IRC channel logs


back to list of logs

<rekado>wow, cvs is slow!
<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.
<Apteryx>(if anyone is interested)
<taohansen>anyone here using the Guix EXWM package?
<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 guix pull is not needed.
<str1ngs>also they don't do he same thing
<taohansen>but i'd prefer it
<taohansen>to logging into a root session then pulling
<str1ngs> in fact it's not a good idea
<taohansen>as i've learned from direct experience
<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
<str1ngs>is this on guixSD ?
<taohansen>expected behavior for me would be a quick elevation via sudo to do the admin task then back to unprivileged
<taohansen>yes it is
<taohansen>NixOS does this correctly IMO
<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
<taohansen>str1ngs: will try, thanks. :-)
<str1ngs>my hack is not ideal, but it's a start
<taohansen>system updating now, have to wait
<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 ?
<str1ngs>lfam: ^
<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
<str1ngs>not sure if that helps you
<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.
<str1ngs>you have*
***gabriel_ is now known as g_bor
<g_bor>Hello guix!
<g_bor>I have tried connecting the irc channel from the homepage, and it is not working for me.
<marusich>What do you mean?
<marusich>If you're talking about it looks correct to me.
<g_bor>I got a connection error, or something like that in a red box.
<g_bor>Maybe I will try later...
<g_bor>It might as well be a network issue...
<rekado>added five nodes to, 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>I've seen the package...
<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.
<civodul>Hello Guix!
<marusich>Hi there.
<g_bor>Ok, thx.
<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>How can I debug that?
<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>I don't think so.
<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…
<civodul>ACTION prepares the announcement
<wingo>wooo :)
<wingo>how did you work around the uri? issue for 2.2.3 vs 2.2.2?
<civodul>wingo: i didn't! :-)
<civodul>i'll do that later today
<civodul>it only affects specific tools after 'guix pull'
<civodul>notably 'guix challenge'
<wingo>hehe :)
<marusich>FYI tests/graph.scm fails on core-updates. Not sure why. I'm bisecting now to find out where the failure was introduced...
<marusich>I'm going to sleep. Goodnight!
<rekado>I’ll add these post-presentation stub articles to the website today.
<civodul>rekado_: awesome
<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>sha256sum gives:
<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
<civodul>arf, too late
<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 | | 0.14.0 is out! | videos: | bugs: | patches: | paste: | log: | Guix in high-performance computing: https://guix-hpc.bordeaux.inria.f'
<civodul>here we are!
<brendyn>midnight on the dot
<pksadiq>that's great. Posted to HN?
<civodul>pksadiq: go ahead :-)
<pksadiq>civodul: done:
<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>civodul: → "The requested URL /gnu/guix/guixsd-usb-install-0.14.0.x86_64-linux.xz was not found on this server." same for GuixSD i686 on I assume it should be as described in the manual.
<kmicu>Scratch the last url, it should be
<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
<civodul>e-party! :)
<kmicu>Thank you.
<efraim>We even got mentioned on phoronix
<efraim>Don't look, details are wrong
<rekado_>they got the package number wrong
<rekado_>it’s 1200 *new* packages, not a total of just 1200.
<rekado_>I’ve sent a correction.
***Digitteknohippie is now known as Guest6183
<rekado_>the error has been corrected.
***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>oh Phoronix :-)
<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>could you take a look, rekado_?
<civodul>esp. regarding bioinfo
<rekado_>civodul: where?
<civodul>here, on my laptop! :-)
<civodul>wait, i'll email it
<civodul>the idea is to give people a feel of what's happening that's relevant to HPC
<rekado_>okay, I’ll look over it.
<rekado_>I’ll be out for a lavish feast in just a moment, but I’ll read it on the way there.
<rekado_>I just went over it – looks good!
<rekado_>I didn’t realise we’ve had so many goodies!
<civodul>yeah, lots of stuff!
<janneke>Congratulations on 0.14!
<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.
<vagrantc>cheers on 0.14.0!
<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.
<vagrantc>sneek: heh. thanks for relaying
<vagrantc>str1ngs: glad it worked out
<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
<ArneBab>Kudos to the nice release!
<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
<christopher74837>how do I install the guile bindings of gnutls?
<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
<shiranaihito>(or maybe you could do both)
<bavier>shiranaihito: does Vultr not do iso uploads?
<christopher74837>are the gnutls bindings part of the guile package...
<christopher74837>oh, it is part of gnutls
<christopher74837>but apparently not built in Debian...?
<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)
<christopher74837>i LOVE compiling ♥
<shiranaihito>some kind of minimal/base install ISO would be cool too
<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
<christopher74837>what am I paying you people for
<vagrantc>christopher74837: it may very well do that, but there's some compiling going on in the middle :)
<christopher74837>erm, what is the command you are supposed to run before autoconf
<bavier>christopher74837: ./bootstrap
<christopher74837>i don't think gnutls has a bootstrap script. that is what I get for pulling from the git repo
<christopher74837>i thinkg autoreconf...
<bavier>christopher74837: oh sorry, I thought you meant for Guix
<christopher74837>no, missing macros, what command gets you the macros
<bavier>christopher74837: autoreconf -ivf
<christopher74837>getting desparate now, I think I'll look at the documentation
<vagrantc>apparently gnutls-guile was disabled in debian's packages intentionally:
<vagrantc>doesn't bode well for getting guix into debian :/
<bavier>vagrantc: there are bigger issues that prevent a guix package in debian
<vagrantc>ACTION is all ears
<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>a challenge
<christopher74837>ack, gnutls instructions say "run autoreconf (etc)"
<vagrantc>it would be a curious way for guix to have a "stable" release :)
<christopher74837>but the (etc) part is what I need to know
<bavier>christopher74837: does 'autoreconf -i' not work for you?
<christopher74837>says can't exec "autopoint". guess I'll install that
<christopher74837>ok, that seems to be working
<christopher74837>don't worry, I'm a trained professional
<christopher74837>they don't give two year degrees to just anyone
<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.
<mb[m]>Fun times!
<lfam>mb[m]: The boot failure is with core-updates? Or master?
<shiranaihito>why is the guixsd installation iso so big btw?
<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>ok :)
<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
<shiranaihito>lfam oh ok, so i guess it's not a problem then
<lfam>We put big (that is, "core") changes on that branch and then whip it into shape :)
<shiranaihito>cool :p
<shiranaihito>overall, GuixSD gives off a well-maintained vibe though :)
<shiranaihito>you've got pretty good docs too
<lfam>It's a problem for us because it's quite annoying for it to regress after several weeks of work
<shiranaihito>mm.. yeah
<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
<efraim>ok, I see it now
<g_bor>Bye! I'm going to sleep!
<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?
<vagrantc>ruuda: couldn't find any relevent categories in or in the debian package
<vagrantc>ACTION mumbles netsplit mumble mumble
<bavier>would it be useful to try to ask at to use their arm systems for building some of our aarch64 packages?
<vagrantc>ruuda: couldn't find any relevent categories in or in the debian package
<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.
<vagrantc>that's what i was thinking
<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)