IRC channel logs
2024-01-06.log
back to list of logs
<apteryx>these are guile modules grouped and compiled for computing derivations <apteryx>such as when using gexps with 'with-imported-modules' <loopback___>did a guix build --sources on a module-import-compiled.drv and it listed the same version of perl sources twice, one a tar.gz and the other a tar.xz. Seems to happen often. Do dependencies have their own copies of others? <apteryx>loopback___: that's a source derivation that got patches applied, then was repacked in a tar.xz <podiki>getting a new home server and will put guix on it... <podiki>ACTION stares at many outdated and pending patches for all sorts of server stuff <aarcov>I'm trying to make a guix package for an older rust crate (specifically this one: https://github.com/mindsbackyard/galvanic-mock) that uses a feature that has been now moved to mainline rust and am trying to add a snippet to remove some specific text from the source files (specifically '/src/lib.rs' and '/tests/*') <aarcov>When I try to build it doesn't seem to be removing the '#![feature(proc_macro)]' string like I need it to <ieure>aarcov, Why not use a patch? Or you can add a build step that calls (substitute* ) instead of using a snippet. <ieure>aarcov, Guess I'd start by trying that substitute* call in a repl to make sure that does what you want. Maybe the snippet is running, just not doing what you expect. <hapster>I am trying to define a package for the mixxx-2.4-beta (dj software). The current stable is already packaged (2.3.6) and I copied all fields except for the version tag which I changed accordingly. Now, after downloading all required dependencies, I run into "guix build: error: while setting up the build environment: getting attributes of path `/etc/services': No such file or directory". <hapster>And thus I have reached the end of my guix foo. I've tried applying the wisdom of "Dissecting Guix" (part 1) to peek into the derivation, but this way I ran into other problems I was unable to solve: `(with-store %store (run-with-store %store "/path/to/derivation.drv")) ` returned "wrong type, struct expected". <hapster>Do you guys have any suggestion how I can approach this? <hapster>tsmish: No, I don't have that file. So you mean that simply creating the file will make the error go away :D? <tsmish>hapster: is it in /usr/etc/services on openSUSE? <tsmish>hapster: just hardlink it by 'ln /usr/etc/services /etc/services'. Should be safe. <tsmish>hapster: symlink would be better, but I don't know how they play with bind-mounts <hapster>tsmish: well, that made the /etc/services go away, thanks! On the flipside, now I am trying to debug the build itself, which is just the same kind of nightmare :D <hapster>Is there a good way to go about debugging? Like a number of steps I can follow to approach the solution? Right now it's always like "well I guess I hit the limit of my abilites, guess its IRC-time" <cmiller>"/etc/resolv.conf" says it is auto generated with resolvconf but the command does not exist. Can I just edit the file or do I use NetworkManager? <cmiller>nvm, I did changes in the past and forgot. <tsmish>hapster: I usually just at errors carefully <tsmish>hapster: you can also do `guix shell -CD <package>` and see if you can build it manually. <ennoausberlin>Any news, why local cuirass installations evaluate, but does not build anymore <tsmish>hapster: if you hit "SoundTouch unsuitable version" this patch will help: https://paste.debian.net/1303224/. pkg-config should discover version by itself, but it doesn't for some reason and fallback logic has problems when version doesn't contain patch component. <tsmish>after adding a version bump for hidapi and eudev, c++-gsl as inputs it seems to build <lilyp>version bumping eudev sounds like gnome-team/c-u kind of stuff, isn't it? <tsmish>lilyp: bad phrasing, only hidapi needed bumping, eudev and c++-gsl only had to be added as input <lilyp>in that case, it ought to be good to go <tsmish>Also you don't need aforementioned patch because pkg-config now finds SoundTouch and fallback logic never triggers. The secret for pkg-config not finding SoundTouch was pkg-config not existing in native-inputs. <rekado>mekeor: probably file system corruption <hapster>tsmish: Currently building, thank you so much! How did you do this so quickly? <tsmish>hapster: copied definition with inherit, tried to build, then fixed whatever failures appeared. <tsmish>hapster: having checkout copied into directory to look about and edit things certainly helped. My thought process more or less was: inherit; try to build; failed due to patch; looked into CMakeLists.txt didn't find what it tried to patch; removed the patch; tried to build; failed due to SoundTouch; looked into FindSoundTouch.cmake; did a few things, they didn't work; found that regex; patched it; tried to build; failed due to dependencies a few times, added <tsmish>them; it basically works, cleaned up a little, figured why pkg-config didn't work, sent. <hapster>tsmish: Thanks a bunch, it built successfully! <tsmish>Kolev: From what I see stuff installed as part of chromebook-ucm-conf (glk/sof-glkda7219ma/sof-glkda7219ma.conf for example) reference stuff that is not installed (/codecs/da7219/init.conf). Also there are a lot of files in that repo that are not installed. Also I have no expierence with alsa UCM. <lalebarde>Hi, If I install the nix package manager in guix OS, will they share the same store to not duplicate same files? Or do they use independent stores? <tsmish>Kolev: also includes are probably broken due to renaming of common to ucm2 <tsmish>lalebarde: AFAIK guix uses /gnu/store, while nix uses /nix/store <lalebarde>tsmish would it be alright to make a link from /nix/store to /gnu/store? <tsmish>lalebarde: probably no. They wouldn't share anyway due to differences in packaging leading to different input hashes. <lalebarde>tsmish ok, thank you. That would have been nice to have them compatible and with the same store. <rekado>they also have a separate database <lucypoo>just eating lunch, what are people up to? <lucypoo>anyone going to guix days or just fosdem in general? <futurile>I'm hoping to go to FOSDEM - never been - got to get a hotel / flights booked though - so who knows <futurile>have you been to FOSDEM before? Any tips - things to do or not do? <aarcov>ieure I'm still learning about the patching stuff, is making a patch during a build step different than patching when obtaining the source? <aarcov>ieure is there a guix repl client? that would definately help to monitor the build while I try to figure out how to make the build <attila_lendvai>aarcov, IIRC there's a section in the manual now discussing the tradeoffs between snippets and patches <aarcov>attila_lendvai sweet, I'll look for that <aarcov>do you by chance know if there is a guix/guile interactive repl like for python for testing stuff? <lucypoo>futurile no i havent, it is my first time. the schedule is up now, there is a decent amount of guix stuff. im not sure how many people there will be but i assume upwards of 1000 <lucypoo>aarcove easy answer for me: `guix repl` <attila_lendvai>aarcov, there's `guix repl`, and there's geiser that you can start in emacs (i regularly use the latter, rarely the former). <lucypoo>thank you for solving the shepherd stalling bug attila <attila_lendvai>lucypoo, you're very welcome! :) it was also haunting me regularly. <attila_lendvai>lucypoo, just wondering... was this bug around for a long time? because IIUC it only manifests in some specific situations that required broken services and reconfiguring. <davidh38>I tried to execute an executable, that is called nexus in guix. is there a concept called executables in guix? <davidh38>bash: ./nexus: No such file or directory <attila_lendvai>davidh38, only fully statically linked binaries work on guix out of the box. otherwise you need to use patchelf and stuff <davidh38>attila_lendvai how can I know, that a binary is fully statically linked? <futurile>davidh38: I take it this is some precompiled binary you've downloaded. It's going to expect lots of standard directories (e.g. /lib) that aren't in Guix. You could try running it under a `guix shell` providing the --emulate-fhs - the manual has a good explanation <metsomedog>Hello. When defining a guix package, can I wrap e.g. the (arguments ...) section in a let to define some variables that are reused several places in the build? <lucypoo>attila_lendvai it was for a while and it was caused by a decent number of scenarios, the first time i noticed it, the command `sudo shutdown` was hanging and I looked at the process tree and it seemed this was due to shepherd. Then more recently, my installer would un-repair-ably hang when running `guix herd start cow-store`. Granted i have not tested your fix yet <davidh38>futurile oh great, thank you for the hint. <davidh38>attila_lendvai so statically linked means, that you have to dependencies in the binary, correct? <attila_lendvai>metsomedog, you'll need a context which is normal scheme code, e.g. wrap the entire (package ...) with a let. (arguments ...) is a field in a record's constructor. <attila_lendvai>davidh38, it means the binary has no dependencies (besides the syscalls that the linux kernel provides). <attila_lendvai>davidh38, mind you, there are very few such fully statically linked binaries. they most often come from the golang and the rust world. <metsomedog>attila_lendvai: I see that arguments is just a huge list form in my case, i.e. (arguments (list ...)) -- I assume I can just wrap the list function call in a let then? <attila_lendvai>metsomedog, yep, you can use a let in the *value* part of that. i wrongly assumed you want to wrap the entire (aruments ...) node. <metsomedog>attila_lendvai: I'm getting an Unbound variable error when relying on the let variable declaration in some lambda-functions under #~(modify-phases). <attila_lendvai>metsomedog, #~ gets you into a quasi-quoted context. you can use #$my-variable to unquote one level <attila_lendvai>metsomedog, this is called GEXP, a custom guix thingy that is similar in kind to normal quasi quotation, i.e. ` and , in normal lisp/scheme code. <Franciman>what's the difference between sexp and gexp? <metsomedog>attila_lendvai: Thanks again. Yet another issue, seems the build "short.circuits" now -- it just completes instantly without any output. Guessing it's not actually doing the building now... <attila_lendvai>Franciman, a sexp is lisp list that is made up from cons cells. a GEXP is a structure made up of scheme records that the guix infrastructure can "lower" into something else (IIUC into instructions to build a derivation when run inside the guix build daemon) <Franciman>hmm attila_lendvai but the constructor (gexp ...) <attila_lendvai>metsomedog, paste us the command and the output. i have no clue what is short.circuits. <attila_lendvai>Franciman, the constructor is a syntacting abstraction that builds a tree (graph) of scheme records as the internal representation. you keep writing sexp syntax inside #~, but it's turned into records internally, and then compiled into something else <metsomedog>Sorry, was not able to write due to some "empty line ignoring" error <metsomedog>/gnu/store/44csykh6m4xqm2kbm7z34d25v0kyxlpk-squeak-vm-6.0 <metsomedog>attila_lendvai: ^ that is the only input and output from the file I sent on debian paste <metsomedog>btw, I forgot to include in the debian paste that at the end of the file there is a single line with: squeak-vm <attila_lendvai>metsomedog, /gnu/store/44csykh6m4xqm2kbm7z34d25v0kyxlpk-squeak-vm-6.0 is the build output. what's inside that dir? isn't it something you wanted? note that if you did not change the package then the derivation will also not change; i.e. if you only changed the way the package is instantiated, but at the end you instantiated the same value. <metsomedog>Yes the expected result is in that directory, however before refactoring the package .scm file, the build was restarted every time I did "guix build" <metsomedog>I see that 'guix build --check' says the package is successfully built <metsomedog>Can I somehow make guix remove that output dir to check that it actually rebuilds? guix gc? <attila_lendvai>metsomedog, i remember i was also surprised why --check doesn't rebuild locally. i'm also still learning... <metsomedog>even ith --rounds=2, as before it just outputs "/gnu/store/44csykh6m4xqm2kbm7z34d25v0kyxlpk-squeak-vm-6.0" and nothing else <attila_lendvai>metsomedog, when `guix build ...` instantly rebuilds, it means that the inputs to the build did not change, which includes the in-memory package object that was constructed from the .scm file. <attila_lendvai>maybe someone more experienced can chime in WRT --chekc and --rounds=2 <metsomedog>I'm trying now after guix gc, I will keep you update <metsomedog>Ok, it is now building from scratch again after doing guix gc. I guess I had just not experienced the scenario where it doesn't need to rebuild before. <attila_lendvai>metsomedog, you can also force a rebuild by making a trivial change, e.g. swap two elements in a list where it is not relevant semantically... <metsomedog>Thanks, will keep that in mind in case it's needed again <metsomedog>So this package could theoretically produce 2 separate binaries (JIT version VM or stack interpreted VM). Each has a separate source directory etc. Is package "outputs" the correct way to select between those? <attila_lendvai>ACTION lacks the neccessary bird's eye view clarity to have a strong opinion on this <metsomedog>From reading the cookbook/manual I'm under the impression this is mostly used for "optional" features such as large documentation. <Franciman>metsomedog: do you usually need both installed? <metsomedog>Franciman: I haven't really used this system myself before (mostly building it out of curiousity/to play around with it). From what I've read they have some distinct advantages, for example the JIT version is faster, but the interpreter version is more lightweight/portable and supports some additional features at runtime. <metsomedog>In other words it could make sense to have both installed <metsomedog>Maybe a separate package for JIT and interpreted version, one inheriting from the other, makes more sense <wdkrnls>Is libreoffice supposed to work for anyone? <wdkrnls>well, I guess that is just a warning. <rekado>it has always worked for me and still does. <alepzi->the declarative lang that's used to config systems and software is called a g-exp? <Franciman>no, it's the language used to define actions to build things <alepzi->do you use gexp to specify how a system should be configured? <Franciman>i use it to specify how a package shouuld be built. That is done in scheme <alepzi->i'm interested in guix and i want to start with just the base OS, no 3rd party software yet <alepzi->what lang do i use to declaratively specify my system's config? <Altadil>alepzi-: config is done in Scheme. The installer will give you an initial config and you can modify it. <alepzi->what file extension does it have? or can you link me to that? <Altadil>alepzi-: you can look at part 11 of the guix manual. It has the complete reference of the system configuration. <Altadil>alepzi-: it’s not the same number because I was looking at the latest version, not the 1.4. Sorry for the confusion <alepzi->ok ya that syntax. that seems way easier to specify our system with that instead of nixos <Franciman>alepzi-: it's also a well known programming language <alepzi->surely it's not a part of Scheme right? <alepzi->operating-system but what is that? a lib? <alepzi->so if you wanted to use guix machinery but for windows could you make a native operating-system and it'd all work? <alepzi->or even make an operating-system for nixos to replace terrible nix <loopback___>is the only way to tell if a derivation is a source derivation if it ends with -checkout .tar.gz etc.? <apteryx>you could read the .drv itself and check its builder code <loopback___>any specific differences from non source derivations? <alepzi->metsomedog: guix tech seems really cool so i'm just brainstorming but couldn't all OS's use basically the same config format? basically just creating a native operating-system <alepzi->i just think if there's a great way to config a system, then it's probably applicable to any OS no? <alepzi->or is there something instrinsicly guix-only? <metsomedog>I'm not familiar with the guix implementation, but at least on linux you can either use it as the entire operating system or just as an additional package manager in another OS such as debian. <metsomedog>There is a tutorial on systemcrafters on how to use guix in WSL2 <alepzi->ah so ppl are using the guix style for other OS's, exactly! now i wonder if it could be used for windows or mac <metsomedog>well WSL2 is pretty well integrated in windows, but idk if you could get it "natively" using e.g. msys <apteryx>Guile would need to run on Windows for one <apteryx>I think it does, but perhaps not for 3.0.9 ? <loopback___>OS's like Linux distros are more commonly made up of different pieces of software written by developers who prefer different things, so there's different configuration methodd. It's tricky to unify them. For example, the "vanilla" guix ip settings don't include an mtu option <alepzi->so you'd need a native guix daemon, but assuming you have that and you put your system config in the scheme format and you have a native operating-system declaration, it should work right? <loopback___>why is guix build --sources=transitive --no-substitutes --no-grafts -e '(load "/run/current-system/configuration.scm")' compiling stuff? I only wanted to download source code <metsomedog>guix goes to great lengths to replace posix stuff such as /lib directories etc., not sure how that would translate to other OSes <metsomedog>alepzi-: if you want to play with it and are using windows I suggest to try it in wsl or wsl2 following some tutorial from the internet <loopback___>building source derivations shoulding compile anything? <alepzi->metsomedog: but why does /lib matter? internally guix daemon just takes a config, and decides what to do. so in guix.exe just use the native version of /lib no? <loopback___>for the most part it's been building only source derivations <apteryx>that's part of the early bootstrap chain <metsomedog>alepzi-: sorry I don't have the knowledge to answer these questions <apteryx>bootstrap packages are added to source derivation to be able to apply e.g. patches <apteryx>see %standard-patch-inputs in (guix packages) <loopback___>so ``guix build --sources=transitive --no-substitutes --no-grafts -e '(load "/run/current-system/configuration.scm")'`` should've already downloaded the sources for the bootstrap packages, and are the only things it'll compile? <loopback___>I mean the downloaded sources would show up in the "these will be built" list <apteryx>the guix used will determine what derivation/store outputs are needed/used <ennoausberlin>Hello. I am writing a package definition and I want to create a shell script with with-output-to-file. In the shell script there is a call like java -jar. How can I specify the path to the java, that the script only uses the java from the propagated-inputs? <alepzi->are gexps a subset of the scheme that's used to config the OS? <Altadil>alepzi-: gexps are made from scheme, but, if I understand correctly, they’re more for making packages than for configuring the OS. <Altadil>For instance, I have a working config on this computer, without using any gexp. <ennoausberlin>alepzi- They are used as dynamic expressions in build phase. Never used it, but it is on my list <alepzi->ya so gexps are a subset of scheme used for a limited purpose <alepzi->is scheme like, the basis for everything in guix and it's a totally regular and consistent system? <metsomedog>ennoausberlin: have you tried something like (which "java") ? <ennoausberlin>metsomedog: Don't know if which finds it the moment I create the script, because java might not yet be installed. Its a propagated-input of my package <metsomedog>ennoausberlin: look at the definition of e.g. the f-seq package, it uses (which "java") to substitute some stuff. There are other similar examples. <qrpnxz>had a hard time finding package specs. Turns out they are in the directory "gnu". Confusing given most of these are not GNU project packages... <dthompson>qrpnxz: 'gnu' means "GNU system" in this context, meaning the entire guix distro <metsomedog>I'm having a gexp problem: trying to do "#:configure-flags #~(append (list ...) #$var-from-let-binding)" and getting "guix build: error: #<unspecified>: invalid G-expression input." from the var. Anyone know why that might be? <metsomedog>^nevermind my question above, I made a mistake elsewhere in the code. Also I could use the splicing #$@ operator over append. <podiki>if I make a live usb image (e.g. guix system image to a bootable usb drive) and then use that to install guix, will i need cow-store? yes because essentially running on a ram disk? <euleritian>Hey guixers! Why does "guix shell -CFD guix" complain with "ldconfig: /lib/libguile-3.0.so.1.6.0-gdb.scm is not an ELF file - it has the wrong magic bytes at the start."? (It's not lying, the file inside the container contains scheme code. I'm running guix 67c9cdf on a foreign distro which does not have this file in its /lib.) <podiki>what are you trying to do or running? your command just makes an fhs-emulated shell containing the build inputs of guix <euleritian>It's the minimal example to reproduce the error message. <podiki>so just running that guix shell does that instead of dropping you to a prompt? <podiki>you should just need guix shell -D guix --pure (maybe through in other things you will need), at least that's what I use and is in the manual <euleritian>It gives me a prompt, too, and the container seems to be working. <podiki>making it in a container (-C) is something different and not needed to build guix locally <podiki>but -F is something else (set up like an FHS system) and shouldn't matter here nor be needed <euleritian>It just seems strange to me that guix sets up the FHS and the complains about it. <podiki>but why are you using -F? the use case is not for building guix <podiki>i mean it shouldn't cause a problem I don't think, so maybe there is some bug here <podiki>oh i think I know why; ldconfig is being run (for FHS container) and there is that file in /lib that is not a library and ldconfig didn't like it <metsomedog>Is it not possible to use symbols in guix package definitions? (eq? #$variant 'stack) gives me "unbound-variable #f "Unbound variable: ~S" (stack) #f" <podiki>but yeah, shouldn't make a difference here and not needed <podiki>metsomedog: what are you trying to do? certainly you can use symbols in package defs, they are filled with them <metsomedog>I'm using a function to generate the (arguments) to 2 packages. The function takes an input variant that can be 'cog or 'stack. Some places I'm checking for the state of the variable to generate some code. <ieure>Is there an Emacs facility to help find what package a procedure is in? Finding it really hard to determine where stuff comes from since everything seems to dump all symbols into the current package. <podiki>ieure: geiser I would think, with jump to definition. but i haven't used it much <metsomedog>Perhaps I must change (eq? #$variant 'stack) with #$(eq? variant 'stack) ? <podiki>metsomedog: your error is telling you it doesn't see stack as a defined variable. maybe in what you are quoting or not in the whole form, hard to say without seeing. there are examples of generated packaged definitions like what you are saying I think, but don't know names off the top of my head <ieure>podiki, Thanks, that helps, though if this works like SLIME and NREPL, it can only jump to things that have already been loaded into the Guile image. <metsomedog>I don't see why stack should be a defined variable when I'm quoting it? <podiki>metsomedog: something is unquoting it perhaps, i don't know your full code so i'm just guessing, but the error is telling you that i doesn't know what it is <podiki>ieure: there are some helpers/setup with emacs and guix but as I said I haven't tried much <podiki>#$ is ungexp, so presumably you have a #~ (gexp) outside that; maybe need two quote? '' <metsomedog>hmm see I was missing a k from %make-squeak-vm-arguments in one place. Either way same error after fixing that <euleritian>podiki: The -F was necessary to compile lean4, which expects /usr/bin/env hardcoded in many bash scripts. I forgot to drop it for guix... my mistake, I'm sorry. <podiki>euleritian: still, shouldn't mess anything up, just ignore that warning <podiki>metsomedog: not sure, having a hard time following what will ultimately be gexp or not; i think might be easier to have a procedure that takes some arguments and returns a package, not just the arguments part to be put in another package definition <podiki>metsomedog: anyway, got it to get past that. put your #$ here: #$(when (eq? variant 'stack .... and then #~(substitute* ... <podiki>in other words, you want to ungexp the whole when form, but then gexp the substitute part <metsomedog>Thanks I will try that. I'm not sure of a clean way to separate between the "cog" and "stack" stuff since they are 2 different build src dirs in the same repo, with almost identical build steps, etc. <metsomedog>Maybe in the future with "parametrized inputs" or w/e, e.g. in gentoo this would probably have USE-flags for the 2 functionalities <podiki>not sure what the cog and stack are, but maybe using inherit or using two outputs <metsomedog>they are basically JIT (cog) or interpreter (stack). I'm keeping the same terminology as upstream here <metsomedog>It's using inherit for the stack variant in the paste from above <metsomedog>btw seems to be building now with the change you suggested, thanks alot <metsomedog>I'm planning to submit this as a contribution so I guess I will get feedback then on how best to separate the packages <metsomedog>btw, do you need to sign something to contribute to guix as with some other gnu projects? <podiki>yeah, i would say get things to build and work first and then worry about details <metsomedog>Got both variations to build and work with launching smalltalk images. Took a lot of work, I found the upstream build structure very messy <metsomedog>also I have no clue how to build C projects in general <dgr>is it normal that plasma isn't loading the .profile from guix home or did I break something? <podiki>sneek: later ask efraim: any thoughts on status of mesa-updates on non-x86? berlin seems to not build any more for some days and coverage seems okay there; should I merge?