Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
Feature request: Can we add a double-inclusion detector for profiles to repoman? If it's not too noisy. Right now, profiles.desc contains 83 profiles with double inclusions like this. See attached data and scripts. Looks nice! 'desktop/*' thing needs serious effort to restructure that. If teams are willing to make things saner, I would go for warning addition (maybe, guarded by --include-dev option). Seems they don't. Ran 'profile-double-inclusion.py' and got similar results. The script is rather slow to use on per-commit basis. Maybe it's worth putting on http://qa-reports.gentoo.org/ ? -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
On Sun, 12 Feb 2012 12:40:04 -0800 Zac Medico zmed...@gentoo.org wrote: On 02/12/2012 10:15 AM, Sergei Trofimovich wrote: Feature request: Can we add a double-inclusion detector for profiles to repoman? If it's not too noisy. Right now, profiles.desc contains 83 profiles with double inclusions like this. See attached data and scripts. Looks nice! 'desktop/*' thing needs serious effort to restructure that. If teams are willing to make things saner, I would go for warning addition (maybe, guarded by --include-dev option). some mips profiles are scary too: http://dev.gentoo.org/~slyfox/profiles_mips.png Another alternative would be to skip double-inclusion of identical profiles at the portage level, but it sounds very fragile and counterintuitive. Maybe, a bit less fragile, than current state. -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
On 02/13/2012 08:16 AM, Sergei Trofimovich wrote: Another alternative would be to skip double-inclusion of identical profiles at the portage level, but it sounds very fragile and counterintuitive. Maybe, a bit less fragile, than current state. Either way is prone to unintended results, so it's better to fix the root problem which is poor profile structuring. If we did skip the double-inclusions automatically, then that would be a PMS change, and I doubt that any of the PMS folks would be in favor of it. -- Thanks, Zac
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
On Mon, Feb 13, 2012 at 11:16 AM, Sergei Trofimovich sly...@gentoo.org wrote: some mips profiles are scary too: http://dev.gentoo.org/~slyfox/profiles_mips.png Weird. I'll take a look at that.
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
Looks like 'arch/amd64/no-multilib' profile inclusion is kept in sync with 'features/64bit-native' one: [1]. Exception is 'hardened/linux/amd64/no-multilib' profile. Looks like a bug. Synced this bit with a fix: | 11 Feb 2012; Sergei Trofimovich sly...@gentoo.org | hardened/linux/amd64/no-multilib/parent: | Make hardened/linux/amd64/no-multilib include arch/amd64/no-multilib | (http://archives.gentoo.org/gentoo-dev/msg_7c41ab6653426048c2e8b0f271637bf3.x | ml). And the change brought the breakage: New profiles popped up: | /usr/portage/profiles/arch/base | /usr/portage/profiles/features/multilib | /usr/portage/profiles/features/multilib/lib32 Likely because of double inclusion of some suspicious parent profiles. Reverted the change :[ Zorry and blueness helped me to investigated the issue further. 'default/linux/amd64/10.0/no-multilib' contains duplicate inheritance chain: Simple script [1] shows us profile loading order: /subvolumes/gentoo-portage/profiles/base /subvolumes/gentoo-portage/profiles/default/linux /subvolumes/gentoo-portage/profiles/arch/base /subvolumes/gentoo-portage/profiles/features/multilib /subvolumes/gentoo-portage/profiles/features/multilib/lib32 /subvolumes/gentoo-portage/profiles/arch/amd64 /subvolumes/gentoo-portage/profiles/default/linux/amd64 /subvolumes/gentoo-portage/profiles/releases /subvolumes/gentoo-portage/profiles/releases/10.0 /subvolumes/gentoo-portage/profiles/default/linux/amd64/10.0 /subvolumes/gentoo-portage/profiles/arch/base /subvolumes/gentoo-portage/profiles/features/multilib /subvolumes/gentoo-portage/profiles/features/multilib/lib32 /subvolumes/gentoo-portage/profiles/arch/amd64 /subvolumes/gentoo-portage/profiles/arch/amd64/no-multilib /subvolumes/gentoo-portage/profiles/features/64bit-native /subvolumes/gentoo-portage/profiles/default/linux/amd64/10.0/no-multilib What we see here is repeating block: /subvolumes/gentoo-portage/profiles/arch/base /subvolumes/gentoo-portage/profiles/features/multilib /subvolumes/gentoo-portage/profiles/features/multilib/lib32 /subvolumes/gentoo-portage/profiles/arch/amd64 /subvolumes/gentoo-portage/profiles/default/linux/amd64 which can rollback all changes introduced by the profiles: /subvolumes/gentoo-portage/profiles/releases /subvolumes/gentoo-portage/profiles/releases/10.0 /subvolumes/gentoo-portage/profiles/default/linux/amd64/10.0 Does not sound like a good thing. For those who can't read: http://dev.gentoo.org/~slyfox/profiles_default.png Notice the 'arch/amd64' inheritance both by 'arch/amd64/no-multilib' 'default/linux/amd64' I think 'arch/amd64/no-multilib' does not need any parents as any profile belongs to some arch, so pulls it explicitely. Even thing like prefix (has the same double-inclusion feature as well): http://dev.gentoo.org/~slyfox/profiles_prefix.png I suggest to: - drop 'parents' for 'profiles/arch/amd64/no-multilib' - [optionally] move 'profiles/arch/amd64/no-multilib' to 'features/amd64-no-multilib' - and 'profiles/arch/amd64/no-multilib' back to 'hardened/linux/amd64/no-multilib' It would state explicitely that it does not inherit anything. [ Another option would be to simplify 'default/linux/amd64' thing not to include 'profiles/arch' ] Thoughts? Feature request: Can we add a double-inclusion detector for profiles to repoman? Thanks for your patience! [1] #!/usr/bin/env python import portage for p in portage.settings.profiles: print %s % p -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
On 02/12/2012 10:15 AM, Sergei Trofimovich wrote: Feature request: Can we add a double-inclusion detector for profiles to repoman? If it's not too noisy. Right now, profiles.desc contains 83 profiles with double inclusions like this. See attached data and scripts. -- Thanks, Zac default/linux/alpha/10.0/desktop/gnome targets/desktop default/linux/alpha/10.0/desktop/kdetargets/desktop default/linux/amd64/10.0/desktop/gnome targets/desktop default/linux/amd64/10.0/desktop/kdetargets/desktop default/linux/amd64/10.0/no-multilibarch/amd64 arch/base features/multilib features/multilib/lib32 default/linux/arm/10.0/armv4arch/armarch/base default/linux/arm/10.0/armv4/desktoparch/armarch/base default/linux/arm/10.0/armv4/desktop/gnome arch/armarch/base targets/desktop default/linux/arm/10.0/armv4/desktop/kdearch/armarch/base targets/desktop default/linux/arm/10.0/armv4/developer arch/armarch/base default/linux/arm/10.0/armv4/server arch/armarch/base default/linux/arm/10.0/armv4t arch/armarch/base default/linux/arm/10.0/armv4t/desktop arch/armarch/base default/linux/arm/10.0/armv4t/desktop/gnome arch/armarch/base targets/desktop default/linux/arm/10.0/armv4t/desktop/kde arch/armarch/base targets/desktop default/linux/arm/10.0/armv4t/developer arch/armarch/base default/linux/arm/10.0/armv4t/serverarch/armarch/base default/linux/arm/10.0/armv5te arch/armarch/base default/linux/arm/10.0/armv5te/desktop arch/armarch/base default/linux/arm/10.0/armv5te/desktop/gnomearch/armarch/base targets/desktop default/linux/arm/10.0/armv5te/desktop/kde arch/armarch/base targets/desktop default/linux/arm/10.0/armv5te/developerarch/armarch/base default/linux/arm/10.0/armv5te/server arch/armarch/base default/linux/arm/10.0/armv6j arch/armarch/base default/linux/arm/10.0/armv6j/desktop arch/armarch/base default/linux/arm/10.0/armv6j/desktop/gnome arch/armarch/base targets/desktop default/linux/arm/10.0/armv6j/desktop/kde arch/armarch/base targets/desktop default/linux/arm/10.0/armv6j/developer arch/armarch/base default/linux/arm/10.0/armv6j/serverarch/armarch/base default/linux/arm/10.0/armv7a arch/armarch/base default/linux/arm/10.0/armv7a/desktop arch/armarch/base default/linux/arm/10.0/armv7a/desktop/gnome arch/armarch/base targets/desktop default/linux/arm/10.0/armv7a/desktop/kde arch/armarch/base targets/desktop default/linux/arm/10.0/armv7a/developer arch/armarch/base default/linux/arm/10.0/armv7a/serverarch/armarch/base default/linux/arm/10.0/desktop/gnometargets/desktop default/linux/arm/10.0/desktop/kde targets/desktop default/linux/hppa/10.0/desktop/gnome targets/desktop default/linux/hppa/10.0/desktop/kde targets/desktop default/linux/ia64/10.0/desktop/gnome targets/desktop default/linux/ia64/10.0/desktop/kde targets/desktop default/linux/m68k/10.0/desktop/gnome targets/desktop default/linux/m68k/10.0/desktop/kde targets/desktop default/linux/mips/10.0 base default/linux/mips/10.0/mipsel arch/mips base default/linux/mips/10.0/mipsel/multilib arch/mips arch/mips/mipsel base default/linux/mips/10.0/mipsel/multilib/n32 arch/mips arch/mips/mipselbase default/linux/mips/10.0/mipsel/multilib/n64 arch/mips arch/mips/mipselbase default/linux/mips/10.0/mipsel/n32 arch/mips arch/mips/mipsel base default/linux/mips/10.0/mipsel/n64 arch/mips arch/mips/mipsel base default/linux/mips/10.0/multilibarch/mips base default/linux/mips/10.0/multilib/n32arch/mips base default/linux/mips/10.0/multilib/n64arch/mips base default/linux/mips/10.0/n32 arch/mips base default/linux/mips/10.0/n64 arch/mips base default/linux/powerpc/ppc32/10.0arch/base arch/powerpc default/linux/powerpc/ppc32/10.0/desktoparch/base arch/powerpc default/linux/powerpc/ppc32/10.0/desktop/gnome arch/base arch/powerpc targets/desktop default/linux/powerpc/ppc32/10.0/desktop/kdearch/base arch/powerpc targets/desktop default/linux/powerpc/ppc32/10.0/developer arch/base arch/powerpc default/linux/powerpc/ppc32/10.0/server arch/base arch/powerpc default/linux/powerpc/ppc64/10.0/32bit-userland arch/base arch/powerpc arch/powerpc/ppc64 default/linux/powerpc/ppc64/10.0/32bit-userland/desktop arch/base arch/powerpcarch/powerpc/ppc64 default/linux/powerpc/ppc64/10.0/32bit-userland/desktop/gnome arch/base arch/powerpcarch/powerpc/ppc64 targets/desktop
[gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
We have 2 files in gentoo-x86 with slightly out-of-sync data: profiles/arch/amd64/no-multilib/package.mask profiles/features/64bit-native/package.use.mask They both essentially block x86-only stuff. AFAIU profiles/features/64bit-native/package.use.mask should contain bits, which are portable across arches, but actively hate 64-bit userland. Looks like 'arch/amd64/no-multilib' profile inclusion is kept in sync with 'features/64bit-native' one: [1]. Exception is 'hardened/linux/amd64/no-multilib' profile. Looks like a bug. Why do we need to keep both 'package.mask' files the same? Why not drop '64bit-native/package.use.mask' or at least shrink it down to software keyworded for non-x86 and non-amd64? Thanks! [1]: $ portage/gentoo-x86/profiles: fgrep -R amd64/no-multilib . | grep -v ChangeLog | grep -v '$Header' | grep -v /CVS/ ./default/linux/amd64/10.0/no-multilib/parent:../../../../../arch/amd64/no-multilib ./default/linux/amd64/2008.0/no-multilib/parent:../../../../../arch/amd64/no-multilib ./hardened/linux/amd64/10.0/no-multilib/deprecated:hardened/linux/amd64/no-multilib $ portage/gentoo-x86/profiles: fgrep -R features/64bit-native . | grep -v ChangeLog | grep -v '$Header' | grep -v /CVS/ ./arch/powerpc/ppc64/64ul/parent:../../../../features/64bit-native ./default/linux/amd64/10.0/no-multilib/parent:../../../../../features/64bit-native ./default/linux/amd64/2008.0/no-multilib/parent:../../../../../features/64bit-native ./hardened/linux/amd64/no-multilib/parent:../../../../features/64bit-native ./hardened/linux/powerpc/ppc64/64bit-userland/parent:../../../../../features/64bit-native -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/11/2012 02:38 PM, Sergei Trofimovich wrote: We have 2 files in gentoo-x86 with slightly out-of-sync data: profiles/arch/amd64/no-multilib/package.mask profiles/features/64bit-native/package.use.mask They both essentially block x86-only stuff. AFAIU profiles/features/64bit-native/package.use.mask should contain bits, which are portable across arches, but actively hate 64-bit userland. Looks like 'arch/amd64/no-multilib' profile inclusion is kept in sync with 'features/64bit-native' one: [1]. Exception is 'hardened/linux/amd64/no-multilib' profile. Looks like a bug. Why do we need to keep both 'package.mask' files the same? Why not drop '64bit-native/package.use.mask' or at least shrink it down to software keyworded for non-x86 and non-amd64? Thanks! [1]: AFAIK features/64bit-native is for other 64-bit arches too like ia64 and ppc64. So we can't really drop this. And we can't drop the per-arch 64bit file because if a package does not work on ia64 it does not mean that it doesn't work on amd64 no-multilib. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPNqDXAAoJEPqDWhW0r/LCI+sP+wRlvgeFu74wAHKHgLqkENBM 5bsmSqPL9kPV8PKYtem4W748EI7PVv5K0ztSHVgzi8fxyZW4kvtjPhXnAuSaCuIJ xIB03hlgC3CKj0mtOAmSFStvDzlE2WLZG5FuGmmRBUekluB9C5ieoWxCQjxUc1QD 6mXp3Puqy6P1qMl4i5v2exT09gEr2dy9S/fXPv5KlMuysPX0oeUYopQtd0DRpft6 ViJ+TNcKySG3c6pcENhlEsL+mJGskZpyedNtdZFsmnIceeZVCHfuka7lbau8OOe7 H/nA4r8ikNU4mdnDVrV3qiJzHcHI2Es1u7W//bx0+9XhOZrvfWGNa4pKOw973V5l tzQyMV2nCdgxJjvJms5SqWGImdhGhErB7u2RkGsqnYBcqh8Ogxw8pJapnfLrigMN fxPX0GWCSh+ANf5GgCMTo57gteT0iNbcTOsDjTv0y6uwK9UEAOAUw5OtvLGtQuyH dksBlmyaJ6H4iUL3vb0WXyI9GdcglYl7WIFbDgBflj0nO5G6Q3ndiV08ndS1P0QM Vkxja29KHG0JJ4h4CwlVdEqCAZmqxr4IE6m4qfQVE3fCWGBm6FBlHJcQ8I0mWmuR ZXAaDFSDFlY9fkepnZWlSe1C8zjiMJ6f/dYCSEsHeavpQMoYCb+4YcQyu6F2o62w jfiMvKIglrlGC1jDHKVD =Tsl6 -END PGP SIGNATURE-
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 AFAIK features/64bit-native is for other 64-bit arches too like ia64 and ppc64. So we can't really drop this. And we can't drop the per-arch 64bit file because if a package does not work on ia64 it does not mean that it doesn't work on amd64 no-multilib. At a first glance $grep -v ^# features/64bit-native/package.mask | xargs -n 1 eshowkw only: app-accessibility/mbrola app-office/ooextras app-text/bibus dev-lang/icc games-emulation/caps games-emulation/snes9express games-fps/quake3-ra3 games-strategy/dominions2 games-strategy/majesty-demo games-strategy/smac net-p2p/sancho-bin sci-libs/ipp are keyworded on non-x86/amd64. I guess the rest can be removed from 'features/64bit-native/package.mask'. And I believe even _these_ should be moved to their no-multilib/pure-64bit equivalents (if yet/supported). If any of those would release native 64-bit binary this file will lose any meaning. - -- Sergei -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk82rX4ACgkQcaHudmEf86pRHwCcD2PS+I+A2n1KcE1trx2qk+ik CWkAnjPqdPsmyjeMNtmG2uoFgoRPjZPd =nZyp -END PGP SIGNATURE-
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
[ CCed gentoo-harde...@lists.gentoo.org to warn against possible breakage. Touching profiles make me nervous. TS: http://archives.gentoo.org/gentoo-dev/msg_7c41ab6653426048c2e8b0f271637bf3.xml ] Looks like 'arch/amd64/no-multilib' profile inclusion is kept in sync with 'features/64bit-native' one: [1]. Exception is 'hardened/linux/amd64/no-multilib' profile. Looks like a bug. Synced this bit with a fix: | 11 Feb 2012; Sergei Trofimovich sly...@gentoo.org | hardened/linux/amd64/no-multilib/parent: | Make hardened/linux/amd64/no-multilib include arch/amd64/no-multilib | (http://archives.gentoo.org/gentoo-dev/msg_7c41ab6653426048c2e8b0f271637bf3.x | ml). Approved by Zorry. Thanks! [1]: $ portage/gentoo-x86/profiles: fgrep -R amd64/no-multilib . | grep -v ChangeLog | grep -v '$Header' | grep -v /CVS/ ./default/linux/amd64/10.0/no-multilib/parent:../../../../../arch/amd64/no-multilib ./default/linux/amd64/2008.0/no-multilib/parent:../../../../../arch/amd64/no-multilib ./hardened/linux/amd64/10.0/no-multilib/deprecated:hardened/linux/amd64/no-multilib $ portage/gentoo-x86/profiles: fgrep -R features/64bit-native . | grep -v ChangeLog | grep -v '$Header' | grep -v /CVS/ ./arch/powerpc/ppc64/64ul/parent:../../../../features/64bit-native ./default/linux/amd64/10.0/no-multilib/parent:../../../../../features/64bit-native ./default/linux/amd64/2008.0/no-multilib/parent:../../../../../features/64bit-native ./hardened/linux/amd64/no-multilib/parent:../../../../features/64bit-native ./hardened/linux/powerpc/ppc64/64bit-userland/parent:../../../../../features/64bit-native -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
Looks like 'arch/amd64/no-multilib' profile inclusion is kept in sync with 'features/64bit-native' one: [1]. Exception is 'hardened/linux/amd64/no-multilib' profile. Looks like a bug. Synced this bit with a fix: | 11 Feb 2012; Sergei Trofimovich sly...@gentoo.org | hardened/linux/amd64/no-multilib/parent: | Make hardened/linux/amd64/no-multilib include arch/amd64/no-multilib | (http://archives.gentoo.org/gentoo-dev/msg_7c41ab6653426048c2e8b0f271637bf3.x | ml). And the change brought the breakage: New profiles popped up: | /usr/portage/profiles/arch/base | /usr/portage/profiles/features/multilib | /usr/portage/profiles/features/multilib/lib32 Likely because of double inclusion of some suspicious parent profiles. Reverted the change :[ -- Sergei signature.asc Description: PGP signature
