Re: problem install new package
On Sun, Mar 10, 2013 at 12:45:00PM +0100, Alfonso Sabato Siciliano wrote: So I have uncopressed beret_1.2.1-1_amd64.deb and in beret_1.2.1-1_amd64/DEBIAN/control there is: Depends: beret-data (= 1.2.1-1), libc6-amd64 (= 2.2.5), libsdl-image1.2 (= 1.2.10), libsdl-mixer1.2, libsdl-ttf2.0-0, libsdl1.2debian (= 1.2.11) libc6-amd64 (= 2.2.5): this version is incorrect! I have installed 2.13-38. Do you do something strange while building the software? Can you publish the package anywhere? -- WBR, wRAR signature.asc Description: Digital signature
Runtime directories: in package or by scripts?
I'm creating packages with programs which use some directories for persistent data. E. g. dladm will use /etc/dladm to save data in. What is the best way to ship such a diretory: in package (d/foo.dirs) or create in postinst script? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALL-Q8zY7EUbeBqncMOD1=zoabvvrz-j9ypqu6e832zfx4h...@mail.gmail.com
Re: Runtime directories: in package or by scripts?
On Sun, Mar 10, 2013 at 04:24:52PM +0400, Игорь Пашев wrote: I'm creating packages with programs which use some directories for persistent data. E. g. dladm will use /etc/dladm to save data in. The proper path is /var/lib/dladm. What is the best way to ship such a diretory: in package (d/foo.dirs) or create in postinst script? Why postinst? -- WBR, wRAR signature.asc Description: Digital signature
Re: problem install new package
Hi,
Alfonso Sabato Siciliano alfi...@gmail.com writes:
if I run: # dpkg -i beret_1.2.1-1_amd64.deb
[...]
beret depends on libc6-amd64 (= 2.2.5).
libc6-amd64 is a i386 package providing an 64bit libc. For some reason
the ${shlibs:Depends} picks this as a dependency instead of the native
libc6 package.
This seems to be a bug (or missing mutliarch feature) in dpkg: it
probably should not use *.shlibs files from packages that do not match
the target architecture.
As a workaround, you could try removing libc6-amd64 when building the
package.
Ansgar
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4jnh1kj@eisei.43-1.org
Re: Runtime directories: in package or by scripts?
2013/3/10 Andrey Rahmatullin w...@wrar.name: On Sun, Mar 10, 2013 at 04:24:52PM +0400, Игорь Пашев wrote: I'm creating packages with programs which use some directories for persistent data. E. g. dladm will use /etc/dladm to save data in. The proper path is /var/lib/dladm. Sorry, I was not accurate. It is system vital data needed for early boot: http://illumos.org/man/1M/dladm What is the best way to ship such a diretory: in package (d/foo.dirs) or create in postinst script? Why postinst? Because on removal there will be a message cannot remove directory, if there are file in that directory. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8wj+s7c5pq+xx4ctl5dccztujbye-ffnzhn+ntqz1f...@mail.gmail.com
Re: Runtime directories: in package or by scripts?
On Sun, Mar 10, 2013 at 04:47:42PM +0400, Игорь Пашев wrote: What is the best way to ship such a diretory: in package (d/foo.dirs) or create in postinst script? Why postinst? Because on removal there will be a message cannot remove directory, if there are file in that directory. Purge them too. -- WBR, wRAR signature.asc Description: Digital signature
Re: Bug#702072: RFS: tilda/1.1.4-1 [ITA]
Hi Anton, thanks for reviewing my package. I have added a new branch tilda-debian-1-1 to my github repository and put the debian/ folder in there, more comments below: On 02/03/13 16:19, Anton Gladky wrote: Hi Sebastian, thanks for working on this package. I think it is ok to switch to a fork as the original software is not developed any more. Some notes/questions on your package: 1) Remove changelog.new. 2) Use VCS for maintaining the package and uncomment corresponding lines in control-file. 3) Current Standards-version is 3.9.4 4) Convert copyright-file to a DEP-5 format, who is copyright-holder after 2008? DONE 5) What is debian/rules.small? If it works, why do you keep an old version? If you plan to use the current debian/rules, it should be cleaned also, using override_dh-commands. I forgot to remove that, debian/rules is the correct one. 6) Lintian's complaining on hardening should be investigated, not just simply overridden. I did investigate, and decided its save to ignore the warnings. Is there anything that would indicate its not? 7) tilda.dirs, seems, useless. Its not, the package doesnt build without the tilda.dirs file. 8) Clean watch-file. It should be 3-lines long. DONE 9) Your package fails to build: cp -f /usr/share/misc/config.sub config.sub cp -f /usr/share/misc/config.guess config.guess dh_autoreconf Can't exec autopoint: No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 345. autoreconf: failed to run autopoint: No such file or directory autoreconf: autopoint is needed because this package uses Gettext dh_autoreconf: autoreconf -f -i returned exit code 1 make: *** [config.status] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 = Added autopoint as build dependency, now it should work. But when I run pbuilder --build to build it inside a debian chroot, then I still get some configure errors. I have to assume that some build dependencies are missing, but I really dont know how to fix that since I dont get any warnings. I have no real idea what pbuilder is doing inside the chroot and how i can reproduce that. If you could help fixing this that would be great. 10) Do you really need debian/source/options? No, removed it. Cheers, Anton Thanks Lanoxx On 03/02/2013 02:23 PM, Lanoxx wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package tilda * Package name: tilda Version : 1.1.4-1 Upstream Author : Sebastian Geiger lan...@gmx.net * URL : https://github.com/lanoxx/tilda * License : GPL-2 Section : x11 It builds those binary packages: tilda - Gtk based drop down terminal for Linux and Unix To access further information about this package, please visit the following URL: http://mentors.debian.net/package/tilda Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/tilda/tilda_1.1.4-1.dsc More information about tilda can be obtained from https://github.com/lanoxx/tilda. I have already spawned a discussion about switching to a new upstream location and becoming new maintainer at this bug #695574 [1]. Please also see bug #583248 [2], which states that the current maintainer is MIA since 2010-05-26. Note that I'm targeting unstable not experimental, because I believe that given the amount of bugs my package fixes makes this package more stable than the one which is currently in unstable. Changes since the last upload: tilda (1.1.4-1) unstable; urgency=low * New upstream release (Closes: #695574, #692904) * Added a watch file (Closes: #501739) * Use x-www-browser as default (Closes: #552505) * Use word characters setting, thanks to Liu Yubao yubao@gmail.com (Closes: #506855) * Remove deprecated dpatch and upgrade to packaging format 3.0 quilt and update to Standards-Version to 3.9.3 and debhelper to 9, thanks to Jari Aalto jari.aa...@cante.net (Closes: #664358) * New maintainer (Sebastian Geiger), thanks to Davide Truffa for his previous work (Closes: #583248) * Update tilda.desktop file to be compatible with freedesktop.org, thanks to Jekyll Wu (Closes: #678129) -- Sebastian Geiger lan...@gmx.net Sat, 23 Feb 2013 12:06:09 +0100 Regards, Sebastian Geiger [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695574 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583248 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513c9d59.7080...@gmx.net
Re: Bug#702072: RFS: tilda/1.1.4-1 [ITA]
Hi Sebastian, On 03/10/2013 03:48 PM, Lanoxx wrote: Added autopoint as build dependency, now it should work. But when I run pbuilder --build to build it inside a debian chroot, then I still get some configure errors. I have to assume that some build dependencies are missing, but I really dont know how to fix that since I dont get any warnings. I have no real idea what pbuilder is doing inside the chroot and how i can reproduce that. If you could help fixing this that would be great. It is really a problem. If your package cannot build inside clean build-environment, it will unlikely be built on Debian-buildservers. You should really investigate that. As you are an upstream-author of the project, I would recommend you to migrate to a cmake-buildsystem. Looking into a your Makefile, it should not be difficult. Debian/rules are still looking like a mess. Please, clean it. Anton signature.asc Description: OpenPGP digital signature
Depending on a -bin package built from the same source version
Hi list,
I'm working on packages for a SW [1,2] that has a main GUI application
(written in Tcl/Tk) and a set of command line programs that are called
from the main GUI app.
I decided to split the program in two packages, polsarpro and
polsarpro-bin, and of course the main one (polsarpro) depends on
polsarpro-bin.
The question is how to specify the the dependency.
The GUI app have to depend from binaries built from the same source code
(not previous of later versions).
For what I can understand the correct approach should be the one
described in [3,4], something like
Depends: polsarpro-bin (= ${source:Version}),
polsarpro-bin ( ${source:Version}.1~)
but the cme tool (provided by [5]) keeps on complaining about it:
$ cme check dpkg-control
Reading package lists... Done
Building dependency tree
Reading state information... Done
Connecting to qa.debian.org to check polsarpro-bin versions. Please wait...
Warning in 'binary:polsarpro Depends:1' value 'polsarpro-bin (=
${source:Version})': package polsarpro-bin is unknown. Check for typos
if not a virtual package.
Warning in 'binary:polsarpro Depends:2' value 'polsarpro-bin (
${source:Version}.1~)': package polsarpro-bin is unknown. Check for
typos if not a virtual package.
Configuration item 'binary:polsarpro Depends:2' has a wrong value:
dependency 'polsarpro-bin ( ${source:Version}.1~)' does not match
grammar
Should I care about it?
Is there a better solution to address the specific problem?
[1] Vcs-Git: git://git.debian.org/git/pkg-grass/polsarpro.git
[2] Vcs-Browser: http://git.debian.org/?p=pkg-grass/polsarpro.git
[3] http://lintian.debian.org/tags/not-binnmuable-all-depends-any.html
[4] http://lintian.debian.org/tags/weak-library-dev-dependency.html
[5] http://packages.qa.debian.org/libc/libconfig-model-perl.html
thanks
--
Antonio Valentino
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/513cc767.9010...@tiscali.it
Re: Depending on a -bin package built from the same source version
Hi,
On 10/03/13 18:48, Antonio Valentino wrote:
The question is how to specify the the dependency.
The GUI app have to depend from binaries built from the same source code
(not previous of later versions).
For what I can understand the correct approach should be the one
described in [3,4], something like
Depends: polsarpro-bin (= ${source:Version}),
polsarpro-bin ( ${source:Version}.1~)
but the cme tool (provided by [5]) keeps on complaining about it:
$ cme check dpkg-control
Reading package lists... Done
Building dependency tree
Reading state information... Done
Connecting to qa.debian.org to check polsarpro-bin versions. Please wait...
Warning in 'binary:polsarpro Depends:1' value 'polsarpro-bin (=
${source:Version})': package polsarpro-bin is unknown. Check for typos
if not a virtual package.
Warning in 'binary:polsarpro Depends:2' value 'polsarpro-bin (
${source:Version}.1~)': package polsarpro-bin is unknown. Check for
typos if not a virtual package.
Configuration item 'binary:polsarpro Depends:2' has a wrong value:
dependency 'polsarpro-bin ( ${source:Version}.1~)' does not match grammar
Should I care about it?
Not about the unknownness of the package as you're currently packaging it.
But about the wrong version value: you can't combine a placeholder and
other characters.
Is there a better solution to address the specific problem?
Yes, simply depend on version equality:
Depends: polsarpro-bin (= ${source:Version})
Remark: you might want to check [1] if a binary:Version placeholder
wouldn't be a better choice.
Cheers, Eric
[1] http://wiki.debian.org/binNMU
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/513cd070.4080...@zorglub.s.bawue.de
Re: Depending on a -bin package built from the same source version
On 2013-03-10 19:26 +0100, Eric Lavarde wrote:
On 10/03/13 18:48, Antonio Valentino wrote:
Configuration item 'binary:polsarpro Depends:2' has a wrong value:
dependency 'polsarpro-bin ( ${source:Version}.1~)' does not match grammar
Should I care about it?
Not about the unknownness of the package as you're currently packaging it.
But about the wrong version value: you can't combine a placeholder and
other characters.
Why not?
Is there a better solution to address the specific problem?
Yes, simply depend on version equality:
Depends: polsarpro-bin (= ${source:Version})
Remark: you might want to check [1] if a binary:Version placeholder
wouldn't be a better choice.
Assuming that polsarpro is Arch:all and polsarpro-bin is Arch:any, which
seems to be the case here, neither of these options works.
A valid possibility would be to reverse the roles and dependencies:
rename polsarpro to polsarpro-data and polsarpro-bin to polsarpro, then
polsarpro can depend on polsarpro-data (= ${source:Version}).
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4jnytbf@turtle.gmx.de
Re: Depending on a -bin package built from the same source version
Hi Sven, hi Eric,
Il 10/03/2013 19:59, Sven Joachim ha scritto:
On 2013-03-10 19:26 +0100, Eric Lavarde wrote:
On 10/03/13 18:48, Antonio Valentino wrote:
Configuration item 'binary:polsarpro Depends:2' has a wrong value:
dependency 'polsarpro-bin ( ${source:Version}.1~)' does not match grammar
Should I care about it?
Not about the unknownness of the package as you're currently packaging it.
But about the wrong version value: you can't combine a placeholder and
other characters.
Why not?
Is it possible that cme is complaining about that.
Is it a cme bug?
Is there a better solution to address the specific problem?
Yes, simply depend on version equality:
Depends: polsarpro-bin (= ${source:Version})
Remark: you might want to check [1] if a binary:Version placeholder
wouldn't be a better choice.
Assuming that polsarpro is Arch:all and polsarpro-bin is Arch:any, which
seems to be the case here, neither of these options works.
A valid possibility would be to reverse the roles and dependencies:
rename polsarpro to polsarpro-data and polsarpro-bin to polsarpro, then
polsarpro can depend on polsarpro-data (= ${source:Version}).
Cheers,
Sven
yes I could use polsarpro-data or polsarpro-gui but the problem remains.
The GUI is written in Tcl/Tk and is arch: all and it must depend form
the package containing command line programs that is arch: any.
Without command line programs the GUI can't perform any useful task.
regards
--
Antonio Valentino
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/513cdc50.6000...@tiscali.it
Re: Depending on a -bin package built from the same source version
Hi,
On 10/03/13 20:17, Antonio Valentino wrote:
Hi Sven, hi Eric,
Il 10/03/2013 19:59, Sven Joachim ha scritto:
On 2013-03-10 19:26 +0100, Eric Lavarde wrote:
On 10/03/13 18:48, Antonio Valentino wrote:
Configuration item 'binary:polsarpro Depends:2' has a wrong value:
dependency 'polsarpro-bin ( ${source:Version}.1~)' does not match
grammar
Should I care about it?
Not about the unknownness of the package as you're currently
packaging it.
But about the wrong version value: you can't combine a placeholder and
other characters.
Why not?
Is it possible that cme is complaining about that.
Is it a cme bug?
Reading again some doc, placeholder and other characters should be
allowed, but it could be indeed that cme is more restrictive (perhaps
add a zero after the tilde?).
Is there a better solution to address the specific problem?
Yes, simply depend on version equality:
Depends: polsarpro-bin (= ${source:Version})
Remark: you might want to check [1] if a binary:Version placeholder
wouldn't be a better choice.
Assuming that polsarpro is Arch:all and polsarpro-bin is Arch:any, which
seems to be the case here, neither of these options works.
A valid possibility would be to reverse the roles and dependencies:
rename polsarpro to polsarpro-data and polsarpro-bin to polsarpro, then
polsarpro can depend on polsarpro-data (= ${source:Version}).
Cheers,
Sven
yes I could use polsarpro-data or polsarpro-gui but the problem remains.
The GUI is written in Tcl/Tk and is arch: all and it must depend form
the package containing command line programs that is arch: any.
Without command line programs the GUI can't perform any useful task.
The assumption from Sven was, I think, that GUI and CLI always come
together, then you could have
CLI depends on GUI = version
GUI depends on CLI (no version)
and users would always tend to install the simplest named package, i.e.
polsarpro but if of course the CLI can be used stand-alone it makes
things more complicated...
I haven't completely thought it through, but you could perhaps have:
GUI depends on CLI (= version)
CLI conflicts with GUI version and with GUI version
(I don't know if conflicts reacts the same way as depends, i.e. remove
the +b stuff from source:Version!?)
As a side-note, you might want to pay attention to the package name if
the CLI can be used independently: I don't think there is a standard but
-bin doesn't sound like something to use standalone, it sounds more like
libraries and plugins, i.e. inert stuff used by the main package. -cli
might be a better choice.
Hope this helps, Eric
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/513ce87e.5020...@zorglub.s.bawue.de
Re: [debian-lan-devel] packaging Debian-LAN
Quoting Andreas B. Mundt (2013-02-03 11:30:29) On Sun, Feb 03, 2013 at 10:53:03AM +0800, Paul Wise wrote: On Sun, Feb 3, 2013 at 4:23 AM, Andreas B. Mundt wrote: Finally, what is the best name for the package? I thought about debian-lan-fai-config, but finally ended up without the fai. I am still not sure if FAI should be mentioned in the package name, or if that gets too long. I was thinking fai-config-lan. Hmm, I don't want to interfere too much with FAI's name space as debian-lan is independent, ... I wait a bit if there are further suggestion, then I'll commit the modifications so far. Choose a name reflecting the primary purpose, avoiding details that might change. If your primary aim was to extend FAI with some classes, which happen to be about setting up a LAN, then Paul's suggestion is better. ...but when the goal of the package is easy Debian deployment for a LAN - mentioning FAI only as a practical way to get there, your own suggestion is better. ...or perhaps simply debian-lan? Then if the project later grows big enough for splitting parts you could move the FAI classes into either debian-lan-config (or debian-lan-config-fai if there will also by then be e.g. a puppet flavor), and have debian-lan become a meta-package pulling both config, tool, documentation, monitoring etc. parts. Avoiding FAI in the name also better fits by secret plan¹ to have FAI be only one way of deplying Debian LAN - Boxer² being another. :-) - Jonas ¹ ...because secret plan sounds more cool than admitting that I have been too lazy to contribute even thoughts yet to Debian LAN project :-/ ² I am currently rewriting in Perl, but a somewhat working first implementation exist with a draft description at http://anonscm.debian.org/gitweb/?p=collab-maint/boxer.git;a=blob;f=README -- * 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: Depending on a -bin package built from the same source version
On 2013-03-10 21:09 +0100, Eric Lavarde wrote:
On 10/03/13 20:17, Antonio Valentino wrote:
Il 10/03/2013 19:59, Sven Joachim ha scritto:
A valid possibility would be to reverse the roles and dependencies:
rename polsarpro to polsarpro-data and polsarpro-bin to polsarpro, then
polsarpro can depend on polsarpro-data (= ${source:Version}).
yes I could use polsarpro-data or polsarpro-gui but the problem remains.
The GUI is written in Tcl/Tk and is arch: all and it must depend form
the package containing command line programs that is arch: any.
Without command line programs the GUI can't perform any useful task.
The assumption from Sven was, I think, that GUI and CLI always come
together,
That was indeed my assumption, don't know if it is valid but the
polsarpro-bin.install file indicates that all the CLI programs are
installed under /usr/lib/polsarpro, so they are probably not very useful
on their own.
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ip4zyobc@turtle.gmx.de
Bug#701693: RFS: compton/0.0.1+git-2182505-2013-02-05-1 [ITP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/13 17:30, Vincent Cheng wrote: On Sat, Mar 9, 2013 at 9:00 PM, Scott Leggett sc...@sl.id.au wrote: snip * Override dh_auto_clean to quiet verbose build warnings. You have an empty override target, which is going to cause multiple builds in a row (e.g. debuild debuild) to FTBFS. If these verbose build warnings are causing the clean target to fail, please fix them. Regards, Vincent Hi Vincent, Thanks for your review, and for spotting the issue. No, the the verbose build warnings on the initial invocation of dh_auto_clean do not cause the target to fail. My use of pdebuild rather than debuild hid the problem with overriding dh_auto_clean. This also caused the build warnings in the first place, regarding missing libraries in the initial, empty, fakeroot environment. Later in the build process, when build-deps have been installed and the package is actually built, no warnings are emitted and the package builds successfully. Therefore I have removed the override and re-uploaded the package. It now builds entirely without overrides or patches. compton (0.0.1+git-b3652f6-2013-03-03-1) experimental; urgency=low * Imported Upstream version 0.0.1+git-b3652f6-2013-03-03 * Initial release (Closes: #679551) -- Scott Leggett sc...@sl.id.au Mon, 11 Mar 2013 00:40:43 +1100 - -- Regards, Scott Leggett. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRPRztAAoJEHlzKPr+55fVSCgP/2OqAI4unicsCB5EEFRhrj// 9YLW+vA3QghMtRKFXDVeqyqQnT01s4kkHZUA5xvxEB5r8a9AelaLaPABgsANi6qT vCebtfl1Uef9EzXE/UMqJlg9wYO8vQC/eJkm+5fCMqb6N3KFyOipXE7CLA4FAHYA J+aaXtWTgqUrdgtp8QXp0CR046amGMz6XlG+qkd5G/TVPGaK48ki2BMHWwcCh8z7 WFyUwSyU4UgeugeZl4uY0Cw0o/aa2Mi8zwOokCwcPLaeRuH2mQA/KzRbLXp6NSuz tN47ZoKpTdfous/j0rYI2epjk1AiHbGeCDBQzv3YrAYZPi6wYih9Uf90iCZjwLjD KtoBr6f8AqrXjcHTVsCQWX6h1k+xCgQoq8tmZTVE+WHvE3u88BEgYi6/ChygOmLl 6EAp6BkPy9gFQzBDmESwxxgnD1BI1DJ0w0qFdLnUVJPU3X6h/bcBt7nTqAvwBiCO YQsMAsYcWFnFQ65rYycVvyWP7XnrYtujqfBMKDPt/dJfOI1XteuJX33HT6V0PaLA YSACBTrcB119xjmNDpuMiz8thkiEw7QYPyfUnKhI9NOwtPHGP+F+wnW7e5h//G44 +jxaRb4jjihqDiv5zmriya3VKyUGBus4kzeSFocLW0/fGxqGY5e798xpvxs9NnsB +Gv2SO1z5nZfVVR0VGrc =nMkX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513d1cfa.3020...@sl.id.au
