IRC channel logs
2018-06-23.log
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... <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_>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. <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>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 https://sqlite.org/fts3.html it explains how to enable FTS3 support, looks like the package definition is doing it right, so *shrug* <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? <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. <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. <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 <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. <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_,- <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 <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>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 guix-patches@gnu.org with your patch attached or in the message. <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>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?: configure.ac:63: error: possibly undefined macro: AC_DEFINE <apteryx`>only happens in a guix builder, not when experimenting with my user profile <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") <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 :-) <snape>you'll see that people use 'gnu-build-system' and modify the 'configure' phase so that it invokes qmake <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 <Copenhagen_Bram>wait a minute, shouldn't there be a guix repo somewhere from every time it clones when I run guix pull? <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 <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 you...to 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>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 <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: if you didn't know already guix has fizmo and glulxe available for zmachines and gblorbs <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) <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--) <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>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? <snape>Copenhagen_Bram: your inputs don't look good <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 <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 <brendyn>shouldn't need to escape the ) either <snape>"illegal character in escape sequence: #\\)", and then #\\. <brendyn>the quote is delimited by ", so ) doesn't need any escaping <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_> /gnu/store/v04ahw3s35swgss4s1a5bwrwwabmilcw-gtk+-3.22.29/lib/gtk-3.0/modules. <pkill9_> Maybe need administrative privileges. <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 <roptat>g_bor: it seems it was pushed 2 months before your comment <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 <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? <mbakke>g_bor: I closed it, thanks for the reminder. <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. <g_bor>roptat: Thanks, I will close it. <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? <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>QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u4) <dddddd>In /proc/cpuinfo the lm flag is present. <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: 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? <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 <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>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>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. <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 bug-guix@gnu.org ;) <mbakke>Alternatively, we could just delete "t/t9902-completion.sh" :P <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 ;-) <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? <civodul>tang0: did you mount the "EFI System Partition" at /boot/efi? <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 <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>Does anyone know if guix can be installed on OpenBSD?