Re: Search content (.h files) of all (-dev) packages?

[Alexander Traud]

Thank you so much. Both helped. For another project, I am going for the -dev 
package content. For this issue here, the source turned out to be much easier.

The result is a bit astonishing. I have not checked for false positives yet. 
But the initial search gave 650 affected source packages. I expected perhaps 15 
packages, which I fix then. However, that is 2.5% of the actual amount, 40 
times more than envisioned. Any idea how to tackle that?

Re: merged /usr vs. symlink farms

[Luca Boccassi]

On Fri, 2021-11-12 at 04:57 +0100, Guillem Jover wrote:
> 
> On Sun, 2021-08-22 at 11:21:38 +0100, Luca Boccassi wrote:
> > On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote:
> > > On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote:
> > > > The bug is real, nobody doubts that - it has been filed on dpkg 20
> > > > years ago.
> > > 
> > > You keep repeating this, but I have no idea what bug you refer to.
> > > 
> > > There's #148258 (from 2002), which is conffile related, and not
> > > actionable and should probably just be closed.
> > > 
> > > There's #182747 (from 2003), which while apparently similar is
> > > something else completely. This is about the (IMO) misfeature of
> > > supporting a local admin to redirect (not alias) a directory using a
> > > local symlink (mainly for space management reasons). For an
> > > explanation
> > > see .
> > > 
> > > There's #406715 (from 2007) which is related to the above misfeature.
> > 
> > I am referring to #134758 since it's linked as the root cause from
> > usrmerge's #848622.
> 
> Well, that's a bogus block then, because that's obviously not the root
> cause. I see I was CCed when that block was set, I guess I missed it.
> :/ Fixed it now…
> 
> > "dpkg-query: Make -S handle unowned symlinks resolving to owned
> > pathnames" filed in February 2002 - 19 years and a half ago. I refer to
> > that because it's linked as the root cause in the BTS of the relevant
> > issue with usrmerge we are discussing.
> 
> Even if the wishlist from that report got implemented, it would still
> not fully solve all the problems, where among them «dpkg-query -S»
> is probably the lesser one, which would not work in the other direction
> anyway (querying a path under /usr/ known to dpkg as being under /).
> 
> And then I'm not convinced this should even be implemented at all,
> as it would introduce behavior differences between literal pathnames
> and patterns, and making them slower (for the first case) or potentially
> extremely slower (for the second case), in addition to making the queries
> dependent on the on-disk layout (so unreliable from the packaging PoV,
> as it would invent on the spot, pathnames not truly coming from any
> package nor otherwise known to dpkg).
> 
> This for a misfeature in dpkg (supporting redirecting symlinks) that
> allowed the current mess anyway. So I'm inclined to wontfix and close
> that one.
> 
> 
> Not looking forward to further interactions…
> Guillem

Thanks for following up! There are currently 469 open bugs against
src:dpkg, it's of course entirely up to you which ones you choose to
fix and which one you close+wontfix. As far as workarounds go, this one
is really really trivial to deal with, so I personally wouldn't mind at
all.

Thank you for your work!

-- 
Kind regards,
Luca Boccassi


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

Re: merged-/usr transition: debconf or not?

[Luca Boccassi]

On Fri, 2021-11-12 at 08:38 +0100, Ansgar wrote:
> Hi Svante,
> 
> On Thu, 2021-11-11 at 23:22 +0100, Svante Signell wrote:
> > I'm not sure he has the skill or experience enough to submit a patch to
> > dpkg. Complaining is much easier than proposing something constructive.
> 
> I would like to remind you that Debian expects somewhat decent behavior
> of contributors. Please see https://www.debian.org/code_of_conduct
> 
> Ansgar
> 

And I want to also add that even if the same request was expressed in
an acceptable form (it was not), may I also remind participants in this
thread that according to our Constitution (2.1), no project member is
obliged to do work on anything they don't want to, and hence it follows
that it is not appropriate to berate a fellow project member for this
reason, even if it was done in a respectful tone (which again it was
not, in this occasion).

So if any project member feels particularly strongly about this issue,
which to the best of my knowledge has not been actually observed in the
wild despite this setup being the default for 100% of Ubuntu users who
install/upgrade to 21.10, 100% of new Ubuntu installs since ~2018 and
an unspecified number of Debian installs being the default in our
installer too for the past two stable releases (and despite other
unrelated Replaces: bugs actually existing and being reported over
time), the constructive way forward would seem to me to contribute the
work themselves to solve it. I dare say it would help their cause a
great deal more, instead of rekindling flame wars on a mailing list, to
come here and say "Hey, here's an alternative
tool/patchset/software/mechanism that has the exact same result but
does not suffer from the issue we are worried about. Could you help us
test it, please?". I for one would be happy to help testing such
alternatives.

-- 
Kind regards,
Luca Boccassi


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

Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?

[Stephan Verbücheln]

Hello

My impression is that web based projects lean towards OpenSSL, while
for example the whole GTK/Gnome desktop stack is using GnuTLS (with
nettle/hogweed). So you will not get rid of either crypto stack.

