Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Tue, 03 Jan 2006 09:28:24 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Here's one example of a global goal: Reduce the learning curve of | Gentoo and increase its usability. That goal is silly and oxymoronic. Reduced learning curve decreases usability. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Split ebuilds for GCC
On Wed, 04 Jan 2006 05:26:44 -0700 Duncan [EMAIL PROTECTED] wrote: | That begs the question... No it doesn't. http://www.wsu.edu/~brians/errors/begs.html | Curious users want to know! Perhaps said curious users should go and take a look, then. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thu, 5 Jan 2006 04:31:30 + Kurt Lieber [EMAIL PROTECTED] wrote: | We haven't done anything interesting or innovative over | the last...year? Codswallop. We've done lots of large, innovative changes. You've just not been paying enough attention to have seen them, and the people doing the changes haven't been going around screaming about it from the rooftops. If you'd like to see more interesting or innovative changes, start by looking into how we can make it easier for developers to advertise what they've been doing. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thu, 5 Jan 2006 12:09:09 + Tom Martin [EMAIL PROTECTED] wrote: | If you'd like to see more interesting or innovative changes, start | by looking into how we can make it easier for developers to | advertise what they've been doing. | | planet.g.o? No, that's censored to only display what certain people want it to say rather than the truth of what's going on. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thu, 5 Jan 2006 07:49:21 -0500 Dan Meltzer [EMAIL PROTECTED] wrote: | Apparently it does. How many huge threads have you seen lately that | accomplished nothing? How many threads have people started with great | ideas, only to give up in disgust because people cause a huge fuss | about small details, and nothing ever gets accomplished? Quite a few. Most of them get somewhere, eventually. They'd get there a bit faster if we booted you, Duncan, Nathan and Alec from the lists, but I guess the cost of doing that wouldn't be worth the gain. Sure, the odd thread ends up going nowhere, but that's usually when the original idea isn't implementable. Look at the news GLEP, for example. Half the replies are worthless drivel from morons. The remainder is extremely useful input. The GLEP in its original form wouldn't have worked -- heck, I knew that when I posted it for review. But it's getting there, and after another round or two we'll end up with something that will work first time when it's implemented. Better to spend a bit of time now having an extended technical discussion (which differs from a flamefest, but only when you look closely) than to go ahead and screw up the tree... -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thu, 05 Jan 2006 07:18:40 -0600 Andrew Gaffney [EMAIL PROTECTED] wrote: | What is your problem with the installer project? Over the past year | or so, there have been *2* people that complained about us treating | them badly. Hrm, have the arch teams really left you in peace for an entire year now? -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thu, 05 Jan 2006 17:20:09 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: | It's getting more and more difficult to get things done, more and | more people / groups / herds to wait on to decide obvious things. Hrm, it is? Seems to me that it's no worse that it used to be. It's just that the stalling points are in different areas. As for obvious... For any problem there's at least one solution that is both obvious and wrong... -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On 01 Jan 2006 05:30:01 Mike Frysinger [EMAIL PROTECTED] wrote: | If you have something you'd wish for us to chat about, maybe even | vote on, let us know ! Simply reply to this e-mail for the whole | Gentoo dev list to see. Could you discuss adopting one of the clauses I proposed in the RFC: disallowing multiple votes per person in council meetings thread? http://marc.theaimsgroup.com/?t=11346783302r=1w=2 -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: regular project updates
On Thu, 5 Jan 2006 17:28:13 +0100 Grobian [EMAIL PROTECTED] wrote: | I'm thinking of quite dull news, so absolutely not meant to be a | publication like GWN, but just thingis like some commits on the | portage sources that say to fix/implement X, a discussion on project | ML Y working on Z. Would our users really like to read a lengthy discussion on the intricacies of the changes made to versionator.eclass to improve performance, or the way in which the ten zillion packages needed by the new KDE/Gnome/Xorg release were keyworded for a particular arch, or the design decisions made for vim-spell.eclass to avoid requiring that our users have four gigs of RAM? I mean, it'd be pretty frickin' boring... -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Tue, 10 Jan 2006 15:12:27 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | Last I knew, its not a simple task for generating those nice looking | html pages that ciaranm made a while back for the developer docs. | When I asked him about (he can probably provide more detail), It took | a lot of processing time and wasn't that scalable. Now, I'm not sure | if anything has changed since then. If you're using docutils, then yes, it's reaallly slow. I've got a (very fast) parser that handles a decent subset of the RST spec written, but getting it converted to be usable in a general kind of way isn't too high up my list of priorities... The thing is... If you're trying to do RST - GuideXML, you'll run into all kinds of weirdness because of the GuideXML heading structure. You'll also run into a load more weirdness because about half of the GLEPs currently massively abuse blockquotes (in all but one case accidentally). See, this is a list in RST: * one * two And this is a list inside a blockquote: * one * two Very easy to screw up, especially since docutils goes to great lengths to create output even if the input is highly weird. My own parser moans on anything like that -- it disallows most nested structure markup -- which means it's useless on most GLEPs unless someone goes through and does some serious whitespace cleanups... -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, 13 Jan 2006 15:13:02 -0500 solar [EMAIL PROTECTED] wrote: | The autouse itself is not a bad feature or idea if it were used properly. | Problem is that it's not been used properly. No, it's bad. It's another thing that makes correct dependency resolution impossible. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] FEATURES=test depends
On Tue, 17 Jan 2006 13:53:02 -0500 Doug Goldstein [EMAIL PROTECTED] wrote: | Basically some packages have additional depends to be able to run the | tests. So if a user has FEATURES=test, then they need additional | depends. For example, gstreamer | http://bugs.gentoo.org/show_bug.cgi?id=115448 and expat (ghetto fix by | me in tree) have depends on dev-libs/check to be able to run | FEATURES=test. Is there anyway to properly do these depends or is | the ghetto fix in expat the best solution thus far? Or go the way of | other packages and have DEPEND=dev-libs/check. See the previous zillion times that this has been discussed and the FEATURES into USE_EXPAND bug (82513). -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Anything else needed before eselect-1.0?
This is your last chance to ask for minor feature enhancements / bug fixes before eselect 1.0. Unless something nasty crops up, there will probably be a 1.0 release within a few days. One note: we'll probably be splitting out most of the distributed with eselect modules into separate packages. The aim is to have only core, non-package-specific, non-experimental-demo stuff distributed with the main eselect. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, 19 Jan 2006 19:24:18 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Mike Frysinger wrote: | - we will set sane debug defaults in the base profile: | * DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g | | On gcc-4, even -O can make it really hard to track stuff. Might want | -O0 instead. 4.1 gets even crazier. -O1 -fno-inline-functions will give you better results with C++ code. Without -O1, g++ will skip some really basic optimisations that makes it even harder than usual to figure out what STL code is doing... -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Compilation in src_test
Say we have an autotooled package that provides a library. Say also that this package provides several well written test programs that are listed in Makefile.am under check_PROGRAMS. When emake is run, the library will be built, but the test programs will not be. When make check is run, the test programs will be built then run. Two problems... Firstly, this will result in non-trivial things being compiled in src_test. Is this an issue? Secondly, check_PROGRAMS when used in a subdirectory won't parallelise the compile even if we override the default src_test (which forces -j1). One way around this is to s/check_/noinst_/ in the Makefile.am. Is it worth it? Is anyone who is familiar with autotools internals aware of a cleverer solution? -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Duplicate licences
On Sat, 21 Jan 2006 00:41:06 -0700 Joshua Baergen [EMAIL PROTECTED] wrote: | The reasons that this system was chosen were correctness and | maintainability. Many of these essentially use the good old MIT | license with various companies' and/or individuals' copyrights at the | top, as you have stated. However, the MIT license does refer to the | copyrights within the license script itself, and many of the licenses | have been slightly altered to include a company's name directly. I'm | no lawyer, but to me this means that the license does indeed include | the copyright. So you propose we go through and change every package in the tree that uses BSD or MIT (or GPL with the copyright disclaimer)? | Now, that splinters the licenses a good amount already, and thus | maintenance becomes an issue. If one half of the licenses are | unique, and we only keep unique ones, packages start depending on | other licenses in a spaghetti-like fashion. We can't just go ahead | and change any given license since it will mess up other packages | dependent on that license. Like good programming practice, I would | argue that less is not necessarily better. Were that the case, we'd do as Debian do and distribute a licence with every single package. Every other package maintainer manages to get it right. That it's a bit more work to do things properly is no excuse. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Mon, 23 Jan 2006 23:33:32 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | What's wrong with the original idea of just making any unported | ebuild pull in all of modular X (minus drivers)? Yes, it means that | some people will pick up unnecessary deps until all packages are | ported, but it avoids anyone having to see flashy red errors. | | The problem with that is that it removes all motivation to ever port | the packages. They'll just stay that way forever, where forever means | until I threaten to remove that from the virtual, in which case | we'll be in the same scenario we are now. Why? Because people have | better things to do than fix stuff that isn't broken. Ok. So... As far as I can see: * There is a clean upgrade solution available that will result in non-ported packages merely pulling in a load of extra unnecessary packages (that non-modular users have anyway). * The clean solution visibly illustrates that a package is unported. Users who are running ~arch can clearly see this, and can file bugs and (if they care) attempt a --nodeps installation. The bugs can be picked up by the package maintainers or the volunteers on this list. * The clean solution is the solution originally proposed to this list, and the reason we are using new style virtuals. * There is an alternate upgrade solution that means that any users who have an unported package will get their screen filled with several pages of incomprehensible bright red crap. * There are currently enough unported packages that many ~arch users will probably have one or two installed (assumption: many users have several utterly random non-mainstream packages installed). * Despite your original assurances to this list, you intend to go ahead and take the alternate solution, which will lead to one of the most user visible and hardest to fix breakages we've ever had. * You are doing this because you believe that it is better to get every package ported over extremely quickly rather than having the odd package with extra unnecessary listed dependencies, and you do not consider the impact upon our users to be relevant. Is my understanding correct? -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Wed, 25 Jan 2006 01:17:23 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | And as there's no current way to fix the invokation of sed from | within xargs or find, I'm not going to ask to change _all_ the calls | of sed, but just the ones done through those two or other scripts and | things that won't honour aliases in bashrc. If there are any hardcoded calls to /usr/bin/sed, it is reasonable for you to ask for them to be fixed. For any others, use a wrapper script. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 23:00:14 -0700 Joshua Baergen [EMAIL PROTECTED] wrote: | To be clear here: nothing will be broken. Xorg 7.0 will just not | provide virtual/x11 (and in fact blocks it), so there will be issues | with blocks showing up due to the upgrade path. Avoiding the upgrade | (and blockage) is very easy if necessary (eg, you use 200 unported | packages or something). That is exactly the issue. Your average ~arch user is going to get pages and pages of nasty red incomprehensible blocks simply because you're making Xorg 7 block the virtual rather than provide it. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 22:28:09 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Yes, for all 3 people who have a clue what it means when virtual/x11 | gets pulled in. How many users do you seriously think will have a clue | and think Oh, virtual/x11 is getting pulled in here. I must have a | package that isn't ported to modular X somewhere in this list. Let me | track it down and file a bug.? When users suddenly see lots of extra X packages being pulled in that they don't need, it'll be rather obvious (and trivial to track down with --tree). Especially if it's documented somewhere that packages that suddenly pull in lots of extra X packages usually means porting needed. | * The clean solution is the solution originally proposed to this | list, and the reason we are using new style virtuals. | | No, this is wrong. The reason we are using new style virtuals is so we | could have a versioning in what provides virtual/x11. Namely, 6.8 or | older. Uh, given that you can do that with old style virtuals, methinks that isn't the case... | * There are currently enough unported packages that many ~arch users | will probably have one or two installed (assumption: many users have | several utterly random non-mainstream packages installed). | | Possible, but we can't prove this one way or the other. Certainly very | few modular X users have encountered apps that are still unported, as | evidenced by very few remaining blockers on #112675. Sure, but that's because there are relatively few users using hard masked packages. When you add it to ~arch the number will go up massively. | * You are doing this because you believe that it is better to get | every package ported over extremely quickly rather than having the | odd package with extra unnecessary listed dependencies, and you do | not consider the impact upon our users to be relevant. | | I consider ~arch users to have agreed to help test and fix new things. | This is included. I would not do the same thing to our stable tree, or | if we only had a stable tree. | | Yes, I do think it is better to have a quick solution and let some of | our ~arch users see a couple of blocks, for which they will file bugs. | Then these bugs will be fixed within a day, and those users will again | have working systems. ...or you could do things as originally planned, and have no non-working systems at all and the only consequences for end users will be a small number of extra packages (that they previously had installed anyway as part of hugeass X) being pulled in. | I don't see what the big deal is. By being ~arch users, they're | already asking to use ebuilds that have a chance of breaking their | systems permanently, let alone a single 'emerge sync'. They are asking to use ebuilds that may have undetected issues. They are not asking to use things that we know fine well are broken. ~arch is for will hopefully go stable after further testing, not stuff that has a very high chance of screwing you over. You're deliberately causing nasty problems for ~arch users when there's a very easy, clean workaround with far lower consequences and the same end result. This is unacceptable. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Wed, 25 Jan 2006 16:08:07 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | Uh, given that you can do that with old style virtuals, methinks | that isn't the case... | | Only by modifying every ebuild that has a virtual/x11 dependency. The | atom virtual/x11 cannot be limited to specific versions on its own | with old style virtuals. Oh? There's at least one old style virtual that specifies a full dep atom rather than a package name. I know this because it broke my first virtuals parser that was expecting a straight name... | The premise for not doing this is that packages will never be fixed, | right? Why not make the modular X provide virtual/x11 and just | institute a policy that no new packages can go into stable with a | virtual/x11 dependency? It could even be easily enforcable if | necessary. Much more sensible. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 23:16:38 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Where do they define lots? Many packages will legitimately pull in a | large quantity of libs or apps that are not installed by someone | emerging xorg-server, e.g. Heck, add in a non-ported-package fake package hack if you really think ~arch users will have a hard time telling. | I guarantee you that adding all of modular X to the virtual/x11 will | make this drag out for years, and THAT is unacceptable to me. Why must it drag out for years? There's no difference in the speed of porting between the solutions. The only difference is the impact upon end users. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Unmasking modular X
On Tue, 24 Jan 2006 23:34:49 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Tue, 24 Jan 2006 23:16:38 -0800 Donnie Berkholz | | I guarantee you that adding all of modular X to the virtual/x11 | | will make this drag out for years, and THAT is unacceptable to me. | | Why must it drag out for years? There's no difference in the speed | of porting between the solutions. The only difference is the impact | upon end users. | | And impact creates motivation. If it isn't literally broken, 95% of | devs just have better things to do than fix it. This does not give you the right to deliberately break things for our users. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] NFP lack of progress
On Fri, 20 Jan 2006 08:42:39 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Email's pretty simple- from where I'm sitting, there doesn't seem to | be any actual progress on trustees issues. *prod* -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Repoman and his automagic
On Fri, 27 Jan 2006 18:57:53 -0500 Alec Warner [EMAIL PROTECTED] wrote: | I personally am against both of these, mostly due to their | automational nature. Indeed. Repoman is significantly stupider than most developers. This is just asking for trouble. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On Sat, 28 Jan 2006 10:31:55 +0100 Grobian [EMAIL PROTECTED] wrote: | In fact, I'd like to have only sh, because I never use bash. How did you become a Gentoo developer? -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Make logrotate a global USE flag?
On Sat, 28 Jan 2006 18:58:52 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Marcelo Góes wrote: | Indeed, logrotate functionality should be optional. Ebuilds that | install logrotate stuff without asking should be updated to use the | logrotate USE flag. | | I'm making it a global USE flag if nobody complains. | | You want people to recompile the whole package to get another text | file installed? | | People who don't want it can set INSTALL_MASK. It should be installed | by default and not switchable with a USE flag. We already had this discussion. It's not that it's another file, it's that it's another file in /etc, which is backed up and requires administrator attention on every upgrade. Packages shouldn't stick stuff in /etc on a whim. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Make logrotate a global USE flag?
On Mon, 30 Jan 2006 07:15:57 +0100 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: | It would be interesting to know how that happened for in the past | for /etc/bash_completion.d, which made a similar move iirc Have you any idea how slow bash is if you use all the completion files for every app with completion support? -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Mon, 30 Jan 2006 06:17:36 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | Also, as repoman complain about linguas_blabla not being a valid | useflags, all the linguas_* useflags should be listed in use.desc No, part of the point of USE_EXPAND is that they shouldn't. This is a repoman bug. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Mon, 30 Jan 2006 20:46:28 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | On Monday 30 January 2006 16:43, Ciaran McCreesh wrote: | On Mon, 30 Jan 2006 06:17:36 +0100 Diego 'Flameeyes' Pettenò | [EMAIL PROTECTED] wrote: | | Also, as repoman complain about linguas_blabla not being a valid | | useflags, all the linguas_* useflags should be listed in use.desc | | No, part of the point of USE_EXPAND is that they shouldn't. This is | a repoman bug. | | I have yet to be enlightened on any merit of USE_EXPAND is so perhaps | you could explain as to why there should be | user-configured-yet-undocumented options for ebuilds? More precisely, | how should they be documented if not via use.desc? 1. Because for things like LINGUAS, there are arbitrarily many legal values, and documenting them all and keeping the list up to date would be extremely difficult. 2. Because USE_EXPAND is used for special USE things like arch and userland, and because we undocumented the special arch USE flags because they're not user settable. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Tue, 31 Jan 2006 20:31:55 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | 1. Because for things like LINGUAS, there are arbitrarily many legal | values, and documenting them all and keeping the list up to date | would be extremely difficult. | | More precisely, how should they be documented if not via use.desc? They shouldn't be. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 31 Jan 2006 12:11:49 + Benjamin Smee (strerror) [EMAIL PROTECTED] wrote: | While I understand various developers concerns about cluttering /etc | (especially embedded), I don't see why this should stop the policy of | writting ebuilds that work and have expected tools around them. | Precisely what that constitutes is the real question. See, you're not really taking into account the cost of sticking files in /etc. For packages where an etc entry is low cost, it's already done. For things like bash completion and log rotation, the cost of installing a file into /etc can be extremely high, so it shouldn't be forced upon system administrators unless they ask for it. The same goes for cron entries for packages where the cron part isn't a core operation. What would be nice is a ban on .example files in anywhere covered by CONFIG_PROTECT. We have /usr/share/doc/ for those. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 31 Jan 2006 14:03:38 + Benjamin Smee (strerror) [EMAIL PROTECTED] wrote: | On Tuesday 31 January 2006 12:31, Ciaran McCreesh wrote: | See, you're not really taking into account the cost of sticking | files in /etc. For packages where an etc entry is low cost, it's | already done. | | What is the cost you are referring to specifically? I think I know | but I'd like a specific definition. 1. Management. For example, handling etc-update. 2. Administration. Everything in /etc must be checked and covered by backup policies and the like. Unless you're a home user, in which case you probably just hope for the best... 3. Performance. Entries in /etc can have a serious performance impact. The easy example is bash completion, which can be reaaaly slow if you have a few hundred entries. Less obvious examples are cron entries for things like updatedb -- if you have a few dozen chroots and svn checkouts of large projects, updatedb can take a very long time and eat a lot of battery power. | Agreed, the question then though is how to manage it. Is USE the | right way? Given that there will always be a couple of exceptions, is | it not reasonable to expect that all packages that install cron | entries do it in a consistant manner? Not really. For some packages, cron files must always be installed for proper operation. For some packages, cron files are strictly optional extras for features that many users will not want. For many it's somewhere in between. For packages in the first group, a USE flag is silly. For packages in the second group, not using a USE flag is silly. For the in-between cases, that's one of those areas where the ebuild maintainer has to make an educated decision. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 31 Jan 2006 17:06:35 + Benjamin Smee (strerror) [EMAIL PROTECTED] wrote: | On Tuesday 31 January 2006 15:47, Ciaran McCreesh wrote: | | What is the cost you are referring to specifically? I think I | | know but I'd like a specific definition. | | 1. Management. For example, handling etc-update. | | That is surely a cost people have for upgrading an application and | have implicitly accepted by doing so. Not really. There's a basic cost of installing or upgrading an application, but there's also additional cost that comes from optional extras. | 3. Performance. Entries in /etc can have a serious performance | impact. The easy example is bash completion, which can be | reaaaly slow if you have a few hundred entries. | | I find this hard to swallow. You could say that about any directory | that is over a certain size, say typically /dev. Thats even on the | assumption that most people use bash completion constantly or that on | modern hardware it is a noticeable problem, which in my experience is | not the case. Noo! Not the cost from using a sucky filesystem. The cost from your application of choice having to parse all those files. Bash is a good example -- it's not particularly fast (read: very slow) at parsing scripts, and if you have a zillion bash completion scripts installed then something as simple as starting a terminal can take a very long time. It's precisely this that lead to bash-completion-config. | Then change the default configuration so that it only updates for the | directories that you want. The expectation that a package works after | an emerge is in 99% of cases perfectly reasonable, and if its not | perfect for one persons particular environment then the onus is on | them to fix it. We can't be everything to everyone, but we can have a | good shot at getting close in most cases. Sure, packages are expected to work after installation. Does providing a cron entry count as part of working? Not for some packages. Does installing a bash completion entry count as part of working? Not for most packages. No-one (sane, anyway) is opposed to decent default config files going into /etc automatically where such a thing is possible. The question is how to handle the high cost extras. | For packages in the first group, a USE flag is | silly. | | Why, there may be cases where what you think should require cron, | doesn't for that particular user and besides which again we are | talking about a tiny minority from what I can see. If that's the case, either your package isn't in the first category or the user is doing something especially weird. Users doing especially weird things are on their own. | For packages in the second group, not using a USE flag is silly. | | I take it you are agreeing we should have a USE flag for these | ebuilds? For packages where /etc entries are wanted by some, not wanted by some, yes. | For the in-between cases, that's one of those areas where the ebuild | maintainer has to make an educated decision. | | and here is the nature of the problem imho. Currently everyone is | making these educated decisions and it means there is no coherency at | all. No! The educated decisions include how everyone else is handling the issue. | Why not say something like Where possible, all ebuilds should | work after being emerged. Example configuration files should be | installed in /usr/share/doc, and additional administration scripts / | configuration should be done via the global use flag FOO where foo | is cron or logrotate as an example. I understand that it isn't | perfect for EVERYTHING, but then there is no one solution for | everything, and having something like that would certainly be a lot | clearer to developers and users alike as to how to go about doing | things instead of having to read ewarn / einfo as they fly by on how | to specifically do things for that specific ebuild. Hah, I tried that with devmanual. The problem is, the worst offenders for doing perverse things in ebuilds are the same ones who won't accept any documentation that isn't official and marked mandatory and who will block any documentation of existing practice from becoming policy because it isn't policy. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Unmasking modular X
On Tue, 31 Jan 2006 10:41:36 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Mark Loeser wrote: | We are talking about completely unrelated versions, not what we are | touching. For example, old imagemagick ebuilds sitting around, | where the newer ebuilds are fixed, but old ones are not. We have a | security bug open about this package right now, and having an error | about deps in some old version doesn't really help arch teams at | all. | | Oh, so we just screw up people using modular X on a stable system by | breaking the latest stable ebuild.. It shouldn't be a critical error. Criticals make it very hard for people to fix other legitimate issues. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
On Tue, 31 Jan 2006 12:15:00 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | I finally came up with an idea for this that satisfies my desire to | not recompile the package to get e.g. a logrotate file. Have the flag | control whether it's installed to /etc or to /usr/share/doc. | | Thoughts? I'd prefer either /etc or /etc and /usr/share/doc personally. But yeah, that's a nice solution. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Default Ebuild behaviour
On Wed, 1 Feb 2006 00:03:46 +0100 Henrik Brix Andersen [EMAIL PROTECTED] wrote: | On Tue, Jan 31, 2006 at 10:53:28PM +, Ciaran McCreesh wrote: | I'd prefer either /etc or /etc and /usr/share/doc personally. But | yeah, that's a nice solution. | | You mean either /usr/share/doc or /etc/ and /usr/share/doc? Uh, yeah. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Unmasking modular X
On Wed, 01 Feb 2006 00:25:25 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Mark Loeser wrote: | I don't really see why anyone that is marking an ebuild stable | needs to have a fatal error because an older version of that | package isn't ported yet. We are perfectly capable of mentioning | this on the bug so the maintainer can fix it later :) A flag to | ignore it will make me, and probably other archs, happy though. | | I see broken dependencies with modular X They're not broken. They're sub-optimal. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Thu, 2 Feb 2006 20:46:55 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | Yeah that would help. But in the mean time what should we do? What you should always do. Do the right thing, even if repoman disagrees. Remember that repoman is there to try to help catch certain kinds of common screwups, not to dictate what you must do. If repoman is wrong, go ahead and commit, but also make sure that there's a bug filed describing how repoman is broken. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Sun, 5 Feb 2006 21:43:58 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Sunday 05 February 2006 21:34, Mike Frysinger wrote: | that's retarded, please remove all such linguas_* crap from | use.desc files | | I can, but then Mr_Bones_ will come back to me again and we're stuck | in this loop. Mr_Bones_ is, in this particular instance, wrong. We do not go around changing ebuilds simply because repoman has a bug. Instead, we make sure that there's a bug filed about repoman being broken, and do the right thing in the tree. repoman is there to help catch certain kinds of common screwup, if you're lucky. It is not there to be relied upon, and it is not there to tell you what to do. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Depend syntax
Just a reminder that all of the following are either illegal or strongly deprecated, so please don't use them even if Portage currently lets you get away with it: DEPEND=blah You should always use the full foo-bar/blah spec inside ebuilds. DEPEND==foo-bar/blah If you specify an operator, you must also specify a version (and if you specify a version, you must also specify an operator, but Portage enforces that by way of exploding horribly). DEPEND=foo? foo-bar/blah You should always use ( ) after a use? dependency. DEPEND=foo? || ( ... ) Extension of the above: you should use ( ) after a use? even if it's immediately followed by a ||. There're quite a few oddities like this in the tree. I'll be either fixing them or filing bugs depending upon whether the package in question is maintained. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Self-circular dependencies
Another not-so-uncommon issue that crops up: packages DEPENDing upon
themselves. Sometimes this is legit -- one of the Ada compilers, for
example, DEPENDs upon || ( itself another-compiler ). Sometimes,
however, it's the result of eclass screwups.
Typical example: you're coding a foo.eclass, that is used by foo and
various foo-extras. In the eclass, you set:
DEPEND==fnord-oink/foo-2.0
Which, for foo-extras, is all well and good. However, for foo, which
also inherits the foo eclass, you get h0rked deps. Portage currently
mostly ignores circular dependencies -- however, relying upon this
behaviour probably isn't a good idea.
The following inside an eclass is totally legal:
if [[ ${PN} != foo ]] ; then
DEPEND==fnord-oink/foo-2.0
fi
Please give serious thought to doing this where applicable.
A similar issue: Portage lets you block yourself, and will ignore the
block. So if foo-2.0 has DEPEND=!fnord-oink/foo, you can still
install foo. (This is a separate thing from blocking specific versions
of yourself, which you may want to do on occasion if a package has a
weird upgrade cycle or is slotted.) Again, please try to avoid relying
upon this behaviour, since it's extremely confusing.
I'll prod on IRC / file bugs for any obvious cases where it's
definitely wrong. There's also a full list, complete with a whole load
of legit cases, at:
http://dev.gentoo.org/~ciaranm/tmp/find_self_circular_deps.txt
--
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] Self-circular dependencies
On Sun, 5 Feb 2006 20:22:05 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: | On Sunday 05 February 2006 17:11, Ciaran McCreesh wrote: | Another not-so-uncommon issue that crops up: packages DEPENDing upon | themselves. Sometimes this is legit -- one of the Ada compilers, for | example, DEPENDs upon || ( itself another-compiler ). Sometimes, | however, it's the result of eclass screwups. | | your script doesnt take into consideration SLOT's ... the | linux-gazette and gcc stuff in your log for example is a false | positive Yup. Easier to just leave them in and filter them manually, since in general it's impossible for a computer to decide whether some of the weird cases are correct or not. I'm not filing bugs without checking manually first, and I'd certainly hope that no-one else will either. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council Meeting Summary (20060209)
On Thu, 9 Feb 2006 15:25:43 -0500 Aron Griffis [EMAIL PROTECTED] wrote: | Outcome: I've committed the amendment to GLEP 39 (council) as discussed. It should show up on the web within an hour or three. If I or docutils screwed it up, someone please let me know. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] eselect 1.0 is out
Version 1.0 of eselect, the modular configuration framework, is now out. All changes since 1.0_rc2 have been bugfixes. We haven't split out some of the shipped with eselect but not core functionality modules in this release, since I didn't want to break anything horribly -- that will probably be done for 1.1. However, we're providing a stable API now, so the keep modules somewhere where the eselect people can find them and fix them for you request is lifted. And since so few people seem to know this, despite it being a design feature that goes back to the very first random prototype hack: you don't have to run eselect module-name args. Many modules install a module-name-config or an update-module-name or somesuch symlink, and this is automatically recognised and converted internally. [ No, I'm not the guy in charge of eselect. That's Aaron, but he's busy and I needed eselect-1.0 before I could get GLEP 42 finalised. You can look forward to eselect 1.0.1 when he returns and finds all the stuff that I forgot to fix. ] -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On Thu, 9 Feb 2006 22:48:32 +0100 Grobian [EMAIL PROTECTED] wrote:
| Please find attached GLEP 47: Creating 'safe' environment variables.
Author: Diego Pettenò, Fabian Groffen
{flameeyes,[EMAIL PROTECTED]
Could you use the standard format please?
Status: Active
Should be Draft.
Instead of proposing a 4-tuple [3]_ keyword, a 2-tuple
keyword is chosen for archs that require them.
Provision should be made for future ports that require more than two
keywords. There's no particular reason to artificially limit this to
two at this stage.
Examples of how this lot is to be used in DEPEND= etc would be good for
clarity.
You should clarify the env map behaviour when multiple matches all
occur (first match, last match or merge?).
You should probably clarify whether the map is part of Portage itself
or in the tree. If it has to be part of Portage, explain why.
There're various English issues too where things don't scan clearly to
a native reader, but it's probably not worth fixing them at this stage.
Let me know when you reach the point where using precise language is
important and I'll make a list.
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On Fri, 10 Feb 2006 01:11:00 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Friday 10 February 2006 00:50, Ciaran McCreesh wrote: | Provision should be made for future ports that require more than two | keywords. There's no particular reason to artificially limit this to | two at this stage. | | There's a reason: simplicity. More than two part keywords simply are | difficult to read, handle and are proving themselves pointless. | We just need to identify an operating system (or a variant of it) not | a whole complex of dependencies. Mmm. Do you consider the cost of slightly simplified wording in the GLEP now to be worth extra effort that may be required in the future by some especially whacked out port? I'd prefer to see at least a note in the GLEP stating that three part keywords are legal if they ever become necessary. | Examples of how this lot is to be used in DEPEND= etc would be good | for clarity. | | Hmm well they are already being used, anyway, the following comes | from rpm2targz: Yeah, *I* know how they work. I suspect that many people reading the GLEP, however, are going to go Huh? Why do we need this lot at all?. | You should clarify the env map behaviour when multiple matches all | occur (first match, last match or merge?). | | Never thought about that actually, good point. I think last match | would be good. Then your example code is wrong :) -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On Thu, 09 Feb 2006 19:26:11 -0500 Alec Warner [EMAIL PROTECTED] wrote: | Assuming the CHOST variable is 'safe' is not a good thing, users can | over-ride this variable. Can you specify some behavior when it's set | to something bogus ( invalid form ) or something thats not in the | mapping? Users that override CHOST to something outside of one of the safe forms (or at all, on many archs) won't be able to compile anything anyway. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Manifest2 decision delayed (was: Gentoo Council Meeting Summary (20060209))
On Fri, 10 Feb 2006 10:14:26 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: | On Fri, 2006-02-10 at 03:17 +, Ciaran McCreesh wrote: | On Thu, 09 Feb 2006 22:05:35 -0500 Ned Ludd [EMAIL PROTECTED] | wrote: | | The words AUXFILE EBUILD MISCFILE DISTFILE could be using shorter | | names such as AUX EBD MSC DST like the existing vdb CONTENTS | | files does for objects dirs and symlinks. | | Would be interesting to see a comparison made between the space that | would be saved by using less clear names here and, say, the space | taken up by blank lines and comments in ebuilds... | | Interesting, yes... but ebuilds are read by humans and it is necessary | to be comprehensible a lot more than the Manifest files are. Sure. But the comparison would show whether or not it's going to make a substantial difference. And if it does, there're other things that can be done in the Manifest file that'll save a whole load of space too (e.g. using $ to represent $PN, ! to represent files/, * to represent ChangeLog and so on, since these characters aren't allowed in any filename in the tree). -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On Fri, 10 Feb 2006 19:25:47 +0100 Grobian [EMAIL PROTECTED] wrote: | On 09-02-2006 23:50:08 +, Ciaran McCreesh wrote: | On Thu, 9 Feb 2006 22:48:32 +0100 Grobian [EMAIL PROTECTED] | wrote: | Instead of proposing a 4-tuple [3]_ keyword, a 2-tuple | keyword is chosen for archs that require them. | | Provision should be made for future ports that require more than two | keywords. There's no particular reason to artificially limit this to | two at this stage. | | Can you come up with an example? kfreebsd-gnu is, in effect, one example you're using already. You'd have x86 as the arch, FreeBSD as the kernel and GNU as the userland. *shrug* I agree that two is enough for sane people. However, I don't see any particular reason to enforce a hard limit of two. | Examples of how this lot is to be used in DEPEND= etc would be good | for clarity. | | Ok, I assume you just want to see something like: |DEPEND=ppc-macos? ( dev-libs/libpcre ) | or |DEPEND=x86? ( dev-libs/libpcre ) | | If not, then I don't understand where you're aiming at. No, the expanded fancy stuff. userland_ etc. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On Fri, 10 Feb 2006 21:44:11 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Friday 10 February 2006 21:22, Ciaran McCreesh wrote: | kfreebsd-gnu is, in effect, one example you're using already. You'd | have x86 as the arch, FreeBSD as the kernel and GNU as the userland. | | x86-kfbsd See, you're saying two should be enough and then special casing when two isn't enough. Why not just go for two is usually enough, but use three where necessary? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
On Sat, 11 Feb 2006 22:28:43 +0100 Grobian [EMAIL PROTECTED] wrote: | Ok. If we're on the same wave length here, then I think the real | question is here whether we do allow hyphens to be in the os part or | not. If yes, the part till the first hyphen is the arch, and | everything from the hyphen (exclusive) till the end of string is the | os part. If no, an 'escape' method must be defined for the os part. | In both cases it is necessary to state that the arch cannot contain | hyphens in it, and if such restriction is defined, it might be handy | to immediately add spaces and the like to the list. Standard practice is to define what's allowed, not what's forbidden, and the usual range is a subset of a-zA-Z0-9_+:- . -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] check-reqs conditionals
For those of you who don't know, check-reqs is an eclass that is
occasionally used by a few packages that have ludicrously high build
requirements. Typical examples have included anything using Haskell (the
programming language with built-in memory leaks!) and certain C++
template metaprogamming voodoo.
Currently it just exports a single function that will warn (or die,
based upon user preference) if the build requirements aren't met. There
has been a request for a clean way of handling packages that can be
built in two different ways that give the same end result (typical
example is use of a really slow but low memory requiring algorithm vs a
fast but memory intensive algorithm when building data tables).
How does something like the attached look? (Yes, it's using old-school
[ rather than [[, since the rest of the eclass is written that way. I
might switch the whole thing over at some point.)
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
Index: check-reqs.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v
retrieving revision 1.4
diff -u -r1.4 check-reqs.eclass
--- check-reqs.eclass 6 Jul 2005 20:23:20 - 1.4
+++ check-reqs.eclass 11 Feb 2006 22:35:14 -
@@ -39,6 +39,10 @@
# check_reqs
# }
#
+# Alternatively, the check_reqs_conditional function can be used to carry out
+# alternate actions (e.g. using a much slower but far less memory intensive
+# build option that gives the same end result).
+#
# You should *not* override the user's CHECKREQS_ACTION setting, nor should you
# attempt to provide a value if it is unset. Note that the environment variables
# are used rather than parameters for a few reasons:
@@ -84,6 +88,23 @@
fi
}
+check_reqs_conditional() {
+ [ -n $1 ] die Usage: check_reqs
+
+ export CHECKREQS_NEED_SLEEP= CHECKREQS_NEED_DIE=
+ if [ $CHECKREQS_ACTION != ignore ] ; then
+ [ -n $CHECKREQS_MEMORY ] check_build_memory
+ [ -n $CHECKREQS_DISK_BUILD ] check_build_disk \
+ ${PORTAGE_TMPDIR} \${PORTAGE_TMPDIR} ${CHECKREQS_DISK_BUILD}
+ [ -n $CHECKREQS_DISK_USR ] check_build_disk \
+ ${ROOT}/usr \${ROOT}/usr ${CHECKREQS_DISK_USR}
+ [ -n $CHECKREQS_DISK_VAR ] check_build_disk \
+ ${ROOT}/var \${ROOT}/var ${CHECKREQS_DISK_VAR}
+ fi
+
+ [ -z ${CHECKREQS_NEED_SLEEP} ] [ -z ${CHECKREQS_NEED_DIE} ]
+}
+
# internal use only!
check_build_memory() {
[ -n $1 ] die Usage: check_build_memory
signature.asc
Description: PGP signature
Re: [gentoo-dev] Request for Comment
On Sun, 12 Feb 2006 00:11:07 +0100 Benno Schulenberg [EMAIL PROTECTED] wrote: | Klaus-J. Wolf wrote: | http://www.seismic.de/gentoo/gentoo_mask_proposal.html | |* Manually keyword unmasking an ebuild, automatically means | unmasking the last one in the line of masked versions. | | No. Use the = to unmask a specific version only. For example: | | =sys-apps/findutils-4.2.25 ~x86 Usually better to use ~, so that you pick up any revbumps. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] eselect 1.0 is out
On Sun, 12 Feb 2006 02:27:33 +0200 Eldad Zack [EMAIL PROTECTED] wrote: | Mmm. What's your readlink? | | sys-apps/coreutils 5.2.1-r7 Looks like it depends upon how ln -s was invoked as to what readlink gives. Guess we'll have to work around that in a couple of places... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Making PROFILE_ARCH more useful?
PROFILE_ARCH is currently used for various sub-architectures (e.g. sparc32 vs sparc64, 32 bit ppc vs ppc64, xbox vs normal x86) that don't have their own keyword but that do occasionally need special behaviour. It can be used in conditionals, but because no-one ever quite got around to it, it *can't* legally be used to alter metadata. Is there any particular reason PROFILE_ARCH shouldn't be added to USE_EXPAND? One example of something that could be fixed this way is sys-apps/s390-oco (bug #99255). There're various others too, most of which are in the different upstream-provided binaries for different subarchs category but there's the odd dep here and there too (e.g. on some multi ABI archs, certain kernel-related packages should dep upon a special compiler). The original idea was that PROFILE_ARCH would get expanded in a special way, like ARCH does, but it never got implemented. Doing things that way could still be an option, but expand seems to be the cleaner solution now. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
On Sun, 12 Feb 2006 22:19:29 -0500 Mark Loeser [EMAIL PROTECTED] wrote: | I don't see this as a groundbreaking change that requires a GLEP or | anything, especially since I eliminated most of the duplicates today, | after talking with the respective maintainers. There are probably | only 3 or 4 left. The original someone should GLEP this was on adding extended USE flag descriptions to metadata.xml. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Mon, 13 Feb 2006 00:57:33 + (UTC) Ferris McCormick [EMAIL PROTECTED] wrote: | Well, the user did the work, too, and doesn't know that you did it | (if I understand your case correctly). So the user deserves as much | credit as you do. What? No, that's silly. The one who does the work gets the credit. If you take all or a significant part of a user contribution, credit the user. If you don't use the user contribution because their proposed fix is lousy (a rather too common occurrence...), they just get credit for reporting the issue. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Sun, 12 Feb 2006 15:53:37 -0700 Duncan [EMAIL PROTECTED] wrote: | Consider this: INVALID is strong enough, under the wrong | circumstances, that it /could/ set an emotionally unstable user off, | causing them to commit suicide or something. Some people go around setting fire to embassies when they don't understand a joke. Doesn't mean we should care about or cater to such people. INVALID doesn't necessarily mean it was wrong for the user to file the bug. Heck, I've closed the occasional bug as INVALID (and sometimes have even had the reporter do it) after massive debugging sessions and discussions that go on for dozens of pages. But... If INVALID is renamed, could we get a new GOAWAY resolution for people who really deserve it? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Sun, 12 Feb 2006 23:32:39 + Daniel Drake [EMAIL PROTECTED] wrote: | It may feel a little harsh to give someone a canned response just by | pasting a URL in the comment field, but curious readers will find his | faq.txt which explains nicely that we aren't evil/lazy, we just have | a lot of work to do. Thanks Ciaran! And some users throw a hissy fit when given a detailed link to a canned response and demand that in future they get personally typed out explanations rather than a link to a detailed pre-written resource that goes into far more depth than anyone could possibly manage in a personalised response. Hence why I no longer spend much time helping in maintainer-wanted bugs unless a submitter specifically asks me to take a look at something for them -- all it takes is for one user to escalate their hissy fit to a devrel bug... Oh, and don't think that this behaviour is limited to end users. Sadly the same thing has been observed in certain Gentoo developers. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] where to install source files for c++ templates
On Mon, 13 Feb 2006 08:38:39 -0600 William Hubbs [EMAIL PROTECTED] wrote: | I can get them to build outside an ebuild fine, but I have found that | festival #includes actual source files from speech-tools to | instantiate c++ templates. | | If I keep speech-tools as a separate package, where should these | source files be installed in the file | system? /usr/share/speech-tools? No. /usr/include/speech-tools. Treat them as header files. Have a look at libebt for an example. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Mon, 13 Feb 2006 19:39:06 +0100 Simon Stelling [EMAIL PROTECTED] wrote: | Are you being serious about this? Sadly, even if he is, there're enough people around here that're taking that kind of thought seriously (see, for example, my sarcastic post on the 0day -core thread that so many people took as genuine)... | NOTABUG sounds good, but as Ciaran said, we need another replacement | for those bugs who really deserve it. If a user sticks | -fvisibility=hidden into his CFLAGS (instead of CXXFLAGS), | PLEASEGOAWAYKTHXBYE would be much more appropriate. They also deserve it if they stick it in their CXXFLAGS... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Mon, 13 Feb 2006 20:07:51 +0100 Grobian [EMAIL PROTECTED] wrote: | If these frustrations get so apparent that they require a solution | flag in Bugzilla for a developer, then it might be a better solution | to just leave the bugzilla work to someone else and try to work a bit | more away from the users for a while. Most of us don't have the luxury of being able to ignore real users... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
On Thu, 16 Feb 2006 21:51:40 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | Unless someone picks this up, it should be package.masked and | removed from portage. There are tons of better and working | alternatives. Uh, it's not a last rites unless someone actually does the masking pending removal. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
On Thu, 16 Feb 2006 22:32:13 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | BTW, x11-misc/bbapm is about one month | overdue (http://bugs.gentoo.org/show_bug.cgi?id=20201) It's not overdue. It hasn't had a proper last rites email sent out yet and probably won't get one either, given the flamefest that occurred last time someone tried to tidy up commonbox... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
On Thu, 16 Feb 2006 22:55:33 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | 16.2.2006, 22:47:49, Ciaran McCreesh wrote: | On Thu, 16 Feb 2006 22:32:13 +0100 Jakub Moc [EMAIL PROTECTED] | wrote: | | BTW, x11-misc/bbapm is about one month | | overdue (http://bugs.gentoo.org/show_bug.cgi?id=20201) | | It's not overdue. It hasn't had a proper last rites email sent out | yet and probably won't get one either, given the flamefest that | occurred last time someone tried to tidy up commonbox... | | Uhm... you need to refresh your memory, it seems: It's not a proper last rites email unless it's sent by someone who's actually going to follow through with it. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
On Thu, 16 Feb 2006 23:45:45 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | OMG, stop this crap and don't waste our time. You specifically asked | me to do it - http://bugs.gentoo.org/show_bug.cgi?id=20201#c11 No, I asked you to do it properly, not to send out one last rites email for something you're not going to remove. | Also, there wasn't exactly any flamefest so I don't know what you are | referring to above. You sent out a mail and noone gave a damn about | that stuff, should have been removed from from the tree 1 1/2 year | ago. Try looking harder next time. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
On Fri, 17 Feb 2006 00:14:42 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | 16.2.2006, 23:58:41, Ciaran McCreesh wrote: | On Thu, 16 Feb 2006 23:45:45 +0100 Jakub Moc [EMAIL PROTECTED] | wrote: | | OMG, stop this crap and don't waste our time. You specifically | | asked me to do it - | | http://bugs.gentoo.org/show_bug.cgi?id=20201#c11 | | No, I asked you to do it properly, not to send out one last rites | email for something you're not going to remove. | | What are you talking about? commonbox is listed as maintainer of that | stuff, it's been broken for years, you neither fixed it or bothered | to remove it from portage, nor did you at least re-assign that to | maintainer-needed and remove yourself from metadata.xml. You should probably go and read herds.xml sometime. | You asked me to send last rites, I did, noone cares about that stuff | - so will you finally punt the broken thing, instead of this | pointless trolling?? Or should I CC QA on that bug, so that someone | else will do it if you don't want to? bbapm is only a small part of the problem. If you're going to do something, do it properly. Stop wasting other people's time by doing it piecemeal and getting it wrong. | | Also, there wasn't exactly any flamefest so I don't know what you | | are referring to above. You sent out a mail and noone gave a damn | | about that stuff, should have been removed from from the tree 1 | | 1/2 year ago. | | Try looking harder next time. | | That's exactly the link you provided in | http://bugs.gentoo.org/show_bug.cgi?id=20201#c7 so why on earth | should I try to look harder? Well, I *was* expecting you to use a bit of common sense when handling the issue. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
On Fri, 17 Feb 2006 00:34:32 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | You should probably go and read herds.xml sometime. | | Or maybe you should, rather... I said to go and read herds.xml. I'm not going to bother carrying on with this if you won't even do that properly. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Beware DESCRIPTION clobbering
Typical example: DESCRIPTION=I am a fish inherit eutils End result: DESCRIPTION=Based on the eutils eclass Some eclasses set DESCRIPTION. This is one of the many reasons that inherit should go as early up the ebuild as possible. List, which may be utterly wrong, of packages that either do this or have DESCRIPTION=$PN, as of when I last ran cvs upd: app-doc/ebook-libgnomeui-1.0: description: major: DESCRIPTION is about as useful as a chocolate teapot -- dev-libs/libole2-0.2.3-r1: description: major: DESCRIPTION equal to $PN? You can do better than that. -- dev-perl/XML-AutoWriter-0.38: description: major: DESCRIPTION equal to $PN? You can do better than that. -- dev-python/docutils-0.3_pre20030530-r3: description: major: DESCRIPTION is about as useful as a chocolate teapot -- dev-python/gnome-python-1.4.2: description: major: DESCRIPTION equal to $PN? You can do better than that. dev-python/gnome-python-1.4.4: description: major: DESCRIPTION equal to $PN? You can do better than that. -- dev-python/m2crypto-0.07_alpha3: description: major: DESCRIPTION is about as useful as a chocolate teapot -- gnome-base/gconf-1.0.8-r3: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-base/gconf-1.0.8-r5: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-base/gnome-applets-1.4.0.5: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-base/libghttp-1.0.9-r2: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-base/libgtop-1.0.13-r2: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-base/librsvg-1.0.3: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-base/nautilus-1.0.6-r9: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-extra/gnome-audio-1.4.0-r2: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-extra/gnome-media-1.2.3-r2: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-extra/gnome-pim-1.4.8: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-extra/gnome-pim-1.4.9: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-extra/gnome-utils-1.4.1.2: description: major: DESCRIPTION equal to $PN? You can do better than that. -- gnome-extra/gtop-1.0.13-r2: description: major: DESCRIPTION equal to $PN? You can do better than that. -- media-radio/xastir-1.2.0: description: major: DESCRIPTION equal to $PN? You can do better than that. media-radio/xastir-1.4.0: description: major: DESCRIPTION equal to $PN? You can do better than that. media-radio/xastir-1.6.0: description: major: DESCRIPTION equal to $PN? You can do better than that. -- sys-cluster/gomd-cvs-0.2_beta1: description: major: DESCRIPTION is about as useful as a chocolate teapot -- sys-cluster/iddev-1.00.00: description: major: DESCRIPTION equal to $PN? You can do better than that. sys-cluster/iddev-1.01.00: description: major: DESCRIPTION equal to $PN? You can do better than that. -- sys-fs/lvm2-2.01.14-r1: description: major: DESCRIPTION is about as useful as a chocolate teapot -- sys-libs/pam-0.78-r2: description: major: DESCRIPTION is about as useful as a chocolate teapot sys-libs/pam-0.78-r3: description: major: DESCRIPTION is about as useful as a chocolate teapot sys-libs/pam-0.78-r4: description: major: DESCRIPTION is about as useful as a chocolate teapot -- x11-libs/libPropList-0.10.1-r2: description: major: DESCRIPTION equal to $PN? You can do better than that. x11-libs/libPropList-0.10.1-r3: description: major: DESCRIPTION equal to $PN? You can do better than that. -- xfce-base/libxfcegui4-4.2.2-r1: description: major: DESCRIPTION is about as useful as a chocolate teapot -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Berlios-hosted SRC_URI components
Berlios have introduced a new Sourceforge-like download.php thing that requires that any download attempt include a magic key in the URL. Thus, Berlios can no longer be used inside SRC_URI. It gets worse. Even if you specify the magic key, Berlios seems to shove an extra random garbage byte onto the end of any tarball. This doesn't affect the output, since tar discards it, but it does screw up digests and gives weird errors when unpacking. It gets worse still. It looks like many our mirrors have broken copies of certain Berlios-hosted tarballs. So... AFAICS, the only way to proceed is, for each package hosted on Berlios, contact upstream and get them to give you a tarball via a different location, then manually mirror it, and use mirror://gentoo/ in SRC_URI. This really really sucks. Does anyone happen to know any of the Berlios staff? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Berlios-hosted SRC_URI components
On Sun, 19 Feb 2006 11:21:16 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: | On Sunday 19 February 2006 10:20, Ciaran McCreesh wrote: | It gets worse still. It looks like many our mirrors have broken | copies of certain Berlios-hosted tarballs. | | Shouldn't that be a general problem with our mirrors - unless Berlios | got hacked and modified tarballs injected, of course?! As I understand it, our mirror scripts rely upon wget being able to fetch the correct tarball from the original location. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Berlios-hosted SRC_URI components
On Mon, 20 Feb 2006 17:36:35 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: | Got a positive answer. Any remaining issues? Positive as in yes, we'll fix it, or positive as in yes, we're mangling the tarballs and we hate you? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Putting all log related packages into it's own category (sys-logging)
On Tue, 21 Feb 2006 11:20:39 +0100 Bjarke Istrup Pedersen [EMAIL PROTECTED] wrote: | Any suggestions on how this could be implemented? (Maybe having a | SQLite database with all the meta info, to save some time syncing and | space. Could with a bit of luck have all the metadata for portage, | like digests etc. , but thats another idea though). Using a database does not save space or make things faster. Nor will it make syncing any faster. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] RESTRICT and no*
What's the deal with no* values in RESTRICT? Is it RESTRICT=strip or RESTRICT=nostrip? fetch or nofetch? Which values work with all Portage versions, which work with only recent ones and which work with none? The documentation and the code are both inconsistent on this... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] SRC_URI component naming collision
Two ways this one can occur. Way the first: foo-1.0 has a file in SRC_URI called foo.pdf. Then foo-1.1 comes along, and has a different foo.pdf. Way the second: foo-1.0 has a file called examples-1.0.tar.bz2. bar-1.0 also has a file called examples-1.0.tar.bz2. To avoid this, ensure that your packages use versioned SRC_URI component names, and that the name part is something that's reasonably likely to be unique (e.g. includes the package name). Side note: if the packages in question are fetch restricted, you're screwed, and will not be able to add them to the tree. Current offenders shall be receiving bugs shortly, since That Which Shall Not Be Named now checks for this. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] dev-lang/nqc could use a maintainer...
Does someone want to pick up dev-lang/nqc? It's a C-like compiler for Lego Mindstorms, and it needs some version bump loving (bug #89257) and some nasty global scope code replacing. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] dev-util/perforce* needs a maintainer
Bug #123923: dev-util/perforce* needs someone to step up as a maintainer and fix the digest issues. Otherwise QA will get very upset. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] SRC_URI component naming collision
On Sun, 26 Feb 2006 19:45:41 + Stuart Herbert [EMAIL PROTECTED] wrote: | On Fri, 2006-02-24 at 14:19 +, Ciaran McCreesh wrote: | Two ways this one can occur. | | [snip] | | Third way ... upstream is a provider of commercial software, and | releases different editions of the same software with identical | filenames. Then you must talk to upstream and get them to change their ways. | I have the QA team on bug #123926 asserting that they have the right | to tell me to remove packages from the tree, because of basename | $SRC_URI filename collisions. We don't *want* to remove the package from the tree. We want to get the breakage fixed. | To the best of my knowledge, there's no policy document in existence | empowering the QA team to order package maintainers to remove packages | from Portage. I've asked the team to provide a copy if one exists, | but I haven't seen one yet. The team have (twice now) instead stated | that the email at the top of this thread is their authority. There's no policy document in existence that explicitly says that you (by name) can add stuff to the tree either. Most of our policy is undocumented, because it's impossible to cover every situation. The number one rule, however, is to be sensible and not commit things that cause breakages. Again, we don't *want* to remove it. On the other hand, if you refuse to work with us to get the problem fixed, we're going to have to do something about it ourselves. | Also, I cannot find this SRC_URI rule (as being applied by the QA | team) in any official Gentoo policy document. As I recall, pretty much nothing about digests at all is in any official policy document. Nor is nearly anything else on any development topic. However, that it is not explicitly forbidden does not mean that it should be done. Where in policy does it say that you shouldn't commit pictures of teletubbies in SVG format in the tree? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] SRC_URI component naming collision
On Sun, 26 Feb 2006 20:46:37 + Stuart Herbert [EMAIL PROTECTED] wrote: | On Sun, 2006-02-26 at 20:00 +, Ciaran McCreesh wrote: | Then you must talk to upstream and get them to change their ways. | | Already covered in the (growing) discussion in bug #123926. UPSTREAM | have previously been contacted over the issue, and have not changed | their release policy. Ok, so given that this is a closed source application, if upstream won't cooperate on something as simple as this, why do you expect them to cooperate with you on bugs or security issues? | I'm a little rusty at this - it's six years since I ran the DDS4 test | team for HP - but isn't one of the internationally recognised | requirements of every recognised QA standard that exists that a QA | policy should be documented? Utterly impractical. If you want to hire a dozen people to do this, go right ahead. But then, if you're hiring a dozen people, there are far more useful things they could be doing. | On a practical note, I don't understand how you expect developers to | follow an undocumented QA process. Sorry, I just don't get that one. We expect you to be sensible. When this fails, we point out issues and work with the developer to get things fixed. Over the past couple of weeks, QA has gotten somewhere around a couple of hundred tree issues fixed. In every situation bar three, the response has been thanks for pointing this out. In another two, the response was to fix the bug silently. No-one is expecting perfection. QA is here first and foremost to find issues, get them fixed and try to prevent the same breakage from being repeated. | Everything else is up for discussion. I think it's unreasonable to | say that I'm refusing to work with you. You're repeatedly closing off the bug rather than suggesting alternative ways of fixing the issue. There's been one possibility mentioned in this thread already, but it can't go anywhere unless someone with an affected package (which is you) is prepared to go to the Portage team with a justification. | Bearing in mind the discussion that's happened in the bug, on IRC with | Halcy0n, and in this mailing list, please understand this: I don't | believe that the QA team has provided evidence that it has the | authority to do anything to these packages over this SRC_URI issue. | If the team chooses to take unilateral action, I'll be left with no | choice but to file a formal complaint against the team as a | consequence. See Daniel's post in the thread. The council has already agreed that QA has authority. | I'm happy (and have suggested earlier) that this issue needs to go to | the council to be resolved. Being done. The council will be asked to approve a more specific description of QA's authority in the next meeting, since our existing mandate is listen to the QA team because they're working of valid policy. if you dont, devrel will take action (sic). | The issue at hand is that the QA team is, in this case, repeatedly | asking for something it doesn't have the authority to insist on. I | also think you're being unreasonable in this specific case. We're asking you to work with us in fixing a tree breakage. That's our goal here. We can't do this if you just go around closing off bugs and refusing to cooperate. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] SRC_URI component naming collision
On Sun, 26 Feb 2006 21:30:22 + Stuart Herbert [EMAIL PROTECTED] wrote: | On Sun, 2006-02-26 at 21:04 +, Ciaran McCreesh wrote: | Ok, so given that this is a closed source application, if upstream | won't cooperate on something as simple as this, why do you expect | them to cooperate with you on bugs or security issues? | | That's not the issue here. The issue here is whether the QA team is | entitled to be requesting the removal of packages in this specific | instance. The issue is whether you have the right to leave broken packages in the tree. I don't see any policy document granting you that right. | There are never any guarantees that any UPSTREAM will co-operate with | us on bugs or security issues. If we can't live with the issues, and | we can't fix them, the packages get dropped. I've no problem with | that. Sure. And if upstream won't even cooperate to the extent of renaming a file, how do you expect them to react when we require something less trvial? | | Everything else is up for discussion. I think it's unreasonable | | to say that I'm refusing to work with you. | | You're repeatedly closing off the bug rather than suggesting | alternative ways of fixing the issue. | | I think, in this specific case, there are better things to spend the | time on. I don't have a queue of users telling me that the way we | handle this today is a problem. There's no evidence that, in this | specific case, there is a problem out in the real world. It's so bad a problem that you even had to document it in the user guide and tell people to use some nasty hacked workaround. | Hang on a moment. It's not clear to me why I must go to the Portage | team for a change, when it's the QA team demanding change? As the QA | team wants the change, why don't you go to the Portage team and ask | them to implement DEST_PREFIX? We don't have a legitimate demonstration package, and we're not going to go and ask the Portage team to make code changes to support hypothetical speculation. You're the only one with a test case here. | | The issue at hand is that the QA team is, in this case, repeatedly | | asking for something it doesn't have the authority to insist on. | | I also think you're being unreasonable in this specific case. | | We're asking you to work with us in fixing a tree breakage. That's | our goal here. We can't do this if you just go around closing off | bugs and refusing to cooperate. | | Please stop spreading FUD, and libelling my name here. You've closed that bug five times now without fixing it. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] SRC_URI component naming collision
On Sun, 26 Feb 2006 22:17:33 + Stuart Herbert [EMAIL PROTECTED] wrote: | On Sun, 2006-02-26 at 17:02 -0500, Daniel Ostrow wrote: | That would work for fetch restricted packages, not nomirrored ones. | | /me nods. That's what we'll have to do. Unfortunately, it leaves | users with a worse experience than before, but until I can find a way | to reach the QA team and help them see my pov as the package | maintainer, what else can I do? :( It leaves them without a weird Portage error message, and it removes the assumption that the user will study a particular document in great detail. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] SRC_URI component naming collision
On Sun, 26 Feb 2006 22:13:32 + Stuart Herbert [EMAIL PROTECTED] wrote: | On Sun, 2006-02-26 at 21:40 +, Ciaran McCreesh wrote: | The issue is whether you have the right to leave broken packages in | the tree. I don't see any policy document granting you that right. | | From a discussion in #-portage, I understand that ferringb has already | told the QA team that file clashes in distfiles is legitimate, and has | no interest in implementing DEST_PREFIX support to tackle the | problem. Which is probably a good thing, since there's exactly one affected set of packages... | | Please stop spreading FUD, and libelling my name here. | | You've closed that bug five times now without fixing it. | | Yes I have. | | I carefully considered the QA team's concerns, and the proposed | solutions, and felt that - in this specific case - the bug doesn't | have enough merit. And then the bug degenerated into the QA team | being repeatedly asked - and unable to provide - any evidence that | they're entitled to push for the package to be removed. There are plenty of options you could have taken rather than repeatedly closing the bug off. From the looks of the rest of this thread, you've decided to go with one of these options. A comment on the bug saying I don't like the proposed fix. Here's how I'd solve it would be fine. Repeatedly closing the bug off and trying to pretend that there isn't a problem when there is is not. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Sun, 26 Feb 2006 17:22:17 -0500 Mark Loeser [EMAIL PROTECTED] wrote: | Yes, Gentoo is supposed to be fun, but we also have a responsibility | to our users to ensure we are providing them with the best possible | distro we can. What, you mean the tree isn't someone's personal playground? | * The QA team may also offer to fix obvious typos and similar minor | issues, and silence from the package maintainers can be taken as | agreement in such situations. Should probably clarify that one. It's in there because there are some situations where we find obvious typos (e.g. 'souce' instead of 'source' in DEPEND) and file a bug to alert the maintainer. If the maintainer fixes it within a few days, there's no problem, but if not there's no point in letting the bug sit there -- someone from QA should be able to fix it themselves. Equally, we don't want to just fix stuff without telling people that they made a mistake, because then they're more likely to do it again. | * The QA team will maintain a list of current QA Standards. The | list is not meant by any means to be a comprehensive document, but | rather a dynamic document that will be updated as new problems are | discovered. Hrm, do we want to include the thing about the QA standards providing rationale and explanations rather than hard rules here? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Sun, 26 Feb 2006 23:11:21 + [EMAIL PROTECTED] wrote: | On Sun, Feb 26, 2006 at 05:22:17PM -0500, Mark Loeser | [EMAIL PROTECTED] wrote: | * The QA team's purpose is to provide cross-herd assistance in | keeping the tree in a good state. This is done primarily by finding | and pointing out issues to maintainers and, where necessary, taking | direct action. | | Please clarify neccessary. I don't want to see repeat occurances of | non-issues bogging down real work. Also, please define around this a | clear and documented policy so when its enforced, its well defended. The problem is... It's impossible to document every single way in which someone can screw up. For example, I wouldn't've thought to document you should not run mkdir in global scope, because I didn't think anyone would be daft enough to do it. Policy *has* to rely upon the basic assumption that developers won't do something crazy. | * The QA team may also offer to fix obvious typos and similar minor |issues, and silence from the package maintainers can be taken as | agreement in such situations. | | I have no objections, on the understanding that there is a definitive | understanding of whats being changed and legitimate things aren't | accidentally replaced. Example of where this clause would be used, had said bug not been fixed quickly anyway: bug #122902. | * In the case of disagreement on policy among QA members, the | majority of established QA members must agree with the action. | | Perhaps pushing it to an open forum on -dev/-core for consensus works | better here? The problem with that is, it usually ends up with too many pointless comments from people saying how things could be fixed in the distant future, or whining that it isn't explicitly forbidden by policy on situations where the screwup was too weird to be documented previously. | * Just because a particular QA violation has yet to cause an issue | does not change the fact that it is still a QA violation. | | Is this a statement or a policy? I assume that if this is policy the | non-visible issue would go about appropriate scrutany, and in turn a | long-term solution made in the situation where it is not easily | resolvable/avoidable. This is to cover for situations where people claim that their screwups are ok because no-one has yet reported it as broken. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | The maintainer should be the absolute authority over his/her packages, | and only the council should be able to overrule maintainer decisions | in the case of disagreement between the maintainer and anybody else. So if the maintainer sticks SANDBOX_DISABLE=1 rm -fr / in global scope and refuses to move it, QA will have to get council approval to fix it? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 00:09:28 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | I think I agree with the part that security@ having near final say. Security have (admittedly not very often) screwed up in the past. Fixing a security issue at the expense of utterly h0rking an arch, for example, is not an acceptable solution... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 09:09:01 + John Mylchreest [EMAIL PROTECTED] wrote: | In this specific instance, impossible is effectively a point of view. | For me the question comes down to this.. If QA trump maintainer, then | who picks the QA staff? If anyone can become QA staff, then this is | questionable in itself. is QA becoming another council with a sole | purpose? If so I'd like to see an election again. At the end of the | day the pack have to have faith in the team doing the work, and | disagreements are obviously contrary to that. QA consists of whoever is on the QA project page. To be added, you must convince the existing QA team that you know what you're doing. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] SRC_URI component naming collision
On Mon, 27 Feb 2006 10:46:23 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | Where is this general consensus documented (other than an email sent | out a few days ago). I'd have to go with Paul on this assumption. I | don't see the problem with keeping a package such as stu's in portage | as long as it doesn't affect other users. Do you honesty expect that | we will get a sterile tree out of this? Please focus your QA efforts | are more important and visible issues. Going on a witch hunt to fix | one problem compared to the bigger issues we know we have is simply | silly. This is really starting to look like a power issue rather than | a QA issue. You know, funnily enough, QA has filed a whole heap of bugs on the conflicting digest issue. With every other maintainer for bugs we've filed, the developer in question has worked with us to fix the issue, and thanked us for pointing out the problem. The only reason this one has gone so far is because of Stuart repeatedly closing the bug off and refusing to discuss alternatives. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 10:47:58 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | So if the maintainer sticks SANDBOX_DISABLE=1 rm -fr / in global | scope and refuses to move it, QA will have to get council approval | to fix it? | | Use some common sense when showing an example please. We all know that | something that stupid needs to be delt with quickly. If we all recognise that level of stupidity, please explain how the heck this got into the tree: http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/bootstrap_cmds/bootstrap_cmds-44.ebuild?rev=1.1content-type=text/plain -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 17:09:42 + John Mylchreest [EMAIL PROTECTED] wrote: | My point was the more along the lines that the existing QA team need | to convince the rest of the development community that they know what | they're doing first. Whats stopping the existing QA team disregarding | all new applicants because they enjoy having authority? Especially | when its mis-placed authority. Oh, that one's easy. We're all lazy and would never turn down someone decent who is going to reduce our workload :P -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] bug #20201 and bbapm
On Mon, 27 Feb 2006 12:15:13 -0500 Alec Warner [EMAIL PROTECTED] wrote: | bbapm has been masked due to no one responding with anything useful to | last rites e-mail. It will be punted in 30 days. No no no. Do this properly. Clean up *all* the broken blackbox applets, not just the one that has someone whining on a bug report. There are at least two in the tree that're more broken than this. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 12:21:29 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: | if something is going to lead to considerable damage and the | maintainer is unwilling to resolve the issue, then i'm pretty sure | there's more to be resolved here than fixing a package Sure. There're other parts of the document that address that. Getting the issue fixed, however, has higher priority than any disciplinary action. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] bug #20201 and bbapm
On Mon, 27 Feb 2006 18:54:13 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | *Please*, be so kind and look at metadata.xml for those ebuild, then | just either do it *yourself* or ask someone from your fellow-devs in | commonbox herd to do it for the other ebuilds that you failed to | mention above... Don't move broken stuff on other people's shoulders, | as you've already done once. | | I fail to see why are you claiming here that there's even more broken | stuff in the tree, yet as a member of maintainer herd haven't dealt | with that properly for quite an extensive period of time - and then | you are asking *other* people to do something properly. Did you read herds.xml yet? Allow me to explain the root of the problem. You're so obsessed with getting that one bug closed that you're not addressing the actual issue, which is that the original bb* demo code was hideously wrong in several places and thus there are a whole load of broken packages in the tree. Closing this one bug off will not, in the grand scheme of things, fix anything. All it will do is give you a false sense of achievement and make me or someone else file yet another bb* is broken bug. If you're really looking to help here, solve the problem properly. There is more to it than getting one bug closed. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 12:05:58 -0600 Grant Goodyear [EMAIL PROTECTED] wrote: | Of course, that leaves the question of who decides on the severity of | a QA violation? All this talk of severity, and no talk of ease of detection or ease of fixing... Allow me to explain. There are certain not particularly high impact issues that can very easily be detected, and with 100% reliability, by The Thing About Which We Do Not Talk. Any individual one of these doesn't look like such a big deal, but when we're talking a couple of hundred instances, all of which can easily be fixed in less overall time than it would take to even detect one instance of a particular severe problem, it's most definitely worth concentrating on the 'easy' issue. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] bug #20201 and bbapm
On Mon, 27 Feb 2006 15:23:07 -0500 Alec Warner [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Mon, 27 Feb 2006 12:15:13 -0500 Alec Warner [EMAIL PROTECTED] | wrote: | | bbapm has been masked due to no one responding with anything | | useful to last rites e-mail. It will be punted in 30 days. | | No no no. Do this properly. Clean up *all* the broken blackbox | applets, not just the one that has someone whining on a bug report. | There are at least two in the tree that're more broken than this. | | I am not the blackbox maintainer, nor do I wish to be. In this | particular case I'm just tired of hearing Jakub and you go at it, and | since no one else acted, I chose to act. Sorry if you thought | otherwise. Yeah, see, if it were as simple as just nuking the one app I'd've done it a long time ago. Just killing one package is ignoring the real problem here. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 20:26:10 + Stuart Herbert [EMAIL PROTECTED] wrote: | On Mon, 2006-02-27 at 17:08 +, Ciaran McCreesh wrote: | Abuse from people like you whenever someone finally gets brave | enough to document all the ways in which webapp-config is broken. | | This isn't the first time we've heard this tune from you, and alas I | fear it won't be the last. | | You know where bugzilla is. You know how to contact any of the | webapp-config maintainers via email, or via IRC. We're ready to | listen to your input, and to work with you (or anyone else) on fixing | any genuine problems that webapp-config has. The more feedback we | get, the better we can make this package for everyone's enjoyment. Then please start with bug 120088. Once that one's fixed we'll go from there. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 20:45:30 + Renat Lumpau [EMAIL PROTECTED] wrote: | Then please start with bug 120088. Once that one's fixed we'll go | from there. | | #120088 (dev-lang/php breaks non-interactivity and does not work on | default USE) has nothing to do with webapp-config. What's your point? My point is that that's a nasty QA bug that's relying upon input from Stuart to be fixed. Whilst that one's still alive, I'm not going to go around filing more similar breaks non-interactively bugs because the discussion will just get repeated over and over. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 21:49:23 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | rhetorical question | May I ask how is that related to webapp-config? | /rhetorical question It is related to Stuart, and hence utterly relevant to the conversation. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | No, that's not a policy document, ebuild policy is documented here: | http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printablepart=3chap=1 No, the whole thing is policy. | Moreover, the cited howto is wrong, since it will break built_with_use | checks No, that's a separate issue. | The howto also doesn't apply to cases like | recode vs. mysql, because that's a completely different | functionality, you can't exactly choose which one is better on behalf | of the user. No, it does apply. | So, to sum it up - you can't make up for portage's lack of features by | inventing a policy that doesn't work. Once again - until portage can | handle USE-based dependencies and until portage can handle | conflicting use flags, there's nothing that could be done here. Until Portage can handle conflicting USE flags, one should take the policy-mandated solution that has been sufficient for everyone else for four years or more. Sure, it's not perfect, but it's a hell of a lot better than repeatedly exploding in the user's face midway through an install. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
