Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009

2008-06-18 Thread Chris Gianelloni
On Sat, 2008-06-07 at 14:46 +0100, Alex Howells wrote:
 I agree with both of these and also think both agaffney and wolf31o2
 would serve us excellently on Council.  Consider them nominated too :)

Thanks, but I no longer have the time nor the desire to dedicate to the
Council.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-18 Thread Chris Gianelloni
On Fri, 2008-06-13 at 11:14 +0100, Ciaran McCreesh wrote:
 But some EAPI-0 accepting Portage versions don't accept inline
 comments. Using inline comments in the tree will break those Portage
 versions.

Yes, and EAPI=0 accepting Portage versions also didn't accept things
like package.use and use.mask in the profiles, considering that EAPI=0
doesn't have a set definition and was based upon a particular portage
version that did have the required support.  So should we ban those from
the tree, too?

Oh yeah, PMS isn't approved, anyway, so there's no policy *at all*
within Gentoo that denies a package manager from being used that doesn't
conform to your idea of how things should work.

 This one's especially an issue when you consider how long it's been
 since Gentoo has released official stage tarballs...

Wow.  Your second stab at my team in 3 days, without me even responding.

I should probably be blushing if it weren't for the fact that I really
don't give a damn about you or anything that you say.

Quite honestly, the same goes for pretty much anybody who works with
you.  You are a poisonous person to Gentoo and I sincerely wish that
some day people around here will grow a pair and realize that your
incessant self-absorbed bullshit simply isn't something we really want
around here.  I mean, we've already thrown out you and three of your
cronies because your attitude sucks and you're all a pain in the ass to
work with.  What exactly do we need to do here?  Ban you all?

I find it massively amusing that most of the traffic on this list over
the past 3 days has come from people that have been *FORCIBLY* removed
from the Gentoo project.

Oh yeah, don't bother responding to me.  I've decided to put you and all
of your little cohorts into my killfile so I no longer have to read your
constant barrage of bullshit.

Seriously, you're a complete fucking waste.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-18 Thread Chris Gianelloni
On Fri, 2008-06-13 at 11:22 +0100, David Leverton wrote:
  PS: An example of something in PMS that is different from Portage:
  inline comments are disallowed. The only reason I can think for
 doing
  this is to not make Paludis change it's behaviour.
 
 Fortunately you don't have to think, you can just read Ciaran's
 explanation.

Yes, because we all should stop thinking for ourselves and let Ciaran
tell us what to think.  After all, we all want to be like the cool
Paludis developers.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-18 Thread Chris Gianelloni
On Fri, 2008-06-13 at 12:22 +0200, Luca Barbato wrote:
 David Leverton wrote:
  On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote:
  Interesting to note, however, that Paludis doesn't accept inline
  comments, and this behaviour predates PMS.
  
  There's a reason for Paludis not accepting them, and the same reason 
  applies 
  to the question of allowing them in PMS or not, therefore PMS doesn't allow 
  them.  There's no evil conspiracy here, just pure logic.
 
 Care to share the logic and wise reasoning ?

[ ${IDEA_ORIGIN} != Ciaran ]  die

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-18 Thread Chris Gianelloni
On Fri, 2008-06-13 at 11:23 +0100, Ciaran McCreesh wrote:
 Did you check whether Portage that's included in current Gentoo
 releases supports inline comments in profiles?

Yeah, the version in 2008.0_beta2 surely does.  Perhaps you meant
something else?  Well, either that, or you're just posting more of your
bullshit where you obscure or otherwise lie about the facts to suit
yourself.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-18 Thread Chris Gianelloni
On Fri, 2008-06-13 at 11:27 +0100, Ciaran McCreesh wrote:
  Well, then it should be updated to match current Portage behaviour.
  PMS is not supposed to document How portage worked at one point of
  time or The intersection of the capabilities of Portage and
  Paludis. It should follow the current portage's behaviour as closely
  as possible.
 
 Do you really want to make it impossible to install Gentoo using the
 most recent official release? Because that's what will happen if we do
 what you're suggesting...

Considering that the most recent official release is 2008.0_beta2, I
don't see where you have a point, at all.

Sure, you're going to mention something about being labeled a beta, to
which my response will be that you're simply backpedaling and changing
the facts to suit your needs.  After all, looking at /releases on the
mirrors, I see a nice and shiny 2008.0_beta2 on all of the
officially-supported arches.

Isn't it about time that you gave up on your little mission to
consistently undermine the hard work put in by a community of
volunteers?

Of course not... You need to stroke your ego some more.  Pfft...

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-18 Thread Chris Gianelloni
On Fri, 2008-06-13 at 12:44 +, Duncan wrote:
 Ciaran's right on this one.  It may have been a bug in portage, now 
 fixed, but at least until a stable current release media set, a working 
 PMS can't change the EAPI-0 definition to fail with portage on the old 
 release media, however stale it might be.  If a current release happens 
 before PMS EAPI-0 finalization, this could possibly be subject to debate, 
 but until then, it just doesn't work, however much we might wish it could.

No, he isn't.  For one, we're talking make.conf, not the profiles.
Second, there's a newer official (and stable) media set.  Sorry if you
don't like the beta moniker, which applies to the media set.  After
all, does a package suddenly become less stable because it is included
in a tarball that has beta in the *FILE NAME* ?  I don't think so.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-18 Thread Chris Gianelloni
On Sun, 2008-06-15 at 15:50 +0100, Ciaran McCreesh wrote:
 Do you think that the differences between the proportion of patches
 from 'Paludis people' that are accepted or rejected and the proportion
 of patches from 'Portage people' or 'Pkgcore people' indicates a
 problem?

Nope.   What I see as a problem is that the primary author and current
de facto maintainer is so much of an asshole that he was forcibly
removed from the Gentoo project, which PMS is supposed to be written
for, and has ostracized (at least) one of the package manager's
development team with his constant not-so-subtle attacks.  Quite
frankly, I'd prefer see Gentoo take control over the specification that
defines the most important single feature of Gentoo and remove the
non-Gentoo developers from its development.  No offense, but you're not
a Gentoo developer any longer and you shouldn't have a say in how *we*
manage ourselves.  You're more than welcome to contribute code, fork, or
whatever the hell you want.  This is open source, after all, but that
doesn't mean you should be allowed to hold the position of power over
Gentoo that you've been granted.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-18 Thread Chris Gianelloni
On Sun, 2008-06-15 at 16:04 +0100, David Leverton wrote:
 On Sunday 15 June 2008 15:42:28 Peter Volkov wrote:
  For example, currently, PMS team does not include anybody from portage
  team - official PM team and thus this team can't represent Gentoo
  interests.
 
 The Portage team is perfectly welcome to contribute if they wish.  zmedico is 
 on the alias, although he seems to have been focussing on working on Portage 
 itself.  genone, from what I've seen, seems to be indifferent at best to the 
 idea of PMS.
 
 I'm curious as to why you think the actively contributing members of the PMS 
 team aren't acting in Gentoo's interests, though.

Maybe because they were booted from Gentoo for not acting in Gentoo's
best interest?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Packages broken by phase ordering change

2008-06-18 Thread Chris Gianelloni
On Sat, 2008-06-14 at 15:09 +0100, Ciaran McCreesh wrote:
 On Fri, 13 Jun 2008 21:55:29 +0200
 Santiago M. Mola [EMAIL PROTECTED] wrote:
  As discussed in bug #222721, portage has changed the execution order
  of phases. It seems the change was introduced in portage-2.1.5 and it
  makes that, when upgrading a package, pkg_postinst is run after the
  old version has been removed. This breaks packages which use
  has_version in pkg_postinst to detect upgrades/downgrades. It can also
  break packages in more subtle ways.
 
 Given that the number of affected ebuilds is so high, I'd say Portage
 should have to revert the changes...

Of course, you would.  What else would we expect from you?

 This is an EAPI scope change, if anything. Although even then the
 implications are a bit messy since you're talking the interaction of
 two different EAPIs.

It seems that everything these days is an EAPI scope change.  That's not
very useful for Gentoo, considering it's been quite some time since PMS
was proposed and we've not seen approval for either EAPI=0 or EAPI=1 (or
PMS, for that matter).  What we have gotten is a half-assed you can use
EAPI=1 in the tree to get these enumerated features from the Council,
but that's nothing like acceptance of a spec.  Perhaps if you spent a
little more time doing something more constructive than being an asshat
on the lists, PMS would have been approved long ago.  Of course, that
doesn't mesh well with your apparent need to be a complete dick to
people, so continue on with the status quo.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] OT Foundation - Council was - Nominations for council

2008-06-06 Thread Chris Gianelloni
Can you take this off-topic thread to the appropriate list?  I'm pretty
tired with hearing the Foundation's self-promotional comments on how
important it is to development on this list.  You guys have your own
list for that crap, as it is.

Thanks,

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] RFC: lzma tarball usage

2008-05-07 Thread Chris Gianelloni
On Wed, 2008-05-07 at 16:23 +0300, Mart Raudsepp wrote:
 I do realize one would remove build-time dependencies and the toolchain
 on an embedded system on deployment anyway, but this means gcc USE=nocxx
 USE flag is pretty much useless, while it would be nice to use it to
 ensure that nothing sneaks in during development that depends on the C++
 standard library easily instead of finding things break later.

It's a pain in the ass for Release Engineering, too.  At this point,
we're looking into how we need to modify the bootstrap sequence to
accommodate people using lzma for system (and lower) packages.

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

We're already getting reports of this due to someone deciding that it'd
be a good idea to use lzma for our daily portage snapshots without any
discussion here.  Luckily, we still have the other tarballs to use, too.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] config_eth0 deprecated - new name?

2008-04-23 Thread Chris Gianelloni
On Wed, 2008-04-23 at 16:21 +0100, Roy Marples wrote:
 address_eth0?

 addresses_eth0?

I think one of these two is the most obvious to people.  Since most
people will likely only have one address per interface, I'd say that
address_eth0 sounds good.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Dependencies that're available at pkg_*inst

2008-04-22 Thread Chris Gianelloni
On Tue, 2008-04-22 at 08:09 +0100, Ciaran McCreesh wrote:
  We definitely don't want to install DEPEND at the pkg_* stages, so I'd
  say the requirement there, if you're asking, is prior to src_*, if
  that matters.
 
 If the alternatives are not being able to install from a binary at all
 due to circular dependencies, or being able to install from a binary
 using DEPEND to satisfy circular dependencies, which would you take?

Given the trouble that we have every release with trying to cram
everything our users want into a limited space, I'd rather the damned
thing not install than pull in a bunch of packages we don't need, just
to satisfy a dependency that isn't even used during execution of the
package.

  I'd love to have some kind of functionality to allow some kind of
  optional dependencies.  The only real way that I could see this
  working is if we tracked what was installed as an optional dependency,
  and not reinstall it if it has been removed the next time the
  depending package is merged.
 
 Sort of like what kdebuild has for suggested dependencies, but less
 strong?

Pretty much, yeah.  The main difference that I would see from the
current *DEPEND variables, besides what was said above, would be that a
lack of visibility wouldn't stop the package merge.  If sys-apps/foo had
ODEPEND=dev-libs/bar and dev-libs/bar was masked, it simply wouldn't
be installed.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Dependencies that're available at pkg_*inst

