announcing backport script designed to reduce potential human errors

[Nicholas D Steeves]

Hi,

I'm not sure if a something like this is worth including in
devscripts, but I found that it wasn't fun to worry about all the
potential mistakes one could make when building formal backports, so
I've been using a script to prevent errors such as:

* building a backport on the wrong branch (lintian catches bad
changelog entries)
* building a backport in the wrong chroot/schroot/LXC or with the wrong
pbuilder tarball
* forgetting to generate the correct foo.changes file, or generating
one against the wrong version
* not realising that a backport will need to pass through NEW

https://salsa.debian.org/sten-guest/backport

With confirmation that it would be useful to other people I'll be
motivated to extend it beyond the basic minimum functionality that I
use. I understand having to edit a script to make it work is less
than optimal ;-)

Cheers,
Nicholas

[James McCoy]

Post by Nicholas D Steeves
I'm not sure if a something like this is worth including in
devscripts, but I found that it wasn't fun to worry about all the
potential mistakes one could make when building formal backports, so

There was a previous request for something like this in #660208. At
the time, I suggested trying to merge the functionality of the proposed
script with one that Russ Allbery used.

It's been a long time since I looked at either of them, so I forget much
of the details.

Cheers,

[Nicholas D Steeves]

Fixed debian-***@debian.org -> debian-***@lists.debian.org so that
people who reply won't have to do this to avoid bounced emails. Sorry
for the mistake!

Hi James,

Post by James McCoy

Post by Nicholas D Steeves
I'm not sure if a something like this is worth including in
devscripts, but I found that it wasn't fun to worry about all the
potential mistakes one could make when building formal backports, so

There was a previous request for something like this in #660208. At
the time, I suggested trying to merge the functionality of the proposed
script with one that Russ Allbery used.
It's been a long time since I looked at either of them, so I forget much
of the details.

Thank you for the feedback and for links to past efforts and
discussions! It would seem that a README is necessary, so I wrote a
very quick 1st draft quality one:

https://salsa.debian.org/sten-guest/backport/blob/master/README.md

tldr; my effort focuses on the stage of building a formal backport
correctly, rather than automating the work of
src_package_from_testing->backported_src_package.

In terms of "big project" ideas, I think it would be neat if there was
a tool that integrated the pkg_from_testing->no_change_bpo
transformation, my tool, and also "Rebuild all the Things" (Sean
Whitton told me about this tool).

https://github.com/Debian/ratt

That, however, would be a big project...but it would be cool to point
it at a leaf package and have the tool output the whole stack,
skipping the packages that are already fulfilled via stable!

If a team formed to work on this effort I would be interested to work
on the builder abstraction and correctness checks, so as long as this
doesn't require Perl ;-) Oh, and this hypothetical project would be
post buster release.

Warm regards,
Nicholas

[Paul Wise]

Post by Nicholas D Steeves
In terms of "big project" ideas, I think it would be neat if there was
a tool that integrated the pkg_from_testing->no_change_bpo
transformation, my tool, and also "Rebuild all the Things" (Sean
Whitton told me about this tool).
https://github.com/Debian/ratt
That, however, would be a big project...but it would be cool to point
it at a leaf package and have the tool output the whole stack,
skipping the packages that are already fulfilled via stable!

I think you are looking for this project, which had backports in scope IIRC:

https://debconf18.debconf.org/talks/49-autodeb-automatic-packages-for-everything/

[Alexander Wirt]

Post by Nicholas D Steeves
Hi,
I'm not sure if a something like this is worth including in
devscripts, but I found that it wasn't fun to worry about all the
potential mistakes one could make when building formal backports, so
* building a backport on the wrong branch (lintian catches bad
changelog entries)
* building a backport in the wrong chroot/schroot/LXC or with the wrong
pbuilder tarball

This would also get catched if people would properly test their backports.
What I don't want to see is that people use those scripts and "forget" to
test the backport afterwards. On ther other what I would like to are automatic
installation tests in a clean chroot/docker/$whatever.

just my 2 cent
Alex

[micah anderson]

Post by Nicholas D Steeves
I'm not sure if a something like this is worth including in
devscripts, but I found that it wasn't fun to worry about all the
potential mistakes one could make when building formal backports, so
* building a backport on the wrong branch (lintian catches bad
changelog entries)
* building a backport in the wrong chroot/schroot/LXC or with the wrong
pbuilder tarball
* forgetting to generate the correct foo.changes file, or generating
one against the wrong version
* not realising that a backport will need to pass through NEW

All of these are nice. You should look at Russ' script that does
something similar:
https://www.eyrie.org/~eagle/software/scripts/backport.html

It hasn't been updated since 2015, but it still works well. I still use
it.

It has similar functionality of your script, and it seems like there is
a little overlap. It would be good to merge the efforts!