Re: [gentoo-dev] Network configuration and bash

2007-02-06 Thread Olivier Crete
On Tue, 2007-06-02 at 20:34 +, Roy Marples wrote:
  Keeping it as is has the advantage that an
  upgrade/downgrade cycle wouldn't change much in functionality based on
  config, which is pretty good (ie, backwards compatibility).  In this
  case, I'm not sure legacy is all that bad, simply because it's
  expressive and concise and easily understood :)
 
 So you're saying we patch other shells to support bash arrays?

What so wrong with bash? Apart from the fact that its not included in
the unmodified base system of FreeBSD? Last I checked, we add lots of
Gentooish stuff already. And that its not friendly to tiny embedded
systems, which dont use a complex and powerful init system like Gentoo's
(but prefer very simple ash scripts).

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Network configuration and bash

2007-02-06 Thread Olivier Crete
On Tue, 2007-06-02 at 21:11 +, Roy Marples wrote:
 On Tue, 06 Feb 2007 16:03:50 -0500
 Olivier Crete [EMAIL PROTECTED] wrote:
  What so wrong with bash?
 
 Unsuited to an init system that wants to work everywhere, like embedded
 systems.
 
 Also, being tied to one shell causes problems when that shell breaks.
 Witness baselayout problems regarding bash-3.0, 3.1 and 3.2
 
 Lastly, in my first email I said 
 Now, this email isn't about the merits of bash, nor the fact that it's
 in base system profile so we can use it anyway, blah blah blah.
 embedded has a vested interest in not using bash and I have a personal
 interest as Gentoo/FreeBSD on Sparc64 takes a very long time to boot.
 
 I'm assuming you did't read that bit :)

Actually I did, but I really dont see what kind of embedded system would
be complex enough to require the Gentoo init system, yet not enough to
use bash.

And I don't see why g/fbsd sparc64 is problematic? Or is it just that
you have a 1995 vintage system and you want to run Gentoo on it?

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] the *box ebuilds and x11

2007-02-05 Thread Olivier Crete
On Tue, 2007-06-02 at 00:54 +0200, Mohammed Hagag wrote:
 Hi all, Today i discovered that *box ebuilds doesn't depend on x11 is
 this a common ? or should i submit a bug ?
 
 i'm tried to emerge blackbox fluxbox openbox and all of them didn't
 depend on x11.

They do not need an X server to run, only the appropriate X libraries
(the X server could be remote).

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Topic for Feb council meeting

2007-01-29 Thread Olivier Crete
On Mon, 2007-29-01 at 14:01 -0600, Grant Goodyear wrote:
 Ned Ludd wrote: [Mon Jan 29 2007, 09:50:28AM CST]
   Then it should be offered to the 8th person, at which point either
   he/she will then refuse the nomination and it's offered to the 9th.
   Rinse and repeat.
   If we run out of nominees then we'll need another election.
   
  
  Agreed. #3
  
  From my POV having a new election potentially over and over is a waste
  of time and resources.
 
 My only qualm with this approach is whether or not we then risk
 promoting a candidate who was resoundingly defeated during the actual
 election to a Council position because only a handful of people ran for
 the position.

Don't we have a re-open nominations item in our electoral process? If
so, we can decide to consider only candidates who are above that
threshold.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Only you can prevent broken portage trees

2006-10-31 Thread Olivier Crete
On Tue, 2006-31-10 at 17:02 +0100, Stuart Herbert wrote:
 This leaves package maintainers in the situation that there are
 'old'/'insecure'/insert preferred adjective here versions of
 packages that are hanging around only because arches have fallen
 behind.  Package maintainers want to be able to remove these old
 versions, but currently cannot because of keywording-lag.
 [...]
 3) ??

What about, package maintainers remove all of the other keywords from
said broken version and add a nasty ewarning message to the pkg_postinst
like this version has a known security problem, dont use it, bitch to
your arch team if you're not happy...

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Ignoring/overwriting IUSE from an eclass

2006-10-30 Thread Olivier Crete
On Mon, 2006-30-10 at 08:26 -0800, Donnie Berkholz wrote:
 Alternate subject: On the sudden appearance of USE=X for tons of stuff
 
 I really want to use font.eclass in x-modular.eclass to get rid of a lot
 of code duplication and more possible bugs. Problem is, it brings in
 IUSE=X for every single X package. I cannot figure out how to prevent
 this. Setting IUSE= after the inherit in x-modular.eclass is not enough.
 
 Anyone got any ideas? The only one I have is to add significant missing
 functionality to font.eclass and switch every font package over that
 instead of x-modular.eclass.

Isnt it possible to define something like I_AM_X=1 in x-modular.eclass
and in fonts.eclass have a if [[ -z ${I_AM_X} ]]; then IUSE=X;
DEPEND=current depends; else DEPEND=as if X use flag was forced; fi
and replace the use X with a use X || [[ -z ${I_AM_X} ]]

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] The Dreaded herd tag

2006-10-30 Thread Olivier Crete
On Mon, 2006-30-10 at 17:40 +0100, George Shapovalov wrote:
 понеділок, 30. жовтень 2006 17:16, Chris Gianelloni Ви написали:
  allow valid devs, and maintainer-needed in maintainer.  
 Should we also disallow adding new no-herd/maintainer-needed ebuilds?
 (As the apparent use of maintainer-needed is to track the ebuilds already in 
 the tree that need some love).

Isn't adding an ebuild without setting oneself or one's herd as the
maintainer already forbidden?

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] implicit vs explicit dependencies

