IRC channel logs

<bavier>istm a global priority queue would in the daemon would be better than walking the dependency tree breadth-first

<civodul>bavier: the graft thing happens on the client side, not in libstore

<civodul>catern: i don't have a link handy, but that was in one of the first discussions about the potluck

<civodul>where Mark raised concerns about having external repos that would assume a stable "package API"

<bavier>civodul: sure, I was thinking more about prioritizing substitutes before local builds

<civodul>oh sorry i misunderstood

<civodul>ACTION -> zZz

<alca>Hi, I'm having a bit of trouble wraping my head around configuration in GuixSD.

<alca>At the moment I'm just trying to get wifi and an X server running.

<alca>On my other systems I just use wpa_supplicant and edit its config file, but that dosen't seem to be the way to go on Guix?

<buenouanq>alca: what do you have thus far, a successfully completed install?

<alca>Yes, I also added the dbus and wpa-supplicant services to my declaration, pulled and reconfigured.

<buenouanq>post your os config

<buenouanq> https://rectilinear.xyz/p/27d8e35bb5 here's mine for you to look at if that helps you

<buenouanq>I'm not exactly sure about wpa_supplicant, but I imagine that has examples in the install guide.

<buenouanq>The supported way to install a working X server, is via the %desktop-service.

<buenouanq>In mine you can see how you would add an additional config to be read with startx.

<alca>Thanks, I'm not sure how to get my config off this machine at the moment, but looking at an example with startx should help.

<buenouanq>all you need is to add %desktop-service to the (services declaration.

<buenouanq>this is not going to be like debian minimal or whatever you're trying to cling to

<buenouanq>there's no supported way to install just x and startx when you want after logging in

<buenouanq>it will install a graphic login manager

<alca>Ah alright, that's what I needed to hear. I was trying to forgo the login manager and just use startx.

<buenouanq>it's possible and people have done it I believe, you'll just have to really get your hands dirty and learn more about all this than you prolly want or are willing

<rekado>Hi Guix!

<rekado>With a recent kernel update on i686 I no longer have /dev/kvm

<rekado>It’s strange that ‘modprobe kvm’ does succeed, but there still is no /dev/kvm

<jsierles>good day guix

<jsierles>wanted to learn 'pre-inst-env' but i don't see it in a fresh checkout of guix.

<phant0mas>good day jsierles, you first have to run ./boostrap && ./configure && make

<jsierles>ah

<jsierles>so i do need at least autoconf and make?

<jsierles>trying to run this on alpine, so need to see what the prereqs are.

<rekado>I think you may do without make; it’s created by ‘configure’.

<jsierles>ok, bootstrap is looking for a specific version of gettext (0.18.1)

<jsierles>which isn't available anymore on alpine.

<jsierles> https://gist.github.com/jsierles/55fe0640f3c1e51b476b84f3cd85ea1a

<jsierles>actually, not sure what's going on there

<jsierles>ok, looks like gettext no longer has 'archive.tar.gz'

<jsierles>ok, fixed it. both 'gettext' and 'gettext-dev' are needed.

<jsierles>now got: configure.ac:75: error: possibly undefined macro: GUILE_MODULE_AVAILABLE

<jsierles>ok, guile also needs to be installed.

<jsierles>almost there. gnutls is not found, even though i installed it from alpine

<jsierles>any way to deal with "The Guile bindings of GnuTLS are missing; please install them"?

<jsierles>i have installed gnutls on alpine.

<phant0mas>jackhill: you need the guile-gnutls package from your distro

<phant0mas>oops wrong username

<phant0mas>and jsierles is offline

<reepca>Hm, how can one easily alter geiser's guile-running command so that it uses ./test-env?

<rekado_>reepca: I haven’t tried this but geiser-guile-binary may be a list

<civodul>Hello Guix!

<rain1>hello :)

<rekado_>reepca: though it may be simpler to create a shell wrapper and use its path as the value for geiser-guile-binary.

<reepca>rekado_: I ended up just going with the --listen approach

<rekado_>hmm, the last thing that keeps me from using texlive-union in python-numpy-documentation is some babel default.

<rekado_>sphinx generates a LaTeX source file that includes \\usepackage{babel}, but babel complains that it doesn’t know what language to use

<rekado_>it should use \\usepackage[english]{babel}

<civodul>hmm

<rekado_>the documentclass, however, does declare the language.

<rekado_>not sure why that’s a problem

<rekado_>annoyingly, the tex file is generated and processed in the same phase, so I can’t easily patch the generated file

<efraim>It turns out our copy of signing-party is so old it doesn't build on aarch64

<efraim>Newer version of Sphinx then?

<rekado_>efraim: I guess I could try a new version of Sphinx

<rekado_>I’m having trouble building the daemon on CentOS 7 inside ‘guix environment guix’

<rekado_>here’s the error I get:

<rekado_>nix/nix-daemon/nix-daemon.cc:890:44: error: cannot convert âin_addrâ to âin_addr_t {aka unsigned int}â in initialization

<rekado_>that’s with latest master and it’s the same with a version from July 4

<rekado_>tried make clean

<rekado_>but this keeps coming up

<reepca>the test environment doesn't by any chance have something against substitutes, does it? Or am I just re-going through the commencement phase?

<rekado>In trying to fix the problem I’m installing gcc-toolchain@5

<rekado>this is with a globally installed guix 0.12.0

<rekado>since there are no substitutes for 0.12.0 anymore this results in building a lot of things.

<rekado>while messages scroll past me on the screen, I’m thinking again about ‘guix pull’

<rekado>here are my naive thoughts:

<rekado>can we add a job on hydra to build the latest version of Guix and turn ‘guix pull’ into a stupid downloader?

<rekado>right now it computes derivations, builds dependencies to build Guix from source, and then builds it from source.

<rekado>this means that if you’re using an old version of Guix on which you run ‘guix pull’ you will need to build from source the old tools that you then use to build the latest Guix.

<rekado>Can we avoid this by not building Guix from source at all?

<rekado>I’m thinking of creating a pack on hydra and downloading that (minus the things one may already have in the store)

<rekado>tb

<rekado>oops

<civodul>rekado: i'm looking at the C+ error above, what g++ version are you using?

<rekado>the problem does not appear with GCC 5.3, but I got it with GCC 4.9

<rekado>i.e. with the default GCC from Guix 0.12.0

<civodul>ok

<civodul>that's super weird, is there a second line for this error message?

<rekado>it just scrolled out of view

<rekado>there’s another instance of this for the IP6 variant

<rekado>but that’s about it

<rekado>no other interesting lines.

<civodul>hmm

<civodul>rekado: i pushed a fix

<rekado>civodul: thank you!

<civodul>this is C++ weirdness, i wonder why it compiled in the first place :-)

<civodul>apparently there was some magical implicit cast and it just worked

<civodul>re guix pull, there's a chicken-and-egg problem

<civodul>basically, we need to compute the derivation of guix if we want to build it (and maybe get a substitute)

<civodul>but to compute the derivation of guix, we need guix, or a large subset thereof

<rekado>I don’t understand why we need to compute a derivation.

<rekado>that’s not necessary when we just want to download a file

<civodul>but that file would contain the output of a derivation no?

<rekado>right now we hardcode the URL to the master tarball

<rekado>could we not provide a URL where the latest version of the pre-built Guix can be fetched from?

<civodul>and that file would not be linked to a derivation?

<rain1>would the loop be broken by somehow splitting guix into parts?

<rekado>civodul: does it have to be linked to a derivation?

<civodul>rain1: yes and no

<rekado>‘guix pull’ is already a bit special

<civodul>rekado: it's akin to downloading a big binary blob from the internet out there

<rekado>yes

<civodul>derivations provide provenance tracking

<civodul>and so we always use derivations when building something

<civodul>of course we could make an exception, but that doesn't sound very good to me at first sight :-)

<rekado>could we download the derivation instead of computing it locally?

<rekado>ACTION is being sneeky

<civodul>in theory yes

<civodul>that'd be some sort of a "meta-substitute"

<civodul>interesting idea!

<reepca>sneek: botsnack

<sneek>:)

<rekado>sneek: that was for me!

<civodul>heheh :-)

<reepca>I hear "computing derivations" mentioned quite a bit, but I don't seem to recall a definition.

<civodul>for a substitute, you have a drv, and you ask the server whether it has the corresponding results

<civodul>for a meta-substitute, you have a commit, and you ask the server whether it has the corresponding drv

<civodul>reepca: by "computing a derivation" i'm referring to what the 'package-derivation' procedure does

<civodul>i.e., taking a high-level package definition, and "compiling" it down to a .drv

<reepca>ah, okay

<reepca>blargh... it's always so bittersweet finding a function that does exactly what you spent a fair bit of time writing a function to do.

<catonano>reepca: :-)

<catonano>reepca: which function was it ?

<reepca>two of them, one which turned out to be provided by guile. string-tokenize, hidden away under "miscellaneous string operations" in the manual, and mount-points from (guix build syscalls), which used string-tokenize. But hey, at least I made something useful - "octal-escaped", in case mount points have spaces in the name.

<reepca>also, out of curiosity, what's the difference between /proc/mounts and /proc/self/mountinfo?

<civodul>reepca: i think the latter takes namespaces into account

<civodul>while the former is the global list of mount points

<rekado>bleh, using the latest sphinx didn’t help.

<rekado>same error: ‘! Package babel Error: You haven’t specified a language option.’

<rekado>oh well

<reepca>Hm, I've tried using debug-set! to make the guile backtrace wider, but it seems truncated at the same point. Is that a geiser thing, and is there a way to control it?

<od1>wg #sxb.so

<od1>sorry

<rekado>gah, I really cannot read TeX code.

<rekado>I really like strace. I can understand what the TeX code tries to achieve by looking at the syscalls it triggers.

<adfeno>rekado: I also don't like writting in TeX/LaTeX. I like Org mode more :)

<adfeno>although Texinfo is fortunatelly more readable compared to TeX/LaTeX. :)

<rekado>I’m fine with LaTeX, but TeX code as used in compiled TeX packages such as babel.sty is simply unreadable.

<adfeno>rekado: Ugh... .... true...

<rekado>I know that it’s all macro expansion, but it takes me forever to figure out what I should even look for.

<rekado>It’s so alien.

<adfeno>What I miss in Org mode is how to make LaTeX + BibTeX work when exporting Org documents.

<adfeno>... also when considering BibTeX files that have accents or spaces in path names.

<yegortimoshenko>does anyone know if there is a darwin (macos) port of guix?

<jsierles>yegortimoshenko: there isn't yet

<jsierles>but, you can get pretty far with guix on OS X using Docker for Mac

<jsierles>not for OSX packages of course. but for using and testing guix for linux

<jsierles>right now i'm using guix in a docker-based development environment.

<jsierles>on Mac

<yegortimoshenko>interesting, thanks. i'm currently using nix but i prefer lisp

<jsierles>civodul: what would it take to make 'localstatedir' work with guix pack -f docker?

<davexunit>what does that mean?

<jsierles>currently if you run 'guix pack --localstatedir -f docker guix', you don't have a /var in the image

<jsierles>you only get a dead store.

<jsierles>my goal here is to create a guix docker image which is bootstrapped for a specific git checkout of guix, with a fully populated store, database and profile links for guix.

<davexunit>for what purpose?

<davexunit>the image is set in stone

<jsierles>we use docker to distribute stuff too

<jsierles>the idea is you have it bootstrapped, then run the image to copy the store and database to a docker volume

<jsierles>i haven't found any faster way to get a 'latest guix' on all my teams local machines

<jsierles>running 'guix pull' takes forever and recompiles stuff that's already been compiled on my substitute server.

<civodul>jsierles: we need to replicate what "guix pack -f tarball --localstatedir" does in the docker backend

<jsierles>civodul: OK. maybe something I could look at as a first task

<civodul>sure, would be great!

<civodul>i'd behappy to provide guidance

<jsierles>but this way works for now, putting a tarball into an image whose job is only to fill up an empty store mount

