[gentoo-dev] Quantity of open bugs

2011-03-10 Thread Kevin F. Quinn
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

2008-02-04 Thread Kevin F. Quinn
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] 'stricter' FEATURE and poor programming practices notice

2007-05-19 Thread Kevin F. Quinn
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] distcc and precompiled headers

2007-05-19 Thread Kevin F. Quinn
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] Eigen and GPL-2 exception - is a new licence required?

2007-05-12 Thread Kevin F. Quinn
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

2007-04-30 Thread Kevin F. Quinn
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

2007-04-22 Thread Kevin F. Quinn
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 blah 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

2007-04-21 Thread Kevin F. Quinn
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: [gentoo-dev] $Header:$ and ebuilds

2007-04-21 Thread Kevin F. Quinn
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] {Guide,Project,Foo}XML too confusing for many devs?

2007-03-26 Thread Kevin F. Quinn
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)

2007-03-25 Thread Kevin F. Quinn
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


[gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla

2007-03-24 Thread Kevin F. Quinn
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] Suggestion: INVALID - NOCHANGE in bugzilla

2007-03-24 Thread Kevin F. Quinn
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

2007-03-24 Thread Kevin F. Quinn
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

2007-03-24 Thread Kevin F. Quinn
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

2007-03-24 Thread Kevin F. Quinn
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

2007-03-24 Thread Kevin F. Quinn
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] RFC Package name additions

2007-03-19 Thread Kevin F. Quinn
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] Re: Gentoo's problems

2007-03-16 Thread Kevin F. Quinn
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] Summary for 15 March 2007 special council meeting on CoC

2007-03-16 Thread Kevin F. Quinn
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] Why I don't think the CoC is a good idea

2007-03-15 Thread Kevin F. Quinn
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

2007-03-15 Thread Kevin F. Quinn
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] Gentoo's problems

2007-03-15 Thread Kevin F. Quinn
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] Introducing the Proctors - Draft Code of Conduct for Gentoo

2007-03-14 Thread Kevin F. Quinn
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] Re: Distrowatch

2007-03-14 Thread Kevin F. Quinn
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] Re: Distrowatch

2007-03-14 Thread Kevin F. Quinn
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] mod_perl in apache conf

2007-03-08 Thread Kevin F. Quinn
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


[gentoo-portage-dev] LC_ALL and friends in make.conf

2007-03-08 Thread Kevin F. Quinn
This is an old issue, but I want to suggest a re-visit :)

As we all know, setting LC_ALL and friends can cause all sorts of
trouble in package builds.  However, many users really appreciate
being able to set it so that errors from the compiler etc are in their
own language.

It occurs to me that during emerge, only LC_MESSAGES is actually useful
for the user, to help interpret build errors.  LC_COLLATE and the
others don't give the user any benefit in the emerge process.

So how about if LANG or LC_* are set, portage would set LC_MESSAGES and
clear the rest?

Is there any real advantage to the user having LC_* set apart from
LC_MESSAGES?

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


Re: [gentoo-dev] Some council topics for March meeting

2007-03-04 Thread Kevin F. Quinn
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: Copyright, non-US devs and Gentoo Foundation vs Gentoo (Was: [gentoo-dev] Some council topics for March meeting)

2007-03-04 Thread Kevin F. Quinn
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] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))

2007-02-22 Thread Kevin F. Quinn
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] Reliance upon || ( use? ( ) ) behaviour

2007-02-22 Thread Kevin F. Quinn
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] A Gentle Reminder

2007-02-11 Thread Kevin F. Quinn
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] A Gentle Reminder

2007-02-11 Thread Kevin F. Quinn
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] afflib licence (BSD4 like)

2007-02-07 Thread Kevin F. Quinn
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] New network config for baselayout-ng

2007-02-07 Thread Kevin F. Quinn
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] New network config for baselayout-ng

2007-02-07 Thread Kevin F. Quinn
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] Hardened USE flag