Then I also think that OpenSSL 0.9.x/1.x and the new OpenSSL 3.x have
to be treated like two completely different libraries. They have
different licenses and intentionally broke APIs to end the mess that
OpenSSL was. It is a situation like Python 2 and 3, we will have both
around for a long time, because upstream code has to be ported to new
APIs.

An then there is NSS by Mozilla, and there is also libgcrypt, which is
the basis of GnuPG. To my knowledge, it does not even share core
routines with GnuTLS. GnuPG is also a core dependency for any Debian
installation that we will not get rid of.

tl;dr: There are many different crypto libraries which more or less do
the same thing, but we will not likely get rid of any.

Regards
Stephan

Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?

[Simon McVittie]

On Fri, 12 Nov 2021 at 12:03:53 +, Stephan Verbücheln wrote:
> My impression is that web based projects lean towards OpenSSL, while
> for example the whole GTK/Gnome desktop stack is using GnuTLS (with
> nettle/hogweed). So you will not get rid of either crypto stack.

I believe the reason why GNOME-adjacent projects generally prefer
GnuTLS is that GNOME's conventional license is LGPL (or sometimes GPL),
resulting in licensing conflicts between the (L)GPL's copyleft and the
OpenSSL 1.x license's advertising clause.

For permissively-licensed (non-copyleft) projects, OpenSSL's licensing
is less of a barrier, and a lot of web projects are permissively-licensed,
so it's unsurprising if they lean towards OpenSSL.

In principle, GTK applications that require TLS should all or nearly
all be using the TLS abstractions available in GLib since around 2011
(such as GTlsConnection), which get their implementation from plugins
rather than directly from GLib, so that distributions that feel strongly
about this sort of thing can use their preferred implementation without
having to patch GLib.

The usual TLS plugins for GLib come from GNOME's glib-networking, which
has both GnuTLS and OpenSSL backends (although I believe the OpenSSL
backend is still considered experimental, and we don't compile it in
Debian). Third-party plugins are also possible, but I don't think we
have any in Debian.

In practice, I'm sure some GNOME and GNOME-adjacent applications use
GnuTLS, OpenSSL and/or NSS directly, either because they need finer
control over TLS behaviour or because they are older than 2011 and never
got converted to use GLib's TLS abstractions.

> An then there is NSS by Mozilla, and there is also libgcrypt, which is
> the basis of GnuPG. To my knowledge, it does not even share core
> routines with GnuTLS.

My understanding is that libgcrypt is a low-level crypto library
comparable to nettle/hogweed and OpenSSL's libcrypto, whereas GnuTLS
is a higher-level TLS library comparable to OpenSSL's libssl.

GnuTLS 2.x used libgcrypt, which it shared with GnuPG. GnuTLS 3.x uses
nettle/hogweed instead.

smcv

Bug#999559: ITP: python-django-parler -- Django model translations (Python3 version)

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-parler
  Version : 2.2.1
  Upstream Author : Diederik van der Boor 
* URL : https://github.com/django-parler/django-parler
* License : Apache-2
  Programming Lang: Python
  Description : Django model translations (Python3 version)


Simple Django model translations without nasty hacks.
Features:
 * Nice admin integration.
 * Access translated attributes like regular attributes.
 * Automatic fallback to the default language.
 * Separate table for translated fields, compatible with django-hvad.
 * Plays nice with others, compatible with django-polymorphic and django-mptt.

I intend to maintain this package as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmGOekIRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoFogf+Lueux6WWoBB4+NqZAsPdczuO2ki7v9gd
GFTUYYw295xUTZRlfllyg8dzXckls+0fmHz6gzSLtzSg4VyTZth3UOjP1k2RJ8wK
0ff+Cy2Uwov4+mXvRxbKeYYmEA98YJDOR0d39UfQN6yuKjvxsi63u7tH5EWD0Way
3W7o4E7ATez1Vkdxi3Wp/nt/GkBOieofuEp6kge/1eCcnTVIR03F53a24bCXPmoy
HwIR2J7QJ9Twx6Qvcmyqj/YXzArE59S3ILy2+4eTDNpg8RhLkj+5PG2JV+hDgRDI
qpoTgQXYm+k/uaFViTai1eJpU77c/PrWKkn3+3Vqbnw4aJGd6H+S6A==
=RGVh
-END PGP SIGNATURE-

Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?

[Andrey Rahmatullin]

On Fri, Nov 12, 2021 at 12:03:53PM +, Stephan Verbücheln wrote:
> Then I also think that OpenSSL 0.9.x/1.x and the new OpenSSL 3.x have
> to be treated like two completely different libraries. They have
> different licenses and intentionally broke APIs to end the mess that
> OpenSSL was. 
When you say "intentionally broke APIs to end the mess that OpenSSL was"
you shouldn't say "0.9.x/1.x":
https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes

> It is a situation like Python 2 and 3, we will have both around for a
> long time, because upstream code has to be ported to new APIs.
Just like for 1.1? Or do you think it will be longer this time?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Epoch bump for golang-github-valyala-fasthttp

