Accepted libpmount 0.0.17-2 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 31 May 2016 19:51:50 +0200
Source: libpmount
Binary: libpmount-dev libpmount0
Architecture: source
Version: 0.0.17-2
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 libpmount-dev - portable mount library - development files
 libpmount0 - portable mount library - shared library
Changes:
 libpmount (0.0.17-2) unstable; urgency=medium
 .
   * Use https for hadrons.org URLs.
   * Now using Standards-Version 3.9.8 (no changes needed).
   * Switch to the dpkg makefile fragments in debian/rules.
   * Enable hardening bindnow feature.
Checksums-Sha1:
 a2f15672ef7d46ee1b8e76c6d131af0d5e84b087 1947 libpmount_0.0.17-2.dsc
 34d18c446a5bde1b21f109b9ae3ff7f52c617acd 9028 libpmount_0.0.17-2.debian.tar.xz
Checksums-Sha256:
 cc14d5e272ce2fe031533ca1f36640acb3268bb45c59702e5c63b729adb69fcc 1947 
libpmount_0.0.17-2.dsc
 f98d03a10ca4d2257308cc6369353c7f33cf23ace3c9928abb69d6d37bb88ff2 9028 
libpmount_0.0.17-2.debian.tar.xz
Files:
 708dd09190ce9a076f3e1a9240ed641f 1947 libs optional libpmount_0.0.17-2.dsc
 42598e6aa8a93dead9e21d3d4ef66c16 9028 libs optional 
libpmount_0.0.17-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXTghxAAoJELlyvz6krlejnJIP/RaxRk7ewibjtcmS5+ybkNx6
evFZZwuJM1Hk2u2QXWg8fEWE4xm9v2UuXle0ClNiE4426PrK9Rj+9nFu6HFMr2Iu
1oyclvKV3y4j2M0hbfIkK3PCdusALJKNnzqMI/nOaOf4KhnYxIasoCpOANBVr/ON
tltBtZbV9WxHSEHtOXqDJgD++wx1yqZcYreokLlvU3djQRR+uJVJvyRZTJcsZYA/
AVhKOPnDxFvf33OvnxhyAQcBhlgPsYJ/BklTdkmztCvYDM08h/qLYvwIhGJ6oipn
TBJUW5bmTy1Gkk6WbJuc9wbSYn94TWWu9FxXqoJbcJxySyrWLydOIqpQ3JwjpsxC
twfzbqep2lzIEKdbKdbdTvtukJ8A+P2lWL4vKODzLVIZgmDyHXSnUdUFMvx9/Kqd
dLulFiXumPSLFX8zGlyam00umT4iw8FaKYI6u9jj9Gh67pwr4CkVeWLQWRfhlCbg
g02sIhH4WLHm4m5C1eu38zVb7E5/kLqR8nvuaJgh9AvSuijZm46jseZGHoAfLary
bTkMcuKcb6pFguCw1b6acNk5R29cCyQMz6TijnqyTzs54UeHfGLSbSReFybcOnK3
w0lLiTCXQTtVnldlg6eRH6Bzqw6dQVpnILb60RoMKEMpJwJ4s7w8Jk4cYOA4h6Hm
ZcXmS9jwZCjtS1dcBrC7
=b7RI
-END PGP SIGNATURE-

Accepted xfstt 1.9.3-1 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 23 May 2016 02:10:33 +0200
Source: xfstt
Binary: xfstt
Architecture: source
Version: 1.9.3-1
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 xfstt  - X Font Server for TrueType fonts
Changes:
 xfstt (1.9.3-1) unstable; urgency=medium
 .
   * New upstream release.
   * Use https for hadrons.org URLs.
   * Rename debian/README.debian to debian/README.Debian.
   * Fix typos in README.Debian.
   * Now using Standards-Version 3.9.8 (no changes needed).
   * Switch to the dpkg makefile fragments in debian/rules.
   * Enable all hardening features.
Checksums-Sha1:
 6417a43e5c4f6089396410779160a6dafc6d91cf 2094 xfstt_1.9.3-1.dsc
 0024485b4bd225b048632e7bd53ec7d9d9ce10f6 215116 xfstt_1.9.3.orig.tar.xz
 283f422ec23a88bf8a8f414cf9bf0835e661fbd6 819 xfstt_1.9.3.orig.tar.xz.asc
 e38da23d758e12b6216fa1815689bb2cf303c757 23660 xfstt_1.9.3-1.debian.tar.xz
Checksums-Sha256:
 ca139ea98bae858e8296b3443e842f2f928a3a718f2e44b481003b4a1e27fdd5 2094 
xfstt_1.9.3-1.dsc
 bca319220c9decd9d9cea6c6d691c705e9ceb50071e8fb1d02b170543ddc4b69 215116 
xfstt_1.9.3.orig.tar.xz
 b3d95ca9f94d5f06a116eea00844e4d8d448bb8574f2110a180e319923be583d 819 
xfstt_1.9.3.orig.tar.xz.asc
 66f527621f62dc01bba781e1b91e2e64019770771b1f9e5620e4a49b194a5558 23660 
xfstt_1.9.3-1.debian.tar.xz
Files:
 d564fcc1c30cd4ddaa0f610466c59cf1 2094 x11 extra xfstt_1.9.3-1.dsc
 a86f302e722dcd392dc10deb704d8ee4 215116 x11 extra xfstt_1.9.3.orig.tar.xz
 6916a3748a8b2f2ba190b2ca07c6c632 819 x11 extra xfstt_1.9.3.orig.tar.xz.asc
 8ed36d3e6b177f1cc1ee9b0deb3e674c 23660 x11 extra xfstt_1.9.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXQlDEAAoJELlyvz6krlejFFEP/1b8zoK9zJ6R8qAZMN0VE+i2
Be0mAZFKbA1WtlTOd3D1L5+ILSCixxUINNF4dP1HrCovFb2921Pih3Wxh1qcvdC+
iRPBn4Y47PTjFmd0sy/K0tep0QOqA9tX0hbot3wdJb8x+oOAPOO0doG50DYX0avD
3atKjYplRrTtu5jmOdqVi+KALRh74+KglAGGNzjrPTPTemZJJiLTgnurr2bcmu9X
yVSxpjdRfke+YAUNCWZe8BHL9rqp7wcSQNV4PRPlXOIacpRrFrT7ApkCZXfz5q+J
JU5Qi4cyVObXPoyDMj6ATcTr2Vmxd0eMipkqMXvjePCLKc8Lpf3qtR4lYEdlr04J
RP7tX9p7fDvyMTBdHy//JtAboQLUGT6fLVMQmus/5X6/XRhpSekWdM7THY6OoQqv
BUB2lsGhFIm7erhpQKoj402UMBagnOGtZvqu/MNuMwQFoYATx03RWKXAneCp9F6/
tVwWY0/LxLfH/bGDtj+A+xYhqdsw9vxVKevKXDwPG0tqBSw4ra7Pd7IsbEM4uNn8
jthh2iLWYLM03juY/OSx/oKEJoiOLAHRM1gtEGp8Z/rF8X1qP1JDj1MnVBRnAaFB
0V+LZk/cN0XADVeEDQOHRA3D0wuKC0ST7OYAfIaUZWjo47/rKZx4+U2ekvY6HUrl
rckYS5jwzu87rRVYRkFs
=/REL
-END PGP SIGNATURE-

Re: PIE and static libraries

[Guillem Jover]

Hi!

On Sun, 2016-05-22 at 10:41:56 +0200, Christian Seiler wrote:
[… useful overview …]

I've tried to condense this and the other message on the other thread
to extend the dpkg-buildflags(1) man page. Attached the patch I'm
intending to apply. Let me know if you have other suggestions,
improvements, wording tweaks, etc.

Thanks,
Guillem
From d3a6f97736bade62a8945f91c22593f22f3e2ae4 Mon Sep 17 00:00:00 2001
From: Guillem Jover <guil...@debian.org>
Date: Sun, 22 May 2016 19:20:04 +0200
Subject: [PATCH] man: Document interaction between PIE and libraries

Prompted-by: Christian Seiler <christ...@iwakd.de>
---
 man/dpkg-buildflags.1 | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/man/dpkg-buildflags.1 b/man/dpkg-buildflags.1
index ac2489e..47b77d8 100644
--- a/man/dpkg-buildflags.1
+++ b/man/dpkg-buildflags.1
@@ -362,6 +362,36 @@ locations to bounce off of during a memory corruption attack.
 This is not compatible with \fB\-fPIC\fP so care must be taken when
 building shared objects.
 
+Static libraries can be used by programs or other shared libraries.
+Depending on the flags used to compile all the objects within a static
+library, these libraries will be usable by different sets of objects:
+
+.RS
+.TP
+none
+Cannot be linked into a PIE program, nor a shared library.
+.TP
+.B \-fPIE
+Can be linked into any program, but not a shared library.
+.TP
+.B \-fPIC
+Can be linked into any program and shared library.
+The resulting program might be slightly slower and bigger in case
+\fBbindnow\fP is not in use.
+.RE
+
+.IP
+Unconditionally passing \fB\-fPIE\fP, \fB\-fpie\fP or \fB\-pie\fP to a
+build-system using libtool is safe as these flags will get stripped when
+building shared libraries.
+Otherwise on projects that build both programs and shared libraries you
+might need to make sure that when building the shared libraries \fB\-fPIC\fP
+is always passed last (so that it overrides any previous \fB\-PIE\fP) to
+compilation flags such as \fBCFLAGS\fP, and \fB\-shared\fP is passed last
+(so that it overrides any previous \fB\-pie\fP) to linking flags such as
+\fBLDFLAGS\fP.
+
+.IP
 Additionally, since PIE is implemented via a general register, some
 register starved architectures (but not including i386 anymore since
 optimizations implemented in gcc >= 5) can see performance losses of up to
-- 
2.8.1

Re: Debian i386 architecture now requires a 686-class processor

[Guillem Jover]

Hi!

On Wed, 2016-05-18 at 16:57:48 +, Sune Vuorela wrote:
> On 2016-05-18, Julien Cristau  wrote:
> > Why aren't those bugs RC?

That's indeed a good question! It would probably be best if a neutral
party would do that. :)

> Either we give both users on old hardware a bad experience or all the
> users on new hardware a bad experience.

I don't follow, as I mentioned on the bug report, the patches I
proposed use the JIT if the CPU supports SSE2, otherwise they fallback
to use the interpreter, so no bad experience for anyone (because I
consider silent failure to run at all, way worse than possibly running
but slowly). And I'd probably characterize i386 as being there precisely
to support old hardware by definition.

Regards,
Guillem

Re: Debian i386 architecture now requires a 686-class processor

[Guillem Jover]

Hi!

On Tue, 2016-05-10 at 19:17:15 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Saturday 07 May 2016 13:23:30 Ben Hutchings wrote:
> > Last year it was decided to increase the minimum CPU features for the
> > i386 architecture to 686-class in the stretch release cycle.  This
> > means dropping support for 586-class and hybrid 586/686
> > processors[1].(Support for 486-class processors was dropped, somewhat
> > accidentally, in squeeze.)
> > 
> > This was implemented in the Linux kernel packages starting with Linux
> > 4.3, which was uploaded to unstable in December last year.
> 
> I guess the answer is "no", but just to be sure: does this means that i386 
> supported processors need to implement SSE2?

I suppose this is related to unconditional SSE2 requirement in new Qt
libraries, (bugs #792594, #794739), for which I thought I had clarified
the conditions and for which I've provided patches already, but also for
which I'm not willing to sign the CLA.

This means that Qt and any application using those specific bits, will
not run at all (silently) in Stretch on any AMD-based i386 CPUs, nor on
older Intel ones, which I'd assume is a pretty big percent of the i386
park.

I think the same is affecting Chromium, which I'll need to fix too.
I've got local packages for the Qt Declarative stuff which I could
publish if there's demand.

Thanks,
Guillem

Re: Bug#824130: ITP: libgames-support -- Useful functionality shared among GNOME games

[Guillem Jover]

Hi!

On Thu, 2016-05-12 at 17:39:57 +0200, Michael Biebl wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Michael Biebl 
> 
> * Package name: libgames-support
>   Version : 1.0.2
>   Upstream Author : Michael Catanzaro 
> * URL : https://wiki.gnome.org/Apps/Games
> * License : LGPL-3+
>   Programming Lang: Vala
>   Description : Useful functionality shared among GNOME games
> 
> Code shared between GNOME games.
> 
> This package will be maintained with the pkg-gnome team.

Hmm that's a very unfortunate and generic name for a project that is
apparently GNOME-specific? Of course other desktops, such as KDE have
committed the same sin but… :(

Thanks,
Guillem

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Guillem Jover]

On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote:
> I'm not a fan myself for turning on hardening flags in the compiler itself,
> but if you do that, then dpkg issues like https://bugs.debian.org/823869
> need to be addressed (whether all obscure build systems picking these up, or
> not).

That bug report is not relevant in its current form, as explained
there.

If the default changes in the Debian default compiler, then I'll just
make the +pie option a no-op and change -pie to set -fno-PIE, so that
the options are only added when they are expected.

The difference with that request is that it would currently add
-fno-PIE for most packages that do not change the default flags,
which might break their build-systems.

Thanks,
Guillem

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Guillem Jover]

Hi!

On Sun, 2016-05-15 at 21:45:55 +0200, Bálint Réczey wrote:
> 2016-05-15 20:49 GMT+02:00 Niels Thykier :
> > Bálint Réczey:
> >> I think making PIE and bindnow default in dpkg (at least for amd64) would 
> >> be
> >> perfect release goals for Stretch.
> >
> > I support the end goal, but I suspect we should enable PIE by default
> > via GCC-6's new configure switch[1].  Assuming it does what I hope, then
> > it will work better than enabling PIE via dpkg-buildflags.
> >
> >  * The major issue with PIE by default is that it is not compatible
> >with -fPIC (and presumably also -static), which causes FTBFS or
> >broken ELF binaries.
> >
> >  * Assuming the GCC option does what I hope, then it would automatically
> >disable PIE for irrelevant outputs.
> >
> > My assumption seems to be aligned with the approach taking by Ubuntu.

Right, I've been pondering about the same. And I also have to agree
enabling PIE globally via dpkg-buildflags is not the right approach,
and I'm not planning to enable that in dpkg for any normal arch.
Because it would require hunting down all broken packages, and making
them opt-out from using PIE, or making them opt-out from PIE in some
parts of their build-system. It would also require a flag-day.

For bindnow, the usual process from the dpkg FAQ would still apply.

> I agree that it would be the easier way and I also tried building packages 
> with
> patched GCC 5 setting PIE as default with success, but we have a CTTE
> decision which says that we should set hardening flags through dpkg:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

Meh, I'm not going to bother reading that bug report, but if that's
what the decision really says, then that decision is just bogus…

Thanks,
Guillem

Accepted dpkg 1.18.7 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 09 May 2016 03:19:52 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source
Version: 1.18.7
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-d...@lists.debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 823428 823431 823619
Changes:
 dpkg (1.18.7) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Add new dpkg-source --require-strong-checksums option and change default.
 There is no point in erroring out on this condition when signature issues
 are only warnings, because we cannot guarantee we have functional keys
 for old signatures. Regression introduced in dpkg 1.18.5. Closes: #823428
   * Stop using several fixed sized buffers for program reporting, which in
 many cases could cause confusing truncation of long messages. Use heap
 allocated formatted strings instead:
 - In start-stop-daemon to report what to stop.
 - In dselect to print main and access methods menu entries.
 - In libdpkg command-line option parsing errors.
 - In libdpkg warning, notice and info reporting.
 - In libdpkg ohshit, ohshitv, ohshite and internerr. But in this case
   fallback to a fixed-size emergency buffer in case of allocation or
   formatting error, so that we can at least print something, even if
   truncated.
 Prompted by Manuel A. Fernandez Montecelo <m...@debian.org>.
   * Colorize all fatal-error printing codepaths in libdpkg.
   * Architecture support:
 - Bump the GNU triplet cpu from i386 to i686 to match toolchain changes.
   Thanks to Ben Hutchings <b...@decadent.org.uk>. Closes: #823619
 - Clarify column descriptions in architecture table files.
   * Perl modules:
 - Relax dependency restrictions parsing to allow again sloppy spaces
   around versions, architectures and profile restrictions.
   Regression introduced in 1.18.5. Closes: #823431
 - Add new require_strong_checksums option to Dpkg::Source::Package.
 - Add new tests_dep option to Dpkg::Deps deps_parse() to allow the
   otherwise invalid ‘@’ character in dependencies. To be used when
   parsing the debian/tests/control file.
   * Documentation:
 - Shorten example symbol names in dpkg-gensymbols to avoid a mandb
   warning due to unwrappable lines in translations.
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
 .
   [ Updated manpages translations ]
   * German (Helge Kreutzmann).
Checksums-Sha1:
 76ee921b1ae3a5c220b8bdab3b9b8b0f5708fa74 2026 dpkg_1.18.7.dsc
 dd223bc6f70f43075cc8b7a3ec4925500ff6be5e 4617284 dpkg_1.18.7.tar.xz
Checksums-Sha256:
 36e362ed6ede976a3eb14a7ab1819676ecb8052904e6eb49ca6c1210b5519929 2026 
dpkg_1.18.7.dsc
 ace36d3a6dc750a42baf797f9e75ec580a21f92bb9ff96b482100755d6d9b87b 4617284 
dpkg_1.18.7.tar.xz
Files:
 11f89c5e55b768ce492b51c34b4b27b9 2026 admin required dpkg_1.18.7.dsc
 073dbf2129a54b0fc627464bf8af4a1b 4617284 admin required dpkg_1.18.7.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXL/+MAAoJELlyvz6krlejN1QP/RwqmTTcwRhc5SO+b+wvUQsS
1lwqWDHvW/7sBDFRCmb8uZrniK+Nbo8D/GolXq1trfHInJifvmaPkg+rv2jDUHI4
CQnk3xFAniFdeHt7z/9NNM2kLUyYzIIpAWmH96rvmrdrW+W0sLYluQYLzvnPOeYR
gOGmWhaeLqALIRgd7fFHtJyjQIF4VsYKLImxndYE1f/+14VcgWAOZONgr95vaamG
WMzyy8UXmAr4g1Usyhdbw0IrzQqEYYVn53vgS+4+VmIKvofk8bnOuEzbQe+TxIXT
8s/BUEmH1MZr6Y59dJQfYGiL1m2yNEc1iRGIUA7JzuIE6DVqE3gIDuj94LT2bAih
xdtyOPdzTTROKEtDWrrNRgjSX2zs5esp2LtVdJ60wbzmaxepqZXlqA1QD9JlydNB
esrNxMROKNFDxT6uiYFO8yb7lLrIRGKM8Y7NfSXqAFBdKoIYMPaDuxhA9LRmBjlX
im/8cfVh6SaGQ6C6ChE4UWSWvk22+X03ncILcf6HariZQlwZitQdAKCzCmP+0vL/
VYuBUMKjkn4JDQTBOwxpgg5MWI7PTW96NYQ3homgu6raJzAIix5GhU17OJtLr4gN
5ywGCAo9HLkVj5B5Xs1mfc8hUozAYDq6FjOLAr9p1nsKm3Rt5Ql2n1t4BAaKK4Ua
+oRXuovbB2mkW1dJ01UP
=S3+1
-END PGP SIGNATURE-

Accepted dpkg 1.18.6 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 03 May 2016 20:17:05 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source
Version: 1.18.6
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-d...@lists.debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 823288
Changes:
 dpkg (1.18.6) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Fix file queue tail assignment on file queue pop during unpack. This
 could mess up the file queue in some circumstances and leave behind
 files in the filesystem as «pathname».dpkg-new after configuration
 and without traces of the files in the dpkg database. Closes: #823288
   * Use m_strdup() instead of strdup() in dpkg recursive installation code.
   * Fix off-by-one array allocation in dpkg recursive installation code that
 can cause segfaults.
   * Rename sysctl() “name” variable to “mib”, to avoid a clash with the
 call site function argument with the same name in start-stop-daemon.
 This fixes a build failure on */kFreeBSD systems.
   * Initialize number of entries on initial process scan in start-stop-daemon
 on */kFreeBSD.
   * Packaging:
 - Bump Standards-Version to 3.9.8 (no changes needed).
 .
   [ Updated programs translations ]
   * German (Sven Joachim).
Checksums-Sha1:
 c997a652e94e3faa80a56bd9f725e4cf58a07294 2026 dpkg_1.18.6.dsc
 0a6006875bf85b9101109d989f6fff8e5d8083c3 4617492 dpkg_1.18.6.tar.xz
Checksums-Sha256:
 ee284047ac5cc7d5586f3ac03631621cc8d440cc0ea2da07966c7a6a2452d64d 2026 
dpkg_1.18.6.dsc
 dd0bc323baafe7aae1571a41d37ab92452171e7a2ce34429f77621fdc0e5dea2 4617492 
dpkg_1.18.6.tar.xz
Files:
 e7108c75a1bd3e6d7b735770e7c13305 2026 admin required dpkg_1.18.6.dsc
 d71b6c2e4dfcc89bab5534130f41b0e1 4617492 admin required dpkg_1.18.6.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXKPI8AAoJELlyvz6krlejjjoQAMDaRgJnT7v9D8RBZj8PF9Jq
UbfFYj29L1pVs8nd6p70+tAk220qzqaBy/va19qjuzgOxwNa5chuhF4DgUs9MWwq
aKnlTj0f9OOf9ZeIkIK8vf661/2kv52o/WVhZsEOgR2uhgXN0cA3nSkzjQhZFdmh
NJCRNzj2polj61Gdf9x3DInxEoTTnFw9+L5vNAGcZ2EAMbyJvPEL9iaGcxE4YZUY
DvmUKzGBVMP9LMk/zgb9YmB/aP04BmgINQVQ6MrJWRQGggpDryaZieZ7eD4yBxaL
BGf7RpSfaCjRloU36TUWqKnmAq618yoJ7LJX28Hcw9inH+fng+D/Ac5W01Emoys4
H8avn1GHnpuaD0EopRGRCcTtv/q9lmjpM/V/495n89kWuO/MVtl3kSgXXdTbPTOi
QcyPKz5RcEWHGGFugfCxqk9b63gqri9e3doI8T35+/d0MYFsr3qS981tTCdCYg/S
p8KhcrvsAnNmTGEoYs7WPJFARsXbLWq+06KFexxZX8c/O7mHGS0spGUkeRXVLS7z
EaBfXmEw9lRaGa3VqZFJB7sF/aLrt+kc/b/SzxC91jYU+hOGql9AFMNwbhPxcSVp
bsWnjx4bKMXMZAmL64b4t8HEKmeNisqqvgAT0QMaakxpkt6hOun1jCn6YGKRYJNL
DMvVhSVdzhPV6yYJAhzP
=unb1
-END PGP SIGNATURE-

Accepted dpkg 1.18.5 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 02 May 2016 04:14:57 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source
Version: 1.18.5
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-d...@lists.debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 719845 780906 784806 784808 795163 804624 807340 809174 809219 809517 
809963 810720 811037 811267 812679 813179 819194 819939 819940 821025 822797 
822798
Changes:
 dpkg (1.18.5) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Print correct integer parse error for short-only command-line options.
 This affects «dpkg-deb -z». Closes: #809174
   * Do not abort when traversing symlinks to directories in dpkg-scanpackages
 and dpkg-scansources. Closes: #809219
   * Implement delete operator with size argument in dselect, required by the
 C++14 spec when the size-less delete operator is defined.
   * Use EACCES instead of EWOULDBLOCK for fcntl(2) F_SETLK in dselect.
   * Print the archive filename when dpkg cannot access it.
   * Check that all passed archive filenames to dpkg exist before queuing them.
 Closes: #809963
   * Use ohshit() instead of internerr() for unhandled dpkg-split exit codes.
 (i.e. do not abort). Closes: #812679
   * Detect non-regular file archive arguments earlier in dpkg.
   * Switch URLs in docs, code comments and packaging, from http:// or git://
 to https:// if the latter is available (round three). This includes the
 dpkg git repository, copyright format URL and examples in man pages among
 others.
   * Clarify where to find the GPL-2 license in debian/copyright.
   * Do not enable stack-protector on nios2 in Debian and derivatives (it is
 not supported by gcc yet).
   * Check first for build type to short-circuit boolean expressions in
 dpkg-genchanges.
   * Add source format backend-specific --help options support to dpkg-source.
   * Add MIPS R6 architectures to arch tables. Closes: #807340
 Thanks to YunQiang Su <wzss...@gmail.com>.
   * Fix memory leak when unpacking conffiles.
   * Use fixed string matching for pathnames in dpkg-maintscript-helper.
 Thanks to Carsten Hey <cars...@debian.org>.
   * Quote shell variables in dpkg-maintscript-helper.
 Thanks to Carsten Hey <cars...@debian.org>.
   * Anchor pathnames in sed and grep regexes in dpkg-maintscript-helper.
 Thanks to Carsten Hey <cars...@debian.org>.
   * Allow broken versions starting with a dash in dpkg-maintscript-helper.
 Thanks to Carsten Hey <cars...@debian.org>.
   * Add a new treewalk module in libdpkg, with the nice properties of avoiding
 duplicate stat(2) calls, not calling find(1), and sorting the output w/o
 stalling on the entire input being slurped and sorted.
 - Use it to build the .deb data member in dpkg-deb.
 - Use it to build the .deb control member in dpkg-deb.
 Closes: #719845
 - Use it with dpkg --recursive option.
   * Unify start-stop-daemon --help output with the rest of the tools.
   * Search for debsig-verify in PATH instead of using an absolute path.
   * Do not error out when failing to open the SE label db on permissive mode.
 Closes: #811037
   * Rewrite the trigger deferred file parser from flex to manual. The format
 is very simple, and a simple hand-written parser is smaller and avoids a
 build dependency.
   * Be more strict when parsing the COLUMNS environment variable in dpkg-query.
   * Make the Architecture field mandatory on package builds.
   * Use new Dpkg::Arch functions to validate and parse architectures when
 building source packages. Closes: #784808
   * Do safe matching of directories containing conffiles in
 dpkg-maintscript-helper, instead of using a variable pathname as a regex
 with grep, which is susceptible to metacharacters acting as part of the
 regex. Proposed by Carsten Hey <cars...@debian.org>.
   * Decouple local keyword declaration from command assignment in
 dpkg-maintscript-helper, which masks the command return value when
 using «set -e».
   * Make dpkg pass  to maintscript actions that cannot get it
 otherwise. These actions are now:
 -  failed-upgrade  
 -  abort-install  
 -  abort-upgrade  
 -  install  
 -  upgrade  
 -  failed-upgrade  
 Prompted by Andrey Utkin <andrey.krieger.ut...@gmail.com>.
   * Promote a print to a warning for missing control files in dpkg-deb.
   * Use info() instead of print in dpkg-buildpackage and dpkg-genchanges.
   * Add very basic color support to all dpkg namespaced programs, enabled by
 setting the environment v

Re: Bug#823052: ITP: python-mkdocs-bootswatch -- Bootswatch themes for MkDocs

[Guillem Jover]

Hi!

On Sat, 2016-04-30 at 21:57:47 +1000, Brian May wrote:
> Would appreciate it if somebody could confirm that the license is BSD
> and if so what version of the BSD license this is.
> 
> https://github.com/mkdocs/mkdocs-bootswatch/blob/master/LICENSE

That looks like a BSD-2 clause license but w/o the clauses itemized.
Of course BSD-style licenses have slight text variations in their
warranty and liability paragraph, but this one seems one of the
common ones that I've seen.

Thanks,
Guillem

Accepted libbsd 0.8.3-1 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 23 Apr 2016 11:11:35 +0200
Source: libbsd
Binary: libbsd-dev libbsd0 libbsd0-udeb
Architecture: source
Version: 0.8.3-1
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 libbsd-dev - utility functions from BSD systems - development files
 libbsd0- utility functions from BSD systems - shared library
 libbsd0-udeb - utility functions from BSD systems - shared library (udeb)
Changes:
 libbsd (0.8.3-1) unstable; urgency=medium
 .
   * New upstream release.
 - Fix a memory leak.
 - Various portability fixes.
 - Improve test suite.
   * Switch Homepage and debian/watch URLs from http:// to https://.
   * Now using Standards-Version 3.9.8 (no changes needed).
   * Switch to the dpkg makefile fragments in debian/rules.
   * Enable hardening bindnow feature.
Checksums-Sha1:
 2a7c98f7fd89de63fc3ec0088ff5eabd2d2e44be 2212 libbsd_0.8.3-1.dsc
 39fd9f427a202568f35622b754b547e1607419da 356772 libbsd_0.8.3.orig.tar.xz
 46100f35244e55562f60f983ea635766b8df1618 819 libbsd_0.8.3.orig.tar.xz.asc
 98aa10a4df7179984a97e8c81d62a0501d668170 14924 libbsd_0.8.3-1.debian.tar.xz
Checksums-Sha256:
 8b53b3731a95f00a0f47195e6afdf8dc4bcb3ed3b9b0d3e7046d8c9c98e5c8f2 2212 
libbsd_0.8.3-1.dsc
 934b634f4dfd865b6482650b8f522c70ae65c463529de8be907b53c89c3a34a8 356772 
libbsd_0.8.3.orig.tar.xz
 c0e26a577d19404d05515e0559b9224106a59ecd30910d6896694c4a5a4b021d 819 
libbsd_0.8.3.orig.tar.xz.asc
 c2beb8b2c4678c9f700b09834d1083fb6b1f883b112e493bd1ed1177355114fc 14924 
libbsd_0.8.3-1.debian.tar.xz
Files:
 eca4c10b808ca2e6b04855dacde91bbc 2212 libs optional libbsd_0.8.3-1.dsc
 e935c1bb6cc98a4a43cb1da22795493a 356772 libs optional libbsd_0.8.3.orig.tar.xz
 813d2cdfd10a02a43f3d8f1aeef1fcec 819 libs optional libbsd_0.8.3.orig.tar.xz.asc
 16553d530e2ff28e09443e9f8d6117e6 14924 libs optional 
libbsd_0.8.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXHQubAAoJELlyvz6krlejZPoQAMmHxAu+g5xUSGu5BQdmShI4
o1vcAGzkdsXKkRwWElgfIeIYH2OvzZLG2P1SAsRjPX8bBp9FBdi0glRyCU0xfyS3
mSWs/oc37FkRNtMCG4BBZAYD/4W2aG7FArfToJrTtZ21eQIAUdFgVVGTkVtJTinE
3IBRrkDFBuzR6BtBMk+wNFj7cFIwtwvRfd3ICaYFRrSpkskb2+Mj6aCvoQFVdPN0
e3TLd7PqOUsVdFVMJivHwnVsv0z4VGlhRKO7BV61QdRFpLzYmxlNsMxVb21TQfDw
q/heKzlcksIbsJjftE32ObmTkX6GBVUcNLuJRPyQlscAeiOnDTOTcdiNPzG3hbi0
QLGf7WJiNn1qr1TgLNOuOri6cyaGkshPy0ACsmwgTGOW0telR25+liFAGOsocALH
mKkD/yb7g0/aRI+YgUY5c6lQbOlczEU9FDjdZmi7QCexGGHraNR718xVG3De9YbF
xoCntcHXwDHU50GVxNS4EEcMYcXwQmJXP4fVkr1ZL4PC206rKjZahLct0QIBCHSq
GEQarNHgKA4/znqupJZH48BsFIa7N4XQZz05QKGmnuCm7GMeo8FmrpZMJw4EJPGO
xdLv8Elx07WzWu35R3Hp+Sx4PkGN5EH1xi5PW20mnuOvdME2yil1G4xbquRjd46Z
Ji2/1ml+Y6NmKikHVLa3
=TPZu
-END PGP SIGNATURE-

