Re: no{thing} build profiles

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes ("Re: no{thing} build profiles"):

>> Minimal installation size is *not* the only goal here.  Ease of use and
>> lack of surprise is important to.  Personally, I'd much rather have
>> numerous unused packages installed than to have something break in an
>> opaque way when I try to use it, even if I'm unlikely to need to use
>> it.

> I would note that none of this is an argument against demoting this
> dependency to a Recommends.

It is *an* argument, but definitely not as strong of an argument.

I'm pretty strongly opposed to Suggests here.  I think that's simply
wrong.  Recommends is a trickier question, and I can see the case for
asking shared libraries to use Recommends instead of Depends for cases
like this, even if it makes the library essentially non-functional.  I'm
not sure I'm convinced, but there's definitely a strong case, particularly
in cases like gnupg where the package is of non-trivial size.

The primary thing that gives me pause is the error handling.  It needs to
be *really obvious* to the user what to do to make the optional
functionality work if the required package was removed for some reason
(and remember that can be for reasons other than disabling Recommends,
which I agree is an advanced configuration; Recommends aren't enforced
across all conflicting package scenarios), and I'm concerned that shared
libraries throwing some API error is not going to bubble up to the user in
any useful way.

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

Re: Confusing our users - who is supporting LTS?

[Noah Meyerhans]

On Tue, Oct 23, 2018 at 10:05:35PM +0200, Tollef Fog Heen wrote:
> > To be clear, the ongoing cost to the cloud team of dealing with jessie
> > on AWS (where this issue originally came up) has been exactly zero,
> > afaict. That is, we haven't actually updated anything in >18 months.
> > Users who launch a jessie image there get 8.7, with 106 pending updates.
> > As long as LTS exists and users are happy with it, there's nothing
> > strictly wrong with this situation. They should update their instances
> > and reboot, but from there, they are free to continue using them in
> > relative safety.
> 
> I disagree with the statement that there's nothing wrong with this.

Sorry; to be more precise, I meant that there's nothing wrong that can't
be remedied using entirely standard and well-established workflows, e.g.
dist-upgrade. There's no need to add custom apt sources, apt keys, or
anything like that. dist-upgrade is something I'd expect most users to
do pretty early in the lifetime of a cloud instance (and possibly
regularly after that, depending on how long it's expected to remain
active).

noah



signature.asc
Description: PGP signature

Re: Confusing our users - who is supporting LTS?

[Paul Wise]

On Wed, Oct 24, 2018 at 4:15 AM Sean Whitton wrote:
>
> On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote:
> >
> > In short: Make it very clear if you want to provide long-term support
> > for your project. Talk to the LTS team in case you need help. Nobody is
> > forced to do anything.
>
> This is a good idea, but ISTM the assumption should be that the
> subproject does not participate unless it explicitly says that it does.

This thread started because users have the opposite assumption. So I
think it would be better to be explicit about support teams and
timelines.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: no{thing} build profiles

[Marco d'Itri]

On Oct 23, Tollef Fog Heen  wrote:

> > I have sympathy with that position, but in which case PGP should be
> > disabled by default in the /etc/Muttrc files too.
> Wouldn't it make more sense for mutt to just go «oh, no GPG installed,
> let's note that there are signatures here, but they can't be verified,
> since there's no GPG installed on the system» and let the user know
> that?  No need to actually disable PGP support.
Yes. Because this way the default configuration will be useful both 
before and after gnupg will have been installed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#911721: ITP: gramalign -- alignment of multiple biological sequences

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: gramalign
  Version : 3.0
* URL : http://bioinfo.unl.edu/gramalign.php
* License : academic non-free
  Description : alignment of multiple biological sequences

About to appear on salsa.debian.org/med-team/gramalign.

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

[Sébastien Villemot]

Le mardi 23 octobre 2018 à 14:12 +, Mo Zhou a écrit :
> On Mon, Oct 22, 2018 at 07:58:38PM +0200, Bastian Blank wrote:
> > On Mon, Oct 22, 2018 at 07:55:10PM +0200, Sébastien Villemot wrote:
> > > For BLAS/LAPACK implementations implemented in C, like OpenBLAS, they
> > > will be compiled using LP64, and not ILP64. Only integers exposed
> > > through the interface will be affected, through the use of appropriate
> > > types.
> > 
> > So you could also to a proper library transition and drop the support
> > for 32-bit indicies completely?
> 
> Completely dropping 32-bit-index version of BLAS/LAPACK for 64-bit
> architectures is a long way to go. We can keep 32-bit-index version and
> 64-bit-index version at the same time for a while and see if the
> 32-bit-version is really droppable.
> 
> This reminds me two points about wheter the 32-bit-index version is
> droppable. As far as I know, Debian (will) have these BLAS[1] providers:
> 
> (1) bin:libblas3  from  src:lapack
> (2) bin:libatlas3-base  from  src:atlas
> (3) bin:libopenblas-base  from  src:openblas
> (4) bin:libblis1  from  src:blis  [WIP]
> (5) bin:libmkl-rt  from  src:intel-mkl  [non-free]
> (6) bin:libnvblas9.1  from  src:nvidia-cuda-toolkit  [non-free] [2]
> 
> * I confirm these providers support 64-bit index in the API.
>   (2) (3) (4) (5)
> 
>   @Sebastien could you please confirm the status of 64-bit-index support
>   in lapack, i.e. (1) ?

Since the BLAS and LAPACK implementations provided by src:lapack are
pure Fortran code, my understanding is that it's just a matter of
compiling them with -fdefault-integer-8 to get 64-bit indexing.

This package also provides C interfaces (resp. CBLAS and LAPACKE).
LAPACKE provides the necessary type aliases to get 64-bit indexing.
Curiously, CBLAS does not seem to have that flexibility, and will
probably need some (reasonably simple) patching.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


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

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

[Sébastien Villemot]

Le mardi 23 octobre 2018 à 14:17 +, Mo Zhou a écrit :

> Two in the audience are object to the "-ilp64" naming convention.
> Then how about this?
> 
> src:openblas
>  bin:libblas-base   (...)
>  bin:libblas-dev(...)
>  bin:libblas64-base (filename=libblas64.so.3, SONAME=libblas64.so.3,
>  provides=libblas64.so.3-x86_64-linux-gnu)
>  bin:libblas64-dev  (...)

Adding a "64" suffix to the package name and to the SONAME (compared to
the 32-bit indexing version) sounds good to me.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


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

Re: Confusing our users - who is supporting LTS?

[Sean Whitton]

Hello Markus,

On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote:

> I believe LTS is not a black and white issue as it is depicted in this
> thread so far.

Yes, that is fair enough.

> This is the first time that someone expresses concern how LTS affects
> other subprojects but I don't think it is correct to assume that it is a
> general issue which can only be solved by making LTS less integrated
> into Debian. I feel the best way to deal with such situations is to
> communicate very clearly that "subproject X" does not support LTS
> releases and recommends to make an upgrade instead. If subproject X is
> general in favor of LTS support but lacks time and energy to make it
> happen, we should determine whether it is possible and desired that the
> LTS team steps in and lends a helping hand.
>
> In short: Make it very clear if you want to provide long-term support
> for your project. Talk to the LTS team in case you need help. Nobody is
> forced to do anything.

This is a good idea, but ISTM the assumption should be that the
subproject does not participate unless it explicitly says that it does.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Confusing our users - who is supporting LTS?

[Tollef Fog Heen]

]] Noah Meyerhans 

