Hi Chris, Thanks for your comprehensive reply :)
On Mon, Jul 15, 2024 at 12:00:56PM -0400, Chris Knadle wrote:
> That said, it's unusual as a package maintainer to be /told/ that a
> package I maintain is going to be NMUed with a new version that
> significantly changes the package, without any serious bug on the
> package. [...] The rules for Debian that I'm aware of would preclude
> doing this without the package maintainer's go-ahead.
From discussions with others I've had about this it seems these rules, if
they are consensus, they are not written-down and in fact contradict what
devref documents (see below). When in doubt I give more weight to
written-down rules over word-of-mouth.
My intent is to both improve neglected packages in Debian as well as
encourage the project as a whole to write-down-the-damn-rules in order to
make onboarding new contributors easier. Something we need to start taking
seriously if we want Debian to thrive.
> There's been no mention of the package's Salsa Git repository or how that
> would be reconciled.
I would expect you to import the NMU DSC into your git repository. Though
when git repo tooling I'm comfortable with is involved I may opt to send a
PR.
Anyway, devref section 5.11.1. explicitly says whishlist bugs are fair game
for NMUs as long as impact is minimized, hence #1043037 qualifies. Whether
the impact is justified is a judgment call I make during packaging or
review in this case.
devref> ("Bugs" means any kind of bugs, e.g. wishlist bugs for packaging a new
devref> upstream version, but care should be taken to minimize the impact to
devref> the maintainer.)
That being said, I'm happy to see you're still around and interested in
collaborating and in fact beat me to getting around to review Michael's
packaging. I much prefer collaborating to having to NMU ofc. More keyboards
can only improve a package's maintainance :)
> I've had a very brief look at Michael's package. I don't understand the new
> debian/changelog entries, it looks like Git commit numbers have been
> included, I've never seen that before in any Debian package and I'm
> wondering how that could be useful to any Debian end user.
Quoting from Michael's package:
```
mlmmj (1.4.4-1) unstable; urgency=medium
* [5d3061c] Import 1.3.0-4 release
* [c595ff9] d/watch: New upstream on codeberg
* [84ce6e8] New upstream version 1.4.4
* [2f397a5] Refresh patches for 1.4.4
* [6e8be23] Update d/copyright
* [b951379] d/control: Add test suite builddeps
* [6a87680] Convert translations from latin1 to utf-8
* [9d7e1c8] Add patch to fix the test suite
* [1d46c85] Add patch to fix encoding in class.rFastTemplate.php
* [a2c64db] Remove obsolete Debian NEWS files
* [c6ea132] Update packaging to debhelper 13
* [ebd67f6] Add Salsa-CI configuration
-- Michael Jeanson <mjean...@debian.org> Fri, 22 Mar 2024 15:31:10 -0400
```
I agree. I've never seen that before either. Michael, what tooling are you
using to make these and why?
> The debian/changelog entries are not just for developers, Debian end
> users use them to know what changes the package has gone through; I think
> I would prefer those Git commit comments not be there unless there's good
> justification.
ACK. Let's see what Michael says.
> I don't understand the debian/control file concerning new
> build dependencies I don't recognized and that have <!nocheck> entries.
> (What is that?)
`foo <!nocheck>` is a dependency on foo that's only effective if the "build
profile" in <> is active. See https://wiki.debian.org/BuildProfileSpec
In this case !nocheck means this dependency is only needed for the
testsute. The general idea of this is to make (re-)bootstrapping Debian
easier by getting rid of uneeded dendencies and hence many dependency
cycles needing manual intervention of bootstrap developers are simply
sidestepped.
The double negation is an unfortunate consequence of how build profiles
were developed. You'll be shocked to learn it ended up this way due to a
difference of opinion AFAIR ;)
No active build profiles means "we want to run the testsuite" and
DEB_BUILD_PROFILES=nocheck means "don't run tests".
> A new salsa-ci.yml file is included which is going to do
> -- something -- which hasn't been discussed.
Please see
https://salsa.debian.org/salsa-ci-team/pipeline#debian-pipeline-for-developers
This gets us builds on every git push before even uploading to
ftp-master. Making the feedback cycle shorter.
Looking at debian/salsa-ci.yml:
```
include:
- https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
- https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
variables:
RELEASE: 'bookworm'
```
This is taken from
https://salsa.debian.org/salsa-ci-team/pipeline#changing-the-debian-release
Michael, I guess you're targeting bookworm with your package. For the
unstable version we should replace this with the standard salsa-ci template
from
https://salsa.debian.org/salsa-ci-team/pipeline#basic-use and once we're in
unstable work on a seperate backport branch for bookworm.
> The debian/rules have been converted to automatic 'dh' rules, and there
> needs to be detailed review of what the end-effect of changing those
> rules are compared to the current package in Debian.
Easy. A debdiff should show you what we need to know. Let me know if you
want us to send one.
Chris, can you handle upgrade testing? Me an (I assume) Michael don't have
running deployments (yet). If not we should do a public call for testing of
an (eventual) unstable/experimental upload on d-devel and the mlmmj list
you mention below.
> Changing the debian/rules is specifically something not to change without
> consent from the package maintainer.
Right, that's a no-go for an NMU. But since you're here now :)
Chis, if I was reviewing you package on d-mentors today doing eveything by
hand would also be a complete no-go. As you can see Michael's version is
significantly shorter (understatement of the year) and it is my
understanding and opionion that using dh is strong consensus in Debian, see
https://anarc.at/blog/2019-02-05-debian-build-systems/
dh usage is only growing.
> Please do not upload this package as it is right now, I think the needs
> changes before it could be released.
Naturally. Do keep in mind that an upload to experimental doesn't need to
be ready for release :)
Michael, let me know if you want to work on Chris' feedback or if I should
take over.
> This is not a situation where Michael's
> Git repo could simply be imported into the Debian MLMMJ Git repository,
As far as NMUers in Debian are concerned your git repo doesn't really
exist. I've followed the recent tag2upload discussion carefully and it is
my opinion that in the general case there is no hope for git based
collaboration in Debian until it is widely used, but since there's
consensus on t2u now this may change soon^TM.
In any case since you seem to be using gbp importing a DSC is easy:
dget -d $URL_from_tracker
gbp import-dsc $dsc
done.
> because there's several past versions that were never released to Debian and
> so don't belong in the Salsa Git repo. I don't think I know enough Git magic
> (rebase?) to reconcile all that to make a clean Salsa Git history of Debian
> releases.
See above. There's no need for that, but I always love a good git challange
so hit me up on OFTC if you want to try that just to learn git better.
Assuming you haven't made changes since Michael's fork I'd just do a
one-off pull of Michael's branches and remove any inappropriate tags. No
need for rebase. If you've made changes since the fork things take a turn
for the next to impossible since gbp makes merge commits. I've tried that
recently and learned the hard way rebasing through merges is not a standard
thing to do. I still think it's possible (with enough brute force): for
each merge you have to do a ranged rebase and re-create the merge by hand
(yey).
IMO this is why gbp is terrible and should not be used. It breaks down as
soon as someone doesn't know it's not a collaboration mechanism outside of
a single central repository, which is a very common misconception
especially for contributors new to Debian.
NMUs are Debian's documented standard and universal collaboration
mechanism. They have terrible fidelity and UX ofc. but at least all tools
I'm aware of support them.
> And if you're not aware, the install instructions for MLMMJ for Exim4 also
> need updating after changes to Exim4 for disallowing using "tainted data"
> and I don't yet know if the new upstream fork has updated those
> instructions.
Doesn't look like upstream updated those instructions in 1.4.6 yet. Could
you report an issue for that on codeberg if you have the details in your
head still?
> That was discussed on the MLMMJ mailing list, which is still active. Let
> me know if you are on the mailing list for MLMMJ to see the discussion of
> these issues.
Could you link me to the ML and discussion? The website got reorganized
recently I can't seem to find it.
> I appreciate the work Micheal has done to create a new Debian package of
> MLMMJ, it's definitely going to be useful even if it can't be released
> directly. At minimum there should be away of 'cherry picking' Git commits
> to include in a new MLMMJ Debian release.
Chris, I've sent a request to join mlmmj-team on Salsa, could you add
Michael (@mjeanson) too?
> Daniel when you have time please let me know your thoughts about all this.
> Hopefully we can figure out a way to make this work, because I could
> certainly use help.
I'm sure we'll get it done and then some :D
Thanks,
--Daniel
signature.asc
Description: PGP signature
