IRC channel logs

<pkill9>Guix generates so much waste xP

<pkill9>harddrive space is cheap though so is all good

<OriansJ>pkill9: Guix isn't the cause of the dependencies but rather the vehicle allowing us to realize the insane graph of dependencies that our most important applications have.

<pkill9>yes this is true

<OriansJ>The good news is now that any developer can do: guix graph -t bag-with-origins slim | dot -Tpdf >| dag.pdf and see exactly what they depend upon. They might just help us fix this mess.

<OriansJ>although I must admit, I find it hard to reduce the number of dependencies in my own packages guix graph -t bag-emerged mescc-tools | dot -Tpdf >| dag2.pdf

<OriansJ>Although I understand mescc-tools might end up creating a feature request for guix to select alternate build paths depending on currently available binaries.

<pkill9>guix makes large dependency graphs manageable

<pkill9>atleast

<pkill9>i love how dependency graphs are isolted from eachother, i know i'm preaching to the choir, but it's great :D

<pkill9>isolated*

<OriansJ>Understandably, they provide perspective and reverse-package comes in very handy at times

<ng0>what is the last good commit before 8d0edc8246389c0f2bb1c8e9c9190c312746a4b4 ? Trying to update an 0.14 installation

<ng0>this one seems to have issues with numpy

<ng0>I should grab b617a9fe239ea645c816d6afcb81d5476f760d84 if it fails again

<civodul>Hello Guix! :-)

<catonano>hello civodul !

<sneek>catonano, you have 1 message.

<sneek>catonano, rekado_ says: The SELinux policy is now part of the repository.

<catonano>sneek later tell rekado re SELinux in thhe repository: ohh my ! Thank you !

<sneek>Okay.

<catonano>has anyone built guile on GuixSD ? I'm having this error ld-wrapper: error: attempt to use impure library "/home/catonano/guile/lib/libguile-2.2.so"

<civodul>catonano: try "export GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yes" :-)

<civodul>we've been meaning to change that

<catonano>civodul: thanks, I'll try

<catonano>it worked. Thanks

<ng0>cool. You can now install GuixSD on DigitalOcean from within Debian with not very much changes and interaction in the DO Panel.

<ng0>I might write a Guide on this

<efraim>Cool

<efraim>I was going to try on scaleway at some point since they have armv8 machines

<ng0>I have some ISPs I'd like to try once I have more money

<ng0>I mean, I have details on them and they need experimentation

<ng0>like OrangeWebsite uses something I didn't know, very large

<ng0>1984 is pretty straightforward Debian->GuixSD

<ng0>a while back they said they'd like to offer ISOs of GuixSD when it's possible

<ng0>I found that in addition to what Wingo wrote in April you also need to copy back the old /etc/guix directory for the ACLs. this is what I missed in my own guide I wrote in early 17 I think

<efraim>I almost have GuixSD booting on the pine64, just need to work out some boot and graphics stuff I think

<efraim>It would certainly help if I added the openssh service to my image

<ng0>well this is new:

<ng0>guix pull: error: mkdir: Permission denied

<ng0>ah, permission issues in $home

<ng0>does someone have any advice on getting gitolite together with git-daemon running on GuixSD? It's been a while since I've set this up with Debian

<ng0>in Debian gitolite is a user.. so I guess some combination of setting up a new user, symlinking to /srv/git for the repo dir, etc

<ng0>which could easily become a new small service in Guix

<ng0>got it. easy.

<ng0>well.

<ng0>remote: Can't locate Data/Dumper.pm in @INC (you may need to install the Data::Dumper module) (@INC contains: /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib /home/git/.guix-profile/lib/perl5/site_perl /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24

<ng0>/usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib/Gitolite/Common.pm line 65.

<ng0>I don't think my gitolite should install perl + perl-data-dumper-concise and still fail this

<ng0>*gitolite user

<ng0>oh, this is https://debbugs.gnu.org/db/25/25957.html all over again

<ng0>meh. "fixed" by creating a special file service with /usr/bin/perl

<pch>Hello Guix, How can i completely remove a package from the store and enforce download at each installation?

<civodul>pch: you could run "guix gc -d /gnu/store/...-the-thing"

<civodul>however, you cannot really force it to be downloaded at each installation

<civodul>what are you trying to achieve?

<pch>i just want to write a service which triggers an installation & download of a certain package

<civodul>hmm ok

<civodul>the key idea here is that downlading/installing now will give exactly the same result as downlading/installing tomorrow or next week

<civodul>bit for bit

<civodul>so there's no value from a Guix perspective in forcing downloads and such

