Re: Updates in the very-old-stable
]] Osamu Aoki > We as DD have shell access to people.debian.org. Also many people have > shell access to alioth.debian.org. Both seems to have packages needed > to set up PPA like archive[1]. I think using any one of the following > tools should be good enough: Please don't encourage people to run package repositories on Alioth, in particular full-distro ones. It's not what it's for. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87hamud8qm@xoog.err.no
Re: bits from the DPL: December 2012
On Fri, Jan 04, 2013 at 05:31:46PM +0100, Stefano Zacchiroli wrote: > buildd usage for events like BSP. Many thanks to Lucas Nussbaum and Erm, typo here. This should have been "Many thanks to Lucas Nussbaum and James Bromberger". Sorry James! -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Architecture: all + M-A: foreign
Le Thu, Dec 06, 2012 at 02:05:13AM -0600, Peter Samuelson a écrit : > > In bug #695229, I noted that an Architecture: all package really should > be Multi-Arch: foreign. This led to an IRC discussion between Goswin, > Steve L. and me in which I formulated the proposal: > > If a package is 'Architecture: all', and all its dependencies are > 'Multi-Arch: foreign' (including the case where there are no > dependencies), this package should implicitly be treated as > 'Multi-Arch: foreign' as well. Hello everybody, have there been progresses on that question ? In light of the last messages in this thread, which suggest that more than 250 packages should be converted from architecture-independant to architecture-dependant in order to solve the problem, I wonder if it is useful to start adding 'Multi-Arch: foreign' to 'Architecture: all' packages. (I ask because it was suggested for mime-support in #695357) 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/20130106093218.gd13...@falafel.plessy.net
Re: Updates in the very-old-stable
On Sun, Jan 06, 2013 at 09:19:13AM +0100, Tollef Fog Heen wrote: > ]] Osamu Aoki > > > We as DD have shell access to people.debian.org. Also many people have > > shell access to alioth.debian.org. Both seems to have packages needed > > to set up PPA like archive[1]. I think using any one of the following > > tools should be good enough: > > Please don't encourage people to run package repositories on Alioth, in > particular full-distro ones. It's not what it's for. Good point. I was only thinking to create small low traffic experimental archives along what zak described and encouraged. I updated http://wiki.debian.org/HowToSetupADebianRepository accordingly. Osamu -- 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/20130106102249.GA28832@goofy.localdomain
Re: Architecture: all + M-A: foreign
+++ Charles Plessy [2013-01-06 18:32 +0900]: > Le Thu, Dec 06, 2012 at 02:05:13AM -0600, Peter Samuelson a écrit : > > > > In bug #695229, I noted that an Architecture: all package really should > > be Multi-Arch: foreign. This led to an IRC discussion between Goswin, > > Steve L. and me in which I formulated the proposal: > > > > If a package is 'Architecture: all', and all its dependencies are > > 'Multi-Arch: foreign' (including the case where there are no > > dependencies), this package should implicitly be treated as > > 'Multi-Arch: foreign' as well. > > Hello everybody, > > have there been progresses on that question ? > > In light of the last messages in this thread, which suggest that more than 250 > packages should be converted from architecture-independant to > architecture-dependant in order to solve the problem, I wonder if it is useful > to start adding 'Multi-Arch: foreign' to 'Architecture: all' packages. Yes it is. 695229 means that you won't _have_ to, but fixing the metadata in the package is always correct. > (I ask because it was suggested for mime-support in #695357) There are tens of these pending, upload away! Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/2013010612.gc5...@stoneboat.aleph1.co.uk
Bug#697505: ITP: ocaml-re -- regular expression library for OCaml
Package: wnpp Severity: wishlist Owner: Mehdi Dogguy * Package name: ocaml-re Version : 1.1.1 Upstream Author : Jerome Vouillon * URL : https://github.com/ocaml/ocaml-re * License : LGPL 2.1 Programming Lang: OCaml Description : regular expression library for OCaml RE is regular expression library for OCaml. The following styles of regular expressions are supported: - Perl-style regular expressions (module Re_perl); - Posix extended regular expressions (module Re_posix); - Emacs-style regular expressions (module Re_emacs); - Shell-style file globbing (module Re_glob). . It is also possible to build regular expressions by combining simpler regular expressions (module Re) -- Mehdi -- 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/20130106112435.3956.81540.reportbug@einsteinium
Bug#697509: ITP: qt5 -- cross-platform application and UI framework for developers using C++ or QML
Package: wnpp Severity: wishlist Owner: Fathi Boudra * Package name: qt5 Version : 5.0.0 Upstream Author : Digia Plc and/or its subsidiary(-ies) * URL : http://qt-project.org/ * License : LGPL-2.1 with Digia Qt LGPL Exception 1.1 or GPL-3 Programming Lang: C++ Description : cross-platform application and UI framework for developers using C++ or QML Qt is a cross-platform application and UI framework for developers using C++ or QML, a CSS & JavaScript like language. The Qt framework is composed of several modules: Qt Base, Qt Declarative, Qt Documentation, Qt Graphical, Qt Image Formats, Qt JavaScript backend, Qt Multimedia, Qt Quick, Qt Script, Qt SVG, Qt Tools, Qt WebKit, Qt XML Patterns, etc... This ITP intend to cover the complete Qt 5 framework, hence each module will close it. As usual, current packaging is available under Debian Qt/KDE team repositories: http://anonscm.debian.org/gitweb/?s=pkg-kde -- 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/20130106120042.11692.90958.reportbug@dc7700p
Re: Updates in the very-old-stable
On Sun, Jan 06, 2013 at 01:54:34PM +0800, Thomas Goirand wrote: > I agree on all what you said (eg: difficulties in doing such a maintenance, > the fact we don't have unlimited manpower, etc.), but I'm still convince it > would be worth a try. > > On 01/06/2013 04:39 AM, Neil Williams wrote: > > It's not about prohibiting updates, it's that most maintainers don't > > have time to support deprecated versions. > > How about allowing anyone to work on any package in very-old-stable? > > This might work at least for a few key packages, which some > users badly need. For example, I'd like to provide backports > for bind if it has a major hole. I disagree. It shouldn't not be some private repository in a dark corner of teh interwebs, it must be an official thing with a mandatory apt line during the installation. Too many people I otherwise respect use lenny (or etch!) on production network-facing servers, no matter how often I scream at them. And if they'll get rooted, there'll be stink about Debian's lack of security. The upgrade window is only 12 months, that's ridiculously short in many environments (corporate with its inertia, small setups where admins are starved for tuits). > It's probable that others will want to updates for apache, postfix, and > stuff like that as well. Ie, anything that is likely to be vulnerable remotely. > Anyone maintaining a large amount of servers will see value > in this (eg: better than nothing). I'd say admins with just one or two servers are more vulnerable, as they won't know about the issue in the first place. > The idea isn't to keep quality as high as we have for stable > or old-stable. The idea isn't to keep the same maintenance > rules either. It's about allowing what can be done to happen. It's impossible to maintain several tens of thousands of packages with the usual level of quality, yes. Doing that for several tens of packages can be done for a decade or two. Thus, I propose: what about adding such an empty repository to wheezy's apt sources NOW? In a few years, when wheezy becomes retired oldstable, there will be time to decide whether to use that repository or not. Or alternatively, you could revive lenny-security -- this has the upside of not adding new entities, and a downside of announcements being not as loud as a 404. -- How to squander your resources: those silly Swedes have a sauce named "hovmästarsås", the best thing ever to put on cheese, yet they waste it solely on mere salmon. -- 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/20130106130839.ga11...@angband.pl
Re: Updates in the very-old-stable
On 01/06/2013 02:32 PM, Osamu Aoki wrote: > > Sure. > > We as DD have shell access to people.debian.org. Also many people have > shell access to alioth.debian.org. Both seems to have packages needed > to set up PPA like archive[1]. I think using any one of the following > tools should be good enough: > * reprepro (support pool)[2] (I am thinking now to use this soonish) > * mini-dinstall[3] > * dpkg-scanpackages (I used to use it. Package: dpkg-dev)[4] The problem isn't setting-up a repository. That is trivial, and I already have a few which I manage for myself. The infrastructure problem is: - buildd so that we have more than a single arch - checking upload rights (eg: uploader key is in the keyring) Cheers, Thomas -- 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/50e97d44.7020...@debian.org
Re: Updates in the very-old-stable
On 01/06/2013 09:08 PM, Adam Borowski wrote: > > It shouldn't not be some private repository in a dark corner of teh > interwebs, it must be an official thing with a mandatory apt line during > the installation. I agree that would be the best thing to do, however it doesn't seem like it's going to happen right now. My point is to create a temporary repository to see if it's doable. Eg: does it get enough traction so that DDs upload security fixes. Also, that's unfortunately the only thing I can setup by myself, without the help of some DSA people. We can move to something more official later on. But I'll start doing something only if I get at least few positive reply to this thread, which I haven't yet... I don't intend to do that all by myself. > Too many people I otherwise respect use lenny (or etch!) on production > network-facing servers, no matter how often I scream at them. And if > they'll get rooted, there'll be stink about Debian's lack of security. > > The upgrade window is only 12 months, that's ridiculously short in many > environments (corporate with its inertia, small setups where admins are > starved for tuits). Exactly ! >> It's probable that others will want to updates for apache, postfix, and >> stuff like that as well. > Ie, anything that is likely to be vulnerable remotely. And also, anything that is likely to be a critical piece of software. Like, for example I wouldn't really care about game servers... > Thus, I propose: > what about adding such an empty repository to wheezy's apt sources NOW? In > a few years, when wheezy becomes retired oldstable, there will be time to > decide whether to use that repository or not. Or alternatively, you could > revive lenny-security -- this has the upside of not adding new entities, and > a downside of announcements being not as loud as a 404. Let's be realistic: this wont happen unless some key DDs reply positively to this thread (DSA, FTP-Masters, security team, etc.). Also, when the old-stable becomes obsolete, it goes to archive.debian.org. So you do get a 404 anyway. I don't see adding a new repository as a problem. It also forces users to know what they are doing. We can also choose a repository name explicitly expressing the fact it's not a full support like it used to be with old-stable. Thomas -- 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/50e980a4.8050...@debian.org
Bug#697520: ITP: pugixml -- Light weight C++ XML processing library
Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath
* Package name: pugixml
Version : 1.2
Upstream Author : Arseny Kapoulkine
* URL : http://pugixml.org/
* License : MIT/X
Programming Lang: C++
Description : Light-weight C++ XML processing library
pugixml is a lightweight C++ XML processing library with XPath
support. It features:
* DOM like interface with rich traversal/modification capabilities
* Extermely fast non-validating XML parser which constructs the DOM
tree from an XML file/buffer.
* XPath 1.0 implementation for complex data-driven tree queries
* Full Unicode support with Unicode interface variants and automatic
encoding conversions.
.
The library is extremely portable and easy to integrate and use.
.
Since pugixml has a DOM parser, it can't process XML documents that do
not fit in memory; also the parser is a non-validating one, so if you
need DTD or XML Schema validation, the library is not for you.
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
signature.asc
Description: Digital signature
Re: Updates in the very-old-stable
On Sun, Jan 06, 2013 at 09:48:20PM +0800, Thomas Goirand wrote: > On 01/06/2013 09:08 PM, Adam Borowski wrote: > > Ie, anything that is likely to be vulnerable remotely. > > And also, anything that is likely to be a critical piece of software. > Like, for example I wouldn't really care about game servers... While this shouldn't matter if you do it the right way (as in, if you do it so people who *do* care about that can upload), please remember that just because it doesn't have value for your job or business shouldn't necessarily mean it also has no value for someone else's business. In other words, please make sure that whatever set-up you do also supports things that are mostly similar in their requirements but somewhat different in their effects. If you find you're having to reject packages because, say, it'd stress the infrastructure too much or some such, you've lost. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20130106173219.gi13...@grep.be
Re: Updates in the very-old-stable
On 01/07/2013 01:32 AM, Wouter Verhelst wrote: > On Sun, Jan 06, 2013 at 09:48:20PM +0800, Thomas Goirand wrote: >> On 01/06/2013 09:08 PM, Adam Borowski wrote: >>> Ie, anything that is likely to be vulnerable remotely. >> And also, anything that is likely to be a critical piece of software. >> Like, for example I wouldn't really care about game servers... > While this shouldn't matter if you do it the right way (as in, if you do > it so people who *do* care about that can upload), please remember that > just because it doesn't have value for your job or business shouldn't > necessarily mean it also has no value for someone else's business. Yes, I do agree with the above. The only limit should be the amount of work time which everyone is ready to invest in. Which is why I wrote about *my* specific use case, implying that others might have other fields of interest. > In other words, please make sure that whatever set-up you do also > supports things that are mostly similar in their requirements but > somewhat different in their effects. I don't understand this sentence (sorry). > If you find you're having to reject > packages because, say, it'd stress the infrastructure too much or some > such, you've lost. So this poses the problem of having an efficient infrastructure. Which means buildd for all arch, mirrors, etc. Another idea that pops up. Obviously, if this starts somehow, it will be for when Squeeze is declared EOL, so that's in about a year of time. Probably we can have an open round table about this at next Debconf. Thomas -- 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/50e9c419.8030...@debian.org
Bug#697553: RFA: nqc -- Not Quite C compiler for LEGO Mindstorms RCX
Package: wnpp The LEGO Mindstorms RCX is a Hitachi microcontroller embedded into a LEGO brick. This package lets you write programs in a C-like language and download them to your RCX using the serial or USB infrared tower included with the RCX. I am seeking a new maintainer for this package because I no longer have access to the RCX hardware required to test it. I suspect that there are few potential maintainers for this package because of its low ranking in the Debian popularity-contest. -- 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/20130106212413.gb29...@blp.benpfaff.org
Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, Following the discussion to #695906, I propose the following solution to the problem. First of all, I'd like to remind that ifupdown supports source directive since very long ago (it was actually my very first patch to ifupdown to add that support), so anyone can split their network config into small chucks and place them under /etc/network/interfaces.d — it's not done by default, however, yet. The main problem mentioned by Tollef was, basically, that he couldn't disable lo interface configuration, which he needed for some reason, as ifupdown's postinst script was repairing the interfaces file. (Actually, creating an empty interfaces file would prevent it from doing so, as it only checks if the file exists, not if it's valid or not.) While there are various opinions on the question raised in that bug, I don't agree that this is a policy violation, but I propose to resolve this by enabling the usage of 'source' directive in the default configuration, and moving 'lo' interface description into /e/n/interfaces.d. Also, d-i would be now supposed to generate interfaces description in this directory as well, and the default interfaces file would consist of one line only from now: source /etc/network/interfaces.d/* (Please note that this 'source' doesn't recurse into subdirectories.) As /etc/network/interfaces.d/lo is now a conffile, it may be freely edited while being managed by dpkg. Of course, I could modify ifupdown to source these files automatically, but I'm not sure it's a very good idea to do that now. Same about making lo implicit and not requiring a declaration. Users upgrading the package from previous versions can have a warning reminding them that there's a new directory, so they may choose to change their configs; alternatively, we may try to migrate them automatically. I'd like to hear opinions on this idea. The current version of the patch is attached. -- WBR, Andrew From: Andrew Shadura Subject: Move loopback definition under /etc/network/interfaces.d, Date: Sun, 06 Jan 2013 20:27:13 +0100 Commit-Id: 534:9673a0084e119856fb5a0e81f9badfd69733c5e7 Move loopback definition under /etc/network/interfaces.d, which is now sourced from the default /etc/network/interfaces. Closes #695906. diff --git a/debian/dirs b/debian/dirs --- a/debian/dirs +++ b/debian/dirs @@ -8,3 +8,4 @@ etc/network/if-pre-up.d etc/network/if-up.d etc/network/if-down.d etc/network/if-post-down.d +etc/network/interfaces.d diff --git a/debian/ifupdown.interfaces.d.lo b/debian/ifupdown.interfaces.d.lo new file mode 100644 --- /dev/null +++ b/debian/ifupdown.interfaces.d.lo @@ -0,0 +1,4 @@ +# We should always have a loopback interface, or bad things may happen. + +auto lo +iface lo inet loopback diff --git a/debian/postinst b/debian/postinst --- a/debian/postinst +++ b/debian/postinst @@ -99,17 +99,26 @@ if [ "$1" = "configure" ] ; then if [ -f /etc/network/interfaces ] ; then # TODO: This should be handled with debconf and the script # could introduce the line there directly -if ! grep -q "^[[:space:]]*iface[[:space:]]\+lo0\?[[:space:]]\+inet[[:space:]]\+loopback\>" /etc/network/interfaces ; then - report_warn "No 'iface lo' definition found in /etc/network/interfaces" -fi -if ! grep -q "^[[:space:]]*\(allow-\|\)auto[[:space:]]\+\(.*[[:space:]]\+\|\)lo0\?\([[:space:]]\+\|$\)" /etc/network/interfaces ; then - report_warn "No 'auto lo' statement found in /etc/network/interfaces" +if ! ifquery --list | grep -q "^lo[0-9]*$" ; then +report_warn "No loopback interface definition is found, you may want to check you configuration, as it may break software badly." +if ! grep -q "^[[:space:]]*iface[[:space:]]\+lo0\?[[:space:]]\+inet[[:space:]]\+loopback\>" /etc/network/interfaces ; then +report_warn "No 'iface lo' definition found in /etc/network/interfaces." +fi +if ! grep -q "^[[:space:]]*\(allow-\|\)auto[[:space:]]\+\(.*[[:space:]]\+\|\)lo0\?\([[:space:]]\+\|$\)" /etc/network/interfaces ; then +report_warn "No 'auto lo' statement found in /etc/network/interfaces." +fi +if [ -d /etc/network/interfaces.d ] ; then +if grep -q "^[[:space:]]*iface[[:space:]]\+lo0\?[[:space:]]\+inet[[:space:]]\+loopback\>" /etc/network/interfaces.d/* ; then +files=$(grep "^[[:space:]]*iface[[:space:]]\+lo0\?[[:space:]]\+inet[[:space:]]\+loopback\>" /etc/network/interfaces.d/* | cut -d : -f 1) +report_warn "Loopback interface definition is found in the following files: $files.\nYou may want to include one of them in your /etc/network/interfaces file using 'source' directive. Read more in interfaces(5)." +fi +fi fi else # ! -f /etc/network/interfaces echo "Creating /etc/network/interfaces." echo "# interfaces(5) file used by ifup(8) and ifdown(8)" > /etc/network/interfaces -echo "auto lo" >> /etc/network/interfaces -echo "iface lo inet loopbac
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hi, On 06.01.2013 23:48, Andrew Shadura wrote: > First of all, I'd like to remind that ifupdown supports source > directive since very long ago (it was actually my very first patch to I've checked the squeeze version of ifupdown, and it doesn't seem to support that directive. So calling it supported "since very long" is probably a bit far fetched. It was complete news to me tbh. > ifupdown to add that support), so anyone can split their network config > into small chucks and place them under /etc/network/interfaces.d — it's > not done by default, however, yet. Please keep in mind that such a setup will break existing tools and scripts, which rely on finding the interface definitions in /e/n/i. E.g. the ifupdown plugin in NetworkManager doesn't know anything about such a source directive. If you are going to use such a interfaces.d/ directory this will break the NM integration. > I'd like to hear opinions on this idea. > > The current version of the patch is attached. Imho it is far too late in the release to consider such a change for wheezy as this has effects on d-i other tools in the archive (as shown above). 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
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, Andrew Shadura (06/01/2013): > While there are various opinions on the question raised in that bug, I > don't agree that this is a policy violation, but I propose to resolve > this by enabling the usage of 'source' directive in the default > configuration, and moving 'lo' interface description > into /e/n/interfaces.d. Also, d-i would be now supposed to generate > interfaces description in this directory as well, and the default > interfaces file would consist of one line only from now: > > source /etc/network/interfaces.d/* > > (Please note that this 'source' doesn't recurse into subdirectories.) NACK from me. We've been slowly progressing towards a situation where setting up the network mostly works (I think/hope/would like it to). I would very much hate changing anything in there if not for fixing bugs in setting up the network. Mraw, KiBi. signature.asc Description: Digital signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, On Mon, 07 Jan 2013 00:12:29 +0100 Michael Biebl wrote: > On 06.01.2013 23:48, Andrew Shadura wrote: > > First of all, I'd like to remind that ifupdown supports source > > directive since very long ago (it was actually my very first patch > > to > I've checked the squeeze version of ifupdown, and it doesn't seem to > support that directive. So calling it supported "since very long" is > probably a bit far fetched. > It was complete news to me tbh. Actually, it's supported for more than 1.5 years already, and the initial version of the patch has been available since 2.5 years ago. So yes, I call that very long ago — but I agree, it's not been in squeeze. And by the way, this has been annouced here. > > ifupdown to add that support), so anyone can split their network > > config into small chucks and place them > > under /etc/network/interfaces.d — it's not done by default, > > however, yet. > Please keep in mind that such a setup will break existing tools and > scripts, which rely on finding the interface definitions in /e/n/i. > E.g. the ifupdown plugin in NetworkManager doesn't know anything about > such a source directive. > If you are going to use such a interfaces.d/ directory this will break > the NM integration. Well, yes, I forgot about NM. Actually, as far as I know, it's the only tool affected, everything else either doesn't care to read /e/n/i, or is already fixed, or this difference is irrelevant and doesn't need to be urgently patched. Correct me if I'm wrong. > > I'd like to hear opinions on this idea. > > The current version of the patch is attached. > Imho it is far too late in the release to consider such a change for > wheezy as this has effects on d-i other tools in the archive (as shown > above). Okay, maybe you're right, as we still have NM unpatched, and it's too little time to patch and test it. So, just sourcing the directory by default shouldn't be enabled either, should it? -- WBR, Andrew signature.asc Description: PGP signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
On 07/01/2013 07:12, Michael Biebl wrote: > Please keep in mind that such a setup will break existing tools and > scripts, which rely on finding the interface definitions in /e/n/i. > E.g. the ifupdown plugin in NetworkManager doesn't know anything about > such a source directive. > If you are going to use such a interfaces.d/ directory this will break > the NM integration. Besides NetworkManager, what other existing tools and scripts are there that parse /e/n/i manually? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, On Mon, 07 Jan 2013 08:50:26 +0800 Chow Loong Jin wrote: > > Please keep in mind that such a setup will break existing tools and > > scripts, which rely on finding the interface definitions in /e/n/i. > > E.g. the ifupdown plugin in NetworkManager doesn't know anything > > about such a source directive. > > If you are going to use such a interfaces.d/ directory this will > > break the NM integration. > Besides NetworkManager, what other existing tools and scripts are > there that parse /e/n/i manually? As far as I know, guessnet (already fixed) and ifupdown's postinst (irrelevant), maybe something else, but I remember none of them at the moment. -- WBR, Andrew signature.asc Description: PGP signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Andrew Shadura (07/01/2013): > On Mon, 07 Jan 2013 08:50:26 +0800 > Chow Loong Jin wrote: > > > > Please keep in mind that such a setup will break existing tools and > > > scripts, which rely on finding the interface definitions in /e/n/i. > > > E.g. the ifupdown plugin in NetworkManager doesn't know anything > > > about such a source directive. > > > If you are going to use such a interfaces.d/ directory this will > > > break the NM integration. > > > Besides NetworkManager, what other existing tools and scripts are > > there that parse /e/n/i manually? > > As far as I know, guessnet (already fixed) and ifupdown's postinst > (irrelevant), maybe something else, but I remember none of them at the > moment. If you want to find out, try http://codesearch.debian.net/ Good candidates from a (very incomplete and too) quick look at it: busybox_1.20.0-7.dsc → static struct interfaces_file_t *read_interfaces(const char *filename) resolvconf_1.67.dsc → debian/config udev_175-7.dsc → extra/net.agent wireless-tools_30~pre9-8.dsc ifrename.c:const char DEBIAN_CONFIG_FILE[] ="/etc/network/interfaces"; ifrename.c:static inline void ifrename.c:probe_debian(intskfd) wpa_1.0-3.dsc → debian/ifupdown/functions.sh There are probably more of them, but finding them all is left as an exercise for the reader. Mraw, KiBi. signature.asc Description: Digital signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello,
On Mon, 07 Jan 2013 00:12:29 +0100
Michael Biebl wrote:
> > ifupdown to add that support), so anyone can split their network
> > config into small chucks and place them
> > under /etc/network/interfaces.d — it's not done by default,
> > however, yet.
> Please keep in mind that such a setup will break existing tools and
> scripts, which rely on finding the interface definitions in /e/n/i.
> E.g. the ifupdown plugin in NetworkManager doesn't know anything about
> such a source directive.
> If you are going to use such a interfaces.d/ directory this will break
> the NM integration.
If I understand the code correctly, the attached patch should do the
job. I haven't tried to compile it, however.
--
WBR, Andrew
--- a/src/settings/plugins/ifupdown/interface_parser.c
+++ b/src/settings/plugins/ifupdown/interface_parser.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "nm-utils.h"
if_block* first;
@@ -211,6 +212,25 @@
add_block(token[0], token[i]);
skip_to_block = 0;
}
+ else if (strcmp(token[0], "source") == 0) {
+ wordexp_t p;
+ char ** w;
+ size_t i;
+ const char * rest = join_values_with_spaces(value, token + 1);
+ int fail = wordexp(rest, &p, WRDE_NOCMD);
+ if (!fail)
+ {
+w = p.we_wordv;
+for (i = 0; i < p.we_wordc; i++)
+{
+ ifparser_init(w[i], quiet);
+}
+wordfree(&p);
+ } else {
+g_message ("Error: failed to match files using %s\n",
+ rest);
+}
+ }
else {
if (skip_to_block) {
if (!quiet) {
signature.asc
Description: PGP signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
On 07.01.2013 02:07, Cyril Brulebois wrote: > There are probably more of them, but finding them all is left as an > exercise for the reader. You can at least add network-admin from gnome-system-tools to the list, or external config tools like webmin. Not counting any local scripts written by sysadmins. I'd be very cautious with such a change. We should be really certain that the benefits are worth the cost. 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
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
Hello, On Mon, 07 Jan 2013 02:31:30 +0100 Michael Biebl wrote: > > There are probably more of them, but finding them all is left as an > > exercise for the reader. > You can at least add network-admin from gnome-system-tools to the > list, or external config tools like webmin. > Not counting any local scripts written by sysadmins. For most of the cases direct parsing of /e/n/i isn't required, for the most of those cases when it's needed, there's now ifquery. So usually if some script parses /e/n/i or writes to it, something is already seriously wrong, with few exceptions. > I'd be very cautious with such a change. We should be really certain > that the benefits are worth the cost. They are. I agree that there may be not enough time. -- WBR, Andrew signature.asc Description: PGP signature
Bug#697270: PC 32-bit programs fails to work on amd64
On Fri, 2013-01-04 at 13:03 +, Colin Watson wrote: > On Thu, Jan 03, 2013 at 06:59:49PM +, Ben Hutchings wrote: > > dpkg --add-architecture i386 > > apt-get update > > > > The installer doesn't AFAIK provide even the option to do this. (The > > i386/amd64 installer images might at least be usable as multiarch APT > > sources though.) So this is a usability regression in wheezy. > > I don't think I got round to updating apt-setup for the new > --add-architecture scheme; but the apt-setup/multiarch template does > exist and I think that at this point it would count as a bug-fix to make > it work properly. Given that, you could at least boot the installer > with apt-setup/multiarch=i386. Yes, please. > I think that apt-setup/multiarch=i386 should be the default on amd64; > but I'm less sure that I could convince anyone that that deserves a > freeze exception. I'm convinced, but I don't count. :-) Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
[Andrew Shadura] > Well, yes, I forgot about NM. Actually, as far as I know, it's the only > tool affected, everything else either doesn't care to read /e/n/i, or > is already fixed, or this difference is irrelevant and doesn't need to > be urgently patched. Correct me if I'm wrong. You are wrong. Debian Edu also expect /etc/network/interfaces to have the complete network setup. -- Happy hacking Petter Reinholdtsen -- 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/2fltxqtbm6y@login2.uio.no
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
On 07/01/2013 13:23, Petter Reinholdtsen wrote: > You are wrong. Debian Edu also expect /etc/network/interfaces to have > the complete network setup. What package is that? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
]] Andrew Shadura > I'd like to hear opinions on this idea. I think you should just get a wheezy-ignore tag from the release team and solve this properly for jessie. Also, your fix doesn't actually solve the RC bug either: You Must Preserve All Admin Changes in /etc. Not just the ones you think is sensible or reasonable. Why not just report that the file is missing and leave it to the admin to fix (on upgrades, feel free to create it on the initial installation)? After all, if they have removed it, they probably know how to bring it back. My suggestion would be to, over the jessie cycle, deprecate (but still read) /etc/network/interfaces and for jessie+1 just drop the file and only use the .d directory. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87pq1hbfrj@xoog.err.no
