Re: [gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
Le 05/12/2008 05:33, Joe Peterson a écrit : How about "PORTAGE_JOBS" to go along with "PORTAGE_OVERLAY", "PORTAGE_NICENESS", etc. While this part of the thread has a lot of bikeshedding potential, Joe's name sounds more consistent with what we already have. Naming issues appart, it's a good idea. +1 from me :) Rémi
Re: [gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
Diego 'Flameeyes' Pettenò wrote: > "Alec Warner" <[EMAIL PROTECTED]> writes: > >> Looks Good To Me, but I would prefix the JOBS variable with some sort >> of namespace (EJOBS, GENTOO_JOBS, etc.) to avoid conflicts with other >> systems that may use JOBS internally already (seems vaguely likely). > > Good point, GENTOO_JOBS sounds good to me. How about "PORTAGE_JOBS" to go along with "PORTAGE_OVERLAY", "PORTAGE_NICENESS", etc. -Joe
[gentoo-dev] Re: Soliciting news items to test GLEP 42 support in sys-apps/portage-2.1.6_rc
On Thu, 04 Dec 2008 12:12:58 -0800 Zac Medico <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > The GLEP 42 news support [1] is going to be available in stable when > sys-apps/portage-2.1.6 is marked stable later this month. I think > the news code is pretty well tested already, but it would be nice to > deploy some news items in order to get some additional testing. If > you have any ideas for news items then please go ahead an propose > them soon so that we can deploy them. > > [1] http://www.gentoo.org/proj/en/glep/glep-0042.html > - -- > Thanks, > Zac I'd like to suggest the obiligatory news item about portage now having support for news items. :) -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] net-misc/arpstar facing removal
It's unmaintained and broken against recent kernels. It would be nice if someone could step up and replace it by adding and maintaining a package for arpon: http://arpon.sourceforge.net/ which I guess it not a kernel module, yay I'm planning to add arpstar to package.mask on December 11th, and remove from tree at the end of the month. Daniel
[gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
"Alec Warner" <[EMAIL PROTECTED]> writes: > Looks Good To Me, but I would prefix the JOBS variable with some sort > of namespace (EJOBS, GENTOO_JOBS, etc.) to avoid conflicts with other > systems that may use JOBS internally already (seems vaguely likely). Good point, GENTOO_JOBS sounds good to me. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp8ZBisU9A7b.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
On Thu, Dec 4, 2008 at 12:29 PM, Diego 'Flameeyes' Pettenò
<[EMAIL PROTECTED]> wrote:
>
> Since not all the buildsystem we support use make for the actual build,
> and they don't necessarily support make-like options (-jX -s and so on),
> it would be nice to be able to express a JOBS variable that could be
> used for parallel build with any build systems.
>
> Right now there are ebuilds like openoffice or some scons-based ebuilds
> that parse MAKEOPTS and get out of that the number of jobs from the -j
> option, but this is a) suboptimal b) error-prone.
>
> One has to consider people might be using -l for parallel building too,
> for which reasons I'd be suggesting doing something like this to make
> the change transparent:
>
> - ebuilds using non-make build systems would use JOBS;
> - ebuilds using make builds systems would just use emake as usual;
> - Portage takes care, if JOBS is unset, to parse it out of MAKEOPTS;
> - if user has set JOBS but not MAKEOPTS this defaults to -j${JOBS};
> - if user has JOBS and MAKEOPTS, MAKEOPTS keeps the same (for -l).
>
> The result is that you can finally combine -l with parallel build on
> OpenOffice and other packages, with a fallback number of maximum jobs
> instead of using load-based decisions.
Looks Good To Me, but I would prefix the JOBS variable with some sort
of namespace (EJOBS, GENTOO_JOBS, etc.) to avoid conflicts with other
systems that may use JOBS internally already (seems vaguely likely).
-Alec
>
> --
> Diego "Flameeyes" Pettenò
> http://blog.flameeyes.eu/
>
>
[gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
Tiziano Müller <[EMAIL PROTECTED]> writes: > What do you do for other build systems which also decide on load-basis > how many jobs to run? Parse again? > In that case I'd like to see a more abstract definition of "how many > jobs to run in parallel" which gets translated to the correct > make-options for emake and which is query'able either via a variable or > a function (something like JOBS="load=0.7||max=3" maybe?). If you can come up with a good enough syntax. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp0CultBim8Q.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
Diego 'Flameeyes' =?utf-8?Q?Petten=C3=B2?= wrote:
>
> Since not all the buildsystem we support use make for the actual build,
> and they don't necessarily support make-like options (-jX -s and so on),
> it would be nice to be able to express a JOBS variable that could be
> used for parallel build with any build systems.
>
> Right now there are ebuilds like openoffice or some scons-based ebuilds
> that parse MAKEOPTS and get out of that the number of jobs from the -j
> option, but this is a) suboptimal b) error-prone.
>
> One has to consider people might be using -l for parallel building too,
> for which reasons I'd be suggesting doing something like this to make
> the change transparent:
>
> - ebuilds using non-make build systems would use JOBS;
> - ebuilds using make builds systems would just use emake as usual;
> - Portage takes care, if JOBS is unset, to parse it out of MAKEOPTS;
> - if user has set JOBS but not MAKEOPTS this defaults to -j${JOBS};
> - if user has JOBS and MAKEOPTS, MAKEOPTS keeps the same (for -l).
>
> The result is that you can finally combine -l with parallel build on
> OpenOffice and other packages, with a fallback number of maximum jobs
> instead of using load-based decisions.
Sounds good for me.
What do you do for other build systems which also decide on load-basis
how many jobs to run? Parse again?
In that case I'd like to see a more abstract definition of "how many
jobs to run in parallel" which gets translated to the correct
make-options for emake and which is query'able either via a variable or
a function (something like JOBS="load=0.7||max=3" maybe?).
Re: [gentoo-dev] [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
On 4-12-2008 21:29, Diego 'Flameeyes' Pettenò wrote: One has to consider people might be using -l for parallel building too, I'd have it in a separate variable as well, IFF another build system is as nice as make towards parallel build. lu
[gentoo-dev] [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
Since not all the buildsystem we support use make for the actual build,
and they don't necessarily support make-like options (-jX -s and so on),
it would be nice to be able to express a JOBS variable that could be
used for parallel build with any build systems.
Right now there are ebuilds like openoffice or some scons-based ebuilds
that parse MAKEOPTS and get out of that the number of jobs from the -j
option, but this is a) suboptimal b) error-prone.
One has to consider people might be using -l for parallel building too,
for which reasons I'd be suggesting doing something like this to make
the change transparent:
- ebuilds using non-make build systems would use JOBS;
- ebuilds using make builds systems would just use emake as usual;
- Portage takes care, if JOBS is unset, to parse it out of MAKEOPTS;
- if user has set JOBS but not MAKEOPTS this defaults to -j${JOBS};
- if user has JOBS and MAKEOPTS, MAKEOPTS keeps the same (for -l).
The result is that you can finally combine -l with parallel build on
OpenOffice and other packages, with a fallback number of maximum jobs
instead of using load-based decisions.
--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
pgpcOEYmHztqL.pgp
Description: PGP signature
[gentoo-dev] Soliciting news items to test GLEP 42 support in sys-apps/portage-2.1.6_rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The GLEP 42 news support [1] is going to be available in stable when sys-apps/portage-2.1.6 is marked stable later this month. I think the news code is pretty well tested already, but it would be nice to deploy some news items in order to get some additional testing. If you have any ideas for news items then please go ahead an propose them soon so that we can deploy them. [1] http://www.gentoo.org/proj/en/glep/glep-0042.html - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk4OckACgkQ/ejvha5XGaN/2gCg5G6ahw5z0Chg4jIlp93ks8GK REkAn2Gymsmmjus+/+/R+/tH1tW3MSPK =6vRj -END PGP SIGNATURE-
[gentoo-dev] Adding QEMU_TARGETS to USE_EXPAND
Since I'm planning to revamp the qemu ebuilds and provide a more flexible way to pick which targets get built since most of the interesting one are already supported by tcg thus building with gcc4 just fine, I'd merge back softmmu and user and export the available targets this way. lu
[gentoo-dev] Last rites: net-misc/nxclient-2xterminalserver and net-misc/nxserver-2xterminalserver
They will be moved to the NX overlay in one month # Bernard Cafarelli <[EMAIL PROTECTED]> (04 Dec 2008) # Masked for removal in 30 days (bug #249799) # * Upstream closed web site and source downloads # * No updates since first release 2 years ago # * Still based on old NX 1.5 code, missing features and being mostly # incompatible with current NX servers/clients # * Client does not compile with gcc4.3 or --as-needed (bug #248138). # * Server includes old, unpatched xorg sources, probably vulnerable to GLSA # 200710-09 and 200804-05. # * GPL alternatives exist: net-misc/qtnx, net-misc/nxserver-freenx net-misc/nxclient-2xterminalserver net-misc/nxserver-2xterminalserver -- Bernard Cafarelli (Voyageur) Gentoo developer (NX, GNUstep, net-misc, ...)
Re: [gentoo-dev] Looking for help with kernel maintenance
Daniel Drake wrote: Hi, I'm looking to find one or more people to help out with gentoo-sources-2.6 maintenance (our primary supported kernel). Thanks to this thread and the GMN, the response in my inbox has been positively overwhelming. I responded to everybody until a point, and was pleasantly surprised at how many people actually followed through with interest and enthusiasm (#gentoo-kernel is buzzing with new faces!!) Anyway, I don't believe there are ever too many kernel maintainers, but the model I'm using is getting people to ask lots of questions and there are only so many people me and Mike can work with at once. So, I'm temporarily withdrawing this request for help while we get the current respondents more and more involved to the point where they can start answering their own questions. But feel free to email me anyway and I'll add you to the list of people we contact when we have more capacity again. Daniel
[gentoo-dev] Gentoo council voting - ~36 hours left
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. This is a final warning that if you are an eligible voter you have ~36 hours left to cast your vote - before 00H00 UTC Saturday 6th Dec. At this point, we have *57* submitted votes from the *245* eligible voters - which means a turnout of around 23.3%!!. If you want a saying in this election, don't forget to *vote*, preferably *now*! ;) - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk3vboACgkQcAWygvVEyAJg0ACfRik+x8BGVactZyanSGW7G01a Pf8An3CiNC/a2cH5nTYwenZNvonsq+C/ =6VBr -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Gentoo Council nominations are now closed
Donnie Berkholz wrote: > On 10:02 Sat 29 Nov , Mauricio Lima Pilla wrote: >> What are the nominees intending to do if they are elected? I miss the >> manifests. > > To those of you telling us to look at what you do now, what you're > saying is that you're good in your current role. That doesn't support > why you would be good in a different role as a council member. > > In other words, writing good code doesn't make you good at everything in > Gentoo. It doesn't mean you would make a good docs writer, a good devrel > member, a good trustee, or a good council member. They all involve > different activities or different levels of thought. > > All I'd like to hear is the same thing I'd want from a job candidate -- > what makes you uniquely qualified? We have plenty of technically good > developers running, so that doesn't exactly differentiate you. > > What is your vision for what the council should do? How about what > Gentoo should do? How would you make it happen? > My first priority within the first two months would be to overhaul the documents describing Gentoo's structure (GLEP 39 for example) and to clarify and write down important procedures (like voting, etc.). Even if this is boring work I think it is important for the future since it will help to avoid unnessecary discussions which cost a lot of energy and time, which is better used to develop new things. After that I'd like to do something about our communication problems (yes, we have one): We definetely have to do something about our website and we have to give users more information on what we're doing, why we're doing it and where they can get involved. Donnie made a good start once by posting more news to the front page but he can't be the only one. (Convincing project leads to write a summary from time to time for example.) Also, the gentoo-dev mailinglist did see more activity in the past. Maybe all developers currently not reading the list could rejoin so we can actually discuss new ideas again with (almost) every developer involved. >From the technical side I'd like to change metadata.xml even further (see my proposals), push projects trying to automate version bump detection, bug-assigning, etc. (most of the boring tasks) and tree signing to help developers focus on the interesting stuff. That's it (more or less), you can also read my manifest (http://www.gentoo.org/proj/en/council/voting-logs/nominees/2008/dev-zero.txt) or my blog entry (currently only on planet.gentoo.org). ... and don't forget to vote for me if you like the mentioned ideas :-) Cheers, Tiziano
Re: [gentoo-dev] A tool helps to diff and override config files
Thanks Josh. I will look at "cfg-update". Best Regards. 2008/12/4 Josh Saddler <[EMAIL PROTECTED]> > Song Ma wrote: > > I tried "dispatch-conf" and "etc-update". Here are two major differences > > from my tool: > > > > 1. For desktop user, my tool will invoke GUI based "kdiff3" to do diff > > and merge files if the user installed the "kdiff3". And for remote login > > user or the user without "kdiff3", the tool will just get the normal > > text-base diff. > > > > 2. My tool can override multiple config files in batch mode. Although > > this is dangerous, sometime it's useful and not so nagging. > > You need to look at cfg-update, which has gtk+ and qt+ interfaces. And > is arguably less dangerous. > > Better yet, just look around in the app-portage category; there are lots > of config file update tools, in addition to the excellent ones already > present in Portage. > > You also need to read the Portage handbook. It explains the built-in > update tools: > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=4 > > >
Re: [gentoo-dev] A tool helps to diff and override config files
Song Ma wrote: > I tried "dispatch-conf" and "etc-update". Here are two major differences > from my tool: > > 1. For desktop user, my tool will invoke GUI based "kdiff3" to do diff > and merge files if the user installed the "kdiff3". And for remote login > user or the user without "kdiff3", the tool will just get the normal > text-base diff. > > 2. My tool can override multiple config files in batch mode. Although > this is dangerous, sometime it's useful and not so nagging. You need to look at cfg-update, which has gtk+ and qt+ interfaces. And is arguably less dangerous. Better yet, just look around in the app-portage category; there are lots of config file update tools, in addition to the excellent ones already present in Portage. You also need to read the Portage handbook. It explains the built-in update tools: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=4 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A tool helps to diff and override config files
I tried "dispatch-conf" and "etc-update". Here are two major differences from my tool: 1. For desktop user, my tool will invoke GUI based "kdiff3" to do diff and merge files if the user installed the "kdiff3". And for remote login user or the user without "kdiff3", the tool will just get the normal text-base diff. 2. My tool can override multiple config files in batch mode. Although this is dangerous, sometime it's useful and not so nagging. Best Regards, Song Ma 2008/12/4 Song Ma <[EMAIL PROTECTED]> > Thanks guys. I didn't realize there are such tools existed already. > > 2008/12/4 Cheng Renquan <[EMAIL PROTECTED]> > > On Thu, Dec 4, 2008 at 4:34 PM, Song Ma <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > With Gentoo if the user runs "emerge --update --newuse --deep world", >> the >> > config file under "/etc" may be updated and get the new config file >> named as >> > "._cfg_", for example, "._cfg_ntp.conf". Normally I will >> > compare this newly updated config file with my existing one, then decide >> if >> > I am going to override the existing one with new one or discard the new >> one >> > since I must keep my existing setting. It is not very efficient to do >> these >> > actions with command lines such as "diff", "cp" or "mv" one by one. I >> wrote >> > a tool with text menu to help Gentoo user compare and copy new the new >> > config file conveniently. Does anyone have interest about it? What >> should I >> > do if I want to make it open source and maintain it for Gentoo users? >> >> Why not use dispatch-conf ? >> >> > >> > A screen shot for the tool use: >> > >> > >> >> >> >> -- >> Cheng Renquan, Shenzhen, China >> Bob Dole - "The internet is a great way to get on the net." >> >> >
Re: [gentoo-dev] A tool helps to diff and override config files
Thanks guys. I didn't realize there are such tools existed already. 2008/12/4 Cheng Renquan <[EMAIL PROTECTED]> > On Thu, Dec 4, 2008 at 4:34 PM, Song Ma <[EMAIL PROTECTED]> wrote: > > Hi, > > > > With Gentoo if the user runs "emerge --update --newuse --deep world", the > > config file under "/etc" may be updated and get the new config file named > as > > "._cfg_", for example, "._cfg_ntp.conf". Normally I will > > compare this newly updated config file with my existing one, then decide > if > > I am going to override the existing one with new one or discard the new > one > > since I must keep my existing setting. It is not very efficient to do > these > > actions with command lines such as "diff", "cp" or "mv" one by one. I > wrote > > a tool with text menu to help Gentoo user compare and copy new the new > > config file conveniently. Does anyone have interest about it? What should > I > > do if I want to make it open source and maintain it for Gentoo users? > > Why not use dispatch-conf ? > > > > > A screen shot for the tool use: > > > > > > > > -- > Cheng Renquan, Shenzhen, China > Bob Dole - "The internet is a great way to get on the net." > >
Re: [gentoo-dev] A tool helps to diff and override config files
On Thu, Dec 4, 2008 at 4:34 PM, Song Ma <[EMAIL PROTECTED]> wrote: > Hi, > > With Gentoo if the user runs "emerge --update --newuse --deep world", the > config file under "/etc" may be updated and get the new config file named as > "._cfg_", for example, "._cfg_ntp.conf". Normally I will > compare this newly updated config file with my existing one, then decide if > I am going to override the existing one with new one or discard the new one > since I must keep my existing setting. It is not very efficient to do these > actions with command lines such as "diff", "cp" or "mv" one by one. I wrote > a tool with text menu to help Gentoo user compare and copy new the new > config file conveniently. Does anyone have interest about it? What should I > do if I want to make it open source and maintain it for Gentoo users? Why not use dispatch-conf ? > > A screen shot for the tool use: > > -- Cheng Renquan, Shenzhen, China Bob Dole - "The internet is a great way to get on the net."
Re: [gentoo-dev] A tool helps to diff and override config files
2008/12/4 Song Ma <[EMAIL PROTECTED]>: > Hi, > > With Gentoo if the user runs "emerge --update --newuse --deep world", the > config file under "/etc" may be updated and get the new config file named as > "._cfg_", for example, "._cfg_ntp.conf". Normally I will > compare this newly updated config file with my existing one, then decide if > I am going to override the existing one with new one or discard the new one > since I must keep my existing setting. It is not very efficient to do these > actions with command lines such as "diff", "cp" or "mv" one by one. I wrote > a tool with text menu to help Gentoo user compare and copy new the new > config file conveniently. Does anyone have interest about it? What should I > do if I want to make it open source and maintain it for Gentoo users? > > A screen shot for the tool use: > > Why reinventing the wheel? What about using existing tools with much more functionality like etc-update, dispatch-conf, cfg-update or etc-proposals? -- Regards, Daniel
[gentoo-dev] A tool helps to diff and override config files
Hi, With Gentoo if the user runs "emerge --update --newuse --deep world", the config file under "/etc" may be updated and get the new config file named as "._cfg_", for example, "._cfg_ntp.conf". Normally I will compare this newly updated config file with my existing one, then decide if I am going to override the existing one with new one or discard the new one since I must keep my existing setting. It is not very efficient to do these actions with command lines such as "diff", "cp" or "mv" one by one. I wrote a tool with text menu to help Gentoo user compare and copy new the new config file conveniently. Does anyone have interest about it? What should I do if I want to make it open source and maintain it for Gentoo users? A screen shot for the tool use: <>
