Am 06.01.2012 10:07, schrieb Arch Website Notification:
> === Signoff report for [testing] ===

Can we get a time/date or similar in the subject of these messages?

> == Incomplete signoffs for [core] (6 total) ==
> * cryptsetup-1.4.1-1 (i686)
> 0/2 signoffs
> * openvpn-2.2.2-1 (i686)
> 1/2 signoffs

Does anyone use those? If not, I'll move them without signoffs.

Am Thu, 5 Jan 2012 19:40:47 -0500
schrieb Dave Reisner <d@falconindy.com>:

> Hey all,
>
> I've just dropped kmod-3 into testing as a replacement for
> module-init-tools. This is still a young project, but it has a lot of
> support from active people, and I (as well as Tom) have been working
> closely with upstream to flesh out and fix bugs.
>
> For the most part, you should not notice any difference. kmod was
> designed as a drop-in replacement for m-i-t, and all the binaries
> should exist with the (mostly) the same options. Whenever possible,
> options or features marked deprecated in m-i-t were removed, such as:
>
> - parsing of depmod/modprobe config for files not ending in .conf
> - modprobe's -l, --list options
>
> IMPORTANT: In line with the first change, it needs to be pointed out
> that we will no longer package /etc/modprobe.d/modprobe.conf. This
> means that if you wrote to that file, it will be .pacsave'd on
> removal of m-i-t and you must rename it. We will continue to ship
> what used to be called /etc/depmod.d/depmod.conf, but rename
> it /lib/depmod.d/search.conf. This will be a read only file -- users
> should put their own tweaks in /etc/depmod.d.

Such thing should be brought up to our lists before they hit the repo.

All files in /etc/depmod.d/ and /etc/modprobe.d/ are ignored
here. So module blacklisting doesn't work there for users/admins. We
need to fix https://bugs.archlinux.org/task/27846 to allow admins to
blacklist modules again.

The only place that works here is /lib/modprobe.d/foo.conf

Should we rebuild all packages that right now put files
into /etc/modprobe.d/ ? Can somebody with a full svn checkout do a grep
to get a list?

-Andy

On Fri, Jan 6, 2012 at 11:29 AM, Andreas Radke <andyrtr@archlinux.org> wrote:
> All files in /etc/depmod.d/ and /etc/modprobe.d/ are ignored
> here. So module blacklisting doesn't work there for users/admins. We
> need to fix https://bugs.archlinux.org/task/27846 to allow admins to
> blacklist modules again.

This is a packaging bug, Dave is rebuilding with a fix.

> Should we rebuild all packages that right now put files
> into /etc/modprobe.d/ ? Can somebody with a full svn checkout do a grep
> to get a list?

In general, and regardless of kmod, packages should install their
config files in /lib/modprobe.d, and leave /etc/modprobe.d to admins.

This works (in module-init-tools, as well as in kmod) in the same way
as with udev's rule files. If a file foo.conf exists in both /etc and
in /lib, the version in /etc is used and the one in /lib is ignored.
This means the admin can easily override the standard config files
supplied by the packages, and the package updating the config file
does not create .pacnew/.pacsave files.

I'll be looking at making a todo with packages to be updated, but
there should be no hurry.

Cheers,

Tom

Hi Dave,
On Fri, Jan 6, 2012 at 1:40 AM, Dave Reisner <d@falconindy.com> wrote:
> I've just dropped kmod-3 into testing as a replacement for
> module-init-tools. This is still a young project, but it has a lot of
> support from active people, and I (as well as Tom) have been working
> closely with upstream to flesh out and fix bugs.

As kmod is installed in /usr/bin, the symlinks from /sbin/modprobe et
al means that users with a separate /usr will be out in the cold.

Once the usr hook is out, this is all good, but in the meantime I
guess this is a bit too harsh? Maybe best to keep m-i-t until usr-hook
is ready, and install kmod without the symlinks?

Alternatively, we could move kmod to /, but then we'd have to make
sure there are no new deps we also need to move, and people would cry
when we move it back, so I'm sort of against that.

I guess the order of doing things should be:

kmod-3 (without symlinks)
util-linux (2.21 or backporting to 2.20, i guess we'll backport if
this is how we end up doing it)
mkinitcpio (with usr hook)
kmod-* (with symlinks, drop m-i-t)
udev-176

If possible I'd like to drop m-i-t in good time before udev-176, so
we can clear up any bugs from that transition before they get muddled
together with the new udev release.

