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.

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

openXC7 #7

Closed
fricklerhandwerk opened this issue Jul 11, 2023 · 65 comments
Closed

openXC7 #7

fricklerhandwerk opened this issue Jul 11, 2023 · 65 comments
Assignees
Labels
NGI0 Review Funded through NGI Zero Review package Create a Nix package

Comments

@fricklerhandwerk
Copy link
Collaborator

Free and open source FPGA toolchain for AMD/Xilinx Series 7 chips

This seems to be a non-trivial project with multiple dependencies. Break down into separate issues as needed.

@fricklerhandwerk fricklerhandwerk added package Create a Nix package NGI0 Review Funded through NGI Zero Review labels Jul 11, 2023
@jleightcap
Copy link
Collaborator

jleightcap commented Aug 9, 2023

@ngi-nix/moss is claiming this!

@hansfbaier
Copy link

Thanks for the devshell! I still have an issue.
If I try to load the yosys-ghdl plugin like this:

$ yosys
yosys> plugin -i /nix/store/wfhih024a3hcri75dzbhphw622ra3p0w-yosys-ghdl-2022.01.11/share/yosys/plugins/ghdl.so
ERROR: Can't load module `/nix/store/wfhih024a3hcri75dzbhphw622ra3p0w-yosys-ghdl-2022.01.11/share/yosys/plugins/ghdl.so': libgnat-10.so: cannot open shared object file: No such file or directory

Then it misses the mentioned library. How can you add shared library dependencies to the devshell?
Also, how can the user get the path to the plugin to load (eg in a Makefile), so that the nix store location does not need to be hardcoded in the Makefile?

@albertchae
Copy link
Contributor

@hansfbaier thanks for the report. We'll look into fixing that and also your question about the path for the Makefile during our next mob session on Thursday

@jleightcap
Copy link
Collaborator

Yeah, seconding the thanks for the update. I wanted to look at using the upstream yosys plugins during our next mob (see: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/yosys/plugins/ghdl.nix)

Without having looked closely at the locally defined builds/versions, was there a reason for packaging separately outside of upstream?

@hansfbaier
Copy link

I nead a special yosys version (0.17) as later versions trigger a non implemented feature in nextpnr-xilinx.

@jleightcap
Copy link
Collaborator

Thanks for the info, I see how you selectively pulled definitions in from upstream at the correct version. We ended up meeting for shorter than expected today, hoping to have more of an update when we meet this Saturday 🙂

@albertchae
Copy link
Contributor

@hansfbaier how are you starting running the dev shell? We tried the following on 2 different machines and were able to load the yosys-ghdl plugin successfully

[~/toolchain-nix]$ nix develop
[nix(openXC7)] yosys

 /----------------------------------------------------------------------------\
 |                                                                            |
 |  yosys -- Yosys Open SYnthesis Suite                                       |
 |                                                                            |
 |  Copyright (C) 2012 - 2020  Claire Xenia Wolf <claire@yosyshq.com>         |
 |                                                                            |
 |  Permission to use, copy, modify, and/or distribute this software for any  |
 |  purpose with or without fee is hereby granted, provided that the above    |
 |  copyright notice and this permission notice appear in all copies.         |
 |                                                                            |
 |  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES  |
 |  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF          |
 |  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR   |
 |  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES    |
 |  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN     |
 |  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF   |
 |  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.            |
 |                                                                            |
 \----------------------------------------------------------------------------/

 Yosys 0.17 (git sha1 yosys-0.17, gcc 11.3.0 -fPIC -Os)


yosys> plugin -i /nix/store/wfhih024a3hcri75dzbhphw622ra3p0w-yosys-ghdl-2022.01.11/share/yosys/plugins/ghdl.so

yosys>

@hansfbaier
Copy link

hansfbaier commented Aug 11, 2023

Yes, I also used nix develop, but on Ubuntu, not NixOS. Interesting, that is actually the main issue that nix set out to solve. I wonder why it fails on my machine.

@albertchae
Copy link
Contributor

We'll try debugging it on ubuntu during our next session

@hansfbaier
Copy link

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.2 LTS"

@hansfbaier
Copy link

hansfbaier commented Aug 11, 2023