2006-10-23 Thread Olivier Crete
On Mon, 2006-23-10 at 22:34 +0300, Alin Nastac wrote:
 Up till now, I relied on implicit dependencies (dependencies of my
 dependencies).
 Apparently now (see https://bugs.gentoo.org/show_bug.cgi?id=152534) we
 should add every atom that an ebuild depends on to (R)DEPEND.

In the pkg-config case, I was wondering if every ebuild that installs
a .pc file should also have pkg-config in its RDEPEND.. Or should we
push pkg-config into the DEPEND of every package using it. Or both...


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Orphaned packages

2006-09-18 Thread Olivier Crete
On Mon, 2006-18-09 at 20:00 +0100, Gustavo Felisberto wrote:
 Due to my work for the next two semesters being increased I'm going to have to
 drop my maintainer status for some of the packages I handle. I'll still keep a
 small number of packages that I really don't want to let go.
 Also, due to the fact that I'll no longer be running ~amd64 but am going the
 stable way it is possible I'll give a greater help there.
 
 The list of orphans is:
 
 app-crypt/qca
 app-crypt/qca-tls
 net-ftp/pure-ftpd
 net-ftp/pureadmin
 net-ftp/proftpd
 net-im/jit
 net-im/jud
 net-im/mercury-bin
 net-im/pymsn-t
 net-im/psi
 net-im/aim-transport
 net-im/mu-conference
 net-im/yahoo-transport
 net-im/msn-transport
 net-im/gabber
 net-im/jabberd
 net-im/gg-transport
 net-mail/sendEmail
 net-misc/blogtk
 sci-misc/netlogo-bin
 x11-themes/gkrellm-themes
 x11-themes/zinf-themes
 x11-themes/gdm-themes
 
 
 I'll update the metadata.xml to maintainer-needed during the next days.

I guess you can transfer the net-im packages to the net-im herd.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] cdrtools license issues

2006-09-01 Thread Olivier Crete
On Fri, 2006-01-09 at 16:20 -0400, Mike Frysinger wrote:
 On Friday 01 September 2006 15:18, Chris White wrote:
  On Friday 01 September 2006 11:26, Greg KH wrote:
   No, we should just stop distributing the prebuild image in our release
   and live cds.  We do not have to do anything with the package in
   portage, as it is the user who builds cdrtools that does the violating
   (and only if they then redistribute the built binary).
 
  Well, I for one would rather not give a user the option to screw themselves
  to this magnitude with a simple emerge cdrtools.  There's people that
  aren't reading this list, and aren't going to know what's going on.  It's
  unfair to them.
 
 set the LICENSE variable and/or add an ewarn to the ebuild ... pushing your 
 ideals by removing the package is wrong
 -mike

Maybe we should p.mask the versions that contain and un-redistributable
mix of CDDL and GPL code.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] mulltiib cruft: /emul

2006-08-21 Thread Olivier Crete
On Mon, 2006-21-08 at 13:28 -0400, Mike Frysinger wrote:
 On Monday 21 August 2006 10:29, Olivier Crête wrote:
  On Mon, 2006-21-08 at 12:21 +0100, Herbie Hopkins wrote:
   I've always viewed the emul libs as a temporary measure until we had full
   multilib fuctionality in portage. Afaik the only person working on this
   was eradicator who has been mia for a while now so I'm unsure weather
   this is ever likely to arise. Given that it looks like we'll be stuck
   with these binary libs for some time yet then we may as well do as you
   suggest and install them in a standard location to make building against
   them a bit easier. I'll look into doing this when I next version bump the
   packages.
 
  I still believe we should reserve the regular directory for the real
  multilib stuff, otherwise it will be very painful when we decide to
  move. And continue to put the stopgap binary packages in /emul.
 
 why ?  this is what blockers are for

Will we make emul-x86-gtk-libs block gtk+? We dont have use based
deps/blockers... how long will it take before we have API/arch based
ones. In my humble opinion, keeping that stuff in emul is much better,
in the same way as we would install binary packages in /opt and
not /usr.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Council polls now open

2006-08-10 Thread Olivier Crete
On Thu, 2006-10-08 at 10:57 -0500, Grant Goodyear wrote:
 Well, we don't yet have reliable software in place to _count_ votes,
 but that's no reason not to start collecting them.  The polls are now
 open, and will remain so until  UTC 20060911 (one month).  To vote,
 log into dev.g.o and type votify --help for instructions.  If you run
 into any problems, please let me know.  All current devs are eligible to
 vote.
 
 Incidentally, I'm currently serving as an election official since I'm
 not running for a spot on the Council.  It would be good to have a
 couple other people acting as officials, too.  Volunteers?

I volunteer (again).. What's the status on the search for voting
software ?

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



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

2006-06-07 Thread Olivier Crete
On Wed, 2006-07-06 at 18:41 +0200, Jakub Moc wrote:
 Arek (James Potts) wrote:
  Donnie Berkholz wrote:
  =virtual/x11-7 is hiding breakage in ebuilds that are not ported for
  modular X.
 
  I couldn't agree more, but I was forced to add this rather than allow
  unported ebuilds to break.
 
  Hmmm...Looks to me like it would be a great idea to fix the unported
  ebuilds.  Would it be possible to mark virtual/x11-7 as deprecated
  (using enotice/ewarn or similar), in order to get people to port any
  build relying on it to modular X?
  
  The way I see it, once virtual/x11-7 has been deprecated for a while (6
  months to a year) and most popular packages have been ported to modular
  X, virtual/x11-7 and any packages still relying on it could be given
  Last Rites.
 
 Hmm, I don't think so... There's been a plenty of time to do this when
 modular X has been package.masked, the remaining unported stuff didn't
 get much further even after it's been unmasked. There's been a
 (debatable) repoman check, which has been too annoying so devs nuked it
 for themselves, now it's non-fatal warning again (which is mostly being
 ignored).
 
 S - I'd pretty much say until the real breakage is *visible* and
 users start to scream - not much will change. Making it visible could
 also help us differentiate between used and used stuff. If there's
 something unported and you get no bug, then probably noone uses the
 thing, nothing depends on it and it can be punted from the tree.