<civodul>which is why i'm curious :-)

<pch>I understand

<pch>what if the next version is available? That means i have to always install a package with its specific version?

<pch>and i guess when the newer version is not available, it should be downloaded

<pch>is my understanding correct?

<ng0>you can create local variants

<ng0>so you have a folder with a module, or just a module file and in there you have a package definition which inherits from the original one

<ng0>replacing version, hash etc

<ng0>I could link to examples, but my server is still not back up

<ng0>oh, O forgot I dual-push some of it to github

<ng0>for example: https://github.com/ng-0/packages/blob/master/ng0/packages/personalized.scm#L62

<ng0>such a collection of module files in the 'GUIX_PACKAGE_PATH' makes sense if you have more than just one package to modify

<pch>ng0: as i understand you still mean to have 1 variant per version right?

<ng0>more or less... https://github.com/ng-0/packages/blob/master/gnunet/packages/gnunet.scm could include different versions of the same package definition. it doesn't, but that's how the foo@1.2 and foo@2.3 etc work

<ng0>you have a public exported variable (package) named "linux-libre", but also "linux-libre-4.14", and you can install (don't install linux-libre this way.. bad example) the 4.14 by using linux-libre@4.14

<ng0>you are free to name those variants whatever.. you can only interact with 1 version in 1 definition

<pch>ok, but i still wish to delete old variants of certain packages from store somehow (in an automated manner)

<pkill9>how do i add all the tools that gnubuild-system imports, to `guix environment`?

<pch>ng0, civodul

<pch>i do not want to keep all the old versions on my device, the idea is that if a certain version is not present on the device, it may be downloaded

<ng0>unreferenced variants can be garbage collected

<pch>ng0, civodul: the space is limited on the device

<ng0>this can be acieved by a cronjob

<civodul>ACTION tests the offload fix on berlin

<pch>ng0, civodul: how for a certain package?

<civodul>pch: in that case, like ng0 writes, i'd run 'guix gc' periodically

<civodul>and then whatever needs to be redownloaded will be redownloaded on demand

<roptat>hi guix :)

<civodul>hi roptat!

<mubarak>hi roptat :-)

<civodul>good to see you again :-)

<pch>ng0, civodul: would this remove all the old versions of all the packages?

<roptat>I have a package and a service for https://framagit.org/Deevad/cat-avatar-generator, but they don't do much. Is it still OK to push them to Guix?

<pch>hi roptat!

<civodul>roptat: if it's useful to you, it may be useful to others :-)

<civodul>so i'd say send it to guix-patches

<roptat>ok, I will do that

<civodul>pch: "guix gc" removes things that are provably unused, see https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-gc.html

<pch>civodul: i have read that, but what does unused mean here/

<ng0>neither part of your profile, system-profile, or any existing system-generation

<pch>civodul: unused means history of all the installed packages?

<civodul>it means that neither ~/.guix-profile nor /run/current-system/ nor any running process refers to it

<civodul>remember that there can be several "generations" of a profile

<civodul>so if a package is present in a previous generation of your profile, it is still considered to be "used"

<civodul>it cannot be deleted

<pch>ng0, civodul: pls take into consideration that i am not using guixSD

<civodul>noted, but the principle is the same

<pch>ng0, civodul: if i have to keep only the last version of the installed package, then wouldnt it still be part of the profile?

<civodul>not sure what you mean

<civodul>essentially, you choose what you want to keep

<civodul>for instance, you can choose to always delete generations older than 1 month

<civodul>in which case, packages that were in those generations can potentially be deleted

<amz3>roptat: awesome package

<roptat>amz3: the author of this package is the author of Pepper and Carrot: https://www.peppercarrot.com/

<ng0>TIL: when you switch the primary group of a user in GuixSD the files in their $home get recursively regrouped

<ng0>*group adjusted

<pch>civodul: trying to put it another way, which command should i use to just keep the last version of all the installed packages i.e. as soon as i install a new version, i am able to remove the previous version

<ng0>pretty cool, I thought I have to do it manually

<pch>civodul: is it somehow better to understand?

<pch>civodul: ok how do i choose what i keep, on a package level?

<amz3>roptat: I thin I saw that artwork featured on krita website

<civodul>pch: you simply choose when to run "guix package --delete-generations", for instance

<civodul> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html

<pch>civodul: yes i just found that "guix package -d", removed all generations excluding the installed

<pch>civodul: is this also possible for a single package?

<rekado_>pch: if you keep each package in its own profile: yes.

<sneek>Welcome back rekado_, you have 1 message.

<sneek>rekado_, catonano says: re SELinux in thhe repository: ohh my ! Thank you !

