Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 07:53:21 +0200 Luca Barbato [EMAIL PROTECTED] wrote: A whole bunch of science packages have upstreams that say If you're building from source, run 'make check' and if it fails don't carry on. Their rationale behind that is that their code is severely broken, using experimental features from their language of choice or, simply, that they are paranoid and couldn't think better ways to annoy people? Their rationale being that compilers and users screw up, and that detecting a failure before deployment is important for people who care about what programs do. Simple example... Take people who use Roy's broken patches from bug 192403. If you build a program that uses C++ exception handling using such a compiler, it'll compile just fine and then do very weird things at runtime. Test suites catch this, and spare a lot of everyone's time. For that matter, I'm strongly inclined to say that for Paludis too... Getting the build time from 30minutes to an hour or more? And saving your ass when you're using a broken compiler that generates broken code that would force you to reinstall a working compiler by hand when the package manager gets h0rked. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 07:58:44 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Oh, so Gentoo has decided that basic QA is another 'poor programming practice' now? Having a good testsuite is part of the QA, having it not failing is part of the QA, running it for supposedly tested code (thus having those test passed already) every time isn't. You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Tue, 10 Jun 2008 17:11:23 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote: On Tue, Jun 10, 2008 at 17:39, Doug Goldstein [EMAIL PROTECTED] wrote: At this point, we should really only discuss features that all 3 package managers have implemented. I'm not sure that's a good idea, only two have implemented EAPI 1 so far. 3 have. If you're aware of a pkgcore issue, then kindly file a bug rather then going for mocking on -dev. Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. http://www.pkgcore.org/trac/pkgcore/newticket lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:01:30 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Wed, 11 Jun 2008 07:49:44 +0200 Alexis Ballier [EMAIL PROTECTED] wrote: I thought tests were already supposed to pass whatever the EAPI is and devs were supposed to run them... Supposedly. But in practice this isn't true, because far too many developers just don't care. and having it forced in the eapi won't change this. Sure it will. They won't be able to install their package without either passing src_test or restricting it. Developers *do* try to install things before committing, right? Enforcing src_test in a you must explicitly say so if your package's test suites are expected to fail way on an EAPI bump is a clean way of recovering from this. You are assuming that every package has a test (false), nobody will have src_test dummified. Not at all. If upstream has no test suite, or developers choose to RESTRICT off test, it just means there's less QA being done for that package. But more importantly, it still means that people *know* that a failing src_test is to be investigated. Currently they instead have to guess whether it's a lazy developer issue or a genuine bug being shown. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:02:48 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. http://www.pkgcore.org/trac/pkgcore/newticket http://www.pkgcore.org/trac/pkgcore/ticket/197 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
On 2008/06/11, Ciaran McCreesh [EMAIL PROTECTED] wrote: You're missing the cases where the cache isn't usable. I was not talking about generating cache entries, and neither were you. I've replied to you because you were suggesting that the EAPI in ebuilds contents solution had extra cost when _using_ valid cache entries (need to extract the EAPI from the ebuild before reading this cache entry), which i think can be easily avoided. On 2008/06/10, Ciaran McCreesh [EMAIL PROTECTED] wrote: Currently we don't touch the ebuild's content *at all* for metadata operations, except where there's no or stale metadata cache (which is rare). We can get away with this currently because 0 and 1 have identical cache layouts and PMS has some (necessary) weasel wording; future EAPIs likely won't, so we're back to the chicken / egg problem. So... We either have the EAPI from the extension (which we already have, since we have to read the dir to know what versions are available), in which case we know how to read the metadata cache file. Or we have to open up a file that would otherwise not be opened, just to parse one line so we know how to read the cache file. -- TGL. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Wed, 11 Jun 2008 08:31:45 +0200 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: On 2008/06/11, Ciaran McCreesh [EMAIL PROTECTED] wrote: You're missing the cases where the cache isn't usable. I was not talking about generating cache entries, and neither were you. I've replied to you because you were suggesting that the EAPI in ebuilds contents solution had extra cost when _using_ valid cache entries (need to extract the EAPI from the ebuild before reading this cache entry), which i think can be easily avoided. And it does, since EAPI has to be known to use the cache contents. The way it's handled currently is a hack that doesn't work with future EAPIs defining new metadata. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Kelly wrote: | Wrong. Thanks for that. I'm gonna assume you meant I think you're wrong. | Sure, because of how the algorithm works, people could potentially do | both, but the GLEP makes it pretty clear that they shouldn't. It doesn't just say they shouldn't, it *says what happens if they do*: pkg-4.ebuild-2, EAPI=1 ~pre-source EAPI is 2, post-source EAPI is 1. EAPI 1 is used So to live up to the GLEP specification, package managers must source the ebuild to determine the correct EAPI. | Basically, you don't set the post-source EAPI. It is only supposed to | be used when the pre-source EAPI cannot be determined. If that's what was meant, the GLEP needs changing to say that. Something like: pkg-4.ebuild-2, EAPI=X ~Pre-source EAPI is 2, post-source EAPI is X. In this instance the post-source EAPI is ignored, since a pre-source EAPI is set, so EAPI 2 is used. It's not a big deal, but it will need a change to the GLEP in its current form, if that's what's meant. Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhPdRUACgkQu7rWomwgFXq1twCgqnFzBqQI8vl63faZ1cq27MF7 7ekAn0aA73nic1v/ovwAUuHsaL44MrTE =StC2 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Wed, 11 Jun 2008 07:53:21 +0200 Luca Barbato [EMAIL PROTECTED] wrote: A whole bunch of science packages have upstreams that say If you're building from source, run 'make check' and if it fails don't carry on. Their rationale behind that is that their code is severely broken, using experimental features from their language of choice or, simply, that they are paranoid and couldn't think better ways to annoy people? Their rationale being that compilers and users screw up, and that detecting a failure before deployment is important for people who care about what programs do. Simple example... Take people who use Roy's broken patches from bug 192403. If you build a program that uses C++ exception handling using such a compiler, it'll compile just fine and then do very weird things at runtime. Test suites catch this, and spare a lot of everyone's time. You are supposed to test proposed patches for opened bugs before deploying them in any way. Your example, that btw is a quite low try to smear Roy, proves nothing. And saving your ass when you're using a broken compiler that generates broken code that would force you to reinstall a working compiler by hand when the package manager gets h0rked. You (upstream) are supposed to test and early users are supposed to check their bleeding edge stuff is working if they care enough. People using released programs that are in stable shouldn't have to do that. If your code doesn't survive a gcc release usually it's the code being wrong most of the times. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:50:47 +0200 Luca Barbato [EMAIL PROTECTED] wrote: And saving your ass when you're using a broken compiler that generates broken code that would force you to reinstall a working compiler by hand when the package manager gets h0rked. You (upstream) are supposed to test and early users are supposed to check their bleeding edge stuff is working if they care enough. People using released programs that are in stable shouldn't have to do that. If everyone running stable used the same base system, tool chain and configuration you would be right. But every Gentoo system is different, so there's no common target to test on. And it's fairly well established that lots stable Gentoo users have broken toolchains... If your code doesn't survive a gcc release usually it's the code being wrong most of the times. If you have bad code, yes. If you have good code, instead it's usually gcc's fault. Things like gcc bug 31899 are common enough to be a nuisance. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:55:16 +0200 Luca Barbato [EMAIL PROTECTED] wrote: But more importantly, it still means that people *know* that a failing src_test is to be investigated. Currently they instead have to guess whether it's a lazy developer issue or a genuine bug being shown. Not really. Ok, if EAPI 2 turns on src_test except where explicitly overridden by the ebuild, explain how EAPI 2 src_test failures are meaningless in the same way that EAPI 0/1 src_test failures are. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:57:35 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. if your code sucks isn't our fault. - gcc upstream And those all too common cases where the code is correct and gcc gets it wrong? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] One-Day Gentoo Council Reminder for June
This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: Sure it will. They won't be able to install their package without either passing src_test or restricting it. Developers *do* try to install things before committing, right? No, they also write the ebuilds using cat /dev/urandom through a perl regexp. But more importantly, it still means that people *know* that a failing src_test is to be investigated. Currently they instead have to guess whether it's a lazy developer issue or a genuine bug being shown. Not really. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Wed, 11 Jun 2008 08:57:35 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. if your code sucks isn't our fault. - gcc upstream And those all too common cases where the code is correct and gcc gets it wrong? Get fixed. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 09:14:03 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Wed, 11 Jun 2008 08:57:35 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. if your code sucks isn't our fault. - gcc upstream And those all too common cases where the code is correct and gcc gets it wrong? Get fixed. And all those people running gcc versions that haven't had the fix applied yet? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: Ok, if EAPI 2 turns on src_test except where explicitly overridden by the ebuild, explain how EAPI 2 src_test failures are meaningless in the same way that EAPI 0/1 src_test failures are. Test failures aren't meaningless right now. Applications with good test suites got them used by the people that cares already. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 09:18:07 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Ok, if EAPI 2 turns on src_test except where explicitly overridden by the ebuild, explain how EAPI 2 src_test failures are meaningless in the same way that EAPI 0/1 src_test failures are. Test failures aren't meaningless right now. Applications with good test suites got them used by the people that cares already. The point you've been missing this whole time: If, as a user or an arch person, I get a src_test failure right now, I don't know whether this means eek! Something's gone wrong, and I really need to fix this or oh, whoever maintains this package doesn't care. But with EAPI 2, I'll be able to know that a src_test failure really does mean something's wrong. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, Jun 11, 2008 at 08:18, Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Ok, if EAPI 2 turns on src_test except where explicitly overridden by the ebuild, explain how EAPI 2 src_test failures are meaningless in the same way that EAPI 0/1 src_test failures are. Test failures aren't meaningless right now. Applications with good test suites got them used by the people that cares already. If you care about tests now, how do you know if foo.ebuild failed its src_test because there's a problem or if src_test failed because no one else has ever run it with test in FEATURES? Also, I think you seem to be suggesting that gentoo is so well tested that once something's marked stable, there's no point in testing it. -- Richard Brown -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
If you need eapi in file name what are the technical reasons of putting it into file name extension? Why don't you suggest better ebuild name like: pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ? I remember last time I've asked this genone told me that this is not backward compatible. Ok, it's not, but what's the problem to change extension once only for this change? Call you new files like pkg-ver-eapi.emerge and that's it! What is the need to change extension every time you introduce new eapi? Another possibility is to implement this new file format and wait another one year before using it instead of crapping the tree for years with such eapi-extesions... -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
On Wed, 11 Jun 2008 11:25:50 +0400 Peter Volkov [EMAIL PROTECTED] wrote: If you need eapi in file name what are the technical reasons of putting it into file name extension? Why don't you suggest better ebuild name like: pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ? a) breaks current package managers b) has no unambiguous parsing c) looks confusing. pkg-1.2.3-1.ebuild or pkg-1-1.2.3.ebuild look a lot like Debian-style foo-1.2-3 versions... I remember last time I've asked this genone told me that this is not backward compatible. Ok, it's not, but what's the problem to change extension once only for this change? It means next time we want to introduce another backward incompatible change, we have to go through the whole mess all over again. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On 00:11 Wed 11 Jun , Bo Ørsted Andresen wrote: I would like the portage devs to comment upon which of the following features they think could easily be implemented before portage 2.2 goes stable. These ones meet the criteria of I know people are working around them because they don't exist yet, and it's annoying and extra work: - Use dependencies, it's not clear to me whether we all agree entirely upon the syntax yet though (bugs #2272 and #174406) - Custom output names in SRC_URI, also called arrows (bug #177863) - Limit values in $USE (bug #176467) - GLEP 42 - news items - maint_*, it's not clear to me if this has been fleshed out in sufficient detail yet (bug #185567) - default_*, allows an ebuild to redefine phases to add more functionality and then call default_$phase. Currently the default phases are lost when redefining the phases. - default for src_install (bug #33544) - Ranged dependencies (bug #4315) Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Wed, Jun 11, 2008 at 04:14:58AM +0100, Ciaran McCreesh wrote: On Tue, 10 Jun 2008 19:14:11 +0200 Olivier Galibert [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote: Except that currently, the ebuild file isn't opened for read. So it's not in memory at all. Why would you need the EAPI before the time when you actually want to interpret the contents? You need the EAPI before you use the metadata. But you don't need the ebuild to get the metadata in the common case. The metadata should carry its version indicator too. OG. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote: !-- EAPI=3 -- *Then* would be the time to change the extension. As long as the ebuild is bash-parseable with an appropriate environment, it doesn't make sense to change the extension because a env-variable set or a comment are more natural methods. If/when the format changes to something not parseable by bash, then it will be time to change the extension. And then how to mark (sub-)version will depend on the chosen new format, in case of xml that would be the dtd information. I suspect the rejection of the extension change will be there as long as the fundamental format (bash script) doesn't change. OG. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, Jun 11, 2008 at 7:53 AM, Luca Barbato [EMAIL PROTECTED] wrote: A whole bunch of science packages have upstreams that say If you're building from source, run 'make check' and if it fails don't carry on. Their rationale behind that is that their code is severely broken, using experimental features from their language of choice or, simply, that they are paranoid and couldn't think better ways to annoy people? It's not as simple as that. A package may fail tests because compiler bugs, build environment misconfiguration, problems in a library which is being used, a setup problem or, of course, a bug in the package which shows up in rare cases and haven't been spoted by upstream yet. When the package can be critical for the system, upgrading to a buggy version will eat people's dogs. I feel a bit safer when I run the test phase for my package manager, and I wouldn't install it if it's failing any test. I don't think that's too paranoid. Also let's put a real example: gmplib. From www.gmplib.org on the front page: IMPORTANT INFORMATION FOR ALL GMP USERS: GMP is very often miscompiled! We are seeing ever increasing problems with miscompilations of the GMP code. It has now come to the point where a compiler should be assumed to miscompile GMP. Please never use your newly compiled libgmp.a or libgmp.so without first running make check. If it doesn't complete without errors, don't trust the library. Please try another compiler release, or change optimization flags until it works. If you have the skill to isolate the problem, please report it to us if it is a GMP bug; else to the compiler vendor. (The compilers that cause problems are HP's unbundled compilers and GCC, in particular Apple's GCC releases.) Upstream clearly states that a gmp build which tests have failed shouldn't be used. I bet they deny support for users who fail to follow that indication ;-) Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
On Wed, Jun 11, 2008 at 03:06:17AM +, Mike Frysinger wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Reiterating the early request, I'd like the council to please discuss the current status of PMS, if the running of it satisfys the councils requirements of a *neutral* standard, if the proposed spec actually meets said standards, and if said spec is actually going to be approved sometimes this side of '09. Effectively, we've watched it essentially progress into a standard that effectively only the paludis folk are adherent to (if in doubt, ask portage folk, my sending this mail is indicative of the pkgcore standpoint)- it's about time the council comment upon it in light of the general view. Yes, ciaran shall comment. My request still stands. Thanks, ~harring pgppkOFB8eMEA.pgp Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Wed, 11 Jun 2008 08:02:48 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. http://www.pkgcore.org/trac/pkgcore/newticket http://www.pkgcore.org/trac/pkgcore/ticket/197 Uh - what is the goal on this list - to make Gentoo a better distribution or to point out that the package manager that I maintain is better than the package manager that you maintain? Gentoo is served by having lots of package managers that all work well. If somebody knows of a bug and intentionally doesn't report it, they're being rather selfish. That's like posting ha, ha - I found a zero-day exploit in apache and if you were as elite as me you'd have found it in your testing! There is an old adage - if you're not part of the solution you're part of the problem. And if you don't want to be part of the solution, then why are you wasting your time here? I'm a big fan of PMS/paludis/etc in general, but why waste your time contributing these things to Gentoo if you don't want Gentoo to succeed? If you do want Gentoo to succeed, then why not give others a helping hand when it costs you virtually nothing to do so? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 06:55:45 -0400 Richard Freeman [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Wed, 11 Jun 2008 08:02:48 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. http://www.pkgcore.org/trac/pkgcore/newticket http://www.pkgcore.org/trac/pkgcore/ticket/197 Uh - what is the goal on this list - to make Gentoo a better distribution or to point out that the package manager that I maintain is better than the package manager that you maintain? The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. And if you don't want to be part of the solution, then why are you wasting your time here? I'm a big fan of PMS/paludis/etc in general, but why waste your time contributing these things to Gentoo if you don't want Gentoo to succeed? If you do want Gentoo to succeed, then why not give others a helping hand when it costs you virtually nothing to do so? Give a man a bug report and he fixes one bug. Persuade a man to write basic unit tests and he fixes a whole load of bugs and catches a whole load more in the future before shipping them out. And then you give him bug reports for what that doesn't catch. The problem is, the pkgcore people are being blatantly irresponsible by sticking a package manager that claims to support EAPI 1 in the tree without actually supporting EAPI 1. In particular, it means we'll have to decide whether to avoid using some EAPI 1 features just to avoid breaking people using older pkgcore versions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Wed, Jun 11, 2008 at 06:51:46AM +0100, Ciaran McCreesh wrote: On Wed, 11 Jun 2008 07:46:39 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Tue, 10 Jun 2008 22:33:41 -0700 Brian Harring [EMAIL PROTECTED] wrote: Lay out how .006/.6 would work properly *per* eapi. As I clarified in my last email, the master would vary dependant on the eapi- which isn't valid unless you're retroactively overriding the versioning rules of an eapi. Must be a superset being wrong does not mean entirely arbitrary changes are OK is right. You have actual usecases (eventually not thin air), which is your counterproposal that works for them? Care to rephrase that in English? I'm not proposing anything, so I'm at a loss as to what you're going on about here. Being that you can't understand the problem you're commenting on, I'll explain it for you. While you can remove _p1, or _random_suffix you cannot change the ordering of an existing version component. Simple example you should grok, changing of 1_p1 such that it's 1.0 is not valid. As I've indicated repeatedly in this thread, and y'all have missed, you cannot change the semantics of the ordering. Sure, you could remove a version component from usage- that said, you cannot change it's ordering. Further, you cannot change the ordering of an existing version- if you can't understand why shifting 0.006 to equivalent to 0.6, then frankly, this discussion need not continue. Cheers. ~harring pgpklKPIXKZ71.pgp Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, Jun 11, 2008 at 08:23:59AM +0100, Richard Brown wrote: Also, I think you seem to be suggesting that gentoo is so well tested that once something's marked stable, there's no point in testing it. A very good point. Just last week the *stable* perl cairo bindings were broken by a x11-libs/cairo bump. We caught this however and noticed that the new perl cairo bindings worked. Those were then stabilized at the same time and users now have a working cairo. What would have happened if that hadn't happened? Any package that depended on dev-perl/Cairo would've been broken. The lesson to learn is that once something is stable doesn't mean it's always stable. If a user finds out that way and files a bug, chances are greater that he'll get a dev-perl/Cairo that works with the new cairo version soon, rather than a dev-perl/Cairo version that breaks immediately. What would you rather have? pgpbdD6ZaLPYT.pgp Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
On Wednesday 11 June 2008 12:11:33 Brian Harring wrote: Effectively, we've watched it essentially progress into a standard that effectively only the paludis folk are adherent to (if in doubt, ask portage folk, my sending this mail is indicative of the pkgcore standpoint)- it's about time the council comment upon it in light of the general view. Paludis isn't completely compliant either. Not sure what you're referring to about portage and pkgcore... if you mean kdebuild, then a) the Council has decided that that won't be part of the official approved version, and b) PMS only describes what kdebuild is, it doesn't say that any package manager has to implement it. As long as it's not being used in the main tree, that's up to the package manager maintainers, and what they think is most beneficial to their users. If you mean something else, feel free to file bugs, it could well be just an oversight. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Wed, Jun 11, 2008 at 12:06 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 11 Jun 2008 08:31:45 +0200 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: On 2008/06/11, Ciaran McCreesh [EMAIL PROTECTED] wrote: You're missing the cases where the cache isn't usable. I was not talking about generating cache entries, and neither were you. I've replied to you because you were suggesting that the EAPI in ebuilds contents solution had extra cost when _using_ valid cache entries (need to extract the EAPI from the ebuild before reading this cache entry), which i think can be easily avoided. And it does, since EAPI has to be known to use the cache contents. The way it's handled currently is a hack that doesn't work with future EAPIs defining new metadata. Fix that, then. And I understand that the code is already there in both portage and pkgcore to store the cache as key-value pairs rather than one-slot-per-key, and would be relatively trivial to add to paludis. Regards, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
On 11 Jun 2008, at 13:11, Brian Harring wrote: On Wed, Jun 11, 2008 at 03:06:17AM +, Mike Frysinger wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Reiterating the early request, I'd like the council to please discuss the current status of PMS, if the running of it satisfys the councils requirements of a *neutral* standard, if the proposed spec actually meets said standards, and if said spec is actually going to be approved sometimes this side of '09. Effectively, we've watched it essentially progress into a standard that effectively only the paludis folk are adherent to (if in doubt, ask portage folk, my sending this mail is indicative of the pkgcore standpoint)- it's about time the council comment upon it in light of the general view. Did you send patches for those parts you don't agree with? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Vlastimil Babka [EMAIL PROTECTED] wrote:
I would prefer something that
doesn't add extra lines to ebuild.
I think I would disagree with you here. I think that having a special
'eblank' or 'eseparator' command is much more readable in an ebuild.
Consider:
pkg_postinst() {
elog Knock knock
eblank
ewarn Who's there?
eblank
elog Interrupting Cow
eblank
ewarn Interrup...
elog Moo!
}
Versus:
pkg_postinst() {
elog -p Knock knock
ewarn Who's there?
elog -pt Interrupting Cow
ewarn Interrup...
elog Moo!
}
I think that in the former case it's much more obvious how the actual
output is going to look. If the cost is an ebuild that's 3 lines
longer, I think that's reasonable.
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
signature.asc
Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
Ciaran McCreesh wrote: http://en.wikipedia.org/wiki/Straw_man http://en.wikipedia.org/wiki/Quote_mining -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] extending existing EAPI semantics
On Wed, Jun 11, 2008 at 12:58, Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: http://en.wikipedia.org/wiki/Straw_man http://en.wikipedia.org/wiki/Quote_mining http://en.wikipedia.org/wiki/Idiot -- Richard Brown -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Santiago M. Mola wrote: It's not as simple as that. A package may fail tests because compiler bugs, build environment misconfiguration, problems in a library which is being used, a setup problem or, of course, a bug in the package which shows up in rare cases and haven't been spotted by upstream yet. May happen indeed. When the package can be critical for the system, upgrading to a buggy version will eat people's dogs. I feel a bit safer when I run the test phase for my package manager, and I wouldn't install it if it's failing any test. I don't think that's too paranoid. The main point is that it could be overly bothersome, if you depend on certain applications you won't just use the standard testsuite but also run your batch of compliance checks, but that isn't common. Upstream clearly states that a gmp build which tests have failed shouldn't be used. I bet they deny support for users who fail to follow that indication ;-) gmp isn't a key component if you aren't using math/sci applications using it. You may point openssl as something you may want to have a round of checks before is too late, same for openssh. Still there are people perfectly happy w/out those since they do not use those packages that for me and possibly many other are vital. I won't be happy to have gcc have its batch of tests run, just to see later it fails on ffmpeg because the tests do not catch those conditions, I have better way to break gcc than those you have in the regression test =/ Changing the default features would just at best have people that do not care switch to -test, people that care already about that won't be affected and just create an annoyance. Putting it in an eapi makes not much sense as well since you may change the defaults as you wish since they aren't causing incompatibilities. To sum up: - having the test feature on by default isn't good for anybody but paranoids and lazy developers, paranoids have that already on, lazy developers will switch it off for them and let people do the automated test for them. - having that mandated by the eapi doesn't have sense since it doesn't change anything by itself. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? Talking away problems, now that is a way to handle QA. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? No, it's just unsubstantiated rumors. As such they are irrelevant until some kind of proof is shown. Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? It is too generic and doesn't even describe the class of bug. By the same rationale portage and paludis have multiple bugs ... Talking away problems, now that is a way to handle QA. So, could anyone just actually mention what the problem is, or is the hivemind not able to express such a simple thing? Just think of the thousands of emails, being read by hundreds of readers, that have cost so much time ... in that time you could have written a patch and a bugreport. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: GLEP 55
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 10 Jun 2008 15:00:18 +0100: On Tue, 10 Jun 2008 09:49:04 -0400 Richard Freeman [EMAIL PROTECTED] wrote: 4) Putting EAPI inside the ebuild, but in a manner that does not require sourcing using bash (ie comment at top of file). - it doubles the number of file reads necessary during resolution. No comment, except that it should be cached after the first one, so the second read should be a memory read. - it heavily restricts future syntax and meaning of EAPIs I don't see this. Putting it at a defined place in the ebuild and parsing it pre-source nails down the problem such that if a future format change is further incompatible, a primary EAPI can be defined that defines a further extension, a second line to look at in the ebuild, some external file, the filename, whatever, for the additional sub-eapi or whatever detail, much as extensions to various Internet RFCs have done when they've wanted to extend beyond what would fit in the then-current definitions. It does little to restrict the ultimate combined primary/secondary EAPI, where the primary simply defines where and how to look for the secondary. - it makes comments have meaning Only if we choose the comment format, and then no more than shebang and similar solutions do. In the latter case it's an already recognized *ix solution. In the former, it's entirely possible to use a backward compatible EAPI= simple assignment that can be pre-parsed, and use the sub-eapi (minor part, in terms discussed elsewhere) if necessary to further define it using functions or the like. That said, I don't see the big deal to putting it in the file extension, when we're already breaking traditional content-defines-type rules by decreeing .ebuild extensions in the first place. I'd personally like to keep it a one-time fixed extension change, if only to force some discipline on the proliferation by forcing each new change to be reauthorized, meaning it's /really/ needed or it's simply not worth the trouble, but really, the precedent was already set when we accepted metadata in filename with the .ebuild thing in the first place, so there's little reason to fight it now, unless the proposal also eliminates that, and backward compatibility with it. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 14:49:19 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. EAPI 1 is entirely specified in terms of a diff against EAPI 0. Checking every part that's changed before releasing an EAPI 1 package manager is the least any responsible person would do. That they would release a version without doing such basic tests shows you just how much they care about Gentoo... Assuming that Ciaranm isn't just lying knowingly it's just plainly rude, otherwise it is pure malice. What, asking the pkgcore people to test their code before releasing a version that claims to support EAPI 1 but actually doesn't, forcing people to avoid using some of EAPI 1 to avoid breaking pkgcore, is malice? The whole EAPI lets us do upgrades cleanly process is broken when people release a package manager that claims to support a certain EAPI but doesn't. If pkgcore had any actual users we'd have to consider banning EAPI 1 in the tree and releasing EAPI 2 as being identical to EAPI 1 just to work around this. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Patrick Lauer schrieb: Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? No, it's just unsubstantiated rumors. As such they are irrelevant until some kind of proof is shown. It might be, but it might also be a bug. Of course the maintainers can choose if they go after it. BTW: The Paludis maintainers did have a look at the security hole you pointed out, even though everyone knows, that you spread lies about Paludis... Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? It is too generic and doesn't even describe the class of bug. By the same rationale portage and paludis have multiple bugs ... It is indeed generic, but then you should test every part of EAPI. The main point was, that test are missing and the fact, that there is might be a bug, that they didn't catch yet is a follow up. Of course, filing a bug report for a single issue might get that issue fixed, but what caused this issue to be still there (missing tests) will still be there. Talking away problems, now that is a way to handle QA. So, could anyone just actually mention what the problem is, or is the hivemind not able to express such a simple thing? Just think of the thousands of emails, being read by hundreds of readers, that have cost so much time ... in that time you could have written a patch and a bugreport. Again, one patch and one bug report wouldn't wipe out the problem in the long term view. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: EAPI 1 is entirely specified in terms of a diff against EAPI 0. That doesn't have a complete definition by itself. Checking every part that's changed before releasing an EAPI 1 package manager is the least any responsible person would do. That they would release a version without doing such basic tests shows you just how much they care about Gentoo... Again smearing without substance. Assuming that Ciaranm isn't just lying knowingly it's just plainly rude, otherwise it is pure malice. What, asking the pkgcore people to test their code before releasing a version that claims to support EAPI 1 but actually doesn't, forcing people to avoid using some of EAPI 1 to avoid breaking pkgcore, is malice? Saying that w/out giving any substance? Sure! The whole EAPI lets us do upgrades cleanly process is broken when people release a package manager that claims to support a certain EAPI but doesn't. If pkgcore had any actual users we'd have to consider banning EAPI 1 in the tree and releasing EAPI 2 as being identical to EAPI 1 just to work around this. Apparently those users do not see the problem, you do, help those blind people. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Luca Barbato schrieb: Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? He doesn't point any issue in particular. And that wasn't the point. He pointed out, that there is an issue, that hasn't been caught because of missing tests. Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. It really doesn't matter how it is specified. You have an implementation of it and should make sure, that this implementation works. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, Jun 11, 2008 at 02:00:19PM +0100, Ciaran McCreesh wrote: On Wed, 11 Jun 2008 14:49:19 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. EAPI 1 is entirely specified in terms of a diff against EAPI 0. Checking every part that's changed before releasing an EAPI 1 package manager is the least any responsible person would do. That they would release a version without doing such basic tests shows you just how much they care about Gentoo... Assuming that Ciaranm isn't just lying knowingly it's just plainly rude, otherwise it is pure malice. What, asking the pkgcore people to test their code before releasing a version that claims to support EAPI 1 but actually doesn't, forcing people to avoid using some of EAPI 1 to avoid breaking pkgcore, is malice? The whole EAPI lets us do upgrades cleanly process is broken when people release a package manager that claims to support a certain EAPI but doesn't. If pkgcore had any actual users we'd have to consider banning EAPI 1 in the tree and releasing EAPI 2 as being identical to EAPI 1 just to work around this. Ya know ciaran, I've just got to point out that you spend quite a large amount of time talking about pkgcore. Literaly- you talk about it more then I do. I could point out how paludis (or portage) has picked up the misc functionality pkgcore (then known as saviour, or ebd) established 4 years back, but hey, I'm not petty like you. Generators aren't at all like the basic repository concept, no sir. But you know that, of course, and of course you've got nothing to worry about from pkgcore, no sir. Alternatively, I'll take your tack- eapi1 actually isn't supported by paludis. Ask me what bug, please, trust me I'll make it entertaining for the gentoo-dev readers. ~harring pgpUGXDUUerqT.pgp Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? He doesn't point any issue in particular. Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. Assuming that Ciaranm isn't just lying knowingly it's just plainly rude, otherwise it is pure malice. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 15:05:47 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: EAPI 1 is entirely specified in terms of a diff against EAPI 0. That doesn't have a complete definition by itself. It's more than enough to write unit tests to ensure that all things changed from 0 to 1 are functioning correctly. Checking every part that's changed before releasing an EAPI 1 package manager is the least any responsible person would do. That they would release a version without doing such basic tests shows you just how much they care about Gentoo... Again smearing without substance. So you're saying they did do adequate testing before releasing, and that you're happy to have the use of EAPIs in Gentoo's tree being restricted by pkgcore's level of testing? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 06:08:20 -0700 Brian Harring [EMAIL PROTECTED] wrote: Ya know ciaran, I've just got to point out that you spend quite a large amount of time talking about pkgcore. Literaly- you talk about it more then I do. Unfortunately, since you don't care about implementing EAPIs correctly, I have to worry about it. Kinda important to make sure that PMS is universal, you know... Generators aren't at all like the basic repository concept, no sir. Er, no, they aren't. They're an entirely different model. It's good to see you're trying to learn how to be a better programmer by avidly reading everything I write, but please pay more attention. Confusing generators and repositories is about on par with confusing a spoon and an apple pie. Alternatively, I'll take your tack- eapi1 actually isn't supported by paludis. Ask me what bug, please, trust me I'll make it entertaining for the gentoo-dev readers. Ah, but I have unit tests, so I can be confident when I say that we're correctly implementing the EAPI 1 changes. Unlike you, I don't have such a high degree of confidence in Paludis contributors' (including myself) abilities to write perfect code the first time that I let changes go through without testing to ensure that they work. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Bernd Steinhauser wrote: He doesn't point any issue in particular. And that wasn't the point. He pointed out, that there is an issue, that hasn't been caught because of missing tests. That may or may not exist because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. It really doesn't matter how it is specified. You have an implementation of it and should make sure, that this implementation works. Seems to works well enough for people using it. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
David Leverton [EMAIL PROTECTED] wrote: Since at least one ebuild has already been modified specifically to work around the bug, I'd say it's pretty real. For those of us trying to play along at home, which one is this? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 15:34:43 +0200 Patrick Lauer [EMAIL PROTECTED] wrote: Presumably those people, if they exist, haven't tried to go through and install every EAPI 1 package in the tree (excluding KDE, since that's big and slow, and starting backwards since the x11- categories are nice and pretty). I did. Can't reproduce. Go away. Then you should probably see a doctor. Also, you should really check your results a lot more carefully -- perhaps there's also a bug in your build tool that makes it not recognise when something fails? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
If, as a user or an arch person, I get a src_test failure right now, I don't know whether this means eek! Something's gone wrong, and I really need to fix this or oh, whoever maintains this package doesn't care. But with EAPI 2, I'll be able to know that a src_test failure really does mean something's wrong. A developer should always care about src_test in my opinion. That some developers don't is a nuisance, and the core of the problem. But trying to change this via EAPI is doing things the wrong way round: At first there has to be an agreement about the importance of test suites (backed up by strict policies that every developer is bound to), and then we can discuss if it makes sense to activate them by default in EAPI-X. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] extending existing EAPI semantics
2008/6/11 Richard Brown [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 12:58, Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: http://en.wikipedia.org/wiki/Straw_man http://en.wikipedia.org/wiki/Quote_mining http://en.wikipedia.org/wiki/Idiot The following should effectively end this string of Wikipedia references: http://en.wikipedia.org/wiki/Flaming_(Internet) http://en.wikipedia.org/wiki/Personal_attacks Thank you, and have a nice day|night. -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Olivier Galibert [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote: !-- EAPI=3 -- *Then* would be the time to change the extension. As long as the ebuild is bash-parseable with an appropriate environment, it doesn't make sense to change the extension because a env-variable set or a comment are more natural methods. If/when the format changes to something not parseable by bash, then it will be time to change the extension. And then how to mark (sub-)version will depend on the chosen new format, in case of xml that would be the dtd information. I suspect the rejection of the extension change will be there as long as the fundamental format (bash script) doesn't change. Well said. This is something that I've heard bandied about on IRC now and then, and sounds to me (notably *not* a package manager developer) like a fairly reasonable compromise. To the proponents of GLEP55: Is there some reason that GLEP55 is preferable to this? Are there reasons why a particular filename extension could not apply to a range of EAPIs? Why not just bump the filename suffix when it is required to support a new EAPI that breaks the sourcing rules of previous EAPIs? Or will backwards-incompatible changes be happening so frequently that the package suffix will have to change for every EAPI bump anyway, which would make this proposal equivalent to GLEP55? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
On Wed, Jun 11, 2008 at 12:05 PM, Olivier Galibert [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote: !-- EAPI=3 -- *Then* would be the time to change the extension. As long as the ebuild is bash-parseable with an appropriate environment, it doesn't make sense to change the extension because a env-variable set or a comment are more natural methods. If/when the format changes to something not parseable by bash, then it will be time to change the extension. And then how to mark (sub-)version will depend on the chosen new format, in case of xml that would be the dtd information. I suspect the rejection of the extension change will be there as long as the fundamental format (bash script) doesn't change. If the extension was based on the fact that ebuilds are bash scripts, they'd have .bash extension. The .ebuild extension means a specific kind of bash script and it doesn't seem wrong to change the extension if that specific kind changes, even if bash is still the interpreter. Even if we switched to sh or zsh I doubt we'd use the .sh or .zsh extension. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Thu, Jun 12, 2008 at 4:07 AM, Jim Ramsay [EMAIL PROTECTED] wrote: Why not just bump the filename suffix when it is required to support a new EAPI that breaks the sourcing rules of previous EAPIs? Or will backwards-incompatible changes be happening so frequently that the package suffix will have to change for every EAPI bump anyway, which would make this proposal equivalent to GLEP55? That works. Although, we'd have to keep track of two parameters when setting our EAPI. One being the EAPI itself and the suffix needed for that EAPI. So this doesn't seem to make the problem simpler. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
В Срд, 11/06/2008 в 08:34 +0100, Ciaran McCreesh пишет: On Wed, 11 Jun 2008 11:25:50 +0400 Peter Volkov [EMAIL PROTECTED] wrote: If you need eapi in file name what are the technical reasons of putting it into file name extension? Why don't you suggest better ebuild name like: pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ? a) breaks current package managers That's why I suggested to change .ebuild extension or fix package manager now and wait another year to start using such syntax. Your answer about extension change It means next time we want to introduce another backward incompatible change, we have to go through the whole mess all over again. is not clear. What changes you have in mind? If we already have pkg, eapi and version in filename what else are you going to add there? b) has no unambiguous parsing Why? For example, just add word eapi and that it: pkg-1.2.3-eapi-1.bld. That's just an example to show that this is possible. c) looks confusing. pkg-1.2.3-1.ebuild or pkg-1-1.2.3.ebuild look a lot like Debian-style foo-1.2-3 versions... Well for me .ebuild-eapi is much more confusing. I still don't see why it's impossible to have eapi as a part of name but not in extension... -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: Presumably those people, if they exist, haven't tried to go through and install every EAPI 1 package in the tree (excluding KDE, since that's big and slow, and starting backwards since the x11- categories are nice and pretty). Nice game, still you aren't giving substance to your claims. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
Peter Volkov wrote: Well for me .ebuild-eapi is much more confusing. I still don't see why it's impossible to have eapi as a part of name but not in extension... Although putting EAPI in the name and not the extension is *slightly* preferable to using the extension, I still do not think that it even belongs there for one main design-based reason: It does not have to be there from a design perspective. All other filename components (name-version-revision.ebuild) uniquely identify the ebuild. EAPI does not (it is meta-information only needed internally by the package manager or by someone interpretting the contents of the file). You could not have two ebuilds, for example, that have identical name/version/revision but different EAPIs - that would not make sense (and yet it would be possible if the EAPI were in the filename, causing the package manager to need rules for choosing the right ebuild to look at). The argument for putting the EAPI in the extension or filename is simply to address a particular technical implementation detail, and there are other, better, ways to solve the problem in my opinion. I would argue that GLEP 54 is also putting needless extra stuff in the filename, but we won't go there right now. :) -Joe -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: GLEP 55
Duncan [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 11 Jun 2008 12:52:24 +: Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 10 Jun 2008 15:00:18 +0100: On Tue, 10 Jun 2008 09:49:04 -0400 Richard Freeman [EMAIL PROTECTED] wrote: 4) Putting EAPI inside the ebuild, but in a manner that does not require sourcing using bash (ie comment at top of file). - it doubles the number of file reads necessary during resolution. No comment, except that it should be cached after the first one, so the second read should be a memory read. Yeah, replying to myself... Having read the metadata-file/ebuild discussion, I see that despite the current sourcing requirement, it's not being done in practice for dependency building during which the EAPI is a necessary data point. Only the metadata is being read, thus speeding up the process where seeks between metadata and the ebuild would otherwise be needed. While a single additional seek per ebuild would suffice (it'd be in cache after that), that could still add up to a LOT of extra seeks (with the resultant time and cache usage increase), especially on an --emptytree world or similar. Still, it's essentially required by the current spec even if the now- current EAPIs manage to avoid it due to similarity of the current EAPIs, so it'd be no new imposition. The question then becomes, if everything else needed is stored in the pre- generated metadata cache, why isn't this? Shouldn't it be there along with the rest of the (meta)data used for building the dependency tree, thus avoiding the extra seek? Why not put it in the ebuild as is the dependency data, then along with said dependency data, copy it to metadata cache when it's generated? As for backward compatibility on the metadata, append or separate (single per repository) file. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On 2008-06-10 15:50, Fernando J. Pereda uttered these thoughts: On 10 Jun 2008, at 15:46, Joe Peterson wrote: Also, I'm not sure reading XML is a problem at all - python has good libs for this already. Reading XML files is easy, but it makes certain codepaths much much slower. Not a good 'feature'. ... AND there's no requirement for the PM to be written in python or any other language currently in use. -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpuqnCKU4eqn.pgp Description: PGP signature
Re: [gentoo-dev] profile shift for arm/s390/sh from stable to dev
On Saturday 31 May 2008, Mike Frysinger wrote: On Saturday 31 May 2008, Mike Frysinger wrote: ive made this shift in profiles.desc: sed -ir '/^(arm|s390|sh)/s:stable:dev:' profiles.desc if/when we get dedicated arch maintainers, they can think about shifting back for the confused ... you should still be adding these arches for stable requests and you should not be dropping their keywords -mike Just for the extra dense among us, does this mean that when a security bug such as 216850[1] gets closed with no response from those arches, that in such cases we are allowed punt the affected ebuild, even though it will break your stable? [1] http://bugs.gentoo.org/216850 -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote: David Leverton [EMAIL PROTECTED] wrote: Since at least one ebuild has already been modified specifically to work around the bug, I'd say it's pretty real. For those of us trying to play along at home, which one is this? http://tinyurl.com/4w4t69 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wednesday 11 June 2008 19:00:16 David Leverton wrote: On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote: David Leverton [EMAIL PROTECTED] wrote: Since at least one ebuild has already been modified specifically to work around the bug, I'd say it's pretty real. For those of us trying to play along at home, which one is this? http://tinyurl.com/4w4t69 Why the need for EAPI=1? A cursory glance shows nothing unusual. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On 11-06-2008 20:24:18 +0100, Roy Marples wrote: On Wednesday 11 June 2008 19:00:16 David Leverton wrote: On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote: David Leverton [EMAIL PROTECTED] wrote: Since at least one ebuild has already been modified specifically to work around the bug, I'd say it's pretty real. For those of us trying to play along at home, which one is this? http://tinyurl.com/4w4t69 Why the need for EAPI=1? A cursory glance shows nothing unusual. slot deps -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: profile shift for arm/s390/sh from stable to dev
Hi, Peter Alfredsen [EMAIL PROTECTED]: Just for the extra dense among us, does this mean that when a security bug such as 216850[1] gets closed with no response from those arches, that in such cases we are allowed punt the affected ebuild, even though it will break your stable? No. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Agenda [WAS: One-Day Gentoo Council Reminder for June]
On 03:06 Wed 11 Jun , Mike Frysinger wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). Here's the proposed agenda. I intend to get every requested topic on the agenda so there is no need for an open floor afterwards. Carefully note the Preparation sections. If they aren't completed, we will postpone the topic to the -council mailing list or the next meeting instead of waste time during the meeting doing things that should've happened in advance. Please respond with any suggestions, including suggested order of the topics by urgency (within old topics and new topics). Unfortunately not all of the topics were posted to the council meeting reminder thread, so it was hard to dig them out. More meeting optimization - I'd like to also set a 2-hour limit on the meeting. Anything we don't hit during that timeframe will be postponed to the list or the next meeting. We can also take an idea from http://en.opensuse.org/Meetings/About and set the +zmn channel modes: * +m - Moderated - People who don't have voices (+v) can't send messages to the channel. * +n - No external messages - With this mode, no one can send messages to the channel without even being joined. * +z - Relaxed moderation - When +z is set each message that would be blocked by +m is sent to all the users who are currently operator. That will allow council members to see everything said by everyone, but non-council people will not be able to see things said by other non-council people. Then +v can be given to anyone with good contributions. What do you think? Thanks, Donnie Updates to last month's topics == http://www.gentoo.org/proj/en/council/meeting-logs/20080508-summary.txt Document of being an active developer - Requested attendees: araujo Last month: Numerous suggested improvements to info on the certificate. Preparation: araujo needs to post progress, an updated certificate and any new requests to the gentoo-council or gentoo-project list 2+ hours before the meeting. Goal: Suggest changes. This should happen on-list. No discussion expected. Slacker arches -- Preparation: vapier needs to send the post 2+ hours before the meeting. Goal: Suggest changes. This should happen on-list. No discussion expected. Can the council help fewer bugs get ignored by arm/sh/s390 teams? - Preparation: Someone on an undermanned arch team needs to describe their workflow on-list 2+ hours before the meeting. Goal: Suggest changes. This should happen on-list. No discussion expected. PMS: Are versions allowed to have more than 8 digits? - http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml https://bugs.gentoo.org/show_bug.cgi?id=188449 Preparation: Do the package maintainers with extremely long PVs need them? The involved packages: sys-process/fuser-bsd sys-apps/net-tools sys-apps/gradm net-im/ntame media-video/captury media-libs/libcaptury media-libs/capseo sys-block/btrace www-apache/mod_depends net-wireless/rt2500 sys-fs/unionfs Preparation: What's the impact of extending versionator.eclass? Goal: With data in hand, make a decision. How to handle appeals - Preparation: Post to the gentoo-council mailing list 2+ hours before the meeting with your opinion. Goal: Vote on an approach that was previously posted to the list. New topics == as-needed by default antarus requested that we vote on whether to add it to the default LDFLAGS. Preparation: Post your opinion to the -dev thread RFC: --as-needed to default LDFLAGS 2+ hours before the meeting. Goal: Vote. GLEP 54 --- Preparation: Post your opinion to the -dev thread A few questions to our nominees 2+ hours before the meeting. Goal: Vote. GLEP 55 --- Preparation: Post your opinion to the -dev thread GLEP 55 2+ hours before the meeting. Let it attempt to come to a consensus before we vote. Goal: Vote once the discussion's no longer clearly ongoing. We can hold this vote on the -council mailing list instead of waiting for the next meeting. GLEP 56 --- Preparation: Post your opinion to the -dev thread [GLEP56] USE flag descriptions in metadata 2+ hours before the meeting. Let it attempt to come to a consensus before we vote. Goal: Vote once the discussion's no longer clearly ongoing. We can hold this vote on the -council mailing list instead of waiting for the next meeting. Status of PMS - ferringb said: I'd like the council to please discuss the current status
Re: [gentoo-dev] Re: GLEP 55
Santiago M. Mola [EMAIL PROTECTED] wrote: On Thu, Jun 12, 2008 at 4:07 AM, Jim Ramsay [EMAIL PROTECTED] wrote: Why not just bump the filename suffix when it is required to support a new EAPI that breaks the sourcing rules of previous EAPIs? Or will backwards-incompatible changes be happening so frequently that the package suffix will have to change for every EAPI bump anyway, which would make this proposal equivalent to GLEP55? That works. Although, we'd have to keep track of two parameters when setting our EAPI. One being the EAPI itself and the suffix needed for that EAPI. So this doesn't seem to make the problem simpler. I agree that it doesn't make things simpler. Though it doesn't make things that much more complex. That said, I'm becoming more convinced that a lot of the changes that really need to be made will indeed break EAPI sourcing rules, so maybe the latter part of my original quote above will indeed be the case - This would be equivalent to GLEP55. I should add that I am not personally opposed to having the EAPI in the filename, but this may find slightly more acceptance from the folks who think that solution is incorrect. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
[gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]
On Wed, Jun 11, 2008 at 07:00:16PM +0100, David Leverton wrote:
On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
David Leverton [EMAIL PROTECTED] wrote:
Since at least one ebuild has already been modified specifically to
work around the bug, I'd say it's pretty real.
For those of us trying to play along at home, which one is this?
http://tinyurl.com/4w4t69
Few things I'll note about this stupid, stupid mess- looks of it,
paludis folk have known about this for a while. In other words, folk
bitching about 'improving' QA intentionally sat on a bug for the sake
of mocking, bug which according to them ebuild devs have supposedly
worked around (yet to see it, but it's viable).
Useful to the whole, I'm sure. Same folk in control of PMS for those
playing the home game, politics over QA seemingly.
So what was the bug? Aside from having to walk the full eapi-1 bugs,
(ebuild referenced wasn't of use), majority of which actually *is*
tested in pkgcore (unlike portage which makes one wonder why pkgcore
is targeted), the fault is a simple defaulting of an unset var being
missed in implementing an undocumented spec (honestly, where is eapi1
spec?).
Literally, the BS of the last day all comes down to inability to state
the following:
=== modified file 'pkgcore/bin/ebuild-env/ebuild-functions.sh'
--- pkgcore/bin/ebuild-env/ebuild-functions.sh 2007-11-12 01:17:24 +
+++ pkgcore/bin/ebuild-env/ebuild-functions.sh 2008-06-11 22:24:16 +
@@ -236,7 +236,7 @@ src_compile
{
if [ ${EAPI:-0} == 0 ] ; then
[ -x ./configure ] econf
-elif [ -x ${ECONF_SOURCE}/configure ]; then
+elif [ -x ${ECONF_SOURCE:-.}/configure ]; then
econf || die econf failed
fi
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
Bit of a dumb bug, but it occurs unfortunately. And yes, bash bits
aren't currently tested since they're going to be completely ripped
out and replaced (in the process shifting where/how it's accessed).
Why the exherbo/paludis/PMS folk decided to go this route to report,
I'm not quite sure aside from assuming they're just griefers.
Regardless, fixed, released as 0.4.7.4, and in the tree.
Cheers
~harring
pgpOv1DdBuCfq.pgp
Description: PGP signature
