Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
portage suggestion - --exclude option
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Klavs
Guru
Guru


Joined: 22 May 2002
Posts: 536
Location: Denmark

PostPosted: Mon Jun 02, 2003 12:31 pm    Post subject: portage suggestion - --exclude option Reply with quote

Hi guys,

I was wondering if I was the only one who could really use an --exclude option.

emerge -Uu php (or whatever) often gives me 30-50 packages needing to be upgraded - some of which is big packages (like X) due to a small -rX change.

Therefore it would be great with an --exclude option, so I could list the packages not to be considered. The --exclude-file option would be cool too.

Even cooler would it be to have a --disregard-revision-only-changes flag too or something like that :)
_________________
Best regards,

Klavs Klavsen
Denmark

Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38.
Back to top
View user's profile Send private message
Loke
Apprentice
Apprentice


Joined: 25 May 2002
Posts: 274
Location: Norway

PostPosted: Mon Jun 02, 2003 12:53 pm    Post subject: Reply with quote

Both "problems" you describe are solved (by you) through the USE="" flags in /etc/make.conf and by (gentoo dev's) ensuring ebuilds are properly written and dont request a package upgrade unless its neccesary.

You can also use the emerge --inject to exclude packages you dont want, to trick portage into thinking its already availabe. So everything you requested is already in Gentoo :-)

Edit: Obviously, you didnt ask about the USE="" option, so never mind that :-) BUT: You can still inject packages, like I mentioned above. However, when an ebuild requires one or several package upgrades it _should_ be a reason for doing so (eg. needs it to work properly) However I suspect most never ebuilds just wants the latest version anyway... I know mine does hehe...

What Id like as a feature instead, is a list of DO_NOT_TOUCH_THESE_PROGRAMS_EVER_NEVER so I could put what I want into this list and never have to worry about them being screwed by an emerge world or something similar. I am not aware of any features that does this.
Back to top
View user's profile Send private message
Klavs
Guru
Guru


Joined: 22 May 2002
Posts: 536
Location: Denmark

PostPosted: Mon Jun 02, 2003 1:01 pm    Post subject: Reply with quote

Nope it's not.

I have X installed - and I want it to be. I just don't want it to be upgraded when I run emerge -Uu php - but I don't want to manually list the 27 other upgrades it suggests when running emerge -Uu (or even with --deep) php because I don't want it to upgrade X.

You see what I mean?
_________________
Best regards,

Klavs Klavsen
Denmark

Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38.
Back to top
View user's profile Send private message
Loke
Apprentice
Apprentice


Joined: 25 May 2002
Posts: 274
Location: Norway

PostPosted: Tue Jun 03, 2003 11:21 am    Post subject: Reply with quote

Yes, I see what you mean - and ive said how to solve it ;-) Just emerge --inject the package you dont want to upgrade, and I recon it will work.
Back to top
View user's profile Send private message
Klavs
Guru
Guru


Joined: 22 May 2002
Posts: 536
Location: Denmark

PostPosted: Tue Jun 03, 2003 11:49 am    Post subject: Reply with quote

So you want me to inject packages that I don't want upgraded. so if I don't want 10 out of 50 packages upgraded, I should inject them - and then when a new revision comes along - I should inject that again ?

Doesn't sound like a very good solution, to what I think is a fair need, considering how often Gentoo's packages get upgraded.
_________________
Best regards,

Klavs Klavsen
Denmark

Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38.
Back to top
View user's profile Send private message
plate
Bodhisattva
Bodhisattva


Joined: 25 Jul 2002
Posts: 1663
Location: Berlin

PostPosted: Tue Jun 03, 2003 12:28 pm    Post subject: Reply with quote

Fair enough. But injecting does provide an immediate workaround, and nobody stops you from using fictitious version numbers. emerge -i x11-base/xfree86-5.0 should leave your installation well outside the greedy reach of portage upgrade attempts for quite a while. :)
Back to top
View user's profile Send private message
Loke
Apprentice
Apprentice


Joined: 25 May 2002
Posts: 274
Location: Norway

PostPosted: Tue Jun 03, 2003 8:55 pm    Post subject: Reply with quote

Exactly :wink:

