[gentoo-dev] Re: [gentoo-dev-announce] Deprecation of Python 2.4
Arfrever Frehtes Taifersar Arahesis wrote: Python 2.4 is deprecated. There are plans to mask for removal it when remaining packages incompatible with Python 2.5 are fixed. (We will announce masking of Python 2.4 at least 1 month before masking it.) Please don't add new packages to the tree which work only with Python 2.4. If you want to add a package which depends on a Python module, which had been maintained separately in the past, but has been also included in Python 2.5, then don't add this Python module to the tree only for use with Python 2.4, but instead depend on Python =2.5. Where's the CC and Reply-To to gentoo-dev? Does removing python 2.4 have any effect on the upgrade path for old installations? Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] QA last rites for dev-cpp/libmxmlplus
# Diego E. Pettenò flamee...@gentoo.org (30 Aug 2009) # on behalf of QA team # # Unmaintained upstream, unneeded in tree, collides with # dev-libs/mini-xml (bug #247405) which is actually used. # # Removal on 2009-10-29 dev-cpp/libmxmlplus
[gentoo-dev] QA last rites for app-pda/synce-0.10; app-pda/synce-rra; app-pda/synce-kde; app-pda/synce-multisync_plugin
# Diego E. Pettenò flamee...@gentoo.org (30 Aug 2009) # on behalf of QA team # # Old version of synce framework; 0.13 and 0.14 are in the # tree and don't need these packages. synce-rra was just # fixed after almost an year (at least) of build failure. # # Removal on 2009-10-29 app-pda/synce-0.10 app-pda/synce-rra app-pda/synce-kde app-pda/synce-multisync_plugin
[gentoo-dev] About udev-145: new features / extras and kernel requirements
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 Second point: udev-145 bundles a lot of new extras, but they can only be enabled/disabled all or nothing. These extras are: * udev-acl: Apply consolekit permissions to devices for users (audio, video, joysticks, scanner, cameras, ...) * usb-db: Provide udev-rules with device names of pci and usb devices * hid2hci: Special utility to fix resume of some hid devices * keymap: Auto-configure model specific keys found on many laptops (brightness up, next song, www browser, or suspend) * modem-modeswitch: Switch modems that provide virtual cd-drive with drivers to modem mode * gudev: glib/gobject support for libudev This makes udev depend on these libs: libacl, libglib2, libusb, usbutils, pciutils, gperf Up to now I have just added use-flag extras to control these. But I suppose that udev-acl and maybe gudev is a hard requirement for newer hal or devicekit versions. And upstream thinks these should be enabled by default. Are any of these extras considered harmful? Regards Matthias
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
2009/8/30 Matthias Schwarzott z...@gentoo.org: 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 All of the above? Rationale being (1) is required to check against the kernel you're supposedly using, (2) for the kernel you definitely are using, and (3) to make sure people remember. An alternative to (2) and (3), though is to add a check to the udev initscript. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
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.
Personally, I would also add an ewarn into pkg_postinst to prevent
users from blundering into a broken system.
Second point: udev-145 bundles a lot of new extras, but they can only be
enabled/disabled all or nothing.
Eww. I suppose upstream is not open to making it a bit more granular?
These extras are:
* udev-acl: Apply consolekit permissions to devices for users (audio, video,
joysticks, scanner, cameras, ...)
This looks very useful for desktop users. As long as it doesn't pull
in ConsoleKit itself, enabling this by default should not be a
problem.
* usb-db: Provide udev-rules with device names of pci and usb devices
What are the consumers of this?
* hid2hci: Special utility to fix resume of some hid devices
If the consumer of this is pm-suspend, pm-hibernate etc, I say enable
by default.
* keymap: Auto-configure model specific keys found on many laptops
(brightness up, next song, www browser, or suspend)
This should be enabled by default, especially since HAL is getting
deprecated, and everything using HAL for this stuff will have to turn
to udev (X, gnome, kde)
* gudev: glib/gobject support for libudev
This is the interface almost everything is going to turn to with GNOME
2.28 (via DeviceKit-power and DeviceKit-disks in most cases). By the
time GNOME 2.30 and 3.0 are released, (theoretically) nothing will use
HAL.
I believe there are ongoing efforts to port X to use udev/gudev
instead of HAL, as well as KDE[1]
This makes udev depend on these libs:
libacl, libglib2, libusb, usbutils, pciutils, gperf
Up to now I have just added use-flag extras to control these. But I suppose
that udev-acl and maybe gudev is a hard requirement for newer hal or
devicekit versions. And upstream thinks these should be enabled by default.
There are no new versions of HAL anymore (it's gone into maintenance
mode), but all current DeviceKit-{power,disks} versions *need* gudev.
In summation, I say hard-enable these:
acl, keymap, hid2hci
Put gudev under a USE-flag, enabled by +use, and put the rest under
extras, not enabled by default.
1. http://fedoraproject.org/wiki/KDE_Programming_Wishlist
--
~Nirbheek Chauhan
GNOME+Mozilla Team, Gentoo
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
On Sun, 30 August 2009 Matthias Schwarzott z...@gentoo.org wrote: 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 /usr/src/linux is not the best place to look at... Checks should rather be done on first kernel config found in following locations (checked in this order): - KBUILD_OUTPUT - KERNEL_DIR - /usr/src/linux, /proc/config.gz, /lib/modules/$(uname -r)/build/.config Maybe just use linux-info eclass for the checks 2. Check /proc/config.gz This should rather happen in init script, if possible do not check on every boot but only when a new kernel is used (e.g. when uname output changes) 3. Print message for user in pkg_postinst This makes sense in any case. Second point: udev-145 bundles a lot of new extras, but they can only be enabled/disabled all or nothing. These extras are: * udev-acl: Apply consolekit permissions to devices for users (audio, video, joysticks, scanner, cameras, ...) Is this bound to consolekit or does it rather fall under 'acl' use-flag? I guess this includes a kernel requirement (ACL support for tmpfs) * usb-db: Provide udev-rules with device names of pci and usb devices * hid2hci: Special utility to fix resume of some hid devices * keymap: Auto-configure model specific keys found on many laptops (brightness up, next song, www browser, or suspend) * modem-modeswitch: Switch modems that provide virtual cd-drive with drivers to modem mode * gudev: glib/gobject support for libudev Is gudev just a binding or is it more? If it's just a binding it may be nice to have it tied to a use-flag. This makes udev depend on these libs: libacl, libglib2, libusb, usbutils, pciutils, gperf Bruno
[gentoo-dev] Re: About udev-145: new features / extras and kernel requirements
Arun Raghavan posted on Sun, 30 Aug 2009 19:54:47 +0530 as excerpted: 2009/8/30 Matthias Schwarzott z...@gentoo.org: 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 All of the above? Rationale being (1) is required to check against the kernel you're supposedly using, (2) for the kernel you definitely are using, and (3) to make sure people remember. Indeed, all of the above, but not requiring the first two only giving their status in #3. Some people don't have the kernel option enabling /proc/config.gz turned on, so #2 isn't reliable, and #1, /usr/src/linux, could point who /knows/ where, maybe something current, maybe not. (Here, it points at my local kernel git repo... which may or may not correspond to the currently running kernel, tho it's usually reasonably close, and it's usually within a few days of upstream unless I'm git bisecting some bug.) Thus, neither of the first two is reliable, but checking them and putting the status in #3 should be helpful. Another alternative, ultimately safer: add another option, and require that at least one of the three pass: 1-2 as they are. 3. Check UDEV_ASSUME_KERNEL_OPTS in the environment (could be set in make.conf for portage and compatible PMs). Then in the message corresponding to the original #3 except presumably in unpack or prepare, report status as a reminder, and die if none of the above tests pass. #3, the env var, would allow users to override without hacking the ebuild itself, if for some reason they decided they needed to. If it's the only one that passes, ewarn/eerror to the effect Relying on UDEV_ASSUME_KERNEL_OPTS override. If it breaks, you get to keep the pieces! -- 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] About udev-145: new features / extras and kernel requirements
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 Hubbs gentoo accessibility team lead willi...@gentoo.org pgpdLEnuLNcR5.pgp Description: PGP signature
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William Hubbs wrote: 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. - From the indenting I can't tell if you wrote this or not, however, we need to differentiate between running and build time environments. Ebuilding is a build-time process. That means the running kernel isn't important, since we're not running udev, we're just building it. When the machine is next rebooted, we could be using a completely different kernel (or even one that hasn't been installed yet). We should only care about the build-time kernel when we're building, which the user has to specify (which they do implicitly by using /usr/src/linux, or explicitly by using KBUILD_OUTPUT or another environment variable). If you go by the running kernel, then you're requiring people to reboot their computers before they can build software for a kernel they're about to run. That simply ensures downtime on a potentially critical service, and moreover it's an unnecessary constraint. The existing udev can continue running until the machine is rebooted without a problem. When the machine restarts *any* kernel could be chosen, and build time checks won't help prevent a bad kernel from being booted. That's why the linux-info.eclass does the checks it currently does, and *doesn't* check /proc/config.gz and *doesn't* check /$(uname -r)/ directories... So in summary: * Check the running kernel if you're about to run. * Check the kernel the user's chosen to build against if you're about to build, using linux-info. If the ebuild restarts the service (causing a reread off disk, rather than just a reread of the rules) then fine, use the check to disable the restart, and/or warn the user, but don't stop the user from building the software. You can also put a check in the init.d, but it just creates the possibility that the check is wrong when udev could potentially still run. I'd simply try running udev and check if it exits or errors as expected. Only if it doesn't exit or error when it should would I add checks to the initscript, and even then I'd suggest fixing the code to error correctly, over adding our own checks in... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqapk4ACgkQu7rWomwgFXqDbACgtYdXtmlgo6JA49o9on111XPE Y/QAnROtzEhAUg0ML9J+nd6rTvKfZeFz =pbOj -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] Deprecation of Python 2.4
On Sun, 30 Aug 2009 12:14:53 +0300 Petteri Räty betelge...@gentoo.org wrote: Arfrever Frehtes Taifersar Arahesis wrote: Python 2.4 is deprecated. There are plans to mask for removal it when remaining packages incompatible with Python 2.5 are fixed. (We will announce masking of Python 2.4 at least 1 month before masking it.) Please don't add new packages to the tree which work only with Python 2.4. If you want to add a package which depends on a Python module, which had been maintained separately in the past, but has been also included in Python 2.5, then don't add this Python module to the tree only for use with Python 2.4, but instead depend on Python =2.5. Where's the CC and Reply-To to gentoo-dev? Does removing python 2.4 have any effect on the upgrade path for old installations? Any upgrade path was destroyed when all python versions (including 2.4) moved to EAPI != 0. -- fonts, toolchain, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
Hi, While writing and using some ebuilds, I had to deal with (pseudo) USE flags requirements. For example, if you install mplayer with USE=encode the result will depend on other USE flags: if you have USE=encode mp3, it will install lame for example. I know a few ebuilds behave like that in the tree. We can also see some ebuilds that will force an option if you set another one: if you set USE=-foo +bar and bar needs foo, it will silently set --enable-foo. Finally, they are some ebuilds like =ekiga-3 that will just fail if you have two USE flags conflicting: kontact needs kde so USE=kde -kontact and USE=kde kontact are okay but USE=-kde kontact will fail. In my opinion, we can't keep auto-enabling some options because the user has enabled another option without telling him and without telling the package manager. For example, I'm a lambda user, I've set USE=kontact but I don't know it's related to KDE, I don't have a KDE desktop and I don't want one. With the regular behavior in the tree, kde will be enabled silently and the user will don't have a clue about it like the package manager. This last one is even worst because if we imagine a library ebuild with this behavior used by other ebuilds in the tree, EAPI-2 use dependencies will break. (foo ebuild depends on ekiga[kde], user will have to rebuild ekiga if it has been built with USE=-kde kontact even if ekiga has been built with kde support or foo ebuild depends on mplayer[mp3] should be mplayer[encode,mp3]. However, dying is probably not the best solution too. 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 the user if he set USE=kontact, kde USE flag is enabled and the PM will enable this USE flag by himself. I think this new feature should help everyones life. We can also imagine great features like a minimal USE-flag that will be something like: USE_REQUIREMENTS=minimal? ( foo bar ) to set a list of USE flags to disable if minimal USE flag is enabled. Combined to EAPI-1 auto-enabled USE flags, it could help disabling all auto-enabled USE flags for some uses... That's just an idea. I'm not writing a GLEP draft so don't try to found an issue in the syntax used, it's only to know if this kind of feature will be appreciated by other users/devs than me and if it could be added to EAPI-4 and worth to work on it. I can write the GLEP and implement the feature in portage. [1] http://www.exherbo.org/docs/exheres-for-smarties.html#myoptions Thanks, Mounir
[gentoo-dev] Re: [gentoo-dev-announce] Deprecation of Python 2.4
2009-08-30 11:14:53 Petteri Räty napisał(a): Arfrever Frehtes Taifersar Arahesis wrote: Python 2.4 is deprecated. There are plans to mask for removal it when remaining packages incompatible with Python 2.5 are fixed. (We will announce masking of Python 2.4 at least 1 month before masking it.) Please don't add new packages to the tree which work only with Python 2.4. If you want to add a package which depends on a Python module, which had been maintained separately in the past, but has been also included in Python 2.5, then don't add this Python module to the tree only for use with Python 2.4, but instead depend on Python =2.5. Where's the CC and Reply-To to gentoo-dev? Does removing python 2.4 have any effect on the upgrade path for old installations? sys-apps/portage-2.1.4.5 should work with Python 2.5 and probably also 2.6. sys-apps/portage-2.1.6.7 works with Python 2.5 and 2.6. =sys-apps/portage-2.1.6.13 works with Python 2.5 and 2.6 and doesn't work with Python 2.4. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
On Sun, Aug 30, 2009 at 07:06:02PM +0200, Mounir Lamouri wrote: Hi, snip However, dying is probably not the best solution too. 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 the user if he set USE=kontact, kde USE flag is enabled and the PM will enable this USE flag by himself. I'm not sure acting as if the user didn't enable the USE flag is the best option. If I manually enable the bar USE-flag I might not expect there to be an issue and not notice that it has been silently ignored. In general I think we should take the approach that if we can't give a user what he/she asked for we should error out and tell him/her that there was a problem and that such-and-such needs to be changed. I'm not writing a GLEP draft so don't try to found an issue in the syntax used, it's only to know if this kind of feature will be appreciated by other users/devs than me and if it could be added to EAPI-4 and worth to work on it. I can write the GLEP and implement the feature in portage. I very much would like this feature. I've been using it in Exherbo and it's quite useful so far. Only thing is that it'll be possible to do this sort of thing(only you'll have to || die) with EAPI-3 as a 'if use foo; then use bar || die foo needs bar'. The question is whether it is worth it to have this special construct for USE-flag combinations(there're far more possibilities than the one I gave), and I'd say it is worth it. [1] http://www.exherbo.org/docs/exheres-for-smarties.html#myoptions Thanks, Mounir Regards, Thomas -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgpC6dfSRDZwM.pgp Description: PGP signature
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
On Sun, Aug 30, 2009 at 05:05:05PM +0200, Bruno wrote: Is this bound to consolekit or does it rather fall under 'acl' use-flag? I guess this includes a kernel requirement (ACL support for tmpfs) Yes, this would imply CONFIG_TMPFS_POSIX_ACL to actually be used. * usb-db: Provide udev-rules with device names of pci and usb devices * hid2hci: Special utility to fix resume of some hid devices * keymap: Auto-configure model specific keys found on many laptops (brightness up, next song, www browser, or suspend) * modem-modeswitch: Switch modems that provide virtual cd-drive with drivers to modem mode * gudev: glib/gobject support for libudev Is gudev just a binding or is it more? If it's just a binding it may be nice to have it tied to a use-flag. USE=glib has a couple of packages already, and this looks like another good one for it. This makes udev depend on these libs: libacl, libglib2, libusb, usbutils, pciutils, gperf dev-util/gperf is not a lib. It's one of those packages that should almost NEVER be seen in RDEPEND even, as it generates C/C++ during build time only. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpH1PMbWGvYu.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
On Sun, Aug 30, 2009 at 10:36 PM, Mounir Lamourivolk...@gentoo.org wrote:
I think this new feature should help everyones life. We can also imagine
great features like a minimal USE-flag that will be something like:
USE_REQUIREMENTS=minimal? ( foo bar ) to set a list of USE flags to
disable if minimal USE flag is enabled. Combined to EAPI-1 auto-enabled
USE flags, it could help disabling all auto-enabled USE flags for some
uses... That's just an idea.
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.
1. http://bugs.gentoo.org/show_bug.cgi?id=251179
--
~Nirbheek Chauhan
GNOME+Mozilla Team, Gentoo
[gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
Seeing the debate raised in the udev thread about checking for the kernel, I'd like to propose that we revise the linux-info.eclass. linux-info already checks a number of locations: - KBUILD_OUTPUT, - KERNEL_DIR, which defaults to /usr/src/linux/ - OUTPUT_DIR, which defaults to /lib/modules/`uname -r`/build/ It does NOT check /proc/config.gz presently. The original logic against not checking /proc was that we were targeting the kernel being built, but that's moot given the use of `uname -r` in OUTPUT_DIR. Additionally, linux-info.eclass already has provisions for non-fatally checking for kernel config options, by prefixing them with a tilde. In parallel to what we actually check, we have the issue of systems that may not have ANY of the above, or ANY kernel sources whatsoever. The most common amongst these are: - Hardened systems - Virtual Machines Proposed solution: -- We need to be able to reduce user error, so we cannot simply make it trust the user by default. So I propose that we add an environment variable (I'm not set on the name yet), eg: EXTERNALLY_BUILT_KERNEL=1 This option will cause linux-info.eclass to consider ALL kernel option checks non-fatal. That way we still get the warnings and logs, but it does not stop the builds. When is the above NOT enough? - The only time that ANY kernel sources are required is when you are building an out-of-tree module. For this purpose, they must be configured. The check for having configured kernel sources must only be executed when the modules are about to be compiled. Putting it in pkg_preinst would block use of binpkgs on (related) machines. - If a package builds modules AND userspace, we should offer a way to build the userspace only, as the user can build their modules externally (or patch them into the kernel) [1] - For packages that ONLY build modules, and no userspace at all, having EXTERNALLY_BUILT_KERNEL=1 means that they should error out? [2] (this case might be thrown into the above one). Footnotes: -- 1. This has already been requested for ipset, bug #274577. 2. What about documentation? Is that enough of userspace still? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgphnpgtI4Etg.pgp Description: PGP signature
[gentoo-dev] Road towards EAPI 3 main tree approval
As many of you know EAPI 3 has been waiting for Portage to implement it for many months now and I asked zmedico for his estimate on whether it will be done this year: 19:50 Betelgeuse zmedico: Let's put it this way. How likely in percentages is EAPI 2 this year? 19:50 Betelgeuse s/2/3/ 19:51 zmedico I'd give it 80% chance I guess As far as I understand paludis already has the features implemented so maybe we could give EAPI 3 some field testing in some overlays to see how it works in practice from ebuild writer point of view. Paludis does not recognize it atm but probably easy to get a new revision/version out: 20:01 zmedico Betelgeuse: I'd guess they could test it as EAPI=paludis-3_pre or something like that 20:01 dleverton Betelgeuse: it doesn't install the config file, just uses it for tests, so that's correct So what's the general sentiment for giving this some spin in overlays? Maybe having some usage would build some social pressure on zmedico :) Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
It does NOT check /proc/config.gz presently. The original logic against
not checking /proc was that we were targeting the kernel being built,
but that's moot given the use of `uname -r` in OUTPUT_DIR.
I might be reading the eclass wrong, but it looks as though OUTPUT_DIR
is only set to use uname -r if the KV_* variables match the output of
uname -r:
[ ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA} == $(uname -r) ] \
OUTPUT_DIR=${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}
Otherwise it's taken from the KBUILD_DIR and then it even checks inside
the KV_DIR's Makefile to find one. So not checking /proc/config.gz
isn't a moot point anymore, which is not to say it's not a good idea,
but the reason against doing it still stands. To deal with running
kernel's, there's a get_running_version function, that will use uname to
fill out the KV_* variables appropriately.
Proposed solution:
--
We need to be able to reduce user error, so we cannot simply make it
trust the user by default. So I propose that we add an environment
variable (I'm not set on the name yet), eg:
EXTERNALLY_BUILT_KERNEL=1
This option will cause linux-info.eclass to consider ALL kernel option
checks non-fatal. That way we still get the warnings and logs, but it
does not stop the builds.
I'm not sure what this is solving? It doesn't seem to reduce user
error, it just allows users a way to override portage errors? It seems
unrelated to config.gz and the discussion going on in the previous
thread. I do like the idea of being able to override portage when it's
stopping us from building (incorrectly), but surely with the capability
to have non-fatal checks, we can try to minimize the times when
portage/the ebuild is wrong using that, instead of a whole new override?
When is the above NOT enough?
-
The only time that ANY kernel sources are required is when you are
building an out-of-tree module. For this purpose, they must be
configured.
There's a lot of ebuilds that use linux-info, and they can't all be
out-of-tree modules. Are they misusing linux-info, or are you saying
there's a specific instance in which linux-info requires configured
kernel sources?
The check for having configured kernel sources must only be executed
when the modules are about to be compiled. Putting it in pkg_preinst
would block use of binpkgs on (related) machines.
- If a package builds modules AND userspace, we should offer a way to
build the userspace only, as the user can build their modules
externally (or patch them into the kernel) [1]
- For packages that ONLY build modules, and no userspace at all, having
EXTERNALLY_BUILT_KERNEL=1 means that they should error out? [2]
(this case might be thrown into the above one).
That all seems fine, but again these just seem like standard guidelines.
Is there not already some how to write kernel module ebuilds page
somewhere that documents how you're supposed to use linux-info?
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkqa30QACgkQu7rWomwgFXo99gCfd8NbK9QkxtJ9BKalq/n1iBxn
l0QAoLiBsvKXZRzR4Dp8HEtoxrsONCtc
=ZK9i
-END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
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 the 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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Road towards EAPI 3 main tree approval
On Sun, 30 Aug 2009 23:03:42 +0300
Petteri Räty betelge...@gentoo.org wrote:
As far as I understand paludis already has the features implemented so
maybe we could give EAPI 3 some field testing in some overlays to see
how it works in practice from ebuild writer point of view.
The main issue with that is eclasses. Quite a few eclasses have
hard-coded lists of 'case ${EAPI:-0} in' lists. These would need to be
updated. So if you go this route:
20:01 zmedico Betelgeuse: I'd guess they could test it as
EAPI=paludis-3_pre or something like that
then you'll have to clutter up the main tree with paludis-3_pre. And if
instead you call it '3', it means we have to guarantee we're not going
to make any last minute changes.
Also, as I recall there're two outstanding issues with EAPI 3 that
would need to be addressed by the Council.
First, there's the question of package.mask etc as directories. Some
people were after either doing a quicky EAPI 2.1 or reopening EAPI 3 to
allow that for the 10.0 profiles. I don't know whether that's still
considered worth doing or whether it's an EAPI 4 thing.
Second, there's the issue with 'nonfatal' and 'die' [1]. EAPI 3 as
originally worded made 'die' ignore 'nonfatal' (so that people wouldn't
have to modify all their eclass functions to take into account that
suddenly callers could override their dies), but some crappy wording in
the original spec (which has been addressed) meant that some people
didn't realise that, and would prefer it if we did that differently.
Paludis does not recognize it atm but probably easy to get a new
revision/version out:
Yup, can do that easily enough if there's interest once the above has
been addressed.
[1]:
http://archives.gentoo.org/gentoo-dev/msg_358b12a494173ab82f3e7d1b2b6b5bf9.xml
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
On Sun, Aug 30, 2009 at 09:21:24PM +0100, Mike Auty wrote:
[ ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA} == $(uname -r) ] \
OUTPUT_DIR=${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}
This check is inside the get_version call, and is ultimately used to set
KV_OUT_DIR, which is in turn used for all the config checks.
The conditional part of the check means that it's only used if the
running kernel is also the one currently pointed to by the sources
variables (which were used further up in the function to populate KV_*).
I also realize on closer reading, that the above bit will never even be
reached unless the kernel sources are present.
Otherwise it's taken from the KBUILD_DIR and then it even checks inside
the KV_DIR's Makefile to find one. So not checking /proc/config.gz
isn't a moot point anymore, which is not to say it's not a good idea,
but the reason against doing it still stands. To deal with running
kernel's, there's a get_running_version function, that will use uname to
fill out the KV_* variables appropriately.
FYI:
get_running_version is used in one single ebuild, in the entire tree:
sys-fs/evms/evms-2.5.5-r10.ebuild
And there it's only for a warning.
Proposed solution:
--
We need to be able to reduce user error, so we cannot simply make it
trust the user by default. So I propose that we add an environment
variable (I'm not set on the name yet), eg:
EXTERNALLY_BUILT_KERNEL=1
This option will cause linux-info.eclass to consider ALL kernel option
checks non-fatal. That way we still get the warnings and logs, but it
does not stop the builds.
I'm not sure what this is solving? It doesn't seem to reduce user
error, it just allows users a way to override portage errors? It seems
unrelated to config.gz and the discussion going on in the previous
thread. I do like the idea of being able to override portage when it's
stopping us from building (incorrectly), but surely with the capability
to have non-fatal checks, we can try to minimize the times when
portage/the ebuild is wrong using that, instead of a whole new override?
The great majority of CONFIG_CHECK usage in the tree is fatal already.
It only actually needs to be fatal only when it's being used to build a
module.
However, past bugs have shown lots of users complaining that a package
doesn't work, simply because they did not have the relevant option
enabled in their kernel.
This leaves us between hand-holding the basic user's kernel configuration
(exiting if the kernel config option is not enabled), and changing all
non-module instances in the tree to be non-fatal.
If we make all the non-module uses non-fatal, there will be an increase of bugs
due to users not reading the warnings.
When is the above NOT enough?
-
The only time that ANY kernel sources are required is when you are
building an out-of-tree module. For this purpose, they must be
configured.
There's a lot of ebuilds that use linux-info, and they can't all be
out-of-tree modules. Are they misusing linux-info, or are you saying
there's a specific instance in which linux-info requires configured
kernel sources?
Here's a few that I know of, off the top of my head:
app-mobilephone/gnokii/gnokii-0.6.27-r4.ebuild:
CONFIG_CHECK=UNIX98_PTYS
/usr/portage/net-print/hplip/hplip-3.9.4b-r1.ebuild:
CONFIG_CHECK=PARPORT PPDEV
/usr/portage/net-firewall/conntrack-tools/conntrack-tools-0.9.13.ebuild:
CONFIG_CHECK=IP_NF_CONNTRACK_NETLINK
CONFIG_CHECK=NF_CT_NETLINK
CONFIG_CHECK=${CONFIG_CHECK} NF_CONNTRACK
linux_chkconfig_present NF_CONNTRACK_IPV4 || \
linux_chkconfig_present NF_CONNTRACK_IPV6 || \
If you don't have configured kernel sources, all of these ebuilds fail right
now. They are not building modules, simply userspace. The CONFIG_CHECK elements
are not prefixed with tilde to make them non-fatal.
conntrack-tools is actually even worse, as it has a kernel version check before
the config checks, which would also fail without kernel sources.
The check for having configured kernel sources must only be executed
when the modules are about to be compiled. Putting it in pkg_preinst
would block use of binpkgs on (related) machines.
- If a package builds modules AND userspace, we should offer a way to
build the userspace only, as the user can build their modules
externally (or patch them into the kernel) [1]
- For packages that ONLY build modules, and no userspace at all, having
EXTERNALLY_BUILT_KERNEL=1 means that they should error out? [2]
(this case might be thrown into the above one).
That all seems fine, but again these just seem like standard guidelines.
Is there not already some how to write kernel module ebuilds page
somewhere that documents how you're supposed to use linux-info?
If you're building modules, most of the time you're using linux-mod, not just
linux-info. There's no document or
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: FYI: get_running_version is used in one single ebuild, in the entire tree: sys-fs/evms/evms-2.5.5-r10.ebuild And there it's only for a warning. Ok, I was just suggesting that if there was an intention to implement config.gz checks, they should only apply when people ask about the running version rather than the build version. Since that doesn't seem popular or even necessary, perhaps neither is the need to check config.gz? The great majority of CONFIG_CHECK usage in the tree is fatal already. It only actually needs to be fatal only when it's being used to build a module. Ok, I see what you're suggesting now. When people want to build packages, but portage knows their kernel isn't setup to run them properly, then it should still build them, but warn them strongly about it (as opposed to currently, where it'll just die). This leaves us between hand-holding the basic user's kernel configuration (exiting if the kernel config option is not enabled), and changing all non-module instances in the tree to be non-fatal. Ok, so then the question is do we sacrifice correctness for fewer (invalid) bugs? Seems like a judgement call. For what it's worth, I'm not sure adding extra plumbing to allow smart users to bypass the checks is the right middle ground. I'd either leave it as is, or change the ebuilds to accurately reflect whether the userspace will build or not. That all seems fine, but again these just seem like standard guidelines. Is there not already some how to write kernel module ebuilds page somewhere that documents how you're supposed to use linux-info? If you're building modules, most of the time you're using linux-mod, not just linux-info. There's no document or recommended behavior in the tree for the above actually, and I'd like to introduce one. Sounds like a good idea, it might also be worth adding to the quizes, if existing devs are asking how it should be done? I guess that's a call on how common it is to have kernel config requirements on userspace... Still, I think I'm on the right page, and even in agreement (which makes me happy). 5:) Thanks! Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqa9gkACgkQu7rWomwgFXq1PwCfTbp8hqsGZjDmsxKE21gKe1Y8 lYYAoI2EBCn5KwQdlm6Xd8u0q7KGl7gI =Jrsa -END PGP SIGNATURE-
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
On Sun, Aug 30, 2009 at 10:58:33PM +0100, Mike Auty wrote: Robin H. Johnson wrote: FYI: get_running_version is used in one single ebuild, in the entire tree: sys-fs/evms/evms-2.5.5-r10.ebuild And there it's only for a warning. Ok, I was just suggesting that if there was an intention to implement config.gz checks, they should only apply when people ask about the running version rather than the build version. Since that doesn't seem popular or even necessary, perhaps neither is the need to check config.gz? The running version stuff may be needed to be used more than it is presently. If no kernel sources are present at all, all functions that check the kernel version presently bail out. get_version is also at the very top of linux-info's pkg_setup function, so it bails as well: * Determining the location of the kernel source code * Unable to find kernel sources at /usr/src/linux ... The existing state is: - Force the user to install sources Our choices are: - `uname -r` output. - Create an override environment variable for all the checks. /proc/config.gz comes back here again, in that, we can use it as a middle ground with `uname -r`, rather than having the environment variable. So from our discussion, I propose the following: Finding the kernel version: --- 0. (optional) give an env var to bypass entirely. 1. Use existing logic of /usr/src/linux, KERNEL_DIR et al. 2. Fall back to using the running version, with a warning. Checking a configuration option, for non-module use: 0. (optional) give an env var to make all checks non-fatal. 1. Use existing logic of .config from /usr/src/linux, KERNEL_DIR et al. 2. Fall back to /proc/config.gz if available. The great majority of CONFIG_CHECK usage in the tree is fatal already. It only actually needs to be fatal only when it's being used to build a module. Ok, I see what you're suggesting now. When people want to build packages, but portage knows their kernel isn't setup to run them properly, then it should still build them, but warn them strongly about it (as opposed to currently, where it'll just die). Two different cases here: 1. Portage knows their kernel is not setup correctly. 2. Portage cannot find out enough info. It's #2 that bites on virtual machines and hardened servers, and is what I'd like to fix. This leaves us between hand-holding the basic user's kernel configuration (exiting if the kernel config option is not enabled), and changing all non-module instances in the tree to be non-fatal. Ok, so then the question is do we sacrifice correctness for fewer (invalid) bugs? Seems like a judgement call. For what it's worth, I'm not sure adding extra plumbing to allow smart users to bypass the checks is the right middle ground. I'd either leave it as is, or change the ebuilds to accurately reflect whether the userspace will build or not. It's a one-liner to give an override making all checks non-fatal, with the downside that it can't differentiate why the checks are being made. So yes, in the case we should simply fix all of the ebuilds (after the kernel source check is fixed as well). If you're building modules, most of the time you're using linux-mod, not just linux-info. There's no document or recommended behavior in the tree for the above actually, and I'd like to introduce one. Sounds like a good idea, it might also be worth adding to the quizes, if existing devs are asking how it should be done? I guess that's a call on how common it is to have kernel config requirements on userspace... 142 packages inherit linux-mod. 130 packages use functions or the MODULE_NAMES code from linux-mod. 105 packages inherit linux-info. 11 packages inherit both linux-info AND linux-mod. So I propose this as resolutions from the above: 1. USE=modules added to the base profile. 2. Every package that builds kernel modules must offer USE=modules, which can be used to disable building the kernel modules, leaving a pure userspace build of that package. Most of the changes to the above can be done in the linux-mod eclass, so I don't think we'll have to touch that many packages directly. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpshiQ2Mw61x.pgp Description: PGP signature
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: The existing state is: - Force the user to install sources Our choices are: - `uname -r` output. - Create an override environment variable for all the checks. /proc/config.gz comes back here again, in that, we can use it as a middle ground with `uname -r`, rather than having the environment variable. Ok, that seems a very reasonable use. So from our discussion, I propose the following: Finding the kernel version: --- 0. (optional) give an env var to bypass entirely. 1. Use existing logic of /usr/src/linux, KERNEL_DIR et al. 2. Fall back to using the running version, with a warning. Checking a configuration option, for non-module use: 0. (optional) give an env var to make all checks non-fatal. 1. Use existing logic of .config from /usr/src/linux, KERNEL_DIR et al. 2. Fall back to /proc/config.gz if available. Where 2 also issues a warning, presumably? I've had a think and can't see any repercussions in changing the default behaviour, but I'm assuming people would only generally hit 2 with virtual machines and/or hardened servers. Can you see either of these suffering from defaulting to the running kernel? Do you know of many circumstances where 2 might get hit by normal users other than those situations? Also (and potentially off-topic), if we're using linux-info to detect kernel sources, whether installed or not, should we also check the tree for ebuilds that require a package which PROVIDES=sources? I personally use a single git checkout, since I think (possibly mistakenly, I honestly haven't checked) that it will leave different checkouts of the kernel all over my /usr/src directory, whenever a new version's emerged. I've had to create a fake-sources package to trick ebuilds that need *some* sources installed, and I'm wondering if that should be necessary? Two different cases here: 1. Portage knows their kernel is not setup correctly. 2. Portage cannot find out enough info. It's #2 that bites on virtual machines and hardened servers, and is what I'd like to fix. Ok, I'm all for it, and the solution you've suggested sounds fine. It's a one-liner to give an override making all checks non-fatal, with the downside that it can't differentiate why the checks are being made. So yes, in the case we should simply fix all of the ebuilds (after the kernel source check is fixed as well). I'd definitely try and do things the right way, and a global override (whilst easy) doesn't sound like it. Fixing all the ebuilds (and the kernel source check) sounds like the way to go. So I propose this as resolutions from the above: 1. USE=modules added to the base profile. 2. Every package that builds kernel modules must offer USE=modules, which can be used to disable building the kernel modules, leaving a pure userspace build of that package. Most of the changes to the above can be done in the linux-mod eclass, so I don't think we'll have to touch that many packages directly. Yep, although if the changes are in linux-mod, then those packages that *only* provide kernel modules will need a way to not present that use flag (no point installing a package is USE=-modules and nothing gets installed). Also, I'd assume +modules would be added as a default. The whole plan sounds extremely sensible in general! 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqbC3oACgkQu7rWomwgFXpwywCeKzcB0Znzuul3wq9U9ew5+SuX scQAnjShkQTVQQrFABb8u2t0RsP9K34z =LFlY -END PGP SIGNATURE-
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
On Mon, Aug 31, 2009 at 12:30:02AM +0100, Mike Auty wrote: Checking a configuration option, for non-module use: 0. (optional) give an env var to make all checks non-fatal. 1. Use existing logic of .config from /usr/src/linux, KERNEL_DIR et al. 2. Fall back to /proc/config.gz if available. Where 2 also issues a warning, presumably? I've had a think and can't see any repercussions in changing the default behaviour, but I'm assuming people would only generally hit 2 with virtual machines and/or hardened servers. Can you see either of these suffering from defaulting to the running kernel? Do you know of many circumstances where 2 might get hit by normal users other than those situations? Yes, a warning with using /proc/config.gz. I missed a bit for the config option. If there is NO source of the config data, what do we do? Error out or more warnings? Also (and potentially off-topic), if we're using linux-info to detect kernel sources, whether installed or not, should we also check the tree for ebuilds that require a package which PROVIDES=sources? I personally use a single git checkout, since I think (possibly mistakenly, I honestly haven't checked) that it will leave different checkouts of the kernel all over my /usr/src directory, whenever a new version's emerged. I've had to create a fake-sources package to trick ebuilds that need *some* sources installed, and I'm wondering if that should be necessary? This is what I use for my home workstation: /etc/portage/profile/virtuals:virtual/linux-sources sys-kernel/git-sources /etc/portage/profile/virtuals:virtual/alsa sys-kernel/git-sources /etc/portage/profile/package.provided:sys-kernel/git-sources-2.6.30 Saves having any fake package like that. It's a one-liner to give an override making all checks non-fatal, with the downside that it can't differentiate why the checks are being made. So yes, in the case we should simply fix all of the ebuilds (after the kernel source check is fixed as well). I'd definitely try and do things the right way, and a global override (whilst easy) doesn't sound like it. Fixing all the ebuilds (and the kernel source check) sounds like the way to go. Want to lend a hand fixing up the ebuilds then? I'll work on the eclass sources check. So I propose this as resolutions from the above: 1. USE=modules added to the base profile. 2. Every package that builds kernel modules must offer USE=modules, which can be used to disable building the kernel modules, leaving a pure userspace build of that package. Yep, although if the changes are in linux-mod, then those packages that *only* provide kernel modules will need a way to not present that use flag (no point installing a package is USE=-modules and nothing gets installed). There IS still a point of having the entirely empty kernel package installed: - Split userspace/kernel packages where the userspace package has a dependency on the module-providing package. - other packages that might have a dependency on the module-providing package. - /etc/modprobe.d/ files. USE=-modules will ONLY block files installed to /lib/modules/. Also, I'd assume +modules would be added as a default. I'm not sure we can get away with USE-defaults for this change, due to the amount of EAPI=0 stuff that will be changing, so it'll be in profiles/base/make.defaults instead. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[gentoo-dev] New global USE flag: modules
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 Existing tree usage: app-emulation/kvm:modules - Build the kernel modules from the kvm package media-libs/libifp:modules - Build kernel modules for non-root usage sys-block/open-iscsi:modules - Build the open-iscsi kernel modules x11-drivers/ati-drivers:modules - Build the kernel modules x11-drivers/linuxwacom:modules - Build kernel module Expected impact: At least 120 packages will change, possibly as many as 140. Many of these may be simply the via the eclass. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpygiLs1lOTh.pgp Description: PGP signature
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: Yes, a warning with using /proc/config.gz. I missed a bit for the config option. If there is NO source of the config data, what do we do? Error out or more warnings? Well, if we can't determine whether a config option's set or not, if it's not critical (ie, it's ~CHECK), then we warn. If there's any hard checks, then we error out I suppose. This is what I use for my home workstation: /etc/portage/profile/virtuals:virtual/linux-sources sys-kernel/git-sources /etc/portage/profile/virtuals:virtual/alsa sys-kernel/git-sources /etc/portage/profile/package.provided:sys-kernel/git-sources-2.6.30 Saves having any fake package like that. Ah cunning, I'll have to try that... Want to lend a hand fixing up the ebuilds then? I'll work on the eclass sources check. Sure, as long as I sure I know how we're fixing them, I'd be glad to help. 5:) I'd just be fixing the userspace ones to make sure they're ~CHECK or would I be doing something else as well? Also should I do that via bugs and a week's grace period, or would you recommend I just dive right in? There IS still a point of having the entirely empty kernel package installed: - Split userspace/kernel packages where the userspace package has a dependency on the module-providing package. - other packages that might have a dependency on the module-providing package. - /etc/modprobe.d/ files. USE=-modules will ONLY block files installed to /lib/modules/. Ok, presumably USE=-modules will also stop the kernel checks, otherwise the following could occur. Let's say the foobar package builds external modules and explicitly requires that foobar not be set in the kernel. With USE=-modules, there's no internal version and there's no external version, but the kernel package is installed, and the deps are happy, even though they'll bug out when it's showtime. Presumably there's also packages that aren't split, or depended on, where not installing the modules is never a good idea. Is there still a way to disable the USE flag, or will it be a requirement of the linux-mod package? I'm not sure we can get away with USE-defaults for this change, due to the amount of EAPI=0 stuff that will be changing, so it'll be in profiles/base/make.defaults instead. That's fine, just so long as it's on and not off, I don't mind what system we use to do it. 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqbEqkACgkQu7rWomwgFXq53QCdFi8YlDrKwkh9b0g6EX2DBI35 0t0AnRRRV+oxqQaKPqzcWxGJDtW2lszQ =oia+ -END PGP SIGNATURE-
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
On Mon, Aug 31, 2009 at 01:00:41AM +0100, Mike Auty wrote: I missed a bit for the config option. If there is NO source of the config data, what do we do? Error out or more warnings? Well, if we can't determine whether a config option's set or not, if it's not critical (ie, it's ~CHECK), then we warn. If there's any hard checks, then we error out I suppose. +1. This is what I use for my home workstation: /etc/portage/profile/virtuals:virtual/linux-sources sys-kernel/git-sources /etc/portage/profile/virtuals:virtual/alsa sys-kernel/git-sources /etc/portage/profile/package.provided:sys-kernel/git-sources-2.6.30 Saves having any fake package like that. Ah cunning, I'll have to try that... We should document it in the kernel web pages. Want to lend a hand fixing up the ebuilds then? I'll work on the eclass sources check. Sure, as long as I sure I know how we're fixing them, I'd be glad to help. 5:) I'd just be fixing the userspace ones to make sure they're ~CHECK or would I be doing something else as well? Also should I do that via bugs and a week's grace period, or would you recommend I just dive right in? If you feel like reviewing ~140 packages and filing bugs for them, I won't stop you. But I'm just going to go and fix the ones that seem simple enough to me, and only file bugs for the complex ones. There IS still a point of having the entirely empty kernel package installed: - Split userspace/kernel packages where the userspace package has a dependency on the module-providing package. - other packages that might have a dependency on the module-providing package. - /etc/modprobe.d/ files. USE=-modules will ONLY block files installed to /lib/modules/. Ok, presumably USE=-modules will also stop the kernel checks, otherwise the following could occur. Let's say the foobar package builds external modules and explicitly requires that foobar not be set in the kernel. With USE=-modules, there's no internal version and there's no external version, but the kernel package is installed, and the deps are happy, even though they'll bug out when it's showtime. Err, I'm not following what you claim is the problem here? cat/foo-mod: inherit linux-mod CONFIG_CHECK=!... MODULE_NAMES= cat/foo-usr: RDEPEND=cat/foo And say foo-mod provides /dev/foo for some crazy hardware. The user sets USE=-modules because they have built cat/foo-mod on their own, into the kernel. foo-mod installs nothing, foo-usr installs fine. foo-usr runs, and /dev/foo already exists, so it gets used fine. Presumably there's also packages that aren't split, or depended on, where not installing the modules is never a good idea. Is there still a way to disable the USE flag, or will it be a requirement of the linux-mod package? It needs to be ALWAYS available. The ipset bug I linked earlier in the thread was an example of that. The userspace is useless without the kernel code, but there is nothing to stop the user patching it into their kernel and not having it as a module at all (as is the case on a couple of my work boxes, which is why the bug got filed). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpGQavFipWmZ.pgp Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-08-30 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-08-30 23h59 UTC. Removals: xfce-extra/thunar-archive 2009-08-24 09:19:17 ssuominen xfce-extra/xfce4-cpu-freq 2009-08-24 09:33:22 ssuominen xfce-extra/xfce4-xfapplet 2009-08-24 12:01:37 ssuominen xfce-extra/xfce4-smartbookmark 2009-08-24 12:15:33 ssuominen xfce-extra/xfce4-mount 2009-08-24 13:30:06 ssuominen xfce-extra/thunar-media-tags2009-08-24 13:53:17 ssuominen xfce-extra/xfce4-netload2009-08-25 07:56:52 ssuominen xfce-extra/xfce4-places 2009-08-25 07:56:52 ssuominen xfce-extra/xfce4-quicklauncher 2009-08-25 08:21:29 ssuominen xfce-extra/xfce4-eyes 2009-08-25 09:02:19 ssuominen xfce-extra/xfce4-genmon 2009-08-25 09:02:20 ssuominen xfce-extra/xfce4-battery2009-08-25 10:51:48 ssuominen xfce-extra/xfce4-cellmodem 2009-08-25 10:51:48 ssuominen xfce-extra/xfce4-notes 2009-08-25 11:42:21 ssuominen xfce-extra/xfce4-cpugraph 2009-08-25 12:35:05 ssuominen xfce-extra/xfce4-datetime 2009-08-25 12:35:05 ssuominen xfce-extra/xfce4-fsguard2009-08-25 12:35:05 ssuominen xfce-extra/xfce4-systemload 2009-08-25 13:24:21 ssuominen xfce-extra/xfce4-time-out 2009-08-25 13:24:22 ssuominen xfce-extra/xfce4-timer 2009-08-25 13:24:22 ssuominen xfce-extra/xfce4-diskperf 2009-08-25 13:49:59 ssuominen xfce-extra/xfce4-verve 2009-08-25 13:50:00 ssuominen xfce-extra/xfce4-wavelan2009-08-25 14:11:06 ssuominen xfce-extra/xfce4-mailwatch 2009-08-25 15:47:43 ssuominen xfce-extra/xfce4-modemlights2009-08-25 15:47:44 ssuominen xfce-extra/xfce4-weather2009-08-25 15:47:44 ssuominen media-sound/gnusound2009-08-27 22:02:26 ssuominen Additions: xfce-extra/thunar-archive-plugin2009-08-24 09:17:21 ssuominen xfce-extra/xfce4-cpufreq-plugin 2009-08-24 09:31:19 ssuominen xfce-extra/xfswitch-plugin 2009-08-24 09:51:48 ssuominen xfce-extra/xfce4-gvfs-mount 2009-08-24 10:03:55 ssuominen xfce-extra/xfce4-xfapplet-plugin2009-08-24 11:59:32 ssuominen xfce-extra/xfce4-smartbookmark-plugin 2009-08-24 12:13:09 ssuominen net-misc/modemmanager 2009-08-24 13:19:04 dagger net-misc/ofono 2009-08-24 13:20:40 dagger net-misc/mobile-broadband-provider-info 2009-08-24 13:21:52 dagger net-misc/connman2009-08-24 13:24:08 dagger gnome-extra/connman-gnome 2009-08-24 13:25:24 dagger xfce-extra/xfce4-mount-plugin 2009-08-24 13:28:44 ssuominen xfce-extra/thunar-media-tags-plugin 2009-08-24 13:52:40 ssuominen app-i18n/ibus-qt2009-08-24 15:00:19 matsuu xfce-extra/xfce4-places-plugin 2009-08-25 07:47:20 ssuominen xfce-extra/xfce4-netload-plugin 2009-08-25 07:52:46 ssuominen xfce-extra/xfce4-quicklauncher-plugin 2009-08-25 08:20:36 ssuominen xfce-extra/xfce4-eyes-plugin2009-08-25 08:43:52 ssuominen xfce-extra/xfce4-genmon-plugin 2009-08-25 08:52:26 ssuominen xfce-extra/xfce4-cellmodem-plugin 2009-08-25 10:23:47 ssuominen xfce-extra/xfce4-battery-plugin 2009-08-25 10:34:19 ssuominen xfce-extra/xfce4-notes-plugin 2009-08-25 11:26:09 ssuominen xfce-extra/xfce4-cpugraph-plugin2009-08-25 12:15:35 ssuominen xfce-extra/xfce4-fsguard-plugin 2009-08-25 12:25:16 ssuominen xfce-extra/xfce4-datetime-plugin2009-08-25 12:32:41 ssuominen xfce-extra/xfce4-systemload-plugin 2009-08-25 13:03:49 ssuominen xfce-extra/xfce4-time-out-plugin2009-08-25 13:13:15 ssuominen xfce-extra/xfce4-timer-plugin 2009-08-25 13:22:44 ssuominen xfce-extra/xfce4-verve-plugin 2009-08-25 13:32:21 ssuominen xfce-extra/xfce4-diskperf-plugin2009-08-25 13:38:35 ssuominen xfce-extra/xfce4-wavelan-plugin 2009-08-25 14:05:05 ssuominen xfce-extra/xfce4-weather-plugin 2009-08-25 15:03:36 ssuominen xfce-extra/xfce4-modemlights-plugin 2009-08-25 15:33:18 ssuominen xfce-extra/xfce4-mailwatch-plugin 2009-08-25 15:45:51 ssuominen dev-perl/common-sense 2009-08-25 17:43:07 robbat2 games-puzzle/zaz2009-08-26 05:50:27 mr_bones_ gnome-extra/indicator-applet2009-08-26 06:13:22 ssuominen net-im/indicator-messages 2009-08-26 06:29:29 ssuominen xfce-extra/xfce4-linelight-plugin 2009-08-26
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: If you feel like reviewing ~140 packages and filing bugs for them, I won't stop you. But I'm just going to go and fix the ones that seem simple enough to me, and only file bugs for the complex ones. Ok, I'll do what I can tomorrow. I'm off to bed now... 5:) Err, I'm not following what you claim is the problem here? cat/foo-mod: inherit linux-mod CONFIG_CHECK=!option ... The user sets USE=-modules because they have built cat/foo-mod on their own, into the kernel. foo-mod installs nothing Just checking that it will actually install nothing, rather than failing out with an error because the kernel has option set. I'm just re-iterating that CONFIG_CHECK should only occur if USE=modules. If USE=-modules, then the CONFIG_CHECK options should probably be ignored shouldn't they? It needs to be ALWAYS available. The ipset bug I linked earlier in the thread was an example of that. The userspace is useless without the kernel code, but there is nothing to stop the user patching it into their kernel and not having it as a module at all (as is the case on a couple of my work boxes, which is why the bug got filed). Ok, fair enough. However, in that instance, ipset is a userspace dependency, I was talking about kernel modules that have no userspace dependencies. I suppose there could be a case where someone is trying to custom build a userspace tool that isn't in portage yet, but I still think it might cause confusion to allow USE=modules on kernel modules (without any dependencies) that then install nothing. I'm wondering which will cause more bugs to be filed? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqbHEEACgkQu7rWomwgFXrEpQCeIMWofCtvwHKJoZsb3/qUyLcP tTUAoIb3Sr645x6NY82LXK6i/3g75NF5 =uaOB -END PGP SIGNATURE-
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
In summation, I say hard-enable these: acl Please don't do this. It would force installation of sys-apps/acl to any user which I think is not desired by everybody. I'd rather like to see this being enabled by either the acl or the consolekit USE flag. Lars Wendler (Polynomial-C) Gentoo Staffer and bug-wrangler signature.asc Description: This is a digitally signed message part.
