Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1231763 > unrolled thread

Bug#1068174: yosys: Please package the latest upstream release

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1068174: yosys: Please package the latest upstream release Daniel Gröber <dxld@darkboxed.org> - 2025-02-04 17:00 +0100
    Bug#1068174: yosys: Please package the latest upstream release Daniel Gröber <dxld@darkboxed.org> - 2025-02-05 15:10 +0100
      Bug#1068174: yosys: Please package the latest upstream release Daniel Gröber <dxld@darkboxed.org> - 2025-02-10 01:10 +0100
        Bug#1068174: yosys: Please package the latest upstream release Daniel Gröber <dxld@darkboxed.org> - 2025-02-10 12:20 +0100
        Bug#1068174: yosys: Please package the latest upstream release Daniel Gröber <dxld@darkboxed.org> - 2025-03-14 21:20 +0100

#1231763 — Bug#1068174: yosys: Please package the latest upstream release

[Multipart message — attachments visible in raw view] — view raw

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 :-)

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.

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.

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? justification
for dropping patches (upstreamed/obsoleted/conflicting..)? did you even test
the new docs build? What about reproducibility testing? (since you're
removing a SOURCE_DATE_EPOCH patch).

I appreciate Andreas jumping in here to provide a new contributor with some
(immediate) positive feedback, which we tend to be collectively bad at in
Debian. However just hitting the merge button doesn't answer any of those
hard questions, only you can realistically do that.

> So I got a salsa account, did the work to clean up my local packages,
> committed the changes and sent out a merge request.
>
> It got merged and I hoped that one of the uploaders would be able to use
> it as a basis for a new upload.
>
> However, that doesn't seem to be the case.

Maitainers are usually quite busy. This weekend FOSDEM consumed many
people's time (including mine). One week is a reasonable time after which
to ping people on IRC, not for despair :3

> So I'm looking for advice for what I should do next.
>
> Should I go through the process to upload my packages to
> mentors.debian.net?  Or is there a better route to take?

In general the escalation order here is something like this:

1) Mail Maintainer through BTS:
   - Note this could be a Team mailinglist or a person.

   - File "new upstream version pls" bug or reply to existing one.

   - For reply note that NNNNNN@bugs.debian.org only sends to Maitainer so
     you must CC other people you want notified.

2) Mail (CC) Uploaders directly (if Team package) or ping Maintainer again,
   - If no response ping on #debian-$team or find Maintainer on IRC

4) Upload to debian-mentors *and* post RFS bug.
   - If no response ping on #debian-mentors

5) Despair and write a strongly worded physical letter to your governing
   body of choice on the pressing matter of funding FLOSS :-)

6) Optionally lament on IRC in #debian-devel and/or debian-devel
   mailinglist.

((I wonder if we have something like this written down in the wiki already))

Something else to keep in mind: Salsa notifications are unreliable as they
are opt-in for maintainers. Always follow up through BTS/mail immediately
or after a couple days if you don't want MRs/issues to be lost. [[Yes this
sucks. I'm as frustrated about that as anyone but it's how it is now. Git
is still "new" in many Debian people's workflows and Salsa even more so.]]

Mentors is always an option as any DD can upload any package in principle
(as a non-maintainer- or team-upload). When they are not supposed to due to
policy/convention they're likeley to tell you, but you can read up on the
guidelines in developers-reference as they can prevent certain types of
changes to be made without Maintainer involvement in some situations:

  https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus

Thanks <3,
--Daniel

[toc] | [next] | [standalone]

#1231872

[Multipart message — attachments visible in raw view] — view raw

Hi Scott,

On Wed, Feb 05, 2025 at 12:58:54PM +0000, Scott Ashcroft wrote:
> 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.

Indeed they have, because I sent them the fix after meditating on the
same old 0.33 code for the n-th time.

  https://github.com/YosysHQ/yosys/issues?q=involves%3ADanielG%20

Staying on upstream is just extra work when you're the one producing the
pertinent fixes by taking the time to debug problems and not just flailing
around :-P

Debugging takes time and understanding tho. When upstream rejigs everything
understanding goes away.

> > 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.

Git is generally not the critical path in Debian. Unlike with upstream few
people use the git repos directly. Generally just the DDs involved and they
still have to manually review and upload the changes so some treat git more
lightly.

> > 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.

Perhaps. This is the sort of thing where ideally we'd communicate with
upstream to find out what's going on ;-)

However, looking at
https://github.com/YosysHQ-Docs/YosysHQ-Docs/issues/30 and
https://github.com/YosysHQ/yosys/pull/3907 it seems the intent was simply
to move the content to the sphinx doc so it should be fine.

> > 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.

If you want to make things easy on DDs and yourself my recommendation would
be to put this sort of commentary in d/changelog, not git commitmsgs, as
that's more compatible with different workflows in Debian.

Say you do end up having to go the mentors route, then your git commits may
not even get looked at (depends on reviewer), however the debian/ files
always are.

I'm not 100% sure this is the-done-thing since changelog is usually more
user-facing and less reviewer-facing. I did the same thing as you before
becoming a DD, but my thinking is that the DD uploading can always opt to
remove superfluous changelog entries, but they might just ignore you if the
amount of commentary is not to their liking so better to opt for more info
in changelog.
See also
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#best-practices-for-debian-changelog

> I'll try to explain things here:
> 
> abc/0006-Fix-spelling-errors.patch
> Upstream have fixed the spelling issues.

Oh yeah that was me years ago https://github.com/YosysHQ/abc/pull/13 :)

> 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.

Finally. :-)

> 0023-Use-SOURCE-DATE-EPOCH-for-docs.patch
> The files affected by this no longer exist.

Not so ffast there. they got moved:
./docs/source/_images/primer/basics_flow.tex

See b6e61c16b ("docs: restructuring images directory").

> 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.

Did you have a look over the pdf, does it look alright? Could you attach
it?

> > 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.

You'll want to look at `reprotest`. There's also `debrepro` but that one's
no longer really used. I had trouble reproducing failures locally. Since
unstable is broken rn anyway we could also just upload when ready to find
out.

Thanks,
--Daniel

[toc] | [prev] | [next] | [standalone]

#1232560

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1232599

[Multipart message — attachments visible in raw view] — view raw

Hi Scott,

On Mon, Feb 10, 2025 at 11:03:32AM +0000, Scott Ashcroft wrote:
> If you could that would be best as I don't have a github account.

Alright.

> > 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
> 
> That's exactly what I ran to start everything off.
> I forked the project on salsa.
> git cloned my fork.
> Ran the gbp command as given above.
> 
> I suspect that what's gone wrong is that the merge requests only cover
> the master branch so you don't see the upstream (and pristine-tar)
> branch commits from my fork.

Huh. That's possible, but doesn't explain why abc was missing then? Looking
at 581750b0 it seems to be there after all. Where did I pull the 48kLoC
number from then? Weird.

One theory: did you use `gbp clone`? If not some of the relevant branches
might have been missing locally. Maybe gbp fails hillariously when you
don't do that? Unsure.

> I really expected my MR not to be merged and that only the useful
> changes in debian/ would be picked up.
> 
> I really do appreciate the work are you doing and I'm sorry if my ham-
> fisted attempts to help have made it more difficult.

Don't worry about it! I don't say these things to berate you for doing
anything wrong, but merely to explain what's going on and motivate you to
help ;-P

I've been doing this Debian thing for a little while now and I still don't
have a clue, but learning means being comfortable not knowing things (yet).

--Daniel

[toc] | [prev] | [next] | [standalone]

#1237789

[Multipart message — attachments visible in raw view] — view raw

Hi Scott,
Hi ∀¬Scott,

tl;dr: yosys packaging still has issues in the docs build. Python/sphinx
help wanted :-).

On Mon, Feb 10, 2025 at 01:04:01AM +0100, Daniel Gröber wrote:
> 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(-)

Finally got around to finishing the 0.49 copyright review. It's all on on
salsa. Now in electronics-team FYI.

> 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.

That turned out to be the only real problem. Everything else was just new
copyright notices.

So when properly done the output looks like
https://salsa.debian.org/electronics-team/yosys/-/commit/c723cde3b43ae251e3422a7e52e86d8be38eb4f8

It technically doesn't have to be quite as precise as I usually make it:
noting down exactly which files have which license, but it's preferred.

> 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.

So what ends up having to happen here is resetting master, upstream and
pristine-tar to the old 0.33 state and deleting the upstream/0.49 tag. I
just did that in magit so I don't have a nice transcript but it's pretty
obvious when you know all the places to fiddle with.

Next challange: repacking the abc component tarball due to the test.ps
blob.

The incantation that ended up working was

    $ mk-origtargz --component abc --compression gzip -v 0.49 ../yosys-abc-0.49.tar.gz

Unlike gbp import-orig mk-origtargz doesn't do all components at once but
you have to do them one at a time. I found that mildly surprising.

The reason I need --compression gzip is that it seems to default to xz and
gbp in it's infinite wisdom doesn't have an option to specify component
tarballs explicitly but rather assumes the compression must SURELY match
and just searches for $pkg_$ver.orig-$component.tar.pkg_compression. UGH!

This right here is the friction I'm talking about... :-)

Anyway. That done we can import that back into gbp. The yosys tarball
didn't change so I just did:

    $ gbp import-orig --component=abc ../yosys_0.49.orig.tar.gz

After that re-applying your commits using git-format-patch+git-am cause I
was too lazy to try and fail twice at constructing the right rebase call
;-).


Now when I build in sbuild I still get a number of failures. For one
Makefile's rsync dependency isn't declared. Easy fix already done. This
type of thing is why we usually build with some kind of isolated builder
and not using debuild/dpkg-buildpackage directly on our workstation.

Then build-indep breaks because of python problems:

```
./yosys-smtbmc --help > docs/source/generated/yosys-smtbmc
Traceback (most recent call last):
  File "/build/yosys-ghivvZ/yosys-0.49/./yosys-smtbmc", line 22, in <module>
    from smtio import SmtIo, SmtOpts, MkVcd
ModuleNotFoundError: No module named 'smtio'
make: *** [Makefile:1034: docs/source/generated/yosys-smtbmc] Error 1
dh_auto_build: error: make -j1 "INSTALL=install --strip-program=true" docs DOC_TARGET=latexpdf -j1 returned exit code 2
```

My guess is backends/smt2/Makefile.inc needs some new
fiddling. cf. debian/patches/0010-Fix-adding-of-sys.path-in-yosys-smtbmc.patch.

Also: ModuleNotFoundError: No module named 'click'. We probably just need
python3-click in Build-Depends-Indep.

I also found that manually running `dh_auto_build -- docs
DOC_TARGET=latexpdf` inside my sbuild --anything-failed-commands
'%SBUILD_SHELL' shell that just running it again lets the build progress
further despite the errors. No good. Upstream forgot to invalidate the
generated --help output files if the process fails. Another patch for the
stack:

-	-$(Q) ./$(PROGRAM_PREFIX)$(1) --help 2> $$@
+	-$(Q) ./$(PROGRAM_PREFIX)$(1) --help 2> $$@ || rm $$@

The `|| rm $@` pattern is something more people should commit to memory
:-).

Finally sphinx complains:

    build finished with problems, 89 warnings (with warnings treated as errors).

Bah!

