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
signature.asc
Description: PGP signature
