Re: Q: Ubuntu PPA induced version ordering mess.

[Jens Reyer]

Am 2. Juli 2024 01:59:26 MESZ schrieb Alec Leamas :
>Soren et. al.,
>
>On 02/07/2024 01:31, Soren Stoutner wrote:
>> Alec,
>> 
>> 
>> If upstream wants to fix this problem, they could just make their next 
>> release
>> version 9000, with the one after that either being 9001 or 9000.1.
>> 
>> Or, possibly, they could encourage everyone to uninstall the PPA package
>> before installing an official one.  For example, release a new package to 
>> their
>> PPA that displays a message encouraging everyone to uninstall the PPA 
>> package,
>> remove the PPA from their list of repositories, and *then* install the 
>> official
>> one.
>> 
>> As a general rule, I wouldn’t expect a user to keep a PPA package installed
>> when switching to an official package.  There is generally no guarantee that
>> upgrading from a PPA package to an official one will work without errors.
>> 
>> Or, once the official package had entered the system, they could instruct 
>> users
>> to remove the PPA from their list of repositories and then perform a
>> downgrade.
>> 
>> All of that being said, Debian could use an epoch to fix the problem.  Having
>> an epoch on a package isn’t the worst thing that has ever happened.
>> 
>So, at least three possible paths:
>
>1. Persuade users to uninstall PPA packages before installing official 
>packages and also generation 2 PPA packages with sane versions like 5.10.x
>
>2. Use versions like 9000.5.10, 9000.5.12. etc.
>
>3. Use an epoch.
>
>Of these I would say that 1. is a **very** hard sell upstream. Users are used 
>to just update and will try, fail and cause friction.
>
>2. and 3. both adds something which must be kept forever. Given this choice I 
>tend to think that the epoch is the lesser evil, mostly because the package 
>version could match the "real" version.
>
>That is, the idea that next opencpn release officially would be 9000.5.10 just 
>won't fly. 2. would be about using package versions with a number prefix like 
>9000. which is not really visible to users.  And that means an impedance 
>problem between the upstream version and the packaged one. A problem the epoch 
>does not have.
>
>--alec
>

[Currently on my phone with no direct access to my Debian mail 
jre.wine...@gmail.com, but annoying autocorrect and topposting instead]

You may avoid the epoch if upstream is willing to provide a separate package 
for about 2 years. (I did something similar to get rid of an epoch in Ubuntu's 
wine packages a few years ago, replacing them with our Debian packages):

package 9000.5.10
Depends: package-transition-to-new-versioning

package-transition-to-new-versioning 5.9.2-1


In 2 years:
package-transition-to-new-versioning 5.9.2-2
Depends: package 5.9.2-2

You'll also need some breaks/replaces in Debian's packages.

I might dig out the details later if your interested.

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

(sorry, I replied thinking I've read the entire thread, I didn't notice
that there is a second thread broken off of this one)


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

On Mon, Jul 01, 2024 at 11:59:00PM +0200, Alec Leamas wrote:
> > > After some thought, I tend to think that adding an epoch is the right 
> > > thing
> > > here.
> > > 
> > > The Policy [1] says:
> > > ---
> > > Epochs can help when the upstream version numbering scheme changes, but 
> > > they
> > > must be used with care. You should not change the epoch, even in
> > > experimental, without getting consensus on debian-devel first.
> > > ---
> > > 
> > > With all this said: Is this a case where using a epoch is justified? If 
> > > not,
> > > why?
> > 
> > Adding epochs to work around 3rd-party repo version problems sounds quite 
> > wrong.
> > We don't even add epochs that Ubuntu itself adds.
> > 
> 
> But this is not about third parties, it's about upstream which publishes PPA
> packages. 

I don't think it matters that they are published by the upstream.
Similarly to the versions issue you are not required to guarantee smooth
upgrades from 3rd-party packages and other such things.

> I also hesitate to add an epoch, after all they are basically considered
> evil. But if we should not use them when upstream has a broken versioning we
> are about to replace, when should we use it?

When upstream had a broken versioning *that we used in Debian*.

> I have good relations with upstream, and they are willing to abandon the
> current broken versioning in favor of something sane. But the legacy is
> there, and we need to handle it.

Again, it's just questionable to me if we *need* to handle upgrades from
non-Debian packages.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Mandatory LC_ALL=C.UTF-8 during package building

[Guillem Jover]

Hi!

On Fri, 2024-06-07 at 15:40:07 +0200, Alexandre Detiste wrote:
> Maybe a compromise would be to at least mandate some UTF-8 locale.

Ah, good thinking! That would actually seem acceptable. I've prepared
the attached preliminary patch (missing better commit message, etc),
as a PoC for how this could look like. If there's consensus about
something like this, I'd be happy to merge into a future dpkg release.

Although I'm not sure though whether this would be enough to make it
possible to remove the hardcoding of LC_ALL=C.UTF-8 usage in debhelper,
which seems counter to l10n work, or perhaps to switch to a subset of
the locale settings. Niels?

Thanks,
Guillem
From 94c2540fe290ffaa70680d21725e3541642ab2f2 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 2 Jul 2024 03:34:35 +0200
Subject: [PATCH] dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when
 building packages

Proposed-by: Alexandre Detiste 
---
 scripts/dpkg-buildpackage.pl | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index df2edded9..3f02f81ca 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -27,6 +27,7 @@ use File::Temp qw(tempdir);
 use File::Basename;
 use File::Copy;
 use File::Glob qw(bsd_glob GLOB_TILDE GLOB_NOCHECK);
+use I18N::Langinfo qw(langinfo CODESET);
 use POSIX qw(:sys_wait_h);
 
 use Dpkg ();
