Re: [gentoo-dev] pax-utils.eclass: elog -> einfo?
On Sun, 13 Mar 2011 17:38:29 -0400 "Anthony G. Basile" wrote: > On 03/13/2011 04:19 PM, Mike Frysinger wrote: > > On Saturday, March 12, 2011 07:36:35 Paweł Hajdan, Jr. wrote: > >> I wonder why pax-utils.eclass uses elog instead of just einfo. An > >> example message looks like this: > >> > >> * Fallback PaX marking -m > >> * out/Release/chrome > >> > >> IMHO it's not very useful in the elog messages, but maybe there are > >> scenarios in which it is useful. > >> > >> My idea is to just replace all elogs with einfos in > >> pax-utils.eclass. What do you think? > > i think it depends on the person. for people who dont use > > grsec/PaX, they probably could care less and never see this > > output. for people who do, they probably do want to see this. > > > > maybe have it `elog` only when [[ $(uname -r) == *-grsec* ]] > > -mike > > blueness@yellowness ~ $ uname -r > 2.6.37-hardened-r5 > > so you need == *-hardened-* I'd suggest doing something like: use hardened && elog ... There's an argument that it's better to make decisions according to make.conf settings rather than the host system configuration, not least to cater for people doing cross-builds. Assuming cross builds work at all; I've not tried that for a long time. Kev.
[gentoo-dev] Quantity of open bugs
Hi all, I was nosing through bugzilla, and noticed: * Number of open bugs is greater than 14,000 * Number of open bugs untouched for more than 2 years - well over 2000. * Number of open bugs untouched between 1 and 2 years - well over 2000. * Number of open bugs untouched between 6 months and 1 year - well over 2000. * Number of open bugs untouched between 3 months and 6 months - over 2000 The winner is bug #78406, which hasn't been touched for over 2240 days - over 6 years - at the time of writing. I would guess these old untouched bugs aren't actually going to be touched, ever - a lot simply won't be relevant any more for one reason or another. All they're doing is cluttering up bugzilla. So I'd like to suggest a drastic, perhaps controversial action. Mark all bugs that haven't been touched for over (say) 3 months as "Resolved:Wontfix", with a polite comment saying that it is closed due to lack of resource amongst the volunteer developer community. I'm sure a suitable bugzilla script wiz could do that relatively easily. Users who care about such bugs can still comment on them, or talk directly to the assigned dev to highlight it's still a relevant issue to them, or even to supply a solution against the current tree. It could be an ongoing policy, in which case, users who care about them can keep bugs alive simply by posting useful updates to the bug, describing how the issue still applies to a new revision for example. Just a thought from an old ex-dev... Kev.
[gentoo-dev] Retiring
Hi all I'm finally giving in to reality and retiring as a Gentoo Dev. I've been effectively inactive since March last year and lack of time means that isn't going to change any time soon. I'll still be using Gentoo of course, so I'll still stick my nose in on bugzilla now and again :) There's not much out there that depends on me; packages that have my name against them as maintainer are: app-admin/eselect-oodict app-text/hunspell app-text/info2html sys-apps/qtparted and app-dicts/myspell-* There's useful work to be done on the myspell dictionaries (which are used by hunspell). Currently various applications install their own copies of dictionaries in various places - something that is just wasteful and lazy. I'd always intended to finish an eselect module for managing myspell dictionaries; got some work done but never finished it off. eselect-oodict was a quick version for dealing with OOo.org dictionaries (which uses myspell dictionaries) and you can find my attempts at a more generic eselect-myspell on bugzilla. Doing that needs co-operation from the relevant applications (particularly the mozilla application set). qtparted is controversial and may not be worth holding on to; see bugzilla for details. Lastly, just to say I've learned a lot from my involvement with Gentoo over the time I was active and it has been very worthwhile for me; hopefully I've managed to contribute at least something back to compensate! All the best, Kev. signature.asc Description: PGP signature
Re: [gentoo-dev] distcc and precompiled headers
On Fri, 18 May 2007 08:41:10 -0400 (EDT) "Caleb Tennis" <[EMAIL PROTECTED]> wrote: > Based on some recent findings, it looks like the two above mentioned > features don't work together. pch don't get distributed to distcc > nodes, so they're basically mutually exclusive. However, distcc is a > FEATURE and pch are a USE flag. > > Should we just put a check in each ebuild that uses the pch use flag, > make an eclass, or build something into the package manager(s) ? > Thoughts? I'd go with a 'pch' utility eclass, and have packages that IUSE pch add a call in pkg_setup (which would either die, or disable distcc). On a related note, we had a discussion on bug #128810 a while back about whether the package manager should be doing distcc and ccache at all, anyway. Personally I think the package manager shouldn't be involved in that at all. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] 'stricter' FEATURE and "poor programming practices" notice
On Thu, 17 May 2007 13:12:01 +0200 Hans de Graaff <[EMAIL PROTECTED]> wrote: > I've had the 'stricter' FEATURE turned on for some time and found that > many packages failed due to the QA notice regarding poor programming > practices. I filed a few bugs for this but have not gotten a lot of > response, or the suggestion to talk to upstream. Obviously the latter > is always a good option, but I'm wondering what the intend behind > this QA notice is. > > My view is that if this is a QA notice then, if a package doesn't > emerge because of it, it is a Gentoo QA bug and package maintainers > should be responsible for fixing it. > > If the notice is only informational, then the emerge process should > not be stopped because of it (and this would mean that it is nice to > fix these issues but not mandatory). Yeah; it's a bit of a pain, especially if you have '-Wall' in CFLAGS (a large proportion of packages fail if you do). I've ended up removing stricter from FEATURES, which is far from ideal as it means all the other checks are no longer fatal, some of which I really want to know about at emerge time (well, to be honest, I've ended up patching portage locally to make the "bad code" thing non-fatal). In a broader scope, we could do with a "QA check control" file or something to provide finer-grained control of these QA checks. However the QA checks themselves seem to be a bit ad-hoc at the moment. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?
On Sat, 12 May 2007 12:41:58 +0100 "Marcus D. Hanwell" <[EMAIL PROTECTED]> wrote: > There is a template library called Eigen I would like to add to the > tree. It is a dependency of an application I would like to add > shortly. It will also end up being a dependency of KDE 4 (for > kalzium). My question relates to the licence the code is released > under. > > It is licenced under the GNU GPL, version 2 or later with the > following exception, This is a common situation with GPL compilers - some are licensed so that they can be used to build non-GPL software, some can only be used to build GPL software. The situation with Eigen is similar to the "libgcc exception" for GCC. We don't mention that in the LICENSE for gcc. This is the exception that allows you to build non-GPL software with gcc (note for the interested - if you build profiled executables with gcc, the GPL applies to the built executable since the profile support code linked into the executable is licensed purely under the GPL - not a real problem as no-one distributes profiled executables!). However there's also a similar exception for gnat-gcc; that has a separate license file GMGPL which explains the situation there. However this is talking about extra libgcc stuff that is Ada-specific - the standard libgcc exception is not mentioned. For information, gnat-gpl (the AdaCore-sponsored version) doesn't have the exception, so is straight GPL - this also means you can't use gnat-gpl to build and distribute BSD-licensed software, for example. So currently we're inconsistent. We must be accurate in our license declarations, I think, so my view is if Eigen has a license that is GPL with some exception, that should be made clear. All these exceptions are doing the same thing - relaxing the GPL as it applies to the compiler (or template library in this case), so that it does not apply to works created using it. I like the "GPL-2-with-linking-exception" license name that the gnu-classpath package uses; perhaps we could include (concatenate) all the exception clauses that lead to the same thing into that license file and have the relevant packages use that license name. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On Mon, 30 Apr 2007 05:07:00 +0200 Roman Zimmermann <[EMAIL PROTECTED]> wrote: > Am Montag 30 April 2007 00:11 schrieb Ciaran McCreesh: > > On Sun, 29 Apr 2007 14:56:57 -0700 > > > > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > > Anyone who wants to build a static binary wants the static libs. > > > Given the difficulty in universally enabling or disabling their > > > builds because of build-system differences, building them and > > > tossing them in the trash with INSTALL_MASK, as Marius suggested, > > > seems like the best way to go. > > > > The best way to go or the only viable short term solution? Best way to go, IMO. > That's the point! Universally disabling static builds can't be a > longterm solution. The only sane way to do this is on a per ebuild > basis. The thing about static libraries, is that the ebuild that creates them doesn't know whether anything else will want to use them. It may be that in practice, most libraries are never used in their static form - but the point is that the ebuild doesn't know enough information to make the decision. However, with INSTALL_MASK, the user makes the decision never to have static binaries, and thus gets a system free of static libraries. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
On Sun, 22 Apr 2007 17:46:18 +0200 Danny van Dyk <[EMAIL PROTECTED]> wrote: > Am Sonntag, 22. April 2007 schrieb Michael Cummings: > > On Sat, Apr 21, 2007 at 08:47:54AM +0100, Kevin F. Quinn wrote: > > > I do the same. The '$Header: $' tells me which version of a file > > > in the CVS tree I last synced to in my overlay, then I can just do > > > a cvs diff on the tree to get a patch of differences since then. > > > Very useful. > > > > FWIW, I've used the $Header $ to determine if a person is looking at > > the latest greatest or needs to synch up first (in particular when I > > was dealing with an eclass bug). Very useful when dealing with bugs > > and you need to confirm that the user is completely synch'd up and > > looking at a current tree or not (because just asking when the last > > time they synch'd doesn't help). > > This can be done using checksum like SHA1 much better, as people can > edit their ebuilds/eclasses/profiles and forget/lie about it, and > still have the same $Headers$ line. In practice I find it's rare that a user has been hacking around in the eclasses. All the SHA1 tells you is that it's not the most recent, but it's not easy to determine from the SHA1 exactly which version they do have (so it's not enough to determine what's different). Having said that, the most accurate way to find out what they have is to get them to attach the eclass and diff it yourself. However relying on the SHA1 also means you can't just say things like, "Check eclass is version 1.836 (look at the "$Header" line at the top of the file)." -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
On Sat, 21 Apr 2007 12:00:55 +0200 Thilo Bangert <[EMAIL PROTECTED]> wrote: > > I do the same. The '$Header: $' tells me which version of a file in > > the CVS tree I last synced to in my overlay, then I can just do a > > cvs diff on the tree to get a patch of differences since then. Very > > useful. > > right - but this functionality would not go away - it would just have > to be implemented differently. a potential move to git would make > this much more easy, if i am not mistaken. By "implemented differently" you mean "by adding extra steps and data to the synchronisation process". Currently, I compare the Header field in my overlay (which SVN doesn't touch) with that in the Gentoo CVS, and use the difference to drive the 'cvs diff' command to get a patch. Removing the header would mean I'd have to record the origin version somewhere, and keep that up-to-date whenever the file is re-synchronised. Having said that, it only works for me because my overlay is in SVN and and is not configured to process CVS header keywords. However I can honestly say that in my experience, the file revision identification is _always_ recorded in the file - I've never yet seen an SCM used in practice that didn't have that information. The reason people put that information in, is so that when the file is taken out of the context of the SCM repository, it's still clear where it came from. This is precisely how I'm using it. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, 20 Apr 2007 14:30:54 +0200 Fabian Groffen <[EMAIL PROTECTED]> wrote: > On 20-04-2007 08:22:42 -0400, Mike Frysinger wrote: > > does anyone actually find this useful ? i think ive used the value > > in there like once (when in reality a `md5sum` would have worked > > just as well) ... otherwise, from my perspective: > > - it causes annoying bogus hunks in diffs > > - not uncommon for people to contact me as the maintainer because > > i'm in that > > - wastes space (well, probably not a strong argument due to bytes > > vs blocks) > > - for mostly green users, it's confusing and they get it wrong > > I use it to make deltas of changes made in the tree, and apply those > deltas on the overlay I'm using. Without $Header: $ there I have no > way to actually see which version I'm dealing with, so which > revisions to retrieve for differences. > For that reason, I prefer as much files as possible in the tree to > have a $Header: $ somewhere, so I can easily sync, keeping my local > changes. I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: SCM choices (was: Re: [gentoo-dev] Re: Gentoo infra backups)
On Wed, 28 Mar 2007 07:58:59 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Please, everyone, go back and read the actual *facts* that were > discovered using copies of *our* repositories before going around > using data from outside sources. Alec Warner's test results are here, of course: http://www.gentoo.org/proj/en/infrastructure/cvs-migration.xml FI on gentoo-x86 we're doing about 10,000 commits a month (from 100 to 500 commits a day), according to my #gentoo-commits logs. (Assuming the SVN revision is a 32-bit number, it'll take about 1000 years to saturate). Personally I'm a fan of SVN over CVS, but that's from a client perspective not the server. It would be interesting to find out why SVN consumes double the bandwidth to checkout a full tree. It would also be interesting to find out why the server disk usage is 4x that of CVS (and what difference the choice of back-end makes). FWIW the things I like in SVN, in order of importance to me are: 1) ability to do diffs off-line 2) maintains history when copying, moving etc (e.g. 'svn log' of CPV-r2 traces the history back through the point at which it was copied from CPV-r1) 3) command line is largely the same as CVS (which avoids confusion when moving between CVS and SVN repositories) Alec - any chance you could flesh out exactly what tests you did? I would have expected that the update-diff-commit cycle that we (well, repoman) typically do would be more efficient on SVN than CVS, in terms of the amount of data transferred between the client and server (svn client sends diffs, cvs client sends whole files, and the diff operation in the repoman cycle would be local in svn). -- Kevin F. Quinn -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] {Guide,Project,Foo}XML too confusing for many devs?
On Mon, 26 Mar 2007 08:05:58 -0700 (PDT) "Alec Warner" <[EMAIL PROTECTED]> wrote: > do you as a developer find writing web pages to be confusing or > difficult? No. > Is there not a good tutorial for learning our webpage XML syntax? For my use, I've found the available docs sufficient. > Do you find that you bump up against restrictions in the DTD or other > problems that prevent you from expressing yourself properly? No. I do try to keep things simple, which may be why. > Do you have any idea how to actually go about extending GuideXML > (or the other XML's we provide) Have you ever tried? No and no - I've never had the need. > Could we improve training with regards to any of this? Do we really expect people to hack around with the DTDs? I thought the whole point is that you stick to the stuff provided by GuideXML. We're not writing fancy interactive websites - we're just writing some docs. All that said, I've only ever written single-page docs. I don't _like_ GuideXML, but have no inclination to do anything differently for Gentoo website stuff, and it's sufficient for the stuff I've used it for. I wouldn't want to write anything sizable in XML, as the markup just gets in the way, much like many other markup languages (LaTeX, GROFF etc). Docutils' RST (reStructuredText) is much better in this regard; its markup is much less intrusive than anything else I've used. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Cultural Differences (was: Suggestion: INVALID -> NOCHANGE in bugzilla)
On Sun, 25 Mar 2007 17:53:51 +0300 Rumen Yotov <[EMAIL PROTECTED]> wrote: > May be a little OT, but just two of four ancient-sayings: > 1.Never accept things personaly (everyone is acting on his own > motives); 2.Try not to make assumptions (just ask questions, till you > get it). Clearly (from above, etc.) i'm not a native speaker, so > forgive my wording. Hope you get the meaning ;) > Better try to find common grounds, that assume something which (very > often) isn't true at all. Very true. My favourite approach is the traditional TCP/IP adage, "be conservative in what you send, liberal in what you receive". -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID -> NOCHANGE in bugzilla
On Sat, 24 Mar 2007 22:46:07 +0100 Marius Mauch <[EMAIL PROTECTED]> wrote: > On Sat, 24 Mar 2007 22:07:08 +0100 > "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > > > Certainly good explanations as to why a bug is being closed are to > > be encouraged. My issue isn't with that - it's with the way that > > the marking INVALID is perceived, when there's no need to be so > > harsh. > > And NOCHANGE could be perceived as "We're not going to change this > anyway", No, that would be WONTFIX (or CANTFIX). NOCHANGE implies there is nothing wrong with the existing code, so there's no question of whether we should change anything or not. > so you're not really solving any problem by just changing a > label. Some people will only ever be happy if they get the FIXED > label on their reports. I'm not sure that's so. There are certainly many who don't like their reports marked INVALID, at least initially. I know I've seen many instances where the word INVALID has got peoples hackles up, yet after it's explained that it doesn't imply they shouldn't have raised the report in the first place, they're ok (I've explained to people before that the INVALID marking just indicates that there's no change required to the tree). This is the same issue I have with "NOTABUG" - it's like saying, "you're wrong, shouldn't have raised the report", just perhaps not as in-your-face as INVALID. Still, it looks like I'm being out-gunned on this one, and I'm starting to repeat myself, so I'll be quiet for a bit... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID -> NOCHANGE in bugzilla
On Sat, 24 Mar 2007 23:17:52 +0200 Alin Năstac <[EMAIL PROTECTED]> wrote: > Kevin F. Quinn wrote: > > The problem I have with NOTABUG is pretty much the same problem I > > have with INVALID - it's not as severe, but it still does the same > > thing to the user (i.e. slaps him with a wet fish rather than a > > frozen one). > > > > > Maybe, just maybe, the problem is not with the resolution name, but > with peeps who cannot accept they could be wrong. > For the most of us, INVALID doesn't mean YOUAREAMORON. My point is that if someone raises a bug, they clearly have an issue - if they didn't, they wouldn't have raised a bug. Closing INVALID is like saying they never had an issue - when clearly they did have an issue, even if it was just an issue of understanding. > A NOTOURBUG resolution would be pointless. I cannot imagine a possible > scenario in which I could choose such resolution over the existing > ones. Probably you want it as a replacement for UPSTREAM? Er, I never suggested NOTOURBUG - as you say we already have UPSTREAM. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID -> NOCHANGE in bugzilla
On Sat, 24 Mar 2007 22:02:48 +0100 Ioannis Aslanidis <[EMAIL PROTECTED]> wrote: > I think that there is a problem of concept. If a bug is marked > INVALID, it's because it is not a real bug. Marking a bug NOCHANGE or > NOCHANGEREQUIRED, not only overlaps with other resolutions, but fails > to better explain the reason why the bug was closed, whereas INVALID > indeed means that the reported bug is simply not a bug or that it was > reported to the wrong place. I don't think it overlaps, as I described before (whether it does or not comes down to how you define it, of course). As to knowing why the bug was closed, personally I would rather the closure flag indicate the impact on the tree etc - i.e. whether something was changed (FIXED), could have changed but didn't (WONTFIX) or would have changed but couldn't be changed (CANTFIX) or in no way indicated a change (NOCHANGE). Bugs filed in the wrong place should just be re-assigned to the right place, not closed INVALID (at least, not at the point where it's still in the wrong place). > Even though it might look harsh to the user to get such a resolution, > it's also harsh for the developers to have to handle bugs that are > not related to them. > > Still, changing the name from INVALID to NOTABUG + NOTOURBUG does > make sense, as the meaning doesn't get lost. I don't think we need NOTOURBUG. Anything that's a real bug, but not a bug in what we do, can be marked UPSTREAM. > > Kevin F. Quinn wrote: > > On Sat, 24 Mar 2007 19:14:38 +0100 > > Marius Mauch <[EMAIL PROTECTED]> wrote: > > > >> On Sat, 24 Mar 2007 18:34:21 +0100 > >> "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > >> > >>> People reporting bugs often get annoyed when their bug is marked > >>> INVALID; especially when they're relatively new to the Gentoo > >>> Experience. We've all seen it many times, I'm sure. > >>> > >>> Arguably no bug is invalid in the normal sense - if someone raises > >>> an issue, they have an issue, regardless what we think of it. To > >>> that end I'd like to propose bugzilla be reconfigured to use the > >>> phrase "NOCHANGE" instead of "INVALID". NOCHANGE would indicate > >>> that whatever the original issue, no change is needed on our part > >>> to resolve the issue. > >> _If_ it's changed then please to something else, NOCHANGE would > >> overlap with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't > >> that obvious to me at least. A fake resolution that's mentioned on > >> IRC from time to time is NOTABUG which would fit better here. > > > > Well, I meant for NOCHANGE to be "no change needed", but figured > > NOCHANGEREQUIRED is a bit longwinded. It implies the issue is > > understood, it has been explained to the bug reporter, but requires > > no change to anything: > > > > CANTFIX: the problem exists, but no sensible way to fix it exists > > WONTFIX: the problem exists, but for some reason it won't be fixed > > WORKSFORME: can't replicate > > > > NOCHANGE: no change needed > > > > The problem I have with NOTABUG is pretty much the same problem I > > have with INVALID - it's not as severe, but it still does the same > > thing to the user (i.e. slaps him with a wet fish rather than a > > frozen one). > > -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID -> NOCHANGE in bugzilla
On Sat, 24 Mar 2007 14:48:25 -0400 Michael Cummings <[EMAIL PROTECTED]> wrote: > On Sat, Mar 24, 2007 at 06:34:21PM +0100, Kevin F. Quinn wrote: > > People reporting bugs often get annoyed when their bug is marked > > INVALID; especially when they're relatively new to the Gentoo > > Experience. We've all seen it many times, I'm sure. > > > But sometimes, just sometimes, the bugs are absolutely 100% invalid. > "Emerging nano broke my apache" (random fake example with two > unrelated packages)(or...are they...?) Well, if someone raises a bug, they have an issue. They may not understand it properly, and may frequently mis-diagnose it, but there's still an issue for them. To take your example, "emerge nano broke my apache" actually implies that apache isn't working properly for the reporter - just because they incorrectly assign blame to an emerge of nano doesn't mean everything is peachy. As the details are eked out of the reporter, the summary may become "ssl support in apache broken with openssl-1.2.3.4", IYSWIM. We shouldn't be closing bugs as INVALID just because the original reporter mis-diagnosed the problem. There are cases where people raise a bug because they've mis-understood something and they don't realise it's behaving correctly - i.e. the behaviour they are complaining about is actually as-designed expected behaviour. But even then, the user had an issue - resolved by the explanation, even if the outcome is no change to anything. Closing it INVALID comes across too often as "oh you're so stupid to raise this as a bug" and there's no need for that to happen, imo. NOTABUG would do well enough in that sort of case I suppose, but there's still an overtone of "you shouldn't have raised this" to it. > More important is to explain > to the user *why* it is invalid, and leave it open to them to argue > and reopen the bug. Better communication, Certainly good explanations as to why a bug is being closed are to be encouraged. My issue isn't with that - it's with the way that the marking INVALID is perceived, when there's no need to be so harsh. > not more convoluted closure > flags, is the solution. IMHO. You know. Word. The idea was to _replace_ INVALID with a less provocative name, not add more closure flags. I certainly agree that we don't need more closure flags. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID -> NOCHANGE in bugzilla
On Sat, 24 Mar 2007 19:14:38 +0100 Marius Mauch <[EMAIL PROTECTED]> wrote: > On Sat, 24 Mar 2007 18:34:21 +0100 > "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > > > People reporting bugs often get annoyed when their bug is marked > > INVALID; especially when they're relatively new to the Gentoo > > Experience. We've all seen it many times, I'm sure. > > > > Arguably no bug is invalid in the normal sense - if someone raises > > an issue, they have an issue, regardless what we think of it. To > > that end I'd like to propose bugzilla be reconfigured to use the > > phrase "NOCHANGE" instead of "INVALID". NOCHANGE would indicate > > that whatever the original issue, no change is needed on our part to > > resolve the issue. > > _If_ it's changed then please to something else, NOCHANGE would > overlap with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't > that obvious to me at least. A fake resolution that's mentioned on > IRC from time to time is NOTABUG which would fit better here. Well, I meant for NOCHANGE to be "no change needed", but figured NOCHANGEREQUIRED is a bit longwinded. It implies the issue is understood, it has been explained to the bug reporter, but requires no change to anything: CANTFIX: the problem exists, but no sensible way to fix it exists WONTFIX: the problem exists, but for some reason it won't be fixed WORKSFORME: can't replicate NOCHANGE: no change needed The problem I have with NOTABUG is pretty much the same problem I have with INVALID - it's not as severe, but it still does the same thing to the user (i.e. slaps him with a wet fish rather than a frozen one). -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] Suggestion: INVALID -> NOCHANGE in bugzilla
People reporting bugs often get annoyed when their bug is marked INVALID; especially when they're relatively new to the Gentoo Experience. We've all seen it many times, I'm sure. Arguably no bug is invalid in the normal sense - if someone raises an issue, they have an issue, regardless what we think of it. To that end I'd like to propose bugzilla be reconfigured to use the phrase "NOCHANGE" instead of "INVALID". NOCHANGE would indicate that whatever the original issue, no change is needed on our part to resolve the issue. Any reasons why this would be a bad idea? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
On Sat, 17 Mar 2007 10:46:22 +0100 "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote: > One thing we could do would be to separate hierarchy from version > naming. This is where upstream version numbers fail to have a decent order (like your example where later versions have lower version numbers). It could be done for example by extending metadata to include definitions of unnatural ordering, but I don't think it's worth the effort. So far we deal with that on a case-by-case basis, and live with the pain when it occurs. > This would prevent cases like currently with rosegarden (~)1.2.4 > (~)1.4.0 4.1.0-r1 4.1.0-r2, where it really should be 4.1.0-r1 > 4.1.0-r2 (~)1.2.4 (~)1.4.0. For example, a simple solution is to just re-number the (presumably older) 4.* as 0.4.* and be done. That would also solve the potential future problem when the latest release reaches 4.* again. The sequence I would do is: 1) copy 4.1.0* to 0.4.1.0*, commit to the tree (here you could either rig the SRC_URI to keep the old tarball names, or copy the old tarballs again with the new revision number) 2) Alter any packages that depend on the 4.1 versions explicitly, to depend on the 0.4.1 versions (after you're sure the new 0.4.* versions are in the tree). 3) Remove the 4.1* versions - after a delay (a few days, a week, whatever, depending on how often your users are likely to update); in the changelog note that users should expect a downgrade and it is ok to do so. As a minimum, delay until you're sure (1) and (2) have reached the rsync mirrors. 4) Get 1.2*, 1.4* stablilised some time later in the normal way. Actually a quick scan of the tree shows there's nothing affected by (2) so that step can be skipped. I'd recommend still having a delay between the copy (1) and the removals (3) - at least long enough for the copies to propogate to the rsync mirrors before the removals happen (I'd probably do the copy one day, check that got through ok the next day and do the removals then). Noting the expected downgrade in the changelog when the higher-numbers are removed is important (this is what users will see if they do emerge -l). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Summary for 15 March 2007 special council meeting on CoC
I'd just like to say good job and thanks, to all involved in the CoC. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Gentoo's problems
On Fri, 16 Mar 2007 08:41:50 + Steve Long <[EMAIL PROTECTED]> wrote: > IMO ciaran has definitely been trolling this list and it's doing my > head in. Is there anyone else who feels the same, strongly enough to > risk his ire? If you think Ciaran is trolling, just ignore him. Be part of the solution, not the part of the problem. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo's problems
On Thu, 15 Mar 2007 18:40:05 +0100 Jakob Buchgraber <[EMAIL PROTECTED]> wrote: > So why don't you start rewriting, refactoring and improving the > portage source? It definitely doesn't make sense to create a > competing package management system. "Patches welcome", I think is the appropriate response :) Seriously, if you want portage to be re-factored, just go ahead and do it; there's nothing to stop you. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Distrowatch
On Wed, 14 Mar 2007 23:40:54 +0100 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > ps. If someone wanted to start a gentoo-politics, by all means, go > ahead, just don't expect anyone to read it. That's not such a bad idea, really. I don't mean creating -politics as such, but the idea of separating out these long debates from -dev, so that -dev can focus on technical issues (is this eclass ok, last rites, how do I do X,Y,Z in ebuilds etc). When these big debates arise, discussion could be shunted to the separate list, requiring those who care enough to join the debate, to join that list, which may help limit the number of people who get involved. Perhaps gentoo-discuss. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Why I don't think the CoC is a good idea
On Thu, 15 Mar 2007 00:06:28 +0100 Alexandre Buisse <[EMAIL PROTECTED]> wrote: > [...] But then, why do we need a Code of Conduct at all? There > is nothing in it that people don't already know and if they choose to > still commit the offense, it's either that they don't think it's one > or that they choose to ignore the consequences and commit it anyway. > In both cases, having a written code won't change a thing. This is a good point; effectiveness is key, and in designing a CoC one should be crystal clear what the document is expected to achieve. In the defense of having a CoC, it does provide a document we can point to when asking people who don't realise their behaviour is disruptive, to moderate that behaviour. Before we commit ourselves to a CoC, we should agree what the CoC precisely is _for_ - setting out the document scope should be the first priority. Here are some examples of what I mean by setting a document scope first: "The aim of the CoC is to encourage developers to work together productively in a positive atmosphere." "The aim of the CoC is to provide a point of reference for developers and users alike to decide if their behaviour is acceptable." "The aim of the CoC is to ensure Gentoo presents a professional image." "The aim of the CoC is to define what behaviour is acceptable for Gentoo developers and users." "The aim of the CoC is to force all developers to adhere to an Anglo-Saxon work ethic." Just some examples; I'm not suggesting any are right, and some are deliberately tongue-in-cheek. What I'm trying to do, is highlight the point that having a well-defined scope makes it easy to critically and objectively examine what should and should not be in the CoC. The scope can be decided in broad discussion - after which the CoC can be drafted off-line and then presented for review against the scope before final sign-off. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Distrowatch
On Wed, 14 Mar 2007 18:18:58 +0100 Christian Faulhammer <[EMAIL PROTECTED]> wrote: > "Kevin F. Quinn" <[EMAIL PROTECTED]>: > > > So please, friends, just ignore it, nothing positive will come of > > it. > > Unfortunately it made its way onto big news site and lowers the view > on Gentoo even more. From many comments I read we are a dying distro. Yeah; isn't the blog-o-sphere great :/ For a dying distro, we're showing up pretty active on http://cia.navi.cx/ - but then I guess DW aren't interested in anything so mundane as facts. Perhaps they're more interested in generating ad revenue from whipped-up scandals... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Distrowatch
On Wed, 14 Mar 2007 12:29:38 -0500 Dale <[EMAIL PROTECTED]> wrote: > And something good is coming from it too. They are setting up rules > so that this sort of thing doesn't happen again. I believe the move towards creating the CoC was in the pipeline before these outside events took place; it was a response to the surge on gentoo-dev itself, and as such an internally instigated matter. The pressure to get the draft approved in the ridiculously short period of three days in the middle of a week does look like it was affected by the bad PR in junk outlets like DW. If that is the case, then it is most definitely a bad thing. > The mess in the last > couple weeks was not the first either. It will happen again if > nothing is done. That's the exact opposite of my reading. The so-called mess in the last couple of weeks is nothing so unusual - happens every few months or so, and IMO it's more about steam venting than the specific issues at hand at the time. Responding to the sort of pathetic blogging seen on Distrowatch is a bad thing, its sends the signal that rantings on the blog-o-sphere are due some respect, which the article of the 13th certainly does not. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Introducing the Proctors - Draft Code of Conduct for Gentoo
On Tue, 13 Mar 2007 19:25:23 -0500 Grant Goodyear <[EMAIL PROTECTED]> wrote: > [...] The previous doc had no "moral weight", so to > speak, because it was imposed on devs without any real discussion, and > that's made it hard to enforce. Moreover, there's long been notable > distrust of devrel, which historically made it hard for them to > enforce it. My belief is that "developer buy-in" would make all of > the difference in how effective a code of conduct would be. I think "developer buy-in" is absolutely _critical_ for this to work. Without it, the exercise will create more unnecessary ante between devrel and the rest of devs, and it'll be much less successful, even largely a waste of time. For the record, 3 calendar days for comment is a ridiculously small amount of time to achieve this. You could put something in place rapidly, if you want to be seen to be responding to the negative press in various quarters, but it must be on the explicit understanding that the CoC will be developed properly over a longer period of time. Short timescale notwithstanding, here are my comments on the document as a whole. I don't have time to be soft and fluffy over this, so forgive me if it comes across too strong. I agree firmly with Grant, that the doc should be positive in its wording throughout. I sent a critique of the old etiquette guide to devrel last week making exactly this point, however the new CoC still weighs in first with negatives and punishments. This is what happens when the document is drafted rapidly in response to, for want of a better phrase, a crisis in communications. The emphasis should on the positive and on empowerment, not on restriction and subjugation. For example, I'd start the document with something like (written previously as a suggestion for the etiquette guide): Developers are representatives of Gentoo; your behaviour as a developer reflects on Gentoo as a whole. These simple etiquette guidelines are here to help you to ensure your own behaviour is a positive asset to the Gentoo project. and I'd have statements like: Keep all your communications polite and focused on the technical discussion at hand. If a respondent is rude, obnoxious, offensive or annoys you in any way, choose to walk away rather than waste your time responding to it. As far as punishments are concerned, I wouldn't focus on specifics, but on the general aim: The elected proctors have overall responsibility for ensuring good standards of behaviour in all Gentoo fora (mailing lists, IRC, forums etc). They are tasked with taking appropriate action should problems arise. (could equally be 'proctors appointed by the elected council') Well, that's about all I can manage for now - don't expect a full critique in such a short timescale... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] mod_perl in apache conf
On Thu, 8 Mar 2007 17:34:39 -0500 Michael Cummings <[EMAIL PROTECTED]> wrote: > [...] (new subject line, so > hopefully unless your mail client threads but message-id's this should > break the chain) > X-Mailer: Claws Mail 2.8.0 (GTK+ 2.10.9; x86_64-pc-linux-gnu) I guess you realise now, if you didn't before, your mail program threads correctly by references ;) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: Copyright, non-US devs and Gentoo Foundation vs Gentoo (Was: [gentoo-dev] Some council topics for March meeting)
I note that FSF-Europe uses what it calls a "Fiduciary Licence Agreement" to gain the ability to prosecute license violations for software whose copyright is distributed amongst many owners. Discussion here: http://www.fsf-europe.org/projects/fla/fla.html and the boilerplate for FTF's agreement in PDF here: http://www.fsf-europe.org/projects/fla/FLA.en.pdf This may be more appropriate than a straight copyright assingment as used by FSF (US). I guess this is an issue for the trustees, rather than the council, but (b)cc'ed both for comment. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Some council topics for March meeting
On Sat, 3 Mar 2007 13:17:56 -0700 "Daniel Robbins" <[EMAIL PROTECTED]> wrote: > So, again, since you are participating as a key member in an official > Gentoo project, which is a developer-only privilege, you should either > have your dev access reinstated or be removed from the project. This is incorrect. The full implication here is that only devs can contribute significantly to Gentoo - which would be a big backwards step, and something we have gone through a fair amount of heart-ache to avoid. We have evolved various ways in which users can contribute valuable work; not just by posting into bugzilla (which was the only mechanism available when I joined, shortly after you left I think) but also working alongside "proxy devs", or working in with devs in overlays, working as Arch Testers and so on. Personally I work with several people who are not Gentoo devs, but are _critically_ important to the work that I do for Gentoo. After all, although we call ourselves developers, really we're integrators. Today, being a dev (which essentially means having commit access to Gentoo repositories) is mostly about taking responsibility for what is finally committed. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour
On Thu, 22 Feb 2007 19:08:48 +
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> The example given in ebuild(5) is:
>
> || (
> sdl? ( media-libs/libsdl )
> svga? ( media-libs/svgalib )
> opengl? ( virtual/opengl )
> ggi? ( media-libs/libggi )
> virtual/x
> )
Took me a while to figure out why anyone would want to write that; the
key is that ebuild(5) says only one of the conditions is satisfied;
i.e. even if all the dependencies are present on the system, the
package will build only against the first matching dependency.
The way I see it, the ebuild has to cater for the dynamic situation
anyway, for example doing something like:
src_configure() {
use sdl &&
has_version media-libs/libsdl &&
vid_conf="--enable sdl" ||
use svga &&
has_version media-libs/svgalib &&
vid_conf="--enable svga" ||
use opengl &&
has_version virtual/opengl &&
vid_conf="--enable opengl" ||
use ggi &&
has_version media-libs/libggi &&
vid_conf="--enable ggi" ||
vid_conf="--enable x11"
...
econf ${vid_conf} ...
}
So the dependency could be re-written as:
sdl? ( media-libs/libsdl )
!sdl? ( svga? ( media-libs/svgalib )
!svga? ( opengl? ( virtual/opengl )
!opengl? ( ggi? ( media-libs/libggi )
!ggi? ( virtual/x ) ) ) )
and you have the same result, which means the originally quoted syntax
is redundant. The only advantage it has is that it looks a little bit
prettier - but I'd argue the logic is clearer in the re-written version.
I guess the question remains, though - should that syntax be in EAPI=0
or not...
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, 22 Feb 2007 17:10:38 +0100 Marien Zwart <[EMAIL PROTECTED]> wrote: > The > idea was to not get any messy portage quirks documented as required > standard behaviour, the risk here is that we'll now get paludis quirks > documented as required standard behaviour. Well, that'll come out in review later, I would expect. I'll be surprised if the EAPI=0 spec Ciaran et. al. are working on just gets rubber-stamped without anyone looking! This thread shows there are a number of people who know what they're talking about and will review it heavily when it is published as a draft, and the council are unlikely to approve something that doesn't have broad support. With respect to having a small relatively closed group for initial drafting - it's a sensible way to do things in the early stages (it's not the only sensible way of course). If anyone doesn't like it, there's nothing stopping them from drafting their own in a different way. Indeed, having two strong drafts would be good, for finding idiosyncrasies from different perspectives. I have to say, the few queries I've seen from Ciaran have been exactly what I would (happily) expect. Queries about whether some current portage behaviours should be classed as quirks or EAPI=0 behaviour, presumably because the answer has a large impact on the design of a package manager. A good example is the recent one about whether EAPI=0 should require that the ebuild be sourced in every phase or only once. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] A Gentle Reminder
On Sun, 11 Feb 2007 12:33:52 + Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 11 Feb 2007 13:22:48 +0100 "Kevin F. Quinn" > <[EMAIL PROTECTED]> wrote: > | Do you object to such packages (specifically with security issues) > | being p.masked? > > If it's forcing a downgrade, yes. > > | I'm not sure we should be encouraging people to continue using > | packages when we know there are known security issues. > > You assume that being affected by a local denial of service on a > system where all users have the root password is more important than > using a package that has been verified to work by an arch team member. I said nothing about local denial of service; perhaps you're thinking of a particular instance - I'm not. To rhetorically follow your line of discussion, you're happy to have remote exploits remain in the tree (i.e. promoted by Gentoo) if a package is marked stable and a patch isn't available? The point about p.masking (rather than removal) is that we have then made reasonable efforts to inform the user and give them the opportunity to decide what they want to do, based on their own security policy - which could be to unmask locally and continue regardless, or could be to remove the package and try something else. That way they'd be making informed decisions. I think if we're to promote packages that have security issues on an arch, we need to be very clear that we're not making reasonable efforts to ensure that arch is free of known exploits. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] A Gentle Reminder
On Thu, 8 Feb 2007 22:34:32 + Stephen Bennett <[EMAIL PROTECTED]> wrote: > If any of you were thinking of removing the latest stable version of a > package, don't. Even if you're the package maintainer, even if there > are open security bugs against it, even if someone has filed you a bug > requesting that it be removed. If it's the latest stable version on > any architecture, you don't remove it. If you do, we'll know, and we > won't be happy. > > There. It's not that hard to understand, is it? Do you object to such packages (specifically with security issues) being p.masked? I'm not sure we should be encouraging people to continue using packages when we know there are known security issues. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Wed, 07 Feb 2007 23:14:14 -0500 Doug Goldstein <[EMAIL PROTECTED]> wrote: > Mike Frysinger wrote: > > On Wednesday 07 February 2007, Roy Marples wrote: > >> Welcome to baselayout-ng > > > > please god do not use this name ... just call it baselayout-2 > > -mike > > Mike how about... yabl.. or ya-baselayout.. How about baselayout-nb (No Bash) :) More seriously baselayout-posix, if posix-compliance of all scripts is a primary motivation. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Wed, 7 Feb 2007 15:11:39 + Roy Marples <[EMAIL PROTECTED]> wrote: > THE CONFIG FILE HAS TO BE PARSEABLE BY ANY SHELL Well, to be precise, it has to be parse-able by whatever runscript (-> runscript.sh) uses to source it. Currently that's hard-wired to /bin/bash; you're suggesting it be hard-wired to /bin/sh instead - but it could be configurable as an option to runscript: #!/bin/runscript --shell=/bin/sh > EVERY SHELL HAS TO BE PATCHED TO UNDERSTAND BASH ARRAYS > > Simply put, this has to work where /bin/sh is any valid POSIX shell. > > #!/bin/sh > . /etc/conf.d/net Another idea; have baselayout install different versions of init.d/conf.d and default shell for runscript depending on USE flags USE=posix -> install posix 'sh' versions of conf.d/init.d scripts, have runscript default to /bin/sh otherwise install the bash versions with runscript defaulting to /bin/bash. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] afflib licence (BSD4 like)
On Wed, 7 Feb 2007 19:50:10 +1100 Daniel Black <[EMAIL PROTECTED]> wrote: > Was looking at http://www.afflib.org/LICENSE.txt and was wondering if > it really had any Gentoo implications with adding it as a package. > > I asked a few questions. Does the following seem reasonable? Just one comment - we should maintain a list of packages that have this sort of clause, so that it would be easy for releng (for example) to either avoid mentioning them in the advertising for release media, or to credit as required. I'm thinking of the "2007.0 LiveCD is now out; upgraded packages include: ... afflib n.m ..." sort of announcement. Personally, I would say that if we include credits for one package, we should include credits for all - it hardly seems fair to prominently highlight credits for a minor package like afflib, without listing everyone else. It'd be a massive list, of course, but it would be fair :) > [1] https://bugs.gentoo.org/show_bug.cgi?id=123175 > > -- Forwarded Message -- > > Subject: Re: afflib licence > Date: Wednesday 07 February 2007 09:56 > From: Simson Garfinkel <[EMAIL PROTECTED]> > To: Daniel Black <[EMAIL PROTECTED]> > Cc: Brian Carrier <[EMAIL PROTECTED]>, Carl Hoffman > <[EMAIL PROTECTED]> > > Hi, Daniel. Thanks for your email. We'd be happy to have you add > AFFLIB to the Gentoo distribution. > > I'll answer your questions: > > Is inclusion in an online database like http://packages.gentoo.org? > > advertising and therefore subject to the clause 3? > > No, we do not consider that advertising. > > > What happens if a security > > vulnerability is found and a GLSA (Gentoo Linux Security Advisory) > > is issued. > > We wouldn't consider that to be an advertisement either. > > > What about a magazine article on Gentoo? > > We don't consider that to be an advertisement. > > > The University of California, Berkeley revoked their clause 3 in > > 1999 I > > believe because of similar legal vagueness over advertising. > > (ref: http://www.freebsd.org/copyright/license.html) > > Yes, I'm aware that they did this. > > We've decided to keep the advertising clause because Basis > Technology, the company that funded a substantial amount of the > AFFLIB development, wishes to be acknowledged in computer forensic > products that use AFF. We do not consider the bundling of AFFLIB on > a CDROM or online distribution of Linux utilities to meet the > requirements in section 3. > > Section 3 states: > > * 3. All advertising materials mentioning features or use of this > software > *must display the following acknowledgement: > > If your advertising of Gentoo mentions features or use of AFFLIB, > then we would expect you to say that AFFLIB is a product of Simson > Garfinkel and Basis Technology. But if you are merely including the > code and not mentioning the fact that you include AFFLIB in your > advertisements, then you have no need to mention Simson Garfinkel or > Basis Technology in your advertisements either. > > I hope that this email clears up any questions that you might have. > But if you have others, please feel free to drop me an email. > > -Simson > > On Feb 6, 2007, at 6:58 AM, Daniel Black wrote: > > Simson, > > > > Was looking at the afflib product and was considering adding it to > > the Gentoo > > distribution when I looked at the license and found the BSD-4 > > license variant. > > > > The problem with the particular license is the condition 3 > > advertising clause > > and its vagueity. > > > > Is inclusion in an online database like http://packages.gentoo.org? > > advertising and therefore subject to the clause 3? What happens if > > a security > > vulnerability is found and a GLSA (Gentoo Linux Security Advisory) > > is issued. > > Is this an advertisement? If Gentoo does a booth at an Expo is this > > included? > > What about a magazine article on Gentoo? > > > > The University of California, Berkeley revoked their clause 3 in > > 1999 I > > believe because of similar legal vagueness over advertising. > > (ref: http://www.freebsd.org/copyright/license.html) > > > > Can you consider doing the same? > > > > Other references: > > http://farragut.flameeyes.is-a-geek.org/articles/2007/01/08/a- > > shadow-lies-upon-all-bsd-distributions > > -- > > Daniel Black <[EMAIL PROTECTED]> > > Gentoo Foundation > > --- > -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 23:26:32 +
Roy Marples <[EMAIL PROTECTED]> wrote:
> On Tue, 6 Feb 2007 21:28:04 +
> Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
>
> > I think it's more that you're expected to justify *why* the bash
> > requirement is so bad, given the cost of changing.
>
> 1) Lack of choice.
> Gentoo is all about giving the user choice. baselayout even supports
> other init systems when requested.
Surely you would provide choice by providing different baselayout
packages; one tailored for embedded systems that only have busybox, one
for general purpose use, etc. That's what the virtual is for, isn't it?
> 2) Speed.
> Bash is one of the slowest shells around for looping.
> However, it also requires less forking due to it's nice built-ins.
> This does of course only work with bash and not other shells.
Restricting everything to 'sh' I think is more likely to slow things
down than anything else. Apart from the forking issue that you
mention, builtins are different - '[' for example is about 30% slower
than '[[' in bash (which is what's implementing sh on Gentoo Linux). I
wonder how much time would be saved on Gentoo Linux by replacing [ with
[[ throughout the init scripts; maybe a percentage point?
If there really is a big speed penalty from using bash on BSD compared
to the native shell, wouldn't it be better to supply a Gentoo/FreeBSD
baselayout? They don't have to be completely independent; smart use of
the vcs would allow you to share scripts between baselayout branches,
with specific variants where it makes a difference.
> 3) What's the cost of *not* changing away from bash?
> I would say that bash is the best shell around in terms of features
> and ease of use, however that is not without cost. That cost is new
> bash versions consistently breaking baselayout, ebuilds and configure
> files.
w.r.t new bash versions, we should certainly be conservative in marking
new versions stable. It's worth noting the breakage isn't always
100% the fault of bash. The recent problem with '=~' and quoting for
example is down to glibc behaving differently to everyone else's libc
when it comes to accepting quoted characters for the regex interfaces
(a point where the POSIX standard is open to interpretation).
> 4) Size.
> Because bash has all these nice features it's large, hence unsuitable
> for low memory or low disk space environments.
But you only get one bash text image in memory at any one time (~825k).
So space isn't a real issue, except on small-memory systems.
> 5) I'm *just* talking about config files here.
> If users want to run bash, that's fine and I won't stop them. They can
> also use bash in their init script if they so wish as I plan to
> support something like so
>
> depend() {
>shell bash
> }
Making that sort of requirement explicit is a good idea. I wouldn't use
'depend()', as in init scripts it's quite cleanly only to do with the
order of services. You could make it an option to runscript:
#!/bin/runscript --shell=/bin/bash
or something along those lines - the shebang is clearly all about how
the script is executed, and the shell used falls nicely into that.
> And voila, problem solved. Of course, that's just an idea I just had.
> However, I also think that baselayout provided services should not
> require bash for the above reasons, hence the need for a new config.
I think the argument for conf.d files is better than that for init.d
scripts; you could have multiple baselayout setups that share conf.d
file formats.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 19:09:26 + Roy Marples <[EMAIL PROTECTED]> wrote: > The stuff that handles our networking maybe written in A.N. > Other-Language (Mrs.), but keeping /etc/conf.d/net readable by a shell > script does have advantages. You need to define what shell (or subset) you want to parse it. 'sh' itself varies from platform to platform. The one we have is a softlink to bash so doesn't make any difference for Gentoo Linux except for limiting what can be written. I just tried variable redirection for example (which can be used to implement pseudo-arrays without using eval) - I was surprised it works in sh here - dunno if it works in BSD sh (doesn't on busybox). What you have on FreeBSD may be different from what's on Solaris. Perhaps busybox sh might be a practical set to choose, for basic posix compliance. You could simply do something like: ifconfig_eth0="\ 10.1.1.1 netmask 255.255.255.0;\ 10.1.1.2 netmask 255.255.255.0" which means standard shell interpretation doesn't lose information, even if it's actually normally parsed by something else (chose ';' as a separator since ':' is used in ipv6 strings). It seems to me that the problem you're trying to solve, is the implementation of baselayout on restricted systems. Reducing all init.d/conf.d and so on to a common denominator for everyone isn't necessarily the best way forward. A different approach could be to provide more than one baselayout; one for large systems, where expecting to have bash available isn't such a big deal, and one for limited systems, restricted to busybox-standard sh. Actually I kinda assumed that's what baselayout-lite was all about... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Hardened USE flag
On Tue, 06 Feb 2007 00:15:25 -0400 Luis Francisco Araujo <[EMAIL PROTECTED]> wrote: > Hello World! > > I want to ask for suggestions and opinions for the best way to handle > this bug: > > http://bugs.gentoo.org/show_bug.cgi?id=158434 [textrels in smalltalk shared librart libgst.so] > I am usually very hesitant to add new use flags to the tree (unless > they are *really* necessary or imply a great advantage.) ; though i > am not sure here if anybody else would consider this a good > recommendation for handling textrels. In general, we would urge maintainers to default to no-textrels for shared libraries; normally the performance impact is negligible (often the performance is better, overall). It would be worth obtaining some real statistics before deciding. Note that textrels in shared libraries are pretty much an x86-only thing. amd64 in particular does not tolerate textrels in shared libraries (PIC is cheaper on amd64). > I was thinking more of a simple 'use hardened && myconf=" .. "' > specific line for this ebuild; but it's probably a good idea offering > to more developers the easy choice of this feature through a USE flag? I think 'use pic' would be more appropriate, because we're talking about whether we want position-independent code or not (but I defer to solar in these things). > If it looks enough useful for many people; then i think we can > proceed to implement it; if it will only be used by this ebuild; then > i am already against it ;-) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for February
On Sat, 03 Feb 2007 14:04:49 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > Kevin F. Quinn wrote: > >> It would but having some kind of deadline after which you are for > >> example free to take over the package if you want to would be nice. > > > > That's going too far; there's certainly no need to take over a > > package just to get a fix in. If you want to take over a package, > > asking the current maintainer has to be the first step, not to > > quietly wait for a timeout then just grab it. Similarly asking the > > current maintainer if they mind you putting a fix in. > > That's of course a given. I think the question here relates to > non-responsive maintainers or herds. Well, this thread didn't start with MIA devs (which is what you're talking about), it started with devs being too slow to take action. I wouldn't have a standard timeout (far too regulatory) - just apply common sense and do what needs to be done. > I have been in the situation > many many times with gcc-porting where I file a bug with a simple > patch (say removing extra qualification) to get a package to build > with GCC 4.1, and get no response for months from the maintainer > despite multiple pings. In that case, i'll apply the fix myself. I > always try to wait a month or more before going ahead and always ping > at least once. So far i've not received any major complaints, but > i'm just waiting for the day someone will get territorial about their > packages and decide rip me a new one. It'd be nice to have some kind > of asshole insurance. Well, my experience so far has been that provided you fix stuff decently (both technically and politically ;) ), people don't mind Maintainers can always tweak later if they prefer a different solution. If things get antsy, there's always devrel to mediate. One obvious point, is to check a dev's away status if they're not responding, before diving in. > This also affects things like treecleaners. How long does a herd team > or maintainer have to be unresponsive to warrant the package falling > into maintainer-needed? Right now the most common way we find these > packages is when Jakub gets annoyed enough with the accumulating bugs > and lack of response to CC us. ;P > > I personally think that for bug fixes a month is a long enough wait to > allow someone to respond. Keep in mind that's to respond, not to fix > the bug. A simple "yep, i'll get to this later" is enough. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Maintainer Timeout
On Fri, 2 Feb 2007 10:19:21 -0600 Grant Goodyear <[EMAIL PROTECTED]> wrote: > [lots of good stuff] I was going to respond to Timothy's proposal in much the same way - but Grant has said everything much better than I would have done! +lots Grant :) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for February
On Thu, 01 Feb 2007 22:19:57 +0200 Petteri Räty <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Thu, 01 Feb 2007 20:36:29 +0200 Petteri Räty > > <[EMAIL PROTECTED]> wrote: > > | I would like the council to discuss if we should have a policy on > > how | long to wait for a developer to respond to a non critical bug > > before | you can fix it yourself. > > > > Wouldn't that depend highly upon the bug? > > > > It would but having some kind of deadline after which you are for > example free to take over the package if you want to would be nice. That's going too far; there's certainly no need to take over a package just to get a fix in. If you want to take over a package, asking the current maintainer has to be the first step, not to quietly wait for a timeout then just grab it. Similarly asking the current maintainer if they mind you putting a fix in. If that approach doesn't succeed, it should then be put in the hands of devrel to arbitrate. I don't see that anything more is needed. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
On Tue, 30 Jan 2007 06:27:49 +
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> [ Background: tr1 is a set of extensions to the C++ Standard Library
> giving various useful things like hash tables and smart pointers.
> There are partial implementations included in g++-4.1 and boost and
> full implementations available from Dinkumware. It is likely that a
> lot of C++ apps will start using it in the not too distant future. ]
>
> What is the best way to handle packages that require parts of tr1?
Dunno what's best, but I think I'd do something like:
inherit ... toolchain-funcs versionator ...
...
IUSE=... boost-tr1 ...
...
DEPEND= ... boost-tr1? ( dev-libs/boost ) ...
...
pkg_setup() {
use boost && return 0;
version_is_at_least "4.1" $(gcc-version) && return 0
elog "Without boost, this package needs >=gcc-4.1, for tr1 support."
elog "Either switch to gcc-4.1 or higher via gcc-config, or specify"
elog "the boost-tr1 USE flag."
die " needs USE=boost-tr1 or >=gcc-4.1, for tr1 support."
}
...
use.(local.)desc:
(:)boost-tr1 - Use boost library for tr1 support (otherwise needs gcc-4.1
or higher)
Profiles that don't support gcc-4.1 could add it to their use.defaults.
I'd also ensure the build process always uses the boost library if
USE=boost-tr1 is specified, and always uses gcc-4.1 library if
boost-tr1 is not specified (so that if you say USE=boost-tr1,
you get it even if the active compiler provides tr1). The idea
being to avoid dependencies on the host build system, where
that's reasonable.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Changing licenses/BSD
On Sat, 13 Jan 2007 20:44:24 +0200 Petteri Räty <[EMAIL PROTECTED]> wrote: > Anyone oppose the attached patch for making the BSD license more > readable? I just came across this way for writing it in one package > and think it would be easier to understand this way. Surely the best thing would be to make it identical to the template at opensource.org: http://www.opensource.org/licenses/bsd-license.php This means just removing the redundant '*'s from the continuation lines. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] deprecating /etc/make.profile
On Wed, 10 Jan 2007 22:30:32 -0800 Ned Ludd <[EMAIL PROTECTED]> wrote: > On Thu, 2007-01-11 at 17:37 +1300, Kent Fredric wrote: > > On 1/11/07, Marius Mauch <[EMAIL PROTECTED]> wrote: > > > > > And I assume there is a non-trivial number of custom scripts out > > > there using make.profile, but that's nothing we can do about. > > > > > > > You could give them all a grace period for which have to comply with > > the new standard by then end of it, and have ( during that grace > > period ) an automatic symlink generation based on that make.conf > > flag. > > > > And just to make sure, I doubt it would be too difficult to have an > > application that analyises packages as they install to check whether > > they reference make.profile or not, and flag a QA warning if they > > do. > > > > > > > And packages that don't switch to the standard by the end of the > > grace period I guess we'll see on a "last rites" bulletin ;) > > Or we/gentoo could just support it and stop breaking the end user. A simple expedient would be to have the package manager re-create the symlink according to the variable, whenever it is run. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Tue, 9 Jan 2007 23:23:55 + Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Tue, 09 Jan 2007 14:41:50 -0800 Zac Medico <[EMAIL PROTECTED]> > wrote: > | Bug #161045 [1] requests that portage support RESTRICT=sandbox. > | This is certainly a valid request but a user may wish to reject a > | package based on certain questionable values of RESTRICT. > > If a RESTRICT value is questionable, it shouldn't be supported or > used. > > Honestly, this strikes me as rather silly and rather dangerous. > RESTRICT is not something about which the end user should have to > know or care; it should be something entirely between ebuilds and the > package manager. And sandbox is not something that should be turned > off lightly; making it so easy will only encourage developers to take > the nasty way out rather than fixing simple bugs. I agree; it'd be useful to know exactly what is failing the sandbox and why, with the aim of fixing sandbox if it isn't quite up to the job. The only shortcoming I'm aware of in sandbox is bug #135745 (have fopen/open() fail normally if the file does not exist, rather than report a violation). Waiting on azarah to roll a new sandbox version, I think. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] autotools eclass - set default for WANT_AUTO*
On Sat, 6 Jan 2007 05:21:48 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Saturday 06 January 2007 05:10, Alon Bar-Lev wrote: > > Is there any reason why not setting "latest" as default for > > WANT_AUTO* variables? > > > > I believe that an ebuild should set these variables only if there is > > some exception. > > that seems like a not-too-shabby idea actually Not sure. Would we run the risk that working ebuilds would start to fail when newer autotools versions arrive? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] GPL-2 vs GPL-2+
On Thu, 4 Jan 2007 12:00:51 +0100 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > On Thursday 04 January 2007 11:42, Kevin F. Quinn wrote: > > On Wed, 3 Jan 2007 10:18:51 +0100 > > > > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > I know that I'm a bit late on this, but to me the "version 2 or > > > later" is a license by itself. Let's call it GPL-RENEW and let the > > > file have contents like: > > > "This package is licensed with the version x or later clause for > > > the GPL." > > > > This is effectively what Diego was proposing with the 'GPL-2+' name. > > Except that a GPL-RENEW tag would be transparent over newer GPL > releases too. Upstreams will likely release under gpl-3 and newer. My > solution would handle it transparently. So you're suggesting "GPL-2 GPL-RENEW" would mean "GPL-2 or later", and "GPL-3 GPL-RENEW" would mean "GPL-3 or later"? Ugh. That'd be a mess for portage to parse. A better way of doing what I think you're suggesting, would be to define (say) the suffix '+' to mean 'or later' (with defined semantics; perhaps such that 'later' means substring that matches regex '-[^-]+\+$' be lexicographically greater in the C locale). However that means adding such management to portage. I still think license groups in LICENSE would be the ideal solution (requires changes to portage), but the most practical solution for now is simply to create GPL-2+ as Diego suggested. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] GPL-2 vs GPL-2+
On Wed, 3 Jan 2007 10:18:51 +0100 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > I know that I'm a bit late on this, but to me the "version 2 or > later" is a license by itself. Let's call it GPL-RENEW and let the > file have contents like: > "This package is licensed with the version x or later clause for the > GPL." This is effectively what Diego was proposing with the 'GPL-2+' name. > The LICENSE would then be: > LICENSE="GPL-2 GPL-RENEW" > > The advantage being that the renew clause is version independent, we > don't lose information, don't have to mutilate licenses (by adding > text). If desired it could even be used as LICENSE="|| (GPL-2 GPL-3) > GPL-RENEW" This isn't necessary - by creating the 'GPL-2+' license name, the only thing that's not fully correct as things stand is that packages that can be accepted with GPL-2 or later won't be accepted if the user has just GPL-3 in ACCEPT_LICENSES. Over time this can be fixed, by replacing "GPL-2" with "GPL-2+" in the LICENSE variable for the relevant packages. The the meaning of each license name would be strictly: GPL-2 : Only licensed under GPL v2 GPL-3 : Only licensed under GPL v3 GPL-2+ : Licensed under GPL v2 or later Which gives everyone what they need; those wanting GPL-2 or later would have ACCEPT_LICENSES="GPL-2 GPL-3 GPL-2+". For me, the only other sane alternative would be to use license groups (assuming license groups can be specified in the LICENSE variable). I don't recall the status of license groups in portage. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] GPL-2 vs GPL-2+
On Sun, 24 Dec 2006 18:05:48 + Stephen Bennett <[EMAIL PROTECTED]> wrote: > On Fri, 22 Dec 2006 21:56:54 +0100 > "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: > > > GPL-2: > > Note: this license states that the software is licensed under GNU > > General Public License version 2, and you might not be able to > > consider it licensed under any later version. > > > > GPL-2+: > > Note: this license explicitly allows licensing under GNU General > > Public License version 2 or, at your option, any later version. > > > > Comments, ideas, proposals? > > From a purist point of view, I'd be inclined to go with this route. > Pragmatically though, given the number of packages that do have the > "or later" clause compared to the number that don't, it might be > simpler to split them into GPL-2 (implying "or later") and > GPL-2-only. That's just a possible naming quibble though -- the idea > I like. > > The suggestion to convert all GPL-2-or-later packages to || ( GPL-2 > GPL-3 ) won't scale -- what happens when GPL-2.1 or GPL-3.1 appear? > It's also an awful lot of work for something that is, when you get > down to it, wrong. I agree. Diego's proposal works fine in practice; the 'might not' in the description for GPL-2 makes it clear that we don't guarantee to have updated all existing ebuilds to use the GPL-2+ name where appropriate. Doing it on an opportunity basis should be fine, so I don't think we need to worry about doing GPL-2-only. Saying GPL-2 when GPL-3 is also acceptable isn't critical in the near term; it won't cause people to install stuff with a license they don't accept. It won't really be needed until someone wants to have GPL-3 stuff but no GPL-2-only stuff - I think it's reasonable to avoid supporting that for a while, at least. If we start now, with all new commits having GPL-2 changed to GPL-2+ if appropriate, after a while we can change the GPL-2 description to be GPL-2 only and let GPL-3-only people (there's always one) bug about packages that are still unchanged when they hit them. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Big change ideea
On Wed, 06 Dec 2006 23:44:26 +0200
Alexandru Mincu <[EMAIL PROTECTED]> wrote:
> http://www.gobolinux.org/
> They have an idea that Mac OS X implemented it when it first came out
> to be more user friendly.
> They are trying to remove the old UNIX file system scheme with the/bin
> /etc /usr /var, etc directories and are trying to implement a little
> more intuitive version of the file system hierarchy.
This is an idea that comes up quite often, especially with people who
come from the Microsoft or Mac world. As far as Gentoo is concerned,
it is quite a lot of work (although not particularly difficult) for very
little gain. The primary motivation for GoboLinux seems to be to make
it easy to find which files go with which applications. You already
have that information of course, in /var/db/pkg/.../CONTENTS.
Indeed, it would be trivial to do the GoboLinux thing but inverted -
leave everything where it currently is, and build a big tree of
symlinks from the places you want. That's a lot of symlinks, however...
One last thing - their 'readdir' kernel hack ("GoboHide") - that's
really nasty! Hacking the kernel interfaces to deliberately break
compatibility is lunacy.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Mon, 27 Nov 2006 10:53:43 -0500
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Monday 27 November 2006 10:48, Marius Mauch wrote:
> > Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > On Sunday 26 November 2006 18:38, Marius Mauch wrote:
> > > > Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > > > is there a way in the new GLEP to say "never bother me with
> > > > > any license bullcrap" ? i made sure the current
> > > > > check_license() function respected the idea of "*" so that i
> > > > > can put this in my make.conf: ACCEPT_LICENSES="*"
looks to me like check_license() will effectively ignore '*' in
ACCEPT_LICENSE:
...
local shopts=$-
local alic
set -o noglob #so that bash doesn't expand "*"
for alic in ${ACCEPT_LICENSE} ; do
if [[ ${alic} == ${l} ]]; then
set +o noglob; set -${shopts} #reset old shell opts
return 0
fi
done
...
It then falls through to interactively requesting confirmation.
> > > > Not directly, you'd need to define a local license group
> > > > including all licenses (could automate that with a postsync
> > > > hook I guess) and use that in ACCEPT_LICENSE.
> > >
> > > in other words, your only proposed solution is a hack ?
> >
> > If you want to word it that way: yes.
>
> so why arent we providing a real solution ?
As I understand it, they're providing a solution that goes as far as it
can without violating the licenses themselves. So you'll be able to
specify all the licenses that don't require explicit acceptance at
installation (@NOT_MUST_HAVE_READ, in the glep proposal), you just won't
be able to say '*' to include the licenses that require explicit
acceptance as well. Since some licenses always have to be excluded,
allowing "*" would be misleading because it wouldn't be allowed to
match all licenses. Some of the licenses that can't be wildcarded or
grouped are the games licenses from ID Software, for example.
From Chris Gianelloni, earlier in the thread:
> We don't want to support ACCEPT_LICENSE="*" including the interactive
> licenses, since that *would* be skipping the requirements on the
> license. This has been discussed on the bug report, already
(re. bug #152593)
I think the sort of license text this is trying to address is:
> "YOU ACKNOWLEDGE THAT YOU HAVE READ THIS AGREEMENT, YOU UNDERSTAND
> THIS AGREEMENT, AND UNDERSTAND THAT BY CONTINUING THE DOWNLOAD OR
> INSTALLATION OF THE SOFTWARE, BY LOADING OR RUNNING THE SOFTWARE,
> OR BY PLACING OR COPYING THE SOFTWARE ONTO YOUR COMPUTER HARD DRIVE
> OR RAM, YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS OF THIS
> AGREEMENT."
in particular the download & installation bits (loading, running being
user concerns, not sys-admin/portage concerns). IANAL so of course I
can't say whether the proposed rules are necessary and sufficient.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Versioning the tree
On Mon, 27 Nov 2006 13:02:17 + "Stuart Herbert" <[EMAIL PROTECTED]> wrote: > On 11/27/06, paul <[EMAIL PROTECTED]> wrote: > > You can't take workload out of the picture since it's the main issue > > here. Stable tree means backport fixes and I don't see this > > happening as it can't be automated: > > "Stable tree means backport fixes" is an assumption, not a > requirement. > > It's one reason why the word "stable" is a poor choice for any such > tree, just as it is a poor choice for the current Portage tree. > > I think the original poster hit the nail on the head. The real > barrier preventing a slower-moving tree is cultural. One method could be to snapshot all package versions at the time that Release Engineering make a release, building a package.mask file out of it masking out all packages of higher revisions (i.e. having '>CPVR' entry for every package in the tree in stable, and 'CPVR' if no versions are stable). Then, rather than back-port security fixes, this list would be updated with security-fixed version numbers, along with minimum required updates to dependent packages. The lists could be stored in the tree; for example as profiles/default-linux/x86/stable.mask. Obviously maintaining that list is some work; predominantly watching the announcements from the security team and fixing up dependencies, and masking out new packages (for what that's worth). It could be regenerated on some or all releases, or perhaps on a yearly basis. It would also mean that versions listed there cannot be removed from the tree (until they're bumped in the list). Some of that maintenance could be tool-assisted; in particular masking new packages and finding the minimum required bumps to support a package that was bumped for a security fix. People who want to use it could then just soft-link from /etc/portage/package.mask to that list. It's just a suggestion - I'm not prepared to do the work ;) However it might be a simple but effective method to help people maintain secure but relatively stable systems, without having to upgrade umpteen packages a week. -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] Announcement: New(ish) eclass pax-utils.eclass
Hi peeps. I added an eclass (a utility class, rather than a "real" eclass) to abstract PaX flag management from ebuilds into a central place where we (hardened project) can maintain the use of the tools which manipulate the PaX flags. These tools are still evolving, and we need to continue to support them as they do so. Abstracting their use into a simple interface allows us to do so without having to hack around in ebuilds all around the place. Although I committed it originally almost a year ago, it hasn't been used yet, so if there's anything fundamentally wrong with whole thing, now is the time say as it can be removed with impunity. I did consider adding the functions to eutils.eclass, but I prefer to have it separate. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Tue, 21 Nov 2006 14:03:08 -0500 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > On Tue, 2006-11-21 at 17:59 +0100, Kevin F. Quinn wrote: > > Am I correct in thinking that the ACCEPT_LICENSE behaviour will just > > affect how portage calculates whether something can be installed or > > not (much like the behaviour w.r.t. KEYWORDS)? In this is the case, > > interactivity doesn't have much to do with it. As Brian suggests, a > > RESTRICT=interactive seems to be the most appropriate way to allow > > the admin to prevent portage from trying to install packages that > > need interaction during the install (whether it's for inserting CDs, > > accepting licenses, or any other reason). It depends on what > > "ACCEPT_LICENSE" means to the package manager. I take it to mean > > that the package may be considered for inclusion during emerge - > > i.e. the sysadmin is happy for portage to attempt to install > > packages under those licenses onto the system - rather than that > > licenses are actually accepted by the admin or user. If that's > > correct, perhaps naming it "ACCEPTABLE_LICENSES" would be clearer. > > It is used to mask the package, correct. When a package is masked, it > gives the output of the license, or, if the license it too large (I > think Marius set it at 20K) informs the user to read the license file. > It also explains to the user that they will need to read and accept > the license. > > RESTRICT="interactive" should be restricted to only the contents of > the ebuild. ACCEPT_LICENSE="RTCW-ETEULA" emerge enemy-territory is > *not* interactive, That's what I've missed then. I didn't realise that setting ACCEPT_LICENSE would inhibit the interactive confirmation that the license has been read. It means that ACCEPT_LICENSE is a list of licenses that have been accepted (which is not what I thought it was). > whereas "emerge ut2004-data" always is. This is > exactly why we are trying to keep licensing separate from ebuild > interactivity. They are not the same thing, at all. > > ACCEPT_LICENSE needs to be used for backwards compatibility. It is > being used currently by many Gentoo users, myself included, for > licenses which I have accepted. ACCEPT_LICENSE is very much like > ACCEPT_KEYWORDS. We don't use ACCEPTABLE_KEYWORDS, do we? The suggestion to use ACCEPTABLE_LICENSE was to highlight the difference; i.e. that ACCEPT_LICENSE means matching licenses have actually been accepted, rather than ACCEPTABLE_LICENSE meaning licenses that the system owner allows users to accept. Since ACCEPT_LICENSE does affirm the license has been accepted, ACCEPTABLE_LICENSE would be wrong and that suggestion goes down the pan. In retrospect it's complete garbage. > > Some packages require each user to accept the license explicitly > > when it is run (e.g. Acrobat Reader), some require it to be accepted > > explicitly during install (Enemy Territory) - in neither case should > > portage be taking automatic responsibility for actually accepting > > the license. > > It isn't. The package manager will not be accepting anything. The > *system administrator* does the accepting... just like if I were to > "emerge enemy-territory" now. > > > On naming - please can we avoid calling any group "NOT-". > > Since the ACCEPT_LICENSE syntax allows -, it's much better > > to use affirmative names always; in this case for example > > INTERACTIVE-INSTALL-ACCEPTANCE instead of NON-MUST-HAVE-READ. One > > can define > > > > ACCEPTABLE_LICENSES="* [EMAIL PROTECTED]" > > > > easily enough. > > Except we don't want that. > > We don't want to support ACCEPT_LICENSE="*" including the interactive > licenses, since that *would* be skipping the requirements on the > license. This has been discussed on the bug report, already, but > unless we made "*" not really equal "*", then it won't work, as it > won't fill the requirement that the license is accepted. OK that's fine. I'd still like to see a positive rather than a negative name, but I admit I can't think of a good one to cover what NOT-MUST-HAVE-READ would cover. Following the discussion about "*" from the bug (#152593 for those who don't know), I can see why you'd rather not have a positive list of restricted licenses. The best name I can think of to replace "NOT-MUST-HAVE-READ", is "UNRESTRICTED". That clearly doesn't say anything about interactivity - it's just a list of all the licenses that have no restrictions on the operation of portage. > Now, I ask everyone to go read the bug before posting any more > comments, since most of this has been discussed quite a bit there, > and doesn't need to be rehashed. I didn't realise there was a bug (#152593) - I was responding to the posting of the GLEP and discussion I've seen here recently. I've read it now... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] amd64 and ia64 keywords
On Sat, 21 Oct 2006 13:36:04 -0400 Jonathan Smith <[EMAIL PROTECTED]> wrote: > ia64 is for itanium, which was > intel's horrid first attempt at a 64-bit successor to x86. I wouldn't call Itanium a successor to x86, any more than SPARC was (recall that early Sun boxes were x86). As you mentioned, it's a completely new architecture. All those years people have been bashing Intel for the limitations of x86 that have been retained for decades for compatibility reasons (limited register set, nasty CISC, ever-increasing instruction set) - they try to do the design-from-scratch thing and it just gets ignored. AMD jump in and do what Intel had always previously done - extend the existing architecture by bolting on extra stuff - and clean up in the marketplace (or at least, hit Intel hard). If you want to call any architecture horrid, I'd suggest x86, which from a programmer's perspective has evolved into a real mess. x86_64 alleviates some nastiness (register set is now workable, pc-relative addressing is possible), but adds some more of its own. Of all the processor architectures I've worked with, modern x86 is far and away the muckiest from the point of view of an embedded software engineer. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: per-package default USE flags
On Fri, 13 Oct 2006 13:53:27 +0200 Simon Stelling <[EMAIL PROTECTED]> wrote: > Paul de Vrieze wrote: > > I would go for the EAPI bump. Even then I think it would be smart > > to wait a short while for packages to use this as we ensure that > > the supporting portage version is stable. > > Err, EAPI was designed to assure that a supporting version is > actually used, no need to wait then. Although obviously nothing using such an EAPI version could go stable until a supporting version of portage goes stable on all relevant arches (I think of EAPI as an implicit BDEPEND on the package manager version). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 04 Oct 2006 15:09:06 +0200 Natanael Copa <[EMAIL PROTECTED]> wrote: > What you didn't need to be a gentoo dev to be a package maintainer? > Lets say anyone could be marked as maintainer in an ebuild. When > there is a bug, the package maintainer fixes the bug and submits an > updated ebuild/patch whatever. This person has no commit access. > > Then a "committer", a gentoo-dev (someone with little more > experience), just take a quick look at it and commit it. This already happens on some packages (in particular where the upstream author is happy to maintain the Gentoo ebuild). One very important thing is for the Gentoo "proxy" dev to be listed in metadata.xml (as well as the non-Gentoo maintainer). The Gentoo dev takes formal responsibility for any commits. The trick is to find a Gentoo dev who is prepared to proxy for you; that involves a trust relationship between the dev and the maintainer. The amount of work the dev has to do depends on how well the maintainer follows the Gentoo ebuild rules. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 11:39:07 -0400 "Thomas Cort" <[EMAIL PROTECTED]> wrote: > On 10/4/06, Kevin F. Quinn <[EMAIL PROTECTED]> wrote: > > On Wed, 4 Oct 2006 09:21:08 -0400 > > "Thomas Cort" <[EMAIL PROTECTED]> wrote: > > > > > > The "minority" arches like mips, sparc etc seem to get along > > > > quite happily. > > > > > > Not the "minority" arches like m68k, s390, alpha, ... > > > > I haven't seen any significant numbers of complaints. What exactly > > about those arches do you think is a problem? > > The speed at which bugs are resolved is the problem. Keywording/stable > bugs can sit for months and sometimes over a year without being > touched. So? Who is complaining? Open stabilisation bugs are a concern for the relevant arches, not for everyone. Once an arch has actioned a stabilisation bug, they remove themselves from CC, after which they don't care. > Some people think the amount of time some arches lag behind > is acceptable, I don't. The primary reason why arches lag is that we > don't have enough people doing the testing and keywording. > > > You should only raise expectations when you know you can follow > > through, not the other way around. Raising expectations before > > being able to follow through leads to disappointment, which is bad. > > I think that if we implement my suggestions (drastically reducing the > workload), we will be able to meet those expectations. All that will happen if you ditch the minority arches, is that the devs involved will take their work into overlay or possibly leave Gentoo altogether. It won't improve anything for other arches. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 11:44:07 -0400 "Thomas Cort" <[EMAIL PROTECTED]> wrote: > On 10/4/06, Kevin F. Quinn <[EMAIL PROTECTED]> wrote: > > On Wed, 04 Oct 2006 09:41:45 -0400 > > Alec Warner <[EMAIL PROTECTED]> wrote: > > > My view is that while they're being actively supported, there's no > > reason to remove them. Granted their mostly SpanKY's babies, but so > > what? > > My view is that currently we cannot offer the same level of support > for the minority arches as the majority arches because we don't have > enough people involved. We don't need to. Gentoo isn't just one single thing, and I see no reason to require that all projects and arches offer the same level of support. Each project and arch can make their own determination about what level of support they can and will offer. Embedded users, for example, are generally more technically-oriented to start with so need far less support than, say, non-technical x86 users. > I think that spreading the developers too thin > leads to conflict and burnout. Look at NetBSD and debian. They are > trying to be everything for everyone. How is that working for them, > how is it working for us? I think we should be more focused, but > that's just my opinion. Minority arches don't affect devs who aren't interested in them, so they have no impact on how spread out the developers are. Effectively you're saying that those involved in the minority arches should stop messing about with that and commit all their Gentoo time to mainline activities, which is obviously not sensible. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 11:44:07 -0400 "Thomas Cort" <[EMAIL PROTECTED]> wrote: > On 10/4/06, Kevin F. Quinn <[EMAIL PROTECTED]> wrote: > > On Wed, 04 Oct 2006 09:41:45 -0400 > > Alec Warner <[EMAIL PROTECTED]> wrote: > > > My view is that while they're being actively supported, there's no > > reason to remove them. Granted their mostly SpanKY's babies, but so > > what? > > My view is that currently we cannot offer the same level of support > for the minority arches as the majority arches because we don't have > enough people involved. We don't need to. Gentoo isn't just one single thing, and I see no reason to require that all projects and arches offer the same level of support. Each project and arch can make their own determination about what level of support they can and will offer. Embedded users, for example, are generally more technically-oriented to start with so need far less support than, say, non-technical x86 users. > I think that spreading the developers too thin > leads to conflict and burnout. Look at NetBSD and debian. They are > trying to be everything for everyone. How is that working for them, > how is it working for us? I think we should be more focused, but > that's just my opinion. Minority arches don't affect devs who aren't interested in them, so they have no impact on how spread out the developers are. Effectively you're saying that those involved in the minority arches should stop messing about with that and commit all their Gentoo time to mainline activities, which is obviously not sensible. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 04 Oct 2006 09:41:45 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: > Thomas Cort wrote: > > - Drop all arches and Gentoo/Alt projects except Linux on amd64, > > ppc32/64, sparc, and x86 > > I can perhaps see some of this stuff dying. Like all of SPanKY's > weird ass arches; I have no idea why they are in the tree. Cool > yes...Useful? debatable. My view is that while they're being actively supported, there's no reason to remove them. Granted their mostly SpanKY's babies, but so what? If you're not using those arches, you don't need to get involved. Incidentally you only have to lurk in #gentoo-embedded to see there are users trying Gentoo on all sorts of bizarre boxes; it's something that is much less painful and much more flexible with Gentoo than with any other distribution. I don't like the idea that only stuff used by large groups should be in the tree. I think the criteria should hinge primarily on whether stuff has an active Gentoo maintainer. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 09:21:08 -0400 "Thomas Cort" <[EMAIL PROTECTED]> wrote: > > The "minority" arches like mips, sparc etc seem to get along quite > > happily. > > Not the "minority" arches like m68k, s390, alpha, ... I haven't seen any significant numbers of complaints. What exactly about those arches do you think is a problem? > > > - Reduce the number of projects by eliminating the dead, weak, > > > understaffed, and unnecessary projects > > > > Weak: Be more specific. What are the "weak" projects, and why? > > Projects that don't achieve anything, have no goals, and don't show > any promise of doing anything productive. By "specific" I meant which projects exactly - i.e name some, and explain how the weakness you perceive is a problem. > > Understaffed: this issue manifests itself as a project being slow to > > update. However the only place this is an issue is for security > > issue management. Another solution to under-staffing is to reduce > > expectations. > > The more we reduce expectations, the more it will hurt users. We > should be raising expectations and following through. You should only raise expectations when you know you can follow through, not the other way around. Raising expectations before being able to follow through leads to disappointment, which is bad. > > Unnecessary: again, be more specific. What are the "unnecessary" > > projects, and why? > > Projects that aren't needed to further Gentoo and are not helpful to > users or developers. Again, by "specific" I meant which projects, by name, do you think meet those criteria. Explain why you consider those projects to be a hindrance to users or developers. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 14:18:54 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Wed, 4 Oct 2006 15:02:17 +0200 "Kevin F. Quinn" > <[EMAIL PROTECTED]> wrote: > | Yuck. Devs should be free to add whatever packages they like, > | provided they're willing to maintain them. > > There're already some restrictions: > > http://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs-in-the-tree? > > Perhaps they should be enforced... Yes, I have no objections to there being rules about what can and cannot be added to the tree, and the ones in your devmanual are clearly sensible and should be applied. I do however object to the suggestion that adding a package to the tree be subject to formal approval (by whom, for a start...). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 4 Oct 2006 07:00:14 -0400 Thomas Cort <[EMAIL PROTECTED]> wrote: > There have been a number of developers leaving Gentoo in the past 6 > months as well as a number of news stories on DistroWatch, Slashdot, > LWN, and others about Gentoo's internal problems. Regarding the news stories - they're just ill-informed sensationalist press (nothing new there, then). If a news site feels the need to report when dev X leaves in a tantrum, it says more about the amount and quality of news they have to report than it does about us. > No one seems to have > pin pointed the problem, but it seems glaringly obvious to me. We > simply don't have enough developers to support the many projects that > we have. One problem is that some expect all work to be done immediately. The only stuff that has to be done asap is security fixes; everything else can be done when it's good and ready. > Here are my ideas for fixing this problem: > > - Cut the number of packages in half (put the removed ebuilds in > community run overlays) We already have TreeCleaners who have a managed approach to removing unmaintained&broken ebuilds. What cuts are you proposing in addition to that, and why? > - Formal approval process (or at least strict criteria) for adding > new packages Yuck. Devs should be free to add whatever packages they like, provided they're willing to maintain them. I'd support stronger QA of ebuilds. Of course that's down to finding enough clue-ful people willing to join the QA team and do the reviews. > - Make every dev a member of at least 1 arch team Why? The only people on arch teams should be those actually doing arch work. Many devs don't get involved in stable keywording, and there's no reason they should be - why should they be on an arch team? > - Double the number of developers with aggressive recruiting Assuming we need more devs, the issues are (1) supply of good people and (2) resource in recruiters. (1) is the crux of the problem. No amount of wand waving is going to change that. > - No competing projects Absolutely disagree. At worst, if two projects cannot physically co-exist in the same tree then they should go into overlay, but we've yet to see that. > - New projects must have 5 devs, a formal plan, and be approved by the > council To what end? Just to make new projects harder to form? There is rather a lot of argument about nascent projects - I'd rather see such discussion happen when projects reach the stage that they have something solid to add. Support for dev and project overlays helps a lot, as it provides a workspace for progressing projects without causing daily disruption to the tree. > - Devs can only belong to 5 projects at most Why? That achieves nothing. The number of projects a dev belongs to is down to the dev and the projects involved. > - Drop all arches and Gentoo/Alt projects except Linux on amd64, > ppc32/64, sparc, and x86 You are joking, aren't you? If you're worried about keywording, the critical arches are x86, ppc, amd64 - which is where you see most comments about slowness of stabilisation. The "minority" arches like mips, sparc etc seem to get along quite happily. > - Reduce the number of projects by eliminating the dead, weak, > understaffed, and unnecessary projects Dead: if you mean projects that no-one uses anymore and are no longer developed, then fine, they're candidates for deletion. Weak: Be more specific. What are the "weak" projects, and why? Understaffed: this issue manifests itself as a project being slow to update. However the only place this is an issue is for security issue management. Another solution to under-staffing is to reduce expectations. Unnecessary: again, be more specific. What are the "unnecessary" projects, and why? > - Project status reports once a month for every project We've discussed this before. Project status reports make sense if they're going to be read. Personally I think each project should organise its own status reporting schedule. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited
On Wed, 20 Sep 2006 10:05:00 -0400 Michael Cummings <[EMAIL PROTECTED]> wrote: > On Wed, 2006-09-20 at 13:36 +0200, Simon Stelling wrote: > > > Every license which a package in the portage tree depends on gets a > > package in the ``txt-licenses/`` category. Its ebuild must install > > the license text to ``/usr/shared/licenses/``. The initial version > > shall be 1 if there is no version specified. > > This doesn't make sense to me. I have a copy of every license used in > the portage tree already in /usr/portage/licenses - why dup that > again? Plus the copies in /usr/share/doc. > We already have an existing LICENSE keywording in the ebuilds, > why not just focus on patching portage to allow a make.conf variable > for allowed licenses and block based on that? Sounds good enough to me. Perhaps two variables; ALLOW_LICENSES and DENY_LICENSES (with wildcard support). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
On Thu, 07 Sep 2006 16:42:11 +0200 Simon Stelling <[EMAIL PROTECTED]> wrote: > Carsten Lohrke wrote: > > One question remains: Is it needed/correct that Portage doesn't > > take blockers for architecture breakages into account? Such a > > line/prefix is easily changed and when someone - whatever the bad > > reason is - uses cvs commit, a real tree breakage is the cause. > > The behaviour is correct. The depstring in question was > "! Reason for this could e.g. be file collisions that got fixed in > hunspell-1.0. > > If the depstring was "! (same as ">=app-text/hunspell-1.0", just retarded) repoman would > complain loudly. 1,$ s/hunspell/hspell/g :) To follow up in the use of a blocker - obviously blocking something like kdelibs, a core part of a major package suite, against a utility like hspell is less than ideal (to put it politely). This was not the case before - kdelibs and hspell could happily be installed on the same system, just kdelibs wouldn't make use of hspell. Adding the blocker unnecessarily restricts the system, and was the wrong thing to do. One point that illustrates this clearly, is that if kdelibs is blocked by hspell, a corollary is that hspell should block kdelibs. However since hspell wasn't blocking kdelibs, you would fail to install kdelibs until hspell was unmerged. Unmerging hspell would allow kdelibs to merge, then you could happily install hspell again and end up with a confused dep tree. Also, to my understanding, having configure automagically build support for hspell if it's available on the system is not the way we're supposed to handle such dependencies. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Bugzilla access for contributors
On Mon, 04 Sep 2006 00:59:44 +0200 Stefan Schweizer <[EMAIL PROTECTED]> wrote: > An example for this has been obvious since the overlays project was > established. Bugs for overlays should be filed on bugs.gentoo.org and > will most likely get assigned to the developer/herd. This does allow > a contributor to fix the bug but only to mark it as fixed in bugzilla > when he is also an arch tester. Is it not enough just to re-assign such bugs to the contributor? The reason devs can resolve bugs is that they have write access to the tree and thus can incorporate a fix. If something is in an overlay, presumably the contributor has write access to that overlay, and should be the assignee of the bug. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers
On Sun, 03 Sep 2006 17:54:33 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > Kevin F. Quinn wrote: > > If you don't care whether a package is stable or not, just let the > > arch team go ahead and do what they need to do to stabilise when > > they wish to. The role of package maintainer has nothing to do with > > stabilisation, which is the preserve of the arch teams. > > Um, sure it does. We're not going to stabilize something without > attempting to contact the maintainer first. If it's > maintainer-needed we'll just go ahead though. Yeah; I meant that ebuild maintainers don't do stabilisation, the arch teams do, and that if the ebuild maintainer isn't interested in whether the package is stable or not, they can leave it for the arch team (and ATs) to do. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo 2006.1
On Sun, 3 Sep 2006 17:44:32 +0100 "Stuart Herbert" <[EMAIL PROTECTED]> wrote: > On 9/3/06, Alec Warner <[EMAIL PROTECTED]> wrote: > > Because the thought that stable is always "stable" or that because > > we released things are "stable" is incorrect ;) > > You're not supposed to break the stable tree; that surely must include > stabilising a compiler (which is the _default_ for new installs) that > can't compile all the packages marked stable for your arch. That's just not feasible, as we've identified before. You can't expect sys-devel/gcc to take responsibility for every package in the tree in all configurations. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
On Sun, 03 Sep 2006 16:22:37 +0200 Stefan Schweizer <[EMAIL PROTECTED]> wrote: > Paul de Vrieze wrote: > > For this stuff, add a comment to the metadata.xml file. Don't do it > > in this less than obvious way. > > arch teams for example will still contact me then for stabilizing, I > do not want that. jeeves and herdstat do not support comments and the > metadata is not often read directly. If you don't care whether a package is stable or not, just let the arch team go ahead and do what they need to do to stabilise when they wish to. The role of package maintainer has nothing to do with stabilisation, which is the preserve of the arch teams. > > The maintainer must still be someone with a > > gentoo email. > > is that written down somewhere? I was under the impression that it is > allowed and have seen it used for example > in /usr/portage/www-client/links/metadata.xml You'll notice that there are two maintainer blocks in there, one for the non-gentoo "third-party" maintainer, and one for the Gentoo dev who proxies - the "official Gentoo" maintainer. There are several packages like this. What I'm conerned about is packages that have no Gentoo maintainer, something that should obviously never happen for packages in the official tree. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers
On Sun, 03 Sep 2006 13:57:10 +0200 Stefan Schweizer <[EMAIL PROTECTED]> wrote: > Kevin F. Quinn wrote: > > I don't think it's a good idea for devs to be putting stuff into the > > tree without taking responsibility for it. > sure I can put myself in there but it will help no one because I > cannot test the thing. Then you should not have committed it - as a dev it is your responsibility to test any ebuilds your commit. There's nothing stopping you doing the normal checks on the ebuild, even if you can't read Hebrew. For example you should verify whether the '-j1' is really necessary on emake. > Furthermore I am actually part of > maintainer-needed and commit fixes there. I am also on the > maintainer-needed email alias. For a start, "maintainer-needed" is just a mail alias, it is not a herd and never can be, by definition. See http://www.gentoo.org/proj/en/metastructure/herds/herds.xml. The point of a herd is to provide a contact for maintenance of the member packages - and maintainer-needed by definition does not do maintenance. > Also maintainer-needed makes obvious to everyone that they do not > have to ask me to fix sth. or take over the package -> less > communication overhead. You can put notes into metadata.xml - see other instances for examples; the easiest way is to have two maintainer entries, and in the description field describe the maintenance arrangement. Putting "maintainer-needed" as the herd just means the package is essentially unmaintained, and is a candidate for removal. We should not be putting stuff into the official tree if no dev has taken responsibility for it. > > I would expect that either > > the herd is set appropriately (which means either the committer be a > > member of the herd, or the herd explicitly agree to be proxy), > which is the case here. See above - maintainer-needed does not satisfy the requirements of the herd entry. > > or the > > committer be listed as a maintainer email address along with > > whoever is being proxied. > the committer in this case has no interest in maintaining the thing. Even more reason the package should acquire a dev to maintain it, or be removed from the tree. > And for proxying it does not matter who is proxying. Proxying is more than just "doing whatever the non-dev says". By committing to the tree, you take full responsibility for those commits. > > Further I believe bugs against such packages should be > > assigned to the @gentoo.org address (proxy maintainer if there is > > one, herd otherwise), and CC'ed to the proxied maintainer address. > > this does not allow the actual maintainer to close the bug and causes > a lot of bugspam for a person who does not care about it and should > be only contacted in the end to commit fixes/patches/bumps. Whoever does the commit takes formal responsibility for those commits. Therefore they should take note of bug activity relating to those commits. If they don't care about that then they should not be acting as proxy in that case. Surely this is what the Sunrise overlay was for; user-supplied ebuilds that don't have a a Gentoo dev to take responsibility for maintenance. -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] packages going into the tree with non-gentoo maintainers
triggered by bug #77751: hspell lists a non-gentoo.org address for the maintainer email, the herd as maintainer-needed, and no other addresses. Is this sort of thing now ok? I don't think it's a good idea for devs to be putting stuff into the tree without taking responsibility for it. I would expect that either the herd is set appropriately (which means either the committer be a member of the herd, or the herd explicitly agree to be proxy), or the committer be listed as a maintainer email address along with whoever is being proxied. Further I believe bugs against such packages should be assigned to the @gentoo.org address (proxy maintainer if there is one, herd otherwise), and CC'ed to the proxied maintainer address. Packages affected: app-arch/rzip app-portage/getdelta app-text/hspell net-misc/vnc sys-fs/dmraidcvs All of the above list a non-gentoo.org address as mainainer, but do not have either a proper herd, or a specific gentoo.org dev listed as maintainer. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo 2006.1
On Sat, 02 Sep 2006 12:34:38 +0200 Edgar Hucek <[EMAIL PROTECTED]> wrote: > Apeal on extended testing : > > Developer, please test things more carefull before you > release it. There are over 10,000 packages in the tree (11247 to be exact); each of which can be built many ways with USE flags. It is simply not feasible to test all of the packages in all possible combinations in all possible USE configurations for all architectures. The number of combinations is literally astronomical. So, we test what we can, but rely on users to raise a bug in bugzilla when a combination they try, that we haven't, fails. > I already found things which does not compile out of > the box. So raise bugs on bugs.gentoo.org. Make sure you include data about the configuration of your system (i.e. the output of 'emerge --info'). > 1.) Use wacom does not compile out of the box. You > have to unmask linuxwacom. Raise a bug, if one hasn't already been raised. > 2.) Enable the use flage accessibility gnome cant be > merged. It fails on compile the speech-tools. Raise a bug, if one hasn't already been raised. > It seams that USE flags are not realy tested or how > can it happen that there are already know bugs in the > stable distro ? > > http://bugs.gentoo.org/show_bug.cgi?id=116030 > Festival and the speech-tools are well know not to > compile with gcc >=4. Er, because the bug is not yet fixed. If we were to hold up the release of everything until all bugs are fixed, we'd never release anything. You have the power to sort out this problem on your own system. Just build the relevant packages with gcc-3.4.6 instead of gcc-4.1.1 (see gcc-config for switching your selected compiler). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Sets
On Tue, 29 Aug 2006 07:57:43 -0400
Alec Warner <[EMAIL PROTECTED]> wrote:
> So I have implemented merging of sets (more or less) in a local
> portage branch.
Could you elaborate how the implementation of sets would differ from:
# emerge $(cat /var/lib/portage/myset)
where /var/lib/portage/myset is a file containing a list of atoms?
That would help in thinking what the behaviour could be.
I'm thinking that perhaps you do everything up to but not including
qmerge for all packages then do the qmerge phase for the set in one go,
provided they all got to install ok. It might be useful to try to move
all actions that might fail during qmerge to the end of the install
phase (I'm thinking things like collision-detection, qa checks), so
that the only reason qmerge on the set would fail is lack of disk space.
Obviously that's simplifying somewhat - if there are build-time DEPEND
relationships between elements of the set, the set has to be broken
down into sub-sets that don't have such internal dependencies. However
I can't think of much else you would do with sets that the $(cat
) approach doesn't already supply. Alternatively you could
require that sets must not have such internal dependencies.
> However there are some use cases for which the
> appopriate action is ambiguous.
>
> Use Case #1:
> Set1 = { postfix, gentoolkit, lsof, bind-utils, vixie-cron }
>
> A set of standard tools to be on a machine. Assume a new install (ie
> none of the packages in Set1 are installed). Is it an error if one of
> the packages in the set is masked or unavailable? In this case I
> would say yes; if you instead just skip the masked package (say
> postfix in this case because it's convenient ) vixie-cron will pull
> ssmtp instead of postfix.
>
> Of course this will also occur if postfix is after vixie-cron in the
> set; but for our purposes we will assume the administrator put them in
> this order such that postfix will get pulled in.
>
> One could also say that the user should have used emerge -pv set1 and
> noticed that ssmtp is being pulled in instead of postfix.
>
> Use Case #2:
>
> Set1 = cat /var/lib/portage/world (the world set)
>
> Assume the world file has 100 packages in it, two which are masked,
> and three of which there are no ebuilds in the tree for. If missing
> packages cause an error (which in use case 1 they should imho) then
> the user cannot update world without unmasking things properly. The
> packages for which ebuilds are missing in the tree is in fact a
> portage bug(I think), and will probably need to be fixed.
For the initial merge case then an error before anything is merged is
good. For an upgrade merge, a warning would be more appropriate
(perhaps becoming an error with FEATURES=stricter or similar).
> Other use cases for sets would be appreciated, as far as behavior. It
> would probably be best to provide some sort of switch.
The most obvious use is to have a related group of packages that may
otherwise include a virtual, making the choice of that virtual explicit
(like your cron example above).
Other sets would be simply groups of packages that make functional
sense together, where perhaps one package might make little sense
without others in the set. For example:
sylpheed-kev = ( sylpheed-claws sylpheed-claws-mailmbox \
sylpheed-claws-smime sylpheed-claws-rssyl sylpheed-claws-smime \
sylpheed-claws-vcalendar)
toolchain4 = ( \
~sys-devel/gcc-4.1.1 \
~sys-devel/binutils-2.16.1 \
~sys-libs/glibc-2.4 )
Are you considering allowing sets to contain other sets? Then world
would contain the names of sets, not just CPs.
> Unmerging sets is also a fun one, I'm not sure if it's entirely
> appropriate yet.
Would it do anything more than:
# emerge -C $(cat /var/lib/portage/myset)
Perhaps it would unmerge any packages merged as dependencies of the
set that are no longer dependencies of anything else currently
installed - but I think that's better handled separately.
Ah; it occurs to me that unmerging a set should only unmerge elements
of the set that are not part of any other installed set (including
world). So behaviour is less like 'emerge $(cat )' and more like
emerge sets/ where /set/set-V.ebuild is like a meta-ebuild.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Democracy: No silver bullet
On Thu, 24 Aug 2006 09:50:04 +0100 "Stuart Herbert" <[EMAIL PROTECTED]> wrote: > We've had a global vision for where Gentoo is going from before I > joined - Gentoo is here to create a source-based distribution where > each package is as close to what $UPSTREAM intended it to be as > possible. We're not trying to take $UPSTREAM packages and innovate > with them - we're here to do a first class job of packaging them up. While that's generally the case, it's not always true; in particular the hardened project deliberately causes stuff to be built differently to the way upstream expect. This illustrates that there is more than one vision, and what's good about Gentoo is that we can support different visions without having to fork the whole of Gentoo. The increased use of overlays helps to scale this up. >... > We don't have a democracy. Gentoo is largely a workocracy (there must > be a better word for it ;), where the vast majority decisions are made > by the folks who actually do the work. Meritocracy, perhaps. >... > * Every staff member has to belong to a team. You join a team by > being voted onto the team by the other members of the team. They > don't vote you in, you can't join. > * If you're not part of any team, your rights and privileges as a > staff member are automatically terminated. There's no place to go to > appeal. > * You can be voted off the team at any time. The teams are > self-managing. I figured this is pretty much how it works at the moment, just without the formality. You don't just attach yourself to a team and start stomping over the work of that team - acceptability of what you do is by consent of the team. The lack of formality means that if the team doesn't explicitly object to something you propose (e.g. what you propose doesn't affect what the rest of the team do, or if it does they don't care), you can just go ahead. Your summary implies explicit consent from the team would be needed, which I don't think would be a good idea. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo-Status
On Mon, 21 Aug 2006 18:56:11 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: > [...] So below we have 3 large far-reaching projects. > > Gentoo Quality Assurance Team > Gentoo Infrastructure Team > Gentoo Portage Team > Gentoo Foundation > Gentoo Council > > All 5 of these projects are active it's growing ;) > [...] > I request that these teams present status reports bi-weekly (thats one > every two weeks). I'm not aware of the issue that sparked this, but if regular reports are a solution, I suggest that rather than mandating a bi-weekly report, each of the relevant projects should propose a reporting schedule that is appropriate to them. For example, the Council meets once a month, so a bi-weekly status update seems inappropriate (half the reports are likely to be empty, the other half a copy of the meeting minutes which we already get). Perhaps the Foundation would be happier with a regular three- or six-month update, with the occasional ad-hoc update as need arises. Whatever, the point is that each project knows best how often it ought to communicate stuff. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs
On Sat, 12 Aug 2006 13:08:50 +0200 Simon Stelling <[EMAIL PROTECTED]> wrote: > Being an amd64 dev, I want to basically add a 'me too!' here. I think > it's not necessary to add the --info output when all worked well, > though, if instead the output of -pv $PN was given. Except when there > was a failure reported before, because then we need it to compare the > two. Thing is, an AT who reports success before someone else reports a failure won't know whether that will happen, and may have moved on since the test was performed. So always reporting `emerge info` at the time of the report makes sense even for successful tests. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs
On Fri, 11 Aug 2006 16:46:33 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > I explained from the outset that this change pertains to stabilisation > bugs. If you are not an arch dev, then why are you taking the opposite > side in a discussion of stabilisation bugs which by their very nature > only pertain to arch devs? Well, first off you asked for comments; "RFC". If I have something to say, I'll say it, even if I'm not immediately affected. You don't have to agree, or even pay attention ;) That said, as I described in my previous email, my concern was that if it becomes policy to attach `emerge --info` instead of inline for stabilisation bugs, that policy might expand to all bugs which would have a negative impact for me. However if the rule is only for "pass" `emerge --info` data then I don't object. > > Another idea is for ATs to attach emerge info if the package passes > > for them, but in-line it if it fails. If the package fails on one > > arch for a given set of USE/FEATURES, other arches may well be > > interested to check if the failure also affects them. > > If it fails, the AT should open a separate bug and make the > stabilisation bug depend on it. Good point. > You said so yourself: > > "Stabilisation bugs shouldn't be doing problem resolution; if a bug is > found during stabilisation testing it should be raised as a normal bug > and set as a dependency of the stabilisation bug." > > I absolutely agree with this. I assume now that you agree with me that > debugging info, including `emerge info`, should *never* be inlined in, > or even attached to, stabilisation bugs. Yes. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Fri, 11 Aug 2006 13:40:23 +0200
Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> On Fri, 11 Aug 2006 12:52:30 +0200
> "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote:
>
> > In general it depends what you're doing. Personally I find inline
> > emerge --info quicker to process, as I tend to do that by scrolling
> > up and down a bug when trying to determine what triggers a bug.
> > However that's for "normal" bugs - I don't spend much time on
> > stabilisation bugs.
>
> "Personally" is meaningless in this context.
"Personally" is critical. Part of my point was that whatever way it's
done, it will be better for some and worse for others. In other words,
what is "better" is subjective. In order to decide to change how
things are currently done, you need to show that it is better for a
majority of the people affected.
> The inline `emerge info`
> is quicker to process for you, not for other-arch devs out there. For
> them the info is useless. Stabilisation bugs in this context are
> bugs CC'd to many arch aliases (see below for a possible solution).
>
> > > you have to wade through all the AT spam to find out what is being
> > > changed over time. It's best to have it in attachments, I think.
> > >
> > > Besides, you're wrong. ATs can add comments to attachments
> > > informing their arch devs of success or failure, and name the
> > > `emerge info` attachment properly so everybody knows what the
> > > attachment actually is (and when to ignore it).
> >
> > In what way am I wrong? I never said AT's can't add comments.
>
> ATs can inform you whether something works in the comment to an
> attachment, which, unlike the attachment, will end up in my mailbox. I
> have no problems with short comments like:
>
>
> --- Comment #5 from [EMAIL PROTECTED] 2006-08-01 02:47 PST ---
> Created an attachment (id=93193)
>--> (http://bugs.gentoo.org/attachment.cgi?id=1&action=view)
> emerge info
>
> Works Great!!!1omg
ok; that makes better sense.
> > Effectively what you're saying is transcribe the emerge info into
> > the attachment name and attachment comment - which effectively
> > makes it in-line again.
>
> No, I meant put the `emerge info` in the attachment, describe the
> attachment properly ("emerge info" would do) and comment on the
> attachment submission with a statement pertaining to the success or
> failure of the test run. This can all be achieved in a single submit
> and it doesn't burden arch devs and bugzilla with lengthy comments.
Doesn't make the slightest difference to the burden on bugzilla,
whether they're inline or attachments.
Whether it's a burden on arch devs or not, you'd have to poll.
If you do go this route, I suggest the attachment title be "PASS
(emerge info)" or "FAIL (emerge info)"; easier to parse the attachment
list. Also allows you to process email by just the subject header.
> > Rule 1 in problem reporting - report your exact configuration and
> > exactly what you see, in the first instance, do not attempt to
> > interpret until you have that data recorded.
>
> Could you consider having ATs report the exact configuration
> elsewhere? In normal bugs, encouraging users to post their emerge info
> is a good thing. In stabilisation bugs, with well-instructed ATs
> posting comments, there's no need to do all that.
Well, I do think the report of the configuration the AT had at the time
of the test should be held as close as possible to the place where it
has relevance. As far as this point is concerned, having it as an
attachment is fine. Having it posted on some website somewhere else as
others have suggested is a bad idea, I think.
> > Not sure I understand. Stabilisation bugs shouldn't be doing
> > problem resolution; if a bug is found during stabilisation testing
> > it should be raised as a normal bug and set as a dependency of the
> > stabilisation bug. If people are using stabilisation bugs for
> > development/bug fixing then they should stop doing so.
>
> N/A
>
> Stabilisation bugs should be short and simple. If the stabilisation
> target changes half way through (a revision bump perhaps, which
> happens quite often, or an extra dep, which happens quite often as
> well), arch devs need to be able to find that information quickly.
>
> > Well, it adds around 40 lines - I don't see that as a problem.
> > It's a good idea if the emerge info output is placed after whatever
> > comment is being made, so that if you don't care about it you can
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Fri, 11 Aug 2006 00:51:56 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > On Thu, 10 Aug 2006 23:58:46 +0200 > "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > > > The problem with attachments is that processing the report takes > > longer > > - you have to go to the web to read the attachment to find out what > > config worked (or failed, if that was the case). It's best to have > > it in-line, I think. > > The problem with inlining is that processing the info takes longer - In general it depends what you're doing. Personally I find inline emerge --info quicker to process, as I tend to do that by scrolling up and down a bug when trying to determine what triggers a bug. However that's for "normal" bugs - I don't spend much time on stabilisation bugs. > you have to wade through all the AT spam to find out what is being > changed over time. It's best to have it in attachments, I think. > > Besides, you're wrong. ATs can add comments to attachments informing > their arch devs of success or failure, and name the `emerge info` > attachment properly so everybody knows what the attachment actually is > (and when to ignore it). In what way am I wrong? I never said AT's can't add comments. Effectively what you're saying is transcribe the emerge info into the attachment name and attachment comment - which effectively makes it in-line again. Obviously only a tiny part of that can actually be put in the attachment name, and there's little point to putting stuff in the attachment comment unless it's highly redacted - how is the AT going to decide what information is significant? Rule 1 in problem reporting - report your exact configuration and exactly what you see, in the first instance, do not attempt to interpret until you have that data recorded. > > If you're not interested in the AT emerge --info data, why are you > > watching the stabilisation bug? > > Because as an arch dev not on an AT-equipped arch, I still need to > find the interesting-not-your-arch-info between all the > your-arch-cruft. Not sure I understand. Stabilisation bugs shouldn't be doing problem resolution; if a bug is found during stabilisation testing it should be raised as a normal bug and set as a dependency of the stabilisation bug. If people are using stabilisation bugs for development/bug fixing then they should stop doing so. > All these `emerge info` comments are completely irrelevant to every > arch dev for 14-ish out of 15-ish arches. Arch devs blessed with ATs' > preparations have their work cut out for them, it seems, having all > that info in their mailbox, while non-AT arches have to fork through > all the spam, both in their mailboxes and on bugs.g.o, to get to the > good bits (ouch, sparc beat us again, must stabilise before mips!). > > Inlining emerge info in comments bloats the e-mail message to roughly > 2.5 times the normal size. Well, it adds around 40 lines - I don't see that as a problem. It's a good idea if the emerge info output is placed after whatever comment is being made, so that if you don't care about it you can just skip to the next message. > I could have spoken out to get AT comments > banned altogether or to urge arches with AT teams to find a proper > technical solution to communicate outside of bugs.g.o. I think using > attachments instead of inlining is a pretty good temporary solution to > a communication problem that has for now been solved by making every > stabilisation bug report a dumping ground for a ton of information > that becomes obsolete within a few days. Stabilisation bugs by their very nature are temporary - they are active for the time it takes to decide a package can be marked stable. Once the package version is marked stable, the bug should be closed. I don't see what the communication problem is. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o
On Fri, 11 Aug 2006 04:56:18 + (UTC) "Duncan" <[EMAIL PROTECTED]> wrote: > Even back before it became the "in" thing, I was posting emerge > --info as attachments, because it simply fit the bill -- bugzy /says/ > to put long stuff as attachments. I never did quite understand why > all that admittedly often useful high-volume spew was tolerated in > the bug comments themselves. Personally I find it a lot easier to read a bug when the emerge --info data from people is inline. Frequently, the trigger for a bug becomes apparent when you compare the emerge --info of the various people who see a bug, and it's a moment's effort to scroll up and down the bug to compare data. This process takes longer if the info is in a bunch of attachments. [re. posting AT configs somewhere] > I like the idea above, tho. For ATs especially, having some place > where emerge --info could be posted just once, with a link to it > instead of the duplicated inline /or/ attachment, makes even more > sense. Presumably, where it's posted could have dated versions, too, > allowing for updated flags without invalidating the info pointed to > for older links. If variation off the norm was needed or used for an > individual package, that could be noted in the comments along with > the link to the standard info. I think the info changes frequently enough that it's easier, and more likely to be correct, if it's posted to the bug at the time the report is made. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Thu, 10 Aug 2006 14:44:13 -0400 Thomas Cort <[EMAIL PROTECTED]> wrote: > On Thu, 10 Aug 2006 19:50:55 +0200 > Jeroen Roovers <[EMAIL PROTECTED]> wrote: > > > I propose the `emerge --info` included in arch testers' comments on > > stabilisation bugs should rather be posted as attachments. The AT > > comments clog up the bugs and are usually not interesting at all to > > devs other than those who are arch devs for the relevant arches. The problem with attachments is that processing the report takes longer - you have to go to the web to read the attachment to find out what config worked (or failed, if that was the case). It's best to have it in-line, I think. If you're not interested in the AT emerge --info data, why are you watching the stabilisation bug? > > It would certainly improve my RSI not to have to scroll past them. > > Why do arch testers need to post `emerge --info` if everything works? So that you know what configuration worked. This is useful information. > Shouldn't we be able to trust that they have sane CFLAGS, proper > FEATURES, and an up to date system? It's not about trust, it's about knowing what the CFLAGS/FEATURES were. That way if someone else reports a failure, you can compare the reports and see what differences might be triggering the fault. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: mulltiib cruft: /emul
On Thu, 10 Aug 2006 12:26:10 -0500
Mike Doty <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Donnie Berkholz wrote:
> > Olivier Crete wrote:
> >> It was chosen by brad_mssw to match the way it is done on ia64.
> >> And I think we should continue to put the binary
> >> app-emulation/emul-linux-x86-* in /emul/ and that lib32 should be
> >> reserved for properly installed packages using portage whenever we
> >> manage to get portage to support it.
> >
> > It makes sense that you wouldn't want these binary packages going
> > into /lib32 or /usr/lib32, but /emul seems like an odd choice
> > compared to something like /opt/lib32.
I though exactly this when I saw SpanKY's query. Having a directory in
'/' is not pretty.
> IIRC, /emul predates FHS acceptance. also, while they are "binary"
> packages, they arn't in the same catagory as binary-only packages. We
> distribute them to assist multilib and to overcome problems that
> portage wasn't really designed for.
More generally we have varying approaches to pre-built packages;
app-office/openoffice-bin installs to /usr for example, while
mail-client/mozilla-thunderbird-bin and www-client/mozilla-firefox-bin
install to /opt.
In these cases, where they are installed on the same target
architecture as they were built, I think it makes sense to have them
install as if they were built with 'emerge -B' for installation via
'emerge -K' - i.e. in /usr rather than /opt.
x86-built binary packages for x86_64 are not the same, of course. One
idea that springs to mind immediately is to put them in a
{bin,include,lib...} hierarchy under /usr/ (which is also
where the compiler stuff for ends up). Conceptually at least
(although no doubt problematic in practice) on x86_64 one could use a
x86(_32) cross-compiler to build stuff to ROOT=/usr/${CTARGET}. Again
in concept a /${CTARGET}/{bin,include,lib...} would exists for
essential boot stuff, althought that's a bit academic.
Just a thought for the pot ;)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] per-package USE defaults
On Tue, 8 Aug 2006 17:49:40 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Tuesday 08 August 2006 15:18, Zac Medico wrote: > > Stuart Herbert wrote: > > > Any chance of per-package USE defaults support? That's much more > > > useful to me. > > > > Attached to bug 61732 there's a patch that implements this via a new > > IUSE_DEFAULTS ebuild variable. If people like that particular > > implementation, then I'll update the patch so that it applies to > > portage-2.1.1_pre. Some might suggest that an EAPI bump is proper > > for the addition of this type of functionality, but perhaps we can > > slide it in without that extra annoyance. > > i'm really really partial to overloading IUSE here rather than > introducing a new variable ... You mean by doing something like: IUSE="alpha +beta gamma" meaning beta is default-on? Could do the same thing in per-package use.mask (although "mask" becomes a misnomer at that point). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Make FEATURES=test the default
On Sat, 5 Aug 2006 14:35:49 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Saturday 05 August 2006 06:57, Kevin F. Quinn wrote: > > On Sat, 5 Aug 2006 11:49:53 +0200 > > Danny van Dyk <[EMAIL PROTECTED]> wrote: > > > Please re-read the list of packages that fail tests: > > > * glibc > > > * autoconf > > > * gettext > > > * tar > > > That makes _4_ system packages. Before I would consider making > > > FEATURES=test a default, I would add least want the system set to > > > actually merge with it. > > > > So you're happy to let users install these packages without them > > knowing the tests would fail? > > before i added binutils-2.17, i ran `make check` on it for about 25 > targets ... of those, about 10 failed ... > > i checked with upstream and others reproduced it ... i dont know > about you, but i dont have the skills to go in and fix the failures > for all of those architectures Agreed, however you could rig src_test() to either skip the tests on those arches, or run them without die()ing and ewarn about the known failures on those arches, or just leave them in ~arch (or even masked) for the arches where they fail, depending on the impact of the failures. That sort of thing is well within our role of package management. > while i like the idea of all packages being able to pass > FEATURES=test, somethings it just aint gonna happen with Gentoo's > available skill set -mike -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Make FEATURES=test the default
On Sat, 05 Aug 2006 17:14:23 +0200 Sven Köhler <[EMAIL PROTECTED]> wrote: > So my question is: > where's the difference between USE="test" and FEATURES="test" ? > > So FEATURES="test" means, that portage runs src_test(), right? Yes. > So what does USE="test" mean? USE="test" is a workaround; portage cannot use FEATUREs in dep strings. So for example, if the test phase needs a separate tarball of data (a common enough occurrence) and the ebuild maintainer wants to download that tarball only if the tests are being run (perhaps the test data is huge), this can only be done with USE flags. Basically, if you set FEATURES="test", add "test" also to your USE flags. USE="test" should never be used for anything other than supporting FEATURES="test". -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Make FEATURES=test the default
On Sat, 5 Aug 2006 11:49:53 +0200 Danny van Dyk <[EMAIL PROTECTED]> wrote: > Please re-read the list of packages that fail tests: > * glibc > * autoconf > * gettext > * tar > That makes _4_ system packages. Before I would consider making > FEATURES=test a default, I would add least want the system set to > actually merge with it. So you're happy to let users install these packages without them knowing the tests would fail? I certainly agree they should pass their tests. autoconf-2.60, gettext-0.15 and tar-1.15.1-r1, which are the latest versions I have installed here, all pass on my system. If they fail on your platform, then you should make sure bugs are open and the relevant maintainers are doing something about it, and IMO they should not go to arch (i.e. should remain ~arch) until the test issues are resolved. Thing is, at the moment you have a bunch of packages installed that fail their tests. This may mean the tests are broken, however it may also mean the packages are not working correctly on your system, and I'd be concerned if I were you. Avoiding the test phase doesn't make the packages work, obviously. glibc is somewhat of a special case; it is especially sensitive to the environment - many of the tests assume a vanilla RedHat environment, and often the test failures in glibc are not actual problems with glibc but limitations of the test suite. However we should not be encouraging people to install glibc versions where the test failures are not understood. Clearly if something in glibc is not behaving properly, the effects can be nasty. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Make FEATURES=test the default
On Fri, 04 Aug 2006 17:25:17 -0700 Joshua Jackson <[EMAIL PROTECTED]> wrote: > While I agree that it would be nice to see more > people using test and collision-protect I don't think its something we > should enable at this point in time till we have many packages working > correctly with the feature. It's a bit chicken-and-egg. While they're not default, they are a low priority to be fixed. However that said, I've been running with FEATURES=test (and collision-protect) pretty much since I joined (certainly all the time I've been a dev) and it doesn't cause a crippling amount of trouble - mainly because most packages do not include a test suite. > If however people feel that by enabling > it, that it'll make us actually fix these issues then I'd like to see > it move forward. That's my main motivation for suggesting it. I think packages should not be unmasked until they pass their test phase for the maintainer. They shouldn't go stable until they pass their test phase for the arch testers. > I'm just curious as to why this has come up suddenly Kevin? Well, it's not sudden for me - I've been thinking it should be the default for a long time, usually every time see a test failure that should have been caught by the maintainer and raise a bug for it. Have to raise the issue some time; there's no particular reason for raising it now, and there's certainly no hurry to change anything. A good time to do it would be when portage goes up a revision (to 2.2, or perhaps even when it goes to 2.1.1 if we think it won't be too disruptive). > p.s I hope all dev's run with test and collision-protect, I know I > know you don't but I can hope. IMO devs should be working with "collision-protect sandbox strict stricter test userpriv" but let's not get too excited ;) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Make FEATURES=test the default
On Sat, 5 Aug 2006 02:39:16 +0200 Danny van Dyk <[EMAIL PROTECTED]> wrote: > Am Samstag, 5. August 2006 02:11 schrieb Kevin F. Quinn: > > At the very least, ebuild maintainers and ATs should be running with > > tests switched on. If the tests are known to fail then the ebuild > > can either RESTRICT=test, or just return successfully from > > src_test() where the test report is useful even if some tests fail. > > > > Thoughts? > * autoconf takes ages (longer than compiling glibc here). > * glibc tests fail on amd64 since at least a year. > * automake|e2fsprogs|neon|gettext|tar have failed tests for me more > than once. > > As soon as these are fixed, i wouldn't mind making FEATURES="test" a > default. Well, if something fails its tests but you still want it regardless or you want to skip the test phase for some other reason, you can always do FEATURES="-test" emerge . Changing the default doesn't prevent people from skipping tests, however in the long term it will reduce the amount of stuff committed to the tree that doesn't pass tests. It will increase the amount of times a system or world update falls over, but changing the default will raise the priority for getting these things fixed. There are many packages in the tree for which it is clear the maintainer did not even attempt to run the tests - e.g. https://bugs.gentoo.org/show_bug.cgi?id=139414 To my mind committing packages without even bothering to try the test phase is inexcusable. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Make FEATURES=test the default
On Fri, 04 Aug 2006 20:18:40 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: > Give me some numbers on how many things still fail with that enabled > because I would be concerned if the number is too high. I don't have numbers, but if you have FEATURES=test set yourself you should know how many fail. It's not insignificant. -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] Make FEATURES=test the default
I'd like to suggest we make FEATURES=test (and therefore USE=test) the default behaviour, rather than the opt-in we currently have. Far too many packages fail their test phase. Since we encourage users to set CFLAGS in ways that upstream may not have predicted, if upstream go to the trouble of providing tests it seems sensible to me that they should be run, unless there is a very good reason not to run them. This will help pick up faults that are due to the compiler version, CFLAGS etc much more consistently. At the very least, ebuild maintainers and ATs should be running with tests switched on. If the tests are known to fail then the ebuild can either RESTRICT=test, or just return successfully from src_test() where the test report is useful even if some tests fail. Thoughts? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Treecleaners Recruiting
On Thu, 03 Aug 2006 19:48:01 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: > To briefly go over requirements you need to be able to: > > Speak English; Why? Surely read & write is enough. -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] metastructure model (was Re: Sunrise contemplations)
On Wed, 02 Aug 2006 12:00:56 +0200 Thierry Carrez <[EMAIL PROTECTED]> wrote: > Excerpt from the metastructure model, chosen by the majority of devs > last year (and not my model): > [...] > * It may have one or many leads, and the leads are selected by the > members of the project. This selection must occur at least once every > 12 months, and may occur at any time. > [...] While we're on the subject of the metastructure model, could we consider changing this rule? It's a little strict, and I suspect it's honoured more in the breach than otherwise (by which I mean some, perhaps many, projects don't bother to hold a selection process every 12 months). The 12 month rule makes perfect sense for the council and foundation trustees but it's over the top as a rule for all projects. I would suggest something along the lines of, "selection of leadership of a project can occur at any time, but can be forced should a majority of the team feel a new selection is necessary", perhaps with a rider allowing projects to setup stricter rules if they feel the need. I'm assuming (since I haven't checked) that project membership requires agreement of the project (i.e. people can't just join a project without the existing project members' agreement). The idea being that if the current leadership want to step down they can do so and selection occurs within the project by default. At the other extreme, if a lead becomes a pita for everyone else on the project, the rest of the project can oust the lead by majority decision (hopefully a rare occurrence). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Sunrise contemplations
ise overlay, in which case they'll get to understand what maintenance means, how much effort is involved and thereby understand better the commitment expected of them should they decide to go for dev-ship. > In conclusion these 3 points come together here : being a dev is not > about adding new ebuilds to the tree, it is about maintaining what is > already there. Dealing with bugs and users. 100% with you there. Anyone can knock up an ebuild - it takes effort to maintain it, and that's the lions share of the work of most devs. > That aspect of Sunrise is > not at all tackled in its goals. What are the longterm prospects of > ebuilds in the Sunrise tree ? Is this not in their documentation? From the project name, I would expect they hope that stuff either rises fully (i.e. to end up in the tree with proper maintainership) or would wither and die depending on how much effort is put in by those who want the package. > That is what QA is about, providing a > stable base to work on. I do not think that devs who mainly add > ebuilds and new packages to the tree are good devs, the real job is > maintenance and bughandling. In that sense Sunrise might be giving > the wrong impression to wannabe devs. > > * The rise of project Sunrise > > Now for the second big point concerning Sunrise : how it came into > being. This was certainly handled very badly. However I think that's history now, and there's not much to be gained from going back over it. > [...] > Anyway, the project after the initial announcement got a 'temporarily > removed' status from gentoo.org . The problem here in my opinion is > not so much that the people who support the project needed to defend > it, but that people who are more conscious about the project need to > prove it is wrong. This had to happen in a mere 2 months where the > project has had hardly any impact. If you want to properly evaluate > such an extensive project it needs to be given much more time. The > project should prove itself before it should be allowed to 'join' > Gentoo, not the other way around. I have seen no tangible benefits > from Sunrise so far, aside from the fact that developers have left > over it and the developer community is seriously divided these days. > As such Sunrise has been one big mistake, the possible benefits at > this point in time do not outweigh the havoc it has caused. Beyond the mailing list wars (I won't call them flamewars because I think most combatants are sincere with their concerns), I don't think there has been any significant detrimental effect - for the same reason; i.e. it's only been around for a couple of months so hasn't had time to produce any of the problems that some people are worried will occur. > * The implications of sunrise > > What will Sunrise mean to the general developer ? > [...] > In short, from my experience Sunrise will only result in more work for > the general developer with little benefits. This may not happen often, > but every single time is one time too much. This is can be really > demotivating, which is probably the worst thing about it. I think as long as Sunrise steers clear of core system packages, essentially focusing on "leaf" packages, the sorts of problem you encountered with BMG can be avoided. Certainly I would expect Sunrise not to be providing alternate versions of stuff already in the tree, and not to be modifying eclasses that exist in the tree - this sort of change is for managed dev overlays. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Mon, 24 Jul 2006 06:23:59 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > On Mon, Jul 24, 2006 at 02:47:46PM +0200, Kevin F. Quinn wrote: > > On Sun, 23 Jul 2006 12:19:28 +0100 > > Stuart Herbert <[EMAIL PROTECTED]> wrote: > > > Just adding an alias > > > into a second category makes the tree more of a mess - not less. > > > > The alias, once setup, can be left alone forever. As far as any > > further maintenance is concerned, it requires none. Even if the > > package is moved again, the alias can still point to the second > > location which becomes an alias for the final location. > > That implicitly means that any second level categorizations can never > be removed. By "second level categorizations" do you mean the intermediate alias? The intermediate alias will exist anyway, as an alias in its own right. If any alias is to be removed, then clearly any references to it need to be cleaned up. This is the case whether the alias in question is part of a chain or not. Also this is no worse a situation than current package moves - a fixpackages-style patch-up becomes necessary at that point (more on removal below). Having said all that, I do think the single alias file approach would be better, and it would be simple then to require all aliases to refer directly to the real category. This would indeed require some maintenance, but not exactly back-breaking, just one file for the maintainer of the package that is being moved to check for existing aliases to the previous location. > Like stuart said, makes a bigger mess of the tree. Package moves can > be disruptive enough- trying to shift out a non-real category is > going to be a much larger mess of building that tree and trying to > rewrite atoms as needed. I disagree, it's not a mess. It's better for existing installations as the old CP still works - so to my mind you get the best of both worlds; you can move the package to whatever category the maintainer thinks is the best, without having to hack around all over the place (which currently leaves standalone installations in the dark, btw) to clean up. > > As far as > > users are concerned, assuming aliases are resolved when being > > parsed, they would see: > > > > $ emerge -p net-im/skype > > > > These are the packages that would be merged, in order: > > > > Calculating dependencies... done! > > [ebuild R ] net-voip/skype-1.3.0.30-r1 > > That doesn't strike you as a bit... daft? they asked for net-im, not > net-voip. Yes, under your scheme, they're the same- that still is > far from intuitive. No, it seems simple enough to me. Someone who has previously installed skype from the net-im category, may remember it was in net-im and type the command I illustrated. However the package has moved to net-voip, and emerge has done the right thing - managed the alias and gone to the correct package. If you really wanted to be verbose about it, it could go like: $ emerge -p net-im/skype These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] net-voip/skype-1.3.0.30-r1 [*] [*] package moved to highlight to the user the package has moved. Currently that same user would do: $ emerge -p net-im/skype These are the packages that would be merged, in order: Calculating dependencies emerge: there are no ebuilds to satisfy "net-im/skype". [bum - where has Skype gone? hmm; perhaps it's somewhere else] $ $ emerge -p net-voip/skype ... Note that since alias names would be ignored if the category is not specified, 'emerge -p skype' would just work in the way it does now. Note also that if a new package is added with the same name, and that package goes in what was once an alias location, the package manager requires you to specify which one you want. > > The only "mess" is that we end up with the alias data in the tree > > and that gradually accumulates. > > Err... cruft accumulating in the tree is a no go. What, like eclasses and ChangeLogs? It's history, rather than cruft. It has meaning to existing installations, as does legacy code in eclasses. I illustrated elsewhere that it could easily be implemented by a simple text file, nothing more intrusive than package.mask et. al. > > However it won't change once it's first > > setup so won't incur any significant synchronisation overhead > > (beyond the overhead for the actual move as done currently). > > A) potential of circular aliasing (fun fun) Circular aliasing is obviously broken and should not be committed. Any such occurrences should be fixed promptly, and the committer slapped. It's also easy to detect. However it's a good rea
Re: [gentoo-dev] New category: net-voip
On Sun, 23 Jul 2006 12:19:28 +0100
Stuart Herbert <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > An advantage to this approach is that package moves just become
> > aliases
> > - existing stuff doesn't break yet you get the new categorisation as
> > well.
>
> That's actually a disadvantage. The whole point of moving a package
> is to take it *out* of its existing category.
No, the point is to take it from a category where it's membership is
not so strong, to one where it is stronger. For exmaple, it's not that
net-im is the wrong place for skype, it's just that net-voip is in some
ways better. Where categorisation is clearly very wrong then it should
be moved as soon as possible (for example if skype had initially been
placed in www-apps) but that's an initial commit problem rather than
maintenance going forward.
> Just adding an alias
> into a second category makes the tree more of a mess - not less.
The alias, once setup, can be left alone forever. As far as any
further maintenance is concerned, it requires none. Even if the
package is moved again, the alias can still point to the second
location which becomes an alias for the final location. As far as
users are concerned, assuming aliases are resolved when being parsed,
they would see:
$ emerge -p net-im/skype
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] net-voip/skype-1.3.0.30-r1
(where net-voip/skype is copied from net-im/skype, then net-im/skpe is
rewritten as an alias), which is clear and simple (it's hardly more
than what emerge does if you only give it the package name). Aliases
can be ignored when the category is not specified (unless we permit
aliasing with different package names, which I suggest we do not).
Similarly with 'emerge -s' - it would return the canonical CP.
The only "mess" is that we end up with the alias data in the tree
and that gradually accumulates. However it won't change once it's first
setup so won't incur any significant synchronisation overhead (beyond
the overhead for the actual move as done currently). I've mentioned the
/alias idea elsewhere, however that's not the only way to do it -
one simple method could be to have a simple text file (e.g.
${PORTDIR}/profiles/alias) listing all the aliases. That's no mess at
all:
example alias file contents
# Alias category/package Resident category
net-im/skype net-voip
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Sat, 22 Jul 2006 13:35:08 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > On Sat, Jul 22, 2006 at 06:04:10PM +0200, Kevin F. Quinn wrote: > > On Fri, 21 Jul 2006 01:05:20 -0700 > > Brian Harring <[EMAIL PROTECTED]> wrote: > > > > > > >Unfortunately the category system is deeply embedded in portage > > > > >and the tree, so changing that system is simply not going to > > > > >happen, which is why I've stopped whinging about the semantic > > > > >inadequacy of the system. > > > > > > > > Instead of whinging about why the existing categories are bad, > > > > why not instead put forward an alternative (preferably with > > > > code, but a clear and consistently argued position would be a > > > > start) for something better? Otherwise, you *are* going to be > > > > ignored ... and with good reason. > > > > > > Just so we're clear, I probably will wedgie anyone who suggests > > > trying to extend the existing tree format with N categories per > > > pkg- sounds nice on paper, but it makes lookup a serious pita- > > > sys-apps/portage, we'll pretend it's actually located in sys-apps, > > > and it's also in category 'pkg-managers'. An atom states > > > 'pkg-managers/portage'; how does a pkg manager do a lookup for it? > > > > Since the names would be aliased, either reference would be fine > > i.e. a dep on pkg-managers/portage would be equivalent to > > sys-apps/portage. > > > > If it were to be implemented with symlinks (implying one entry is > > "real" and the others are aliases) the package manager just needs to > > canonicalise any symlinked CPs it comes across. > > > > Since we can't have symlinks in CVS, there are other ways it can be > > done; first thing that pops into my head is an "alias" package > > entry in the tree, where instead of ebuilds & files/ etc it would > > just contain a file "alias" with the category (and perhaps package > > name) of the aliased package. > > > > I would expect it to be non-trivial to implement in portage, since > > portage code has evolved for so long assuming that a package is in > > one category - I'm not saying portage code is bad, I'm just saying > > that much of it may have been implemented under that assumption and > > breaking it means testing lots of stuff. > > > > > Has to walk the entire tree... so if N category per pkg is going > > > to be proposed, need to preserve the fast lookup that's there now. > > > > I don't think the above ideas cause any substantial change to the > > amount of processing required. > > > > An advantage to this approach is that package moves just become > > aliases > > - existing stuff doesn't break yet you get the new categorisation as > > well. > > A disadvantage being that without a tree, your graph is broken > (aliases live in the tree); this includes using strictly a bintree > (remote or otherwise). I don't get what you're talking about here; perhaps I'm missing something. I don't see why the deps can't be managed by canonicalising every reference as they are parsed. As you build the graph, the aliases disappear as they are canonicalised before they reach the graph. That way the only place aliases exist is in the portage tree itself - the package manager can forget about them once it has parsed the deps. Certainly trying to build the dependency tree without canonicalising aliases would be a mess; anyone trying to do it like that is asking for trouble. You want unique names for everything for which you're building the dependency tree. > Big disadvantage, hence why that approach was ignored last time it > was brought up. -- Kevin F. Quinn signature.asc Description: PGP signature
