<fnstudio>does anybody know why some derivations are still being built when upgrading my packages, even if i have a substitute server configured? (https://ci.guix.gnu.org) <fnstudio>i imagine it simply happens they're not yet been built on the server? <nckx>That's possible. Another possibility is that they are somehow unique to your configuration. Which derivations? <fnstudio>nckx: icedove, pcmanfm, diffoscope - but i suppose you want to know the exact hash? <fnstudio>nckx: i've tried pulling again, in case that can help? <nckx>fnstudio: What does ‘guix weather icedove pcmanfm ...’ say? <fnstudio>`guix upgrade --dry-run` still says there's these 3 derivations that are going to be built <fnstudio>`33.3% substitutes available (1 out of 3)` <nckx>Oh, that's right, it doesn't tell you which one. <nckx>Here it's diffoscope, but my Guix is a few days old. <fnstudio>building icedove totally kills my machine :) that's why i'm so keen not to build it :) <fnstudio>thanks for helping with this, it's been the excuse to learn a few more things <vagrantc>mbakke: apparently libgit2 is 1.0.x in experimental... <nckx>fnstudio: guix.tobias.gr has diffoscope if the diffing's urgent (...probably not), unfortunately no icedove yet. <fnstudio>nckx: amazing, thanks! (and i'm very happy i understood the underlying logic) <technomancy>when I boot a guix USB drive on my old thinkpads, I just get a black screen with the word "GRUB" in the top-right corner. pressing keys makes it just beep. it's very difficult to search for this problem; can anyone recommend search terms that would be illuminating? "grub stuck boot" gives no relevant results. <nckx>fnstudio: It's also building IceDove at the moment so it *might* beat berlin. <nckx>technomancy: I don't think I can help but which model, and BIOS/UEFI/LibreBoot/...? <jackhill>technomancy: I have even less of an idea than nckx, but nice to see you here! <technomancy>nckx: it's consistent both on my X300 and X200s which use stock bios <technomancy>jackhill: hi; do I know you from #emacs or somewhere else? <jackhill>technomancy: you probably don't know me, but I've seen you around other places online. Yes #emacs, but also #fennel *nckx really gunning for the Great Advice award tonight. <nckx>Looks like the last answer in #grub was 5h ago, since then it's been all questions. Might have to ask again at different times of day. <vagrantc>ok, "guix weather hello" shows 100% substitute availabiltiy <vagrantc>so i think there's a problem with /etc/guix/acl or something <vagrantc>i've done: cat ci.guix.gnu.org.pub | guix archive --authorize <vagrantc>and it seems to have created /etc/guix/acl appropriately... <nckx>If /etc/guix/acl contains the correct key(s) it should work. It's been made more ‘declarative’ on Guix System but the location & format & semantics are still exactly the same. <vagrantc>would not having nscd installed and configured somehow matter for guix-daemon? *vagrantc reviews the manual for information about installing on a foreign distro <nckx>Guix probably won't like that Debian lie. *nckx needs to 😴, good night all. <vagrantc>but the daemon is running with the correct language *nckx actually likes C.utf8 as a concept no hate <vagrantc>it works great for Debian and Fedora for ages, but neither distro has convinced upstream glibc :( <vagrantc>and validating the web of trust ... is hard to do well ***dongcarl1 is now known as dongcarl
<vagrantc>well, i figured out why it wasn't accepting substitutes: 310496 /usr/bin/guix-daemon --build-users-group=_guixbuild --no-substitutes <mtm>weirdly the `git` I installed doesn't know about the `submodule` command. <mtm>heh, yeah `ungoogled-chromium` builds really get my fan running <vagrantc>i had leftover some files from an old guix install in /etc/systemd/system to disable substitutes, apparently <vagrantc>to test the issue with "guix pull" not finding origin/keyring, maybe i need to rebuild guile-git with libgit2-dev 1.0.x and then rebuild guix with that to see if that fixes the issue... ***catonano_ is now known as catonano
***amiloradovsky1 is now known as amiloradovsky
***amiloradovsky1 is now known as amiloradovsky
<vagrantc>mbakke: you were spot on with your guess about libgit2! upgrading libgit2-dev and using libgit2-1.0 fixes it without even rebuilding guile-git or guix <vagrantc>so with that in mind, guix pull works correctly <nefix>hello! I'm getting the following error when I run docker build: `cgroups: cannot find cgroup mount destination: unknown`. Does anybody know what does this mean? <sss2>hi all, how to properly setup offload facility on foreign host os with guix installed ? <jid>Hi. With stable graphical installer the guided partition step fails and goes back to the locale selection screen. At this point in /var/log/messages it says: 'nvme nvme0: ctrl returned bogus length: 16 for NVME_NIDT_EUI64'. Is there a workaround for this? <civodul>it would be great if you could test a 1.2.0 pre-release ISO, which supposedly fixes this issue *civodul looks for a link *civodul runs "make release" to make a release candidate *janneke smiles unto civodul <iyzsong-w>can input to a package be a 'computed-file'? I'd like to package 'sx' (or xinit) and make '(xorg-configuration->file (xorg-configuration))' as a input. <zceejkr>Hello everyone. I am trying to install the Guix System on my laptop using the graphical installer, and when I get to the partitioning part, the installer restarts back to the beginning. Is this a known issue? What can I do to fix it? Cheers. <zceejkr>I found this same issue via googling on the guix mailing list, and the person said they resolved it like so (quoting): "I noticed that the installer detected my EFI partition as FAT16. After changing it to FAT32, the installer continued.". But I do not know how to check this, or change it. <mbakke>zceejkr: there will be a beta release of guix 1.2 in a few hours, if you're not in a hurry it would be great if you could try that :-) <zceejkr>mbakke: great to hear. Will wait, thanks for the heads up. <zceejkr>Still making my way trough the manual anyways :) <g_bor[m]>I've just set up a new debian vm to test the guix package. <roptat>civodul, I didn't see your message yesterday about no-break space. Can we do it programmatically? inserting @tie{} everywhere is annoying (unless there's another solution?) <pinoaffe>hi guix! is there a generic way to specify in a package definition that the source code for a package is encapsulated in a specific, additional directory? <pinoaffe>or would I need to manually add an extra phase to the build process <nckx>pinoaffe: Indeed, a chdir phase is as generic as it gets. <dannym>pinoaffe: It's necessary to do a chdir in an extra phase. <civodul>roptat: we can search/replace for ex. " :" with " :" (where is NO-BREAK SPACE) <civodul>we should double-check but i think Texinfo handles NO-BREAK SPACE fine in PDF, HTML, and Info <roptat>I'd rather use @tie{}, because it's visible <civodul>editors usually display in a visible way, too <civodul>having @tie{} everywhere sounds tedious, no? *civodul starts "make release" for the 3rd time, this time with the correct offloading setup (hopefully) <bdju>would love it if someone updated the package :) <sneek>vagrantc?, pretty sure was seen in #guix 9 hours ago, saying: so with that in mind, guix pull works correctly. <g_bor[m]>sneek: later tell vargantc : I tried to do an install, from a freshly installed stable, and had to add unstable and experimental to sources.list, then apt upgrade. <g_bor[m]>sneek: later tell vagrantc : then something lige setup of amd64-libnis or similar fialed. <g_bor[m]>sneek: later tell vagrantc:Then the daemon complains that group _guixbuild does not exists <apteryx>civodul: When fixing broken things I think we should put them on the version-1.2.0; we can merge version-1.2.0 periodically back into master. This will make things easier to track and prevent forgetting cherry-picking fixes to version-1.2.0. WDYT? <civodul>apteryx: sure; i have a local tag for RC so just don't push right now please <civodul>but yeah, that sounds like a good strategy <civodul>as long as it's mostly about leaf packages though <civodul>otherwise we could end up having to wait for CI to catch up again <apteryx>civodul: hmm I just pushed 4e01bc440a which fixed the build for python-pysam on version-1.2.0, before I could see your message about a local tag. Well, the RC won't include that one. No big deal. <civodul>yeah the problem is more that the tag will point to something not on the branch <civodul>but maybe i can just have a tiny branch just for that RC, merged back into version-1.2.0 <apteryx>isn't the tag pointing to a commit? We're not rewriting history, so that commit should still exist even there are newer commits on top, no? <civodul>i think it's almost done building the VM image now <civodul>i'll push all the tarballs/images to alpha.gnu.org <vagrantc>oh, this sounds promising... what did i miss? :) <sneek>Welcome back vagrantc, you have 2 messages! <sneek>vagrantc, g_bor[m] says: : then something lige setup of amd64-libnis or similar fialed. <sneek>vagrantc, g_bor[m] says: the daemon complains that group _guixbuild does not exists <vagrantc>g_bor[m]: i think you need to reboot to get the groups/users set up ... it uses sysusers.d <civodul>hey vagrantc! not much, i've had "make release" running for most of the day, which should give us an RC soonish :-) <vagrantc>the git snapshot i have for the debian package feels a bit dirty <vagrantc>i mean, dirt is good and all, but for gardens, not software so much <civodul>my garden has dirt and worms, even bugs <vagrantc>g_bor[m]: i also find you want libgit2-dev from experimental installed as well; it fixes issues with "guix pull" <vagrantc>g_bor[m]: i think i might just need a postinst script to call systemd-sysusers to get the groups and users set up automatically *jsoo still looking for places to start on GHC_PACKAGE_PATH <apteryx>I'd like to try my hand at RC2 when the time is right, to make sure I'm not missing bits from the process <jsoo>the ghc package db stopped working after the haskell-build-system refactor <apteryx>is there a way to tell geiser to send the last sexp to the REPL and evaluate there? In a way that it creates a $N reference to allow using it later <apteryx>right now it prints the result to the mini-buffer, but I cannot refer to it, unless I'm missing something. <jsoo>I'm up to fix it but I'm sadly not as good with the ghc-pkg interface as would be required <jsoo>sneek: later tell rekado_: I want to fix the package db (ghc can't find packages when used after installing libraries anymore). Do you know where I should start? How did cabal register change in haskell-build-system? <jsoo>i have a debbugs question: who can close a bug? there are some open issues in debbugs that have been fixed i'd like to close <jsoo>also, how does one close a bug? <jsoo>vits-test: that seems hard haha <vagrantc>jsoo: follow-up with an email to NNN-done@debbugs.gnu.org <mbakke>db48x: I suppose labeling /gnu/store/.*guile as guix_daemon_exec_t could work around the second case discussed in the SELinux bug? <db48x>mbakke: only guix-daemon should need to be labeled guix_daemon_exec_t <vagrantc>oh, i wonder if some of the test suite failures were because of the old libgit2 version... <db48x>mbakke: was that AVC generated in permissive mode? do you know if it stops guix-daemon from working? <jsoo>mbakke: thanks for fixing freecad :) I was just going to start working on it <mbakke>jsoo: when did I fix freecad? :-) <mbakke>db48x: I used enfording mode after the reboot, and guix-daemon failed to start without the mentioned tweaks <jackhill>jsoo, dustyweb: I wonder if what GHC does with the package db is simmilar at all to Racket's raco's global state. With the obvious follow on that if they if there is a common solution :) <mbakke>jsoo: perhaps you can take some inspiration from the 'ganeti' package wrt GHC_PACKAGE_PATH <vagrantc>does guix-daemon need guix to function, or does it potentially make sense independently? <mbakke>db48x: so you are not able to reproduce it? <mbakke>db48x: readlink -f /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon reports /gnu/store/wvn92qff4pg4ipflg6169zdnmw8i6jkl-guix-daemon <vagrantc>is there any way to get "guix archive --authorize" output to direct to somewhere other than /etc/guix/acl ? does it do anything other than modify that file? <vagrantc>it would be nice if you could instead just drop files in /etc/guix/acl.d instead of having to run "guix archive --authorize" <g_bor[m]>vagrantc: it seems to work fine after reboot <vagrantc>as you might guess from my question, i'm pondering how to get substitutes working out of the box as well :) <janneke>vagrantc: it only modifies that file <janneke>note that since recently, on Guix System /etc/guix/acl is a link to the store <vagrantc>i mean, i guess you could symlink it wherever you want <vagrantc>how stable is the format of /etc/guix/acl ? can i just dump a header and cat ci.guix.gnu.org.pub in the middle and add a tail on the end? <vagrantc>when you add keys, does it reformat the indentation? ... etc. <vagrantc>i'd like substitutes to work out of the box in the debian package, which probably means making it a file with a reasonable default <db48x>vagrantc: can't you run "guix archive --authorize" in one of the package's install scripts? <nckx>I'm sure it rewrites the entire file when you use guix archive --authorise, but setting it to a default should be safe for now. Safer would be to script guix to write it. <vagrantc>db48x: i guess i can do it from the first install only, and only if it doesn't exist, and remove it on purge ... <db48x>or leave it up to the user to decide which package sources to trust <divoplade>Hello, I have installed help2man but when I run it on my program with a non-C locale I get: help2man: no locale support (Locale::gettext required) <divoplade>Try it yourself: help2man help2man -L fr_FR.UTF-8 <divoplade>That's not a great example since the help of help2man is not internationalized <divoplade>You can try with help2man guix -L fr_FR.UTF-8 <vagrantc>db48x: i'd rather have it work out of the box with the defaults, and if someone wants something different, they configure it <vagrantc>db48x: otherwise, guix will just start start rebuilding the world for the simplest of operations <vagrantc>the binary install script enables the substitute servers by default, yes? <mbakke>zceejkr: hopefully the new release works better: ^ <db48x>vagrantc: possibly; I don't actually know <vagrantc>basically, the debian package should basically get you to the same place as the install script... <vagrantc>civodul: oh, found the tag... too impatient :) <jsoo>mbakke: I think a few months ago freecad got fixed. <jsoo>The ghc package path used to be set by haskell-build-system. I think... <civodul>vagrantc: yeah i had forgotten to push the tag, again <civodul>i guess little has changed since the revision you picked! <vagrantc>civodul: the .version that landed in the tarball is 0.12.0.3485-e9491 ... though the .tarball-version matches the tarball :) <vagrantc>the .guix-authorizations file isn't in the tarball ... is that needed? <nckx>vagrantc: Why is it messy? <vagrantc>nckx: debian has complicated rules around files in /etc <db48x>that's fair; guix has complicated rules too <vagrantc>guix focusing on functional management is a huge plus :) <db48x>vagrantc: the code that adds the key to the file is quite simple <db48x>guix/scripts/archive.scm:319 <db48x>whatever simple way that you want to build the file is likely fine <zceejkr>mbakke: tried installing the 1.2rc. I still get an error on the same spot, but this time I see an error message instead of the installer restarting. So when I tried to partition the disk, I get an error that says: "Unhandeled ext2 fs-type". Can anyone recommend some next steps I could take to get around this? Cheers <zceejkr>The error message is actually quite long, and I can try to take a picture if needed, but I guess what I wrote above is the gist of it. <nckx>vagrantc: Fair'nough; my suggestion might've been based on a somewhat stereotypical view of stateful package managers ☺ <vagrantc>but maybe just running it if not present will be good enough <vagrantc>oh, i have to handle a sysadmin removing the file and not re-add it ... bah. <apteryx>question: should the ctypes.find_library of Python in Guix be patched to look into LIBRARY_PATH? Currently it only looks in LD_LIBRARY_PATH <vagrantc>i think i'll just create the file during package build, and then it can be managed by conffile handling. <nckx>vagrantc: Yeah, and it can't be completely empty because Guile expects a valid sexp. <apteryx>vagrantc: to the contrary, thank you for working on the Debian packaging of Guix! <nckx>(acl) is probably the shortest valid content. <vagrantc>if the sysadmin breaks something, that's not the package(r)s fault :) <nckx>I mean that you create an empty one as ‘signal’ not to replace it with the default, but that's probably moot, since a sysadmin could create an empty-list one. <vagrantc>does guix get all grumpy if the permissions of /etc/guix/acl are too permissive? <nckx>But it's the kind of question that doesn't bode well. <vagrantc>well, there's a big difference between read and write permission <vagrantc>i can see an argument that which substitute servers you trust is ... potentially private information <vagrantc>though that would mean that the users of the system wouldn't necessarily know what substitute servers they can use <vagrantc>arg. not much changed, but a fresh new test suite failure for me in 1.2.0rc1 :/ <nckx>vagrantc: The file is world-readable by default, so I assumed you meant write permission, which would be bad. I don't buy the (hypothetical) privacy argument. <vagrantc>nckx: guix archive --authorize makes it only readable by root <vagrantc>sure learning how to disable test suites :) <nckx>vagrantc: I'm on Guix System, where it's in the store (now). If privacy were an issue somebody would have probably complained already ☺ <nckx>vagrantc: Which test now? <vagrantc>tests/guix-system.sh and tests/build-utils.scm test-name: alist-cons-after, reference not found <nckx>I still wouldn't agree anyway. <nckx>That's a strange test to fail. <vagrantc>how does guix archive --authorize handle /etc/guix/acl being a symlink to the read-only store now? <vagrantc>fail gracefully, ungracefully, back it up and overwrite it? <nckx>vagrantc: How does alist-cons-after fail? Here it generates a suspicious-looking ‘failed to create alist-cons-after.log’. <nckx>vagrantc: Silently replace it with a regular file with the new key appended to the previous (store) contents. <nckx>Unless it working at all is a bug, it should at least warn. <vagrantc>nckx: i'm trying to figure out how to generate the file manually, but i'm getting some weird non-printable whitespace differences <nckx>I'm aware of trailing spaces (presumably) due to DISPLAY, but not non-printable ones... <nckx>i.e. each line not ending on ) will have a trailing space but that's it. <nckx>Are they not regular ones? <vagrantc>oh, maybe it's a trailing whitespace issue <vagrantc>nckx: it was trailing whitespace on my end! <vagrantc>ah, no, there's trailing whitespace in etc/substitutes/ci.guix.gnu.org.pub <nckx>In guix.git? There is here. <nckx>That's what DISPLAY does although I don't know why. <nckx>I'm afraid that ‘your end’ will have to emulate that even if you don't like it. <nckx>Although I'm not sure why. Another Debian rule? Guix doesn't care about the formatting. <nckx>tecosaur: About what? If you're referring to a previous discussion it's not in my log. <vagrantc>nckx: i'd rather produce identical output to what "guix archive --authorize" would produce <nckx>Sorry if I sound super distracted -- I am. <vagrantc>what would be even easier is running "guix archive --authorize --export > somefile" but ... --authorize seems like some arbitrary feature tacked on to archive <nckx>I laughed at your last error: guix system: error: invalid character `~' in name `shepherd-file-system--build-guix-1WL3Dl-guix-1.2.0~rc1-test-tmp-store.scm-builder' <vagrantc>my eyes missed that, nice to have extras :) <nckx>Even a fancy rc tag can blow up something elsewhere. Heh. <nckx>Nice that a test caught it. <tecosaur>If anyone has any suggestions, please ping me 🙂 <vagrantc>that might be due to my debian patch ... hrm. <vagrantc>i wonder where it's getting the ~rc version from <vagrantc>ah, it's my debian/bin/get-upstream-version hack <vagrantc>no, that just uses .tarball-version with no ~ ***amiloradovsky1 is now known as amiloradovsky
<__red__>Greetings - I'm attempting to boot the hurd .qcow image and it appears to be stuck at the: "start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec" line <sneek>__red__, you have 1 message! <sneek>__red__, jsoo says: I want to fix the package db (ghc can't find packages when used after installing libraries anymore). Do you know where I should start? How did cabal register change in haskell-build-system? <__red__>I am entirely the wrong person to ask sneek / jsoo <chipb>__red__: hm. I'd bet missing driver for the virtualized hardware you've instantiated. might want to look closely at how docs suggest launching it and compare to your qemu invocation. <__red__>I launched it using the "easy" button <__red__>I got it from the download page, link to the CI pipeline only <__red__>the guix docs only have a reference to the hurd as "coming soon" <apteryx>what does 'dlopen' uses to find a library? man dlopen suggest I can set LD_LIBRARY_PATH, but that still doesn't work, at least with Python's ctypes.CDLL <apteryx>I know I can patch the lib by its absolute path, but I'm curious to know why it doesn't work in the first place anyway. <nckx>apteryx: That's basically it, plus hard-coded /lib stuff useless (and perhaps disabled) on Guix, unless the programme uses SOMETHING_RPATH. <nckx>LD_LIBRARY_PATH should really work. <civodul>vagrantc: uh what's the deal with .tarball-version <civodul>as for .guix-authorizations, it's not strictly needed but it's best to include it <maav>apteryx: LTDL_LIBRARY_PATH? <sneek>Welcome back maav, you have 4 messages! <sneek>maav, luis-felipe says: How about using "Vistazo" for "Overview"? <sneek>maav, luis-felipe says: In the Overview page, how about "Guix proporciona actualizaciones y reversiones transaccionales, gestión de paquetes sin privilegios, y más." <sneek>maav, luis-felipe says: Besides the "vídeo" problem, what I find peculiar is the use of feminine nouns and pronouns as neutrals. I'm courious about this choice. Is that really used in Europe? <sneek>maav, luis-felipe says: Also, in "configuración del sistema al completo", "al completo" is new to me, would "configuración entera/completa/total del sistema" work around there? <nckx>maav, apteryx: Wait, are you talking about dlopen or lt_dlopen? <nckx>LTDL_LIBRARY_PATH should not affect the former. <maav>¡hola civodul! sorry for the noise about core-updates ;-) <maav>it's compiling gcc-7.5, hehe <civodul>maav: i haven't heard any noise (yet) :-) <civodul>i did feel frustrated reading about Emacs-Guix, but that's another story <maav>civodul: nah, just an idea for the gcc problems (the patch attached needs a change but i wanted to finish the test first) and a change for libtool, more tested, hehehe <vagrantc>civodul: .tarball-version looked fine, .version picked a very curious version <maav>and yes, emacs-guix thing is sad, but you said it, it's an opportunity :) <apteryx>the "out" store file name is already known before the build system kicks in, correct? i.e., I can refer to a file in (assoc-ref outputs "out") in an phase ordered after 'unpack, correct? <nckx>All output names are already embedded in the .drv. <vagrantc>aha. the build-path included the version with a ~ <rndd>hi everyone, i'm getting "collect2: error: ld returned 1 exit status" when trying to use gcc <sneek>rndd, vits-test says: А нафига кириллица, да ещё в шутере? Is it work in Emacs, btw? <sneek>rndd, vits-test says: * Hello. <sneek>rndd, vits-test says: Some apps may require the person to switch a layout _before_ start the app. I'd that in gtypist. <rndd>vits-test: oh, i will check it <nckx>rndd: The reason will be in one of the (possibly voluminous) previous lines. <rndd>nckx: "ld: cannot find crti.o: No such file or directory" <rndd>but i wrote simple hello world <rndd>vits-test: nope, it's same <nckx>rndd: Are you using gcc-toolchain? Can you share your file + command used in a paste? <vagrantc>so, two tests fail if the build directory contains a ~ somewhere in the path <nckx>rndd: How did you install GCC? If I echo that C into test2.c and run ‘guix environment --pure --ad-hoc gcc-toolchain -- gcc test2.c && ./a.out’, it just works. That is equivalent to running ‘guix install gcc-toolchain’. <rndd>nckx: i installed gcc with ‘guix install gcc-toolchain’. <nckx>Is this on a Guix System? Does the above pure environment work for you? <nckx>It works outside of that environment with a previously guix-installed gcc-toolchain, but I'm on Guix System. If you're not, perhaps Guix's gcc is trying to link against non-Guix libraries and that may well cause fiery death. *nckx AFK a while for dinner. <rndd>nckx: yes, it is on guix system. yes, above command works <nckx>Hmkay. What does ‘echo $LIBRARY_PATH’ say? Try the classic ‘GUIX_PROFILE="$HOME/.guix-profile"; . "$GUIX_PROFILE/etc/profile"’ just in case. <pkill9>i wonder if the parts of gtk+ and hwatever that are used to generate guix profiles could be split out into their own package <pkill9>so it wouldn't take much time to build/download <nckx>rndd: \o/ Now I'm certain that your previous ‘guix install gcc-toolchain’ was in the same terminal, and that it printed the 2 GUIX_PROFILE lines above 😉 <nckx>That's not to berate you (I ‘forget’ to read warnings all the time) but to point out that this one can be important. <nckx>Well, ‘same terminal’ isn't quite right. If you'd opened a new terminal and run ‘gcc’ it would have worked. <rndd>nckx: well, i definately should read warnings next time <nckx>What happens is ‘guix install gcc-toolchain’ updates your bash profile to set some important variables for GCC, but Guix can't change the environment of processes that have already been started. It can only ask you to copy & paste a command. <nckx>So yeh, not ideal, but good enough. *nckx → spag bol & beer now.