nextpnr-nexus: default "main" not tracking most recent build

[hdl]

nextpnr-nexus: default "main" not tracking most recent build

[PiotrZierhoffer]

The reason for that is inconsistent version naming: with or without "v". It changed after we switched from @timvideos fork to upstream.

@ajelinski can you please take a look? We can't really drop old versions (i don't think we can. Are they used?). Should we adjust the naming scheme? Can we do that with current scripting?

[ajelinski]

Yes, we can simply adjust the naming scheme for this package. Let's add the 0.0.0 extra tag to the initial commit during the repository preparation so that the package's version will be just as if the package was still built from the timvideos fork.

This exact problem extends to the ecp5, generic and ice40 nextpnr packages so I'll fix their recipes too.

[tcal-x]

@PiotrZierhoffer , @ajelinski --

I still get 0.0.0-3403-g3fd1ee77 if I don't specify a particular version. What controls the addition of the "main" label?

https://anaconda.org/LiteX-Hub/nextpnr-nexus/files --

the new one that I don't get
linux-64/nextpnr-nexus-0.0.0_3846_g4d97e299-20211001_162618_py37.tar.bz2 has label ci-master-1295827473

the old one that I still get
linux-64/nextpnr-nexus-0.0.0_3403_g3fd1ee77-20210923_082942_py37.tar.bz2 has label main

[PiotrZierhoffer]

It's because of the failed CI. It failed for unrelated reasons, as it seems.

I will add the main label for now, so it's fixed for you, but we need to investigate the verilator-uhdm package