Debian Bug report logs - #794587
binaries, man page, udev rules and conffiles are part of both libvbp0 and libvbp1

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: man page is part of both libvbp0 and libvbp1

Date: Tue, 04 Aug 2015 19:44:23 +0200

Package: libvbp1
Version: 4.2.59-1
Severity: serious
Tags: sid stretch

the man page is part of both libvbp0 and libvbp1.

Errors were encountered while processing:
 /var/cache/apt/archives/libvpb1_4.2.59-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Message #16 received at 794587@bugs.debian.org (full text, mbox, reply):

From: Ralf Treinen <treinen@free.fr>

To: 794587@bugs.debian.org

Subject: Re: man page is part of both libvbp0 and libvbp1

Date: Wed, 5 Aug 2015 14:14:18 +0200

In fact, there are more files that exist in both packages. According to
the Contents file :

  /etc/modprobe.d/blunt-axe.conf
  /lib/udev/rules.d/60-vtcore.rules
  /usr/bin/vtdeviceinfo
  /usr/bin/vtdriverinfo
  /usr/sbin/VpbConfigurator
  /usr/sbin/vpbconf
  /usr/sbin/vpbscan
  /usr/share/man/man1/vpbconf.1.gz
  /usr/share/man/man1/vpbscan.1.gz
  /usr/share/man/man1/vtdeviceinfo.1.gz
  /usr/share/man/man1/vtdriverinfo.1.gz
  /usr/share/man/man8/VpbConfigurator.8.gz

-Ralf.

Message #21 received at 794587@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Matthias Klose <doko@debian.org>, 794587@bugs.debian.org

Subject: Re: Bug#794587: man page is part of both libvbp0 and libvbp1

Date: Wed, 5 Aug 2015 14:14:24 +0200

[Message part 1 (text/plain, inline)]

Hello,

Matthias Klose [2015-08-04 19:44 +0200]:
> Package: libvbp1
> Version: 4.2.59-1
> Severity: serious
> Tags: sid stretch
> 
> the man page is part of both libvbp0 and libvbp1.

It's not just that, it's much worse -- the library contains udev
rules, binaries, /etc/modprobe.d/blunt-axe.conf. None of this belongs
into a library, but into some vpb-something binary, presumably
vpb-utils? (Also: Please don't make the lib depend on that).

While you are at fixing this, would you mind dropping the
/etc/modprobe.d/blunt-axe.conf conffile and adding an
/usr/lib/modules-load.d/ snippet instead?

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[signature.asc (application/pgp-signature, inline)]

Message #28 received at 794587@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Martin Pitt <mpitt@debian.org>, 794587@bugs.debian.org

Cc: Matthias Klose <doko@debian.org>

Subject: Re: Bug#794587: man page is part of both libvbp0 and libvbp1

Date: Wed, 5 Aug 2015 23:19:53 +0930

On Wed, Aug 05, 2015 at 02:14:24PM +0200, Martin Pitt wrote:
> Hello,
> 
> Matthias Klose [2015-08-04 19:44 +0200]:
> > Package: libvbp1
> > Version: 4.2.59-1
> > Severity: serious
> > Tags: sid stretch
> > 
> > the man page is part of both libvbp0 and libvbp1.

sigh, I knew something was going to bite me if I raced this out, but I
had a small window between other urgent things, and figured I'd get it
out of the gcc-5 blocker list.  oh well.

> It's not just that, it's much worse -- the library contains udev
> rules, binaries, /etc/modprobe.d/blunt-axe.conf. None of this belongs
> into a library, but into some vpb-something binary, presumably
> vpb-utils? (Also: Please don't make the lib depend on that).

Yeah, the API was solidly stable before this got uploaded to Debian,
so having a separate -common or whatever package seemed like overkill
since we were never planning to bump SONAME and need a transition
that had them co-installable.

vpb-utils isn't really the right place for it all (or it would already
be in there), some of it is necessary for setting up the environment
for the library to operate (so the lib package will need to depend on
it), and some of it, like the udev rules, more properly belongs with
the kernel module package, but that one *is* co-installable for
different kernel versions which is why this became the common package
for that.

The stuff in vpb-utils are 'application level' utilities and test
programs, so they really are optional to have installed.


Arguably, I could just make this package conflict with libvpb0 ...
it's not like any real user is actually going to need them coinstalled,
either you'll update it, or you won't.  There's a kind of natural limit
to how many things can be controlling your phone lines at the same time.

I know it's not "by the book" for a lib package (I knew that when I did
it) - but I weighed that up against bloating the archive with a separate
package for ~1kB of support files and the reality of being committed to
never breaking the existing ABI.


> While you are at fixing this, would you mind dropping the
> /etc/modprobe.d/blunt-axe.conf conffile and adding an
> /usr/lib/modules-load.d/ snippet instead?

hmm, I didn't even know that directory existed.  When was it first added
and how widely is it supported?  (I'd like to keep this all as easily
portable as possible, since there are users on lots of different distro
releases still).