[Guillem Jover]

On Fri, 2021-11-12 at 10:55:26 +0530, Pirate Praveen wrote:
> On 12 November 2021 12:38:23 am IST, Guillem Jover  wrote:
> >The golang-github-valyala-fasthttp package used to have date-based
> >release numbers (current Debian version 20160617-2). Upstream has
> >since switched to semver (latest upstream version 1.31.0).
> >
> >So the version scheme has been reset, and unfortunately given that no
> >prefix was used when initially packaging this, an epoch seems to be in
> >order now.
> >
> >I'm planning on updating in the coming days to the latest upstream
> >release and bump the version using an epoch.
> 
> How about golang-github-valyala-fasthttp-v1 ?
> Though it won't match import path, it can avoid the epoch.

While interesting, I think this might be worse. I'm not a fan of
epochs, but this is precisely the case they were intended for. The way
I see it, the source package name is now burned, and even if we played
games and used a different source+binary name w/o epoch, but breaking
the current convention and expectation of package names trying to map
closely to import paths, the current source+binary one could/should not
be reused anyway, so we might as well bump the epoch there, and if in
the future there's a «.v1» kind of import path bump, then we can simply
drop the current one and completely get rid of the epoch.

> Most projects change import paths on incompatible bumps.

But this didn't happen upstream in this case.

Thanks,
Guillem

Re: Epoch bump for golang-github-valyala-fasthttp

[Emilio Pozuelo Monfort]

On 12/11/2021 16:26, Guillem Jover wrote:

On Fri, 2021-11-12 at 10:55:26 +0530, Pirate Praveen wrote:

On 12 November 2021 12:38:23 am IST, Guillem Jover  wrote:

The golang-github-valyala-fasthttp package used to have date-based
release numbers (current Debian version 20160617-2). Upstream has
since switched to semver (latest upstream version 1.31.0).

So the version scheme has been reset, and unfortunately given that no
prefix was used when initially packaging this, an epoch seems to be in
order now.

I'm planning on updating in the coming days to the latest upstream
release and bump the version using an epoch.


How about golang-github-valyala-fasthttp-v1 ?
Though it won't match import path, it can avoid the epoch.


While interesting, I think this might be worse. I'm not a fan of
epochs, but this is precisely the case they were intended for.


Indeed, I think an epoch bump here is sensible.

Cheers,
Emilio

Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?

[Russ Allbery]

Stephan Verbücheln  writes:

> Then I also think that OpenSSL 0.9.x/1.x and the new OpenSSL 3.x have to
> be treated like two completely different libraries. They have different
> licenses and intentionally broke APIs to end the mess that OpenSSL
> was. It is a situation like Python 2 and 3, we will have both around for
> a long time, because upstream code has to be ported to new APIs.

I don't think the changes in OpenSSL 3.x are anywhere near as significant
as the changes between Python 2 and Python 3.  They seem largely in line
with the kinds of changes that are always required when there's a new
major OpenSSL release (and are far, far less significant than, say, the
differences between the OpenSSL and GnuTLS APIs).

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

Bug#999570: ITP: libfuture-io-perl -- collection of Future-returning IO methods

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libfuture-io-perl
  Version : 0.10
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Future-IO
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : collection of Future-returning IO methods

The Future::IO distribution provides a few basic methods that behave
similarly to the same-named core perl functions relating to IO operations,
but yield their results asynchronously via Future instances.

This is provided primarily as a decoupling mechanism, to allow modules to be
written that perform IO in an asynchronous manner to depend directly on this,
while allowing asynchronous event systems to provide an implementation of
these operations.

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

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#999589: ITP: catatonit -- Lightweight init implementation for containers

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: catatonit
  Version : 0.1.7
  Upstream Author : 2018 SUSE LLC
* URL or Web page : https://github.com/openSUSE/catatonit
* License : GPLv3
  Description : Lightweight init implementation for containers

A container init that is so simple it's effectively brain-dead. This is a
rewrite of [initrs][initrs] in C, because we found that it is not possible to
statically compile Rust binaries without using musl. That was, in turn, a
reimplementation of other container inits like `tini` and `dumb-init`.

The reason for re-implementing `docker-init` is because it appears as though
all of the other implementations do not handle signals as correctly as they
should. In particular, they all appear to make use of `sigwait(2)` (`tini` does
a `sigtimedwait(2)` for an interval and then will do a `waitpid(2)` even if it
didn't detect a `SIGCHLD`). `catatonit` uses `signalfd(2)`, which [has its own
warts][signalfd-broken], but the improvements over `sigwait(2)` are significant
in terms of stability. Ideally we would just write a patch for the other
projects to use `signalfd(2)` rather than creating a new project, but after
some time spent looking at `tini` and `dumb-init` we felt that such patches
would be closer to full rewrites.

In addition, the purpose of `catatonit` is to only support the key usage by
`docker-init` which is `/dev/init -- `. With few exceptions, no
other features will be added.

Co-maintainers welcome!