IRC channel logs


back to list of logs

<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
<lfam>Btw atomsk298: There is already a Guix package for luakit:
<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?
<raingloom>checked the hash too, it matches.
<iyzsong-w>what program output that 'bash' does not exist? the console login or guix?
<raingloom>iyzsong-w: login
<iyzsong-w>um, then how you check it, if you can't login..
<raingloom>iyzsong-w: recovery ISO.
<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
<raingloom>the rescue ISO is Ubuntu.
<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
<roptat>anyway, need to go, good luck!
<raingloom>roptat: it was, but it was working perfectly file while i was using it. i even rebooted it a few times.
<raingloom>iyzsong-w: i mounted it and it can't be run
<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>this is the only system generations i have
<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>all had the default 1.1.0-checksum version
<raingloom>or 1.2.0, whichever is the current one.
<lfam>You checked what?
<raingloom>the telltale sign was that yggdrasil disappeared.
<lfam>Or, what command did you run?
<raingloom>guix describe
<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>like, today new. few hours old.
<raingloom>no, installed on top of Ubuntu from the install script.
<lfam>Ah, `guix system init`?
<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>well, i have the rescue ISO
<raingloom>lfam: config.scm was based on this
<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
<raingloom>the user did not exist
<lfam>Okay, check the permissions anyways
<raingloom>700 for ~user
<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>iyzsong-w: at least once, yeah.
<raingloom>lfam: ok, but how does that explain sshd not being found?
<raingloom>nor bash.
<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 see
<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?
<iyzsong-w>sure, strace may help to find out why..
<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?
<raingloom>lfam: yep.
<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)
<iyzsong-w>need to find a cli paste service :)
<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
<raingloom>...doesn't seem like i can do much tho.
<iyzsong-w>okay, there is no previous system generations?
<lfam>I wonder if does anything to handle the bootloader when installing over a VPS. In my experience that doesn't "just work"
<iyzsong-w> should only install 'guix'
<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.
<raingloom>strace output:
<raingloom>i said it was very minimal.
<raingloom>ldd output:
<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>iyzsong-w: it's the exact same output.
<iyzsong-w>um, okay
<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/ 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
<markasoftware>Why are the Atom and VSCode editors not in the guix repos?
<raingloom>markasoftware: npm ecosystem is very difficult to package reproducibly. lots of dependency loops from what i heard.
<markasoftware>That sounds reasonable
<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)
<abcdw>s/latest/latest tag/
<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
<leoprikler>i.e. 2.4-20200721-git-hash
<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>leporikler: like that?
<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
<raghavgururajan>Hello Guix!
<raghavgururajan>Do anyone use OpenVPN Service?
<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>Hello Guix!
<janneke>hello civodul!
<mothacehe>hey civodul, hey janneke!
<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>civodul: sure, seems fine!
<mothacehe>Cuirass does not build iso on top of the 1.2.0 branch
<mothacehe>maybe I should fix it
<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...
<g_bor[m]>just the basics.
<civodul>g_bor[m]: that'd be great! we'll have one soonish
*mothacehe fire up sqlite
<civodul>then there's the GLib patch apteryx & i were fiddling with, but then there's this vm-image issue:
*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
<abcdw>leoprikler: Does this patch looks good?
<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>One package is easier to maintain ;)
<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>leoprikler: true) but emacs has established release cycle and it's clear when new release will appear. There is an issue about creating 2.5, which not treated in any way for more than half an year.
<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)
<vits-test>gpk: some doc and few examples
<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 but the package builds correctly on my machine.
<divoplade>I'm following
<zimoun>mothacehe: the log of java-snappy looks really weird. Is it not an IO issue?
<roptat>I tried to help with but the source archive isn't versionned, and it's sometimes updated in place
<roptat>what's our policy for that? I don't think there is any other way to get this archive
<zimoun>roptat: is that similar enough?
<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
<efraim>TIL qemu has a fuloong2e option
<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>that .drv doesn't exist on berlin
<civodul>did you do "-d --no-grafts" from version-1.2.0?
<civodul>well, or master
<zimoun>I am on version-1.2.0, I hope
<zimoun>yes, sbcl-zpb-ttf is missing. But everything is fine. I think it was a IO issue.
<civodul>roptat: re, we have a few unversioned tarballs
<civodul>you could ask the submitter whether there's a more reliable way to get it
<civodul>like a VCS repo
<civodul>and as a last resort, we can refer to the unversioned tarball
<zimoun>civodul: has something happened on Nov. 2dn on Berlin?
<civodul>can you be more specific? :-)
<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.
<divoplade>I have opened a bug :
<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 why the package is missing, then try to build it locally.
<civodul>and how do you reach "Nov 2nd"?
<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>i'm trying to test the GLib patch for
<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
<zimoun>roptat: cool!
<roptat>zimoun, oh and I should finish the ocaml update...
<zimoun>it is not pushed? In staging?
<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 :(
<roptat>we have guix... :)
<divoplade>The closest thing would be hall, but it lacks features and extensibility
<rekado>zimoun: there’s a problem with wip-r:
<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>and my bracketing fails
<leoprikler>(origin (inherit (package-source pkg)) (snippet ...))
<divoplade>Yay, it works!
<divoplade>That's a bit strange to me that the function package-source returns an origin
<divoplade>and not a source
<divoplade>Or maybe that's the same thing.
<divoplade>Whatever, it works.
<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>rekado: «Free for academic use. Non-academic users are requested to obtain a license agreement with KEGG.» Therefore I am confused for the license.
<efraim>first glance sounds non-free
<zimoun>efraim, yeah I agree. But how are defined academic and non-academic? I mean it is not legal terms, even if IANAL.
<civodul>definitely non-free
<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>apteryx: i posted an experiment report for the GLib thingie, and a video!
<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
<efraim>i'm not about to solve ghc :)
<civodul>oh, i'm disappointed ;-)
<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>I tried adding to the output of the general binutils but it fails with
<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, yay!
<jsoo>Well I would love to have cross-binutils-gold
<bavier[m]1>abcdw: yay! \o/
<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 is one of the big hurdles towards that
<jsoo>(A cross le.
<jsoo>Cross that is
<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>apteryx: awesome!
<civodul>vagrantc: we have tests relying on %bootstrap-gcc & co.?
<civodul>i think they are already under "if (network-reachable?)" or similar, no?
<vagrantc>civodul: debug-link
<vagrantc>derivations ...
<civodul>ah yes
<vagrantc>etc ... git grep %bootstrap tests/
<civodul>but they're skipped if those are unavailable
<civodul>so we should be fine
<roptat>maybe not in 1.1.0 though?
<civodul>i'm not keen on adding another env var because it's likely to bitrot
<vagrantc>maybe it fails to detect if it can skip
<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>i'm also still carrying a patch for apparently
<vagrantc>maybe my failures are not network related, then ...
<civodul>this bug is closed :-)
<civodul>are you looking at 1.1.0 or current-ish master?
<vagrantc>civodul: based on origin/version-1.2.0
<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>vagrantc: BTW i mentioned the Debian package at the bottom of
<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>i might have to end up reverting back to guile 2.2 ... there are issues with guile-gnutls with guile 3.0 preventing it from being available
<vagrantc>or maybe just debian's specific build of guile 3.0 ... hrm.
<civodul>uh, weird & scary issue
<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)
<civodul>GnuTLS is fine for us tho
<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
<buenouanq>how fix?
<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>i think tests/processes.scm
<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>maybe a custom device-tree
<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
<vits-test>bluekeys: str1ngs has one
<vits-test>* pinephone
<cbaines>vagrantc, I guess that failure might occur with the Guix package as well then
<vagrantc>could be ...
<apteryx>sneek later tell mothacehe disk-image supports only 4 GiB it seems, when using --image-size, otherwise I get:
<zimoun>efraim: thanks
<vagrantc>so far i've got 96 test failures, and 953 test passes ... all of the failures appear to be related to bootstrap binaries
<vagrantc>er, most of the failures...
<apteryx>oh, sneek is missing in action
<apteryx>actualy the --image-size always seem to break
<apteryx>for 'guix system disk-image'
<lfam>apteryx: Sneek was noticed missing yesterday: <>
*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.
<apteryx>gnome-commander is at 500 MiB
<nckx>apteryx: No dice, no source.
<leoprikler>apteryx: polari is relatively small (dependencies are mostly covered by gnome already)
<apteryx>leoprikler: thanks!
<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)
<abcdw>bye guix!
<nckx>apteryx: Yeah, that can be confusing until you realise what's happening.
<nckx>Esp. when writing system tests &c.
<nckx>Who here uses Lyx?
<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.
<cbaines>vagrantc: ^
<PotentialUser>Is the IRC logs site down or is the link wrong?
<apteryx>leoprikler: emacs-no-x has a .desktop file and weights 263 MiB :-)
<leoprikler>ah, that's the better option then
<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>oh, okay
<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...
<cbaines>It's unclear why
<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.
<apteryx>(it still didn't work)
<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
<civodul>cbaines: i haven't encountered guile+libgc@8 problems, but Debian's guile-gnutls has:
<rekado>civodul: it’s guile-xapian that triggers a segfault
<civodul>oh right, not quite pure Scheme
<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
<civodul>i think it uses faketime no?
*rekado restarted goggles manually, don’t judge
*rekado disappears again
<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
<civodul>yes, guile3.0-gnutls is deprecated
*civodul is running it
<nckx>Thanks to whoever fixed the goggles.
*nckx were eatin' pizza.
*nckx goes eat more pizza.
<civodul>enjoy, nckx!
<civodul>cbaines: it passes for me! /gnu/store/0f6agk6xk8rcz99907d39nd1vzmc4abq-gnutls-3.6.14
<cbaines>hmm, what derivation did you build?
<cbaines>I built /gnu/store/vhphki5sg9xkdhh2pbc8gi6vhpfzryf0-gnutls-3.6.12.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)
<civodul>testing now
<civodul>yes, that's the one
<cbaines>Ok, so I didn't spot that guile3.0-gnutls is deprecated, and just an alias for the unreplaced gnutls
<cbaines>which happens to fail to build
<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>can you file a bug on bug-guix?
<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
<civodul>actually that may not help:
<efraim>cbaines: icedtea@2 fails in 2115 IIRC
<civodul>ah, that's good to know
<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?
*civodul doesn't know
<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
<MSavoritias[m]2>this one
<MSavoritias[m]2>this is the config.scm
<civodul>apteryx: weird, i'm just doing this:
<apteryx>even without grafts it didn't work, hm.
<civodul>what do you observe?
<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>mbakke: it's configurable
<mbakke>apteryx: oh, how?
<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).
<mbakke>apteryx: compression maybe?
<apteryx>cpu is nearly idling
<civodul>apteryx: with or without --cache?
<civodul>without --cache it's necessarily slower because it serializes and compresses stuff on the fly
<apteryx>but shouldn't that max the CPU?
<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='
<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>that could be the reason
<apteryx>hmm I have 1.5 MiB of strace log
<civodul>oh yes, that was it!
<apteryx>civodul: what does that do?
<civodul>just like 5e3d169945935b53325e6b738a307ba286751259, a few lines above
<civodul>it's a 10x difference on localhost
<civodul>(using 128KiB buffers instead of the default size, which must be 16K or something)
<apteryx>I'll be a happy tester
<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
<apteryx>OK, got it running! now the test
*mbakke will try the SELinux fix from #44549 tomorrow, I think we should push it to 1.2.0 if it's good
<civodul>mbakke: yup, let us know!
<db48x>mbakke: thank you :)
<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>Hi mbakke
<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>I wasn't expecting this
<lfam>Oh well!
<db48x>mbakke: excellent
<lfam>It ran out of space at "[100%] Built target ceph-monstore-tool"
<civodul>that was too much
<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>so I'm rebuilding a similar variant
<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>lfam: ouch :/
<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
<lfam>That's good to know
<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>apteryx: you can just run "wget -O /dev/null http://localhost:8080/nar/xyz"
<civodul>where xyz is the basename of a large enough nar
<civodul>s/nar/store item/
<apteryx>good idea
<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.
<apteryx>that's a good improvement already!
<apteryx>thank you!
<lfam>That is really great mbakke
<lfam>I regret stepping away from it but I simply ran out of energy