@@ -589,6 +590,19 @@ if ($signsource && build_has_none(BUILD_SOURCE)) {
 if ($sanitize_env) {
 run_vendor_hook('sanitize-environment');
 }
+my %allow_codeset = map { $_ => 1 } qw(
+UTF-8
+ANSI_X3.4-1968
+ANSI_X3.4-1986
+ISO646-US
+ASCII
+US-ASCII
+);
+
+my $codeset = langinfo(CODESET);
+if (not exists $allow_codeset{$codeset}) {
+error(g_('requires a locale with a UTF-8 (or ASCII) codeset'));
+}
 
 my $build_driver = Dpkg::BuildDriver->new(
 ctrl => $ctrl,
-- 
2.45.2

Re: Q: Ubuntu PPA induced version ordering mess.

[Guillem Jover]

Hi!

On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote:
> On 2024-07-01 23:59 +0200, Alec Leamas wrote:
> > But this is not about third parties, it's about upstream which publishes PPA
> > packages. So far these are by far the most used Linux packages.
> > 
> > I also hesitate to add an epoch, after all they are basically considered
> > evil. But if we should not use them when upstream has a broken versioning we
> > are about to replace, when should we use it?
> 
> Quite. People are quite resistant to spoiling neat version numbers
> with epochs, and no-one likes them, but they don't do any actual harm
> (except sometimes break scripts and tools that forgot to allow for
> them),

Oh, but they can cause actual harm. As has been mentioned on this
list many times, epochs by design invalidate existing versioned
relationships in both packaging fields (inside the distro (but in this
case that does not look like a problem) and on custom local packages),
and on tools/(maint)scripts comparing these versions. These can either
cause letting versions that should not be installed through, or can
cause version unsatisfiability.

There's also the problem that epochs are (currently) not included as
part of the filenames.

They are also a common source of errors, due to people forgetting they
need to add them in relationships (if you read package changelogs,
this is a common-ish occurrence).

This is covered in the dpkg FAQ (although I should probably also add
the accidental omission case):

  
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F

> and this seems seems like a very sensible use case: essentially
> jus thwat they are intended for.. Yes it was upstream that messed up
> not us/you, but we have the technology and you can make user's lives
> easier by just adding an epoch.

I guess the first question that pops in my mind is whether users who
have installed the packages from the PPA, because the Debian/Ubuntu
packages were not satisfactory, are going to be switching to the
Debian/Ubuntu packages? Perhaps only temporarily and then back to
the PPA? Are we going to get a version arms-race then?

(Personally I'd find the "sort the mess on the PPA side", the better
approach, but *shrug*.)

> It's a pity upsream didn't know about the 0~ trick so that it wouldn't
> matter what crazy version string was used, but it's done now.

AFAIUI upstream was using "correct" versions in their releases, they
just used the build-increment-based versions in that PPA.

Thanks,
Guillem

Re: Q: Ubuntu PPA induced version ordering mess.

[Scott Kitterman]

On July 2, 2024 12:26:49 AM UTC, Soren Stoutner  wrote:
>Alec,
>
>On Monday, July 1, 2024 5:19:37 PM MST Alec Leamas wrote:
>> For Debian users we backport opencpn which works well. However, the
>> Ubuntu backport process is, well, interesting (been there, done that).
>> 
>> The PPA represents a much better way to publish backports to current
>> Ubuntu branches. But for this to work we need to reset the versioning so
>> it works together with the official stream from Debian.
>> 
>> Anyway, seems we have a emerging conclusion that an epoch is a correct
>> solution here.
>
>That adds some needed clarification.  I agree that in that circumstance, 
>adding 
>an epoch is the best way forward.  It allows you to maintain the current 
>upstream program version number, while unifying the Debian, Ubuntu, and PPA 
>version numbers in such a way that packages from those repositories can be 
>used interchangeably.
>
I would suggest that you work with upstream on how they will version things in 
the future, so you aren't bumping the epoch every year.

Scott K

Re: Q: Ubuntu PPA induced version ordering mess.

[Soren Stoutner]

Alec,

On Monday, July 1, 2024 5:19:37 PM MST Alec Leamas wrote:
> For Debian users we backport opencpn which works well. However, the
> Ubuntu backport process is, well, interesting (been there, done that).
> 
> The PPA represents a much better way to publish backports to current
> Ubuntu branches. But for this to work we need to reset the versioning so
> it works together with the official stream from Debian.
> 
> Anyway, seems we have a emerging conclusion that an epoch is a correct
> solution here.

That adds some needed clarification.  I agree that in that circumstance, adding 
an epoch is the best way forward.  It allows you to maintain the current 
upstream program version number, while unifying the Debian, Ubuntu, and PPA 
version numbers in such a way that packages from those repositories can be 
used interchangeably.

-- 
Soren Stoutner
so...@debian.org

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

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

HI again,

This becomes somewhat more complicated than it perhaps is.

On 02/07/2024 02:08, Soren Stoutner wrote:


Although I generally agree with your conclusions, using a PPA is the type of
end user task that involved them making modifications to the repositories on
their systems.  I would assume that anyone who has done so, and who is already
running Linux instead of Windows, is fully capable of handling a “downgrade”
to an official package.  Asking users to remove the PPA they manually added and
install an official package doesn’t really seem like that hard of an ask to me.



But this is not about replacing the PPA with the official packages.

For various reasons opencpn tends be released just after a Debian 
release in summertime, and the Debian version thus quite outdated when 
it hits the Ubuntu repos.


For Debian users we backport opencpn which works well. However, the 
Ubuntu backport process is, well, interesting (been there, done that).


The PPA represents a much better way to publish backports to current 
Ubuntu branches. But for this to work we need to reset the versioning so 
it works together with the official stream from Debian.


Anyway, seems we have a emerging conclusion that an epoch is a correct 
solution here.


--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Russ Allbery]

Alec Leamas  writes:

> So, at least three possible paths:

> 1. Persuade users to uninstall PPA packages before installing official
> packages and also generation 2 PPA packages with sane versions like
> 5.10.x

> 2. Use versions like 9000.5.10, 9000.5.12. etc.

> 3. Use an epoch.

> Of these I would say that 1. is a **very** hard sell upstream. Users are
> used to just update and will try, fail and cause friction.

> 2. and 3. both adds something which must be kept forever. Given this
> choice I tend to think that the epoch is the lesser evil, mostly because
> the package version could match the "real" version.

I would use an epoch.

It sounds like the PPA was in serious use by the intended users and
they're going to be switching to your packages.  You are trying to make
that easy and avoid obvious and easily-forseen problems and I think that's
good: that's exactly what a maintainer should do.  If it were just a
handful of people you could walk through the transition, that's maybe
different, but it sounds like that's not the case.

2 is a hard sell to upstream for psychological reasons.  Maybe it
shouldn't be, maybe upstream should be fine with this, but as you say
upstream in practice isn't going to be fine with this and honestly if I
were upstream I probably wouldn't be either, even if I knew I should be.
It's hard enough to get people to use version numbers properly.  Getting
them to use a "weird" version number that their users might be confused by
for the rest of time is going to be difficult.

Changing the version number only in Debian is even worse: that's just
horribly confusing for users and will be forever.  And the confusion is
going to affect upstream as well.

Basically, you'd be burning a lot of social capital with upstream for no
really good reason and you probably still wouldn't be able to convince
them.  I don't think it's worth it.

I would just use the epoch.  I know people really hate them and they have
a few weird and annoying properties, but we have a bunch of packages with
epochs and it's mostly fine.  It's something you'll have to keep working
around forever, but not in a way that's really that hard to deal with,
IMO.  (I would also warn upstream that you're doing that, so that they
know what the weird "1:" thing means in bug reports in the future and why
it's there.)

This feels like exactly the type of situation that epochs were designed
for: upstream was releasing packages with weird version numbers and now
they're effectively going back to normal version numbers that are much
smaller.  In other words, to quote policy, "situations where the upstream
version numbering scheme changes."  Yes, in this case it was only in their
packages and not in their software releases, but that still counts when
they have an existing user base that has those packages installed.

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

Re: Q: Ubuntu PPA induced version ordering mess.

[Soren Stoutner]

Alec,

Is upstream planning to maintain their PPA after the packages are released into 
Debian?  
Or, will it be more like Gentoo, OpenSUSE, or Mageia, where the OpenCPN website 
simply links to the official packages?

https://opencpn.org/OpenCPN/info/downloadopencpn.html[1]

On Monday, July 1, 2024 5:06:54 PM MST Alec Leamas wrote:
> So have I also understood it.
> 
> And this is more or less the situation. For all practical purposes the
> PPA is the current upstream packages, it's not some random packaging of
> opencpn. I have some control over both the PPA and the debian/ubuntu
> packages.
> 
> And what we want to do is to switch the upstream versioning in a way
> which means the "next" version is lower than current version. The end
> game is that the PPA is proper pre-releases of the official packages,
> built from the same sources and debian/ directories.
> 
> On other words, a rather good example on when an epoch makes sense.
> 
> --alec


-- 
Soren Stoutner
so...@debian.org


[1] https://opencpn.org/OpenCPN/info/downloadopencpn.html


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

Re: Q: Ubuntu PPA induced version ordering mess.

[Soren Stoutner]

Alec,

On Monday, July 1, 2024 4:59:26 PM MST Alec Leamas wrote:
> 1. Persuade users to uninstall PPA packages before installing official
> packages and also generation 2 PPA packages with sane versions like 5.10.x

[...]

> Of these I would say that 1. is a **very** hard sell upstream. Users are
> used to just update and will try, fail and cause friction.

Although I generally agree with your conclusions, using a PPA is the type of 
end user task that involved them making modifications to the repositories on 
their systems.  I would assume that anyone who has done so, and who is already 
running Linux instead of Windows, is fully capable of handling a “downgrade” 
to an official package.  Asking users to remove the PPA they manually added and 
install an official package doesn’t really seem like that hard of an ask to me.

-- 
Soren Stoutner
so...@debian.org

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

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

Soren,

On 02/07/2024 01:41, Soren Stoutner wrote:

Alec,

On Monday, July 1, 2024 4:25:59 PM MST Alec Leamas wrote:

On 02/07/2024 01:19, Alec Leamas wrote:

Let's drop this subthread, keeping eyes on the ball: what is a sane
version?


Looking at this from another point of view: is there any situation where
an epoch is appropriate?

--alec


Epocs are usually used when upstream changes their versioning system in a way
that causes problem for our packaging.  For example, if they previous have
used dates for their release versions and switch to ordinals, Debian needs a
way of indicating that version 1.0 is newer than 2024.01.05.


So have I also understood it.

And this is more or less the situation. For all practical purposes the 
PPA is the current upstream packages, it's not some random packaging of 
opencpn. I have some control over both the PPA and the debian/ubuntu 
packages.


And what we want to do is to switch the upstream versioning in a way 
which means the "next" version is lower than current version. The end 
game is that the PPA is proper pre-releases of the official packages, 
built from the same sources and debian/ directories.


On other words, a rather good example on when an epoch makes sense.

--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

Soren et. al.,

On 02/07/2024 01:31, Soren Stoutner wrote:

Alec,


If upstream wants to fix this problem, they could just make their next release
version 9000, with the one after that either being 9001 or 9000.1.

Or, possibly, they could encourage everyone to uninstall the PPA package
before installing an official one.  For example, release a new package to their
PPA that displays a message encouraging everyone to uninstall the PPA package,
remove the PPA from their list of repositories, and *then* install the official
one.

As a general rule, I wouldn’t expect a user to keep a PPA package installed
when switching to an official package.  There is generally no guarantee that
upgrading from a PPA package to an official one will work without errors.

Or, once the official package had entered the system, they could instruct users
to remove the PPA from their list of repositories and then perform a
downgrade.

All of that being said, Debian could use an epoch to fix the problem.  Having
an epoch on a package isn’t the worst thing that has ever happened.


So, at least three possible paths:

1. Persuade users to uninstall PPA packages before installing official 
packages and also generation 2 PPA packages with sane versions like 5.10.x


2. Use versions like 9000.5.10, 9000.5.12. etc.

3. Use an epoch.

Of these I would say that 1. is a **very** hard sell upstream. Users are 
used to just update and will try, fail and cause friction.


2. and 3. both adds something which must be kept forever. Given this 
choice I tend to think that the epoch is the lesser evil, mostly because 
the package version could match the "real" version.


That is, the idea that next opencpn release officially would be 
9000.5.10 just won't fly. 2. would be about using package versions with 
a number prefix like 9000. which is not really visible to users.  And 
that means an impedance problem between the upstream version and the 
packaged one. A problem the epoch does not have.


--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Wookey]

On 2024-07-01 23:59 +0200, Alec Leamas wrote:

> But this is not about third parties, it's about upstream which publishes PPA
> packages. So far these are by far the most used Linux packages.
> 
> I also hesitate to add an epoch, after all they are basically considered
> evil. But if we should not use them when upstream has a broken versioning we
> are about to replace, when should we use it?

Quite. People are quite resistant to spoiling neat version numbers
with epochs, and no-one likes them, but they don't do any actual harm
(except sometimes break scripts and tools that forgot to allow for
them), and this seems seems like a very sensible use case: essentially
jus thwat they are intended for.. Yes it was upstream that messed up
not us/you, but we have the technology and you can make user's lives
easier by just adding an epoch.

It's a pity upsream didn't know about the 0~ trick so that it wouldn't
matter what crazy version string was used, but it's done now.

I guess the only potential argument against it (beyond 'we don't like
epochs') is 'how big is the userbase now and later'. i.e if this is
actually fairly new and there aren't really that many users with the
duff versions, but maybe in the future there will be 100 times more
getting their packages from us, ubuntu and upstream PPA, then that's a
reasonable argument to make them have to deal with it manually in
exchange for 'neat' epochless versions forevermore for all those
future users when everyone has forgotten about this cock-up.

Ultimately you are the maintainer so it's up to you. 

From what you have said, I think I'd epoch in this case, unless I
thought the current set of users could be considered 'de minimus' from
the point of view of say 5 years time.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Soren Stoutner]

Alec,

On Monday, July 1, 2024 4:25:59 PM MST Alec Leamas wrote:
> On 02/07/2024 01:19, Alec Leamas wrote:
> > Let's drop this subthread, keeping eyes on the ball: what is a sane
> > version?
> 
> Looking at this from another point of view: is there any situation where
> an epoch is appropriate?
> 
> --alec

Epocs are usually used when upstream changes their versioning system in a way 
that causes problem for our packaging.  For example, if they previous have 
used dates for their release versions and switch to ordinals, Debian needs a 
way of indicating that version 1.0 is newer than 2024.01.05.  This is to 
support upgrades of official Debian packages in Debian repositories from one 
version to the next.

Epocs are not typically used to fix problems in .debs published in some PPA 
that was never an official part of Debian.  This case is a little odd because 
the unofficial .debs were published in the PPA by upstream themselves (without 
thinking through how the .debs should be versioned).  As a general 
observation, upstream developers don’t tend to have a good grasp of how to 
create an idomatic .deb.  If they did, they would just release it to Debian 
themselves (I say that with my upstream hat on).

However, as I said in the other email, adding an epoch to a package isn’t the 
worst thing that has ever happened, and if there are a large number of users 
who have these PPA packages installed, then it might be in the best interests 
of the *users* to do so.  In my mind, the users always come first when making 
these types of decisions.

-- 
Soren Stoutner
so...@debian.org

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

Re: Q: Ubuntu PPA induced version ordering mess.

[Scott Kitterman]

On July 1, 2024 11:25:59 PM UTC, Alec Leamas  wrote:
>On 02/07/2024 01:19, Alec Leamas wrote:
>
>> Let's drop this subthread, keeping eyes on the ball: what is a sane version?
>
>Looking at this from another point of view: is there any situation where an 
>epoch is appropriate?

Yes.  I don't think this is it.

A sane version is one that's higher than the last one.  If upstream wants the 
last one to include their versioning from non-Debian packages, they can do 
that.  If they don't want to, that's fine, but I don't think we should either 
then.

Scott K

Re: Q: Ubuntu PPA induced version ordering mess.

[Soren Stoutner]

Alec,

On Monday, July 1, 2024 4:19:22 PM MST Alec Leamas wrote:
> Hi again
> 
> On 02/07/2024 01:13, Scott Kitterman wrote:
> > On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:
> >> On 02/07/2024 00:54, Scott Kitterman wrote:
> >>> On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
>  If you switch hats for a moment: have you any advice for upstream in
>  this situation?
> >>> 
> >>> 8763.5.10
> >> 
> >> Yes, I have had a similar idea using 1 instead of 8763 to make it
> >> stand out less. In my eyes, this is worse and will lead to that the
> >> package versions does not match the "public" version like 5.10.2.
> >> 
> >> But if the list agrees that this is the correct solution so be it. To be
> >> honest, it might be a hard sell upstream.
> >> 
> >>> Next build is:
> >>> 
> >>> 8763.5.10~8764
> >> 
> >> Why?
> >> 
> >> --alec
> > 
> > Because the '~' means less than.  It's a way to add the build number to 
the
> > interim versions in the future without causing the same problem again.  I
> > guess it should have been 8763.5.11~8764, if 5.11 is the next 'real'
> > version.
> 
> There is absolutely no need of build numbers in the version, it's just a
> sad legacy.
> 
> Let's drop this subthread, keeping eyes on the ball: what is a sane version?
> 
> --a

If upstream wants to fix this problem, they could just make their next release 
version 9000, with the one after that either being 9001 or 9000.1.

Or, possibly, they could encourage everyone to uninstall the PPA package 
before installing an official one.  For example, release a new package to their 
PPA that displays a message encouraging everyone to uninstall the PPA package, 
remove the PPA from their list of repositories, and *then* install the official 
one.

As a general rule, I wouldn’t expect a user to keep a PPA package installed 
when switching to an official package.  There is generally no guarantee that 
upgrading from a PPA package to an official one will work without errors.

Or, once the official package had entered the system, they could instruct users 
to remove the PPA from their list of repositories and then perform a 
downgrade.

All of that being said, Debian could use an epoch to fix the problem.  Having 
an epoch on a package isn’t the worst thing that has ever happened.

-- 
Soren Stoutner
so...@debian.org

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

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

On 02/07/2024 01:19, Alec Leamas wrote:

Let's drop this subthread, keeping eyes on the ball: what is a sane 
version?


Looking at this from another point of view: is there any situation where 
an epoch is appropriate?


--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

Hi again

On 02/07/2024 01:13, Scott Kitterman wrote:

On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:

On 02/07/2024 00:54, Scott Kitterman wrote:

On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:

If you switch hats for a moment: have you any advice for upstream in
this situation?


8763.5.10


Yes, I have had a similar idea using 1 instead of 8763 to make it
stand out less. In my eyes, this is worse and will lead to that the
package versions does not match the "public" version like 5.10.2.

But if the list agrees that this is the correct solution so be it. To be
honest, it might be a hard sell upstream.


Next build is:

8763.5.10~8764


Why?

--alec


Because the '~' means less than.  It's a way to add the build number to the
interim versions in the future without causing the same problem again.  I
guess it should have been 8763.5.11~8764, if 5.11 is the next 'real' version.


There is absolutely no need of build numbers in the version, it's just a 
sad legacy.


Let's drop this subthread, keeping eyes on the ball: what is a sane version?

--a

Re: Q: Ubuntu PPA induced version ordering mess.

[Scott Kitterman]

On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:
> On 02/07/2024 00:54, Scott Kitterman wrote:
> > On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
> >> If you switch hats for a moment: have you any advice for upstream in
> >> this situation?
> > 
> > 8763.5.10
> 
> Yes, I have had a similar idea using 1 instead of 8763 to make it
> stand out less. In my eyes, this is worse and will lead to that the
> package versions does not match the "public" version like 5.10.2.
> 
> But if the list agrees that this is the correct solution so be it. To be
> honest, it might be a hard sell upstream.
> 
> > Next build is:
> > 
> > 8763.5.10~8764
> 
> Why?
> 
> --alec

Because the '~' means less than.  It's a way to add the build number to the 
interim versions in the future without causing the same problem again.  I 
guess it should have been 8763.5.11~8764, if 5.11 is the next 'real' version.

Scott K

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

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

On 02/07/2024 00:54, Scott Kitterman wrote:

On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:




If you switch hats for a moment: have you any advice for upstream in
this situation?



8763.5.10


Yes, I have had a similar idea using 1 instead of 8763 to make it 
stand out less. In my eyes, this is worse and will lead to that the 
package versions does not match the "public" version like 5.10.2.


But if the list agrees that this is the correct solution so be it. To be 
honest, it might be a hard sell upstream.




Next build is:

8763.5.10~8764


Why?

--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Scott Kitterman]