<pch>civodul: ignore my question. I got it. Thanks

<pch>rekado_: right!

<amz3>sorry for the empty mail, on the mailling list, I sent another mail some content

<amz3>Does guix already distribute 'data' packages?

<amz3>another +with some content

<amz3>ref: http://lists.gnu.org/archive/html/guix-devel/2018-02/msg00177.html

<amz3>fwiw, I might have financial support to work on that project ^

<roptat>amz3: in games, there's 0ad and 0ad-data

<ng0>amz3: a while back there was a threat about the tor location thing

<ng0>GeoIP.. MaxwhateverDB

<ng0>Pjotr mentioned something back then I think

<pkill9>i don't think mono is beign configured to look for libraries in the store, is that intended?

<pkill9>eh nvm, i'm probably misunderstanding mono

<amz3>what is appropriate storage mechanisms.

<amz3>?

<amz3>wrt civodul reply on the mailling list

<g_bor>Hello guix!

<vagrantc>ACTION waves

<vagrantc>with the "hifive unleashed" coming, wondering if anyone has mentioned working on a guix port

<g_bor>yes, I did.

<g_bor>ng0 also did.

<g_bor>It was considered as aGSoC proposal, but later determined that it does not fit the framework well.

<g_bor>Currently I am waiting for glibc 2.27 to land on core-updates, which will most probably happen only after the merge.

<ng0>g_bor: I thought about opening a bug to track resources and work on this rather long project.. or share what I already found out

<vagrantc>very cool

<vagrantc>seems lacking in storage, though, which might be challenging for guix

<ng0>first work on a port to RISC-V wouldn't involve hardware

<vagrantc>bootstrapping cross-compilers? seems like much of the upstream core build toolchain is there

<ng0>btw, gitolite is working now with a hack. Not that the original problem is solved, but it's working for me

<mbakke>Is there a grep-like utility that can try different decompression methods on the input stream?

<pkill9>what's 'hifive unleashed'?

<vagrantc> https://www.sifive.com/products/hifive-unleashed/

<pkill9>why is it a 'revolution' as they claim?

<pkill9>i don't know anything about RISC

<cehteh>open source chip design

<cehteh>which recently got some drive, few real implementations become available

<ng0>"Indeed. RISC architecture is gonna change everything."

<ng0>:D

<g_bor>mbakke: I don't know about a ready made one, but you can try choosing a decompressing cat based on extension, if that suits your use case.

<pkill9>so i'm guessing there's no completely open-source system-on-a-chip, and this is the first one that's completley open?

<vagrantc>pkill9: that's the part to be excited about ... although there may be some components not so open

<vagrantc>and maybe actually fast enough to be useful

<pkill9>aren't most boards also almost completely open, e.g. raspberry pi is open except the bootloader/boot firmware (don't know much low level stuff), so when you say 'not so open', how open do you mean?

<vagrantc>pkill9: the raspberry pi isn't open at all

<pkill9>oh ok

<vagrantc>pkill9: the processor is licensed by ARM and closed, the GPU is closed ... don't think there is enough published information to buy all the parts and manufacture a clone

<pkill9>ah ok then i was completely wrong heh

<vagrantc>a more interesting comparison would be against the beaglebone black or something :)

<ng0>pkill9: bunny did a great talk, I should look upo the recording.. about the misconceptions software hackers have about hardware hackers and how difficult "just" open source hardware is

<vagrantc>where the docs for the hardware are published, and you can manufacture your own variant

<vagrantc>but still, ARM CPU not open, i think the GPU not open as well

<ng0>*bunnie

<pkill9>ng0: do you take requests for your custom guix repository?

<ng0> https://www.youtube.com/watch?v=zXwy65d_tu8 not sure, might've been this.

<pkill9>was that at FOSDEM?

<ng0>no

<ng0>no to the video

<ng0>I take pull requests and patches.. requests, yes.. I have some delay for packaging though

<ng0>right now I'm still restoring my server.. it's not primarily on github

<pkill9>i'm not sure if what i want is possible, but what i want is a package definition just for Qtwebengine, so it doesn't take a day to build. I thougth since Qtwebkit is a separate package, qtwebengine can be as well

<ng0>without yt: https://riscv.org/wp-content/uploads/2017/05/Wed1100-impedancematch-huang.pdf

<pkill9>it's explicitely disabled from the Qt build for security reasons it seems https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/qt.scm#n122

<ng0>uh... short answer: not doable for me in a time anyone would be happy with atm. But I reme,mber that I have it somewhere, or a depdenency which required qtwebengine