2008-04-21 Thread Chris Gianelloni
On Sat, 2008-04-19 at 06:33 +0100, Ciaran McCreesh wrote:
 On Fri, 18 Apr 2008 22:27:21 -0700
 Donnie Berkholz [EMAIL PROTECTED] wrote:
  My interpretation is pkg_* counts as runtime (I can imagine a package 
  wanting to run itself at this point), so packages in RDEPEND should
  be usable at that point.
 
 Which would be fine, except it makes the tree unusable.
 
  Really, it seems to be an additional type of dependency that neither
  DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't
  quite capturing it either.
 
 Yup, and for future EAPIs labels can fix this. But we have to have a
 sound solution for current EAPIs.

I would agree that RDEPEND should likely be installed prior to
pkg_preinst to satisfy the dependency.  After all, PDEPEND is good
enough for doing packages that aren't required at
pkg_preinst/pkg_postinst.

We definitely don't want to install DEPEND at the pkg_* stages, so I'd
say the requirement there, if you're asking, is prior to src_*, if that
matters.

I'd love to have some kind of functionality to allow some kind of
optional dependencies.  The only real way that I could see this
working is if we tracked what was installed as an optional dependency,
and not reinstall it if it has been removed the next time the depending
package is merged.

Simple example:

ODEPEND=video_cards_nvidia? ( x11-drivers/nvidia-drivers) would
install x11-drivers/nvidia-drivers the first time it's ran with
VIDEO_CARDS=nvidia, but if I removed x11-drivers/nvidia-drivers, it
wouldn't get reinstalled.  This would probably need some kind of
--newuse like capability to allow for installing only *new* optional
dependencies, but I think that the tracking would already allow that.
The idea here would be to allow for installing recommended software
along with others.  We could even have --ask ask for the dependencies,
since they are optional, after all.

This way, we could ship a more robust configuration/setup for many
popular applications without forcing software on people.

It's an idea, anyway, and I hope that I didn't hijack the thread.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Early stabilisation

2008-04-16 Thread Chris Gianelloni
On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote:
  thirty days is the norm for the minimal period between an ebuilds last

It is the norm.  It is not a requirement.  In fact, it is specifically a
guideline rather than a hard rule.  It is up to the maintainer's
discretion when to ask for stabilization, just like it is up to the arch
team's discretion when to actually *do* the stabilization.  If you don't
think that it's ready on your arch, say so, but be prepared to defend
why you think so when the package maintainer, who should be much more
familiar with the package, thinks that it is ready.

  On the other hand, maybe these early stabilisation bug reports are a
  sign of the times and we need to shorten the normal thirty day period,
  become even more of a cutting edge distro - or at least discuss the
  options.
 
 I'd say leave the current norm and smack the misbehaving maintainers :)

Who says that they're misbehaving?  Again, the maintainers probably know
their packages better than anyone else, so why are we not trusting their
judgement again?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] New profiles

2008-04-09 Thread Chris Gianelloni
Please remember to sync gentoo-x86/profiles before doing any further
commits.  The new profiles need as much checking as possible.  There
have been several commits made by people who have masked things and such
but forgot the new profiles.  Also, if you make changes to any of the
new profiles, please let me know so I can sync the changes into the
snapshot tree.

Thanks,

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



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

2008-04-03 Thread Chris Gianelloni
On Thu, 2008-04-03 at 13:49 +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
   If we used git, proxy maintaining would be easier.
  
 
   True, but with some acls we could also have a different model where people
  worked on parts of the tree and where commit privileges didn't pose so many
  security risks. With the current practice of doing work in overlays it would
  also be simpler to merge the work back into the Portage tree.
 
 Also Subversion would be sufficient.

Release Engineering has been using subversion for the 2008.0 snapshot
tree.  The repository is running in tmpfs on a dual Opteron box.  IT's
still quite painfully slow.  Of course, we're doing commits at the
top-level since we have a single top-level ChangeLog for the repository,
but we don't even have history.  We literally just pulled ebuilds from
the tree.

Once the release is done, we can play around with the repository all
that we want to get some real numbers, but unless there's some magic
bullet that I'm missing, subversion might simply be too damned slow for
our needs.  As an anecdotal example, I've had a single commit of several
profiles take up to 6 minutes to complete, and that's not with repoman
or anything.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



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

2008-04-03 Thread Chris Gianelloni
On Thu, 2008-04-03 at 09:21 -0400, Richard Freeman wrote:
 Regardless, as long as devs actually follow policy I don't see any need 
 to boot them.  Maybe very long periods of inactivity should result in 
 having accounts locked as a security measure (so that we don't end up 
 with hundreds of ssh keys with commit access floating around who knows 
 where).  Booting out lots of devs just takes a limited set of resources 
 and limits them further.  If anything we want to find a way to let more 
 people contribute in a significant way - not less...

I think many people seem to forget that it isn't the number of
developers or the number of commits.  It is all about the amount of
actual work that gets done.  We need more work being done.  Period.  It
doesn't matter how that gets accomplished, but it is what we need.
Removing less active developers would be perfectly fine once we had a
good proxy maintainer program in place that would allow people to
contribute easily without having to have commit access.  A developer who
only commits rarely isn't any more valuable to Gentoo than a regular
user who contributes at the same pace.  The only difference is the
commit access and the Gentoo resources used by the individual.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Help offered - Portage tree

2008-03-13 Thread Chris Gianelloni
On Thu, 2008-03-13 at 17:22 +0100, Fabio Erculiani wrote:
 [gio mar 13 2008] [02:54:56] lxnay  agaffney: I don't think it's
 worth it wasting my time insulting you, I've something better to do

 [gio mar 13 2008] [02:55:07] agaffney   lxnay: oh, burn!
 [gio mar 13 2008] [02:55:11]   * agaffney cries in the corner

 [gio mar 13 2008] [02:55:40] lxnay  what stupid are you

Thanks for reminding me once again how you like to interact with the
people that you're trying to help out.  You wonder why people respond
negatively to your demands and this is how you react to people.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Help offered - Portage tree

2008-03-13 Thread Chris Gianelloni
On Thu, 2008-03-13 at 17:48 +0100, Fabio Erculiani wrote:
 On 3/13/08, Chris Gianelloni [EMAIL PROTECTED] wrote:
  I'm a distro builder, too, and I haven't been hitting any of these
   problems.  Would you care to point out the actual problems, or will the
   close to useless comment be our only indication of the perceived
   problems?

 Yeah, but IIRC you are a SOURCE distro builder. Arent't you? (I am just 
 asking!)

No.  I build binary packages.  Hell, catalyst uses the binary package
support *heavily* for its caching.

Do people really think that a pre-compiled stage tarball is source?  How
about a pre-compiled LiveCD?  Anyone?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Help offered - Portage tree

2008-03-13 Thread Chris Gianelloni
On Thu, 2008-03-13 at 14:48 -0400, Caleb Tennis wrote:
  As much as I hate to say it, your example was rather bunk, because
  openssl changed SONAME during that time.  Keeping the package
 
 You're right here.  After review, the problem was the difference between 
 0.9.8e and
 0.9.8g, the latter of which provided some form of newer symbol that wasn't in 
 e. 
 But the concept is the same.

Correct.  That would not have been caught and would be an issue, still.

  Uhh... = in RDEPEND does that, already... Also, this wouldn't have
  resolved your openssl issue, at all.  Your machine scenario above would
  have still failed, since the minimum version was 0.9.7 on your build
  host.
 
 I'm not talking about meeting the minimum required by the ebuild, I'm talking 
 about
 the minimum that were installed at the time of the emerge.
 
  Well, I sincerely hope that you do not file such a bug, as it would
  royally screw over the one team in Gentoo that *does* consistently use
  our binary package support.
 
 I don't plan on filing the bug, but if it was an optional emerge option to 
 use the
 actual version deps vs. the DEPEND of the ebuild, it wouldn't affect you 
 would it?

If it were optional, it wouldn't affect us.  I'd have no issue with some
kind of optional support for this sort of thing.

  I would definitely like to see the support improved, but not at the
  expense of doing very stupid things like locking to specific
  versions/revisions of packages.  No offense, but that screams of RPM
  hell.
 
 I'm not trying to lock to any specific version.  I'm trying to reproduce on 
 machine
 2 the same state of packages that package A was compiled against on machine 
 1.  And
 even make it optional to do so, via an emerge flag.

This is likely usually done by controlling the binrepo.  At least,
that's how I do it.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] RE: Mesa on i965 (DRI)

2008-02-29 Thread Chris Gianelloni
On Thu, 2008-02-28 at 20:19 +0100, Mateusz Mierzwinski wrote:
 Ok, I've try i810 and... no DRI.

Please take this off the general development mailing list and to one of
the support lists, or, even better, to our bug tracker at
http://bugs.gentoo.org instead.

Thanks,

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: What is bump request?

2008-02-27 Thread Chris Gianelloni
On Tue, 2008-02-26 at 20:47 -0600, Ryan Hill wrote:
 Shaochun Wang wrote:
  I see the phrase bump request in bugzilla of Gentoo. What does it
  mean?
 
 A request to update the version of a package in portage to a later one, 
 usually 
 the latest released.

It is also done by many people as an attempt to get the developer to
look at an issue.  This is usually done by people used to web forums,
where things are sorted by the most recent and things disappear off the
front page over time.  Most of these people either do not realize that
bugs do not act the same as a web forum, or they're simply rude and
trying to tell the developer that they think that their issue is more
important than others.  ;]

Generally, bump request means to bump the version of a package,
whereas just bump is for bumping the thread...

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] MESA i965 SUPPORT PLEASE!

2008-02-27 Thread Chris Gianelloni
On Wed, 2008-02-27 at 20:11 +0100, Mateusz Mierzwinski wrote:
 Another day with non compatible DRI on X. After 3 days of discover I've 
 saw that Xorg must be compiled with same NPTL flag setting as MESA but 
 guess what? Someone don't insert i965 card from VIDEO_CARD variable but 
 Mesa sources allready provide that card's drivers. If I want to install 
 Mesa with i965 card support I must download source from 
 www.intellinuxgraphics.com by git and compile it by myself. But what 
 should I do if I cannot enable NPTL flag in make compiled source without 
 ./configure script?. Better to add i965 to mesa VIDEO_CARD variable. I 
 don't want to change compile profile to non-NPTL.

This belongs in a bug report.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] MESA i965 SUPPORT PLEASE!

2008-02-27 Thread Chris Gianelloni
On Wed, 2008-02-27 at 20:11 +0100, Mateusz Mierzwinski wrote:
 Another day with non compatible DRI on X. After 3 days of discover I've 
 saw that Xorg must be compiled with same NPTL flag setting as MESA but 
 guess what? Someone don't insert i965 card from VIDEO_CARD variable but 
 Mesa sources allready provide that card's drivers. If I want to install 
 Mesa with i965 card support I must download source from 
 www.intellinuxgraphics.com by git and compile it by myself. But what 
 should I do if I cannot enable NPTL flag in make compiled source without 
 ./configure script?. Better to add i965 to mesa VIDEO_CARD variable. I 
 don't want to change compile profile to non-NPTL.

