IRC channel logs


back to list of logs

<pkill9_>does clementine fail for anyone else?
<kkebreau>pkill9_: I'd check but my computer is busy building other things right now
<ProfessorDey>Is there any way to modify the kernel config for linux-libre? Because all I'm seeing is a completely enclosed system that I can't get into because the make-linux-libre package isn't defined publicly and the linux-libre package doesn't accept any arguments. is there any way I can modify that? add a key or whatever? literally just need to add a couple of config changes, which could literally just be inserted into
<ProfessorDey>%extra-linux-options if I could access/modify that definition
<kkebreau>ProfessorDey: I remember doing this a while back, but I lost the config file. Let me see if I can find where I learned it...
<ProfessorDey>kkebreau: thanks
<nckx>pkill9_: No. @ build-succeeded /gnu/store/v47xqj675iaizm0d750bbh8p6wyxy68a-clementine-1.3.1-2.4619a4c.drv - /gnu/store/z6lyq3cvjvyalmi9fqqc21xd57q133wy-clementine-1.3.1-2.4619a4c
<pkill9_>nckx: i mean running clementine
<pkill9_>for a one liner, `guix environment --ad-hoc clementine -- clementine`
<pkill9_>it fails with an error about not being able to access a database
<nckx>Hehe. The mindset of debugging builds all evening.
<pkill9_>heh :)
<nckx>Let me download it & check.
<nckx>Yep: db error: QSqlError("1", "Unable to fetch row", "unknown tokenizer: unicode")
<nckx>Are we building sqlite3 without FTS3?
<nckx>;; This is used by Clementine. | (define-public sqlite-with-fts3
<kkebreau>ProfessorDey: Good news is I've found it, bad news is it involves proprietary software.
<kkebreau>But I should be able to "clean" it, so to speak.
<nckx>pkill9_: So your mission, if you choose to accept it, is to figure out why even building with sqlite-with-fts3 still results in ‘Couldn't register FTS3 tokenizer : QSqlError("1", "Unable to fetch row", "fts3tokenize disabled")’
<ProfessorDey>kkebreau: that's fine, I'm not a guixian that cares about free everything. My hardware really isn't usable with guixSD otherwise
<kkebreau>ProfessorDey: Well this is a free software channel, so I can show you the principles of customization, I don't want to advocate for proprietary software or its use. But what you do on your machine is not my business.
<ProfessorDey>kkebreau: Fair enough I guess.
<kkebreau>ProfessorDey: Okay, so here's an example config:
<ProfessorDey>fair enough, that's pretty much what I was already using, so thanks for the clarification.
<kkebreau>Basically, in your system config.scm file, use define your kernel mirrors of choice, where your custom .config file is on the disk, and make a custom kernel package that uses those mirrors and that custom .config file.
<pkill9_>nckx: looking in the configure file of the source of sqlite, there's nothing with 'FTS3' or 'fts3' in it, only fts5
<kkebreau>ProfessorDey: FYI, the system configuration snippet I posted was based on one from our own mbakke (Marius Bakke on the Guix mailing lists).
<pkill9_>under '2. Compiling and Enabling FTS3 and FTS4' at it explains how to enable FTS3 support, looks like the package definition is doing it right, so *shrug*
<pkill9_>actually there is one thing to try
<nckx><pkill9_> looking in the configure file of the source of sqlite, there's nothing with 'FTS3' or 'fts3' in it, only fts5
<ProfessorDey>kkebreau: fair enough, was mainly just hoping I could just put my config changes in a scm definition without having to make sure I have an external config around
<pkill9_>setting the configure flags to CPPFLAGS="-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS" instead of adding each '-D<...>' as a compile flag
<nckx>So do you mean our -with-fts3 package is passing flags that are just ignored?
<pkill9_>yeah it could be that nckx
<nckx>Weird. But at least that would lead to a straightforward fix.
<pkill9_>i think they need to be put in CPPFLAGS, i'm not familiar with all the variables and stuff for cmake though
<pkill9_>but it's simple enough that it's worth a try
<nckx>I think -DFOO is the ‘standard’ way, but I have no idea 1) if that's true 2) how much CMake enforces that if at all 3) Sqlite does some weird NIH shit. So it's worth a shot.
<kkebreau>ProfessorDey: I agree that would be very convenient. Maybe there's a way that requires being extra clever.
<kkebreau>ProfessorDey: I may have a solution...
<ProfessorDey>kkebreau: not really very clever, literally just have to allow you to pass in a config or list of options as a key as an optional argument for linux-libre
<kkebreau>ProfessorDey: Yes, it seems it may be that easy.
<ProfessorDey>but of course that would only be doable if someone submitted that as a patch that then got upstreamed to the guix source. So yay for potentially having to go through whatever hastle that is XP
<kkebreau>In the new paste, I've just copied the relevant parts from gnu/packages/linux.scm to the system config.scm.
<kkebreau>Also, it turns out that there is a mailing list thread on this, but I'd prefer to have a canonical method of doing this:
<ProfessorDey>yeah, that's basically the config I was trying to use, but my scm is for an install disk, so it also tries to pull linux-libre despite using a different kernel and then complains that the initrd can't find a kernel module that I told it not to look for, because it ignores my raw-initrd definition
<apteryx`>nckx: I got my full setup with udev rules for i2c + ratpoison shortcut to put ddcutil to good use, it's great!
<apteryx`>no more sore eyes in the middle of the night.
<apteryx`>manpages can be costly to generate still: 69319 entries processed in 111.1 s
<apteryx`>1.6 ms per manpage
<ProfessorDey>kkebreau: Literally all they'd need to do is redefine the linux-libre package like I've done here:
<kkebreau>Perhaps one of us could bring this up on the guix-devel mailing list.
<ProfessorDey>kkebreau:I wouldn't mind, I just assume that's a members only club, or at least, I'm not familiar with how one actually participates in such a mailing list. But I can easily write up a full patch for the current setup.
<kkebreau>It's definitely not members only. We invite anyone with concerns about Guix development to share them.
<ProfessorDey>fair enough
<kkebreau>Just introduce yourself and share your idea/patch. That's how I got started. :)
<ProfessorDey>fair enough. Ironic that I only originally started on this issue because my lead programmer asked me to move the server over to GuixSD for the best compatibility with developing with Idris on Guix -,_O_,-
<kkebreau>ProfessorDey: Interesting. This Idris?
<ProfessorDey>kkebreau: Yes indeed. Building a Single Page Application forum/message board on the LBRY Network/Protocol, it's called Liberum. We're using idris so we can have formally verified, high level functional programming language as the basis for what will ultimately be compiled down to browser friendly MinifiedJS
<pkill9_>nckx: I tried bilding clementine with this but the resulting binary still failed in the same way as without it, but i may have not written it correctly, here it is if you're interested
<kkebreau>ProfessorDey: Definitely seems interesting.
<ProfessorDey>It's definitely going to be a fun project. We're currently funded for the rest of the month, so we're getting a workable demo of the clientside done that handles fake data, so mainly writing DSLs for each interface
<apteryx`>ACTION tries fixing gnucash 3.0 test failures
<ProfessorDey>we have an irc, but it's on the server we're planning to wipe and install guixsd on so... yeah, bit awkward there, reason we also have a discord server XP
<ProfessorDey>kkebreau: Right, done the patch, which you can see here: And now I guess I just need to figure out how these mailing list things work XP
<ProfessorDey>I say patch, rather, that's the patched file, not an actual patch file as such, need to remember how to make that
<kkebreau>ProfessorDey: For the mailing list just email with your patch attached or in the message.
<ProfessorDey>Thanks, I'll work on doing that then
<apteryx`>which package provides libtoolize?
<apteryx`>libtool I guess :)
<kkebreau>As for the patch format, use Git to add and commit the change to your local Guix repository, and use "git format-patch" to get the patch in the right format. The commit message format is specific, too, but basing your commit message on the existing ones should be a good start.
<kkebreau>apteryx`: Yes, libtool.
<kkebreau>Just double checked.
<kkebreau>I did something weird to my setup so that the pre-inst-env script isn't working properly. :(
<kkebreau>I'll have to look at it after some sleep. Bye all.
<apteryx`>what's this strange error caused by?: error: possibly undefined macro: AC_DEFINE
<apteryx`>only happens in a guix builder, not when experimenting with my user profile
<apteryx`>it was pkg-config
<reepca>hmm, just installed guixsd on a new hard drive for my laptop and I'm getting complaints on using `guix package -m manifest` about "wrong number of arguments". Did the manifest format change since 0.14?
<reepca>said manifest was copied from ~/.guix-profile/manifest of my install on my other hard drive
<reepca>ah, it seems that it's not intended to be evaluated, only read... attempting to convert to a manifest object using profile-manifest in the directory it's in (because read-manifest isn't exported from (guix profiles)) and now it's complaining about store output paths being invalid. Which makes sense, I didn't copy the store over, because I didn't have a flash drive large enough to serve as an intermediate step...
<reepca>Is there a simple way to go from "profile manifest" to "more general description"?
<reepca>(I ended up just doing some manual transformations to the sexp that just grabbed the package name and output and concatenated them with a ":" in the middle, then stuck that entire list in a specifications->manifest form)
<reepca>(and by manual I mean "in the REPL, with map")
<Copenhagen_Bram>Hello guix!
<pkill9_>hi Copenhagen_Bram
<Copenhagen_Bram>Hmm. I'd like to package a thing called qtads:
<Copenhagen_Bram>ACTION starts with `guix download`
<Copenhagen_Bram>hey snape
<snape>hey Copenhagen_Bram!
<Copenhagen_Bram>I'm trying to create a package for qtads
<snape>and I guess you are stuck? :-)
<Copenhagen_Bram>hmm. I think I need something other than gnu-build-system. Something that compiles for qt4
<snape>Copenhagen_Bram: you may grep 'qt' or 'qt-4' in gnu/packages, there are several examples. Some of them use 'cmake-build-system'
<Copenhagen_Bram>snape: I mean I need to find a build system that runs qmake. I think I may have to use trivial-build-system
<snape>grep 'qmake' in gnu/packages :-)
<Copenhagen_Bram>(1) Please see the ‘(guix build gnu-build-system)’ modules for more
<Copenhagen_Bram>details about the build phases.
<snape>you'll see that people use 'gnu-build-system' and modify the 'configure' phase so that it invokes qmake
<Copenhagen_Bram>How do I do that?
<snape>(guix build gnu-build-system) is in guix/build/gnu-build-system.scm
<snape>that's how guile modules work
<snape>did you 'git clone' the Guix repository?
<snape>it's pretty important if you want to create packages in my opinion
<janneke>hi g_bor!
<Copenhagen_Bram>ACTION copies the guix repo from his backups to save internet
<Copenhagen_Bram>wait a minute, shouldn't there be a guix repo somewhere from every time it clones when I run guix pull?
<snape>good question
<janneke>with yet another cheat: injecting LD binary from the bootstrap binaries, i have now bootstrapped binutils-2.20.1a+gcc-2.95.3+glibc-2.2.5 => gcc-2.95.3
<janneke>apparently, there is a bug in bootstrapped LD that needs to be identified and fixed
<mbakke>Copenhagen_Bram: You can use `git clone --reference ~/.cache/guix/pull/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq` to save some bandwidth.
<snape>mbakke: nice ;-)
<janneke>wondering whether to work on building/packaging gcc-4.7 and friends first, and how many intermediate steps are needed
<mbakke>janneke: Woow, nice progress :-)
<janneke>thank me it felt a bit like "standing still" for about a week ;-) but i guess you're right
<g_bor>If I were you, I'd go for gcc-4.7 first, I guess.
<g_bor>Could you sort out the problem with M1 segfaulting?
<Copenhagen_Bram>How come dependencies aka inputs are written as so: ("package", package)?
<janneke>g_bor: OK
<janneke>yes, M1 and all our other tools segfaulting was due to a bug in our ELF headers
<janneke>that bug was harmless on linux < 4.17
<mbakke>Copenhagen_Bram: That's an association list, the first key is used as a name/identifier, the second is the package object.
<janneke>g_bor: our elf header would define identical text and data sections
<janneke>that's not allowed anymore
<mbakke>So you can refer to a particular input using '(assoc-ref inputs "package")' inside a build expression.
<dddddd>yay, IF! Thanks Copenhagen_Bram (:
<Copenhagen_Bram>dddddd: yw, maybe if I get good at this I'll package gargoyle
<Copenhagen_Bram>dddddd: if you didn't know already guix has fizmo and glulxe available for zmachines and gblorbs
<Copenhagen_Bram>but not tads
<dddddd>Thanks for the info. I really didn't searched for them, indeed. TADS is really great. </offtopic> Good luck with the packaging (sadly, I won't be of any help, I'm really new to guix)
<Copenhagen_Bram>thanks dddddd. I still feel kinda new to guix too.
<Copenhagen_Bram>How many days ago did you start using it?
<dddddd>I just tried one "foreign install" (if I recall the term right) some time ago, but never touched it again... so, a couple of days (: Copenhagen_Bram (BTW, there's #intfiction --low traffic--)
<Copenhagen_Bram>Thanks dddddd. What's a foreign install?
<g_bor>sneek: botsnack!
<g_bor>sneek later ask rekado_ what is the status of #29976 gnu: Add git-subtree?
<g_bor>sneek: later ask rekado_ what is the status of #29976 gnu: Add git-subtree?
<dddddd>Copenhagen_Bram, it's a way to install Guix on another (the foreign one) distro than GuixSD IIRC
<Copenhagen_Bram>Ah. you have to configure some new users and some environment variables.
<Copenhagen_Bram>I believe I successfully foreign installed it on my previous Parabola system
<Copenhagen_Bram>So what does this mean:
<Copenhagen_Bram>guix build: error: failed to load '/home/elonsatoshi/qtads.scm':
<Copenhagen_Bram>ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
<Copenhagen_Bram>In procedure scm_lreadr: /home/elonsatoshi/qtads.scm:23:72: illegal character in escape sequence: #\\)
<snape>Copenhagen_Bram: could you paste qtads.scm somewhere, and tell us what command you typed?
<g_bor>mbakke: It seems we have boost 1.66, I guess 28330 can be closed, as it patches 1.65. WDYT?
<Copenhagen_Bram>command was `guix build -f ~/qtads.scm`
<snape>Copenhagen_Bram: your inputs don't look good
<Copenhagen_Bram>snape: i know, but i don't think it's causing my error
<Copenhagen_Bram>once i fix this mysterious illegal character in my description, then I can move on to whatever error my lazy inputs will cause
<Copenhagen_Bram>unless they are somehow causing this error in a weird way
<g_bor>roptat: What is the status of #29697 small fixes for java-powermock?
<snape>Copenhagen_Bram: it's the description that causes the error
<snape>oh you said it already :)
<Copenhagen_Bram>hmm. I tried escaping the period
<brendyn>like \\"Zork\\"\\)\\.
<snape>it's complaining about it
<brendyn>shouldn't need to escape the ) either
<snape>"illegal character in escape sequence: #\\)", and then #\\.
<Copenhagen_Bram>ok unescaping the parenthesi fixed it
<brendyn>the quote is delimited by ", so ) doesn't need any escaping
<Copenhagen_Bram>ACTION fixes a quote typo
<Copenhagen_Bram>ok now we're into the input errors
<Copenhagen_Bram>/home/elonsatoshi/qtads.scm:18:3: error: invalid field specifier
<Copenhagen_Bram>not to mention i need to modify the build system to use qmake
<snape>one thing at a time :-)
<brendyn>Copenhagen_Bram: you need to wrap your inputs in `(...)
<snape>each input is a list whose first element is the key and the second element the corresponding variable
<snape>Copenhagen_Bram: you may want to read about quasiquoting, in the Guile manual
<dddddd>Copenhagen_Bram, do you know frobtads? It's easier to compile, so it would be a first step to have any working TADS interpreter. I never compiled qtads; frobtads it's straightforward.
<pkill9_>anyone know the flag to change the gtk modules output dir? i get CMake Error at subprojects/appmenu-gtk-module/src/cmake_install.cmake:55 (file):
<pkill9_> file cannot create directory:
<pkill9_> /gnu/store/v04ahw3s35swgss4s1a5bwrwwabmilcw-gtk+-3.22.29/lib/gtk-3.0/modules.
<pkill9_> Maybe need administrative privileges.
<pkill9_>nvm foudn it
<Copenhagen_Bram>Weird. I'm getting a `/home/elonsatoshi/qtads.scm:12:11: error: gnu-build-system: unbound variable` even though I added the module (guix build-system) as instructed by the manual. Why is that?
<snape>because it's (guix build-system gnu)
<roptat>g_bor: 59e0021cc79b577daaf0f23a9f0b93e166400261
<snape>Copenhagen_Bram: you should look at the Guix repository to see how other packages do
<snape>and copy ;)
<roptat>g_bor: it seems it was pushed 2 months before your comment
<Copenhagen_Bram>whelp i added all the modules from games.scm and got this:
<Copenhagen_Bram>guix build: error: #<unspecified>: not something we can build
<roptat>g_bor: it seems it was pushed 2 months before your comment
<roptat>g_bor: 59e0021cc79b577daaf0f23a9f0b93e166400261
<snape>Copenhagen_Bram: the input of guix build -f is a package
<snape>(define-public ...) returns something undefined
<snape>you just need to remove it
<mbakke>One test in git 2.18.0 fails because 'compgen' is unavailable. I wonder if it's worth the effort to use the "full" bash, or simply delete this one. Opinions?
<snape>mbakke: what are the drawbacks of using the full bash?
<mbakke>snape: It might end up in the final build, I'm not sure which bash (which "bash") (heh) will pick up.
<snape>I think (which "bash") picks up bash-minimal
<vgfr>Installing rust fails in the check phase of "rust-1.23" with the "out-of-stack" test. Is there a way to skip it?
<snape>but it's easy to verify
<snape>re (heh) -> :-)
<mbakke>g_bor: I closed it, thanks for the reminder.
<Copenhagen_Bram>Thanks snape! Now I've made my way to a backtrace error.
<Copenhagen_Bram>ok now i've made the inputs look like they are in another package, and I get the quasiquote error again.
<mbakke>snape`: Bah, bash does end up in the closure by simply adding it as an input. Now to figure out where.
<Copenhagen_Bram>oh snape ish gone
<g_bor>roptat: Thanks, I will close it.
<snape>back :-)
<snape>I've read
<mbakke>'patch-source-shebangs' seems to have picked up the wrong shell, among other problems.
<mbakke>I suppose I can write a post-install phase that patches the shebangs back to bash-minimal.
<mbakke>Actually, the best fix is probably to patch git to use @SHELL_PATH@ in shebangs rather than /bin/sh.
<vgfr>How can i patch the linker (interpreter) of a precompiled executable?
<pkill9_>vgfr: using patchelf
<mbakke>Woah, this is a funny store path: /gnu/store/2vzqr585zwyxmw50qgxqjhahxrbipf4x-bgl49yjagcpiny0g4dvws2xxbrlvfp26-git
<mbakke>(created by `guix build --with-source=/my/local/git git`)
<dddddd>Trying to boot the 0.14.0-x86_64 pre-built GuixSD VM using -enable-kvm on a (old-ish) 64 bits CPU (with 32 bits kernel) hangs after grub menu. I can see on the host:
<dddddd>warning: host doesn't support requested feature: CPUID.80000001H:EDX.syscall [bit 11]
<dddddd>warning: host doesn't support requested feature: CPUID.80000001H:EDX.lm [bit 29]
<dddddd>It boots fine (and slow, sure) without -enable-kvm
<dddddd>Is this because the host CPU or because the 32 bit kernel? Or anything else?
<dddddd>$ lscpu
<dddddd>Architecture: i686
<dddddd>CPU op-mode(s): 32-bit, 64-bit
<dddddd>$ qemu-system-x86_64 --version
<dddddd>QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u4)
<dddddd>In /proc/cpuinfo the lm flag is present.
<dddddd>... and the vmx flag
<vgfr>How can you use rust under guix?
<mbakke>Hmm, the wrapper also picks up the wrong bash when both bash-minimal and bash are present.
<mbakke>It would be nice with a #:shell argument to wrap-program.
<snape>mbakke: doesn't wrap-program take bash from the PATH?
<snape>you just need to change the PATH then
<mbakke>snape: It uses (which "bash").
<mbakke>Hmm, that could work.
<mbakke>snape: Somehow the wrapper still picks the wrong bash even with bash-minimal first in PATH.
<mbakke>I'll try to remove the full bash from PATH instead.
<g_bor>mbakke: I was looking around the bugtracker, and I've found 28330, where you proposed a list of patches for boost 1.65. We now have 1.66, do you think it is ok to close this?
<mbakke>Heh, it finds the wrong bash even when it's not in PATH.
<mbakke>g_bor: I closed it recently, thanks for the reminder :-)
<snape>mbakke: could you share the code?
<g_bor>Ok, thanks:)
<janneke>g_bor: just built binutils-2.20.1 with gcc-2.95.3 and glibc-2.2.5, now attempting a big leap to gcc-4.7.4
<mbakke>snape: It's a bit messy, but here's a diff:
<g_bor>janneke: That is so nice! Do you have the missing items documented? Also, is the ELF header problem already patched?
<mbakke>Tests are disabled so testing #:disallowed-references is faster.
<janneke>g_bor: the ELF header problem is patched -- all fixed on savannay wip-bootstrap
<janneke>later developments on my ever-resetting gitlab wip-bootstrap :-)
<janneke>g_bor: apropos documented: what i'm doing is explicitly set PATH (and other env vars) to in each package
<g_bor>janneke: thanks, I will give it a try again next week :)
<janneke>it looks like this:
<janneke>so "we" can start replacing all binary seeds one by one
<janneke>g_bor: lovely! we have a release coming, that's much more important right now ;-)
<snape>mbakke: I don't think you should modify the PATH in another phase, because there might be something in-between that changes it again
<snape>instead I would (setenv "PATH" bash) just before calling wrap-program, in the same phase
<mbakke>snape: It's needed for the 'patch-shebangs' phase too.
<mbakke>But I can try to reset PATH again in that phase.
<wigust>ACTION thinks ‘#:shell’ argument for ‘wrap-program’ was a good idea
<mbakke>Heh, I removed "bash-full" from PATH in that phase, yet the wrapper still finds the wrong bash.
<snape>mbakke: did you try to setenv just before calling wrap-program? With just the bash you need?
<mbakke>I guess (guix build utils) uses the environment file rather than the live environment.
<mbakke>snape: I tried that, but then the next phase fails due to not finding tar. Will try adding tar too.
<snape>mbakke: what about using with-environment-variable (from tests/scripts.scm)? :-)
<mbakke>snape: Oddly, 'gitk' has the correct shebang in the build directory, but installing gives it the wrong shell.
<snape>mbakke: are you sure they are the same gitk? Did you check with 'which'?
<mbakke>Oh, there's a patch-shebangs phase after install.
<snape>ha :)
<snape>oh I misunderstood, I thought you were talking about 'guix package install'
<snape>whereas you were talking about the phase
<snape>so do you use with-environment-variable?
<mbakke>The 'patch-shebangs' phase does not seem to use PATH at all, but rather builds its own PATH based on inputs.
<snape>I meant for wrap-program
<mbakke>snape: Not needed, the culprit is the 'patch-shebangs' phase.
<mbakke>Resetting the environment was indeed sufficient for wrap-program and 'patch-source-shebangs'.
<mbakke>But I'm not sure how to make 'patch-shebangs' ignore the other bash.
<mbakke>There's a comment in the phase going 'Shebangs should refer to binaries of the target system---i.e., from "inputs", not from "native-inputs"'.
<mbakke>Yet it manages to pick the bash from native-inputs.
<mbakke>But since it does not work as it should anyway, perhaps we can just drop the phase in this case.
<snape>mbakke: why is having a full bash in the closure an issue?
<mbakke>snape: Two reasons: 1) it's a "native-input", so bad things will happen when cross-compiled; and 2) it makes the package unnecessarily larger.
<snape>1) seems very good indeed :-)
<snape>vgfr: rust doesn't seem to build. Its build even managed to shut down my machine :-)
<snape>so I guess it's a bug. Maybe you could report it to ;)
<mbakke>snape: I sent the final patch here:
<mbakke>Alternatively, we could just delete "t/" :P
<snape>yes :
<snape>so you delete patch-shebang and you don't replace it?
<snape>doesn't it end up with wrongly shebanged files?
<mbakke>It ended up with wrongly shebanged files with that phase -- no idea what other consequences it might have :-)
<snape>what about using bash as an input? Then you avoid 1), shebangs will be fine, and all tests will work :-) Only problem 2) remains
<snape>which is imho not that important
<snape>given that lots of people have bash already installed
<mbakke>snape: Tests are guaranteed not to work when cross-compiling in that case. And it's still a workaround for a bug in the patch-shebangs phase.
<mbakke>But feel free to mention it in the bug report :-)
<snape>mbakke: oh yes, got it. Did you report the patch-shebangs bug?
<mbakke>snape: Nope! And I have to go now. Maybe tomorrow ;-)
<snape>good bye then :)
<tang0>Hello, guix. I'm attempting to install GuixSD and I'm running into a problem. The error message I'm getting looks something like **k33grub-efi-2.02/sbin/grub-install: error: failed to get canonical path of `/boot/efi'
<tang0>Any ideas as to how proceed?
<dddddd>Hello again.
<civodul>tang0: did you mount the "EFI System Partition" at /boot/efi?
<pkill9_>is there anything stopping this (kdenlive) from being merged?
<tang0>civodul: yes, /boot/efi is mounted
<tang0>civodul: to be accurate, it's currently mounted at /mnt/boot/efi. but config.scm has /boot/efi relative to /.
<civodul>tang0: ok; i think you also need to have /boot/efi mounted in the installation image, though
<civodul>pkill9_: maybe not, you can chime in on that issue if you think it's ready!
<pkill9_>i just wondered, i haven't tried building it
<pkill9_>though i think i will at some point
<tang0>civodul: what does it to mean to also have it "mounted in the installation image"?
<tang0>civodul: /dev/sda2, my ESP partition, is mounted on /mnt/boot/efi. Do I need to move that mountpoint elsewhere?
<civodul>during the installation you may need to mount it at /boot/efi, not /mnt/boot/efi
<tang0>Oh I see what you mean. I'll try that now.
<civodul>i don't fully remember, but i think that's what 'grub-install' checks
<wigust>./pre-inst-env guix system => guix: system: command not found
<CornBurglar>Heyy Guix
<CornBurglar>Does anyone know if guix can be installed on OpenBSD?
<wigust>ACTION seems to hit #31841