Re: debconf as a registry
On Fri, Oct 17, 2014 at 12:37:27PM +0800, Thomas Goirand wrote:
> On 10/17/2014 04:34 AM, Bas Wijnen wrote:
> > So debconf needs to read configuration files, but it doesn't know how to
> > parse them. So it does the only thing it can: it uses its cache. Which
> > means that each and every package that uses debconf must make sure that
> > they read the configuration files and update debconf's cache _before_
> > running debconf. And most of them don't do that.
>
> Could you name a few package for which this is the case? Has bugs been
> opened for them?
I have not reported any bugs, because there is no solution that I
consider acceptable yet. Any package with a config script that does not
include db_set and that writes the result of db_get to a config file (in
postinst) is broken. But, as I found, strictly speaking they are not
always violating policy.
Getting random packages from apt-cache rdepends debconf shows:
- several packages that use debconf for questions that are only about
actions that don't need to be (and aren't) stored in config files.
- cxref uses ucf in postinst. This doesn't violate policy, but does (in
case of local changes) give the wrong default in the debconf question,
and an annoying "do you want to overwrite local changes?" after
answering the question. If the default would have been correct, there
would have been no need for that.
- esmtp starts by asking if you want to overwrite your config and
refuses to be configured by debconf if you don't. Also
policy-compliant, but very unfriendly to users.
- dict does it right. This costs it more than 20 lines of code in the
config script.
- dvi2ps does something I don't understand... It asks questions but
never runs db_get. Presumably it pre-seeds some other package?
- ibam depends on debconf but doesn't seem to ask any questions; it
doesn't even have a config or postinst script.
- gpm does it right, in surprisingly few lines.
- grr does it wrong.
This tiny investigation shows that most of the packages that handle
configuration files are either doing it in a way that is not
user-friendly, or that uses significant code in the config script. Both
of those cases would benefit from taking that code out of the source (if
it was there) and replacing it with an include statement.
> > The above problems are solved by my plan to create a "static script
> > library", which is included in config scripts at package build time.
> > This library would define functions for parsing common config file
> > formats, and can be included in config scripts with a line similar to
> > ##DEBHELPER##. This has the benefit of solving the problem, without
> > causing the problem of adding lots of duplicate code to the soures.
>
> Then such a library *must* be marked as essential, and installed by
> default, otherwise it would break the install workflow.
No; it's a _static_ library. It is included in the config script at
package build time. This means every binary package using it will have
a copy of the code in its maintainerscript. But the source packages do
not. A change in the library requires a rebuild of all the packages for
the change to take effect. That's not ideal, but better than marking it
as essential, or making it part of debconf (which would also work, but
requires Joey Hess to accept it, and so far he refuses to even
acknowledge that there is a problem; even if he would, I find making it
a separate package a more elegant solution).
> > Oh yes, and I have some code ready for feedback. I haven't written the
> > script libraries yet (and I want others to write some of them), but I
> > have written the debhelper module for using them. I have set up a
> > mini-dinstall repository where you can get the binary and source
> > packages:
> > deb [arch=all,amd64] http://wijnen.dtdns.net/archive unstable main
> > deb-src http://wijnen.dtdns.net/archive unstable main
> > (Please ignore problems with the keys; I'm still getting it to work
> > right.)
> >
> > The code is derived from dh-autoreconf and it is the first ever perl
> > program I wrote. So please don't insult me, but also don't hold back
> > when you see things that need to be improved. :-)
>
> Ok, you have a repository. But which package should we look into?
Oops, sorry and thanks for the reminder. It's dh-parseconfig:
http://wijnen.dtdns.net/archive/unstable/{all,source}/dh-parseconfig*
> As for parsing files, I don't think using perl is a great idea.
The perl script only pastes the file into the config script. The actual
parsing is done by a script in the language that config is written in.
That means there must be an implementation for every language (/bin/sh
being the most important) and every common file type (ini and csv
probably being the most important).
Note that none of those parsing libraries have been written yet. I'll
probably take some code from pioneers as a starting point.
I intend most libraries to be included in the dh-parseconfig sou
Re: debconf as a registry
On Fri, Oct 17, 2014 at 12:37 PM, Thomas Goirand wrote: > maintenance of them, like for example moving a directive from one > section to another (when this happens upstream). Sounds like you want one of these: Config::Model based config file upgrades: https://wiki.debian.org/PackageConfigUpgrade Elektra based config file upgrades: https://wiki.debian.org/SummerOfCode2014/Projects/Improve%20Configuration%20Upgrade%20Mechansim%20with%20Elektra -- bye, pabs https://wiki.debian.org/PaulWise -- 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/caktje6egpmrfqjlzt_sx6yzffxykc2tuew3hgdngy8eztb6...@mail.gmail.com
Re: debconf as a registry
On 10/17/2014 04:34 AM, Bas Wijnen wrote: > So debconf needs to read configuration files, but it doesn't know how to > parse them. So it does the only thing it can: it uses its cache. Which > means that each and every package that uses debconf must make sure that > they read the configuration files and update debconf's cache _before_ > running debconf. And most of them don't do that. Could you name a few package for which this is the case? Has bugs been opened for them? > The above problems are solved by my plan to create a "static script > library", which is included in config scripts at package build time. > This library would define functions for parsing common config file > formats, and can be included in config scripts with a line similar to > ##DEBHELPER##. This has the benefit of solving the problem, without > causing the problem of adding lots of duplicate code to the soures. Then such a library *must* be marked as essential, and installed by default, otherwise it would break the install workflow. > Oh yes, and I have some code ready for feedback. I haven't written the > script libraries yet (and I want others to write some of them), but I > have written the debhelper module for using them. I have set up a > mini-dinstall repository where you can get the binary and source > packages: > deb [arch=all,amd64] http://wijnen.dtdns.net/archive unstable main > deb-src http://wijnen.dtdns.net/archive unstable main > (Please ignore problems with the keys; I'm still getting it to work > right.) > > The code is derived from dh-autoreconf and it is the first ever perl > program I wrote. So please don't insult me, but also don't hold back > when you see things that need to be improved. :-) > > Thanks, > Bas Ok, you have a repository. But which package should we look into? As for parsing files, I don't think using perl is a great idea. Such configuration files sometimes may be huge. But anyway. I have a list of features that such a library would need to do for .ini files. This would include not only reading and writing to .ini files, but also allow maintenance of them, like for example moving a directive from one section to another (when this happens upstream). 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/54409d07.4080...@debian.org
Bug#765656: ITP: libmarc-transform-perl -- Perl module to transform a MARC record with a yaml configuration file
Package: wnpp Severity: wishlist Owner: Robin Sheat * Package name: libmarc-transform-perl Version : 0.003005 Upstream Author : Stéphane Delaune * URL : https://metacpan.org/release/MARC-Transform * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to transform a MARC record with a yaml configuration file MARC::Transform transforms a MARC record using a YAML configuration file. It allows you to create, update, delete, and duplicate fields and subfields of a record. You can also use scripts and lookup tables. You can specify conditions to execute these actions. All conditions, actions, functions and lookup tables are defined by YAML. -- 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/20141017024957.13526.88527.report...@debmaker32.wgtn.cat-it.co.nz
Work-needing packages report for Oct 17, 2014
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 611 (new: 3) Total number of packages offered up for adoption: 141 (new: 3) Total number of packages requested help for: 58 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: fstrcmp (#765334), orphaned 2 days ago Description: fuzzy comparison of strings Reverse Depends: fstrcmp libfstrcmp-dev libfstrcmp0-dbg Installations reported by Popcon: 27 lcdf-typetools (#765323), orphaned 2 days ago Description: Programs to manipulate OpenType, multiple-master, and Type 1 Reverse Depends: open-font-design-toolkit texlive-full Installations reported by Popcon: 3569 libexplain (#765335), orphaned 2 days ago Description: utility to explain system call errors Reverse Depends: explain libexplain-dev libexplain30-dbg libexplain51-dbg tardy Installations reported by Popcon: 42 608 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: adns (#765629), offered today Description: Asynchronous-capable DNS client library and utilities Reverse Depends: adns-tools apachetop libadns1-dev python-adns sauce tetrinetx Installations reported by Popcon: 3575 splash (#764684), offered 6 days ago Description: Visualisation tool for Smoothed Particle Hydrodynamics simulation Installations reported by Popcon: 1 t1utils (#765322), offered 2 days ago Description: Collection of simple Type 1 font manipulation programs Reverse Depends: lintian mftrace texlive-full Installations reported by Popcon: 14086 138 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1718 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay packagesearch Installations reported by Popcon: 77655 athcool (#278442), requested 3642 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 45 awstats (#755797), requested 85 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4161 balsa (#642906), requested 1117 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 750 cardstories (#624100), requested 1270 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 14 chromium-browser (#583826), requested 1600 days ago Description: Chromium browser Reverse Depends: chromedriver chromium-dbg chromium-l10n mozplugger Installations reported by Popcon: 25864 cups (#532097), requested 1958 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-core-drivers (63 more omitted) Installations reported by Popcon: 143067 debtags (#567954), requested 1718 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2274 developers-reference (#759995), requested 47 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 15098 fbcat (#565156), requested 1737 days ago Description: framebuffer grabber Installations reported by Popcon: 164 freeipmi (#628062), requested 1239 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools libfreeipmi-dev libfreeipmi16 libipmiconsole-dev libipmiconsole2 libipmidetect-dev (4 more omitted) Installations reported by Popcon: 5693 gnat-gps (#496905), requested 2240 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 508 gnokii (#677750), requested 852 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6
Bug#765646: ITP: libconvert-basen-perl -- encoding and decoding of base{2, 4, 8, 16, 32, 64} strings
Package: wnpp
Severity: wishlist
Owner: Robin Sheat
* Package name: libconvert-basen-perl
Version : 0.01
Upstream Author : Dan Kogai
* URL : https://metacpan.org/release/Convert-BaseN
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : encoding and decoding of base{2,4,8,16,32,64} strings
Convert::BaseN makes it easy to deal with various data encoding formats,
such as base2, base4, ..., base64. In addition, it allows the format of
the encoding to be configured, for example by supplying custom character
maps.
--
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/20141016215242.3503.93171.report...@debmaker32.wgtn.cat-it.co.nz
Re: piece of mind (Re: Moderated posts?)
On Thu, Oct 16, 2014 at 3:02 AM, Martin Read wrote: > On 15/10/14 23:01, Adam Borowski wrote: >> >> shim doesn't appear to work, at least for me. To get basic functionality >> like shutdown from GUI, suspend or mounting USB drives, I needed to >> downgrade the whole Utopia stack to their last working versions. > > > Out of interest, what's the bug number? 757348 (merged with 754850, 758746) 757698 747821 760281 759745 (assigned to gdm3 currently) and possibly 741698 (assigned to lightdm currently, IIRC) I think most of these bugs have been fixed with the recent releases of cgmanager and systemd-shim, just waiting for maintainers to verify and close them. (as well as for those version to make it to testing in a week or so) Cheers, -- Cameron Norman -- 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/CALZWFR+WjXfRV4Hi7EQ=43=p9rtmgors+odtvjyan8vo9jh...@mail.gmail.com
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hi Bas, On Thu, Oct 16, 2014 at 08:27:37PM +0200, Bas Wijnen wrote: > Ok. Is it supposed to be possible to install more than one blend > simultaneously? Is that technically prevented with Conflicts? Not at all. I have not tested but I would bet that you can install all existing metapackages of all Blends at the same time. Conflicts do not make any sense to the contrary it makes sense to install say med-bio and science-typesetting at the same time (just to say a random example). > > ... as always with documentation. :-) The same applies to me to some > > extend (and I'm not proud about this). > > No, I'm not proud of it either. But as Feynman said: "you [yourself] > are the easiest person to fool." So I take some pride in admitting it; > telling myself otherwise would have been easier. ;-) :-) Kind regards Andreas. -- http://fam-tille.de -- 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/20141016203751.gd30...@an3as.eu
Re: debconf as a registry
As I wrote in the blend thread, reading through bug #311188 raised some new questions for me about this one. I will start by explaining the original problem again; it seemed to me that it wasn't understood by everyone. Then I'll add some new thoughts based on that bug. Finally, I present some code to solve the problem, on which I welcome feedback. = Explanation of the problem = Policy says (10.7.3): local changes must be preserved during a package upgrade However, configuration is stored in two places: in the configuration files in /etc, and in debconf's "configuration space" (which I'll call debconf's cache). The expected way that things work is: - On package install, a debconf question is asked and the answer is stored in debconf's cache. - Later during the same install, the cached value is copied into the configuration file by postinst. The problem appears on upgrade: debconf will again be called, and the question is whether or not to ask a question, and if so, what the default answer should be. And if not, what the value in the cache should be after not asking the question. That latter question is easily answered: it must have the same value that would have been the default if the question was asked. For the default answer there are three options: - The default that was supplied by the package. This is obviously wrong, it must only be used if there is no other data. - The value from debconf's cache. - The value from the configuration file. Since debconf's cache is a cache, not a registry, the latter is the correct answer. Debconf's cache MUST BE IGNORED if there is a configuration file. In practice it often doesn't matter, because the values are identical. But when they aren't, the admin has made local changes and they must be preserved. So debconf needs to read configuration files, but it doesn't know how to parse them. So it does the only thing it can: it uses its cache. Which means that each and every package that uses debconf must make sure that they read the configuration files and update debconf's cache _before_ running debconf. And most of them don't do that. (It also involves a significant amount of nontrivial code, which we really shouldn't want to see duplicated in every debconf-using package.) In fact, the debconf specification[0] even suggests that using debconf's cache is perfectly fine. The paragraph on "The configuration space" explains how two packages that share a configuration value can use the same value in the cache. But the important thing is that they should share a configuration file (as described in policy 10.7.4). While sharing a cache key is a good idea, because it avoids a duplicate question if both packages are installed simultaneously (both config scripts are run before both postinst scripts, so the shared configuration file is not updated when the second config script runs), that is really a minor issue. In the quote below my text, Russ agrees that all the packages are buggy, but he doesn't address the issue of how those bugs should be fixed. IMO telling all those maintainers to copy a significant piece of code into their config script is a bad idea. [0] https://www.debian.org/doc/packaging-manuals/debconf_specification.html which is linked from policy 3.9.1. = New thoughts inspired by #311188 = This bug is about debian-edu which needs to configure the system for its users. Because it wants to be a Pure Blend, it uses packages from the official archive. That's very nice. However, those packages all have their own ways of storing their configuration. So debian-edu has a similar problem as debconf: it cannot change the configuration of the packages in a policy-compliant way. Debconf doesn't know how to edit the files; debian-edu does know (because it uses code that is targeting specific files), but isn't allowed to do it. The solution would be for every package that debian-edu wants to configure to either add debconf questions which can be preseeded, or to add update-* scripts to allow those configuration files to be shared. If debconf is used properly, as described above, preseeding the cache should only work while the configuration file doesn't exist yet (otherwise the cache is overwritten before it is used). For this purpose, I consider that a feature, not a bug (because it means the admin can trust that the system doesn't decide to change things seemingly at random). However, regardless of which option is chosen, the packages require significant code to make them work. On the bright side, the result of that work is that they can be configured with debconf, which means it improves the quality of Debian. = Conclusion = The above problems are solved by my plan to create a "static script library", which is included in config scripts at package build time. This library would define functions for parsing common config file formats, and can be included in config scripts wi
Migration from cron to cron-daemon?
Hi! I sent the attached message to debian-release, but I was told to ask in debian-devel. So here is the mail. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | --- Begin Message --- Hi! Is there currently a migration from „cron” to „cron-daemon” as virtual package? New packages like brcon-run don’t provide cron anymore but cron-daemon. And many packages like exim4-base or mgetty-fax haven’t changed their dependencies (and other packages their recommends). Some packages have already bug reports for this case. But shouldn’t this be a reason for a mass bug filling? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature --- End Message --- smime.p7s Description: S/MIME cryptographic signature
Re: apt-get install sysvinit-core removes gnome?
On Thu, 2014-10-16 at 20:36 +0200, Bas Wijnen wrote:
> On Thu, Oct 16, 2014 at 05:35:09PM +0100, Martin Read wrote:
> > mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
> > Aptitude::ProblemResolver {
> > SolutionCost "priority, removals, canceled-actions";
> > }
>
> That looks very useful, thanks!
How to configure apt pinning? Just for the record (to be published
where?) (or does this apply to apt too, not only aptitude?)
--
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/1413485223.27347.17.ca...@g3620.my.own.domain
Re: apt-get install sysvinit-core removes gnome?
On Thu, Oct 16, 2014 at 05:35:09PM +0100, Martin Read wrote:
> mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
> Aptitude::ProblemResolver {
> SolutionCost "priority, removals, canceled-actions";
> }
That looks very useful, thanks!
Bas
signature.asc
Description: Digital signature
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Hello, On Thu, Oct 16, 2014 at 08:47:19AM +0200, Andreas Tille wrote: > > Would this use case also be a reason for creating a personal blend? Or > > even an official one? > > Jonas has answered this question. I'd like to add that I'm no fan of > "personal" things since you spoil the idea of forming a team around the > idea. Yes, I agree. However, sometimes the needs are so specific that it doesn't make sense to do them on a larger scale. I'd make the packages public, but I wouldn't suggest that a blend for very limited use deserves a prominent position in the installer. But as Jonas pointed out, if the blend only does the setup for running a single application and any application can be chosen at install time, that increases the audience to a point where it may deserve that position. I'll consider if I want to drive that effort. I'd really like to see this happen, but I'm also trying to limit new projects I start, so that I have enough time to handle the things I do properly. If more people (besides Jonas) are interested, please let me know privately. If you want to be the driver, definitely let me know, too. :-) I'll send a status update by the end of the month. > Well, these are good questions. They are abit hard to answer in a > situation when we are discussing about how to properly install the > currently existing Blends. Indeed. Someone should remember to bring them back up once that question has been answered (and the answer has been implemented). > > So it installs a package which changes configuration of other packages > > when it is installed? That sounds very ugly... Isn't there a better > > way to preconfigure a system? > > Yes. The better way is to convince the single package maintainers. The > longish discussion is in bug #311188. Reading that raises questions regarding the configuration editing tool I wrote about some time ago. I'll follow up to that thread (on -devel only). > > Oh, and I have another question; this seems very similar to "tasks"; how > > is it different? > > Each Blend creates metapackages and a -tasks package to feed > tasksel. Yes, we are using this term actively. The difference is more > in the content that the tasks are specific for fields of interest but > the used technique is the same (which is intentional to enable > integration into the installer easily). Ok. Is it supposed to be possible to install more than one blend simultaneously? Is that technically prevented with Conflicts? > > > Enhancements / patches(source is in package source of blends source > > > package) are always welcome. > > > > I might write a patch, but knowing myself I probably don't get around to > > actually do that. > > ... as always with documentation. :-) The same applies to me to some > extend (and I'm not proud about this). No, I'm not proud of it either. But as Feynman said: "you [yourself] are the easiest person to fool." So I take some pride in admitting it; telling myself otherwise would have been easier. ;-) Thanks, Bas signature.asc Description: Digital signature
Bug#765629: RFA: adns -- Asynchronous-capable DNS client library and utilities
Package: wnpp Severity: normal Hi, I request an adopter for the adns package. The package description is: adns is a resolver library for C (and C++) programs. In contrast with the existing interfaces, gethostbyname et al and libresolv, it can be used in an asynchronous, non-blocking manner. Many queries can be handled simultaneously. . Includes useful test tools and utilities for IP address resolving in logfiles. -- Robert Edmonds edmo...@debian.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/20141016182207.ga8...@mycre.ws
Re: Determining, ad hoc, whether someone is a DD
2014-10-15 15:02 Ian Jackson: Many of our lookup interfaces don't give out a clear indication of the status of the person you are looking up. Eg db.debian.org contains DMs and DDs and the public lookup doesn't distinguish. www.debian.org/devel/people lists maintainers, DMs and DDs without distinction. (This is contrary to the information on https://wiki.debian.org/DebianDeveloper.) AFAICT there are two ways right now to find out whether someone is a DD from primary sources[1]: [...] Not a primary source, but perhaps this is of some use, it is in general a nice overview and easy to lookup by name or username. In particular, it is very clear to see the status of the people. Results in the left can be filtered by clicking in e.g. "Debian Developer, uploading"; and clicking on name/username gives more detailed info for the people. https://nm.debian.org/public/people -- Manuel A. Fernandez Montecelo -- 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/20141016170333.ga2...@reva.itsari.org
Re: apt-get install sysvinit-core removes gnome?
On 16/10/14 12:20, Matthias Urlichs wrote:
Apitude, too, *really* likes to choose 500 deletions rather than upgrading
even a single package to a version with slightly-lower priority (as defined
in /etc/apt/pref*), but at least you can tell it to try harder. :-/
I got sick of "remove half the planet" being the first suggested option,
so added a configuration fragment to /etc/apt/apt.conf.d that gets a
behaviour I find more reasonable:
mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
Aptitude::ProblemResolver {
SolutionCost "priority, removals, canceled-actions";
}
mormegil@cocytus:~$
(Yes, the choice of filename does reflect a certain amount of...
*grouchiness* on my part regarding the default behaviour of the aptitude
interactive dependency resolver. This is a home system; if I was writing
this up as a general-purpose article I'd give it a less loaded name.)
--
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/543ff3bd.1020...@zen.co.uk
Bug#765603: ITP: r-bioc-s4vectors -- BioConductor S4 implementation of vectors and lists
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-s4vectors Version : 0.4.0 Upstream Author : Bioconductor Package Maintainer * URL : http://bioconductor.org/packages/release/bioc/html/S4Vectors.html * License : Artistic-2.0 Programming Lang: GNU R Description : BioConductor S4 implementation of vectors and lists The S4Vectors package defines the Vector and List virtual classes and a set of generic functions that extend the semantic of ordinary vectors and lists in R. Package developers can easily implement vector-like or list-like objects as concrete subclasses of Vector or List. In addition, a few low-level concrete subclasses of general interest (e.g. DataFrame, Rle, and Hits) are implemented in the S4Vectors package itself (many more are implemented in the IRanges package and in other Bioconductor infrastructure packages). Remark: BioConductor 3.0 has new dependencies and this is one basic package. It is maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-s4vectors/trunk/ -- 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/20141016141254.27981.14554.report...@mail.an3as.eu
Re: bash exorcism experiment ('bug' 762923 & 763012)
On Oct 16, Thorsten Glaser wrote:
> > | If one of the members of the tech ctte considers that we should
> > | either overwrite the udev-maintainer or move printf to /bin, we
> The coreutils maintainer may still decide to do just that.
> That’s what would help the most.
In a few years, when /{bin,sbin,lib}/ will be folded in /usr/, this will
be meaningless anyway.
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: piece of mind (Re: Moderated posts?)
[ answered on -user only ] -- 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/20141016125024.gc17...@smurf.noris.de
Re: piece of mind (Re: Moderated posts?)
On Mon, Oct 13, 2014 at 10:29:11AM +0200, Matthias Urlichs wrote: > Hi, > > lee: > > I'm sure we could find quite a few supporters for having a GR amongst > > the users (here). > > We don't do a GR among our users. We do that among Debian > members/maintainers/developers/take-your-pick. > > Of those, most … > * are perfectly happy with the TC's decision > * can live with it > * are unhappy, but think that to continue discussing this is way worse > than biting the bullet and getting on with actual work > * you do know that we plan to release Jessie sometime this decade, > right? > * are disillusioned about it all and decided to stand aside ^^^ I am that. I dont like the systemd approach - i have lived 20 years in a different linux ecosystem - i had loads of trouble with the last thing of lennart so thanks - Evolution instead of revolution. > > Judging by the last couple of months, the rest appears to number <6 people. * Have not yet bitten by the systemd issue. Honestly i have not installed a new debian release in the past until months after the release. With a couple of hundret systems to admin you are not hurrying for the next release. So the masses of users have not yet even heard of systemd, nor have experienced it. So my guess is that the big uproar from the sysadmins comes 3-6 Month after release. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: Built-Using, again…
On 2014-10-16 10:23, Jonathan Dowland wrote: The mails to the @buildd addresses are of course private to those behind the list, so the peanut gallery on -devel can't see what tg wrote nor judge for ourselves whether it was whiny or not, but characterising it as such here is not helpful. TG's mail to -devel, at least, was polite, and I was sad to see passive aggressive responses from you and others. For some value of "of course": buildd.debian.org:/srv/buildd.debian.org/mbox has DD-readable mboxes for the arch aliases. (Not wb-team, because that's private and contains security requests.) But I know that it's not greatly documented. Kind regards Philipp Kern -- 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/215d81dc44adb5836c535ed77d1c0...@hub.kern.lc
Re: Built-Using, again…
On 2014-10-16 10:10, Andreas Barth wrote: Wrong again, I dist-upgraded the chroots and gave back the package. But as before, facts are difficult. FWIW, you did not update neither the d-d nor the buildd.d.o thread about that. Which means that the other people think that it's still open. Kind regards Philipp Kern -- 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/f1c905175f45b5ba82414287a8e9c...@hub.kern.lc
Re: bash exorcism experiment ('bug' 762923 & 763012)
On Thu, 16 Oct 2014, Ian Jackson wrote: > | If one of the members of the tech ctte considers that we should > | either overwrite the udev-maintainer or move printf to /bin, we The coreutils maintainer may still decide to do just that. That’s what would help the most. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general -- 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/alpine.deb.2.11.1410161422290.5...@tglase.lan.tarent.de
Re: bash exorcism experiment ('bug' 762923 & 763012)
Thorsten Glaser writes ("Re: bash exorcism experiment ('bug' 762923 & 763012)"):
> I’d rather prefer to see this resolved by getting #428189 fixed.
Clearly you would, but #428189 (moving coreutils printf to /bin) was
also implicitly rejected by the TC in its decision on #539158. The
question of whether to move printf to /bin was raised in that
conversation, and rejected:
As Andreas wrote here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539158#15
| If one of the members of the tech ctte considers that we should
| either overwrite the udev-maintainer or move printf to /bin, we
| should draft another resolution text for that.
> Fixing #428189 would avoid pulling printf into the list of builtins
> and not violate the #539158 decision.
So I think #428189 ought to be closed.
If you disagree about the meaning of the TC decision in #539158 then
the TC should clarify it.
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/21567.45486.215252.540...@chiark.greenend.org.uk
Re: Bug#765512: general: distrust old crypto algos and protocols perdefault
Lars Wirzenius writes ("Re: Bug#765512: general: distrust old crypto algos and
protocols perdefault"):
> Merely defending one's opinions is a recipe for long threads. A good,
> productive discussion about Debian development requires understanding
> other people's arguments, evaluating one's own point of view, and
> adapting it to produce an improved synthesis position, and iterating
> this a few times to end up with a consensus of an accurate mental
> model of reality and a realistic plan of action, which can be worked
> on, preferably by named people, who agree to it. Such a discussion
> benefits greatly from empathy, sympathy, good will, and the lack of a
> conviction that one is right.
We should frame that. Thanks, Lars.
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/21567.44981.266587.833...@chiark.greenend.org.uk
Re: apt-get install sysvinit-core removes gnome?
Hi, Florian Lohoff: > is it intentional that gnome is removed when systemd is replaced by > sysvinit-core? Please always retry this kind of thing with aptitude, and try to let it choose alternate resolutions to the dependency chains. Apitude, too, *really* likes to choose 500 deletions rather than upgrading even a single package to a version with slightly-lower priority (as defined in /etc/apt/pref*), but at least you can tell it to try harder. :-/ -- -- Matthias Urlichs -- 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/20141016112053.ga17...@smurf.noris.de
Re: apt-get install sysvinit-core removes gnome?
On Thu, Oct 16, 2014 at 12:47:41PM +0200, Dominik George wrote: > Hi, > > >but it seems there is some dependency in jessie which makes gnome > >unavailable > >without systemd. > > It is there because upstream requires it. There is no GNOME without systemd. > This is not specific to Debian. *örgs* Because i - aehm - cant set an icon for my system via hostnamed or something? I still wait to wake up to let this bad dream of systemd go past me. This can only be a bad dream ... Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: apt-get install sysvinit-core removes gnome?
On 16/10/14 12:47, Dominik George wrote: > Hi, > >> but it seems there is some dependency in jessie which makes gnome >> unavailable >> without systemd. > > It is there because upstream requires it. There is no GNOME without systemd. > This is not specific to Debian. No, that's wrong. $ sudo aptitude install sysvinit-core The following NEW packages will be installed: sysvinit-core 0 packages upgraded, 1 newly installed, 0 to remove and 204 not upgraded. Need to get 130 kB of archives. After unpacking 253 kB will be used. The following packages have unmet dependencies: systemd-sysv : Conflicts: sysvinit-core but 2.88dsf-53.4 is to be installed. Internal error: found 2 (choice -> promotion) mappings for a single choice. Internal error: found 2 (choice -> promotion) mappings for a single choice. The following actions will resolve these dependencies: Remove the following packages: 1) aptdaemon 2) brasero 3) colord 4) gdm3 5) gnome-control-center 6) gnome-disk-utility 7) gnome-session 8) gnome-settings-daemon 9) gnome-shell 10) gnome-shell-dbg 11) gvfs 12) gvfs-backends 13) gvfs-daemons 14) gvfs-dbg 15) gvfs-fuse 16) hplip 17) libpam-systemd 18) nautilus 19) nautilus-sendto 20) network-manager 21) network-manager-gnome 22) packagekit 23) packagekit-tools 24) policykit-1 25) policykit-1-gnome 26) printer-driver-postscript-hp 27) steadyflow 28) systemd-sysv 29) udisks2 Leave the following dependencies unresolved: 30) python-aptdaemon recommends aptdaemon 31) python3-aptdaemon recommends aptdaemon 32) libcolord2 recommends colord 33) libcolord-gtk1 recommends colord 34) cups recommends colord 35) cups-daemon recommends colord 36) cups-filters recommends colord 37) empathy recommends gvfs-backends 38) evince recommends gvfs 39) file-roller recommends gvfs 40) gnome-calculator recommends gvfs 41) gnome-control-center-data recommends gnome-control-center (>= 1:3.14.0-1) 42) gnome-media recommends gnome-control-center 43) gnome-online-accounts recommends gnome-control-center (>= 3.6.1) 44) gnome-session-bin recommends libpam-systemd 45) gnome-shell recommends gnome-control-center 46) gnome-system-monitor recommends gvfs 47) gnome-terminal recommends gvfs 48) gvfs-common recommends gvfs
Re: apt-get install sysvinit-core removes gnome?
Hi, >but it seems there is some dependency in jessie which makes gnome >unavailable >without systemd. It is there because upstream requires it. There is no GNOME without systemd. This is not specific to Debian. -nik -- 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/09e6843b-eb29-4082-8868-d9617b053...@naturalnet.de
Re: piece of mind (Re: Moderated posts?)
On 15/10/14 23:01, Adam Borowski wrote: shim doesn't appear to work, at least for me. To get basic functionality like shutdown from GUI, suspend or mounting USB drives, I needed to downgrade the whole Utopia stack to their last working versions. Out of interest, what's the bug number? -- 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/543f97a6.9050...@zen.co.uk
apt-get install sysvinit-core removes gnome?
Hi, is it intentional that gnome is removed when systemd is replaced by sysvinit-core? an apt-get install sysvinit-core sysvinit-utils on a fresh jessie removed most of the gnome desktop. I dont want systemd and i'd like to remove as much of the blob as possible. I thought systemd-shim + sysvinit-core/utils would be enough to make a usable system but it seems there is some dependency in jessie which makes gnome unavailable without systemd. Am i wrong? Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: Bug#765512: marked as done (general: distrust old crypto algos and protocols perdefault)
Hi Christoph, thanks for closing this bug again! :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Quoting Andreas Tille (2014-10-16 08:47:19) > On Wed, Oct 15, 2014 at 07:49:32PM +0200, Bas Wijnen wrote: >> On occasion, I've needed a single-use system; something that boots up >> into an application and that shuts down when that application exits. >> (Having the full power of Debian in the background is a nice feature, >> but mostly unused.) For example, for dancing rehearsal I want the >> instructors to be able to switch their computer on and have the sound >> program start up without any interaction. It isn't hard to set this >> up, but if I want to tell other dancing instructors how to do this, >> it requires more steps than I would like. I've tried making custom >> live CDs, with a special package that does these things. >> >> Would this use case also be a reason for creating a personal blend? >> Or even an official one? > > Jonas has answered this question. I'd like to add that I'm no fan of > "personal" things since you spoil the idea of forming a team around > the idea. I could perfectly imagine such a Blend and every specific > application is a separate "task" (in the Blends slang). So you can > assemble those people with the goal to run one dedicated application. And I fully agree with Andreas: I assumed you were talking about "Debian Blends" as defined at https://wiki.debian.org/DebianPureBlends#Terminology and that you therefore really a generally reusable Blend (sparked by personal _needs_ which I see as a perfectly fine drive for creating a Debian Blend). I am sorry if I twisted your meaning. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: bash exorcism experiment ('bug' 762923 & 763012)
On Wed, 2014-10-15 at 23:36 +0100, Ian Jackson wrote: > Actually, the problem is indeed in policy. In its resolution of > #539158 the TC decided unanimously (but unfortunately slightly > implicitly) that printf ought to be provided by our /bin/sh. > > Unfortunately the policy has not been properly clarified. This leaves > us in the somewhat unsatisfactory situation where our real > compatibility requirement is de facto rather than de jure. > > As the maintainer of a minority shell, Thorsten has the most interest > in regularising this. Perhaps Thorsten would like to propose a > suitable policy wording (with a view to changing posh to match). > > Obviously that wording ought to be consistent with the TC's decision > in #539158 - ie, it should specify printf as a builtin. The arguments about printf in #539158 also applies to '['. POSIX does not say '[' must be a built in (in POSIX's terminology is part of the 'Special Built-In Utilities'). Thus if the shell didn't implement '[' udev would fail since uses [ and sets PATH to be /bin:/sbin. The reality is in a POSIX (or a minimal Policy 10.4) world shell scripts must have access to bulk of the stuff that is both covered in the man1p pages and is required in Debian. Turns out only three commands fall into that category: [, printf, and test. And yes, to me the obvious fix is say in policy /bin/sh have those commands as builtins. signature.asc Description: This is a digitally signed message part
Re: Built-Using, again…
On Thu, 16 Oct 2014, Jonathan Dowland wrote: > > > But it’s now resolved, thanks Philipp! > > > > Wrong again, I dist-upgraded the chroots and gave back the package. > > But as before, facts are difficult. > > Likewise, you could have pointed this out without being quite so condecending. Uhm yes. Philipp wrote back about the issue being fixed. Thanks Andreas for doing the work, I did not know about that particular detail. Anyway, fixed is good, back to work. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- 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/alpine.deb.2.11.1410161025350.5...@tglase.lan.tarent.de
Re: Built-Using, again…
On Thu, Oct 16, 2014 at 10:10:46AM +0200, Andreas Barth wrote: > You didn't ask a wider audience, you whined to one, and that on > something totally unrelated to the thing you really wanted. The mails to the @buildd addresses are of course private to those behind the list, so the peanut gallery on -devel can't see what tg wrote nor judge for ourselves whether it was whiny or not, but characterising it as such here is not helpful. TG's mail to -devel, at least, was polite, and I was sad to see passive aggressive responses from you and others. > > But it’s now resolved, thanks Philipp! > > Wrong again, I dist-upgraded the chroots and gave back the package. > But as before, facts are difficult. Likewise, you could have pointed this out without being quite so condecending. -- Jonathan Dowland -- 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/20141016082322.ga13...@chew.redmars.org
Re: Built-Using, again…
* Thorsten Glaser (t.gla...@tarent.de) [141016 09:39]: > On Wed, 15 Oct 2014, Andreas Barth wrote: > > > Buildd administration — @buildd.debian.org > > lists a couple of people. And also a working mail address. Contacting > > people via a role account is always prefered. > > Yeah, that’s whom I contacted first, on Friday. It was just not > getting any sort of response or action there which made me ask > with a wider audience. You didn't ask a wider audience, you whined to one, and that on something totally unrelated to the thing you really wanted. The right thing to do would be "I asked about this and that, and nothing happened". So please refer to my mail "sending smart mails". Would you have asked "I asked for a dist-upgrade, and nothing happend" that would have made it more easier. And I'm not sure if 3 days are not too short to escalate to d-d, but that's a different question. I'd really encourage you to write in the mails what you want. If you want a dist-upgrade, then please write "can you please dist-upgrade the ppc chroots because ... failed, and give the package back"? And not start whining and hide what you want at the very end of the mail. If you started the mails to d-d with a subject showing what you want, like "powerpc buildds: how to get the chroots upgraded", I would have probably done that immediatly. So I put it as "some functionality discussion" aside. > But it’s now resolved, thanks Philipp! Wrong again, I dist-upgraded the chroots and gave back the package. But as before, facts are difficult. Andi -- 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/20141016081046.gu20...@mails.so.argh.org
Re: Bug#765512: general: distrust old crypto algos and protocols perdefault
On Wed, 15 Oct 2014, Christoph Anton Mitterer wrote: > I see it a bit differently: > RC4 is broken. Full stop. > Therefore new versions clients and servers should per default not > use/enable/accept it. Sorry, but I *have* to nitpick here. RC4 as used by SSL is mostly broken. (A server could reset login cookies to be invalid after, say, 65536 pageloads, so that the attack cannot be mounted. This would allow the use of RC4 in SSL for compatibility/interoperability.) RC4 as used by arc4random is not broken, because arc4random (at least the more sane implementations) have one or several changes in effect that prevent the issues from RC4 becoming abused. RC4 as used by WEP is broken. I think this cannot be phrased differently, either. RC4 as used by Kerberos has been described to you already. RC4 (aRC4) is just a stream cipher with some bad properties, that can, mostly, be worked around in the protocol. But if the protocol does not do that, it’s broken, yes. bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"... -- 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/alpine.deb.2.11.1410160946270.5...@tglase.lan.tarent.de
Re: bash exorcism experiment ('bug' 762923 & 763012)
On Wed, 15 Oct 2014, Ian Jackson wrote: > Actually, the problem is indeed in policy. In its resolution of > #539158 the TC decided unanimously (but unfortunately slightly > implicitly) that printf ought to be provided by our /bin/sh. Somewhat. > As the maintainer of a minority shell, Thorsten has the most interest > in regularising this. Perhaps Thorsten would like to propose a > suitable policy wording (with a view to changing posh to match). I’d rather prefer to see this resolved by getting #428189 fixed. Michael, can you please comment on that bug, as coreutils maintainer? > Obviously that wording ought to be consistent with the TC's decision > in #539158 - ie, it should specify printf as a builtin. Fixing #428189 would avoid pulling printf into the list of builtins and not violate the #539158 decision. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- 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/alpine.deb.2.11.1410160941230.5...@tglase.lan.tarent.de
Bug#765557: ITP: jenkins-antisamy-markup-formatter-plugin -- OWASP Markup Formatter Plugin for Jenkins
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: jenkins-antisamy-markup-formatter-plugin Version : 1.2 Upstream Author : Kohsuke Kawaguchi * URL : https://github.com/jenkinsci/antisamy-markup-formatter-plugin * License : MIT Programming Lang: Java Description : OWASP Markup Formatter Plugin for Jenkins Jenkins plugin using policy definitions to allow limited HTML markup in user-submitted text. This is one of the core plugins bundled with Jenkins. -- 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/543f749d.1010...@apache.org
Re: Built-Using, again…
On Wed, 15 Oct 2014, Andreas Barth wrote: > Buildd administration — @buildd.debian.org > lists a couple of people. And also a working mail address. Contacting > people via a role account is always prefered. Yeah, that’s whom I contacted first, on Friday. It was just not getting any sort of response or action there which made me ask with a wider audience. But it’s now resolved, thanks Philipp! bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-) -- 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/alpine.deb.2.11.1410160937320.5...@tglase.lan.tarent.de
