Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

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


On July 2, 2024 12:26:49 AM UTC, Soren Stoutner  wrote:



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.


Agreed.

I have many hats here, one of them being the upstream one. There is a 
clear vision how this should work in the future; this vision does not 
include any further epoch bumps.


--alec

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

Hi Jens,

On 02/07/2024 06:38, Jens Reyer wrote:

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.


Thanks for interesting input, I do appreciate it even if I don't think 
it works in this case for two reasons.


The first is that upstream should accept to use a package version like 
9000.5.x. Even if it's for a limited time it's a very hard sell. Russ 
Allberry phrased this well earlier in this thread.


The second is that this is navigation software used in boats and ships 
which often are off line. In this context users tends to cling to their 
working installations. That is, it will take a long time before the 
existing 8764.x versions are gone, much longer than two years.


OTOH, I understand the idea and can see it being useful in other cases.

Cheers!
--alec

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

[Simon McVittie]

On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote:
> 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.
>
> dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when
> building packages

Allowing ASCII seems counterproductive: that puts us in the code path
where various tools and runtimes (especially Python) will refuse to
process or output anything outside the 0-127 range, which I believe is
exactly the problem that debhelper aims to solve by using C.UTF-8 for
some categories of package (in particular those that build with Meson).

To get what Alexandre suggested, we'd need to allow UTF-8 but not allow
ASCII (so for example fr_FR.UTF-8 or C.UTF-8 is fine, but in particular
the C locale is not).

Or perhaps this pseudocode?

if (charset != UTF-8) {
emit a warning
export LC_ALL=C.UTF-8
unset LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE (etc.)
}

smcv

Bug#1074623: ITP: python-milc -- Opinionated Batteries-Included Python 3 CLI Framework

[Agathe Porte]

Package: wnpp
Severity: wishlist
Owner: Agathe Porte 
X-Debbugs-Cc: debian-devel@lists.debian.org, gag...@debian.org

* Package name: python-milc
  Version : 1.8.0
  Upstream Contact: skullydazed 
* URL : https://github.com/clueboard/milc/
* License : Expat
  Programming Lang: Python
  Description : Opinionated Batteries-Included Python 3 CLI Framework


MILC is a framework for writing CLI applications in Python 3.7+. It gives you
all the features users expect from a modern CLI tool out of the box:
.
 * CLI Argument Parsing, with or without subcommands
 * Automatic tab-completion support through 
