On Tue, 2025-02-04 at 16:52 +0100, Daniel Gröber wrote: > Hi Scott, > > On Tue, Feb 04, 2025 at 01:22:18PM +0000, Scott Ashcroft wrote: > > Then out of blue there was an upload in January, still based on an > > old > > version. > > Larry reminded me to do it that's why :-)
Thanks for taking the time to respond and looking my MR. > As much as I try sometimes these mail threads end up not going to the > BTS, > gah. > > The short of "why still 0.33" is new versions introduce new problems > and we > were still fixing the old ones (reproducibility). When contributor > time is > the limiting factor Debian tends to prioritise stability over latest > and > greatest features. I understand that but you've also made more work for yourself by not looking at the newer upstream versions. A lot of the issues in the docs build, which seems to be the biggest issue, have been addressed there. > You're very welcome to help with that, but you have to understand > that > Debian work is more time consuming than that you may be used to in > almost > every aspect imaginable. We have a plethora of architectures to > support, > stacks of policy to conform to and more users than one might > reasonably > expect ;-) > > The very first step for reviewing a new upstream version is always > copyright/DFSG review which is just going to take a serious amount of > time > right off the bat with 43k lines added in this case. I understand that too and that's why I was a bit shocked that my changes just got merged. I really expected them to sit as an MR which might have been useful at some point in the future. > These factors are why you'll find us DDs are slow to review new > contibutions at times because it's a *lot of work* and while > reverting a > botched new upstream import is in principle always possible it's ugly > (See > debian-policy 5.6.12.1. on use of +really), represents even more work > and > after the xz incident we're just a tad more paranoid in general :-) > > Your MR in particular was looking very good but missing a lot of > context on > the doc side of things: why is presentation.pdf being removed? Upstream removed it between versions 0.39 and 0.40. The commit that kills it, and the whole manual directory, is "Move the last presentation slides" but there's no further explanation. My guess is it was just out of date as it was written in the very early days of the project. > justification > for dropping patches (upstreamed/obsoleted/conflicting..)? Looking back on it, I should have made better commit messages for those, but I've been tweaking the patches for more than a year so it really felt like a simple refresh. I'll try to explain things here: abc/0006-Fix-spelling-errors.patch Upstream have fixed the spelling issues. switch-to-free-font.patch The presentation is gone and luximono isn't mentioned elsewhere. 0021-Fix-global-cache-destruction-in-IdString-class.patch Upstream have refactored the IdString class and deprecated parts of it. That makes this patch obsolete. 0023-Use-SOURCE-DATE-EPOCH-for-docs.patch The files affected by this no longer exist. 0024-Fix-docs-images-tidy-race.patch Upstream have changed the docs build so that tidy is only used during clean. 0025-Remove-emoji-causing-latex-errors.patch The file affected by this no longer exist. I couldn't find any other emojis in the latex source. > did you even test > the new docs build? Yes. It builds fine even with -j16. Upstream have now made the docs target depend on docs/prep which seems to fix the races seen in earlier versions. In my version of 0.44 I had a bunch of extra steps in debian/rules just to get things to build to completion but those are not required any more. > What about reproducibility testing? (since you're > removing a SOURCE_DATE_EPOCH patch). I'm looking at that now and I can see that the manual.pdf produced isn't reproducible. The upstream Makefile seemed to be addressing the issue but obviously not completely. I expect that something like the SOURCE_DATE_EPOCH patch is required but I'm happy to work on that. Cheers, Scott