Is there a recent list of non-ported packages ? Maybe we should do a
last effort to port everything for a week or two and then package.mask
the packages that no one cares enough about to port them.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] enroll users for testing packages

2006-04-11 Thread Olivier Crete
On Tue, 2006-11-04 at 19:35 -0500, Daniel Goller wrote:
  Isn't this why we already have the arch tester position as described by 
  GLEP 41 (http://www.gentoo.org/proj/en/glep/glep-0041.html)? 
  Furthermore, are you saying that users would enroll themselves via this 
  hypothetical web interface, or that an arch team would do so for users 
  who have proven themselves to be worthy?  If the former, this would be a 
  serious step back in terms of QA (think about sorting out all the crap 
  reports from ricer overlay users with OMGFAST CFLAGS from the decent 
  ones).  If the latter, I think the arch tester position already covers 
  this sort of thing.
  
 
 didn't he ask for people who know a particular application very well?
 i think there is a big difference between agreeing to test one
 particular package since they know it very well and want to make sure
 noone breaks it vs. being a full AT with all the things they get asked
 to test

Having a user test an application for a dev isn't a problem, as long as
the dev takes full responsibility for his resulting actions. This is
also true for ATs (the devs are still responsible for their commits even
if its on AT advice). So a dev can keep a list of trusted users, but if
we want to have an official list, then we need to make sure that the
people on that list are competent and that's where the AT process is
important.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Gentoo theming during bootup

2006-04-10 Thread Olivier Crete
On Mon, 2006-10-04 at 18:25 -0400, Mike Frysinger wrote:
 On Monday 10 April 2006 15:37, Grant Goodyear wrote:
  In any event, I think we need to remove the flying saucer guy.  When
  drobbins left and turned over the Gentoo IP to us, one thing that he
  kept was the flying saucer guy.  I believe that he was allowing us to
  use it while we got the redesign put together, but since that's dead it
  seems unfair to hold on to that flying saucer guy indefinitely.
 
 i'll miss him :(

Yea we have to keep him, he is one of the most important members of our
community.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X: unmasking tonight, RFC

2006-03-22 Thread Olivier Crete
On Wed, 2006-22-03 at 15:16 -0800, Donnie Berkholz wrote:
 Hi all,
 
 There aren't really any remaining blockers to keep modular X out of
 ~arch, as far as I can see.
 
 If anyone's got one, please bring it up now. I'm planning to unmask
 later tonight.

If modular X is used and gnome-base/control-center is not patched..
gnome-settings-daemon on some evdev combinations...

Not sure if that's a blocker... but we should rush in a new version of
control-center with the patch

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


Btw, how many ebuilds are left to be ported ?

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] What's on with ejabberd and relatives?

2006-03-02 Thread Olivier Crete
On Thu, 2006-02-03 at 21:14 +0100, Lars Strojny wrote:
 Am Sonntag, den 26.02.2006, 21:25 -0800 schrieb Donnie Berkholz:
 [...]
  You might want to talk to the maintainer and herd, not all of us. Or
  even file a bug for updates -- some people are very busy and just don't
  notice there's a new version.
 
 Tried to talk to the maintainer, no answer for days. What would you
 suggest to do now?

Then you ask the herd.. But it seems humpback is still responsive, look
at his reply to bug #101708


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: /etc/rc.conf

2006-02-13 Thread Olivier Crete
On Mon, 2006-13-02 at 16:51 -0500, Forrest Voight wrote:
 What about env.d? Gnome could install and env file that by default
 sets XSESSION to gnome.

Can't do... you can have gnome, kde, xfce, etc all installed at the same
time. 

 On 2/13/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
  On Monday 13 February 2006 13:19, Forrest Voight wrote:
   Why doesn't it make sense to split DISPLAYMANAGER and XSESSION up?
   They are related, but in different contexts. XSESSION is for the user
   and DISPLAYMANAGER is used at boot time.
  
   On 2/13/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
On Monday 13 February 2006 03:33, Donnie Berkholz wrote:
 And even then, it's only copied over when you specify the -m option
 to useradd. It isn't done by default.
   
Users might further decide they use a .bashrc from a different
system, or to clean all percieved cruft from the
.bashrc/.bash_profile. Having a sane default is probably better.
 
  I was just arguing why one should not keep XSESSION in .bashrc only, and
  rely on skel. It's too easy to break.
 
  Paul
 
  --
  Paul de Vrieze
  Gentoo Developer
  Mail: [EMAIL PROTECTED]
  Homepage: http://www.devrieze.net
 
 

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Unmasking modular X

2006-01-24 Thread Olivier Crete
On Tue, 2006-24-01 at 13:32 -0800, Donnie Berkholz wrote:
 Mark Loeser wrote:
  On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz
  [EMAIL PROTECTED] wrote:
  What's wrong with the original idea of just making any unported ebuild
  pull in all of modular X (minus drivers)? Yes, it means that some
  people will pick up unnecessary deps until all packages are ported, but
  it avoids anyone having to see flashy red errors.
  The problem with that is that it removes all motivation to ever port the
  packages. They'll just stay that way forever, where forever means until
  I threaten to remove that from the virtual, in which case we'll be in
  the same scenario we are now. Why? Because people have better things to
  do than fix stuff that isn't broken.
  
  It'd be nice if you reconsidered this as it will minimize any breakage that
  may occur.  Knowing that 800 packages are broken, and going to unmask it
  knowing that just doesn't seem acceptable in my eyes.  ~arch isn't meant to
  be things are known to be broken.  It's meant to mean, we think all of 
  this
  is ready to be stable, which it certainly won't be in this case.
 
 No, it won't. It will just postpone the same breakage, as I said above.
 You haven't provided any logic or backup to your contrary statement,
 just said that somehow a large portion of the other 800 will magically
 get ported.

