[gentoo-dev] Moving unmaintained packages to Sunrise
Hello, There are some packages which were 'readded' to the Sunrise overlay after lying unmaintained in the tree for a long time and finally being removed. One example could be net-im/ekg2 for removal of which I've been personally waiting. Although such a workflow 'works' indeed, for most of the users packages are just removed. Even if they use Sunrise, the delay of few days required in order to get the new ebuild rewritten and reviewed causes them to remove and forget about the package. And in fact, gx86 states it was 'removed'. Currently, the Sunrise policy states that there could be added only packages which are maintainer-wanted and thus not in gx86. For maintainer-needed, there is a proxy-commit mechanism but it's a little awkward, especially if the new ebuild is supposed to be written from scratch (like ekg2 one was). Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? In this case by 'unmaintained' I mean those which have open bugs assigned to 'maintainer-needed' for a long time, and are potentially a candidates for the treecleaning (not necessarily being in the removal queue yet). The particular Sunrise user wanting to maintain the package suggests moving it to Sunrise (to whom?). If developers agree on that, he is allowed to prepare the Sunrise ebuild and even commit it to the 'sunrise' (non-public) tree. When Sunrise dev does the final review, after which the package would be moved to 'reviewed' (public) tree, he/she also masks the original package in gx86 stating that the package is now maintained in Sunrise. After 30 (or more) days, the masked gx86 packages are removed as usual. The advantage of such a workflow is quite obvious -- instead of seeing 'removed' packages which they need to either copy to their own overlay or abandon, users are advised to add 'sunrise' to their repository list and use the user-maintained ebuild. And then the move is almost transparent to current Sunrise users. -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] Moving unmaintained packages to Sunrise
On 06/13/2010 10:41 AM, Michał Górny wrote: Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? In this case by 'unmaintained' I mean those which have open bugs assigned to 'maintainer-needed' for a long time, and are potentially a candidates for the treecleaning (not necessarily being in the removal queue yet). What's stopping you or any of the sunrise guys to pick up packages when treecleaners send the last rites? You have 30 days minimum, to get a new ebuild rolling before it gets the axe. Sounds like plenty of time to me. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Moving unmaintained packages to Sunrise
Michał Górny posted on Sun, 13 Jun 2010 10:41:43 +0200 as excerpted: Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? ++ I've thought something like that was needed for awhile, tho I'm not sure it fits the sunrise theme too well. But if not there, surely somewhere, and I see no reason to fragment overlays just for that, so sunrise is good. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On 06/11/2010 12:27 PM, Pacho Ramos wrote: 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. There's nothing preventing you from already doing this. package.use.mask is something package maintainers themselves should be looking after for their packages. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
If you start moving maintainer-needed package on Sunrise then Sunrise will end up as a garbage collector overlay having many many ebuilds that nobody will actually maintain. If you care about maintainer-needed package then step up and proxy maintain it. The delay ( which is not that big if you cooperate with an active developer/herd ) might be a drawback but still... I don't want sunrise to become a place where abandoned ebuilds will end up. On Sun, Jun 13, 2010 at 1:38 PM, Duncan 1i5t5.dun...@cox.net wrote: Michał Górny posted on Sun, 13 Jun 2010 10:41:43 +0200 as excerpted: Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? ++ I've thought something like that was needed for awhile, tho I'm not sure it fits the sunrise theme too well. But if not there, surely somewhere, and I see no reason to fragment overlays just for that, so sunrise is good. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] FW: [Bug 150091] app-forensics/samhain ebuild issues
If you care enough about this package, move it to sunrise or step up and proxy maintain it, cooperating with a developer http://overlays.gentoo.org/proj/sunrise/wiki/ProxyMaintainer On Sun, Jun 13, 2010 at 7:21 AM, sch...@subverted.org wrote: On Sat, Jun 12, 2010 at 11:04:26PM -0500, Jeremy Olexa wrote: Shortage of man power will do this, especially for maintainer-needed packages. It was not my intent to personally offend you regarding this package. I know no personal offense was intended, nor was any taken. There should be a bump, but it was just frustrating that the only issue that seemed to remain was an innocuous comment within the ebuild. If that wasn't enough, it would've been nice to know what the objections were before whacking it.
Re: [gentoo-dev] Suggestion related with dropping keywords policy
El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió: On 06/11/2010 12:27 PM, Pacho Ramos wrote: 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. There's nothing preventing you from already doing this. package.use.mask is something package maintainers themselves should be looking after for their packages. Regards, Petteri OK, thanks a lot :-D signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
media-video/avidemux Qt team will pick this up ( first herd on metadata.xml ) and I will add myself as maintainer Cheers On Sat, Jun 12, 2010 at 3:09 PM, Alex Alexander wi...@gentoo.org wrote: On Fri, Jun 11, 2010 at 11:50:38PM +0200, Ben de Groot wrote: 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: app-misc/vifm media-sound/ncmpcpp net-misc/wput ^^ I'll take these media-video/smplayer ^^ The Qt team will take care of this. I might add myself as a maintainter to give it some extra attention, we'll see. -- Alex Alexander :: wired Gentoo Developer www.linuxized.com
Re: [gentoo-dev] Moving unmaintained packages to Sunrise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13-06-2010 08:41, Michał Górny wrote: Hello, There are some packages which were 'readded' to the Sunrise overlay after lying unmaintained in the tree for a long time and finally being removed. One example could be net-im/ekg2 for removal of which I've been personally waiting. Although such a workflow 'works' indeed, for most of the users packages are just removed. Even if they use Sunrise, the delay of few days required in order to get the new ebuild rewritten and reviewed causes them to remove and forget about the package. And in fact, gx86 states it was 'removed'. Currently, the Sunrise policy states that there could be added only packages which are maintainer-wanted and thus not in gx86. For maintainer-needed, there is a proxy-commit mechanism but it's a little awkward, especially if the new ebuild is supposed to be written from scratch (like ekg2 one was). Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? In this case by 'unmaintained' I mean those which have open bugs assigned to 'maintainer-needed' for a long time, and are potentially a candidates for the treecleaning (not necessarily being in the removal queue yet). I think you might not have been around at that time, but when the sunrise overlay was created, there was a proposal to create a sunset overlay, like the java team used and now kde uses as well. The purpose of this overlay would be to keep the packages that are removed from the tree because they have no maintainers. As was discussed back then, the people wishing to work on sunrise are likely not interested in having all the removed packages dumped in their shoulders. Besides, sunrise is about packages that have an interested user submitting and hopefully maintaining ebuilds for new packages, while sunset is likely to become a dumping ground for stuff that we can't find anyone to take care of. If we want to find a way to not drop the maintainer-needed packages, I'd prefer we move them to sunset and not to sunrise. As this overlay is likely to become large, probably huge, and as it will host security vulnerable packages, we should evaluate whether we really want to host it and, if so, what measures to take to protect distracted users. I think package masking all the packages put there with links to relevant bugs might be a first step. The particular Sunrise user wanting to maintain the package suggests moving it to Sunrise (to whom?). If developers agree on that, he is allowed to prepare the Sunrise ebuild and even commit it to the 'sunrise' (non-public) tree. When Sunrise dev does the final review, after which the package would be moved to 'reviewed' (public) tree, he/she also masks the original package in gx86 stating that the package is now maintained in Sunrise. After 30 (or more) days, the masked gx86 packages are removed as usual. The advantage of such a workflow is quite obvious -- instead of seeing 'removed' packages which they need to either copy to their own overlay or abandon, users are advised to add 'sunrise' to their repository list and use the user-maintained ebuild. And then the move is almost transparent to current Sunrise users. The problem with the above is exposing users to potentially dangerous applications - from a security perspective. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMFOqSAAoJEC8ZTXQF1qEPVh0QAKT38JEDUHY4neIhQ44m5aeL sqZIfIULeVY4Xh5EaGJ/kS1cLyFuy+QXU2y/NLFWT7+DD9vPZiUGx/z90ph6irVC YURd9scd4SdDKJKv2vp56A0USPXfRqRxok6l1m2HvZaqMoV+WN9Y+WQ/wxcu69Ce 2hDUikABMwAazjA5GotfC7Wa5Aadk6+6fYVSMiCZAtpD35rq+9yLJ8wJFr0YQq50 1Cj/B2vyA90uXRG/wfWhetU+sOLsOoF0yGoINHMzRon6J8SgQr+5mLsQYL1JhcsK yNem0omoBB0qio4kihxT5L11n8rK2nesLr+ay93udfPc/0hHy6J6rK+ZCW5alG1r fARHgKcdU+HPwXKp2xhAJyo/ooHZFN32DhEfEE6RF5M2KS4wq2kNhLnh0mnMRjtV GhH3TWC8DFuMwZDFwYZs99G1biCmc4jaw7xyAx9Q3c60vB0UGeVPlCb73CwuE3we 5YHuEyG2TY7Xju7wGm/KLte70FUK+MynJL+yaF4fkxkVz7YzOSTMcEv9YgvWJ3kF aa1U1B6TQxEqqR2w734SNB3dE/BMyrWXvJ8WMfw63NpDRfkEVmC9ogarLvOtEjQ0 GQ9Id7hx85B+1+8LsKwrHJu09cEDsB7k0+l2AFGJ8llWX8ptBeYhZfLzhPzYllhB DEUzrXPW7/AyrLwpyU8j =7Q9z -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
On Sun, 13 Jun 2010 15:07:12 +0300 Markos Chandras hwoar...@gentoo.org wrote: If you start moving maintainer-needed package on Sunrise then Sunrise will end up as a garbage collector overlay having many many ebuilds that nobody will actually maintain. If you care about maintainer-needed package then step up and proxy maintain it. The delay ( which is not that big if you cooperate with an active developer/herd ) might be a drawback but still... I don't want sunrise to become a place where abandoned ebuilds will end up. But who's talking here about moving abandoned ebuilds just to keep them? I'd wanted just to make it simpler to switch the 'maintainership' from Gentoo devs to Sunrise users, when the second are ready to maintain the ebuild well. You may take a look at Sunrise net-im/ekg2 ebuild as an example. It has probably almost nothing in common with the original ebuild. It even uses an alternate build system, allows to fine-tune the build like not many packages do. Do you consider that an 'abandoned ebuild'? -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
We ( as treecleaners ) can't move the packages to sunrise. If there are users out there who want to maintain them either move the ebuilds on sunrise themselves or proxy maintain them. On Sun, Jun 13, 2010 at 7:35 PM, Michał Górny gen...@mgorny.alt.pl wrote: On Sun, 13 Jun 2010 15:07:12 +0300 Markos Chandras hwoar...@gentoo.org wrote: If you start moving maintainer-needed package on Sunrise then Sunrise will end up as a garbage collector overlay having many many ebuilds that nobody will actually maintain. If you care about maintainer-needed package then step up and proxy maintain it. The delay ( which is not that big if you cooperate with an active developer/herd ) might be a drawback but still... I don't want sunrise to become a place where abandoned ebuilds will end up. But who's talking here about moving abandoned ebuilds just to keep them? I'd wanted just to make it simpler to switch the 'maintainership' from Gentoo devs to Sunrise users, when the second are ready to maintain the ebuild well. You may take a look at Sunrise net-im/ekg2 ebuild as an example. It has probably almost nothing in common with the original ebuild. It even uses an alternate build system, allows to fine-tune the build like not many packages do. Do you consider that an 'abandoned ebuild'? -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru xmpp%3amgo...@jabber.ru
Re: [gentoo-dev] Re: Moving unmaintained packages to Sunrise
On 6/13/10 6:35 PM, Michał Górny wrote: But who's talking here about moving abandoned ebuilds just to keep them? I'd wanted just to make it simpler to switch the 'maintainership' from Gentoo devs to Sunrise users, when the second are ready to maintain the ebuild well. Can you suggest a specific plan or process how to do that? Please don't go into discussion no, the devs should do that vs no, the users should do that. Currently it seems the users can take the last-rited ebuilds and get them into sunrise. They can step up as proxy maintainers and prevent the package from getting tree-cleaned. There are many options, which can be used right now and have existed for months. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Moving unmaintained packages to Sunrise
Jorge Manuel B. S. Vicetto posted on Sun, 13 Jun 2010 14:26:26 + as excerpted: there was a proposal to create a sunset overlay, like the java team used and now kde uses as well. The purpose of this overlay would be to keep the packages that are removed from the tree because they have no maintainers. As was discussed back then, the people wishing to work on sunrise are likely not interested in having all the removed packages dumped in their shoulders. Besides, sunrise is about packages that have an interested user submitting and hopefully maintaining ebuilds for new packages, while sunset is likely to become a dumping ground for stuff that we can't find anyone to take care of. If we want to find a way to not drop the maintainer-needed packages, I'd prefer we move them to sunset and not to sunrise. As this overlay is likely to become large, probably huge, and as it will host security vulnerable packages, we should evaluate whether we really want to host it and, if so, what measures to take to protect distracted users. I think package masking all the packages put there with links to relevant bugs might be a first step. You obviously read the proposal differently than I did. MG can pop in and say what he intended, but as I read it, and why I said ++, is... We change the policy of sunrise, not to be a dumping ground for /all/ tree- cleaned packages, but to allow interested users who see that a package they're interested in is unmaintained, to add it to (the unpublic part of) sunrise before the package is removed and potentially before it's even masked for removal, such that it can be approved and ready to go public in sunrise at the same time it's removed (or even when masked for removal) from the main tree. So packages wouldn't be dumped there without a maintainer. The only ones that would qualify would be those where a user actively proposes to maintain them in sunrise, the idea being that in some instances (as with the posted example), they can be maintained better there than they can be proxy-maintained in-tree. Apparently, sunrise has been around long enough, now, that there has been at least one package that started in sunrise, was added to the tree, then the person who added it lost interest or retired... and now it's rotting in the tree, and the same user that put it in sunrise before is still interested in it and has updated ebuilds, etc, but can't easily get proxies to commit the new ebuilds to the tree. From my read, that was apparently what sparked the post and whole proposed change. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Moving unmaintained packages to Sunrise
On 06/13/2010 05:26 PM, Jorge Manuel B. S. Vicetto wrote: Wouldn't it be better to officially support moving unmaintained packages directly into Sunrise? In this case by 'unmaintained' I mean those which have open bugs assigned to 'maintainer-needed' for a long time, and are potentially a candidates for the treecleaning (not necessarily being in the removal queue yet). I think you might not have been around at that time, but when the sunrise overlay was created, there was a proposal to create a sunset overlay, like the java team used and now kde uses as well. We (java) still use it and call it junkyard. That's an adequate description for the quality of the overlay. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion related with dropping keywords policy
El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió: El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió: On 06/11/2010 12:27 PM, Pacho Ramos wrote: 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. There's nothing preventing you from already doing this. package.use.mask is something package maintainers themselves should be looking after for their packages. Regards, Petteri OK, thanks a lot :-D The problem is that hppa team seems to not allow others than they to edit their package.use.mask :-/, is there any special reason for it? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-php5/{creole,jargon}
# Matti Bickel m...@gentoo.org (13 Jun 2010) # Dead upstream (bug #321685) # Removal on 2010-07-13 dev-php5/jargon dev-php5/creole signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving unmaintained packages to Sunrise
On 06/13/10 16:26, Jorge Manuel B. S. Vicetto wrote: If we want to find a way to not drop the maintainer-needed packages, I'd prefer we move them to sunset and not to sunrise. Agreed. If there is a user-maintainer move to sunrise, if there isn't move to sunset. As this overlay is likely to become large, probably huge, and as it will host security vulnerable packages, we should evaluate whether we really want to host it and, if so, what measures to take to protect distracted users. I think package masking all the packages put there with links to relevant bugs might be a first step. We introduced a graveyard quality level to layman recently that allows for marking such repositories (and a split tree in the future). Quoting the current repositories.dtd: [..] quality (core|stable|testing|experimental|graveyard) #REQUIRED [..] So Layman can be made handling such a repo specially, say displaying certain warnings. Sebastian
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-06-13 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-06-13 23h59 UTC. Removals: x11-plugins/wmmsens 2010-06-07 10:05:44 s4t4n x11-plugins/wmsensormon 2010-06-07 10:10:25 s4t4n x11-plugins/wmalms 2010-06-07 10:15:57 s4t4n dev-util/cola 2010-06-08 08:21:06 dev-zero dev-cpp/Ice 2010-06-08 08:32:00 dev-zero dev-ruby/activerecord-jdbc 2010-06-12 19:36:35 graaff app-forensics/samhain 2010-06-12 20:02:58 darkside virtual/gnus2010-06-12 20:05:35 darkside mail-client/mozilla-thunderbird 2010-06-13 02:31:39 nirbheek dev-perl/ShadowHash 2010-06-13 06:45:47 tove media-plugins/quodlibet-trayicon2010-06-13 16:17:07 ssuominen Additions: app-emulation/ganeti-instance-image 2010-06-07 22:30:37 ramereth dev-vcs/cola2010-06-08 08:15:04 dev-zero dev-libs/Ice2010-06-08 08:25:34 dev-zero app-forensics/yasat 2010-06-08 09:19:24 hwoarang app-vim/bufferexplorer 2010-06-08 20:54:22 spatz sci-libs/superlu2010-06-09 08:18:58 jlec sci-libs/punc 2010-06-09 09:07:27 jlec dev-perl/Net-LDAPapi2010-06-09 11:33:33 dev-zero app-crypt/hmaccalc 2010-06-09 18:05:23 robbat2 sys-fs/lessfs 2010-06-09 21:01:49 hwoarang media-libs/jbig2dec 2010-06-10 09:00:48 ssuominen app-misc/scrub 2010-06-10 09:53:57 dev-zero net-wireless/iwl6000-ucode 2010-06-10 13:46:22 flameeyes media-libs/libvpx 2010-06-10 16:02:09 lu_zero sys-apps/9base 2010-06-11 16:24:26 ssuominen dev-ml/fort 2010-06-11 20:02:03 xarthisius app-i18n/ibus-mozc 2010-06-11 23:50:08 matsuu net-libs/dhcpcd-dbus2010-06-12 21:32:34 darkside net-misc/dhcpcd-ui 2010-06-12 21:35:25 darkside mail-client/thunderbird 2010-06-13 02:26:39 nirbheek dev-perl/Tie-ShadowHash 2010-06-13 06:43:00 tove media-plugins/mythnetvision 2010-06-13 07:06:24 cardoe gnome-base/libgnome-keyring 2010-06-13 18:29:41 pacho net-analyzer/synscan2010-06-13 21:46:49 ssuominen dev-util/gnome-devel-docs 2010-06-13 22:07:04 pacho dev-haskell/hpc 2010-06-13 22:14:27 kolmodin net-misc/pmsvn 2010-06-13 23:34:14 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: x11-plugins/wmmsens,removed,s4t4n,2010-06-07 10:05:44 x11-plugins/wmsensormon,removed,s4t4n,2010-06-07 10:10:25 x11-plugins/wmalms,removed,s4t4n,2010-06-07 10:15:57 dev-util/cola,removed,dev-zero,2010-06-08 08:21:06 dev-cpp/Ice,removed,dev-zero,2010-06-08 08:32:00 dev-ruby/activerecord-jdbc,removed,graaff,2010-06-12 19:36:35 app-forensics/samhain,removed,darkside,2010-06-12 20:02:58 virtual/gnus,removed,darkside,2010-06-12 20:05:35 mail-client/mozilla-thunderbird,removed,nirbheek,2010-06-13 02:31:39 dev-perl/ShadowHash,removed,tove,2010-06-13 06:45:47 media-plugins/quodlibet-trayicon,removed,ssuominen,2010-06-13 16:17:07 Added Packages: app-emulation/ganeti-instance-image,added,ramereth,2010-06-07 22:30:37 dev-vcs/cola,added,dev-zero,2010-06-08 08:15:04 dev-libs/Ice,added,dev-zero,2010-06-08 08:25:34 app-forensics/yasat,added,hwoarang,2010-06-08 09:19:24 app-vim/bufferexplorer,added,spatz,2010-06-08 20:54:22 sci-libs/superlu,added,jlec,2010-06-09 08:18:58 sci-libs/punc,added,jlec,2010-06-09 09:07:27 dev-perl/Net-LDAPapi,added,dev-zero,2010-06-09 11:33:33 app-crypt/hmaccalc,added,robbat2,2010-06-09 18:05:23 sys-fs/lessfs,added,hwoarang,2010-06-09 21:01:49 media-libs/jbig2dec,added,ssuominen,2010-06-10 09:00:48 app-misc/scrub,added,dev-zero,2010-06-10 09:53:57 net-wireless/iwl6000-ucode,added,flameeyes,2010-06-10 13:46:22 media-libs/libvpx,added,lu_zero,2010-06-10 16:02:09 sys-apps/9base,added,ssuominen,2010-06-11 16:24:26 dev-ml/fort,added,xarthisius,2010-06-11 20:02:03 app-i18n/ibus-mozc,added,matsuu,2010-06-11 23:50:08 net-libs/dhcpcd-dbus,added,darkside,2010-06-12 21:32:34 net-misc/dhcpcd-ui,added,darkside,2010-06-12 21:35:25 mail-client/thunderbird,added,nirbheek,2010-06-13 02:26:39 dev-perl/Tie-ShadowHash,added,tove,2010-06-13 06:43:00 media-plugins/mythnetvision,added,cardoe,2010-06-13 07:06:24 gnome-base/libgnome-keyring,added,pacho,2010-06-13 18:29:41 net-analyzer/synscan,added,ssuominen,2010-06-13 21:46:49
[gentoo-dev] Testing of Python 2.7
Final release of Python 2.7 is currently scheduled on 2010-07-03. Snapshots of Python 2.7 are available in python overlay. Python 2.7 will be initially masked in gentoo-x86 after release. I would like to encourage Gentoo developers and users to install a snapshot of Python 2.7 and test miscellaneous packages with Python 2.7. Please file bugs in Gentoo bugzilla, after ensuring that they don't occur with Python 2.6. There are already 22 bugs filed, so don't file duplicates. (I currently discourage using Python 3.2.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Mon, 14 Jun 2010 00:29:19 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió: El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió: On 06/11/2010 12:27 PM, Pacho Ramos wrote: 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. There's nothing preventing you from already doing this. package.use.mask is something package maintainers themselves should be looking after for their packages. Regards, Petteri OK, thanks a lot :-D The problem is that hppa team seems to not allow others than they to edit their package.use.mask :-/, is there any special reason for it? What is the problem? The files in place ask you to file a bug report instead of fiddling with the files yourselves. I put that in place because I got (fucking) tired of seeing the after effects of people fiddling with the arch profile files without 1) consideration, 2) informing the involved arch team. What do you expect? File a bloody bug report detailing the (commit) problem you are facing and you will probably see 1) response and 2) cooperation. If you fuck around with the arch profile files without doing any of that, you will face 1) a lack of willingness to cooperate and 2) evil wrath. Regards, jer
