Re: [gentoo-dev] Network configuration and bash
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] Network configuration and bash
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] the *box ebuilds and x11
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
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
On Tue, 2006-31-10 at 17:02 +0100, Stuart Herbert wrote: > This leaves package maintainers in the situation that there are > 'old'/'insecure'/ 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] The Dreaded herd tag
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] Ignoring/overwriting IUSE from an eclass
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] implicit vs explicit dependencies
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
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
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
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
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
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
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
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
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?
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
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
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] New developer: Patrick Mclean
On Mon, 2006-23-01 at 11:21 -0600, Mike Doty wrote: > I am currently working as a systems administrator for McGill University > School of Computer Science, Montreal, Quebec, Canada. I live with my > girlfriend in an apartment in the east of Montreal. Hey, I'm not longer the only one in Montreal! And we're what, 4 in Quebec now! -- 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
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
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] fix binary debug support, part elevenity billion
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 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] New developers: Martin Ehmsen (ehmsen) and Michal Kurgan (moloh)
On Sun, 2006-15-01 at 22:05 +, Tom Martin wrote: > Hi list, > > Two new developers to tell you about. First up is Martin Ehmsen, who is > going to be helping out with the text-markup herd, i.e. tex ;). Ah finally someone to fix all of my TeX problems... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
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
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] last rites for net-im/sim
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] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
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] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)
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] [GLEP] Manifest2 format
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
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] Email subdomain
On Fri, 2005-18-11 at 22:06 +0100, Max wrote: > Hi. > > On 11/18/05, Homer Parker <[EMAIL PROTECTED]> wrote: > > > > Thoughts, better ideas appreciated. > > > Well, they are called testers, so why not @testers.g.o? I like @testers.g.o .. it feels like an army of mini-me ! Can I get [EMAIL PROTECTED] ? ;) -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Reminder on dependencies.
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
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
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
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=1&chap=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
Re: [gentoo-dev] combining x86 and amd64
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] combining x86 and amd64
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
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
[gentoo-dev] Re: [gentoo-core] Election results
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] Re: [gentoo-core] crap use flags in the profiles
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] Re: [gentoo-core] crap use flags in the profiles
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
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] Fixing the TERM mess
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] stripping implementation in portage
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 /.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] stripping implementation in portage
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 /.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] imlate x86 Editon and more x86 fun
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] New Developer: Luis Medinas
On Mon, 2005-08-08 at 10:32 -0500, Mike Doty wrote: > Everyone welcome our newest minion: MetalGOD. Luis joins us to help out > with the printing herd and amd64 keywording. He also has his eyes on > the GDP project. I'll let him introduce himself. Welcome among us ! And give us those amd64 keywords! -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] net community servers, in what category?
On Wed, 2005-20-07 at 23:58 +0200, Christian Parpart wrote: > community-libs/libyacs > community-server/yacsd > community-server/yacs-meta > So, finally, in what category could those packages be placed in? What about net-libs and net-misc ? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
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
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] Glibc, non-glibc and external libs
On Thu, 2005-16-06 at 00:02 +0200, Diego 'Flameeyes' Pettenò wrote: > The problem with external libraries which are needed on non-glibc systems > (not > sure about uclibc) to have GNU-style functions is getting bigger. > > Not only we need to depend on gettext and libiconv, but there's now also > another library, gnugetopt which provides getopt_long function non non-glibc > systems. > > This is going to be a problem, because waiting for new virtuals for those > will > take a lot of time and Gentoo/FreeBSD is slowed down by this a lot. > > I'm asking for a quick solution because Gentoo/FreeBSD is proceeding well but > this is hurting the possibility to have all the depends cleaned out. > > There are other solutions a part the new virtuals? Why dont you just add them to the profile as system packages ? -- 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
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 Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ekeyword and ordering
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 Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
