Bastian Blank wrote:
> On Tue, Nov 03, 2009 at 09:41:24PM +0100, Michael Biebl wrote:
>> Discussing with upstream, 95-devkit-disks.rules was changed to only act on
>> "change" events (and not "add|change")
>
> The rules may still be called with the device suspended and then block
> udev to handle
On Wed, 04 Nov 2009, Michael Biebl wrote:
> > Michael or Martin, can you integrate those 2 patches and upload?
>
> Raphael, please see my last email why those changes were not uploaded yet and
> how it has been approached differently.
Oh I missed that mail, thanks for the update. I'm not subscrib
Raphael Hertzog wrote:
> On Sun, 18 Oct 2009, Bastian Blank wrote:
>> On Fri, Oct 16, 2009 at 11:55:55PM +0200, Bastian Blank wrote:
>>> On Fri, Oct 16, 2009 at 11:43:52PM +0200, Bastian Blank wrote:
Okay. What about point 1 of my list? This still probes device-mapper
devices.
>> | - Prob
On Tue, Nov 03, 2009 at 09:41:24PM +0100, Michael Biebl wrote:
> Discussing with upstream, 95-devkit-disks.rules was changed to only act on
> "change" events (and not "add|change")
The rules may still be called with the device suspended and then block
udev to handle further rules and events, inclu
On Sun, 18 Oct 2009, Bastian Blank wrote:
> On Fri, Oct 16, 2009 at 11:55:55PM +0200, Bastian Blank wrote:
> > On Fri, Oct 16, 2009 at 11:43:52PM +0200, Bastian Blank wrote:
> > > Okay. What about point 1 of my list? This still probes device-mapper
> > > devices.
>
> | - Probe for partitions, aka
Bastian Blank wrote:
> On Fri, Oct 16, 2009 at 11:55:55PM +0200, Bastian Blank wrote:
>> On Fri, Oct 16, 2009 at 11:43:52PM +0200, Bastian Blank wrote:
>>> Okay. What about point 1 of my list? This still probes device-mapper
>>> devices.
>
> | - Probe for partitions, aka open, on all block devices
also sprach Michael Biebl [2009.10.15.1444 +0200]:
> P.S: I have to retract my statement wrt to mdadm. I double checked the Debian
> mdadm udev rules files, and it uses the upstream udev rules file that calls
> "mdadm --detail", whereas the dk-disks udev rule calls "mdadm --examine". The
> former
On Fri, Oct 16, 2009 at 11:55:55PM +0200, Bastian Blank wrote:
> On Fri, Oct 16, 2009 at 11:43:52PM +0200, Bastian Blank wrote:
> > Okay. What about point 1 of my list? This still probes device-mapper
> > devices.
| - Probe for partitions, aka open, on all block devices with a (small)
| blacklis
On Fri, Oct 16, 2009 at 06:20:48PM -0400, David Zeuthen wrote:
> Yeah, I'd like to know exactly how much of this can be expected to be in
> other distros.
All of them.
> FWIW, I've been telling the LVM/device-mapper guys for a
> long time to include udev rules etc. in the stock up
found 545032 008-1
thanks
On Sat, Oct 17, 2009 at 12:02:19AM +0200, Michael Biebl wrote:
> Bastian Blank wrote:
> > On Fri, Oct 16, 2009 at 10:45:25PM +0200, Michael Biebl wrote:
> >> I adressed the issues you mentioned [1] and just uploaded 007-3 to
> >> unstable.
> > Okay. What about point 1 of
On Thu, 2009-10-15 at 14:44 +0200, Michael Biebl wrote:
> Bastian Blank wrote:
> > On Tue, Oct 13, 2009 at 05:45:27PM +0200, Michael Biebl wrote:
> >> What we can not remove currently, is the call to devkit-disks-dm-export,
> >> as it makes additional information available like (DKM_)DM_TARGET_TYPE
Bastian Blank wrote:
> On Fri, Oct 16, 2009 at 10:45:25PM +0200, Michael Biebl wrote:
>> I adressed the issues you mentioned [1] and just uploaded 007-3 to unstable.
>
> Okay. What about point 1 of my list? This still probes device-mapper
> devices.
What? Where?
--
Why is it that all of the in
On Fri, Oct 16, 2009 at 11:43:52PM +0200, Bastian Blank wrote:
> On Fri, Oct 16, 2009 at 10:45:25PM +0200, Michael Biebl wrote:
> > I adressed the issues you mentioned [1] and just uploaded 007-3 to unstable.
> Okay. What about point 1 of my list? This still probes device-mapper
> devices.
This pa
On Fri, Oct 16, 2009 at 10:45:25PM +0200, Michael Biebl wrote:
> I adressed the issues you mentioned [1] and just uploaded 007-3 to unstable.
Okay. What about point 1 of my list? This still probes device-mapper
devices.
Bastian
--
Lots of people drink from the wrong bottle sometimes.
I adressed the issues you mentioned [1] and just uploaded 007-3 to unstable.
Michael
[1] http://git.debian.org/?p=pkg-utopia/devicekit-disks.git;a=summary
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description:
On Fri, Oct 16, 2009 at 04:37:53AM +0200, Michael Biebl wrote:
> +(g_str_has_prefix (dm_uuid, "CRYPT-LUKS1") ||
"CRYPT-LUKS1-", maybe there will be a CRYPT-LUKS10 someday.
> + g_regex_match_simple ("^CRYPT-[a-f0-9-]+$", dm_uuid, 0, 0)) &&
"^CRYPT-[0-9a-f]", no need to have
Bastian Blank wrote:
> [ Triming mdadm maintainers from CC. ]
>
> The last looks like the correct one according to the names and checks.
> The correct check for this one would be:
> CRYPT-[0-9a-f]* || CRYPT-LUKS-*
> The check for temporary-cryptsetup-* can go then. This will catch
> anything from
On Thu, Oct 15, 2009 at 08:15:22PM +0200, Bastian Blank wrote:
> On Thu, Oct 15, 2009 at 02:44:23PM +0200, Michael Biebl wrote:
> > If not, since what version of cryptsetup/dmsetup is this naming interface
> > stable?
> 1.1, which is supposed to be
> releas
[ Triming mdadm maintainers from CC. ]
On Thu, Oct 15, 2009 at 02:44:23PM +0200, Michael Biebl wrote:
> Is the DM_UUID=CRYPT-* naming scheme documented somewhere? I'd like to send
> this
> patch upstream and would need to know if it is a Debian specific feature.
I forgot to cite the information
Bastian Blank wrote:
> On Tue, Oct 13, 2009 at 05:45:27PM +0200, Michael Biebl wrote:
>> What we can not remove currently, is the call to devkit-disks-dm-export,
>> as it makes additional information available like (DKM_)DM_TARGET_TYPES,
>> which is used inside the dk-disks code.
>
> Please explai
On Tue, Oct 13, 2009 at 05:45:27PM +0200, Michael Biebl wrote:
> What we can not remove currently, is the call to devkit-disks-dm-export,
> as it makes additional information available like (DKM_)DM_TARGET_TYPES,
> which is used inside the dk-disks code.
Please explain which highlevel information
Bastian Blank schrieb:
> On Sun, Oct 11, 2009 at 09:04:09PM +0200, Andreas Barth wrote:
>> As what I read from the bug report, Bastian prefers to have all udev
>> rules in dmsetup.
>
> Not in dmsetup, but in the package that controls that sort of device. So
> dmsetup for the core rules, lvm2 for t
On Sun, Oct 11, 2009 at 09:04:09PM +0200, Andreas Barth wrote:
> As what I read from the bug report, Bastian prefers to have all udev
> rules in dmsetup.
Not in dmsetup, but in the package that controls that sort of device. So
dmsetup for the core rules, lvm2 for the lvm specific rules, cryptsetup
* Michael Biebl (bi...@debian.org) [091011 18:58]:
> Where exactly in the rules does it overwrite data setup by device mapper?
> Which part exactly in the rules file does break other apps?
> What do you suggest instead?
I think this are the core questions, and we should try to get to an
"at least"
On Wed, Sep 23, 2009 at 04:36:54PM +0200, Michael Biebl wrote:
> > But anyway, the duplication of the rules already warants this bug.
> Right, but not with this severity. So downgrading to important.
The rules are set by the kernel and userspace part of device-mapper to
make several of its users w
On Wed, Sep 23, 2009 at 05:06:00PM +0200, Michael Biebl wrote:
> Bastian Blank wrote:
> > On Wed, Sep 23, 2009 at 04:36:54PM +0200, Michael Biebl wrote:
> >> Right, but not with this severity. So downgrading to important.
> > Sure with this. You break dmsetup. Anyway, will add a conflict.
> Adding
Bastian Blank wrote:
> On Wed, Sep 23, 2009 at 04:36:54PM +0200, Michael Biebl wrote:
>> Right, but not with this severity. So downgrading to important.
>
> Sure with this. You break dmsetup. Anyway, will add a conflict.
Adding a conflict is certainly not the way I want it to go, as dk-disks is m
On Wed, Sep 23, 2009 at 04:36:54PM +0200, Michael Biebl wrote:
> Right, but not with this severity. So downgrading to important.
Sure with this. You break dmsetup. Anyway, will add a conflict.
Bastian
--
No one may kill a man. Not for any purpose. It cannot be condoned.
-- Kir
severity 545032 important
thanks
Bastian Blank wrote:
> On Fri, Sep 04, 2009 at 05:16:29PM +0200, Michael Biebl wrote:
>> Bastian Blank wrote:
>>> devicekit-disks adds its own udev rules that likes to handle add actions
>>> of device-mapper devices. This will break arbitrary usage, for example
>>>
On Fri, Sep 04, 2009 at 05:16:29PM +0200, Michael Biebl wrote:
> Bastian Blank wrote:
> > devicekit-disks adds its own udev rules that likes to handle add actions
> > of device-mapper devices. This will break arbitrary usage, for example
> > cryptsetup. So this is not allowed for anything except th
Package: devicekit-disks
Severity: critical
devicekit-disks adds its own udev rules that likes to handle add actions
of device-mapper devices. This will break arbitrary usage, for example
cryptsetup. So this is not allowed for anything except the device mapper
core with special precaution. Also it
Bastian Blank wrote:
> Package: devicekit-disks
> Severity: critical
>
> devicekit-disks adds its own udev rules that likes to handle add actions
> of device-mapper devices. This will break arbitrary usage, for example
> cryptsetup. So this is not allowed for anything except the device mapper
> co
32 matches
Mail list logo