Why not just postpone the unmasking by a few days... and lets say give
48h from now for all devs to fix their apps and have the volunteers
finish off the rest. Btw, I'll volunteer to help if I have any free time
this week. And then the unmasking can be much less painful. 

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2

2006-01-19 Thread Olivier Crete
On Thu, 2006-19-01 at 17:56 -0500, Mike Frysinger wrote:
 - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* 
 enables additional runtime code (such as assert()'s or helpful debug 
 output) ... if you're confused by what i mean, run `USE=debug emerge nano` 
 and then run `nano`

This is so overdue..
+1

 - if debug-build is in FEATURES, then the following happens:
  * auto sets CFLAGS to DEBUG_CFLAGS, LDFLAGS to DEBUG_LDFLAGS, CXXFLAGS to 
 DEBUG_CXXFLAGS (and in the future, we can add more variables as the need 
 comes up)

What about: CFLAGS=${CFLAGS} ${DEBUG_CFLAGS} .. otherwise bugs that
only appear after certain GCC optmisations may go away... 

 - we will set sane debug defaults in the base profile:
  * DEBUG_CFLAGS=DEBUG_CXXFLAGS=-O -g

I'd propose -fno-omit-frame-pointer -ggdb for x86/amd64 and -g for
default... 


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] fix binary debug support, part elevenity billion

2006-01-17 Thread Olivier Crete
On Tue, 2006-17-01 at 08:11 -0700, Richard Fish wrote:
 On 1/15/06, Olivier Crête [EMAIL PROTECTED] wrote:
  Why not use the splitdebug instead of nostrip? And make building with -g
  the default, then tell small HD users how to disable it in the docs. And
  it needs to disable -fomit-frame-pointer at least on x86. I've been
  building my whole system with splitdebug and yes it does take a lot of
  space, but its really useful.
 
 No argument against splitdebug, but my guess is that it would be
 useless for 99.97% of users, and would lead to complaints on -user
 about how much disk space gentoo consumes compared to insert least
 favorite distribution here, so it should not be the default.

The argument in favor of splitdebug is that it allows users to give
useful bugreports when using tools such as gnome's bug-buddy. Currently,
gentoo users provide very little useful information because everything
is stripped. And it only adds a few hundred megs and its easy to
disable. Probably should be explained in the handbook if we make it the
default.


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] fix binary debug support, part elevenity billion

2006-01-17 Thread Olivier Crete
On Tue, 2006-17-01 at 18:03 +0100, Diego 'Flameeyes' Pettenò wrote:
 On Tuesday 17 January 2006 17:51, Olivier Crete wrote:
  The argument in favor of splitdebug is that it allows users to give
  useful bugreports when using tools such as gnome's bug-buddy.
 Erm actually it does not. Unless gnome herd fixed it recently.
 The same goes for KCrashHandler/Dr Konqui.

It does on my system, bug-buddy just spawned GDB (and it has worked that
way for as long as I can remember). So you just need gdb 5/6 and it
should work without problems with splitdebug.


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

2006-01-06 Thread Olivier Crete
On Fri, 2006-06-01 at 09:39 -0800, Brian Harring wrote:
 On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote:
  On Fri, 2006-01-06 at 09:00 +, Chris Bainbridge wrote:
   On 06/01/06, Brian Harring [EMAIL PROTECTED] wrote:
   1)  Manpower. There are already 10,000 open bugs in bugzilla (and
   growing) without adding more.
  
  This is probably the primary reason it died.  This, of course, ties in
  greatly to #2.
 
 Automation can reduce workload, within limits.  Fex, scripting for 
 yanking packages/deptree out of normal tree for merging into a g19 
 tree.

Baz has developed a script that would yank a subtree with the proper
deps for the original GLEP 19 effort. It wasn't that hard to do.

And the idea of having a subtree is that the backports would be done by
a specific group of developers instead of the package maintainers and
therefore not getting any more work on the other devs.

I'm not really sure why the older one died... We were pretty close to
being able to build the stages and starting to distribute it... I would
be very favorable to seeing the whole thing restarted.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] last rites for net-im/sim

2005-12-19 Thread Olivier Crete
On Mon, 2005-19-12 at 12:19 +0100, George Shapovalov wrote:
 Ugh, it is the only one that reliably connects to icq (yea, I am stuck using 
 it for many people whom I contact as this is pretty much the only protocol 
 honored there) *and* handles various encodings in a sane way (no, gaim, 
 while been really nice on a protocol side, does not cut it on localization 
 side, not even close. And kopete is the other way around :))..

You may want to try GnomeICU for ICQ.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] last rites for net-im/sim