gcc-on-diet (was Re: Seriously, these binaries should be stripped by default)

[Guillem Jover]

Hi!

On Thu, 2016-04-21 at 18:28:59 +0100, Steve McIntyre wrote:
> Control: severity -1 serious
> Justification: wasting many megabytes of space and download

Yes.

> We're shipping broken toolchain packages that are intentionally too
> large, and this is causing issues elsewhere. The "netinst" CD image
> that we advertise to people as the default Debian image to use for
> most installations is now huge. The multi-arch netinst no longer even
> fits on a single CD due to this waste of space.

And meanwhile, as I mentioned on the bug report. for anyone who cannot
tolerate either the current situation, I cooked a low-fat/light/zero
workaround at:

  

If there's demand and no one else does it I could perhaps be bothered
to create a proper Debian repo somewhere, maybe. :)

Thanks,
Guillem

Time for a .changes file format 2.0?

[Guillem Jover]

Hi!

Samuel Thibault recently reported in #818618 that the Binary field in
the .changes files does not get filtered to only include the binary
packages that are being uploaded, as documented in the ancient
doc/programming.sgml in dpkg 1.3.3 [P], current debian-policy and
now in the dpkg deb-changes(5) [C] man page (in git master).

  [P] 

  [C] 

But this is not really a new behavior, this has behaved like that
since dpkg-genchanges' inception. So either the documentation needs
fixing or we should make dpkg-genchanges behave as documented.

The latter has the immediate problem that it breaks long backwards
compatibility pretty severely. And I think current users such as
DAK (ftp-masters CCed) and probably others might rely on that field
containing all possibly generated binary packages(?), although the
Binary field in the .dsc file already contains that information. This
gets worse with source-only uploads as that might break quite many
expectations, as the field would be missing.


So I'd propose the conservative way out to just fix the docs to match
reality with format 1.8. And then use the opportunity to revamp the
.changes format and draft a new version 2.0, and include the change
there. As a starting point I've listed several of the current issues
I see in the following very early draft:

  

Thanks,
Guillem

Re: Bug#821066: ITP: glide -- Vendor package management for golang

[Guillem Jover]

Hi!

On Fri, 2016-04-15 at 13:34:37 +0800, ChangZhuo Chen wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "ChangZhuo Chen (陳昌倬)" 
> 
> * Package name: glide

There is already an unrelated glide source package in the archive.
Which also generates several *glide* binary packages. Namespacing
this one would seem like a good idea.

>   Version : 0.10.2
>   Upstream Author : Copyright (C) 2014-2016, Matt Butcher and Matt
> Copyright (C) 2016, Hewlett Packard Enterprise 
> Development LP
> Copyright (C) 2015, Google
> * URL : http://www.example.org/
> * License : Expat
>   Programming Lang: golang
>   Description : Vendor package management for golang
> 
>  Manage your vendor and vendored packages with ease. Glide is a tool for
>  managing the vendor directory within a Go package. This feature, first
>  introduced in Go 1.5, allows each package to have a vendor directory
>  containing dependent packages for the project. These vendor packages
>  can be installed by a tool (e.g. glide), similar to go get or they can
>  be vendored and distributed with the package.

Thanks,
Guillem

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Guillem Jover]

On Sun, 2016-03-20 at 20:31:13 +, Ben Hutchings wrote:
> On Sun, 2016-03-20 at 12:39 -0700, Josh Triplett wrote:
> > Leaving aside any other reasons: many packages have a versioned
> > dependency on iceweasel, and we don't have versioned provides.

> Yes we do, since dpkg 1.18.

Actually since dpkg 1.17.11 (as documented in deb-control(5)), and
apt 1.0.7. Both in Debian jessie.

Thanks,
Guillem

Re: Archive changes

[Guillem Jover]

Hi!

On Tue, 2016-03-15 at 15:32:40 -0700, Josh Triplett wrote:
> On Tue, Mar 15, 2016 at 11:15:16PM +0100, Joerg Jaspert wrote:
> > I've just activated a few changes to the archive we talk(ed) about for a
> > long time. And while it is not exactly the start of this release cycle,
> > it should still work out nicely (so one hopes).
> > 
> > As of now, InRelease/Release files, Packages and Sources no longer
> > provide MD5Sum and SHA1sums, only SHA256.
> > 
> > Additionally I turned off generating gzip compressed versions of those
> > files, xz is there.
> 
> In addition to the security improvement,

The only way this might possibly improve security is by perhaps flushing
out things that rely exclusively on weak hashes, once these start to fail.
Otherwise reducing the amount of hashes is not a security improvement.

Increased security is what apt is doing now, which will validate all the
hashes but consider weak ones not sufficient to consider the repo secure.

> a quick analysis on
> binary-amd64 shows that this will reduce the size of Packages for
> binary-amd64 from 39MB to 35MB (uncompressed), and the size of the
> xz-compressed version from 7.9MB to 5.9MB.  Very nice!

While the space reduction is nice…

> That also helps reduce the impact and overhead of adding additional
> binary packages.

…I get the feeling you seem to be fixated on the metadata as the only
problem with an explosion of additional binary packages (tiny or not).
As I've commented on before, metadata size is just a tiny part of the
overhead for a package introduced into the system:

  

Thanks,
Guillem

Accepted dpkg-repack 1.43 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 29 Feb 2016 09:03:09 +0100
Source: dpkg-repack
Binary: dpkg-repack
Architecture: source all
Version: 1.43
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-d...@lists.debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 dpkg-repack - Debian package archiving tool
Changes:
 dpkg-repack (1.43) unstable; urgency=medium
 .
   * Fix variable name botched in a last-minute rebase.
   * Add very basic unit test to check syntax failures.
Checksums-Sha1:
 a98a76a490721b4ddadd80b9d2b15e50be9f8635 1711 dpkg-repack_1.43.dsc
 96bbb82244751fe153b5d88b7664176a19a9dcf7 18912 dpkg-repack_1.43.tar.xz
 b8734aab7d69c600f5ff67cab1a2fc3cd6cd2275 14822 dpkg-repack_1.43_all.deb
Checksums-Sha256:
 d80974944d7953c49c2fb360174b558fa07a2f84dbb1ded1595b6c89f3fb759e 1711 
dpkg-repack_1.43.dsc
 ea8cbf771d5fccd645f16289b3e015f4d56d8335a610b619ad283be1b010a663 18912 
dpkg-repack_1.43.tar.xz
 1d30d1bbd61367e004739192c6885e0ee11556ed7f42a9e471ab0b527dee6e25 14822 
dpkg-repack_1.43_all.deb
Files:
 c2254a7b831de751edb2027e69bdcc74 1711 admin optional dpkg-repack_1.43.dsc
 443b4e2e1eadd9f5d80545fe120f8214 18912 admin optional dpkg-repack_1.43.tar.xz
 a36cd74e5a0ae021201547ae80147356 14822 admin optional dpkg-repack_1.43_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW0/vKAAoJELlyvz6krlejHXoP/3bMFk9BCT7qwpar7oqYKTgj
Gq4V401xy6lSfwNSCEETCweIwFI1IZE7wbKizuSZc+dsqw7MJyN67HsWonnLs9IJ
1VW4GCsIqpVr9i/13DFXqeZrHDQs0E98L7JzsUt2iMHp7b4207D4qX9RoChe5JXo
2rnISqNq3t8GG0BZrCGusm6or/l/xwee+vNLRk3XiHZdBhuaYGFn3eQr/ZKow2RZ
4XWkiWtufcAItQ4XzFhALaHOf/7Geq6qCXvQmDkYzfTH9zy63YLhg5xnqxKP7PsV
9PFrVWns4/SXr4bCBUUBUGEYiwPokFpblR270UYmAoCMpqbiQKWjfdiWd7dnVAZn
XSOv8FKyiTk5s3yKpkGKBY9MiLRzKJkktRqY1+SiBodJSdhEgtvsccqUq7QJPYoX
YXSpTku8MeEHCkoNvqL0DB/KuUYUb3CORp5T1dLRLQ8spgKw4WBJ1c32n8ihbHQi
6aLVjsP6yYRc81sJEUl91/IM50Bf96b8R/4vYw6RRXErV8RGc0K/Etkf5hBWTNXL
HzBedqgpv+/eNSdMbINVbakJd4f811/nhGrZp3ggjNmdk+9WH+R1MwYyJUv62AUS
N6J/1ESUssyV89H5Kyzr7NMp9QgjtsML75U3X0+LK3nl/I2yCoYvJ3PQU0dKtTH+
458o0vXXJkYh02SiYDVi
=PtDy
-END PGP SIGNATURE-

Accepted device3dfx 2013.08.08-4 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 29 Feb 2016 00:19:35 +0100
Source: device3dfx
Binary: device3dfx-source
Architecture: source all
Version: 2013.08.08-4
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 device3dfx-source - Linux 2.2+ device driver source for 3Dfx boards
Changes:
 device3dfx (2013.08.08-4) unstable; urgency=medium
 .
   * Use https for hadrons.org URLs.
   * Sort generated kernel module source tarball contents to make the build
 reproducible.
   * Switch URLs for git repository from git:// to https://.
   * Now using Standards-Version 3.9.7 (no changes needed).
Checksums-Sha1:
 eec93a58395fc3296c54d1c079ab58c64e5a885d 1878 device3dfx_2013.08.08-4.dsc
 1f5efc7e270c43f9aad3d0c000466eaf580a6a24 11992 
device3dfx_2013.08.08-4.debian.tar.xz
 37f307ad3d75fe7fcaf49663345460c0d28f622a 23146 
device3dfx-source_2013.08.08-4_all.deb
Checksums-Sha256:
 60728df81ef13d15d4bcf9535cef32d421ff928a521b389fb4e18fcf10653fef 1878 
device3dfx_2013.08.08-4.dsc
 218140625f33411861de6b8bb6000b73faded0d3ea0eb621846d742fd8d8acc1 11992 
device3dfx_2013.08.08-4.debian.tar.xz
 ef62f7a3f8671aef4eef07479857b1238760a166496cc9c2956c91a2d8b4aed0 23146 
device3dfx-source_2013.08.08-4_all.deb
Files:
 09d00ad07507df36fd8ee5b2e8e95a01 1878 kernel extra device3dfx_2013.08.08-4.dsc
 215a7996e5ee3c4b30033e168529b482 11992 kernel extra 
device3dfx_2013.08.08-4.debian.tar.xz
 ac4a9b14b1af9b4026cd4435aafc56b2 23146 kernel extra 
device3dfx-source_2013.08.08-4_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW04DTAAoJELlyvz6krlejdpEQAIaEQ53Wn1GdxVpWlyzPpsIm
p1292qPI5e24HkOTIQCy45P1NpsnXNQmkUaZnwh3K75KmZCF/S/iGKbJ1pVHwrpc
fVoRBew5zpcb9CIDkmaUlzOIxICe5wMIJKR0Sm/lbJMIUfeX00pPahd9vY95BT+v
0uPYCRp5tm0xv3RYjNPMYisAXCKwtYcrTOJ6Wohpe3HsB4GrolxwrU6fsRf1Ky6i
E9i0+vQ5r0jlhBZ651eQIf925SgtsUD4abRRxZc9h56kTWIp4De5cvp2Om4XhdIb
Jszw6NB2h93klmgyGQlm6aHFeKZcotAwXjNlQgXSOsnFAjIQQspu5mNTbjE7ar/p
REZ2u/IHttLyDj7Fb8QWRPI3+FyITNsDMLcG42jQqcE+gHR+gLlN0QZvALFfVUYz
LpsMsX9L4IbjTpDGOkX7EoP02GHaSowh/liejdPhXHkbpTTo4+q9KufXj7Q2SLrV
3xO2/tSRgPs55eHK/YJsa2dCizow50xeMb51USQ+bexcZSvkvEIQZaeI9gwOjh1l
MMYiH2lUZkb7fZDSP/HMvX47VV0exudUamIeSadgCHJRcWPnm9yXFMSenEe5++tQ
AGylo3oMIZrhhAX6nihakfLHlWGKnqm01gYl8jByni+/pODlNFgobutdX1M2ZLLk
yDmfzDN8ZGZrg90bi67Q
=xknx
-END PGP SIGNATURE-

Accepted dpkg-repack 1.42 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 28 Feb 2016 23:10:41 +0100
Source: dpkg-repack
Binary: dpkg-repack
Architecture: source all
Version: 1.42
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-d...@lists.debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 dpkg-repack - Debian package archiving tool
Closes: 788627 788628
Changes:
 dpkg-repack (1.42) unstable; urgency=medium
 .
   * Use https for the debian/copyright Format URL.
   * Remove ancient versioned Build-Depends on dpkg.
   * Do not add spurious newlines to the binary control file.
   * Ignore case when comparing all field names, although «dpkg -s» already
 normalizes them for known ones.
   * Use a proper non-deterministic temporary directory per package. This fixes
 a possible security issue, and using --generate with multiple packages.
   * Include the package name in the temporary directory, so that they
 are easier to distinguish when operating on multiple packages with
 --generate.
   * Check immediately if we cannot get any package control information.
   * Switch to use Dpkg::Control to handle the control data. Add a dependency
 on libdpkg-perl.
   * Add basic autopkgtest test cases.
   * When using --generate, also print the error summary if the tree might
 be broken due to processing errors.
   * Automatically use fakeroot if available and not running as root.
   * Add fakeroot to a Suggests field.
   * Rename packagename to package-name in --help output.
   * Remove duplicated program name prefix in generate Info message.
 Thanks to Brian Beffa <brb...@gmail.com>.
   * Remove duplicated newline in Warn message.
 Thanks to Brian Beffa <brb...@gmail.com>.
   * Fix grammatical errors and typos in man page and --help output.
 Thanks to Brian Beffa <brb...@gmail.com>.
   * Add a --tag option to select what to mark as being repackaged.
 Based on a patch by Brian Beffa <brb...@gmail.com>. Closes: #788628
   * Add a --tag value to mark the package version as repackaged.
 Closes: #788627
   * Switch git repository URLs from git:// to https:// in README and
 debian/control Vcs-Git field.
   * Bump Standard-Version to 3.9.7 (no changed needed).
Checksums-Sha1:
 9ac8cf70caae194b6c69063454a030289f899d5d 1647 dpkg-repack_1.42.dsc
 dc980c3daf53ee97b4c933b432745345f5346789 18584 dpkg-repack_1.42.tar.xz
 88bade065e49258e35c6ca59ec3d740766da141b 14752 dpkg-repack_1.42_all.deb
Checksums-Sha256:
 1ed17f40f1a5fc223cd825d80652104a7879e343cb6bb264e2911afd8de5df7e 1647 
dpkg-repack_1.42.dsc
 64f27b9a5d05409d3c7a47a35c5a1effe438dc1424484082dd1c8ffbaa2c3459 18584 
dpkg-repack_1.42.tar.xz
 0c38a3fe0d6b0f637d5ac051ace7e829e668e72ec7642c7d93bf69208603ab31 14752 
dpkg-repack_1.42_all.deb
Files:
 c22f9943a8c3fa2f526b1a3130f07446 1647 admin optional dpkg-repack_1.42.dsc
 91102ef3bad3e9065e319bc5f0d81745 18584 admin optional dpkg-repack_1.42.tar.xz
 c992bd401e4331c8d515699aecb22bf0 14752 admin optional dpkg-repack_1.42_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW03VNAAoJELlyvz6krlejAAkQAND72XTloUNS6M+gVJVgX3jr
3qT+W1LwMn2RTfzpJMdo+5U41AFvRDnsMFzhcFZHcroOfXypv4ULYVqWBoyzDDwS
UiQIGAC92Z0dq89KOOF+rh+6MRWqz9Zp82wRxjqBvcAyTeBzcoVhUJhdz53XvxTl
Q/Q8eywimwO1JlEspZX102HT00v1ZjpdHF0CqSQZ2624m5kFAOGUXuNgSKkE30wx
oZhTwHwKMfr1F5EyRTenn/1WlznkkuWzcXXPtypVoDi5mNstL/M65ePFerCz4fBr
rV2t5LZDma7lSdiiXRjLR5OGX3DJoK7IKKoT882cK8jjY7QSxljYPkjYgdaWLE4+
AHvD4BmY6PifVbuQXIoHdXDwS54uw+aRR5Zsc8wK4IQDRBkVOoSEbtr4tFOAvCDK
nPWf3xv5OzakRSQKqT7S+jYzAcpHne5I/HZ/3Le5nTpdsdvqZPErnGngpj7jNRgv
AA7XvsOP+vveh6e0w6Ab/uYbf6/NzO8eOOyRJgNk6xLemsYoo/2cnjg7/oABMQTA
xQd19sha3eOIlYHx3aHXfZicYjpOlAMJlzTvltG0W6X3uaWsxusqWO8hO3501FFG
WJ1+OP4OWD9b1amcnIszVSp4wybeJ/UvZLpAHBXpWjDVeXRqsfmHgUPxEZUS1wpY
vpeW99y57fjjHwekMwr6
=7/Lv
-END PGP SIGNATURE-

Re: Debian package on Windows

[Guillem Jover]

Hi!

On Mon, 2016-02-22 at 14:05:33 +, Jonathan Dowland wrote:
> [ for -devel: this is a reply to a post to debian-apache, please see
>   https://lists.debian.org/debian-apache/2016/02/msg4.html ]

Inlining parts of that mail here:

> On Sat, 20 Feb 2016 01:09:18 +, Eric Mittelette wrote:
> > I contact you today about a crazy idea, but I hope it is a right kind of
> > crazy!

I have no problem with crazy, this one seems to me more shocking than
anything else. :)

> > I'm PM in the Visual C++ Team (VC Lib to be precise here at Microsoft),
> > we started to think about lib acquisition (still a painful process for
> > C++ on Windows) and we are imaging different options, one is to port
> > apt-get on Windows.

I'd assume that porting apt itself should be not too difficult. As
Jonathan has pointed out, you might want to get in contact with the
apt team though.

  

> > Porting Apt-Get mean using Debian format (we love it) and providing
> > Windows binary inside the package...

If by that you mean you'd also want to use dpkg, then that might be a
bit more difficult, as dpkg relies heavily on the underlying system to
provide POSIX semantics. Such as being able to remove opened files, or
replacing opened files with other opened files. Extensive use of fork(2).
And other similar things.

I'd be quite uncomfortable working around several of those things to
make dpkg work on such a best though. Because some of those are IMO
the basis for a sane package manager.

  

> > For doing that we imagine a light way process to adapt your actual build
> > script to generate Windows binaries using our latest Clang/c2 compiler
> > integration (meaning in theory just changing an env variable to switch
> > from gcc or Clang to our Clang/C2 compiler will be enough...)

Over the years there's been attempts to create various Windows ports
based on different runtimes:

  Debian GNU/Interix
  
  

Hmm it seems we even have a mailing list, which seems pretty dead to me,
but might give background information on previous attempts:

  

I think people in general have concluded that such a port would be mostly
useful only to cross-build, but not to run stuff.

There are other teams that have worked to use clang instead of gcc in
Debian proper:

  

> > The main idea here is to not reinvent the wheel for packaging management
> > and use something existing, powerful and well known by the community.
> >
> > Of course all the project will be open source (the new Microsoft J)

That sounds great. And it would be an interesting curiosity to end up
adding this "thing" to . :)

> > Do you want to be included in future discussions and provide feedback as
> > we get more details fleshed out?

I'm not sure if there's interest in a Windows port of Debian, but
porting specific projects might be of interest to the particular
teams, so you'd want to contact those individually perhaps.

Also if you'd like for any changes you end up doing to be included in
the original projects, I'd recommend including those upstream teams in
your discussions, so that they can tell you what is and what is not
acceptable, or a direction they'll agree to take or not.

Thanks,
Guillem

Re: libmd (was Re: Having a single, good arc4random in Debian)

[Guillem Jover]

Hi!

On Tue, 2016-01-19 at 01:18:28 +0100, Guillem Jover wrote:
> [ Just posting to debian and fdo mailing lists, but this might be of
>   interest to other distros, please feel free to forward. ]

This still applies.

> On Mon, 2016-01-18 at 18:25:36 +0100, Marco d'Itri wrote:
> > The same issue was discussed recently for the MD5 functions.
> > The first step is to create a lintian test for packages which use an 
> > internal copy of these functions.
> 
> This is something I've been a bit conflicted with for a while, and I'd
> probably appreciate some input, particularly from potential users.
> 
> In comparison with the BSDs, GNU/Linux does not have basic message digest
> functions available from the base system, and the BSD md functions end
> up being embedded in most code, because they are pretty small, and it's
> better than relying on one of the many libraries that might ship those in
> some form, it's also a guaranteed way to have these present.

> What I've been undecided on has been whether to add those to libbsd
> (which already has MD5 functions since its inception), because that's
> a compatibility library I can see some upstreams not willing to use, or
> releasing libmd [M], which matches what some BSDs actually provide, so
> some upstream already check for its presence, and it's a clean and
> targetted API.

> I'd probably prefer libmd as an independent library, because merging
> it into, say, libbsd is trivial, but taking out the symbols implies a
> SOVERSION bump, which I'd rather avoid.
>
> Also I think it would be nice to be able to have something like libmd
> in the base system, so that anything can use that w/o needing to embed
> the code, nor having to pull in bigger or less "standard" APIs there.

After the overwhelming silent support, I saw no other option than to
go ahead with releasing libmd. :)

  <https://lists.freedesktop.org/archives/ftp-release/2016-February/000700.html>
  <https://ftp-master.debian.org/new/libmd_0.0.0-1.html>

Thanks,
Guillem

Accepted debsig-verify 0.14 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 13 Feb 2016 11:32:58 +0100
Source: debsig-verify
Binary: debsig-verify
Architecture: source
Version: 0.14
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers <debian-d...@lists.debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 debsig-verify - Debian package signature verification tool
Changes:
 debsig-verify (0.14) unstable; urgency=low
 .
   * Assume at least C89 and POSIX.1-2001.
   * Fix man page formatting.
   * Add references to debsigs(1) and gpg(1) to the man page.
   * Add missing man page .TH fields.
   * Use https instead of git or http in URLs.
   * Add new test case covering key to name id mapping.
   * Switch to use more of libdpkg instead of ad-hoc code:
 - Use path_make_temp_template().
 - Switch from popen() to subproc_fork() and execlp(), to avoid shell
   invocation and unsafe argument passing.
 - Use the command module to invoke GnuPG instead of execlp().
   * Do not use an absolute pathname to the GnuPG program.
   * Make the GnuPG program configurable through the DEBSIG_GNUPG_PROGRAM
 environment variable.
   * Fix handling of a possibly non-terminated origin ID string.
   * Fix a file TOCTOU issue in the XML parser.
   * Set umask() for mkstemp() calls.
   * Do not free() nor unlink() an uninitialized string.
   * Fix printing debug message on unmatched key IDs in getKeyID().
   * Update copyright years.
Checksums-Sha1:
 a5ad5cd3813e1d5b7f7057195147f907957fb0fe 1659 debsig-verify_0.14.dsc
 067e4fcdb0a4fefba9c1f4cd754373dcd9b4e48a 127188 debsig-verify_0.14.tar.xz
Checksums-Sha256:
 8ed0552527cf76f67178920fb3ab8da2dd24ae7df67ec17558150a5b34e2be1b 1659 
debsig-verify_0.14.dsc
 a93346012c3602014ba28f7eb2e53ac7bd46ab78b481bb72afbb9871a2c376be 127188 
debsig-verify_0.14.tar.xz
Files:
 c9bff807ca26453b5ee873b37733ec0d 1659 admin optional debsig-verify_0.14.dsc
 f3957713768196292570455a91098456 127188 admin optional 
debsig-verify_0.14.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWvwc4AAoJELlyvz6krlejkb4P/AwCb7GNOd7+ZCrRghRKUMaD
w53pQ2n7ZIVmdDsK3kKi2DMBYPLbB+wcCE733Ob+IpWhKzFcq5yto+NLIcPvaNOR
4pXSBVbyHIUdQGniS4wvdYQplJSns19YAJNwJThOVl/Nz+6Tu8d2F1sLn+FD1Q9r
AxKh8C7DYuc9/GNOWM7kCqf+Huqp8HUSdsvnGN6qmiLmh+SGLgD3VpdL/u/PLtvp
EmETIiqjec1xL2oMT4zf3m16Nrmdk2R8icjx/EuzosSbH8acaed+EcM7T1aWEjEW
oYWAgDymC8XzhPT/UXAwb3R2d5HMAxGtwX+vp1uC/joRwYUmCAUvEg6/4gK6mN90
NhV6kHxkEhvGD0mQhXH/Pxvn1btM3sIfThQpHdZ+suQWwiDDfBBNuuRPZwm0G/Bx
hRB1dfsqqyZo/m+ITIX3MK8gStG6focXwToiB8oMqc/vfMTI3xzszLr1cnxMBYvj
U495cum6BtpTqvZ3lyiS5a0Wf5vHRS/8j1HI65TzB7jGKjLx39cBt078+wiHvPfm
nBXIrlX4bTYxCf911tydbUUno1qqD1ZSnjV/G1cz63fYby0IE2T/dVwGHey4kX0T
PqCdPaE0tfz9bxm0HPXWa6QT6spdQlHrOlDvpfXiOFecE2A/J5ZKa93xeXgtZjwf
BsSL/JwiwNM1ncFKaGE+
=lz+s
-END PGP SIGNATURE-

Accepted libmd 0.0.0-1 (source amd64) into unstable, unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 10 Feb 2016 00:43:54 +0100
Source: libmd
Binary: libmd-dev libmd0
Architecture: source amd64
Version: 0.0.0-1
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 libmd-dev  - message digest functions from BSD systems - development files
 libmd0 - message digest functions from BSD systems - shared library