Edit: I'd still like a DO-NOT-TOUCH-THESE-PROGRAMS-EVER-NEVER list in Gentoo. I think that would solve most of the problems you describe... There are other packages besides X id like emerge to never touch.
Back to top
View user's profile Send private message
crazy-bee
Apprentice
Apprentice


Joined: 03 Jan 2003
Posts: 170

PostPosted: Sat Jun 07, 2003 9:41 am    Post subject: Reply with quote

Count me in.

I definitly need such an option, too.

I helped myself with marking the packages I do not want to be touched as masked, but since this is always overwritten with an emerge sync, it sucks since it has to be done manually.
Back to top
View user's profile Send private message
Lion
Apprentice
Apprentice


Joined: 23 Jun 2002
Posts: 207

PostPosted: Sun Jun 08, 2003 7:32 am    Post subject: The problem is that -u does too much! Reply with quote

I think that we don't need an --exclude here, but that the --upgrade option does too much. IMO "emerge --upgrade package" should do only that: upgrade the named package if an upgrade is available, and only upgrade dependencies if the dependency upgrade is REQUIRED by the newer package.

Instead, now, if package depends on X, for example, and you --upgrade package, an upgrade for X is automatically performed, even if package would function perfectly with the older version of X.

I don't see any reason why --upgrade should do this.
For automatic update of dependencies, we have --deep, don't we?

I think I'm going to file a request for change of the --update behaviour in bugzilla.
Back to top
View user's profile Send private message
Matje
l33t
l33t


Joined: 29 Oct 2002
Posts: 619
Location: Hasselt, Belgium

PostPosted: Sun Jun 08, 2003 8:24 am    Post subject: Reply with quote

You might want to try emerge -U, without the -u flag. This way, only the packages necessary get installed, instead of telling portage to upgrade everything php depends of...

Code:
matje@lambik matje $ emerge -up php
 
These are the packages that I would merge, in order:
 
Calculating dependencies ...done!
[ebuild    UD] sys-libs/glibc-2.3.1-r4 [2.3.2-r1]
[ebuild    U ] app-crypt/mhash-0.8.18-r1 [0.8.16]
[ebuild    UD] media-libs/libgd-1.8.3-r6 [2.0.12]
[ebuild    U ] sys-libs/cracklib-2.7-r7 [2.7-r6]
[ebuild    UD] dev-libs/libxml2-2.5.6 [2.5.7]
[ebuild  N   ] dev-php/php-4.3.2
 
matje@lambik matje $ emerge -p php
 
These are the packages that I would merge, in order:
 
Calculating dependencies ...done!
[ebuild    U ] sys-libs/cracklib-2.7-r7 [2.7-r6]
[ebuild  N   ] dev-php/php-4.3.2

_________________
Life is like a box of chocolates... Before you know it, it's empty...
Back to top
View user's profile Send private message
Lion
Apprentice
Apprentice


Joined: 23 Jun 2002
Posts: 207

PostPosted: Sun Jun 08, 2003 9:31 am    Post subject: Reply with quote

Matje wrote:
You might want to try emerge -U, without the -u flag. This way, only the packages necessary get installed, instead of telling portage to upgrade everything php depends of...


I don't think so. -U tells emerge to upgrade only, never to downgrade (and, as you can see from the example you just gave yourself, this is broken too!).

Furthermore, -U implies -u, so if you add -U to the options, you implicitly add -u as well. I don't have your setup, so please try the emerge -Up that you proposed, and see what that leads to.

Finally, you show that in your case emerge php would lead to the upgrade from cracklib 2.7-r6 to cracklib 2.7-r7. WHY??? I checked the php ebuild, and nowhere is specified that cracklib-2.7-r7 is necessary. As I said before, if I want all dependencies to be updated as well, I will use --deep!
Back to top
View user's profile Send private message
Matje
l33t
l33t


Joined: 29 Oct 2002
Posts: 619
Location: Hasselt, Belgium

PostPosted: Sun Jun 08, 2003 9:49 am    Post subject: Reply with quote

Code:
 matje@lambik matje $ emerge -Up php
>>> --upgradeonly implies --update... adding --update to options.
 
These are the packages that I would merge, in order:
 