2007-02-06 Thread Kevin F. Quinn
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] Network configuration and bash

2007-02-06 Thread Kevin F. Quinn
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] Network configuration and bash

2007-02-06 Thread Kevin F. Quinn
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] Re: Monthly Gentoo Council Reminder for February

2007-02-03 Thread Kevin F. Quinn
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

2007-02-02 Thread Kevin F. Quinn
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

2007-02-01 Thread Kevin F. Quinn
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-portage-dev] [RFC] Depending on active version

2007-01-31 Thread Kevin F. Quinn
On Wed, 31 Jan 2007 12:27:10 -0500
Alec Warner [EMAIL PROTECTED] wrote:

  Hmm; one could get the same benefit by introducing a new interface
  (e.g. pkg_env_check()) which is defined to return true if the
  environment is ok, false otherwise (with some text to stdout,
  perhaps). The package manager would then run this function, after
  building the depgraph and finding the candidate packages to merge,
  for each candidate package - if any package fails is env_check,
  none of the packages get emerged.  Note this is then completely
  independent of depgraph creation.
  
  In the 'tr1' example, I'd imagine something like this:
  
  use.local.desc: boost: Use boost library for tr1 rather than gcc's.
  
  ebuild:
  
  ...
  inherit ... toolchain-funcs versionator ...
  ...
  DEPEND=... boost? ( dev-libs/boost ) ...
  ...
  pkg_env_check() {
  use boost  return 0
  version_is_at_least 4.1 $(gcc-version)  return 0
  echo Either USE boost, or switch to gcc later than 4.1
  }
  
  
  (with a default definition, pkg_env_check() { return 0; } )
 
 In an ideal system you'd want this stuff in the metadata cache so that
 the resolver can deal with it up front.

You're talking about the metadata on the host, rather than the stuff on
the rsync servers?  I'm not sure you could cache the results even on
the host - you would need to know what could affect the results so as
to know when the cached information is out of date and has to be
recalculated.  That would either have to checked on every emerge, or
made a separate switch (i.e. rely on the user to tell emerge when the
environment has changed).

  All resolution is a brute
 force metadata search; and assuming we had all the necessary data up
 front, we can optimize the search there (see pkgcore and restriction
 subsystem) versus IMHO doing a 'dumb' search and then running through
 a list of criteria for inclusion.
 
 This is the same reason why built_with_use in pkg_setup is really just
 use_deps; these metadata should be included during resolution, not
 after.

My concern about dynamic dependencies runs to use deps, as well :)
One could consider use-deps to be a special case of Marius' active
checks.  how pkg P was built isn't so different from slot S of P is
active in terms of dep-graph creation; both are asking about the
state of host  target systems, rather than the tree.

In the case of USE deps, things are saner because the data doesn't
change without the package manager knowing about it.  Effectively the
depgraph becomes static w.r.t. the tree + installation record (rather
than just static w.r.t. the tree).  With active checks implemented in
the depgraph, however, that is no longer the case - the depgraph can
change independently of the tree and the installation record.

 With that said, I'm not sure how easy it would be to rewrite that
 code; and this is simpler in that it's just a few bash functions as
 opposed to more resolver foo.

There's a lot to be said for keeping things simple, of course :)  It's
easy enough to mess up things like dep-graphs in any case - introducing
these sorts of dynamic dependencies can render it substantially more
complex.

Another way to look at it, is to consider how often this sort of thing
comes up.  My understanding is that it is relatively rare; across the
10,000+ packages in the tree only a handful use 'built_with_use' fex.
That makes a strong case for having a simple solution in the near term,
and re-visit if it becomes commonplace.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


Re: [gentoo-dev] Changing licenses/BSD

2007-01-14 Thread Kevin F. Quinn
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

2007-01-11 Thread Kevin F. Quinn
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

2007-01-09 Thread Kevin F. Quinn
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*

2007-01-06 Thread Kevin F. Quinn
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+

2007-01-04 Thread Kevin F. Quinn
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+

2007-01-03 Thread Kevin F. Quinn
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

2006-12-06 Thread Kevin F. Quinn
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] Re: Versioning the tree

2006-11-27 Thread Kevin F. Quinn
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


Re: [gentoo-dev] ACCEPT_LICENSE revisited

2006-11-27 Thread Kevin F. Quinn
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


[gentoo-dev] Announcement: New(ish) eclass pax-utils.eclass

2006-11-24 Thread Kevin F. Quinn
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

2006-11-22 Thread Kevin F. Quinn
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-something.
  Since the ACCEPT_LICENSE syntax allows -license, 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

2006-10-25 Thread Kevin F. Quinn
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

2006-10-13 Thread Kevin F. Quinn
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

2006-10-10 Thread Kevin F. Quinn
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

2006-10-05 Thread Kevin F. Quinn
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

2006-10-05 Thread Kevin F. Quinn
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

2006-10-05 Thread Kevin F. Quinn
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

2006-10-04 Thread Kevin F. Quinn
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
unmaintainedbroken 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] Gentoo World Domination. a 10 step guide

2006-10-04 Thread Kevin F. Quinn
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

2006-10-04 Thread Kevin F. Quinn
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

2006-10-04 Thread Kevin F. Quinn
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] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Kevin F. Quinn
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

2006-09-07 Thread Kevin F. Quinn
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
 !app-text/hunspell-1.0, which means that you can't have
 hunspell-1.0 and kdelibs installed on a system at the same time.
 Reason for this could e.g. be file collisions that got fixed in
 hunspell-1.0.
 
 If the depstring was !app-text/hunspell-1.0 app-text/hunspell,
 (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] Re: packages going into the tree with non-gentoo maintainers

2006-09-04 Thread Kevin F. Quinn
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] [GLEP] Bugzilla access for contributors

2006-09-04 Thread Kevin F. Quinn
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


[gentoo-dev] packages going into the tree with non-gentoo maintainers

2006-09-03 Thread Kevin F. Quinn
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] Re: packages going into the tree with non-gentoo maintainers

2006-09-03 Thread Kevin F. Quinn
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


Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-03 Thread Kevin F. Quinn
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] Gentoo 2006.1

2006-09-03 Thread Kevin F. Quinn
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] Gentoo 2006.1

2006-09-02 Thread Kevin F. Quinn
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

2006-08-29 Thread Kevin F. Quinn
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
file) 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 set)' and more like
emerge sets/set where sets/set/set-V.ebuild is like a meta-ebuild.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


Re: [gentoo-dev] Democracy: No silver bullet

2006-08-24 Thread Kevin F. Quinn
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

2006-08-21 Thread Kevin F. Quinn
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

2006-08-12 Thread Kevin F. Quinn
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] Re: RFC: AT emerge info cruft attachments on bugs.g.o

2006-08-11 Thread Kevin F. Quinn
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

2006-08-11 Thread Kevin F. Quinn
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] RFC: AT emerge info cruft attachments on bugs.g.o

2006-08-11 Thread Kevin F. Quinn
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=1action=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
  just skip to the next message.
 
 Erm. It is a problem - I've explained why. It adds bloat and it clogs
 many arch devs' mailboxen with tons of useless info. Merrily skipping
 past it is impossible when a bug spans 5 instead of 2 pages because
 of 3 AT comments, interspersed with possibly useful comments. I guess
 you would feel the same way if I started inlining `emerge info` for
 all my HPPA systems. You'd have to parse each one of them just to
 find your own ATs' `emerge info` among mine.

I don't understand how you're getting many pages in one email - surely
each report by an AT is a separate comment and hence a separate
email

Re: [gentoo-dev] RFC: AT emerge info cruft attachments to [STABLE] bugs

2006-08-11 Thread Kevin F. Quinn
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] Re: mulltiib cruft: /emul

2006-08-10 Thread Kevin F. Quinn
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/ctarget (which is also
where the compiler stuff for ctarget 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] RFC: AT emerge info cruft attachments on bugs.g.o

2006-08-10 Thread Kevin F. Quinn
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] per-package USE defaults

2006-08-09 Thread Kevin F. Quinn
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

2006-08-05 Thread Kevin F. Quinn
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


Re: [gentoo-dev] Make FEATURES=test the default

2006-08-05 Thread Kevin F. Quinn
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 foo.

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

2006-08-05 Thread Kevin F. Quinn
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

2006-08-05 Thread Kevin F. Quinn
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] Re: Make FEATURES=test the default

2006-08-05 Thread Kevin F. Quinn
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

2006-08-05 Thread Kevin F. Quinn
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] Treecleaners Recruiting

2006-08-04 Thread Kevin F. Quinn
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] Make FEATURES=test the default

2006-08-04 Thread Kevin F. Quinn
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


[gentoo-dev] metastructure model (was Re: Sunrise contemplations)

2006-08-02 Thread Kevin F. Quinn
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

2006-08-01 Thread Kevin F. Quinn
 : 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

2006-07-24 Thread Kevin F. Quinn
On Sat, 22 Jul 2006 21:42:07 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Sat, 22 Jul 2006 18:04:10 +0200 Kevin F. Quinn
 [EMAIL PROTECTED] wrote:
 | 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.
 
 Not that simple. Think about installed packages, overlays and changing
 aliases. The package manager would need to keep track of what aliases
 were at any given time.

Not if the aliases are resolved to the canonical CP when they are
parsed.  At any point in time, the dep resolver would be working with
canonical CPs as they exist at that point, not what they were when the
package was installed or the binpackage was built.

 Then there're symlinks to outside the tree and

Maybe I've misunderstood you here, but surely aliasing from inside the
tree to outside it (e.g. to an overlay package not present in the
primary tree) would not be sensible.

 circular symlinks... There's a lot more too it than is initially
 obvious.

My understanding is that circular dependencies are not supported; the
situation would be no different with aliasing, pretty much by
definition if nothing else - all aliases should ultimately resolve to a
real package, which they can't do if you allow circular aliases.

 | 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.
 
 Files are cleaner than symlinks for other reasons too. Also allows the
 opportunity of making 'deprecated' aliases that issue QA warnings.

 |  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.
 
 Perhaps you should think. It's nowhere near as straight forward as you
 claim. Which is not to say it's not doable, just that it's not doable
 cheaply...

I still don't see how, if aliases are canonicalised when they are
parsed, the issue becomes more complex.  Internally the package manager
would always think in terms of the canonical CP, at which point it's
not doing anything that it isn't already.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


Re: [gentoo-dev] New category: net-voip

2006-07-24 Thread Kevin F. Quinn
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


Re: [gentoo-dev] New category: net-voip

2006-07-24 Thread Kevin F. Quinn
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
CP/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

2006-07-24 Thread Kevin F. Quinn
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]

  $ insert favourite package searching mechanism here
  $ 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 reason to require all aliases to be direct (i.e. no
aliases of aliases).

 B) potential of aliasing multiple pkgs to the same cat (fun fun)

Ditto :)

 C) pkgs that grow capabilities after a certain version, thus they now 
 belong in a new category.  Now we require full atoms for aliasing 
 (which means lookup gets more complicated now

Re: [gentoo-dev] New category: net-voip

2006-07-22 Thread Kevin F. Quinn
On Thu, 20 Jul 2006 13:24:55 -0700
Brian Harring [EMAIL PROTECTED] wrote:

 On Thu, Jul 20, 2006 at 08:41:46PM +0200, Kevin F. Quinn wrote:
  On Thu, 20 Jul 2006 00:37:47 -0700
  Brian Harring [EMAIL PROTECTED] wrote:
  
   On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote:
On Wed, 19 Jul 2006 17:15:38 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Wed, 19 Jul 2006 08:57:32 +0200 Kevin F. Quinn
 [EMAIL PROTECTED] wrote:
 | Things that package moves cause:
 | 1) Dependencies throughout the tree have to be updated
 
 And? This isn't a breakage.

It is however unnecessary inconvenience for the user, even
assuming the support for moves is bug-free.
   
   Think you're ignoring that proper categorization *is* useful to
   the user.  One of the costs of that is moving when necessary.
  
  My main point is that proper categorisation is subjective.  What
  should be in net-voip for some people, should be in net-im for
  others (since many packages provide functionality in both areas).
  Thus whether or not it moves are necessary is subjective.
 
 How often does a package lie equally across multiple categories?  I 
 think your point (pulling probably fairly close figures out of the 
 head) is relevant to all of 100 or so packages in the tree, out of 
 11k.

Pretty much anything in the sys-* categories, for a start.  Then
there's dev-libs - many packages provide libs and a simple app to use
them, so where do they go?  In *-libs or a category for the simple app?

   Sounds of it, you don't much care for categorizatin- that's fine, 
   please keep in mind some people do find it a net gain to maintain
   the categorization however.
  
  I'm happy with the idea of categorisation in general, I do however
  think that the categorisation in the tree as it stands is simply
  inadequate.
 
 Examples would be lovely- numerous examples specifically.  Please
 keep in mind the tree holds (as of about 15 hours back) 11,212
 packages. Pointing at one or two packages to label all categorization
 as inadequate won't suffice, going to need to clear at *least* 1% of
 the tree to back that assertion up.

I'm not going to waste time going through 11k+ packages to show you
that many packages provide functionality that applies to more than one
category; it seems obvious to me.  Some categories are better than
others - games-* for example, because those apps tend to be designed to
fit a category in the first place.  The problems arise when
categorisation occurs in more than one direction (e.g. sys-* overlaps
other categories) or when categorisation has become so tight that few
packages fit only in such categories (which is what I think is
happening with the net-im/voip categorisation).

 | 3) Binary packages go out-of-date
 
 So rebuild them. Binary packages go out of date whenever
 someone does a version bump too.

So your opinion is that it's fine to cause users to rebuild
stuff even when the package itself hasn't changed?
   
   You're ignoring what fixpackages does.  Ever noticed how it's far 
   faster when you don't have buildpkgs enabled? ;)
  
  I certainly noticed how much time is lost when fixpackages chunters
  through built packages to fix stuff up.
 
 My usual response to criticism of that sort applies- you know where 
 the src is ;)

My understanding is that the amount of time it takes to fix up binary
packages is down to having to unpack, tweak, then re-pack - the unpack
and re-pack are what consume the resource.  Any alternative would
involve changing the package format.

 Doing things *correctly* isn't always the same as doing things
 *fast*. Throwing correctness bits out in the name of speed is a no go
 (iow, fixpackages ought to be nonoptional).

I agree - however this for me is an argument to avoid package moves
unless the move is very necessary.

   Again, you may not view categories as useful, but others may.
  
  My experience with categories as they stand, is that to find a
  package whose location I don't already know I have to search all
  categories anyway - it's certainly not possible to predict in which
  category a package lives.
 
 Not much experience then.  Your use scenario above is I'm looking 
 for a package, not I'm trying to find packages in category x.

Huh?  That's my point - if I'm looking for a package I often don't know
what category it is until I find it.  Some categories are better than
others in this respect.  The point remains though that categories are
one-to-one, where as many packages provide functionality in more
than one area (one-to-many).  You can do one-to-many in a directory
structure by using links (symbolic or hard) - however CVS doesn't
support them, and the dep resolver won't cope with that at the moment
(it could be made to without too much trouble, I think).

 Of course categories don't matter to you in your case- you're not 
 *using* them.  What others are talking about how ever

  1   2   3   >