[gentoo-dev] Last rites: app-misc/sleepyhead

2020-02-16 Thread Richard Freeman
# Rich Freeman  (2020-02-16)
# Dead upstream, obsolete deps.

Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON

2010-12-03 Thread Richard Freeman
On 12/03/2010 07:05 AM, Michał Górny wrote:
 On Fri, 03 Dec 2010 11:35:14 +0100
 Sebastian Pipping sp...@gentoo.org wrote:
 to better communicate USE_PYTHON we could use:
 The first question that comes into my mind is -- why do we need
 to communicate that? I think that USE_PYTHON is a pretty specific
 variable which should be used only if specially required (i.e. to keep
 multiple Python versions ready for use).

I tend to agree.  For a user who doesn't actually USE python, but just
has it installed because half of the rest of the system doesn't work
without it, python is just another dependency.  If a package only works
with python v1.2, then it should depend on the appropriate slot/etc.

If a user actually USES python, then they should have a mechanism to
tell the system what versions of python to keep around.  If you could
put slots in the world file that might do the trick, but this variable
seems like a reasonable way to do it as well.

 What needs to be fixed IMO is the default value of that variable.
 If you already disabled switching the active Python version by default,
 you should also make the Python eclass base its' USE_PYTHON defaults
 on the active Python version.

I tend to agree here as well.  The distro should manage the version used
for distro packages.  Maybe a user wants to do cutting-edge development
work in python-v12.  The system should still use a sane version of
python to run portage/etc, unless the user specifically tells it to do

Rather than hard-coding this in every package a distro-wide default
probably makes sense.  When new versions of python are deemed acceptable
for distro-wide use the default can be updated.

Gentoo has to work reasonably well without having to micro-manage python
versions.  Users shouldn't have to figure out what version of python
they want to run to do an install.


Re: [gentoo-dev] Re: Re: Maintainer notes in metadata.xml?

2010-12-01 Thread Richard Freeman
On 12/01/2010 01:16 PM, Diego Elio Pettenò wrote:
 Il giorno mer, 01/12/2010 alle 19.05 +0100, Thomas Kahle ha scritto:

 I agree, comments within the ebuild are practically invisible to
 archteams (at least to me for x86).  But also running repoman is
 the final step, right before committing.  The place for comments that
 need to be considered during archtesting would be right in the stable
 request bug. This is where I usually start.
 This is where I usually try to provide them; it's a bit more complex
 when users require the stable themselves, or when new developers are
 replacing the old ones.

Agreed on all points.  Ideal behavior is to provide comments in the bug.
 However, if that doesn't happen then this comment will give a warning
to the arch team before they inadvertently shoot themselves in the foot.


 If I do normal build tests first and then find they have been in vain
 when running repoman, then I wasted cycles for the build tests. I'm
 unsure if this would apply to your original example, though.

 I sincerely expect(ed) a repoman scan of the ebuild to be done after
 tweaking keywords to ensure all the deps are stable already, thus why I
 asked it to be printed on scan.

So, my typical stable workflow is:

Install package, after overriding keywords/etc in /etc/portage.
Test package and satisfy myself that it is OK.
From CVS tree, cvs update, ekeyword, echangelog, repoman manifest,
repoman scan, repoman commit.

All the testing typically takes place well before I've touched an ebuild
or run repoman.

However, I don't see this as a big deal.  Right now I shoot myself in
the foot and make a bunch of users upset if I don't know about something
when I stable a package.  The enhancement causes me to potentially waste
some of my time, but less than if I have a big mess to clean up.  The
ideal solution as all agree is to have the package maintainer point
things out in the STABLEREQ.


Re: [gentoo-dev] Changes in server profiles

2010-10-30 Thread Richard Freeman
On 10/30/2010 05:09 AM, Markos Chandras wrote:
 On Sat, Oct 30, 2010 at 10:05:17AM +0400, Peter Volkov wrote:
 В Птн, 29/10/2010 в 09:11 -0700, Alec Warner пишет:
 On Fri, Oct 29, 2010 at 5:21 AM, Markos Chandras hwoar...@gentoo.org 
 Can I install a machine with the server profile and USE=-ldap, but
 still get ldap + pam working?
 Can I install a machine with the server profile and USE=-apache, but
 still get apache + php working?  apache + rails?
 How many packages support each USE flag?
 How many of those packages have IUSE defaults for +ldap or +apache already?

 Having lxc/openvz/vserver technologies at hand it's not rare to split
 LAMP server into a number of virtual servers (containers): mysql /
 backend with php / frontend / smtp - everything sits in its own
 container. And USE=apache will be used only in _one_ container. Also not
 all servers are web servers. So IMO server profile should be just
 minimal profile that hints users that this profile will stay minimal and
 usable for all kinds of servers. That said I think server profile is
 useless and for servers I maintain my own profiles.


 Exactly! How about the warning message. Should the statement about
 gcc+glibc be removed and keep the one about hardened but make it a bit
 different?Like This profile is making use of a minimal set of use flag.
 You may find it useful in a server environment. However, If you are seeking
 for extra security, please check the Hardened project

What exactly is the intended use of the server flag?

When I want a minimal image, I usually just use the default profile.
That is pretty-much a bare-bones gentoo install.  I can see the use of
desktop, and I can see the use of hardened.  Right now server just looks
like default with random stuff for various kinds of servers added.

I could see if server had a different set of keywords and QA policy
(like debian stable), or if there were a set of use flags that would be
universally useful on a server and not on a desktop.

Right now it just seems like the server profile exists since lots of
other distros have server editions, so we should too.  If that is the
case, why not just point users to the default profile, or hardened?'

I'd be curious what the users of the server profile say.  If anything
they are the ones we should be listening to since they've found a use
for it.


Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree

2010-10-04 Thread Richard Freeman
On 10/04/2010 03:50 AM, Michael Haubenwallner wrote:
 So - would it make sense to split repoman into its own ebuild?


I always did wonder why the two have been part of the same project.
Repoman updates could probably be stabilized more quickly with so much
worry about impact on users at large.


Re: [gentoo-dev] Re: .la files and their future on Gentoo

2010-10-04 Thread Richard Freeman
On 10/03/2010 09:26 PM, Duncan wrote:
 The problem is that in-tree is a reasonably bounded set of builds, while 
 out-of-tree is unlimited.  Practically speaking, I simply don't see how 
 Gentoo can be concerned with out-of-tree in general.

If any other distro had that attitude Gentoo (and other source-based
distros) would be the only ones that provided packages for GCC, since no
other distro requires a functioning toolchain to install packages.

Libraries don't exist just to run packaged programs - they're also
needed to build new programs.  So, this is a use case that needs to be
considered.  Probably one of the reasons that Gentoo is popular among
developers is that it provides a very complete toolchain and libraries/etc.

That said, supporting this use case should not interfere with more
mainstream use of the distro.  I like the USE flag proposal because it
lets us have our cake and eat it too.  Those who don't need .la files
don't get them except where absolutely essential, and those who need and
are willing to live with tons of them can have it their way.

Gentoo is about choice...


Re: [gentoo-dev] .la files and their future on Gentoo

2010-10-03 Thread Richard Freeman
On 10/03/2010 07:53 AM, David Leverton wrote:
 Would it be too much trouble to have a standardised variable that
 means .la files should be kept?  It maybe /shouldn't/ be exposed as a
 USE flag because very few people will need it, but if it's easy to
 implement (maybe by having an eutils function to do the removal,
 checking the variable first) it would remove any objections I could

Such a solution would also have the virtue of allowing the use of USE
dependencies.  So, you would only install the .la files from a
particular library if another package actually needed them.  Packages
could also have USE defaults as seems logical to their maintainers and
distro policy.

Where this would get complex is if we want more than all-or-nothing
resolution.  The simplest USE approach would be to have it toggle all
the .la files in the package.  However, if you have 5 files that are
essential, and 5 that are likely nothing but trouble it will be harder
to manage that while still allowing full control.  I guess careful use
of local flags might work, in combination with some sane policy.  I'm
not sure if this is a use case that is even worth worrying about...


Re: [gentoo-dev] openrc stabilization update

2010-09-20 Thread Richard Freeman
On 09/20/2010 07:06 AM, Michał Górny wrote:
 I guess quite a good solution for now might be enabling newnet through
 an USE flag, being masked in the profile by default. That would satisfy
 the oldnet compatibility requirement for users, while the small group
 preferring newnet could still benefit from it.

This pretty-much guarantees that arch testers/etc will end up testing it
one way or the other, and not both.  That could lead to QA issues when
packages work fine for some users and not for others.

Granted, this is mainly a concern for lower-level network-config related

I'd hate to be the maintainer of an ebuild that needs to take into
account multiple network configuration options.

I still haven't heard a good reason as to why we need two.  I'm running
oldnet (baselayout-1), and changing to newnet would be a pain, but I
don't expect the distro to take this into account for my sake when
making decisions like this.  I'm sure people running newnet feel similarly.

The only argument I've heard for newnet is that it is more DHCP-friendly
or something like that (not that DHCP is required).  However, I've never
found getting DHCP to work particularly difficult - it practically comes
like that by default (just emerge dhcpcd and add the interface to your
init.d).  I imagine wireless might be more complex.

One argument I've heard against newnet is that you can't bring
individual interfaces up and down.  That sounds like a potential
drawback.  Granted, most of the sorts of things that I'd like to
conditionally bring up (vpn, ipv6 tunnel, etc) probably won't use the
network scripts anyway.


Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-26 Thread Richard Freeman

On 08/25/2010 08:29 PM, Duncan wrote:

But that was pretty much decided some time ago, based on my following of
the relevant discussions here and elsewhere, so why are you arguing a
point that's not being argued any more?  I believe that's what Mike's
WTFing about.  It's not that you're wrong, you're not, it's that you're
debating a question that's no longer being asked.


The post I replied to cited upstream issues as a reason not to adopt 
OpenRC.  My point is that upstream issues are not a distinguishing 
factor between OpenRC and baselayout-1.

It isn't like I'm re-opening a thread from months ago.  I'm replying 
directly to a point others have raised.

If there is no debate about whether OpenRC should be adopting it, then 
why is it even being discussed in this way?  Let's just do it...


Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-25 Thread Richard Freeman

On 08/24/2010 11:57 PM, Nathan Zachary wrote:

If we are going to endorse using OpenRC,
the more relevant issues are the ones regarding its future development.

Is the future development of OpenRC more problematic than the future 
development of baselayout-1?  As far as I can tell, baselayout-1 never 
had an upstream, and never will have one.

It seems like the debate is around openrc vs systemd or whatever.  I 
think the debate we need to settle first is openrc vs baselayout-1. 
Otherwise we're going to end up maintaining TWO different legacy init.d 
systems while we spend the next few years aiming for yet another target.

Wouldn't it make more sense to clean up openrc and get it deployed, even 
if in the long-term we decide to get rid of it?

Alternatively, we drop support for openrc entirely, and tell everybody 
running ~arch to move to our next target or back to baselayout-1.  I 
don't think we want to have three targets to maintain.


Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-25 Thread Richard Freeman

On 08/25/2010 03:06 PM, Mike Frysinger wrote:

On Wednesday, August 25, 2010 12:37:34 Richard Freeman wrote:

On 08/24/2010 11:57 PM, Nathan Zachary wrote:

If we are going to endorse using OpenRC,
the more relevant issues are the ones regarding its future development.

Is the future development of OpenRC more problematic than the future
development of baselayout-1?  As far as I can tell, baselayout-1 never
had an upstream, and never will have one.

wtf are you talking about ?  Gentoo was always been the upstream of it.

Uh, that was essentially my point...  :)

Clearly upstream support is not an issue that distinguishes openrc from 

Wouldn't it make more sense to clean up openrc and get it deployed, even
if in the long-term we decide to get rid of it?

it's already cleaned up.  this is the squash regressions from baselayout-1
and make sure all stable packages are happy with it phase.

And my point was essentially that we should finish doing that, and not 
bag the whole project because of the OpenRC upstream issues.  Sure, we 
can think about the next great thing that is coming along, but let's not 
abandon the work done so far, because doing so means living with 
baselayout-1 for another few more years.

I was just being a bit subtle in my argument...


Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

2010-08-24 Thread Richard Freeman

On 08/24/2010 08:57 AM, Thilo Bangert wrote:

given how long, so far, it has taken openrc to reach stable, it is no
wonder people start lobbying for systemd today. ;-)

Perhaps, but if we want to move in that direction perhaps we should 
consider at least getting openrc stable first.  That doesn't mean making 
it perfect, or feature-complete.  However, right now we have two 
different baselayouts, and if we start talking about systemd then we'll 
have three.  Do we really want to start on seriously supporting a third 
one, without first getting rid of one of the other two?

Alternatively we could dump openrc and move everybody back to 
baselayout-1, but I don't see that happening anytime soon.

Looking at the tracker bug, I see all of three issues blocking openrc 
from going stable.  One is documentation, one is getting an evms upgrade 
stable on a few minor archs, and one is some kind of mdadm upgrade with 
a few issues.

It seems like we should just make the next bugday OpenRC Cleanup Day 
or something like that.  Everybody can take 15 minutes to contribute to 
a wiki on getting started with openrc, or blog about it, or whatever. 
the docs team can glean the best of that and get the docs in order.  The 
evms/mdadm/arch maintainers could make a push to finish up, and others 
can help them with patches.

If we made a real push to get OpenRC stable I'm sure that those bugs 
would get taken care of quickly.  Right now I'm guessing that it just 
isn't on anybody's radar.

Or, is the situation with OpenRC less stable than is apparent in the 


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

2010-08-14 Thread Richard Freeman

On 08/14/2010 10:29 AM, Markos Chandras wrote:

So do I. Fixing your package and you don't even bother to send a *ready to go* 
upstream seems like a bit rude to me as well. Perhaps, we do have a complete
different point of view in this one.
Recent example is Chí-Thanh Christopher Nguyễn who thanked me for fixing his
package, asked me to attach the patch so *he* can send it upstream. I thought
that was the *default* policy. Anyway. I should talk to each maintainer
separately when I fix his package. Seems to me is the best approach

My two cents.  In my opinion, whether a commit is good or not depends on 
whether it left Gentoo as a whole in better or worse shape than before 
it was made.

Here it sounds like we had QA problems before the commit, and no QA 
problems after the commit.  Maybe the maintainer has some work to do 
now, but he had it to do anyway, and the maintainers have less work to 
do now than they did before the patches were made.

Now, if he had broken something due to a sloppy commit I'd be more 

Many hands make for lighter work.  The best way to have many hands is to 
make individual tasks easier.  1+1+1+1+1 is going to happen faster than 
3+2, since nobody ever gets around to doing 3.

If we give devs an ultimatum like fix it all or don't fix anything 
guess which one they'll pick?


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

2010-08-14 Thread Richard Freeman

On 08/14/2010 02:35 PM, Duncan wrote:

User perspective here...

For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.
Yes, it requires a rebuild, but the rebuilds will occur as the bugs are
fixed so it's a few at a time for people who keep reasonably updated
(every month or more frequently).  The alternative is triggering a several-
hundred-package rebuild when some base library package updates, because
all those LDFLAGS respecting changes weren't rev-bumped and the user's
installed set is still ignoring them, and thus --as-needed.

Interesting - I was looking at it in the opposite way.

Not having as-needed means that I /might/ have to rebuild that one 
package unnecessarily at some point in the future - if it isn't upgraded 
first for some other reason.

Rev-bumping the build means that I /will/ have to rebuild that one 
package for certain - right now.

I think we can all at least agree that this is a gray area as far as the 
INTENT of the (apparently unwritten) policy goes.

I would like to echo Markos's comment that having policies written down, 
if only to point stubborn maintainers to them, would be helpful.  The 
other reason to have them written is so that they go through some kind 
of review, and there is some way of challenging them if they no longer 
make sense.

In any case, I think we're making a pretty big deal about a pretty small 
issue - we can probably all afford to think about this a little more and 
move on...


Re: [gentoo-dev] Git Commit Procedures

2010-07-26 Thread Richard Freeman

On 07/26/2010 12:32 AM, Jeremy Olexa wrote:

On 07/24/2010 10:10 AM, Richard Freeman wrote:

I'm trying to make a correction to the devmanual (assuming this is
supposed to be general access) for bug 293629. However, I can't seem to
find where to clone the repository from.

See Git Repositories on http://sources.gentoo.org



Would this work for commits?  Assuming of course that I had rights to 

If this isn't supposed to be edited by devs at large, then somebody can
feel free to close that bug. It had been open for ages so I figured I
might just see if I could take care of it.

Attach a patch to bug. That repo is not open for anyone to commit to,
you have to be a member of the QA team, (or approval from Halcy0n or

Makes sense.  That would be the issue in this case.

My general point was that documentation in general around git is very 
vague, except for the overlays (which is still lacking, but there is 
enough info to at least be dangerous there).

Maybe a worked example with full command lines might be helpful - 
starting from scratch check out repository, change a file, and commit it 
to the official repository.  The info out there does require filling in 
a lot of blanks, and since git itself has no concept of a central 
repository there aren't a lot of examples of how to do this.  Such an 
example should of course factor in any Gentoo-isms as well (changelogs 
(if applicable), commit messages, etc - anything we ought to be doing).


[gentoo-dev] Git Commit Procedures

2010-07-24 Thread Richard Freeman
Are the procedures for using git with anything but an overlay on gentoo 
documented anywhere?

I'm trying to make a correction to the devmanual (assuming this is 
supposed to be general access) for bug 293629.  However, I can't seem to 
find where to clone the repository from.

If this isn't supposed to be edited by devs at large, then somebody can 
feel free to close that bug.  It had been open for ages so I figured I 
might just see if I could take care of it.

In general I think that before we can really consider any kind of 
migration to git we need to actually publish at least a little 
documentation around how it is to be used.  Sure, devs can read the 
various tutorials online, but what will Gentoo's policy be on putting 
branches in the official repository, and where should sources be checked 
out from, and what if anything do devs need to do besides a git push so 
that everybody doesn't get upset, etc.

It need not be 40 pages of documentation, but for something we're 
already using in an official capacity there should probably be at least 
a little documentation.  It exists for the overlays, although barely 
(just a bunch of commands without much explanation, and they are 
commands that would not be covered in any normal git tutorial).


Re: [gentoo-dev] Updated handbooks for autobuilds

2010-07-20 Thread Richard Freeman

On 07/20/2010 04:34 PM, Joshua Saddler wrote:

x86 and AMD64 have not had new stages or LiveCDs in months.
jmbsvicetto just started working on 'em, but we need LOTS of eyes and
fixers for our two biggest arches. Right now there's no one else.
Most of the breakages seem to come from toolchain and Python 3.x
build failures (because *someone* wanted it stable), but it needs

Is the process for creating these documented somewhere?  I did some 
googling and couldn't really find any documentation on how our stages 
and liveCDs are built in the first place.  There are some generic 
catalyst docs, but no real docs on how to generate an official build - 
that is one that would be identical (not necessarily bitwise) to what 
you'd find on the mirrors if they were up to date.


Re: [gentoo-dev] rfc: amateur radio applications should not be in media-radio

2010-07-14 Thread Richard Freeman

On 07/14/2010 03:16 PM, William Hubbs wrote:

I am an amateur radio operator as well, and that is why putting the ham radio
apps inmedia-radio bothers me.  Ham radio is not part of the media.

Most of the stuff in the media-* doesn't have anything to do with the 
media - whatever that is.

Media likely stands for multimedia - generally referring to anything 
that has to do with sound, graphics, video, etc.  I doubt that the 
jsmath font has anything to do with the media, but it is a font, and 
fonts have to do with graphics, and graphics are part of multimedia.

If we REALLY want to move I guess we can do so, but I don't think that 
the category was supposed to be suggestive of the news or entertainment 


Re: [gentoo-dev] Gentoo Council 14/7 introductory meeting

2010-07-13 Thread Richard Freeman

On 07/12/2010 10:18 PM, Paweł Hajdan, Jr. wrote:

Rationale: Meeting summary for 20091012 is to be completed. Meeting
summary for 20100419 is also to be completed, and all following
council meetings lack summaries. This makes it hard to follow the
council's work.

I've seen this at work quite a bit.  I've also seen an elegant solution 
that works moderately well.  The minutes of the meeting are taken in 
realtime during the meeting by whoever will take it, and this is shared 
with the participants in realtime.  This way errors in the minutes are 
instantly corrected.  When the meeting is done you just save and publish 
the minutes and you are done.

Realtime collaboration could involve any number of mechanisms.  I don't 
know if google docs supports it, but I imagine Wave would.  There might 
be other mechanisms as well.  Webex/GotoMeeting/etc are usually the 
methods employed in the business world.  There might be an FOSS equivalent.

I think this should be purely up to the council's discretion, but I 
wanted to offer this as a suggestion.

I'm not a fan of slacker marks in the first place - but, if you have to 
have them then I'd do it in a way so as to avoid creating a negative 
incentive for volunteering to do the work in the first place.


Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-27 Thread Richard Freeman

On 06/27/2010 06:52 AM, Enrico Weigelt wrote:

remark #981: operands are evaluated in unspecified order (tons of them)
   return strcmp( left.c_str(), right.c_str() )  0;

I'm not sure if this really qualifies an warning, since - AFAIK -
C spec never said, that there is an evaluation order for
function parameters.

I could see how somebody might make that assumption (incorrectly), and 
get burned by this.  However, creating local variables just to hold 
intermediate results so as to not embed them in function calls seems to 
be a lot of overhead - certainly in terms of readability, and I can't 
think of a situation where the compiler would have to do it on its own. 
 I guess religiously doing this might make the code less likely to 
contain very subtle bugs, but perhaps it is a bit over the top for 
anybody who wouldn't be otherwise developing in ADA.


Re: [gentoo-dev] Tone in Gentoo

2010-06-20 Thread Richard Freeman

On 06/19/2010 03:10 PM, Jorge Manuel B. S. Vicetto wrote:

I can assure you that if someone goes to #gentoo-forums and tries to
tell the forums team what tone should be used in that channel, we'll
kindly ask the person to stop or to leave. This is one of the public
and exposed channels and thus we have a tone with that in mind, but
we're not going to set our tone according to the demands of a developer
that is not even part of the team.

I was not suggesting that tone in Gentoo was up to the discretion of any 
individual developer - neither myself, nor you, nor the head of 
infra/forums/etc.  The tone in Gentoo is up to Gentoo.  Fortunately we 
have a forum for deciding what Gentoo wants - we elect them annually.

What would grant
any non-member of a team the right to demand how the members of the team
should act amongst themselves in their private room?

Simple - the room belongs to Gentoo as a whole.  You're certainly free 
not to listen to me, but I and others are free to point out that this 
isn't good for Gentoo.  I certainly wouldn't take it upon myself to 
enforce the CofC, but I certainly would urge those responsible for 
governing the distro to do so.

About the legal right, that isn't true. There are a few misconceptions
in your statement. Even though the Foundation is the body which holds
the Gentoo brand, trademarks and logo, it's not the Foundation that sets
the rules for joining and be part of the Gentoo Developers Community.
Furthermore, being a Gentoo developer doesn't mean you can join any team
you want or that you have a right to go to any #gentoo-* channel. In
case you have any doubt, I can give you a list of quite a few channels
most developers don't have access to.

Your statement is partially correct - obviously if I am a stockholder in 
Google I can't choose to just waltz onto the corporate campus and go 
around as I please, merely by virtue of being a shareholder.

However, a shareholder of Google certainly is able to speak out about 
actions within the company that they feel damage it, and their elected 
representatives (the board) can give power to anybody (including 
themselves) to waltz around and put things in order.  This starts with 
their authority to hire and fire the CEO at whim.

Ultimately, if anything contains the name Gentoo and represents itself 
as being associated with a linux distribution, then it is using a 
trademark owned by the Gentoo Foundation.  In the end, any use of Gentoo 
trademarks is completely at the discretion of the Foundation.

If you insist, to address the question that access lists for #gentoo-*
channels can be set by Freenode (our main IRC network), you should know
that the only people Freenode will listen to regarding that are the
members of the Freenode Gentoo Group Contacts. The people in that group
were not chosen by the Foundation nor do they respond to it.

Well, this is getting a bit silly, but they'd certainly answer to a 
cease and desist, or those hosting their servers certainly would.  It 
would obviously never come to that.  Go ahead and try to register 
#microsoft-press-releases and see if being named the official contact 
gets you anywhere.

Also, please never forget that being part of Gentoo is a privilege and
not a right.

On that we certainly agree.  It really wasn't my intention to suggest 
that somehow anybody was personally beholden to me.  I really am just 
stating my opinion, as are you.

As an example, even though I use my gentoo cloak online, you don't have
any right to impose a behaviour into me in my private channel.

Sure, I cannot, personally.  However, Gentoo certainly can.  At the very 
least I'd expect devs to generally conduct themselves in a manner where 
such things aren't necessary to even bring up.

We have a loosely-knit community that is able to provide a reasonable
product Gentoo Linux. Let's try to avoid killing it by wanting to
impose a certain mentality or behaviour into others and let's try to
respect each other and learn to live in a community.

Well, the whole principle of the CofC is that it imposes behaviors on 
those who wish to use Gentoo media, or be Gentoo staff.

That said, I really don't suggest that anybody need be heavy-handed. 
Nor do I suggest that my personal opinion should be the one that rules 
Gentoo (I would say the same regarding your opinion as well).  In the 
end that's all we're doing - you say that infra decides what happens on 
#gentoo-infra, and I say that they don't (well, not ultimately - 
certainly I'd suggest that the trustees/council should of course 
delegate channel moderation to the team that uses the channel, and only 
intervene if necessary).

What I would say is that I encourage those who are in the trustees and 
council to recognize the importance of this issue, and I ask that they 
consider that tone really does matter.  We elect these bodies to speak 
for Gentoo, and I think that this is an issue where Gentoo could stand 
to be heard.  

Re: [gentoo-dev] Tone in Gentoo

2010-06-19 Thread Richard Freeman

On 06/19/2010 01:06 PM, Jorge Manuel B. S. Vicetto wrote:

On 19-06-2010 16:15, Sebastian Pipping wrote:

#gentoo-infra is a channel on infra matters.
The fact that it's developers only doesn't make it a private channel in
a sense of tone doesn't matter.

you've failed to notice an important point that others have already
tried to convey to you - #gentoo-infra is the home of the Gentoo infra
team. Yes, developers go there to address infra issues on Gentoo, but it
is the infra team channel and not the channel of every Gentoo developer.

Perhaps he didn't fail to notice this point, but rather he just 
disagrees with it?

The fact is that #gentoo-infra is part of the Gentoo linux distribution. 
 It belongs to every Gentoo developer, or at least legally to every 
Gentoo foundation member.  Conduct on this channel reflects on all 
Gentoo developers.

It really does bother me that everybody is lining up to defend this kind 
of behavior.  If the response had been - sorry, I guess the joking got 
out of hand I'd say, ok, well, let's try to do better but let's all move 
on.  I don't see offensive behavior using Gentoo IDs/IRC Cloaks/media as 
a trivial matter.  It sets the overall tone of the distro, which is what 
this thread is all about.

I've heard several devs over the years comment that they love 
contributing to Gentoo, but they'd never put it on their resume.  Who 
can blame them?  I know that if I ever were hiring somebody and they 
pointed out that they were a Gentoo dev, I'd tend to assume that their 
technical knowledge was pretty good but you can be assured I'd do quite 
a bit of digging around to figure out if they're somebody I'd want 
working on my team.

Unless somebody is so good that you'd be fine if they were the only 
person working for you, then they're not too good to pass over.  Rest 
assured that if you hire and keep certain people, sooner or later they 
WILL be the only ones working for you...

I don't think that most Gentoo devs behave in this way.  I think a lot 
of people care about trying to fix this.  I don't think it is asking too 
much for Gentoo devs to try to keep their behavior reasonably 
professional when using Gentoo media, or Gentoo emails/cloaks/etc.

No need to start burning people at the stake for slip-ups, but let's at 
least try to agree that we'd like to be associated with a somewhat 
professional-acting distribution?


Re: [gentoo-dev] Tone in Gentoo

2010-06-19 Thread Richard Freeman

On 06/19/2010 06:54 AM, Ben de Groot wrote:

This is a point that deserves more consideration. One of the top
reasons (as witnessed in forum discussions) many people are not
getting more involved and volunteering to become developers is the
level of in-fighting and the ineffective way that bullies and other
poisonous people are being dealt with. Does Gentoo really prefer to
keep more sensitive people out instead of effectively getting rid of
repeat offenders?



We don't need one-strike-and-you're-out, but tone does matter.


Re: [gentoo-dev] Proposing fundamental changes to DevRel

2010-06-17 Thread Richard Freeman

On 06/16/2010 08:33 PM, Jorge Manuel B. S. Vicetto wrote:

On 17-06-2010 00:00, Sebastian Pipping wrote:

  3) Let Gentoo developers vote on who's in the conflict resolution
 team just like we do with the council.

AFAIK this never happened before and in my opinion choosing conflict
resolution members by popularity is a very bad idea.

Well, as long as the council remains the board of appeals and it is 
elected, I don't have a problem.

I'd also go a step further and say that devrel members serve at the 
pleasure of the council.  Some might debate that.


Re: [gentoo-dev] gentoo embedded reference accounts?

2010-05-29 Thread Richard Freeman

On 05/29/2010 01:54 PM, Joshua Saddler wrote:

D-Link routers, for example, run (or used to run) Gentoo. SRI's solar
probe, RAISE, ran Gentoo. The Misa Digital Guitar, just entering mass
production, runs Gentoo. There are many more places where Gentoo's
been used in various devices and production environments, so the PR,
GMN, and GWN archives are your friends, as well as searching Google
for Gentoo success stories.

When I think about pros/cons for Gentoo vs something else here are a few 
thoughts (some of which you may have already had):

Linux in general isn't the only OS used in embedded apps - there are 
other options like vxware/etc, which probably should be at least 
considered as well.  Advantages of linux in general would be familiarity 
and a very wide range of features.  A more purpose-driven OS might have 
the advantage of better realtime support and stability, as well as 
better vendor support (embedded is all that they do).

If you're going to run linux, then I'd consider Gentoo well up there - 
granted I'd strip out a lot of it before deploying it.  Gentoo has most 
of the flexibility of linux from scratch, but is FAR more maintainable 
if you plan to keep it updated.  The fact that you can mix and match 
just about any version of any library/etc is a big plus - it gives you 
more control over what you put on your device.  On the other hand, some 
other distros might give you better long-term-support if you're willing 
to live with the library versions they pick and how they build 
everything.  If your device goes on a network then it may need security 
patching, and that is generally safer if you have a vendor who will 
backport security fixes for 5+ years.  Something like RHEL has 
certifications/etc and more formal support, so you can hire people who 
probably know what they're doing.

Like anything you have to consider all the pros/cons.  If I were 
building something on my own dime in an embedded space I'd probably 
strongly consider Gentoo.

Of course, if you do use Gentoo unless you have a ton of storage you're 
going to want to strip out the toolchain, portage, etc.  You would use 
gentoo to maintain a development image, and then any time you want to 
you could copy that and then trim it way down (you could probably script 

Just some random thoughts.


Re: [gentoo-dev] bug wrangler queue is large...

2010-05-25 Thread Richard Freeman

On 05/25/2010 02:24 PM, Mike Frysinger wrote:

On Tuesday 18 May 2010 02:02:01 Andreas K. Huettel wrote:

could you please help the poor bug wranglers a bit?! The queue has reached
170 unassigned bugs...

people dont seem to realize that bug-wranglers isnt just for re-assigning to
the proper maintainer.  they are supposed to be doing basic triage, user
feedback, as well as cleaning up the bug.  i shouldnt be seeing bugs assigned
to maintainers that have ${PN}-1.ebuild as their subject, nor bugs that lack
basic things like `emerge --info` or build logs.

As long as the status quo works I don't think we need to change it. 
However if we are running into issues with keeping up it might make 
sense to just have wranglers do assignments to maintainers and let the 
maintainers deal with the rest.

The reason is that the maintainer might be able to spot dups much more 
readily, or spot obvious solutions to bugs, where a wrangler might be 
hunting around.

By all means wranglers should do what they can when they can, but keep 
in mind that if you yell at a wrangler any time they do it wrong a 
natural response of devs will be to not bother with bug wrangling or 
just looking for their own bugs in the list.

I'm not necessarily proposing any changes here, but in general we need 
to be careful about barriers to entry in projects that are undermanned.


Re: [gentoo-dev] Re: [gentoo-core] (infra) rsync updates and distfile fetching offline for next 12-18 hours.

2010-05-21 Thread Richard Freeman

On 05/20/2010 01:46 PM, Arun Raghavan wrote:

Why is gentoo-core is not enough? I thought all devs were expected to
follow -core, no exceptions made.

Well, unless something is sensitive it probably doesn't belong on -core. 
 In the spirit of openness we really should have very little traffic on 
-core (which happily is the case).

Now, if the announcement included somebody in infra's cell phone number 
of something as a contact then of course that would be -core material.

If you want all devs to get something -dev-announce is the right forum, 
unless it is sensitive.


Re: [gentoo-dev] Does anyone use the VERIFIED status in bugzilla?

2010-05-14 Thread Richard Freeman

On 05/14/2010 09:34 AM, Samuli Suominen wrote:

I'd like to see the whole thing go away. It's this one user I've pretty
much ever seen using it. And he's using it to change RESOLVED status
to VERIFIED on e.g. removal bugs, stabilization bugs, keywording bugs...

I think that VERIFIED could have a place in a serious quality management 
system that closes the loop on every change.  If we had a test branch 
and a release branch the VERIFIED might be the glue that moves patches 
from one to the other.

However, we don't have anything like this in place right now, and so 
this is really just spam.  Having the extra state does no good without 
all the processes that go with it.

Would Gentoo have a higher level of quality if we did some CMM-5 
practices like these?  Absolutely!  Would it struggle to keep up with 
Debian Stable?  Absolutely!   I don't think we really have the resources 
to pull off something like this.  As it is we struggle with the current 
~arch/arch system.

I'd get rid of it...

Re: [gentoo-dev] Re: Requiring two sets of eyes for all eclass commits

2010-04-25 Thread Richard Freeman

On 04/25/2010 07:36 AM, Ryan Hill wrote:

People make mistakes.

Agreed - at work I've often found a quality mindset that is 100% focused 
on preventing mistakes, and I've found that these kinds of systems are 
almost equally as focused on preventing them from being fixed (three 
minutes to fix a bug, three weeks to document and release the fix - then 
we wonder why the system has hundreds of trivial open bugs with no ROI 
for fixing them).

A good quality system isn't just about preventing mistakes - it needs to 
be about fixing them too.  The system that prevents typos from getting 
into the tree shouldn't get in the way of those typos being fixed. 
There needs to be a balance.

Scripts running on repository servers don't have a sense of balance, so 
they aren't the answer.  Nor is cutting off hands any time a dev messes 
up unless it becomes a pattern or there is malicious intent.

However, a systematic review process is probably a good thing most of 
the time, and published policies supporting this are a good thing.


Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

2010-04-13 Thread Richard Freeman

On 04/13/2010 12:33 PM, Matti Bickel wrote:

Alec Warner wrote:

Its not possible in perforce once your change has been submitted.

Oh, missed that one. Maybe that makes perforce more auditble or whatnot.

I suspect that is the gist of it.  I work with numerous systems that 
have audit trails that are subject to regulation, and it is pretty 
typical that the way to correct an audit trail entry is to add an 
additional audit trail entry (with the old entry still being there - 
perhaps with a pointer to the new entry).  There is no shame in 
admitting that you made a mistake - the kinds of people who audit these 
systems look at a lack of mistakes as evidence that something is being 


Re: [gentoo-dev] Who is willing to be lead?

2010-04-10 Thread Richard Freeman

On 04/10/2010 07:44 PM, Ben de Groot wrote:

On 11 April 2010 00:54, Denis Dupeyroncalc...@gentoo.org  wrote:

I know it hurts the eyes a bit, but calling problems by their name is
part of fixing them.

Except when someone else does it, then calling the problem of lack of
leadership suddenly becomes immature political ranting. Nice try.

You know, leadership can be as much about NOT replying to an email as 
replying to one...  :)

You don't need to be elected to the council to be a leader.  I'd say 
that with very few exceptions those who have been on the council were 
elected because a majority of devs recognize that they have been leaders.

I can certainly say that they have put in a lot more time than most 
reading this list, and it really isn't anybody's place to lecture them 
on being leaders as a result.  If somebody really thinks they have 
constructive advice then make it constructive, or at least send it in 
private to coun...@g.o.

If there is ANYBODY here who actually intends to lift a finger to 
actually do work to rectify these problems, by all means contact the 
appropriate project lead or the council or something and ask how to 
pitch in and help.  Based on Patteri's post it sounds like you can feel 
free to ping him on irc/email if you're looking for something to do.

And let's try to remember that we're all in it together - infighting 
isn't going to inspire more people to join the cause...


Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

2010-04-07 Thread Richard Freeman

On 04/07/2010 05:58 AM, Angelo Arrifano wrote:

3*) With git, one would just branch (lets call it embedded branch) the
package. Apply the patches there and let people using embedded profiles
to emerge from that branch instead of master.
Benefits? I think they are pretty obvious - people can start putting
quick patches in the tree for specific arches while not breaking others.

IMHO, the only bottleneck I see on Gentoo development is the massive
policy (not saying it is not needed) a -dev has to follow just to commit
a simple fix. Git my friends, will be our holly grail.

I think that allowing for different levels of QA standards, and 
accomodating things like this are good reasons to use branches. 
HOWEVER, we do need to manage this so that it doesn't get out of hand.

We really don't want users following 14 different branches and have 10 
different variations on every package in the tree - which is how it 
could get after a year or two of branching without any effort to do 
pruning and get things merged into a main tree.

Having branches to do development and facilitate access and testing 
seems fine, however we should always have the goal of getting these 
tested revisions merged back into the main tree.  We really don't want 
divergent development to be the norm.

Re: [gentoo-dev] Council meeting 19 April 2010

2010-04-07 Thread Richard Freeman

On 04/07/2010 11:00 AM, Denis Dupeyron wrote:

5. centralize developer documentation

This is an interesting idea which I believe I have seen discussed on
irc at some point. Feel free to work on a GLEP to address that.

To be honest, this doesn't even need a GLEP so much as a website or 
something.  If somebody consolidated all this stuff into a reasonable 
format, I bet that half the devs would pitch in and make their 
contributions.  The only thing that might warrant a GLEP is a policy 
decision that all development policies must be documented or linked from 
that site to be binding, or something like that.

I don't think that for the council to make a policy decision that there 
needs to be a GLEP.  Sure, it is the best way to make big changes, or 
changes that require some level of formality.  However, the council can 
still show leadership in affirming their agreement on issues even if it 
isn't a formal affair.  I'm sure every other town government in the 
Western World has taken a vote in support of their troops or something 
like that without going through the official lawmaking process and all 
that - it is just a gesture.

I don't have the time to create such a website although I would agree 
that it is sorely needed.  Hence, I will try to be careful in throwing 
around criticism - it is much easier to bring problems to the table than 


Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

2010-04-06 Thread Richard Freeman

On 04/05/2010 10:13 PM, Nirbheek Chauhan wrote:

* Proposed is to generate ChangeLogs from git commits on the rsync
server side when metadata generation is done
   - Scripts to do this already exist[1]

I haven't seen this discussed, so I'm going to toss this out there and duck:

Why not just get rid of the in-tree Changelogs entirely?  The scm logs 
already document this information, so why have it in a file?

It seems like the main purpose for it is for end-users to have some idea 
what changed in an ebuild.  However, in my experience the upstream 
changes are far more impactful than the ebuild changes, and those aren't 
in the Changelogs at all.

Instead, why not just create a script that gets distributed with portage 
that will upon request tell a user what changed based on the scm logs? 
I can't imagine that the hit on the servers will be all that large, and 
since this is read-only traffic it might be manageable through replication.


Re: [gentoo-dev] [Gentoo Phoenix] recruitment process

2010-04-05 Thread Richard Freeman

On 04/05/2010 03:48 AM, Ciaran McCreesh wrote:

On Mon, 05 Apr 2010 03:33:52 +0200
Tobias Heinleinkeytoas...@gentoo.org  wrote:

3) Questions that aren't that important at all and would just be nice
to know.
Examples for these:

5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
inside SRC_URI, DEPEND, etc?
[Devmanual, Caching]

How the heck is this not important? Anyone who doesn't immediately know
the answer to this has absolutely no business touching any ebuild that
might end up being given to someone else.

My concern with these kinds of questions is that there really isn't any 
page where we have key gotchas consolidated like don't execute external 
programs in global scope.  Sure, it is in the devmanual, and if you 
read the whole thing then maybe you might remember that one bit in 

I agree that somebody who doesn't know this particular fact shouldn't be 
committing ebuilds.  My concern is that we don't really have any way to 
make people aware of that particular fact.

Honestly, I think it would be just as effective to simply write up a 
single webpage with thou shalt not's, and not make people go hunting all 
over the place to figure out the whys.  By all means have a link on each 
thou shalt not to the reason.

There are lots of people who would be perfectly capable of doing many 
developer activities who might not come in knowing about the metadata 
cache.  They don't need to know the nuts and bolts of how it works, just 
what they need to do to avoid problems with it.

In any case, giving hints as to the location of the answer in this kind 
of a question seems fine to me.  The important thing is that the 
candidate dev learn about the potential problem - not that they figure 
it out 100% on their own.  Still, the socratic method is a good approach 
to teaching, so I'm not opposed to the QA format of the quiz in 
general.  We just need to let candidates know that we're there to help 
them succeed and the quiz is a tool - the goal isn't to eliminate any 
potential contributor who doesn't come to the table knowing as much 
about Gentoo as any seasoned dev.


Re: [gentoo-dev] Is Gentoo a Phoenix?

2010-04-05 Thread Richard Freeman

On 04/04/2010 02:09 PM, Denis Dupeyron wrote:

All ideas regarding improving recruitment are welcome, thanks. However
if, during your review, you were not given the impression that your
maturity and other social skills were being assessed then you were
being blissfully naive.  :o)

That actually wasn't what I was trying to convey (guess I need to work 
on those communications skills :) ).  I did recognize that you were 
looking to assess this, and that you felt that this was of critical 

What I was getting at is trying to identify what aspects of the whole 
recruitment process added the most value and which added the least, and 
adjusting accordingly.  I think that assessing attitude and maturity, 
and providing the tools and education needed are the most critical 
aspects of recruitment.

That's why I'm all for changing the approach to quizzes - from my 
experience it wasn't the quizzes themselves that really added the most 
value for me.  The interaction that they triggered and getting me to 
consider some of the more critical issues that come up in ebuild 
maintenance added far more value than getting every detail of the 
answers 100% correct.

The quizzes are just a tool - not the ultimate validators of ability. 
Let's use every tool at our disposal in the best way possible.


Re: [gentoo-dev] Is Gentoo a Phoenix?

2010-04-03 Thread Richard Freeman

On 04/03/2010 06:19 AM, Tobias Scherbaum wrote:

And still, when someone tries to fix things in such an understaffed herd
people go all territorial and are like omg u touched my package.
Right now I'm quite confused what our project strategy seems to be, as
far as I can tell there's one group aiming for an aesthetical optimum
and the other group just wants to get things fixed. And they are not
cooperating well ...

I for one can't say I had any territorial problems when touching
packages belonging to other devs or herds - it's just a problem if you
screw up.

Agreed - if you ping the herd in advance, and get an OK (or at least no 
reply for a few days), and then you make some simple fixes to their 
packages, it is very unlikely that you're going to have any complaints.

If you send the the proposed patch in advance and let them review it, 
and you get no complaints, you're even more clearly in the right.

If you don't notify them at all, or you notify them and do a cvs commit 
3 minutes later, or if you completely redesign their ebuilds in addition 
to fixing a 1-line problem, then you're going to get complaints.

Nobody minds help.  People do mind when somebody drops by to help them 
for 5 minutes and they're stuck with the aftermath.  We don't own our 
packages, but existing maintainers have at least shown a long-term 
commitment to them (however strong) and that should at least be respected.

On other topics in this thread:

I agree wholeheartedly that whenever possible just do it is a good 
approach - especially when you're talking about documentation and 
external websites/etc.  Modifications to things that already exist are 
less amenable to just do it.

I really think that the Gentoo recruitment process needs improvement. 
Right now it seems like a LOT of effort is required both to become a 
Gentoo dev and to help somebody become a Gentoo dev.  That means we have 
great people, but not many of them.

I think the problem is that our recruitment process uses the ability to 
answer complex technical and organizational questions as a way to assess 
maturity.  I think that maturity is far more important than technical 
skill in a distro - a mature person will recognize their own limitations 
and exercise due diligence when stepping outside of them.  Instead of 
playing 20 questions and going back and forth with recruits, maybe a 
better approach would be to cut down the questions dramatically (or more 
clearly put their answers in the documentation), and then use other 
approaches like references and interviews.  A new recruit might be given 
the names of 5 devs that they will need to interview with for 30-60 
minutes by phone or IRC (preference on phone), and they will need to 
submit references, who will be contacted.  When we hire people at work 
we don't play trivial pursuit with them, we use an interview to get a 
feel for what they're like and how they handle situations, and we screen 
resumes and references to determine experience.  I'm sure any of the 
professional linux distros would work in the same way, but perhaps 
somebody should ask around and see how it is done elsewhere.

So, now instead of a recruiter having to spend hours helping somebody 
through quizzes without giving them answers, instead they just send them 
a list of interviewers, and collate the results.  Any interviewer will 
just need to spend 30 minutes on an interview and 10 minutes on a 
writeup.  Plus, the whole process will make Gentoo a bit more human.


Re: [gentoo-dev] [RFC] Reworking package stabilization policies

2010-03-28 Thread Richard Freeman

On 03/28/2010 06:04 AM, Tomáš Chvátal wrote:

Basically you are saying that NONE tested that package on the arch until
the stablerequest. That's quite wrong and it should mean that the arch
should be ~ only, since they are stabling packages that they first
tested the day they stable them.

Well, keep in mind that if a package is marked ~arch, it is getting 
used, but for the most part it isn't getting used with other packages 
that are stable.  So, if your package is ~arch for a period of time that 
gives you strong evidence that it works with openrc, but no evidence as 
to whether it works with baselayout-1, which is what stable users have.

So, I would argue that for any package to be stabilized on an arch it 
should be tested on that arch on a stable platform.

amd64 has had the policy that any dev can stabilize if they've tested it 
on a stable amd64 system, and this hasn't really caused problems.

Perhaps we should encourage understaffed arch teams to recruit more arch 
testers if possible?  Then any dev could ask an arch tester to test on 
some platform that they don't have access to, and then stabilize 

For arch-neutral packages a more liberal policy might be possible, but 
keep in mind that the set of stable packages is not the same across 
archs.  So, unless you check carefully you might not be testing the same 
library dependency versions from one stable platform to another, and 
that could cause problems.


Re: [gentoo-dev] Re: List of User projects

2010-03-28 Thread Richard Freeman

On 03/28/2010 10:27 AM, Duncan wrote:

The point being, perhaps I'm wrong and openrc does have a broader
distribution basis than I'm aware of, but in practice, it seems all of
these tend to be used /almost/ exclusively with Gentoo and Gentoo based
distributions.  If openrc's usage is rather wider than I'm aware of, well
then, I'm about to learn that. =:^)

Well, I'm sure there is an openrc list somewhere that might be a better 
forum for these kinds of discussions, but I suspect that they need to 
walk before they run.  Right now openrc isn't even the stable init 
system for Gentoo.

I know that their goal was to be completely distro-neutral, and once it 
stabilizes we might see it happen.  It certainly would be very useful - 
it would standardize a ton of stuff across distros.


Re: [gentoo-dev] Python 3.1: Stabilization and news item

2010-03-25 Thread Richard Freeman

On 03/24/2010 11:47 PM, Joshua Saddler wrote:

Even then, it'll likely get
installed first, as users will probably learn about p.masking it only
*after* they install it.

I don't have strong feelings on whether having v3 installed by default 
is a big problem, but the last bit here probably should be addressed.

The current news item only shows up for people with python 3.1 already 
installed.  Would it make sense to have it show up for anybody with any 
version of python installed?  Otherwise it is news after-the-fact.


Re: [gentoo-dev] Python 3.1: Stabilization and news item

2010-03-24 Thread Richard Freeman

On 03/24/2010 02:28 PM, Joshua Saddler wrote:

On Wed, 24 Mar 2010 19:04:51 +0100 Arfrever Frehtes Taifersar
Arahesisarfre...@gentoo.org  wrote:

People, don't want Python 3, probably have already masked it. There
is no reason to waste Council's time for decision on what sentence
should be included in the news item.

Not the folks running the stable tree, because they don't know about
it. They're not following the discussion here on -dev. They're going
to get unpleasantly surprised when it shows up in their next world

Include instructions on how to mask it if desired in the news item.

Will not masking python-3 cause anything to break in any way?  Do users 
need to do anything to make python-2.6 or whatever the default 
interpreter (instructions for using eselect python are not given in the 
news item)?

If the only potential issue is that users might have a few extra files 
installed that they don't need but which won't cause them problems, then 
I don't know that we need to instruct users to create masks.

If having python-3 will cause stable users problems, then we probably 
shouldn't be stabilizing it anyway.

Compared to the KDE 3-4 migration this is probably going to be a fairly 
minor issue for most stable users, unless we're expecting breakage.


Re: [gentoo-dev] [RFC]: Proxy-maintainer project

2010-03-19 Thread Richard Freeman

On 03/18/2010 04:34 PM, Ben de Groot wrote:

Recruitment being the bottleneck that it is (with candidates
waiting many months), it is good to have another option
for people who want to contribute.

If we do have a list of people waiting to get in, could we maybe publish 
this list somewhere, or instruct these people to look for 
maintainer-wanted bugs and offer their services as proxy-maintainers? 
Can we have some way of communicating that one of these almost-devs has 
written some ebuilds so that devs can work with them to get them committed?

This would get them a head-start and will give them VERY practical 
instruction.  For the devs that work with them they'll know that they're 
working with somebody with a long-term interest.  I'm not sure that we 
want a policy that states that when the recruits become devs that they 
will maintain these packages long-term, but it would be nice if they did so.

Perhaps the devs could also provide feedback to the recruiters on the 
recruit's strong/weak points so that they could work on these.  (NOTE - 
I'm not suggesting marking people for exclusion here - if somebody is 
fairly raw we want to work with them, but it doesn't hurt for the 
recruiters to know about that up-front.)

I realized that some of these ideas are still half-baked, but I'm 
wondering if there isn't an opportunity here.


Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-11 Thread Richard Freeman

On 03/11/2010 03:53 PM, Alec Warner wrote:
 however if it becomes some kind of integral part of Gentoo

(which I doubt it will) we will have to look at switching to something
else (which is easy given the many export formats of Google Calendar

I think you hit the nail on the head.  Right now it isn't really getting 
used at all, and as you pointed out we can always transition it later.

Before we build out an uber-calendaring-application maybe we should just 
let the current calendar get some use, and then we can see how it goes. 
 Plus, our experiences with Google Calendar may come in handy when 
defining requirements for a pure-FOSS solution.

Of course, if somebody wants to setup something that is FOSS anyway, 
nobody is going to stop them.


Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Richard Freeman

On 03/10/2010 04:42 PM, Duncan wrote:

So a gmail account is now considered mandatory for Gentoo devs, at least
if they want calendar access?

What about those who might think that Google knows enough about them with
search and the web crawling and database correlation Google does, and
whatever ad serving might leak thru, and object to having a gmail account
on principle?

Honestly, Google calendar works well enough that I'm not sure that I 
like the idea of re-inventing the wheel.  Maybe if somebody designed 
some kind of open calendar access protocol that was comparable.

If you don't like Google tracking all that you do, create a gmail 
account and don't use it for ANYTHING but Google Calendar.  That will 
greatly limit the amount of database correlation they can do.

If somebody has a suggestion for a reasonable multi-user calendaring 
infrastructure that has reasonably close feature parity and isn't a bear 
to maintain I'm sure it would be considered.


Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

2010-03-06 Thread Richard Freeman

On 03/05/2010 08:06 AM, Ben de Groot wrote:

On 5 March 2010 04:18, Graham Murraygra...@gmurray.org.uk  wrote:

3.  Include one or both of the packages in the stage tarball.

None of the packages involved (gtk+, cups and poppler) is in any
shape or form essential, so you will have a very hard time convincing
people that this is the best solution.

I tend to agree, but do consider this:

1.  We wouldn't need to put all the packages in the dep list up to these 
packages in the tarball - you could just put one package in the tarball 
so that when emerge gets to this point it won't die.

2.  You don't need to put that package in @system, so the first time the 
user cleans out their install it will be removed.  For server users it 
will start out there but will eventually go away.

It does increase the size of the tarball, which is of course 
undesirable.  We might also need to modify the build scripts since I'm 
guessing those scripts look at @system to figure out what belongs in the 
tarball and these packages don't need to be there.

I do agree that it isn't really an ideal solution, and probably not the 
first thing we should try...


Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

2010-03-04 Thread Richard Freeman

On 03/04/2010 08:57 PM, Patrick Nagel wrote:

Obviously, users who re-install Gentoo the way you do will have less
difficulties resolving a circular dependency than those who are just following
the guide and getting their first Gentoo experience.

I think that the cups issue is probably worth mentioning in the 
Handbook.  Whether it is there by default or not lots of people get 
burned by it.  A little advanced warning would help.

I think that at the very least following the handbooks to the letter 
should never lead to an error.

I think that a good argument can be made for or against having cups in 
the desktop profile - this might actually be the sort of thing a survey 
would be useful to address.

I think that is separate from the circular dependency issue.  As long as 
we have an unresolved circular dependency I think cups should be off the 
list.  However, I'd be the first to agree that this is a short-term 

The problem is that we only have two long-term solutions so far:

1.  A smarter package manager that can work through these dependencies 

2.  Splitting packages like poppler that have these issues.

Both of these need effort to address.  #1 requires PM work, and #2 
requires an ongoing commitment to do more work to keep poppler working.

Unless somebody can come up with a #3 at this point the most 
constructive thing anybody can do is help out.  A good place to start 
would be to write up some patches to the handbook that clearly explain 
how to deal with this problem.

I'm not sure I agree with the poppler maintainers but they may have 
reasons that aren't apparent to me and the fact is that it is a whole 
lot easier to tell somebody how to maintain a package when I'm not the 
one actually doing the work.  Nothing gets results in FOSS like dirty 


Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

2010-03-03 Thread Richard Freeman

On 03/03/2010 09:41 PM, Dale wrote:

So in the situation above, removing cups doesn't help any? The user
would still have to work around the dependency problem. Is there not a
better way to handle this?

Agreed that there should be better ways of handling things.

However, at the very least if somebody follows the instructions in the 
Gentoo Handbook to the letter, they shouldn't end up staring at an error 
message.  A completely scripted install using any non-experimental 
profile should just work.

So, removing the use flag should probably be done at least in the interim.

That said, I do agree that we need to try to avoid this circular 
dependency in the first place.  It is kind of silly that you can't even 
do an emerge -u world right out of a stage3 using a fairly common set of 
use flags and get a working system.

Re: [gentoo-dev] Re: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption

2010-03-01 Thread Richard Freeman

On 03/01/2010 09:24 AM, Ben de Groot wrote:

The 72 hours have passed, so I take it we are ready to officially
publish this. Richard, are you going to commit this?

I will do so today.

Re: [gentoo-dev] Re: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption

2010-02-26 Thread Richard Freeman

On 02/26/2010 07:06 AM, Ben de Groot wrote:

Is there a simple way for users to determine what client versions they may have?

Forwarding my reply:

Well, they can always just ask the package manager what version is 
installed.  The news item is targeted only at users who do not already 
have mythtv 0.22 installed, so only potentially impacted users will get 
the announcement.  The guide includes instructions for determining 
whether a particular database has problems.

mythfrontend also has a --version option that returns some useful 

However, anybody getting the news item has a potential issue, and since 
mythtv isn't compatible across client versions if their gentoo install 
has a problem then all of their clients should need an upgrade.


Re: [gentoo-dev] Re: Pending mask of Qt3 and MythTV

2010-02-24 Thread Richard Freeman

On 02/24/2010 02:15 AM, Doug Goldstein wrote:

My response was the arch teams haven't stabilized MythTV in years
because none of them have a setup to test it, so please stabilize it.
I'm running it on a stable machine.

Well, to their credit, you CAN'T stabilize a package if you can't test
it.  I can test it and stabilize it on amd64, but that's it.  If there
is an arch that nobody has a mythtv setup for testing on then the
solution is to drop the stable keyword entirely - not to just mark it

As far as the news item goes, as I've said before. Its completely
unnecessary since MythTV will handle notifying you properly if you
need to do anything to your database. I can count more than a dozen
people on Gentoo that have successfully done the conversion without

Here is the problem I have with this:  doing the migration takes time.
Somebody who does an emerge -u world probably doesn't set aside an hour
or two to manually fix databases.  Anybody doing this for mythtv will at
best have a mythtv install that refuses to start until they spend time
doing database dumps, sed scripts, and reloads.  If for some reason the
mythbacked doesn't detect the problem and starts up anyway, then they'll
end up with partial database corruptions.

I think that if nothing else we should send out a news item warning
users that a major mythtv upgrade is coming and that they should
exercise care in upgrading it, setting aside time for database cleanup
if they are long-time users.  I'm completely open to revised wording,
but I don't feel comfortable stabilizing this for amd64 without any news
at all.

I do appreciate all you've done for mythtv, and the time crunch you are
in right now.  However, if I commit a keyword stabilization I need to be
accountable for the results.  I suspect the other arch teams feel
similarly - nobody wants to just commit something like this without
testing and good documentation.

How about this revised news item:

Title: MythTV 0.22 Upgrade Database Corruption
Author: Richard Freeman ri...@gentoo.org
Content-Type: text/plain
Posted: date
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: media-tv/mythtv-0.22

Due to an incompatibility between MythTV 0.21 and the default Gentoo 
MySQL configuration, it is likely that long-time MythTV users will have 
databases with a mixture of locale encodings.  If you upgrade to 0.22 
without following these directions carefully, you could end up with a 
database that contains errors that are extremely difficult to fix.

Note that not all mythtv users need to modify their databases, and this 
should only be performed at the time of the upgrade.  The guide below 
contains instructions that can be used to determine if this problem 
pertains to you.

Please see the MythTV Upgrade Guide for instructions:


Be sure to save a database backup before upgrading.  Also, be sure to
upgrade any other clients/backends you are using to 0.22 at the same 
time.  The upgrade instructions need to be followed once per database - 
individual client/backend upgrades do not require these steps.

If you do run into problems with your upgrade, there is a forum thread 
where you may be able to find help:


Re: [gentoo-dev] Pending mask of Qt3 and MythTV

2010-02-22 Thread Richard Freeman

On 02/22/2010 12:25 AM, Ben de Groot wrote:

If no action is taken soon, we see no other way than to protect the
users by masking the complete mythtv package. We hope this won't be

Agreed none of the options are nice.  The mythtv wiki isn't a bad 
resource, how about this for a news item (I can commit if there are no 
objections - and be gentle as I just parsed the GLEP - also posted to 
the bug 299222):

Title: MythTV 0.22 Upgrade Database Corruption
Author: Richard Freeman ri...@gentoo.org
Content-Type: text/plain
Posted: date
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: media-tv/mythtv-0.22

Due to an incompatibility between MythTV 0.21 and the default Gentoo 
MySQL configuration, it is likely that long-time MythTV users will have 
databases with a mixture of locale encodings.  If you upgrade to 0.22 
without following these directions carefully, you could end up with a 
database that contains errors that are extremely difficult to fix.

Please see the MythTV Upgrade Guide for instructions:


Be sure to save a database backup before upgrading.  Also, be sure to 
upgrade any other clients/backends you are using to 0.22 at the same 
time.  The upgrade instructions need to be followed once per database - 
individual client/backend upgrades do not require these steps.

Re: [gentoo-dev] News item: MySQL 5.1 bump

2010-02-21 Thread Richard Freeman

On 02/20/2010 09:23 PM, Robin H. Johnson wrote:

The MySQL 5.1 news item with all updates is now commited, and 5.1.x have
been unblocked in package.mask.

It looks like that news item is visible to users running stable as well. 
 When 5.1 eventually goes stable we might want to re-announce it since 
it may have been long forgotten by then...

Re: [gentoo-dev] emerge -C eselect-python disaster

2010-01-24 Thread Richard Freeman

On 01/24/2010 01:20 PM, Ben de Groot wrote:

2010/1/24 Petteri Rätybetelge...@gentoo.org:

On 01/24/2010 03:02 PM, Ben de Groot wrote:
Why should we keep redundant information in the list?

How is that redundant?

Well, I doubt we'll get away from python in the system set anytime soon, 
but imagine the results of having a policy that anything that is a 
dependency of something in system needs to be in system.

Now the system set is three times larger than it is now.  There is also 
no easy way to tell whether something is in the set simply because it is 
a dependency.  Then in the future if something is no longer a dependency 
it will be installed on every gentoo system unnecessarily.

Sure, we can clean things up every once in a while, and maybe even 
automate that, but what would be the point.

The whole reason we have dependency management in our package managers 
is so that you don't have to worry about details like what package 
requires what.  Package managers shouldn't make it trivial to 
accidentally remove a dependency in an unsafe manner


Re: [gentoo-dev] emerge -C eselect-python disaster

2010-01-24 Thread Richard Freeman

On 01/24/2010 07:02 PM, Dale wrote:

Is there something that I am missing here? For me, system should
include the things needed for booting and for the package manager to

It should include the programs directly involved in booting, and the
package manager.  I'm not sure that it should contain their dependencies
- since that information can be derived from the packages themselves.

As I pointed out in another reply, portage won't let you unmerge
itself but it will let you unmerge a package that will render portage

Well, it shouldn't allow you to unmerge anything that will render
ANYTHING useless without some explicit instruction to do so.

The documentation does warn of this behavior:

--unmerge (-C)
WARNING: This action can remove important packages! Removes  all 
matching packages.  This does no checking of dependencies, so it

may remove packages necessary for the proper operation  of your
system.  Its arguments can be atoms or ebuilds. For a dependency
aware version of --unmerge, use --depclean or --prune.

If you use --depclean to remove your package then you're safe.

Note - the command line option names are not well-chosen here.  -C 
should really be --unmerge-without-checking-dependencies-unsafe or some 
other obnoxious option, and --depclean should be the easy to type parameter.

Re: [gentoo-dev] Re: Last rites: net-nntp/inn

2010-01-17 Thread Richard Freeman

On 01/17/2010 03:20 PM, Thilo Bangert wrote:

Ben de Grootyng...@gentoo.org  said:

I think we have a bigger problem with packages that have a maintainer,
at least nominally, but said maintainer does not actually maintain the
package anymore.

full ack. i was thinking that maybe we need an 'easy-fix' team, which can
do all the easy fixes, which have been laying around for way too long and
which aparently are easy to fix (ie. only waiting for somebody to

I think this is a good idea.  Alternatively, perhaps if we just make a 
policy that it is acceptable for a dev to touch a package and leave it 
with QA problems, as long as it ends up with no more QA problems than it 
started with.  Of course, devs are encouraged to fix QA problems 
whenever they can.

This way devs will be more willing to make small fixes that generally 
improve the distro without being worried about being chewed out because 
they didn't go through the package with a fine-tooth comb looking for 

That will at least get poorly-maintained packages trending in the right 
direction.  Along with that I think we need to address the problem of 
packages that list a maintainer but which aren't maintained.

Perhaps a solution would be to have some way to periodically ping 
maintainers to confirm they're still looking at a package.  That could 
take many forms - a simple one would be to ask the maintainer to touch 
the metadata.xml file or something like that (obviously the manipulation 
has to be something that is noticed by CVS).  On the other hand we don't 
want needless churn.  Then an automated process can ping maintainers if 
they haven't done this, and after a delay the package would be set to 

Actively-maintained projects would be allowed to use automation to keep 
packages they track marked fresh.  However, the project does then become 
accountable for actually maintaining them.

This would go along with an (unwritten but already in place) policy that 
anybody listed as a maintainer has to actually maintain the package, 
with consequences for not doing so to some defined standard.  This 
standard would not be zero-bugs, but certainly anything real flagged by 
repoman or a violation of a written QA policy would be expected to be 
cleaned up in a timely manner.

The goal is to make the maintainer field meaningful.

Then we could figure out a policy for maintainer-wanted builds.  My 
feeling is that as long as they build, don't have security issues, and 
don't have QA issues that genuinely get in the way of some Gentoo 
initiative, they can stay around.  Once any of the above ceases to be 
the case they're announced on-list and then treecleaned.

The bottom line though is that we can write all the rules we want - 
ultimately Gentoo needs warm bodies to fix bugs.  No amount of process 
will get around that.  What process can do for us, however, is to 
increase visibility of issues so that QA doesn't waste time hunting down 
inactive devs and so that people running servers or whatever can tell if 
a package is actively maintained.

Re: [gentoo-dev] Re: Last rites: net-nntp/inn

2010-01-17 Thread Richard Freeman

On 01/17/2010 08:23 PM, Ben de Groot wrote:

What about something like: if a bug has been open for 2 months without
any apparent maintainer activity, anyone can step in and commit a fix?

How about - anybody at any time can at their discretion post a comment 
in a bug asking if there are objections to committing a fix.  If there 
is no reply from the maintainer/project/etc in two days go ahead and do 
it.  Do check devaway first to see if it makes sense to wait a little 
longer, and use discretion on the more critical packages.

Re: [gentoo-dev] Re: Last rites: net-nntp/inn

2010-01-13 Thread Richard Freeman

On 01/13/2010 09:24 AM, Mike Frysinger wrote:

On Tuesday 12 January 2010 15:51:28 Tomáš Chvátal wrote:

And since WE want to enable as-needed as default at some time we need to
work on the bugs

which isnt going to happen

This isn't really intended to point fingers at anybody in particular - I 
haven't personally investigated the complexity of fixing the as-needed 
issue for this particular package.

I think that logging as-needed bugs is certainly a value-add.

I think that tracking a blocker for as-needed is a value-add.

However, if we want to turn as-needed into a QA issue and try to enforce 
it, I think that this should really be run past the council and 
documented.  It wouldn't hurt to also document tips for solving the 
problem and the proper way to mask as-needed if it just isn't going to 
work (even if we make as-needed the default that doesn't mean that we 
can't mask it if we have to).

I think that devs should make good-faith efforts to fix as-needed 
issues, but if the problem is with the overall upstream design and major 
work is involved, that is an UPSTREAM problem.  Sure, it is nice if 
somebody wants to be an upstream contributor and fix their problems for 
them, but I'm not sure that it is worth the Gentoo resources in every 
single case.  Maybe for system packages or common dependencies we might 
push a little harder.

In any case, when this kind of controversy exists the best solution is 
to make a proposal and ask the council to render a decision.  It isn't 
productive to have battles on the mailing list about whether something 
should or shouldn't be policy.

I don't mean to suggest that QA or treecleaners or whatever absolutely 
must run everything they do past the council.  However, when we run into 
genuine disagreements between projects/herds/devs that is the ultimate 
escalation path.

Package mask is not a very good way to try to hit devs with a cluestick 
anyway - the main victims of this sort of approach tend to be the users.

Re: [gentoo-dev] Re: Last rites: net-nntp/inn

2010-01-13 Thread Richard Freeman

On 01/13/2010 10:06 AM, Arnaud Launay wrote:

which kind of explain what is a proxy maintainer (more or less),
but does not explain how to become one...

We don't really have any official process around this.  Things like 
sunrise and proxy-maintainers are good ways to get new blood into the 
contributor pool, however, and I think they'd be good things to look 
into.  Maybe I'll try to brainstorm some ideas of how to generate 
involvement (I'll post on -project if I come up with something).

Le Tue, Jan 12, 2010 at 09:49:10PM +0200, Markos Chandras a écrit:

If you feel like it, become a proxy-maintainer and poke a
developer to put your ebuilds on tree. Have you ever heard of that ? :)

No problem. Just tell me who I need to poke :) Would that be
antarus, saying hey, I'm mostly in servers, how may I be of
service ?

Yup - some kind of clearinghouse and communications tool wouldn't hurt. 
 You can always post in irc or a list and see if you get any takers. 
You can also post them in bugzilla under maintainer-wanted, but it 
doesn't get much visibility there.

Re: [gentoo-dev] Re: Last rites: net-nntp/inn

2010-01-12 Thread Richard Freeman

On 01/11/2010 10:43 PM, Jeremy Olexa wrote:

(A general reply, not targeted towards you, Rich)

No prob - my post wasn't really directed personally at anybody.

Speaking on behalf of the treecleaners:
The fact is, some of us have never heard of inn and until Gentoo has
some sort of popularity tracking software/tool, the treecleaners will
continue to mask unmaintained software.

Yikes - just goes to show how NNTP is starting to fade into the past.  :)

I'm not sure if it would cause undue overhead, but perhaps a solution 
would be to:

1.  Open a bug stating that the package will be discarded - assign to 
the maintainer.  This gives the maintainer a chance to wake up.  You can 
even do this without having to try to contact them first which might 
save you a step if you're doing that now.

2.  Periodically post a list of packages that have said bugs logged for 
more than two weeks on -dev-announce - reference the bug number.  That 
gives the community at large a chance to pick up the package.

3.  In another two weeks, if some dev hasn't stepped in to maintain, 
then mask as usual.  Don't announce this since anybody who cares should 
have CC'ed themselves on the bug.

4.  Of course, security issues / etc take priority and appropriate 
action is taken quickly (try to find a maintainer, but mask otherwise).

I'd think that if you tagged bugs appropriately you could largely 
automate #2 and #3 - just query for bugs over a certain age with a given 
keyword or whatever.

This would probably lengthen the time needed to get rid of a package, 
but it wouldn't really increase the work needed by too much.  You 
already announce on the list that you're masking packages - now you'd 
announce two weeks earlier and skip the announcement when the mask is made.

This is just a suggestion, but it does eliminate the need to try to make 
judgment calls about whether a given package is or isn't important.


Re: [gentoo-dev] Re: Last rites: net-nntp/inn

2010-01-12 Thread Richard Freeman

On 01/12/2010 01:30 PM, Markos Chandras wrote:

IMHO ( this is not a treecleaners@ opinion, i m just talking for my
self ), announcing and masking a package is a good way to inform and wake up
everybody to take care of this package if they really really want to stay on

I agree with the announce part, and the THREAT of masking.  I just don't 
think that the masking should happen at the same time as the announcement.

Having open bugs for months isn't a way to let everybody know that this
package is broken for long time, so it is a valid candidate for removal?
Should we send that via e-mail as well?

I don't think an open bug constitutes notice.  It is valid notice to the 
maintainer of the package, but not to the larger community.

I probably have 100-200 packages installed, and I'd probably be annoyed 
if any of them went away (I'm still missing kdirstat, but that isn't 
really the kde team's fault).  If an important one was about to go away 
I might step in to maintain it, and I'm sure a lot of other people feel 
the same way.  At the same time, I can't monitor the bugs on 100-200 
packages - that is the reason for having a maintainer.

I think the concern is that some maintainers don't respond in a timely 
manner.  Now, I don't know that maintainers have an obligation to fix 
every bug within a certain timeframe - some packages are problematic and 
I'm not sure that we should discard a 98% solution in favor of a 0% one 
because we don't have a 100% one.  However, serious issues should be in 
scope for treecleaners, but the first goal should be to find a 
maintainer, and only if that fails should we consider masking.

Also - if a maintainer can't be found we might also try to coordinate 
with the Sunrise folks to see if they're willing to take it over.

We should also solicit proxy-maintainers among the user community when 
we announce pending removals.  That could be very helpful with something 
like inn:  I use it VERY lightly and I'm not a news guru, but I am a 
dev.  I bet we have users who are news gurus and who care about inn, but 
they aren't Gentoo devs.  Together we could probably cover the gaps and 
I'm sure devs would be more willing to pick up a package if they knew 
they had some help with the nuances of the package itself.  If that 
falls apart later, at least an active dev is assigned to the package, 
and they can always decide to try to find a new maintainer or kill the 
package (saving treecleaners the work of doing so).

In short - treecleaners should be about getting packages back into the 
mainstream maintenance model, with removal being the fallback option if 
that doesn't work.  They shouldn't have to go out of their way to do 
this, but an advance announcement and some coordination is probably a 
good idea.


Re: [gentoo-dev] Re: Last rites: net-nntp/inn

2010-01-11 Thread Richard Freeman

On 01/11/2010 06:30 PM, Arnaud Launay wrote:

As a newsmaster, I'm a bit concerned by this.

Yeah, inn seems like a really high-profile package to mask for removal. 
 It would be conspicuous in its absence.

Would it make sense to post on -dev BEFORE masking packages like this? 
I'm sure there are lots of people who would chip in before something 
like this dies.

Right now lots of users are going to get errors due to a masked package 
until somebody takes the initiative to fix it.  I suspect that nobody 
wants to poke their head up and risk getting it shot off by doing 
something like that...

Perhaps Gentoo needs a little more of Wikipedia's Be Bold attitude and 
a little less of their delete first and ask questions later attitude.

Note - I'm not suggesting the problem shouldn't be fixed - I'm just 
suggesting that in this case the solution is worse than the original 


Re: [gentoo-dev] Non-free software in Gentoo

2010-01-08 Thread Richard Freeman

On 01/08/2010 12:26 AM, Greg KH wrote:

If the kernel loads a firmware
file that is not free, or if the device itself has a firmware in it that
you can not change so easily, has _nothing_ to do with the license of
the kernel,

I don't think anybody is concerned about the license of the kernel, 
but rather the license of sys-kernel/gentoo-sources.  Gentoo-sources 
contains the kernel as well as a bunch of other stuff (documentation, 
firmware, etc).  It can only have a single license if EVERYTHING 
installed by the package is usable under that single license.

The LICENSE in an ebuild pertains to the package - not just to the 
largest component or majority of the package.  Very few people install 
gentoo-sources mainly to read the docs or get a firmware blob, but they 
are still there, and the license should reflect this.

Re: [gentoo-dev] Non-free software in Gentoo

2010-01-07 Thread Richard Freeman

On 01/07/2010 01:19 AM, Vincent Launchbury wrote:

All I'm asking for is that users who care about this will be shown an
accurate license,

I think that this really sums this whole thing up.  Can you run a 
computer with ONLY FOSS on it (firmware to ROMs to hard drive 
controlers) - probably not, but maybe.  I think that is really a 
separate matter.

I think this really just boils down to this:  If we have a piece of 
metadata on a package it should be accurate.  The license should reflect 
the license of whatever ends up on a user's hard drive.  Maybe knowing 
the license isn't that important - in that case maybe we shouldn't track 
licenses at all.  However, if we're going to track the license, then it 
should be completely accurate (or at least we should aim for that even 
if Gentoo metadata can never be perfect).  That's why I also support 
having GPL2 vs GPL2+ / etc in the license field.  Sure, it won't be 
exactly right for a while, but it is worth shooting for.

Ditto for other metadata - homepages should be official, maintainers 
should be active, and all that.  QA will always have work to do as this 
will never be 100% right for everything in the tree, but there is value 
in being accurate anytime we can be.

By all means the default install should have an ACCEPT_LICENSE that is 
both legal and fully functional - if people want to trim it down that is 
up to them.  Maybe somebody wants to use Gentoo to build an appliance 
and they want to go pure non-copyleft - that's a major chore but we 
could still give them a great head-start on identifying where the issues 
with that are and at least getting them 80% of a functional system.

I think this whole thread really boils down to - make the license 
accurate.  What users do with it is up to them, and we don't need to 
support non-standard configurations just because we make them possible.

Re: [gentoo-dev] Some ideas on the licensing issue

2010-01-07 Thread Richard Freeman

On 01/07/2010 05:46 AM, Hanno Böck wrote:

I think the GPL-compatible set makes barely sense.


Difference between OSI and FSF approved: ... I think the definitions
of FSF and OSI are pretty much the same, ... So I'd like it much more
to have one big This is free and open source software set.


I think that we should make the license groups as objective as possible. 
 EVERYBODY can agree that such a license is or isn't OSI approved or 
FSF approved - whether they hate or love the FSF/etc.

By all means every gentoo dev is welcome to post on their blog if you 
want free and open source software put this in your ACCEPT_LICENSE - 
and everybody can post comments on the blog calling them the next saint 
of the Church of GNU, or the devil incarnate.  Let's just keep the 
portage tree to the facts.

Now groups that are fairly legally objective like 
redistributable-without-modification I think are useful.  They could 
be useful in doing QA checks on RESTRICT=mirror, for example.  However, 
let's try to stick with simple objective criteria that both people who 
hate a license and love it can agree on.

What bites me is the man-pages issue. Is it really the case that
there's no free (as in freedom) man-pages package? Maybe then we
should provide an option to install the base system without

I guess strictly-speaking man-pages aren't essential as part of system, 
but they'd seem like a big omission to leave out.  Unless we want a 
free-only profile (nobody seems to want to fully support this), I think 
that the better option is this:

Write up instructions on how to have a free gentoo install and put it on 
your blog or whatever.  If they've good enough maybe we can have the doc 
team make it official (gotta consider support issues here).

You can always stick the man-pages in package_provided or whatever so 
that portage doesn't try to install it.

You can also make your own profile, and post instructions for the world 
to see.  Again, break it and you get to keep the pieces and all that...

Re: [gentoo-dev] Re: Documentation licenses and license_groups

2010-01-06 Thread Richard Freeman

On 01/05/2010 01:07 PM, Duncan wrote:

Periodically there's talk of adding + versions of at least the FSF
licenses, but while it would probably be quite a good thing, it'd be a
LOT of VERY boring work poring thru all those packages and either
updating to the + version, or leaving comments in each one saying they'd
been checked already.

I think that this should at least be added.  If some things are more 
conservatively labeled as v2 when it should be v2+ it doesn't cause all 
that much harm.  Over time the licenses would get updated, and then we'd 
have more useful metadata.

The whole concept of GPL-compatible doesn't work when GPL2 isn't 
compatible with GPL3, and vice-versa, and all the way back to 1.  At 
best we can have GPL3-compatible or GPL2-compatible or whatever.  What 
happens when GPL4 comes out and we need to edit the group again?  What 
will that break?

Re: [gentoo-dev] Non-free software in Gentoo

2009-12-31 Thread Richard Freeman

On 12/30/2009 11:48 PM, Greg KH wrote:

Heh, no, it does not, unless your BIOS, and your keyboard firmware, and
your mouse firmware are all under a free license.  The only thing
close to this type of machine is the OLPC, and even then, I don't think
all the microcode for the box was ever released.

So it's a pointless effort.

Actually, you describe the futility of the effort, not the pointlessness 
of the effort.  The fact that an effort is difficult or even futile does 
not make it pointless.  Some might disagree about it being impossible as 
well (there are open-source BIOS implementations, for example).

I'm sure the people who have such philosophies try to run free software 
anytime that it is possible.  They might not be able to run free 
software on their microwave, but if one came out with an open-source 
firmware they'd probably try to buy it.  I don't see this as being 
inconsistent, just practical.  The fact that they can't buy an 
open-source toaster or mouse doesn't mean that they can't use an 
open-source kernel.

Hint, these firmware blobs do not run on your processor, so they have
nothing to do with the license of your system.

I'm not really sure where you're coming up with this argument.  The 
purpose of a license is to ALLOW you to do something you otherwise 
wouldn't be allowed to do.  Licenses don't actually take away rights, 
they grant them.  Laws do take away rights.  There is a law that says 
that if I write a program and give it to you, you can't copy it and give 
it to somebody else.  However, if I give you a license to copy the file 
under some conditions, then you can copy it legally if you follow those 
conditions.  Nowhere in copyright law is the word processor found or 
implied - the technology used to copy is also irrelevant except to the 
degree that it impacts fair use.

When you run software you aren't distributing it.  The concept of a 
use-license is a bit blurry - some people think that you don't need a 
license to use software, and other people think you do.  I don't believe 
that court rulings are as uniform on the topic of use as they are on the 
concept of copying.  In any case, the GPL v2 does not in any way attempt 
to restrict or grant the rights to use software - only to distribute it. 
 GPL v3 is a bit murkier in this regard, but irrelevant to a discussion 
on the kernel.

Again, no, the GPLv2 covers the license of all of the code you run in
the kernel package.

The concern isn't about RUNNING the software - it is about DISTRIBUTING 
the software.

And again, you do not run those firmware images on your processor, so
the point is moot.

Sure you do - you run them on your sound card processor, or your video 
capture card processor, or whatever.  However, the concern isn't running 
the software, it is redistributing it.

And note, _I_ placed those images in the kernel image, after consulting
lawyers about this issue, so it's not like I don't know what I am
talking about here.

Did they say that the GPLv2 applied to the entire tarball containing the 
firmware?  Or did they simply state that building/running kernels using 
the tarball was legal?

Nobody is saying that the presence of the proprietary bits violates the 
GPL (v1, v2, OR v3).  You're not doing anything illegal.

However, the tarball is not licensed under the GPLv2.  I can't modify 
that tarball at will, for example, and redistribute it.  If I modify 10 
bytes in the middle of one of those firmware blobs, reassemble the 
tarball, and post that on my website, I can be sued by the maker of that 
firmware blob.  I haven't violated the GPL in doing any of that - the 
problem is that the firmware blob isn't licensed under the GPL.

The license to redistribute the gentoo-sources tarball is NOT GPLv2 - it 
is GPLv2 for 98% of it, and a mix of other licenses for the rest.  I 
don't own a keyspan usb serial device, but that doesn't mean I can 
modify the usa28.fw file and put it in a kernel tarball on my website, 
as the license for that file SPECIFICALLY states that I'm not allowed to 
do this and it is copyrighted.  Doing this doesn't violate the GPL, but 
the GPL doesn't apply to this file.

The point of this thread is that the gentoo-sources package is 
mislabeled as GPLv2 when the entire package is not licensed under GPL 
v2.  Nobody is saying that it is illegal to distribute gentoo-sources, 
only that it cannot be entirely distributed solely under GPLv2.

Re: [gentoo-dev] Qt3 deprecation and removal policy

2009-12-31 Thread Richard Freeman

On 12/30/2009 12:14 PM, Ben de Groot wrote:


* Qt team meeting: discuss actions to be taken regarding remaining
pkgs that use qt:3


* mask qt:3 and depending ebuilds, pending removal

30 days isn't a long time.  How about filing bugs against anything that 
currently uses qt3 right away, so that maintainers have an extra three 
weeks to resolve these issues?  Granted, one would hope they've been 
paying attention.

As a random example, the current stable version of mythtv uses qt3, but 
I don't see any open bugs about that (that package is probably an easy 
fix as the newer versions use qt3support, and that version is already 
stable upstream).

Usually the approach in these situations is to have a big tracker bug 
for qt3 removal and a million blocker bugs against individual packages. 
 I'm not saying you can't move forward until everybody else gets their 
acts together, but tracking this in bugzilla probably isn't a bad move 
if it isn't too much work.  Plus, you might decide that one or two of 
the blockers really are critical, and decide to work with those 
maintainers more closely or escalate the issue.

Re: [gentoo-dev] Re: Qt3 deprecation and removal policy

2009-12-31 Thread Richard Freeman

On 12/31/2009 08:24 AM, Samuli Suominen wrote:

On 12/31/2009 03:13 PM, Christian Faulhammer wrote:


Samuli Suominenssuomi...@gentoo.org:

Just saying...

  Please track progress somehow.  I know it is a lot of work, but makes
understanding the process easier.


It's been done in,


That is for kdelibs-3.5 - not for qt-3.  However, it wouldn't shock me 
if the list is almost identical.  If the opinion of those with more 
knowledge of such things it that the one effectively covers the other I 
have no objections to not duplicating work...  If not maybe a tracker 
for any additional qt3 packages that aren't already tracked might not 
hurt, or we could lump them in together since from a work perspective 
they're almost the same.

Re: [gentoo-dev] Qt3 deprecation and removal policy

2009-12-31 Thread Richard Freeman

On 12/31/2009 07:51 AM, Samuli Suominen wrote:

Stable MythTV has more issues than just Qt3, as the current stable
doesn't compile anymore, http://bugs.gentoo.org/show_bug.cgi?id=280303
which is about to get masked tomorrow with kdelibs-3...

Those of us who run it wouldn't mind seeing a STABLEREQ if cardoe thinks 
it is ready...  :)  I've been thinking about taking the plunge anyway. 
A news item about the utf-8 issues might not hurt though as doing the 
upgrade right involves backups/etc.  The news item should be released 
BEFORE it goes stable.  That is, unless the upgrade process has become 
seamless now.

Re: [gentoo-dev] Non-free software in Gentoo

2009-12-30 Thread Richard Freeman

On 12/29/2009 07:52 PM, Greg KH wrote:

No, the readme/copying is correct, it covers all of the code that runs
on the processor as one body of work.  Firmware blobs are different in
that they do not run in the same processor, and can be of a different

Yes, but they don't cover everything in the tarball.  If I want to copy 
the tarball, then I need to comply with the distribution license of the 
tarball.  That license isn't clearly advertised.  It is a mix of a 
number of licenses from GPL v2 to allowed-to-copy-without-modifications.

The processor that the software runs on is fairly irrelevant.

In any case, I'm sure the kernel team will update the ebuild license 
string appropriately - this is more of a debate for the LKML.  I just 
don't think that they've done a good job with it.  Others are welcome to 
hold differing opinions.  :)

Re: [gentoo-dev] Why do packages which will not build remain in the distribution list?

2009-12-30 Thread Richard Freeman

On 12/30/2009 05:18 AM, Petteri Räty wrote:

You need to understand what the world set means. The world set is the
packages in /var/lib/portage/world and the sets from
/var/lib/portage/world_sets . From this follows that we can't change the
content of the world set as it's a user specific configuration issue.

Just to clarify a little (the above is completely accurate, but it might 
not be obvious how portage works just from reading this):

The world set is a list of every package that you've executed an emerge 
package command on, without a -1 on the command line.  So, if you type 
emerge xterm, then xterm is in your world set.  A package is removed 
from world if you uninstall it, or if you edit that file manually.

Packages that are installed because they are needed by packages that you 
install are not added to world, unless you later manually emerge them 
without a -1 on the command line.

The idea is that anything you explicitly ask for is something that 
portage will try to keep around for you, and anything you don't 
explicitly ask for is something that portage will try to get rid of if 
it isn't needed later.

So, those ruby packages ended up in world because you emerged them.  Any 
new version that goes stable/testing on those packages will consequently 
get pulled in by an emerge -u world.

The real issue (as was pointed out) is that packages shouldn't even be 
marked for testing (let alone stable) if they don't actually build, or 
if they have serious problems.  They should be masked, so that only 
those interested in developing/debugging the package get hit with it.

I don't want to comment on the packages you listed in particular, but 
sometimes you can run into build issues due to a need to run 
revdep-rebuild, or lafilefixer, or to rebuild some library.  I had an 
x86 chroot that absolutely refused to build imagemagick until I just 
reinstalled the whole thing from stage3 - probably some obscure 
library/compiler problem.  So a build error might not reflect a problem 
with the package you're trying to build.  Obviously we still try to 
avoid these kinds of issues and warn users when they are likely to happen.

I'd continue to follow the bug, and if it seems like something like this 
isn't being resolved expediently feel free to contact the QA team:


The QA team ensures that Gentoo quality policies are being followed and 
can poke maintainers or step in as appropriate.

Note that I haven't reviewed the packages/bugs that are being discussed 
here, so none of this is targeted at anybody in particular.  I'm just 
pointing out how things like this are supposed to work in general.


Re: [gentoo-dev] QA Documentation

2009-12-28 Thread Richard Freeman

On 12/28/2009 06:23 AM, Tomáš Chvátal wrote:

we should ENFORCE it, not just fill bugs about it, because mostly people
tend to ignore that things.

Agreed, although some presumption of innocence should be assumed.  If a 
dev is ignoring repoman output that is a fairly big violation, but if a 
dev missed that compiling under some strange set of circumstances or 
combination of use flags causes a problem, well, that's a bug that needs 
to be fixed.  There were some --as-needed issues detected by the 
tinderbox that only show up when you use a modified gcc profile, for 
example.  That doesn't mean they're not worth fixing, but we shouldn't 
punish people for that stuff.

I don't think the QA team has an issue with mistakes (not that I can 
really speak for them) - their main frustration is probably when bugs 
get filed and then get ignored.  Expecting people to resolve bugs in a 
week for minor issues is probably asking a bit much, but if a dev has 14 
packages with 25 open bugs each that are six months old that is probably 
a cause for concern that should be escalated to devrel.

On the other hand, some allowance for brain-dead upstream tactics should 
be made.  I'd consider embedded libraries a QA issue, but if we made 
that a stern policy we'd never see chromium in the tree for quite a long 
time.  I'm sure the guys maintaining that would love to try to patch out 
as much of the embedded stuff as they can, but they've got a LOT of work 
to do due to the way it was written.  I'm not sure that simply banning 
chromium from the tree is the right approach either as long as upstream 
deals with the inevitable security issues when they come up.

Re: [gentoo-dev] Non-free software in Gentoo

2009-12-28 Thread Richard Freeman

On 12/28/2009 01:56 PM, Robin H. Johnson wrote:

Actually, this is a case where the license on the ebuild is wrong, not
the license group. The kernel ebuilds should have GPL-2 and something
else, and by definition should not pass @FSF-APPROVED alone.

Is this appropriate?  The kernel sources indicate that they are licensed 
under GPLv2, and they make no mention of other licenses for any 
component of the sources.

Perhaps Linus/etc are wrong about this - but shouldn't that be something 
that people take up with them, unless Gentoo gets a letter from some 
lawyers claiming that we're infringing?

For that matter, for all we know kdelibs contains 10 lines of code from 
Jack Smith, who didn't agree to the LGPL and those 10 lines are under 
the Jack Smith Distribution License.  However, it would be best if Jack 
Smith were to take this up with the KDE team and not with every distro 
that uses KDE.

If Gentoo starts second-guessing the licenses on packages, do we then 
become liable if we fail to do this for a package?

Re: [gentoo-dev] Non-free software in Gentoo

2009-12-28 Thread Richard Freeman

On 12/28/2009 05:53 PM, Robin H. Johnson wrote:

You're wrong there. The kernel does contain additional licenses, and
EXPLICITLY mentions them. Go and read 'firmware/WHENCE'.

The licenses listed therein range from use-permitted only
no-modification, to GPL-compliant and BSD-like.

I stand corrected.  Somebody should tell Linus that his readme/copying 
is a bit misleading.  They really shouldn't bury licenses in subdirectories.

There is no second-guessing. What I am concerned with is that Gentoo's
statement of licensing does not accurately reflect what licenses are on
the package.

Agreed - I think the key is for the package maintainer to ensure the 
license is accurate, and if anybody notices a problem just file a bug. 
I think the kernel is a bit of an oddball since the sources are so large 
- most packages are much smaller and have a single license, and the 
maintainer will probably be familiar enough to sort it out.

[gentoo-dev] QA Documentation

2009-12-27 Thread Richard Freeman

Started new subject since this is only tangentially related to the election.

On 12/27/2009 06:16 PM, Tomáš Chvátal wrote:

Anyway, i wont write huge manifesto but these things i would like spent
my time:

QA propagation (motivating people, explaining why we are doing stuff and
so on)

Could this include documenting QA policies a bit better?  Some are 
documented in scattered docs, some are in the ebuild quiz answers (which 
of course no two developers have the exact same answers to, and they 
aren't anywhere you can point to for reference), and many are learned 
when QA files a bug on a package one maintains.

It would be really nice to just have a list somewhere that we could 
periodically look at and refresh our memories against.  Plus, some 
policies aren't always obvious or can be misinterpreted.

Don't get me wrong - the QA team is doing a great job and I love Diego's 
work on the tinderbox.  I've had a bug or two filed by them, and I've 
found that they've only been helpful when somebody actually bothers to 
try to resolve them.

Re: [gentoo-dev] metdata.dtd should require herd/

2009-12-24 Thread Richard Freeman

On 12/23/2009 01:36 PM, Paul de Vrieze wrote:

Perhaps we should create a schema to validate the file. XMLSchema (or
any of the other standards) allows for much more flexibility in
specifying these things. Btw. I did not design the metadata DTD for
order to be significant. The only priority is that maintainer goes
before herd, that's all.

I think we should definitely have some way of designating which should 
be the contact for bugs.  I've had some bugs sit around for a while 
without being noticed because they were assigned to the herd the package 
is in, and not to me personally, and I don't generally work with that 
herd, and the project associated with the herd doesn't generally 
maintain the package.

I'm sure there are many cases where a similar situation exists.

Another way to handle this is at least CC EVERYBODY in the metadata in 
new bugs, and not assume that copying the project will get all the 

Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date

2009-12-21 Thread Richard Freeman

On 12/21/2009 02:54 AM, Fabian Groffen wrote:

If all mail that would go to -dev-announce would guaranteed be sent to
-dev as well, I didn't have to check -dev-announce, and archives.g.o
would also have the original January 2010 meeting date mail in the
thread on -dev.

Or you could just subscribe to both and add this to your procmailrc:

:0 Wh: msgid.lock
| formail -D 8192 msgid.cache

:0 a:

Cross-posting in general tends to mess up threads, but there isn't much 
that can be done about that unless we just ban it.  However, most 
cross-posts are honest attempts to try to move list discussion to a 
place where it might better belong.

Honestly, list traffic is a lot better than it used to be, and I'm not 
sure that this is really a big problem these days.

Re: [gentoo-dev] Re: [gentoo-dev-announce] Election for the Gentoo Council empty seat

2009-12-21 Thread Richard Freeman

On 12/20/2009 01:04 PM, Jeremy Olexa wrote:

Flattered, but I decline. I don't agree with the way the Council works
and don't have motivation to attempt to change it.

Out of curiosity, would you care to elaborate?  I don't have much of a 
political axe to grind so I guess I tend to stay out of the politics...

Re: [gentoo-dev] Re: [gentoo-dev-announce] Election for the Gentoo Council empty seat

2009-12-21 Thread Richard Freeman

On 12/21/2009 06:33 AM, Richard Freeman wrote:

On 12/20/2009 01:04 PM, Jeremy Olexa wrote:

Flattered, but I decline. I don't agree with the way the Council works
and don't have motivation to attempt to change it.

Out of curiosity, would you care to elaborate? I don't have much of a
political axe to grind so I guess I tend to stay out of the politics...

Sorry - that was not meant to go to the list, although list-replies in 
-project might be appropriate if they are constructive...

Re: [gentoo-dev] CAcert certificate distribution license to third parties (i.e. distributors like gentoo)

2009-12-15 Thread Richard Freeman

On 12/15/2009 01:46 AM, Daniel Black wrote:

I did email the debian maintainer too. no response yet. They have interactive
builds though and I guess we do too now. Will be a royal pain if every
CA/software did the same thing.

The last thing gentoo needs is interactive builds.  XFree86 was forked 
over something less annoying than that (advertising clause)...

I'd rather put a disclaimer in the handbook that when you install gentoo 
you bear the consequences of anything you do with it: if you're in a 
jurisdiction where software licenses are binding on those who use 
software then be sure to set ACCEPT_LICENSE accordingly, and all users 
should monitor the outputs of their builds for important notices.

On that note, perhaps the default make.conf should send ELOGs to 
r...@localhost or something?  People can disable it if they don't like 
it, but I don't think we want our default to be that important notices 
are lost.

If legal experts feel that the only thing that will work would be an 
interactive build, then we should:

1.  Have the build by default terminate with an error that it requires 
some kind of acknowledgment.  Ideally have the package manager detect 
this condition at --pretend time.
2.  Have the user set this acknowledgment using an environment variable 
in make.conf (perhaps a setting for these purposes), or a local use 
flag, or some other one-time non-interactive mechanism.
3.  Have the build notice this and proceed normally (so the actual build 
and future upgrades are non-interactive).

4.  Ensure that this package is NOT required by anything in system, or 
installed by default by any major popular package (so maybe we have 
ca-certificates, and ca-certificates-annoying or something).

We definitely don't want the gentoo experience to be one of typing 
emerge world and then having to check back on it every three minutes to 
see what the latest prompt is.

I'm generally in favor of including CACert by default, but if they're 
going to shoot themselves in the foot over licensing then that is their 
loss.  I already have to install it manually for chromium (a real pita, 
btw).  I can't see the council voting to allow interactive builds for a 
certificate, and I really don't see why CACert is pushing this either...

Re: [gentoo-dev] CAcert certificate distribution license to third parties (i.e. distributors like gentoo)

2009-12-14 Thread Richard Freeman

On 12/13/2009 02:49 PM, Robin H. Johnson wrote:

On Sun, Dec 13, 2009 at 10:44:05PM +1100, Daniel Black wrote:

Recently this got produced as a draft license for parties distributing
CAcert's root certificate(s) (like us).

That's a pretty dense license. I can see why you had a headache.

I believe that in it's current form, we will have to make sure we have a
liability disclaimer to users for the license, but that should be about

First, I am not a lawyer.

The 3PV license does require that the user be presented with:

I'm not sure that simply posting the link in an einfo would satisfy the 
requirements.  We might need to post the full text to qualify as having 
presented it to the user - not sure about that.  I don't see anything in 
there that requires interaction though (hitting a yes button or anything 
like that).

The license itself is fairly short - we only need to post the NRP and 
not the 3PV license.  The 3PV is a license for Gentoo to distribute 
content to users under the NRP.  Users who don't redistribute the key 
don't need to worry about it.

An option would be to RESTRICT=mirror their root key, and install it 
directly from their site, assuming they don't start messing with the 
URL.  Then we can just put the license in the ebuild like any other. 
Since we don't redistribute anything copyrighted, Gentoo itself doesn't 
enter into any license agreement.

Only issue with that is that it is often bundled with a bunch of others 
and I don't know that you can restrict only one URL in the ebuild.

Re: [gentoo-dev] CAcert certificate distribution license to third parties (i.e. distributors like gentoo)

2009-12-14 Thread Richard Freeman

On 12/14/2009 03:10 PM, Robin H. Johnson wrote:

1.4  Vendor's Agreement with End-User
Vendor agrees
1. to distribute both the NRP-DaL and this present agreement to end-user,

Ah, this was my mistake.  I read that as to distribute both the NRP-DaL 
and present this agreement to [the] end-user,  Funny how swapping the 
order of two words changes an adjective to a verb...  :)

[gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting)

2009-11-30 Thread Richard Freeman

Antoni Grzymala wrote:

How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort
a year ago to summarize the then-current state of things regarding tree
and package signing, however the matter seems to have lain idle and
untouched for more than a year since.

One concern I have with the GLEP-57 is that it is a bit hazy on some of 
the implementation details, and the current implementation has some 

I go ahead and sign my commits.  However, when I do this I'm signing the 
WHOLE manifest.  So, if I stabilize foo-1.23-r5 on my arch, at best I've 
tested that one particular version of that package works fine for me. 
My signature applies to ALL versions of the package even though I 
haven't tested those.

Now, if we had an unbroken chain of custody then that wouldn't be a 
problem.  However, repoman commit doesn't enforce this and the manifest 
file doesn't really contain any indication of what packages are assured 
to what level of confidence.

If we want to sign manifests then the only way I see it actually 
providing real security benefits is if either:

1.  The distro does this in the background in some way in a secure 
manner (ensuring it happens 100% of the time).

2.  Every developer signs everything 100% of the time (make it a QA 

The instant you have a break in the signature chain you can potentially 
have a modification.  If somebody cares enough to check signatures, then 
they're going to care that the signature means something.  Otherwise it 
only protects against accidental modifications, and the hashes already 
provide pretty good protection against this.

Re: [gentoo-dev] QA is unimportant?

2009-11-09 Thread Richard Freeman

Peter Volkov wrote:

1. Our good non-formal policy if developer touched anything he becames
responsible for that ebuild and should fix issues noticed is sometimes
ignored. We see people reacting: you've noticed - you fix. I think such
attitude is unacceptable.

Keep in mind the downside to such a policy is that people just ignore 
problems that are trivial to fix, because they don't have the time to go 
over the ebuild with a fine-toothed comb.  Then, if people get their 
heads chewed off on -dev if they do miss something that lowers the 
motivation just a bit more.

Sure, if a dev fixes an ebuild they should give it a once-over to make 
sure there are no major problems, and obviously they should do moderate 
testing to make sure it builds and works.  However, if I spotted a minor 
problem with an ebuild that I could fix, and a major problem that I 
couldn't fix, chances are that I wouldn't touch it at all.  Then the 
ebuild stays in the tree with both problems, instead of one fewer.

I think it all boils down to we're all in this together.  If you see a 
problem try to fix it, and if you see somebody make a mistake try to 
help them out.While we do need policies, and policies do imply 
police, nobody likes the police, so let's try to make that work with the 
minimum in fuss.  A good rule of thumb is whether a dev has left a 
situation better off or worse off than when they touched something, and 
in this case I'd have to say that we're better off.

While the good can be the enemy of the best, sometimes the best can be 
the enemy of the good, and I think that sums up the current situation well.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

2009-11-08 Thread Richard Freeman

Petteri Räty wrote:

# starting to hate sf.net ...

The filename that violates our policies hasn't changed between the new
and old SRC_URI.

Is this policy actually written down someplace?  Sure, having the 
SRC_URI pick up the package version automatically is good practice and 
all, but does this actually rise to the level of a QA policy violation? 
 To me the word policy violation means more than just something that 
could have been done better.  It means that someplace there is an 
official rule in writing that wasn't followed, and that rule was 
endorsed by some official body recognized by gentoo.  I don't think 
quizzes can be considered policy since by design their answers aren't 
written anywhere.

The only downside to not being clever with the SRC_URI is that to bump 
the package you'd need to edit the URL.  That isn't exactly the end of 
the world, and while this is a trivial one to fix I've certainly seen a 
few that are quite messy to automate.

Now, if there were no version in the filename I'd consider that a policy 
issue as it would mean that the distfiles would get confused rather 
quickly.  However, not every lack of ideality is a policy violation 
worthy of a 30-post -dev thread.

Even so, it doesn't hurt to point out non-idealities so that they can be 
corrected.  Let's just try not to treat them the same as if somebody had 
keyworded something that breaks stable systems...

Re: [gentoo-dev] [RFC] Improve policy of stabilizations

2009-11-01 Thread Richard Freeman

Mart Raudsepp wrote:

Is it stated in any documentation that 30 days is a policy?

Not that I'm aware of - it is a guideline as you indicate.  However, 
don't expect anybody to actually take action on a STABLEREQ if there 
isn't some kind of rationale for going stable so quickly.

The whole point of stable is that they provide some sanity to the 
release process - if upstream releases a new version every other week 
then perhaps we should either:

1.  Question whether it should go stable at all.
2.  Pick a version once in a while and target it for stabilization, 
backporting fixes as needed.

We don't need to be Debian stable, but if the only reason for 
stabilizing a package is that upstream has already moved on, then I 
think we're making a mistake.  In fact, if upstream abandoned a release 
after only two weeks that would be a good reason NOT to stabilize it.

End users can always run ~arch if they need to - at least this way they 
know in advance what they're getting into.

Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME

2009-10-26 Thread Richard Freeman

Duncan wrote:
Actually, yes.  Gentoo has never been a hand-holding distribution.  We 
try to provide documentation and reasonable defaults for any apps the 
user chooses to install, and let the user configure what they will.

Gentoo is about choice.  Well, except for the choice to not have to 

I don't see why having some nice polished sets of use flags is a bad 
thing.  Personally, I find it a pain when I've emerged half of my system 
only to find out I left out some critical use flag (my use flags take up 
several lines now).  Sure, leave users a choice, but there is no harm in 
giving them some pointers.

Gentoo should be fully usable in a USE= state, but that doesn't mean 
that we need to make users start out from this point.

Re: [gentoo-dev] Init systems portage category

2009-10-12 Thread Richard Freeman

Jesús Guerrero wrote:

In my opinion, if we really want to speak about a way to implement that
kind of snapshoting, we should start thinking about providing a better
integration with lvm, from the root. lvm can take care of the snapshots on
a non-expensive way, and it would be relatively easy to implement. However
a lot of stuff would need to be re-documented, starting from the handbook,
and the init system.

LVM snapshotting is extremely wasteful - it has no knowledge of the 
underlying structure of a filesystem.  For example, if I moved all the 
files around on a fairly full ext3 filesystem, an LVM snapshot would 
consume the full size of the filesystem.  However, a filesystem-level 
solution wouldn't need to store a single byte of data since nothing 
actually changed.

Also - a snapshot restoration obliterates ALL data on the partition that 
has changed since the snapshot was taken - so unless the essential files 
are on a separate partition it won't work out well.

LVM snapshots really seem to be a solution to atomic backups - if you 
unmount, snapshot, and remount a filesystem then you can run a 
self-consistent backup off of the snapshot with minimal downtime.  The 
wasted space isn't a big deal since the snapshot would be deleted before 
it grew too far.

Finally - I'm not to eager to try out lvm2 again anytime soon - I lost a 
ton of data when something glitched and wiped out data across multiple 
lvm partitions.  I know that the error must have been in the lvm layer 
(not md or the filesystem), because when I fscked and repaired one 
filesystem, another filesystem instantly became hosed (on a separate lvm 
partition).  Somehow the partitions had gotten scrambled together and 
the fsck was crossing partition boundaries.  Plus, dmesg was dumping all 
kinds of compliants at the md layer about the lvm device trying to 
access out-of-range clusters.  Googling I found a few other reports of 
similar behavior - it seems extremely rare, but very nasty.

Fortunately the most important stuff on my PC was backed up (good 
planning), but it was still a pain - I lost tons of DVR recordings since 
I don't back that up (not worth the cost vs the value of the data).  Now 
I just run ext3 on top of md and I haven't had any problems.

You're right that btrfs will definitely help.  However, being able to 
create a personal stage1 tarball at will would certainly also be useful, 
and it wouldn't actually consume much disk space.

Re: [gentoo-dev] Anyone interested in maintaining the Gentoo Handbooks?

2009-10-04 Thread Richard Freeman

Joshua Saddler wrote:

On Sat, 3 Oct 2009 20:45:21 +0300 Markos Chandras
hwoar...@gentoo.org wrote:

This is actually true. Maybe all devs should have access on docs
since the docs teams are dead. I would suggest to let all
developers contribute to documentation whether they belong to docs
team or not

No. Many (most?) devs do not write good documentation. 


They don't know all the myriad documents that need editing to
pick up the change made to one part of a different document.

They say that the enemy of the great is the good, but I think that in 
this case the enemy of the good is the great.  Since many devs can't 
write excellent documentation the argument is that they shouldn't be 
permitted to write any documentation.

The problem with this is that some of our official documentation is just 
outright wrong.  Right now if somebody follows the docs they are 
guaranteed to end up with a non-functional system.  Suppose a dev edits 
those docs and fixes the version but doesn't completely clean up the 
accompanying text or misses some obscure cross-reference.  Well, maybe 
now a user has a 50% chance of getting it wrong - which is better than a 
100% chance of getting it wrong.  Others can then clean it up (such as 
the folks on the forums who get all kinds of feedback about these sorts 
of issues).

I'd be the first to agree that it would be better to just file a bug and 
let the doc team clean up the docs.  Perhaps this situation is just an 
anomoly, in which case we shouldn't be changing overall policy as a 
result.  However, if we have a resource bottleneck here then we need to 
do something to help clear it up.  That isn't meant to reflect poorly on 
anybody who is contributing to docs - you might be doing a wonderful job 
but unless we can find more of you then you're going to be playing 

The amd64 team ran into a similar issue which is why there is a policy 
that package maintainers are trusted to stabilize their own packages as 
long as they've tested them on the platform.  That doesn't mean that 
there aren't decent amd64 team members - only that there simply aren't 
enough of us to keep up with everything.

Re: [gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item

2009-10-02 Thread Richard Freeman

Rémi Cardona wrote:
May I request a faster commit time since I didn't expect Samuli to 
stabilize everything so quickly?

Yup - I wouldn't be surprised if within a few hours 80% of the concerned 
users will have already installed it.  Even if you send out the news now 
anybody who synced overnight wouldn't get it in time anyway.

Might not hurt to log a blocker bug just to track the news item the next 
time you consider a major upgrade like this.  Then you don't actually 
stabilize anything until AFTER the news goes out.  :)

Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Richard Freeman

Olivier Crête wrote:

~arch is for testing ebuilds, not the upstream package

I'm pretty sure this isn't the case - at least not as cleanly as you 
suggest.  Certainly testing the ebuilds themselves is part of the reason 
for having ~arch, but upstream readiness is part of it as well.  If a 
package hit ~arch and we got 10 serious bugs that were all upstream 
problems and then somebody filed a STABLEREQ I know that I wouldn't be 
the one to stabilize it.

The whole point of having QA is so that people who don't want to be 
bothered with bleeding-edge packages aren't bothered with them.  Masking 
is for packages with known serious problems, ~arch is for packages that 
we think are fine but don't have much production history with, and 
stable is for packages that are known to be decent with history.

However, I'm not convinced that the 3.1 issues need to be a showstopper 
for going stable.  Others have made some of these suggestions, but let 
me consolidate some ideas that have come up:

1.  A tracking bug should be created to track 3.1 stabilization issues 
(assuming it doesn't already exist).
2.  Portage (and other system packages) deps should be checked to ensure 
it pulls in the current version.  This should be carefully coordinated.
3.  -dev-announce message sent out to check your python deps and fix 
them (logging blockers as needed).  This need not be carefully coordinated.
4.  einfo message about not eselecting the new version of python.  News 
message as well.

As long as the current version doesn't go anywhere and the current 
version can be re-selected at-will, then I don't see how users can get 
themselves into a corner.

The ability to support stuff like this is the reason we have SLOTs in 
the first place.

Re: [gentoo-dev] EAPI and system packages

2009-09-20 Thread Richard Freeman

Ryan Hill wrote:

So, should we always keep a working EAPI 0 version around?  If not, when can
we drop support for old EAPIs?  Your opinions please.

You might want to define what you mean by dropping support for old 
EAPIs?  Do you mean:

1.  No longer ensuring that users who have pre-EAPI versions of portage 
have a clean upgrade path.


2.  No longer supporting EAPI=0/1 in package managers.

The former seems to be what we're talking about, but your question 
sounds like it is suggesting the latter.

If we want to drop support for EAPI=0/1 then EVERY package in portage 
needs to be updated to a more recent EAPI.  I suspect we're not there 
yet (at the very least all those system packages that are deliberately 
held back need to change).

I can see why package managers would benefit from fewer cases to 
support, however...

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

2009-09-13 Thread Richard Freeman

Jesús Guerrero wrote:

Most Gentoo users will have no problem to use overlays as they need
them. If we had more developers we could as maintain more packages,
as simple as that.

I actually tend to agree with this position, however to use overlays as 
a valid solution for end-users we need to do more to support them. 
Right now it is at least a little painful to get set up with an overlay. 
 There also isn't really any official place to vet overlays, and there 
isn't any official source for overlays that aren't maintained by gentoo.

Sure, overlays.g.o has tons of overlays - but which ones are 
mostly-stable, and which ones are intended to break systems?  What is 
the QA policy for each overlay?  If I'm an end-user not interested in 
breaking my system, what overlays are safe for me to use?

If we really want overlays to be an outlet to allow more non-devs to 
contribute, then there needs to be some way to standardize them.  Maybe 
a simple ratings system - an overlay needs to comply with one set of 
rules just to get listed on o.g.o.  If you want to be marked as stable, 
then you obey some additional rules.  And so on...

Then we can have overlays of various types for various purposes, and 
users can pick which ones they want to follow.  We could also have 
things like overlay groups - like stable or desktop or KDE / etc.

Maybe a fancy GUI to allow users to configure all of this.

Of course, for this to work somebody needs to develop it.  If somebody 
were willing to do the work I doubt anybody would get in their way.  It 
isn't like any of this would interfere with anybody who just wanted to 
make their own overlay without rules and not have it listed on some 
official site.

Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future

2009-09-13 Thread Richard Freeman

Jesús Guerrero wrote:

Yeah, devs for that as well.

Yup - I think we're actually on the same page.  Ultimately quality 
matters more than quantity and everybody does what they can given the 
resources we have.

Right now it is at least a little painful to get set up with an overlay.

No, it's a matter of using layman -a whatever

Sure, and that is fine if overlays are intended only as experimental 
development spaces.  However, some (not necessarily including yourself) 
advocate that it is perfectly fine that the portage tree gets stale 
since we have all those overlays.  That certainly is a possible approach 
to take, but to go that route overlays need to become more robust. 
Right now they're really not a replacement for /usr/portage.

There's no policy. Just like unofficial repos for any other distro.
We can't control that. It's outside Gentoo.

Exactly.  And, because it is outside of Gentoo - packages in overlays 
don't count when we consider how up-to-date Gentoo is.  If we want to 
say that package foo isn't stale because there are recent versions in 
some overlay, then Gentoo needs to take responsibility for the overlays. 
 That might be as simple as being a gatekeeper - auditing overlays and 
booting ones that drift out of control.

I don't think we can do any more with the number of developers we
have right now unless we start dumping blindingly and without any check
every ebuild that we get across.

Absolutely.  The whole logic behind going to an overlay-based approach 
is that it allows developers to leverage external help more effectively 
- a developer can essentially delegate a whole mini portage-tree to some 
other entity to manage, simply providing oversight and QA.  In theory 
you could even have official overlays - which would allow better 
delineation of responsibilities (you don't need to grant people commit 
access to everything - just their project's overlay).

Ultimately, as you argue, it doesn't make a difference if nobody is 
willing to step up and actually maintain ebuilds.

Personally, I like the overlay idea, but right now it just isn't 
necessary.  In theory proxy maintainers work almost as well, and we're 
not really making heavy use of this model right now.  If we had hundreds 
of users submitting high-quality ebuilds in bugzilla and simply couldn't 
find enough devs to commit them all, then a more overlay-based approach 
would help reduce the bottleneck of having a centralized group of 
committers.  Right now we probably have far more devs than proxy-devs, 
so the need to delegate the tree further really isn't there.

Re: [gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?

2009-07-03 Thread Richard Freeman

Luca Barbato wrote:

Jorge Manuel B. S. Vicetto wrote:

I have a few ideas about this that I'll have to put in writing and share
later, but let me start by proposing that for such a change we require
the support of at least 2/3 of the devs that vote *and* a minimum of 1/3
of all devs.

I'd use absolute majority even if it is more strict.

The only concern I have with these kinds of approaches is that right now 
we tend to be pretty liberal with allowing people to be devs even if 
they aren't heavily involved in gentoo.  As long as their commits are of 
sufficient quality that isn't a big deal.  However, it does allow the 
voting rolls to get pretty big with people that don't have a huge stake 
in the outcome of an election.

Organizations that tend to have supermajority policies tend to have 
other kinds of requirements on dues or activity, and they also tend to 
routinely clean out their rolls.  A supermajority policy might work fine 
if we also had a policy that a dev who fails to vote in two consecutive 
elections gets the boot.  I'm not sure that we really want that kind of 
a policy, however.

My feeling is that if you don't care enough to vote, you should have to 
live with the consequences.  Now, all elections of any kind should be 
announced well in advance, and should span a period of a few weeks (as 
they currently do).  If an issue is particularly critical and nobody can 
get around to voting for it in a 2 weeks span while there are hundreds 
of arguments raging in IRC and the lists, then I'm not sure we can take 
their silence as a vote of disapproval.

Re: [gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?

2009-07-02 Thread Richard Freeman

Doug Goldstein wrote:

On Wed, Jul 1, 2009 at 9:33 PM, Ned Luddso...@gentoo.org wrote:

Meetings will likely go back to one time per month and be +m with +v be
handed out per request with open chat pre/post meetings.  The reason for
this is to keep the meetings on-track. I won't engage in endless
discussions. Facts can be presented. They will be reviewed on merit,
technical and social.

Thank you again. I tried the +m/+v thing a year ago and received a few
pieces of hate e-mail from mostly non-developer people. 

Please do go to +m.  I usually just read council summaries - when I've 
tried to read the actual logs it is a COMPLETE mess.

In most organizational board-like bodies the board meeting is NOT the 
place to have open discussion on topics.  The open discussion happens 
everywhere BUT the board meeting.  It happens on the phone, on mailing 
lists, in newspapers, on TV, on talk radio, etc.  During the board 
meeting people who want to make a statement can do so within a limited 
amount of time, and then the board casts its vote.  95% of the time the 
way the vote will go is known before the meeting happens.  The meeting 
is just a formality.

If there is to be a 300 line argument over proposal-A vs proposal-B, do 
it on the mailing lists, or on IRC.  Council votes should be 
straightforward matters.

If we want to have more interaction - how about this idea:  Formal 
council meetings happen once per month, and they are the ONLY place 
votes take place.  However, the council will try to meet more often for 
less formal discussion.  +m/+v may be imposed at any time if there is a 
large turnout just to keep things somewhat orderly.  Attendance is not 
mandatory for these meetings, but is encouraged.  You could also 
schedule them at a variety of times - again, you're not missing any 
votes so if only 1/3rd of the council makes any particular meeting it 
isn't a big deal.

As far as having two council members temporarily approve items goes - it 
isn't a bad thing to have in general, but it should really only be used 
in emergency situations.  I'm not sure if we even need it - I suspect 
that groups like infra will do the right thing most of the time if 
there is an emergency (dev starts committing rm -rf /* scripts all 
over the portage tree - infra suspends cvs access first and finds devrel 

Maybe a quick way to assess developer opinions on issues would be forum 
polls?  The votify system is potentially good as well, but I'm not sure 
how much work it requires on the part of infra to gather/tally the 
votes.  We really don't need the full rigor of votify for most issues 
(though it probably should be used if there are true referendums on 
serious matters).  And, of course, there is always the measure the 
noise on the mailing list approach, but I'm not a big fan of that 
(though I am a fan of lists in general).

Re: [gentoo-dev] 2009 Council Elections

2009-06-26 Thread Richard Freeman

Ben de Groot wrote:

In my opinion it is in the best interest of Gentoo at this point to
ignore Exherbo and to silence those people involved with Exherbo that
have been so divisive and generated so much conflict in Gentoo channels.

Nobody needs to be silenced (unless they're litereally spamming the list 
- as close as cirianm comes to this his posts are at least relevant to 
the topic and even if I sometimes disagree with them and he could 
exercise restraint I don't think he should be banned).  I suspect most 
devs just avoid the drama.

I do echo the sentiment that the Gentoo council should be focused on 
Gentoo.  Sure, nothing wrong with cooperating with other projects and 
learning from them.  Certainly I don't want a not-invented-here 
attitude, and I think paludis has a lot to offer.

However, those who have questioned the wisdom of cirianm as a proxy do 
have a point.  Technical knowledge alone is not the critiera of a 
council member.  One needs to be able to build consensus - not that we 
need to be strangled by consensus, but we can't afford to rule by edict 

I'm happy that everybody seems to be getting along better, but council 
leadership requires maturity, and maturity is reflected by how people 
behave over the long haul.  Cirianm's best bet to get accepted by the 
gentoo devs is to just start working with them - if he works positively 
with enough different people (especially those with different opinions) 
he'll have no trouble gaining their support.  However, that is something 
that can take months or years - not weeks to a few months.  I might be 
willing to give him the benefit of the doubt, but that is just me.  I'm 
not so sure I'd be eager to have him be a proxy if I were on the 
council.  Sure, I'd be happy to yield my floor time to him if I thought 
he had something worth listening to, but a proxy is more than just a 
platform to talk - any mailing list subscriber already has that.

Re: [gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009

2009-06-19 Thread Richard Freeman

Nirbheek Chauhan wrote:

Please, do not waste everyone's time and bandwidth with thoughts that
do not belong on this list, and hence they do not care about.

Let's be nice.  Somehow I don't think Duncan's goal was to get the 
mailing lists to be as flame-filled as he perceives IRC to be...  :)

Agreed that just about everything but the original council summary in 
this thread (and I mean the first original one) probably belongs in 

Re: [gentoo-dev] Re: GLEP 55 Version 2

2009-06-07 Thread Richard Freeman

Ulrich Mueller wrote:

Let's assume for the moment that we change from .ebuild to .eb.
Then we obviously cannot change all ebuilds in the tree to .eb,
otherwise old Portage versions would see an empty tree and there would
be no upgrade path.

Or am I missing something?

That is a good point.  Although things would probably break more 
gracefully than having old portage versions attempting to parse new 
ebuilds (maybe, maybe not).

That actually makes me wonder - if we didn't change the extension at all 
could we somehow poison the portage tree so that old versions of portage 
would abort before doing anything dumb with a meaningful error message?

As far as an upgrade path goes - we could provide a one-time tarball 
that will update portage (and its essential dependencies) to a version 
that can get users out of this bind.  If a user has a system THAT old 
then they might just want to extract a stage1 tarball (manually - 
without overwriting /etc without care) and go from there.

I'm not sure that gentoo generally supports graceful upgrades from very 
ancient systems to modern ones without keeping up to date.  Other 
distros can do it since they do ~annual releases and users could just 
apply those sequentially.  For portage we don't keep around all the 
files needed to do a sequential upgrade like this - if a user were to 
try to upgrade to a 3-year-old version of some package most likely it 
wouldn't be mirrored and upstream might not have it either.

We obviously need to give some thought to not breaking old versions of 
portage, but given that portage will be only one of many problems if a 
user doesn't do an emerge -u world for 5 years I'm not sure we need a 
bulletproof solution...

Re: [gentoo-dev] Re: GLEP 55 Version 2

2009-06-07 Thread Richard Freeman

Patrick Lauer wrote:

And if you really absolutely have to do that you can change the sync
location on every disruptive change, but (imo) that should be

If mirroring and other practical concerns weren't an issue what you're 
essentially describing is just moving to a CVS/git/etc repository and 
using such a tool to do all the syncs (ie not using rsync at all).  Then 
all you need is an update page that has a list of commands like:

emerge --sync --date 2008-01-01

emerge -u world

emerge --sync --date 2008-08-10

Follow this xorg update doc: link

emerge --sync --date 2034-04-02

emerge -u portage so that you have support for the finally-approved glep55

And so on...  :)

That actually gives you a best-of-both-worlds option: continue to use 
rsync for normal use to ease distribution, but have a cvs tree that 
anybody can read from which could be used in upgrade guides for 
out-of-date users.

  1   2   3   >