Re: [gentoo-dev] Brand spanking new developer - Anrdrew Ross aka aross
Hope so - don't want rumors that Gentoo kills relationships. Yes, that would be bad.. and may make the need for date-a-dev even more apparant.. And we don't want that. (There is no way I'm letting antarus and ChrisWhite win..) Adopt a Developer needs developer requests? -- Daniel Black [EMAIL PROTECTED] Gentoo Crypto/Forensics/NetMon pgppkPkaDgeZq.pgp Description: PGP signature
Re: [gentoo-dev] per-package USE defaults
On Tue, 8 Aug 2006 17:49:40 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 08 August 2006 15:18, Zac Medico wrote: Stuart Herbert wrote: Any chance of per-package USE defaults support? That's much more useful to me. Attached to bug 61732 there's a patch that implements this via a new IUSE_DEFAULTS ebuild variable. If people like that particular implementation, then I'll update the patch so that it applies to portage-2.1.1_pre. Some might suggest that an EAPI bump is proper for the addition of this type of functionality, but perhaps we can slide it in without that extra annoyance. i'm really really partial to overloading IUSE here rather than introducing a new variable ... You mean by doing something like: IUSE=alpha +beta gamma meaning beta is default-on? Could do the same thing in per-package use.mask (although mask becomes a misnomer at that point). -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] Re: mulltiib cruft: /emul
Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 08 Aug 2006 11:43:13 -0400: looks like your mail server ate this ... someone remind me why our emul packages install in some obscure directory tree rooted in /emul if we moved these things to the standard lib32 dirs, it would certainly ease the pain of people doing multilib building, both in and out of portage it'd also let us free up env.d crap ... but most importantly, it'll stop breaking my friggin tab completion for /etc It came thru b4. As an amd64 user, I've been hoping a member of the arch team would reply, as it's a question that seeing it asked, I'm now curious about myself, but nothing yet. Pure speculation here, but the idea /might/ have been to separate prebuilt binary stuff into /emul, so it wouldn't conflict with future multiarch portage support (which would presumably use /lib32), which IIRC was hoped to be here by now, but turned out to be rather complicated and had no portage devs which had that particular itch they needed to scratch, so... (IOW, no blame or finger pointing, just that we'd hoped it'd be here by 2.1, and it isn't, and that's a fact amd64 continues to have to deal with.) As I said, pure speculation, likely wrong, but that's the first logical thing that came to my mind. I too am interested in a real answer. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: mulltiib cruft: /emul
On Wednesday 09 August 2006 10:57, Duncan wrote: Mike Frysinger [EMAIL PROTECTED] posted looks like your mail server ate this ... someone remind me why our emul packages install in some obscure directory tree rooted in /emul if we moved these things to the standard lib32 dirs, it would certainly ease the pain of people doing multilib building, both in and out of portage it'd also let us free up env.d crap ... but most importantly, it'll stop breaking my friggin tab completion for /etc It came thru b4. As an amd64 user, I've been hoping a member of the arch team would reply, as it's a question that seeing it asked, I'm now curious about myself, but nothing yet. i asked some others and they didnt get the e-mail either ... looks like our gentoo mail server is really starting to crash here ... Pure speculation here, but the idea /might/ have been to separate prebuilt binary stuff into /emul, so it wouldn't conflict with future multiarch portage support (which would presumably use /lib32), which IIRC was hoped to be here by now, but turned out to be rather complicated and had no portage devs which had that particular itch they needed to scratch, so... (IOW, no blame or finger pointing, just that we'd hoped it'd be here by 2.1, and it isn't, and that's a fact amd64 continues to have to deal with.) from what i remember, /emul was done because that's how some other distro was doing it ... but at the time i was staying out of multilib development because it sucked and i didnt have an amd64 now i have an amd64 and this current state annoys me greatly, so rather than bitch all the time, i want to fix it -mike pgp69KGwc2sCj.pgp Description: PGP signature
Re: [gentoo-dev] Re: mulltiib cruft: /emul
Am Mittwoch, 9. August 2006 17:50 schrieb Mike Frysinger: On Wednesday 09 August 2006 10:57, Duncan wrote: Mike Frysinger [EMAIL PROTECTED] posted Pure speculation here, but the idea /might/ have been to separate prebuilt binary stuff into /emul, so it wouldn't conflict with future multiarch portage support (which would presumably use /lib32), which IIRC was hoped to be here by now, but turned out to be rather complicated and had no portage devs which had that particular itch they needed to scratch, so... (IOW, no blame or finger pointing, just that we'd hoped it'd be here by 2.1, and it isn't, and that's a fact amd64 continues to have to deal with.) from what i remember, /emul was done because that's how some other distro was doing it ... but at the time i was staying out of multilib development because it sucked and i didnt have an amd64 now i have an amd64 and this current state annoys me greatly, so rather than bitch all the time, i want to fix it Herbs is maintaing the emul-libraries. IMHO it shouldn't be to hard to change it from /emul to /lib32 and /usr/lib32. And yes, /emul was there from the very beginning aka Tester/brad_mssw :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: mulltiib cruft: /emul
On 8/9/06, Mike Frysinger [EMAIL PROTECTED] wrote: i asked some others and they didnt get the e-mail either ... looks like our gentoo mail server is really starting to crash here ... http://bugs.gentoo.org/show_bug.cgi?id=141904 -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Who wants to tinker with a Palm Zire 71?
Title: Who wants to tinker with a Palm Zire 71? Hi, I have a Palm Zire 71 device, with Palm OS on it and a 400 MHz ARM-Processor in it. Actually I don't use this device anymore, so if somebody wants try to get Gentoo Linux run on it, I would give it to him. There is an SD/MMC-Slot which could become used to get data on the devie an there is also an IR interface and a USB-Adapter. But the biggest problem I see is that the OS is on a ROM, but maybe there would be a way to manipulate the BIOS if it has one, to boot from somewhere on the RAM. In any case I guess it would require to maipulate the hardware. If somebody here have the skills and motivation to try that, he or she should tell me and I will send him or her my device. Best Regards Sebastian Noack
Re: [gentoo-dev] Who wants to tinker with a Palm Zire 71?
Noack, Sebastian wrote: Hi, I have a Palm Zire 71 device, with Palm OS on it and a 400 MHz ARM-Processor in it. Actually I don't use this device anymore, so if somebody wants try to get Gentoo Linux run on it, I would give it to him. There is an SD/MMC-Slot which could become used to get data on the devie an there is also an IR interface and a USB-Adapter. But the biggest problem I see is that the OS is on a ROM, but maybe there would be a way to manipulate the BIOS if it has one, to boot from somewhere on the RAM. In any case I guess it would require to maipulate the hardware. If somebody here have the skills and motivation to try that, he or she should tell me and I will send him or her my device. Best Regards Sebastian Noack I'd love to - if anyone else hasn't already claimed it :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Tue, Aug 08, 2006 at 09:23:34PM +0200, Thomas de Grenier de Latour wrote: On Tue, 8 Aug 2006 00:22:50 -0700, Brian Harring [EMAIL PROTECTED] wrote: forcing cxx on via package.mask for gcc sys-devel/gcc[-cxx] If i want to build a cxx-free system, am i supposed to add sys-devel/gcc[-cxx] to its package.unmask? If so, what will prevent Portage upgrading to some package.masked 4.2_alpha version? After all, that's what a depatom interpretation would imply. Or am i supposed to carefully unmask =sys-devel/gcc-4.1*[-cxx] only, and pray for not overlooking the 4.2 upgrade when it comes (since it would bring cxx back in), and that there won't ever be a gcc-4.1.99-r42 dev's playground? Sarcasm aside, day or so I've sat and wondered about this one I don't have a good answer. For others who missed it, masks are collapsed into one statement, unmasks are collapsed into another, visibility is determined via if (!MASKED || UNMASKED) essentially. Sliding per package use masking into a seperate file sidesteps the issue via allowing for easier implementation- if (!USE_MASKED || USE_UNMASKED) (!MASKED || UNMASKED) That said, it still is an issue when use-deps hit- there isn't anything blocking a use dep being slid into the masks, requiring version ranges to be used to nuke it sanely via unmask. General problem with use deps; *could* still implement it via seperating out use specific restrictions and generating the second logic statement above, but that's bit magic imo. Perhaps an alt op? Or am i supposed to put -sys-devel/gcc[-cxx] in some profile overriding file? But then, when the tree mask is changed to sys-devel/gcc[-cxx,-fortran], my diff rule will suddenly be lost (this method of text lines overriding is okay in the context of official profiles, where coherent changesets can be done at once, but in user's config files, it's hell to maintain). Affect would be cumulative in that case, you'd wind up with a masking of sys-devel/gcc[-fortran] In short, i hope that either i have missed something about your proposal, No, per the norm you spotted something annoying overlooked by everyone else who commented. :/ Suggestions welcome- it can be sidestepped via seperate file, down the line when use-deps are available, the potential will still be waiting. Definitely grounds to force package.* instead of reusing unmask/mask, but I'd still like to get some form of solution for the general issue here- it's not going to go away unfortunately. ~harring pgpwfDifkbvRU.pgp Description: PGP signature
[gentoo-dev] moving gen_usr_ldscript() from eutils.eclass to toolchain-funcs.eclass
as the subject says, i'd like to move gen_usr_ldscript() to toolchain-funcs.elcass ... the reason for this is that i have an improvement to the function which will start writing OUTPUT_FORMAT() to ldscripts, but this requires $(tc-getCC) motivation: better multilib handling :) speak now before i start in -mike pgpGAGmjRFccZ.pgp Description: PGP signature
