IRC channel logs


back to list of 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>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
<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 !
<catonano>has anyone built guile on GuixSD ? I'm having this error ld-wrapper: error: attempt to use impure library "/home/catonano/guile/lib/"
<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>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>remote: Can't locate Data/ 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/ 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 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:
<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... 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, 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
<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:
<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
<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>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
<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'?
<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."
<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
<pkill9>ng0: do you take requests for your custom guix repository?
<ng0> not sure, might've been this.
<pkill9>was that at FOSDEM?
<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:
<pkill9>it's explicitely disabled from the Qt build for security reasons it seems
<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> 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
<pkill9>it's also from jully 2015
<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
<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!
<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 where the messages get posted to
<rekado_>that’s what NEWS is for.
<ng0>OriansJ: though it could be easier
<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:
<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