<nckx>Xanderificnl_: Yes. Both will invoke different copies of guix, which may be at wildly different versions.
<Xanderificnl_>Good to know. As per the manual, I'm guessing the user's $PATH is prefered?
<nckx>‘sudo guix’ still invokes your regular user's guix, but as root. ‘sudo -i guix’ invokes the ‘system guix’, for lack of a better word. The one that provides the daemon, is available to newly-created users that haven't yet pulled their own guix, etc.
<nckx>It is strongly recommended to always use your own Guix, yes.
<nckx>Actually, no, ‘sudo -i guix’ will invoke root's guix if root has ever pulled guix. It just goes to prove my point that on this 5+ year-old system I've never pulled as root once and forgot that :)
<Xanderificnl_>Good to know. Guix's documentation so far is amazing, and I haven't scratched the surface yet. It is super refreshing!
<nckx>Thanks! It shines in places, but there's plenty of room for improvement too.
<nckx>Please don't hesitate to ask if something is still unclear after careful reading.
<apteryx>nckx: no, it seems fine, I was just confused that it's not 'linked' with it
<apteryx>seems it mostly has to do with configure time checks, which then conditionally enables some code that only deals with a gpm daemon (outside of Emacs), so there's no refrence kept to a gpm library
<apteryx>I found out that mailutils as an input is similar; it's useful during configure time, to ensure Emacs later looks for movemail from PATH instead of using its own fallback, which would be inferior and insecure.
<Xanderificnl_>Yes, that's how I interpreted the note in the manual, too. I'm still missing a few bits of information, but still many chapters to go. I'm surprised the recommendation isn't the other way around (i.e. using root's package definition for the global system configuration, and the user's definition for the user.).
<nckx>(That was the consensus above, but I didn't verify.)
<apteryx>not sure why but I've updated mailutils, and attempting to build the emacs collections it affects (via 'emacs' I think), I saw it attempting to rebuild the whole rust chain; retrying now, it seems to have gotten a substitutes for rust
<apteryx>or at least it's not bothering me with it anymore
<Xanderificnl_>Discarded the prebuilt VM and starting from scratch to get a better feel/idea. I'm settling on manual installing, but the graphical installer in combination with QEMU are a bit in the way. Usually you can switch tty's via ctrl+arrow, but the graphical installer seems to be catching that. So I ended up ctrl+alt+2 (switch to Qemu console) and
<Xanderificnl_>executing `sendkey ctrl-alt-f3` manually, and switching back to the machine via ctrl+alt+1. TTY2 and TTY3 can be switched via arrows.
<Xanderificnl_>Perhaps this could be documented or the graphical installer can add a key mapping to switch to docs/terminal via `chvt`? :)
<lfam>We should definitely add the QEMU incantations to the manual section Installing Guix in a Virtual Machine
<nckx>Would you mind putting that in a bug report to email@example.com? If you don't have the time I'll do so to make sure it doesn't get lost, but I'm pretty clueless about QEMU. I figured out the same workaround as you but thought it was just me missing a more obvious way.
<Xanderificnl_>(honestly, though: I think instead of working around Qemu, the real solution is to just add mappings like: F2 and F3 to `chvt` to the graphical installer, it'll be more universal. I'll suggest that in the bug report. :))
<lfam>"[...] it is worth noting that the fact that the defendant’s infringement was established in this case was because the violation of the GPL3.0 agreement led to the automatic cancellation of the GPL3.0 agreement, and the defendant lost the source code authorization protection under the GPL3.0 agreement, which constituted infringement."
<nckx>iskarian: I feel like the one kid at the party awkwardly waiting for the magit to kick in, but feeling nothing.
<lfam>Who knows, maybe there is something buried in `man git-config`
<yewscion>Hello all, I've been struggling with an issue for a few days now. I've recently made the switch to Guix as my daily OS. The only issue I've found so far is that EMMS will not play any of my MIDI files using timidity. It skips them, as though the file is complete, and simply cycles through the entire playlist. Anyone here have any ideas what might be causing that?
<nckx>lfam: OK, I can try throwing it on top of the todo pile and listening for the clunk. It does sound easy…
<nckx>Which is probably as high as such praise tends to get.
<yewscion>nckx: I've been looking for some way to log more verbosely than the default, but it doesn't seem to be something that's built in, unfortunately. I'll keep looking. Bongo works for now, but I do prefer EMMS. Either way, thanks for the warm welcome, lfam and nckx!
<Xanderificnl_>Was away for a bit, but submitted it a couple of minutes ago. Haven't received a bounce or success mail back yet. So I'm guessing the bug will show up in the tracker at some point. If something went wrong, please let me know!
<lfam>Xanderificnl_: If it's your first-ish mail to the mailing list, it might be held for a little bit for moderation. Subsequent emails should go through more quickly
<Xanderificnl_>I sent it to the email adres mentioned above ( "bug-guix" <firstname.lastname@example.org> )
<iskarian>nckx, it's only magic insofar as it's integrated into emacs, it's interactive, and it adds a bunch of discoverability to git. If you already have your git workflow down, a lot of that isn't as useful.
<nckx>Xanderificnl_: You're not in the queue, but it can sometimes take a while.
<Xanderificnl_>So the reason I'm going for the manual install, instead of the graphical one, is because it asks for locale language: and afterwards region. What I *want* is to set my language to English but my region to the Netherlands, but that isn't an option. Any idea why?
<lfam>iskarian: Regarding "Remove when updating", does that mean "Remove when updating the package in question? Or the default Go?
<nckx>iskarian: Oh, that's actually an interesting and helpful view, thanks.
<Xanderificnl_>Ah, that's fine. I figured there be a cron job or something running at some point!
<iskarian>lfam, remove when updating the package in question as it's in master, so it'll be in the next version
<Xanderificnl_>So amongst others, yes: also user passwords. It wouldn't be much work to actually just `passwd` manually, but I'm thinking bigger, i.e. everything that's confidential so I can quite easily get up and running on another machine.
<Xanderificnl_>lfam thanks though. I'm sorry I wasn't very clear to begin with ha, had some difficulty clearly conveying/translating from what my brain was thinking to what I was typing :)
<blackbeard>I am gonna be installing Guix on my laptop and then I'll check some issues I can start with
<Xanderificnl_>Age is written in Go I think. Rage is the Rust variant iirc.
<blackbeard>I am gonna be using my work's laptop, let's nothing gets broken :p
<lfam>Yeah, whether Go or Rust, I'm not sure we are ready to make Guix depend on those languages. We have support in Guix but it's somewhat dicey. But it should be possible to provide a basic and correct file encryption utility in Scheme or C
<Xanderificnl_>It's really just one of many times that happens. Everytime I think: "why would you register a domain to advertise on GitHub just to return us right back to GitHub?" -- anyway /end of rant.
<singpolyma>Is there a way to get guix build to leave the /tmp/guix-build-* directory in place for debugging build errors?
<Xanderificnl_>Anyway, I'm going to boot into the installer. I'll be back after I'm running Guix!
<blackbeard>lfam: yeah it went up!! I was getting 3.35MB/s and finished super fast
<singpolyma>Anyone have a guess why (arguments) in a package definition might be seemingly ignored by guix build? I'm trying a #:phases modification, but even setting #:tests? #f seems to have no effect. Even putting full typos and whatever in there causes no change in behaviour...
<lfam>singpolyma: It could be that the development dependencies if your Git checkout have been deleted
<lfam>In that case, you'd need to do `guix environment guix -- ./configure --localstatedir=/var` again
<lfam>When that happens, Guix can't recompile based on your code changes so you end up using stale compiled Guix
<singpolyma>I'm not running inside a guix git checkout, just using guix build from my user profile
<muradm>sneek: later tell civodul, basically "make check-system ..." not working, i tried some tests under gnu/tests/*, they all fail the same, test executed, conditions pass, but something around them fails
<dhruvin>sneek: later tell maximed I was able to add a profile with latest guix using (latest-channel-derivation). I'll symlink first generation of "/var/guix/profiles/per-user/build/current-guix" to it in the shepherd-service (the way guix pull internally does). With this development, the users of guix build image can safely install packages (via manifest.scm or guix install) and get latest packages from substitute servers or build from latest
<dhruvin>definitions, without running guix pull first.
<dhruvin>I'm working on pre-populating guix repo checkout in "~/.cache/guix/checkouts/<guix-repository>". So even if the users run guix pull, they recieve only the missing commits from guix's git server, and not the whole repo. I believe not downloading the whole guix repo will lower the burden on guix git server, and will save significant bandwidth (since the builders are run every commit).
<sneek>civodul, muradm says: after merging master, there is an issue with system tests, tests them selves are passing, something around them is crashing: https://paste.rs/6hd
<sneek>civodul, muradm says: basically "make check-system ..." not working, i tried some tests under gnu/tests/*, they all fail the same, test executed, conditions pass, but something around them fails
<PurpleSym>dhruvin: Pre-populating the checkout cache would be very useful imo. Running `guix pull` the first time is very painful right now, especially with lots of users on the same system.
<civodul>muradm: thanks for testing & reporting the issue! i'll take a look
<dhruvin>PurpleSym: Yes, that's the intention. Right now, I'm using a hacky way to do it. That is, tarballing the checkout in cache and then adding it to the store, to preserve the writeable bit of files. If you know of a better way of doing it, do share. :)
<sneek>maximed, dhruvin says: I was able to add a profile with latest guix using (latest-channel-derivation). I'll symlink first generation of "/var/guix/profiles/per-user/build/current-guix" to it in the shepherd-service (the way guix pull internally does). With this development, the users of guix build image can safely install packages (via manifest.scm or guix install) and get latest packages from substitute servers or build from latest
<attila_lendvai>civodul, it should be provided by the package python-trezor, and it's recorded as a dependency. hence my interest to see whether it's installed... and apparently it's not?! not present in: ll ~/.guix-profile/lib/python3.8/site-packages/ | grep trezor
<zimoun>civodul: about SWH and 44187, I missed the new stuff on the SWH side. :-) What is new?
<zimoun>efraim: thanks for <http://issues.guix.gnu.org/issue/50501>. I was fighting with manifest.scm for the website; puzzled about why all git outputs (send-email, svn and others) are fetched when only “git” was expected. You save me some time. :-)
<civodul>zimoun: the vault can now cook "git-bare" archives
<civodul>IOW, you can fetch complete repos, which was not quite possible before (there was git-fastexport, but it was discouraged)
<jpoiret>i've tried setting up geiser-guile to hack on the guix source tree, but trying to look up the definition of eg `modify-phases` hangs for a while and fails to find it, does anyone have any tips regarding that? (i'm using the melpa versions and the guix source is in `geiser-guile-load-path`)
<blackbeard>yesterday building guix from source I got 3 errors
<notnckx>This Libera-hosted Gamja gizmo is pretty spiff.
<civodul>jpoiret: the reason is that Guix code is often "multi-staged": it contains code that's quoted (possibly as gexps), staged for later execution; Geiser doesn't know about that, and it doesn't know what modules this staged code imports
<jpoiret>that's true, I guess geiser won't be that useful for most packaging then
<jpoiret>maybe a vm would work but i feel like setting up vms would be a hassle compared to just building the system with that one change (and it's just a simple session file so it should be fine)
<jpoiret>i'll try setting them up later though, i'm not one to tinker with things that needs bare metal
***jonsger1 is now known as jonsger
<Xanderificnl_>Hi. I'm trying to figure out how I'm supposed to figure out the base32 of a sha256sum of a tarball. From what I read, it should be as simple as: "guix download http://url/to/tarball" -- however, after using the resulting base32 string, Guix will eventually tell me it's wrong. Is there a step, or something I'm missing? I also tried confirming a
<Xanderificnl_>base32 string by comparing the output of the download command with a value already in gnu/packages/wm.scm.
<Xanderificnl_>(it didn't match.) I'm guessing I must have overlooked something.
<singpolyma>Xanderificnl_: I just put a wrong one and get the right one from the error message ;)
<Xanderificnl_>I'm thinking that's really wasteful to do it by trial and error
<Xanderificnl_>Yes, it's all about the tarbal. Let me check that out. I'm unsure what I did wrong with guix download then, I'll check the hash command. Thanks
<jackhill>Ideally, you'd have some way to verify the authenticity of the artifact (but I know this can be difficult. Hopefully at least having multiple people who have different adversaries get the same hash works for the most part), and then run `guix hash` an a known authentic tarball
<jackhill>Often with signature files, I have no reason to trust the signing cert, but at least if I'm working on the same package over a number of releases and they use the same cert, I can keep using my same local cert copy to verify
<Xanderificnl_>So i figured, guix download was the shortcut, to 1) download the file and 2) do the hashing.
<Xanderificnl_>Fair enough; this is really just hour 12 for me on Guix, so I'm still learning the ropes. So the first real step is to get Sway updated to the last version, and if that works out, I'm going to be really happy. Then, I'll look more into verifying and the likes.
<Xanderificnl_>(that is to say: I'm actually trying Guix out to see if it can be my daily driver!)
<jackhill>your milage may vary I suppose. Recently I've mosting been working with packages that use git-download, and I already have the repo cloned in order to find the right tag/commit to use.
<jackhill>Xanderificnl_: awesome, hope you enjoy it!
<Xanderificnl_>So far, it's been a charm. My current 'actual' daily driver is Nix and I've ended up fighting with it, and its DSL more than I'd like. So far, I've felt more productive in these 12 hours than I did in double that time.
<Xanderificnl_>It's pretty cool. Yeah, this package actually comes from Git, but I'm just updating the version values and base32 strings for now that are already provided in the default packages.
<Errol-6946>I'm trying to configure dovecot. Anyone know the syntax of the "dict" parameter? I couldn't figure it out myself and can't find examples.
<Errol-6946>I want something like (dict (dict-configuration (entries '(("quota" "psql:/etc/..."))))), but this doesn't work.
<notnckx>Xanderificnl_: Maybe you were hashing the git repository Web UI's HTML? guix download is merely a shortcut for curl/wget + guix hash, and the result should be identical, but it's not clever enough to call git clone instead. Yet?
<Xanderificnl_>Just ran `file ~/Downloads/wlroots*` and all .tar.gz's can back as gzip compressed data
<Xanderificnl_>I did a couple of things, i.e. first `guix download [url to tarball]` then `guix hash /path/to/tarball` and eventually cloned the repository and checkout the proper branch and ran `guix hash -rv`
<Xanderificnl_>the first 2 commands resulted in: 1nv9i12jsr23wi0c3nf43jwbmb3v8ywh5sd4r1bh6a5cg7aq72j4 and the last in: 1sshp3lvlkl1i670kxhwsb4xzxl8raz6769kqvgmxzcb63ns9ay1 (this one being right.)
<Xanderificnl_>So I'm actually guessing it was me making a wrong presumption. For the record, I'm referring to: wlroots version: 0.14.1
***jonsger1 is now known as jonsger
<muradm>a bit offtopic, i did "certtool --generate-privkey --outfile some.pem ..." how do i do public key out of it? in openssl it was "-pubout der"
<Xanderificnl_>the assumption being that `method git-fetch` would result in the same checksum as the tarball which is of course silly because the tarball is an archive. Extracing the tarball however yields the proper checksum. So that was my flaw in thinking.
<Xanderificnl_>Looking at `man certtool` it mentions `pubkey-info` and options which you can combine to extract the public key. Is that what you're looking for?
<muradm>i don't think so, it provides info on key as far as i understand
<muradm>ok may be it is, now some public key info in output, near private key
<Xanderificnl_>It does mention explicitely that it can extract the public key, i.e. the full text: "The option combined with --load-request, --load-pubkey, --load-privkey and --load-certificate will extract the public key of the object in question."
<roptat>blackbeard, which version is this? a checkout of the master branch?
<Xanderificnl_>nckx, yeah, I wasn't seeing what was right in front of me ha. :) | muradm, no worries. The man page has many examples I might add, in case it helps, try: man certtool - and you can use `/` to search for keywords. It's useful!
<Xanderificnl_>Ah, haven't used `info` that much yet. Emacs: I've only just installed it (for the second time or so), and it's still a bit alien to me, but it seems to fit into this ecosystem by default so, I'm trying to assimilate ha ;)
<Xanderificnl_>(or be assimilated, I'm not sure. English isn't my primary language)
<maximed>Xanderificnl_: fwiw, the texinfo manual is available as HTML as well
***ChanServ sets mode: +o litharge
***notnckx was kicked by litharge (time to log out (by nckx))
<roptat>great! not sure what we should do though, do we want to support older guile versions?
<jonsger>wonder if I just can disable building docs for babl as it would require OpenSSH for scp
<jonsger>I did as the docs weren't built before either...
<jpoiret>has anyone successfully added sway (or any wayland compositor) to the possible gdm sessions? I modified the wayland-sessions desktop file to have Exec=/actual/store/path/sway but it still doesn't get picked up by gdm
<blackbeard>roptat: sorry, I meant the newer guile, I am running the checks right now
<Xanderificnl_>GDM should be able to start Wayland sessions, I think fedora uses Gnome w/ Wayland by default. I'm actually updating Sway to the latest version and I did have some links in my notes, let me see if any will help.
<dstolfa>AFAIK guix gdm currently lacks support for wayland
<dstolfa>it's not that it can't do it, it's just that nobody's done the work i'd assume
<Xanderificnl_>So, if I'm reading this right (I might not, I'm just starting with Guix/guile/scheme) there's a provision in GDM's definition to "substitute" wayland-session.c with x-session.c, does that sound like it's disabling wayland?
<steggy[m]>Yep, substitute* is used for string replacement, usually on build
<steggy[m]>If you want to see if you are on wayland or whatnot, I'd recommend consulting `$XDG_SESSION_TYPE`
<Xanderificnl_>The real thing we're trying to figure out is how to get wayland sessions to show up in GDM.
<steggy[m]>`The desktop environments in Guix use the Xorg display server by default. If you’d like to use the newer display server protocol called Wayland, you need to use the sddm-service instead of GDM as the graphical login manager. You should then select the “GNOME (Wayland)” session in SDDM. Alternatively you can also try starting GNOME on Wayland manually from a TTY with the command “XDG_SESSION_TYPE=wayland exec dbus-run-session
<Xanderificnl_>I'll come back to that in a bit if you don't mind. I really just want to finish this first ha, it already distracted me from what I was doing haha ;)
<steggy[m]>Yeah no worries, you don't owe me anything :). I'm off and on but if you want me in particular can always nameping, though many of the devs hang out here and can likely give you better advice
<Xanderificnl_>I do appreciate your help though! It's just that I got sidetracked, and need to get back to the main thing :)
<roptat>blackbeard, ok, that's weird, both pass here... can you send the reports for these two tests to the bug you opened earlier?
<Xanderificnl_>I'm sure at least the debug log will tell us where GDM is _actually_ looking for the desktop files. I'm guessing that's the "real" question at this point. Or, if you're feeling particularly adventerous use strace (but I'm guessing debug is waaay more readable.)
<jpoiret>enabling debug doesn't help much, no mention of `wayland` in the whole log
<jackhill>Xanderificnl_, jpoiret: when last I looked into this, I learned the following: GDM will only offer wayland sessions if it is running in wayland mode. I couldn't get GDM to start in wayland mode. I could see in the logs that it was trying to launch a wayland gnome-shell, but that failed for some indeterminent reason, so it would fall back to x11.
<jackhill>if I instead used sddm, which I think currently only support x11 mode, I could launch a wayland gnome session that mostly worked (in Guix at least screen locking doesn't work without GDM though)
<jackhill>Apologies for not keepign detailed notes or having logs available. I had hoped to revisit it after the (long-awaited) gnome upgrade lands
<jackhill>(the hope being it magically starts working 😀)
<jpoiret>jackhill: do you remember in which log you could see that? cause it seems x starts right away for me
<lilyp>Xanderificnl_: I think I saw a similar snippet (replacing wayland with X) in raghavgururajan's GTK4 patches. Chances are someone was overly eager trying to adjust tests and ended up adjusting features instead :P
<jonsger>can someone search for a file named "fikparm.mf" on CI or another big /gnu/store. I'm trying to fix lilypond on core-updates-frozen...
<lilyp>the value of wayland_search_dir needs patching
<lilyp>instead of DATADIR it probably ought to refer to /run/current-system/profile/share/
<Xanderificnl_>What is really confusing, at least to me, is that one the one hand we're patching and the other hand we're substituting in another file. It's really tough to see clearly see what's going on without having to run through it all.
<jpoiret>seems it's both being patched and substituted
<lilyp>In this instance adjusting the patch is to be preferred, since it's a simple modification to make
<lilyp>So, does anyone have their quilt in hands? :P
<jpoiret>does substitute* fail if it cannot actually find one substring?
<jpoiret>but honestly even having EnableWayland=true still starts X11 gdm so i actually have no idea
<Xanderificnl_>Not really. On another note, I'm getting "patch-shebang ... no binary ... 'python' in $PATH" while rebuilding Sway. Any idea? I thought I might be missing Python, but at least in my quix-env it's installed.
*dstolfa is loving this wayland debugging and hopes it results in gdm + wayland!
<Xanderificnl_>jpoiret I did actually read somewhere, not sure if applicable to Guix, that GDM will write a temporary custom.conf and it'll have to be removed manually and until then GDM won't use the default/builtin. Not sure if applicable to Guix, or even still current!
<Xanderificnl_>Might be worthwhile to `find` and check if that's happening. (i.e. I meant: GDM will have disabled wayland until the custom file is removed/expired. Generally it was kept in /run iirc.)