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

[Russ Allbery]

Hendrik Sattler  writes:
> Am 18. Juni 2015 03:54:56 MESZ, schrieb Russ Allbery :

>> Shared library symbol versioning makes the problem go away.  Package
>> dependencies try to solve the problem at the wrong level.

> The problem is rather that the package dependency system doesn't look at
> specific package dependency trees to find conflict between liblow1 and
> liblow2. Instead it always does this globally. That problem is solvable.

You missed the part of my message (which you snipped) where I specifically
dealt with this.  You cannot make liblow1 and liblow2 conflict without
causing tons of other problems, such as preventing partial upgrades and
making upgrade solutions infeasible.

We want to support coinstallation of different SONAMEs of shared libraries
and partial upgrades.  These are major, important features for both our
users and for our release and library transition process.

> But you just but the burden on upstreams again. 

We can add symbol versioning in the Debian packaging even if it's not done
upstream.  We do that already for some libraries.  It's obviously better
to do it upstream, though, so that different distributions use the same
versioning.

It sounds like you're upset about my conclusion for some reason.  You're
certainly entitled to be upset, but your upsetness is not persuasive to
anyone other than you.  If you want to effectively argue with conclusion,
you're going to have to address my rather extended explanation for why
this is the best solution.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fv5py680@hope.eyrie.org

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

[Hendrik Sattler]

Am 18. Juni 2015 03:54:56 MESZ, schrieb Russ Allbery :
>Vincent Lefevre 
>Shared library symbol versioning makes the problem go away.  Package
>dependencies try to solve the problem at the wrong level.

The problem is rather that the package dependency system doesn't look at 
specific package dependency trees to find conflict between liblow1 and liblow2. 
Instead it always does this globally. That problem is solvable.

But you just but the burden on upstreams again. 

HS



-- 
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/25719340-bf04-4aa0-a69f-38c4c19d5...@hendrik-sattler.de

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

[Clint Adams]

On Wed, Jun 17, 2015 at 12:58:55AM +0200, Guillem Jover wrote:
> 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.

No, in this particular case, upstream IS releasing source tarballs and
the packagers are refusing to use them for reasons I find
incomprehensible.


-- 
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/20150618023157.ga5...@scru.org

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

[Russ Allbery]

Vincent Lefevre  writes:
> On 2015-06-16 09:12:36 -0700, Russ Allbery wrote:

>> There are a lot of really complex things you can do with versioning and
>> cases where that version number is meaningful, but for the vast
>> majority of libraries, I recommend not worrying about it and just
>> always using some simple transform of the SONAME as the version for all
>> symbols in the library.  When you bump the SONAME, bump all the symbol
>> versions.  When you introduce a new symbol, use the SONAME as the
>> symbol version.

>> This is not strictly correct in that the symbol version doesn't
>> correspond to a specific API (you're adding new symbols with the same
>> symbol version as old symbols), but most of the functionality you lose
>> is just meaningful error messages when running new binaries against
>> too-old versions of the shared library.  And it's way simpler to
>> implement.

> But can this be detected so that a versioned dependency of the shared
> library can *automatically* be added when the binary packages are
> generated, avoiding this problem?

I'm not sure what "this" you're referring to.

If you mean detecting that you have newer binaries that require a new
version of the shared library, and thus the shared library needs to be
upgraded, yes, absolutely.  Debian solved this problem years and years
ago.  That's what you're fixing by bumping the version in dh_makeshlibs in
the shared library package: signaling that binary packages should have a
tigher versioned dependency.  debian/symbols does this in an even more
sophisticated way.

Just in case, by "this", you meant the whole problem of shared library
upgrades where you *don't* have symbol versions, here's the long-winded
explanation for why you need symbol versions and package dependencies
don't cut it:

It is nearly impossible to solve this problem with package dependencies.
Shared library symbol versioning is required to solve the problem
properly and without painstaking and very fragile manual work.

This is because the problem is not with direct dependencies on a shared
library, but rather with indirect dependencies.  What happens is that you
have some library -- call it liblow1 -- and you have two other libraries
that use it -- call them libfoo1 and libbar1.  liblow1 does not have
symbol versioning.  An incompatible liblow2 is released.  The user
upgrades the system such that libfoo1 is rebuilt against liblow2, but
libbar1 is not.

Now, some application, app, which is linked against both libfoo1 and
libbar1, is started.  What happens is that calls to the functions in
liblow1 and liblow2 go to one of the two implementations semi-randomly,
and one of either libfoo1 or libbar1 is going to break horribly, usually
in some very subtle and awful way.

There are a bunch of ELF tricks that you can try to do to minimize this,
but none of them are 100% effective.  However, symbol versioning is 100%
effective, since then libfoo1 and libbar1 are linked against specific
versioned symbols, there are no symbol conflicts between liblow1 and
liblow2, and both get loaded into memory, both are used appropriately, and
app works.