Closes: 609757
Changes:
 libmd (0.0.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #609757)
Checksums-Sha1:
 47ba337d18d1d1051c795dd15296c4bb0dff0d59 1864 libmd_0.0.0-1.dsc
 86d521272c075b4e76fc2d3f8133bb58798d6e03 252384 libmd_0.0.0.orig.tar.xz
 fafa097d13170756e2487d2712a12a79e654603c 9180 libmd_0.0.0-1.debian.tar.xz
 f050aad69fb7903befe8ffeea0d98fd583303880 40528 libmd-dev_0.0.0-1_amd64.deb
 856bbc346fdeab9e6e36dd187c88783ade0d23d1 29608 libmd0-dbgsym_0.0.0-1_amd64.deb
 8e8a08490812c73fd379effaba872f1af574d62e 23092 libmd0_0.0.0-1_amd64.deb
Checksums-Sha256:
 d4084da822e34d8f9a214eceab752a1d661853378cb9ef8110d833dd912c84b3 1864 
libmd_0.0.0-1.dsc
 fd3f2366236fb3fd0dac0c0a778511e2939c79d1d58daf56e3f5ee383a88 252384 
libmd_0.0.0.orig.tar.xz
 0651a822962c3a742b9f81c6891c687000843f27e7d0fc14f60098462fc97c07 9180 
libmd_0.0.0-1.debian.tar.xz
 36766e5ddd50122df12af74741d4f44e5696aa70c25768fbf784d46b308926a9 40528 
libmd-dev_0.0.0-1_amd64.deb
 92f7df7ff984a552dde079cac09e4f49837afb99ef206fe05ede4db32c67a120 29608 
libmd0-dbgsym_0.0.0-1_amd64.deb
 c80257e830ce827e9040b2e5f2191b8cde1895d01223aca0297a2fb14bdc6c50 23092 
libmd0_0.0.0-1_amd64.deb
Files:
 0393686aed150fdd617f5847d2a98aa7 1864 libs optional libmd_0.0.0-1.dsc
 05be4882f4a982e03615722a413d141e 252384 libs optional libmd_0.0.0.orig.tar.xz
 9c08b5874ac74fafda3af29f2b7109ff 9180 libs optional libmd_0.0.0-1.debian.tar.xz
 978d78807cc0be4a5081db5f9975b59e 40528 libdevel optional 
libmd-dev_0.0.0-1_amd64.deb
 29bd5c43fcc0d0c60c5b9c552170d27d 29608 debug extra 
libmd0-dbgsym_0.0.0-1_amd64.deb
 33f30923280529a585dff926df000c09 23092 libs optional libmd0_0.0.0-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWvv/yAAoJELlyvz6krlejHeQP/iqQWohPPAvxHN1FWR6EKR/D
o9NLtJIANi1hzWEkf83nyzrOnpUh7cz3Pbi1CpX8tEaKIsg7HhWAuBI++YBUsVcG
St+a06+e7FDqHHbM6F6nDRUBsGZd5RUM+ijolynukF6/zmQZTmzzDRZ6JGasuRMR
Yx5TRza8C9gNAy277m8w4RN+k1Aqs2LE1a9BZBDCoG8YkXf7ia719inSbI8bk2dH
oosLeBBg9VufwZZxNVx/k2eTrCZCzhLTd+ZNUbP+ugkGserUl0w8omi5ecmDuW9r
yjy3Qt+4/SHhDVY4LqfYQy8BpQhaiFhwtZaZ2GEP1mNcbnPF3+9Wd0dwfA7vd1eN
QctY/HeGOZXOqgbS6evpCQA7sftoGztC5MzN8NvU2oFwHL/6bjeLYNIM+p1cp6am
SlwjAHRc3qb+zjZR80UwRLDv3BMVC9oQZ7Pu100gEvmyKkQwYleFUOFFtzk1AmrW
Ef0ZiQ1ekr2479aN5cY4RRamCE+xEHaZeJgrb9Ibf4Kr/rDfyzKXAuGw+VbuR6/6
2TYbebmdwF0RywxSdamyTlIXZQbUcWBc9EDDwwu+iCSfWn4wcZSscKz1rWWux63k
VXyOY/s3NQQ0Y5xDnI3PgKbaSqnGXKUfOz8ZbBxsbaqOVzSZTGO+nNWOZ8ViLQIo
QYhxS/NvwWFO+PHk3rf4
=FpeL
-END PGP SIGNATURE-

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

[Guillem Jover]

Hi!

On Tue, 2016-02-02 at 20:23:08 +, Simon McVittie wrote:
> On 02/02/16 17:38, Jonathan Dowland wrote:
> > I must say that I do not like this proposal. The current situation does 
> > result
> > in under-maintained packages requiring churn, but that's true for many 
> > aspects
> > of them, not least their policy version. It's a good indicator of which
> > packages need some attention.
> 
> At the moment, lintian needs changes anyway whenever best-practice
> changes. Would it perhaps make sense to do the same transformations in
> dak - perhaps data-driven, with some regexes supplied by the Alioth or
> lintian maintainers - so that what is published in the Sources file for
> consumers is always the currently-preferred form?

That was exactly my thought. dak is already applying overrides for
Section and Priority, and adding Tag fields, etc, it might as well
fix other stuff.

> > I think it makes the
> > cognitive load of the control file larger. You have to know there are 
> > special
> > rules that exist for some URLs, but not all.

Exactly, I've to say I cannot agree more with Jonathan. And that while
having to adapt the whole archive for new URL changes is cumbersome,
introducing external magic would be worse, because downstreams or
casual users will not know what those URLs refer to, and we'll also
have to hardcode those magic rules in anything that tries to use those
URLs.

Thanks,
Guillem

Accepted libbsd 0.8.2-1 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 27 Jan 2016 17:25:11 +0100
Source: libbsd
Binary: libbsd-dev libbsd0 libbsd0-udeb
Architecture: source
Version: 0.8.2-1
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 libbsd-dev - utility functions from BSD systems - development files
 libbsd0- utility functions from BSD systems - shared library
 libbsd0-udeb - utility functions from BSD systems - shared library (udeb)
Changes:
 libbsd (0.8.2-1) unstable; urgency=medium
 .
   * New upstream release.
 - Fix heap buffer overflow in fgetwln().
 - Various test suite fixes.
   * Switch debug package to an automatic dbgsym package.
   * Output the test suite log on errors.
   * Remove old upgrade postinst to handle lost replaced nlist.h.
   * Switch Vcs-Git URL from git to https.
   * Switch debian/copyright Format field URL to https.
Checksums-Sha1:
 052dda4763db905192696686fdd544953f9b6968 1970 libbsd_0.8.2-1.dsc
 2a8218fc192531f93c62524b3a80fbfc8aeab023 344292 libbsd_0.8.2.orig.tar.xz
 b0d7616ee684dab03f5217421c2abb8edaa064c5 14788 libbsd_0.8.2-1.debian.tar.xz
Checksums-Sha256:
 c620fbc461ea4f78bb2283ed55e36d1d819354ee08980b28577795f512c2948f 1970 
libbsd_0.8.2-1.dsc
 b2f644cae94a6e2fe109449c20ad79a0f6ee4faec2205b07eefa0020565e250a 344292 
libbsd_0.8.2.orig.tar.xz
 03e03c6230dc0243aff0535e89f8e1969f2977b247c1ec57a9783cb1094a0906 14788 
libbsd_0.8.2-1.debian.tar.xz
Files:
 8c9689b460c925599ac0020746188e9c 1970 libs optional libbsd_0.8.2-1.dsc
 cdee252ccff978b50ad2336278c506c9 344292 libs optional libbsd_0.8.2.orig.tar.xz
 eac4182f386a97371b7186187bc39ccc 14788 libs optional 
libbsd_0.8.2-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWqShuAAoJELlyvz6krlejVfsP/j1GJRWnSIF+JcLOhq+OfsbZ
pH2scaI9v6gUFq9gtr9QK77gxR8lm9ePIrrcUlHnWVdGTUGswfU1CE7DVdui2S1X
ltGfNfva1oUsSKiIcnxLhxn92M8cihlkNRvGOiE5GGzAoVJLCAvNC3ZaslYe0I1C
sp6nmWjdWGfz8KnZUc2T7UJCFUsWZrwxZuwWtbys1j8MaG9Tp/W/kwbd1HLUBwXf
JHRykb4yFjzVjSKZcc8PuTo+dnN+17+yfSpOwUiLlIxWNzsLvvSuwDQjdFga5XwR
6bJtRsHPl6CtKpzwNYa6VesvwZsuTVxApByoDscC4lOeXgSZBdEpbEEj376WKf/A
TlcmXEGUYwuBmBWsylD+21ZaNcqcqolo6rb6kAaDuVaz2axWgq8Xy+1RgX/nQYRz
XTPPPQoG4M4pskY7h9yxgGEQamK+OLKezE+nO1tSzk7WL7S7IsG2QpjH+fuq8ONN
w3SI/BQhVtQ3igi+9G5BJaCPin3aSbXeQRJ06N6hExLLufUtH0XECyR9RRQffmfC
0UYT/N6ZUKA6mVDNan4xetOGgR7cChNPQs+Xg3ktEwgNKmyVbRII5tOTmbo76hlJ
MBTrPz1KKhdWd/lfI4tH2i3LO9k7nJJ3J1lw0lvsIyolEoYMSFOA/8Qwg6gsuMF3
s5dtx8LKp8DYU3OudLPH
=Pj5Q
-END PGP SIGNATURE-

libmd (was Re: Having a single, good arc4random in Debian)

[Guillem Jover]

Hi!

[ Just posting to debian and fdo mailing lists, but this might be of
  interest to other distros, please feel free to forward. ]

On Mon, 2016-01-18 at 18:25:36 +0100, Marco d'Itri wrote:
> On Jan 18, Steven Chamberlain  wrote:
> > More background information follows.  What do others think about going
> > in this direction;  the Debian Security Team in particular?  Thanks!

> The same issue was discussed recently for the MD5 functions.
> The first step is to create a lintian test for packages which use an 
> internal copy of these functions.

This is something I've been a bit conflicted with for a while, and I'd
probably appreciate some input, particularly from potential users.

In comparison with the BSDs, GNU/Linux does not have basic message digest
functions available from the base system, and the BSD md functions end
up being embedded in most code, because they are pretty small, and it's
better than relying on one of the many libraries that might ship those in
some form, it's also a guaranteed way to have these present.

What I've been undecided on has been whether to add those to libbsd
(which already has MD5 functions since its inception), because that's
a compatibility library I can see some upstreams not willing to use, or
releasing libmd [M], which matches what some BSDs actually provide, so
some upstream already check for its presence, and it's a clean and
targetted API.

  [M] 

I'd probably prefer libmd as an independent library, because merging
it into, say, libbsd is trivial, but taking out the symbols implies a
SOVERSION bump, which I'd rather avoid.



Also I think it would be nice to be able to have something like libmd
in the base system, so that anything can use that w/o needing to embed
the code, nor having to pull in bigger or less "standard" APIs there.

And here's a small analysis (probably outdated by now, but I'd
appreciate corrections) I did quite some time ago, on why none of the
following seem suitable to me. Either because they contain much more than
needed, the functions are namespaced and/or on "non-standard" headers, the
language used, or the license might not be adequate for the calling code:

  rhash C; MIT; rhash_ namespace
  libtomcrypt   C; PD; bloated (ciphers)
  libcrypto++   C++; PD; bloated (ciphers)
  botan C++; BSD-2; bloated (ciphers + other)
  libheimdal-hcryptoC; BSD-3; bloated (ciphers)
  libaprutil1-dev   C; APL + PD; bloated (general purpose),
   apr_ namespace
  libbind9  C; MIT + BSD-3; bloated (general purpose),
   isc_ namespace, only md5, sha1, sha2
  cyrus-sasl2   C; BSD-4 + RSA-advert; bloated (ciphers)
  beecrypt  C; LGPL2.1+; bloated (ciphers)
  libgcrypt C; LGPL2.1+; bloated (ciphers)
  nettleC; LGPL2.1+; bloated (ciphers)
  bglibsC; LGPL2.1+; bloated (general purpose)
  libxcrypt C; LGPL2.1+; bloated (crypt), only md5 and sha1
  nss   C; MPL, GPL2+, LGPL2.1+; bloated (ciphers)
  polarssl  C; GPL2+; bloated (ciphers)
  matrixssl C; GPL2+; bloated (ciphers)

Thanks,
Guillem

Re: Having a single, good arc4random in Debian

[Guillem Jover]

Hi!

On Mon, 2016-01-18 at 09:57:27 -0800, Russ Allbery wrote:
> Steven Chamberlain  writes:
> > I think it would be good for Debian to standardise on a single, good
> > arc4random implementation, available to any application that wants to
> > use it.
> 
> > I'd like it to become ubiquitous, on all Debian arches (and eventually
> > other distributions).  We should ensure applications do find it and use
> > it, instead of using risky fallbacks like rand(), getpid() and time().
> > (Scan build logs for "checking.*arc4random" for example).
> 
> > We could deprecate dozens of code copies, most of them unmaintained,
> > some having known security flaws that were fixed in later versions.

BTW, the implementation in libbsd uses ChaCha20 and getentropy(3)
since 0.8.0.

> I'm all in favor of this, but when working on this, please take the
> concerns of upstream into account.  libbsd is readily available on Debian,
> but I don't know if that's the case on the other systems that upstream is
> trying to support, so they're going to be understandably worried about
> portability.  Ideally, we wouldn't have to carry a ton of Debian-specific
> patches to do this, though.

I try to track the currently known (at least to me) downstreams in
the project main page . Also I
consider portability a very important thing, so if there's a system
out there (even non-GNU) that's not supported, I'd appreciate bug
reports and/or patches!

> If someone could put together a kit for upstream with Autoconf probes and
> all the machinery for selectively using this implementation if libbsd is
> available, I think that would go a long way towards helping us actually
> achieve this.

