Bug#1032050: ITP: cryptacular -- high level, general purpose Java cryptographic library

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-j...@lists.debian.org, 
j...@nahmias.net, cryptacu...@googlegroups.com
Control: -1 blocks 1031807

* Package name: cryptacular
  Version : 1.2.5
  Upstream Authors: Daniel Fisher , Marvin S. Addison 

* URL : https://www.cryptacular.org/
* License : Apache-2.0 OR LGPL-3.0
  Programming Lang: Java
  Description : high level, general purpose Java cryptographic library

 General-purpose Java cryptograhic library, which complements the Bouncy
 Castle libraries, that has the following design goals:
 .
  * Flexible JCE provider. Prefers the Bouncy Castle Java Provider, but
can fall back to other providers defined in the environment for
algorithms not implemented by BC.
  * Ease of use for common cryptographic operations. A one liner
highlights this well; the following prints the MD5 hash of a password
as a string of HEX characters:
System.out.println(new MD5().digest(passBytes, new HexConverter()));
  * Convenient and performant handling of cryptographic operations on
large data streams.
  * Support for base-64 and hexadecimal encoding of ciphertext input/output.
  * Support for I/O operations on cryptographic primitives including
generating and writing symmetric encryption keys, public/private key
pairs, and X.509 certificates. Both PEM and DER encoding is handled
conveniently.
  * Command line interface for each class of cryptographic operation
(digest, symmetric encryption, public-key encryption, message signing,
etc). A command line interface for keystore operations is also
included, which is notable as it supports features above and beyond
the the Java keytool utility.
 .
 It is important to note that no cryptographic algorithms are implemented;
 Bouncy Castle provides all cryptographic algorithms where required.

Non-free-firmware changes - initial cut released!

[Steve McIntyre]

Hey all!

Here's a status update on the non-free-firmware changes that we voted
for last year [1].

Cyril has done a huge amount of work [2], implementing the bulk of
what we need. We released d-i bookworm alpha 2 last weekend [3],
including those changes. Our own testing shows that things work well
on *our* test hardware, but we'd like some more assistance in testing!
If you would like to help and you have a machine that wants firmware,
please:

 1. Boot the installer and verify that it identifies the necessary
firmware correctly - go as far as configuring the network. If
there are still missing firmware blobs, d-i will complain. If you
stop before making any changes in the partitioner (partman), then
this should a safe thing to do on your existing machine and won't
make any permanent changes.

 2. (If you can) complete an installation and check that all the
hardware works as expected after normal bootup. We'd love people
to do this to verify the more awkward blobs: audio and GPU.

We're especially interested in wifi, NIC and GPU firmware here, as
they have been the things blocking people installing Debian in the
past.

Please file bugs against "installation-reports" with whatever you
find! Thanks in advance!

We're also planning more updates before the full bookworm release -
watch this space!

[1] https://www.debian.org/vote/2022/vote_003
[2] https://debamax.com/blog/2023/02/27/debian-versus-non-free-firmware/
[3] https://lists.debian.org/debian-devel-announce/2023/02/msg5.html

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Re: Reducing allowed Vcs for packaging?

[Simon McVittie]

On Mon, 27 Feb 2023 at 00:17:41 +0100, Diederik de Haas wrote:
> Russ Allbery  wrote:
> > dgit maintains a history of every package in Debian.
> 
> AFAIK the Debian Xen Team does use dgit (not surprising given dgit's 
> maintainer (and author?)) ... and that drives me insane.
> I'm very sure that is due to me not understanding the concepts/idea/etc, but 
> I 
> can't wrap my head around it and it feels *to me* like it constantly rewrites 
> the (git) history and then does a `git push -f` ... every time.

In most practical maintainer workflows, the Debian patch series
fundamentally *does* get rebased every time there is a new upstream
release (if not more often), so the various packaging workflows (including
at least gbp-pq and git-debrebase, possibly also git-dpm) are ways to
reconcile that with wanting the history to be fast-forwarding.

dgit is at least partially workflow-agnostic, but as a central design
principle it had to choose exactly one representation to be the canonical
one, and the one its authors chose was "patches-applied", meaning that
any Debian-specific changes to the upstream source code of a package are
already pre-applied in the version you get from dgit.

Many (perhaps most?) Debian packages in git use the "patches-unapplied"
layout compatible with quilt or `gbp pq`, in which the Debian-specific
changes in the public VCS only exist in debian/patches and are not
pre-applied to the upstream source code (similar to what we used to do
in cvs and svn); if using `gbp pq` (as I do), the patches do temporarily
get imported into git as a patch-queue branch, which gets rebased, but
that patch-queue branch isn't intended to be pushed anywhere. Examples
of this include everything maintained by the Perl, Python, GNOME and
systemd teams, and many others.

For packages that use the common patches-unapplied workflow, the
representation in dgit and the representation used by the package's
maintainer are not the same (dgit refers to this as "split brain mode").
Packages that I maintain, like dbus and flatpak, might be useful examples
for this. The representation you get from Salsa is the way I prefer to
work with the package, and the representation you get from `dgit clone`
is the way the dgit maintainers would prefer it to be represented. dgit
reconciles these two views of the world automatically for me when I
upload, so I don't need to do anything differently. See dgit-maint-gbp(7)
for more details from the dgit side. Using that workflow is a way I can
be nice to dgit users without changing how I interact with debian/patches
and without requiring my co-maintainers to do anything differently,
so I do that.

I suspect that the Xen packaging is using a different workflow that is
less focused on the "patches-unapplied" tree than mine is, perhaps based
on git-dpm or git-debrebase.

smcv

Re: Reducing allowed Vcs for packaging?

[Adrian Bunk]

On Sun, Feb 26, 2023 at 11:42:25PM +0100, Diederik de Haas wrote:
>...
> The reason that I'm such a proponent of that is that 3 weeks or 3 months from 
> now, there's a reasonable chance that you (the author/committer) does no 
> longer remember the details of that commit.
> In 3+ years that will be close to 0.
> AFAIK actual mind reading does not exist, so someone else surely wouldn't 
> know.
> 
> I've already encountered several cases where the commit was 10+ years old and 
> the commit msg what "Disable setting X" and looking at the diff, I can see 
> the 
> X was indeed disabled. But nothing more.
> But now I want to enable setting X. But I have no context to know why that 
> would be a bad idea, or actually a good idea *now*, or what will break as a 
> consequence of my enabling X. All I can do is enable X and keep an eye out 
> for 
> bug reports.
> 
> I think that's what you want to achieve with 'better' changelogs is something 
> similar. I think the git commits are a better place as it's easier to make 
> finer grained distinctions and it's more directly linked to the changes.
>...

Where applicable:
You can add comments in debian/rules.
You can write long descriptions in debian/patches/*.patch
That's even more directly linked to the changes.

You can also write 5 line changelog entries.

The "if" and "where" are likely far less related than you hope:

People tend to be either terse or verbose,
not terse in the package but verbose in git commits.

And when trying to improve verbosity, this shouldn't be only
in the git metadata outside the package.

> Cheers,
>   Diederik

cu
Adrian

Re: required targets attempting internet access (was: Bug#1031548)

[Simon McVittie]

On Sun, 26 Feb 2023 at 19:09:59 +0100, Daniel Leidert wrote:
> Am Sonntag, dem 26.02.2023 um 19:45 +0200 schrieb Adrian Bunk:
> > 
> [..]
> > Debian Policy §4.9 says that *attempting* to access the internet
> > is forbidden:
> > 
> >   For packages in the main archive, required targets must not attempt
> >   network access, except, via the loopback interface, to services on the 
> >   build host that have been started by the build.
> 
> And the "test" target is not listed as a required target there.

If the series of events is:

* dpkg-buildpackage invokes build-arch or binary-arch or their -indep
  equivalents, which are required targets;
* some dependency of those required targets invokes the test target;
* the test target tries to access the internet

then I'm sorry but as Adrian said, that's a required target attempting
network access. The network access isn't directly written into the recipe
for the required target, but it's indirectly caused by the required
target, so this is in-scope for the Policy rule quoted here.

If that wasn't the intended interpretation, then this Policy rule would
be fairly pointless: if Policy §4.9 doesn't allow doing something like

build-arch:
make
make test with_internet=yes  # not allowed

then it also shouldn't allow this:

build-arch: try-to-bypass-policy-4.9
@echo "this is not the Internet access you are looking for"

try-to-bypass-policy-4.9:
make
make test with_internet=yes  # also not allowed!

which it seems like your interpretation would allow?

If the test is gracefully skipped in the absence of internet access, then
I'm not sure I would necessarily agree with Adrian that it's a *RC* bug
(not every Policy violation is RC, only serious Policy violations), but
I think it's certainly a bug.

As Adrian said on the bug, a good way to handle packages whose test
suites require internet access is to disable the test suite (or just
the part of it requiring internet access, if you can) at build time
(instead of probing for ability to talk to the internet, always take the
"cannot talk to the internet" code path), and use an autopkgtest with
the needs-internet restriction to get that coverage back.

Having an environment variable like TESTS_NO_NETWORK that makes the test
suite take the "no internet" code path, and exporting that variable
in debian/rules, is one fairly straightforward way to achieve that. For
example, game-data-packager's tests/download_shareware.py skips itself
if DEB_BUILD_TIME_TESTS is set, and debian/rules exports that variable.

I personally think it would also be OK if the Ruby team defined a
way that maintainers could opt-in to running build-time tests that do
access the internet, if you find that useful, as long as it's not the
default code path; for example you could set it up so that that adding
x-ruby-tests-can-use-internet to DEB_BUILD_OPTIONS would have that
effect. (This is only my opinion and has not been through the Policy
process, and I don't know whether project consensus would agree with me,
but I hope it would.)

smcv

Re: Reducing allowed Vcs for packaging?

[Diederik de Haas]

[please CC me in replies as I'm not subscribed to d-devel]

Russ Allbery  wrote:
> Diederik de Haas  writes:
> > Question as I don't know: is that only the package change that gets
> > uploaded to the Debian archive, or is there also a place where the (git)
> > history of the changes leading up to a new upload gets stored?
> 
> dgit maintains a history of every package in Debian.  If you use dgit to
> make your upload, that will include the full Git history of the changes,
> regardless of where you store your Git repository.  If you don't, then it
> only has the uploads to work with, so each package upload is a new commit
> and the detailed breakdown of the work between those uploads is not
> available via dgit.
> 
> But it does provide at least upload-level granularity as a Git history for
> every package, even those maintained with no version control system at
> all, with the option for each package maintainer of opting into providing
> more.

I'm not new to git or Debian, but I have ~0 experience with packaging (and I 
want to change that with id3lib).
Therefor I don't have (much) experience with the packaging tools (in general).

But AFAIK the Debian Xen Team does use dgit (not surprising given dgit's 
maintainer (and author?)) ... and that drives me insane.
I'm very sure that is due to me not understanding the concepts/idea/etc, but I 
can't wrap my head around it and it feels *to me* like it constantly rewrites 
the (git) history and then does a `git push -f` ... every time.
I once referenced a patch by number (and a short description iirc) and on the 
next push, that patch had a different number, thus messing up my commit msg.

The most confusing thing for/to me is that it completely rearranges the commit 
sequence, so I can't follow the changes that happened over time.
Right now in https://salsa.debian.org/xen-team/debian-xen/-/commits/master 
HEAD~30 (and the 2 commits before that) are the most recent (and to me the 
most relevant), but HEAD~9 was made 8 YEARS ago.

I may learn dgit in time, but that'll probably be a (long) while.

But as I described in another reply to this thread, the upload-level 
granularity is mostly useless *to me* as it usually only (tersely) describes 
the *what*, but not the *why*.

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

Re: Reducing allowed Vcs for packaging?

[Diederik de Haas]

On Sunday, 26 February 2023 22:38:51 CET Adrian Bunk wrote:
> On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
> > On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
> >...
> >
> > > For anything in Debian, the package sources in Debian would not
> > > disappear when a repository (or salsa) disappears.
> > 
> > Question as I don't know: is that only the package change that gets
> > uploaded to the Debian archive, or is there also a place where the (git)
> > history of the changes leading up to a new upload gets stored?
> > 
> > To use an analogy: I'd like that not only the 'destination' is preserved,
> > but also the lead up to the destination.
> 
> What goes into the Debian archive is based on tarballs and quilt patches.
> Nothing is stored there except the files you upload.

Thanks, I thought/'feared' so.

> But what do you expect to get from the git history?
> 
> There is no requirement that any history in addition to what is in
> the Debian archive exists at all, or any guarantee that what is in
> some git tree somewhere is actually the same as what is in the
> Debian archive. And git history might just be one commit per upload.
> 
> I would rather like to see people write useful changelog entries
> that will still be useful in 25 years instead of
>   * New upstream version (Closes: #1234567, #1234568, #1234569, ...
> or
>   * Add R³
> than hoping that git metadata would contain anything more useful
> than that for such packages.

What you described and what I mostly see on changelog entries is:
What was changed.

What I rarely see is *why*

I'm a big proponent of the following git commit structure, which then 
automatically becomes the git history:
primary commit msg: what has changed
secondary commit msg: why that change was made including context, 
deliberations made during that change/commit and alternative solutions 
considered and why the committer didn't choose for those.

The secondary commit msg can be LONG and I like that as it also shows the 
author/committer pays attention to such things.
The (upstream) kernel commit history is a treasure trove of excellent commit 
messages.

The reason that I'm such a proponent of that is that 3 weeks or 3 months from 
now, there's a reasonable chance that you (the author/committer) does no 
longer remember the details of that commit.
In 3+ years that will be close to 0.
AFAIK actual mind reading does not exist, so someone else surely wouldn't 
know.

I've already encountered several cases where the commit was 10+ years old and 
the commit msg what "Disable setting X" and looking at the diff, I can see the 
X was indeed disabled. But nothing more.
But now I want to enable setting X. But I have no context to know why that 
would be a bad idea, or actually a good idea *now*, or what will break as a 
consequence of my enabling X. All I can do is enable X and keep an eye out for 
bug reports.

I think that's what you want to achieve with 'better' changelogs is something 
similar. I think the git commits are a better place as it's easier to make 
finer grained distinctions and it's more directly linked to the changes.

FTR: I don't *expect* to see those extended commit messages in those old SVN 
repos, but I do hope I can at least derive _some_ information from the various 
commits itself.

When I was using my own SVN repo I started doing that and I know that I 
benefited from that a couple of months later. I should have a backup of that 
somewhere and I'm quite curious if I restore it (and convert it to git) if I 
can still construct enough detail/history/context from those commit msgs.
(As described in the debian-qa ML post, that repo should be 15+ y/o ?)

Cheers,
  Diederik

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

Re: Reducing allowed Vcs for packaging?

[Adrian Bunk]

On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
> On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
>...
> > For anything in Debian, the package sources in Debian would not
> > disappear when a repository (or salsa) disappears.
> 
> Question as I don't know: is that only the package change that gets uploaded 
> to the Debian archive, or is there also a place where the (git) history of 
> the 
> changes leading up to a new upload gets stored?
> 
> To use an analogy: I'd like that not only the 'destination' is preserved, but 
> also the lead up to the destination. 

What goes into the Debian archive is based on tarballs and quilt patches.
Nothing is stored there except the files you upload.

But what do you expect to get from the git history?

There is no requirement that any history in addition to what is in
the Debian archive exists at all, or any guarantee that what is in
some git tree somewhere is actually the same as what is in the
Debian archive. And git history might just be one commit per upload.

I would rather like to see people write useful changelog entries
that will still be useful in 25 years instead of
  * New upstream version (Closes: #1234567, #1234568, #1234569, ...
or
  * Add R³
than hoping that git metadata would contain anything more useful
than that for such packages.

cu
Adrian

Re: Reducing allowed Vcs for packaging?

[Russ Allbery]

Diederik de Haas  writes:

> Question as I don't know: is that only the package change that gets
> uploaded to the Debian archive, or is there also a place where the (git)
> history of the changes leading up to a new upload gets stored?

dgit maintains a history of every package in Debian.  If you use dgit to
make your upload, that will include the full Git history of the changes,
regardless of where you store your Git repository.  If you don't, then it
only has the uploads to work with, so each package upload is a new commit
and the detailed breakdown of the work between those uploads is not
available via dgit.

But it does provide at least upload-level granularity as a Git history for
every package, even those maintained with no version control system at
all, with the option for each package maintainer of opting into providing
more.

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

Re: Bug#1031548: FTBFS with ruby-jekyll-github-metadata 2.15.0

[Andrey Rakhmatullin]

On Sun, Feb 26, 2023 at 09:20:13PM +0100, Daniel Leidert wrote:
> > > > Debian Policy §4.9 says that *attempting* to access the internet
> > > > is forbidden:
> > > > 
> > > >   For packages in the main archive, required targets must not
> > > > attempt
> > > >   network access, except, via the loopback interface, to services
> > > > on the 
> > > >   build host that have been started by the build.
> > > 
> > > And the "test" target is not listed as a required target there.
> > > ...
> > 
> > 
> > It is called from a required target.
> 
> That might be your personal opinion.
??
Do you mean "test" being called from "binary-indep" or "binary-indep"
being a required target?

> The policy contains a wording that disproves your claim.
Which wording (also which claim)?

Re: Reducing allowed Vcs for packaging?

[Diederik de Haas]

On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
> On Sun, Feb 26, 2023 at 07:25:57PM +0100, Diederik de Haas wrote:
> > Apart from me not liking proprietary systems in general and M$ GitHub in
> > particular, you also run the risk of things disappearing entirely without
> > any notice and without any recourse.
> 
> Perhaps tomorrow some company like Oracle decides to buy GitLab Inc.,
> and then Oracle GitLab stops the current Freemium business model
> effective immediately.

That is a concern afaic, but the critical difference for me is that (all) the 
*data* is on Debian infrastructure.

> For anything in Debian, the package sources in Debian would not
> disappear when a repository (or salsa) disappears.

Question as I don't know: is that only the package change that gets uploaded 
to the Debian archive, or is there also a place where the (git) history of the 
changes leading up to a new upload gets stored?

To use an analogy: I'd like that not only the 'destination' is preserved, but 
also the lead up to the destination. 

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

Re: Bug#1031548: FTBFS with ruby-jekyll-github-metadata 2.15.0

[Daniel Leidert]

Am Sonntag, dem 26.02.2023 um 21:36 +0200 schrieb Adrian Bunk:
> On Sun, Feb 26, 2023 at 07:09:59PM +0100, Daniel Leidert wrote:
> > Am Sonntag, dem 26.02.2023 um 19:45 +0200 schrieb Adrian Bunk:
> > > 
> > [..]
> > > Debian Policy §4.9 says that *attempting* to access the internet
> > > is forbidden:
> > > 
> > >   For packages in the main archive, required targets must not
> > > attempt
> > >   network access, except, via the loopback interface, to services
> > > on the 
> > >   build host that have been started by the build.
> > 
> > And the "test" target is not listed as a required target there.
> > ...
> 
> 
> It is called from a required target.

That might be your personal opinion.

The policy contains a wording that disproves your claim. And instead of
waiting what the discussion would bring, you escalate further.
Considering my last encounters with you and your arrogant and demeaning
attitude: Go away.


Daniel

Bug#1032033: ITP: tfk8s -- Tool for converting Kubernetes YAML manifests to Terraform HCL

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: tfk8s
  Version : 0.1.10-1
  Upstream Author : John Houston
* URL : https://github.com/jrhouston/tfk8s
* License : Expat
  Programming Lang: Go
  Description : Tool for converting Kubernetes YAML manifests to Terraform 
HCL

 tfk8s is a tool that makes it easier to work with the Terraform
 Kubernetes Provider (https://github.com/hashicorp/terraform-provider-
 kubernetes).

Re: Bug#1031548: FTBFS with ruby-jekyll-github-metadata 2.15.0

[Adrian Bunk]

On Sun, Feb 26, 2023 at 07:09:59PM +0100, Daniel Leidert wrote:
> Am Sonntag, dem 26.02.2023 um 19:45 +0200 schrieb Adrian Bunk:
> > 
> [..]
> > Debian Policy §4.9 says that *attempting* to access the internet
> > is forbidden:
> > 
> >   For packages in the main archive, required targets must not attempt
> >   network access, except, via the loopback interface, to services on the 
> >   build host that have been started by the build.
> 
> And the "test" target is not listed as a required target there.
>...

It is called from a required target.

Do you have a list of the packages maintained by the Ruby team that
are RC-buggy due to this?

> Daniel

cu
Adrian

Bug#1032030: ITP: czkawka-gui -- Multi functional app to find duplicates, empty folders, similar images etc

[Fab Stz]

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

* Package name: czkawka-gui
  Version : 5.1.0
  Upstream Author : Rafał Mikrut 
* URL : https://github.com/qarmin/czkawka
* License : MIT
  Programming Lang: rust
  Description : Multi functional app to find duplicates, empty folders,
similar images etc

There is a GUI and a cli package:
- czkawka-gui
- czkawka-cli

Czkawka (tch-kav-ka, hiccup) is a simple, fast and free app to remove
unnecessary files from your computer.

Features:
- Written in memory safe Rust
- Amazingly fast - due to using more or less advanced algorithms and
  multithreading
- Free, Open Source without ads
- Multiplatform - works on Linux, Windows and macOS
- Cache support - second and further scans should be a lot faster than
  the first one
- CLI frontend - for easy automation
- GUI frontend - uses modern GTK 3 and looks similar to FSlint
- Rich search option - allows setting absolute included and excluded
  directories, set of allowed file extensions or excluded items with
  the * wildcard
- Multiple tools to use:
  - Duplicates - Finds duplicates basing on file name, size, hash,
first 1 MB of hash
  - Empty Folders - Finds empty folders with the help of an advanced
algorithm
  - Big Files - Finds the provided number of the biggest files in
given location
  - Empty Files - Looks for empty files across the drive
  - Temporary Files - Finds temporary files
  - Similar Images - Finds images which are not exactly the same
(different resolution, watermarks)
  - Zeroed Files - Finds files which are filled with zeros (usually
corrupted)
  - Same Music - Searches for music with same artist, album etc.
  - Invalid Symbolic Links - Shows symbolic links which points to
non-existent files/directories
  - Broken Files - Finds files with an invalid extension or that are
corrupted


This should close RFP: #1006181

fslint which did a similar job was removed from bullseye because it required
python2. This is a alternative/replacement.

Should be maintained by rust team.

Re: DEB_BUILD_OPTIONS=nowerror

[Helmut Grohne]

On Sun, Feb 26, 2023 at 07:15:45PM +0200, Adrian Bunk wrote:
> What you describe is an RC bug as soon as the more recent toolchain
> becomes default, and the correct solution is to not build with -Werror. 
>
> DEB_BUILD_OPTIONS=nowerror would imply that building with -Werror
> by default would be OK, but there are already too many FTBFS due
> to -Werror.


I would happily agree with all of this, but I do not see consensus on
either.

> DEB_BUILD_OPTIONS=werror as standard name for an opt-in option for CI 
> builds would be a better solution.

Why would I disagree? But that's not the problem I'm trying to solve.

> >...
> > Examples:
> > * glibc adds -Werror
> >...
> 
> glibc does not use the default gcc, which avoids most of the problems 
> you are worried about (but is not a general solution).

In a bootstrap build, glibc must be built with the toolchain that
provides libgcc-s1, so building glibc with a newer toolchain is
unavoidable. The selection of a specific toolchain is not a solution to
the -Werror problem and exactly why we are discussing it.

If glibc and nss were to drop -Werror (which was tried before), I
wouldn't be asking for an option.

The problem here specifically arises, because we do not have consensus
on -Werror being a bad idea in release builds.

However, maybe I can ask Aurelien whether we can opt out of -Werror
whenever a user specifies DEB_GCC_VERSION.

Helmut

Re: Reducing allowed Vcs for packaging?

[Adrian Bunk]

On Sun, Feb 26, 2023 at 07:25:57PM +0100, Diederik de Haas wrote:
>...
> Apart from me not liking proprietary systems in general and M$ GitHub in 
> particular, you also run the risk of things disappearing entirely without any 
> notice and without any recourse.

Perhaps tomorrow some company like Oracle decides to buy GitLab Inc.,
and then Oracle GitLab stops the current Freemium business model
effective immediately.

Would anyone be able to provide security support for the stale free 
version, or would salsa be shutdown with the next CVE?

> C.I.P. https://github.com/community/community/discussions/48173
> where VundleVim (vim plugin manager) disappeared 'out of the blue'.
> (that vundlevim isn't packaged for Debian is irrelevant)

For anything in Debian, the package sources in Debian would not 
disappear when a repository (or salsa) disappears.

cu
Adrian

Re: Bug#1031548: FTBFS with ruby-jekyll-github-metadata 2.15.0

[Daniel Leidert]

Am Sonntag, dem 26.02.2023 um 19:45 +0200 schrieb Adrian Bunk:
> 
[..]
> Debian Policy §4.9 says that *attempting* to access the internet
> is forbidden:
> 
>   For packages in the main archive, required targets must not attempt
>   network access, except, via the loopback interface, to services on the 
>   build host that have been started by the build.

And the "test" target is not listed as a required target there.

Also, please don't keep the bug report in the loop here. The report is
about a test showing a valid regression that would appear in
autopkgtest anyway ... independent of this topic.

Daniel

Re: Reducing allowed Vcs for packaging?

[Diederik de Haas]

On Sunday, 26 February 2023 17:59:52 CET Bill Allombert wrote:
> > During the last weeks I had a look at the Vcs situation in Debian.
> > 
> > For the allowed systems the situation in unstable is the following:
> > ...
> > svn is used by ~130 packages, many of which point to bad URLs.
> > 
> > We can see: The Vcs wars are over; with git there is a clear winner and in
> > my opinion, we should remove the possibility to use most of them for
> > package maintenance. It is one additional barrier to get into package
> > maintenance and we should remove the barriers that are not necessary.

I have something to say about this too, but I'll do it in a P.S. as that's not 
the main point I want to make ...

> People that use e.g. subversion could just remove the Vcs-svn field and
> pretend that they do not use any VCS. What does that gain us ?

I'm currently working on doing a mass-migration from (old) SVN repos to git.
See https://lists.debian.org/debian-qa/2023/01/msg00031.html for details.

As for this specific point: that obsolete/non-working (svn) URL are actually 
useful for me to figure out which need to be converted.

> I have sympathy for maintainers that use the same VCS as usptream. I have
> sympathy for upstream of a VCS to use that VCS instead of GIT.
> 
> ... Unfortunately some projects I work with did not convert their whole
> history to GIT and I find useful that Debian still provide subversion and
> mercurial to access older commits (and dead projects history).

One response to my debian-qa mail contained this:

> use "gbp import-dscs" to recreate some partial history based on
> snapshot.debian.org and I would not put any more effort than this.

That would probably be easier/faster, but I'm hoping to (indeed) preserve all 
(or at least as much as possible) of the original packaging commit history.

Diederik

PS: I would also like that all packaging data is available on Salsa
For some it's not available at all (but apparently permitted per Policy 
§5.6.26), which makes it hard(er then needed) if someone wants to contribute.
And in other cases it's contained in an external (proprietary) system like 
GitHub, which is not under Debian's control.
Apart from me not liking proprietary systems in general and M$ GitHub in 
particular, you also run the risk of things disappearing entirely without any 
notice and without any recourse.
C.I.P. https://github.com/community/community/discussions/48173
where VundleVim (vim plugin manager) disappeared 'out of the blue'.
(that vundlevim isn't packaged for Debian is irrelevant)

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

Re: Bug#1031548: FTBFS with ruby-jekyll-github-metadata 2.15.0

[Adrian Bunk]

On Sun, Feb 26, 2023 at 04:32:59PM +0100, Daniel Leidert wrote:
> Am Sonntag, dem 26.02.2023 um 16:57 +0200 schrieb Adrian Bunk:
> > On Sun, Feb 26, 2023 at 03:47:49PM +0100, Daniel Leidert wrote:
> > > Am Samstag, dem 25.02.2023 um 16:15 +0200 schrieb Adrian Bunk:
> > > 
> > > [..]
> > > > FYI:
> > > > 
> > > > The package in bookworm builds with jekyll-github-metadata
> > > > 2.15.0:
> > > > https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/ruby-jekyll-remote-theme.html
> > > > (the buildinfo link has the complete package list)
> > > 
> > > That is due to this environments not running the failing test. The
> > > test-file checks if there is an internet connection and adds or
> > > removes
> > > tests depending on the outcome). The test in question is one that
> > > requires an internet connection.
> > > ...
> > 
> > Accessing the internet during the build is an RC bug.
> 
> It would be pretty stupid to generally disable tests for a *remote
> theme* plugin (or any other package) that by defition relies on the
> internet. This would disable the majority of tests here. We (as in "the
> Ruby team") instead handle the tests if there is no internet, and
> whenever possible, run them via autopkgtest (needs-internet
> restriction) at least.
> 
> IMHO this is a valid approach and in this case spotted a regression. To
> my understanding, builds must not fail due to access attempts and the
> build itself must not rely on downloaded resources. However, this is
> the test stage, not the build stage. But if you feel that strongly
> about that, please show me the exact ruling.
>...

Debian Policy §4.9 says that *attempting* to access the internet
is forbidden:

  For packages in the main archive, required targets must not attempt 
  network access, except, via the loopback interface, to services on the 
  build host that have been started by the build.

Your additional approach via autopkgtest with the needs-internet 
restriction is a good way to test such packages.

I am adding debian-devel to Cc, where other people have more knowledge 
on that topic than I have.

> Daniel

cu
Adrian

Bug#1032026: ITP: heart -- Card game about avoiding having to take tricks

[Benedikt Straub]

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

* Package name    : heart
  Version : 0.1
  Upstream Contact: Benedikt Straub 
* URL : https://github.com/Noordfrees/Heart
* License : GPL-3
  Programming Lang: Java
  Description : Card game about avoiding having to take tricks

Heart (also known as Hearts) is a popular card game for four players
with the aim of gaining as few points as possible. The game is played
over several rounds until one or more players reach 100 points.
In my implementation a single human player plays against 3 computer players.

There used to be a similar game in the Debian and Ubuntu repos,
but it was removed long ago due (iirc) to being defunctional.
This is a reasonably well-known, small-ish game concept that is
a great way of wasting time, so having a Hearts-like game in
the repos again would be much appreciated.

I added a basic, functional debian packaging dir to my lightweight
Java-based Heart implementation (see GitHub link above).
I am also prepared to perform all maintenance that may be
needed for this package in the future.

I would be honored if my game were accepted into the official repos.

Best regards,
Benedikt Straub

Re: DEB_BUILD_OPTIONS=nowerror

[Adrian Bunk]

On Fri, Feb 24, 2023 at 07:19:41AM +0100, Helmut Grohne wrote:
>...
>  * A package adds -Werror to the build. When a new toolchain version is
>uploaded, it triggers a new warning and that makes the package FTBFS.
>...
> When building affected packages with more recent toolchains, such build
> failures are annoying. In a bootstrap setting, they hide later problems.
> For that reason, I would like to have a standard way to opt out of such
> failures. I understand that some of the warnings may be pointing at real
> bugs and that ignoring them certainly is a compromise. I also understand
> that packages may fail to build for other reasons with new toolchains
> (e.g. missing #includes). However, -Werror has proven to be quite
> repetitive and seems worthwhile to address to me.
> 
> As such, I propose a generic DEB_BUILD_OPTIONS=nowerror modelled after
> the original observation,
>...
> So let me know if you think this is a bad idea.

What you describe is an RC bug as soon as the more recent toolchain
becomes default, and the correct solution is to not build with -Werror. 

DEB_BUILD_OPTIONS=nowerror would imply that building with -Werror
by default would be OK, but there are already too many FTBFS due
to -Werror.

DEB_BUILD_OPTIONS=werror as standard name for an opt-in option for CI 
builds would be a better solution.

>...
> Examples:
> * glibc adds -Werror
>...

glibc does not use the default gcc, which avoids most of the problems 
you are worried about (but is not a general solution).

> Helmut

cu
Adrian

Re: Reducing allowed Vcs for packaging?

[Sean Whitton]

Hello,

On Sun 26 Feb 2023 at 02:24PM +01, Bastian Germann wrote:

> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of 
> them for
> one package. No package makes use of several Vcs references and frankly I do 
> not
> see why this was supported in the first place.
>
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
>
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.
>
> I would like to suggest removing the possibility to specify several systems 
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and 
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in 
> debian/control
> should be adapted to do the specified thing.
>
> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.

Why don't we just fix all those packacges, instead of changing any
documents?  Is there anyone who actually wants to introduce new packages
not using git?  I'm not so sure.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Reducing allowed Vcs for packaging?

[Bill Allombert]

On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote:
> Hi!
> 
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of 
> them for
> one package. No package makes use of several Vcs references and frankly I do 
> not
> see why this was supported in the first place.
> 
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
> 
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.

People that use e.g. subversion could just remove the Vcs-svn field and pretend
that they do not use any VCS. What does that gain us ?

I have sympathy for maintainers that use the same VCS as usptream. I have 
sympathy for 
upstream of a VCS to use that VCS instead of GIT.

... Unfortunately some projects I work with did not convert their whole history 
to GIT 
and I find useful that Debian still provide subversion and mercurial to access 
older
commits (and dead projects history).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Yearless copyrights: what do people think?

[Adrian Bunk]

On Wed, Feb 22, 2023 at 07:39:09AM -0700, Sam Hartman wrote:
> 
> As Jonas mentions, including the years allows people to know when works
> enter the public domain and the license becomes more liberal.
> I think our users are better served by knowing when the Debian packaging
> would enter the public domain.

If this is the intention, then including the years is pointless.

Article 7 of the Berne Convention says:
(1) The term of protection granted by this Convention shall be the life 
of the author and fifty years after his death.
...
(6) The countries of the Union may grant a term of protection in excess 
of those provided by the preceding paragraphs.
...

> --Sam

cu
Adrian

Re: Reducing allowed Vcs for packaging?

[Bastian Germann]

Am 26.02.23 um 17:26 schrieb Adrian Bunk:

I do not get your point what we would gain if the cvsd maintainer
drops the Vcs-Cvs reference while continuing to maintain the package
in cvs.


That would be a prerequisite to drop Vcs-Cvs support.
It is the last package that points to a working CVS URL.

Re: Reducing allowed Vcs for packaging?

[Adrian Bunk]

On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote:
> Hi!
> 
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of 
> them for
> one package. No package makes use of several Vcs references and frankly I do 
> not
> see why this was supported in the first place.

Policy §5.6.26 says it is not permitted.

> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
> 
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.

One barrier is that our work is based around tarballs and quilt,
instead of using upstream git trees and commits.

> I would like to suggest removing the possibility to specify several systems 
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and 
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in 
> debian/control
> should be adapted to do the specified thing.

Policy §5.6.26 would be the primary definition you want to change.

Not using any Vcs for maintaining packages in Debian stays permitted, 
and I do not get your point what we would gain if the cvsd maintainer 
drops the Vcs-Cvs reference while continuing to maintain the package
in cvs.

In practice e.g. tracker.d.o seems to support Vcs-Bzr but not Vcs-Cvs,
and there is no requirement for tools to drop working support for
something that is no longer specified.

Vcs-Browser is Vcs agnostic and would stay permitted for any kind of Vcs,
including ones never listed in Policy.

> Thanks for any comments,
> Bastian

cu
Adrian

Re: Reducing allowed Vcs for packaging?

[Andrey Rakhmatullin]

On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote:
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed
I see a difference between (dis)allowing a VCS in the Vcs-* fields and
(dis)allowing maintainers to store packages in a VCS.

> We can see: The Vcs wars are over; with git there is a clear winner
True.

> and in my opinion, we should remove the possibility to use most of them
> for package maintenance.
Which is not done by restricting Vcs-* values.

> It is one additional barrier to get into package maintenance
I don't think anything mentioned here is a barrier.
Even if you imagine someone looking at the list of allowed Vcs-* values to
choose which VCS to use without any context about any of these VCSes, we
have since recently "Almost all packages in Debian that use a version
control system use Git; if you create a new package, using Git is a good
idea simply because it's the system that contributors will be familiar
with." in devref 6.2.5.2.

> I would like to suggest removing the possibility to specify several systems 
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and 
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 
The main place for this is Policy 5.6.26, not devref (I don't know what
does devref mean when saying "currently the following systems are
supported by the package tracking system").

> and whatever parses Vcs-* in debian/control should be adapted to do the 
> specified thing.
Do you mean "by dropping support for ones that are no longer allowed"?
This is code cleanup in the best case and breaking support for looking at
the relevant field in old packages in the worst one.

> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
This can be done independently.

Re: Reducing allowed Vcs for packaging?

[Brian Thompson]

On Sun, 2023-02-26 at 14:24 +0100, Bastian Germann wrote:
> Hi!
> 
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of them
> for
> one package. No package makes use of several Vcs references and frankly I do
> not
> see why this was supported in the first place.
> 
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
> 
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.
> 
> I would like to suggest removing the possibility to specify several systems
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in
> debian/control
> should be adapted to do the specified thing.
> 
> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
> 
> Thanks for any comments,
> Bastian
> 

It does seem like the VCS wars are over--for now.  Who knows what type of
situation could force our hand to use a different VCS than Git?  That future is
hard to imagine but is certainly a possibility.  I think I'm understanding your
point that it would make the package maintainers lives' easier, and it does
sound like some of the packages using non-Git VCS are rotting, at least in that
regard.  However, I would be hesitant to remove support for the other VCS
systems.  

From my experience, whenever software engineers are actively limited for
seemingly no or little gain, they tend to turn their attention elsewhere.  Also,
ripping out logic to support 7 other VCS systems stifles creativity and puts us
down a one-way street.  Sure, you could argue that adding that logic back in
wouldn't be hard, but then why remove it in the first place?  Wouldn't it be
more prudent just to update the non-Git packages to use Git?   That's going to
have to be done anyway for a lot of them (or not).  

My point is, the gain doesn't seem to be larger than the possible (and not that
probable in the near future) cost.  Admittedly, it's difficult to gauge the
costs of these things.

-- 
Sincerely,

Brian T


publickey - brianrobt@pm.me - c8f2ec48.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Reducing allowed Vcs for packaging?

[Bastian Germann]

Hi!

During the last weeks I had a look at the Vcs situation in Debian. Currently,
there are eight possible systems allowed and one might specify several of them 
for
one package. No package makes use of several Vcs references and frankly I do not
see why this was supported in the first place.

For the allowed systems the situation in unstable is the following:
arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
bzr is used by ~50 packages, half of which point to bad URLs.
cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
svn is used by ~130 packages, many of which point to bad URLs.
darcs, mtn, and hg are not used.

We can see: The Vcs wars are over; with git there is a clear winner and in my
opinion, we should remove the possibility to use most of them for package
maintenance. It is one additional barrier to get into package maintenance and
we should remove the barriers that are not necessary.

I would like to suggest removing the possibility to specify several systems and
removing all systems except bzr, svn, and git, while deprecating bzr and 
possibly svn.
This means solving the four listed bugs and convincing the cvsd maintainer to
switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
should specify the changes in §6.2.5 and whatever parses Vcs-* in debian/control
should be adapted to do the specified thing.

Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
(see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.

Thanks for any comments,
Bastian

Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Colin Watson]

On Sat, Feb 25, 2023 at 11:13:29PM -0600, G. Branden Robinson wrote:
> I've sent you a couple of mails over the past few months, but I don't
> recall seeing a reply.

Sorry about that!  Feel free to grab me on IRC if I'm not replying to
email.

> I am not a proficient gbp user, but I think I have done what is
> necessary.

groff doesn't use gbp - it uses git-dpm.  If you try to use gbp for it
then you will probably get quite confused and so will I, so please
don't.

First, move your current branch somewhere for reference, then make a new
one.  Then, my routine for pulling in new upstreams looks roughly like
this:

  git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched 
../foo.orig.tar.gz
  # this imports the unpacked upstream tarball onto an upstream branch
  # based on $UPSTREAMTAG, then drops you into a rebase session

  ... continue with rebase as needed, then once you're finished ...

  git-dpm update-patches --amend
  # the --amend is just because the import-new-upstream step will
  # already have recorded the new upstream on the branch you started
  # from, but the history looks clearer if you bundle the rebase with
  # that in a single merge commit, which this does

Then you can cherry-pick your packaging changes on top of this, as well
as telling pristine-tar about the new upstream tarball based on the
appropriate imported branch.

If you push the results to a temporary branch on salsa then I can look
over them, which is probably a good idea since you're unfamiliar with
git-dpm.

> How do we move forward with this?  I am anxious about the closing of the
> soft freeze window.

There is no way that this giant new upstream release will be suitable at
this stage in the freeze; it's too late.  This should be targeted at
experimental.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Andrey Rakhmatullin]

On Sun, Feb 26, 2023 at 12:06:18AM -0600, G. Branden Robinson wrote:
> Background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011666
> 
> Can someone advise me as to the correct procedure for merging upstream
> release candidate archives into https://salsa.debian.org/debian/groff ?
Just import them? Do you have any specific questions or problems with
this?

> ...except that I don't think I did the upstream merge/tagging right.
You shouldn't do merging or taging manually, gbp import-orig does that for
you.

> I suspect this because if I do a "git rebase -i origin", git goes crazy
> and tells me I have merge conflicts. 
Why are you running this command and what do expect to get after running
it? And if it's in a pushed branch then you shouldn't ever do that.

> None of the release candidates were already staged even as reference
> points, so I had to wade into the gbp documentation myself, and I
> probably screwed it up.
Not sure what do you mean by this but importing upstream tarballs is a
very basic gbp action that's hard to screw assuming the repo was already n
a good shape. And it doesn't matter that tarballs are "release candidates"
unless that implies something else.

> [1] Here are my clumsy attempts to get those release candidate archives
> in.  (I expanded some git aliases that I have set up.)
> 
>   587  git branch upstream
But the repo already has the upstream branch.

>   592  git commit -v debian/watch
The upstream branch doesn't have a debian/watch file. Have you confused
master and upstream by running the previous command? Or are some commands
missing?

>   598  gbp import-orig --upstream-branch=upstream 
> https://alpha.gnu.org/gnu/groff/groff-1.23.0.rc1.tar.gz
>   599  gbp import-orig --upstream-branch=upstream 
> https://alpha.gnu.org/gnu/groff/groff-1.23.0.rc2.tar.gz
>   600  gbp import-orig --upstream-branch=upstream 
> https://alpha.gnu.org/gnu/groff/groff-1.23.0.rc3.tar.gz
(--upstream-branch=upstream should be the default)

>   643  git tag upstream/1.23.0_rc1 bc599bf23fcb428295d769c7944bdfd97d8a203d
>   644  git tag upstream/1.23.0_rc2 ff6560eb9b39d2c45a0f8a0c1cc12527edaf270d
>   645  git tag upstream/1.23.0_rc3 ff12aaae2c82beece4d9ff6bb90f019ab142ed06
>   647  git tag -d upstream/1.23.0.rc1
>   648  git tag -d upstream/1.23.0.rc2
>   649  git tag -d upstream/1.23.0.rc3
None of this should be needed if you tell import-orig that the versions
are 1.23.0~rcN instead of the default 1.23.0.rc1.

>   At that point I was able to get "gbp buildpackage" to run, and it was
>   just a matter of doing ordinary packaging work, as illustrated in the
>   commit messages above.
> 
>   Advice is appreciated!
Again, which advice? You said that it works for you.