Calculating dependencies ...done!
[ebuild    U ] app-crypt/mhash-0.8.18-r1 [0.8.16]
[ebuild    U ] sys-libs/cracklib-2.7-r7 [2.7-r6]
[ebuild  N   ] dev-php/php-4.3.2


I didn't realize that, but the -U flag does work properly. Because upgrade implies upgrade the package and all of it's direct dependency's, you get this output. However, I don't see cracklib and mhash in the ebuild either, but it are not deps of the two that are in there, readline and ncurses, so my best bet is that it has something to do with the inherit php option. This adds more dependency's I think (after all, the deps in the file are added to an existing $DEPEND, and so is the use-variable readline)...
--deep is used for dependency's of dependency's

I'm no developer either, talk to them for more info about this, I'm also just guessing here :-)
_________________
Life is like a box of chocolates... Before you know it, it's empty...
Back to top
View user's profile Send private message
Lion
Apprentice
Apprentice


Joined: 23 Jun 2002
Posts: 207

PostPosted: Sun Jun 08, 2003 11:08 am    Post subject: Reply with quote

Matje wrote:

I didn't realize that, but the -U flag does work properly.

You are right in this case, I did not read your original post correctly.
But I have seen cases where -U definitely wanted to downgrade things. In my case, it was glibc, which led to quite some fun...
Matje wrote:

Because upgrade implies upgrade the package and all of it's direct dependency's, you get this output.

Exactly, and I think this is undesired behaviour.
Why would you always upgrade automatically direct dependencies if those upgrades are not necessary for the package you are upgrading?
If I'm using Gaim, and Gaim depends directly on Xfree, why then should I update a minor revision of Xfree that I would not otherwise think necessary when there is an update for Gaim, or have to jump through all kinds of hoops to prevent this?
Matje wrote:
--deep is used for dependency's of dependency's

Yes, and this is what I don't understand. Why not make --deep act for all dependencies, be it first level or multilevel? I see absolutely no advantage in the current behaviour of --update of automatically updating the first level of dependencies.
Back to top
View user's profile Send private message
Loke
Apprentice
Apprentice


Joined: 25 May 2002
Posts: 274
Location: Norway

PostPosted: Wed Jun 11, 2003 12:55 pm    Post subject: Reply with quote

I agree, updating -rX versions which quite clearly poses no real advantage beside the fancy new -rX extension is pointless really, and should only occure when you request it with --deep option. EDIT: I realize there _are_ changes in a package when they change the -rX number, but often these are just additional comments in a config file for example.

I believe a redesign of the --upgrade feature, together with a NEVER-TOUCH-THESE-PACKAGES-EVER (maybe a /usr/portage/profiles/package.protected file) list to put packages of your liking into would go along way to solve this problem.

Edit: typo


Last edited by Loke on Wed Jun 11, 2003 1:20 pm; edited 2 times in total
Back to top
View user's profile Send private message
Loke
Apprentice
Apprentice


Joined: 25 May 2002
Posts: 274
Location: Norway

PostPosted: Wed Jun 11, 2003 1:04 pm    Post subject: Reply with quote

Example of broken behaviour:

Code:

# emerge -Uup world

These are the packages that I would merge, in order:

Calculating world dependencies ...done!
[ebuild    U ] sys-kernel/ksymoops-2.4.9 [2.4.8]
[ebuild    U ] sys-apps/e2fsprogs-1.33 [1.32-r2]
[ebuild    U ] net-analyzer/nmap-3.27 [3.20]
[ebuild    U ] dev-libs/libxslt-1.0.30 [1.0.29]
[ebuild    U ] app-emulation/wine-20030508 [20030219]
[ebuild    U ] dev-java/sun-jdk-1.4.1.02-r1 [1.4.1.02]
[ebuild    U ] net-www/mozilla-1.3-r2 [1.3-r1]
[ebuild    UD] sys-apps/acpid-1.0.1 [1.0.1-r1]

# emerge -Up world
>>> --upgradeonly implies --update... adding --update to options.

These are the packages that I would merge, in order:

Calculating world dependencies ...done!
[ebuild    U ] sys-kernel/ksymoops-2.4.9 [2.4.8]
[ebuild    U ] sys-apps/e2fsprogs-1.33 [1.32-r2]
[ebuild    U ] net-analyzer/nmap-3.27 [3.20]
[ebuild    U ] dev-libs/libxslt-1.0.30 [1.0.29]
[ebuild    U ] app-emulation/wine-20030508 [20030219]
[ebuild    U ] dev-java/sun-jdk-1.4.1.02-r1 [1.4.1.02]
[ebuild    U ] net-www/mozilla-1.3-r2 [1.3-r1]
[ebuild    UD] sys-apps/acpid-1.0.1 [1.0.1-r1]

#


Notice the
Code:

>>> --upgradeonly implies --update... adding --update to options.


And _especially_ :

Code:

[ebuild    UD] sys-apps/acpid-1.0.1 [1.0.1-r1]


An upgrade request which in fact downgrades a package.

EDIT: While Im at it, lets take a look at my mozilla package. I see that portage wants to "upgrade" my mozilla package:
Code:

[ebuild    U ] net-www/mozilla-1.3-r2 [1.3-r1]


You'd expect id get a "better" mozilla by doing this right? At least thats what I think when I hear somethings being "upgraded" :-) Well, here's a diff from the two ebuilds:

Code:

# diff /usr/portage/net-www/mozilla/mozilla-1.3-r1.ebuild /usr/portage/net-www/mozilla/mozilla-1.3-r2.ebuild
3c3
< # $Header: /home/cvsroot/gentoo-x86/net-www/mozilla/mozilla-1.3-r1.ebuild,v 1.6 2003/05/22 04:25:42 azarah Exp $
---
> # $Header: /home/cvsroot/gentoo-x86/net-www/mozilla/mozilla-1.3-r2.ebuild,v 1.2 2003/06/09 19:26:02 brad Exp $
321,323c321,325
<               export CFLAGS="${CFLAGS/-march=pentium4/-march=pentium3}"
<               export CXXFLAGS="${CXXFLAGS/-march=pentium4/-march=pentium3}"
<
---
>       if [ "$(gcc-minor-version)" -lt "3" ]; then
>           replace-flags -march=pentium4 -march=pentium3
>           filter-flags -msse2
>       fi
>
#


This revision to the ebuild is most likely neccesary for people with an Intel P4 CPU - however, since Im on an AMD, do I benefit from letting my dual cpu rig compile for X hours? No, not at all. In fact, I can only think of negative aspects: I waste bandwith downloading mozilla (again), I waste rsync mirror bandwith, I waste cpu cycles and most importantly I waste alot of time.
Back to top
View user's profile Send private message
Ssl
Apprentice
Apprentice


Joined: 21 Feb 2003
Posts: 178
Location: Serbia

PostPosted: Thu Jun 12, 2003 8:09 am    Post subject: Reply with quote

Loke wrote:
I agree, updating -rX versions which quite clearly poses no real advantage beside the fancy new -rX extension is pointless really, and should only occure when you request it with --deep option. EDIT: I realize there _are_ changes in a package when they change the -rX number, but often these are just additional comments in a config file for example.

I believe a redesign of the --upgrade feature, together with a NEVER-TOUCH-THESE-PACKAGES-EVER (maybe a /usr/portage/profiles/package.protected file) list to put packages of your liking into would go along way to solve this problem.

Edit: typo

There is solution (this is also said somewhere in userdocs/portage*) for NEVER-TOUCH-THESE-PACKAGES... :D your request.

Example:

If I do an
Code:
emerge -p world | grep xfree
I see this:
Code:
[ebuild    U ] x11-base/xfree-4.3.0-r3 [4.3.0-r1]


I don't want to upgrade xfree-4.3.0-r1 to newer one, so I edited /var/cache/edb/world and added
Code:
=x11-base/xfree-4.3.0-r1


Now with emerge -p world | grep xfree I see nothing ! :D

As I know, this is working only for emerge world not for plain emerge <package_name>. Any comments?

Slobo
Back to top
View user's profile Send private message
Matje
l33t
l33t


Joined: 29 Oct 2002
Posts: 619
Location: Hasselt, Belgium

PostPosted: Thu Jun 12, 2003 8:50 am    Post subject: Reply with quote

