IRC channel logs


back to list of logs

<paroneayea>ACTION writes a guile-bleeding-edge package
***necronian_ is now known as necronian
<yrns>Just installed guix on Arch. If I try to install anything it kills X and punts me back to login.
<yrns>As root it works, though.
<davexunit>yrns: any error log or other information you can get about this would be very helpful
<davexunit>I don't know why that would happen
<yrns>No error message in the output, except for the locale warnings. I'm trying to install glibc-locales.
<davexunit>strace could help get a log of the system calls
<davexunit>perhaps we'd see the one that causes the crash
<yrns>I tried strace and it was cut off at the end. I'll try again.
<davexunit>at the very least, you can write to to report the issue and any details you can think to give
<mark_weaver>yrns: it sounds like you added your normal user to the 'guix-builder' group. is that right?
<yrns>I don't remember doing that, but yes.
<davexunit>oh. this sounds familiar now.
<yrns>That's bad?
<mark_weaver>yrns: here's what happens: any user in that group is a user that guix-daemon is allowed to use to do builds. so, in this case, it chose your user
<mark_weaver>then, when the build is done, guix-daemon kills every process owned by that user, to make sure everything is cleaned up
<yrns>Definitely bad. Thanks for the explanation.
<yrns>So for Arch/systemd I have to install glibc-locales as root and set LOCPATH in the service file to avoid the locale warnings?
<yrns>I'm trying to write a package file for Guix on Arch, so that I don't have to write any more package files for Arch...
<davexunit>yrns: that sounds correct
<mark_weaver>yrns: the warnings are harmless, but indeed you can silence them by setting LOCPATH in the systemd service file
<mark_weaver>however, that raises two complications: (1) how and when will the locales package be updated
<mark_weaver>and (2) if the LOCPATH you set points directly into /gnu/store/*, then you need to add a symlink to /var/guix/gcroots/ to prevent it from being deleted by the garbage collector
<yrns>Do I need the symlink if locales are installed as root?
<yrns>I see I have another, similar problem which is editing the service file.
<mark_weaver>yrns: anything that's part of a user profile is automatically protected from GC
<mark_weaver>(because of the /var/guix/gcroots/profiles symlink)
<mark_weaver>so, if you arrange for the locales to be installed in root's profile, and then set LOCPATH to ~root/.guix-profile/... then it should all be good
<mark_weaver>that's probably the best approach
<yrns>Got it. If I set LOCPATH for root, I'm not sure that propagates to the systemd environment, without editing the service file.
<yrns>Ahh, I just discovered 'systemctl set-environment'.
<mark_weaver>yrns: there's a field that you can add to the systemd service file itself
<mark_weaver>someone did it recently, and told us about it
***tschwing_ is now known as tschwinge
<abuela>anyone awake?
<abuela>thought so. I should sleep
<civodul>Hello Guix!
<C-Keen>hi folks! I have installed the guix binary on top of a debian system and followed the installation instructions. However I get a "warning: failed to install locale: Invalid argument" upon guix invocation. What's missing?
<civodul>C-Keen: most likely you need to install locale data, as described at
<C-Keen>civodul: thanks I will have a look
<C-Keen>civodul: yeah that helped, thanks!
<C-Keen>I gues this means I will have to have a closer look at guile again :)
<civodul>good :-)
<Steap>Do we have a complete description of how Guix works that could be copied/pasted in a blog article ?
<Steap>ACTION doesn't feel like writing the whole thing :D
<Steap>oh, dthompson copied a few paragraphs in his own article
<civodul>there's also and
<civodul>and the "About" part at for something shorter
<karhunguixi>Hi. I've installed Hexchat and Icecat and find them both missing from the XFCE applications list [Internet]. What is the proper way of adding them there?
<davexunit>karhunguixi: need more information. how were they installed?
<karhunguixi>guix package -i
<davexunit>so to your user profile, ok.
<davexunit>icecat doesn't show up in that menu for me either.
<davexunit>it's likely missing the relevant .desktop file
<karhunguixi>i'm thinking maybe there should be something in the package definition
<civodul>davexunit: is there a search path for those .desktop files?
<davexunit>civodul: share/applications
<davexunit>find ~/.guix-profile -name "*.desktop" -follow
<civodul>ok but is there an env. var that Xfce honors?
<davexunit>that I don't know.
<davexunit>desktop environments aren't my forte.
<civodul>yeah me neither :-)
<civodul>sneek: seen iyzsong
<sneek>I last saw iyzsong on Sep 13 at 10:45 am UTC, saying: I update libtasn1 to 4.6 in 'core-updates', but it break a test of gnutls, with a report email sent to the gnutls and libtasn1 ML. If the full build of 'core-updates' start, I'll stop doing push packages updates, and better revert the libtasn1 update right?.
<davexunit>all I know is that the way we have xfce configured, it already looks in our profile for these things
<davexunit>maybe it's XDG_DATA_DIRS ?
<civodul>karhunguixi: are you on GuixSD or on some other distro?
<karhunguixi>GuixSD (fully encrypted ;))
<civodul>aah right!
<civodul>karhunguixi: speaking of which, could you post the changes you made on the mailing list?
<civodul>we need to integrate it :-)
<civodul>oh, right in time
<civodul>hey iyzsong :-)
<civodul>iyzsong: karhunguixi was mentioning that apps installed in the user profile wouldn't show up in the Xfce menu
<iyzsong>civodul: assuming the app does have $out/share/application/*.desktop, maybe a restart of xfce4-panel is needed (or logout).
<davexunit>iyzsong: in this case, icecat doesn't have a .desktop file
<davexunit>I guess we need to add a patch
<karhunguixi>to get full encryption i used: and (i'll send to mailing list as well)
<civodul>sending to the ML is a good idea :-)
<karhunguixi>i was thinking maybe you could add those modules always, so you don't need them in your config, what do you think about that?
<karhunguixi>dm-crypt.ko and xts.ko
<iyzsong>karhunguixi: cool! yes, I think it's a good idea.
<civodul>yes, maybe
<bavier1>I was investigating the GHC runpath question a bit. I think we can give our ghc package a GHC_PACKAGE_PATH native-search-path, tweak the haskell-build-system just a bit, and then we could work with haskell packages without any input propagation
<bavier1>I think we just need to get search-path-specification's 'file-pattern' to work on directory names
<civodul>sounds nice
<civodul>ISTR effa said there were issues with simply using GHC_PACKAGE_PATH, but maybe what you have in mind addresses those
<bavier1>civodul: I might want to find/hear effa's concerns again, just to be sure they are addressed
<bavier1>they had to do with cabal's insistence that GHC_PACKAGE_PATH is unset during package configuration
<bavier1>but it appears to me that that is the only time cabal complains, so we can simply unset it during that phase
<civodul>and those discussions were before we added the GHC profile hook
<bavier1>civodul: ok, I think those issues are addressed with what I've done so far
<bavier1>I just need to look at search-path-as-list for directory name patterns
<civodul>i think it's just (search-path (file-type 'directory) ...)
<bavier1>but it will also need to find some symlinks, if the directories are symlinked in the profile
<bavier1>or do we abstract away?
<civodul>bavier1: it depends on whether it uses stat or lstat
<civodul>i think it uses the former
<civodul>right, search-path-as-list uses stat, so it won't distinguish between symlinks-to-dirs and actual directories
<bavier1>civodul: but search-path-as-list uses find-files' default argument for stat, which is lstat
<bavier1>when a pattern is used
<bavier1>so maybe just doing (find-files file pattern #:stat stat) is enough
<civodul>yes but it's not a pattern here, is it?
<civodul>you're looking for directories with a specific name, no?
<bavier1>civodul: no, I'll need a pattern on the directory name
<civodul>like what?
<bavier1>to address the binary cache collision issue
<civodul>then we're screwed
<bavier1>under the "lib/ghc-7.8.4" directory
<civodul>directories are call lib/ghc-7.8.4/foo.conf.d and lib/ghc-7.8.4/bar.conf.d?
<bavier1>that's my proposal at least
<civodul>ah ok
<civodul>well i guess i don't know the situation well enough
<civodul>what's sure is that search-path-as-list uses 'stat' for patterns, as you noticed
<civodul>we could change that, but you'd have to wait for the next cycle
<civodul>i don't know if this is really a problem, even
<civodul>maybe you should mail the list + Fede?
<bavier1>aha, got it to work
<civodul>and/or give it a try
<civodul>great :-)
<civodul>ACTION goes afk for a bit
<bavier1>I'll clean up and send a patch later
<davexunit>my Chef scripts contain an ad hoc, informally-specified, bug-ridden, slow implementation of half of Guix.
<davexunit>I just got bit hard by a Chef script that tries to avoid rebuilding software when it doesn't have to.
<davexunit>and I just ran into a case where it should have been rebuilt, but wasn't, and left the server broken and sounded the alarms.
<davexunit>such a thing would have never happened with guix, and I also wouldn't be compiling software from source on production VMs.
<bavier>davexunit: I also have such a script for in-house software builds
<bavier>it's working well so far, but the lack of rigor is bothersome to me
<civodul>sounds like davexunit's 10th rule
<zacts>hello guix
<paroneayea>:D davexunit's 10th rule
<paroneayea>I do feel like things are converging on a guix-like direction
<paroneayea>and I say guix-like rather than nix-like because scriptability in a nice language is important
<davexunit>much like programming languages converge on lisp
<paroneayea>java just got lambdas and streams...
<davexunit>despite not being lisp and missing many crucial features that make me want to pull my hair out
<paroneayea>(GOOD-ENOUGH? language)
<paroneayea>my brother and I were watching the SICP lectures
<davexunit>they are so great.
<paroneayea>and they had the GOOD-ENOUGH? thing
<paroneayea>and he said
<paroneayea>"GOOD-ENOUGH? QE-effing-D!"
<paroneayea>I thought it was really funny, in the moment at least
<davexunit>ah yes that was the square root procedure, right?
<davexunit>newton's method
<paroneayea>GOOD-ENOUGH? has become a local meme here now
<davexunit>I like it :)
<civodul>ACTION fixes imagemagick in core-updates
<civodul>the code is pretty horrid
<paroneayea>I wrote a guile-bleeding-edge package last night
<davexunit>ooh :)
<paroneayea>maybe I should update guile-for-guile-emacs to be based on it (they share a lot of stuff) and then push a patch
<paroneayea>sounds like I'm not the only guix community member who wants a way to easily test their software with the latest guile then? :)
<paroneayea>I'll get it into patch format and submit to the list
<davexunit>I'd like to use it for Sly
<paroneayea>davexunit: cool
<civodul>i guess it would be very beneficial for Guix
<civodul>but it also needs more testing
<paroneayea>civodul: guile's master?
<paroneayea>civodul: seems like a good reason to package it then!
<paroneayea>I think the package name guile-bleeding-edge lets you know what you'r ein for
<paroneayea>*you're in
<civodul>we could simply call it "guile", but the risk is that 'guix package -i guile' would take it instead of 2.0, possibly leading to confusion
<paroneayea>civodul: yeah best not risk it. I think a different package name is useful. Makes making use of it very explicit
<davexunit>guile-next maybe
<civodul>yes, sounds good
<paroneayea>ok, can rename to that
***exio4 is now known as exio
***exio is now known as exio4
<efraim>I'm packaging owncloud and dependency now, and, other than the version number, i found a bug report against qtkeychain that is identical to the error I ran up against
<davexunit>efraim: owncloud client I guess?
<davexunit>we still need php for the server
<davexunit>php is a real pain last I tried
<efraim>yeah owncloud-client is what i meant
<davexunit>ah okay
<bavier>efraim: neat, I've been wanting that package
<efraim>after owncloud-client, almost every program i regularly use should be packaged
<efraim>i think that leaves tilda and git-annex
<efraim>and git-annex is a beast
<bavier>efraim: I've almost got git-annex working
<bavier>all package dependencies are in place (~150 ghc-* packages)
<bavier>the git-annex configure phase is getting stuck though
<bavier>in the mean time, you can use the 'cabal-install' package to install git-annex locally
<bavier>davexunit: I seem to pick the packages with massive dependency sets
<efraim>oh and quassel. i haven't looked at building it yet, but in debian its split monolithic, server and client
<davexunit>I'll say...
<efraim> is the official NixOS repository?
<davexunit>efraim: yes
<davexunit>well the official repo for packages
<efraim>i'm always suprised when I see github as the main hosting location for a distro
<efraim>anyone know offhand the cmake flag for QT_TRANSLATIONS_DIR
<mthl>efraim: I hope you will never get used to it :)
<efraim>i told my wife that this would be easier if people understood that english is the master language
<efraim>and stopped translating things :)
<efraim>I tried to just toss a setenv in there, but it looks like I'll need the whole alist-replace thing to toss in the options
<paroneayea>civodul: so, the first time I built this package I accidentally had tests disabled since I accidentally borrowed that from guile-for-guile-emacs
<paroneayea>it turns out tests don't work anyway!
<paroneayea>civodul: are we okay with having guile-next lack tests in guix?
<paroneayea>we were for guile-for-guile-emacs
<paroneayea>so maybe, since this is also bleeding edge
***davi_ is now known as Guest79295
<civodul>paroneayea: that's ok
<paroneayea>civodul: ok cool
<paroneayea>ACTION verifying that guile-for-guile-emacs builds now too and then will post the patch to the list
<davexunit>guix: homoiconic devops
<paroneayea>guix package -i accept --no-substitutes #vaguejokes
<civodul>"isomorphic full-stack devops" vs. "homoiconic devops""
<civodul>do people understand each other? :-)
<civodul>paroneayea: what's up with ?
<civodul>still no announcement it seems
<paroneayea>civodul: from this morning:
<paroneayea>oh well I won't paste conversations from a private channel exactly, but :)
<C-Keen>what's the preferred way to get patches for package updates?
<paroneayea>summary is that one of the group organizers is going to get it on the site, hasn't gotten to yet, is waiting to send out the email first
<paroneayea>is waiting to send out the email till has it first
<paroneayea>civodul: sorry for the delays! Out of my hands though.
<civodul>np, i was wondering if i had missed something!
<civodul>C-Keen: basically send'em to the mailing list, see
<C-Keen>alright, will do
<davexunit>it took until now for me to look up if there's a Boston LUG
<davexunit>of course there is, and they're even metting tonight, but I have band practice so I can't go.
<davexunit>I guess next month I'll try.
<paroneayea>I have a fondness for free software usergroups
<paroneayea>the chicago python usergroup in particular is where I exercised most of my comfort zone stretching as in terms of giving technical talks
<paroneayea>always a great place to learn, too
<davexunit>yeah I need to get involved
<davexunit>they are having a keysigning party tonight.
<davexunit>I normally don't have practice today, but we moved it this week. damn it.
<paroneayea>davexunit: there's always next month :)
<davexunit>just a bummer. I feel like going to MIT Press to get The Little Prover finally and then going to the meetup.
<civodul>yay for MIT Press
<civodul>i'll have to order it right from Boston it seems
<civodul>mark_weaver: re pixman,
<civodul>i failed to actually fix it
<mark_weaver>civodul: okay, thanks for investigating and filing the bug report!
<civodul>mark_weaver: obviously, i found a fix right after submitting it :-)
<civodul>i'm testing it now
<mark_weaver>ah, excellent! :)
<mark_weaver>imagemagick failed on x86_64. that's the next problem.
<civodul>just pushed a fix
<civodul>for imagemagick
<mark_weaver>oooh, nice!
<civodul>grr the pixmap thing is not fully baked
<civodul>it makes Valgrind happy but still segfaults in the chroot
<karhunguixi>civodul, i sent an e-mail to earlier, but it doesn't show up on the archive page. Do you know anything about this?
<civodul>karhunguixi: if it's your first message, there's a delay of a few hours before the message reaches the list
<civodul>and then the archive itself is updated periodically
<civodul>mark_weaver: well, i posted the half-baked workaround at if you want to investigate further
<goglosh>anyone here installed guixsd?
<rekado>re imagemagick: can be used as a drop-in replacement?
<goglosh>I tried that yesterday but I had a dumb error
<goglosh>it stopped when it couldn't find /etc/resolv.conf
<karhunguixi>goglosh, did you do "ifconfig enp0s25 up" and "dhclient enp0s25"?
<goglosh>oh that's one thing
<goglosh>I don't have ethernet access as of now
<goglosh>I connected wireless
<goglosh>anyway I am not a gnulinux veteran, I was only following instructions. I was just doing a test install check if it worked
<karhunguixi>yeah, i used wired and it was fine.
<goglosh>I was thinking of maybe taking the resolv.conf from my manjaro
<goglosh>but maybe I can save an extra trip if I take other files I might need.
<goglosh>or maybe I should read something that actually teaches me what I'd be doing rather than just follow steps, check the source, idk
***root` is now known as Guest72426
<karhunguixi>I'd take the knowlegde route ;)
<Guest72426>I have just installed guixsd
<goglosh>and you guys know it feels weird to just run a script and not really know what you're doing, so I would appreciate some advice, references, you know what I mean
<goglosh>Guest72426: you used a wired connection for that?
<karhunguixi>maybe someone else will assist you if you hang around a bit
<goglosh>know what I'll boot up the usb and login from somwhere else
<Guest72426>goglosh: I used lan
<rekado>goglosh: for all my machines I used a wired connection. (My laptops don't have functional wireless cards.)
<civodul>rekado: i never fully understood the deal with GraphicsMagick vs ImageMagick
<zwets>Question from a newbie: I have installed guix 0.8.3 from binary according to the steps in the manual. Root has its guix-profile set up and all works fine. Now to set up guix in my regular user account, I expected this would do the trick: ~root/.guix-profile/bin/guix package -i guix. However this installs guix- Why doesn't it link to the 0.8.3 which is installed for root?
<davexunit>zwets: guix 0.8.3 can't possibly know the hash of itself.
<davexunit>so that 0.8.2 version is a snapshot just prior to the 0.8.3 release
<davexunit>to get the latest version of the guix master branch, you can run 'guix pull'
<davexunit>which will compile guix
<davexunit>rekado: awesome job with those 11 new ruby gems :)
<davexunit>I have yet to review them
<keverets>is it usual to do "guix pull" after an initial install?
<davexunit>rekado: but I'm excited to see so many ruby libraries being added. :)
<davexunit>keverets: pretty normal, yeah.
<davexunit>but not required unless there's a bug fix or package update that you need.
<davexunit>rekado: I did just look at the FFI patch because I'm personally interested in that one. I think it's okay to enable the tests and do the redundant compilation. there's no way to fix that AFAIK.
<rekado>davexunit: but we already have a libffi package.
<rekado>nowhere else in the ruby-ffi package do I have to compile this.
<rekado>just for the tests.
<davexunit>oh wait it bundles libffi?
<davexunit>I thought you were talking the native extension
<rekado>erm... it's been a while.
<rekado>but I think it did try to build libffi.
<rekado>I can check again tomorrow.
<davexunit>yeah, it does.
<davexunit>but it must do the same thing when running 'gem install', no?
<davexunit>so even with tests enabled, the bundled library is being used.
<goglosh>okaay I partitioned my hard drive, now I guess I should label, or actually make the filesystems
<goglosh>...right? I remember last time I did mk2efs on /dev/sda3 (my root partition)
<rekado>davexunit: dunno. I honestly don't remember. These patches had already collected some dust when I decided to submit them. Must check again tomorrow.
<rekado>goglosh: you can do mkfs.ext4 -L the-label /dev/the-device
<davexunit>rekado: ok, no worries. just curious. :)
<goglosh>rekado: now I remember that for some reason mkfs didnt work
<goglosh>anyway, should I do this to /boot and /home as well? also what about SWAP?
<goglosh>okay did it, except for swap, what should I do with that one?
<karhunguixi>i think you just mark a partition as swap
<goglosh>i used mkswap
<goglosh>time to setup the config.scm
<karhunguixi>are you aware of the two examples in /etc/configuration?
<goglosh>yes I'm using the desktop one
<zwets>davexunit: thanks! It makes sense that guix 0.8.3 can't know the hash of itself. However, when I run as root: guix package --list-installed, this gives "guix 0.8.3 out /gnu/store/85nyj4lz480mxaj5szffli3c1k2rbhfn-guix-0.8.3"
<paroneayea>guile-next submitted to guix
<goglosh>(bootloader (grub-configuration (device "/dev/sdX"))) should there go sda or sda1? (sda1 shall be my /boot)
<rekado>AFAIK this should be the disk, not the partition.
<ebrasca>can I install guixsd on lvm ?
<civodul>ebrasca: no, not yet
<ebrasca>civodul: ok + thx