On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
> On 02/07/2024 00:31, Scott Kitterman wrote:
> 
> HI again
> 
> > On July 1, 2024 10:18:07 PM UTC, Alec Leamas  
wrote:
> >> But here the situation is that upstream do care and wants to fix it. But
> >> they need our help (an epoch) to accomplish this to handle the legacy.
> >> 
> >> We could be helpful, or not. Why not give a hand?
> > 
> > No.  That's us fixing it.  They can bump the version to whatever they want
> > to address the issue.  Epochs are forever, so should be a last resort.
> Yes, epochs are forever and should not be taken lightly, agreed.
> 
> Expanding on the situation. The current opencpn version is 5.9.x, soon
> to be 5.10 in a tick-tock cycle.
> 
> However, the opencpn packages have versions like 8763.x, automatically
> generated from a build number. This is not communicated to users, they
> just install and update.
> 
> Obviously, upstream should start building packages with versions like
> 5.9.x..., 5.10.x... etc. But any such version is lower than the current
> build number.
> 
> If you switch hats for a moment: have you any advice for upstream in
> this situation?
> 
> --alec
8763.5.10

Next build is:

8763.5.10~8764

Scott K


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

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

On 02/07/2024 00:31, Scott Kitterman wrote:

HI again


On July 1, 2024 10:18:07 PM UTC, Alec Leamas  wrote:



