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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
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>
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>
DDC_DEVICEs are control points for high-end monitors such as the
HP DreamColor. The DDC/CI interface allows userspace applications
to upload custom colorspaces and interact with the display without
using the monitor hardware controls.
Extend the DVD+RW/DVD-RAM check in commit 1ef6c9e to also cover DVD-RW, since
in "restricted overwrite" mode they behave similar to DVD+RW.
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
Those do not yet support the 0x46 "GET CONFIGURATION" support. If we have
those, fall back to the 0x51 "READ DISC INFORMATION" call. This can only
differentiate between CD-RW and CD-R, but first that's better than a complete
detection failure, and second, those old drives likely don't support more
modern media in the first place.
https://launchpad.net/bugs/502143
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
Once formatted, DVD+RW and DVD-RAM discs are always reported "complete" by the
drive. Check the if the Volume Descriptor or Volume Descriptor Anchor sectors
are empty, and if so, set the status to blank. If the disc is unformatted the
blank status is maintained and no reads are issued. If the disc is formatted and
read command fails, the status remains set to complete to avoid accidental
blanking.
Bug-Ubuntu: https://launchpad.net/bugs/581925
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
We should do only do classes of devices, not individual pieces
of hardware.
There is no way for us to manage this in the long term, and it needs
to be thought through what we want here, but it surely isn't a list of
smartphones in the udev source tarball installed on all systems.
The previous fix for udev-acl was incomplete. The ACL were not properly
assigned to the new user when switching from root's session because of
the test for 'uid != 0'.
Centralize the special handling of root to a single place (in set_facl).
https://bugzilla.redhat.com/show_bug.cgi?id=608712
Fortunato Ventre (voRia) <vorione@gmail.com> reports a lot more Samsung models
which need the "samsung-other" keymap. Instead of eternally playing catchup,
apply it to all Samsung models for now, and keep the two known special cases.
https://launchpad.net/bugs/554066
keymap: add My Mivvy G310
Fixes volume keys not sending key release on My Mivvy G310 laptop.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
Newer Lenovos apparently have a lower case "extra buttons" module, cover this
as well.
Sent by Quentin Denis <quentin.denis@gmail.com> via private mail.
This patch adds a case handling path_id invoked on a virtio-blk device.
Currently path_id walks the parent path to virtio-pci but doesn't know
that it's the end of the path and exits without building the path (providing no
output resulting in no disk/by-path symlinks to virtio-blk devices).
This patch handles the virtio-pci path and updates the path accordingly.
/lib/udev/path_id --debug /block/vda
udev_device_new_from_syspath: device 0x2300120 has devpath '/devices/virtio-pci/virtio1/block/vda'
udev_device_new_from_syspath: device 0x2300380 has devpath '/devices/virtio-pci/virtio1'
udev_device_new_from_syspath: device 0x2300670 has devpath '/devices/virtio-pci'
ID_PATH=virtio-pci-virtio1
And with the current persistent-storage rules generates:
% ls -al /dev/disk/by-path | grep vda
lrwxrwxrwx. 1 root root 9 Jun 1 22:09 virtio-pci-virtio1 -> ../../vda
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
commit 2599cabd36770785a13bf884049d649d385fd80c
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Fri Jun 18 02:08:48 2010 +0300
Add autodetection for xD/smartmedia cards
This can easily be extended for other types of FTL
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
