Re: Creating a C/C++ team?
On Fri, Nov 29, 2024 at 10:36:13AM +0100, Liliana Marie Prikler wrote: > Hi Greg, > > Am Montag, dem 25.11.2024 um 13:27 -0500 schrieb Greg Hogan: > > Guix, > > > > Should we have a C++ team? I think project contributions regarding C > > and C++ compilers, libraries, tools, and programs would benefit from > > a tag to flag, discuss, and triage issues and a team branch to > > manage, test, and pre-build patches. > > > > This team would of course be distinct from the core-packages team, > > which manages the most fundamental packages and challenging updates. > I think there is a risk that this still overlaps with core-packages on > the account of GCC being our main C/C++ toolchain. > > Note: while I'm already swamped with work on gnome and emacs, I would > be interested in joining a hypothetical c++ team. > > > diff --git a/etc/teams.scm b/etc/teams.scm > > index fe3291f914..e257650a04 100755 > > --- a/etc/teams.scm > > +++ b/etc/teams.scm > > @@ -611,0 +612,14 @@ (define-team zig > > +(define-team c++ > > + (team 'c++ > > + #:name "C/C++ team" > > + #:description > > + "C and C++ compilers, libraries, tools, and programs" > I would limit the scope to "libraries and tools". That programs happen > to be written in C/C++ is almost always incidental :) > > > + #:scope (list "gnu/packages/c.scm" > > + "gnu/packages/cpp.scm" > Of course. > > > + "gnu/packages/llvm.scm" > > + "gnu/packages/llvm-meta.scm" > Not sure about these two. Since our main use for LLVM is in > Rust/Zig/Mesa, all of which have their own teams, maybe we should leave > a broader LLVM team with members from all of that open for folks who > are not necessarily interested in the rest of C/C++. > > > + "gnu/packages/ninja.scm" > > + "gnu/packages/valgrind.scm" > If we add these, I would also suggest adding build-tools.scm, > check.scm, debug.scm etc. > > > + "gnu/build/cmake-build-system.scm" > > + "gnu/build-system/cmake.scm"))) > These are under guix/ and belong to the core team IIRC. As someone who is in more teams than I mean to be, I wouldn't mind some overlap between the different teams. Likely the default llvm hasn't been upgraded still because no one wants to be the one to break something. Also its nice when someone else is able to take something off your plate. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: guix package -i kicad will fait with #error "Unsupported CPU architecture" on my Talos II
On Sat, 2024-11-30 at 20:59 +, Ian Eure wrote: > Hi Tobias, > > On Sat, Nov 30, 2024, at 8:18 PM, Tobias Alexandra Platen wrote: > > When I try to install Kicad, I'll get the following output: > > > > The following derivations will be built: > > /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv > > /gnu/store/x26zsx3fw74vhfc35i79fansmlmhl0cc-libfabric-1.22.0.drv > > /gnu/store/nfj2qvhyxvfc7x5fkdlyg2z1wnpqw9cz-openmpi-4.1.6.drv > > /gnu/store/l1rbmwj9m4kgkm1qada665mm0m6g10w1-libngspice-43.drv > > /gnu/store/y88c48hzcm78ch39wjfa3dpdgw9n6m7r-webkitgtk-with- > > libsoup2- > > 2.44.1.drv > > /gnu/store/qv0zpz8h2dvhbmxz6smsbmc763rdkdxm-wxwidgets-3.2.5.drv > > /gnu/store/llydl3baxardzgf9xmdbgjikny68vaar-python-wxpython- > > 4.2.0.drv > > /gnu/store/b0s2jgimknw6035kcqvpb6sdxkhakz7b-kicad-7.0.11.drv > > > > After a few minutes the build fails with: > > > > building /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv... > > \ 'build' phasebuilder for > > `/gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv' failed with exit code 1 > > build of /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv failed > > View build log at > > '/var/log/guix/drvs/5r/inv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv.gz'. > > > > CC utils/read_lat.o > > > > #error "Unsupported CPU architecture" > > > > I also found a blogpost which mentions libcxi, what does libcxi do? > > https://hpc.guix.info/blog/2024/11/targeting-the-crayhpe-slingshot-interconnect/ > > > > The package description provides a pretty good summary: > > Interface to the Cassini/Slingshot high-speed interconnect > > Libcxi provides applications with a low-level interface to > the > Cray/HPE Cassini high-speed NIC (network interface > controller), also > known as Slingshot. > > > I guess that libcxi is optional for Kicad, so I could hack guix to > > build Kicad without libcxi. Since I do not have that interconnect I would make it optional. The fastest interconnect that I have is USB 3.0 between my Talos II (host) and ROCKPro64 (device/otg). I plan to make my own guix channel anyway with personal changes and for software development. For example I plan to add guile scripting to eeschema, after I found out that the python scripts are broken and upgrade to KiCad 8 or any later version. > > > > I think this is worth a bug report, and maybe you're also up to > sending some patches? I think it's slightly more complicated than > just the kicad package, though, since libcxi isn't a direct > dependency: > > $ guix graph --path kicad libcxi > kicad@7.0.11 > libngspice@43 > openmpi@4.1.6 > libfabric@1.22.0 > libcxi@1.0.1-0.5b6f8b5 > > So, I think what needs to happen is that libcxi needs to have POWER9 > removed from its supported-systems field; and libfabric needs to > conditionally include libcxi in its inputs based on architecture. I > think the best way to do that is by checking for the build system in > (package-supported-systems libcxi), which will avoid hardcoding > duplicate arch tests in two packages. > > -- Ian >
Re: Bootstrapping Zig with no binary blobs: status update and call for packages.
Hi Ashvith, On Mon, 02 Dec 2024 04:39:09 +0800, Ashvith Shetty wrote: > > There's a lot of builds happening (perhaps related to the Zig sub-versions) > when I try to build Zig 0.13 locally to test building a package of my > choice. Is there a way to navigate this blocker? I'm building them on my server so there're substitutes on [1], I didn't mention it before because it requires extra authorization. Thanks --- [1]: https://substitute.boiledscript.com
Re: guix package -i kicad will fait with #error "Unsupported CPU architecture" on my Talos II
Confimed, it is working. On Sun, 2024-12-01 at 15:50 +0200, Efraim Flashner wrote: > On Sat, Nov 30, 2024 at 08:59:02PM +, Ian Eure wrote: > > Hi Tobias, > > > > On Sat, Nov 30, 2024, at 8:18 PM, Tobias Alexandra Platen wrote: > > > When I try to install Kicad, I'll get the following output: > > > > > > The following derivations will be built: > > > /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > > 0.5b6f8b5.drv > > > /gnu/store/x26zsx3fw74vhfc35i79fansmlmhl0cc-libfabric- > > > 1.22.0.drv > > > /gnu/store/nfj2qvhyxvfc7x5fkdlyg2z1wnpqw9cz-openmpi-4.1.6.drv > > > /gnu/store/l1rbmwj9m4kgkm1qada665mm0m6g10w1-libngspice-43.drv > > > /gnu/store/y88c48hzcm78ch39wjfa3dpdgw9n6m7r-webkitgtk-with- > > > libsoup2- > > > 2.44.1.drv > > > /gnu/store/qv0zpz8h2dvhbmxz6smsbmc763rdkdxm-wxwidgets-3.2.5.drv > > > /gnu/store/llydl3baxardzgf9xmdbgjikny68vaar-python-wxpython- > > > 4.2.0.drv > > > /gnu/store/b0s2jgimknw6035kcqvpb6sdxkhakz7b-kicad-7.0.11.drv > > > > > > After a few minutes the build fails with: > > > > > > building /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi- > > > 1.0.1- > > > 0.5b6f8b5.drv... > > > \ 'build' phasebuilder for > > > `/gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > > 0.5b6f8b5.drv' failed with exit code 1 > > > build of /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi- > > > 1.0.1- > > > 0.5b6f8b5.drv failed > > > View build log at > > > '/var/log/guix/drvs/5r/inv8djwjz0bdami6nr6cm3zj382fsb-libcxi- > > > 1.0.1- > > > 0.5b6f8b5.drv.gz'. > > > > > > CC utils/read_lat.o > > > > > > #error "Unsupported CPU architecture" > > > > > > I also found a blogpost which mentions libcxi, what does libcxi > > > do? > > > https://hpc.guix.info/blog/2024/11/targeting-the-crayhpe-slingshot-interconnect/ > > > > > > > The package description provides a pretty good summary: > > > > Interface to the Cassini/Slingshot high-speed interconnect > > > > Libcxi provides applications with a low-level interface to > > the > > Cray/HPE Cassini high-speed NIC (network interface > > controller), also > > known as Slingshot. > > > > > I guess that libcxi is optional for Kicad, so I could hack guix > > > to > > > build Kicad without libcxi. > > > > > > > I think this is worth a bug report, and maybe you're also up to > > sending some patches? I think it's slightly more complicated than > > just the kicad package, though, since libcxi isn't a direct > > dependency: > > > > $ guix graph --path kicad libcxi > > kicad@7.0.11 > > libngspice@43 > > openmpi@4.1.6 > > libfabric@1.22.0 > > libcxi@1.0.1-0.5b6f8b5 > > > > So, I think what needs to happen is that libcxi needs to have > > POWER9 removed from its supported-systems field; and libfabric > > needs to conditionally include libcxi in its inputs based on > > architecture. I think the best way to do that is by checking for > > the build system in (package-supported-systems libcxi), which will > > avoid hardcoding duplicate arch tests in two packages. > > I pushed a patch limiting cassini-headers (one of libcxi's > dependencies) > to the architectures it supports, and then I adjusted libfabric to > check > the transitive-supported-packages. Kicad should now build again on > ppc64le. >
Re: Bootstrapping Zig with no binary blobs: status update and call for packages.
Hi Hilton, There's a lot of builds happening (perhaps related to the Zig sub-versions) when I try to build Zig 0.13 locally to test building a package of my choice. Is there a way to navigate this blocker? Regards, Ashvith
Re: bug#72686: Impossible to remove all offload machines
Hi Maxim, Maxim Cournoyer writes: Hi Ian, Ian Eure writes: [...] The only other option I can see would be to keep the existing filenames for user configuration, and declaritively manage different files -- like declaritive-channels.scm. This comes with its own set of problems, like needing to update the Guix daemon to read and combine multiple files; and the inability to know whether a given `channels.scm' is declaritively- or manually-managed means a bumpy upgrade path (ex. should this preexisting channels.scm file be left as-is, or renamed to the new name?) I'd think that be a great option to pursue, although it's more work more thoughts. Perhaps it could work along these lines (brainstorming) I like the idea to leave the original, potentially manually written file in place and complement it with a declarative counterpart. The same would also have benefited /etc/guix/acl, which suffers from the same ambiguity. Apologies for the silence, life stuff has been eating most of my free time, but I have a bit of bandwidth to spend on this problem again. I took a swing at this, it wasn’t as difficult as I expected. While this approach gives a smooth upgrade path for those who’ve configured channels in a stateful way switching to declarative configuration, it’s possibly bumpy for those already using a declarative config. If a machine with declarative channels is reconfigured, the channels will be duplicated from /etc/guix/channels.scm to /etc/guix/channels-declarative.scm. Using `delete-duplicates' on the merged channels should avoid major problems, but I think it still needs a loud entry in news and manual action (deleting /etc/guix/channels.scm) to upgrade. Given that both approaches will require manual action, I’m a bit inclined to go with the simpler, and take over the existing file. That said, I think the failure mode of the simpler approach (stomping on channels a user may have configured) is undeniably worse than potentially duplicating channels or continuing to pull in old ones unexpectedly. Do either of you have a strong opinion or more information which would help guide this decision? The root issue at work behind all these problems is that activation code only sees the desired target config, rather than the current and target configs. Comparing the current and target configs would allow the code to more precisely compute the needd change to move from one state to the next. I think that could be a good change to make, though it’s obviously going to be much more involved, and IMO will require discussion outside the scope of this specific bug. I have a draft patch series I hope to send up soon, but need to get Guix System up in a VM to test first. It does separate declarative channels into their own config, but doesn’t do the same for build machines. While I think many fewer users configure build machines than channels, it’s probably a good idea to use the same approach for both channels and machines. — Ian
Re: guix package -i kicad will fait with #error "Unsupported CPU architecture" on my Talos II
On Sat, Nov 30, 2024 at 08:59:02PM +, Ian Eure wrote: > Hi Tobias, > > On Sat, Nov 30, 2024, at 8:18 PM, Tobias Alexandra Platen wrote: > > When I try to install Kicad, I'll get the following output: > > > > The following derivations will be built: > > /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv > > /gnu/store/x26zsx3fw74vhfc35i79fansmlmhl0cc-libfabric-1.22.0.drv > > /gnu/store/nfj2qvhyxvfc7x5fkdlyg2z1wnpqw9cz-openmpi-4.1.6.drv > > /gnu/store/l1rbmwj9m4kgkm1qada665mm0m6g10w1-libngspice-43.drv > > /gnu/store/y88c48hzcm78ch39wjfa3dpdgw9n6m7r-webkitgtk-with-libsoup2- > > 2.44.1.drv > > /gnu/store/qv0zpz8h2dvhbmxz6smsbmc763rdkdxm-wxwidgets-3.2.5.drv > > /gnu/store/llydl3baxardzgf9xmdbgjikny68vaar-python-wxpython-4.2.0.drv > > /gnu/store/b0s2jgimknw6035kcqvpb6sdxkhakz7b-kicad-7.0.11.drv > > > > After a few minutes the build fails with: > > > > building /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv... > > \ 'build' phasebuilder for > > `/gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv' failed with exit code 1 > > build of /gnu/store/5rinv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv failed > > View build log at > > '/var/log/guix/drvs/5r/inv8djwjz0bdami6nr6cm3zj382fsb-libcxi-1.0.1- > > 0.5b6f8b5.drv.gz'. > > > > CC utils/read_lat.o > > > > #error "Unsupported CPU architecture" > > > > I also found a blogpost which mentions libcxi, what does libcxi do? > > https://hpc.guix.info/blog/2024/11/targeting-the-crayhpe-slingshot-interconnect/ > > > > The package description provides a pretty good summary: > > Interface to the Cassini/Slingshot high-speed interconnect > > Libcxi provides applications with a low-level interface to the > Cray/HPE Cassini high-speed NIC (network interface controller), also > known as Slingshot. > > > I guess that libcxi is optional for Kicad, so I could hack guix to > > build Kicad without libcxi. > > > > I think this is worth a bug report, and maybe you're also up to sending some > patches? I think it's slightly more complicated than just the kicad package, > though, since libcxi isn't a direct dependency: > > $ guix graph --path kicad libcxi > kicad@7.0.11 > libngspice@43 > openmpi@4.1.6 > libfabric@1.22.0 > libcxi@1.0.1-0.5b6f8b5 > > So, I think what needs to happen is that libcxi needs to have POWER9 removed > from its supported-systems field; and libfabric needs to conditionally > include libcxi in its inputs based on architecture. I think the best way to > do that is by checking for the build system in (package-supported-systems > libcxi), which will avoid hardcoding duplicate arch tests in two packages. I pushed a patch limiting cassini-headers (one of libcxi's dependencies) to the architectures it supports, and then I adjusted libfabric to check the transitive-supported-packages. Kicad should now build again on ppc64le. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Bootstrapping Zig with no binary blobs: status update and call for packages.
On Mon, Dec 02, 2024 at 07:19:11AM +0800, Hilton Chain wrote: > Hi Ashvith, > > On Mon, 02 Dec 2024 04:39:09 +0800, > Ashvith Shetty wrote: > > > > There's a lot of builds happening (perhaps related to the Zig sub-versions) > > when I try to build Zig 0.13 locally to test building a package of my > > choice. Is there a way to navigate this blocker? > > I'm building them on my server so there're substitutes on [1], I didn't > mention > it before because it requires extra authorization. > > Thanks > --- > [1]: https://substitute.boiledscript.com Also the substitutes on berlin (ci.guix.gnu.org) might need to be baked before they're served. So if it says there aren't substitutes it may be worth waiting a few minutes and asking again to see if they just hadn't been requested previously. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
