<KE0VVT>So I need to re-download the binary? <lfam>The SELinux policy file (guix-daemon.cil) is contained in it <lfam>So, if you want that file, you should download the binary tarball again <rekado_>the cil file was written for an old version of Fedora <rekado_>well, it was reasonably fresh at the time <rekado_>but by now it sholud be horribly outdated. <the_tubular>Is this me or shepard is blazingly fast compared to other init system ? <the_tubular>I've never seen a system boot as fast and the specs of this system are pretty dated <KE0VVT>the_tubular: Shepherd was slower than systemd last time I booted GuixSD with GNOME. <char>the_tubular: I don't know if it is shepherd, but I have also noticed that guix starts very fast. <jgart>In other words should it be changed to define instead of define-public and just exported? <jgart>s/Since it is already included in the exports/Since it is being exported from the module and using a define-public form <the_tubular>char maybe you are right, it could be irrelevant to guix <char>the_tubular: I'm not usig libre due to hardware issues, so it isn't that either <GNUtoo>apteryx: guix build --sources=all git-repo gives me that: /gnu/store/3bpy0k170ls57j7iaka035d2ad2vqhvw-git-repo-2.4.1-checkout ***califax- is now known as califax
<jgart>iskarian, Ok, I'll send a patch to update that <the_tubular>What does that mean when I guix pull : listing Emacs sub-directories... ? <jgart>I tried this the other day. Quite comfy with broot: <jgart>`broot $(guix build bitmask)` <jgart>just wanted to share in case it's useful for anyone else <jgart>The usual is to use `tree $(guix build bitmask)` or `ls $(guix build bitmask)` <apteryx>GNUtoo: oh, sorry it seems it rather should be: guix build --sources=transitive git-repo <apteryx>'all' seems to mean to take both the source of the package as well as any other input used as source <apteryx>it only looks at the current package; transitive looks at its closure. <KM4MBG>jgart: thanks for the hint. broot looks cool, but not packaged for guix yet. Something for the list! ***KM4MBG is now known as jackhill
<jgart>KM4MBG: Definitely, definitely <jackhill>I am curious about the origin of the name now. <jgart>tig and git-interactive-rebase-tool make nice tools in the git toolbelt <jgart>the ui looks nicer than poezio, imho <jgart>but no omemo yet. They're working on it in a branch <jackhill>cool, I've been using profanity for my terminal xmpp needs <jackhill>I've been using it with a guix pack on a non-guix system actually. Something I have to investigate there, it doen't like non ASCII. Maybe a locale is missing in the pack? <jgart>what guix pack output are you using? <jgart>what system were you using it on? <jgart>jackhill, have you tried the deb archive output yet? <jackhill>jgart: I have not, but it's on my list to try. Looke neat! Not approprate for this system though, as I don't have root. <jackhill>What's more likely is that we actually get guix going on it though. <dragestil>is the guix info manual available for downloading somewhere? <dragestil>hmm, but makeinfo complains about missing files like version.texi <mothacehe>not much, trying to have a few more packages to build on core-updates :) <civodul>i haven't done much in this area over the last few days <jgart>Hey Civodul! I saw you released a new version of guix-jupyter. <jgart>Have you tried/tested launching a notebook preconfigured with the guix kernel as default instead of selecting the guix kernel when it launches? <civodul>mothacehe: the Common Lisp patch LGTM! <civodul>jgart: i haven't tried that, it'd be interesting <jgart>civodul, would you like me to upgrade guix-jupyter in guix? I could use the upgrade too in upstream since I'm testing things with it. <jgart>MultiKernelManager.default_kernel_nameUnicode takes a string <jgart>it's set to python3 by default <civodul>i don't think we should change the default in our "jupyter" package because that'd make it behave differently than those of other distros <civodul>and i'm not sure upstream would be interested in changing the default :-) <civodul>but i guess that's a useful tip for the personal config of those who use Guix-Jupyter <jgart>yup, I also think that wouldn't be a good idea for general jupyter users <jgart>declarative and reproducible Jupyter environments - powered by Nix <jgart>I discovered it today. I'm just studying it a bit to see how it works <jgart>> In practice, a Jupyter environment is defined in a single shell.nix file which can be distributed together with a notebook as a self-contained reproducible package. <civodul>jgart: no i didn't know about this one, i don't think it existed back when we started working on Guix-Jupyter <civodul>AIUI, it's akin to running "guix environment --ad-hoc jupyter python-ipykernel ...", no? <civodul>so it's still non-self-contained notebooks <civodul>(actually, i wonder why they need something special at all to achieve that, weird) <brendyn>There is also version 5.23.0 since 20 days ago so im not sure why you updated to 5.21 <vivien>Hello, I’m trying to get date->string from srfi-19 to return the locale date (without time). Is it even possible? <vivien>(the date according to the locale) <jgart>> "guix environment --ad-hoc jupyter python-ipykernel ...", <jgart>yup, but with nix-shell. I haven't studied the internals of how nix-shell works. I imagine it's similar to `guix environment ...` <jgart>not considering the cli goodies that guix has, of course ;) <civodul>jgart: maybe the reason they need this library is because Nix doesn't figure out JUPYTER_PATH automatically or something <civodul>vivien: hi! yes, data->string returns the date in the current locale <vivien>civodule, it also returns the time <civodul>ah, then check out the various format strings for date->string <civodul>maybe more of a topic for #guile actually :-) <vivien>I haven’t found any format for that <civodul>there are quite a few flags to choose from <vivien>Yes, but I know some locales have the day and day number swapped and I’d like to use the locale information for that and not compose that format myself. <vivien>~c does it automatically, but it’s the only one to do it, and it has the time <civodul>does locale data actually have info regarding d/m/y order? not sure <civodul>maybe you have to use strftime instead of date->string <vivien>Oops, ~c has the order backwards too <jlicht>civodul: all great, pretty excited about the next round of core-updates coming to master Real Soon (tm) <civodul>vivien: see also locale-date-format in (ice-9 i18n) <rekado>gotta check tlpdb to see what package should provide it, but I’m guessing that it’s a core part of the base LaTeX installation <vivien>civodul, OK locale-date-format works <rekado>mothacehe: I’m setting up my clone of core-updates, and will then fetch the tlpdb from texlive-bin on core-updates, and then search for that file. <civodul>it could have to do with the recent TeX Live upgrade <mothacehe>rekado: thanks for your help, I'm quite a TeX Live noob. <mbakke>the latest version fixes it, OK to update? <bricewge>ATM modifying "set-xorg-configuration" is very awkward, being able to modify a service by name would made this simpler. <bricewge>But "service-type-name" field state it's "for debugging". ***califax- is now known as califax
<rekado>unsurprisingly, the l3backend package should contain the file. <rekado>our texlive-latex-l3backend does include the file <rekado>it’s not propagated anywhere, which I feel is a mistake. <rekado>but for the time being we should be able to fix this particular problem by including texlive-latex-l3backend in the texlive union for r-with-tests <rekado>we’ll need to package grfext as well <vivien>Removing linux-libre 5.12 broke the project that must not be named. <rekado>vivien: report it to them instead <rekado>mothacehe: I have two commits to fix this. Should this go to core-updates and then cherry-picked to core-updates-frozen? <mothacehe>rekado: oh great! yes that would be perfect. <rekado>okay, pushing to core-updates now <rekado>…and pushed the two commits to core-updates-frozen <GNUtoo>apteryx: thanks a lot, I'll try it now <bauermann>rekado, thanks for fixing this! I’ll look into propagating texlive-latex-l3backend today. <GNUtoo>I've many /gnu/store/* that look like source code <mbakke>rekado: I don't think you have to push to both branches, I suppose we'll merge -frozen into core-updates regularly. <mbakke>speaking of merges, we should get 'master' into 'core-updates-frozen' for the PHP update... I can probably give it a go later today. *mbakke developed a habit of pushing core-updates fixes through 'master' when appropriate *civodul embarks on pytorch packaging as a silly way of procrastinating <guil>Hello! I'd like to contribute to the main guix channel. I've made a package for vimpc, a TUI mpd client like ncmpcpp. <dstolfa>if you have any questions, feel free to ask here, i'm sure plenty of people here are happy to help <rekado>mbakke: okay. I’m not very familiar with the new process. <rekado>bauermann: oh, are you working on TeX Live things in Guix? <mbakke>bauermann is our new TeX Live hero :-) thanks for the 2021 update! <bauermann>rekado, I did the update to TeX Live 2021, for better or worse :-) <mbakke>dstolfa: not yet, but you can beta test by running 'guix pull --branch=core-updates-frozen' ;-) <mbakke>you may want to wait a few hours for the build farm to catch up first <dstolfa>mbakke: will give it a try later today, thanks! <pineapples>I see that a Mesa patch hasn't made it into core-updates in time :-( <bauermann>mbakke, you're most welcome. I enjoyed working on the update <civodul>rekado: luck is exactly what one needs when packaging this kind of stuff <guil>Should I only use tarballs or Am I allowed to use git repositories as well? <rekado>bauermann: for the next core-updates cycle it would be great if we could review the existing packages and ensure that they include all files that texlive.tlpdb mentions. <rekado>we also need some improved tools and abstractions <rekado>the simple-texlive-package, for example, still requires a lot of manual overrides, which I’d like us to get rid of in the future <rekado>(especially for the easy case where a dtx file is supposed to be unpacked and files are to be installed into a well-known directory) <bauermann>rekado, nice, those sound like interesting projects. I added them to my notes and will look into the simple-texlive-package easy case “soonish” :-) <bauermann>rekado, one thing that is on my mind is switching texlive-bin to build from the SVN tag rather than the tarball. that way we would pick up post-yearly-release fixes. there are a few patches on the newer 2021.x tags already. what do you think? <bauermann>guil, AFAIK you are allowed to use git repos because some existing packages do that, but I’d also like to know about whether there’s any preference in the Guix community between tarball vs repo. <mothacehe>fixing build-system issues allows to have thousands of packages fixed with a single commit, quite satisfying. <rekado>bauermann: taking the source for texlive-bin from SVN sounds like a good idea. <rekado>bauermann: an example of a package that would benefit from a revamping of simple-texlive-package is the new texlive-grfext <civodul>mothacehe: plus, it looks like a left quite a few such "satisfaction opportunities" :-) <rekado>I had to override quite a few arguments and even then there are too many files that are installed. <mothacehe>civodul: hehe, yes any java or go experts around :p ? <rekado>the Honeycomb boards I ordered in May are delayed even further. <rekado>I asked SolidRun about the status (previously delayed to “end of July”); now they say they will be delayed until the end of August. <civodul>rekado: uh, that inspires confidence <roptat>mothacehe, java "expert" here :) <roptat>uh, the cuirass website doesn't like my typos "sytem:x86_64-linux" returns an empty page <mothacehe>roptat: regarding the Cuirass issue that might deserve a bug report :) <apapsch>me to boss: "I need to publish this guix channel under gpl" boss: "why?" me: "guix itself is gpl licensed and I don't have to fiddle with git authentication" boss: "just do it!" <rekado>my license recommendations went similarly smoothly <roptat>mothacehe, it's not classpath failing, it's ant-bootstrap <rekado>there’s also the other side of it: want to make a commercial product out of this? You can! It’s all free software, so you have the rights to turn it into a commercial service without having to ask anyone for permisssions. <rekado>my boss was very happy about the simplicity of it all. <apapsch>rekado: it's great there's a big mountain of free software and I'm happy to add to it. The argument against publishing is often "competitors might copy it and succeed before we succeed" <muradm>maybe <lclmount> and <umount> should be specified explicitly?.. <muradm>config specifies <cryptmount> and <cryptumount> only <roptat>it looks like the issue is after generating the rule file, when creating the content of the etc directory <roptat>I suppose /gnu/store/sx6vcxa2lpk156mn72id2l3f0a778ccm-* corresponds to the rule file? <muradm>name is /gnu/store/sx6vcxa2lpk156mn72id2l3f0a778ccm-pam_mount.conf.xml <minikN>roptat: I fixed my issue with the WSL script finally. Thought to let you know. <minikN>The issue was actually simple to fix once I realised it: In my base-system.scm I used stuff from other channels, but I never declared the channels I used (for the reconfigure command). So what I ended up doing was to simple add this (https://paste.debian.net/1205947/) to the shell script invoking the command <muradm>from gnu/services/pam-mount.scm it looks like cryptmount/cryptumount are hardcoded and mandatory although i'm not going to use them <muradm>and there is no lclmount/umount at all <roptat>minikN, I see, that's why it was working well for me: I simply removed the stuff that depended on that channel because I don't have it <roptat>muradm, I don't think that's the issue: the rule file was generated after all <minikN>Yeah I never thought about that because the error was about something completely different <nefix>Hello! I've built a derivation in a server, exported with `guix archive` and then imported it into my laptop. It appears in the store, and I can install it through `guix install /gnu/store/path`. However, if I try to use it in a `guix environment`, it tries to build again the whole derivation. Am I missing something? Thanks! :) <civodul>nefix: hi! does 'guix build the-package --no-grafts' show the same derivation? <nefix>civodul: in my laptop it tries to build it entirely <civodul>ah sorry, i mean "guix build the-package --no-grafts -d" <nefix>I guess that with `git pull`ing both it will work out, right? <nefix>Also, is there a way to specify `guix environment` arguments? I'd like to execute something like `guix shell` and then automatically jump to my environment with everything. Is a shell script the answer? <muradm>roptat: any idea what to look at? <nefix>And a third question: is .bashrc always sourced? (even with the `--pure` argument?) <roptat>not really, I'd look at the etc-service-type, that generate the etc directory, to see what can result in "permission denied" <roptat>maybe there's actually another service that has already created a rule file previously, and it doesn't have permission to overwrite it? <muradm>roptat: i had pam-limits-service also, when i move it before pam-mount-service-type i get "In procedure symlink: File exists" <roptat>interesting, so the two services are not compatible? <muradm>limits are: /etc/security/limits.conf <muradm>pam mount is: /etc/security/pam_mount.conf.xml <muradm>both create /etc/security/ directory which is conflict point? <rekado>the collapse of the wave function is where functional beauty is translated to state <muradm>roptat: one or the other works, not both <the_tubular>Guix is install, but I can't start the guix daemon right now <muradm>roptat: looking at the code, I would say that problem is with pam-limits-service-type gnu/services/base.scm:1385, this is where limits.conf is defined in let, it calls mkdir directy. while pam-mount-etc-service defines its config as "security/pam_mount.conf.xml" <minikN>Are you trying to install the package manager or guixsd? <muradm>roptat: so, i would be fixing gnu/services/base.scm:1385 <muradm>pam-limits should not own "security" but "security/limits.conf" <the_tubular>That's also what I followed, minikN It worked like for 1 day, then it stopped wroking after I got a blue screen (Gotta love Windows...) <minikN>Maybe try invoking the guix-init.sh script again with the given command <the_tubular>minikN, It seems to work ... ? I have no clue what I did differently <minikN>Was the error you had before this: guix system: warning: while talking to shepherd: No such file or directory ? <roptat>muradm, would you mind sending a bug report? I can't act on it right now <cwebber>I pushed origin/wip-setuid with a rebased version. It looks like we've (including bricewge) done all the changes civodul requested earlier. <cwebber>is there any problem with me pushing to master? <cwebber>I guess I'll update the issue saying just that <bricewge>Is there an issue already tracking postfix status in Guix? <cwebber>then there was some conversation on guix-devel on the "wip-postfix" and "Setuid programs" threads <cwebber>(actually I said earlier that the tests all pass; I mis-saw my terminal, they're still running. Letting them run before I merge this one in.) <raghavgururajan>brendyn: Ah, sorry, I missed that patch-set as it was closed. I updated to 2.21 because versions after that seems to require newer sqlite. <leoprikler>for the record, what's the state of sqlite on cu-frozen? <apteryx>bricewge: heya! Thanks for the setuid work! Unfortunately it broke 'guix pull', it seems. <vivien>(oh sorry it looks like what apteryx is writing) <apteryx>there's a missing dependency error for (gnu system setuid) in (guix modules) <vivien>Previously a reconfigure messed with my system user ids <cwebber>somehow when pull in in the patch series (which had hit a conflict) <cwebber>it was in my checkout without being committed. <apteryx>OK! no worries, thanks for the prompt resolution. <GNUtoo>Ah we just need to guix pull then, thanks for the fix <vivien>So I have a specific user to run a service, and the shepherd service creates a bunch of directories in /var/cache, /var/lib and /var/log <vivien>But it seems that that system user got a new ID because the old files are owned by a mysterious "968" user <vivien>I can fix it easily with chown though <vivien>Maybe it was a bug in my service though <GNUtoo>It's also part of the tradeoff with rolling release (more risk of breakage but very recent software, more people wanting to contribute to get the result of the contribution immediately, etc) <jorge[m]>Hola,por favor al que pueda colaborar de revisar estos 2 reportes en paste 1205873 y 1205874. <zacchae[m]>Anyone do any machine learning on guix? Most ML uses CUDA which is proprietary, but there seems to be a push to support for AMD/ROCm, which, correct me if I am wrong, is free software. <zacchae[m]> * Anyone do any machine learning on guix? Most ML uses Nvidia/CUDA which is proprietary, but there seems to be a push to support for AMD/ROCm, which, correct me if I am wrong, is free software. <civodul>zacchae[m]: hi! that would be great, because NVIDIA is so terrible <civodul>perhaps we should start by packaging it? <zacchae[m]>I'm actually still trying to verify that it is free software. I have heard that AMD is much more free software friendly, but I want to make sure everything is gucci <zacchae[m]>This seems like a pretty important thing to address. Machine learning/AI is becoming a larger and larger part of society, so there really needs to be a free software path to using ML/AI <zacchae[m]>I see the kernel driver is distributed under a modified GPL licence <civodul>i agree not having proper ML support is becoming more and more problematic <civodul>yet, i wonder about the extent to which ML applications are "good for society" <civodul>i'm biased because i'm mostly concerned about its application to surveillance <zacchae[m]>civodul: I think the point is that ML/AI are here to stay, so better for it to be free and open than in the hands of a select few. <zacchae[m]>Though as an AI/ML researcher, I may be a bit biased :P <leoprikler>Even if you make all of it free, those who have more hardware can do more stuff with it while you're still trying how to best breed your anime pfp. <vivien>Not necessarily, it’s also about the data. <leoprikler>I think we can safely agree, that governments and tech giants have more space for data (as well as more data) than you could hope to amass individually. <vivien>There are legitimate use for machine learning. Have you noticed how tedious it is to always tag your activitystream activities? Well, you could do a lot of it with ML. <vivien>leoprikler, yes, Amazon has a lot of fake reviews, facebook has a lot of bots to learn from. <vivien>That does not necessarily improve things ^^ <vivien>But all jokes aside, solving big corporation having a lot of data is a different fight <leoprikler>Even when there is a legitimate use, ML suffers from the fact that it's by design about as obscure as proprietary software. <leoprikler>Like, even if you understand the maths behind it (FSVO "understand"), you can typically not 1. introspect the state of your AI at any given moment 2. reason about it meaningfully. <vivien>That’s for a very specific type of machine learning though. <leoprikler>Well, it's the "very specific type of machine learning" that people typically mean when talking about machine learning. <vivien>So, let’s not do that and let’s do more useful machine learning with guix. <leoprikler>What exactly do you think about when you say "more useful machine learning"? <vivien>Well, knowledge extraction that you can do with reasonable hardware and reasonable data :) <zacchae[m]>leoprikler: Useful applications of AI: brain-machine interfaces, especially for the differently abled (blind, unable to use certain limbs). Text to speech for various reasons. Home security systems. Any and every medical diagnosis ever can probably be better done with AI <zacchae[m]>More and more medical diagnoses are made with AI as they beat out human doctors. Brain machine interfaces, as scary as that sounds, will probably become one of the most integral pieces of society. <vivien>Also we would use the fast linear algebra systems just like people doing non-AI things, like fluid dynamics simulations and so on <zacchae[m]>My point being, that yes, the free software community should really care about enabling free development of AI/ML tools <leoprikler>I find it hard to believe that a society that lets homeless people starve to death will somehow produce brain machine interfaces for the masses under ethical circumstances. <vivien>Well, a society that lets homeless people starve to death invented the internet <leoprikler>I'll grant you TTS/OCR, that is useful and can be done reasonably well even with bad data. <zacchae[m]>leoprikler: I'm not sure about the production being "ethical", but I nor any reasonable person is going to attach things to their brain unless they are convinced that it is safe. Yes, people don't care much when it comes to things like phones, but you can bet I'm not letting any proprietary software near my noggin <zacchae[m]>phones aren't as obviously connected to your brain <leoprikler>I know it's a meme that the medical system in the US is fucked, but even in the enlightened countries of Europe there's lower tier healthcare. <zacchae[m]>I live in the US where not even vaccines are mandatory during a global pandemic. So yes, I will have a choice. Admittedly, I can't really say for future generations <leoprikler>I mean a choice between a free software implant and a proprietary one, not between a proprietary one and "go fuck yourself" <zacchae[m]>For any current designs, the brain machine interface is more of a relay than a computer sending (an sometimes recieving) arbitrary sensor data. The free software part would come into play on the external device that is controlling it. So yeah, free software is on the table. <zacchae[m]>The design of the physical sensor would need to be relatively transparent if people are going to use it anyway <leoprikler>So I take it your hospital has already upgraded to Windows XP. If not, I struggle to see your enthusiasm, we are masters at gating hardware behind proprietary drivers. <zacchae[m]> * For any current designs, the brain machine interface is more of a relay than a computer, sending (and sometimes receiving) arbitrary sensor data. The free software part would come into play on the external device that is controlling it. So yeah, free software is on the table. <leoprikler>Commas are important, but I don't think I misunderstood you based on a lack thereof. <leoprikler>How that arbitrary sensor data is relayed to other machines is very important and we both know that there are ways to make it difficult for free software to access properly. <zacchae[m]>leoprikler: I forgot that in IRC, it repasts the whole comment. In matrix, I can edit in-place. For context, Neuralink uses a standard bluetooth connection. Based on my success with bluetooth on guix, I'm relatively confident that I can freely get the data to python (and from there, the world!) <leoprikler>Well, apart from the thing that publishing health-related data to the world is probably a bad idea, that may be fine. <zacchae[m]>I was going more for a "tap into the matrix"/"mad scientist" vibe, but yeah probably won't be broadcasting raw data like that ***iyzsong- is now known as iyzsong
<leoprikler>Well, call yourself a mad scientist, but German criticism speculates about a "brain cloud" collecting your thoughts, so… <leoprikler>(taken straight from Wikipedia, so apply a grain of salt) <zacchae[m]>leoprikler: "brain cloud" sounds like the human singularity merging all of mankind through machines. Sounds good to me ***Kimapr7 is now known as Kimapr
<rekado>we have a number of good ML applications for diagnostics <rekado>it’s a point of embarrassment for me that we can’t package these (and can’t easily replace the CUDA stuff). <rekado>(Maui probably even works without GPU acceleration.) <civodul>apteryx: xnnpack is a neural network thingie that pytorch depends on <civodul>rekado: oh indeed, i can sympathize with being embarrassed <civodul>i've just pushed the pytorch dependencies that were missing, so we should be able to provide it (CPU) Real Soon Now <zacchae[m]>rekado: It looks like your codes use tensorflow, which now has AMD/ROCm support, so it may not be difficult to package them freely anymore. Though, there are a lot of other codes in your requirements.txt, so I'm not 100% sure <civodul>zacchae[m]: don't tell rekado about tensorflow ;-) <civodul>rekado packaged tensorflow v1, which was quite a bit of a challenge <civodul>but v2 can only build with Bazel, and Bazel can only build with itself <zacchae[m]>also, I should reitterate that I haven't completely verified that AMD/ROCm is totally free software compatible, but it seems to be the case <rekado>it would not be a good look if I started to write Python code <rekado>someone suggested we should evaluate gradient boosting instead of jumping straight to deep learning. <rekado>I agree not because I understand why, but because it gives me an excuse not to write deep learning code. <leoprikler>rekado: what's the problem with aiscm? It appears to use the GNU build system at least <leoprikler>in terms of dependencies, we might need to package clearsilver, but the rest is also there <leoprikler>ahh, clearsilver appears to be a packaging nightmare though <nefix>Hello! I'm struggling to use C++ standard library, specifically the "<limits>" package. It shows the following error: /c++/limits:42:10: fatal error: 'bits/c++config.h' file not found. Does somebody know what am I missing? Thanks! :) <nefix>I'm creating a pure environment with `gcc-toolchain`, but it doesn't seem to contain the required file <GNUtoo>nefix: do you have the commands to run (guix environment --pure gcc-toolchain?) and example C++ file? <monego>rekado: i sent patches for xgboost and lightgbm (gradient boosting libraries in both C++ and python) a while ago <monego>they compile fast, have few dependencies, and it's easy to separate the c++/python interfaces <Noisytoot>openttd-opensfx seems to be the only package licensed under it <leoprikler>yep, zig should compile C code as well as zig code <GNUtoo>ah yes it's the zig language which can also compile C / C++ for many architectures *GNUtoo likes the idea of having clear runtime / compile time separation in the code