<ng0>it -> a start of it

<ng0>qtwebengine is a monster + we had some issues because of chromium in it and I'm not reading through that big thread

<pkill9>oh ok

<ng0>unless someone gives me a tl;dr about it I'm not diving into the chromium inside qtwebengine and kde is bad for doing it discussion again.. for Guix. outside of Guix as my personal projects I do lots of things.

<ng0>but really, it's huge

<ng0>oh wait.

<ng0>let me take a note on this and give you a reply after exams and after today (bad day).

<pkill9>ok thanks

<ng0>ok :)

<ng0>but seriously: what was the conclusion, if any, with the Qtwebengine thread and KDE?

<ng0>pkill9: I think I had quzilla depending on Qtwebengine at some point in its graph what feels like at least 12 months ago

<ng0> https://github.com/ng-0/guix/commit/d60fa24d59038f5f3dc22bb971cc08e84f9d988a yep

<pkill9>yeah Qupzilla uses webengine, qutebrowser also does which I want to package with guix

<ng0>big browser are nasty.. it's fun because they are challenging.

<ng0>or can be

<pkill9>ng0: this is the only webnegine-related thread that shows up in search, it doesn't mention KDE though https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00722.html

<pkill9>it's also from jully 2015

<pkill9>july*

<ng0>I can't really hand links out as I just have everything offline, but there was a lengthy thread with lots of annoying crossposting

<ng0>I'll search the date and subject

<ng0>Subject: [libreplanet-discuss] QTWebengine is nonfree - january 2017 - on at least libreplanet discuss

<ng0>I think it went beyond the 33 results I get.. but 33 wouldn't be that bad. It's still much to read through

<ng0>there've been some follow-up threads

<ng0>looking at the ebuild (Gentoo) of qtwebengine, I remember that (back then) some more Qt modules were missing

<ng0>but I think that'S all I can do now.. doable yes, gigantic piece of work, yep.

<jackhill>speaking of browsers, I'm starting to, slowly, work on packages of Next https://gitlab.oit.duke.edu/jackhill/guix-packages/blob/master/next-browser.scm

<jackhill>It uses WebKitGTK which seems to be fairly well maintained.

<jackhill>I'm less certain about some of the Lisp dependencies as at last two of them will probably have to be build from a snapshot and not a release.

<ng0>well it'S okay as long as it works

<jackhill>indeed. And continues to work. I'm optimistic that it will.

<snape>I wonder what is the best, as a certbot interface for multiple domain certificates: space separated strings (wouldn't change the interface), or list of strings (would change the interface). I tend to prefer the second, but users will have to change their config.

<civodul>snape: i'd prefer the second as well

<civodul>we could explicitly check for 'string?' to support the previous configs

<snape>indeed, but I wonder how many people use the service. Is it worth it?

<civodul>actually the 'hosts' field is already documented as a list of hosts

<civodul>or am i missing something?

<snape>yes, but right now 1 host = 1 domain. I want 1 host = n domains

<ng0>I assumed that a list would be aceptable

<ng0>that it's not many hosts is news to me

<snape>host is in fact the certificate name

<ng0>On breaking service configs: you can notify people in advance through the mailinglistlist with a message that has comprehendable information in the subject and body.

<snape>to make it simple, I want to change ("host1" "host2") into (("domain1" domain2") ("domain3" "domain4")). Only domain1 and domain3 would be certificates names.

<snape>ng0: yes good idea

<ng0>an mbox feature for Guix I proposed a long time ago and I think it was rejected or ignored.. "hey, here's what will break in n weeks, please read this to not have to read the git log"

<ng0>like the portage news

<civodul>snape: oh got it

<civodul>snape: well i guess you could submit the change, and it may be ok to do without backward-compat

<snape>okay, I'll send the patch to the ml anyway, and that'll be the notification. Thanks!

<civodul>yw

<OriansJ>the portage news idea would be helpful to guix, I just hope someone picks it up and runs with it.

<ng0>I think when I looked at it it was fetching mail from a list at gentoo.org where the messages get posted to

<rekado_>that’s what NEWS is for.

<ng0>OriansJ: though it could be easier https://gitweb.gentoo.org/data/gentoo-news.git/

<ng0>which is just the data repo

<OriansJ>So, it is rather technically simple but requires organizational cooperation and effort to sustain.

<ng0>OriansJ: and a bit of python: https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/news.py

<pkill9>what do you mean what will break?

<pkill9>what in guix can break?

<ng0>iirc this is also feeds a part of the Gentoo news website

<ng0>but I could be wrong

IRC channel logs

2018-02-09.log