[Pkg-electronics-devel] Bug#1101325: nextpnr: New upstream release 0.8

[Daniel Gröber]

On Wed, Mar 26, 2025 at 02:03:18PM +0100, Tarik Graba wrote:
> > I started packaging earlier today. Current blocker is that I'm undecided on
> > is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101323.
> > 
> > Upstream import and WIP packaging is already in salsa if you want to help:
> > 
> >   $ gbp clone https://salsa.debian.org/electronics-team/nextpnr
> 
> Nice! I will take a look.

Awesome. Remember we should try to get this done well before the Soft
Freeze on April 15th to give nextpnr a chance to migrate to testing before
that. I think the 5day delay applies to us so this or next week(end) would
be a good time to work on it ;-)

> > Right I've been mulling whether I should Conflict+Replaces nextpnr-gowin
> > with nextpnr-himbaechel-gowin (symlinks) or not. Digging into what the
> > cmdline differences are would be useful!
> 
> Is it really useful to keep nextpnr-gowin or even have something called
> nextpnr-himbaechel-gowin?

Actually come to think of it stable never had nextpnr-gowin so it's not
worth doing a package replacement here.

> I see that upstream are completely removing references to nextpnr-gowin. For
> example, for apicula examples:
> 
> https://github.com/YosysHQ/apicula/commit/3225c57c53f380817250a01be17ec42283df5ca6
> 
> They are just calling nextpnr-himbaechel the Makefile:
> 
> https://github.com/YosysHQ/apicula/blob/master/examples/Makefile

Right. I was going to enable SPLIT mode to get individual executables for
each uARCH, but I suppose this could end up being a point of friction for
users if other distros choose differently here. Hmm.

I guess if the gowin -> himbaechel replacement doesn't make sense SPLIT
isn't really super useful either.

Except. Individualized chipdb package dependencies for each uarch might
still make this appealing.

Also being able to see if the particular uarch backend you need is
abailable in the distro is a good thing for users. Installing himbaechel
and then having your makefile throw errors because of a missing uarch is
more annoying I think.

We might want to try to coordinate with other distros on this. LMK if you
want to have a go at that or if I should handle it. See
  https://repology.org/project/nextpnr/versions
for a list of who to email.

I already reached out to the Fedora maintainer, somlo, who I already know
on IRC. https://packages.fedoraproject.org/pkgs/nextpnr/nextpnr/

> Regarding he cmdline, it looks also that some options are not passed
> directly anymore but using the vopt option.
> For example:
> 
> $(NEXTPNR) --json $< --write $@ --device GW1NR-LV9QN88PC6/I5 --family
> GW1N-9C --cst tangnano9k.cst
> 
> becomes:
> 
> $(NEXTPNR) --json $< --write $@ --device GW1NR-LV9QN88PC6/I5 --vopt
> family=GW1N-9C --vopt cst=tangnano9k.cst

Got it: it's incompatible. Thanks for looking.

--Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20250326/aa944aec/attachment.sig>