If adding m4sugar macros would help I'd happily add those to libbsd.
Also libbsd can be used in a transparent way w/o any code modifications
by using its overlay, simply like this:

  ,---
  CFLAGS := $(shell pkg-config --cflags libbsd-overlay)
  LDFLAGS := $(shell pkg-config --libs libbsd-overlay)
  `---

I should probably document this better. :/

> Even better, of course, would be to get glibc to take the interface, since
> then all one needs is the Autoconf probes.  But I'm not sure how practical
> that really is.

I think this has been proposed in the past, and rejected, I'd not
expect this to happen TBH.

On Mon, 2016-01-18 at 13:08:32 -0500, Scott Kitterman wrote:
> I looked into this a last year or possibly the year before when I was
> trying to get an upstream to drop embedded copies of functions provided
> by libbsd.  I found it was packaged for all major Linux distributions,
> enough coverage to get the upstream in question to just depend on it
> being available.

Right, even samba uses it now. :)

Thanks,
Guillem

Re: What is the correct way to set owner to package's files?

[Guillem Jover]

Hi!

On Wed, 2015-12-30 at 16:46:23 +0300, Konstantin Khomoutov wrote:
> Two caveats:
> 
> 1) Be aware that a user "foo" on your build system might have different
>UID than the user "foo" on the customer's system, and files' metadata
>has owning user and group recorded as a pair of integers -- UID and
>GID, respectively.

The deb(5) format stores the file attributes as part of the tar archive,
which records both numeric ids and their string representation. The
string names are used if the system knows about those names, otherwise
dpkg will gracefully fallback to use the numeric ids.

>IOW, these integers are not portable across systems (unless user
>and group database is in LDAP or NIS or otherwise centralized and
>shared by these systems), and you have to make sure that when your
>package is unpacked to the target filesystem, the UIDs and GIDs on
>its files belong to the user they should.

Actually, you'd just need to make sure the user and group names exist
before the package gets extracted. You can do that in the preinst.

> 2) Newer Debian packaging often uses a generic helper sequencer, `dh`,
>wich is able to reduce debian/rules to a mere couple of lines.

> If this does not work (with the point (1) above being especially
> problematic, IMO), you might have better luck with post-installation
> fixup of the permissions.  The idea is that the list of files a package
> contains is located in /var/lib/dpkg/info/{packagename}.list file,
> so in your postinst script (maybe even in preinst -- after the package
> is unpacked -- I can't remember the exact details, please refer to the
> Debian policy which explains all these things) you should be able to
> read this file and feed it to something fixing up permissions, like
> 
>   xargs -n 30 chmod foo:foo \
>< /var/lib/dpkg/info/{packagename}.list

The dpkg database is supposed to be private and an internal
implementation detail. There's a perfectly usable public interface for
this: «dpkg-query -L», please use that instead.

But in any case I think this is a bad idea, as it will stomp over
dpkg-statoverride(1)s.

> provided your script first called `useradd` to add that user and/or may
> be first verified it already exists via calls to `getent passwd foo`
> and `getent group foo` etc.

Depending on the usage you might want to use adduser instead. But then,
if you use it in preinst you'll need a Pre-Depends.

Thanks,
Guillem

Accepted dpkg 1.18.4 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 25 Dec 2015 13:20:26 +0100
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source
Version: 1.18.4
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-d...@lists.debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 760248 799046 799432 799875 800513 800649 801156 801329 801958 805872 
806315 807156 808912
Changes:
 dpkg (1.18.4) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Switch dpkg-scansources and dpkg-scanpackages to use File::Find instead
 of find(1), as the former is more portable with more consistent behavior,
 and always canonicalizes the pathnames. Closes: #800649
   * Initialize Config-Version also for packages previously in triggers-pending
 state, otherwise we end up not passing the previously configured version
 to «postinst configure», which might consider this a first install instead
 of an upgrade. Closes: #801156
   * Fix memory leaks in «dpkg --verify» and dpkg infodb format upgrade logic.
   * Merge all update-alternatives action handling into a single if-else-if
 block, to unify the code an allow a future switch into a shared library.
   * Perform any necessary cleanups on normal exit from dpkg-divert --add and
 --remove commands.
   * Make dpkg-architecture warning on non-matching GNU system type compiler
 agnostic.
   * Add ‘.gitreview’ to the default dpkg-source ignore lists.
   * Add support for DPKG_MAINTSCRIPT_DEBUG environment variable to dpkg.
   * Fix dpkg-checkbuilddeps exit code to be 1 instead of a random error value
 on unsatisfied dependencies. Regression introduced in dpkg 1.18.3.
   * Fix an off-by-one write access in dpkg-deb when parsing the old format
 .deb control member size. Thanks to Hanno Böck <ha...@hboeck.de>.
 Fixes CVE-2015-0860.
   * Fix an off-by-one read access in dpkg-deb when parsing ar member names.
 Thanks to Hanno Böck <ha...@hboeck.de>.
   * Add experimental multithreaded xz compression support in libdpkg, which
 requires xz >= 5.2.0.
   * Fix physical file offset comparison in dpkg. Closes: #808912
 Thanks to Yuri Gribov <tetra2...@gmail.com>.
   * Fix usage of dpkg-architecture -s after other action options.
 Reported by Niels Thykier <ni...@thykier.net>.
   * Add NIOS2 support to cputable. Thanks to Marek Vasut <ma...@denx.de>.
   * On Debian and derivatives enable timeless build flag feature by default.
 Thanks to Paul Wise <p...@debian.org>. Closes: #805872
   * Perl modules:
 - Add support for Build-Essential field. Closes: #806315
   * Test suite:
 - Improve perl code test coverage.
   * Build system:
 - Set PERL5LIB globally for the test suite to the local modules directory,
   to avoid using the system modules. Regression introduced in dpkg 1.17.8.
   Reported by Jérémy Bobbio <lu...@debian.org>. Closes: #801329
 - Use absolute buildir pathnames in PATH variable for the test suite.
 - Descend into scripts directory when cleaning up code coverage files.
 - Add new configure option --disable-devel-docs to select the kind of docs
   to generate, default for now is development documentation.
 - Try to use AM_GNU_GETTEXT_REQUIRE_VERSION to benefit from the latest
   installed gettext version, while guaranteeing a minimal required version.
   * Packaging:
 - Add missing Build-Depends for restriction formula support.
   * Documentation:
 - Move description for “target architecture” from the dpkg-architecture(1)
   ‘-A’ option to the TERMS section. Closes: #799046
 - Clarify that the md5sum check on «dpkg --verify» is performed on the
   file contents, and failures denote changed content. Closes: #760248
 - Document that dpkg-buildpacakge -nc -S implies -d.
 - Clarify role of Build-Depends in deb-src-control(5).
   Prompted by Johannes Schauer <j.scha...@email.de>.
 - Document supported feature areas.
 - Clarify in dpkg-query(1) when binary:Package gets arch-qualified.
   Closes: #801958
 - Add a subsection separating external from internal environment variables
   in dpkg(1).
 .
   [ Updated programs translations ]
   * Dutch (Frans Spiesschaert). Closes: #800513
   * Japanese (Kenshi Muto). Closes: #799432
   * Turkish (Mert Dirik). Closes: #799875
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
 .
   [ Updated manpages translations ]
   * German (Helge Kreutzmann, Julian R). Closes: #807156
Checksums-Sha1:
 4f1df693463e7279d4d0362dbb00b6116353a933 2053 dpkg_1.18.4.dsc
 87707de6726d27f2c60fb

Accepted libbsd 0.8.1-1 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 14 Dec 2015 04:10:23 +0100
Source: libbsd
Binary: libbsd-dev libbsd0 libbsd0-udeb libbsd0-dbg
Architecture: source
Version: 0.8.1-1
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 libbsd-dev - utility functions from BSD systems - development files
 libbsd0- utility functions from BSD systems - shared library
 libbsd0-dbg - utility functions from BSD systems - debugging symbols
 libbsd0-udeb - utility functions from BSD systems - shared library (udeb)
Closes: 806840 807730
Changes:
 libbsd (0.8.1-1) unstable; urgency=medium
 .
   * New upstream release.
 - Add support for GNU/Hurd and GNU/kFreeBSD. (Closes: #806840)
 - Fix implicit dependencies for non-overlaid headers. (Closes: #807730)
   * Switch debian/copyright to machine readable format, reusing upstream
 COPYING file.
   * Use https for hadrons.org URLs.
Checksums-Sha1:
 ea7659d471511d7624a1c79859db876763feccd7 2010 libbsd_0.8.1-1.dsc
 ef77627a44506e5bf3fbd3a65deaf46364724af5 343624 libbsd_0.8.1.orig.tar.xz
 d40eea96302f3c3d3792e8bead4cd78cf7984fbb 16576 libbsd_0.8.1-1.debian.tar.xz
Checksums-Sha256:
 985fa5d23d8a7fec60b8c48a2d0d436239a6525355eb9d07b718d0b9df7f3689 2010 
libbsd_0.8.1-1.dsc
 adbc8781ad720bce939b689f38a9f0247732a36792147a7c28027c393c2af9b0 343624 
libbsd_0.8.1.orig.tar.xz
 166b9fb4eaca0c3e136503474e72bddef1e5f4727b5706f0575847f0d799eef2 16576 
libbsd_0.8.1-1.debian.tar.xz
Files:
 2c571171f3a58d5ead5ec01d78afbc86 2010 libs optional libbsd_0.8.1-1.dsc
 f3daff0283af6e30f25d68be2deac4ef 343624 libs optional libbsd_0.8.1.orig.tar.xz
 0ac6971102ad789ece3589463e62904e 16576 libs optional 
libbsd_0.8.1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWbjOdAAoJELlyvz6krlejpFIQAKq2IpFSihAau6opS5fCyutr
mFOYYxDshuONpwX7+NUYGA9rx1IaB95Alcn41YBMVdeb8pDXmB5FeOBn5rdaOng8
upB4LF4tGsmMq/vT3fMYZ1ccB9Ew+Ii885wbi6W7nz5O+hs+he6Hh7Dv7fMJHR5t
SU8GJJHa1KjlxJCboFQxchpuyxZCs0gnAG8YNVeCJHQPWWdmezCftALCvI5sW88t
ggE6x7hu1cYiQ9P1+HAjXsmbd58mH6lc4Okm8i4EOe66R4DcT/1ajHYv1nK1W+MK
3DS1RJxbSx0VNGlZwkhcA2Ia9W5CdBUCeCKArkYORKwGoqzIr49RTpv1obR+uDoL
AC0U4w0TrwOqja+rIODETMw/lpKcG7D0Bc51zhTyqfYXRVpmztYUwUlZdRvOMa1v
VDXC0eWQWYcgZSmf+wAJvUwvtZufLzL0LHESPtTJLWSsGBvG+QwnSgFa3u1RZcY2
FCL/HyCzVRYesFjQHZtG3Qcm7yZ8xW1eiUCUcWdTZevNb4H1+m47L4HcoFn8tt96
2b9HoKuSykecom69WbX8Orf3ZWJj1NWCHS9euFFcpLbWtQ3xqC840RFy2BTPn3BH
/68sxEYpvlx+NQKyvR8xxI7NruMLmf/yAR2REyTBAOz/Sv2gdfCXnH2LFmGVTLLV
ZRG5KVpEwku/+J80FXjg
=LMCc
-END PGP SIGNATURE-

Accepted libbsd 0.8.0-2 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 02 Dec 2015 00:40:34 +0100
Source: libbsd
Binary: libbsd-dev libbsd0 libbsd0-udeb libbsd0-dbg
Architecture: source
Version: 0.8.0-2
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 libbsd-dev - utility functions from BSD systems - development files
 libbsd0- utility functions from BSD systems - shared library
 libbsd0-dbg - utility functions from BSD systems - debugging symbols
 libbsd0-udeb - utility functions from BSD systems - shared library (udeb)
Changes:
 libbsd (0.8.0-2) unstable; urgency=medium
 .
   * Revert addition of libtestu01-0-dev into Build-Depends as it is only
 available in the non-free area of the archive for now.
Checksums-Sha1:
 99c4676fe2b30664691d8fb55d4275a2b14b48bf 2009 libbsd_0.8.0-2.dsc
 0f3d8d0b0722f7c9b427331376be4b6fbec011a5 17116 libbsd_0.8.0-2.debian.tar.xz
Checksums-Sha256:
 22447deb410357415ca56ca785446c9059019b6067ef11dbe1edcf7894bc8bb4 2009 
libbsd_0.8.0-2.dsc
 d56ef3042393712606dc0a591203d7f4f71d0ada0716c3cb9175e33dc525f331 17116 
libbsd_0.8.0-2.debian.tar.xz
Files:
 5146b3e93e6e4f01d6dc23a84775e385 2009 libs optional libbsd_0.8.0-2.dsc
 4d27b897ea3a5b6fbc0fa2eb35312bce 17116 libs optional 
libbsd_0.8.0-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWXjVtAAoJELlyvz6krlej0wkQAOa6Fskmu24K3IFzhaUbKMTZ
b5IqIPq3ObZOKj4bR55UYnRB9yPGs1HkNhT2G6V5yhyzhOoYhiTqDznHvZtDulpL
cNmeC6kZVtkHTDouiOglEd8h1tBfF//ODkW4szBE5Lf6FOpLUS/TOu/KMMcyEJ4T
ItU8EZVRcUO+j0I3f1Y0S6dKagv/uA152qPTP6ItNtj0igUYDY9ThybcLA93Y5TA
0QDXpkcly7avDX7ICxlpwpgzn1vwb2JfPPqLtr8yj/zJ0fyttv4xEJHsEB33WC23
1Vok9vKlcVAKxUO7EwMOv0uEq7fEYE79Rvuj0kHBnqpYXtgAZm4zwgxphMNmUNOX
/ua9B9HzxqgMOCXYbuGABz0fwq5t2Dz9LeECoh6exlgYqVWeLYTYZKr1UGkuZlom
IZDkYi0u41aq2dGCg9kq+bZrZDu2qzjHIehljI5+1uNOhLjiA/kl4W/YdQCQDNFY
XSJ/6ku7Uwe+VhH8Q7xi1LZTHN+S7iHOjwPzCt+7qQQMJtbV6IFYDBZfPIP/s6rx
VemydVP33AD0OA7Ppi3JcUsjz7MKqLxgUgOk4NHHYncwJAPv6KrTSIwnz93mOXg+
VzyUOCSVqdgcA1bfKq+3mAb+5cAtoqgC8R2/ARJO82LTUkEklRELF6W+LHwvPffZ
YeJO38jAqMjrXj4VG/lc
=eCV/
-END PGP SIGNATURE-

Accepted libbsd 0.8.0-1 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 30 Nov 2015 23:34:00 +0100
Source: libbsd
Binary: libbsd-dev libbsd0 libbsd0-udeb libbsd0-dbg
Architecture: source
Version: 0.8.0-1
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 libbsd-dev - utility functions from BSD systems - development files
 libbsd0- utility functions from BSD systems - shared library
 libbsd0-dbg - utility functions from BSD systems - debugging symbols
 libbsd0-udeb - utility functions from BSD systems - shared library (udeb)
Closes: 719640 747671
Changes:
 libbsd (0.8.0-1) unstable; urgency=medium
 .
   * New upstream release.
 - Add new man page for reallocarray(3).
 - Rename funopen.3 manpage to funopen.3bsd.
 - Add __DECONST, __DEVOLATILE, __DEQUALIFY, __offsetof, __rangeof and
   __containerof to sys/cdefs.h.
 - Sync sys/queue.h from FreeBSD.
 - Add compile and link-time deprecation warnings for fgetln().
 - Add explicit_bzero() function from OpenBSD.
 - Fix arc4random prototypes from uchar to unsigned char. (Closes: #719640)
 - Update arc4random to use ChaCha20. (Closes: #747671)
   * Switch Vcs-Browser to a cgit URL.
   * Now using Standards-Version 3.9.6 (no changes needed).
Checksums-Sha1:
 11b851a662f255f1e318093334bc1e6721979d4f 2048 libbsd_0.8.0-1.dsc
 af8981b6406f85b9260a84aac3c633c05a47d919 342016 libbsd_0.8.0.orig.tar.xz
 e6b2cd6ad678ff4c8d62b37943c79daefd10a215 16992 libbsd_0.8.0-1.debian.tar.xz
Checksums-Sha256:
 81029dc0ffe7f326009bc17d75cfbff3a65cebffa5083ea2bb592bc47607bc5d 2048 
libbsd_0.8.0-1.dsc
 fbb732084bd960e4c78b688aac875be98e290cc6fe462b2ff8ee946a6473e38c 342016 
libbsd_0.8.0.orig.tar.xz
 8c85ae4d9c51ba80eca4c15581b9d25b6c926762736438292284be76d525 16992 
libbsd_0.8.0-1.debian.tar.xz
Files:
 b2f8b5a94d293de65b5de07c247e756f 2048 libs optional libbsd_0.8.0-1.dsc
 262bdd1aa3bee6066a8c9cb49bb6c584 342016 libs optional libbsd_0.8.0.orig.tar.xz
 702e73142b7a83310e66d86735ff9277 16992 libs optional 
libbsd_0.8.0-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWXQWxAAoJELlyvz6krlejKFgP/RXWqa/OltXTDUQZqamsKK7f
p7Jbxr5C/fLMzfhoNnjj+1UW4PLiBTK9Q23/9mRrRK7MMQ0r2El8yosIFFhr5Jpg
KviW5WhpdSbNxEnaWSPAL6hm9Rv1XqD8qc3b5qcUVYF0N5ntrtwSoC0hnrfd597g
Dl5in7X2wSgmKevcriUFU0sa/5/wlz7M0uSiYeyAsqD6vaeTCxWb83FzyScirpVk
fX8Rv3Tk1k/Inp6CVfv6If1bdLj2BWJwHjyDTM3Ha2I4R50Qg9Q74wHq2Rfl5bwG
rlSKaaAP1N4Pfgf3Rdya8Cd87hCiLWSkajBVNq3PbvEfaQNimpgbeHapTXdCVibq
u6VM719EwI7yJQOmpb/k4CHE3RUAbLJ18f18nvtmRbcQCC5hVQQid+KybsrC2LaL
MaoVgi/RHbNZztWXqqLqLo7TRPvh14GSh7G2+0Hns5Tc0iQoA+6+7CpZUhuHxpyN
s8mG/lMCAyKrJsD9jfcDY4+G+DoXZer1S9jxzjY1YjTBcvioWwZfe/AscACjfBLW
KtxHao82rfFc4kO8DC9MvoJfQYLxjr0rpEZs69AKnh2HJSecBguYtTEjK+W5bUKP
/23J42tfhBFuvixTkygv0KAVLR4/iGhAbyxH0ucqoVvaNZewfmGiZPYsK2fcYEDX
lWeqKflf1Qm+YwNJpDd7
=jvH5
-END PGP SIGNATURE-

Heads up: New -Wdate-time in default dpkg-buildflags output

[Guillem Jover]

Hi!

On Tue, 2015-11-10 at 17:32:31 +, Mattia Rizzolo wrote:
> As part of the Reproducible Builds effort [0] we added a
> "reproducible/timeless" feature area to dpkg which exports -Wdate-time
> via CPPFLAGS [1].
> 
> In our CI infrastructure we enabled that in Spring.
> 
> We now think this is the right time to enable this flag by default.
> From our builds, we can only see 4 packages which fail to build due to
> this:
> subversion + unbound
> https://bugs.debian.org/790102
> expeyes
> https://bugs.debian.org/790103
> wsjt
> https://bugs.debian.org/804672
> 
> 
> Following [2] we're now bringing this up on debian-devel@l.d.o to learn
> about for any known issues we may be not aware of, any concerns, etc.

BTW, thanks for doing all this!

In any case this is a heads up to note that the next dpkg upload will
include the change requested in #805872. If anyone has concerns or
objections, please bring them up now.

Thanks,
Guillem

Re: quedada octubre Sevilla

[Guillem Jover]

Hola!

On Fri, 2015-10-23 at 09:28:06 +0200, Arturo Borrero Gonzalez wrote:
> Nos vemos hoy, no?
> 
> * viernes 23 octubre
> * 20:00h en el Pub Merchant (Sevilla)
> * https://wiki.debian.org/DebianEvents/es/2015/SevillaMeetingOctober

Yo al final no podré ir. :( Pero si se organiza otra me apunto!

Saludos,
Guillem

Re: Replacing ldconfig maintscripts with declarative methods

[Guillem Jover]

Hi!

On Mon, 2015-10-05 at 16:14:38 +, Niels Thykier wrote:
> As of debhelper/9.20151004, dh_makeshlibs is now using triggers rather
> than maintainer scripts to invoke ldconfig.
> 
>  * Lintian in untable + testing is already aware of this
>  * Lintian has /not yet/ been backported.  Lintian from backports still
>(incorrectly) reports this an issue.

Wonderful! Thanks for this Niels.

Regards,
Guillem

Re: Defaulting to i686 for the Debian i386 architecture

[Guillem Jover]

On Thu, 2015-10-01 at 19:15:54 +0200, Matthias Klose wrote:
> question to the Hurd and KFreeBSD maintainers ... change that on these
> platforms too?

As it currently stands, this is not a question when it comes to
dpkg, that specific change is all or nothing. The Debian ←→ GNU
cpu mapping is global for all architectures.

But as I've mentioned several times now, I think changing the GNU
triplet (only on i386) every time we bump the ISA is the wrong way
around this, and the above is another reason of why, but this has
been ignored in the past so… you'll have to sort this out.

Thanks,
Guillem

Re: Bug#800093: ITP: libdpkg-parse-perl -- module to parse various dpkg files into Perl Objects

[Guillem Jover]

Hi!

On Mon, 2015-09-28 at 12:37:22 +0100, Andrew Beverley wrote:
> On Mon, 2015-09-28 at 13:12 +0200, Guillem Jover wrote:
> > On Sat, 2015-09-26 at 21:12:57 +0300, Andy Beverley wrote:
> > > Package: wnpp
> > > Owner: Andy Beverley <a...@andybev.com>
> > > Severity: wishlist
> > > X-Debbugs-CC: debian-devel@lists.debian.org, 
> > > debian-p...@lists.debian.org
> > > 
> > > * Package name: libdpkg-parse-perl
> > 
> > What's the advantage of this over the various modules in libdpkg-perl?
> 
> I think it's the only way to retrieve version information. It's a long time
> since I wrote my original patch for dh-make-perl, but I seem to remember
> that DPKG::Parse was the only module that provided certain information I
> needed (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774074).
> 
> I certainly tried to do it with other modules already packaged, but I
> couldn't gain all the required information.

The attached untested patch should in principle do it. In any case the
available file is only ever up-to-date when using dselect. If it's too
slow, this should be fixed in libdpkg-perl anyway as that would benefit
every caller.

Thanks,
Guillem
From 30408bf2dd2cd7da3a794a1a5869a4cdcf1c8332 Mon Sep 17 00:00:00 2001
From: Guillem Jover <guil...@debian.org>
Date: Tue, 29 Sep 2015 15:06:34 +0200
Subject: [PATCH] Switch from libdpkg-parse-perl to libdpkg-perl modules

---
 Build.PL|  3 ++-
 debian/control  |  1 -
 lib/Debian/Control/FromCPAN.pm  | 18 --
 lib/DhMakePerl/Command/Packaging.pm | 16 +---
 4 files changed, 15 insertions(+), 23 deletions(-)

diff --git a/Build.PL b/Build.PL
index cc3ae8b..e2eaf31 100644
--- a/Build.PL
+++ b/Build.PL
@@ -7,7 +7,6 @@ my $builder = My::Builder->new(
 module_name => 'DhMakePerl',
 license => 'gpl',
 recommends  => {
-'DPKG::Parse' => 0.02,
 'Git' => 0,
 'IO::Dir' => 0,
 },
@@ -24,6 +23,8 @@ my $builder = My::Builder->new(
 'CPAN::Meta'=> 0,
 'Cwd'   => 0,
 'Dpkg'  => 0,
+'Dpkg::Index'   => 0,
+'Dpkg::Control::Types'  => 0,
 'Dpkg::Source::Package' => 0,
 'Email::Address'=> 0,
 'Email::Date::Format'   => 0,
diff --git a/debian/control b/debian/control
index f02f170..2de9da9 100644
--- a/debian/control
+++ b/debian/control
@@ -78,7 +78,6 @@ Depends: debhelper (>= 8),
  ${perl:Depends}
 Recommends: apt-file (>= 2.5.0),
 git,
-libdpkg-parse-perl,
 pristine-tar
 Description: helper for creating Debian packages from perl modules
  dh-make-perl will create the files required to build a Debian source
diff --git a/lib/Debian/Control/FromCPAN.pm b/lib/Debian/Control/FromCPAN.pm
index b0895e1..f4d5d48 100644
--- a/lib/Debian/Control/FromCPAN.pm
+++ b/lib/Debian/Control/FromCPAN.pm
@@ -48,11 +48,12 @@ An instance of L to be used when locating to which package
 a required module belongs.
 
 =item dpkg_available
-An instance of L to be used when checking whether
+
+An instance of L to be used when checking whether
 the locally available package is the required version. For example:
 
-my $available = DPKG::Parse::Available->new;
-$available->parse;
+my $available = Dpkg::Index->new(type => CTRL_INFO_PKG);
+$available->load("$Dpkg::ADMINDIR/available");
 
 =item dir
 
@@ -272,7 +273,7 @@ L class) and a list of missing modules.
 
 Perl core is searched first, then installed packages, then the APT contents.
 
-If a DPKG::Parse::Available object is passed, also check the available package version
+If a Dpkg::Index object is passed, also check the available package version.
 
 =cut
 
@@ -307,12 +308,12 @@ sub find_debs_for_modules {
 );
 
 # Check the actual version available, if we've been passed
-# a DPKG::Parse::Available object
+# a Dpkg::Index object
 if ( $dpkg_available ) {
 my @available;
 my @satisfied = grep {
-if ( my $pkg = $dpkg_available->get_package('name' => $_) ) {
-my $have_pkg = Debian::Dependency->new( $_, '=', $pkg->version );
+if ( my $pkg = $dpkg_available->get_by_key($_) ) {
+my $have_pkg = Debian::Dependency->new( $_, '=', $pkg->{Version} );
 push @available, $have_pkg;
 $have_pkg->satisfies($dep);
 }
@@ -327,9 +328,6 @@ sub find_debs_for_modules {
 push @missing, $module;
 }
 }
-  

Accepted libaio 0.3.110-2 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 29 Sep 2015 16:48:30 +0200
Source: libaio
Binary: libaio1 libaio1-udeb libaio1-dbg libaio-dev
Architecture: source
Version: 0.3.110-2
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover <guil...@debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 libaio-dev - Linux kernel AIO access library - development files
 libaio1- Linux kernel AIO access library - shared library
 libaio1-dbg - Linux kernel AIO access library - debugging symbols
 libaio1-udeb - Linux kernel AIO access library - shared library (udeb)
Changes:
 libaio (0.3.110-2) unstable; urgency=medium
 .
   * Use https for the debian/copyright Format URL.
   * Switch Vcs-Browser to a cgit URL.
   * Update Homepage URL to new release site.
 Prompted by Sedat Dilek <sedat.di...@gmail.com>.
   * Use https in debian/watch URL.
   * Add a small note on each long package description explaining what is
 contained on each package.
   * Document each patch.
Checksums-Sha1:
 f79e7c0386d2648b1accfc2d7b424e5b594017ae 2028 libaio_0.3.110-2.dsc
 8c74130cc8367fa1fafb7751c655510f6d58a00b 19076 libaio_0.3.110-2.debian.tar.xz
Checksums-Sha256:
 e4dba8c41a98b2175a71106250c2c93bcd1d181741179f1e155906137a42a4f9 2028 
libaio_0.3.110-2.dsc
 429e9b3423d6d7d70a3adafc5dd2bab70703b5b3472d7bc080d153c3455bd85a 19076 
libaio_0.3.110-2.debian.tar.xz
Files:
 cd93327f4e269f10a91489e2bb40fd66 2028 libs optional libaio_0.3.110-2.dsc
 1c4007f838256454ab3fe9475862618c 19076 libs optional 
libaio_0.3.110-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWCqp2AAoJELlyvz6krlejF5kP/jM7k4Mr4I8PI2DJkAbThE7A
kDc73/6pn2xpZJF4ByaO8qagMxBFJclV7nvC9v2K4K2KPvZ4B6p4HmHBoSwV9KdQ
JOkPzC8ME4cZkfWZ26iGUF/VQacY1+CyVt6mxJDYKf55yDxF11+pu7/rcw3zB2GV
QWVrUo662SKdo6RAlgfip0aXouirVoJcTY7v4Gj++p4Pavh/64bp1sdznE3dkElF
bUL891/MEWWw2VMVwslgA+q1SdMBjLlQhdTTxxOVMpNRXesuZSO/Kq9jCyCPOexZ
AzJdv2/rmSt0xox3BSBmKNpaHw7WNiFy9CcOVcahnbraSoTdPMPBClQdbxy2YuGE
qnxoZGOLUXxbMvWXkukzgTg5DUKrWsVTQOAtMyhGRZyCqNRy2oii9sHY1Y5L50h/
giPn911iwEf8wi3B5fshKTjBSAf8KIsLhx+mYemzQAQN5ljq+V3BCfmN9Z04oQqM
e2vdRdNgxex5eLsbvDqmhF6oJjy+erXePYelixx3z6dALMKIzFgE+1GPhpdCL3YM
g21XXV8fz2vf9MuMiAnoOfjt2H74+5i0lGVEYTKmLYN4YCDMA4ROUhYhy6/F/UVf
xtufmTgdy5c3DocpvJO9CquirC4qIPqxdJntscYTF3+dZ8nAKzcUH3ljWDGkv1ls
qJkZ1y6RXB3jzjBz5USq
=Xh24
-END PGP SIGNATURE-

Re: Bug#800093: ITP: libdpkg-parse-perl -- module to parse various dpkg files into Perl Objects

[Guillem Jover]

Hi!

On Sat, 2015-09-26 at 21:12:57 +0300, Andy Beverley wrote:
> Package: wnpp
> Owner: Andy Beverley 
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
> 
> * Package name: libdpkg-parse-perl
>   Version : 0.03
>   Upstream Author : Adam Jacob 
> * URL : https://metacpan.org/release/DPKG-Parse
> * License : Artistic or GPL-1+
>   Programming Lang: Perl
>   Description : module to parse various dpkg files into Perl Objects
> 
> DPKG::Parse contains utilities to parse the various files created by dpkg and
> turn them into helpful Perl objects. Current files understood by various
> DPKG::Parse modules:
> 
> /var/lib/dpkg/status - DPKG::Parse::Status
> 
> /var/lib/dpkg/available - DPKG::Parse::Available
> 
> Packages.gz - DPKG::Parse::Packages
> 
> See each module's documentation for particulars - You should not be calling
> DPKG::Parse directly.

What's the advantage of this over the various modules in libdpkg-perl?

Thanks,
Guillem

Accepted dpkg 1.18.3 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 21 Sep 2015 07:11:42 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source
Version: 1.18.3
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-d...@lists.debian.org>
Changed-By: Guillem Jover <guil...@debian.org>
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 794688 794694 794977 795936 796283 796671 798324 798369 798370 798371
Changes:
 dpkg (1.18.3) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Fix short-lived memory leaks in start-stop-daemon. As a side effect now
 a missing group after ‘:’ on --chuid is a fatal error.
   * Print the master and slave links in «update-alternatives --display».
   * Print the current best alternative in the head instead of the trail
 in «update-alternatives --display», with a two space indentation.
   * Reimplement «update-alternatives --all» as a fully built-in command
 instead of executing itself with --config per subtask.
   * Reimplement «update-alternatives --set-selections» as a fully built-in
 command instead of executing itself with --set or --auto per subtask.
   * Add kfreebsd-armhf support to ostable and triplettable. Closes: #796283
 Thanks to Steven Chamberlain <ste...@pyro.eu.org>.
   * Fix «dpkg --verify» with --root.
   * Fix an off-by-one write access in dpkg-deb when parsing the .deb magic.
 Reported by Jacek Wielemborek <d33...@gmail.com>. Closes: #798324
   * Split overlong perl regexes into multiline extended regexes.
   * Switch dselect multicd method license from GPL2 to GPL2+, with consent
 from all its authors.
   * Fix inadvertent license change for lib/dpkg/utils.c from GPL2 to GPL2+.
   * Fix segfault when using «dpkg --no-act» with a synthetic --admindir.
 Reported by David Kalnischkies <da...@kalnischkies.de>.
   * Perl modules:
 - Only warn on invalid week days instead of aborting in
   Dpkg::Changelog::Entry::Debian. Regression introduced in dpkg 1.18.2.
   Reported by Jakub Wilk <jw...@debian.org>.
 - Do not warn when removing an empty subdirectory on source package
   extraction in Dpkg::Source::Package::V2. Closes: #796671
 - Do not abort on parse errors from Time::Piece->strptime() for the
   changelog trailer date, just queue them so that the caller can decide
   if they should be warnings or actual errors. Closes: #795936
 - Validate the changelog trailer date, and catch and warn or error on
   bogus month names, such as unknown or unabbreviated ones.
   * Test suite:
 - Get the reference build flags from dpkg-buildflags.pl, instead of
   hardcoding them, which might not match depending on the architecture.
   Closes: #794694
 - Delete any environment variable starting with DEB_ in mk.t that might
   affect the test results.
   * Build system:
 - Add a new --with-devlibdir configure option for the C libdpkg library.
   * Packaging:
 - Remove unneeded --sourcedir options from dh_install calls.
 - Use the new --with-devlibdir configure option to only switch libdpkg-dev
   files to the multi-arch directory. Closes: #794977
   * Documentation:
 - Fix typos for --predep-package option name. Closes: #794688
 - Add missing dashes to package-list in deb-src-control(5).
 - Mark each individual required field as such, instead of using segregated
   sections.
 .
   [ Updated programs translations ]
   * Catalan (Jordi Mallach).
   * French (Sébastien Poher). Closes: #798371
   * German (Sven Joachim).
   * Vietnamese (Trần Ngọc Quân).
 .
   [ Updated dselect translations ]
   * French (Sébastien Poher). Closes: #798370
 .
   [ Updated scripts translations ]
   * French (Sébastien Poher). Closes: #798369
   * German (Helge Kreutzmann).
 .
   [ Updated manpages translations ]
   * German (Helge Kreutzmann).
Checksums-Sha1:
 5d9b6ea29328c98d2362e13f3bfb8f13b72618ff 2021 dpkg_1.18.3.dsc
 fa70b3ed84d8ed678a85b64a37f2a787cc678f26 4359884 dpkg_1.18.3.tar.xz
Checksums-Sha256:
 472d01b4be4ac80f4f8b50b3cbbed07c23728fc1014d283eab5e9281896616a7 2021 
dpkg_1.18.3.dsc
 a40ffe38d7f36d858a752189a306433cfc52c7d15d7b98f61d9f9dd49e0e4807 4359884 
dpkg_1.18.3.tar.xz
Files:
 69573ae1565f820c925572e2c5bf253b 2021 admin required dpkg_1.18.3.dsc
 a5ca138121cc37c8fb0083462a3b4d47 4359884 admin required dpkg_1.18.3.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV/5mpAAoJELlyvz6krlejXNIP/iirqbBKyKiM7zVidtNPwnR9
qGhxBcCJSPwamSlxc0eROtIOA0QiC7VBxr4Zl/HefwauOGDnrtFAw05lcO8BT/NU
0YMLP8GuWvi2/+q4/cltHk821M6+IR+13dGkhrMagoJR5FaXPz4zQ+L7DP+M2VM5
T50uvjw9xS9kofF/6caywEkitY9bzm843kW+Bk+qOF2is6uBp+kqY9JQj+egLS9a
nzLFjZg919DNimGr9MZZXSSxf

Re: Improving your archive and package system for small package

[Guillem Jover]

Hi!

On Thu, 2015-09-03 at 13:26:12 -0700, Josh Triplett wrote:
> Jonas Smedegaard wrote:
> > Seems Osamu Aoki is working on at least part of the puzzle:
> > https://bugs.debian.org/797045
> 
> Merging multiple sources *really* shouldn't be necessary.  And the
> metadata for those sources will vary, so that likely won't save that
> much space.

Well, there seems to be different kinds of overhead when it comes to
extremely tiny packages (those with dozens or hundreds of lines of code).

Metadata is one, amount of packages on the distribution, installed systems
and files on the mirrors is another one.

All the above involve in one way or another some overhead on at least
the amount or size of source packages, binary packages, Sources and
Packages indices, package manager databases and possibly increased
dependency complexity, usage on disk after installation, inodes used
on mirrors or installed systems, number of source VCS, etc.

This can have a cost on the mirror network, buildds, on any team doing
distribution wide work, such as the ftp-masters, release, porter, QA or
reproducible teams, tools like lintian, autopkgtest, DUCK, VCS or watch
checkers, britney, botch, etc. On maintainers having to maintain hundreds
of similar tiny packages.


Doing package collections in Debian might reduce part of the above
overhead, but *if* this needs fixing, ideally it should be fixed
upstream. Having to package 100 new upstream release updates instead
of one is significant work, and that cannot be easily skipped if
upstreams do not do the conglomeration themselves.

> Perhaps we should add a few more things to common-licenses, or figure
> out if our packaging metadata could be further reduced or de-duplicated.
> It should be possible to package a 1kB library without several kB of
> overhead.

There are certain things that we could do to reduce overhead in some
places, I don't think we can easily reduce most of the overhead
anyway. For example each source and binary package contain a
changelog, that's usually what takes most space. Even if we went
with my proposal to store that and the copyright files in the dpkg
database, that might only reduce some overhead on installed systems.

> But even if we have to pay that overhead, so be it; we have
> tens of thousands of packages already, what's a few hundred more tiny
> JavaScript packages as long as they're actually used?

If we were talking about few hundred packages, I don't think anyone
would have much of an issue, I guess what people are worried about is
this setting precedent and opening the flood gates. That's probably
one of the reasons people have not tried to inject much of CPAN or CRAN
or similar upstream archives into Debian even if I don't think those
are as tiny as the ones proposed here, and most of it could be automated
for example.

Thanks,
Guillem

Re: Improving your archive and package system for small package

[Guillem Jover]

Hi!

On Thu, 2015-09-03 at 17:28:38 +0200, Adrien CLERC wrote:
> This may have been discussed before, but could we achieve something like
> this with virtual package?

With the implemented version Provides, which means having versioned
virtual packages, this is actually probably a good solution, either
to pack a collection of different upstream projects or a collection
of versions for the same upstream project.

Thanks,
Guillem

Re: Facilitating external repositories

[Guillem Jover]

Hi!

On Mon, 2015-08-17 at 09:53:17 +0200, Wouter Verhelst wrote:
 A repository with a whitelist cannot install packages with names outside
 that whitelist. It should also not be able to have packages with
 Provides: or Replaces: headers outside that whitelist (so you can't ship
 a package that claims to provide libc6). Since you cannot overwrite
 other packages' files without Replaces:, you can't have a Package:
 libbeidlibc6 which contains a file shipped by libc6.

You can use dpkg-divert, or triggers + moving files around from
maintscripts, but the latter would probably be really dodgy. :)

Regards,
Guillem

Accepted libpmount 0.0.17-1 (source amd64) into unstable, unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 13 Aug 2015 00:34:27 +0200
Source: libpmount
Binary: libpmount-dev libpmount0
Architecture: source amd64
Version: 0.0.17-1
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 libpmount-dev - portable mount library - development files
 libpmount0 - portable mount library - shared library
Changes:
 libpmount (0.0.17-1) unstable; urgency=low
 .
   * New upstream release.
 - Enable LFS.
 - Add genisoimage to Build-Depends, required by the test suite.
 - Rework debian/rules for the new upstream build system.
 - Switch source package to «3.0 (quilt)».
 - Rename libpmount0.0 to libpmount0.
   * Remove packaging history from debian/copyright.
   * Switch debian/copyright to machine-readable format 1.0.
   * Switch to debhelper compatibility level 9.
   * Now using Standards-Version 3.9.6 (no changes needed).
   * Add upstream Homepage field.
   * Add a watch file.
   * Update packaging Vcs field URLs to their new location, and switch to
 use the cgit web interface.
   * Make library packages multiarch:
- Mark libpmount0 and libpmount-dev as “Multi-Arch: same”.
- Define DEB_HOST_MULTIARCH and use it to set libdir.
- Change paths from lib/ to lib/* in install files.
Checksums-Sha1:
 c3549d75a0ee5d65ff84d515ca60d44287e94452 1944 libpmount_0.0.17-1.dsc
 48bbd39bb11b0b2ebccb10e98c4808b387cf75b0 225132 libpmount_0.0.17.orig.tar.xz
 f3a7ad938033c3c1c69cd2493725cade723e5352 8956 libpmount_0.0.17-1.debian.tar.xz
 ad0d8894d1d810c83bdc2e3ed612b8a6de77e039 14940 libpmount-dev_0.0.17-1_amd64.deb
 8974a04cd6a4349cf7ad3f0f64e88f9801d24407 15456 libpmount0_0.0.17-1_amd64.deb
Checksums-Sha256:
 241a7a79eef9257b66f1d69f400cc92b97a00d94e8df6632c329edab1627c877 1944 
libpmount_0.0.17-1.dsc
 8e5fe47301c57c0d42d9d7c65b40474d2c1bb146d99fc35793f2ecb47a547cd2 225132 
libpmount_0.0.17.orig.tar.xz
 6b1c2ab836eca3145dce4f080d4e457fe66b16ab9a052ef0635238a3b9446a70 8956 
libpmount_0.0.17-1.debian.tar.xz
 dcda120f537a803803515833195abb87bb6add2b14bea22f7282c8fbe73b086e 14940 
libpmount-dev_0.0.17-1_amd64.deb
 5fae0df13e5e49e42e39831d1f62d26075ca74d8d933e5006261e6167f5d9219 15456 
libpmount0_0.0.17-1_amd64.deb
Files:
 685d3d440b45b66f181e7750c9d90721 1944 libs optional libpmount_0.0.17-1.dsc
 d63fbf5634c6f82ea1479eb902def4a3 225132 libs optional 
libpmount_0.0.17.orig.tar.xz
 425637320aea662c5164cc869ad2bd62 8956 libs optional 
libpmount_0.0.17-1.debian.tar.xz
 c07b432fc8ea1f2ebc488f19a49e828f 14940 libdevel optional 
libpmount-dev_0.0.17-1_amd64.deb
 e13d26aec0080b7b242d15f62551436d 15456 libs optional 
libpmount0_0.0.17-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVy9dOAAoJELlyvz6krlejnAcP/iSEJfMY0Fi40Bk+eboTp2OF
xO2Cs0HoY9u3531lC/XRgr1Dn5JqEIg6mYRlH0+kybpJFpCzc4haAp3srvCkxQ6S
MN6oQcCxxgqyNMBOVY3A42Rlyy+55Zg10Kpx5cfGY4jpZln31/El/k1aI1ZYMQeV
EiW/xOsq+Y1NkqLOXI2wlPMsh/p3jhcfYxB9THHrl8Yig3RXDvoIIi9qrIHVnRw0
7/x2DuDREnEorx6MBQBaEpOJALNn1L7bYg2lTjvFqlsw8uIxNDFQ22ROS3kHUEzJ
QIIUyoq7ElCosN8VIAvhU4yJNxSKDvS+Idso+I9EzXTGUUaTpSK4l/Hrmj+mYIZk
rV4tFKnmyQuBASKMVLEx4WvsAeq9jhDkHC/ly/otW92dVo3y0w42LyCcUr7Q0wkW
3Gefk0KLqnFrfoy9nsaHolVq3yMyqtZOrHDAJeHvOUOhePMG+fweTljbKpp3GwDc
q2i5L8arV1czogbx9JZVbPpEkRvAU4r7Lwum49LUDKFZuwGv8QEbC6JMVE7xydHl
GWmyQXVcf6294GaciYmZorvmmriQncqIfnGf+CrkaP30hMVw176GcQwEJxDYSNZX
cBi0w5LqirTGLwCmzyne6oDpttMzxYYPbjFMCfoid1h7vSFt6YwmK9WtCe86lZZF
xYIJqvJ3yFyzv+N47urw
=1SBp
-END PGP SIGNATURE-

Accepted unace 1.2b-14 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 11 Aug 2015 04:30:18 +0200
Source: unace
Binary: unace
Architecture: source
Version: 1.2b-14
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 unace  - extract, test and view .ace archives
Changes:
 unace (1.2b-14) unstable; urgency=low
 .
   * Enable LFS, using getconf to pass the correct build flags.
Checksums-Sha1:
 52df24bdf96a42772f325522505475322e72b112 1736 unace_1.2b-14.dsc
 e6ce2071b13f1c05400db21a4d449122e9d52b1b 8048 unace_1.2b-14.debian.tar.xz
Checksums-Sha256:
 226532e182b319c4f2331a7a23a3e45bccb5889dfe6eb904ef1abf95496498b8 1736 
unace_1.2b-14.dsc
 da785294b01f6a44075f14f130ff9ad8e7854a12f613225fb2cc43bdadec4715 8048 
unace_1.2b-14.debian.tar.xz
Files:
 00905b8319aff57812bbb1ce287378c0 1736 utils optional unace_1.2b-14.dsc
 4a7be2f7a9e5778153b904af86e2e7b2 8048 utils optional 
unace_1.2b-14.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVyV8VAAoJELlyvz6krlej5y8QALwSqQ+0RLDJEHE5M8AiOBgB
evnEXnTO6JrpxEwCS8z1wbi1valadNWcXT+jn2yGOP8e7759O+Wqv2lHsYkM2OLH
57jUHZpo4wCf8RSSyqKmxVNSmDkKOO6ZufEKW9v27eERRBw7FwSGQM439ACcdwLi
fgCv87uRhNsJPQNNcPBWMNUnGpMst7zjDELgEN3VMfVKeEFpnTEL5cYXqBab4MRO
Epsmc80pu26fBHicTLY5InwR7vV3jzB4q8K08WApLTZOlN1G20lryKL5taaaD4Kq
hrOeLKi2zKk3qSmrXXDAvaozR7Dwo5M3vfiJ4sTL4VBppxhjup3xSH6zWEZb8jHW
nlYgKIgeFbFLvfTNYWR0Q6w2R1NTCvLrn52zzPz0rX1QjELRjFSWK68RWkdSrG1R
4X8WzHOXz1zMrRQPC5S7VDC7hx5kjoehmz4lGR1MJwlJRiFhmQOSyQO59BnN0ejY
JXyZquSAYqvaeZ0rfmVdYvskJyHblislQlpUP+bB2BUdeAh8szXUd5S8uI9h64bw
8U1eX60NfzRcx/wlyeaxMCcDLV0si9pKOaCUmZSa7AUszWm96KLz3A/sG8+Y0V5J
3Ow8fPoJLKkko7ayExEg+kUQ53nU9zqM9/WtoQnuNsXzN7zStP+MDqSosf33rkuU
zG6TrOhUmsYUm6OKjz5o
=gJ2i
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1zp0ln-0007lc...@franck.debian.org

Accepted xfstt 1.9.2-1 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 11 Aug 2015 04:04:19 +0200
Source: xfstt
Binary: xfstt
Architecture: source
Version: 1.9.2-1
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 xfstt  - X Font Server for TrueType fonts
Changes:
 xfstt (1.9.2-1) unstable; urgency=low
 .
   * New upstream release.
   * Use https for the copyright Format URL.
   * Switch Vcs-Browser to a cgit URL.
   * Move Debian specific LGPL-2.1 filesystem location in debian/copyright
 to a Comment field.
Checksums-Sha1:
 ff4fbd57928eab3c55cd65ecec7d515153134326 1852 xfstt_1.9.2-1.dsc
 08acb4459eb6a9222a630f6871eda0682e618273 213816 xfstt_1.9.2.orig.tar.xz
 2aa6b71e95adc9ce4bd126c56a55ba8fd0a15d6f 23652 xfstt_1.9.2-1.debian.tar.xz
Checksums-Sha256:
 465db196da660ec74ed2ffaf2f53982b76cc1427d489d8af9a59db59265922a8 1852 
xfstt_1.9.2-1.dsc
 798a0071719ef302b67abd04652dae9bbe8ae9b9dc497fc6d3360fca7eded46d 213816 
xfstt_1.9.2.orig.tar.xz
 4f3c6ccc8ab736fefcea885d84873ee3bb86ce3708e67f5eb033912ff174279e 23652 
xfstt_1.9.2-1.debian.tar.xz
Files:
 5f647864873405e93a1633bcc5474c3d 1852 x11 extra xfstt_1.9.2-1.dsc
 1fe93643d7b97e4eb073914891996e6a 213816 x11 extra xfstt_1.9.2.orig.tar.xz
 e7f70dacb44a8c46b1c1347879a2cb5a 23652 x11 extra xfstt_1.9.2-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVyVyAAAoJELlyvz6krlej8hgP/02eF07VvDVm+YNIXVLv66kh
37LZZP6XVjhlcri1siPXCO2zyv5Jk10zkO8BmmbBWoKhToxghsw9yIz31V3dvJ/f
7Y5jL/JzbMXvw4Qh3viga2YL0pxA05Mhznmy2WBTqBN+/+ehn/kbjid++Vd//sbr
87PzTq8B92lyU61/nCamIhcVgt1cFoRgHKXMLNElSuw+aL3HrsGD5RqPUu1Dtu60
ek6fbtr8cKK5ZBxDn6j2DKc3qd2nNDbOzw4C014mVK9rWoRUvod1JXNr7RRgAJHO
iZtl7NZ+Yhdn1mV+xIEh26yfkmWh49E/65L6cIYRLyBqaWsh5dDkwQJ6YQUPKyS2
zhacPBYxvo/X4Fa2sBb2oO3/WOynxO+WpE9eonB6fmmvwwvnqegp/2ID5F2Mcl84
TDP5h6w/TRBlYV8Qy+8iEbbAcRtBNFmskTm6eQ0iStlCyGo9ItPjSxtRFZBB/I8u
ta0+hRUk9g8rUlJxC731WAyDGCzY97ued27eF06l/zNiYxWrEgxTbfnVQLhqGXom
ayuvgL+nqgS/uqqBU6ePdFOvyU3sT4vVReemDLpH1RTjT3d9OIaokh5tKKfpfIDW
iWqKvrjn8dxSeIyrrbcgnGT8m2QEkUd+mQWA34WcbHkEk1PAGO358VlOA+bWhYc+
SM+/hccJj0E12Mxxwrdd
=nECF
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1zp0lt-0007mf...@franck.debian.org

Accepted dpkg 1.18.2 (source all amd64) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 03 Aug 2015 15:40:21 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source all amd64
Version: 1.18.2
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers debian-d...@lists.debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 480638 571671 785344 787616 787986 788211 788819 789096 789097 789580 
789957 790025 790073 791535 792491 793330
Changes:
 dpkg (1.18.2) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Fix plural form translations for single plural languages. Closes: #790025
   * Add new dpkg-buildpackage -J option, which is a safe version of -j.
   * Fix dpkg-gencontrol to add correct binary filename to debian/files,
 even when overriding the Package field value with the -D option.
 Reported by Niels Thykier ni...@thykier.net.
   * Move the implicit build-essential:native Build-Depends from
 dpkg-checkbuilddeps to a new vendor hook, as it is Debian-specific.
   * Add support for ignoring built-in build dependencies and conflicts
 with the new «dpkg-buildpackage --ignore-builtin-builddeps» and
 «dpkg-checkbuilddeps -I» options. Closes: #480638, #571671
   * When sys_siglist is defined in the system, try to use NSIG as we cannot
 compute the array size with sizeof(). If NSIG is missing fallback to 32
 items. Prompted by Igor Pashev pashev.i...@gmail.com.
   * Use string_to_security_class() instead of a literal SECCLASS value in
 the setexecfilecon() libcompat function, as selinux/flask.h is now
 deprecated.
   * Switch libdpkg xz compressor to use CRC64 for integrity checks, to match
 the default on the command-line tool, which should provide slightly better
 detection against damaged data, at a negligible speed difference.
   * Only use the SHELL environment variable for interactive shells.
 Closes: #788819
   * Move tar option --no-recursion before -T in dpkg-deb. With tar  1.28 the
 --no-recursion option is now positional, and needs to be passed before
 the -T option, otherwise the tarball will end up with duplicated entries.
 Thanks to Richard Purdie richard.pur...@linuxfoundation.org.
   * Add an extra level of escaping for double $(evals) in architecture.mk
 and buildflags.mk, so that the variables are computed lazily again.
 Regression introduced in dpkg 1.16.2. Closes: #793330
   * Add binary packages Essential information to Package-List field in the
 .dsc file, as optional essential=yes entries. This allows precomputing
 the pseudo-essential set before starting an architecture bootstrap.
   * Perl modules:
 - Remove non-functional timezone name support from
   Dpkg::Changelog::Entry::Debian.
 - Use Time::Piece (part of the perl core distribution) instead of
   Date::Parse in Dpkg::Changelog::Entry::Debian. This reduces the build
   and run-time dependencies, and helps architecture bootstrapping.
 - Simplify distribution splitting in Dpkg::Changelog::Entry::Debian.
 - Add new function changelog_parse_plugin() in Dpkg::Changelog::Parse.
 - Add new function changelog_parse_debian() in Dpkg::Changelog::Parse, and
   use it in changelog_parse() instead of the external plugin parser when
   the input format is “debian”. This significantly speeds up the parsing.
 - Remove trailing space before handling blank line dot-separator in
   Dpkg::Control::HashCore. Regression introduced in dpkg 1.18.0.
   Reported by Jakub Wilk jw...@debian.org. Closes: #789580
 - Allow the Maintainer field in CTRL_FILE_STATUS.
 - Import make_path from File::Path in Dpkg::Source::Package::V2.
   Regression introduced in dpkg 1.18.0. Closes: #789957
 - Make the BinaryFiles subpackage self-contained by explicitly importing
   File::Spec in Dpkg::Source::Package::V2.
 - Do not exclude pre-existing symlinks when unpacking the debian/ tarball
   in Dpkg::Source::Package::V2. Closes: #790073, #791535
 - Disable the thread sanitizer when the address sanitizer is enabled
   in Dpkg::Vendor::Debian as these are mutually incompatible, and make
   sanitize=+all not work at all.
 - Allow colons (:) in added filenames in Dpkg::Dist::Files, which can be
   present when the upstream version contains colons. Regression introduced
   in dpkg 1.18.0. Reported by Jakub Wilk jw...@debian.org.
 - Future-proof tar invocations in Dpkg::Source::Archive for options that
   might become positional in the future, and by always placing function
   options first.
 - Make the dependency comparison deep by comparing not only the first
   dependency alternative, to get them sorted

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

[Guillem Jover]

Hi!

On Wed, 2015-05-13 at 14:21:54 +0200, Guillem Jover wrote:
 On Tue, 2015-05-12 at 10:02:27 +0100, Jonathan Dowland wrote:
  On Mon, May 11, 2015 at 08:40:16PM +0200, Guillem Jover wrote:
   $ make -jN -f debian/rules build
   
   and
   
   $ DEB_BUILD_OPTIONS=parallel=N debian/rules build
  
  I prefer the latter behaviour but the former brevity. Would you consider
  something like -J in dpkg-buildpackage adjusting parallel= in
  DEB_BUILD_OPTIONS, and perhaps in the future phasing out -j?
 
 Sure, adding either an option to disable the forced parallel runs in
 combination with -j, or a new option such as -J seems fine to me.

I've now pushed a patch to dpkg git master that adds -J to
dpkg-buildpackage, will be included in the upcoming dpkg 1.18.2.

Thanks,
Guillem


-- 
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/20150730044738.ga2...@gaara.hadrons.org

Bug#793404: massive waste of CPU time in debian/rules by inline commands

[Guillem Jover]

Control: block -1 by 657390

[ Blocking on that, because there's currently no other such bug. So
  not to imply this is lintian maintainers sole responsibility. ]

Hi!

On Fri, 2015-07-24 at 12:19:36 +0200, Jakub Wilk wrote:
 dpkg-buildpackage -B will run debian/rules 4 times: once to determine if
 build-arch exist, and once for every target: clean, build(-arch),
 binary-arch.

Ideally the first would disappear though. Please see the blocking bug
report for a tentative plan on how to do so.

Thanks,
Guillem


-- 
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/20150724143301.ga32...@gaara.hadrons.org

Re: Facilitating external repositories

[Guillem Jover]

Hi!

On Sat, 2015-07-25 at 11:10:25 +0800, Paul Wise wrote:
 I would suggest reviewing Ubuntu's solution for adding PPA sources.list
 snippets and seeing if we can take any inspiration from it or make our
 solution more compatible with it.
 
 https://help.ubuntu.com/community/Repositories/Ubuntu#Adding_PPAs
 
 I'm not aware of any other solutions from derivative distros, but you
 might want to contact the debian-derivatives list to find out.

Maemo's Hildon Application Manager did have support for one-click
installs of packages and repository information:

  http://hildon-app-mgr.garage.maemo.org/install-devel.html

Thanks,
Guillem


-- 
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/20150725040021.gb9...@gaara.hadrons.org

Re: LFS status, and enabling it opportunistically on next SONAME bump

[Guillem Jover]

Hi!

On Tue, 2015-07-21 at 19:00:18 +0200, Niels Thykier wrote:
 The tag being experimental is orthogonal to its severity.  If you are
 interested in seeing it become a non-experimental tag, I can recommend
 having a look at writing a patch for #787853.  From memory, the
 information needed is already collected.  It just need to be used (bonus
 for a test case too).

Thanks to Sebastian for preparing a patch!

 As for the severity: Surely, it could be bumped, but given it is not a
 tag people can always trivially fix (possibly breaking ABI is not my
 definition of trivial), I am not necessarily convince it is in our
 best interest to be very loud with this tag.  That said, I can be
 convinced otherwise as long as it does *not* lead to blindly fixed
 lintian tag syndrome.

Perhaps it could be bumped for binary packages that do not contain any
shared library, but I'm assuming that is not currently possible(?).

In any case, even packages that do not trigger the lintian warning are
not guaranteed to be LFS-safe, this needs either testing or code review.

Thanks,
Guillem


-- 
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/20150725035449.ga9...@gaara.hadrons.org

Bug#793404: massive waste of CPU time in debian/rules by inline commands

[Guillem Jover]

Control: block -1 by 793330

Hi!

On Thu, 2015-07-23 at 19:43:46 +0200, Eduard Bloch wrote:
 Package: general
 Severity: minor

 The problem: I see lots of $(shell ...) stuff. In boost, there are about
 12 such calls. And they run dpkg-architecture or dpkg-parsechangelogs or
 similar commands. When this was done a just couple of times (i.e. before
 dh(7)), that's acceptable. But now, it looks like debian/rules is called
 many, many times through dh. Making many, many calls of that inline
 commands. Wasting many, many CPU cycles. All that just to retrieve the
 same information all over again.

There are multiple culprits that pile up here:

1) The /usr/share/dpkg/architecture.mk and /usr/share/dpkg/buildflags.mk
   lazy and caching value initialization is not effective. I had noticed
   it but had not yet checked if it was a problem with the makefiles or
   in make, etc. It appears is a bad interaction with the foreach, which
   defeats the lazy and cached evaluation. I guess I'll try to make the
   foreach work, or revert to an unrolled implementation.

2) debhelper's Dh_Lib.pm does not try to use existing dpkg-architecture
   variables from the environment. Those should not be expected to be
   present, but when using dpkg-buildpackage they will be present so it
   would be an optimization. I'll file a bug report about this.

3) Slow dpkg-parsechangelog implementation and usage:

 In the emulated m68k environment, it spends about half an hour (guessed,
 not measured) before starting the actual build, doing things like:
 
 |  \_ /usr/bin/perl -w /usr/bin/dh build --with python2 --with python3
 |  \_ /usr/bin/make -f debian/rules override_dh_auto_configure
 |  \_ /bin/sh -c dpkg-parsechangelog | grep Version | cut -d' ' 
 -f2
 |  \_ /usr/bin/perl /usr/bin/dpkg-parsechangelog
 |  |   \_ /usr/bin/perl /usr/lib/dpkg/parsechangelog/debian 
 -ldebian/changelog --file debia

3.1) As mentioned in the thread, callers can avoid the other shell
 commands and pipes by using -S.

3.2) debian/rules (or debhelper/cdbs) will still call the program for
 different changelog values. But dpkg-buildpackage has to parse the
 current and previous entries anyway, so we could preset values for
 those in the environment that could opportunistically be used by
 debian/rules and debhelper/cdbs. A possible drawback is that
 packages might accidentally rely on those variables w/o setting
 them beforehand.

3.3) dpkg-parsechangelog supports other changelog formats, and those
 are implemented by external parsers. This means it needs to scan
 the changelog twice, and then parse+output+parse the data from
 the parser. I've already implemented an optimization (to be
 included in dpkg 1.18.2) when forcing the format to be debian,
 that uses a builtin parser, which halves the execution time.
 «dpkg-parsechangelog -Fdebian». I guess I can take this further
 and use the builtin parser whenever the format is debian.

And probably some others…

Thanks,
Guillem


-- 
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/20150723232012.ga32...@gaara.hadrons.org

Re: Huge data files in Debian

[Guillem Jover]

Hi!

On Fri, 2015-07-17 at 12:03:36 -0400, Yaroslav Halchenko wrote:
 On Fri, 17 Jul 2015, Ole Streicher wrote:
  But: These packages sum up to ~25 GB, with the maximal package size of
  3.5 GB. What is the best way to deal with them? Loosely following the
  discussion about the Icedove icons, it is probably not a wise idea
  (privacy breach) to let them downloaded from a third party server; at
  least as long as they are DFSG-free. But can (and shall) our Debian
  servers store these files? Is 25 GB much for us or not these days?
 
 Unfortunately it is unlikely that we (as Debian) would be able to
 afford providing generic storage and distribution of such large data
 packages.  It just wouldn't scale -- where would be a cut off? (some
 datasets we deal with in neuroimaging are already tens of TBs)

 But also it is not just about storage -- conventional organization
 (.orig.tar.* + .deb) with data being duplicated in both doesn't scale
 well as well.

In addition, the .deb format has some size limits. Each tar entry is
currently limited to 8 GiB (but it should be 16 EiB, which I'll be
fixing soon), and each ar member is limited to around 9536.74 MiB
(which is inherently unfixable).

And not even all current code handling .deb handle current LFS,
https://wiki.debian.org/Teams/Dpkg/DebSupport.

 The ultimate solution we are aiming for (see http://datalad.org for more
 information) is to utilize git-annex and ship either mere pointers to
 git-annex sources or lean (without data) git-annex repositories which
 fetch data from original (or mirrors) data providers.
 
 Meanwhile, we (http://neuro.debian.net) have started to use git-annex to
 at least avoid bloated .orig.tar.gz, see e.g.
 http://neuro.debian.net/pkgs/python-mvpa2-tutorialdata.html
 sources: http://git.debian.org/?p=pkg-exppsy/pymvpa2-tutorialdata.git
 
 So, .orig is in 3.0 (git) format and is just a lean annex repository.
 When building a binary packages then load gets fetched, and brought into
 .deb binary packages.

Oh, then I think this settles #720598 (requesting the removal of the
«3.0 (git)» source format) for now, and knowing that it's being used
I'll just close the request. :)

Thanks,
Guillem


-- 
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/20150718030145.ga25...@gaara.hadrons.org

Re: Timezone name in Debian changelog format

[Guillem Jover]

Hi!

On Fri, 2015-06-26 at 10:56:58 +0200, Santiago Vila wrote:
 On Fri, Jun 26, 2015 at 04:40:58AM +0200, Guillem Jover wrote:
  So given that the timezone name has never been accepted, many
  time-parsing functions ignore it, it is redundant, declared obsolete
  by RFC5322 and Debian policy dropped an explicit reference to it due
  to bug 569174. I'd say we should just drop it instead of fixing the
  regex. Comments?
 
 Go ahead. As you have just shown, there are plenty of good reasons to
 drop it and little to keep it.
 
 [ I did a little experiment and could not find a single timezone name
   in my 18 years of changelogs ].

Ok, thanks, I've queued the patch for dpkg now, and filed bugs with
patches to remove support for timezone names for the other packages:

On Fri, 2015-06-26 at 04:40:58 +0200, Guillem Jover wrote:
   libparse-debianchangelog-perl: Parse/DebianChangelog.pm

  #792414

   python-debian: lib/debian/changelog.py endline and endline_nodetails

  #792415

   po4a: lib/Locale/Po4a/Text.pm parse_debianchangelog

  #792416

   root-system: build/package/lib/makerpmcl.pl

  #792417

Thanks,
Guillem


-- 
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/20150714160334.ga4...@gaara.hadrons.org

LFS status, and enabling it opportunistically on next SONAME bump

[Guillem Jover]

Hi!

Our Large File Support on some 32-bit architectures is a bit poor, and
this has been going on for a while now:

  https://lintian.debian.org/tags/binary-file-built-without-LFS-support.html
  (Although this includes some false-positives as reported in #787853.)

In addition, the problem is actually worse than it seems, because even
programs that might not need nor usually have to read and handle large
files, might still fail, if they have to operate on files with large
metadata values, like inode numbers for example. A simple stat(2) on
a file might fail on a filesystem with large inode numbers, even if
the file is otherwise not large.

  (I've filed #792167 to clarify the above in the lintian tag description.)

If you've got one such package please consider enabling LFS, and if you
maintain a shared library that might need to bump its SONAME soon, for
example due to the gcc-5 transition, please use the opportunity to also
try to enable LFS at the same time. Shared libraries might not break the
ABI when enabling LFS, but doing so when bumping the SONAME means even
if they would break the ABI, it will be fine.

This still will not guarantee that LFS works, as an underlying shared
library might still not have LFS enabled, or any of the other problems
listed in the lintian tag might remain, but it's better than nothing
I guess.

Thanks,
Guillem


-- 
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/20150712173723.ga29...@gaara.hadrons.org

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Guillem Jover]

Hi!

On Wed, 2015-07-08 at 16:45:12 -0400, Sandro Tosi wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Sandro Tosi mo...@debian.org
 
 * Package name: daemonize
   Version : 1.7.6
   Upstream Author : Brian Clapper, b...@clapper.org
 * URL : http://software.clapper.org/daemonize/
 * License : BSD
   Programming Lang: C
   Description : tool to run a command as a daemon

  Most programs that are designed to be run as daemons do that work for
  themselves. However, you’ll occasionally run across one that does not. When
  you must run a daemon program that does not properly make itself into a true
  Unix daemon, you can use daemonize to force it to run as a true daemon.

Does this have any advantage over start-stop-daemon?

Thanks,
Guillem


-- 
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/20150709001908.ga9...@gaara.hadrons.org

Re: Bug#790399: ITP: structlog -- tructured Logging for Python

[Guillem Jover]

Hi!

On Wed, 2015-07-01 at 02:58:41 +0100, Filippo Giunchedi wrote:
 On Mon, Jun 29, 2015 at 01:56:55PM +0500, Andrey Rahmatullin wrote:
  On Mon, Jun 29, 2015 at 10:22:30AM +0200, Adrien CLERC wrote:
   Le 29/06/2015 02:51, Filippo Giunchedi a écrit :
* Package name: structlog

   It seems to be a Python library (in the main site, I can read that it is
   used as an imported module), it should be named python-structlog.

  Not necessarily (as we are talking about the source package name).
·
 indeed, most python modules I've looked at so far don't have the python-
 prefix in their name

I've always considered this a bad practice that I'd really like, we as
a project, stopped perpetuating.

One of the most (if not the most) important resource a distribution has
to curate and arbitrate over is namespaces of many kinds, source/binary
package names, version strings, filesystem objects, exposed APIs, etc.

Here's a relevant snippet from a reply I sent on the bash8 ITP #748383:

,---
Also just following upstream when it comes to naming be it for source
or binary packages is not wise in many cases. Lots of upstreams create
packages or language modules in language silos, where those names are
implicitly namespaced by being part of that language community/portal
for example. Having Http be a perl module is fine, the same for a
python or ruby module, not so much when it comes to integrating it
in a general purpose distribution. Why should the http source package
name be the perl implementation? Even if that source provided modules
for many languages, why should it take over the canonical protocol
name for its source package? Also the source package name is really
pretty visible in many places in the distribution.

The current practice of many python modules to just use the upstream
name as the source package name is a namespace grab, wrong and unfair
to the rest of the distribution, some quick examples to illustrate:

  appdirs argvalidate audioread distlib

I wish other language teams in Debian followed the perl lead here.
`---

This also grabs the non-namespaced name for actual possible programs
for example.

I'll be filing a bug on the python-policy document to request that
binary *and* source packages be namespaced.

Thanks,
Guillem


-- 
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/20150706183930.gc12...@gaara.hadrons.org

Re: Bug#790933: ITP: drive - Google Drive tool

[Guillem Jover]

Hi!

On Fri, 2015-07-03 at 09:09:42 +0200, Sophie Brun wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Sophie Brun sop...@freexian.com
 X-Debbugs-Cc: debian-devel@lists.debian.org

 Package name :  drive
 Version : 0.2.5
 Upstream Author :  Emmanuel Odeke od...@ualberta.ca
 mailto:%6f%64%65%6b%65@%75%61%6c%62%65%72%74%61.%63%61
 URL : https://github.com/odeke-em/drive
 License : Apache-2.0
 Programming Lang: Go
 
 Description:  Google Drive tool
 Drive is a command line tool for managing data on Google drive.

drive is an extremely generic name in tech, please use something else
when packaging this, both for the source/binary packages and the
executables and other related files. Prefixing it with «google-» could
be an option, perhaps. Doing this upstream would be preferable.

Thanks,
Guillem


-- 
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/20150703194630.gb12...@gaara.hadrons.org

Accepted arj 3.10.22-14 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 02 Jul 2015 03:11:36 +0200
Source: arj
Binary: arj
Architecture: source
Version: 3.10.22-14
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 arj- archiver for .arj files
Closes: 783948
Changes:
 arj (3.10.22-14) unstable; urgency=low
 .
   * Use https for the debian/copyright Format and Source URLs.
   * Switch Vcs-Browser to a cgit URL.
   * Now using Standards-Version 3.9.6 (no changes needed).
   * Strip .comment and .note sections from executables.
   * Fix out-of-bounds read access due to an index overflow, from controlled
 input data in an archive. (Closes: #783948)
   * Enable LFS, using getconf to pass the correct build flags.
Checksums-Sha1:
 0d9e7086829771a292d208f81bbe22208532170c 1847 arj_3.10.22-14.dsc
 eb66897037ed2088061208c6ec3922aa11b9845f 16436 arj_3.10.22-14.debian.tar.xz
Checksums-Sha256:
 8a1c0fc416f7611a5647292b12d1aa0ac2374548b1ae769c7df42976b8606947 1847 
arj_3.10.22-14.dsc
 992b740d8cce5e5c5c866f625a2201514930191548ee56df27c34905ea4be665 16436 
arj_3.10.22-14.debian.tar.xz
Files:
 457cc4b250d4dabfe67895f166fc3d8d 1847 utils optional arj_3.10.22-14.dsc
 0d62aee4624329e7ac7d41126fd6ae8b 16436 utils optional 
arj_3.10.22-14.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVlJX1AAoJELlyvz6krlejt+cP/iCu3lQmNx2fzEVIFptfE2Jf
+9o/OkblfWDTvMVkemnSbuEG7ZaPFkLkzYWSAi8qwTQt3joIkVU7Icire/vtZ151
RAcrF54HW2xkzUCAOWuUBZO4aud+wfQKyHc220wj00D8Kt952Bkg63tWm6kQngsX
f/DzgsZnJ0Lr3W8J2QrrzJNcMJhKR3R+UqoTsoIA2HBV6bikEwNrSOZLmmrQdhEJ
YnxpScZStRuMOCgIETqVrftVn8Lwe9+L8dWPsaqBr/r9Tf1WGNYQIAvhmPemFQBL
k1GjUatIK5k8+sSc3nV4fJVy5ioYci6xqFMi7NqLTMApw9/0U/pmwrx2QrdWdNfG
X8zWJXXzm4eO18lJDlWApVlKa2fMAAZ18JbEE3JT5IcumbeUs0MMHvPYpwR6mmly
SajrC4/K5wqcUpvhmcgjQP9lVjg3OlE4CnnLT37dhdnbpk0uuXlpYhF2rKWSE3kD
v6D/iTK436uszZGFW826aDtHw/CBYe+kdZpslsj5ZjI1l4T90bJTSQKdQhoC0Ynr
bGVNHtdh/i0ISNfjE1RHhGrRKodIobmpss2tC+hgc4M9lvtcjPldaageN8CTTxPT
SurrQQ56T/BgtXKFrPoO6StqMXlSgXkBzpY1z6Mqxq5vUcDWrOykFBcgPSDlyOEZ
DU8h56+IxB/LSWRUO/S7
=L1hw
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1zatcp-0005cq...@franck.debian.org

Timezone name in Debian changelog format

[Guillem Jover]

Hi!

The other day, while fixing some dpkg code, I noticed that the Debian
changelog trailer regex intended to support a timezone name inside
parenthesis, like this:

 -- Name m...@example.org  Sat, 30 May 2015 03:18:43 +0200 (CEST)

is bogus (since its inception in dpkg 1.3.0, 1996-08), and it only
accepts one character. As in:

 -- Name m...@example.org  Sat, 30 May 2015 03:18:43 +0200 (C)

(Which while also “valid”, as per RFC822, they are pretty much
useless as per RFC5322.)

I also checked, and it seems that several (most?) other changelog
parsers have just copied that regex (maintainers BCCed), and suffer
from the same issue:

  libdpkg-perl: scripts/Dpkg/Changelog/Entry/Debian.pm $regex_trailer
  libparse-debianchangelog-perl: Parse/DebianChangelog.pm
  python-debian: lib/debian/changelog.py endline and endline_nodetails
  po4a: lib/Locale/Po4a/Text.pm parse_debianchangelog
  root-system: build/package/lib/makerpmcl.pl

So given that the timezone name has never been accepted, many
time-parsing functions ignore it, it is redundant, declared obsolete
by RFC5322 and Debian policy dropped an explicit reference to it due
to bug 569174. I'd say we should just drop it instead of fixing the
regex. Comments?

Thanks,
Guillem


--
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/20150626024057.ga12...@gaara.hadrons.org

Re: Allowing both cross building and using an alternative compiler

[Guillem Jover]

On Tue, 2015-06-16 at 16:07:20 +0100, Wookey wrote:
 (Guillem - I was wondering if you had any response to my post on this
 therad.

I do.

 I hope I haven't derailed your progress by asking awkward
 questions without really providing solutions. I should really take
 your suggestion and try to provide an improved version).

Well, the mail was long and a reply requires some research and thinking,
so the draft has been sitting on an open terminal for a while now. Will
try to get back to it soon. :)

Thanks,
Guillem


-- 
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/20150626033217.ga31...@pulsar.hadrons.org

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

[Guillem Jover]

Hi!

On Tue, 2015-06-16 at 09:18:34 +0200, Vincent Bernat wrote:
 There is not a lot of documentation about how to handle that from an
 upstream point of view. There is the info page (section VERSION) of ld
 about -version-script.

That's true, there's lots of information spread all over the place, that
is either too detailed/deep, or too vague.

For example there is also:

  http://www.akkadia.org/drepper/symbol-versioning
  http://www.akkadia.org/drepper/goodpractice.pdf
  http://www.akkadia.org/drepper/dsohowto.pdf

In any case, barring better documentation or guides, using example
implementations simpler than glibc might be useful to people. So I
offer libbsd, but I'm sure there are many others. We could perhaps
even create a wiki page listing some of those pointers.

libbsd for example exposes setproctitle() with different versions.

 How a library should transition from non-versioned symbols (use of
 -version-info only) to versioned symbols?

You just switch it, code compiled against the new version will require
at least the version switching to versioned symbols, code compiled
against an older version will keep working with both.

Thanks,
Guillem


-- 
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/20150616135050.ga18...@gaara.hadrons.org

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Guillem Jover]

On Sun, 2015-06-14 at 14:08:24 +0200, Thomas Goirand wrote:
 On 06/14/2015 05:46 AM, Guillem Jover wrote:
  Well if you want reproducible output, then use the same tool version.
 
 That's not possible: Jessie, Sid and Trusty don't have the same version,
 and we need to generate the orig.tar file in all of them. The
 contributors for the Debian OpenStack packaging are mostly using Ubuntu,
 and they need to keep a workflow with the orig.tar file in the Git
 repository.

 I did tell them to just get the file from the Debian archive, but it
 doesn't work. One of the reason it doesn't is because sometimes, they
 upload first to Ubuntu, and then I do in Debian, and we end up with
 different orig.tar.xz files, meaning it's hard for them to sync back
 with Debian. I would like this to not be an issue anymore.

From where I'm sitting it all pretty much looks like a self-inflicted
problem. Upstream does not believe in releasing source tarballs (so
each user has to generate them from git-archive, which should be
considered inherently non-reproducible across different versions), and
then for packaging you want to use a pristine-tar workflow w/o using
pristine-tar, nor by creating a single common upstream source tarball,
nor by communicating/coordinating the creation of the first upstream
source tarball and reusing that on the other distro.

  That's the equivalent of expecting that using a different gcc version
  will give you the same output.
 
 I fail to see what gcc and a lossless compressor have in common.

A lossless compressor is not defined in terms of it needing to
generate the same compressed bistream, but in that it should produce
the same output when uncompressed.

gcc and a lossless compressor are similar in that they might produce
different bitstreams as long as the result is correct, for example
by performing optimizations that improve speed or reduce size.

  As long as the bitstream is compatible with previous versions, I don't
  see it as a problem
 
 The problem, I just explained it: I can't use xz in a pristine-tar like
 workflow, because it wouldn't reproduce the same output. And I'd like to
 use something better than the 20 years old gzip.

See Felipe and Russ replies. And I don't think you've explained why you
cannot use pristine-tar, which was implemented precisely to overcome such
problems.

  And how does that have anything to do with what gets packaged in Debian.
  For Debian you only need to generate it once, why would you want to
  generate it anew every time you build a new Debian revision instead
  of just reusing the same tarball that is on the archive, if you don't
  keep source tarball releases around?
 
 See above. It's a pristine-tar like workflow. Your question is
 equivalent to: why do people use pristine-tar?. The answer is: because
 it's convenient to just use git, without having to look into the Debian
 archive.

No, my question would actually be: why are you not using the tool that
was designed to do what you want to do?

Personally, which is besides a bit the point here, I think pristine-tar
is an interesting idea, but I find it pretty fragile and requiring an
ongoing amount of hacks to keep it going over time, so not something I'd
rely on for my data for long-term storage. For more details, see
pristine-tar O: bug #737871. I'm also part of the Cult of the Tarball,
and the Cult of no Autogenerated Cruft in a VCS.

 And by the way, xz wouldn't be usable with pristine-tar for the
 same reason.

If that is based on actual usage and pristine-tar is not working for
you, the correct solution is to fix it.

  Adding lzip support for source packages *might* make some sense, as
  I pointed out in the bug report. But doing so does have a very high cost:
  

  https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_compressors_for_.dsc_packages.3F
 
 I do understand the cost. But there's a valid reason. If you believe
 there's something better than lz, with the same properties, and that we
 had support for it, I'd happily adopt it. It is just that xz doesn't
 work right now, and most likely will break again in future versions of
 xz-utils.

It's not a matter of there being something better than lzip, I think
your expectations are unrealistic. Either lzip has a guarantee that it
will not change its bitstream ever again (does it?), which implies that
part of the compressor cannot ever be improved anymore, which makes it
quite unintersting as it's stale on arrival, or would require users to
tune parameters manually, removing simplicity, one of it's claimed
advantages over xz-utils; or it can change and then it loses the
property you seem to believe that you want from it.

The same applies to gzip, bzip2, tar, or even git versions (see the
above mentioned prsintine-tar O: bug), all those have changed and can
change in the future.

Regards,
Guillem


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas

Accepted device3dfx 2013.08.08-3 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 16 Jun 2015 03:32:34 +0200
Source: device3dfx
Binary: device3dfx-source
Architecture: source all
Version: 2013.08.08-3
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 device3dfx-source - Linux 2.2+ device driver source for 3Dfx boards
Changes:
 device3dfx (2013.08.08-3) unstable; urgency=low
 .
   * Use install instead of cp to generate the module source tarball, so
 that it is impervious to umask variance.
Checksums-Sha1:
 2848a5affbde6e72b05ea1def176cf7566021282 1875 device3dfx_2013.08.08-3.dsc
 0a9bfebbd9bd523c076d4a1ab07987d83346da54 11900 
device3dfx_2013.08.08-3.debian.tar.xz
 67c3c915b542d517f1f7dee0e2820c9e032142bb 22900 
device3dfx-source_2013.08.08-3_all.deb
Checksums-Sha256:
 d35253392effb619b925a299cf6ee181ba48926e7035dde56576dd6be50aa966 1875 
device3dfx_2013.08.08-3.dsc
 d1da6a6a80cf255b27ce6f57be9549ccfa0f23dc3c13b4fe2a1bb231451665d0 11900 
device3dfx_2013.08.08-3.debian.tar.xz
 4597014aec4a6f70591341f76fbc2cd9125bcfd197928c74e7b356f0b818b86d 22900 
device3dfx-source_2013.08.08-3_all.deb
Files:
 aeafa159fc41b31cf502da2c559cf89a 1875 kernel extra device3dfx_2013.08.08-3.dsc
 9e6adef886f94d35c52af0cea7443430 11900 kernel extra 
device3dfx_2013.08.08-3.debian.tar.xz
 6b40eb4174ef04287c4d107cca4a7d48 22900 kernel extra 
device3dfx-source_2013.08.08-3_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVf4A5AAoJELlyvz6krlejH0AQAOCUH0cn/LlGrDo43uTpxqYy
k7B0PaAvnUEBwCT5ANRP/13/m27U4oTgvp9MKC2Uf8Mg8X1KRi6DmKxhucR09kOQ
LS/AT13qxdC6nFrV6ruMpqjOjsNFlWyI4JNLdWYRmgQ2htXvmPnB1n4a7oyjm2lm
R266c8XcQfu0zazx1DTEB1pConrG5j5YLZ0Sa1jAAgJymIuAwlDO2QPintVUzq7F
D34KBdiOTKmzz9/NxX4FKTdnlb6g9cSyyyNJN8WbuLa3EWTyiSyqOItgglGE1YkD
MX5tw1OujYNzkf7AjJdd21R1slTkc6jghOC4VCogZSnLWhDmrxPFiA7/cPrhZ5HK
r3K9oqg2CmfM9PcjSYWO4hgu3VBz55CIgpU3yfUCPIvO4jbRbNhlMiXldx6hpmMJ
9lD4WxI2YkAtMwNZe5GPbOcTqd3qQ80h4lHpidtduik1/VnRPL1apdnAeaNW7im8
/SEfEhCgP2dLuQF3M1ira8rNLP42xTGpJcXyWjnPnR5Utw30/H0pos9FzH0/G6mV
tCmm79fQAB3jlWqCewW25xqCwrieOFYSa6GnvKhay8sokZ1YT8ZFv2QCKrXZq2qf
H6jgN3PxiEP3Fmqch9L8k6/SxVUv/EGvfmtbYVh24RM656spJlLz2Ks9uIlFsHXL
rzOyLj8UrHGGfu4LEa0Y
=iEtR
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1z4ilu-8n...@franck.debian.org

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Guillem Jover]

Hi!

On Sun, 2015-06-14 at 16:48:21 +0200, Vincent Lefevre wrote:
 On 2015-06-14 05:46:00 +0200, Guillem Jover wrote:
  On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote:
   On 06/13/2015 10:55 AM, Paul Wise wrote:
On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
As a friend puts it:

This is a fundamental problem/defect with xz. This (and a lot of
other such defects, e.g. non-robustness of xz archives that easily
lead to file corruption etc) are the reason that there is lzip (and
which is why gnu.org has, on a technical basis, decided that lzip is
official gzip-successor for gnu software releases when they come in
tarballs).
  
  TBH this smells like FUD. For example I've never heard of corruption in
  .xz files due to non-robustness, I'd expect that corruption to come from
  external forces, and that integrity would help or not detect it.
 
 xz-utils (4.999.9beta-1) experimental; urgency=low
 
   [ Jonathan Nieder ]
   * New upstream release.
  - Fix a data corruption in the compression code. (Closes: #544872)
 [...]
 
 But of course, this is old,

Yes, that was even before dpkg started to use xz-utils to handle .xz
files.

 and any compression software can have the
 same kind of bug (possibly unless proved formally).

And in any case I don't see how this is a fundamental problem with
the format, this is simply just a bug in a beta version, although an
unfortunate one.

 However lzip compresses better, sometimes much better:
 
 -rw-r- 1 vinc17 vinc17   822474 2015-04-26 00:45:51 mail.log.lz
 -rw-r- 1 vinc17 vinc17   915544 2015-04-26 00:45:51 mail.log.xz

Oh, interesting, this didn't use to be the case when we added .xz
support to dpkg.

 (this example is a postfix mail log) and uses much less memory for
 compression:
 
 $ sh -c 'ulimit -v 20; lzip -9  mail.log  /dev/null'
 $ sh -c 'ulimit -v 80; xz -9  mail.log  /dev/null'
 xz: (stdin): Cannot allocate memory
 $ sh -c 'ulimit -v 80; xz -9  /dev/null  /dev/null'
 xz: (stdin): Cannot allocate memory
 
 Note: see the 20 for lzip and 80 for xz.

The preset levels do not match between lzip and xz. For example for -9, xz
uses a dictionary size of 64 MiB, while lzip uses 32 MiB. Other parameters
are also probably quite different. In addition lzip seems to be
substantially slower (at least) when compressing compared to xz using the
same preset levels. With a small pdf file it took more than twice the time:

,---
$ cat Posix_1003.1e-990310.pdf /dev/null
$ ls -la Posix_1003.1e-990310.pdf
-rw-r- 1 guillem guillem 3486116 Feb 20 16:43 Posix_1003.1e-990310.pdf
$ /usr/bin/time xz -9k Posix_1003.1e-990310.pdf
1.24user 0.07system 0:01.31elapsed 99%CPU (0avgtext+0avgdata 98748maxresident)k
0inputs+3520outputs (0major+24291minor)pagefaults 0swaps
$ rm -f Posix_1003.1e-990310.pdf.xz
$ /usr/bin/time xz -9k Posix_1003.1e-990310.pdf
1.25user 0.06system 0:01.31elapsed 99%CPU (0avgtext+0avgdata 98952maxresident)k
0inputs+3520outputs (0major+24295minor)pagefaults 0swaps
$ ls -la Posix_1003.1e-990310.pdf.xz
-rw-r- 1 guillem guillem 1801372 Feb 20 16:43 Posix_1003.1e-990310.pdf.xz
$ rm -f Posix_1003.1e-990310.pdf.xz
#
$ /usr/bin/time lzip -9k Posix_1003.1e-990310.pdf
2.93user 0.02system 0:02.96elapsed 99%CPU (0avgtext+0avgdata 37628maxresident)k
0inputs+3520outputs (0major+8957minor)pagefaults 0swaps
$ rm -f Posix_1003.1e-990310.pdf.lz
$ /usr/bin/time lzip -9k Posix_1003.1e-990310.pdf
2.94user 0.03system 0:02.98elapsed 99%CPU (0avgtext+0avgdata 37576maxresident)k
0inputs+3520outputs (0major+8955minor)pagefaults 0swaps
-rw-r- 1 guillem guillem 1798338 Feb 20 16:43 Posix_1003.1e-990310.pdf.lz
$ rm -f Posix_1003.1e-990310.pdf.lz
`---

With the linux sources:

,---
$ cat linux_4.0.4.orig.tar /dev/null
$ ls -la linux_4.0.4.orig.tar
-rw-r--r-- 1 guillem guillem 582932480 May 26 20:15 linux_4.0.4.orig.tar
$ /usr/bin/time lzip -k9 linux_4.0.4.orig.tar
619.52user 1.27system 10:21.95elapsed 99%CPU (0avgtext+0avgdata 
363168maxresident)k
24inputs+156680outputs (0major+90387minor)pagefaults 0swaps
$ ls -la linux_4.0.4.orig.tar.lz
-rw-r--r-- 1 guillem guillem 80218126 May 26 20:15 linux_4.0.4.orig.tar.lz
$ rm -f linux_4.0.4.orig.tar.lz
$ /usr/bin/time lzip -k9 linux_4.0.4.orig.tar
618.94user 1.10system 10:21.02elapsed 99%CPU (0avgtext+0avgdata 
363180maxresident)k
8inputs+156680outputs (0major+90389minor)pagefaults 0swaps
$ rm -f linux_4.0.4.orig.tar.lz
#
$ /usr/bin/time xz -k9 linux_4.0.4.orig.tar
514.76user 1.53system 8:37.22elapsed 99%CPU (0avgtext+0avgdata 
691428maxresident)k
176inputs+156656outputs (1major+172417minor)pagefaults 0swaps
$ ls -la linux_4.0.4.orig.tar.xz 
-rw-r--r-- 1 guillem guillem 80205900 May 26 20:15 linux_4.0.4.orig.tar.xz
$ rm -f linux_4.0.4.orig.tar.xz
$ /usr/bin/time xz -k9 linux_4.0.4.orig.tar
515.96user 1.62system 8:38.60elapsed 99%CPU (0avgtext+0avgdata 
691328maxresident)k
56inputs+156656outputs (0major+172413minor)pagefaults 0swaps
$ rm -f linux_4.0.4.orig.tar.xz

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Guillem Jover]

Hi,

On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote:
 On 06/13/2015 10:55 AM, Paul Wise wrote:
  On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
  I've been using xz compression for a long time, but I see a big defect
  which is today pushing me to turn it off for the .orig.tar file. The
  issue is that depending on the version of xz-utils, it produces a
  different output.

Well if you want reproducible output, then use the same tool version.
That's the equivalent of expecting that using a different gcc version
will give you the same output.

As long as the bitstream is compatible with previous versions, I don't
see it as a problem, and I'd expect such changes to be beneficial,
because say, they might allow making the encoder faster, or compress
better, etc.

  We use git archive within the PKG OpenStack team to generate this
  tarball (which is more or less the same as pristine-tar, except we use
  upstream tags rather than a pristine-tar branch). The fact that xz
  produces a different result makes it not reproducible. As a
  consequence, it is very hard for us to use this system across
  distributions (ie: use that in both Debian and Ubuntu, or in Sid 
  Jessie). We need consistency.

If you generate it once, as part of the release process, why do you
need to generate it on different systems with different versions? And
how does that have anything to do with what gets packaged in Debian.
For Debian you only need to generate it once, why would you want to
generate it anew every time you build a new Debian revision instead
of just reusing the same tarball that is on the archive, if you don't
keep source tarball releases around?

  As a friend puts it:
  
  This is a fundamental problem/defect with xz. This (and a lot of
  other such defects, e.g. non-robustness of xz archives that easily
  lead to file corruption etc) are the reason that there is lzip (and
  which is why gnu.org has, on a technical basis, decided that lzip is
  official gzip-successor for gnu software releases when they come in
  tarballs).

TBH this smells like FUD. For example I've never heard of corruption in
.xz files due to non-robustness, I'd expect that corruption to come from
external forces, and that integrity would help or not detect it. In any
case .xz supports CRC32, CRC64 and SHA-256 for integrity checks, .lz only
supports CRC32. More over lzip was created to overcome limitations in the
.lzma format, .xz came later and fixed the limitations of the .lzma format
too.

(And I could probably switch dpkg-deb's .xz integrity check to CRC64,
given that's the xz-utils command-line tool default.)

Also many GNU projects do not release lzip tarballs, but do release bzip
or xz ones and there are very few that exclusively release lzip tarballs.
If that's the equivalent of bazaar being the official GNU VCS that most
of the GNU projects do not use, well…

Actually where is the gnu.org decision documented? I don't see it
neither in the GCS, the “Information for Maintainers of GNU Software”,
nor in the ftp.gnu.org site. And automake still defaults to dist-gz in
latest git.

  http://www.gnu.org/prep/standards/
  http://www.gnu.org/prep/maintain/

  So it'd be super nice to have LZIP support in dpkg, and use that
  instead of xz, archive wide.
  
  Your thoughts everyone? Is there any reason why we wouldn't do that?

Yes, replacing xz with lzip on .deb or .dsc packages does not make any
sense. Adding lzip support for source packages *might* make some sense, as
I pointed out in the bug report. But doing so does have a very high cost:

  
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_compressors_for_.dsc_packages.3F

Whenever considering to add a new compressor, all surrounding tools need
to be modified to support it as well:

  https://wiki.debian.org/Teams/Dpkg/DebSupport
  https://wiki.debian.org/Teams/Dpkg/DscSupport

That's a non-zero amount of work and time, and that does not take into
account external tools and users. It would also not be usable until the
next stable release. Also notice that for example there are still tools
that do not support data.tar.xz in .deb, which has been the default for
a while, which should give you an idea of what it takes.

Adding a new compressor, that does not bring any significant benefit in
compression ratio, speed or container format, that is either not widely
used or widely available in many systems, just for the benefit of very
few packages that might be releasing as well in other formats, or that
can be easily recompressed, still does not seem worth it, no.

I've yet to see an actual convincing argument why this would be worth
the effort and trouble.

Also not to mention that I was the first to also consider .lz when we
evaluated adding .xz support in dpkg back in 2009.

  https://lists.debian.org/debian-dpkg/2009/10/msg00029.html

  It was already rejected by the dpkg maintainers twice.
  
  https://bugs.debian.org/600094
  https://bugs.debian.org/556960
 

Re: DEB_SIGN_KEYID vs DEBSIGN_KEYID

[Guillem Jover]

Hi!

On Sun, 2015-06-07 at 10:36:41 +0200, Harald Dunkel wrote:
 For devscripts you can define a variable DEBSIGN_KEYID. For
 dpkg it is called DEB_SIGN_KEYID. git-buildpackage doesn't
 support a keyid environment variable at all, as it seems. All
 ignore the default-key option set in .gnupg/gpg.conf .

The devscripts ones are only settable in the devscripts config file.
The dpkg one is an environment variable:

  https://lists.debian.org/debian-dpkg/2013/10/msg00017.html

I don't think changing the behavior of dpkg-buildpackage to defer to
GnuPG's default-key would be a good idea. Using the changelog address
as the default value seems saner to me, as that should in principle
pick the correct key in most cases. Also changing this would probably
break far many setups, which I'm not looking forward to.

 Would it be possible to get a common line here?

I'd recommend adding support for DEB_SIGN_KEYID as an environment
variable in other tools. :)

Thanks,
Guillem


-- 
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/20150614041206.gb10...@gaara.hadrons.org

Accepted inetutils 2:1.9.4-1 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 11 Jun 2015 05:40:05 +0200
Source: inetutils
Binary: inetutils-ftp inetutils-ftpd inetutils-inetd inetutils-ping 
inetutils-traceroute inetutils-syslogd inetutils-talk inetutils-talkd 
inetutils-telnet inetutils-telnetd inetutils-tools
Architecture: source
Version: 2:1.9.4-1
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 inetutils-ftp - File Transfer Protocol client
 inetutils-ftpd - File Transfer Protocol server
 inetutils-inetd - internet super server
 inetutils-ping - ICMP echo tool
 inetutils-syslogd - system logging daemon
 inetutils-talk - talk to another user
 inetutils-talkd - remote user communication server
 inetutils-telnet - telnet client
 inetutils-telnetd - telnet server
 inetutils-tools - base networking utilities (experimental package)
 inetutils-traceroute - trace the IPv4 route to another host
Changes:
 inetutils (2:1.9.4-1) unstable; urgency=low
 .
   * New upstream release.
 - debian/patches/01_disable_useless_man_pages.patch: Refreshed.
 - debian/patches/fts_alignment.patch: Remove, merged upstream.
 - debian/patches/ping_linebuff.patch: Likewise.
   * Add netbase to Build-Depends, used by the test suite.
 Suggested by Mats Erik Andersson mats.anders...@gisladisker.se.
Checksums-Sha1:
 6505193651e98c3105b3717bcb22f6d45f3289d0 2659 inetutils_1.9.4-1.dsc
 5e515cc9da142cb73bb1beda137b4c2dcf2b528c 1364408 inetutils_1.9.4.orig.tar.xz
 b445359e33a44a70311923bfd30d826f37836d1d 76540 inetutils_1.9.4-1.debian.tar.xz
Checksums-Sha256:
 787bdedf048db9a021331228914f96743f1b31e552e2d31222d24adbacdba636 2659 
inetutils_1.9.4-1.dsc
 849d96f136effdef69548a940e3e0ec0624fc0c81265296987986a0dd36ded37 1364408 
inetutils_1.9.4.orig.tar.xz
 de6daa5c3ec9716b8a667734820e0fa0e49444ba36c95d1321bfb5c98d71586d 76540 
inetutils_1.9.4-1.debian.tar.xz
Files:
 c88de7496782dbefb35f46ac219481fb 2659 net extra inetutils_1.9.4-1.dsc
 87fef1fa3f603aef11c41dcc097af75e 1364408 net extra inetutils_1.9.4.orig.tar.xz
 d29e37699f3b58477657f9ab8f163c54 76540 net extra 
inetutils_1.9.4-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVeUw9AAoJELlyvz6krlejTekP/A4SzHgxIULlUqLk9TwKk2SY
eWwHc4A7sbhwLVnKm07oXUWm0cloKmCcdsN4OpeCjtq/s/Sd0hIyfVT87trDGk0b
2UFzDYR8wgGbDXF7QcD0dmhIYCeJ09+YbXDctVjs69kTFd4AfvmJAsg/3+LgJNPw
q6O6biQTGExj5RXHz0PCa90lStzZvyPMPitlTqW1E68jhjYHhUnNGWMZI0HmQv8K
MdVdLLI6F+pohKSfyo3yJvzT6noSij03hSzlu9BKHt/3M6g3GtkHVGmlJFqLGKvW
KTgFqmXABUWAgkQ8BY4L79V4U1HarJnIfS7EzvlMnaoA0ki3OqTKVFqJlCGuRgxT
e/vQzuabAZT4UFy0xjllDYzocZpMQXEwEFydHkhIJtVurSukv4EAxjEKmjdKjKB5
SlF5ZCqJNU+VDCj0Ny0Dd+iqHM7AtIZz8l5CsD2+pGYK0Pgqh58MI4SWpJDJFiE4
WfeU2XKbYa5bFb1Fqgk+3TG2H09TTvtJN878aSAbvQtffRHphei+hUyZtsvIMlsm
LF0RGE1hiqn+kq3O8OIqHhIEkdaGNh55cy5FX9ruiUTLfrYFt0qySKkGk+MoN65C
gn6zZNynmTPmUMxWhZ9l5LUzkB+p3JesBBND/eaqNKCGs2KhFIwJK/4MiuQYHS92
UJxTpNNfIHXRF7DCvYny
=b8ZI
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1z2zcx-00012b...@franck.debian.org

Accepted dpkg 1.18.1 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 30 May 2015 03:00:21 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source all
Version: 1.18.1
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers debian-d...@lists.debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 377860 720761 785937 786377 786435 786654 786840
Changes:
 dpkg (1.18.1) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Cast c_isbits() c argument to an unsigned char when indexing the array.
 This fixes build failures on armel, armhf, ppc64el and s390x.
   * Do not allow pathnames with embedded newlines in dpkg-deb and dpkg.
 Closes: #720761
   * Fix setting the SE Linux context when a file has a statoverride.
 Closes: #786435
   * Set the SE Linux file context even when the file mode has no file type.
   * Make dpkg-buildpackage -j override any parallel option specified in
 DEB_BUILD_OPTIONS. Regression introduced in dpkg 1.14.15.
   * Honor Pre-Depends, Conflicts and Breaks for packages in unpacked and
 half states. Thanks to Ian Jackson i...@ubuntu.com. Closes: #377860
   * Fix build failure on FreeBSD by actually using libmd if available.
   * Sort dpkg-scanpackages output by package name and version.
 Thanks to Maximilian Schwerin maximilian.schwe...@tigris.de.
   * Sort dpkg-scansources output by package name and version.
 Thanks to Maximilian Schwerin maximilian.schwe...@tigris.de.
   * Set the correct default compression value in dpkg-deb for control.tar.gz
 member. This meant using compression level 1 when using the zlib shared
 library to compress the control.tar member, and always failing when using
 the gzip command. Regression introduced in dpkg 1.17.6. Closes: #786654
   * Use the generated template file instead of the original one when looking
 for changes in dpkg-gensymbols. There's too much information not being
 preserved in the symbols files to be able to regenerate templates for
 them. Closes: #785937, #786840
   * Perl modules:
 - Add missing strict and warnings pragmas for submodules.
 - Use non-destructive substitutions inside map.
 - Use the state keyword to simplify the code.
 - Do not replace #PACKAGE# in template mode in Dpkg::Shlibs::SymbolFile.
   * Documentation:
 - Update current default source compressor from gzip to xz.
 - Remove spurious ‘=’ from parallel DEB_BUILD_OPTIONS without arguments
   in dpkg-buildpackage(1).
 .
   [ Updated programs translations ]
   * German (Sven Joachim).
   * Simplified Chinese (Zhou Mo). Closes: #786377
 .
   [ Updated manpages translations ]
   * German (Helge Kreutzmann).
 .
   [ Updated dselect translations ]
   * German (Sven Joachim).
Checksums-Sha1:
 0409942a8410b62930f053f7ae4d85881ee2b237 2014 dpkg_1.18.1.dsc
 3c44e6e7f8b2e72bef457568984b4ceb33ed6a45 4340240 dpkg_1.18.1.tar.xz
 39400c87363b772e8659e964c212162a2e0cc451 1415366 dpkg-dev_1.18.1_all.deb
 6255384b21ba702a108903c936ec9bc84bc0c1d5 1108034 libdpkg-perl_1.18.1_all.deb
Checksums-Sha256:
 ac13c57145473570e75ecd2ad40a727edc199e77162d0b35acda858d88747c95 2014 
dpkg_1.18.1.dsc
 cb26a97ca21c970cbe63a762125fe21f7437663badf6ce686589fe62650399da 4340240 
dpkg_1.18.1.tar.xz
 2db86ff116c1fb931e35e29fc35641a600d447cf8b32351261a05d6f70be9987 1415366 
dpkg-dev_1.18.1_all.deb
 894217d792614cc701f9acb908f2fa2dd86b1c34f643c1dbd48f641d22c3dd7f 1108034 
libdpkg-perl_1.18.1_all.deb
Files:
 aefdcf8b716cc8ca692b2660c336edf5 2014 admin required dpkg_1.18.1.dsc
 809169e14489dbcc603dc011381fdc67 4340240 admin required dpkg_1.18.1.tar.xz
 ebd6b31b20515cce1ff1066915a0d918 1415366 utils optional dpkg-dev_1.18.1_all.deb
 7787dfd48a2a7438349914f95a2203a4 1108034 perl optional 
libdpkg-perl_1.18.1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVaQ+zAAoJELlyvz6krlejM64QAOdq8zmjbGa1nxgRimg6FPP7
OEy5/3KFCIWW69WvW26MVlxp3CaExPSrPhfBL18h+2/3Z6okcjAJzm5xeeIBZDLT
5bxbDL7TGWkcn+smlsMMMcxz4U4DiM+uQX3m84lLlY4d3xEMxBmj+bp8jXQf3/ha
JNu5bVjJIIEPOLUU4dRZweQYnesSTkKnnBkEAtG6ZeWNzoP79QCQCcDzCOU7jUrq
Ib4r+SjQU+sy+MMRt/QpoQhrbVO3FSPtuwaD4b5fLpuXg+3wjdriUM0DRYE7yPYd
a4qgRtPQ9Tav+CxleGGfENifreWptuo5vQbBKD9gi5eW8/YA8f3yjWZfm42EBbtV
GwFMYp2zESQ++OUFIGOBI/gDvtxRj0XEWKRQElCgr3TlHoGJRetNMbvyfdTu1Shd
a9Lsb9Q5vRfeltqipkcpySyNjIq57rcSDH69m5BYEXvRO4PCLf7GTotmaboq1gU2
HGDXZrWxlyDyM2BlXlsj0roPpHoBx3f9Gp09w58TRg/+X7HKesFFOI1obQuz0HvN
GJjHPNC89qR0uYUr+ygNlVTQyO2hfNgug/VSnc1xO1XqLf4zZdkg+mF1TJDbPLtg
/bl8dyNh7/YKeWitEyA2kA0fI+RftRDBJnC5M1S7Mlv5y1ILqrS263biatWMhEgC
eaCRjuySwv/lgZqzZG8e
=xTfb
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact

Accepted inetutils 2:1.9.3-2 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 26 May 2015 16:57:46 +0200
Source: inetutils
Binary: inetutils-ftp inetutils-ftpd inetutils-inetd inetutils-ping 
inetutils-traceroute inetutils-syslogd inetutils-talk inetutils-talkd 
inetutils-telnet inetutils-telnetd inetutils-tools
Architecture: source
Version: 2:1.9.3-2
Distribution: unstable
Urgency: medium
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 inetutils-ftp - File Transfer Protocol client
 inetutils-ftpd - File Transfer Protocol server
 inetutils-inetd - internet super server
 inetutils-ping - ICMP echo tool
 inetutils-syslogd - system logging daemon
 inetutils-talk - talk to another user
 inetutils-talkd - remote user communication server
 inetutils-telnet - telnet client
 inetutils-telnetd - telnet server
 inetutils-tools - base networking utilities (experimental package)
 inetutils-traceroute - trace the IPv4 route to another host
Changes:
 inetutils (2:1.9.3-2) unstable; urgency=medium
 .
   * Pass VERBOSE=1 to «make check» call, to get testsuite details on failure.
   * Fix misaligned memory access for stat struct in lstat() call. Fixes a
 build failure on sparc.
   * Build-Depend on net-tools for netstat, used by the test suite.
   * Review and update of obsolete man pages. Addresses: #609934, covering:
 - local/man/ftp.1
 - local/man/inetd.8
 - local/man/netrc.5
 - local/man/ping6.1
 - local/man/talk.1
 - local/man/trceroute.1
   * Drop ancient hurd Conflicts from inetutils-ping.
   * Add LSB Description fields to inetd and syslogd init scripts.
Checksums-Sha1:
 bd5cfe69e146784b9f77aaf8adb959e07f64ad44 2650 inetutils_1.9.3-2.dsc
 ff81f18f0fd0761b3290bf7df74a14c2c3c4166f 77156 inetutils_1.9.3-2.debian.tar.xz
Checksums-Sha256:
 21bda3c51a7045678efbf6a649a428e29318c73f20c053f2cecfd245f64bda08 2650 
inetutils_1.9.3-2.dsc
 39a7ffb3272a4af044f69200963d0ac9731658f12587e903042e5db2feefb059 77156 
inetutils_1.9.3-2.debian.tar.xz
Files:
 87088d58dd8d2e84bfb8af492b7f430e 2650 net extra inetutils_1.9.3-2.dsc
 56a49de1ffe2da6e3fa2ec0b768bf8ea 77156 net extra 
inetutils_1.9.3-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVZJB4AAoJELlyvz6krlejVL4P/32UYi8xkj1/Thdvc9WiVjMd
3oRzCPJj/5BH5tdDDYBzI785ulERKsyXqllaIcxMx5am26eOM8tebU/QQB864DHI
G+O4aKevGgS1vT/ntdgh3T0Okq+B8TgmX7NZZzt7EfADCkUfBWCOzJ4I6Je9N+HK
Syym2T07gjsivFB3zvpJCcUu+tgR5l0tVRhChwpcwYHF/tZk3hUQMWfXfL8hl+zd
pN12kI3z5qLAyWYbtWTrpWvvLWcecAL/4ZXDh9Dx926ipqE/BVg4PA/V2JQE9pID
KrdfSUmAwk1EXAWhlHaF3O52PcJd9uzdWvxWNP1cwAlslSIWaXcArW23wkoIsUXg
4XrFoObGEsC/jzJpXnO3OfoViHwoFuXg3zX5S0ifENnIzFAWxo61zplSoICyv1o7
xrtwbc7OqgbYOld4KitL+oI3LaAVSTer+azBq9/LzuoekWpf8d1vjaFbfZA6eXO2
WllHKkBK3BbOCYhzKJTh4Eh5RZ1idKMaJTVvJtWwV4ABr7wxG43b5Q8tPKF48H6Y
N2Sb2kwGlpZgkvSkEGvpW0XbstZgrW5jBz9IsZmpe65cg9u/1I71uCdXjy3vWk6e
haz3B8nPt2s1B4VMMmQnrgxasn/UWYFn+4WCN6uwxiQAxUN82fMopE+PTK5yMLFG
UurMcQ3PXqLZbt+oz96W
=3ivt
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yxhpv-0003j7...@franck.debian.org

Re: static linking

[Guillem Jover]

Hi!

On Tue, 2015-05-19 at 18:21:40 +0100, Rebecca N. Palmer wrote:
 What's the preferred way to set Built-Using:

 http://sources.debian.net/src/chromium-browser/42.0.2311.135-2/debian/control/?hl=82#L82

This one is wrong in two ways, it's missing the exact version, and the
field does not belong in the source stanza.

 http://sources.debian.net/src/binutils/2.25-7/debian/rules/?hl=998#L998 ,

This one is correct.

 or something else?

Another slightly more involved option would be:

  http://sources.debian.net/src/debsig-verify/0.13/debian/rules/#L3
  http://sources.debian.net/src/debsig-verify/0.13/debian/rules/#L90
  http://sources.debian.net/src/debsig-verify/0.13/debian/control/#L17

which is what I'm pondering supporting natively in dpkg, and would end
up requiring only the change in the control file.

Thanks,
Guillem


-- 
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/20150519182529.ga30...@gaara.hadrons.org

Accepted dpkg 1.18.0 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 18 May 2015 15:08:31 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source all
Version: 1.18.0
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers debian-d...@lists.debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 588505 616614 630342 650077 690361 693951 760741 767003 768842 769515 
771752 772184 773398 773718 775124 775258 775379 776072 776551 777044 779467 
780866 781074 781887 782019 782326 783014 784966 785096
Changes:
 dpkg (1.18.0) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Only trim trailing “/” and “/.” from «dpkg-query --search» arguments if
 they are a pathname, and not a pattern or a substring match.
   * Switch C/C++ code to use a new set of C locale character type functions
 independent of the current locale.
   * Add support for arch-bits and arch-endian dpkg-gensymbols tags.
 Closes: #630342
   * Switch perl code from legacy File::Path functions to new ones.
   * Fix perl uninitialized value usage in dpkg-scansources when the Binary
 field is missing.
   * Use dpkg-query instead of dpkg for --search in dpkg-shlibdeps so that
 the subprocesses get the correct admindir. Closes: #775258
   * Rework the Installed-Size field default value computation to make it
 reproducible regardless of the build system filesystem, and document
 how the value is computed and that it is just an approximation.
 Closes: #650077
   * Use strftime() instead of «date -R» in dpkg-genchanges, as the latter
 is not specified by POSIX and is not widely portable.
   * Warn on obsolete '' and '' operators in dpkg --compare-versions.
   * Trim end of line whitespace from dpkg and dselect config file parsers.
 Reported by Christoph Biedl debian.a...@manchmal.in-ulm.de.
   * Do not silently eat a standalone ‘-’ in the libdpkg command-line parser.
   * Fix short-lived memory leaks in dpkg-deb and libdpkg. Closes: #769515
   * Fix «dpkg-deb -b» filename generation when the package does not contain
 an Architecture field. Regression introduced in dpkg 1.16.2.
   * Fix «dpkg --audit» to report missing and empty architecture fields.
 Regression introduced in dpkg 1.16.2.
   * Add support to dpkg-deb for reading the archive from standard input,
 except for --raw-extract which does not yet support it. Closes: #616614
 Based on a patch by Johannes Schauer j.scha...@email.de.
   * Add ‘.mailmap’ to the default dpkg-source ignore lists.
   * Set the SE Linux context on «dpkg-statoverride --update». Closes: #690361
   * Do not fail on dpkg-query -W and -l when multiple arguments match the
 same package. Closes: #588505
   * Change dpkg-maintscript-helper to handle symlinks and pathnames ending in
 slash. For the former error out, for the latter strip it. Closes: #771752
   * Support moving a conffile not being shipped anymore. Closes: #767003
 Thanks to Mathias Behrle mathi...@m9s.biz.
   * Add a new dpkg-buildflags sanitize feature area:
 - Add new “address”, “thread”, “leak” and “undefined” features, all
   disabled by default. Closes: #760741
   * Do not accept unknown user or group names on «dpkg-statoverride --add».
 Regression introduced in dpkg 1.17.11. Closes: #775124
   * Normalize dpkg-parsechangelog command-line parsing, so that «-ovalue»,
 «-o value», «--option=value» and «--option value» will all be accepted.
 Closes: #693951
   * Add dpkg --ctrl-tarfile forwarding command for dpkg-deb.
   * Disable dependency checks on dpkg-buildpackage -S -nc.
   * Make dependency checks fatal for dpkg-buildpackage -S.
   * Update amd64 GNU cpu regex in cputable to match amd64 too, in addition
 to x86_64. This is required for FreeBSD.
   * Use badusage() instead of ohshit() for command-line errors.
   * Use the original template symbols file when diffing in dpkg-gensymbols.
 We should not create a new template symbols file, because the output
 might change (different sorting order for example) relative to the
 original. Closes: #773718
   * Do not leak kvm descriptors in start-stop-daemon on GNU/kFreeBSD systems.
 Based on a patch by Jeff Epler jep...@unpythonic.net. Closes: #779467
   * Switch start-stop-daemon to use a monotonic clock if available. This
 makes the timeout checks resilient to abrupt system clock changes.
 Suggested by Jose M Calhariz jose.calha...@hds.com. Closes: #783014
   * Fix perl warning in dpkg-genchanges when parsing BY-HAND file entries.
 Regression introduced in dpkg 1.17.7. Closes: #781074
   * Use the checksums files list order when building the Files field to match
 the other Checksum fields

Heads up: Changes in dpkg-shlibdeps directory search list

[Guillem Jover]

[ Please follow up on d-d and d-cross (M-F-T set). ]

Hi!

There are several cleanups and order changes in the pipe for the default
dpkg-shlibdeps shared library directory search list in dpkg 1.18.x.

It was previously, in decreasing order of preference:

  0. «dpkg-shlibdeps -l» (or via «dh_shlibdeps -l»)
  1. ENV{LD_LIBRARY_PATH} (deprecated)
  2. DEFAULT_LIBRARY_PATH (/lib, /usr/lib)
  3. DEFAULT_MULTILIB_PATH (/lib32, /usr/lib32, /lib64, /usr/lib64,
/emul/ia32-linux/lib, /emul/ia32-linux/usr/lib)
  4. If cross-building or building a cross-compiler:
   cross-multiarch (/lib/triplet, /usr/lib/triplet)
   cross-root (/triplet/lib, /usr/triplet/lib)
   cross-root-multilib (/triplet/lib32, /usr/triplet/lib32,
/triplet/lib64, /usr/triplet/lib64)
  5. ld.so.conf

And will become:

  a. «dpkg-shlibdeps -l» (or via «dh_shlibdeps -l»)
  b. ENV{LD_LIBRARY_PATH} (obsolete)
  c. If cross-building or building a cross-compiler:
   cross-multiarch (/lib/triplet, /usr/lib/triplet)
  d. DEFAULT_LIBRARY_PATH (/lib, /usr/lib)
  e. ld.so.conf
  f. DEFAULT_MULTILIB_PATH (legacy: /lib32, /usr/lib32, /lib64, /usr/lib64)

And the rationale for the changes follows:

* Setting LD_LIBRARY_PATH in debian/rules to specify the local build-tree
  has been obsoleted by «dpkg-shlibdeps -l». That variable is for the
  run-time linker, using is also for the build-time environment mixes
  them up, and does not play nice when cross-building, if you've got a
  package doing that, please switch to use the option -l. I'll request
  a lintian check for this.

* The ancient GCC_TARGET environment variable is not honored anymore,
  this was a way to specify cross-compiler builds, DEB_TARGET_GNU_TYPE
  can always be used for that now.

* The cross-root directories (/triplet/lib* and /usr/triplet/lib*)
  are not added anymore to the default list when cross-building. These are
  legacy from a pre-multiarch era, no package uploaded to Debian should
  be using these, and having them in the default list is just an accident
  waiting to happen. Of course people using local cross-root setups can
  still use those paths, they will just not be used for *packaged*
  binaries, and if people still want to use these paths to package stuff
  outside of Debian they can still use «dpkg-shlibdeps -l».

* When cross-building the cross-multiarch paths should have precedence
  over the native ones, because that's what we are linking against. In
  theory when cross-building no native paths (b. sometimes, d. and f.)
  should be in the list, as that pollutes it, and I'm pondering about
  doing that, but we might need to keep loading ld.so.conf as foreign
  packages might have added required paths for cross-compiling there…

* The ancient multilib paths (/emul/ia32-linux/lib and
  /emul/ia32-linux/usr/lib) inherited from ia64 are gone now, these
  were transitioned away from in squeeze.

* The legacy multilib paths now have lower precedence than the ld.so.conf
  ones, as proper standard or multiarch paths should be always preferred,
  or programs might end up accidentally depending on multilib packages. In
  the near future I'd like to either remove or hide multilib paths from
  the default list if DPKG_ENABLE_DEPRECATED_MULTILIB=yes is not set in
  the environment (for example), to avoid polluting the default list, and
  because they are pretty much non-exhaustive and do not cover all
  current multilib paths anyway.

Thanks,
Guillem


-- 
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/20150516031504.ga21...@gaara.hadrons.org

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

[Guillem Jover]

[ reproducible-builds people, please see below. ]

Hi!

On Tue, 2015-05-12 at 10:02:27 +0100, Jonathan Dowland wrote:
 On Mon, May 11, 2015 at 08:40:16PM +0200, Guillem Jover wrote:
  $ make -jN -f debian/rules build
  
  and
  
  $ DEB_BUILD_OPTIONS=parallel=N debian/rules build
 
 I prefer the latter behaviour but the former brevity. Would you consider
 something like -J in dpkg-buildpackage adjusting parallel= in
 DEB_BUILD_OPTIONS, and perhaps in the future phasing out -j?

Sure, adding either an option to disable the forced parallel runs in
combination with -j, or a new option such as -J seems fine to me.

The “nice” thing about -j is that it allows anyone to naturally exercise
parallel builds (like they'd do with an upstream project) and possibly
notice if something does not support them. Getting rid of it would mean
that the current marking of packages might be even slower than it is.
Because we have to opt-in for every and each package in the archive,
with the usual multi-year Debian adoption rates and probably longer in
this case. So I think having both semantics at hand is useful.

And of course «dpkg-buildpackage -jN» does not cover build systems that
do not use make, but I've always thought of DEB_BUILD_OPTIONS=paralle=N
as a way to request that.

  Actually Makefiles that do not support parallel builds and do not
  declare so with .NOTPARALLEL: are buggy, because upstreams do not
  have any standardized opt-in way to honor a parallel build request.
 
 Now that rules files have to be makefiles; I wonder if this should be 
 clarified
 in policy, one way or the other. That is: should debian/rules be assumed to
 support parallel building by default, or not? I imagine the saner default for
 us would be not (even though I am a big fan of parallel builds).

IMO dpkg-buildpackage should assume yes, in the same way it assumes
packages are cross-buildable, and we don't go around marking them as
such. But I guess for Debian that depends on how much of our packaging
and upstream build systems are parallel buildable. I'd have assumed that
with projects like Gentoo around and multicore systems being so common
nowadays, many things would be parallel buildable already, although I
don't have numbers…

… but, we do have a way to check if a package is parallel buildable now,
through reproducible builds. If a package outputs exactly the same with
dpkg-buildpackage -j1 and -jauto (w/o DEB_BUILD_OPTIONS) then it means
the package is good, otherwise it might need fixing one way or another.

Thanks,
Guillem


-- 
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/20150513122154.ga17...@gaara.hadrons.org

Re: Allowing both cross building and using an alternative compiler

[Guillem Jover]

Hi!

On Mon, 2015-05-11 at 01:34:08 +0200, Matthias Klose wrote:
 On 05/10/2015 03:32 AM, Guillem Jover wrote:
  CC_FOR_BUILD = gcc
 
 the above mentioned wiki pages still talk about HOSTCC and BUILDCC. Please
 clarify when to use these.

I think HOSTCC and BUILDCC should never be used, because they are either
very confused in their meaning alternating depending on the upstream, or
impose unnecessary work when the default CC should always be considered
the compiler for the host system, because that's the common action to do
and it is an implicit make variable, and as such does not require any
modification to the default build rules. Of course there are upstream
projects using these, so initially it might be easier to map them in
debian/rules from our standard variables than to patch their build system.

There are very few instances of BUILDCC around. There are many more for
HOSTCC, but then we find gems like this:

,---
# HOSTCC and HOSTCFLAGS are used to build executables that will be run as
# part of the build process, i.e. on the build machine.  These will usually
# be the same as CC and CFLAGS, except in a cross-compilation environment.
# Note that HOSTCFLAGS should include any -D flags that affect thread support.
HOSTCC=$(CC)
HOSTCFLAGS=$(CFLAGS)
`---

So these are really BUILD tools not HOST tools…


In any case the wiki page only mentions them as some kind of possible
solution to cover cross-builds, I don't see it as any kind of done deal
decision. I'll let the proposers of that goal update the wiki if they
feel like it.

 Are the names now final?

If you mean the names such as CC and CC_FOR_BUILD, that's the autotools
nomenclature for these, I think it makes sense, and I'd like us to
standardize on them. Final, well this thread was a way to canvas
support/objections for all this stuff. :)

 Also I don't see OBJC and OBJCXX in use, and GOC and GDC are missing.

A quick search on http://codesearch.debian.net/ at the time revealed
many instances of OBJC and OBJCXX, these are also the variables used
by autotools for Objective C/C++ support via AC_PROG_OBJC and
AC_PROG_OBJCXX. Also GNU make has OBJC as an implicit variable.

I didn't add any other compiler variables (such as GOC or GDC) if they
were missing compiler flags support in dpkg-buildflags. If you want to
get support for them, please send the corresponding appropriate default
flags.

Thanks,
Guillem


-- 
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/20150513123216.gb18...@gaara.hadrons.org

Accepted inetutils 2:1.9.3-1 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 13 May 2015 02:32:03 +0200
Source: inetutils
Binary: inetutils-ftp inetutils-ftpd inetutils-inetd inetutils-ping 
inetutils-traceroute inetutils-syslogd inetutils-talk inetutils-talkd 
inetutils-telnet inetutils-telnetd inetutils-tools
Architecture: source
Version: 2:1.9.3-1
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 inetutils-ftp - File Transfer Protocol client
 inetutils-ftpd - File Transfer Protocol server
 inetutils-inetd - internet super server
 inetutils-ping - ICMP echo tool
 inetutils-syslogd - system logging daemon
 inetutils-talk - talk to another user
 inetutils-talkd - remote user communication server
 inetutils-telnet - telnet client
 inetutils-telnetd - telnet server
 inetutils-tools - base networking utilities (experimental package)
 inetutils-traceroute - trace the IPv4 route to another host
Closes: 777661 779399 780884 780885 781061 782727
Changes:
 inetutils (2:1.9.3-1) unstable; urgency=low
 .
   * New upstream snapshot.
 - Fix telnetd to handle all TIOCPKT control bytes. Closes: #779399
 - Fix telnetd to allow autologin without authentication. Closes: #780884
 - Fix ftp to allow alias names in netrc file. Closes: #780885
   * Switch Vcs-Browser to a cgit URL.
   * Fix build-arch target to not depend on debian/control, a leftover from
 when debian/control was generated at release time.
   * Pass build flags through configure with a single dpkg-buildflags call,
 instead of on each make invocation.
   * Run the testsuite during the build-arch target, and honor nocheck.
   * Add slave alternatives for pftp, pftp.1.gz and netrc.5.gz in
 inetutils-ftp. Closes: #781061
   * Split inetutils-netrc.5 man page out from inetutils-ftp.1.
   * Set man pages .TH source and .Os to GNU inetutils.
   * Set delaycompress for all syslogd logrotate files. Closes: #777661
   * Always force ping and ping6 line buffering on stdout, so that programs
 parsing their output have more timely responses. Closes: #782727
Checksums-Sha1:
 27622a9244a2da95f3b2e47e8b13badb9b196d5c 2639 inetutils_1.9.3-1.dsc
 9fab38b8225ff5d5b3d586bdcf63f7eee0b322d8 1363456 inetutils_1.9.3.orig.tar.xz
 07192e22511eb90b7ce37ceb012ff0f9288040d7 76164 inetutils_1.9.3-1.debian.tar.xz
Checksums-Sha256:
 111696a366a2f4f8a10f0f5294df6dbd6152550c006f88e66681de3ff0a8aa48 2639 
inetutils_1.9.3-1.dsc
 40ed8bb3d21eca5afbc9865125e9049ee524b2b0f66b388878861d436d0d773d 1363456 
inetutils_1.9.3.orig.tar.xz
 d0b91d887ccdfbc5d2ed31e64f40cef95fedbd3a98ffd47839314ab5c8bc219b 76164 
inetutils_1.9.3-1.debian.tar.xz
Files:
 9db4de7ac72e8aea3f31202794a5837e 2639 net extra inetutils_1.9.3-1.dsc
 452ae548aa0421eee0bf2bfa21000e39 1363456 net extra inetutils_1.9.3.orig.tar.xz
 a9ffd917fc84da7ed1c1e6ebf7b7c2ec 76164 net extra 
inetutils_1.9.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVUqVJAAoJELlyvz6krlejPckP/iFUHoNNgOUMPhcUYtwp4O1t
EY0h2zamPc9PmOrPkkzNgQxx8/Q6fiOuVHFeFLbx8EYjDw0bvDHOLzrqt+mYUBsw
Y+LMKVkxrQP/ORr3SK84GJuck2SQ2zhJ0xlCrGw43SImkjuwEEg1nEXggdwHMUlJ
q3WmqZvQMx/7Oquu+A/w1Y4kZG68e5rJwxc31xMJIo0ob58rMUeiSEX7GBJm6k3w
41rdVJTDcdektUlKEMd8mPj3O1Ve3RHsVHTKHZr+iD443WB0lMx+9AuPui/I9Jo6
CwJ6uFRLAcpiHS+9JDu60Wkwt1x8Z7ZBtALK6/NWP6zp/XDR7Fu8qlOJxoV3VRO+
TVHVYqWGBhvXaBPnnh7XN2PqcmyIh5jXmc1VwTh2WirYlNq+LEmEZUu0IsIrEGrt
62Xa7x19x/YsFrJvWMiWglgeEO54tqlPM1evf+IsT9Rf7HyM9AQpJa48PWLHz5s2
UvlL018fWZV+tw2rZ229PUSgtsJOEQyM+Y8d8wgVtapfgPqJGicjiBwzBKcGkBw6
VV14B2TKYyY0Ewp9woi89XLcs4TjEBnr4KN1ANprvPijzBX2QeoPd2eWZT4oi3Te
S0ymXnoAMSH0dMF1w0hY4m+oNr6jSAPZmQmey6bYabd88OlEGU+kaCH0SV1izOnP
7dehJ5ALayKEp+F06yU2
=MMxv
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yslmy-0001uj...@franck.debian.org

Accepted unace 1.2b-13 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 13 May 2015 03:56:11 +0200
Source: unace
Binary: unace
Architecture: source
Version: 1.2b-13
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 unace  - extract, test and view .ace archives
Changes:
 unace (1.2b-13) unstable; urgency=low
 .
   * Use https for the copyright Format URL.
   * Switch Vcs-Browser to a cgit URL.
   * Now using Standards-Version 3.9.6 (no changes needed).
   * Move local filesystem location of GPL to a Comment: copyright section.
   * Move AUTHOR section in man page to a comment header.
   * Update SEE ALSO in man page. Remove ppmd(1), and add xz(1) and unrar(1).
Checksums-Sha1:
 c716f3ea3a9332499e031d3ca6f4849bc5252517 1736 unace_1.2b-13.dsc
 42c9b1c526f78c8137c812825c45585c2a574a36 7984 unace_1.2b-13.debian.tar.xz
Checksums-Sha256:
 9d67c08f20fefcdf2a95348b59322db023eba01743685552ec8e617db867 1736 
unace_1.2b-13.dsc
 cb6e312d1766b294b503ac562ceac56ca3c4f71f90b141fc47132945d6a55f08 7984 
unace_1.2b-13.debian.tar.xz
Files:
 704e96c0c381e47be2654d85fa0d051e 1736 utils optional unace_1.2b-13.dsc
 22720835061bb4667b2c809fea590fd9 7984 utils optional 
unace_1.2b-13.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVUrBKAAoJELlyvz6krlejmMQP/1v7c5Kpy15EztXJrQAkcBrM
j66z7msq4GujxWvtWqt+eLzEv/moa5z/F7hVHrXzx3ep2FAYxJPLJ95jV7CcWgt9
bPwFpUWJZhSPjHjmS2Sk+Wny/ewl5Rb9kKgllDTgZoZX0cLINb9Mlfc9z1z+0iHd
u7Fpw5W72jq8cnF6dejFkmhqgHI4TWLhpPeha2gi1//GG9yVIsq6NROcZeIyojVt
oUh85NjIX3Hgnd0JoGKsASebcqwHsWysgoWqXYSZ/cA9c1ps4CzylrZhIsooBxnz
7qup7IASKPOvOEws/SSgqzpI43kggQSro1uMkBgRYyBUxpOgOmkY42g3E9Oq1piu
hcuyDGY7QI+xzlU8/coys5Y3F+EZlEwnikLqs0rZE/maQ/KCaMXUZ+JMPo3qocUr
/YSqBLV3EZz8W8tzLKsQAWUgEHrWQQyQ5J6Nldr6Gb6Hb32/wr2xHxOlYI9bL6jg
bQy15LEfW8Smygnri6Pf4L3MYlBrcdFEE2Ur0bEUYpqw1/Py1jgH+x2hEV/wxsyB
kKJMgILWQxL5c9Uj3F9poTtP1zvfqzE5/Fa0f97Q1v6ERFPh56Ar6deerDTKEY4u
oo7ZVUB8BFPqSSNpDBHRFTq25Ob7demNZZrnjsFiKjZQCvjvRjZuA+kFBYA+OaHW
Hc+KPh3MVpULDrG0oq7m
=yg8g
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ysnj7-0007ub...@franck.debian.org

Accepted device3dfx 2013.08.08-2 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 09 May 2015 00:48:58 +0200
Source: device3dfx
Binary: device3dfx-source
Architecture: source all
Version: 2013.08.08-2
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 device3dfx-source - Linux 2.2+ device driver source for 3Dfx boards
Closes: 778213
Changes:
 device3dfx (2013.08.08-2) unstable; urgency=low
 .
   * Remove packaging history from debian/copyright.
   * Remove license clarification from debian/copyright, upstream sources
 have included a proper license notice for a long time now.
   * Switch debian/copyright to machine-readable format 1.0.
   * Switch Vcs-Browser to a cgit URL.
   * Now using Standards-Version 3.9.6 (no changes needed).
   * Remove debian/source/options, xz compression is the default now.
   * Use the debian/changelog date for the generated source module tarball
 mtime. Based on a patch by Chris Lamb la...@debian.org. Closes: #778213
   * Add a debian/watch file.
Checksums-Sha1:
 2054fb5e890f50e4f40bdcb501a9b475405fa541 1875 device3dfx_2013.08.08-2.dsc
 0707187f0cc7d635bec22c7404a9c7f456b5788a 11808 
device3dfx_2013.08.08-2.debian.tar.xz
 615f562aa95d4af5aa0581b88d85933bdcd50560 22862 
device3dfx-source_2013.08.08-2_all.deb
Checksums-Sha256:
 a5e8059e805042441c539ca3fdcfd4b1f5e1da8b992ce82e6e09b821bd7f6851 1875 
device3dfx_2013.08.08-2.dsc
 cf8271a417024272900e813ce049c16b07497fbaa6de6ce9cff7d72bf266de9e 11808 
device3dfx_2013.08.08-2.debian.tar.xz
 f0afc3844bd746d6d0f3803cecc36a820ac7f9b40cbe900883b4245bc53a74ab 22862 
device3dfx-source_2013.08.08-2_all.deb
Files:
 934a7262d723168ffd77f445b1e1de6f 1875 kernel extra device3dfx_2013.08.08-2.dsc
 c14b6efb579cfdc26b88e55e6cf22871 11808 kernel extra 
device3dfx_2013.08.08-2.debian.tar.xz
 6df9d70f581c4e4b0d585835b805c98e 22862 kernel extra 
device3dfx-source_2013.08.08-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVUrkGAAoJELlyvz6krlej/bIQAOUWQwcw4UW5RDc0AW9DM3xH
kSItOjpXmb2l3Dr0XLiI8Z9JjpEaBLDJw7oR+5eo7GyufD5BIi7380iqjxBss3DO
Vg2KOobG38NvFB/w13Fo2dXTNSacyZnoA1YtUNZarwLhnmPWZPO77NKuSxR4oKKq
I2RaYKKt54/MQrTqUDdHeHKufaarzEqA4xU+atO08yszAkxQ28RJPvmUfpYcZe2d
x5ghS6eLZ0hhs4eCGYsCym6buBZLiepEJtL5PSrSU4cZym767Aj+Gltgs23vh0c6
npbWl36/q3wjnJo8I+pb2+DJdmJ+D4vBw65wuojjtUBeFskATVdBQJHJML30e3uL
iEkkI8mWCt18raylJgvoEEbm04OiK26iMkVYOc6dhTAO40LAK9uZoOVuHqr1MfYz
M1uyRja5DGrRcEdpLGId8Dj80uTpd35nNZHEKrBTjakdzOonbOI54cLNyCJdV6lg
o0JXhPdoBguJxD2pQstkBP9VLxPwcRMOHQt7q3OhdPikLKSQPTos8IQkoC6mQy9c
u9XuCds7/F47hcvdMTvEEEjUjM5SlaWF9HQUdiwlgYZzigaP5yrph+7vebYu/8TN
G4Necl20aE6HTEYT6ql1WiOFMuRIdld5wMcmV3jz4fv+skRkB+V7MeUo4U0VQ4Ji
7JBItONAD9kGmhrm86Mn
=tjX9
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ysngd-0007y4...@franck.debian.org

Re: Bug#761348: ftp.debian.org: need machine-readable metadata about suites repositories

[Guillem Jover]

Hi!

On Sat, 2014-09-13 at 15:24:58 +0800, Paul Wise wrote:
 Package: ftp.debian.org
 Severity: wishlist
 X-Debbugs-CC: debian-devel@lists.debian.org

 Various places in Debian infrastructure (QA especially) hard-code
 aspects of the Debian archive (suite, code, component, arch names etc).
 This is a problem because after new suites or architectures are added,
 we have lots of places that need to be updated. Most of them can be
 fixed (help needed), however Debian does not provide information about
 which repositories are available where, which suites are provided by
 them, nor any information about the relative order of those suites, nor
 any information about which suites are archived.

There's also another type of archive-specific data, which I think is
relevant to this bug report, that currently needs to be duplicated and
translated at least on each high-level package manager frontend, but
other tools carry it too.

That is the list of package sections and possibly their descriptions
and translations (there's the priorities too, but these are more static
and entrenched in implementations so probably can be ignored). There
are currently hard-coding of sections in (at least):

Package managers (downloaders)


  aptitudesection-descriptions, aptitude-defaults.LL
  synapticcommon/sections_trans.cc
  aptdaemon   aptdaemon/pkcompat.py
  packagekit  backends/apt/aptBackend.py, backends/aptcc/apt-utils.cpp
  hildon-application-manager (not in Debian, abandoned)

Other (offline)
-

  reportbug   reportbug/debbugs.py
  lintian data/fields/archive-sections, checks/fields.desc
  libconfig-model-dpkg-perl
  lib/Config/Model/models/Dpkg/Control/Binary.pl,
  lib/Config/Model/models/Dpkg/Control/Source.pl
  dl10n   dl10n-check
  dpkg-wwwsrc/dpkg
  configure-debian
  configure-debian
  gambas3 app/src/gambas3/install/group/debian,
  app/src/gambas3/install/group/ubuntu
  vim runtime/syntax/debcontrol.vim
  zsh Completion/Debian/Command/_debfoster,
  Completion/Debian/Command/_dak


So it would be nice for every archive to provide a file with the list
of sections found in it, their description and translation. Perhaps
something like:

,--- (text lifted from aptitude)
Section: graphics
Description: Utilities to create, view, and edit graphics files
 Packages in the 'graphics' section include viewers for image files,
 image processing and manipulation software, software to interact with
 graphics hardware (such as video cards, scanners, and digital
 cameras), and programming tools for handling graphics.
Description-ca: Eines per crear, visualitzar i editar fitxers gràfics
 Els paquets de la secció 'graphics' inclouen visualitzadors de
 fitxers d'imatges, programari de processament i manipulació
 d'imatges, programari per interaccionar amb el maquinari gràfic
 (targetes de vídeo, escàners i càmeres digitals), i eines de
 programació per gestionar gràfics.
…

Section: …
…
`---

Thanks,
Guillem


-- 
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/20150511143710.ga28...@gaara.hadrons.org

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

[Guillem Jover]

On Sun, 2015-05-10 at 19:56:49 +0200, Julien Cristau wrote:
 On Sun, May 10, 2015 at 18:49:25 +0100, Wookey wrote:
  I'm happy if you change this - it seems like fixing a bug to me, but I
  will just throw in this observation from recent arm64 archive-rebuilds,
  that -j and DEB_BUILD_OPTIONS=parallel= are not exactly the same. Is
  that expected?

Yes, this is expected, there was a bug report recently asking to
clarify this in the man page, fixed in master and will be included
in the upcoming dpkg 1.18.0 release.

 dpkg-buildpackage -j is buggy.

No. This is the equivalent distinction between:

$ make -jN -f debian/rules build

and

$ DEB_BUILD_OPTIONS=parallel=N debian/rules build

You might not like the behavior, and that is fine, but that does not
make it buggy. (And BTW debuild also sets MAKEFLAGS.)

 It sets MAKEFLAGS whether the package
 supports parallel builds or not.  Whereas setting DEB_BUILD_OPTIONS lets
 the package know it's allowed to use more processes if it wants to /
 can, but doesn't have to.

Actually Makefiles that do not support parallel builds and do not
declare so with .NOTPARALLEL: are buggy, because upstreams do not
have any standardized opt-in way to honor a parallel build request.

Regards,
Guillem


-- 
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/20150511184016.ga18...@gaara.hadrons.org

Allowing both cross building and using an alternative compiler

[Guillem Jover]

[ Please followup on debian-devel (M-F-T set). ]

Hi!

There are currently two goals people are pursuing that seemed to
initially conflict with each other:

  https://wiki.debian.org/ReleaseGoals/CrossBuildableBase
  https://wiki.debian.org/ReleaseGoals/honorCCandCXX

But they can be made to coexist gracefully, if using the same
semantics as used by autotools but on a Makefile.

,---
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

ifeq ($(origin CC),default)
CC = $(DEB_HOST_GNU_TYPE)-gcc
endif
CC ?= $(DEB_HOST_GNU_TYPE)-gcc
CC_FOR_BUILD = gcc
`---

This allows the user to both set CC to any non-default compiler such
as clang or gcc-6, and supports cross compiling out of the box. I guess
that if people do not see any obvious problem with it, something like
this should probably be codified in policy.

I'm in principle planning to add the attached Makefile to dpkg-dev to
make this kind of usage easier for packagers.

Thanks,
Guillem
# This Makefile snippet defines the following variables for host tools:
#
# CPP: C preprocessor
# CC: C compiler
# CXX: C++ compiler
# OBJC: Objective C compiler
# OBJCXX: Objective C++ compiler
# GCJ: GNU Java compiler
# F77: Fortran 77 compiler
# FC: Fortran 9x compiler
# LD: linker
#
# All the above variables have a counterpart variable for the build tool,
# as in CC → CC_FOR_BUILD.
#
# The variables are not exported by default. This can be changed by
# defining DPKG_EXPORT_BUILDTOOLS.

DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

define dpkg_buildtool_setvar
ifeq ($(origin $(1)),default)
$(1) = $(DEB_HOST_GNU_TYPE)-$(2)
endif
$(1) ?= $(DEB_HOST_GNU_TYPE)-$(2)
$(1)_FOR_BUILD = $(2)
ifdef DPKG_EXPORT_BUILDTOOLS
export $(1)
export $(1)_FOR_BUILD
endif
endef

$(eval $(call dpkg_buildtool_setvar,CPP,gcc -E))
$(eval $(call dpkg_buildtool_setvar,CC,gcc))
$(eval $(call dpkg_buildtool_setvar,CXX,g++))
$(eval $(call dpkg_buildtool_setvar,OBJC,gcc))
$(eval $(call dpkg_buildtool_setvar,OBJCXX,g++))
$(eval $(call dpkg_buildtool_setvar,GCJ,gcj))
$(eval $(call dpkg_buildtool_setvar,F77,f77))
$(eval $(call dpkg_buildtool_setvar,FC,f95))
$(eval $(call dpkg_buildtool_setvar,LD,ld))

Heads up: Upcoming dpkg-buildpackage -j precedence change

[Guillem Jover]

Hi!

“Recently” when adding support for «-jauto» to dpkg-buildpackage, I
noticed that the semantics for the -j option were quite unorthodox.
The value from the DEB_BUILD_OPTIONS paralle= option takes precedence
and overrides any explicit value passed on the commend-line via -j,
(when -j should be overriding the environment instead).

I'm not entirely sure what I was thinking when I did that change in
dpkg 1.14.15 (2008-01), but that specific part seems entirely broken.
But even then given that this behavior has been like that for a long
time now, I'm a bit hesitant to suddenly change it.

If you happen to depend on this behavior and stuff would break due to
that change, please shout and I'll deploy a staged transition with
warnings and similar, otherwise I'll just go ahead with the change.

Thanks,
Guillem


-- 
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/20150510025347.ga15...@gaara.hadrons.org

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

[Guillem Jover]

Hi!

On Tue, 2015-04-07 at 22:11:18 +0200, Niels Thykier wrote:
   A) Use .deb (i.e. the regular extension) with a new section.

Is there any problem with using the existing debug section? Or is
the different section used to distinguish that these are autogenerated
perhaps?

   B) Use .ddeb (i.e. with an extra d).

What where the motivations for using a different extension? I can
see the motivation for .udeb:s as they need to live in a different
namespace, but that does not seem to be the case for debug debs.

Assuming that any issue with debug .deb:s is fixed in the tools, is
there any remaining reason to use .ddeb:s?

 On 2015-04-07 21:10, Niels Thykier wrote:
  Both have their own advantages and disadvantages.  In particular:
  
   A) means that almost every existing tool will handle the debug debs
  like a regular deb (which it is) and will generally work perfectly
  out of the box.
  - There are a couple of exceptions, but we are limited to something
like lintian and dpkg-genchanges.

I'd happily look into making dpkg-genchanges allow this.

  - There will be tools that might want to handle them differently.
Programs like dak and reprepro might want to (support) put(ting)
them in a different part of their repositories.

They could already do that by keying on the Section, no? Otherwise the
filename is also unique enough to be keyed on («*-dbgsym_*»)?

  - This is *currently not working* since dpkg-genchanges errors out
on the auto-generated .deb files.

See above. :)

   B) means that .ddebs can be special cased on filenames rather than on
  section (like udebs).  Furthermore, there might be a lot of things
  that do not need to support .ddebs at all.

Personally I think it breaks expectations, from muscle memory:

  # dpkg -i *.deb

to many tools that might process debs and expect them to have that
extension, which of course could be fixed but we have to take into
account tools outside of the Debian archive.

  - Downside is that adding support is a manual extra step for many
tools, that (besides the filename) would otherwise be able to
handle .ddebs immediately.

For example dpkg-scanpackages can be told to use a different package
type, but it cannot be told to recognize multiple package types for
the same invocation. I guess in this case you can cat the result, but
still:

  $ ( dpkg-scanpackages . ; dpkg-scanpackages --type ddeb . ) Pacakges

this would imply either fixing the tool or going around and changing lots
of scripts for custom repositories.

  - On the plus side: dpkg-genchanges in Jessie can support this
solution immediately with a minor warning.

Sure, immediate deployment is a plus, but I'd rather we'd carefully
consider the consequences of any such decission that might be pretty
hard to reverse course in the future in case we find it to be too
problematic.

 From my point of view, I am not strongly attached to one solution over
  the other:
   * I am slightly preferring A), but I am ready to implement either
 solution in the tools, I maintain.
   * The difference for debhelper is a single d and a section name.
   * The change for lintian is larger, but B) is the heavy solution
 and I already got a mostly working patch for that.

Barring any strong reasoning behind B) above, I pretty much prefer A).

Thanks,
Guillem


-- 
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/20150503165831.gb9...@gaara.hadrons.org

Re: Bits from the dpkg project: 1.17.x series, general news

[Guillem Jover]

Hi!

On Mon, 2015-04-20 at 15:01:48 +0200, Thibaut Paumard wrote:
 Le 18/04/2015 21:27, Guillem Jover a écrit :
Portability in dpkg is very important, to be able to support downstreams
and people who use it on other systems, or even package it in other
(non-GNU/Linux) distributions. But for many such systems I'm currently
porting purely through documentation. And as such, subsequent build and
run-time issues are clearly reactive, but I'd like to switch to a more
proactive model. So I'd very much appreciate if either interested
parties could provide access to such systems, or setup some kind of
continuous integration system from git. I'm thinking specifically of
systems such as non-glibc based Linux, FreeBSD, NetBSD, OpenBSD, Minix,
Solaris, Mac OS X, HP-UX and AIX.

 Possibly stating the obvious, but a you aware that fink (a package
 management system for Mac OS X/Darwin) is based on a dpkg fork? Have you
 been in touch with them?

Yeah, I'm aware (https://wiki.debian.org/Teams/Dpkg/Downstream). I
try to keep track of the delta in all downstreams I know of, and try
to fix stuff on my own or merge what looks good. In the case of the fink
project, I've been in contact with them on and off and merged patches
from them and tracked down issues or got patches tested with their help.
But given that they are stuck with dpkg 1.10.x switching to the latest
branch has been a slow moving target for them. Also there's still at
least an unresolved reported test suite failure for dpkg-divert.

 The MacPorts projects also packaged dpkg (1.14.29).

