On Wed, Jan 04, 2006 at 11:52:58AM +0100, Josselin Mouette wrote:
> Furthermore, udev doesn't bring new problems. You can't have a
> persistent naming scheme with a static /dev either, unless you are
> loading modules by hand. If you still want to load your modules by hand,
> udev won't prevent yo
Le mercredi 04 janvier 2006 à 01:06 +, Stephen Gran a écrit :
> > Can you give us a way to change permissions of a device that can be
> > plugged or unplugged?
>
> Of course. With a static /dev/, the node is always there to be operated
> on whether or not there is hardware associated with the
This one time, at band camp, Josselin Mouette said:
> Le jeudi 29 décembre 2005 à 21:25 -0600, Adam Heath a écrit :
> > > You edit or add to the udev rules. These are usually used to set
> > > policy for whole categories of devices, but you can of course fine
> > > tune it, or replace all the stan
Le jeudi 29 décembre 2005 à 21:25 -0600, Adam Heath a écrit :
> > You edit or add to the udev rules. These are usually used to set
> > policy for whole categories of devices, but you can of course fine
> > tune it, or replace all the standard rules with your own. The default
> > gives you all the
On Dec 31, Joey Hess <[EMAIL PROTECTED]> wrote:
> Is there any good way to map from a given device (or set of related
> devices) in /dev to a udev rule that will match and allow overriding
> only that device?
For the general case, no: e.g. compare udevinfo -a -p /sys/block/hda and
udevinfo -a -p /
Joey Hess wrote:
> If there is then it would be possible to write a tool
> like what I think Anthony is suggesting:
>
> udev-chown 666 /dev/cdrom
> udev-chmod -a 644 /dev/sda /dev/sdb # change all scsi usb devices
>
That'd definitely be a great tool.
--
To UNSUBSCRIBE, email to [EMAIL PROTEC
Marco d'Itri wrote:
> The correct solution would be to add this to a file like
> /etc/udev/rules.d/local.rules:
>
> KERNEL=="hdc", GROUP="disk"
Is there any good way to map from a given device (or set of related
devices) in /dev to a udev rule that will match and allow overriding
only that device
pe, 2005-12-30 kello 09:34 +0100, Wouter Verhelst kirjoitti:
> On Fri, Dec 30, 2005 at 05:31:09PM +1000, Anthony Towns wrote:
> > On Fri, Dec 30, 2005 at 12:40:37AM -0600, Adam Heath wrote:
> > > > Indeed. Editing plain text configuration files has never been the Unix
> > > > way, and vi certainly
Adam Heath writes:
> What ever happened to standard unix tools? chmod/mkdir/chown/mv?
>
> You're suggesting doing things like some other OS(like Windows, were you have
> to edit a registry).
I agree with you, but OTOH, if I change something in /usr, I have to
fuck around with dpkg-statoverride
On Dec 30, Frank Lichtenheld <[EMAIL PROTECTED]> wrote:
> Hmm, I have a package that depends on makedev (pbbuttonsd) and I was
> wondering why it doesn't show up in your list? Maybe because it
> is powerpc only?
Yes, I did build the list on my x86 box.
--
ciao,
Marco
signature.asc
Description:
On Dec 30, Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
> bug filed.) Next, it looks like you edit 020_permissions.rules (or
> rather the file it is symlinked to). Maybe you change this line:
>
> ENV{ID_CDROM}=="?*",GROUP="cdrom"
>
> to
>
> ENV{ID_CDROM}=="?*", KERN
On Thu, Dec 29, 2005 at 01:39:01PM +0100, Marco d'Itri wrote:
> To prepare for the eventual removal of makedev, I propose that packages
> currently depending on it will add an alternative dependency to udev.
> Also, policy should be amended accordingly.
>
> The affected packages are:
[...]
Hmm, I
On Fri, Dec 30, 2005 at 05:31:09PM +1000, Anthony Towns wrote:
> On Fri, Dec 30, 2005 at 12:40:37AM -0600, Adam Heath wrote:
> > > Indeed. Editing plain text configuration files has never been the Unix
> > > way, and vi certainly isn't a standard unix tool.
> > No, I'm saying why are people attempt
On Fri, Dec 30, 2005 at 12:40:37AM -0600, Adam Heath wrote:
> > Indeed. Editing plain text configuration files has never been the Unix
> > way, and vi certainly isn't a standard unix tool.
> No, I'm saying why are people attempting to replace what already works with
> something new and obfusicated?
On Fri, 30 Dec 2005, Matthew Garrett wrote:
> Adam Heath <[EMAIL PROTECTED]> wrote:
>
> > That's the wrong answer.
> >
> > What ever happened to standard unix tools? chmod/mkdir/chown/mv?
> >
> > You're suggesting doing things like some other OS(like Windows, were you
> > have
> > to edit a regi
Matthew Garrett wrote:
> Indeed. Editing plain text configuration files has never been the Unix
> way, and vi certainly isn't a standard unix tool.
>
I think the right question for him to ask is, "what ever happened to the
unix way?"
chmod, chown, etc. are all simple tools that do one job and d
Adam Heath <[EMAIL PROTECTED]> wrote:
> That's the wrong answer.
>
> What ever happened to standard unix tools? chmod/mkdir/chown/mv?
>
> You're suggesting doing things like some other OS(like Windows, were you have
> to edit a registry).
Indeed. Editing plain text configuration files has neve
On Fri, 30 Dec 2005, Roger Leigh wrote:
> > How does persistance of the permission model work? Can I do chown/chmod on
> > the dynamic files in /dev, and have them remain the next time? Even if a
> > device node changes it's name? Or do I have to edit some alternative
> > database?
>
> You edit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam Heath <[EMAIL PROTECTED]> writes:
> On Thu, 29 Dec 2005, Marco d'Itri wrote:
>
>> On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
>>
> How does persistance of the permission model work? Can I do chown/chmod on
> the dynamic files in /dev, and h
On Thu, 29 Dec 2005, Adam Heath wrote:
> On Thu, 29 Dec 2005, Marco d'Itri wrote:
>
> > On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
> >
> > > > Because /eventually/ it will not be needed anymore (at least by most
> > > > users, which then will be able to remove it from their systems).
> > > I
On Thu, 29 Dec 2005, Marco d'Itri wrote:
> On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
>
> > > Because /eventually/ it will not be needed anymore (at least by most
> > > users, which then will be able to remove it from their systems).
> > Is there something to replace it, completely, in *all*
On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
> > Because /eventually/ it will not be needed anymore (at least by most
> > users, which then will be able to remove it from their systems).
> Is there something to replace it, completely, in *all* situations?
udev, at least for the general case of
On Thu, 29 Dec 2005, Marco d'Itri wrote:
> On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
>
> > > To prepare for the eventual removal of makedev, I propose that packages
> > Er, why is makedev being removed? Please clue me in.
> "Eventual" is the key word here.
> Because /eventually/ it will no
On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
> > To prepare for the eventual removal of makedev, I propose that packages
> Er, why is makedev being removed? Please clue me in.
"Eventual" is the key word here.
Because /eventually/ it will not be needed anymore (at least by most
users, which th
On Thu, 29 Dec 2005, Marco d'Itri wrote:
> To prepare for the eventual removal of makedev, I propose that packages
> currently depending on it will add an alternative dependency to udev.
> Also, policy should be amended accordingly.
Er, why is makedev being removed? Please clue me in.
--
To U
On Thu, 29 Dec 2005, Marco d'Itri wrote:
> On Dec 29, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> No. I mean that it currently depends on makedeva while it should depend
> on makedev | udev.
I see.
> > rng-tools postinst does this:
> > (cd /dev && ./MAKEDEV hwrandom || ./MAKEDEV inte
On Dec 29, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> Huh? rng-tools certainly takes benefit of MAKEDEV. It doesn't bork if
> MAKEDEV has disappeared, though. Is that what you mean?
No. I mean that it currently depends on makedeva while it should depend
on makedev | udev.
> rng-to
On Thu, 29 Dec 2005, Marco d'Itri wrote:
> These packages have already been fixed:
> rng-tools
Huh? rng-tools certainly takes benefit of MAKEDEV. It doesn't bork if
MAKEDEV has disappeared, though. Is that what you mean?
rng-tools postinst does this:
(cd /dev && ./MAKEDEV hwrandom || ./MAKEDEV
On Thu, Dec 29, 2005 at 01:39:01PM +0100, Marco d'Itri wrote:
> To prepare for the eventual removal of makedev, I propose that packages
> currently depending on it will add an alternative dependency to udev.
> Also, policy should be amended accordingly.
It might be useful to tell the maintainers
to, 2005-12-29 kello 13:39 +0100, Marco d'Itri kirjoitti:
> To prepare for the eventual removal of makedev, I propose that packages
> currently depending on it will add an alternative dependency to udev.
> Also, policy should be amended accordingly.
>
> The affected packages are:
This is the same
To prepare for the eventual removal of makedev, I propose that packages
currently depending on it will add an alternative dependency to udev.
Also, policy should be amended accordingly.
The affected packages are:
alevt
camstream
cdrecord
dvb-utils
fbset
gnupg
gnupg2
irda-utils
isdnutils-base
joys
31 matches
Mail list logo
