<nckx>jas4711: ...phew, because that would have been a pain to debug remotely :-) Yes, our error messages still need work. <jas4711>nckx: i made some other errors too. it is now installing at least... *nckx → afk, good luck! Guix + md works great. <mbakke>Actually, it does not work on EFI. I forgot to report that bug. <jas4711>mbakke: yeah, i spent an hour trying to get md to work with efi and gave up <jas4711>msdos disk labels never goes out of style *nckx gets lured back in: ehmmm, no, I use UEFI. <jas4711>nckx: the error message i got when trying md+uefi was: grub-install: error: failed to get canonical path of `none'. <mbakke>GRUB failed when I tried installing to a mdraid created on the 0.15 image. <mbakke>Perhaps a recent regression? I really need to write those EFI system tests. <mbakke>jas4711: I had a more specific error from GRUB (could not add required modules or something). It's possible we both screwed up :P <jas4711>mbakke: it is more likely to be my fault. it could be a forgotten mapped-device then too <nckx>jas4711: Wild guess, but that sounds like an error you'd also get when your bootloader-configuration's not up to snuff. <nckx>Guess I won't be updating my servers any time soon... :-( *nckx really has to go or will rightly sleep on the sofa tonite. xoxo <jas4711>sigh. 'ERROR: In procedure scm-errors: pre-mount actions failed'. for some reasons the kernel says 'md0 stopped' before *jas4711 giving up on md boot tonight, really need this machine (my backup server) in production before vacation <mbakke>nckx: Do you have any special bootloader configuration outside of (target "/dev/foo")? Good night! <mbakke>jas4711: Can you post your config? <mbakke>jas4711: When are you getting that error? During `guix system init`? <jas4711>guix system init lead to grub-install: error: failed to get canonical path of `none'. <mbakke>jas4711: Was the device node called "/dev/md0" in the installation image? <mbakke>I've had weird errors when installing to a different device path than what was mounted. <jas4711>it would be nice to see a copy of a working UEFI+MDRAID installation including config.scm <janneke>rekado/snape: the gnupg minibuffer signing recipe works for me -- thank you so much! <snape>There's something weird with rekado's config. My switch to the browser buffer is instantaneous. <mbakke>jas4711: I think if we ask nckx very nicely he might just show us a glimpse. But we'll need to be tålmodig. <janneke>snape: yeah, never saw that -- rekado is either running different bits than we are, or he is running the same bits in a different environment <janneke>snape: should we somehow describe this in the manual? <janneke>i never imagined to install both emacs-pinentry, pinentry-emacs *and* pinentry <janneke>also, i missed allow-loopback-pinentry in either the gpg-conf or emacs conf...don't remember <snape>maybe. Actually, I don't even remember the role each of them play <janneke>i was very close, but didn't manage to figure it out, and suffered the popup for over a month <snape>I suffered from it too, for a long time <janneke>then you have a feel for how happy i am! <snape>about the doc, I don't know. Isn't it more Emacs than Guix/ <janneke>snape: the packages to install are pretty guix'y <janneke>we should maybe just bother civodul (or rekado after we help him to get this working...) <snape>yes, I just don't know how where to insert this bit of doc <snape>my configuration isn't perfect by the way <snape>(did I forget to admit it? :D) <janneke>well, give it your best try, post it to guix-patches and you'll get a friendly correction where how can do better? <snape>it works not well if one edge case (when I enter my password as a result of a freenode password decryption) *ecbrown is chomping at the bit for that chromium commit <snape>janneke: right, I write this in a TODO <apteryx>janneke: I had that GTK pinentry bite me too, had to install emacs-pinentry. <apteryx>and then put in your ~/.emacs: (pinentry-start) ***Steap_ is now known as Steap
<reepca-laptop>How do --system and --target of "guix build" map to the --build, --host, and --target of autoconf? As far as I can tell, --target according to autoconf should specify what platform a compiler being built would compile for, for example. Is that right? <ecbrown>offload build to the beast in the basement <montxero>Hey guys, is it normal for programs installed via guix to be very slow. Paticularly emacs. <mange>I haven't noticed Guix's programs being slow. How slow is very slow? <montxero>mange: So slow, characters take between 2 to 5 seconds to show up on the screen (enter the buffer). So slow some characters are dropped <mange>Yeah, okay. That's very abnormal. Are you on GuixSD, or are you using Guix on a foreign distro? Are other programs on the same machine also super slow? <montxero>mange: Using Guix on a foreign distro. I haven't really noticed the problem in other applications. To be fair, I only have locales, hello world, guile and emacs. <mange>Mmm. I'm using Emacs on a foreign distro and things are working fine for me. Sorry! <montxero>Okay thanks.... maybe I'll unisntall and re install the package ***rekado_ is now known as rekado
<rekado>montxero: this is generally futile with Guix as packages are reproducible. <rekado>you’d very likely end up with exactly the same binaries as before and have the same problems. <rekado>feel free to send a description of the problem to help-guix@gnu.org where people might be able to help you debug this. <montxero>rekado: Damn this reproducible builds! whatever happened to good ol, here's a program, trust it for it is blessed <mange>Is Guile also slow, or is it just Emacs? And are you using Emacs in a terminal? <montxero>mange: Using emacs in a terminal yes. Will have to try out guile... Any ideas on how to test it out apart from writing and running a small scheme script <mange>Well, the thing I was actually interested in what whether the issue was something to do with Emacs interacting with the windowing system poorly, so if you're using it in a terminal then that's clearly not an issue. <montxero>rekado: I was kidding with what I said about reproducible builds <roptat>I'd like to filter the result of find-files to filenames containing only one "/" <roptat>more precisely, I'd like to get the list of subdirectories of a directory <mbakke>jlicht: Have you had any success building the 10.X series of Node? ***mt is now known as mteufel
<rekado>I think we should have the installer script at a nicer URL <snape>rekado: the problem is if users start using it without reading the manual first <snape>roptat: I think you could use 'readdir', as in 'files-in-directory' from guix/build/union.scm <snape>and add the 'file-is-directory?' check (just below) <rekado>snape: I don’t want to *replace* the manual but I’d like to make the URL more memorable. <rekado>guix.info/install is much easier to remember than some cgit URL. <rekado>we could additionally do these things: 1) print the info command to read post-install instructions at the end of the script, 2) provide additional helpful error messages in case some configuration is missing (e.g. daemon not started) <tune>can someone link me to the part of the manual about how to automatically mount a swapfile via /etc/config.scm? <rekado>tune: in an info reader try ‘i swap RET’ <tune>oh shoot. you told me that yesterday, didn't you? <tune>I think I went to bed without doing it <tune>I don't use info much, I'm not having luck with the i part <tune>both emacs and the info command are telling me there's no index <rekado>you need to be inside of the Guix manual in order to access its index. <tune>oh, I see. how do I get to the guix manual? <tune>I usually view it in a web browser <rekado>if INFOPATH is set up correctly doing ‘info guix’ should be fine. <tune>awesome, that did work. thanks <rekado>you could also use info -f /path/to/guix.info <rekado>(the ‘info’ command provides a rather primitive reader; the info reader in Emacs is prettier) <tune>I haven't used emacs much either <tune>I know I can get to info with M-x info, but then what? <rekado>it shows you the directory by default, listing all manuals you have access to <rekado>from there you can do ‘m’ followed by the name of the manual you want to access <rekado>or you could tab your way through the directory, or use C-s to search. <rekado>info can be a bit weird at first, but what’s great is that you’ll have documentation that actually matches the version of software you’re really using. <rekado>given a good manual you could access relevant information faster than through a web search. <tune>I do like the thought of that <janneke>civodul: again some progress (if you can call it that..%-/ on wip-bootstrap: i replaced glibc-mesboot 2.2.5 with the "old" %bootstrap-glibc; now binutils-cross-boot0 builds <civodul>janneke: BTW, did you see my feedback yesterday afternoon? <janneke>here on irc -- i think i cannot find a log... :-( sorry! <janneke>civodul: can you please give me that feedback again? ***benny is now known as Guest23921
*janneke just found out that znc doesn't keep logs by default --thought it would <tune>I think guix logs are publicly recorded at least <tune>didn't know they were ever down, I don't actually check them myself. sorry if I got your hopes up <rekado>janneke: I also found this out much too late. <rekado>bayfront-log has been recording logs via znc for a couple of days now. <rekado>I just haven’t found time to publish them yet. <rekado>(I wonder if it’s enough to remove strip off joins and parts to get rid of IP addresses.) <janneke>rekado: ...i know this doesn't scale, but if you could send me yesterdays's log with civodul's comments that would be great <janneke>civodul: thanks for the patch; by not evaluating (%current-system) at load time, we don't have to develop in a guix-x86 vm anymore --that's great! <wingo>does berlin have more substitutes for x86-64 than hydra? if so how do i ask for substitutes from there? <wingo>afaiu only aarch64 defaults to berlin <wingo>weird that the manual doesn't mention this as a recommendation <rekado>(no substitute for qtwebkit, though) <wingo>at least, i didn't see it when i looked <rekado>I think it will be the default for the next release. <rekado>(in addition to hydra of course) <wingo>already having a substitute for webkitgtk is a good thing *wingo has rebuilt libreoffice twice in the last couple days :P *snape needs an ERC plugin to hide Matrix infrastructure issues <wingo>ok yay everything with the right pango now <wingo>it is pretty sad that i need to worry about the security of my irc program to not leak my private keys! <rekado>I keep getting a build error trying to build qtwebkit. <rekado>the error is ‘EOFError: EOF read where object expected’ <rekado>I have 16GB free on /tmp and 22G RAM. <rekado>and qtwebkit is required by pyqt, which is used a lot (for better or worse) in the scientific python stack. <rekado>as a stop-gap we could add a python-pyqt-without-qtwebkit variant and use that in matplotlib. <rekado>as it stands, matplotlib is currenty broken, and with it almost every package used for scientific computing with python. *rekado tries building python-matplotlib with the new python-pyqt-without-qtwebkit before pushing *janneke just built libstdc++-boot0-4.9.4, with the added %bootstrap-glibc debt/cheat <civodul>janneke: just saw you commits to wip-bootstrap: for testing, i just do: "guix build -e '(@@ (gnu packages commencement) gnu-make-boot0)' <janneke>i made small commits, so that we can easily remove them <janneke>i'm almost finished writing an email to guix-devel, i think we're done <janneke>err, functioally speaking...lost to cleanup and do :-) <rekado>tests abort for some unknown reason <janneke>civodul: i'm almost done building gcc-final <civodul>i thought i'd be done with the guile-gcrypt migration today but... looks like not <grafoo>hi! i sent a new package patch to guix-patches@gnu.org but forgot to add a file. <rekado>issues.guix.info is now also available via HTTPS. <grafoo>can i just amend the commit an resend the patch? <rekado>grafoo: yes. Please send it as a reply to the bug number that you received in the confirmation message. <jlicht>rekado: it looks really nice! I'm really liking the colour scheme. Also yay for https <jlicht>the mailto: links are a nice touch as well <grafoo>rekado: how long does it usually take to get a confirmation? <snape>grafoo: average is 2-3 days if it's your first patch <snape>grafoo: also, your first email to the list will be subject to human verification <snape>so it's normal that it takes time to arrive <nly>Got guix working yay! ***mteufel is now known as mt
<RetardedOnion>what mail clients do you use? i know mutt is packaged but i am definitly not competent enough to configure it <mbakke>Why does qtbase propagate 'which'? <tune>RetardedOnion: I recently installed claws-mail. it's not as nice as thunderbird, but it works <RetardedOnion>since i am not that interested in learning emacs, i will check out claws-mail. and maybe get around and find out wtf i am doing wrong with mutt <apteryx>what's the correct incantation to start Emacs in a pure guix environment with some emacs packages right now? <tune>can I system reconfigure while in the middle of user-level updates? I'm trying it <tune>>waiting for locks or build slots... <janneke>the guix-daemon has a --max-jobs argument, you may want to use that <tune>I'm using 99% of my cpu already so I'll probably just wait it out <tune>feeling a little regret starting this *before* installing a package quick <tune>actually I guess I can maybe ctrl-c out of it <oitofelix>No one running mark's port (branch wip-loongson2f), that could point me in the right direction to get it running on my Yeeloong? (I wonder why it wasn't merged into master) <atw>oitofelix: to both points, I would guess it's because not many people have that hardware <tune>I actually like that it'll wait for build slots and then automatically start <tune>I just started the reconfigure and then restarted the user updates so they'll start again after the reconfigure ends <tune>my brother has a lemote yeelong, but he's not actively using it. I think it's got debian on it <tune>if guixsd turns out to work okay on that hardware, maybe I'll ask him if I can borrow the laptop to install it <apteryx>here's a crude hack for launching Emacs in an environment with the emacs libraries available: for p in $GUIX_ENVIRONMENT/share/emacs/site-lisp/guix.d/*; do export EMACSLOADPATH+="$p:"; done; emacs -Q <oitofelix> Are there instructions on how to install GuixSD from scratch (starting from a git clone)? <apteryx>oitofelix: there are, see the Guix info manual. <atw>apteryx: It strikes me as odd that you have to construct EMACSLOADPATH yourself as I have done guix environment --ad-hoc some-emacs-package -- emacs successfully. Does running emacs with -Q cause packages available in the Guix environment to not be loaded? Is emacs -q a viable alternative? <ng0>out of the apparently many ways we have to find out which package is referenced why, do we have a short and memorizable line for when someone asks "why guix does my profile update tell me qtwebkit is getting in the way of upgrading (failing) when I have no qtwebkit installed by myself?" ? <reepca-laptop>Whenever I try reconfiguring my system now, it tries to build mariadb, and fails a bunch of tests. Anyone else experience that? <mbakke>rekado: We might have to remove the "--no-feature-renameat2" flag from qtbase on core-updates. <rekado>sneek: later tell snape I’m aware of the encoding problems. I haven’t yet implemented a multipart email parser. I might do this later tonight. <mbakke>Which means qtbase will require kernel 3.16. <nly>Wow rekado, how do I become a pro like you? <mbakke>It prevents use of a kernel 3.16 interface. <mbakke>However, the same function was added in glibc 2.28. So when qtbase tries to redefine it, it fails. <rekado>qtbase is needed by pyqt, which is needed by matplotlib, which is needed by the whole scientific python stack. <mbakke>The glibc implementation also requires kernel support. <rekado>meaning: when renameat2 is required CentOS 6 can’t use the scientific Python stack. <mbakke>The only way I see to patch it, is to #ifdef all <stdio.h> includes in qtbase all the way down to src/corelib/io/qfilesystemengine_unix.cpp. <rekado>can we patch qtbase so that it checks for the feature in glibc before redefining it? <mbakke>Actually, I think it will be okay to remove the flag. Are you able to test core-updates on RHEL6 rekado? <janneke>@ build-succeeded /gnu/store/v6bh5551q8jc9fww3wal4qj6y8vj8j6j-hello-2.10.drv - <janneke>/gnu/store/rdky1ydbv64r5ivxzm1x1yry7yvnq18k-hello-2.10 <rain1>what's the graph of the hello package look like? <janneke>rain1: hard to see... guix graph hello is just "hello" <janneke>guix graph --type=bag is *very big* (eog crashes) <janneke>you're aware that i dropped the ball on glibc for now; but everything up to the first gcc-4.7.4 is built without the %bootstrap-glibc <nly>janneke: what is exciting? I am a newbie <janneke>nly: some of us have been working for ~2y over at #bootstrappable, to create a fresh build of guix, starting without a binary binutils, glibc or gcc <janneke>i just built `hello', which kind of means a major milestone -- we cheated here and there, that will to be addressed later <nly>how does anything start building without any binary? <janneke>of course, that's not possible -- you need at least one binary <janneke>currently, we still start with several binaries; the major achievement is that binutils and gcc have been removed from the initial binaries <janneke>instead, we now only have a binary macro assembler and hex linker; we also added the generated assembly of a tiny scheme interpreter <jabranham>so I have cloned the guix repo, and changed the version number on a package. How do I try to build it then? Doing guix build pkg@newver just results in "package not found for version newver." <jabranham>Do I have to modify GUIX_PACKAGE_PATH to point to my clone? <tune>I get an error when trying to use :bulkrename in ranger <tune>it's supposed to ask me what editor to use and then open the filenames in my editor <tune>but it says something about not being able to find the files 'file' : 'file' <tune>like, it actually says file. not sure what it's trying to do <janneke>jabranham: ./pre-inst-env guix build <package> <rekado>mbakke: testing core-updates on RHEL6: I could maybe give it a try on Sunday, but more likely Monday. Would that be okay? <janneke>of course, there's lots of work to do: cleanup, glibc, x86_64, ...etc but hey <rekado>jabranham: has the code been configured and built? <jabranham>rekado: I did git clone <the guix git repo>, cd guix, guix envionment guix, ./bootstrap, ./configure --localstatedir=/var <janneke>the abstract recipe you give us: pkg@newver, should work...maybe you should make it concrete and present the diff you made on paste.debian.net? <jabranham>janneke: ah, looking back over "make check" it appears as though I accidentally interrupted it. I'll do that again and hopefully it'll work this time <rekado>jabranham: you don’t need to run ‘make check’ <rekado>jabranham: it will run all tests, some of which might fail (which is no reason for concern) <rekado>jabranham: but you should run ‘make’ to compile the Guile modules. <jabranham>rekado: Good to know. The manual says I do though: "Finally, you have to invoke 'make check' to run tests" under building from git <rekado>jabranham: yes, that’s generally a good idea, but I know that there are a few tests that do currently fail. <rekado>running the tests also won’t have an effect on the problem you reported. <jabranham>ah, so I get the error: ERROR: In procedute %resolve-variable: error: gzip: unbound variable <rekado>jabranham: this sounds like a bad configure. <jabranham>rekado: OK, I'll try again from a clean git checkout <jabranham>wow magit-status is basically unusable from the guix repo, huh :-( <rekado>it’s possible that it’s because of automatic changes to the ‘po’ directory. <jabranham>I think it's trying to highlight all the po/guix <rekado>this happens sometimes after a new build. Haven’t seen this during day to day development, though. <jabranham>aren't these po/ files regenerated all the time though? wouldn't this be a problem whenever anyone modifies anything? <jabranham>rerunning make from a clean git checkout failed with the same error :-( <jabranham>rekado: yeah. ./bootstrap, ./configure --localstatedir=/var, make <rekado>and you get ‘gzip: unbound variable’ when running make? <jabranham>in procedure %resolve-variable: error gzip: unbound variable <rekado>‘configure’ did not print any errors, right? <snape>jabranham: did you change the environment from your .bashrc? <sneek>Welcome back snape, you have 1 message. <sneek>snape, rekado says: I’m aware of the encoding problems. I haven’t yet implemented a multipart email parser. I might do this later tonight. <jonsger>I think guix doesnt like guile2.0 :( <snape>rekado: great :-) nice work anyway <snape>(well, I just wish I could filter by submitter, but that seems close to impossible) <jabranham>snape: the .bashrc file is the one that came with guixsd <rekado>snape: I’ll work on this after fixing multipart parsing <jabranham>well I deleted that guix clone, rebooted the computer, and guix clone'ed anew. Seems to be working now. <jabranham>OK, so on to the next error. If I change the sha256sum of this package, I get: invalid-base32-character [character: #\e string: <the sha256sum>] <reepca-laptop>specifically mariadb's "rpl.rpl_multi_engine" test seems to be failing