Even better... i965 support is added by VIDEO_CARDS=i810 already.  You
don't need to do anything by hand...

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] clean deprecated eclasses(?) (was: missing quotes in eclasses)

2008-02-14 Thread Chris Gianelloni
On Thu, 2008-02-14 at 16:52 +0300, Peter Volkov wrote:
 The check was done with the following script:
 
 find /usr/portage \( -name '*.ebuild' -o -name '*.eclass' \) \
 -exec awk /inherit.*[[:blank:]]+${eclass}([[:blank:]]+.*|$+)/{print FILENAME 
 } \{\} \;
 
 For inherit eclass I've searched manually.

There's also games-etmod games-ut2k4mod and games-q3mod which were all
replaced by games-mods quite some time ago.  There isn't anything in the
tree using these.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] clean deprecated eclasses(?)

2008-02-14 Thread Chris Gianelloni
On Thu, 2008-02-14 at 16:03 +0200, Petteri Räty wrote:
 Peter Volkov kirjoitti:
  
  May be we should punt them from the tree?
  
 
 Eclasses can't be removed...

Well, this isn't really true anymore thanks to bug #46223 being
resolved.  I'd say that it only makes sense that we keep them around for
a long time from here on out, but they *can* be safe to move in the
future.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Removing default-darwin profiles

2008-02-14 Thread Chris Gianelloni
On Thu, 2008-02-14 at 20:21 +0100, Fabian Groffen wrote:
 Before doing so I'd like to hear if anyone has objections to removing
 it, and the keyword + profile from arch.list and profiles.desc.  Also,
 do I forget anything?

Let me know if/when you do this so I can do the same in my snapshot.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: [RFC] Adding two USE flags to 2008.0's profiles

2008-02-02 Thread Chris Gianelloni
On Sat, 2008-02-02 at 09:45 +0100, Christian Faulhammer wrote:
 Chris Gianelloni [EMAIL PROTECTED]:
  If adding bluetooth seems to be a bit much, how about just the usb
  USE flag?  After all, my UPS won't work with apcupsd without USE=usb
  on my server... ;]
 
  I don't know how badly needed bluetooth is (no need here), but I
 remember we had to mask USE=bluetooth two times in the last week (KDE
 and something else, pulseaudio I think) to not break stable users...so
 I consider it a bit of a cruft.

Understandable, bluetooth isn't the most mature thing in Linux.  It
tends to either work or it doesn't.

OK, then I'll just add usb across the board.  We can hold off until
later for bluetooth support.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Changes to some profiles

2008-02-02 Thread Chris Gianelloni
On Sat, 2008-02-02 at 09:45 +, Duncan wrote:
  How about just some elog If you use make install, emerge --noreplace
  debianutils in the kernel's postinst or something.
 
 Well, that doesn't help those who get their kernels elsewhere, which IMO 
 are the ones most likely to have their own scripted solutions using make 
 install and thus debianutils in the first place, thus the general 
 announcement suggestion, but a kernel-2.eclass einfo as proposed is a 
 start and certainly won't hurt. =8^)  (Also, as I've said, folks with 
 such site-customized scripts are precisely the ones advanced enough they 
 /should/ catch it and be well able to make the necessary changes 
 themselves, regardless of warning, but should != will, and a GMN/GWN/
 upgrade-guide warning is a nice touch in any case.)

Well, we can hold off adding it to the actual tree until after the next
GMN, so that's not really an issue.

My main question was if there was any opposition, and it appears that
there is none, so long as information is provided to our users.  I'm in
total agreement.

If I don't hear any complaints, I'd like to go ahead and get a GMN
article together.

Do we really need a front-page news item for this?  I don't think the
impact would be terribly great, as I suspect this affects a very small
number of people whom are likely to be more advanced users.  I think
adding the info to GMN/gentoo-dev-announce/gentoo-user should suffice.
If someone thinks we need to do a front-page article, we can do that,
too.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Changes to some profiles

2008-02-02 Thread Chris Gianelloni
On Sat, 2008-02-02 at 14:21 +0100, Vlastimil Babka wrote:
 Chris Gianelloni wrote:
  Do we really need a front-page news item for this?  I don't think the
  impact would be terribly great, as I suspect this affects a very small
  number of people whom are likely to be more advanced users.  I think
  adding the info to GMN/gentoo-dev-announce/gentoo-user should suffice.
  If someone thinks we need to do a front-page article, we can do that,
  too.
 
 IIRC it will affect only 2008 profiles, and not older, so people have to 
 switch profiles first? Which already involves knowing what you're doing?
 So what about putting up a GMN/front page article announcing all such 
 changes in new profiles, and not just for debianutils removal. I don't 
 recall there was this kind of article/documentation before, but might be 
 wrong.

Ehh, I didn't say I was only doing it for 2008.0's profiles.  I *could*
but there's not really much point.  The package isn't needed in system
for anything to compile/run, so why should we force it onto everyone's
machines?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


[gentoo-dev] Changes to some profiles

2008-02-01 Thread Chris Gianelloni
OK, so I built a complete set of stages (with no circular dependencies!)
on amd64 for testing, using both the default-linux/amd64/dev/2008.0
and the default-linux/amd64/dev/2008.0/desktop profiles with the
following changes and everything worked perfectly.  I would like to
replicate this to the tree before the snapshot today.  If nobody has any
objections in the next 12 hours or so, I'm going to do it.

base/packages:
removed debianutils
removed perl
removed python
changed sys-apps/portage to virtual/portage

default-linux/packages.build:
removed perl
removed python
changed sys-apps/baselayout to virtual/baselayout
changed sys-apps/portage to virtual/portage

Even without perl/python in packages.build, we still end up with both in
stage1's tarball.  We pull in perl via auto{conf,make} and python via
portage (duh).  I'd like to also try removing autoconf and automake from
packages and packages.build above, since things *should* now be
depending on them if they need them.  Of course, I won't commit that
until after posting here again after testing it and being sure it's
good.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


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

2008-02-01 Thread Chris Gianelloni
On Fri, 2008-02-01 at 19:59 +0100, Tiziano Müller wrote:
 GLEP46, as discussed on Januar 21-24.
 I'd say it's ready. The only minor thing is where to keep the list of
 available tags. As far as I understood neysx we should keep it in
 metadata.dtd itself.

http://www.gentoo.org/proj/en/glep/glep-0046.html for anybody wanting to
know what GLEP49 entails.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Changes to some profiles

2008-02-01 Thread Chris Gianelloni
On Fri, 2008-02-01 at 23:47 +0200, Petteri Räty wrote:
 Chris Gianelloni kirjoitti:
  
  base/packages:
  removed debianutils
 
 I don't think we reached a decision on whether debianutils should go to 
 kernel-2.eclass before this is done.

Actually, it isn't very important if it happens or not (to me/release),
and doesn't change that I'll be testing with it, either way.  After all,
it's a rather simple change to revert.  That being said, you've got
until March 10th (final snapshot freeze) to decide.  ;]

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] [RFC] Adding two USE flags to 2008.0's profiles

2008-02-01 Thread Chris Gianelloni
I'm thinking of adding both the bluetooth and usb USE flags to the
2008.0 profiles for amd64/x86.  I'll be adding just usb for everybody
else, unless they want bluetooth, also.

So why am I asking about this?

Well, I'm wanting to add it to the 2008.0 profiles, not the desktop
or server sub-profiles.  This means it'll hit pretty much everybody.
That being said, this normally enables hardware support, so I see it as
a good thing.

If adding bluetooth seems to be a bit much, how about just the usb
USE flag?  After all, my UPS won't work with apcupsd without USE=usb
on my server... ;]

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] debianutils: system worthy ?

2008-01-30 Thread Chris Gianelloni
On Wed, 2008-01-30 at 12:35 -0500, Philip Webb wrote:
 'equery d debianutils' gives me 
 
   app-admin/sysklogd-1.4.2_pre20061230 (sys-apps/debianutils)
   app-portage/gentoolkit-0.2.3-r1 (userland_GNU? sys-apps/debianutils)
   sys-apps/mktemp-1.5 (=sys-apps/debianutils-2.16.2)
 
 The 2nd cb ignored, but the others seem important.
 I have Mktemp-1.5 installed, so what do you mean by your lines 1-2 ?

Funny enough, mktemp is included in newer coreutils.

 Sysklogd seems to be an important pkg too.

Unless you use metalog, or syslog-ng, or...

 What am I missing (smile) ?

That nothing that you've said counters the package not being needed in
the system target.  In fact, the packages that you list all explicitly
depend on debianutils, so they wouldn't break if we removed it from
system.  The problem is packages which require debianutils but do *not*
depend on it, because it's in system now.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] debianutils: system worthy ?

2008-01-30 Thread Chris Gianelloni
On Wed, 2008-01-30 at 10:32 -0800, Chris Gianelloni wrote:
 That nothing that you've said counters the package not being needed in
 the system target.  In fact, the packages that you list all explicitly
 depend on debianutils, so they wouldn't break if we removed it from
 system.  The problem is packages which require debianutils but do *not*
 depend on it, because it's in system now.

I'm running a stage build with debianutils removed from system.  I'll
let everyone know the results.  If it works, I'll do the same for a
LiveDVD build, which covers most of the major packages in the tree.
Sure, there might be a few stragglers after that, but I doubt that there
would be too many.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: removal of digest files from the tree

2008-01-30 Thread Chris Gianelloni
On Thu, 2008-01-31 at 00:45 +0100, Santiago M. Mola wrote:
 On Jan 31, 2008 12:32 AM, Robin H. Johnson [EMAIL PROTECTED] wrote:
 
  On Thu, Jan 31, 2008 at 12:05:26AM +0100, Vlastimil Babka wrote:
   Chris Gianelloni wrote:
   I think throwing up an announcement today/tomorrow for Thursday/Friday
   should be sufficient for this sort of a change, as it won't affect any
   user who has a version of portage released in the past ~1.5 years.
   So, since it seems nobody objected it, time for the announcement? And the
   removal (server-side by robbat2) would be best done right before the
   snapshot?
  It's pretty much irrelevant to the snapshot. wolf31o2 has my patch to
  exclude digests in the snapshot anyway.
 
 
 Then I guess it could be done as soon as the doc patch is prepared...

It really is best done in the tree first, so everything is correct for
the snapshot.  We didn't have much issue last time because we push
manifest1_obsolete into the snapshot, so digests are removed, anyway,
but I'd *really* prefer if this were done prior to the snapshot being
made.

The less fudging I have to do with the snapshot, the better.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] archives.gentoo.org linking brokenness

2008-01-27 Thread Chris Gianelloni
On Sun, 2008-01-27 at 01:49 -0800, Robin H. Johnson wrote:
 sequential numbers), but it will be a day or two - restoring the old
 ones is not possible at all.

Umm... OK.  What's the new format?  Do we just have to go an manually
change every single link we've ever made to anything on archives?  How
are we going to find the articles if the old links don't work?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] RFC: removal of digest files from the tree