> To be clear, the ongoing cost to the cloud team of dealing with jessie
> on AWS (where this issue originally came up) has been exactly zero,
> afaict. That is, we haven't actually updated anything in >18 months.
> Users who launch a jessie image there get 8.7, with 106 pending updates.
> As long as LTS exists and users are happy with it, there's nothing
> strictly wrong with this situation. They should update their instances
> and reboot, but from there, they are free to continue using them in
> relative safety.

I disagree with the statement that there's nothing wrong with this.

We should not be in the business of distributing known-vulnerable
software.  There are practical considerations around point releases and
such which makes this not-really-true for a period of time after there's
a security update out, but this gets converged at each point release. If
you look cdimage.d.o, we are only distributing the latest point release.
I think the same standard should apply to cloud images.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: no{thing} build profiles

[Tollef Fog Heen]

]] Jonathan Dowland 

> On Tue, Oct 23, 2018 at 02:11:48PM +0200, Marco d'Itri wrote:
> >PGP-signed mail is an highly advanced feature, so I do not think that it
> >is unreasonable to expect from users who want to use it to also install
> >gnupg.
> …
> >No: it is also TOTALLY POINTLESS to even just automatically verify
> >received emails because any result is meaningless unless the local user
> >has manually configured local sources of trust. Which requires
> >installing AND configuring gnupg, so again the user has to know about
> >it.
> 
> I have sympathy with that position, but in which case PGP should be
> disabled by default in the /etc/Muttrc files too.

Wouldn't it make more sense for mutt to just go «oh, no GPG installed,
let's note that there are signatures here, but they can't be verified,
since there's no GPG installed on the system» and let the user know
that?  No need to actually disable PGP support.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Confusing our users - who is supporting LTS?

[Noah Meyerhans]

On Tue, Oct 23, 2018 at 11:03:39AM -0400, Antoine Beaupré wrote:
> TL;DR: Why not just delegate image management to the LTS team once
> oldstable because LTS just like we do with security? Zobel also provided
> a good template for the images life cycle which could clarify this on
> debian-cloud@, which I fully support.

We could certainly delegate. The goal for the future, though, is to have
enough automation in place that continuing to support an old release is
simply a matter of not turning off its image generation. For technical
reasons, jessie is a bit different, but future releases should be
simpler. But the question really isn't "how do we keep publishing and
supporting jessie?", it's "should we keep publishing and supporting
jessie?"

To be clear, the ongoing cost to the cloud team of dealing with jessie
on AWS (where this issue originally came up) has been exactly zero,
afaict. That is, we haven't actually updated anything in >18 months.
Users who launch a jessie image there get 8.7, with 106 pending updates.
As long as LTS exists and users are happy with it, there's nothing
strictly wrong with this situation. They should update their instances
and reboot, but from there, they are free to continue using them in
relative safety.

> But in the cloud infrastructure, things are slightly different. The base
> image isn't as important as the application and/or data that runs on
> top. In the cloud, we install new "machines" all the time, sometimes as
> part of CI/CD processes and those machines are not "pets", they are
> "cattle" and recycled constantly.

That's a very common use case, for sure, but not the only one we want to
support. We definitely do have people who launch an instance and then
keep it around for a long time, interacting with and configuring it by
hand, just as they would with any physical server. (In fact, I recently
noticed a bunch of what appeared to be jessie EC2 instances owned by our
QA team; when I asked about them, I learned that they'd all been
upgraded in place to stretch.)

> In that sense, switching the base OS is, paradoxically, a big deal so
> it actually makes sense to install an older release for newer
> machines. This is why Travis CI still supports Ubuntu LTS Precise
> (12.04) and Trusty (14.04), the former which isn't supported by
> Canonical, and it's missing *two* more recent LTS releases, Xenial
> (16.04) and Bionic (18.04).

Yes, this is correct; it's also something we can continue to support,
even without active engagement from the LTS team. As long as the LTS
team doesn't do anything that breaks updates on the old images, we're
never going to tell people that they can't launch them. The question
here was simply about discoverability. If you're a Debian user just
beginning exploration of public cloud alternatives, should we make it
easy for you to launch LTS instead of stable?

> It seems like a nice, symmetrical approach to solve the problem: just
> punt this over to the LTS team. We have some capacity and knowledge. I
> know I would be happy to work on those images.

I'm not even sure that's necessary. I, as a member of the cloud team and
maintainer of the stretch AWS images, have already expressed willingness
to update the jessie images, if it's something we as a project agree is
appropriate.  Coming to some clearer agreement about that, especially in
light of a decision to the contrary that we made within the cloud team
recently, is the sticky point.

The perception, afaict, is that LTS only exists because people are paid
to work on it. There has not traditionally been sufficient interest
within Debian to sustain support of a release for 5 years, so some
companies have provided financial incentives. That's fine, but potential
somewhat fragile. If that funding goes away, does LTS go away? Is LTS
work, for pay, going to drain resources from volunteer work? These
questions exist outside the context of the current cloud team issue. The
cloud team just happens to be the one to have tripped over them in this
instance.

noah



signature.asc
Description: PGP signature

Re: no{thing} build profiles

[Ivan Shmakov]

> Wouter Verhelst  writes:
> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:

[…]

 >>> I think the prerequisite for making a change like this would be for
 >>> the library to be able to surface this transitive requirement in
 >>> metadata so that debhelper could support automatically adding it
 >>> to the dependencies of all linked programs (and I’m not sure that
 >>> sort of collapse of our dependency structure is a good idea).

 >> That would be a bad idea – we don’t want gratuitous dependencies
 >> all around.  Just because I use xfce doesn’t mean I want a daemon
 >> for some old kinds of iApple iJunk

 > Why not?  What does it cost you, other than a few bits on your hard
 > disk, to have those things installed?

 > It is an actual cost for users who do not (want to) understand the
 > technical background in why their iSomething doesn’t communicate with
 > Debian properly, and it costs *us* time in support questions if we
 > have to explain to them that they just need to install this one
 > little thing here that takes a few MB (if that; haven’t checked).

