IRC channel logs

2017-07-07.log

back to list of logs

<Salt>I'm currently compiling Guix to bootstrap Guix and finally got through dependency hell, however, it now is trying to download packages and our HPC's build machine is not net accessible. Is there a way to download-only or somehow skip this step? Thanks!
<rain1>sorry salt there is no way
<Salt>rain1, so there's no way to separate the download stage from the make stage?
<rain1>it needs to get the packages - usually thats via hydra but I believe it is possibel to make a local network node publish the packages
<rain1>I havent done this though
<Salt>v_v
<Salt>I was really hoping our HPC could use Guix, I suppose it's time to look at an alternative, I think someone got a working portage solution
<ZombieChicken>Salt: emerge --fetch-only if you're trying to download something via Portage and only want to fetch it, though I'll be honest that Gentoo isn't the most stable platform
<slyfox>Salt: also, if the bandwidth is not a concern you can mirror whole ebuild tree and distfiles trees: 'rsync distfiles.gentoo.org::gentoo/distfiles'
<civodul>Hello Guix!
<earthfail22>while hello
<earthfail22>civodul: I know it has been a long time (a week or so) but did you figure out what happened with my problem (29/6/2017)
<janneke>i have one machine that fails to download source tarballs when building something:
<janneke>guix build -S hello --no-substitutes --no-build- hook --no-grafts ==>
<janneke>The following derivation will be built:
<janneke> /gnu/store/i6m8qw631n2ddvqhfgr23nd34qrnx446-hello-2.10.tar.gz.drv
<janneke>guix build: error: build failed: directory `/homeless-shelter' exists; please remove it
<civodul>janneke: pretty explicit no? :-)
<janneke>civodul: not really...i finally found how to "fix" it: this patch: http://paste.lisp.org/display/350186
<civodul>janneke: the fix is "sudo rmdir /homeless-shelter"
<civodul>it shouldn't exist
<janneke>wtf? i thought that would be in the build container?
<janneke>sudo rm -rf /homeless-shelter fixes it...
<civodul>the "download" builtin runs outside the container
<civodul>see guix/scripts/perform-download.scm
<janneke>yeah, pretty obvious if you know how to interpret it... *thank you*
<janneke>how did i create this directory?
<janneke>why does guix not remove it for me?
<civodul>are you sure you'd want Guix to remove files for you? :-)
<civodul>perhaps it was created as you were running "guix-daemon --disable-chroot"?
<janneke>well...
<civodul>dunno
<janneke>i guess guix created it for me?
<civodul>looks like it, but i'm not sure how that happened
<civodul>it Shouldn't Happen™
<janneke>i'm confused: the error message is very explicit...but still i have seen /homeless-shelter only in build containers ... so it just escapes me to consider my root file system /homeless-shelter
<janneke>i take the message to mean: "something went wrong with the source download"
<janneke>hmm :-)
<janneke>anyway, thanks a lot, civodul!
<brendos>janneke: I think that homeless-shelter thing comes from Nix
<janneke>brendos: i tried to resurrect hydra and did some nix things...but this has been a GuixSD machine since a year orso
<janneke>weird :-)
<janneke>we've been working to convert the small company i'm consulting for to Guix/GuixSD, very interesting times
<brendos>This is what happens when we let the demon out of it's prison, it's starts meddling in the material world
<janneke>brendos: exactly, i've only seen homeless-shelter inside containers...it never occured to me to look at /
<janneke>ACTION *awareness awareness awareness*
<civodul>janneke: yeah that's why i thought that *maybe* that directory could have been created in a --disable-chroot setup
<civodul>although even that sounds weird
<civodul>weirdness all around!
***Piece_Maker is now known as Acou_Bass
<janneke>civodul: --disable-chroot does not ring a bell...
<janneke>but i'm often very sloppy...
<efraim1>civodul: right now i'm building gccgo@7 with ((#:strip-binaries? _) #f) and then i'll try using that to build leo's syncthing package
<civodul>neat!
<civodul>ACTION takes a look at core-updates
<fr33domlover>Hello
<fr33domlover>Is this the best way if I have 2 machines and I want one to guix build tasks for the other?
<fr33domlover> https://www.gnu.org/software/guix/manual/html_node/Daemon-Offload-Setup.html#Daemon-Offload-Setup
<fr33domlover>*to do
<fr33domlover>Also does it work if one of them is x86 and the other x86-64?
<civodul>fr33domlover: yes!
<civodul>x86_64 in general can be used to build i686 (32-bit) code, but not the reverse
<fr33domlover>civodul, yeah that's my case, the build machine is 64
<fr33domlover>it will just work transparently?
<civodul>yes
<civodul>setup is relatively tedious but "guix offload test" allows you to test it beforehand
<fr33domlover>thanks civodul :)
<efraim>Make sure its 'guix offload test' and not './pre-inst-env guix offload test'
<fr33domlover>civodul, efraim, once I do the setup, when does offload happen? Does the build happen entirely on the target machine?
<jlicht>hello #guix
<adfeno>Hi jlicht :)
<civodul>fr33domlover: yes, builds happen on the remote machine, though some builds are explicitly marked as "non-offloadable"
<fr33domlover>civodul, thanks! I hope those are nothing serious though :
<fr33domlover>:)
<fr33domlover>I have Guix on a thinkpad x60, some builds just take forever
<fr33domlover>and/or get stuck at some point and it's unclear if they ever intend to finish
<fr33domlover>so I want to offload as much as I can to a more powerful machine
<jlicht>hiya civodul o/
<jlicht>you mentioned something on the ML regarding committing to the Guix git repo: I do not have any such rights currently, but it would be nice to be able to push reviewed patches
<civodul>jlicht: definitely, do you have an account on Savannah?
<jlicht>civodul: jlicht is also my account name on Savannah ;-).
<jlicht>ACTION leaves for groceries
<rekado_>Hi Guix!
<rekado>sneek later tell jsierles You don’t have to use old hardware to use GuixSD. You only need to make sure that your hardware is supported by Linux libre.
<sneek>Okay.
<adfeno>I wonder why `guix environment guix` is building Guile 2.2.2...
<civodul>hi rekado!
<jonsger>rekado: that is kind of equivalent...
<civodul>jonsger: i'm using bleeding-edge hardware :-)
<jonsger>civodul: which???
<civodul>an HP laptop
<civodul>i do use an external wifi dongle, but that's it
<lfam>I wonder where people got the idea that linux-libre couldn't boot new hardware :(
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, efraim says: https://www.pine64.org/?page_id=7147 4GB RAM and 64 GB emmc for $75, should be supported by 4.12
<lfam>efraim: That's a pretty good price for the specs, but I wonder if it is designed to handle high loads. I found that many of the cheaper boards are designed without consideration of thermal regulation
<cehteh>lfam: its not the boot, but wireless and other stuff
<lfam>cehteh: Yeah, but for a laptop is typically just the wireless, since they lack esoteric wired networking and I/O interfaces
<lfam>But recently I noticed lots of people claim that linux-libre could only boot old hardware, which is incorrect
<cehteh>yes
<lfam>Now, the wifi is a real blocker for many people, but nevertheless
<cehteh>but still .. i want a normal linux kernel for some netbook i got to have wlan
<cehteh>exactly
<cehteh>sound, graphics sometimes too
<lfam>What sound hardware doesn't work?
<cehteh>but lack of wireless make installation already a pain
<lfam>I hadn't heard of built-in sound cards not working for linux-libre but it would be good to know
<cehteh>some esoteric sound adapters need blobed firmware
<lfam>Yes, the wireless issue is a blocker for many people, like I said
<cehteh>esp some high quality ones, but these are uncommon
<lfam>Professional external sound cards, but not built-in cards, right?
<cehteh>dunno if these are on board on a few boards, i am not that much into hardware
<cehteh>and old times winmodem stuff, using sonudcard as modem :D but we are talking about actual use cases
<cehteh>anyway .. i'd really like if people recognite that free software was meant for the freedom of the people and not the freedom of the bits, thus one may consider to be not *so* hostile against nonfree stuff when people want to use it (its their freedom to do so and its only arguable how much support one may give them, like it or not)
<cehteh>i understand that guix is a gnu project and will never include non-free stuff, but some semi-recognized external non-free repository should be acceptable (i mean talking about and not shunned)
<davexunit>we would never promote such a thing
<cehteh>yes, sadly
<cehteh>well i dont ask for 'promotion'
<davexunit>many people here instead help users locate hardware that is compatible
<cehteh>but some part of the manual about "how do i add some foreign repository into my guix installation" .. not promoting a non-free directly would be nice
<davexunit>oh we have that
<davexunit>we explain GUIX_PACKAGE_PATH
<cehteh>locating hardware isnt always a solution, there are countless old pc's and unused notebooks around which could be given away with a guix installation for example
<davexunit>which is the current mechanism.
<cehteh>yes
<cehteh>but if someone tries to lift of some 'non-free' repo he usually gets a lot critism and blame, instead 'just do, we dont care'
<cehteh>not from the core devs but from some community people
<adfeno>cehteh: Well... That repo could exist, but people would probably not get support from #guix or Guix project directly, not because there wouldn't be people to do so, but because we cannot foster it.
<cehteh>ACTION remembers the duscussion around 'mame'
<adfeno>foster (recommend/install/teach-usage/sell/share)
<adfeno>cehteh: What about MAME?
<adfeno>If I'm not mistaken, MAME is free/libre, at least if we take into account itself, not what it's used for.
<cehteh>thats long ago, someone wanted to have it removed because it may run non free games
<cehteh>it was resolved sanely, but just that thought, that someone thinks he can mandate other people what they should and should not do is restricting freedom
<rain1>yeah I totally disagree with that
<rain1>MAME is 100% free software
<rain1>just look at the definition of free software
<cehteh>i was tempted to post a © cehteh, all rights reserved bash snippet to the ml, and then asking for removing bash .. and deleting the ML because anyone who would reply could distribute my source unathorized :D
<cehteh>i understand that, but some done
<cehteh>dont
<adfeno>We agree that MAME is free/libre software, but one thing that we must be careful is: avoid fostering usage of MAME for using non-free software.
<adfeno>The only reasons for which the free/libre software movement agrees on keeping emulators, simulators, virtualizers, is both: (a) because their source files are free/libre (and the build can be done through free/libre software by default), (b) and because it's assumed that these are useful for *developing* free/libre software for the emulated/simulated/virtualized thing, or that the simulated/emulated/virtualized thing can be used to
<adfeno>understand how the non-free parts work and allow the interested person to develop replacements.
<cehteh>well i hate when the free software movement becomes a cult which is hostile against any other believers, freedom is/should be for the people and tolerance is a very important part of that.
<davexunit>I don't think there is any intolerance here.
<cehteh>note that i am (almost) only using free software since 20+ years
<cehteh>somewhere there is, but i am out biking now bbl
<davexunit>cehteh: re: the MAME thing, the person that asserted that MAME was non-free was not a core developer, and all core developers agreed that MAME was free.
<davexunit>we can't control other people that go overboard, but as far as devs close to the project I think they are all very level-headed about this.
<cehteh>he didnt assert it was non free iirc, he only asserted it promotes use of non free software (because it can emulate those games)
<davexunit>yeah, that's more accurate.
<cehteh>and yes i am happy that the core devs dont have this attitude, because i think its very dangerous
<cehteh>of course you cant and should not control others
<cehteh>well i am off cu
<davexunit>bye!
<rain1>>avoid fostering usage of MAME for using non-free software.
<rain1>The freedom to run the program as you wish, for any purpose (freedom 0).
<rain1>libre linux distributions can pick and choose the software they want to include, but freedom 0 is very clear
<adfeno>rain1: Yes, but once lots of people in the support resources of the distro start saying to other pople to "use MAME to do this", then perhaps we have ap roblem.
<adfeno>rain1: Or if they start telling people to "use MAME to run your favorite non-free games".
<janneke>adfeno: please do not advice or hint about running non-free software here
<adfeno>janneke: Indeed, don't worry.... I was just making examples of what some people started doing on some other free/libre software related support resources (mailing lists, IRC, forums and such). I'm not the one fostering such things.
<lfam__>"gnu: groff: Remove dependency on netpbm." Thank you!!!
<lfam__>efraim: FYI, I moved my syncthing package from a branch of the Guix Git repo to my 3rd party packages repo: https://github.com/lfam/pkgs/commit/897196d14b34dc29f0a57ea42489d4de17dc9b1d
<Salt>ZombieChicken, slyfox thanks for the tips, but I'm not hoping to use Gentoo or Portage, I'm hoping to use Guix, just know that's my fallback v_v
<rekado>Did I say here already that I installed GuixSD on Sun servers without problemse?
<rekado>*problems
<rekado>Linux-libre supports all the hardware I use on these servers.
<rekado>I also find it very strange to hear claims that Linux libre is not okay for new hardware.
<rekado>is this disdain for deblobbed Linux or is it a way too dark outlook on the current state of blob-free hardware support?
<rekado>on the topic of proprietary software: it’s not immoral to *use* non-free software.
<rekado>but this project is all about building the GNU system, so our goals are to do without proprietary software and to help people get a usable system without non-free parts.
<davexunit>my last 2 laptops I've been able to operate without blobs
<rekado>when we make it a habit to discuss how to install vanilla Linux or how to get this or that nonfree thing to work we may cause others to give up on getting rid of nonfree software.
<rekado>for me this is a bit like dieting when colleagues bring cakes to the office
<rekado>this is a space for building a fully free operating system; we won’t recommend another specific venue for discussing partially free operating systems using Guix.
<rekado>I also feel I should say something about using the term “cult” in reference to the free software movement.
<rekado>while the term was used in what looked like a warning and not as a description of what the movement is, I think it should not be used lightly.
<rekado>why? Because it is often used in propaganda against the free software movement, along with the terms “viral” for the GPL and “unusable” for linux-libre.
<ZombieChicken>Salt: Well, since apparently what you're wanting to do can't be done (file a bugreport/feature request for it if you want), I thought I'd share that little tidbit
<adfeno>rekado: if your recommendation is against using the term "cult": I agree. :)
<adfeno>I also find it misleading.
<Salt>ZombieChicken, thanks for the tip, will do that as able, need to get an alternate source management system in place before a trip in two weeks
<ZombieChicken>rekado: Linux Libre is unusable if you are on a modern nVidia chipset and need the 3D acceleration, just FYI. That's why my desktop is running Gentoo
<Salt>it is pretty odd that compiling a package requires network access
<ZombieChicken>Not at all; you have to download the source to build it, or download the prebuilt package. It's a little weird that you can't fetch that seperatly imo, though
<ZombieChicken>rekado: just FYI, the noveau nVidia driver doesn't work with the DDR3-memory boards; it can't change the clock setting, so you're running it at a very slow speed. Just so you know one reason why Linux Libre isn't usable in that specific case
<davexunit>yes but there is plenty of hardware that does work with linux-libre
<davexunit>nvidia is well established as a terrible company to get hardware from.
<paroneayea>heya
<paroneayea>if I've stored the root of a profile somewhere
<paroneayea>how do I re-enable it again?
<paroneayea>from bash
<paroneayea>?
<paroneayea>I think there's a profile object or something I'm supposed to source
<paroneayea>I'm going on a hack-trip in the woods with no intarwebs and I want to "bring my environments with me" ;)
<paroneayea>oh!
<paroneayea>etc/profile
<davexunit>I couldn't remember but yeah! that's it
<ZombieChicken>davexunit: Yeah. but it's still an issue and a reason why the Libre kernel won't work in some cases. If there is a reason someone /has/ to use that hardware (I'd imagine some laptops would likely fall into this category, or hardware someone can't upgrade for whatever reason), the Libre kernel is entirely unusable.
<ZombieChicken>which reminds me, I need to find out if Radeon chips have the same problem
<davexunit>and that's unfortunate, but linux-libre isn't the problem
<ZombieChicken>Actually, the bug where it can't load firmware is the problem
<davexunit>it's the hardware that is unusable!
<ZombieChicken>I disagree.
<davexunit>well that's the position of this channel.
<davexunit>getting people to use proprietary drivers is not our goal.
<ZombieChicken>So, does disk encryption work for Guix? I thought it did, and I can get GRUB to unlock the drive, but apparently it can't find a partition after booting...
<rekado>ZombieChicken: are you using Libreboot?
<ZombieChicken>rekado: Nope
<quigonjinn>ZombieChicken: did you run 'guix pull' before 'guix system init ...'?
<rekado>I’m using full disk encryption with Libreboot.
<ZombieChicken>quigonjinn: Yes. I may have missed a (dependency ...) in the (file-system ...) list.
<quigonjinn>ZombieChicken: yes, probably. There was an issue in 0.13, but it should be fixed if you run 'guix pull'
<ZombieChicken>Yeah. Given GRUB was able to boot the system, I think that's a pretty good indication that things are fine and there is just a small problem. I just hope I won't need to reinstall the system and take another 10+ hours of compiling
<quigonjinn>ZombieChicken: BTW, it is possible to reclock some Nvidia GPUs with linux-libre, namely most of the Kepler series.
<adfeno>I take that I agree with both ZombieChicken and davexunit on the Linux-libre issue. I disagree to arguments about it "being usable only on old hardware". But I think part of the problems are related to that firmware loading bug, and also due to the fact that the hardware itself is to blame.
<adfeno>ZombieChicken: Having seen a friend of mine test what quigonjinn said, and seeing the Feature and Compatibility matrixes of Nouveau, I agree with quigonjinn.
<ZombieChicken>It's entirely possible they got things to work with newer GPUs since I last checked with them
<quigonjinn>I am actually having my GPU reclocked on GuixSD atm
<ZombieChicken>I didn't keep up because I figure the better option would likely be Radeon
<jonsger>ZombieChicken: radeon has FOSS driver, but propetary firmware which isn't include in linux-libre
<davexunit>I returned a new radeon card for this reason
<davexunit>everything I had was like "yeah it's all free now!" so I ordered one
<davexunit>s/had/read/
<paroneayea>the nice thing about using guix
<paroneayea>I can pack up all my profiles for hacking before the trip
<paroneayea>I guess I should pack my *real* things now ;)
<davexunit>paroneayea: that's a really nice property that I hadn't really thought about before
<davexunit>I will be taking a train trip in august and I don't want to rely on spotty Amtrak wifi so I should pre-bake all my profiles before I go
<paroneayea>davexunit: :D
<paroneayea>you helped build a thing and you haven't even realized its full power ;)
<paroneayea>guix environment ftw
<paroneayea>ACTION ... we need an ftw package ;)
<davexunit>lol
<paroneayea>I am enjoying this Mastodon/fediverse thread btw
<davexunit>'guix environment' is still missing the thing to make this workflow easy. a way to easily save the env
<davexunit>and restore it. which would essentially just do what you are doing manually.
<paroneayea>davexunit: yeah there's --root which saves it but
<paroneayea>yeah and you also want per-environment generations
<davexunit>and yeah, this is the best mastodon thread I've seen yet.
<paroneayea>and ideally, emacs environment :)
<paroneayea> https://toot.cat/users/dthompson/updates/36745
<paroneayea> here's the thread for the curious :)
<davexunit>hoo boy that's a longer thread than I thought
<davexunit>I did block someone, though
<paroneayea>lol
<paroneayea>too bad that conversation doesn't display threading
<paroneayea>there's a whole bunch of subthreads happening in there
<davexunit>yeah I was just wishing it could do that
<davexunit>someone will write that... someday...
<paroneayea>StatusNet (GNU Social) can technically do it
<paroneayea>that was *the default* on identi.ca back in the day
<paroneayea>then in statusnet 1.0 they turned it off by default!
<davexunit>2 steps forward, 1 step back!
<paroneayea>but they allowed people to re-enable it in your profile because there was a user outcry
<lfam__>Do we have a video editor packaged that I could use to cut a video into parts?
<lfam__>Ideally something not too hard to learn...
<paroneayea>lfam__: I was about to say Blender before that last message :)
<lfam__>Heh, I'd rather not become a professional video editor to remove the shaky beginnings and ends of my vacation videos
<paroneayea>:)
<paroneayea>lfam__: if you're just time-splicing it
<paroneayea>ffmpeg has commands for that via the command line
<paroneayea>I hear kdenlive is well regarded as being easy but I don't see it packaged
<lfam__>I wonder how close we are to packaging that layer of KDE
<lfam__>iMovie was perfect this use case
<paroneayea>ACTION debates whether or not to remove and gc away crawl-tiles before going on this trip...
<paroneayea>a real time sucker :)
<rekado>I used Blender’s sequence editor for that. It’s almost separate from the rest of Blender. I still don’t know how to do 3d animation, but I remember video cut with Blender to be pretty easy.
<adfeno>I occasionally do some video editing with Blender,
<adfeno>I avoid 3D animation entirely because, thanks to nVidia, Nouveau puts rendering to the CPU; :S
<adfeno>I spent 4d trying to render an animated 5s scene of simple 7 letters being "shot" towards a cement wall as a light beam passed through.
<lfam__>rekado: You think I can figure it out? :)
<fr33domlover>Q: I run Guix on trisquel, I copied the upstart init script to /etc/init like the docs say
<fr33domlover>So to update guix, I run guix pull as root and then do that copy again?
<lfam__>fr33domlover: You should not need to copy that file again
<lfam__>What does the 'exec' line of the file say?
<fr33domlover>lfam__, exec /gnu/store/9nw4zglfl1dc8zc00rikkvln4kgjify9-guix-0.11.0/bin/guix-daemon --build-users-group=guixbuild
<fr33domlover>I've been trying to guix pull, no luck so far
<fr33domlover>to update from 0.11 to 0.13
<lfam__>I see. The exec line should read "exec /var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon --build-users-group=guixbuild"
<lfam__>We fixed this bug since 0.11
<fr33domlover>lfam__, yes I know you did, I saw :)
<lfam__>To update Guix itself, run `guix pull && guix package --upgrade .` The '.' character is regex to match all the installed packages. It's necessary if you pass other flags to the command
<adfeno>Now I wonder, what was done in order for the users of 0.11 to fix it? ...
<lfam__>adfeno: They should change the line as I suggested
<lfam__>fr33domlover: What happens when you try to run `guix pull`
<lfam__>?
<fr33domlover>lfam__, I'll try again in a bit and check what happens
<lfam__>fr33domlover: It's possible that you will not be able to pull directly from 0.11 to 0.13. You may need to do it in two stages. If so please paste the error messages on paste.lisp.org and we will try to help.
<rekado>lfam__: you’d have to get past the initial confusion of using Blender. And I remember that exporting video sequences was a bit more work than I liked.
<lfam__>rekado: But I should look into the blender "sequence editor"? I didn't even know where to start, but if I have some words to look up, I should be able to get there :)
<rekado>lfam__: (disclaimer: I’ve last done this 4 or 5 years ago)
<rekado>lfam__: here’s the documentation for the sequence editor: https://docs.blender.org/manual/en/dev/editors/vse/index.html
<lfam__>Thanks rekado, this will help me get started :)
<adfeno>Yes, Video Sequence Editor is the video editing area for Blender.
<rekado>there are some tutorials out there, but many that I’ve seen look like they are based on an older version of Blender.
<adfeno>Indeed.
<rekado>I’m confused about the license of “Beneath a Steel Sky”
<rekado> http://metadata.ftp-master.debian.org/changelogs/main/b/beneath-a-steel-sky/beneath-a-steel-sky_0.0372-4_copyright
<rekado>it’s in debian
<rekado>but point 3 looks like it disallows certain kinds of commercial usage
<rekado>wouldn’t that make it non-free?
<adfeno>rekado: Beneath a Steel Sky's license seems to be similar to SIL OFL.
<fr33domlover>lfam__, I got this, idk if related to the version issue: guix pull: error: build failed: build of `/gnu/store/65q1hfkfw323q6kv6z8fr0jbrd3wd704-guile-ssh-0.10.1.drv' failed
<adfeno>SIL Open Font License
<lfam__>Does anyone know which commit to pull from to avoid the guile-ssh issue?
<lfam__>rekado?
<rekado>I don’t know this issue
<rekado>sorry
<adfeno>I know that issue, although I don't know the exact commit....
<adfeno>rekado: If I'm right, the guile-ssh issue affected `guix pull` and migration from Guile 2.0 to 2.2. Although I might be wrong on this.
<lfam_>rekado: That license sounds fishy: "You may not charge a fee for the game itself." "You may charge a reasonable copying fee for this archive"
<rekado>yeah
<lfam_>A free license would not restrict the sale or say vague things like "reasonable"
<lfam_>But, I'm not an expert.
<adfeno>lfam_ rekado: see [[https://www.gnu.org/licenses/license-list.html#SILOFL]].
<lfam_>Huh
<fr33domlover>How does Debian handle it?
<fr33domlover>That game is in debian iirc
<fr33domlover>(in the main free repo)
<rekado>yes, I know. That’s why I’m confused.
<lfam_>Like I said, I'm no expert. Sometimes these issues are counterintuitive
<fr33domlover>Licenses, such a silly terrible invention, everything should just be free ^_^
<rekado>fr33domlover: can you tell me *how* the build of guile-ssh failed?
<rekado>commit 75c260ba5ae7baec44d2b5bf6ae57734eeebcd2f updated guile-ssh to version 0.11.0
<fr33domlover>rekado, one of the tests failed. But I run guix pull again, it's still runnning, I think it passed this time
<lfam_>Maybe that's the relevant commit
<lfam_>Is there a way to search the #guix logs on gnunet.org?
<lfam_>I think efraim gave the commit here: https://gnunet.org/bot/log/guix/2017-06-30#T1433159
<lfam_>As rekado suggested, if it fails again, try `http://git.savannah.gnu.org/cgit/guix.git/snapshot/75c260ba5ae7baec44d2b5bf6ae57734eeebcd2f.tar.gz`
<lfam_>fr33domlover ^
<lfam_>Sorry, I'll clarify
<lfam_>Try this:
<lfam_>guix pull --url=https://git.savannah.gnu.org/cgit/guix.git/snapshot/75c260ba5ae7baec44d2b5bf6ae57734eeebcd2f.tar.gz
<lfam_>Then, you should be able to do `guix pull` to get the latest
<fr33domlover>lfam_, thanks it already worked :)
<lfam_>Okay, good!
<fr33domlover>yeah lucky ^_^
<fr33domlover>thanks for the help :)
<lfam_>By way, I'm curious about people still using 0.11.0 or other old versions. Had you just left this system alone for a while, or where you still using it at that version?
<lfam_>Recently I got worried that many people were not upgrading, so I've been trying to find out why and make it more likely that they will upgrade
<fr33domlover>lfam_, tbh I never did guix package -u until a few days ago and it got stuck at some point / slow / idk if it woulf work ^_^
<fr33domlover>but yeah been using guix for months without upgrade
<fr33domlover>lfam_, how about some automatic script to check for updates? etc. much like APT has one in debian?
<lfam_>I get concerned about people that don't update because we fix large numbers of remotely exploitable bugs in the packages
<fr33domlover>a cron job etc. or some reminder telling you if there are upgrades
<lfam_>Recent versions of Guix will warn you if you are using an older version
<lfam_>`guix pull` is relatively computationally expensive, so I don't think we'll make it update itself automatically be default, but maybe we could create a service for GuixSD that users could enable
<fr33domlover>lfam_, even just notify the user there are updates
<fr33domlover>and they can run guix pull if they wish
<lfam_>Right, that's the new feature I mentioned
<fr33domlover>:)
<lfam_>Since there are always updates, it's based on the time elapsed since the last update
<fr33domlover>I tried GuixSD on a home server but discovered there's no LVM
<fr33domlover>so can't encrypt the disk properly
<fr33domlover>But I really want to use it :)
<lfam_>Yeah, we need an LVM champion to implement this!
<reepca>Why isn't guix itself substitutable?
<rain1>I have an idea for guix
<oriansj>what is the idea?
<adfeno>Hm.... reepca has a good point :)
<fr33domlover>lfam_, I'm far from that but I'd do it like this: (1) expand the partition config to allow for more partitions and encryption and LVM volumes etc. (2) check maybe how debian reads that data and actually makes the partitions and updates the cryptttab etc. and do it similarly in GuixSD ^_^
<rain1>I don't know if this is possible, someone vwould need to sanity check this
<rain1>but splitting guix repo into 2 things, the guix demon and tool and then separately all the packages
<Leo`>Is it possible to reconfigure on the live installation system? I'd like to start a few services to check that some things work before installing.
<rain1>and the benefit (potentially) would be to build guix much much faster
<lfam_>rain1: It's been suggested but many of the Guix developers would prefer to develop them together without having to maintain an API between them
<rain1>ah nevermind then
<lfam_>The packages themselves and the supporting code are very intertwined, and it's easier for us to develop them together. A similar model to Linux kernel + drivers
<lfam_>But of course, there are benefits to splitting them up, too
<lfam_>But, check out the discussion of "channels" and "guix potluck" on the mailing lists for some potentially related discussion
<oriansj>splitting them up forces consistency and stability but slows down development
<rekado>there are ideas to make parts of Guix substitutable, but for the time being “guix pull” remains special
<rekado>ACTION –> zzzZ
<lfam_>ACTION also has to go
<lfam_>later!
<Leo`>Anyone using ModemManager on Guix?
<fr33domlover>Q: What if I use Guix on top of Devuan (running the default sysvinit?), is there an init script for guix-daemon for me to use?