Just inject the package, less hassle, and it works too when you try anything else as emerge world...
_________________
Life is like a box of chocolates... Before you know it, it's empty...
Back to top
View user's profile Send private message
Loke
Apprentice
Apprentice


Joined: 25 May 2002
Posts: 274
Location: Norway

PostPosted: Thu Jun 12, 2003 6:36 pm    Post subject: Reply with quote

Slobo wrote:

I don't want to upgrade xfree-4.3.0-r1 to newer one, so I edited /var/cache/edb/world and added
Code:
=x11-base/xfree-4.3.0-r1


Now with emerge -p world | grep xfree I see nothing ! :D


Matje wrote:

Just inject the package, less hassle, and it works too when you try anything else as emerge world...


Both solutions work, but they really doesnt adress the problem. (I see them as quick-hacks btw) If I add a certain xfree ebuild flavour to the world file, I have to add it again when another ebuild is available in stable for example.

The solution to this, is whats mentioned earlier in this thread: Inject the package with a version number high above portages greedy grip, for example xfree-5.0. However, what then when xfree-5.0 is released? Like I said before, its a quick-hack, not a solution.

Both these methods are quick and dirty hacks. And after injecting X packages, do you really keep track after Y months or have you in reality lost control over what youve done in the past to your preciousss portage tree?

A NEVER-TOUCH-THESE-PACKAGES... list could just be:

Code:

xfree
mplayer
nvidia-kernel
nvidia-glx


for example, and these ebuilds would _NEVER_ be touched - even if it meant upgrades in the future which does in fact require an xfree upgrade breaks. This list should _only_ be used by people who know what they are doing eg. "experts" :-)

You could for example have a FEATURES="portage-protect-list" in /etc/make.conf, so you explicitly have to request this feature (much like prelinking for example). This way hopefully only people who know how to handle this, enables it :-)

Comments? Perhaps its time to attract a developers attention to this thread?
Back to top
View user's profile Send private message
deepthought
Guru
Guru


Joined: 04 Apr 2003
Posts: 321
Location: icbm://5131''N:0710''E

PostPosted: Thu Jun 12, 2003 7:58 pm    Post subject: Reply with quote

Loke wrote:
Slobo wrote:

I don't want to upgrade xfree-4.3.0-r1 to newer one, so I edited /var/cache/edb/world and added
Code:
=x11-base/xfree-4.3.0-r1


Now with emerge -p world | grep xfree I see nothing ! :D


Matje wrote:

Just inject the package, less hassle, and it works too when you try anything else as emerge world...


Both solutions work, but they really doesnt adress the problem. (I see them as quick-hacks btw) If I add a certain xfree ebuild flavour to the world file, I have to add it again when another ebuild is available in stable for example.


Hm, I would disagree on this. When wanting to "pin" a package to a certain version (aka DONTEVERUPDATE), you *don't want* to update. Saying things like
Code:
=foo-1.2.5-r4

is a perfectly safe solution for your problem. Btw, this is ubercustomizable: you can "pin" the package to a certain major/minor/rev version or say "I want foo, but I want it to be never greater/lighter/equal than v<something>".

This is certainly not a "quick-hack" as you stated above, but the real power of the Gentoo portage system.

Loke wrote:

The solution to this, is whats mentioned earlier in this thread: Inject the package with a version number high above portages greedy grip, for example xfree-5.0. However, what then when xfree-5.0 is released? Like I said before, its a quick-hack, not a solution.

Both these methods are quick and dirty hacks. And after injecting X packages, do you really keep track after Y months or have you in reality lost control over what youve done in the past to your preciousss portage tree?


This is a *bad idea*. Noone (except for those guys being able to recite their package tree in reverse polish notation) will be able to track the changes on this. Note that starting this "inject frenzy" also can have unwanted side-effects: Injecting makes portage think a package is really there, so the deps for it are satisfied and so on... this can also badly break your installation.

Loke wrote:

A NEVER-TOUCH-THESE-PACKAGES... list could just be:

Code:

xfree
mplayer
nvidia-kernel
nvidia-glx


