IRC channel logs
2024-02-08.log
back to list of logs
<peanuts>"GitHub - facebook/ocamlrep: Sets of libraries and tools to write applications and libraries mixing OCaml and Rust. These libraries will help keeping your types and data structures synchronized, and enable seamless exchange between OCaml and Rust" https://github.com/facebook/ocamlrep <ulfvonbelow>how does a "normal" non-guix cargo build look, anyway? I can't help but notice that guix-vendor/ ends up with a *lot* of stuff in it, even for packages with few immediate dependencies. Is this just cargo working as intended? Do no rust developers use small filesystems? <vagrantc>eeyk. nearly all platforms have been disabled for the linux-libre aarch64 kernel <oriansj>bumble: welcome to guix. The people are nice and the software is free as in freedom. there is much to learn, do and friendships to find. <ulfvonbelow>hmm, trying to package a rust thing and getting "error[E0554]: `#![feature]` may not be used on the stable release channel". Searching online suggests that it means I'm supposed to be using something called "nightly". Any idea what's up with that? <ulfvonbelow>how would one go about making an origin that downloads a git repository and packs it as a tarball? <ulfvonbelow>seems like just about any attempt to use tar in a snippet introduces module cycles <ulfvonbelow>this is a bit troublesome because it's not like I can just put the origin in as a native-input, since cargo-build-system specifically looks in the source field <cnx>herlot guix, could someone take a look at my vim version bump? i need it for janet file type recognition <amano>I cannot run something like element-desktop on guix? <amano>nix os just install element-desktop with yarn.... <amano>At least, nix os people know how to build element-desktop in an offline sandbox. <amano>I think guix people can also learn to package element-desktop. <efraim>I wonder if I can get rav1e to dynamically link to its library <cnx>amano, doesn't element pull dozens of packages from npm? <cnx>mirroring them locally isn't exactly offline _sandbox_ imho unless each is vetted <miro`>I looked in the logs of the file that guix brought me but the file is completely empty <cnx>nixpkgs basically go with `trust me bro' when pulling nodejs or go deps <miro`>And also when I do a guix pull, it pulls all guix each time which takes like 1 hour. <miro`>We can't just pull one channel? <efraim>looks like I should add rav1e to the list of packages which should be marked as tunable <cbaines>civodul, looking at the earliest bordeaux build, it happened on 2021-04-09 <natmeo>is there a reason there's no home services for databases (unprivileged, naturally) other than nobody has bothered yet? <wigust>natmeo: i think no reason, except you keep in mind that home services will start after user's login <natmeo>wigust: works just fine in my scenario <snape>there are very few node packages <oriansj>snape: because either 1) they were not needed or 2) no one has figured out how to properly bootstrap them yet. <theesm>vagrantc: replied to the issue regarding aarch64 a few hours ago; I'll fix the config as soon as I'll find time to do so today (and to test on my pbp)^^ maybe it'd be also a good idea to enable the platform support configs in extra-options of the arm-generic kernel packages to ensure they're present? <snape>I imagine having ~50 of them packaged means the concept works <oriansj>snape: huge work never stopped guix from doing crazy impressive things. Heck we bootstrapped from 256bytes in a master boot record on a disk that doesn't even have a file system. <snape>although not sure, maybe they are exceptions <oriansj>now if there was work no one was willing to do that would also be a valid option. <efraim>I have unfortunately come across a node package that I apparently need, haven't decided what to do with it yet <snape>well me too (lots of browser extensions) <oriansj>and more often then not depend upon binary blobs <ae_chep>speaking of binary blobs, Are we okay with packages depending on bytecode that resembles C header files? <snape>I imagine if it's readable and free, bytecode is fine <ae_chep>Okay, I hope the person reviewing my patch will agree :) <snape>ACTION is huge fan of org-babel <oriansj>ae_chep: well ask yourself a very simple question: did a human manually write that bytecode by hand and would manually updating that bytecode be the preferred form of making updates or fixes? <oriansj>because for the hex0 at the root of the guix bootstrap; we definitely hand wrote every single byte of the 256bytes by hand and added extensive comments for every single bit. Not to mention made sure there was a thousand different methods one could reproduce our binary exactly from the .hex0 documentation. <ae_chep>oriansj: they are generated and wouldn't be manually edited. But the language implementer (these bytecodes are for a self-compiling programming language) is allowing a java implementation of this language which we can use to generate the bytecode with. What if they didn't? <oriansj>well is the source code (supposedly) used to build that bytecode available under an FSF approved license? <efraim>'source code' is generally interpreted to be 'the intended method of editing the code', so autogenerated code doesn't generally count <ae_chep>I understand tho 'source code' argument and it makes sense to me <oriansj>and we enforce it with very few exceptions (for which we have plans on eliminating those exceptions) <ae_chep>oriansj: yes, and cbqn is available as a package in guix already. It's just a bit outdated because I have been slacking off, and its build process has been changing slightly and that's where my questiens are coming from <ae_chep>I should look into how other self-bootstrapping languages (available in guix) solve this problem <oriansj>ae_chep: we basically have a compiler or interpreter for that language written in a different language <oriansj>for example to bootstrap C, I wrote a compiler in M1 macro assembly. Which I bootstrapped M1 macro assembly in hex2, which was bootstrapped in hex1 which was written in hex0 which was built by the hex0 root binary. <oriansj>so gcc/tcc/mescc and all the rest could be built and written in C (just the subset supported by the previously built compilers) <ae_chep>Okay, I think it makes sense to not try to bend the rules then <ae_chep>I had the package definition updated that can rely on prebuilt bytecodes or the Java implementation. I'll go w/ Java only and submit a patch <oriansj>well it is easy for languages to have a proper bootstrap if they were created in the last 2 decades. (prior tends to be a different story) <oriansj>more often then not, you can go back in versions to find one which could be bootstrapped and then use that version to build a chain to the current version. (like the mrustc to current rust build chain) <oriansj>but sometimes actual bootstrapping requires a little code change because the author(s) cheated. (like when Bison shipped a new feature implemented in that new feature itself, so we had to reverse engineer and create an alternate implemention of that feature in a slightly older version of Bison to bootstrap it) <ae_chep>Does that mean two package definitions exist? 1) that relies on the presence of an older version to build itself and 2) the older version that requires on alternative implementations to build itself <oriansj>ae_chep: You can hundreds of versions of a language if needed (check out gnu/packages/rust.scm ) <ae_chep>Thanks for the answers. I'll have to pretend to work now but I've understood well how to package the newer versions of bqn <oriansj>thank you ae_chep for caring to do the right thing ^_^ <civodul>rekado: ouch, we shouldnât use those snapshots <civodul>i think last time we copied the tarball to ftp.gnu.org/gnu/guix/mirror <graywolf>Hello. This is probably stupid question, but how should (bootloader) and (file-systems) look like for a system configuration intended only for guix system vm? <efraim>it looks like cairo can only read SVGs but can read or write PNGs <cbaines>if anyone knows why running the bootstrap tar binary gives "Text file busy", let me know <cbaines>bash: /gnu/test/mfw5na8wxs4qs9rw229iinp2bz8hi3f8-tar: Text file busy <civodul>cbaines: does this file show up in âsudo lsofâ? <cbaines>ah, yeah, guix perform-download had it open for some reason <cbaines>I was considering trying to restart my laptop, and I guess that would have actually worked <civodul>you could also turn off the light and turn it back on <graywolf>How can I bake a guix home config into a VM created using guix system vm? <miro`>Can someone explain to me where the indentation error is, it must have been at least 15 minutes ÂŻ_(ă)_/ÂŻ that I've been searching but everything looks correct: https://paste.debian.net/1306691/ <futurile>miro`: do you have too many brackets ending your first channel? <miro`>in debian.past there is the channels conf if ever.. <snihil>hi Guix, is there a way to specify a key file within a (LUKS) mapped-device? Looking at the record definition seems to indicate this is still not a thing. Is this something the community is interested in or are there technical limitations preventing that? <graywolf>snihil: It is possible, my patch was merged few weeks back <snihil>graywolf: great! Not sure how I missed that :) <graywolf>snihil: I suspect you were looking at current version of the manual instead of the devel version. <graywolf>Google usually lands you on the current version. <graywolf>Notice the /devel/ in the url. In general you want to look into the devel version :) <graywolf>Hm, maybe "current" -> "stable", "devel" -> "current" would have been better phrasing <dariqq>anyone got an idea on how to easily clean up multiple invocations of guix import -r . I have now a lot of duplicates <apteryx>if the packages you added are in your local tree, and you use './pre-inst-env guix import -r', it should detect they are already there <dariqq>yeah should have done that. Now I have a 15k line file with multiple packages being defined 10 times or so <efraim>dariqq: if you're working on rust stuff you should work against the rust-team branch. Also the gnome-team branch I think has some newer gtk/gnome libraries <dariqq>yeah thats one of my problems currently that i need both newer gtk and newer rust <efraim>rust-team has 1.75, i'm not sure what the gnome branch has on it for newer gtk. I would suggest packaging an older version as one option <cbaines>apteryx, that cycle detector shouldn't be useful now that there's cycle detection in package-transitive-supported-systems <cbaines>both those approaches don't account for cycles introduced as part of origins though <apteryx>the cycle detection there only works on package cycles, not derivation cycles, according to a comment there <apteryx>so I though going back to your approach with a visited set on the package->derivation hot path would be more generally capable of detecting cycles <cbaines>it shouldn't be, since that also only looked for package cycles <apteryx>this is the tail of my log which I'm trying to make sense of; I think the cycle is between pkgconf-as-pkg-config and guile <apteryx>maybe because I'm defining the pkgconf packages via gexps, which introduces guile-final as input? <sham1>Hm, seems that the lightdm support is still a bit flakey. It doesn't find my desktop sessions for whatever reason even though I checked and they're where you'd expect them to be <alethkit>Should the bootstrap be taking over 2 hours to build? <apteryx>more than 24 h on my machine, I think <sham1>apteryx: that's exactly the issue. Annoying. Maybe I could just go with slim for the time being <alethkit>apteryx: Is there any way to avoid rebuilding it? this wasn't an issue prior to moving everything over to a new drive <apteryx>sham1: I had tried to debug it, but to no avail. I think it was using dbus to list the desktop files. <apteryx>I'm not too good at following execution when dbus is involved <apteryx>alethkit: I guess you need to authenticate the build farms to get binary substitutes <apteryx>maybe if you still have a backup you can put that file back into place <apteryx>guile-final depends on pkg-config; how is pkg-config built then? <rekado>alethkit: did you move /gnu/store to a new location? <alethkit>rekado: i moved everything else to a new drive, and ran `guix system init` from the previous drive whilst I mounted the new one to /mnt <rekado>alethkit: I see. Then you probably only need to authorize the build farm keys. <rekado>the manual explain how to do that with âguix archiveâ (as root) <rekado>does /etc/guix/acl exist? Is it empty? <apteryx>hm, build code of derivations is run by guile-final, while the guile builder used by build systems is guile-3.0; is this intended? <alethkit>rekado: I didn't know about guix archive, so I'll try that. I don't recall the bootstrap taking this long on my initial installation. Does the install ISO do something different? <apteryx>hm, nope, it uses guile-final in both cases... the default-guile procedure is exported by (guix packages) and refers to guile-final <apteryx>it's (guix gexp) which defines its own default-guile that refers to guile-3.0 instead <apteryx>by design according to a comment there <apteryx>trivial-build-system pulls in guile@3.0 for some reasons, compared to the gnu-build-system <rekado>alethkit: you shouldnât have to bootstrap from source. The installer asks whether you want to get binary substitutes from our build farm; it defaults to âYesâ. <rekado>alethkit: check the contents of /etc/guix/acl <rekado>janneke: on core-updates the snapshot URLs in (gnu packages commencement) have no stable hashes. We should probably host copies of these tarballs ⌠somewhere. <janneke>rekado: eek, that's weird -- it seemed to use to work on master? <janneke>possibly civodul has an idea what might have been going on, they suggested and created this possibility <rekado>IIUC the tarball behind these /snapshot URLs are generated upon demand and thus vary over time. <janneke>possibly, i just wonder how this didn't hit us before (or even right now on master)? <janneke>so i'm all for hosting them but let's ask civodul (tomorrow?) <janneke>(i'm afraid i just goofed-up something here) <rekado>if you still have the /gnu/store/sc029pj22sqkpqkdng7l6zc096g9sjsf-hurd-v0.9.git20230520.tar.gz tarball with hash 1m0lgk0741f3scib87130w1spc598zbz7gcc946wi7mg97h8d53m (new hash is 0ybmx7bhy21zv1if2hfdspn13zn68vki1na72sw2jj87gj8przna) then we could compare them to see what changed. <rekado>ACTION checks if its on ci.guix.gnu.org <janneke>ACTION goes to dig up older machine to check <rekado>no biggie if we canât do that. Weâll just check with civodul tomorrow to figure out a longer term solution for these tarballs. <apteryx>ACTION tried '#:guile %bootstrap-guile' on their pkgconf-as-pkg-config package, but that's not enough to break the cycle <janneke>is that the "guix system build bare-bones.tmpl" cycle? <apteryx>nope, it's an attempt trying to replace pkg-config with pkgconf, which somehow causes some cycle via gexp shenanighans (?), see the wip-cu-switch-to-pkgconf branch <apteryx>which I've been trying to debug for days <apteryx>its more correct interpretation of private fields in .pc files would allow us to stop propagating Requires.private fields <apteryx>I don't quite understand why there's no cycles when using pkg-config; guile requires pkg-config, and any building requires guile, such as building pkg-config should require <Tedium>I'm trying to make a package for OpenTofu, but go-build-system returns a "build constraints exclude all go files" error. Is anyone familiar with how to avoid that error? Code is here https://paste.debian.net/1306715 <apteryx>so it seems like we wouldn't be able to build pkg-config in the first place, unless our default-guile somehow avoids having pkg-config as input, which is not what I'm seeing (I may have gotten confused though) <apteryx>e.g. ,pp (package-transitive-inputs (default-guile)) -> contains pkg-config among others <janneke>rekado: i can only find "git20230520" as a version for mig? <janneke>ACTION checked in git log -p -- gnu/packages/commencement.scm gnu/packages/hurd.scm <apteryx>,pp (package-transitive-inputs pkg-config) suggests the builder uses /gnu/store/4p1l5bdxxbyyqc3wh0d07jv9rp1pdcy7-guile-2.0.14 <rekado>hurd-headers-boot0 has 0.9.git20230520 <theotherone>Hey guix people, I am trying to switch from use-package to guix for my emacs configuration. Are there potential issues when you use both tools side-by-side? I've noticed some errors when activating packages, e.g. "Unable to activate package âlsp-modeâ. Required package âdash-2.18.0â is unavailable". Could that have something to do with some packages coming from use-package while others come <theotherone>from guix? I am a bit lost... (Both lsp-mode and dash are installed using guix) Any guidance is appreciated :) <janneke>rekado: ah right, core-updates -- my bad <rekado>theotherone: Iâm on Guix System and I use use-package in my Emacs configuration (I also use Guix Home). I havenât had any problems with it, nor do I do anything unusual. My init.el just says (require 'use-package) and then I use it. <apteryx>I think problems can occur if you're mixing guix and emacs packages (installed via M-x package-install) <apteryx>stick to guix-provided ones to avoid problems <rekado>janneke: the bad hash is 1m0lgk0741f3scib87130w1spc598zbz7gcc946wi7mg97h8d53m, and it appears in commencement.scm as well as hurd.scm. It looks fine in hurd.scm. <theotherone>Hmm, then something may be of with my init.el. Thanks! <janneke>rekado: i cannot find the tarball anywhere; i'm starting to believe it may never have existed and the hash is just wrong <rekado>janneke: but I must say that Iâm a little confused about the behavior. I only ever got this error with â./pre-inst-env guix build --system=i586-gnu hurdâ while attempting to offload to a childhurd. <rekado>I just get the expected checkout with ./pre-inst-env guix build --system=i586-gnu -S -e '(@@ (gnu packages commencement) hurd-headers-boot0)' <rekado>(even when I make the hash invalid, which I find surprising) <yeikoff>Hi there. I'm trying out guix. Is there a way to get a `guix shell` with a particular environment variable exported to it? <yeikoff>I've managed to get an env variable through the search paths, but I need it to be a given string, not a search path. <ieure>yeikoff, Environment from the shell `guix shell' is launched from are visible by default. What exactly are you doing and what's the `guix shell' invocation? <viperML>I guess something to be configured within a shell.scm? <janneke>rekado: i'm pretty sure that i used the --source variant to "check" the hash <janneke>so i would suggest to change it to what the --system=i586-gnu offload expects <ieure>yeikoff3, `FOO=hi guix shell' then `echo $FOO' in that shell and it'll print "hi". <janneke>it would be (more than) nice to have the --source build check against the same hash, this is surprising indeed <alethkit>Rekado: i have, only one entry is present <yeikoff3>I'm trying to figure out if guix is a viable package manager for lua + fennel <yeikoff3>I've managed to get some lua and fennel libs into ~/.guix-config/share/lua/x.y/ <yeikoff3>but the default lua path points to /usr/.* <yeikoff3>thus I would like to set the LUA_PATH programatically <ieure>yeikoff3, I'm not sure of the best approach for this, you can probably look at similar things (like Python and how the PYTHONPATH is managed) for ideas. <yeikoff3>Thanks. Yeah. I am thinking that the env variable should be configured within the package definition of lua. <yeikoff3>But, while the LUA_PATH looks a lot like a regular path, it is not. It's a string, ending with "?.lua". So I cannot set my env variable from within a search-path-specification. <yeikoff3>Because it's not a directory nor a file. But a particular string <yeikoff3>The other option would be, bringing files from the ~/.guix-profile(...) into the current directory. Is that possible? <janneke>rekado: i wonder how "./pre-inst-env guix build --system=i586-gnu -e '(@@ (gnu packages commencement) hurd-headers-boot0)' " built for me <janneke>walking through the `-d' derivations, it mentions that tarball that i don't have, similarly for gnumach-headers-boot0 <darkexior>hello! im using an nvidia rtx 2060 super. my screen is currently yellow after finishing intallation? is this a driver problem? <darkexior>if so, how do i install drivers for gnu linux? <darkexior>i already checked if its the cable, and if its the monitor, it seems to be the OS and the hardware <tschilp>This might be better for the emacs channel, however I guess it's quite some emacsens here. I have an async function in my init.el, which worked nicely until very recently: http://paste.debian.net/1306720 <tschilp>The command itself works completely OK, if I run it from bash. Any points to get started fixing? <tschilp>This is on Guix system d3c3922a8f5d50855165941e19a204d32469006f <tschilp>with emacs, emacs-ement, and pantalaimon set up via guix home and gnome via system configuration. <darkexior>hello, now i realize that maybe its the windowing system x11 thats turning my screen yellow becausei switch between the ttd with the windowing system and the ttd with no windowing system and then back to the one with the windowing system and the yellow goes away, its only until i log in the user that the screen turns yellow, somebody please help if <ekaitz>futurile: question from the patches discussion! i reviewed a patch, but I don't have commit access, now what? <apteryx>rekado: were you able to use b4 shazam? <apteryx>it basically should just work with 'guix shell b4 -- b4 shazam <message-id>', which you can now easily retrieve from mumi <hutzdog>Is anyone else having intermittent connection issues with the Guix websites and substitute server? <rekado>apteryx: I havenât tried it yet, but I intend to do that on the weekend <ieure>hutzdog, It's been my experience (as a user and sometimes contributor) that the Guix infrastructure isn't quite in the place it needs to be, reliability-wise. <apteryx>why doesn't ',trace' work from 'guix repl' ? <apteryx>its output goes to /dev/null, or so it seems <rekado>hutzdog: the connectivity of the build farm at ci.guix.gnu.org is excellent, but ISPs donât necessarily pass that on to their customers. <rekado>since we donât have a network of mirroring servers that you could connect to instead, the impression you may take away from this is that connectivity is not great â dependent on what ISP you use. <civodul>apteryx: itâs because âguix replâ starts with the âregularâ VM engine (as opposed to the âdebugâ VM engine that you get when running âguileâ without arguments) <hutzdog>Ah, I see. I'll check the manual and see if I can change to a different mirror <apteryx>civodul: oh, is there a good reason for that? <apteryx>(other idea: ,trace in Guile could warn: hey, regular engine used, trace won't output anything)