It works both ways, actually.  I’ve recently seen a problem
with a newly installed system ending up with /two/ configured
IPv4 addresses (where one was expected.)  The cause of this
surprise?  Recommends:¹.

More specifically, the admin there installed isc-dhcp-client and
configured interfaces(5) accordingly.  He also installed lxqt,
which Recommends: cmst, which in turn Depends: connman (entirely
appropriately, I guess, as the former is a GUI for the latter),
which /also/ configures network interfaces.

  ¹ Not entirely, obviously.  But the claim that ‘more is better,’
and leads to ‘lack of surprise’ and a ‘more straightforward user
experience’ isn’t without a flaw when it comes to practice.

 > My laptop, which has a 240G SSD, is mostly full.  That is, however,
 > *not* because of the amount of software that’s installed; 90% of that
 > storage is in my /home.

 > I suspect that the same is true for most users, and therefore that we
 > just shouldn’t care about it.

The disk usage is indeed a concern, even if likely minor for an
average user.  Consider, for instance, that you run a dozens of
VMs and want Mutt installed on every single one.  Unless you use
LXC on Btrfs with transparent deduplication there, the gnupg and
its own dependencies may accumulate into a non-trivial disk usage.

Alternatively, if you perform incremental block-level backups of
the root filesystem (and I do), every update to the gnupg package
(within the archive retention time) – as well as each of its
unique dependencies – will add the respective Installed-Size: to
the archive size.

Another issue is that GnuPG, being called from Mutt automatically
by default, /does/ increase the attack surface.  Of course, you
can (remember to) turn it off in the configuration, but the more
/straightforward/ way to avoid that is /not to install/ the package
in the first place.  In general, the software that you do /not/
have installed, is most certainly /not/ going to break.

Then, there’s the issue of surprise.  The software which hooks
into other software that you use /can/ surprise you.  For example,
the bash-completion package makes Bash completion function
unusable to me; so I usually do not install it at all, and where
it is installed, I make sure to disable it with ‘complete -r’ in
my personal configuration.

To summarize, I’d expect for a non-trivial fraction of experienced
users to actually put effort into minimizing the amount of
/code/ installed – precisely to /ensure/ straightforward and
unsurprising behavior.

As for GnuPG, well, as Mario points out, – it’s useless unless
configured by the user, /and/ is prone to result in ‘cryptic’
error messages even if correctly installed.  In turn, to configure
GnuPG, the user will presumably have to invoke it directly, or
perhaps from some UI wrapper, at which point he either will notice
the absence of the command, /or/ the absence of said wrapper –
for which it /would/ be entirely reasonable to depend on gnupg.

So the particular point that Mutt is going to misbehave without
GnuPG installed is moot: the cause for its misbehavior wouldn’t
be the lack of GnuPG, but rather the lack of user’s knowledge of
it – or motivation to use.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: no{thing} build profiles

[Vincent Lefevre]

On 2018-10-23 17:01:04 +0200, Wouter Verhelst wrote:
> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> > That would be a bad idea -- we don't want gratuitous dependencies
> > all around. Just because I use xfce doesn't mean I want a daemon
> > for some old kinds of iApple iJunk
> 
> Why not? What does it cost you, other than a few bits on your hard disk,
> to have those things installed?

If executables are installed somewhere in $PATH, this hurts
completion.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: no{thing} build profiles

[Vincent Lefevre]

On 2018-10-23 16:55:00 +0200, Wouter Verhelst wrote:
> On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> > * Sune Vuorela  [181021 06:05]:
> > > On 2018-10-21, Jonas Smedegaard  wrote:
> > > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at 
> > > > all: 
> > > > As a library it cannot possibly declare how tight a relationship to 
> > > > declare - instead, all _consumers_ of the library must declare whether 
> > > > they depend/recommend/suggest gnupg.
> > > 
> > > libgpgme is completely useless without gnupg. I think it is perfectly
> > > fine for these kind of relations, unless we really are in corner-case
> > > territory. See for example fam.
> > 
> > I strongly agree with Jonas.  Upstream links to libgpgme as a .so to
> > provide optional behavior.  This requires libgpgme to be installed in
> > order to even run neomutt, whether the user wants the feature or not.
> > It is perfectly reasonable to want to install neomutt but want to _not_
> > install gnupg.
> 
> Not in Debian.
> 
> The Debian philosophy in this has always been to link against all
> libraries where possible, and to detect at runtime whether something can
> be used. [...]

This matches what Marvin said just above: Link against libgpgme (thus
depend on it) and let the user choose whether to install gnupg or not.
The availability of gnupg is checked at runtime.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: no{thing} build profiles

[Ian Jackson]

Russ Allbery writes ("Re: no{thing} build profiles"):
> Minimal installation size is *not* the only goal here.  Ease of use and
> lack of surprise is important to.  Personally, I'd much rather have
> numerous unused packages installed than to have something break in an
> opaque way when I try to use it, even if I'm unlikely to need to use it.

I would note that none of this is an argument against demoting this
dependency to a Recommends.

Ian.

Re: Confusing our users - who is supporting LTS?

[Antoine Beaupré]

Hi Steve!

On 2018-10-23 04:26:18, Steve McIntyre wrote:
> So I'm worried that those of us who have *not* volunteered to support
> LTS are being pressured into spending our time on it anyway. What can
> we do to fix that? How/where do we clarify for our users (and
> developers!) what LTS means, and what expectations are fair?

TL;DR: Why not just delegate image management to the LTS team once
oldstable because LTS just like we do with security? Zobel also provided
a good template for the images life cycle which could clarify this on
debian-cloud@, which I fully support.

I acknowledge this is, indeed, a problem Debian volunteers have
sometimes mentioned. It's a broader issue than just the cloud team of
course, but if I may, I would like to try and fix that specific issue in
itself. I know there's the larger debate of separation of duty and
infrastructure, paid-vs-unpaid work and other questions, but I do not
think it's productive to fix that particular issue by addressing the
larger ones up front, as they seem intractable unless we address
specific cases.

In this case, it seems to me we have a flawed assumption in the way we
handle Debian LTS: we assume people will not actually install it and
instead just upgrade machines installed when LTS was "stable". It's a
fair assumption in the case of workstations and long-lived, "pet"
servers. I know I wouldn't install a new bare-metal server with an
unsupported release: I would install stretch, if not buster, not jessie.

But in the cloud infrastructure, things are slightly different. The base
image isn't as important as the application and/or data that runs on
top. In the cloud, we install new "machines" all the time, sometimes as
part of CI/CD processes and those machines are not "pets", they are
"cattle" and recycled constantly. In that sense, switching the base OS
is, paradoxically, a big deal so it actually makes sense to install an
older release for newer machines. This is why Travis CI still supports
Ubuntu LTS Precise (12.04) and Trusty (14.04), the former which isn't
supported by Canonical, and it's missing *two* more recent LTS releases,
Xenial (16.04) and Bionic (18.04).

