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.
<dsmith>.
<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?
<Christoph[m]> https://xkcd.com/327/
<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?
<dsmith>.
<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
<Baptiste>about it? Thanks
<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!
<nckhexen>o/
<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]>antipode: Pay up: https://www.youtube.com/watch?v=PX3A7GLtFqM, https://www.youtube.com/watch?v=a0Yn5bYclv4, https://www.youtube.com/watch?v=Gc9iwBxPI_I
<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]>Oh, and this one: https://www.youtube.com/watch?v=fXXJ1LOqHEk
<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]>NO
<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
<nckhexen>o/
<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>hmm, it's downloading stuff and C-c doesn't cancel it
<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?
<apteryx>the link doesn't exist yet
<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?
<VesselWave>*broken symlink
<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
<unmatched-paren>hm
<dgcampea>that one appears under herd
<unmatched-paren>could you share the output of ``herd status''?
<dgcampea> https://paste.centos.org/view/2fbade13
<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
<dgcampea>dhcp doesn't do dhcpv6 sadly
<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>huh
<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”?
<vagrantc>oh, it tried to download the bash bootstrap binaries...
<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
<unmatched-paren>jab: basically, https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html
<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.
<unmatched-paren> https://issues.guix.gnu.org/55903#546 <- the latest version (v13) has 42 patches, most of which add go dependencies
<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 :)
<unmatched-paren>have a look here: https://guix.gnu.org/manual/devel/en/html_node/Contributing.html and https://issues.guix.gnu.org/58648#8
<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_>yes
<rekado_>I have a working GHC 4.08.2
<rekado_>GHC 6.0 is built from Haskell sources, no generated C there.
<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_>none of them worked out
<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>This is becoming quadratic.
<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 :)
<tribals> https://paste.debian.net/1258364/
<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)