Debian actually dropped the netjet module from its kernel builds quite
a long time ago due to its retardedness, so largely this is for people
who build it on ubuntu and other distros that haven't - but I also keep
it as insurance in case one day someone goes "hey let's add this back".

I know moving things out of /etc is something of a current craze, but
is it doing any real harm there?  Aside from possibly having to move
a conffile to another package if I don't just add the Conflicts, it
does reasonably fit with my idea of why conffiles are actually Good
if the local admin does want to override it for some reason.


Does anyone have a good practical argument for why I shouldn't just
make this conflict with libvpb0?  (I know all the reasons why this
is *normally* not a good idea for library packages, so no need to
repeat those - but in this specific case, for this specific package,
it might still be the Lesser Evil here).

  Cheers,
  Ron

Message #33 received at 794587@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Ron <ron@debian.org>

Cc: 794587@bugs.debian.org, Matthias Klose <doko@debian.org>

Subject: Re: Bug#794587: man page is part of both libvbp0 and libvbp1

Date: Wed, 5 Aug 2015 16:20:43 +0200

Hey Ron,

Ron [2015-08-05 23:19 +0930]:
> sigh, I knew something was going to bite me if I raced this out

Welcome to the madness of C++ :-(

> Does anyone have a good practical argument for why I shouldn't just
> make this conflict with libvpb0?

Conflicts: and Replaces:, please. That's indeed a good enough quickfix
for the RC part of this bug, and what I did in Ubuntu as well.

Thanks for the heads-up!

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #38 received at 794587-close@bugs.debian.org (full text, mbox, reply):

From: Ron Lee <ron@debian.org>

To: 794587-close@bugs.debian.org

Subject: Bug#794587: fixed in vpb-driver 4.2.59-2

Date: Wed, 05 Aug 2015 16:49:36 +0000

Source: vpb-driver
Source-Version: 4.2.59-2

We believe that the bug you reported is fixed in the latest version of
vpb-driver, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 794587@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ron Lee <ron@debian.org> (supplier of updated vpb-driver package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 06 Aug 2015 00:20:48 +0930
Source: vpb-driver
Binary: vpb-driver-source vpb-utils libvpb1 libvpb-dev libvpb-doc libvpb-dbg
Architecture: source amd64 all
Version: 4.2.59-2
Distribution: unstable
Urgency: medium
Maintainer: Ron Lee <ron@debian.org>
Changed-By: Ron Lee <ron@debian.org>
Description:
 libvpb-dbg - debugging symbols for libvpb and vpb-utils
 libvpb-dev - Voicetronix telephony hardware userspace library development file
 libvpb-doc - Voicetronix telephony interface library documentation
 libvpb1    - Voicetronix telephony hardware userspace interface library
 vpb-driver-source - Voicetronix telephony hardware driver source
 vpb-utils  - Voicetronix telephony hardware userspace tools
Closes: 794587
Changes:
 vpb-driver (4.2.59-2) unstable; urgency=medium
 .
   * Conflict/Replace libvpb0.  Closes: #794587
   * This is really just a kludge-around for the fact that we have unversioned
     files installed in the runtime library package, which ordinarily would be
     a Terribly Wrong thing to do, but this code is stable and had a strong
     guarantee that the ABI was never going to be broken and it would never
     need a transition, so for several reasons that was the least worst option
     for nearly 10 years now.  Until gcc-5 broke that promise on us ...
     In this case, we can probably still quite reasonably get away with just
     forcing the old package off the system when it is upgraded, since there is
     a fairly natural limit to how many applications you can have controlling
     your phone lines on a system, and no real user is likely to actually need
     the old and new packages to be co-installable.  Either they'll update to
     the new one, or they won't.  There's no prolonged transition where things
     they might need could still be using the old one.  It's still technically
     wrong though, so kids don't try this at home, but unless gcc starts to
     make a habit of this, it's probably the least disruptive change we can
     impose on users to cope with that transition, and hopefully something we
     won't need to deal with again for at least another ten years.  If we do,
     then we'll reassess where the pros and cons really lay for making more
     intrusive changes to support things that "should have never happened".
Checksums-Sha1:
 cf5fc99d4197cbef2df18ae3ed5cf9d400c20667 2010 vpb-driver_4.2.59-2.dsc
 dff97c3a41577cf417b28e9a7254bac6739fb23a 17199 vpb-driver_4.2.59-2.diff.gz
 4c9b92c8371833b9ea9a2bde24163128432975d6 855482 libvpb-dbg_4.2.59-2_amd64.deb
 7bab1af27668dcb175e91aefd8e723c2c71a74fd 187378 libvpb-dev_4.2.59-2_amd64.deb
 ea072e901607d7f2d84aaa7293b67c735170baf1 5100288 libvpb-doc_4.2.59-2_all.deb
 85689a41c93995626db356d37d98102003c8d2bb 155510 libvpb1_4.2.59-2_amd64.deb
 25b8776a801c81945724a9b280fc31cfa8c73c92 85392 vpb-driver-source_4.2.59-2_all.deb
 e0f54e8a5fdf60d81ec1cfe8bf097b6cf1dc2bd1 52942 vpb-utils_4.2.59-2_amd64.deb
Checksums-Sha256:
 01d5111d9c4d47f97f5f58699be44f487c15a8d001c346ba641a2587259913f9 2010 vpb-driver_4.2.59-2.dsc
 897e122319d953e3e275121654a2ec0c397d37cfb93528c70b1d3b11f12ef754 17199 vpb-driver_4.2.59-2.diff.gz
 7cfb37e6815210c56e0ed0fb0274c1837eea9b2a23feb6123ee646bd3dab9191 855482 libvpb-dbg_4.2.59-2_amd64.deb
 5a23100787527224c3c04de2cc7301b8d6a9a5438024e003a77c203448837563 187378 libvpb-dev_4.2.59-2_amd64.deb
 ca36fb1f4e5076b7a2a6673d5b336e3b2e38a3f66255dfb30f674ac47f627552 5100288 libvpb-doc_4.2.59-2_all.deb
 70aac0f4453943e3a4097a1efd7a69c8f556185b48533cd11c33a201de8d9407 155510 libvpb1_4.2.59-2_amd64.deb
 a85a1fde2e7396160b89eb2550bf2e957fd01a12951d834244bae43d150b4f56 85392 vpb-driver-source_4.2.59-2_all.deb
 036a3edef995e00492fe304e83076d0deca1f9ac141a194b291870c81f353cb7 52942 vpb-utils_4.2.59-2_amd64.deb
Files:
 65056a423766a7b3c1dc71e947d26629 2010 comm optional vpb-driver_4.2.59-2.dsc
 34f893dfb76ba6cc988811d504911a4c 17199 comm optional vpb-driver_4.2.59-2.diff.gz
 54e6d9010ac22be354e9ccfdc88e3441 855482 debug extra libvpb-dbg_4.2.59-2_amd64.deb
 e3a10d4372dc62083b8e951901acd468 187378 libdevel optional libvpb-dev_4.2.59-2_amd64.deb
 2780dacab2bcb575dea3328c426c01fe 5100288 doc optional libvpb-doc_4.2.59-2_all.deb
 73b8ef9405c2884b0a3082b24cd67bc3 155510 libs optional libvpb1_4.2.59-2_amd64.deb
 e5224ad2f7526849ed511c4a32fae81c 85392 kernel optional vpb-driver-source_4.2.59-2_all.deb
 c45682ae305d5c73315817c210f47e67 52942 comm optional vpb-utils_4.2.59-2_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVwjnyAAoJECSWn9pgwHEsfIEP/1dmOH6rj7Vr/CuXExXQJr72
a1nHmp2aqbZ/fWMzfNRbvubzIOgTi2zUR1cTz/cMyA04JIMgiKwRLHciTMVdHZzo
v/q0/1ZuewNq1MlPeSRxOkJIj5u0KnmFH/FQAuuz8NY0igr+2vMUtP7kC+LEFA0i
gnkXC0ut0BKg81TgBxB5pFODznMfMmirafDysA/VpF1TINEbIlH6iEKI50XRoAbN
NcQ+b0FomH+zOsUUgcY215BLOflv3jhux56PXu8nbS2/gkQ5pPtDhy3uTivHdwSq
YL+QLZo8ILoWVoZNvjeiVWQDE05WC2t+uzSQ7gxvfx0YDAzHbvzxr3QKn1BJtNXU
Pxsgcywq0ORVN8St7dvomhkxDqQlatM2//HEZdWNutXjn2C/fz3JyhG8ZZc5G8N6
jcMLIMCIcImNBSvQHkgmw6lfjpJUB9KL2WanKXzmGSfGI9JXKSxdOCG40kEvBJV8
A6OIAVAx5HPzwolK/WjT43WOvpMpIcMUy2WkRdhH3iisHyPfF9v5dW4wD2AVBlud
b59GaQALDoN4Ou9ZEyXeyv89n3uXRu5JOOffjlK5i1x9OF0wc8ECEBx6cac5N9ww
RhRHPnhfLps6PQrJoj15AyGDgupqxn/qbv4p2iVCVdUEUjbmiPCP0n+zklIjDVhj
L7vF0+WYGnBjOubGEk2v
=2sdv
-----END PGP SIGNATURE-----

Message #41 received at 794587@bugs.debian.org (full text, mbox, reply):

From: Andrei POPESCU <andreimpopescu@gmail.com>

To: Matthias Klose <doko@debian.org>, 794587@bugs.debian.org

Cc: libvpb1@packages.debian.org

Subject: Re: Bug#794587: man page is part of both libvbp0 and libvbp1

Date: Sat, 15 Aug 2015 18:19:38 +0300

[Message part 1 (text/plain, inline)]

Control: reassign -1 libvpb1 4.2.59-1

On Ma, 04 aug 15, 19:44:23, Matthias Klose wrote:
> Package: libvbp1
> Version: 4.2.59-1
> Severity: serious
> Tags: sid stretch
> 
> the man page is part of both libvbp0 and libvbp1.
> 
> Errors were encountered while processing:
>  /var/cache/apt/archives/libvpb1_4.2.59-1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.