***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 <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 bug-guix@gnu.org 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. <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... <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>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 <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>Environment="LOCPATH=/root/.guix-profile/lib/locale" ***tschwing_ is now known as tschwinge
<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? <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 :) <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 <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? <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>find ~/.guix-profile -name "*.desktop" -follow <civodul>ok but is there an env. var that Xfce honors? <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 <civodul>karhunguixi: are you on GuixSD or on some other distro? <civodul>karhunguixi: speaking of which, could you post the changes you made on the mailing list? <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 <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? <iyzsong>karhunguixi: cool! yes, I think it's a good idea. <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>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 <civodul>bavier1: it depends on whether it uses stat or lstat <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>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 <bavier1>to address the binary cache collision issue <civodul>directories are call lib/ghc-7.8.4/foo.conf.d and lib/ghc-7.8.4/bar.conf.d? <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>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 <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 <davexunit>despite not being lisp and missing many crucial features that make me want to pull my hair out <paroneayea>my brother and I were watching the SICP lectures <paroneayea>I thought it was really funny, in the moment at least <davexunit>ah yes that was the square root procedure, right? <civodul>ACTION fixes imagemagick in core-updates <paroneayea>I wrote a guile-bleeding-edge package last night <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 <civodul>i guess it would be very beneficial for Guix <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 <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 ***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 <efraim>yeah owncloud-client is what i meant <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 <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 <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>civodul: are we okay with having guile-next lack tests in guix? ***davi_ is now known as Guest79295
<paroneayea>ACTION verifying that guile-for-guile-emacs builds now too and then will post the patch to the list <paroneayea>guix package -i accept --no-substitutes #vaguejokes <civodul>"isomorphic full-stack devops" vs. "homoiconic devops"" <civodul>do people understand each other? :-) <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 chicagolug.org has it first <paroneayea>civodul: sorry for the delays! Out of my hands though. <civodul>np, i was wondering if i had missed something! <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. <paroneayea>the chicago python usergroup in particular is where I exercised most of my comfort zone stretching as in terms of giving technical talks <davexunit>I normally don't have practice today, but we moved it this week. damn it. <davexunit>just a bummer. I feel like going to MIT Press to get The Little Prover finally and then going to the meetup. <civodul>i'll have to order it right from Boston it seems <mark_weaver>civodul: okay, thanks for investigating and filing the bug report! <civodul>mark_weaver: obviously, i found a fix right after submitting it :-) <mark_weaver>imagemagick failed on x86_64. that's the next problem. <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 guix-devel@gnu.org 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 <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>I don't have ethernet access as of now <goglosh>anyway I am not a gnulinux veteran, I was only following instructions. I was just doing a test install check if it worked <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
<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 <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-0.8.2.72cd8ec. 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>rekado: awesome job with those 11 new ruby gems :) <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>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. <davexunit>I thought you were talking the native extension <rekado>but I think it did try to build libffi. <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 <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>are you aware of the two examples in /etc/configuration? <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" <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.