<civodul>ok

<jsierles>this should allow anyone to try the latest guix too, on any docker platform

<civodul>yup

<civodul>ACTION has to go

<civodul>ttyl!

<jsierles>laters

<quiliro>hello guixistoj

<quiliro>saluton guixantoj

<quiliro>mi lernas guix

<quiliro>guixon

<quiliro>kaj mi konstructas la pakagxon de openmolar1

<quiliro>anyone would please help me change my keyboard layout?

<quiliro>i cannot load dvorak-es

<quiliro>i stalled on the construction of qscintilla

<quiliro>which is needed for openmolar

<quiliro>would someone guide me please?

<davexunit>jsierles: ah, the use-case makes sense now. thanks for explaining.

<davexunit>it will be so nice when 'guix pull' just fetches a binary

<quiliro>would someone remind me of the distro based on guixsd which was being designed for a stable release?

<quiliro>pragmaos?

<davexunit>yeah something like that

<quiliro>how to some loadkeys es error: cannot open file es

<quiliro>?

<rekado_>quiliro: hey, where are you stuck?

<rekado_>quiliro: if I remember correctly you were almost done with qscintilla.

<rekado_>you only needed to override the installation target directory

<rekado_>quiliro: AFAIK there is no distro based on GuixSD. All I know of are ideas.

<rekado_>ACTION would really like to rewrite bournish

<quiliro>rekado_: hey! o/

<quiliro>currently running guix pull

<quiliro>it takes some time on my machine

<quiliro>after that, i will run guix environment guix

<rekado_>quiliro: why run ‘guix pull’ when you have the git checkout?

<rekado_>you don’t need ‘guix environment guix’ so often

<quiliro>ok

<rekado_>it’s fine to have one or two files not compiled

<rekado_>you’ll be changing them anyway

<quiliro>i will run git co

<quiliro>give me a minute

<quiliro>Your branch is up-to-date with 'origin/master'.

<rekado_>regarding qscintilla, I think you need to run ‘qmake’ with some arguments to set QT_INSTALL_PREFIX

<quiliro>now i dont need guix environment guix you say.....what should i do then?

<rekado_>you can just run ‘./pre-inst-env guix build …’

<rekado_>put if you have a lot of uncompiled modules I recommend actually doing ‘guix environment guix’ first to run ‘make’

<rekado_>I don’t always do this, but after a big ‘git pull’ with lots of changes it makes things faster.

<rekado_>here’s the qmake syntax to set variables: ‘qmake -set PROPERTY VALUE’

<rekado_>according to http://doc.qt.io/qt-5/qmake-environment-reference.html

<rekado_>I think it might be enough to do something like ‘qmake -set QT_INSTALL_PREFIX (assoc-ref outputs "out")’

<quiliro>did not run guix environment guix

<rekado_>note, this qmake stuff should be part of the qscintilla package definition; part of some build phase.

<quiliro>ran ./pre-inst-env guix build qscintilla

<quiliro>it is working now

<rekado_>this will fail eventually

<rekado_>because we still haven’t made any changes to the recipe

<quiliro>rekado_: in what part of the qscintilla package should i place 'qmake -set

<rekado_>I’m not sure how this works, but I think it’s safe to run this in the same phase where we run ‘qmake’ on its own.

<rekado_>we can just run it before and chain the commands with ‘and’

<rekado_>try ‘(and 23 12)’ in the REPL (e.g. with Geiser)

<rekado_>or ‘(and 'foo 'bar 12 + -)’

<rekado_>and then try ‘(and 12 #f 34 1 3)’

<rekado_>quiliro: what does ‘and’ do?

<quiliro>i dont understand the results

<quiliro>scheme@(guile-user)> (and 23 12)

<quiliro>$1 = 12

<quiliro>scheme@(guile-user)> (and 'foo 'bar 12 + -)

<quiliro>scheme@(guile-user)> (and 12 #f 34 1 3)

<quiliro>$3 = #f

<rekado_>in the first case you get 12, in the second case you get a procedure called ‘-’, in the third case you get #f, which stands for ‘false’.

<rekado_>in Scheme every value that is not #f is considered ‘true’.

<rekado_>‘and’ keeps going until it hits #f.

<rekado_>it returns the last value.

<rekado_>we can use it to chain procedures that return either true or false.

<rekado_>such as ‘zero?’, which will return either #t or #f.

<quiliro>ok

<quiliro>but why will it show only the last and not the chain?

<rekado_>that’s just how it works. It’s supposed to evaluate all arguments until it hits #f.

<rekado_>an evaluation can have a side effect.

<rekado_>do you remember how we can run external commands with Scheme?

<quiliro>rekado_: let me check

<quiliro><rekado> quiliro: while you are in a Scheme buffer hit C-c C-z to switch to geiser [15:17]

<quiliro><rekado> then type ,use (guix build gnu-build-system)

<quiliro><rekado> then %standard-phases

<quiliro><rekado> this will show you the value of that variable

<rekado_>no, that only gets you to geiser and then shows you what value %standard-phases has

<rekado_>look in the recipe for qscintilla

<rekado_>you’re already calling an external command in one of the build phases

<quiliro>chdir?

<rekado_>‘chdir’ cannot call an arbitrary command. All it does is change the current directory.

<quiliro>yes...it modifies standard-phases

<rekado_>what I meant is ‘system*’

<rekado_>try this in a REPL: (system* "ls")

<rekado_>we’re using this in qscintilla to run ‘qmake’

<rekado_>system* takes one or more arguments. The first argument is a command. All other arguments are arguments to that command.

<rekado_>try (system* "ls" "-l")

<quiliro>it lists the files

<rekado_>okay, what about (system* "touch" "/tmp/a")

<rekado_>that’s a command that … does something but we cannot really see if it was successful by looking at the output

<rekado_>because it doesn’t print any output.

<quiliro>ok...i understand

<quiliro>system* pases commands

<quiliro>in one or more arguments

<rekado_>note the return value of system*

<rekado_>what return value do you get for the last expression?

<quiliro>$7 = 0

<rekado_>good

<quiliro>(system* "ls" "/tmp")

<rekado_>what about (system* "touch" "/whatever")

<quiliro>$9 = 0

<quiliro>from (system* "touch" "/tmp/whatever")

<rekado_>try (system* "touch" "/whatever")

<quiliro>permission denied

<quiliro>$10 = 256

<rekado_>yes!

<quiliro>ok 0= no error

<rekado_>correct

<rekado_>so we can check with ‘zero?’

<rekado_>(zero? $10)

<quiliro>false

<quiliro>ACTION is learning a lot!

<rekado_>(these $ values are intermediate variables that the REPL creates, so that we can more easily refer to previous results)

<quiliro>it is very clear

<quiliro>$number is like a variable

<quiliro>we can check its value

<rekado_>okay, so we can use ‘(zero? (system* "something"))’ to check if the command ‘something’ had an error.

<lfam>ACTION prepares master -> core-updates merge. Please no commits to core-updates in the next few minutes!

<rekado_>if it had no error, it will return #t. If it had an error it will return #f.

<rekado_>let’s now chain commands with ‘and’

<quiliro>ok

<rekado_>‘and’ evaluates things until it hits ‘#f’.

<quiliro>i get it

<quiliro>zero checks if it is zero or in other words correct

<rekado_>so (and (zero? (system* "ls")) (zero? (system* "touch" "/bad"))) will return … what?

<quiliro>let me think before testing it

<rekado_>ok

<rekado_>when doing this in your head: evaluate from the left to right, from the inside to the outside

<quiliro>false

<quiliro>let me test

<quiliro>why did it ls?

<quiliro>only the last output you said with and

<rekado_>it first evaluates (system* "ls")

<rekado_>this returns 0

<quiliro>let me experiment

<quiliro>yes

<rekado_>so ‘zero?’ returns #t

<rekado_>let’s rewrite this:

<quiliro>it does but it is not hte last one

<rekado_>(and (zero? (system* "ls")) (zero? (system* "touch" "/bad")))

<rekado_>(and (zero? 0) (zero? (system* "touch" "/bad")))

<rekado_>(and #t (zero? (system* "touch" "/bad")))

<rekado_>‘and’ evaluates all its arguments until it hits #f.

<quiliro>you want me to think or to test?

<rekado_>so far there’s no #f

<rekado_>we got a #t

<quiliro>ok

<rekado_>let’s evaluate this further

<rekado_>(and #t (zero? 256))

<rekado_>(and #t #f)

<rekado_>=> #f

<quiliro>yes

<rekado_>had there been any further argument it would have been ignored

<rekado_>because it hit #f

<rekado_>you can confirm this by doing this:

<rekado_>(and (zero? (system* "ls")) (zero? (system* "touch" "/bad")) (zero? (system* "ls")))

<quiliro>oh...so all values are displayed until #f only

<adfeno>(and ...) keeps going until everything is done, or until it hits #f.

<rekado_>the first and the last should both be fine, but the last command is never executed.

<rekado_>‘display’ is not correct. They are *evaluated*.

<quiliro>ok

<rekado_>it just so happens that the evaluation of ‘(system* "ls")’ prints some text.

<rekado_>anyway, that’s enough to change the recipe

<rekado_>we want to first run ‘qmake -set QT_INSTALL_PREFIX /gnu/store/…’, and then ‘qmake’.

<quiliro>yes

<rekado_>since we don’t know the name of the directory under /gnu/store we can simply ask Guix to tell us the name.

<quiliro>because we already removed /usr

<quiliro>ok

<rekado_>we use ‘(assoc-ref outputs "out")’ to get a string of the target directory in the store.

<quiliro>ok

<rekado_>so the command is (system* "qmake" "-set" "QT_INSTALL_PREFIX" (assoc-ref outputs "out"))

<quiliro>how do i feed that result to our command?

<quiliro>ok

<rekado_>that’s okay because ‘system*’ takes just a bunch of strings, and (assoc-ref outputs "out") returns a string.

<adfeno>quiliro: Important note: rekado_'s (system* "ls") example is, of course a simple usage of (system* ...), however, Guile Scheme itself has procedures (like "commands" in GNU Bash, or "functions" in any language) to do the same as "ls".

<rekado>quiliro: when you’re done modifying the recipe for qscintilla please share it with me.

<quiliro>rekado: i did it...i was going to./pre-inst....

<quiliro>i will paste it now

<rekado>I think it’s going to fail, because ‘outputs’ is undefined

<quiliro> http://sprunge.us/XgRW

<quiliro> git diff gnu/packages/qt.scm | curl -F 'sprunge=<-' http://sprunge.us

<rekado>okay

<rekado>there are a couple of problems here

<rekado>we want to run two commands

<rekado>first is ‘qmake -set …’

<rekado>the second is ‘qmake’

<rekado>we want to chain them and only run the second if the first succeeded.

<rekado>the second problem is ‘lambda _’

<rekado>the ‘_’ means: “whatever, I don’t care”

<rekado>some background: the build procedures are all called with a bunch of keyword arguments.

<rekado>previously, we didn’t care.

<rekado>but one of these arguments is a value for “outputs”

<rekado>so we should let our lambda *bind* that value.

<rekado>change “lambda _” to “lambda* (#:key outputs #:allow-other-keys)”

<quiliro>done...what does this co?

<quiliro> http://sprunge.us/fgJf

<quiliro>s/co/do/

<rekado>this declares that we have a procedure that takes keyword arguments, ignores most of them, and binds the value for the keyword argument “outputs” to the variable “outputs”.

<rekado>you still need to remove “_”

<rekado>and you need to use “and” to chain the two qmake commands. (You only have one.)

<quiliro>i did

<quiliro>oh..i did remove _

<quiliro>but did not use and yet

<quiliro>'and'

<lfam>ACTION pushes the core-updates merge

<quiliro> http://sprunge.us/Yjdf

<quiliro>done

<rekado>heh, the “and” is in the wrong place :)

<quiliro>this looks like the tests at elementary school

<quiliro>oh

<rekado>look at the previous example again

<jsierles>`guix pack nss-certs` generates this unusual error: i/o error: /gnu/store/v3badl9wh3zv569zzm3za7gr51dnwgan-profile/etc/ssl/certs/T??B??TAK_UEKAE_K??k_Sertifika_Hizmet_Sa??lay??c??s??_-_S??r??m_3:2.1.17.pem: No such file or directory

<rekado>jsierles: this looks like a locale problem.

<jsierles>the resulting tar exists but without these files.

<quiliro>let me reread your instructions...you said:

<jsierles>rekado: does guix need a special locale setting? running 'tar cf' on the directory directory works fine

<rekado>I don’t know. This looks like a bug to me.

<rekado>let me try to reproduce it

<jsierles>alright. will file it

<lfam>rekado, jsierles: I believe we discussed this previously on one of the mailing lists

<jsierles>oh? i'll take a look

<lfam>I recommend searching the archives for 'nss-certs' in the last ~6 months

<lfam>Too bad one can't search all the lists at once, but oh well

<adfeno>quiliro: Example: (and (zero? (system* "ls"))

<quiliro><rekado_> we want to first run ‘qmake -set QT_INSTALL_PREFIX /gnu/store/…’,

<quiliro>so and should go before both qmake

<quiliro>s

<adfeno>quiliro: (zero? (system* "pwd")))

<rekado>jsierles: I can reproduce this.

<adfeno>quiliro: Notice what rekado said: "before *both* qmake".

<rekado>jsierles: I remember seeing a bug relating to encoding in Guile some time ago.

<jsierles>i found it. looks http://lists.gnu.org/archive/html/bug-guix/2017-05/msg00282.html

<rekado>jsierles: this could be it.

<jsierles>guess the daemon needs to run in utf8 locale

<quiliro>(arguments `(#:phases (modify-phases %standard-phases (replace 'configure (lambda* (#:key outputs #:allow-other-keys)_ (chdir "Qt4Qt5") (zero? (system* (and ("qmake" "-set" "QT_INSTALL_PREFIX" (assoc-ref outputs "out"))) "qmake")))))))

<quiliro>and is before both qmake

<quiliro>(system* (and ("qmake" "-set" "QT_INSTALL_PREFIX" (assoc-ref outputs "out"))) "qmake")

<rekado>("qmake" "-set" "QT_INSTALL_PREFIX" (assoc-ref outputs "out")) <– that’s not a command

<rekado>remember that the first thing must always be a procedure or special syntax.

<rekado>what we need is something like this: (and (zero? (system* …)) (zero? (system* …)))

<rekado>that whole expression will either return #t or #f

<quiliro>ok

<quiliro>so i need to check if the first qmake is true

<adfeno>Also, there is a underline near (lambda * ()_

<quiliro>then eval the second

<adfeno>That underline must not exist :)

<rekado>correct

<quiliro>let me check

<quiliro>oh...the _ went right before chdir

<quiliro>did not see it

<adfeno>:)

<adfeno>quiliro: To put the examples given by me and rekado in a friendly view: http://ix.io/yq9

<quiliro> http://sprunge.us/dRcG

<rekado>quiliro: excellent!

<rekado>now, let’s see if this fixes our problem

<rekado>run ./pre-inst-env guix build qscintilla

<quiliro>running

<quiliro>it is g++ ing

<adfeno>:)

<quiliro>compiling c++ code with g++ ?

<adfeno>GNU C++ compiler :)

<quiliro>ok...i i was right then!

<quiliro>almost...

<quiliro>is that what stallman wrote initially?

<quiliro>or was it gcc?

<quiliro>or are they both the same

<rekado>GCC is a compiler collection.

<quiliro>?

<quiliro>ok

<rekado>it includes the C++ compiler.

<quiliro>cool!

<quiliro>but i guess he did not write the c++ part

<quiliro>it has not broken yet

<quiliro>the other time it broke in this time

<quiliro>oh..it broke

<lfam>Hm, the latest man-db fails its tests: http://paste.lisp.org/+7IGE

<quiliro>make: [Makefile:3905: install_header] Error 3 (ignored)

<quiliro>mkdir: cannot create directory ‘/gnu/store/6wmrf9c7rpv2c8q02vxvv1frsmljr5lh-qtbase-5.9.1/translations’: Permission denied

<rekado>argh

<quiliro>ln: failed to create symbolic link '/gnu/store/6wmrf9c7rpv2c8q02vxvv1frsmljr5lh-qtbase-5.9.1/lib/libqscintilla2_qt5.so.13': Permission denied

<rekado>ACTION checks http://doc.qt.io/qt-5/qmake-environment-reference.html

<quiliro>that is good to know

<quiliro>it helps replicate rekado!

<quiliro>if that is not #f

<rekado>looks like setting QT_INSTALL_PREFIX didn’t help

<rekado>we may need to set all of the variables that qscintilla.pro uses

<adfeno>quiliro: Dont worry, everything is going well in the context of learning. Right now, rekado is checking the link he just gave, it seems that qmake is a little more tricky than what we thought. But in the learning side, we are doing fine :)

<quiliro>(and (zero? (compile qcintilla quiliro) (zero? (compile qcintilla rekado)))

<rekado>QT_INSTALL_LIBS, QT_INSTALL_HEADERS, QT_INSTALL_TRANSLATIONS, QT_INSTALL_DATA, QT_INSTALL_DATA

<adfeno>Hm... I wonder if qscintilla itself has a text file inside that sets everything...

<rekado>quiliro: heh, now you speak like a Scheme programme :)

<rekado>adfeno: no, these seem to be the default values that qtbase provides

<quiliro>(and (zero? (compile qcintilla quiliro) ((zero? (adfeno guide quiliro)) | (zero? (rekado guide quiliro))) (zero? (compile qcintilla quiliro) (zero? (compile qcintilla

<quiliro><rekado> QT_INSTALL_LIBS, QT_INSTALL_HEADERS, QT_INSTALL_TRANSLATIONS,

<quiliro>i guess that is not the correct algorithm

<quiliro>sorry absout the extra paste

<adfeno>quiliro: I think that what rekado means is that we must repeat the (zero? (system* "qmake -set ...")) for every item he just told us about...

<adfeno>Let's see....

<rekado>I’m trying this right now

<rekado>maybe it’s easier than that

<quiliro>adfeno: isnt it supposed to be modified in qt itself?

<rekado>I’m not familiar with qmake, but I looked around in qt.scm

<quiliro>python-pyqt

<rekado>no

<rekado>python-pyqt is completely independent

<adfeno>Oh... so rekado is also searching for an easier way... :)

<quiliro>in define-public qt?

<rekado>here’s how we can speed this up

<rekado>we end the extra build phase that runs qmake with “#f” and then use “./pre-inst-env guix build -K qscintilla”

<rekado>then we take a look at the generated Makefile

<quiliro>ok...how do we end the extra build hase?

<quiliro>phase

<quiliro>you mean we suppress it?

<rekado>right now it ends with whatever zero? returns

<rekado>since we’re using (and …) we can just put an extra #f there

<quiliro>oh...break it

<quiliro>stop

<rekado>yes

<quiliro>ok

<quiliro>after (zero? (system* "qmake") we insert #f

<quiliro>?

<adfeno>Hm... and we try to (substitute* "Makefile" (...)) the problematic paths ... :)

<adfeno>quiliro: About your last question: after the last (zero? ...).

<quiliro>adfeno: ok

<rekado>adfeno: we could do that, but I think it’s prettier to generate the correct Makefile

<quiliro>i guess my synthax was not correct...but i meant the same as you said.... rekado: ok

<quiliro>adfeno: ok

<quiliro>never mind

<quiliro>rekado: how to generate the Makefile

<quiliro>?

<quiliro>what does that?

<quiliro>i imagine that ./configure

<quiliro>but how to change it?

<rekado>we must figure out how to tell qmake to generate a Makefile with the correct target directory

<rekado>I tried “qmake -set” on all variables, but it doesn’t have any effect.

<rekado>I’m trying “qmake PREFIX=/…”

<rekado>but none of these seem to work

<rekado>:(

<catonano>rekado: you suggested me a workaround for a qmake based package, some time ago

<rekado>actually, qtsvg contains a phase that just patches up the generated Makefile

<rekado>not very satisfying.

<quiliro>is there something i can do in the meantime?

<quiliro>i feel useless

<rekado>heh :)

<rekado>you could check the sources of Qscintilla to confirm the license.

<quiliro>ok

<rekado>is it really GPLv3 or does it contain the “or later” clause?

<quiliro>i should check every file?

<quiliro>ok...ill do that first

<rekado>you don’t have to do it manually. There are tools to find strings in files ;)

<quiliro>which ones?

<adfeno>grep

<adfeno>grep -ir 'lic'

<adfeno>Or, there might be a "LICENSE" file in the directory where qscintilla is.

<rekado>or COPYING

<adfeno>Err... sorry, the LICENSE file is only the entire license, not what copyright holder writes in the license notice....

<quiliro>there is the license file...it is the GNU GPLv3

<adfeno>I think the license notice is in a README file, or in a "main" file, or in a file with the same name of the project.

<quiliro>it is not the readme

<quiliro>it is just a reference

<quiliro>README.doc

<quiliro>inside doc/

<adfeno>Hm....

<rekado>quiliro: this version seems to build and install successfully: http://sprunge.us/caRF

<quiliro>rekado: how can i use that link without retypyng everything?

<adfeno>rekado: I was just reading the README.doc and noticed that you substitute things in the "qscintilla.pro" file....

<quiliro>yes! i read that too

<adfeno>rekado: ... I wonder if we don't need to update the "features/qscintilla.prf" file too

<quiliro>that means i dont make changes to qt.scm?

<rekado>quiliro: you can visit the URL with eww and then apply the contents of the buffer as a patch

<adfeno>rekado: Won't he loose the "openmolar" custom package?

<quiliro>i should download the link as a file?

<quiliro>openmolar is in medical.scm

<adfeno>Oopps... Openmolar is in another file. :)

<adfeno>quiliro: Yes, that link rekado just gave can be downloaded as a simple text file.

<adfeno>It'll be used by us as a patch.

<rekado>I suppose you could just do this: patch -p1 < <(wget -qO - http://sprunge.us/caRF)

<rekado>this fetches the paste, prints it to standard output, creates a temporary file handle and then applies the patch.

<rekado>make sure that you have no changes to qt.scm or else the patch won’t apply

<rekado>you can do “git checkout -- gnu/packages/qt.scm” to erase all of your changes.

<rekado>i.e. all the changes to qt.scm; none of your other changes will be touched.

<adfeno>quiliro: ^ this is why the "-- gnu/packages/qt.scm" part is important, we don't want to lose openmolar :)

<quiliro> http://sprunge.us/bSTe

<quiliro>wrong...

<quiliro>sorry

<quiliro>wait please...dont open

<jsierles>anyone got clojure working with guix?

<quiliro>i copied manually

<quiliro> http://sprunge.us/SdLH

<quiliro>please check

<quiliro>wrong paste

<quiliro>this is it http://sprunge.us/AHGB

<quiliro>building now

<quiliro>lets see if it works

<quiliro>it it very difficult to use this english keyboard

<quiliro>i use dvorak-es

<rekado>I use dvorak

<quiliro>so i cannot type without looking at the keys on en

<quiliro>rekado: cool

<quiliro>but loadkeys does not work on guixsd

<rekado>In my system configuration I have this service: (console-keymap-service "dvorak")

<rekado>quiliro: are you using a virtual console only? Or also a graphical user interface?

<quiliro>graphical

<quiliro>i3

<quiliro>i dont know how to use anything on the console

<quiliro>but i can learn

<quiliro>if it is useful

<rekado>FWIW “sudo loadkeys dvorak-es” works for me

<rekado>(but I don’t know how it differs from the English dvorak)

<rekado>I use stumpwm.

<rekado>I rarely use the virtual console

<rekado>to me it’s only useful when things break

<quiliro>used (console-keymap-service "dvorak-es") on the (operating-system) section

<quiliro>then i have 'guix system reconfigure config.scm'?

<quiliro>building openmolar now

<rekado>the console-keymap-service only affects the virtual console, though :-/

<rekado>for the graphical user interface I have an additional setting

<quiliro>that is ok...if it boots with dvorak-es, everything else will too.

<quiliro>i have noticed

<quiliro>is that not so?

<rekado>I have this file: http://paste.lisp.org/display/350517 as /etc/config.d/evdev.conf

<efraim>whats the difference between cl-stumpwm, ecl- and sbcl-?

<quiliro>at least on i3

<rekado>and in my configuration file this: http://paste.lisp.org/display/350517#1

<rekado>efraim: they use different Lisp runtimes.

<jsierles>so on my server, I used 'guix pull' and then 'guix pack guix'. but the packed image doesn't contain the 'guix-latest' derivation

<jsierles>what would i need to do on the target system where the pack was unloaded to use latest guix?

<quiliro>i guess openmolar built correctly

<quiliro>with './pre-inst-env guix build openmolar'

<quiliro>no error

<quiliro>what should i do now?

<jsierles>i assumed running 'guix pack guix' would give me the latest incarnation of guix

<lfam>rekado: Any progress on those new old servers?

<civodul>jsierles: "guix pack PKG" creates a pack for PKG; the 'guix' package is different from what 'guix pull' provides

<civodul>see (gnu packages package-management)

<jsierles>civodul: oh. so is there no way then to do what I'm trying to do?

<civodul>quiliro: nice!

<jsierles>using guix pack or otherwise.

<civodul>quiliro: i guess you can check https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html

<quiliro>what should i do to test it?

<civodul>you can install it and run it (i don't know this piece of software)

<civodul>jsierles: you'd have to pass 'guix pack' a fresh snapshot of the Guix code, with "guix pack guix --with-source=./guix-0.1.2.3.tar.gz"

<civodul>see https://www.gnu.org/software/guix/manual/html_node/Package-Transformation-Options.html

<jsierles>civodul: ok. so guix would still have to build on the target system?

<civodul>yes

<jsierles>ah, bummer. so conclusion is that guix always needs to build, no way to port a 'guix latest' around yet

<rekado>lfam: paperwork!

<rekado>lfam: the servers just sit here waiting for approval.

<rekado>I was out last week and there hasn’t been any progress :(

<adfeno>rekado: quiliro: About the license used by qscintilla: README.doc says its under GNU GPL 3 (only).

<lfam>rekado: Lovely :)

<civodul>rekado: if lfam and i can sign something on change.org, let us know ;-)

<rekado>I had to prepare a project proposal with risk estimates etc to move this forward.

<rekado>I hope we can get something done this week.

<jsierles>civodul: so what about getting all the dependencies into a pack at least?

<rekado>civodul: hah :)

<civodul>rekado: woow, thanks for doing that

<quiliro>i did './pre-inst-env guix build openmolar'

<civodul>jsierles: "guix pack guix" will provide all the dependencies (+ guix as a bonus :-))

<quiliro>and had no errors

<rekado>quiliro: did you add qscintilla to the inputs?

<jsierles>civodul: ok, i thought so, but i see gcc, perl, etc being build locally after having unpacked

<quiliro>rekado: it was added....but let me check

<lfam>civodul: Can you reply to Niall on help-guix to give some clarification about the new profile collision detector? I don't understand it well enough to explain it

<civodul>jsierles: is /var/guix/db/db.sqlite properly initialized?

<civodul>as with --localstatedir

<civodul>lfam: will do

<jsierles>civodul: i just untarred and ran wit that. what needs to be done?

<civodul>ACTION has to reboot due to a broken reconfigure with experimentalish code

<civodul>brb

<quiliro>rekado: http://sprunge.us/SgOG

<jsierles>the pack was built with localstatedir.

<adfeno>quiliro: That's empty.

<quiliro> git diff gnu/packages/medical.scm | curl -F 'sprunge=<-' http://sprunge.us

<quiliro>is that correct?

<rekado>try “git diff gnu/packages/medical.scm” first

<rekado>you’ll probably see no output

<rekado>that’s because we don’t have medical.scm in git.

<rekado>just use “cat” instead of “git diff”

<quiliro> there is medical.scm http://sprunge.us/UEJa

<rekado>but there’s no qscintilla among the inputs

<quiliro>no...but openmolar build worked

<quiliro>weird

<rekado>it worked before.

<rekado>you only had problems when running it.

<quiliro>perhaps because it was already installed?

<quiliro>oh...right

<quiliro>i will add it to medical then

<rekado>add it to the inputs of “openmolar”

<rekado>don’t move the definition there :)

<civodul>rekado: i'm willing to push the service "customization" patch

<civodul>rekado: it's not ideal, but i don't have a better idea, and it solves a real problem

<civodul>WDYT?

<quiliro>openmolar with qscintilla inputs http://sprunge.us/HUiJ

<adfeno>quiliro: That should do it :)

<quiliro>i dont remember how to run it

<rekado>civodul: which patch is this?

<quiliro>./pre-inst-env guix environment --ad-hoc openmolar -- openmolar

<quiliro>is that it?

<rekado>ACTION hasn’t yet regained an overview after vacation

<rekado>quiliro: yes, that would work.

<civodul>rekado: https://bugs.gnu.org/27155

<rekado>you can also just do $(guix build openmolar)/bin/openmolar

<civodul>ACTION feels ashamed that alezost has been waiting for a solution for so long

<quiliro>ImportError: cannot import name 'Qsci'

<rekado>civodul: my biggest concern with this is probably that there is no ordering

<rekado>quiliro: too bad.

<rekado>quiliro: that’s a Python error, though

<rekado>maybe we’re missing python bindings to Qscintilla?

<rekado>no, wait

<rekado>we have bindings in python-pyqt

<rekado>and that should just load qscintilla

<rekado>could you try this:

<rekado>export LD_LIBRARY_PATH=$(guix build qscintilla)/lib; $(guix build openmolar)/bin/openmolar

<quiliro> $(guix build openmolar)/bin/openmolar

<quiliro>will not work

<quiliro>bash: /bin/openmolar: No existe el fichero o el directorio

<quiliro>i will try what you say

<quiliro>guix build: error: qscintilla: unknown package

<quiliro>guix build: error: openmolar: unknown package

<quiliro>bash: /bin/openmolar: No existe el fichero o el directorio

<quiliro>FileNotFoundError: [Errno 2] No existe el fichero o el directorio: '/usr/share/openmolar/resources/appointment_shortcuts.xml'

<quiliro>with ./pre-inst-env guix environment --ad-hoc openmolar -- openmolar

<quiliro>./pre-inst-env guix environment --ad-hoc openmolar -- openmolar 2>&1 | curl -F 'sprunge=<-' http://sprunge.us

<quiliro> http://sprunge.us/jCWQ

<quiliro>rekado: the output was http://sprunge.us/jCWQ

<quiliro>rekado: from './pre-inst-env guix environment --ad-hoc openmolar -- openmolar 2>&1 | curl -F 'sprunge=<-' http://sprunge.us'

<rekado>quiliro: oh, sorry. Use “./pre-inst-env guix”, not just “guix”

<quiliro>??

<quiliro>oh

<rekado>export LD_LIBRARY_PATH=$(./pre-inst-env guix build qscintilla)/lib; $(./pre-inst-env guix build openmolar)/bin/openmolar

<jsierles>civodul: so how should the db be initialized?

<quiliro>rekado: same error as last paste

<quiliro>FileNotFoundError: [Errno 2] No existe el fichero o el directorio: '/usr/share/openmolar/resources/appointment_shortcuts.xml'

<jsierles>i used 'guix pack --localstatedir guix'

<quiliro>ImportError: cannot import name 'Qsci'

<jsierles>just assumed I can untar the db in place.

<rekado>quiliro: the first error indicates that we need to patch the openmolar sources a little, but that’s okay..

<rekado>quiliro: the second error is what makes me worry a little

<quiliro>export LD_LIBRARY_PATH=$(./pre-inst-env guix build qscintilla)/lib; $(./pre-inst-env guix build openmolar)/bin/openmolar 2>&1 | curl -F 'sprunge=<-' http://sprunge.us

<rekado>quiliro: we need to investigate why it cannot import Qsci

<rekado>I’ll try with plain python

<quiliro>ok

<quiliro>in a couple of second i will put the link to the paste

<quiliro> http://sprunge.us/LcYH

<rekado>./pre-inst-env guix environment --ad-hoc python-wrapper python-pyqt qscintilla

<civodul>jsierles: if --localstatedir was passed to 'guix pack', then that file should be non-empty

<jsierles>civodul: yes, the db looks OK

<civodul>ok

<civodul>jsierles: if you don't want to rebuild everything, you also need to authorize the key for substitutes

<jsierles>so now i would expect 'guix pull' with the git hash to be fairly quick, right?

<quiliro>rekado: no error

<jsierles>civodul: yep , i have authorized my sub server

<civodul>jsierles: not necessarily quick, it depends on a few things

<quiliro>rekado: no error with the last command you asked me to run

<jsierles>hmm, i think maybe my store and db were out of sync.

<jsierles>civodul: now i wiped the store and untarred freshly, it seems to only be downloading now

<jsierles>civodul: what i'm curious about is why all the things it's downloading are not included in the pack.

<jsierles>i guess because the latest release has a lot of new dependencies? i see it downloading libX11 for example.

<jsierles>huh, now it's downloading a ton of source files. *confused*

<rekado>quiliro: looks like we’re not done with qscintilla yet.

<rekado>quiliro: see http://pyqt.sourceforge.net/Docs/QScintilla2/

<rekado>quiliro: we actually need to build the Python bindings

<rekado>quiliro: see the heading of the same name.

<jsierles>civodul: so it is building everything in the end.

<rekado>quiliro: we can either create a new package “python-qscintilla” that inherits from “qscintilla”, or we can build the Python bindings in another build phase.

<rekado>quiliro: but I’m out of time now.

<rekado>ACTION –> zzZZ

<quiliro>If you do make changes, specifically to the names of the installation directories or the name of the library, then you may also need to update the Qt4Qt5/features/qscintilla2.prf file.

<quiliro>ok....thank you very much rekado

<quiliro>perhaps someone else will guide me now

<quiliro>or i can return another day if someone else is not available for helping now

<quiliro>perhas tomorrow

<jsierles>maybe my issue is my substitute server is not working correctly.

<civodul>jsierles: 'guix pull' uses dependencies "of its time", if you see what i mean

<jsierles>"gzip: stdin: invalid compressed data--crc error" that looks bad

<civodul>ouch

<civodul>URL?

<jsierles>guix substitute: error: corrupt input while restoring '/gnu/store/wak3m4kdkgw010qn1ksnqlggvklp4b24-gmp-6.1.2/lib/libgmp.a' from #{read pipe}#

<jsierles>this was using hydra's mirror

<quiliro>i will return tommorrow or the day after tomorrow

<jsierles>civodul: i understand the deps would be different. but since i have that version of guix on my build server, i assume my sub server will deliver those packages

<quiliro>will someone send me homework please?

<jsierles>ugh, on my build server i'm now seeing 'profile contains conflicting entries for gmp:ou'

<jsierles>does this mean my store is corrupted?

<quiliro>rekado, civodul, adfeno: what should i study?

<civodul>jsierles: no, it means the profile contains two entries for "gpm"

<civodul>*"gmp"

<jsierles>civodul: how does a profile get two entries like that?

<jsierles>i see, maybe by having run 'guix package -i guix'

<quiliro>i will check the sources and see what i can do

<jsierles>civodul: do you think the crc error is an issue on my end, or with hydra?

<jsierles>fwiw, i have gmp-6.1.2 built on my server

<quiliro>thank you all for the help...i am proud of my progress

<quiliro>bye

<civodul>jsierles: on hydra; can you report the faulty URL?

IRC channel logs

2017-07-10.log