Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On 05/08/2012 02:01 AM, Rich Freeman wrote: > On Mon, May 7, 2012 at 7:17 PM, Walter Dnes wrote: >> There's a "server" profile which could be the answer. > > I've never seen that as being a terribly useful profile. Servers tend > to be very minimal configurations. Maybe if we ever ripped sshd out > of the default profile we might put it there, but beyond that what > would you run on EVERY server? If I were to build a server I'd just > stick with the default profile, and then add to it. Hi, read what Walter written till the very end ;) Problem is not what to *add* to the default profile, but rather that you have to *remove* tons of flags from it to have something compact. As he already mentioned usually USE="-*" is the way to start. There were plans once among the cluster herd's members to write minimalistic profile for hpc server/node and ha cluster that would inherit from a "barebone" server profile. We just never got to it as demand wasn't that high. Maybe it's time to revisit the problem. Cheers, Kacper signature.asc Description: OpenPGP digital signature
[gentoo-dev] Python without threads?
Upstream is talking about removing the ability to build python without threads support (non-double negative: future Python would require threads support). Is anyone here depending on building Python with -threads? Cheers, Dirkjan
Re: [gentoo-dev] add global useflag: webkit
On 05/07/2012 09:07 PM, Michał Górny wrote: > On Mon, 07 May 2012 20:58:18 -0700 > Zac Medico wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 05/07/2012 08:50 PM, Michał Górny wrote: >>> On Mon, 07 May 2012 14:41:33 -0700 Zac Medico >>> wrote: >>> On 05/07/2012 01:43 PM, Michał Górny wrote: > On Mon, 07 May 2012 13:24:31 -0700 Zac Medico > wrote: > >> On 05/07/2012 12:18 PM, Ulrich Mueller wrote: On Mon, 7 May 2012, Ciaran McCreesh wrote: >>> I propose: >>> REQUIRED_USE="== ( qt webkit )" >>> >>> But this just means that the ebuild has redundant USE >>> flags, so one of them shouldn't be in IUSE, in the first >>> place. >> >> It serves to convey meaning, such that a user who has >> disabled the qt USE flag will get a meaningful prompt if that >> flag is required for webkit support. This kind of information >> could be useful to some people, and it may be preferable to >> having a separate webkit-qt flag. > > If 'qt' flag is required for webkit support, it's 'webkit? ( qt > )'. What if '!webkit? ( !qt )' also applies though? As an alternative to listing both constraints separately, you could combine them as '^^ ( webkit !qt )', or add support for '== ( qt webkit )' to make the expression easier to read. >>> >>> Then it's pointless to have the 'webkit' flag which doesn't >>> control anything. >> >> Generalize the discussion to be about two abstract flags "x" and "y" >> that have the same kind of relationship, where each one actually does >> control something, but the two features are intertwined in a >> particular package such that they must both be enabled or disabled in >> unison. > > Then please show me an example of that. I don't see any offhand. I guess it's fairly uncommon, or non-existent. -- Thanks, Zac
Re: [gentoo-dev] add global useflag: webkit
On Mon, 07 May 2012 20:58:18 -0700 Zac Medico wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/07/2012 08:50 PM, Michał Górny wrote: > > On Mon, 07 May 2012 14:41:33 -0700 Zac Medico > > wrote: > > > >> On 05/07/2012 01:43 PM, Michał Górny wrote: > >>> On Mon, 07 May 2012 13:24:31 -0700 Zac Medico > >>> wrote: > >>> > On 05/07/2012 12:18 PM, Ulrich Mueller wrote: > >> On Mon, 7 May 2012, Ciaran McCreesh wrote: > > > >> I propose: > > > >> REQUIRED_USE="== ( qt webkit )" > > > > But this just means that the ebuild has redundant USE > > flags, so one of them shouldn't be in IUSE, in the first > > place. > > It serves to convey meaning, such that a user who has > disabled the qt USE flag will get a meaningful prompt if that > flag is required for webkit support. This kind of information > could be useful to some people, and it may be preferable to > having a separate webkit-qt flag. > >>> > >>> If 'qt' flag is required for webkit support, it's 'webkit? ( qt > >>> )'. > >> > >> What if '!webkit? ( !qt )' also applies though? As an alternative > >> to listing both constraints separately, you could combine them as > >> '^^ ( webkit !qt )', or add support for '== ( qt webkit )' to > >> make the expression easier to read. > > > > Then it's pointless to have the 'webkit' flag which doesn't > > control anything. > > Generalize the discussion to be about two abstract flags "x" and "y" > that have the same kind of relationship, where each one actually does > control something, but the two features are intertwined in a > particular package such that they must both be enabled or disabled in > unison. Then please show me an example of that. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] add global useflag: webkit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2012 08:50 PM, Michał Górny wrote: > On Mon, 07 May 2012 14:41:33 -0700 Zac Medico > wrote: > >> On 05/07/2012 01:43 PM, Michał Górny wrote: >>> On Mon, 07 May 2012 13:24:31 -0700 Zac Medico >>> wrote: >>> On 05/07/2012 12:18 PM, Ulrich Mueller wrote: >> On Mon, 7 May 2012, Ciaran McCreesh wrote: > >> I propose: > >> REQUIRED_USE="== ( qt webkit )" > > But this just means that the ebuild has redundant USE > flags, so one of them shouldn't be in IUSE, in the first > place. It serves to convey meaning, such that a user who has disabled the qt USE flag will get a meaningful prompt if that flag is required for webkit support. This kind of information could be useful to some people, and it may be preferable to having a separate webkit-qt flag. >>> >>> If 'qt' flag is required for webkit support, it's 'webkit? ( qt >>> )'. >> >> What if '!webkit? ( !qt )' also applies though? As an alternative >> to listing both constraints separately, you could combine them as >> '^^ ( webkit !qt )', or add support for '== ( qt webkit )' to >> make the expression easier to read. > > Then it's pointless to have the 'webkit' flag which doesn't > control anything. Generalize the discussion to be about two abstract flags "x" and "y" that have the same kind of relationship, where each one actually does control something, but the two features are intertwined in a particular package such that they must both be enabled or disabled in unison. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+omdkACgkQ/ejvha5XGaO4CQCdGwcuuk4usnDj25nrcmd7D697 /TgAn3vXcPzEX3jCLhBVPPbnnX+lLWDW =G/eD -END PGP SIGNATURE-
Re: [gentoo-dev] Chromium bundled code
On 04/05/12 17:59, Greg KH wrote: > On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote: >> On 04/05/12 14:35, Walter Dnes wrote: >>> What could work is a shim or compatability layer that gets >>> called, and pre-processes requests and forwards them to mdev. >> >> That's my idea =) > > and then, look, you have reimplemented udev. > I think that's the whole point of the exercise. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] add global useflag: webkit
On Mon, 07 May 2012 14:41:33 -0700 Zac Medico wrote: > On 05/07/2012 01:43 PM, Michał Górny wrote: > > On Mon, 07 May 2012 13:24:31 -0700 > > Zac Medico wrote: > > > >> On 05/07/2012 12:18 PM, Ulrich Mueller wrote: > On Mon, 7 May 2012, Ciaran McCreesh wrote: > >>> > I propose: > >>> > REQUIRED_USE="== ( qt webkit )" > >>> > >>> But this just means that the ebuild has redundant USE flags, so > >>> one of them shouldn't be in IUSE, in the first place. > >> > >> It serves to convey meaning, such that a user who has disabled the > >> qt USE flag will get a meaningful prompt if that flag is required > >> for webkit support. This kind of information could be useful to > >> some people, and it may be preferable to having a separate > >> webkit-qt flag. > > > > If 'qt' flag is required for webkit support, it's 'webkit? ( qt )'. > > What if '!webkit? ( !qt )' also applies though? As an alternative to > listing both constraints separately, you could combine them as '^^ ( > webkit !qt )', or add support for '== ( qt webkit )' to make the > expression easier to read. Then it's pointless to have the 'webkit' flag which doesn't control anything. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Chromium bundled code
On 04/05/12 18:02, Greg KH wrote: > When was the last time dbus crashed on you? Last time I used with bluez? I think about few months ago, I hadn't time to debug the issue and I tend not to use stuff I known broken. I know that's a chicken egg issue =| I'm not sure if connman hanging randomly is related to dbus or connman itself, again I hadn't had time to check what's exactly wrong. > And what would you consider "reliable" enough for "core services"? No dependency beside libc. > dbus > has proven itself over _many_ years to handle all of the issues that > something like this requires very well. It's a non-trivial thing to > implement and the authors of it have done a very good job, after > learning how to do it from other failed attempts at the same thing. Yet it crashes in some situations. My fault for not helping debugging them I guess. Again, I had something more interesting to do. > And what are you going to do when dbus moves into the kernel itself > (hint, it will be there soon)? Disabling it if I don't need it, as everybody in the world does disable the posix message queues? > How are you going to not use it then? I guess freebsd is still a supported platform for enlightenment and all the programs I use. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 05/07/12 21:40, Steven J Long wrote: > "The future of GNOME is as a Linux based OS. It is harmful to pretend > that you are writing the OS core to work on any number of different > kernels, user space subsystem combinations, and core libraries.. > Kernels just aren't that interesting. Linux isn't an OS. Now it is > our job to try to build one - finally. Let's do it."[3] For what it is worth, the OS core is the kernel, libc and bootloader. GNOME runs on top of that. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
Greg KH wrote: > On Fri, May 04, 2012 at 03:50:24PM +0100, Steven J Long wrote: >> >> To confirm again, that this is about without initramfs: >> > systemd and udev are being merged into one tarball. For the >> > "foreseeable future", it will still build 2 separate binaries. >> > What happens down the road if/when it all becomes one combined >> > binary? >> (It's much easier to introduce coupling between software in the same >> package. GregKH has also mooted a tightly-coupled "core" Linux distro, >> which afaict is the same reasoning as GnomeOS, and /that/ sounds like a >> clusterfsck waiting to happen.) > > "mooted"? > Yes, in the sense of "raised it as a possibility" or in this case a future direction[1] as discussed on debian-dev[2]. I'll assume you're just not familiar with the word 'moot' as a verb; originally the adjective meant 'on the agenda' or 'on the table', and 'to moot' means to raise an item for discussion. Its modern meaning of 'no longer worth discussing' comes from the judiciary: for it to be dismissed, it had to be under discussion in the first place, and so usage evolved. > And since when does having a set of tightly coupled base libraries and > systems that work well together somehow turn into "GnomeOS"? Reaching > like that is just foolish on your part. > When did I say that it's the same thing? I simply said it sounds like "the same reasoning." Compare: "There are a number of folk in the Linux ecosystem pushing for a small core of tightly coupled components to make the core of a modern linux distro. The idea is that this 'core distro' can evolve in sync with the kernel, and generally move fast. This is both good for the overall platform and very hard to implement for the 'universal' distros [such as Gentoo or Debian]." [1] ..with: "The future of GNOME is as a Linux based OS. It is harmful to pretend that you are writing the OS core to work on any number of different kernels, user space subsystem combinations, and core libraries.. Kernels just aren't that interesting. Linux isn't an OS. Now it is our job to try to build one - finally. Let's do it."[3] They sound like very similar reasoning to me. You misinterpreted what I said, which is one thing: there was no need to be discourteous. Let me be clear: I don't personally have an issue with udev talking to dbus (a requirement for it sounds wrong to me, but that's by-the-by.) It would annoy me no end, however, if udev required systemd, since I don't want to switch to it. And that is what we were discussing: possible future coupling between the two, which is much easier to do when the sources are part of the same package. Everything I need done on a desktop or a laptop in terms of hotplug, acpid events and wifi, the current udev has been able to do for years. I'd find it odd (read: the design smells) if those use-cases suddenly required new external dependencies. AFAIC vertical integration is supposed to mean closer downward coupling, typically skipping a layer or two; if it also means upward coupling, then the design is flawed ime. *shrug* What you do with your time, is your business. I'll evaluate any coupling that does or doesn't come up as and when, and make my own decisions then. That it's been mooted by you ;) means I'm glad others are doing work on busybox and mdev integration into openrc (I've read tonight that mdev works fine for simple hotplug like USB sticks) especially the applet to fsck and mount /usr early. OFC you could just assure us that udev will never rely on systemd as a design decision. I can understand that systemd might need close integration with the underlying udev implementation[PS]. SteveL. [1] https://plus.google.com/u/0/111049168280159033135/posts/V2t57Efkf1s [2] http://lists.debian.org/debian-devel/2012/04/msg00649.html [3] http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00439.html [PS] Though it reminds me of packages distributing libraries, and I'd question why one git repo can't be used to make two tarballs, with beta testing of udev alone by distros like Gentoo or Debian. A separate tarball would mean automated tests can be done, which is useful as a basis for systemd et al: another benefit of no upward coupling. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] add global useflag: webkit
On 05/06/2012 12:52 PM, Davide Pesavento wrote: > On Sun, May 6, 2012 at 2:34 AM, hasufell wrote: >> # grep :webkit use.local.desc | wc -l >> 33 >> >> I would vote to make this a global useflag: >> >> webkit - Adds support for the webkit library/module >> > > I suggest the following description: > > "Add support for the WebKit HTML rendering/layout engine." > > Otherwise +1 from me. > > Thanks, > Davide > I took the liberty to apply the change. https://bugs.gentoo.org/show_bug.cgi?id=285743 I have not changed all metadata.xml files, because quite a few of them have detailed descriptions on what the flag really does. I don't see a problem with that, so the maintainers should decide. There is still "net-irc/kvirc" which uses "qt-webkit". I would suggest to change that to "webkit" like in "net-irc/quassel" (with pretty much the same description). Any reservations against that?
Re: [gentoo-dev] Chromium bundled code
On 05/08/12 07:16, Olivier Crête wrote:
> On Mon, 2012-05-07 at 18:23 -0400, Walter Dnes wrote:
>> On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
>>> On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
On 04/05/12 14:35, Walter Dnes wrote:
> What could work is a shim or compatability layer that gets
> called, and pre-processes requests and forwards them to mdev.
That's my idea =)
>>> and then, look, you have reimplemented udev.
>>>
>>> {sigh}
>> Actually, more like what udev *USED TO BE*, namely a simple devicei
>> manager.
> Maybe Greg understands how udev was
... and of course the horrors that were called "devfs" and such - we
remember :)
> and how it should be better than you
> do,
err, that's bad. Maybe I know my needs better than other people? Maybe
my needs don't completely overlap with those of other people. Maybe
their vision of a tightly coupled everything doesn't even cover my
usecases nicely ...
> since he wrote it.
>
>
Classical argumentum ad verecundiam, you win a cookie.
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On Mon, May 7, 2012 at 7:17 PM, Walter Dnes wrote: > There's a "server" profile which could be the answer. I've never seen that as being a terribly useful profile. Servers tend to be very minimal configurations. Maybe if we ever ripped sshd out of the default profile we might put it there, but beyond that what would you run on EVERY server? If I were to build a server I'd just stick with the default profile, and then add to it. Rich
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On Sun, May 06, 2012 at 07:33:59AM -0400, Rich Freeman wrote > The bottom line is that we don't need 47 different profile targets - > there will always be a "use" for 1 more. That's why we all run Gentoo > - we aren't bound by the decisions made for us by the package > maintainers. There's a "server" profile which could be the answer. I tried using it for a while. Unfortunately, it results in an ewarn log message in /var/log/portage/elog for *EVERY LAST SINGLE BUILD*. I then changed over to starting my USE flag with "-*". If that message could be gotten rid of, so as not to pollute /var/log/portage/elog, it could be useful as a server_or_lightweight_desktop profile. -- Walter Dnes
Re: [gentoo-dev] Chromium bundled code
On Mon, 2012-05-07 at 18:23 -0400, Walter Dnes wrote:
> On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
> > On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
> > > On 04/05/12 14:35, Walter Dnes wrote:
> > > > What could work is a shim or compatability layer that gets
> > > > called, and pre-processes requests and forwards them to mdev.
> > >
> > > That's my idea =)
> >
> > and then, look, you have reimplemented udev.
> >
> > {sigh}
>
> Actually, more like what udev *USED TO BE*, namely a simple devicei
> manager.
Maybe Greg understands how udev was and how it should be better than you
do, since he wrote it.
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Chromium bundled code
On Fri, May 04, 2012 at 06:06:52PM -0700, Greg KH wrote > > Remember, you are passing the complexity of insisting that you do not > > want these things to the people managing the packages and trying to > > support the system in so many different combinations. Why someone would > > want to run Chromium on a system without udev or dbus is just looney... > > s/Chromium/Chrome/ Ahem... = waltdnes@d531 ~ $ USE="icu" emerge -pv chromium These are the packages that would be merged, in order: Calculating dependencies... done! !!! All ebuilds that could satisfy "sys-fs/udev" have been masked. !!! One of the following masked packages is required to complete your request: - sys-fs/udev-::gentoo (masked by: package.mask, missing keyword) /etc/portage/package.mask: - sys-fs/udev-182-r3::gentoo (masked by: package.mask, ~x86 keyword) - sys-fs/udev-182-r2::gentoo (masked by: package.mask, ~x86 keyword) - sys-fs/udev-171-r5::gentoo (masked by: package.mask) - sys-fs/udev-164-r2::gentoo (masked by: package.mask) - sys-fs/udev-151-r4::gentoo (masked by: package.mask) - sys-fs/udev-149::gentoo (masked by: package.mask) - sys-fs/udev-146-r1::gentoo (masked by: package.mask) - sys-fs/udev-141-r1::gentoo (masked by: package.mask, ~x86 keyword) - sys-fs/udev-141::gentoo (masked by: package.mask) - sys-fs/udev-124-r2::gentoo (masked by: package.mask) - sys-fs/udev-124-r1::gentoo (masked by: package.mask) - sys-fs/udev-119::gentoo (masked by: package.mask) - sys-fs/udev-115-r1::gentoo (masked by: package.mask) - sys-fs/udev-114::gentoo (masked by: package.mask) (dependency required by "www-client/chromium-18.0.1025.151" [ebuild]) (dependency required by "chromium" [argument]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. = OK, I temporarily unmask udev... = waltdnes@d531 ~ $ USE="icu" emerge -pv chromium These are the packages that would be merged, in order: Calculating dependencies... done! !!! All ebuilds that could satisfy ">=sys-apps/dbus-1.4.16" have been masked. !!! One of the following masked packages is required to complete your request: - sys-apps/dbus-1.4.20::gentoo (masked by: package.mask) /etc/portage/package.mask: - sys-apps/dbus-1.4.18::gentoo (masked by: package.mask) - sys-apps/dbus-1.4.16-r2::gentoo (masked by: package.mask, ~x86 keyword) - sys-apps/dbus-1.4.16::gentoo (masked by: package.mask) (dependency required by "dev-libs/dbus-glib-0.98" [ebuild]) (dependency required by "www-client/chromium-18.0.1025.151" [ebuild]) (dependency required by "chromium" [argument]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. = QED. -- Walter Dnes
Re: [gentoo-dev] Chromium bundled code
On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
> On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
> > On 04/05/12 14:35, Walter Dnes wrote:
> > > What could work is a shim or compatability layer that gets
> > > called, and pre-processes requests and forwards them to mdev.
> >
> > That's my idea =)
>
> and then, look, you have reimplemented udev.
>
> {sigh}
Actually, more like what udev *USED TO BE*, namely a simple devicei
manager.
--
Walter Dnes
Re: [gentoo-dev] add global useflag: webkit
On Mon, 07 May 2012 14:41:33 -0700 Zac Medico wrote: > What if '!webkit? ( !qt )' also applies though? As an alternative to > listing both constraints separately, you could combine them as '^^ ( > webkit !qt )', or add support for '== ( qt webkit )' to make the > expression easier to read. Forget "easier to read". The important part is being able to produce error messages for users. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] add global useflag: webkit
On 05/07/2012 01:43 PM, Michał Górny wrote: > On Mon, 07 May 2012 13:24:31 -0700 > Zac Medico wrote: > >> On 05/07/2012 12:18 PM, Ulrich Mueller wrote: On Mon, 7 May 2012, Ciaran McCreesh wrote: >>> I propose: >>> REQUIRED_USE="== ( qt webkit )" >>> >>> But this just means that the ebuild has redundant USE flags, so one >>> of them shouldn't be in IUSE, in the first place. >> >> It serves to convey meaning, such that a user who has disabled the qt >> USE flag will get a meaningful prompt if that flag is required for >> webkit support. This kind of information could be useful to some >> people, and it may be preferable to having a separate webkit-qt flag. > > If 'qt' flag is required for webkit support, it's 'webkit? ( qt )'. What if '!webkit? ( !qt )' also applies though? As an alternative to listing both constraints separately, you could combine them as '^^ ( webkit !qt )', or add support for '== ( qt webkit )' to make the expression easier to read. -- Thanks, Zac
Re: [gentoo-dev] add global useflag: webkit
On Mon, 07 May 2012 13:24:31 -0700 Zac Medico wrote: > On 05/07/2012 12:18 PM, Ulrich Mueller wrote: > >> On Mon, 7 May 2012, Ciaran McCreesh wrote: > > > >> I propose: > > > >> REQUIRED_USE="== ( qt webkit )" > > > > But this just means that the ebuild has redundant USE flags, so one > > of them shouldn't be in IUSE, in the first place. > > It serves to convey meaning, such that a user who has disabled the qt > USE flag will get a meaningful prompt if that flag is required for > webkit support. This kind of information could be useful to some > people, and it may be preferable to having a separate webkit-qt flag. If 'qt' flag is required for webkit support, it's 'webkit? ( qt )'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] add global useflag: webkit
On 05/07/2012 12:33 PM, Stelian Ionescu wrote: > Isn't it the time to make a new EAPI which no longer has USE "flags" but > USE "values" ? Many of the really weird USE flags combinations would be > much more clearly expressed if the possible types for a USE variable > were: > 1) member-of: for choosing the backend of certain functionality; e.g. > all combinations of USE="ssl openssl gnutls nss" would become e.g. > in the ebuild: > USE="ssl=[member-of: openssl,gnutls,nss]" > in make-conf: > USE: ssl=openssl, as synonymous of old USE="ssl openssl", or > USE: ssl=none, as synonymous of old USE="-ssl" > 2) subset-of: for selecting a number of modules to build. This would > replace USE_EXPAND quite neatly > 3) boolean: as alias for member-of: [true,false] > 4) unsigned int: IIRC some (few) packages can take optional uint at > configure-time. for example with dev-lisp/sbcl one can customize some > hardcoded GC parameters suchs as the default heap size, generation size, > etc... > > In the above case, one could have a USE variable named "webkit" of type > member-of: [qt,gtk] We can get similar results using booleans with REQUIRED_USE, and your approach seems to introduce needless complexity. -- Thanks, Zac
Re: [gentoo-dev] add global useflag: webkit
On 05/07/2012 12:18 PM, Ulrich Mueller wrote: >> On Mon, 7 May 2012, Ciaran McCreesh wrote: > >> I propose: > >> REQUIRED_USE="== ( qt webkit )" > > But this just means that the ebuild has redundant USE flags, so one of > them shouldn't be in IUSE, in the first place. It serves to convey meaning, such that a user who has disabled the qt USE flag will get a meaningful prompt if that flag is required for webkit support. This kind of information could be useful to some people, and it may be preferable to having a separate webkit-qt flag. -- Thanks, Zac
Re: [gentoo-dev] add global useflag: webkit
On Mon, 2012-05-07 at 11:11 -0700, Zac Medico wrote: > On 05/06/2012 05:47 PM, Arfrever Frehtes Taifersar Arahesis wrote: > > 2012-05-06 02:34:26 hasufell napisał(a): > >> # grep :webkit use.local.desc | wc -l > >> 33 > >> > >> I would vote to make this a global useflag: > >> > >> webkit - Adds support for the webkit library/module > > > > I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE flags. > > Another possible way to model this kind of relationship would be to us > REQUIRED_USE to enforce relationships with the qt and gtk flags: > > REQUIRED_USE="webkit? ( qt ) !webkit? ( !qt ) qt? ( webkit ) !qt? ( > !webkit )" > > versus > > REQUIRED_USE="webkit? ( gtk ) !webkit? ( !gtk ) gtk? ( webkit ) !gtk? ( > !webkit )" > > It's pretty awkward with the existing operators, but we could extend the > REQUIRED_USE syntax to support an equivalent operator in a future EAPI. Isn't it the time to make a new EAPI which no longer has USE "flags" but USE "values" ? Many of the really weird USE flags combinations would be much more clearly expressed if the possible types for a USE variable were: 1) member-of: for choosing the backend of certain functionality; e.g. all combinations of USE="ssl openssl gnutls nss" would become e.g. in the ebuild: USE="ssl=[member-of: openssl,gnutls,nss]" in make-conf: USE: ssl=openssl, as synonymous of old USE="ssl openssl", or USE: ssl=none, as synonymous of old USE="-ssl" 2) subset-of: for selecting a number of modules to build. This would replace USE_EXPAND quite neatly 3) boolean: as alias for member-of: [true,false] 4) unsigned int: IIRC some (few) packages can take optional uint at configure-time. for example with dev-lisp/sbcl one can customize some hardcoded GC parameters suchs as the default heap size, generation size, etc... In the above case, one could have a USE variable named "webkit" of type member-of: [qt,gtk] -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] add global useflag: webkit
> On Mon, 7 May 2012, Ciaran McCreesh wrote: > I propose: > REQUIRED_USE="== ( qt webkit )" But this just means that the ebuild has redundant USE flags, so one of them shouldn't be in IUSE, in the first place. Ulrich
Re: [gentoo-dev] add global useflag: webkit
On 05/07/2012 11:26 AM, Ulrich Mueller wrote: >> REQUIRED_USE="webkit? ( gtk ) !webkit? ( !gtk ) gtk? ( webkit ) !gtk? ( >> !webkit )" > >> It's pretty awkward with the existing operators, but we could extend >> the REQUIRED_USE syntax to support an equivalent operator in a >> future EAPI. > > As far as I can see, it is equivalent to: > > REQUIRED_USE="^^ ( webkit !qt )" > > (or analog for the gtk case). But see above. Ah, that's right. This would another good example for the dev manual, like the one from bug 399069 [1]. [1] https://bugs.gentoo.org/show_bug.cgi?id=399069 -- Thanks, Zac
Re: [gentoo-dev] add global useflag: webkit
On Mon, 7 May 2012 20:26:08 +0200 Ulrich Mueller wrote: > REQUIRED_USE="^^ ( webkit !qt )" Please provide an algorithm that will turn that into an appropriate error message for displaying to a user. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] add global useflag: webkit
> On Mon, 07 May 2012, Zac Medico wrote: > Another possible way to model this kind of relationship would be to > us REQUIRED_USE to enforce relationships with the qt and gtk flags: > REQUIRED_USE="webkit? ( qt ) !webkit? ( !qt ) qt? ( webkit ) !qt? ( > !webkit )" This line just says that either both webkit and qt must be set, or neither of them. In other words, that the ebuild has redundant flags, which IMHO should be avoided. > versus > REQUIRED_USE="webkit? ( gtk ) !webkit? ( !gtk ) gtk? ( webkit ) !gtk? ( > !webkit )" > It's pretty awkward with the existing operators, but we could extend > the REQUIRED_USE syntax to support an equivalent operator in a > future EAPI. As far as I can see, it is equivalent to: REQUIRED_USE="^^ ( webkit !qt )" (or analog for the gtk case). But see above. Ulrich
Re: [gentoo-dev] add global useflag: webkit
On Mon, 07 May 2012 11:11:04 -0700 Zac Medico wrote: > REQUIRED_USE="webkit? ( qt ) !webkit? ( !qt ) qt? ( webkit ) !qt? ( > !webkit )" Why do you need to write it both ways? > It's pretty awkward with the existing operators, but we could extend > the REQUIRED_USE syntax to support an equivalent operator in a future > EAPI. If we're doing this, can we get it in EAPI 5 please, and not use workarounds in the tree until EAPI 5 is done? Getting the package mangler to come up with good error messages for REQUIRED_USE failures is a huge pain, and it gets worse the more clever tricks people come up with to get around its inexpressivity. I propose: REQUIRED_USE="== ( qt webkit )" -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] add global useflag: webkit
On 05/06/2012 05:47 PM, Arfrever Frehtes Taifersar Arahesis wrote: > 2012-05-06 02:34:26 hasufell napisał(a): >> # grep :webkit use.local.desc | wc -l >> 33 >> >> I would vote to make this a global useflag: >> >> webkit - Adds support for the webkit library/module > > I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE flags. Another possible way to model this kind of relationship would be to us REQUIRED_USE to enforce relationships with the qt and gtk flags: REQUIRED_USE="webkit? ( qt ) !webkit? ( !qt ) qt? ( webkit ) !qt? ( !webkit )" versus REQUIRED_USE="webkit? ( gtk ) !webkit? ( !gtk ) gtk? ( webkit ) !gtk? ( !webkit )" It's pretty awkward with the existing operators, but we could extend the REQUIRED_USE syntax to support an equivalent operator in a future EAPI. -- Thanks, Zac
[gentoo-dev] Lastrite =www-client/firefox-3.6*
# Samuli Suominen (07 May 2012) # Upstream discontinued security support for 3.6 series. # Blocking net-libs/xulrunner removal wrt bug #403415. # If you still need these, now is the time to copy them # to your local overlay. # Masked for removal in 30 days. =www-client/firefox-3.6*
Re: Re: [gentoo-dev] New category for (libre)office extensions: office-ext?
> > On Sun, 6 May 2012, Andreas K Huettel wrote: > > I've collected information and the extensions (should) work with any > > office variant, openoffice and libreoffice. To be more precise, they > > should work with anything that uses the so-called "uno bridge". > > > > This is why I like the new category "office-plugins" best... and > > would like to implement that one. > > Is there any chance that there will be more than one or two office-* > categories in future? If not, I think that we shouldn't introduce a > new category prefix for this. The category should be named app-* > instead. > > How about app-ooo, following the naming of the virtual? > > Ulrich Well... we're already breaking that rule by having lxde-base, perl-core, sec- policy... and kde-*, rox-*, xfce-* exist only twice. So I would not handle this requirement too strongly. (I could e.g. imagine categories office-templates, office-filters, but that's right now pure speculation.) app-ooo kind of minimizes the "ah yes I know what goes there" effect. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/traverso: traverso-0.49.2-r1.ebuild ChangeLog traverso-0.49.2.ebuild traverso-0.49.1.ebuild
On Mon, 7 May 2012 21:00:18 +0800 Ben de Groot wrote: > On 7 May 2012 20:35, Alexis Ballier wrote: > >> + 07 May 2012; Ben de Groot > >> + +files/traverso-0.49.2-desktop.patch, > >> +files/traverso-0.49.2-gold.patch, > > > > that patch is not portable, please fix > > I considered that, but these patches have been sent upstream, > so if all is well, then they can be dropped with the next release. > In case they won't be applied, I'd be happy to make them > more portable at that time. if you know that, please do the right thing... now... if a half-broken patch is applied, that's not because it's good, that's because the person applying it didn't think about the broken case... A. PS: feel free to take maintainership of the package.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/traverso: traverso-0.49.2-r1.ebuild ChangeLog traverso-0.49.2.ebuild traverso-0.49.1.ebuild
> + 07 May 2012; Ben de Groot > + +files/traverso-0.49.2-desktop.patch, > +files/traverso-0.49.2-gold.patch, that patch is not portable, please fix > + +traverso-0.49.2-r1.ebuild, -traverso-0.49.1.ebuild, > -traverso-0.49.2.ebuild: this leaves a stray patch in files, please fix
[gentoo-dev] Lastrite: app-misc/beagle and related dependencies
# Samuli Suominen (07 May 2012) # Dead upstream. Removal in 30 days. Bugs 339811, # 372009 and 414837. Use app-misc/tracker or any other # indexer instead. app-misc/beagle app-misc/beagle-xesam dev-libs/libbeagle sys-fs/beaglefs
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
On 05/07/2012 02:24 AM, Ulrich Mueller wrote: Therefore I suggest we move this example a bit down in skel.ebuild as it's more logical to continue with new lines instead of applying in-between Any objections? Yes. Please leave it as it is. Yeah, I will if someone has a (good) argument for doing so. RESTRICT and PROPERTIES are on a single line and it's natural to add them to the second group of such variables, namely LICENSE, SLOT, KEYWORDS, and IUSE. Whereas DEPEND and RDEPEND typically extend over several lines; sometimes they are quite long. So, a RESTRICT line placed after *DEPEND will be much more easily missed than in its current place. Oh well, you have a point here. I'll just leave it as is and adjust my own behavior accordingly instead. Case closed.
Re: [gentoo-dev] add global useflag: webkit
On 05/07/2012 04:00 AM, hasufell wrote: On 05/07/2012 02:47 AM, Arfrever Frehtes Taifersar Arahesis wrote: 2012-05-06 02:34:26 hasufell napisał(a): # grep :webkit use.local.desc | wc -l 33 I would vote to make this a global useflag: webkit - Adds support for the webkit library/module I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE flags. You mean that for example KDE users who set +webkit in make.conf would possibly get some weird gtk-deps too? KDE shouldn't be trying to avoid GTK+ in any case, as USE="gtk" is enabled in the default desktop profile and is a graphical toolkit which may be the only graphical toolkit available for an package (and likely is). It's not like it's "straightup" GNOME. -1 for separating them
