<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? <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! <vivien>libepoxy brings the whole llvm too <jab>apteryx: why does gtk depend on gstreamer? <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 ***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. <johnabs[m]>Oh okay, good. I was hoping it wasn't an issue where I sent it <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>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 <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. <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? <johnabs[m]>Hmm, so my issues is from lisp-stat, apparently the cffi can't find libcrypto, even after installing openssl <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 <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.) <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. ***ChanServ sets mode: +o nckhexen
<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. <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 ***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 <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 ***dsmith is now known as not-dsmith
***not-dsmith is now known as dsmith
<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>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) <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>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! <johnabs[m]>Wait, but which fraction? Because if it's just 4/2, that's just a normal bicycle <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 <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’. <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>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 <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 <nckhexen>The above works if/because they were both the same nss-certs build. <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 <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 tries it with the regular daemon instead of test-env <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' ^^' <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 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>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 check happens before creating the link <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 <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* <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>we have a bug # for GnuTLS to honor the openssl environment variables <apteryx>46779 normal Maxim Cournoyer GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates <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>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 <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 <ardon>Yeah in my case it works too, but the resulting Emacs Lisp file in the store is empty <apteryx>works fine on my side (contents included) <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>Is ‘Please wait while gathering entropy to generate the key pair;’ not a proper service then? <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 <dgcampea>how does the network-manager-service-type work <dgcampea>running nmcli gets "Error: NetworkManager is not running." <dgcampea>what's providing the internet connectivity and configuration here? <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 <unmatched-paren>connman and dhcp also provide networking, which makes them mutually exclusive <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 <unmatched-paren>dgcampea: hmm... do you already have another dbus instance running?? <dgcampea>I think it messed up when I did a herd restart networking <apteryx>hed restart networking does strang things here too <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>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>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? <antipode>How is it installed through the Guix package manager? <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. ***mark_ is now known as mjw
<nckhexen>To be clear, I was asking silas fox how they installed gutenprint. <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>I'm trying to use with-parameters, but I can't run it, it returns a <parameterized> object <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_>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. <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 ***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: 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”. <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_>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_>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. <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 <two[m]>it only works with emulate-fhs anyway <two[m]>because my "build" is unpack zup <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 <Lumine>And then I wonder why isn't the webpage zooming <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? <jeko>does `local-file` work for directories ? <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. <antipode>For example, coreutils has 'ls', 'cat', ... <nckhexen>Guix has no way to specify dependencies in the classic package manager sense. <jeko>unmatched-paren: oooh neat ! <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 <tribals>I'm totally unaware of where those (possible) files located <clever>tribals: is there a /etc/shepherd? <clever>does shepherd have something like `systemctl status` ? <clever>tribals: when you make a change to the config and deploy, does it list what paths its building? <moggikorken[m]>unmatched-paren: that looks a bit hairy :D but ty I will try to make sense of it <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>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` <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)