# IRC channel logs

## 2022-10-26.log

back to list of logs

<vivien>So when we build something with "no-grafts", does that mean that we build against oh-no or do we rebuild everything against oh-yeah?
<nckhexen>oh-no.
<vivien>I wish guix could know about optional inputs with a way to disable them
<vivien>Without gstreamer and without tracker, my pack nearly halved
<apteryx>vivien: it's nothing new; gtk@4 depends on qt; there's a bug about it I reported months ago
<jab>apteryx: gkt4 depends on qt? That sounds awful!
<apteryx>see #51994
<vivien>libepoxy brings the whole llvm too
<jab>apteryx: why does gtk depend on gstreamer?
<apteryx>through various gstreamer plugins
<apteryx>err, for video playback capability
<jab>hmmmm.
<johnabs[m]>Hi all, anybody able to help with a Julia issue? I've been banging my head against it for a while, and I need it working so I can keep doing my research :/
<johnabs[m]>The bug I'm experiencing is super easy to reproduce: just install julia, then run using Pkg, Pkg.add("DrWatson"). And suddenly it screams about curl_multisocket_errors. I've never seen this before on other distros, so I suspect it's unique to guix
<johnabs[m]>Or, at least GuixSD
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*@cpe-24-29-202-168.neo.res.rr.com
***litharge sets mode: -o litharge
<nckhexen>johnabs[m]: I can't help you, but try the mailing list (help-guix at gnu dot org) as well if you haven't yet. More eyes.
<johnabs[m]>I did send out a bug to that one (as I assume it likely is one), was that the wrong place to send it?
<nckhexen>Just FYI, the ‘GuixSD’ name was retired years ago for ‘Guix System’. Treat guides/articles/blogs/… that still use it today with caution.
<johnabs[m]>Oh okay, I'll keep that in mind, thanks for the correction 😄
<nckhexen>johnabs[m]: To help-guix@? Strange, I searched for ‘julia’.
<johnabs[m]>nckhexen: Sorry, no, I sent it to bug-guix@gnu.org, as I thought it was likely a bug, but I can send it to help-guix instead?
<nckhexen>Bug reports are better tracked at bug-guix at gnu.org (and end up on issues.guix.gnu.org), but the line isn't always clear and you won't get yelled at for sending it to the ‘wrong’ address.
<nckhexen>Oh, I see. No, bug is fine.
<johnabs[m]>Oh okay, good. I was hoping it wasn't an issue where I sent it
<nckhexen>rimshot.flac
<johnabs[m]>Also, I've yet to see it show up on the issue tracker; is that because the submitted bugs are manually reviewed before being added?
<nckhexen>I was just looking at that.
<nckhexen>johnabs[m]: No, they aren't. GNU has been having mail delay trouble the past few days (really: longer, but it peaked), but that was supposed to have been mostly solved…
<nckhexen>Did you get any automated response via mail?
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!*@cpe-24-29-202-168.neo.res.rr.com litharge
<johnabs[m]>nckhexen: Ah, good to know. And no, no responses yet, though it's definitely in my sent emails both in emacs and on the webserver, so I'm pretty sure it sent
<nckhexen>Sure, that's a safe assumption.
<johnabs[m]>Worst case scenario, should I resubmit if I don't get an email response within a few days?
<nckhexen>We (Guix) don't have access to the mail server or logs so I can't say much more than ‘wait a bit, and resend in a—yes, that.
<nckhexen>Very unsatisfying but little else we can do, short of self-hosting yet another thing.
<nckhexen>Which, to be very clear, we would be worse at than the GNU folks. I was not suggesting we do :)
*nckhexen → 😴💤 , don't let sneek take over the channel.
<jab>nckhexen: how difficult do you suppose is it to maintain mailing lists?
<johnabs[m]>Fair enough, thank you so much for the help so far; it looks like I may be moving back to my old machine sooner than I expected lol
<johnabs[m]>Which sucks, cause this one is faster, but if I can't run my research code, I'm outta luck for the time being
<winter>> As of version 1.3.0, the standalone Guix System can be installed on an i686, x86_64, ARMv7, or AArch64 machine.
<winter>I see this on the download page, but no installer images for ARM machines. Am I missing something obvious?
<winter>Ah, looks like (based on grepping some historical logs) I'll have to bootstrap from another OS?
<winter>Or at least another live image, if I can get Guix installed there.
<dsmith>Well, Sorry folks. The bot keeps dying, and I haven't found out why yet. So I've stopped it in #guix for now
<dsmith>Looks like when the list of nicks in the channel is being sent, it dies.
<Christoph[m]>Is little bobby tables on the list?
<winter><winter> Ah, looks like (based on grepping some historical logs) I'll have to bootstrap from another OS? <-- This is going well, I think.
<winter>Though it looks like I'm compiling the kernel for whatever reason.
<winter>It's taking ages to grab the source tarball of all things... strange.
<winter>Guess I'm just getting a bad kernel.org mirror maybe?
<winter>ah, unpacking is taking ages for some reason
<winter>oh i bet this will end up exploding in the end since i don't have a cow store
<johnabs[m]>Oh, one more question, is libcrypto available? I see aws-lc, would that provide libcrypto.so or some equivalent?
<apteryx>crypto.so is from openssl, IIRC
<johnabs[m]>Hmmmm...interesting, I'll check a thing
<johnabs[m]>Hmm, so my issues is from lisp-stat, apparently the cffi can't find libcrypto, even after installing openssl
<johnabs[m]>The file is in ~/.guix-profile/lib though...hmm
<dsmith>sneek: botsnack
<sneek>:)
<dsmith>sneek: botsnack
<sneek>:)
<dsmith>goodbot
<johnabs[m]>Okay, if I install sbcl-cl+ssl, how do I add load that into sbcl?
<johnabs[m]>It seems like sbcl doesn't find it, but maybe I'm doing something wrong
<johnabs[m]>(sbcl-cl+ssl is a guix package btw)
<winter>I cloned master, and tried to run guix system image -t iso9660 gnu/system/install.scm on an aarch64-linux machine. (I want to build an ISO to use with QEMU's UEFI environment.)
<winter>I then got an error about guix-setuid and I'm not sure how to debug this at all. (I can't provide the actual error at the moment, but I'm asking now just in case it's known that I can't do this on aarch64-linux or something else I'm missing.)
<winter>Thanks!
<atka>hello guixers!
<unmatched-paren>morning!
<ngz>I'm under the impression that the initial package list in https://guix.gnu.org/packages/ is sub-optimal. I mean: it is most than certainly useless for anyone. Nothing would be better (as in faster). Or maybe the list of the most recently added or updated packages.
<cbaines>ngz, there's probably some room for improvement indeed. A while back, there was some work to try and build a packages thing based off of the data in data.guix.gnu.org
<ngz>That could be nice. However, while we wait for Someone© to do this, maybe just removing the initial list of packages is better than nothing (!). Anyway, this is not a big issue, we're just wasting bits :)
***wielaard is now known as mjw
<nckhexen>Christoph[m]: It's not content-related like that: it joins just fine if the join is delayed by a few seconds. It had something to do with ban lists(???) flooding the queue. I don't get it either.
<sneek>nckhexen, you have 1 message!
<sneek>nckhexen, dsmith says: Just might have worked around it.
<nckhexen>sneek: no botsnack for you.
<sneek>:)
***ChanServ sets mode: +o nckhexen
<nckhexen>Don't just absent-mindedly uparrow.
<xd1le>lol
<nckhexen>johnabs[m]: …and indeed, your message seems to have arrived with a 4h 3m delay…
<johnabs[m]><nckhexen> "johnabs: …and indeed, your..." <- Oh, which one?
<nckhexen>bug#58789: julia 1.6.7 Pkg.add fails with curl_multisocket error
<johnabs[m]>Oh, perfect! Thanks :3 That's one heck of a delay, but I'll take it!
<nckhexen>I'm afraid we've seem worse, but on the bright side the average is much lower than this.
<nckhexen>*seen
<Baptiste>Hello everyone,
<Baptiste>I would like to export my manifest when I'm reconfiguring my system. I've found an export-manifest function in guix/scripts/shell that probably would do the job but I can't seem to figure out a way to call it from a guix REPL. The function is not exported so I'm using @@ but even with that, Guile tells me that it is unbound. How would you go
<johnabs[m]>Above average? Awwwwwww yiss
***ChanServ sets mode: +o litharge
***litharge sets mode: -bbo *!*@2001:470:69fc:105::2:a756 *!*@2001:470:69fc:105::2:a0b1 litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bbbo *!*@2001:470:69fc:105::2:890e *!*@2001:470:69fc:105::2:8e37 *!*@2001:470:69fc:105::2:892d litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bbbo *!*@2001:470:69fc:105::2:7a24 *!*@2001:470:69fc:105::2:8118 *!*@2001:470:69fc:105::2:75fc litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bbo *!*@2001:470:69fc:105::2:73bc *!*@2001:470:69fc:105::2:34a4 litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!*@2001:470:69fc:105::2:1269 litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!*@2001:470:69fc:105::2:120c litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!*@2001:470:69fc:105::2:1198 litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!*@2001:470:69fc:105::1:6a20 litharge
*nckhexen sorry for the noise.
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo $a:crk$##fix-your-connection litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -bbo $r:@*:ggc-project.de$r:@*:asozial.org litharge
*nckhexen did not say there would not be more noise.
***ChanServ sets mode: -o nckhexen
<efraim>do we update git on the master branch? guix refresh -l git git-minimal says 660 packages
<cbaines>my impression at the moment is that "anything goes"
<cbaines>while that's not ideal, the processes around branches aren't great either
<attila_lendvai>is there a GUI QR code app in the guix repos?
<attila_lendvai>there's zbarcam-qt but it only decodes
<nckhexen>Baptiste: @@ not working might be a ‘declarative modules’ thing. They can break that (unsupported) hack. The manifest produced by export-manifest isn't a hard ‘pin’; in most cases it's just an unadorned specifications->manifest call. You could write that yourself with much less ballast. (guix scripts …) can be tempting red herrings; take a look at things like packages->manifest first.
<nckhexen>efraim, cbaines: Someone forgetting about git-minimal seems more likely than them thinking ‘anything goes’, which would be worrying IMO?
<nckhexen>These limits exist for homebuilders as much as (if not more than) the CIs.
<cbaines>"anything goes" more refers to other large rebuilds, I wasn't specificly referring to git
<cbaines>although with the guidance as it stands, both git and git-minimal are OK to update on master (< 300 dependents as reported by guix refresh -l)
<nckhexen>…what? That is a very lawyerly view of the per-package limit but I can't say you're wrong 😃
<nckhexen>No, I guess it's a valid reading, carry on.
<cbaines>indeed, but I'm not sure how well that matches up with the goal of minimising pointless rebuilds and keeping Guix usable without substitutes
*nckhexen nods.
***dsmith is now known as not-dsmith
***not-dsmith is now known as dsmith
<merula>hello guix!
<merula>I've recursively imported a go package -- I got like 10000 LOC back
<merula>when I try to build it guix takes up the whole ram and swap then hangs
<antipode>Cycle?
<antipode>As in, a package cycle, not a proposal to bicycle.
<antipode>I think Guix should use 'call-with-stack-overflow-handler' or such.
<merula>antipode: hm havent thought of that!
<antipode>Presumably a test cycle that can be broken by disabling tests in some of the packages.
<johnabs[m]>antipode: Not recommending n-cycling where n is any integer or rational number)? I for one, am shocked, and appalled at this clear bicycle favoritism. (Sorry, couldn't resist, I've been up all night xD)
<johnabs[m]>s/where/(where
<antipode>johnabs[m]: If you can show my a (non-integer) fractional amount of cycles, you win an Internet prize.
<merula>antipode: what do you mean by "test cycle"? A cycle in packages that are required for running tests?
<antipode>Maybe.
<antipode>More precisely, A depends on B, and B depends on A but only for tests (if tests are disabled then B does not depend on A).
<antipode>Such a cycle can be broken even if running all the tests, by building B (with tests) against a variant of A that is built against a variant of B with disabled tests (and hence doesn't depend on A or variant of A)
<johnabs[m]>Technically they sum to integer values, but that's only because they kept the in-line theme
<johnabs[m]>But the fact that fractional wheels are possible implies the potential existence of fractional wheels that don't sum to whole values
<antipode>Fortunately for me, my current Internet connection is bad enough that I cannot verify that.
<johnabs[m]>That's the closest, as you can consider the n-points on the back an infinitesimal fraction of a circle which contains infinitely many equidistant points from the center, so if you're a topologist, it counts!
<nckhexen>You win a unicycle.
<johnabs[m]>So, what's my prize? XD
<johnabs[m]>THE LEAST OF ALL CYCLES
<nckhexen>The fractional bicycle 🤷
<johnabs[m]>Wait, but which fraction? Because if it's just 4/2, that's just a normal bicycle
<antipode>johnabs[m]: In my opinions that's (https://www.youtube.com/watch?v=PX3A7GLtFqM) a tricycle.
<johnabs[m]>antipode: Ah, but you see, the primary wheel is a "cycle" in that it's an annulus, the latter two "wheels" are semi-annuli, thus making neither of them cycles in their own right
<antipode>It's still three wheels IMO, even if not each individual wheel makes a full 2pi
<nckhexen>The least of all cycles are these cursed things: http://www.cocody.nl/upload/w480/bierfiets.jpg
<antipode>I think 'cycle' in 'N-cycle' means 'wheel', not the 2pi (360 degrees)
<johnabs[m]>antipode: Right, but is it really a wheel if it can't roll of it's own volition?
<johnabs[m]>nckhexen: I think that has more cycles than a unicycle
<johnabs[m]>Also, I just want to make sure I'm not so off topic that I'm gonna get banned 😂
<antipode>Yes, IMO being broken or having unusual restrictions in usage doesn't make an X a not-X.
<nckhexen>johnabs[m]: You don't get banned for being off-topic, only for (ideally, rudely) persisting when it's time to stop.
<johnabs[m]>Well according to topology, you ain't allowed to cut it, only stretch/deform it.
<johnabs[m]>nckhexen: Okay perfect, I'm kind of all over the place when I haven't slept, but I try really hard to not be rude around the clock :3
<nckhexen>See, you've already beat a nonzero percentage of IRC users by trying.
<antipode>Currently I'm doing group theory, and the rotation group on S^1 is not a cyclic group.
<antipode>(Cyclic groups are countable, and the rotations on S^1 aren't).
<antipode>So those 'fractional cycles' aren't really cyclic.
<johnabs[m]>antipode: I don't know enough group theory to refute you, but I'm a sophisticated enough neural network to classify "working wheel" and "not working wheel" with at least 99% accuracy! So take that :P
<johnabs[m]>nckhexen: YEAH, I'm in at least the 1/\infty percentile, the bar has been set xD
<antipode>For your internet prize, have a free C^× ((multiplicative) unit group on the complex numbers, which corresponds to the unit circle), where proper Unicode is left as an exercise to the reader.
<johnabs[m]>I graciously accept :3 Let it be known that soon-to-be Dr.BS has achieved a circle, with literally no way to prove it since it's not implemented in Unicode yet, and therefore cannot be rendered in text reliably. An excellent prize for such a mathematically acute mind to discover rational bicycles xD
<johnabs[m]>Also, I hope that link doesn't go anywhere, that's just what I'm going to have people call me once I finish my PhD xD
<nckhexen>johnabs[m]: Just FYI, ‘dr.bs’ is available for the low low price of ‘several hundred bucks’.
<pkill9>hello
<johnabs[m]><nckhexen> "johnabs: Just FYI, ‘dr.bs’ is..." <- I already own the domain doctor.bs.blogspot.co.uk (okay, that wasn't true)
<daviwil_>Has anyone successfully used Emscripten in Guix? Using guix shell --container --enable-fhs I was able to get so far as to use the emcc compiler but compilation immediately fails because the header gnu/stubs_32.h is missing
<daviwil_>I'm guessing this is because multilib headers are not included in gcc-toolchain?
<daviwil_>I suppose the quickest way to get going would be to use the official Emscripten docker image
<apteryx>efraim: perhaps more packages should depend on git-minimal/fixed; 660 is getting unwieldy for 'git'
<lilyp>anything leading with --enable-fhs sounds like "I have no idea how this works, so I'm trying to make do with any hack possible"
<lilyp>Which if that's your solution to get things working in Guix, chances are no one else had any idea either
<nckhexen>Yep, that's the use case.
<nckhexen>daviwil_: There's no such thing as ‘multilib’ in Guix (or in 2022, one would hope, but nope). You can try running legacy stuff with --system=i686-linux. But unless that ‘_’ was a typo, good luck.
<nckhexen>(Put differently, Guix is infinitely multilib, unlike the lib32 kluge, as long as you don't cross the streams at run time.)
<daviwil_>lilyp: I'm trying to use the official Emscripten distribution as-is just to see if it works. The next step would be an attempt to package it properly, but I don't have time for that at the moment
<daviwil_>nckhexen: Thanks! I'll try that
<nckhexen>I fear something else will break next; I confirmed only that it adds gnu/stubs-32.h.
<nckhexen>If so, check whether emscripten itself can be asked not to do this ad hoc multilib stuff to begin with. But I also understand the Docker image is tempting you with its siren whalesong.
<daviwil_>The twist here is that Emscripten is using clang instead of GCC so --system isn't available. There's probably some other configuration I can do to make it work, but doesn't seem worth it at the moment. Thanks for looking into it!
<nckhexen>I meant Guix's --system argument, FWIW (which may be little).
<nckhexen>But yeah, clang ain't going to help simplify matters…
<VesselWave>Hello. How do I install cargo-make in guix container using cargo or guix itself?
<VesselWave>I neither found a rust-cargo-make package definition nor able to provide proper SSL certicates for cargo in the containeiner
<nckhexen>VesselWave: Add ‘--expose=/etc/ssl nss-certs’ to get the certs working.
<apteryx>perhaps --expose=/gnu, since ssl certs can by symlinked to the store
<apteryx>(also)
<nckhexen>--expose=/ # it's friday 5pm
<nckhexen>apteryx: Yep, they are, good spot.
<nckhexen>The above works if/because they were both the same nss-certs build.
<VesselWave>I previosly exposed /etc/ssl/certs, it updated crates.io index but then: failed to download from https://crates.io/api/v1/crates/cargo-make/0.36.2/download. Trying whole /etc/ssl
<VesselWave>No still that error
<nckhexen>Did you try also adding apteryx's /gnu?
<nckhexen>(It's not very ‘contained’ anymore, I know.)
<VesselWave>guix shell: error: mount: mount "/gnu" on "/tmp/guix-directory.Gx7c6u//gnu": Invalid argument
<VesselWave>Could anyone try? guix shell --network -C --expose=/etc/ssl rust:cargo nss-certs -- cargo install cargo-make
<apteryx>or /gnu/store
<nckhexen>VesselWave: That's the exact command I used, plus --expose=/gnu/store (but I can't really test that — it works without that here, because above reason).
<apteryx>works here too
<apteryx>hmm, after adding symlink dangling check in evaluate-populate-directive from (gnu build install), one 'guix pack' test fails like so: https://paste.debian.net/1258310/; any clue?
*apteryx tries it with the regular daemon instead of test-env
<apteryx>fails the same, good
<VesselWave>nckhexen: Interesting thing, when I do guix shell in my home dir it doesn't update index. But in any other dir it makes network stuff. So try again in dir where you don't have .cargo
<nckhexen>I never had a .cargo in the directory I was using (was it supposed to be created? It wasn't), nor in my ~.
<nckhexen>It *does* do network stuff. It downloads cargo-make. I thought that was the point. Note that I know nothing of cargo beyond that.
<apteryx>odd, I can't seem to use '(define profile (profile (content (packages->manifest (list %bootstrap-guile))) (hooks '()) (locales? #f)))' at the REPL; I always end up with error: content: unbound variable
<apteryx>ah, I shouldn't redefine 'profile' ^^'
<nckhexen>apteryx: Where is <profile> defined?
<nckhexen>Yah.
<apteryx>(guix profiles)
<apteryx>yep, works now: (define p (profile (content (packages->manifest (list %bootstrap-guile))) (hooks '()) (locales? #f)))
<nckhexen>I should have asked ‘profile’, not <profile>, I was already spoiling my hypothesis :)
<apteryx>:-)
*apteryx is not really sure why we need relative links, instead of absolute ones when creating symlinks in guix packs
<apteryx>that line: (,source -> ,(relative-file-name parent target))
<f3n1x>hi guixers. i would like to install KDE Desktop ... I see a lots of Guix kde* packages. I'm not sure which one to use . Which is the name of the 'KDE Desktop' package that would accomplish it ?
<sneek>Welcome back f3n1x, you have 1 message!
<sneek>f3n1x, nckhexen says: Unless the Emacs package has freedom bugs, please share the package so people can give concrete advice. TTYL!
<apteryx>ah, the relative file name business is for relocatable packs: "pack: Add '--relocatable" in commit 47a60325ca650e8fc1a291c8655b4297f4de8deb
<nckhexen>f3n1x: I don't think that exists, and I don't just mean it's not exposed. I don't think Guix supports anything close to a KDE desktop yet.
<nckhexen>Part of that is chicken & egg, but then other DEs overcame that, so it's also just a relative lack of KDE interest in general amongst Guix users.
<nckhexen>+ extreme size & complexity.
<nckhexen>There are separate ‘KDE’- & plasma-based packages though.
<apteryx>fixed my dangling symlink check issue; when the link is relative, we need to change directory to the parent dir of the link before validating its target existence
*apteryx is curious why 'make check SCM_LOG_DRIVER_FLAGS="--brief=no --errors-only=yes" VERBOSE=1 TESTS=tests/pack.sh' runs tests/pack.scm
<nckhexen>apteryx: Can you not canonicalize-path, or is that overkill?
<nckhexen>(Also ew ‘path’ in a GNU programme.)
<apteryx>the check happens before creating the link
<nckhexen>IC.
<apteryx>haha!
<VesselWave>Fixed! /etc/ssl/certs/ca-certificates.crt is a broken inside a guix container, but $GUIX_ENVIRONMENT/etc/ssl/...ficates.crt is not. So I had to override is using SSL_CERT_FILE=$GUIX_ENVIRONMENT/etc/ssl/certs/ca-certificates.crt cargo install cargo-make
<apteryx>VesselWave: broken because it's a symlink pointing to /gnu/store?
<apteryx>if you --expose=/gnu/store it won't be broken
<nckhexen>VesselWave: It's not broken.
<nckhexen>It's… yeah.
<apteryx>I've hit that gotcha before, it's not optimal. Perhaps we should just copy the certs to /etc/ssl (rather than link) to ease this use case
<VesselWave>all of those pointing to /gnu/store/*nss-certs*/ but this to /gnu/store/*ca-certificate-bundle*
<nckhexen>Which should also exist.
<apteryx>sanity check: guix pack --symlink specs's second value, e.g. --symlink=/usr/bin/env=bin/env is always relative to the profile it's to be created in, hence there's no valid use case to use an absolute path for it, correct?
<apteryx>s'/it's to be created in/it points to/'
<nckhexen>VesselWave: Can you paste in full the command you're using to create this broken link?
<nckhexen>If it does not contain the suggested ‘--expose=/gnu/store’, reconsider.
<VesselWave>‘guix shell --network -C --expose=/etc/ssl coreutils nss-certs’ and then try to cat /etc/ssl/certs/ca-certificates.crt
<nckhexen>Why didn't you add --expose=/gnu/store ?
<VesselWave>It sholdn't, it's a CONTINER. I think best approach is just to override. Why not?
<nckhexen>I don't know why not. Just a mention would have been appreciated.
<nckhexen>I think it's better to fix SSL_CERT_* (somehow, *waves hands*) automatically than to copy regular files to /etc/ssl to ease sharing. I'm not sure that iffy use case (--expose=/gnu/store) deserves that much effort or encouragement.
<nckhexen>VesselWave: You can emulate that with e.g., ‘guix shell --network -C --expose=/etc/ssl coreutils nss-certs openssl’ but it's arcane as heck.
<nckhexen>apteryx: The penultimate line was aimed mainly at you, BTW. No idea about --symlink, sorry.
<apteryx>nckhexen: yeah, I agree
<apteryx>we have a bug # for GnuTLS to honor the openssl environment variables
<nckhexen>Oh, I was literally writing one.
<nckhexen>So that's good.
<apteryx>46779 normal Maxim Cournoyer GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates
*nckhexen C-x C-c
<ardon>Hi Guix! I stumbled across a small quirk earlier on. I'm trying to package a local Elisp library using local-file but since the library ends in ".el", it's treated like a file rather than a directory to recur into. How do I go about this without having to rename the directory?
*apteryx tries their hand at exception handling again, with poor results: https://paste.debian.net/1258332/
<apteryx>I was expecting some error message, not a backtrace
<apteryx>ardon: not sure about the local-file problem, but an origin fetch-url method is able to ingest a plain file; you could point it to your local file using the file:// prefix (aka protocol)
<apteryx>something like "file:///home/your-home/src/proj/that-file.el"
<ardon>apteryx: Thanks for the suggestion. However, I want to point to the directory though (which happens to be suffixed with ".el" like many Elisp libraries) and I'm using the #:recursive #t' flag of local-file to achieve this
<apteryx>and it doesn't work?
<ardon>It works fine if I rename the directory (e.g. ement.el -> ement) and then I call (local-file "/home/your-home/src/ement")', but if I include the ".el" suffix it treats it as a file rather than a directory
<apteryx>that's odd, if you used #:recursive #t, I'd expected it'd do what you want no matter the name
<apteryx>works here
<ardon>Yeah in my case it works too, but the resulting Emacs Lisp file in the store is empty
<apteryx>sorry, no idea
<apteryx>works fine on my side (contents included)
<apteryx>I tested using something like: https://paste.debian.net/1258335/
<nckhexen>Hm. Either pk doesn't print to the console during early boot, or it's not triggering when I think it is. Anyone know which?
<nckhexen>As in whether the first clause it #t or #f.
<apteryx>I think shepherd capture pk's output (any stderr)
<nckhexen>Ah.
<nckhexen>Is ‘Please wait while gathering entropy to generate the key pair;’ not a proper service then?
<nckhexen>(I didn't check, just assumed it was.)
<nckhexen>But thanks for the info!
<ardon>apteryx: Thanks for that example. Would you be able to insert some contents into either of those .el files and see if the resulting file in the store is non-empty?
<ardon>I mean, if the .el files are non-empty
<ardon>apteryx: Now that I think about it, it might not be related to local-file but rather the emacs-build-system
<VesselWave>exit
<dgcampea>how does the network-manager-service-type work
<dgcampea>it doesn't appear under herd ?
<dgcampea>running nmcli gets "Error: NetworkManager is not running."
<dgcampea>what's providing the internet connectivity and configuration here?
<unmatched-paren>dgcampea: do you have wpa_supplicant?
<unmatched-paren>i think you need it for networkmanager
<unmatched-paren>wpa-supplicant-service-type, that is
<dgcampea>I do
<dgcampea>that one appears under herd
<unmatched-paren>could you share the output of herd status''?
<unmatched-paren>hm. networking is stopped.
<unmatched-paren>(network-manager-service-type provides the networking'' service, not a network-manager'' service)
<dgcampea>I did a restart on it thinking it was network-manager
<dgcampea>but I just pulled this out via ssh
<dgcampea>so the machine is connected
<unmatched-paren>connman and dhcp also provide networking, which makes them mutually exclusive
<unmatched-paren>try poking around in /var/loc
<unmatched-paren>/var/log
<unmatched-paren>i use connman, which works well for my basic wifi needs...
<dgcampea>I'm seeing "fatal failure to acquire D-Bus service "org.freedesktop.NetworkManager" (3). Service already taken"
<zimoun>apteryx: about error handling, where is the ’raise’ handled?
<zimoun>from the pastebin example of symlink-spec
<apteryx>that new raise is used in (guix scripts pack), in an option parser... which hm, indeed, occurs before error handling is setup
<apteryx>I'll try installing the error handling earlier
<apteryx>thanks!
<zimoun>yw
<unmatched-paren>dgcampea: hmm... do you already have another dbus instance running??
<unmatched-paren>s/dbus/networkmanager/
<unmatched-paren>outside of herd
<dgcampea>I think it messed up when I did a herd restart networking
<unmatched-paren>no, that should work
<dgcampea>just done a reboot and nmcli now works
<unmatched-paren>maybe it was dbus that needed to be restarted
<apteryx>hed restart networking does strang things here too
<unmatched-paren>I guess dbus fails to deregister the connection?
<unmatched-paren>Or something.
<apteryx>zimoun: odd, I've put with-error-handling right under the (synopsis ...) line of (guix scripts pack), and it still crashes with a backtrace rather than report the error nicely
***Dynom_ is now known as Guest8769
<vagrantc>wow, failure, failure, failure: https://buildd.debian.org/status/package.php?p=guix&suite=experimental
<vagrantc>the future for guix on debian is not looking bright
<vagrantc>although several of them look fairly obvious to fix
<vagrantc>no idea why "test-name: wrap-script, argument handling" and "test-name: wrap-script, argument handling, bash --norc" failed
<vagrantc>"test-name: profile-derivation format version 3" and "test-name: deduplication of repeated entries" require bootstrap binaries, so not appropriate for a debian build environment
***GNUcifer is now known as cehteh
<zimoun>apteryx: is this ’symlink-spec-option-parser’ in master?
*vagrantc tries to decipher why tests/guix-shell-export-manifest.sh failed
<zimoun>apteryx: why not put the handler directly in this “symlink-spec-option-parser”?
<silasfox>Hey guix!
<unmatched-paren>eveninng!
<silasfox>I've used this patch (https://issues.guix.gnu.org/45725#10) to install gutenprint drivers to my guix system. And I can see that they're kind of used, because when I try to add a printer, it shows in system-config-printer and I can add it.
<silasfox>But then I get a popup that says: "Printer 'Canon-...' requires the '/gnu/store/some-hash-cups-2.3.3op2/lib/cups/filter/rastertogutenprint.5.3' program but it is not currently installed."
<Andronikos>I am getting "Zygote could not fork: process_type gpu-p rocess numfds 3 child_pid -1" inside a container with fhs. How can I fix that?
<silasfox>The thing is, rastertogutenprint.5.3 is installed, but in /gnu/store/some-hash-gutenprint-5.3.4/lib/cups/filter/, as it should be. The same thing also happens with splix drivers. Does anyone know how to teach cups where to find those filters?
<antipode>Andronikos: It would be useful to know what software you are running.
<antipode>'Zygote' sounds like Android, are you running an Android userspace in a container?
<antipode>silasfox: Usually for such things you need to add an appropriate substitute* to the package definition, though from some previous experience CUPS is complicated
<antipode>(to replace the wrong file name by the right file name)
<gnou_liber>I have a problem, and it is that the adwaita icons do not show me despite having the adwaita-icon-theme package installed. Do you know how I can solve this?
<nckhexen>silasfox: How is it ‘installed’?
<gnou_liber>nckhexen: Through the Guix package manager.
<antipode>How is it installed through the Guix package manager?
<nckhexen>Right. That won't work.
<antipode>OOps, I mixed up some conversations.
<nckhexen>Add it to the (extensions …) field of the CUPS service and see if that helps, or the error message changes. If not, patching might be needed, but I assume the patch you used wasn't fundamentally broken.
<nckhexen>gnou_liber: ☝
<nckhexen>Oops, now I did.
<nckhexen>Hilarity.
<nckhexen>silasfox: ☝
<gnou_liber>antipode: guix install [package name]
***mark_ is now known as mjw
<nckhexen>To be clear, I was asking silas fox how they installed gutenprint.
*nckhexen AFK a while.
<silasfox>nckhexen: I installed it via the (extensions ...) field. Cups does seem to find it enough to find the printer, but not enough to use it.
<Andronikos>antipode: I am on Gentoo with Guix as package manager. Trying to test out if I can now get this running on Guix without much hassle.
<antipode>I can reproduce in the sense that I cannot switch to any other icon theme (e.g.: guix shell papirus-icon-theme eom -- eom)
<antipode>I guess it's a search path issue again (XDG_DATA_DIRS not being an implicit search path and not being a search path of eom)
<roptat>hi guix!
<roptat>I'm trying to use with-parameters, but I can't run it, it returns a <parameterized> object
<roptat>nevermind, I figured it out :)
<dgcampea>how can I get rasdaemon output? ras-mc-ctl doesn't seem to exist
<silasfox>I shouldn't have mentioned the gutenprint driver, that just confuses the point. The problem seems to appear with splix as well.
<silasfox>I have to go offline for a while, will check the logs.
<vagrantc>whoah, all tests passed when building guix from git. i can't recall the last time that happened.
<rekado_>I’m stuck building ghc 6.0; getting a 127 (command not found) error some time during the build of the second stage compiler.
<rekado_>it’s weird because the error cannot be reproduced outside the build container
<rekado_>so my guess is that it’s /bin/sh or something like that
<rekado_>I’d love to go finish the GHC bootstrap before the release
<jab>rekado_: Is GHC not bootstrapped? Or is version 6 not bootstrapped?
<rekado_>jab: we have a binary of 7.8
<rekado_>I wouldn’t have worked on this since ~2017 if we had a bootstrapped GHC.
<jab>rekado_: I thought guix tried to avoid packaging things that were not bootstrapped.
<unmatched-paren>jab: we make exceptions when bootstrapping is extremely difficult
<unmatched-paren>such as with ghc
<jab>unmatched-paren: that makes sense. I mean power9 is not reproducible if I recall...
<jab>rekado_: what makes bootstrapping it so hard?
<apteryx>zimoun: not yet in master! it's a very large error handler that is used upon entering the guix entry points such as 'pack', 'shell', etc. user facing commands
<mirai>does 'serialize-configuration' transform a 'configuration' into a list of strings?
<mirai>I'm looking to serialize a 'configuration' into multiple files
<unmatched-paren>jab: well, every single public version of GHC is written in Haskell
***TopExpert is now known as normalperson
<apteryx>zimoun: to be clear, the very large handler is already in master, see (guix ui) with-error-handling. What I'm trying to do is raise a formatted-message condition at the time of parsing the option and have it handled by it
<apteryx>rekado_: try 'rm /bin/sh' in a 'guix shell -CD ghc@6' to see if you can reproduce?
***user0523 is now known as antero
<jab>unmatched-paren: thanks
<jab>does anyone know of any plans to add an openhttpd service to guix?
<apteryx>zimoun: odd, this works at the REPL: https://paste.debian.net/1258358/
<apteryx>zimoun: it works! it was really putting the with-error-handler at the right place
<Aurora_v_kosmose>Is it some false perception on my end or is Golang just slightly less of a dependency nightmare than Javascript?
<Aurora_v_kosmose>I've been considering packaging some things and the sheer number of transitive dependencies just seems absurd.
<jab>Aurora_v_kosmose: I think unmatched-paren tried to package the aerc email client. It's written in go, and apparently it has been quite the pain to package.
<Aurora_v_kosmose>It's a rather unfortunate situation. I think that in promoting so heavily portable statically-linked binaries, the downsides of so many dependencies being so hidden were completely ignored.
<zimoun>apteryx: cool it finally works. :-)
<unmatched-paren>Aurora_v_kosmose: There were a lot of go dependencies for aerc, yes.
<zimoun>rekado_: wow! you almost have GHC@6. From nhc98? Or using another path?
<unmatched-paren>zimoun: From pre-generated C files created for an older version, I think.
<unmatched-paren>It's still not fully bootstrapped, but it's orders of magnitude better than binaries.
<gnou_liber>Do you have plans to add mat2 to the guix repositories?
<unmatched-paren>gnou_liber: you'll have to add it yourself if you want it in there :)
<rekado_>zimoun: from GHC 4.08.2 with 3.x MB of generated C “sources”.
<zimoun>unmatched-paren: thanks.
<rekado_>I got tired of working on stuff that would lead nowhere but waste time.
<rekado_>so i thought: build GHC 4 first and take it from there
<rekado_>see if the bootstrap path actually works
<rekado_>and get rid of that massive GHC 7.8 binary
<rekado_>and if this all works fine then revisit GHC 4 and see if we can shrink the C blob some more
<zimoun>have you almost built GHC@6 from GHC@4 using the «C backend»?
<rekado_>I have a working GHC 4.08.2
<zimoun>oh, awesome! so I have missed the Part 2 of your blog :-)
<rekado_>I tried a few other things before making compromises on GHC 4.
<rekado_>built gofer, but it turns out that this is non-free software
<rekado_>tried to build HBC but it’s written in Lazy ML — a language that it implements
<rekado_>it comes with lml2hs, but that’s also written in Lazy ML
<rekado_>eventually, it may be worth looking at GHC 0.29 again.
<rekado_>or to try to build GHC 4.08.2 in several stages: just the RTS, then use it with Hugs in “combined” mode, then use that to build the compiler, etc
<rekado_>but it all takes way too much time, and I’d like to have some minor successes before bathing in that sea of frustration again.
<jeko>Yoo Guixters !
<two[m]>hi
<unmatched-paren>evening!
<tricon>jeko in da houz!
<jeko>haha
<two[m]>if a package uses git sed tar gzip in its operation, do i include them in propagated inpouts?
<unmatched-paren>two[m]: try to patch the program to refer to the /gnu/store/.../bin path
<unmatched-paren>instead of calling the program from PATH
<unmatched-paren>and then put them in regular inputs
<two[m]>it only works with emulate-fhs anyway
<two[m]>because my "build" is unpack zup
<Lumine>Good evening #guix
<jeko>Lumine: o/
<nckhexen>Evening all.
<jeko>nckhexen: o/
<Lumine>I have a coffee
<nckhexen>But I won't say no to quadratic coffee.
<Lumine>I'm so used to using Caps Lock as my Ctrl that I keep hitting it even when I'm on Plasma with normal keybindings
<jeko>I can relate to that
<Lumine>And then I wonder why isn't the webpage zooming
<nckhexen>Whilst shouting.
<nckhexen>(Test) VMs are annoying that way.
<antipode>On VMs: I recommend against running "make check-system" on core-updates when you can do so on master instead.
<moggikorken[m]>is there a way to declare binary runtime dependencies for packages.
<moggikorken[m]>I cannot think of a good example of this that would be packaged in guix but I am trying to package sbt for my own use and thats easy enough just pull a binary and put it on the machine however it also requires sed, grep, and openjdk16 >= .
<moggikorken[m]>now I can just put those dependencies in when I use the package but I guess what I am wondering is if there is a way for a package to consist of more than one binary even so its not up to the user to figure it out? (Iv tried with inputs, native-inputs and propagated-inputs and none seem to work) and if so is there a package I can look at in official guix for ideas?
<tribals>hello!
<jeko>does local-file work for directories ?
<jeko>tribals: Yo
<antipode>There are already some packages that consist of multiple binaries.
<unmatched-paren>moggikorken[m]: usually runtime binaries should have their full /gnu/store/.../bin path substituted in
<nckhexen>moggikorken[m]: You patch the package to run /gnu/store/\${sed}/bin/sed explicitly, using substitute*, or you wrap the binaries using wrap-program or wrap-script.
<unmatched-paren>and you add the binary package to inputs
<antipode>For example, coreutils has 'ls', 'cat', ...
<unmatched-paren>jeko: yes, using #:recursive? #t
<nckhexen>Guix has no way to specify dependencies in the classic package manager sense.
<jeko>unmatched-paren: oooh neat !
<jeko>unmatched-paren thx
<tribals>I'm trying to understand how to configure my system. I'm adjusting my config, then applying changes with guix deploy, but seems like changes aren't applied despite new generation reported as current. I'm configuring guix system shepherd service.
<tribals>I need to verify that changes I made to configuration.scm reflected after guix deploy. To do so I want to check generated config file for shepherd service. Where it is located?
<clever>tribals: usually, the service gets restarted automatically, and has a --config flag pointing it to the new config file
<clever>check ps aux for the service, and see what args it has
<tribals>that's the issue. I has been looking to process command line with pgrep -a <service>. Seems like I've had an error in config, and service doesn't start. So, this method doesn't work any more. Unfortunatelly, config file name is not reported at logs either.
<clever>tribals: i assume your using systemd? what is in /etc/systemd/system/foo.service for that service?
<moggikorken[m]>unmatched-paren: hmm is there an example of this that I can look at somewhere?
<tribals>No, I'm using guix system, it is shepherd-based service, which is generated (I suppose) from (operating-system (services ...) ...) definition
<unmatched-paren>moggikorken[m]: hmm...
<unmatched-paren>lemme think
<tribals>I'm totally unaware of where those (possible) files located
<clever>tribals: is there a /etc/shepherd?
<tribals>clever: no
<clever>does shepherd have something like systemctl status ?
<tribals>I think, it is sudo herd status
<unmatched-paren>moggikorken[m]: try looking at fuse
<unmatched-paren>(guix edit fuse)
<clever>tribals: when you make a change to the config and deploy, does it list what paths its building?
<tribals>.drv paths, mostly
<clever>can you pastebin that list?
<tribals>sure, minute
*unmatched-paren away
<moggikorken[m]>unmatched-paren: that looks a bit hairy :D but ty I will try to make sense of it
<unmatched-paren>moggikorken[m]: it's less hairy than propagated-inputs :)
<clever>tribals: and which service are you editing configs for?
<clever>/gnu/store/5ihwr769b077rg9sbjipdnli0jnyv65f-upgrade-shepherd-services.scm.drv looks like a likely place for the shepherd configs, but we want the output path
<clever>under nix, that would have been just nix-store --query --binding out /foo.drv, but i'm less familiar with guix
<antipode>Then run "guix build /gnu/store/....scm.drv"
<clever>that can also work
<clever>it should tell you the output path, and may create a result symlink
<antipode>"guix build" just builds the thing (or doesn't, if it's already built) and returns the output file names, it doesn't automatically make any symlinks
<clever>ah, so thats most like nix-store -r
<tribals>thanks, it helped
<antipode>If you want to create a root (symlink to store item protected for GC), then there's the '--root' option of various guix commands.
<tribals>I've verified that a config is generated as I'm assuming. Seems like my assumption is wrong.
<antipode>The openat / mkdir-p/perms patches should be in theory ready now, but compiling the new guile is taking a while ...
<moggikorken[m]>unmatched-paren: I am going to have to get back to it. Im finding it hard to reason about what substutute* is doing it seems like its doing nothing and failing silently :/ (very probably its me using it wrong but I have no idea how to get guix to tell me when Im using it wrong/right)