IRC channel logs
2024-11-18.log
back to list of logs
<f1refly>Are there things I should know when trying to execute appimage files on guix? I tried to start Cura 5.8 by UltiMaker but zsh (and strace) just report `exec: No such file or directory` <divya>It isn't a dependency issue of not being able to find gtk, since I've added it as both native-inputs and propagated-inputs. <look>divya: I just took a quick look at it, you might want to properly install the 'po' and 'data' directories onto the proper location, or simply wrap-program the output binary with the 'PO_DIR' and 'DATA_DIR' env vars pointing to the installed-source location <look>since we have '#:install-source? #t' by default, pointing those env vars to their respective #$output/share/cargo/src/package-version/{po,data} should suffice, but ofc would be better to properly install the bundled .desktop and icons when you're done with making sure the package works <divya>look: Ah, thank you. But is the error that it reports related to that? <civodul>yeah, i realized i couldn’t reconfigure my laptop <civodul>(because childhurd -> genimage -> u-boot-tools) <mange>Is it possible for a Guix channel to define a custom Guix command? That is, to make "guix command-from-my-channel" do something? I vaguely remember trying a bit ago and it not working, but I have no idea what I tried. <civodul>mange: it’s not working right now, but we should fix it <janneke>Franciman: a childhurd is a hurd in a (qemu) vm <mange>Do you know how it's broken, civodul? I'm happy to dig in to try to fix it, but investigating it might take me a while. <civodul>mange: yes, the problem is that %load-path is modified in (gnu packages); so until that module is loaded, modules that come from the channel are not in the search path <janneke>Franciman: we use childhurds for hurd development and to build substitutes <mange>civodul: Thanks! I'll take a look tonight. I've immediately run into "what do three forms in a let* binding mean?" in %package-module-path, which surprises me. I thought I was pretty comfortable with scheme! :P <efraim>where can I get pthread for mingw? zstd won't cross compile <efraim>nvm, I'll just disable threading for windows for testing <civodul>mange: that SRFI-71, ‘let*’ with multiple-value support <mange>Thanks! I assumed it was an SRFI, so I compared the lists between a module that was working and one that wasn't and figured that out. Unfortunately the index on let* in the Guile Reference manual didn't take me there, but I worked it out in the end. :) <PotentialUser-18>How do I specify the specific output of an inferior package? Using the following manifest, maven does not seem to find the JDK in openjdk:jdk: <civodul>PotentialUser-18: (list (first (lookup-inferior-packages pinned-version "openjdk" "11")) "jdk") looks correct <xelxebar>civodul: Shouldn't "jdk" be (specification->package "jdk")? <snamellit>01:40 <divya> efraim: Any clue about cargo giving spurious network errors? I, with the help of ekaitz, added git-fetch-with-cli to cargo.toml but it still throws spurious complaint. Is this common in cargo-build-system? <Rutherther>xelxebar no, specifications refer to a package, not to output of package <look>divya: That won't do, wrap-program needs the program to wrap, and it is only created in #$output after the install phase, so you must do it after it <look>divya: Also, what i meant by package-version was '{package-name}-{package-version}', so in this case 'blue-recorder-0.2.0' <look>You'd also need to propagate gtk and xwininfo, since it seems the app expects the xwininfo to be in path (you can try building it without xwininfo propagated to see the error for yourself) <PotentialUser-18>civodul: Seems then that the issue lies in that the shell environment created with this manifest somehow differs from the corresponding environment created through time-machine. So I guess using time-machine is preferrable for reproducibility? <civodul>PotentialUser-18: yeah, in general ‘time-machine’ is the best approach; inferiors exist for the unusual case where one needs to mix old and new packages, but it’s more complex and often unnecessary <yelninei>hi, i just reconfigured my system and it seems i have to rebootstrap the final inputs for i586-gnu/hurd? cant find anything obvious that should have an effect? <yelninei>or is the guile-launcher more influental than i thought? <xelxebar>Rutherther: Specifications refer to the *name* of a package, not the package structure. <xelxebar>Or, more generally, some collection of data that has enough information to reify into a unique package structure. <PotentialUser-18>Hmm, it looks like my issue really stems from the environment being different depending on whether you list the dependencies in a manifest, or list them directly as arguments to the `guix shell` command. This behavior was unexpected to me, is it a bug? <divya>look: Ah, by 'program' you meant it needs the binary, got it. Many thanks. <Rutherther>xelxebar I didnt say they are package, I said they refer to it <Rutherther>xelxebar by that I meant that in (specification->package "jdk") you refer to a package with name jdk, latest version, and obtain its package record. But there is no such package, and op needs to refer to jdk output of an inferior "package" (which is then even more problematic ad specification->package refers only to current channel packages not inferiors - unfortunately you cant get inferior into package structure) <look>PotentialUser-18: if you remove the first openjdk package, and only use the "jdk" output, does it work as intended? <look>My initial thoughts are that it seems to be an weird behaviour with inferiors, as I cannot reproduce this with a regular manifest file with both "out" and "jdk" outputs (it works as expected without using inferiors) <PotentialUser-18>For me it does not work as expected, even when using time-machine. I cannot test without time-machine, as the up-to-date maven-surefire plugin is broken. <jaadu>How can I configure Emacs to have the same paren highlight as in the web-based guix manual? <jaadu>aemogie: rainbox-delimiters don't do any interactive highlighting. <aemogie>ah, right. my bad. just now noticed that the web manual only highlights the hovered expressions <jaadu>aemogie: No wonder, I have installed rainbow-delimiters multiple times thinking it having this feature, only to get disappointed and forget about it. <xelxebar>Rutherther: Ah, okay. You clearly have more context than I do. I was simply trying to pointt out the funny argument. <aemogie>(wall of text) what is the preferred way to lock system-wide guix channels? in my current setup, i currently have a "channels.scm" in my config directory, which i lock with "guix describe" as in the manual into a "channels.lock.scm" file. in the system configuration i make use of (guix-configuration (channels (load "channels.lock.scm"))). ive never written scheme before, not sure if this is idiomatic. my doubts on this are due to every <aemogie>single rebuild trying to compute the derivation 2 times (i assume once for the "channels" field, and once more for "guix-for-channels"), and it's extremely slow each time. time-machine seems to cache these, is there no way for the build to use the same cache? and why doesn't the default configuration compute the derivation? the computation gives postgresql warnings, so i assume it's the guix channel itself that is being computed. <look>PotentialUser-18: I have no idea why, but try adding openjdk AFTER the "jdk" in the manifest <look>wow, seems like in any manifest the order which you add the packages to the list matters, when using two different outputs of the same package <look>doesn't seem like intended behaviour to me <apteryx>hm, I'm having an odd problems where two tests using 'with-http-test', when used alone, pass, but the last one fails when both run sequentially <apteryx>seems the dummy web server is not completely isolated to within a 'with-http-server' block ? <divya>The package finally builds and works swiftly. Thanks to everyone, especially efraim , look and of course my untitled senior ekaitz haha. <divya>We'll have another good GUI screen recorder in guix <divya>Also just to clear up, this package definition needs a lot rust crates to be defined, am I expected to send a separate commit (and patch) for each of those definitions or can I send the whole thing (~2K LOC)/ <divya>I think they have to be separate since the crates need to go into crates-*.scm and the app itself into rust-apps.scm <ekaitz>divya: you can send them together in a chain of patches to the same thread <ekaitz>divya: remember to send the cover letter first, obtain an issue number and then send the patches to it <ekaitz>that's explained in the guix manual btw <divya>Okay, using --cover-letter. Got it. <ekaitz>yes, make sure you don't send patches in the first email, only the letter <ekaitz>and then, when you get the answer, you send the patches there <divya>ekaitz: okay, I should send the patches after someone has responded to the cover-letter mail? <ekaitz>divya: it's not "someone", but a bot, assigning you an issue number <ekaitz>if you don't do this, you'd be opening one issue per email, and that's not what we want <ekaitz>we do all this to keep everything in one thread (one issue) <ekaitz>it's just a way to overcome how the system works <look>divya: A massive quick tip: use `guix import --insert /path/to/guix/gnu/packages/crates-something.scm crate <crate-name>` for adding the dependencies, it will save you a LOT of time <divya>ekaitz: Indeed, that makes sense. <look>You can also pass '-r' too <divya>look: oh, I don't have to manually write the definitions myself? would the versioning and everything else be taken care of? <look>divya: That would be the case, you cant do it for the app package definition directly because its not in crates.io, but since you got all the dependencies from cargo2guix you can just guix import them with the above command <divya>look: That sounds neat, let me try that. <look>divya: make sure to check all the other options too, they are very useful as well: `guix import crate --help` <divya>(This community is great :D) <umanwizard>Hi, how can I force a particular package to be built locally? I thought this was what `guix challenge` was for, but it doesn't seem to do it: <umanwizard>`guix challenge coreutils` for me e.g. just immediately prints "1 store items were analyzed: 1 (100.0%) were identical" <dariqq>umanwizard: try 'guix build --check [--no-grafts]' <umanwizard>I really wish building Guix was faster while bisecting something :D <rekado>ekaitz, divya: "mumi send-email" might help with this workflow. <divya>ekaitz: Oh, I'll check, I was wondering if it could be done within Magit. (pretty cozy in Emacs) <futurile>NOTE: Guix.social patch review and social chitting-chatting is this Friday. Just emailed guix-help so I won't repeat all the links here. However note that Christine Lemmer-Webber will be talking at the last Guix.social of the year in early December. If you want to be notified about that subscribe to the Libreplanet Wiki page so you get updates! <attila_lendvai>is anyone using slime with the r7rs-swank backend while hacking on guix? is it in a usable shape? <luca>futurile: What's guix.social? <efraim>well, I manged to cross-compile zstd for x86_64-w64-mingw32, but I'm not sure about the naming of libraries and such <futurile>luca: we chat about guix, have talks sometimes and do patch reviews. It's roughly every 3-4 weeks. You should check it out ;-) <luca>Will do, thanks for the tip! <ekaitz>futurile: I have at least 2 stupid patches to review that are just docs <divya>futurile: I'm also joining this friday, hopefully I'd have something to participate. <futurile>we have enough patches to review and add to the distro to do patch review sessions forever :-) <ekaitz>futurile: mine are just docs, in fact someone should just commit them but they don't get the attention... :S