<quiliro>guix does not update itself first thing? <lfam>So, if CharlieBrown installed using the 0.12.0 installer, they will not have those updates available until they do `guix pull` <quiliro>guix package update should be in order before installing packages <lfam>`guix pull` is similar to `apt-get update`, and `guix package --upgrade .` is similar to `apt-get upgrade` <lfam>I agree that all users should run `guix pull` after installing, and they should run it often afterwards <quiliro>lfam: guix package --update does exist <lfam>Okay, sorry none of know about mariadb <CharlieBrown>lfam: Thanks. I just wanted to make sure. It's been a while since I've used Guix. <quiliro>when i connect again in a few days i will report the error <lfam>So, I can connect to the QEMU VM over the emulated serial port, but I can't seem to make it work over the real serial port even when using the same disk image. <lfam>I invoke QEMU like this: qemu-system-x86_64 -enable-kvm -m 3072 -net user -net nic,model=virtio -boot menu=on -drive file=/home/leo/tmp/test-image -serial pty <lfam>It tells me which pts device to use, and I can connect with screen <lfam>When I leave the agetty-service out of the disk-image, that no longer works <quiliro>lfam: is the guix pull error i get a personal error? <lfam>Well, it works, but there is no login prompt <lfam>quiliro: It's working for me <lfam>Do you know how long its been since your last `guix pull`? <lfam>Also, I'm on x86_64, but it looks like you are using i686. Is that correct <lfam>Okay, I'm sorry you have to go :( <lfam>I don't know what's wrong. I'll try to test <CharlieBrown>:-) updated GNU Guix successfully deployed under `/home/cal/.config/guix/latest' <CharlieBrown>Hm. I always forget how to remedy "warning: failed to install locale: Invalid argument". <lfam>It doesn't make a difference in practice, but you need to set GUIX_LOCPATH in the guix-daemon's environment. So, in the systemd service file <CharlieBrown>lfam: Could you link the document describing this, so I can save it? <lfam>If you used our systemd service file, I *think* it sets that variable anyways. In which case, I think your user is using a different set of locales from the daemon <lfam>Like I said, it doesn't make a difference in practice in my experience <CharlieBrown>lfam: My user has been logged in since before root installed Guix. <CharlieBrown>I guess it doesn't matter. I don't want to mess with root, anyway. I'll do whta's in the manual. <CharlieBrown>Whoa. Just installing IceCat uses a lot of disk space. O_O <lfam>CharlieBrown: The word 'install' in that context does not refer to installing a package into your profile ***quasisan1 is now known as quasisane_
***quasisane_ is now known as quasisane
<CharlieBrown>paroneayea: Actually, do I submit package requests to bugs or help? <CharlieBrown>paroneayea: Yeah, but where do I submit requests for people to make packages? <paroneayea>CharlieBrown: I guess that would be guix-patches, but I dunno! <paroneayea>CharlieBrown: try submitting a request for a package there and see how the conversation goes... if someone gives you a hard time, say Chris Webber said to submit it here and to find out if this is the appropriate venue <arescorpio> A personal and small-business financial-accounting application <clacke[m]>CharlieBrown: This is by design. Setting all file time stamps to zero is part of reproducibility. <clacke[m]>Never seen epoch as 1969-12-31 before. East-of-Greenwich bias. :-) <clacke[m]>Epoch 0 is as good as any arbitrary date. Have to pick a date if you don't want time stamps to depend on when you built the thing. <degauss>I'm having a serious problem with package-related commands after my last "guix pull" <degauss>most of them (pull, package update, rollback…) fail with a similar error: <degauss>guix pull Starting download of /tmp/guix-file.Vf8r20 From http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz... ….tar.gz 4.7MiB/s 00:02 | 11.0MiB transferred Backtrace: In guix/packages.scm: 982: 19 [bag-grafts # #] 966: 18 [fold-bag-dependencies #<procedure 5080ce0 at guix/packages.scm:982:29 (package grafts)> ...] 983: 17 [#<procedure 5080ce0 at guix/packages.scm:982:29 (package gra <degauss>guix/packages.scm:871:27: In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f <degauss>guix 0.12.0-4.d9da out /gnu/store/9hhljacc22jppmjx57xc7c46by10y8gh-guix-0.12.0-4.d9da <degauss>running on top of Debian unstable, all search paths imported <degauss>I'm pretty stuck with that error since I'm not even able to roll back! <degauss>invoking the commands with other versions of guix in my store throw the same error <jmd>degauss: Often that suggests an API break. <degauss>jmd: so I pulled some pkg info that is not compatible with the version of guix I'm using? <jmd>Exactly what command gives the error? <degauss>then I guess I should update guix by some means different than "guix package"? <degauss>jmd: guix pull, guix package -u, guix package --roll-back… <degauss>let me check "guix package -u guix"… <clacke[m]>I had that problem and solved it by running guix-daemon 0.12.0 <jmd>Can you do "guix environment guix" ? <clacke[m]>what's the output of "readlink -e path/to/your/guix-daemon"? <degauss>ir's /gnu/store/9hhljacc22jppmjx57xc7c46by10y8gh-guix-0.12.0-4.d9da/bin/guix-daemon <clacke[m]>Having an up-to-date guix client (on your user) isn't enough, you also need an up-to-date guix-daemon <clacke[m]>Maybe you didn't restart it for several weeks <degauss>jmd: "guix environment guix" fails with the same error :( <degauss>I just restarted my computer yesterday, but let me check <degauss>clacke[m]: not, just pkgs on top of Debian <clacke[m]>If you aren't on GuixSD, how are you running guix-daemon? I'm guessing you have a service definition somewhere, maybe it statically points to guix-0.11.0/bin/guix-daemon (or indirectly, through /usr/local/bin/guix-daemon), or maybe it points to whatever guix root has installed, and you only upgrade on your non-privileged user? <jmd>I would suggest removing all the existing .go files <clacke[m]>The .go files are reproducible. Removing them won't change anything. <degauss>I explicitly run the latest daemon as root, and the user can do guix pull now <degauss>curiously I never needed to boot the daemon explicitly <jmd>clacke[m]: If they correspond to old sources, it can cause these types of errors. <jmd>Especially if there has been an API change. <degauss>it seems that it didn't blow until there was an actual API change <clacke[m]>If you build guix in guix, I don't see how that situation occurs. <degauss>so I should also upgrade root's guix from time to time… <degauss>clacke[m]: I don't know, I don't build guix myself <clacke[m]>there's not source/binary mismatch if guix is in guix, only if you git clone yourself and play with it <degauss>now I did pull and upgrade guix in the same run, it's building guix from sources ;) <degauss>maybe the docs should be more clear in reminding the user to also upgrade root's profile from time to time <clacke[m]>The issue here is that newer guix sources can't be evaluated by a 0.11.0 daemon. <clacke[m]>It would be nice if at least the first commit with a new minor version could be compiled by the previous minor version. I never run the -devel daemon, so I couldn't upgrade to 0.12.0 without some hassle. <degauss>thank you both, you saved my day! :) <clacke[m]>I admin I'm not sure where the breaking happens and what's the interaction between package tree, guix client and guix daemon. <clacke[m]>When I could guix pull I tried guix pulling some older commits all the way back to december and they all failed <clacke[m]>So I realize now the problem probably wasn't in the version I was trying to pull, but in the guix or package tree was installed in my user. <roelj>Is it possible to modify a value in a (guix records) record? So, in a (package ...) could I (set-package-name! ...) when set-package-name! would've been defined in the record type somewhere? ***kensington_ is now known as kensington
<degauss>clacke[m]: I forgot that I was starting the daemon via supervisord, it was probably not starting <degauss>after upgrading my root profile and restarting supervisord, I'm able to successfully run package operations with the normal user :) <jmd>We need to teach sneek about the verb "to ask". ***jonsger1 is now known as jonsger
<erliphant>Hi - I'm trying to use a git-fetch type package source but the fetch needs ssh installed. We can't clone over http. As far as I can tell, everything basically looks ok but the clone fails because ssh isn't available <erliphant>Some further digging suggests that ssh isn't in the set of (standard-packages) and isn't available <roelj>erliphant: What's the error message you get? <erliphant>What is the recommended way to proceed from here. Should I write my own fetcher? Where is the best place to put it if I don't want to modify the guix sources? <erliphant>I'll dig up the exact message - basically that ssh isn't available and that the fork fails <roelj>Is it an existing package, or one you're currently packaging? <erliphant>Something that I'm packaging. My sources are on an internal git server but I need to clone over ssh <roelj>Could we look at the package recipe? <roelj>Or the (source ...) bits at least <erliphant>Sure.. I'll see if I can put it somewhere. It's fairly basic. <rekado>erliphant: writing a fetcher is not too hard and does not require that the fetcher be part of the official Guix sources. <rekado>erliphant: before the hg-fetch method made it into Guix I used it locally for some packages. <erliphant>The exact error messages are: "error: can not run ssh: No such file or directory". This is followed by "fatal: unable to fork" <rekado>in your case it may be sufficient to create a git-fetch variant, which also pulls in openssh. <erliphant>@rekado + @roelj - what is the best way to make these customisations available to guix? <rekado>what I did back then was add hg.scm in the "guix/build" directory of a package repository <rekado>it only needed to be on the GUIX_PACKAGE_PATH <rekado>are you already using GUIX_PACKAGE_PATH for your custom packages? <erliphant>@rekado - I just wasn't sure that I should put non package definition code in there. <rekado>I also added a couple of extra license definitions there <erliphant>@rekado - perfect.. that sounds like a way forward for me. <rekado>erliphant: are you sure, though, that you cannot fix this by adding openssh to the inputs? <erliphant>@rekado - I mean I think it gets executed too late <rekado>git fetch takes a key argument "git" <rekado>maybe you can override this at some point and use a git package that propagates openssh? <erliphant>@rekado and @roelj - thank you both for your help. Appreciated very much as always. <jmi2k>How can I disable --enable-fast-install in the configure phase? <efraim_>you're going to have to write a custom 'configure phase <jmi2k>efraim: oh ok. Something special to keep in mind, or just running configure with prefix? <bavier`>does debian run 'autoreconf' when it builds autotools-based packages? <efraim>I believe they do as part of their build process <efraim>It eliminates a bunch of architecture problems that we occasionally patch <bavier`>interesting. I've run into more problems with configure.[ac,in] not working with later versions of autoconf <jmd>rekado: We never got around to discussing your patches for the installer. <mekeor>almost after every boot, i have to manually run 'sudo dhclient -i my_wifi_interface' in order to get my internet connection working. is this a known thing? <mekeor>oh, maybe it's because my system configuration lacks a dhcp-client-service? ***davidl is now known as usrname
***usrname is now known as davidl
<lfam>Argh. I wasted so much time testing the agetty service by not noticing the effect of the kernel's cache while trying to write test images to my USB flash drive <lfam>I wasn't actually testing the new images <lfam>Well, it's a good day if you learn something <jmd>lfam: dd usually is a reliable way to write images. <lfam>jmd: That's my experience, too, but at some point yesterday the kernel starting "writing" to the cache and not to the physical device, and I was removing the device before the cache was flushed <lfam>The thing is, I did run `sync` after dd exited, but that wasn't enough <lfam>So now I'm invoking dd with 'oflag=nocache conv=fdatasync' <lfam>I only noticed this when I started poking around in the files on the device and noticed some of them were not correct :/ <jmd>sync will have no effect on dd. <lfam>That's my observation, but I don't understand why. <jmd>(assuming it was a physical device you were writing to). <lfam>Do you know why it doesn't work? <jmd>lfam: why what doesn't work? <lfam>Why it has no effect on dd <jmd>Becuse it's not designed to. Sync flushes a filesystem cache. <jmd>I suspect your problem might be caching in the device itself rather than the kernel. <lfam>It's a 32 GB USB flash drive, and I was trying to write ~1.5 GB of data to it <jmd>I had a similar problem once with a usb drive. I was writing to it and then removing power before unplugging the USB cable. <jmd>I discovered the correct way is to remove the USB connection *before* removing the power. <lfam>In my case, the power comes through the data connection. It's not externally powered <lfam>I should have been more suspicious when the write speed jumped from ~10 MB/s to ~300 MB/s after a couple flashes <efraim>who was here to hear me complain about dependancies on the linux kernel for glibc? a quick grep showed other dependancies on the kernel, so I think I should just add the kernel headers to the bootstrap process like LFS suggests <lfam>But of course I wanted it to be that fast <lfam>efraim: Interesting. I guess we should discuss it on guix-devel <efraim>we do have a note in glibc that limits.h refers to linux/limits.h so it should propagate the kernel headers, it could be that the bootstrap process until now just hasn't come across code that needed it before <efraim>I meant to say hi to the guys at the LFS booth at FOSDEM, their manual has been really helpful with understanding the bootstrap process <bavier`>ryanwatkins: I think it was you who had asked about a qutebrowser package; I've pushed one to master <erliphant> So I need to clone a repo over git+ssh. After speaking to rekado I modified the git-download module to include ssh and tt seems this will work as desired. However, I now need to deal with host keys and ssh config etc. What's the best way to set up this config inside the build jail? <erliphant>My specific problem is that host key verification has failed but I may need secrets (keys) etc too. <lfam>Honestly, I'd ask on the guix-devel or help-guix mailing lists for advice, because somebody else might have already made this work. guix-devel probably has more subscribers. <lfam>If somebody pops up here, that's great too :) <lfam>erliphant: You might look at the code for `guix download`, which can conditionally include X.509 certificates when it's necessary to connect over HTTPS <lfam>Recently we stopped using that code directly. Instead we use something called perform-download, which helps to avoid a bootstrapping problem where TLS client source code is only accessible over HTTPS <lfam>But, the old stuff might give you some ideas about how to include and use resources like keys <erliphant>@lfam - I assume now with perform-download that the download is done before the jail is setup? <lfam>erliphant: I don't know it that well, but my understanding is that it is invoked by the guix-daemon and downloads directly to /gnu/store <erliphant>@lfam - thanks again. I'll have a sniff about. <lfam>Good luck and ask questions :) <bavier`>awww.. the "future of guix" fosdem video got cut short <lfam>They ejected us from the room quite firmly after that! <bavier`>otoh I guess I didn't miss much then :) <bavier`>well on our way to breaking 5K packages for the next release ***davidl_ is now known as davidl
<lfam>Isorkin: I'm not sure what you are asking. Is something not working correctly? <Isorkin>displayed instead of lines qqqqqqqqqqqqqq and xxxxxxxxxxxxxxxx <root_guix>How can I install Japanese characters support in GuixSD? <lfam>Isorkin: I'm not sure. If nobody answers here, you will probably get a response from the mailing list <help-guix@gnu.org>. <lfam>But I use the default (en_US.utf8) so I don't have any experience <janneke>woot /me has built `hello' with Guix on Debian/Hurd <janneke>janneke@debian:~/src/guix$ file $(which hello) <janneke>/home/janneke/.guix-profile/bin/hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so, for GNU/Hurd 0.0.0, not stripped <seaword>I've just installed GuixSD (using luks) and on the xfce desktop there's an encrypted drive. Double clicking this prompts me to enter a password. I then get an error about cryptsetup not being found. I installed this and upated my PATH however xfce still can't find cryptsetup. <ng0>damn... did someone of you run into something like this recently, even after sourcing the new envrionment variable for the GIT thing? /home/ng0/.guix-profile/libexec/git-core/git-sh-setup: line 46: <ng0>/home/ng0/.guix-profile/libexec/git-core:/gnu/store/wbq43z00nhpzdvs7b8yjsi9q5gw3hqs2-profile/libexec/git-core:/gnu/store/wbq43z00nhpzdvs7b8yjsi9q5gw3hqs2-profile/libexec/git-core:/gnu/store/wbq43z00nhpzdvs7b8yjsi9q5gw3hqs2-profile/libexec/git-core:/home/ng0/.guix-profile/libexec/git-core/git-sh-i18n: No such file or directory <ng0>happens when I try to rebase <clacke[m]>That variable apparently isn't a path in the sense that one can tag several paths on there with : <clacke[m]>and the variable is unnecessary really, as git falls back to the correct path <clacke[m]>took me 30-60 minutes to solve earlier today, glad I could help someone avoid that :-) <ng0>why do we set it at all? <clacke[m]>misunderstanding? corner case? We'd have to look in the source who enabled it and why. <clacke[m]>now don't get me curious, I'm supposed to sleep now :-) <ng0>82de2655a16dcc7a8e3b992b4afd34ec32c244a6 apparently this. <lfam>clacke[m]: I found I needed to set the variable to help git find `git send-email`. Something changed and it had stopped working <clacke[m]>Yeah, the problem is that search-path-specification thinks it can add several paths. What happened to ng0 and to me earlier today was that through some circumstances ~/.guix-profile/.... ended up their twice, which broke everything <lfam>Hm... I wonder what changed? 