But here the situation is that upstream do care and wants to fix it. But they 
need our help (an epoch) to accomplish this to handle the legacy.

We could be helpful, or not. Why not give a hand?



No.  That's us fixing it.  They can bump the version to whatever they want to 
address the issue.  Epochs are forever, so should be a last resort.



Yes, epochs are forever and should not be taken lightly, agreed.

Expanding on the situation. The current opencpn version is 5.9.x, soon 
to be 5.10 in a tick-tock cycle.


However, the opencpn packages have versions like 8763.x, automatically 
generated from a build number. This is not communicated to users, they 
just install and update.


Obviously, upstream should start building packages with versions like 
5.9.x..., 5.10.x... etc. But any such version is lower than the current 
build number.


If you switch hats for a moment: have you any advice for upstream in 
this situation?


--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Scott Kitterman]

On July 1, 2024 10:18:07 PM UTC, Alec Leamas  wrote:
>On 02/07/2024 00:10, Scott Kitterman wrote:
>
>Hi Scott,
>
>> Upstream can change the versioning however they want.  They are upstream.  If
>> they don't care to fix it, then I think we assume they are fine with it and
>> leave it as is.
>
>
>But here the situation is that upstream do care and wants to fix it. But they 
>need our help (an epoch) to accomplish this to handle the legacy.
>
>We could be helpful, or not. Why not give a hand?
>

