IRC channel logs

2017-01-16.log

back to list of logs

<adfeno>mekeor: Please check the manuals that came with your computer.
<cehteh>blow out the fanholes, be careful not to inhale the dust
<adfeno>They tell what beeps might be.
<mekeor>alright
<adfeno>You can perhaps also find the corresponding manuals online.
<cehteh>they rarely mention that, but you see an american megatrends bios .. may google for that
<cehteh> http://www.bios-info.de/4p92x846/amsignal.htm
<adfeno>The beeps are not fast, so pay attention: look for descriptions related to average beep interval, not fast.
<cehteh> http://www.bioscentral.com/beepcodes/amibeep.htm
<adfeno>Hm....
<adfeno>"POST" has passed tests...?
<cehteh>na that would be only one beep
<cehteh>thats common
<cehteh>i dont see anything which fits to you constant beeps
<adfeno>Problem iss... It's the only that fits the description.
<cehteh>just inspect the hardware carefully, how old is the machine?
<cehteh>like i saied, try be removing unnecessary stuff, reinsert anything pluggable (in case of oxidized contacts)
<mekeor>yeah, first of all i'll clean the dust
<mekeor>thanks friends <3
<cehteh>i had such problems with faulty setted rams
<adfeno>Hm....
<adfeno>Some other sites says that memory might be at fault.
<Apteryx>Hmm, if I modify the python-2.7 package in my git tree (and using guix from git), then doing "guix environment guix" tries to rebuild the modified python-2.7 package. Why is that?
<Apteryx>I wouldn't think guix depends on python-2.7.
<cehteh>yes memory would by my 2nd guess if its not dust
<cehteh>btw: http://www.corsair.com/de-de/vs4gsds800d2 anyone needs one of those?
<cehteh>reviving some old laptop with more memory
<Apteryx>Oh, just looked at "guix graph python@2", and guix does depend (indirectly) on python-2.7 because of graphviz... Interesting.
<Apteryx>Sorry, another question: how can I look at the build log of a previous build? Or from hydra directly?
<mekeor>omg, there was a big dust chunk in my fan. let's see if the beep is dead
<adfeno> Wooow! :)
<Apteryx>Ok, figured it out: one can go here: http://hydra.gnu.org/queue and search for a package name in the search box.
<ng0>Apteryx: local build logs are kept in not very friendly structured folders/files :) there's a logfile switch for guix build
<Apteryx>ng0: I know about guix build --log-file; but i've modified the package and running this command would just start compiling for an hour or so.
<ng0>they are kept by default, and the name is listed
<Apteryx>Is it possible to access the "previous" build log? I'd like to compare the two as it goes, without having to go online if possible.
<Apteryx>There's a log diff in the hydra interface which is nice for when both logs have already been generated, but I want the same thing locally ;)
<mekeor>the beep remains...
<ng0>Apteryx: https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01240.html so far only in emacs probably
<adfeno>Emacs! :)
<ng0>i have never run the emacs-guix interface though
<adfeno>Neither I
<Apteryx>I get along well with Emacs. Let me try this 'guix-build-log-mode'
<Apteryx>guix-build-log-mode is a log viewer for the build log.
<Apteryx>You can navigate between build phases, and toggle on and off their content (show/hide).
<Apteryx>And it has the usual keybindigs of the "compilation" mode of emacs to navigate from one error to the next.
<Apteryx>That's what I could get from its online help, at least.
<Apteryx>Have to relogin...
<ng0>something is funny about the python build system. I just packaged bandicoot, and 150/168 tests fail, but it's still positive.
<ng0>well the tests are optional
<ng0>"failure is always an option" was the title of the last anual conference in a hacker space here which for the first time didn't happen
<adfeno>ng0: One thing that was funny, which I have seen in some of our package recipes is that some modified phases ended with #t.
<ng0>why is that funny?
<adfeno>Because I always though that it would take the status of last command/procedure.
<ng0>"* this program is licensed under the GPL." uhhh.... what. GPL1,2,3?
<ng0> https://github.com/infodox/tsh-sctp/blob/master/tsh.c
<adfeno>ng0: My...
<ng0>I'll ask the author when I come to upstreaming it. one of my package paths is gathering pentest related software while things build and I'm not in the mood to read books
<ng0>there's this new blend of Archlinux, BlackArch, and they have a number of questionable license packages. I pointed out the ones they keep in their own profile, but the rest I'll encounter only when I package the software myself.
<ng0>well the questionable thing was no license at all, which they will fix very soon
<Somelauw>The binaries didn't include zsh completion, can I still find the files somewhere?
<Apteryx>Hm... I've built my python@2 binary with my changes to fix the search paths, now I just want to try it out.
<Apteryx>If I do `guix build python@2`, I get /gnu/store/aihap0b724vzbsy5534gclw62z6wk56m-python-2.7.12
<Somelauw>ok, i'll just download the whole source and delete everything afterwards
<Apteryx>Now if I do "guix package -i /gnu/store/aihap0b724vzbsy5534gclw62z6wk56m-python-2.7.12" it starts building boost??
<Apteryx>Seems like doing a "guix package -i" can trigger a rebuild of guix itself? (I'm running guix from the same git tree where I modified Python@2, one of its dependencies...)
<adfeno>Somelauw: Which files?
<adfeno>Apteryx: I don't use Guix from it's git tree, but that's llikely
<adfeno>I guess this is why they do bunch of modifications in almost one commit perhaps, to avoid making the build farms restart everything so frequently.
<Apteryx>adfeno: Do you use the pre-inst-env trick?
<ng0>Somelauw: that sounds wrong
<adfeno>Apteryx: Nope. I'm only aan average Guix user that happens to contribute patches over time.
<Apteryx>adfeno: Cool!
<ng0>Somelauw: after an initial guix pull (or the ./bootstrap, configure, make etc see documentation) they should be in etc/completion, that's just the source checkpout I have here. I don't use zsh
<ng0>and iirc the completion should be installed when you install zsh from guix
<ng0>at least I assume so
<ng0>don't take my word for it
<Apteryx>OK. I'll bite the bullet and let it build what it wants.
<Apteryx>It's gonna take forever. Last time it built boost, cmake, and a bunch of other giant things.
<ng0>is this an existing install?
<Somelauw>ng0: oh, i haven't done guix pull yet
<Somelauw>but i got no completion by default /etc/guix only contains a file 'acl'
<ng0>I left out the leading / for a reason
<ng0>it is in root of guix checkout/source , etc/completion/zsh
<ng0>which (haevn't looked at zsh recipe) should be installed by the zsh package
<Somelauw>i'm using guix on another distro, so i'm using the zsh from guix
<Somelauw>not*
<ng0>when you git clone the repository, or if you look in your local build of the guix sourcecode, you will find this: http://git.savannah.gnu.org/cgit/guix.git/tree/etc/completion/zsh
<lfam>ng0: It's a known bug that failing tests don't fail builds with the python-build-system
<ng0>yes
<ng0>I followed that side thread in one of the packages I've sent
<ng0>but sometimes they fail though
<ng0>I'm on packaging nyx
<ng0>and there I had to disable tests
<Apteryx>lfam: Isn't this fixed since the new python-build-system by Hartmut?
<lfam>Apteryx: That new build system fixed some other issues and introduced this bug. We are working on fixing test failures on the python-tests branch
<Apteryx>OK!
<lfam>Apteryx: See http://bugs.gnu.org/25177
<Apteryx>lfam: thanks
<Apteryx>Can I make guix more verbose about what it's building and whyÉ
<Apteryx>?
<Apteryx>It failed building serf package.
<Apteryx>Oh, nevermind. My patch for Python has a bug.
<ng0>:O I finally got a tarball in the run of packaging palemoon. that's 80% done, now unpackaging and unbundling are the next steps.
<ng0>the end result of the build is a tarball
<chipb>heya. I'm bootstrapping a guix installation into a non-standard path (so I can share it on a personal network path), and naturally, I have a lot of rebuild to run.
<chipb>but it would appear that I can't download the linux-libre-headers tarball from any mirror.
<chipb>I think I can work around it easily enough, but thought someone might be interested in knowing bootstrap-from-source is potentially broken.
<rekado>sneek: later tell ng0 “this program is licensed under the GPL” means any version of the GPL unless specified.
<sneek>Got it.
<rekado>Apteryx: re build logs: you don’t need emacs-guix to view the build logs. See the “--log-file” option to “guix build”.
<rekado>sneek: later tell adfeno You can do “mpv URL” directly, no need to separately run “youtube-dl” first. (mpv does that for you.)
<sneek>Will do.
<chipb>do people generally set GUIX_PACKAGE_PATH to a checkout of the main git tree? is there any guarantee that package definitions can be used by e.g. the 0.12.0 release?
<rekado>chipb: GUIX_PACKAGE_PATH is for things that are not part of guix.
<rekado>chipb: I have a separate repository of packages that are not in guix, and that repository is on GUIX_PACKAGE_PATH.
<rekado>for modifications to guix itself I use the git checkout.
<rekado>the checkout is linked as ~/.config/guix/latest
<chipb>ah, interesting.
<chipb>the checkout is of master?
<chipb>I think 'core-updates' might be what I was looking for.
<chipb>which I presume is what guix refresh maps to for 'core' subset?
<cbaines>core-updates is just a branch, like master
<cbaines>however, changes that would require building lots of packages are pushed to the core-updates branch instead of master
<cbaines>then when hydra has built a significant number of the packages for the core-updates branch, it is merged in to master
<cbaines>this happens as needed
<chipb>and the non-core subset referred to by 'guix refresh' docs is basically the state of the package definitions on master?
<chipb>or am I off in the weeds?
<cbaines>I think you are relating the branches in the Git repository, and sets of packages, which are not explicitly related
<cbaines>the core/non-core subsets that are described in the guix refresh docs are as it says, either packages that are used to build everything else, or everything else
<cbaines>So, updates to packages in the core set would probably be pushed to the core-updates branch, but I believe there may be other updates that would be too costly to push straight to master as well
<chipb>hm. clarity escapes me. I think I should probably get some sleep.
<chipb>thanks for the pointers.
<roelj>Why does it have to build derivations the second time when I run `guix environment --container ...' twice?
<roelj>And can I avoid it? I'd like to test the container stuff on a machine that cannot run guix-daemon as root
<roelj>So it cannot build derivations.
<rekado>roelj: what kind of derivations are these? Is it profile hooks?
<cbaines>Also, you may want to look at guix system container, as that generates a script in the store to start the container
<rekado>I have never (successfully) used “guix system container” before. Guess I should try it one day.
<rekado>I remember vaguely that it had some rough edges.
<roelj>rekado: Yes, I think so
<roelj>rekado: profile, fonts-dir, ca-certificates-bundle, and info-dir
<rekado>I don’t know if there’s a good reason for them to be rebuilt. It might be a bug.
<efraim>In case anyone else is working on it, I'm checking the zlib update on core-updates now
<Gottox>hi! is this the right channel to ask questions about elogind?
<Gottox>I'm currently trying to get elogind running on voidlinux, but it fails with "Cannot determine cgroup we are running in: No such file or directory"
<Gottox>According to the source it tries to load /proc/self/cgroup and searches for a controller.
<Gottox>How can I setup the cgroups before calling elogind?
<civodul>roelj: 'guix environment' now has a --root option if you want to protect the profile it built from GC
<civodul>Gottox: hi!
<civodul>Gottox: there's a bunch of cgroup file systems to mount
<civodul> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/file-systems.scm#n235
<Gottox>civodul: thx a lot! how do you guys manage elogind? is it started as an system service or do you start it dynamicly through dbus?
<civodul>Gottox: it is started via D-Bus activation
<civodul>that way, the first time you login, pam_elogind requests the org.something.logind service, and dbus-daemon starts it
<Gottox>I wondered because the service on the repository points to /bin/false
<Gottox>at gh
<civodul>right, we fix that in our package :-)
<civodul>there's some info in https://www.gnu.org/software/guix/news/gnome-in-guixsd.html
<Gottox>ah, cool :)
<Gottox>Up to now we at voidlinux were using consolekit patches but it gets harder and harder to port those so I'm looking for an alternative.
<civodul>elogind works pretty well AFAIK
<civodul>(though i don't personally use GNOME)
<civodul>it's a good idea to join forces anyway :-)
<Gottox>yea :D
<Gottox>I already posted a patch to fix gcc-6 for elogind at gh.
<Gottox>(maybe it's obsolete at the next systemd rebase, but anyway)
<roelj>civodul: Thanks. I did not know that.
<Gottox>but thanks for the help! :D
<efraim>If I ever finish my aarch64 stuff then I might try looking at making an x32 system with guix, since I have so many 64-bit laptops with ~2GB of ram
<roelj>Hmm. Doing ./pre-inst-env guix environment guix; ./bootstrap; ./configure; results in the error: "configure: error: C compiler cannot create executables"
<roelj>What am I missing?
<roelj>Ooh, wingo told be the solution a while ago..
<efraim>whats the solution, that sounds a lot like the error I was getting on aarch64
<roelj>I'm trying to find it..
<rekado>roelj: you could check the config.log
<rekado>it includes the test programme that failed.
<rekado>bleh, another rebuild of numpy
<rekado>there are a lot of rebuilds in the latest evaluation.
<rekado>geiser-edit-symbol-at-point does funny things.
<rekado>I'm on a package reference to netcdf and M-. takes me to a string mentioning netcdf.
<rekado>instead of taking me to the package definition.
<rekado>oh, it might be my fault.
<rekado>I'm using two worktrees and have nothing but trouble with them.
<rekado>I have ~/dev/guix and ~/dev/guix-wip and my REPL is configured to look up stuff in guix-wip (but I'm currently working with ~/dev/guix)
<roelj>efraim: I found it: export GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yep
<roelj>efraim: But, do not use it for anything that ends up in the store :)
<efraim>i'll have to check if aarch64 fails on gcc-final or gcc itself :)
<efraim>thanks
<divan>Hi All. I've read this thread on tramp and guixsd https://lists.gnu.org/archive/html/help-guix/2016-10/msg00042.html
<divan>but still have the issue with Wrong method specification for ‘ssh’.
<divan>my source emacs system is parabola. I note the comment "probably only helps if you start on a guixsd machine..!"
<divan>my source system isn;t (yet) guixsd. Anyone know how do I get tramp working?
<divan>ah nevermind, had to set tramp-default-method to ssh too.
<divan>:)
<ng0>the best problems are the ones which fix themselves :)
<sneek>Welcome back ng0, you have 1 message.
<sneek>ng0, rekado says: “this program is licensed under the GPL” means any version of the GPL unless specified.
<ng0>rekado: so GPL3+ as the current version
<ng0>GPL3 or later, as it applies to any version
<rekado>with a comment that any version is okay
<rekado>ng0: but please double check any license headers in the source files.
<rekado>sometimes the README is sloppy
<ng0>the only header said:
<ng0>ah one moment...
<ng0>i get the link to the source
<ng0> https://github.com/infodox/tsh-sctp/blob/master/aes.c this should be the one
<adfeno>Hm.... Strange-looking-full-of-codes tables we have there....
<sneek>adfeno, you have 1 message.
<sneek>adfeno, rekado says: You can do “mpv URL” directly, no need to separately run “youtube-dl” first. (mpv does that for you.)
<divan>anyone have a link with various ppls example config.scm (system) file? Useful for the clueless.
<adfeno>Oh... Thanks rekado :)
<adfeno>I wonder if the so called "FIPS-197" tells people to implement such unreadable tables. :)
<divan>When installing pkgs, I suppose(best practice?) many pkgs should be installed at user level and not global level. Though I want the entire system defined in one config.scm file. How to install pkgs for a user (not global) in the config.scm file?
<adfeno>When installing GNUnet using Guix (not GuixSD), must I install it at least twice? (one for root and other for each normal user)
<ng0>no idea. reminds me that I should turn on the other computer, extract the service and ask for help on debugging the oddities of shepherd
<adfeno>Because, per the README file included in the GNUnet recipe that came from GNUnet's git, it has to have two-step configuration.
<adfeno>... One for "gnunet" user, that's initiated by root.
<ng0>the default would be running a service which does that kind of thing for you and you run it as a user, but so far I don't have any clue how to finish te service
<adfeno>... And other for each user.
<adfeno>Also, the included README had a typo, perhaps.
<ng0>which line?
<adfeno>Line `adduser gnunet gnunet` would need to be:
<ng0>and, which version
<adfeno>adduser --system --home "/var/lib/gnunet" --group gnunet
<ng0>afaik that's up to the system
<adfeno>Package is "gnunet-git" version 0.10.1-dev, from Guix recipe that came from GNUnet git repo.
<adfeno>ng0: Hm...
<ng0>I can change it if that's not specific to any debian or whatever
<adfeno>It's because doing `adduser gnunet gnunet` exits with 1 status.
<ng0>on GuixSD?
<adfeno>ng0: Hm.... No, I'm not using GuixSD, but Trisquel 7.
<ng0>in that case, no idea.
<adfeno>I used "/var/lib/gnunet" before because the README file recommends doing so.
<ng0>ah
<adfeno>Although the recommendation isn't in the same line in which the command is asked to be done.... It's further on.
<ng0>adduser adds the user to the previously created gorup "gnunet" and uses the defaults (in this case /home/$name ?
<ng0>the docs are changes anyway, but if that adduser you recommended makes more sense I can change it
<ng0>*are being changed
<adfeno>ng0: `adduser gnunet` add's a normal user (non-system), makes "/home/$USER" his $HOME, and makes non-system group of same $USER name.
<adfeno>Non-system users are asked to provide password and an optional friendly name.
<ng0>afaik there's a debian adduser and an upstream adduser
<adfeno>Whilest system users have disabled login.
<adfeno>Hm....
<adfeno>Interesting....
<adfeno>I always though of either `adduser` (friendly one), and `useradd` (low-level one).
<rekado>I think I asked this a couple of months ago, but here goes: how can I run a shell script in a snippet?
<ng0>anyway, I just asked about this change if it makes sense and when I get feedback i'll add it.
<ng0>ah, ok that's it
<rekado>background: shogun comes with a script to remove all non-free parts; we could use that instead of the brittle snippet thing I once wrote.
<rekado>but I don't know how to access the shell during the snippet evaluation.
<adfeno>rekado: Let's see...
<adfeno>tWhat do you expect to get from the script once it's finished?
<adfeno>(a) standard output or error.
<adfeno>(b) exit status
<adfeno>(c) nothing
<adfeno>At any rate, as basis for my answer, I have seen recipes using (system ...) (or was it (system* ...) ???) procedure to run scripts.
<adfeno>s/to run scripts/to run arbitrary shell commands/
<adfeno>As far as I know both system and system* can return exit statuses, not #t or #f.
<adfeno>So at best you can do (zero? (system ...))
<ng0>I think the problem is that this does not work in snippet.
<mekeor>omg, i just booted GuixSD the first time. i worked around my beep-then-shutdown hardware-issue by re-installing guixSD without LUKS-encryption
<ng0>adfeno: applied
<adfeno>mekeor: That's great :)
<adfeno>I wonder what in LUKS encryption caused that.
<mekeor>adfeno: it's not LUKS' fault. it's an hardware-issue. it took too long to type in my password for LUKS...
<adfeno>Oh.... I see...
<mekeor>because the hardware-issue disappears as soon as the OS is loaded but otherwise my computer shuts down...
<adfeno>Oh... Wow...
<adfeno>It's like "You have 5s to boot OS otherwise I'll self destruct"
<mekeor>hahah yeah, exactly :D
<ng0>that's useful.. somehow.
<adfeno>Indeed...
<adfeno>I was just thinking of some situation that it could be good to have that hardware issue.
<mekeor>so, i've now installed guixSD without a clue how to use this. how do i install emacs?
<mekeor>lol haha
<adfeno>No wonder why we could find little information about long beeps repeating continuously.... it was a timer.... for security of LUKS encrypted device???
<ng0>adfeno: regarding gnunet, see #gnunet log
<adfeno>ng0: Will see it now.... Actually, will join channel.now too.
<ng0>that doesn't help, i meant the log
<adfeno>Yep... I'm going to the site which holds #gnunet logs.
<Gottox>another elogind question. elogind now runs in background; loginctl works but gdm just sits there and does nothing if I start it. again using voidlinux :)
<phant0mas>hello everyone
<phant0mas>can anyone try running ./pre-inst-env guix build --target=i686-linux-gnu coreutils on latest core-updates on his machine?
<phant0mas>or ./pre-inst-env guix build --target=i586-pc-gnu coreutils
<civodul>phant0mas: can i set hydra to cross-build for i586-pc-gnu on core-updates?
<civodul>is that the right triplet?
<efraim>i'm building the new zlib on core-updates on x86_64 atm
<phant0mas>civodul: yes civodul, but we have an issue with coreutils when cross-building
<phant0mas>Makefile:3440: *** Recursive variable 'INSTALL' references itself (eventually). Stop.
<phant0mas>I have reproduced the same error with target Hurd and i686-linux
<phant0mas>civodul: start the build on hydra and you will see for yourself
<phant0mas>./pre-inst-env guix build --target=i586-pc-gnu bootstrap-tarballs
<mekeor>when running "guix system reconfigure /etc/config.scm", i get "guix substitute: error: download from [...]mirror.hydra.gnu.org[...]adwaita-icon-theme[...] failed: 504, "Gateway Time-out". any ideas why?
<civodul>mekeor: the build machine seems to be overloaded right now
<civodul>you can either use --fallback, in which case it will fall back to building from source
<civodul>or try again in a minute
<mekeor>alright, yeah, i'm trying that already rn :) thanks
<civodul>yw :-)
<roelj>Say I have a Gexp in which #$takes is '(("words" . "hello" "Guix")). Then #$(assoc-ref "words" takes) results in #f. What should I do instead?
<roelj>Uh.. #$takes is '(("words" . '("hello" "Guix")))
<rekado>assoc-ref takes the alist first, then the key
<roelj>Oooohh how silly of me :)
<roelj>Thanks rekado! That works fine :)
<rekado>heh
<rekado>always keep a REPL around.
<civodul>rpi-open-firmware looks like good news: http://crna.cc/b/11
<mekeor>why does "guix system reconfigure config.scm --fall-back" build many packages i didn't say i want? like inkscape, texlive etc.
<civodul>it builds things that it could not download from mirror.hydra.gnu.org
<civodul>so that really depends on your config
<civodul>perhaps there are things are build-depend on texlive, for example
<civodul>(though that seems weird)
<mekeor>hmm.
<mekeor>how can i find out the packages included in %base-packages?
<mekeor>and how can i find out packages needed for %desktop-services?
<mekeor>maybe you can point me to the section in the docs?
<civodul>sneek: later tell mekeor see https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html#index-_0025base_002dpackages and https://www.gnu.org/software/guix/manual/html_node/Desktop-Services.html#index-_0025desktop_002dservices
<sneek>Okay.
<efraim>good news! zlib-1.2.11 built without problem on core-updates
<roelj>efraim: nice!
<mekeor>hello from GuixSD :)
<sneek>Welcome back mekeor, you have 1 message.
<sneek>mekeor, civodul says: see https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html#index-_0025base_002dpackages and https://www.gnu.org/software/guix/manual/html_node/Desktop-Services.html#index-_0025desktop_002dservices
<mekeor>fuck. i'm just realizing i forgot to backup my pgp-keys before installing guixSD... ugh
<rekado>ouch!
<rekado>a good backup program that's available for Guix: borg.
<adfeno>rekado: borg?
<adfeno>Oh... I see...
<rekado>adfeno: it's a tool for deduplicated, incremental, encrypted backups
<rekado>and it's easy to use
<adfeno>Since lots of projects depend on GitHub to make contirbutions, I ended up rolling my own backup solution using rsync and tar
<rekado>I did this for a long time, but I was never quite satisfied.
<adfeno>I know rsync supports incremental , but I decided to make whole backups instead.
<adfeno>I feel safer this way.
<rekado>I don't have enough storage for multiple full backups
<mekeor>talking about GitHub: i get an error concerning SSL CA certificate when trying to clone a GitHub project over https... did you also experience this?
<adfeno>I only do two at time.
<adfeno>I only keep two full backups at each time.
<rekado>adfeno: I keep 6 monthly, 4 weekly, 7 daily.
<adfeno>Wooow.
<mekeor>wow
<adfeno>I do mine each month.
<mekeor>what are you backing up actually?
<rekado>mekeor: you may want to set GIT_SSL_CAINFO to $HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt
<rekado>mekeor: after installing nss-certs
<rekado>mekeor: our laptops and my server.
<adfeno>I must test something, will be back.
<efraim>I back up most of $HOME with borg
<mekeor>what kind of data though? like code? images? videos? keys? config? documents?
<efraim>Not music, videos, git folders, downloads
<rekado>code, music, images, keys, config, no videos
<efraim>Music and videos are stored on the NAS and shuffled around with git-annex
<mekeor>efraim: Not music? or Lot music?
<mekeor>oic
<mekeor>rekado: i don't have a $HOME/.guix-profile/ folder atm
<mekeor>i did 'git config --global http.sslCAInfo /etc/ssl/certs/ca/ca-certificates.crt' instead, but i still get this error.. hm.
<mekeor>oh, i see. it's because of access rights. mmh. i do have nss-certs installed globally though. what do i have to do in order get a ~/.guix-profile folder?
<snape>mekeor: how did you create your user profile?
<snape>it's weird that you don't have .guix-profile
<rekado>mekeor: you could also just point GIT_SSL_CAINFO at the global file
<rekado>mekeor: once you install a package you have ~/.guix-profile
<snape>oh I see
<snape>then it's weird that guix package is necessary to get a working environment
<mekeor>rekado: no, that doesn't work because the global file is only readable for root
<snape>imho guix system reconfigure should have created ~/.guix-profile for each user
<mekeor>yes, think so, too
<snape>Oh I see
<snape>.guix-profile is probably useless without user-installed packages
<mekeor>well, true
<snape>and that would be why it is created on first guix package command
<mekeor>snape: as i suggested though, the global ca-certificates.crt is only readable for root; i.e. the ~/.guix-profile folder *does* in fact make sense without user-installed packages, no?
<snape>yes, but you have to install nss-certs with 'guix package'
<snape>in order to have certificates in .guix-profile dir, I think
<mekeor>ah, i see
<snape>by 'guix package', I mean: as a user
<mekeor>sure
<mekeor>okay, i installed nss-certs as user. but still, the issue occurs. i think it's because ~/.guix-profile/etc/ssl/certs/ca-certificates.crt is a symlink to a file only readable by root
<mekeor>(before trying git clone, ofc i did changed the git-config to point to the .guix-profile version of ca-certificates.crt)
<roelj>Uh-oh: guix package: error: build failed: while setting up the build environment: mounting /dev/pts: Invalid argument
<mekeor>so, i'd guess there's a little bug in package nss-certs concerning the file priviledges?
<mekeor>oops, i'm wrong.
<mekeor>the ca-certificates.crt *is* readable for others
<mekeor>do you use mail-clients? which one? -- usually, i use thunderbird but it's not available in guix yet. i read the discussion here, in #guix@freenode, from last october on thunderbird but it just ended up in the unanswered question in "so are we going with thunderbird?"
<adfeno>I'm using Emacs' Gnus mode.
<adfeno>So far I'm liking it very much
<efraim>Mutt with msmtp
<efraim>We do have claws mail packaged though
<mekeor>alright; i'll get this managed
<buenouanq>mekeor: claws-mail is pretty great
<buenouanq>haven't yet been able to get spellcheck working in it on guixsd though
<mekeor>buenouanq: cool. does it also work nice with PGP?
<buenouanq>mekeor: yes, you just have to enable the relevant (3) plugins it ships with
<buenouanq>I really should step up to Gnus though.
<adfeno>:)
<adfeno>What is left for me is to find a way to setup my Gnus so that, if I receive a message with some Word attachment, I automatically send a reply back :)
<adfeno>I think I'll stick to non-local Sieve service for now...
<adfeno>I hope it works as I expect it to.
<mekeor>gcc: error trying to exec 'as': execvp: Datei oder Verzeichnis nicht gefunden
<mekeor>this is what i get when i try 'xmonad --recompile'...
<mekeor>i guess 'as' is GNU Assembler, right?
<mekeor>is it part of gcc?
<lfam>rekado, mekeor: Actually, borg doesn't do incremental backups. Each backup run creates a chunk-deduplicated snapshot of your files, and represents a "full" backup.
<lfam>mekeor: I backup hundreds of GB with borg, and there are people using it to backup terabytes of data.
<alezost>mekeor: if I understand you correctly, you need to install "gcc-toolchain" instead of "gcc"
<lfam>mekeor: Here are user stories, if you're interested: https://github.com/borgbackup/borg/issues/216
<mekeor>alezost: does gcc-toolchain include 'as'?
<alezost>mekeor: yes, if you want to use gcc to compile something, then remove "gcc" and install "gcc-toolchain"
<adfeno>Hm.... Sieve deosn't seem to do what I want to too.
<rekado>lfam: yes, you’re right. I meant deduplicating.
<rekado>mekeor: re email client: I like mu4e in Emacs with msmtp and offlineimap.
<mekeor>with 'guix package -s' i found out, ghc-toolchain is defined in 'commencement' package-module. so, i included that in my manifest, but 'guix package -m manifest.scm' still says gcc-toolchain is unbound. why?
<mekeor>but 'guix package -i ghc-toolchain' works...
<civodul>mekeor: i'd recommend using 'specification->package' in your manifest
<civodul>this looks up packages by name
<civodul>see https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html#index-specification_002d_003epackage
<alezost>mekeor: because there is no 'gcc-toolchain' variable in that module, there are 'gcc-toolchain-5', 'gcc-toolchain-6' and others. Try "guix edit gcc-toolchain" and look at the bottom of (gnu packages commencement) module
<civodul>ACTION found a terrible bug in grafts.scm
<civodul>essentially there was no caching, so in pathological cases it could take forever to determine what needed to be grafted
<jmd>Only in pathological cases?
<lfam>I wonder if that's the cause of the recent slowness some users have described
<lfam>I noticed the reports seemed to follow some new grafts
<efraim>it sounds like a bug that would hit slow computers, and I don't think I've hit that one :)
<lfam>I have an extremely slow one, but it's headless
<jmd>I wonder if civodul means "forever" in the literal meaning or just "a very long time"?
<lfam>A trivial distinction to a human being ;)
<civodul>"a very long time" indeed
<civodul>:-)
<civodul>kdevelop was a pathological case
<civodul>i've never seen anything that bad before
<civodul>so i wonder how this went unnoticed
<civodul>at least by me ;-)
<efraim>davexunit sped up grafting, so I think that hid a bunch
<civodul>efraim: when was that?
<efraim>months ago
<efraim>august
<efraim>5a1add373ab427a3b336981d857252e703a9f8d1
<lfam>That's Mark :)
<efraim>doh
<civodul>oh right, and that was for the actual grafting process
<civodul>here i was referring to what happens on the "host side"
<efraim>do we want to skip the tests on python{,2}-minimal?
<efraim> https://git.gnome.org/browse/libxslt/tree/configure.in?h=v1.1.29#n316 maybe libxslt should be built with python2, then python2 won't have a dependancy on python3
<civodul>libxslt does not depend on Python, does it?
<efraim>it does for its python bindings
<civodul>oh i see, it's a build-time dependency
<civodul>not a run-time dep
<mekeor>it would be nice to have a list of guix configurations. already some of us put them on online, e.g. on github, but it'd be nice to have them linked at a single place, IMHO
<cbaines>I have a rather uninformative error from running guix system build http://paste.lisp.org/display/336766/raw
<cbaines>Luckilly, I'm pretty sure this is related to the changes I am trying to the NetworkManager service, as it works fine without those
<cbaines>Apart from that though, I have no idea what I have done wrong
***snape` is now known as snape
<civodul>cbaines: of course, #f is not a procedure, muahaha
<civodul>:-)
<civodul>i guess we'd need to look at your diff
<civodul>this backtrace is terrible
<cbaines>I think I might have solved it... guix system build is downloading lots of substitutes, which I assume is good, as it wasn't doing that before
<cbaines>I was changing the network-manager-service-type, and I think I was passing a list containing a record to dbus-root-service-type and polkit-service-type, instead of the list containing a package that was passed previously
<cbaines>Huh, and build offloading has just started working for me, that's nice :)
<rekado>civodul: this might be avoided if we were able to prevent propagation of bogus values earlier.
<rekado>I’d really like to have something like compile-time type checking for our monads
<snape>civodul: I don't understand why you check SSH pid file in your ssh-deamon test. If the service were to crash, the pid file would still be there I think, so what does it prove?
<civodul>rekado: agreed
<civodul>snape: it's a fresh VM, so it's just a way to check whether the daemon created its file
<snape>I see. But maybe checking if the file matches a real process with "ps -p PID" would add more value. I'll do that in my test :)
<cbaines>So, I think build offloading was working, now it seems to have broken, guix is just printing the following over and over: process 22323 acquired build slot '/var/guix/offload/capella.local/0'
<civodul>cbaines: could it be that the machine in question is loaded?
<civodul>offload keeps trying until the load is < 2
<cbaines>No, the load is tiny
<cbaines>I terminated the process to restart it, so I could have messed up the state on the either machines involved?
<civodul>not sure
<civodul>make sure "guix offload test" is OK
<civodul>but otherwise i don't know what could be going wrong
<civodul>if you still have the problem, could you post the offload log?
<cbaines>where would I find that?
<mekeor>after upgrading GHC to version 8.0.1, i now get an "error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory". anyone making the same experience?
<rekado>mekeor: there’s a bug report about this, I think.
<lfam>Err, did 384344198d (file-systems: 'file-system-needed-for-boot?' is #t for parents of the store.) break the build for anyone else?
<mekeor>rekado: for guix?
<lfam>mekeor: http://bugs.gnu.org/25421
<civodul>lfam: "rm gnu/system.go"
<civodul>there's an ABI break