Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

2006-06-11 Thread Luis Francisco Araujo

Patrick Lauer wrote:

On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
  

How exactly is it easier to manage a large number of ebuilds versus a
small number?


It is easier to manage one large overlay than managing 35 small overlays.
Communication overhead, duplication of effort, ...

  
How many people will manage the big overlay? , How many ebuilds will 
this overlay have? ,
now compare that to the amount of people maintaining the small overlays 
and their number

of ebuilds.

Which one is easier now?

Note: And i am omitting all that part of who are maintaining the 
ebuilds?, how they are maintaining them?,
what kind of ebuilds they are maintaining?, and many many other details 
that probably immediately kill
the assumption of a big overlay being easier than 35, 40, 90, 500 
smaller overlays.



--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

2006-06-11 Thread Kevin F. Quinn
On Sat, 10 Jun 2006 10:27:29 -0400
Chris Gianelloni [EMAIL PROTECTED] wrote:

[lots of good stuff - +lots Chris]

 Not so many moons ago, new ebuilds were submitted to bugzilla.  The
 bug wranglers would assign the bugs to the team most likely to end up
 as the maintainers, and new ebuilds either made it into the tree, or
 sat in bugzilla until the interest was there for it to be added, if
 ever.  Some people felt that this process left lots of packages in
 bugzilla, with no one to watch over them.  Because of this, the
 maintainer-wanted, and maintainer-needed bugzilla accounts were
 created to assist in tracking these bugs/packages.  This was a good
 idea at the time, and worked fairly well so long as there were
 developers going through and actively searching for bugs, that were
 no longer assigned to the relevant teams, but instead, assigned into
 some big dumping ground for new package requests.

I think it's clear that the maintainer-wanted/maintainer-needed hasn't
actually solved the problem it was trying to address. While it has
improved on some counts, I think the fact that herd maintainers
are not watching those aliases means that new builds are not being
brought to the attention of the devs most likely to take them on.

Instead of having sunrise on gentoo.org, which I agree with Chris is
fundamentally a bad idea, could we simply go back to assigning new
builds to the most relevant herd alias, but also add
maintainer-wanted/needed to the CC:?  That way some responsibility is
assigned to the herd to deal with it one way or another. If the
herd does not have the manpower to deal with it they can just reassign
to maintainer-needed and CC the herd, indicating they need someone
to join the group of herd maintainers to take the package on. With
maintainer-* on CC the benefits accrued so far from having a bunch of
people helping to iron out early QA problems would remain, and at the
same time the group of people most likely to pick up the package would
also be aware of it.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] i18n project

2006-06-11 Thread Peter Volkov (pva)
On Вск, 2006-06-11 at 02:16 +0200, Marius Mauch wrote:
 On Sat, 10 Jun 2006 15:11:50 +0200
 Jan Kundrát [EMAIL PROTECTED] wrote:
  b) Localization of Gentoo-developed applications (portage,
  gentoolkit,...) including their manpages
 
 I don't really like this one. Documentation, sure, but for the tools
 themselves I think it could cause more problems than actually help.

IIUYC there are tree problems with localized portage tools: 1) for users
such bug reports are hard to search 2) for devs it's hard to read
localized bug reports 3) Overtranslation for all it's hard to
understand. Right?

1,2): While generally I agree that output of build process should be in
C locale at least the following line should be translated on all
possible languages:
!!! If you need support, post the topmost build error, and the call
stack if relevant.

Everybody will benefit from translation of this message. ;)

3) Bad translation is just another bug that should be fixed. Nothing
in reality can be done without errors. But have this stoped anybody?

Peter.


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] i18n project

2006-06-11 Thread Nguyễn Thái Ngọc Duy

On 6/10/06, Jan Kundrát [EMAIL PROTECTED] wrote:

So, let's rephrase it a bit. The following items represent my view about
the i18n team's responsibilities:

a) Translation of metadata.xml stuff in our tree (Is there any method to
keep them up-to-date when the English text changes? Something like
revision attribute that gets bumped when the English text gets updated?)

Keep only English in metadata.xml. Using tools such as intltool or
xml2po to extract strings and let i18n translate/maintain .po files
themselves. Generated .mo files will be included in metadata directory
when rsycing. Another portage hack to use .mo files in metadata
directory instead of plain English if locale variables is not C.

But that's just part of the problem. What about strings inside ebuild?
--
Bi Cờ Lao

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Dealing with /var/cache on unmerge

2006-06-11 Thread Jakub Moc
Daniel Drake wrote:
 Mike Frysinger wrote:
 maybe give ebuilds a way to maintain a list of files that portage
 should nuke when unmerging the package ...
 
 Something similar to this would be useful for kernel ebuilds, as simply
 unmerging kernel source will leave a load of temporary and object files
 on the filesystem.
 
 Daniel

Already been there and got removed, because it broke emerge -e world for
ebuilds that need configured kernel to compile.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Perforce packages have been removed from the tree

2006-06-11 Thread Stuart Herbert

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Just a note that no-one took over maintainership of the perforce packages,
so I've removed them from the tree.

I've archived a copy in my personal overlay, just in case there are any
Gentoo users out there who'd like to help maintain them.  If you want to
help with them, come and talk to me on #gentoo-php or #gentoo-overlays.

Best regards,
Stu
- --
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
~   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEi+F1DC+AuvmvxXwRAgfTAKCglAXMlsbnmmiyoB1jZziYTveg7gCdGrWk
T/fX2xvlaygsJVtPUKpoNyg=
=w1ZG
-END PGP SIGNATURE-

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds

2006-06-11 Thread Jakub Moc
Donnie Berkholz wrote:
 Jakub Moc wrote:
 Olivier Crete wrote:
 Is there a recent list of non-ported packages ? Maybe we should do a
 last effort to port everything for a week or two and then package.mask
 the packages that no one cares enough about to port them.
 Hmmm, not a up2date one, AFAIK... There's a tracker bug

 http://bugs.gentoo.org/show_bug.cgi?id=112675

 and below is the most recent list from spyderous I was able to find (no
 idea how much relevant it still is).

 http://dev.gentoo.org/~spyderous/broken_modular/broken_modular.txt.20060315
 
 I can probably generate one tonight. Need to dig up the scripts, and
 I've got an emerge -e world running in the background.
 
 Thanks,
 Donnie

Donnie, pingy! ;) Just a friendly reminder to run the script again, so
that we can do a last attempt on fixing the remaining stuff before
resorting to more drastic solutions...

Thanks. ;)

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Dealing with /var/cache on unmerge

2006-06-11 Thread Mike Frysinger
On Sunday 11 June 2006 05:01, Jakub Moc wrote:
 Daniel Drake wrote:
  Mike Frysinger wrote:
  maybe give ebuilds a way to maintain a list of files that portage
  should nuke when unmerging the package ...
 
  Something similar to this would be useful for kernel ebuilds, as simply
  unmerging kernel source will leave a load of temporary and object files
  on the filesystem.

 Already been there and got removed, because it broke emerge -e world for
 ebuilds that need configured kernel to compile.

that isnt a bug

you cant assume the kernel sources that were just dropped into place match 
exactly the compiled objects in the same tree
-mike


pgpJwABwgWcmr.pgp
Description: PGP signature


Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Henrik Brix Andersen
On Sat, Jun 10, 2006 at 11:37:42AM -0400, Alec Warner wrote:
 Have the GWN posted to -core in a sane time period prior to it's 
 release.  I seriously doubt anyone cares about whether the publication 
 is always on time (whatever that may be).  If it's a bi-weekly 
 publication it doesn't always have to go out on the same day, as long as 
 you get it out in the general time period.  I sometimes respond with 
 corrections/additions but they never make it because it is released 
 before my mail is sent.  Often when I see the core mail I don't even 
 bother reading it since by looking at the timestamp I can guess it's 
 already been mailed.

That's one of he things that keeps me away from contributing anything
to the GWN. Whenever I've sent something to the feedback address or
replied to a draft GWN with corrections, I've never heard back nor
have my corrections been made or rejected with a reason.

If the GWN wants to be that independent I wont stand in their
way. But I do agree with Christel that the GWN today is only a shadow
of what it used to be.

Regards,
Brix
-- 
Henrik Brix Andersen [EMAIL PROTECTED]
Gentoo Metadistribution | Mobile computing herd


pgpw7Y85R8IH7.pgp
Description: PGP signature


Re: [gentoo-dev] Project Sunrise -- Proposal

2006-06-11 Thread Henrik Brix Andersen
On Sat, Jun 10, 2006 at 01:37:15PM +0200, Markus Ullmann wrote:
 Okay, so after figuring out open problems (thanks to kloeri and various
 other people for help here), we now have a resolution that should
 satisfy all involved parties here. This should adress dostrow's demands
 as well.

While I do think this proposal is much better than the previous
non-existing proposal, it still doesn't address the problem of having
the sunrise overlay hosted on a non *.gentoo.org address to make it
100% clear to the public that it is unsupported.

Regards,
Brix
-- 
Henrik Brix Andersen [EMAIL PROTECTED]
Gentoo Metadistribution | Mobile computing herd


pgpf03IBTNUlw.pgp
Description: PGP signature


Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Josh Saddler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
 On Sun, 11 Jun 2006 01:00:43 +0200
 Patrick Lauer [EMAIL PROTECTED] wrote:
 
 On Sat, 2006-06-10 at 11:37 -0400, Alec Warner wrote:
 Have the GWN posted to -core in a sane time period prior to it's 
 release.  I seriously doubt anyone cares about whether the
 publication is always on time (whatever that may be). 
 So what would a sane time period be? 12h? 24h?
 The problem with that is that you need an editor who is available
 during this period to add corrections, but with the new influx of
 helpers I think we can manage.
 
 It should be sent *at least* 24 hours in advance IMO so everyone gets
 a chance to check it. Better to send news that's a few days old than to
 send incorrect news.

Agreed. A full day in advance helps ensure that any needed corrections or
additions can make it in.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEi/aQrsJQqN81j74RAu9PAKCFkXjY1/u1s4Xk2y2z8m0RdTwHwACcCm4W
RRtsFocJpavIee8jaZpnnWM=
=vBld
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Project Sunrise -- Proposal

2006-06-11 Thread Jakub Moc
Henrik Brix Andersen wrote:
 On Sat, Jun 10, 2006 at 01:37:15PM +0200, Markus Ullmann wrote:
 Okay, so after figuring out open problems (thanks to kloeri and various
 other people for help here), we now have a resolution that should
 satisfy all involved parties here. This should adress dostrow's demands
 as well.
 
 While I do think this proposal is much better than the previous
 non-existing proposal, it still doesn't address the problem of having
 the sunrise overlay hosted on a non *.gentoo.org address to make it
 100% clear to the public that it is unsupported.
 
 Regards,
 Brix

So, move it to this.is.unsupported.and.will.blow.your.box.gentoo.org if
you feel it will help anybody. I feel it's completely irrelevant, but
that's just me.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

2006-06-11 Thread Josh Saddler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Gianelloni wrote:
 [. . .]

Right on! :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEi/j4rsJQqN81j74RAsRHAKCJsN09KKGlLq5CD4Bh/7r9QYJ12QCgnFx1
lRWrDI1euePCP0MrwoP/Emg=
=G9qu
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] i18n project

2006-06-11 Thread Jan Kundrát
Marius Mauch wrote:
 genone and my point is that users often don't even realize that
 their post contains non-english text

Make Portage add a line with Some of the previous errors were reported
in non-English language. If you want to get support from official
channel, please run `LC_ALL=C command`. when it detects a non-English
locale.

 Basically I don't think the benefit is rather dubious or maybe it's
 just that I had some rather bad experiences with translated versions of
 FOSS applications, but I'm quite opposed to this part of the project
 unless you have a way to remove my concerns.

Sure, translating GCC output is *not* good, but why don't provide
localized version of Portage messages like, for example, those when
Portage complains about unsatisfied dependency?

Cheers,
-jkt

-- 
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] i18n project

2006-06-11 Thread Jan Kundrát
Peter Volkov (pva) wrote:
 On Сбт, 2006-06-10 at 15:11 +0200, Jan Kundrát wrote:
 a) Translation of metadata.xml stuff in our tree (Is there any method to
 keep them up-to-date when the English text changes? Something like
 revision attribute that gets bumped when the English text gets updated?)
 
 While we do not have version or revision attribute, just drop all
 translations whenever you update English.

Re-adding them again and checking RCS history seems like unnecessary
work to me.

 c) l10n for other packages and sending patches upstream
 d) Translation of manpages. man-pages-cs for example sucks :(.
 
 Do we really need to do this inside Gentoo i18n project? This tasks are
 common for many distributions and should be done outside Gentoo. So just
 translate and send translations upstream.

Nope, that wouldn't be the primary job of the i18n team, just some kind
of task that they might do when they'd be idling otherwise :)

 Fex, to increase the profit from translated GWN
 translated versions should come out together with English one.

Tricky or even impossible one, considering the current time schedule.

 Personally I do not like idea to look at web for package documentation.
 There already exist decision to put all example files somewhere
 into /usr/share. I hope one day this happens and then all translated
 configuration files also can be put there.

While the comments in configuration files are certainly very useful, I
am persuaded that they shouldn't contain more information than the docs
available somewhere else. It's quite common for an administrator to work
on a remote box, possibly with a crappy network connection, and browsing
some doc over web is easier than launching yet another links session
under screen.

Cheers,
-jkt

-- 
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] i18n project

2006-06-11 Thread Jan Kundrát
Nguyễn Thái Ngọc Duy wrote:
 Keep only English in metadata.xml. Using tools such as intltool or
 xml2po to extract strings and let i18n translate/maintain .po files
 themselves. Generated .mo files will be included in metadata directory
 when rsycing. Another portage hack to use .mo files in metadata
 directory instead of plain English if locale variables is not C.

That would require external tools to support Yet Another Method of
Retrieving Metadata which is a Bad Thing (tm).

Cheers,
-jkt

-- 
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification

2006-06-11 Thread Christian Birchinger
On Fri, Jun 09, 2006 at 02:04:57PM +0200, Stefan Schweizer wrote:

 svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application;
 emerge application
 

As long as it's made for pulling single ebuilds (and their
support files), i think it's really helpfull.

It's exactly the same as downloading single ebuilds from
Bugzilla just without the pain of using bugzilla for it.
While Bugzilla is fine for handling bugs, i think it's
annoying to use for maintaining and downloading ebuilds.

The danger of people breaking something is exactly the
same though. I don't see a difference between downloading
an ebuild with bugzilla and fetching them with svn.

What i would fear is a full overlay with eclasses and many
other things the user didn't cherry pick.

I would mostly like a method to easily add external ebuilds
to my own overlay.
When that source allows people to maintain their ebuilds in
a simple way, it's also better. Raising the annoyance bar
for handling ebuilds doesn't increase their quality.


Christian
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-11 Thread Kevin F. Quinn
On Sun, 11 Jun 2006 07:33:19 -0400
Peter [EMAIL PROTECTED] wrote:

 On Sat, 10 Jun 2006 13:37:15 +0200, Markus Ullmann wrote:
 
  1) m-w / m-n requirement
  
  Only ebuilds that are reported to bugzie (valid bug#) and set to
  maintainer-wanted are allowed here as well as maintainer-needed
  ones.
  
  maintainer-needed are only allowed if they're removed from the tree
  and moved over to sunrise (and thus end up as maintainer-wanted
  again).
  
 
 Um, there are numerous new not-in-portage-tree ebuilds submitted to
 bz which have been assigned to teams. However, they may still
 languish. They were assigned by the wranglers, and not improperly.
 Yet, for many reasons, the bugs wait. So, will there be a mechanism
 for a contributor to get an ebuild uploaded to sunrise in this
 circumstance?

What those bugs are waiting for is a dev to step up and agree to
maintain it.  I don't see how sunrise improves that situation.  The
only way such a bug will be resolved if no dev is interested, is if
someone who wants the package in the tree decides to become a dev - and
that means demonstrating technical ability, and sticking around (not
just dumping it in the tree then disappearing - in which case the
package would likely get removed after a while anyway due to lack of
maintenance).

 I would also suggest having some sort of review process for inclusion
 of m-n/m-w bugs. Some may not have any relevance (i.e. the program is
 no longer supported, or the upstream project has been incorporated
 into a new one, or the version of dated). Doing a blanket import of
 m-w bugs could make quite a mess of things IMO.
 
 One of the terrific benefits of sunrise will be the cleaning out of
 bugzilla. Nuking open bugs is an especially satisfying experience!

Sorry, I don't buy that.  Having m-w/m-n packages in the sunrise
overlay cannot be sufficient to close the bugs in bugzilla.  The bugs
get closed when the package gets maintenance support from a dev and is
put into the tree.  Sunrise doesn't do anything to make that more
likely.

I also don't think that having large numbers of bugs open in bugzilla
is a problem.  The search facilities are quite capable of giving you
focused lists of open bugs.  If you don't want to see the bugs about
m-w/m-n ebuilds, filter them out of your search.

 Lastly, what about user contributions? Will users require some kind of
 sponsorship in order to have their ebuilds posted? What will the
 procedure be (or did I miss it in one of the hundreds of emails)?

This reflects back on the primary objection to sunrise on gentoo.org.
Your question is essentially, who will take responsibility for it and
put it in the tree?.  Sunrise might help in getting ebuilds to a decent
standard, and it might help some users to contribute, but it won't help
if no dev wants to take on maintainership of the package.  That last
point is the only reason why m-w/m-n packages are not in the tree.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


[gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-11 Thread Stefan Schweizer
Peter wrote:
 Um, there are numerous new not-in-portage-tree ebuilds submitted to bz
 which have been assigned to teams. However, they may still languish. They
 were assigned by the wranglers, and not improperly. Yet, for many reasons,
 the bugs wait. So, will there be a mechanism for a contributor to get an
 ebuild uploaded to sunrise in this circumstance?

You need to ask a team member then to move them to maintainer-wanted.
Usually the teams have no problem with moving bugs over to
maintainer-wanted because they know that they cannot maintain everything
themselves.


 I would also suggest having some sort of review process for inclusion of
 m-n/m-w bugs. Some may not have any relevance (i.e. the program is no
 longer supported, or the upstream project has been incorporated into a new
 one, or the version of dated). Doing a blanket import of m-w bugs could
 make quite a mess of things IMO.
This is volunteers work and usually volunteers are only moving over the
ebuilds they use themselves. We are not doing this in a general way, but on
a per-user per-package basis. We do not plan to run any importing scripts.
It will only be done if a user or developer is interested in it :)

 One of the terrific benefits of sunrise will be the cleaning out of
 bugzilla. Nuking open bugs is an especially satisfying experience!

Sorry, we are not doing this. We are assigning a bug to every sunrise ebuild
to make sure that it can be discussed there and is still easily searchable.
 
 Lastly, what about user contributions? Will users require some kind of
 sponsorship in order to have their ebuilds posted? What will the procedure
 be (or did I miss it in one of the hundreds of emails)?

see 5) from Markus' email. You just need to have a good ebuild contribution
that we can review with you, You will not gain full access but it is a
start.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Christel Dahlskjaer
After waiting for my replies for 24+ hours I presume they disappeared
into a blackhole while we were lacking lists, so I'm resending.


 Forwarded Message 
 From: Christel Dahlskjaer [EMAIL PROTECTED]
 To: gentoo-dev@lists.gentoo.org
 Subject: Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
 Date: Sat, 10 Jun 2006 13:13:37 +0100
 
 On Sat, 2006-06-10 at 09:27 +0200, Wernfried Haas wrote:
  On Sat, Jun 10, 2006 at 04:28:36AM +0100, Christel Dahlskjaer wrote:
   I would like to ask that the Council discuss the current state and
   future of the GWN at their next meeting.
  
  Council? Why escalate things? Have you talked to Ulrich about the
  problems mentioned below? Isn't the GWN somehow a userrel issue? ;-)
 
 I have attempted, but as it happens I have never ever spoken to Ulrich
 as he does not respond to my e-mails and does not frequent IRC and I
 don't have his telephone number or address. And the GWN doesn't come
 under Userrel, although they do have a representative within Userrel,
 one whom I understand to be wanting to make some improvements to the
 GWN.  
 
 As for why the Council, because thats what people suggested when I asked
 which route to take when he was unresponsive. 
 
   1. Reliability. The GWN claims to be a weekly publication, yet it
   frequently fails to publish without prior warning. There was no edition
   this week, and Patrick Lauer says that it is unknown whether there
   will be an edition next week as Ulrich Plate is AWOL.
  
  I agree there are problems due to Ulrich being awol every now and
  then, but what can the council do about it? Fire him so the GWN is
  unmaintained? ;-)
 
 No. I don't want anyone fired. However, I believe that the other GWN guy
 could be provided with sufficient access to make sure it goes out, and I
 believe that Ulrich could give some warning when possible so that
 Patrick or whomever can get it out regardless of whether Ulrich is
 around or not. 
 
   2. Permissions. Although it could be considered flattering that the GWN
   should choose a developer's blog as inspiration for an article, they
   should ensure that they have the developer / author's permission before
   quoting them (see previous complaints by brix, ciaranm and others).
  
  Why? What makes blog posts different to mailing list/forum threads,
  new versions being released etc? Do you want to ask people for
  permission then, too?
 
 If you re-read what I said I don't have an issue with the GWN or anyone
 else using someones blog post as inspiration, I do however believe that
 when quoting someone and writing the article in such a way that the
 'quotee' appears to have spoken to the publication you need to get some
 consensus before printing. 
 
   I also believe that when posting an article or interview, a copy should
   be sent to the relevant people to ensure that they are ok with what is
   being posted (my dev of the week interview, for example, was rather
   screwed up and misrepresentative). When someone contacts GWN to have
   something corrected, it would be appreciated were the GWN staff to at
   least deign to acknowledge receipt, even if for some reason they choose
   not to honour the corrections or post a retraction (although refusing to
   publish corrections is extremely insulting to those wronged).
  
  Considering Ulrich is appearently still/again awol, could that be the
  reason? I have requested small fixes (like wrong email addresses in
  stuff i submitted) every now and than and got what i asked for.
 
 He wasn't awol at the time of my writing my first few e-mails. 
 
   3. Misinformation, misquotations and outright fabrications. Sure,
   there's freedom of the press, but that shouldn't be used as an excuse
   for deliberately making up quotes and printing intentional
   misinformation.
  
  Huh? Can you back that statement up?
 
 To take an example, there were made up quotes in my GWN interview,
 however, nothing of great harm. I believe that time it was a case of
 attempting to make it more fun, it is however a worrying trend.
 
   From a PR perspective, Gentoo could benefit greatly by better
   utilisation of the GWN. I believe that as it stands, however, the GWN is
   discouraging people from contributing and damaging Gentoo's credibility.
  
  I have submitted a bunch of articles to the GWN, and it has always
  worked fine for me. Yes, Ulrich is awol at times and sometimes there
  are smaller corrections to make in the final article, but i never felt
  discouraged to submit my stuff. Worst case it takes a few extra days
  to get published.
 
 Ok. I am very glad to hear that not everyone shares the same experiences
 when it comes to contributing to the GWN. 
 
   Another thing that concerns me is the way the articles are written. It
   is blatanly obvious that the GWN writers are not native English speakers
   as both the grammar and the flow of the articles is far from attractive.
   Having read through the archives, I notice 

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Christel Dahlskjaer
The reply appears to have disappeared into a black hole.

 Forwarded Message 
 From: Christel Dahlskjaer [EMAIL PROTECTED]
 To: gentoo-dev@lists.gentoo.org
 Subject: Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
 Date: Sat, 10 Jun 2006 13:26:31 +0100
 
 On Sat, 2006-06-10 at 10:07 +0200, Lars Weiler wrote:
  Congratulations.  I just unsubscribed from the
  gwn-feedback-alias after reading your mail.
  
  * Christel Dahlskjaer [EMAIL PROTECTED] [06/06/10 04:28 +0100]:
   1. Reliability. The GWN claims to be a weekly publication, yet it
   frequently fails to publish without prior warning. There was no edition
   this week, and Patrick Lauer says that it is unknown whether there
   will be an edition next week as Ulrich Plate is AWOL.
  
  Several times Kurt or I took over the job of publicing the
  GWN when Ulrich asked us.  So, there is a backup, but he
  didn't asked for this week.
 
 I am glad to hear that backup has been used in the past, and I hope that
 it will be again.
 
   2. Permissions. Although it could be considered flattering that the GWN
   should choose a developer's blog as inspiration for an article, they
   should ensure that they have the developer / author's permission before
   quoting them (see previous complaints by brix, ciaranm and others).
   
   I also believe that when posting an article or interview, a copy should
   be sent to the relevant people to ensure that they are ok with what is
   being posted (my dev of the week interview, for example, was rather
   screwed up and misrepresentative). When someone contacts GWN to have
   something corrected, it would be appreciated were the GWN staff to at
   least deign to acknowledge receipt, even if for some reason they choose
   not to honour the corrections or post a retraction (although refusing to
   publish corrections is extremely insulting to those wronged).
  
  And I expect the same from you.  You should ask the affected
  people first before starting a discussion about them on our
  public mailing lists.  This is a device I can give you for
  further userrelations-activities.
 
 I have actually contacted Ulrich on several occasions, he chose not to
 get back to me. And I have spoken a fair bit with Patrick, and from
 speaking with Patrick it is quite obvious that the GWN could do with
 some help, and I am hoping that my addressing the problems we can pool
 together and find ways of helping them.
 
   4. Credit. Care should be taken to ensure that crrect credit is given.
  
  It is.  Either as Author or Contributor.
 
 Or it is totally lacking, like in the above mentioned blog scenario. 
 
   Another thing that concerns me is the way the articles are written. It
   is blatanly obvious that the GWN writers are not native English speakers
   as both the grammar and the flow of the articles is far from attractive.
   Having read through the archives, I notice that there was once a time
   when the GWN was a great publication, and I would like to think that it
   could become great yet again; in its current state, though, it is doing
   more harm than good.
  
  It's quite interesting to see, that the GWN and also
  Debian's Weekly Newsletter is run by Germans mostly.  Is
  there a problem with native speakers to run a periodically
  newsletter for a long time ( 3 years)?
 
 No, there isn't a problem with it. However, as I understand it the GWN
 is translated into N languages, and I would presume the german version
 to be the one which reads better. Could it be an idea to have someone
 whos first language is English look over and improve upon the English
 version? I know we already dot the i's and cross the t's, maybe it would
 be of benefit if someone worked a bit on how it flows.
 
   Lack of content and poorly written or incorrect articles are often
   justified by the GWN team on grounds of overwork and insufficient
   manpower. When I asked why they were not recruiting, I was informed that
   no-one has any interest in contributing. Upon speaking with others,
   however, I find that this is not the case -- people are interested, but
   fear (and rightly so) that their work will be edited in such a way that
   it is no longer something with which they want to be associated.
  
  Subscribe to the gwn-feedback-alias and read or comment the
  submissions to the GWN.  Make sure that every user will
  receive and answer.  And forward questions to the
  arch-teams.  Isn't that userrel's job?  I didn't saw your
  contributions there yet.
 
 I wasn't aware the gwn-feedback alias was public, if it is then I would
 be more than happy to subscribe to it and read and comment to every
 user. Would I be stepping on anyones toes by doing so? And if the GWN
 would like to off-load some stuff onto Userrel, then userrel would be
 more than happy to help. We already have a GWN representative and he
 knows that several of the userrel team would jump at the chance to help
 out with various GWN related bits.



Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Christel Dahlskjaer
Another vanishing reply from yesterday.


 Forwarded Message 
 From: Christel Dahlskjaer [EMAIL PROTECTED]
 To: gentoo-dev@lists.gentoo.org
 Subject: Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
 Date: Sat, 10 Jun 2006 13:44:02 +0100
 
 On Sat, 2006-06-10 at 10:56 +0200, Patrick Lauer wrote:
  On Sat, 2006-06-10 at 03:28 +0100, Christel Dahlskjaer wrote:
   I would like to ask that the Council discuss the current state and
   future of the GWN at their next meeting.
  I don't think you have to escalate that far. We should be able to discuss 
  things without the thermonuclear option ;-)
 
 I have no idea, I asked people, they suggested the Council. It may be
 the wrong place :)
 
   1. Reliability. The GWN claims to be a weekly publication, yet it
   frequently fails to publish without prior warning. There was no edition
   this week, and Patrick Lauer says that it is unknown whether there
   will be an edition next week as Ulrich Plate is AWOL.
  We have tried to get a backup structure working, Halcy0n for example 
  offered to help. Ulrich never responded to these offers. He usually has 
  a good reason for not doing the GWN (like no Internet access, broken 
  notebook etc), but I also find this quite unsatisfactory.
 
 I am sure his reasons are good, and I agree there should be a backup
 structure in place. 
 
   2. Permissions. Although it could be considered flattering that the GWN
   should choose a developer's blog as inspiration for an article, they
   should ensure that they have the developer / author's permission before
   quoting them (see previous complaints by brix, ciaranm and others).
  As far as I'm aware this has been taken care of. But with the GWN quite 
  understaffed it is not easy to get everything done well.
  I'd appreciate some more support from others, but sadly my recruiting
  experiments usually ended after one contribution (for example summary of
  the -user ML).
 
 Which is why I am hoping that by bringing it up elsewhere, someone may
 have some ideas of how to recruit people, or just attract people enough
 for them to make the occasional contribution. 
 
   I also believe that when posting an article or interview, a copy should
   be sent to the relevant people to ensure that they are ok with what is
   being posted (my dev of the week interview, for example, was rather
   screwed up and misrepresentative).
  My fault. 
 
 Ok, thank you.
 
When someone contacts GWN to have
   something corrected, it would be appreciated were the GWN staff to at
   least deign to acknowledge receipt, even if for some reason they choose
   not to honour the corrections or post a retraction (although refusing to
   publish corrections is extremely insulting to those wronged).
  The reason for that is that the GWN is mostly sent out by mail. This 
  makes corrections a bit more difficult, but I think having a sane policy 
  for that would be helpful.
  
   3. Misinformation, misquotations and outright fabrications. Sure,
   there's freedom of the press, but that shouldn't be used as an excuse
   for deliberately making up quotes and printing intentional
   misinformation.
  I don't know what exactly you are talking about here. But it shouldn't 
  happen.
  
   4. Credit. Care should be taken to ensure that crrect credit is given.
  Yes. 
  
   From a PR perspective, Gentoo could benefit greatly by better
   utilisation of the GWN. I believe that as it stands, however, the GWN is
   discouraging people from contributing and damaging Gentoo's credibility.
  The problem with the GWN is the lack of reliable useful contributions.
  There was a time when the GWN was ~80% written by me, but that took more
  time than I could afford in the last weeks.
 
 See, if you spent less time arguing with that elitist bastard Chri...
 er, no :P Yes, I think what the GWN needs the most is more hands at the
 deck. 
 
   Another thing that concerns me is the way the articles are written. It
   is blatanly obvious that the GWN writers are not native English speakers
   as both the grammar and the flow of the articles is far from attractive.
  Help is appreciated :-)
  The GWN has become a german thing, we have jokingly discussed writing it
  in german and letting someone translate it to english.
 
 I don't think thats a bad bad idea, that is, maybe someone could atleast
 vamp it up a bit before it goes live. 
 
   Having read through the archives, I notice that there was once a time
   when the GWN was a great publication, and I would like to think that it
   could become great yet again; in its current state, though, it is doing
   more harm than good.
  Agreed.
  
   Lack of content and poorly written or incorrect articles are often
   justified by the GWN team on grounds of overwork and insufficient
   manpower. When I asked why they were not recruiting, I was informed that
   no-one has any interest in contributing.
  There's a big difference between one-off articles and 

Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds

2006-06-11 Thread Donnie Berkholz
Jakub Moc wrote:
 Donnie, pingy! ;) Just a friendly reminder to run the script again, so
 that we can do a last attempt on fixing the remaining stuff before
 resorting to more drastic solutions...

Yeah, it's on my list, but I've got family here all weekend so no time
to work on stuff.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Project Sunrise -- Proposal

2006-06-11 Thread Donnie Berkholz
Henrik Brix Andersen wrote:
 While I do think this proposal is much better than the previous
 non-existing proposal, it still doesn't address the problem of having
 the sunrise overlay hosted on a non *.gentoo.org address to make it
 100% clear to the public that it is unsupported.

It's no more or less supported than anything else on
overlays.gentoo.org. The word overlays ought to be enough. I suppose
you oppose the whole concept, anyhow?

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification

2006-06-11 Thread Henrik Brix Andersen
On Sun, Jun 11, 2006 at 03:42:19PM +0200, Christian Birchinger wrote:
 On Fri, Jun 09, 2006 at 02:04:57PM +0200, Stefan Schweizer wrote:
 
  svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application;
  emerge application
  
 
 As long as it's made for pulling single ebuilds (and their
 support files), i think it's really helpfull.

The way SVN works you can just as easily do svn co
http://overlays.gentoo.org/svn/proj/sunrise/; and get the full
repository - so no, this is not limited to pulling single ebuilds.

./Brix
-- 
Henrik Brix Andersen [EMAIL PROTECTED]
Gentoo Metadistribution | Mobile computing herd


pgpdMipiLWjnS.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-11 Thread Henrik Brix Andersen
On Sun, Jun 11, 2006 at 04:01:50PM +0200, Stefan Schweizer wrote:
 You need to ask a team member then to move them to maintainer-wanted.
 Usually the teams have no problem with moving bugs over to
 maintainer-wanted because they know that they cannot maintain everything
 themselves.

But Project Sunrise can? I'm sorry, but I believe you are
overestimating yourself...

Regards,
Brix
-- 
Henrik Brix Andersen [EMAIL PROTECTED]
Gentoo Metadistribution | Mobile computing herd


pgpKiMpk5C9m9.pgp
Description: PGP signature


Re: [gentoo-dev] Project Sunrise -- Proposal

2006-06-11 Thread Henrik Brix Andersen
On Sun, Jun 11, 2006 at 09:43:01AM -0700, Donnie Berkholz wrote:
 It's no more or less supported than anything else on
 overlays.gentoo.org. The word overlays ought to be enough. I suppose
 you oppose the whole concept, anyhow?

No, I am certainly not opposed to overlays in general. I even maintain
my own public overlay of packages I work on in portage, an overlay I
consider moving to overlays.g.o when I have more time.

However, as has been pointed out several times in this thread already,
back when the devloper community agreed to the overlays project it was
also agreed that projects similar to what is now known as Project
Sunrise was not be present on overlays.gentoo.org. I believe this was
why many developers agreed to having the overlays project in the first
place. The idea was to have a central repository for the team and
developer specific overlays that already are available on
e.g. dev.gentoo.org. Overlays that are far more limited in contents
and where the ebuilds are written and reviewed by people who actually
know the packages in question.

Instead of following this consensus, the people behind Project Sunrise
choose to ignore this and went ahead and implemented the project -
without even presenting the idea to the developer community before
announcing it's presence to the world; perhaps thinking it would be
easier to get pardon than permission.

As I see it we have already agreed that an overlay of this type should
not be hosted on the overlays project back when the overlays project
was agreed upon. Yet a small number of developers ignored this and
implemented it anyhow behind the back of the rest of the developers,
disregarding their public stated oppinion. As this is a project that
has the potential of affecting the entire project I find this very
problematic.

Regards,
Brix
-- 
Henrik Brix Andersen [EMAIL PROTECTED]
Gentoo Metadistribution | Mobile computing herd


pgpml7nyTSUpF.pgp
Description: PGP signature


Re: [gentoo-dev] Project Sunrise -- Proposal

2006-06-11 Thread Stuart Herbert

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Henrik Brix Andersen wrote:
| However, as has been pointed out several times in this thread already,
| back when the devloper community agreed to the overlays project it was
| also agreed that projects similar to what is now known as Project
| Sunrise was not be present on overlays.gentoo.org.

Can you provide a reference to this, please?  I've been through my -dev M/L
archive several times, and cannot find an email where I agreed to this.

Best regards,
Stu
- --
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
~   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEjFivDC+AuvmvxXwRAungAKCejd72YGbpZ5bzFjtg2ezAu8XwswCeK2PP
GwYPr/RE79+j4iiZMbcA3zM=
=ZOKP
-END PGP SIGNATURE-

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-11 Thread Stefan Schweizer
Dan Meltzer wrote:
 On 6/10/06, Markus Ullmann [EMAIL PROTECTED] wrote:
 2) Not one large tree but subdirs, one per herd

 to help herds better keeping track of which parts are alive in the
 overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be
 a netmon/ dir with net-analyzer/specialapp below it.

 
 If its unofficially part of a herd, then isn't it no longer a m-w/m-n
 ebuild?

I think you are right, see my answer to the threadstarter to find a solution
that works without subdirs.


 I think this is a much improved//thought out version of the proposal.
 From the looks of things sunrise should never make it to layman
 however, because as we all know, anything that makes things more
 easily accessible to users is going to be (mis)used by more of them.
 From what I understand, you see Sunrise as an overlay for users to
 improve their ebuilds because they are insufficient quality to be in
 the main tree.  If they are of this poor quality, they should be no
 where near users hands, this doesn't make sense.

We will yet have to see if quality will be that bad. I want some more time
to see how the ebuild quality works out before we make it more publically
available.

 If on the other hand you saw sunrise as a way for more packages to be
 available to users due to there being a lack of maintainers, asking
 herds to check out ebuilds as part of the proposal seems
 counterproductive to the cause.

They do not have to. It is just nice to let us know that they would like to
see a package in sunrise.

 Maybe you should expand on the goal of the sunrise project, what
 exactly do you want it to do?
The Sunrise Project goals may change, it is not yet running long enough to
know about all the effects and the goals. Because of this, I cannot give
you an exact definition now, sorry.

our goals include for example:
- encourage users to write ebuilds
- get new recruits
- make maintainer-wanted ebuild access and development easier
- work with users on new ebuilds and explain them what they can do better

I think these are working out quite well currently, I hope it helps you.

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Wernfried Haas
On Sun, Jun 11, 2006 at 05:50:05PM +0100, Christel Dahlskjaer wrote:
  As for why the Council, because thats what people suggested when I asked
  which route to take when he was unresponsive. 

I see, and that puts your suggestion of conctacting the council in a
different angle.

[some stuff skipped as it seems to be cleared up]

3. Misinformation, misquotations and outright fabrications. Sure,
there's freedom of the press, but that shouldn't be used as an excuse
for deliberately making up quotes and printing intentional
misinformation.
   
   Huh? Can you back that statement up?
  
  To take an example, there were made up quotes in my GWN interview,
  however, nothing of great harm. I believe that time it was a case of
  attempting to make it more fun, it is however a worrying trend.

Agreed, that shouldn't happen.

Another complaint is that the GWN rejects any writing style which has
any degree of character or levity. Any attempt at dececnt writing (the
kind that would make it into publication in English newspapers or
magazines, for example), is met with the claim that the GWN is not a
humorous publication.
   
   http://www.gentoo.org/news/en/gwn/20060522-newsletter.xml#doc_chap3
   Look at the picture and tell me it's not at least a tiny bit
   humorous. Agreed, the joke is a bit obvious.
  
  I can't quite see how your picture has anything to do with writing style
  and character of writing.

It's something a not humorous publication probably wouldn't print -
but whatever. ;-)

  I am not entirely sure why the council wouldn't be a good place to start
  a discussion about this. I believe that the council members will wish to
  help the GWN help themselves sufficiently to solve their problems,
  whether that be attempting to help them think of new ways to attract
  contributors or make any other changes. 

I'm not sure how the council can do something here either, i think
discussing it here on the list may probably help solve some issues.

cheers,
Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org


pgpRTcoRFpF9b.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-11 Thread Markus Ullmann
Ryan Hill wrote:
 2. People who contribute good ebuilds over a certain period of time are
 allowed upon decision by project devs to actively help maintaining the
 project. They'll be given commit rights for the project then. Same frome
 above applies here: If we notice any abuse, we revoke access immediately.
 
 Would they be considered Gentoo staff, with everything that involves (quiz, 
 etc)?

No, they are only given permission for the project. Becoming a gentoo
developer is a separate step and involves a full recruiting.
However, they need to do the normal ebuild quiz with one of the project
devs to be allowed to commit to the project overlay on their own.

 7) tag on bugs

 All ebuilds that are made available on sunrise get an InOverlay KEYWORDS
 entry on bugs.g.o so that everyone, who looks at the bug, knows about it.
 
 Would it also be useful to also have a keyword to indicate that the Sunrise
 ebuild has reached the point where it could be migrated to the gentoo repo if 
 a
 maintainer for it steps up?  I'm thinking that would make it easy to get a 
 list
 of all m-w ebuilds that are ready for the tree.  Maybe a page listing these
 packages would also be a good idea.

Okay so leave a comment on the bug for now and later on we can follow
your idea here and provide a ready to move over list as well, which
seems quite a good idea :)

Greetz,
Jokey



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Project Sunrise -- Proposal

2006-06-11 Thread Henrik Brix Andersen
On Sun, Jun 11, 2006 at 06:53:51PM +0100, Stuart Herbert wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Henrik Brix Andersen wrote:
 | However, as has been pointed out several times in this thread already,
 | back when the devloper community agreed to the overlays project it was
 | also agreed that projects similar to what is now known as Project
 | Sunrise was not be present on overlays.gentoo.org.
 
 Can you provide a reference to this, please?  I've been through my -dev M/L
 archive several times, and cannot find an email where I agreed to this.

Perhaps not in those exact words, I admit. But the general consensus
in my eyes, and I'm not alone with this view according to other
replies to this thread, was that the purpose of overlays.gentoo.org
would be to provide a common place to host project and developer
overlays - not a place to host Joe User's ebuild contributions (except
for users regularly contributing to specific teams/herds and
devs-in-spee). [1] [2] [3]

You could argue that Project Sunrise *is* a specific project. Fact is
that nobody at that time could predict that a small group of
developers would go ahead and create a project with the single goal of
providing Joe User's bugzilla-contributed ebuilds to end-users through
overlays.gentoo.org.

In my opinion, creating a new project with this purpose should not
have been allowed. I fear that perhaps creating the project was just
an attempt to circumvent the policy of overlays.gentoo.org, which
states that only project teams and individual Gentoo developers can
have an overlay on overlays.gentoo.org. It seems that the developers
who started Project Sunrise already planed to use overlays.gentoo.org
as a free-for-all overlay with no QA and policy checks back when the
idea of an official overlays project was discussed. [4] [5]

The security issues of having an official overlay of unsupported
ebuilds was also raised back then. [6] [7] [8] [9] [10] As was the
concerns about potential damage to the reputation of Gentoo as a
whole. [11] [12]

On the other hand, having team/herd specific overlays with commit
access from a select few end-users (as was written in the original
proposal) was seen as a good idea. [13] [14]

I've spent tonight reading through the entire thread that let to the
creation of the overlays project, and I still come out in the end with
the feeling that a consensus of having overlays.gentoo.org for hosting
the already existing developer and herd/team overlays in a central
place was reached. It also looks to me like the idea of having a
free-for-all or a user-contrib overlay hosted there would not be
acceptable due to security issues and risk of damaging the reputation
of Gentoo as a whole.

I know this doesn't provide solid evidence that this is how it was,
but truth is - we hardly ever see an email on the developers list
stating This is what we agreed on. Due to the nature of the media we
tend to have a lot of input and discussion back and forth after which
a general consensus is found. This consensus, as I see it, is
reflected in the policy for overlays.gentoo.org. [15]

I urge people to read through the initial thread that fostered
overlays.gentoo.org as well - if only to refresh peoples memory on the
stuff that was discussed back then. You can start at
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09877.html

Sincerely,
Brix

[1]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09913.html
[2]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09921.html
[3]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09983.html

[4]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09962.html
[5]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09966.html

[6]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09918.html
[7]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09959.html
[8]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09884.html
[9]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09964.html
[10]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09963.html
[11]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09910.html
[12]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09946.html

[13]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09948.html
[14]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09972.html

[15]: http://www.gentoo.org/proj/en/overlays/policy.xml
-- 
Henrik Brix Andersen [EMAIL PROTECTED]
Gentoo Metadistribution | Mobile computing herd


pgp3PFucKP198.pgp
Description: PGP signature


Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Christel Dahlskjaer
On Sat, 2006-06-10 at 09:27 +0200, Wernfried Haas wrote:
 On Sat, Jun 10, 2006 at 04:28:36AM +0100, Christel Dahlskjaer wrote:
  I would like to ask that the Council discuss the current state and
  future of the GWN at their next meeting.
 
 Council? Why escalate things? Have you talked to Ulrich about the
 problems mentioned below? Isn't the GWN somehow a userrel issue? ;-)

I have attempted, but as it happens I have never ever spoken to Ulrich
as he does not respond to my e-mails and does not frequent IRC and I
don't have his telephone number or address. And the GWN doesn't come
under Userrel, although they do have a representative within Userrel,
one whom I understand to be wanting to make some improvements to the
GWN.  

As for why the Council, because thats what people suggested when I asked
which route to take when he was unresponsive. 

  1. Reliability. The GWN claims to be a weekly publication, yet it
  frequently fails to publish without prior warning. There was no edition
  this week, and Patrick Lauer says that it is unknown whether there
  will be an edition next week as Ulrich Plate is AWOL.
 
 I agree there are problems due to Ulrich being awol every now and
 then, but what can the council do about it? Fire him so the GWN is
 unmaintained? ;-)

No. I don't want anyone fired. However, I believe that the other GWN guy
could be provided with sufficient access to make sure it goes out, and I
believe that Ulrich could give some warning when possible so that
Patrick or whomever can get it out regardless of whether Ulrich is
around or not. 

  2. Permissions. Although it could be considered flattering that the GWN
  should choose a developer's blog as inspiration for an article, they
  should ensure that they have the developer / author's permission before
  quoting them (see previous complaints by brix, ciaranm and others).
 
 Why? What makes blog posts different to mailing list/forum threads,
 new versions being released etc? Do you want to ask people for
 permission then, too?

If you re-read what I said I don't have an issue with the GWN or anyone
else using someones blog post as inspiration, I do however believe that
when quoting someone and writing the article in such a way that the
'quotee' appears to have spoken to the publication you need to get some
consensus before printing. 

  I also believe that when posting an article or interview, a copy should
  be sent to the relevant people to ensure that they are ok with what is
  being posted (my dev of the week interview, for example, was rather
  screwed up and misrepresentative). When someone contacts GWN to have
  something corrected, it would be appreciated were the GWN staff to at
  least deign to acknowledge receipt, even if for some reason they choose
  not to honour the corrections or post a retraction (although refusing to
  publish corrections is extremely insulting to those wronged).
 
 Considering Ulrich is appearently still/again awol, could that be the
 reason? I have requested small fixes (like wrong email addresses in
 stuff i submitted) every now and than and got what i asked for.

He wasn't awol at the time of my writing my first few e-mails. 

  3. Misinformation, misquotations and outright fabrications. Sure,
  there's freedom of the press, but that shouldn't be used as an excuse
  for deliberately making up quotes and printing intentional
  misinformation.
 
 Huh? Can you back that statement up?

To take an example, there were made up quotes in my GWN interview,
however, nothing of great harm. I believe that time it was a case of
attempting to make it more fun, it is however a worrying trend.

  From a PR perspective, Gentoo could benefit greatly by better
  utilisation of the GWN. I believe that as it stands, however, the GWN is
  discouraging people from contributing and damaging Gentoo's credibility.
 
 I have submitted a bunch of articles to the GWN, and it has always
 worked fine for me. Yes, Ulrich is awol at times and sometimes there
 are smaller corrections to make in the final article, but i never felt
 discouraged to submit my stuff. Worst case it takes a few extra days
 to get published.

Ok. I am very glad to hear that not everyone shares the same experiences
when it comes to contributing to the GWN. 

  Another thing that concerns me is the way the articles are written. It
  is blatanly obvious that the GWN writers are not native English speakers
  as both the grammar and the flow of the articles is far from attractive.
  Having read through the archives, I notice that there was once a time
  when the GWN was a great publication, and I would like to think that it
  could become great yet again; in its current state, though, it is doing
  more harm than good.
 
 I disagree. GWN could use some more manpower to improve this and that,
 but i don't see the harm - at least i could easily come up with lots
 of stuff happening that does more harm (Not pointing my finger at
 anyone and leaving it up to everyone's 

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Christel Dahlskjaer
On Sat, 2006-06-10 at 10:07 +0200, Lars Weiler wrote:
 Congratulations.  I just unsubscribed from the
 gwn-feedback-alias after reading your mail.
 
 * Christel Dahlskjaer [EMAIL PROTECTED] [06/06/10 04:28 +0100]:
  1. Reliability. The GWN claims to be a weekly publication, yet it
  frequently fails to publish without prior warning. There was no edition
  this week, and Patrick Lauer says that it is unknown whether there
  will be an edition next week as Ulrich Plate is AWOL.
 
 Several times Kurt or I took over the job of publicing the
 GWN when Ulrich asked us.  So, there is a backup, but he
 didn't asked for this week.

I am glad to hear that backup has been used in the past, and I hope that
it will be again.

  2. Permissions. Although it could be considered flattering that the GWN
  should choose a developer's blog as inspiration for an article, they
  should ensure that they have the developer / author's permission before
  quoting them (see previous complaints by brix, ciaranm and others).
  
  I also believe that when posting an article or interview, a copy should
  be sent to the relevant people to ensure that they are ok with what is
  being posted (my dev of the week interview, for example, was rather
  screwed up and misrepresentative). When someone contacts GWN to have
  something corrected, it would be appreciated were the GWN staff to at
  least deign to acknowledge receipt, even if for some reason they choose
  not to honour the corrections or post a retraction (although refusing to
  publish corrections is extremely insulting to those wronged).
 
 And I expect the same from you.  You should ask the affected
 people first before starting a discussion about them on our
 public mailing lists.  This is a device I can give you for
 further userrelations-activities.

I have actually contacted Ulrich on several occasions, he chose not to
get back to me. And I have spoken a fair bit with Patrick, and from
speaking with Patrick it is quite obvious that the GWN could do with
some help, and I am hoping that my addressing the problems we can pool
together and find ways of helping them.

  4. Credit. Care should be taken to ensure that crrect credit is given.
 
 It is.  Either as Author or Contributor.

Or it is totally lacking, like in the above mentioned blog scenario. 

  Another thing that concerns me is the way the articles are written. It
  is blatanly obvious that the GWN writers are not native English speakers
  as both the grammar and the flow of the articles is far from attractive.
  Having read through the archives, I notice that there was once a time
  when the GWN was a great publication, and I would like to think that it
  could become great yet again; in its current state, though, it is doing
  more harm than good.
 
 It's quite interesting to see, that the GWN and also
 Debian's Weekly Newsletter is run by Germans mostly.  Is
 there a problem with native speakers to run a periodically
 newsletter for a long time ( 3 years)?

No, there isn't a problem with it. However, as I understand it the GWN
is translated into N languages, and I would presume the german version
to be the one which reads better. Could it be an idea to have someone
whos first language is English look over and improve upon the English
version? I know we already dot the i's and cross the t's, maybe it would
be of benefit if someone worked a bit on how it flows.

  Lack of content and poorly written or incorrect articles are often
  justified by the GWN team on grounds of overwork and insufficient
  manpower. When I asked why they were not recruiting, I was informed that
  no-one has any interest in contributing. Upon speaking with others,
  however, I find that this is not the case -- people are interested, but
  fear (and rightly so) that their work will be edited in such a way that
  it is no longer something with which they want to be associated.
 
 Subscribe to the gwn-feedback-alias and read or comment the
 submissions to the GWN.  Make sure that every user will
 receive and answer.  And forward questions to the
 arch-teams.  Isn't that userrel's job?  I didn't saw your
 contributions there yet.

I wasn't aware the gwn-feedback alias was public, if it is then I would
be more than happy to subscribe to it and read and comment to every
user. Would I be stepping on anyones toes by doing so? And if the GWN
would like to off-load some stuff onto Userrel, then userrel would be
more than happy to help. We already have a GWN representative and he
knows that several of the userrel team would jump at the chance to help
out with various GWN related bits.


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Christel Dahlskjaer
On Sat, 2006-06-10 at 10:56 +0200, Patrick Lauer wrote:
 On Sat, 2006-06-10 at 03:28 +0100, Christel Dahlskjaer wrote:
  I would like to ask that the Council discuss the current state and
  future of the GWN at their next meeting.
 I don't think you have to escalate that far. We should be able to discuss 
 things without the thermonuclear option ;-)

I have no idea, I asked people, they suggested the Council. It may be
the wrong place :)

  1. Reliability. The GWN claims to be a weekly publication, yet it
  frequently fails to publish without prior warning. There was no edition
  this week, and Patrick Lauer says that it is unknown whether there
  will be an edition next week as Ulrich Plate is AWOL.
 We have tried to get a backup structure working, Halcy0n for example 
 offered to help. Ulrich never responded to these offers. He usually has 
 a good reason for not doing the GWN (like no Internet access, broken notebook 
 etc), but I also find this quite unsatisfactory.

I am sure his reasons are good, and I agree there should be a backup
structure in place. 

  2. Permissions. Although it could be considered flattering that the GWN
  should choose a developer's blog as inspiration for an article, they
  should ensure that they have the developer / author's permission before
  quoting them (see previous complaints by brix, ciaranm and others).
 As far as I'm aware this has been taken care of. But with the GWN quite 
 understaffed it is not easy to get everything done well.
 I'd appreciate some more support from others, but sadly my recruiting
 experiments usually ended after one contribution (for example summary of
 the -user ML).

Which is why I am hoping that by bringing it up elsewhere, someone may
have some ideas of how to recruit people, or just attract people enough
for them to make the occasional contribution. 

  I also believe that when posting an article or interview, a copy should
  be sent to the relevant people to ensure that they are ok with what is
  being posted (my dev of the week interview, for example, was rather
  screwed up and misrepresentative).
 My fault. 

Ok, thank you.

   When someone contacts GWN to have
  something corrected, it would be appreciated were the GWN staff to at
  least deign to acknowledge receipt, even if for some reason they choose
  not to honour the corrections or post a retraction (although refusing to
  publish corrections is extremely insulting to those wronged).
 The reason for that is that the GWN is mostly sent out by mail. This 
 makes corrections a bit more difficult, but I think having a sane policy 
 for that would be helpful.
 
  3. Misinformation, misquotations and outright fabrications. Sure,
  there's freedom of the press, but that shouldn't be used as an excuse
  for deliberately making up quotes and printing intentional
  misinformation.
 I don't know what exactly you are talking about here. But it shouldn't happen.
 
  4. Credit. Care should be taken to ensure that crrect credit is given.
 Yes. 
 
  From a PR perspective, Gentoo could benefit greatly by better
  utilisation of the GWN. I believe that as it stands, however, the GWN is
  discouraging people from contributing and damaging Gentoo's credibility.
 The problem with the GWN is the lack of reliable useful contributions.
 There was a time when the GWN was ~80% written by me, but that took more
 time than I could afford in the last weeks.

See, if you spent less time arguing with that elitist bastard Chri...
er, no :P Yes, I think what the GWN needs the most is more hands at the
deck. 

  Another thing that concerns me is the way the articles are written. It
  is blatanly obvious that the GWN writers are not native English speakers
  as both the grammar and the flow of the articles is far from attractive.
 Help is appreciated :-)
 The GWN has become a german thing, we have jokingly discussed writing it
 in german and letting someone translate it to english.

I don't think thats a bad bad idea, that is, maybe someone could atleast
vamp it up a bit before it goes live. 

  Having read through the archives, I notice that there was once a time
  when the GWN was a great publication, and I would like to think that it
  could become great yet again; in its current state, though, it is doing
  more harm than good.
 Agreed.
 
  Lack of content and poorly written or incorrect articles are often
  justified by the GWN team on grounds of overwork and insufficient
  manpower. When I asked why they were not recruiting, I was informed that
  no-one has any interest in contributing.
 There's a big difference between one-off articles and continuous
 contribution. Also those that I found most willing to contribute had the
 biggest language problems - what we need is support from the native
 speakers.

Nod. I presume for some contributing weekly is rather difficult (finding
something to write about, finding the time to draft, re-draft, clean,
tidy, send off for feedback, double check, stand on their head 

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Ciaran McCreesh
On Sat, 10 Jun 2006 10:56:48 +0200 Patrick Lauer [EMAIL PROTECTED]
wrote:
|  I also believe that when posting an article or interview, a copy
|  should be sent to the relevant people to ensure that they are ok
|  with what is being posted (my dev of the week interview, for
|  example, was rather screwed up and misrepresentative).
| My fault. 

Good start. Now, are you going to post corrections?

|   When someone contacts GWN to have
|  something corrected, it would be appreciated were the GWN staff to
|  at least deign to acknowledge receipt, even if for some reason they
|  choose not to honour the corrections or post a retraction (although
|  refusing to publish corrections is extremely insulting to those
|  wronged).
| The reason for that is that the GWN is mostly sent out by mail. This 
| makes corrections a bit more difficult, but I think having a sane
| policy for that would be helpful.

Publish a 'corrections' section in the next edition?

|  Having read through the archives, I notice that there was once a
|  time when the GWN was a great publication, and I would like to
|  think that it could become great yet again; in its current state,
|  though, it is doing more harm than good.
|
| Agreed.

Given that it is doing more harm than good, should it be discontinued
until a solution is found?

|  Another complaint is that the GWN rejects any writing style which
|  has any degree of character or levity. Any attempt at dececnt
|  writing (the kind that would make it into publication in English
|  newspapers or magazines, for example), is met with the claim that
|  the GWN is not a humorous publication.
|
| Blame the flamefests of the past. Whenever attempts were made to give
| the GWN more dynamic it was flamed down (because ze german humor is
| not funny! Nein! ;-) )
| So the consensus was to keep the silly jokes out of the GWN since
| always someone misunderstands or complains. I'd like to have it a bit
| more open, funny, enjoyable ... but there's only so much I can do. 

Christel did not talk about silly jokes. She spoke about decent
writing (the kind that would make it into publication in newspapers or
magazines, for example). There's a rather large difference (well, if
you assume she means *respectable* newspapers and magazines -- good
examples for anyone wanting examples are the Times, the Guardian or the
Scotsman). I'd imagine the distinction could be not too obvious for
some non-native speakers, but it is a large and very important
distinction.

You don't have to be silly or boring to be considered respectable. Take
Jeremy Clarkson, for example. He's frequently rather outrageous, very
very funny, prone to using extremely colourful metaphors and writes for
the highly respectable Sunday Times, which has such a good reputation
not despite having such writers but because of it.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Henrik Brix Andersen
On Sat, Jun 10, 2006 at 01:13:36PM +0100, Christel Dahlskjaer wrote:
 To take an example, there were made up quotes in my GWN interview,
 however, nothing of great harm. I believe that time it was a case of
 attempting to make it more fun, it is however a worrying trend.

One of my blog entries was also over-interpreted and included in the
GWN without consulting me first, causing a mail storm in my inbox from
angry users of xsupplicant:

http://planet.gentoo.org/developers/brix/2005/11/25/wpa_supplicant_vs_xsupplicant

Regards,
Brix
-- 
Henrik Brix Andersen [EMAIL PROTECTED]
Gentoo Metadistribution | Mobile computing herd


pgpYZmxDaOU68.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-11 Thread Marius Mauch

Stefan Schweizer schrieb:

Marius Mauch wrote:


On Sat, 10 Jun 2006 13:37:15 +0200
Markus Ullmann [EMAIL PROTECTED] wrote:


Okay, so after figuring out open problems (thanks to kloeri and
various other people for help here), we now have a resolution that
should satisfy all involved parties here. This should adress
dostrow's demands as well.

1) m-w / m-n requirement

Only ebuilds that are reported to bugzie (valid bug#) and set to
maintainer-wanted are allowed here as well as maintainer-needed ones.

maintainer-needed are only allowed if they're removed from the tree
and moved over to sunrise (and thus end up as maintainer-wanted
again).
5) commit access to the overlay

We implement two levels of commit rights:

1. As there are people out there who just want to maintain one app for
start, the ebuild should reach a level that project devs are fine with
it, then the user is given permission to commit on that single app. An
automated check makes sure that he doesn't commit anywhere else. If
violations arise, the access is revoked immediately.

2. People who contribute good ebuilds over a certain period of time
are allowed upon decision by project devs to actively help
maintaining the project. They'll be given commit rights for the
project then. Same frome above applies here: If we notice any abuse,
we revoke access immediately.

One more rule I'd like to see (should be obvious, but better to write
it down):

People who commit to a certain project/ebuild have to be on the CC
list of the relevant bug report(s) and any important commits should be
documented on the bugs (including the revision of/link to the commit).

I have not made it a rule yet to prevent whitespacing and updates for minor
changes, also I would like to leave things like that to the people to
decide to prevent that too many rules lock us in.
How far would you want to go? Update for I have removed some quotes for I
have made a version bump?


Functional changes, bugfixes, etc. Let people use common sense there. 
The intention is simply that people watching the bug don't have to track 
the overlay as well to get notifications of important changes (like a 
bugfix that prevented them from using the ebuild previously).
Certainly you wouldn't consider whitespace changes or coding style 
updates as an *important*, would you?


Marius
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Donnie Berkholz
Henrik Brix Andersen wrote:
 On Sat, Jun 10, 2006 at 01:13:36PM +0100, Christel Dahlskjaer wrote:
 To take an example, there were made up quotes in my GWN interview,
 however, nothing of great harm. I believe that time it was a case of
 attempting to make it more fun, it is however a worrying trend.
 
 One of my blog entries was also over-interpreted and included in the
 GWN without consulting me first, causing a mail storm in my inbox from
 angry users of xsupplicant:

If errors in the GWN result in large numbers of emails directly to you
rather than to the GWN, maybe the developer's email link shouldn't be
included in articles and feedback should instead be linked to gwn-feedback.

The GWN is a fairly independent publication, so I think it should be
free to make its own mistakes as long as it retains journalistic
integrity. But perhaps it could benefit from some sort of advisory board
of Gentoo developers/staff?

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

2006-06-11 Thread Alec Warner

Donnie Berkholz wrote:

Henrik Brix Andersen wrote:


On Sat, Jun 10, 2006 at 01:13:36PM +0100, Christel Dahlskjaer wrote:


To take an example, there were made up quotes in my GWN interview,
however, nothing of great harm. I believe that time it was a case of
attempting to make it more fun, it is however a worrying trend.


One of my blog entries was also over-interpreted and included in the
GWN without consulting me first, causing a mail storm in my inbox from
angry users of xsupplicant:



If errors in the GWN result in large numbers of emails directly to you
rather than to the GWN, maybe the developer's email link shouldn't be
included in articles and feedback should instead be linked to gwn-feedback.

The GWN is a fairly independent publication, so I think it should be
free to make its own mistakes as long as it retains journalistic
integrity. But perhaps it could benefit from some sort of advisory board
of Gentoo developers/staff?


Er the GWN is currently a Gentoo Project.

http://www.gentoo.org/proj/en/pr/gwn.xml

Although apparently the project page needs updating ;)



Thanks,
Donnie



--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] aging ebuilds with unstable keywords

2006-06-11 Thread Daniel Ahlberg
Hi,

This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 15545 ebuilds.

The page shows results from a number of tests that are run against the ebuilds. 
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from 
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.

The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]

Script has been running for 218 minutes.

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-portage-dev] updated portage cache progress patch

2006-06-11 Thread Jason Pepas

Hello,

Now that there is a new version of portage out (2.1), I updated my 
portage cache progress patch.  If the --verbose option is given, it 
shows more information while updating the portage cache.


normal behavior:

 Updating Portage cache: 18%

verbose behavior:

 Updating Portage cache: 18% (dev-db/libpq)

This patch is very hackish and ugly, as I was simply trying to work 
around the existing logic rather than really understand what was going 
on.  Perhaps someone else can clean it up a bit and integrate it into 
the next release.


-jason
--- emerge.orig	2006-06-11 04:05:46.0 -0500
+++ emerge	2006-06-11 04:20:56.0 -0500
@@ -2920,7 +2920,7 @@
 
 	if os.path.exists(myportdir+/metadata/cache) and updatecache_flg:
 		if --quiet not in myopts:
-			print \n Updating Portage cache:  ,
+			print \n Updating Portage cache: ,
 		os.umask(0002)
 		cachedir = os.path.normpath(portage.settings.depcachedir)
 		if cachedir in [/,/bin, /dev,  /etc,  /home,
@@ -2982,9 +2982,16 @@
 self.min_cp_all = l/100.0
 self.count = 1
 self.pstr = ''
+self.prev_pstr_len = 0
+self.bksp_len = 0
+self.cur = 0
+self.last_shown = 0
+self.cur_pkg = None
 
 			def __iter__(self):
 for x in self.cp_all:
+	self.cur_pkg = x
+	self.cur = self.cur+1
 	self.count += 1
 	if self.count  self.min_cp_all:
 		self.call_update_min = 0
@@ -2994,14 +3001,22 @@
 self.call_update_mine = 0
 
 			def update(self, *arg):
-try:self.pstr = int(self.pstr) + 1
-except ValueError:	self.pstr = 1
-sys.stdout.write(%s%i%% % (\b * (len(str(self.pstr))+1), self.pstr))
-sys.stdout.flush()
-self.call_update_min = 1000
+if self.last_shown  self.cur:
+	bksp = %s % (\b * self.bksp_len)
+	self.pstr = %.0f%% % (float(self.cur)/len(self.cp_all)*100)
+	if --verbose in myopts:
+		self.pstr = self.pstr +  (%s) % (self.cur_pkg)
+	erasure =   * max(self.prev_pstr_len - len(self.pstr), 0)
+	self.prev_pstr_len = len(self.pstr)
+	self.bksp_len = len(self.pstr) + len(erasure)
+	sys.stdout.write(%s%s%s % (bksp, self.pstr, erasure))
+	sys.stdout.flush()
+	self.call_update_min = 1000
+	self.last_shown = self.cur
 
 			def finish(self, *arg):
-sys.stdout.write(\b\b\b\b100%\n)
+self.update()
+sys.stdout.write(\n)
 sys.stdout.flush()
 
 
@@ -3014,7 +3029,7 @@
 			noise_maker = cache.util.quiet_mirroring()
 		else:
 			noise_maker = source = percentage_noise_maker(pdb)
-		cache.util.mirror_cache(source, cm, pdb.auxdb[porttree_root], eclass_cache=ec, verbose_instance=noise_maker)
+		cache.util.mirror_cache(source, cm, pdb.auxdb[porttree_root], eclass_cache=ec, verbose_instance=noise_maker, myopts=myopts)
 
 		sys.stdout.flush()
 
--- util.py.orig	2006-06-11 04:25:52.0 -0500
+++ util.py	2006-06-11 04:25:56.0 -0500
@@ -5,7 +5,7 @@
 
 import cache_errors
 
-def mirror_cache(valid_nodes_iterable, src_cache, trg_cache, eclass_cache=None, verbose_instance=None):
+def mirror_cache(valid_nodes_iterable, src_cache, trg_cache, eclass_cache=None, verbose_instance=None, myopts=None):
 
 	if not src_cache.complete_eclass_entries and not eclass_cache:
 		raise Exception(eclass_cache required for cache's of class %s! % src_cache.__class__)
@@ -69,7 +69,7 @@
 noise.exception(x, ce)
 del ce
 continue
-		if count = noise.call_update_min:
+		if count = noise.call_update_min or --verbose in myopts:
 			noise.update(x)
 			count = 0