<nckx>(Reading the mentioned ‘ECMAScript’ part in the Guile manual, I think it's quite obvious the author is talking about themselves. Maybe I'm missing some self-deprecating humour on Caleb's part but it's sad if the project left them so demotivated that they actually feared ending up a pariah.)
<ix>dstolfa: take that up with just about everyone ive ever argued with
<danderson>I dunno, I suppose I have a different threshold for that. It's emotional for sure, but not unreasonably so. And given the content being conveyed, it seems like a legitimate place to talk about the non-technical problems
<dstolfa>ix: i think it's just a case of text-based communication being an less-than-great medium for some things
<nckx>It's a trade-off, since you increase the query overhead by asking each server in turn, but they are tested in order so if you put ci.guix first (or whichever is fastest to build) it's not too bad.
<vslg_>Hi, this might be a stupid question, but I'm new to Guix and I'm trying to do a bit of packaging. Every time I run ./pre-inst-env guix [...], it rebuilds Guix from scratch, there are a lot of notes saying that the source file is newer than the compiled one (in the store). Is this normal? Every time I want to test a change in my package, it rebuilds everything an it takes time.
<vslg_>Should I mention that I'm running Guix package manager from other distro different than Guix.
<nckx>vslg_: First run ‘guix environment guix -- ./pre-inst-env make -j$(nproc)‘ to recompile all those modified files.
<nckx>From then on it will only print that warning (and incur a slight delay) for the file(s) you're actually working on.
<nckx>When editing different files, repeat as needed.
<bauermann>mbakke, FYI: I'm halfway through (I hope!) creating a patch which updates TeX Live to version 2021.1. I have a hunch that it will fix the current irreproducibility of texlive packages (bug 48064)
<bauermann>though that may be just unwarranted blind hope...
<danderson>hmm, does a default guix install not allow pubkey login to root@?
<danderson>no. In this VM, I did a `guix system reconfigure /etc/config.scm`, which took a while pulling a bunch of substitutes, but eventually finished. Then I ran the exact same thing again, and now it's building guix-1.3.0rc2 from source?
<danderson>mostly I'm confused as to why the second `guix system reconfigure` wasn't a no-op. It seems to be doing more stuff that it didn't do the first time round.
<danderson>I presume, somewhere, there is a log that tells me more than "lol, no", but I can't find it. On a systemd distro that'd be journalctl, and the status output would helpfully show me exerpts from it. So far I'm not finding anything like that for shepherd.
<danderson>Nothing in /var/log, obviously no journald...
<danderson>note I'm only even caring about this because `guix system reconfigure` told me that it failed to start some stuff and I should do it myself.
<danderson>I am exploring the system. I'm attempting to do the things the manual tells me, and finding problems. You telling me that I'm exploring wrong when I'm trying to do that the manual says isn't helping :(
<sneek>apteryx, yoctocell says: have you seen https://issues.guix.gnu.org/issue/48934 ? Sometime ago you mentioned that the generated docs for service configurations had a different style compared to the hand-written ones. This should fix that.
<apteryx>sneek: yoctocell thank you! I've been meaning to try it/comment on it, but haven't gotten around it yet.
<apteryx>sneek: later tell yoctocell thank you! I've been meaning to try it/comment on it, but haven't gotten around it yet.
<Horizon-1207>apasch: I was curious because sometimes the libre kernel doesn't (didn't) support some AMD graphics cards
<Horizon-1207>apapsch: I was curious because sometimes the libre kernel doesn't (didn't) support some AMD graphics cards
<apapsch>Horizon-1207: I remember a conversation here a few days ago that revolved around amdgpu driver not having the firmware for a card. You should see a message via dmesg. If you are affected, you are out of luck in a pure libre system
<thorwil>not entirely sure just setting prefix is the thing to, but that’s what i started with. only: error: Failed to import waf (cannot import name 'Context' from 'waflib' (unknown location))
<thorwil>command "python" "waf" "configure" "--prefix=/gnu/store/ni14smiskgqljqsqpmqgyn6jfii35zbf-mda-lv2-1.2.6" "--prefix=/gnu/store/ni14smiskgqljqsqpmqgyn6jfii35zbf-mda-lv2-1.2.6" failed with status 1
<mothacehe>guix substitute knows the length because its asks the narinfo beforehand put I wasn't aware of "guix archive -t"
<thorwil>apparently there should be a waflib, but the tarball for mda.lv2 comes with an empty "waflib" folder. bbl.
<civodul>mothacehe: "guix archive -t" parses the raw nar, but the nar itself doesn't have a clear end marker
<civodul>in HTTP terms though, there should be "something" happening when the response is complete no?
<mothacehe>when the server is able to send the content-length everything works fine, as Guile http-get will do the right thing. When it's not the case, as there's no nar end marker, the client cannot know when the transfer is complete
<mothacehe>and the server must not hang-up to respect the keep-alive
<mothacehe>civodul: I think the problem is that guix-publish doesn't keep up when multiple workers are requesting substitutes at the same time, without keep-alive. The worker connection requests cannot be honored in less thn 5 seconds (connection timeout), causing this: https://issues.guix.gnu.org/48468.
<abcdw>civodul, leoprikler, roptat: I would like to get a commit access to work on Guix Home migration from rde repo to guix-home branch of guix repository. Can you vouch for me, please?
<mothacehe>Since the keep-alive fix deployment I haven't seen this error
<mothacehe>but there are still some "server is somewhat slow" substitute warning denoting that guix-publish is a bit under water
<leoprikler>Do I qualify for vouching? I don't recall having reviewed any of your work on the ML.
<leoprikler>(Or maybe I'm bad in mapping IRC nicks to mail addresses.)
<abcdw>leoprikler: I don't have too much work on guix ML, but we had few discussions on emacs build system. I'm Andrew Tropin BTW)
<civodul>abcdw: i'll sure do! could you email guix-maintainers once you have three people?
<civodul>mothacehe: thing is, 'guix publish' is single-threaded...
<civodul>so either we "do it right" and fiberize it
<civodul>or, at least as a short-term fix, we add a tiny bit of nginx caching
<leoprikler>This is my first time vouching for someone. Are there any formal requirements or is "I'm vouching for Andrew" enough?
<mothacehe>civodul: oh nginx caching is the reason we don't have much "somewhat slow" warnings when using the publish server at ci.guix.gnu.org?
<civodul>leoprikler: no formal requirement, but it implies that you trust abcdw to "follow the rules"; ideally you'd mentor them when they get started
<civodul>perhaps a discussion to be had beforehand together
<mothacehe>the fiberized web server that cuirass-web uses seems to perform nicely, maybe we could also use it for guix-publish
<civodul>mothacehe: there's nginx but no caching at ci.guix.gnu.org (i removed it a while back)
<civodul>i liked the idea of a simple/simplistic 'guix publish', but maybe that's no longer an option
<civodul>we should understand exactly where those "somewhat slow" diagnostics come from, though
<apteryx_>hello Guix! Quick check; supposed I was to build some package (e.g. qtbase) using a custom toolchain made of our current GCC (7.5) and an old glibc (we have 2.28), I should be able to link against it on any GNU/Linux system that has a glibc >= 2.28, correct?
<abcdw>civodul: Sure, will add a Finalization section to the document!)
<civodul>apteryx_: hi! maybe you don't even need an old glibc; what matters most is the minimum kernel version required by glibc
<civodul>unless you want to build a custom pack stripped of Guix's own libc
<apapsch>is there a way to to get details about "invalid G-expression input"? I have a hard time figuring out what is invalid
<civodul>apapsch: usually it means you're "inserting" something in the gexp that cannot be "lowered" to a file in the store
<civodul>for example, if you do #$(begin foo bar #$(current-module)), you'll get that error
<civodul>because (current-module) returns a <module> record that cannot be lowered to a file
<apapsch>ah, I see it now, a procedure that wasn't invoked but passed as value, thanks
<apteryx_>apapsch: emacs + paredit changed my life
<apapsch>apteryx_: I have the Perfect Setup set up, though without the fu it ain't enough. It's an immaterial thing not obtainable via guix install ;-)
<apteryx_>civodul: the idea would be to build the target application (e.g., jami-qt) with Guix's Qt but otherwise using the system's native libraries (e.g. Debian 10's own libraries but with Guix's Qt). Since the linking would be made by Debian 10's glibc, the glibc used to build Guix's qt would need to be older on equal than the glibc of Debian, no?
<apteryx_>apapsch: OK! Nice. It's all about practice then, which is the fun part :-).
<apteryx_>err, the linking would be made by Debian's linker, rather. Which would link using the Debian's glibc symbols, IIUC.
<civodul>apteryx_: you should check with dongcarl who did something like that for Bitcoin Core, IIRC
<civodul>that requires some surgery though, such as changing the loader's file name and stripping RUNPATH
<civodul>we could make that an option for 'guix pack'
<apteryx_>hehe, OK, I will look into that and perhaps ping dongcarl, thank you
<apteryx_>or go directly to the .deb guix pack generator :-)
<apteryx_>I started looking into that and it doesn't seem too difficult to achieve
<civodul>yeah, i guess we could run code in a Debian VM, and possibly use checkinstall
<apteryx_>the .deb format is very simple; we just need to provide three files; two which are metadata and one which is the file system tarball
<iskarian>when sending a patchset, is it still recommended to use `--in-reply-to=... --no-thread` when sending to NNN@debbugs.gnu.org (in reply to the cover letter)?
<apteryx_>I think the difficulty would be in the details, such as when wanting to install different Guix-generated .deb files that would own the same set of /gnu/store files, they'd likely conflict together.
<apteryx_>that's a weird Qt error to have following my change; I don't have an explanation in mind.
<apteryx_>that paraview package comes from a channel?
<apteryx_>civodul: just realized, in my case (specification->package "gcc@7") was used in a manifest in constructing my custom c-toolchain; what I really want to get is the lonely gcc package rather than the toolchain. Seems I'll have to use the gcc-7 variable directly.
<apteryx_>civodul: note that if we add (define qtbase qtbase-5), the same will also be needed to be done for each qt module (define qtsvg qtsvg-5) when they get updated (there's a patch in review from ecbrown upgrading many qt modules for version 6)
<apteryx_>civodul: for the error you see (qt 5 not being found), I guess I missed some reference to it somewhere, and it's now at qt 6 in your build, causing it to not be found
<apteryx_>all your qtbase references in your channel are now at qtbase-6
<apteryx_>afte we add (define qtbase qtbase-5) that build failure will probably go away.
<apteryx_>hmm, thinking more about it, I don't really like the idea of having qtbase point to qt5. It means we wouldn't likely be able to have the qtbase variable be at qtbase-6 for a year or more (I'm expecting the transition will take a lot of time, similar to Python 2 -> Python 3).
<civodul>apteryx_: you cannot refer to 'gcc' (the variable) via specification->package, because it's hidden
<apapsch>given a one-shot service that is a requirement of a daemon service, the daemon service will start as soon as the one-shot service is successfully started, no? one-shot must not complete before daemon is started?
<civodul>apteryx_: i'm fine with running sed on my channel, np, but it still sounds useful to keep a 'qtbase' variable
<apteryx_>If qtbase was to point to qtbase-6, how would it be useful? In my opinion, Qt5 users should use qtbase-5 from now on, the same Python 2 users must specificy python-2 :-)
<ecbrown>people would have 64-bit containers everywhere
<wenngle>New to Guix System, trying to configure SDDM as a display manager, but I get the error: service 'xorg-server' provided more than once. I'm using the service modules desktop sddm and xorg. How can I resolve this?
<bsima>does the guix world have any thoughts on nix flakes?
<lispmacs[work]>raghavgururajan: not sure if you were looking for my opinion, but the badges in the 48827 issue look good. If you wanted me to be really picky, I'd probably suggest /thinking about/ maybe a slightly simpler logo text, like "GNU Guix ready"
<apteryx>dongcarl: thanks for asking :-). I'm investigating the feasibility of having qtbase built by Guix, and used as part of foreign builds (Debian, Fedora, etc.). My simplest idea is to 'guix pack qtbase', then point the foreign build system to it so that it can be used linked against by the native build. I've read that for this to work, usually the linker/gcc must be newer than any of the constituting
<apteryx>parts, so perhaps I'd have to downgrade the glibc used to build qtbaes on Guix. Any thoughts?
<apteryx>civodul: that could be useful, although we are not ready yet because most qt packages will not only depend on qtbase but also on the qt modules (e.g., qtsvg), which need to be updated first.
<apteryx>civodul: strangely, when building qtbase using a gcc-toolchain made using the 'make-gcc-toolchain' helper, the implicit input named "libc" doesn't seem to exist among the builder inputs; (assoc-ref inputs "libc") apparently return #f, breaking qtbase's patch-paths phase. Any idea why that might be?
<apteryx>civodul: the diff of the inputs when using a custom toolchain; seems the toolchain inputs usually appearing flatly in the bag are now hidden behind the "toolchain" package: https://paste.debian.net/1201209/
<muradm>i'm trying to use libgccjit for emacs, is there any example on how to use it with other package?
<muradm>just puting it to native-inputs or inputs does not work
<muradm>ld: cannot find crtbeginS.o: No such file or directory
<apteryx>are there any differences between .lzma and .xz archives?
<jackhill>systemd sounds like its special software, so probably takes more wrangling than usual to get a working package :) It looks like some of the concerns are being worked though in the ticket, and we'll probably get a systemd package eventually. I guess gccjit is special too, but at least its a component of the already-packaged gcc
<muradm>native compilation will definetly require additional step in emacs-build-system
<jackhill>I wonder if native comp will make the emacs build more reproducable
<dstolfa>i hope it will make emacs drain less battery...
<dstolfa>emacs right now is really heavy on battery usage in large files
<muradm>jackhill: obviously i know what does it mean ) just wander why emacs build isn't
<muradm>if it wasn't reproducable before, why libgccjit should make it so, i can't imagine
<jackhill>well, if we knew exactly why, then it would be easier to fix :) Overall, I think non-reproducable aspects were introduced over the many years, and it hasn't been a priority by the emacs developers to fix. My thought about native comp helping came from seeing many of the reproducability problems in .elc files and the new prortable dumper, which native comp may make irrelivant.
<jackhill>Or it could mean that I really don't understand the big picture.
<apteryx>seems like the upstream of guile-hashing vanished