2005-12-19 Thread Olivier Crete
On Mon, 2005-19-12 at 21:08 +0100, George Shapovalov wrote:
 Thanks, I'll try, but seeing gnome in the name I am quite skeptical. It's 
 really nothing personal. Its just in my experience gnome/gtk apps could never 
 handle cyrillic well enough in all situations..
 
 Yea, cyrillic is a bitch. Its probably worse than chineese, no really :). 
 These guys were later to the game, so even though they have like tons of 
 variants and intrinsically more complex stuff, at least they got it right. 
 With cyrillic we have like 4 different encodings for the very same thing, and 
 3 of them are widely used (ironically, the one not used much is the official 
 standard, well, as usual :)). So, you can imagine people having set their 
 environment to one encoding, client reporting another and, to top it off, 
 messages getting recoded while on the server (at least I can see a difference 
 when some poeple shift to direct mode after having logged in, versus messaged 
 left on server when somebody is out.. Well, that might be a server screwing 
 some reported settings, but that does not help.). As you can guess, I can't 
 wait for the last non-utf-8 aware app to die painfull death :) (whell, where 
 this kind of stuff is important of course).

Modern ICQ is either unicode or specifies the encoding (but as a windows
locale and not a regular encoding..). Old ICQ sucks and you have to
guess.. If you have problems with GnomeICU.. please file a bug at
bugzilla.gnome.org .. I'm the upstream maintainer too...

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

2005-12-13 Thread Olivier Crete
On Tue, 2005-13-12 at 20:43 +, Ciaran McCreesh wrote:
 On Tue, 13 Dec 2005 21:35:44 +0100 Danny van Dyk [EMAIL PROTECTED]
 wrote:
 | I don't think that we need a GLEP for it, no matter how 'mini' it
 | would be.. Just asked Grant if I can convert dates in current GLEPs,
 | and he's ok with, though he wanted to have input from -dev first, so:
 | 
 | Anyone objecting to change those dates from dd-mon- format to
 | -mm-dd?
 
 I object. You're changing the GLEP process, and the way that that's
 done is through another GLEP. Otherwise we'll end up with people
 writing GLEPs following GLEP 1, and not realising that GLEP 1 is no
 longer how things work.

Why not just modify GlEP 1 ?

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

2005-12-13 Thread Olivier Crete
On Tue, 2005-13-12 at 21:09 +, Ciaran McCreesh wrote:
 On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete [EMAIL PROTECTED]
 wrote:
 | Why not just modify GlEP 1 ?
 
 Going back and retroactively modifying standards is icky, and it
 *still* doesn't address the issue of documenting why the change was
 made.

And why not just adding a changelog to the glep explaining the changes?
I really don't like to idea of having to read 8 gleps to find out how to
write a glep ... and calling it glep 1.a is a good idea.. or 1.1

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [GLEP] Manifest2 format

2005-12-06 Thread Olivier Crete
On Tue, 2005-06-12 at 17:04 +0100, Marius Mauch wrote:
 As promised here the GLEP for Manifest2 support:
 http://www.gentoo.org/proj/en/glep/glep-0044.html

I see nothing about GPG in the GLEP.. Would those manifest files be
signed like the current ones? Would it be possible to have per-line
signing, or something like the stacked signing idea that was proposed
last month. If we are going to change the manifest format, might as well
do it properly.


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] status of http://wwwredesign.gentoo.org

2005-11-21 Thread Olivier Crete
On Mon, 2005-21-11 at 02:18 -0500, Curtis Napier wrote:
 I'm asking for everyone (developers and users alike) to please have a 
 look at the updated site and send any feedback you may have. I'm 
 especially interested in feedback from anyone who uses accessibilty 
 programs such as screen readers or if you are color blind or have any 
 other accessibilty issues.

First, in the project pages, it says
Gentoo Projectscript generated (all stuck together)

Second, where is the path bar that was in the original design. I found
it really useful to help users see where they are inside the tree web
tree. 

Third, the green links in the header are way too dark on the crappy crt
I have at work, and not easy to see where one link ends and the next
starts. Using a lighter color would help.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Reminder on dependencies.

2005-10-25 Thread Olivier Crete
On Tue, 2005-25-10 at 20:16 +0100, Ciaran McCreesh wrote:
 On Tue, 25 Oct 2005 13:55:36 -0400 solar [EMAIL PROTECTED] wrote:
 | Please do not put words in my mouth. I've already asserted to you
 | several times that the definition of RDEPEND= is unclear and that we
 | do infact need a new set of depend atoms. R=(runtime) not Buildtime
 | for the NNth time. Till then please focus your efforts on something
 | useful that does not break other peoples systems or projects.
 
 Given the choice of possibly causing minor inconvenience to the embedded
 people or outright breaking the tree for every single user, the sane
 option is to keep the tree working. If embedded has a requirement for
 better DEPEND specifications, why don't they start working on a GLEP?

Maybe I dont get the problem of the embedded people, but why don't they
just rm -rf /usr/include (or INSTALL_MASK it)

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-16 Thread Olivier Crete
On Fri, 2005-16-09 at 16:21 -0400, Aron Griffis wrote:
 Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
   Those should be in package.mask. ~arch is for candidates for arch that
   haven't yet proven themselves.
  
  It's often the case that those ebuilds in principle work, but there
  are other reasons for not marking stable yet. Some packages for
  example can have upgrade problems for stable users while being
  stable for testing (by benefit of allready having passed such
  upgrade problems). Masking the ebuild is not really an option
  (causing testing users to go through unnecessary hoops again), while
  marking stable is also no option.
 
 You're saying there's four states:
 
 package.mask
 ~arch
 ~arch candidate for arch
 arch
[...]
 So far I find myself agreeing with Ciaran's idea in this thread.
 I don't see the point (yet) in more than three states.

Well having the ~arch candidate for arch makes the imlate script much
easier to use.. I would find it a PITA to have to go through the
changelog of every package to see if it has been in testing for 30
days.. Or we need to automate it, something like a
imlate-because-the-package-hasnt-changed-in-30-days.py 

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] first council meeting