To try to solve this with dependencies, you have to make liblow2 conflict
with liblow1.  But this completely breaks shared library upgrades, since
now you have to upgrade every program linked to liblow in lockstep, even
if there's no risk for that application of loading two versions at the
same time, because you can't have both shared libraries on the system at
the same time.  It also wipes out our dependency resolver, because there
are too many conflicts to find a good solution.

Alternately, you can do what we're trying to do here, which is add a
complex mess of Breaks and Conflicts to all the various consumers of
liblow1 and hope that you caught them all.  Spoiler: you never catch them
all.  Particularly since some of them are user programs that aren't even
part of the distribution.

Shared library symbol versioning makes the problem go away.  Package
dependencies try to solve the problem at the wrong level.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbelye4v@hope.eyrie.org

Lintian auto-reject changes

[Joerg Jaspert]

Hi,

we got one more lintian auto-reject active on ftp-master, in dak.git 
commit e0364a10b4a8ab37dd6527bbd1ba67a2f43da9cc

Everything hitting "empty-binary-package" is a *nonfatal* reject now.

Thanks to Jakub Wilk. Eventual tarring and feathering too please, but
for common amusement do it where the DebConf Video Team can record it. :)

-- 
bye, Joerg
 Deine Größe macht mich klein 
<@joerg> doll
 du darfst mein Bestrafer sein 
(!) Wrecktum was kicked from #german by joerg [ok]


signature.asc
Description: PGP signature

Re: Xen PVUSB - Debian 8

[Tomas Pospisek]

Am 16.06.2015 um 11:19 schrieb pietrop:
> Hi all,
> 
> I am trying to setup a Debian 8 machine running XEN, which I've
> installed from the package manager, to use the USB passthrough.
> 
> It looks like I need to use the module xen-usbfront and xen-usbback,
> which I can't find in the /lib/modules/(my kern)/*
> 
> 
> Are there ways to get around this ?

This is possibly not the right list to ask this question. You could try on:

https://www.debian.org/support
https://lists.debian.org/debian-user/
http://forums.debian.net/
http://ask.debian.net/
irc://irc.oftc.net/debian

But probably it's better to go to an even more specialized list f.ex.
for sysadmins or for Xen itself.
*t


-- 
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/5581d694.3060...@sourcepole.ch

Re: preparing for GCC 5, especially libstdc++6

[Lisandro Damián Nicanor Pérez Meyer]

On Tuesday 16 June 2015 23:37:41 Matthias Klose wrote:
> Hi,
> 
> it's time to prepare for GCC 5 as the default compiler in unstable. 
> Compared to earlier version bumps, the switch to GCC 5 is a bit more
> complicated because libstdc++6 sees a few ABI incompatibilities, partially
> depending on the C++ standard version used for the builds.  libstdc++6 will
> support two ABI's, the classic cxx98 ABI (currently in testing/unstable)
> and the new cxx11 ABI (currently enabled in experimental as the default
> ABI).

Hi Matthias!

[snip]

> My goal is to make the GCC version bump in early July, and use the time
> until then to prepare libstdc++6 depending packages to get ready for GCC 5,
> and avoiding version bumps for C++ libraries until this time.

As you already know we the Qt/KDE team, in order to avoid an ABI break, need 
to either:

a) Push Qt 5.4.2 to unstable before gcc5 becomes the default compiler. This is 
currently not an option due to #787689.

b) Push Qt 5.4.2 to unstable at the same time as gcc5 becomes the default 
(well, one or two dinstalls later maybe). If some package gets compiled with 
gcc5 and Qt < 5.4.2 in the meantime we can binNMU it.

c) Push Qt 5.4.2 to unstable a couple of days before gcc5 becomes the default. 
Once gcc5 becomes the default ask for a give back in armhf.

d) Push Qt 5.4.2 to unstable either by forcing gcc5 as default at build time 
or working around the bug. I would definitely would like to avoid this option 
as:
  - The current Qt stack is comprised of 25 source packages. I don't think me
or my teammates will have the time to hack all of them before beginnings
of July.
  - I don't know if some other lib/app that build depends on qt5 will still
have the issue on armhf if we workaround it.
  - I don't know what happens if Qt5 gets built against gcc5 but apps against
gcc4.9. Possibly and hopefully nothing, but I just don't know.

My current preference would be acb (totally discarding d), but I'm open to 
suggestions too.

Kinds regards, Lisandro.

-- 
El futuro es WIN95 A no ser que hagamos algo a tiempo.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug #789081: ITP: coyote -- GDL library from D.Fannings IDL courses

[Ole Streicher]

Package: wnpp
Owner: Ole Streicher 
Severity: wishlist
X-Debbugs-Cc:
debian-devel@lists.debian.org,debian-as...@lists.debian.org,debian-scie...@lists.debian.org

* Package name: coyote
  Version :
  Upstream Author : David Fanning
* URL : http://www.idlcoyote.com
* License : BSD-3
  Programming Lang: GDL (IDL)
  Description : GDL library from D.Fannings IDL courses
 The Coyote Library evolved from work David Fanning was doing teaching
 IDL courses and answering IDL questions on the IDL newsgroup. It is
 meant to be a well-documented library that demonstrates how to write
 solid (dare we say eloquent) GDL/IDL programs that are easy to
 maintain and extend.

The software is written for the commercial language "IDL", but works in
large parts with GDL as well. Since I don't have much experience with
GDL/IDL, any input, help, co-maintenance or even taking over the
packaging is appreciated.

The main motivation to create this package is to extend the idlastro
package.

The software will be maintained within te Debian Astronomy Team.
A git repository is created on alioth at

https://anonscm.debian.org/cgit/debian-astro/packages/coyote.git

The package will *require* gnudatalanguage. Feel free to start a
discussion if this is a good idea and or if and how the commercial
package (IDL) should be supported.

Best regards

Ole

P.S. x-debbugscc went wrong; therefore I manually re-sent this with the
bug #.


-- 
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/55819a75.3080...@debian.org

Bug#789061: ITP: scala-parser-combinators -- Scala Standard Parser Combinator Library

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: scala-parser-combinators
  Version : 1.0.3
  Upstream Author : Typesafe, Inc.
* URL : https://github.com/scala/scala-parser-combinators
* License : BSD-3-clause
  Programming Lang: Scala
  Description : Scala Standard Parser Combinator Library

The Scala parser combinator library was part of Scala up to the version 2.10
and is now a separate library. It is required to package Scala 2.11.


-- 
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/20150617131724.10301.42072.report...@icare.ariane-software.com

Bug#789043: ITP: egctl -- control state of EnerGenie Programmable surge protector

[Hector Oron]

Package: wnpp
Severity: wishlist
Owner: Hector Oron 

* Package name: egctl
  Version : 1.0
  Upstream Author : Vitaly Sinilin 
* URL : https://github.com/unterwulf/egctl
* License : MIT/X
  Programming Lang: C
  Description : control state of EnerGenie Programmable surge protector

  program to control the state of EnerGenie Programmable surge protector with
  LAN interface. It uses native EG-PMS-LAN data exchange protocol version 2.0
  or 2.1, not HTTP.


-- 
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/20150617110055.11420.51729.report...@polynomio.collabora.co.uk

Bug#789041: ITP: lqa -- LAVA QA Tool

[Hector Oron]

Package: wnpp
Severity: wishlist
Owner: Hector Oron 

* Package name: lqa
  Version : 20150520.0
* URL : https://git.collabora.com/cgit/singularity/tools/lqa.git/
* License : LGPL2.1+
  Programming Lang: Python
  Description : LAVA QA Tool

  This package contains a command line tool for LAVA quality assurance tasks.


-- 
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/20150617105834.11369.8086.report...@polynomio.collabora.co.uk

Re: Invoking ‘init’ from an init.d script (Wheezy)

[David Kalnischkies]

On Tue, Jun 16, 2015 at 12:49:36PM +, Thorsten Glaser wrote:
> Ansgar Burchardt  debian.org> writes:
> 
> > Please be aware that --force-yes makes apt ignore invalid signatures for
> 
> Ouch.

Oh, how disingenuous these apt developers are!

I wonder, what got you: The friendly, very peaceful and gentle option
name --force-yes (who doesn't like to be forced to a yes?), the promise
of ponies and rainbows in the manpage ("destroy your system" … "harmful"
… "should not be used") or are you just running any arbitrary command
you run across on the internet without checking what they do first?

In either case: "Ouch"… I hope it really hurts… *indistinguishable curses*


There is a HUGE difference between being forced to use such an option
because you either don't know the alternative or there isn't one and
just using random options you don't understand and acting like it is
the fault of someone else then you are hurt by it…


> What is the equivalent of --force-yes with*out* --allow-unauthenticated,
> then? This scenario (scheduled non-interactive upgrades) is common…

If only documentation would exists… I think it would read like this:

-y, --yes, --assume-yes
 Automatic yes to prompts; assume "yes" as answer to all prompts and run
 non-interactively.  If an undesirable situation, such as changing a held
 package, trying to install a unauthenticated package or removing an essential
 package occurs then apt-get will abort.
 Configuration Item: APT::Get::Assume-Yes.


You already know --allow-unauthenticated, there is also --ignore-hold.
The other two (downgrade and essential removal) currently lumped together
in --force-yes do not have a dedicated option ATM.

If anyone wants to writing a patch for this feel free to – and achieve
everlasting glory by fixing an apt bug (lots of opportunity, very few
takers)!


Best regards

David Kalnischkies


signature.asc
Description: Digital signature