<nckx>Does anyone have /gnu/store/q81fsxf2wbd3qpbv2v9i10whrgcahxjc-libcxx-7.0.1.src.tar.xz ? ***schematico is now known as sync-q
***amiloradovsky1 is now known as amiloradovsky
***Elon_Satoshi is now known as Copenhage_Bram
<vagrantc>ok, have a variant linux-libre 5.0 running on the c201/veyron-speedy! ... without patches, just a different config <vagrantc>seems feasible to get it to work with the regular linux-libre package now... <civodul>mbakke: did you see my message here regarding Python test failures on core-updates? <civodul>the new Helm somehow changed 'ffap' such that now it tries to scan the parent directory <civodul>so if you do M-x ffap on a /gnu/store/foo file name, it apparently scans /gnu/store <civodul>i end up doing M-: (find-file ...) but that's inconvenient <roptat>how was the guix logo created in the install script? <civodul>otherwise there's a command-line tool in libcaca IIRC <rekado_>roptat: I forgot. I used software for converting it, but I don’t recall how. <rekado_>then later copied it to the installer script ***Guest6698 is now known as sturm
<efraim>There might be something wrong with my ietf channel, I have RFC14 but checking online that number wasn't issued <efraim>I hope that one has been deprecated <nckx>[Standards-track] Who's having sandwiches on Friday? <nckx>Did you figure out the deal with RFC 14? <ng0>is the patches queue and backlog big this time? wondering if anyone will pick up my 5 patches series from last week <efraim>nckx: the text of the RFC downloaded says "RFC 14 was never issued" <efraim>with almost 8600 possible RFCs I'm going to have to insert notes in appropriate places <nckx>efraim: I didn't realise you made the selection. I though IETF had a tarball or something. Cool. <nckx>ng0: Backlog is always an issue… The cover letter sounds very ‘this will require allocating a large contiguous region of time’ too. <ng0>actually the major time consumption there is probably gnunet+gnunet-gtk, the preceding patches are no-brainers if they still apply. <civodul>rekado_: congrats for Evolution! i just noticed <civodul>so it turned out to be less frightening than we thought? <nckx>ng0: Well, I wasn't talking about the first two ;-) I'm guessing those aren't the most important/urgent ones, but if you want me to push those on their own I can. <ng0>they are independent of the last patch. So if you want to, yes <rekado_>civodul: yes, it just hadn’t been done. <rekado_>I’m sure there’s more that can be added to Evolution, but the base package should be fine. <rekado_>I’m rebasing wip-gnome3.30 *again* on top of staging. <rekado_>letting these two gnome branches sit idle for so long was a big mistake <rekado_>lots of patches that I finished months ago have already made it into staging or master, and now the merge is just extremely painful. <rekado_>ng0: I looked over your patches but since the last one is unfinished I decided not to work on it. <rekado_>I always prefer finished patches over WIP. <ng0>ok. next time I split the patches <civodul>rekado_: re wip-gnome3.30, i agree, i think we did badly, in part due to poor tooling that makes (made?) it hard to find out what the status is <civodul>hopefully 'guix weather -c' helps a bit now <efraim>So gnome3.30 is our next 'big branch' for merging then? <rekado_>should be gnome3.30, not wip-gnome3.30… eeh <rekado_>yes, gnome3.30 should be merged soon after staging. <rvgn-net>Wow! What a co-incident. I was just asking GNU IRC channel that whether Rust is better than C. Now, I see something getting blovked by Rust. XD <rekado_>roptat: the “modules” directory needs to be added to the load path manually. <rekado_>I think you could also use “-L” or similar <roptat>weird, I created a (config services) module, and imported it in my configuration file, but guix says that it can't find my-services (exported from (config services)) and that I should add (use-modules (config services)), but that's already the case... <efraim>GUILE_LOAD_PATH=/path/to/custom/modules:$GUILE_LOAD_PATH guix system ... <roptat>the issue was that there was an error in (config services) <roptat>but the error is badly reported :/ <roptat>can I create a file-like object that's the concatenation of multiple files (like local-file, but with multiple files)? <quiliro>going to libreplanet? i do not see any talks about guix on their schodule <quiliro>i am not going...but i always dawload the talks <quiliro>白い熊 ... these characters do not display on guixsd's icecat <quiliro>but i can see them well on emacs' erc <rekado_>quiliro: you may need to install a font that provides glyphs for these characters. It shows up correctly in my icecat. <nckx>quiliro: Same here. You're just missing suitably Unicode/CJK fonts. <quiliro>How do i find out what font is missing and what package I need to install? <rvgn>Hello! Do anyone had issues with Gajim? <roptat>quiliro, try "guix package -s CJK" maybe? <nckx>quiliro: Noto is an example of a font that aims to provide ‘everything’. I don't know where you'd learn more about fonts in general. <roptat>I think I use font-adobe-source-han-sans <nckx>You'll get colour emojos in your terminal, so be warned. ;-) <quiliro>nckx: font-google-noto? no worries about google? <nckx>quiliro: Worries? I'm no fan of Google, but what's there to worry about? <nckx>quiliro: The former. All fonts are prefixed font-. <nckx>(Unfortunately there's also font-util, which isn't a font at all, but that's the way it is…) <nckx>quiliro: I actually Install All The Fonts! once (guix package -A ^font- | grep-v font-util | cut -f1) and don't worry about them. <quiliro>nckx: cool...i am worried about google's control over all of us <quiliro>don't be evil...but control everyone...something of the sort of telling us what is good for us <quiliro>i guess steve jobs in all his authoritarianism did not comply <nckx>quiliro: Then don't install Google fonts. 🤷 <nckx>I think those fonts are about the least evil thing they do to be honest. <nckx>Now when they fork Unicode… <nckx>You don't have to convince me to dislike Google, don't worry. <efraim>rekado_: blasr is missing a home-page <quiliro>this cut left package installation via emacs-guix at the middle of a download <roptat>"this cut left package installation via emacs-guix at the middle of a download" is the last message from you <quiliro>i see fonts-google-noto is half a giga <roptat>(apart from the one asking whether we read you :p) <roptat>they include every possible character, so it's not surprising <quiliro>sometimes i get 1 second ping to my access point <quiliro>so the download is taking an enourmous amount of time <quiliro>what happens with erc on emacs when there is no link...it waits until there is a link for sending text? <quiliro>but received messages i suppose thy get lost <roptat>it's tcp, so it depends if it times out I guess <quiliro>mail.riseup.net is possible to read on emacs without downloading? <nckx>quiliro: [non-authoritative content] I don't think any Emacs browsers can handle RoundCube. I see they have a SquirrelMail fall-back option, though. That might work. <nckx>Simple Scan doesn't save its preferences or print any warning of that to the console. Is that a GNOME thing? <rekado_>could you trace it to see how it tries to store preferences? <rekado_>I’ve seen this behaviour in other packages before. <rekado_>Some end up using a dconf memory backend and thus don’t persist their configuration changes. <civodul>when that happens you have a GSettings warning saying that it's using the "memory" backend <nckx>Only the classic ** (simple-scan:6374): WARNING **: 17:01:36.836: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files <quiliro>nckx: emacs eww does net open riseup with squirrelmail <rekado_>nckx: can you tell us something about the preferences that you are trying to save? <nckx>quiliro: Then I suppose you're out of luck. <nckx>rekado_: Just bumping the ‘Photo’ resolution from ‘300 (default)’ to 600. <rekado_>nckx: it might be helpful to see the trace with “-s 2048” to catch the contents of the settings. <quiliro>hi again...on emacs-guix is there a way to continue download of package when the connection is broken <quiliro>when i re-establish the connection, the download does not continue <quiliro>and when i close the repl, it will start from 0 <quiliro>i clicked again on the link to install font-google-noto on emacs-guix <quiliro>(process-package-actions "/var/guix/profiles/per-user/quiliro/guix-profile" #:install '((39295424 "out")) #:upgrade '() #:remove '() #:use-substitutes? #t #:dry-run? #f) <quiliro>but will not progress on the download as it did before <nckx>rekado_: Thanks for the tip. And lo: “write(6, "[+0.00s] DEBUG: simple-scan.vala:674: Starting Simple Scan 3.24.1, PID=7373\n[+0.86s] MESSAGE: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications…” <nckx>I guess printing that to the console would be too distracting 😒 <nckx>(Trace file updated in place (oof), but I guess this is a known problem?) <rekado_>it is a known problem, but I don’t remember if we have a bug report about this. <rekado_>I wonder if this could be fixed by setting an env variable that points to the other gsettings backends. <rekado_>you could try to set GIO_EXTRA_MODULES to $(guix build dconf)/lib/gio/modules <quiliro>It just shows a square with 6 numbers in it <quiliro>i pasted it on the terminal and it shows...but not on emacs <nckx>rekado_: Thanks. But it does nothing ☹ <nckx>quiliro: So earlier you had better CJK support in emacs than elsewhere, but worse emoji support? Choose your poison, I guess. <nckx>WARNING: failed to commit changes to dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files <rekado_>nckx: that’s better than before, though. <rekado_>share/dbus-1/services/ca.desrt.dconf.service is provided by dconf <lsl88>hi guix! don't know if I should write here or by mail. I was guix pulling my teenager computer, where i had guix 0.15.0 installed. I added the --fallback in the end, and I will show you what I am getting, but it ends in "send the bug to the list" <quiliro>i will try to install from the terminal...i was not successful with emacs-guix <rekado_>so I guess you “just” need to make sure that this directory is listed on some environment variable that tells dbus what services it can start. <rekado_>lsl88: then you better send it to the list :) <nckx>rekado_: Am I missing some search path integration by setting GIO_... directly? I'll try installing it into my profile. <quiliro>lsl88: on old computers compiling is very slow *nckx runs the ‘dbus-launch --exit-with-session ssh-agent i3’ desktop environment. <lfam>Wasn't there some intermediate commit that had to be pulled from when going from 0.15.0 to 0.16.0? <quiliro>lsl88: you should wait a week or two after 'guix pull' for binaries to be ready in order to avoid using --fallback <lfam>I think a couple hours for most packages, maybe 6 hours at most <quiliro>the basic packages are available at most after 1 day <lfam>Anyways, it's not relevant to lsl88's issue <nckx>quiliro: I don't doubt your lived experience but that sounds like something's very wrong somewhere. It should never take 2 weeks. <nckx>quiliro: Packages aren't prioritised in any way. <quiliro>nckx: i have been ok with 2 weeks...but have not been ok with 6 hours <quiliro>nckx: they are compiled when someone asks for them <rekado_>you may be thinking about substitute archives that are baked when requested. <nckx>They are compressed and cached (called ‘baking’) the first time someone requests them. <quiliro>i had been thinking that was the reason i had to --fallback many times <lsl88>rekado_: but maybe I am doing sth wrong. I was pastedebian it on my machine to send it. <quiliro>so you mean the substitutes are available but are not cached? <quiliro>what difference deos that make for the client? <rekado_>lsl88: it may be easier for us to investigate things when all information is available in one email. IRC isn’t great for this kind of thing. <quiliro>and why was i told they were not available? <rekado_>quiliro: when an item isn’t cached you get a 404; it’s baked in the background and ~5 mins later you can usually try again. <nckx>quiliro: The first person to ask for a substitute that has already been built will not recieve it. It will be compressed in the background. When it is ready, all requests will succeed. <quiliro>(not available because no one had requested them) <nckx>But that takes minutes, if that, not hours. *nckx never got that system but it's not my farm and not my monkeys. <lsl88>quiliro: yes, it didn't take that much. I first tried the guix pull, then I changed the substitutes for the new one, got the same error in both cases (sorry for not specifying it, will run guix pull again, with anything else, and write back), so ended up adding the fallback <quiliro>why ask the user to --fallback then?...the message should be to wait 5 minutes *rekado_ isn’t a fan of the initial 404 because it hurts the first person to download something <nckx>I'm sure there's a reason not to transparently compress and cache (I do this and it runs at severeal KiB/s on mediocre hardware). Still much better than a cache miss and a local build. <nckx>quiliro: That would be misleading. It needs to be fixed properly on the build farm, not guessed at by the client (which prints that message). <lsl88>if it takes that much time, then something is breaking really at the beginning <quiliro>ok...new info...will never --fallback again with my core2duo...it takes days <lsl88>will run guix pull again, and send both outputs, but maybe it is sth that I don't know or have not configured well <nckx>quiliro: The only place I use --fallback… is on my build farm :-p <nckx>there's also a local narinfo cache on your machine <nckx>the TTL for that might be much higher than 5 minutes <quiliro>but even without --fallback , a core2duo is not aideal for guixsd <nckx>causing Guix to report ‘no substitutes’ without checking upstream where they do actually exist. <nckx>Ah! Installing dconf into my profile says: The following environment variable definitions may be needed: export GIO_EXTRA_MODULES="/home/nckx/.guix-profile/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES" <nckx>So that, at least, is integrated already. <lsl88>quiliro: so you mean that I shouldn't have guixSD on that machine? except for the guix pull i can use it without any issues <nckx>And behold, my settings are saved. <rekado_>nckx: obviously, this is a terrible default situation. <rekado_>can we add dconf to the desktop packages? <nckx>rekado_: I mainly blame simple-scan for not printing to stdout. <nckx>But yes, this can be improved. <quiliro>lsl88: i use it on old machines, but it is not very fast to install packages...it is a pain <phenoble>So I'm fairly certain to have found an issue involving the gcc toolchain, the c++ stdlib package, and c++17 in guix. <nckx>Sounds extremely plausible. <quiliro>my take on my old-machine situation will be to offload on another newer machine to install somewhere on the internet <phenoble>g++ snippet.cpp -std=c++17 -o out && ./out *nckx installs gcc-toolchain. <quiliro>lsl88: maybe you can install the guix package on a newer machine to make the offloading possible on your older machine with GSD <quiliro>lsl88: please do not avoid GuixSD...even on that old machine <rekado_>quiliro: AFAIU lsl88 does not have problems building packages, but cannot upgrade from 0.15.0 <lsl88>quiliro: I have as a package manager in the computer that I use for working. That was an old machine that, for my surprise, runs guixSD without issues *Digit loves guix for freedom being considered most important <rekado_>lsl88: I’ll take a look at your problem if you can send all relevant info to the mailing list. <lsl88>rekado_: exactly, I just can't run a successful guixpull <rekado_>I’ve previously made the upgrade from 0.15.0 and it’s a little unconfortable. <nckx>phenoble: No problem. But could you paste that snippet someplace where I don't have to accept an EULA? :\ <quiliro>lsl88: well running is ok for me...installing has been a pain...but liveable <nckx>‘Thanks for your interest in what Compiler Explorer does with your data.’ <nckx>Believe me, I have none. <lsl88>rekado_: shall I send, don't know, lshw command output, guix pull output, guix pull -l output, and this one with fallback? I am running again guix pull, only to copy where it fails. It will take a little longer than right now. <rekado_>just the full error message, the commands you executed, and the version of Guix. <nckx>phenoble: λ g++ snippet.cpp -std=c++17 -o out && ./out → 10 <nckx>(λ is just my silly bash prompt.) <quiliro>lsl88: did you try to update guix on root? then the daemon will update first <nckx>This is in my regular (non-pure) environment after ‘guix package -i gcc-toolchain’. <phenoble>nckx: um, actually, today this compiles on my machine as well <phenoble>And that lsp-server that I spent 2 hours to get it to build using guix yesterday - now compiles as well. <lsl88>quiliro: I didn't, will try that. Maybe that was the issue. With the normal guix pull but changing substitutes? (recall that it has the hydra by default) <nckx>phenoble: :-D I'm… sorry? I wish I had worse news. <phenoble>nckx: anyhoo, thank you for the quick install <quiliro>what i mean is to login to root and 'guix pull' <lsl88>but I will write down all the steps and full commands and outputs - the relevant part - because maybe even if solved it helps for oldies like mine's. The OS, except for that, works great <quiliro>lsl88: then try guix pull on the user <rekado_>quiliro: what is this supposed to accomplish? <lsl88>quiliro: I have aready done it, exit status 1. I am running it again to get what makes it fail <lsl88>quiliro: after having that, will try your suggestion on root <nckx>I haven't been following, but this isn't GuixSD, right? <quiliro>lsl88: you said it was guixsd, right? <nckx>quiliro: Then please don't advise people to log in as root and guix pull… <nckx>And it certainly doesn't ‘update the daemon’. <lsl88>quiliro: yes! it was installed with the previous version on that machine <lsl88>I have a really simple installation I want that machine to play with GuixSD and also to do basic stuff like browsing the internet <lsl88>I can install, remove packages, generations, and so on. <nckx>phenoble: I tested it in a --pure environment just in case (nothing but gcc-toolchain & bash), but still success. No idea what was wrong yesterday. <quiliro>nckx: What? I don't understand then! I have been told to 'guix pull' root first so the daemon is updated <nckx>quiliro: Are you running GuixSD? <quiliro>except that my access point is intermitent <quiliro>but that has nothing to do with guixsd <nckx>quiliro: No, I just wanted to know because it might make sense to do that on a foreign distro. <nckx>guix pull && sudo -E guix system reconfigure … is the way to update the daemon. <nckx>(Well, there's also ‘herd stop guix-daemon’ && run it manually, but I digress :-) <nckx>quiliro: On a foreign distribution, the guix run by systemd or whatever is indeed root's guix. On GuixSD, it's the *system's* guix, not root's. Root is just another user. <nckx>Running ‘guix pull’ as root will serve no purpose other than to create a confusing Guix profile for root that 99% of people will never use. <nckx>And then wonder why ‘sudo guix’ (when they forget ‘-E’) subtly borks their system because it's using root's guix and not their user's. <nckx>And root's Guix is 2 years old. <nckx>TL;DR: dont sudo guix pull. <lfam>You almost never want plain sudo *nckx has SETENV in their sudoers anyway. <nckx>So sudo is always sudo -E. <lfam>The UNIX users / groups-based privilege system is pretty bad :/ <nckx>It has certainly served its purpose and had its time. <quiliro>ok...i understand now, the daemon is not updated when 'guix pull' is run unless it is not a guix user that manages the daemon <lfam>Yes, it is certainly the best one we have are using! <lfam>Good thing that GNU is not UNIX so we can innovate freely :) <nckx>quiliro: I can't parse ‘unless it is not a guix user that manages the daemon’, but yes, correct. <quiliro>root user manages the daemon on a foreign distro, so it is correct to 'guix pull' on that user then <quiliro>but on guixsd, the daemon is not managed by that user but by herd <nckx>quiliro: I've never used Guix on a foreign distro, but yes, I *think* so. *nckx RFC-2119 MUST go out before the shops close to buy coffee. o/ <nckx>quiliro: My point, though, was not to ‘sudo guix’ on GuixSD. Not what to do on non-GuixSD. <quiliro>nckx: i did not suggest 'sudo guix pull' <quiliro>i suggested running 'guix pull' on root <quiliro>but now i understand that will work on guix outside of guixsd <quiliro>why will 'guix package -i ...' not continue a download where it got cut off when runnig it again? <quiliro>why will it start the downlead fro 0? <nckx>quiliro: You suggested guix pull as root, which is identical. And: because we don't keep half-downloaded files around. *nckx got the last bag. Phew. (o_o)` <nckx>quiliro: There are package managers that do so, and Guix could, but we'd have to be very careful and nobody thought it was worth it so far. <nckx>Developer bandwidth privilege. :-/ <lsl88>I'm back, I chose pastedebian: this is the output of my guix pull (from my unprivileged user), but I guess this line is the important one: builder for `/gnu/store/yp9ilbjpvwn8qbss3fzb5fw0qm09xx7j-guix-packages-base.drv' failed due to signal 9 (Killed) <nckx>lsl88: The lines above that are. <lsl88>that's the result of guix pull <nckx>But signal 9 is not a natural cause of death and usually hints at OOM (out-of-memory). <lsl88>yes, you are right, it complains about heap <nckx>lsl88: Does your dmesg end in a scary backtrace of the kernel plotting to kill someone? <nckx>Yeah. That's very OOMy. :-/ <nckx>It will be slow, but there's no way around it I'm afraid. *nckx used to run then-GuixSD on a 256MiB VPS back in the day, but those days are gone. <rvgn-net>Is there an application packaged in Guix that can compose and edit Texinfo in a straight forward way? <lsl88>nckx: yes, it is killing guile. I do have swap, remembered setting it and I will check but probably my swap is much much bigger than my RAM -1G- <kmicu>Why guix pull wants to build Guix and needs more memory? lsl88 how much free memory is reported by ‘free -h’ (column ‘free’). <rvgn-net>What I mean is, instead of typing all @.. commands, I would just edit the document as text which edits the Texinfo at the back. <rvgn-net>quiliro Would I be editing in emacs just like text? <nckx>kmicu: The purpose of ‘guix pull’ is to build a new Guix. The problem is that ‘recent’ Guile versions (well, several years now) are very resource-hungry when compiling. <quiliro>i have never used it...but i have heard it is the best for texinfo <nckx>Does guix pull respect -M and -c? It's not in the --help output but I've seen ‘guix pull’ use 800% CPU… <nckx>That can't be good for RAM usage. <kmicu>nckx: couldn’t we download a substitute and avoid building it? <nckx>kmicu: That's what happens now. <nckx>If substitutes are available, of course. <lsl88>I don't know why swap appears with everything in 0, when I even set it to be of 5Gb (had a lot of extra space) and even running my icecat I only have 100Mb left <nckx>And guix pull being guix pull… the build farm doesn't have much time to catch up. <kmicu>Ah, so in this case guix-fa5a25386 is not ready yet. <nckx>You can't ‘guix pu— && sleep 10m && guix —ll’, so to speak. <lsl88>apparently swap was not mounted. Don't know why. Did a swapon <nckx>lsl88: Your swap space shows up in ‘swapon’? <kmicu>Is there no ‘guix pull fa5a25386’ to pull specific commit (which allows waiting)? <nckx>kmicu: Oh, that should work. It's just tedious. <nckx>s/It's/Finding the right commit hash every time is/ — better? <kmicu>A user could create an alias to guix pull $(1-day old guix revision). <nckx>kmicu: See ‘guix build --commit=…’. <lsl88>nckx: it didn't appear, but I did a swapon of the partition and now it is up <quiliro>lsl88: i once had that problem too...bad system init file definition <nckx>‘guix build --commit=master~50’ should be possible to implement… <quiliro>i hope i don't mess up on that suggestion too! <lsl88>of course I close everything except the terminal (maybe I should use a tty?) and running a top next to my other terminal I don't see that memory is full <nckx>quiliro: :-D You didn't mess up. I was just trying to be clear and direct and prevent myths from spreading earlier. <lsl88>quiliro: I mixed them, well, in fact used desktop but without gnome, and changing the type of bios and mapped devices. ***jonsger1 is now known as jonsger
<quiliro>in fact...let me check mine...often used guixsd without swap <kmicu>It looks like guix pull supports --commit so maybe lsl88 could update to 1 day/week old revision to get 0.16. <nckx>kmicu: Hum. Just wondering if you saw my message about that above. <nckx><nckx> kmicu: See ‘guix build --commit=…’. <nckx>Still missed it the second time. Sorry. <nckx>See? This is why I need my coffee 😒 <nckx>I was looking on hydra.gnu.org for a recently evaluated commit but it's uselessly slow. <kmicu>‘guix pull --commit=39c0a3fdb7’ is 3 days old commit and that should avoid building guix. <nckx>0d5101c seems like a good candidate on Hydra. <kmicu>Hydra welcomes me with ‘master 'master' branch 2018-04-28 19:08:49’ xD <nckx>kmicu: Yeah, hence my question (oh dear) above. ‘gnu’ is current. <kmicu>Ah, guix 0.15 uses hydra not ci. Good catch nckx <nckx>kmicu: Hydra is still operational. Just ‘special’. <kmicu>I follow fsf.status on fediverse and ‘operational’ is a very generous word xD <nckx>Now witness the power of this fully operational Hy— uh. Just a moment. We're… sec… <lsl88>oh yes, I thought it was implicit the use of hydra in my case. I rebooted, killed the GUI, and now my swap is on <lsl88>and I am trying to see if not having the GUI helps :) <enderby>hi guix, i have question about the calf-0.90.1 package. on my laptop it installed and the plugins are showing up with lv2ls (and in ardour) and are in /gnu/store/77fb6jx5g2wrl5mynaag9shibbvi9550-calf-0.90.1/lib/lv2/calf.lv2/. on my desktop, there are no .ttl files in that dir. wondering what's up? <nckx>So it does seem that they're not on Hydra at all. *nckx is so out of date :-( <lsl88>my bad, had to mount again swap <nckx>lsl88: If that fails, try --commit=fa5a253 if you still have the energy. It should definitely substitute. <nckx>ci.guix.info is so speeedy ♥ <lsl88>nckx: I have the energy, want to make it work, and is fun, but sometimes I am still afraid of asking, specially when I think "I should know this" <lsl88>nckx: I know, in fact in a VM I couldn't make it change to 16 and remember asking how to use ci.guix.info as the default <kmicu>Hi enderby: it’s possible that you are the first real calf user. So expect bugs. :( <lsl88>what caughts my attention is that my two cores are working at maximum when guix pulling <kmicu>enderby: I see in git blame that calf was last time updated in 20180814. <nckx>lsl88: You do have substitutes from ci.guix.info enabled and working, right? <lsl88>I know I should, shall I cancel the pull and set them <nckx>Your only hopes are to get substitutes for ‘guix pull’, or waiting a very long time for it to finish locally with lots of swapping. <kmicu>lsl88: please, don’t hesitate to ask questions, especially those with ‘obvious’ answers. (They help improve guix and help lurkers to learn new things ヽ(*＾▽＾)／). <nckx>lsl88: If you've already authorised ci.guix.info's signing key, you can just ‘guix pull --commit=fa5a253 --substitute-urls=https://ci.guix.info’. <kmicu>Thank you nckx. Direct commands are appriciated. <nckx>lsl88: I've been using Guix{,SD, System} for almost 5 years now… I still don't know many things. Please, ask away! <nckx>kmicu: I don't usually do that only since I make so many thinkos (‘guix build’) and it risks confusing people. FWIW. <lsl88>nckx: I remember asking how to add ci.guix.info maybe a month ago or more as the default one <lsl88>i need to change that again, because otherwhise it uses hydra <nckx>lsl88: Does your /etc/guix/acl contain 8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394 ? <nckx>Bah. Then you need to ‘sudo [for once] guix archive --authorize < …/ci.guix.info.pub’. <nckx>ci.guix.info.pub can be found in the Guix git repository. <nckx>etc/substitutes/ci.guix.info.pub to be precise. <jackhill>rekado_: yay gnome3.30. Thanks for your work on that! Let me know if you need help testing. <nckx>(I could paste it, but I could theoretically paste a malicious key, I guess…) <kmicu>(That would be catched and you would be expelled from our kingdom.) <nckx>Sure. I just don't want to encourage bad habits in others ;-) <nckx>curl | sudo bash > /dev/sda <nckx>(inb4 ‘you need to use tee’) *kmicu goes back to watching official recap to all 41 songs of the 2019 Eurovision Song Contest <lsl88>first I want to be able to guix pull, I added manually the --substitute-urls.... <lsl88>I killed the GUI, and only have two ttys, one with my guix pull and anohter one running to <nckx>Sorry to interrupt, but have you run the ‘guix archive --authorize’ above? Substitutes will be ignored otherwise, even with --substitute-urls. <lsl88>nckx: don't get it. I can't find the pub key here. <nckx>--substitute-urls= won't help without it, so we need to take care of that first. <nckx>Straight from the (source). <nckx>(This would not be necessary if you were installing Guix now, but your Guix is older than ci.guix.info itself, I believe :-) <lfam>Any examples of how to remove package inputs provided by the build system? <lfam>Not sure if I can match by label here or not, though <lfam>I'm trying to remove the default GCC since it is unused but is referenced by the built Go <lsl88>nckx: apparently it is using it all the same, since it is going fast (sorry I cannot look at both machines at the same time :P ). But I remember having run the command and then see your message. <nckx>lsl88: Hm. Well, whatever happened, as long as it works. <lsl88>So, in case I am lucky enough to have guix pulled and have it upgraded to 16, I should import the new "substitute" to se it as the default one <nckx>lsl88: You only need to import the key once (that will add it to /etc/guix/acl), then add ci.guix.info to your system configuration so it's used by default. <lsl88>and I want my swap to be automounted, then I guess I will need to run a system reconfigure right? <lsl88>great, so those are my steps :) <nckx>lsl88: So ‘guix pull’ is downloading substitutes instead of compiling everything locally? <lsl88>nckx: yes, that was the original idea. i guess I changed it because of the failure <pkill9>it's great nckx, it only takes two minutes to run guix pull on this laptop <nckx>I wish my laptop were that fast. <nckx>‘guix environment’ takes that long just to construct the profile… <nckx>A rubbish one (AMD C-70 APU) with 5400-RPM hard drive. <nckx>So it's almost my own fault. <nckx>UEFI won't recognise the SSD I bought for it and I've been travelling too much to fix it. <civodul>nckx: if it's ext3/ext4, does it have the "dir_index" feature enabled? <civodul>(we were recently reminded how big of a difference it makes) <nckx>civodul: I think so. I'm pretty good at that sort of thing, usually… <nckx>Filesystem features: has_journal ext_attr resize_inode dir_index sparse_super2 filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize bigalloc <roptat>I get these lines while running guix pull: "@ build-log 8038 95", is that expected? <roptat>as well as the output of the build being done <roptat>I thought it was supposed to be hidden? <roptat>maybe, it's the daemon that was installed with guix init from a 0.16 install <civodul>roptat, rekado_: that happens when the compute-guix-derivation script ends up building things (due to grafts) <roptat>my guix pull has officially been running for 24 hours now, and it's still not completed ^^' <roptat>I have, but it's still building some stuff <roptat>I saw it download substitutes though <civodul>oh wait, we don't build "guix-modular" for arm <roptat>not on berlin, but I think we have on hydra? <civodul>hmm dunno, i was thinking about berlin <roptat>I'm a bit worried for my SD card <civodul>i just changed the config for "guix-modular-master" on berlin <civodul>so next time you push, it'll build on ARMv7 in addition to the 3 others <civodul>BTW, we still have only two OverDrives plugged in on berlin <rekado_>are none of the new ones plugged in? <rekado_>the firewall ports are open already. <civodul>the one at roptat's place is plugged in, but that's it <civodul>i think Andreas plugged in the other one on berlin *nckx will finally be home sweet home on Thursday. <roptat>Is the overdrive at my place doing work or do you mean there's a problem with it? ***amz3` is now known as amz3
<vagrantc>roptat: i've only been seeing armhf substitutes from mirror.hydra.gnu.org, not from berlin <vagrantc>or at least, much fewer armhf substitutes