[gentoo-dev] Re: RFC: changing the developer profile: FEATURES="test" -> FEATURES="test-fail-continue"
On Mon, 7 Jun 2010 14:02:50 +0200 Jeroen Roovers wrote: > I see more and more calls for either 1) "fixing the test suite", as if > that is suddenly not an UPSTREAM issue but the ebuilds' maintainers' > When instead a test suite should do a SKIP but erroneously does a FAIL, > then RESTRICT=test is not the solution. Fixing the test suite is, but > then that's not the maintainer's problem, but upstream's. Oddly enough > we have QA checks in place (for ICEs, for instance) that direct users > directly to upstream (through the HOMEPAGE variable), when it's > suddenly the maintainer's problem if a package fails its test suite > (because of FEATURES=userpriv or a missing kernel feature, perhaps - > nothing the maintainer can prepare the user's system for). I'm having trouble understanding how you can say fixing build failures is part of a maintainer's duties while fixing test failures is upstream's problem. A test failure _is_ a build failure. Yes, we should get it fixed upstream, just like any other bug. Packages can fail to compile with userpriv or missing kernel features too. Should we also send users directly to upstream in these cases? Can you explain the difference? I agree fully with all your other points. -- fonts, there's a hole in my neighbourhood gcc-porting, down which of late i cannot help but fall wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
I guess I should have done a proper grep on the tree before my first message. I missed a few more that are now up for grabs: media-sound/ncmpcpp - tanderson?, sound herd app-text/convertlit app-admin/makepasswd app-backup/rsnapshot - proxy maintainer needs new contact app-cdr/recorder - media-optical herd app-laptop/lenovo-sl-laptop dev-php5/symfony - proxy maintainer needs new contact media-sound/wavegain - sound herd net-misc/wput www-client/dillo - desktop-misc herd, but could use dedicated maintainer (also for fltk:2) x11-themes/pekwm-themes-hewphoria - proxy maintainer (same as for echinus) needs new contact (xarthisius?) Cheers, Ben
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
On Friday 11 of June 2010 21:26:06 Ben de Groot wrote: > On 11 June 2010 21:12, Ben de Groot wrote: > > As I'm retiring, the following packages I maintained need someone else > > to look after them: > > > > media-video/avidemux - video and qt herds (this one needs a version bump) > > media-video/smplayer - qt and video herds > > x11-themes/haematite-xcursors - desktop-misc herd > > x11-themes/obsidian-xcursors - ,, > > x11-themes/pearlgrey-xcursors - ,, > > x11-wm/openbox - hwoarang?, lxde herd, desktop-wm herd > > app-misc/vifm <-- this is now maintainer-needed! > > app-text/wgetpaste <-- this is now maintainer-needed! > > > > Also, my proxy-maintainers will need new contacts: > > x11-wm/echinus - anyone from desktop-wm still active? > > dev-php/roadsend-php - anyone from php? > > > > I hope I didn't forget anything. > > I forgot to add: > > app-text/poppler - reavertm?, now assigned to kde herd, and printing > herd which is basically dead Yeah, kde herd is on it. > app-text/poppler-data - assigned to dead printing herd and loki_val > who is on extended devaway We can also assimilate this one if needed. -- regards MM
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 11.06.2010 21:12, Ben de Groot pisze: > app-text/wgetpaste <-- this is now maintainer-needed! I would like to grab it > Also, my proxy-maintainers will need new contacts: > x11-wm/echinus - anyone from desktop-wm still active? Alive & kicking, we'll gladly proxy it for Nico Best regards, Kacper Kowalik -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAkwSjfIACgkQIiMqcbOVdxSR+AP7Bo5GPnHwjBKjnmbZVRp0BM6t 1cIT5YwvRQ9CmJjf9Zd5wNLNAOgPSgTRcbL4jJcWDvo9zk3KizCzh36wVg2LVlw1 y59oJcbR1x2WOmHbHhBHk5eQH1Dq/WW+nOs7JMF6bAL58SKXQwDaDW+jbLQM4u51 tQ/AbrwY+fqx4acnx9o= =t2Ne -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
On 11 June 2010 21:12, Ben de Groot wrote: > As I'm retiring, the following packages I maintained need someone else > to look after them: > > media-video/avidemux - video and qt herds (this one needs a version bump) > media-video/smplayer - qt and video herds > x11-themes/haematite-xcursors - desktop-misc herd > x11-themes/obsidian-xcursors - ,, > x11-themes/pearlgrey-xcursors - ,, > x11-wm/openbox - hwoarang?, lxde herd, desktop-wm herd > app-misc/vifm <-- this is now maintainer-needed! > app-text/wgetpaste <-- this is now maintainer-needed! > > Also, my proxy-maintainers will need new contacts: > x11-wm/echinus - anyone from desktop-wm still active? > dev-php/roadsend-php - anyone from php? > > I hope I didn't forget anything. I forgot to add: app-text/poppler - reavertm?, now assigned to kde herd, and printing herd which is basically dead app-text/poppler-data - assigned to dead printing herd and loki_val who is on extended devaway dev-python/python-poppler - taken over by python herd Cheers, Ben
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
As I'm retiring, the following packages I maintained need someone else to look after them: media-video/avidemux - video and qt herds (this one needs a version bump) media-video/smplayer - qt and video herds x11-themes/haematite-xcursors - desktop-misc herd x11-themes/obsidian-xcursors - ,, x11-themes/pearlgrey-xcursors - ,, x11-wm/openbox - hwoarang?, lxde herd, desktop-wm herd app-misc/vifm <-- this is now maintainer-needed! app-text/wgetpaste <-- this is now maintainer-needed! Also, my proxy-maintainers will need new contacts: x11-wm/echinus - anyone from desktop-wm still active? dev-php/roadsend-php - anyone from php? I hope I didn't forget anything. Cheers, Ben
[gentoo-dev] Lastrite: net-wireless/bluez-{libs,utils}
# Pacho Ramos (11 Jun 2010) # Drop old and deprecated bluez-libs and bluez-utils. Use bluez instead. # Masked for removal in 30 days. # See bug 301630. net-wireless/bluez-libs net-wireless/bluez-utils And really thanks a lot to Samuli for taking care of the hard work (cleaning deps). signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Suggestion related with dropping keywords policy
> > Hello > > Let my explain the problem and my suggestion to handle it better (at > least from my point of view) with an example: > > Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that > bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added. > Since libcap-ng was not keyworded in all arches but x86 and amd64, I had > to drop keywords for bluez and open > http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it. > > From my point of view, I would prefer to: > 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to > keep bluez keyworded. > 2. Open two bug reports as done with current policy: one for keywording > libcap-ng and other to check bluez works ok with it asking arch team to > unmask that USE flag if possible. > > This way to go would have the advantage of letting people running bluez > on affected arches to still get the latest bluez version instead of > still having to run a pretty old (and buggy) one. > > Thanks for considering it > Your preferred method is exactly how (as a ppc keyworder) I like to see these kind of bugs handled. Dropping keywords makes an awful lot more work for us and hurts our users, especially since we're not always very prompt at handling bugs. Thanks for bringing this up on the mailing list! -Joe
[gentoo-dev] Lastrite: gnome-extra/gnome-vfs-obexftp
# Samuli Suominen (11 Jun 2010) # Only used by old bluez-libs and bluez-utils. # Masked for removal in 30 days. # See bug 301630. gnome-extra/gnome-vfs-obexftp
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
On 11.6.2010 12.32, Thilo Bangert wrote: >> This thread belongs to gentoo-project. > > perhaps its time to reduce the number of mailinglists again. IMHO it > doesnt hurt to have this thread on gentoo-dev and the volume of messages > and their tone here has been sufficiently normal to again allow for more > subjects. > > just my 2 cents > kind regards > Thilo Sure but doing that should be done by opening a new thread and gathering opinions. Until then we should follow the agreed rules. Regards, Petteri
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
On Friday 11 June 2010 10:48:36 Maciej Mrozowski wrote: > I'm all for moving to LDAP every info that fits and it's possible. Maybe > even things like Gentoo overlays access. That's not possible, as it is not an attribute that the developer himself should touch, but the overlays team only. Furthermore, access to overlays is granted to non-developers as well, so either way it isn't easier for us -- Theo Chatzimichos (tampakrap) Gentoo KDE, Qt, SGML, Overlays, Planet Teams blog.tampakrap.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion related with dropping keywords policy
Pacho Ramos said: > Hello > > Let my explain the problem and my suggestion to handle it better (at > least from my point of view) with an example: > > Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that > bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added. > Since libcap-ng was not keyworded in all arches but x86 and amd64, I > had to drop keywords for bluez and open > http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it. > > From my point of view, I would prefer to: > 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to > keep bluez keyworded. > 2. Open two bug reports as done with current policy: one for keywording > libcap-ng and other to check bluez works ok with it asking arch team to > unmask that USE flag if possible. > > This way to go would have the advantage of letting people running bluez > on affected arches to still get the latest bluez version instead of > still having to run a pretty old (and buggy) one. it seems to depend on turnaround time. if arch teams respond quickly, then the USE flag masking would just be an increase in workload. if they are slow to respond then that may be a good investment. given that one cant dictate the speed at which arch teams work, your proposal sounds very sensible. I am OK with both methods. kind regards Thilo > > Thanks for considering it signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
> This thread belongs to gentoo-project. perhaps its time to reduce the number of mailinglists again. IMHO it doesnt hurt to have this thread on gentoo-dev and the volume of messages and their tone here has been sufficiently normal to again allow for more subjects. just my 2 cents kind regards Thilo signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Suggestion related with dropping keywords policy
Hello Let my explain the problem and my suggestion to handle it better (at least from my point of view) with an example: Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added. Since libcap-ng was not keyworded in all arches but x86 and amd64, I had to drop keywords for bluez and open http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it. From my point of view, I would prefer to: 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to keep bluez keyworded. 2. Open two bug reports as done with current policy: one for keywording libcap-ng and other to check bluez works ok with it asking arch team to unmask that USE flag if possible. This way to go would have the advantage of letting people running bluez on affected arches to still get the latest bluez version instead of still having to run a pretty old (and buggy) one. Thanks for considering it signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
On 11.6.2010 6.27, Robin H. Johnson wrote: > On Thu, Jun 10, 2010 at 07:07:53PM +0200, Pacho Ramos wrote: >> Currently, we only need to set a proper message in ~/.away (as talked in >> http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml ) when >> becoming "devaway". > Related to integration of that, I would like opinions on moving some > data from developer home directories into LDAP. I already placed the SPF > data straight into LDAP, since I needed to be able to reach it from > another machine anyway. > This thread belongs to gentoo-project. Regards, Petteri
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild
On Thursday 10 June 2010 23:45:29 Arfrever Frehtes Taifersar Arahesis wrote: [...] > This commit only removed some compiler warnings. This adds a cflag preventing the compiler to make some assumptions on the code for its optimisations, hence making the code slower/bigger. While the changelog entry will help figuring out why this was added, a comment in the ebuild explaining why will be even better. Once you'll have to dig into 4 years of cvs log to figure out wth a cflag filtering/addition was added into an ebuild maybe you'll reconsider your opinion. Please always keep in mind that you're not the only one that will ever commit to $package and even less the only one that will have a look at a given ebuild. A. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
В Птн, 11/06/2010 в 09:48 +0200, Maciej Mrozowski пишет: > On Friday 11 of June 2010 09:24:45 Peter Volkov wrote: > > В Чтв, 10/06/2010 в 23:42 -0700, Alec Warner пишет: > > > > I don't agree with that, but just out of curiosity, is it possible to > > > > use a web interface? phpldapadmin or something > > > > > > The problem with phpldapadmin is that it potentially opens up LDAP to > > > the world. > > > > Require everybody to forward connection through ssh to get ldap web > > interface? It's not hard to setup such tunnel manually or e.g. use > > xinetd for automatic tunnel creation on request... Another option is to > > use https with ssl client side certificates). I think it's not hard for > > developers to generate certificates on dev.gentoo.org and import them > > into browsers. > > I suppose simply making LDAP globally available (SSL only) is asking for > trouble. In such case anyway one could choose his/her favourite LDAP client. I'm talking about _web_ interface with required _ssl client authentification_. I guess it is as secure as ssh. -- Peter.
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
On Friday 11 of June 2010 09:24:45 Peter Volkov wrote: > В Чтв, 10/06/2010 в 23:42 -0700, Alec Warner пишет: > > > I don't agree with that, but just out of curiosity, is it possible to > > > use a web interface? phpldapadmin or something > > > > The problem with phpldapadmin is that it potentially opens up LDAP to > > the world. > > Require everybody to forward connection through ssh to get ldap web > interface? It's not hard to setup such tunnel manually or e.g. use > xinetd for automatic tunnel creation on request... Another option is to > use https with ssl client side certificates). I think it's not hard for > developers to generate certificates on dev.gentoo.org and import them > into browsers. I suppose simply making LDAP globally available (SSL only) is asking for trouble. In such case anyway one could choose his/her favourite LDAP client. Anyway I think simple shell scripts for most common activities (devaway, change etc) would do. I'm all for moving to LDAP every info that fits and it's possible. Maybe even things like Gentoo overlays access. -- regards MM
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
В Чтв, 10/06/2010 в 23:42 -0700, Alec Warner пишет: > > I don't agree with that, but just out of curiosity, is it possible to use a > > web interface? phpldapadmin or something > > The problem with phpldapadmin is that it potentially opens up LDAP to > the world. Require everybody to forward connection through ssh to get ldap web interface? It's not hard to setup such tunnel manually or e.g. use xinetd for automatic tunnel creation on request... Another option is to use https with ssl client side certificates). I think it's not hard for developers to generate certificates on dev.gentoo.org and import them into browsers. > >> Bonus plans: > >> - Maybe move mail aliases to LDAP? We'd lose comments :-(. > > Not if you added a comments field ;) +1. Comments are useful (e.g. for non @gentoo.org mail addresses) and btw, it's good idea if willikins will show them too. -- Peter.
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
On Fri, Jun 11, 2010 at 08:58, "Paweł Hajdan, Jr." wrote: >> Cons: >> - developers get changes to LDAP wrong already. >> = I counter that they ALSO change the wrong filenames and wonder why >> there is no effect. I counted a large number of '.permissave', >> '.devaway' and '.asmtppasswd' files. Couldn't we just have a script that opens the devAway from my LDAP entry in my EDITOR and writes it when I save & close? Cheers, Dirkjan
