Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
On Tue, 19 Jun 2012 23:07:01 +0200 Thomas Sachau to...@gentoo.org wrote: Do you prefer having everything hardcoded in PMS or can you accept outsourcing bigger code pieces into some sort of eclass (i am thinking about some external code base, which can be duplicated by the package manager with internal code, but has to be used, if the external eclass has a newer version/revision then the duplicated internal code)? The package manager mustn't require any particular eclass to be present, and there mustn't be duplication between eclasses and the package manager. I am especially thinking about the setup of the environment and the code details for the wrappers for binaries and headers, hardcoding those details into PMS makes it hard to change/fix issues later on. Sounds like you haven't really got a clean design then. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] spec draft for cross-compile support in future EAPI (EAPI-5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2012 08:14 PM, Thomas Sachau wrote: and possibly split RDEPEND/DEPEND to have HDEPEND to list build dependencies that need to be run on host. What should the difference between DEPEND and HDEPEND be? Not library but program that have to run. Think about generators. lu - -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/hfm8ACgkQ6Ex4woTpDjRrtgCfXm2/b3FlZldoKfbVoNA8DKOf Sx4AoIAy1WEHulrBY3LsDxIyv6JUMjPV =MCO8 -END PGP SIGNATURE-
Re: [gentoo-dev] About what would be included in EAPI5
On Sat, 16 Jun 2012 14:12:13 +0200 Ulrich Mueller u...@gentoo.org wrote: On Sat, 16 Jun 2012, Pacho Ramos wrote: I would like to know if there is some place where things going to be included (or proposed to be included) for eapi5 are listed (if such place exists). Currently, looks like there is no eapi5 tracker :-/ The PMS git repository has an eapi-5 development branch, and some parallel discussion took place in the gentoo-pms mailing list. So far we have: ╓ ║ EAPI 5 is EAPI 4 with the following changes: ║ ║ • econf adds --disable-silent-rules. ║ • Slot operator dependencies. ║ • src_test supports parallel tests. ║ • USE is calculated differently. ║ • IMAGE is gone. ║ • REQUIRED_USE now supports ?? groups. ║ • apply_user_patches function, with src_prepare changes. ║ • EBUILD_PHASE_FUNC. ║ • find is guaranteed to be GNU. ║ • new* can read from standard input. ╙ Could someone open bugs for all of that? I was looking for user patches on the future EAPI tracker, and I don't see it there. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 11:07:55 +0200 Michał Górny mgo...@gentoo.org wrote: Could someone open bugs for all of that? I was looking for user patches on the future EAPI tracker, and I don't see it there. Please don't. User patches were discussed on this list, and there's already wording written. We don't need a bug to track it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 12:02:42 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 20 Jun 2012 11:07:55 +0200 Michał Górny mgo...@gentoo.org wrote: Could someone open bugs for all of that? I was looking for user patches on the future EAPI tracker, and I don't see it there. Please don't. User patches were discussed on this list, and there's already wording written. We don't need a bug to track it. So you want requests here or do I have do look back to find that thread? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 13:12:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 20 Jun 2012 12:02:42 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Please don't. User patches were discussed on this list, and there's already wording written. We don't need a bug to track it. So you want requests here or do I have do look back to find that thread? I believe we consider the user patches feature to be finalised, so if you want something else, it should be treated as a new feature rather than a change. But please don't rehash anything that's already been covered. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 12:14:38 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 20 Jun 2012 13:12:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Wed, 20 Jun 2012 12:02:42 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Please don't. User patches were discussed on this list, and there's already wording written. We don't need a bug to track it. So you want requests here or do I have do look back to find that thread? I believe we consider the user patches feature to be finalised, so if you want something else, it should be treated as a new feature rather than a change. But please don't rehash anything that's already been covered. I simply don't get why the spec obligates package managers to support user patches while it doesn't provide any explanation how the patches should be applied nor any function to actually apply patches... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 13:22:22 +0200 Michał Górny mgo...@gentoo.org wrote: I believe we consider the user patches feature to be finalised, so if you want something else, it should be treated as a new feature rather than a change. But please don't rehash anything that's already been covered. I simply don't get why the spec obligates package managers to support user patches while it doesn't provide any explanation how the patches should be applied The spec does not obligate package managers to support user patches. It obligates ebuilds to support user packages. This was all covered in the original thread. nor any function to actually apply patches... Moving epatch into EAPI 5 is a separate feature, and one that's probably going to be controversial. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On di, 2012-06-19 at 18:53 +0200, hasufell wrote: On 06/17/2012 10:31 PM, Michał Górny wrote: Hello, A simple solution to a program long-unsolved. In GLEP form. Both attached and published as a gist: https://gist.github.com/2945569 (please note that github doesn't render GLEP headers correctly) As already stated I like this idea, because I already got some optional dep bloat in x11-misc/spacefm and media-sound/gmusicbrowser. However I have a few objections: 1. Optional deps are SUGGESTIONS from the dev which he considered nice/good/sane at the time of writing the ebuild. Other people might totally disagree with those suggestions. As useflags in IUSE_RUNTIME can pick from global useflags as well or even set +foo the user might have a hard time to turn off things he does not want without turning them off for regular IUSE as well. I think we're not all agreeing on which problem is being solved here. I see IUSE_RUNTIME as an improvement for packages that have a runtime dependency on another package to provide a certain feature, but no way of turning this feature off at build time. Examples of this kind of dependency are executables or python imports, where the executable or library being absent is dealt with at runtime. For such packages putting the dependency behind a USE flag makes sense, and for other packages to depend on the package with that USE flag set also makes sense. This already works today. However, if you originally built the package with the USE flag off, and now try to install something that depends on the package with the USE flag on, you force a rebuild. That's not so nice, as there's no change to the installed package at all: the rebuild is a waste of time. IUSE_RUNTIME allows the package manager to skip that rebuild, as it now knows it is unnecessary. What you are describing is more like suggested dependencies. Those may also be useful, but do not solve quite the same problem. I do not think they quite replace the USE flag-based approach described above, as it makes sense for other ebuilds to depend on foo with support for feature blah through the blah USE flag without all those other packages having to know which specific dependencies this adds to foo, or whether foo needs a rebuild to enable the feature or not. Also, even in packages in which IUSE_RUNTIME is used for something like suggested dependencies it is not terribly hard for the user to turn the USE flag off (package.use) and install the interesting bits by hand. 2. Afais useflags that are already in IUSE and used for build-time stuff must not be used for IUSE_RUNTIME too. This is a random rule IMO. I don't have many cases in mind where this would be annoying (could think of debug enabling some in-source switches and adding optional debug tools in RDEPEND. Having one flag here would make it cleaner and tighter for the user to interact with useflags.). However... this is not a logical rule, rather a technical issue. If there is a way to avoid this restriction that would be nice. I do not see where you are going with this. If it makes sense to turn on the build-time support for a feature without installing all the dependencies then the extra dependencies should go behind a separate USE flag (and that separate USE flag may depend on the USE flag controlling the build-time support using REQUIRED_USE). Or perhaps the additional dependencies should be in some new kind of suggested depend. 3. There are no unconditional optional deps possible. ssuominen had an example: virtualx.eclass could have suggestion/recommendation to enable USE=xvfb in x11-base/xorg-server I do not see where you are going with this. Can you refer me to where this suggestion was made? virtualx.eclass adds a hard dependency if the test USE flag (or some other USE flag) is set, and no dependency if this USE flag is not set. When would virtualx.eclass add an optional dependency? -- Marien Zwart
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012, Ciaran McCreesh wrote: I believe we consider the user patches feature to be finalised, [...] I disagree with this. As it is currently worded, every ebuild would be required would be required to call a special function in src_prepare. This is the worst possible solution, IMHO. Ulrich
[gentoo-dev] [RFC] gcc-native-flags() proposal addition to toolchain-funcs.eclass
Meeting with bug: #409471 suggested that some ebuilds could benefit from expanding -march=native to the actual flags the compiler use. Cannot suggest where to use it at the moment, but implementation was simple enough and possibly someone on this list could have a use for it. # @FUNCTION: gcc-native-flags # @USAGE: [CC compiler] # @RETURN: 1st march 2nd mtune =3rd flags gcc-native-flags() gcc-native-flags can take an argument, the compiler to use, then return something in the form: -march=corei7-avx -mtune=generic -mcx16 [...] --param=l2-cache-size=8192 issues so far: 1) --param l2-cache-size=8192 become --param=l2-cache-size=8192, notice the space become an =, this work and indeed I've encountered broken packages that didn't compile with -param\ ... form 2) what to do if $CC is not gcc / how to check cc is gcc 3) there are redundant flags, they are kept for simplicity 4) array usage is not really needed, just being a port of a python version it was natural this way ;-) 5) better name? #409471 dev-python/pypy-1.8-r1 CFLAGS=-march=native fails to compile https://bugs.gentoo.org/show_bug.cgi?id=409471 the attached file could be launched as is, it fake inherit some eclass and calls the function with available gcc thanks, Francesco Riosa hw-cflags.sh Description: application/shellscript
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 17:44:36 +0200 Ulrich Mueller u...@gentoo.org wrote: On Wed, 20 Jun 2012, Ciaran McCreesh wrote: I believe we consider the user patches feature to be finalised, [...] I disagree with this. As it is currently worded, every ebuild would be required would be required to call a special function in src_prepare. This is the worst possible solution, IMHO. Every ebuild that defines its own src_prepare, yes. That's the point: the package mangler can't know where to apply patches itself otherwise, and user patches are rare enough that developers are very likely to forget to check if they aren't made to. We had this discussion in the original thread. If we're just looking for a feature that might work sometimes, there's no point sticking any of this in the EAPI at all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 17:44:36 +0200 Ulrich Mueller u...@gentoo.org wrote: I disagree with this. As it is currently worded, every ebuild would be required to call a special function in src_prepare. This is the worst possible solution, IMHO. Every ebuild that defines its own src_prepare, yes. That's the point: the package mangler can't know where to apply patches itself otherwise, and user patches are rare enough that developers are very likely to forget to check if they aren't made to. Right, user patches are rare, and patches that change the build system such that eautoreconf is necessary are even rarer. I'd say that EAPI 5 should provide an apply_patches_here function that can be called by ebuilds, but if the ebuild hasn't called the function, then it should fall back to applying user patches just after src_prepare. We had this discussion in the original thread. If we're just looking for a feature that might work sometimes, there's no point sticking any of this in the EAPI at all. I don't see why the above wouldn't work. The user still has complete control, because he can always patch (e.g.) configure along with configure.in. Then there are ebuilds that don't call eautoreconf, in the first place. Should we require that all of them inherit autotools now, just for the unlikely case that user patches could be applied? Ulrich
Re: [gentoo-dev] About what would be included in EAPI5
On Wed, 20 Jun 2012 18:45:31 +0200 Ulrich Mueller u...@gentoo.org wrote: I'd say that EAPI 5 should provide an apply_patches_here function that can be called by ebuilds, but if the ebuild hasn't called the function, then it should fall back to applying user patches just after src_prepare. But applying user patches after src_prepare is wrong. We already had this discussion. We had this discussion in the original thread. If we're just looking for a feature that might work sometimes, there's no point sticking any of this in the EAPI at all. I don't see why the above wouldn't work. The user still has complete control, because he can always patch (e.g.) configure along with configure.in. Not really, since patches mess with timestamps. Then there are ebuilds that don't call eautoreconf, in the first place. Should we require that all of them inherit autotools now, just for the unlikely case that user patches could be applied? If the aim is to provide a working feature to users, yes. The alternative is to not provide user patches support. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/20/2012 05:05 PM, Marien Zwart wrote: On di, 2012-06-19 at 18:53 +0200, hasufell wrote: 1. Optional deps are SUGGESTIONS from the dev which he considered nice/good/sane at the time of writing the ebuild. Other people might totally disagree with those suggestions. As useflags in IUSE_RUNTIME can pick from global useflags as well or even set +foo the user might have a hard time to turn off things he does not want without turning them off for regular IUSE as well. I think we're not all agreeing on which problem is being solved here. I see IUSE_RUNTIME as an improvement for packages that have a runtime dependency on another package to provide a certain feature, but no way of turning this feature off at build time. Examples of this kind of dependency are executables or python imports, where the executable or library being absent is dealt with at runtime. For such packages putting the dependency behind a USE flag makes sense, and for other packages to depend on the package with that USE flag set also makes sense. Makes sense to you or the developer who wrote the ebuild. I know the usecases of IUSE_RUNTIME, but you have to realize that people might _not_ want additional optional runtime dependencies turned on by useflags that are already in _make.conf_! IUSE_RUNTIME is technically not a seperate thing, cause they go all into IUSE and maintaining useflags might become way more complicated for some users/usecases than it used to be, because of this new feature and a lot more dependencies that are triggered by your USE=... variable. Something like FEATURES=optional-deps would simply enable people to have a minimum of dependencies and still be able to use global useflags _without_ micro-managing all of them per-package, cause some of them are in IUSE_RUNTIME and others not. 2. Afais useflags that are already in IUSE and used for build-time stuff must not be used for IUSE_RUNTIME too. This is a random rule IMO. I don't have many cases in mind where this would be annoying (could think of debug enabling some in-source switches and adding optional debug tools in RDEPEND. Having one flag here would make it cleaner and tighter for the user to interact with useflags.). However... this is not a logical rule, rather a technical issue. If there is a way to avoid this restriction that would be nice. I do not see where you are going with this. If it makes sense to turn on the build-time support for a feature without installing all the dependencies then the extra dependencies should go behind a separate USE flag (and that separate USE flag may depend on the USE flag controlling the build-time support using REQUIRED_USE). Or perhaps the additional dependencies should be in some new kind of suggested depend. I think it is bad to overuse REQUIRED_USE in that way. REQUIRED_USE blocks the emerge process and should only be used when there is a technical (not logical) useflag correlation. Using a seperate USE flag just because the name is blocked means the user has to look up another useflag and think about what it is for. But as I said... that is rather minor. I just don't like it either, cause I feel it might annoy me in the future. What do you think about useflag expansion and seperating them in make.conf like yngwin suggested: USE_RUNTIME=debug - will enable runtime_debug useflag for all ebuilds USE=debug - will enable debug useflag for all ebuilds This would also solve point #1 somehow, cause you don't have to fear that your dependency graph will grow just because you didn't examine all newly introduced IUSE_RUNTIME flags. For people who want that stuff unconditionally they could do: USE_RUNTIME=$USE and never bother again with it. 3. There are no unconditional optional deps possible. ssuominen had an example: virtualx.eclass could have suggestion/recommendation to enable USE=xvfb in x11-base/xorg-server I do not see where you are going with this. Can you refer me to where this suggestion was made? virtualx.eclass adds a hard dependency if the test USE flag (or some other USE flag) is set, and no dependency if this USE flag is not set. When would virtualx.eclass add an optional dependency? I hope ssuominen might explain more about this idea as I already requested.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 18:57:19 +0200 hasufell hasuf...@gentoo.org wrote: 2. Afais useflags that are already in IUSE and used for build-time stuff must not be used for IUSE_RUNTIME too. This is a random rule IMO. I don't have many cases in mind where this would be annoying (could think of debug enabling some in-source switches and adding optional debug tools in RDEPEND. Having one flag here would make it cleaner and tighter for the user to interact with useflags.). However... this is not a logical rule, rather a technical issue. If there is a way to avoid this restriction that would be nice. I do not see where you are going with this. If it makes sense to turn on the build-time support for a feature without installing all the dependencies then the extra dependencies should go behind a separate USE flag (and that separate USE flag may depend on the USE flag controlling the build-time support using REQUIRED_USE). Or perhaps the additional dependencies should be in some new kind of suggested depend. I think it is bad to overuse REQUIRED_USE in that way. REQUIRED_USE blocks the emerge process and should only be used when there is a technical (not logical) useflag correlation. Using a seperate USE flag just because the name is blocked means the user has to look up another useflag and think about what it is for. But as I said... that is rather minor. I just don't like it either, cause I feel it might annoy me in the future. What do you think about useflag expansion and seperating them in make.conf like yngwin suggested: USE_RUNTIME=debug - will enable runtime_debug useflag for all ebuilds USE=debug - will enable debug useflag for all ebuilds This would also solve point #1 somehow, cause you don't have to fear that your dependency graph will grow just because you didn't examine all newly introduced IUSE_RUNTIME flags. For people who want that stuff unconditionally they could do: USE_RUNTIME=$USE and never bother again with it. Please read the rationale. Again. The whole thing. Three times. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/20/2012 07:07 PM, Michał Górny wrote: Please read the rationale. Again. The whole thing. Three times. Please read my suggestions. Again. The whole thing. Three times.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 19:11:33 +0200 hasufell hasuf...@gentoo.org wrote: On 06/20/2012 07:07 PM, Michał Górny wrote: Please read the rationale. Again. The whole thing. Three times. Please read my suggestions. Again. The whole thing. Three times. Can we all agree to just stop this and just restrict the arguing to being between SDEPEND and DEPENDENCIES? Cheers. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 18:24:33 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Can we all agree to just stop this and just restrict the arguing to being between SDEPEND and DEPENDENCIES? Cheers. I clearly favour going with SDEPEND now as this fits better what people are used to and the move to DEPENDENCIES is also a chance to clean up dep-specs after we added all quirks we need(*). Let's name GLEP 54 here which we hopefully can add to EAPI 6. (*) or for when we run out of special chars ;) signature.asc Description: PGP signature
Re: [gentoo-dev] Killing UEFI Secure Boot
On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. You have a much better chance of just telling the user, Disable the Secure Boot option in your BIOS. No, that doesn't mean that Linux isn't secure. Yes, I understand it looks that way. And the conversation degenerates from there. Sorry, not a valid solution. And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? greg k-h
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/20/2012 04:08 PM, Greg KH wrote: On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? To be clear, I was not talking about taking away options from users. I was talking about giving them options.
Re: [gentoo-dev] Killing UEFI Secure Boot
On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote: On 06/20/2012 04:08 PM, Greg KH wrote: On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. No, neither of them replaces the BIOS in their machines with an opensource version. There is no BIOS in those platforms, it's just uboot or fastboot, the PC-like ecosystem is so vastly different it's laughable. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. And I agree with that developer. Don't get replace all of userspace and the kernel confused with replace the UEFI bios. You do realize that the UEFI bios is at least double the size of the Linux kernel, with custom device drivers and tons of other stuff in there? Good luck replacing that... And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? To be clear, I was not talking about taking away options from users. I was talking about giving them options. You are taking secure boot out of their systems, that sounds like taking away an option to me :) Anyway, it's all a moot point, as has been explained already, sorry. greg k-h
[gentoo-dev] My wishlist for EAPI 5
Here is my wishlist for EAPI 5: Multilib (and/or multiarch) support Automated epatch_user support Parallel make checks POSIX Shell compliance Here are some explanations: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. Automated epatch_user support Users should be able to test patches without modifying their ebuilds. This also saves developer time because we don't need to navigate the portage tree (or an overlay), make a change and test it. We could just dump the patch in the appropriate directory and build. Parallel make checks As it stands, `make check` is so slow that few people actually run it and QA suffers as a result. We have the ability to do parallel checks, but we need to explicitly put `emake check` into the ebuild and use autoconf 1.12 to get that. It would be best if this behavior were the default, not the exception. POSIX Shell compliance There has been a great deal of work done to give the user full control of what is on his system and there is more that we can do there. In particular, I think a lean Gentoo Linux system should be able to use busybox sh and nothing else. That requires POSIX shell compliance. OpenRC init scripts support this and the configure scripts support this. The few exceptions are bugs that are addressed by the Gentoo BSD developers. As such, I think we should make EAPI=5 use POSIX shell by default. If an ebuild requires bash, we can allow the ebuild to declare that (e.g. WANT_SH=bash), but that should be the exception and not the rule.
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/20/2012 04:20 PM, Greg KH wrote: On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote: On 06/20/2012 04:08 PM, Greg KH wrote: On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. No, neither of them replaces the BIOS in their machines with an opensource version. There is no BIOS in those platforms, it's just uboot or fastboot, the PC-like ecosystem is so vastly different it's laughable. The BIOS on our machines is analogous to the flash on those machines on which the firmware operates. There is no difference. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. And I agree with that developer. Don't get replace all of userspace and the kernel confused with replace the UEFI bios. You do realize that the UEFI bios is at least double the size of the Linux kernel, with custom device drivers and tons of other stuff in there? Good luck replacing that... Replacing UEFI does not mean that we need a compatible replacement. Things like being able to boot Windows is unnecessary functionality that can be removed. The only thing replacement firmware must do is get the kernel loaded into memory, initialize the structures that the kernel wants and jump into it. That is it. And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? To be clear, I was not talking about taking away options from users. I was talking about giving them options. You are taking secure boot out of their systems, that sounds like taking away an option to me :) I have an Asus motherboard that fails to boot when it has more than 6 hard drives. If I replaced its BIOS with our own firmware, I could fix that. If I had our own firmware and I wanted to do my own key signing, I could implement that. If were to replace UEFI with our own firmware, the user would have full view of the source code, rather than some mystery blob. The pool of people who could do bug fixes would increase and that in general would be a good thing. Technical hurdles will likely prevent this unless we an get vendors to release documentation. Is there any chance you could contact people at Intel requesting programming documentation on their memory controller and anything else we would need to write a small OS that we could flash in place of UEFI?
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. POSIX Shell compliance There has been a great deal of work done to give the user full control of what is on his system and there is more that we can do there. In particular, I think a lean Gentoo Linux system should be able to use busybox sh and nothing else. That requires POSIX shell compliance. OpenRC init scripts support this and the configure scripts support this. The few exceptions are bugs that are addressed by the Gentoo BSD developers. As such, I think we should make EAPI=5 use POSIX shell by default. If an ebuild requires bash, we can allow the ebuild to declare that (e.g. WANT_SH=bash), but that should be the exception and not the rule. So far as I know, every PM relies heavily upon bash anyway (and can't easily be made not to), so even if developers would accept having to rewrite all their eclasses, it still wouldn't remove the dep. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support Sorry for a possibly ignorant question. Does multilib support include the ability to build Busybox against uclibc (on a glibc system)? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, 20 Jun 2012 23:39:42 +0300 Maxim Kammerer m...@dee.su wrote: On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support Sorry for a possibly ignorant question. Does multilib support include the ability to build Busybox against uclibc (on a glibc system)? Nobody knows, since everyone you ask has a different idea of what multilib is. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. The multilib-portage overlay already has this working. POSIX Shell compliance There has been a great deal of work done to give the user full control of what is on his system and there is more that we can do there. In particular, I think a lean Gentoo Linux system should be able to use busybox sh and nothing else. That requires POSIX shell compliance. OpenRC init scripts support this and the configure scripts support this. The few exceptions are bugs that are addressed by the Gentoo BSD developers. As such, I think we should make EAPI=5 use POSIX shell by default. If an ebuild requires bash, we can allow the ebuild to declare that (e.g. WANT_SH=bash), but that should be the exception and not the rule. So far as I know, every PM relies heavily upon bash anyway (and can't easily be made not to), so even if developers would accept having to rewrite all their eclasses, it still wouldn't remove the dep. Lets address POSIX compliance in the ebuilds first. Then we can deal with the package managers. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP4jeZAAoJECDuEZm+6Exkt6cP/jpDU3CQmCZlOJWHf2uLYPpg +Ft2bN2JyMs1rquIrAd0PGtMXu8zrQC5U7Q0SAO1Vm+Ieu98aHknGMPWJYtV0PpU X5/bFqk+LjaO/fFAo+x+IKET24hYXry9P27om/ZUgURKDbWvityQAeIKrZhT9U/r LzPWgSu/v9wLDBVwZpIEjlMeYMD/uA868srBDK/dVjhZHFB6bzVK8h8xhI4zq/X3 UQYPXFuCgg2s7+g/2Z+pCvGVKwX/GdGXU8ZMRtEu3PF1hgBXBXb1qkaQRQoOGsEG BRkOAp+MqI+/VClvxPFGGVfqvRZaqQhmg4VxYIELkPh4jzvfIJu/WC7CReOix574 hBhDXrPWwJ2r6Y1updNpWUg7yBQGRmAtmRd6AL4MVHG70j/6IlSrsGrQr8KrdxuP BzQDTzN0rd5iDocO3bACluzxMSrd2wk73bvaAcWYsmIVVigVASHIcdvMthgx/ctw zSEOp7sIvXejbONeIwhcqu6M6qvFi6i2o/82Mk68JXH0BAIZ2cC8atn+mmZd0SMz R49Wu9GSyNCAeubuxTxUaEatGmSGGNtXEACxGpvtyo8XbvYmfNvntsxorRvnWNXt hhIQQYQwVOsSUSCHSqKS1/lD/8EIWoMD531IRKEyhP6eMoGZBUFCrc94zoGLwmz5 VlJuFNCU9ylfbEWMayLC =I8nt -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
On 06/20/2012 10:25 PM, Richard Yao wrote: Here is my wishlist for EAPI 5: Multilib (and/or multiarch) support Automated epatch_user support Parallel make checks POSIX Shell compliance Here are some explanations: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. Automated epatch_user support Users should be able to test patches without modifying their ebuilds. This also saves developer time because we don't need to navigate the portage tree (or an overlay), make a change and test it. We could just dump the patch in the appropriate directory and build. Parallel make checks As it stands, `make check` is so slow that few people actually run it and QA suffers as a result. We have the ability to do parallel checks, but we need to explicitly put `emake check` into the ebuild and use autoconf 1.12 to get that. It would be best if this behavior were the default, not the exception. POSIX Shell compliance There has been a great deal of work done to give the user full control of what is on his system and there is more that we can do there. In particular, I think a lean Gentoo Linux system should be able to use busybox sh and nothing else. That requires POSIX shell compliance. OpenRC init scripts support this and the configure scripts support this. The few exceptions are bugs that are addressed by the Gentoo BSD developers. As such, I think we should make EAPI=5 use POSIX shell by default. If an ebuild requires bash, we can allow the ebuild to declare that (e.g. WANT_SH=bash), but that should be the exception and not the rule. It is more likely to succeed either adding to busybox the missing bits of bash we use or forking bash (so eventually it could be developed on a source repo) and making it lean and fast for our specific purposes. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] My wishlist for EAPI 5
On 06/20/2012 04:39 PM, Maxim Kammerer wrote: On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support Sorry for a possibly ignorant question. Does multilib support include the ability to build Busybox against uclibc (on a glibc system)? It includes it no more than portage does currently.
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao r...@gentoo.org wrote: On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. The multilib-portage overlay already has this working. But there is no spec, nor is there a developer-centric description of it. So far as I know, every PM relies heavily upon bash anyway (and can't easily be made not to), so even if developers would accept having to rewrite all their eclasses, it still wouldn't remove the dep. Lets address POSIX compliance in the ebuilds first. Then we can deal with the package managers. Why? It's highly doubtful the package manglers could switch shells even if they wanted to, and even if every ebuild started using EAPI 5. It's wasted effort. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/iOG8ACgkQ96zL6DUtXhG5FgCgw3V9qz3o1d0A4TUw5y83lfCE LWkAnRbY4WKJz1xribnhUat0YL1XEwHR =dYt+ -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 04:54 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao r...@gentoo.org wrote: On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. The multilib-portage overlay already has this working. But there is no spec, nor is there a developer-centric description of it. So far as I know, every PM relies heavily upon bash anyway (and can't easily be made not to), so even if developers would accept having to rewrite all their eclasses, it still wouldn't remove the dep. Lets address POSIX compliance in the ebuilds first. Then we can deal with the package managers. Why? It's highly doubtful the package manglers could switch shells even if they wanted to, and even if every ebuild started using EAPI 5. It's wasted effort. Source the ebuild using the system shell, check for WANT_SH. If it does not exist, proceed. If it does, start over with a different shell. I do not see any technical problem. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP4jpSAAoJECDuEZm+6ExkBqgQAJjLoTfIgSUAVk6aLzC34Pkh +d7Q62a4jwZxh/XPG2WA2AoDX09JCIyr8yfdMTpayas1v7tdOP62IgG1Ovjfsb1g J3Tywf3zem6jq32ju/xfWcLn2ZVRxkHvgn0J8YLPnIWBCUUBpdGqWyNxdAbGX/94 XCD6kmAMOr1EWpk3E3SQ2C1YNN/+vLX6DWW8sFEg7TZJU/5pUTnS66LIgp0ebcte 38lYHwdZGVZBLi4ehc/RSTbFtXs4vi5Q2YW32OREyMT2oyuoSqFCH4fLczvUVzF0 SKjooI0tv7dlFcXDjkEOg7fLnHioeSVyl5q/Fgz4rcyEhJuvdJu8SmqZStS5n3q3 Dd0EJ8ntUPMKcYt6g6hSczWrsKEYGSOynM+cg0WBkaTvx/J/5JVtjfsCXU707kkj 2Z/oNpjM1XgwOfnP+LY9vsBBx0y7j+EMc0/eOO8ZDxWCVsIstTtiCUhJr2TuNpDr r2l1qVgc95JOZqGPx0/reopdM7x/8vWw+Opadg0xXZVFpvfnBlVCUH9cqFhu/DUU ygLtZgbNnIgrlykZVLL8o8kKqKauTKpAwi1SRPjY5WIdH64lt1LEGDRfoN4BkfXZ jjL5kT0tM9uEjt7SanG7EdJi2x0xZQolXdsaYOOgUOH1g35s0uuuQE69hEpe/TXP wk2bZWtEPc1wDcty1/RN =nGyi -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 04:54 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao r...@gentoo.org wrote: On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. The multilib-portage overlay already has this working. But there is no spec, nor is there a developer-centric description of it. I missed this tibbit. I am not sure what you expect me to do this about this. Thomas Sachau developed the multilib overlay, he has put a great deal of work into it and he likely has a specification. You are more than welcome to talk to him about the specification. If it not well defined, feel free to share your ideas on how it could be better defined. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP4jszAAoJECDuEZm+6Exk5EMP/0xRHW2PjOzb4xIEwW2ve+qM BJNEk5lMJfL2N8x5CM30n+uUOH665fSw26o6H6mkh397F7UO+BGCctQuBgSo0q3V s+bA3yFp5mZwr326RnnNKkgY5vKNHUjd7MH568i1ARHJdCx7Epn5Ep2o95msz0XG yzfxFkKT1O5BXKYXyLeTNfHvyS6cRx4qIaq394u0iLOZbH8eIzZT4GPhy0KkPc0S yeLLULtaSLQfO+F0QF/IDBC7Dupl0nxGp5cOBfsBC8Eg+mBOEHHemmKkRqv4Cv7X kddw9bx+wjSYx0unDztyoLQ34c1XklIteOjzU+gLZtQkJ0W7+z3XQ42RwlIGPUbM dUKsYZ2rPsKjUl0gh4Gux0PyEMkokmpygqbxd8vmE1lnAJaRR4jMgcG45jv7eSLp ToGPNRVvuQUypmqkyIgVSCzBoplC4DkymS5oVy96GbNGNPypx3AhuAMpo8NwsH58 TNqetlVI9RQp2Yq4S930pSDmeqtel4G3zm6yJhmRfhpc28fnyrh7yzNwERKAqbpU rExTfGd6BJul0cirkujo9ni9OOV1ue2WjBTqhp74BsBWjse5Q9J92zWmbZ9umcu0 JNJHr3wq/Fx1E4ozoYcVIKRor7T5mj7JuZpm+cyH5/GPfPZTzb0zuJy4JqbIKqHp RfpE5eCLf16fZrB94NYz =02/m -END PGP SIGNATURE-
Re: [gentoo-dev] Killing UEFI Secure Boot
On Wed, Jun 20, 2012 at 04:35:41PM -0400, Richard Yao wrote: On 06/20/2012 04:20 PM, Greg KH wrote: On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote: On 06/20/2012 04:08 PM, Greg KH wrote: On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. No, neither of them replaces the BIOS in their machines with an opensource version. There is no BIOS in those platforms, it's just uboot or fastboot, the PC-like ecosystem is so vastly different it's laughable. The BIOS on our machines is analogous to the flash on those machines on which the firmware operates. There is no difference. There is a huge difference here, please do a bit of research before claiming otherwise. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. And I agree with that developer. Don't get replace all of userspace and the kernel confused with replace the UEFI bios. You do realize that the UEFI bios is at least double the size of the Linux kernel, with custom device drivers and tons of other stuff in there? Good luck replacing that... Replacing UEFI does not mean that we need a compatible replacement. Things like being able to boot Windows is unnecessary functionality that can be removed. The only thing replacement firmware must do is get the kernel loaded into memory, initialize the structures that the kernel wants and jump into it. That is it. A BIOS does much much more than just that. See the coreboot code for examples of what needs to happen to get a x86-like machine up and running to the point at which it is possible to hand off control to a bootloader. And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? To be clear, I was not talking about taking away options from users. I was talking about giving them options. You are taking secure boot out of their systems, that sounds like taking away an option to me :) I have an Asus motherboard that fails to boot when it has more than 6 hard drives. If I replaced its BIOS with our own firmware, I could fix that. If I had our own firmware and I wanted to do my own key signing, I could implement that. If were to replace UEFI with our own firmware, the user would have full view of the source code, rather than some mystery blob. The pool of people who could do bug fixes would increase and that in general would be a good thing. You do realize that the majority of the UEFI code is opensource, right? That's not the hard part here, the response from the coreboot developer should have given you a glimpse into the real difficulties involved. Technical hurdles will likely prevent this unless we an get vendors to release documentation. Is there any chance you could contact people at Intel requesting programming documentation on their memory controller and anything else we would need to write a small OS that we could flash in place of UEFI? Again, see the response from Peter about what is needed here. That anything else is not trivial. But feel free to prove me wrong, I love it when that happens :) greg k-h
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Jun 2012 17:02:10 -0400 Richard Yao r...@gentoo.org wrote: Lets address POSIX compliance in the ebuilds first. Then we can deal with the package managers. Why? It's highly doubtful the package manglers could switch shells even if they wanted to, and even if every ebuild started using EAPI 5. It's wasted effort. Source the ebuild using the system shell, check for WANT_SH. If it does not exist, proceed. If it does, start over with a different shell. I do not see any technical problem. Package managers don't source the ebuild... You should take a look at the amount of horrible bash code the three PMs have, and see why it's there. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/iPC8ACgkQ96zL6DUtXhH6rQCghGeOb2N8iOm9F5u7k9jJkn2s hcwAoKLB4kSHq7KaVh9D7mllQnU3U78Z =DLvZ -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Jun 2012 17:05:55 -0400 Richard Yao r...@gentoo.org wrote: The multilib-portage overlay already has this working. But there is no spec, nor is there a developer-centric description of it. I missed this tibbit. I am not sure what you expect me to do this about this. Thomas Sachau developed the multilib overlay, he has put a great deal of work into it and he likely has a specification. He has something, but it's nowhere near what's needed for someone to be able to either implement it independently or produce a PMS patch. General consensus seems to be that it needs a GLEP and a proposed diff against PMS before anyone can even reasonably pass comment on it, let alone accept it. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/iPKQACgkQ96zL6DUtXhG0xACfXFY/W9pck1Fl0qTR8vWWCCOC VLQAoLm0SJV42+bizP1wquNZKdKxvycF =PPkQ -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao r...@gentoo.org wrote: Here is my wishlist for EAPI 5: Multilib (and/or multiarch) support Automated epatch_user support Parallel make checks POSIX Shell compliance Here are some explanations: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. Automated epatch_user support Users should be able to test patches without modifying their ebuilds. This also saves developer time because we don't need to navigate the portage tree (or an overlay), make a change and test it. We could just dump the patch in the appropriate directory and build. Parallel make checks As it stands, `make check` is so slow that few people actually run it and QA suffers as a result. We have the ability to do parallel checks, but we need to explicitly put `emake check` into the ebuild and use autoconf 1.12 to get that. It would be best if this behavior were the default, not the exception. POSIX Shell compliance There has been a great deal of work done to give the user full control of what is on his system and there is more that we can do there. In particular, I think a lean Gentoo Linux system should be able to use busybox sh and nothing else. That requires POSIX shell compliance. OpenRC init scripts support this and the configure scripts support this. The few exceptions are bugs that are addressed by the Gentoo BSD developers. As such, I think we should make EAPI=5 use POSIX shell by default. If an ebuild requires bash, we can allow the ebuild to declare that (e.g. WANT_SH=bash), but that should be the exception and not the rule. Our ebuilds are written in bash. I dunno about you, but bash sucks for writing anything remotely complicated in. My goal is any script that is 200 lines of bash or more gets rewritten in something else (usually python.) I mean the canonical example here is the old python.eclass which was a masterful example of how bash can really be used to shoot yourself in the foot. However I'd argue that the opposite of what Ciaran said is true. Screw trying to get the PM to stop using bash; developers are not interested in writing ebuilds in posix shell; bar none. Why would I as an ebuild author waste a bunch of time writing my ebuild in posix compatible sh when I can use bash (and if I had a better language than bash to write ebuilds in; I'd use that too.) You are free to write your ebuilds in posix sh; good luck to you. -A
Re: [gentoo-dev] My wishlist for EAPI 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2012 05:12 PM, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 17:05:55 -0400 Richard Yao r...@gentoo.org wrote: The multilib-portage overlay already has this working. But there is no spec, nor is there a developer-centric description of it. I missed this tibbit. I am not sure what you expect me to do this about this. Thomas Sachau developed the multilib overlay, he has put a great deal of work into it and he likely has a specification. He has something, but it's nowhere near what's needed for someone to be able to either implement it independently or produce a PMS patch. General consensus seems to be that it needs a GLEP and a proposed diff against PMS before anyone can even reasonably pass comment on it, let alone accept it. A new EAPI implies a GLEP. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP4kIDAAoJECDuEZm+6Exk9vMP/0dP/XzzX0zifeyfHDl4wqdc RtfBbDX4C4Rm+5Ii8P/GbegDBxnZ+/SzBynx+d23mvNiAu1B5SKcAoa0dR5k2IIa IiftgPbu1nfPA9ijNcdhi6VlFbjXJVllJt3Q7BfZTu8sPrKiq0Qbi4fnpJP4OFVH XY/17GUhZy5sizpsqFIZQTggvcqVdkM99iZCey32egIhqXHM7tn8fl9StziP+dlE 4/JzkPqVCv8QojarxAGI3asQ3ysMzbVa2zRo9FGQtMi23AqiTvnakIahy6b+U5C1 holKFfTkCdp2mJAw8FHZtNeQ+DMAOSj069YTCct+fOIv6HaT5sAHYjO1ovSOkYRw VZ0SfwTlCr8dbFCpur1YbZkfBpDuhAtJq9MbQbzuqjXQXy6y2KQlHJDi7FHJCuDl 0xKlxb1nenRk1RbxWNz6Tc530G+AkwrMnqmIlEI5X1p8J6xXwDnA7I4uAUfXhnY2 Au72AeratlSIMBYuR75ocHaaFKDhK1bG0Yu1W3Kw7hwMwaEmWHLgAr4Ne/PynwUw /tck8Dl/F1vnnzR/YqY14rwC1b3tbuMdsGc2sO33sNHJw16EQTJklETV7KBhqQhf wej+MTZInbOMF0m4giyohJ+6jWaAXKQhsHo8+h1SmRY/0SLuIQPySPSI01y9Gcun PY3t9ESaVd9kZMo10trj =/oj6 -END PGP SIGNATURE-
Re: [gentoo-dev] My wishlist for EAPI 5
On 20.06.2012 22:35, Ciaran McCreesh wrote: On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote: Multilib (and/or multiarch) support The current binaries cause a great deal of pain, particularly when a user does not want to upgrade something. I had this problem with WINE and glibc because I wanted to avoid the reverse memcpy() fiasco on my systems. This situation would have been avoided entirely if the package manager supported multilib. This one's unlikely to happen unless someone's prepared to put in the work. Tommy worked a lot on this and he asked for help to bring his proposal/spec/glep into shape. We are all aware what this is all about and know that anybody who is using multilib would benefit. Can't you simply work with him together to get it into what you expect it to be instead of pointing out that it isn't? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/20/2012 05:09 PM, Greg KH wrote: Technical hurdles will likely prevent this unless we an get vendors to release documentation. Is there any chance you could contact people at Intel requesting programming documentation on their memory controller and anything else we would need to write a small OS that we could flash in place of UEFI? Again, see the response from Peter about what is needed here. That anything else is not trivial. But feel free to prove me wrong, I love it when that happens :) greg k-h You must not have read this, where I said that I realized that this is infeasible: On 06/20/2012 04:13 PM, Richard Yao wrote: Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. From what I can tell, the Core Boot developers could use that documentation. You yourself said If there's anything that anyone is thinking I should be doing but seem not to be, please let me know.. Do you have any intention of acting on that?
