Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
On Wed, 11 Jan 2006 14:51:46 -0800
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> I've been cleaning up media-fonts/ to work with modular-X, and I see a
> lot of ebuilds with stuff like this:
> for font in *.bdf; do
> /usr/X11R6/bin/bdftopcf ${font} > `basename $font .bdf`.pcf
> done
> gzip *.pcf
>
> ['make' suggestion and example makefile snipped]
You could just do it directly in bash:
for font in *.bdf; do
pcf=`basename $font`.pcf && \
/usr/X11R6/bin/bdftopcf ${font} > ${pcf} &&
gzip ${pcf} &
done
wait
You may want to limit the number of parallel processes somewhat (as
with 'make -jN'), which is also easy enough to do:
n=${MAX_PARALLEL}
for font in *.bdf; do
pcf=`basename $font .bdf`.pcf && \
/usr/X11R6/bin/bdftopcf ${font} > ${pcf} && \
gzip ${pcf} &
[[ ${n} -eq 0 ]] && wait && n=${MAX_PARALLEL}
((n=${n}-1))
done
wait
--
Kevin F. Quinn
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
Lisa Seelye wrote:
On Thu, 2006-01-12 at 00:18 +, Ferris McCormick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 11 Jan 2006, Lisa Seelye wrote:
On Wed, 2006-01-11 at 14:51 -0800, Robin H. Johnson wrote:
I've been cleaning up media-fonts/ to work with modular-X, and I see a
lot of ebuilds with stuff like this:
for font in *.bdf; do
/usr/X11R6/bin/bdftopcf ${font} > `basename $font .bdf`.pcf
done
gzip *.pcf
For having 100 files in *bdf, this is so serial it's painful.
And here I was hoping Distcc would get some usage. :(
Distcc gets lots of usage with modular X. But for the fonts? :)
Time for distfont? ;)
Make this distributed tool for tar zip bzip2 and gzip and I'm in, I don't think
it would be useful with anything else than Gigabit Ethernet.
We might want to have in the make.conf 2 separate variables, one of them saying
how many threads can be run on the machine, then How many threads/process across
a cluster.
For example, my Dual Xeon EM64T file server can do make -j4 locally, like in
make install, make docs etc etc, But for compiling I can use -j20, really not
useful over -j8 anyway. But the point is, it would be usefully to separate the
load distribution on the local machine and cluster nodes.
Philippe Trottier
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a plea for testing help
Greg KH wrote: > And if someone wants to forward this over to -user, feel free. Do you want to have this kernel documented in our Kernel guide [1]? [1] http://www.gentoo.org/doc/en/gentoo-kernel.xml#doc_chap3 Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] Conversion from kernel-mod.eclass to linux-mod/linux-info
Hi, As stated in bug #74396, all ebuilds using kernel-mod.eclass must be converted to using either linux-mod.eclass and/or linux-info.eclass. The bug has been open since 2004-12-14, yet there are still ebuilds in the tree which inherits kernel-mod.eclass: $ find . -name "*.ebuild"|xargs grep inherit|grep kernel-mod|cut -d '/' -f 2,4|sed -e "s:\.ebuild.*::" sci-misc/comedi-0.7.68 sci-misc/comedi-0.7.67 media-libs/svgalib-1.9.19-r3 sys-apps/realtime-lsm-0.8.2_pre20041022 sys-apps/realtime-lsm-0.8.3 sys-apps/realtime-lsm-0.8.5 sys-cluster/pvfs2-1.2.0 sys-fs/cryptsetup-0.1 media-sound/alsa-driver-1.0.3 media-tv/linuxtv-dvb-1.1.1-r1 media-tv/rivatv-0.8.5-r2 Apart from sci-misc/comedi and sys-cluster/pvfs2, the ebuilds all have newer versions which have already been ported. If you maintain any of these ebuilds, please see to it that the older versions which use kernel-mod.eclass are either removed from the tree or updated to use the new eclasses. Needless to say, the sci-misc/comedi and sys-cluster/pvfs2 needs to be converted to use the new eclasses as well. The old kernel-mod.eclass is not for use in new ebuilds. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgp8QhG8sLaGd.pgp Description: PGP signature
[gentoo-dev] Jan/2006 council agenda
for this month: * GLEP 45 - GLEP date format * disallow multiple votes per person (from ciaranm) http://marc.theaimsgroup.com/?t=11346783302&r=1&w=2 * global gentoo goals for 2006 for next month: * periodically freezing the tree for new packages (from carlo) i miss anything ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC --- Thoughts on devrel bug content
On Wed, 2006-01-11 at 14:08 -0700, Duncan wrote: > Ferris McCormick posted > <[EMAIL PROTECTED]>, excerpted below, on > Wed, 11 Jan 2006 19:04:19 +: > > > B. "Jurisdiction" --- why this is something for devrel to consider (policy > > violation or whatever). This is a categorization of the report, not an > > argument why it is valid. (This could be handled by a predefined set of > > reasons by an existing Bugzilla field similar to "Component," but > > currently it is not.) > > An enumeration or list of examples would be rather helpful, here. Since > you say it could be a predefined list, enumerating it in the RFC, or at > least giving a couple examples, shouldn't be unreasonable. Keep in mind > that it's possible/likely the filer will have never filed something like > this before, so the vague guideline as stated simply isn't all that much > help. You want it concrete, make it so. > This is a reasonable request, but I don't have such a list right now. Here are some annotated examples of the sorts of things devrel is interested in, so you can use these as guides: 1. Abusive behavior, IRC. (Recurring abusive behavior) 2. Abusive behavior, email. 3. Abusive/inappropriate responses on normal bug reports. 4. Abusive behavior, forums. (The forum moderators almost always handle this sort of problem pretty quickly.) 5. Other etiquette violation, IRC. (Recurring violation of a #gentoo IRC channel's etiquette policy, not covered by abusive behavior. If you wish to report such a violation, please keep language and cultural differences in mind.) 6. IRC policy violation (abuse of operator status in violation of policy on particular channel). 7. Disruptive behavior, IRC (Well, maybe. An example might be a running feud between two developers where the participants don't mind, but the cumulative effect is to make the channel unusable for others.) 8. QA dispute between developers. (One developer (or user) believes another has violated policy, and they cannot resolve their differences by normal means (discussion, appeal to project lead, etc.)) 9. QA violation, reported by QA. (QA believes developer has seriously violated policy but cannot resolve the issue with the developer directly.) This list is not necessarily complete, nor is everything on the list necessarily appropriate for reporting to devrel. But it should give some idea of the sorts of things that are helpful for briefly explaining why devrel has jurisdiction and to give a clue how the reporter wants the bug to be processed. > Otherwise... unpleasant subject matter, but I'm glad someone's dealing > with it. The rest seems reasonable enough. > > -- > 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 in > http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html > > -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
On Thu, 2006-01-12 at 11:23 +0200, Philippe Trottier wrote: > Make this distributed tool for tar zip bzip2 and gzip and I'm in, I don't > think > it would be useful with anything else than Gigabit Ethernet. app-arch/pbzip2 It covers only bzip2, but proves that it can be done. I tend to like it for catalyst, since it helps a lot on SMP machines. > We might want to have in the make.conf 2 separate variables, one of them > saying > how many threads can be run on the machine, then How many threads/process > across > a cluster. > > For example, my Dual Xeon EM64T file server can do make -j4 locally, like in > make install, make docs etc etc, But for compiling I can use -j20, really not > useful over -j8 anyway. But the point is, it would be usefully to separate > the > load distribution on the local machine and cluster nodes. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Re: RFC --- Thoughts on devrel bug content
Ferris McCormick posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 12 Jan 2006 13:59:43 +: > This list is not necessarily complete, nor is everything on the list > necessarily appropriate for reporting to devrel. But it should give some > idea of the sorts of things that are helpful for briefly explaining why > devrel has jurisdiction and to give a clue how the reporter wants the bug > to be processed. Thanks. That list at least provides a decent set of examples. When I read "jurisdiction", I thought the usual US/legal sense, as in courts ruling whether they have jurisdiction over a case or not, and my mind was boggling... I couldn't quite figure out how to boil such a concept down into the itemized list you were describing. The examples definitely help me get my mind around the concept you intended! I'd suggest putting at least one or two examples in whatever bug template or HOWTO might result from this, if the thing isn't made an itemized list as you suggested, anyway. I know I had a /terrible/ time figuring out Gentoo's bug system for regular bugs, and can easily envision myself having the same issues trying to fit square pegs into crescent-moon-shaped holes here, so some sort of guide is SURE to prove beneficial. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Parallizing ebuilds - 'trivial' ebuilds
Chris Gianelloni posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 12 Jan 2006 09:11:27 -0500: > app-arch/pbzip2 > > It covers only bzip2, but proves that it can be done. I tend to like it > for catalyst, since it helps a lot on SMP machines. Very cool! I didn't know that existed. It could be quite useful here on my dual Opteron. Thanks! -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Parallizing ebuilds - 'trivial' ebuilds
Duncan wrote: app-arch/pbzip2 It covers only bzip2, but proves that it can be done. I tend to like it for catalyst, since it helps a lot on SMP machines. Very cool! I didn't know that existed. It could be quite useful here on my dual Opteron. Thanks! For those who wondered what might be the purpose of that mail, re-read the last sentence with stress on the last three words. SCNR -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a plea for testing help
On Thu, Jan 12, 2006 at 01:41:41PM +0100, Jan Kundr?t wrote: > Greg KH wrote: > > And if someone wants to forward this over to -user, feel free. > > Do you want to have this kernel documented in our Kernel guide [1]? > > [1] http://www.gentoo.org/doc/en/gentoo-kernel.xml#doc_chap3 That would be great to have added there. In the "Unsupported kernels" section please. thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Conversion from kernel-mod.eclass to linux-mod/linux-info
Henrik Brix Andersen wrote: > Hi, > > As stated in bug #74396, all ebuilds using kernel-mod.eclass must be > converted to using either linux-mod.eclass and/or linux-info.eclass. > > The bug has been open since 2004-12-14, yet there are still ebuilds in > the tree which inherits kernel-mod.eclass: > > $ find . -name "*.ebuild"|xargs grep inherit|grep kernel-mod|cut -d '/' -f > 2,4|sed -e "s:\.ebuild.*::" > sci-misc/comedi-0.7.68 > sci-misc/comedi-0.7.67 > media-libs/svgalib-1.9.19-r3 > sys-apps/realtime-lsm-0.8.2_pre20041022 > sys-apps/realtime-lsm-0.8.3 > sys-apps/realtime-lsm-0.8.5 > sys-cluster/pvfs2-1.2.0 > sys-fs/cryptsetup-0.1 > media-sound/alsa-driver-1.0.3 > media-tv/linuxtv-dvb-1.1.1-r1 > media-tv/rivatv-0.8.5-r2 > > Apart from sci-misc/comedi and sys-cluster/pvfs2, the ebuilds all have > newer versions which have already been ported. If you maintain any of > these ebuilds, please see to it that the older versions which use > kernel-mod.eclass are either removed from the tree or updated to use > the new eclasses. > > Needless to say, the sci-misc/comedi and sys-cluster/pvfs2 needs to be > converted to use the new eclasses as well. The old kernel-mod.eclass > is not for use in new ebuilds. > > Regards, > Brix AFAIK, cryptsetup should be pulled in favor of cryptsetup-luks. I think everything uses luks now rather then cryptsetup. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Conversion from kernel-mod.eclass to linux-mod/linux-info
On Thu, 2006-01-12 at 11:45 -0500, Doug Goldstein wrote: > AFAIK, cryptsetup should be pulled in favor of cryptsetup-luks. I think > everything uses luks now rather then cryptsetup. We're still using cryptsetup on the InstallCD/LiveCD. Should we switch? What's the differences? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Conversion from kernel-mod.eclass to linux-mod/linux-info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 lo, On Thursday 12 January 2006 17:17, Chris Gianelloni wrote: > On Thu, 2006-01-12 at 11:45 -0500, Doug Goldstein wrote: > > AFAIK, cryptsetup should be pulled in favor of cryptsetup-luks. I think > > everything uses luks now rather then cryptsetup. > > We're still using cryptsetup on the InstallCD/LiveCD. Should we switch? > What's the differences? Where possible you should be using cryptsetup-luks over cryptsetup. I'm still of two minds about pulling it completely, but at this point cryptsetup-luks has its full functionality, is actively maintained, a drop in replacement and has the blessing of the original cryptsetup author. - -- Benjamin Smee (strerror) crypto/forensics/netmail/netmon -BEGIN PGP SIGNATURE- Version: GnuPG v1.9.19 (GNU/Linux) iD8DBQFDxpKpAEpm7USL54wRAmZJAJ9v6fWaRbIKX325AFKCvP1o2DF3TACeN3gb 0vWLoMgMFWAO4U7uaX+OVcs= =VQNJ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Conversion from kernel-mod.eclass to linux-mod/linux-info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 lo, On Thursday 12 January 2006 16:45, Doug Goldstein wrote: > AFAIK, cryptsetup should be pulled in favor of cryptsetup-luks. I think > everything uses luks now rather then cryptsetup. I know that the latest versions of gnome now are using cryptsetup-luks but I'm not 100% sure that all things are now pulling in cryptsetup-luks yet. Re the original post, I'll go and file a stabilize bug for the newer versions of cryptsetup I put in the tree a while back, they have fixed the kernel-mod usage and have been around for many months without bugs so I assume there is no problem with them. - -- Benjamin Smee (strerror) crypto/forensics/netmail/netmon -BEGIN PGP SIGNATURE- Version: GnuPG v1.9.19 (GNU/Linux) iD8DBQFDxpNtAEpm7USL54wRAsTQAJ9MYCP2CuqsLN83t6rqpjVd8PWOsACfaHSh KVWxzAXTa3mr+Mc31MiS8vc= =CEP9 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 13:42, Greg KH wrote: > On Thu, Jan 05, 2006 at 07:56:30AM -0500, Chris Gianelloni wrote: > > You guys are more than welcome to go apply at Red Hat or Novell. > > Some of us already work for companies that produce other Linux > distributions or support the companies that do. :) i know i would if i could get hired ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] packages without homepages
Matthias Langer <[EMAIL PROTECTED]> said: > After reading the response for bug 118607, which i filed, i was > woundering if there isn't a more appropriate default procedure for > packages with no homepages then just leaving the invalid 'homepage-link' > alone ... Shouldn't there be a way to tell portage that a certain > package simply doesn't have a homepage ? It'd be nice to get a decision on this. repoman complains, but the dev manual says that DESCRIPTION and HOMEPAGE are required (except in unique circumstances). I don't see why we can't just say they are always required. Something should _always_ have a description, and if a package has no HOMEPAGE, I think putting "none" in there is better than leaving it blank. I'm trying to go around and clean up all of the stuff repoman is complaining about, and there are quite a few of these, so I'd like to know how to handle them. We need to either make repoman not complain if HOMEPAGE="" is supposed to be valid, or put "none" in there if necessary. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpIvbIk9pjy8.pgp Description: PGP signature
[gentoo-dev] Gentoo Council Meeting Summary (20060112)
Monthly Gentoo Council Meeting for Jan 2006. Present: Koon (Thierry Carrez) Swift (Sven Vermeulen) agriffis (Aron Griffis) seemant (Seemant Kulleen) solar (Ned Ludd) vapier (Mike Frysinger) Absent: azarah (Martin Schlemmer) Where abouts unknown for the last 30 days. Attendance by non council members appeared to be rather low. Agenda: * GLEP 45 - GLEP date format * Disallowing council members to act as proxies for other council members. * Global gentoo goals for 2006 Outcome: * GLEP 45: As stated on the mailing lists minor changes to GLEP's and the GLEP process is best left in the hands of the GLEP editors. Everybody supported g2boojum's ability to decide. Otherwise we would of voted yes. * Disallowing council members to act as proxies for other council members. Status = Approved. * Global gentoo goals for 2006 This was mostly a brainstorming session covering such topics as should the council even be setting global goals, enterprise support, GRP, ebuild/profile/eclass and binpkg signing. -- solar <[EMAIL PROTECTED]> Gentoo Linux -:- Topic (#gentoo-council): changed by vapier: Meeting at 1900 UTC (1400 EST) || anybody seen azarah in the last month? 06:54PM where am I? 06:54PM :p 06:55PM batman anybody want to step up and chair this or open session today? 06:57PM i would but like i said, i'm prob gonna have to pop out early 06:59PM welp, by my clock, it's about that time eh 07:00PM i'm pretty sure az isnt going to show up -:- tove [EMAIL PROTECTED] has joined #gentoo-council 07:00PM Koon / seemant / solar / seemant / vapier 07:00PM who is awake ? check 07:01PM mate 07:01PM I am awake 07:02PM i'll assume Koon will wake shortly -:- kloeri_ [EMAIL PROTECTED]/developer/kloeri] has joined #gentoo-council * GLEP 45 - GLEP date format <-- ok this one. This is not even for us to decide on is it? The glep editors got that one covered right? 07:02PM yes, g2boojum is for it 07:02PM * SwifT/#gentoo-council doesn't mind at all 07:02PM and i'm pretty sure we'd all vote yes -:- NetSplit: irc.freenode.net split from zelazny.freenode.net [07:02pm] -:- BitchX: Press ^F to see who left ^E to change to [irc.freenode.net] 07:02PM it's not for us to decide, I should think 07:02PM stupid freenode -:- [Users(#gentoo-council:10)] [ kloeri_ ] [ tove ] [EMAIL PROTECTED] ] [EMAIL PROTECTED]] [ kallamej ] [vg2boojum ] [ FuzzyRay ] [EMAIL PROTECTED] ] [ spb ] [EMAIL PROTECTED] ] -:- Topic (#gentoo-council): Meeting at 1900 UTC (1400 EST) || anybody seen azarah in the last month? -:- Topic (#gentoo-council): set by vapier at Thu Jan 12 18:54:06 2006 07:02PM regarding chairing, sorry, just saw the e-mail. Perhaps next meeting who did we lose on that split? 07:03PM I support g2boojum's ability to decide that :) 07:03PM Koon -:- Koon [EMAIL PROTECTED]/developer/Koon] has joined #gentoo-council -:- mode/#gentoo-council [+o Koon] by ChanServ 07:03PM here he is ok next item is. * disallow multiple votes per person (from ciaranm) http://marc.theaimsgroup.com/?t=11346783302&r=1&w=2 07:04PM WFM 07:04PM wfm? 07:04PM the reasoning in that email is sound 07:04PM yes too 07:04PM so yes, wfm2 07:04PM isn't it Windows Meta Format or something? 07:04PM SwifT: works for me 07:04PM emerge wtf && wtf wfm 07:04PM oh, that 07:04PM yes, wfmaw 07:04PM pfft that isnt real 07:05PM you're just making s**t up 07:05PM brb phone 07:05PM have we all voted for that? 07:05PM (or a majority anyway) 07:05PM solar hasnt I dont see the point personally and what brought it up was I'm guessing me trying to cover for az last month. but if the majority want to put into effect thats ok. so yes 07:06PM you're so accommodating 07:06PM !alindeman:*! Hi all .. Regional server looks to be having some trouble; we're working to resolve it now next item is * global gentoo goals for 2006 07:06PM whee 07:06PM that thread went to garbage fast eh that we talked about a short bit in mail and said that global goals is not something that the council should decide. anybody have any input towards that subject? 07:08PM i dont think that's it 07:08PM so my followup question is: who's role is that to play? explain please 07:09PM !lilo:*! Problem with a temporary main rotation server; however, we'd removed it from the main rotation as soon as we could manage, and about 800 users were affected 07:09PM we cant just defer it, if we do we're saying "what Gentoo is now is good enough" 07:10PM no, but some people would like to see us 7 give the global direction where Gentoo is heading at 07:10PM which, frankly, will probably upset at least 7 other people :p 07:10PM however, if the council could work on keeping track of Gentoo's shortcomings and possible interesting areas, we can give a boost to new proposals 07:10PM well, not really "council" job, but someone has to :) 07:11PM that seems feasible 07:11PM previously, the gentoo managers did that a bit 07:11PM honestly, that
