Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Why do use-flag dependencies require so much manual handling
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 500
Location: NRW, Germany

PostPosted: Thu May 02, 2019 10:41 am    Post subject: Why do use-flag dependencies require so much manual handling Reply with quote

I like to play games; and the reality of the situation is that this very often means running 32-bit binaries on my 64-bit system, sometimes via wine. As a result I maintain a package.use file with around 100 packages setting abi_x86_32 for each of them and right now I'm wondering why portage works the way it does.
When I want to install pkg/foo that depends on pkg/bar, portage doesn't abort and tell me to add pkg/bar to my world file first. But in the use-flag example that is pretty much what happens. The package.use file i mentioned earlier contains only a handful of packages that I need directly, most of them are transitive dependencies; or at least I think they are, at this point they might or might not be. The most efficient way to clean up the file is probably to delete it and recreate it through multiple iterations of 'emerge -a'.
(On that topic, why does portage insist on writing to a random existing file in package.use? Wouldn't a new file be much cleaner?)
Anyway, my question is why its not possible to set abi_x86_32 for, say, app-emulation/wine and the dependencies' flags get enabled as needed? Is that not possible? Not desirable? Or has noone gotten around to implementing it?
Back to top
View user's profile Send private message
fedeliallalinea
Bodhisattva
Bodhisattva


Joined: 08 Mar 2003
Posts: 22485
Location: here

PostPosted: Thu May 02, 2019 11:52 am    Post subject: Re: Why do use-flag dependencies require so much manual hand Reply with quote

Dr.Willy wrote:
(On that topic, why does portage insist on writing to a random existing file in package.use? Wouldn't a new file be much cleaner?)

It isn't random, emerge put these entries in last file ordered alphabetically. You can create file zzz and emerge will put always the entries in it.
_________________
Questions are guaranteed in life; Answers aren't.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7195

PostPosted: Thu May 02, 2019 12:12 pm    Post subject: Reply with quote

Dr. Willy wrote:
Anyway, my question is why its not possible to set abi_x86_32 for, say, app-emulation/wine and the dependencies' flags get enabled as needed? Is that not possible? Not desirable?


Because you only think of your case, where you assume, i want useflag "X" with pkgZ, and make all deps of pkgZ also built with "X" set.
It's not wanted, it's not because i will use pkgZ with "X" that i want portage to force "X" on all its deps. "X" is an useflag, which is an option on a package, it's not because i want the option for pckZ that i will want it on every package i own.

You can actually get the list of packages directly from portage, you can temporary but globally set your changes and get the list of what will be change with --pretend.
here's an output of my system times ago when i was looking at wine and 32bits too.
https://paste.pound-python.org/show/J62xOEzMzf3wV0GhL1SE/
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4313
Location: Dallas area

PostPosted: Thu May 02, 2019 12:23 pm    Post subject: Reply with quote

krinn wrote:
Dr. Willy wrote:
Anyway, my question is why its not possible to set abi_x86_32 for, say, app-emulation/wine and the dependencies' flags get enabled as needed? Is that not possible? Not desirable?


Because you only think of your case, where you assume, i want useflag "X" with pkgZ, and make all deps of pkgZ also built with "X" set.


In some cases it would be a nice thing, some variable being set that says "all wine dependencies get abi_x86_32 set" I could see a use for.
I wouldn't make it a hard and fast rule for all packages, all use flags.

I remember when I was messing with wine and it was a god-awful pain to get all the dependencies set properly, mostly because it took many repeated emerges to finally get through it. An alternative would be for emerge to not barf at the first dependency but list all those needed by wine (for example).
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 500
Location: NRW, Germany

PostPosted: Thu May 02, 2019 12:28 pm    Post subject: Reply with quote

fedeliallalinea wrote:
Dr.Willy wrote:
(On that topic, why does portage insist on writing to a random existing file in package.use? Wouldn't a new file be much cleaner?)

It isn't random, emerge put these entries in last file ordered alphabetically. You can create file zzz and emerge will put always the entries in it.

That's … weird, but useful.

krinn wrote:
Because you only think of your case, where you assume, i want useflag "X" with pkgZ, and make all deps of pkgZ also built with "X" set.
It's not wanted, it's not because i will use pkgZ with "X" that i want portage to force "X" on all its deps. "X" is an useflag, which is an option on a package, it's not because i want the option for pckZ that i will want it on every package i own.

That is not the case I'm talking about here, krinn. I want flag U on pkg/foo. pkg/foo depends on pkg/bar[U]. Therefore U should be enabled for pkg/bar automatically, because pkg/foo depends on bar with U enabled.
I don't mean to enable U on all deps, but on the ones where U is a requirement (and not an option).
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7195

PostPosted: Thu May 02, 2019 12:57 pm    Post subject: Reply with quote

Dr.Willy wrote:
That is not the case I'm talking about here, krinn. I want flag U on pkg/foo. pkg/foo depends on pkg/bar[U]. Therefore U should be enabled for pkg/bar automatically, because pkg/foo depends on bar with U enabled.

I see what you speak about, still you assume [U] that is a "safe" option on pkg/foo must be a safe option also on pkg/bar
but what if pkg/bar is [U]? systemd ; you'll be happy portage install systemd because portage assume it's ok to set [U] on pkg/bar
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 500
Location: NRW, Germany

PostPosted: Thu May 02, 2019 7:53 pm    Post subject: Reply with quote

krinn wrote:
Dr.Willy wrote:
That is not the case I'm talking about here, krinn. I want flag U on pkg/foo. pkg/foo depends on pkg/bar[U]. Therefore U should be enabled for pkg/bar automatically, because pkg/foo depends on bar with U enabled.

I see what you speak about, still you assume [U] that is a "safe" option on pkg/foo must be a safe option also on pkg/bar
but what if pkg/bar is [U]? systemd ; you'll be happy portage install systemd because portage assume it's ok to set [U] on pkg/bar

How is this different from regular dependency behaviour? If foo depends on bar, then installing foo installs bar. I'm not sure what point you're trying to make here.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14289

PostPosted: Fri May 03, 2019 1:47 am    Post subject: Reply with quote

The point is that sometimes cascading changes are the wrong solution. Maybe you will choose to abandon the change because it is too invasive. Maybe you will choose to disable some features in a supporting package, to cut the dependency tree short. When they are the right solution, the right way to do them is for Portage to propose all of them in a single step, let autounmask write them all, and then you proceed. Automatically flipping flags based on the the presence of other packages is bad, because you might remove the consuming package, then Portage would decide to rebuild the consumed package with different options.
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 500
Location: NRW, Germany

PostPosted: Fri May 03, 2019 8:12 am    Post subject: Reply with quote

Hu wrote:
The point is that sometimes cascading changes are the wrong solution.
Yes, sometimes.

Hu wrote:
Maybe you will choose to abandon the change because it is too invasive. Maybe you will choose to disable some features in a supporting package, to cut the dependency tree short. When they are the right solution, the right way to do them is for Portage to propose all of them in a single step, let autounmask write them all, and then you proceed.

Yes, maybe a change is too invasive. Yes, maybe you want to disable features in a supporting package. But your 'right way' does not follow from those points.
Portage has a --pretend flag and the workflow would be the same as when you realize that a package you want to install depends on kde-meta.

Hu wrote:
Automatically flipping flags based on the the presence of other packages is bad, because you might remove the consuming package, then Portage would decide to rebuild the consumed package with different options.

And this is bad, because, … ? If you actually care about having certain options on consumed-package you should add them to your package.use.
The analogy I made earlier is the worlds file. It should only contain the packages you actually care about and not all packages with all their dependencies.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14289

PostPosted: Sat May 04, 2019 12:49 am    Post subject: Reply with quote

Dr.Willy wrote:
And this is bad, because, … ? If you actually care about having certain options on consumed-package you should add them to your package.use.
Exactly. The current scheme requires you to do exactly that. I understood the earlier posts to be a request for a feature where Portage would look at what packages were requested and automatically begin pretending package.use had certain changes, for so long as those other packages were installed. When those packages were removed, Portage would stop pretending, and would then want to rebuild. Here, by requiring the user to express their intent in package.use, that intent remains in effect regardless of subsequent removals.
Back to top
View user's profile Send private message
berferd
Tux's lil' helper
Tux's lil' helper


Joined: 13 May 2004
Posts: 117

PostPosted: Sat May 04, 2019 4:24 am    Post subject: Reply with quote

krinn wrote:
I see what you speak about, still you assume [U] that is a "safe" option on pkg/foo must be a safe option also on pkg/bar
but what if pkg/bar is [U]? systemd ; you'll be happy portage install systemd because portage assume it's ok to set [U] on pkg/bar


That depends on whether the systemd use flag is on by default for pkg/bar, and whether systemd is enabled or disabled system-wide. If the flag is enabled by default and not disabled globally, the package should install with its systemd dependencies. Otherwise, it should ask the user, which is what's happening to Dr. Willy. This is the correct behavior and makes sense for all flags except maybe for abi_x86_32.

The problem with enabling abi_x86_32 system-wide is you'll spend a lot of time compiling useless 32-bit versions of Firefox and the like. It can't be enabled by default in most packages for the same reason. You could go and come up with a list of libraries that are often used by 32-bit systems and enable abi_x86_32 on them by default, but then you'd annoy the people who want to have a clean 64-bit system and don't care at all about 32-bit compatibility.

It seems to me that the abi_x86_32 use flag is a special case where transitive use-flag enabling makes sense. I think adding that feature to portage would add a lot of complexity that is perhaps only useful for this one flag. Perhaps a middle ground could be a set of curated files you can drop into your /etc/portage/package.use for common 32-bit uses. In that spirit, here's the one I came up with for Steam on a Funtoo system:

Code:
dev-libs/libpthread-stubs abi_x86_32
virtual/opengl abi_x86_32
x11-libs/libX11 abi_x86_32
x11-libs/libXau abi_x86_32
x11-libs/libXdmcp abi_x86_32
x11-libs/libXext abi_x86_32
x11-libs/libxcb abi_x86_32
x11-proto/inputproto abi_x86_32
x11-proto/kbproto abi_x86_32
x11-proto/xcb-proto abi_x86_32
x11-proto/xextproto abi_x86_32
x11-proto/xf86bigfontproto abi_x86_32
x11-proto/xproto abi_x86_32
#
x11-proto/dri2proto abi_x86_32
x11-proto/xf86vidmodeproto abi_x86_32
x11-libs/libva abi_x86_32
x11-libs/libxshmfence abi_x86_32
virtual/libiconv abi_x86_32
sys-apps/attr abi_x86_32
sys-libs/zlib abi_x86_32
x11-proto/glproto abi_x86_32
#
virtual/libffi abi_x86_32
x11-libs/libva-vdpau-driver abi_x86_32
x11-libs/libXxf86vm abi_x86_32
x11-proto/presentproto abi_x86_32
x11-proto/dri3proto abi_x86_32
media-libs/mesa abi_x86_32
x11-libs/libXvMC abi_x86_32
x11-libs/libXv abi_x86_32
x11-proto/xf86driproto abi_x86_32
dev-libs/libffi abi_x86_32
x11-proto/videoproto abi_x86_32
#
x11-libs/libXfixes abi_x86_32
x11-libs/libvdpau abi_x86_32
dev-libs/glib abi_x86_32
x11-libs/libXdamage abi_x86_32
x11-proto/damageproto abi_x86_32
dev-libs/expat abi_x86_32
sys-libs/ncurses abi_x86_32
sys-fs/eudev abi_x86_32
sys-libs/libudev-compat abi_x86_32
x11-libs/libdrm abi_x86_32
x11-proto/fixesproto abi_x86_32
#
x11-libs/libXcursor abi_x86_32
x11-libs/libXtst abi_x86_32
x11-libs/gtk+:2 abi_x86_32
dev-libs/atk abi_x86_32
x11-proto/recordproto abi_x86_32
x11-libs/libXcomposite abi_x86_32
x11-proto/compositeproto abi_x86_32
x11-libs/libSM abi_x86_32
sys-apps/util-linux abi_x86_32
x11-libs/libICE abi_x86_32
media-libs/alsa-lib abi_x86_32
media-sound/apulse abi_x86_32
media-libs/openal abi_x86_32
media-libs/libsdl2 abi_x86_32
x11-libs/libXt abi_x86_32
x11-proto/scrnsaverproto abi_x86_32
x11-libs/libXScrnSaver abi_x86_32
media-libs/libogg abi_x86_32
media-libs/flac abi_x86_32
media-libs/audiofile abi_x86_32
dev-libs/nss abi_x86_32
dev-libs/nspr abi_x86_32
gnome-base/gconf abi_x86_32
sys-apps/dbus abi_x86_32
dev-libs/dbus-glib abi_x86_32
net-print/cups abi_x86_32
app-text/ghostscript-gpl cups
virtual/libusb:1 abi_x86_32
dev-libs/libusb abi_x86_32
#
dev-libs/libtasn1 abi_x86_32
net-nds/openldap abi_x86_32
dev-libs/nettle abi_x86_32
dev-libs/libgpg-error abi_x86_32
dev-libs/gmp abi_x86_32
virtual/libintl abi_x86_32
dev-libs/libgcrypt abi_x86_32
net-libs/gnutls abi_x86_32
net-misc/curl abi_x86_32
#
sys-devel/llvm abi_x86_32
sys-auth/consolekit policykit
#
dev-db/sqlite abi_x86_32
sys-libs/readline abi_x86_32
dev-libs/icu abi_x86_32
#
dev-libs/openssl abi_x86_32
net-misc/networkmanager abi_x86_32 dhcpcd -gnutls -dhclient -modemmanager -ppp -resolvconf -wext -wifi
virtual/libgudev abi_x86_32
dev-libs/libgudev abi_x86_32
sys-libs/pam abi_x86_32
sys-devel/flex abi_x86_32
sys-libs/cracklib abi_x86_32
sys-libs/db abi_x86_32
sys-auth/nss-pam-ldapd abi_x86_32
#
# required by dev-libs/cyrus-sasl[pam]
# required by sys-auth/nss-pam-ldapd[sasl]
virtual/pam abi_x86_32
# required by sys-auth/nss-pam-ldapd[sasl]
dev-libs/cyrus-sasl abi_x86_32
#
# required by net-libs/gnutls-3.5.12::gentoo[idn]
# required by net-libs/glib-networking-2.46.1::gentoo[ssl]
net-dns/libidn2 abi_x86_32
# required by net-libs/gnutls-3.5.12::gentoo
# required by net-libs/glib-networking-2.46.1::gentoo[ssl]
dev-libs/libunistring abi_x86_32
# TF2 won't start without this
net-libs/libcurl-debian abi_x86_32
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 500
Location: NRW, Germany

PostPosted: Sat May 04, 2019 6:55 am    Post subject: Reply with quote

Hu wrote:
Dr.Willy wrote:
And this is bad, because, … ? If you actually care about having certain options on consumed-package you should add them to your package.use.
Exactly. The current scheme requires you to do exactly that. I understood the earlier posts to be a request for a feature where Portage would look at what packages were requested and automatically begin pretending package.use had certain changes, for so long as those other packages were installed. When those packages were removed, Portage would stop pretending, and would then want to rebuild. Here, by requiring the user to express their intent in package.use, that intent remains in effect regardless of subsequent removals.

Yes. (I think?)

cat/foo:
Code:
IUSE=""
DEPEND="cat/bar[xyz]"

cat/bar:
Code:
IUSE="xyz"
...

Now you (the user) want to install cat/foo. In order to do so you have to add
Code:
cat/bar xyz
to your package.use. I argue portage should automatically consider xyz enabled for cat/bar, since cat/foo depends on it.
If you (the user) want to have xyz enabled for cat/bar, regardless of whether cat/foo is installed or not, then and only then it should be added to package.use.
That was my proposal for ABI_X86 and I was wondering if it would make sense in the general case.
Back to top
View user's profile Send private message
berferd
Tux's lil' helper
Tux's lil' helper


Joined: 13 May 2004
Posts: 117

PostPosted: Sat May 04, 2019 4:09 pm    Post subject: Reply with quote

Dr.Willy wrote:
cat/bar:
Code:
IUSE="xyz"
...

Now you (the user) want to install cat/foo. In order to do so you have to add
Code:
cat/bar xyz
to your package.use. I argue portage should automatically consider xyz enabled for cat/bar, since cat/foo depends on it.


Unless your make.conf has "-xyz" in it. Emerge should and does ask you whether you want to enable it for that one specific package in that case.

You can achieve what you want by setting ABI_X86="32" in your make.conf, but that will enable abi_x86_32 for everything in your system. This is why that flag is disabled by default in 64-bit profiles.

Like I said, you can't achieve what you want, selective transitive enabling of use flags, within the current semantics of portage. Creating that feature just for your use case is way too much work, and adds a whole lot of complexity for just one use case.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14289

PostPosted: Sat May 04, 2019 4:54 pm    Post subject: Reply with quote

OK, so we agree on what you want Portage to do. I think it would be wrong for it to do that, and that letting autounmask suggest the change is as far as it should go. I think the user should be given the opportunity to explicitly confirm the change, in the form of the autounmask event. You think it should go farther.
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 7328
Location: Saint Amant, Acadiana

PostPosted: Sat May 04, 2019 5:00 pm    Post subject: Reply with quote

Gee, I thought Gentoo is "manual" distro? I hear there are much cozier Linux distros, you will get everything and the only price you pay is bloat.
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4313
Location: Dallas area

PostPosted: Sat May 04, 2019 5:09 pm    Post subject: Reply with quote

Hu wrote:
the right way to do them is for Portage to propose all of them in a single step, let autounmask write them all, and then you proceed.


I wonder how much trouble it would be for this to happen vs the way it does now (emerge, complain about one package, rinse, lather, repeat)
It could be tied into the pretend option, ignore failure by keeping track of it, then proceed to the next package to see if suitable or needs use flag modification, till it reaches the end, then output all potential changes needed.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
berferd
Tux's lil' helper
Tux's lil' helper


Joined: 13 May 2004
Posts: 117

PostPosted: Sat May 04, 2019 6:26 pm    Post subject: Reply with quote

Hu wrote:
OK, so we agree on what you want Portage to do. I think it would be wrong for it to do that, and that letting autounmask suggest the change is as far as it should go. I think the user should be given the opportunity to explicitly confirm the change, in the form of the autounmask event. You think it should go farther.


Yes, and I think this was Krinn's point all along.
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 500
Location: NRW, Germany

PostPosted: Sat May 04, 2019 7:22 pm    Post subject: Reply with quote

Hu wrote:
OK, so we agree on what you want Portage to do.
Good :-)
Hu wrote:
think it would be wrong for it to do that, and that letting autounmask suggest the change is as far as it should go. I think the user should be given the opportunity to explicitly confirm the change, in the form of the autounmask event.

Why?
My rationale is the analogy to the worlds file, which only contains the packages the user cares about, not their dependencies. package.use however must contain the useflags the user wants to set for his system AND the flags that are required due to use dependency relations.
This surfaced, when I set abi_x86_32 for wine and then mindlessly had to add entries to my packages.use until portage stopped finally complaining.
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 500
Location: NRW, Germany

PostPosted: Sat May 04, 2019 7:26 pm    Post subject: Reply with quote

berferd wrote:
Yes, and I think this was Krinn's point all along.

No, what he argued was that adding xyz to cat/foo should not enable xyz for all of cat/foo's dependencies, regadless of there being a dependency on that useflag being enabled.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7176
Location: Austria

PostPosted: Sat May 04, 2019 10:30 pm    Post subject: Reply with quote

Dr.Willy wrote:
This surfaced, when I set abi_x86_32 for wine and then mindlessly had to add entries to my packages.use until portage stopped finally complaining.

--autounmask=y works pretty good for that purpose (and for that alone) though, it didn't take me more than one `emerge -p wine` to create a dedicated package.use file.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4313
Location: Dallas area

PostPosted: Sat May 04, 2019 11:41 pm    Post subject: Reply with quote

asturm wrote:
Dr.Willy wrote:
This surfaced, when I set abi_x86_32 for wine and then mindlessly had to add entries to my packages.use until portage stopped finally complaining.

--autounmask=y works pretty good for that purpose (and for that alone) though, it didn't take me more than one `emerge -p wine` to create a dedicated package.use file.


I didn't realize that autounmask worked that way, a reasonable approach for finding all abi_x86_32 settings for wine.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7195

PostPosted: Sun May 05, 2019 12:17 pm    Post subject: Reply with quote

Dr.Willy wrote:
berferd wrote:
Yes, and I think this was Krinn's point all along.

No, what he argued was that adding xyz to cat/foo should not enable xyz for all of cat/foo's dependencies, regadless of there being a dependency on that useflag being enabled.

You do realise too that such an "auto guess what user think" would still be a failure anyway, and that because of the feature, portage would also introduce the feature "ok dude, you ask me anything, come back next week for your answer"?
If for you portage is fast enough, glad for you, for me, i think portage has done already bad with autounmask, preserved-libs... speaking of time lost/benefits taken.
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 500
Location: NRW, Germany

PostPosted: Mon May 06, 2019 7:54 am    Post subject: Reply with quote

krinn wrote:
You do realise too that such an "auto guess what user think" would still be a failure anyway, […]

I don't know why you keep bringing this up, but you're resolving dependencies. There is no guessing involved.

Also yes, I do understand dependency resolution is NP-hard.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
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