<marusich>I'd expect the release image to "just work"...I'm sorry to hear it isn't the case <reed_>No, I haven't added any software or services that weren't on the default <marusich>could you share the build failure output? <marusich>use the --on-error=backtrace option to "guix system" to ensure you get a backtrace, also. <marusich>A backtrace is additional debug information that can help explain the problem in some cases. <reed_>I have: sha256 mismatch for output path `/gnu/store/<long hash>-bzip2-1.0.6.tar.gz' <reed_>(there's more, I didn't mean to press enter yet) <marusich>No worries. That probably indicates that the release tarball for bzip2 changed recently. <reed_>expected: <longhash1> (newline) actual: <longhash2> (newline) cannot build derivation `/gnu/store/<hash>-bzip2-1.0.6.drv': 1 dependendies couldn't be build (newline) cannot build derivation `/gnu/store/<hash>-python-3.6.5.drv': 1 dependencies couldn't be built <reed_>same for python2-2.7.14 and curl-7.60.0.drv <reed_>okay, so you think if I run guix pull first, I'll get the right tar downloaded? <marusich>Yes, but the trick is...where to get that? <marusich>When Guix builds bzip2, it is trying to fetch the source. A package definition exists (you can see it by running 'guix package edit bzip2') that tells Guix where to get the source release tarball for bzip2, among other things. <marusich>That package definition contains a line like (sha256 (base32 "...some long value...")). <marusich>This tells Guix that the content is uniquely identified by that long value, which is a sha256 hash of the contents. <marusich>Most likely, the people who own the bzip2 source release tarball have uploade a new version on top of what existed before. <reed_>ahh, without changing the uri? <marusich>Or, something else happened, like the release tarball is no longer available, and maybe guix is fetching a webpage that says something like "sorry, this doesn't exist any more" <marusich>It happens from time to time, although it's not great practice. <marusich>Because Guix enforces the content to be identical, it fails the build, as it should. <marusich>You can solve it in a variety of ways. For example, like you said, if you can find a copy of the file somewhere, you can use it. <marusich>Some Internet searching shows that the bzip2 website expired recently... <marusich>If it is, it will have the same content hash, and then the bzip2 build required for "guix system init" will work. <marusich>If it isn't, it will sit in your /gnu/store, but it won't be used. <marusich>And if it isn't used, it will be cleaned up automatically when you next run "guix gc". <reed_>okay. If I rerun guix system init, will it pick up where it left off? because it took me about 5 hours to get to this point <marusich>When you tell Guix to install or build stuff, it keeps the build results around a least until you run "guix gc" <marusich>So, every build that succeeds will not be lost. <marusich>If you can type something like "guix build /gnu/store/...some long hash...-bzip2-1.0.6.drv" it will build just that derivation <marusich>I.e., you can tell Guix to build just bzip2, to test if it works, if you know the path of the derivation that it was trying to build. <marusich>In Guix, a "derivation" is a description of exactly what must be done to build a piece of software, and they are represented in the store by .drv files. <marusich>to "build" the software means to "run" (or "build") the derivation <marusich>So you can either run "guix system init" and let it pick up where it left off. Or you can run "guix build /gnu/store/...-bzip2-1.0.6.drv" if you know its path. <reed_>when I tried to run the "guix download command" it failed with: X.509 certificate of 'web.archive.org' could not be verified: (newline) signer-not-found (newline) invalid <lfam_>reed_: Is it on GuixSD or are you using Guix on another distro? <reed_>with a freshly downloaded iso <lfam_>You are using the installation image? Or the QEMU / VM image? <lfam_>Hm, well that's a bug in the installation image, but you can work around it. I recommend changing the URL to use 'http' instead of 'https' <reed_>that worked to get it to download. I'll report back if the "guix system init" command succeeds or fails <lfam>I'm still here as lfam, btw :) <lfam>I'm surprised this tarball isn't found on the Nix mirror. It makes wonder if our Nix mirror download code is still working as expected <reed_>haha okay. About 6 months ago I installed GuixSD and while the initial install took a while, I feel like it is taking longer this time around, which makes me think that I'm building a lot more from source. So perhaps that's evidence that something is wrong with more downloads <reed_>but I'm new to this, so I have no idea <lfam>reed_: You're right, you are probably building more this time. The installation image looks for "substitutes" (prebuilt packages) at mirror.hydra.gnu.org, but hydra.gnu.org is currently offline due to a suprisingly slow storage migration. Normally you would have downloaded the bzip2 source code from mirror.hydra.gnu.org and would not have noticed that bzip.org is offline <lsl88>verisimilitude: : thank you anyway :) I will try to figure it out. Or at least if I submit a patch mention that I was not able to build it for some formats for reasons that belong to magic <reed_>lfam: ahh, that makes sense. Is there an expected date for hydra.gnu.org to be back online? <lfam>reed_: There is an alternative official substitute server at <https://berlin.guixsd.org>. You could try using it by adding '--substitute-urls=https://berlin.guixsd.org' to the commands you are running. You would need to authorize that signing key as well. I'm checking now to see exactly where the key is in the installer, and if it's possible to authorize new keys in the installer (some parts of the installer's file-systems are read-only, <lfam>reed_: The current estimate is Tuesday November 6 on the USA east coast <pkill9_>i think the signing key is already authorized in guix by default now, I might be wrong though <lfam>I think it depends on the context but let's find out :) <lfam>Well, the key can be found at '/run/current-system/profile/share/guix/berlin.guixsd.org.pub', and to authorize it you do `guix archive --authorize < /run/current-system/profile[...]` <lfam>reed_: If you add the argument '--substitute-urls=https://berlin.guixsd.org' to your installation command, and you authorize the key (may need to `herd restart guix-daemon` after, not sure), then you can get substitutes from that server <lfam>That should save you time <reed_>lfam: okay, if it doesn't finish in the next 30 minutes or so I'll give that a try <reed_>lfam: that seems to have some effect, it's now updating substitutes to the berlin url <lfam>Good, that will save a lot of building. In the installed system, you'll probably want to add berlin to the default, by re-authorizing the key and editing the Guix service <lfam>It's relatively inefficient to use both servers as in the example, but that's how you'd do it <lfam>The dbus, gpm, ntp, wicd services are extraneous to using a custom Guix service, btw ***jonsger1 is now known as jonsger
<apteryx>ah, guix-copy s/defaults/forces/ port 22 when we use the .ssh/config 'host' name only (and that host defines an alternative port number than 22). <apteryx>it was introduced by commit cc1dfc202f. <ng0>I don't have much time and will be off soon, but in my observation of the last couple of days with other people, Shepherd improvements like decent normal logging etc should be a GuixSD 1.0 requirement. init1 is one of the main aspects people look at when managing systems. because we provide no alternative, like OpenRC OR shepherd, making shepherd "production ready" should be a goal for claining SD is 1.0. <ng0>Otherwise SD should move at different versioning than Guix itself. <divansantana>Guessing this is a known issue? Anyone have the workaround or email thread on hand? <jonsger>divansantana: mirror.hydra.gnu.org is still down, due to ongoing maintenance work on the server <g_bor>I am trying to reproduce this python-minimal leak on core-updates, some observe the problem, some not. I could not reproduce it so far. <roptat>but I didn't observe the leak on master either <g_bor>roptat: do you think that it is possible, that the problematic code does not exist in linux-libre? <g_bor>Maybe we should have a look at that protocol implementation in the kernel... <g_bor>I only got one report from guixsd, but there is a linux kernel in use. <g_bor>Also, I can reproduce the test failure of nss. <g_bor>hello snape, I see some interesting things when I run guix weather. <g_bor>It seems that the api consistently 504-s. <nlyy>Hi guix :-). In guix/ui.scm canonicalize-path cannot resolve paths opened with tramp in emacs, something like this "C-x C-f /sudo::/etc/guix/system/configuration.scm" <nlyy>then "M-x geiser-compile-current-buffer" returns an error <nlyy>ERROR: In procedure canonicalize-path: <nlyy>In procedure canonicalize-path: Wrong type argument in position 1 (expecting string): #("/sudo:root@uf:/etc/guix/system/configuration.scm" 6 10 (tramp-default t)) <nlyy>0 (canonicalize-path #("/sudo:root@uf:/etc/guix/system/configu…" …)) <g_bor>I have a bit of a problem here. <g_bor>We got two last minute contribution to our Outreachy project, without any previous communications. <g_bor>I should give them a video upload target, but this got me unprepared. <g_bor>I believe we should not lose these contributions. Where should I direct them to upload? <nlyy>(if they don't mind using google services that is :) <snape>g_bor: I don't think it's intentional :) <kristofer>I've been attempting to use the berlin server for substitutes. I'm unsure what's up, but I keep running out of memory during guix system reconfigure -- while building python-minimal-3.6.5. I have 4G memory and currently a 24G swap file, still will not build <nlyy>I can 'guix publish' if you'd like? <nlyy>guix (GNU Guix) a46c00a3d8a45e0390fc5e5fd18c74000550554c <nlyy>I am on this commit so idk how much you can substitute... <g_bor>krsitofer: this is a known problem. Are you on a foreign distro? <efraim>What's the filesystem for /tmp? HDD or ssd? <kristofer>guix (GNU Guix) 64eb038eef41dc7c1f912dc7097aa53e8b5d8b7c <jonsger>kristofer: did you tried using `guix system reconfigure --cores=1`? <jonsger>that could help here, because building with more cores requires more RAM/swap... <roptat>kristofer: did you authorize berlin? <demotri>g_bor: Sorry, have to go to launch now :-(. I have two more candidates in the pipe. I nearly finished an email to you, will send that out now, we can discuss later and/or by email. <hotsieflotsie>Guix pull complains: Migrating profile generations to '/var/guix/profiles/per-user/root'... <hotsieflotsie>guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/root/current-guix-1-link" <pkill9_>not sure, but a lot of people have had that issue i think <Gamayun>I have a problem with my fairly freshly reinstalled GuixSD - both ethernet and wifi devices appear unavailable to NetworkManager... Anything been changed? <dustyweb>substitutions from berlin are suddenly failing <nly>guixSD has become harder to use without hydra.gnu.org <nly>In particular, i cannot build anything with python, rust, qt, gtk <dustyweb>nly: other mirrors don't have the substitutes for those I guess? <civodul>nly: indeed, the recommendation is to use berlin.guixsd.org <civodul>now berlin.guixsd.org is becoming short on disk space :-/ <apteryx>w.r.t to the substitutes problem, it has at least the merit of raviving my itch to get a P2P substitutes sharing system going :) <roptat>btw, how do I send and receive UDP packets in guile? <jonsger>civodul: do we need larger hard drives for berlin? <ng0>civodul: I think the webview for your sqlite3 disappeared or did you move it? <ng0>then we should change the displayed homepage. <ng0>unless it was changed recently and I'm just behind with guix pull <bavier>would a dyndns service help to make it easier for people to 'guix publish' their stores? <bavier>that service could maybe also double as a mirror <ng0>we can't even get sources via HTTPS_PROXY because we only have HTTP_PROXY. you have to do this at firewall level. so, no, no HS. <bavier>I'm thinking something like what yunohost provides for people during installation <bavier>they can choose to set up dyndns on a subdomain of nohost.me, e.g. <nly>P2p would be awesome <nly>I have setup a dyndns in case i have to share substitutes with 'guix publish' <bavier>nly: cool. yeah, there's certainly existing dyndns services that can be used; having one specifically for 'guix publish' might just help reduce some friction <bavier>imho; I haven't thought it through a ton <roptat>a dyndns service would be great :) <civodul>ng0: yeah i "migrated" it but notabug did not create a redirect :-/ <ng0>you could ask the admin / community if it doesn't succeed. they are okay <civodul>jonsger: "we" (ie. rekado's employer) actually has them, but there are troubles with GRUB support IIUC <civodul>i think g_bor looked into it as well <vaab>Hi all. Looking for some clue on a newbie question. I'm setting up offload. I have a password less ssh working well. I did set GUILE_LOAD_PATH on builder so that ``ssh $BUILDER guile -c "'(use-modules (guix config))'"`` is not failing (no output)... but ``guix offload test`` is still failing about "Guile modules not found on remote host". What did <vaab>I overlook ? Sorry for the newbie question. <civodul>vaab: perhaps you need to kill the running 'guile' process on your machine before rerunning 'guix offload test' <vaab>@civodul: thanks, it took some time... but did fail again the same way. <vaab>@civodul: ok, did it a second time with some other changes (related to some things I tried but that are not that interesting). And it passes now. So this was it... . Thanks a lot ! <janneke>sneek: later tell civodul: i stumbled upon guile-2.2-default-utf8.patch, which makes bootstrap-guile behave differently from normal guile; can we think of another, more compatible way of achieving what the patch tries to achieve? <g_bor>It seems our cert is expired. <g_bor>(bayfrontm irc logs download says certificate expired on 30th Oct) <g_bor>I am getting some errors here, most probably form a store corruption. <g_bor>One of the errors is can't get information from store item ... <g_bor>I see that there is no such item in the store, but there is a .lock corresponding to that item <demotri>g_bor: concerning store: Have you tried the repair options of guix gc? Can't remember the details, but see manual. <g_bor>demotri: I've sent you a private message <davidl>How can I see if a package has been built on berlin.guixsd.org? <g_bor>you can see it using guix weather <davidl>g_bor: it says computing 8,605 package derivations for x86_64-linux... <g_bor>last time I did that I created a manifest file, seen in the guix package section of the manual containing only the package I was asking for, then guix weather -m manifest-file-here --substitute-urls="..." <g_bor>If oyu are only interested in a few packages you have to pass a manifest. <davidl>.0% substitutes available (0 out of 8,954) <davidl>where do I report a failed build? <davidl>I unzipped the log output of my failed webkitgtk build and the last 100 lines or so seems relevant for debugging. <g_bor>you can create a bug report by sending an email to bug-guix@gnu.org. <g_bor>please also state the verison of guix in use, and at least if this is on a foreign distro. <g_bor>Also, did you specify berlin in the substitute urls of guix weather? This number does not seem realistic. <davidl>I first specified hydra, but then berlin. And berlin doesn't appear to have my needed package. <g_bor>I've also seen some interesting artifacts today on berlin, but I am on core-updates guixsd, so it might be not representative. <davidl>g_bor what do you mean artifacts? <lsl88>mbakke: thank you! I will take a look at that :) <lsl88>mbakke: is it available in other formats too? I mean, where do you access from guix webpage? I mean if I go to https://www.gnu.org/manual/manual.html and I navigate until Guix in English, there are different formats: html, html separated from nodes, plain text, and so on. And when I inspected the page source I'm affraid that all links are for html_node, which return 404 <mbakke>lsl88: Do you mean that formats other than HTML are broken? <g_bor>Actually make shoudl update the guix.info in you source tree. <lsl88>mbakke: and taking a quick look at the view-source guix.info and the gnu.org/software/guix webpages, I don't know very well why the site changed, but if you click download, even the installation manual keeps the same - not the one provided by guix.info <g_bor>davidl: for example the api 504-s on berlin. <g_bor>It does so quite consistently. <g_bor>We discussed it with snape, it seems to be not intentional. <dorfsmay>I'm trying to install guix on a Ubuntu server, but the install shell fails because missing a gpg key, then I run a gpg command as instructed to import the key but get "no data" <dorfsmay>gpg --keyserver pgp.mit.edu --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 <lsl88>mbakke: the link you have just sent me has only the long HTML file, no other formats available. And if you click or inspect guix.info webpage with your browser, all the references to the manual are with html_node and then clicking them returns therefore 404, not found <g_bor>lsl88: also sometimes make pollutes the source tree with newer version of the translated files, you can get rid of those modifications by doing git checkout filename. <mbakke>dorfsmay: pgp.mit.edu may be down, you can try an alternative server such as keyserver.ubuntu.com. <g_bor>dorfsmay: You can also just not specify the keyserver, then it will try the default. <g_bor>lsl88: it seems to me that from guix.info site only the html format is available. <g_bor>What are you trying to achieve? <lsl88>g_bor: I tried several steps: inspected the Makefile, to see if there was a target for the documentation only, and ran make doc/something, ran make without any params again without seeing any changes at all, still was getting the error related to the .info file, made a backup copy of my guix.texi and copied the clean doc/ directory that I have from an untouched cloned repo, and ran make again, and replaced my guix.texi with my cindex <lsl88>g_bor: The answer to your question is: I added just a few cindex and wanted to create all the documentation in all available formats that are shown in the manual's webpage <dorfsmay>Does guix manages its own set of packages? Or can it manage a distro (say ubuntu) native packages? <pkill9_>no it only manages it's own packages <dorfsmay>Ah. Is there a list of packages available? Is it the same as availaible on guixSD? <vagrantc>hey folks! trying to package pyelftools, and i've got it working: https://paste.debian.net/1050493 but guix lint complains that it shouldn't have python-setuptools as an input ... if i remove python-setuptools from native-inputs it fails to build <vagrantc>or, more specifically, the test suite fails <civodul>vagrantc: looks like 'guix lint' is wrong in this case :-) <civodul>perhaps leave a comment explaining that some module of setuptools is needed by the tests <janneke>sneek: later tell civodul: i stumbled upon guile-2.2-default-utf8.patch, which makes bootstrap-guile behave differently from normal guile; can we think of another, more compatible way of achieving what the patch tries to achieve? <janneke>hi civodul -- /me played for sneek, just missed you earlier <civodul>janneke: i don't know if we can do something smarter than this patch, maybe we could! <civodul>perhaps with 2.2 it's not really needed, not sure <pkill9_>does it not use python-setuptools automatically when using the python-build-system? <janneke>the patch tries to work around ...something iconv... but in the process it changes ports that are binary by default to utf-8 <janneke>ah -- on wip-bootstrap i have switched to guile-2.2 anyway, because gash needs PEG <pkill9_>as in, doesn't the python-build-system add the python-setuptools input automatically? *civodul needs to catch up on Gash (among other things) <civodul>pkill9_: something like that, i forgot the details why this lint check was added <civodul>janneke: alternately i think libc has an option for a statically-linked gconv <janneke>rutger has been hacking on gash all weekend to completely overhaul the peg parser -- i hope we can do a 0.2 release some time soon. i have added some bournish builtins <hulten>Laalf: It appears that 'guix gc' doesn't need root rights (yesterday discussion). <hulten>But the command does save quite some space, thanks :) <lfam_>Is anyone else having problems `make`-ing Guix due to issues with the translations? <lfam_>make[2]: Entering directory '/home/leo/work/guix/po/guix <lfam_>make[2]: *** No rule to make target 'all'. Stop. <lfam_>Hm, looks I need to bootstrap again. Not sure what went wrong... <mbakke>lfam_: That is typical when some of the build files are corrupt, e.g. local.mk. <lfam_>mbakke: Turns out I was missing all the build files in 'po/' <Laalf>does anyone use gnustep as his desktop environment? <Laalf>i saw it has been packaged. i dont see a service for it though <civodul>Laalf: GNUstep itself hasn't been packaged <civodul>it's just a tool along the way that's been packaged <civodul>dustyweb: i just read your Goblins post from last week and really enjoyed it! <civodul>it got me thinking about things like Guix's SPKI-inspired ACL and how we could improve on that <bavier>foiled by webengine once again :( <bavier>got OpenShot all packaged up, but it needs PyQtWebEngineWidgets <mbakke>I started packaging QtWebEngine a while back, but got distracted. <mbakke>It's difficult, but not insurmountable. <brendyyn>|guix system: error: build failed: | | | bind mounting `/dev/full' to `/gnu/store/xhvqpmb85qhcv8613sgjcgd0bbvb9lbh-polkit-0.115.drv.chroot/dev/full'