So while we haven't taken up the work of managing the debian-installer
parts of Debian LTS (because there was no need or demand for it), it
seems to me like a fair request that the Debian LTS team should manage
the Debian Cloud images once the official support window closes. Just
like the security team delegates oldstable to LTS, the cloud team could
hand off unsupported images to the LTS team. In a way, just like APT and
the normal archive, "cloud images" are just another way to "upgrade" an
existing Debian install.

It seems like a nice, symmetrical approach to solve the problem: just
punt this over to the LTS team. We have some capacity and knowledge. I
know I would be happy to work on those images.

That's for the expectations part of the question. As for how to clarify
this to our users, Martin Zobel-Helas made a good proposal for a
workflow of how and when the team updates the images and when they
become unsupported. The /etc/motd in the images could mention this, for
example and the last build could add a warning pointing to it. If we
agree to delegate to the LTS team, the document should also mention that
transition.

Sorry for the long email, I hope it's useful!

a.

-- 
We have to talk about liberating minds as well as liberating society.
- Angela Davis

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

[Drew Parsons]

On 2018-10-23 22:17, Mo Zhou wrote:

Hi Sebastien,

Two in the audience are object to the "-ilp64" naming convention.
Then how about this?

src:openblas
 bin:libblas-base   (...)
 bin:libblas-dev(...)
 bin:libblas64-base (filename=libblas64.so.3, SONAME=libblas64.so.3,
 provides=libblas64.so.3-x86_64-linux-gnu)
 bin:libblas64-dev  (...)



This is consistent (modulo hyphen) with Cray, which has

cray-petsc   cray-petsc-64
cray-tpslcray-tpsl-64

Curiously Cray's BLAS implementation (cray-libsci) doesn't have a 
separate 64 version.


Drew

Re: no{thing} build profiles

[Andrey Rahmatullin]

On Tue, Oct 23, 2018 at 05:01:04PM +0200, Wouter Verhelst wrote:
> > That would be a bad idea -- we don't want gratuitous dependencies all
> > around.  Just because I use xfce doesn't mean I want a daemon for some old
> > kinds of iApple iJunk
> 
> Why not? What does it cost you, other than a few bits on your hard disk,
> to have those things installed?
Installed and started.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: no{thing} build profiles

[Vincent Lefevre]

On 2018-10-22 10:47:05 +0100, Jonathan Dowland wrote:
> On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:
> > It can be argued that libgpgme11 does not “provide a significant
> > amount of functionality” (7.2) without gnupg.
> 
> It won't function at all without gnupg.

That's pointless. A library *alone* is not usable. The real dependency
should come from the application that will use gnupg via libgpgme11.

Imagine a package A that provides an application that is linked
against libgpgme because gnupg may be used as an optional feature,
say by 0.1% of the users. This package must depend on libgpgme11,
otherwise the application wouldn't even run (even in the case
libgpgme will not be used). But a Depends or Recommends on gnupg
will annoy 99.9% of the users; thus it should just be a Suggests.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: no{thing} build profiles

[Adam Borowski]

On Tue, Oct 23, 2018 at 04:55:00PM +0200, Wouter Verhelst wrote:
> On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> > * Sune Vuorela  [181021 06:05]:
> > > On 2018-10-21, Jonas Smedegaard  wrote:
> > > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at 
> > > > all: 
> > > > As a library it cannot possibly declare how tight a relationship to 
> > > > declare - instead, all _consumers_ of the library must declare whether 
> > > > they depend/recommend/suggest gnupg.
> > > 
> > > libgpgme is completely useless without gnupg. I think it is perfectly
> > > fine for these kind of relations, unless we really are in corner-case
> > > territory. See for example fam.
> > 
> > I strongly agree with Jonas.  Upstream links to libgpgme as a .so to
> > provide optional behavior.  This requires libgpgme to be installed in
> > order to even run neomutt, whether the user wants the feature or not.
> > It is perfectly reasonable to want to install neomutt but want to _not_
> > install gnupg.
> 
> Not in Debian.
> 
> The Debian philosophy in this has always been to link against all
> libraries where possible, and to detect at runtime whether something can
> be used. This introduces a much larger dependency tree, but ends up
> being easier to use for most users.

Link against the _libraries_.  That's indeed much more reliable, requires
less effort, and has a minimal cost (the libraries themselves take little
space).  And the library itself is content not having gnupg installed as
long as its functions don't get used.

> The alternative is something like Gentoo, where you *can* decide what
> you compile in and what you don't. The trouble with Gentoo, however, is
> that you spend seven hours installing it, and then your mouse doesn't
> work because you set one USE flag incorrectly and now you have to
> recompile the universe (I exaggerate, but you get the point).

That's why libgpgme is compiled into our mutts.  That's nice; the Depends
from mutt to libgpgme11 is not in question here -- what I'm complaining
about is the Depends from libgpgme11 on gnupg and Recommends on the rest of
gpg programs.

It's trivial to install gnupg if you need it; it does nothing good without
some manual configuration anyway.

> > The proper fix is to convince upstream to dynamically link at runtime
> > and disable some features if libgpgme is not available.
> 
> That's a great way to introduce a large set of bugs of the "oops, tried
> to use libX when dlopen failed for some reason" type. It's better to
> avoid that issue by just having a hard dependency on the library in
> question.

Yeah, most languages don't handle missing libs gracefully; we can cut the
chain in a place where it's easier to make it optional.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Re: Confusing our users - who is supporting LTS?

[Markus Koschany]

[I am trimming the CC list a little. Steve is subscribed to debian-lts.
Our leader is subscribed to debian-lts and debian-devel and drowns in
emails anyway. I hope you agree.]

Am 23.10.18 um 15:47 schrieb Sean Whitton:
[...]
> The more LTS is integrated with the regular project, the more that teams
> will feel they have to spend time on LTS matters.  Even if paid LTS team
> members are the ones writing the patches to do the actual integration,
> the relevant Debian team will still have to review those patches, engage
> in design discussion and keep LTS needs in mind while doing their other
> work.  Indeed, that's what you're asking for in the paragraphs of your
> e-mail I've quoted.  Reducing integration avoids this problem.

I believe LTS is not a black and white issue as it is depicted in this
thread so far. We neither solve such a problem by hiding LTS nor by
reducing the integration within the Debian project. The goals of the LTS
project have been clearly communicated from the beginning and nobody was
ever forced to work on them. [1] Our main goal is to extend the lifetime
of stable releases by providing security support and bug fixes for all
packages except those which are marked as unsupported in our
debian-security-support package. That has never implied that we support
every official or non-official subproject that bases its work on the
availability of LTS.

