IRC channel logs

<pmikkelsen>hello guix, some time ago I read it was possible to 'convert' a debian system into a guixsd one, but do you think it is possible on a VPS that runs openVZ? my understanding of it is that every VPS has to run the same kernel as the host or something :)

<pkill9>how do i untar a bz2-compressed tar file with a trivial builder?

<snape>pkill9: (system* "tar" "xf" "file.tar.bz2")?

<pkill9>i tried that but it can't find bzip2, even after adding it to native-inputs

<pkill9>unless it's some extra stuff i have at the beginning

<pkill9>i'lltry removing that

<pkill9>ok that helped

<ng0>pmikkelsen: I plan t owrite a follow-up to wingo's email + my own guide I published a while back

<ng0>for example on DigitalOcean it's easy

<pmikkelsen>ng0: ah okay, do you have a recommended VPS provider for running guixSD?

<ng0>idk.. 1984 and DO are the ones I've ran it on

<pmikkelsen>okay thanks :)

<ng0>would've picked 1984 again, but if you're low on bugdet and have something as demanding as GuixSD the smallest instance at 1984 isn't good. you can scale up, but scaling down doesn't work the way they are made

<ng0>but if 17 - 30 euro / month is okay for you, contact 1984. they were even open to adding official GuixSD support

<ng0>I have some notes on theoretical support for IN-Berlin, but that's up to those who want to test their patience

<ng0>those ISPs differ sometmes only in minor details

<pmikkelsen>Unfortunately my budget is rather low as this is mostly for experimenting, so I think I might go with digital ocean then

<ng0>it's getting early/late here, but I'll send a short email as soon as I can

<ng0>on the weekend / next weekend

<ng0>oh. we have saturday. well, tomorrow or next weekend then

<pmikkelsen>ng0 sounds good, it's also getting late here so i better go ;)

<ng0>bsaically: follow what wingo wrote, but take the small instance/droplet (1GB RAM), upgrade it to 2GB RAM temporarily (depends on the usage but 2 GB RAM is what we still need to compile Guix without waiting for many many hours), when you come to the reconfigure step, let it fail once as written and when you do the cp+move step include "cp -r /etc/guix" in there.

<ng0>I've done this a couple of times, so I'd first experiment at home.. or use the server, you can shred it if you break it without means for recovering

<ng0>I might end up writing a script for that, but it would be tailored to my idea of the process + my wip'ish guix templating

<pmikkelsen>thank you very much ng0 :)

<pkill9>is there a decent guide to making your own trivial builders?

<OriansJ>sneek: later tell janneke we have a new toy for him (https://github.com/oriansj/kaem) that way we can remove shells and make from our build process

<sneek>Got it.

<OriansJ>sneek: botsnack!

<sneek>:)

<thomassgn>hmm, guix complains about not finding packages like python-2; both from 'guix package -i python-2' and 'guix environment python-2'. I see my $GUIX_PACKAGE_PATH only contains my own module dir. I think it used to have guix's also?

<iyzsong>thomassgn: the syntax had change to 'python@2'

<thomassgn>ok, trying. But the '.config/guix/latest/gnu/packages/python.scm' contains '(define-public python-2 python-2.7)' and a full definition of python-2.7.

<thomassgn>so it does seem to work with the @ notation, at least for guix package -i

<iyzsong>yes, packages are lookup by name@version, 'python@2' will find a package which has the name 'python' and version starts with '2'.

<iyzsong>the scheme variable name 'python-2' has nothing to do with packages lookup.

<thomassgn>ye, but if .... hmm, I clearly don't understand the mapping of that ^^

<thomassgn>but it's allright. don't have a mind to understand it now anyway :)

<thomassgn>Thanks

<iyzsong>you're welcome :-)

<shorttraveler>quick question: am i correct in believing it is only root who can create and then use arbitrary package definitions? [GUIX_PACKAGE_PATH seems ignored in non-root usage] this is something i expect to be the case for security reasons - but guix has pleasant surprises in it :)

