Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
tcal-x opened this issue Sep 30, 2021 · 4 comments · Fixed by #140
Closed

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

tcal-x opened this issue Sep 30, 2021 · 4 comments · Fixed by #140
Assignees
@ajelinski

Comments

@tcal-x
Copy link
Member

tcal-x commented Sep 30, 2021

No description provided.

@PiotrZierhoffer
Copy link
Contributor

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
Copy link
Contributor

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.

ajelinski added a commit that referenced this issue Oct 1, 2021
@ajelinski
nextpnr: Fix package versions after switching to the upstream repository
7e0eb80 
The upstream repository doesn't have any tags so `conda-build-prepare`
tags the initial commit with the `v0.0` tag. The `timvideos/nextpnr`
fork has the initial commit tagged differently which is what causes the
version naming change. It results in the old packages being preferred by
Conda.

Let's use the `extra.tags` file to tag the initial commit similarly as
in the `timvideos` fork during the repository preparation.

Fixes #139.
@ajelinski ajelinski mentioned this issue Oct 1, 2021
Merged
@tcal-x
Copy link
Member Author

tcal-x commented Oct 1, 2021

@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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ajelinski ajelinski

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

nextpnr: Fix package versions after switching to the upstream repository hdl/conda-eda
3 participants
@PiotrZierhoffer @ajelinski @tcal-x