<castilma>is this a typo on the new website?: "They can leave together." leave instead of live? <Apteryx>is native CVS support in Emacs good? <Apteryx>I have something which is sorta like magit for bzr & other older VCS, it's called DVC. Haven't had a use for it but I have it packaged here. <taohansen>also: kind of curious why there is a discrepancy in behavior between a `sudo guix pull` invocation and a `sudo --login` followed by `guix pull` <str1ngs>sudo uses the same HOME as the current logged in user <str1ngs>and pull uses things like $HOME/.config/guix for say latest guix <str1ngs>you need to somehow tell sudo to use roots environment <taohansen>as an administrator of my own system, i find it disconcerting i need to login to a root shell to reconfigure the state of my system <taohansen>expected behavior for me would be a quick elevation via sudo to do the admin task then back to unprivileged <str1ngs>I don't enough about guixSD to help much. <str1ngs>try with . $ sudo su - root -- guix pull <taohansen>civodul: would love your input on this when you find yourself near a machine <str1ngs>my hack is not ideal, but it's a start <str1ngs>again, there could be a better way to do this either with guix or sudo <str1ngs>do you have any sudo alias like -E maybe? <str1ngs>also -H could do what you want as well. ie sudo -H guix pull <str1ngs>I think even -E keeps your current HOME so -H might be required either way <lfam>I recommend `sudo --login` <str1ngs>su - root is the same effect, then if you want a one liner <str1ngs>ahh unless you mean $ sudo --login guix pull ? <lfam>Yeah, that's what I meant. In this case it does the right thing compared to the other sudo invocations above <str1ngs>I agree, sorry I miss understood what you meant. I took it as $ sudo --login\\n <str1ngs>taohansen: sudo --login guix pull . seems the better way here <brendyn>Can someone that is running gnome please tell me what their XDG_CURRENT_DESKTOP variable is set too, if you haven't set it manually? <str1ngs>brendyn: logging into GNOME sessions gives me GNOME for XDG_CURRENT_DESKTOP. using host gnome through <brendyn>Thanks what I wanted thanks. I just wanted to know if GNOME was correctly setting it. <str1ngs>that might change though, depending if your say using wayland vs x11 <str1ngs>I'll see if I can find some gnome documentation on that <str1ngs>GNOME seems the right thing either way <str1ngs>technically, if GNOME is setting it. it is the right thing. I guessing have a specific reason for asking though. ***gabriel_ is now known as g_bor
<g_bor>I have tried connecting the irc channel from the homepage, and it is not working for me. <g_bor>I got a connection error, or something like that in a red box. <g_bor>It might as well be a network issue... <rekado>added five nodes to berlin.guixsd.org, but one of them died right after installation. <g_bor>Do we have a service for smb? <g_bor>I'm planning to deploy a fileserver, and I was considering guixsd... <rekado>we have a samba package, but I don’t know of a service for it. <g_bor>But I also don't know about a service. <g_bor>Anyone else is interested in this? <g_bor>I might consider writing a service for that, but it feels a bit too much if noone else is interested... <marusich>If you need it, then there is a good reason to make it. <g_bor>I might make a draft of that... <g_bor>I had recently a restart on one of my guixsd systems, and i have an openssh service there, which failed to start. <g_bor>I only have a single log line stating that it didn't start. <g_bor>I worked before that, and after that, and I was even able to start it on the running system, once I got a console... <marusich>Actually, I don't know. I also have a system where openssh's ssh-daemon fails to start, but there is no additional information. I have to manually start it myself each time...what a pain. <marusich>If anyone here has any ideas about how to debug it, I'm all ears. The only clue I have is that Shepherd says, in /var/log/shepherd.log, that the it failed to start. <marusich>...but it doesn't fail to start when I manually start it with "sudo herd start ssh-daemon" (or whatever the right invocation is). <marusich>I'm guessing maybe it failed because it started up before the network was available or something, but it's hard to say without error messages. <g_bor>At least in my log it is always starting before I get the log line that the network is started. <marusich>Well, apparently the openssh shepherd service only requires syslogd before it will start, so yeah I guess maybe that isn't the reason... <rekado>ACTION saw that something great has just been uploaded to the gnu servers… <wingo>how did you work around the uri? issue for 2.2.3 vs 2.2.2? <civodul>it only affects specific tools after 'guix pull' <marusich>FYI tests/graph.scm fails on core-updates. Not sure why. I'm bisecting now to find out where the failure was introduced... <rekado>I’ll add these post-presentation stub articles to the website today. <civodul>rekado_: any preference on the release highlights for the blog post? <civodul>so far i have ISO-9660, bootloader API, UI improvements, 'guix-daemon --listen', 'guix import json' <rekado_>civodul: these highlights seem fine to me. <nicklaf>guix beginner here: anybody know why a hash would fail to match when running guix package -i? <nicklaf>Starting download of /gnu/store/akc5vvh64mzrkg86zgg4fd2qpbrl7j38-erlang-19.3.tar.gz <nicklaf>output path `/gnu/store/akc5vvh64mzrkg86zgg4fd2qpbrl7j38-erlang-19.3.tar.gz' should have sha256 hash `1b47jh549yywyp8fbs8a8j4ydr3zn982navzyqvlms6rg8vwb0pw', instead has `17ddyhz1awzfvy5mgx7a8nph12x24k1bamnhyk5zvw47i36wysfz' <nicklaf>I downloaded that file with wget and sha256 gives yet a different hash <nicklaf>df69cfcd8887f0fdcbf4d056b5c224a28b00af45eaf4578bdfee73153ef4ad9d otp-OTP-19.3.tar.gz <nicklaf>guix is also complaining about an invalad locale, although i've been able to install other software correctly despite that <efraim>Qt 5.10 released, I'll look at it soon. I'm plannign on leaving monolithic qt on LTS ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | 0.14.0 is out! https://gnu.org/s/guix/blog/2017/gnu-guix-and-guixsd-0.14.0-released/ | videos: https://gnu.org/s/guix/help/#talks | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: https://paste.debian.net | log: https://gnunet.org/bot/log/guix | Guix in high-performance computing: https://guix-hpc.bordeaux.inria.f'
<Sahil>civodul: great news, Thanks to the Guix developers and contributers :D ***pksadiq_ is now known as pksadiq
***pksadiq is now known as Guest88338
***Digitteknohippie is now known as Digit
<kmicu>(Also verification step shows that your key expired 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 'Note: This key has expired!') <g_bor>It was very nice to take part in this :) <civodul>kmicu: thanks for the heads-up, looking into it <efraim>We even got mentioned on phoronix <rekado_>it’s 1200 *new* packages, not a total of just 1200. ***Digitteknohippie is now known as Guest6183
***Guest6183 is now known as Digit
***Digit is now known as Guest24662
***Guest24662 is now known as Digitteknohippie
***Digitteknohippie is now known as Guest12371
***dirgert is now known as Digit
***Digit is now known as Guest23655
<civodul>now it says "1,211 new packages (more than 6k packages in total)" <rekado_>yes, they corrected it really quickly after I sent Michael a message. <civodul>i started writing down the HPC-related changes that have been made in this release cycle, mostly packaging <civodul>the idea is to give people a feel of what's happening that's relevant to HPC <rekado_>I’ll be out for a lavish feast in just a moment, but I’ll read it on the way there. <rekado_>I didn’t realise we’ve had so many goodies! <apteryx_>I found another problem with the way Emacs dependencies are managed; apparently doing "guix environment --pure --ad-hoc emacs", emacs still discovers all of the emacs packages installed through Guix in your main profile. <sneek>vagrantc, you have 1 message. <sneek>vagrantc, str1ngs says: removing my TZ variable resolved it. But I suspect tzdata needs some setup. either way thanks for the help. <christopher74837>if you install guix on Debian, isn't there problems because you can't control the version of kernel running on the system...? <roptat>it's ok, guix doesn't depend that much on kernel interfaces <roptat>and programs usually use glibc which works for any kernel after 2.6.32 if I'm not mistaken (--enable-kernel=2.6.32 in glibc package) <OriansJ>christopher74837: assuming proper engineering, there is no reason for any program (save those that depend on some recently developed feature that can't be approximated) should even care about kernel version <OriansJ>also if certain kernel functionality is critical, you can always backport new kernel features as modules to previous versions of the linux kernel. (we have the source after all) <vagrantc>so, if i've been running "guix pull" regularly, guix 0.14.0 isn't a huge deal, i'm guessing? mostly just useful for bootstrapping new systems? <christopher74837>i was just trying to ancipate difficulties. I'm going to try to install guix on my Debian stretch system <vagrantc>ACTION also recently installed guix on a debian system, but should have waited for 0.14.0 to come out <OriansJ>christopher74837: well, the default signing key for guix is not in the debian key ring and it can be a little memory hungry and you have to remember to create a couple things, it works <vagrantc>ACTION wonders if people would balk at uploading a guix keyring to debian... <OriansJ>vagrantc: go for it (if you think they'll accept it) <vagrantc>it wouldn't be hard to do, but no idea what keys to include at this point <shiranaihito>guys? :) please consider mirroring GuixSD as a plain ISO file, instead of the xz compressed version. I'm trying to install it on a Vultr VPS but it can't deal with the compression, and publishing it somewhere so that Vultr can download it is a bit of a pain in the ass :p <bavier>shiranaihito: does Vultr not do iso uploads? <bavier>christopher74837: right, you'll probably need to build your own gnutls <shiranaihito>bavier yes, i'm trying to "upload custom ISO" to Vultr, but their system only accepts plain ISO files (and GuixSD is distributed as an xz-compressed ISO file) <shiranaihito>(the normal one seems quite big uncompressed - i wonder why that is) <vagrantc>christopher74837: if you LOVE compiling, you'll LOVE guix. <bavier>christopher74837: you can even start your deamon with --no-substitutes ;) <christopher74837>what!? I thought this was one of those handholding distros where you say "guix make dinner" and it gives you a cheeseburger <bavier>but seriously, substitutes are recommended <vagrantc>christopher74837: it may very well do that, but there's some compiling going on in the middle :) <christopher74837>i don't think gnutls has a bootstrap script. that is what I get for pulling from the git repo <bavier>christopher74837: oh sorry, I thought you meant for Guix <bavier>christopher74837: autoreconf -ivf <vagrantc>doesn't bode well for getting guix into debian :/ <bavier>vagrantc: there are bigger issues that prevent a guix package in debian <bavier>vagrantc: e.g. that guix writes to /gnu <vagrantc>ACTION never understood why it wasn't /opt/guix <bavier>vagrantc: that might be a workaround, but someone would presumably want to maintain a build farm that serves packages built for that store prefix <vagrantc>but yeah, that would make the re-useability of substitutes <vagrantc>it would be a curious way for guix to have a "stable" release :) <bavier>christopher74837: does 'autoreconf -i' not work for you? <mb[m]>Ugh, core-updates is completely broken after the latest merge. <mb[m]>`guix pull --branch=core-updates` fails with "Module named (system repl debug) does not exist" after it has compiled everything. <mb[m]>GuixSD fails to boot as well; and on a foreign system the daemon fails to do anything due to "the group guixbuild does not exist", which it obviously does. <lfam>mb[m]: The boot failure is with core-updates? Or master? <shiranaihito>it's 1.1GB uncompressed, and ~280MB compressed, right? is there just lots of "empty space" that's included in the image <bavier>code and text that tends to compress well <shiranaihito>"Ugh, core-updates is completely broken after the latest merge" <-- is this the kind of stuff why GuixSD "isn't production-ready" yet? :P <lfam>shiranaihito: core-updates is a development branch, not deployed to users <shiranaihito>that sounds kind of scary but i have no clue if that's something i'd run into when using GuixSD for running my SaaS app <lfam>We put big (that is, "core") changes on that branch and then whip it into shape :) <shiranaihito>overall, GuixSD gives off a well-maintained vibe though :) <lfam>It's a problem for us because it's quite annoying for it to regress after several weeks of work <lfam>Thanks, please let us know where the docs fall short, or about bugs / usability issues you find <shiranaihito>well, at the moment i'm planning to actually use GuixSD "in production" for my tiny little fledgling SaaS app <shiranaihito>i just get the feeling that Guix might be on to something relatively "big" <christopher74837>sometimes the easiest way to get source to build is to just delete the offending makefile lines <g_bor>Well, now I'm building on an older core-updates, but I think I will just fire up a brand new vm, with the shiny new version 14, and have a look at what mb[m] just said... <apteryx_>Is anyone else using Emacs on a foreign distro? <apteryx_>I'm there's something under the site-lisp directory that causes Emacs to split its buffer when passing a file as argument. <apteryx_>When I run emacs with the "-Q" flag this doesn't happen. <apteryx_>I've made sure nothing Emacs on the host system causes the issues (apt purge emacs, removed /usr/share/emacs, etc.) <efraim>did we push the gtk+@2 fix to core-updates? I'm still getting that as a failure <bavier>just fixed jemalloc build on aarch64 <ruuda>Hi, I am investigating a reproducibility issue. Diffoscope identified small differences in /gnu/store/<hash>-manual-database/share/man/index.db. <ruuda>In two entries, there are 16 bytes that differ, they look like ascii digits, just after the package name and before the description. <ruuda>Is this a known issue, and is there anything I could do to help fix it? <ruuda>No me neither, in fact the package is reproducible <ruuda>I think Debian never ran into this, because it is the database itself that is not reproducible, not the mandb program <ruuda>I will reach out to the man-db maintainer to see if he can help <vagrantc>and debian generates the db at install time vs. when building? <ruuda>The db is not part of the package, is it? It is something that you generate locally after installation. <ruuda>As far as I could see, it is the manual-database procedure in profiles.scm that invokes man-db to generate the database. <daviid>congrat or the release guixers! very impressive! amazing quantity of top quality work, my hat!! <slyfox>there is a new release of guix out. it seems to have a new dependency called guile-git. Does guile-git have any releases? <bavier>slyfox: no "official", unfortunately IMHO <slyfox>aha, that's unfortunate. will require a few more steps to package guix source in gentoo (and I guess other distros which prefer building from source)