Re: [gentoo-dev] Re: remove my address
Mike Frysinger wrote: On Wednesday 25 October 2006 01:53, Drake Wyrm wrote: I think someone is yanking your chain, vapier. i doubt it ... other people on irc mentioned receiving said e-mail as well Haven't seen said email here... George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: remove my address
George Prowse wrote: Mike Frysinger wrote: On Wednesday 25 October 2006 01:53, Drake Wyrm wrote: I think someone is yanking your chain, vapier. i doubt it ... other people on irc mentioned receiving said e-mail as well Haven't seen said email here... From my understanding, it wasn't sent to the actual mailing list, but to a few specific @gentoo.org addresses. -- David Shakaryan GnuPG Public Key: 0x4B8FE14B signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: remove my address
David Shakaryan wrote: George Prowse wrote: Mike Frysinger wrote: On Wednesday 25 October 2006 01:53, Drake Wyrm wrote: I think someone is yanking your chain, vapier. i doubt it ... other people on irc mentioned receiving said e-mail as well Haven't seen said email here... From my understanding, it wasn't sent to the actual mailing list, but to a few specific @gentoo.org addresses. Infra team, please block anything from [EMAIL PROTECTED] I could do it for my mailbox, but since there are many of us spammed by that moron, I think it would be best to block it on mail from SMTP command. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
Hi, On 10/25/06, Donnie Berkholz [EMAIL PROTECTED] wrote: Danny van Dyk wrote: Design phase for new projects: New projects need to post an RFC containing information about their goals, the plan on how to implement their goals and the necessary resources to -dev prior to creating the project. This proposal was accepted with 6 members voting yes and one member abstained from voting Could someone amend GLEP 39 to reflect this new requirement? (This _isn't_ intended to turn into a flamefest. It's intended to start a discussion on a point of principle). The current metastructure (as documented in GLEP 39) is a little unusual; it's a proposal that was voted in by all Gentoo developers. As such, as a point of principle, should the council be able to change/override/replace the rules in GLEP 39 w/out putting it to a vote of all Gentoo developers? (As a second principle, if GLEP 39 is amended, wouldn't it be better to publish a new GLEP to superceed it, rather than revise the existing GLEP?) Please - let's not get sidetracked about the nature of the change, or its merits. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Changing the metastructure
Tach Stuart, 0x2B859DE3 (PGP-PK-ID) Stuart Herbert schrieb: (As a second principle, if GLEP 39 is amended, wouldn't it be better to publish a new GLEP to superceed it, rather than revise the existing GLEP?) GLEP 39a? V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure
On Wednesday 25 October 2006 03:27, Stuart Herbert wrote: As such, as a point of principle, should the council be able to change/override/replace the rules in GLEP 39 w/out putting it to a vote of all Gentoo developers? sort of like the president rewriting the rules that control his own power ... do we treat GLEP 39 as the constitution and all changes require wider developer base approval while all other GLEPs are laws which can be amended ? (As a second principle, if GLEP 39 is amended, wouldn't it be better to publish a new GLEP to superceed it, rather than revise the existing GLEP?) i think in general it depends on the nature of the change and how drastic it is of the original ... but that can be a bit of a slippery slope i guess (how do you measure the degree of a change ?) -mike pgpqkHM8GQ9Pz.pgp Description: PGP signature
[gentoo-dev] eselect module for choosing between gnash and netscape-flash
Hi,
(Sorry if this is a dupe. I tried sending it before, but it seems to
have disappeared into /dev/null.)
I wrote an eselect module for choosing between the browser plugins from
net-www/gnash and net-www/netscape-flash, and I was wondering if it
could be included in Gentoo (probably not in its current state...).
I haven't updated any ebuilds to use it yet, because some details are
still open for discussion, in particular the location the plugins should
be installed to. If you want to test it in the meantime, create a
/usr/lib{,64,32}/nsbrowser/plugins/flash directory, and move the
existing Flash .so's from /usr/lib{,64,32}/nsbrowser/plugins to the new
directory. eselect will name the plugins after their filenames, minus
the .so - possibly not very user-friendly, but this could be fixed by
either using a separate display name, or by installing them with nicer
names.
Note that changing the active plugin while the browser's running may or
may not work reliably, it's best to restart it each time. Don't think
that's a bug in the module, I'm sure there are enough of those as it is. ;-)
Another issue is that it currently only works system-wide. It could be
nice to let each user override the global preference, but I don't know
of any reliable way to do that. At least SeaMonkey doesn't allow the
user's plugin directory to override the global one.
Other things: the multilib bits aren't tested much, since unless I've
missed something there's no way to build gnash in 32-bit mode on an
AMD64 system. On the other hand, it works for 64-bit browsers with the
help of net-www/nspluginwrapper. Speaking of which, it would be nice if
the two could be made to cooperate a bit better. nspluginwrapper works
by generating stubs for all the plugins it finds at merge-time, but it
would need to know about the special plugin location. There are two
ways I can think of to do this: either patch nspluginwrapper (yuck) or
make its ebuild juggle the plugins appropriately (slightly less yuck,
but wouldn't work if the administrator tries to generate the stibs
manually later on, which is needed if nspluginwrapper is installed
before Flash). Any preferences?
That's all I can think of for now. Any comments are appreciated.
The original MIME headers for this attachment are:
Content-Type: text/plain;
name=flash-nsplugin.eselect-0.1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename=flash-nsplugin.eselect-0.1
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id: $
# based on kernel.eselect
DESCRIPTION=Manage the Flash browser plugin symlink
MAINTAINER= # XXX
#SVN_DATE='$Date: $'
#VERSION=$(svn_date_to_version ${SVN_DATE} )
VERSION=0.1
plugindir=nsbrowser/plugins
flashdir=flash
flashlink=flashplugin.so
# return the appropriate libdir based on command-line parameters
get_libdir() {
local abi=${1} libdirs
# uses the same approach as java-nsplugin.eselect: hardcode
# /usr/lib{,32,64}, since it's not entirely clear how to map the
# abi parameter onto list_libdirs's results
if [[ -z ${abi} ]] ; then
if [[ -d ${ROOT}/usr/lib ]] ; then
echo ${ROOT}/usr/lib
else
die Can't find libdir! That's bad!
fi
elif [[ ${abi} == 64bit ]] ; then
if [[ -d ${ROOT}/usr/lib64 ]] ; then
echo ${ROOT}/usr/lib64
else
die -q \64bit\ doesn't appear to be valid on your
system
fi
elif [[ ${abi} == 32bit ]] ; then
if [[ -d ${ROOT}/usr/lib32 ]] ; then
echo ${ROOT}/usr/lib32
else
die -q \32bit\ doesn't appear to be valid on your
system
fi
else
die -q Unrecognised ABI \${abi}\
fi
}
# return the human-readable name for the specified plugin
human_name() {
local plugin=${1}
plugin=${plugin##*/}
plugin=${plugin%.so}
echo ${plugin#npwrapper.}
}
# find a list of Flash plugins in the specified libdir
find_targets() {
local libdir=${1} oldshopts
oldnullglob=$(shopt -p nullglob )
shopt -s nullglob
for p in ${libdir}/${plugindir}/${flashdir}/*.so; do
human_name ${p}
done
${oldnullglob}
}
# try to remove the Flash plugin symlink from the specified libdir
remove_symlink() {
local libdir=${1}
rm ${libdir}/${plugindir}/${flashlink}
}
# set the kernel symlink in the specified libdir
set_symlink() {
local libdir=${1} target=${2}
if is_number ${target} ; then
targets=( $(find_targets ${libdir} ) )
target=${targets[$(( ${target} - 1 ))]}
fi
if [[ -z ${target} ]] ; then
die -q Target \${target}\ doesn't appear to be
Re: [gentoo-dev] eselect module for choosing between gnash and netscape-flash
On Saturday 21 October 2006 08:38, David Leverton wrote: (Sorry if this is a dupe. I tried sending it before, but it seems to have disappeared into /dev/null.) nah, it made it through (ive got a copy) ... i bet the mailing list shit a brick though which is why you didnt see it ... ive taken to checking gmane.org now before resending stuff ... http://dir.gmane.org/gmane.linux.gentoo.devel -mike pgpUDmgb1ugBn.pgp Description: PGP signature
Re: [gentoo-dev] Changing the metastructure
Mike Frysinger wrote: (how do you measure the degree of a change ?) By the number of inflammatory mails it causes within the timeframe of two weekdays. Quite obvious, isn't it? ;) -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: Mike Frysinger wrote: (how do you measure the degree of a change ?) By the number of inflammatory mails it causes within the timeframe of two weekdays. Quite obvious, isn't it? ;) ok, lemme just shutdown email for the next couple days :p - -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRT87hoBrouQZ9K4FAQK9bAP+M5YdBRbM4aEUqq+dCPBJMsnpH+MLcg7R 3miey2QbznZL/nI55d6FiGOZvgOGQ4ibd0G8WIbfxvBZdQmHpOqPHmOUW1WgtfIK L7aDb2Y1DNF+9MWwSs+STLrZbuaUUX94E/On+mk34VSkYeP0Dq1s602aGfVpD95d /ZpbSeY7WeI= =9QaS -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure
Simon Stelling ha scritto: Mike Frysinger wrote: (how do you measure the degree of a change ?) By the number of inflammatory mails it causes within the timeframe of two weekdays. Quite obvious, isn't it? ;) No also by who/howmany start the biggest number of inflammatory mails quote... but that can be a bit of a slippery slope i guess/quote -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] amd64 and ia64 keywords
On Sat, 21 Oct 2006 13:36:04 -0400 Jonathan Smith [EMAIL PROTECTED] wrote: ia64 is for itanium, which was intel's horrid first attempt at a 64-bit successor to x86. I wouldn't call Itanium a successor to x86, any more than SPARC was (recall that early Sun boxes were x86). As you mentioned, it's a completely new architecture. All those years people have been bashing Intel for the limitations of x86 that have been retained for decades for compatibility reasons (limited register set, nasty CISC, ever-increasing instruction set) - they try to do the design-from-scratch thing and it just gets ignored. AMD jump in and do what Intel had always previously done - extend the existing architecture by bolting on extra stuff - and clean up in the marketplace (or at least, hit Intel hard). If you want to call any architecture horrid, I'd suggest x86, which from a programmer's perspective has evolved into a real mess. x86_64 alleviates some nastiness (register set is now workable, pc-relative addressing is possible), but adds some more of its own. Of all the processor architectures I've worked with, modern x86 is far and away the muckiest from the point of view of an embedded software engineer. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
On Wed, 2006-10-25 at 08:27 +0100, Stuart Herbert wrote: The current metastructure (as documented in GLEP 39) is a little unusual; it's a proposal that was voted in by all Gentoo developers. As such, as a point of principle, should the council be able to change/override/replace the rules in GLEP 39 w/out putting it to a vote of all Gentoo developers? Well, let's make it simpler, then. Does it say anywhere in GLEP 39 that the elected Council cannot change it? Does it limit the council's powers in any way? (As a second principle, if GLEP 39 is amended, wouldn't it be better to publish a new GLEP to superceed it, rather than revise the existing GLEP?) For something like this, I think that merely noting that it was changed via an amendment from the Council should be sufficient. I do agree that changing it inline without such a note would be bad. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
On Wed, 2006-10-25 at 08:27 +0100, Stuart Herbert wrote: (As a second principle, if GLEP 39 is amended, wouldn't it be better to publish a new GLEP to superceed it, rather than revise the existing GLEP?) Also, I'd like to know what you would propose we do if we were to follow something like this. Would we post something like GLEP 39a, as an amendment to GLEP 39, or would we have to rewrite the whole thing, with just the one change, to supersede? Perhaps we need an amendment to GLEP 1 to allow explictly-stated amendments? Realize that the new council is trying to both become the leaders of Gentoo that so many seem to want, yet also have to balance not overstepping the bounds some people think we need. We honestly do need everyone's opinions on these things, so thank you for posing yours. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
On Wed, 25 Oct 2006 08:27:13 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | As such, as a point of principle, should the council be able to | change/override/replace the rules in GLEP 39 w/out putting it to a | vote of all Gentoo developers? The Council has already done so, with the addition of the final bullet point in Specification list B. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
Hi Chris, On 10/25/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Well, let's make it simpler, then. Does it say anywhere in GLEP 39 that the elected Council cannot change it? Does it limit the council's powers in any way? No, it does not. That's why I've asked for a discussion of this as point of principle, rather than as a point of law, so to speak. Reading the council logs and seeing this item, it occurred to me that it's something that I don't think we've ever actually debated as a group. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
Chris Gianelloni wrote: Realize that the new council is trying to both become the leaders of Gentoo that so many seem to want, yet also have to balance not overstepping the bounds some people think we need. We honestly do need everyone's opinions on these things, so thank you for posing yours. I don't mind the council touching the metastructure, as long as they do it right ;) If they don't, I will surely state so and ask for a referendum. If it turns out that like 60% of the devs don't share the council's opinion I'm sure they will re-think their decision. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
On 10/25/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: The Council has already done so, with the addition of the final bullet point in Specification list B. Thanks for pointing that out. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
On Wed, 2006-10-25 at 13:17 +0100, Stuart Herbert wrote: On 10/25/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Also, I'd like to know what you would propose we do if we were to follow something like this. Would we post something like GLEP 39a, as an amendment to GLEP 39, or would we have to rewrite the whole thing, with just the one change, to supersede? Perhaps we need an amendment to GLEP 1 to allow explictly-stated amendments? I think it'd be common sense to post -r1, -r2 etc, and extend the XML syntax so that we could easily indicate which sentences had been changed. I think it'll make things easier than a read-GLEP-39-now-read-GLEPs-39a-to-39z type of approach. We could also have a 'Revisions' section somewhere (if we don't have one already) in the GLEP listing the date, a link to the Council meeting logs approving the change, and a (very) brief summary of the change. I'm sure there are other ways we could do this that would also be practical. I think the likely best way would be to do something like: All new projects must first be proposed as an RFC to the gentoo-dev mailing list with a list of goals, project plan, and a list of resources required[1]. Then there would be an Amendments section, which would contain something like: 1. This was added by vote of the Gentoo Council on 2006/10/19 to improve communications between developers. We could then include a link to the meeting summary, too, or a link to the mailing list thread or whatever, that caused the change. This should satisfy everyone, as changes are noted from the original, yet there's still just the one authoritative place to look for the information. How does this work for you? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
Hi Chris, On 10/25/06, Chris Gianelloni [EMAIL PROTECTED] wrote: I think the likely best way would be to do something like: [snip] Yeah, that works for me. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
On Wed, 25 Oct 2006 10:48:57 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | (Incidentally, I apologize for missing the meeting. I was in | intensely boring radiation safety training.) Uh, isn't boring a good thing when it comes to things involving radiation? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Changing the metastructure
Vapier wrote: [Wed Oct 25 2006, 02:56:28AM CDT] On Wednesday 25 October 2006 03:27, Stuart Herbert wrote: (As a second principle, if GLEP 39 is amended, wouldn't it be better to publish a new GLEP to superceed it, rather than revise the existing GLEP?) i think in general it depends on the nature of the change and how drastic it is of the original ... but that can be a bit of a slippery slope i guess (how do you measure the degree of a change ?) Nonetheless, I agree w/ vapier. GLEP 39 supercedes GLEP 4, and clearly the changes were extreme there. For the previous and current changes to GLEP 39 the changes are much smaller, and I'd rather see the changes done inline. *Shrug* It's a slippery slope, but I'd rather rely on common sense until there's actual evidence that it's failing. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpBtKJjfiUBe.pgp Description: PGP signature
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
Ciaran McCreesh wrote: [Wed Oct 25 2006, 11:17:09AM CDT] On Wed, 25 Oct 2006 10:48:57 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | (Incidentally, I apologize for missing the meeting. I was in | intensely boring radiation safety training.) Uh, isn't boring a good thing when it comes to things involving radiation? Yes, when you're handling actual nukes (nuclear sources). No, when it's the fourth eight-hour day of explaining how the keys to nuclear safety are distance (farther is better, and exposure is an inverse square law), time (shorter is better), and shielding (more is better, and use plastic or water to stop neutrons, not lead). Meanwhile, I received this reply to my e-mail well before the actual e-mail. Anybody know what's causing these e-mail issues? Now that we have trustees in place, would ordering new boxes help? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpul3cw5lsGw.pgp Description: PGP signature
Re: [gentoo-dev] GeNUS : how I currently manage my gentoo network (200+ machines)
Hi guys (and girls ;) ), And sorry for the long delay of my answer, I was very busy in the last few days. I just cleaned up (a bit) and uploaded my script, with a set of fake configs, in a nice .tgz file (1). Feel free to contact me if something is not clear enough (high probability since I didn't wrote any documentation about it). Preston Cody a crit : Sounds interesting. Would you perhaps be interested in helping with the Scire project? Sure I am ! I'll try to touch you on IRC asap. Cheers, Hubert. (1) http://www.neskaya.free.fr/files/gentoo/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: put new additions along with removals in GWN
On Wednesday 25 October 2006 21:56, Yuri Vasilevski wrote: After seeing Upcoming package removals, for couple of weeks now, in GWN I'm beginning to think that I would like to see also a list of new packages added to portage next to the list of packages to be removed. http://packages.gentoo.org/ -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpW9VJdUOkQ7.pgp Description: PGP signature
Re: [gentoo-dev] RFC: put new additions along with removals in GWN
On Wed, 2006-10-25 at 14:56 -0500, Yuri Vasilevski wrote: If you think this is a good idea, I'd be glad to write some scripts for this. If you write all the code, I'll run it, but I'm not taking my time to track down all of the additions. The current removals is done by hand by some volunteers for the GWN. There's nothing automatic about it. Someone else already suggested this to us, but I explained to him that unless someone had some way to automate it that it simply wasn't feasible to do by hand. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: put new additions along with removals in GWN
reporting additions of new programs aren't feasible? or are you referring to version updates and package bumps and such -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: put new additions along with removals in GWN
On Wed, 2006-10-25 at 16:25 -0400, Caleb Cushing wrote: reporting additions of new programs aren't feasible? or are you referring to version updates and package bumps and such None of it is feasible if I'm left to do it by hand. I have much better things to do (like actually add new packages) than try to keep track of what everyone else is doing. The GWN takes a significant amount of time as it is to put together. Any process that isn't automated is pretty much out of the question due to time constraints. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: put new additions along with removals in GWN
Caleb Cushing wrote:
reporting additions of new programs aren't feasible? or are you
referring to version updates and package bumps and such
Reporting removals will be done by treecleaners once I have it implemented.
Reporting additions may require some cvs foo on lark; such as new
directories in ${PORTDIR}/$CAT/
Someone needs to implement the foo; however.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
i just noticed mx2.gentoo.org isnt responding on port 25, shouldnt it be? defeats the purpose of backup MX if its not respond :)CpuID.On 10/26/06, Grant Goodyear [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: [Wed Oct 25 2006, 11:17:09AM CDT] On Wed, 25 Oct 2006 10:48:57 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | (Incidentally, I apologize for missing the meeting.I was in | intensely boring radiation safety training.) Uh, isn't boring a good thing when it comes to things involving radiation?Yes, when you're handling actual nukes (nuclear sources).No, when it's the fourth eight-hour day of explaining how the keys to nuclear safetyare distance (farther is better, and exposure is an inverse square law),time (shorter is better), and shielding (more is better, and use plastic or water to stop neutrons, not lead).Meanwhile, I received this reply to my e-mail well before the actuale-mail.Anybody know what's causing these e-mail issues?Now that wehave trustees in place, would ordering new boxes help? -g2boojum---Grant GoodyearGentoo Developer[EMAIL PROTECTED]http://www.gentoo.org/~g2boojumGPG Fingerprint: D706 9802 1663 DEF5 81B09573 A6DC 7152 E0F6 5B76
Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
On Wednesday 25 October 2006 08:17, Stuart Herbert wrote: I think it'd be common sense to post -r1, -r2 etc, and extend the XML syntax so that we could easily indicate which sentences had been changed. well each GLEP itself has a version number ... we could just bump it and expect people to go read CVS history, or we add a new section to the end of the glep and use that as a mini ChangeLog ... -mike pgpeLLfK4tpvn.pgp Description: PGP signature
[gentoo-dev] mplayer global use flag
If no one objects, I'd like to add an mplayer global USE flag to replace all the local ones. 5 ebuilds use it right now for all the same purpose, and I'm going to need one on mythvideo as well. Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] virtuals and dependencies dispaly
On Tuesday 24 October 2006 16:36, Brian wrote: def get_virtual_dep(atom): returns a resolved virtual dependency. contributed by Jason Stubbs, with a little adaptation # Thanks Jason non_virtual_atom = portage.dep_virtual([atom], portage.settings)[0] if atom == non_virtual_atom: # atom,is a 'new style' virtual (aka regular package) return atom else: # atom,is an 'old style' virtual that resolves to: non_virtual_atom return non_virtual_atom This could be simplified to: def get_virtual_dep(atom): returns a resolved virtual dependency. return portage.dep_virtual([atom], portage.settings)[0] Hmm.. Actually, there is one problem here. import portage portage.dep_virtual(['virtual/mda'], portage.settings) [['||', 'mail-mta/postfix', 'mail-filter/procmail']] The values of portage.settings.virtuals are arranged in such a way that the first value in a key's list is either an installed package or the package that would be chosen (if no other package in the list or new package PROVIDEing the virtual was brought in for other reasons) so you'd probably be better off doing something like: def get_virtual_dep(atom): returns a resolved virtual dependency. key = portage.dep_getkey(atom) virtuals = portage.settings.getvirtuals() if key in virtuals: return atom.replace(key, virtuals[key][0]) else: return atom Displaying all known packages for any specific virtual is also a possibility... I'll leave it up to you on that. ;) -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
