[arch-dev-public] [signoff] kernel26 2.6.24.3-1
Bumped to the .3 kernel, tested on both architectures, please sign off. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [signoff] fakeroot 1.9.3-1
On Tue, 26 Feb 2008, Andreas Radke wrote: Am Mon, 25 Feb 2008 08:24:26 +0200 schrieb "Roman Kyrylych" <[EMAIL PROTECTED]>: I've built some packges with it that seem fine, so I'll signoff. Signed off (i686). somebody for x86_64? signing off x86_64 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [arch-dev-public] Module blacklisting
On Tue, Feb 26, 2008 at 11:59 AM, Aaron Griffin <[EMAIL PROTECTED]> wrote: > On Tue, Feb 26, 2008 at 11:54 AM, Dan McGee <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 26, 2008 at 11:30 AM, Aaron Griffin <[EMAIL PROTECTED]> wrote: > > > > > > On Tue, Feb 26, 2008 at 11:15 AM, Daniel Isenmann > > > <[EMAIL PROTECTED]> wrote: > > > > I'm a little bit confused right now. How can I blacklist modules. I > > > > have test both, MOD_BLACKLIST=(...) and MODULES=(!...), but both > don't > > > > work. udev loads every module which can be loaded. For example I > > > > blacklist nvidiafb, but udev loads it. Packages are up2date with > > > > testing repo. > > > > > > > > Can someone please explain it or the status is on this topic? > > > > > > The status is that I haven't gotten a concise answer. On this. For the > > > time being, I think we should do the following: > > > > > > a) Rebuild udev 118 with start_udev in there, for the people who keep > > > their systems in some goofy limbo state by only updating singular > > > packages at a time > > > > And add a big old echo at the top saying "You are using start_dev. > > This script will be removed in a future release!" > > Doesn't work. It's run with 2>&1 >/dev/null, which is very good at > keeping users uninformed of what's going on. Well that is dumb. Shoot. > > > c) Remove framebuffer module loading from the load-modules script (it > > > should never have been there in the first place). > > Agreed. What are the hotpoints in this script as well? Something like > > this seems inefficient: > > i="$(/sbin/modprobe -i --show-depends $1 | sed "s#^insmod > > /lib.*/\(.*\)\.ko.*#\1#g" | sed 's|-|_|g')" > > > > We invoke 3 subprocesses here (modprobe, sed, and sed). Surely the two > > seds can be combined. > > already done locally. > > > > See a trend here? So we have the following in one run of > > load-modules.sh (if we look back at the version packaged with 116): > > Good catch with all the seds... but ummm how about we NOT worry > about optimizing a script we'd like to get rid of? I'm sure start_udev > could use some cleanup, want to do that too? start_udev isn't even used by the curent initscripts though, so thats a different point than this one. Yes, I feel like maybe a short and sweet C program would be better, but for now cleaning some things up makes sense and will probably have an effect on the loading events time, thats all. If I can spend a half hour making it a little better and/or more efficient, I think that is time well spent, even if it is going to eventually be scrapped. -Dan
Re: [arch-dev-public] Module blacklisting
On Tue, Feb 26, 2008 at 11:54 AM, Dan McGee <[EMAIL PROTECTED]> wrote: > On Tue, Feb 26, 2008 at 11:30 AM, Aaron Griffin <[EMAIL PROTECTED]> wrote: > > > > On Tue, Feb 26, 2008 at 11:15 AM, Daniel Isenmann > > <[EMAIL PROTECTED]> wrote: > > > I'm a little bit confused right now. How can I blacklist modules. I > > > have test both, MOD_BLACKLIST=(...) and MODULES=(!...), but both don't > > > work. udev loads every module which can be loaded. For example I > > > blacklist nvidiafb, but udev loads it. Packages are up2date with > > > testing repo. > > > > > > Can someone please explain it or the status is on this topic? > > > > The status is that I haven't gotten a concise answer. On this. For the > > time being, I think we should do the following: > > > > a) Rebuild udev 118 with start_udev in there, for the people who keep > > their systems in some goofy limbo state by only updating singular > > packages at a time > > And add a big old echo at the top saying "You are using start_dev. > This script will be removed in a future release!" Doesn't work. It's run with 2>&1 >/dev/null, which is very good at keeping users uninformed of what's going on. > > c) Remove framebuffer module loading from the load-modules script (it > > should never have been there in the first place). > Agreed. What are the hotpoints in this script as well? Something like > this seems inefficient: > i="$(/sbin/modprobe -i --show-depends $1 | sed "s#^insmod > /lib.*/\(.*\)\.ko.*#\1#g" | sed 's|-|_|g')" > > We invoke 3 subprocesses here (modprobe, sed, and sed). Surely the two > seds can be combined. already done locally. > See a trend here? So we have the following in one run of > load-modules.sh (if we look back at the version packaged with 116): Good catch with all the seds... but ummm how about we NOT worry about optimizing a script we'd like to get rid of? I'm sure start_udev could use some cleanup, want to do that too?
Re: [arch-dev-public] Module blacklisting
On Tue, Feb 26, 2008 at 11:30 AM, Aaron Griffin <[EMAIL PROTECTED]> wrote:
>
> On Tue, Feb 26, 2008 at 11:15 AM, Daniel Isenmann
> <[EMAIL PROTECTED]> wrote:
> > I'm a little bit confused right now. How can I blacklist modules. I
> > have test both, MOD_BLACKLIST=(...) and MODULES=(!...), but both don't
> > work. udev loads every module which can be loaded. For example I
> > blacklist nvidiafb, but udev loads it. Packages are up2date with
> > testing repo.
> >
> > Can someone please explain it or the status is on this topic?
>
> The status is that I haven't gotten a concise answer. On this. For the
> time being, I think we should do the following:
>
> a) Rebuild udev 118 with start_udev in there, for the people who keep
> their systems in some goofy limbo state by only updating singular
> packages at a time
And add a big old echo at the top saying "You are using start_dev.
This script will be removed in a future release!"
> b) Switch to the udev 116 way of module loading
For now, yes. We know it works, and we can do some more investigation into this.
> c) Remove framebuffer module loading from the load-modules script (it
> should never have been there in the first place).
Agreed. What are the hotpoints in this script as well? Something like
this seems inefficient:
i="$(/sbin/modprobe -i --show-depends $1 | sed "s#^insmod
/lib.*/\(.*\)\.ko.*#\1#g" | sed 's|-|_|g')"
We invoke 3 subprocesses here (modprobe, sed, and sed). Surely the two
seds can be combined.
k="$(echo $BLACKLIST [EMAIL PROTECTED] | sed 's|-|_|g')"
j="$(echo [EMAIL PROTECTED] | sed 's|-|_|g')"
Hmm, two more seds.
# add disablemodules= from commandline to blacklist
k="${k} $(echo ${disablemodules} | sed 's|-|_|g' | sed 's|,| |g')"
See a trend here? So we have the following in one run of
load-modules.sh (if we look back at the version packaged with 116):
cat: 1 invocation
eval: invocation count depends on results of cat
sed: 6 calls, probably not cheap
echo: 5+ calls, but probably a shell builtin
grep: 1 call
This all means we spawn *at least* 8 processes per module passed to
load-modules.sh. I can help clean this up and test if anyone else is
willing to help.
-Dan
Re: [arch-dev-public] Module blacklisting
On Tue, Feb 26, 2008 at 11:15 AM, Daniel Isenmann <[EMAIL PROTECTED]> wrote: > I'm a little bit confused right now. How can I blacklist modules. I > have test both, MOD_BLACKLIST=(...) and MODULES=(!...), but both don't > work. udev loads every module which can be loaded. For example I > blacklist nvidiafb, but udev loads it. Packages are up2date with > testing repo. > > Can someone please explain it or the status is on this topic? The status is that I haven't gotten a concise answer. On this. For the time being, I think we should do the following: a) Rebuild udev 118 with start_udev in there, for the people who keep their systems in some goofy limbo state by only updating singular packages at a time b) Switch to the udev 116 way of module loading c) Remove framebuffer module loading from the load-modules script (it should never have been there in the first place). Anything wrong with doing it this way?
Re: [arch-dev-public] [signoff] grub 0.97-11
Am Tue, 26 Feb 2008 14:50:56 +0100 schrieb Thomas Bächler <[EMAIL PROTECTED]>: > Sorry for dropping off the radar lately, I am not sure what happened > myself, but I have been away from all Arch work for two weeks. > > I corrected my grub -10 package and fixed the bugs mentioned by Andy. > Please sign off. > signoff x86_64
Re: [arch-dev-public] Module blacklisting
I'm a little bit confused right now. How can I blacklist modules. I have test both, MOD_BLACKLIST=(...) and MODULES=(!...), but both don't work. udev loads every module which can be loaded. For example I blacklist nvidiafb, but udev loads it. Packages are up2date with testing repo. Can someone please explain it or the status is on this topic? Thanks Daniel
Re: [arch-dev-public] [signoff] fakeroot 1.9.3-1
Am Mon, 25 Feb 2008 08:24:26 +0200 schrieb "Roman Kyrylych" <[EMAIL PROTECTED]>: > > > > I've built some packges with it that seem fine, so I'll signoff. > > Signed off (i686). > somebody for x86_64?
Re: [arch-dev-public] [signoff] grub 0.97-11
On Tue, 26 Feb 2008 14:50:56 +0100 Thomas Bächler <[EMAIL PROTECTED]> wrote: > Sorry for dropping off the radar lately, I am not sure what happened > myself, but I have been away from all Arch work for two weeks. > > I corrected my grub -10 package and fixed the bugs mentioned by Andy. > Please sign off. > works here on x86_64. signoff
Re: [arch-dev-public] [signoff] iproute 2.6.24_rc7-1
On Tue, Feb 26, 2008 at 05:11:00PM +0100, Thomas Bächler wrote: > Daniel Isenmann schrieb: > > warning: iproute: local (070710-3) is newer than testing (2.6.24_rc7-1) > > > > There should be a force for this update. > > done > Please have a look at : http://www.archlinux.org/pipermail/arch-dev-public/2007-November/003307.html
Re: [arch-dev-public] [signoff] iproute 2.6.24_rc7-1
Daniel Isenmann schrieb: > On Tue, 26 Feb 2008 16:12:33 +0100 > Thomas Bächler <[EMAIL PROTECTED]> wrote: > >> Update of iproute to the latest version, please sign off. > > warning: iproute: local (070710-3) is newer than testing (2.6.24_rc7-1) > > There should be a force for this update. done signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [signoff] iproute 2.6.24_rc7-1
On Tue, 26 Feb 2008 16:12:33 +0100 Thomas Bächler <[EMAIL PROTECTED]> wrote: > Update of iproute to the latest version, please sign off. warning: iproute: local (070710-3) is newer than testing (2.6.24_rc7-1) There should be a force for this update. Daniel
Re: [arch-dev-public] [signoff] iptables 1.4.0-1
On Tue, Feb 26, 2008 at 9:04 AM, Thomas Bächler <[EMAIL PROTECTED]> wrote: > In addition to a version bump, I changed the simple_firewall.rules file > to a more generic and correct configuration. > > Please sign off. Seems to be OK here. Signoff i686. -Dan
Re: [arch-dev-public] [signoff] attr 2.4.41-1 and acl 2.2.47-1
Thomas Bächler wrote: Version bums for attr and acl, please sign off. Looks good to me, sign-off for x86_64 from me.
[arch-dev-public] [signoff] attr 2.4.41-1 and acl 2.2.47-1
Version bums for attr and acl, please sign off. signature.asc Description: OpenPGP digital signature
[arch-dev-public] [signoff] iproute 2.6.24_rc7-1
Update of iproute to the latest version, please sign off. signature.asc Description: OpenPGP digital signature
[arch-dev-public] [signoff] iptables 1.4.0-1
In addition to a version bump, I changed the simple_firewall.rules file to a more generic and correct configuration. Please sign off. signature.asc Description: OpenPGP digital signature
[arch-dev-public] [signoff] ntfs-3g 1.2216-1
Version bump, please sign off. signature.asc Description: OpenPGP digital signature
[arch-dev-public] [signoff] e2fsprogs 1.40.6-1
Another version bump, still contains our fix to the configuration file that reenables a default inode size of 128. Please sign off. signature.asc Description: OpenPGP digital signature
[arch-dev-public] [signoff] grub 0.97-11
Sorry for dropping off the radar lately, I am not sure what happened myself, but I have been away from all Arch work for two weeks. I corrected my grub -10 package and fixed the bugs mentioned by Andy. Please sign off. signature.asc Description: OpenPGP digital signature
