IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit 68bffc607f.
After discussing this with Kay we decided to drop this again as by-id
links only make sense for devices that have a unique serial id. If they
don't any attempts to make them unique have the side effect of
nourishing assumptions by users that cannot be met, as the by-id device
link of a device could differ depending on the history of simultaneously
plugged in device.
So, to make sure that all device nodes follow the same rules for by-id/
symlinks, drop this patch again.
If two USB sound cards that have the same serial number are plugged in
make sure the by-id/ device node symlink is unique at least during
runtime, by including the ALSA card id in the symlink name.
This is a followup to ed1b2d9fc7.
Actually dev_t is an unsigned quad type (e.g. 64-bit even on 32-bit
x86) so defining it to be an integer is wrong and not future
proof. Thus, redefine it to actually be a dev_t (as originally wanted)
and instead add a work-around for GNOME bug #584517, see
https://bugzilla.gnome.org/show_bug.cgi?id=584517
for details. This way, GObject Introspection will still work.
This change is technically an API/ABI break but
- all released GUdev versions requires the user to understand that
the API/ABI is unstable by requiring the G_UDEV_API_IS_SUBJECT_TO_CHANGE
symbols to be defined
- functions using GUdevDeviceNumber are rarely used
so we don't bump the so number.
Signed-off-by: David Zeuthen <davidz@redhat.com>
If two USB sound cards that have the same serial number are plugged in
make sure ID_ID is unique at least during runtime, by including the ALSA
card id in the ID_ID string.
Fixes issues like this one:
http://pulseaudio.org/ticket/661
This should also address:
On Tue, Nov 3, 2009 at 16:21, Marco d'Itri <md@linux.it> wrote:
> udev_rules_new() in udev/udev-rules.c unconditionally creates the
> directory.
> This is a problem because the function is called also by e.g. udevadm
> test, and creating /dev/.udev/ when it does not exist is an unacceptable
> side effect which will break everything else that checks for its
> existence to know if udev is running.
link_find_prioritized(): Properly close directory handles to fix a major fd
leak which caused hotplugging to fail entirely in many cases due to having too
many open files.
https://launchpad.net/bugs/463347
On Thu, Oct 29, 2009 at 19:15, Christian P. Schmidt <schmidt@digadd.de> wrote:
> After the getty replaces itself with login the pam module pam_mount
> calls mount. This in turn determines that the partition to be mounted is
> LUKS encrypted, and calls cryptsetup. Cryptsetup receives the password,
> unlocks the partition, and calls udevadm settle in order to avoid some
> problems in interaction with LVM.
>
> udevadm settle never returns.
>
> The problem here is that SIGUSR1 and SIGALRM are both blocked in oldmask
> already, and never reach udevadm. No care is ever taken to ensure those
> signals are not blocked.
These retry loops are required where create_path() could race with
delete_path(). But only the main udevd process writes to the queue,
so no races will happen here.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Its use breaks too many things which expect to be run from independent
later rules, and is an idication that something needs to be fixed
properly instead.
On Wed, Oct 7, 2009 at 21:46, Alan Jenkins <sourcejedi.lkml@googlemail.com> wrote:
> Udev would have avoided the race prior to
>
> 82c785e "udevd: remove check for dev_t, DEVPATH_OLD takes care of that"
>
> (the "check" removed here used to serialize events based on the device
> major:minor number).
On Wed, Oct 7, 2009 at 22:31, Michael Guntsche <mike@it-loops.com> wrote:
> add /module/8250_pnp (module)
> remove /devices/platform/serial8250/tty/ttyS0 (tty)
> add /devices/pnp0/00:05/tty/ttyS0 (tty)
Commit f61e72d8 made raw USB printers accessible for the lp group. However,
chmoding them to 0660 is a bit over-zealous, since by default raw USB devices
are world-readable. Not being so breaks lsusb unnecessarily. Now set
permissions to 0664.
On Wed, Sep 23, 2009 at 23:11, Matthias Schwarzott <zzam@gentoo.org> wrote:
> It is about ioctl failures on amd64:
> http://bugs.gentoo.org/show_bug.cgi?id=286041
>
> A bad parameter type to an ioctl() call causes udev-146 to generate "error
> getting buffer for inotify" messages in syslog. The offending code is
> roughly:
>
> ssize_t nbytes, pos;
> // ...
> ioctl(fd, FIONREAD, &nbytes);
>
> where ssize_t is 64 bits on amd64, but the kernel code for FIONREAD (at least
> through gentoo-sources-2.6.31) uses type int:
>
> p = (void __user *) arg;
> switch (cmd) {
> case FIONREAD:
> // ...
> ret = put_user(send_len, (int __user *) p);
>
> so the upper 32 bits of "nbytes" are left uninitialized, and the subsequent
> malloc(nbytes) fails unless those 32 bits happen to be zero (or the system has
> a LOT of memory).
The previous patch was almost, but not quite, correct. Rather than
restoring the signal mask it actually tried to make an even more
restrictive signal mask (had SIGALRM been blocked when udevd started,
anyway).
Fix it harder.
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
ID_CDROM_MEDIA_SESSION_LAST_OFFSET is not set for CDs with only a single
session (i. e. for the vast majority of CDs out there). The previous rules ran
blkid with invalid arguments for these, causing CD detection to fail in
DK-disks and gvfs.
Now check whether we actually have ID_CDROM_MEDIA_SESSION_LAST_OFFSET, and if
not, call blkid without -O for specifying the offset.
Many thanks to Maxim Levitsky for tracking this down!
https://launchpad.net/bugs/431055
On 8/29/09, Florian Zumbiehl <florz@florz.de> wrote:
> Could it happen that > util_create_path() and util_delete_path()
> do run in parallel for > the same directory? After all, util_create_path()
> does handle > the case where creation of the directory happens in parallel
> to it running, so it doesn't seem all that unlikely to me ...
