Hi Julien!
On Mon, 07 Sep 2009, Julien Cristau wrote:
> On Mon, Sep 7, 2009 at 14:59:44 -0300, Henrique de Moraes Holschuh wrote:
>
> > khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
> > Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
> > Modem / E270 HSDPA/HSUPA Mode
On Mon, 07 Sep 2009, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 07 Sep 2009, Julien Cristau wrote:
> > > On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > > From what I can see in /lib/udev/rules.d, the ids files
On Mon, Sep 7, 2009 at 14:59:44 -0300, Henrique de Moraes Holschuh wrote:
> khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
> Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
> Modem / E270 HSDPA/HSUPA Modem
> lrwxrwxrwx 1 root root 13 2009-09-07 14:56
> /dev/serial/by-id
On Mon, 07 Sep 2009, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 07 Sep 2009, Julien Cristau wrote:
> > > On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > > From what I can see in /lib/udev/rules.d, the ids files
On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Julien Cristau wrote:
> > On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > From what I can see in /lib/udev/rules.d, the ids files are only used to
> > > setup
> > > the (udev) env
Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Julien Cristau wrote:
>> On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
>>> From what I can see in /lib/udev/rules.d, the ids files are only used to
>>> setup
>>> the (udev) environment variable ID_VENDOR_FROM_DATABASE
>>> (75
On Mon, 07 Sep 2009, Julien Cristau wrote:
> On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > From what I can see in /lib/udev/rules.d, the ids files are only used to
> > setup
> > the (udev) environment variable ID_VENDOR_FROM_DATABASE
> > (75-net-description.rules, 75-tty-descrip
Le lundi 07 septembre 2009 à 17:29 +0200, Michael Biebl a écrit :
> > So, again, why can't the programs that want to display this do the
> > lookup themselves? Both libpciaccess and libpci provide API for this as
> > far as I can tell.
>
> I am sure, they could. My guess is, it was added to udev
Julien Cristau wrote:
> On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
>
>> From what I can see in /lib/udev/rules.d, the ids files are only used to
>> setup
>> the (udev) environment variable ID_VENDOR_FROM_DATABASE
>> (75-net-description.rules, 75-tty-description.rules, 78-sound-c
On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> From what I can see in /lib/udev/rules.d, the ids files are only used to setup
> the (udev) environment variable ID_VENDOR_FROM_DATABASE
> (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules).
>
> There are no sym
Henrique de Moraes Holschuh wrote:
> IMO, whomever came up with the idea of leaking pci.ids and usb.ids data to
> /dev, made a bad mistake. Just because you'd show something in an UI,
> doesn't mean it can be used to permanently identify a device safely. I have
> no idea what HAL, and HAL-consume
On Mon, 07 Sep 2009, Michael Biebl wrote:
> Henrique de Moraes Holschuh wrote:
> > So why exactly should we support this breakage in udev, again? If what it
> > takes is to move the usb and pci ID databases to /, so be it. When compared
> > to our kernel tarballs, they're small, less than 1MB for
Henrique de Moraes Holschuh wrote:
> So why exactly should we support this breakage in udev, again? If what it
> takes is to move the usb and pci ID databases to /, so be it. When compared
> to our kernel tarballs, they're small, less than 1MB for both of them.
Agreed. Moving usb.ids and pci.id
On Fri, 04 Sep 2009, Marco d'Itri wrote:
> On Sep 04, Ron Johnson wrote:
> > Whatever the cause, it breaks the FHS.
> Since it keeps being repeated, it is time to destroy this argument.
> FHS documents what distributions want to do: of the other relevant
> distributions, representatives from Red H
On Sun, 2009-09-06 at 05:01 +0200, Marco d'Itri wrote:
> On Sep 06, Steve Langasek wrote:
> > It's normal that in the process of drafting a standard, people will take
> > into account the prevailing real-world practices, to ensure that the
> > standard will be useful. Once something *is a standa
On Sep 06, Steve Langasek wrote:
> If you're unable to persuade upstream to change their implementation, and
> you're unwilling to diverge from upstream to ensure the package complies
> with Debian policy, your other option is to orphan the package and let
I am willing to diverge from upstream an
On Sun, Sep 06, 2009 at 12:56:03AM +0200, Marco d'Itri wrote:
> > > They are currently providing most of the manpower for developing udev
> > > and the related infrastructure so this is pretty much the practical
> > > effect, yes.
> > So what, you think this means we don't have any right to object
On Sep 05, Steve Langasek wrote:
> > They are currently providing most of the manpower for developing udev
> > and the related infrastructure so this is pretty much the practical
> > effect, yes.
> So what, you think this means we don't have any right to object when they
> design things wrong?
No
On 2009-09-05, Goswin von Brederlow wrote:
>>> Mounting NFS volumes from
>>> the initramfs is probably not worth the effort.
>> How do you make root on NFS work without this?
> By building a kernel with nfsroot support and mounting without
> locking and specific nfs version.
>
> I'm not sure if in
Petter Reinholdtsen writes:
> [Bastian Blank]
>> Why do you not extend the current setup to do another step?
>> Currently we have two
>> - in the initramfs with only minimal information and
>> - during the rcS run with / available.
>
> Eh, currently we have 5 sections during the boot:
>
> - init
Josselin Mouette writes:
> Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit :
>> In Debian, /usr/ is allowed to be on NFS.
>
> So is /.
>
>> Mounting NFS volumes from
>> the initramfs is probably not worth the effort.
>
> How do you make root on NFS work without this?
By
sean finney writes:
> On Tue, Sep 01, 2009 at 03:01:35PM +0200, Giacomo A. Catenazzi wrote:
>> Jonas Meurer wrote:
>> >do we really consider to stop support for seperate /usr? after all fhs
>> >supports seperate /usr by design. [1]
>> >i hope that we keep fhs compability within debian.
>>
>> I a
On Fri, Sep 04, 2009 at 09:12:03PM +0200, Marco d'Itri wrote:
> > But I guess Red Hat and Suse decide. Debian does what they do, nobody
> They are currently providing most of the manpower for developing udev
> and the related infrastructure so this is pretty much the practical
> effect, yes.
So w
On Fri, Sep 04, 2009 at 06:58:18PM +0200, Marco d'Itri wrote:
> On Sep 04, Bastian Blank wrote:
>
> > Why do you not extend the current setup to do another step? Currently we
> Even if this were possible at all, it would require (for a start):
> - working out all the possible side effects of synt
m...@linux.it (Marco d'Itri) writes:
> On your part, you could try to understand them instead of attributing to
> me straw man positions.
That's a good advice. Thanks. Please help me understand: What is the
usb-db and/or pci-db use case?
I'm afraid my creative imagination is far too limited to
On Sep 04, Bjørn Mork wrote:
> The issue is most certainly raised by other distributions. See e.g. the
> thread starting with http://article.gmane.org/gmane.linux.gentoo.devel/62973
This is about the micromanagement of dependencies which greatly excites
Gentoo users, so is not very relevant (and
Bjørn Mork wrote:
Personally I really can't see why these addons (usb-db,pci-db) are so
important. Nobody has demonstrated a usecase for them. Yet you make it
sound like there is no choice at all, but to include them in udev.
Seconded. The Debian 5 system I just built (2.6.29 kernel from
b
m...@linux.it (Marco d'Itri) writes:
> On Sep 04, Ron Johnson wrote:
>
>> Whatever the cause, it breaks the FHS.
> Since it keeps being repeated, it is time to destroy this argument.
> FHS documents what distributions want to do: of the other relevant
> distributions, representatives from Red Hat
On Sep 04, Bastian Blank wrote:
> Why do you not extend the current setup to do another step? Currently we
Even if this were possible at all, it would require (for a start):
- working out all the possible side effects of synthesizing all/most
(which ones?) events a second time
- having to forwa
On Sep 04, Ron Johnson wrote:
> Whatever the cause, it breaks the FHS.
Since it keeps being repeated, it is time to destroy this argument.
FHS documents what distributions want to do: of the other relevant
distributions, representatives from Red Hat and Suse said they do not
support this and exce
[Bastian Blank]
> Why do you not extend the current setup to do another step?
> Currently we have two
> - in the initramfs with only minimal information and
> - during the rcS run with / available.
Eh, currently we have 5 sections during the boot:
- initramfs with minimal set of files available.
On Tue, Sep 01, 2009 at 05:24:19AM +0200, Marco d'Itri wrote:
> FYI, udev 146 ships usb-id and pci-id programs which read
> /usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
> udev itself does not care about the results of these programs but other
> programs which used to use HAL may do, leadin
On 2009-09-04 07:46, Marco d'Itri wrote:
On Sep 04, Gabor Gombas wrote:
Incompetent, no. Careless, yes. Just think about the udev-related
breakages in the past. And speaking about design, udev was originally
praised because it can do everything in user space. Now, the authors of
udev are propo
On Sep 04, Gabor Gombas wrote:
> Incompetent, no. Careless, yes. Just think about the udev-related
> breakages in the past. And speaking about design, udev was originally
> praised because it can do everything in user space. Now, the authors of
> udev are proposing devtmpfs, because as it turned
On Fri, Sep 04, 2009 at 11:41:41AM +0200, Marco d'Itri wrote:
> So you believe that the upstream maintainers are incompetent and
> released something which is unreliable by design?
Incompetent, no. Careless, yes. Just think about the udev-related
breakages in the past. And speaking about design,
m...@linux.it (Marco d'Itri) writes:
> On Sep 04, Bjørn Mork wrote:
>
>> Yes. Any device specific matching should use vid:pid. How about just
>> disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
>> getting any users of this info in Debian? It will always be too
>> unreliabl
On Fri, Sep 4, 2009 at 11:41:41 +0200, Marco d'Itri wrote:
> On Sep 04, Steve Langasek wrote:
>
> > I still can't fathom why someone decided that udev should be responsible for
> > translating PCI IDs and USB IDs into text strings. This smells of crazy.
> I think that part of the rationale is
On Sep 04, Steve Langasek wrote:
> I still can't fathom why someone decided that udev should be responsible for
> translating PCI IDs and USB IDs into text strings. This smells of crazy.
I think that part of the rationale is that eventually HAL will go away
replaced by udev and programs like thi
Steve Langasek writes:
> I still can't fathom why someone decided that udev should be responsible for
> translating PCI IDs and USB IDs into text strings. This smells of crazy.
Yes. Any device specific matching should use vid:pid. How about just
disabling the /lib/udev/{pci,usb}-db helpers al
Steve Langasek wrote:
On Fri, Sep 04, 2009 at 12:59:10AM -0400, Felipe Sateler wrote:
The issue was raised by the udev upstream maintainer along with the udev
package maintainers of the major distributions, who all agreed that this
configuration is not supported.
FYI, udev 146 ships usb-id and
On Fri, Sep 04, 2009 at 12:59:10AM -0400, Felipe Sateler wrote:
> >>> The issue was raised by the udev upstream maintainer along with the udev
> >>> package maintainers of the major distributions, who all agreed that this
> >>> configuration is not supported.
> >> FYI, udev 146 ships usb-id and pci
Giacomo A. Catenazzi wrote:
> Marco d'Itri wrote:
>> On May 31, md wrote:
>>
>>> The issue was raised by the udev upstream maintainer along with the udev
>>> package maintainers of the major distributions, who all agreed that this
>>> configuration is not supported.
>> FYI, udev 146 ships usb-id a
On Thu, Sep 03, 2009 at 12:53:10PM +0200, Tollef Fog Heen wrote:
> ]] Florian Lohoff
>
> | I have ~600 Machines in the field - all with /usr on a seperate fs - If
> Debian
> | is going to make seperate /usr a no-go its about 30 Euros worth
> | of field Engineer time - swapping disks.
>
> I'
On Wed, Sep 02, 2009 at 11:11:31PM +0200, Josselin Mouette wrote:
> Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit :
> > /usr was on seperate filesystems for decades and some 3733t broken by design
> > Desktop utility turns around old Unix paradigms? I dont get it ...
>
> Sin
On Thu, 03 Sep 2009 13:23:11 +0200, Marc Haber
wrote:
>On Wed, 2 Sep 2009 22:30:37 +0200, Florian Lohoff
>wrote:
>>I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
>>is going to make seperate /usr a no-go its about 30 Euros worth
>>of field Engineer time - swappi
On Wed, 2 Sep 2009 22:30:37 +0200, Florian Lohoff
wrote:
>I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
>is going to make seperate /usr a no-go its about 30 Euros worth
>of field Engineer time - swapping disks.
>
>/usr was on seperate filesystems for decades an
Josselin Mouette wrote:
Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit :
/usr was on seperate filesystems for decades and some 3733t broken by design
Desktop utility turns around old Unix paradigms? I dont get it ...
Since when is udev a desktop utility?
hmm. udev doesn'
On Thu, Sep 03, 2009 at 12:53:10PM +0200, Tollef Fog Heen wrote:
> ]] Florian Lohoff
> | I have ~600 Machines in the field - all with /usr on a seperate fs - If
> Debian
> | is going to make seperate /usr a no-go its about 30 Euros worth
> | of field Engineer time - swapping disks.
> I'm fa
]] Florian Lohoff
| I have ~600 Machines in the field - all with /usr on a seperate fs - If Debian
| is going to make seperate /usr a no-go its about 30 Euros worth
| of field Engineer time - swapping disks.
I'm fairly sure I can sell you a small shell script that you can install
in the init
Le mercredi 02 septembre 2009 à 22:30 +0200, Florian Lohoff a écrit :
> /usr was on seperate filesystems for decades and some 3733t broken by design
> Desktop utility turns around old Unix paradigms? I dont get it ...
Since when is udev a desktop utility?
--
.''`. Josselin Mouette
: :' :
On Wed, Sep 02, 2009 at 04:26:08AM +0200, Marco d'Itri wrote:
> On Sep 01, Steve Langasek wrote:
> > You are drawing an artificial distinction between /usr and /var which is not
> > consistent with the standard, nor with how I've been laying out my
> > filesystems for years. I'm not going to refa
Marco d'Itri wrote:
On May 31, md wrote:
The issue was raised by the udev upstream maintainer along with the udev
package maintainers of the major distributions, who all agreed that this
configuration is not supported.
FYI, udev 146 ships usb-id and pci-id programs which read
/usr/share/misc/u
On Sep 01, Steve Langasek wrote:
> Why do programs need udev to read this information in at driver load time?
> Why can't packages that need this information query it when they need it
> (which is well after /usr is mounted), instead of expecting udev to provide
> it?
I did not design this aspect
On Tue, Sep 01, 2009 at 05:24:19AM +0200, Marco d'Itri wrote:
> > The issue was raised by the udev upstream maintainer along with the udev
> > package maintainers of the major distributions, who all agreed that this
> > configuration is not supported.
> FYI, udev 146 ships usb-id and pci-id progra
Neil McGovern wrote:
Do we only support network configuration with DHCP now?
That's not the point, the slightly off-topic point we got onto was that
you can in fact share / between hosts if you're using DHCP. I don't
think the FHS supports it, but I can see uses for it in places.
--
Chris
On Tue, Sep 01, 2009 at 04:47:54PM +0200, Josselin Mouette wrote:
> Le mardi 01 septembre 2009 à 15:36 +0100, Chris Jackson a écrit :
> > Well, /etc needs to be on /, since otherwise you can't get to fstab to
> > mount it, and generally things like /etc/hostname will be different, so,
> > while
On Sep 01, Gabor Gombas wrote:
> How about re-running the rules after all the filesystems have been
> mounted?
No.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Tue, Sep 01, 2009 at 01:45:23PM +0200, Marco d'Itri wrote:
> > How will usb-id and pci-id behave, if the ids files are not accessible?
> Print an error on stderr and exit with rc=1.
> The more interesting question is which packages care about this
> information and how they will behave when it
Josselin Mouette wrote:
Ever heard of DHCP ?
Mmm, fair enough. Anyway, it isn't true that what's said about /usr also
applies to / since, once init is running (and a little before that), we
definitely have a /, but may not have a /usr yet, or /usr may fail to
mount. I'm not 100% sure wheth
Le mardi 01 septembre 2009 à 15:36 +0100, Chris Jackson a écrit :
> Well, /etc needs to be on /, since otherwise you can't get to fstab to
> mount it, and generally things like /etc/hostname will be different, so,
> while I suppose it's theoretically possible, I'd take it also to be
> somewhat
Josselin Mouette wrote:
/ is shareable as well, if you mount it read-only.
Everything that has been said about /usr in this thread can also be said
about /, so please think about it before making propositions.
Well, /etc needs to be on /, since otherwise you can't get to fstab to
mount it,
Le mardi 01 septembre 2009 à 13:41 +0100, Chris Jackson a écrit :
> Well, /usr is supposed to be shareable between hosts; forcing it to be
> on the same filesystem as / is very sub-optimal.
/ is shareable as well, if you mount it read-only.
Everything that has been said about /usr in this threa
On Tue, Sep 01, 2009 at 11:18:47AM +0200, Giacomo A. Catenazzi wrote:
> Josselin Mouette wrote:
> >Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a
> >écrit :
> >>In Debian, /usr/ is allowed to be on NFS.
> >
> >So is /.
>
> I was thinking the same, but #441291 (root over nfs) is st
Mike Hommey wrote:
An interesting corollary is how will upgraded systems behave ? A lot of
the currently installed ones have a separate /usr. It would be a shame to
tell users they have to reinstall (or go through hoops to put /usr in /)
Well, /usr is supposed to be shareable between hosts; f
On Tue, Sep 01, 2009 at 03:01:35PM +0200, Giacomo A. Catenazzi wrote:
> Jonas Meurer wrote:
> >do we really consider to stop support for seperate /usr? after all fhs
> >supports seperate /usr by design. [1]
> >i hope that we keep fhs compability within debian.
>
> I agree, but the problem is "how?
Jonas Meurer wrote:
do we really consider to stop support for seperate /usr? after all fhs
supports seperate /usr by design. [1]
i hope that we keep fhs compability within debian.
I agree, but the problem is "how?".
Moving too much thinkgs from /usr to / is also against
the design of FHS, thus
hey,
On 01/09/2009 Mike Hommey wrote:
> On Tue, Sep 01, 2009 at 01:45:23PM +0200, Marco d'Itri wrote:
> > On Sep 01, Michael Biebl wrote:
> >
> > > Wouldn't make it sense then if udev had a recommends or at least suggests
> > > for
> > > usbutils and pciutils?
> > Yes, the next upload (today i
On Tue, Sep 01, 2009 at 01:45:23PM +0200, Marco d'Itri wrote:
> On Sep 01, Michael Biebl wrote:
>
> > Wouldn't make it sense then if udev had a recommends or at least suggests
> > for
> > usbutils and pciutils?
> Yes, the next upload (today in experimental maybe) will do this.
>
> > How will u
On Sep 01, Michael Biebl wrote:
> Wouldn't make it sense then if udev had a recommends or at least suggests for
> usbutils and pciutils?
Yes, the next upload (today in experimental maybe) will do this.
> How will usb-id and pci-id behave, if the ids files are not accessible?
Print an error on st
[Josselin Mouette]
> Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit :
>> In Debian, /usr/ is allowed to be on NFS.
>
> So is /.
Perhaps, but it is not a supported solution which need to be handled
by all packages. /usr/ on NFS on the other hand is a supported
solution tha
Josselin Mouette wrote:
Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit :
In Debian, /usr/ is allowed to be on NFS.
So is /.
I was thinking the same, but #441291 (root over nfs) is still open.
ciao
cate
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.d
Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit :
> In Debian, /usr/ is allowed to be on NFS.
So is /.
> Mounting NFS volumes from
> the initramfs is probably not worth the effort.
How do you make root on NFS work without this?
--
.''`. Josselin Mouette
: :' :
`. `
[Giacomo A. Catenazzi]
> I still think /usr standalone should be supported, but I agree with
> you that it could be difficult to support it in actual way.
>
> Thus: Are there any technical difficulties to mount usr in the
> standard initramfs?
> I don't think there are more "special" /usr environm
Marco d'Itri wrote:
On May 31, md wrote:
The issue was raised by the udev upstream maintainer along with the udev
package maintainers of the major distributions, who all agreed that this
configuration is not supported.
FYI, udev 146 ships usb-id and pci-id programs which read
/usr/share/misc/u
Marco d'Itri wrote:
> On May 31, md wrote:
>
>> The issue was raised by the udev upstream maintainer along with the udev
>> package maintainers of the major distributions, who all agreed that this
>> configuration is not supported.
> FYI, udev 146 ships usb-id and pci-id programs which read
> /usr
On May 31, md wrote:
> The issue was raised by the udev upstream maintainer along with the udev
> package maintainers of the major distributions, who all agreed that this
> configuration is not supported.
FYI, udev 146 ships usb-id and pci-id programs which read
/usr/share/misc/usb.ids and /usr/sh
76 matches
Mail list logo