2008-01-27 Thread Chris Gianelloni
On Sun, 2008-01-27 at 06:27 -0800, Robin H. Johnson wrote:
 Due to how CVS hooks operate, it's not quite possible.
 You wouldn't be able to block the entire commit, only the contents of
 the files/ directory would get totally blocked.
 If you were committing an ebuild along with a patch, this would be very
 bad, as the ebuild+Manifest would get committed, but the patch wouldn't.

Bleh... CVS vs. SVN.  There's no pre-commit equivalent on CVS?

Also, wouldn't the second Manifest run fix the missing digest commit?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] RFC: removal of digest files from the tree

2008-01-27 Thread Chris Gianelloni
On Sat, 2008-01-26 at 17:08 -0800, Zac Medico wrote:
 If there are no objections then I don't so any reason not to go ahead and add
 the manifest1_obsolete sometime in the near future. Thoughts?

1. Add blocking of commit of files/digest-* in CVS pre-commit hook
2. Add manifest1_obsolete to tree
3. Remove all files/digest-* files from tree (on CVS server side)
4. Remove all files dirs that are empty (on CVS server side)

This should be all that we need.  The 2007.1 snapshot was done without
any digest files, and it worked just fine, also the default settings
have been to not sync the digest files for some time, so only people
with an older/unsupported portage have been getting digest files, at
all.

I do have one question, though.  What does an older portage version do
when it hits a package with a missing digest file?

Let's say I've got portage prior to 2007.0's, so it doesn't support
Manifest2 only.  I want to emerge --oneshot portage to get to the
latest version.  What do I need a digest on?  Just portage?  portage and
its dependencies?  Which dependencies?  All of them, or just the ones
I'll actually need to merge?

I guess what I'm asking is if it is possible to have repoman create a
digest for sys-apps/portage only, for the slow upgraders.  Of course,
this assumes its even possible on the portage side to bother.  If not,
just ignore this part.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] RFC: removal of digest files from the tree

2008-01-27 Thread Chris Gianelloni
On Sun, 2008-01-27 at 17:11 -0800, Zac Medico wrote:
  If there are no objections then I don't so any reason not to go ahead and 
  add
  the manifest1_obsolete sometime in the near future. Thoughts?
  Let's do it. I look forward to a lot less inodes on my disks.
 
 Let's schedule a date for it then and we can have a big announcement
 to let everyone know.

Dammit.

I wanted this before January 31st, so it would make it into the 2008.0
snapshot.  Do we think we can get this done by January 31st?

I think so.  One reason that I think that we don't need to wait very
long is rather simple.  People running very old versions of portage that
will be affected by this are also not likely to read our news or see our
front page on a regular basis.  They're likely to get broken, no matter
what we do.  Hell, even posting it to the GMN/forums/lists/planet/front
page, we'll still end up getting complaints from these people when they
come back $months from now and the news is no longer sticky in the
forums, has rotated off the front page, isn't even a distant memory on
the lists, and is in a several month old newsletter.

When gauging impact/scope of a problem, always look at who it affects
and the situation.  You only need to take as much precaution as
necessary to cover the cases worth spending the time to cover.  There
will *always* be corner cases.  You just try to minimize them.

I doubt much of anything aside from portage/paludis/pkgcore use the
digest files, and I'd bet that paludis/pkgcore don't use them, at all.

I think throwing up an announcement today/tomorrow for Thursday/Friday
should be sufficient for this sort of a change, as it won't affect any
user who has a version of portage released in the past ~1.5 years.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] RFC: removal of digest files from the tree

2008-01-27 Thread Chris Gianelloni
On Sun, 2008-01-27 at 18:01 -0800, Robin H. Johnson wrote:
 On Sun, Jan 27, 2008 at 05:34:14PM -0800, Chris Gianelloni wrote:
  On Sun, 2008-01-27 at 06:27 -0800, Robin H. Johnson wrote:
   Due to how CVS hooks operate, it's not quite possible.
   You wouldn't be able to block the entire commit, only the contents of
   the files/ directory would get totally blocked.
   If you were committing an ebuild along with a patch, this would be very
   bad, as the ebuild+Manifest would get committed, but the patch wouldn't.
  Bleh... CVS vs. SVN.  There's no pre-commit equivalent on CVS?
 There is pre-commit, but it's not recursive. It gets applied to only a
 single directory and in isolation from the other directories.

OK.  So we could block on commits of digest-* files to files, right?
What else would we need?

  Also, wouldn't the second Manifest run fix the missing digest commit?
 In what way? the problem I was concerned about was non-digest files
 not being committed leading to broken ebuilds.

Ahh, never mind... I was thinking of something else.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] archives.gentoo.org linking brokenness

2008-01-27 Thread Chris Gianelloni
On Sun, 2008-01-27 at 17:57 -0800, Robin H. Johnson wrote:
  Do we just have to go an manually change every single link we've ever
  made to anything on archives?  How are we going to find the articles
  if the old links don't work?
 Unfortunately the hard way, by hand.

Ouch.

 The new ones use a hash of (salt, Received, Date, Message-ID, From,
 Subject, List-Id), and it's guaranteed to be the same regardless of
 mhonarc deciding to ignore it's existing database.

OK.  At least now they're designed so that this cannot happen again.
Thanks for taking the time to code that part up.  I hope that you sent
that patch upstream!  ;]

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]

2008-01-23 Thread Chris Gianelloni
On Mon, 2008-01-21 at 20:34 -0500, Caleb Cushing wrote:
 On Jan 20, 2008 8:43 AM, Richard Freeman [EMAIL PROTECTED] wrote:
 Stefan de Konink wrote:
  ..very offtopic but how are you all compiling stuff like
 firefox on a
  ram disk. Or is 8GB of ram very cheap suddenly?
 
 not to mention, last time I checked open office only required ~2GB of
 space to compile and it takes more than firefox. Most apps can be done
 in less than 512MB

The largest abuser of space in the tree that I am aware of is
games-fps/ut2004-data which weighs in at nearly 7GB to install.  I'm
pretty sure that games-strategy/nwn-data is pretty close with USE=hou
sou enabled.  ;]

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: USE flag documentation

2008-01-15 Thread Chris Gianelloni
On Tue, 2008-01-15 at 17:00 -0600, Ryan Hill wrote:
 My expectation is that `grep flag use.local.desc` will give me a
 list of packages using that flag (or having it in the description),
 one per line. Putting paragraphs in there doesn't seem right.

A single long line still fills this requirement for us.  However, it
does bring up the point.  Why even have use.local.desc (or
metadata.xml's use tag) at all?  Is there really a need for a *global*
list of flags that are ebuild-specific?  (I don't care or have much
opinion, either way, I'm merely presenting some topic for discussion on
this.)

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Available hardware

2008-01-15 Thread Chris Gianelloni
On Tue, 2008-01-15 at 16:25 -0800, Daniel Ostrow wrote:
 1x HP ZX2000 1.4 GHz Itanium2

I know that you said off-list, but I'm stating this here simply because
I want to make sure people know that I have dibs if this meets my
needs.

Can this box be upgraded to SMP?

If not, I rescind my dibs since mine is more powerful.  I just want to
be able to have decent video so I can do games on IA64.  As you know, my
Itanium box is a server without AGP and with only PCI-X (so PCI video is
my only choice). 

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Seeking questions for a user survey

2008-01-14 Thread Chris Gianelloni
On Mon, 2008-01-14 at 04:33 -0800, Robin H. Johnson wrote:
 Release-related questions:
 - Should CD media be released at a different rate than stage tarballs?
 - Desired release frequency for minimal/livecd/GRP/stages (annual,
   bi-annual, quarterly, monthly, weekly?)
 - Do you use the installer or install by hand? (need an other field here)

This question would be interesting, though a little moot.  With future
releases, we're making the Installer binary-only.  The reason is simple,
there are too many possible failure opportunities in the live tree or
when building from source.  The number of installer bugs that are
simply compilation bugs (many of which are already fixed in newer
versions/revisions in the tree) is overwhelming compared to the actual
number of bugs in the Installer.  By making it binary only, we only
allow the Installer to use known-good input for producing a user's
system.  All networked installs will be manual, and will follow the
Handbook.  I've thought of producing a simple default source-based
install script that allows someone to still use a source-based and
current installation, without having to type in a bunch of commands.  I
don't know how well this would be received, but it could be something
that you could ask here.

 - How often do you use the media?

Which media do you use? (minimal, universal, livecd, livedvd)

Which version do you use? (So many people tell me things like, I still
use a $version CD, so I think it would be useful...)

 - How often do you install Gentoo (using the stage tarballs or the
   installer)?
 - Do you use GRP? 
 - Would you like to use GRP in future?
 - Binhost questions maybe?
 - Do you use the portage snapshot associated with the release or the
   latest available snapshot or other?
 - Do you use a Gentoo derivative? (give a list with an other option)

What features do you think are lacking on Gentoo install media? (free
form)

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Seeking questions for a user survey

2008-01-14 Thread Chris Gianelloni
On Mon, 2008-01-14 at 22:53 +, likewhoa wrote:
 Which DE/WM would you prefer for the gentoo livecd instead of the one
 provided?
  Kde 
  Xfce 
  Fluxbox
  E16
  Fvwm 
  Gnome
  Other

Can I suggest that we not ask anything that we likely won't change?  I
have a strong feeling that KDE would win out here, but there's *NO WAY*
that we can fit KDE on a LiveCD with the other stuff.  When we were
planning 2007.1, we had decided to switch to Xfce, simply because of the
space savings.  Cramming a lot of useful stuff onto 700MB is *not* an
easy task.  Space is our biggest enemy here.  Were we to drop the LiveCD
fully in favor of the LiveDVD, then I could see this as (somewhat)
valid, as all of those Window Managers/Desktop Environments are already
shipped on the LiveDVD (except FVWM).  I'm not too interested in
people's opinions for the defaults on a media set that includes them all
and each is only a click or two away, though, as it doesn't really add
anything to what we provide.  If it weren't for the size constraints,
I'd love to know what people prefer on the CD, so I don't want anyone to
think that we don't care.  We do.  We just are limited by a hard size
limit than we cannot do anything about and have to act accordingly.

 Do they use grp packages?
  Yes
  No
  What is grp?
  Sometimes
  Never

Definitely word this in a manner so people know what you're referring
to.  I would say something more along the lines of Do you use the
Installer in Networkless mode or GRP packages when installing your
system?

 Which livecd(s) do they prefer?
  Gentoo livecd-2007.0
  Sabayon livecd
  Sysresccd
  Knoppix
  My own
  Other

Be sure to list the Minimal CD and the Universal CD, as well as the
LiveCD, and also list the LiveDVD.  We'll have to relate this data to
the architecture used when we try to make anything useful out of it, but
it'll be more accurate, as I definitely want to know *which* Gentoo
media people are using.  I would also add something like an older
Gentoo CD to the mix.

 Do you think commercial packages should be part of the main tree?
  Yes
  No
  Why not
  Never!
  in unofficial overlay
  Dunno

Is this something that we really even want to ask?  I mean, if we're all
about trying to provide the best user experience, then binary packages
are almost a requirement, especially with binary packages that were
originally targeted at specific binary distributions.  I tend to see
this as one of those religious issues that is best left alone, like
emacs versus vi.

 How often should GWN be updated?
  once a week
  everyday
  every month
  every six months
  what is GWN?

Again, you're asking something that I don't think that we should be
asking.  We couldn't get content even though we begged and pleaded for
it.  No offense meant to anyone, but I don't care if people want a daily
newsletter.  If we cannot get enough content, we cannot get enough
content.  No survey is going to change that, and asking a question like
this gives the impression that the user's opinion will make a
difference, when it likely will not.  I'd much rather not ask questions
that the users are going to feel like they were ignored than ask them
and not make any changes based on the answers.  Of course, if you're
volunteering to pick up the slack and write any necessary articles to
make it happen at the interval decided by our users, well, I completely
welcome it, then... ;]

 Do you like the Gentoo Linux Installer (GLI)?
  Yes
  No
  Never heard of it