This is the first time that someone expresses concern how LTS affects
other subprojects but I don't think it is correct to assume that it is a
general issue which can only be solved by making LTS less integrated
into Debian. I feel the best way to deal with such situations is to
communicate very clearly that "subproject X" does not support LTS
releases and recommends to make an upgrade instead. If subproject X is
general in favor of LTS support but lacks time and energy to make it
happen, we should determine whether it is possible and desired that the
LTS team steps in and lends a helping hand.

In short: Make it very clear if you want to provide long-term support
for your project. Talk to the LTS team in case you need help. Nobody is
forced to do anything.

Regards,

Markus

P.S.:

As a first step I'm going to create a LTS/Jessie subpage on our wiki
that will outline what we currently (don't) support in Jessie.

[1] https://wiki.debian.org/LTS/



signature.asc
Description: OpenPGP digital signature

Re: no{thing} build profiles

[Wouter Verhelst]

On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
> > Adam Borowski  writes:
> > 
> > > Thus, I'd re-propose a Policy change that was mentioned in multiple
> > > threads in the past:
> > 
> > > "A runtime library should not Depend: or Recommend: on any packages than
> > > other libraries or dormant data, unless the library or its programming
> > > language provides a convenient scheme for it being loaded only
> > > optionally.  Any such dependencies should be declared by programs linked
> > > against such a library."
> > 
> > I think the prerequisite for making a change like this would be for the
> > library to be able to surface this transitive requirement in metadata so
> > that debhelper could support automatically adding it to the dependencies
> > of all linked programs (and I'm not sure that sort of collapse of our
> > dependency structure is a good idea).
> 
> That would be a bad idea -- we don't want gratuitous dependencies all
> around.  Just because I use xfce doesn't mean I want a daemon for some old
> kinds of iApple iJunk

Why not? What does it cost you, other than a few bits on your hard disk,
to have those things installed?

It is an actual cost for users who do not (want to) understand the
technical background in why their iSomething doesn't communicate with
Debian properly, and it costs *us* time in support questions if we have
to explain to them that they just need to install this one little thing
here that takes a few MB (if that; haven't checked).

My laptop, which has a 240G SSD, is mostly full. That is, however, *not*
because of the amount of software that's installed; 90% of that storage
is in my /home.

I suspect that the same is true for most users, and therefore that we
just shouldn't care about it.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Debian Buster release to partially drop non-systemd support

[Wouter Verhelst]

On Sat, Oct 20, 2018 at 08:22:35AM +0800, Paul Wise wrote:
> On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote:
> 
> > As long as people choose to strip of dependencies to libsystemd from
> > packages like util-linux, avoiding a fork would not work with how Debian
> > and Debian based distributions are built.
> 
> It might be feasible to introduce nosystemd build profiles to Debian
> source packages

This has been discussed before and rejected. It makes no sense.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: no{thing} build profiles

[Wouter Verhelst]

On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> * Sune Vuorela  [181021 06:05]:
> > On 2018-10-21, Jonas Smedegaard  wrote:
> > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all: 
> > > As a library it cannot possibly declare how tight a relationship to 
> > > declare - instead, all _consumers_ of the library must declare whether 
> > > they depend/recommend/suggest gnupg.
> > 
> > libgpgme is completely useless without gnupg. I think it is perfectly
> > fine for these kind of relations, unless we really are in corner-case
> > territory. See for example fam.
> 
> I strongly agree with Jonas.  Upstream links to libgpgme as a .so to
> provide optional behavior.  This requires libgpgme to be installed in
> order to even run neomutt, whether the user wants the feature or not.
> It is perfectly reasonable to want to install neomutt but want to _not_
> install gnupg.

Not in Debian.

The Debian philosophy in this has always been to link against all
libraries where possible, and to detect at runtime whether something can
be used. This introduces a much larger dependency tree, but ends up
being easier to use for most users.

The alternative is something like Gentoo, where you *can* decide what
you compile in and what you don't. The trouble with Gentoo, however, is
that you spend seven hours installing it, and then your mouse doesn't
work because you set one USE flag incorrectly and now you have to
recompile the universe (I exaggerate, but you get the point).

> The proper fix is to convince upstream to dynamically link at runtime
> and disable some features if libgpgme is not available.

That's a great way to introduce a large set of bugs of the "oops, tried
to use libX when dlopen failed for some reason" type. It's better to
avoid that issue by just having a hard dependency on the library in
question.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#911682: ITP: libmojo-sqlite-perl -- tiny Mojolicious wrapper for SQLite

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: libmojo-sqlite-perl
  Version : 3.001
  Upstream Author : Dan Book 
* URL : https://metacpan.org/release/Mojo-SQLite
* License : Artistic-2.0
  Programming Lang: Perl
  Description : tiny Mojolicious wrapper for SQLite

Mojo::SQLite is a tiny wrapper around DBD::SQLite that makes SQLite a
lot of fun to use with the Mojolicious real-time web framework. Use
all SQL features SQLite has to offer, generate CRUD queries from data
structures, and manage your database schema with migrations.

The package will be maintained under the umbrella of the Debian Perl
Group.

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

[Mo Zhou]

On Tue, Oct 23, 2018 at 02:12:16PM +, Mo Zhou wrote:
> (1) bin:libblas3  from  src:lapack
> (2) bin:libatlas3-base  from  src:atlas
> (3) bin:libopenblas-base  from  src:openblas
> (4) bin:libblis1  from  src:blis  [WIP]
> (5) bin:libmkl-rt  from  src:intel-mkl  [non-free]
> (6) bin:libnvblas9.1  from  src:nvidia-cuda-toolkit  [non-free] [2]
> 
> * I confirm these providers support 64-bit index in the API.
>   (2) (3) (4) (5)
> 
>   @Sebastien could you please confirm the status of 64-bit-index support
>   in lapack, i.e. (1) ?

Sorry, I mistyped. (2) shouldn't be there.

(2) seems not supporting 64-bit index.
It's header uses "const int" as the type of index.
header available in bin:libatlas-base-dev

And I took a look into the netlib blas, aka the standard BLAS
implementation and it's index type is "const int" too ...


Not every BLAS provider can provide 64-bit-index API.  It's fine if only
OpenBLAS (3), MKL (5), BLIS (4) can provide 64-bit-index API, because
they are basically the fastest cpu-based BLAS implementations publically
available.

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

[Mo Zhou]

Hi Sebastien,

Two in the audience are object to the "-ilp64" naming convention.
Then how about this?

src:openblas
 bin:libblas-base   (...)
 bin:libblas-dev(...)
 bin:libblas64-base (filename=libblas64.so.3, SONAME=libblas64.so.3,
 provides=libblas64.so.3-x86_64-linux-gnu)
 bin:libblas64-dev  (...)

* Unlike Fedora or Julia upstream, we don't mangle symbol names.

On Mon, Oct 22, 2018 at 07:55:10PM +0200, Sébastien Villemot wrote:
> Le lundi 22 octobre 2018 à 18:38 +0100, Simon McVittie a écrit :
> > On Mon, 22 Oct 2018 at 18:17:32 +0100, Ben Hutchings wrote:
> > > On Mon, 2018-10-22 at 15:07 +, Mo Zhou wrote:
> > > > Here are some references:
> > > > 
> > > > 1. 
> > > > https://software.intel.com/en-us/mkl-linux-developer-guide-using-the-ilp64-interface-vs-lp64-interface
> > > > 
> > > >    The Intel MKL ILP64 libraries use the 64-bit integer type (necessary
> > > >    for indexing large arrays, with more than 231-1 elements), whereas
> > > >    the LP64 libraries index arrays with the 32-bit integer type.
> > > 
> > > [...]
> > > 
> > > The correct C types for indexing arrays are ptrdiff_t and size_t. 
> > > These are already 64-bit in LP64 ABIs.  So this seems like a workaround
> > > for code using the wrong types.
> > 
> > Do BLAS/LAPACK really mean ILP64, or do they really mean "ABI with large
> > array indexes"?
> 
> The latter. This is why I think that "ILP64" is a misnomer, and should
> not be used for labeling the newly introduced libraries.
> 
> The ambiguity arises from the fact that some BLAS/LAPACK
> implementations are written in Fortran, and use the default integer
> type for array indexes. Hence the solution is to compile them with
> -fdefault-integer-8. But this does not mean that this code is really
> ILP64, because it's not C and hence it does not uses the C ABI. Only
> integers exposed through the BLAS/LAPACK ABI are affected (most of them
> are array indices, the remaining others are return codes).
> 
> For BLAS/LAPACK implementations implemented in C, like OpenBLAS, they
> will be compiled using LP64, and not ILP64. Only integers exposed
> through the interface will be affected, through the use of appropriate
> types.
> 
> 
> Best,
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
> ⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
> ⠈⠳⣄  http://www.debian.org

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

[Mo Zhou]

On Mon, Oct 22, 2018 at 07:58:38PM +0200, Bastian Blank wrote:
> On Mon, Oct 22, 2018 at 07:55:10PM +0200, Sébastien Villemot wrote:
> > For BLAS/LAPACK implementations implemented in C, like OpenBLAS, they
> > will be compiled using LP64, and not ILP64. Only integers exposed
> > through the interface will be affected, through the use of appropriate
> > types.
> 
> So you could also to a proper library transition and drop the support
> for 32-bit indicies completely?

Completely dropping 32-bit-index version of BLAS/LAPACK for 64-bit
architectures is a long way to go. We can keep 32-bit-index version and
64-bit-index version at the same time for a while and see if the
32-bit-version is really droppable.

This reminds me two points about wheter the 32-bit-index version is
droppable. As far as I know, Debian (will) have these BLAS[1] providers:

(1) bin:libblas3  from  src:lapack
(2) bin:libatlas3-base  from  src:atlas
(3) bin:libopenblas-base  from  src:openblas
(4) bin:libblis1  from  src:blis  [WIP]
(5) bin:libmkl-rt  from  src:intel-mkl  [non-free]
(6) bin:libnvblas9.1  from  src:nvidia-cuda-toolkit  [non-free] [2]

* I confirm these providers support 64-bit index in the API.
  (2) (3) (4) (5)

  @Sebastien could you please confirm the status of 64-bit-index support
  in lapack, i.e. (1) ?

* Provider (6) will become a tragedy when Debian no longer provide
  32-bit-index version of BLAS... nvBLAS is a quite special BLAS
  implementation. NVIDIA calls it a "drop in" BLAS library but in fact
  it only implemented several level-3 BLAS routines. When a program
  calls a BLAS function that doesn't exist in nvBLAS, nvBLAS will pass
  the call into another BLAS implementation which is defined in a
  configuration file given by the user.
  
  That means, nvBLAS should call a library which uses index in the same
  width. And nvblas.h suggests that this library only supports 32-bit
  index.
  
  60 /* GEMM */ 
 
  61 void sgemm_ (const char *transa, const char *transb, const int *m, const 
int *n, const int *k,
  62  const float *alpha, const float *a, const int *lda, const 
float *b, const int *ldb,
  63  const float *beta, float *c, const int *ldc); 
 

  nvBLAS blocks the removal of 32-bit-index version of BLAS...


[1] Not mentioning LAPACK here.
[2] It has not been added to the update-alternatives system yet.

Re: Confusing our users - who is supporting LTS?

[Sean Whitton]

Hello Raphael,

On Tue 23 Oct 2018 at 09:52AM +0200, Raphael Hertzog wrote:

> Instead we are rather aiming to integrate LTS more and more everywhere.
> However, when LTS is becoming a burden on other teams, we should
> definitely look how the LTS team can help to alleviate that burden.
> Because as you know the LTS team has paid contributors to do that kind
> of work.
>
> I invite you to start a conversation between debian-lts and debian-cloud
> to discuss how the LTS team can help you with the workload that you would
> rather get rid of. Maybe we need to allocate some time each month to
> update LTS images, maybe you need our help to improve your tooling to better
> support LTS and that would be enough, etc. I don't know. Let's discuss.

Unfortunately, I don't think this suggestion could help with the issues
raised by Steve.

The more LTS is integrated with the regular project, the more that teams
will feel they have to spend time on LTS matters.  Even if paid LTS team
members are the ones writing the patches to do the actual integration,
the relevant Debian team will still have to review those patches, engage
in design discussion and keep LTS needs in mind while doing their other
work.  Indeed, that's what you're asking for in the paragraphs of your
e-mail I've quoted.  Reducing integration avoids this problem.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

[Mo Zhou]

On Mon, Oct 22, 2018 at 09:57:56PM +0200, Florian Weimer wrote:
> > Proposal:
> >
> >   * The "-ilp64" postfix should be appended to the SONAME of all the new
> > shared objects that provide ILP64 interface. For example:
> >
> >   libblas.so.3 (LP64) -> libblas-ilp64.so.3 (ILP64)
> >
> > As a result, the same postfix should be added to the binary package
> > name. For example:
> >
> >   libblas3 (LP64) -> libblas-ilp64-3 (ILP64)
> >
> >   * No change will be made to all the present BLAS/LAPACK libraires that
> > provide LP64 interface.
> >
> >   * No change will be made to either API or ABI of BLAS/LAPACK.
> >
> >   * This proposal only applies to 64-bit-capable architectures.
> 
> Why do you want to retain the libraries with 32-bit indices?  Is it
> for ABI compatibility with Fortran code that uses them directly?
 
BLAS/LAPACK providers with 32-bit index have to stay in the archive for
a while for compatibility. And BLAS/LAPACK maintainers will have enough
time to align all the affected pacakges and diagnoze with possible
problems.

> What's the time frame for these changes?  Is it likely that a Fortran
> ABI bump occurs before that anyway?
 
I have no ETA. 32-bit and 64-bit index version of BLAS/LAPACK packages
are expected to co-exist for a while. Only when all the reverse
dependencies don't break with 64-bit index version should we consider
dropping the 32-bit index version.

Bug#911671: ITP: haskell-shelly -- shell-like (systems) programming in Haskell

[Ilias Tsitsimpis]

Package: wnpp
Severity: wishlist
Owner: Ilias Tsitsimpis 

* Package name: haskell-shelly
  Version : 1.8.1
  Upstream Author : Greg Weber 
* URL : https://hackage.haskell.org/package/shelly
* License : BSD-3-clause
  Programming Lang: Haskell
  Description : shell-like (systems) programming in Haskell
  .
  Shelly provides convenient systems programming in Haskell,
  similar in spirit to POSIX shells. Shelly:
  .
   * is aimed at convenience and getting things done rather than
 being a demonstration of elegance
   * has detailed and useful error messages
   * maintains its own environment, making it thread-safe
   * is modern, using Text and system-filepath/system-fileio
  .
  Shelly is originally forked from the Shellish package.

This is a dependency for newer versions of fsnotify (>= 0.3.0.0).

-- 
Ilias

Re: no{thing} build profiles

[Jonathan Dowland]

On Tue, Oct 23, 2018 at 02:11:48PM +0200, Marco d'Itri wrote:

PGP-signed mail is an highly advanced feature, so I do not think that it
is unreasonable to expect from users who want to use it to also install
gnupg.

…

No: it is also TOTALLY POINTLESS to even just automatically verify
received emails because any result is meaningless unless the local user
has manually configured local sources of trust. Which requires
installing AND configuring gnupg, so again the user has to know about
it.


I have sympathy with that position, but in which case PGP should be
disabled by default in the /etc/Muttrc files too.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: no{thing} build profiles

[Marvin Renich]

[I'm subscribed; please do not CC me.]

* Matthias Klumpp  [181022 14:18]:
> Because having a real dependency eliminates another source of bugs.
> The library will throw weird (for unexperienced end-users) errors and
> they have to hunt down a solution for why something isn't working as
> they expect.

Why would a library give a weird error to a user?  It is the
application's responsibility to check the return code from the library
and provide an appropriate message to the user (e.g. "Unable to
initialize gpg library."), which should be sufficient for the end user
to track down the problem, even if the message is a bit cryptic to them
at first.  The point here is that it is still a bug in the software if
error messages are insufficient to correct the issue.  So if someone
reports "my application broke and I can't figure out what to do",
retitle the bug to "Error message given to user when libgpgme returns
failure is too cryptic."  It is still a bug, just a different one than
the user reported.

> The "Recommends" relation should work here in theory, in practice
> though people manage to remove stuff that was recommended by accident,

I think this is the key point.  Your experiences are obviously different
from mine, because I do not see accidental removal of recommended
packages very often.  However, I am willing to accept that it does
happen, and its likelihood probably depends on the organization (which
might be a personal one-user computer or a cluster of corporate servers)
and its admins.

> or even configure APT to never install recommends, and then end up
> with things not working (granted, in the latter case it's their own
> fault).

Right.

However, in both cases, abusing the dependency system to force the
installation of a package that the admin should be able to choose not to
install in specific situations is the wrong answer.

In a well-run organization, the admins either will install recommends as
the default, or they will be rather selective about choosing appropriate
dependencies to install or not install.  Further, their users will come
to them, not Debian, with problems.

Debian can't do anything about poorly-run larger organizations, and
should not abuse dependencies to try to fix them. :-P

That mostly leaves the single-user computer with a less experienced
user-admin.  I suspect that this is the source of the large majority of
this class of bug reports.  If you think about why they would configure
APT to not install recommends, it is likely because they have heard that
Debian has a reputation for inflating dependencies, and they don't
really need all the Recommended packages.  I think in some cases this
reputation either is or was justified.

So, what is the solution?  Keep inflating dependencies until everything
is Depends?  This is exactly the wrong solution.

There are at least two better responses to these "false" bug reports.
The first is to retitle and forward upstream as in my reply above.  The
second is to enhance reportbug to list recommended packages that are not
installed and encourage the user to try to reproduce the problem with
all recommended packages installed.  Also, reportbug can check the APT
configuration and nudge the user if appropriate as well as including it
in the bug report for the maintainer's information.

The problem with inflating Suggests to Recommends is that then people
routinely avoid installing Recommends.  However, inflating Recommends to
Depends is _much_ worse, because you have removed the admin's ability to
make informed choices.

Ignoring the policy definition of Recommends to avoid getting bug
reports from inexperienced users (or more experience users who are about
to have a palm-to-forehead moment) is simply and unequivocally wrong.

...Marvin

Re: no{thing} build profiles

[Marco d'Itri]

On Oct 23, Jonathan Dowland  wrote:

> Both of Depends and Recommends in this case have drawbacks. It's a
> matter of weighing them up and considering their likelyhoods on a case
> by case basis. In this case, the maintainer must weigh the experience of
> users who may install mutt without gnupg and get a compromised
> experience, and how likely they are to hit that, versus the likelyhood
> that a user would be significantly troubled by installing gnupg even if
> they don't intend to use it; and in the latter case, factor in that we
> do have a system for addressing that, equivs, as you point out.
It's not just gnupg. gnupg depends on (among many other things) 
gpg-agent, which depends on pinentry, which used to pull in X libraries 
unless I remembered to manually install pinentry-curses first.
It has always been a pain and it is not justified just to check the 
content of a maildir in a server.
PGP-signed mail is an highly advanced feature, so I do not think that it 
is unreasonable to expect from users who want to use it to also install 
gnupg.

> In the case of mutt&neomutt, both are configured to have PGP enabled by
> default. With the default configuration, as soon as you read a
> PGP-signed mail, you will hit the behaviour that requires gnupg
> installed to function properly. Due to this, I don't think this
No: it is also TOTALLY POINTLESS to even just automatically verify 
received emails because any result is meaningless unless the local user 
has manually configured local sources of trust. Which requires 
installing AND configuring gnupg, so again the user has to know about 
it.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: no{thing} build profiles

[Jonas Smedegaard]

Quoting Jonathan Dowland (2018-10-23 11:06:15)
> On Mon, Oct 22, 2018 at 11:32:21AM -0400, Marvin Renich wrote:
> >I'm going to use the neomutt → libgpgme → gnupg as an example, but 
> >this applies as well to any other case where someone has a legitimate 
> >use for installing one package without a dependency that would 
> >normally be found with that package.
> >
> >If libgpgme Depends: gnupg, then anyone who wishes to install 
> >libgpgme (or, in cases like this, a package that has a Depends: 
> >libgpgme) without gnupg must either use equivs to build a fake gnupg 
> >package or build a modified libgpgme package that does not depend on 
> >gnupg.
> 
> Both of Depends and Recommends in this case have drawbacks. It's a 
> matter of weighing them up and considering their likelyhoods on a case 
> by case basis. In this case, the maintainer must weigh the experience 
> of users who may install mutt without gnupg and get a compromised 
> experience, and how likely they are to hit that, versus the likelyhood 
> that a user would be significantly troubled by installing gnupg even 
> if they don't intend to use it; and in the latter case, factor in that 
> we do have a system for addressing that, equivs, as you point out.

I believe you are mistaken: 

What should be weighed on a case-by-case basis is Recommends versus 
Suggests.

Depends should *only* be used when not even exotic use is possible 
without the package relation satisfied.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: no{thing} build profiles

[Marvin Renich]

* Russ Allbery  [181022 16:23]:
> Minimal installation size is *not* the only goal here.  Ease of use and
> lack of surprise is important to.

Then don't disable Recommends in apt preferences.

> Personally, I think people in this thread are too worried about trying to
> remove as many packages from their system as possible and not worried
> enough about a straightforward user experience.

I agree with Adam here.  The problem is that it is not just a small
number of packages that inflate dependencies.  It only takes a few
inflated dependencies here and a few there to result in significant
bloat.

And to be clear, this thread is not about the difference between
Suggests and Recommends.  Both of those cases allow the admin to choose
not to install the dependent package.  It is about the difference
between Recommends and Depends.  Once this line is crossed, you have
taken away the sysadmin's ability to choose.

...Marvin

Re: no{thing} build profiles

[Holger Levsen]

On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
> Personally, I think people in this thread are too worried about trying to
> remove as many packages from their system as possible and not worried
> enough about a straightforward user experience.

yep.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: no{thing} build profiles

[Jonathan Dowland]

On Mon, Oct 22, 2018 at 11:32:21AM -0400, Marvin Renich wrote:

This keeps getting repeated in this thread in spite of the fact that
multiple people have stated that having libgpgme installed without gnupg
is useful in a very reasonable scenario.


The scenario you describe, where the utility of the libgpgme package is
soley as a way of satisfying a package dependency, and nothing to do
with the bytes contained within the package, is an interesing case. It
has taken me a few attempts to actually understand that this utility was
what you (and Ivan iirc) were referring to. But it's not the traditional
understanding of the utility of a package, and I don't think it's a
purpose that was being considered when the relevant sections of policy
were written.


Why are some maintainers so adamant about using Depends when Recommends
is the correct dependency?


Because we don't agree that it is!


I'm going to use the neomutt → libgpgme → gnupg as an example, but this
applies as well to any other case where someone has a legitimate use for
installing one package without a dependency that would normally be found
with that package.

If libgpgme Depends: gnupg, then anyone who wishes to install libgpgme
(or, in cases like this, a package that has a Depends: libgpgme) without
gnupg must either use equivs to build a fake gnupg package or build a
modified libgpgme package that does not depend on gnupg.


Both of Depends and Recommends in this case have drawbacks. It's a
matter of weighing them up and considering their likelyhoods on a case
by case basis. In this case, the maintainer must weigh the experience of
users who may install mutt without gnupg and get a compromised
experience, and how likely they are to hit that, versus the likelyhood
that a user would be significantly troubled by installing gnupg even if
they don't intend to use it; and in the latter case, factor in that we
do have a system for addressing that, equivs, as you point out.

In the case of mutt&neomutt, both are configured to have PGP enabled by
default. With the default configuration, as soon as you read a
PGP-signed mail, you will hit the behaviour that requires gnupg
installed to function properly. Due to this, I don't think this
functionality can be considered niché. Adam Borowski makes a compelling
argument that it should be niché in another mail to this thread; but
this should be reflected in the default configuration, IMHO, before any
dependency strengths are altered.


However, if libgpgme Recommends: gnupg, then gnupg will be installed
whenever libgpgme is installed, _unless_ the admin specifically prevents
its installation.


By "specifically prevents its installation" you may be referring to a
much older decision that the admin made to disable installing Recommends
by default, possibly when they installed the OS. When the user runs mutt
and the PGP functionality does not work, they may not necessarily relate
that failure to their early policy decision, which might have been a
long time ago. And that's a situation we want to avoid, especially for
beginner users.


N.B. the policy definition of 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.

That definition fits the relationship between libgpgme and gnupg
perfectly.


It's vague definition with plenty of room for interpretation, on
purpose, precisely so that a decision can be made factoring in all of
the considerations outlined above on a case-by-case basis.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Package deb with shared library

[Thomas Goirand]

On 10/22/18 12:36 PM, Damir Porobic wrote:
> Hi All,
> 
> 
> I was not sure to which Mailing list my question belongs so I'm writing
> here, if I should use a different list, let me know.
> 
> 
> Currently I'm trying to create a .deb package for my Application and I'm
> kind of stuck with packaging a shared library that I use. The shared
> library is not available via any public repository, so it can't be
> installed the usual way, but it's open source and I build it from source
> and install before I package the application. It's installed under
> //usr/local//.

You must create a Debian package that installs the lib in a proper
directly under /usr/lib. That's the correct way to do things.

> I was able to build the .deb package but when I install it on a machine,
> it fails to start with the message that it was not able to find my
> shared library.

Which means that you haven't installed the lib at the correct place.

> Is there a way to deploy my shared library with the .deb package without
> my shared library being available on public repos? If yes, could you
> point me to an example?

Get the source package from any library in Debian and have a look how
its made.

Cheers,

Thomas Goirand (zigo)

Re: Confusing our users - who is supporting LTS?

[Raphael Hertzog]

Hi Steve,

On Tue, 23 Oct 2018, Steve McIntyre wrote:
> So I'm worried that those of us who have *not* volunteered to support
> LTS are being pressured into spending our time on it anyway. What can
> we do to fix that? How/where do we clarify for our users (and
> developers!) what LTS means, and what expectations are fair?

FWIW, I don't think that the right answer is to make LTS even more clearly
separate. We want to be able to say that Debian is supported for 5 years
and we don't want to have to put an asterisk pointing to a long list of
exceptions.

Instead we are rather aiming to integrate LTS more and more everywhere.
However, when LTS is becoming a burden on other teams, we should
definitely look how the LTS team can help to alleviate that burden.
Because as you know the LTS team has paid contributors to do that kind
of work.

I invite you to start a conversation between debian-lts and debian-cloud
to discuss how the LTS team can help you with the workload that you would
rather get rid of. Maybe we need to allocate some time each month to
update LTS images, maybe you need our help to improve your tooling to better
support LTS and that would be enough, etc. I don't know. Let's discuss.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature