Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Sun, 30 Aug 2009 19:06:02 +0200
Mounir Lamouri volk...@gentoo.org wrote:
So I think we should add a new feature in PMS already used in Exherbo
EAPI, USE flags requirements [1]. That means an ebuild should be able
to say a USE flag is available only if some other ones are in a
specific state. Let's take the mplayer example, if we have a line
like this: USE_REQUIREMENTS=encode? ( mp2 mp3 faac x264 xvid ), PM
should be able to show the user USE=mp3 will be ignored because he
didn't set USE=encode and the PM will disable this USE flag by
himself. The same way, for ekiga:
USE_REQUIREMENTS=kde? ( kontact ), PM should be able to show thed
user if he set USE=kontact, kde USE flag is enabled and the PM will
enable this USE flag by himself.
Is the less expressive solution you're describing still useful enough
to make it worthwhile? When we were doing this for Exherbo, we
identified five types of inter-use-flag dependency:
* if a then b
* if a then not b
* at least one of a b c, possibly only if d
* exactly one of a b c, possibly only if d
* at most one of a b c, possibly only if d
Does Gentoo make use of all of these, and are there any cases that the
above doesn't cover? How would you express each of the above using
USE_REQUIREMENTS?
From a package manager perspective, it's much easier to give good
advice to the user if we're told by the ebuild exactly what's going on.
I've said this before, but maybe now the time is right.
I think that many of these issues are caused by use flags being binary which
causes the total number of options to be a power of 2. If the real total number
of options is not a pwoer of 2 then some combinations of use flags are a priori
bad and thus currently we try to work around this.
I propose that use flag are not merely binary flags, but can take a value out of
a range of possible values. Binary use flags could be `on' or `off'. Other use
flags could range over a wider range of values. We could then catch errors early
as use flag $flag has bad value $badvalue.
* if a then b
This means that the situation +a -b is bad. So going with the ekiga example
above, there could be a `kontact' use flag with possible values `off-kde',
`off+kde' and `on'. The same situation can also be modeled by a `kde' use flag
with possible values `on-with-kontact', `on-without-kontact', `off'.
* if a then not b
Basically the same as above: +a +b is bad, so use flag `f' could range over
a-b -a-b -ab and signal an error for any other value.
* at least one of a b c, possibly only if d
I would be interested in knowing the specifics of packages wanting this. (It
could possibly be addressed by use flags that take a set of values
simultaneously.)
* exactly one of a b c, possibly only if d
There should be a use flag `d' with possible values in `a', `b', `c' and
possibly `off'. This is really the situation where my proposal shines. This
covers the situation where you need an implementation of $proglang but don't
care whether it is $progimpl-lolcat, $progimpl-fuzzycat, $progimpl-dog or any
one of a number of other supported implementations.
* at most one of a b c, possibly only if d
This situation is equivalent to the situation:
* exactly one of `a' `b' `c' `none', possibly only if d which was solved above.
4 out of 5 ain't bad ;P
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqbq4YACgkQp/VmCx0OL2wyLQCgiZz5l+UyPEMc8Ci35C/muAmd
IZEAniGWrm52eWZTsyJUDGzVJjx8uRlH
=iieZ
-END PGP SIGNATURE-
[gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Hi, Sebastian Pipping webmas...@hartwork.org: Alexey Shvetsov wrote: Hi all! seems smoltSendProfile doesnt work with unicode locales =) 100%] x11-wm/twm-1.0.4 Traceback (most recent call last): File /usr/lib/python2.6/site-packages/smolt/client/sendProfile.py, line 211, in module % excerpts UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128) Sorry I wasn't able to address this issue earlier. I have just committed a patch [1] that could fix it. Please try again with the latest HEAD and let me know how it works for you. Traceback (most recent call last): File /usr/lib/python2.6/site-packages/smolt/client/sendProfile.py, line 215, in module % excerpts UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128) Similar. :) V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] New global USE flag: modules
Dne pondělí 31 Srpen 2009 01:54:00 Robin H. Johnson napsal(a): Per my thread on building modules and linux-info, USE=modules will be moving from being a local USE flag to being a global, AND it will be enabled by default in the base profile. Proposed description: - Enable building of kernel modules As ati-drivers maintainer I say it is good description for my package :] So my word is: PROCEED :] Cheers Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
On Sun, Aug 30, 2009 at 10:45 AM, William Hubbswilli...@gentoo.org wrote: On Sun, Aug 30, 2009 at 08:16:47PM +0530, Nirbheek Chauhan wrote: On Sun, Aug 30, 2009 at 7:41 PM, Matthias Schwarzottz...@gentoo.org wrote: Hi there! The new udev-145 and newer have some new kernel requirements. How should the ebuild verify they are met? Some possible ways: 1. Check config under /usr/src/linux 2. Check /proc/config.gz 3. Print message for user in pkg_postinst ebuilds usually use linux-info.eclass for this, but that only checks /usr/src/linux -- although checking /proc/config.gz *as well* would be better. That change should be made in the eclass. I agree here. The eclass should check /proc/config.gz. Also, another reason to use the eclass is it respects KBUILD_OUTPUT if it is set. If /proc/config.gz is the first thing we check, I don't think we need to bother at all with checking .config since we know the setup of the running kernel. What does everyone think? William, not picking on you, just replying in general. People that suggest to only check /proc/config.gz only are pretty crazy considering that file is a tunable option. What if the user has CONFIG_IKCONFIG_PROC=n?? The ebuild fails?! Of course, I haven't seen any code yet, so maybe people are just suggesting to check config.gz if is exists, then proceed via other means? ;-) -Jeremy
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
Nirbheek Chauhan wrote:
There's also bug 251179[1], which is ugly at first glance, but shows
that we don't really need an extra variable to control dependencies
between USE-flags (it *is* after all a dependency).
So, we can either use
use1? ( =${CATEGORY}/${PVR}[use2,use3,use4] )
which will probably require less changes to portage's resolver; or
something else like
use1? ( use2 use3 use4 )
The latter is unambiguous because it's not a package atom (no / ).
Either of these will work great when portage gets automatic
USE-dependency enabling.
Indeed, this is doable but I don't think it's clear enough. In addition,
speaking of PM, it will force it to be able to detect use1? ( use2 ) and
use1? ( cat/pkg ). Speaking of ebuild readability it's also not a good
thing because that's not real a dependency.
If needed, we can put this in IUSE variable actually. I've nothing
against even if I prefer IUSE_REQUIREMENTS because it's clearer: we
define IUSE vars somewhere and how to handle them somewhere else.
--
Mounir
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
Ciaran McCreesh wrote: Is the less expressive solution you're describing still useful enough to make it worthwhile? When we were doing this for Exherbo, we identified five types of inter-use-flag dependency: Actually, I said in my email I was looking for opinions about the feature not really about the syntax. It was just an example but as no-one jump to say it was useless and stupid, let's try with a clearer syntax. * if a then b IUSE_REQUIREMENTS=a? ( b ) * if a then not b IUSE_REQUIREMENTS=a? ( -b ) * at least one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) * exactly one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) a ? ( -b -c ) b ? ( -a -c ) c? ( -a -b ) * at most one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) ) if needed we can add IUSE_REQUIREMENTS=!d? ( -a -b -c) Does Gentoo make use of all of these, and are there any cases that the above doesn't cover? How would you express each of the above using USE_REQUIREMENTS? From a package manager perspective, it's much easier to give good advice to the user if we're told by the ebuild exactly what's going on. So I think we can satisfy all use cases with the classic Gentoo syntax even if new operators could be appreciated ;) -- Mounir
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
On Mon, 31 Aug 2009 20:15:37 +0200 Mounir Lamouri volk...@gentoo.org wrote: * at least one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) Moderately eww... * exactly one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) a ? ( -b -c ) b ? ( -a -c ) c? ( -a -b ) Really eww... * at most one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) ) Similarly eww. From a package manager perspective, it's much easier to give good advice to the user if we're told by the ebuild exactly what's going on. So I think we can satisfy all use cases with the classic Gentoo syntax even if new operators could be appreciated ;) How do we translate the above into nice friendly messages for the user? Taking the exactly one case, it's much better to say to the user: * If 'd' is enabled, exactly one of 'a', 'b' or 'c' must be enabled Than: * If 'd' is enabled, at least one of 'a', 'b' or 'bc' must be enabled Then when the user turns on all three: * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled And in the general case, there's no way of translating the latter into the former. Much easier for everyone if you just say what you mean rather than converting it into some convoluted (but theoretically equivalent) less expressive syntax. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
On Mon, Aug 31, 2009 at 07:27:32PM +0100, Ciaran McCreesh wrote: Then when the user turns on all three: * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled And in the general case, there's no way of translating the latter into the former. Much easier for everyone if you just say what you mean rather than converting it into some convoluted (but theoretically equivalent) less expressive syntax. I suggest alternative syntax, less powerfull but more expressive: groups of use-flags. Guess we define the following flags in IUSE: 3d.nvidia 3d.ati 3d.intel or 3d+nvidia 3d+ati 3d+intel or 3d:nvidia 3d:ati 3d:intel In first case we may enable any number of those flags. In second case we must enable at least one of them. In third case we must enable exactly one of them. In all 3 cases, if (and only if) flag '3d' itself exist in IUSE, those flags are ignored when it is unset. For convenience, user may use '.' as middle-character in config in all 3 cases (or, perhaps, even omit it and everything before it), but in output of PM he will see proper character and understand dependencies between flags without any explanation in English. If we add flag which depends on nvidia (e.g. cg), we name it 3d.nvidia.cg, and it will be ignored (perhaps with warning) if flag 3d.nvidia is unset.
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
Ciaran McCreesh wrote: On Mon, 31 Aug 2009 20:15:37 +0200 Mounir Lamouri volk...@gentoo.org wrote: * at least one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) Moderately eww... * exactly one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) a ? ( -b -c ) b ? ( -a -c ) c? ( -a -b ) Really eww... * at most one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) ) Similarly eww. From a package manager perspective, it's much easier to give good advice to the user if we're told by the ebuild exactly what's going on. So I think we can satisfy all use cases with the classic Gentoo syntax even if new operators could be appreciated ;) How do we translate the above into nice friendly messages for the user? Taking the exactly one case, it's much better to say to the user: * If 'd' is enabled, exactly one of 'a', 'b' or 'c' must be enabled Than: * If 'd' is enabled, at least one of 'a', 'b' or 'bc' must be enabled Then when the user turns on all three: * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled And in the general case, there's no way of translating the latter into the former. Much easier for everyone if you just say what you mean rather than converting it into some convoluted (but theoretically equivalent) less expressive syntax. We don't see this feature the same way. I don't want to add a feature that will prevent the maintainer to die if we can't found another way. I want the package manager do make some decisions before calling the ebuild. For example: * if a then b IUSE_REQUIREMENTS=a? ( b ) if USE=-a b is used, the package manager should enable a because it's needed for b and it should show this. We could say we also can disable b but we can't know if a USE flag is disabled or just not enabled (in other words, because every USE flags is disabled by default). In addition, we can consider if someone want to enable a feature it should be more important than disabling another. * if a then not b IUSE_REQUIREMENTS=a? ( -b ) if USE=a b, b should be disabled by the PM. It's up to the maintainer to choose a default behavior by setting the relation between USE flags (b? ( -a ) is equivalent but will disable a). * at least one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) if USE=d, the PM will enable a. * exactly one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( || ( a b c ) ) a? ( -b -c ) b? ( -a -c ) c? ( -a -b ) if USE=d, same as before. if USE=d a, nothing if USE=d a b, it's harder because a? ( -b -c ) and b? ( -a -c ). We can imagine to disable b because a is the first value in || ( a b c ) but it's not satisfying. We can imagine another operator like | to represent this dependency: d? ( | ( a b c ) ) * at most one of a b c, possibly only if d IUSE_REQUIREMENTS=d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) ) it's quite similar to the previous one but here it's harder to guess which one should be keep if USE=d a b. As previously, we can imagine another operator like d? ( ||| ( a b c ) ) But if we want to move to a really generic specification, we can introduce something similar to Exherbos syntax: exactly-N, max-N, min-N with N as a positive integer. So, we could write: d? ( exactly-1? ( a b c ) ) d? ( max-1? ( a b c ) ) d? ( min-1? ( a b c ) ) With this syntax, it's easy to consider first values as one to use by default for the PM (so, never failing). The only big issue I see with this syntax is it will make exactly-N, max-N and min-N no valid USE flags. But we can prevent that by prefixing the name by an illegal character like ||exactly-1. About the dying thing, I just want to precise I don't want to add a feature that will only die with a cool message. Maintainers can do that. The idea is to prevent maintainers to do that without silently enabling a feature or moving to an unstable state (because of EAPI-2 use dependencies). It will let maintainers to die if they want. They will not have to set a? ( b ) if they really think a shouldn't be enabled (even with possible user knowledge) if b is enabled. In this case, the classic die statement will be ok. Thanks, Mounir
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
dev-ran...@mail.ru wrote: On Mon, Aug 31, 2009 at 07:27:32PM +0100, Ciaran McCreesh wrote: Then when the user turns on all three: * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled And in the general case, there's no way of translating the latter into the former. Much easier for everyone if you just say what you mean rather than converting it into some convoluted (but theoretically equivalent) less expressive syntax. I suggest alternative syntax, less powerfull but more expressive: groups of use-flags. Guess we define the following flags in IUSE: 3d.nvidia 3d.ati 3d.intel or 3d+nvidia 3d+ati 3d+intel or 3d:nvidia 3d:ati 3d:intel In first case we may enable any number of those flags. In second case we must enable at least one of them. In third case we must enable exactly one of them. In all 3 cases, if (and only if) flag '3d' itself exist in IUSE, those flags are ignored when it is unset. For convenience, user may use '.' as middle-character in config in all 3 cases (or, perhaps, even omit it and everything before it), but in output of PM he will see proper character and understand dependencies between flags without any explanation in English. If we add flag which depends on nvidia (e.g. cg), we name it 3d.nvidia.cg, and it will be ignored (perhaps with warning) if flag 3d.nvidia is unset As you said, it's not enough powerful. It's going to be hard if foo flags depends on 3d and bar. In addition, I don't think the real issues is the friendliness of the syntax but the powerful aspect. Indeed, it shouldn't be shown to the user and more the syntax is powerful less the user will be annoyed. -- Mounir
[gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Hi, As you should know, GLEP 23 [1] introduced USE flags conditions in LICENSE variable and || operator in addition of licenses groups and ACCEPT_LICENSE variable. [1] http://www.gentoo.org/proj/en/glep/glep-0023.html I want to show an issue in ACCEPT_LICENSE that have to be fixed with a new operator in LICENSE variable. Imagine we have ACCEPT_LICENSE=GPL-3, every ebuilds without GPL-3 in LICENSE variable will be filtered even ebuilds with LICENSE=GPL-2 and a lot of packages are actually GPL-2+, not GPL-2 strict. That means they should be shown if ACCEPT_LICENSE=GPL-3. It's even worst when we try to use ACCEPT_LICENSE to have a free operating system. Let's suppose 'free' in fsf free and osf free, LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most LGPL-2 licensed packages in the tree are LGPL-2+ actually. So, what I propose is to let a license to be suffixed by the + operator. In this case, if a newer license is accepted by ACCEPT_LICENSE, the PM should not filter the package. I think it's not a hard modification and it will only need an amend to GLEP 23 (in addition of implementations in PM's). Thanks, Mounir
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Le 01/09/2009 00:12, Mounir Lamouri a écrit : Hi, As you should know, GLEP 23 [1] introduced USE flags conditions in LICENSE variable and || operator in addition of licenses groups and ACCEPT_LICENSE variable. [1] http://www.gentoo.org/proj/en/glep/glep-0023.html /me still thinks LICENSE should be informational _at_best_. Users who rely on LICENSE to build an FSF-approved system will simply be mislead. If we want to support this sort of things properly, we should have a treewide license audit. Anything short of that will just be a disservice to our users. Cheers, Rémi
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok,
Here's the list of ebuilds that feature a CONFIG_CHECK, and which ones
I've been through to check for either NONEED (already using ~option),
MODULE (builds a module so may really want to bomb out), and FIXED
(packages which I've fixed).
About half the list is done, I'm posting it here as a progress/grab 'em
if you want to do 'em type list (as requested by robbat2).
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkqcUhoACgkQu7rWomwgFXp3GwCfddJEgoKsDgaGTLzkouavCdVp
srQAoLUMEEwmobCBwWAHasrwJjjSt9k5
=iMAd
-END PGP SIGNATURE-
FIXED app-admin/longrun/longrun-0.9-r3.ebuild:CONFIG_CHECK=X86_MSR X86_CPUID
FIXED app-cdr/nero/nero-3.5.2.3.ebuild:CONFIG_CHECK=CHR_DEV_SG
FIXED app-cdr/nero/nero-3.5.3.1.ebuild:CONFIG_CHECK=CHR_DEV_SG
FIXED app-crypt/truecrypt/truecrypt-6.2.ebuild: local
CONFIG_CHECK=BLK_DEV_DM DM_CRYPT FUSE_FS CRYPTO
FIXED app-crypt/truecrypt/truecrypt-6.2a.ebuild: local
CONFIG_CHECK=BLK_DEV_DM DM_CRYPT FUSE_FS CRYPTO
MODULE app-emulation/vmware-modules/vmware-modules-1.0.0.15-r2.ebuild:
CONFIG_CHECK=
MODULE app-emulation/vmware-modules/vmware-modules-1.0.0.15-r2.ebuild:
CONFIG_CHECK=UNUSED_SYMBOLS
MODULE app-laptop/acer_acpi/acer_acpi-0.10.ebuild:CONFIG_CHECK=LEDS_CLASS
BACKLIGHT_LCD_SUPPORT
MODULE app-laptop/acer_acpi/acer_acpi-0.11.2.ebuild:CONFIG_CHECK=LEDS_CLASS
BACKLIGHT_LCD_SUPPORT
MODULE app-laptop/acer_acpi/acer_acpi-0.8.2.ebuild:CONFIG_CHECK=LEDS_CLASS
MODULE app-laptop/acpi4asus/acpi4asus-0.41.ebuild:
CONFIG_CHECK=LEDS_CLASS
MODULE app-laptop/acpi4asus/acpi4asus-0.41.ebuild:
CONFIG_CHECK=~ASUS_LAPTOP
DONEapp-laptop/hdapsd/hdapsd-20060409-r1.ebuild:CONFIG_CHECK=SENSORS_HDAPS
DONEapp-laptop/hdapsd/hdapsd-20060409-r3.ebuild:
CONFIG_CHECK=SENSORS_HDAPS
DONEapp-laptop/hdapsd/hdapsd-20060409.ebuild:CONFIG_CHECK=SENSORS_HDAPS
MODULE
app-laptop/lenovo-sl-laptop/lenovo-sl-laptop-.ebuild:CONFIG_CHECK=HWMON
BACKLIGHT_CLASS_DEVICE
MODULE app-laptop/tp_smapi/tp_smapi-0.37.ebuild:
CONFIG_CHECK=!SENSORS_HDAPS
MODULE app-laptop/tp_smapi/tp_smapi-0.39.ebuild:
CONFIG_CHECK=!SENSORS_HDAPS
MODULE app-laptop/tp_smapi/tp_smapi-0.40.ebuild:
CONFIG_CHECK=~INPUT_UINPUT
MODULE app-laptop/tp_smapi/tp_smapi-0.40.ebuild:
CONFIG_CHECK=!SENSORS_HDAPS
NONEED app-laptop/tpb/tpb-0.6.4.ebuild:CONFIG_CHECK=~NVRAM
NONEED app-misc/actkbd/actkbd-0.2.8.ebuild:CONFIG_CHECK=~INPUT_EVDEV
NONEED app-misc/dnetc/dnetc-2.9013.498.ebuild: local CONFIG_CHECK=~SYSVIPC
NONEED app-misc/dnetc/dnetc-2.9015.504.ebuild: local CONFIG_CHECK=~SYSVIPC
MODULE
app-misc/sdricoh_cs/sdricoh_cs-0.1.3_p20080521.ebuild:CONFIG_CHECK=MMC_BLOCK
MODULE
app-misc/sdricoh_cs/sdricoh_cs-0.1.3_p20080525.ebuild:CONFIG_CHECK=MMC_BLOCK
FIXED
app-mobilephone/gnokii/gnokii-0.6.27-r2.ebuild:CONFIG_CHECK=UNIX98_PTYS
(STABLE)
FIXED
app-mobilephone/gnokii/gnokii-0.6.27-r4.ebuild:CONFIG_CHECK=UNIX98_PTYS
FIXED app-mobilephone/gnokii/gnokii-.ebuild:CONFIG_CHECK=UNIX98_PTYS
MODULE
dev-embedded/parapin-driver/parapin-driver-1.0.0.ebuild:CONFIG_CHECK=PARPORT
FIXED dev-java/jusb/jusb-0.4.4-r1.ebuild:CONFIG_CHECK=USB_DEVICEFS
MODULE dev-util/sysprof/sysprof-1.0.12-r1.ebuild: CONFIG_CHECK=PROFILING
MODULE dev-util/sysprof/sysprof-1.0.12.ebuild: CONFIG_CHECK=PROFILING
NONEED dev-util/systemtap/systemtap-0.7.ebuild:CONFIG_CHECK=~KPROBES ~RELAY
~DEBUG_FS
NONEED dev-util/systemtap/systemtap-0.8.ebuild:CONFIG_CHECK=~KPROBES ~RELAY
~DEBUG_FS
NONEED dev-util/systemtap/systemtap-0.9.5.ebuild:CONFIG_CHECK=~KPROBES ~RELAY
~DEBUG_FS
NONEED dev-util/systemtap/systemtap-0.9.7.ebuild:CONFIG_CHECK=~KPROBES ~RELAY
~DEBUG_FS
NONEED dev-util/systemtap/systemtap-0.9.8.ebuild:CONFIG_CHECK=~KPROBES ~RELAY
~DEBUG_FS
NONEED dev-util/systemtap/systemtap-0.9.9.ebuild:CONFIG_CHECK=~KPROBES ~RELAY
~DEBUG_FS
NONEED gnome-base/gnome-menus/gnome-menus-2.20.3.ebuild:
CONFIG_CHECK=~INOTIFY
MODULE media-sound/alsa-driver/alsa-driver-1.0.20-r1.ebuild: local
CONFIG_CHECK=!SND SOUND ${CHECK_PNP} ${CHECK_ISA} ${CHECK_FW} ${CHECK_PARPORT}
MODULE media-sound/alsa-driver/alsa-driver-.ebuild:local
CONFIG_CHECK=!SND SOUND ${CHECK_PNP} ${CHECK_ISA} ${CHECK_FW}
MODULE media-sound/line6usb/line6usb-0.7.3.ebuild:CONFIG_CHECK=USB SOUND
MODULE media-sound/line6usb/line6usb-0.8.1.ebuild:CONFIG_CHECK=USB SOUND
MODULE media-sound/xfi-drivers/xfi-drivers-1.00.ebuild:CONFIG_CHECK=SND SOUND
MODULE media-tv/ivtv/ivtv-1.0.1.ebuild:CONFIG_CHECK=EXPERIMENTAL KMOD
HAS_IOMEM FW_LOADER I2C I2C_ALGOBIT
MODULE media-tv/ivtv/ivtv-1.0.1.ebuild:
CONFIG_CHECK=${CONFIG_CHECK} FB FB_TRIDENT FRAMEBUFFER_CONSOLE FONTS
MODULE media-tv/ivtv/ivtv-1.0.2.ebuild:CONFIG_CHECK=EXPERIMENTAL KMOD
HAS_IOMEM FW_LOADER I2C I2C_ALGOBIT
MODULE media-tv/ivtv/ivtv-1.0.2.ebuild:
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Mounir Lamouri wrote: It's even worst when we try to use ACCEPT_LICENSE to have a free operating system. Let's suppose 'free' in fsf free and osf free, LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most LGPL-2 licensed packages in the tree are LGPL-2+ actually. Are you aware that we have license groups like @FSF-APPROVED? It's set up in /usr/portage/profiles/license_groups. So, what I propose is to let a license to be suffixed by the + operator. In this case, if a newer license is accepted by ACCEPT_LICENSE, the PM should not filter the package. My vote is against it. It feels like black magic to me and many licenses are not versioned, at least not their reference names in Gentoo. However I do notice that GPL-2+ could make things easier. Why not introduce a license group for it like @GPL-2+ or so, instead? That would be transparent and use existing means. What do you think? Sebastian
Re: [gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Christian Faulhammer wrote: I have just committed a patch [1] that could fix it. Please try again with the latest HEAD and let me know how it works for you. Traceback (most recent call last): File /usr/lib/python2.6/site-packages/smolt/client/sendProfile.py, line 215, in module % excerpts UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128) Similar. :) Is that after the patch? The string should be plain ASCII at that point already. That puzzles me, are you very sure it's the new code? There should be a new function to_ascii in there. If it's after the patch do you have the time to play with the code yourself? Is it on a machine I could SSH into? It's kind of hard for me to debug this with it not happening on my machine. I can fake-produce it (which I did) but I don't get your scenario, it seems. Sebastian
[gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Hi, Sebastian Pipping webmas...@hartwork.org: Christian Faulhammer wrote: I have just committed a patch [1] that could fix it. Please try again with the latest HEAD and let me know how it works for you. Traceback (most recent call last): File /usr/lib/python2.6/site-packages/smolt/client/sendProfile.py, line 215, in module % excerpts UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128) Similar. :) Is that after the patch? The string should be plain ASCII at that point already. That puzzles me, are you very sure it's the new code? There should be a new function to_ascii in there. Yes, it is after the patch. The line number also changed. :) If it's after the patch do you have the time to play with the code yourself? Is it on a machine I could SSH into? It's kind of hard for me to debug this with it not happening on my machine. I can fake-produce it (which I did) but I don't get your scenario, it seems. I only have some basics in Python, but I am willing to play, tell me what to do. Unfortunately I am not able to give out SSH access. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-portage-dev] ebuild --debug takes forever when FEATURES contains keeptemp: detects QA warnings in build.log
Hi. When I'm executing ebuild --debug /path/to/my/ebuild.ebuild /some/file, ebuild keeps dumping QA warnings to /some/file. I think its because its grepping for : warning : in build.log, and such messages are quoted into build.log because of the use of --debug. If I remove /var/tmp/portage/CATEGORY/PV/temp/, ebuild's execution terminates after a reasonable period of time. I'm wondering whether this is a known issue, and assuming I want to keep 'keeptemp' in my FEATURES, is there some other workaround? Amit
