<rekado_>mbakke: wow, I’m looking forward to this! <mbakke>rekado_: cool :-) I'm thinking it could be nice to have on some of the MDC nodes, to easily provision Guix VMs, run HA services, etc. <NieDzejkob>heh, I see I am being called out in the guix authorization blog post. Twice. :P <jsoo>Rust versions 1.4x are really helping. I packaged racer and rustfmt-nightly with it. Hopefully those patches can get merged when the rust patches land <NieDzejkob>jsoo: Nice! How did you deal with the nightly features that rustfmt requires? <jsoo>I used the forbidden RUSTC_BOOTSTRAP variable. I was thinking that guix users might appreciate one pinned nightly rustc too. I was considering packaging a rust-nightly in the future <NieDzejkob>hmm. I was going to investigate whether it's possible to take the rustc source and tell it to build just rustfmt/clippy/rls with x.py <NieDzejkob>I'm hoping that setting local-rebuild will avoid compiling rustc itself in this case <NieDzejkob>either way, it would be good to use the rustfmt that's shipped together with rustc, that way RUSTC_BOOTSTRAP won't actually ever break <jsoo>I agree. A separate output for rust might be a good solution for the dev tools <jsoo>I used the tool I know how to use is why I made separate packages <jsoo>I also looked at how nix deals with crates that require nightly and it looks like they use RUSTC_BOOTSTRAP, too ***terpri__ is now known as terpri
<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>this is a weird thing to want, so there is no easy way to do it. At least, that I know of <murmr>I would prefer to construct my own binaries for this specific machine. I read that Guix could construct all packages from source (similar to Gentoo, etc). <jonsger>roptat: I'm applying your guix publish nginx settings block by block. It's nice to see how the speed goes up. nar caching brings the most (more then 15x) :) <roptat>jonsger, hm... I think I simply copied that config from the guix repo <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? <roptat>do you use its url in substitute-urls? <jonsger>hm the key somehow change. downloaded, authorized and restarted guix-daemon. It's already in my system substitute-urls <jonsger>manually downloading the nar from host/nar/lzip/abcde works <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 ***jonsger1 is now known as jonsger
***apteryx is now known as Guest47826
***apteryx_ is now known as apteryx
<civodul>hey! mini reproducibility hackathon starting on #guix-hpc :-) <civodul>nckx: do you happen to know what it takes to become op on #guix-hpc? <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 141.80.167.158 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 <leoprikler>but interpreted languages like guile or python use the profile <leoprikler>and then, there's some (mostly GNOME apps), that don't, because they need something really in ~/.guix-profile <janneke>civodul,rekado: not to kick you out of hpc-mode...just a headsup that i managed to a very first successful chilhurd offload on my laptop <zzappie>leoprikler: Thanks for clarification! <rekado>I just used the CUPS web interface; it’s not slow <rekado>I managed to connect to the childhurd only on berlin itself, but not with an extra SSH hop to the nodes where it’s running. <rekado>ignoring that extra hop: connecting directly while on the build node does not work <jonsger>rekado: ehm tallking about the web interface. And it's just the /admin route which is slow *jonsger pulls to the past to get substitutes :( <janneke>rekado: did you (have to) disable the (net-options) ? <janneke>i needed that on my laptop to connect from remote <janneke>the default only has qemu expose the SSH port on 127.0.0.1 <jonsger>is the hash of a narinfo the one of the drv, of the package or a complete different? ***Guest25669 is now known as nikita
***Guest6133 is now known as nikita`
<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. <NieDzejkob>(not sure how to do it with cmake, kodi uses -DSYSTEM_LDFLAGS) <nckx>civodul: I need to ask a Freenode staff member to do that, and there are currently none marked as 'available'. No idea how long it will take. <jonsger>nckx: okay, if I can help testing/reviewing let me know <nckx>Thanks. Won't be today. I've bloofed my rootfs and am currently restoring from backups. <bricewge>I'm building klibc and I'm wondering how to organize it's many outputs <civodul>nckx: ok thanks, it's no big deal, i was wondering if i was missing something <nckx>civodul: OK, I have become op (destroyer of spam), but ChanServ isn't responding to my msgs :-/ Anything specific I can take care of until it does? Topic? Banz? <civodul>NieDzejkob: sometimes cuirass gets it wrong <civodul>it could be because the build actually failed when cuirass initiated it <civodul>but then it was restarted and succeeded <NieDzejkob>civodul: hmm, but guix weather says the substitute isn't available <civodul>NieDzejkob: there's a delay between end-of-build and substitute-available, that might be the reason <redick>I am running guix on by debian laptop and I think I corrupted something. guix pull -l gives an error about my profile not existing. <redick>ls /var/guix/profiles/per-user/redick/ <redick>shows a number of profiles but the 'current-guix' is a broken symlink <redick>I can still install and remove guix packages which is odd. <redick>How do I restore / fix my profile? <Noisytoot>On a user with Guix Rust and Haskell do not work (not installed from Guix), but on a user without Guix they do. Is there a fix for this. <civodul>redick: "current-guix" is the profile populated by 'guix pull' <civodul>did you ever run 'guix pull' before? <redick>@Noisytoot - 'do not work' is rather vague. Is there a specific error message? <madage>NieDzejkob: about that error on pulling "make-channel-introduction: unbound variable", it seems currently channels.scm does not export it <madage>what I did here was: (define make-channel-introduction (@@ (guix channels) make-channel-introduction)) <civodul>madage: that bit was made public ~24h ago, so perhaps you're getting an error because you're running an "old" version <NieDzejkob>Noisytoot: I cannot reproduce this. You need to give us more information. <redick>civodul - no, guix pull prints a message about the savannah git repo and just site there <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 <NieDzejkob>Search on ci.guix.gnu.org is behaving weirdly. When I search for ldc-1, it sometimes shows only successful builds, and sometimes only failing ones <bhartrihari>Hello, which module provides the reduce function in Guile scheme? Directly using it in the repl doesn't work. <NieDzejkob>raghavgururajan: did it print out the commandline for the linker during build? *janneke builds prototype server in VM using inferiors <NieDzejkob>raghavgururajan: CMake Warning: Manually-specified variables were not used by the project: SYSTEM_LDFLAGS <NieDzejkob>I guess kodi had a custom variable and you need to find another way to specify LDFLAGS <MSavoritias[m]1>I install Monero-Gui but for some reason the icon is not added to the Gnome Applications ***zap1 is now known as zzappie
<raghavgururajan>MSavoritias[m]1: Try adding adwaita-icon-theme and/or hicolor-icon-theme to system packages (via system config file). ***ChanServ sets mode: -o nckx
<raghavgururajan>ry adding adwaita-icon-theme and/or hicolor-icon-theme to system packages. That is, edit config.scm and do system reconfigure. <nckx>raghavgururajan: How go things. <Noisytoot>redick: Haskell/Stack works when I set the PATH to the same as the user without Guix. ***Server sets mode: +cnt
<nckx>raghavgururajan: My file system shit the bed (not unexpected; bcachefs) and revealed a bug in my back-up strategy, so I'm now half-way the stages of grief, but otherwise fine 😉 <nckx>raghavgururajan: It depends (as always), mostly on the build system. E.g. if there's a Makefile, read or grep it. <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... <nckx>raghavgururajan: CI/before_install.linux.sh installs gtest/gmock into the container, but I don't see them actually being used anywhere. Maybe just copy & paste :-/ <nckx>raghavgururajan: WANT_DEVTEST? I don't know what ‘DevTest’ files are. <nckx>No INSTALL file, of course, because this is a Very Modern Project. <zzappie>Can I get the repl during buld process? <zzappie>I have nively put (start repl) inside modify-phases but it just doesnt have any effect <Noisytoot>redick: Yes, now everything works, but only when I set the PATH correctly. <nckx>zzappie: I'm not aware of any way to do that. <nckx>Yeah. We'd need a way for the daemon to say (and enforce) ‘you've touched this now, I'm putting it in /gnu/store/foo.tainted’ or something, but that would be worth it. <badair>Deblob issues aside, is anyone working on PinePhone support? ***nckx is now known as ProboskissesXOXO
<vagrantc>badair: basic functionality shouldn't be much different from the pinebook, which has ok-ish support <John1987>Does anyone know how to get Japanese input to work? <John1987>I was able to install Anthy, but I am only able to type in the GNOME search bar. <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? ***ProboskissesXOXO is now known as nck
***nck is now known as nckx
<nckx>Otherwise you're reconfiguring the live system itself which may or may not end well and is definitely pointless. <redick>civodul - I know you said guix pull takes a while for the first time but its been several hours and that seems horribly too long and even with -v 5 nothing is being printed <nckx>lispmacs[work]: That would be best. <nckx>lispmacs[work]: I'm not sure what (if anything) the GUInstaller does after that but I just unmount, reboot, and enjoy the Guix. <rekado>janneke: when I stop the childhurd service and run the exact same command in a shell session I can connect via SSH. <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. <nckx>Hm, that wasn't short at all. <lispmacs[work]>I ran `hash guix' and guix describe shows a guix commit from today, so hopefully I'm good now <janneke>rekado: so, a manual "herd stop childhurd; herd start childurd" does not help? <janneke>i'm wondering if it could be a provision dependency problem? <rekado>janneke: no, that doesn’t work. When I stop and start the childhurd via shepherd the SSH connection attempt times out. <rekado>but we’re probably really close; gotta be some environment/terminal nonsense <raghavgururajan>Now, I am trying to package using cargo-build-system. The dependency lodepng is not being detected. ***terpri_ is now known as terpri
***zap1 is now known as zzappie
<janneke>rekado: yeah..it sometimes amazes me what hurd'les the computer comes up with <janneke>redick: it's become something of a running gag after 5months of troubles <janneke>badair: i haven't caught up, but in genereral mainline + patches is better than a full fork? <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. <badair>Locally, I am just using their fork instead of making patches from it. Which is fine with me :) <janneke>badair: interesting, it's prolly not at all black and white <badair>jenneke: Indeed, thanks for the feedback. <stikonas>ant in guix embeds compile date. Am I missing something or does this make build non-reproducible? <janneke>raghavgururajan: make your diff smaller and bisect; use "make" and look at any warnings <janneke>possibly you made a circular dependency, or have stale .go files <janneke>with a very small diff, it's easier to spot the problem or get help :-) <janneke>yes, that was what i meant; in case you tried "guix build" or something without running make <nckx>stikonas: Yes. You can see it with ‘guix build ant --{check,keep-failed}’. <nckx>Oh, thanks alextee[m]. I've been unable to (re)obtain my Chinese IME that used to work fine. <stikonas>although, maybe there are more problems... <raghavgururajan>nckx: Please leave me a message via sneek. Going to sleep now. Hope it finish building before I wake up. <walter[m]1>sneek, later telp raingloom: hey I fixed my udisks issue by adding polkit-service and polkit-wheel-service to my system.scm <walter[m]1>sneek, later tell raingloom: hey I fixed my udisks issue by adding polkit-service and polkit-wheel-service to my system.scm <ArneBab>somehow the rust bootstrap path is extremely aggravating. It is compiling for more than one full day now. <janneke>it may get better once rust developers start to understand what they have been doing *janneke doesn't mean to single-out rust language devs <jsoo>i spent a week recompiling rust <jsoo>i added a souce output to rust <jsoo>in the spirit of rustup component add rust-src <NieDzejkob>couldn't you do it just for the last version, where it actually matters? <jsoo>also i gc'd and now have to do it over again, oops <NieDzejkob>anyway, hopefully we'll be able to do mrustc->1.39 soon. The commit log for mrustc looks promising :) <NieDzejkob>maybe it's a good idea to redo it and move it to the most recent version this time? <roptat>my build farm is building rust 1.31 now ^^ <roptat>I don't know why, it's leaving a lot of defunct gdb processes behind <stikonas>NieDzejkob: it does take more RAM, doesn't it? <stikonas>not sure about 1.39, but 1.29 needs over 10 GB of RAM on Gentoo <stikonas>once it is compiled with mrustc, it's just as good <stikonas>I think what actually happens is mrustc spits some big .c file which is compiled with gcc and gcc then uses 10 GiB or RAM or so ***sneek_ is now known as sneek
<jsoo>i'm trying to test bpftrace now. i know somewhat little about kernel modules. when running bpftrace it errors saying that the kheaders module is not in booted-system <jsoo>do i need to insmod something or specify kernel modules in config.scm? <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>this is where shepherd puts its stuff <civodul>but then individual daemons may have their own file <jojoz[m]>civodul: It just says "Jul 3 22:15:39 localhost shepherd[1]: 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 *rekado adds guix to the inputs <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) <cbaines>murmr, do you happen to know what derivation failed to build? <murmr>cbaines: Shutdown the machine so not sure I have the log anymore. Fairly certain it was 1.26. <civodul>cbaines: that's a likely culprit, though i'm pretty sure i built all the dependents <rekado>civodul: oh, there it is: you replaced ‘guix’ with ‘guile’. <jojoz[m]>civodul: Oh, ok. I've made some progress using good ol' trial-and-error, but not having the log is really too bad :/ <luke-jr>guix build: error: could not find bootstrap binary 'tar' for system 'powerpc64le-linux' ***slyfox_ is now known as slyfox
<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? <civodul>oh we should complete that import/semver review <civodul>not sure why you get that error, does "guile -c '(use-modules (semver))'" work? <ngz>civodul: no code for module semver (or guile-semver). <ngz>I may not be doing it right though. I applied the 6 patches on a new branch, then run guix environment guix, and ./pre-inst-env guix import crate whatever <civodul>i just tried "find $(guix build guile-semver)" <civodul>it's built for Guile 2.2, unlike the other packages <civodul>so you'll need to switch it to 3.0 first <ngz>There's a guile3.0-semver already <rekado>luke-jr: have you ported Guix to powerpc64le-linux? What have you done so far to build the bootstrap binaries? <luke-jr>rekado: I was thinking `guix build bootstrap-tarballs` would do that <ngz>civodul: guile -c '(use-modules (guile3.0-semver))' fails too. <luke-jr>this isn't an arch/platform issue yet - I'll cross that bridge when I get there <rekado>luke-jr: you would need to cross-build the bootstrap binaries for powerpc64le-linux first, I think; then add them to %bootstrap-executables in (gnu packages bootstrap), etc