Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa darks...@gentoo.org wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: Index: metadata.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd; pkgmetadata herdno-herd/herd maintainer emailmaintainer-nee...@gentoo.org/email /maintainer /pkgmetadata Can this practice of adding m-n packages to gentoo-x86 be stopped? If you add it, take responsibility for it, please. If you don't want to take responsibility for it, at least find a team that is willing to look after it. If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Lastrite: luks-tools, pam_usb and thoggen
# Samuli Suominen ssuomi...@gentoo.org (27 Mar 2011) # Last packages with hardcoded sys-apps/hal depend. # Upstream has either stopped development, or it's too slow. # Bugs 313425, 358935 and finally 313389. # Removal in 30 days. app-crypt/luks-tools media-video/thoggen sys-auth/pam_usb
[gentoo-dev] Heads up: libjpeg-turbo stabilization, becoming the default
libjpeg-turbo stabilization is happening for amd64/x86 at http://bugs.gentoo.org/360715 - the gentoo-x86 has been converted to virtual/jpeg to support this. - we have no bugs reported against the package. - libjpeg-turbo is default in virtual/jpeg so just heads up.
[gentoo-dev] FYI: USE=hal masked in base/use.mask and related
USE=hal is masked in base/use.mask, but unmasked for kde-base/solid and app-cdr/k3b in base/package.use.mask pending on KDE 4.6.x stabilization. This is preparation for dropping the uncompressed usb.ids file from sys-apps/usbutils, which HAL relies on. Also, both udisks and upower now have blockers for sys-apps/hal to prevent overlapping features. -Samuli
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 01:17:46PM +0530, Nirbheek Chauhan wrote: On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa darks...@gentoo.org wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: Index: metadata.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd; pkgmetadata herdno-herd/herd maintainer emailmaintainer-nee...@gentoo.org/email /maintainer /pkgmetadata Can this practice of adding m-n packages to gentoo-x86 be stopped? If you add it, take responsibility for it, please. If you don't want to take responsibility for it, at least find a team that is willing to look after it. If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team Uhm no. The fact that nobody takes care of it doesn't necessarily mean that the package is broken and that it should be removed Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpMZ35rXvm0k.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 3:59 PM, Markos Chandras hwoar...@gentoo.org wrote: On Sun, Mar 27, 2011 at 01:17:46PM +0530, Nirbheek Chauhan wrote: On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa darks...@gentoo.org wrote: Can this practice of adding m-n packages to gentoo-x86 be stopped? If you add it, take responsibility for it, please. If you don't want to take responsibility for it, at least find a team that is willing to look after it. If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. Uhm no. The fact that nobody takes care of it doesn't necessarily mean that the package is broken and that it should be removed I never said that such packages were broken. I'm saying that if no one wants to maintain them, they probably aren't needed by anyone, and we should clean such cruft from the tree. If they *are* needed by someone, then those folks should come forward to maintain it. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] [warning] the bug queue has 104 bugs
Our bug queue has 104 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click one of the following links: http: http://bit.ly/bsHeJt https: http://bit.ly/8Z4xUU Thanks!
[gentoo-dev] developer profile, FEATURES=digest
FEATURES=digest results in a scary warning and a possibly dangerous re-generation of manifests at the beginning of every emerge: * The FEATURES=digest setting can prevent corruption from being noticed. * The `repoman manifest` command is the preferred way to generate * manifests and it is capable of doing an entire repository or category at * once. However, FEATURES=digest is enabled in the developer profile, and only in that profile: $ egrep '^FEATURES=.*digest' -r /usr/portage/profiles/ /usr/portage/profiles/targets/developer/make.defaults:FEATURES=collision-protect digest multilib-strict sign splitdebug stricter test test-fail-continue userpriv usersandbox I'd like to suggest removing digest from the line above. I've been running with the developer profile and -digest in /etc/make.conf, and everything is working fine. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How a new ARCH is added to Gentoo?
On Mon, Mar 21, 2011 at 4:14 PM, Mike Frysinger vap...@gentoo.org wrote: On Mon, Mar 21, 2011 at 8:28 AM, Kfir Lavi wrote: Is there any article that elaborate my question? My aim is to explain, why Gentoo is much more agile then any other binary distribution when hopping between arches. Lets say we started development on x86, then we want to move to another arch, or a totally new arch. I would like to know the process, lets say compared to Debian. https://bugs.gentoo.org/318251 -mike Hey Mike, thanks a lot for your document. It seems really easy to do this. (Well, after you know how to handle Catalyst ;-) I guess the wicking part and the compilation of packages will add some work. But it really seems simple. Thanks, Kfir
Re: [gentoo-dev] FYI: USE=hal masked in base/use.mask and related
Samuli Suominen schrieb: Also, both udisks and upower now have blockers for sys-apps/hal to prevent overlapping features. The result of this is that KDE and Gnome are now not installable at the same time on a stable system. Best regards, Chí-Thanh Christopher Nguyễn
Treeclean all maintainer-needed packages, was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Nirbheek Chauhan schrieb: I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. Uhm no. The fact that nobody takes care of it doesn't necessarily mean that the package is broken and that it should be removed I never said that such packages were broken. I'm saying that if no one wants to maintain them, they probably aren't needed by anyone, and we should clean such cruft from the tree. If they *are* needed by someone, then those folks should come forward to maintain it. The only such package I would like to see go is net-misc/mDNSResponder. And I am not convinced that having a maintainer listed in metadata.xml makes the package automatically non-cruft, or that orphaned packages are not at all cared about. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexadarks...@gentoo.org wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: Index: metadata.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd; pkgmetadata herdno-herd/herd maintainer emailmaintainer-nee...@gentoo.org/email /maintainer /pkgmetadata Can this practice of adding m-n packages to gentoo-x86 be stopped? If you add it, take responsibility for it, please. If you don't want to take responsibility for it, at least find a team that is willing to look after it. If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. Why does anyone need to *add* a package that is maintainer-needed? This is one of the problems of the gentoo-x86 tree - too many maintainer-needed packages. It is a bad thing for our users because when they submit bugs and/or fixes, they go [generally] unnoticed for ages. Also, as you may know, the treecleaner team is constantly fighting with removing m-n packages. The tree has 679 m-n packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. -Jeremy
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 7:00 PM, Jeremy Olexa darks...@gentoo.org wrote: On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. Why does anyone need to *add* a package that is maintainer-needed? This is one of the problems of the gentoo-x86 tree - too many maintainer-needed packages. I'm just pointing out that if you prohibit that by policy, this is what people will do. The real problem is that maintainer-needed packages are allowed to remain in the tree *indefinitely*. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. Just start removing old[1] maintainer-needed packages. If people complain, tell them to start maintaining it. If they continue to complain, ignore them. As tree-cleaner, you have the power to do this and not take bullshit from people about it. 1. Set old as one month, with a 2 month package.mask duration before it's removed. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa darks...@gentoo.org wrote: On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. So, I'd like to propose that somewhere between adding stuff to the tree that nobody has any intent to look after, and removing stuff that has been around a long time with no clear problems, there is a happy medium. How about this - if you add a package to the tree, you are responsible for it for at least a year. If you can get somebody else to take it then that is fine. If it has problems QA can flame you (privately at first) for it, and you should feel appropriately embarrassed and fix it, or remove it. After a year, it can go maintainer-needed. Before a year, it cannot, and you either need to actually maintain it, or remove it. Developers should not be adding packages they have no interest in whatsoever, or that have so many QA issues initially that they're high-maintenance right from the start. If a dev gets a package from a proxy-maintainer and they disappear then they can nurse it along or remove it as makes sense - we should be nice to these devs but we shouldn't just cut the packages loose. Packages that are maintainer-needed stay around as long as they're not making trouble. If they get lots of complaints they get announced on -dev, and after two weeks they get masked if not picked up. If they end up blocking something then likewise they get announced and then masked. That basically is the current practice anyway. I don't see a need to remove m-n packages wholesale just to say that we did it, or to punish users for not becoming devs or whatever. And of course, the usual long-term solutions like making proxy-maintaining easier should be pursued. Rich
Re: [gentoo-dev] FYI: USE=hal masked in base/use.mask and related
Chí-Thanh Christopher Nguyễn schrieb: Samuli Suominen schrieb: Also, both udisks and upower now have blockers for sys-apps/hal to prevent overlapping features. The result of this is that KDE and Gnome are now not installable at the same time on a stable system. Ah sorry, I was wrong. KDE and Gnome are installable at the same time if you disable automounting support in KDE. However that situation is still not great. Best regards, Chí-Thanh Christopher Nguyễn
Maintainership offering; was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Am 27.03.2011 15:30, schrieb Jeremy Olexa: The tree has 679 m-n packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml If you cannot find someone else as a maintainer and someone is willing to proxy me, I'd take dev-vcs/stgit: I use it on a daily basis (though only to manage my configs) and the current ebuild has been written by me (well - except the -r1-Diff). This would at least reduce the number of m-n packages to 678 :-) - René signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrite: dev-libs/eggdbus
# Samuli Suominen ssuomi...@gentoo.org (27 Mar 2011) # Orphaned library with bad habit of spreading around the system from libtool's # files. Not used by anything in tree. If you have problems after removal, # look into using lafilefixer or revdep-rebuild. # Removal in 30 days. dev-libs/eggdbus
Re: [gentoo-dev] RFC: emboss.eclass as replacement for embassy.eclass
So I need one last hint, how to correct following correctly? #if defined (HAVE64) !defined(AJ_MACOSXLF) !defined(AJ_HPUXLF) !defined(AJ_FreeBSDLF) !defined(AJ_AIXLF) struct dirent64 *dp; #else struct dirent *dp; #endif #if defined (HAVE64) !defined(AJ_MACOSXLF) !defined(AJ_HPUXLF) !defined(AJ_FreeBSDLF) !defined(AJ_AIXLF) struct stat64 sbuf; #else struct stat sbuf; #endif signature.asc Description: OpenPGP digital signature
[gentoo-dev] Fwd: VIRTUAL MACHINES
hello friends, i am syed armani and i am willing to participate in the gentoo development process via GSOC-2011 i am a computer science student, 3rd year at DCE,NCR,INDIA i want to work in Virtual Machine Builder (website or desktop client)project: i have already tried its basic things..i created a gentoo vm from a stage 3 tarball on a gentoo host. *i did this by the following way: * 1.created a directory Armani 2. downloaded stage3 tarball and portage. 3.extracted in the directory Armani. 4.copied reslov.conf to Armani/etc/resolv.conf 5.chroot to Armani, 6.update environment 7.Downloaded and installed , zen and its dependencies. 8. installed grub and configured grub.conf 9.set the root passwd and create the image using qemu. 10.moved the build to /mnt partition. 11.Game over :) Regards Syed Armani ( Armaan) ABOUT ME: i know about - c/c++ and QT4 GUI development with c++. - python - java - lua - xhtml/css/javascript - Assembly (mid level 8085 n 8086) - BASH scripting. - VIRTUALIATION AND WORKING OF HYPERVISORS AND LIBVERT. - PHP - MYSQL - DEEP LEVEL LINUX OS - BASH SCRIPTING - LAMP/WAMP - WEB 2.0 - NETWORK PROTOCOLS - NETWORK PROGRAMMING - Android Apps development I have a personality of a creative explorer, i always seek knowledge. I also organise hacking competitions at http://syedarmani.dyndns.org(disabled for now).
Re: [gentoo-dev] RFC: emboss.eclass as replacement for embassy.eclass
On Sun, Mar 27, 2011 at 10:34 AM, justin wrote: So I need one last hint, how to correct following correctly? #if defined (HAVE64) !defined(AJ_MACOSXLF) !defined(AJ_HPUXLF) !defined(AJ_FreeBSDLF) !defined(AJ_AIXLF) struct dirent64 *dp; #else struct dirent *dp; #endif #if defined (HAVE64) !defined(AJ_MACOSXLF) !defined(AJ_HPUXLF) !defined(AJ_FreeBSDLF) !defined(AJ_AIXLF) struct stat64 sbuf; #else struct stat sbuf; #endif neither should be necessary with LFS. if you call AC_USE_SYSTEM_EXTENSIONS or AC_SYS_LARGEFILE, the system will take care of translating stat into stat64 as needed. but in practice, i guess what they'll want to do is: - call AC_USE_SYSTEM_EXTENSIONS at top of configure script - add some AC_TRY_COMPILE's: AC_CACHE_CHECK([for stat64], ac_cv_struct_stat64, [AC_TRY_COMPILE([#include sys/stat.h], [struct stat64 st], ac_cv_struct_stat64=yes, ac_cv_struct_stat64=no)]) if test x$ac_cv_struct_stat64 = xyes; then AC_DEFINE(HAVE_STRUCT_STAT64) fi - change the code to look at HAVE_STRUCT_STAT64 instead of random system defines (largely untested :P) -mike
Re: [gentoo-dev] Fwd: VIRTUAL MACHINES
On Sun, Mar 27, 2011 at 10:35 AM, Armaan wrote: i am syed armani and i am willing to participate in the gentoo development process via GSOC-2011 i am a computer science student, 3rd year at DCE,NCR,INDIA gentoo-...@gentoo.org is the mailing list for GSoC -mike
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 27.3.2011 15:44, Rich Freeman napsal(a): On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa darks...@gentoo.org wrote: On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. So, I'd like to propose that somewhere between adding stuff to the tree that nobody has any intent to look after, and removing stuff that has been around a long time with no clear problems, there is a happy medium. How about this - if you add a package to the tree, you are responsible for it for at least a year. If you can get somebody else to take it then that is fine. If it has problems QA can flame you (privately at first) for it, and you should feel appropriately embarrassed and fix it, or remove it. After a year, it can go maintainer-needed. Before a year, it cannot, and you either need to actually maintain it, or remove it. Developers should not be adding packages they have no interest in whatsoever, or that have so many QA issues initially that they're high-maintenance right from the start. If a dev gets a package from a proxy-maintainer and they disappear then they can nurse it along or remove it as makes sense - we should be nice to these devs but we shouldn't just cut the packages loose. Packages that are maintainer-needed stay around as long as they're not making trouble. If they get lots of complaints they get announced on -dev, and after two weeks they get masked if not picked up. If they end up blocking something then likewise they get announced and then masked. That basically is the current practice anyway. I don't see a need to remove m-n packages wholesale just to say that we did it, or to punish users for not becoming devs or whatever. And of course, the usual long-term solutions like making proxy-maintaining easier should be pursued. Rich And how exactly you want to track the level of failure for the package? Since nobody is watching them already we usually don't know how much they fail until somebody tries to emerge them from dev team or notify QA by adding as CC to bug... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2PT5MACgkQHB6c3gNBRYdepgCfYUo00PKNQFoa+ZaqGoPTHOuv Dd8Ani+d1sa/jIHvrWyZrwOF3UUkESl8 =k1EI -END PGP SIGNATURE-
Re: [gentoo-dev] Fwd: VIRTUAL MACHINES
On Sun, 27 Mar 2011 20:05:20 +0530 Armaan dce3...@gmail.com wrote: ABOUT ME: i know about [...] I have a personality of a creative explorer, i always seek knowledge. Then I suggest you take a guide on caps lock use. -- Best regards, Michał Górny
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, 27 Mar 2011 15:09:09 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: On Sun, Mar 27, 2011 at 3:59 PM, Markos Chandras hwoar...@gentoo.org wrote: On Sun, Mar 27, 2011 at 01:17:46PM +0530, Nirbheek Chauhan wrote: I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. Uhm no. The fact that nobody takes care of it doesn't necessarily mean that the package is broken and that it should be removed I never said that such packages were broken. I'm saying that if no one wants to maintain them, they probably aren't needed by anyone, and we should clean such cruft from the tree. This is just wrong. If a package is working then it's easy to overlook the fact it has no maintainer. Nor does it need one. When it breaks is when people notice and either fix it or trash it. If they *are* needed by someone, then those folks should come forward to maintain it. Good luck with that. :) -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: emboss.eclass as replacement for embassy.eclass
On 27/03/11 16:50, Mike Frysinger wrote: On Sun, Mar 27, 2011 at 10:34 AM, justin wrote: So I need one last hint, how to correct following correctly? #if defined (HAVE64) !defined(AJ_MACOSXLF) !defined(AJ_HPUXLF) !defined(AJ_FreeBSDLF) !defined(AJ_AIXLF) struct dirent64 *dp; #else struct dirent *dp; #endif #if defined (HAVE64) !defined(AJ_MACOSXLF) !defined(AJ_HPUXLF) !defined(AJ_FreeBSDLF) !defined(AJ_AIXLF) struct stat64 sbuf; #else struct stat sbuf; #endif neither should be necessary with LFS. if you call AC_USE_SYSTEM_EXTENSIONS or AC_SYS_LARGEFILE, the system will take care of translating stat into stat64 as needed. but in practice, i guess what they'll want to do is: - call AC_USE_SYSTEM_EXTENSIONS at top of configure script - add some AC_TRY_COMPILE's: AC_CACHE_CHECK([for stat64], ac_cv_struct_stat64, [AC_TRY_COMPILE([#include sys/stat.h], [struct stat64 st], ac_cv_struct_stat64=yes, ac_cv_struct_stat64=no)]) if test x$ac_cv_struct_stat64 = xyes; then AC_DEFINE(HAVE_STRUCT_STAT64) fi - change the code to look at HAVE_STRUCT_STAT64 instead of random system defines (largely untested :P) -mike Thanks Mike, compiletime and runtime tests are fine. I really owe you one! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mar 27, 2011 11:01 AM, Tomáš Chvátal scarab...@gentoo.org wrote: And how exactly you want to track the level of failure for the package? Since nobody is watching them already we usually don't know how much they fail until somebody tries to emerge them from dev team or notify QA by adding as CC to bug... If a tree falls in the forest...does anybody care? Broken packages that nobody notices don't cost us much. A tinderbox sweep will id and tag them for cleaning eventually. All I'm saying is that the problem is broken packages, so address those, m-n or otherwise. By all means be proactive about finding maintainers, but let's not go purging working packages. As far as how broken is too broken - if it causes the distro headaches, address it. That could be blockers, or tons of bug reports, or whatever... Rich
Re: Maintainership offering; was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 03/27/2011 09:08 AM, René 'Necoro' Neumann wrote: If you cannot find someone else as a maintainer and someone is willing to proxy me, I'd take dev-vcs/stgit: I use it on a daily basis (though % cvs di Index: metadata.xml === RCS file: /var/cvsroot/gentoo-x86/dev-vcs/stgit/metadata.xml,v retrieving revision 1.1 diff -u -r1.1 metadata.xml --- metadata.xml6 Mar 2010 15:58:48 - 1.1 +++ metadata.xml27 Mar 2011 18:56:24 - @@ -3,6 +3,12 @@ pkgmetadata herdno-herd/herd maintainer - emailmaintainer-nee...@gentoo.org/email + emailgen...@necoro.eu/email + nameRené 'Necoro' Neumann/name + descriptionProxy maintainer, assign bugs/description +/maintainer +maintainer + emaildarks...@gentoo.org/email + descriptionProxy committer, CC bugs/description /maintainer /pkgmetadata All yours, pleasure to work with you. Please maintain a relationship on relevant bugs and poke me via personal email when I forget to do something =D (By the way, I know nothing of this package and will rely on you to do the work minus committing, I'll do that for you) -Jeremy
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 1:43 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Sun, Mar 27, 2011 at 7:00 PM, Jeremy Olexa darks...@gentoo.org wrote: On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: If you prohibit people from doing that, they'll just commit it normally, and then remove themselves a week later. Why does anyone need to *add* a package that is maintainer-needed? This is one of the problems of the gentoo-x86 tree - too many maintainer-needed packages. I'm just pointing out that if you prohibit that by policy, this is what people will do. The real problem is that maintainer-needed packages are allowed to remain in the tree *indefinitely*. I propose that we should be more aggressive about package.masking (for removal) all maintainer-needed packages from the tree by doing that one month after they become maintainer-needed. If someone doesn't volunteer to take care of it, it probably wasn't important anyway. That is abit extreme for me (read: I don't have motivation to fight the flames), but I wouldn't complain if someone else did it to be honest. Just start removing old[1] maintainer-needed packages. If people complain, tell them to start maintaining it. If they continue to complain, ignore them. As tree-cleaner, you have the power to do this and not take bullshit from people about it. The intent of the TreeCleaner project (years ago) was to essentially look for packages in bugzilla that had lots of bugs and no maintainer. For a while beandog essentially maintained a site that tracked this for us (Gentoo Package that need Lovin' was the awesome title.) From that list you either fixed the problems and commited them (e.g. you were a roving package maintainer) or you pmasked it and marked it for the deadpool. There is not much policy on treecleaning a package just because no one has touched it. Time since last touch was just one of a dozen indicators used to find packages that are broken (because a package not touched since 2006 is also not likely to compile.) -A 1. Set old as one month, with a 2 month package.mask duration before it's removed. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] RFC: Remove .lzma in favor of .xz portage snapshots
On 03/04/2011 11:33 AM, Jeremy Olexa wrote: Hello all, This email is to solicit concerns or thoughts about removing the .lzma portage snapshots. The facts: - Starting on 2011-03-03, I enabled .xz compression on snapshots that Gentoo makes available[1]. - On 2011-01-05, Mike added[2] .xz support to emerge-webrsync. - xz-utils is now in the system set[3] anyway and .xz instead of .lzma should eliminate some confusion for new users. That is about all I can think of. My opinion is that this is mostly a cosmetic change (as lzma is generated via xz-utils anyway) but makes sense given the popular[4] compression choices. I'd like to target 2011-04-01 as the date to turn off lzma generation. After generation is turned off, the lzma archives will fall off the mirrors in 7 days. Any concerns? Done as of today, ahead of schedule because I have time now :) -Jeremy Thanks, Jeremy [1]: http://gentoo.osuosl.org/snapshots/ [2]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9ff806 [3]: http://archives.gentoo.org/gentoo-dev/msg_998b4e7fdf578346bb5cfc66be340f7d.xml [4]: Without known data to back this up, I'm using the short options of tar(1) to form some opinion as presented by the community.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 12:47 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Mar 27, 2011 at 1:43 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: Just start removing old[1] maintainer-needed packages. If people complain, tell them to start maintaining it. If they continue to complain, ignore them. As tree-cleaner, you have the power to do this and not take bullshit from people about it. The intent of the TreeCleaner project (years ago) was to essentially look for packages in bugzilla that had lots of bugs and no maintainer. For a while beandog essentially maintained a site that tracked this for us (Gentoo Package that need Lovin' was the awesome title.) From that list you either fixed the problems and commited them (e.g. you were a roving package maintainer) or you pmasked it and marked it for the deadpool. There is not much policy on treecleaning a package just because no one has touched it. Time since last touch was just one of a dozen indicators used to find packages that are broken (because a package not touched since 2006 is also not likely to compile.) Sure, that's the history. But what made sense back then doesn't make sense now. Back then we didn't have 600+ packages that no one maintains, and whose bugs go almost entirely unread. We had crazy amounts of manpower back then. As we evolve, the responsibilities of the different parts of Gentoo also evolve. As such, the tree-cleaners project has evolved, and if the team isn't allowed to clean the tree, then why do we even have it anymore? I really don't understand *why* people want to keep around unmaintained packages. If a package is not maintained, we should come up and say it outright. Trying to maintain the illusion of maintenance is really bad — for each person reporting a bug about a package, 100 people who got that same bug don't report it at all. So what happens when there are just 50 users for some packages? Half the time we won't even know that one of them is broken[1]. The rest of the time, users will get a bad impression of Gentoo saying Man, half the packages don't even work. It's really simple: (a) If the package has plenty of users, there should be no problems finding a maintainer or a proxy-maintainer. (b) If the package has few users and is high-maintenance, it's either already broken, or will get broken soon without a maintainer. Find one or remove it! (c) If the package has few users and is low-maintenance, package.mask it so we can figure out who the users are, and we can get them to proxy-maintain it, it's so little work anyway, right? (d) If the package has very few or no users, what the hell is it doing unmaintained in the tree? It's just eating up disk inodes and space. We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. Let's not turn portage into a graveyard for packages. Let's just remove crap. 1. Writer is bad at statistics, this is probably inaccurate. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Last rites for app-text/ssddiff app-text/mxml2man sys-block/unieject
# Diego E. Pettenò flamee...@gentoo.org (27 Mar 2011) # Last release in 2006, nobody looking after it. # Pending removal on 2011-04-27 app-text/ssddiff # Diego E. Pettenò flamee...@gentoo.org (27 Mar 2011) # Abandoned project of mine. Nothing really use it. # Pending removal on 2011-04-27 app-text/mxml2man # Diego E. Pettenò flamee...@gentoo.org (27 Mar 2011) # Abandoned project of mine; doesn't work as intended on Linux # nowadays. # Pending removal on 2011-04-27 sys-block/unieject -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 7:40 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Mon, Mar 28, 2011 at 12:47 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Mar 27, 2011 at 1:43 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: Just start removing old[1] maintainer-needed packages. If people complain, tell them to start maintaining it. If they continue to complain, ignore them. As tree-cleaner, you have the power to do this and not take bullshit from people about it. The intent of the TreeCleaner project (years ago) was to essentially look for packages in bugzilla that had lots of bugs and no maintainer. For a while beandog essentially maintained a site that tracked this for us (Gentoo Package that need Lovin' was the awesome title.) From that list you either fixed the problems and commited them (e.g. you were a roving package maintainer) or you pmasked it and marked it for the deadpool. There is not much policy on treecleaning a package just because no one has touched it. Time since last touch was just one of a dozen indicators used to find packages that are broken (because a package not touched since 2006 is also not likely to compile.) Sure, that's the history. But what made sense back then doesn't make sense now. Back then we didn't have 600+ packages that no one maintains, and whose bugs go almost entirely unread. We had crazy amounts of manpower back then. We probably had more than 600 unmaintained packages because no one was removing dead packages from the tree. I also dispute your manpower logic. Gentoo has been short on developers for years. I don't see how 2011 is any different than 2007 in this aspect. As we evolve, the responsibilities of the different parts of Gentoo also evolve. As such, the tree-cleaners project has evolved, and if the team isn't allowed to clean the tree, then why do we even have it anymore? The community got pissed when I deleted unmaintained packages from the tree 'just because it was unmaintained.' Thats why there were a set of criteria for removal. Maybe they changed their mind and you can convince them. Ignoring people's opinions because they are whiners and you are Treecleaners is a thin edge to walk though; so I'd be careful. At least during my tenure there were still hundreds of unmaintained and broken packages; so I didn't much care about unmaintained but working stuff (since there was plenty of work to do.) I would argue the tree is still in a similar state. I really don't understand *why* people want to keep around unmaintained packages. If a package is not maintained, we should come up and say it outright. Trying to maintain the illusion of maintenance is really bad — for each person reporting a bug about a package, 100 people who got that same bug don't report it at all. So what happens when there are just 50 users for some packages? Half the time we won't even know that one of them is broken[1]. The rest of the time, users will get a bad impression of Gentoo saying Man, half the packages don't even work. Properly tagged I don't think there is any illusion. Maintainer-needed is maintainer-needed after all. If half of the packages *in the tree* don't work then we have a problem. If half the packages *a user tries to install* are broken then they should certainly use another distro. Perhaps Gentoo is not for their area (and the key point is that it doesn't have to be.) It's really simple: (a) If the package has plenty of users, there should be no problems finding a maintainer or a proxy-maintainer. (b) If the package has few users and is high-maintenance, it's either already broken, or will get broken soon without a maintainer. Find one or remove it! (c) If the package has few users and is low-maintenance, package.mask it so we can figure out who the users are, and we can get them to proxy-maintain it, it's so little work anyway, right? (d) If the package has very few or no users, what the hell is it doing unmaintained in the tree? It's just eating up disk inodes and space. So launch gstats and get usage numbers. If no one is using a package that is a keen indicator it can be punted; however no one will get off their ass and get more data to back anything up (myself included...) All of your points above assume we have a decent metric of 'how many users a package has' and about the only way we know that is when users file bugs for it (version bump, bug, feature req, etc..) We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. But again this is all made up...m-n was 670-odd packages last I checked. Do we still have m-w these days? Let's not turn portage into a graveyard for packages. Let's just remove crap. 1. Writer is bad at statistics, this is probably inaccurate. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2011 08:30:16 -0500 Jeremy Olexa darks...@gentoo.org wrote: The tree has 679 m-n packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml I want to proxy-maintain app-misc/pwsafe. It hasn't been updated in six years, but it still builds (albeit with a few warnings) and works and I use it and don't want to see it disappear. Is anyone willing to do this? Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: GnuPT 2.7.2 iEYEARECAAYFAk2PnAEACgkQXUF6hOTGP7fSvACgls+xMxexfWytiXxYH0VwTY9c G1MAn3nKImR6inTrnh2Bsnq86rcsbzXd =pDQ6 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: It's really simple: (a) If the package has plenty of users, there should be no problems finding a maintainer or a proxy-maintainer. Uh, I guess that's why we are flooded with people wanting to be devs... There are lots of high-use packages that could use more maintainers. I'm not aware of any teams that would turn away help. (b) If the package has few users and is high-maintenance, it's either already broken, or will get broken soon without a maintainer. Find one or remove it! If it doesn't build, then it can be removed. Nobody is arguing with that. If you think that someday it might not build, then just wait a few months and if you're right you can satisfy your itch to prune the tree... (c) If the package has few users and is low-maintenance, package.mask it so we can figure out who the users are, and we can get them to proxy-maintain it, it's so little work anyway, right? Uh, package.mask is not intended to be an end-user communication tool. News is slightly better in this respect, but again this is not its purpose. We shouldn't be punishing people for not becoming developers. I don't want to use a distro that throws up warning messages every few months because some package I've been using had its developer retire, and I'm a developer. If it breaks and I care enough about it, I'll rescue it. If I'm passionate about it, I'll step in before it breaks. Holding users ransom is not the solution. (d) If the package has very few or no users, what the hell is it doing unmaintained in the tree? It's just eating up disk inodes and space. Uh, and how much does the inodes, space, and bandwidth consumed by those ~700 m-n packages actually cost. Are we talking about going through wailing and gnashing of teeth so that our stakeholders can save a total of 45 cents worth of disk space across 50 mirrors and 50,000 Gentoo boxes over the next 5 years? If one person is getting use out of it, and nobody is getting hurt, and it costs a few inodes, I'm fine with that. We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. I don't know anybody who uses Gentoo because of our huge repository. Sure, compared to LFS it is big. Compared to most major distros, Gentoo isn't all that large. If all somebody wants is a ton of packages they're going to run Debian or whatever. Sure, we have a nice repository and we should be proud of it, but I don't think anybody is trying to over-inflate our repo size just by loading it up with junk. The thing I don't understand here is that there seems to be some perception that having stuff in the tree or in Bugzilla costs us something. Sure, at some level it does, and if 99.99% of portage were junk data, then we might have a problem. However, database records and inodes come billions for the dollar. Having a few percent more churn so that we can more gracefully handle the lifecycle of packages doesn't seem like much of a sacrifice. If you're tired of looking at junk when you search bugzilla, then you need to think about how you're searching it. These sorts of arguments come up at work all the time and unless there is some kind of regulatory issue at stake or real loss of revenue associated with lost opportunities, chasing down unnecessary database records to be tidy almost always costs far more than it saves. I'd be shocked if the total cost to our sponsors in mirror space for m-n packages exceeded the value of time spent by everybody reading this thread. I think we should be practical - I'm all for giving treecleaners a free hand when packages really cause problems, but being anal-retentive just for the sake of doing so doesn't seem to create real value. Rich
Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 1:50 AM, Christopher Head hea...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2011 08:30:16 -0500 Jeremy Olexa darks...@gentoo.org wrote: The tree has 679 m-n packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml I want to proxy-maintain app-misc/pwsafe. It hasn't been updated in six years, but it still builds (albeit with a few warnings) and works and I use it and don't want to see it disappear. Is anyone willing to do this? I can proxy-maintain app-misc/pwsafe with you. I have no idea how pwsafe works, though, so I'll trust that you've done your homework w.r.t bumps or bugfixes :) There are currently two bugs open with pwsafe: https://bugs.gentoo.org/show_bug.cgi?id=347549 (stable req) https://bugs.gentoo.org/show_bug.cgi?id=292749 (cosmetic enhancement) You should open a bugzilla account so that I can assign these to you. However, the bugs aren't urgent, so we can tackle them when you have time. --- metadata.xml22 Mar 2009 02:35:03 - 1.5 +++ metadata.xml27 Mar 2011 20:46:54 - @@ -3,7 +3,13 @@ pkgmetadata herdno-herd/herd maintainer -emailmaintainer-nee...@gentoo.org/email + nameChristopher Head/name + emailhea...@gentoo.org/email + descriptionProxy maintainer, assign bugs/description + /maintainer + maintainer + nameNirbheek Chauhan/name +emailnirbh...@gentoo.org/email /maintainer longdescription lang=en pwsafe is a commandline password database utility compatible with -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Am 27.03.2011 22:47, schrieb Nirbheek Chauhan: --- metadata.xml 22 Mar 2009 02:35:03 - 1.5 +++ metadata.xml 27 Mar 2011 20:46:54 - @@ -3,7 +3,13 @@ pkgmetadata herdno-herd/herd maintainer -emailmaintainer-nee...@gentoo.org/email + nameChristopher Head/name + emailhea...@gentoo.org/email That should be s/gentoo.org/gmail.com/, shouldn't it? signature.asc Description: OpenPGP digital signature
Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, Mar 27, 2011 at 4:47 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Mon, Mar 28, 2011 at 1:50 AM, Christopher Head hea...@gmail.com wrote: --- metadata.xml 22 Mar 2009 02:35:03 - 1.5 +++ metadata.xml 27 Mar 2011 20:46:54 - @@ -3,7 +3,13 @@ pkgmetadata herdno-herd/herd maintainer - emailmaintainer-nee...@gentoo.org/email + nameChristopher Head/name + emailhea...@gentoo.org/email + descriptionProxy maintainer, assign bugs/description + /maintainer + maintainer + nameNirbheek Chauhan/name + emailnirbh...@gentoo.org/email /maintainer longdescription lang=en pwsafe is a commandline password database utility compatible with -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team - emailhea...@gentoo.org/email + emailhea...@gmail.com/email -- David Abbott (dabbott) Gentoo http://dev.gentoo.org/~dabbott/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 2:14 AM, Rich Freeman ri...@gentoo.org wrote: On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: It's really simple: (a) If the package has plenty of users, there should be no problems finding a maintainer or a proxy-maintainer. Uh, I guess that's why we are flooded with people wanting to be devs... There are lots of high-use packages that could use more maintainers. I'm not aware of any teams that would turn away help. Everyone thinks all is dandy, and so no one volunteers. Why would someone volunteer their help if we don't advertise the need? Every single team I know has members that are there for historical value and don't do anything anymore. This means team member lists are inevitably artificially inflated. (b) If the package has few users and is high-maintenance, it's either already broken, or will get broken soon without a maintainer. Find one or remove it! If it doesn't build, then it can be removed. Nobody is arguing with that. If you think that someday it might not build, then just wait a few months and if you're right you can satisfy your itch to prune the tree... I think you missed my point about fewer users meaning the likelihood of bugs getting reported being low. And even if bugs get reported, who reads bug reports assigned to maintainer-nee...@gentoo.org? (c) If the package has few users and is low-maintenance, package.mask it so we can figure out who the users are, and we can get them to proxy-maintain it, it's so little work anyway, right? Uh, package.mask is not intended to be an end-user communication tool. News is slightly better in this respect, but again this is not its purpose. End-user? No. Potential developer? Yes. That's why we have a one-month package.mask period while last-riting unmaintained packages for QA problems. We shouldn't be punishing people for not becoming developers. I don't want to use a distro that throws up warning messages every few months because some package I've been using had its developer retire, and I'm a developer. If it breaks and I care enough about it, I'll rescue it. If I'm passionate about it, I'll step in before it breaks. Holding users ransom is not the solution. So you're worried that the oldness criteria in the policy should not be too strict? Cool, that's something for discussion. (d) If the package has very few or no users, what the hell is it doing unmaintained in the tree? It's just eating up disk inodes and space. Uh, and how much does the inodes, space, and bandwidth consumed by those ~700 m-n packages actually cost. Are we talking about going through wailing and gnashing of teeth so that our stakeholders can save a total of 45 cents worth of disk space across 50 mirrors and 50,000 Gentoo boxes over the next 5 years? If one person is getting use out of it, and nobody is getting hurt, and it costs a few inodes, I'm fine with that. One person who gets some use out of it, and how many who either can't compile it, or can't run it? This kind of thing affects how people see Gentoo. Besides, removal of a package from the tree doesn't mean there's no way to use it anymore. For those who still use that one package that no one else really uses anymore, local portdir_overlay configuration is really easy. We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. I don't know anybody who uses Gentoo because of our huge repository. Sure, compared to LFS it is big. Compared to most major distros, Gentoo isn't all that large. If all somebody wants is a ton of packages they're going to run Debian or whatever. Note that most other distros have large package numbers because they split their packages into pkgname, pkgname-dev pkgname-doc, etc. I'm not sure if anyone counts source-package numbers for binary distros. Sure, we have a nice repository and we should be proud of it, but I don't think anybody is trying to over-inflate our repo size just by loading it up with junk. The thing I don't understand here is that there seems to be some perception that having stuff in the tree or in Bugzilla costs us something. Sure, at some level it does, and if 99.99% of portage were junk data, then we might have a problem. However, database records and inodes come billions for the dollar. Having a few percent more churn so that we can more gracefully handle the lifecycle of packages doesn't seem like much of a sacrifice. If you're tired of looking at junk when you search bugzilla, then you need to think about how you're searching it. These sorts of arguments come up at work all the time and unless there is some kind of regulatory issue at stake or real loss of revenue associated with lost opportunities, chasing down unnecessary database records to be tidy almost always costs far
Re: [gentoo-dev] FYI: USE=hal masked in base/use.mask and related
Le 27/03/2011 10:36, Samuli Suominen a écrit :
Also, both udisks and upower now have blockers for sys-apps/hal to
prevent overlapping features.
Samuli,
I know you want to kill HAL with a vengeance. I don't disagree with the
ultimate goal but I think you've gone too far.
HAL and u{power,disks} are _perfectly_ parallel installable and there
are absolutely _no_ conflicts between the two.
Blockers should be used for _file_ conflicts, not for _feature_
conflicts, otherwise we'd have to mask and get rid of half (or even
more) of all the packages we provide in portage.
I urge to reconsider this blocker and mask.
Thanks
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 1:47 AM, Alec Warner anta...@gentoo.org wrote: On Sun, Mar 27, 2011 at 7:40 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: Sure, that's the history. But what made sense back then doesn't make sense now. Back then we didn't have 600+ packages that no one maintains, and whose bugs go almost entirely unread. We had crazy amounts of manpower back then. We probably had more than 600 unmaintained packages because no one was removing dead packages from the tree. I also dispute your manpower logic. Gentoo has been short on developers for years. I don't see how 2011 is any different than 2007 in this aspect. The current problem is burnt-out or semi-active devs who commit occasionally, but aren't able to help with any herd-related work because they're out of touch. As such, their presence in the team gives a false indication of strength. This problem was much less severe in 2007 (afair). As we evolve, the responsibilities of the different parts of Gentoo also evolve. As such, the tree-cleaners project has evolved, and if the team isn't allowed to clean the tree, then why do we even have it anymore? The community got pissed when I deleted unmaintained packages from the tree 'just because it was unmaintained.' Thats why there were a set of criteria for removal. Maybe they changed their mind and you can convince them. Well, I bet that more than half of them retired or stopped being active. Ignoring people's opinions because they are whiners and you are Treecleaners is a thin edge to walk though; so I'd be careful. At least during my tenure there were still hundreds of unmaintained and broken packages; so I didn't much care about unmaintained but working stuff (since there was plenty of work to do.) I would argue the tree is still in a similar state. The fun part is that we really don't even know in what state those packages are w.r.t. runtime issues. I know that deigo's tinderbox keeps track of compile-time issues *extremely* well, but we have zero runtime testing. I really don't understand *why* people want to keep around unmaintained packages. If a package is not maintained, we should come up and say it outright. Trying to maintain the illusion of maintenance is really bad — for each person reporting a bug about a package, 100 people who got that same bug don't report it at all. So what happens when there are just 50 users for some packages? Half the time we won't even know that one of them is broken[1]. The rest of the time, users will get a bad impression of Gentoo saying Man, half the packages don't even work. Properly tagged I don't think there is any illusion. Maintainer-needed is maintainer-needed after all. The problem is that from the PoV of the user, everything in the tree is official. After all, that's how all the distros function. So launch gstats and get usage numbers. If no one is using a package that is a keen indicator it can be punted; however no one will get off their ass and get more data to back anything up (myself included...) If we launch gstats *today*, it'll take us at least a long time before we get decent numbers, and even after that, those numbers will be biased towards those people who are really active in following Gentoo news and developments. Unlike Firefox's usage stats, we have no way of prompting pre-existing gentoo installations with a Do want to take part in gstats? question. All of your points above assume we have a decent metric of 'how many users a package has' and about the only way we know that is when users file bugs for it (version bump, bug, feature req, etc..) Yes. But we have another (more reliable) way: p.mask it and wait for people to complain. We all like to boast about how gentoo has 15,000 packages, but we neglect to mention that more than 1000 of these are either unmaintained or very poorly maintained. And this is a very conservative number. But again this is all made up...m-n was 670-odd packages last I checked. Do we still have m-w these days? very poorly meant maintainers ignoring bugs for years, or empty herds. We have plenty of both. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Am 27.03.2011 22:44, schrieb Rich Freeman: We shouldn't be punishing people for not becoming developers. I don't want to use a distro that throws up warning messages every few months because some package I've been using had its developer retire, and I'm a developer. If it breaks and I care enough about it, I'll rescue it. If I'm passionate about it, I'll step in before it breaks. Holding users ransom is not the solution. Well, but you need some way of communicate that certain packages are w/o a proper maintainer. Why else should someone step up? I, for instance, was quite surprised about the list of m-n packages and seeing that quite some packages I use are on that list. I would never had a look at it without this thread (or are users nowadays supposed to check metadata.xml on a regular basis?). So, why not at least add some elog-like output at the end of an emerge run like The following installed packages are without maintainer: $LIST. If you want to step up, please see $PROXY_MAINTAINER_URL. And before you state well - it is enough if someone steps up when it breaks: Even then it might get unnoticed, that the package is unmaintained. I never check thoroughly where the package gets assigned to during bug-wrangling, and I suppose that I'm not alone here. So the only thing one notices is a bug which never gets any response. And this is frustrating. Regarding the pro-active masking/removal: As a user I'd object to this. Please try a less obtrusive path first, like the info output I mentioned above. Seeing that used packages gets masked quite often spawns bad mood (at least in my experience and seeing reactions in forum threads). - René signature.asc Description: OpenPGP digital signature
Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Mar 28, 2011 at 2:25 AM, David Abbott dabb...@gentoo.org wrote: On Sun, Mar 27, 2011 at 4:47 PM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Mon, Mar 28, 2011 at 1:50 AM, Christopher Head hea...@gmail.com wrote: --- metadata.xml 22 Mar 2009 02:35:03 - 1.5 +++ metadata.xml 27 Mar 2011 20:46:54 - @@ -3,7 +3,13 @@ pkgmetadata herdno-herd/herd maintainer - emailmaintainer-nee...@gentoo.org/email + nameChristopher Head/name + emailhea...@gentoo.org/email + descriptionProxy maintainer, assign bugs/description + /maintainer + maintainer + nameNirbheek Chauhan/name + emailnirbh...@gentoo.org/email /maintainer longdescription lang=en pwsafe is a commandline password database utility compatible with -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team - emailhea...@gentoo.org/email + emailhea...@gmail.com/email Oops, fixed :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] FYI: USE=hal masked in base/use.mask and related
On Sun, Mar 27, 2011 at 5:13 PM, Rémi Cardona wrote:
Le 27/03/2011 10:36, Samuli Suominen a écrit :
Also, both udisks and upower now have blockers for sys-apps/hal to
prevent overlapping features.
I know you want to kill HAL with a vengeance. I don't disagree with the
ultimate goal but I think you've gone too far.
HAL and u{power,disks} are _perfectly_ parallel installable and there
are absolutely _no_ conflicts between the two.
Blockers should be used for _file_ conflicts, not for _feature_
conflicts, otherwise we'd have to mask and get rid of half (or even
more) of all the packages we provide in portage.
latest pciutils blocks hal, so i think that should cover the urge
people to migrate aspect in ~arch
-mike
[gentoo-dev] LiveCD: unpacking firmware
I had a question related to the amd64 minimal livecd. I was not sure of the appropriate mailing list, so please forgive redirect if this is the wrong one. What exactly is happening at the Unpacking firmware stage of the boot process? Is there a way to find out exactly what firmware is being loaded? Or a way to boot without loading the firmware? Why? It is a somewhat strange reason. I am having issues with a high-pitched hum coming from the audio jacks (occurs on both MB sound and a creative sound card) I have a very nice sound system (a sound board, studio monitors...I am an audio hobbyist), and no other system has these problems, so I am relatively sure that it is not the speakers/cables. I have been booting from the liveCD, and I have pinpointed the point at which the hum starts to something near the *Unpacking firmware stage. I realize this is somewhat esoteric, but it renders my system almost useless, and would greatly appreciate any input. Thanks, Colleen Josephson Dept. of Electrical Engineering and Computer Science Massachusetts Institute of Technology Class of 2013
Re: [gentoo-dev] LiveCD: unpacking firmware
On Sun, Mar 27, 2011 at 5:38 PM, Colleen Josephson wrote: I had a question related to the amd64 minimal livecd. I was not sure of the appropriate mailing list, so please forgive redirect if this is the wrong one. you probably want the gentoo-catalyst mailing list -mike
Re: [gentoo-dev] rejecting unsigned commits
On 03/24/2011 04:59 PM, Mike Frysinger wrote: this is especially important for the people doing arch keywording since they make a ton of commits. i'm looking at you armin76. One thing I don't get amidst this whole conversation is why I should sign a Manifest file when committing KEYWORDS or something equally as trivial like deleting ebuilds. By signing the Manifest, I interpret that as yes, I committed this Manifest file and yes I trust every hash in this Manifest file when in reality, I have no clue if the Manifest file is correct because I didn't inspect anything. Am I missing something? Thanks, Jeremy
Re: [gentoo-dev] FYI: USE=hal masked in base/use.mask and related
On 03/28/2011 12:32 AM, Mike Frysinger wrote:
On Sun, Mar 27, 2011 at 5:13 PM, Rémi Cardona wrote:
Le 27/03/2011 10:36, Samuli Suominen a écrit :
Also, both udisks and upower now have blockers for sys-apps/hal to
prevent overlapping features.
I know you want to kill HAL with a vengeance. I don't disagree with the
ultimate goal but I think you've gone too far.
HAL and u{power,disks} are _perfectly_ parallel installable and there
are absolutely _no_ conflicts between the two.
Blockers should be used for _file_ conflicts, not for _feature_
conflicts, otherwise we'd have to mask and get rid of half (or even
more) of all the packages we provide in portage.
latest pciutils blocks hal, so i think that should cover the urge
people to migrate aspect in ~arch
-mike
I've changed this to be a bit more friendly.
As you pointed out, pciutils is one.
And ~arch version of upower is second.
KDE really needs to step up and get KDE 4.6.x stabilization bug open,
and this non-issue would become moot ;-)
Re: [gentoo-dev] FYI: USE=hal masked in base/use.mask and related
KDE really needs to step up and get KDE 4.6.x stabilization bug open, and this non-issue would become moot ;-) True, we'd also have a new stable KDE rather sooner than later. It's only limited fun if upstream considers your stable version dead. :| 4.6.0 looked OK for a .0 release, some regressions compared to 4.5.5 4.6.1 introduced a lot of regressions compared to _4.6.0_! One possible cause for this might be that upstream was (and still is) in the middle of the svn - git migration, and that the 4.6.1 tarballs were pieced together by hand from different repositories... (*) Anyway. 4.6.2 will be tagged on thursday, and we hope this is going to be a worthy stable candidate. (and no, afaic that does not include kdepim...) (*) The discussion for 4.6.1: http://mail.kde.org/pipermail/release-team/2011-February/004572.html The ongoing discussion for 4.6.2: http://mail.kde.org/pipermail/release-team/2011-March/004619.html -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, 28 Mar 2011 02:55:14 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: The current problem is burnt-out or semi-active devs who commit occasionally, but aren't able to help with any herd-related work because they're out of touch. As such, their presence in the team gives a false indication of strength. This problem was much less severe in 2007 (afair). What? If anything it was much worse. It used to be next to impossible to get any answer whatsoever out of some herds until you gave up and fixed it yourself. Then they would bitch you out for touching their junk. My job has gotten a lot easier lately. The community got pissed when I deleted unmaintained packages from the tree 'just because it was unmaintained.' Thats why there were a set of criteria for removal. Maybe they changed their mind and you can convince them. Well, I bet that more than half of them retired or stopped being active. Nope, still here, still bitching. :) At least during my tenure there were still hundreds of unmaintained and broken packages; so I didn't much care about unmaintained but working stuff (since there was plenty of work to do.) I would argue the tree is still in a similar state. The fun part is that we really don't even know in what state those packages are w.r.t. runtime issues. I know that deigo's tinderbox keeps track of compile-time issues *extremely* well, but we have zero runtime testing. Well, that /is/ what bugzilla is for, after all. We can only fix what we know is broken. And I don't see how that's any different than maintained packages. I really don't understand *why* people want to keep around unmaintained packages. If a package is not maintained, we should come up and say it outright. Trying to maintain the illusion of maintenance is really bad — for each person reporting a bug about a package, 100 people who got that same bug don't report it at all. So what happens when there are just 50 users for some packages? Half the time we won't even know that one of them is broken[1]. The rest of the time, users will get a bad impression of Gentoo saying Man, half the packages don't even work. Properly tagged I don't think there is any illusion. Maintainer-needed is maintainer-needed after all. The problem is that from the PoV of the user, everything in the tree is official. After all, that's how all the distros function. The problem is that you assume that anything that is maintainer-needed is automatically broken, when the vast majority of it is not. Would it make you feel better if packages had default herds they could fall back on rather than go maintainer-needed (eg. app-crypt packages would automatically go into the crypto herd, media-gfx go to graphics, etc.)? That's something we could be more aggressive about. So launch gstats and get usage numbers. If no one is using a package that is a keen indicator it can be punted; however no one will get off their ass and get more data to back anything up (myself included...) If we launch gstats *today*, it'll take us at least a long time before we get decent numbers, and even after that, those numbers will be biased towards those people who are really active in following Gentoo news and developments. Unlike Firefox's usage stats, we have no way of prompting pre-existing gentoo installations with a Do want to take part in gstats? question. Last I checked we had a nifty news system for making announcements. And I thought we were supposed to have Smolt support like two years ago. What happened to it? All of your points above assume we have a decent metric of 'how many users a package has' and about the only way we know that is when users file bugs for it (version bump, bug, feature req, etc..) Yes. But we have another (more reliable) way: p.mask it and wait for people to complain. Hey, maybe next we can slip random build errors into packages and see who files bugs. I don't know why people continue to think that breaking the tree to see who complains is an acceptable form of QA. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] rejecting unsigned commits
On Sun, 27 Mar 2011 17:04:56 -0500 Jeremy Olexa darks...@gentoo.org wrote: this is especially important for the people doing arch keywording since they make a ton of commits. i'm looking at you armin76. One thing I don't get amidst this whole conversation is why I should sign a Manifest file when committing KEYWORDS or something equally as trivial like deleting ebuilds. By signing the Manifest, I interpret that as yes, I committed this Manifest file and yes I trust every hash in this Manifest file when in reality, I have no clue if the Manifest file is correct because I didn't inspect anything. Am I missing something? You sign, that you did this. More or less. The guy before you did the same. If there is an error all previous revisions of the tree are available and you can check, whose mistake it was. Nothing really changes, but I can check whether a gentoo dev committed the change and who it was (and that it was not anybody who hacked some rsync mirror). Philipp --
Re: [gentoo-dev] Re: rejecting unsigned commits
On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote: 3) Rely on an existing key list somewhere distributed in portage; the list ... Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed people around?) You can use the long-format key IDs if you want. 0xB27B944E34884E85 is my long-form key. Am I missing something? In my tree-signing GLEPs, I explicitly pointed out that the developer signing of content only had real value for the developer-CVS part of the chain. Specifically, that while building the rsync tree for distribution, we can verify that the content we are preparing was indeed from a developer. Please re-read GLEP57. Everything in this thread been attempting to apply solutions to 'Process #1' (developer-infrastructure) to provide direct security for the end user after 'Process #2' (infrastructure-mirrors-users). What can we be certain of? 1. Developers should be signing manifests. 2. Infrastructure should be verifying those commits before pushing out to rsync. 3. Regardless of their choice of rsync or websync, users need to be able to verify that the tree that left Infrastructure was not modified in transit. RegI see so many bad ideas mentioned in this thread. The suggestions to keep a gpg-agent with a very long passphrase TTL just provides a massive new security hole: === Attacker breaks into developer's system, has access to SSH agent and GPG agent thanks to software like keychain, now can commit as that developer. === Is this the easiest attack? No, certainly not, looking at mirrors mirror, potentially a running deliberate selective malicious mirror would be much easier. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpDvfvXctmiO.pgp Description: PGP signature
Re: [gentoo-dev] Re: rejecting unsigned commits
On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote: 3) Rely on an existing key list somewhere distributed in portage; the list file with the key id's (not the keys themselves) is signed with a master key. Is a mediocre and potentially insecure workaround. Pros: you can exactly decide what keys are used and trusted, without thinking about GnuPG's inner workings. A user can edit his key and the key remains trusted. Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed people around?) 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids) 2. Clear-sign L, produces L' 3. Include L' in /metadata/ during rsync content build. 3.1. Provide all L' files in a trusted Git repository for historical reference. 4. Tree-sign per GLEP58, such that signed list is included. Pros: - L' is plaintext and works well w/ rsync deltas. Security weakpoints: - Introduces new weak point if attacker can compromise the automated clear-signing service of #2. 4) Rely on an existing list of keys somewhere distributed in portage and possibly somewhere else (keyservers); a key userid is signed with a master key. Work with GnuPG's well-tested and well-thought-out trust relationships. Back to start, time to re-read the entire thread... :) What does this actually add over #3 in terms of security? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpwQC5IuPHgi.pgp Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2011-03-27 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2011-03-27 23h59 UTC. Removals: net-im/silc-plugin 2011-03-21 15:07:36 signals media-libs/libdjconsole 2011-03-22 18:18:36 ssuominen x11-misc/talika 2011-03-24 12:04:41 hwoarang sys-apps/inotail2011-03-24 15:13:14 angelos games-puzzle/xphotohunter 2011-03-24 18:12:29 ssuominen games-kids/stickers 2011-03-24 18:12:58 ssuominen dev-php5/PEAR-PHP_TokenStream 2011-03-26 11:39:04 olemarkus dev-php5/phpunit2011-03-26 11:39:04 olemarkus media-sound/phonon 2011-03-26 17:56:57 dilfridge app-cdr/pxlinux 2011-03-27 04:18:06 darkside app-cdr/cddetect2011-03-27 04:19:23 darkside app-emulation/basiliskII-jit2011-03-27 04:20:30 darkside dev-dotnet/ipod-sharp 2011-03-27 07:31:24 ssuominen dev-dotnet/podsleuth2011-03-27 07:31:24 ssuominen media-libs/libipoddevice2011-03-27 07:31:57 ssuominen sys-apps/halevt 2011-03-27 07:33:50 ssuominen dev-libs/boolstuff 2011-03-27 07:35:43 ssuominen sys-power/guidance-power-manager2011-03-27 07:45:26 ssuominen media-sound/phonon-gstreamer2011-03-27 12:39:27 dilfridge gnome-base/gnome-mount 2011-03-27 16:01:24 ssuominen sci-misc/brlcad 2011-03-27 18:32:24 dilfridge Additions: sci-chemistry/pymol-plugins-msms2011-03-22 08:33:08 jlec app-vim/slimv 2011-03-22 09:38:33 radhermit sci-chemistry/surf 2011-03-22 11:10:03 jlec media-libs/libwebp 2011-03-22 15:02:37 ssuominen media-fonts/montecarlo 2011-03-22 15:31:14 wired games-strategy/revenge-of-the-titans2011-03-22 17:20:12 vapier media-video/libav 2011-03-22 21:01:29 scarabeus sys-apps/baselayout-prefix 2011-03-23 08:00:48 grobian net-libs/openpgm2011-03-23 12:39:05 djc virtual/ffmpeg 2011-03-23 13:41:40 scarabeus net-libs/libdmapsharing 2011-03-23 22:51:57 eva net-fs/smbtad 2011-03-24 09:42:30 dagger net-fs/smbtatools 2011-03-24 09:44:08 dagger dev-php/phpdepend 2011-03-25 13:35:51 olemarkus dev-php/phpmd 2011-03-25 13:47:47 olemarkus dev-php/phploc 2011-03-25 13:53:02 olemarkus dev-python/pyodbc 2011-03-25 15:07:11 neurogeek dev-python/PyZilla 2011-03-26 05:52:10 vapier dev-php/php-tokenstream 2011-03-26 10:22:44 olemarkus dev-php/phpunit 2011-03-26 11:31:20 olemarkus dev-php/yaml2011-03-26 12:04:20 olemarkus sys-apps/biosdevname2011-03-26 12:15:27 aidecoe dev-php/phpcpd 2011-03-26 12:55:05 olemarkus media-libs/libechonest 2011-03-26 14:04:10 ssuominen sci-libs/inchi 2011-03-26 15:18:23 jlec sci-chemistry/openbabel-python 2011-03-26 15:34:19 jlec sci-chemistry/openbabel-perl2011-03-26 15:52:07 jlec media-libs/phonon 2011-03-26 16:07:01 dilfridge dev-php/xhprof 2011-03-26 18:02:29 olemarkus media-libs/phonon-gstreamer 2011-03-27 12:31:20 dilfridge app-emulation/vmware-tools 2011-03-27 15:22:22 vadimk media-gfx/brlcad2011-03-27 18:28:20 dilfridge dev-php/twig2011-03-27 20:29:15 olemarkus x11-themes/notify-osd-icons 2011-03-27 20:32:52 ssuominen sys-apps/stroke 2011-03-27 22:07:57 hwoarang -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-im/silc-plugin,removed,signals,2011-03-21 15:07:36 media-libs/libdjconsole,removed,ssuominen,2011-03-22 18:18:36 x11-misc/talika,removed,hwoarang,2011-03-24 12:04:41 sys-apps/inotail,removed,angelos,2011-03-24 15:13:14 games-puzzle/xphotohunter,removed,ssuominen,2011-03-24 18:12:29 games-kids/stickers,removed,ssuominen,2011-03-24 18:12:58 dev-php5/PEAR-PHP_TokenStream,removed,olemarkus,2011-03-26 11:39:04 dev-php5/phpunit,removed,olemarkus,2011-03-26 11:39:04 media-sound/phonon,removed,dilfridge,2011-03-26 17:56:57 app-cdr/pxlinux,removed,darkside,2011-03-27 04:18:06
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 02:39 Mon 28 Mar , Nirbheek Chauhan wrote: Where did this come from? My entire argument was based around the fact that unmaintained packages that may or may not be broken fundamentally constitute a *bad* experience for the user. If we cannot guarantee that bugs for a package will be fixed, we should not take up the responsibility of the package! Which is worse? Suddenly pulling a package from underneath the feet of users when it inevitably breaks or telling them upfront that it's *completely not* supported by us so they can do something about it before it breaks? Here's the key point: may or may not. Arbitrary criteria with no relevance to whether a package works for users are not helpful. The mere existence of a maintainer-needed package doesn't mean it should be removed. The existence of the same thing with numerous serious, unfixed bugs or tinderbox errors means something much different. We have the ability to do these kinds of intersections today, since our wonderful bug wranglers normally insert the $CAT/$PN into summaries and Diego has tinderbox bugs filed. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpjZzeJgz4hc.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 17:34 Sun 27 Mar , Ryan Hill wrote: On Mon, 28 Mar 2011 02:55:14 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: If we launch gstats *today*, it'll take us at least a long time before we get decent numbers, and even after that, those numbers will be biased towards those people who are really active in following Gentoo news and developments. Unlike Firefox's usage stats, we have no way of prompting pre-existing gentoo installations with a Do want to take part in gstats? question. Last I checked we had a nifty news system for making announcements. And I thought we were supposed to have Smolt support like two years ago. What happened to it? I wonder the same question too, since it seems statistics is an eternally returning GSoC project. Sebastian, you worked on this in 2009. What needs to happen to get it deployed? -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpxww8cShQhy.pgp Description: PGP signature
Re: [gentoo-dev] Re: rejecting unsigned commits
On 03/25/2011 14:30, Mike Frysinger wrote: for people who dont have a key yet: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6 for people interested, bugs to get repoman extended to make the gpg process smoother: http://bugs.gentoo.org/360459 http://bugs.gentoo.org/360461 -mike So I'm one of those that became a dev before GPG keys were required (I think). at some point, though, I created one on an old machine I had, which was my primary dev machine at the time. But the machine died, and I never got the key off (I never used it). The drive is still good, but it's lost in a pile of boxes somewhere. Rather than mounting an expedition to find it, it's probably easier for me to generate a new key, but this raises a few questions, because I'm a complete idiot when it comes to GPG/PGP stuff: 1. How can I revoke the old key? The revocation cert is probably on the same drive. 2. The dev manual states not to create a key with an expiration longer than 6 months. How does this impact items signed already if the key has to be replaced bi-annually? (I suspect I'm not fully grasping something here w/r to GPG). 3. If I'm going to start using GPG, I might as well use it for a few things. Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
[gentoo-dev] Lastrite openfoam-kernel and reverse dependencies.
# Samuli Suominen ssuomi...@gentoo.org (28 Mar 2011) # Masked for QA. # Not installable for almost an year now wrt bugs #326613, # #284921, #315411, #316515. Other minor bugs, #336126. # Removal in 30 days. sci-libs/openfoam-kernel sci-libs/openfoam-meta sci-libs/openfoam-solvers sci-libs/openfoam-utilities sci-libs/openfoam-src sci-libs/openfoam-wmake
