[Pkg-electronics-devel] Bug#1068174: yosys: Please package the latest upstream release

[Scott Ashcroft]

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