/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:131: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/addr_gen_hier.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:154: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/addr_gen_proc.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:174: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/addr_gen_clean.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:259: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_proc.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:305: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_flat.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:390: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_adffe.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:429: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_wreduce.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:451: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_memrdv2.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:536: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_alumacc.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:554: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_coarse.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:605: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_map_ram.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:647: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_map_ffram.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:682: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_map_gates.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:711: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_map_ffs.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:736: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_map_luts.*
/<<PKGBUILDDIR>>/docs/source/getting_started/example_synth.rst:753: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/rdata_map_cells.*
/<<PKGBUILDDIR>>/docs/source/getting_started/scripting_intro.rst:139: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/addr_gen_show.*
/<<PKGBUILDDIR>>/docs/source/getting_started/scripting_intro.rst:189: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/new_cells_show.*
/<<PKGBUILDDIR>>/docs/source/getting_started/scripting_intro.rst:204: WARNING: a suitable image for latex builder not found: _images/code_examples/fifo/addr_gen_hier.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/proc.rst:44: WARNING: a suitable image for latex builder not found: _images/code_examples/synth_flow/proc_01.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/proc.rst:47: WARNING: a suitable image for latex builder not found: _images/code_examples/synth_flow/proc_02.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/proc.rst:58: WARNING: a suitable image for latex builder not found: _images/code_examples/synth_flow/proc_03.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/memory.rst:41: WARNING: a suitable image for latex builder not found: _images/code_examples/synth_flow/memory_01.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/memory.rst:52: WARNING: a suitable image for latex builder not found: _images/code_examples/synth_flow/memory_02.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/opt.rst:90: WARNING: a suitable image for latex builder not found: _images/code_examples/opt/opt_expr.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/opt.rst:113: WARNING: a suitable image for latex builder not found: _images/code_examples/opt/opt_merge.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/opt.rst:135: WARNING: a suitable image for latex builder not found: _images/code_examples/opt/opt_muxtree.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/opt.rst:174: WARNING: a suitable image for latex builder not found: _images/code_examples/opt/opt_share.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:25: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_simple_test_00a.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:34: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_simple_test_00b.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:51: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_simple_test_01a.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:54: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_simple_test_01b.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:61: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_simple_test_02a.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:64: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_simple_test_02b.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:151: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test1a.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:154: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test1b.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:162: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test2a.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:165: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test2b.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:170: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test1b.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:178: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test1c.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:183: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test2b.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:191: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test2c.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:196: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test1c.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:204: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test1d.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:209: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test2c.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:217: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test2d.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:222: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test2d.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/extract.rst:230: WARNING: a suitable image for latex builder not found: _images/code_examples/macc/macc_xilinx_test2e.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/cell_libs.rst:53: WARNING: a suitable image for latex builder not found: _images/code_examples/intro/counter_00.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/cell_libs.rst:68: WARNING: a suitable image for latex builder not found: _images/code_examples/intro/counter_01.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/cell_libs.rst:82: WARNING: a suitable image for latex builder not found: _images/code_examples/intro/counter_02.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/synthesis/cell_libs.rst:115: WARNING: a suitable image for latex builder not found: _images/code_examples/intro/counter_03.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:162: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/sumprod_00.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:179: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/sumprod_01.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:202: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/sumprod_02.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:207: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/sumprod_03.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:212: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/sumprod_04.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:217: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/sumprod_05.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:282: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/memdemo_00.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:293: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/memdemo_01.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:305: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/memdemo_02.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:319: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/memdemo_03.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:330: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/memdemo_05.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:342: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/memdemo_04.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/selections.rst:419: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/select.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:57: WARNING: a suitable image for latex builder not found: _images/code_examples/show/example_first.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:89: WARNING: a suitable image for latex builder not found: _images/code_examples/show/example_second.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:111: WARNING: a suitable image for latex builder not found: _images/code_examples/show/example_third.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:138: WARNING: a suitable image for latex builder not found: _images/code_examples/show/splice.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:166: WARNING: a suitable image for latex builder not found: _images/code_examples/show/cmos_00.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:186: WARNING: a suitable image for latex builder not found: _images/code_examples/show/cmos_01.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:355: WARNING: a suitable image for latex builder not found: _images/code_examples/scrambler/scrambler_p01.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:358: WARNING: a suitable image for latex builder not found: _images/code_examples/scrambler/scrambler_p02.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:439: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/memdemo_00.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:460: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/submod_02.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:465: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/submod_03.*
/<<PKGBUILDDIR>>/docs/source/using_yosys/more_scripting/interactive_investigation.rst:471: WARNING: a suitable image for latex builder not found: _images/code_examples/selections/submod_01.*
/<<PKGBUILDDIR>>/docs/source/yosys_internals/extending_yosys/extensions.rst:137: WARNING: a suitable image for latex builder not found: _images/code_examples/extensions/test1.*
/<<PKGBUILDDIR>>/docs/source/yosys_internals/techmap.rst:36: WARNING: a suitable image for latex builder not found: _images/code_examples/techmap/red_or3x1.*
/<<PKGBUILDDIR>>/docs/source/yosys_internals/techmap.rst:63: WARNING: a suitable image for latex builder not found: _images/code_examples/techmap/sym_mul.*
/<<PKGBUILDDIR>>/docs/source/yosys_internals/techmap.rst:102: WARNING: a suitable image for latex builder not found: _images/code_examples/techmap/mymul.*
/<<PKGBUILDDIR>>/docs/source/yosys_internals/techmap.rst:132: WARNING: a suitable image for latex builder not found: _images/code_examples/techmap/mulshift.*
/<<PKGBUILDDIR>>/docs/source/yosys_internals/techmap.rst:164: WARNING: a suitable image for latex builder not found: _images/code_examples/techmap/addshift.*

I don't feel like figuring those out. If someone wants to have a look that
would be appreciated!

Worst case we can just disable the whole "warnings treated as errors"
thing.

--Daniel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web