What do you think? If you agree I'll push a new util-linux today (if
you also remind me which patches you need backported ;-) ).

Cheers,

Tom

On Fri, Jan 6, 2012 at 11:23, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 06.01.2012 10:07, schrieb Arch Website Notification:
>> === Signoff report for [testing] ===
>
> Can we get a time/date or similar in the subject of these messages?
>
>> == Incomplete signoffs for [core] (6 total) ==
>> * cryptsetup-1.4.1-1 (i686)
>> Â* Â* 0/2 signoffs
>> * openvpn-2.2.2-1 (i686)
>> Â* Â* 1/2 signoffs
>
> Does anyone use those? If not, I'll move them without signoffs.

I use cryptsetup (root and 4 other partitions).
Upgrade went fine.
Signoff x86_64.

--
Roman Kyrylych (Ð*оман Кирилич)

Am 06.01.2012 14:19, schrieb Roman Kyrylych:
> On Fri, Jan 6, 2012 at 11:23, Thomas Bächler <thomas@archlinux.org> wrote:
>> Am 06.01.2012 10:07, schrieb Arch Website Notification:
>>> === Signoff report for [testing] ===
>>
>> Can we get a time/date or similar in the subject of these messages?
>>
>>> == Incomplete signoffs for [core] (6 total) ==
>>> * cryptsetup-1.4.1-1 (i686)
>>> 0/2 signoffs
>>> * openvpn-2.2.2-1 (i686)
>>> 1/2 signoffs
>>
>> Does anyone use those? If not, I'll move them without signoffs.
>
> I use cryptsetup (root and 4 other partitions).
> Upgrade went fine.
> Signoff x86_64.

You see, the signoff report says that signoffs are lacking for i686 (as
usual).

On Fri, Jan 6, 2012 at 15:22, Thomas Bächler <thomas@archlinux.org> wrote:
> You see, the signoff report says that signoffs are lacking for i686 (as
> usual).

My bad. Sorry, no working i686 with cryptsetup.
For such cases a user signoff request on arch-general may be useful.
Or just move it without signoff.

--
Roman Kyrylych (Ð*оман Кирилич)

On Fri, Jan 06, 2012 at 01:17:37PM +0100, Tom Gundersen wrote:
> I guess the order of doing things should be:
>
> kmod-3 (without symlinks)
> util-linux (2.21 or backporting to 2.20, i guess we'll backport if
> this is how we end up doing it)
> mkinitcpio (with usr hook)
> kmod-* (with symlinks, drop m-i-t)
> udev-176

Let's leave kmod as is for now. We'll get the /usr mount functionality
ready for mkinitcpio and roll that out for testing after you repackage
u-l 2.20.1 for me.

> If possible I'd like to drop m-i-t in good time before udev-176, so
> we can clear up any bugs from that transition before they get muddled
> together with the new udev release.

Well, the "possible" part is only made possibly by kmod-3 not throwing
any show stoppers. It hasn't... yet.

> What do you think? If you agree I'll push a new util-linux today (if
> you also remind me which patches you need backported ;-) ).

14f66ad6^..46c59b51: fixes bugs that Gerardo pointed out about mount not
behaving properly with regard to attempting canonicalization of pseudofs
mount sources. This is visible in the form of /run being mounted with a
source of /run (rather than just run). It also crops up in a few other
situations [1] and is is varying degrees of annoying, but isn't fatal.

d466c6a1: alters the -s, --fstab option of findmnt -- allows an optarg
to point to an arbitrary fstab. I'd like to leverage this for mounting
/usr from early userspace.

d

[1] http://mailman.archlinux.org/pipermail/arch-projects/2011-December/002297.html

On Friday 06 of January 2012 15:30:16 Roman Kyrylych wrote:
> My bad. Sorry, no working i686 with cryptsetup.
> For such cases a user signoff request on arch-general may be useful.
> Or just move it without signoff.
user sign-off for cryptsetup on i686, 4 partitions on a laptop, running daily. all ok.
--

Marek Otahal )

On 01/04/2012 11:23 AM, walt wrote:
> I'm always getting email with links to youtube and various
> other flash-intensive websites, and just a few days ago the
> flash content stopped loading in firefox when I click on the
> URL in thunderbird.

I still have no idea what the problem was, but it's fixed with
today's update to Thunderbird 9.