<luis-felipe>Oh, the instructions to build the website don't work for me, I get the following error after I run the command in the "Build locally" section of the README: <luis-felipe>guix environment: error: stat: No existe el fichero o el directorio: "/home/yo/.guix-profile/lib/locale" <luis-felipe>In any case, the style for the proposed banner just puts the banner below the header element, changes the background color to "#144054" and adds "box-shadow: inset 0px 0px 4px black;" <luis-felipe>If someone with commit access would like to make the change. <pkill9>chromium extensions packaged in guix now, nice <atomsk298>Hello, I am attempting to build a package, but I am having some difficulty towards the install phase. The error Im seeing is no binary interpreter for lua or ruby found, but Im not exactly sure what is meant by that. Any suggestions? Here is the paste of the code: <lfam>atomsk298: I'm not familiar with this program, but I'd guess that you need to add the lua (or ruby?) package to the list of inputs <lfam>atomsk298: You might also take a look at some of the packages in 'gnu/packages/lua.scm'. Maybe there is some inspiration there <raingloom>heeyy, so, my VPS says it /gnu/store/<hash>-bash-5.0.16/bin/bash does not exist, but it is definitely there. what the heck could be up with it? last thing i remember doing was running guix pull, but i think i interrupted it? but that should not break login.... right? <iyzsong-w>what program output that 'bash' does not exist? the console login or guix? <iyzsong-w>um, then how you check it, if you can't login.. <raingloom>i mounted /dev/vda1 from the live session and looked at the store. <raingloom>at least i get an init debug repl, but it's not much help. <iyzsong-w>okay, is that bash runable? you can bind mount store into /gnu and try <iyzsong-w>that dosen't matter, you can mount /dev/vda1 into /mnt, then bind mount /mnt/gnu into /gnu, then try run /gnu/store/...bash../bin/bash <roptat>also "not found" can sometimes mean that a library was not found <roptat>check all its libraries are actually present in the store; you should find them with ldd /gnu/store/.../bin/bash <iyzsong-w>sure, if it can not be run, then we should find some tips.. <roptat>was this installed with "guix system init /etc/config.scm /"? I think this might override the database and make huge parts of the store unusable <raingloom>roptat: it was, but it was working perfectly file while i was using it. i even rebooted it a few times. <iyzsong-w>okay, 'ldd' that bash show missing libraries? <iyzsong-w>it was working, but now broken, between that time, have you run 'guix gc' or 'guix system reconfigure'? <iyzsong-w>to fix it, you can try boot previous system generations (in the grub menu), or install again.. <raingloom>iyzsong-w: looks like all the referenced libraries exist <raingloom>...i'm not actually sure how to access the grub menu. <iyzsong-w>raingloom: um.. try 'strace -o /tmp/x.log /gnu/.../bash', then maybe find what's not found in '/tmp/x.log', i guess you can install strace via apt. <lfam>When you say "looks like all the referenced libraries exist", did you look them up "by hand"? Or did you use ldd <raingloom>lfam: i piped ldd through some grep/awk/xargs/file magic <iyzsong-w>ah, you're install on VPS, maybe through its webVNC <lfam>So, you had a working system (new install?), interrupted `guix pull`, and it broke? <lfam>Can you give any more details? <raingloom>lfam: well, guix describe said i haven't pulled yet, which was definitely false. <raingloom>so i triple checked, with sudo -i and bash -i, and as the non-root user. <raingloom>the telltale sign was that yggdrasil disappeared. <lfam>Or, what command did you run? <lfam>So, the wrong version of guix was in effect, even though you had previously ran `guix pull`? <lfam>Was it a new installation? <lfam>From the installer image? <raingloom>no, installed on top of Ubuntu from the install script. <lfam>My impression is that it's tricky on a VPS <lfam>Hard to debug if you can't log in <lfam>Which script did you follow? <raingloom>the installation was done using the official install script. <lfam>Sorry, I don't know that one. Do you have a link? <lfam>I would double-check the permissions of /home <lfam>Especially if that user already existed <lfam>The one specific in config.scm <lfam>Okay, check the permissions anyways <iyzsong-w>so you 'boot ubuntu iso', 'install guix in the live environment', then 'guix system init' <lfam>You should compare the permissions with /etc/passwd and /etc/group, and against your own effective user as well <iyzsong-w>have you once boot the installed guix system successful? <raingloom>lfam: ok, but how does that explain sshd not being found? <lfam>Sometimes the "not found" error message is misleading <lfam>Especially since the files *do* exist and have proper permissions, right? <raingloom>yeah, but sshd is started by shepherd, it has nothing to do with my user. <lfam>And since you can't login, it makes me suspect the user stuff <lfam>Yes, but presumably there was already an sshd user from the host OS <raingloom>right now it doesn't even boot properly, it drops me into the init rescue REPL. <lfam>I thought the problem was that you couldn't log in <iyzsong-w>did you install ubuntu on /dev/vda1 first, then guix system, or only guix system? <lfam>I agree, strace will help a lot <raingloom>strace is def a good idea... hopefully the ISO has it... <raingloom>....but what do i strace??? bash? because i have no idea how to trace the init. <raingloom>one of the """perks""" of the current REPL. >_> <lfam>You can mount the filesystem, right? <lfam>strace -f /gnu/store/...-bash/bin/bash <raingloom>i'm not sure what to make of the strace output.... the very first call (the execve one) returns ENOENT... the rest seems like boilerplate to print the error... <lfam>Can you share the full strace output with us? <raingloom>fstat(2,,..), ioctl(2,...), write(2,...), getpid(), exit_group(1) <raingloom>lfam: uuuh, only as a screenshot... i'll try to ssh into it. this NoVNC thing is getting on my nerves. <raingloom>iyzsong-w: the copy part is the problem, not the paste. <iyzsong-w>strace -o /tmp/x.log, can output it into a file (/tmp/x.log) <raingloom>ohhh, rebooting from the recovery with active VNC gives me a GRUB menu :O <iyzsong-w>okay, there is no previous system generations? <lfam>I wonder if guix-install.sh does anything to handle the bootloader when installing over a VPS. In my experience that doesn't "just work" <iyzsong-w>then 'guix system init /mnt' as usually to install the system, if /mnt is empty, then it's idential to do a install from the guix live system iso. <lfam>Can you run it again without abbreviation? `strace -f -e abbrev=none ...` <iyzsong-w>also, i guess we may get more useful ldd output if we use '/gnu/store/xxx/bin/ldd /gnu/store/.../bash' <iyzsong-w>can you try again with full path to bash, not './bash'? <raingloom>hmm, /mnt/var/guix/profiles/per-user/root/current-guix.lock exists <raingloom>thanks for the help so far, i think i'm gonna restart from a snapshot. <raingloom>and take notes of what i'm doing, so if i mess it up again, i'll have some data. <lfam>Thanks, that will be helpful <iyzsong-w>um, i guess it's the dynamic loader (/gnu/store/...glibc.../lib/ld-linux-x86-64.so.X) can't be loaded <raingloom>> error: executing `/gnu/store/ar5qp4vilw2jmnikvcsf1h5ii80m46q6-guix-1.1.0-32.5e7cf66/bin/guix substitute': No such file or directory <raingloom>ok, i think it's gonna happen again. i totally forgot last time, but this was the error i saw. <raingloom>bash: /run/current-system/profile/bin/ls: No such file or directory :D <raingloom>ok, i'm not rebooting this time. let's see if i can rescue it from this shell. <raingloom>bash: /run/current-system/profile/bin/ls: No such file or directory <raingloom>bash: /run/booted-system/profile/bin/ls: No such file or directory <raingloom>markasoftware: npm ecosystem is very difficult to package reproducibly. lots of dependency loops from what i heard. <lfam>raingloom: Sorry we don't have more advice about your problem. You should get more help if you ask again later, or send a bug report — ideally with steps to reproduce <raingloom>lfam: no prob. i found an alternate way to install it on the mailing list, gonna try it once my custom VM image upload is finished. <raingloom>it's not quite as good as the original attempt, as it incurs some extra billing, but probably won't cost anything significant. <mroh>abcdw: So, we need to update our emacs-use-package to make it useable with emacs28? <abcdw>Dear maintainers, can I send a patch to update version of emacs-use-package? It has latest in the repository 2.4 since november 2018, but this version doesn't work with emacs28. melpa and many other GNU/Linux distributions uses version from 20200721. <abcdw>mroh: lol, I was writing the message about it) <leoprikler>if there's a 3.x, 2.5 or 2.4.x release, naturally <leoprikler>if not, compatibility might be a reason to pin a certain commit, but you might want to make it emacs-next-use-package and still keep the Guix versioning scheme <abcdw>leoprikler: there is no tag for the commit from 20200721. I just found that in melpa and nix repositories they use the same commit. <abcdw>Actually the version from 20200721 works with emacs27. And there is not so much sense to keep a separate emacs-next-use-package. <bdju>anyone here using piper and ratbagd? I installed piper as my user and added the simple service to my system config but it still can't find the daemon <leoprikler>abcdw: there is, because you can specifically build that using emacs-next as #:emacs <leoprikler>instead of hardcoding version use (git-version version revision tag) <abcdw>leoprikler: it works even built with emacs-minimal. I won't be adding a separate argument here. <bryanhonof>Hello, I recently started using NixOS and I think I am getting the hang of it. Now, I'd like to liberate my machine with Guix but I am unsure if my Wi-Fi card is supported, is there any way to check it? <abcdw>leoprikler: can you clarify the message about git-version, please? <abcdw>bryanhonof: Just boot with livecd/usb and check) <bryanhonof>abcdw: That could indeed work, I'll try that. Thank you ^.^ ***apteryx is now known as Guest67236
***apteryx_ is now known as apteryx
<leoprikler>abcdw: When building stuff from git commits, we use a versioning scheme, that looks like (version (git-version v r c)), where v is the latest "stable" version, c is the commit and r is a revision tag <leoprikler>r is typically counted from 0 upwards, but there are other kinds of r (e.g. date tags) too <abcdw>leoprikler: Also, I would like to remove diminish from propagated-inputs, because it's an optional dependency, as well as delight (which isn't in propagated-inputs). <civodul>mothacehe: did you find out what the problem was with partitioning? <mothacehe>civodul: no, I'm pretty sure auto-partitioning didn't like the original partitioning of my USB drive but I was unable to reproduce it :( <mothacehe>can't remember what was originally on that drive <mothacehe>tried dos and gpt tables with fat/ntfs/ext partitions without success <leoprikler>abcdw: lgtm, but you should change the (name ) field as well *jonsger needs one more folk to pledge for commit access :) <civodul>mothacehe: perhaps we can reproduce it with QEMU: create an image, boot the installer to partition that image, stop QEMU, then restart the installer and see if it crashes <civodul>that said, if you already tried different combinations and failed to reproduce it, maybe that's okay <civodul>how do you think we should proceed now? <mothacehe>I also tried to put a Guix System image on an USB drive and run auto-partition on it (on real HW), no success. <mothacehe>I can try it with QEMU but it should be the same <civodul>should we send another call for testing? <mothacehe>well it's certainly some tricky corner case, so it's fine to proceed I think. Plus having the debug output I added will help to understand if someone reproduces it. <civodul>there've been a few noticeable changes since the last testing round though, do you think we should ask again and wait for a few days? <efraim>good news on mips64el, if I can make a good PMON config file then I can skip grub entirely <civodul>that means we'd be effectively releasing next week, probably <civodul>like we/i could build the images and all over the week-end and announce on Monday maybe *jonsger can do a last installation test on his laptop <g_bor[m]>do we have a 1.2 image already available somewhere? <mothacehe>Cuirass does not build iso on top of the 1.2.0 branch <civodul>mothacehe: oh yes, that'd be great, so we can ask people to download it from there <g_bor[m]>I could free up a vm and do a complete manual install test... <civodul>g_bor[m]: that'd be great! we'll have one soonish *mothacehe fire up sqlite *civodul tries to reproduce <efraim>looks like I can't use a loopback device on bayfront, I'll have to copy the image to my machine <leoprikler>Apart from the fact, that you're replacing a stable version without a comment as to why, lgtm <leoprikler>Comment as in code comment, but your commit message needs the changelog treatment too <efraim>hmm, my disk image has an extra EFI partition in it :/ <leoprikler>[And again, since stable works fine, why replace it for 27 users?] <abcdw>leoprikler: Replacing seems logical, because it will be easier to maintain one package instead of two. I see only one problem in this patch: I remove diminish from propagated inputs, which can break someones setup. <leoprikler>In that case why even have emacs-next, when emacs already exists? <leoprikler>Prior to the Emacs 27 launch, we had a number of packages built extra for emacs-next [at that time next being 27], so doing the same for 28 will not be wrong. <abcdw>and it seems that difference between 27 and 28 much bigger than 2.4 and 2.5 for use-package. <leoprikler>perhaps, but what are you trying to accomplish here? <leoprikler>is it not to package a 28-compatible use-package? <abcdw>leoprikler: ok, sounds reasonable. Will make a separate package for 28. <abcdw>leoprikler: thank you for help and tips! <abcdw>Additionally posted a comment on the issue about 2.5 tag) <leoprikler>For the record, there is also emacs-leaf, which in Guix is updated to 4.2.5 <leoprikler>(Which is interesting, given that latest Git tag is 4.1.0, but elpa is fresher) <mothacehe> civodul: there's a first 1.2.0 image available at: <divoplade>Hi! I'm trying to set up exim, but it does not find the "plaintext" authenticator <zimoun>civodul: “guix weather -c 100“ returns java-snappy. Well, I am not sure to understand Data Service and ci.guix.gnu.org but the package builds correctly on my machine. <roptat>what's our policy for that? I don't think there is any other way to get this archive <roptat>I don't know, I'm just trying to help someone get their patches merged <roptat>it's "inspired by", so it's clearly not exactly the same, not sure if the contributor will be happy with this ***Kimapr_ is now known as Kimapr
<zimoun>civodul: sbcl-zpb-ttf with counts at 23 seems scheduled but never build. The package builds locally. (And on Bayfront) <zimoun>roptat: I do not know if there is any solution if upstream is sometimes doing in-place replacement. Well, it depends on the “sometimes”. :-) <roptat>it happened somewhere 2 months ago, but that can't really help getting an idea of how frequent that is :) <divoplade>More precisely, it seems that texim cannot find any authenticator <civodul>zimoun: do you have the .drv file name of that one? <zimoun>civodul: Hi :-) (With lockdown, I am losing the notion of time so I never know) <zimoun>civodul, do you mean that /gnu/store/dwp33i2ylw81q996aq4zm4lgjl25pzyh-sbcl-zpb-ttf-1.0.3.drv? <civodul>did you do "-d --no-grafts" from version-1.2.0? <zimoun>yes, sbcl-zpb-ttf is missing. But everything is fine. I think it was a IO issue. <civodul>you could ask the submitter whether there's a more reliable way to get it <civodul>and as a last resort, we can refer to the unversioned tarball <zimoun>civodul: has something happened on Nov. 2dn on Berlin? <zimoun>I do not, trying the packages from the list “guix weather -c 10” I have the impression that some packages are scheduled since the Nov. 02. Maybe just eyes too tired. <civodul>zimoun: what are you looking at though? "guix weather" doesn't mention scheduling times <zimoun>civodul: my process is “guix weather -c 20” then package by package look to Data Service and ci.guix.gnu.org why the package is missing, then try to build it locally. <zimoun>from the Data Service. But the most probable is bunch of sbcl commits at this date. <zimoun>civodul: aside these minor build issue, version-1.2.0 seems in good shape, isn’t it? <civodul>that's the last thing we could possibly include <roptat>oh by the way, I have a meeting with someone from opam, and the person behind opam2nix tomorrow :) <roptat>they're interested in our ocaml packaging <civodul>let's see which of "guix import opam" and "opam2nix" deserves a prize :-) <civodul>it's great to be able to have such a discussion <roptat>zimoun, oh and I should finish the ocaml update... <roptat>no, after your last comments, I just forgot to work on it ^^' <roptat>we pushed the dune update though <divoplade>I wish we had something comparable to dune for guile :( <divoplade>The closest thing would be hall, but it lacks features and extensibility <rekado>the error is: “(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (r-kegg-db)) (value #f))” <zimoun>rekado: wip-r is from my branch, right? <apteryx>civodul: I just pushed update-guix-package to version-1.2.0. 'make release' should be operational. <rekado>zimoun: yes, I just rebased it a few days ago. <abcdw>leoprikler: yup, it's funny, there is no 4.2.5 tag in leaf repo. <apteryx>Could someone run 'make update-guix-package' on the version-1.2.0 branch and report any failure? <civodul>apteryx: thank you! i'll give it a try <divoplade>Is it possible to inherit a package, while just adding a snippet to its origin? <divoplade>I can copy the whole source definition and add my gexp at the end, but maybe there's a better way? <leoprikler>yes, but it's a little complicated, because you have to inherit the origin as well <leoprikler>i.e. (origin (inherit (package-source pkg) (snippet ...))) <leoprikler>(origin (inherit (package-source pkg)) (snippet ...)) <divoplade>That's a bit strange to me that the function package-source returns an origin <leoprikler>the source field of a package must always be an <origin> record <zimoun>rekado: how do I correct? Do I rebase and push a write the history or add a commit that fixes? Since it is ’wip-r’, rewriting the allowed, right? <efraim>what kinds of fixes are OK on 1.2.0? I was thinking of trying to fix some of the aarch64 failures from 'guix weather -c 100 --system=aarch64-linux' <zimoun>efraim, yeah I agree. But how are defined academic and non-academic? I mean it is not legal terms, even if IANAL. <efraim>my understanding is since it limits the license to exclude non-academic users (alternatively tall users, left-handed users, users in the Southern Hemisphere) it's non-free. <civodul>efraim: package fixes are welcome, as long as it doesn't trigger rebuilds on platforms where everything's fine <civodul>if unsure, we can discuss on a case-by-case basis! <efraim>civodul: sounds good. i've ruled out a couple so far as building just fine on my board <zimoun>rekado: I rewrote the history of my branch removing the offender. <g_bor[m]>civodul: please ping when we have a 1.2 image <apteryx>civodul: nice video! This is with your original patch? <civodul>apteryx: yes, so if you still have the improved variant, that'd be nice <civodul>(you said the last one that you posted doesn't work, right?) <jsoo>Is that because of lack of reference to gcc? <g_bor[m]>jsoo: What is the problem with having it in a separate output? <abcdw>Sent my first patch to guix-patches@gnu.org, yay! <jsoo>Well I would love to have cross-binutils-gold <jsoo>I know there is a lot of work put into binutils to keep gcc out of the closure <jsoo>I'm trying to get ghc onto aarch64 <jsoo>I think ld.gold is one of the big hurdles towards that <apteryx>civodul: I think I hadn't post the last version I meant to test <jsoo>In other words, I don't mind if it's in a separate package as long as I can use it as an input when cross-compiling ghc <apteryx>civodul: I'll try to test it now, and if it seems to work, I'll share it <vagrantc>civodul: so, it seemed that the simple bash, mkdir, xz and tar bootstrap binaries are simple enough to copy for the tests, but %bootstrap-guile %bootstrap-coreutils&co %bootstrap-binutils %bootstrap-gcc are proving to be more challenging <vagrantc>i wonder if a flag to pass to tests GUIX_USE_SYSTEM_BOOTSTRAP or something would make sense <vagrantc>although jwilk someone pointed out that passing RES_OPTIONS=attempts:0 should disable name resolution, which might be simpler for disabling the network tests at least ... doesn't resolve all the bootstrap binary stuff, though <civodul>vagrantc: we have tests relying on %bootstrap-gcc & co.? <civodul>i think they are already under "if (network-reachable?)" or similar, no? <civodul>but they're skipped if those are unavailable <civodul>i'm not keen on adding another env var because it's likely to bitrot <vagrantc>they seem to require network if the files aren't present, but do not seem network guarded to me... <vagrantc>but maybe the name resolution workaround will work well enough <civodul>debug-link.scm has (unless (network-reachable?) (test-skip 1)) <civodul>they're definitely network-guarded otherwise the 'guix' package would fail to build <vagrantc>maybe my failures are not network related, then ... <civodul>are you looking at 1.1.0 or current-ish master? <vagrantc>i'll drop that patch and see if it hurts. <vagrantc>must have been resolved in some way that wasn't entirely incompatible with the patch. <civodul>let me know if you think it's a bad idea :-) <vagrantc>9e2523c25f7b8d6e8c29c679ad899703a120eed8 to be exact <vagrantc>civodul: hope to have it working well enough "soon" <vagrantc>civodul: so sure, it's probably nice to have it there :) <vagrantc>or maybe just debian's specific build of guile 3.0 ... hrm. <civodul>we've had issues with Guile on libgc 8.0 <civodul>i think cbaines & mothacehe had to resort to Guile on libgc 7.x in a couple of places <civodul>(Data Service, Coordinator, and Cuirass, i think) <jonsger>vagrantc: so debian has libgc 8 or 7? <civodul>but maybe that indicates a deeper problem <vagrantc>jonsger: appears to be both versions under different package names ... <buenouanq>on guixsd gnome, xfce4-terminal does not recieve focus when opened <zimoun>efraim: which packages of aarch64 are yoy tring to fix? <vagrantc>jonsger: though maybe one of them is just cruft at this point and hasn't been removed <vagrantc>civodul: the bootstrap binaries aren't pulled in as (implicit?) inputs for guix? <vagrantc>test seems to be hung on 6536 /usr/bin/guile-3.0 \ /build/guix-1H8BxH/guix-1.1.0+67260.9e2523/scripts/guix substitute --query <vagrantc>definitely tests requiring bootstrap-guile are failing when they can't download it <apteryx>civodul: I've tested your patch again with a disk image, and I cannot reproduce the success... not sure what's going on. I've grafted the glib package with your patch added. <vits-test>buenouanq: if i remember well Gnome has some settings for focus, like "click to focus, point cursor to focus". can it be the case? *vagrantc tries copying /usr/bin/guile-3.0 to gnu/packages/bootstrap/$(BOOTSTRAP_ARCH)/guile <vagrantc>but i have this suspicion that's not where it goes... <bluekeys>Hi guix. I just got a delivery of a pinephone. Anyone else here got one? Anyone running guix on it? <vagrantc>depending on how far the pinephone has deviated from pine64+ and pinebook, both of which work reasonably well, it should certainly be worth trying, though you'll probably at least need a custom bootloader <vagrantc>looks like there is some support for pinephone since linux-ibre 5.7 ... <vagrantc>might need to enable some kernel options for the display, etc... <cbaines>have you encountered a guile+libgc@8 problem just now civodul? <efraim>zimoun: of the ones I've tested so far only sbcl-cffi-libffi has actually been broken on aarch64 <vagrantc>cbaines: it appears to be an (indirect) issue for the guix package on debian being able to use guile 3.0 <cbaines>vagrantc, interesting, where did you see the crash? <vagrantc>cbaines: guile-gnutls fails to build with guile 3.0 in some cases on debian, which is needed to build guix <cbaines>vagrantc, I guess that failure might occur with the Guix package as well then <vagrantc>so far i've got 96 test failures, and 953 test passes ... all of the failures appear to be related to bootstrap binaries <apteryx>actualy the --image-size always seem to break *vagrantc was missing sneek too <apteryx>what's the smallest application you know of that has a .desktop file? <apteryx>lfam: indeed! Was it dthompson who manages sneek? <apteryx>ah, thank you. Wonder how it's done. Perhaps we could have a guix service for it on the head node. <nckx>apteryx: No dice, no source. <leoprikler>apteryx: polari is relatively small (dependencies are mostly covered by gnome already) <apteryx>interestingly when testing in a disk image the guix in use doesn't seem to be the guix that populated the store, so installing something pulls the complete deps (doesn't reuse those of the GNOME desktop) <nckx>apteryx: Yeah, that can be confusing until you realise what's happening. <nckx>Esp. when writing system tests &c. <cbaines>Is it the status-request-revoked test that you see fail with guile-gnutls? I've seen that fail a few times. <bluekeys>Thanks vagrantc, vits-test. The custom bootloader and screen settings would put me off slightly, but I'll try and speak to str1ngs, see how they got on. <apteryx>leoprikler: emacs-no-x has a .desktop file and weights 263 MiB :-) <apteryx>there's probably even smaller things that I can't think about <lfam>It's down PotentialUser. It was up within the last hour-ish <PotentialUser>just wanted to check if there were any plans on porting .NET 5.0 <apteryx>another disk-image question: aren't these supposed to be booted as persistent storage? When I boot it right now, nothing gets persisted (it seems to use some volatile overlayfs on top of root) ***lukedashjr is now known as luke-jr
<cbaines>I just tried restarting goggles on bayfront, but it doesn't start... <apteryx>civodul: I've made another fresh try with the grafted approach (changing only an insignificant detail from the patch to make sure the grafts get recreated). Something's fishy. <nckx>cbaines: goggles.scm[26223]: segfault at 0 ip 0000000000000000 sp 00007f3d152ee978 error 14 in guile[400000+1000] <civodul>apteryx: weird; do you have the GLib patch around? <civodul>vagrantc: re bootstrap-guile, it has to go to the test store; see package-management.scm <civodul>but hmm then it has to have the file name and hash that appear in bootstrap.scm <civodul>so you won't be able to just drop /usr/bin/guile in there <civodul>you'd need to patch (gnu packages bootstrap) for the tests <civodul>cbaines, nckx: ouch, d'you have a backtrace? <civodul>it's pure Scheme so a segfault is surprising <cbaines>nckx, is the person for that problem <rekado>civodul: it’s guile-xapian that triggers a segfault <cbaines>In other news, I think the guile3.0-gnutls build is time dependent, as I think one of the certificates used in the tests has expired *rekado restarted goggles manually, don’t judge <cbaines>I think guix build --no-grafts --check guile3.0-gnutls fails repeatedly for me <cbaines>although I think it's the gnutls package that Guix is actually deciding to build, which gails <nckx>Thanks to whoever fixed the goggles. *nckx goes eat more pizza. <civodul>cbaines: it passes for me! /gnu/store/0f6agk6xk8rcz99907d39nd1vzmc4abq-gnutls-3.6.14 <cbaines>I built /gnu/store/vhphki5sg9xkdhh2pbc8gi6vhpfzryf0-gnutls-3.6.12.drv <civodul>/gnu/store/91qxmwz9wm9w6jwxqmkalrlfxnkd3c0c-gnutls-3.6.14.drv <civodul>that's the replacement (it's public) <cbaines>ah, so I'm building an older gnutls package for some reason... <civodul>probably you're building (@ (gnu packages tls) gnutls) <cbaines>Ok, so I didn't spot that guile3.0-gnutls is deprecated, and just an alias for the unreplaced gnutls <cbaines>I guess that's somewhat still relevant, since you need to build with the older version, even if you're using grafts? <civodul>i see it now: FAIL: status-request-revoked <civodul>i think there's little we can do at this stage <civodul>but maybe we can think of how to address such issues in the future <cbaines>This is where it would be good to methodically build everything on systems with the time set to 2030, just to see if it fails... <civodul>that or use the clock namespace and have the unpack phase change the date to that of the source code or something <efraim>cbaines: icedtea@2 fails in 2115 IIRC <efraim>actually I think it was icedtea@1, one of the dependencies complained about the time being off by more than 10 years <apteryx>is there any reason why we have multiple ovmf packages per architecture instead of only one? <apteryx>the 'ovmf' one only supports x86_64, and there is a ovmf-aarch64 and ovmf-arm <apteryx>civodul: It's the same as you shared in the issue <apteryx>I'm retrying a non-grafted image (I added the patch to glib directly and rebuilt lots of stuff) <MSavoritias[m]2>I have been trying to reconfigure my system with sddm and sway but everytime i try to reconfigure it comes up with a backtrace <apteryx>even without grafts it didn't work, hm. <apteryx>nothing; I install emacs-no-x in the disk-image I build, then I search from the dash and it hasn't appeared <apteryx>strace output is also silent at the time the profile link gets changed <mbakke>since not-so-recently I found that offloading does not start new jobs until the normalized load is at ~0.6, which seems a bit odd. <mbakke>previously I could "fool" the offloading script by adding more max-jobs on a node to force jobs to start, but now Guix tries to outsmart me :-) <mbakke>it's a bit boring to wait for the server load to go down to ~60%, just so I can run a tiny 1-minute job. <mbakke>but given the recent offloading work by cbaines and mothacehe, I won't bother filing a bug report :P <nckx>apteryx: Didn't you change that same code not-so-recently? <apteryx>info '(guix) Daemon Offloading Setup' -> search for overload-threshold <apteryx>or just i build-machine RET in 'info guix' <mbakke>apteryx: oh I've completely missed that, thanks! :-) <apteryx>you can set it to #f if you'd like to not care about load <apteryx>civodul: any idea why guix publish is much slower than scp ? <apteryx>1.4 MiB vs 5.9 MiB (the later is my maximum download bandwith). <civodul>without --cache it's necessarily slower because it serializes and compresses stuff on the fly <civodul>not necessarily because it all happens in a pipeline: read from disk, serialize, compress, send <apteryx>the switches 'are -u guix-publish -p 80 -C gzip:3 --nar-path=nar --listen=0.0.0.0' <civodul>so if the disk and connections are fast, it should max the CPU <apteryx>everything is super fast on the guix-publish host <apteryx>IO is slow on the receiver, but it can sustain more than 1.4 MiB/s at least (scp does 5.9 MiB/s) <civodul>we'd have to strace publish to see, then <civodul>i see we don't change SO_SNDBUF in the no-cache case (application/x-nix-archive) <civodul>just like 5e3d169945935b53325e6b738a307ba286751259, a few lines above <civodul>(using 128KiB buffers instead of the default size, which must be 16K or something) <apteryx>bump guix, guix deploy, then 'herd restart guix-daemon' should install the patch, right? <civodul>you can run it with: sudo -E ./pre-inst-env guix publish -u guix-publish ... <civodul>quicker than upgrading the 'guix' package and all :-) <apteryx>we should perhaps document --sysconfdir=/etc when configuring Guix <apteryx>otherwise authorized keys are looked somewhere else *mbakke will try the SELinux fix from #44549 tomorrow, I think we should push it to 1.2.0 if it's good <mbakke>db48x: oh, hi! fancy seeing you here. :-) <db48x>weird coincidence; I've been busy all day and just happened to look at this channel <mbakke>db48x: out of curiosity, which distro did you try it on? <lfam>Do you know roughly how much disk space is required while building ceph? <mbakke>db48x: OK. I'll test on RHEL8 and let you know how it goes. :-) <lfam>Currently it's using about 8.1 GB and is "93%" done building <mbakke>lfam: haven't looked at that in a while, but I'm guessing in the 10GiB range <lfam>I increased my tmpfs to 10 GB after it failed with 6 GB. Hopefully it fits! <lfam>It ran out of space at "[100%] Built target ceph-monstore-tool" <civodul>apteryx: what's the throughput like? :-) <apteryx>civodul: I lost my reproducer (a large partition.img), as it completed once :-D <apteryx>guix gc -D wants to optimize and takes too long <apteryx>(that guix gc -D wants to do some lengthy optimization is an annoyance when testing -- we should disable that or make it optional (off by default)) <mbakke>perhaps we should have a property to run certain derivations with a different TMPDIR... <lfam>Afterwards I learned that one can remount a tmpfs with a new size online <mbakke>(looking at you, ungoogled-chromium) <lfam>Oh, this is where I want to build things. I'm just not used to building packages that need this much space. I have the RAM for it, I think <lfam>It would be a nice command-line option, though <lfam>Now that I know I can resize the tmpfs online, it should be smooth sailing <mbakke>lfam: in that case I'd just set it statically to 50% or so of the available RAM, it won't use anything unless you actually fill the directory <mbakke>I used to use a tmpfs as TMPDIR too, up until I started working on ungoogled-chromium, which currently sits in the 40GiB range :P <db48x>I've had good luck using an optane nvme ssd as tmp, and as swap <civodul>where xyz is the basename of a large enough nar <apteryx>it seems less steady, but perhaps that's just the output of wget <mbakke>ooh, looks like Hartmut took on the crate importer work, awesome :-) <apteryx>civodul: it now maxes at 5.9 at least, but usually averages around 4.7 or 5 it seems. <lfam>That is really great mbakke <lfam>I regret stepping away from it but I simply ran out of energy