2005-09-15 Thread Olivier Crete
On Thu, 2005-15-09 at 16:51 -0400, Aron Griffis wrote:
  3. glep40: Standardizing arch keywording across all archs
 Vote asked by Grant Goodyear
 
 Approved.

What does that glep mean anyways ? Appart from the creation of the x86
team, is there any action to be taken?
- Is the maint keyword approved? 
- Does it mean that devs who are not part of the x86 team can't move
packages from ~x86 to x86 ?
- Is there something else I failed to read?

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

2005-09-12 Thread Olivier Crete
On Mon, 2005-12-09 at 20:50 +0100, Ciaran McCreesh wrote:
 On Mon, 12 Sep 2005 21:39:48 +0200 Simon Stelling [EMAIL PROTECTED]
 wrote:
 | This has been in the todo-list for quite a while, but finally it's
 | done. I'm curious what you think of it.
 
 Could we get some numbers? How many arch testers have gone to become
 official developers? How many have disappeared without trace? How many
 stuck around but didn't do much?

Here is the list of AT's, current and past. Those marked active are
really active. And most of them joined in the last 2-3 months. 

http://www.gentoo.org/proj/en/base/amd64/tests/index.xml?part=1chap=1

Btw, do we want to be voters in the council elections? I'm not sure they
should be given a more official status. But giving easier access to
developership if they have done a good job as ATs should definitely be
considered.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [gentoo-core] Election results

2005-09-01 Thread Olivier Crete
On Thu, 2005-01-09 at 07:09 -0500, Grant Goodyear wrote:
 Thanks to the 148 people who voted.  I think that's slightly less than a
 50% turnout, but it's still not too shabby.
 
 The new Gentoo Council is:
 
 seemant
 vapier
 agriffis
 solar 
 azarah
 Swift
 Koon

As your friendly election official, I confirm that this result is valid
(ie consistent with the master ballot).

Congratulations to our new council! Now lets get to work!

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] combining x86 and amd64

2005-09-01 Thread Olivier Crete
On Thu, 2005-01-09 at 19:02 +0100, Ciaran McCreesh wrote:
 On Thu, 1 Sep 2005 19:50:11 +0200 Diego 'Flameeyes' Pettenò
 [EMAIL PROTECTED] wrote:
 | On Thursday 01 September 2005 19:41, Ciaran McCreesh wrote:
 |  Untrue.
 |
 | Can I have reasoning?
 
 Take a look at how sparc and mips currently handle packages which will
 run on some CPU kinds or ABIs but not others.

Is it just me, it seems that only sparc/mips devs want that kind of
change and non none of the x86/amd64 devs... 

I still dont see what practical advantage that would bring to x86/amd64
users or developers? 

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] combining x86 and amd64

2005-09-01 Thread Olivier Crete
On Thu, 2005-01-09 at 19:53 +0100, Ciaran McCreesh wrote:
 On Thu, 1 Sep 2005 20:46:46 +0200 Diego 'Flameeyes' Pettenò
 [EMAIL PROTECTED] wrote:
 | On Thursday 01 September 2005 20:32, Ciaran McCreesh wrote:
 |  Ideally they wouldn't be keyworded at all.
 | I live in a real world, not an ideal one.
 | 
 |  More users means more QA feedback. This means x86/amd64 will have an
 |  *easier* job.
 | SNR, this unknown value that's so much important in communications...
 | this is when I like the school I did.
 
 So your argument is that our users are clueless morons?

Many of the x86/amd64 user are... many like reiser4.. some even use
love-sources...

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] combining x86 and amd64

2005-09-01 Thread Olivier Crete
On Thu, 2005-01-09 at 15:25 -0400, Chris Gianelloni wrote:
 So would just making an x86 arch team.  It would also be much less of a
 problem than merging x86 and amd64.  How about this?  I proclaim and x86
 arch team now exists.  It already has a security liason.
 
 $ cat /var/mail/alias/arch/x86
 avenj
 solar
 tester
 port001
 azarah
 
 Seems that we even have two of our new Council members on the team.
 Anybody else want to join the team?  Just add yourself to the alias and
 start paying attention to requests that are submitted to [EMAIL PROTECTED]
 via bugzilla.

The people maintaining the x86 kernel should also join, as well as the
release maintainer (chris, is that you?), the grub/lilo maintainers,
etc... That would be a good start. 

We should also try to recruit one or two x86 arch testers, hparker has
offered to help. 

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

2005-08-30 Thread Olivier Crete
On Tue, 2005-30-08 at 10:46 -0400, Stephen P. Becker wrote:
 Shouldn't this fall under the x86 arch team rather than releng? The
  
  I'm sorry, but *what* x86 arch team?
 
 That's the point.  Ciaran is just pointing out for the gazillionth time 
 that x86 is an unsupported arch, if you go by the standards the other 
 arches have to follow to be part of Gentoo.  When is this going to be 
 fixed?  Or, will it just be ignored until all the x86 folks get amd64 
 machines and x86 pretty much becomes irrelevant?

Stop being jealous and get a Dell dude.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

2005-08-30 Thread Olivier Crete
On Tue, 2005-30-08 at 21:40 +0100, Stephen Bennett wrote:
 On Tue, 30 Aug 2005 21:15:18 +
 Luis Medinas [EMAIL PROTECTED] wrote:
 
  I belive the worse QA is in x86 and not in AMD64 and MIPS. Between
  AMD64 and x86 there's a lot of differences i.e. many packages in the
  tree that needs to be patched to work on AMD64 so we cannot cover
  AMD64/x86 under the same keyword. 
 
 There are packages that will work on (for example) little-endian mips
 but won't work or will need patching to work on big-endian, yet we
 still cover both of those with one keyword.