for example, and these ebuilds would _NEVER_ be touched - even if it meant upgrades in the future which does in fact require an xfree upgrade breaks. This list should _only_ be used by people who know what they are doing eg. "experts" :-)

You could for example have a FEATURES="portage-protect-list" in /etc/make.conf, so you explicitly have to request this feature (much like prelinking for example). This way hopefully only people who know how to handle this, enables it :-)

Comments? Perhaps its time to attract a developers attention to this thread?


I would deem this unnecessary, because the "pin-version" feature of portage in the world file perfectly satisfies all your needs.

Regards,
Alexander
_________________
Out of loyalty to its disregarded comrades, this message feels free to ignore the reader.
Registered Linux User #317705
Back to top
View user's profile Send private message
Loke
Apprentice
Apprentice


Joined: 25 May 2002
Posts: 274
Location: Norway

PostPosted: Thu Jun 12, 2003 8:13 pm    Post subject: Reply with quote

Ok, if the "pin-feature" works they way you describe it, I agree it fits the needs I wanted, so thanks for pointing that out. I misunderstood this feature when it was mentioned before, since I didnt realize you _could_ lock a certain version from never being updated.
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9644
Location: beyond the rim

PostPosted: Fri Jun 13, 2003 12:26 am    Post subject: Reply with quote

There is already a bug for this: 16342. I'm really for it as I think the inject is an ugly workaround and the version-pinning never worked right for me. Well, at least I have now another item on my "things I wanna do to portage"-list.
Back to top
View user's profile Send private message
deepthought
Guru
Guru


Joined: 04 Apr 2003
Posts: 321
Location: icbm://5131''N:0710''E

PostPosted: Fri Jun 13, 2003 11:19 am    Post subject: Reply with quote

Hm, at least for me, version pinning works perfectly. What's wrong with it?

Regards,
Alexander
_________________
Out of loyalty to its disregarded comrades, this message feels free to ignore the reader.
Registered Linux User #317705
Back to top
View user's profile Send private message
Loke
Apprentice
Apprentice


Joined: 25 May 2002
Posts: 274
Location: Norway

PostPosted: Fri Jun 13, 2003 11:26 am    Post subject: Reply with quote

Not that Ive tried it yet, but wouldnt version pinning only work for world upgrades? It seems logical at least, and im pretty sure it does this by design - but is this what the requests in this thread deals with?
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9644
Location: beyond the rim

PostPosted: Fri Jun 13, 2003 11:49 am    Post subject: Reply with quote

deepthought wrote:
Hm, at least for me, version pinning works perfectly. What's wrong with it?


Well, I only played with it a bit, I tried to pin my mozilla version to >=1.3 (which was ~x86 at that time) and that didn't work. Maybe I was expecting too much from this little feature.
Back to top
View user's profile Send private message
Mnemia
Guru
Guru


Joined: 17 May 2002
Posts: 476

PostPosted: Thu Jun 26, 2003 4:35 am    Post subject: Reply with quote

OK, here's a weird one for ya guys -
Code:

luna root # emerge -pU  world
>>> --upgradeonly implies --update... adding --update to options.

These are the packages that I would merge, in order:

Calculating world dependencies ...done!
[ebuild    U ] media-gfx/gimp-1.2.4 [1.3.15] +python +nls +gnome +aalib +perl -doc +jpeg +png -tiff -doc
...

Why, oh why, is portage trying to downgrade gimp without popping up the little 'D' flag and thus allowing me to stop it from doing that when I use '-U' instead of '-u'? At first I thought this problem was occurring because the gimp version I have installed is in the ~x86 profile and I don't have ~x86 set in make.conf (I emerged it manually). But, I have done that exact thing with ~10 other packages and none of them have this problem. None of the others fail to show that flag. Is this a bug in the gimp ebuilds or just an example of horribly broken behavior in portage??

PS: I'm not going to be using --inject to fix this. As pointed out above, this risks breaking my system. And besides that's just a major hassle to keep track of all my own injected ebuilds just to cobble around portages' failure to properly track versions. If it doesn't work in all cases then -U is completely useless to me when doing an update world.

PPS: I've noticed this same problem a number of times lately. Methinks there are some major bugs lurking in the newer portage builds...
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 1, 2  Next
Page 1 of 2

 
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