IRC channel logs

<lfam>It's my personal clone of the Guix git repository.

<lfam>fps: That's exactly what I did

<fps>the guix package definition is evaluated in guile, the builder is assembled and the daemon starts the build

<lfam>Okay, sounds good

<lfam>It would be :( if the build process kept grabbing stuff from the filesystem throughout the build

<fps>the daemon then grabs the package source code from somewhere [not in your guix git clone though] extracts it and continues with its work

<fps>this is separate from the guix git clone afaict

<fps>now why i was asking about the distinction was:

<fps>if i just git cloned github.com/some/package.git and started a build and then switched to another branch

<fps>that would be possibly desastrou

<fps>s

<lfam>The package source code comes from upstream, unless you have it cached

<fps>yeah, when you use guix to build it

<fps>i wasn't sure if that was what you did, and just tried to elaborate on why i asked whether that was the case :)

<lfam>Now, how can I lint a dependency graph?

<fps>no idea :)

<lfam>I get the feeling this would be super easy if I lived in emacs / scheme

<fps>just generally speaking you could load the package in a guile repl dump out all package names in its dependency graph and lint the list

<lfam>Heh, that's exactly what I was thinking. But I don't know how :(

<fps>maybe even (map (lambda (name) (system* "guix" "lint" name)) packages)

<fps>where packages is the list of package names ;)

<fps>but since it's a graph, i have a feeling fold would come in somewhere ;)

<fps>scheme@(guile-user)> (use-modules (gnu))

<fps>scheme@(guile-user)> (specification->package "xmonad")

<fps>how to get to its dependencies now?

<fps>i think that package is a srfi-9 record type?

<lfam>Heh, sorry I can't help :p

<fps>got it already :)

<fps>(use modules (gnu))

<fps>oops

<fps>(use-modules (guix packages))

<fps>(package-inputs (specification->package "xmonad"))

<fps>$3 = (("ghc-mtl" #<package ghc-mtl-2.2.1 gnu/packages/haskell.scm:1306 3a0f9c0>) ("ghc-utf8-string" #<package ghc-utf8-string-1.0.1.1 gnu/packages/haskell.scm:1355 3a0f840>) ("ghc-extensible-exceptions" #<package ghc-extensible-exceptions-0.1.1.4 gnu/packages/haskell.scm:1255 3a0fb40>) ("ghc-x11" #<package ghc-x11-1.6.1.2 gnu/packages/haskell.scm:1398 3a0f6c0>))

<fps>then do that recursively

<fps>let's see

<fps>(map car (package-inputs (specification->package "xmonad")))

<fps>$5 = ("ghc-mtl" "ghc-utf8-string" "ghc-extensible-exceptions" "ghc-x11")

<fps>etc.. does this help to get started?

<fps>[that last step wasn't recursive, but at least i got the package names out one level deep]

<lfam>I'd only need it one level deep since I am just linting my own contributions

<fps>do you just need to do it once?

<lfam>Well, I will probably want to do it many times in the future. I really need to spend some time learning how to use the Guile REPL.

<lfam>I don't use it at all now

<fps>lfam: do you know at least a little lisp/scheme?

<lfam>fps: I can, with effort, understand the Scheme used in Guix packages and internals. I often need to read the Guile manual. But I haven't written anything in Scheme besides what goes into package definitions, and that's really just the Guix DSL

<lfam>It's on my list of "winter work"

<fps>ok, the above is almost somewhat usable then. let's finish it then. note i'm a guixsd/guile noob and discover along here :)

<fps>so your packages live in a git clone

<fps>i wonder: if you do ./pre-inst-env guile

<fps>and then (use-modules (gnu))

<fps>and (use-modules (guix packages))

<fps>and then (specification-package "your_package_name_here")

<fps>do you get an error? or something that looks like:

<lfam>ACTION tries it

<fps>oops

<fps>specification->package

<fps>note the "->"

<lfam>(use-modules (gnu)): it seems that every package variable is "possibly unbound"

<fps>oh drats, you might also need to do (use-modules (gnu packages))

<fps>hold on. i think i actually got a custom package on this guixsd install, too.

<lfam>In procedure module-lookup: Unbound variable: specification-package

<lfam>That's what I get when I do (specification-package...)

<fps>yes

<fps>specification->package

<fps>had a typo there

<fps>note the "->"

<lfam>like this: (specification-package -> "lets-encrypt")

<lfam>?

<fps>(specification->package "lets-encrypt")

<fps>it's just the name of the function that has a -> in it :)

<lfam>Okay, it compiled some scm files and gave me this: $1 = #<package lets-encrypt-0.0.0.dev20151114 gnu/packages/tls.scm:359 2141480>

<fps>awesome, now do:

<fps>(package-inputs (specification->package "lets-encrypt"))

<lfam>Okay, it returns the inputs. I altered it to get the propagated-inputs, which are the bulk.

<fps>ok, now do (map car ((package-inputs (specification->package "lets-encrypt")))

<fps>or with propagated inputs instead of package-inputs

<fps>do you want me to comment on what the (map car ...) part does?

<lfam>I get the basic idea of map from other applications, and I know about car, cdr, and cons

<fps>ok

<fps>you noted that the result of the package-inputs gave you a list of lists like:

<fps>scheme@(guile-user)> (package-inputs (specification->package "swh-plugins-lv2"))

<fps>$2 = (("lv2" #<package lv2-1.12.0 gnu/packages/audio.scm:920 4a3de40>) ("unzip" #<package unzip-6.0 gnu/packages/zip.scm:74 3c6c240>) ("fftw" #<package fftw-3.3.4 gnu/packages/algebra.scm:325 52dfcc0>) ("libxslt" #<package libxslt-1.1.28 gnu/packages/xml.scm:123 4fdc6c0>))

<fps>and the first entry in each list is a string :)

<lfam>When I ran your command, I got '...'. When I closed the last paren, I got a "Wrong type to apply" on the whole list of inputs

<fps>can you copy and paste the command here?

<fps>ooh

<fps>i had a typo in there :)

<fps>(map car ((package-inputs (specification->package "lets-encrypt")))

<fps>do you see it? :)

<lfam>It's missing a closing paren

<fps>should be:

<lfam>Isn't it?

<fps>(map car (package-inputs (specification->package "lets-encrypt")))

<fps>almost :)

<lfam>Oh

<fps>one too many opening parens

<lfam>Right

<lfam>Great, so it returns the list of package names

<fps>ok, so let's try to massage it into ouputting the names one on each line

<fps>then you can put this into a little .scm file

<lfam>Why, is this Unix? ;)

<fps>and then you can use for n in `guile lalala.scm`; do guix lint "$n"; done

<lfam>Nice :) This will be useful. I will actually use GNU Parallel to do it faster

<fps>haha, good thinking :)

<fps>one moment. gotta find out how to print in guile ;)

<fps>(map display (map car (package-inputs (specification->package "swh-plugins-lv2"))))

<fps>almost there. still missing line breaks

<fps>(map (lambda (name) (display name) (display "\\n")) (map car (package-inputs (specification->package "swh-plugins-lv2"))))

<lfam>I realized that some of my dependencies have deeper trees than I remembered.

<lfam>./pre-inst-env guix graph lets-encrypt | grep label | cut -d\\" -f4

<lfam>Inspired by civodul reusing (guix graph) for `guix refresh -l`

<lfam>This has been a good little intro to the REPL though. I really appreciate it!

<fps>cool

<fps>let's do one little thing though

<fps>you might have noticed missing readline support

<fps>which is really annoying

<orbea>yay, I have guix installed on slackware, now I need to grok what to do with it....

<lfam>Actually, I set up Guile with readline a few months ago but I never did anything with it

<lfam>I still have the .guile with the readline bit

<fps>oh cool. i just looked it up again.. :)

<lfam>That would have been really painful without it!

<fps>for any other interested parties: https://www.gnu.org/software/guile/manual/html_node/Loading-Readline-Support.html#Loading-Readline-Support

<lfam>Do you know what the number in the REPL prompt means? It increments... sometimes

<fps>yeah, it's an error context i think

<fps>you can ctrl-d out of it

<lfam>I noticed that.

<fps>i think it's there so you can inspect the state where the error happened

<lfam>So if I have [5], that means I am 5 errors deep? Yikes!

<fps>yeah :)

<lfam>Talk about inbox zero ;)

<lfam>I can't imagine if a Bourne shell prompt counted your errors for you

<Digit>orbea, man pages for the guix commands (like guix package) will help. i hear guix pull is advised upon install of guix sd at least (not sure if relevant in your case). and of course the online docs help too: (one-page version) https://www.gnu.org/software/guix/manual/guix.html

<fps>lfam: it's not really just counting though

<lfam>I know, I checked the manual page. Very nice feature

<fps>lfam: lisp REPLs are powerful beasts :)

<lfam>I have heard this!

<fps>i'm having fun finally discovering them a little too

<fps>glad to have stumbled over guixsd. finally a reason to semi seriously learn me some scheme

<lfam>That's part of what attracted me to Guix in the first place

<fps>ok, let's install network-manager and dump this image to a usb stick :)

<fps>orbea: install some packages maybe :) and maybe watch some of ludovic's talks on what it can do for you

<orbea>im trying guix pull now

<orbea>I made a slackbuild out of boredom and procrastination on other projects, not cause I needed it... ^_^

<fps>orbea: ok, then one straight forward example:

<fps>ever had two projects on disk that needed different versions of the same package?

<fps>and your distri's package manager insisted on only installing one of them?

<orbea>slackware doesn't do that, but I get what you mean

<fps>well, even if slackware allows you to install libfoo-0.1.1 and libfoo-0.1.2 ldconfig will only symlink one of them

<fps>to libfoo-0.1 and libfoo-0

<fps>with guix you can make your two projects each depend on the precise one you need

<orbea>I mean the package manager will never tell you can only install one, but yea, needs some trickery to have both

<orbea>guix seems to make it easier in that regard

<fps>also: ever upgraded a package and everything went to hell but you forgot which precise version you had installed before?

<fps>rollback the upgrade.. etc. pp

<fps>traditional distris suddenly feel so ancient, chaotic and weird

<orbea>rollback is more more manual in slackware, I do like that feature, besides guixsd and nixos the only other distro really offereing it is sourcemage

<fps>i must admit the last time i used slackware was in ftp.funet.fi days

<fps>ca. 17 years ago or so ;)

<fps>never tried sourcemage

<orbea>its like lfs in a way, but lot less manual, instread prompts you upfront on how you want to compile everything

<fps>oh, the memories, sneaking into our uni's computer room aged 16 or so, with a staple of floppy disks, leeching slackware 1.x or so, running home, installing everything, and then one disk had a bad sector

<orbea>:)

<fps>actually, was probably more like 20 years ago. is linux really that old? or am i confused?

<fps>oh, i tried LFS once ;)

<fps>that wasn't too much fun...

<Digit>fps, >20 years since the kernel and slack 1.0

<orbea>heh, how much space does /gnu usually use? more or less?

<orbea>I might have to make a partition for it ^_^

<fps>Digit: yeah, horrible :)