No.  That's us fixing it.  They can bump the version to whatever they want to 
address the issue.  Epochs are forever, so should be a last resort.

Scott K

Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

On 02/07/2024 00:10, Scott Kitterman wrote:

Hi Scott,


Upstream can change the versioning however they want.  They are upstream.  If
they don't care to fix it, then I think we assume they are fine with it and
leave it as is.



But here the situation is that upstream do care and wants to fix it. But 
they need our help (an epoch) to accomplish this to handle the legacy.


We could be helpful, or not. Why not give a hand?

--a

Re: Q: Ubuntu PPA induced version ordering mess.

[Scott Kitterman]

On Monday, July 1, 2024 5:59:00 PM EDT Alec Leamas wrote:
> On 01/07/2024 21:51, Andrey Rakhmatullin wrote:
> 
> Hi Andrey.
> 
> Thanks for input.
> 
> > On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote:
> >> After some thought, I tend to think that adding an epoch is the right
> >> thing
> >> here.
> >> 
> >> The Policy [1] says:
> >> ---
> >> Epochs can help when the upstream version numbering scheme changes, but
> >> they must be used with care. You should not change the epoch, even in
> >> experimental, without getting consensus on debian-devel first.
> >> ---
> >> 
> >> With all this said: Is this a case where using a epoch is justified? If
> >> not, why?
> > 
> > Adding epochs to work around 3rd-party repo version problems sounds quite
> > wrong. We don't even add epochs that Ubuntu itself adds.
> 
> But this is not about third parties, it's about upstream which publishes
> PPA packages. So far these are by far the most used Linux packages.
> 
> I also hesitate to add an epoch, after all they are basically considered
> evil. But if we should not use them when upstream has a broken
> versioning we are about to replace, when should we use it?
> 
> I have good relations with upstream, and they are willing to abandon the
> current broken versioning in favor of something sane. But the legacy is
> there, and we need to handle it.
> 
> Have considered tricks like adding a 1. prefix to the debian/ubuntu
> versions. But to me, this looks even worse.
> 
> Thoughts?

Upstream can change the versioning however they want.  They are upstream.  If 
they don't care to fix it, then I think we assume they are fine with it and 
leave it as is.

Scott K

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

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

On 01/07/2024 21:51, Andrey Rakhmatullin wrote:

Hi Andrey.

Thanks for input.


On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote:



After some thought, I tend to think that adding an epoch is the right thing
here.

The Policy [1] says:
---
Epochs can help when the upstream version numbering scheme changes, but they
must be used with care. You should not change the epoch, even in
experimental, without getting consensus on debian-devel first.
---

With all this said: Is this a case where using a epoch is justified? If not,
why?