[argcomplete](https://github.com/kislyuk/argcomplete)
 * Configuration file which can be overridden by CLI options
 * ANSI color support- even on Windows- with 
[colorama](https://github.com/tartley/colorama)
 * Logging to stderr and/or a file, with ANSI colors
 * Easy method for printing to stdout with ANSI colors
 * Labeling log output with colored emoji to easily distinguish message types
 * Thread safety
 * More than 60 built-in 
[spinners](https://github.com/manrajgrover/py-spinners) with the ability to add 
your own

This package is a dependency for qmk. I plan to maintain this package
under the Debian Python Team.

Bug#1074624: ITP: qmk -- program to help users work with QMK Firmware

[Agathe Porte]

Package: wnpp
Severity: wishlist
Owner: Agathe Porte 
X-Debbugs-Cc: debian-devel@lists.debian.org, gag...@debian.org

* Package name: qmk
  Version : 1.1.5
  Upstream Contact: skullydazed 
* URL : https://github.com/qmk/qmk_cli
* License : Expat
  Programming Lang: Python
  Description : program to help users work with QMK Firmware


A program to help users work with [QMK Firmware](https://qmk.fm/).
.
# Features
.
 * Interact with your qmk_firmware tree from any location
 * Use `qmk clone` to pull down anyone's `qmk_firmware` fork
 * Setup your build environment with `qmk setup`
 * Use `qmk console` to get debugging information from your keyboard(s)
 * Check that your environment is correctly setup with `qmk doctor`
 * Integrates with qmk_firmware for additional functionality:
* `qmk compile`
* `qmk info`
* `qmk flash`
* `qmk lint`
* ...and many more!

I intent to maintain this package under the Debian Python Team.

Re: Q: Ubuntu PPA induced version ordering mess.

[Holger Levsen]

On Mon, Jul 01, 2024 at 05:17:09PM -0700, Russ Allbery wrote:
> I would use an epoch.

yes.
 
[...]
> 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.

yes.

> 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. 

a bunch?

$ grep ^Version: 
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources 
|awk ' { print $2 } ' |grep -c :
1142
$ grep -c ^Version: 
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
38200

ok, maybe 3% of all packages is a bunch. :)

> 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.

yes.

> 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.

yes.

Thank you Russ, for wording this so well, that I don't have to type much.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

In a world where you can be anything, be kind.


signature.asc
Description: PGP signature

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

[Guillem Jover]

Hi!

On Tue, 2024-07-02 at 09:52:05 +0100, Simon McVittie wrote:
> On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote:
> > 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.
> >
> > dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when
> > building packages
> 
> Allowing ASCII seems counterproductive: that puts us in the code path
> where various tools and runtimes (especially Python) will refuse to
> process or output anything outside the 0-127 range, which I believe is
> exactly the problem that debhelper aims to solve by using C.UTF-8 for
> some categories of package (in particular those that build with Meson).
> 
> To get what Alexandre suggested, we'd need to allow UTF-8 but not allow
> ASCII (so for example fr_FR.UTF-8 or C.UTF-8 is fine, but in particular
> the C locale is not).

Err, you are right. I think I implemented this from my recollection of
the thread, trying to enforce as little as possible, and to try to let
users set "translations" to pure ASCII if desired, but that then defeats
the point brought up in the original mail, and the locale setting in
debhelper. I'll amend the PoC commit to only allow UTF-8.

(Also as long as LC_CTYPE is UTF-8 I think it should not matter whether
LC_MESSAGES is non-UTF-8 as the output codeset should still be UTF-8.)

> Or perhaps this pseudocode?
> 
> if (charset != UTF-8) {
> emit a warning
> export LC_ALL=C.UTF-8
> unset LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE (etc.)
> }

As it stands, I don't think this would be good enough, because it would
introduce an implicit setting in dpkg-buildpackage while it is
currently not the only supported entry point, so packages could still
not rely on this being always set, and it still disables translated
messages.

While erroring out (even when dpkg-buildpackage is still not the only
supported entry point) would not give a full guarantee that a package
build is always done in a UTF-8 locale, it at least forces the caller
(be that a tool or a human) to change the running environment, while
not forcing untranslated messages. I guess this could be made a stronger
guarantee if debhelper switched from unconditionally setting the locale
to performing a similar check and erroring out too (instead of simply
removing the locale setting).


But from your pseudocode, now I realize the check I implemented is
probably too naive, as it should probably at least also check whether
LC_COLLATE is also UTF-8. So I'll try to think how to make it more
robust.

But, I guess I can at least unconditionally set LC_CTYPE=C.UTF-8 when
using --sanitive-env, right away though.

Thanks,
Guillem

Re: Q: Ubuntu PPA induced version ordering mess.

[Guillem Jover]

Hi!

On Tue, 2024-07-02 at 03:32:53 +0200, Guillem Jover wrote:
> On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote:
> > 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).

Ah, another one that I had forgotten (which I had in mind adding
explicitly to the FAQ), but I guess is a variant of the "them being
confusing" point.

Epochs make it way harder to understand the history of the archive.
When you are not familiar with a package and its history it might be
hard to tell what happened to it to require an epoch bump, where in
many cases this is not even documented in the changelog (and it gets
worse now with the trimmed changelogs), and you might need to dig
into that history (via BTS, or git, or mailing list threads) to know
for example whether a security issue affects old versions or not,
whether that package used to be a different source package, whether it
was due to an unnecessary epoch bump to revert a problematic version,
whether it was for a proper version-space reset, etc.


The fact that they are perceived as ugly, is a good thing, but it's
not the main reason they should be avoided, to me that's just a
materialization of their powerful and problematic nature. They indeed
have their place, but I still have the feeling people reach for epochs
too easily, because in general their addition _seems_ trivial (but not
its irreversible consequences).

Thanks,
Guillem

Bug#1074772: ITP: gecode-snapshot -- low-level modelling language for constraint problems

[Kari Pahula]

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

* Package name: gecode-snapshot
  Version : 6.2.0+gitMMDD
  Upstream Contact: Guido Tack , Mikael Zayenz Lagerkvist 

* URL : https://www.gecode.org/
* License : MIT/X (and others)
  Programming Lang: C++
  Description : low-level modelling language for constraint problems

 FlatZinc is a low-level modelling language for constraint
 problems. It is designed to be easily interfaceable to constraint
 solvers (like Gecode). For more information on FlatZinc, please refer
 to the MiniZinc pages of the G12 project .

Source package name would be gecode-snapshot and it'll likely have a
single binary package, gecode-flatzinc.

Gecode is already in Debian, this is get an updated version of
FlatZinc available for MiniZinc.  Gecode hasn't had a release since
2019 and I need to use it as a library as well.  Fuller description of
the situation can be found at
https://lists.debian.org/debian-devel/2024/06/msg00312.html

Hopefully gecode-snapshot can be removed in the future when Gecode's
had a release again.

Re: Q: Ubuntu PPA induced version ordering mess.

[Gunnar Wolf]

Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:
> 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.

You can also consider a third possible path: Pick a different package
name.

I am unfamiliar with opencpn to be able to suggest an alternative. But
given opencpn has never been part of Debian, you could just name your
package "opencpn-deb". Just to be sure users don't get surprised by
having two different versions of the same package, it can "Conflict:
opencpn". Then, you get a blank slate from which you can work your
versioning as you deem adequate.

It does, yes, introduce some confusion, but I think is the least evil
option. 

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

On 02/07/2024 20:46, Gunnar Wolf wrote:

Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:

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.


You can also consider a third possible path: Pick a different package
name.

I am unfamiliar with opencpn to be able to suggest an alternative. But
given opencpn has never been part of Debian, you could just name your
package "opencpn-deb". Just to be sure users don't get surprised by
having two different versions of the same package, it can "Conflict:
opencpn". Then, you get a blank slate from which you can work your
versioning as you deem adequate.

It does, yes, introduce some confusion, but I think is the least evil
option.


opencpn is part of Debian since many years. However, the major 
distribution is through an Ubuntu PPA, the official Debian package is 
not that visible and of course outdated in Ubuntu.


opencpn users are counted in at least thousands. We are trying to 
convince the developer community that it's a good idea to use a package 
created as an official Debian package  rather than an auto-generated 
cmake package distributed using the Ubuntu PPA.


If the condition for this is to change the package name, the idea to use 
the official package will fail;  the package name has some substantial 
mindshare. In other words, this would probably be a even harder sell to 
upstream than the 9000.5.10 ideas floated earlier in this thread.


Russ Allbery has phrased the overall considerations applicable also to 
this idea earlier in this thread [1].


Cheers!
--alec

[1] https://lists.debian.org/debian-devel/2024/07/msg00029.html

Re: Q: Ubuntu PPA induced version ordering mess.

[Milan Kupcevic]

On 7/1/24 14:48, Alec Leamas wrote:

[...]


Hi Alec,




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.




[...]


The upstream shall consider adopting 5 digit release version numbering 
without dots/periods. E.g. 50903 would mean version 5, major 09, minor 
03. Thus you would go with package version numbering 50903-1 or 
50903+dfsg0-1 as the case might be.


Milan

Re: Q: Ubuntu PPA induced version ordering mess.

[Alec Leamas]

Hi Milan,

On 02/07/2024 23:54, Milan Kupcevic wrote:

On 7/1/24 14:48, Alec Leamas wrote:

[...]


Hi Alec,




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.




[...]


The upstream shall consider adopting 5 digit release version numbering 
without dots/periods. E.g. 50903 would mean version 5, major 09, minor 
03. Thus you would go with package version numbering 50903-1 or 
50903+dfsg0-1 as the case might be.





The upstream "shall" not do anything, they are open for discussions but 
certainly not for dictates.


If you are able to sell this idea to upstream it would certainly work. I 
would not try it, it would generate a lot of friction to no use. And at 
least I would fail to convince upstream. The user community is used to a 
certain version scheme and if  using the Debian package requires such an 
odd version the Debian package will probably not be used.


The proposed version also does not even resemble the ubiquitous  semver 
specifications which actually are more or less followed now. Seems like 
a wrong move just to avoid the epoch.


Again, Russ Allbery's post [1] describes these kind of considerations. 
IMHO they apply also to this idea.


Cheers!
--alec

[1] https://lists.debian.org/debian-devel/2024/07/msg00029.html

Re: Q: Ubuntu PPA induced version ordering mess.

[Debian GNU|Linux]

On 7/3/24 00:28, Alec Leamas wrote:


The upstream shall consider adopting 5 digit release version numbering 

[...]


The upstream "shall" not do anything, they are open for discussions but 
certainly not for dictates.


thou shalt not ask if thou wisheth for no answers.

(please keep in mind that not all Debian contributors are native 
speakers so you probably should go easy on the subtle differences 
between the various subjunctive forms. so unless somebody uses "SHALL 
(as in RFC-2119)", I would assume that the "shall" is a mere suggestion).


If you are able to sell this idea to upstream it would certainly work. I 
would not try it, it would generate a lot of friction to no use. And at 


afaict, all suggestions end with that same argument: upstream would 
resist. which makes the discussion a bit moot.


anyhow here's my 2¢:
according to you¹, upstream have simply botched their package 
versioning, which i would consider *a bug*.

bugs cause pain.
if upstream acknowledges that it *is* a bug, they might be interested in 
fixing it (even if the fix causes more intermediate pain).

if they don't, I personally would go for a workaround like an epoch :-)

and some other idea (not very well through through, it's still early in 
the morning and the caffeine level is low):
depending on the ecosystem, you might get away with using an epoch only 
for the frontend application package.
e.g. if there is a meta (binary) package "opencpn" that 
depends/recommends/... on various opencpn libraries, plugins and what 
not you could bump the epoch for this package only and have some clever 
Breaks against the too-high versions, which should eventually force the 
users to downgrade/re-install the child packages.



gdfasmr
IOhannes


¹ i looked up 
 and 
did not see any problematic package versions (i probably did not look 
long enough).

so which (actual) package/version is this about?



OpenPGP_0xB65019C47F7A36F8.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature