IRC channel logs

2018-11-28.log

back to list of logs

<rekado>ngz: the scribus build is now fixed. Thank you for the hint!
<ngz>Thank you!
<ngz>OOC, how did you extract the patch from the link I sent you?
<rekado>I added “.patch” to the URL
<ngz>duh
<ngz>I didn't know you could do that.
*rekado –> zzZZ
<ngz>rekado: Thank you again. Good night.
***jonsger1 is now known as jonsger
<pkill9>i have a user that isn't added to the audio group, yet it can recieve audio input through pulseaudio and record it in audacity, how do i fix this?
<noobly>hello, I'm trying to install alongside an existing gnu/linux OS. I'm not sure how to configure grub to do this though, so getting my config.scm right is where I'm stuck. i don't want to install over my existing grub and block myself out or anything
<NOOBLY>I am trying to boot guixSD alongside an existing gnu/linux distribution and I'm not sure how to express this in my config.scm. If someone wouldn't mind walking me through this portion of the install, I'd really appreciate it.
<bavier>NOOBLY: see the section of the manual named "Bootloader Configuration"
<bavier>which contains an example of providing bootloader menu entries for other systems
<noobly>bavier: I have read it forward and back now, along with any mailing list info I could scrounge up. I'm still paranoid about ruining my other install
<bavier>noobly: understood. I can't offer any first-hand experience, but maybe others can
<noobly>bavier: thanks for the kindness, I suppose the worst that can happen is my boot configuration for the other OS getting fried, which isn't too hard to fix I guess
<bavier>prototype "arch" updater finds 1060 potential updates
***slyfox_ is now known as slyfox
<fps>ok, i think i see what the problem is:
<fps>curl https://berlin.guixsd.org/api/latestbuilds?nr=10 | jq . | less
<fps>all these derivations aren't really for store items that lateron appear on the mirrors as nars.. it's just some builds of complete branches, tags, etc..
<efraim>I have a fix for the clang failures, testing it now
<civodul>Hello Guix!
*vagrantc waves
<efraim>hi!
<janneke>o/
<fps>civodul: the stream of builds that that berlin api returns aren't really items that land in the store or on mirror.hydra directly. it seems to be mostly builds of complete branches, etc..
<civodul>fps: berlin and hydra are completely separate build farms
<civodul>so what berlin reports has nothing to do with what's available on hydra
<civodul>the /latestbuilds entry point does report completed builds though
<civodul>if you use Emacs, you can try M-x build-farm to browse it
<fps>oh, there seem to be individual jobs available, too..
<fps>like e.g. job 651507
<fps>*indidividual store items
<fps>it's the first narinfo i got from any of the reported builds ;)
<fps>it seems i just had bad timing yesterday...
<fps>ok, i got this almost automated :)
<civodul>neat
<civodul>fps: note that (guix ci) and (guix scripts substitute) contain code to deal with that
<civodul>roptat: it seems the "TRANSLATORS" comment in guix.texi doesn't make it into the pot file, any idea why?
<fps>civodul: i'm not in the mindset of using scheme for this (yet). i hacked together a colleciton of shell scripts that produce this: https://ipfs.io/ipns/QmPMJYhxbeaSYXzNLMRbvvJknpYcJG9DcG8h2kJJmukd9i
<civodul>heh fun :-)
<civodul>would using 'guix publish -C /some/dir' help?
<civodul>it doesn't produce exactly the same structure, but close to it
<civodul>s/-C/--cache/
<fps> https://ipfs.io/ipfs/QmXsZYuyyaDtCBn64sTJzb31HoNcnWn83kHbLcm6s1mygU
<fps>this is basically the thing ;) it now runs while true; do bash update.sh; sleep 1; done
<fps>the url above: https://ipfs.io/ipns/QmPMJYhxbeaSYXzNLMRbvvJknpYcJG9DcG8h2kJJmukd9i should already work as a substitute url
<fps>or relative to localhost:8080/ if you have a local ipfs daemon running
*civodul runs "guix weather --substitute-urls=https://ipfs.io/ipns/QmPMJYhxbeaSYXzNLMRbvvJknpYcJG9DcG8h2kJJmukd9i" :-)
<fps>ah
<fps>does it work?
<civodul>it's "doing something"
<fps>note though that this ugly collection of scripts with little to no error checking only caches everything from now on.. no buzilds from the past
<fps>and also since there's no push api it might miss some builds..
<civodul>yeah it found nothing this time
<civodul>re update.sh, it would be nice it you could leave more than 1 second in between queries :-)
<fps>eh ok ;) sure..
<fps>what would you recommend?
<jonsger>guix weather: error: ghc-haddock-library-unbundle.patch: patch not found ... :(
<civodul>fps: if you do that every minute it's good enough because usually there won't be tens of builds in a minute
<fps>ok
<civodul>anyway that's really cool
<civodul>if people can run a local IPFS HTTP proxy and use it, that's great
<civodul>we just need the IPFS package :-)
<civodul>roptat: i filed this: https://github.com/mquinson/po4a/issues/162
<pkill9>s
<demotri>I have a patch for arc-theme, a GNOME-theme. How can i test it?
<civodul>demotri: maybe you can add arc-theme to desktop.tmpl, "guix system vm" it, and try to change themes in the GNOME UI in the VM?
<demotri>civodul: You mean under "packages" of the "operating-system" record? Hm, I have a VM which I guix-system-reconfigured in that way but I can't see the theme in the gnome-tweak-tool. Have I done a mistake or do I have to register it somehow? I will double-check.
<civodul>demotri: yes, in the 'packages' field
<civodul>i don't know how GNOME themes work though :-)
<demotri>Me not either. I just went through the core-updates errors from a to z :-)
<civodul>heh :-)
<civodul>well if you have a arc-theme failed to build and now builds fine, that's already an improvement
<demotri>And I checked: There are at least some PNGs and SVGs in the output :-) Will reconfigure my VM again on core-updates and then see.
<fps>civodul: if you want to play with ipfs i have made a hacky package from their binary release.. 11:31 < civodul> if people can run a local IPFS HTTP proxy and use it, that's great
<fps>damnnit,. copy and paste
<fps>civodul: if you want to play with ipfs i have made a hacky package from their binary release.. https://github.com/fps/guix-packages/blob/master/ipfs-hack.scm
<demotri>Why are there so many evaluations in parallel on Hydra? Wouldn't it make more sense to stop older evaluations?
<brendyyn>I wonder if we could make a Friend to Friend configuration for ipfs instead of open Peer to Peer. that way people could choose to only download from a list of hosts. If it is unlimited then it runs the risk of allowing people to spy on what software a person is downloading like what can be done with bittorrent
<efraim>fps: from guix weather I got: .0% substitutes available (2 out of 9,188)
<civodul>demotri: indeed, i'm trying again to cancel old builds
<civodul>hmm i just realized that the installer doesn't actually install anything yet
<fps>efraim: what precisely does guix weather check?
<fps>i see that my mirror has e.g. https://ipfs.io/ipns/QmPMJYhxbeaSYXzNLMRbvvJknpYcJG9DcG8h2kJJmukd9i/nar/gzip/yhpvd67d785mpkkdr4g3l2chvzzg4dip-clang-3.5.2
<efraim>How many of the current builds there are substitutes for
<pkill9>fps: have you gotten ipfs substitutes working?
<efraim>2 of 9188 is small, but it that could totally be something else, and it still found them
<fps>i'm basically scraping the output of the berlin API.. here you can see all nars i got: https://ipfs.io/ipns/QmPMJYhxbeaSYXzNLMRbvvJknpYcJG9DcG8h2kJJmukd9i/nar/gzip
<fps>the majority are just outputs of test drivers, etc..
<pkill9>so you're download the nars from berlin to ipfs?
<pkill9>downloading*
<fps>yeah, checking wether builds finished and then i grab the narinfo and nar and upload them to ipfs..
<pkill9>cool
<pkill9>so you just need to find out how to export a nar from the store?
<fps>i also maintain an ipfs name (the ipns part) which i update when i add new stuff
<fps>so the URL is stable..
<fps>pkill9: actually that might be useful. BUT...
<demotri>civodul: "trying to cancel", that sounds like it is not that straight forward?
<fps>if people have the ipfs daemon running locally and install things through the local http proxy http://localhost:8080/ipns/QmPMJYhxbeaSYXzNLMRbvvJknpYcJG9DcG8h2kJJmukd9i/nar/gzip then they are automatically contributing to the swarm
<fps>oops without the /nar/gzip at the end :)
<civodul>demotri: it's clicking a button but sometimes it times out, and in this case it just said "0 builds canceled" :-/
<civodul>maybe i'm doing it wrong
<fps>is there a way to get a particular store item via guix package?
<pkill9>so inside those gzipped files are a single file, is that a nar combined with a narinfo in a format unique to guix?
<fps>like trying to get precisely yhpvd67d785mpkkdr4g3l2chvzzg4dip-clang-3.5.2
<pkill9>is it afile from `guix archive --export`?
<fps>pkill9: you were right back then. guix archive --export produces a signed nar
<fps>but the nars used for substitutes are unsigned
<fps>so these are not bit identical..
<pkill9>if i try to import it will it accept an unsigned nar?
<fps>i'm not sure..
<pkill9>fps: dunno if you've seen this, might be helpful https://github.com/NixOS/nix/issues/859
<civodul>pkill9: in Guix only signed nars can be imported
<civodul>signed and authorized
<pkill9>ok, that's good
<civodul>that's the least we can do ;-)
<civodul>pkill9: also, https://www.gnu.org/software/guix/blog/2017/reproducible-builds-a-status-update/ has some details on narinfos
<civodul>pretty much the only "doc" we have on this topic
<pkill9>ok, thanks
<demotri>civodul: I see. Hydra is so slow.
<civodul>yeah
<fps>h, i should probably only grab builds for "guix-master", eh?
<civodul>oh IPFS people will be at the R-B summit
<fps>when is this gonna be?
<fps>oh, in paris from 11th of dec
<fps>damn, in the middle of the week ;)
<civodul>yeah
<civodul>well at least we can tell them about what you're doing :-)
<fps>"there's a guy in our channel who's doing dirty evil hacks to use ipfs to distribute builds" ;)
<fps>i have this small library to finish in julia, which implements forward and inverse kinematics of rigid mechanisms in an opinionated way.. after that i might find time to do it more properly ;)
<ng0>civodul: you could arrange a mumble session or similar for people who can't make it to tune in, if participants agree
<fps>brendyyn: well, i didn't think of the information of what software you download to be sensitive..
<fps>brendyyn: there is a way to run a separate ipfs network iirc
<fps>or at least there should be :)
<fps>in a similar vein how there are partitions of blockchain networks into testing and "real" networks..
<fps>one (brittle) way would be to provide our own set of bootstrap nodes..
<civodul>ng0: the R-B summit is really an in-person meeting far away from keyboards, so i think this wouldn't be appropriate
<roptat>but anyone could join your parallel network, so that doesn't solve the issue I tihnk
<civodul>fps: we could add a hook in 'guix publish' to run code when an item has been baked, and use that hook to run "ipfs add" or whatever it's called
<civodul>all this could run directly on berlin
<fps>civodul: that's true.. there's one important feature i didn't implement yet though.. it would make entries in the directory published eternal even if the data entries disappear from the disk
<fps>civodul: as long as someone in the swarm still had the narinfo/nar in their local repo it could still be served.. it's a couple of lines to add to the scripts, but i won't get to it today ;)
<fps>it boils down to instead of ipfs add -r cache/, where cache is my local cache of all the downloads, i'd manipulate the DAG directly to add entries to it for newly cached items
<civodul>ok
<fps>once the hacky prototype is feature complete we can think about running it all properly on berlin
<fps>i can try to write a little README.md this weekend that explains the rationale and implementation so you have a basis for discussion at R-B
<fps>a repo for this junk:https://github.com/fps/guix-ipfs-cache
<civodul>cool, thanks!
<fps>np :)
<fps>roptat: i'm not conviced that is an issue though.. or rather: it depends on the user whether it's an issue or not
<fps>roptat: there are distributed datastores that make better guarntees about confidentiality like i2p. but that comes at a hefty price
<fps>namely sloooooooooooooooooooooooooooowness :)
<fps>i guess as long as the caveat that other network participants can identify what store items you download is documented well, then the user is free and informed to decide for or against using it
***slyfox_ is now known as slyfox
<efraim>Ipfs is written in go?
<fps>eh, i had a bug in one of the scripts that missed quite a few nars ;)
<fps>efraim: ipfs is a protocol and there are several implementations. one is in go
<fps>it's the most complete afaik
<efraim>I didn't realize there were multiple implementations. Was wondering since go doesn't build yet on armhf or aarch64
<efraim>I know i2p has a c implementation
<fps>wow, lots of clang builds i missed previously ;)
<fps>should i only mirror what comes from guix-master?
<fps>or everything for the time being? ;)
<bavier`>civodul: would it be safe to conditional compile guix/swh.scm, or is it finally time to make guile-json a required dependency?
<civodul>bavier`: good point! i thought guile-json was required already :-)
<civodul>probably we should just require it, indeed
<bavier`>there's some cleanup that would go along with that
<jonsger>opensuse use it since nov 2015 as dependency :P
<efraim>Is guile-json guile2.2 only?
*efraim is on a phone
<jonsger>efraim: no, at least it worked fine with guile2.0
<bavier`>efraim: I'm using it with guile 2.0 atm, and guix has a guile2.0-json package
<efraim>Sounds good
<civodul>bavier: if you could prepare a patch, that'd be great
<bavier`>civodul: sure thing ;)
<civodul>awesome :-)
<efraim>i might switch sbcl to using clisp for armhf and aarch64, ccl doesn't build for armhf and doesn't seem to support fully aarch64 yet
<efraim>well I did something right yesterday, hydra just reported x265 for armhf as a newly succeeding job
<efraim>for sbcl on aarch64: Error opening /dev/tty: No such device or address
*janneke revisits scheme-only bootstrap work on wip-bootstrap
<baconicsynergy>hello friends :)
<bavier`>hi baconicsynergy
***rekado_ is now known as rekado
<rekado>I’m getting this error: substitute: guix substitute: error: TLS error in procedure 'handshake': Error in the pull function.
<rekado>:(
*rekado tries with fewer substitute servers
<baconicsynergy>I'm attempting to install guix on parabola, and I followed the instructions at https://wiki.parabola.nu/Using_GNU_Guix_on_Parabola . However, I'm still unable to use guix in any capacity. Am I missing something?
<roptat>hey, I'm trying to update the translation for the next release, but I'm missing some context
<roptat>what's an example of "failed to create ~a derivation: ~a"
<roptat>I'm not sure what the first ~a is, so I'm not sure about where I should put it in the sentence in my language
<efraim>roptat: it's in guix/scripts/lint.scm
<bavier`>I think the first is a number
<efraim>system type
<bavier`>ah, ok
<efraim>second is an "error message"
<bavier`>might call for one of those "note to translators" comments
<roptat>hm... so "failed to create aarch64 derivation: some error message"?
<bavier`>baconicsynergy: can you provide some details? what isn't working?
<efraim>roptat: that's what it looks like to me
<roptat>ok, thanks
<rekado>hmm, I haven’t done anything (wasn’t even around computers). Don’t understand the error message.
<baconicsynergy>bavier`, guix pull is hanging, and i can't search for packages or install anything
<efraim>rekado: I think there's something wrong with hydra's substitutes
<efraim>it's hanging for me when I try to get armhf substitutes
<rekado>hmm
<rekado>seems so.
<rekado>I’m only using mirror.hydra.gnu.org and berlin.guixsd.org
<rekado>with only berlin.guixsd.org it seems fine.
<bavier`>I think our github updater doesn't work for origins using git-fetch
<bavier`>would be nice to fix that
<civodul>rekado: mirror.hydra.gnu.org seems to be dead, i can't log in
<civodul>we can still ping it but ssh and http don't respond
<OriansJ>civodul: ssh in, check to see if the httpd service is running and then check the iptables rules
<rekado>OriansJ: we can’t ssh :)
<OriansJ>rekado: well hookup the crash-cart and serial shell in
<roptat>civodul: I think the tarball you sent contains an out of date guix-manual.pot...
<roptat>looking at it, it looks like it's from 0.15.0-pre1
<civodul>roptat: doesn't "make dist" regenerate it?
<civodul>it does for the other pot files
<roptat>it seems it doesn't...
<civodul>we should definitely fix it
<roptat>agreed
<roptat>I'll look at it
<civodul>in the meantime, would you like to send a new tarball?
<OriansJ>I'm assuming the hosting provider has a serial console access through an ssh-proxy or via a java console after web-login.
<roptat>civodul: can you do it? you only need to run 'make doc-pot-update' before 'make dist'
<civodul>OriansJ: i'm checking with the "hosting provider" (grothoff's former employer)
<civodul>roptat: okay
<roptat>thanks
<roptat>do you know how I add this as a prerequisite for the dist target?
<civodul>simply "dist: doc-pot-update"?
<roptat>yes, you're right
<civodul>or "dist-hook"?
<civodul>hmm
<civodul>yes, "dist-hook: doc-pot-update" looks better
<civodul>feel free to push it!
<civodul>roptat: ↑
<roptat>sure
<civodul>rekado: i guess we should send a note on info-guix about mirror.*, thoughts?
<pkill9>is anyone here knowledgeable on linux permissions? My user account can read/write this file even though they're not on the 'audio' group: crw-rw----+ 1 root audio 116, 5 Nov 28 20:01 /dev/snd/controlC1
<baconicsynergy>It seems like my problem is related to hydra going down
<baconicsynergy>I uninstalled the guix package from parabola and tried to do it from scratch via https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html , but it won't find anything
<bavier`>baconicsynergy: you say something like `guix package --search=hello` doesn't work?
<baconicsynergy>bavier`, i was in error. i could search for packages, but not install them
<baconicsynergy>i was doing 'guix -s package' like a gosh darn fool
<bavier`>baconicsynergy: :), np. you should still be able to install with '--fallback', if you don't mind building packages locally
<baconicsynergy>oh cool!
<OriansJ>civodul: I would be heavily suprised if any modern infrastructure doesn't have a terminal server or (Intel Management/AMD PSP) administration proxy server. Now if you'll get access is an entirely different matter...
<OriansJ>(sometimes referred to as IPMI service)
<civodul>OriansJ: i'm aware of that :-)
<fps>ugh, can't do guix pull with 12G of RAM ;)
*vagrantc just figured out that ln -s .config/guix/current/bin/guix into ~/bin/ on debian to be easier than updating PATH
<vagrantc>as by default ~/bin gets added to path on debian, rather than having to edit .bashrc or whatever
<fps>oooh, it was guix weather which drove ipfs to have 19G RSS
<fps>oops
<vagrantc>although it still will lack the other inevitable variables
<fps>ah, no, it was only 1.9G. hmmm
<baconicsynergy>So out of curiosity, is there anyway for coreboot/libreboot to play nicely with guix system reconfiguration? the GRUB payload is flashed into the BIOS memory. any thoughts on this?
<baconicsynergy>is there a way for guix to modify the GRUB configuration thats flashed into the BIOS to create bootloader entries for each reconfiguration?
<roptat>civodul: should 'make dist' also update the po files according to the new .pot?
<fps>oh wow, python 3's test suite eats more than 10G or RAM.. hrmpf
<civodul>roptat: i think that already happens automatically no?
<civodul>well for the other po files at least
<rekado>civodul: I hope this is just a transient problem. If we find that it will be offline for a little longer, though, we should make an announcement.
<roptat>it doesn't seem so, but I think that's because we have almost no support from the autotools here
<bavier`>fps: I think that issue's been fixed on core-updates, or core-updates-next, iirc
<rekado>pkill9: for pulseaudio being in the “audio” group is optional and depends on how things are configured. See https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/
<civodul>rekado: i made an announcement, though i hope it won't last long
<rekado>thank you!
*civodul feels like a fire fighter today :-)
<rekado>Starting from Friday I should be a little more active again.
<rekado>handover of the old apartment is tomorrow and I’m still doing repairs… :(
<civodul>oh
<pkill9>thankyou rekado
<civodul>that's never fun
<rekado>we have these old wooden double windows, and I need to repaint the inner windows as well as the inner side of the outer windows.
<rekado>it’s a lot of work and it’s messy too…
<rekado>painting walls is easy; they’re at least somewhat smooth. The windows on the other hand…
<rekado>ugh.
<madage>hello guix!
<baconicsynergy>madage, hiiii
<madage>I'm trying to compile guix from source but got stuck on compiling gnutls with guile support
<madage>when the configure script tries to search for guile development files it fails, though they are installed
<rekado>madage: did you install the guile development package in addition to Guile itself?
<madage>searching the configure script for the problematic function, I've found out that it is trying to check for guile versions 1.8 and 2.0
<madage>rekado: I've compiled guile from source
<madage>but it's version 2.2
<civodul>rekado: bah i can imagine, plus you have to open the windows and the air may be fresh out there ;-)
<madage>I've inserted 2.2 on the script and then it completes with success
<madage>but now I'm wondering if I'd better recompile a prior version of guile
<rekado>2.2 should be fine
<rekado>1.8 won’t work.
<bavier`>madage: is it an older version of gnutls?
<rekado>make sure that the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH is set to the appropriate locations.
<bavier`>the 3.5.18 version doesn't look for a particular version
<madage>bavier`: it's version 3.6.4
<civodul>roptat: thanks for the fix!
<madage>rekado: thanks, I'll make sure to add those
<roptat>yw
<grothoff>To whom it may concern: for the mirror.hydra.gnu.org outage, I've contacted the local sysadmin who might be able to help. The machine is in Munich.
<grothoff>fdold: if you are still in Munich, you should urgently contact Ludo and plan a trip to TUM...
<civodul>thanks grothoff!
<jonsger>madage: you maybe need a patch. For openSUSE I use that one https://build.opensuse.org/package/view_file/security:tls/gnutls/gnutls-enbale-guile-2.2.patch?expand=1
<jonsger>with that patch it builds also with guile-2.2 :)
<madage>thanks jonsger! I'll have a look at it
<bavier`>madage: it seems the gnutls@3.6 configure script was generated with guile@2.0 installed
<bavier`>and otherwise does not declare compatible guile versions
<jonsger>I'll file a bug upstream
<bavier`>imho using versions like this in configure scripts can only lead to disappointment
<madage>jonsger: that patch is similar to what I did, except I didn't change the aclocal.m4 file. I'll try and compile then...
<civodul>roptat: sent the new tarball
<jonsger>madage: https://gitlab.com/gnutls/gnutls/issues/631
<roptat>civodul: thanks
<madage>jonsger: nice, that was really fast
<civodul>roptat: i hope Benno won't be mad at me ;-)
<vagrantc>any reason why GUIX_LOCPATH doesn't end up in .guix-profile/etc/profile ?
<catonano>madage: are you bumble's rumple on Mastodon ?
<vagrantc>so, sometimes when i do "guix build ..." it just shows me a small number of lines for each item it's building, and sometimes it spits out the whole output of the build log as it's building ... what controls that?