IRC channel logs


back to list of logs

<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>not good
<quiliro>guix package update should be in order before installing packages
<quiliro>guix package --update
<lfam>There's no such command
<quiliro>guix package -U
<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>slyfox: agree
<quiliro>lfam: guix package --update does exist
<quiliro>lfam: mistake
<quiliro>i must go
<quiliro>big hug to all of you
<lfam>Okay, sorry none of know about mariadb
<quiliro>thank you for being part of guix
<lfam>none of us know*
<CharlieBrown>lfam: Thanks. I just wanted to make sure. It's been a while since I've used Guix.
<quiliro>lfam: np
<CharlieBrown>Running guix pull...
<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
<quiliro>or is it for all
<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
<quiliro>lfam: yes
<quiliro>last guix pull on sunday
<quiliro>about 48 hours ago
<quiliro>turning the lights off on me
<lfam>Okay, I'm sorry you have to go :(
<lfam>I don't know what's wrong. I'll try to test
<CharlieBrown>Is it safe to replace my distro's XFCE with Guix's?
<CharlieBrown>:-) updated GNU Guix successfully deployed under `/home/cal/.config/guix/latest'
<CharlieBrown>Hey, there's no IceDove.
<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>It's in the manual, section 'Application Setup':
<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
<CharlieBrown>Oh wait, that was my battery... Nvm.
<CharlieBrown>How do I get Guix programs in my PATH?
<CharlieBrown>Found it.
<CharlieBrown>warning: failed to install locale: Invalid argument
<CharlieBrown>Wait... but I did install glibc-utf8-locales...
<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>Where's the mailing list?
<paroneayea>CharlieBrown: which one?
<CharlieBrown>paroneayea: Found it.
<CharlieBrown>paroneayea: Actually, do I submit package requests to bugs or help?
<paroneayea>CharlieBrown: submit patches for patches/features to and for bugs,
<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
<paroneayea>guix-patches is brand new :)
<CharlieBrown>paroneayea: I sent it to guix-help
<paroneayea>ok! :)
<paroneayea>that's probably a safe route.
<CharlieBrown>Hey, what's up with this? The binaries in my profile are dated to the Unix epoch...
<dmarinoj>Where do I get pre-inst-env?
<CharlieBrown>Whoa, I didn't know GNU had a crash reporter.
<arescorpio>extra/gnucash 2.6.15-1
<arescorpio> A personal and small-business financial-accounting application
<arescorpio>extra/gnucash-docs 2.6.14-1
<arescorpio> GnuCash documentation package
<CharlieBrown>pavucontrol from Guix does not see my audio sources.
<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. :-)
<braunr>clacke[m]: eh
<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>hi people
<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 ….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>that's the last line
<degauss>any ideas?
<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
<braunr>i'm curious too
<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>It could be.
<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…
<clacke[m]>degauss: how old is your guix-daemon?
<degauss>let me check "guix package -u guix"…
<clacke[m]>I had that problem and solved it by running guix-daemon 0.12.0
<degauss>(same error)
<degauss>clacke[m]: how can I check?
<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]>Is that the daemon currently running?
<clacke[m]>Maybe you didn't restart it for several weeks
<degauss>jmd: "guix environment guix" fails with the same error :(
<clacke[m]>Are you on GuixSD?
<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
<degauss>clacke[m]: I think you're right!
<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>thanks a lot!
<clacke[m]>had this problem yesterday myself
<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]>I meant jmd's comment
<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]>Yes, sure, but always from a clean slate
<degauss>yup, root's guix was still 0.11.0
<jmd>clacke[m]: It happened a few weeks back:
<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.
<clacke[m]>as the break happened as late as January
<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 :)
<efraim_>sneek: later tell phant0mas does hurd in guix (or guix on hurd) use glibc or a hurdish glibc? I found this patch in glibc-2.25 that's messing with my bootstrap
<sneek>Got it.
<efraim_>sneek: botsnack
<jmd>We need to teach sneek about the verb "to ask".
***jonsger1 is now known as jonsger
<rogers1>nick erliphant
<erliphant>Hi - sorry about that
<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?
<erliphant>do I need to build my own fork of 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 - yes I am indeed
<erliphant>@rekado - I just wasn't sure that I should put non package definition code in there.
<rekado>you can
<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?
<rekado>(I think it wouldn't work)
<erliphant>@rekado - I think that's too late
<erliphant>@rekado - I mean I think it gets executed too late
<rekado>another idea:
<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 - interesting thought.
<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?
<efraim>normally just the prefix
<jmi2k>Ok, I'll do that, thanks
<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
<nliadm>yeah, you need to sync
<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>makes sense
<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>erliphant: Tricky :)
<erliphant>@lfam - ha ha.. I'm finding that
<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 :)
<erliphant>@lfam - I'll do as suggested.
<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
<erliphant>@lfam - that's very helpful - will do.
<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>erliphant: Announcement of that tool:
<erliphant>@lfam: thx
<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 :)
<jonsger>was quite interesting :)
<bavier`>well on our way to breaking 5K packages for the next release
<Isorkin>Hi. How to fix codepage in putty/kitty? The terminal is displayed normally.
***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 <>.
<lfam>root_guix: I think that all you have to do is set the (locale) field of your operating system configuration and reconfigure your system:
<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/, for GNU/Hurd 0.0.0, not stripped
<janneke>all kudos go to phant0mas
<catonano_>janneke: wow :-)
<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.
<seaword>Any clues?
<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]>unset GIT_EXEC_PATH
<clacke[m]>then you're fine
<ng0>thanks, i'll try
<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
<ng0>that fixed it
<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.
<ng0>I'll be off now too
<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?