<fps> http://www.slackware.com/announce/1.0.php

<fps>1993 ;)

<fps>orbea: you mean guixsd

<fps>?

<orbea>no, the /gnu directory when you install guix on another os

<fps>no idea. i only ever tried guixsd.. once you install some packages all dependencies are stored though. so you might get an extra libc besides your os's, etc.

<fps>possibly multiple ones, depending on how many generations you keep..

<fps>so maybe give it a gig or two to just play around? no idea

<orbea>its a bit over a gig now in the middle of hte guix pull, its unpacking gcc

<Digit>"hd space is cheep" io've heard quipped a few times surrounding guix. u can let it get really big over time if u keep every past [*forgets proper term]* state.

<orbea>yea, i have lots of space, just not on my root partition....

<Digit>ACTION wonders if a gnu/store partition could be symlinked/mounted n have everything "just work"

<fps>Digit: i wouldn;t know why not..

<orbea>i was thinking about sticking /gnu in its own partition

<fps>you might possibly even just ctrl-c out of it

<fps>copy the stuff somewhere else

<fps>mount the fs

<fps>and redo the pull

<fps>it shouldn't redownload completed packages

<orbea>im plannning to if it gets too bad

<fps>transactions are useful :)

<orbea>7 gbs left

<fps>only possible pitfall might be dates on the files

<fps>note how they should all be unix time 0?

<fps>eh, i need to zZz

<fps>have fun..

<orbea>night

<fps>nn

<lfam>Hmm, I have a bunch of commits that are just making python-2 versions of packages introduced in earlier commits. So just two lines of code plus an empty line, all together. When I try to squash these onto the "full package" commit, it starts a big chain reaction of having to manually edit ALL the patches. What is going on there?

<lfam>If interested, this is the branch: https://github.com/lfam/guix/tree/wip-lets-encrypt

<lfam>The commits are the ones adding the zope libraries, and the later commits adding python-2 versions of the zope libraries. It's a package manager database of sorts

<lfam>Sorry, I copied and pasted that from #git. You all know what it is :p

<orbea>aww gzip didn't build http://dpaste.com/3D04303

<lfam>orbea: You ran out of space in your build directory

<orbea>really, that doesn't look right...

<lfam>It's in the 2nd line

<lfam>How much space does that partition have? It defaults to /tmp

<orbea>its at 2 gbs free now

<orbea>does it clean up after itself after failing?

<orbea>I should have it compile elsewher eanyways

<lfam>Yeah, that may not be enough. At the moment, my guix-daemon is using ~/tmp, because /home is very large on my machine

<lfam>I had a compilation run out of space on /tmp after several hours earlier today

<lfam>I also had to enlarge my / to make room for the store.

<orbea>:) just made an 8 gb xfs partition for /gnu and store

<lfam>Maybe add a few more gigabytes and put a guix-build directory on there

<orbea>yea, good idea

<lfam>What is the difference between the x11 license and the expat license? Lots of software seems to conflate them and just call it "MIT". I'm trying to figure out how to distinguish them.

<lfam>It looks like the only difference is that the x11 license specifically names the X Consortium in the disclaimer and has some clauses relating to that.

<orbea>ACTION goes back to guix pulling with a 16 gb xfs partition

<lfam>orbea: That should be sufficient

<fps> https://pastee.org/3abh3

<fps>how could you people live without redshift

<fps>anyways

<fps>is there a way to see the configure output?

<fps>probably just missing pkg-config anyways

<fps>found it

<fps>man, the damn .po files screw with me

<efraim>translations in qt apps just about killed me when I was packaging owncloud-client

<civodul>Hello Guix!

<efraim>hi!

<fps>yo

<efraim>i'm not sure that guix refresh works too well for python packages

<fps>efraim: it's mostly that they are in git control

<fps>efraim: and you have to keep them in mind when commiting

<fps>one still slipped through for no reason i could tell

<fps>so i had to revert everything lalala

<fps>maybe i should file a bug report about it

<civodul>efraim: what do you mean?

<civodul>or fps?

<efraim>civodul: guix refresh -l python-pyjwt only listed the package I was working on, but I didn't add it so I was sure it should be used by something else

<efraim>guix refresh -l python-py gives a more standard 15 immediate, ~50 dependants

<efraim>python-oauthlib only lists itself as a dependant, but I'm sure I didn't add it, so its like it magically appeared

<efraim>I should look at it more, this whole upgrade and revert and build and rebuild, trying to not break anything while adding missing depenencies and enabling tests is driving me crazy

<efraim>guix build python2-oauthlib works perfectly, guix build python2-keystoneclient tries to rebuild python2-oauthlib and fails

<fps>civodul: i have a guix git clone

<fps>civodul: edit some package module

<fps>civodul: then build/install the package.. and all kinds of .po files changed

<fps> https://pastee.org/3j5se

<fps>git status output

<civodul>efraim: from a quick grep, what "guix refresh -l python-pyjwt" is correct

