Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Chromium is taking a long time to compile
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
SoulDeaD
n00b
n00b


Joined: 16 Jul 2010
Posts: 8

PostPosted: Tue Feb 20, 2018 9:51 am    Post subject: Reply with quote

Zucca wrote:
SoulDeaD wrote:
Did you test it already?
Nope. I don't have urgent need for that... I don't even have ccache installed. But I'm seriously considering enabling ccache for all the webkit based packages.

I'm going to test it very soon on Chromium, but I won't be until after several nights. I use Gentoo as a desktop and I will build only through the nights. I'll use the cache as restore point from where I interrupt the build in the morning. I will report here the results here, but I don't expect anything wrong with it.
Just as a remark, jumbo build on Chromium does not work well, if at all, with ccache. It fails even on an empty cache. My test will be with the slow build. This way I expect preventing cache invalidation because the number of files changed and that lead to change in order in which files were merged. Or if a single files changed, it would lead to cache invalidation of the whole bunch of files that were merged.
Back to top
View user's profile Send private message
SoulDeaD
n00b
n00b


Joined: 16 Jul 2010
Posts: 8

PostPosted: Tue Feb 20, 2018 11:31 am    Post subject: Reply with quote

Zucca wrote:
A little out of topic...
Chiitoo wrote:
https://blogs.gentoo.org/mgorny/2017/07/23/optimizing-ccache-using-per-package-caches/

Am I missing something... But I think one could just get away with a single if -sentence.

/etc/portage/bashrc:
if [[ ${FEATURES} == *ccache* && ${EBUILD_PHASE_FUNC} == src_* ]]; then
   if [[ ${CCACHE_DIR} == /var/cache/ccache ]]; then
      export CCACHE_DIR=/var/cache/ccache/${CATEGORY}/${PN}:${SLOT}
      mkdir -p "${CCACHE_DIR}" || die
   fi
fi

Could be simply:
Code:
if [[ ${CCACHE_DIR} == /var/cache/ccache && ${FEATURES} == *ccache* && ${EBUILD_PHASE_FUNC} == src_* ]]; then
    # Rest of the code
fi
... Right?

I'm thinking of using that... But maybe slightly modified version.

Actually I can skip the ${CCACHE_DIR} == /var/cache/ccache condition. It's necessary only if I want to use separate cache only when I specify the /var/cache/ccache directory in make.conf or by hand. I'm going to activate ccache only for the packages I want, so this test is unnecessary. Is there a config file where I can override the FEATURES variable per package instead of globally in make.conf?

Just export CCACHE_DIR=${CCACHE_DIR}/${CATEGORY}/${PN}:${SLOT}

Is that correct?
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Mon Mar 12, 2018 5:45 am    Post subject: Reply with quote

Chiitoo wrote:
mv wrote:
As an alternative, you can also think about using a per-package ccache temporary directory, although it is then your responsibility to clean up regularly. mgorny had some blog post somewhere about it.

Fairly sure it's this here thing:

https://blogs.gentoo.org/mgorny/2017/07/23/optimizing-ccache-using-per-package-caches/


This doesn't work:
Code:
du -sh /var/cache/ccache/
164K   /var/cache/ccache/

I did it exactly as it's described in the blog.

Fortunately I have installed ck-sources and disabled jumbo-build which makes it bearable to compile and work in the same time on my E6300 with 6G or RAM. What I could have done better was to remove j2 from MAKEOPTS and this way free one core to make my work smoother, but it's OK this way too. Next time :-)

EDIT:

I think there's a problem particularly with Chromium. Portage created separate cache for other packages I emerged. Maybe that has something to do with Chromium being built with Clang.

EDIT2:

According to Knowledge Base:Overriding environment variables per package article I created /etc/portage/env directoryand put a file there which contained the CCACHE_DIR var. Then in package.env I selected this file for Chromium just the same ways as it's done for use flags in package.use. Did the same for libreoffice. It looks like it works for libreoffice, but it doesn't for Chromium. I think it's because Chromium build is switched to Clang and CCACHE needs different options to deal with Clang. Unfortunately my current knowledge level does not allow me to dig deeper into it and currently I can't spare time to increase it.

Maybe I'll dig a bit deeper for the next update of Chromium. I consider using a different way of combining the KB article with the blog post, different from comparing CCACHE_DIR value. Maybe a checking if a different variable is set and switching CCACHE_DIR for individual packages and s shared one.
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Tue Mar 13, 2018 12:21 pm    Post subject: Reply with quote

I assembled a solution to build Chromium with individual cache, taking into account that it's being built with Clang now.
Using the following sources:
1) Current thread;
2) Optimizing ccache using per-package caches;
3) Knowledge Base:Overriding environment variables per package
4) Gentoo Project/Clang