I'd like to see the answers to this one, but I have a feeling that
everybody has a love/hate relationship with this.  They either love it,
or they hate it.  I also tend to think that *many* people have an
opinion on the Installer without ever even using it.  As such, I don't
think that we'd get any usable results out of this, but it'll still be
fun to ask.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Seeking questions for a user survey

2008-01-14 Thread Chris Gianelloni
On Tue, 2008-01-15 at 00:34 +, likewhoa wrote:
   Do you think commercial packages should be part of the main tree?
Yes
No
Why not
Never!
in unofficial overlay
Dunno
 
  Is this something that we really even want to ask?  I mean, if we're all
  about trying to provide the best user experience, then binary packages
  are almost a requirement, especially with binary packages that were
  originally targeted at specific binary distributions.  I tend to see
  this as one of those religious issues that is best left alone, like
  emacs versus vi.
 
 Yea commercial packages should maybe be part of overlays.gentoo.org so
 that the tree can stay clean from these types of packages. But I agree
 if it's decided not to included in the user survey.

I look at it very differently.  One of the main advantages to Gentoo is
being source-based.  This allows us to ship packages in our repository
for binary and commercial packages that would otherwise be impossible in
a binary distribution.  Remember, we don't actually ship the commercial
software.  We ship a bash script (essentially) that tells how to install
the software.  As much as I like to appeal to zealots (hahaha, right), I
don't consider shipping a bash script telling how to install a product
to be *anything* like shipping said product, endorsing it, or anything
else license zealots will try to spout to justify the removal of GPL-2
code from our repository.

Many people don't consider overlays, even Gentoo-run ones, to be of
sufficient quality/support/whatever to be used on production systems.
These are the same systems and people that would most likely utilize
these commercial ebuilds.

Basically, it is removing the *option* to install these packages from
the people who would like to use them for the sake of the people who
*REFUSE* to use the packages and insist on their removal from the tree
simply because they don't like the license under which is was released.
I'm sorry, but if that's not against the idea of a free and open
community, I don't know what is.

You have the right to chose what licenses you wish to support and use
software which agrees with your ideals, but that doesn't give you the
right to *DENY* others to do the same.

Sorry, I just don't see it as a valid question, at all.

   Do you like the Gentoo Linux Installer (GLI)?
Yes
No
Never heard of it
 
  I'd like to see the answers to this one, but I have a feeling that
  everybody has a love/hate relationship with this.  They either love it,
  or they hate it.  I also tend to think that *many* people have an
  opinion on the Installer without ever even using it.  As such, I don't
  think that we'd get any usable results out of this, but it'll still be
  fun to ask.
 
 I for one never used it so I can't really love or hate it but from
 what people who have used it tells me to stay away from it because
 I'll eventually hate it.

Well, anybody who dislikes it because of bugs or a bad experience, I can
completely understand.  I was really speaking mostly of the people who
dislike the *idea* of an Installer for Gentoo, and then go and bash it
as much as they can without providing any real evidence or reasons,
except for the old faithful it's against the spirit of Gentoo reason,
which is a complete fallacy.  Again, Gentoo is about empowering the
users to make their own decisions.  No, I won't say Gentoo is about
choice, because that is *STUPID* in that it gives people an excuse to
argue about even the biggest piece of junk being added to our tree or
supported, as if we have to, to give them the choice.  Instead, I
prefer the concept of empowering the user to make their own choices,
where they can choose to add anything that they want in their personal
overlay, as we have given them the tools to do so.  Now, if a user wants
to use an Installer and someone wants to write the code, who are you (or
I) to say that they are in the wrong?  After all, isn't it that idea of
empowering the user *really* the spirit of Gentoo?

I think so.

 Thanks for the great feedback Chris Gianelloni

You're totally welcome.  Take what I've said here as my own opinion, of
course.

 Fernando
-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


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

2008-01-12 Thread Chris Gianelloni
(Didn't really have anything specific to reply to, so just picking this)

On Sat, 2008-01-12 at 05:39 +, Steve Long wrote:
 Mr McCormick

Ehh, Ferris and I resolved our issues after a couple emails and just a
little time to chill out.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] extend profiles.desc to include experimental profiles

2008-01-12 Thread Chris Gianelloni
On Sat, 2008-01-12 at 00:40 -0500, Mike Frysinger wrote:
 On Friday 11 January 2008, Chris Gianelloni wrote:
  For one, a way to mark a profile as deprecated in profiles.desc so
  repoman doesn't scan it (currently, we remove tend to remove them from
  the list).
 
 is this really needed ?  i'm trying to see why this would be useful, and not 
 coming up with much ... profiles.desc exists for two reasons:
  - for qa tools to scan
  - so people have a list of valid profiles
 if a profile is deprecated and on the way out, neither of these two things 
 apply to it, so what's the use of having it listed ?  we can already mark 
 profiles deprecated for users who already have it selected ...

I guess I was thinking more for the package manager.  As I said, I would
love for it to enforce a valid profile as defined in profiles.desc, even
if it is a deprecated one, until the user switches.  This means the
deprecated profile needs to be listed in profiles.desc, but we don't
want to run QA on it, as you said.

  The second would be a change to repoman that's more 
  invasive in that it changes current behavior a good bit, but having
  repoman only scan stable profiles, by default, with options to scan
  the other types.
 
 i think by moving our most annoying profiles out of the dev to the exp state 
 would mean that any warnings left while in the dev state are something we 
 want to be seeing and addressing.  the problem right now is that we have two 
 types of profiles listed in dev: ones that people should care about and 
 shouldnt be breaking and ones that people shouldnt care about and are free to 
 break.  package maintainers obviously dont (and shouldnt) know which are 
 which.

Indeed.  I can see that with the profiles reassigned there's no need for
this.

  I've always wanted to have *every* valid profile 
  listed in profiles.desc so we can do things like have portage not allow
  someone to use a profile that isn't listed in profiles.desc (of course,
  overlay users crazy enough could do their own profiles.desc and it would
  be stacked with the in-tree one).  The main problem with doing this has
  been the effect on repoman, since it scans every listed profile every
  time.  I know that most of the profile selection tools out there already
  only show profiles that are listed in profiles.desc, so it wouldn't
  really be a change for them, but I think it would be useful elsewhere,
  too.  All in all, having profiles.desc actually showing the status of
  all of the profiles would be great.
 
 i could see it tied to FEATURES=strict.  if you have this enabled, then 
 you're 
 only allowed to use declared profiles (which means if you use a non-standard 
 one, you'd need to declare it).

Sure.  I see no reason to not allow someone to turn it off.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Re: GMN (was: Re: Projects and subproject status)

2008-01-11 Thread Chris Gianelloni
On Fri, 2008-01-11 at 11:30 +0530, Anant Narayanan wrote:
 Thanks Chris. I just went through the Gentoo Weekly News guide (which  
 is a little outdated, but still quite helpful). Are there any other  
 scripts other than glsa2gwn.py and bugs2gwn.py that need to be run?  

Yeah, there's other scripts.  If you check gentoo/src/gwn, you'll find
them all.  Basically, you need get_glsas.py (which needs glsa2gwn.py)
which you run against the last GWN and it gives you all GLSA since.  Of
course, you'll have to modify the first one manually, since it'll give
you everything since October 15th.  Speaking of which, it might be a
good idea for us to put out at least one stats-only GWN with all of
the stats since October 15th until the newest edition (whenever that may
be).  Taking Robin's output for the adds/removes, you feed the file to
gwn_adds_removes.py which does all the good stuff like formatting and
pulling dev names automatically.  The gwn_bugzilla_report_en.py pulls
the bugzilla stats.  If you run it on its own, it'll give you the stats
for the last week, starting from the previous day.  It also accepts a
date range so you can specify the dates.  If we switch to a monthly
newsletter, it would probably be best to change it to simply pull all
the stats for a given month (like December).

Ryan's last rites stuff was always properly formatted, so a simple
paste is all you need there.  It would be nice to get Robin's
adds/removes to be processed automatically through gwn_adds_removes.py
and sent to gwn-feedback already formatted.

That covers the stats.  Aside from that, there is the gwn_to_text.sh and
gwn2txt.xsl, which does the XML - text conversion for emailing.
Something that I always wanted was something in the XSL which would
allow us to mark a GWN as published and disallow further changes.
Basically, you would do something like put in a published tag (or
whatever) and a few things would happen:

#1 - That GWN would no longer be editable.  This is actually a good
thing, as changes after publishing has been something that's bitten us a
few times, especially given the nature of the emailed editions of the
GWN.  Rather than change the GWN after it is published, I planned on
doing a Corrections type section where we would list any mistakes
(worth mentioning, not typos and such) in the previous GWN.

#2 - That GWN gets automatically converted to plain text via a
post-commit hook and automatically emailed to the GWN list.

#3 - That GWN is published to the front page.  How this would be done is
still something up in the air.  Perhaps adding a summary tag which
would allow you to set the summary, which would show up on the front
page, in the GWN itself, even if it is never displayed directly in the
GWN edition.

The idea is to take all of the steps which could be easily automated and
do so, saving the GWN editor a lot of time doing manual/menial copy and
pasting.

 I'll try and co-ordinate with infra to get them running automatically  
 on a monthly basis. Is there anything else I need to know?
 
 A few points:
 
 1) I'm going to create a sub-project called 'GMN' under the PR  
 project, which will supersede the GWN project.

That sounds like a good idea.

 2) I'm planning to get the first issue out by 21st of this month, and  
 subsequently on the third monday of every month.

Are you planning on having the 21st edition show stats for December,
or... ?

 3) Can we have email aliases [EMAIL PROTECTED] and [EMAIL PROTECTED]  
 for purposes of this project? (It sounds silly to ask for feedback on  
 the GMN at [EMAIL PROTECTED])

Sounds good to me.  What is the purpose of 2 aliases, though?  We found
that people had enough problems with only one email to send to, so I'm
just curious what your thinking is here.

 4) Can we 'move' the gentoo-gwn mailing list to gentoo-gmn?

Definitely.

 @Christian, William and Ryan:
 Please do resume sending your articles as soon as I get the gmn email  
 alias setup. I'll get in touch with you shortly after the necessary  
 arrangements have been made.

Let me know once the alias is up and I'll forward along all of the stuff
people have submitted since October.  Whether you use it all (or none of
it) at least you'll have it.

 Any suggestions/tips/comments on the new venture, are of course, more  
 than welcome.

Feel free to ask me any questions that you have along the way.  I tried
to make publishing the GWN easier, but I still didn't get nearly as much
accomplished as I had wished.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] extend profiles.desc to include experimental profiles

