IRC channel logs


back to list of logs

<sturm>`guix reconfigure` warns me: "guix system: warning: The 'device' field of bootloader configurations is deprecated.guix system: warning: Use 'target' instead." Can anyone advise on how I should change my config to address this? I've tried a few things without any luck.
<benny>sturm: just changing device inside the grub-configuration to target worked for me
<sturm>benny: oh, I was looking at "device" under file-systems. I'll try that
<sturm> [benny]( brilliant that worked for me, thanks!
<sturm>Also, is it significant that reconfigure warns "shepherd: Service user-homes could not be started"
<benny>I'm very new so I don't know, I'd guess not because if you're already booted the service is already running
***Piece_Maker is now known as Acou_Bass
<fusion809>Hi folks whenever I run guix pull today I get the error: "guix substitute: error: download from '' failed: 404, "Not Found""
<brendyn>fusion809: you can try adding --substitute-urls=""
<g_bor>hello guix!
<g_bor>I packaged python-networkx2 lately.
<g_bor>I've seen, that in phase reset-gzip-timestamps we do not check if the files are writeable, and fail with permission errors if they are not.
<g_bor>I think this is a bug in our tools, I do not consider strict permission a bug from upstream.
<g_bor>Maybe we should do something like this:
<rekado_>Hi g_bor!
<g_bor>If in a phase we have to write a file, check if it is writeable. If it is not, then note the original permissions, then give write permission, do the modification and reset permission to the original.
<rekado_>brendyn: rather --substitute-urls="" so that things not on berlin are fetched from the mirror.
<rekado_>g_bor: I think that’s reasonable. Would you like to propose a patch?
<g_bor>What do you think about that?
<g_bor>Yes, definietly
<g_bor>Ok, I will look into that then.
<rekado_>this would likely result in many rebuilds, so please do this on core-updates.
<g_bor>Ok, will do.
<g_bor>Do we know about other phases that might need this?
<g_bor> think this is somewhat cross-cutting...
<TeMPOraL>been stracing guix package install today; seems that it hangs for few minutes on read()ing a socket that is connected to guix daemon
<TeMPOraL>guix daemon has some logs somewhere, right?
<g_bor>Right, daemon logs are in: /var/log/guix-daemon.log
<TeMPOraL>found /var/log/guix-daemon.log, but nothing useful there
<TeMPOraL>only shows the times I ^C the installation process
<TeMPOraL>and some "spurious SIGPOLL" lines in between
<TeMPOraL>also, out of curiosity - does Guix use some code from Nix?
<TeMPOraL>because the (presumably) ^C lines in guix-daemon.log read "unexpected Nix daemon error: interrupted by the user"
<g_bor>maybe you should have a look at this
<g_bor>There were some discussion about a similar error...
<g_bor>I am sure it used to, but it was proposed to get rid of that.
<g_bor>I don't know what is the current state actually.
<TeMPOraL>g_bor: well, those lines are expected because I ^C the "guix package -i" I was strace'ing
<g_bor>Could you strace also the daemon?
<TeMPOraL>I could; any tips on how to do that, given that it starts automatically (I run guixsd)?
<g_bor>You could see where it stucks...
<g_bor>Ok, I will check how I did it last time...
<g_bor>yes, i just got the daemon pid from ps, then I used -p swith to strace to attach to that.
<g_bor>as root
<rekado_>also -f
<g_bor>yes, you should also need that to get anything meaningful.
<TeMPOraL>oh, so you can strace a running process? great
<TeMPOraL>I'll try that
<OriansJ>well, anyone know of a more efficient way to express this in C?
<sneek>OriansJ, you have 1 message.
<sneek>OriansJ, janneke says: a surprise bubbling...that sounds just great!
<janneke>a very nice surprise and bubbling indeed ;-)
<OriansJ>the big delay as always is my need to make it pretty
<janneke>pretty is very helpful, i'm often too impatient to aim for pretty early on
<OriansJ>I was taught to always assume that the person who was going to maintain the code that I write as a violent psychopath who knows where I live.
<janneke>OriansJ: you may have more luck of getting help here by using, or another site that can be used with Tor
<OriansJ>janneke: unfortunately when I hit that, i get "Due to continued abuse, this service has been disabled"
<OriansJ>I wish I knew of a good .onion paste site
<nee`>Hello, I have an old guixsd installation that I want to upgrade, but it currently fails at installing guile-git.
<nee`>./pre-inst-env guix package -i guile-git
<nee`>guix package: error: build failed: getting attributes of path `/gnu/store/aiz8db2gni401wc9fgidmcggxyb1czis-guile-bootstrap-2.0': No such file or directory
<janneke>OriansJ: sorry, used it quite recently -- how sad
<janneke>sneek: later tell civodul: has been disabled, can we recommend another tor-friendly pastebin?
<janneke>eh, but they will know i guess
<ng0>sneek: forget it
<ng0>oh sorry
<ng0>sorry didn't read the whole buffer >.<
<janneke>ng0: np, .NET was a typo anyway
<ng0> works (and installations of it (pb) elsewhere.
<_0bitcount>Possible trademark problem in the future?
<htgoebel>How can I make the guix-daemon in the installation-image to use
<lfam>_0bitcount: We'll cross that bridge if we come to it
<ng0>_0bitcount: I don't think that will happen
<ng0>maybe at some point we would need to point out at each others side that we are not the other party, but it's unlikely.
<ng0>different solutions and applications
<ng0>*side => website
<lfam>htgoebel: It's not convenient for me to boot an installer right now, but you could pass the --substitute-url argument to any commands you need to use, and authorize berlin's key in the normal way
<_0bitcount>I was remembering the Gnome incident:
<htgoebel>lfam: So you mean "her start guix-daemon --substitute-url= should work?
<htgoebel>will tr
<htgoebel>will try
<lfam>htgoebel: You don't even need to restart the daemon. You can pass the urls to any command that builds things. For example, to `guix system`
<htgoebel>lfam: Huh! That's new to me!
<lfam>It's very convenient :)
<lfam>It's one of the "common build options":
<htgoebel>lfam: wow, indeed this is working. Thanks
<lfam>But root privileges are still required to authorize the signing key, except in cases where packages are bit-reproducible and berlin serves a substitute that is identical to what was advertised by a different authorized key
<lfam>Because in that case it doesn't matter much, except if there are exploitable bugs in the code that downloads and checks the hash of the download
<htgoebel>lfam: I search for this option in 'guix system --help#, but overlooked it.
<lfam>To clarify, you always need root to authorize a key, but you don't need a key to get those identical substitutes if they are advertised by a different server whose key you have authorized
<htgoebel>ACTION is setting up an offload server and experiences this is more work than expected :-(
<ng0>oh, just offloading? yeah it takes some time to get it right the first time but it's quiet easy
<ng0>I thought with your emails that you are setting up a personal CI
<lfam>ACTION tries building the latest cmake
<htgoebel>ng0: You mean due to the overlay, Qt and KDE Framework patches?
<htgoebel>These are the result of my (labours) work on KDE Plasma.
<ng0>no, your question on setting up …server…GuixSD… (all I remembered)
<htgoebel>Just paying around in different areas.
<htgoebel>One of my long-term, low-prio aims is to replace my debops-driven debian systems with guixop-driven GuixSD systems :-)
<TeMPOraL>hmm... now I realize that global installation of stumpwm in GuixSD needs some extra work
<TeMPOraL>in particular, I need to figure out how to inject quicklisp into it / the global(?) SBCL off which it's based
<g_bor>hello guix!
<g_bor>do we have a proposed way to build pyc files reproducibly?
<g_bor>I've read in the report, that we are not there yet, but is someone working on it?
<lfam>g_bor: This is the report you mention? <>
<lfam>I'm not sure if anyone has been working on it since the last message
<g_bor>thx, just what i was looking for.
<lfam>It's possible that some work in this area is pending on the 'core-updates' Git branch, but I'm not sure
<mb[m]1>At this stage we might as well wait for this to land upstream:
<mb[m]1>`guix pull` on a Rockchip Veyron armv7 takes around 64 minutes.
<lfam>I agree, it's probably best to wait for CPython to fix the issue upstream
<efraim>Just hopped in for a second, guix pull on the firefly 3399, 2xA72 and 4xA53, is 65 minutes IIRC
<mb[m]1>I tried cherry-picking this commit:
<lfam>efraim: Does it use all 6 cores at once?
<mb[m]1>But struggled with some new test failures.
<efraim>Yes actually
<lfam>Is that with the vendor kernel or something else?
<mb[m]1>Ugh, now I have to compile binutils and glibc. See you tomorrow, Chromebook.
<efraim>Vendor kernel, its actually running on Ubuntu and a 4.4 kernel
<lfam>I wonder if there is some magic in the vendor kernel to make it use all the cores together
<lfam>mb[m]1: I'm working on the CMake update now, hopefully pushing today. So don't build too far :)
<mb[m]1>Doesn't sound like it, my board has four cores and also uses 65 minutes (actually 64m54s).
<mb[m]1>Yay :) Haven't started building core-updates yet.
<efraim>Oh good, I was hoping I wouldn't have to do the cake one
<lfam>mb[m]1: I was curious about the Firefly since it has two different kinds of CPUs. I'd heard that those systems may only use one type at a time
<lfam>Basically for "mobile" use cases
<efraim>Building that pegs at 100% always hits 6.00
<lfam>Yesterday I learned that building Audacity is more complicated than I thought. They have patches on all their bundled libraries, and we don't delete the bundled libraries... so someone should try building it after deleting the bundled libraries
<efraim>I need to fix my macbook, most of the time at boot up the touchpad is wonky
<mb[m]1>I'll see if I can figure out what's going on with binutils 2.29.
<lfam>Specifically regarding Portaudio and Audacity. Audacity 2.2.0 (latest) fails to build against our Portaudio package. I saw a comment in Nixpkgs about "giving up on the portaudio patch". They are using the bundled Portaudio now
<efraim>I also wanted to see about adding grub menu items for the multiple rEFInd binaries
<lfam>So much to do...
<lfam>Speaking of GRUB, I like this idea:
<lfam>Currently, GRUB is basically the weak point of GuixSD bootability
<lfam>If you break GRUB, then you have to get your hands dirty
<lfam>But using that mechanism could improve the situation
<lfam>I didn't really look into it yet, though
<mb[m]1>It looks like it still relies on the generated config, so the main difference would be that it automatically switches to the previous generation.
<mb[m]1>Which is a nice touch still.
<ng0>the cmake is a lie.
<lfam>Right, at least your system would boot
<lfam>Heh, ng0 ;)
<OriansJ>ng0: cmake is simply for people who can't use make correctly
<efraim>Oops, 'sudo rmmod hid_apple' also killed the keyboard
<mb[m]1>Lol, what could possibly go wrong.
<lfam>Progress on CMake! I've got the list of failing tests ;)
<mb[m]1>`guix lint -c cve binutils` on 2.29.1 passes. Not sure if that's good or bad :P
<lfam>We should do upgrade net-tools-for-tests this cycle
<lfam>Especially since efraim said it didn't build
<mb[m]1>Maybe also ncurses?
<efraim>i thought ncurses is still at 6.0
<lfam>Yes, if there is a new major release or if somebody wants to figure out the patch releases. The patches are not patches, but shell scripts
<efraim>i know debian increases snapshots of it
<lfam>I looked at those "patches" and decided to take a walk ;)
<mb[m]1>There are weekly snapshots here:
<efraim>to keep the log i want 1>log.file ?
<lfam>Hm, are they really "code" or are they complicated folders full of scripts you have to run?
<mb[m]1>efraim: depending on the tool, you may need 2>&1 as well.
<efraim>for guix build
<mb[m]1>to capture stderr
<mb[m]1>efraim: Have you tried `guix build --log-file`?
<efraim>i haven't tried it for packages that fail to build
<lfam>I do `guix build foo 2>&1 | tee log`
<mb[m]1>The last "patch rollup" was 2017-10-01.
<efraim>ACTION heads off for a bit
<mb[m]1>I'll try to figure out how that shell script works.
<lfam>Now I also remember that there are problems with the ncurses server that distributes the patches, which causes corrupted downloads.
<lfam>I reported it upstream but the maintainer decided not to fix it
<lfam>So, another reason I gave up
<lfam>They tend to end up being gzipped twice, IIRC
<mb[m]1>Ah, common problem.
<lfam>It was overall very frustrating and I decided to punt
<lfam>Like, I just tried downloading a snapshot and the signature verification failed due to this issue
<lfam>But, we really should be using these patches. I'm sure there are important bugs fixed in them
<mb[m]1>"Due to continued abuse, this service has been disabled":
<mb[m]1>What's a good pastebin nowadays?
<mb[m]1>Wow, this ncurses way of distributing patches is....creative.
<lfam>Yes, quite
<mb[m]1>It's a uuencoded gzipped megapatch, distributed within a shell script.
<mb[m]1>Errh, with binutils-2.29.1, gcc-cross-boot0 fails the validate-runpath phase. efraim sounds familiar?
<ng0>mb[m]1: for example
<ng0>or grab the code of pb and deploy it elsewhere
<lfam>The CMake test 'SkipTest' fails spuriously. So, I guess we will need to skip SkipTest
<mb[m]1>lfam: Heh.
<mb[m]1>ng0: Thanks!
<lfam>Okay, I will finish CMake and deal with net-tools-for-tests. Hopefully today, but at least this weekend.
<lfam>What else do we want to do this cycle?
<mb[m]1>Yay. Maybe we can even start building on Monday.
<mb[m]1>lfam: gawk 4.2! Gettext fails a test with it.
<mb[m]1>I tried reporting a bug to the address, but got a bounce-ish reply back in French.
<mb[m]1>(for gettext)
<lfam>It went through:
<lfam>Shall we pick a deadline for updates? For example, if we can't figure out the binutils upgrade in time, we just patch the security bugs?
<mb[m]1>I don't understand how gcc-cross-boot0 ends up with an unqualified reference to '' with binutils 2.29. Is it not using the ld wrapper?
<mb[m]1>lfam: Sounds good.
<lfam>Which date?
<lfam>I can only handle CMake and net-tools-for-tests this weekend
<mb[m]1>Friday, maybe?
<lfam>Sounds good
<lfam>Do you want to email guix-devel to say that?
<lfam>I mean, will you? :)
<lfam>The CMake test DisabledTest also failed spuriously!
<mb[m]1>Lol, great.
<mb[m]1>Yeah I can send an update tomorrow with the tentative schedule.
<mb[m]1>s/tentative/totally set in stone/
<fusion809>Hey is there a way to test, in a shell script, which commit of the guix.git repository is the latest one that's been pulled with guix? Tried to answer this question myself by searching /gnu/store with find for what I know at the moment is the latest commit I've pulled but since it returned no files matching that hash I'm kind of stuck. Oh and I also ran grep to see if any file named "refs" was in /gnu/store and contained that
<fusion809>commit hash.
<mb[m]1>I wish the was a way to use --keep-failed without --no-build-hook.
<mb[m]1>fusion809: Does `guix --version` achieve what you are after?
<fusion809>Oh yes it does! Surprised it did, I thought it'd just say which version of Guix I've got installed, 0.13.0.
<lfam>I don't understand how to use <>. Where do I get the link to share?
<ng0>well you can use curl directly with it, I never used the web interface very much
<mb[m]1>Press the "short url" button maybe?
<lfam>The short url button creates a message that says "already exists"
<lfam>Anyways, the 3rd and final CMake test failure:
<ng0>lfam: by pressing "paste"
<mb[m]1>lfam: Rofl.
<lfam>ng0: I pressed paste. How do I share it now?
<ng0>oh course we could tell sudokode that the link should be displayed :D
<ng0>just a sec
<lfam>Apparently Debian's paste site is accessible over Tor. Maybe we can recommend that
<ng0>you see the blue bar with "status: created \\n uuid: … " right?
<ng0>the "created" contains the link
<ng0>it's an anchor
<ng0>maybe it would be good to print the link in addition to it
<ng0>there's also the command line interface to pb I packaged aeons ago and has since then be stuck because of cURL
<lfam>Ah, I see
<lfam>Another problem is that if I paste something non-unique, it doesn't even show the UUID / anchor URL
<ng0>what's non-unique?
<lfam>Like, if you put 'testing' in the box, you can't get a link
<lfam>Oh no, I'm wrong!
<lfam>It's there, in the "already exists" text
<mb[m]1>Good UX.
<lfam>Heh, well apparently you're supposed to use it from the command line. So I can't blame them for neglecting the GUI
<lfam>I'd say the UI (user intention) is incorrect ;)
<ng0>the pbwww is a different project
<ng0>it just happens to live there
<ng0>at least that's my understanding
<ng0>ACTION has aliases
<efraim>missing lambda _ line in acl on core-updates
<efraim>and a perl regex error
<janneke>ACTION attempts to hack rekado_'s $ORIGIN suggestion for gcc
<ng0>I think I should re-send the pbpst + tup patches, maybe we can find a solution 1 year later now
<ng0>lfam: <- status = link isn't very intuitive
<ng0>added 1.5 years ago… fixes welcome I guess
<lfam>Bah, I'll fix it shortly efraim
<lfam>Pushed, efraim
<mb[m]1>I wonder if we could start the 'core' package set on Hydra already, so that people who want to contribute to core-updates don't have to do the whole bootstrap thing.
<efraim>or at least the initial bit
<efraim>the 'core' set
<mb[m]1>In other news, looks like 'python-sphinx' is failing on master:
<emacsomancer>how do I enable ssh in on guix?
<emacsoma`>query: on guixsd, how do I enable ssh in ? (I can ssh out of the
<mb[m]1>emacsoma`: You'll need to add an SSH server service to your system configuration.
<emacsomancer>is there a model for this somewhere ? I'm just getting started with guixsd.
<mb[m]1>emacsomancer: See this example configuration file, which includes an SSH server:
<emacsomancer>thanks, mb[m]1 !
<efraim>Libxml2 2.9.7 is apparently out
<mb[m]1>efraim: uh-oh ;)
<mb[m]1>Smells like trouble.
<mb[m]1>So apparently gunzip/gzip -d cannot write the output to an arbitrary location, only redirect or unzip to the same directory.
<mb[m]1>So I'll need to "unpack" the ncurses patch in a separate derivation, or use pipes with Guile.
<emacsomancer>when I reconfigure the system using the configuration file, is it expected that it seems to go through downloading all of the packages again?
<benny>if the last generation of the system is old then sure, if you only add one service or one package then no
<mb[m]1>emacsomancer: Did you run `guix pull` in between?
<emacsomancer>mb[m]1: no, should I have done?
<mb[m]1>If you didn't, only the packages/services that has been added in the config will be downloaded/built.
<benny>oh sorry for the misinformation
<mb[m]1>Errh, the ncurses stable patch does not apply!
<emacsomancer>hmm... even after `guix pull` it seems to be rebuilding everything again
<efraim>am I supposed to run 'make' in a git-worktree?
<mb[m]1>Huh, it looks like the latest stable patch depends on the other stable patches, contrary to what the README says.
<mb[m]1>Okay, the standalone patch depends on the previous patches, but the "shell script" version works.
<efraim>i'm going to have to run guix gc after the core-updates merge, i'm down to 15gb on my firefly
<htgoebel>mb[m]1, lfam, g_borg: will not solve out problem. It introduces a new format for the .pyc-file header which can not be backported. So we still need a solution for python <= 3.6
<volhack>downloaded guix image for qemu, it's asking for gnu login. Unable to find anything in the docs, any help?
<TeMPOraL>found direct cause of my slow guix problem
<TeMPOraL>IPv6 issue
<TeMPOraL>guix-daemon tries to connect to an IPv6 address, and waits until timeout (after ~130 seconds)
<TeMPOraL>now the question is, what's broken with IPv6 on my machine and why :<
<mb[m]1>volhack: Try logging in as "root", no password should be required.
<OriansJ>janneke: do you perhaps know a more compact way to express ?
<janneke>compact in what sense? what does emit do? -- any reason for not doing 3 times a write/fputs "# Defining_" , label, "\\n"
<OriansJ> it simply builds the output list
<OriansJ>the only other piece involved in the formatting of output is
<janneke>OriansJ: what about strcat?
<OriansJ>janneke: that might work