I assembled the following solution:

/etc/portage/bashrc:
Code:
if [[ ${FEATURES} == *ccache* && ${EBUILD_PHASE_FUNC} == src_* ]]; then
    if [[ -n $IND_CACHE ]]; then
        export CCACHE_DIR=${CCACHE_DIR}/${CATEGORY}/${PN}:${SLOT}
        mkdir -p "${CCACHE_DIR}" || die
    else
        export CCACHE_DIR=${CCACHE_DIR}/shared
        mkdir -p "${CCACHE_DIR}" || die
    fi
fi



/etc/portage/env/ind-cache:
Code:
IND_CACHE=yes


/etc/portage/package.env/ind-cache:
Code:
app-office/libreoffice ind-cache
www-client/chromium ind-cache


According to (4) ccache version must be >=ccache-3.9-r3. On 3.2.4 the build failed. I updated to 3.3.4 and that seems to solve the problem.

Тhere is a subfolder in the default ccache folder, named shared, where there's shared cache and subfolders for each category and package marked with IND_CACHE=yes in package.env. Now it's even possible to "resume" a terminated build.

The only thing I don't like is that portage instantiates ccache in the default folder, no matter what /etc/portage/bashrc exports. This creates the ccache.conf and folders named with digits and letters. Maybe portage does that before bashrc is executed?

This post has been edited several times, please check if you've read the latest version.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Tue Mar 13, 2018 9:00 pm    Post subject: Reply with quote

Posting in here just to warn everyone that chromium 65's (currently in ~arch) compile time is %$@£ing insane. It forces use of clang - which doesn't work with distcc and would invalidate ccache anyway if not for jumbo-build already breaking it. I saw it running a bundled copy of nodejs too despite $DEPENDing on the system nodejs package, there's probably more where that came from. The icing on the cake is that it spits unrecognised flag warnings for every compile command, because the build system adds a bunch of GCC-specific flags! Were they even thinking when they wrote this stuff?

This is still ongoing:
Code:
~ # qlop -gtHcv --date '1 week ago' chromium
 * www-client/chromium-65.0.3325.146
     started: Fri Mar  9 23:38:02 2018
     elapsed: 3 days, 21 hours, 19 minutes, 33 seconds

I've already sunk the cost of it so I'm going to let it finish, but this is the last time. Next time it wants me to update, it's getting replaced with Firefox.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Wed Mar 14, 2018 6:43 am    Post subject: Reply with quote

Ant P. wrote:
chromium 65's (currently in ~arch)

65 is already arch since 1-2 days.
Quote:
It forces use of clang which [...] would invalidate ccache anyway

Of course, the first time after such a change the ccache will not help. But hopefully not for the next upgrade again. I have no experience with it, though.
Quote:
I saw it running a bundled copy of nodejs too

This is nothing new. AFAIK this is on their TODO list since years.
Quote:
unrecognised flag warnings for every compile command, because the build system adds a bunch of GCC-specific flags!

Perhaps your clang is too old (I used clang:6). Also, it might be related with your CFLAGS:
I had such messages (and actually even a segfault with clang:6) before I filtered -fno-plt. (I have no idea why filtering -fno-plt avoided warnings about various -Wl,... flags not being used....)
If you use portage-bashrc-mv you should also set NOLDADD=1 and filter all -flto-related stuff (because by default, portage-bashrc-mv adds C*FLAGS to LDFLAGS as this is safe for gcc and needed for flto).
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Wed Mar 14, 2018 7:38 am    Post subject: Reply with quote

Regarding the compile time, no-jumboo build of v63 took nearly the same time as no-jumboo build of 65.
Regarding jumboo build and ccache, I think both are never going to work together. Even two consequent compilations of one and the same version were failing.
Regarding the warnings - they are harmless.
Regarding Firefox, I heard not very good things about Rust compilation speed, so you might not get better compile times with it. But it's worth a try.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Wed Mar 14, 2018 8:29 am    Post subject: Reply with quote

logrusx wrote:
Regarding Firefox, I heard not very good things about Rust compilation speed, so you might not get better compile times with it. But it's worth a try.

Rust takes 18 hours on my slow netbook (it also suffers from a total lack of distcc/ccache support). There's also frequent pain from it overspecifying version numbers in its deps which cause it to fail late into the build with errors about libressl being 0.0.1 off or whatever.

On the other hand, chromium's still going.
Back to top
View user's profile Send private message
Zucca
Moderator
Moderator


Joined: 14 Jun 2007
Posts: 3345
Location: Rasi, Finland

