Re: Proposal: enable stateless persistant network interface names
On 05/11/2015 05:53 AM, Marco d'Itri wrote: > On May 08, Martin Pitt wrote: > >> I propose to retire [mac], i. e. drop >> /lib/udev/rules.d/75-persistent-net-generator.rules and enable >> [ifnames] by default. > I see a large enough consensus about switching by default to ifnames, FWIW: I don't. In this very thread, I have read many counter-arguments. > and I believe that the few people who want MAC-based names for USB > interfaces can easily set NamePolicy=mac or write a custom rule. As always (and as it was for systemd), what counts here is the default. >> So we can only let time and replacing/reinstalling machines take care >> of this. /etc/udev/rules.d/70-persistent-net.rules requires zero >> maintenance from us (it's just like the admin had manually set their >> own rules). > Actually it requires us to keep maintaining the > Revert-udev-network-device-renaming patch as long as there will be > systems with a 70-persistent-net.rules file renaming eth* to eth*. The other solution would be to upstream that patch (maybe as a kernel option if that is relevant). > I believe that firmware-based device names work well enough in practice > since RHEL 7 uses them by default: I tend to trust a market-based > approach to maintenability more than anecdote from a very selected > population like the debian-devel@ subscribers. Oh, how nice is that... So our opinions don't count, and Red Hat is just always right! FYI, I had non-anecdotal very bad experience to report, with the ifnames from udev causing not-so-easy to fix issues deploying OpenStack on a variety of hardware. I'm talking about large deployments here (in my mind, large means more than 200 machines...). > This is the relevant documentation, which I strongly recommend everybody > interested in this issue to read: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html All from redhat. /me not surprised... > Maybe biosdevname would be nice to have, but: > - somebody needs to actually maintain it in Debian > - by default it only works on Dell systems > - it is not loved by the udev/systemd upstream maintainers > - it does not seem to me to provide any benefit over the firmware-based > names since in practice both would use by default an interface index > in the common case > > So I do not think that we need to care about it. > > An obvious downside is longer names for devices which do not provide > ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does > not (wlp2s0), but the Ethernet port does (eno1). > It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on > my Allwinner-based ARM computer), which means that interfaces will get > a mac-based name like enx028909xx. Which is so convenient to type on the shell, right? :) > But if somebody cares about the aesthetic value of network interface > names then they can probably write a custom udev rule to rename them, > or keep using 75-persistent-net-generator if we can keep it around. So your proposal is: if the default is unusable (like above), then the poor user has to find a way to fix that... I'm not convince that this is what we want. I'd very much prefer a usable default. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558d1507.1010...@debian.org
Re: Proposal v2: enable stateless persistant network interface names
On 25/06/15 23:14, Philipp Kern wrote: > On the other hand I'm more of a fan of actually naming > interfaces by their purpose or external labeling. Makes for even less > mental gymnastics. \-: You can still do this via manual configuration; as far as I understand it, nobody is proposing to take away the ability to rename interfaces to "lan" and "wan", or whatever, selected on the basis of path, MAC address, driver or any other udev attribute, via udev rules analogous to those written out by persistent-net-generator. However, in the absence of manual configuration, *something* needs to happen, one of: * the kernel defaults (eth0, ... in arbitrary order) * the current Debian-specific persistent-net-generator scheme * one of the various ifnames schemes * different ifnames schemes depending on device type (as implemented in systemd >= 220-5, which uses MAC-based IDs for USB and path-based for PCI) and there are some additional considerations that might not be obvious to some readers of this thread: * the default setup cannot use /var because that might be remote * the udev maintainers do not want the default to involve writing to /etc * each network device has exactly one name, and no aliases (kernel limitation) * renaming to ethN or wlanN, where N is a small integer, cannot work reliably regardless (because it can race with the kernel assigning the same ethN/wlanN name to different hardware; this is why ifnames never assigns names in that form) To some extent, all of this complexity is because network devices aren't device nodes in /dev, so they can't have aliases (symlinks) but must instead have precisely one name. udev has been able to introduce new disk naming schemes without breaking old ones, precisely because symlinks to disk device nodes work fine. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558d1729.2070...@debian.org
Re: Proposal: enable stateless persistant network interface names
On Jun 26, Thomas Goirand wrote: > > Actually it requires us to keep maintaining the > > Revert-udev-network-device-renaming patch as long as there will be > > systems with a 70-persistent-net.rules file renaming eth* to eth*. > The other solution would be to upstream that patch (maybe as a kernel > option if that is relevant). This cannot happen since the patch actually reverts an upstream change. > > I believe that firmware-based device names work well enough in practice > > since RHEL 7 uses them by default: I tend to trust a market-based > > approach to maintenability more than anecdote from a very selected > > population like the debian-devel@ subscribers. > Oh, how nice is that... So our opinions don't count, and Red Hat is just > always right! Opinions do not make a statistic, indeed. And you have not been paying attention, because right here I have expressed many times disagreement with some Red Hat decisions. > All from redhat. /me not surprised... Yes, at this point it is not a surprise that they produce good documentation and we do not. > So your proposal is: if the default is unusable (like above), then the > poor user has to find a way to fix that... I'm not convince that this is > what we want. I'd very much prefer a usable default. Me too, but there is none that we can use. -- ciao, Marco pgpisrqazVIXl.pgp Description: PGP signature
Re: Timezone name in Debian changelog format
On Fri, Jun 26, 2015 at 04:40:58AM +0200, Guillem Jover wrote: > So given that the timezone name has never been accepted, many > time-parsing functions ignore it, it is redundant, declared obsolete > by RFC5322 and Debian policy dropped an explicit reference to it due > to bug 569174. I'd say we should just drop it instead of fixing the > regex. Comments? Go ahead. As you have just shown, there are plenty of good reasons to drop it and little to keep it. [ I did a little experiment and could not find a single timezone name in my 18 years of changelogs ]. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150626085658.ga13...@cantor.unex.es
Bug#790030: ITP: jersey1 -- RESTful Web Services in Java
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: jersey1 Version : 1.19 Upstream Author : Oracle Corporation * URL : https://jersey.java.net * License : CDDL-1.1 or GPL-2 with Classpath exception Programming Lang: Java Description : RESTful Web Services in Java Jersey RESTful Web Services framework is the open source, production quality, framework for developing RESTful Web Services in Java that provides support for JAX-RS APIs and serves as a JAX-RS (JSR 311 & JSR 339) Reference Implementation. This library is a dependency of Apache Hadoop. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150626113044.14473.97414.report...@icare.ariane-software.com
Bug#790031: ITP: fcitx-zhuyin -- Fcitx wrapper for Zhuyin library
Package: wnpp Severity: wishlist Owner: IME Packaging Team * Package name: fcitx-zhuyin Version : 0~20150625 Upstream Author : CSSlayer * URL : https://github.com/fcitx/fcitx-zhuyin * License : GPL-2+ Programming Lang: C++ Description : Fcitx wrapper for Zhuyin library fcitx-zhuyin is a wrapper of Zhuyin IM engine for Fcitx. . The libzhuyin project aims to provide the algorithms core for intelligent sentence-based Chinese zhuyin input methods for Traditional Chinese user. -- ChangZhuo Chen (陳昌倬) http://czchen.info/ Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: Digital signature
Ihre Werbung auf Lochfolie
[Sollte diese E-Mail nicht richtig dargestellt werden, besuchen Sie hier die Webversion. ](http://p.n2g17.com/l/76375318/c/0-7b5b-9pe4ig-fso) (http://www.foliotex.n2g17.com/l/76375313/c/0-7b5b-9pe4ig-fso) Sehr geehrte Damen und Herren das Foliotex-Team freut sich Aktuelles zu verkünden: = Windowfolie (Lochfolie) === *DIE ideale Lösung für Ihr Werbeprojekt mit Durchblick.* == (http://www.foliotex.n2g17.com/l/76375314/c/0-7b5b-9pe4ig-fso) Preisbeispiel: == Heckscheiben-Werbung für kurz- bis mittelfristige Dauer in Lochfolie/Windowfolie ohne Laminat 130 x 50cm. - Digitaldruck ab druckfertigen angelieferten Daten - ab Fr.55.- == exkl. MwSt exkl. Datentransfer (pro Sujet Fr.45.-) Perforierte weisse glänzende Spezial-PVC-Folie mit schwarzer Rückseite für den Einsatz auf ebenen transparenten Untergrund aus Glas. Nach der Bedruckung der Folienvorderseite ergibt sich ein sichtbares Druckbild, wobei die perforierte schwarze Rückseite blickdurchlässig ist. Der Anteil der bedruckbaren Fläche an der Gesamtfläche beträgt 60%. Der geringe Lochdurchmesser von 1,5 mm ermöglicht ein vergleichsweise besonders feines Druckbild. Für kurz- und mittelfristige Werbegrafiken auf Fahrzeugen, Schaufenstern oder anderen ebenen transparenten Werbeträgern aus Glas, die rückseitig eine hohe Blickdurchlässigkeit aufweisen sollen. Da sich bei Außenanwendungen in der Perforierung Feuchtigkeit sammeln kann, die zu einer deutlichen Reduzierung der Blickdurchlässigkeit führt, muss die perforierte Folie nach dem Druck mit einem für diese Anwendung speziell entwickelten Schutzlaminat geschützt werden. *Aktionsdauer bis 31.August 2015* = (http://www.foliotex.n2g17.com/l/76375315/c/0-7b5b-9pe4ig-fso) - kompetente Beratung - familiärer Kleinbetrieb - speditive Abwiklung - faire Konditionen Foliotex GmbH in Bernhardzell SG Haben Sie einen Werbewunsch? Kommen Sie einfach vorbei oder schreiben sie uns. Vielfach haben wir die passende Werbeidee dazu. In unserer Werkstatt in Bernhardzell SG bekleben wir Ihr Fahrzeug, Ihre Werbetafel und Anderes direkt oder wir senden Ihnen die geplotteten oder gedruckten Werbeträger auch gerne zu Ihnen nach Hause, wo Sie es auch gerne (mit ein wenig Vorkenntnissen ) selber montieren können. Auf Wunsch kommen wir auch zu Ihnen nach Hause oder ins Geschäft; sehen uns mit Ihnen gemeinsam Ihre Werbewünsche vor Ort an und versuchen gemeinsam eine treffende Werbelösung zu finden. (http://www.foliotex.n2g17.com/l/76375316/c/0-7b5b-9pe4ig-fso) Foliotex GmbH St.Gallerstrasse 68 CH 9304 Bernhardzell Schweiz 071 420 09 31 [Newsletter abbestellen ](http://www.newsletter-abmeldung.n2g17.com/l/76375312/c/0-7b5b-9pe4ig-fso)
Re: GooString
With the Web based mailer, References could not be added. On Wed, Jun 24, 2015 at 08:11:25AM -0700, pe...@easthope.ca wrote: > GooString is referenced in pdftohtml.cc. What is its purpose > or purposes? From: Andrey Rahmatullin Date: Wed, 24 Jun 2015 21:11:27 +0500 > Wrong list? OK. What is the correct list for a question about cc code in Debian? Thanks,Peter E. -- Telephone 1 360 639 0202. Bcc: peter at easthope.ca "http://carnot.yi.org/ " -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/118d38c537e41490e077841d7cde5e7c.squir...@easthope.ca
Re: GooString
On Fri, 26 Jun 2015 08:57:25 -0700 "Peter Easthope" wrote: > With the Web based mailer, References could not be added. > > On Wed, Jun 24, 2015 at 08:11:25AM -0700, pe...@easthope.ca wrote: > > GooString is referenced in pdftohtml.cc. What is its purpose > > or purposes? > > From: Andrey Rahmatullin > Date: Wed, 24 Jun 2015 21:11:27 +0500 > > Wrong list? > > OK. What is the correct list for a question about cc > code in Debian? Whatever is the method of contacting the upstream of the package containing the cc file. That may turn out to be within Debian, most likely it will be somewhere else. You've already got the package details if you've got the cc file, so start there. It could be any one of these: http://codesearch.debian.net/results/GooString/page_0 Possibly this one: http://sources.debian.net/src/poppler/0.26.5-2/utils/pdftotext.cc/?hl=166#L166 That leads here: https://tracker.debian.org/pkg/poppler and then to http://poppler.freedesktop.org/, which leads to http://lists.freedesktop.org/mailman/listinfo/poppler -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp0NLU_8PFML.pgp Description: OpenPGP digital signature
Re: curl and certificate verification in jessie
It looks like nothing got done about this :-(. Is there any (GPL-compatible) TLS HTTP client library or tool in jessie which allows me to specify explicitly the expected End Entity certificate ? At the moment I'm using curl and wget. I was using --cacert=blah --capath=/dev/null and it did DTRT some time ago but now doesn't. In the meantime I'm going to have to make the whole thing rely on ca-certificates. The result is that our internal infrastructure (dgit in this case) is going to be (entirely needlessly) vulnerable to security failures in the X.509 CA cabal. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21901.57092.251321.252...@chiark.greenend.org.uk
GID collab-maint or scm_collab-maint on alioth git
Hi, I noticed that the alioth collab-maint repositories have GID collab-maint (older projects) scm_collab-maint (recent projects) depending on the project when a person complained to me that he can not accesss one with scm_collab-maint. drwxrwsr-x+ 7 osamu scm_collab-maint 4096 Jun 9 11:46 debmake-doc.git drwxrwsr-x+ 7 osamu collab-maint 4096 Sep 16 2013 debmake.git Are there any document for these group usages? What are the differences? Any differnces for people with -guest account? Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150627014629.GB13109@goofy.local
