[gentoo-dev] bugs.gentoo.org status report, 2009/03/19 10h00 UTC
The primary Bugzilla webserver is now back in operation. Additionally, for the moment, I've re-enabled the load-balancing, but note that it comes with a warning... Load balanced bugzilla webservers: http://bugs-web-lb.gentoo.org/ (HTTPS supported as well, but the SSL certificate won't match). Visiting either specific side of the webserver nodes: http://bugs-web1.gentoo.org/ http://bugs-web2.gentoo.org/ (The web node you're on is listed on the frontpage only). Caveat: - Why can't we just always use the load-balancer? Unfortunately bugzilla writes a number of files to the local disk and then gives you a URL to them. If the file was written to disk on web1, but your request was delivered to web2, then you would get a 404 error. - What pages are most affected by this? The major ones I know about so far are the graph outputs from reports, and the bug dependency graphs (which are disabled at the moment due to the recent abuse). If you're using the load-balanced version of the site, and you get a 404, please file a bug to bugzilla@ -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpkRinVVZefk.pgp Description: PGP signature
Re: [gentoo-dev] Make the policykit USE flag global
Hi, On Wednesday 18 March 2009 13:12:45 Olivier Crête wrote: Hello, use.local.desc:app-admin/gnome-system-tools:policykit - Use sys-auth/policykit to gain privileges to change configuration files use.local.desc:app-admin/system-tools-backends:policykit - Use sys-auth/policykit to gain privileges to change configuration files use.local.desc:gnome-extra/gnome-lirc-properties:policykit - Use sys-auth/policykit to gain privileges to change configuration files use.local.desc:gnome-extra/gnome-power-manager:policykit - Enable sys-auth/policykit authentication support use.local.desc:media-sound/pulseaudio:policykit - Enable support for PolicyKit framework. use.local.desc:sys-auth/consolekit:policykit - Use the PolicyKit framework (sys-auth/policykit) to get authorization for suspend/shutdown. Feel the trend? gnome-base/gnome-panel will follow soon. Lets make this global. Unless we decide that PolicyKit is the future and make it compulsory). If no one complains, I will make the changes in a couple days. I think it would be also good idea to add policykit support and finally unmask it. It seems some packages have hardcoded --without-policy-kit / --without- policykit and some others add policykit to package.use.mask (btw can it be unmasked by user from portage level??). I've been playing with policykit for a while now and never had any real problems with it. I would gladly help to support it by default. Thanks, Rob signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Make the policykit USE flag global
Le 19/03/2009 15:23, Robert Piasek a écrit : Feel the trend? gnome-base/gnome-panel will follow soon. Lets make this global. Unless we decide that PolicyKit is the future and make it compulsory). If no one complains, I will make the changes in a couple days. That seems reasonable. ACK from me. I think it would be also good idea to add policykit support and finally unmask it. It seems some packages have hardcoded --without-policy-kit / --without- policykit and some others add policykit to package.use.mask (btw can it be unmasked by user from portage level??). I've been playing with policykit for a while now and never had any real problems with it. I would gladly help to support it by default. It's unfortunately not that simple. Some applications require very little from PK (the clock applet from gnome-panel is one of those iirc). But some others (I'm looking at you, gnome-power-manager) just fail miserably if a specific policy file isn't installed. So for each package that uses PK, we need to come up with a default policy file that fits with Gentoo tradition. Bottom line, none of us took the time to do this because we just didn't have the time to take care of this. We could definitely use some help to figure out what to ship as reasonable defaults to our users. Cheers, Rémi
[gentoo-dev] Last rites: app-text/xetex, dev-tex/xkeyval, dev-tex/breqn
# Ulrich Mueller u...@gentoo.org (18 Mar 2009) # Depends on teTeX. Fails to build. # Newer version is included in app-text/texlive-core. # Masked for removal in 60 days, bug 227593. app-text/xetex # Ulrich Mueller u...@gentoo.org (18 Mar 2009) # Depends on teTeX. Newer version is included # in dev-texlive/texlive-latexrecommended. # Masked for removal in 60 days, bug 262897. dev-tex/xkeyval # Ulrich Mueller u...@gentoo.org (19 Mar 2009) # No longer maintained as a separate package, use dev-tex/mh instead. # Masked for removal in 30 days, bug 262934. dev-tex/breqn
Re: [gentoo-dev] Make the policykit USE flag global
On Thu, Mar 19, 2009 at 10:26 AM, Rémi Cardona r...@gentoo.org wrote: Le 19/03/2009 15:23, Robert Piasek a écrit : Feel the trend? gnome-base/gnome-panel will follow soon. Lets make this global. Unless we decide that PolicyKit is the future and make it compulsory). If no one complains, I will make the changes in a couple days. That seems reasonable. ACK from me. I think it would be also good idea to add policykit support and finally unmask it. It seems some packages have hardcoded --without-policy-kit / --without- policykit and some others add policykit to package.use.mask (btw can it be unmasked by user from portage level??). I've been playing with policykit for a while now and never had any real problems with it. I would gladly help to support it by default. It's unfortunately not that simple. Some applications require very little from PK (the clock applet from gnome-panel is one of those iirc). But some others (I'm looking at you, gnome-power-manager) just fail miserably if a specific policy file isn't installed. So for each package that uses PK, we need to come up with a default policy file that fits with Gentoo tradition. Bottom line, none of us took the time to do this because we just didn't have the time to take care of this. We could definitely use some help to figure out what to ship as reasonable defaults to our users. Cheers, Rémi The problem would be a simple fix if PolicyKit supported groups and we could just say give all access to those in the wheel group as a reasonable default. But alas, it does not. Arguably we can probably patch that in and just be done with it. Unless someone has some better ideas for a reasonable default. (IMHO, removing all of PolicyKit is a reasonable default but it looks like going forward GNOME is just using it without really any documentation or any forethought into the real world implications of PolicyKit and the inherent support/issues with ConsoleKit) -- Doug Goldstein
[gentoo-dev] Last rites for media-libs/libpano12
+# Markus Meier mae...@gentoo.org (19 Mar 2009) +# No longer needed, use media-libs/libpano13 +# Masked for removal in 30 days +media-libs/libpano12 + signature.asc Description: PGP signature
Re: [gentoo-dev] Make the policykit USE flag global
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Piasek wrote: I think it would be also good idea to add policykit support and finally unmask it. It seems some packages have hardcoded --without-policy-kit / --without- policykit and some others add policykit to package.use.mask (btw can it be unmasked by user from portage level??). You can unmask the flag globally like this: mkdir -p /etc/portage/profile/ echo -policykit /etc/portage/profile/use.mask Or, you can unmask it for a specific package like this: echo gnome-base/gnome-session -policykit /etc/portage/profile/package.use.mask - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknCmxAACgkQ/ejvha5XGaMQaACgp09qS5b0mnfYKioovsvyb2eS wXQAoIAKgSe/YPbGlLPFWvUogws2GOfq =5wNe -END PGP SIGNATURE-
Re: [gentoo-dev] Make the policykit USE flag global
Le 19/03/2009 19:12, Doug Goldstein a écrit : The problem would be a simple fix if PolicyKit supported groups and we could just say give all access to those in the wheel group as a reasonable default. But alas, it does not. Arguably we can probably patch that in and just be done with it. Actually, for a while, I had a policy file that returned allow to all auth requests. That was obviously not secure at all... For some reason, even _that_ didn't allow all apps to work properly, as they expect their own policy file and not just a default setting. It's as if GConf required schemas to be installed for apps to work. Unless someone has some better ideas for a reasonable default. The only way ATM is to go through the policy file for each applications, read it, make sense of it and adapt it to Gentoo... Again, the Gnome herd is quite short on manpower these days, even with the precious help of our latest recruits (Arun and Nirbheek). (IMHO, removing all of PolicyKit is a reasonable default but it looks like going forward GNOME is just using it without really any documentation or any forethought into the real world implications of PolicyKit and the inherent support/issues with ConsoleKit) I think we all agree here, Gilles, Mart and others have dutifully patched most (all?) core gnome components to at least build without PK, even if that means loosing some features. Thankfully, most of those patches have been accepted upstream. As for Gnome blindly using PK... again, we're all on the same page :) If anyone _really_ wants PK, please get in touch with us so we can try to support it in Portage. Thanks
[gentoo-dev] Re: Make the policykit USE flag global
Doug Goldstein car...@gentoo.org posted eafa4c130903191112t50cef619l1a2eeb8c45898...@mail.gmail.com, excerpted below, on Thu, 19 Mar 2009 13:12:15 -0500: Unless someone has some better ideas for a reasonable default. (IMHO, removing all of PolicyKit is a reasonable default but it looks like going forward GNOME is just using it without really any documentation or any forethought into the real world implications of PolicyKit and the inherent support/issues with ConsoleKit) Just asking, can the following be made to avoid #4 in the following sequence with policykit, now? It used to be a terrible issue with consolekit or whatever it was called. Or is that still one of the problems? 1. Boot to a VT. 2. Login at VT. 3. startx by sourcing a script that logs out of the VT after the startx, as that login is now unneeded. 4. Have sound and various other device permissions break as there's no active login, despite X and all its apps otherwise running normally. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Make the policykit USE flag global
Le jeudi 19 mars 2009 à 20:55 +, Duncan a écrit : Doug Goldstein car...@gentoo.org posted eafa4c130903191112t50cef619l1a2eeb8c45898...@mail.gmail.com, excerpted below, on Thu, 19 Mar 2009 13:12:15 -0500: Unless someone has some better ideas for a reasonable default. (IMHO, removing all of PolicyKit is a reasonable default but it looks like going forward GNOME is just using it without really any documentation or any forethought into the real world implications of PolicyKit and the inherent support/issues with ConsoleKit) Just asking, can the following be made to avoid #4 in the following sequence with policykit, now? It used to be a terrible issue with consolekit or whatever it was called. Or is that still one of the problems? 1. Boot to a VT. 2. Login at VT. 3. startx by sourcing a script that logs out of the VT after the startx, as that login is now unneeded. 4. Have sound and various other device permissions break as there's no active login, despite X and all its apps otherwise running normally. could you report a bug ? I've been discussing with diego about issues with where pam_ck_connector is placed in our pam stack having someone with a real problem with how things are today would probably help to iron out this once and for all. Also you might want to try consolekit-0.3 (and especially read the elog messages). -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
[gentoo-dev] Re: Make the policykit USE flag global
Gilles Dartiguelongue e...@gentoo.org posted 1237503483.7654.1.ca...@keitaro, excerpted below, on Thu, 19 Mar 2009 23:58:03 +0100: could you report a bug ? I've been discussing with diego about issues with where pam_ck_connector is placed in our pam stack having someone with a real problem with how things are today would probably help to iron out this once and for all. Also you might want to try consolekit-0.3 (and especially read the elog messages). Umm... not really. I think I got the name wrong (I did say or whatever it was called). I was thinking earlier, pam-console maybe? It's quite evident I'm rather confused by this consolekit stuff. It became a requirement for xorg somewhere along the line and I have it installed (the 0.3.0 version you mention), but I've not touched the configuration at all as I haven't the foggiest, except that I know that despite starting it as a service, xorg still complains about it in that brief half-second or so before it switches to the X VT... and it's scrolled out of the buffer by the usual assortment of KDE complaints long before I get back to it, and doesn't appear in the xorg log. Despite the complaint, X still works, certainly the reason I've not spent more time on it. There's probably some documentation about it somewhere, but while I make it a point to read the elog messages, either I've a blind spot in that regard (entirely possible), or there's been nothing pointing out what it's all about. I feel like this is a bit of an abuse of the devel list for user issues... anyway, feel free to mail me directly or take it to the desktop list, which is somewhat topical at least. Or just point me to some documentation, and I'll shut up and read it and post any questions to the desktop list or whatever when I'm done. But bringing it back to development and thus on topic, if I'm missing the documentation, I'm sure others are as well. Maybe that's what I should file a bug on? As should be evident by now, I'm rather confused on the topic... but I guess having it so publicly demonstrated keeps me humble. =:^) But if I'm confused and I spend quite some time on trying to keep up with such things, what about the poor user that doesn't have that time to spend? -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
