Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On Mon, 21 Jan 2013 13:27:18 +0800 Ben de Groot wrote: > On 21 January 2013 12:16, Peter Stuge wrote: > > Panagiotis Christopoulos wrote: > >> I don't build server machines every day, others do and it would be > >> much appreciated if they could respond here. > > > > I build catalyst stage4s. Any default profiles are kindof pointless > > for me; I have USE=-* and the flags that I want. > > > > Anything else seems a bit too random. > > This is why I think we do need something like a truly minimal profile > to start building from. Too many people are doing this. > -* will still be required by those same people for EAPI 1 package defaults. Cleaning a profile won't change that. signature.asc Description: PGP signature
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sun, 2013-01-20 at 18:03 +0100, Chí-Thanh Christopher Nguyễn wrote: > We can either set it in the base profile, then there is no need for > IUSE="+dri". Or we can set it in every single ebuild that has the dri > flag. I prefer the former because it reduces our maintenance burden. You make it sound like these two options are equivalent, but I don't think they are. Setting the option in the profile tells me: "Here's this option you can play with, and we think you might need it. Or not." Setting the option in the ebuild tells me: "You know, we are nice and give you this option, but really you should keep this turned on. Really." >From the descriptions it sounds like you want the latter effect, and thus use IUSE="+dri". This would also help all the people starting out with "-*". Hans
Re: [gentoo-dev] About dropping ppc-kernel herd
Pozdrawiam/Best regards Tomasz Kondzioła Dnia 20 sty 2013 o godz. 10:26 Pacho Ramos napisał(a): > Looks like no package is included in it, I think we should drop that > herd then > > Do you agree? >
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-client/claws-mail-rssyl: ChangeLog claws-mail-rssyl-0.34.ebuild
On Sun, 20 Jan 2013 21:56:35 + (UTC) "Christian Faulhammer (fauli)" wrote: > fauli 13/01/20 21:56:35 > > Modified: ChangeLog > Removed: claws-mail-rssyl-0.34.ebuild > Log: > clean up I'm guessing you meant to remove the old 0.33 ebuild, not the newly stabilized one. :p -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On 21 January 2013 12:16, Peter Stuge wrote: > Panagiotis Christopoulos wrote: >> I don't build server machines every day, others do and it would be >> much appreciated if they could respond here. > > I build catalyst stage4s. Any default profiles are kindof pointless > for me; I have USE=-* and the flags that I want. > > Anything else seems a bit too random. This is why I think we do need something like a truly minimal profile to start building from. Too many people are doing this. > > Ben, binary distributions like debian without cups? Forget about it. > They can't manage two differently compiled binary packages of e.g. > samba, so guess if they will have a samba without printing support? ;) I know, I am an idealist. Guess why I keep coming back to Gentoo... -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: USE flags dri, cups, pppd
On 21 January 2013 10:42, Duncan <1i5t5.dun...@cox.net> wrote: > So that's what I (and others, but less explicitly) propose, leaving > USE=dri where it is in the old and soon-to-be-deprecated 10.x profiles so > nobody gets broken, while in the new 13.0 profiles, USE=dri is moved from > base to desktop. That way, it'll still be defaulted on for desktop where > most people will want it, but won't appear in the new base, thus > eliminating the pollution for people unlikely to care about it, there. > And the only possibility for breakage will be with the profile upgrade, > when people should expect and thus be prepared to deal with a bit of > config change. No, that doesn't seem the best way to do this. There are lots of users who stick with the base profile but do install X. They *need* to have dri enabled, unless they *really* know what they are doing. So, it either needs to stay in the base profile, as it has been up till now, or it needs to be set as default (IUSE="+dri") in the specific packages. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Separately buildable binary blobs
Doug Goldstein wrote: > we go through the effort to ALLOW users to build their own binary > blobs but is it really necessary as part of our culture? I don't think that question can be answered? The way I see it either someone maintains those packages, or not. I'd be sad to see them go, but am not a dev so can not do anything about it. //Peter
Re: [gentoo-dev] Separately buildable binary blobs
On Sun, Jan 20, 2013 at 10:45 PM, Peter Stuge wrote: > Doug Goldstein wrote: >> sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios, >> sys-firmware/vgabios > .. >> So basically, how important is it to keep supporting these separately >> buildable blobs knowing that it might slow the release of QEMU within >> our own tree. > > Each of those sys-firmware/ packages have quite significant use cases > well outside of QEMU. Aware of that, but no one added them to the tree prior to me adding them to the tree for QEMU. Since then I haven't had a single user report a bug or contact me in any way about using it outside of QEMU. The one exception is myself with ipxe as I use that at work to provide something similar to boot.fedoraproject.org but on a much grander scale. > > Note also that in particular SeaBIOS but possibly the others too are > really recommended to build with a separate, known-good, toolchain - > even if you're building for the same platform that you run on. Aware of that as well, you'll notice we have always defaulted to using pre-built binaries of the releases by Kevin O'Connor the upstream maintainer and for any bugs reported with QEMU if someone built their own BIOS I always tell them they need to try with the upstream blob. The point of my original post was we go through the effort to ALLOW users to build their own binary blobs but is it really necessary as part of our culture? If this was Debian the answer would obviously be yes. -- Doug Goldstein
Re: [gentoo-dev] Separately buildable binary blobs
Doug Goldstein wrote: > sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios, > sys-firmware/vgabios .. > So basically, how important is it to keep supporting these separately > buildable blobs knowing that it might slow the release of QEMU within > our own tree. Each of those sys-firmware/ packages have quite significant use cases well outside of QEMU. Note also that in particular SeaBIOS but possibly the others too are really recommended to build with a separate, known-good, toolchain - even if you're building for the same platform that you run on. The buildgcc[1] script from coreboot generates such a toolchain. USE=vanilla gcc+binutils may or may not work. I have certainly experienced USE=-vanilla gcc+binutils output broken machine code for coreboot and SeaBIOS. I have been unable to take time to investigate and report those breakages anywhere so they may still output broken machine code because of whatever patches. //Peter [1] http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/crossgcc
[gentoo-dev] Re: About dropping mips-kernel herd
On 01/20/2013 4:23 AM, Pacho Ramos wrote: > Looks like no package is included in it, I think we should drop that > herd then > > Do you agree? Yeah, I am the only maintainer of mips-sources anyways. Any problems with that package should go to me or the mips herd direct. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
Panagiotis Christopoulos wrote: > I don't build server machines every day, others do and it would be > much appreciated if they could respond here. I build catalyst stage4s. Any default profiles are kindof pointless for me; I have USE=-* and the flags that I want. Anything else seems a bit too random. I haven't yet experimented with creating my own profiles. I might still. Ben, binary distributions like debian without cups? Forget about it. They can't manage two differently compiled binary packages of e.g. samba, so guess if they will have a samba without printing support? ;) //Peter pgpflDxc5R_rc.pgp Description: PGP signature
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
On Sun, Jan 20, 2013 at 6:28 PM, Peter Stuge wrote: > Alec Warner wrote: > [..removed 25 lines of quoted text which I had already read..] >> The primary complaint was the fact that there is too much email. > > Many emails are not neccessarily a problem if only they have high > signal-to-noise ratio. > > I have *never* seen so competent people output so incompetent email > as on gentoo-dev. It is seriously the worst bunch of lazy-ass email > authors that I have ever seen. Sad face. Well if you compare to say ubuntu-devel (which I recently joined) you will find far fewer conversations there. I think part of that reason is just that they have a more direct management structure. Leads have the ability to make decisions without consulting *everyone*. We seemed to have ditched the idea of leads long ago; except for a few remaining projects. -A > > That is of course only *my* opinion. > > > //Peter >
[gentoo-dev] Re: USE flags dri, cups, pppd
Ciaran McCreesh posted on Sun, 20 Jan 2013 22:00:20 + as excerpted: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sun, 20 Jan 2013 16:59:24 -0500 "Rick \"Zero_Chaos\" Farina" > wrote: >> chithanh, maybe you can explain to everyone why USE=dri is needed for >> base profile. You seem to be the most knowledgable here, can you cite >> a specific example for how/why a non-desktop profile machine would need >> USE=dri. I think that the example may make it more obvious to people >> what is right or wrong here. > > Your question is the wrong one to ask. What you should ask is whether a > non-desktop profile machine *would be in any way affected by* USE=dri. Exactly so. equery h -p dri ... returns, with a single exception, only x11-drivers/xf86-video-* xorg graphics driver packages. The single exception is x11-libs/libvdpau. So the only way the status of USE=dri even /matters/ is if one of those graphics drivers or that vdpau library is installed. And for those packages, USE=+dri is the best default, regardless of whether they're installed for some reason on a server, or on a desktop. Nothing else cares. That said, there IS the argument for eliminating USE flag pollution in profiles where they aren't likely to be used in any case. For the server non-X-installed server case, just having the flag there means time out of every responsible server admin's life, just to figure out that the flag is simply noise they don't have to worry about, and from this point of view, shouldn't even be seeing. I mean, while it's technically true that a USE flag not actually used by any packages won't make a difference, that logic, taken to its conclusion, would lead to every USE flag ever used by a single package showing up in both global USE and in profiles, since the claim is that it doesn't make a difference if no installed package uses the flag anyway, but we REALLY REALLY need a default, just in case you DO decide to install the one obscure package that actually DOES use the flag! So were we starting fresh, the best case would be to put the dri USE flag in the desktop profile, instead of in base, simply to avoid the USE flag noise pollution in non-desktop profiles. However, the argument here is that we're not starting fresh, and changing it now could break a lot of users. But I think those supporting that argument may have lost sight of the context: The context is the new 13.0 profiles, and from all I've seen (Dale can back me up as he's far more involved on the user lists and forums), users switching/upgrading profiles generally /expect/ to have a few config changes they might need to deal with. Thus, while the flag arguably shouldn't be changed in the old soon-to-be-deprecated 10.x profiles to avoid breaking people, the new 13.0 profiles are a chance to cleanup that USE flag pollution -- likely the best chance we're going to get for a few years. So that's what I (and others, but less explicitly) propose, leaving USE=dri where it is in the old and soon-to-be-deprecated 10.x profiles so nobody gets broken, while in the new 13.0 profiles, USE=dri is moved from base to desktop. That way, it'll still be defaulted on for desktop where most people will want it, but won't appear in the new base, thus eliminating the pollution for people unlikely to care about it, there. And the only possibility for breakage will be with the profile upgrade, when people should expect and thus be prepared to deal with a bit of config change. -- 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
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
Alec Warner wrote: [..removed 25 lines of quoted text which I had already read..] > The primary complaint was the fact that there is too much email. Many emails are not neccessarily a problem if only they have high signal-to-noise ratio. I have *never* seen so competent people output so incompetent email as on gentoo-dev. It is seriously the worst bunch of lazy-ass email authors that I have ever seen. Sad face. That is of course only *my* opinion. //Peter
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Sun, Jan 20, 2013 at 3:01 PM, Thomas Sachau wrote: > So you want to re-implement multilib-portage in an eclass without the > additional benefits a package-manager level implementation has? I really wish you'd just make the PMS diff and get your stuff implemented. How long has it been?
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-01-20 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-01-20 23h59 UTC. Removals: media-gfx/opencolorio 2013-01-16 05:57:48 pinkbyte dev-util/nvidia-cuda-npp2013-01-17 10:14:37 jlec virtual/pcmcia 2013-01-19 21:47:01 ssuominen Additions: games-engines/residualvm2013-01-14 18:35:28 hasufell profiles/eapi-5-files 2013-01-14 20:47:01 dilfridge dev-libs/libcdio-paranoia 2013-01-15 19:09:19 ssuominen app-admin/eselect-cdparanoia2013-01-15 20:53:26 ssuominen app-admin/eselect-mpg1232013-01-15 21:42:33 ssuominen profiles/default/linux/amd642013-01-15 23:07:59 dilfridge profiles/default/linux/arm 2013-01-15 23:26:02 dilfridge media-libs/opencolorio 2013-01-16 05:47:02 pinkbyte profiles/default/linux/ia64 2013-01-16 21:45:20 dilfridge profiles/default/linux/m68k 2013-01-16 21:53:25 dilfridge profiles/default/linux/mips 2013-01-16 22:14:07 dilfridge profiles/default/linux/powerpc 2013-01-16 22:32:56 dilfridge dev-db/pgxnclient 2013-01-17 07:36:31 patrick dev-python/jsonpointer 2013-01-17 17:04:22 prometheanfire dev-python/jsonpatch2013-01-17 17:13:33 prometheanfire dev-python/warlock 2013-01-17 17:25:38 prometheanfire dev-python/python-glanceclient 2013-01-17 17:30:41 prometheanfire games-action/trosh 2013-01-17 21:40:07 hasufell dev-libs/libRocket 2013-01-18 18:40:21 hasufell profiles/default/linux/s390 2013-01-18 19:35:08 dilfridge profiles/default/linux/sh 2013-01-18 19:40:43 dilfridge profiles/default/linux/sparc2013-01-18 19:48:22 dilfridge profiles/default/linux/x86 2013-01-18 19:55:05 dilfridge dev-libs/angelscript2013-01-18 20:46:44 hasufell app-doc/devmanual 2013-01-19 10:36:17 hwoarang app-admin/glance2013-01-20 06:39:20 prometheanfire media-plugins/gst-plugins-ivorbis 2013-01-20 17:51:36 eva dev-python/PyGithub 2013-01-20 20:23:26 floppym dev-util/cligh 2013-01-20 20:47:15 floppym dev-games/t4k-common2013-01-20 21:50:12 hasufell -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-gfx/opencolorio,removed,pinkbyte,2013-01-16 05:57:48 dev-util/nvidia-cuda-npp,removed,jlec,2013-01-17 10:14:37 virtual/pcmcia,removed,ssuominen,2013-01-19 21:47:01 Added Packages: games-engines/residualvm,added,hasufell,2013-01-14 18:35:28 profiles/eapi-5-files,added,dilfridge,2013-01-14 20:47:01 dev-libs/libcdio-paranoia,added,ssuominen,2013-01-15 19:09:19 app-admin/eselect-cdparanoia,added,ssuominen,2013-01-15 20:53:26 app-admin/eselect-mpg123,added,ssuominen,2013-01-15 21:42:33 profiles/default/linux/amd64,added,dilfridge,2013-01-15 23:07:59 profiles/default/linux/arm,added,dilfridge,2013-01-15 23:26:02 media-libs/opencolorio,added,pinkbyte,2013-01-16 05:47:02 profiles/default/linux/ia64,added,dilfridge,2013-01-16 21:45:20 profiles/default/linux/m68k,added,dilfridge,2013-01-16 21:53:25 profiles/default/linux/mips,added,dilfridge,2013-01-16 22:14:07 profiles/default/linux/powerpc,added,dilfridge,2013-01-16 22:32:56 dev-db/pgxnclient,added,patrick,2013-01-17 07:36:31 dev-python/jsonpointer,added,prometheanfire,2013-01-17 17:04:22 dev-python/jsonpatch,added,prometheanfire,2013-01-17 17:13:33 dev-python/warlock,added,prometheanfire,2013-01-17 17:25:38 dev-python/python-glanceclient,added,prometheanfire,2013-01-17 17:30:41 games-action/trosh,added,hasufell,2013-01-17 21:40:07 dev-libs/libRocket,added,hasufell,2013-01-18 18:40:21 profiles/default/linux/s390,added,dilfridge,2013-01-18 19:35:08 profiles/default/linux/sh,added,dilfridge,2013-01-18 19:40:43 profiles/default/linux/sparc,added,dilfridge,2013-01-18 19:48:22 profiles/default/linux/x86,added,dilfridge,2013-01-18 19:55:05 dev-libs/angelscript,added,hasufell,2013-01-18 20:46:44 app-doc/devmanual,added,hwoarang,2013-01-19 10:36:17 app-admin/glance,added,prometheanfire,2013-01-20 06:39:20 media-plugins/gst-plugins-ivorbis,added,eva,2013-01-20 17:51:36 dev-python/PyGithub,added,floppym,2013-01-20 20:23:26 dev-util/cligh,added,floppym,2013-01-20 20:47:15 dev-games/t4k-common,added,hasufell,2013-01-20 21:50:12 Done.
Re: [gentoo-dev] USE flags dri, cups, pppd
> "AWS" == Aaron W Swenson writes:
AWS> That's why there's a base desktop profile and desktop/{gnome,kde}
AWS> profiles.
/usr/portage/profiles/targets/desktop/make.defaults still has too much
crap for a real base profile for a box which (might) run X or wl.
Also, I suspect the things dri brings in (or that one would presume dri
to bring in) are needed for gpGPU and the like.
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
Thomas Sachau schrieb: > So you want to re-implement multilib-portage in an eclass without the > additional benefits a package-manager level implementation has? Once the package-manager level implementation becomes available in g-x86 then we can switch to it. If something in the proposed changes makes the PM implementation harder or causes additional work, please point this out so it can be addressed. Personally I wouldn't mind waiting until the next council meeting and keep all changes in the x11 overlay until then. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
Gilles Dartiguelongue schrieb: > Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit : >> Michał Górny schrieb: >>> Hello, >>> >>> There is a fair interest in multilib and while still early, it would be >>> a good moment to decide on how USE flags to use for it. >>> >>> The current attempts are mostly using USE=multilib which is not really >>> expressive and poor. What I would go for is a clear variable specifying >>> which targets package is built for. >>> >>> >>> This raises the following questions: >>> >>> 1) do we want the default ABI to be switchable? >>> >>> 2) do we want irrelevant ABIs to be visible to emerge users? >>> >>> By 2) I mean: do we want the users to see stuff like: >>> >>> MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) >>> (-ppc64_abi2) (-ppc64_abi3) ..." >>> >>> or just the relevant part. >>> >>> To be honest, I don't know if there's other way to hide USE flags than >>> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split >>> the flags per-arch, i.e. have: >>> >>> MULTILIB_AMD64="abi1 abi2 abi3" >>> MULTILIB_PPC64="abi1 abi2 abi3" >>> >>> with appropriate USE_EXPAND_HIDDEN set by profiles. >>> >>> >>> What are your thoughts? Which arches would like to use multilib? What >>> names for ABIs do you suggest? >>> >> >> So you want to re-implement multilib-portage in an eclass without the >> additional benefits a package-manager level implementation has? > > Well that's the point of the eclass that was proposed a few days ago > allow building multiple ABIs. Having clear USE-dep like python-r1.eclass > is imho the way to go. > > As said in another reply of this thread, USE=multilib really is a > solution that has its problems (no fine PM control for ABIs, slow > updates of emul-pkgs) to the current problem and portage-multilib, well > it's a subject that pops up from time to time I have no idea how and > will it will come nor do I have time to help on that front. multilib-portage exists and works for years, the problem usually is, that posts about it are ignored until i write something about "planned to ask council", which results in new requests to be fulfilled (for the inclusion of this feature in the next EAPI). This could also get us rid of USE=multilib and the emul packages. ;-) > However this eclass would enable quick and easy per-ebuild support for > multiple ABIs just like python-r1 and friends, and this is a good thing > for every maintainer that wants to provide this kind of support. I know > I would, at least to get rid of the always lagging emul packages. As already written in another thread not long ago, the USE flag part (shown USE flags per arch and USE flag dependencies) will be pretty hard to implement at eclass level. So i will wait and see, if someone can surprise me with a solution, that works as good as multilib-portage without bad side effects or additional work for all sides. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sun, Jan 20, 2013 at 4:59 PM, Rick "Zero_Chaos" Farina wrote: >> If we have it as IUSE default, it can be removed from the profiles >> entirely. Having it only in the desktop profile is not good in any >> scenario I can think of. > > chithanh, maybe you can explain to everyone why USE=dri is needed for > base profile. You seem to be the most knowledgable here, can you cite a > specific example for how/why a non-desktop profile machine would need > USE=dri. I think that the example may make it more obvious to people > what is right or wrong here. > It is needed if you want to run X11 in the generally-recommended configuration. I believe it is required for kernel modesetting, and that is the most stable way to run X11 (and I think that allows a non-suid X11 server). I would think that would be the best configuration for X11 on any system, whether server, desktop, etc. Now, in case some of you are thinking "but I NEVER run X11 on my ," in that case the USE flag won't have any effect anyway. But, if there are people who run X11 on their they will get an all-around better experience with dri enabled. I can't really think of a case where somebody would want something that supports dri that is in the tree, but wouldn't want to use dri. Even things like embedded use dri (and in fact it is even more important there with the wimpy CPUs). And if you're running X11 on a server for whatever reason, wouldn't that be the place you would most want it to run as non-root? Rich
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit : > Michał Górny schrieb: > > Hello, > > > > There is a fair interest in multilib and while still early, it would be > > a good moment to decide on how USE flags to use for it. > > > > The current attempts are mostly using USE=multilib which is not really > > expressive and poor. What I would go for is a clear variable specifying > > which targets package is built for. > > > > > > This raises the following questions: > > > > 1) do we want the default ABI to be switchable? > > > > 2) do we want irrelevant ABIs to be visible to emerge users? > > > > By 2) I mean: do we want the users to see stuff like: > > > > MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) > > (-ppc64_abi2) (-ppc64_abi3) ..." > > > > or just the relevant part. > > > > To be honest, I don't know if there's other way to hide USE flags than > > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split > > the flags per-arch, i.e. have: > > > > MULTILIB_AMD64="abi1 abi2 abi3" > > MULTILIB_PPC64="abi1 abi2 abi3" > > > > with appropriate USE_EXPAND_HIDDEN set by profiles. > > > > > > What are your thoughts? Which arches would like to use multilib? What > > names for ABIs do you suggest? > > > > So you want to re-implement multilib-portage in an eclass without the > additional benefits a package-manager level implementation has? Well that's the point of the eclass that was proposed a few days ago allow building multiple ABIs. Having clear USE-dep like python-r1.eclass is imho the way to go. As said in another reply of this thread, USE=multilib really is a solution that has its problems (no fine PM control for ABIs, slow updates of emul-pkgs) to the current problem and portage-multilib, well it's a subject that pops up from time to time I have no idea how and will it will come nor do I have time to help on that front. However this eclass would enable quick and easy per-ebuild support for multiple ABIs just like python-r1 and friends, and this is a good thing for every maintainer that wants to provide this kind of support. I know I would, at least to get rid of the always lagging emul packages. -- Gilles Dartiguelongue Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Mon, 21 Jan 2013 00:01:05 +0100 Thomas Sachau wrote: > Michał Górny schrieb: > > Hello, > > > > There is a fair interest in multilib and while still early, it would be > > a good moment to decide on how USE flags to use for it. > > > > The current attempts are mostly using USE=multilib which is not really > > expressive and poor. What I would go for is a clear variable specifying > > which targets package is built for. > > > > > > This raises the following questions: > > > > 1) do we want the default ABI to be switchable? > > > > 2) do we want irrelevant ABIs to be visible to emerge users? > > > > By 2) I mean: do we want the users to see stuff like: > > > > MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) > > (-ppc64_abi2) (-ppc64_abi3) ..." > > > > or just the relevant part. > > > > To be honest, I don't know if there's other way to hide USE flags than > > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split > > the flags per-arch, i.e. have: > > > > MULTILIB_AMD64="abi1 abi2 abi3" > > MULTILIB_PPC64="abi1 abi2 abi3" > > > > with appropriate USE_EXPAND_HIDDEN set by profiles. > > > > > > What are your thoughts? Which arches would like to use multilib? What > > names for ABIs do you suggest? > > > > So you want to re-implement multilib-portage in an eclass without the > additional benefits a package-manager level implementation has? Could you stay on topic, please? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
Sergei Trofimovich schrieb:
> On Sun, 20 Jan 2013 20:11:31 +0100
> Michał Górny wrote:
>
>> Hello,
>>
>> There is a fair interest in multilib and while still early, it would be
>> a good moment to decide on how USE flags to use for it.
>>
>> The current attempts are mostly using USE=multilib which is not really
>> expressive and poor. What I would go for is a clear variable specifying
>> which targets package is built for.
>
> You just need to add 'ABI' and 'MULTILIB_ABIS' to
> "emerge --info ${pkg}" output.
>
> Do you plan to keep precise depends for packages?
> like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.
>
> What to do if someone builds a package only with non-default ABI?
> (it means installed package does not quite work for default ABI)
>
> like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
> any of ABI=amd64 users.
>
> In order to track such depends precisely you would need to add
> ABI flags to each revdep recursively. It's quite invasive. Is it worth
> the effort?
>
> Currently USE=multilib means 'build for all toolchain-supported' ABIs.
> It looks clean and short.
>
>> This raises the following questions:
>>
>> 1) do we want the default ABI to be switchable?
> It already is via /etc/portage/env per-package.
> Or via profile globally. arch/amd64/make.defaults:
> MULTILIB_ABIS="amd64 x86"
>
> DEFAULT_ABI="amd64"
>
> crossdev allows bootstrapping with any random default
> ABI out there as one-liner:
> crossdev -A 'x32 amd64' x86_64-unknown-linux-gnu.
>
>> 2) do we want irrelevant ABIs to be visible to emerge users?
>>
>> By 2) I mean: do we want the users to see stuff like:
>>
>> MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
>> (-ppc64_abi2) (-ppc64_abi3) ..."
>
> Would adding irrelevant ABIs trigger rebuilds on world update?
>
> Do you intermingle gentoo's $ARCH and ABI?
> How many ABI vars do you expect to see for simple "common" cases?
>
> x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64)
> x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64)
> x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64)
> i686-pc-linux-gnu-gcc -m32 (host ARCH=x86)
> i686-pc-linux-gnu-gcc -m64 (host ARCH=x86)
> i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86)
>
> 3 or 6?
>
> Looks like insane amount of metadata growth for each
> plagued package.
>
>> or just the relevant part.
>>
>> To be honest, I don't know if there's other way to hide USE flags than
>> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
>> the flags per-arch, i.e. have:
>>
>> MULTILIB_AMD64="abi1 abi2 abi3"
>> MULTILIB_PPC64="abi1 abi2 abi3"
>>
>> with appropriate USE_EXPAND_HIDDEN set by profiles.
>
> Having direct support in portage's core might reduce amount of
> user-visible/storable metadata in main tree. No slightest idea
> how it would look like though.
>
Support for cross-compiling packages for toolchain-supported ABIs
already exists and works for some years in multilib-portage (code in the
multilib branch of portage git repo, ebuild in the multilib-portage
overlay with very basic setup instructions in the doc dir of the overlay
and the #gentoo-multilib-overlay channel in freenode for questions).
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
Michał Górny schrieb: > Hello, > > There is a fair interest in multilib and while still early, it would be > a good moment to decide on how USE flags to use for it. > > The current attempts are mostly using USE=multilib which is not really > expressive and poor. What I would go for is a clear variable specifying > which targets package is built for. > > > This raises the following questions: > > 1) do we want the default ABI to be switchable? > > 2) do we want irrelevant ABIs to be visible to emerge users? > > By 2) I mean: do we want the users to see stuff like: > > MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) > (-ppc64_abi2) (-ppc64_abi3) ..." > > or just the relevant part. > > To be honest, I don't know if there's other way to hide USE flags than > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split > the flags per-arch, i.e. have: > > MULTILIB_AMD64="abi1 abi2 abi3" > MULTILIB_PPC64="abi1 abi2 abi3" > > with appropriate USE_EXPAND_HIDDEN set by profiles. > > > What are your thoughts? Which arches would like to use multilib? What > names for ABIs do you suggest? > So you want to re-implement multilib-portage in an eclass without the additional benefits a package-manager level implementation has? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Mon, 21 Jan 2013 01:05:56 +0300
Sergei Trofimovich wrote:
> On Sun, 20 Jan 2013 20:11:31 +0100
> Michał Górny wrote:
>
> > There is a fair interest in multilib and while still early, it would be
> > a good moment to decide on how USE flags to use for it.
> >
> > The current attempts are mostly using USE=multilib which is not really
> > expressive and poor. What I would go for is a clear variable specifying
> > which targets package is built for.
>
> You just need to add 'ABI' and 'MULTILIB_ABIS' to
> "emerge --info ${pkg}" output.
No, that's not the same. It's like python.eclass vs new Python
eclasses. Cheap hidden logic vs explicit USE-dep logic.
> Do you plan to keep precise depends for packages?
> like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.
Yes. ${MULTILIB_USEDEP} is for that (it currently evaluates
to 'multilib?').
> What to do if someone builds a package only with non-default ABI?
> (it means installed package does not quite work for default ABI)
Well, I was asking the same question. That was what my q1 was asking,
I think you misunderstood it.
> like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
> any of ABI=amd64 users.
>
> In order to track such depends precisely you would need to add
> ABI flags to each revdep recursively. It's quite invasive. Is it worth
> the effort?
A good point. I'd say that the default impl should be built then.
But... how about making it a USE flag with use.force logic? That way,
it would be explicitly visible, and if someone really wanted to disable
it, he would be able to do it on his own responsibility.
> Currently USE=multilib means 'build for all toolchain-supported' ABIs.
> It looks clean and short.
But if we wanted to introduce x32, it would become no longer clean. I
believe many of our users want/need multilib only for running 32-bit
apps on amd64 (like wine). Why would they need x32 libraries?
But on the other hand, if we follow that logic we will probably have
no reason to enable x32 on amd64 for a long time. Maybe mips ABIs will
be a better example?
> > 2) do we want irrelevant ABIs to be visible to emerge users?
> >
> > By 2) I mean: do we want the users to see stuff like:
> >
> > MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
> > (-ppc64_abi2) (-ppc64_abi3) ..."
>
> Would adding irrelevant ABIs trigger rebuilds on world update?
That's a good question, especially wrt USE_EXPAND_HIDDEN.
> Do you intermingle gentoo's $ARCH and ABI?
I think not. I believe that ABIs shall be defined by profiles.
If someone tries to set ARCH for something incorrect for the profile,
that's not something we shall support, I believe.
> How many ABI vars do you expect to see for simple "common" cases?
>
> x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64)
> x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64)
> x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64)
> i686-pc-linux-gnu-gcc -m32 (host ARCH=x86)
> i686-pc-linux-gnu-gcc -m64 (host ARCH=x86)
> i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86)
>
> 3 or 6?
I think 3 will be enough.
> Looks like insane amount of metadata growth for each
> plagued package.
I don't think metadata is really important here. I believe that
the amount of additional metadata introduced by the packages affected
by multilib is not really one worth worrying.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Sun, 20 Jan 2013 20:11:31 +0100
Michał Górny wrote:
> Hello,
>
> There is a fair interest in multilib and while still early, it would be
> a good moment to decide on how USE flags to use for it.
>
> The current attempts are mostly using USE=multilib which is not really
> expressive and poor. What I would go for is a clear variable specifying
> which targets package is built for.
You just need to add 'ABI' and 'MULTILIB_ABIS' to
"emerge --info ${pkg}" output.
Do you plan to keep precise depends for packages?
like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.
What to do if someone builds a package only with non-default ABI?
(it means installed package does not quite work for default ABI)
like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
any of ABI=amd64 users.
In order to track such depends precisely you would need to add
ABI flags to each revdep recursively. It's quite invasive. Is it worth
the effort?
Currently USE=multilib means 'build for all toolchain-supported' ABIs.
It looks clean and short.
> This raises the following questions:
>
> 1) do we want the default ABI to be switchable?
It already is via /etc/portage/env per-package.
Or via profile globally. arch/amd64/make.defaults:
MULTILIB_ABIS="amd64 x86"
DEFAULT_ABI="amd64"
crossdev allows bootstrapping with any random default
ABI out there as one-liner:
crossdev -A 'x32 amd64' x86_64-unknown-linux-gnu.
> 2) do we want irrelevant ABIs to be visible to emerge users?
>
> By 2) I mean: do we want the users to see stuff like:
>
> MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
> (-ppc64_abi2) (-ppc64_abi3) ..."
Would adding irrelevant ABIs trigger rebuilds on world update?
Do you intermingle gentoo's $ARCH and ABI?
How many ABI vars do you expect to see for simple "common" cases?
x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64)
x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64)
x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64)
i686-pc-linux-gnu-gcc -m32 (host ARCH=x86)
i686-pc-linux-gnu-gcc -m64 (host ARCH=x86)
i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86)
3 or 6?
Looks like insane amount of metadata growth for each
plagued package.
> or just the relevant part.
>
> To be honest, I don't know if there's other way to hide USE flags than
> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> the flags per-arch, i.e. have:
>
> MULTILIB_AMD64="abi1 abi2 abi3"
> MULTILIB_PPC64="abi1 abi2 abi3"
>
> with appropriate USE_EXPAND_HIDDEN set by profiles.
Having direct support in portage's core might reduce amount of
user-visible/storable metadata in main tree. No slightest idea
how it would look like though.
--
Sergei
signature.asc
Description: PGP signature
Re: [gentoo-dev] USE flags dri, cups, pppd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 20 Jan 2013 16:59:24 -0500 "Rick \"Zero_Chaos\" Farina" wrote: > chithanh, maybe you can explain to everyone why USE=dri is needed for > base profile. You seem to be the most knowledgable here, can you > cite a specific example for how/why a non-desktop profile machine > would need USE=dri. I think that the example may make it more > obvious to people what is right or wrong here. Your question is the wrong one to ask. What you should ask is whether a non-desktop profile machine *would be in any way affected by* USE=dri. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD8aPgACgkQ96zL6DUtXhGpfgCgxjrIlAp1M0gzkg4FJs2Yx+hM 290AniFiLh7uqNl8elQ/yWre1W903ZdC =d+Zn -END PGP SIGNATURE-
Re: [gentoo-dev] USE flags dri, cups, pppd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > If we have it as IUSE default, it can be removed from the profiles > entirely. Having it only in the desktop profile is not good in any > scenario I can think of. > chithanh, maybe you can explain to everyone why USE=dri is needed for base profile. You seem to be the most knowledgable here, can you cite a specific example for how/why a non-desktop profile machine would need USE=dri. I think that the example may make it more obvious to people what is right or wrong here. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ/Gi8AAoJEKXdFCfdEflKvoEP/RVOpm+dVKo4M5rRK0dM/IiZ Hj5bFHcfrtXGUDslZSNXgkPs7FU44hFcNvVIyurksbSvAa5mDyl/2A3mwmVbx7vk uWIyACt28IwX13XP6qUXCQWNkoo1KGiUUxA5GgeuRMGRiJmF0kR8shc3YvamFvGo 1keEnDoy/uZCJZx8YRQPmYls9ZxVlJ1ks9NUg9zU3Mh1/47Yikv5jrElsMfqkHKg /idqTDL1b8FmMDOSKTaMirOtOUToZriST4sd+WxkE1kRQVyc5wmEMyDYQ0DZqMtC FSBIuhn5Y3/tw/b0qBSsTn+iHeTs/JilukHT77x2mVVyM+a7GjAedGJP5TJHONvT d4g0sI/wh6Z/n8Qh/zmp74VJjGBNTi8ARYhttjo12G92irEEN7aZ06bExI9WFlb/ oQB/KWQ7SPBfAxGXwMVyhAMK//E3rptdAt/tX7Xetudphhz6RrJ9Zz6XFc8zu5xY AjsQlFNvFhrXHLUrJmL6YtbNTqXRq627gdKJFlvXjjCFF7Zg95EBPGbDxz8j/hGQ RrR5pUIKync3HELs5cyExBlk8nRMVdmW9c5/veAXJ2YQYJM23P6bwkyaEHPFyNbf Ggz8sweFDUln4G0EY/0k8KpSoG2xmCac59a9lB9zkby6nvGPvDIiOjd1GFqvPWQN 9dr4fV3EfS+w2wthWoua =80/k -END PGP SIGNATURE-
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
On Sun, Jan 20, 2013 at 9:32 AM, Andreas K. Huettel wrote: > Am Sonntag, 20. Januar 2013, 10:39:58 schrieb Rich Freeman: >> >> What's the point? I don't think democracy is the best way to handle >> these sorts of things. > > LOL. Yeah, but haven't we tried to give ourselves rules that at least resemble > it? > > If I wanted to find out expert opinions and act on that, I'd directly ask a > couple of people on IRC that I consider knowledgeable, and then directly > follow their advice. No mailing list need be involved. This would be > effective, most likely technologically correct, and fast. It would also cause > major $hitstorms, since every developer knows best about a lot of things, and > since a lot of people would understandably feel bypassed. I would lose commit > privileges quite fast. I think it is more difficult to lose commit privs than you think. There are lots of warning signs. People being pissed off does not equal getting your privs revoked. You do that for making horrific technical errors; generally speaking. > > On the other hand, if I want to do the ultimate "right thing" in a community > sense, I ask on the list and let the discussion develop. I get a lot of > opinions. Some of these I consider more, some less sensible; some of these are > better, some less well informed. On most issues, even well-informed people > will have different opinions - sometimes things are just a matter of personal > taste. Getting a real unanimous vote is impossible. I wait for everyone to > read his mail; we've already heard that 72h is by far not enough time. (Half a > year?) In the meantime the discussion has branched into a couple of topics, > and most people have forgotten the original issue... Action may be taken on > the day when debian stable has a newer glibc than gentoo (metaphorically > speaking). The general culture that I aspire to is one where developers take responsibility for their work. If you make a change and break stuff, you will lose trust. If you make a change and it goes well, you gain trust. Trusted people are allowed more freedom (changes with perhaps less discussion, or changes against an established consensus.) I think listening to people is important. However listening to them does not equal agreeing with them, or doing what they want. In the end you are 'in charge' of your change. People can make suggestions on how to do things better, or offer advice against pitfalls. However in the end you are the person doing the work, so the decisions are nominally yours to make. > > We will in the end need a compromise that both gets things done and involves > everyone that actively wants to be involved. (And yes, that means reading your > mail!) > > -- > Andreas K. Huettel > Gentoo Linux developer > dilfri...@gentoo.org > http://www.akhuettel.de/
[gentoo-dev] Re: Packages up for grabs
On 01/20/2013 05:30 AM, Pacho Ramos wrote: > Due swegener focusing in less packages until he has more time: > x11-misc/x11vnc -> maybe net-libs/libvncserver could be interested in > this > Yeah, I picked it up. As always, anyone is free to co-maintain if they like. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
Hello, There is a fair interest in multilib and while still early, it would be a good moment to decide on how USE flags to use for it. The current attempts are mostly using USE=multilib which is not really expressive and poor. What I would go for is a clear variable specifying which targets package is built for. This raises the following questions: 1) do we want the default ABI to be switchable? 2) do we want irrelevant ABIs to be visible to emerge users? By 2) I mean: do we want the users to see stuff like: MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) (-ppc64_abi2) (-ppc64_abi3) ..." or just the relevant part. To be honest, I don't know if there's other way to hide USE flags than using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split the flags per-arch, i.e. have: MULTILIB_AMD64="abi1 abi2 abi3" MULTILIB_PPC64="abi1 abi2 abi3" with appropriate USE_EXPAND_HIDDEN set by profiles. What are your thoughts? Which arches would like to use multilib? What names for ABIs do you suggest? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
On 17:52 Sun 20 Jan , Andreas K. Huettel wrote: > > > > > *the thing with USE flags is a big change. > > You're kidding, right? > > If we seriously start doing that, we'll either get slapped with "dont bother > us with that" by the council members, or nobody wants to run for council > anymore. > I didn't mean, to start asking the Council for everything (certainly not for USE flags changes in profiles). Writing that "the thing with USE flags is a big change", I meant that those USE flags were wrongly put/remained in base profiles in first place and before removing them we have to be sure that we won't break more, any user configurations. and how we 're going to do it safely. That's why I said about more time than 72h. But I stop here, as this thread is about something else, just wanted to explain the logic behind writing ^^. I think I will stop using words like small/big/bigger as it may confuse people. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgptoQdaZQybx.pgp Description: PGP signature
Re: [gentoo-dev] Chromium system ffmpeg
On 1/20/13 1:46 AM, Luca Barbato wrote: > On 19/01/13 20:10, "Paweł Hajdan, Jr." wrote: >> have a way to more simply exclude code that requires CODEC_ID_OPUS. > > Exclude in chrome or in libavcodec? > > The latter is a matter of adding --disable-decoder=opus and/or not > --enable-libopus in the configure. Exclude in chrome, in case old ffmpeg/libav does not support it. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: new "qt" category
Ben de Groot wrote: > On 20 January 2013 21:35, Dale wrote: >> Same here. I have had to re-emerge qt packages several times myself. >> It seems that when I do, I have to do them all one at a time too. > In which case you're better off with something like: >emerge -a1 `eix --only-names -IC qt` > I'm not a developer and I don't write fancy commands like that. When something needs to be emerged or re-emerged, I do it by hand. Sometimes, I emerge one, then emerge the next one etc etc. Sometimes I put all packages on the same line. I don't use commands like yours unless I copy and paste it from a news item or something. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] theology herd is empty
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2013 04:34 AM, Pacho Ramos wrote: > If we agree on keeping this herd instead of trying to find one > maintainer per package, somebody should join. Otherwise I will > move their packages to maintainer-needed in a week > > Thanks > I will join this herd, but anyone who wants to add themselves as a maintainer to a package is welcome to do so. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD8LQYACgkQ23laikJhg1SqkgCfbVyh/gK1lCwGJMkuP0I+HDPM VSwAn2rlVv6TCuvTP8EldDfXruWkHk8v =dWxs -END PGP SIGNATURE-
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
Am Sonntag, 20. Januar 2013, 10:39:58 schrieb Rich Freeman: > > What's the point? I don't think democracy is the best way to handle > these sorts of things. LOL. Yeah, but haven't we tried to give ourselves rules that at least resemble it? If I wanted to find out expert opinions and act on that, I'd directly ask a couple of people on IRC that I consider knowledgeable, and then directly follow their advice. No mailing list need be involved. This would be effective, most likely technologically correct, and fast. It would also cause major $hitstorms, since every developer knows best about a lot of things, and since a lot of people would understandably feel bypassed. I would lose commit privileges quite fast. On the other hand, if I want to do the ultimate "right thing" in a community sense, I ask on the list and let the discussion develop. I get a lot of opinions. Some of these I consider more, some less sensible; some of these are better, some less well informed. On most issues, even well-informed people will have different opinions - sometimes things are just a matter of personal taste. Getting a real unanimous vote is impossible. I wait for everyone to read his mail; we've already heard that 72h is by far not enough time. (Half a year?) In the meantime the discussion has branched into a couple of topics, and most people have forgotten the original issue... Action may be taken on the day when debian stable has a newer glibc than gentoo (metaphorically speaking). We will in the end need a compromise that both gets things done and involves everyone that actively wants to be involved. (And yes, that means reading your mail!) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] USE flags dri, cups, pppd
Mike Frysinger schrieb: > On Sunday 20 January 2013 10:54:55 Chí-Thanh Christopher Nguyễn wrote: >> Yes, I mentioned this in another post already. We can use EAPI=1 IUSE >> defaults instead. But this will not change any systems so I fail to >> see the point behind this. This will only move clutter from profiles >> into ebuilds. > where it should have been in the first place. if it's a package-specific > issue, > then it belongs in the package. It is a common issue shared among all packages and package versions that have this flag. So I think the profile is the correct place. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: Getting the general dev opinion ("Meinungsbild") on some feature
Andreas K. Huettel posted on Sun, 20 Jan 2013 17:52:40 +0100 as excerpted: >> *the thing with USE flags is a big change. > > You're kidding, right? > > If we seriously start doing that, we'll either get slapped with "dont > bother us with that" by the council members, or nobody wants to run for > council anymore. Additionally, the council has historically been somewhat like the US Supreme Court -- they like to have their discussion and to make the final decision, but the case itself is supposed to have actually been argued and all the basic issues covered at the trial-court level (which for us is the list). Which would put us back where we started, since that pre-council-decision discussion would happen... on the list. -- 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
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sunday 20 January 2013 10:54:55 Chí-Thanh Christopher Nguyễn wrote: > Ben de Groot schrieb: > > On 20 January 2013 23:22, Chí-Thanh Christopher Nguyễn wrote: > >> Andreas K. Huettel schrieb: > * move setting USE=dri from default/linux/make.defaults to > targets/desktop/make.defaults > >> > >> I must say that I am unhappy about this. The packages in question should > >> not be built with dri disabled unless you really *really* know what you > >> are doing. > > > > It seems to me this is an obvious case where sane useflag defaults > > need to be set by the packages involved. We no longer need to rely on > > global profiles for this. > > Yes, I mentioned this in another post already. We can use EAPI=1 IUSE > defaults instead. But this will not change any systems so I fail to see > the point behind this. This will only move clutter from profiles into > ebuilds. where it should have been in the first place. if it's a package-specific issue, then it belongs in the package. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: RFC: new "qt" category
Ben de Groot posted on Sun, 20 Jan 2013 21:59:49 +0800 as excerpted: > On 20 January 2013 21:35, Dale wrote: >> Same here. I have had to re-emerge qt packages several times myself. >> It seems that when I do, I have to do them all one at a time too. > > In which case you're better off with something like: >emerge -a1 `eix --only-names -IC qt` FWIW, I have a qt set here. I don't have it listed in world_sets as all my qt package installs are deps and I want to keep it that way, but it sure makes remerging them easier when I need to remerge them all. =:^) -- 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
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
On Sun, 20 Jan 2013 16:20:42 +0100 "Andreas K. Huettel" wrote: > I would like to suggest and ask your opinion on a simple way of getting the > developers' collective opinion: cast votes with a shell script on our > favourite shell server, which is then displayed on a web page (either only as > stats, or with name lists as now in the public list discussion). > A typical choice of options would be restricted to "Yes, No, More discussion > needed", a typical deadine 72h. > > So, a thread like "Should we enable useflag Z by default" would then include > "Please discuss here, vote on ..." with a link to the count page (updated via > cron every 1h). On login to ..., a message similar to the "open elections > message" could be displayed. > > Obviously the implementation does not exist, but this is conceptually simple > enough so it could be implemented within reasonable time. I think Rich has raised the main points already, and I mostly agree with him on the disadvantages of 'simple voting'. I once or twice told it would be really useful to have a stack exchange-like platform to discuss problems. Although it wouldn't be perfect, it would be something in between blind-voting and mailing list discussion. A place where everyone could suggest a solution and others could vote on the proposed solutions. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] USE flags dri, cups, pppd
Brian Dolbec schrieb: > But, doesn't your point above very strongly suggest that IUSE=+dri > should be set on those pkgs irregardless of where/if the dri USE flag > should be set in some profile. We can either set it in the base profile, then there is no need for IUSE="+dri". Or we can set it in every single ebuild that has the dri flag. I prefer the former because it reduces our maintenance burden. > With that in place, then moving it to > the desktop profile from the base wouldn't be bad, would it? If we have it as IUSE default, it can be removed from the profiles entirely. Having it only in the desktop profile is not good in any scenario I can think of. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
> > *the thing with USE flags is a big change. You're kidding, right? If we seriously start doing that, we'll either get slapped with "dont bother us with that" by the council members, or nobody wants to run for council anymore. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
On Sun, Jan 20, 2013 at 7:39 AM, Rich Freeman wrote: > On Sun, Jan 20, 2013 at 10:20 AM, Andreas K. Huettel > wrote: >> So, a thread like "Should we enable useflag Z by default" would then include >> "Please discuss here, vote on ..." with a link to the count page (updated via >> cron every 1h). On login to ..., a message similar to the "open elections >> message" could be displayed. >> >> Obviously the implementation does not exist, but this is conceptually simple >> enough so it could be implemented within reasonable time. >> >> Opinions? >> (Yes / No / More discussion needed :D ) > > What's the point? I don't think democracy is the best way to handle > these sorts of things. > > Plus, it leaves out users. Why does that matter? Think about it: > > If what you want is expert opinion then the last thing you want is any > kind of poll of anybody. Put it on the lists, follow the discussion, > chat with experts that emerge on irc/email/etc, and make the best > decision. Is that hard? Sure. But, if your goal is to discover > issues and learn then you won't get that in an easier way. . The primary complaint was the fact that there is too much email. While I don't disagree with your idea overall; it doesn't solve the problem of essentially too many messages to read, which is a disincentive to even try. This ends up where developers don't read -dev (or skim -dev, or are not even subscribed to -dev.) > > If you just want to get a sense for what people find useful in a case > where popularity really is relevant (like the cups example) then you > really want to poll the entire userbase. A forum poll or something > like that is more useful for that. This isn't used for judging > technical rightness, but purely for assessing popularity. > > If an issue is highly contentious then rather than counting votes it > makes more sense to ask the council. > > Other options include creating choices (that requires a maintenance > commitment though), and this is often facilitated by starting a > project. Then you can have somewhat more organized meetings/etc > around a topic of interest. > > Rich >
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sun, 2013-01-20 at 10:30 -0500, Rich Freeman wrote: > It seemed like most who were knowledgeable suggested disabling dri was > a bad move. I think it is required for kernel-modesetting among other > things. Why would somebody install xorg and not use dri? > > Rich > Since I'm not so knowledgeable about it, I didn't vote on this specific issue. But, doesn't your point above very strongly suggest that IUSE=+dri should be set on those pkgs irregardless of where/if the dri USE flag should be set in some profile. With that in place, then moving it to the desktop profile from the base wouldn't be bad, would it? -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] USE flags dri, cups, pppd
Ben de Groot schrieb: > On 20 January 2013 23:22, Chí-Thanh Christopher Nguyễn > wrote: >> Andreas K. Huettel schrieb: * move setting USE=dri from default/linux/make.defaults to targets/desktop/make.defaults >> I must say that I am unhappy about this. The packages in question should >> not be built with dri disabled unless you really *really* know what you >> are doing. > It seems to me this is an obvious case where sane useflag defaults > need to be set by the packages involved. We no longer need to rely on > global profiles for this. > Yes, I mentioned this in another post already. We can use EAPI=1 IUSE defaults instead. But this will not change any systems so I fail to see the point behind this. This will only move clutter from profiles into ebuilds. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] USE flags dri, cups, pppd
On 20 January 2013 23:22, Chí-Thanh Christopher Nguyễn wrote: > Andreas K. Huettel schrieb: >>> * move setting USE=dri from default/linux/make.defaults to >>> targets/desktop/make.defaults > > I must say that I am unhappy about this. The packages in question should > not be built with dri disabled unless you really *really* know what you > are doing. It seems to me this is an obvious case where sane useflag defaults need to be set by the packages involved. We no longer need to rely on global profiles for this. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
On 16:20 Sun 20 Jan , Andreas K. Huettel wrote: > I would like to suggest and ask your opinion on a simple way of getting the > developers' collective opinion: cast votes with a shell script on our > favourite shell server, which is then displayed on a web page (either only as > stats, or with name lists as now in the public list discussion). > A typical choice of options would be restricted to "Yes, No, More discussion > needed", a typical deadine 72h. > 72h is too little. Generally, on big changes*, I would say at least 2 weeks before actually doing (acting on) anything. Because people may be devaway for a while or busy with stuff and not reading their mail for some days (for some reason). And there is still the Council for bigger things. *the thing with USE flags is a big change. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgp0nsyh60fTd.pgp Description: PGP signature
Re: [gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
On Sun, Jan 20, 2013 at 10:20 AM, Andreas K. Huettel wrote: > So, a thread like "Should we enable useflag Z by default" would then include > "Please discuss here, vote on ..." with a link to the count page (updated via > cron every 1h). On login to ..., a message similar to the "open elections > message" could be displayed. > > Obviously the implementation does not exist, but this is conceptually simple > enough so it could be implemented within reasonable time. > > Opinions? > (Yes / No / More discussion needed :D ) What's the point? I don't think democracy is the best way to handle these sorts of things. Plus, it leaves out users. Why does that matter? Think about it: If what you want is expert opinion then the last thing you want is any kind of poll of anybody. Put it on the lists, follow the discussion, chat with experts that emerge on irc/email/etc, and make the best decision. Is that hard? Sure. But, if your goal is to discover issues and learn then you won't get that in an easier way. . If you just want to get a sense for what people find useful in a case where popularity really is relevant (like the cups example) then you really want to poll the entire userbase. A forum poll or something like that is more useful for that. This isn't used for judging technical rightness, but purely for assessing popularity. If an issue is highly contentious then rather than counting votes it makes more sense to ask the council. Other options include creating choices (that requires a maintenance commitment though), and this is often facilitated by starting a project. Then you can have somewhat more organized meetings/etc around a topic of interest. Rich
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sun, Jan 20, 2013 at 10:22 AM, Chí-Thanh Christopher Nguyễn wrote: > Andreas K. Huettel schrieb: >> >> Summarizing this thread: >> >>> * move setting USE=dri from default/linux/make.defaults to >>> targets/desktop/make.defaults >> >> +1 by dilfridge, djc, kensington, vapier, pesa, hwoarang >> chitanh, titanofold, zerochaos wants to keep this in default profile >> >> ===> done because it's still 2:1 (see remark at bottom) > > I must say that I am unhappy about this. The packages in question should > not be built with dri disabled unless you really *really* know what you > are doing. ++ It seemed like most who were knowledgeable suggested disabling dri was a bad move. I think it is required for kernel-modesetting among other things. Why would somebody install xorg and not use dri? Rich
Re: [gentoo-dev] USE flags dri, cups, pppd
Chí-Thanh Christopher Nguyễn schrieb: >>> * move setting USE=dri from default/linux/make.defaults to >>> targets/desktop/make.defaults >> +1 by dilfridge, djc, kensington, vapier, pesa, hwoarang >> chitanh, titanofold, zerochaos wants to keep this in default profile >> >> ===> done because it's still 2:1 (see remark at bottom) Also you didn't count yngwin Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] USE flags dri, cups, pppd
Andreas K. Huettel schrieb: > > Summarizing this thread: > >> * move setting USE=dri from default/linux/make.defaults to >> targets/desktop/make.defaults > > +1 by dilfridge, djc, kensington, vapier, pesa, hwoarang > chitanh, titanofold, zerochaos wants to keep this in default profile > > ===> done because it's still 2:1 (see remark at bottom) I must say that I am unhappy about this. The packages in question should not be built with dri disabled unless you really *really* know what you are doing. > We definitely need a better way to come to a consensus about such decisions. > Distilling everyone's intent out of the bikeshedding is a pain. I'll come up > with a separate e-mail about this and some suggestions soon... (or do it > yourself, but PLEASE start a separate thread!) 2:1 after two days on -devel and no indication that the number of developers chiming in would be used for decision making. If consensus was not required for this decision, then why bother reaching it at all? Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Getting the general dev opinion ("Meinungsbild") on some feature
Hi everyone, we've now had a few cases where mails were sent to this list to get a general opinion whether * some change should be implemented * some feature is still needed * ... While discussing this on a mailing list is nice, there are some disadvantages: * Threads are easily hijacked, and drift away from the original question * Bikeshedding about details. You know what I mean. * "Counting the votes" is a pain. * "+1" mails are certainly useful, but the number of bytes per bit of information is a bit high * and probably more. I would like to suggest and ask your opinion on a simple way of getting the developers' collective opinion: cast votes with a shell script on our favourite shell server, which is then displayed on a web page (either only as stats, or with name lists as now in the public list discussion). A typical choice of options would be restricted to "Yes, No, More discussion needed", a typical deadine 72h. So, a thread like "Should we enable useflag Z by default" would then include "Please discuss here, vote on ..." with a link to the count page (updated via cron every 1h). On login to ..., a message similar to the "open elections message" could be displayed. Obviously the implementation does not exist, but this is conceptually simple enough so it could be implemented within reasonable time. Opinions? (Yes / No / More discussion needed :D ) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On 23:47 Sat 19 Jan , Walter Dnes wrote: > ... > On a lark, I once tried the "default/linux/x86/10.0" profile for a > re-install on my netbook without "-*". I soon ended up with more "-" > entries in make.conf and package.use, than I have add-on entries when > using "-*". And I was only half-way through installing the apps I > normally use. I went back to "-*". > I have to admit that I've been using USE="-* " in my server boxes for a long time now, however it's a nasty hack and I wish for a better alternative. Profiles exist for reasons, bypassing them may break things unless you know what you're doing and you're active in Gentoo's community (so that have knowledge of certain bugs/news/discussions in mailing lists etc.). The problem is not with experienced users who can find their way. It is with newcomers. I like the idea of having minimal base profiles and on top of them desktop and/or server profiles enabling certain things. Because newcomers will not have to scratch their heads (as I wrote previously) from the first moment, if they enable one of them. Of course, even experienced users sometimes may become frustrated, when doing everything manually. (-* etc.). And things become more complex as time passes (new EAPIs, new portage features). This thread is about suggestions on better server profiles and need to think about that. For example,I would like to see a server profile with iptables and iproute2 on the system set. Maybe also a logger or a metapackage pulling certain packages (eg. bind-tools and nfs-utils). But it's just me, and it's a matter of taste/experience. I don't build server machines every day, others do and it would be much appreciated if they could respond here. Just, let's don't forget that profiles are not only about USE flags (because most discussions have been about the latter). -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgppwHH1awD7E.pgp Description: PGP signature
Re: [gentoo-dev] About dropping comm-fax herd
On 20 January 2013 09:10, Pacho Ramos wrote: > Only one package is inside it: > net-misc/capi4hylafax > > It should probably be moved to kingtaco (if he is still interested... > are you?) or maintainer-needed until any other steps up as maintainer. > > What do you think about removing this herd? +1 and thanks for your work -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
[gentoo-dev] Last rites: dev-lang/ruby-enterprise
# Hans de Graaff (20 Jan 2013) Mask # dev-lang/ruby-enterprise for removal, bug 453178. The current # versions have minor security issues, the latest versions are masked # and don't work, and upstream announced end-of-life almost a year # ago. Ruby 1.9 has almost all of the benefits of REE, so the # recommendation is to switch to that if you are still using REE. dev-lang/ruby-enterprise
Re: [gentoo-dev] Re: About dropping mips-kernel herd
On 01/20/2013 07:45 AM, Michael Palimaka wrote: On 20/01/2013 20:23, Pacho Ramos wrote: Looks like no package is included in it, I think we should drop that herd then Do you agree? +1 Yes drop it. I see no need. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Re: RFC: new "qt" category
On 20 January 2013 21:35, Dale wrote: > Same here. I have had to re-emerge qt packages several times myself. > It seems that when I do, I have to do them all one at a time too. In which case you're better off with something like: emerge -a1 `eix --only-names -IC qt` -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] USE flags dri, cups, pppd
Summarizing this thread: > * move setting USE=dri from default/linux/make.defaults to > targets/desktop/make.defaults +1 by dilfridge, djc, kensington, vapier, pesa, hwoarang chitanh, titanofold, zerochaos wants to keep this in default profile ===> done because it's still 2:1 (see remark at bottom) > * move setting USE=cups from default/linux/make.defaults to > targets/desktop/make.defaults +1 by dilfridge, djc, kensington, vapier, pesa, titanofold, dolsen ===> done, pretty much unanimous > * remove setting USE=pppd in default/linux/make.defaults, instead have it > default to on in net-dialup/capi4k-utils (the only place where it is used) +1 by dilfridge, djc, kensington, vapier, pesa, yngwin ===> done, pretty much unanimous We definitely need a better way to come to a consensus about such decisions. Distilling everyone's intent out of the bikeshedding is a pain. I'll come up with a separate e-mail about this and some suggestions soon... (or do it yourself, but PLEASE start a separate thread!) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About dropping sparc-kernel herd
On 01/20/13 10:32, Pacho Ramos wrote: > Looks like no package is included in it, I think we should drop > that herd then > > Do you agree? > > +1
Re: [gentoo-dev] Re: RFC: new "qt" category
Duncan wrote: > Ben de Groot posted on Sun, 20 Jan 2013 16:24:14 +0800 as excerpted: > >> On 20 January 2013 00:48, Duncan <1i5t5.dun...@cox.net> wrote: >>> *** (VERY strongly!) Please avoid namespace pollution! Don't drop the >>> hyphenated qt-pkg names. As a user, most of the time I DO only refer >>> to the package name, and dropping the qt- from qt-core, qt-gui, etc, is >>> WAYYY too generic to be practical. I for one would be cursing the >>> generic names every time I had to deal with the package. (Tho it's a >>> kde upstream issue, the same applies to "the application formerly known >>> as kcontrol", now the impossibly generic system-settings, and the >>> former ksysguard, now generically system-monitor. Anyone active on the >>> kde general or kde linux lists knows I simply refuse to use the generic >>> names.) >> And how often do you specifically emerge individual qt modules? These >> are usually pulled in as dependencies, and the great majority of users >> do not have to deal with this. (Just emerge smplayer, or emerge >> kde-meta, or emerge -uD1 @world ...) > More often than one might think. =:^] > > Same here. I have had to re-emerge qt packages several times myself. It seems that when I do, I have to do them all one at a time too. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
[gentoo-dev] Re: About dropping comm-fax herd
On 20/01/2013 20:10, Pacho Ramos wrote: Only one package is inside it: net-misc/capi4hylafax It should probably be moved to kingtaco (if he is still interested... are you?) or maintainer-needed until any other steps up as maintainer. What do you think about removing this herd? +1
[gentoo-dev] Re: About completely dropping lcd herd
On 20/01/2013 20:21, Pacho Ramos wrote: Looks like it's still listed in herds.xml even being empty and with no packages inside it. Probably it's time to safely remove it completely. OK with that? Best regards +1
[gentoo-dev] Re: net-news herd is empty
On 20/01/2013 21:34, Pacho Ramos wrote: Feel free to join for taking care of its packages. If nobody joins, will move that packages to maintainer-needed in a week Thanks Hi, I will join this herd. People who are interested in specific packages should still feel free to add themselves to/take them I think. Best regards, Michael
[gentoo-dev] Re: About dropping ppc-kernel herd
On 20/01/2013 20:26, Pacho Ramos wrote: Looks like no package is included in it, I think we should drop that herd then Do you agree? +1
[gentoo-dev] Re: About dropping sparc-kernel herd
On 20/01/2013 20:32, Pacho Ramos wrote: Looks like no package is included in it, I think we should drop that herd then Do you agree? +1
[gentoo-dev] Re: About dropping mips-kernel herd
On 20/01/2013 20:23, Pacho Ramos wrote: Looks like no package is included in it, I think we should drop that herd then Do you agree? +1
[gentoo-dev] Re: About dropping hppa-kernel herd
On 20/01/2013 20:19, Pacho Ramos wrote: Hello Looks like no package is inside this herd, I think would be safe to drop it. What do you think? Thanks +1
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El jue, 17-01-2013 a las 08:31 -0800, Zac Medico escribió:
> On 01/17/2013 08:00 AM, Pacho Ramos wrote:
> > Another try ;)
>
> Looks good to me.
+ 20 Jan 2013; Pacho Ramos +readme.gentoo.eclass:
+ Finally commit readme.gentoo.eclass to create a README.gentoo doc
file
+ recording tips shown via elog messages first time the package is
merged.
+
About handling more exotic cases (like different tips per version),
please should set DOC_CONTENTS instead of relying in
${FILESDIR}/README.gentoo* files (that are harder to make as flexible as
all this cases would require)
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] Support running commands in parallel if desirable.
...and use if for src_configure().
---
gx86/eclass/autotools-multilib.eclass | 41 +--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
index fe6372d..3aa5f27 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -28,7 +28,7 @@ if [[ ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
die "${ECLASS}: multilib support requires out-of-source builds."
fi
-inherit autotools-utils multilib
+inherit autotools-utils multilib multiprocessing
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
@@ -57,8 +57,45 @@ autotools-multilib_foreach_abi() {
fi
}
+# @FUNCTION: autotools-multilib_parallel_foreach_abi
+# @USAGE: argv...
+# @DESCRIPTION:
+# If multilib support is enabled, sets the toolchain up for each
+# supported ABI along with the ABI variable and correct BUILD_DIR,
+# and runs the given commands with them. The commands are run
+# in parallel with number of jobs being determined from MAKEOPTS.
+#
+# If multilib support is disabled, it just runs the commands. No setup
+# is done.
+#
+# Useful for running configure scripts.
+autotools-multilib_parallel_foreach_abi() {
+ local initial_dir=${BUILD_DIR:-${S}}
+
+ if use multilib; then
+ multijob_init
+
+ local ABI
+ for ABI in $(get_all_abis); do
+ (
+ multijob_child_init
+
+ multilib_toolchain_setup "${ABI}"
+ BUILD_DIR=${initial_dir%%/}-${ABI}
+ "${@}"
+ ) &
+
+ multijob_post_fork
+ done
+
+ multijob_finish
+ else
+ "${@}"
+ fi
+}
+
autotools-multilib_src_configure() {
- autotools-multilib_foreach_abi autotools-utils_src_configure
+ autotools-multilib_parallel_foreach_abi autotools-utils_src_configure
}
autotools-multilib_src_compile() {
--
1.8.1.1
Re: [gentoo-dev] app-emulation/qemu-user mask
On 16/01/13 20:20, Luca Barbato wrote: > Again please do not mix qemu system emulation with qemu userspace > wrappers. They have different needs and requirements. qemu-user-1.2.2 in portage. I'll drop the mask as said before. We can discuss on irc or here on what's the best strategy today anytime. lu
[gentoo-dev] net-news herd is empty
Feel free to join for taking care of its packages. If nobody joins, will move that packages to maintainer-needed in a week Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs
Due swegener focusing in less packages until he has more time: x11-misc/x11vnc -> maybe net-libs/libvncserver could be interested in this signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs due spock retirement
On 1/20/13 11:09 AM, Pacho Ramos wrote: > dev-python/pycuda Sci is taking this. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs due spock retirement
dev-python/pycuda media-gfx/bootsplash-themes media-gfx/fbgrab media-gfx/fbida media-gfx/fblogo media-gfx/quat media-gfx/splash-themes-gentoo media-gfx/splashutils sys-apps/v86d Thanks for taking care of them signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: RFC: new "qt" category
Ben de Groot posted on Sun, 20 Jan 2013 16:24:14 +0800 as excerpted: > On 20 January 2013 00:48, Duncan <1i5t5.dun...@cox.net> wrote: >> *** (VERY strongly!) Please avoid namespace pollution! Don't drop the >> hyphenated qt-pkg names. As a user, most of the time I DO only refer >> to the package name, and dropping the qt- from qt-core, qt-gui, etc, is >> WAYYY too generic to be practical. I for one would be cursing the >> generic names every time I had to deal with the package. (Tho it's a >> kde upstream issue, the same applies to "the application formerly known >> as kcontrol", now the impossibly generic system-settings, and the >> former ksysguard, now generically system-monitor. Anyone active on the >> kde general or kde linux lists knows I simply refuse to use the generic >> names.) > > And how often do you specifically emerge individual qt modules? These > are usually pulled in as dependencies, and the great majority of users > do not have to deal with this. (Just emerge smplayer, or emerge > kde-meta, or emerge -uD1 @world ...) More often than one might think. =:^] (TLDR folks feel free to skip, the summary is the line above.) Seriously, there's occasional remerges due to USE flag changes or gcc upgrades and full rebuilds, there's -rX bumps, and there's the usual upstream version bumps. While most of these (save for the straght-up same-version remerges) originally appear in emerge -NuDa, thus letting me know they're there, it's not unusual at all for me to pick and choose from the upgrade list and do bits of it at a time for one reason or another. Often, the reason is because I see something changing in the upgrade list, and I'm not thru researching what's going on and how I might need to change the config to accommodate it. I routinely check the ebuild changelogs for -rX bumps before I actually do the upgrade, for instance, because if the gentoo maintainer's doing an out-of-upstream-cycle bump (thus the -rX), there's generally a reason, and part of being a good admin is being aware at at least a general level, what's going on with such things, especially because they might change my desired config, or fix/trigger different bugs than the original package did. Other times I'm still researching new USE flags, or maybe entirely new packages are being pulled into the depgraph, and I don't know yet what's pulling them in and why, when there's a reasonable chance I'll want to change USE flags or the like to avoid the new deps, if I can. Thus I'll often set portage going with a subset of the full upgrade list, the "uninteresting" upgrades or those I've already researched, just to have it working on something in one terminal, while I continue doing my research on other package changes in another terminal window and/or in the browser, looking up bug-numbers, etc. Then of course there's the times when some package or other doesn't build. Given the amount of masked, overlay and prerelease packages I'm often running, this isn't unusual (yesterday's was plasma-workspace from kde 4.9.98, aka 4.10-rc3, when I was doing the .97 -> .98 upgrade; there's a missing extract-only, bug 450708 from 4.9.97 re-opened as it was fixed in that ebuild but the fix apparently didn't make it into the 4.9.98 ebuild). Often, I'll see it fail in the listing in one window (where portage is running with multiple jobs in --keep-going mode), and go try to remerge it in another window, letting it fail again to get the log, then researching and hopefully fixing the problem. When I do, I can now rerun the merge for all the dependencies portage dropped due to the failure, sometimes while the main update is still going. =:^) For these and other reasons it's not unusual in the least for me to be merging specific deep-dep packages by name. (Of course I have -1 in my default emerge aliases/scripts so I don't need to worry about the world file getting screwed up, tho it's empty anyway as everything's in sets.) -- 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
Re: [gentoo-dev] Chromium system ffmpeg
On 19/01/13 20:10, "Paweł Hajdan, Jr." wrote: > have a way to more simply exclude code that requires CODEC_ID_OPUS. Exclude in chrome or in libavcodec? The latter is a matter of adding --disable-decoder=opus and/or not --enable-libopus in the configure. lu
Re: [gentoo-dev] About completely dropping lcd herd
On 20 January 2013 17:21, Pacho Ramos wrote: > Looks like it's still listed in herds.xml even being empty and with no > packages inside it. Probably it's time to safely remove it completely. > > OK with that? > Best regards Yes please -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] theology herd is empty
If we agree on keeping this herd instead of trying to find one maintainer per package, somebody should join. Otherwise I will move their packages to maintainer-needed in a week Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] About dropping sparc-kernel herd
Looks like no package is included in it, I think we should drop that herd then Do you agree? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: About dropping ppc-kernel herd
On 20/01/13 10:26, Pacho Ramos wrote: > Looks like no package is included in it, I think we should drop that > herd then > > Do you agree? > Agreed.
[gentoo-dev] About dropping ppc-kernel herd
Looks like no package is included in it, I think we should drop that herd then Do you agree? signature.asc Description: This is a digitally signed message part
[gentoo-dev] About dropping mips-kernel herd
Looks like no package is included in it, I think we should drop that herd then Do you agree? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About dropping comm-fax herd
20.01.2013 13:10, Pacho Ramos wrote: > Only one package is inside it: > net-misc/capi4hylafax Personally, i think that keeping herd only for one package(if it's not god-damn-hard-to-maintain) is a bit overkill. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About dropping comm-fax herd
On 20 January 2013 17:10, Pacho Ramos wrote: > Only one package is inside it: > net-misc/capi4hylafax > > It should probably be moved to kingtaco (if he is still interested... > are you?) or maintainer-needed until any other steps up as maintainer. > > What do you think about removing this herd? +1 -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] About completely dropping lcd herd
Looks like it's still listed in herds.xml even being empty and with no packages inside it. Probably it's time to safely remove it completely. OK with that? Best regards signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: new "qt" category
On 20 January 2013 17:09, Nikos Chantziaras wrote: > On 20/01/13 10:39, Ben de Groot wrote: >> There is no need for multiple qt categories. We want everything that >> the upstream Qt Project considers to be part of the Qt Framework to be >> in one category. Besides that there are only a handful of third-party >> extensions, such as qwt. There is no need for a separate category for >> those at this point in time. > > > These are the essential modules: > > http://qt-project.org/wiki/Qt-Essentials-Modules > > and these are (or will be) the add-on modules: > > http://qt-project.org/wiki/Qt-Essentials-Modules > > So maybe "qt-base" and "qt-addon"? No, both the essentials and the add-ons will be in the same qt category. There is no reason to split these into different categories. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] About dropping hppa-kernel herd
Hello Looks like no package is inside this herd, I think would be safe to drop it. What do you think? Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] About dropping comm-fax herd
Only one package is inside it: net-misc/capi4hylafax It should probably be moved to kingtaco (if he is still interested... are you?) or maintainer-needed until any other steps up as maintainer. What do you think about removing this herd? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: RFC: new "qt" category
On 20/01/13 10:39, Ben de Groot wrote: On 20 January 2013 15:59, Nikos Chantziaras wrote: Just a user with a suggestion here. Since portage already has kde-base and kde-misc, why not qt-base and qt-misc (and qt-something is the need arises.) Qt5 will have standard core modules and extensions. qt-base and qt-misc look like they can cover these. There is no need for multiple qt categories. We want everything that the upstream Qt Project considers to be part of the Qt Framework to be in one category. Besides that there are only a handful of third-party extensions, such as qwt. There is no need for a separate category for those at this point in time. These are the essential modules: http://qt-project.org/wiki/Qt-Essentials-Modules and these are (or will be) the add-on modules: http://qt-project.org/wiki/Qt-Essentials-Modules So maybe "qt-base" and "qt-addon"?
Re: [gentoo-dev] Re: RFC: new "qt" category
On 20 January 2013 15:59, Nikos Chantziaras wrote: > Just a user with a suggestion here. Since portage already has kde-base and > kde-misc, why not qt-base and qt-misc (and qt-something is the need arises.) > Qt5 will have standard core modules and extensions. qt-base and qt-misc > look like they can cover these. There is no need for multiple qt categories. We want everything that the upstream Qt Project considers to be part of the Qt Framework to be in one category. Besides that there are only a handful of third-party extensions, such as qwt. There is no need for a separate category for those at this point in time. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] RFC: new "qt" category
On 20 January 2013 06:59, Francesco Riosa wrote: > 2013/1/19 Michał Górny >> Just a completely different idea -- how about putting those libraries >> into different categories appropriate to the topic? We have a bunch of >> categories like dev-libs, media-libs, etc. -- and I wonder how many of >> the Qt libs would fit into each of them. >> > This would be the right thing to do, or the correct way. > Most would really hate it (me too) Only for certain values of right and correct. Your gut reaction shows there are other ways to look at it. Besides, do you really want to spread the modules that are distributed in the same tarball into different categories? And then how about updating, something equivalent to: emerge -au1 `eix --only-names -IC qt` (or dev-qt, or whatever the single category will be)? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] RFC: new "qt" category
On 20 January 2013 05:03, Philip Webb wrote:
> 130119 Ben de Groot wrote:
>> On 19 January 2013 21:46, Patrick Lauer wrote:
>>> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it?
>> These are libraries and applications
>> that are used by developers of end-user applications.
>
> They are also encountered by users when updating KDE etc.
Not directly, only as dependencies. A simple world update will do what
is needed.
And otherwise this is more precise and concise:
emerge -au1 `eix --only-names -IC qt`
>> If there is too much opposition to a simple "qt" category
>> -- at least there seems to be some quite vocal opposition -- ,
>> then dev-qt is in my eyes the next best alternative.
>
> 'qt' alone is inconsistent with the rest of the tree.
Not really. We already have virtual/.
>> A third option we came up with is qt-framework.
>
> Too long to type & again no parallel in the existing tree.
But closer to upstream naming.
>> Somewhat comparable categories in the current tree
>> are dev-dotnet and gnustep-{base,libs}.
>
> Flame-eyes' suggestion is simple, consistent & involves least change :
> 'x11-qt/qt-core' 'x11-qt/qt-gui' etc. Please do it like that.
Most of Qt has nothing whatsoever to do with X11 directly, and that
will increasingly be true for Qt5 with its Wayland support.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: RFC: new "qt" category
On 20 January 2013 00:48, Duncan <1i5t5.dun...@cox.net> wrote: > * In general, yes, I'm in favor of a dedicated qt-* category, but... Good :-) > *** (VERY strongly!) Please avoid namespace pollution! Don't drop the > hyphenated qt-pkg names. As a user, most of the time I DO only refer to > the package name, and dropping the qt- from qt-core, qt-gui, etc, is WAYYY > too generic to be practical. I for one would be cursing the generic > names every time I had to deal with the package. (Tho it's a kde > upstream issue, the same applies to "the application formerly known as > kcontrol", now the impossibly generic system-settings, and the former > ksysguard, now generically system-monitor. Anyone active on the kde > general or kde linux lists knows I simply refuse to use the generic > names.) And how often do you specifically emerge individual qt modules? These are usually pulled in as dependencies, and the great majority of users do not have to deal with this. (Just emerge smplayer, or emerge kde-meta, or emerge -uD1 @world ...) > * (Less strongly.) Please keep the hyphenated category name scheme as > well. Why? > * dev-qt seems appropriate. Agreed. I think this is the next best option, if plain qt is too controversial. > * qt-base would work too. No, this wouldn't work. Upstream has a qtbase repo that is one of the parts of the Qt Framework as a whole. Using qt-base as a category name could be unnecessarily confusing. > * qt-libs or lib-qt, not so much, because there's executables as well. Agreed. > * x11-qt not so much, as qt5 is no longer x11 limited. Additionally, x11/ > xorg will arguably start losing its dominance to wayland in the qt5 > timeframe, with qt5 even now having (preliminary?) wayland support I > believe, and at some point, x11-qt may well look rather quaint and > anachronistic, sort of like references to ip-chains or xfree86 do today. Agreed. > So my vote would be for dev-qt/qt-*. Yes, that's a doubled qt reference > with the category, but in practice, few use the category name unless they > have to anyway, and it sure beats the namespace polluting alternative! Again, I don't think that should be a problem, because people would hardly ever need to deal with qt modules directly. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] RFC: new "qt" category
On 19 January 2013 23:38, Michael Weber wrote: > We have a fixed number of exact 2 tags (foo and bar), > This limitation has proven it's usability in the past of Gentoo, but > there are reasons to break it up (Like making up funny points like regex > and it has always been this way). foo-bar-baz might be usefull, too. That's just convention, not a limitation. We already have virtual/ which breaks the convention. There is nothing, except resistance to change, that requires us to follow the convention. > But it's plain redundacy to in insist on *qt*/qt-*. Agreed, though some people seem to prefer that. > Either reject using an appropriate category and place it > as misc-randoom/qt-* or use a category and strip the "qt-" prefix. > > I'm fine with qt/core, my preference would be lib-qt/core or lib/qt-core. We don't have lib-* categories now, and I don't see why we should use qt to start that. Besides, this whole discussion got started initially because we were asking ourselves where to place the *applications* (designer and linguist) that we want to split off from qt-gui and give separate ebuilds. They are not libs, strictly spoken. So that brought up, for us in the Qt team, that maybe it's time to have our own category. This is why I prefer plain "qt", or alternatively "dev-qt" or "qt-framework". The more concise, the better. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] Re: RFC: new "qt" category
On 17/01/13 15:57, Ben de Groot wrote: Presently we already have a good number of split qt-* library packages in x11-libs. With the arrival of Qt5 upstream has gone a lot further in modularization, so we expect the number of packages to grow much more. We, the Gentoo Qt team, are of the opinion that the time has come to split all these out into their own category. This category is to be used for the various modules and applications that belong to the upstream Qt Framework only (these include e.g. assistant and linguist). Third-party applications should remain in the current categories. After some initial bikeshedding we came to the conclusion that naming the category simply "qt" is the most elegant solution. We will then also be dropping the qt- prefix in package names. This means x11-libs/qt-core will be moved to qt/core, and so on. Just a user with a suggestion here. Since portage already has kde-base and kde-misc, why not qt-base and qt-misc (and qt-something is the need arises.) Qt5 will have standard core modules and extensions. qt-base and qt-misc look like they can cover these.
