<arjan>does anyone now how to fix this when using tramp in emacs to a guix machine through ssh? "File error: Couldn't find a proper `ls' command" <arjan>this happens at completion in find-file by the way <rekado_>arjan: you need to set the remote search path <podiki[m]>I had the same problem and the fix was mentioned here somewhere... <rekado_>e.g. (add-to-list 'tramp-remote-path "~/.guix-profile/bin") <podiki[m]>now I'm blanking if that was a default on a guix emacs, or should be? <podiki[m]>oh it is, but I think the custom one I use maybe dropped that somehow? <podiki[m]>since it is a snippet in source, I think it wasn't inherited then ***stikonas_ is now known as stikonas
<arjan>rekado_: thank you for the hint, fixed it by adding "/run/current-system/profile/bin" <arjan>podiki[m]: the client is also on guix, but I do not see any defaults related to guix <podiki[m]>arjan: the guix emacs package should patch tramp to have this set... <podiki[m]>but if you were on a non-guix emacs and tramp-ing to a guix machine, then yes you'd need to set this <podiki[m]>(my problem was that this snippet was dropped in the package I was using, but I was using tramp for sudo privileges locally) <podiki[m]>huh....can someone else check if guix emacs has tramp-default-path set with the guix directories? I'm not seeing it <podiki[m]>I mean I see the source snippet, but not the changes in the variable or code in the output emacs <podiki[m]>I think the file should be tramp.el not tramp-sh.el; wouldn't there be an error if the substitute didn't find a match? <podiki[m]>I think it is just removing the "-sh" from the file being patched; I'll try later tonight if no one else does <arjan>ah I am actually on emacs 28.1 <podiki[m]>I can test the change and submit a patch later tonight if no one does it first <yewscion>Hello Guix! I have a question, as I may have found a bug while packaging something. <yewscion> https://git.sr.ht/~yewscion/genpro/tree/trunk/item/guix.scm I was trying to build a `guix shell` environment using this `guix.scm` file as the base. The project builds fine, but when it comes to setting up the profile (the steps after the package has successfully been built), it would always fail on the "Building TeX Live font maps" step. The error <yewscion>was from `updmap`; It couldn't find (specifically) `dvips35.map` 'pdftex35.map` and 'ps2pk35.map` when it ran. However, if I add the `--bootstrap` flag to the end ( so: `guix shell -f guix.scm --bootstrap` ) it builds fine and works as expected. <yewscion>Is this expected behavior, or have I overlooked something in the above definition that might be causing this? <yewscion>s/works fine/works fine without specifying `--bootstrap` / <jorge[m]>Hello, as my desktop environment updates <isf>hello, where i can find guix package manager documentation? <nckx>yewscion: I guess I'm missing the (tex) module to reproduce. Could you report that to bug-guix at gnu dot org? <isf>is impossible to read the gnu gnuix manual in spanish <isf>is like speaking to a woman, permanently <isf>and im a man, so is like maybe some part of feminism movement <podiki[m]>ok, I believe the emacs tramp issue is fixed with just changing the source snippet patch from "tramp-sh.el" to "tramp.el" <podiki[m]>though I would have thought guix would throw some error on not finding a match for the phrase (in subsitute*) <yewscion>nckx: I will do so. Thanks for the suggestion! <yewscion>nckx: The "tex" module is on my personal channel, unfortunately. I realize that makes the debugging more difficult. ***yewscion is now known as yewscion_
***yewscion_ is now known as yewscion
<whereiseveryone_>How can I run a custom guix channel off of a particular upstream branch only like wip-python-pep517? <podiki[m]>for a patch that fixes an open bug, should it be sent to patches list and cc the debbug of the open bug? <nckx>yewscion: No problem. I'm not sure it's a bug, I'm just confused, like you. If someone answers with ‘this is expected because x’ I'll be just as enlightened :) <yewscion>Either way, I'll be sure to learn something! One of the things I love most about GNU Guix. <nckx>whereiseveryone_: I can see those being useful to document the daemon protocol (although it's so underdocumented that almost anything would be an improvement), I don't quite see it for Gexps yet. In both cases an example diagramme would say more than words. <nckx>Am I just trying to trick you into making a patch? Possibly! But no. <podiki[m]>nckx: is there supposed to be an error or warning if you do a substitute* but there is no match for the pattern given? <nckx>It's just that I don't find the CheckEmail example very clear. <nckx>I'd prefer it if it errored out by default, with an optional keyword to restore the previous tolerant behaviour. Warnings are a waste of time, they scroll by and are lost. <nckx>podiki[m]: Likely so you can (for-each (substitute foo) (find-files "." "\\.c$")) without having to hard-code the exact set of matching files, which is a pain. <nckx>Having it continue is objectively better in that case, but it should be opt-in IMO. <nckx>I'm not sure where snippets enter the game. Could you elaborate? <podiki[m]>oh, in this case it is a snippet in emacs source field <nckx>podiki[m]: To which somebody will reply ‘no no API set in stone, we'll add a #:must-match keyword instead’ and I completely stop caring because that's just more noise. <podiki[m]>wait, did you mean the file given to substitute? what about the pattern it looks to replace? <nckx>You can't give it a non-existent file. <podiki[m]>right, I mean the string regex it is matching in the actual replacement <nckx>(But yes, #:continue-on-error would be ambiguous, hence my preference for ‘match’ in the name.) <nckx>Yes. Also what I was talking about. <nckx>I bet you could find more than a handful of substitute*s in Guix today that have absolutely no effect. <podiki[m]>well either way, I believe this bug will be squished <podiki[m]>though I wouldn't mind some sort of #:strict mode that gives lots of info on what it matched and replaced or not (I always stumble in guile substitutes).... <nckx>whereiseveryone_: I'm not sure what you mean by ‘run a channel off of’. <nckx>Hell, again, I agree but just make it the default. <nckx>The fact that complex substitutions aren't logged but the simplest recursive copy of an entire directory gets a file-by-line listing isn't some great design decision, it's just random. There's no need to ever say ‘no, *this* (substitute*) must not disturb the tranquility of the build log, we need a keyword’. <nckx>It's a good idea though. <nckx>Not just because I agree, but it helps. *nckx adds both as to-do items, but feel free to do either. <podiki[m]>I guess one could just do a local my-substitute or something for debugging that packaging <podiki[m]>I would file all this away under "stuff to improve packaging, especially for people stumbling along like me" <nckx>Or add ‘punt’ after the (substitute* …), build with -K, then look in /tmp to see if your change(s) applied. It's all possible, but once you actually think about it there's no reason it shouldn't be easier. <nckx>podiki[m]: It's a big file. :-/ <podiki[m]>that's too fancy, I tend to just hit ctrl-c at the right moment :-P <nckx>Does that --keep-failed? <podiki[m]>it is a timing game if the package is real small ***sneek_ is now known as sneek
***janneke_ is now known as janneke
***lukedashjr is now known as luke-jr
<unmatched-paren>muradm: i noticed that if i didn't add (sleep 1) before the (execl #$sway ...) in my wlgreet service, sway would fail to find seatd and refuse to launch. how did you get around that in gtkgreet? ***rgherdt_ is now known as rgherdt
<muradm>unmatched-paren: i don't know how you do it <muradm>but from my snippets i see that i had (sleep 5) also, but commented out <unmatched-paren>next i'll be adding sway 1.7, which will hopefully fix an annoying segfault and maybe an issue with wlgreet/vt switching <muradm>unmatched-paren: what is with vt switching? <muradm>i don't see/can't remember why sleep could help <muradm>may be i will find out it on weekend when submitting gtkgreet tuigreet <muradm>unmatched-paren: cound you share screen / photo of wlgreet by chance? <efraim>20 test failures for python-pandas on riscv64-linux. I'll look at that one later <muradm>guix environment --pure --ad-hoc gcc-toolchain ;; quick drop to environment with gcc <muradm>is there a way to drop to environment with cmake-build-system <efraim>based on the additions in those build systems you'll probably want just something like 'guix environment --pure --ad-hoc gcc-toolchain cmake' for the cmake-build-system <efraim>although I assume 'guix environment --pure insert-package-here' will pull in cmake if it's a cmake package <muradm>efrain: ah, nice point with last one, thanks <muradm>ouch: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS <fnstudio_>hey, i'm an "entry-level" guix user and i'd like to start using guix for provisioning some of my servers; i know how to do that (or parts of that) for simple services such as an HTTPS webserver <fnstudio_>a bit of a dream goal would be for me to be able to deploy something a bit more complicated - e.g. a matrix or a nextcloud server <fnstudio_>i'll be thinking of a simple service that i can start with; i understand that some "candidates" might come with a few moving parts and might be trickier to implement - e.g. matrix (synapse) might not be the best place for me to start? ***wielaard is now known as mjw
<jpoiret>i'm not familiar with synapse, but usually writing a service is more a matter of choosing the service interface, ie how to structure the different service configuration options for the user <jpoiret>properly launching the problem shouldn't be too hard <fnstudio_>jpoiret: hm interesting, thanks, will continue exploring <dcunit3d>i'm trying to write a package that extends flatpak with custom installations. i'm using a gexp, but before any code is evaluated, i'm getting a cryptic message: Unknown # object: "#k" <dcunit3d>i'm not getting a stack trace and i'm new to scheme. i think a module dependency isn't being compiled, but i'm only referencing guix modules. if i use gexp's do i need to add a srfi? <mbakke>dcunit3d: did you include the (guix gexp) module at the top of the file? <jpoiret>you have #k written somewhere likely <jpoiret># is special syntax in guile, it looks at the next character to know how to read the following data. This lets you override the default syntax reader for a specific part of your code <fnstudio_>ardon: this is amazing!! thanks so much for sharing, it'll be super helpful for me to learn - yes i'll try and provide feedback if i notice anything <jpoiret>gexps use that for example, hence why there's a hash at the beginning of gexp-related stuff <jpoiret>you also have #\ to input characters <dcunit3d>if i did, i can't find it. let me see if i can get the hello package to build <jpoiret>can you paste the relevant file at paste.debian.net (or any other paste service)? <dcunit3d>i do have some input strings. i'm looking at examples of packages and services where gexp's are being used. <jpoiret>you wrote #key instead of #:key at line 44 <jpoiret>remember, in Guile, #<char> is special syntax. keywords are #: <dcunit3d>i bought the SICP book to help me learn scheme, but i'm tied down learning statics at the moment, so i haven't gotten as much practice as i would like <jpoiret>have you dabbled in functional languages before/any other languages? <jpoiret>i don't think you'll need to learn formal scheme (much less SICP) to start packaging things in guix <dcunit3d>yes, clojure, emacs-lisp, swift and maybe others <dcunit3d>so far, the guix codebase and associated channels have helped a lot. also, mcron and its tests have helped. <jpoiret>i think you'll be ok, especially with emacs lisp background ***rgherdt_ is now known as rgherdt
<dcunit3d>i noticed that (plain-file ..) is not used on packages, only services. is that the best way to install files from plain strings? <jpoiret>the lack of them in packages is because packages until very recently did not use gexps <dcunit3d>does nix have a language faculty like gexp's? <jpoiret>nix is a DSL, it is not a full programming language like scheme <dcunit3d>it's very powerful to be able to combine the results of builds using gexps <dcunit3d>thanks for the help. i'm at the next step and iterating on the builds. ***Xenguy_ is now known as Xenguy
<efraim>go-1.17.11 builds with gccgo-10, nice <fnstudio_>ardon: hey pretty amazing work that you've done there on the synapse service definition <fnstudio_>i mean - speaking from the point of view of an entry-level user, so that's on a for what my opinion is worth basis :) <apteryx>I'm not sure I understand the ramifications of not having nscd running on a host... say I use something like xvfb-run from guix on top of a buildroot image to run some foreign application... will it load the Guix libc and have that used by the foreign application too? ***rgherdt_ is now known as rgherdt
<jorge[m]>Hi, as my desktop environment updates,example Enlightenment <apteryx>there's no nscd daemon running on that box... can I use the one provided by Guix to set as a service up somehow? <ardon>fnstudio_: Thanks :) my plan is now to build services for some Matrix bridges <jpoiret>apteryx: iiuc, if you don't have nscd running, guix's libc will try to dlopen the host's modules instead of communicating with nscd <apteryx>OK; so I'm exposed to incompatibilities between the Guix libc and the host libc modules <apteryx>if nscd was running it would instead load the modules provided by the Guix's libc? <KarlJoad>Out of curiosity, what would need to happen for KDE Plasma to show up as a DE in Guix? <podiki[m]>is there an easy way to make sure people who responded to a debbug get a response? they are not automatically subscribed if they didn't create the bug report right? <podiki[m]>KarlJoad: roughly I think we need whatever packages are missing for plasma and then at least a kde desktop session file (service?); not sure the details though, might have been discussed on guix-devel in the past <apteryx>KarlJoad: a lot of work done by motivated individuals* ? :-) <apteryx>(that's my canned answered for any "what would need to happen to have X in Guix") <KarlJoad>Fair enough. I was asking more along the lines of, is a new build-system needed? Low-level machinery, really. <KarlJoad>Because that is the biggest thing holding me back from Guix right now. Plasma is too much a normal part of my workflow. <trevdev`>Could the use of a substitutions folder cause the reinstallation of packages during a guix home container/reconfigure? <trevdev`>At this point I am sure something is changing enough for home to feel like something needs re-building. I gc often, but I haven't pulled since my last reconfigure. <trevdev`>I don't wanna build derivations until I want derivations built. I just want to test a new home config <KarlJoad>trevdev`: As in, you want Guix to evaluate your home-environment to double-check that the file is correct, but not build anything? <trevdev`>100% this is how I am having to rebuild things almost daily. <apteryx>KarlJoad: I think KDE things must be using CMake mostly? If that's still true, we already have the necessary machinery (cmake-build-system) <trevdev`>KarlJoad: Yeah more or less, or make sure services/crons are running properly <KarlJoad>If you want to make sure services/crons run properly, you need to build the derivations for everything anyway. To double-check the file, there is no "dry-run" option as far as I am aware. <KarlJoad>apteryx: I have no idea. Perhaps something to add to my ever-growing list of things to do. <trevdev`>KarlJoad: I think my hiccup is I want to use the new guix home, but I haven't adjusted my habits for the whole philosophy of the aggressively reproducible model. The habit of running guix gc after a couple hours of playing because "please don't bloat my system" is an old Arch habit. I came here to settle down once I've more or less learned how it it works <trevdev`>I could have just used the `.config` directory for services/mcron and some package manifests, I probably would have had to rebuild far less often <trevdev`>I think it might be worth suggesting that if someone is using guix home, maybe skip garbage collecting packages required by guix home <KarlJoad>You should not be garbage collecting packages required by your home-environment, unless you delete the generation too. <trevdev`>I have deleted package generations to consolidate that history, I have been told that the logic for how it all works across guix package and guix home is the same. Maybe I should avoid consolidating my history? <trevdev`>The `guix package -l` command shows me everything that's on my system, starting at generation 52, with store hashes. I would think this is concurrent enough for guix gc <KarlJoad>Are you mixing `guix package` for imperative installation and `guix home` for declarative? <trevdev`>I started my home env with guix home reconfigure, and as I add packages with guix package -i (or guix install) and decide I like other packages, I have been adding them to a module that propegates my home packages. <trevdev`>If my home package generations ends up being 3 pages long, I run a `home package -d` to get it back to 1 page. I guix gc around this time. As Guix is a new thing for me, I probably gc 2x a week <trevdev`>So whenever I run a guix home container, or a guix home reconfigure, the packages should always be installed and not need of rebuilding unless I decided to guix pull, yeah? <KarlJoad>Strange that it is doing that for you. Only thing I can think of is that propagation module you talked about. <KarlJoad>They may still need a rebuild, if the package inputs changed somehow. I don't understand how that would happen though, because you have not pulled. <trevdev`>At some point I suppose I need to be brave enough to mail in my config. It has a non-free aspects to it, and I don't want to frustrate anyone with an unsupported config <KarlJoad>Why do you want to prevent Guix from building these derivations? Unless they are big packages, like TeXLive, they usually should not consume *too* much space. *yewscion is back (gone for 11:34.56) <trevdev`>If my package manifest hasn't changed, and all of those packages are installed, and I have not pulled my repositories (channels), why should they need rebuilding at all? <trevdev`>I have 2 problematic packages that keep me coming back: telegram-messenger and emacs-pgtk-native-comp. They both don't have substitutions on the non-gnu subs server. They both burn CPU and several minutes of time to re-build <KarlJoad>Good question. Only thing that can cause re-builds is an input changing. I am not sure what that may be. <podiki[m]>KarlJoad: see previous message for plasma discussion <trevdev`>I can accept avoiding the garbage collection if it means guix home will let me try a new cron without rebuilding. Otherwise, if this is not the intended side-effect of my usage, I am sure I have goofed somewhere that I cannot see. <KarlJoad>I usually don't GC for long stretches of time. I only do it if I pull (on metal) or run out of disk space (on a VM). <ternary>Is anyone familiar with the cargo build process? I have a package that doesn't get vendored when using it in "cargo-inputs" for some reason. But only when built from a git source rather than a crates.io source <trevdev`>KarlJoad: Do you gc prior to, or after pulling? <trevdev`>I assume after as I feel like that makes way more sense. <maximed>trevdev`: Guix never gc's anything that is still in use. <maximed>However, due to grafts, many things can become out-of-use only to be reused on the next "guix home reconfigure" or whatever <maximed>(To test the hypothesis, logs are required) <KarlJoad>trevdev`: I pull, then `guix system/home build` to make sure I update TOFU things (Linux kernel hash), when everything builds, I reconfigure. If everything works for a while, then I delete the old generation, then GC. <KarlJoad>maximed: As far as I understand, a graft is a package that has been rebuilt, with its runtime dependencies changed. <trevdev`>I see, and guix does a great job of obfuscating the dependencies. <trevdev`>If I want to pass a function name with a doc string to a mcron job so that I may `herd schedule mcron` and see a meaningful record of what I've scheduled, how may I do that? Using a lambda all I see is "Lambda function". <trevdev`>The docsting doesn't show up in the lambda, either. <trevdev`>It doesn't seem to want to take the symbol name from a module function, quoted or unquoted. <trevdev`>But it will call that function in a lambda as a closure *yewscion is back (gone for 00:25.49) <unmatched-paren>muradm: sorry, i should have indicated i was away. (vt switching) whenever sway is running on a tty *other than tty1*, when i switch away it segfaults. (wlgreet screenshot) I guess i could, but it's just a box with the word "Login" and a text input labelled "User" or "password"... <unmatched-paren>there's also an issue where i switch away from the greeter in tty1, then when i switch back i lose focus on the greeter and can't get focus back <oriansj>just a silly idea but guix processes sleep and guix processes resume to pause and resume guix builds <oriansj>would really help with builds that locally could take days/weeks <nckx>I suggested it but it was considered too observable. <nckx>Just send STOP in your favourite htop clone. <oriansj>nckx: odd but I guess I'll have to hack together a pair of scripts to share with everyone <nckx>unmatched-paren: I thought I was. <unmatched-paren>nckx: were you? that's great if so, but i thought you said "Noted, but not right now" re the D patch :) <unmatched-paren>I guess, but i didn't want to bother anyone specifically, so I just made a generic request <unmatched-paren>Besides, I was making a request for aerc too, and I guess as an emacs user you wouldn't care much for it :) <nckx>I only clicked on the most aesthetically pleasing bug number. <nckx>unmatched-paren: Forbidden bug. <unmatched-paren>nckx: Inevitably bug 66666 will be about "$GNU_PACKAGE doesn't work on FreeBSD" <nckx>I like how it implies something… happened to the record. <unmatched-paren>#10 is the first one I can access; it's an emacs bug titled "url-gw should support HTTP CONNECT proxies" from 2008 <nckx>unmatched-paren: Meanwhile! Back at the topic: I'm trying to build btdu, if you remember, and the results are promising indeed. <nckx>Now I get a very well-behaved message about all the dependencies I need to package :-/ <nckx>Languages where ‘cannot find ncurses’ does not mean ’add ncurses to the inputs and go enjoy the sunshine’, it means ‘have fun packagaging d-ncurses and d-libeverythingprobably all afternoon’. <nckx>(Guile has that too, but then guile-libeverythingprobably is already packaged in Guix, so sunshine ahoy.) <nckx>Luckily, none of those packages seem to have ‘Dependencies’ on dlang.org <nckx>unmatched-paren: I've never installed or used akku. Nough said. <nckx>I'm not a Guile package maintainer, TBC, but that still means a good deal of something. <nckx>unmatched-paren: Anyway, give me just a bit more quality time with #55999 and D itself and I'll happily merge it. <unmatched-paren>Interesting how D is so much older than Go and Rust, yet it never caught on like they did. <unmatched-paren>I guess it *is* just C++ with a GC, less gross metaprogramming, and slightly better syntax. <unmatched-paren>Suppose there just wasn't enough innovation in there to get people to switch... <nckx><less gross metaprogramming> The worst thing about that remark is that it is technically even correct. <nckx>Or how something can be correct without being true. ***rgherdt_ is now known as rgherdt
<Michal_Atlas[m]>Hello, sorry to intrude, quick question, is it expected that time-machine can't go back more than a little bit? It usually doesn't work for me, and today I tried a commit from 2018 (wanted to fool around with mdl) and it just throws random errors my way (a "You found a bug" this time), every commit seems to give a different error though. Is this the way it just is or am I encountering flukes? <nckx>Honest Bjarne's More Efficient Footgun Emporium & Prosthetics Workshop. <maximed>Mitchal_Atlas: What's the error (paste.debian.net)? <maximed>If it keeps throwing errors, they probably aren't random. <maximed>FWIW, there's a minimal time travel date, but I don't know when exactly. <maximed>Probably it's just a bug & correctly used. <maximed>It's not exactly automatically robustly tested currently. <nckx>Michal_Atlas[m]: I'm not sure you can travel back before the invention of the time-machine, which was in 2019. <Michal_Atlas[m]>Oh, you're right I've used too much software where errors are an acceptable thing to just happen lately, Imma copy it ver. <nckx>Uh, Guix is definitely in that category too but we shouldn't accept it. <Michal_Atlas[m]>Ooh, actually the other commit I tried, gives a different error message, but in the end references the same issue. <jpoiret>nckx: i think time-traveling back then should be ok <jpoiret>time travel uses the same mechanism as guix pull <nckx>Nor mine, hence the weasel wording. <nckx>unmatched-paren: You are D expert, da? <nckx>The dub-build-system is complaining about the absence of dub.json. <nckx>There's a package.json though. <nckx>Yes, it detects the 3, I think. <nckx>At least I vaguely remember seeing a 3-clause or statement earlier. <nckx>Also, not surprisingly, unsuccessful. <GNUtoo>hi, what can I use after the #! to make the script compatible with all the distributions around here? <GNUtoo>Guix lacks /usr/bin/env in guix shell -C though <unmatched-paren>GNUtoo: pretty much any system can be assumed to have env. it's part of coreutils. <GNUtoo>s/Around here/that are somewhat maintained/ <GNUtoo>So the solution would be to add /usr/bin/env or does the program behind #! respect the $PATH ? <nckx>unmatched-paren: Because that's what it asks for, and using just dub.json didn't work (tried that first). 🤷 <gabber>GNUtoo: usually you put the path to your usual distro <gabber>in guix this is converted (at build time) to the path of the specified interpreter that is present on your specific system configuration <unmatched-paren>nckx: that's pretty strange. it should use dub.json, then dub.sdl, then package.json. <nckx>GNUtoo: Shebangs do not use $PATH, that's /usr/bin/env's only job. <GNUtoo>To give more background, I'm using scripts in ./configure and in tests of a library I maintain, so ideally these should work on all distributions, including Guix <nckx>#!/usr/bin/env foo → look up foo in $PATH and run my script with it. <GNUtoo>And the issue is that there is no /usr/bin/env with Guix shell -C <unmatched-paren>GNUtoo: Guix has a patch-shebangs thing that makes scripts work automatically <nckx>GNUtoo: The only thing that exists in shell -C is /bin/sh, which is quite portable but not considered as modurn as /usr/bin/env. <GNUtoo>if /bin/sh is in other distros as well that could work for me <unmatched-paren>nckx: can you paste the output of dub when you have .dub/dub.json created? <GNUtoo>I wonder if some distributions have it in /usr/bin/sh though <GNUtoo>At least in Parabola and Trisquel 9 /bin/sh work <nckx>GNUtoo: ‘Other distros’ is too absolute. There isn't a shebang that will work on every niche disto in existence. /usr/bin/env is most likely, then comes /bin/sh (and you're limited to POSIX sh with that). <nckx>Poking around to see what happens to exist on random distros you have lying around is a worse answer than the ones you got here. <GNUtoo>So I guess I need to stick with /usr/bin/env and add /usr/bin/env to guix shell <GNUtoo>Else I end up in a situation where I've to choose between Guix and other distros <unmatched-paren>Guix also patches /usr/bin/env ... to /gnu/store/... before building a package <GNUtoo>to be more clear my issue with env is that there is no /bin/env or /usr/bin/env in guix shell -C but env is in path at /gnu/store/ahmmahqib7pab67gwfp74p8rd67f5skv-profile/bin/env <nckx>GNUtoo: <So I guess> Yes. <unmatched-paren>Hmm... not sure why /usr/bin/env can't be accessed in the container. <GNUtoo>There is only /bin/sh and nothing else in /bin and no /usr/ <nckx>Guix shell is not a distro, it's a minimal contained environment. /bin/sh being there is weird. I wonder if something breaks without it. <nckx>/usr/bin/env works fine on the distro Guix System. <nckx>If your host distro has it there. <nckx>Which Guix System does, and most others should™. <GNUtoo>Here the fix is me or someone else making a patch to fix it, else we can't really execute portable scripts in guix shell -C <nckx>I think that ‘shell -C’ being minimal by default is a good thing. <nckx>Lots of things won't run in an empty container. <GNUtoo>Is there a way to use --expose in manifests? <nckx>I don't think shell scripts are special. <unmatched-paren>GNUtoo: wdym? you're doing `guix shell -C -m manifest.scm`, right? just add --expose *GNUtoo likes when things work without hacks <apteryx>nckx: I'd favor removing /bin/sh in containerized environment <apteryx>it often leads to discrepancies with what we see in the build chroot <GNUtoo>Here it's pretty clear that the container doesn't have much things, and that you need to install coreutils and so on, it's by design <nckx>apteryx: Why is it there in the first place? Does some low-level thing (glibc, guile) need to exec /bin/sh? <GNUtoo>but I'm not sure that breaking scripts by default should be by design <apteryx>nckx: I think it's the shell executed after entering the container, perhaps? <nckx>GNUtoo: It's a feature, not a bug. :) <nckx>GNUtoo: Why do you need this shebang in the first place? <unmatched-paren>you won't have coreutils by default, so sh scripts almost certainly won't work <GNUtoo>The discussion about removing 'sh' here seems to indicate that but I don't get the point of removing /bin/sh or not having env <nckx>If the shebang breaks things, can you get away without an explicit shebang. <unmatched-paren>GNUtoo: it's supposed to isolate the contained programs as much as is physically possible <nckx>GNUtoo: Because adding random programmes that are (truly) useful to somebody is still defeating the point of having shell -C in the first place. <GNUtoo>indeed, as I understand you do guix shell -C <packages> and that's how it works, and --expose should be in special cases I guess <nckx>As unmatched-paren says, the next person will want python, because Python scripts are common. <nckx>And you can't do much without coreutils, so why not— etc. <GNUtoo>unmatched-paren: yes, the /bin/sh or /usr/bin/env would be isolated too, or maybe I'm missing something? <unmatched-paren>which means unsharing (I think that's the term?) as many resources as physically possible <GNUtoo>oh ok, that's what I didn't get before, because I had only -C in mind <GNUtoo>with -C we have: /bin/sh -> /gnu/store/fpm43sm4y6x39h4mjf6wnn19pn9ykkh0-bash-5.1.8/bin/sh <nckx>GNUtoo: Nobody is running ‘guix shell -C’ interactively. So they are starting it because it's either part of your build script or -instructions (a README or so?), so why can't that invocation just include --expose=/usr/bin/env? <GNUtoo>And here the host is Parabola so that's clearly not the host in this specific case <GNUtoo>Oh ok, I used that interactively <GNUtoo>(I use it to build software with Guix dependencies, do tests, etc) <unmatched-paren>if you want to do that, surely you could just write a guix package for it? <GNUtoo>I've that too, but the uses cases are different <nckx>How should I phrase this. It is started ‘on demand’, by a human. It's not like a distro that's ‘just there’, like Guix System (which again, has /usr/bin/env for exactly this convenience). <berkowski>Are packaged installed with `guix home` not supposed to show in `guix package -I`? <GNUtoo>I don't use 'guix build -f scripts/guix.scm' during development, but I sometimes use guix shell during development <nckx>If that human wants to run scripts, they need to add coreutils, bash (well, clearly not, but ideally they would), to the ‘guix shell’ command line. <GNUtoo>The difference is that guix build rebuilds the software from scratch, and copies it all in /tmp/ <nckx>And has automagical patch-shebanging. <unmatched-paren>GNUtoo: it would be nice if guix could start builds from a specific phase <nckx>You might be the first to ask for a *start* :) <GNUtoo>Like for instance I found several bugs with make dist && tar xf path/to/tarball && guix shell -D and ./configure && make && make check that I wound't have found with guix build <GNUtoo>(I forgot to ship test files in the tarballs) <nckx>How did ‘guix build’ run the tests? <GNUtoo>I used the local git source with guix build <GNUtoo>(local-file (dirname (dirname (current-filename))) #:recursive? #t)) <GNUtoo>And it depends on git for the revision <GNUtoo>A compromise here could be to add exports inside the manifest? <GNUtoo>The manifest is part of the environment somehow so it could make sense to have them there? <nckx>Not an environment in the same sense, I think. <nckx>Manifests are lists of packages. <nckx>People keep trying to add MY_FAVOURITE_ENV_VAR to them but they've been held off so far. <GNUtoo>Someone managed to run the Android SDK in guix through many exports and so on, so at some point the number of --exports become big <GNUtoo>So it would make sense to save that in a file somehow <GNUtoo>yes that could probably be better, this way manifest is for packages and environment.scm would be for packages + extra settings <unmatched-paren>environment.scm could just act like a local version of guix home -.o.- <nckx>Yes, it should be an extra layer, not forced into manifests. <nckx>Oh look it's an extra layer :) <singpolyma>Right. Home and system are mostly the same to me <GNUtoo>guix home looks closer to guix shell + some command line flags <unmatched-paren>It could also allow you to start services I guess, if you needed that... <GNUtoo>What are the limitations of Guix home? can it instanciates a new home without touching the one you are using? <GNUtoo>wow nice, so if the perfs are roughly the same I just need to use guix home then <nckx>I wish there were some way to express ‘guix shell -C coreutils --expose=$(guix build coreutils)/bin/env=/usr/bin/env’ <nckx>Unfortunately, guix shell -C coreutils --expose=$(guix build coreutils | grep '[0-9]$')/bin/env=/usr/bin/env ain't it. <nckx>Well, it is, but hell no. <nckx>But yes, this is starting to sound like an extra-special-files-service, isn't it. <GNUtoo>What I don't understand is how to create a /usr/bin/env in home.scm <GNUtoo>ah I think I found it, special-files-service-type <GNUtoo>Though I'm not sure it works in guix home <fnstudio_>hallo :) when editing a guix definition under emacs, is there anything like elisp's `ctrl-h f' to get to a function definition? <GNUtoo>So the solution would then be to (1) add special-files-service-type to guix home (2) make a home.scm instead of a manifest.scm <unmatched-paren>you wouldn't be able to declare a special-file for anything outside of it <GNUtoo>indeed + you'd need a ton of setup to use that <unmatched-paren>GNUtoo: yes, there are no differences between reconfigure and container except that the latter is temporary <nckx><ton of setup> I wonder how much that could be reduced (not sure I'd call it a ton even now, but definitely more than strictly needed). <GNUtoo>unmatched-paren: ahh expose doesn't do what I thought it did, it will take the host /usr/bin/env... <nckx>Making system definitions so light-weight they can become the go-to abstraction beyond manifests is a compelling idea (without thinking it through, anyway). <GNUtoo>Guix pack has something nice for that kind of stuff, you can create symlinks <nckx>Hence my attempt to ‘expose’ coreutils above, which isn't strictly pure but would end up with a matching Guix version at least. <GNUtoo>for instance "--symlink=/usr/bin/env=bin/env" <nckx>You could quite easily copy out the relevant code into a Guile script though. It's rather simple. <nckx>And doesn't rely on anything Guixy, just $PATH. <GNUtoo>So here I'm a bit lost on the options left <GNUtoo>maybe if I add the ability to run some simple services (that create files) in guix shell it could work? <nckx>Hey, guess what I forgot. unmatched-paren's question. Sorry! <nckx>And no, (rename-file "package.json" "dub.json") doesn't suffice. <nckx>unmatched-paren: What, this makes sense to you? <nckx>Are you in cahoots with D? <nckx>But why does it need both. <nckx>Well, maybe the build system just assumes it does, throws an error early, but only actually uses one later on. <nckx>I didn't check that, because I need a break. <nckx>Yes. I wonder if it will work if we relax some dub-build-system check. <nckx>I'm taking the dub-build-system as documentation on ‘how do dub work’ but it appears that might be risky. <unmatched-paren>Maybe dub used to produce this file as generated metadata, but doesn't anymore. <nckx>.dub is in upstream's .gitignore but that might also be cruft. <unmatched-paren>Or I guess maybe this particular package sensibly doesn't check it in to their source repo. After all, it seems to be a generated build output. <nckx>Sure, but I meant that it appears not to be generated any more. <nckx>Or sure, maybe our -build-system is erroring out bogusly before it can be. <unmatched-paren>Okay, I'll submit a patch to that same thread fixing dub-build-system. <nckx>Now I'm getting fatal error: cannot find ‘ld’ <nckx>You dealt with that, non? <fnstudio_>if i understand it correctly, the idea of using "service" in the context of guix home is just because the extension mechanism resembles (or is the same) used by shepherd? but there's no real service involved, in the traditional sense... <unmatched-paren>nckx: I'll need to add ld-gold-wrapper to the default dub-build-system inputs <unmatched-paren>if you look at the "D fixes" patches, you'll see i added it manually to dub and d-tools <fnstudio_>unmatched-paren: ok, if sometimes that's an actual service, then i guess there's a good basis for the naming choice <nckx>fnstudio_: It's not a home thing. Guix System services != daemons either. <nckx>They can be, but it's not a synonym. <nckx>They are actual services. <nckx>I was not expecting that. <fnstudio_>i see... interesting... i was surprised by hearing of a bash configuration, for example, as some kind of service <fnstudio_>but i guess it makes perfect sense in the larger scheme <nckx>‘One shot services’ is, I think, what you'd call them 10-20 years ago, or maybe in systemd, but I've GC'd the little I knew about that feller. <nckx>I knew this would end in (gnu packages commencement). <nckx>Import darkness my old friend. <nckx>This was oddly simultaneously worse and not as bad as I expected. <nckx>I know a lot less about D{,ub} than I expected to at this point (that is, nothing). <nckx>That will probably avenge itself soon. <nckx>Tasty cargo from the gods 📦 <nckx>unmatched-paren: Do you have background reading for ‘doesn't like’? <unmatched-paren>nckx: yeah, looks like .dub/dub.json isn't produced anymore, from testing on (module-ref (resolve-interface <nckx>If I get this package over with, I'll try building everything with that part commented out or adjusted to whatever it is now. <unmatched-paren>I'm just preparing a patch to guix/build-system/dub.scm and guix/build/dub-build-system.scm <nckx>unmatched-paren: Once one's aware of the gold gotcha, packaging seems to proceed apace. <nckx>Thanks for dragging dub-build-system back into relevancy. <nckx>Will I ever like this language? Probably not. But it's good to have, a surprising amount of software is written in it (by which I mean: any). <nckx>Like a less popular Ada (ouch). <unmatched-paren>The elegant simplicity of C++ and the low-level control provided by Go!(TM) <lilyp>If only other misguided “improvements” of C suffered the same fate. <unmatched-paren>Someone just add first-class tagged unions, defer, and better syntax to C and I'll be happy. Which is why I like Hare. <unmatched-paren>nckx: specifically, that patch should let you remove ld-gold-wrapper from inputs and remove the copy-file from package.json to .dub/dub.json <nckx>That's all I needed to add, so that's great. <nckx>Setting LD/CC isn't my best hobby, but it's hardly rare. <GNUtoo>About sway, did some people managed to launch it wihtout gdm? <GNUtoo>In guix system I managed to launch it with sddm by running seatd -u gnutoo -g gnutoo and also running elogind as service <unmatched-paren>GNUtoo: there's currently no greeters for greetd other than agreety available <GNUtoo>For some reasons seatd and elogind services conflicts but I've no idea if it's on purpose or not <unmatched-paren>but elogind is a steaming lump of doom carefully extracted from systemd <GNUtoo>because using both works for me but not using only one at the same time <GNUtoo>ok, what is different is that I tried to launch it with sddm, so sudo su + screen + seatd -u gnutoo -g gnutoo + entering my password in sddm worked, other configurations didn't work <GNUtoo>I didn't try to use the tty to start it though <GNUtoo>probably and maybe sway requires seatd and not elogind <lilyp>In a perfect world everything would use my libseat abstraction layer. <lilyp>And it's written in Rust with only 12000 dependencies. <GNUtoo>ahh ok maybe that's related with my issue, I don't have rust (i686) <bjc>lilyp: how'd you learn to program so good? <GNUtoo>Basically mrustc requires more than 3GiB of RAM, so maybe I should try to reproduce my issue on x86_64 to see if it's related or not <lilyp>bjc: Simple, I just copy-pasta'd every other Rust code I could find until I somehow ended up with a functioning program. <bjc>wow! that sounds like very advanced ai! <bjc>i have to pay github $10/month for such modern technique <lilyp>I think there's a deep learning decision tree in there somewhere, but it got mixed up with a recommender system 600 commits down the line and now I can no longer reproduce the paper I wrote yesterday. <lilyp>It still works for image recognition tho (I think) <bjc>move fast nad brake thngis *nckx adds a liblily libseat abstraction layer back-end to libseat. <lilyp>Don't forget to delete the original libseat source code so that we have a bootstrapping nightmare. <lilyp>It's fine, cause I vendored my own heavily patched libseat reimplementation in Brainfuck. <nckx>It bootstraps itself with a binary in the source tree. <bjc>i bootstrap under the pale light of a harvest moon, my keyboard rinsed in a lake of frozen salt. when the chorus of wrens falls silent, i press “return” and the dark ritual begins <unmatched-paren>nckx: ah, you see, this is special enterprise pizza. to make enterprise pizza, you need enterprise pizza. <nckx>I mean, I guess you do need yeast for tasty zah. <nckx>So it's not entirely untrue. <lilyp>And here I thought my joke was actually silly for once... <vagrantc>well, aarch64 seems to be practically free of rust ... <GNUtoo>For rust I'm unsure what to do too, like I managed to build it under 4GiB, so if we merged the patches at the time we'd have substitutes (because the build machines use x86_64 kenrels, so userspace can use 4GiB) but users running i686 kernels wouldn't be able to rebuild them... <GNUtoo>(processes can have up to 3GiB of memory when running an i686 kenrel) <GNUtoo>Basically I removed -g if I recall well, which made the thing fit between 3GiB and 4GiB <maximed>Apparently ‘Fat LTO’ takes can require much more memory. <GNUtoo>ok, I probably need to remove that too <maximed>Maybe rustc (or at least, old rustc's in the toolchain) are built with fat LTO, and it can be changed to thin lto? <GNUtoo>I don't remember if the other patches I had also shrinked the memory usage, though I need to rebase them now as mrustc changed a lot <GNUtoo>Maybe removing lto completely would also work <maximed>Is the hamburger button on ci.guix.gnu.org supposed to do something? <nckx>unmatched-paren: Perfectly, thank you. More ufortunately, a thing called ‘inputs’ doesn't seem to work in the dub-build-system, which is a wee bit of a blocker. <nckx>Unresolvable dependencies to package ae: <nckx> btrfs ~master depends on ae ~>0.0.2830 <nckx>Somehow I doubt that the hamburger was updated to use the latest wasm any time in the past 5 years. <maximed>(TBC, I mean the big hamburgur on the top, not the small one on the right) <nckx>It's in the top right, maximed. 😛 <nckx>There are no ‘big’ and ‘small’ burgers, there is only one. <nckx>maximed: tobias.gr/burgher.png <nckx>unmatched-paren: Is that really relevant? <nckx>I just don't know how to answer that. <maximed>nckx: I meant ci.guix.gnu.org, not guix.gnu.org <nckx>You're right, I missed that. <maximed>FWIW the burger only appears when zooming in <nckx>It replaces Status, yes? <nckx>maximed: By the way, I don't need to zoom in here. <nckx>unmatched-paren: Yep. It's a ‘du’ for the better file system. *unmatched-paren hoping dub has a vendor option... <nckx>unmatched-paren: Eh? As in support? <nckx>Do you have access to a support contract…? *unmatched-paren also confused. <nckx>> unmatched-paren hoping dub has a vendor option... <nckx>Implying you sell D software, or so I thought. <maximed>I was thinking it referred to bundling. <maximed>Apparently some use vendoring=bundling <unmatched-paren>"vendor option" means "option to use a directory for D packages instead of downloading them from the interwebs"... <maximed>unmatched-paren: Maybe it has an option to use the version installed by the OS package manager? <unmatched-paren>maximed, nckx: The guix Cargo bundling directory is called guix-vendor, and the argument that stores its path is #:vendor-path... <maximed>unmatched-paren: FWIW, nowadays Windows has a package manager. <nckx>unmatched-paren: So it's a separate a directory for the seller (distributor) as opposed to author? <nckx>Assuming proprietary software by default, wonderful. <nckx>Strange that Cargo uses that proprietary lingo. <unmatched-paren>Basically just allows you to use local files for dependencies instead of downloading them. <nckx>I wasn't questioning your bona fides, just their choice of language. <nckx>> Implying bundling equals selling. <unmatched-paren>Adds a local package directory to be used during dependency resolution. This command is useful for registering local packages, such as GIT working copies, that are either not available in the package registry, or are supposed to be overwritten. <unmatched-paren>Annoyingly it doesn't use "vendor" or "bundling" in the description, so i couldn't /-search for it. <nckx>(The words it does use are more clear to me, so I'm not complaining, but I see your point.) <nckx>unmatched-paren: Who says that?? <nckx>I've seen HG (doet wat het belooft) but not —ah, OK, phew. <unmatched-paren>(although linux is derived from UNIX, which actually is stylized with capitals, so...) <z20>I'm going a fresh install of Guix System on some rather old hardware, but I only see dots rather than package names now that it's downloading packages (e.g. "111MB will be downloaded\n...\n.\n..\n.....\n"") <nckx>unmatched-paren: Do not get me started on that 😃 (It's not… exactly.) <unmatched-paren>z20: maybe it's doing one of its "oh no the network disconnected, I'm going to hang and/or give a confusing corrupt archive message instead of saying 'network disconnected'" things. <nckx>The dots are expected, the newlines not so much. <nckx>I think .... is what the progress spinner uses when it thinks it can't reliably send control codes. <nckx>z20: I think what you're seeing is ‘normal’, just inelegant output multiplexing by different parallel download jobs. <nckx>One doesn't know what the others are doing so they just all blurt things at the terminal. <z20>nckx: That's interesting. I had a corrupted archive message last night. (The newlines are literal, I'm just representing them that way). I guess I'll see what happens. <nckx>(Right, I was referring to ‘real’ newlines too.) <unmatched-paren> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /tmp/guix-build-rust-cargo-0.53.0.drv-0/cargo-0.53.0/guix-vendor/rust-libgit2-sys-0.12.25+1.3.0.tar.xz/build.rs:198:39 <nckx>True, but not what's going on here (but give it time! Have faith.) <nckx>unmatched-paren: I keep getting called AFK, but at last: that worked perfectly, thanks. <nckx>Well, the test suite is still running, but it does find d-ae. <nckx>You have to run it before 'check (or thereabouts), not after 'unpack. ***caleb__ is now known as KE0VVT
<nckx>It's also hor-ri-ble, taking us back to the opaque Rust status quo of source-based-but-bad packaging. <acrow>I was about to abandon #guix to restart emacs after adding emacs-exwm. Maybe this is excessive, no? Additionally, emacs is running in another long-running xfce session. Maybe that too needs to be restarted after a guix home reconfigure? I hate it when things, later, start to go wonky after I've forgotten my mischief. <acrow>BTW -- R, is, of course, for reproducible builds.... <acrow>ok, after instantiating a new emacs instance I see exwm commands. *yewscion is back (gone for 04:16.21) <justkdng>how can I run an (invoke) but with certain environment variables? <rekado>justkdng: just use (setenv "FOO" "bar") before invoke. <acrow>vagrantc: Checking it out... <acrow>vagrantc: Yes. And since 'R' is all about math -- you might think reproducibility would be important. 