<vagrantc>don't know if it's just because substitutes aren't available or what <nckx>vagrantc: A lack of substitute triggers the local build, but can't affect its demands. <vagrantc>guess there's been misc problems with the substitute servers lately, so it wouldn't be surprising if they were lagging <vagrantc>wow, looks like i actually had 14GB of free disk space <vagrantc>i think last time i had this issue it eventually required something between 13-14GB <vagrantc>i'm apparently using my local nginx caches, one of which points to berlin.guixsd.org and the other mirrors.hydra.gnu.org <vagrantc>though i've never been impressed by the hit rate on it <vagrantc>this time the qtwebkit build even suggested it failed due to lack of disk space ... <luciddreamzzz>vagrantc, interesting berlin.guixsd.org is supposed to be good for substitutes <nckx>vagrantc: I just built qtwebkit with 8G RAM/4G swap (and other builds running in parallel) using -{M,c}1. I do have 972 MiB of free space though... <nckx>(OK, ‘just’ is a bit of a silly. Of course it took hours.) <nckx>Can be substituted from munich.tobias.gr if you trust me with your binaries... <vagrantc>972MiB ? the build directory itself seems to take at least 8GiB during the process of the build for me <LucidDreamz>vagrantc: looks like no substitutes available on hydra <vagrantc>ok, with 27GB of free space (probably overkill), and --cores=3 ... it successfully built <vagrantc>i don't think i've ever gotten a hit on icecat from a substitute server <g_bor>I managed to recover my system. <g_bor>It seems that all my user profiles were broken, but the system profile remained more or less intact, at least I could guix pull to core-updates... <efraim>anyone know offhand what I need for '-ltinfo'? <roptat>I've just commited the German version of the manual :D <Laalf>roptat: do you have a link to that? i am a native speaker <mbakke>Laalf: Hydra will likely be down over the weekend. <roptat>you can also run guix pull, then "info guix.de" <Laalf>"you can also run guix pull" no i cannot because hydra is down and i dont have enough ram for python <efraim>mbakke: i already had ncurses, i'll try '--ad-hoc ncurses pkg-config' <Laalf>does someone have acpi-call running? <Laalf>you coul theoretically add a patch to the kernel, right? <pkill9>i know litle about kernel development though <pkill9>i looked into adding acpi_call but it was ove my head <pkill9>and compiling the kernel takes a long time so i can't really compile then test it <pkill9>and i'd have to reboot into it each time <Laalf>pkill9: do you know how dkms works? i thought about just adding the module directly to the modules path. but i am very sure that this will not work <ng0>it is very obvious that the discussion about CoC vs GKCK has long arrived at the point of strawmen. could you just let the discussion die? there's no good coming out of this. discuss this offline, fossdem or whereever. this will continue moving in circles.. <ng0>it would be less annoying if we had "guix-chat" or whatever, but this is on a _developer_ mailinglist, where I have to read threads occasionally to stay up to date <efraim>we do have a CoC channel, don't remember what the name of it is though <ng0>roptat: will the problem with the translated french manual not being properly integrated into the build-system be solved by then or is it already addressed? I keep git stashing the french diffs. <ng0>i fear that a german translation might behave the same <roptat>ng0: mh... I don't remember what the issue is very well <roptat>that's when the .po file is changed, it regenerates the .texi file, is that it? <roptat>if we add guix.*.texi to .gitignore, can I still commit these files when I upgrade the .po file? <ng0>po is okay, you can normally stash that <ng0>but also the .texi file is causing conflicts I can't remember exactly <ng0>didn't have an bug report about this? <efraim>ng0: 'git checkout -- doc/' , then you don't have to stash it anymore <ng0>but the problem remains, .fr.texi causes diffs with updates. <ng0>we should probably read into how other projects handle this <amz3>I like the idea of linking guix pacckages to wikidata, see the mailing list for more info, and submit your input <vaab>Hi all. I'm trying guix these days. I'm hit by Gateway Timeout, I guess this is normal ? (well expected ?) <vaab>When building anything, it seems that the substitutes server is always down (Gateway Timeout)... <roptat>expected yes, because one of our build farm is down for maintenance <roptat>but first I think you need to allow substitutes from it <vaab>This forces me to build stuff, which is completely okay... apart that all builds fails on bzip2's tar gz from www.bzip.org website not having the expected sha256 ... same question... is that a known issue or did I do something wrong ? <vaab>@roptat: thanks for the suggestion, trying to see what I can do to use this second build farm. <Laalf>i am missing phy1nbsmlml06lkjixjw2dfb4k6wi5al-python-3.6.5.drv for example. this doesnt seem to be available on berlin or mirror <Laalf>so i cant really do anything at the moment <vaab>@roptat: I'm a newbie, what can I do to give you this info ? If "guix --version", then it's 0.15.0 <roptat>vaab: you'll probably have more luck after you run "guix pull --substitute-urls..." <roptat>hopefully, the issue you have is fixed in more recent versions of guix <roptat>Laalf: you're right, I'm also building python... <vaab>@roptat: this last command seems to download things at last (didn't need to authorize anything BTW and FYI) <Laalf>roptat: i have 24gb of ram and i cant build it because its not enough <joshuaBPMan>why is guix building pango when I am doing a 'guix package -r cmake llvm' ? <joshuaBPMan>Why would it even need to talk to the substitute servers? <roptat>joshuaBPMan: try with --no-grafts? <Laalf>"id be happy to compile it on my notebook. it has enough power". well not enough for python:D <joshuaBPMan>it's still building stuff. That just seems to weird. <roptat>then it's probably needed to run a profile hook <roptat>you probably have graphical applications that install icons? <roptat>IIRC pango is a dependency of gtk which provides the binaries to update the icon cache <joshuaBPMan>it's build xorg-server 1.19. I'm running guix on a foreign distro. I don't even have X installed via guix... <roptat>if you don't want to run the profile hooks, you can switch to an older profile generation <roptat>(guix package -l to see the list of generations) <vaab>@Laalf: I have no guix knowledge, but I regularly compile python with modest setups... So that seems strange for me. <Laalf>vaab: how much ram do you have? normally packages are built automatically and are available in substitutes. since hydra is down at the moment, you will build it more often <roptat>Laalf: I built python on my machine with 16GB of RAM only <Laalf>i cannot build python 3 with 24 <roptat>I'm on current master: /gnu/store/ld32bzn3dxjbd29v4i2p0jnaak31dssn-python-3.6.5 <Laalf>roptat: did you disable tests? <roptat>but maybe that was downloaded from berlin <pkill9>if only we had as many substitute servers as archlinux has mirrors <roptat>Laalf: it's the same version as what you're trying to build actually <roptat>give me some time to configure guix to serve substitutes from my machine <vaab>@Laalf: I compile it by hand usually, with less than 8GB, didn't try last version of python thou... I can do a quick test if you want. I might have issues, who knows. <Laalf>pkill9: we dont have enough shitware for huge interest <Laalf>vaab: "by hand" does nothing on guix <Laalf>roptat: wasnt there a guix archive --export or something? <pkill9>i'm getting tonnes of these errors: guix/ui.scm:1583:12: In procedure run-guix-command: <pkill9>Bad Read-Header-Line header: #<eof> <pkill9>does it use the same authorization key as the main server/berlin? <vaab>@Laalf: I'm telling you, I don't know guix, but I compile python often by hand (and guix is suppose to follow the same path than I do... download source code, use auto-tools configure, make) and I can tell you that it should not take 24GB. If guix can't do it, this means something is probably going very wrong. Again, I might say enormities as I'm a <roptat>pkill9: no it's using mine, but as long as my substitutes have the same hash as hydra or berlin, it should be accepted <vaab>@Laalf: last source code compiled on my surface pro 3 (8G ram) in less than 2mn. <Laalf>i can compile it fine. tests break it <roptat>mbakke: ha, I might not have reconfigured in a long time, so maybe I'm on an older kernel <vaab>@Laalf: talking about Python, that compile in less than 2mn with barely noticeable usage of memory in my memory graph consumption report. <Laalf>vaab: i am also talking about python. see the link that mbakke provided <mbakke>Laalf: One (ugly) workaround is to run `guix pull --branch=core-updates`, where the broken Python test has been removed. <mbakke>Berlin should have substitutes for most of that branch. <Laalf>mbakke: guix pull: error: '--url', '--commit', and '--branch' are not applicable <pkill9>roptat: i don't think the guix store associated substitutes with where they came from internally, i thought it's just to allow it to download from that server <mbakke>Laalf: In that case you probably have a channel defined, and would have to adjust your channels.scm. <Laalf>mbakke: yes i have your chromium defined:D <pkill9>roptat: i think guix only signs substitutes when they're exported using `guix archive --export` <mbakke>Laalf: In your channels.scm, you can replace %default-channels with (channel (name 'guix) (url "https://...") (branch "core-updates")). <mbakke>url can also point to a local repository, which is convenient. <pkill9>but if it works as you say it does, then that would be very useful for p2p distribution of binaries <pkill9>i dunno what narinfo is, i recognise that from when it downloads sometimes <roptat>I think it signs narinfo, but if the signature is not trusted, it will still download substitutes as long as their sha256 matches that of a trusted substitute server <Laalf>mbakke: i removed chromium for the time being. there was no interesting update anyways. btw: is there any update to fsf maybe accepting chromium as free software? <mbakke>Laalf: Right, but the broken test has been removed at least. <Laalf>mbakke: thanks for notifying. <pkill9>Laalf: i think chromium has long been considered unknown as to whether it's free or not <mbakke>Laalf: Re chromium, I don't think there is any new information from FSF, but I do not regard that as a blocker from getting it into Guix. <mbakke>roptat: Yes, because it's grafted. <Laalf>mbakke: i mean other fsf approved distros arent allowed to package chromium as well. so why should guixsd be allowed to? <mbakke>roptat: It is used for some of Guix dependencies, such as libssh and/or libgit. <roptat>Laalf: you might have to trust my substitute server then <mbakke>roptat: Though I suspect there is a bug there somewhere, last I checked it was only a build-time dependency and thus we should not have to build the grafted variant. <mbakke>Laalf: To the best of my knowledge, Chromium is free software. I cannot prove that, but IMO the onus is on FSF to prove otherwise. <Laalf>roptat: i have to trust my hardware too much anyways. a random guy on the irc is someone id rather trust than intel. but i trust both. will pull with core-updates. <Laalf>mbakke: a chromium like you built phones less home than icecat. <Laalf>chromium should have been considered free software 5 years ago <roptat>maybe we should discuss it with other free distros? <Laalf>on the parabola irc there was this discussion once. we should get an official statement since nobody wants to start i guess. <mbakke>I plan to give a heads-up to relevant mailing lists once I'm ready to get "ungoogled-chromium" into Guix. <vaab>@mbakke: ok that makes more sense :- <roptat>how far are we from merging core-updates? <Laalf>a solution to plugins should exist before it gets put into distros that are for more casual users. <mbakke>roptat: Not very far, but unfortunately we're severely handicapped without Hydra. <vaab>@mbakke: it was for the bug report on python. Was AFK a moment. <Laalf>dark reader, ublock origin and keepassxc-browser are my only plugins atm but i am not really interested in letting chromium phone home at every start <Laalf>mbakke: wouldnt it be possible to add your channel via guix channel add? it would solve the guix pull issue i saw if i read that right <mbakke>Laalf: I don't think there's a "channel" subcommand for Guix yet. But there is room for UX improvements for sure! <Laalf>ye i forgot. that idea isnt upstream yet <vaab>What is the rationale behind executing tests after compilation in a reproducible build system ? <Laalf>even core-updates' python 3 breaks my ram <Laalf>roptat: it would be sudo guix archive --authorize Downloads/rennes.lepiller.eu.pub, right? that takes forever <roptat>sudo guix archive --authorize < Downloads/rennes.lepiller.eu.pub <roptat>it reads from the standard input <pkill9>i feel like it would be nice to be able to organise channels, substitute servers and their authorization keys together <pkill9>i'm getting weird UI-related errors too <pkill9>specifically guix/ui.scm:1583:12: In procedure run-guix-command: <pkill9>Bad Read-Header-Line header: #<eof> <XWill1>Hello, with your help and documentation, i managed to get the touchscreen and wacom pen working in guixSD on my Lenovo x200 tablet <Laalf>XWill1: great to hear! you might now have a look at libreboot!:D <XWill1>i look at it but it requires soldering wires on the bios chip... and i'm not sure if vt and vt-d will be available with it <Laalf>XWill1: you dont need soldering, you dont need vt-d. only vt-x since you dont pass pci devices through. <XWill1>maybe if i can manage to install a xen kernel, i could use vt-d to make a driver domain for the network <reed_>Hi All, does anyone have any insight as to how to set up guixsd with a realtime kernel? <Laalf>reed_: if you can create a package for the rt kernel, its easily doable <Laalf>there are many people who did this with nonfree kernels. i am not gonna show that since i dont want to promote nonfree software <reed_>do you have any other references I can look at? I'm looking at the documentation for the operating-system call and there isn't much detail on the kernel argument <Laalf>reed_: ask a search engine for a nonfree kernel <Laalf>roptat: you dont have gawk and/or python-minimal built. <roptat>Laalf: I have /gnu/store/jiq073al7bhzicbcv8x81vv4mx63fsfp-gawk-4.2.1 <Laalf>roptat: substitution of /gnu/store/jiq073al7bhzicbcv8x81vv4mx63fsfp-gawk-4.2.1 failed <Laalf>i guix gc'd which wiped my custom kernel. <Laalf>fug. so i will report back when its build. after dinner <g_bor>:) now my system is back in business, reconfiguring to core-updates :) <Laalf>i really needed this notebook upgrade if i am going to rebuild gcc and linux 30 times a day <lfam>Rebuilding GCC and Linux isn't a normal requirement of Guix unless you are actually working on those packages <lfam>It's just a temporary issue while our infrastructure has some issues <lfam>Even then, you should only need to build them once unless, again, you're making changes to those packages <Laalf>bios whitelist. i need a nonfree kernel on this notebook now. until i get a hardware flasher and someone who mods this bios ***jonsger1 is now known as jonsger
<amz3>hello, what is the right way to test guile-next, I used 'guix pull' but guile-next is not there <Laalf>roptat: substitution of /gnu/store/jiq073al7bhzicbcv8x81vv4mx63fsfp-gawk-4.2.1 failed ***jonsger1 is now known as jonsger
<roptat>also don't forget to add my server to the list of substitute servers <roptat>also note it's not going to be up forever, it's my desktop machine :) <Laalf>roptat: guix build works just fine... weirdly... i cant guix pull since that throws some error i sent earlier. what gpu do you have in your desktop? <Laalf>there are no libre compatible pcie graphics cards that arent very old or old and nouveau <Laalf>roptat: is there a good way to download everything you have from your pc? <Laalf>its trying to "building /gnu/store/fa7r64a4b82j21r7zls5wsxs9gmlkbgk-Python-3.6.5.tar.xz.drv..." which makes no sense since guix build python gives /gnu/store/0yh3i4ad43k0nr0xc63jwwz67md356a6-python-3.6.5 and /gnu/store/1y3b22r7yhwvmlndn3vxkqvrcm20ihwm-python-3.6.5-tk <roptat>maybe there are other packages with this source? <roptat>or it's trying to build the ungrafted version <Laalf>it would be nice if system reconfigure would tell me what it needs <Laalf>i am now downloading some stuff via guix build. i am still weirded out by that python 3 <lfam>Laalf: There are a few Python 3 packages. There is also python-minimal and python-wrapper <Laalf>lfam: i know there are python-minimal and wrapper. but i dont know why there are multiple Python-3.6.5 packages <roptat>"building /gnu/store/fa7r64a4b82j21r7zls5wsxs9gmlkbgk-Python-3.6.5.tar.xz.drv..." means it's downloading sources, but we don't know what for <roptat>what's strange is that I have all three of them, grafted and ungrafted <Laalf>that is why i cancel that. i know it will just break my ram again <roptat>maybe you have more hints with the dry run? <Laalf>building libvirt in the background. will dry run and put on a pastebin. pls dont judge <Laalf>i forgot LC_ALL=c but its readable i think <roptat>looks like python-minimal-wrapper is the culprit <Laalf>guix build python-minimal-wrapper python-wrapper <roptat>I just got it from berlin though... <lfam>Well, my guess is that it's downloading the Python sources so that it can build one of the Python 3 packages. All of the ones I mentioned are version 3.6.5 <roptat>yes, the dry run shows python-minimal-wrapper and python-wrapper <roptat>but that's weird because they should be available on berlin and on my substitute server <Laalf>and i cant build python because i dont have enough ram <roptat>what if you try to build them and specify my server only? <roptat>if it doesn't work, try with --no-grafts <roptat>ok, give me some time to export them and send them to you <roptat>it contains two packages (python-minimal and python-minimal-wrapper) you can add them to your store with guix archive --import < python.nar <Laalf>its downloading. i will run my system reconfigure after that <roptat>don't forget to import before reconfiguring ;) <Laalf>thank you so much for your help <roptat>I hope the situation is resolved soon <Laalf>i hope that hydra is back soon <Laalf>the rest should be easily buildable for me <Laalf>remind me to not run guix gc <roptat>my own guix warned me about my disk being almost full <roptat>but I don't really want to run guix gc right now either <Laalf>when i can reconfigure i can add another ssd to a subfolder of home. that will give me another 50gb or so for /gnu <roptat>we now have openjdk 9 and 10 in guix! <roptat>icedtea doesn't exist for these versions <XWill1>i had the same problem with guix gc, i had to rebuild all the toolchain and with not enought RAM it took about two days of swapping <XWill1>Only after i read the documentation and saw "guix gc could collect the toolchain" ! <Laalf>XWill1: you can offload to a server if you want <Laalf>and if you can install guile-ssh <roptat>pkill9: icedtea is a set of tools and patches to be able to build openjdk 6 to 8 <roptat>apparently they didn't distribute everything as a single package and lacked a few parts of the jdk, so icedtea filled the gaps <nckx>Is there a list of ‘unofficial’ substitute providers for those who still trust in strangers they know? <Laalf>icedtea prodices some issues, openjdk produces some issues. <Laalf>nckx: i dont know of one server but my own. which doesnt work atm <nckx>Julien's was news to me, for example. <roptat>I just happened to have the packages Laalf needed :) <XWill1>yes maybe later i will install guixSD on my desktop with guix publish, i'm still novice in guix/guixSD/guile and i hope it will be my last linux distribution <Laalf>is there an easy way to set up a build farm like on berlin or something? <g_bor>diffoscope does not build for me on core-updates. <roptat>Laalf: you'd need a powerfull machine, then it seems not too difficult to install cuirass on guixsd <roptat>g_bor: have you seen? I've just pushed openjdk 9 and 10 to core-updates, more non-determinism for you to fix :p <roptat>did you fix the issue with libjvm.so? <g_bor>I will need to have a more thorough look at the idectea-6 stuff, as <g_bor>it seems that after the first patches some patches in the icedtea patches diretory does not apply any more, but do not fail the build <Laalf>roptat: when i have way too much money i will get back to you. probably. <Laalf>when i look at python i will probably need a server with a few more gb of ram <g_bor>Moreover, these pathces are modififying a lot of different files, in different places, and after the source tree is assembled from these repos all over, so it seems a bit complicated. <g_bor>However icedtea already has a 'patch-patches build phase :) that seems like to place to add this stuff... <nckx>Laalf: I managed to completely wear out an SSD in ~8 months running a build server on it. Maybe it was bad, maybe I misconfigured something (I did use fstrim & overprovisioned), but still, all my build farm rust now sweetly spins. <g_bor>I could not do much unfortunately these days, I was busy tring to recover my system from something, that I still don't know was what... <g_bor>All user profile stuff seemd to be gc-d, moreover not failing immeditately... <Laalf>nckx: i live in germany. my internet wouldnt be ok for a server like this. i would rent one. <g_bor>I just don't know what happened. <roptat>g_bor: I observed similar symptoms with a disk failure <lfam>nckx: Did you have a way to estimate the total amount of data written? Also, which SSD was it? <roptat>guix binary's was replaced by a part of an irish mo file ^^' <nckx>Laalf: I live next door, I don't think it's much better here. I use a caching nginx proxy on a cheap VPS to mirror it. <Laalf>nckx: alright. that might be a good idea. if i stumble upon a cheap dual 1366 machine i will buy it. <nckx>lfam: Erm, ‘all of it’ ;-) ‘Remaining lifetime writes’ or whatever it's called was zero. It was a (budget OEM) M.2-or-what's-that-motherboard-thingy Samsung. <nckx>Laalf: 4 TB but it doubles as a NAS. <lfam>Heh, okay. That's an impressively short lifetime. Good (Samsung) SSDs can accept several hundred times their capacity in writes <Laalf>nckx: oh. i thought a build server needed a lot more <nckx>Yeah, I have no idea what went wrong. The drive was probably a second to begin with. <Laalf>i have a 750 evo 250gb here that has around 800tb written <nckx>Now I wish I'd kept the thing instead of therapeutically... disposing of it. <Laalf>i kinda wish ddr3 ecc prices would come down again <Laalf>even they are way too expensive <nckx>Laalf: ‘All of Guix’ is still surprisingly small. Between 75-100 GiB, last I checked. It only starts to add up if you care about more than the latest master. <lfam>" evo 250gb here that has around 800tb written" Wow <Laalf>samsungs shitty windows software shows it as well afaik <g_bor>roptat will try that, but this is a vm, and the host s.m.a.r.t. shows the hd where the image resides is healthy. <nckx>I bought a (branded ;-) 500 GB 860 Evo for my laptop and am paranoid about writing to it now. So that is music to my ears. <Laalf>96gb ddr3 ecc ram still costs about 300€. that stuff is old now.... <Laalf>nckx: my 860 evo is pretty damn fast for a sata ssd. <nckx>Laalf: I know, right? Booting is CPU-bound now. I mean what. I know I'm old-school but it still blows my mind. <Laalf>nckx: its not cpu bound for me. and i am on ivy. on my pc it would be if my motherboard didnt die. but nvme is kinda cheating if you cool it a bit <nckx>Laalf: Well, it is on an AMD C-70 APU with Radeon(tm) HD Graphics 😒 <nckx>Mind you, checking my e-mail in emacs is CPU-bound on this thing. <Laalf>i am very happy with my purchase of my w530. 24gb ram is nice. but that damn wifi whitelist <pkill9>you can flash a patched BIOS to get rid of the wifi whitelist can't you? or flash coreboot - although i dunno if you need to do a hardware modification <Laalf>pkill9: i can "just" flash a patched bios. via hardware. and i cannot patch it <Laalf>coreboot isnt available and idk about the nvidia card in there... <roptat>g_bor: diffoscope failed on core-updates here too <Laalf>you need to desolder the chip as well. which is more of a pain than i want. if i get someone to patch it (maybe even 0x194?) i might do it. but its easier just to accept that intel listens through the ME anyways, so they can listen via closed wifi firmware as well <g_bor>roptat: ok, I will have a closer look tomorrow. <g_bor>:) I will have some sleep now, lookaing at these progress indicators spinning is not especially enlightening :) <vaab>Reading the general options, and especially the ``--fallback`` option, it is still not clear for me how to prevent local build whatever happens. I'm in cases I just want everything to come through substitutes servers or fail. I'll provide substitute servers that will have everything available. <vaab>Reading the doc: "Note that when substitutes are disabled or no substitute is available for the derivation in question, a local build will always be performed, regardless of whether or not --fallback was given. " Which is not what I'm aiming at. I'd like to simply fail if no substitute are available. <nckx>vaab: There's no such option. <nckx>There might be a wishlist bug about it that you can ping, or you can open one. It's been asked several times.