IRC channel logs
2018-02-09.log
back to list of logs
<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. <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>i love how dependency graphs are isolted from eachother, i know i'm preaching to the choir, but it's great :D <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 <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 ! <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" :-) <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>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>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>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>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 <pch>i just want to write a service which triggers an installation & download of a certain package <civodul>the key idea here is that downlading/installing now will give exactly the same result as downlading/installing tomorrow or next week <civodul>so there's no value from a Guix perspective in forcing downloads and such <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>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>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>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 <pch>ng0, civodul: would this remove all the old versions of all the packages? <civodul>roptat: if it's useful to you, it may be useful to others :-) <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" <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>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 <ng0>TIL: when you switch the primary group of a user in GuixSD the files in their $home get recursively regrouped <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 <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 <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>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>wrt civodul reply on the mailling list <vagrantc>with the "hifive unleashed" coming, wondering if anyone has mentioned working on a guix port <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>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>why is it a 'revolution' as they claim? <pkill9>i don't know anything about RISC <cehteh>which recently got some drive, few real implementations become available <ng0>"Indeed. RISC architecture is gonna change everything." <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 <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 <pkill9>ng0: do you take requests for your custom guix repository? <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>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>qtwebengine is a monster + we had some issues because of chromium in it and I'm not reading through that big thread <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>let me take a note on this and give you a reply after exams and after today (bad day). <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 <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>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>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 <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. <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: 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! <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 <ng0>which is just the data repo <OriansJ>So, it is rather technically simple but requires organizational cooperation and effort to sustain. <pkill9>what do you mean what will break? <ng0>iirc this is also feeds a part of the Gentoo news website <ng0>but I could be wrong