[Pkg-sssd-devel] [tag2upload 3161] irrecoverable sssd 2.12.0-4

[Simon Josefsson]

Ian Jackson <ijackson at chiark.greenend.org.uk> writes:

> Hi.  I'm giving a rather long answer which I hope will be more useful
> to your co-maintainers on this package, who may be lacking much
> of the context.

Wonderful, thank you!  Quoting your entire message below because it
didn't make it to the pkg-sssd-devel yet due to moderation (sorry I'm
not a list admin so can't approve it).  Co-maintainers, any opinion on
way forward with 'sssd' here?

I will try 'git-debpush --quilt=gbp' next time.  I've developed a habit
to use --quilt=unapplied because that's the quilt style I prefer, and
'git-debpush' helps me to enforce that style by rejecting repositories
(before tagging and pushing) that doesn't conform.  Usually the culprit
has been to remove debian/.gitignore.  In this case git-debpush didn't
notice that --quilt=unapplied wouldn't work, so it pushed the tag and
the error happened on the server side.

/Simon

> Simon Josefsson writes ("Re: [tag2upload 3161] irrecoverable sssd 2.12.0-4"):
>> However the upload still fails, see rejection output below.  I realize
>> now that this is because of the patch style used for this project:
>> 
>> https://salsa.debian.org/sssd-team/sssd/-/blob/master/debian/README.source?ref_type=heads
>
> This seems to describe a normal use of quilt.  I looked at the rest of
> the git tree and it has the upstream files as expected.
>
>> Could some 'git-debpush --quilt=FOO' parameter had make a difference?
>
> Maybe it could help but I think a different fix is required.
> (How did you select "uannplied" rather than "gbp"?)
>
> I eyeballed the list of files in the report, and I think that
>
>  1. this git branch is based purely on upstream history
>  2. the orig tarball is the upstream "source" tarball
>  3. the upstream "source" tarball contains many non-source objects
>  4. the upstream "source" tarball omits some source files
>
> Examples of 3 include autoconf output eg Makefile.in and the many .mo
> files.  Examples of 4 include .gitignore and probably things like
> contrib/test-suite, and Vagrantfile; evidently these aren't used in
> the Debian package build, but they might be useful for someone working
> on the Debian version of the package so they should be included.
> Something is going on with src/tests/ too, that I don't understand.
>
> In order to do a properly git-based upload, you need a git branch and
> orig tarball that correspond with each other, so that the Debian
> source package and formally published git history can correspond.
>
> There are two ways to square this circle:
>
> You can forget about the upstream orig tarball and just use upstream
> git.  In a case like this that would involve choosing a new "upstream
> version number" and generating a tarball from an upstream git tag.
> (tag2upload can do that for you.)  My recent blog post has a few rune
> suggestions for this [1].
>
> If you did that, the new source package would be significantly
> different to the previous uploads, because it would omit the
> autogenerated files and include all the source files.  But the git
> would remain very similar.  You might need to make some changes to the
> debian/rules because (for example) the autogenerated autotools files
> would now not be present.
>
> It's also possible that you might discover that there are things your
> build relies on that aren't in your git branch.  If there *are* any
> such things, then they are probably autogenerated files which are you
> are not regenereating from real source code; in that case the real
> source code might not even be in the current source package at all!
> Such things can be quite a substantial yak, but an important one:
> it would be software supply chain risk and maybe a DFSG problem.
>
> The other approach is to use gbp import-orig.  This is very common in
> Debian and many people will be familiar with it.  It privileges
> upstream tarball contents over upstream git, so it facilitates various
> anomalies (and even attacks, see for example the famous xz attack).
>
> If you did that, your source package would be quite like the previous
> uploads.  But your Debian git branch would end up containing all this
> autogenerated stuff from the orig tarball.  (You'd probably want
> --quilt=gbp.)
>
> This is the easier option.  It doesn't involve any changes to
> debian/rules.  It avoids detecting uses of autogenerated files that
> exist only in the upstream tarball.  (I'm reminded of the
> sarcastic/parodic aphorism "never check for an error condition you
> don't know how to handle.")
>
> Hope this helps.
>
> You can of course continue to do dput based uploads.
>
> However, it is in cases like this that the weaknesses of "git is only
> on salsa" [2] are most acute.  Because the git branch on salsa has
> totally different contents to the source package, it is not really
> directly useable.  The only way to use the salsa git branch to make a
> source package that looks like the official source code in the ftp
> archive, is to get the orig tarball from the archive and use that in
> combination with the git branch from salsa.  That means that the
> preferred form for modificfation of this package is the *combination*
> of the git from salsa, and the orig from the ftp archive.
>
> Of course we are all volunteers here and there are many suboptimal
> things that need our attention.  And, sadly, these kind of anomaly is
> quite common in Debian.  So I quite understand if opening and sorting
> all these cans of worms doesn't make it to the top of your todo list.
>
> Regards,
> Ian.
>
> [1] In the part for git-debrebase adopters, here:
>   https://diziet.dreamwidth.org/20851.html#determine-upstream-git-and-stop-using-upstream-tarballs
>
> [2] I discuss these problems in from the point of view of a user
> in my 2021 blog post
>   Get source to Debian packages only via dgit;
>   "official" git links are beartraps
>   https://diziet.dreamwidth.org/9556.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-sssd-devel/attachments/20260315/6902a72e/attachment.sig>