Re: Depends/Recommends from libraries

[Russ Allbery]

Marvin Renich  writes:

> If libbar-dev documents that it requires bar-daemon (and under what
> circumstances, if appropriate), but libbar does not declare the Depends,
> then it becomes the Debian maintainer of foo who decides to add an
> appropriate Depends, Recommends, or Suggests for bar-daemon, in addition
> to the Depends (that should be, but can't be, a Recommends or Suggests)
> on libbar.

And if you think the maintainer of foo is going to remember to do that,
well damn, why do we even bother with dpkg-shlibdeps?  Our maintainers can
just hand-craft this stuff -- it's so easy!

Humans don't work this way.

> Every Debian maintainer whose package links libbar would then be
> required to read the documentation of libbar-dev, and act on that to add
> a dependency that libbar would have used.  I would certainly expect a
> Debian maintainer to read said documentation (irregardless of Ian's
> proposal).

I would absolutely not expect that.

Let's please not create more situations where packaging requires careful
memory, multiple checklists, and human judgement.  It is absolutely not
okay to require maintainers read all of the documentation of all dev
packages they depend on in order to hand-craft dependencies.  This is not
how we make a better distribution or make Debian packaging easier or more
likely to be correct; this is how we end up with a bunch of frustrating
bugs.

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

Re: Release file for own backport repository?

[Joerg Desch]

Am Fri, 10 Mar 2017 11:04:40 +0800 schrieb Paul Wise:

> Did you also update your sources.list?

No, because I use the directory name for it. Or isn't an entry with an 
trailing slash an directory?

deb http://debian.jdesch.de/repositories/experimental/ jessie/

Symbol specific dependencies (was Re: Depends/Recommends from libraries)

[Guillem Jover]

Hi!

On Thu, 2017-03-09 at 17:29:09 +, Ian Jackson wrote:
> I think the right way to solve this problem is to declare that:
[…]
>  * If a library needs or wants additional software installed,
>if and when functions in that library are called, this
>should be documented in the /usr/share/doc/BAR/README.Debian.gz for
>the corresponding -dev library package.  (If churn is
>likely, a library-specific virtual package name may need
>to be documented, and provided as appropriate.)

>  * Programs which call functions in libraries (directly or indirectly)
>should arrange to Depend on, Recommend, or Suggest, the appropriate
>infrastructure, as documented by the -dev package(s).

We can already represent symbol specific dependencies, so we can have
a library that ships this following made-up symbols file:

,---
libservice.so.0 libservice0 #MINVER#
| serviced
 start_service_daemon 0 1
 generic_serviceless_action 0
`---

Of course one problem is that libraries might not be delimited in this
way, and they might just start such services when merely initializing
the library, when calling any of its functions, or at any point inside
some state machine or whatever. Also a program might call such function
but that might be conditional on a configuration parameter or something
else, so the fact that a program uses that symbol does not mean it might
even call it.

Thanks,
Guillem

Re: Release file for own backport repository?

[Paul Wise]

On Thu, Mar 9, 2017 at 7:36 PM, Joerg Desch wrote:

> After this, "apt-get update" prints the error (jessie expected but jessie-
> backports received):

Did you also update your sources.list?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#857320: ITP: kubernetes-addon-heapster -- Resource usage analysis and monitoring addon for Kubernetes

[Potter, Tim]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: kubernetes-addon-heapster
  Version : 1.2.0
  Upstream Author : Vish Kannan, Marcin Wielgus, Piotr Szczesniak
* URL : https://github.com/kubernetes/heapster
* License : Apache-2.0
  Programming Lang: Go
  Description : Resource usage analysis and monitoring addon for Kubernetes

 The Kubernetes Heapster addon is an addon for computing resource
 usage analysis and monitoring of container clusters.  Heapster
 collects and interprest various signals like comput resource usage,
 lifecycle events, etc, and exports cluster metrics via REST
 endpoints.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#857319: ITP: golang-gopkg-olivere-elastic.v3 -- Elasticsearch client for Golang

[Potter, Tim]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-gopkg-olivere-elastic.v3
  Version : 3.0.41-1
  Upstream Author : Oliver Eilhard
* URL : https://github.com/olivere/elastic
* License : Expat
  Programming Lang: Go
  Description : Elasticsearch client for Golang

Provides an interface to the Elasticsearch server
(http://www.elasticsearch.org/). It can manage full text indices,
index documents, and search them.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#857318: ITP: golang-github-optiopay-kafka -- Go client library for Apache Kafka

[Potter, Tim]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-optiopay-kafka
  Version : 0.0~git20150921.0.bc8e095-1
  Upstream Author : Piotr Husiatyński
* URL : https://github.com/optiopay/kafka
* License : Expat
  Programming Lang: Go
  Description : Go client library for Apache Kafka

This library provides a high-level client API for Apacha Kafaka. It
implements connection management as well as producer and consumer
objects for sending and receiving messages, respectively.
.
Apache Kafka is an open-source stream processing software providing a
unified, high-throughput, low-latency platform for handling real-time
data feeds.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Work-needing packages report for Mar 10, 2017

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1055 (new: 5)
Total number of packages offered up for adoption: 167 (new: 0)
Total number of packages requested help for: 44 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   linux-igd (#857247), orphaned today
 Description: Linux UPnP Internet Gateway Device
 Installations reported by Popcon: 159
 Bug Report URL: http://bugs.debian.org/857247

   npapi-sdk (#856737), orphaned 5 days ago
 Description: NPAPI headers bundle for building plugins
 Installations reported by Popcon: 106
 Bug Report URL: http://bugs.debian.org/856737

   nullmailer (#857248), orphaned today
 Description: simple relay-only mail transport agent
 Installations reported by Popcon: 1564
 Bug Report URL: http://bugs.debian.org/857248

   obexpushd (#856738), orphaned 5 days ago
 Description: program for receiving files via Bluetooth or IRDA
 Installations reported by Popcon: 442
 Bug Report URL: http://bugs.debian.org/856738

   pidgin-skype (#856736), orphaned 5 days ago
 Description: Skype plugin for libpurple messengers (common files)
 Reverse Depends: empathy-skype pidgin-skype pidgin-skype-dbg
 Installations reported by Popcon: 1749
 Bug Report URL: http://bugs.debian.org/856736

1050 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 167 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   athcool (#278442), requested 4517 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 19
 Bug Report URL: http://bugs.debian.org/278442

   autopkgtest (#846328), requested 99 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 754
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 1992 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 684
 Bug Report URL: http://bugs.debian.org/642906

   busybox (#854181), requested 33 days ago
 Description: Tiny utilities for small and embedded systems
 Reverse Depends: bootcd busybox-syslogd dropbear-initramfs
   live-boot-initramfs-tools open-infrastructure-system-boot udhcpc
   udhcpd wicd-daemon zfs-initramfs
 Installations reported by Popcon: 195175
 Bug Report URL: http://bugs.debian.org/854181

   cups (#532097), requested 2833 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (66 more omitted)
 Installations reported by Popcon: 178272
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 533 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (127 more omitted)
 Installations reported by Popcon: 196406
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 237 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 64623
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 922 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 19820
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 527 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (25 more
   omitted)
 Installations reported by Popcon: 12985
 Bug Report URL: http://bugs.debian.org/800413

   ejabberd (#767874), requested 857 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
   

Re: AppStream Re: Depends/Recommends from libraries

[Jeremy Bicha]

On Thu, Mar 9, 2017 at 6:23 PM, Rebecca N. Palmer
 wrote:
> When beignet-opencl-icd added AppStream metadata (black line in [1]), there
> was no noticeable increase in its installs.  As it's for popular hardware

I think a lot of those appstream installs are from KDE and GNOME which
install plasma-discover and gnome-software by default.

But beignet-opencli-icd's appstream metadata is invalid.

https://appstream.debian.org/sid/main/issues/beignet-opencl-icd.html

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license

When you fix this issue, it may take a day or so for Debian's
appstream generator to pick up the change and publish it. If there are
no issues, the issues page won't be live but
https://appstream.debian.org/sid/main/metainfo/beignet-opencl-icd.html will be.

Also, do you have a link for more information about what
beignet-opencl-icd does?

Thanks,
Jeremy

AppStream Re: Depends/Recommends from libraries

[Rebecca N. Palmer]

appstream itself is installed on ~60% of sid/stretch desktops [0], but 
isenkram on only ~5% (and most of those are the -cli version).


When beignet-opencl-icd added AppStream metadata (black line in [1]), 
there was no noticeable increase in its installs.  As it's for popular 
hardware (~33% of systems [2]) but a sufficiently behind-the-scenes 
feature that few users manually install it, this is a fairly sensitive 
test: <10% of new (including newly upgraded) sid/stretch desktop 
installations with the hardware installed it.


Hence, either most users don't see AppStream suggestions, or most users 
don't want GPU compute when offered the option.  (beignet-opencl-icd's 
AppStream summary/description are "OpenCL (GPU compute) driver for Intel 
GPUs"/"This allows using Intel integrated GPUs for general computation, 
speeding up some applications."  At least libreoffice-calc and probably 
ffmpeg can take advantage of it, but it's very possible that typical use 
of these is either on too little data to notice the difference, or has a 
better option (libva/libvdpau).)


[0] 
https://qa.debian.org/popcon-graph.php?packages=libvpx4+libllvm3.9+appstream+libappstream4+beignet-opencl-icd&show_installed=on&want_legend=on&want_ticks=on&from_date=2016-01-01&to_date=&hlght_date=2017-01-18&date_fmt=%25Y-%25m&beenhere=1
libvpx4 (video decoding, dependency of firefox and chromium) and 
libllvm3.9 (compiler library, dependency of libgl1-mesa-dri) were chosen 
as approximations of "all stretch/sid desktops", as they have changed 
soname since jessie.


[1] 
https://qa.debian.org/popcon-graph.php?packages=beignet-opencl-icd+mesa-opencl-icd+pocl-opencl-icd&show_installed=on&want_legend=on&want_ticks=on&from_date=2016-01-01&to_date=&hlght_date=2017-01-18&date_fmt=%25Y-%25m&beenhere=1


[2] from recent bug reports:
http://www.mail-archive.com/search?a=1&l=debian-bugs-dist%40lists.debian.org&haswords=VGA+compatible+controller+[0300]&x=16&y=26&from=&subject=&datewithin=1y&date=2017-01-01¬words=&o=newest

Re: Depends/Recommends from libraries

[Nick Phillips]

On Thu, 2017-03-09 at 10:19 -0800, Russ Allbery wrote:
> 
> I think this would be a great way of introducing spurious bugs in our
> distribution from people who don't happen to read the README file and
> miss
> dependencies they actually need because they're used to Debian
> properly
> picking up shared library dependencies and to the dependencies of any
> given package being fully self-contained.  Both of which, I should
> add,
> are major *features* of our distribution that many of us have worked
> very
> hard to achieve.  I'm opposed.
> 

Can we just clarify - in the setup that Ian proposed, a "normal" user
would have experience no different to now (except for less bloat);
package maintainers and those using -dev libs are the ones who would
need to read those docs. Package maintainers in order to ensure they
set the correct deps on their packages, and -dev package users to
ensure they are aware of which features of a library need extra
packages installed in order to function.


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

Re: Depends/Recommends from libraries

[Marvin Renich]

* Russ Allbery  [170309 13:19]:
> I think this would be a great way of introducing spurious bugs in our
> distribution from people who don't happen to read the README file and miss
> dependencies they actually need...

I think you are missing Ian's meaning.  Currently foo Depends libbar,
and libbar Depends bar-daemon.  If libbar were dynamically loaded, the
maintainer of foo would have used either a Recommends or Suggests for
libbar, but must instead use Depends because it is statically loaded.
If libbar-dev documents that it requires bar-daemon (and under what
circumstances, if appropriate), but libbar does not declare the Depends,
then it becomes the Debian maintainer of foo who decides to add an
appropriate Depends, Recommends, or Suggests for bar-daemon, in addition
to the Depends (that should be, but can't be, a Recommends or Suggests)
on libbar.  This is not pushed to the user at all, except in the normal
way that a user currently chooses to install Recommends or Suggests in
other circumstances.

Every Debian maintainer whose package links libbar would then be
required to read the documentation of libbar-dev, and act on that to add
a dependency that libbar would have used.  I would certainly expect a
Debian maintainer to read said documentation (irregardless of Ian's
proposal).  This has nothing to do with an end user reading a README
file to get the dependencies right (at least not any differently than
the current situation for other non-lib Recommends or Suggests).

I have not decided which side of the fence I am on, but I am certainly
empathetic to Ian's, Adam's, and others' desire to improve the
situation, as I have been bitten by this myself on more than one
occasion.  This is a situation where the maintainer of foo has no choice
but to use Depends, even if the library "can perhaps enhance [foo's]
usefulness, but installing [foo] without [libbar] is perfectly
reasonable."  You end up with a daemon that you don't want because
libbar Depends bar-daemon is appropriate, even if you, the end user, are
never going to use foo in a way that uses the libbar functionality.

If more upstreams were careful to use dynamic loading in these
situations, it would be less of a problem.  In a perfect world, the
solution would be for foo's maintainer to convince upstream to switch to
dynamic loading.  I'm not convinced that Ian's proposal is the right
approach, but I definitely agree that it is an attempt to solve a real
problem, and I believe it has more merit than you give it.

...Marvin

Re: Depends/Recommends from libraries

[Russ Allbery]

Adam Borowski  writes:

> What's wrong in the current state is that it looks only from the point
> of view of the library: libwrap1 is useless without tcpd, thus it's
> natural for it to have an elevanted severity.  But that dependency is
> wrong from a more global point of view.  That's why I'm proposing making
> the decision a responsibility of programs which link to the library.

I don't think these issues are as hard to reason about one by one as
you're saying.  This is a good example: libwrap0 is *not* useless without
tcpd.  All that tcpd is providing it are the default /etc/hosts.allow and
/etc/hosts.deny files (and maybe some binaries that are used in unusual --
these days -- situations like safe_finger).  You can use libwrap0 easily
without having tcpd installed if you write those files yourself.

Therefore, I think it would be reasonable to downgrade this Recommends to
Suggests.  (However, I seem to recall that we talked about this before and
there was some specific problem Marco was worried about that we haven't
captured in this discussion.)

That said, while I get that every little bit counts, installing tcpd on a
system has remarkably minimal impact.  It's just a few binaries in a tiny
package that doesn't start any processes and doesn't do anything.  It
takes all of roughly 92KB on disk.

The difficulty with the usbmuxd issue is precisely that it's just on the
borderline.  It only supports one specific (and not particularly common
for Debian, if common out in the world) type of hardware, but it's kind of
important on that piece of hardware.  There isn't a communication problem
here, there isn't a Policy problem here, there's a *hard tradeoff* problem
here, and talking about this as if it were an issue with missing Policy
loses the fact that this is a thoughtful choice the maintainers have made
with an understanding of all of the consequences.

I get that you disagree with their decision, but their decision isn't
obviously wrong.  We don't have a better way of supporting unusual
hardware than this.  It's worth noting that some steps have been taken to
minimize the impact of the additional dependency (it's small, it's only
started on demand, etc.), which I at least find entirely reasonable and
therefore feel fairly comfortable with still having it in the Recommends
set because otherwise people with Apple hardware have to do fairly obscure
things to get their hardware working.

I think everyone involved would be happy to switch to a better solution if
we had one (some package that detects packages needed for specific
hardware profiles and installs them, for instance).

It feels like you're unhappy with a decision that was made thoughtfully,
not accidentally, and want to use Policy as a way to override that
decision, which makes me quite uncomfortable.

And, with my Policy Editor hat on, I will say that this is not the purpose
of Policy; Policy is to document consensus about how we build the
distribution.  If you have a technical disagreement with maintainers about
their package metadata that involves thoughtful and principled
disagreement between two valid approaches with different tradeoffs (which
appears to be the case here), then for better or worse that's what the
Technical Committee is for.

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

Re: Depends/Recommends from libraries

[Russ Allbery]

Andrey Rahmatullin  writes:
> On Thu, Mar 09, 2017 at 12:22:17PM -0800, Russ Allbery wrote:

>> Sure, but hopefully we find and report those as bugs.  I personally run
>> without recommends on Debian unstable on several different types of
>> systems and report these problems whenever I run into them.

> But how do you decide if a specific problem caused by Recommends not
> installed is serious enough to be worth a bug report? "all but unusual
> installations" after all.

Mostly I use my judgement.

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

Re: Depends/Recommends from libraries

[Adam Borowski]

On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> > Quoting Russ Allbery (2017-03-09 04:24:09)
> 
> >> In general, I don't want to see us place too many restrictions on 
> >> Recommends.  If you don't want additional helpful programs, disable 
> >> installing Recommends by default.  I think it's very odd to worry 
> >> about bloat while simultaneously installing Recommends by default; 
> >> those aren't really consistent things to do.
> 
> > I strongly disagree: We _can_ improve on the default behaviour of our 
> > package handling - we need not give up and leave it to power users able 
> > to handle arguably broken systems.
> 
> Well, I strongly disagree with you.  I think this would take things in the
> wrong direction; I like that software is fully useful when Recommends are
> enabled at the cost of some bloat.

Yeah, but how the _library_ can make a meaningful decision about how
important the dependency is?  Only the program that links with the library
knows whether it's a fringe option or something important.

> If you don't want possibly unused software installed, we have a supported
> mechanism for that: disable automatic installation of Recommends.

The policy says:
#  `Recommends'
#  This declares a strong, but not absolute, dependency.
#
#  The `Recommends' field should list packages that would be found
#  together with this one in all but unusual installations.

Ie, if a substantial part of users don't want that package installed, then,
by the Policy's wording, that dependency is wrong.


What's wrong in the current state is that it looks only from the point of
view of the library: libwrap1 is useless without tcpd, thus it's natural for
it to have an elevanted severity.  But that dependency is wrong from a more
global point of view.  That's why I'm proposing making the decision a
responsibility of programs which link to the library.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Re: Depends/Recommends from libraries

[Michael Lustfield]

On Mar 9, 2017 12:22 PM, "Russ Allbery"  wrote:


Sure, but hopefully we find and report those as bugs.  I personally run
without recommends on Debian unstable on several different types of
systems and report these problems whenever I run into them.


I'm in this same boat. I disable installing recommends on all but one of my
systems, including my laptop's and other devices. If (when) I have issues
or check out new software, I take a look at those lists to see what I might
want.


Heh.. I remember using gnome, kde, xfce, etc. and they all seemed to have
this problem in one way or another. After enough battling, I eventually
arrived at the conclusion that these desktop environments were written to
be super complete, not super lean. They were for everybody, not for me.

I ended up switching to openbox and a whole different selection of
"desktop" utilities and even had to write some myself. Issues like this
have completely evaporated for me.

Re: Depends/Recommends from libraries

[Andrey Rahmatullin]

On Thu, Mar 09, 2017 at 12:22:17PM -0800, Russ Allbery wrote:
> >> If you don't want possibly unused software installed, we have a
> >> supported mechanism for that: disable automatic installation of
> >> Recommends.
> 
> > Which explodes from time to time, like when ntpdate and ntpd only
> > recommended lockfile-progs (#731976).
> 
> Sure, but hopefully we find and report those as bugs.  I personally run
> without recommends on Debian unstable on several different types of
> systems and report these problems whenever I run into them.
But how do you decide if a specific problem caused by Recommends not
installed is serious enough to be worth a bug report? "all but unusual
installations" after all.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Depends/Recommends from libraries

[Russ Allbery]

Andrey Rahmatullin  writes:
> On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote:

>> If you don't want possibly unused software installed, we have a
>> supported mechanism for that: disable automatic installation of
>> Recommends.

> Which explodes from time to time, like when ntpdate and ntpd only
> recommended lockfile-progs (#731976).

Sure, but hopefully we find and report those as bugs.  I personally run
without recommends on Debian unstable on several different types of
systems and report these problems whenever I run into them.

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

Re: Depends/Recommends from libraries

[Andrey Rahmatullin]

On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote:
> If you don't want possibly unused software installed, we have a supported
> mechanism for that: disable automatic installation of Recommends.
Which explodes from time to time, like when ntpdate and ntpd only
recommended lockfile-progs (#731976).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Depends/Recommends from libraries

[Holger Levsen]

On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote:
> Well, I strongly disagree with you.  I think this would take things in the
> wrong direction; I like that software is fully useful when Recommends are
> enabled at the cost of some bloat.
> 
> If you don't want possibly unused software installed, we have a supported
> mechanism for that: disable automatic installation of Recommends.
> 
> That said, it's certainly still fine to question individual choices, and
> to request a downgrade to Suggests if the provided benefit is marginal.
 
FWIW, +1 on everything here.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Depends/Recommends from libraries

[Russ Allbery]

Ian Jackson  writes:

> I think the right way to solve this problem is to declare that:

>  * When a library package is installed, the Depends and Recommends
>of the library should be appropriate on the assumption that:

>  - the library package is only installed because it is the dormant
>runtime-link-dependency of an executable or other library;

>  - none of the functions in the library are going to be
>called.

>Normally this will mean that the library will reference only other
>library packages, on which it has runtime-link dependencies.

>  * If a library needs or wants additional software installed,
>if and when functions in that library are called, this
>should be documented in the /usr/share/doc/BAR/README.Debian.gz for
>the corresponding -dev library package.  (If churn is
>likely, a library-specific virtual package name may need
>to be documented, and provided as appropriate.)

>  * Programs which call functions in libraries (directly or indirectly)
>should arrange to Depend on, Recommend, or Suggest, the appropriate
>infrastructure, as documented by the -dev package(s).

I think this would be a great way of introducing spurious bugs in our
distribution from people who don't happen to read the README file and miss
dependencies they actually need because they're used to Debian properly
picking up shared library dependencies and to the dependencies of any
given package being fully self-contained.  Both of which, I should add,
are major *features* of our distribution that many of us have worked very
hard to achieve.  I'm opposed.

Now, if this were taken a further step so that dpkg-shlibdeps would
provide some mechanism to *automatically* add those downstream
dependencies to packages that depend on the library unless the
dependencies were explicitly suppressed, I wouldn't be as strongly
opposed.  It still feels like needless complexity to me, but at least we
would default to the known-working dependencies but provide an easy way
for a library consumer to relax those dependencies as needed.  But that
would require writing some additional infrastructure and relabeling all of
those libraries to have a new dependency field, and I strongly suspect
it's more effort than it's worth.

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

Re: Depends/Recommends from libraries

[Russ Allbery]

Jonas Smedegaard  writes:
> Quoting Russ Allbery (2017-03-09 04:24:09)

>> In general, I don't want to see us place too many restrictions on 
>> Recommends.  If you don't want additional helpful programs, disable 
>> installing Recommends by default.  I think it's very odd to worry 
>> about bloat while simultaneously installing Recommends by default; 
>> those aren't really consistent things to do.

> I strongly disagree: We _can_ improve on the default behaviour of our 
> package handling - we need not give up and leave it to power users able 
> to handle arguably broken systems.

Well, I strongly disagree with you.  I think this would take things in the
wrong direction; I like that software is fully useful when Recommends are
enabled at the cost of some bloat.

If you don't want possibly unused software installed, we have a supported
mechanism for that: disable automatic installation of Recommends.

That said, it's certainly still fine to question individual choices, and
to request a downgrade to Suggests if the provided benefit is marginal.

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

Re: Depends/Recommends from libraries

[Ian Jackson]

Russ Allbery writes ("Re: Depends/Recommends from libraries"):
> I feel like the problem here is that people are failing to fix bugs in
> their packages (unnecessary dependencies on libraries that have heavy
> dependencies),

No.  The problem is that for an ordinary library, if package foo ever
wants to call functions in library bar, /usr/bin/foo ends up linked
against libbar.so.  If the libbar runtime is not installed, foo fails
to start at all.

So foo ends up with a Depends on libbar - even if the bar
functionality in foo is an extreme niche feature, or even is only
relevant for some other package wombat (depending on foo).

If libbar has a Depends or Recommends on bar-daemon then default
installations of foo all have bar-daemon installed.

This is a problem because:

 * bar-daemon may have undesirable security properties

 * bar-daemon may need or want configuration, resulting in unnecessary
   config management (including potential exposure of foo's users to
   defects or lacunae in bar's config manageent, migrations, etc.)

 * bar-daemon may be large (disk space, backup, and bandwidth costs,
   especially if bar gets many updates)

 * bar-daemon's dependency stack may itself be large, causing large
   quantities of further unnecessary software to be installed,
   increasing the risks of problems I've just discussed

If foo executed /usr/bin/bar directly, or connected to
/run/bar/socket, or something, then the maintainers of foo (and maybe
wombat) could control the strength of the dependencies themselves,
based on their knowledge of the likely need of foo's (or wombat's)
users for bar, and the error behaviour if the bar-related
functionality is requested without the right pieces installed.

But because foo must Depend on libbar, with our current arrangements
the strength of the dependency is determined by the dependencies of
libbar.

But the bar authors:

 * do not know how or why libbar is called in any particular
circumstances

 * have a natural tendency to assume that their package is more
important than perhaps it is in the global scheme of things

 * are in any case unable to set the dependencies differently
for different callers


I think the right way to solve this problem is to declare that:

 * When a library package is installed, the Depends and Recommends
   of the library should be appropriate on the assumption that:

 - the library package is only installed because it is the dormant
   runtime-link-dependency of an executable or other library;

 - none of the functions in the library are going to be
   called.

   Normally this will mean that the library will reference only other
   library packages, on which it has runtime-link dependencies.

 * If a library needs or wants additional software installed,
   if and when functions in that library are called, this
   should be documented in the /usr/share/doc/BAR/README.Debian.gz for
   the corresponding -dev library package.  (If churn is
   likely, a library-specific virtual package name may need
   to be documented, and provided as appropriate.)

 * Programs which call functions in libraries (directly or indirectly)
   should arrange to Depend on, Recommend, or Suggest, the appropriate
   infrastructure, as documented by the -dev package(s).


This applies to libraries in C and C++.  For libraries in other
languages, it depends on whether the conventional calling pattern for
the library, and the language, is to load it unconditionally (so that
anyone who might call it, no matter how rarely, must require it to be
installed), or to load it on demand.


Ian.

Re: Depends/Recommends from libraries

[Ian Jackson]

Thibaut Paumard writes ("Re: Depends/Recommends from libraries"):
> There are quite legitimate uses for dependencies or recommendations in
> libraries. For instance, tne library that I maintain (libgyoto) has the
> option to provide MPI paralellisation. This requires an external
> executable, which is provided in a separate package. The external tool
> is in a separate package because it can exist only for one architecture
> at a time on the system (it lives in /usr/bin), while the library lives
> in a multi-arch directory.

This is perhaps a nice example.  Mind if I ask some questions ?

You say "an option to provide MPI paralellisation".  Is this option
enabled by default ?  Does it occur with all useful functions in the
library ?  Do library callers control over whether it occurs ?

Are there any programs linked against libgyoto which actually call
into libgyoto only some of the time (perhaps, rarely) ?  (I did a
quick search and it seems that libgyoto's rdependency stack is quite
short.  There's some python modules and something to do with yorick,
but they are all explicitly gyoto-related; and there are some blend
metapackages, which are fine.  So maybe the answer to this is no, but
maybe it will become yes in the future.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#857291: ITP: golang-golang-x-debug -- debugging tools

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg 

* Package name: golang-golang-x-debug
  Version : 0.0~git20160621.0.fb50892-1
  Upstream Author : The Go Authors
* URL : https://golang.org/x/debug
* License : BSD-3-clause
  Programming Lang: Go
  Description : debugging tools

Package debug provides the portable interface to a program being debugged.

golang.org/x/debug is a dependency of cloud.google.com/go, which is a
dependency of upspin.

I know that the package description is very brief, but this is all that
upstream provides us with :|.

Re: Depends/Recommends from libraries

[Thibaut Paumard]

Le 08/03/2017 à 23:33, Adam Borowski a écrit :
> Hi, mortals and paultag!
> 
> I'd like to discuss (and then propose to -policy) the following rule:
> 
> # Libraries which don't provide a convenient means of conditionally loading
> # at runtime (this includes most libraries for languages such as C), SHOULD
> # NOT declare a "Depends:" or "Recommends:" relationship, directly or
> # indirectly, on packages containing anything more than dormant files. 
> # Those include, among others, daemons, executables in $PATH, etc.  Any such
> # relationship should be instead declared by programs that use the library
> # in question -- it is up to them to decide how important the relationship
> # is.

Hi,

This doesn't seem to make sense to me. You list a number of examples
where the outcome of a dependency or recommendation chain is not
desirable. That means that those packages may be improved by breaking
this chain, which doesn't need to go through a policy amendment.

There are quite legitimate uses for dependencies or recommendations in
libraries. For instance, tne library that I maintain (libgyoto) has the
option to provide MPI paralellisation. This requires an external
executable, which is provided in a separate package. The external tool
is in a separate package because it can exist only for one architecture
at a time on the system (it lives in /usr/bin), while the library lives
in a multi-arch directory.

Kind regards, Thibaut.

Re: Depends/Recommends from libraries

[Adrian Bunk]

On Wed, Mar 08, 2017 at 11:33:21PM +, Ian Jackson wrote:
> Adam Borowski writes ("Depends/Recommends from libraries"):
> > I'd like to discuss (and then propose to -policy) the following rule:
> > 
> > # Libraries which don't provide a convenient means of conditionally loading
> > # at runtime (this includes most libraries for languages such as C), SHOULD
> > # NOT declare a "Depends:" or "Recommends:" relationship, directly or
> > # indirectly, on packages containing anything more than dormant files. 
> > # Those include, among others, daemons, executables in $PATH, etc.  Any such
> > # relationship should be instead declared by programs that use the library
> > # in question -- it is up to them to decide how important the relationship
> > # is.
> 
> This seems like a non-brainer to me.  Can anyone come up with a reason
> why this would be wrong in general ?
>...

I can even come up with two:


First, it sounds like a layering violation, forcing programs to know 
about implementation details several layers of dependencies away.

As an example, look at the "libdbus-1-3 -> dbus" Recommends.

When libdbus-1-3 itself is used by a library, I don't see any reasonable
way to push the implementation detail that dbus is used all the way up
to all applications.


Second, what should this achieve?

The mentioned usbmuxd is 0.1 MB.

libglib2.0-0 recommends libglib2.0-data.
The sole contents of libglib2.0-data are 9.5 MB translations.
This recommends would still be permitted, and by default these
translations should be installed.

In the common case disk space is plenty and not a problem.
Except for some cases of daemons, installing too much is
therefore usually not a problem.[1]

Recommends are basically dependencies you are allowed to break when
you know what you are doing, and that's the level of expertise someone 
is expected to have when optimizing disk space usage.


> Ian.

cu
Adrian

[1] "libfoo pulls in 100 MB of data" cases are rare

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#857282: ITP: golang-github-golang-geo -- S2 geometry library in Go

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg 

* Package name: golang-github-golang-geo
  Version : 0.0~git20170112.0.f819552-1
  Upstream Author : Google Inc.
* URL : https://github.com/golang/geo
* License : Apache-2.0
  Programming Lang: Go
  Description : S2 geometry library in Go

 S2 is a library for manipulating geometric shapes. Unlike many geometry
 libraries, S2 is primarily designed to work with spherical geometry, i.e.,
 shapes drawn on a sphere rather than on a planar 2D map. (In fact, the name S2
 is derived from the mathematical notation for the unit sphere.) This makes it
 especially suitable for working with geographic data.
 .
 The library consists of:
 * Basic representations of angles, intervals, latitude-longitude points, unit
   3D vectors, and conversions among them.
 * Various shapes over the unit sphere, such as spherical caps ("discs"),
   latitude-longitude rectangles, polylines, and polygons. These are
   collectively known as "regions".
 * Support for spatial indexing of collections of geometry, and algorithms for
   testing containment, finding nearby objects, finding intersections, etc.
 * A hierarchical decomposition of the sphere into regions called "cells". The
   hierarchy starts with the six faces of a projected cube and recursively
   subdivides them in a quadtree-like fashion.
 * The ability to approximate arbitrary regions as a collection of cells. This
   is useful for building inverted indexes that allow queries over arbitrarily
   shaped regions.  The implementations attempt to be precise both in terms of
   mathematical definitions (e.g. whether regions include their boundaries,
   representations of empty and full regions) and numerical accuracy (e.g.
   avoiding cancellation error).
 .
 Note that the intent of this library is to represent geometry as a
 mathematical abstraction. For example, although the unit sphere is
 obviously a useful approximation for the Earth's surface, functions that
 are specifically related to geography are not part of the core library
 (e.g. easting/northing conversions, ellipsoid approximations, geodetic
 vs. geocentric coordinates, etc).

github.com/golang/geo is a dependency of cloud.google.com/go, which is a
dependency of upspin.

Fwd: Virus spam in the bug tracker

[Holger Levsen]

- Forwarded message from Francois Gouget  -

Date: Thu, 9 Mar 2017 14:23:52 +0100 (CET)
From: Francois Gouget 
To: debian-devel@lists.debian.org
Subject: Virus spam in the bug tracker
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
List-Id: 


This has been mentionned before but today I discovered that a lot of 
Debian bugs have a bunch of spam emails on their tail end. What's worse, 
these actually contain a virus in an attachment.

Do a web search for:

site:bugs.debian.org FedEx
site:bugs.debian.org USPS delivery
site:bugs.debian.org UPS delivery

Since these date back to about 3 to 6 months ago I wonder if the 
administrators missed them. I reported a few dozen of them but it looks 
like something that administrators could cleanup much more efficiently 
since all these spams are very similar (bug #854201 discusses 
spamassassin rules to block them).

Essentially any email that contains the words "FedEX", "USPS" or "UPS", 
and the word "delivery" and a zip or doc attachment contains a virus.

It also feels like this is the sort of email that could have been 
trivially blocked with an anti-virus before ever reaching the BTS.

-- 
Francois Gouget   http://fgouget.free.fr/
   If it stinks, it's chemistry. If it moves, it's biology.
  If it does not work, it's computer science.


- End forwarded message -

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Virus spam in the bug tracker

[Francois Gouget]

This has been mentionned before but today I discovered that a lot of 
Debian bugs have a bunch of spam emails on their tail end. What's worse, 
these actually contain a virus in an attachment.

Do a web search for:

site:bugs.debian.org FedEx
site:bugs.debian.org USPS delivery
site:bugs.debian.org UPS delivery

Since these date back to about 3 to 6 months ago I wonder if the 
administrators missed them. I reported a few dozen of them but it looks 
like something that administrators could cleanup much more efficiently 
since all these spams are very similar (bug #854201 discusses 
spamassassin rules to block them).

Essentially any email that contains the words "FedEX", "USPS" or "UPS", 
and the word "delivery" and a zip or doc attachment contains a virus.

It also feels like this is the sort of email that could have been 
trivially blocked with an anti-virus before ever reaching the BTS.

-- 
Francois Gouget   http://fgouget.free.fr/
   If it stinks, it's chemistry. If it moves, it's biology.
  If it does not work, it's computer science.

Re: Release file for own backport repository?

[Joerg Desch]

I've just tried it without "Version:" and with "Suite:" and "Codename:" 
set to jessie-backports.

After this, "apt-get update" prints the error (jessie expected but jessie-
backports received):

W: Konflikt bei Distribution: http://debian.jdesch.de jessie/ Release 
(jessie erwartet, aber jessie-backports bekommen)


> 
> Origin: joede-backports
> Label: Joedes Debian Jessie backports
> Suite: stable
> Version: 8.1 
> Codename: jessie 
> NotAutomatic: yes
> ButAutomaticUpgrades: yes
> Architectures: amd64
> Components: main contrib
> non-free Description: joede's local repository of backports
> ~

Re: USA TODAY: Google weighs in on WikiLeaks bombshell

[Jan Žolík]

Dňa 9. 3. 2017 9:58 používateľ "Jan Žolík"  napísal:

>From USA TODAY:
Google weighs in on WikiLeaks bombshell
Google is the latest company to weigh in on WikiLeaks' stunning disclosure
yesterday that it is among several high-profile tech companies whose
products canbe turned into spying devices.

http://usat.ly/2m3Wbd2



Get USA TODAY on your mobile device: http://www.usatoday.com/mobile-apps/

Release file for own backport repository?

[Joerg Desch]

Hi. I currently maintain a repository with my own backports for Jessie. 
Therefore I have a Release file with a suite entry "stable". Since my 
backports should be overwriteable by the official backport repository,
I want change the "name" of the origin von "stable" to "jessie-backports".

How do I have to change the "Release" file? Do I have to change the 
entries "Suite:" and "Codename:"?


The content of the current file is:


Origin: joede-backports
Label: Joedes Debian Jessie backports
Suite: stable
Version: 8.1
Codename: jessie
NotAutomatic: yes
ButAutomaticUpgrades: yes
Architectures: amd64
Components: main contrib non-free
Description: joede's local repository of backports
~


I have already lowered the priority to get the same behavior. Without the 
possibility to change the target release, I am no longer able to overcome 
this lower priority.