You are comparing apples and oranges.. Most of the herd devs only have
x86 and are not able to test amd64. That's the main difference. 

And I dont think the QA is worst on x86.. Most herd devs are on x86 and
its their responsability to do their QA. I've seen many horrible ebuilds
done by ppc people too. And x86 has many more packages that any other
architecture.

Also, x86 is where most of the newbies are, we can't assume that if it
works on amd64 it will also work on x86.. Let me say it again: x86 is
still special.. its not a regular architecture. 

That said, I agree, we need an x86 team. Maybe you want to lead it ?

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles

2005-08-30 Thread Olivier Crete
On Tue, 2005-30-08 at 21:56 +0100, Ciaran McCreesh wrote:
 On Tue, 30 Aug 2005 16:45:24 -0400 Olivier Crete [EMAIL PROTECTED]
 wrote:
 | And I dont think the QA is worst on x86.. Most herd devs are on x86
 | and its their responsability to do their QA.
 
 QA needs coordination. Otherwise we end up with repeats of the Gnome
 not building on stable x86 for several weeks at a time because the
 Gnome and Mozilla herds don't talk to each other fiasco.

I could not agree more. Do you want to do the coordination ?

 | And x86 has many more packages that any other architecture.
 
 Careful with that... The difference is not so big as you might think,
 and when you consider how many people own, say, sparc and compare it
 with how many own x86, you might be surprised...

Well, I would not be surprised at the number of packages that are not
use by anyone on sparc or mips or even amd64. But that might have a few
x86 users.. 

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] stripping implementation in portage

2005-08-23 Thread Olivier Crete
On Tue, 2005-23-08 at 11:16 +0200, Paul de Vrieze wrote:
 As an aside to this. Does anyone know how debug information can be changed 
 to have a different basedir. My idea was to create a custom strip 
 wrapper that would create external debugging files (like now possible 
 with gdb/binutils) and point them to a location 
 in /usr/src/packagenameplusversion. For that it would be necessary to in 
 some way hack the source location in the debug information.

There is already a patch [1] in bugzilla that does that.. And in bonus
to keeping the debug files (currently in libpath/.debug/libname.so.dbg
but that can be changed) . It can also keep the source files
in /usr/src/debug so they can loaded by gdb (pretty useful when
debugging into libraries). 

It creates 3 new features, keepdebug, keepdebugbin and keepsources

keepdebug will keep the debug symbols for libs
keepdebugbin will keep then for non-lib binaries
and keepsources will keep the related sources..

[1] http://bugs.gentoo.org/show_bug.cgi?id=45150

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] stripping implementation in portage

2005-08-23 Thread Olivier Crete
On Tue, 2005-23-08 at 12:40 -0500, Brian Harring wrote:
 First, sidenote (mild ot to this thread also), pardon the dupe posts, 
 thick fingered typing dumping an old message :)
 
 On Tue, Aug 23, 2005 at 01:34:33PM -0400, Olivier Crete wrote:
  On Tue, 2005-23-08 at 11:16 +0200, Paul de Vrieze wrote:
   As an aside to this. Does anyone know how debug information can be 
   changed 
   to have a different basedir. My idea was to create a custom strip 
   wrapper that would create external debugging files (like now possible 
   with gdb/binutils) and point them to a location 
   in /usr/src/packagenameplusversion. For that it would be necessary to in 
   some way hack the source location in the debug information.
  
  There is already a patch [1] in bugzilla that does that.. And in bonus
  to keeping the debug files (currently in libpath/.debug/libname.so.dbg
  but that can be changed) . It can also keep the source files
  in /usr/src/debug so they can loaded by gdb (pretty useful when
  debugging into libraries). 
  
  It creates 3 new features, keepdebug, keepdebugbin and keepsources
 Would rather implement those as filters as described above; short 
 version is that features is chunked up in the rewrite, so it's options 
 on the component you're configuring moreso.  That said, still will map 
 from old make.* to new format (on the fly, no forced config upgrades), 
 but I'd rather see it implemented as I've proposed.
 
 Reasoning is that if you build with debugging crap on, you've got 
 maximal flexibility in your choice of what your binpkgs/vdb winds up 
 with.
 
 Thoughts/yay/nays?

I havent looked at your new implementation (does it exist).. but yea
what you wrote seems to make sense... except that I keep the source code
too.. so it would bloat binary packages.. I think it should be done
before the packages are made.. or maybe use separate debug and have
separate debug packages like RedHat does.

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Fixing the TERM mess

2005-08-23 Thread Olivier Crete
On Tue, 2005-23-08 at 21:27 +0100, Ciaran McCreesh wrote:
 On Tue, 23 Aug 2005 8:52:13 +0200 Kevin F. Quinn
 [EMAIL PROTECTED] wrote:
 | On 21/8/2005 23:05:05, Ciaran McCreesh ([EMAIL PROTECTED]) wrote:
 |  Now the proposal. This isn't something that can happen immediately,
 |  but it's something I'd like to see us working towards:
 |  
 |  [...]
 |  
 |  * De-cripple the standard xterm definition and remove restrictions
 |  from programs which can make full use of xterm's capabilities.
 | 
 | This bit, obviously, has to wait until at least the more common
 | packages have been adjusted for their own TERM value.  In the
 | interim, how about creating a 'xtermstd' entry with the de-crippled
 | definition, and altering the (presumably few) packages that supply
 | fully-compatible xterms to use that, with a view to changing them
 | back to 'xterm' later once the rest of the world is in line.
 | 
 | I think it's also worth considering leaving the existing xterm entry
 | crippled, and just accept that abuse of it is too entrenched and
 | widespread to fix.  
 
 Hrm, I'd really rather not do that, on the grounds that it's a nasty
 hack and that it encourages people to carry on abusing TERM. By leaving
 xterm crippled in the long term, we're in effect saying it's ok to
 pretend to be an xterm, which it isn't.