<ngz>Hello. I'm having an error when trying to use "./pre-inst-env" (after using autoreconf -vfi and ./configure --localstatedir=/var), something like guix build error, cannot find guile.2.0.9.tar.xz for system x86_64-linux

<ngz>I didn't call "make" beforehand, would it be the reason?

<ng0>what was the decision why guix pull shouldn't support git:// URLs, or is it because of libgit2? I'M getting Network is unreachable for git:// URLs to pull from

<ng0>woops. okay it is my server or DNS

<ng0>never mind

<thomassgn>shorttraveler: I use GUIX_PACKAGE_PATH as user all the time.

<thomassgn>I put it in one of the configs bash source when it starts (I think at login) and then I have my own packages available through guix

<shorttraveler>hmm. thanks thomassgn! on closer inspection it would seem i was not expanding ~/ when setting that environmental variable

<shorttraveler>works now :)

<thomassgn>:)

<ngz>I think there is a documentation bug about localstatedir

<ngz>The manual states about garbage-collector root that "That directory is normally

<ngz>‘LOCALSTATEDIR/profiles/per-user/USER’"

<ngz>According to my understanding, it should be `LOCALSTATEDIR/guix/profiles/per-user/USER'

<ng0>Can someone clarify the chat some people here had about the certbot-service? If *one* certificate included multiple ALT-DNSname (name: foo.org + 2.foo.org + 3.foo.org), would this currently be an issue with the service? My only deployment of the certbot-service is a substitutes server with just one domain in the cert, but now I need more on another server.

<snape>ng0: currently it's not possible to include alt names in one certificate

<snape>that's the issue. I'm working on it. Hopefully I'll send the patches tonight, or tomorrow.

<snape>I'll rework quite a lot of things too

<snape>in particular, the renew command doesn't work

<snape>because "-d" can't be used with "renew"

<snape>Also, I'll add an "email" field, that will be mandatory

<snape>and cert-name will be specified, so that people can use another name for their certificate

<ng0>oh. so when I created them the usual way (with -d foo -d bar etc) it won't work currently?

<ng0>oh, you were faster

<ng0>oh, nice

<snape>it work for creation (certonly), but not for update (renew)

<snape>the solution is to use certonly for renewal as well

<ng0>another thing I find troubling, at least when I used certbot on Debian, was that the ssl certfile name changed randomly.. is this certbot normal behavior?

<snape>yes, but it won't happen with my patches, because I will use --cert-name

<ng0>my renewal script involved a pre-hook where I stoped nginx, used the whole -d bla lines and a post-hook where I started nginx again

<snape>if you don't use --cert-name and a certificate with the same name already exists, the new one will be named with an extra "-1" or something

<ng0>I never ran renew on its own :)

<ng0>oh

<ng0>makes sense

<ng0>daw

<snape>well, you could as well stop nginx, use "certbot renew", and restart nginx

<snape>"certbot renew" will renew all certificates, so you don't need to provide the "-d" options

<snape>but for the service we will renew only the certificates that are registered

<snape>not all of them. Thus we won't use "renew", we will use "certonly" instead.

<ng0>is "-k" still an option for certbot? it was for acme.sh, for example -k 4096 for 4096 keylength

<snape>there is --rsa-key-size

<snape>the default is 2048. Do you think I should add a field for this?

<ng0>yes, or maybe an optional-arguments list

<snape>that'll be a field with a default-value of 2048

<snape>(certbot-configuration) vs (certbot-configuration (rsa-key-size 4096))

<ng0>hm.. ok

<jlicht>hi guix

<pkill9>hi

<pkill9>i'm naming my firstborn 'Guix'

<pkill9>joke, i don't want children

<jlicht>pkill9: heh, reminds me of "A boy named Sue" ;-)

<davidl>How can I install both python 2.7.13 and python 3.5.x?

<pkill9>davidl: `guix package -i python@2.7 python` i think will work

<wigust>davidl: As I remember and if nothing changed, you cannot do it. But you could use a separate Guix profile either for 2 or 3 version.

<pkill9>oh yeah you can't :/ it says they conflict

<pkill9>not sure why though, I can run `guix environment --ad-hoc python@2.7 python` and it works

<wigust>pkill9: Because of PYTHONPATH

<wigust>pkill9: if you do this in guix environment, you will PYTHONPATH value will be python 2 libraries

<wigust>*you will get PYTHONPATH with a value of python 2 libraries

<pkill9>interesting

<pkill9>does python hardcode it's own pythonpaths which include versions to search?

<efraim>sbcl failed to build on aarch64 on core-updates

<efraim>so no change from master

<efraim>should etc/guix-daemon.cil be added to .gitignore?

<Apteryx>why must we sometimes use ''(some list)?

<ng0>what'S that file?

<Apteryx>like in the build systems default arguments values

<Apteryx>b

<Apteryx>For example: (guix build-system gnu)

<pkill9>why do the python packages rely on the PYTHONPATH environment variable?

<Apteryx>search-paths defaults to '(), but configure-flags defaults to ''(). Which is right?

<Apteryx>pkill9: I think that's the mechanism used to find other Python libraries... Normally site.py would do that but in Guix it's not (currently) made to work that way.

<pkill9>why is it not made to work that way in Guix?

<Apteryx>because nobody got around to do it yet/been bothered by it enough?

<pkill9>oh so it's not a technical reason

<marusich>Also, it's probably difficult because Python's site.py uses idiosyncratic heuristics to find its "site" libraries.

<marusich>As I recall the last time I looked at how it works, Python checks a few places relative to the executable path to find the libraries, so it really doesn't play well with situations in which the libraries are not installed in the same actual directory structure as the executable.

<Apteryx>I forgot the detail, I once took a look at it.

<pkill9>maybe it could be patched to look for them in a different location?

<marusich>Probably.

<pkill9>i wonder why they don't just make it possible to specify where to look for them

<Apteryx>pkill9: If I recall it was a bit difficult to find something general enough that would do the job both at build time and in a profile.

<pkill9>by they i mean python upstream

<marusich>To figure out a solution you would ned to look closely at Python's C code (where the heuristics live, I think), and the site.py module (where more mechanisms live).

<Apteryx>marusich: There's not much heuristics, everything's laid out flat in that site.py file, in Python.

<Apteryx>(IIRC)

<marusich>Are you sure? Well, the last time I checked, Python went on a journey starting from its executable to find a special sentinel file (a module file, actually, which they always expected to be present), and walked the directory tree starting from the Python executable path.

<marusich>And I can't remember if they absolutized the path to the Python executable before beginning - which matters because if they do that, and if you invoke Python via a symlink tree that you have built with many libraries symlinked in from various distant parts of the file system, then Python won't find its libraries via the site mechanism.

<marusich>Anyway, I could be wrong, but somebody would need to review the code to make sure.

<marusich>I gotta run, but what's the problem, anyway?

<marusich>Apteryx, as for why we use double quotation in some places, it's probably because it's a situation where you have to pass a quoted list, which itself must contain a quoted list

<Apteryx>here's a patch I had started: http://paste.debian.net/1009673/. I'm not sure it works at all (don't recall), but it might gives pointers.

<pkill9>someone earlier wanted to install both pyhton2 and python3 to the profile, tbh i'd like to as well

<marusich>If there is code that expects to receive a quoted list, which passes the quoted list to another piece of code that expects another quoted list, then you have to use two quotes

<marusich>at least...something like that, I think

<Apteryx>marusich: OK, thanks!

<marusich>I recall being confused about that as well...

<pkill9>it can't be done though because they both will rely on PYTHONPATH var which specifies a path to the python libs including the version

<marusich>pkill9, I can understand that, but one cannot stuff everything into a single profile - there will be conflicts, either in environment variables or file paths. Why not use a second profile?

<pkill9>how would it be best to organise multiple profiles?

<marusich>It's pretty free-form. When I have created additional profiles, I've just plopped them into whatever directory is convenient. Just do "guix package -p .my-other-profile -i python3" or something in the directory where you want it.

<pkill9>ah ok

<marusich>But yeah, not being able to install both in a single profile is particularly jarring if you are used to having both installed side by side :(

<marusich>I'm sure there are ways to fix it, but nobody has done it. In the meantime, you can use a second profile.

<pkill9>yeah, i just thought having them installed side-by-side is something suported in almost every other distribution, yet the one distro that explicitely is about being able to install multiple versions of packages together can't xD

<marusich>Then when you want to use the second profile, either you can just invoke applications directly from it, or (if you need to run Python3 and use its libraries, e.g. in the repl or for development), you'll need to run something like 'eval "$(guix package --search-paths .my-other-profile)"'

<marusich>Well...you can! But you need to use two profiles right now.

<pkill9>true :p

<marusich>Gotta run. Have a nice day!

<pkill9>yeah it's not really a huge problem, just quality of life thing hehe

<pkill9>cya :)

<Apteryx>pkill9: look at the patch I pointed to if you want it badly enough ;) maybe we can figure out something.

<pkill9>i should look into using profiles more

<temp_trisquel>Hi.

<temp_trisquel>I have abandoned my laptop for a while.

<temp_trisquel>GuixSD 0.13.0 is installed and 0.14.0 is here.

<temp_trisquel>If I will update it, will /etc/config.scm be updated if something is added?

<temp_trisquel>Or it's better to reinstall?

<Apteryx>/etc/config.scm is generated, it's an input to guix system reconfigure /etc/config.scm.

<Apteryx>is *not* generated

<Apteryx>unless things changed and we now keep a generated copy as /etc/config.scm

<Apteryx>I just checked; it's not the case by default.

<temp_trisquel>Can I find default config.scm without using GuixSD image?

<temp_trisquel>Anyway, I must edit it for system-wide Tor.

<Apteryx>Just copy paste one of the templates used in the doc or found in guix sources.

<Apteryx>but if you installed GuixSD before you must still have the original config.scm, perhaps?

<temp_trisquel>I think something was added to it after 0.13.0 was released.

<temp_trisquel>I don't know about 0.14.0

<Apteryx>temp_trisquel: I'm using latest and not seeing that.

<ngz>Genuine question: a package requires PyInstaller to build. Is there any other way to install this (i.e., using the ".spec" file) since we do not provide PyInstaller?

<temp_trisquel>Build PyInstaller from source and install it?

<ngz>I tried. I got errors like this one "Linux-32bit/run: error: depends on 'libz.so.1', which cannot be found in RUNPATH ()" even though zlib is listed among the inputs.

<temp_trisquel>I think, the problem is with variables.

<temp_trisquel>Set LD_LIBRARY_PATH=path_to_zlib:path_to_other_library

<temp_trisquel>: is separator if you don't know

<ngz>OK. I'm trying that now. Thank you

<ngz>temp_trisquel: It didn't change anything

<temp_trisquel>I don't know what to do then?

<temp_trisquel>*then.

<Apteryx>how does a package outputs "out" get turned into the full path?

<Apteryx>(I mean the package name + version part)

<rekado>don’t use LD_LIBRARY_PATH

<Apteryx>ACTION answering themself: seems it just uses package-name + package-version

<rekado>ngz: it’s possible that the installer clears certain variables or removes them from the RUNPATH before linking.

<rekado>ngz: in that case you’d have to figure out how to override that behaviour

<ngz>AFAIU PyInstaller provides pre-compiled bootloaders. I need to regenerated them. Hopefully, that will get RUNPATH right.

<ngz>Re-generating the bootloaders didn't help either. Bummer.

<ngz>Hmmm something's cheesy. PyInstaller doesn't appear in Debian.

IRC channel logs

2018-02-10.log