Hello, the package can't build since new peppercorn 1.14 was uploaded in sid:
Missing build dependencies: python3-peppercorn (<< 1.14~)

I think a bump of dependencies, or relaxing them might be needed.

thanks

Gianfranco

tags 1152532 -patch
thanks

Hi,
I expected the changes between 1.13 and 1.14 to be rather minor, but it
turns out they're not. So the options right now are to upload a
prjpeppercorn 1.14+really1.13 and create a really convoluted
Build-Depends/Build-Conflicts construct, or leave the current state
until the new nextpnr release is tagged, which should be soon.

I'm tending towards the latter, as prjpeppercorn 1.14 cannot migrate to
testing, so we have a consistent state there, and any trickery with
dependencies endangers that, plus there will be bigger changes to
nextpnr with the next upload anyway.

Since that upload will have to go through NEW, I will have to find out
how to avoid triggering the slop machine first.

    Simon

control: tags -1 patch
Hello

I just cherry-picked an upstream one-line fix to bump the version and the build went just fine.


https://launchpad.net/ubuntu/+source/nextpnr/0.11.1+dfsg-5ubuntu2

I'm attaching the patch in case you want to consider an upload :)

Thank you!

Gianfranco





Il giorno venerdì 30 ottobre 2026 alle ore 11:12:00 CET, Simon Richter <sjr@debian.org> ha scritto:





tags 1152532 -patch
thanks

Hi,
I expected the changes between 1.13 and 1.14 to be rather minor, but it
turns out they're not. So the options right now are to upload a
prjpeppercorn 1.14+really1.13 and create a really convoluted
Build-Depends/Build-Conflicts construct, or leave the current state
until the new nextpnr release is tagged, which should be soon.

I'm tending towards the latter, as prjpeppercorn 1.14 cannot migrate to
testing, so we have a consistent state there, and any trickery with
dependencies endangers that, plus there will be bigger changes to
nextpnr with the next upload anyway.

Since that upload will have to go through NEW, I will have to find out
how to avoid triggering the slop machine first.

Simon

Hi,
interpretation of the data, that's why upstream built the
EXPECTED_VERSION logic in the first place.

You'd need all the changes in himbaechel/uarch/gatemate (18 commits
IIRC), plus their dependencies in common parts, to get something that
has a chance of actually working.

If an Ubuntu release is close enough that you need a working version
right now, we could possibly make a 0.11.1+gitXXXX intermediate version,
but generally speaking, upstream changes so much between versions that
using tagged versions is the better choice.

Uploading prjpeppercorn 1.14 was a mistake (and I held back for a few
months back when 1.13 came out for the same reason) -- but I wonder why
Ubuntu picked it up if it breaks the Build-Depends of nextpnr.

Unrelated: can Ubuntu deal with Build-Depends-Arch: on the arch:all
packages from the same source? There are two WIP branches on Salsa[1],
and one of them is a horrible hack that might or might not work on
Ubuntu (but it saves a few days of autobuilder time on each upload, so...).

    Simon

[1] https://salsa.debian.org/electronics-team/nextpnr

Hello!

the release is 6 months away, but I'm trying to rebuild against new boost,
and having something that doesn't build is preventing decruft of old library...
but no hurry at all, indeed

I guess it was auto-syncd, or don't know

I guess not, sadly. We usually do a build with some nocheck/stage1 profile enabled, then we upload
a new version that takes it from the previous built package.

In 2026 bootstrapping packages is still a nightmare

G.

Hi,
It's not a full bootstrap, the basic idea is that Build-Depends-Indep
will get the build dependencies on the various prj* packages that bring
the FPGA databases, and will build BE/LE database packages that the go
into Build-Depends-Arch (with a <!nocheck> qualifier, because they are
only required to run tests).

So basically you can run either of

     DEB_BUILD_PROFILES=nocheck dpkg-buildpackage -b

or

     dpkg-buildpackage -A
     dpkg -i ../*.deb
     dpkg-buildpackage -B

The latter is what Debian autobuilders do, as arch:all is a separate
autobuilder.

    Simon