Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 06.04.2013 20:08, Michał Górny wrote: Hello, As far as I'm aware, we don't really have much of a patch maintenance policy in Gentoo. There a few loose rules like «don't put awfully big files into FILESDIR» or the common sense «use unified diff», but no complete and clear policy. Especially considering the late discussion related to the needless and semi-broken functionality in epatch, I'd like to propose setting the following rules for patches in tree and in Gentoo-sourced patchsets: 1. Patches have to be either in unified or context diff format. Unified diff is preferred. 2. Patches have to apply to the top directory of the source tree with 'patch -p1'. If patches are applied to sub-directories, necessary '-p' argument shall be passed to 'epatch' explicitly. Developers are encouraged to create patches which are compatible with 'git am'. 3. Patches have to end with either '.patch' or '.diff' suffix. 4. If possible, patches shall be named in a way allowing them to be applied in lexical order. However, this one isn't necessary if patches from an older ebuild are applied to a newer one. 5. The patch name shall shortly summarize the changes done by it. 6. Patch files shall start with a brief description of what the patch does. Developers are encouraged to use git-style tags like 'Fixes:' to point to the relevant bug URIs. 7. Patch combining is discouraged. Developers shall prefer multiple patches following either the upstream commits or a logical commit sequence (if changes are not committed upstream). The above-listed policy will apply to the patches kept in the gx86 tree (in FILESDIRs) and patch archives created by Gentoo developers. They will not apply to the patch archives created upstream. Hi, there's at least one guideline written by the Ancient Ones that I know [1] It roughly follows the ideas that you've described. I think it'd be enough if people read it and used as a suggestion not a strict ruling. Imposing things like lexical order or git-style heading is a bit too much for me. Do we really need rules for everything? Cheers, Kacper [1] http://dev.gentoo.org/~vapier/clean-patches signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 7/04/2013 04:22, Markos Chandras wrote: On 6 April 2013 19:08, Michał Górny mgo...@gentoo.org wrote: Hello, ... What are your thoughts? Maybe it is time to setup a patch tracking system like Debian[1]? Sometimes it is really hard to understand what patches are applied by an ebuild (especially when all the build process is handled by an eclass) and/or when people keep a separate .tar.* with all the patches. Debian makes is so much easier to see what patches each package contains. [1]http://patch-tracker.debian.org/ -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang I have always found Debian's patch tracker very useful, I would definitely support us implementing something similar.
[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 7/04/2013 16:53, Kacper Kowalik wrote: On 06.04.2013 20:08, Michał Górny wrote: Hello, As far as I'm aware, we don't really have much of a patch maintenance policy in Gentoo. There a few loose rules like «don't put awfully big files into FILESDIR» or the common sense «use unified diff», but no complete and clear policy. Especially considering the late discussion related to the needless and semi-broken functionality in epatch, I'd like to propose setting the following rules for patches in tree and in Gentoo-sourced patchsets: 1. Patches have to be either in unified or context diff format. Unified diff is preferred. 2. Patches have to apply to the top directory of the source tree with 'patch -p1'. If patches are applied to sub-directories, necessary '-p' argument shall be passed to 'epatch' explicitly. Developers are encouraged to create patches which are compatible with 'git am'. 3. Patches have to end with either '.patch' or '.diff' suffix. 4. If possible, patches shall be named in a way allowing them to be applied in lexical order. However, this one isn't necessary if patches from an older ebuild are applied to a newer one. 5. The patch name shall shortly summarize the changes done by it. 6. Patch files shall start with a brief description of what the patch does. Developers are encouraged to use git-style tags like 'Fixes:' to point to the relevant bug URIs. 7. Patch combining is discouraged. Developers shall prefer multiple patches following either the upstream commits or a logical commit sequence (if changes are not committed upstream). The above-listed policy will apply to the patches kept in the gx86 tree (in FILESDIRs) and patch archives created by Gentoo developers. They will not apply to the patch archives created upstream. Hi, there's at least one guideline written by the Ancient Ones that I know [1] It roughly follows the ideas that you've described. I think it'd be enough if people read it and used as a suggestion not a strict ruling. Imposing things like lexical order or git-style heading is a bit too much for me Do we really need rules for everything? Cheers, Kacper [1] http://dev.gentoo.org/~vapier/clean-patches We already have policy regarding patches[1], this just expands and formalises it a bit more. Regarding lexical order and git-style headings, my interpretation is that this is a recommendation only. I don't think the intention is to make you rebase complex patches needlessly. vapier's clean-patches document is an informative read, but I don't think devspace is a good method of disseminating of information that may not necessarily reflect the reality of the project. [1]: http://devmanual.gentoo.org/ebuild-writing/misc-files/patches/index.html
[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 7/04/2013 07:01, Robin H. Johnson wrote: On Sat, Apr 06, 2013 at 08:08:43PM +0200, Michał Górny wrote: The above-listed policy will apply to the patches kept in the gx86 tree (in FILESDIRs) and patch archives created by Gentoo developers. They will not apply to the patch archives created upstream. What about patches created by upstream, but stored in the FILESDIR (eg from upstream mailing lists, bugfixes before the next release). We want to keep them intact and not respin them. What sort of respinning are you concerned about? It seems that each point could be addressed trivially with a text editor.
Re: [gentoo-dev] [PATCHES] multilib-build: public API for header wrapping
On Thu, 4 Apr 2013 22:50:46 +0200 Michał Górny mgo...@gentoo.org wrote: Following the introduction of header wrapping in autotools-multilib, I'm submitting two patches: one providing a public API for it in multilib-build, and the other one using it in multilib-minimal. Both patches will be sent in reply to this mail. Rebased on the tree without the $ABI-$MULTILIB_ABI patch, and committed. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On Mon, Apr 08, 2013 at 12:36:36AM +1000, Michael Palimaka wrote: On 7/04/2013 07:01, Robin H. Johnson wrote: On Sat, Apr 06, 2013 at 08:08:43PM +0200, Michał Górny wrote: The above-listed policy will apply to the patches kept in the gx86 tree (in FILESDIRs) and patch archives created by Gentoo developers. They will not apply to the patch archives created upstream. What about patches created by upstream, but stored in the FILESDIR (eg from upstream mailing lists, bugfixes before the next release). We want to keep them intact and not respin them. What sort of respinning are you concerned about? It seems that each point could be addressed trivially with a text editor. The -p1 directive primarily. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] news item -- baselayout-1.x deprecation final warning
All, We have continued support for baselayout-1 to baselayout-2/OpenRc migration for almost two years now, so I think it is about time we kill this off. Here is the news item I want to send out on 10 Apr. Let me know what you think. Thanks, William Title: baselayout-1.x deprecation final warning Author: William Hubbs willi...@gentoo.org Content-Type: text/plain Posted: 2013-04-10 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/baselayout-2 WARNING! THIS NEWS ITEM REQUIRES IMMEDIATE ATTENTION! On 28 Jun 2011, baselayout-2.x and OpenRC were first marked stable on all supported architectures in Gentoo Linux. Although we no longer support baselayout-1, we have continued support for migration from baselayout-1 to baselayout-2 and OpenRc. According to Gentoo policy, the support for migration from baselayout-1 to baselayout-2 could end on 28 Jun 2012, a year after OpenRc became stable. This is your final warning. OpenRc-0.11.8 will be the final release of OpenRc to support migration from baselayout-1. If you do not upgrade your systems to openrc-0.11.8 before it leaves the tree, you may need to reinstall them. For questions about how to migrate your system, see the OpenRC migration guide [1]. [1] http://www.gentoo.org/doc/en/openrc-migration.xml pgpXGgYsG3tG_.pgp Description: PGP signature
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
On 07/04/13 03:36 PM, William Hubbs wrote: According to Gentoo policy, the support for migration from baselayout-1 to baselayout-2 could end on 28 Jun 2012, a year after OpenRc became stable. could end sounds a bit awkward. Try was slated to end or perhaps could have ended. Be more consistent: it's either OpenRC, OpenRc (?) or openrc. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
On 2013.04.07 20:36, William Hubbs wrote: All, We have continued support for baselayout-1 to baselayout-2/OpenRc migration for almost two years now, so I think it is about time we kill this off. Here is the news item I want to send out on 10 Apr. Let me know what you think. Thanks, William quote If you do not upgrade your systems to openrc-0.11.8 before it leaves the tree, you may need to reinstall them. /quote I think you mean If you do not upgrade your systems to baselayout-2 and openrc-0.11.8 before openrc-0.11.8 leaves the tree, you may need to reinstall them. The problem is with baselayout-1 and that's what needs to be updated. The you may need to reinstall them is a bit over the top. You can always pick up the pieces with a liveCD. Do you need to point out that the old ( ... ) syntax will no longer be supported, or do you intend to tolerate the baselayout-1 syntax in /etc/conf.d/net and friends a while longer. A friendly link to the update guide http://www.gentoo.org/doc/en/openrc-migration.xml may be in order too. I've seen many users on baselayout-2 with baselayout-1 net files. This news item will bypass them. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpUphhQvpZpg.pgp Description: PGP signature
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
Notably, NetworkManager generates old-style net files. On 07/04/13 04:13 PM, Roy Bamford wrote: On 2013.04.07 20:36, William Hubbs wrote: All, We have continued support for baselayout-1 to baselayout-2/OpenRc migration for almost two years now, so I think it is about time we kill this off. Here is the news item I want to send out on 10 Apr. Let me know what you think. Thanks, William quote If you do not upgrade your systems to openrc-0.11.8 before it leaves the tree, you may need to reinstall them. /quote I think you mean If you do not upgrade your systems to baselayout-2 and openrc-0.11.8 before openrc-0.11.8 leaves the tree, you may need to reinstall them. The problem is with baselayout-1 and that's what needs to be updated. The you may need to reinstall them is a bit over the top. You can always pick up the pieces with a liveCD. Do you need to point out that the old ( ... ) syntax will no longer be supported, or do you intend to tolerate the baselayout-1 syntax in /etc/conf.d/net and friends a while longer. A friendly link to the update guide http://www.gentoo.org/doc/en/openrc-migration.xml may be in order too. I've seen many users on baselayout-2 with baselayout-1 net files. This news item will bypass them. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Python 2.7.4, 3.2.4, 3.3.1 updates
I will be adding these versions to the tree over the next few days, initially masked. The 2.7 and 3.2 bumps should be nothing major, but better safe then sorry. Please give them a try if you have time. We should be able to unmask these pretty quickly. One question for the community: Does anyone have a strong objection to using EAPI 5 in the Python 2.7.4 ebuild? If so, I would like to know your reasons. This seems like a good opportunity to add slot operator deps and remove some prefix workarounds. We can keep an old ebuild around to facilitate upgrades if we need to. We (the python team) still need to work out a plan for unmasking 3.3. That will happen in the next few weeks I imagine.
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
On Sun, Apr 07, 2013 at 04:37:42PM -0400, Alex Xu wrote: On 07/04/13 04:13 PM, Roy Bamford wrote: On 2013.04.07 20:36, William Hubbs wrote: If you do not upgrade your systems to openrc-0.11.8 before it leaves the tree, you may need to reinstall them. /quote I think you mean If you do not upgrade your systems to baselayout-2 and openrc-0.11.8 before openrc-0.11.8 leaves the tree, you may need to reinstall them. The problem is with baselayout-1 and that's what needs to be updated. The you may need to reinstall them is a bit over the top. You can always pick up the pieces with a liveCD. That's why I said may. I haven't attempted that migration manually, so I don't know how easy or difficult it would be. You may be able to do that, but you will be basically on your own to figure it out. Do you need to point out that the old ( ... ) syntax will no longer be supported, or do you intend to tolerate the baselayout-1 syntax in /etc/conf.d/net and friends a while longer. Notably, NetworkManager generates old-style net files. This issue with the conf.d/net syntax is a separate one and will be handled later. A friendly link to the update guide http://www.gentoo.org/doc/en/openrc-migration.xml may be in order too. This is already there. I've seen many users on baselayout-2 with baselayout-1 net files. This news item will bypass them. That is ok, I am just talking about the automatic support for the Migration. William pgpPAF1klWAH1.pgp Description: PGP signature
[gentoo-dev] Automagic pax-mark
Hello All, After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no longer has a || die. This means that the resulting binaries may have PT_PAX, XATTR_PAX, both or neither markings depending on kernel configuration, filesystem and mount options. I'd say that is not a good thing. If you agree with me, what could be done here? Have pax-mark die in the eclass or mandate || die in ebuilds? This would probably require pax-mark calls to be conditional on pax_kernel USE flag or similar. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Automagic pax-mark
On Sun, Apr 7, 2013 at 5:11 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Hello All, After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no longer has a || die. This means that the resulting binaries may have PT_PAX, XATTR_PAX, both or neither markings depending on kernel configuration, filesystem and mount options. I'd say that is not a good thing. If you agree with me, what could be done here? Have pax-mark die in the eclass or mandate || die in ebuilds? This would probably require pax-mark calls to be conditional on pax_kernel USE flag or similar. Most ebuilds do not call pax-mark || die. Most people do not run PaX systems, so a failure here is not a major issue. I would like to see the kernel patch enabling user.pax attributes on tmpfs submitted to Linus' kernel tree; that would eliminate the major cause of failures here. In the mean time, maybe we could disable XATTR_PAX markings by default for people not using the hardened profile.
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
All, here is the second draft. I am including updates from this thread as well as a couple of my own. Let me know what you think. Thanks, William Title: baselayout-1.x deprecation final warning Author: William Hubbs willi...@gentoo.org Content-Type: text/plain Posted: 2013-04-10 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/baselayout-2 WARNING! THIS NEWS ITEM REQUIRES IMMEDIATE ATTENTION! On 28 Jun 2011, baselayout-2.x and OpenRC were first marked stable on all supported architectures in Gentoo Linux. Although we no longer support baselayout-1.x, we have continued support for migration from baselayout-1.x to baselayout-2.x and OpenRC. According to Gentoo policy, the support for migration was slated to end on 28 Jun 2012, a year after OpenRC was first marked stable. This is your final warning. openrc-0.11.8 will be the final release of OpenRC to support migration from baselayout-1.x. If you do not upgrade your system to baselayout-2.x and openrc-0.11.8 before openrc-0.11.8 leaves the tree, you will have to perform the migration manually when you upgrade or you will be left with an unbootable system. Manual migration is not officially supported, and could include fixing things with a live cd or re-installing your system. For questions about how to migrate your system, see the OpenRC migration guide [1]. [1] http://www.gentoo.org/doc/en/openrc-migration.xml pgpImX2BOMZsE.pgp Description: PGP signature
Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning
On Sun, Apr 07, 2013 at 04:06:40PM -0500, William Hubbs wrote: That's why I said may. I haven't attempted that migration manually, so I don't know how easy or difficult it would be. You may be able to do that, but you will be basically on your own to figure it out. I did it on a really old box yesterday. It's a little bumpy since I can't reboot the box all yet, so it's not entirely done. 21:51:38 up 1035 days, 15:04, 2 users, load average: 2.24, 1.70, 1.31 It went from sys-apps/baselayout-1.12.14-r1 to sys-apps/baselayout-2.1-r1. Still has kernel 2.6.11, glibc-2.10.1-r1, sys-fs/udev-151-r4, sys-apps/coreutils-8.7 Rough guide: 1. Make your own /run and mount it beforehand. 2. Grab a list of ALL services that are running to a file. You won't be able to do this later. 3. Upgrade the package. 4. Update your configs, esp hwclock/clock, and ensure clocks are good. 5. echo default /run/openrc/softlevel 6. For each service from #2, touch /run/openrc/started/$SERVICE 7. rc-update -u 8. Check that all your services are still good. The kernel/udev/glibc/coreutils upgrade is going to be a little bit more fun. Disclaimer for the foolhardy: I have taken on consulting in the past on upgrading ancient Gentoo servers to latest, with minimal downtime or breakage; my record is a box with updates more than 6 years prior. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Re: news item -- baselayout-1.x deprecation final warning
(apologies to those who got this twice - my MUA used a from address that the list likely rejected instead of using the correct one which I actually did select - Google needs to fix their GMail Android app) On Sun, Apr 7, 2013 at 3:36 PM, William Hubbs willi...@gentoo.org wrote: We have continued support for baselayout-1 to baselayout-2/OpenRc migration for almost two years now, so I think it is about time we kill this off. I would drop the first three paragraphs and the first sentence of the fourth. Keep it to the news, not the justification. Rich
Re: [gentoo-dev] Automagic pax-mark
On 04/07/2013 05:20 PM, Mike Gilbert wrote: On Sun, Apr 7, 2013 at 5:11 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Hello All, After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no longer has a || die. This means that the resulting binaries may have PT_PAX, XATTR_PAX, both or neither markings depending on kernel configuration, filesystem and mount options. I'd say that is not a good thing. If you agree with me, what could be done here? Have pax-mark die in the eclass or mandate || die in ebuilds? This would probably require pax-mark calls to be conditional on pax_kernel USE flag or similar. Most ebuilds do not call pax-mark || die. Most people do not run PaX systems, so a failure here is not a major issue. I would like to see the kernel patch enabling user.pax attributes on tmpfs submitted to Linus' kernel tree; that would eliminate the major cause of failures here. In the mean time, maybe we could disable XATTR_PAX markings by default for people not using the hardened profile. You can disable either or both type of pax markings by setting PAX_MARKINGS. We can change the default in the eclass. Its currently set to PT XT. Setting it to PT would revert to only doing PT_PAX markings. Then users will have to manually set XT in their make.conf. I can try to get the user.pax on tmpfs patch into the Linux tree. At the very least, we can get it into gentoo-sources. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Automagic pax-mark
On Sun, 07 Apr 2013 18:08:41 -0400 Anthony G. Basile bluen...@gentoo.org wrote: I can try to get the user.pax on tmpfs patch into the Linux tree. At the very least, we can get it into gentoo-sources. What does this patch do? I haven't been following this discussion; also, please CC ker...@gentoo.org when you report this so we can track. On a side note, stabilization in the 3.8 branch is not far away; I am expecting this to happen somewhere in the second half of this month. If you want the patch to be present in the stabilized 3.8 branch kernel, it would be nice to have the patch before then. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] libpng 1.6 upgrade and subslotting (and misuse of subslotting when there is also normal slotting)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/13 10:33 AM, Alexis Ballier wrote: On Fri, 05 Apr 2013 22:18:22 -0400 Ian Stakenvicius a...@gentoo.org wrote: Revbump -- very important in this case, as the slot-operator dep (iirc) does not take effect to allow sub-slot-triggered until after a version with the slot-operator has been emerged. So we want users to re-emerge packages either at the same time libpng-1.6 hits the tree, or beforehand so that they will be triggered for rebuild when libpng-1.6 hits. so we force two rebuilds instead of one ? Either we time it so they just rebuild at the same time (ie when the package is unmasked or stable-keyworded), or we commit the revbump earlier which would force a superfluous rebuild. Technically there could (in theory at least) be a way of rewriting the vdb to have the correct sub-slot entries (i had a script that did this during my EAPI=4-slot-abi testing) but this isn't particularily safe and would probably cause more issues for end users than the libpng-1.6 bump WITHOUT slot-operatored rdeps. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlFiChMACgkQ2ugaI38ACPBtYAD/YWxxprE1szh2meJVBt16Q+8x it+AvHEbMiRetCHchoUA/R0Nkw0Tg6zrx0jO/RgA5U4/H6GGWZUO27VYz8TFu5ae =yIRc -END PGP SIGNATURE-
Re: [gentoo-dev] Automagic pax-mark
On 04/07/2013 07:01 PM, Tom Wijsman wrote: On Sun, 07 Apr 2013 18:08:41 -0400 Anthony G. Basile bluen...@gentoo.org wrote: I can try to get the user.pax on tmpfs patch into the Linux tree. At the very least, we can get it into gentoo-sources. What does this patch do? I haven't been following this discussion; also, please CC ker...@gentoo.org when you report this so we can track. On a side note, stabilization in the 3.8 branch is not far away; I am expecting this to happen somewhere in the second half of this month. If you want the patch to be present in the stabilized 3.8 branch kernel, it would be nice to have the patch before then. Currently tmpfs only supports XATTR_SECURITY and XATTR_TRUSTED namespaces. Take a look at mm/shmem.c, particularly shmem_xattr_validate() around line 2112. But we're putting XATTR_PAX markings in the user namespace, actually a subspace of it, user.pax. Since we need to preserve XATTR_PAX flags as portage moves stuff around, we need to expand the allowed xattr namespace for tmpfs. That's what this patch does. I originally wanted in gentoo-sources, but there was concern --- I forget who. Pushing it upstream may be hard because upstream doesn't respect PaX. I can still try. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-04-07 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-04-07 23h59 UTC. Removals: kde-misc/print-manager 2013-04-01 14:00:36 kensington dev-python/pyutp2013-04-07 09:08:13 ssuominen dev-php/PEAR-PEAR_PackageFileManager_Cli2013-04-07 18:10:25 olemarkus sys-auth/polkit-kde 2013-04-07 19:05:56 kensington Additions: dev-python/django-select2 2013-04-01 17:38:24 prometheanfire dev-haskell/chasingbottoms 2013-04-02 07:26:52 gienah dev-perl/Test-Command-Simple2013-04-02 08:18:01 pinkbyte dev-haskell/file-embed 2013-04-02 11:49:34 gienah dev-haskell/data-default2013-04-02 12:45:54 gienah dev-perl/Data-Diver 2013-04-03 08:30:19 pinkbyte dev-haskell/data-default-class 2013-04-03 11:27:05 gienah dev-haskell/data-default-instances-base 2013-04-03 11:27:40 gienah dev-haskell/data-default-instances-containers 2013-04-03 11:28:12 gienah dev-haskell/data-default-instances-dlist2013-04-03 11:28:50 gienah dev-haskell/data-default-instances-old-locale 2013-04-03 11:29:29 gienah sci-chemistry/nmrglue 2013-04-04 18:22:57 jlec gnustep-apps/cynthiune 2013-04-04 18:34:43 voyageur app-i18n/qimhangul 2013-04-06 02:14:11 naota app-text/deplate2013-04-06 04:06:11 naota media-sound/din 2013-04-06 09:50:00 radhermit -- 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: kde-misc/print-manager,removed,kensington,2013-04-01 14:00:36 dev-python/pyutp,removed,ssuominen,2013-04-07 09:08:13 dev-php/PEAR-PEAR_PackageFileManager_Cli,removed,olemarkus,2013-04-07 18:10:25 sys-auth/polkit-kde,removed,kensington,2013-04-07 19:05:56 Added Packages: dev-python/django-select2,added,prometheanfire,2013-04-01 17:38:24 dev-haskell/chasingbottoms,added,gienah,2013-04-02 07:26:52 dev-perl/Test-Command-Simple,added,pinkbyte,2013-04-02 08:18:01 dev-haskell/file-embed,added,gienah,2013-04-02 11:49:34 dev-haskell/data-default,added,gienah,2013-04-02 12:45:54 dev-perl/Data-Diver,added,pinkbyte,2013-04-03 08:30:19 dev-haskell/data-default-class,added,gienah,2013-04-03 11:27:05 dev-haskell/data-default-instances-base,added,gienah,2013-04-03 11:27:40 dev-haskell/data-default-instances-containers,added,gienah,2013-04-03 11:28:12 dev-haskell/data-default-instances-dlist,added,gienah,2013-04-03 11:28:50 dev-haskell/data-default-instances-old-locale,added,gienah,2013-04-03 11:29:29 sci-chemistry/nmrglue,added,jlec,2013-04-04 18:22:57 gnustep-apps/cynthiune,added,voyageur,2013-04-04 18:34:43 app-i18n/qimhangul,added,naota,2013-04-06 02:14:11 app-text/deplate,added,naota,2013-04-06 04:06:11 media-sound/din,added,radhermit,2013-04-06 09:50:00 Done.
Re: [gentoo-dev] libpng 1.6 upgrade and subslotting (and misuse of subslotting when there is also normal slotting)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/13 11:27 AM, Ciaran McCreesh wrote: I concurr. Plus it was decided a couple of months back that everyone should revbump or version bump when migrating to EAPI5 (if not all future EAPIs). The main issue, as I recall, with libpng system updates is that a regular system-update-and-revdep-rebuild tends to fail because packages need to be rebuilt during the middle of the system update. Although this IS manageable even for green end-users with a bit of hand-holding, ideally we want to avoid it as much as possible. AFAICT, it's just a matter of timing the migration of rdeps we bump to EAPI5 and slot-operator deps. If we wanted to, we could: 1. revbump-and-p.mask ~arch packages, and the unmask them all when libpng-1.6 is unmasked -- a common, grep'able comment in p.mask could be used to indicate this list of package atoms. 2. ~arch-keyword a revbump of stable packages, and mass-stabilize when libpng-1.6 goes stable. A tracker bug would probably be best for this. And of course, if the package has an update for other reasons in the meantime, then they can just hit the tree as per normal and be removed from the list(s) above. Thoughts? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlFiEJIACgkQ2ugaI38ACPCmWAD/UPXBQd0JwmK++UeZKfbaUK6w tBkv+9sGVkQoJ3rGMfwA/ivRzMbrKJFoLH7TAsi0lGvIL4AQrgkVVv02oFKgRpaP =u0Qx -END PGP SIGNATURE-
Re: [gentoo-dev] Python 2.7.4, 3.2.4, 3.3.1 updates
Dear Mike, Mike Gilbert flop...@gentoo.org writes: This seems like a good opportunity to add slot operator deps and remove some prefix workarounds. We can keep an old ebuild around to facilitate upgrades if we need to. What kind of prefix workaround are you referring to? This reminds me that Prefix team is maintaining aqua support (GUI for Mac OS X) in Python in their own overlay for a long time. I'd like to see it merged to gx86. If feasible, I am going to run out a patch for review. Cheers, Benda
Re: [gentoo-dev] Python 2.7.4, 3.2.4, 3.3.1 updates
On Sun, Apr 7, 2013 at 9:14 PM, heroxbd hero...@gentoo.org wrote: Dear Mike, Mike Gilbert flop...@gentoo.org writes: This seems like a good opportunity to add slot operator deps and remove some prefix workarounds. We can keep an old ebuild around to facilitate upgrades if we need to. What kind of prefix workaround are you referring to? Nothing too exciting; just some logic to define EPREFIX in EAPI 2. A simple upgrade to EAPI 3 would suffice for that. This reminds me that Prefix team is maintaining aqua support (GUI for Mac OS X) in Python in their own overlay for a long time. I'd like to see it merged to gx86. If feasible, I am going to run out a patch for review. Sounds good to me. Is it something that can be submitted upstream, at least for Python 3.3+?
