IRC channel logs

2016-12-13.log

back to list of logs

***bavier2 is now known as bavier
***jje is now known as Guest20859
***Helius_ is now known as Helius
<efraim>i see we moved core-updates to gcc@5 again, time to rebase my patches
<efraim>might as well gc on my aarch64 board since i'll have to compile from scratch again
<reirob>Hello, I just wanted to check if obnam can be installed in guixsd
<reirob>guix package --list-available
<reirob>doesn't show it
<reirob>So I ran:>
<reirob>guix refresh
<reirob>but then I got an error:
<reirob>ERROR: In procedure scm-error: ERROR: Error downloading release information through the GitHub API. This may be fixed by using an access token and setting the environment variable GUIX_GITHUB_TOKEN, for instance one procured from https://github.com/settings/tokens
<reirob>What does it mean?
<reirob>Does anybody know how I get obnam installed on guixsd?
<reirob>I want to check if I could recover the backups that I have done on another system
<efraim>sneek: later tell ludo: should we switch gcc-boot0 from gmp-6.0.0a to gmp-6.1.0?
<sneek>Got it.
<efraim>sneek: botsnack
<sneek>:)
<efraim>reirob: guix refresh checks for upstream releases to make updating the package definitions easier
<efraim>currently obnam isn't packaged
<efraim>for updating the list of packages and versions, you want `guix pull'
<reirob>I guess I don't know what upstream release means - I just wanted to update the list of packages to see if obnam is there. Trying guix pull now
<reirob>If obnam is not there, then I will try to build it from source
<reirob>I am too new for the guix stuff - somehow managed to make it work on an old libreboot thinkpad
<efraim>upstream is the actual authors of the programs
<efraim>a number of people here have librebooted thinkpads
<reirob>So, what would I use upstream releases for? I mean as a normal user?
<efraim>guix tries to blur the destinction between developers, maintainers and "end users", and tries to make it easy to package your own programs or different versions of programs
<efraim>g2g, have to run to the store while the sun is out
<reirob>So normally, to update my package to the latest ones, what should I run?
<reirob>Thanks efraim!
<reirob>Well, now I am trying to build obnam and obnam needs python. So I checked with guix package --list-available and I see that there are 3 different versions of python available
<reirob>Obnam need python 2 and guix has 2.7.12
<reirob>how can I tell it to install the 2.7.12 version and not the latest one?
<janneke>hi guix!
<thomasd`>reirob: i think `guix package -i python@2.7.12'
<thomasd`> https://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-package
<thomasd`>janneke: your Mes project looks interesting. I recently saw a similar project, but can't remember the name now (something like "0stage")?
<janneke>thomasd`: thanks! That's probably OrianJ's https://github.com/oriansj/stage0
<janneke>last time i looked their plan was not to bootstrap via scheme, but you never know
<reirob>Thank you thomasd` !
<reirob>Trying it out now
<thomasd`>janneke: yes exactly :) so do I understand it correctly that the projects are complementary, and the work in stage0 could lead to the minimal C compiler needed to bootstrap your C interpreter?
<janneke>thomasd`: interesting ideas!
<janneke>i'm not sure how much overlap or underlap the projects have, iwbn to chat a bit about that with OriansJ
<thomasd`>well I'm just asking you, having 0 background knowledge :)
<janneke>:-)
<janneke>when I started mes, stage0 was in development and that inspired me
<janneke>i thought: ah, next step will be a scheme interpreter...but they took another route
<janneke>i really wanted to see what would happen to the scheme route, so i started that
<thomasd`>I wonder about the genealogy of the compilers we're using every day. What were they originally bootstrapped from, and when? Presumably, the ancestry of a gcc binary shipped with a current linux distribution could go back a long time?
<thomasd`>janneke: I also understand that you coded parts of your interpreter in C instead of scheme for performance reasons? What's the order of performance difference?
<janneke>thomasd`: 10-500, but the interpreter could and should get some performance fixes
<janneke>performance vs minimal bits in C is currently a tradeoff that's hard to make
<thomasd`>to bootstrap a system, performance is probably not the highest priority, but at a 500x penalty, I suppose patience runs out :-)
<roelj>Does anyone know about this one: When running guix build bootstrap-tarballs it errors with: "guix: offload: command not found".
<roelj>Anyone?
<janneke>roelj: i'm going...think i've seen this before...cannot figure out when
<janneke>and assert if
<roelj>janneke: Thanks. I'm trying to disable the offload facility, but it shouldn't be enabled anyway.
<thomasd`>so how did yesterday's meetup go? any wonderful new developments? :)
<davexunit>oh there was a meetup? fun
<thomasd`>some people met in Berlin, I believe
<thomasd`>I think that's why yesterday was a quiet day on the mailing list and here
<roelj>I was at the meeting too
<roelj>It was nice. Ricardo has the meeting minutes.
<roelj>Hm. I changed nix/scripts/offload to not run "guix offload $@", but that didn't really get me any further: "guix build: error: build failed: unexpected EOF reading a line"
<roelj>And there seems to be a compilation error when building guix: "gnu/packages/image.scm:1080:38: illegal character in escape sequence: #\\("
<roelj>So, I finally found a commit that isn't affected by this problem. And this commit is from November 15th.
<rekado>Yes, the meeting was nice! Didn’t expect to be able to fill a whole day with relevant Guix discussions :)
<rekado>We’ll share the condensed meeting minutes on the list soon.
<rekado>I’m at the reproducible build summit right now (and for the next two days)
<davexunit>rekado: cool!
<buenouanq>that is the greatest name for an event
<buenouanq>when's the bootstrapping congress?
<rekado>buenouanq: I hope we’ll talk about bootstrapping tomorrow. It’s on the roadmap.
<rekado>did some brainstorming to identify issues we’d like to see discussed and the bootstrapping problem(s) are on the radar.
<efraim>sneek: later tell roelj you can work around the auto-offload problem with the --no-build-hook flag
<sneek>Got it.
<efraim>sneek: botsnack
<sneek>:)
<efraim>I want to write a patch to pass the flag "-T 0" each time we call xz, but I only have dual core processors so I can't really test the multithreadedness of it
<ng0>I have a quadcore around here i think
<ng0>if taht helps in testing it
<rekado>sneek: later tell roelj Your problem seems to be that you build Guix in “guix environment guix”, which contains “guile-ssh”. Offloading is enabled when GuileSSH is found at build time. When you run Guix later, however, you do not seem to have GuileSSH available, which results in an error. To fix this: 1) remove guile-ssh from the environment in which you build Guix, or 2) install GuileSSH, or 3) pass “--no-build-hook”
<sneek>Okay.
<rekado>sneek: thank you, friendly bot. Have a botsnack!
<sneek>:)
<Helius>installing gnutls (guix package -i gnutls ) I get a test fail on name-constraints.
<Helius>actually I have installed guix last week from binary with out problems. Today I wipedout everything and tryed the whole install from the begining but I got the gnutls error.
<Helius>and guix pull does not work as well
<thomassgn>hi, why is lsh the default ssh implementation when it looks like it's been unmaintained for 3+ years?
<alezost>probably only civodul knows but he's not here at the moment
<alezost>I think originally it was because lsh is a GNU project while openssh is not (but I don't really know)
<thomassgn>alezost:ok, do you know if people use one or the other?
<thomassgn>also Thanks
<rekado>Helius: could you tell us the exact error message you get?
<alezost>thomassgn: well, I've been using lshd (the daemon) just because there was no openssh-service at the time and I don't have any problems with it; but for client tools, I use openssh (installed in my user profile)
<Petter>Looking for what to set as (version) for a library without a release. Manual doesn't say and in gnu/packages I see 1. (version "20160726.53127f6") and 2. (version (string-append "0.0-0." (string-take commit 7))) seemingly dealing with this situation.
<thomassgn>kool.
<Helius>rekado: http://pastie.org/10982264
<Petter>For Go libraries I expect to see more of this.
<Petter>I think "date.commit" would be the better option.
<alezost>Petter: AFAIK the convention is to do (string-append "0.0-0." (string-take commit 7))
<Helius>rekado: I hope that is enough, or tell me how to provide a better log
<Petter>alezost: What if some new program is pinned to an older commit?
<alezost>Petter: it looks improbable :-) I think no one thought about this possibility
<rekado>Helius: I don’t know why gnutls fails to build on your machine, but it looks like you should be able to download a binary for it.
<rekado>Helius: is Guix downloading any binaries for you from hydra?
<Helius>rekado: I think some yes, at the beginning guix told me to use the fallback option
<Helius>rekado: is there a sort of check up procedure ?
<Petter>What I mean by "new" is "new to Guix". The "next" program could easily be pinned to an older version of the dependency than the program that happened to be packaged first.
<Petter>I think we should have a solid plan for this starting to package Go programs.
<Petter>I'm not surprised the first of Syncthings library I went to didn't have a release.
<Petter>*libraries
<rekado>Helius: FWIW, I just updated to the latest version of Guix and asked Guix to give me gnutls (“guix build gnutls”) and it downloaded the binary from our build farm successfully.
<rekado>Helius: what architecture are you on?
<rekado>(I’m on x86_64)
<Helius>rekado: Ubuntu 14.04.3 LTS (GNU/Linux 3.19.0-75-generic x86_64), it is a virtual machine running on Proxmox
<rekado>okay. With x86_64 you really should be getting the binary.
<rekado>There’s no reason why a local build would be necessary.
<Helius>rekado: I agree, is there a way to force the download ?
<Helius>rekado: I need a running guix because I want to contribute to bioinformatics and R packages
<rekado>Helius: nice!
<rekado>Helius: you wrote that “guix pull” doesn’t work for you. Is this the same error?
<Helius>rekado: same, yes
<rekado>i.e. it also tries to build gnutls and then fails?
<rekado>hmm
<rekado>how did you install guix?
<rekado>did you use the binary installation method?
<Helius>rekado: https://gist.github.com/helios/d7639aca96f0e305e10c7b95d31bf77b
<rekado>Helius: could you show me at which point in that file you run into trouble?
<Helius>ok I can re do every things
<Helius>from zero
<rekado>after installing with the binary method I suggest updating Guix for the current user by running “guix pull”
<rekado>everything up to “guix archive --authorize …” looks okay to me.
<rekado>at this point you should have a working guix, albeit outdated.
<rekado>if you were to install things with that version of guix you’d likely have to build some things from source.
<rekado>so I suggest doing “guix pull” as the user that you want to continue to use for your work.
<rekado>if you do “guix pull” as root it’s only going to affect root, not any other user.
<Helius>rekado: ok I am redogin everything
<rekado>Helius: another thing in your notes: “update your .bashrc with output from …” that’s not necessary (and it shouldn’t be bashrc). You can just do “source /path/to/guix-profile/etc/profile”.
<rekado>every profile comes with an “./etc/profile” that sets all needed environment variables.
<Helius>rekado: ah thanks!
<rekado>I’d also like to suggest to never run /gnu/store/…/bin/something directly
<rekado>that’s what profiles are for.
<rekado>the fact that things are somewhere in the store is an implementation detail. Users shouldn’t have to know of locations in the store.
<rekado>So, once you made /var/guix/profiles/per-user/root/guix-profile/bin/guix available globally as /usr/local/bin/guix users can just run “guix pull” to get the latest.
<rekado>(it’s similar to “apt-get update”, but only for the current user)
<rekado>(a link will be created in ~/.config/guix/latest, which points somewhere into the store)
<rekado>the stuff at “alternative with environment” could be simplified as just “guix environment guix”, which gives you everything you need to build or hack on guix.
<Helius>ok, I am after “authorize”,
<rekado>I guess I don’t understand what you’re trying to achieve, but this looks really weird: “# copy the generated guix-r on the other side/node”
<Helius>running guix pull as my user
<rekado>okay
<rekado>if this is spewing out a lot of text and compiling dependencies something is probably wrong
<Helius>rekado: last week I created a a tar.gz with a custom build of R (v3.3.2) and unpacked the archive on another machine without the whole guix installation.
<rekado>you can export the necessary subset for a given package (i.e. its closure) with “guix archive --export”
<rekado>maybe this is helpful: http://guix.mdc-berlin.de/documentation.html#sec-6-2
<rekado>(that’s how we’re using Guix at my institute and how researchers can share environments)
<rekado>“I think there is a better approach other than installing the R package into the main store” <— everything ends up in the store; things you build, sources, derivations, profiles, etc
<rekado>you could just build the thing with “guix build r”, but that only skips generating a new profile.
<Helius>thanks ! I am really new and trying to figure out things
<Helius>btw this is the error https://gist.github.com/helios/6d13037a7ae7be40f118573545cbccb3
<rekado>odd, but using “--fallback” should be fine here.
<rekado>yeah, no problem. I hope we can help you figure things out :)
<Helius>rekado: yep but fallback is not available with guix pull
<Petter>Do you know which license this is? https://github.com/bkaradzic/go-lz4/blob/master/LICENSE
<rekado>Helius: oh, hmm.
<rekado>Petter: this looks like BSD-2: https://opensource.org/licenses/BSD-2-Clause
<rekado>Helius: I don’t know how to get around this error (or why this even happens).
<Petter>rekado: Indeed. Thank you!
<rekado>“guix pull” is kinda weak and many of us don’t use it
<rekado>(because we work with a git checkout most of the time)
<rekado>if you’re open to experimentation maybe it would be best to go the git route directly.
<rekado>i.e. clone the guix git repo, build that, then link ~/.config/guix/latest to point to /path/to/your/guix clone
<rekado>I admit that this isn’t an optimal first impression :-/
<Helius>rekado: ok, I have the git repo, but it is very strange that last week everything was working
<rekado>maybe someone else here has an idea about what this module-import-compiled mismatch is about.
<rekado>Helius: guix pull just downloads “master”
<ng0>Petter: so go-build-system (or golang-?) build system in its basic functionality works now?
<rekado>could be that something happened between last week and today that broke guix pull
<rekado>dunno
<Petter>ng0: Yes. I've been able to build Syncthing with it :)
<ng0>cool
<ng0>nice work!
<Petter>I've called it "go-build-system".
<Petter>Thanks! :)
<Petter>Currently beefing up the Syncthing libraries with description, licenses etc.
<Helius>rekado: thanks for the link and the help I will study more
<ng0>any pointers how I figure out dependencies for go applications if they are not listed? will the go build system complain? there's this software I wanted to package back on gentoo a year ago and never did it
<ng0>basically onion scan security
<ng0>Petter: ^
<ng0>oh got it
<Petter>ng0: There.. oh.
<ng0>only one external dependeny i think
<Petter>Easy to see if it's only a file or two, by opening them and looking at "imports" at the top.
<ng0>the main.go in toplevel lists only the one external import :)
<ng0>maybe
<Petter>Otherwise there's "go list" that can be used.
<ng0>golang.org/x/crypto/ssh/terminal
<Petter>go list -f '{{.Imports}}' .
<ng0>ok, thanks
<ng0>I'll try tomorrow or within the next days. lots of stuff to do, and I'm still tired from the journey today
<Petter>I don't see any external dependencies though, only standard lib.
<ng0>that's not the appliaction
<ng0>that's the dependnecy
<Petter>Oh, ok.
<ng0>origin https://github.com/s-rah/onionscan.git (fetch) is the appliaction
<efraim>for the go-build-system, would it make sense to have a #:go keyword, or is everything supposed to be built with the latest version?
<Petter>For pinning to a version of the language, or?
<efraim>like with python, we can specify to build with python2
<efraim>would there be a reason to build with not the latest version
<Petter>They make great efforts to not break the language for each dot-release. Except in the "unsafe" package; projects using this are on their own.
<Petter>So, at least projects using unsafe would require a specific Go version.
<Petter>It's a good point.
<rekado>does anyone know how to actually deploy changes to the website?
<rekado>I’ve updated and pushed the code in guix-artwork, but I don’t know how to deploy the changes
<lfam_>rekado: CVS is used for this
<civodul>'lo Guix :-)
<lfam_>Hello!
<Petter>Salut!
<artyom-poptsov>Hello civodul :-)
<civodul>hey artyom-poptsov!
<civodul>nice to see you here ;-)
<artyom-poptsov>:-)
<artyom-poptsov>civodul, have you received my email?
<thomassgn>what are currently good ways of splitting of some parts of a system config to modules? E.g. having a webapp with a DB in an "isolated" environment. Not sure if guile modules is the way to go or if there are other more appropriate methods?
<civodul>artyom-poptsov: to guix-sysadmin? yes, but i'm a bit swamped right now :-)
<civodul>i trust you to do the right thing anyway ;-)
<artyom-poptsov>civodul: OK, thanks. :-)
<artyom-poptsov>civodul: I'll continue my work on the 'pgrep' implementation, but I'd love to hear comments from Guix developers' perspective.
<artyom-poptsov>At the end of the day, Guix is the biggest project in which my library is used so far (at least, as far as I know.)
<civodul>artyom-poptsov: sure, i'll reply "sometime soon" if nobody else does
<civodul>i really appreciate your responsiveness on this!
<artyom-poptsov>civodul: Thanks. There's no need to hurry with the email reply; "sometime soon" is soon enough.
<civodul>ok :-)
<lfam>Do we have a package of 'crypto++'? I'm wondering if we need to address this: seclists.org/oss-sec/2016/q4/660a
<lfam>Woooooooooow: https://www.debian.org/security/2016/dsa-3733
<lfam>Awesome to fetch the updates over HTTP