Re: [gentoo-dev] rfc: udev-rules.eclass
On Thu, 12 Jul 2012 13:01:21 +0800 Ben de Groot yng...@gentoo.org wrote: On 12 July 2012 07:42, William Hubbs willi...@gentoo.org wrote: On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: Il 11/07/2012 21:11, William Hubbs ha scritto: I am about to release udev-186-r1, which will move everything currently in /lib/udev to /usr/lib/udev. Unless you're going to establish a symlink, please keep it under p.mask until everything is using some common code — otherwise things _will_ break. Since multiple packages put things in /lib/udev, I'm not sure it is possible to establish a symlink from /lib/udev to /usr/lib/udev if that's what you mean; I'll look into it though. Couldn't you, on udev upgrade, move everything in /lib/udev to /usr/lib/udev, and then make the symlink? Seems fairly simple to me, but maybe I'm overlooking something? You are overlooking conflicts introduced through moving files without updating vardb. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: udev-rules.eclass
On 07/12/2012 12:17 AM, Michał Górny wrote: On Thu, 12 Jul 2012 13:01:21 +0800 Ben de Groot yng...@gentoo.org wrote: On 12 July 2012 07:42, William Hubbs willi...@gentoo.org wrote: On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: Il 11/07/2012 21:11, William Hubbs ha scritto: I am about to release udev-186-r1, which will move everything currently in /lib/udev to /usr/lib/udev. Unless you're going to establish a symlink, please keep it under p.mask until everything is using some common code — otherwise things _will_ break. Since multiple packages put things in /lib/udev, I'm not sure it is possible to establish a symlink from /lib/udev to /usr/lib/udev if that's what you mean; I'll look into it though. Couldn't you, on udev upgrade, move everything in /lib/udev to /usr/lib/udev, and then make the symlink? Seems fairly simple to me, but maybe I'm overlooking something? You are overlooking conflicts introduced through moving files without updating vardb. Maybe that's package manager dependent. I think it should work fine with Portage though. -- Thanks, Zac
Re: [gentoo-dev] Portage Output / End User Experience
On Thu, Jul 12, 2012 at 12:17 AM, Ben de Groot yng...@gentoo.org wrote: Actually, there is another workable solution, and that is to set USE=-gstreamer -icu for qt-webkit. Currently we enable gstreamer by default in the ebuild (as it is used for HTML5 audio/video, which is expected functionality in qt-webkit based web browsers etc.), but we are considering if we should perhaps not enable this by default. As discussed on the bug, this will likely help some, but it doesn't help anybody who uses KDE or Gnome. I'd normally suggest a news item, and that would make sense BEFORE making changes like this, but at this point it is a bit like fixing the doors after the horses have already left. It won't even help new users much - their difficulty will be getting these packages installed, so unless we just broadcast it to everybody just in case they want to install qt and chromium, it isn't going to be effective. We almost need some kind of news mechanism for people who are about to install something. Rich
Re: [gentoo-dev] Portage Output / End User Experience
On 12 July 2012 17:52, Rich Freeman ri...@gentoo.org wrote: On Thu, Jul 12, 2012 at 12:17 AM, Ben de Groot yng...@gentoo.org wrote: Actually, there is another workable solution, and that is to set USE=-gstreamer -icu for qt-webkit. Currently we enable gstreamer by default in the ebuild (as it is used for HTML5 audio/video, which is expected functionality in qt-webkit based web browsers etc.), but we are considering if we should perhaps not enable this by default. As discussed on the bug, this will likely help some, but it doesn't help anybody who uses KDE or Gnome. As far as I know the gstreamer useflag is only enabled in the gnome profile, not the kde one currently. Once we decide on this, I will add it to the Qt FAQ (now on the wiki) and make an announcement on the forums. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] udev - mdev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/07/12 11:40 PM, Walter Dnes wrote: On Wed, Jul 11, 2012 at 09:49:18AM -0400, Michael Mol wrote Walter Dnes (very active over in gentoo-user) has put a lot of work into testing and documenting mdev as an alternative for udev. There's been a good deal of success there, up to and including it working with GNOME 2. The work's been documented on the wiki: https://wiki.gentoo.org/wiki/Mdev I'm now testing automount under mdev. No GUI required. I hope to have a wiki page up soon. As for GNOME and KDE, they're trying to become OS's in their own right. What can I say? There are a lot of alternative desktop environments and window managers. That's my target. Out of curiosity, since mdev is (i assume) more than complete enough to handle mounting, would it be possible to initially start with mdev and then hand over control to udev (if there was a need for udev, that is) , to avoid initramfs with separate /usr ? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/+0x0ACgkQ2ugaI38ACPB1zwD/UTRcKHG91/q9RyovsvChaPWE voF+oOAl5mE6A6hoN5UA/12KAC5XHModBZqNkWYuMqpB2q67t4fWHhp/w5lL7u7Z =3uUp -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Output / End User Experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 12:17 AM, Ben de Groot wrote: On 12 July 2012 06:51, Zac Medico zmed...@gentoo.org wrote: Here's another related bug report, specifically about the solving the libxml2/qt-webkit/chromium conflict: https://bugs.gentoo.org/show_bug.cgi?id=426222 -- Actually, there is another workable solution, and that is to set USE=-gstreamer -icu for qt-webkit. Currently we enable gstreamer by default in the ebuild (as it is used for HTML5 audio/video, which is expected functionality in qt-webkit based web browsers etc.), but we are considering if we should perhaps not enable this by default. Would the conflict go away if the rdeps of qt-webkit (these browsers) still had a use dep on gstreamer? IE, do these browsers tend to be installed even though the user's installed/installing chromium ? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/+04gACgkQ2ugaI38ACPDRUAD+MgphaweWeoPKBrZEJRY3LsTK pfBUoCujOvXgicioP4EA/18m849xCRC3lXrjF1fbKBurQuqt56zvk5HQ/kWbhAlC =6EZF -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: udev-rules.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 01:01 AM, Ben de Groot wrote: On 12 July 2012 07:42, William Hubbs willi...@gentoo.org wrote: On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: Il 11/07/2012 21:11, William Hubbs ha scritto: I am about to release udev-186-r1, which will move everything currently in /lib/udev to /usr/lib/udev. Unless you're going to establish a symlink, please keep it under p.mask until everything is using some common code — otherwise things _will_ break. Since multiple packages put things in /lib/udev, I'm not sure it is possible to establish a symlink from /lib/udev to /usr/lib/udev if that's what you mean; I'll look into it though. Couldn't you, on udev upgrade, move everything in /lib/udev to /usr/lib/udev, and then make the symlink? Seems fairly simple to me, but maybe I'm overlooking something? A symlink isn't a good idea as, iirc, the new udev still -reads- from both /usr/lib/udev and /lib/udev .. so it'd have two sources for the exact same rules; could be an issue. Given this, the way I see it all we need is a helper s.t. all installs going forward put the rules into the right place according to the installed udev (or maybe the installed virtual/device-manager) so that ebuilds/packages dont need to worry about setting the paths explicitly; and eventually as things progress all the rules in /lib/udev will get cleaned out in favour of /usr/lib/udev ... ? We could always just forgo the helper and make all packages migrate via a =udev-186-r1 dep and setting the rules install paths explicitly to /usr/lib/udev ... the helper (to me) just makes this cleaner in the ebuild.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/+1J0ACgkQ2ugaI38ACPAaRgEAuknxIx3LOgVniVsEqxrwWfnj vNW5Zc/6/ZCn8QL+LZ8A/iepdgiZ7bmYtUb+Zj537o46z/prXP290q6oo/2DQy2j =G32M -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: udev-rules.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 03:17 AM, Michał Górny wrote: On Thu, 12 Jul 2012 13:01:21 +0800 Ben de Groot yng...@gentoo.org wrote: On 12 July 2012 07:42, William Hubbs willi...@gentoo.org wrote: On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: Il 11/07/2012 21:11, William Hubbs ha scritto: I am about to release udev-186-r1, which will move everything currently in /lib/udev to /usr/lib/udev. Unless you're going to establish a symlink, please keep it under p.mask until everything is using some common code — otherwise things _will_ break. Since multiple packages put things in /lib/udev, I'm not sure it is possible to establish a symlink from /lib/udev to /usr/lib/udev if that's what you mean; I'll look into it though. Couldn't you, on udev upgrade, move everything in /lib/udev to /usr/lib/udev, and then make the symlink? Seems fairly simple to me, but maybe I'm overlooking something? You are overlooking conflicts introduced through moving files without updating vardb. There were no vdb issues when baselayout-1 was migrated to baselayout-2, and it rewrote a whackload of stuff iirc... Updating vdb shouldn't be an issue here, as long as pkg_postinst doesn't crash mid-stream. Is the vdb common between package managers or does each one have a different solution? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/+1XUACgkQ2ugaI38ACPBKdgD/S3jlct63PVIKE8UmHW4jEanZ T2/lgnF/cUzTSlsyrEQA/iQWSvOcowsgI/r2VUlJLFpltNVea/f8pm5wKq5F4cjk =HA5O -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Output / End User Experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 07:41 AM, Ben de Groot wrote: On 12 July 2012 17:52, Rich Freeman ri...@gentoo.org wrote: On Thu, Jul 12, 2012 at 12:17 AM, Ben de Groot yng...@gentoo.org wrote: Actually, there is another workable solution, and that is to set USE=-gstreamer -icu for qt-webkit. Currently we enable gstreamer by default in the ebuild (as it is used for HTML5 audio/video, which is expected functionality in qt-webkit based web browsers etc.), but we are considering if we should perhaps not enable this by default. As discussed on the bug, this will likely help some, but it doesn't help anybody who uses KDE or Gnome. As far as I know the gstreamer useflag is only enabled in the gnome profile, not the kde one currently. How much Gnome stuff needs qt-webkit? I figured that gnome stuffs would be much more likely to require webkit-gtk , yes? So a KDE user, with USE=-gstreamer , is most likely not going to run into this issue yes? And Gnome users that have webkit-gtk[gstreamer] packages don't run into this issue with chromium anyways, right? (i know there's always overlap as anyone can install anything, but i'm thinking of the general scope of impact here) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/+1m0ACgkQ2ugaI38ACPBgQwD8DuLYiLZv4LUAuW1VACqRW/av npl1U7DXm8jqPM4l0B4BALR4FY+yUD824X2+UwbB6hAjEZrYpLSIQz2zINbUiLYK =vYhV -END PGP SIGNATURE-
Re: [gentoo-dev] dev-libs/ffcall is looking for a new maintainer
On 07/11/2012 04:36 PM, Bernard Cafarelli wrote: This package historically belongs to the gnustep herd, but ffcall support in gnustep has been deprecated for some time now in favor of libffi (in fact the USE-flag may go away soon) Also, I do not have the time to work on it, although it requires a bit of work: * switch to new upstream (recommending to grab CVS tarballs) at http://www.gnu.org/software/libffcall/ * a bunch of opened issues (parallel make/install, ldflags, execstacks, ...): https://bugs.gentoo.org/buglist.cgi?quicksearch=ffcall So if you are interested, please add yourself to metadata.xml (and remove gnustep herd) and start bug sqashing. As a bonus, you will still have a backup herd (common-lisp), thoug a real maintainer would be great Reverse RDEPEND for dev-libs/ffcall: dev-lang/gforth-0.7.0 dev-lisp/clisp-2.47-r1 dev-lisp/clisp-2.48-r1 dev-lisp/clisp-2.48-r2 gnustep-base/gnustep-base-1.20.1:!libffi gnustep-base/gnustep-base-1.24.0-r1:!libffi libffi should be a full replacement and more widely adapted variant. isn't it time to let this simply fade away (lastrite)?
Re: [gentoo-dev] rfc: udev-rules.eclass
On Thu, 12 Jul 2012 09:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 03:17 AM, Michał Górny wrote: On Thu, 12 Jul 2012 13:01:21 +0800 Ben de Groot yng...@gentoo.org wrote: On 12 July 2012 07:42, William Hubbs willi...@gentoo.org wrote: On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: Il 11/07/2012 21:11, William Hubbs ha scritto: I am about to release udev-186-r1, which will move everything currently in /lib/udev to /usr/lib/udev. Unless you're going to establish a symlink, please keep it under p.mask until everything is using some common code — otherwise things _will_ break. Since multiple packages put things in /lib/udev, I'm not sure it is possible to establish a symlink from /lib/udev to /usr/lib/udev if that's what you mean; I'll look into it though. Couldn't you, on udev upgrade, move everything in /lib/udev to /usr/lib/udev, and then make the symlink? Seems fairly simple to me, but maybe I'm overlooking something? You are overlooking conflicts introduced through moving files without updating vardb. There were no vdb issues when baselayout-1 was migrated to baselayout-2, and it rewrote a whackload of stuff iirc... Updating vdb shouldn't be an issue here, as long as pkg_postinst doesn't crash mid-stream. Is the vdb common between package managers or does each one have a different solution? Yes, it is common because for many years people keep noticing it is common and using that. In other words, for many there is a failing attempt to stop relying on its format. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: udev-rules.eclass
On Thu, 12 Jul 2012 09:43:57 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 01:01 AM, Ben de Groot wrote: On 12 July 2012 07:42, William Hubbs willi...@gentoo.org wrote: On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: Il 11/07/2012 21:11, William Hubbs ha scritto: I am about to release udev-186-r1, which will move everything currently in /lib/udev to /usr/lib/udev. Unless you're going to establish a symlink, please keep it under p.mask until everything is using some common code — otherwise things _will_ break. Since multiple packages put things in /lib/udev, I'm not sure it is possible to establish a symlink from /lib/udev to /usr/lib/udev if that's what you mean; I'll look into it though. Couldn't you, on udev upgrade, move everything in /lib/udev to /usr/lib/udev, and then make the symlink? Seems fairly simple to me, but maybe I'm overlooking something? A symlink isn't a good idea as, iirc, the new udev still -reads- from both /usr/lib/udev and /lib/udev .. Does it? I wasn't able to reproduce and wanted to start convincing Kay to let it do that... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 11 Jul 2012 14:11:42 -0500
William Hubbs willi...@gentoo.org wrote:
# @FUNCTION: _udev_get_rulesdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed udev rules directory.
_udev_get_rulesdir() {
local dir
if has_version 'sys-fs/udev-186-r1'; then
dir=/lib/udev/rules.d
else
dir=/usr/lib/udev/rules.d
fi
echo -n $dir
}
For now, I think it would be better to just use /lib/udev/rules.d. We
can decide on moving the rules later.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] inittab with SIGPWR support
DEP They _are_ deprecated after all. Where is that documented? man inittab
Re: [gentoo-dev] rfc: udev-rules.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 10:19 AM, Michał Górny wrote: On Thu, 12 Jul 2012 09:47:33 -0400 Ian Stakenvicius a...@gentoo.org wrote: Updating vdb shouldn't be an issue here, as long as pkg_postinst doesn't crash mid-stream. Is the vdb common between package managers or does each one have a different solution? Yes, it is common because for many years people keep noticing it is common and using that. In other words, for many there is a failing attempt to stop relying on its format. ..i'm not following this -- so it's common (ie, portage, paludis, etc all use it) because it's always been there? Anyways, if all the package managers do use it, then there isn't any reason at this juncture to not handle this via an update to vdb. If in the future different package managers use something different, then we'd need to have individual vdb-update scripts for each (differing) pms, but unless I misread you this is currently a non-issue.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/+4GQACgkQ2ugaI38ACPDP8QD9HPv+l8vFW7cm/xA5ksKhUUyD xzOtVY93XLL3ArhqlYkBAJxi98IIk5qWib6BK7VckhQLwJVmmHO+xtDPFuhP78rU =YIIr -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: udev-rules.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 10:20 AM, Michał Górny wrote: On Thu, 12 Jul 2012 09:43:57 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 01:01 AM, Ben de Groot wrote: On 12 July 2012 07:42, William Hubbs willi...@gentoo.org wrote: On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: Il 11/07/2012 21:11, William Hubbs ha scritto: I am about to release udev-186-r1, which will move everything currently in /lib/udev to /usr/lib/udev. Unless you're going to establish a symlink, please keep it under p.mask until everything is using some common code — otherwise things _will_ break. Since multiple packages put things in /lib/udev, I'm not sure it is possible to establish a symlink from /lib/udev to /usr/lib/udev if that's what you mean; I'll look into it though. Couldn't you, on udev upgrade, move everything in /lib/udev to /usr/lib/udev, and then make the symlink? Seems fairly simple to me, but maybe I'm overlooking something? A symlink isn't a good idea as, iirc, the new udev still -reads- from both /usr/lib/udev and /lib/udev .. Does it? I wasn't able to reproduce and wanted to start convincing Kay to let it do that... ..i was going by your statement, i guess i misread you (thought you said that it did, not that it should).. Sorry! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/+4JAACgkQ2ugaI38ACPCJSgEAp8xI9d8dDO5G2l1lC/pYGT+c P1rx1XWffLntT12AG94A/j2321qa6OeC+I8AXmK2N+CtWt1FMSzP250H7yMkB0CH =MERT -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: udev-rules.eclass
On Thu, Jul 12, 2012 at 04:22:20PM +0200, Michał Górny wrote:
On Wed, 11 Jul 2012 14:11:42 -0500
William Hubbs willi...@gentoo.org wrote:
# @FUNCTION: _udev_get_rulesdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed udev rules directory.
_udev_get_rulesdir() {
local dir
if has_version 'sys-fs/udev-186-r1'; then
dir=/lib/udev/rules.d
else
dir=/usr/lib/udev/rules.d
fi
echo -n $dir
}
For now, I think it would be better to just use /lib/udev/rules.d. We
can decide on moving the rules later.
We can hold off on this for udev-186. Sometime soon though we will need
to move the rools.
The more I think about it it will do best to be a hard dependency on
=sys-fs/udev-187 and not worry about the whole eclass issue.
William
pgpJDVvbVa59x.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: udev-rules.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jul 2012 10:34:12 -0400 Ian Stakenvicius a...@gentoo.org wrote: ..i'm not following this -- so it's common (ie, portage, paludis, etc all use it) because it's always been there? It's sort of commonish because there's some disgusting code in some eclasses that sort of relies upon its format being sort of right. We have yet to manage to do away with that code, which is annoying, because VDB's format stinks. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk/+4T0ACgkQ96zL6DUtXhEXYACfaxKsxed/K0QIKSVKXry/Zkkv sKEAn14ssmyzDzmdT9oMeodQvRMfRHis =VFuE -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: udev-rules.eclass
On Thu, 12 Jul 2012 10:34:56 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 10:20 AM, Michał Górny wrote: On Thu, 12 Jul 2012 09:43:57 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 01:01 AM, Ben de Groot wrote: On 12 July 2012 07:42, William Hubbs willi...@gentoo.org wrote: On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote: Il 11/07/2012 21:11, William Hubbs ha scritto: I am about to release udev-186-r1, which will move everything currently in /lib/udev to /usr/lib/udev. Unless you're going to establish a symlink, please keep it under p.mask until everything is using some common code — otherwise things _will_ break. Since multiple packages put things in /lib/udev, I'm not sure it is possible to establish a symlink from /lib/udev to /usr/lib/udev if that's what you mean; I'll look into it though. Couldn't you, on udev upgrade, move everything in /lib/udev to /usr/lib/udev, and then make the symlink? Seems fairly simple to me, but maybe I'm overlooking something? A symlink isn't a good idea as, iirc, the new udev still -reads- from both /usr/lib/udev and /lib/udev .. Does it? I wasn't able to reproduce and wanted to start convincing Kay to let it do that... ..i was going by your statement, i guess i misread you (thought you said that it did, not that it should).. Sorry! I will try to convince upstream to support it that way. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Looking for a (temporary) proxy docdev for french documentation
Hello, The french documentation is quite outdated, and this is not a good vitrine to Gentoo for the French-speaking users. By this outdated documentation, we get, in the french subforum and #gentoofr IRC channel, many outdated questions about HAL, baselayout 1, or CHOST changes... I had contact with cam, who said there is nobody now in the FR doc team. In the other side, there are some volunteers who can help to update the official documentation. We need thus an /ad interim/ proxy docdev to help us to merge the patches for the documentation. Meanwhile, I could follow the procedure to become a docdev. Kind regards, Xavier Miller.
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 11 Jul 2012 18:48:08 -0500 William Hubbs willi...@gentoo.org wrote: On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: How do you plan to handle the following: - foo installs an udev rule - install foo with old udev - upgrade udev are rules installed by foo used by new udev ? No, they wouldn't be; that is a good reason to question the value of the eclass itself. Maybe the correct way to do this is to forget the eclass and just file bugs against packages that break having them move their rules to the new location and set a dependency on the newer udev. This would have to be a rev bump for the broken packages. this sounds heavy for only changing the location of a file, but that's the only sane solution i can think of :( A.
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 11 Jul 2012 20:41:04 -0700 Brian Dolbec dol...@gentoo.org wrote: On Wed, 2012-07-11 at 18:48 -0500, William Hubbs wrote: On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: How do you plan to handle the following: - foo installs an udev rule - install foo with old udev - upgrade udev are rules installed by foo used by new udev ? No, they wouldn't be; that is a good reason to question the value of the eclass itself. Maybe the correct way to do this is to forget the eclass and just file bugs against packages that break having them move their rules to the new location and set a dependency on the newer udev. This would have to be a rev bump for the broken packages. William A. So, does that mean the rule itself changes or just the location change is needed? If it is just a location change, a fairly simple udev-updater script would do it. [...] how do you handle the package manager database containing the location of the file ? A.
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, 11 Jul 2012 19:50:42 -0700 Zac Medico zmed...@gentoo.org wrote: On 07/11/2012 07:25 PM, Rick Zero_Chaos Farina wrote: On 07/11/2012 07:48 PM, William Hubbs wrote: On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: How do you plan to handle the following: - foo installs an udev rule - install foo with old udev - upgrade udev are rules installed by foo used by new udev ? No, they wouldn't be; that is a good reason to question the value of the eclass itself. Maybe the correct way to do this is to forget the eclass and just file bugs against packages that break having them move their rules to the new location and set a dependency on the newer udev. Perhaps a new ebuild helper would be best here? It seems no one knows where to install udev rules in the first place (I know I didn't till a recent version of portage yelled at me with a QA warning). How about dorule/newrule? I guess then we'd need the installed udev to set an environment variable via /etc/env.d, in order to control the location where the rules are installed? Having the location of installed files depend on environment variables always sounded bad practices to me. Maybe it is quite common, but I remember specifically hardcoding paths in TeXLive's ebuilds/eclasses to avoid this behavior. A.
Re: [gentoo-dev] RFC: virtual/libudev
Il 11/07/2012 22:33, Mike Gilbert ha scritto: On Wed, Jul 11, 2012 at 3:54 PM, William Hubbswilli...@gentoo.org wrote: On Wed, Jul 11, 2012 at 03:27:41PM -0400, Mike Gilbert wrote: Just to put a number to this, there are currently 126 packages in the tree with a dependency on sys-fs/udev. Personally, I think a consolidated systemd/udev package is the best way to go here. Short of that, the virtual + blockers seems like an acceptable solution. Thinking on this, I agree with Mike here, and to make it easier for maintainers so they don't have to change their dependencies, it should be a udev ebuild with a systemd use flag. An alternative to the funky udev[systemd] solution would be to replace the entire udev ebuild with RDEPEND=sys-apps/systemd, and implement the requisite logic in the systemd ebuild. This would effectively make udev a virtual package without the need to modify any other packages. Long time ago portage managed virtual/* ebuilds differently from the others, it may be wise to ask to the portage developers if that's still the case and why/what is done.
Re: [gentoo-dev] Looking for a (temporary) proxy docdev for french documentation
On Thu, Jul 12, 2012 at 06:22:31PM +0200, Xavier Miller wrote: The french documentation is quite outdated, and this is not a good vitrine to Gentoo for the French-speaking users. By this outdated documentation, we get, in the french subforum and #gentoofr IRC channel, many outdated questions about HAL, baselayout 1, or CHOST changes... I had contact with cam, who said there is nobody now in the FR doc team. In the other side, there are some volunteers who can help to update the official documentation. We need thus an /ad interim/ proxy docdev to help us to merge the patches for the documentation. Meanwhile, I could follow the procedure to become a docdev. Hi Xavier, You might want to take this to the gentoo-doc mailinglist. That being said, I don't mind proxying commits for you guys. I'll contact you offlist for the details. Wkr, Sven Vermeulen
[gentoo-dev] Re: gentoo-x86 commit in profiles: ChangeLog package.mask
Shouldn't CVS have prevented my changes to profile.mask from being overwritten by the next committer? chainsaw12/07/11 12:24:43 Modified: ChangeLog package.mask Log: Mask =net-misc/asterisk-10.6.0 for null pointer dereferencing. Revision ChangesPath 1.6769 profiles/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/ChangeLog?rev=1.6769view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/ChangeLog?rev=1.6769content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/ChangeLog?r1=1.6768r2=1.6769 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/profiles/ChangeLog,v retrieving revision 1.6768 retrieving revision 1.6769 diff -u -r1.6768 -r1.6769 --- ChangeLog 10 Jul 2012 16:54:21 - 1.6768 +++ ChangeLog 11 Jul 2012 12:24:42 - 1.6769 @@ -1,11 +1,14 @@ # ChangeLog for profile directory # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/profiles/ChangeLog,v 1.6768 2012/07/10 16:54:21 tetromino Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/ChangeLog,v 1.6769 2012/07/11 12:24:42 chainsaw Exp $ # # This ChangeLog should include records for all changes in profiles directory. # Only typo fixes which don't affect portage/repoman behaviour could be avoided # here. If in doubt put a record here! + 11 Jul 2012; Tony Vroon chain...@gentoo.org package.mask: + Mask =net-misc/asterisk-10.6.0 for null pointer dereferencing. + 10 Jul 2012; Alexandre Rostovtsev tetrom...@gentoo.org package.mask: Mask gnome-extra/gnome-screensaver-3.4.2 for bug #425070. 1.13950 profiles/package.mask file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.13950view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.13950content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.13949r2=1.13950 Index: package.mask === RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v retrieving revision 1.13949 retrieving revision 1.13950 diff -u -r1.13949 -r1.13950 --- package.mask10 Jul 2012 16:54:21 - 1.13949 +++ package.mask11 Jul 2012 12:24:42 - 1.13950 @@ -1,5 +1,5 @@ -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.13949 2012/07/10 16:54:21 tetromino Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.13950 2012/07/11 12:24:42 chainsaw Exp $ # # When you add an entry to the top of this file, add your name, the date, and # an explanation of why something is getting masked. Please be extremely @@ -31,9 +31,11 @@ #--- END OF EXAMPLES --- -# Alexandre Rostovtsev tetrom...@gentoo.org (10 Jul 2012) -# Fails to unlock the screen for some gnome-shell users, bug #425070 -=gnome-extra/gnome-screensaver-3.4.2 +# Tony Vroon chain...@gentoo.org (11 Jul 2012) +# This segfaults repeatedly in actual use for me, and I can not in good +# conscience allow this to surprise others. Unmask only to help trace +# where the fault is, not to run on live systems. +=net-misc/asterisk-10.6.0 # Mike Gilbert flop...@gentoo.org (09 Jul 2012) # Dev channel releases are only for people who are developers or want more
[gentoo-dev] Re: gentoo-x86 commit in profiles: ChangeLog package.mask
On 12-07-2012 14:50:18 -0400, Alexandre Rostovtsev wrote: Shouldn't CVS have prevented my changes to profile.mask from being overwritten by the next committer? How could CVS have done that (or git, hg, whatever VCS)? -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: gentoo-x86 commit in profiles: ChangeLog package.mask
On Thu, Jul 12, 2012 at 8:50 PM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: Shouldn't CVS have prevented my changes to profile.mask from being overwritten by the next committer? Maybe Tony mismerged your changes into his? On Thu, Jul 12, 2012 at 9:04 PM, Fabian Groffen grob...@gentoo.org wrote: On 12-07-2012 14:50:18 -0400, Alexandre Rostovtsev wrote: Shouldn't CVS have prevented my changes to profile.mask from being overwritten by the next committer? How could CVS have done that (or git, hg, whatever VCS)? In general, the VCS would not let you commit/push conflicting changes. For CVS, I think you cannot commit unless your local copy is up to date, so you'd have to update before committing, at which point CVS would launch a merge tool or put merge markers in the file. Right? Dirkjan
Re: [gentoo-dev] Re: gentoo-x86 commit in profiles: ChangeLog package.mask
On Thu, 2012-07-12 at 21:09 +0200, Dirkjan Ochtman wrote: Maybe Tony mismerged your changes into his? Thank you for your trust in me. cvs commit -m completed non-interactively, without notification of conflict or request to merge. Regards, Tony V. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: gentoo-x86 commit in profiles: ChangeLog package.mask
On Thu, Jul 12, 2012 at 9:12 PM, Tony Chainsaw Vroon chain...@gentoo.org wrote: On Thu, 2012-07-12 at 21:09 +0200, Dirkjan Ochtman wrote: Maybe Tony mismerged your changes into his? Thank you for your trust in me. cvs commit -m completed non-interactively, without notification of conflict or request to merge. I certainly didn't mean to accuse you; I hoped to convey that this happened accidentally, which in my experience happens once in a while (though a problem with the tools might be more likely). Cheers, Dirkjan
Re: [gentoo-dev] rfc: udev-rules.eclass
On 07/11/2012 10:11 PM, William Hubbs wrote:
All,
I am about to release udev-186-r1, which will move everything currently
in /lib/udev to /usr/lib/udev.
For packages that install udev rules in ${FILESDIR}, we need an eclass
that tests the version of udev installed on the user's system and
installs the udev rules in the proper place. I'm not sure how many
packages do this, so if it is a very small number of packages, it may
not be worth the eclass. It would be good to discuss that as well as
reviewing the proposed eclass.
Thanks,
William
Please don't hardcode the path like this, use pkg-config instead:
inherit toolchain-funcs
dir=$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d
Re: [gentoo-dev] udev - mdev
On Thu, Jul 12, 2012 at 09:37:33AM -0400, Ian Stakenvicius wrote First a disclaimer... I am not a C programmer, let alone a developer. I feel like I've been dragged into this kicking and screaming in order to save the Gentoo that I remember from a few years ago. Out of curiosity, since mdev is (i assume) more than complete enough to handle mounting, would it be possible to initially start with mdev and then hand over control to udev (if there was a need for udev, that is) , to avoid initramfs with separate /usr ? I think that's exactly how initramfs itself works. You might be able to use an initrd instead of initramfs. See Zac Medico's posting at... http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml That was the clue that got me started on replacing udev with mdev. Once you have psuedo-filesystems and partitions mounted, you need to shut down mdev and start up udev. And make sure that /proc/sys/kernel/hotplug points to udev. If you want to get fancy, you can boot from a separate small boot partition, or for that matter a USB key. Then either chroot or pivot_root into the udev environment. For pivot_root man pages see http://linux.die.net/man/8/pivot_root and http://linux.die.net/man/2/pivot_root -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] rfc: udev-rules.eclass
On Thu, Jul 12, 2012 at 3:58 PM, Samuli Suominen ssuomi...@gentoo.org wrote: Please don't hardcode the path like this, use pkg-config instead: inherit toolchain-funcs dir=$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d Heh, I didn't realize udev installed a pkg-config file for that. Nice.
Re: [gentoo-dev] Looking for a (temporary) proxy docdev for french documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/12/2012 05:22 PM, Xavier Miller wrote: Hello, The french documentation is quite outdated, and this is not a good vitrine to Gentoo for the French-speaking users. By this outdated documentation, we get, in the french subforum and #gentoofr IRC channel, many outdated questions about HAL, baselayout 1, or CHOST changes... I had contact with cam, who said there is nobody now in the FR doc team. In the other side, there are some volunteers who can help to update the official documentation. We need thus an /ad interim/ proxy docdev to help us to merge the patches for the documentation. Meanwhile, I could follow the procedure to become a docdev. Kind regards, Xavier Miller. Hi Xavier, You need to get in touch with the Documentation Project[1] as only these people have access to the docs repository. [1] http://www.gentoo.org/proj/en/gdp/ - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJP/zuUAAoJEPqDWhW0r/LCOh8QALJYyV5E4Xo92tMHCmO4cIsm spMQiZ3Jc8HPHnReL3r/h57Q0Fxnx3hjKqhyxdeSY2zQF3R5mbOacSiSg/Z3Y/B8 0FmKLQX6iWgVK4GexKlLgxBx0/DZd/xIId8Xb743o8EBU1WoSWA4HzNrRDWvAT95 7GEFYqqW6ZsukSlfrv4YZLSoZb3SxlgIfXy5nefH0DcDwXxwxjv63LLDkrvU7GBi SkeVyG9xdiSqqIWfancwZ4o1npwi/ABQFplmg2B5GeLBHyJyzlaQVP9EUXv543ym TuTJNj7UM97hh9SgHl92ilsEdHPGC4jBkr9UyUgeQOu2toJ++kpqUZY3zzSgtXJe zSPUPJq9LLDoUcWNC4WeO6kanOXZoly3iO/Sj+eocpgY6SoCXGcdcOqZaTLVoGkN ATflTnLq2wu253rXwmTHHk0P3gG5JJ29XBMTpJ8qctmqHxwmrt5SxLt1RpCKKQYp /5y8aPptEVhzQ1lnxktGxRriULa9TU760lbYbvG5erxJtC46cg6luA3ESXWgDb+j I7jDR8UwqSW/BURvSLfg42TJcjxF8wd7zNVPy6hNmrnlEBBLTKZ9OwF+zJaxE1Wp ODXVvyiomskfC2NS8IuWR/b1cY6u6m61esUKiR3qvGTlcxul6pa1syrp8gxvtmxw AIKghaJWLg/sLjkEZTYx =FDkf -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: udev-rules.eclass
On Thu, 12 Jul 2012 22:58:29 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
On 07/11/2012 10:11 PM, William Hubbs wrote:
All,
I am about to release udev-186-r1, which will move everything
currently in /lib/udev to /usr/lib/udev.
For packages that install udev rules in ${FILESDIR}, we need an
eclass that tests the version of udev installed on the user's
system and installs the udev rules in the proper place. I'm not
sure how many packages do this, so if it is a very small number of
packages, it may not be worth the eclass. It would be good to
discuss that as well as reviewing the proposed eclass.
Thanks,
William
Please don't hardcode the path like this, use pkg-config instead:
inherit toolchain-funcs
dir=$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d
Don't forget to add udev to DEPEND of every package using the eclass
then. Oh wait...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: udev-rules.eclass
On 07/13/2012 12:04 AM, Michał Górny wrote:
On Thu, 12 Jul 2012 22:58:29 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
On 07/11/2012 10:11 PM, William Hubbs wrote:
All,
I am about to release udev-186-r1, which will move everything
currently in /lib/udev to /usr/lib/udev.
For packages that install udev rules in ${FILESDIR}, we need an
eclass that tests the version of udev installed on the user's
system and installs the udev rules in the proper place. I'm not
sure how many packages do this, so if it is a very small number of
packages, it may not be worth the eclass. It would be good to
discuss that as well as reviewing the proposed eclass.
Thanks,
William
Please don't hardcode the path like this, use pkg-config instead:
inherit toolchain-funcs
dir=$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d
Don't forget to add udev to DEPEND of every package using the eclass
then. Oh wait...
Obviously the pkg-config should be only the primary method and there
should be a fallback, like what has already been posted.
See attachment.
--- udev-rules.eclass.orig 2012-07-12 23:59:40.465838370 +0300
+++ udev-rules.eclass 2012-07-13 00:01:12.921831177 +0300
@@ -22,6 +22,8 @@
# }
# @CODE
+inherit toolchain-funcs
+
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die ${ECLASS}.eclass API in EAPI ${EAPI} not yet established.
@@ -33,10 +35,14 @@
# Get unprefixed udev rules directory.
_udev_get_rulesdir() {
local dir
- if has_version 'sys-fs/udev-186-r1'; then
- dir=/lib/udev/rules.d
+ if has_version virtual/pkgconfig; then
+ dir=$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d
else
- dir=/usr/lib/udev/rules.d
+ if has_version 'sys-fs/udev-186-r1'; then
+ dir=/lib/udev/rules.d
+ else
+ dir=/usr/lib/udev/rules.d
+ fi
fi
echo -n $dir
}
Re: [gentoo-dev] rfc: udev-rules.eclass
On 07/13/2012 12:01 AM, Samuli Suominen wrote:
On 07/13/2012 12:04 AM, Michał Górny wrote:
On Thu, 12 Jul 2012 22:58:29 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
On 07/11/2012 10:11 PM, William Hubbs wrote:
All,
I am about to release udev-186-r1, which will move everything
currently in /lib/udev to /usr/lib/udev.
For packages that install udev rules in ${FILESDIR}, we need an
eclass that tests the version of udev installed on the user's
system and installs the udev rules in the proper place. I'm not
sure how many packages do this, so if it is a very small number of
packages, it may not be worth the eclass. It would be good to
discuss that as well as reviewing the proposed eclass.
Thanks,
William
Please don't hardcode the path like this, use pkg-config instead:
inherit toolchain-funcs
dir=$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d
Don't forget to add udev to DEPEND of every package using the eclass
then. Oh wait...
Obviously the pkg-config should be only the primary method and there
should be a fallback, like what has already been posted.
See attachment.
Err, this one.
--- udev-rules.eclass.orig 2012-07-12 23:59:40.465838370 +0300
+++ udev-rules.eclass 2012-07-13 00:09:00.138793712 +0300
@@ -22,6 +22,8 @@
# }
# @CODE
+inherit toolchain-funcs
+
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die ${ECLASS}.eclass API in EAPI ${EAPI} not yet established.
@@ -33,10 +35,14 @@
# Get unprefixed udev rules directory.
_udev_get_rulesdir() {
local dir
- if has_version 'sys-fs/udev-186-r1'; then
- dir=/lib/udev/rules.d
+ if $($(tc-getPKG_CONFIG) --exists udev); then
+ dir=$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d
else
- dir=/usr/lib/udev/rules.d
+ if has_version 'sys-fs/udev-186-r1'; then
+ dir=/lib/udev/rules.d
+ else
+ dir=/usr/lib/udev/rules.d
+ fi
fi
echo -n $dir
}
[gentoo-dev] Re: rfc: udev-rules.eclass
On 07/12/2012 05:09 PM, Samuli Suominen wrote:
@@ -33,10 +35,14 @@
# Get unprefixed udev rules directory.
_udev_get_rulesdir() {
local dir
- if has_version 'sys-fs/udev-186-r1'; then
- dir=/lib/udev/rules.d
+ if $($(tc-getPKG_CONFIG) --exists udev); then
This should probably be:
if $(tc-getPKG_CONFIG) --exists udev 2/dev/null; then
+ dir=$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d
else
- dir=/usr/lib/udev/rules.d
+ if has_version 'sys-fs/udev-186-r1'; then
+ dir=/lib/udev/rules.d
+ else
+ dir=/usr/lib/udev/rules.d
+ fi
fi
echo -n $dir
}
--
Jonathan Callen
Re: [gentoo-dev] udev - mdev
Hi all, On Thu, Jul 12, 2012 at 04:07:41PM -0400, Walter Dnes wrote: On Thu, Jul 12, 2012 at 09:37:33AM -0400, Ian Stakenvicius wrote First a disclaimer... I am not a C programmer, let alone a developer. I feel like I've been dragged into this kicking and screaming in order to save the Gentoo that I remember from a few years ago. Out of curiosity, since mdev is (i assume) more than complete enough to handle mounting, would it be possible to initially start with mdev and then hand over control to udev (if there was a need for udev, that is) , to avoid initramfs with separate /usr ? I think that's exactly how initramfs itself works. You might be able to use an initrd instead of initramfs. See Zac Medico's posting at... http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml That was the clue that got me started on replacing udev with mdev. initrd is deprecated and has been for a long time; you should use initramfs. Once you have psuedo-filesystems and partitions mounted, you need to shut down mdev and start up udev. And make sure that /proc/sys/kernel/hotplug points to udev. If you are using udev, /proc/sys/kernel/hotplug should be empty; do not point this to udev. Thanks, William pgpbZG40oxrBE.pgp Description: PGP signature
Re: [gentoo-dev] rfc: udev-rules.eclass
On Thu, 2012-07-12 at 12:30 -0400, Alexis Ballier wrote: On Wed, 11 Jul 2012 20:41:04 -0700 Brian Dolbec dol...@gentoo.org wrote: On Wed, 2012-07-11 at 18:48 -0500, William Hubbs wrote: On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote: How do you plan to handle the following: - foo installs an udev rule - install foo with old udev - upgrade udev are rules installed by foo used by new udev ? No, they wouldn't be; that is a good reason to question the value of the eclass itself. Maybe the correct way to do this is to forget the eclass and just file bugs against packages that break having them move their rules to the new location and set a dependency on the newer udev. This would have to be a rev bump for the broken packages. William A. So, does that mean the rule itself changes or just the location change is needed? If it is just a location change, a fairly simple udev-updater script would do it. [...] how do you handle the package manager database containing the location of the file ? A. Personally, since I'm not a bash programmer, I'd use python. And since this is the package managers db, I'd use the pkg manager to do it. Specifically I'd create an emaint module to do it in the fully modular/plug-in-able emaint rewrite I did (waiting for Zac's review, merge). It can make it's modules fully available for direct or managed import by other portage code, or other scripts. In fact in that branch I moved some clean-logs code from emerge into an emaint module, extended it a bit so you can change the time setting, run pretend runs (-c, --check)... and had the emerge FEATURE run it instead. So you could run it independently of emerge if you choose. There is an outdated vdbkeys emaint module that did changes and updates to several files in a pkg's vdb directory. Creating one to do this should be quite simple. That said, I don't profess to know what other possible ramifications there would be to changing a few entries in a pkg's CONTENTS file. I'll leave that up to Zac and the others. But I haven't heard any screaming of breakage that would occur for doing so. -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: udev - mdev
William Hubbs posted on Thu, 12 Jul 2012 17:29:31 -0500 as excerpted: And make sure that /proc/sys/kernel/hotplug points to udev. If you are using udev, /proc/sys/kernel/hotplug should be empty; do not point this to udev. Yes. I've not changed that setting from whatever the default is, and I guess udev moved its hook out from there quite some time ago so it's pointing at nothing, but having that actually point to something is known in kernel circles to lead to a lot of unnecessary grief. They're seriously thinking about (and may be planning on) removing that option from the kernel entirely, to keep people configuring their first kernels from getting themselves in trouble, but of course that's now part of the kernel/userspace interface, so it isn't allowed to just disappear like kernel/kernel interfaces can. At minimum they'd likely have to have it on the deprecation and removal schedule for awhile. (I've not checked to see if it's there already.) -- 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
