Re: overriding udev rules
Am 10.09.2013 01:28, schrieb Uoti Urpala: > Russ Allbery wrote: >> Kay Sievers writes: >>> Hmm, why would upgrades break? >> >>> The old file would still be there, rename the devices (if you keep the >>> patch to swap names, which upstream does not support any more), and take >>> precedence over tht new names; the old rules file would just not be >>> updated anymore when new devices appear. >> >> Manually-deployed /etc/network/interfaces files that assume a specific >> device naming come to mind. We have tons of those at work. > > Why would those break? Just having a manually-deployed > /etc/network/interfaces file that uses names like "eth0" should not > break upgrades, because as mentioned in the part you quoted, the > existing already-generated rules should still trigger and keep renaming > the same card to eth0. So you need to assume something more to have an > example of a problem case. As I mentioned earlier, the problem is for those cases, where we *didn't* generate persistent network interface names and used the kernel provided names. The conditions are listed at [1]. In such a case, the file /etc/udev/rules.d/70-persistent-net.rules will *not* be created. (There is also the case where an administrator decided to opt-out and not use the persistent naming by running "echo : > /etc/udev/rules.d/75-persistent-net-generator.rules") Kay was kind enough to point out [2], that the new network interface naming has similar rules where it skips the renaming but there might be setups where those rules don't overlap, and there you would get a network interface name change after an upgrade. Kay expects this number to be very low. The risk of breaking setups on upgrades made me uneasy though. We have to be reasonably sure that the number of breakages is indeed very low and ideally can detect such cases before we decide making the new interface naming the default (at least for upgrades). So far nobody did the analysis for that. Michael [1] http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=blob;f=debian/extra/rules/75-persistent-net-generator.rules;h=b6fcb917ee220b6ec6305b7170680caac3f0acdd;hb=refs/heads/debian-experimental#l23 [2] -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
Uoti Urpala writes:
> Russ Allbery wrote:
>>Kay Sievers writes:
>> > Hmm, why would upgrades break?
>>
>> > The old file would still be there, rename the devices (if you keep the
>> > patch to swap names, which upstream does not support any more), and take
>> > precedence over tht new names; the old rules file would just not be
>> > updated anymore when new devices appear.
>>
>> Manually-deployed /etc/network/interfaces files that assume a specific
>> device naming come to mind. We have tons of those at work.
>
> Why would those break? Just having a manually-deployed
> /etc/network/interfaces file that uses names like "eth0" should not
> break upgrades, because as mentioned in the part you quoted, the
> existing already-generated rules should still trigger and keep renaming
> the same card to eth0. So you need to assume something more to have an
> example of a problem case.
Things will break because the new scheme changes interface names which
never have been added to the generated rules.
As just one example, these names have been in use at some point in time
on my laptop:
bjorn@nemi:~$ egrep ^iface /etc/network/interfaces
iface lo inet loopback
iface eth0 inet manual
iface wlan0 inet manual
iface default inet dhcp
iface mbm0 inet dhcp
iface mb0 inet dhcp
iface wwan0 inet dhcp
iface wwan1 inet dhcp
iface test inet dhcp
iface debug inet dhcp
iface mob inet dhcp
iface mbb inet dhcp
iface testv4 inet dhcp
iface testv6 inet6 manual
iface usb0 inet dhcp
iface usb1 inet dhcp
iface tap0 inet manual
iface tap0.42 inet manual
iface bnep0 inet dhcp
Only two of them have persistent entries and can be expected to continue
working:
bjorn@nemi:~$ grep NAME /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:21:86:a3:25:7d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="0c:8b:fd:08:09:71", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="wlan*", NAME="wlan0"
I'm not claiming that I use all those entries, and some of them were
added due to breakage caused by the existing scheme. But this doesn't
change the fact that converting to the new scheme will cause additional
breakage, e.g. by renaming my internal wwanX devices to wwsomething.
I'll leave up to others to decide whether such breakage is acceptable or
not.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob81t0u0@nemi.mork.no
Re: new persistent network interface naming [Re: overriding udev rules]
Btw, we didn't remove support for the new predictable network interface naming scheme. It's explicitly opt-in atm and you can use it by setting the net.ifnames=1 kernel command line parameter [1]. Existing NAMEs set via /etc/udev/rules.d/70-persistent-net.rules still take precedence, so you will have to remove that file. Just wanted to mention this in case anyone want's to test the new scheme in Debian. You'll need udev 204-1 or later. Michael [1] http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=d5051f7666e25ecf2b32c7076ce18c1de969d01b -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: overriding udev rules
Hi, Am 10.09.2013 02:06, schrieb Patrick Lauer: > On 09/10/2013 02:50 AM, Lennart Poettering wrote: >> See >> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ >> >> The resulting names are somtimes a bit ugly, but predictable and stable, >> and do not change on every VM reboot... [..] > There are still race conditions. The point here is, that the new network naming scheme doesn't reuse the ethX namespace but completely different names which do not clash with the kernel names. Say you have two network interfaces A and B and a udev rule which assigns A the NAME eth1. So if the kernel would assign A eth0 an B eth1, and you are in the process of renaming A to eth1, you get a race condition. By using a completely different naming scheme you avoid that problem. But maybe I misunderstood you what you meant to imply saying it still has race conditions and it would be great if you can elaborate. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Mass bug filing: Ruby packages still following old policy
Hi, I am about to file a bug on ~30 packages, most of them Ruby libraries, some of them packages that include a Ruby library between their outputs. I am still going through the packages to get a final list, but it will mostly affect: • libabstract-ruby • libamazon-ruby • libamrita2-ruby • libescape-ruby • libgdal-ruby • libgv-ruby • libhdfeos5-ruby • libhdfeos5-ruby1.8 • libhtml-htmltokenizer-ruby • libhtml-template-ruby • libhtree-ruby1.8 • liblangscan-ruby • libmapscript-ruby • libmaruku-ruby • libneedle-extras-ruby • libnet-netrc-ruby • libobexftp-ruby • libposixlock-ruby • libraspell-ruby • librdf-ruby • librfilter-ruby1.8 • libroot-bindings-ruby5.34 • libroot-bindings-ruby-dev • librrd-ruby • libsnmp-ruby • libstfl-ruby • libstfl-ruby • libsuikyo-ruby1.8 • libsvn-ruby • libtcltk-ruby • libtioga-ruby • libvorbisfile-ruby • libwebapp-ruby • libzip-ruby We want to request the release of Ruby 1.8 (which will surely break most of them); Ruby 1.9.3 is already the default interpreter version, and Ruby 2.0 has already been accepted in Debian. The new policy allows, between many other niceties, to no longer require maintainers to create a binary package for each interpreter version (and really makes interpreter transitions smoother). I will file the bugs with "Normal" severity, although I expect most if not all of the affected packages to become uninstallable and FTBFS when 1.8 is dropped. signature.asc Description: Digital signature
Bug#722429: ITP: osmctools -- Some tools to manipulate OpenStreetMap files
Package: wnpp Severity: wishlist Owner: Pierre Blanc * Package name: osmctools Version : 0.1 Upstream Author : Markus Weber * URL : http://gitorious.org/osm-c-tools/ * License : AGPL-3 Programming Lang: C Description : Some tools to manipulate OpenStreetMap files Small collection of basic OpenStreetMap tools, include converter, filter and updater files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130910211147.24634.75931.reportbug@orcus
using packages from sid on travis-ci.org
Some of the upstream projects I work on use travis-ci.org for continuous integration In some cases I'd like to configure builds that depend on packages from Debian unstable, but I'm not sure of the Ubuntu or travis way of doing that, has anybody dealt with this before? Or is there a Debian alternative? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522f8421.6060...@pocock.com.au
Re: Nitpicking in the NEW queue.
Hi Paul, Le Tue, Sep 03, 2013 at 09:12:42AM -0400, Paul Tagliamonte a écrit : > > README.Source would surely get my attention (as would README.Debian). Acutally, I do not know what is missing from README.Debian to justify the existence of this package. It runs a script each time a kernel package is installed or removed. I do not see which other package would be fit for these kernel hooks. We are going into circles: I still have no hint on what else I can do that I have not done before. I therefore re-uploaded with the following change. --- a/debian/copyright +++ b/debian/copyright @@ -1,6 +1,6 @@ Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ -Files: debian/update-grub +Files: * If this bug in the machine-readable file was the only blocker, it would have helped a lot to have marked it as such in your rejection message. Otherwise, a policy about small packages would have been helpful. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130911021016.gb30...@falafel.plessy.net
Re: Bug#722203: RFP: Kids' Media Player - an audio and video player designed especially for children
Control: reassign -1 wnpp Control: retitle -1 RFP: kmp -- Kid's Media Player - audio and video player designed especially for children Hi Michael, Have you considered packaging it yourself? You can ask for advice and look for a sponsor on http://lists.debian.org/debian-mentors Full quote below for the benefit of debian-devel. Kind regards, Andrei On Du, 08 sep 13, 21:16:57, Michael Staggs wrote: > Package: kmp > Severity: wishlist > > This is an audio and video player that uses pictures for navigation instead > of > text to give children the ability to select their own music and videos to > play > even before they're able to read. I coded it using Python and PyQT because I > gave my five year old daughter a linux box and there wasn't anything out > there > to fill this niche. > > It features album search by cover art, video search by thumbnail and plays > mp3s for audio and mov, mp4, mpeg and m4v videos. It plays the videos full > screen and allows pausing by hitting the spacebar or quitting the video by > hitting q. For audio, you can play and pause as well. In addition, when you > play a song, it searches the album info on wikipedia and, if you're old > enough > to read, you can click browser to read it. > > I tried to make it very simple and my daughter now uses it daily with no > problems. The Doudoulinux developers have expressed interest in putting the > kmp in their next major release, but I want to get it out to as wide an > audience as possible because there is nothing like it for children right now. > > It is released under GPLv3 and you can get the source tarball (as well as > screenshots) from the Qt-apps.org page: > http://qt-apps.org/content/show.php?action=content&content=160528 > > or the development code from google code: > http://code.google.com/p/kids-media-player/ > > You can see a video demo of it here: > http://www.youtube.com/watch?v=5s3ETtIGw7I > > I'd really appreciate it if someone could package this and it could be > included in Debian. -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#722445: ITP: skippy-xd -- A full-screen Expose-style standalone task switcher for X11.
Package: wnpp Severity: wishlist Owner: Martin Brambilla * Package name: skippy-xd Version : 0.5.1 Upstream Author : Martin Brambilla * URL : http://code.google.com/p/skippy-xd/ * License : GPL v2+ Programming Lang: C Description : A full-screen Expose-style standalone task switcher for X11. Skippy-XD is a full-screen task-switcher for X11. You know that thing Mac OS X, Compiz and KWin do where you press a hotkey and suddenly you see miniature versions of all your windows at once? Skippy-XD does just that. It's most commonly known by Mac OS X's name for it - Expose. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130911060501.2384.88128.report...@debian.tecso.coop
