<leoprikler>I don't really think the Guix workflow of letting your patches sit in a mailing list for a few days to a few weeks is well-suited for nightly package upgrades.
<murmr>Hi, after recently installing GuixSD, I would like to retroactively build all of my current packages from source. But calling reconfigure with --no-substitutes doesn't seem to initiate any builds.
<NieDzejkob>murmr: Hmm, I'm having trouble coming up with a threat model where this has any benefit. Usually you'd just not use substitutes from the start if you don't trust them.
<murmr>NieDzejkob: I'm not v concerned about the security, mostly curious on how to reproducibly bootstrap my system from source. Since I used the guided installer, I did not see an option for rejecting substitutes.
***jonsger1 is now known as jonsger
<NieDzejkob>murmr: Well, it's tricky as you can't remove the items from the store, but you could do guix gc and then guix build --check on the (package-closure (operating-system-packages your-config))
<jonsger>getting my system to use my substitution server is another story. It does not use them, even if they available. I don't know why
<roptat>have you authorized your substitute server?
<NieDzejkob>huh, guix pull is complaining that "/etc/guix/channels.scm:15:6: error: make-channel-introduction: unbound variable" and "hint: Did you forget `(use-modules (guix channels))'?", but I already have (use-modules (guix channels)) at the top of /etc/guix/channels.scm
<lrssi>error: connect: /run/user/1000/shepherd/socket: No such file or directory
<lrssi>How should I use the shepherd user service?
<murmr>Tried pulling, looks like I can't compute the derivation for Guix 67d621c
<zzappie>I'm packaging a project containig guile code and C extension. It seemed to me that I configured everything with autotools (that was a challenge), but after installatin with guix I can not load the extensions. So I looked at how other folks do It and found extensions are placed either in lib/guile/$(GUILE_EFFECTIVE_VERSION)/extensions or just in LIBRARY_DIR. But one thing that surprised me that it's
<zzappie>not common pratice is to patch scm files so they load extension forom sthe store
***nikita_ is now known as nikita
<zzappie>civodul: Hi! Happy hackathon. I'd love to join in but im busy today :(
***nikita is now known as Guest25669
<zzappie>So linkg... So is it the prefered way to pakage guile with extensions? And if it is, why don't we have the env variable telling guile to load extensions from guiles extensions dir? Does any one has an idea?
*zzappie i wrote *not common practice* but actually meant *common practice* :)
<civodul>zzappie: yeah it's common practice to make sure extensions are dlopened from the right place
<rekado>janneke: the two nodes are now configured with childhurds. Thank you!
<rekado>the only hiccup was that the remote needed to have an updated Guix, so I first deployed a later version of Guix and then deployed again with the childhurd enabled.
<zzappie>What I don't get is that extensions end up in profile anyway but we are ignoring the existing link in profile in a folder specifically made for guile extensions and ponting straight to the store item.
<rekado>unfortunately, I can’t ssh to the hurds; I tried ‘ssh 22.214.171.124 ssh -p 10022 127.0.0.1’, but this times out
<leoprikler>zzappie: the thing is, that Guile doesn't search ~/.guix-profiles for extensions. In my personal opinion it should do that, but it doesn't.
<rekado>.guix-profile is not the only location where people can install extensions (or anything)
<rekado>so searching .guix-profile would only work in the simplest case
<leoprikler>Well, that was actually a shorthand for saying, that we don't have a search-path for extensions.
<leoprikler>We do set GUILE_LOAD_PATH in ~/.guix-profile/etc/profiles but not extension paths, even though $prefix/lib/guile/$GUILE_VERSION/extensions is the canonical path most libraries use for that
<zzappie>leopicker: Yes I think a bit counterintuitive because if we link globally the profile no longer provide "everything you need". It's a first time I see this maybe there are other cases. I know that nix always does linking to store they even patch elfs. I actually thought that It is a guix way to incapsulate everything in a profile, and I thought this is the reason that there so much environment
<raghavgururajan>error: depends on 'libmfx.so.1', which cannot be found in RUNPATH ("/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib" "/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib" "/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/../../..")
<rekado>janneke: I commented net-options only for the initial run of ‘guix deploy’; I then uncommented them and re-ran ‘guix deploy’ (now with a newer Guix on the remote)
<rekado>I’ll try stopping the service and re-deploying
<janneke>rekado: okay, great...let's see how it goes
***lukedashjr is now known as luke-jr
<nckx>jonsger: You mean as opposed to another...? Or just in general? Yes, the 2-minute delay is there both on localhost and the nginx-proxied print server. The fix is trivial but not merged yet AFAIK.
<redick>Noisytoot - My first guess would be to check the PATH and other env variables
<Noisytoot>redick: For Rust it has a segmentation fault when I run the program (sometimes it does not even compile), and for Haskell running the program fails with "error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory" and also sometimes does not even compile.
<civodul>redick: the first 'guix pull' takes a bit of time to clone the Git repository
<civodul>unfortunately it doesn't print a progress report at this point
<redick>civodul - ah, and thus missing profile is 'normal' and 'ok' at this point
<nckx>I didn't lose much (back-ups started corrupting 3 weeks ago) and nothing critical, and I can rewrite it if I remember what it was. It's more the not knowing/frantically trying to remember *which* genius ideas I had the past 3 weeks...
<rekado>John1987: there seems to be a recent regression; I can no longer reliably use Chinese input methods.
<John1987>I see. It works fine in the GNOME search bar but nowhere else.
<lispmacs[work]>I'm attempting to install guix on a system using the ISO I downloaded a month or a two. I get through most of the install wizard but the profile building process fails due to some problem with input/output while trying to run a union-of-directories procedure on the store
<lispmacs[work]>rather than figuring that out, I was just going to run guix pull
<lispmacs[work]>which I am doing. But what command should I use after that exactly to build the system?
<lispmacs[work]>I mean, will just guix reconfigure /mnt/etc/config.scm work, or do I need to add any arguments?
<janneke>rekado: well...of course booting it takes some time and also, /sometimes/ booting fails
<janneke>about 1 in 20 times or so, ext2fs.static just "hangs"
<wdkrnls>How do I do the equivalent of a 'make clean' with guix time-machine? I thought maybe there was a 'guix gc' command, but I'm not seeing a promising sounding argument.
<wdkrnls>I tried `guix gc -D ...` but that didn't see like it did enough. The full computation isn't being redone.
<janneke>rekado: so...i've seen quite some (weird) things but sadly this does not ring a bell yet...
<lispmacs[work]>nckx: after running `guix pull' I get a "hint" that implies I should set PATH, and then run `hash guix'. I'm not quite clear on what that means
<nckx>TL;DR: Unix processes can't set the environment of the shell that spawned them; your shell might have cached the ‘old’ (/run/current-system) location of guix instead of looking it up in $PATH every time; your pulled guix is in ~/.config/guix; hash guix will force the shell to look it up in $PATH again.
<badair>janneke: Is this the conventional wisdom? So we need to generate fresh patches from the vendor fork ourselves whenever we bump the mainline version?
<janneke>badair: i don't know...i'm not a big fan of conventional wisdom; thoughtful discussion > mindless policy
<janneke>i said "in general ... is better than"; i meant that as an invitation to keep thinking
<janneke>the projection is that vendor forks will be upstreamed, if someone helps with that it's great, no?
<badair>One one hand I can see that patches in our source tree are easier to audit and trust. On the other hand, it seems like repeating work already done by the vendor. AFAICT Pine64 is pretty good about upstreaming things.
<stikonas>it's probably C++ actually, not C, so tcc wouldn't work
<jojoz[m]>Where do I find the herd log? I'm trying to set up a httpd server, but any nontrivial configs I write causes the service to fail to start. Trying to start it manually with `herd start httpd` only says "Service httpd could not be started".
<jojoz[m]>I want to find out what Apache has to say about the config, like if there's some module I've forgotten to load. This is why I want to read the log.
<civodul>but then individual daemons may have their own file
<jojoz[m]>civodul: It just says "Jul 3 22:15:39 localhost shepherd: Service httpd could not be started."
<jojoz[m]>httpd writes errors to /var/log/httpd/error_log, but it doesn't get that far in the process. I assume it fails during reading of the config, which is before it's even knows to write errors there.
<jojoz[m]>So the errors ought to have been printed to stderr when trying to start the service. Is this not recorded in some similar global shepherd log?
<civodul>jojoz[m]: it's not recorded, unless the service definition explicitly uses #:log-file
<civodul>which is apparently not the case here :-/
<rekado>can’t reconfigure on bayfront because hpcguix-web says: configure: error: Guix appears to be too old; please upgrade to Guix > 0.15.0.
<rekado>suspicious: checking if (guix inferior) is available... no
<civodul>hpcguix-web must have broken recently, it built in 8b1f7c03d239ca703b56f2a6e5f228c79bc1857e
<murmr>Hello, after spending +13 hours building Rust, and ending up with a derivation failure, I'm wondering what the recommended upgrade strategy is for GuixSD? Should I be waiting several days to trust the master branch? Should I not be relying on master at all for stability?
<murmr>(initially I required the latest ISO to get around the nvme bug in the installer)
<ngz>Hello. I wanted to try guile-semver patch set in order to import some Rust library, but I get `semver-range-contains?: unbound variable' error. I assume guile-semver is not properly loaded. What am I missing?