[gentoo-dev] Re: Restabilizing MIPS
Hi, Matt Turner matts...@gentoo.org: I don't have a long-term plan other than to stabilize the base system and provide n32 stages. Where it goes from there, I don't know. So I am sure you coordinate with redhatter. Though, you'd think with six members of the MIPS herd we'd have enough man-power between us to keep some stable keywords. I don't want to stop you, but you are relatively new to the real keywording business. amd64 at a point had over 30 members and could not work on the backlog in a timely manner. Think about * your long-time motivation, burn-out in arch work is quite common, * problems you will run on a minor architecture as MIPS - lots of patching, * reducing your keyword set (stable-wise) to a relative small subset and rethink your normal testing keywords. * proper documentation (handbook or elsewhere) V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Restabilizing MIPS
On 11/15/10 11:20 AM, Christian Faulhammer wrote: * reducing your keyword set (stable-wise) to a relative small subset and rethink your normal testing keywords. I think there is a related point here: when you start with a minimal stable set, it's easy to extend that set later. However, if you attempt to have a (relatively) large stable set, and it turns out later you're not able to maintain it, the situation is much worse because you'd probably have to force downgrades, drop stable keywords, etc. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Re: fat binaries
Il giorno lun, 15/11/2010 alle 00.41 +0100, Thomas Kahle ha scritto: Using ‘--enable-fat’ selects a “fat binary” build on x86 or x86 64 systems, where optimized low level subroutines are chosen at runtime according to the CPU de- tected. This means more code, but gives reasonable performance from a single bi- nary for all x86 chips, or similarly for all x86 64 chips. (This option might become available for more architectures in the future.) Okay this then has nothing to do with FatELF, and the name fat binary here is misused by most canons. What you have is instead a runtime cpu detection, which is something glibc (via ifunc), ffmpeg, mplayer, xine and so on already supports. My personal suggestion having worked with that kind of code is not to enable it unless it has more fine-grained logic than the simple arch-based one (such as FFmpeg's way to detect broken SSE3 implementations). And if you do enable it, the USE flag you need is cpudetection (already used by ffmpeg, mplayer and jack-audio-connection-kit). -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] Disabling auto-bumping of active Python version
On 11/14/10 22:42, Florian Philipp wrote: Is there a chance to do the same for perl and perl-cleaner? I understand perl is not slotted at the moment and there are probably good technical reasons for not doing so but I still wanted to ask. :) I'm not sure if the Perl team is watching this thread. Maybe ask on gentoo-perl directly. http://www.gentoo.org/main/en/lists.xml There are similar issues with ocaml and ocaml-rebuild.sh. Maybe try contacting m...@g.o on that one. I don't see any Ocaml project pages or mailing lists in Gentoo. Sebastian
Re: [gentoo-dev] Re: Restabilizing MIPS
On 11:20 Mon 15 Nov , Christian Faulhammer wrote: I don't want to stop you, but you are relatively new to the real keywording business. amd64 at a point had over 30 members and could not work on the backlog in a timely manner. Think about ... I completely agree. I don't know even what's the status of ~mips in the main tree. It would be better, I believe, to start working on the ~mips system/world set, then start stabilizing only toolchain and/or @base-system packages. Please don't start keywording/stabilizing random packages without taking into *serious* consideration what Christian wrote. I was here when we dropped the stable mips keyword, I don't want to see it happening again. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgpDe4eoeVA3y.pgp Description: PGP signature
Re: [gentoo-dev] EAPI versioning of files in profiles
2010-11-03 06:18:01 Zac Medico napisał(a): When you need to use a new EAPI, why not just create a sub-profile that uses the existing 'eapi' file support? For example, you could create 10.1 profiles that inherit from the 10.0 profiles, and put anything requiring the new EAPI in the 10.1 sub-profiles. Your suggestion would require that hundreds of packages are manually masked in base profile and unmasked in this new subprofile. E.g. it is planned that dev-python/setuptools will have python_abis_2.5-jython USE flag. This flag should be masked on architectures, which don't support Java/Jython. use.mask and package.use.mask files in base profile don't support such a USE flag, so dev-python/setuptools and all its (at least indirect) reverse dependencies would have to be masked in base profile. If a future EAPI allows a new character in package names, then my suggestion would allow to handle such packages. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI versioning of files in profiles
2010-11-15 19:32:28 Zac Medico napisał(a): On 11/15/2010 10:23 AM, Arfrever Frehtes Taifersar Arahesis wrote: 2010-11-03 06:18:01 Zac Medico napisał(a): When you need to use a new EAPI, why not just create a sub-profile that uses the existing 'eapi' file support? For example, you could create 10.1 profiles that inherit from the 10.0 profiles, and put anything requiring the new EAPI in the 10.1 sub-profiles. Your suggestion would require that hundreds of packages are manually masked in base profile and unmasked in this new subprofile. E.g. it is planned that dev-python/setuptools will have python_abis_2.5-jython USE flag. This flag should be masked on architectures, which don't support Java/Jython. use.mask and package.use.mask files in base profile don't support such a USE flag, so dev-python/setuptools and all its (at least indirect) reverse dependencies would have to be masked in base profile. Why would they have to be masked, just to make repoman happy? Yes. Alternatively, we could simply deprecate the older profile and remove it from profiles.desc so that repoman doesn't check it anymore. It's desirable to remove old profiles from profiles.desc anyway, since we don't want them to slow down repoman. The advantage of my suggestion is that it's fully backward compatible and doesn't require such changes in profiles.desc. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Restabilizing MIPS
On Mon, Nov 15, 2010 at 1:15 PM, Panagiotis Christopoulos pchr...@gentoo.org wrote: On 11:20 Mon 15 Nov , Christian Faulhammer wrote: I don't want to stop you, but you are relatively new to the real keywording business. amd64 at a point had over 30 members and could not work on the backlog in a timely manner. Think about ... I completely agree. I don't know even what's the status of ~mips in the main tree. It would be better, I believe, to start working on the ~mips system/world set, then start stabilizing only toolchain and/or @base-system packages. Please don't start keywording/stabilizing random packages without taking into *serious* consideration what Christian wrote. I was here when we dropped the stable mips keyword, I don't want to see it happening again. I'm not planning an ad-hoc at-random stabilization/keywording spree. I'd just like to have a stable and tested base system.
Re: [gentoo-dev] Re: Restabilizing MIPS
On Mon, 15 Nov 2010 14:41:17 -0500, Matt Turner wrote: snip I'm not planning an ad-hoc at-random stabilization/keywording spree. I'd just like to have a stable and tested base system. Sure, but you have to understand the concerns here. You have no long-term plan, you are underestimating the size of the team needed to keep a stable tree, and you are new. Do you blame people for raising questions and providing tips? No one is trying to stop you here, just trying to help. Maybe an alternative is to keep a stable base system in an overlay until you can verify: that it is doable, the mips team can keep up, and the team doesn't burn out regarding keywording? -Jeremy
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 16:03:01 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:56:18 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-10-25 15:42:00 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:24:23 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 1. Support for . characters in names of USE flags If you do this, you'll have to either convert everything using Python ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users get confused if they have to set both python_abis_3_2 (for EAPI 4 packages) and python_abis_3.2 (for EAPI 4 packages)? There won't be any such USE flags for EAPI 4. Ok, that answers that objection. In that case I'd not be opposed to . being allowed *provided*: - Portage explicitly enforces it not being allowed anywhere else, including in profiles that aren't marked as eapi 4 I have implemented validation of syntax of USE flags in files in profiles: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=9e9c822aae0c3daab208175025b161d6d34877fe -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Disabling auto-bumping of active Python version
On Monday 15 November 2010 11:37:08 Sebastian Pipping wrote: On 11/14/10 22:42, Florian Philipp wrote: Is there a chance to do the same for perl and perl-cleaner? I understand perl is not slotted at the moment and there are probably good technical reasons for not doing so but I still wanted to ask. :) I'm not sure if the Perl team is watching this thread. Maybe ask on gentoo-perl directly. http://www.gentoo.org/main/en/lists.xml There are similar issues with ocaml and ocaml-rebuild.sh. Maybe try contacting m...@g.o on that one. I don't see any Ocaml project pages or mailing lists in Gentoo. Since none are slotted, I don't understand what outcome you expect by contacting the maintainers. At best, perl-cleaner and ocaml-rebuild.sh shall be merged into portage in a preserve-libs like manner. A.
Re: [gentoo-dev] EAPI versioning of files in profiles
On Mon, Nov 15, 2010 at 07:40:44PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
Some updates to my suggestion:
- Files would optionally end with -${EAPI} suffix.
- The following files would be affected:
package.mask
package.unmask
package.keywords
package.accept_keywords
package.use
package.provided
use.force
use.mask
use.unsatisfiable
package.use.force
package.use.mask
package.use.unsatisfiable
packages
virtuals
(Some of these files aren't documented in PMS.)
I would like to suggest that this feature be included in EAPI=4.
I have a patch, which implements this feature in Portage.
The council has already decided that a filename suffix is not a
desirable way to fix issues like this.
We really need another solution..
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com
pgpYqazF9Ucai.pgp
Description: PGP signature
Re: [gentoo-dev] News item: Dropping Java support on ia64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-11-2010 18:41, Paweł Hajdan, Jr. wrote: On 11/14/10 8:36 PM, Petteri Räty wrote: The IA64 arch team does not have the resources to maintain Java support so we agreed that support will be dropped unless more man power becomes available. Could you also add the info to http://www.gentoo.org/proj/en/devrel/staffing-needs/ ? That page is generated automatically from info on project pages[1]. For more info about ProjectXML writing, check the guide[2]. [1] - http://www.gentoo.org/proj/en/metastructure/projectxml.xml#doc_chap3 [2] - http://www.gentoo.org/proj/en/metastructure/projectxml.xml - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJM4chmAAoJEC8ZTXQF1qEPXkkP/3zNt7JzsdbM2Fu4MEWKHhpo 1K/DgS9zpyDS8N2CyjetqEd7mZgUOPkV8uZJLVjo8JM6SCtFhDKpiPjHQmPw1nUg GwlbR4MsS5G3yr3bW+lUIc/pxE0yX34mslPBaGZOWVn4kr3jiyoZgp4UwWjLEXUD Urn/Cm0CQ7DauOzfgjoqMZBnKATiQZM9WOL22ETMLyYBysDT1NkZy1ZE2/vhp4iI 1BUNRqc+eq0DRZ8aAkaTSqcFaRwOD5eSLz30V0wwfYjK3GMTkDXtKv1YOgf2x7Z7 M0/YvmOK0kIWXqFpVE0kF/3L3wgwhLchf7OE2zr7eJffdcSLsb1/RfWqiW1wI7rU 4J/A6kMq1C2QICc8UwvLwVNs500Jy3+DI7L9XzH8IRZ1SivigS1DUYefRK+ttCEH ninqh4UjHGlynT4qoBdfEza2VKSnq87aUER8TsX3SkNaa6lufRKBIfeOjLuCn3ql uMpLYZ9tere+NgXhGLUDjJ3HDgUGE/1dzIDtQHpOLY1GkNF7k8vNSZMWQB9C75J4 elFrEYEqxPVuqTyWU4zn1ClFaaHLLHPTwKBtLtckB51TesnsPLl1F4lj8fFS5j9u sAjSyndnfXefcxqhWg+E4Dk8SNX2/TD2pt/Tlv6j7zRBgponKBdphkUKtaaMh2OA 54cjJizdynp48mTLmQtZ =kPh/ -END PGP SIGNATURE-
Re: [gentoo-dev] Disabling auto-bumping of active Python version
On 11/15/2010 02:02 PM, Alexis Ballier wrote: Since none are slotted, I don't understand what outcome you expect by contacting the maintainers. At best, perl-cleaner and ocaml-rebuild.sh shall be merged into portage in a preserve-libs like manner. In case some aren't aware, I'll mention that abi-slot dependencies (if/when implemented) can potentially serve as a generic solution that covers all such un-slotted cases (as discussed in bug #192319 [1]). For slotted packages, the rebuild logic will be slightly different, but it will be nice to devise a generic solution for those too. [1] https://bugs.gentoo.org/show_bug.cgi?id=192319 -- Thanks, Zac
