***rekado_ is now known as rekado
***Xenguy__ is now known as Xenguy
<FlaminWalrus>Aurora_v_kosmose: it's distributed as a part of texlive; just checked and I've got the `xelatex` command on my path <Kolev>Installing System on laptop again. No need for Jellyfin. <Gooberpatrol66>ping doesn't work inside a guix system vm even though other tools like wget work. is there a way to fix this? <Aurora_v_kosmose>FlaminWalrus: It's one of the few things that's unfortunate with Guix I think. One can't simply do something like "apt-file search $filename" as Guix has no manifest of the files in a package <tewi>hello, in the configuration system section of the manual, i see %base-packages, %base-groups, and so on used. is there a way to see what these actually stand for, and what variables like that are bound by default? ***rekado_ is now known as rekado
<jgart[m]>This month we're rotating to use an APAC friendly time for our Guixers on that side of the š <FlaminWalrus>Aurora_v_kosmose: yes, that would be helpful. I recall having a heck of a time figuring out that terminfo capabilities came from ncurses...something like `guix search which` that'd return a list of all packages that provide a specific command would be great too. It'd either need a change to (package...) objects though, or be something that'd build the package in a temporary environment and inspect the output, but cache the results on <FlaminWalrus>the substitute servers so queries wouldn't outlast the Sun... <apteryx>Aurora_v_kosmose: yes, it's part of texlive-bin <apteryx>but polyglossia is broken in master (fixed on the wip-ipython-polyglossia branch I'm working on) <Ox151>is there any documentation for adding a windows partition to the grub menu? <apteryx>sneek later tell 0x151 there's an example in "info (grub)Chain-loading" <apteryx>Ox151: ah, it starts with o, not 0 ;-) ^ <apteryx>Gooberpatrol66: that's a documented limitation of the QEMU user mode networking <apteryx>TCP-based tools (such as wget) works but ping uses the ICMP protocole which QEMU user networking itself uses, conflicting with it, if I recall correctly. <Ox151>apteryx: ;) irc doesnt allow numbers at the start of a nick XD <Aurora_v_kosmose>FlaminWalrus: I would imagine that it could be a saved build artifact. The CI farm could cache the ones for its own builds and serve them too. <bjc>there is a guix data service that seems like it could be made to suit the purpose of caching file locations <bjc>ludo also mentioned another database that he'd hacked together, but i can't find the ml post right now <apteryx>sneek: later tell attila_lendvai you could also reference the package/origin directly via gexps (e.g, #~(modify-phases ... (invoke "something" ... #$the-origin) ...) <FlaminWalrus>bjc: I would think there would general programmatic advantages to having a summary of all side effects of a build somewhere beyond these kinds of searches; a Scheme function mapping derivations (or gexps) to a higher-level summary (i.e. only the /what/, not the /how/) could be helpful for debugging stuff like build irreproducibility or hidden dependencies. It's cool to see guix-devel already has this on the mind! <FlaminWalrus>On the topic of changes to Guix, has anyone ever talked about first-class kernel modification support? Right now, the workflow is 1. clone sources from git.kernel.org 2. wait 3hrs 3. copy /proc/config.gz to exactly the right location in the massive source tree 4. make menuconfig 5. manually write the new config into a kernel package definition. I tried to investigate pulling the 'make menuconfig' code out of the kernel for a tool tha <FlaminWalrus>automatically produces a package definition from the changes Ć la 'guix import', but the kernel's recursive Makefile structure is nightmarish and I gave up pretty quick... <apteryx>lechner: hi! the source of the manual is at doc/guix-cookbook.texi; edit it, build it/review the result, then send a patch to guix-patches@gnu.org. The contribution process is documented, see info (guix)Contributing ***zmv is now known as notzmv
<eskin>Is there a way I could see a package's source after snippets are applied? I'm not sure if guix holds on to source code, I didn't see it when poking around <jpoiret>xelxebar: iiuc you don't need to manually consider grafts <jpoiret>oh, you're using package->derivation anyways <xelxebar>jpoiret: Thanks for the input. Yeah, for some reason a simple package->derivation isn't picking up the grafts. <xelxebar>Hrm. AFIU, `guix build` eventually boils down to a package->derivation call for simple cases, and package->derivation already does call graft-derivation*. <jpoiret>In what context are you running that code? guix repl? <jpoiret>if you pass #:graft? #t explicitely to package->derivation, does it consider them? <xelxebar>Hehe. Tried that, and I saw no difference. <xelxebar>Huh! That's interesting. I'm building a package directly from the git repo. <xelxebar>That's on the `devel/make3` branch, and the relevant code is inside jbuild.scm <xelxebar>You can see the build-package definition near the bottom of jbuild.scm. <lechner>Hi, does Guix ship foot-terminfo anywhere? Thanks! <jpoiret>xelxebar: i don't see any grafts in your definitions <jpoiret>orr do you mean grafts somewhere in the dep tree? <xelxebar>jpoiret: Correct. My package doesn't directly have grafts, but some of its dependencies seem to. <jpoiret>so, using build-package doesn't give you the same as `guix build -f yourjdefinition.scm`? <xelxebar>Currently, it does. However, if I remove the explicit graft-derivation call, then build-package fails to generate the output path in the store. <xelxebar>The "non-grafted" output path is built, however, and I see that as a dep of the .drv. <jpoiret>xelxebar: unrelated, (concatenate (map ..)) can be replaced by append-map in srfi-1 <lechner>jpoiret: thanks, but doesn't the proposed fix require me to install the terminal app on the server, even though it is never used there? <jpoiret>we don't have separate terminfo packages in guix unfortunately <lechner>and pull in the wayland libs on a linode? <jpoiret>you could set TERM=some-compatible-but-usual-terminal <jpoiret>maybe that could be something we could do <jpoiret>or even just add a terminfo output to all terminal packages, hopefully they won't retain references to anything <jpoiret>xelxebar: how do you build drv when you're not using the manual grafting? <xelxebar>jpoiret: Cheers. You should be able to see missing grafts issue if you remove line 474. <xelxebar>Rather, the script will just error out, complaining that the package's /gnu/store/...-blah path doesn't exist. <jpoiret>if you simply remove line 474, then you're just not building the derivation at all <jpoiret>you need to use something like (build-derivations (list drv)) at some point <jpoiret>you'll build something because package->derivation needs to build some things to work (namely the thing it's grafting on iirc), but it won't build the derivation you want <xelxebar>I did have a built-derivations call at 474, so maybe I'm just confused. <jpoiret>maybe i'm wrong then, if it still doesn't work with a built-derivations <xelxebar>I could easily just be confused. Checking. <xelxebar>Okay. It seems to be working with built-derivations :D <xelxebar>Maybe I had been using it before I figured out that mbegin is needed. <jpoiret>by the way, that package definition looks good :) <jpoiret>and mlet doesn't support multiple body forms for some reason <xelxebar>:P Still working on the cpu tuning stuff <jpoiret>would you be interested in the mdo notation i talked about in the MLs? <phodina[m]>I attempting to update rust package `rust-wayland-egl` to version 0.29.4. But the build fails as it cannot find crate `cfg-if` in rust-nix-0.22 which is dependency of `rust-wayland-client-0.29` (this is dependency of `rust-wayland-egl`). <phodina[m]>However, when I check the `rust-nix-0.22` package it's listed in the cargo-inputs. Any idea what to do? <jpoiret>i'll try to cook up something today then <jpoiret>phodina[m]: maybe a version constraint? *xelxebar gives a thumbs up to jpoiret <unmatched-paren>i did try before, but i had search path problems with it not finding the standard library <jpoiret>unmatched-paren: is that the devault project? <phodina[m]>jpoiret: Thanks, I'll check that but `cargo` normally it complains if there is a specific version needed <unmatched-paren>jgart: would you be interested in helping with a hare compiler package in Guix R Us? see above ^^^ <phodina[m]>jpoiret: I checked the version and there's no constrain <jpoiret>i image you updated rust-nix but not cfg-if? could you send a paste of it so we could try locally? <phodina[m]>jpoiret: I can send you the 18 patches you need to replicate that if you want <phodina[m]>jpoiret: Nope I didn't update rust-nix, that's already on master. I just need to update the wayland crates to get newest alacritty terminal <jpoiret>oh it doesn't even need to, disregard that <phodina[m]>jpoiret: Not sure what you meant as it's listed in the cargo-inputs of `rust-nix` package. <unmatched-paren>i have a search path for `hare', but it doesn't seem to be working... <unmatched-paren>"When you āuseā a module, Hare will search for that module in your HAREPATH, which is a colon-delimited list of directories to look through. The first directory is always the current directory, so if you want to add a private module called āexampleā you can place its files at ./example/*.ha. The standard library is usually installed (on Unix systems) at /usr/src/hare/stdlib, and third-party <unmatched-paren>modules are installed at /usr/src/hare/third-party, both of which are configured in your HAREPATH by default. We recommend that you make liberal use of these resources in your work ā donāt hesitiate to read the source code for your dependencies. <unmatched-paren>the runtime is in a different place (with the bootstrap harec), so it can't find it <jpoiret>phodina[m]: could you paste your rust-nix definition? <jpoiret>seems it's not being picked up as a rust input <phodina[m]><phodina[m]> "jpoiret: I can send you the 18..." <- All the patches apply and mostly just update the versions and inputs. But with this confusing message it's hard to figure out what's wrong as the `cfg-if` package is in already merged package and other packages depending on `rust-nix` compile and don't throw any error <jpoiret>phodina[m]: can you keep the build directory and inspect guix-vendor? <phodina[m]>jpoiret: If I add `rust-cfg-if` to `rust-wayland-egl-0.29` into cargo-inputs it the complains about missing `autocfg` but that's a dependency of `memoffset` which is dependency of `rust-nix`. Looking at the `rust-nix-0.22` it skips build. Could it be that's it's merged but doesn't build? <jpoiret>why can't i just @@ the procedures defined in guix/build-system/cargo.scm :( <maximed>eskin: Try "guix build --source the-package" <maximed>That will build the post-snippet source <maximed>(as in, the source itself, not the binaries) <maximed>phodina: Something to be aware of: cargo-inputs != cargo-development-inputs. So maybe cfg-if is in the wrong one <vivien>Hello guix! I see thereās a lot of activity around the python build system. I still have a patch waiting for review, but if the build system work is active as I can see right now, it is reasonable for me to wait for the job to be done and then rethink my package with the new build system. <vivien>Iām not sure my sentence is easy to understand, thatās my bad sorry. <vivien>Anyway, I guess thereās only a handful of python packagers in guix, so better let them concentrate on the bigger task first. <phodina[m]>maximed: Thanks, I'll doublecheck the dependencies with the Cargo.toml <phodina[m]><maximed> "phodina: Something to be aware..." <- Not sure why but adding the dependencies of `rust-nix` and `rust-memoffset` to cargo-development in `rust-wayland-egl` solved the build issue š. I'll mention it in the patch thread when submitting. <unmatched-paren>there seems to be an issue with the home-fish-service-type where it creates ~/config/fish/* instead of ~/.config/fish/*, probably because of the recent change where home no longer prepends a dot <phodina[m]>I've found similar issue with `rust-glutin-0.28`. It fails on `rust-glutin-egl-sys-0.1` even if I put it in the cargo-development-inputs or inputs. <phodina[m]>The Cargo.toml says it should be just cargo-input. Also the crate is in the `guix-vedor` dir when building with `-K`. <unmatched-paren>but i changed ~/config to ~/.config in its definition, and it still didn't wor <WesterWest[m]><unmatched-paren> "there seems to be an issue..." <- i already submitted a patch but theres no activity on it <WesterWest[m]><unmatched-paren> "anyone have any idea of what..." <- i just hard-link it everytime, you can try sourcing the config file if it fixes it <wehlutyk[m]>I'm slowly progressing with a guix-based project on rock64 (aarch64), for which I'd like to use rust <wehlutyk[m]>I just discovered rust isn't currently supported on aarch64, but haven't found any news about current development for support <wehlutyk[m]>(with rust in the kernel i read somewhere this will become pressing quickly) <wehlutyk[m]>Is there anywhere I can follow this? Or give a hand? <maximed>phodina: FWIW, I'm writing a new (Guix) build system for Rust (antioxidant-build-system), that (is intended to) integrate better with Guix <maximed>so maybe the issue will disappear eventually <maximed>It's not yet ready for general usage though. <maximed>wehlutyk[m]: IIUC, the problem is that currently, Rust cannot be bootstrapped on aarch64 -- only on x86_64 <wehlutyk[m]>yes, also mrustc now supports 1.54.0 (but as you say, not on aarch64) <wehlutyk[m]>maximed: what's your antioxidant-build-system based on? <wehlutyk[m]>I mean, it sounds interesting -- what are the planned benefits? <maximed>wehlutyk[m]: antioxidant-build-system is a Guix build system like python-build-system or gnu-build-system <maximed>It reads Cargo.toml files like Cargo does. <maximed>But instead of calling "cargo SOMETHING", it calls the underlying rust compiler 'rustc' <maximed>Benefits include: Removing the special #:cargo-development-inputs / #:cargo-inputs in favour of the usual 'inputs' / 'native-inputs' / 'propagated-inputs' <wehlutyk[m]>ah yes I remember seeing that not long ago! (maybe on the mailing list) <maximed>Also, in the cargo-build-system, the build results of dependencies were not reused in dependents <GNUtoo>hi, do some people often have "ice-9/eval.scm:293:34: error: tcc: unbound variable" when building Guix? *GNUtoo tries with make -j1 to get the full trace <maximed>GNUtoo: in build-aux/build-self.scm (or was it compile.scm?) there's a āload all the modulesā followed ācompile every moduleā? Maybe there will be a better error if the āload all the modulesā is removed <maximed>Though this will have some side effects <maximed>Remove the (load-files source-directory ...) <maximed>Then if "make" fails, at least the 10% files that could be loaded will be compiled, so next time, they don't have to be loaded again <maximed>Actually 'load-files' compiles the files I think, it just doesn't save them? <GNUtoo>Maybe it's some race conditions because sometimes I have it sometimes not and every time I didn't understand how it disapeared <GNUtoo>so maybe it's related to some build order <GNUtoo>So maybe I need to (1) reproduce the bug again (2) find a workaround (3) bug report? <maximed>GNUtoo: does your guix tree have modifications? <maximed>Or maybe undo the change to compile.scm. <GNUtoo>I've now undoed all changes and I'm at 78% <GNUtoo>It worked so I'll try to reproduce and to workaround by compiling c.scm first somehow and report if that works <GNUtoo>Anyway thanks a lot for the help, it pointed me in the right direction as on top of the code to comment there is a bug report link <phodina[m]><maximed> "so maybe the issue will disappea..." <- Thanks for the info. Do you have a tracking branch? <maximed>For now, it's developed outside Guix itself. <maximed>Though the idea is to eventually move it into Guix itself and teach "guix style" to automatically rewrite package definitions <maximed>lechner: I'm not familiar with knot but that seems about right. <maximed>Did you do "guix system reconfigure"? <maximed>lechner: Maybe knot keeps some logs that can be investigated? <lechner>maximed: great hint. i was looking to herd for the logs but it's not like systemd. i found something i need to recocile with the guix docs and my own knowledge of knot error: config, file '/gnu/store/1mw2hs2vsax7a4smx879995mwqxhxw9l-knot.conf', line 22, item 'acl', value 'wallace-acl' (invalid reference) <lechner>yeah the config file doesn't look quite like i expected ***Noisytoot is now known as [
<maximed>antioxidant update: 'sniffglue' now builds <maximed>technor: maybe just (list "notify")? <maximed>Also, ideally Guix would just throw some error here, instead of having to dig through the configuration file. <lechner>maximed: the (list "notify") threw no error but produced no output <lechner>i'll contribute better error messages once i learn more about Guix <lechner>where can i find the Guile code for it (or whatever else i need)? it may not be implemented right <maximed>"git grep -F" may be useful to find where exactly <maximed>The manual has some information on where to download the source code from. <lechner>Hi, what are everyone's favorite DNS client programs in Guix? Also, should 'ldns' ship an executable called 'drill'? ***rekado_ is now known as rekado
<vagrantc>it's a good day when i get linux-libre substitutes for aarch64 :) <vagrantc>don't recall anything, per se. wouldn't be a bad idea to implement <mekeor[m]>is there a search engine to search packages in a maintained set of channels? <GNUtoo>I heard of thinkgs like that in the past but I'm unsure if it was a plan of it it exists but there is a need anyway. <vagrantc>for reasons i don't quite understand, guix system/shepherd stalls on my rockpro64 on reboot or halt if the dw_mmc_platform module is loaded ... manually removing the module and it proceeds reasonably fast <GNUtoo>vagrantc: maybe dmesg could tell? <GNUtoo>Do you have an UART or do you see the messages somehow? <GNUtoo>You could also try to load it manually and look at dmesg <vagrantc>yeah, on serial console i bump the kernel logging <vagrantc>problem is, to trigger the system, i basically have no access to anything, as all the shells/logins/etc. are stopped at that point <GNUtoo>btw, beside that does this board works well? <vagrantc>i wonder if shepherd is somehow seeing a kernel process as a userspace process for some reason... <GNUtoo>You probably need to add loglevel=8 to the kernel cmdline and hook up an UART then <vagrantc>reasonably well for me. i know rekado had some troubles with using a different sata controller <vagrantc>i've bumped it to 9 using ctrl-a b 9 from the screen monitoring it <vagrantc>shepherd[1]: waiting for process termination (processes left: (1 162)) <vagrantc>on the booted system pid 162 is some kernel process relating to the mmc bus <GNUtoo>with "console=ttySomething1 loglevel=8" it will be the kernel that outputs the message, so you can remove shepherd from the equation <GNUtoo>so the ctrl-a b 9 is like dmesg -n 8 <vagrantc>it sends abreak signal to the serial console and enables the kernel logging <vagrantc>"ctrl-a b h" lists all sorts of features you can do, but most are disabled for security reasons <vagrantc>but it might be useful to just enable it at boot since i'm having this problem <vagrantc>the process shepherd seems to be waiting on is 162 kworker/2:2-mm_percpu_wq <GNUtoo>It's also probably better to be 100% sure in cases like that <GNUtoo> dev_dbg(host->dev, "remove slot\n"); <GNUtoo>It should also probably print that <GNUtoo>it's in void dw_mci_remove(struct dw_mci *host) <GNUtoo>I'm unsure how it works with reboot or shutdown though <GNUtoo>but I guess it has to disable devices at some point so it should probably call .remove() <vagrantc>yeah, that revealed the same messages... <vagrantc>although interestingly enough, the kernel process is now 156 instead <GNUtoo>The pids are probably somewhat random <GNUtoo>The OpenSSH key issue publicized that <vagrantc>only change when i change something in the system configuration <vagrantc>most likely because the modules from the initrd are loaded in a predictible order ***zmv is now known as notzmv