PostPosted: Wed Mar 14, 2018 9:14 am    Post subject: Reply with quote

With such high compile times and not being able to use distcc and ccache, wouldn't it be more benefitical to use crossdev etc. and compile the whole mess on another PC althogether?
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
Quote:
I am NaN! I am a man!
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Wed Mar 14, 2018 10:45 am    Post subject: Reply with quote

Using distcc with clang is possible. It's just a matter of some research, modifications and some trial and error. There are quite a lot of resources on the Internet. Gentoo Wiki Clang page also confirms that:
Gentoo/Clang#distcc
Furthermore Clang is cross compiler and therefore it must be subject to distributed compiling:
Cross-compilation using Clang
Unfortunately with Google's "kill a fly with an atomic bomb" approach I think we can't do much about Chromium compile times. They use huge amount of cores and RAM, even on their personal working stations. With Jumboo build a full development Chromium build takes less than 20 minutes and they somehow recompile only the parts they've modified. How do you make people who have such resources on their disposal improve compilation process when they experience no necessity to do so? No way. Either Chromium takes a different direction, be it by forking a different project, or because of some fortunate circumstance forcing Google to do so, or we stay in reaction mode, ready to take whatever Google throws at us and deal with it. For now I don't see an option different than the later one, so I'm looking for ways to do my job. I prefer to be prepared and that's why I try this approach with non-jumboo build and ccache. If it works even partially I'll be fine.
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Wed Mar 14, 2018 9:59 pm    Post subject: Reply with quote

Test 1: Passed - completed a cached build.
It took a bit more than hour, most of which was python scripts execution. The uncached build took more than 30 hours, but I can't account for how much it was delayed because I did other, though not heavy stuff, maybe through 1/5 to 1/4 of the time.
The size of generated cache is 1.7G.
Now we wait for the next stable version, which is scheduled approximately for 12th of April, to see if there's any real benefit or if it even builds with cache.
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Tue May 01, 2018 5:12 am    Post subject: Reply with quote

It appears that cache is barely useful, if of any use at all, for Chromium build.
Update from 65.0.3325.146 to 66.0.3359.117 is taking more than 14 hours already and is still going. Nothing suggest cache is even slightly useful.
Back to top
View user's profile Send private message
n05ph3r42
Tux's lil' helper
Tux's lil' helper


Joined: 11 Jul 2016
Posts: 134

PostPosted: Tue May 01, 2018 8:29 am    Post subject: chromium compilation speed up trick Reply with quote

check https://forums.gentoo.org/viewtopic-t-1074724.html
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Tue May 01, 2018 8:41 am    Post subject: Re: chromium compilation speed up trick Reply with quote

n05ph3r42 wrote:
check https://forums.gentoo.org/viewtopic-t-1074724.html

This experiment was about testing if using ccache can benefit the compile time between two consequent versions of Chromium. Individual cache was intended to increase the chances of cache hits to a maximum, while jumboo build would decrease it to minimum if not diminish it at all and significantly increase the chances of build failures.
The conclusion is it wouldn't, therefore jumboo build would be faster. However it's prone to OOM and would significantly decrease usability of the system while compiling mostly because of huge memory consumption.

For the next Chromium update I will consider enabling jumboo build and disabling ccache individually for Chromium.
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Sat May 12, 2018 8:53 am    Post subject: Reply with quote

After all it turned out that individual cache for Chromium is not that useless.
Chromium 65.0.3325.146 took 100 000 seconds (~28 hours) to compile without jumboo build and like 1 hour to recompile from cache.
Chromium 66.0.3359.117 took twice as much, mainly because I was using the computer, which means the cache from 65 didn't do much, if anything to speed up the build.
Chromium 66.0.3359.139 however took only 12375 seconds (~3,5 hours) to recompile using the cache from 117, which is nearly 10% supposing that 66 would have taken nearly the same time as 65 if I hadn't used the computer.

Libreoffice seems to have benefited less than 10% decrease of the time between versions 6.0.1, 6.0.2, 6.0.3 and 6.0.4, noticing the decrease is greater between 6.0.3 and 6.0.4 and insignificant between 6.0.1 and 6.0.2.

The conclusion regarding Chromium is that although the build is quite slow for major versions, the benefit is significant between minor updates. The most important point for me is the system is usable while compiling without jumboo build as opposed to jumboo build with merge filke limit 10(that's how much my system can take), when at moments system almost freezes.

Given the above I find that experiment successful and the results useful. However people have way more powerful systems with more RAM these days and soon I'll get such as well, so for people with more modern systems cache might be almost irrelevant.

So people with old systems like mine (E6300 with 6G RAM) who need to use their systems while compiling might consider this option.

An important point is that I'm using ck-sources with Con Kolivas MUQSS scheduler to increase the system responsiveness.
Back to top
View user's profile Send private message
alinefr
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2009
Posts: 113
Location: São Paulo, Brasil

PostPosted: Wed Jun 13, 2018 2:53 am    Post subject: Reply with quote

I wanted to build chromium as I don't want to use google-chrome binaries anymore, so I left my computer building while I went to work. I was expecting to be able to install the binary in the office as my home system serves binhost but I was afraid something was wrong because I could not find chromium in my binhost. Back home I was upset to find out that chromium is still building.

Code:

* www-client/chromium-67.0.3396.62
     started: Tue Jun 12 13:28:58 2018
     elapsed: 10 hours, 13 minutes, 55 seconds


As a way of comparison my latest builds of firefox:
Code:

firefox-52.6.0: Sat Mar 10 13:28:55 2018: 36 minutes, 56 seconds
firefox-52.6.0: Fri Mar 30 10:17:51 2018: 1 hour, 50 minutes, 42 seconds
firefox-52.6.0: Sat May 12 22:28:18 2018: 1 hour, 45 minutes, 15 seconds
firefox-52.8.0: Thu May 24 01:17:34 2018: 2 hours, 55 minutes, 49 seconds


And libreoffice:
Code:

libreoffice-5.4.5.1: Tue Mar 27 01:09:59 2018: 3 hours, 13 minutes, 15 seconds
libreoffice-5.4.5.1: Wed Apr  4 09:16:37 2018: 2 hours, 58 minutes, 3 seconds
libreoffice-6.0.3.2: Thu May 24 01:19:54 2018: 4 hours, 40 minutes, 12 seconds
libreoffice-6.0.3.2: Thu May 24 08:59:43 2018: 3 hours, 43 minutes, 46 seconds
libreoffice-6.0.3.2: Fri May 25 01:54:38 2018: 3 hours, 24 minutes, 14 seconds
libreoffice-6.0.3.2: Thu Jun  7 01:04:08 2018: 4 hours, 48 minutes, 26 seconds


I'm ok with nightly or daily builds. But days of build is too much. Holy clang crap :evil:
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Wed Jun 13, 2018 8:52 am    Post subject: Reply with quote

alinefr wrote:

I'm ok with nightly or daily builds. But days of build is too much. Holy clang crap :evil:

It's not clang to blame. Only two months ago the build used gcc and it didn't make a difference. It's google development process. If you implement the solution I implemented, you'll bring down the minor version change builds to below 1-2 hours, but major version build between 24 and 48 hours. On Intel Core 2 Duo E6300 with 6 Gigs of RAM it takes around 36 hours. Jumboo build takes around 7-9 hours, but the system is not usable most of the time and it's vulnerable to OOMs with file merge limit of 15. That's why I prefer to have one long build from time to time and number of shorter builds in between.
Back to top
View user's profile Send private message
alinefr
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2009
Posts: 113
Location: São Paulo, Brasil

PostPosted: Wed Jun 13, 2018 1:03 pm    Post subject: Reply with quote

It finished!

Code:

chromium-67.0.3396.62: Tue Jun 12 13:20:13 2018: 16 hours, 24 minutes, 2 seconds


logrusx wrote:
If you implement the solution I implemented, you'll bring down the minor version change builds to below 1-2 hours, but major version build between 24 and 48 hours.

I may try it next time. I was not expecting so long time to compile as I was not used to build chromium. Thanks!
Back to top
View user's profile Send private message
logrusx
Veteran
Veteran


Joined: 22 Feb 2018
Posts: 1533

PostPosted: Wed Jun 13, 2018 1:06 pm    Post subject: Reply with quote

alinefr wrote:
It finished!

Code:

chromium-67.0.3396.62: Tue Jun 12 13:20:13 2018: 16 hours, 24 minutes, 2 seconds


logrusx wrote:
If you implement the solution I implemented, you'll bring down the minor version change builds to below 1-2 hours, but major version build between 24 and 48 hours.

I may try it next time. I was not expecting so long time to compile as I was not used to build chromium. Thanks!

You have more than twice faster system than me. Soon I'll upgrade to something really powerful, so maybe I'll forget for issues of that kind, but for now it's not reasonable to upgrade just to build faster :-)
Back to top
View user's profile Send private message
weedy
Apprentice
Apprentice


Joined: 24 Jun 2005
Posts: 247

PostPosted: Sun Aug 26, 2018 4:00 pm    Post subject: Reply with quote

mv wrote:

Code:
CCACHE_SLOPPINESS="file_macro,time_macros,include_file_mtime,include_file_ctime,file_stat_matches,pch_defines"
CCACHE_BASEDIR="${PORTAGE_TMPDIR}/portage"

Without the latter, you will have almost no hits for upgrades in direct mode. Note that changing such variables invalidates your previous ccache content.
Of course, your ccache directory should be on a file system which does not cause serious performance hits for huge directories (e.g. ext4). As an alternative, you can also think about using a per-package ccache temporary directory, although it is then your responsibility to clean up regularly. mgorny had some blog post somewhere about it.


So I'm guessing this has been tested on chromium, but are these loose setting a good idea system wide? I've set up chrome vs. system ccache so I can leave these settings for chrome by itself.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Aug 26, 2018 4:09 pm    Post subject: Reply with quote

weedy wrote:
So I'm guessing this has been tested on chromium, but are these loose setting a good idea system wide?

Especially system wide.
With chromium itself I currently do not get a good improvement for major upgrades.
Back to top
View user's profile Send private message
weedy
Apprentice
Apprentice


Joined: 24 Jun 2005
Posts: 247

PostPosted: Mon Aug 27, 2018 6:06 am    Post subject: Reply with quote

logrusx wrote:

/etc/portage/bashrc:
Code:
if [[ ${FEATURES} == *ccache* && ${EBUILD_PHASE_FUNC} == src_* ]]; then
    if [[ -n $IND_CACHE ]]; then
        export CCACHE_DIR=${CCACHE_DIR}/${CATEGORY}/${PN}:${SLOT}
        mkdir -p "${CCACHE_DIR}" || die
    else
        export CCACHE_DIR=${CCACHE_DIR}/shared
        mkdir -p "${CCACHE_DIR}" || die
    fi
fi


Next question.
If we are going to bother putting intelligence in front of ccache invocation is there any reason we wouldn't add something like export CCACHE_BASEDIR="${WORKDIR}/"?
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Tue Aug 28, 2018 5:03 am    Post subject: Reply with quote

weedy wrote:
export CCACHE_BASEDIR="${WORKDIR}/"?

This is worse than CCACHE_BASEDIR=${PORTAGE_TMPDIR}/portage as explained in e.g. this bug.
Back to top
View user's profile Send private message
LordArthas
Guru
Guru


Joined: 01 Nov 2004
Posts: 500
Location: Maniago, Friûl, Italia

PostPosted: Wed Sep 26, 2018 1:05 pm    Post subject: Reply with quote

Hi!

Chromium just finished compiling on my box as well:

Code:
chromium-69.0.3497.100: Tue Sep 25 18:43:18 2018: 18 hours, 14 minutes, 9 seconds


As you see, it took an eternity. My AMD 4-core isn't exactly new, but chromium is the only package which takes a long time to build.

Michele.
_________________
Michele Beltrame
https://www.cattlegrid.info/
Back to top
View user's profile Send private message
nowhereman
n00b
n00b


Joined: 01 Sep 2006
Posts: 38

PostPosted: Sat Oct 27, 2018 1:13 pm    Post subject: Reply with quote

Building chromium also takes a huge amout of time for me. It seems to have started with version 66:

Code:
     Tue Apr 24 13:27:21 2018 >>> www-client/chromium-66.0.3359.117:0                                                                                                             
       merge time: 4 hours, 6 minutes and 5 seconds.                                                                                                                               

     Wed May  9 06:55:35 2018 >>> www-client/chromium-66.0.3359.139:0                                                                                                             
       merge time: 8 hours, 27 minutes and 19 seconds.                                                                                                                             

     Sun May 27 13:09:55 2018 >>> www-client/chromium-66.0.3359.170:0                                                                                                             
       merge time: 11 hours, 1 minute and 16 seconds.                             


Then I enabled ccache and got a rebuild in 25 minutes. That is not really useful though, because there are new major and minor versions all the time.
I also tried jumbo-build, but it didn’t really help much either.

Plus now I have to install llvm:4, llvm:5 and llvm:6, which each take more than an hour.

I wonder when we'll reach the point when after building the newest version, the next one is already available.
At least now the build time is not increasing as much anymore:
Code:
     Sat Oct 27 15:12:48 2018 >>> www-client/chromium-70.0.3538.67:0                                                                                                               
       merge time: 12 hours, 24 minutes and 39 seconds.   


For comparison:

Code:
     Thu Mar  8 13:41:38 2018 >>> app-office/libreoffice-5.4.5.1:0                                                                                                                 
       merge time: 2 hours, 33 minutes and 19 seconds.

_________________
NOTHING IS REAL
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 3 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum