[gentoo-dev] One-Day Gentoo Council Reminder for January

2008-01-09 Thread Mike Frysinger
This is your one-day friendly reminder !  The monthly Gentoo Council
meeting is tomorrow in #gentoo-council on irc.freenode.net.  See the
channel topic for the exact time (but it's probably 2000 UTC).

If you're supposed to show up, please show up.  If you're not supposed
to show up, then show up anyways and watch your Council monkeys dance
for you.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Fabian Groffen
On 07-01-2008 22:31:54 +0100, Luca Barbato wrote:
 Here is a list of interesting questions: Are we fine? What are we
 going to do?

GNUstep

 Are we fine?

I'd say thanks to voyageur (much kudos to the guy) GNUstep is back where
it should be within Gentoo and up-to-date.  Eclass changes, package
changes, all just got better.

 What are we going to do:

Probably trying to keep it up-to-date like it is right now, and try to
be the best distro for GNUstep users.  Of course we'll hope that Etoile
becomes less buggy and more usable.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] New developer : Jean-Noël Rivasseau (elvanor)

2008-01-09 Thread Bernard Cafarelli

On Tue, 08 Jan 2008 15:26:04 +0100, Rémi Cardona [EMAIL PROTECTED] wrote:
 Pierre-Yves Rofes a écrit :
 On Tue, January 8, 2008 1:29 pm, Denis Dupeyron wrote:
 So please give a warm welcome to Jean-Noël as a new Gentoo developer.


 Yay for the french conspiracy growing yet again :)
 
 We'll have to have another conspiracy beer-meeting then ;)
Yay for conspiracy beer-meetings :)

 
 Welcome to you Jean-Noël!

 
 Welcome from me as well.

And welcome from me too, Jean-Noël! 

-- 
Bernard



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



Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Petteri Räty

Luca Barbato kirjoitti:


Please project leaders try to reply in short.


Recruiters



About the stuff I'm involved:

Are we fine?


If Calchan agrees, we are fine.


What are we going to do:



Keep going as usual.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Denis Dupeyron
On Jan 9, 2008 1:12 PM, Petteri Räty [EMAIL PROTECTED] wrote:
 Recruiters

 
  About the stuff I'm involved:
 
  Are we fine?

 If Calchan agrees, we are fine.

I'm taking care of recruits as fast as I can. I figure any time I
spend for the recruiters project is worth a lot more than the same
time spent on fixing dev-embedded, sci-electronics or other exotic
ebuilds I usually maintain. The good news is I'm close to being able
to keep up, i.e. there is very little backlog if any. The bad news is
that we'd need to recruit more, and if an additional flow of recruits
were to arrive (and that would be welcome) a backlog would certainly
start to build up. Also I'm traveling more than I used to (and would
like) nowadays, and I'm going to move to the US this summer. So you
should expect some offlineness from my part for a few months while I
swim across the pond.

  What are we going to do:
 

 Keep going as usual.

All in all, we'd need an additional recruiter. Candidates are welcome,
but you should know that although it is a very gratifying job, it
takes a lot of time and dedication if you want to do it properly. Each
recruit takes me anywhere between 6 and 12 hours depending on how many
gaps I have to fill. We need as many recruits as possible, but need to
have them of sufficient quality. One way to go is to reject those that
aren't good enough, and another is to bring as many as you can to a
level where they can be useful. I much prefer the latter because I
don't think we can afford the former.

We would also need to attract more recruits. I'm doing my best to
relay queries from potential recruits to various teams and projects,
but I'm afraid to say it's seldom that these are answered. So please,
whoever you are and even if you're not a project/team leader, next
time you're forwarded such mail by me please reply to the user's
queries. At the very least you should politely decline the offer. And
mentoring will take you some time, but it's time well invested for the
future of your project.

Finally, if you're a mentor, or are considering mentoring somebody, do
not hesitate to contact us in case you have any questions. I have
tried to update our documentation recently, so you'll find valuable
practical information in there although more could be needed
(suggestions welcome). And do not hesitate to go hunting for recruits
instead of complaining you don't have enough time managing your Gentoo
stuff. For that too we'll be happy to advise.

Happy new year to each one of you.
Denis.


Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Samuli Suominen
On Mon, 07 Jan 2008 22:31:54 +0100
Luca Barbato [EMAIL PROTECTED] wrote:

 Here is a list of interesting questions: Are we fine? What are we
 going to do?
 
 Please project leaders try to reply in short.

xfce (has no lead, it's angelos, welp or me) - we are good, few ~minor
bugs, everything up to date

treecleaners - needs more developers (please) to review  save the stuff
that is getting removed so it doesn't end up as a tool that few devs
can use to punt stuff they want, but others use(!)

  - gfx  : nothing much under the sun, bumping stuff here and there.

I just joined gfx, will try to contribute some more.


- drac
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 9 Jan 2008 15:37:47 +0100
Christian Faulhammer [EMAIL PROTECTED] wrote:
 Christian Faulhammer [EMAIL PROTECTED]:
   A quick check [...]
 
  Hereby you have proven that you are not interested about
 real arguments...some people have tried to gather facts and you pick
 those that maybe have a weak reasoning or come from people you know
 how to upset.  Congratulations.

Actually, I've taken to ignoring people who're just outright wrong.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 09 Jan 2008 04:11:58 +0100
Matthias Langer [EMAIL PROTECTED] wrote:
 Really, this discussion is completely pointless unless some mips
 users/developers join in - or aren't there any at all?

I'd imagine most of them are staying well clear of it because they've
already seen this discussion a dozen times before and know that it's
just the usual malcontents going around making largely bogus claims and
backing them up with lots of thinly veiled mips bashing rather than
anything relevant...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Tue, 08 Jan 2008 18:59:29 -0800
Chris Gianelloni [EMAIL PROTECTED] wrote:
 The issue that was raised is that certain arch teams are incapable of
 keeping up with the minimal workload they already have and what should
 be done about it.

The issue was raised, with absolutely no proof or justification, and
every previous time said issue has been raised it's turned out to be
somewhere between highly misleading and utter bollocks.

 We want the Council to do something about this issue. You can deny
 the issue all that you want or try to deflect conversation from the
 actual issue, but your opinion isn't very important to the much of
 the current developer pool, seeing as how it doesn't affect you in
 any way, having been thrown from the project, and all.

Ah, so now what matters is who says something, not whether or not it's
true.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

2008-01-09 Thread Caleb Tennis
 Why taking it against arch teams? How is that different from certain
 maintainer not taking care of a bug that holds stabilization of certain
 package by some time measured in months ? I'll tell you my answer: 'no
 difference at all'.

You are right, there's not much difference.  However, I brought up the topic 
because
I felt like this particular situation was a bit of a problem that needed to be
addressed.  Yours is also one that can/should potentially be addressed, and I 
advise
you to recommend the council discuss it as well.

My goal wasn't to point fingers or to call anyone lazy.  My goal was to address 
that
if development in this certain area has stagnated, how can those of us who it
affects continue to move forward?  This is simply an area that is gray and 
needs
to be discussed.  There are many other gray areas that need to be discussed too.

I understand we all have real lives and are volunteers.  But if there are areas 
that
we are responsible for and we aren't able to meet the needs/demands of the other
developers in those areas, it's only fair to let them continue moving forward.

I never even mentioned any specific arch in my original request, nor did I call 
any
developer out.  So please, nobody needs to take this personally.

Caleb

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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Alec Warner
On 1/8/08, Ciaran McCreesh [EMAIL PROTECTED] wrote:
 On Tue, 8 Jan 2008 18:44:22 -0800
 Alec Warner [EMAIL PROTECTED] wrote:
   Uh... So where do the original problems come from? Are you saying
   that packages mysteriously start breaking on their own because
   no-one's maintaining them?
 
  Of course they do

 Ah, right. Because of the magical elf that lives in the CVS server
 that mysteriously goes around breaking dependencies when no-one's
 looking.

 Yes, a magical elf. Much more plausible than the theory that it's
 actually developers screwing up by dropping keywords or best keyworded
 version on a package's deps.

I was going to go with 'the stable glibc changed' or 'some lib this
software depended on was updated to a new version' or any other action
that could cause software to not work as intended.

I'm not trying to make the argument that developers don't screw up.
Certainly mr_bones can attest that they do it on a daily basis.

I think the argument here is that developers control ebuilds.  If a
given ebuild is causing 'trouble' for a maintainer it is within their
control to remove the ebuild.  Just as if a given package is causing
the maintainer grief it can be deleted from the tree, so can keywords
for a given arch be removed for a given ebuild (and possibly that
ebuild removed because it is known to be old and buggy.)

If the arch team wants that ebuild in the tree they should do some
work to keep a given package up to date in terms of other arches or we
should define some sort of metadata that notifies people that the arch
team is the 'maintainer' for a given version of a package.

I agree that you should not break the arch's tree by removing a given
package (or it's last stable ebuild).
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 9 Jan 2008 06:58:40 -0800
Alec Warner [EMAIL PROTECTED] wrote:
 I think the argument here is that developers control ebuilds.  If a
 given ebuild is causing 'trouble' for a maintainer it is within their
 control to remove the ebuild.  Just as if a given package is causing
 the maintainer grief it can be deleted from the tree, so can keywords
 for a given arch be removed for a given ebuild (and possibly that
 ebuild removed because it is known to be old and buggy.)
 
 If the arch team wants that ebuild in the tree they should do some
 work to keep a given package up to date in terms of other arches or we
 should define some sort of metadata that notifies people that the arch
 team is the 'maintainer' for a given version of a package.

The problem is this: the impact upon an arch of dekeywording something
is almost always far higher than the impact of leaving things the way
they are. And even if, like some people here, you don't care about the
arch, the impact upon the rest of the tree when you dekeyword is often
massive. If, for example, an arch were to have their last stable
keyword of something like gtk+ removed by a developer who did it in
order to 'fix' a repoman message, a very large number of other
developers would then end up with a far bigger repoman mess.

Heck, most of the repoman messages people are moaning about are caused
by developers doing exactly this.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Re: Projects and subproject status

2008-01-09 Thread Christian Faulhammer

Hi,

CCing gentoo-lisp mailing list.

Luca Barbato [EMAIL PROTECTED]:
 Please project leaders try to reply in short.

 Though Emacs project (subproject of Lisp) has no official leader, I
speak up as senior dev. :)
 
 Are we fine?

XEmacs:
I cannot tell much, but graaff seems to have closed most of the severe
bugs and worked on having more/bette eclasses for the app-xemacs
category.

GNU Emacs:
 * We took care of nearly all incoming bugs and punched ones
still sitting around
 * Started keywording all packages with stable x86 and amd64 (majority
is done)
 * Split up of eselect-ctags and eselect-emacs so them Vim wheenies
stop crying (just after Portage was able to handle needed upgrade path
correctly)
 * Files which enable additional packages from app-emacs category in
Emacs are now stored in /usr/share/emacs/site-lisp/site-gentoo.d/, with
full backwards compatability (fully transparent for non-aware users).
emacs-updater from eselec-emacs package can check if you still have
site files in the old location.
 * Support for echangelog (by C-c C-a) in app-emacs/gentoo-syntax
 * Man, we got so many test plans for our packages that arch teams
should be able to stabilise our packages in the blink of an eye.
 * Fixed some more packages that were working but not in a good shape
regarding coding practice (Emacs and Ebuild)

 What are we going to do:

 * Improve the tree further, though we are nearly done
 * Bring some really handy packages into the tree from our overlay
 * Improve gentoo-syntax to use the whole Gentoo toolchain for Ebuild
developers

 V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

URL:http://www.faulhammer.org/


signature.asc
Description: PGP signature


[gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Christian Faulhammer
Hi,

Christian Faulhammer [EMAIL PROTECTED]:
  A quick check [...]

 Hereby you have proven that you are not interested about
real arguments...some people have tried to gather facts and you pick
those that maybe have a weak reasoning or come from people you know how
to upset.  Congratulations.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

URL:http://www.faulhammer.org/


signature.asc
Description: PGP signature


Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Brent Baude

For the ppc64 project


Are we fine?
  
- The induction of the PS3 has helped us a lot.  We have more users than 
before.  Great variance skill-wise amongst those users but interest 
level is high.  We need more folks on the dev team but otherwise we're 
as healthy as we've ever been.
- Just put a ps3 dev profile into portage to begin moving towards our 
longer term goals
- Lu_zero and I have added a couple of ps3 specific ebuilds into the 
tree; previously were in the cell overlay



What are we going to do:
  
- Anticipating gcc-4.3 and the love it is supposed to bring, 
specifically cell optimizations.

- BAU


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Scanned with Copfilter Version 0.84beta3a (ProxSMTP 1.6)
AntiVirus: ClamAV 0.91.2/5451 - Wed Jan  9 03:07:04 2008
by Markus Madlener @ http://www.copfilter.org
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

2008-01-09 Thread Fernando J. Pereda
On Wed, Jan 09, 2008 at 09:25:11AM -0500, Caleb Tennis wrote:
  Why taking it against arch teams? How is that different from
  certain maintainer not taking care of a bug that holds
  stabilization of certain package by some time measured in months ?
  I'll tell you my answer: 'no difference at all'.

 You are right, there's not much difference.  However, I brought up the
 topic because I felt like this particular situation was a bit of a
 problem that needed to be addressed.  Yours is also one that
 can/should potentially be addressed, and I advise you to recommend the
 council discuss it as well.

Well, while discussing what you brought up, they should _also_ consider
what I said as part of the same (so-called) problem.

 My goal wasn't to point fingers or to call anyone lazy.  My goal was
 to address that if development in this certain area has stagnated, how
 can those of us who it affects continue to move forward?  This is
 simply an area that is gray and needs to be discussed.  There are
 many other gray areas that need to be discussed too.

 I understand we all have real lives and are volunteers.  But if there
 are areas that we are responsible for and we aren't able to meet the
 needs/demands of the other developers in those areas, it's only fair
 to let them continue moving forward.

 I never even mentioned any specific arch in my original request, nor
 did I call any developer out.  So please, nobody needs to take this
 personally.

I didn't take it personally myself, honestly, I couldn't care less.

Wonder why there is almost no non-mainstream arch team people
contributing to this thread?

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4


pgpOiXoZzRjqH.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Caleb Tennis
 I'd imagine most of them are staying well clear of it because they've
 already seen this discussion a dozen times before and know that it's
 just the usual malcontents going around making largely bogus claims and
 backing them up with lots of thinly veiled mips bashing rather than
 anything relevant...

Your demand for evidence in this thread doesn't seem balanced with your ability 
to
only offer speculation.

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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Caleb Tennis
 The issue was raised, with absolutely no proof or justification, and
 every previous time said issue has been raised it's turned out to be
 somewhere between highly misleading and utter bollocks.

Let's assume that you are right, and that dropping keywords is not a proper 
thing to
do.

What's the proper fix for when keyword requests stagnate in bugzilla?  If the 
arch
team in question was to completely disband and stop all keywording today, then
you're suggesting the proper thing to do is to never remove the ebuild from 
portage
that has keywords for that arch?

And thus, the current system of filing a stabilization request and waiting
indefinitely is sufficient?

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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 9 Jan 2008 10:36:13 -0500 (EST)
Caleb Tennis [EMAIL PROTECTED] wrote:
  The issue was raised, with absolutely no proof or justification, and
  every previous time said issue has been raised it's turned out to be
  somewhere between highly misleading and utter bollocks.
 
 Let's assume that you are right, and that dropping keywords is not a
 proper thing to do.
 
 What's the proper fix for when keyword requests stagnate in
 bugzilla?

That depends upon whether the keyword request is important. If it isn't,
you wait for the arch team to get around to it. If it is (and
legitimately so -- we're not talking spurious I want to remove this
old version that doesn't affect anything, that works fine and isn't
causing any problems beyond it existing here), you ask the arch team to
prioritise it, explaining why.

 If the arch team in question was to completely disband and
 stop all keywording today, then you're suggesting the proper thing to
 do is to never remove the ebuild from portage that has keywords for
 that arch?

If that ever comes remotely close to happening then the issue can be
raised when it does. You might as well ask what would happen if
suddenly all the KDE maintainers disappeared.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Projects and subproject status: KDE

2008-01-09 Thread Wulf C. Krueger

- KDE 3  KDE 4
- KDE-related stuff


Are we fine?


All in all, we're doing acceptably well, I'd say. In some areas, we're  
doing really well.


I've recently mentored two new recruits, namely Ingmar Ingmar  
Vanhassel and Bo zlin Andresen who will hopefully soon become new  
members of the KDE herd. These new slav^H^H^H^Hhelpers ;) are both  
great additions to the herd and will allow us to become more efficient  
in the near future.



KDE 3: We're still fixing bugs but should soon be able to finally  
stabilise 3.5.8. This took us much longer than I wanted it to but I'm  
under heavy workload in real life and had to take some time off from  
Gentoo.


We still have 3.5.5 in the tree but that's going to change once either  
Carlo or myself will make ourselves remove those ebuilds. If we remove  
them, this can lead to some breakage for a certain arch but they've  
known for long enough now: http://bugs.gentoo.org/show_bug.cgi?id=188857


KDE 3 is pretty solid now apart from some bugs we're tackling along the way.


KDE 4: A core team consisting of volunteers from the KDE herd and  
interested users (that's how tgurr, Ingmar and zlin got on board or  
are going to get on board as devs. :-) ) as well as some help from  
interested fellow devs is working on a new set of eclasses (going to  
be submitted here very soon) and ebuilds (both monolithic and split  
ebuilds; splits being the new default) for KDE 4.


KDE 4.0.0 will be released on January, 11th 2008, and if things keep  
going like they do now we might be able to put all the stuff into  
~arch on the release day.

I'm going to mail about this again in -core soon.

The excellent cooperation among the core team members and all others  
involved in KDE4 in Gentoo is truly amazing and makes me really proud  
to be a part of this effort. I'm happy and optimistic about things to  
come if we manage to keep some of the drive we currently have.


--
Best regards, Wulf

pgpw0oqxeYuxl.pgp
Description: PGP Digital Signature


RE: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Chrissy Fullam
 Ferris McCormick wrote:
 With all due respect, for some reason we don't have Proctors 
 anymore to enforce the CoC.  Thus, things we would expect the 
 proctors to catch and handle under CoC get sent to devrel 
 instead.  All I am doing is wondering out loud (now that CoC 
 is coming alive again) if we should start processing these 
 under CoC rules.  I'm asking Council because CoC belongs to 
 Council, but I do not expect a ruling, just perhaps an 
 interesting discussion.  See, these things can't be caught 
 before they get to devrel because you ensured there would be 
 no one to catch them --- you are the one who wanted to kill 
 off the proctors, after all.

Please lay off the personal attacks here; it's getting beyond ridiculous.
Wolf31o2 is not the only council member who wanted to 'kill off the
proctors', see below:
http://www.gentoo.org/proj/en/council/meeting-logs/20070712-summary.txt
- Kingtaco wanted a vote to cancel the proctors. robbat2 wanted them to just
  die quietly if no material was forthcoming. Others called for a definate
  stand rather than the die quietly. All 5 attending council members voted
  in favour of dropping the proctors.
Seems to me that every council member in attendance decided they wanted to
'kill off the proctors.'

Kind regards,
Christina Fullam
Gentoo Developer Relations Lead | Gentoo Public Relations 

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



Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

2008-01-09 Thread Richard Freeman
I wanted to take this thread in a slightly different direction so that 
the council has a little more to work with tomorrow.  Obviously there 
are multiple opinions on whether a problem currently exists - and the 
council will need to decide on this.  If no problem currently exists 
they will likely take no action.  However, if a problem does exist, what 
would be a reasonable solution?


Here's a proposal.  Maybe not a great one - feel free to come up with 
others (other than just do nothing - if we are going to do nothing we 
don't need to work out what that will be).  I think it gives arch teams 
a fair amount of time to keep up with stable requests, but also allows 
package maintainers to eventually get rid of cruft.  The exact 
timeframes are of course the easiest and most obvious things to modify.


My hope is that this will give everybody something to think about so 
that if a decision to enact policy is made tomorrow the policy is a good 
one...



Ebuild Stabilization Time

Arch teams will normally have until the LATER of the following two dates 
to stabilize ebuilds for non-security-related issues:
1.  60 days from the day the last substantial change was made to the 
ebuild (clock resets if a non-trivial change is made to the ebuild). 
That's 30 days to allow the package to be proven stable, and 30 days to 
do something about it.
2.  30 days from the day a bug was filed and keyworded STABLEREQ and the 
arch was CCed and the maintainer either filed the bug or commented that 
it was OK to stabilize (clock starts when all of these conditions are met).


Perhaps the guideline should be one week on both time periods for 
security bugs.



Technical Problems With Ebuild Revisions

If an arch team finds a technical problem with an ebuild preventing 
stabilization a bug will be logged as a blocker for the stable keyword 
request.  The bug being resolved counts as a substantial change for the 
purpose of #1 above.



Removing Stable Ebuilds.

If an ebuild meets the time criteria above and there are no technical 
issues preventing stabilization, then the maintainer MAY choose to 
delete an older version even if it is the most recent stable version for 
a particular arch.


If an ebuild meets the time criteria and there IS a technical problem 
preventing stabilization, but the package is subject to security issues, 
the maintainer MAY choose to mask the vulnerable versions in package.mask.


If an ebuild does not meet the time criteria or there is a technical 
problem preventing stabilization and there isn't an outstanding security 
issue, then the maintainer must not remove the highest-versioned stable 
ebuild for any given arch.



Spirit of Cooperation

Ebuild maintainers and arch teams are encouraged to work together for 
the sake of each other and end users in facilitating the testing and 
maintenance of ebuilds on obscure hardware or where obscure expertise is 
needed.  Package maintainers are encouraged to use discretion when 
removing ebuilds in accordance with this policy.

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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 09 Jan 2008 17:49:40 +0100
Wulf C. Krueger [EMAIL PROTECTED] wrote:
  What's the proper fix for when keyword requests stagnate in
  bugzilla?
  That depends upon whether the keyword request is important.
 
 Let's take a real world example: KDE 3.5.5 is old, buggy and has
 some important issues which won't be fixed anymore.

Yet it's the most proven version on mips.

  If it is (and legitimately so
 
 I hope you'll accept it when I say that 3.5.5 is such a legitimate
 case now.

Why? It was good enough to be keyworded stable at one point.

 What would you suggest to do now? I think we've done all we could  
 short of the following:
 
 a) Drop all keywords but those of mips. Leaves mips and, more  
 importantly, its users with a vulnerable and unmaintained set of  
 packages.

...and break the tree spectacularly, causing huge amounts of pain for
your fellow developers when they encounter horrible repoman output when
they try to do anything.

 b) package.mask 3.5.5 with a big, fat warning and let the users  
 decide. Same drawbacks as a).

...and break the tree spectacularly, causing huge amounts of pain for
your fellow developers when they encounter horrible repoman output when
they try to do anything.

 c) Drop 3.5.5 from the tree. The cleanest but most radical solution.  
 If mips' users want KDE, they would have to bug (sic!) the mips team.

...and break the tree spectacularly, causing huge amounts of pain for
your fellow developers when they encounter horrible repoman output when
they try to do anything.

 The solution I favour by far is c). What's your suggestion or did I  
 miss any other viable solution? Just doing nothing is not an option  
 here, I'd say, but state your case.

3.5.5 was good enough to be keyworded stable at one point. Thus, it
can't be *that* bad.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Roy Marples
On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote:
 3.5.5 was good enough to be keyworded stable at one point. Thus, it
 can't be *that* bad.

So what happens if a flaw is discovered in KDE 3.5.5 that allows root
access?

In your world you allow mips users to trivially install now flawed and
insecure software, instead of having to add
to /etc/portage/package.keywords or package.unmask

Yes, this breaks their tree, but it's fixable from the users end as we
can rest in the knowledge that mips users have acknowledged the security
flaw by adding the package to the above mentioned files.

Thanks

Roy

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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Alec Warner
On 1/9/08, Ciaran McCreesh [EMAIL PROTECTED] wrote:
 On Wed, 09 Jan 2008 17:49:40 +0100
 Wulf C. Krueger [EMAIL PROTECTED] wrote:
   What's the proper fix for when keyword requests stagnate in
   bugzilla?
   That depends upon whether the keyword request is important.
 
  Let's take a real world example: KDE 3.5.5 is old, buggy and has
  some important issues which won't be fixed anymore.

 Yet it's the most proven version on mips.

   If it is (and legitimately so
 
  I hope you'll accept it when I say that 3.5.5 is such a legitimate
  case now.

 Why? It was good enough to be keyworded stable at one point.

  What would you suggest to do now? I think we've done all we could
  short of the following:
 
  a) Drop all keywords but those of mips. Leaves mips and, more
  importantly, its users with a vulnerable and unmaintained set of
  packages.

 ...and break the tree spectacularly, causing huge amounts of pain for
 your fellow developers when they encounter horrible repoman output when
 they try to do anything.

  b) package.mask 3.5.5 with a big, fat warning and let the users
  decide. Same drawbacks as a).

 ...and break the tree spectacularly, causing huge amounts of pain for
 your fellow developers when they encounter horrible repoman output when
 they try to do anything.

  c) Drop 3.5.5 from the tree. The cleanest but most radical solution.
  If mips' users want KDE, they would have to bug (sic!) the mips team.

 ...and break the tree spectacularly, causing huge amounts of pain for
 your fellow developers when they encounter horrible repoman output when
 they try to do anything.

Actually if they dump kde-3.5.5 and anything depending on it, then
they don't break the tree and everyone is happy, no?
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 9 Jan 2008 10:07:31 -0800
Alec Warner [EMAIL PROTECTED] wrote:
 Actually if they dump kde-3.5.5 and anything depending on it, then
 they don't break the tree and everyone is happy, no?

Everyone except the users, who end up with pages and pages of horrible
Portage output...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 09 Jan 2008 17:27:52 +
Roy Marples [EMAIL PROTECTED] wrote:
 On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote:
  3.5.5 was good enough to be keyworded stable at one point. Thus, it
  can't be *that* bad.
 
 So what happens if a flaw is discovered in KDE 3.5.5 that allows root
 access?

Then the one particular part of 3.5.5 that's affected gets fixed and
priority keyworded.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Wulf C. Krueger
On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote:
  So what happens if a flaw is discovered in KDE 3.5.5 that allows root
  access?
 Then the one particular part of 3.5.5 that's affected gets fixed and
 priority keyworded.

So you suggest that mips keeps doing nothing and expect others to work 
*more* in exchange for that?

-- 
Best regards, Wulf


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 9 Jan 2008 19:29:53 +0100
Wulf C. Krueger [EMAIL PROTECTED] wrote:
 On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote:
   So what happens if a flaw is discovered in KDE 3.5.5 that allows
   root access?
  Then the one particular part of 3.5.5 that's affected gets fixed and
  priority keyworded.
 
 So you suggest that mips keeps doing nothing and expect others to
 work *more* in exchange for that?

Well, most users will simply ignore or postpone the mass upgrade, so
yes. Forcing a mass upgrade is rarely if ever the correct solution to
any security issue.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] gnupg-1, gnupg-2, gpgme, slight apology

2008-01-09 Thread William L. Thomson Jr.
First off to get the apology out of the way. Me being a user of both
seahorse and gnupg, I wasn't fully aware of the mess going on in between
the two. So in that regard I do apologize to Alon Bar-Lev ( alonbl ).
Things are not so cut and dry, and I could see where one might have the
need for eselect there. Although there might be other options as well.

The story as clear and concise as I can make it. Yes upstream created
gnupg-1 and gnupg-2 to co-exist. However upstream did not do anything to
address a VERY popular wrapper to gnugp, gpgme. Presently most apps like
seahorse use gpgme to interface with gnupg. Instead of doing it
directly. At the present time you end up linking gpgme to either gnupg-1
or gnupg-2. No means to do both, and that's where the eselect part comes
into play. Ideally apps should interface directly, but upstream didn't
really encourage that, and it's why gpgme exists in the first place.
Which might die.

There are other issues, like gpgme executing gpg on each invocation. So
it's hardly ideal and from what Robin (robbat2) has told me. They might
be getting rid of gpgme and/or introducing a --server flag or something
like that for gnupg. Not 100% clear there and doesn't really matter per
our present problems and situations. But would be a performance benefit
from that change :)

Despite other distros shipping both gnupg-1 and gnupg-2. They are just
now seeing the problems. Because being binary, I don't believe gpgme was
ever linked against gnupg-2. So it's there for users, but apps really
aren't bound to it. So some like Debian are hitting this now, when we
ran into it a year ago.

Now that their is full understanding, and some clarity. It still doesn't
present us with a solution at this time. Seems like most all issues with
gnupg-2 have been worked out, but a few remain. Not sure how important
it is to address those. I have no doubt both Alon and Robin are working
on those as time permits.

Slots and eselect is one way to go. I mentioned to Robin, maybe doing a
USE flag on gpgme, to control what it's bound to, like gpg2 or gpg,
since the later is already a USE flag I believe. Slotting both in the
mean time, till the gpgme mess is cleared up. That way users could chose
what gpgme is linked to, and still use gnupg-2/gnupg-1 or etc. But like
before, totally up to those working on it, Alon and Robin.

Anyway just wanted to take a moment to apologize a bit. It's quite a
mess, and I do appreciate those in Gentoo undertaking it, and seeing it
through. Very sorry for any flack or abrasiveness. Just got sucked into
all this as just a user of said apps.

But really most all are problems are gpgme. Upstream is JUST now
starting to acknowledge that problem. When people have been pointing it
out for over a year :) It's a wonderful mess.

-- 
William L. Thomson Jr.
Gentoo/Java


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 09 Jan 2008 20:50:38 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
 So you just ignore for example my post about CIA activity for the
 mips team?

That falls into the highly misleading category.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Petteri Räty

Ciaran McCreesh kirjoitti:

On Tue, 08 Jan 2008 18:59:29 -0800
Chris Gianelloni [EMAIL PROTECTED] wrote:

The issue that was raised is that certain arch teams are incapable of
keeping up with the minimal workload they already have and what should
be done about it.


The issue was raised, with absolutely no proof or justification, and
every previous time said issue has been raised it's turned out to be
somewhere between highly misleading and utter bollocks.



So you just ignore for example my post about CIA activity for the mips team?

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Ciaran McCreesh
On Wed, 9 Jan 2008 20:06:00 +0100
Wulf C. Krueger [EMAIL PROTECTED] wrote:
 On Wednesday, 09. January 2008 19:45:38 Ciaran McCreesh wrote:
Then the one particular part of 3.5.5 that's affected gets fixed
and priority keyworded.
   So you suggest that mips keeps doing nothing and expect others to
   work *more* in exchange for that?
  Well, most users will simply ignore or postpone the mass upgrade, 
 
 So far so good. If users postpone it, that's entirely their 
 responsibility.

It's all very well to say that, but which do you care about? Covering
your ass and claiming that you have a secure distribution, or the
security of end user systems?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Roy Marples
On Wednesday 09 January 2008 18:16:24 Ciaran McCreesh wrote:
 On Wed, 09 Jan 2008 17:27:52 +

 Roy Marples [EMAIL PROTECTED] wrote:
  On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote:
   3.5.5 was good enough to be keyworded stable at one point. Thus, it
   can't be *that* bad.
 
  So what happens if a flaw is discovered in KDE 3.5.5 that allows root
  access?

 Then the one particular part of 3.5.5 that's affected gets fixed and
 priority keyworded.

Lets say that there's just 3.5.5 and 3.5.8 in the tree.
3.5.5 is keyworded stable mips
3.5.8 doesn't have the mips keyword because it's horribly broken on mips

A security flaw is discovered in 3.5.5, the solution is to upgrade to 3.5.8.
This flaw involves code that has radically changed from 3.5.5 to 3.5.8. For 
the sake of argument say it will take 1 month of time for anyone to create a 
patch for 3.5.5 that fixes the flaw OR makes 3.5.8 magically work on mips.

During this month, what do you propose happens to the end user?

The choices are
1) Carry on as we are, user is blissfully unaware of security flaw and doesn't 
have time to read GLSA's, etc has he's busy with real life thereby giving 
Gentoo the reputation of shipping insecure software.
2) Force the user to spend a few minutes adding 3.5.5 to a package.unmask, 
thereby acknowledging the security flaw but by his own choice keeping the 
highly insecure software.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Wulf C. Krueger
On Wednesday, 09. January 2008 19:45:38 Ciaran McCreesh wrote:
   Then the one particular part of 3.5.5 that's affected gets fixed
   and priority keyworded.
  So you suggest that mips keeps doing nothing and expect others to
  work *more* in exchange for that?
 Well, most users will simply ignore or postpone the mass upgrade, 

So far so good. If users postpone it, that's entirely their 
responsibility.

 so yes. 

That's not so good, though, and where we really disagree. Thanks for the 
straight answer, though. 

In my book, it's not acceptable to not do one's job properly and by that  
force others to do more. You basically told me the same when I suggested 
likewise measures against mips. :-)

The only difference being that we supported KDE 3.5.5 for a long time and 
gave mips months to get up to speed again.

 Forcing a mass upgrade is rarely if ever the correct solution to 
 any security issue.

I absolutely agree. This, IMO, is such a case, though.

-- 
Best regards, Wulf


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


Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Luca Barbato
Petteri Räty wrote:
 
 - Get the remaining Generation 1 stuff out of the tree (not much left)
 - Start using virtuals more
 - Eclass cleanup and new make our setup even more automatic

any plan/idea about icedtea? as a ppc user I'd love too see it in
portage ^^;

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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



Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Luca Barbato
Ferris McCormick wrote:
 With all due respect, for some reason we don't have Proctors anymore to 
 enforce
 the CoC.

The perception is that they aren't/weren't _exactly_ needed as they are,
either because nobody wants the secret policy feeling or because self
regulation is working almost nicely.

 Thus, things we would expect the proctors to catch and handle under CoC
 get sent to devrel instead.  All I am doing is wondering out loud (now that 
 CoC
 is coming alive again) if we should start processing these under CoC rules.  
 I'm
 asking Council because CoC belongs to Council, but I do not expect a ruling,
 just perhaps an interesting discussion.  See, these things can't be caught 
 before
 they get to devrel because you ensured there would be no one to catch them ---
 you are the one who wanted to kill off the proctors, after all.

Item already present I think.

 I am asking a question as a member of the devrel confres subproject and as
 an interested developer.

you know the channel and the time ^^;

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Vlastimil Babka

Ciaran McCreesh wrote:
a) Drop all keywords but those of mips. Leaves mips and, more  
importantly, its users with a vulnerable and unmaintained set of  
packages.


...and break the tree spectacularly, causing huge amounts of pain for
your fellow developers when they encounter horrible repoman output when
they try to do anything.


Can somebody clarify to me why would it cause this? Maybe I just miss 
something.


VB
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 14:00 +, Ferris McCormick wrote:
 they get to devrel because you ensured there would be no one to catch
 them --- you are the one who wanted to kill off the proctors, after
 all.

...and the finger-pointing starts... Bravo!

I never have been able to figure out what the hell I did to you to make
you feel like you need to personally attack me every step of the way,
but I'm not putting up with it, anymore.

I'm adding Developer Relations to this email and will be filing a formal
complaint against you.  Have a good day.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 09:25 -0500, Caleb Tennis wrote:
 I never even mentioned any specific arch in my original request, nor
 did I call any developer out.  So please, nobody needs to take this
 personally.

Correct, you did not.  What I find absolutely *damning* is the fact that
as soon as any arches *were* mentioned, everybody was talking about the
same one.  It's rather funny that everybody seems to have the exact same
impression of what architecture might be a slacker and would be affected
by this.  I wonder why that is?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Pierre-Yves Rofes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh a écrit :
 On Wed, 9 Jan 2008 20:06:00 +0100
 Wulf C. Krueger [EMAIL PROTECTED] wrote:
 On Wednesday, 09. January 2008 19:45:38 Ciaran McCreesh wrote:
 Then the one particular part of 3.5.5 that's affected gets fixed
 and priority keyworded.
 So you suggest that mips keeps doing nothing and expect others to
 work *more* in exchange for that?
 Well, most users will simply ignore or postpone the mass upgrade, 
 So far so good. If users postpone it, that's entirely their 
 responsibility.
 
 It's all very well to say that, but which do you care about? Covering
 your ass and claiming that you have a secure distribution, or the
 security of end user systems?
 

And what's the point in caring about the security of users systems, when
some of them don't care themselves in the first place? Remember, Gentoo
is all about choices. If users choose to skip security updates, it's up
to them and there's nothing you can do to change it. When their boxes
get rooted due to unpatched vulnerabilities, maybe they'll change their
mind. Ok, I admit that a few dumbasses will claim that Gentoo sucks and
switch to another distro instead, but hey, that's just the way it is.

- --
Pierre-Yves Rofes
Gentoo Linux Security Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFHhSS/uhJ+ozIKI5gRAgJdAJjymZUrjZfg06W2TMohYZx3FSwsAJ9i4JD/
YZRXDJv/bZWzMXePfuP/Kg==
=SFc9
-END PGP SIGNATURE-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Luca Barbato
Wulf C. Krueger wrote:
 On Tuesday, 08. January 2008 22:44:17 Chrissy Fullam wrote:
 'bodies' would be needed to enforce CoC on #gentoo-dev 
 
 I don't really see any need for moderation on #gentoo-dev. We've managed 
 quite nicely without big brothers watching us so far and I think we 
 should simply keep doing that.

The main idea isn't to have big brothers, just have a set of minimum
requirements in order to make people deciding to kick/defer/ban/shun
other feel and look less arbitrary.

 Yes, people have been kicked or even banned in the heat of some 
 discussions but this basically regulated itself by those kicked (by 
 simply re-joining) or others removing those bans rather sooner than later 
 if they were inappropriate.

And that's perfectly fine and will remain the same hopefully =)

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 14:44 +, Ciaran McCreesh wrote:
  We want the Council to do something about this issue. You can deny
  the issue all that you want or try to deflect conversation from the
  actual issue, but your opinion isn't very important to the much of
  the current developer pool, seeing as how it doesn't affect you in
  any way, having been thrown from the project, and all.
 
 Ah, so now what matters is who says something, not whether or not it's
 true.

Well, when a non-developer who was thrown out of the project because his
attitude and approach was unwanted points out something and makes
statements as if he actually were still involved in the process of
maintaining packages or working on an architecture team and is unable to
get others to agree with him and insists that there isn't a problem but
is unable to back it up, then yes, it definitely does matter.  I'm just
making sure that people are aware of the situation, as you like to
portray yourself as important to the Gentoo project, when the project
has deemed you as not important and forcibly removed you.  Thanks for
playing, but you fail.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Luca Barbato
Ciaran McCreesh wrote:
 And why does repoman do that?
 
 Oh. Yeah. Because people with an attitude like yours think that the
 correct way to fix a repoman message is to start nuking arch keywords,
 ignoring what it does to the rest of the tree.

Dropping keywords works perfectly to have repoman quit complaining, you
just have to do a recursive dropping on the rdeps of this package.

 Perhaps because the people maintaining those archs have better things
 to do that deal with the same silly ill-thought-out arguments every
 three months.

cia/cvs commits ml says something different, gentoo wise at least.

 I mean, if vapier can maintain arm/sh/s390, by himself, to a better
 degree than the mips *TEAM* can do, that should be an indication of a
 problem.
 
 That's an interesting assertion. Can you back it up?

Feel free to run imlate scripts and come up with some numbers.

Note that I hate whining and I love get solutions.

MOST of the packages runs fine if they build fine, MOST of the
endian-issues or the 64bit-issues got caught by ppc and amd64 and there
aren't that many right now. Ugly arch specific codepath could be
present, but, as I said, usually you catch those breaking on gcc. So
having some way to test if the package builds (cross toolchain) and if
the package at least runs (qemu) IS something that should let small
arches with large tree coverage improve a bit. Otherwise you can just
reduce the tree coverage.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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



Re: [gentoo-dev] Projects and subproject status: KDE

2008-01-09 Thread Carsten Lohrke
 KDE 4.0.0 will be released on January, 11th 2008, and if things keep
 going like they do now we might be able to put all the stuff into
 ~arch on the release day.
 I'm going to mail about this again in -core soon.

Unless you mean hard masked, I do object. The code base has too many issues 
and is incomplete compared to KDE 3.5, so it's not ready to push it to the 
regular ~arch user, yet.


Carsten


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 15:11 +, Ciaran McCreesh wrote:
 Heck, most of the repoman messages people are moaning about are caused
 by developers doing exactly this.

No, most of the ones we're complaining about have nothing to do with
KEYWORDS, at all, and everything to do with changes to policy and such
that have been enacted since the ebuild was last touched.  See, repoman
doesn't care if you're just making a KEYWORD change or if you're making
coding changes to an ebuild.  It still will fail if something fails a QA
check, even if the failure is on an ebuild you're not touching.  As
such, it is a serious pain in the ass for architecture teams and
developers who are *not* slacking when one particular architecture only
has ebuilds that are ancient marked stable.  It increases the support
burden for *EVERYONE* else to keep this one architecture's stable tree
as it currently sits.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

2008-01-09 Thread Peter Volkov
В Срд, 09/01/2008 в 13:13 +0100, Fernando J. Pereda пишет:
 Why taking it against arch teams? How is that different from certain
 maintainer not taking care of a bug that holds stabilization of certain
 package by some time measured in months ? I'll tell you my answer: 'no
 difference at all'.

No. There is difference. If you see maintainer does not care, you can
ask him and fix bug by yourself. In case of arch teams bugs, you must
have access to hardware.

-- 
Peter.


signature.asc
Description: Эта	 часть	 сообщения	 подписана	 цифровой	 подписью


Re: [gentoo-dev] RFC: length of the DESCRIPTION variable

2008-01-09 Thread Mike Frysinger
On Saturday 05 January 2008, Petteri Räty wrote:
 Petteri Räty kirjoitti:
  Current devmanual suggest to not use line lengths over 80 characters.
  http://devmanual.gentoo.org/ebuild-writing/file-format/index.html
 
  I wrote a repoman check that checks that the value doesn't go over 80.
  This is useful for tools like eix that show the DESCRIPTION. The thing
  is that lots of ebuilds will fail this currently. Do you think we should
  use a higher limit like 100? qualudis seems to use 120 currently.

 Seems devmanual is currently putting the limit to 80 too.

 http://devmanual.gentoo.org/ebuild-writing/variables/index.html

 DESCRIPTIONA short (less than 80 characters) description of the
 package's purpose.

it's always been highly recommended that the DESCRIPTION be a short string, 
but there has never been a hard limit.  if you want to have repoman warn upon 
large strings (over 100 chars), that's fine, but there should be no hard 
limit anywhere.
-mike


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


Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Ferris McCormick

On Wed, 2008-01-09 at 11:51 -0800, Chris Gianelloni wrote:
 On Wed, 2008-01-09 at 14:00 +, Ferris McCormick wrote:
  they get to devrel because you ensured there would be no one to catch
  them --- you are the one who wanted to kill off the proctors, after
  all.
 
 ...and the finger-pointing starts... Bravo!
 
 I never have been able to figure out what the hell I did to you to make
 you feel like you need to personally attack me every step of the way,
 but I'm not putting up with it, anymore.
 
 I'm adding Developer Relations to this email and will be filing a formal
 complaint against you.  Have a good day.
 

To the extent you see this as a personal attack, I apologize.  I never
intended it as such.  I was only recalling your email from 5 June which
reads:

On Tue, 2007-06-05 at 21:52 +0100, Ciaran McCreesh wrote:
 On Tue, 05 Jun 2007 21:44:23 +0100
 Roy Bamford [EMAIL PROTECTED] wrote:
  For that reason alone, it should normally be avoided in international 
  forums such as are provided by Gentoo. 
 
 Why yes! Gentoo needs to be one hundred percent serious and entirely
 not fun. Anyone saying anything remotely amusing needs to be shut down
 by the proctors immediately. Please keep up the good work.

I really have to agree with you.  The proctors have completely lost
their way.  They are ineffective.  They tend to compound the problems
they were created to stop.  They are slow.  They have not prevented
anything, which was the reason for their creation.  Rather, what they
*have* done is stifle conversation, piss off people, get in the way of
Developer Relations reports, and otherwise making developers feel like
they don't want to participate in our official discussion channels.

What do I think needs to be done?

The proctors project needs to go away.  It simply wasn't implemented in
the way the Council had hoped and has proven to be more harmful than the
original problems to morale and inter-developer trust.  While the
individual members might be doing what they think is best and trying
their best, they've failed at the goals of improving our communications
channels.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation
=
From this I inferred you were the one who wanted to kill off the proctors.  I
am not attacking you:  I am saying there is no way to catch CoC violations
because the mechanism for that was the proctors, we don't have any proctors,
and it seems to me (The proctors project needs to go away) that you were
instrumental in that.  If any of this is incorrect, I'll retract it, but I am
trying to be factually correct and what I have is the above email.

As for filing a devrel complaint, do so if you must.  But as you know, policy
strongly suggests you should talk to me first so we can figure out where the
miscommunication is.  We also might discuss why you chose to hang an attack on
devrel onto my rather innocuous musings.

Sorry for any confusion,
Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (Devrel, Sparc, Userrel)


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 18:56 +0100, Jan Kundrát wrote:
 Chris Gianelloni wrote:
  I have foo 1.0, which is mips.  There is foo 2.0, which is stable
  everywhere else.  The foo 1.0 ebuild does not conform to current ebuild
  standards.  I want to commit changes to foo 2.0, and repoman won't allow
  me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo
  1.0, because it's been EOL for 2 years
 
 Why don't fix repoman not to scream about such issues, then?

What, have repoman complain only about problems in ebuilds that have
been changed unless someone does repoman full ?

Honestly, that coupled with dropping all KEYWORDS except for the arch in
question (in other words, marking something KEYWORDS=mips and then
ignoring it, as a maintainer) would be enough to keep package
maintainers and other architecture teams from having to deal with the
crap left all over the tree due to slacker arches.  Of course, tree
quality would probably go down even more, since these QA issues would
likely never be fixed on said architectures, but who really cares,
anyway.  The support burden gets lain on the people who are slacking,
and not on the package maintainers or other architecture teams.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 18:11 +, Ciaran McCreesh wrote:
 On Wed, 9 Jan 2008 10:07:31 -0800
 Alec Warner [EMAIL PROTECTED] wrote:
  Actually if they dump kde-3.5.5 and anything depending on it, then
  they don't break the tree and everyone is happy, no?
 
 Everyone except the users, who end up with pages and pages of horrible
 Portage output...

What, all six of them?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 18:45 +, Ciaran McCreesh wrote:
 On Wed, 9 Jan 2008 19:29:53 +0100
 Wulf C. Krueger [EMAIL PROTECTED] wrote:
  On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote:
So what happens if a flaw is discovered in KDE 3.5.5 that allows
root access?
   Then the one particular part of 3.5.5 that's affected gets fixed and
   priority keyworded.
  
  So you suggest that mips keeps doing nothing and expect others to
  work *more* in exchange for that?
 
 Well, most users will simply ignore or postpone the mass upgrade, so
 yes. Forcing a mass upgrade is rarely if ever the correct solution to
 any security issue.

This is why I find it funny that people even bother to listen to Ciaran,
at all.  All he cares about is his little pet projects/teams and doesn't
care if it increases workload for everybody else.  I mean, where would
Gentoo be if not for our support of mips?  Oh dear, we'd definitely be
nowhere near as popular... *cough*

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 20:50 +0200, Petteri Räty wrote:
 Ciaran McCreesh kirjoitti:
  On Tue, 08 Jan 2008 18:59:29 -0800
  Chris Gianelloni [EMAIL PROTECTED] wrote:
  The issue that was raised is that certain arch teams are incapable of
  keeping up with the minimal workload they already have and what should
  be done about it.
  
  The issue was raised, with absolutely no proof or justification, and
  every previous time said issue has been raised it's turned out to be
  somewhere between highly misleading and utter bollocks.
  
 
 So you just ignore for example my post about CIA activity for the mips team?

Of course, it is common practice to ignore any factual data that
supports the opposing side of a discussion.  This is Gentoo, man!
Where've you been?  :P

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Chris Gianelloni
On Mon, 2008-01-07 at 22:31 +0100, Luca Barbato wrote:
 Here is a list of interesting questions: Are we fine? What are we
 going to do?
 
 Please project leaders try to reply in short.
 
 About the stuff I'm involved:
 
 Are we fine?

GWN: The GWN is currently in a permanent state of hiatus.  I have no
intentions on spending another minute working on the GWN.  While many,
many improvements have been made in the processes for getting the
automated data, getting articles has been pulling teeth, at best.  This
was taking me upwards of 12 hours a week, which was impacting the time I
had available to work on things like releases and my day job.  As such,
the GWN is abandoned and will likely stay that way until someone steps
up and decides they're ready and willing to give up their lives to work
on this publication.  Yes, I think switching to a monthly newsletter
would *help* the problem, but it still won't resolve it.  The GWN needs
articles more than anything, and few people are submitting anything.

Release Engineering: We dropped the 2007.1 release due to many issues
which I won't go into here, since it really isn't appropriate at this
time.  As such, we're deciding on what our plan is for 2008 and beyond.
We are working on finalizing the latest versions of genkernel/catalyst.

PR: Well, I'm not the lead here, but since the lead is AWOL, I guess
that I can give my input.  This project is essentially dead.  There are
a couple people who occasionally respond to user queries to the alias,
but otherwise, nothing is going on here.  Nobody is really active.  I
sent in some news about 2007.1 a few weeks back and nobody's posted
anything or even responded.  I'd say the project is dead if we can't
even get out pertinent information like the cancellation of a release to
our users.

Trustees: Well, the Foundation no longer exists, legally, so it's pretty
obvious that things are not fine here.

 What are we going to do:

GWN: no clue, looks like nothing

RelEng: work on catalyst/genkernel, no further plans

PR: no clue, looks like nothing

Trustees: I retired as a Trustee since there's not much point without a
Foundation to run, leaving us with one (or possibly two) trustees.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Petteri Räty

Luca Barbato kirjoitti:

Petteri Räty wrote:

- Get the remaining Generation 1 stuff out of the tree (not much left)
- Start using virtuals more
- Eclass cleanup and new make our setup even more automatic


any plan/idea about icedtea? as a ppc user I'd love too see it in
portage ^^;

lu



Well having it open source doesn't mean automatically ppc support but 
there are people working on it.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] me and mail

2008-01-09 Thread Deedra Waters
My mail server died over the holidays and i ended up losing a lot of
mail, so if you've tried to contact me in the past 2 weeks or so, you'll
have to send again.

Deedra



-- 
Deedra Waters - Gentoo accessibility and amd64 -
[EMAIL PROTECTED]
Gentoo linux: http://www.gentoo.org

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



Re: [gentoo-dev] [RFC] Reducing the size of the system package set

2008-01-09 Thread Mike Frysinger
On Monday 07 January 2008, Diego 'Flameeyes' Pettenò wrote:
 I already ranted about the fact that the dependency tree of our ebuilds
 is vastly incomplete, as many lack dependency on zlib; trying to get
 this fixed was impossible, as Donnie and other insisted that as zlib was
 in system, we shouldn’t depend on it at all. I disagree, and I would
 like to know why we can’t depend on a system package, but whatever.

the system dep rule isnt hard as in if it's system, you cannot depend on it.  
that's silly.  it applies to packages which, if they do not exist, the system 
would not be usable.  things like grep/sed/tail/ps/etc... do not belong in 
the depend strings.  you cannot have a usable system without such utilities 
on your system.  that means packages like grep/sed/coreutils/procps/etc... do 
not belong in depend strings.  there is also the issue that these packages 
tend to be swappable based on the system (embedded/bsd/whatever), so listing 
them only causes problems.

 Anyway, as having a complete dependency tree is almost impossible
 because of that, I have an alternative proposal: reducing the size of
 the system package set.  Right now system contains stuff like ncurses,
 readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so
 on. Those are packages that certainly would be part of any base Gentoo
 system, but are those actual part of the system set of packages? I
 sincerely doubt it.

for ncurses/readline, they certainly are part of the system set.  that doesnt 
mean they should not show up in depend strings, it just means they are system 
packages that every Gentoo system should have installed.

i have no problem with shunting the rest.  the only thing you need to keep in 
mind is that if we do move all of these things to build-only depend (which 
they are logically), then people who like to depclean their system would 
constantly be removing/adding them.

 The reason of the existence of the system package set is related first
 and foremost to breaking circular dependencies: for instance if any
 package that used the C compiler would depend on gcc, then the packages
 that gcc depends upon would create a circular dependency between gcc and
 itself. Also, specifying libc in almost any ebuild would be quite
 pointless, as well as coreutils (or freebsd-bin/ubin) for cp, mv,
 install, …

not really.  the system package set is what went into releases and we wanted 
all of these things in our stage tarballs.  it is nigh impossible to emerge 
anything on a Gentoo system without any of these packages, so forcing them 
all by default didnt cause any problems.

 For what concern the three main libraries, there aren’t that many
 packages using zlib directly nowadays, this is especially easy to spot
 on a system built with --as-needed, as without that you actually do see
 zlib used in every other binary, for indirect dependencies. Nor there
 aren’t tons and tons of packages using readline, or ncurses. Actually in
 my own vserver’s chroot I only found four packages using readline, none
 of them part of system: ruby with the readline extension (uhm I wonder
 if I should ask for this to become an USE flag, I certainly don’t need
 it and I’d rather get rid of it), psql from postgresql (which maybe it’s
 still good to have with readline compiled in, but I could easily get rid
 of), bc (which is just an e2fsprogs build-dep, and I could build without
 readline just fine), and mysql.

bash uses readline as well ... but currently statically links it in ... i 
could (should?) change that ...

 A little bit different the status of ncurses, which is used by screen,
 gettext (only a build-dep, not needed for runtime on Linux anyway),
 procps, psmisc and util-linux (and I wonder why we don’t have a switch
 to turn it off), texinfo (wonder why we can’t remove it entirely
 actually) and yet again ruby. Still, I wonder why ncurses is in system
 rather than being properly on the dependencies list of those packages.

not sure how you missed the fact that *bash* needs it.  that seems pretty 
critical.

 As for perl, that’s probably a bit more justified, there are tons of
 packages using perl directly or indirectly, especially in build
 systems. But I would like those to depend on perl properly rather than
 having perl in system, as there are cases where perl is not really
 needed at runtime at least.

i'd say quite the opposite ... requiring perl in system blows.  it's there for 
two reasons: autotools and openssl.  but both are build time requirements 
only.

 And the only users of gnuconfig are the packages making use of the old
 and deprecated gnuconfig.eclass, or portage’s econf. Why can’t it be a
 dependency of portage then?

you've missed all of the autotool reliance on gnuconfig.  they symlink their 
config files to gnuconfig.  the fact that it is tied into econf is irrelevant 
i think ... any autotool based package has a dep on gnuconfig as bundled 
config files should always update to this.  how it gets 

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 18:56 +, Ciaran McCreesh wrote:
 On Wed, 09 Jan 2008 20:50:38 +0200
 Petteri Räty [EMAIL PROTECTED] wrote:
  So you just ignore for example my post about CIA activity for the
  mips team?
 
 That falls into the highly misleading category.

Yes, hard numbers are always misleading, especially when they show that
the entire team is barely active, at all, and only one of those people
is doing *any* mips work.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 20:45 +0100, Vlastimil Babka wrote:
 Ciaran McCreesh wrote:
  a) Drop all keywords but those of mips. Leaves mips and, more  
  importantly, its users with a vulnerable and unmaintained set of  
  packages.
  
  ...and break the tree spectacularly, causing huge amounts of pain for
  your fellow developers when they encounter horrible repoman output when
  they try to do anything.
 
 Can somebody clarify to me why would it cause this? Maybe I just miss 
 something.

He's making the assumption that this sort of thing would be done
improperly and would cause other developers issues.

I went and created a tiny script[1] to change mips KEYWORDS to ~mips in
the tree, and created a patch[2] against the current CVS tree.  Were the
Council to choose this course of action, the work is mostly done.

[1] http://dev.gentoo.org/~wolf31o2/killmips.sh
[2] http://dev.gentoo.org/~wolf31o2/mips_to_testing.patch

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


RE: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Chrissy Fullam
   Ferris McCormick wrote:
   they get to devrel because you ensured there would be no one to 
   catch them --- you are the one who wanted to kill off the 
   proctors, after all.
  
  Chris Gianelloni wrote:
  ...and the finger-pointing starts... Bravo!
 
 Ferris McCormick wrote:
 To the extent you see this as a personal attack, I apologize.
 I never intended it as such.  I was only recalling your email
 from 5 June

Fmccor, your comment about wolf 'being the one who wanted to kill off the
proctors' really served no purpose to the point; that being that the
proctors are no more and your personal curiosity as to how the CoC should
now be enforced. Adding no benefit to the point makes your comments useless
information. Your wording ('you ensured' and 'you are the one') only
furthers to make it useless information and appear very personal. 'You'
versus 'council' for example. You may honestly not intend it as such but
please be aware that it is easily interpreted that way when a simple change
of wording might have avoided this.

Wolf31o2 is not the council member who called to vote to disband the
proctors, and he is only one of five council members who voted to disband
the proctors. I myself had private conversations with council members OTHER
than wolf31o2 who had expressed the desire to drop the proctor project. The
combination of those things justifies me simply stating that your statement
is incorrect. Sure he sent that lovely email that you provided us all;
doesn't mean much though as he's not the only one who said those things. He
took a stance, as a council member should do, I mean isnt that why we have
council? And he is one person who can contribute but not solely rule, isnt
that why we have several council members instead of just one person? Quit
giving him 'credit' for the entire thing.

 Ferris McCormick wrote:
 As for filing a devrel complaint, do so if you must.  But as 
 you know, policy strongly suggests you should talk to me 
 first so we can figure out where the miscommunication is.  We 
 also might discuss why you chose to hang an attack on devrel 
 onto my rather innocuous musings.

You have a negative history with wolf31o2, and the details of which quite
frankly should be kept off this mailing list. His negative experiences
throughout all of 2007 with Conflict Resolution and consequently Developer
Relations justify any of your alleged 'attacks on devrel.' Let's take this
discussion elsewhere.
And a final note, you have had to justify your 'innocuous musings' a few
times recently, on this list and other Gentoo lists. Perhaps that could be a
sign that you should mull over and validate those musings yourself before
throwing them at the rest of us. Might cause fewer 'misunderstandings' with
regards to your statements.

Kind regards,
Christina Fullam
Gentoo Developer Relations Lead | Gentoo Public Relations 


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



Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

2008-01-09 Thread Caleb Tennis
 Correct, you did not.  What I find absolutely *damning* is the fact that
 as soon as any arches *were* mentioned, everybody was talking about the
 same one.  It's rather funny that everybody seems to have the exact same
 impression of what architecture might be a slacker and would be affected
 by this.  I wonder why that is?

Righto.  I also have specific mips related issues, and while I'm certain all of 
the
mips conversation will play on lots of people's minds, I think it also is 
helpful
from the council point of view to address this generically as it may be a 
problem
for a different arch in the future.

In other words, if people want to use mips as an example, then so be it, but
whatever resolution eventually comes to play shouldn't be mips specific.



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



Re: [gentoo-dev] [RFC] Reducing the size of the system package set

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 15:51 -0500, Mike Frysinger wrote:
  Anyway, as having a complete dependency tree is almost impossible
  because of that, I have an alternative proposal: reducing the size of
  the system package set.  Right now system contains stuff like ncurses,
  readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so
  on. Those are packages that certainly would be part of any base Gentoo
  system, but are those actual part of the system set of packages? I
  sincerely doubt it.
 
 for ncurses/readline, they certainly are part of the system set.  that doesnt 
 mean they should not show up in depend strings, it just means they are system 
 packages that every Gentoo system should have installed.

Well, one solution for some of this would be to move said things to a
higher level profile.  Rather than have them all in base/packages,
move some to default-linux/packages (or even further down, if
appropriate).  When the stages get built against these profiles, we
would end up with the complete system set, but other profiles
inheriting from the lower profiles like base won't have to negate
things.

 i have no problem with shunting the rest.  the only thing you need to keep in 
 mind is that if we do move all of these things to build-only depend (which 
 they are logically), then people who like to depclean their system would 
 constantly be removing/adding them.

Well, unless they were added to another profile.  I think the main
reason for Diego's request is for non-Linux non-default profiles that
inherit from base.

 not really.  the system package set is what went into releases and we wanted 
 all of these things in our stage tarballs.  it is nigh impossible to emerge 
 anything on a Gentoo system without any of these packages, so forcing them 
 all by default didnt cause any problems.

Exactly.  I just think that we can still accomplish what Diego is asking
by shifting where things get added to system in the profiles.  The
end-result would be the same (for default Linux installs) but everybody
else would have a cleaner common base from which to start.

 i'd say quite the opposite ... requiring perl in system blows.  it's there 
 for 
 two reasons: autotools and openssl.  but both are build time requirements 
 only.

Indeed.  We ended up having to get perl into the stage1 because of
exactly these problems.  It sucks.  I'd love to be able to remove perl
(and anything else not necessarily required) out of the base system set.
If they're required in other profiles, they should be added in said
profiles.

  So there are more things that were brought to my attention, like ssh,
  flex, bison, e2fsprogs, and so on. We should probably look into what to
  keep, rather than what to remove.
 
 flex/bison are in the exact same boat as autotools.  dont know why you 
 separated them out.  openssh and e2fsprogs are part of the system set because 
 every Gentoo system out there should have them installed.  if you dont like 
 it, feel free to tweak your files locally, but to attempt to account for a 
 few people at the detriment of 99.9% of the people out there makes no sense 
 at all.

Well, openssh has always been questionable.  Sure, *I* think it should
be on any Gentoo system I'd want to touch, but it really isn't necessary
for a lot of people.  Moving this to, say, the server profiles only
would be acceptable to me, but then again, so is leaving it how it is
now.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Luca Barbato
Petteri Räty wrote:
 Well having it open source doesn't mean automatically ppc support but
 there are people working on it.

I'm quite aware about it I followed the improvement on this side since a
while even if I hadn't the time to try myself building it on ppc yet.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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



Re: [gentoo-dev] OpenRC available for testing.

2008-01-09 Thread Mike Frysinger
On Thursday 03 January 2008, Roy Marples wrote:
 On Thu, 2008-01-03 at 10:49 -0500, Mike Frysinger wrote:
  while is_older_than is negotiable, removing KV_* is not.  those are
  pretty tight utility functions which duplication in $random-packages will
  only lead to problems (especially considering the history of making sure
  they were coded right).  they've weathered quite a long time and should
  be pretty much unchanged, so there is no good reason to omit them.  there
  is no overhead of having them available and maintaining them.

 KV_* only makes sense when dealing with Linux version numbers are
 they're always numeric. The BSD's on the other hand include textual
 elemants too.
 uname -r on this machine is 7.0-RC1.

that's incorrect ... linux uname's often have textual content as well 
(-mm, -git, -rc, -fooie).  the KV_* functions only parse out the relevant 
values and in the case of the linux kernel, that is:
major.minor.micro[.stable]

 luckily, baselayout-2 as it stands in portage only exports the KV_to_int
 function so that's the only one we should be dealing with.

i'm not so sure ... the other functions are trivial to implement and 
considering KV_to_int is implemented based on those ... no reason to cull the 
functions when they are certainly useful.

 So, the question is, do we want to maintain one massive KV_to_int that
 has different code paths for uname -s output, or get function.sh to
 include an OS specific file we supply just for this one function?

how you want to architect it in the backend is up to you, but the latter 
probably makes more sense.  my concern is for the frontend (API) and that 
is that the functions need to be exported.

 Or just put the function in modules-update and udev as they are the only
 two applications that use it.

no, that is most certainly not where we want to go

  if you want a cleaner interface for is_older_than, then we could hammer
  that out, but if it's just a pass through to a C applet, then leaving it
  alone makes sense.

 Currently it's neither as it's been integrated into the librc dependency
 code. Again, the only consumer of this function is now modules-update.

that may simply be because the only people who have been tracking the code 
closely are you and me ... considering the nature of the function, it sounds 
like a good function other things can leverage as it provides make-style 
timestamp tracking for conditionally updating of files.

I also notice that the timezone of clock is gone, any alternative?
Also the network dependency of stopping/starting services when
network is unavailable/available is gone, any alternative?
  
   The timezone was variable was just a hack for the timezone ebuild to
   update /etc/localtime if it's not a symlink. I'm striving to remove all
   Gentooisms from it so that it really is platform neutral.
 
  you view the purpose of TIMEZONE incorrectly.  it was a central script
  parasable location to store the system timezone.  every distribution out
  there does it somehow.  the way for OpenRC to do it is set the variable
  in /etc/conf.d/clock.  the fact that currently the timezone ebuild is the
  only one using it is irrelevant.

 Then I suggest that conf.d/clock is the wrong place for it as if it was
 set there then it implies that `/etc/init.d/clock start` would change to
 that timezone, which is clearly not the case.

that's fair.  i'd also add that forcing the value into conf.d/clock forces a 
reliance on openrc and prevents alternative init packages (which we've seen 
people use).  i know debian uses /etc/localtime, any one know what other 
distro conventions are in use out there ?
-mike


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


Re: [gentoo-dev] OpenRC available for testing.

2008-01-09 Thread Mike Frysinger
On Thursday 03 January 2008, Roy Marples wrote:
 On Thu, 2008-01-03 at 16:24 +, Roy Marples wrote:
  On Thu, 2008-01-03 at 10:50 -0500, Mike Frysinger wrote:
   it also means a deprecation notice needs to be added here and
   everywhere else that has changed.  perhaps create a small script that
   takes
   the /etc/modules.autoload.d/ directory and converts it into the
   corresponding /etc/conf.d/modules file.
 
  I'll go with a conversion script in the ebuild I think.

 I've gone with a warning message instead as a converstion script will
 take a little while. It should suffice for the time being.

we'll need a full review before going ~arch obviously ... i imagine 
modules/clock arent the only difference
-mike


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


[gentoo-dev] sqlite/sqlite3 useflag inconsistency

2008-01-09 Thread Benedikt Morbach
Hi out there,

as I was told on bugzilla, I am taking this here.

I do not know if this was proposed earlier, but I noticed, that
USE=sqlite seems to just pull in any dev-db/sqlite, which in many
cases does not really mean any, like
DEPEND=sqlite? dev-db/sqlite
would do, but something like
DEPEND=sqlite? ( =dev-db/sqlite-3 ) ## from app-portage/eix/eix-0.10.3.ebuild

While sqlite3 pulls in dev-db/sqlite-3* (At least it should, I have
not really checked that one)

In my humble opinion it would be nice to have a greater degree of
control by separating this into two useflags, sqlite2 and sqlite3,
just like e.g. qt3 and qt4

Regards,
Benedikt
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Fabian Groffen
On 09-01-2008 13:03:13 -0800, Chrissy Fullam wrote:
 You have a negative history with wolf31o2, and the details of which quite
 frankly should be kept off this mailing list. His negative experiences
 throughout all of 2007 with Conflict Resolution and consequently Developer
 Relations justify any of your alleged 'attacks on devrel.' Let's take this
 discussion elsewhere.

 Kind regards,
 Christina Fullam
 Gentoo Developer Relations Lead | Gentoo Public Relations 

IMHO, you have a very big conflict of interest in this issue.  Why do
you (for the second time) handle a case like this one, and not someone
else from devrel?

I have a hard time to take your message as an objective and unbiased
one.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] [RFC] Reducing the size of the system package set

2008-01-09 Thread Mike Frysinger
On Wednesday 09 January 2008, Chris Gianelloni wrote:
 On Wed, 2008-01-09 at 15:51 -0500, Mike Frysinger wrote:
   Anyway, as having a complete dependency tree is almost impossible
   because of that, I have an alternative proposal: reducing the size of
   the system package set.  Right now system contains stuff like ncurses,
   readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so
   on. Those are packages that certainly would be part of any base Gentoo
   system, but are those actual part of the system set of packages? I
   sincerely doubt it.
 
  for ncurses/readline, they certainly are part of the system set.  that
  doesnt mean they should not show up in depend strings, it just means they
  are system packages that every Gentoo system should have installed.

 Well, one solution for some of this would be to move said things to a
 higher level profile.  Rather than have them all in base/packages,
 move some to default-linux/packages (or even further down, if
 appropriate).  When the stages get built against these profiles, we
 would end up with the complete system set, but other profiles
 inheriting from the lower profiles like base won't have to negate
 things.

i dont think Diego's goal is completely BSD driven ... so moving them from 
say base to default-linux doesnt quite help.  they're stuck in this gray 
middle ground.

  i have no problem with shunting the rest.  the only thing you need to
  keep in mind is that if we do move all of these things to build-only
  depend (which they are logically), then people who like to depclean their
  system would constantly be removing/adding them.

 Well, unless they were added to another profile.  I think the main
 reason for Diego's request is for non-Linux non-default profiles that
 inherit from base.

for these build-only deps, it isnt a Linux problem.  it's a any system that 
compiles thing from source problem.  so non-Linux systems would be just as 
affected.

  not really.  the system package set is what went into releases and we
  wanted all of these things in our stage tarballs.  it is nigh impossible
  to emerge anything on a Gentoo system without any of these packages, so
  forcing them all by default didnt cause any problems.

 Exactly.  I just think that we can still accomplish what Diego is asking
 by shifting where things get added to system in the profiles.  The
 end-result would be the same (for default Linux installs) but everybody
 else would have a cleaner common base from which to start.

sure, i'm not arguing for the status quo.  but i'm not also not arguing for 
stripping them all (which would make Diego happy i imagine).  i wonder if the 
profiles frags we talked about a while ago is the only real solution and 
shuffling packages around in the meantime is only a temporary (and fragile) 
workaround.

  i'd say quite the opposite ... requiring perl in system blows.  it's
  there for two reasons: autotools and openssl.  but both are build time
  requirements only.

 Indeed.  We ended up having to get perl into the stage1 because of
 exactly these problems.  It sucks.  I'd love to be able to remove perl
 (and anything else not necessarily required) out of the base system set.
 If they're required in other profiles, they should be added in said
 profiles.

i often debate simply chucking the perl build requirements of openssl in favor 
of autoconf ... maybe i'll set up a git tree on Gentoo's git for this ... i 
think that'd solve the perl required in stages issue ?

   So there are more things that were brought to my attention, like ssh,
   flex, bison, e2fsprogs, and so on. We should probably look into what to
   keep, rather than what to remove.
 
  flex/bison are in the exact same boat as autotools.  dont know why you
  separated them out.  openssh and e2fsprogs are part of the system set
  because every Gentoo system out there should have them installed.  if you
  dont like it, feel free to tweak your files locally, but to attempt to
  account for a few people at the detriment of 99.9% of the people out
  there makes no sense at all.

 Well, openssh has always been questionable.  Sure, *I* think it should
 be on any Gentoo system I'd want to touch, but it really isn't necessary
 for a lot of people.  Moving this to, say, the server profiles only
 would be acceptable to me, but then again, so is leaving it how it is
 now.

i'd argue pretty vehemently against removing openssh from any default official 
Gentoo install.  ssh is defacto standard for loginning into any other 
machines.  it should be on all Gentoo desktops/severs/etc...  
specialized/embedded/whatever are certainly free to cull openssh (and doing 
so is actually beyond trivial).  whether we express this requirement in base/ 
or frags or something is certainly open for discussion, but i believe 
removing it from a stage3 in any of our standard releases is a huge 
disservice to everyone.
-mike


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


Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Luca Barbato
Chris Gianelloni wrote:

 What are we going to do:
 
 GWN: no clue, looks like nothing

Well I hope there is somebody willing to at least try to get a minimal
gwn as new year kickoff out even just by summarizing this thread ^^;

 RelEng: work on catalyst/genkernel, no further plans

I'm looking forward to see the improved tools and hopefully get the in
system deps fixed as vapier just suggested/pointed.

 PR: no clue, looks like nothing

Maybe would be good check who is alive.

 Trustees: I retired as a Trustee since there's not much point without a
 Foundation to run, leaving us with one (or possibly two) trustees.

I guess this part requires discussion elsewhere since there isn't much
technical.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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



RE: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Chrissy Fullam
 Fabian Groffen wrote:
 On 09-01-2008 13:03:13 -0800, Chrissy Fullam wrote:
  You have a negative history with wolf31o2, and the details of which 
  quite frankly should be kept off this mailing list. ...
  Let's take this discussion elsewhere.
 
 IMHO, you have a very big conflict of interest in this issue. 
  Why do you (for the second time) handle a case like this 
 one, and not someone else from devrel?
 
 I have a hard time to take your message as an objective and 
 unbiased one.

I apologize if my email was not clear enough for you. I never said that I
would, nor have any intention to, handle this case personally. I do however
feel that a dispute/disagreement between two developers should not be taken
to the mailing lists. Please let me be clear, I did not say I would
personally handle this nor do I have any intention of personally handling
this. My intent is to assign someone to attempt mediation. If mediation
efforts fail, it will be escalated as per policy.

I appreciate your opinion and your right to have such an opinion, however, I
have a hard time understanding your reason for said opinion. I would expect
any person to be able to say 'enough' and 'lets take this elsewhere.' If you
feel that a person in DevRel can have no relationship with any other
developer, friendship or otherwise, then you are sadly mistaken. And having
any sort of relationship with any other developer does not then cloud your
ability to think; if it does then that person has a host of problems to
contend with, Gentoo being the least of them.

Kind regards,
Christina Fullam
Gentoo Developer Relations Lead | Gentoo Public Relations 

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



Re: [gentoo-dev] [RFC] Reducing the size of the system package set

2008-01-09 Thread Josh Saddler
Mike Frysinger wrote:
 Well, openssh has always been questionable.  Sure, *I* think it should
 be on any Gentoo system I'd want to touch, but it really isn't necessary
 for a lot of people.  Moving this to, say, the server profiles only
 would be acceptable to me, but then again, so is leaving it how it is
 now.
 
 i'd argue pretty vehemently against removing openssh from any default 
 official 
 Gentoo install.  ssh is defacto standard for loginning into any other 
 machines.  it should be on all Gentoo desktops/severs/etc...  
 specialized/embedded/whatever are certainly free to cull openssh (and doing 
 so is actually beyond trivial).  whether we express this requirement in base/ 
 or frags or something is certainly open for discussion, but i believe 
 removing it from a stage3 in any of our standard releases is a huge 
 disservice to everyone.

We all know that ssh is good for sysadmins and netadmins and Gentoo
developers, etc. However, desktop users -- i.e., those not in those
categories, which is most everyone else, likely do not find it as
useful. I'd say that most of our userbase doesn't need to remotely
connect to other machines. Our development/admin experiences are *not*
typical of our installed userbase, judging by our huge forums. Their
machines aren't used for such purposes. openssh may be a de facto
standard for the kind of application it is, but that doesn't mean we
need to force it on end-users. Our philosophy has been more of opt-in,
rather than opt-out, and quite simply, ssh isn't a critical system
package; a base installed system won't be broken if it's  not there. If
you *need* it to do work (admins, I'm looking at you), then you can
*emerge* it. Just like vim, cvs, dev_tool_foo etc.

I *am* a desktop user. And . . . aside from Gentoo development, I have
no need for ssh. It could easily be removed from the system profile --
the only place it might be kept is in the liveCD environment, for remote
installations. Other than that, we don't need to ship it in our stages;
just on the media.


(Whoa, sudden feeling of deja vu. I'm 80% positive this was previously
brought up on the MLs within the last two to three years...and I stated
the same view then!)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 22:42 +0100, Fabian Groffen wrote:
 On 09-01-2008 13:03:13 -0800, Chrissy Fullam wrote:
  You have a negative history with wolf31o2, and the details of which quite
  frankly should be kept off this mailing list. His negative experiences
  throughout all of 2007 with Conflict Resolution and consequently Developer
  Relations justify any of your alleged 'attacks on devrel.' Let's take this
  discussion elsewhere.
 
  Kind regards,
  Christina Fullam
  Gentoo Developer Relations Lead | Gentoo Public Relations 
 
 IMHO, you have a very big conflict of interest in this issue.  Why do

Umm... and?

Where in policy does it say that someone *must* remove themselves from a
*conversation* where there *might* be a conflict of interest or bias?
See, I had assumed that we all were supposed to respect each other's
ability to look at the *facts* and *evidence* and make decisions based
on said facts and evidence.  I mean, if we all stopped participating in
conversations where we had our own personal bias, there'd be no need for
this list, our IRC channels, or any shared communications medium.  See,
it is *expected* that people are going to be biased.  Everyone will have
their own bias.  It is how people *act* that makes the difference.  Of
course, I guess that only applies when it has nothing to do with me,
huh?

 you (for the second time) handle a case like this one, and not someone
 else from devrel?

Like who, exactly?  Can you even tell who is active in Developer
Relations?  The Conflict Resolution team is *exactly* Christel, who is
pretty much AWOL (not that I blame her... :P) and Ferris.

 I have a hard time to take your message as an objective and unbiased
 one.

So?  You mean the fact that I've had numerous verifiable issues with
Developer Relations is somehow a matter of opinion that is being based
on bias?  I guess the emails that I sent to Developer Relations about
issues that I was having *long before Chrissy ever became a developer*
are all a part of her bias towards me and completely fabricated?  What
about the fact that several other members of Developer Relations have
been reviewing and agreeing with all of her determinations?

I find this whole thing humorous.  None of you know a damn thing about
Chrissy and my relationship, yet you make your assumptions.  Keep on
assuming.  I really couldn't care less.

It's this exact form of double standard and using things only when they
fit what you want that keeps things from actually getting done,
especially when they're untrue or based on faulty assumptions.  I guess
that's just business as usual around here, though.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Jan Kundrát
Chrissy Fullam wrote:
 I appreciate your opinion and your right to have such an opinion, however, I
 have a hard time understanding your reason for said opinion. I would expect
 any person to be able to say 'enough' and 'lets take this elsewhere.'

Perhaps he feels in such a way because your mail wasn't really please
talk about it elsewhere, but rather a warning (at least that's how I
perceived it) and you signed it as a Gentoo Developer Relations Lead.
I hope this helps you understand why someone might have such an opinion :).

Cheers,
-jkt

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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Reducing the size of the system package set

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 16:42 -0500, Mike Frysinger wrote:
  Indeed.  We ended up having to get perl into the stage1 because of
  exactly these problems.  It sucks.  I'd love to be able to remove perl
  (and anything else not necessarily required) out of the base system set.
  If they're required in other profiles, they should be added in said
  profiles.
 
 i often debate simply chucking the perl build requirements of openssl in 
 favor 
 of autoconf ... maybe i'll set up a git tree on Gentoo's git for this ... i 
 think that'd solve the perl required in stages issue ?

As far as I know, only openssl would really be affected.  If that were
fixed, we very likely could drop perl from system.  I'd have to check.
I *know* that we could drop it from stage1/stage2, though.

  Well, openssh has always been questionable.  Sure, *I* think it should
  be on any Gentoo system I'd want to touch, but it really isn't necessary
  for a lot of people.  Moving this to, say, the server profiles only
  would be acceptable to me, but then again, so is leaving it how it is
  now.
 
 i'd argue pretty vehemently against removing openssh from any default 
 official 
 Gentoo install.  ssh is defacto standard for loginning into any other 
 machines.  it should be on all Gentoo desktops/severs/etc...  
 specialized/embedded/whatever are certainly free to cull openssh (and doing 
 so is actually beyond trivial).  whether we express this requirement in base/ 
 or frags or something is certainly open for discussion, but i believe 
 removing it from a stage3 in any of our standard releases is a huge 
 disservice to everyone.

Well, I wasn't really saying that it wouldn't end up in the stages.
More that by moving it into the sub-profiles, it allows people to choose
a profile where it isn't in system anymore.  Of course, most of this
is rather moot considering you can override parts of the profile and
someone could quite easily just remove this one package, if they so
desired.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Stephen Bennett



I'm adding Developer Relations to this email and will be filing a formal
complaint against you.  Have a good day.
  

lol.
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] OpenRC available for testing.

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 16:26 -0500, Mike Frysinger wrote:
 that's fair.  i'd also add that forcing the value into conf.d/clock
 forces a reliance on openrc and prevents alternative init packages
 (which we've seen people use).  i know debian uses /etc/localtime, any
 one know what other distro conventions are in use out there ?

Well, RH/RHEL/Fedora/CentOS/Mandrake/Mandriva all use /etc/localtime

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer


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


Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting

2008-01-09 Thread Chris Gianelloni
On Wed, 2008-01-09 at 23:27 +0100, Jan Kundrát wrote:
 and you signed it as a Gentoo Developer Relations Lead.

Umm... because that's her .sig?

Wow.  I'm really surprised that this concept is foreign to people.  Are
you saying that you need beer from the pub because of your signature?
Are you speaking on behalf of pubs?  Beer?  Maybe mouths?

(Yes, you can quickly see just how asinine the assumption is...)

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] OpenRC available for testing.

2008-01-09 Thread Mike Frysinger
On Wednesday 09 January 2008, Chris Gianelloni wrote:
 On Wed, 2008-01-09 at 16:26 -0500, Mike Frysinger wrote:
  that's fair.  i'd also add that forcing the value into conf.d/clock
  forces a reliance on openrc and prevents alternative init packages
  (which we've seen people use).  i know debian uses /etc/localtime, any
  one know what other distro conventions are in use out there ?

 Well, RH/RHEL/Fedora/CentOS/Mandrake/Mandriva all use /etc/localtime

err, sorry, you're right of course.  every glibc guy uses /etc/localtime.  i 
meant /etc/timezone.
-mike


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


Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Pierre-Yves Rofes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Luca Barbato a écrit :
 Here is a list of interesting questions: Are we fine? What are we
 going to do?
 
 Please project leaders try to reply in short.
 

Ok, technically I'm not security lead, but since I and rbu almost
completely handled the security team since 2 months, I think I can at
least give my opinions on what's going on.

 About the stuff I'm involved:
 
 Are we fine?

security:
Well, with an average of ~ 1 GLSA/day for November and December, things
are going a little bit better than some months ago. We still have too
many open bugs (~115),but we tend to be a little more reactive since we
now actively monitor the vendor-security mailing list plus the freshly
attributed CVE ids, so we're able to file bugs and get them corrected
before they go public. This also means arches security liaisons should
be prepared to get called more often from now on.

 
 What are we going to do:
 

Personally, I'd like that we become more regular for the GLSA releases,
instead of doing nothing for days then rushing to send 10 GLSAs in 2 days.
I'd also like to take care of the really old bugs, say, opened for at
least 6 months (~25 at the moment).
Don't know if we'll manage to do it, but at least we'll try.


This was a (very) short reply, sec team members are of course
welcome to complete.

- --
Pierre-Yves Rofes
Gentoo Linux Security Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHhVS1uhJ+ozIKI5gRAqbnAJ9URJQ2fMFdjrpaER1dKF+ws4VDQQCdHZ98
2rCq9l3JGrxfSXZNttN40ok=
=5N0K
-END PGP SIGNATURE-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Paul Varner

On Mon, 2008-01-07 at 22:31 +0100, Luca Barbato wrote:
 Here is a list of interesting questions: Are we fine? What are we
 going to do?
 
 Please project leaders try to reply in short.

tools-portage:

Are we fine?  The short answer is no.  We need more developers.
Unfortunately, real life work is consuming all of my time and what free
time is left is going to my family.  mpagano has started to step up and
work bugs, but we definitely need more help. I am on email and IRC so I
can answer questions and work with any developer who would like to step
up and help (even temporarily).

Marius (genone) stepped down as team lead on December 3rd and asked for
help for the team at that time.  I have not seen any reponses to that
request.

What are we going to do?

Due to lack of time and participation, I currently don't have a good
answer for that.

On my short list is to get revdep-rebuild fixed.  The current state
leaves much to be desired and while it works for most people, it is
definitely a visible turn off for people when it fails.

Regards,
Paul
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] [RFC] Reducing the size of the system package set

2008-01-09 Thread Petteri Räty

Mike Frysinger kirjoitti:


i'd argue pretty vehemently against removing openssh from any default official 
Gentoo install.  ssh is defacto standard for loginning into any other 
machines.  it should be on all Gentoo desktops/severs/etc...  
specialized/embedded/whatever are certainly free to cull openssh (and doing 
so is actually beyond trivial).  whether we express this requirement in base/ 
or frags or something is certainly open for discussion, but i believe 
removing it from a stage3 in any of our standard releases is a huge 
disservice to everyone.

-mike


I wouldn't say ssh is any more important than a dhcp client.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Projects and subproject status

2008-01-09 Thread Ryan Hill

Luca Barbato wrote:

Here is a list of interesting questions: Are we fine? What are we
going to do?

Please project leaders try to reply in short.


[ wxWidgets ] (i'm not the lead but i don't think leio will mind)

Done:
  We got 2.8 into the tree (yay).  After a few bug reports that were 
mostly silliness on my part, things have mostly been smooth sailing. 
Hopefully it's working out for everyone.


To Do:
  I have a couple people interested in ports other than wxGTK (eg. 
wxMac).  I'd like to start by separating wxBase into its own package and 
get support for building against an external wxBase into upstream.  I 
haven't talked to upstream about this yet and they may violently 
disagree with this approach so all this is highly tentative.  I have no 
idea what form other ports in portage will take at the moment.
  Work on upcoming releases (2.10(?)/3.0) will begin when said releases 
are closer to.. er.. release.



[ gcc-porting ] (again not the lead but I don't think vapier will mind)

Done:
  The usual.
To Do:
  I've been working on getting the tree ready for GCC 4.3 but it's been 
slow going.  4.3 is a hell of a lot more disruptive than 4.2 was.  There 
is a preliminary porting document posted at 
http://people.redhat.com/~bkoz/porting_to_gcc43.html which outlines most 
of the major issues if people are interested.  Right now I almost have 
Gnome building while KDE is a bit further behind just due to the most 
commonly encountered 4.3 incompatibilities being in C++ code (KDE itself 
has been fine, most of the problems are in the dependencies).  Anyone 
wishing to follow this progress can checkout my overlay via layman and 
subscribe to Bug #198121.  (I also have svn GCC ebuilds in my overlay. 
They work on 64bit targets which i think the ones in the toolchain 
overlay have trouble with (?).)



[ fonts ] (hey, i do run this one!)

Done:
  Version bumping.  Random fixing.  Thanks to pva the eclass now 
handles conf files with spaces in their names. :)  Thanks to cardoe we 
have an awesome eselect module for tweaking said conf files. :)  I think 
all of our major bugs have been fixed.

To Do:
  We've gotten a couple more ppl so things should go a bit smoother. 
There are a crapload of font ebuild requests in bugzilla I'd like to 
sort through.  (I'm not adding every request to the tree;  fonts will be 
considered based on quality, coverage, license, etc.)  I'd like to bring 
our font selection up to the level of other mainstream distros, as well 
as review our defaults to try and provide a better out-of-the-box 
experience for =2008.x.  fontconfig-2.5 helps with this and I'm 
planning on stabilizing it soon.



--
fonts,by design, by neglect
gcc-porting,  for a fact or just for effect
wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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



Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

2008-01-09 Thread Kumba


Well, I guess it's something that's been needing to be faced for some time now, 
as difficult as it is to do.  Regardless of the accusations and 
counter-accusations flying around in this thread, I'll just go ahead and state 
the fact that yes, we are a slacker arch.


Why?  Because there's just no time anymore these days and no one left really of 
the original team.  And a lot of that really is my fault.  Tuxus may have laid 
the first keel of our ship, but I was the one who, so long ago, made her 
seaworthy and crewed her.  But now, she's largely a ghost ship -- adrift in the 
seas, and a hazard to the other ships.


And for that, I apologize to all of you.


My availability lately has been diminished as I've started wearing more hats 
at work, and I find myself with barely five hours a night of free time to 
meander about in whatever entertains me in my free time.  Occasionally, I pull 
up the window that connects to my Octane and keyword a bunch of things, and 
knock out some bugs.  But I'll be honest, that's been a rare thing these days.


So many of you by now are probably thinking Ah hell, he's jumping ship on us. 
 No, not yet.  I have to fix what I created before I even begin to ponder those 
thoughts.  To just up and leave with the mess I've allowed to occur would be 
unfair, and frankly, just not something that's in my character.


So how can this ship be righted?  I did a quick scan of most of the mails in the 
thread to get an idea of some of the existing opinions (while trying to pass 
over the arguments), and here's what I found that needed to be addressed.




1. It's been suggested that mips drop all stable keywords ('mips') leaving 
unstable keywords as-is ('~mips').


Contrary to whatever damage and/or impact this may create, I think this is a 
good idea for us.  I've always ran ~arch on my Octane, and with a few 
exceptions, have found ~arch to be pretty usable.  Does something sometimes 
break?  Sure, but when one looks at all the wacky crap that exists in our arch, 
sometimes you're left wondering how it all manages to work anyways.


Besides, we've always been a more experimental arch to begin with.  Usually 
we've been the first to try some new hair-brained idea (like automated netboot 
builds via catalyst or running the most bleeding edge glibc), so this would just 
be another item in our tumultuous history to take a swing at.


That said, however, I don't think it would be appropriate to commit a patch to 
portage that wipes out all our stable keywords in one go.  I think it would be 
more appropriate to phase such a change in gently, because as far as I know, no 
one else has really done this.  The other archs typically maintain a 
stable/unstable set of keywords in the tree.  So I think this should be managed 
by the profiles.  I've been needing to do some profile cleanup anyways, so I can 
probably fiddle with a 2008.0-dev profile set to only do ~arch, and then see how 
that goes.


Thus as 2007.0 and 2007.1-dev die off, so does our stable keywords.  This frees 
up other package maintainers to not have to worry about one of our pesky 
keywords holding things back, and should give us more freedom to move at our own 
pace, relative to those who have free time and those who don't.




2. Many have wandered if we as a team are still alive.

And the answer to that really is a resounding No.  Individually, me and 
Redhatter are probably the only ones who still do anything (and Redhatter, 
thanks for all the work you've done keeping things alive).  The rest had other 
priorities come up in their lives that ultimately required them to resign or 
fade into some un-indexed inode someplace.  And it's my fault for not replacing 
those lost team members with new folks.


I've got a guy in mentoring right now, but even that's been really slow as both 
of us have found time to be a scarce thing.  But I'd like to get some kind of a 
team back together, and hopefully get them on the right track to run things so 
that I can step off the platform as Lead and take more of a backseat role, 
which I feel is something better suited for me anyways.  It's not like I've lost 
faith in Gentoo or found I have zero time, it's just that I don't have enough 
time to operate effectively in the role of a Team Lead anymore.  Right now, I 
fit in better as That crazy old guy who lives in a cave, or something equivalent.


But I can't do that till I get things back in shape, and so, I'll need help from 
the rest of you guys.  I need people to step up who want a chance to play with 
an arch that's about as insane as a pikachu slamming PCP.  People who don't mind 
running machines that are heavy, sometimes noisy, usually slow, and weren't 
exactly designed with energy conservation in mind.  People who want to help 
bring us closer to the rest of Gentoo, rather than off in our own little world, 
as we are oft found to be.


I'll fill those interested in all the dirty information they need to hunt down a 
machine 

Re: [gentoo-dev] Projects and subproject status

2008-01-09 Thread Josh Saddler
Luca Barbato wrote:
 Here is a list of interesting questions: Are we fine? What are we
 going to do?

Documentation

(Note: I'm not the project lead, but neysx isn't on the list, nor does
he send status updates, so I hope he and the rest of the project won't mind.

 Are we fine?

Sure, why not. The pace of new bugs has slowed down, which is good, as
it allows for, uh, existing bugs to get fixed?

Over the last couple of months, some GDP devs besides me have been
making commits, which is a nice change of pace from how the year had
been previously. :) (I can take a vacation, whoo!)

Sure, we have a few bugs that are two or three (or even four) years old,
but who doesn't?

We could always use more translators though. We have several dead
languages, some of which used to be pretty big.

 What are we going to do:

The handbooks for the upcoming release are almost ready. Our release
plans have changed slightly; still coordinating with releng. We'll get
'em finished up and delivered . . . at some point. Promise.

On down the road, you can expect the usual maintenance of existing
world-class docs. I hope to get more patches submitted[1] against our
ldap guide[2] so that it can be made an official doc once again.

I'm sure we'll be seeing new documentation this year; there's always at
least a few new guides per year. You have any suggestions on new docs
you'd like to see, feel free to send 'em my way. Or open a bug if you
have actual content already written. ;)


[1] http://bugs.gentoo.org/show_bug.cgi?id=176075
[2] http://www.gentoo.org/doc/en/ldap-howto.xml



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Projects and subproject status

2008-01-09 Thread Gunnar Wrobel
Luca Barbato [EMAIL PROTECTED] writes:

 Here is a list of interesting questions: Are we fine? What are we
 going to do?

 Please project leaders try to reply in short.

 About the stuff I'm involved:

web-apps


 Are we fine?

webapps is more or less fine. We have several people in the herd
maintaining their favourite webapps and rl03 and me are handling the
rest of them. With rl03 really busy at the moment I'm lagging a little
bit behind but have been able so far to keep the bug list on a small
level.

I was not able to continue development on webapp-config for a while
though.

 What are we going to do:

Continue caring for webapps and hopefully closing more bugs than new
ones come in during the next months.

And then finally getting back to the next version of webapp-config.

Cheers,

Gunnar

-- 
Gunnar WrobelGentoo Developer
__C_o_n_t_a_c_t__

Mail: [EMAIL PROTECTED]
WWW:  http://www.gunnarwrobel.de
IRC:  #gentoo-web at freenode.org
_
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

2008-01-09 Thread Mike Frysinger
On Wednesday 09 January 2008, Kumba wrote:
 Well, I guess it's something that's been needing to be faced for some time
 now, as difficult as it is to do.  Regardless of the accusations and
 counter-accusations flying around in this thread, I'll just go ahead and
 state the fact that yes, we are a slacker arch.

 Why?  Because there's just no time anymore these days and no one left
 really of the original team.  And a lot of that really is my fault.  Tuxus
 may have laid the first keel of our ship, but I was the one who, so long
 ago, made her seaworthy and crewed her.  But now, she's largely a ghost
 ship -- adrift in the seas, and a hazard to the other ships.

thanks ... you've always been a straight shooter without any bs mixed in.

 1. It's been suggested that mips drop all stable keywords ('mips') leaving
 unstable keywords as-is ('~mips').

 That said, however, I don't think it would be appropriate to commit a patch
 to portage that wipes out all our stable keywords in one go.  I think it
 would be more appropriate to phase such a change in gently, because as far
 as I know, no one else has really done this.  The other archs typically
 maintain a stable/unstable set of keywords in the tree.  So I think this
 should be managed by the profiles.  I've been needing to do some profile
 cleanup anyways, so I can probably fiddle with a 2008.0-dev profile set to
 only do ~arch, and then see how that goes.

that certainly sounds reasonable to me.  if the stable cant be maintained, let 
the common workflow of developers transition it back to ~arch until someone 
has the time to keep arch usable.  changing profiles.desc accordingly should 
be done ahead of time.  perhaps a new category for profiles.desc ?  exp for 
such ports ?  i could see all *-fbsd ports being moved there.  tweak repoman 
to be less verbose about dep issues for such profiles and we're set.

 3. Should Gentoo even continue to support mips?

i see dropping keywords as a very last resort.  getting a port *back* into the 
tree is a *tremendous* amount of work (i went through it and it was hell), 
while keeping ~arch alive is a sliver of effort and generally not a blocker 
for package maintainers.

 Do people even *use* mips? 

mips certainly sees use on the embedded side.  there should be no doubt 
whatsoever about its usage.
-mike


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


[gentoo-dev] Re: Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

2008-01-09 Thread Markus Ullmann
Thanks for your input on this, really made it look by 200% better from 
what we have so far on this list and gives a much better point of view 
to judge from.


Kumba++

Greetz
-Jokey



signature.asc
Description: OpenPGP digital signature