<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>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
<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: <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_>g_bor: I think that’s reasonable. Would you like to propose a patch? <g_bor>What do you think about that? <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>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>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>yes, you should also need that to get anything meaningful. <TeMPOraL>oh, so you can strace a running process? great <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 paste.lisp.org, 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: paste.lisp.net has been disabled, can we recommend another tor-friendly pastebin? <janneke>eh, paste.lisp.org but they will know i guess <ng0>sorry didn't read the whole buffer >.< <ng0>ptpb.pw works (and installations of it (pb) elsewhere. <htgoebel>How can I make the guix-daemon in the installation-image to use berlin.guixsd.org? <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 <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 <htgoebel>lfam: So you mean "her start guix-daemon --substitute-url= should work? <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: 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>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>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>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>`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 <lfam>efraim: Does it use all 6 cores at once? <mb[m]1>But struggled with some new test failures. <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>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. <lfam>Right, at least your system would boot <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 <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 ;) <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. <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. <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 <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>What's a good pastebin nowadays? <mb[m]1>Wow, this ncurses way of distributing patches is....creative. <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 ptpb.pw <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 <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 @gnu.org address, but got a bounce-ish reply back in French. <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 'libstdc++.so.6' with binutils 2.29. Is it not using the ld wrapper? <lfam>I can only handle CMake and net-tools-for-tests this weekend <lfam>Do you want to email guix-devel to say that? <lfam>The CMake test DisabledTest also failed spuriously! <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 <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. <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" <ng0>lfam: by pressing "paste" <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 <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>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>Another problem is that if I paste something non-unique, it doesn't even show the UUID / anchor URL <lfam>Like, if you put 'testing' in the box, you can't get a link <lfam>It's there, in the "already exists" text <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 <efraim>missing lambda _ line in acl on core-updates <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>added 1.5 years ago… fixes welcome I guess <lfam>Bah, I'll fix it shortly 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. <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>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? <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 <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>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. <janneke>compact in what sense? what does emit do? -- any reason for not doing 3 times a write/fputs "# Defining_" , label, "\\n"