I though about this thing last night, and frankly, I think its a lost
cause. I remember that during the Gnome 1.x era, gnome-terminal used to
set TERM=gnome (at least it did on Red Hat) and they had the proper
termcap/terminfo entries. But they ended up going back to TERM=xterm,
probably because it caused problems for their users, like login into
anything else and being reduced to the lowest possible common
denominator (like logging into a Solaris system and being reduced to
non-visual mode by vi). And by the way, Solaris 2.8 still does not know
about rxvt.

As a gnome-terminal user, I've never had problems with anything that
tried to use advanced xterm crap... probably because no uses them. If
you want X stuff, just use a real X application (like gvim...). I'm
strictly opposed to crippling my terminal use in the most common cases
(such a logging into a non-Gentoo system) for one or two legacy
applications.

In the era of massive sshing, we have to forget terminfo and new
terminal types. We should understand xterm to mean a basic x terminal
and not the application from X.org. 


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] imlate x86 Editon and more x86 fun

2005-08-12 Thread Olivier Crete
On Fri, 2005-12-08 at 13:53 +0900, Chris White wrote:
 I really do agree with not only this, but the need for stable marking
 as well.  Gentoo is very bleeding edge at this point, and I feel that
 stable packages are somewhat lacking.  However, the problems I see is
 what is considered Let the herd handle it and what is considered
 sure why not.  The script output should help, I'm just afraid that
 if a person marks a package that the maintainer was planning on
 working at, things could go wrong.  I'm open to ideas on such a team,
 but I'm not sure how to workout the major issues at this point.

I know this has been discussed before without coming to a conclusion.
But we need a wait for package maintainers to notify their intent. Maybe
adding a maint keyword that maintainers would add went they mark their
package stable. Especially since there seem more and more maintainers
whose primary arch is not x86.. or worse, who use more than one arch.
The concept of maintainer arch does not seem very adequate anymore.
Maybe we need to complete this with -maint and ~maint.. Those would
serve as guidance to arch teams.


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: qt.eclass

2005-06-30 Thread Olivier Crete
On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote:
 On Thursday 30 June 2005 03:01 pm, Thomas de Grenier de Latour wrote:
  It seems that portage evaluates disjonction left to right and
  stops on the first match it founds. Thus, if you want want it to
  choose the best matching version, you should rather sort them in
  decreasing order. (At least, that's what a small test with CVS
  HEAD shows here.)
 
 I'm sorry, yes, that's what I do in this case.
 
 Also, the eclass is in portage if anyone is so inclined to see how harmless 
 it 
 really i

Why not just use =qt-3.3 since qt3 probably wont have any new major
release ?


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project

2005-06-28 Thread Olivier Crete
On Tue, 2005-28-06 at 07:20 -0400, Jon Portnoy wrote:
 On Tue, Jun 28, 2005 at 12:57:46PM +0200, Ioannis Aslanidis wrote:
  On 6/28/05, Shyam Mani [EMAIL PROTECTED] wrote:
   The only difference I see b/w Staff and Developers is that you might
   not have access to CVS. You'll have an email ID and an account on
   dev.g.o, just like the rest of us (I'm assuming here). So what/where is
   the big deal about it?
  
  Maybe just that Developer sounds prettier than Staff. The rest is
  exactly as you stated. Now let me ask developers this:
  
  Does it really matter you if we are called developers instead of staff?
  
 
 Yes. You don't develop anything

Neither do infra devs or doc devs...

-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Removal of articles.xml from website

2005-06-09 Thread Olivier Crete
On Thu, 2005-09-06 at 10:40 -0700, Donnie Berkholz wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Sven Vermeulen wrote:
  On Thu, Jun 09, 2005 at 09:35:26AM -0700, Donnie Berkholz wrote:
  
 It would still be useful to keep the titles and other info, just
 removing the link. Otherwise, how are people supposed to even know the
 articles exist?
  
  
  Google?
  
  It's not our job to index Linux-related articles.
 
 So I can google for all Linux-related articles by Gentoo developers?
 It's not all Linux-related articles, so your comment is a bit deceptive.
 It's articles by Gentoo developers. And it is our job to be Gentoo. =)

I still fail to see why everything done by Gentoo devs belongs on the
Gentoo page. The only article that belongs on the Gentoo page is the one
about the Enoch and how it became Gentoo.

-- 
Olivier Crte
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] ekeyword and ordering

2005-06-07 Thread Olivier Crete
On Tue, 2005-07-06 at 17:44 -0400, Aron Griffis wrote:
 Marcus D. Hanwell wrote:[Tue Jun 07 2005, 05:32:31PM EDT]
  I also vote for alpha. I would like to see some indication of
  maintainer arch in metadata too, but in general agree with the
  policy of if one arch stabilises then we can assume that is the
  maintainer arch.
 
 Whoa, careful there.  It's not a policy and it's not even
 a recommendation.  I believe there are arch teams that will
 automatically stable a package after it has been ~arch for a period of
 time.  They will break your assumption.

This would be very evil. Are you sure its not a policy? Because it
should be and it has been discussed before. Arch teams should NOT get
ahead of the maintainer without his permission... or if they really
really know what they are doing. Maintainers normally know their
package/ebuilds and often have very good reasons to keep a package ~arch
for more than 30 days..  This is almost as evil as keywording on
architectures on which you can't test.. 

-- 
Olivier Crte
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list