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

[Tarik Graba]

Hi Daniel,

On 26/03/2025 14:43, Daniel Gröber wrote:
> 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 ;-)
> 

Sorry here, but I will not be able to help you on this task.
I do not have a proper build environment for the moment and I will not 
have the time.

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

I also think so.

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

I think you are more aware of packaging constraints and how to organize 
them.

> 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 did not contact the maintainers, but I have taken a look at what/how 
packages are built.

1. Fedora: they only build for generic/ice40/ecp5
    * specfile 
https://src.fedoraproject.org/rpms/nextpnr/blob/rawhide/f/nextpnr.spec
    * the last snapshot they are targeting is after the removal of the 
gowin variant (#d8988e16827a4)
    * plausibly, nextpnr-gowin will never be packaged here.

2. Arch/AUR they build the Himbaechel variant
    * pkgbuild 
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nextpnr-git
    * and they have just removed the Gowin arch
     -> 
https://aur.archlinux.org/cgit/aur.git/commit/?h=nextpnr-git&id=e19e188a034a020b9332c5f5ae0eaf1e6867ea3a

3. BSD port has a 0.8 release, but they only build for ICE40 and ECP5
      - https://cgit.freebsd.org/ports/tree/devel/nextpnr/Makefile

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

Upstream has already a packaging strategy with the oss-cad-suite-build 
(https://github.com/YosysHQ/oss-cad-suite-build).

Shouldn't distributions do something similar?

The commit where they removed the Gowin variant:

https://github.com/YosysHQ/oss-cad-suite-build/commit/d9e0f11ca87ad90c10e1bacc45365137ac1ac01c

"default/rules/default.py" contains the targets list and 
"default/scrips" the build scripts.

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

Thanks again for your commitment,

Tarik