IRC channel logs


back to list of logs

<apteryx1>I'm at snowdon.
<lfam>What's snowdon?
<mbakke>Are we doing a quiz?
<lfam>Pub quiz with 0% Jupiler
<pkill9>what's the best way work on the guix importer modules?
<pkill9>also, is the time spent compiling with `guix pull` compiling Guix itself or the package definitions?
<lfam>pkill9: Guix "itself" and the package definitions are not really separate things, so `guix pull` compiles both
<lfam>If you're interested, this is the latest discussion of how slow `guix pull` is:
<xetver>hi, what is the best way to handle shebang paths? e.g. gitolite has some perl scripts (#!/usr/bin/perl)
<Apteryx>sneek: later tell lfam I'm afraid it's not that interesting, but here you have it:
<sneek>Will do.
<Apteryx>rekado: thanks for the guix packages snippets! they're great.
<civodul>Hello Guix!
<snape>xetver: there are some issues with gitolite and shebangs
<snape>or there was, I don't remember clearly. Anyway, the problem with gitolite is that it copies files in user directories, and those files tend to keep references to the store.
<snape>If one of those files has a #!/usr/bin/perl shebang, the easiest way to deal with it probably is to use special-files-service-type to create /usr/bin/perl.
<xetver>@snape thx for the hint. I add an extra-special-file for perl now
<efraim>I was going to add efi support to u-boot for aarch64 but it seems to build with it be default
<jlicht>'ello guix
<Apteryx>owhen patch-el-files fails it doesn't say in which file it was :/
<pch>Hello Guix, i am trying to write my first package scm file and just want to install a custom binary (basically move it from one particular location to another). Which build system should I use for this?
<roptat>that would be trivial-build-system
<pch>yes, i had a look at this, but could not understand how it works
<pch>roptat: is there any example you know of?
<roptat>pch: you can grep for trivial-build-system in the guix source code
<roptat>for instance, the first package in uses that
<jlicht>pch: If you are going to run a binary that has been built on a different system, you might even need to fix it up with `patchelf' as well.
<pch>my requirement is to just to download the cross compiled binaries and install them to certain locations
<pch>i do not want to build it on the target system
<mbakke>pch: Guix can cross-compile too :)
<pch>mbakke: do you mean cross-compile package host->download->install on target?
<pch>mbakke: do you mean cross-compile where package repository is hosted -> download cross compiled binary to target -> and install on target?
<roptat>on host, you can run "guix build ... --target=..."
<roptat>that creates a package for your target, then you can use guix export / guix import to send the package and install it on the target
<pch>roptat: thanks, this is what I am looking for
<roptat>but I'm not sure it could be found on the target... cross-compiling produces a different binary than compiling on the target
<pch>roptat: at the moment am just trying to move a binary file (pre imported - downloaded) from one location to another, and trying to find the way how to do it
<pch>roptat: i mean the bin is lying on a certain location on the target and i want to move it to the install location using "guix package -i"
<pch>roptat: and as we discussed, i want to do it with trivial-build-system, but not able to achieve it
<roptat>if that's a single file, guix download should be able to import it to the store and give you the hash of it
<roptat>that would be useful to write a package defenition
<mbakke>pch: the "source" property of a package definition can also take a filesystem path.
<mbakke>As in (source "/path/to/executable").
<mbakke>Then in the builder you could copy this to %output.
<pkill9>i thought you had to use (source (local-path "/path/to/file"))?
<pch>just have a look to the link i sent, is there something wrong here?
<roptat>oh, I didn't know that
<civodul>pkill9: you can use 'local-file' indeed
<pkill9>does `source` also take a string that is a path to the file?
<civodul>it also takes a file name, yes
<civodul>but that's less future-proof
<pch>roptat: i have uploaded the scm which i am working on
<rekado>on master I get a weird error about module discovery: “(append #<unspecified> ())” is executed and that fails.
<rekado>looks like that was because I had files from gnu/packages/aux-files/linux-libre open in an editor.
<efraim>Autosave files from emacs?
<rekado>I really need Python 3.6 for my pipeline paper :(
<rekado>gotta get core-updates ready
<civodul>rekado: did you see this talk: ?
<civodul>i wonder what a GuixSD-based deployment thing would look like
<civodul>how it would address this use case
<rekado>ACTION investigates the Java problems (ant-bootstrap crash in sablevm)
<rekado>when building sablevm with glibc-2.25 ant-bootstrap doesn’t segfault.
<rekado>since sablevm is just a bootstrap input it should be okay to let it depend on glibc-2.25 for a few weeks to allow us to merge core-updates
<rekado>I’m now building ant-bootstrap 10 times and see if it fails. If it doesn’t I’ll push this fix to core-updates.
<myglc2>Hello, Is there a way to set the host-key in openssh-service-type?
<myglc2>Motivation: building/managing vm-images
<rekado>:( ant-bootstrap failed in one of those 10 builds.
<bavier`>sad day :(
<cbaines>myglc2, doesn't look like it, but if you can probably just put the right files in the right place using the activation service
<cbaines>the extra-special-file procedure might come in handy
<myglc2>cbaines: activation service? don't follow
<myglc2>cbaines: I'll have to try extra-special-file
<cbaines>There is a service type (activation-service-type) which organises running some system setup stuff
<cbaines>myglc2, that will allow you to setup the key when the system starts, but there might be a neater way of building it in to an image... I don't think you can do this yet though
<rekado>I’m now building ant-bootstrap for 10 times with a differently configured sablevm.
<rekado>for python-pandas the solution seems to be reverting the datetime update.
<myglc2>cbaines: OK, Thanks.
<catonano>cbaines: I loved the graph that you showed in your talk, How did you do it ? Last time I tried, Graphviz coulodn' t draw my graph as it was too large
<catonano>couldn' t
<cbaines>catonano, I can't quite remember, but I think it was mostly just tweaking the dot options
<cbaines>and possibly using the sfdp program
<cbaines>I then did the colouring of the derivations in purple in Inkscape
<catonano>I used sfdp too but I wasn' t happy with the result. Probably the npm graph was bigger
<myglc2>cbaines: extra-special-file works to put /etc/ssh/ssh_host_ed25519_key & /etc/ssh/ in the image.
<cbaines>great :)
<myglc2>cbaines: only downside is WARNING: UNPROTECTED PRIVATE KEY FILE!
<mbakke>rekado: pandas was broken before the datetime update.
<mbakke>I expected we had to update the whole numpy/scipy stack. Will give it a go tomorrow.
<rekado>mbakke: yes, pandas always must be updated together with numpy and scipy.
<rekado>I had this problem in the past already when I tried to update the scientific python stack, but scipy wouldn’t build with any of the published versions of the other tools.
<rekado>ended up reverting the update.
<rekado>I can’t get sablevm in the ant-bootstrap build to segfault any more.
<rekado>sablevm is a bit slower now (changed the threading configure flags), but it seems to work fine now.
<mbakke>rekado: awesome! Do you think we're ready to merge once pandas is fixed?
<jsierles>Just making my way back into guix after a while
<jsierles>Updates in 0.14 look good!
<civodul>heya jsierles :-)
<jsierles>Did 'guix pull' get faster?
<rekado>mbakke: yes.
<quiliro>was looking for a screen anything packaged for guixsd yet? i am using i3
<rekado>mbakke: I haven’t been able to check the list of failed builds on core-updates because hydra’s web interface times out for me, but I think java and pandas were the biggest and most important broken parts.
<rekado>jsierles: if you feel it’s faster then I won’t try to convince you otherwise :
<rekado>jsierles: there’s a branch that civodul worked on to make “guix pull” quite a bit faster.
<jsierles>Cool. Going to look through commits now to see what's new
<mbakke>quiliro: guix has "obs", although I haven't tried it.
<mbakke>rekado: I think those were the main blockers too. There's django as well, but I'm willing to forgo that.
<mbakke>And some "leaf" Python packages that didn't have a lot of dependents.
<rekado>ACTION pushed the sablevm fix
<pkill9>where do people submit packages to be added to guix?
<catonano`>pkill9: there's a mailing list for that
<catonano`>pkill9: guix-patches
<catonano`>pkill9: it is also a debbugs instance, so you can use an Emacs based interface for that, if you don't like emails