Adding epochs to work around 3rd-party repo version problems sounds quite wrong.
We don't even add epochs that Ubuntu itself adds.



But this is not about third parties, it's about upstream which publishes 
PPA packages. So far these are by far the most used Linux packages.


I also hesitate to add an epoch, after all they are basically considered 
evil. But if we should not use them when upstream has a broken 
versioning we are about to replace, when should we use it?


I have good relations with upstream, and they are willing to abandon the 
current broken versioning in favor of something sane. But the legacy is 
there, and we need to handle it.


Have considered tricks like adding a 1. prefix to the debian/ubuntu 
versions. But to me, this looks even worse.


Thoughts?

--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote:
> On 01/07/2024 20:48, Alec Leamas wrote:
> > Dear list,
> > 
> > Still working with the opencpn package. Now trying to normalize the
> > Ubuntu PPA builds so they can are based on the same debian/ directory
> > and tools as the existing Debian opencpn package.
> > 
> > opencpn is currently in a beta phase targeting a 5.10.1 release. The
> > beta versions are like "5.9.2-beta2+dfsg-1ubuntu1~bpo2204.1". The
> > upstream policy is to use 5.9.2-beta2, 5.9.3-beta3 so this ordering is,
> > although a bit strange, still ok.
> > 
> > However, a quite large user base have PPA packages installed. These have
> > versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build
> > number, so they are ordered. but all these versions are higher than
> > anything like 5.9.x.
> > 
> 
> After some thought, I tend to think that adding an epoch is the right thing
> here.
> 
> The Policy [1] says:
> ---
> Epochs can help when the upstream version numbering scheme changes, but they
> must be used with care. You should not change the epoch, even in
> experimental, without getting consensus on debian-devel first.
> ---
> 
> With all this said: Is this a case where using a epoch is justified? If not,
> why?

Adding epochs to work around 3rd-party repo version problems sounds quite wrong.
We don't even add epochs that Ubuntu itself adds.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

On 01/07/2024 20:48, Alec Leamas wrote:

Dear list,

Still working with the opencpn package. Now trying to normalize the 
Ubuntu PPA builds so they can are based on the same debian/ directory 
and tools as the existing Debian opencpn package.


opencpn is currently in a beta phase targeting a 5.10.1 release. The 
beta versions are like "5.9.2-beta2+dfsg-1ubuntu1~bpo2204.1". The 
upstream policy is to use 5.9.2-beta2, 5.9.3-beta3 so this ordering is, 
although a bit strange, still ok.


However, a quite large user base have PPA packages installed. These have 
versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build 
number, so they are ordered. but all these versions are higher than 
anything like 5.9.x.




After some thought, I tend to think that adding an epoch is the right 
thing here.


The Policy [1] says:
---
Epochs can help when the upstream version numbering scheme changes, but 
they must be used with care. You should not change the epoch, even in 
experimental, without getting consensus on debian-devel first.

---

With all this said: Is this a case where using a epoch is justified? If 
not, why?


--alec

Re: Reviving schroot as used by sbuild

[Reinhard Tartler]

On Mon, Jul 1, 2024 at 11:59 AM Simon McVittie  wrote:

> On Mon, 01 Jul 2024 at 09:18:19 +0200, Philipp Kern wrote:
> One use-case that I'm familiar with is bwrap (bubblewrap, as used by
> flatpak) nested inside podman. bwrap is a relatively limited container
> technology with relatively "light" requirements, at the cost of imposing
> harsh restrictions on the code inside the container: you only get access
> to one uid, and all other uids get mapped to the overflow uid ("nobody).
> You can think of as having two possible identities, "me" and "not me".
> Even with that limitation, bwrap inside podman doesn't normally work,
> because podman forbids most nested container operations. I'm unsure
> whether this is a functional requirement to prevent attacks where the
> podman container "payload" escapes from the container and gets arbitrary
> code execution on the host, or whether this is merely non-essential
> security hardening to make it harder to exploit possible vulnerabilities
> that podman aims to already prevent in some other way. Either way,
> I would expect that buildd operators would not want to allow it.
>
> podman nested inside podman is "more difficult" than bwrap nested inside
> podman (because it's more capable and imposes fewer restrictions on the
> payload, therefore needs a larger-than-default block of uids to be made
> available, whereas bwrap only needs one uid), and almost certainly also
> won't work.
>

you might find https://www.redhat.com/sysadmin/podman-inside-container
an interesting and useful read on this topic.

tl;dr: it depends. When discussing nesting containers with
podman, specifically podman-in-podman, there are four cases to consider:

- Rootful Podman in rootful Podman
- Rootless Podman in rootful Podman
- Rootful Podman in rootless Podman
- Rootless Podman in rootless Podman

Those cases naturally translate when considering other technologies such as
bubblewrap or unshare.

best,
Reinhard

Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

Dear list,

Still working with the opencpn package. Now trying to normalize the 
Ubuntu PPA builds so they can are based on the same debian/ directory 
and tools as the existing Debian opencpn package.


opencpn is currently in a beta phase targeting a 5.10.1 release. The 
beta versions are like "5.9.2-beta2+dfsg-1ubuntu1~bpo2204.1". The 
upstream policy is to use 5.9.2-beta2, 5.9.3-beta3 so this ordering is, 
although a bit strange, still ok.


However, a quite large user base have PPA packages installed. These have 
versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build 
number, so they are ordered. but all these versions are higher than 
anything like 5.9.x.


I understand that one way to handle this is to just say that sloppy PPA 
version numbers is not a Debian problem. That said, are there other 
ideas out there how to handle this?


Cheers!

--alec

Re: Reviving schroot as used by sbuild

[Simon McVittie]

On Mon, 01 Jul 2024 at 09:18:19 +0200, Philipp Kern wrote:
> Specifically I'm concerned about what [advocating use of podman]
> means for tests and if they
> should be able to use unprivileged containers themselves to test things.

tl;dr: There's no regression here, because you already can't run those
tests on a buildd.

There's no unified definition of "container" in the Linux kernel, only
a selection of different mechanisms that are used by container managers
to do what they want to do according to their individual security models
and desired functionality, so the only fully general answer we can give
to this is: there are containers, and there are containers, so you'll
need to be more specific about which specific things you want.

One use-case that I'm familiar with is bwrap (bubblewrap, as used by
flatpak) nested inside podman. bwrap is a relatively limited container
technology with relatively "light" requirements, at the cost of imposing
harsh restrictions on the code inside the container: you only get access
to one uid, and all other uids get mapped to the overflow uid ("nobody).
You can think of as having two possible identities, "me" and "not me".
Even with that limitation, bwrap inside podman doesn't normally work,
because podman forbids most nested container operations. I'm unsure
whether this is a functional requirement to prevent attacks where the
podman container "payload" escapes from the container and gets arbitrary
code execution on the host, or whether this is merely non-essential
security hardening to make it harder to exploit possible vulnerabilities
that podman aims to already prevent in some other way. Either way,
I would expect that buildd operators would not want to allow it.

podman nested inside podman is "more difficult" than bwrap nested inside
podman (because it's more capable and imposes fewer restrictions on the
payload, therefore needs a larger-than-default block of uids to be made
available, whereas bwrap only needs one uid), and almost certainly also
won't work.

But neither of these is a regression, because we can't normally do either
of those things inside schroot anyway! So packages like bubblewrap and
flatpak have no choice but to skip most of their regression tests at
build-time. This is obviously not ideal, but it's better than not being
able to ship these packages in Debian at all.

On ci.debian.net, the bubblewrap and flatpak test suites are re-run as
"as-installed" tests, and those *can* be run, using autopkgtest's qemu
backend - although I believe that's currently disabled because of some
technical issues with the qemu backend or the infrastructure, so those
tests might end up being skipped (again) on the lxc backend.

I believe bwrap nested inside `podman --privileged` *does* work. As I
said above, I don't know where that falls on the scale between "believed
to be secure, but less well-hardened" and "definitely not secure".

> Relatedly it'd be great if we actually had a VM in-between us and the build.

Prior art for this includes `sbuild --chroot-mode=autopkgtest
--autopkgtest-virt-server=qemu` (which uses qemu instead of schroot
or podman as the "container" for the actual build), openSUSE's
Open Build Service (which uses a new VM for each build in at
least some configurations), and my own experimental build wrapper
 (which runs the whole sbuild
instance inside the VM, in an attempt to be bug-for-bug compatible with
Debian's production infrastructure as mentioned earlier in this thread).

smcv

Bug#1074581: ITP: libtie-aliashash-perl -- module to provide hash with aliases key (multiple keys, one value)

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtie-aliashash-perl
  Version : 1.02
  Upstream Contact: Aldo Calpini 
* URL : https://metacpan.org/release/Tie-AliasHash
* License : Artistic
  Programming Lang: Perl
  Description : module to provide hash with aliases key (multiple keys, one 
value)

 Tie::AliasHash creates hashes that can have multiple keys for a single value.
 This means that some keys are just 'aliases' for other keys.
 
 Two aliases keys share the same value, so that fetching either of them will
 always return the same value, and storing a value in one of them will change
 both.
 
 The only difference between the two keys is that aliased key is not reported
 by keys() and each().

-- 
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Re: WolfSSL and Netatalk

[Jonas Smedegaard]

Quoting Daniel Markstedt (2024-07-01 12:04:03)
> On the licensing situation, so my understanding now is that *some*
> permissive licenses can coexist with GPLv2 licensed code, such as
> BSD-*, MIT, LGPL* etc.
> However, SSLeay explicitly forbids redistribution under GPL, while GPL
> explicitly says the entire software package has be distributed under
> the GPL.
> Does this sound about right?

Almost: It is GPL that forbids anti-freedoms in the SSLeay license.

Free software licensing is all about freeing software from the slavery
the monopoly-minded laws called "copyright".  GPL contains wording to
ensure that its promised freedoms are not hampered e.g. by additional
licensing terms introducing through linked code: GPL will terminate,
if combined with lesser free terms.
Some perceive GPL as being a "viral" license due to this mechanism: GPL
cannot be "watered down"; The combinatorial result of mixing licensing
terms must be at least as free as GPL.

Confusingly, OpenSSL v3 do not use the OpenSSL license, so reusing
SSLeay-licensed code is legally different from linking with OpenSSL:
https://www.gnu.org/licenses/license-list.en.html#OpenSSL

> FWIW, I naively thought it was sufficient to retain the original licensing 
> blurb for each source file, and independently adhere to the licensing terms 
> for each.
> But I see now how one license can impose its terms on other source files in 
> the same distribution...
> 
> Anyhow, let's work towards a broader solution in the upstream issue ticket 
> that you raised.

Yes, let's discuss those details upstream :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Re: WolfSSL and Netatalk

[Daniel Markstedt]

On Monday, July 1st, 2024 at 5:38 PM, Jonas Smedegaard  wrote:

> 
> 
> Quoting Daniel Markstedt (2024-06-23 07:58:54)
> 
> > On Sunday, June 23rd, 2024 at 6:35 AM, Bernd Zeimetz be...@bzed.de
> > wrote:
> > 
> > > > A few days ago, we released Netatalk 3.2.0 which comes bundled
> > > > with a customized subset of WolfSSL as SSL provider.
> > > > However, when I spoke to a Debian developer last year about this
> > > > very topic, they told me that using WolfSSL for packaged software
> > > > in Debian required some kind of special exemption and approval.
> 
> 
> [...]
> 
> > > (I didn't check for licence compabilites and such things, guess
> > > you've done that already).
> > 
> > All of the original WolfSSL codebase is GPLv2 licensed, which is the
> > same license that Netatalk uses.
> > However, a handful of source files (five of them to exact) are
> > licensed under the traditional SSLeay license.
> > They constitute key parts of the OpenSSL compatibility layer...
> 
> 
> Problem is licensing, not of WolfSSL but of the "handful of source
> files" recently added to Netatalk:
> 
> I looked at one of those files you recently introduced,
> include/atalk/cast.h, and it contains the following note just below (or
> arguably part of) the SSLeay license text:
> 
> > The licence and distribution terms for any publically available
> > version or derivative of this code cannot be changed. i.e. this code
> > cannot simply be copied and put under another distribution licence
> > [including the GNU Public Licence.]
> 
> 
> Since Netatalk is licensed under GPL-2+, it is perfectly legal¹ for the
> Netatalk project to include the above file as part of its source, and
> for the Debian project to provide prebuilt shared libraries involving
> such source files as input as long as it does not link with code
> licensed under GPL licenses, but anyone (other than the Netatalk project
> itself, who is not bound by its own license²) violates the GPL-2+
> licensing terms if linking with that file, so effectively your project
> is not Free software when making use of those files, and Debian cannot
> distribute (in main) a build of Netatalk making use of that code.
> 
> I have reported this upstream to the Netatalk project as well:
> https://github.com/Netatalk/netatalk/issues/1185
> 
> - Jonas
> 
> 
> ¹ I am not a lawyer. Take my words here only as inspiration.
> 
> ² But beware: It is everyone holding copyright in the Netatalk project
> that needs to agree on distributing binaries under different terms, not
> only its current developers.
> 

Jonas,

First off: The good news is that we were able to successfully link with 
Debian's WolfSSL library the other day.
The next upstream release version of Netatalk will come with build system 
support out of the box.

On the licensing situation, so my understanding now is that *some* permissive 
licenses can coexist with GPLv2 licensed code, such as BSD-*, MIT, LGPL* etc.
However, SSLeay explicitly forbids redistribution under GPL, while GPL 
explicitly says the entire software package has be distributed under the GPL.
Does this sound about right?

FWIW, I naively thought it was sufficient to retain the original licensing 
blurb for each source file, and independently adhere to the licensing terms for 
each.
But I see now how one license can impose its terms on other source files in the 
same distribution...

Anyhow, let's work towards a broader solution in the upstream issue ticket that 
you raised.

Cheers,
Daniel

Bug#1074569: ITP: emacs-dape -- Debug Adapter Protocol for Emacs

[Xiyue Deng]

Package: wnpp
Severity: wishlist
Owner: Xiyue Deng 

* Package name: emacs-dape
  Version : 0.13.0
  Upstream Author : Daniel Pettersson 
* URL or Web page : https://github.com/svaante/dape
* License : GPL-3+
  Programming lang: Emacs Lisp
  Description : Debug Adapter Protocol for Emacs
 Dape is a debug adapter client for Emacs.  The debug adapter
 protocol, much like its more well-known counterpart, the language
 server protocol, aims to establish a common API for programming
 tools.  However, instead of functionalities such as code
 completions, it provides a standardized interface for debuggers.
 .
 To begin a debugging session, invoke the `dape' command.  In the
 minibuffer prompt, enter a debug adapter configuration name from
 `dape-configs'.
 .
 For complete functionality, make sure to enable `eldoc-mode' in your
 source buffers and `repeat-mode' for more pleasant key mappings.
 .
 Package looks is heavily inspired by gdb-mi.el

I intend to maintain this package in the Debian Emacsen Team.  I'll need
a sponsor for uploading.

Re: WolfSSL and Netatalk

[Jonas Smedegaard]

Quoting Daniel Markstedt (2024-06-23 07:58:54)
> On Sunday, June 23rd, 2024 at 6:35 AM, Bernd Zeimetz 
> wrote:
> > > A few days ago, we released Netatalk 3.2.0 which comes bundled
> > > with a customized subset of WolfSSL as SSL provider.
> > > However, when I spoke to a Debian developer last year about this
> > > very topic, they told me that using WolfSSL for packaged software
> > > in Debian required some kind of special exemption and approval.

[...]

> > (I didn't check for licence compabilites and such things, guess
> > you've done that already).
> > 
> 
> All of the original WolfSSL codebase is GPLv2 licensed, which is the
> same license that Netatalk uses.
> However, a handful of source files (five of them to exact) are
> licensed under the traditional SSLeay license.
> They constitute key parts of the OpenSSL compatibility layer...

Problem *is* licensing, not of WolfSSL but of the "handful of source
files" recently added to Netatalk:

I looked at one of those files you recently introduced,
include/atalk/cast.h, and it contains the following note just below (or
arguably part of) the SSLeay license text:

> The licence and distribution terms for any publically available
> version or derivative of this code cannot be changed.  i.e. this code
> cannot simply be copied and put under another distribution licence
> [including the GNU Public Licence.]

Since Netatalk is licensed under GPL-2+, it is perfectly legal¹ for the
Netatalk project to include the above file as part of its source, and
for the Debian project to provide prebuilt shared libraries involving
such source files as input as long as it does not link with code
licensed under GPL licenses, but anyone (other than the Netatalk project
itself, who is not bound by its own license²) violates the GPL-2+
licensing terms if linking with that file, so effectively your project
is not Free software when making use of those files, and Debian cannot
distribute (in main) a build of Netatalk making use of that code.

I have reported this upstream to the Netatalk project as well:
https://github.com/Netatalk/netatalk/issues/1185

 - Jonas


¹ I am not a lawyer. Take my words here only as inspiration.

² But beware: It is everyone holding copyright in the Netatalk project
that needs to agree on distributing binaries under different terms, not
only its current developers.

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Re: Reviving schroot as used by sbuild

[Philipp Kern]

Hi,

On 2024-06-29 22:21, Christian Kastner wrote:
At the moment, rootless Podman would seem like the obvious choice. As 
far
as I'm aware, it has the same user namespaces requirements as the 
unshare
backends in mmdebstrap, autopkgtest and schroot (user namespaces 
enabled,
setuid newuidmap, 65536 uids in /etc/subuid, 65536 gids in 
/etc/subgid).


As a datapoint, I use rootless podman containers extensively both for
autopkgtest and as an sbuild backend (though the latter is affected by
#1033352 for which I still need to implement a cleaner workaround).

I think the only problem I encountered was a corner case when passing 
in
a device into a container: at some point, autopkgtest runs su which 
uses

the setgroups() syscall, and group permissions get lost. The solution
was to setup up the proper gidmaps. I documented my findings here [1].

Though this latter issue shouldn't be a problem on buildds, where
devices aren't passed in.


How well does this setup nest? I had a lot of trouble trying to run the 
unshare backend within an unprivileged container as setup by 
systemd-nspawn - mostly with device nodes. In the end I had to give up 
and replaced the container with a full-blown VM. I understand that some 
of the things compose a little if the submaps are set up correctly, with 
less IDs allocated to the nested child. Is there a way to make this work 
properly, or would you always run into setup issues with device nodes at 
this point?


Specifically I'm concerned about what this means for tests and if they 
should be able to use unprivileged containers themselves to test things. 
I guess we made the decision that we just assume "root" for testing. But 
right now you could - presumably - also setup more things under that 
assumption that would not work in an unprivileged setup. Is that a 
problem?


Relatedly it'd be great if we actually had a VM in-between us and the 
build. But that only works well on some architectures, only composes 
well on even less (e.g. arm64 not having nested virtualization yet), and 
only provides a marginal benefit if you execute the build outside of the 
VM as well. But it'd shield us more from supply chain issues.


Kind regards
Philipp Kern