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