Getting this to 1.17.x would be great.

 I can presumably update, build and test the macports package
 occasionally (it doesn't have an individual maintainer atm), but I
 cannot set up an automated framework (although MacPorts does have
 autobuilders).

Barring anything better, testing git master (or a released tarball if
that's easier) from time to time and reporting build or test suite
failures would already be great!

Thanks,
Guillem


--
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/20150420184631.ge12...@gaara.hadrons.org

Accepted dpkg-repack 1.41 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 11 Apr 2015 17:04:52 +0200
Source: dpkg-repack
Binary: dpkg-repack
Architecture: source all
Version: 1.41
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers debian-d...@lists.debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 dpkg-repack - Debian package archiving tool
Changes:
 dpkg-repack (1.41) unstable; urgency=low
 .
   * Actually fix the blank line insertion for the descriptor mangling.
   * Add a Vcs-Browser field.
   * Slightly reword package Description.
   * Remove blank lines between sections in man page.
   * Mark architecture all in bold in man page.
Checksums-Sha1:
 21c33486eda1829033c1d2d919ccdf92beb8c949 1635 dpkg-repack_1.41.dsc
 6dcd4ea807dde29ad0cde4d041b230f579f6eb55 17260 dpkg-repack_1.41.tar.xz
 53e13c448dcc3f2a539a975d67d4a6fc9b230ee1 13476 dpkg-repack_1.41_all.deb
Checksums-Sha256:
 57e627347fd8fd906f2adbdd2bdc733dec5df2375d99221be5f155bd76ed19c6 1635 
dpkg-repack_1.41.dsc
 1ba6945a5a50ffaab9a8dae3ee877cdebed36ac31da8fb4da0bd46c314657f6b 17260 
dpkg-repack_1.41.tar.xz
 c99b7c500c5c4e5d6f3f6be5bba6bdfbe825e50715096af6a7a72bbdab5175a9 13476 
dpkg-repack_1.41_all.deb
Files:
 165ace20e167d2800b0534d7a420fd32 1635 admin optional dpkg-repack_1.41.dsc
 ce524d62df5136ec276409e557aa172d 17260 admin optional dpkg-repack_1.41.tar.xz
 354094e69bf12e1ed7ac5096ebac85c6 13476 admin optional dpkg-repack_1.41_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVKT1UAAoJELlyvz6krlej02sQALJrefPADeP6JZsCsiyMH561
kwMVWH64F5TY9MNFlWAqh4eFPT0LzEI9PfSDrmR0axjD+hRjzoTp1wyJUF0KQBi1
KvOJ0T8IaP6DTkXAZGPJxAeT9lQ3gKFrCc18yxfCOXAyZ/PjVnHrwXd9qA4cEGmN
Y8C0fi8FtZehwisLaxPJsftyHkFSyntGPJar4k+N4uJjGeUO5YqwfdfPOR8HZnr5
jd3ixufKee+pHBcTbhxNkFl33nU8LeSokcOCDH5HcXcemDHQ+js8YnDqqfOKDFth
WQUdTUpZxS776BJ5ixfqKRzSdExEqjHPQQazD8rpq6O2VGhCj0soPPU9KRmiVUpJ
FUBkz4ehjMDLiE9PJ+BJ6dY3IFXAAJCVl4uoMOfc2+v+y1M+NTki9b915m+FOeh4
MEZEZcvZAXgw7dbM/cb0Y4R8S3B61exTd8QNfVOHXcE/6Dpx/JLlS8LFywn1Rg1o
pxhc0yQGA/S/rLvQ/IVdLuT5s6gM9moSmRWFER9JacQwK/IYSMvMXO+ITSRMW5Nj
iFNFlKiYzsJJYkUw5TaxxfwjIyCCDqamJF97XWq5Tc+YUuGMT+m+SdilEoFQzFSD
x1arj//rZb89nv05JeF+FUzKhcHFEVHp17gJzo8DN3Xli2QSQpBpfK5xDPB3uG75
+R/QfbIXKcDYIQ4DfbFs
=pyln
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ygxet-0006uy...@franck.debian.org

Accepted arj 3.10.22-13 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 28 Mar 2015 04:22:18 +0100
Source: arj
Binary: arj
Architecture: source
Version: 3.10.22-13
Distribution: unstable
Urgency: high
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 arj- archiver for .arj files
Closes: 774015 774434 774435
Changes:
 arj (3.10.22-13) unstable; urgency=high
 .
   * Fix buffer overflow from size under user control, causing free() on an
 invalid pointer. (Closes: #774015)
   * Fix absolute path directory traversal. Fixes CVE-2015-0557.
 (Closes: #774435)
   * Fix symlink directory traversal. Fixes CVE-2015-0556. (Closes: #774434)
Checksums-Sha1:
 57ee5fe96805c416050fd806686c995b1b8799d9 1845 arj_3.10.22-13.dsc
 43dbf02ffbcd78a1d408215f63dbf7209eba9634 15904 arj_3.10.22-13.debian.tar.xz
Checksums-Sha256:
 f21fc0ac96208eb0a241dd6a64297041799dfe03a10ab55a4625690efd5ae58e 1845 
arj_3.10.22-13.dsc
 d74588f13a2de780d762d3405b0216a02cf4e55bda4ac4703cab94310ac3ea46 15904 
arj_3.10.22-13.debian.tar.xz
Files:
 b275600afa1d8303fd2aaeaf1ad218af 1845 utils optional arj_3.10.22-13.dsc
 2623eac2713d5d0d116261c1cf707dc8 15904 utils optional 
arj_3.10.22-13.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVFidXAAoJELlyvz6krlejBV4QAIot49gZCXUFqJ6GgxnVlptu
dtaH0pdayH3LV3JbgifMEM3cmYiyi9TDipFKTzXK4Od8kWkUDROt583eNUp56R9e
fSgAPWrUS7yEuj4X4GYP0VvHEEQHaE4IX7XBC3R6/T354nICQ7hMi8gqi6oBnA3T
04ZzS0hNPkZDYpmqEvxRHtGW6egVEJQJV6YDN3HOuocTD8lDgTbwpNwPsC9gjMyM
WECc+gdHSMlYBQAZxK8n/jsIfR8C1o4dJ0ot/VGgpN45rCG/fh+ogqYMliDP3T2Z
ZO4iA/q9QkmotNLCFa1+EExg0wMLou4eSY44Te2F4gmbv62jspcdu04OSHvnninv
h2/Y4aJGn3uJduF9/17ME77mJsCZcWxMeIB56G0L1wDjz9E6LJodQbF3qMFDSPmR
yYoONhTdRMFTJ4nLLpgapFZKAVvoSR3hLUpt9dy+RVyrPLmlOH48AhXZtfWuaiSB
cK9dBcsrcLhMRY0sPKedc45TXfAm1MishIMRo56QOt9cZgRKfchdZ06BTt/Q6HmO
j4sE5OPPgK2zNIT7QRA8o4qfGQrazZAmqVPtPyqJmw5UXa04Q4fMKiVh+JMA/gIC
DAOkW90RlHI10/k08RbFJhZPFbNSeCnWUH3oEjEr/E19H951UyMizOxQo1K39KSQ
yOp9s5vHAYO65Apj9BXJ
=bX23
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ybidl-0002y2...@franck.debian.org

Re: CUT rolling release debian BUT a cautionary comment

[Guillem Jover]

Hi!

On Sun, 2015-03-08 at 03:50:50 +0100, Adam Borowski wrote:
 On Sat, Mar 07, 2015 at 12:38:53PM +0100, David Kalnischkies wrote:
  If I remember correctly btrfs mostly showed its ugly experimental
  state by being very slow which is hard to justify in an environment
  where everyone already complains how slow upgrades are in Debian.
  Hopefully its better now…
 
 The cause is dpkg doing fsync() after each write, to placate a deficiency in
 traditional filesystems: there's no way to tell them to make a barrier other
 than a full fsync.  This is because POSIX provides no API to do so.  And
 fsync isn't that bad on a simple filesystems, but horrible on ones that
 provide additional guarantees.

No, the problem was precisely on some of those new filesystems, that
required fsync(2) to not get zero-sized files on abrupt shutdowns, and
at the same time behave(d) in an extremely poor way when confronted with
the requirement they impose on applications:

https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is_dpkg_so_slow_when_using_new_filesystems_such_as_btrfs_or_ext4.3F

 There was some recentish work (kernel 3.5) that greatly reduced the cost of
 fsync, but it's still slower than, say, ext4.

Last time there were benchmarks performed on ext4, even after it was
claimed to have been fixed, it showed it was pretty much suboptimal,
compared to ext3 for example (see the kernel bug referenced in the FAQ
entry).

 Until dpkg gets filesystem transaction support, you can wrap dpkg calls
 with eatmydata: the worst that can happen is that in the case of power
 loss you'll have to issue a rollback manually.

As long as Linux does not have an unified filesystem-independent way
of doing that, I don't see that support coming, the current state is a
mess. You can always use dpkg invoke hooks to perform the snapshots.

Thanks,
Guillem


-- 
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/20150317093347.gb17...@gaara.hadrons.org

Accepted unace 1.2b-12 (source) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 24 Feb 2015 10:47:45 +0100
Source: unace
Binary: unace
Architecture: source
Version: 1.2b-12
Distribution: unstable
Urgency: high
Maintainer: Guillem Jover guil...@debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 unace  - extract, test and view .ace archives
Closes: 775003
Changes:
 unace (1.2b-12) unstable; urgency=high
 .
   * Fix buffer overflow when reading ace files with file headers smaller
 than expected. Fixes CVE-2015-2063. (Closes: #775003)
Checksums-Sha1:
 7ce5606eb4b3d618605f7c233a01ce423418ad88 1734 unace_1.2b-12.dsc
 c13e08ae17fcff28ce65051b8e048501aca3d4f8 7972 unace_1.2b-12.debian.tar.xz
Checksums-Sha256:
 a2313fe1d5d37e4e3c44305c64194fee23e5f24602277bad4dd9cc61986160ae 1734 
unace_1.2b-12.dsc
 dc662bfccd1a056ae95d4a9f9f74aff9d815efe9981a621b95900db38ef3749b 7972 
unace_1.2b-12.debian.tar.xz
Files:
 160267e4534cdb5f717f236b09be3339 1734 utils optional unace_1.2b-12.dsc
 f4f1c590183cf37d083d6159b2e520c9 7972 utils optional 
unace_1.2b-12.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJU7FoKAAoJELlyvz6krlej75AQAOPNh1KmDGaVlbBybtywdeTM
YS5eiOiWNHQTL1wddP8rmyu5uvlUk/s++69HpK1LyzL2tWNeWc1xwVXRrbnhFWsZ
mYeaxXhnTxoOPwkCcxBeh9LU7/JJSknVJgWVXjGPIk8On/UV6uCGJDLxhvVP020N
xH0tNWBYldqrNMTrRiJbDO7qNZ8wdbGnFN7Q2GCCAOoUvKUiQAr8fmzZbmLWiB5g
UgKGvFXzVTIJ/gEbhJyB+ZsMJb/2e9NCINO9hqjufhfX2RUQ+ZWxTYXJVoVcR+Fn
tDFSe3545c/fjKZ5FtyMLLTtWVuzD0HmvDj2j35rnuG/fI0R/Y6qq3RLG4fk1F6Q
cmjb5pE9w9b+a2/fLL5vsiawrEEw2qIEdkY/z0g5u8gfw+IYvOX+SgxudBhpttwE
HXurOM932IgOZG2MPs+G7XYhCidOZpbbYFlOAMl7j53cCOvN3V4EuXnxHNaommwg
xacMlEVghKmx7sWP61IOhuRGsfQOZQBM074xfuRvddqlSK9wxypYNYulPZnxxbK1
dhvyPZBuSSf7Zmvhm5JOSGw6NHID8Pihsed+JFSD2kXhMLk/tlecdo6etN340oBA
+sh4CN0MY66xt0Bv6zigT8864hshSIJt67LvRBhltw8KrQmAREeA6DVd0qIpIPr8
5Fp38EVGEUVb2QRZdf6X
=mneD
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1yqdxe-0005bh...@franck.debian.org

Accepted dpkg 1.17.24 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 22 Feb 2015 22:54:51 +0100
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source all
Version: 1.17.24
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers debian-d...@lists.debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 774794 775124 776984 777044
Changes:
 dpkg (1.17.24) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Add missing versioned Breaks on packages creating trigger cycles.
 Namely debian-security-support, doc-base, gitweb, grace, install-info,
 libapache2-mod-php5, libapache2-mod-php5filter, php5-fpm and xine-ui.
 Closes: #774794
   * Switch versioned Breaks for trigger cycles from = to  relations (with
 the necessary version adjustments).
   * Add Conflicts for removed packages expecting dpkg to ship install-info.
 Namely octave3.2-info, octave3.0-info and polgen-doc. Closes: #776984
   * Do not accept unknown user or group names on «dpkg-statoverride --add».
 Regression introduced in dpkg 1.17.11. Closes: #775124
   * Check that HAVE_DECL_SYS_SIGLIST is 0 instead of undefined, to fix a
 build failure on uclibc based systems. Closes: #777044
 Based on a patch by Alex Potapenko opotape...@gmail.com.
   * Disable dependency checks on trigger processing. There are still trigger
 cycles showing up this close to the Debian release, which are hard to
 detect automatically as they are caused by maintainer script actions.
 Requested by Niels Thykier ni...@thykier.net (Debian Release Manager).
 .
   [ Raphaël Hertzog ]
   * Drop myself from Uploaders.
 .
   [ Updated programs translations ]
   * All complete languages (shadow package).
   * Thai (Theppitak Karoonboonyanan).
 .
   [ Updated manpages translations ]
   * German (Helge Kreutzmann).
Checksums-Sha1:
 80153e56f90c61ed63aac6446797c8c23df9958d 2018 dpkg_1.17.24.dsc
 9a66df2865cb51e6ea9b1285f7a52e69a36d789c 4388276 dpkg_1.17.24.tar.xz
 fb49c17a12a7a1703779cc75f6587547fd528ae5 1541742 dpkg-dev_1.17.24_all.deb
 9a818a4ba9af8f65f9501b4e7a192608a6d60646 1067872 libdpkg-perl_1.17.24_all.deb
Checksums-Sha256:
 5c0fc795257091374122d622c5d32b6e7219e95d601733c6d49e629b7c89c1a9 2018 
dpkg_1.17.24.dsc
 afd60233ef090aa5a4d9e181b8986d1f5deb23a3428a2309b6b4ec448d539eac 4388276 
dpkg_1.17.24.tar.xz
 901164b4443a38b1a4a2b56f5fbca19223acc2f05a415023328e296aee4c0090 1541742 
dpkg-dev_1.17.24_all.deb
 ae1cd2fb29da1195688d05ff37b814fab0ae4e80fd337ef999742fcd85a9efef 1067872 
libdpkg-perl_1.17.24_all.deb
Files:
 b04f7e0d3db638a7bec096a3c91ea122 2018 admin required dpkg_1.17.24.dsc
 4c62dd2675ea75759faf03e2c758a805 4388276 admin required dpkg_1.17.24.tar.xz
 d10c9cf85996db8791786ece923b89f5 1541742 utils optional 
dpkg-dev_1.17.24_all.deb
 93390d917a17d4e43713afd080f113e4 1067872 perl optional 
libdpkg-perl_1.17.24_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJU6ldIAAoJELlyvz6krlejVZIP/jM7nBNwVe65IX/tyZRF0esY
brlA/5Pigi0U627QzKNyEH3k9yBRtDhvdxSg6B3WslZMMnlLMq8PKT5+BxF1+XJZ
onkF7VWbbfqnOQM3bFHh7AU74BXKsyKFT+9u2Dbw1Psm+zREQhLnoyZPNlIPTQ6q
GJfMySC6OpBWIj62XaaBjiNnqq9optSzOsD7IJZXTRBmIqEZg57MUsjEsFVuCmiA
dXHq8d1PiWNdkVSVF2LpMmTr0HR8+/8LdtmMVSy4sNyzBcrYtyK8T84Ej1RjNXh9
EHxDKrAa88wAHsooR3MENNU7+vDEUpUzkrtzKKvVyTtKpXuLtwUnwMw2WiBAaIQ5
lYaJ/w7f9AZdKH66l5Jfw1jcR7GzQEjI90KhokPY61vkOBFQRsHUjo+ng+QvWHTD
Lexj4qDzDSDPorYNou4QgJxF0co/XsfCGmxSce9iAlK3ZZtTHBj5aRb3JXCTln00
Nj69z3ggdVnQxlJNYihn7KiVu42LFk7UrLU95BGbW7tl8LvDUEhTrByt3EnrcRDD
f0xcAW4ZbhuBpx5lJRED4URZ18i0ScslmaydEjJp5g4Bwogqf01wO5xdvMEzeDuL
Dyf2EK+OrA/sbUO8sG22x3gUoQf8G2OLUzFUwDNjUJpuKs3Ej3W4Pk2gD7VbcW6p
MOBM0TClNOV8zcPByQMk
=VjHO
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ypggp-0002mg...@franck.debian.org

Re: dpkg-capoverride (?)

[Guillem Jover]

Hi!

On Fri, 2015-02-20 at 11:30:02 +0100, Santiago Vila wrote:
 Would it worth to have a procedure like dpkg-capoverride so that
 whenever a package needs to change a capability, the change gets
 registered somewhere other than the filesystem itself?

Yes and no. It might be more convenient, but it introduces other
problems. POSIX capabilities (not to be confused with capability-based
security!) are defined by a withdrawn POSIX draft spec, and the subset
of POSIX capabilities specified in that draft is quite limited, the rest
are Linux-specific extensions that have grown organically w/o much
thought, many pretty much amount to root rights anyway.

I'm not aware of any other (non-Linux) system implementing POSIX
capabilities, which means that if something else got to implement them,
the non-specified POSIX capabilities might not match 1:1 with the ones
found in Linux. So either dpkg would need to try to map them as best as
possible (if at all possible) or it would need to punt the problem to
the packages, which would need to handle the differences, so it's a
leaking interface no matter what. Not very enticing.

Another option could be to add a new option to just preserve all xattrs
on upgrade, or a specified subset, so the admin or the package could say
for example to preserve «security.capabilities» if present.

See #502580 for more context.

Thanks,
Guillem


-- 
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/20150220192934.ga19...@gaara.hadrons.org

Re: new pre-dependency: perl{,-base,-modules} - dpkg (= 1.17.17)

[Guillem Jover]

[ CCing debian-release. ]

Hi!

On Sun, 2015-01-18 at 20:12:55 +0200, Niko Tyni wrote:
 In order to fix trigger related wheezy-jessie upgrade failures in
 xfonts-traditional (#774844, cc'd), I intend to make the main perl
 binary packages (perl, perl-base, and perl-modules) Pre-Depend on dpkg
 (= 1.17.17), which has this change:
 
   * Defer trigger processing if the package does not fulfill dependencies.
 Closes: #671711
 
 Together with making the jessie perl-modules and perl-base Break the
 wheezy perl, this should ensure that the xfonts-traditional trigger will
 not run when perl is in a broken state during upgrades.
 
 Please see the #774844 bug log for details, and let me know if you have
 objections or other suggestions.

I've not looked into the details yet, but just to comment that there's
been talk about possibly reverting that fix, because in some error
situations it can get apt into an unrecoverable state (#774124). :(

Of course reverting that fix brings back all upgrade issues related
to trigger processing w/o the required dependencies. Which are
probably more, and easier to get into.

(I guess this just calls for both a fixed apt, and a dpkg that
workarounds any such situation.)

Thanks,
Guillem


-- 
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/20150119101504.gc20...@gaara.hadrons.org

Re: length of a package extended description

[Guillem Jover]

Hi!

On Sun, 2015-01-11, Martijn van Oosterhout wrote:
 On 10 January 2015 at 17:27, Guillem Jover guil...@debian.org wrote:
  I think fixing translator tools would be an improvement, because it
  would reduce translator work in other situations too, by chunking the
  description on long lists (and not necessarily just for godzilla-sized
  ones :).
 
 Since forever the DDTP project has always considered the paragraphs to
 be the blocks that people can translate. I can certainly see that in
 this case you don't need to see the surrounding context to be able to
 translate it, but is this always the case?
 
 Not being a translator myself I'm not sure if it better to provide the
 whole chunk, and make the tool recognise paragraphs, or to split the
 lists into seperate chunks to translate seperately...

On Sun, 2015-01-11 at 16:57:09 +, Joe Dalton wrote:
 You definitely need to see/know about the surrounding context. (it
 might be done differently than today, but the need is there).

I think those are orthogonal, you might want to *see* some surrounding
context for lists, but that does not mean that the chunk to *translate*
needs to be the entire list. In this and similar cases it's more
convenient to be able to translate single list items, because they are
supposedly somewha independent from the other items in the list.

Thanks,
Guillem


-- 
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/2015083256.ga7...@gaara.hadrons.org

Re: length of a package extended description

[Guillem Jover]

Hi!

On Sat, 2015-01-10 at 07:20:31 +0100, Christian PERRIER wrote:
 Please also note that identifying lists in package descriptions
 might be a very interesting thing to do, given the various way you
 (maintainers) all have to make lists, given the loose rules for
 writing package descriptions (just think about bullets not being
 standardized and neither are wordwrapping rules).
 
 So, even shorter followup: what you suggest is impossible.and will
 even break hundreds (thousands?) of existing translations. 

I also think it would be best to switch that Description to use list
syntax. Daniel Burrows prepared a policy proposal some time ago, and
did some analysis:

  https://wiki.debian.org/Aptitude%3A%3AParse-Description-Bullets%3Dtrue

the analysis might be outdated by now, but given that this aptitude
option has been on by default for a long time I'd expect problems would
have been reported over time. It would still be nice to standardize on
something like the above.

 So, no, fixing the translators tools is not an option. Whether or
 not texlive-* packages are too long is a debate I already had with
 Norbert in the bug report he mentioned. He gave a rationale which
 doesn't entirely satisfies mebut makes sense and I decided that we
 both have better things to do than argue over this...:-)

I think fixing translator tools would be an improvement, because it
would reduce translator work in other situations too, by chunking the
description on long lists (and not necessarily just for godzilla-sized
ones :).

Thanks,
Guillem


-- 
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/20150110162739.ga32...@gaara.hadrons.org

Accepted dpkg 1.17.23 (source all) into unstable

[Guillem Jover]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 23 Dec 2014 17:45:44 +0100
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source all
Version: 1.17.23
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers debian-d...@lists.debian.org
Changed-By: Guillem Jover guil...@debian.org
Description:
 dpkg   - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect- Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 771264 771673 771682 771691 771730 771893 772841 772965
Changes:
 dpkg (1.17.23) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Use a matching group instead of ${^MATCH} in s/// in dselect build script.
   * Skip tar extractor tests if tar is not GNU tar = 1.27.
   * Reset the trigger cycle tracking on unsatisfied dependencies during
 trigger processing. Closes: #771730
   * Fix out-of-bounds buffer read accesses when parsing field and trigger
 names or checking package ownership of conffiles and directories.
 Reported by Joshua Rogers megaman...@gmail.com.
   * Add versioned Breaks on packages creating trigger cycles. Namely auctex,
 apt-cudf, ccache, cups, distcc, fusionforge-plugin-mediawiki, gap-core,
 gxine, hoogle, icecc, libjs-protoaculous, mcollective, pypy, wordpress
 and xfonts-traditional.
 .
   [ Updated programs translations ]
   * Basque (Iñaki Larrañaga Murgoitio). Closes: #771893
   * Catalan (Guillem Jover).
   * Czech (Miroslav Kure).
   * Esperanto (Felipe Castro).
   * French (Sébastien Poher).
   * Italian (Milo Casagrande).
   * Portuguese (Miguel Figueiredo).
   * Russian (Yuri Kozlov). Closes: #771691
   * Simplified Chinese (Zhou Mo). Closes: #771264
   * Spanish (Javier Fernández-Sanguino)
   * Swedish (Peter Krefting).
   * Thai (Theppitak Karoonboonyanan). Closes: #772965
 .
   [ Updated scripts translations ]
   * Catalan (Guillem Jover).
   * Polish (Łukasz Dulny).
   * Russian (Yuri Kozlov). Closes: #772841
 .
   [ Updated manpages translations ]
   * French (Sébastien Poher).
   * Italian (Beatrice Torracca). Closes: #771673
 .
   [ Updated dselect translations ]
   * Catalan (Guillem Jover).
   * Czech (Miroslav Kure).
   * Norwegian Bokmål (Hans Fredrik Nordhaug).
   * Polish (Łukasz Dulny).
   * Portuguese (Miguel Figueiredo).
   * Russian (Yuri Kozlov). Closes: #771682
   * Spanish (Javier Fernández-Sanguino)
   * Vietnamese (Trần Ngọc Quân).
Checksums-Sha1:
 4460124f0ba87183b554af68105e21133a169b7b 2057 dpkg_1.17.23.dsc
 ed1754f56b1ae62e9ba9ef615a21b40c126532ea 4386124 dpkg_1.17.23.tar.xz
 0df35221bee33038044d1c20ce34d8659ab5110d 1539234 dpkg-dev_1.17.23_all.deb
 929181dacc084d4e785cc44989e8b36e778eed3d 1065136 libdpkg-perl_1.17.23_all.deb
Checksums-Sha256:
 4e5b3274ff02b0580356ed1528eb6b45db2e33fbade30f709f3a1009341f34ce 2057 
dpkg_1.17.23.dsc
 90c4af92fc248a7542cf6db1141d69b042130abd82781943b3c2608e78f860b5 4386124 
dpkg_1.17.23.tar.xz
 42d605ab246a525f64f4c14e49d09d7419c24c1a0651be072b88cf29fd2188df 1539234 
dpkg-dev_1.17.23_all.deb
 29990a695aa9b76348087e201955625e7fd93742e6722d39fdf43afeb28ced10 1065136 
libdpkg-perl_1.17.23_all.deb
Files:
 fb28bd2215fdee5e94fad167c88429e1 2057 admin required dpkg_1.17.23.dsc
 1d4b8eba5823e0a2b1c6f1f690fecbee 4386124 admin required dpkg_1.17.23.tar.xz
 d3107807aa83e0850203e15a691419bd 1539234 utils optional 
dpkg-dev_1.17.23_all.deb
 dc47299b233c496dec1ac9e3f4658bcc 1065136 perl optional 
libdpkg-perl_1.17.23_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJUn0uHAAoJELlyvz6krlej9VwQAOBv6zWIXiWWrF/uKD0Xbc9v
fkjUkjG3FfSs5+CQcx7RJlj7uT6ppprYfB4dkfPcn5WynI1uKXMEVidBolEO5csi
3xWr+hahk5u6CNYgFM309l1ZTwAzZ4oBSU1rrVtx4LDT87An4CDEhcoxPjHCNhGq
16KHQvt+yWhCxX492ig4nnWx24O8IIDhgc3+vvQ8ZPT0+qwXV7KOuqT9IQzm9FrB
+9kqgGgAPmz6u1Iv6dfI/r4NL7/t+6b+bCX/6/j8MHcuh9MtRcMYZ1Xr3/6og3mf
DZ1ozQP6l2LTOn0aVctKL7yzejGima2zjBzp9ufPkrU8zK9lVeUwzgBXvasN6Zfv
D+egC1R5FU42FWtJJpwe3pgsMhXfLvvjundGcB41WKyysKqYald30HSUvD5zqHhK
F5KjnFvV9n9ry6ewRYSBCfSkW25c6K7H2YUmuzK+r4at/yFkKNIdVu7uxjujx7Ex
ojI6LAkgNaGGsgrBTkoBsMh7xgqcEtf1CJgiz5J6JrpxbyuTbIU0r1bsyyVvIPLc
ybsIH5g2yVjakfddovj4Yif/OE3qgAZUzltVwb30jcGy74fW74zFqnOzK99ZOKBv
JZavPQ3YA3gYSkX0/J4JJosddWMqwUNIzvD8ouNU3Gcuw3t1s9Fr7X5OFUNnnI6z
s6f8Wm65dY7ST2FFCoYj
=5L6P
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1y52jb-0007ya...@franck.debian.org

Re: one package altering other package's postrm

[Guillem Jover]

On Sun, 2014-12-14 at 15:26:37 +, Philip Hands wrote:
 Alexandre Detiste alexandre.deti...@gmail.com writes:
  I've sent a one-liner patch, as this put the least work on cron maintainers:
 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773095
 
  I guess they can apply it right away, even during the freeze;
  if there were a new RC bug popping up;
  this could even be included in Jessie.

  To me too, I guess I could check in preinst
  [1] that /etc/cron.allow or /etc/cron.deny even exists (by default no)
  [2] that some version of cron without this patch is installed
  before deleting cron.postrm as last resort.

As mentioned before, just add a versioned Breaks against the cron
package not supporting that, do not mangle its maintainer scripts.

 If this is something you're expecting to come up during the upgrade,
 then one coud solve it by (assuming that you find that the files exist)
 simply hard-linking them to another name then you can hapilly let the
 untouched postrm do whatever it likes.

 Then in your postinst, check for the presence of the backup files, and
 move them back into place if they exist.

If using current apt with APT::Get::Purge=true or --purge, or the
aptitude TUI and marking cron for purge, the conflicting package will
get purged before the other package is even in the picture. If libapt
was using dpkg selections for removals, then dpkg would first remove
the conflicting package then unpack the replacement and afterwards
purge the conflictor, which would allow to do backups of those files.

 On the other hand, if the problem is that the upgrade causes a remove,
 and then some time later the user is going to tidy up by purging cron,
 then rather than simply removing the postrm, you could edit it, thus:
 
   sed -e 's#rm .*/etc/cron.allow#: #' /var/lib/dpkg/info/cron.postrm
 
 although that still seems like a bad thing to be doing, but as long as
 you discuss it with the cron maintainer, and ensure that the pattern is
 going to match all versions, then you'll at least only be breaking
 things for downstreams that have decided to change that line for some
 reason.

This also breaks with back and forth switches. Say you have cron, switch
to systemd-cron (which disables the puring in cron), switch back to cron,
purge systemd-cron, and after a while purge cron, leavinge behind cruft.

 Making the files be conffiles of a common package seems like a better
 way to go to me.

They cannot be made conffiles, because their mere existence changes
cron's behavior.

Thanks,
Guillem


-- 
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/20141215155143.ga5...@gaara.hadrons.org

Re: one package altering other package's postrm

[Guillem Jover]

Hi!

On Sun, 2014-12-14 at 14:26:19 +0100, Christian Kastner wrote:
 On 2014-12-14 00:36, Guillem Jover wrote:
  There are some possible more “correct” ways to fix this, for example:
  
* Move the handling of those (and any other) common files or dirs
  (like /etc/cron.allow, /etc/cron.deny, crontab.5, /etc/crontab,
  the /etc/cron.* dirs and placeholders, and possibly also the cron
  spool) to a third package (say cron-common/cron-support/cron-base/etc)
  that both packages depend on.
 
 I believe that in the long-term, this would be the most reasonable
 solution. The cron package currently ships these files but really, these
 follow from standards and established practices.
 
 We already have some smallish hacks WRT to the above-mentioned files and
 cooperation with bcron; splitting these files out would probably make
 these hacks no longer necessary.

Yes, this is the only correct solution, anything else is just less bad.

* Or change cron (and systemd-cron) to take into account each others
  presence to not purge those files in that case (although this one
  is not future-proof).
 
 Isn't it the intention of purge to remove files regardless?

Well, if the conclusion is that at least those two files are a shared
resource, which they seem to be, because they are never created by any
package, but are somewhat the responsibility of a cron implementation,
then I think it makes sense, as a temporary workaround, to take into
account if there are other cron implementations around and not remove
them. Of course the problem with this approach is that you need to
hardcode the list of current cron implementations in the archive in
all other cron implementations, which does not scale and is not
future-proof. But better than removing the postrm, because that
will disable any other cleanup the other package needs to do now or
in the future on removal/purge.

 I was under the impression that installing systemd-cron would result in
 a remove of cron, and a purge would be an explicit request for,
 well, a purge of all its stuff.

The problem here is that those files are not its stuff. And while
purging on upgrades or by default is really not a good idea, given
how apt is currently implemented (which forces removals before the
new conflicting package gets installed) the situation right now is
a bit worse than what it could be.

Thanks,
Guillem


-- 
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/20141214135935.ga29...@gaara.hadrons.org

Re: one package altering other package's postrm

[Guillem Jover]

Hi!

On Sat, 2014-12-13 at 23:09:08 +0100, Alexandre Detiste wrote:
 Would it be OK / ugly / forbiden to do a
 rm -f /var/lib/dpkg/info/cron.postrm
 in systemd-cron preinst script ?

This would be just wrong and unnecessary. This is not the prerm case in
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_dpkg_be_told_to_avoid_invoking_a_harmful_prerm_from_an_installed_package_on_upgrade.3F,
which cannot be avoided.

 This is needed to avoid that /etc/cron.allow  /etc/cron.deny disapears
 when cron is purged but systemd-cron still needs those. (from v1.5.1)
 
 In http://anonscm.debian.org/cgit/pkg-cron/pkg-cron.git/tree/debian/postrm :
 # if [ $1 = purge ]; then 
 #rm -f /etc/cron.allow /etc/cron.deny
 # fi
 
 The handover of custom /etc/crontab works fine thank to the Replace:
 in d/control

There are some possible more “correct” ways to fix this, for example:

  * Move the handling of those (and any other) common files or dirs
(like /etc/cron.allow, /etc/cron.deny, crontab.5, /etc/crontab,
the /etc/cron.* dirs and placeholders, and possibly also the cron
spool) to a third package (say cron-common/cron-support/cron-base/etc)
that both packages depend on.
  * Or change cron (and systemd-cron) to take into account each others
presence to not purge those files in that case (although this one
is not future-proof).

Appropriate Breaks would need to be added to both packages on the fixed
versions.

Thanks,
Guillem


-- 
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/20141213233611.ga32...@gaara.hadrons.org

Re: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2

[Guillem Jover]

Hi!

On Tue, 2014-12-09 at 14:56:56 +0100, Ondřej Surý wrote:
 On Tue, Dec 9, 2014, at 12:24, Gerrit Pape wrote:
  On Mon, Nov 24, 2014 at 10:08:49PM +, Simon McVittie wrote:
   On 24/11/14 21:41, Gerrit Pape wrote:
Better than (2) would be to make the existence of /etc/inittab still
essential for jessie, by moving the corresponding code from
sysvinit-core into the essential init package.  What do you think?
   
   If you go this route, I think initscripts might be a better home for
  
  As I wrote above, I actually don't have the time to go any road at all.
  
  The packages worked just fine until I learnt that support for the
  inittab interface is dropped in jessie.  I fixed the packages.  Now I
  learnt that the existence of /etc/inittab is no longer essential, next
  thing breaking my packages - when switching jessie to sysvinit.
 
 I haven't noticed if this was mentioned before, but dpkg-trigger on
 /etc/inittab doesn't work?
 
 e.g.
 
 interest /etc/inittab

It should not, because the file is not managed by dpkg, and no one
AFAIK is explicitly activating that file trigger. (And remember,
always consider if using the -noawait trigger variants is more
appropriate, as that makes the upgrade path way easier, and avoids
possible trigger cycles.)

Thanks,
Guillem


-- 
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/20141209142736.ga28...@gaara.hadrons.org