I found this with strace:

openat(AT_FDCWD, "/nix/store/2j8jqmnd9l7plihhf713yf291c9vyqjm-glibc-2.35-224/lib/libgnat-10.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

I looked into the directory. I tlooks ok, except that libgnat does not exist there:

$ ls /nix/store/2j8jqmnd9l7plihhf713yf291c9vyqjm-glibc-2.35-224/lib
Mcrt1.o  crti.o   grcrt1.o              libanl.so    libc_malloc_debug.so    libdl.so.2     libm.so.6       libnsl.so.1         libnss_db.so.2     libnss_hesiod.so.2  libresolv.so    libthread_db.so    locale
Scrt1.o  crtn.o   ld-linux-x86-64.so.2  libanl.so.1  libc_malloc_debug.so.0  libgcc_s.so    libmemusage.so  libnss_compat.so    libnss_dns.so.2    libpcprofile.so     libresolv.so.2  libthread_db.so.1  rcrt1.o
audit    gconv    libBrokenLocale.so    libc.so      libc_nonshared.a        libgcc_s.so.1  libmvec.so      libnss_compat.so.2  libnss_files.so.2  libpthread.so       librt.so        libutil.so
crt1.o   gcrt1.o  libBrokenLocale.so.1  libc.so.6    libdl.so                libm.so        libmvec.so.1    libnss_db.so        libnss_hesiod.so   libpthread.so.0     librt.so.1      libutil.so.1

@hansfbaier
Copy link

If I do

sudo /nix/var/nix/profiles/default/bin/nix --extra-experimental-features nix-command store repair /nix/store/2j8jqmnd9l7plihhf713yf291c9vyqjm-glibc-2.35-224

it seems to reinstall the package, but libgnat is still not there.

@albertchae
Copy link
Contributor

@hansfbaier we tried a few different things but we are still having trouble reproducing your issue

  • we wanted to identify if the devshell was relying on a libgnat available in the outer NixOS. We did this by running nix develop -i (-i for ignore environment). However, no issues loading the plugin.

  • We then tried to see if the issue was nix on ubuntu. On an ubuntu 22.04 install, we tried nix develop -i and had no issues loading the plugin.

  • One interesting thing is that we also do not have libgnat in our /nix/store/2j8jqmnd9l7plihhf713yf291c9vyqjm-glibc-2.35-224/lib on ubuntu. In fact, if we run strace (either on the entire devshell with strace -f -o out.log nix develop -i or even just on yosys once we're in the dev shell with strace -f -o out.log yosys), we see libgnat referred to in a completely different place

361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/glibc-hwcaps/x86-64-v3/libgnat-12.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
361515 newfstatat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/glibc-hwcaps/x86-64-v3", 0x7fffffffaa60, 0) = -1 ENOENT (No such file or directory)
361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/glibc-hwcaps/x86-64-v2/libgnat-12.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
361515 newfstatat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/glibc-hwcaps/x86-64-v2", 0x7fffffffaa60, 0) = -1 ENOENT (No such file or directory)
361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/tls/haswell/x86_64/libgnat-12.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
361515 newfstatat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/tls/haswell/x86_64", 0x7fffffffaa60, 0) = -1 ENOENT (No such file or directory)
361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/tls/haswell/libgnat-12.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
361515 newfstatat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/tls/haswell", 0x7fffffffaa60, 0) = -1 ENOENT (No such file or directory)
361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/tls/x86_64/libgnat-12.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
361515 newfstatat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/tls/x86_64", 0x7fffffffaa60, 0) = -1 ENOENT (No such file or directory)
361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/tls/libgnat-12.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
361515 newfstatat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/tls", 0x7fffffffaa60, 0) = -1 ENOENT (No such file or directory)
361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/haswell/x86_64/libgnat-12.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
361515 newfstatat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/haswell/x86_64", 0x7fffffffaa60, 0) = -1 ENOENT (No such file or directory)
361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/haswell/libgnat-12.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
361515 newfstatat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/haswell", 0x7fffffffaa60, 0) = -1 ENOENT (No such file or directory)
361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/x86_64/libgnat-12.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
361515 newfstatat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/x86_64", 0x7fffffffaa60, 0) = -1 ENOENT (No such file or directory)
361515 openat(AT_FDCWD, "/nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/adalib/libgnat-12.so", O_RDONLY|O_CLOEXEC) = 3

Also that it is looking for libgnat-12 in /nix/store/x8fwz375r3qkz79x1bgbaaykla8sk3s0-gnat-12.2.0, while your errors show that it was trying to load libgnat-10

Honestly, we're kind of at a loss at what to try next. Can you tell us your nix --version? We were able to get working dev shells on 2.15.1, 2.15.0 and 2.13. Also, we installed nix using the determinate systems installer.

@hansfbaier
Copy link

Thanks, sorry I can't do anything at the moment, my PC is defective and I have to figure out which part needs to be replaced.

@hansfbaier
Copy link

Hmm, got by PC up and running again. Removed flake.lock, then it downloaded and recompiled everything, but I still have the same issue.

@hansfbaier
Copy link

Ah, if I use the ghdl plugin from the same hash version as you, then it also works for me:

 Yosys 0.17 (git sha1 yosys-0.17, gcc 11.3.0 -fPIC -Os)


yosys> plugin -i /nix/store/wfhih024a3hcri75dzbhphw622ra3p0w-yosys-ghdl-2022.01.11/share/yosys/plugins/ghdl.so

yosys> 

So the question is, how does the user find the right path to the ghdl plugin?
Can that be automated somehow?

@albertchae
Copy link
Contributor

@hansfbaier sorry to hear about your PC issues but I'm glad you have it running again. Could you tell us your nix version and also how you installed it?

If you're available to meet on video call sometime this week for a live debugging session, that might be next best option.

@hansfbaier
Copy link

@albertchae I just got it working, by deleting flake.lock and using your hash for the yosys plugin.

@hansfbaier
Copy link

@albertchae I have to add that the culprit is probably my active nix profile. When I tried a new user it works,
but in my nix profile it does not.

@hansfbaier
Copy link

$ nix profile list
0 flake:nixpkgs#legacyPackages.x86_64-linux.vscodium github:NixOS/nixpkgs/4a56ce9727a0c5478a836a0d8a8f641c5b9a3d5f#legacyPackages.x86_64-linux.vscodium /nix/store/m5m2z5hr4cdqdxir96p6620xx8mqqdnz-vscodium-1.80.2.23209
1 flake:nixpkgs#legacyPackages.x86_64-linux.librewolf github:NixOS/nixpkgs/0cb867999eec4085e1c9ca61c09b72261fa63bb4#legacyPackages.x86_64-linux.librewolf /nix/store/dxj6jzbd5ik01zpdqlw0lr4yppvvb9ik-librewolf-113.0-3
2 flake:nixpkgs#legacyPackages.x86_64-linux.github-desktop github:NixOS/nixpkgs/0cb867999eec4085e1c9ca61c09b72261fa63bb4#legacyPackages.x86_64-linux.github-desktop /nix/store/fwxqw86ba3r3yxxkhjypm30x5lrx6kdk-github-desktop-3.2.1
3 flake:nixpkgs#legacyPackages.x86_64-linux.helix github:NixOS/nixpkgs/3acb5c4264c490e7714d503c7166a3fde0c51324#legacyPackages.x86_64-linux.helix /nix/store/h24wygkxsrfwsyaxi35faxx3hfwdaqks-helix-23.05
4 flake:nixpkgs#legacyPackages.x86_64-linux.poetry github:NixOS/nixpkgs/0cb867999eec4085e1c9ca61c09b72261fa63bb4#legacyPackages.x86_64-linux.poetry /nix/store/plyy5cj3q364mzyjmczm95grsf8wpr6y-python3.10-poetry-1.4.2
5 flake:nixpkgs#legacyPackages.x86_64-linux.verilator github:NixOS/nixpkgs/0cb867999eec4085e1c9ca61c09b72261fa63bb4#legacyPackages.x86_64-linux.verilator /nix/store/my28m8asnxnrpj47d3hiznygsmaqv3rh-verilator-5.010
6 flake:nixpkgs#legacyPackages.x86_64-linux.lldb github:NixOS/nixpkgs/0cb867999eec4085e1c9ca61c09b72261fa63bb4#legacyPackages.x86_64-linux.lldb /nix/store/nc6534f8dbzf0m266yddwvngmvd5k2in-lldb-14.0.6

@hansfbaier
Copy link

hansfbaier commented Aug 21, 2023

@albertchae No, it was not the profile, I narrowed it down: I had LD_LIBRARY_PATH set to /usr/local/lib.
As soon as I remove that environment variable, it starts working. So the remaining question is: how does the user discover the proper path of the ghdl plugin for his current yosys version?

@albertchae
Copy link
Contributor

@hansfbaier we decided to pull out formatting changes only to openXC7/toolchain-nix#5 and then we had some additional questions for you in openXC7/toolchain-nix#4 (comment) that'll help us keep improving openXC7/toolchain-nix#4

@albertchae
Copy link
Contributor

@hansfbaier we wanted to check in since we have less than 2 weeks left for summer of nix. From our understanding of the scope of this issue, our goal was to package the entire toolchain for OpenXC7 using Nix within https://github.com/openXC7/toolchain-nix. It seemed like you already had most of that in place, but we helped you add a devShell in openXC7/toolchain-nix#2 and then helped refactor the Nix code to be more idiomatic (and thus hopefully closer to upstreamable) with openXC7/toolchain-nix#3 openXC7/toolchain-nix#5 and openXC7/toolchain-nix#4.

We believe the last missing package/tool in the toolchain was fasm which you called out in the README, so we have a PR to add this in openXC7/toolchain-nix#6. Was there anything else you needed in the toolchain-nix repo as part of the OpenXC7 toolchain, or would you say that merging this PR would complete the scope of work under Summer of Nix? We will open a separate thread (probably as an issue in toolchain-nix repo) about continuing to try and upstream packages outside of Summer of Nix.

@hansfbaier
Copy link

hansfbaier commented Oct 5, 2023

@albertchae Thanks, for the fasm changes. When I use the fasm package, I still get a warning message that the antlr parser is not available, which degrades performance:

python3
Python 3.10.11 (main, Apr  4 2023, 22:10:32) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import fasm
/nix/store/7aplvxiy7r1nl7fa2rlp2r681pihjh52-python3.10-fasm/lib/python3.10/site-packages/fasm/parser/__init__.py:30: RuntimeWarning: Unable to import fast Antlr4 parser implementation.
  ImportError: cannot import name tags

  Falling back to the much slower pure Python textX based parser
  implementation.

  Getting the faster antlr parser can normally be done by installing the
  required dependencies and then reinstalling the fasm package with:
    pip uninstall
    pip install -v fasm

  warn(
>>> 

Does the fasm package require the antlr4 package as a dependency?

@jleightcap
Copy link
Collaborator

jleightcap commented Oct 6, 2023

Using the ANTLR4 parser is currently quite difficult given the state of both nixpkgs and fasm. ANTLR4 is not required because the textx parser is available as a slower fallback.

If ANTRL4 support was useful for the toolchain, my general recommendation is to 'revive' the fasm repository somehow. I'd probably recommend forking the repository, as the current upstream seems abandoned; build system fixes exist on an umerged PR, for example.

We might be able to help with this, but I'd note this is likely outside of the Summer of Nix goals.

@fricklerhandwerk
Copy link
Collaborator Author

fricklerhandwerk commented Oct 6, 2023

Does the fasm package require the antlr4 package as a dependency?

If the warning is really annoying, I'd suggest to patch out the offending lines so we can come to a conclusion here. Indeed we can't resolve an issue as deep as dealing with an unmaintained dependency.

@hansfbaier
Copy link

@albertchae @fricklerhandwerk point taken, yes I agree.

@hansfbaier
Copy link

@albertchae There is one item left, which puzzles me. Setting environment variables seems to work in prjxray-setup-hook.sh, but not in nextpnr-setup-hook.sh.
I can see the variable from prjxray, but not from nextpnr in the devshell.
Why might that be?

@hansfbaier
Copy link

I also have another question: When I want to get the path of a package, I could:

nix eval --raw ".#nextpnr-xilinx-chipdb.spartan7.outPath"

but that only works inside the flake directory.
If I want to use this in a Makefile I would either have to provide the path to the flake
in the local file system, or use the GitHub URL.
The latter is independend of the CWD, but requires me to be online.
Is there a way to get the path in a CWD independent manner offline?
One would be the setup hook, but that does not seem to work for nextpnr-xilinx and the chip databases.

@hansfbaier
Copy link

Ah I found a way:
image

@hansfbaier
Copy link

So another item that is left, is how to get into the devshell in a CWD independent and offline manner.

jleightcap added a commit to ngi-nix/toolchain-nix that referenced this issue Oct 7, 2023
see:
ngi-nix/ngipkgs#7 (comment)

fasm provides two options for runtime parsing: `textx` and ANTLR4.

ANTLR4 is:

- not immediately in nixpkgs as a C++ runtime with compatible CMake
  hooks
- not easily exposed in the fasm build scripts.

There is an Arch Linux specific workaround on an unmerged branch.

For the time being, fall back to the flower `textx` parser and patch out
the runtime warning:

```
RuntimeWarning: Unable to import fast Antlr4 parser implementation.
      ImportError: cannot import name tags

      Falling back to the much slower pure Python textX based parser
      implementation.

      Getting the faster antlr parser can normally be done by installing the
      required dependencies and then reinstalling the fasm package with:
        pip uninstall
        pip install -v fasm

      warn(
```

Thanks for the tip fricklerhandwerk!

Signed-off-by: Jack Leightcap <jack@leightcap.com>
@jleightcap
Copy link
Collaborator

jleightcap commented Oct 7, 2023 via email

@jleightcap
Copy link
Collaborator

jleightcap commented Oct 7, 2023 via email

@albertchae
Copy link
Contributor

Hi @hansfbaier , we're looking into your question here #7 (comment), but I wanted to ask again

Was there anything else you needed in the toolchain-nix repo as part of the OpenXC7 toolchain (besides fasm)?

If there is a package or tool missing, please let us know.

@hansfbaier
Copy link

@albertchae The shellHook in the devshell, solves #7 (comment)
sufficiently. I will let you know should I have more needs. Thank you so much for your help!

@albertchae
Copy link
Contributor

Thanks for confirming @hansfbaier ! In that case, we will close this issue for Summer of Nix tracking 🚀 Thanks again for the great collaboration

For further work outside of Summer of Nix, we should continue discussion in openXC7/toolchain-nix#7 (which you've already commented on). Because that will be outside of the Summer of Nix, only volunteers who have interest in the project will be participating (so far @jleightcap and I).

@jleightcap
Copy link
Collaborator

https://fosstodon.org/@hansfbaier/111220127699758726
Nice to see, @hansfbaier!

@lorenzleutgeb
Copy link
Member

@albertchae can https://github.com/ngi-nix/toolchain-nix be archived? Or probably even better, if you don't care about the history, deleted?

@jleightcap
Copy link
Collaborator

We have two open PRs rooted from that fork.

That work is towards upstreaming into nixpkgs, and so their usefulness is dependent on if @hansfbaier finds that effort useful.

@lorenzleutgeb
Copy link
Member

Okay, sorry that I missed those PRs. Then the question changes to whether the repo can be archived/deleted once both of these PRs are closed.

@jleightcap
Copy link
Collaborator

No worries, that work was outside of the scope of Summer of Nix anyways, so it shouldn't reside there. I'll wait a bit more to see if they get reviewed after the ping above, and if not, I'll move that work into a personal fork and delete https://github.com/ngi-nix/toolchain-nix.

@fricklerhandwerk
Copy link
Collaborator Author

@lorenzleutgeb please don't ever delete repos, only archive them. We can always link to a query that filters out archived repos.

@jleightcap
Copy link
Collaborator

I've forked the repository into my personal account. Feel free to archive. There are still active PRs based in that repository, so please don't delete.

@hansfbaier
Copy link

Good news: I tried the latest yosys version and it seems to work well now. Will keep on testing for a while but it looks like it is time to switch.

@jleightcap jleightcap mentioned this issue Mar 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NGI0 Review Funded through NGI Zero Review package Create a Nix package
Projects
Status: mobleted
Development

No branches or pull requests

8 participants