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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add test/rule-syntax-check.py, a script for checking the syntax of all udev
rules files passed as command line arguments.
Add a wrapper test/rules-test.sh which calls rule-syntax-check.py on all udev
rules that we ship, but does nothing if Python is not available. Integrate this
into make check/distcheck.
... that the GUdevClient object was constructed in. This change makes
GUdev follow the GLib guidelines and, more importantly, makes it
possible to actually use the library in a multi-threaded
application. Prior to this patch, signals were emitted in the thread
that ran the "default" main loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
In v141 -> v142 entry, there's a note about udevd creating
/dev/{null,kmsg,console}. It was added in commit 540f46698d,
but shortly after that removed in a00bdfa16b before v142
release.
Signed-off-by: Michal Soltys <soltys@ziu.info>
Not generating persistent MAC address rules will significantly ease cloning of
VMs. The kernel reliably sorts eth* enumeration by bus number, so as long as
you only have cards from one vendor (or more precisely, drivers), the
enumeration will be stable. Having cards from different vendors is very
unlikely in VMs.
KVM was already covered in the previous commit, this is the equivalent
blacklist for VMWare:
http://www.coffer.com/mac_find/?string=005056http://www.coffer.com/mac_find/?string=000c29https://launchpad.net/bugs/341006
Reportedly, many CD drive firmwares will only consider the MSB in a READ
command, thus if we request 17 blocks to be read, we'll actually only get 16 in
many cases, and thus miss out the interesting sector #17. This would lead to
falsely considering nonempty DVDs as blank.
Fetch 32 blocks now, which should work everywhere.
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
Commit cf2205a19 applied the "restricted overwrite" vs. "sequential" DVD-RW
test to feature_profiles() (which reads the drive capabilities), which caused
every DVD medium to be detected as ID_CDROM_MEDIA_DVD_RW. Now apply it to
cd_profiles() instead, to just check the current profile.
gudev_client_new() assumes that priv->monitor is never NULL, but this happens
on older kernels. Let's not crash client programs because of that.
https://launchpad.net/bugs/581527
Fix the manpage to describe the real behaviour of $attr: It doesn't search all
parent devices any more, just the one selected by KERNELS etc.
https://launchpad.net/bugs/348513
Rules files must end in .rules.
Also drop the redundant and confusing sentence about "file names must be
unique". What is really meant is explained in a better way in the paragraph
above.
https://launchpad.net/bugs/616108
Commit cf2205a fixed the media status for fresh DVD-RW in restricted overwrite
mode, but missed a detail: We should not report the ID_CDROM_MEDIA_SESSION_NEXT
property either, since in that mode you can never append tracks/sessions; this
just works in sequential mode.
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
Harald Hoyer discovered some incorrect behavior while debugging
problems with network interface renaming:
Udev events might be queued for devices which are renamed. A new
device registered the same time may claime the old name and create
a database entry for it. The current rename logic would move over
this databse entry to the wrong device.
Fresh DVD-RW in restricted overwite mode reports itself as "appendable"; change
it to "blank" to make it consistent with what gets reported after blanking, and
what userspace expects.
For the exotic case where some uses multi-track recording on a DVD-RW in
sequential mode, we need to tell apart sequential and restricted overwrite
modes, so keep separate states for them internally.
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
