IRC channel logs


back to list of logs

<lfam>So, I guess there is some very weird issue with my systemd...
<lfam>Is anybody else fetching substitutes over https on a systemd-based OS, such as Debian?
<lfam>I can also see in /proc that the daemon started by systemd has the expected filesystem path
<lfam>I'm tempted to reinstall Guix from scratch, but if other users are having this issue, I'm willing to be the subject of debugging
<lfam>mark_weaver: Good find!
<rain1>looks like building firefox on guixsd is too hard :(
<NiAsterisk>any problems you run into? I'd be glad to know, I plan to do torbrowser sometime in the next months
<rain1>It wants a specific autoconf version 2.13, I cheated and one of guix's versions but the it ca't find some AC macros
<mark_weaver>rain1: you shouldn't need autoconf to build from a tarball release
<mark_weaver>but yeah, firefox is surely a difficult package. icecat certainly was.
<rain1>ill try that! I was using hg
<rain1>which is what i used to do on arch
<mark_weaver>packaging autoconf 2.13 would likely be quite easy
<mark_weaver>but I should warn you: if the autoconf issue seemed too hard for you, you're unlikely to get firefox packaged, because there are surely more difficult problems ahead for you
<rain1>im not packaging ff just building it
<rain1>also I just can't really be bothered debugging autoconf m4 macro search paths
<rain1>these tools are terrible and dont' make life easier
<mark_weaver>packaging it might be easier than building it manually
<mark_weaver>lots of issues are handled automatically by gnu-build-system, and our icecat package would probably be a good start.
<mark_weaver>version 45 will be the new ESR, so icecat will switch to it at some point and I'll need to update our icecat package to deal with version 45.
<mark_weaver>lots of people complain about autoconf, but all of the replacements that people have come up with are much worse.
<lfam>Doing Guix has made me love autoconf (as a packager). There's nothing I dread more than some hand-rolled build configuration system
<lfam>Whereas the autoconf packages *just work*
<mark_weaver>yeah, autoconf is the only thing that's robust enough to deal with unusual systems like ours without a lot of pain
<rain1>except this one
<lfam>Right, except that one
<mark_weaver>any tool can be used badly.
<lfam>Generally they just work ;)
<mark_weaver>from a packager's point of view, I must say that epiphany is by far the sanest modern browser
<lfam>I've noticed you saying that
<rain1>does it suffer from the same problem as midori?
<mark_weaver>rain1: no, it uses modern webkit, with process separation.
<rain1>oh great, maybe i can use that instead
<rain1>for some reason if i make guix environment icecat --ad-hoc gstreamer gst-plugins-base
<mark_weaver>at present, it uses a version of webkitgtk that was just released within the last week or two, with fresh security updates from upstream work by apple.
<rain1>oh nv
<NiAsterisk>mark_weaver: with this package (rust) after I already wrote my own I discovered one on with your name from around 2014. I suppose you don't remember where it failed or why it never was finished?
<lfam>rain1: That only 'ad-hocs' gstreamer, but not gst-plugins-base
<lfam>rain1: You have to put '--ad-hoc' for each package
<mark_weaver>NiAsterisk: I've never packaged (or even used) Rust. what's the link?
<NiAsterisk>maybe I am wrong about that. one moment
<mark_weaver>I might have tried to help someone else trying package it, though
<mark_weaver>I don't remember
<mark_weaver>I am the maintainer of Guix's icecat package
<NiAsterisk>yes. sorry I thought I opened another termianl
<mark_weaver>rain1: what did you mean by "on nv" ?
<NiAsterisk>I can't locate the bookmark. I guess you helped someone with it
<rain1>the icons are all missing in epiphany
<NiAsterisk>one of the many packages I need for panopticon which now uses too much cargo, so I need cargo import, which will happen at some point too because I want panopticon :)
<rain1>wonder if i should take a screenshot
<rain1>if anyone is interested in that
<lfam>rain1: Heh, I think we can picture it in our minds
<mark_weaver>rain1: interesting. I've only ever tried to use it from within GNOME and Xfce. maybe it depends on something else being installed in the system (or user) profile
<mark_weaver>rain1: can you run it within strace and see what it's trying and failing to find?
<rain1>theres 4000 lines of ENOENT
<rain1>I guess ill grep -v away the ones that aren't interesting
<mark_weaver>rain1: in the environments where I run epiphany, XDG_DATA_DIRS is set to include many directories
<mark_weaver>my first guess is that something is missing from that
<rain1>here's the value of that variable for me:
<rain1>so other than defaults its just got xfce4 session
<rain1>this is kind of interesting
<mark_weaver>rain1: I have adwaita-icon-theme installed in my system profile. maybe that's it?
<rain1>oh I think this must be regular guix behavior
<rain1>but it searches for every library in each thing in the gnu store!
<rain1>so that's why there are heaps of ENOENTs
<rain1>what is meant exactly by that being in system profile? I'll do this as my regular user: guix package -i adwaita-icon-theme
<mark_weaver>I also have "Adwaita" selected as my icon theme in the xfce appearance settings
<mark_weaver>rain1: that might be enough, try that first.
<mark_weaver>rain1: but fyi, the system profile is /run/current-system/profile, and contains packages listed in the 'packages' field of your OS configuration.
<mark_weaver>services can add packages to the system profile as well
<lfam>The following package will be downgraded: guix 0.9.0.f888c0b →
<mark_weaver>the system profile can only be changed by "guix system reconfigure"
<rain1>ah I see
<lfam>Shouldn't we should use a "revision" integer between the version and the hash to prevent that?
<mark_weaver>lfam: that should fix your https problems
<mark_weaver>lfam: and yes, we should
<rain1> is not working, I had to use http
<rain1>I think this is a regression?
<lfam>mark_weaver: I can make the change. Should it go to master, core-updates, the mailing list?
<mark_weaver>lfam: it should already be done.
<lfam>Okay then!
<rain1>by the way I wonder about all these "warning: collision encountered:"
<mark_weaver>lfam: civodul updated the guix development snapshot to fix the https problem.
<rain1>mark_weaver, oh that got me all the icons!
<mark_weaver>rain1: that's good! can you email about it, so we don't forget to fix it?
<rain1>ok sent that :)
<lfam>mark_weaver: Do you think it's okay that `guix package -u` sometimes doesn't update to the lastest version of guix-devel due to the hash? I thought I understand what you meant by "it should already be done" but after a few minutes I realize that I don't
<lfam>Currently it's version is defined like this: (version (string-append "0.9.0." (string-take commit 7)))
<lfam>Ideally it should be (version (string-append "0.9.0." revision (string-take commit 7))), right?
<lfam>Or, like that but with added punctuation to separate the revision from the hash
<lfam>Anyways, this solved my https problem, thankfully!
<lfam>I'm very glad for that
<rain1>does guix have something like lxc? containers
<rain1>I guess this pflask thing, it's new to me
<lfam>There is `guix environment --container`, as well some good tools for working with QEMU virtual machines in `guix system vm` and `guix system vm-image`. I don't know whether or not they meet your use case...
<mark_weaver>rain1: there's also an experimental 'guix container' command
<lfam>Wow, I didn't know that one!
<rain1>I would like to run a different OS like arch linux or something
<rain1>would that be possible with either of those?
<lfam>rain1: You could use plain QEMU
<rain1>that's true but it's so hard for my use case
<lfam>By which I mean, without `guix system`
<rain1>it's quite nice to use a browser inside a container, but if it's a VM it makes things like copy/paste between not work
<mark_weaver>rain1: you should ask davexunit about this
<lfam>True, that aspect is annoying. But, if I am running a browser in a container for security reasons, I don't want it to be able to access the host's clipboard anyways
<Piece_Maker>theres a few docker packages available... not sure if the whole suit is available
<Piece_Maker>docker is sort of ridiculous and huge though
<NiAsterisk>which suite?
<Piece_Maker>well i mean, docker-compose seems to be available in guix repos but im not sure if thats all you need for docker containers
<lfam>Piece_Maker: IIRC, davexunit added docker-compose so he could use it at his job. I don't think it's the whole shebang though
<Piece_Maker>yeah thats what i figured
<lfam>If you search the guix-devel archives there should be some context
<Piece_Maker>ive always used firejail on my arch PC
<lfam>BTW davexunit is also our resident container expert. I think he has some choice words about docker ;)
<Piece_Maker>ive never liked docker... its a bit... i dunno, sort of makes me nervous in multiple ways
<rain1>I may have to package debootstrap :/
<Piece_Maker>if i need docker-like containers ive used systemd-nspawn, thats a REALLY nice container solution but doesnt help guixsd as obviously that uses shepherd not systemd
<lfam>rain1: detrout is a Debian developer. She may be able to give you advice
<rain1>is lxc lacking in some way?
<Piece_Maker>rain1: most container solutions i believe are built ontop of lxc
<rain1>I wonder why there's lots and lots of alternatives, I didn'tk now about them and assumedi t was the default
<Piece_Maker>docker is more or less a frontend for LXC, with a docker hub/other such nonsense built around it ;P
<rain1>I don't like docker...
<rain1>I think that its bad
<rain1>some program I wanted to build once uses docker during build for some reason
<rain1>and I tried to build it inside my lxc container and it cannot work
<Piece_Maker>;S yeah, thats no good
<rain1>why did they not make docker work inside a container?
<Piece_Maker>i reckon packaging something like firejail for guixSD would be awesome... not sure how that would work though
<rain1>I am thinking about trying pflask
<Piece_Maker>and not sure how much itd really differ from the current guix package container command hehe
<Piece_Maker>let us know ;D it sounds cool
<detrout>rain1: there's also cdebootstrap which can eventually be just a binary
<detrout>gotta go
<tssseq>Is hydra down at the moment? Just keep getting 504 errors
<NiAsterisk>this in #configure-flags looks a bit broken to me, the part with (which "llvm"), I am not sure. (list (string-append "--llvm-root=" (which "llvm")))
<NiAsterisk>I think I can fix this. nvm the question
<rain1>does anybody have a tip on RUNPATH validation failing?
<myglc2>Hello! I am seeking advice on submitting a patch to the doc
<myglc2>introduction. Issue: patch has a .dot figure but
<myglc2>DOT_OPTIONS make a mess of it. I have the output, a 29K PNG,
<myglc2>which makes my patch weight in at 54K. Would it be horrible to
<myglc2>submit a patch like this? If so, how should I put this up for
<myglc2>discussion and recruit to mode
<myglc2>* hopefull recruit someone to modify
<myglc2>* hopefully
<chewieQC>Is guix participating in Google Summer of code via the GNU project?
<chewieQC>That is very nice
<chewieQC>As a student who wants to learn about reproducible software packaging, should I submit my candidature or is it too "simple"?
<chewieQC>Or not shiny enough I should say
<NiAsterisk>I am not sure, I think others are more informed about the gsoc to reply to that
<chewieQC>Ok thanks
<NiAsterisk>all I know is that should have a news item and link to the gsoc proposed topics
<NiAsterisk>sorry that I can't be of more help :) others will know more
<chewieQC>That is very helpful actually :)
<duende>I am having strange problem installing guix
<duende>Substitute: updating list of substitutes [...] finishes
<duende>and then it starts echoing Substitute: updating list of substitutes [...] 100% nonstop
<duende>(instaling guixSD)
<NiAsterisk>that might have to do with recent guix changes, I read something on the list about this. but I'm away now. good night and success with installing guix :)
<chewieQC>Have you activated any substitutes?
<duende>no I'm just following the installation guide
<Piece_Maker>are there any other substitutes besides hydra...? (just curious) XD
<chewieQC>You can roll your own with the guix publish command
<chewieQC>But there are no other public ones that I now of
<Piece_Maker>do i need a build farm behind it? :P
<chewieQC>Depends on your ambitions :)
<duende>Retying, it seems to be working now
<Piece_Maker>i always thought itd be interesting to build a decentralised package repository running on something like syncthing or the bittorrent protocol... could be possible with the reproducability of guix...
<chewieQC>Check out ipfs
<chewieQC>It's exactly what you need to build that
<chewieQC>I'm actually looking on how to add it to GuixSD right now :)
<rain1>chewieQC, I've been thinking that would be a great idea too
<NiAsterisk>Piece_Maker: check the plans / ideas of guix regarding gnunet distribution and steps in how to get there eventually.
<rain1>oh guix packages over gnunet? that would be amazing
<Piece_Maker>i did read that guix was eventually planned to be decentralised/p2p
<chewieQC>rain1: Could I do that as a GSoC project?
<NiAsterisk>one of the reasons why I am here.
<Piece_Maker>sounds sooo epic
<rain1>I don't know
<NiAsterisk>now I'll be off to bed. good night
<Piece_Maker>the thing i was never able to figure out (i actually tried making what is essentially a decentralised repository for arch's pacman) is that all users neeed to mirror the entire repo... couldnt figure out how to JUST pull the packages that i actually want to install...
<Piece_Maker>but i reckon with gnunet or ipfs that could be worked around
<Piece_Maker>that is, unless EVERY package was its own bittorrent file... which would get messy very quickly
<chewieQC>Piece_Maker: Could use this
<rain1>I had a go packaging lxc, it doesn't work yet though
<rain1>you can run the programs but they give some strange errors
<Piece_Maker>chewieQC: look good - i reckon your ipfs plan would work better though hehe
<rain1>Piece_Maker, what's wrong with each file being its own torrent?
<Piece_Maker>i suppose it wouldnt be THAT bad, openSUSE already does it
<rain1>i think ipfs is exactly designed tto solve this though
<Piece_Maker>they use metalinks not bittorrents
<Piece_Maker>but yeah
<rain1>wow does it!
<rain1>ill look into that, that's pretty cool
<Piece_Maker>openSUSE packages are pulled from ALL their mirrors at once via metalinks using aria2c
<Piece_Maker>its like magic
<Piece_Maker>not quite decentralized, but like... if you could make them into torrents and allow all users of that package to seed
<Piece_Maker>its rudimentary but it could work, and then you just need to figure out how to roll out updates (which i reckon guixSD has already solved too) XD
<Piece_Maker>i reckon guixSD is the perfect distro to actually maket his work with, as all the packages are in /gnu/store and not scattered all over the damn place where youd have to mess about with symlinks and whatever
<rain1>yes :D
<davexunit>omg gnome-keyring is written in javascript!
<davexunit>crazy land.
<davexunit>gnome keyring is giving me all sorts of problems, and then I look at the logs to see a javascript backtrace
<davexunit>I need to somehow remove this from the list of autostart applications
<Jookia>davexunit: polkit is written in JS too. lots of fun
<davexunit>I killed gnome-keyring and started gpg-agent as normal. things are better again.
<davexunit>but I think the only way to really stop this thing is to modify the package recipe for gnome-keyring so that it doesn't install the gnome-keyring.desktop autostart file
<civodul>Hello Guix!
<wingo>ahoi :)
<Jookia>Can Guix generate shell scripts with inline replacements like '#$dhcp' ?
<janneke>Jookia: i am thinking of releasing a template-substitution module
<janneke>i don't think something like this is in guix yet
<civodul>Jookia: there's 'text-file*' which does roughly what you want
<civodul>though it's really Guile scripts that you should generate ;-)
<Jookia>I'm still on the fence about using Guile as an init system given how much space its ccache takes up :(
<civodul>you mean in the initrd?
<civodul>hmm GNOME cannot run in QEMU
<civodul>there's a gnome-session warning about missing hardware acceleration
<civodul>could it be that it's a fatal warning?
<wingo>civodul: yeah we need to pass --disable-acceleration-check to gnome-session
<wingo>alternately it would be nice to figure out how to enable acceleration in qemu
<civodul>is it possible at all?
<wingo>i don't know, proprietary solutions can do it so i assume qemu will soon i guess
<civodul>i'll try --disable-acceleration-check in the meantime
<civodul>i assume this does not disable hardware acceleration when it's available, right?
<wingo>it disables an early check in gnome-session that aborts if acceleration is not available
<wingo>and i think janneke said that adding that option worked for him
<wingo>so probably we should enable it in whatever package it is that starts gnome-session
<wingo>civodul: apparently seems to be the thing
<wingo>still research but is active and hacked on by a good x hacker
<wingo>and marc-andré is a libvirt/qemu person
<wingo>so it seems maybe we will have a nice solution there
<wingo>oh that makes me happy. great stuff.
<civodul>ACTION has to go for a while
<janneke>wingo: yes, that's right
<janneke>sorry to just have missed civodul
<rain1>What would it take to get pacman on arch linux?
<rain1>sorry from arch linux, onto guixsd
<rekado>rain1: you would need to package pacman first. The sources are available here:
<rain1>I get that I was just thinking it might interact weirdly with guixsd
<Jookia>It probably would
<Jookia>Guix wants control of /bin doesn't it?
<rekado>you could use pacman in a container, though.
<rain1>the script that I want to run to build a container needs pacman
<rain1>it's really annoying
<Jookia>I think I may have ruined my Guix somehow
<Jookia>Guix thinks I don't have a GCC install so I built it but now it give really bad errors
<rain1>is there a way to build containers on guixsd already?
<rekado>rain1: "guix environment --container --ad-hoc"?
<rekado>Jookia: did you build gcc-toolchain?
<rain1>how would I get pacman in that?
<Jookia>rekado: I don't know, I compiled the entire system and compiled other stuff, so obviously I have a gcc. Maybe garbage collecting wiped out the gcc that 'guix environment --ad-hoc' wants, though I tried all three. Compiling gcc@4.9 gives me a compiler with weird errors
<rekado>rain1: you first package pacman, then ask "guix environment" to spawn an environment in which "pacman" is available: "guix environment --container --ad-hoc coreutils pacman ..."
<Jookia>oh god
<Jookia>did i accidentally overwrite files in my store
<rain1>I'm trying to package pacman and guix build fails
<rain1>600/800 failed tests
<rain1>it says: See ./test/test-suite.log
<rain1>how could I read that file?
<Jookia>rekado: Have you seen this error: ?
<rain1>I think it's due to: /bin/bash: bad interpreter: No such file or directory
<rain1>not sure how to trick it into thinking /bin/bash exists
<rain1>I see that it generally has a patch shebang phase but it must not be getting applied to the test suite
<Jookia>Is there a special package for linux/limits.h ?
<davexunit>Jookia: linux-libre-headers
<Jookia>It's odd I need that for openssl
<Jookia>I also need glibc to fix 'cannot find crt1.o' but then it seems to work
<Jookia>trying to run the binary gives " error while loading shared libraries:" :\\
<NiAsterisk>I want to work on coreboot without headaches (gives some errors I don't want to fix rn in guix), are there any gnu livesystems with git and developer tools included?
<rain1>autoconf/whatever is giving me nightmares, think I need to give up
<rain1>i couldn't package pacstrap because pacman had errors and I can't package debootstrap because of weird autoconf stuff in libdebian-installer
<NiAsterisk>i have too many livecds.. asking because of that
<jmarciano>please, the future users of GuixSD certainly need a pacman.
<Jookia>a pacman?
<jmarciano>pacman is for fun I know. I like more productivity software.
<rekado>Jookia: why don't you use gcc-toolchain instead of gcc?
<rekado>rain1: what errors?
<Jookia>jmarciano: pacman is a package manager
<Jookia>rekado: I don't know, should I? I have to rebuild gcc I think
<Jookia>oh i guess not
<rekado>gcc-toolchain contains the correct linker wrapper and other stuff you need to build software with Guix
<Jookia>Thanks, that's what I needed
<davexunit>happy friday, everyone! here's a little guix+bash magic to build a Ruby on Rails development environment container:
<NiAsterisk>ACTION shakes fist at 1-month-ago-self
<NiAsterisk>should've bought that beaglebone.. now I am literally stuck with GuixSD until I get a beaglebone, because make of coreboot on guixsd is not easy.
<jmarciano>I understand what it does:
<rekado>are recursive module dependencies a problem?
<rekado>I have a package that should go to "statistics", and it depends on packages in "machine-learning" and "statistics". But the "statistics" module cannot load the "machine-learning" module because "machine-learning" already imports "statistics".
<rekado>Is this a problem or will this be lazily resolved?
<efraim>it'll work out no problem
<efraim>as long as you don't have a cyclical package dependancy
<rekado>oh, good.
<rekado>I also should not use "#:select", right?
<efraim>I've never used #:select
<rain1>I came across this earlier and I just noticed they recommend guix
<rain1>"Look at Guix package manager."
<kristofer>good morning!
<davexunit>rekado: re circular module dependencies: "it depends" ;)
<kristofer>how can I blacklist a kernel module?
<rekado>kristofer: you can add this to the kernel command line: modprobe.blacklist=module,you,want,to,blacklist
<rain1>why does guixsd use lsh instead of openssh? Was just reading
<rekado>rain1: lsh is a GNU project.
<rekado>we also provide openssh.
<rain1>is there a service to use it as a demon?
<davexunit>not yet
<davexunit>been meaning to make one
<davexunit>hoping someone beats me to it
<rain1>I'm just curious if there was more to the decision
<rain1>was it really just because its GNU?
<rain1>that seems odd because lsh is much less well known and used
<davexunit>that's what motivated ludo to make a service for it
<davexunit>apparently no one else has been motivated to make an openssh service
<rain1>btw I think lsh is nice and am glad to learn about it through guixsd
<davexunit>GuixSD is what you configure it to be. lsh isn't *the* ssh server you can use.
<rain1>I packaged lxc but I wasn't able to package any of the tools needed t obuild container templates
<libreH4cker>what virtualisation technologies does Guix have?
<rain1>so I can't really test it
<davexunit>libreH4cker: we have qemu packaged
<kristofer>I'm getting an unbound variable xorg-configuration-file when I run guix system reconfigure
<libreH4cker>davexunit: sweet
<libreH4cker>how does guix as a package manager compare to other libre distros' package managers?
<mark_weaver>kristofer: 'xorg-configuration-file' is exported by the (gnu services xorg) module. so you need either (use-modules (gnu services xorg)) or (use-service-modules xorg) at the top of your OS config
<kristofer>mark_weaver: now the error says unbound variable slock
<rekado>libreH4cker: guix is a functional package manager. I suggest watching some of the talks on to learn what this means.
<mark_weaver>kristofer: "guix package -A slock" will tell you that it's defined in gnu/packages/suckless.scm so add (use-package-modules suckless)
<kristofer>I see.. I'm trying to define a custom set of %desktop-services
<libreH4cker>how's the Hurd support going?
<dptd>Hello Guix!
<rekado>libreH4cker: there will probably be another GSoC project for that.
<libreH4cker>neato. thnx
<dptd>Anyone had such a problem before?
<dptd>Happens all the time. It is log from the guix system init command.
<rain1>I had that happen to me
<rain1>im not sure
<rain1>maybe low memory?
<dptd>rain1: I don't think so. I have 16GB and this is just a clean install (desktop.scm config).
<jmarciano>ocrad - optical character recognition in GuixSD, very nice... let me scan the book of 280 pages.
<chewieQC>Has anyone written a tutorial on how to package software for Guix?
<piyo>chewieQC: this has some good info
<chewieQC>piyo: Thanks!
<NiAsterisk>#:configure-flags (list (string-append "--lvm-root=" (which "llvm")))
<NiAsterisk>does someone spot the mistake?
<NiAsterisk>errors I get are like ERROR: In procedure string-append: Wrong type (expecting string): #f
<bavier>NiAsterisk: 'which' is only for binaries
<NiAsterisk>where llvm is no binary
<bavier>you probably want (assoc-ref %build-inputs "llvm") instead
<NiAsterisk>right, i did this some days ago... /me headdesks
<NiAsterisk>i'm a bit under the weather or whatever.. thanks :)
<redshelled>Hey guys, I moved farther on my install, but now after running the command guix system init, it is trying to build guix- and fails during the store.scm test. Is there away to get around this so I can continue the install?
<davexunit>redshelled: if you are using substitutes then it shouldn't be building locally
<davexunit>so perhaps you aren't using substitutes? did you run 'guix pull'?
<redshelled>davexunit, I am using substitute as it uses substitutes for everything else
<redshelled>yes I ran guix pull before the guix system init comman
<davexunit>well there is a bug here because the guix test suite should pass. what platform are you using?
<redshelled>its on a lenovo e530, on an intel i3
<redshelled>if that helps
<redshelled>it does say at the end of the tests "testsuite summary for guix 0.9.1" Maybe that is intended?
<davexunit>redshelled: it would be great to get the test-suite.log file from that build.
<davexunit>if you have a way of extracting such a log off of the build machine, I could tell you what to run.
<redshelled>ok, ill see if i can grab it
<jmarciano>redshelled: your Lenovo e530 has working wireless with GuixSD?
<redshelled>jmarciano, no I am using it wired
<davexunit>redshelled: run 'guix build -K guix'
<davexunit>that will build guix and keep the failed build around
<davexunit>which will allow extracting the test suite log
<redshelled>davexunit, I am running it now, it may take a few minutes since this machine isnt exactly a compiling monster
<davexunit>okay. thanks!
<davexunit>test suites are tricky things...
<davexunit>they all seem to behave differently on different machines. my guess is that a test that I wrote is failing.
<redshelled>I could understand that. I imagine everything is ok with the build. I was just surprised that it wasnt using the substitute and trying to build it
<davexunit>that's another question
<davexunit>not sure what's going on there
<davexunit>could you try...
<davexunit>guix build guix --substitute-urls=
<redshelled>I tried guix system init <config> /mnt --substitute-urls= and it gave me the same result, still trying to build from source. Maybe the build command will yield different results?
<davexunit>no it will be the same, so nevermind.
<redshelled>my machine is running the tests now so shouldnt take much longer
<davexunit>either way, the build should complete successfully on your own machine so I'd love to know what's going wrong.
<redshelled>when i get it do you want me to paste it to
<davexunit>redshelled: I can confirm that the latest version of the guix package builds locally for me as well.
<davexunit>redshelled: sure!
<davexunit> is fine
<davexunit>let's see if we get similar results :)
<davexunit>such is life on the beta bleeding edge
<redshelled>haha yes, and rough edges are expected :)
<rain1>nothing i can do seems to let my guix system init suceed
<rain1>it always dies on python 2.7.10
<redshelled>i had to build that one from source as well if i remember correctly
<redshelled>that and gobject-introspection
<davexunit>this could mean that either hydra has not caught up and built them *or* that the builds are failing on hydra
<davexunit>it's non-trivial to find out which it is. I want to see that fixed sometime. I'd really like Guix to warn the user if they are about to build something that is known to fail.
<redshelled>ah I see. That would be a useful feature. those two did build successfully on my local machine
<davexunit>redshelled: guix built successfully on my x86_64 machine.
<redshelled>here you go!
<davexunit>drat! just one failure!
<redshelled>looks like a hash mismatch for the substitute too
<davexunit>redshelled: hmm, I'm not familiar with this particular test. could you email describing this failure? include this test suite log, your platform (x86_64), and the package version string for the failing guix
<davexunit>I believe the version string is
<davexunit>if we're running the same thing
<redshelled>it looks like that is mine as well
<davexunit>okay cool
<davexunit>to get your system installed, we could try a little hackery :)
<redshelled>that sounds entertaining!
<davexunit>may or may not work ;)
<redshelled>Well were starting at not working so cant make it worse :D
<davexunit>could you try adding that to the top of your OS config file?
<davexunit>what I'm attempting to do here is overwrite the 'guix' variable with a new guix package that disables the test suite.
<redshelled>ok ill see if that works
<davexunit>redshelled: I didn't test it so perhaps I've made a typo or some other silly error
<bavier>could we perhaps have 'guix build --log-file foo' ignore grafting logs?
<redshelled>davexunit, failed again!
<davexunit>redshelled: that means it ran tests, which means it didn't use our modified guix package
<davexunit>one sec
<davexunit>well, I'm not sure.
<davexunit>a sure-fire way for it to work is to make a git clone of guix
<davexunit>build it
<davexunit>patch the guix package to disable tests
<davexunit>and install using that
<redshelled>In the mean time, I have spare laptops, so I can just try it out on one of the others until maybe something fixes that.
<davexunit>I have one last idea
<davexunit>redshelled: guix pull --url=
<davexunit>this should build a custom version of guix I made that disables the test suite for that guix package
<davexunit>then you should be able to install the system
<redshelled>davexunit, its pulling now
<davexunit>if this doesn't work then I give up for now
<redshelled>ill be back here in a few mins, gotta do something, the build is running now. Ill report back with results
<davexunit>sounds good
<NiAsterisk>rust's configure script sucks.
<lfam>Is it... rusty?
<lfam>ACTION groans
<NiAsterisk>I advanced a bit through failures, but now: configure: error: program '/gnu/store/p5qnqhas3bfg281q1xpwzszbbxpii51y-llvm-3.6.2/bin/FileCheck' is missing, please install it
<lfam>Hm, maybe that's a feature we should enable in our llvm package?
<NiAsterisk>if that's a llvm thing, yes
<NiAsterisk>I can give you full context with the current .scm and log
<lfam>Well, the error message says that it's missing from the llvm tree. Does that file exist anywhere in the llvm store directory?
<NiAsterisk>one moment
<lfam>I would look into the llvm source code and manual learn about it and how to build it
<lfam>So, what could cause a python package to retain references to all its native-inputs via the wrapper? Or is that expected?
<NiAsterisk>okay, I'm doing it. just had a short detour into linux from scratch with llvm and I just saw how incredible bporing lfs is, it's just like gentoo stage 1.. never looked into lfs.
<lfam>I've found it helpful when trying to build some tricky things. It seems like a good resource
<NiAsterisk>yes, but I always thought it was something other than a big manual, I had no expectations and never read into it. no idea what I expected..
<NiAsterisk>*documented manual
<lfam>Yeah, I was pleasantly surprised when I first started reading it. It pops up often when I am debugging build failures
<NiAsterisk>I think I might have looked at in '99 when I first looked at Gentoo and with a time limited, slow internet connection it was not pleasant to read into.. and now I have about 16 more years of experience with things.
<redshelled>davexunit, IT WORKED
<davexunit>redshelled: yay!
<redshelled>Thanks for all the help :D
<NiAsterisk>if this is docker, how is this fixing things when you still use apt-get and stuff.. I never used it, but looking at it... "why?".
<davexunit>NiAsterisk: it's "fixing" things by allowing each application to have an isolated environment in which to run, so that you don't have to worry about application A's dependencies clashing with application B.
<davexunit>and it works by using existing distribution tools to do the heavy lifting to create the necessary disk image
<NiAsterisk>I know how it basically works, but what if apt-get breaks. or some tool included in the disk image is 4 years outdated, nobody checks that
<davexunit>obviously, we know that there's a better way, but Docker is allowing people to do things that were more difficult to do prior.
<davexunit>NiAsterisk: exactly.
<davexunit>these are real issues.
<davexunit>which is why I do not like Docker.
<davexunit>it's not good for user autonomy and control.
<davexunit>it's good for developers to control how their software is run
<davexunit>they just ship a disk image with a mini-distro that can run their application!
<davexunit>ACTION shudders
<NiAsterisk>some do that with virtualbox and gentoo hardened based systems, the company sirrix for example.
<lfam>A disk image that is then never updated or patched
<davexunit>I'm (so far unsuccessfully) trying to demonstrate to others that with Guix we can do much better than Docker.
<lfam>It's interesting to see what aspect of Guix / Nix systems turns people on. Different things speak to different people
<davexunit>call-with-container trails behind Docker on important features like virtualized networking and cgroups to limit system resources.
<lfam>To me it was the basic idea of putting software in a content addressed store where each package is named for it's dependency graph. With that base, you can go in many different directions
<davexunit>but 'guix environment --container' was released with support for user namespaces *before* Docker did. ;)
<davexunit>lfam: yes, precisely.
<davexunit>it's amazing the things that can be built on top of that foundation.
<lfam>To others, it's the language (Scheme, or for some, Nix)
<NiAsterisk>I think originally I was drawn by GNUnet, and the maybe future feature to have a GNUnet oriented distribution for software updates. then it became hey, when I fix enough and add enough I can run servers again without being angry at them that much.
<davexunit>our container implementation has the luxury of being much simpler than Docker because we don't need the crazy disk image layering stuff that they do.
<davexunit>we just use the provided foundation: the immutable store
<lfam>I remember your announcement mentioned that angle, and it's true
<davexunit>tell guix which store items you want in your container and guix will prepare it for you.
<redshelled>Scheme brought me here. The only thing I was wondering about is the differences in scheme and nix. As far as I understand it, nix is lazier than scheme which may be an advantage
<davexunit>and on top of that, data is shared between *all* containers, system-wide.
<davexunit>that's much harder to do in Docker
<davexunit>but we get it for free in Guix.
<bavier>I was recently doing some personal web server work, and I was very much missing GuixSD; that I couldn't declare the system state was very frustrating
<davexunit>containers whose dependency graphs overlap aren't duplicated.
<davexunit>bavier: yup, I miss it every day at $dayjob.
<lfam>redshelled: The fact that Scheme code is data is hugely powerful for us. I'm relatively new to Guix and Scheme, so I can't really take advantage of that, but it allows us to easily do a lot of stuff that would otherwise require hacks like scraping and parsing our own package recipes.
<rain1>I think guix will win, it is the best :)
<davexunit>it's nice that we can write code that the build daemon will run by simply quoting the expression
<davexunit>(+ 1 2 3)
<bavier>I'm kinda scared that my now-special-snowflake will break and I won't be able to get it back
<davexunit>I want the daemon to run that
<davexunit>'(1 2 3)
<redshelled>lfam, thats very true. I also appreciate the fact that there are many tools for guile and scheme already.
<davexunit>'(+ 1 2 3)
<redshelled>nix is very niche
<NiAsterisk>I hope to arrive at the point where I can configure and setup a gnunet node through the system file and have it on a dedicated headless server.
<lfam>bavier: I know what you mean. I'm spoiled by Guix
<lfam>I already hated having to document my snowflakes, but it's a different feeling when you have used something better
<bavier>lfam: yup
<davexunit>we're getting closer to being able to handle web server type use-cases.
<redshelled>plus scheme is pretty common to teach at universities
<davexunit>not quite there yet, but getting there.
<lfam>davexunit: What do you think we're missing?
<redshelled>and a good intro to functional programming or so ive been told
<lfam>Besides a letsencrypt package ;)
<lfam>I mean "service"!
<davexunit>lfam: zero downtime web server upgrades is one thing
<NiAsterisk>redshelled: what? where? I only see js, java, c,..
<NiAsterisk>lisp was big here in the 80s
<davexunit>lfam: nginx has the ability to be upgraded without downtime, but so far shepherd isn't smart enough to handle it yet.
<lfam>davexunit: So, better service restarting within shepherd? Does the nginx shepherd service implement reloading yet?
<NiAsterisk>then something happened and we are at Java everywhere
<lfam>Ah ;)
***Dezponia_ is now known as Dezponia
<davexunit>lfam: no reloading yet, that's step 1.
<redshelled>NiAsterisk: many big universities teach it in the US
<davexunit>then step 2 is handling the nginx binary being upgraded as well.
<redshelled>ill find an example :)
<lfam>I hadn't thought of that
<davexunit>need more services in general
<davexunit>that kind of stuff
<NiAsterisk>interesting. where I looked (germany) at universities of applied science it was more or less what I mentioned plus some extensions to this
<lfam>Yeah, I need to take a break from packaging and learn to write a service that does more than just execute a binary
<lfam>We need more services
<davexunit>mysql/mariadb service needed
<davexunit>all sorts of stuff :)
<davexunit>but we're set up for some really nice features
<redshelled>NiAsterisk: UCLA, Brown, Michigan, and MIT I think all have some type of scheme classes
<davexunit>for example, I wrote a patch that allows the nginx-service to be extended with additional config files
<NiAsterisk>I want to package rust and then do rust cargo imports, after that one of the bigger tasks for this year is done, then I can write services I wanted to do and afterwards I can do Torbrowser :)
<lfam>I could start submitting "stub" services that just execute a binary, for software that can be configured completely from a text file. At least they would provide run-on-boot
<NiAsterisk>redshelled: cool
<lfam>I'd *love* to see a presentation on services from one of the more experienced Guix developers
<lfam>The written documentation is as dense as I am ;)
<NiAsterisk>redshelled: I invst more time into this than I thought... I have a todo list stretching about 12 months for Guix alone I think, but I had the plan to learn C++, Guile and Lisp this year. this is shared time between a project where I would like to contribute code
<NiAsterisk>well I am learning a subset of Guile with Guix.
<redshelled>NiAsterisk: thats quite a 12 month plan. I just started with guix like two days ago and I may add lisp or guile for guixsd afer I get done with scala
<redshelled>Dont hate me for the java connection L)
<NiAsterisk>what do you mean? there's guile and lisp in Guix already
<redshelled>NiAsterisk: I mean personally learning so I can contribute
<rain1>guix has icedtea as well, can run java
<NiAsterisk>redshelled: ah, I see
<redshelled>rain1: that is good to know! I notice how much hate java gets in general in the oss community but i really enjoy scala
<rain1>scala is pretty cool
<NiAsterisk>i consider learning more webdevelopment and java, so eventually if I decide that I want to study it'll be usefull, or if I don't get a job elsewhere I can do freelance webdev work.. anything to just get a start again.
<lfam>Yeah, we have some new java stuff, too, like an ant-build-system to abstract the build process for software that uses Ant
<redshelled>NiAsterisk: it appears that java will be around for a while, and its pretty well respected in corporate environments if thats your thing. I imagine a java programmer wouldnt struggle too terribly for work
<redshelled>webdev is always good too
<NiAsterisk>yeah. my other perspectives are try to get into IT Sec. somehow (could've recently, but I'm not ready for fulltime stress again) or just work whatever I find part time and have enough time for the other projects around GNUnet.
<rain1>is GNU net packaged andworking on guixsd?
<NiAsterisk>be welcome to test and add a comment for gnunet-svn on the devel list
<NiAsterisk>gnunet-0.10.1 is available, but (described in the threads i opened in the last time) it is old.
<lfam>Indeed, it's great when people try patches from the list! We need more people to do that :)
<NiAsterisk>I also have no idea if it's just due to 6 people having commit access, or me threading emails in a funny way and no more CC that patches I send sometimes only get accidental attention.
<NiAsterisk>not that I want to be pushy, it's just that -devel gets more and more emails per month
<rain1>I have to set up my guixsd system a little differently to test this
<lfam>NiAsterisk: It's true, things fall through the cracks. The best thing to do if nobody responds to your patch is to try again
<lfam>I'm one of the less experienced reviewers, so there are some things I'm not qualified to review. And still, I have a long list of emails to read!
<rain1>is there a guide to follow? For patching against the guix packages
<NiAsterisk>but isn't that confusing? should we, if infrastructure allows it, have a patches only list?
<rain1>not applying patch, but having guix point to an editable repo
<lfam>NiAsterisk: Is there any patch in particular you'd like to go over now, on IRC? Sometimes it's easier when the communication is faster than email
<lfam>rain1: Can you clarify what you mean?
<rain1>sorry I didn't explain it well
<rain1>export GUIX_PACKAGE_PATH=/home/rain/Code/repos/pkgs/
<rain1>this is what I have now
<NiAsterisk>no, I'm just waiting for ludovic to review my reply on the gnunet.scm patch set, but that's all iirc. nothing which needs to be rushed.
<lfam>NiAsterisk: Maybe it's confusing, maybe not. But "the squeeky wheel gets the grease"
<rain1>but I would like to help test gnunet svn so I should git clone guix and point to there instead? (and patch there)
<lfam>rain1: So, GUIX_PACKAGE_PATH is for your private package collection, but you can also have the full Guix git repo and work out of that
<NiAsterisk>i mean, I did test gnunet-svn, -gtk-svn and 2 more people. I also added a bug which needs people to participate with results to narrow down the issues
<rain1>or do I edit ~/.config/guix/latest/ ?
<lfam>I do all 3 on my Debian system: Guix installed from the binary tarball, working out of git, and a private package tree
<NiAsterisk>the only "issue" is that under certain environments, gnunet-fs stays black
<lfam>rain1: You can do that, or you can just configure Guix from git and then use the ./pre-inst-env file that results
<lfam>Some users *only* use Guix from a git repo. They never do `make install` or the binary tarball
<lfam>It's very flexible
<lfam>If you want to contribute patches, you should have a copy of the Guix git repo that you can use. Whether or not you do everything from that repo is up to you
<lfam>NiAsterisk: Can we talk about powwow? So, the issue is that the program works fine, but it's not really suitable as a chat client by default?
<rain1>actually I am failing to apply the patch
<rain1>patch -p0 < gnunet.patch, patch -p1 < gnunet.patch does not work
<lfam>Perhaps the context has changed since the patch was generated?
<NiAsterisk>nobody worked on gnunet.scm afaik.
<rain1>could it be because of address@hidden ?
<rain1>well if you can post the file instead of patch i could test it
<NiAsterisk>lfam, yes. longer reply in progress here.
<NiAsterisk>sure. did my reply not come through? What I tried to further explain was: initially I had the assumption that powwow at the * location was not patched and the CMDSEP was changed from ; to § (legal) in a config file. When I realized it wasn't I started a powwow-chat.scm which will not be in the master tree ever and can be obtained elsewhere. powwow is a client which can be used to access chat servers
<NiAsterisk>like, but when you write sentences every ; breaks the line
<lfam>Right, I think I understand that. So, your question is regarding what should go in the description?
<NiAsterisk>that's why I removed the referencing lines. I can however send in a patch which adds a better explanation.
<lfam>Yes, can you send a fresh patch?
<NiAsterisk>yes, I see if I can do it this weekend.
<lfam>Okay, thanks!
<rain1> I'm supposed to copy this and paste it into a gnunet.patch file, correct?
<NiAsterisk>if you want to, does not alter the attachments
<NiAsterisk>all the emails etc there
<NiAsterisk>how you apply it, i don't know. it fixes gnunet description, fixes gnunet-gtk configure, fixes one other package, adds gnunet-svn, adds gnunet-gtk-svn
<NiAsterisk>I had no idea how to separate
<rain1>ok this sounds too hard
<NiAsterisk>well it's just all in one file
<rain1>if the file exists somewhere I could get that - like a fork of the guix repo?
<NiAsterisk>currently I have no web accessible version of this. I could upload the patch again, not rebased against current master, but the master it was based on
<rain1>oh it's okay
<NiAsterisk>is this what you mean, having the .patch in a downloadable location?
<rain1>.scm would be even easier
<NiAsterisk>I deleted the branch already
<rain1>I'll just wait then
<myglc2>Anyone know why cloning (using dd) the GuixSD HD works to a HD but not a SSD?
<myglc2>I get waiting for partition "b1sd" to appear (repeats)
<myglc2>ERROR: in procedure scm-error
<myglc2>ERROR: failed to resolve partition "g1sd"
<lfam>myglc2: What command line are you running when you get that error?
<NiAsterisk>lfam: some days ago rust had a commit which fixed their bug described here: so if I package a recent rust (or wait) this might solve llvm. but I need a break and look at it again, just read throught it.
<NiAsterisk>meaingin, maybe we don't need to alter llvm
<NiAsterisk>ACTION afk
<myglc2>lfam: Rebooting. The GuixSD welcome screen comes on the SSD and then the OS starts loading and then I get the above mentioned errors
<lfam>Okay, is that related to `dd`?
<myglc2>I do dd to clone the HD to SSD, then I pull out the HD and try to boot, then I get the above.
<rain1>maybe the device numbers changed
<myglc2>DUH! Of couse, the HD clone comes up /dev/sda but the SSD /dev/nvme0n1
<lfam>Cool, I hope that it works now!
<myglc2>OK how do I tell Guix to run from the different disk?
<myglc2>I guess I could reconfigure the system now?
<myglc2>Run on the HD and reconfig to point it at the SSD and then It will come up running on the SSD clone?
<lfam>I haven't done this yet, but I assume you'd alter either the 'bootloader' or 'file-systems' fields in your OS configuration
<lfam>Or both, I'm not sure
<myglc2>That sounds right, I'll try it!! Thanks!!!
<lfam>Okay good luck!
<myglc2>lfam & rain1: re clone to SSD & reboot, no dice. I changed 'bootloader' to point to SSD: '(device "/dev/nvme0n1")' and rebooted but we don't find the root partition on the SSD, which was created with 'mkfs.ext4 -L g1sd /dev/sda1' and mounted with '(device "g1sd")'.
<myglc2>Ahem, I did guix system reconfigure and then rebooted
<rain1>I've never tried labels
<myglc2>Recommended by the doc :)
<myglc2>But me neither until now.
<myglc2>So maybe I try no label
<civodul>myglc2: /dev/mvme0n1?
<civodul>non-volatile memory?
<davexunit>civodul: hey! today I used Guix containers to assist in making a Ruby development environment
<davexunit>shared it earlier but I'm sharing it again ;)
<davexunit>in case you didn't see
<civodul>davexunit: neat!
<civodul>that was for work, i guess?
<davexunit>it's a rather nice half-way solution since I counted 178 ruby gem dependencies and don't have time to package all of that.
<davexunit>civodul: yeah
<davexunit>I can tell you that it's way easier than making a Docker container!
<civodul>i can imagine, for relatively simple cases like this at least
<davexunit>yeah, plenty more to do, but I'm a happy camper. :)
<civodul>one thing i don't understand: the lines after "openssl" are not executed in the environment, right?
<davexunit>civodul: they are. this isn't a proper bash script that you can run.
<davexunit>it's just a dump of what I did
<davexunit>everything after 'guix environment' is run in the sub-shell
<civodul>ah ok, got it
<davexunit>guess I should have prefixed each line with "$ " to show that it's not a script
<civodul>would be nice to use 'guix environment' as the shebang, somehow
<davexunit>nix-shell does this
<davexunit>but I haven't seen an example that doesn't do /usr/bin/env nix-shell
<civodul>we could use a fancy binfmt_misc hack!
<lfam>Some recent update broke khal :(
<davexunit>civodul: I am completely ignorant of binfmt_misc :(
<civodul>it's just a way to extend the kernel's shebang handling
<civodul>lfam: oh, how?
<davexunit>civodul: I'd love one that extends the maximum shebang length ;)
<davexunit>every time I think about the shebang length limit I get mad.
<civodul>oh, that's 22nd century-ish
<myglc2>civodul: /dev/mvme0 = Samsung 'SSD 950 PRO NVMe' plugged into an adapter in PCIe slot = ~4x faster than SATA partly because Linux Kernal supports alternate (NVMe) access mechanism with 'mvme' prefix instead of 'sd'
<lfam>A test started failing. I'm going to try to find the change "by hand" since bisecting back to mid-January will be so expensive!
<civodul>davexunit: for now, 127 bytes "should be enough for everyone"
<civodul>myglc2: interesting
<civodul>lfam: could it be that the test is non deterministic?
<davexunit>civodul: :)
<lfam>civodul: I wish! I ran it several times
<myglc2>civodul: I had the SSD it in my Debian server RAIDed with 2 HDs & set read preferrentially from the SSD. That is where I want to go on GuixSD now.
<davexunit>now that I have a more-or-less working GNOME, I really feel like I'm using a "real distro"
<lfam>khal's failing assertion:
<lfam>E assert ('VCALENDAR',...set([]))]))])) == ('VCALENDAR', ...set([]))]))]))
<davexunit>that's a lot of parens, even for me.
<myglc2>civodul: for now I am just trying to run from the SSD w/o RAID.
<lfam>I assert those strings are the same!
<lfam>Oh, there is a space after the comma in the second string
<lfam>Of course, all the "likely suspects" in the commit history are my own commits ;)
<lfam>Wow, the sheer volume of commits...
<chewieQC>Does guix support projects written in Go?
<bavier>chewieQC: someone has been working on a gcc-go package
<bavier>but it's not finished yet
<chewieQC>Bavier: Nice! Is it coming along nicely?
<bavier>I don't recall the latest status