<nckx>mbakke: If you don't think it's noise 🙂 Done. <sirgazil>I think I missed that bug report and reported mine because I searched for gio-launch-desktop is:open... <sirgazil>This is one thing I don't like about debbugs and other issue trackers: that the developer is the one who says if an issue is fixed. But, in this case, the fix is not in production yet, so the problem is not fixed for the bugees. <sirgazil>I tried the workaround in Thunar on Xfce, Caja on MATE and Nautilus on sway, and problem solved :) <jsoo>Blackbeard: I was confused forever about console fonts too. I think you can specify the full path, without a flag, too <jsoo>raghavgururajan: hi raghav! <jsoo>mbakke: how’s the cargo importer going? <raghavgururajan>nckx So for time being (until I get my device back), I am using my friend's laptop. I installed guix on the ubuntu. I installed glibc-utf8-locales and exported the PATH variable. But still I get the error "Could not set locale". What should I do? <Blackbeard>sirgazil: ah good. Somebody asked about it recently. Great to hear it has an easy fix <guix-vits>nickname: PT***************S0 -- "are you sure you ain't mistaken login and password fields?" <nothingmuch>is (concatenate-manifests (list (specifications->manifest '(...)) (load "some_other_manifest.scm")) idiomatic/good style? <nothingmuch>fwiw the context is manifests in version control for the same project, the first is a daemon running on a service that fetches data, and the second is a jupyter notebook environment run on a user's machine, which inherits all deps of the daemon <guix-vits>nothingmuch: i ain't dev; from my point of view you shouldn't worry about style so much with Lisp -- so long as modularity is there. <guix-vits>"... we change them as our perception of model deepens, enlarges, generalizes until the model ultimately attains a metastable place within still another model with which we struggle." -- Foreword from SICP. <Blackbeard> make DESTDIR="${pkgdir}" BINDIR="/usr/bin/" install <nothingmuch>guix-vits: i don't mean formatting etc, just the use of 'load' from a manifest <nothingmuch>i didn't find any reason in the guile docs to suspect it's a bad practice, but in other languages that kind of stuff often comes with some baggage (search paths, changing interpreter state, etc) <guix-vits>nothingmuch: You'll change it later, anyway :) <nothingmuch>that's not what worries me, that's kind of a given, my concern is creating a mine field for anyone who comes after me since i'm not experienced with guile/scheme <guix-vits>nothingmuch: "i'm not experienced.." + "not want to create a mine field" = /0 :) (but i'll stop my flood) <nothingmuch>basically, from a modularity POV i agree with everything you said, and this seems modular to me <nothingmuch>but given my experience with other languages, treating a file of source code as a nullary function is an over simplification <nothingmuch>Blackbeard: i think make-flags would suffice, since the install phase includes it inthe make invocation, and those variables probably won't interfere with targets other than 'install' <nothingmuch>if DESTDIR is like a prefix, then something like #:make-flags (list (string-append "DESTDIR=" (assoc-ref %outputs "out"))) <nothingmuch>(there are plenty of examples in gnu/packages/... fwiw) <nothingmuch>well, i didn't read that package's Makefile, so i don't know how it interprets DESTDIR and BINDIR <nothingmuch>but (assoc-ref %outputs "out") will give an appropriate prefix for the package's output which can be supplied to make <Blackbeard>nothingmuch: however the package is not working :( <Blackbeard>i think i'll have to set all of the flags manually <nothingmuch>Blackbeard: not sure what you mean by manually. how does it break? does it install to the wrong path? does make install error? <Blackbeard>it install to the right path, but the binary is nested inside %outputs/usr/games/blobwars <nothingmuch>i think the right approach would be to set DESTDIR=%out, BINDIR=/bin to override BINDIR=$PREFIX/games,and also set PREFIX=/ for other data <nothingmuch>i would try (list "RELEASE=1" (string-append "DESTDIR=" out) "PREFIX=/" "BINDIR=/bin")) <genghis-sean>Hey #guix! I'm having trouble running guix pull on a GuixSD installation. I just got a seg fault. Do you all have any tips to debug it? <guix-vits>Blackbeard: i'm not sure if it mean "(((sed)))" :) <nothingmuch>is uppose (list "RELEASE=1" (string-append "PREFIX=" out) (string-append "BINDIR=" out "/bin")) <nothingmuch>it's kind of iffy both ways because the makefile variable declarations don't provide a clean wayto set the basename of BINDIR <Blackbeard>guix-vits: well I am not sure, the part you sent me is about werror, but that is already fixed <nothingmuch>Blackbeard: oops, BINDIR will need a trailing slash, so (string-append "BINDIR=" out "/bin/") <nothingmuch>Blackbeard: why are you explicitly setting RELEASE=1 ? that appears to be the default <guix-vits>genghis-sean: installed recently or this is happens after an update? <nothingmuch>Blackbeard: you can also just set DESTDIR, and (substitute* "Makefile" "\\$\\(PREFIX\\)/games" "$(PREFIX)/bin") after unpacking <genghis-sean>guix-vits: I installed it sort of recently. The last update was Feb 20 <Blackbeard>sort of though, the binary runs but complains about missing fonts <guix-vits>genghis-sean: can you roll-back and pull (yesterday pull on my x86 works) again? <nothingmuch>Blackbeard: is that distributed separately? the makefile does try to install it (PAKNAME) <Blackbeard>nothingmuch: yes it is distributed in a different package and url <nothingmuch>does the buildpak target need to be run on that or is that something else? <guix-vits>not sure if this needed there, just in case. <nothingmuch>that would cause the $ALL variable to contain "buildpak", which would cause it to be built <nothingmuch>as for adding $(LIBS) - no clue if that's appropriate, i guess if buildpak target fails <Blackbeard>blobwars-data-2.00.tar.gz: HTML document, UTF-8 Unicode text, with very long lines <nothingmuch>i think you want mirror://sourceforge/blobwars-data/blobwars-data-2.00.tar.gz <guix-vits>nothingmuch: `guix download ...` printed "following redirection to..." multiple times, but returned html too. <nothingmuch>fwiw guix download mirror://sourceforge/blobwars/blobwars-2.00.tar.gz WFM <genghis-sean>guix-vits: after rolling back I was unable to login through my normal user or the root user <genghis-sean>It looked like the password was correct, but there was no desktop environment to load <nothingmuch>i think just adding USEPAK=1 to the make flags will build the data from gfx sound music, etc <nothingmuch>i guess debian and other distros just package it separately? <nothingmuch>not sure what the rationale is, but i think a more guix-ish way to do that would be to have a single package with multiple outputs <nothingmuch>i guess that would allow reuse of the data in case the code changes? <guix-vits>genghis-sean: i'd similar: deleted user with UID 1000 and my user with 1001 become 1000; i was unable to login, because no access to home dir. idk about root. <genghis-sean>I rolled forward back to gen #2 and it seems like something is corrupted <genghis-sean>Yea, I wonder if a fresh install is in order. This time a shared library couldn't be found so my guix commands are aborting <guix-vits>genghis-sean: if that was not, try "manual" installation this time? <nothingmuch>Blackbeard: sorry, can't ATM, i need to run off for a bit... i'm glad it works though, and i would read the guix manual on multiple outputs to see if the same approach as other distros makes sense for guix (i can't remember if identical outputs can be shared between different derivations) <nothingmuch>fwiw you don't need (string-append "USEPAK=1"), just "USEPAK=1" , and since you have a subsitute* already, maybe it'd be cleaner to substitute "\\$\\(PREFIX\\)/games/" with "$(PREFIX)/bin/" <nothingmuch>i also forgot when it's more approrpiate to use snippets and when it's more appropriate to add another build phase for substitution *guix-vits guix package -f Blackbeard_blobwars_reshaped_for_use_with_f_flag.scm .... <genghis-sean>welp my computer seems pretty unhappy. I might just call it a night <guix-vits>Blackbeard: i'd to add to your definition a (string-append "RELEASE=1") <genghis-sean>I tried reinstalling guixSD and the final step failed. After going back through the steps the installer can't find any disks to partition anymore :/ <guix-vits>without it `blobwars -version` returns (Version 2.00, Release 0) <guix-vits>yes, at least in Debian page. Maybe source-forge tar has another ones? <genghis-sean>eh, shit happens. Hopefully I'll be able to squash the bug and make someone else's guix install go smoother <guix-vits>Blackbeard: when game is started, there is a message at top right corner: "No Medal Key found - Online functions disabled", idk what it is. <guix-vits>in ~/.parallelrealities/blobwars/ there is, indeed, no any key. <guix-vits>Blackbeard: probably you're right ("The game also contains an in-game "Medal" service, which allows players to receive award notifications for performing certain tasks, not unlike the trophy and achievements system found on PlayStation Network and Xbox Live." -- Wikipedia) <Blackbeard>guix-vits: oh thanks for that link! they have more games :) ***apteryx_ is now known as apteryx
<divansantana>Is there a workaround to assist with installing node packages on guix? I think npm is not yet available in guix. <efraim>we have npm, it's part of the node package <guix-vits>efraim: Is the @url and @uref are the only <a> marks in .texi? (/doc, http vs https links) <efraim>guix-vits: I have no idea, I don't have a good grasp of texi formatting. I normally just copy from other packages <rekado>guix-vits: you can take a look at the comprehensive Texinfo manual (in Emacs or another Info reader). <guix-vits>rekado: "For the second edition we are particularly grateful (...), and to David Jones, TEX wizard extraordinaire." -- no way XD <janneke>efraim: thanks for the libstdc++ patch, that could enable me to remove one or two of my hurd patches *janneke is now looking at a python build regression :-( <janneke>"Fatal Python error: Py_Initialize: can't initialize time" -- this was one of the first things that I fixed by patching glibc, what could have happened?? Hmm <efraim>janneke: :) I tested it with aarch64 and with powerpc, it feels like bikeshedding for aarch64 but necessary for other architectures <janneke>yes; i didn't think of using another gcc version, arch-based; but the hurd has a similar problem <PurpleSym>(In fact it’s a dependency of python-virtualenv, which recently got a major version bump.) <efraim>I was looking at the couchdb patch and it looks like there's a bunch of bundled libraries. Then I checked erlang and it looks the same. I wonder if we're doing erlang packaging wrong :/ <PurpleSym>efraim: I don’t know anything about erlang unfortunately. For couchdb I tried to unbundle the build system, but it did not work :/ <efraim>PurpleSym: so you sent the patch? <nckx>PurpleSym: Indeed, virtualenv should propagate importlib-metadata for its run/plugin/base.py. *nckx wonders why python-virtualenv propagates none of its inputs. <nckx>PurpleSym: Done on master. <janneke>hmm, maybe it has to do with the cross build (or /cough/ containerized build?) <guix-vits>Thanks, nckx. if some link accessed by https doesn't throw an cert-error but redirects to http, this link should be written as http in /doc? <guix-vits>i'm use curl to test https-accessebility in .sh <nckx>guix-vits: If the server responds over HTTPS, even oddly, prefer HTTPS. Upstream can fix it later. <NieDzejkob>nckx: python-build-system's wrapper suffices for python-virtualenv <nckx>NieDzejkob: I assume you're not talking about p-b-s's ‘wrap’ procedure (which wraps {s,}bin & doesn't seem relevant here), so am curious what you mean. <NieDzejkob>I didn't realize virtualenv could be used as a library <nckx>I think that's the only way. <nckx>Nobody's ever told me that :'-) <NieDzejkob>nckx: everybody told you you're noone so far? That's sad... <janneke>ah, my new bootstrap glibc is fubar'ed -- the conditional source patching to trigger rebuilds did not work, of course! <janneke>nckx: not being called at all, that's bad *nckx buys phone, waits for friends. <nckx>C'mon this is what the adverts say happens. <OriansJ>*friends reject nckx because of the phone he buys because he watches too many ads* <OriansJ>nothing one can buy brings friendship, the closest thing commercially is hookers. *nckx snorts while eating noodles. <guix-vits>Sent patch. Please, if that will be committed, add: "Guided-By: nckx on IRC" to it. <OriansJ>or employees depending on your capital allocation and who you preferred to be the fuck'd party to be. <guix-vits>OriansJ: i'm not parsed your latest message. Can you explain it in simplier words? <anadon>I'm having to train on a LIMS system, and I swear the entire field of programs here are terrible. And the documentation sucks. It is a heap of bad ideas whose owners think the cloud will save them. <sneek>Welcome back Veera, you have 1 message. <sneek>Veera, NieDzejkob says: Don't worry about lambda expressions. It's a simple concept with a scary sounding name - a lambda is just a function that doesn't have a name <Veera>NieDzejkob: oh then it's easy <Veera>in guix can't we have root user password <civodul>anadon: i think you can discuss GWL things here <civodul>anadon: if you don't get a timely reply here, you can try the gwl mailing list :-) <roelj>anadon: Thanks, I'll fix that right away. <rekado>is that wrong in the manual as well…? *anadon does a papa Palpatine <rekado>anadon: so did you look for /releases/gwl-0.1.1.tar.gz…? (I just saw that in the website logs.) <anadon>Nope, just noticed something on the website. <rekado>I’m only looking because someone keeps trying PHP exploits on the GWL website. <anadon>That is not me. I have other things to do with my time. <anadon>If you guys were to see my TODO backlog, it spans, I kid you not, 5 years. <nckx>Veera: Guix System handles user passwords exactly like other systems (passwd, etc.). <rekado>anadon: oh, I didn’t mean to imply that I suspect you for trying PHP exploits! <Veera>Well the installation from did not go well <nckx>So you can set whatever root password you want. Veera: Additionally, you can set a password in your system configuration, but it can be insecure if you don't do it right. <Veera>But I did it with vm image and its working <rekado>anadon: this stuff happens all the time, so I checked, and that’s when the request for the release tarball came in. <Veera>But It is not allowing root login <anadon>rekado: Is it on 7.4? Everything got better in the 5 -> 7 jump. <rekado>anadon: It’s using Guile, not PHP. <anadon>Yeah, that isn't ever going to work then. <rekado>I have to split my TODO every year. Every year 80% of the items in TODO move into my MAYBE file. <nckx>Veera: Can you log in as guest and use sudo (or sudo su -) to become root? <nckx>That's safer anyway. You don't need to run an entire desktop environment as root just to admin some sys. <Veera>default login in vm img download is guest <nckx>Veera: I'm going to answer questions about the VM image here, because someone might know more. Best ask in #guix then. You can try changing the username from ‘guest’ to something else and reconfiguring. Most things will happily keep working. Maybe all. <nckx>Does the vm have a system configuration file? Usually /etc/config.scm. <Veera>yes it has /etc/config.scm file <Veera>I have to read them for basic understanding <jboy>nckx: I didn't manage to grab the gitless package definition the other day, and the link now seems to have expired. Did you send it for inclusion in guix pkgs? <Veera>A MSG: The Guix System ISO are not working with Qemu 3.1 in Debian 10 Buster <Veera>A MSG: The Guix System VM img is working fine with Qemu 3.1 in Debian 10 Buster <nckx>jboy: Eek. I don't know if I still have it. <anadon>Veera: I ran into something similar in CentOS except with the 2.0 line. The image is geared towards Qemu v4.x. <nckx>jboy: I didn't submit it, I thought you wanted to. <anadon>There are older instructions somewhere which may work with older versions of Qemu. <jboy>nckx: I just found a browser tab with the non-final version. <nckx>(Assuming that means mine — it wasn't final, the description needed love.) <jboy>nckx: yes, your version that lived at p.deb/1133736 <jboy>sorry, just didn't get around to it till now <nckx>I'll never forget to reset the paste expiration drop-down again. <Veera>anadon: instructions haven't changed <Veera>The Guix has not been tested for older VM emulators <Veera>As Debian stable lags behind official latest versions of sw <Veera>Qemu upstream does not supports such old version as 3.1 <Veera>And you people have perhaps developed, build and tested on new versions <Veera>Software and Hardware mismatch <Veera>Official Qemu still has source for 3.1.1.1 <Veera>But they may not have been tested with every hardware and software released <nckx>There was someone on the ML recently with a similar problem, although it might've been anadon. I don't have it handy. <nckx>anadon: Did you have any success with those older instructions you found? <jboy>do you remember why you had the comment "XXX remove" next to python-cached-property as native-input, nckx? <anadon>I did not. What I ended up doing is installing Qemu through guix, then ran it there. <nckx>jboy: IIRC it should already be propagated by something else. If the package builds fine without it, it can go. <nckx>Whee, 40000+ bug numbers. <nckx>(Chillax, these are for all of GNU debbugs, not just Guix.) <janneke>yeah, i got 40006! almost felt lucky <nckx>I remember the 20000s and I'm not even that ‘old’. <bdju>Checking old emails, it looks like I was around mostly starting with the 29k-30k area. *civodul wonders what their debbugs age is <janneke>civodul: the make-4.3 situation on hurd is terrible <janneke>i built make-4.3 on debian (nothing guix'y), so full up to date glibc patches... <jboy>so the answer to making sure code is properly formatted is "install emacs"? <janneke>==> "574 Tests in 115 Categories Failed (See .diff* files in work dir for details) :-(" <janneke>it hangs, and worse -- so i guess i'll just have to diversify on package level and do something like: gnu-make-boot0 and gnu-make-boot0-4.1 <guix-vits>janneke: if any other tool can mimic "make" (in case something is easier to package)? <dongcarl>Hi all, apologize for my absence as of late, trying to get back into the groove now. <janneke>guix-vits: make-4.1 runs fine, gnu make is not something you want to do without; certainly not while bootstrapping <dongcarl>Wondering what the best way is of adding a configure flag for all gcc versions >= 4.9 <nckx>jboy: Yes. You don't have to *use* emacs if you don't want to, there's an etc/indent-code.el script to format the code from the command line. <janneke>dongcarl: boo for being away so long!!! ;-) <dongcarl>Just add it to gcc-4.9 and let inheritance do the trick? *dongcarl is glad janneke noticed *janneke is happy dongcarl is back! <janneke>yes, i think that could work -- what is your concern? <dongcarl>janneke: I want to add the --with-glibc-version configure flag, which allows us to use glibc for things like ssp <dongcarl>I've had to work around that by injecting the cache value at make time <civodul>janneke: with this many test failures, there might be just one tiny issue at the very core no? :-) <dongcarl>The configure flag was added in 4.9, and has been maintained, so I'm thinking we should turn it on if we see that the libc input is glibc... I guess the tricky part is detecting whether a package _is_ glibc... Perhaps I'll just go by package name? <janneke>civodul: it says "Killed!" on most everything <janneke>could be just one rpc call, or just one glibc function <janneke>i guess that's the test suite timeout...rpctrace shows it hangs: <janneke>.... => task192(pid22798)->gsync_wait (19578944 2 0 0 0) *janneke goes ask around on #hurd <janneke>hmm, using another/parameterized gnu-make-boot0 isn't all that trivial <civodul>janneke: if there aren't too many commits, perhaps a git bisect on make could do? <janneke>civodul: yes, looking at commencement.scm just inspired me enough to take a look at make again; and i mean that in the most positive way possible :-) <janneke>i did a rough bisect, make-v4.2 is not bug-free, but only 3 tests fail; so i only need to bisect the 4.3 series *janneke goes to try writing a git bisect run script <janneke>this is more inspiring that bisecting the missing glibc patch; i would hope free software becomes so wonderful one day that such thing would be a trivial task too <raghavgururajan>nckx So for time being (until I get my device back), I am using my friend's laptop. I installed guix on the ubuntu. I installed glibc-utf8-locales and exported the PATH variable. But still I get the error "Could not set locale". What should I do? <anadon>raghavgururajan: Give up all hope <janneke>omg gnu make has a 1000LOC bash "./bootstrap" script... <nckx>raghavgururajan: 1. Are you sure this is an error and not just an annoying warning? 2. Does your guix-daemon.service have Environment=GUIX_LOCPATH='/var/guix/profiles/per-user/<you!>/current-guix/lib/locale' LC_ALL=en_US.utf8 <nckx>That way you won't have to remember to sudo guix pull once in a while. <nckx>raghavgururajan: Or, really, just ignore this non-error until you get your laptop back. <nckx>Because, guess what, it happens on ‘my’ Ubuntu system as well and I had no idea because I've become entirely blind to that message. <nckx>Well, that's what I demonstrate above. <anadon>When I `guix install gwl` as per the manual, the `guix workflow` doesn't get added as an option. What obvious thing did I read over? <raghavgururajan>nckx Also, during package transactions, I get "substitute: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)". Are they same warning?\ <dongcarl>I know I'm probably doing something dumb, but would appreciate help <nckx>raghavgururajan: Yes, this all indicates your daemon(! not your ‘guix’ command) doesn't have the right variables set. Hence the need to set them in the sysd service. <nckx>substitute inherits them. <nckx>dongcarl: %build-inputs doesn't exist until build time, and you're trying to use it at ‘guix time’. <dongcarl>What would I need to refer to it at guix time? Is that even possible? <nckx>I don't have much context, but can't you just use the variable name directly? Of if this is parameterised, the procedure's parameter? *nckx goes to look at ze code. <dongcarl>I basically just need a way to refer to "the libc input of _this_ package" <janneke>possibly (package-inputs <package>)? <janneke>without looking at code, /me runs away again <dongcarl>Hahaha I mean... Wouldn't that create a circular reference? <nckx>(assoc-ref (package-inputs this-package) "libc")? <nckx>I don't know when this-package is bound TBH. <nckx>dongcarl: Why not use gcc-4.8? <nckx>Why is (package-inputs this-thing) not guaranteed to be identical? Is there some magical sideways injection happening elsewhere? <dongcarl>Well I mean it's common to rewrite the libc input for gcc <dongcarl>I'll just do (assoc-ref (package-inputs gcc-4.8) "libc") then <nckx>dongcarl: It's (I think, since I'm just making up most of the context here) like changing ‘version’ in inheritance: source doesn't magically update. Same here. If you want more magic you'll have to do it at build time, using phases, I think. <nckx>Yeah. Anyone rewriting it will have to take responsibility, so to speak. <dongcarl>Yup yup, I'll play around and post to mailing list if I run into anything, thanks again for the help! *dongcarl stares at the endless nss tests <dongcarl>Oh wait nckx you mean I should add the flags at build time using a phase? <dongcarl>Okay I think I'm seeing what you're saying <nckx>Er, that's a possibility to do what you want, yes. I do *not* know if it's worth it or a good idea, so don't put shoulds in my mouth 😛 <dongcarl>Haha yeah no worries, will give it a go tho! *dongcarl remembers that just a few months he added a 'make-gcc-libc procedure which is a better place to do this <janneke>civodul: haha 749a54d7a458dc6779936138caf40ce600a80052 is the first bad commit <janneke> * job.c (child_execute_job): Prefer posix_spawn() over fork()/exec() <civodul>oh, too bad, because posix_spawn is Better <anadon>What is the difference between posix_spawn() and fork()? <janneke>civodul: didn't "someone" write post patch for guile around that theme ;) <janneke>it's really ironic, have you read the implementation of glibc's fork/exec on the hurd? <janneke>anyway, workaround: ./configure ac_cv_func_posix_spawn=no *cough* <janneke>"someone" needs to debug and fix this further <civodul>janneke: that's a reasonable workaround <civodul>the implementation of fork on the hurd is quite terrible <janneke>yeah, the mes c library does not support that yet, on the hurd <sirgazil>GNOME's dektop recording is working again. Maybe the workaround for the gio-launch-desktop thing fixed it (I'll check). <Blackbeard>@freenode_sirgazil:matrix.org: then I think it should be reported to the manual, so others know about the fix too :) <sirgazil>I forgot how to close issues. Is it BUG-NUMBER-done@debbugs.gnu.org? <lfam>All the different debbugs commands ***matijja is now known as irk
***irk is now known as matijja
<dongcarl>Hi all, is there a way to build my local checkout of guix without regenerating the `po` files? ***jonsger1 is now known as jonsger
<jsgrant>I'm trying to do a 'sudo guix system reconfigure /etc/config.scm' with modules from added channels in my ~/.config/guix/channels.scm -- I already pulled it both with my regular user and it shows up there -- how / where do I need to declare it for root user? <jsgrant>Is there a file I'm missing in etc, or? I see historically there was just a 'guix channels command that seems of since been removed <nckx>Why doesn't /root/.config/guix work? <nckx>Even better: don't guix pull as root. <jsgrant>Firstly, lol, because I didn't even think of that (might try that); Secondly, if we're not supposed to guix pull as root -- does reconfigure handle pulling the latest automatically, I guess and in a 'safer way'? <nckx>jsgrant: You just ‘guix guix reconfigure …’ <nckx>That will use ‘your’ guix. <nckx>If it's doesn't, something's amiss. <jsgrant>But that's for a local user right, not global / host os? I'm trying to get my network card working <nckx>And you can use ‘sudo -E guix’ to force the issue. <nckx>jsgrant: No, for the system. <nckx>‘guix system’ always and only affects the system. <nckx>And Guix by default configures sudo to preserve the relevant environment variables to make ‘sudo guix’ find your regular user's profile. *lfam tests the latest certbot <nckx>Which is why ‘sudo guix pull’ on Guix System will pull into *your* home, but set everything to be owned by root, so it's a really bad idea. It ‘works’ on some other distributions but not all. *nckx enjoys the sumptious elliptic curves of their switch to dehydrated. <nckx>jsgrant: I hope I haven't made a mistake anywhere because keeping this straight is a mess, but ‘don't sudo guix pull’ and ‘99% of peeps shouldn't guix pull as root, ever’ are deffo true. <jsgrant>This is my spare box, so not 'too too worried' about breaking anything big -- but haven't messed with Guix for legimately like near 5 years now, so trying to half-remember the little I did know / learn, almost certainly is going to result in growing-pains regardless lol <nckx>lfam: Does it bring anything fancy to the table? <lfam>nckx: You know we gotta have the latest version of everything <mbakke>git log -G has become my best friend when merging branches <jsgrant>But def appreciate it; I would have probably used sudo for just about anything like I seem to do, by near default, on other distros <lfam>I think the latest certbot adds some features regarding OCSP, nckx <nckx>jsgrant: That's the problem. It's muscle memory for so many of us. Not guix pulling as root prevents you from accidentally using, say, root's year-old copy of Guix instead of your fresh one if you would type ‘sudo guix system …’ by mistake. <lfam>I think that since 5 years, the guidance about working as root has changed a bit. It used to be more common to maintain a root Guix and an unprivileged Guix <lfam>Now we recommend what nckx is saying <nckx>‘Certbot will now renew certificates early if they have been revoked according to OCSP.’ Oh cool. <nckx>Dehydrated probably does not do that, luckily I was unaffected. <jsgrant>Huh, it might not be an issue of the channels not being found afterall; Getting an error saying 'ice-9/boot-9.scm:2803:6: In procedure resolve-interface: no code for module' listing the given modules that channel should provide? <nckx>lfam: The wide split between ‘foreign’ and Guix Systems doesn't help. ‘You should *never* have to ‘sudo guix pull’ oh you use Debian then you *must* sudo guix pull’. <nckx>jsgrant: I wish you the best of luck. <jsoo>Is there a way to make guix system vm-image images smaller? For instance if I specify that my vm image will not have guix installed, can the system profile replace the symlink tree? <jsoo>I was learning a bit about tinyx and it seems like the functional package managers can do the same thing <lfam>Can you clarify your question about having guix installed? <anadon>I'm going to head out for the day. Talk to you all tomorrow. <jsgrant>Okay ... my mistake, figured it out; I tried to append the modules to the same s-exp as I had gnu to and not make a seperate one for each 'group'. Working now. <jsgrant>Don't know how self-evident it is / was, but to be fair the example I saw was multiple s-exp so maybe I should've figured that out earlier lol <rndd>how to add scripts that executes at the startup of guix? for example i want to add "feh --bg-scale " at start-up <nckx>…aaand never mind I'm back. 😒 <nckx>rndd: I put that in my .xsession. Guix start-up is too early, there's no X session yet. <nckx>Also, halp, I middle-buttoned 2.2 MiB of text into emacs and now it's gone out to dinner. <nckx>sirgazil: Is this on Guix System? <sirgazil>But I have never follow that advise since I installed the system because I trust nckx :) <nckx>I agree, that's horribly misleading if that's the default. I use a custom sudoers, I guess that's why I've never seen that…? <sirgazil>And, sadly, I've heard people here recommending pulling as root. So it is even more confusing. <nckx>Problem is, there *are* (or at least *were*, I haven't kept up) good reasons to pull as root on non-Guix Systems. But never in the ‘sudo guix pull && guix install …’ sense. However, it was a way to keep your daemon up-to-date. <nckx>This is why I recommend running the daemon from your user profile if that isn't the default yet. <sirgazil>Hmm, and how do you do that? I haven't touched the daemon ever. Is that documented? <nckx>sirgazil: You'd edit /etc/systemd/system/guix-daemon.service to refer to /var/guix/profiles/per-user/sirgy/current-guix/bin/guix-daemon (and adjust any other relevant paths). <nckx>Or whatever init system you use. Again, this is for foreigners only. <nckx>sirgazil: On Guix System, the daemon is part of the system profile you created with ‘guix system reconfigure’, so is updated along with all your other softs. <nckx>It's not ‘special’ like on foreign distroes. <nckx>Blackbeard: One herd restart emacs and she's good as new. ♥ <nckx>(Replace .xsession with xdg-bloaty-mcbloatfoo if you use a DE, I guess.) <ngz>Hello. When I run `guix pull`, I get the following error. "guix/ui.scm:1826:12: In procedure run-guix-command: synopsis: unbound variable". <nckx>Blackbeard: I dunno. Possible! Why? <nckx>Whatever it does in the background, the Shepherd can still track & kill it so I'm happy. <nckx>ngz: I cannot reproduce here, let me try on another machine. Are you pulling from Savannah? Any channels you might've forgot about? <ngz>hmmm. No, I don't use channels yet. I still have GUIX_PACKAGE_PATH set. I'm surprised the error may come from there. <nckx>ngz: I've successfully pulled on 2 machines, one of them definitely ‘stock’ so it must be. <ngz>you mean export GUIX_PACKAGE_PATH="" guix pull <nckx>If that would succeeds (and replace your guix command with a vanilla one with fewer packages), you can still manually invoke a previous Guix with ‘/var/guix/profiles/per-user/nckx/current-guix-n-link/bin/guix’. <ngz>It succeeds with a "Nothing to do" message. So I guess the error was happening after a successful pull. <jsoo>nckx: I think you would use --fg-daemon so stdout can go to a log file. Also systemd semantics required foregrounded processes the last time i used it. <nckx>jsoo: Thanks. I've never even looked at emacs's stdout or used systemd, but that's good to know. <nckx>ngz: Mmmmaybe. I'm not convinced. 🙂 <jsoo>when you start up the daemon there's some output usually and sometimes it can report errors which can be nice to have. <nckx>Oh I'm sure. I've just never had to debug a start-up failure. <ngz>nckx: Neither I am, but I don't have a better explanation. In any case, it does work now. Thank you. <nckx>Just knowing you won't backslide into an undefined mess increases the joy of working on/debugging anything. Respawn checkpoints for your peesee. <Blackbeard>nckx: I don't know which is better or why. I just use fg-daemon hahaha