2008-01-11 Thread Chris Gianelloni
On Fri, 2008-01-11 at 09:59 -0500, Doug Klima wrote:
 Mike Frysinger wrote:
  after dealing with m68k, mips, and the *-fbsd ports, i think we could do 
  with 
  a new state for profiles.desc.  the new field would simply be exp to 
  indicate that the profile is experimental and that qa tools should 
  generally 
  not issue warnings about them.  so in repoman's default mode, you wouldnt 
  get 
  any warnings, but if you were to run it in full mode, you'd see stuff like 
  normal.  this is useful for new projects which are still in the process of 
  merging (like *-fbsd, m68k, and any new hardware i get my hands on) and are 
  not really ready for dev marking.  there are plenty of warnings in 
  packages 
  right now due to these profiles being labeled as dev that are the sole 
  problem of the keyword maintainer in question and not the package 
  maintainer.
  -mike

 I've very much been a proponent of properly listing out all of our 
 profiles in profiles.desc. This sounds very reasonable and logical. And 
 hopefully if the tools in question are coded properly, it should be 
 compatible with older versions until users upgrade.

To go along with this, I've always wanted a few other minor changes.

For one, a way to mark a profile as deprecated in profiles.desc so
repoman doesn't scan it (currently, we remove tend to remove them from
the list).  The second would be a change to repoman that's more
invasive in that it changes current behavior a good bit, but having
repoman only scan stable profiles, by default, with options to scan
the other types.  I've always wanted to have *every* valid profile
listed in profiles.desc so we can do things like have portage not allow
someone to use a profile that isn't listed in profiles.desc (of course,
overlay users crazy enough could do their own profiles.desc and it would
be stacked with the in-tree one).  The main problem with doing this has
been the effect on repoman, since it scans every listed profile every
time.  I know that most of the profile selection tools out there already
only show profiles that are listed in profiles.desc, so it wouldn't
really be a change for them, but I think it would be useful elsewhere,
too.  All in all, having profiles.desc actually showing the status of
all of the profiles would be great.

 Good stuff Mike.

Indeed.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


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

2008-01-10 Thread Chris Gianelloni
On Thu, 2008-01-10 at 07:08 +, Ciaran McCreesh wrote:
 On Wed, 09 Jan 2008 12:33:40 -0800
 Chris Gianelloni [EMAIL PROTECTED] wrote:
  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*
 
 Ah yes, you're entirely right. We should all listen to you instead,
 because of the brilliant job you're doing on your pet projects, 2007.1
 and the GWN.

I'm afraid that once again, you simply don't have a clue what you're
talking about.  I've not been doing the GWN for a few months now, nor
was it *ever* a pet project of mine.  Keep it coming.  You're
entertaining the *hell* out of me.  *grin*

 In the mean time, I'll just say that if you don't drop the personal
 attacks and apologise, I'll have no choice but to take it up with
 devrel. You're supposed to be arguing technically here, but all you do
 is go around name calling.

Feel free to bring up an issue with Developer Relations.  They'll likely
throw it out because YOU ARE NOT A DEVELOPER.  Also, you'll notice that
rather than call you names, which is really your forte, I have instead
pointed out why I think your opinion is completely worthless to Gentoo.
If you feel insulted by people pointing out things like you being fired
from the project due to your attitude, perhaps you shouldn't have gone
and gotten yourself fired?  I mean, you made your bed, now lie in it.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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


Re: [gentoo-dev] Projects and subproject status

2008-01-10 Thread Chris Gianelloni
On Thu, 2008-01-10 at 23:35 +0530, Anant Narayanan wrote:
 If nobody has a problem with making the GWN a GMN (Monthly  
 newsletter), then I am willing to volunteer to get this project back  
 on track. Even if few people actually submit anything, I think there  
 is enough activity going on this list, the planet and -commits to fill  
 up a newsletter every month. And I'm willing to invest 12, even 15,  
 hours a month to get this thing rolling again.

That's great!  I am afraid that it'll likely take you much longer than
you anticipate, as it took me that long every *week* when I was doing
it.

Some of the scripts would need to be updated to work on a monthly-basis
rather than weekly.  Also, I still think that it would be good to
automate the scripts that run by putting them on infra somewhere and
having just the output mailed to gwn-feedback as it'll save a little bit
of time for the person doing the GWN and also it'll make sure you don't
forget to run it.

-- 
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 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 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 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] 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] 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] [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] 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] [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] 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] Re: Monthly Gentoo Council Reminder for January

2008-01-08 Thread Chris Gianelloni
On Sat, 2008-01-05 at 04:32 +, Ciaran McCreesh wrote:
 On Fri, 04 Jan 2008 20:20:18 -0800
 Chris Gianelloni [EMAIL PROTECTED] wrote:
  No offense to anyone, but holding back hundreds of developers and
  thousands of users for a handful of developers
 
 ...and how exactly are hundreds of developers and thousands of users
 being held back? So far as I can see, in cases where anyone really is
 being held back, the arch teams are quite happy to prioritise -- the
 people who go around moaning about 'slacker archs' rarely if ever
 actually have anything holding them back.
 
 If anyone has any examples of where they really are being held back and
 where they really have given the arch teams plenty of time to do
 something, I'd like to see them... Somehow I doubt it happens very
 often, if at all.

It happened several times during the 2007.1 release cycle.  Of course, I
don't feel like wasting my time searching bugs to justify myself to you,
so if you're interested, feel free to search on your own.  Pretending it
doesn't happen doesn't make it go away.

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


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


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

2008-01-08 Thread Chris Gianelloni
On Sun, 2008-01-06 at 23:34 +, Ciaran McCreesh wrote:
 Ok, so explain:
 
 * How perpetually open bugs are a maintenance burden. They don't
 generate emails and they don't require any work on the maintainer's
 part. Is the mere fact that they show up in queries all you're
 concerned about, and if so, have you considered either adapting your
 queries or requesting a special keyword to make such bugs easier to
 filter?

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 and I've had an open bug for mips
to test the newer version for 2 years.  I've asked several mips team
developers, who all give me the same we don't have enough
manpower/horsepower to test that right now excuse.

 * How unmaintained ebuilds are a maintenance burden. Doesn't that
 contradict itself?

When repoman keeps me from being able to commit due to an ebuild that
remains in the tree only for an architecture hardly anyone uses or cares
about, that affects me.

Now, I know that you're just being your usual self-absorbed
argumentative self and I likely shouldn't feed you, but I thought that
answering this might clear it up for the people who don't understand
this as well as you do.

This is especially true since you've been pretty much the main proponent
for keeping things as they are with these slack arches.  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.

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


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


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

2008-01-08 Thread Chris Gianelloni
On Sun, 2008-01-06 at 23:35 +, Ciaran McCreesh wrote:
 On Sun, 06 Jan 2008 14:09:24 +0100
 Matthias Langer [EMAIL PROTECTED] wrote:
  This kind of conversation is not technical at all... Ciaranm, are you
  a MIPS user? If so, do you think that running KEYWORDS=mips is less
  likely to result in breakage than running KEYWORDS=~mips?
 
 I think you'd need a much larger sample than one to get any meaningful
 answer there (and it might be worth doing it across all other archs
 too, to find out whether mips is in any way anomalous).

Are there even enough users to get a larger sample?  Other than the like
3 devs still working on mips, I thought you were the only actual user.
I mean, I've watched things in system get broken on mips and nobody
even notices for several weeks.  There simply can't be that many people
who actually care if nobody even notices when *system* breaks.

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


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


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

2008-01-08 Thread Chris Gianelloni
On Sun, 2008-01-06 at 11:36 -0600, Ryan Hill wrote:
 that has both sides happy here, but that won't happen if you don't admit 
 there's a problem.

He doesn't have to admit anything.  He is neither an ebuild maintainer
nor an arch team developer.  Basically, his opinion is useless in this
case, as *his* work flow is not affected.  As such, I think we can
simply just ignore him.

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


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


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

2008-01-08 Thread Chris Gianelloni
On Tue, 2008-01-08 at 00:30 -0800, Donnie Berkholz wrote:
 On 00:42 Tue 08 Jan , Diego 'Flameeyes' Pettenò 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.
 
 What is your goal? Is there something you're trying to accomplish that's 
 impossible? It's clear that changing this would be a fair amount of 
 work, and I don't understand the benefits.

Come work on a Gentoo release some time.  Implicit dependencies waste
more time than pretty much anything else.  Almost all circular
dependency issues we currently have are due to implicit dependencies.
Also, several things have been added either to system or (more commonly)
packages.build, to try to work around these deficiencies in the tree.

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


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


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

2008-01-08 Thread Chris Gianelloni
On Tue, 2008-01-08 at 19:59 +, Ferris McCormick wrote:
 3)  Most devrel requests seem really to relate to CoC violations.  Would
 you like us to bounce those to the CoC people, process them using CoC
 rules, or keep doing what we are doing now (generally, close them with a
 note explaining why or mediate them)?  (I'm talking about the He's
 being rude/sarcastic/disrespectful sorts of things which really need to
 be processed immediately and merit a warning or brief suspension if
 anything.)

How hard is it to realize that the CoC is a superset of DevRel (and
other) policies?

If someone breaks DevRel policy (be good to each other) that also
happens to be a CoC rule and someone reports it to DevRel, they should
actually *do* something about it, rather than trying to pass it off onto
someone else or spend months engaging in witless banter about whether
there's even an issue or not.  After all, when the CoC was enacted,
never once was it said that it would override DevRel or otherwise make
DevRel invalid.  If someone comes to DevRel with a problem, you're
supposed to try to work out the issue with them.  It really is that
simple.  There's no need for some kind of territorial pissing match or
passing the buck.

Someone came to DevRel for help because they think DevRel can help them
and it is DevRel's job to do so.  The CoC was put in place to allow for
catching bad behaviors *before* they would get to DevRel, without
requiring someone to necessarily report the issue.  Once a developer
has reported an issue to DevRel, it's their job to work it using their
own policies, as it then becomes a DevRel issue.  The two things serve
somewhat different purposes.  The CoC was designed to curb or prevent
bad behavior, where DevRel's job is to prevent bad behavior from
recurring, or taking disciplinary action when necessary for repeat
offenders.

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


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


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

2008-01-08 Thread Chris Gianelloni
On Tue, 2008-01-08 at 21:49 +0200, Petteri Räty wrote:
 Stefan Hellermann kirjoitti:
  I've tried to not use the system-set and set up a virtual called 
  virtual/minimal-system which depends on all the packages I need (no gcc 
  or perl, only coreutils, glibc, baselayout and some packages that are 
  really needed for booting up). This is what I think  should be the 
  system-set. And there would be a development-set which most people would 
  use, but don't have to. And maybe a set with packages like man, texinfo ...
  
 
 Probably would be useful to separate DEPEND and RDEPEND base systems. So 
 things like gcc would only be needed for the DEPEND part.

Be careful with this one.  Lots of things end up linking with libstdc
++.so.* from GCC.

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


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


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

2008-01-08 Thread Chris Gianelloni
On Wed, 2008-01-09 at 02:47 +, Ciaran McCreesh 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.

Actually, nobody ever said anything about things that magically break.
It's more the things like ebuilds with bad code that can't really be
changed without a revision bump, which would also require the arch team
in question to ACTUALLY DO SOMETHING to make stable.

Seriously, your thinly-veiled attempts at deflecting the conversation to
something that supports your pithy points is laughable.

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.  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.

Now, if you have something possibly constructive to add to this
conversation, as a user, feel free, but don't pretend like you're still
a member of the mips team.  You're not.

-- 
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-04 Thread Chris Gianelloni
On Fri, 2008-01-04 at 21:02 +, Ciaran McCreesh wrote:
 X and Y are pretty much irrelevant. The important factor is Z, the
 impact of leaving things the way they are.

...and the idea is to let the Council decide what level of Z is
acceptable.  Currently, it appears as if the issue is maintainers
being forced to keep abhorrently old versions of packages, including
security-vulnerable packages, simply because a security-unsupported
architecture hasn't had time to test/update/whatever.

This has been an issue for quite some time.  Of course, the impact is
debatable, but it seems that we cannot agree ourselves on what is
agreeable, so I see this as a point to bring to the Council simply so it
can be resolved once and for all and things can resume normal
operation.  I know that I, as an ebuild developer, would be much more
comfortable/accepting of having to keep around old versions of packages,
if the Council had deemed it to be something important enough.  No
offence to any alternative architectures or their hard-working team
members, but there are some times when we have to look at the common
good, and forcing maintainers to spend time keeping older ebuilds that
are possibly using older ebuild code and other idiosyncrasies versus the
current versions for the more mainstream architectures simply might not
be worth it for architectures with a very minimal number of users.

I've heard some suggestions for removing stable KEYWORDS on arches that
aren't security supported.  I see this as a possible solution to such
issues, since ~arch packages aren't security-supported in the sense of
GLSA and such, so why not keep arches which aren't security-supported
from having stable KEYWORDS?  Of course, this is a global change which
affects multiple architectures, so it should be deferred to the Council.
I don't really think it requires a large amount of discussion simply
because it is simple to see how it would come to a swift stand-still.
The arch teams affected will want nothing to change, the package
maintainers will want to make things easier on themselves.  This is to
be expected.  We elect the Council for a reason.  Making decisions like
this is one of them.  Let's let them do their job and follow their
leadership.

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


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


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

2008-01-04 Thread Chris Gianelloni
On Fri, 2008-01-04 at 22:37 +, Ciaran McCreesh wrote:
 Really, I'd like to see some genuine examples of cases where people
 think they have a legitimate value of Z...

How about we base X Y and Z on the number of verifiable users of said
arch?  That's just as arbitrary and fits with the normal pink ponies
philosophy of pulling complete bullshit out of the air and using it as a
justification or argument.  Maybe we'll base it on how many months
they've been security-supported?

No offense to anyone, but holding back hundreds of developers and
thousands of users for a handful of developers, who could do their jobs
just as well without stable KEYWORDS, and an nearly as small number of
users, just isn't worth it to us all.  How many users do you really
think breaking some of these arches affects?  If the architecture (or
its team) is incapable of maintaining stable KEYWORDS in a timely
manner, why should we care about them, again?

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


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


Re: [gentoo-dev] Re: [RFC] Some new global USE-flags

2007-12-28 Thread Chris Gianelloni
On Fri, 2007-12-28 at 05:53 +, Steve Long wrote:
 Chris Gianelloni wrote:
 
  branding: Enable Gentoo specific branding
  [questionable, as used for splashes/shortcuts/artwork]
  
  Well, my personal opinion here is that we should enable this by default
  on *at least* the desktop profiles, as providing sensible defaults and
  branding isn't outside the scope of the project.  We still stay as close
  to upstream as possible with this stuff and only use it for branding or
  optional Gentoo-specific minor config changes.  Also, it can still be
  disabled for people who want everything as upstream intended.
  
 I have no objection to it being flagged on by default in desktop profiles,
 but Gentoo-specific minor config changes concerns me, since I take it as
 given that installing for a specific distro implies config changes to work
 with that distro, and not having those because I have turned branding off
 sounds bad for me as a user and seems a confusion of purpose. (It could
 lead to more optional config changes bundled in future which wouldn't be
 apparent without knowledge of the ebuild.)

Well, by this I meant something like bug #170059 which would mean
changing the default home page (minor config change) to something
Gentoo-specific.  Not all config changes are for required functionality.
Sorry, I had assumed that people on this list would be technical and
able to realize this without it being explicitly spelled-out.

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


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


Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]

2007-12-27 Thread Chris Gianelloni
On Thu, 2007-12-27 at 18:11 +, Ciaran McCreesh wrote:
 On Thu, 27 Dec 2007 18:03:27 +
 Roy Marples [EMAIL PROTECTED] wrote:
  On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote:
   Or to put it another way, you're objecting to painting the house
   pink rather than green because you don't like pink (because your
   last house was green too), ignoring that it's been demonstrated
   that when painted green, it's impossible to add a conservatory and
   central heating because the green paint will catch fire and kill
   everyone.
  
  Using your analogy you should then recognise that there is a strong
  dislike for pink and should seek a new colour that allows the building
  of said extensions.
 
 And what colour would that be? We've already ruled out purple, brown
 and yellow, and no-one has yet found any other colour of paint.

Any chance we can back on, you know, the actual topic, rather than these
useless analogies?

Thanks,

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


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


Re: [gentoo-dev] [RFC] Some new global USE-flags

2007-12-26 Thread Chris Gianelloni
On Thu, 2007-12-20 at 19:57 +0100, Markus Meier wrote:
 novideo   5

These should probably really go away and use package.use and such to use
the already-existing videos USE flag.

 branding: Enable Gentoo specific branding
 [questionable, as used for splashes/shortcuts/artwork]

Well, my personal opinion here is that we should enable this by default
on *at least* the desktop profiles, as providing sensible defaults and
branding isn't outside the scope of the project.  We still stay as close
to upstream as possible with this stuff and only use it for branding or
optional Gentoo-specific minor config changes.  Also, it can still be
disabled for people who want everything as upstream intended.

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


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


Re: [gentoo-dev] Patch make_desktop_entry to produce entries that validate better

2007-11-20 Thread Chris Gianelloni
On Sun, 2007-11-18 at 02:59 +0100, Daniel Pielmeier wrote:
 I have attached an updated patch.

Thanks, Daniel.  The patch has been applied.

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


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


Reminder: Set your Reply-To (was Re: [gentoo-dev] packages.gentoo.org lives!)

2007-11-15 Thread Chris Gianelloni
On Wed, 2007-11-14 at 13:22 -0700, Joe Peterson wrote:
 (Sorry for the previous reply to announce..)

Let me take this opportunity to remind people to set a reply-to when
sending anything to gentoo-dev-announce so people replying will reply to
the proper place.

Thanks,

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


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


Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

2007-11-13 Thread Chris Gianelloni
On Sun, 2007-11-11 at 21:01 +0200, Petteri Räty wrote:
 I plan to make the java eclasses use the EAPI 1

Any chance we can *at least* wait until we have a release out the door
that has a portage version which supports these features *before* we
start trying to use them in the tree?  Our general rule was to not use
features for 1+ years since it was added to a *stable* portage before we
started using them.  Now, this isn't so much of an issue with individual
ebuilds, but you're talking about changing how the Java eclasses work,
essentially blocking *anyone* using an older portage (including everyone
installing from 2007.0 media) from using any package which inherits the
eclass.

Also, we should really think about this sort of thing before we start
using it.  How are we going to support EAPI changes in eclasses?  What
if I have an eclass with EAPI=1 features and I want to add some EAPI=2
features?  I think allowing EAPI=* globally in an eclass should be
prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds,
only.  In other words, you'd need new EAPI=1 eclasses for your EAPI=1
ebuilds.  Either that, or some way to say something like: execute code
path A for EAPI=0 and execute code path B for EAPI=1 or something
similar.  I would suspect that the best current solution is to check
EAPI in the individual functions and perform the right actions based on
those functions, rather than marking an entire eclass.  After all, only
EAPI=* functions need to be hidden behind EAPI.

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


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


Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

2007-11-13 Thread Chris Gianelloni
On Tue, 2007-11-13 at 20:31 +, Ciaran McCreesh wrote:
 That was only the case because previously, using new features that
 Portage didn't support would cause horrible breakage. Now, instead, the
 ebuilds show up as being masked.

...which is just as good as broken when it happens to a new user first
installing Gentoo and wondering why he can't even follow the directions
in the Handbook.

What brought me to bring this up was the mention of changing of eclasses
which support a large number of ebuilds, effectively masking a
significant portion of the tree from our users.  Let's say that I added
EAPI=1 to eutils.eclass because I wanted to use some new EAPI=1 feature
in one of the functions.  Guess what?  I've now managed to mask
*portage* for users of older portage versions.  In fact, I've managed to
mask paludis and pkgcore, too.  Yes, this is an extreme example.  Yes,
it is completely possible.  Yes, that user would be completely screwed.

  Now, this isn't so much of an issue with individual ebuilds, but
  you're talking about changing how the Java eclasses work, essentially
  blocking *anyone* using an older portage (including everyone
  installing from 2007.0 media) from using any package which inherits
  the eclass.
 
 They just need to upgrade their package manager first. Easy.

Expecting users to do pretty much anything on their own is broken
behavior and should not be relied on for package manager compatibility.

  Also, we should really think about this sort of thing before we start
  using it.  How are we going to support EAPI changes in eclasses?  What
  if I have an eclass with EAPI=1 features and I want to add some EAPI=2
  features?  I think allowing EAPI=* globally in an eclass should be
  prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds,
  only.
 
 Doing an entire eclass for one specific EAPI generally isn't a good idea
 since it's fairly likely that EAPI bumps will be a fairly common thing.
 
  In other words, you'd need new EAPI=1 eclasses for your EAPI=1
  ebuilds.  Either that, or some way to say something like: execute
  code path A for EAPI=0 and execute code path B for EAPI=1 or
  something similar.  I would suspect that the best current solution
  is to check EAPI in the individual functions and perform the right
  actions based on those functions, rather than marking an entire
  eclass.  After all, only EAPI=* functions need to be hidden behind
  EAPI.
 
 A solution with EAPI-agnostic code in foo-common.eclass and
 EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more
 readable and maintainable in most cases.

Umm... So in the paragraph above, you say an EAPI-specific eclass isn't
a good idea, and here you push it as the proposed solution.  Huh?
Consistency, please...

I guess my real point is that we need to be *really* careful when using
this stuff.  It is *not* as simple as you make it out to sound.  All it
takes is one person adding an EAPI into an eclass somewhere to
completely screw over a *huge* number of our users.  I am just trying to
point this out and hopefully get discussion going on how to utilize
these great new features without potentially causing damage to our
user's machines and our reputation.

I still think that EAPI should not be allowed to be set in an eclass
globally.  All I can see is it causing problems for tons of users who
don't have a clue what is happening to their systems.

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


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


Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

2007-11-13 Thread Chris Gianelloni
On Wed, 2007-11-14 at 00:39 +, Ciaran McCreesh wrote:
  Umm... So in the paragraph above, you say an EAPI-specific eclass
  isn't a good idea, and here you push it as the proposed solution.
  Huh? Consistency, please...
 
 Read it (and my explanation of it earlier in the thread) until you
 understand it. There is nothing consistent in what I'm saying.

You are *so* correct.  There really is nothing consistent in your
replies.  Rather, you've decided to pick and choose how you respond to
maximize insult.  It's *so* much easier to simply avoid any potential
issues than to actually discuss them.  As such, I've decided to quit
responding to this thread until someone who wishes to actually
participate in a discussion, rather than trying to win it comes along.

Thank you for your input and have a nice day.

  I still think that EAPI should not be allowed to be set in an eclass
  globally.  All I can see is it causing problems for tons of users who
  don't have a clue what is happening to their systems.
 
 EAPI *can't* be set in an eclass correctly anyway because EAPI is
 allowed to (and likely will in the future) change the behaviour of
 inherit.

...and this proves my point.  Rather than simply stating this, you
decided to post $diety knows how many lines of completely worthless
information again and again.  Had you simply said *exactly this* at the
beginning, the thread/discussion would have been over.  This is exactly
what people mean when they say that they feel that you are not
participating in discussions fairly.  It's like you specifically hold
back information that you know and bait people into saying things simply
so you call put out the ace from your sleeve and point out how someone
else is wrong.

Yay!  You win.

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


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


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild

2007-11-10 Thread Chris Gianelloni
On Sat, 2007-11-10 at 16:14 +, Ciaran McCreesh wrote:
 On Sat, 10 Nov 2007 14:58:42 +0100
 Daniel Pielmeier [EMAIL PROTECTED] wrote:
  Lucky you are that your native language is one of the world's most
  widely spoken languages. Imagine to express yourself in a language you
  are not familiar with!
 
 And when not speaking in my native language, I made damned sure I'm not
 just misunderstanding something before going around making all sorts of
 unfounded accusations in public.

Please try to be the better man here and discontinue this current line
of thinking.  I ask you, instead, to look at Denis' email as a friendly
reminder to keep things on a more civil level.  As a native English
speaker, I didn't see anything wrong with your comments, as they were
directed towards code, not a person.  Were the same comments made
towards a person, yes, it would be offensive.  Since not all of us are
native speakers, sometimes just the simple replacement of a word can
help change the tone to those of us not born in an English speaking
country.

I've noticed your civility of late and want to encourage you to
continue.  I would like to apologize if you feel ass if you've been
baited or anything.  I know Denis and know that wasn't really his
intention, but rather to remind you (and others) to try to think about
the word choices we make.  Had you said odd instead of perverse, we
wouldn't likely be having this conversation, though you and I know the
functional meaning of the two words in that context are nearly
identical.  This is mostly the case with words with multiple meanings,
where non-native speakers might not know all of the alternate meanings
and can misinterpret your words.  I know it has happened to me quite a
few times.

Thanks,

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


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


Re: [gentoo-dev] Kolab2/Gentoo project

2007-10-14 Thread Chris Gianelloni
On Sun, 2007-10-14 at 00:05 +0200, Wulf C. Krueger wrote:
 On Saturday, 13. October 2007 19:27:05 Chris Gianelloni wrote:
  On Thu, 2007-10-11 at 13:11 +0200, Gunnar Wrobel wrote:
   The project has advanced far enough though that I feel it is a good
   time point to declare this a real Gentoo project.
   http://www.gentoo.org/proj/en/kolab/index.xml
  Umm... why?  Why does a package need a project?  Is this not just a
  mail server?
 
 It's a full-blown collaboration/groupware server and it will likely need a 
 fair bit of coordination between different herds and maintainers as it 
 uses several major F/OSS components which (at least until recently) need 
 patches and integration changes to be usable with Kolab.
 
 http://kolab.org/about-kolab-server.html
 
  I don't mean any offense.  I just want to know.  Why do we need to
  create a project, which should normally be reserved for wide-sweeping
  changes or things that require massive amounts of coordination?
 
 Indeed. Having tried to use Kolab on Gentoo before, I assume it will be 
 the latter that makes a Kolab project reasonable.

Cool.  In the future (this is to everyone), can we say this kind of
information in the announcement message so we don't end up having to ask
such questions?

Thanks,

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


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


Re: [gentoo-dev] Re: lame use flag, local to global

2007-10-13 Thread Chris Gianelloni
On Sat, 2007-10-13 at 10:37 +, Duncan wrote:
 Chris Gianelloni [EMAIL PROTECTED] posted
 [EMAIL PROTECTED], excerpted below, on  Fri,
 12 Oct 2007 17:22:54 -0700:
 
  Steve Long wrote:
  Duncan wrote:
   Steve Dibb posted:
   
   there is more than one mp3 encoder.
   
   [S]houldn't the description mention that?
  
  How about:
  
  Prefer using LAME for MP3 encoding support
  
  It doesn't mention anything else, so it'll work in all cases.
 
 WORKSFORME =8^)

InCVS... :P

I've gone ahead and changed this.  It isn't a harmful change, so I just
went ahead and did it.  Enjoy your newly modified description.

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


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


Re: [gentoo-dev] Kolab2/Gentoo project

2007-10-13 Thread Chris Gianelloni
On Thu, 2007-10-11 at 13:11 +0200, Gunnar Wrobel wrote:
 The project has advanced far enough though that I feel it is a good
 time point to declare this a real Gentoo project.
 
 http://www.gentoo.org/proj/en/kolab/index.xml

Umm... why?  Why does a package need a project?  Is this not just a mail
server?

I don't mean any offense.  I just want to know.  Why do we need to
create a project, which should normally be reserved for wide-sweeping
changes or things that require massive amounts of coordination?  Why is
this not just a part of the net-mail herd?  It *is* a mail system, is it
not?

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


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


Re: [gentoo-dev] Re: lame use flag, local to global

2007-10-12 Thread Chris Gianelloni
On Fri, 2007-10-12 at 07:26 +0100, Steve Long wrote:
 Duncan wrote:
 
  Steve Dibb [EMAIL PROTECTED] posted [EMAIL PROTECTED],
  excerpted below, on  Wed, 10 Oct 2007 07:55:01 -0600:
  
  The reason we have mp3 and lame use flag is because there is more than
  one mp3 encoder.  In almost every case of the use flag being applied
  above, there is already support for another mp3 codec (ffmpeg).  So,
  lame adds support for lame, not for mp3, which is also provided.
  
  In that case, shouldn't the description mention that?  Something like:
  
  MP3 encoding support using LAME (as opposed to ffmpeg)
  
 What about when the next one gets added-- would it need to say as opposed
 to ffmpeg or lame?
 
 I agree where there's a choice, the ebuild should offer lame or ffmpeg or
 w/e, and where not simply mp3 (along with the encode/decode being
 orthogonal.)

How about:

Prefer using LAME for MP3 encoding support

It doesn't mention anything else, so it'll work in all cases.

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


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


Re: [gentoo-dev] lame use flag, local to global

2007-10-10 Thread Chris Gianelloni
On Wed, 2007-10-10 at 07:55 -0600, Steve Dibb wrote:
 Mart Raudsepp wrote:
  On T, 2007-10-09 at 21:03 -0600, Steve Dibb wrote:
  The little lame use flag has started showing up more in local use flags, 
  and all for the same purpose, MP3 support using LAME libraries.  I vote 
  we move it into a global use flag.  Any objections, let me know.
 
  $ quse -D lame
local:lame:media-libs/libquicktime: Support LAME mp3 encoding
local:lame:media-libs/mlt: Support LAME mp3 encoding
local:lame:media-sound/abcde: Support LAME mp3 encoding
local:lame:media-sound/gnusound: Enable lame support
local:lame:media-video/mpeg4ip: Support LAME mp3 encoding in the 
  server/mp4live
  
  Any reason to not use something like mp3enc flag instead at that point?
  mp3 USE flag is already global, and appears to mean mp3 decoding, so how
  about a general mp3 encoding USE flag? I guess merging decoding and
  encoding behind the same USE flag might be an option too.
  
 
 Ah, I knew this question was gonna come up, should have addresed it 
 first time around.
 
 The reason we have mp3 and lame use flag is because there is more than 
 one mp3 encoder.  In almost every case of the use flag being applied 
 above, there is already support for another mp3 codec (ffmpeg).  So, 
 lame adds support for lame, not for mp3, which is also provided.
 
 When there is just one mp3 codec used in an ebuild, then it makes sense 
 to use just the mp3 use flag.

Actually, the encode USE flag makes more sense, if encoding support is
optional.

Basically, it should be like so:

A is a mp3 program/library, which can do both encoding and decoding.  It
doesn't use USE=mp3, at all, since it is solely an mp3 program.
Encoding support is enabled via USE=encode.

B is a media program/library, which can do both encoding and decoding
for multiple formats.  It would use USE=mp3 to enable mp3 support.  It
would use USE=encode (with mp3 support enabled) to enable mp3 encoding
support.

C is an encoder for multiple formats.  It uses USE=mp3 for enabling mp3
encoding.

D is an encoder for mp3.  It uses no USE flags, since it is always a mp3
encoder.

I'm sure I missed other cases, but you get the point.

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


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


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/ncdu: ChangeLog ncdu-1.3.ebuild

2007-10-07 Thread Chris Gianelloni
On Sun, 2007-10-07 at 07:57 -0700, Alec Warner wrote:
 What about those of us suffering with Outlook!??!

Umm... woodpecker has procmail on it.  Every developer has access to
procmail.  Also, nobody forces you to use Outlook.

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


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


Re: [gentoo-dev] new-style virtual/editor

2007-10-05 Thread Chris Gianelloni
On Fri, 2007-10-05 at 14:57 -0400, Olivier Crête wrote:
 On Fri, 2007-05-10 at 11:46 -0700, Donnie Berkholz wrote:
  How many packages depend on virtual/editor? Should it be a virtual at 
  all?
 
 Tester_ !rdep virtual/editor
 jeeves virtual/editor - app-admin/sudo sys-process/fcron
 
 I think the answer is none that really should, I would favor just
 removing virtual/editor.

Ehh... system also requires it.  Removing the virtual means everybody,
no matter what, will get nano and won't be able to remove it without
portage bitching up a storm.  Currently, you can replace nano with any
editor that meets the virtual and it'll satisfy the system target.

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


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


Re: [gentoo-dev] Re: controlling src_test

2007-10-04 Thread Chris Gianelloni
On Thu, 2007-10-04 at 13:47 -0600, Ryan Hill wrote:
  I usually disable tests on a per-package basis using /etc/portage/env
  entries.
  
  [EMAIL PROTECTED] ~ $ cat /etc/portage/env/sci-libs/fftw
  NEWFEATURES=
  
  for f in ${FEATURES}; do
  if [[ ! $f == test ]]; then
  NEWFEATURES=${NEWFEATURES} $f
  fi
  done
  
  FEATURES=${NEWFEATURES}
 
 here's a crappy little script to automate it.

See, I think this sort of thing is what we should be adding into
gentoolkit.  It is something that is very useful, but not required for
running a Gentoo system.

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


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


  1   2   3   4   5   6   7   8   9   10   >