<civodul>efraim: if you find something doubtful, could you grep gnu/packages/*.scm to see if it makes sense, and report the problem if it doesn't?

<efraim>sure

<civodul>fps: you can ignore those; but i think the .po only get regenerated upon 'make dist' or something

<civodul>so it's not something that shows up every day normally

<fps>civodul: my point was that ignoring those takes extra work

<fps>and i don't think i ever did make dist

<fps>maybe it was included in the all target though

<civodul>you did "make all"?

<fps>nah

<fps>i did "make"

<civodul>i usually run "make", and that doesn't rebuild the .po

<fps>./boostrap; configure --prefix=/; make

<fps>iirc

<civodul>ooh, ./bootstrap

<civodul>you just need to run it once in your life

<civodul>then never touch it again :-)

<fps>yes

<civodul>that's the cause of the issue

<fps>i did and then never touched it again

<civodul>ok

<civodul>so when you run it, it'll trigger the .po rebuild

<civodul>the first time

<civodul>but then that's fine

<civodul>isn't it?

<fps>well, i need to actively avoid checking those changes in

<civodul>(still an annoyance, i agree, but if it's just once, that's fine)

<fps>or should i put them in .gitignore?

<civodul>just do "git reset --hard"

<civodul>they won't show up again

<fps>yeah, i'll limit the reset to the po files though ;)

<fps>otherwise my changes are lost :)

<fps>civodul: but thanks for the tip

<fps>ugh. gotta do checkout instead i suppose

<zacts>hi guix

<fps>ok, awesome..

<fps>civodul: thanks

<zacts>how will gnunet be used with guix?

<fps>zacts: interesting question :)

<zacts>:-)

<fps>afaict sks to retrieve chk for substitutes

<fps>this is not fully decentralized though

<zacts>what does sks mean?

<fps>zacts: hold on

<fps>chk identifies files, typically: gnunet://ecrs/chk/[file hash, using 0-9A-V].[query hash, using 0-9A-V].[file size in bytes]

<zacts>ah ok

<fps>sks identifies files within namespaces, typically: gnunet://ecrs/sks/NAMESPACE/IDENTIFIER

<fps>where NAMESPACE is a public key base32hex encoded

<fps>hold on, i'll paste some ML links which i got thanks to lu

<fps>civodul:

<fps>;)

<fps> https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00455.html

<fps> https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00033.html

<zacts>oh neato

<fps>i'm very interested in moving that forward, too

<fps>since hydra is so bog slow that my expected reward function indicates that it'll overall save me time in the pretty near future

<fps>i was gonna try to get gnunet running for my account first at all

<fps>the documentation sadly, while being complete, is pretty lacking

<fps>and no, that's not a contradiction ;)

<fps>the one thing that it lacks is: you have the gnunet binaries in SOMEPATH, here's the n commands to get _anything_ done ;)

<fps>which is always a good starting point

<efraim>they seem to assume either a working knowledge of gnunet, or gnunet-gtk installed

<fps>precisely

<fps>i have no interest in gnunet-gtk

<efraim>it should help with the learning part

<fps>i started to study the developer's manual, which seems to be complete in the aforementioned sense that it lacks working examples

<efraim>finally rechecked hydra, python2-setuptools fails on hydra too, so I don't need to worry about anything that relies on that

<civodul>fps: it's great that you're looking into it!

<civodul>though for the immediate need of work around slow hydra, it's much easier to set up 'guix publish' somewhere :-)

<civodul>but long-term, p2p is the right thing

<fps>i could also offer some bandwidth by cache proxying hydda on my server, but i sadly have limited disk space.. only a few tens of G

<fps>*hydra

<efraim>off the cuff idea, would it work to have hydra say that the url for the substitutes is at a gnunet url instead of an http one, and have people interested in making substitutes available run a version of hydra

<fps>50G or so

<civodul>fps: or just build stuff on that machine and run 'guix publish'

<efraim>from `guix publish` how do we let people know they're there? word of mouth?

<civodul>they'd have to let others know

<civodul>so you would email the list with the URL and public key

<fps>hmm, let me think. i have another vm on that server that has ca 90G of disk space and it runs guixsd. but it's not publically reachable. i suppose i could forward the http port though

<fps>civodul: is setting up hydra hard?

<civodul>rather hard

<civodul>it'll be easier when we have a GuixSD service for it

<fps>i suppose i could try to make the vm publically accessible.. 4G of ram, 90G of hd, 2-4 cores

<fps>on a

<fps>model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

<fps>about half a TB of traffic to spare i'd reckon

<fps>[per month]

<civodul>sounds good!

<fps>and i could provide a sudo enabled ssh accessible user account for a knowledgable party to set up hydra

<fps>;)

<civodul>and then periodically do: guix build $(guix package -A | cut -f1)

<civodul>honestly, just do guix publish plus this

<fps>oh, i could just try that now.. and let it run, since i got stuff to do

<civodul>it'll be much easier

<fps>civodul: that works as unprivileged user?

<fps>how much diskspace does one generation of building the whole thing take?

<civodul>fps: yes

<civodul>re disk space, i don't know exactly

<civodul>several 10s of GiB maybe

<fps>civodul: oh well, doing a guix pull and then recofigure to add a user to do the work, and then i'll let the build run. we'll know more later ;)

<civodul>cool!

<civodul>you can use guix-publish-service in your config

<civodul>super easy :-)

<fps>civodul: just add it to the service list?

<civodul>see http://www.gnu.org/software/guix/manual/html_node/Base-Services.html#Base-Services

<civodul>yes

<civodul>but do run "guix archive --generate-key" beforehand

<civodul>(that takes a while)

<fps>ok

<fps>as root?

<fps>or as the user that publishes later?

<fps>efraim: re your previous comment:

<fps>that would require users to have a working gnunet setup

<civodul>the key must be generated as root

<civodul>fps: you'll also have to choose whether or not you want to use substitutes on that machine, in which case it would mostly be a "mirror"

<civodul>it's best if you build everything locally, but it's up to you!

<fps>efraim: setting up a basic gnunet-service for fetching from the gnunet dds is, i guess, part of getting gnunet involved

<fps>efraim: to make it easy for people to use it. there's so many details unclear to me yet though, that i rather not say more for fear of spewing nonsense :)

<fps>civodul: ah right, the keypair has to live in /etc/guix

<fps>civodul: you mean in the guix build invocation? i.e. --no-substitutes?

<fps>wow, that's a rather secure key pair judging from the time it takes to generate ;)

<fps>probably secure until the heat death of the universe

<fps>ok, key pair generated. yay

<fps>build@raksha ~$ guix build $(guix package -A | cut -f1) -c 3

<fps>guix build: error: rsem-makefile.patch: patch not found

<fps>civodul: do i need to guix git clone for that user? i thought guix build should just work with the system wide guix

<fps>hm hm

<fps>too bad i gotta go for a while now..bbiab..

<efraim>oh fun, new version of python-mock wants python-pbr, which depends on python-mock to build. Got a stack overflow/cyclic dependency error

<efraim>I could add a pegged version of python-pbr-1.3.0, but I should probably peg a version of python-mock pre dependency on python-pbr also

<efraim>i'll draw circles in the air while I walk to school and figure that out :)

<civodul>fps: rsem-makefile.patch was missing from the release; could you do a guix pull?

<fps>civodul: sure

<civodul>ACTION has to go

<fps>hmm, that didn't fix it...

<fps>even after sudo guix pull, guix system reconfigure and a reboot

<fps>i have a feeling that the program patch is just missing

<fps>had to remove plink and rsem from the list of packages to build.. now something's happening i think

<fps>guix build -c 3 --no-substitutes --verbosity=3 $(guix package -A | cut -f1 | grep -v rsem | grep -v plink)

<fps>at least this runs a little longer witout output for now

<fps>loads and loads of build fail with guix build $(guix package -A | cut -f1)

<fps>i'll report on the ML

<davexunit>hopefully you'll elaborate

<davexunit>because there's no detail here

<davexunit>are you using substitutes? which version of guix? which architecture?

<fps>hold on.

<fps>x86_64

<fps>sudo guix pulled a couple of hours ago.. reconfigured the system, so the user has the system guix..

<fps>fps@raksha ~$ guix --version

<fps>guix (GNU Guix) 0.9.0

<fps>my latest attempt at filtering out all the failures..

<davexunit>'sudo guix pull' updates guix for the root user

<fps>yes

<davexunit>did you also start the builds as the root user?

<fps>and then i did a system reconfigure as root

<fps>so the current guix got into the system profile

<davexunit>that's not how it works

<davexunit>the version of the guix-devel package that is in (gnu packages package-management) is what got installed to the system profile

<davexunit>and that is surely different than the version that the root user now has after 'guix pull'

<rekado>As I decend further and further into the madness of the tangled web of Ruby dependencies I begin to doubt my decision to package buildr just to be able to build the two dependencies of Maven. Maybe it would be better to spend time to work around the circular dependencies in Maven.

<davexunit>rekado: on the bright side, you've really helped improve our ruby support. :)

<fps>davexunit: oh ok. that was a missing piece of information that actually makes sense

<fps>davexunit: thanks

<davexunit>yw

<fps>i'll do guix pull as user then

<davexunit>you won't do any rebuilding if the pulled version is the same as what root is using

<davexunit>since it's already built

<fps>nice.. you're right :)

<fps>awesome..

<fps>ok, then i'll try the build of everything again :)

<davexunit>that pipeline is pretty crazy

<davexunit>you can just use scheme instead

<rekado>fps: why remove rsem and plink? Is there anything wrong with them?

<fps>yeah i reverted to guix build -c 3 --no-substitutes --verbosity=3 $(guix package -A | cut -f1) now

<fps>rekado: in 0.9.0 yes

<fps>they don't build :)

<rekado>oh.

<rekado>is it fixed in master?+

<fps>dunno, will find out soon-ish (couple of minutes to hours)

<fps>i still get this:

<fps>;;; Failed to autoload make-session in (gnutls):

<fps>;;; ERROR: missing interface for module (gnutls)

<fps>ERROR: In procedure module-lookup: Unbound variable: make-session

<fps>and some 404s

<davexunit>your gnutls setup is broken

<Steap_>fps: have you installed guile-gnutls ? :p

<fps>no, should i?

<Steap_>yes.

<Steap_>not sure whether that is the exact name of the package

<Steap_>it is used for https urls

<fps>build@raksha ~$ guix package -i guile-gnutls

<fps>guix package: error: guile-gnutls: package not found

<fps>ok, taking a look

<rekado>you can search with "guix package -s gnutls"

<davexunit>it's just 'guix package -i gnutls'

<davexunit>I don't need this on guixsd

<fps>i am on guixsd, too

<desiderantes>hello, i am following the steps on https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html, but the command on step 5 is taking a LONG time, is this normal?

<fps>why doesn't guix have it as dependency then if it needs it for functioning?

<fps>anyways, need to shower and work. hf

<Steap_>love the passion

<Steap_>people wake up and go straight to guix

<Steap_>before showering, eating, working

<rekado>desiderantes: it's a daemon. It will never finish.

<rekado>it is supposed to run in the background.

<rekado>you can leave it running or append & to make it go into the background.

<rekado>we also offer a systemd unit file with which you can run the daemon as a service.

<desiderantes>rekado, oh nice, i was expecting that to just fork

<davexunit>that would be bad.

<davexunit>that's the init system's job

<desiderantes>well, i get "warning: failed to install locale: Invalid argument" when authorizing the hydra.gnu.org substitute

<desiderantes>:(

<efraim>I fixed python2-setuptools-scm, so when I push it we should have a flood of newly built python2 packages that were held up by it

<rekado>desiderantes: that's not an error. Just a warning.

<rekado>efraim: would this not also cause a rebuild of all other python2 packages?

<rekado>I think it would be better to push it to core-updates or a separate branch.

<fps>same error after guix package -i gnutls

<efraim>rekado: a whole bunch of python2 just isn't building because python2-setuptools-scm wasn't building

<rekado>oh, sorry, I thought you fixed "python2-setuptools" not "python2-setuptools-scm".

<fps>oh well, off for work..laters..

<efraim>desiderantes: export GUIX_LOCPATH=/home/efraim/.guix-profile/lib/locale:/home/efraim/.guix-profile/share/locale

<rekado>the latter will of course require much fewer rebuilds.

<efraim>except with your username instead of efraim

<rekado>or with $HOME instead of "/home/efraim"

<efraim>that would also work nicely :)

<efraim>rekado: I'm going to rebase the python packages that I'm working on and try to build the python2 versions, that should see if they build nicely

<rekado>efraim: thanks for working on it. I wasn't even aware of the failure in setuptools-scm.

<efraim>i take a look at hydra now and then and see if there are low hanging fruit :)

<desiderantes>efraim, rekado, thanks

<piyo>"The following environmental variables maybe needed" How do I get this to display again so I can check it? The last time I got this message I was doing a guix package -i guix in my user account on my foreign distro.

<rekado>guix package --search-paths

<piyo>confirmed

<piyo>thanks

<efraim>pypi is down, so I'm going to have to take a break :)

<efraim>civodul: I fixed python2-setuptools-scm and updated it to 1.9.0. I've been working on some of the packages that depend on the python2 version to update and make them build, but with the new packages it'll end up being emails to the mailinglist later

<efraim>so i'm thinking of just uploading the setuptools-scm fix and working out the rest later. As far as I can tell there are no new broken packages from the update

<efraim>I could split it up to the fix and the update if you think that'd be better, but it'll have to be in a little bit, i g2g

<civodul>uh?

<civodul>i think i'm a bit lost but do send the details on list! :-)

<lfam>I have a patch that applies to a program called "python-configobj". It also applies to "python2-configobj". How can I satisfy the linter? It wants the patch's filename to include the package name, but I can't make it match both. Currently, the patch name is "python-configobj-setuptools.patch"

<lfam>To clarify, the linter complains when I lint python2-configobj.

<davexunit>Kodi was a real beast, but I think I've finally wrangled it.

<davexunit>the recipe is ~150 lines long!

<lfam>Heh, a procedure should never be longer than 24 lines! ;)

<lfam>davexunit: In the final stages of packaging lets-encrypt. I have real certs installed on server with it :)

<lfam>on my* server

<lfam>Thanks for getting it started. Should I add your name to the copyright list of python.scm?

<lfam>And tls.scm

<davexunit>lfam: awesome!

<davexunit>lfam: yes, please.

<davexunit>if any of my packages are still present.

<lfam>davexunit: Awesome. The zope packages are still mostly present (especially your wrangling of the circular depedency) and I'm sure the lets-encrypt package has enough of your work. You really got it off the ground so I'd say you have a piece of it.

<lfam>davexunit: What is your preferred email address for the copyright attribution? I see two in gnu/packages. gnu.org and worcester.edu

<davexunit>lfam: gnu.org pls

<lfam>Okay

<davexunit>(it just forwards to the other)

<davexunit>(because gnu doesn't have IMAP)

<efraim>hello guix!

<davexunit>yesssss Kodi built successfully!

<davexunit>now to do all of the boring cleanup

<efraim>without special handholding along the way?

<davexunit>fully automated in a guix recipe

<davexunit>it's ugly

<davexunit>but it works!

<lfam>That's awesome

<efraim>wow, nice

<davexunit>yeah, this is a big one for me.

<davexunit>it unblocks the migration of my last computer to GuixSD

<davexunit>now I just need a Kodi service and a Transmission web service.

<davexunit>my living room computer is a home theater/torrent box

<davexunit>but it's been badly neglected because it is a fragile debian sid setup

<davexunit>and pretty much every time I try to do something I break it

<davexunit>hadn't pulled in awhile, apparently a bunch of stuff has been updated so I have to rebuild everything :)

<efraim>wow

<efraim>do you have apt-list-bugs installed on it?

<davexunit>where everything is just a handful of things

<davexunit>efraim: no

<efraim>it makes running sid much easier

<davexunit>it's just a system that accumulates cruft because I had to set it up in a special way to get xbmc to work right

<lfam>Or you could run stable with Guix on top :)

<davexunit>no point when I can run GuixSD

<lfam>For the rest of us rubes

<efraim>s/apt-list-bugs/apt-listbugs

<davexunit>I need several system services as well, so it's much better to use GuixSD.

<efraim>completely off topic, I was thinking about silly commands I've run in the past, and it took me a long time to switch from running `cat foo | grep bar` to just running `grep bar foo`

<davexunit>the old "useless use of cat" thing

<efraim>i need to reread the cut or grep manpage, I remember there being something about finding a string and printing the lines above and below it

<efraim>last time I saw it, it involved using `wget -O -`, parsing the website, and passing the baseball scores to conky

<lfam>efraim: For grep, use -A and -B for after and before. For example: `grep -A10 -B10 query` will give ten lines of context before and after.

<lfam>I use this heavily in gnu/packages while searching for examples

<lfam>`grep -rI -A5 -B1 query`

<lfam>piped into less

<efraim>yes! that was it

<efraim>also just learned, `grep -c foo bar` and not `grep foo bar | wc -l`

<lfam>Hmm, I'm trying to clean up lets-encrypt before submitting for review. I want to drop an old commit but the rebase just results in this awful chain of merge conflicts from the deleted commit to HEAD

<lfam>what the heck

<davexunit>because each subsequent commit has an overlapping diff

<davexunit>this happens when packages are added one after the other in the same file

<lfam>Exactly. That overlapping diff is literally a single blank line

<lfam>Over and over and over

<lfam>Any advice?

<davexunit>keep resolving those conflicts and be done with it

<davexunit>:)

<lfam>So, eventually the conflicts will be over? I won't be resolving merge conflicts for every commit made in the future, to infinity? ;)

<davexunit>once you drop the patch and finish the rebase, you will be free... for now.

<lfam>If I set a git tag now, will I be able to undo the rebase by checkout out tag if necessary?

<lfam>*checking out the tag

<davexunit>or note down the SHA, or abort the rebase

<lfam>I'm removing the python-zope-component-bootstrap because I was able to get everything to build without it. But I want to be able to get it back if necessary.

<efraim>you could export it as a patch

<efraim>or you could add a second commit reverting it

<lfam>True. There are many options. I just want to minimize the number of times I resolve a couple dozen merge conflicts.

<lfam>Hm, that seems easiest. It might be ugly in the submitted patchset but it could be useful.

<lfam>I will do that. I expect to have to make a lot of changes after sending it to the ML so I guess it's okay.

<davexunit>don't send a patch set to the list that reverts another patch in the patch set

<lfam>Okay then :(

<davexunit>just clean the patch set up once

<davexunit>I don't see the problem.

<lfam>So much time...

<davexunit>you only have to do it *once*

<lfam>More valuable than a pretty changelog

<lfam>Maybe not. If I want to join the python-zope... and python2-zope... commits I also have the same kind of conflicts. It adds up to a lot.

<davexunit>do it in a single rebase

<davexunit>actually, no, that won't cause more conflicts if you squash them

<lfam>The squashes don't happen cleanly. I tried it yesterday.

<davexunit>that doesn't make any sense

<davexunit>you must be re-ordering the commits

<davexunit>squashing by itself *cannot* create conflicts

<davexunit>re-ordering or dropping commits can

<lfam>I split your big commit into a bunch of python-zope... commits, per package. Then, I added a bunch of other dependencies. Then, I created all the python2-zope... packages. So, when I try to squash a python2-zope... onto its python-zope... partner, I get the chain of merge conflicts.

<davexunit>because you're re-ordering the commits

<davexunit>did you add the python2 variants directly under the python3 version?

<lfam>In the code, yes. In the git history, no.

<davexunit>so you should re-order everything as needed and deal with the conflicts the one time that you need to deal with them

<davexunit>once you've re-ordered them, you're good to go.

<lfam>Ah, you think that will work? Just re-order them in one big annoying rebase, and then the squash rebase will go easily?

<davexunit>yes

<davexunit>squashing cannot cause conflicts

<lfam>Alright, wish me luck.

<davexunit>good luck.

<davexunit>I know it's gross, but you've just gotta hang in there and get it done one time and then you should be free.

<davexunit>enca, recode, and other packages changed yesterday don't seem to have been rebuilt on hydra yet

<davexunit>wtf?

<lfam>Is there a way to view the changes in the commit dialog while rebasing? Like what you get from `git commit -v`.

<davexunit>dunno

<davexunit>I just use magit

<lfam>I am hampered by my poor tools

<efraim>I used to use gitk, but then I found tig

<orbea>is it possible to set TMPDIR for guix and only guix? Other programs like firefox also use it and that is annoying....

<civodul>orbea: you mean for guix-daemon specifically?

<orbea>without typing it everytime

<orbea>yea

<civodul>yeah you can run it like: TMPDIR=/foo/bar guix-daemon ...

<lfam>orbea: If you are using systemd, you can set it in the unit file with a line like: Environment=TMPDIR=/special/tmp

<orbea>no systemd here

<orbea>I start it with a rc.guix script, I could stick the environment variable in there, but kind of wanted to avoid it

<orbea>I guess that is best way... http://dpaste.com/39R2FZK

<orbea>thanks

<civodul>hmm tk-update still being built

<efraim>its progressing, but slowly

<civodul>yeah :-(

<civodul>taylan: do you want me to take care of finalizing the 'guix pull' patch?

<civodul>i think it should go in now :-)

<davexunit>ACTION sees 23 patches from lfam roll in

<davexunit>let's encrypt!!

<lfam>:)

<lfam>Feedback please

<civodul>woohoo!

<davexunit>soon I'll be able to have real ssl certs

<davexunit>I've got 3 patches incoming to add Kodi

<davexunit>hairiest package recipe I've ever written.

<lfam>Heh, I'd like to see it

<lfam>I just closed 14 browser tabs that were detritus of Let's Encrypt

<fps>civodul: ok, good to catch you again.. i suppose i still do something wrong doing the build of everything :)

<fps>meh, xterm sucks horribly

<fps>is there a decent terminal emulator in guix? ;)

<fps>oh, gnome-terminal might do. let's see

<davexunit>ACTION uses gnome-terminal

<fps>anyways, i guix pulled both as root and as user, installed gnutls and gnurls

<fps>[using gnome-terminal means i'll have to move away from the default xmonad config though, but starting it manually will do for now]

<orbea>rxvt-unicode

<fps>does it have decent copy and paste, notices URLs reliably etc?

<orbea>yea, if you set it up in .Xresources or w/e you call that fiel

<orbea>*file

<fps>haha

<fps>ok

<fps>no :)

<fps>some things just need to die

<orbea>here is an example http://dpaste.com/0QSV50M

<fps>orbea: but thanks for the tip.

<lfam>I paste into rxvt-unicode with my middle mouse button and copy by selecting

<lfam>Works okay

<fps>yeah.. i like that way for some things, too

<lfam>You can always use tmux with mouse support. I assume screen can do the same.

<fps>but icecat kills that buffer when it autocompletes an url

<lfam>Yeah, that's a pain.

<lfam>What terminal do you want to use? You should package it.

<fps>i usually prefer konsole

<fps>and some other kde tools

<fps>like dolphin

<fps>ugh

<fps>gnome-terminal errors

<lfam>Konsole would require a bunch of kde stuff, wouldn't it?

<fps>fps@raksha ~$ gnome-terminal

<fps>** (gnome-terminal:8307): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

<fps>Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Failed to execute child process "dbus-launch" (No such file or directory)

<fps>lfam: yes

<fps>as would dolphin

<lfam>Well, it's never too early to start packaging something like that ;)

<orbea>have you considered terminator? I don't like it at all, but it might be for you

<orbea>its not packaged for guix yet actually

<fps>is terminator that tiling terminal emulator?

<fps>i think i used it a while ago

<orbea>it can tile, it has a lot of keybinds by default too that are annoying

<fps>i'll try lxterminal and xfce4-terminal

<fps>but i remember the fonts looking horrible in the xfce one

<lfam>That seems like it would configurable

<fps>possibly. i'll give it another try

<orbea>if you like quake styled terms, tilda is not bad, its packaged for guix too

<fps>hm hm, but i like my wm to tile them :)

<orbea>i know that feeling, i use spectrwm here :)

<fps>oh, looks promising

<orbea>I like to look at xmonad, spectrwm and dwm as their own little group of wms, xmonad has haskell, dwm is suckless (minimal) and spectrwm is a nice middle ground, not as extensible as xmonad and not as diy as dwm

<orbea>ACTION afks for class

<fps>there's also a guile scheme based tiling wm

<davexunit>it's actually a generic window manager

<davexunit>which comes with tiling and floating wm configurations

<davexunit>very flexible, but needs love

<fps>yep, that's the impression i had, too

<davexunit>I haven't used it in quite some time due to a few bugs

<davexunit>it's a project that I really want someone to continue hacking

<fps>yeah, imho the only way to move projects forward that don't move on their own is to take some money into one's hand

<fps>and throw it in their general direction

<fps>which i did a couple of times when i still had a decent job

<davexunit>I think the developer got out of guile programming in general

<fps>or pay someone else to do it :)

<fps>that's one of the beauties of free software :)

<fps>i can't pay anyone besides microsoft to implement a particular feature

<civodul>yeah it looks like a nice piece of work

<fps>with free software i can pay anyone who'swilling to do it :)

<davexunit>guile-xcb in particular is interesting

<davexunit>xcb is fully specified in an xml document

<civodul>yeah, very clever

<civodul>i mean the compiler front-end for xcb

<davexunit>so mark witmer, the author, wrote a new language for guile that reads that xml file and produces the interface

<davexunit>yeah

<davexunit>really great

<fps>i'm not getting any progress with building everything btw

<fps>guix pulled as root, as user, yada yada

<civodul>fps: what's the problem?

<fps>but guix --version still shows me 0.9.0

<civodul>that's expected, see http://bugs.gnu.org/19318

<fps>oh ok

<civodul>well, "expected" :-)

<fps>;)

<fps>ok, but you're right

<fps>the nature of the errors changed.. i was just fooled. hold on. trying to get the error copied and pasted..

<fps> https://pastee.org/3vh6x

<fps>is pastee's line display broken?

<lfam>The first error is a 404

<fps>oh ok.now it just seems to be a broken source download

<fps>but then there's his "failed to autoload make-session"

<civodul>yeah, you'll have some of them, see https://www.gnu.org/software/guix/packages/issues.html

<civodul>this one is listed there

<civodul>nevermind the "failed to autoload make-session", it's harmles

<civodul>+s

<fps>is that a followup error? and i should just "blacklist" the broken ones?

<lfam>You should find a better source URI and send a patch :)

<fps>i suppose i could do it differently: use individual guix build commands per package

<fps>so i can continue in case one or the other fails

<civodul>fps: yes, that's what i was going to suggest

<civodul>though that's possibly less efficient

<civodul>but yeah, that'd be great as a start

<fps>civodul: but only time-efficiency wise, not disk resource usage?

<civodul>CPU efficiency

<civodul>well it's equivalent if you use --max-jobs=1, which is the default

<fps>oh well, i'll use gnu parallel then ;)

<civodul>heh

<civodul>or, instead of using 'guix build', you write a tiny Scheme snippet that does the right thing

<fps>that might work, too, but i'm already overdue to sleep

<civodul>ok :-)

<fps>i just need to tell parallel to ignore errors

<fps>then i can let it run overnight

<fps>oh, installing parallel misses perl

<fps>hmm

<fps>interesting ;)

<civodul>"misses" perl?

<fps>guix package -i parallel gives you a parallel that complains about perl not being installe

<fps>guix package -i perl fixes that

<fps>hmm, might this do the job?

<fps>guix package -A | cut -f1 | parallel "guix build {} || true"

<fps>oops

<fps>--no-substitutes

<fps>and for some reason history editing is broken when i do sudo su build -l

<fps>ugh

<fps>oh, line editing in general is

<fps>i'll just do it as my regular user..

<civodul>just run guix-daemon itself with --no-substitutes

<civodul>so you don't have to pass it every time

<fps>next time. started it now.. gn :)

<lfam>Does this mean that Parallel needs perl propagated?

<lfam>I'll look into it later

<civodul>good night/day, Guix!

<roelj>goodnight!

IRC channel logs

2015-11-24.log