IRC channel logs

2018-10-12.log

back to list of logs

***runejuhl1 is now known as runejuhl_
<ng0>what's the guile way to achieve this: (when ssh? (setenv "CVS_RSH" "ssh")) ? I know right now this is wrong, because: 'warning: definition in expression context, where definitions are not allowed,'. I assume (setenv) can't be done conditionally, so I am reading more sources to understand what is done usually.
<ng0>doh. I have been looking at the wrong file.
<efraim>As far as the code snippet, I'd go with (if ssh '((setenv ...)) '())
<ng0>the code was alright, I was looking at the wrong file and the wrong section which produced errors :)
<ng0>but thanks
<nly>Does anyone use Bluetooth on GuixSD?
*civodul doesn't
<civodul>hi there!
<kmicu>( ^_^)ļ¼
<janneke>hi civodul!
<roptat>hi guix!
<civodul>hey! what's up here?
<civodul>rekado, efraim: as incredible as it may seem, SoftIron finally sent me a replacement PSU!
<civodul>(for the OverDrive)
<civodul>so now i have no excuse, i'll try to change it over the week-end
<Formbi>guix pull: error: rename-file: Invalid cross-device link
<Formbi>what is this?
<civodul>ouch, probably a brand new bug
<civodul>lemme chec
<civodul>+k
<civodul>Formbi: i guess /var and $HOME are different partitions on your system, right?
<Formbi>yes
<civodul>the problem comes from this code: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/pull.scm#n241
<civodul>it tries to move ~/.config/guix/current* to /var/guix/profiles/per-user/$USER
<civodul>but it does so using rename(2), hence the error
<Formbi>so what can I do?
<civodul>i'll push a fix shortly
<civodul>in the meantime, you can rename things "by hand"
<civodul>or you can run "guix package --rollback -p ~/.config/guix/current" and wait for the fix
<civodul>does that make sense?
<Formbi>ok
<efraim>civodul: wow! I'd forgotten you'd asked for one
<Formbi>thanks
<efraim>currently shepherd fails on core-updates for armhf
<civodul>efraim: re the PSU, np!
<civodul>efraim: i suppose the shepherd failure is non-deterministic, is it?
<efraim>i can try to build it quickly
<efraim> https://hydra.gnu.org/build/3115212/log/raw
<efraim>maybe not so quickly, i'm apparently due to build guile on the way
<civodul>oh that's quite a few test failures actually hmm
<civodul>Formbi: i've pushed the fix, so you can run 'guix pull' now (from the previous 'guix')
<Formbi>thanks :)
<civodul>sorry for the inconvenience!
<Formbi>kdenlive from Guix gives this:
<Formbi>libGL error: No matching fbConfigs or visuals found
<Formbi>how can I fix this?
<ng0>civodul: Since G_ is for the guix gettext in messages, what's the N_? Another gettext domain, or where within our code is it defined?
<kristofer>Good morning #guix!
<civodul>ng0: N_ is for plurals (ngettext)
<kristofer>man, hacking on guix has brought emacs to a crawl on this old machine
<ng0>thanks :)
<g_bor>hello guix!
<nckx>Hullo!
<civodul>"The following derivations would be built (estimated time: 54 mn):"
<civodul>how does that sound?
<civodul>problem is that it works by grovelling the log files, which is quite inefficient
<civodul>maybe we should do that on the daemon side
<g_bor>civodul: istm, that the project to rewrite the daemon would bring some benefits, wdyt?
<g_bor>it has been attemtpted severaly times, am I right?
<g_bor>civodul: I'm trying to track down the javadoc reproducibility problem.
<g_bor>It seems, that it has an option to disable timestamp generation, but it should be done at each site this tool is called. (i.e. we need to patch the build.xml in every package, where we are not generating one, but using the upstream one).
<g_bor>Another option would be to not use this option, but make the tool respect SOURCE_DATE_EPOCH. This would involve patching jdk though.
<g_bor>WDYT?
<vagrantc>fixing reproducibility issues at the toolchain level avoids playing whack-a-mole for some new as-yet packaged thing
<vagrantc>new not-yet-packaged, i meant
<mylainos>Hi, I would like to try GuixSD as my main OS and I have few questions, can I ask them here ?
<kmicu>Hi mylainos, sure, this channels is for Guix and GuixSD.
<buenouanq>mylainos: DO IT
<mylainos>Ok :) I'm using a fully encrypted system with LVM on LUKS but Guix doesn't support LVM so how can I have the same functionality or something similar?
<mylainos>Does one use LUKS without LVM? Just one partition for everything (/, /home, ...)
***hugh_marera_ is now known as hugh_marera
<pkill9>i use LUKS on a home partition
<pkill9>and have an unencrypted root partition
<pkill9>that's only because I didn't know of a way to encrypt the root partition and have guix able to bootup, but apparentlyt hat is possible by setting the partition as a partition neccessary for boot
<pkill9>or something
<joehillen>guix supports encrypted boot. I'm using it on my laptop. But that may not have been true when you set up your machine
<joehillen>at some point I want to figure out how to do this so that I don't have to type in my password twice https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs
<OriansJ>joehillen: please let me know when you figure that one out; as I too hope for that functionality
<georges-duperon>Hi guix!
<georges-duperon>Unsurprisingly, Guix is licensed under the GPL. How does that affect the license of the recipes I write?
<georges-duperon>I'm asking because I usually release my code using the CC0 public domain, but I don't know if recipes are "linking" against the Guix libraries or other stuff that could prevent me from using the CC0.
<nckx>I absolutely think it's linking but don't trust me; ask somebody with an expensive degree ā™Ŗ
<OriansJ>georges-duperon: well I don't think package recipes would qualify as linking anymore than writing a bash script means you are linking to the gpl. Now adding functionality to extend guix would be a different matter entirely.
<yrk>cc0 is gpl compatible, which helps: http://www.gnu.org/licenses/license-list.html#CC0
<nckx>Mm. A better comparison is (heavily) using library code (which Guix is), or them being loadable modules, although that's already more of a stretch. Both would be considered linking. But we're all just randoes on the 'Net.
<nckx>But yrk is absolutely right that this doesn't invalidate your choice of licence.
<nckx>Hey Guix. Does anyone else run GuixSD from a spinning platter?
<nckx>& how many minutes does it take you to boot?
<mylainos>Thanks everyone, I will search more
<roptat>nckx: you mean hard disk (vs ssd)?
<roptat>in my case it takes maybe 20-30 seconds
<nckx>roptat: Yeah.
<nckx>Wow.
<roptat>from grub to login screen
<nckx>In mine it takes a few minutes. And not two.
<roptat>but then it has to load more things, like icecat takes a few seconds to start for instance
<roptat>and it's loud when icecat loads :)
<nckx>I have a (very hacky no no bad) 'preload' loop in my .xsession to load things like icecat into RAM while I make my coffee.
<roptat>well I don't really have bad load times, so I'm fine
<nckx>But I'm not counting that as start-up time. That's EFI ā†’ opening a terminal window. :-)
<roptat>then count at least a minute cause I can't type my password :p
<nckx>OK, thank you for sharing. That means it might not be I/O-bound (I have a slow CPU) and I shouldn't expect too much from a new SSD...
<roptat>in a laptop with a SSD it takes around 5 seconds to boot I'd say
<nckx>Which rather sucks as I just blew ā‚¬100 on one šŸ˜Š
<roptat>it's definitely faster
<nckx>It will at least give me more battery time. That's valuable too.
<georges-duperon>OriansJ, yrk, nckx: thanks for your answers! It would be nice to have an official stance on recipe licensing somewhere on the Guix website, since as you say it's kinda debatable :-/ .
<nckx>georges-duperon: I agree.
<nckx>Probably a question for the FSF.
<yrk>licensing@fsf.org is the address
<yrk>at least for the licensing side of this issue; of course guix get to make their own policies
<yrk>(I'm one of the volunteers who helps the fsf answer questions at that address, so if y'all write in I'll make sure to hand it off to the right people)
<roptat>weird, I just guix pulled and I get "guix package: warning: Consider running 'guix pull' followed by" when running "guix package -u"
<roptat>the guix I run is in ~/.config/guix/current/bin/guix and "guix --version" shows the version I just pulled
<nckx>yrk: That's an interesting way to volunteer. How's the workload?
<ng0>So the major boilerplate of Buildbot is done. I need to debug some cases, then see how deployment goes, and afterwards I can upstream the entire suite of Buildbot.
<ng0>might even throw in a service depending on when this'll be upstreamed to guix
<cbaines>sounds good ng0! I've never used buildbot, but it's always come up as an alternative to things like Jenkins...
<nckx>'And if you order NOW, ā€¦
<nckx>^ +1
<ng0>hu what? :)
<ng0>cbaines: well I just have to do it Taler as part of my work on migrating them to GuixSD.
<ng0>*for Taler
<nckx>I wanted to +1 cbaines comment without bothering them and guess I royally fucked up.
<yrk>nckx: it requires a few solid hours a week at first but later on (I've been at it over a decade) you end up answering lots of questions relatively fast
<nckx>yrk: Wow. That many questions, huh.
<yrk>nckx: always a backlog, unfortunately. bringing a new volunteer up to speed is hard because it requies a lot of guidance, and so if that volunteer drops out before being able to do independent work you've wasted a lot of effort
<yrk>nckx: no judgement on those volunteers though; everyone has a life to live and their own decisions to make
<nckx>I'll take the hint to heart :-)
<yrk>ah, the infinite subtlety of irc
<rekado>georges-duperon: Guix package recipes are code, and they call procedures provided by the Guix libraries, so in my opinion it is clear that they are a derivative and should thus be under the GPL.
<rekado>but Iā€™m very happy to say that Iā€™m not a lawyer.
*rekado ā€“> zzZ