Hi Scott, On Wed, Feb 05, 2025 at 08:28:47PM +0000, Scott Ashcroft wrote: > That was much more difficult than I thought.
Tell me about it! ;-)
> The combination of your work and upstream had dealt with all the
> date/time based stuff. The tex source for the various images which get
> inserted had the magic:
>
> \pdfinfoomitdate 1
> \pdfsuppressptexinfo 1
> \pdftrailerid{}
>
> in them but the .tex file generated by sphinx did not.
> I've added a patch which modifies the conf.py file to make that happen.
> Multiple builds in a row now produce manual.pdf with the same checksum.
Excellent! Can you send the patch upstream or do you want me to?
The patch is also (technically) missing a DEP-3 header
(https://dep-team.pages.debian.net/deps/dep3/). I'm also pretty loose with
that myself since it's a pain to maintain when using git. Most of it is
optional tho and you can embed it in the commitmsg and then export using
git-format-patch (cf. gbp-pq for how to work on a patchstack). Just another
annoying reason to focus on in-tree metadata when doing Debian work.
Maybe tag2upload will change things soon^TM
https://lists.debian.org/debian-devel/2025/02/msg00090.html
https://people.debian.org/~iwj/tag2upload/draft/ I'm enthusiastic :-)
The one thing that is useful in DEP-3 is the Forwarded: bit to note down
that this is going upstream already but when the patch is in
git-format-patch format we can usually guess whether it's a Debian patch or
not from the author ;-)
> I pushed that and made another merge request.
> I've also updated the changelog to hopefully explain why the patches
> were dropped.
That all looks good. However. I've now had a closer look at the git repo
and I find you didn't do the upstream import quite right. d/README.Source
documents the correct incantation:
$ gbp import-orig --component=abc --uscan
What you've done looks like this:
b9680a10 * Update upstream source from tag 'upstream/0.49'
|\
581750b0 | * New upstream version 0.49
b176a4b0 * | Fix watch to match upstream tag format change.
|/
1d6febf8 * debian/0.33-6 Update changelog for 0.33-6 release
i.e. you just committed the upstream changes straight to master. Not sure
how you did that. Probably by hand? Use the tooling!
PS: On a stylistically pedantic note: your commit messages should not end
in a period.
What the incantation does is this:
$ git log --decorate --oneline --graph --simplify-by-decoration master upstream
* e0989fdd (HEAD -> master) Update upstream source from tag 'upstream/0.49'
|\
| * 15958c59 (tag: upstream/0.49, upstream) New upstream version 0.49
* | 1d6febf8 (tag: debian/0.33-6) Update changelog for 0.33-6 release
* | 039639cd (tag: debian/0.33-5) Update changelog for 0.33-5 release
* | 6877c437 (tag: debian/0.33-4) Update changelog for 0.33-4 release
* | d49a5b77 (tag: debian/0.33-3) Update changelog for 0.33-3 release
* | f821c5bc (tag: debian/0.33-2) Update changelog for 0.33-2 release
* | 62f63741 (tag: debian/0.33-1) Reduce docs build verbosity
* | 8b96b385 Update upstream source from tag 'upstream/0.33'
|\|
| * fe499729 (tag: upstream/0.33, salsa/upstream) New upstream version 0.33
* | e01261b9 (tag: debian/0.32-2) Update changelog for 0.32-2 release
See how the upstream imports go into the upstream branch and it's is strung
along on the side there? I hate this aspect of gbp's design but that's how
it is. The upstream branch is used (by default) when gbp doesn't see an
orig tarball. It will do the equivalent of gbp export-orig during the
build, i.e. try to construct a tarball from the git repo. This is usually a
bad idea, but almost certainly wrong when DDs will review your work.
You see, I don't want to have to trust you didn't smuggle a backdoor into
the huge "new upstream" git commit, I just want to download the tarball
myself and not have to think about that possibility :-)
For that reason I generally do the import myself and rebase or cherry-pick
commits from contributors. Andreas merging your MRs broke this bit of my
workflow so now I'll have to force push over this.
In principle I could also review that the upstream import commit
corresponds to the tarball by git-diff'ing it agains a (throwaway) import I
do locally, but I find that counter-intuitive (and annoying) and am not
convinced I can't mess that up ;-)
So next steps wise: I'm going to move yosys to electronics-team since
that's long overdue to put all the FPGA related packages in one place and
might make Andreas just ever so slightly less likeley to mess with my
precious git history as a side-effect haha (I actually talked with him off
list about this don't worry).
I'm also working my way through the copyright review. I think 48k was
underestimating the amount of code added since you didn't import the abc
component properly, so now I'm looking at 145k LoC
1321 files changed, 145055 insertions(+), 28546 deletions(-)
yey. Joy is me.
25% in and I already found a DFSG problem: abc/test.ps so now I have to
update d/copyright to add that to Files-Excluded and re-do the gbp import
and rebase again gah. I'm kind of burned out on this gbp friction tbh. No
clue how other DDs put up with this I'm probably doing something
(everything?) wrong. Oh well.
Note to self: I'm at 60% (1165350,0) libs/fst/lz4.h now. Have to finish
this later :-)
Just FYI so you know what I'm doing: collecting Copyright (C) notices and
similar authorship info for d/copyright and updating the associated
copyright years while also looking for things that look fishy. Perhaps like
new vendored code we can replace, like you already did with
cxxopts. Excellent.
There are some tools to help with the license review aspect. I'm not super
fond of any of them haha. Still useful to cross check their output
sometimes: https://wiki.debian.org/CopyrightReviewTools I'm sure AI will
fix this too in time.</s>
IMO doing this is to some extent an excercise in signaling that shows
someone actually at least scrolled over the code to make sure there's no
new DFSG problems: i.e. blobs (anything not build from source like test.ps)
or new (incompatible) licenses, but I find it's also valuable to properly
credit people's hard work on the code in the durable form that is
d/copyright. Remember those files installed on every (ok, most) Debian
systems along with the corresponding packages. eg.:
/usr/share/doc/yosys/copyright
Hoping you have a slightly better idea of why things take so darn long in
Debian now. Getting this far took most of my Sunday,
--Daniel
signature.asc
Description: PGP signature
