IRC channel logs

2020-06-11.log

back to list of logs

<NieDzejkob>mbakke: Filed as #41796
<mbakke>NieDzejkob: great :-)
<mbakke>NieDzejkob: interestingly there are already tests for multiple outputs in tests/grafts.scm: https://git.savannah.gnu.org/cgit/guix.git/tree/tests/grafts.scm#n188
<leoprikler>mbakke: that uses low-level operations – is there something similar on the package specification level?
<pkill9>how can i change the guix binary install script to use a specified tarball?
<pkill9>i can't work out where to change it
<roptat_>hi! I'm trying to install cuirass on a server, but running it for the first time, it fails with "ice-9/eval.scm:619:8: In procedure mkdir: Permission denied"
<roptat_>any ideas?
<mbakke>leoprikler: I think the grafting mechanism only cares about inputs and outputs no matter the derivation
<romulas> https://www.youtube.com/watch?v=xSP8u4iiLEg
<sneek>romulas, you have 2 messages!
<sneek>romulas, nckx says: So the reason I asked about trying another USB drive is that I had the same problem a while ago. Guix didn't even show up in the UEFI menu. There was no corruption. Wrote it to a different drive, worked fine. I don't think there's much we can do about that without some hint of an error message :-/
<sneek>romulas, nckx says: There are plenty of machines that hard-code something they shouldn't. You could try copying /EFI/Guix/grubx64.efi to EFI/boot/bootx64.efi.
<romulas>The First Mini-LED isn’t a 14” MacBook
<romulas>But can it run guix?
<lispmacs[work]>leoprikler: I'm not sure of the nature of the problem, why mate cannot interact with my gnome keyring. But I'm getting a variety of interesting messages in the logs: http://dpaste.com/3MF5DP1
<romulas>Might want to make a bug report to mate.
<romulas>The First Mini-LED isn’t a 14” MacBook
<romulas> https://github.com/mate-desktop
<NieDzejkob>mbakke: I think that test has "other-pkg" have multiple outputs, the case that's broken is "core-pkg" having multiple outputs
<NieDzejkob>uh oh, the next test links to a bug that looks exactly like this one
<NieDzejkob>a quick glance at the APIs involved suggests that the grafting of each output is requested separately?
***catonano_ is now known as catonano
<jackhill>ryanprior: https://nibblestew.blogspot.com/2020/06/short-term-usability-is-not-same-as.html reminds me of our conversation yesterday about manifests with less programming.
<ryanprior>jackhill "Most problems are in fact pretty much the same for most projects and the solutions for those are mostly boring."
<ryanprior>This tracks with my experience. I love boring tools that get common problems out of your way.
<Kozo>I have emacs-auto-complete installed but it's not auto completing my operators in emacs for common lisp. Anyone can point me in the right direction please?
<alduin>I've been thinking of trying out GuixSD, because the packagee manager seems interesting. But how does it work when you're regularly compiling and recompiling a binary, such as suckless utilities like st or dwm?
<lfam>alduin: Those are those programs you have to recompile to change a setting?
<alduin>Yes. They're small enough that this takes seconds.
<lfam>You would create a custom package recipe for them and edit that
<lfam>It's easier on Guix than many distros
<lfam>You could set up your own channel for them: https://guix.gnu.org/manual/en/html_node/Channels.html
<lfam>This way you'd be able to customize but still manage them with the normal distro tools
<alduin>lfam: Thanks, I'll check that out
<lfam>Cool, feel free to ask for help if you need it
<alduin>lfam: One thing, though. Do these channels have to be online, or can "url" be defined as a local directory?
<lfam>It can be local
<lfam>I don't remember if you use 'file://path/to/dir' or if '/path/to/dir' is enough
<raghavgururajan>mbakke: I made some changes to package definitions and tried building with `--system` argument. It builds fine.
<arend>whats BTRFS support like these days?
<guix-vits>arend: FWIW my Guix is on btrfs (laptop, home-single-user).
<arend>you have btrfs as your /?
<arend>with cow?
<semper>Guix package -u keeps trying to redownload Icecat (360mb~) and LaTeX (2.5gb~) despite them being identical to the currently installed packages and not updates at all. Is this a bug? It's hard to tell sometimes.
<guix-vits>arend: yes.
<guix-vits>arend: i'm not sure how up-to-date the current installation .iso are, so you may want not to use a fs-compression before updating the installed system.
<arend>whats btrfs performance like as / with cow
<arend>I use it for raid1 backup mainly which then gets stored offsite
<guix-vits>arend: on my HDD? same as everywhere (not much).
<arend>I dont use guix currently, but I am nuking my Void Install pretty soon so I am ready to hop
<guix-vits>arend: why dropping Void? Guix can be installed as a package manager (on top of another distro).
<arend>that isnt working out for me
<arend>guix daemon refuses connection
<arend>and Void's community... is.... drama infested atm
<guix-vits>arend: idk about this matters, but please report the bugs to the developers. Many of them use Guix-on-Another scheme.
<guix-vits>semper: see the Cookbook, about the profiles. Install the Latex in a separate one, and update it not so frequently(?).
<guix-vits>i did similar to "The battle for Wesnoth". Actually packed it with `guix pack`, so no updates ever. Just unpack-n-go.
<semper>guix-vits: I'll look into that, because distro-hopping is not at all an appealing prospect. But I don't know why it's updating something with an exact copy of itself, redownloaded. Is that really not a bug?
<guix-vits>semper: IDK, totally. There are developers around... try ask again later. I'd not yet hit this one, no idea.
<guix-vits>semper: what `guix weather icecat` says?
<guix-vits>maybe it's just need to.. khm, who knows?
<semper>guix-vits: .0% substitutes available (0/1,) 0mb on disk, ending with a gateway timeout from ci.guix.gnu.org. I don't really know how to interpret any of that, but perhaps I misused guix gc.
<guix-vits>semper: i guess (without any proper understandin of things) that some dependencies was changed, or some "graft" (security-update) should be applied.. so (as there is no an ready to use binary substitute) you're downloading the sources to compile the icecat. I REALLY-MAY BE WRONG.
<guix-vits>semper: gateway time out is a bad thing. Though i can access ci.guix.gnu.org from my browser now (via Tor, though).
<guix-vits>Got 502 for `guix weather` too, at the end. Probably known issue.
<mroh>good morning guix!
<guix-vits>Hi mroh. sneek tell mroh MORNING :D
<guix-vits>sneek: botsnack?
<sneek>:)
<guix-vits>sneek later tell guix-vits test
<sneek>Okay.
<guix-vits>sneek forget it
<sneek>guix-vits, you have 1 message!
<sneek>guix-vits, guix-vits says: test
<sneek>Okay.
<guix-vits>Looks like an improvement.
<guix-vits>sneek tell sneek hi
<sneek>Weirdo.
*guix-vits error: success
<Gooberpatrol66>How can I edit /etc/pulse/default.pa?
<rekado_>Gooberpatrol66: you don’t. But you can specify a different file to load.
<Gooberpatrol66>How do I do that?
<rekado_>Gooberpatrol66: /etc/pulse/default.pa is provided by the pulseaudio package and it’s just linked to /etc/pulse
<rekado_>so changing this would require changing the pulseaudio package, which you probably don’t want to do.
<rekado_>the manual documents pulseaudio-service-type
<rekado_>it takes pulseaudio-configuration
<rekado_>and that has a field called script-file
<rekado_>it defaults to (file-append pulseaudio "/etc/pulse/default.pa"), but it could be anything else
<rekado_>so just modify the pulseaudio-service-type in your operating system configuration
<Gooberpatrol66>thanks
<mothacehe>Hello Guix! rekado_, I'd like to reconfigure berlin to update Cuirass. Would it be ok?
<raghavgururajan>Hello Guix!
<raghavgururajan>What to do when the build scripts are under a sub-dir instead of root-dir of git repo?
<raghavgururajan>The root-dir of the repository has two sub-dirs, which are two different packages with their own build scripts. How to handle this during packaging?
<leoprikler>If the packages are self-contained, you should be able to just do (add-after 'unpack 'chdir (lambda _ (chdir "package-A")))
<bricewge1>Hi Guix!
<raghavgururajan>leoprikler: For (https://github.com/Libvisual/libvisual), is (add-after 'unpack 'chdir (lambda_ (chdir "libvisual") #t)) correct?
<leoprikler>yep, looks like it
<raghavgururajan>Thanks!
*efraim just yelled at their computer 'Return True!'
<reepca>hmm... 'torsocks icecat' seems to not work, and the included tor button doesn't work either. Any suggestions for getting secure, anonymous browsing up and running?
<rekado_>mothacehe: sure, go ahead.
<rekado_>mothacehe: but please don’t reboot.
<reepca>will be curious to see what happens with database contention on berlin
<reepca>finally got around to pushing that patch series \o/
<xelxebar>Argh. I have a package that fails a bunch of tests but having trouble reproducing the errors manually.
<xelxebar>After a failing build due to the checks, running this passes just fine: cd /tmp/guix-build-<blah>/source; source ../environment-variables; make check
<PurpleSym>xelxebar: Maybe the tests fail due to being run in a container?
<xelxebar>PurpleSym: I spun up a container, copied over the /tmp/guix-build-<blah>, and find the same thing... :/
<PurpleSym>Did you use `guix environment -C`?
<xelxebar>Yeah
<reepca>when I run next I can't seem to get M-l to work... it opens the minibuffer and promopts "Open URL in new buffer: " but any keys I press thereafter are ignored. next -v indicates that the keys are going through - it prints debugging info for each one - but somehow they aren't causing anything.
<PurpleSym>Hm, it’s unfortunately very difficult to reproduce the exact environment the guix-daemon uses for building stuff :/
<xelxebar>PurpleSym: AFAICT both --pure and -C are behaving the same. It's crucial to source the `environment-variables' file though.
<lprndn>Hello guix!
<xelxebar>Hrm. That's unforunate...
<PurpleSym>Can you figure out what the failing tests are doing? Network-related stuff almost never works in the build environment.
<xelxebar>PurpleSym: Yeah, I am chatting with the developers on their channel, but we have a large timezone difference, and I'm having a hard time pinning down how to recreate the problem on their end.
<xelxebar>No network stuff. It's a package for an interpreted language. From what I gather, the tests for their jit compiler are working fine but executing the compiled code is what's failing...
<mroh>reepca: I cant reproduce this. what windowmanager do you use? maybe try asking in #next-browser?
<reepca>mroh: I use i3wm
<xelxebar>Separate question: When packing a git-revision source, what's a good way to get the sha256? I've been letting build just error out and tell me the correct hash, but running build again with a corrected hash ends up cloning the repo again. For a large repo this is slow and annoying to say the least.
<xelxebar>s/git-revision/git-fetch/
<mothacehe>rekado_: ok! I would need someone to initialize my password so that I can sudo. Could you do that please :)
<civodul>Hello Guix!
<raghavgururajan>How do I overcome this configure error. https://bin.disroot.org/?d55ed8768c52dd8e#DXXutXNAtCqvSwrJb9MJJbgCBoFHGBoDvKCyGronVQPt
<mothacehe>hey civodul :)
<xelxebar>raghavgururajan: Mind using a pastebin that doesn't require javascript? The one mentioned in the channel banner is paste.debian.net. Then there's ix.io, which is nice for cli usage.
<raghavgururajan>xelxebar: Cool!
<raghavgururajan>xelxebar: Here, https://paste.debian.net/1151552/
<raghavgururajan>Short version of the error is: configure: error: can only configure for one host and one target at a time
<raghavgururajan>Never mind!
<raghavgururajan>Fixed using (lambda _ (invoke "autoreconf" "-vfi"))
<bricewge1>".a" shouldn't be kept in packages, right?
<bricewge1>I have found "(install-file "libapfs.a" lib)" in apfs-fuse, there is no explanation for it. It make me doubts...
<efraim>bricewge1: before you get rid of it I'd check if any of the dependants use it. If so you can stick it in the "static" output
<bricewge1>It has no dependents
<bricewge1>Is there a reason for not having a linter that check the presence of static libraries?
<efraim>then it would have to build the package in order to lint it
<guix-vits>reepca: Arch Wiki have a page about tor, with "Transparent torification". This (probably) can be limited to one UID.
<civodul>bricewge1: re lint & static libraries, so far 'guix lint' would only perform checks that don't require building the package
<civodul>perhaps we could add optional "checkers" that require something to be built
<bricewge1>Ok I get it, thanks
<mothacehe>civodul: I'm a bit stuck trying to fix the cow-store issue of the installer. I sent a small summary of the situation here: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00043.html. If you happen to have any idea :)
<bricewge1>reepca: If you want to use Tor with IceCat you can read the log there http://logs.guix.gnu.org/guix/2020-06-03.log#144001
<bricewge1>Or use the 'torcat' script http://ix.io/2ob8
<rekado_>mothacehe: you’ve got mail
<mothacehe>rekado_: working, thanks!
<xelxebar>Blargh. Is there a way to run a single build phase on top of an existing directory (e.g. the /tmp/guix-build-* of a previous run)?
<xelxebar>I have a package that takes forever to build but the `check' phase is failing mysteriously. Need a way to poke at it without building from scratch every darn time.
<zzappie>Hello Guix!
<zzappie>Whoa what a great new irc log page
<civodul>mothacehe: a quick hack that comes to mind would be a white list of processes not to kill
<civodul>would that even help, though?
<civodul>otherwise, trying to see why kmscon opens a font file at that point and somehow prevent that
<civodul>does that make sense?
<mothacehe>civodul: I already have such a whitelist, but not killing kmscon means that it won't be possible to umount partitions
<mothacehe>yes the only solution left if to prevent kmscon from opening font files after startup I guess
<mothacehe>I can try that, thank you :)
<civodul>mothacehe: ok (i don't think i was particularly helpful tho :-))
<kondor[m]>I'm probably getting this for the n-th time: Unable to find remote helper for 'https' during git clone; apparently, this is connected to git being unable to locate libcurl; I do have libcurl under lib in the profile where git is installed
<kondor[m]>any ideas?
<civodul>kondor[m]: is GIT_EXEC_PATH set?
<civodul>if not, you should do: export GIT_EXEC_PATH=$HOME/.guix-profile/libexec/git-core
<civodul>this happens automatically via ~/.guix-profile/etc/profile
<kondor[m]>oh yes it is, it is set to a slightly misspelled path :D
<kondor[m]>thanks civodul
<civodul>hey janneke
<civodul>janneke: could you look into a blog post regarding the reduced bootstrap binaries? :-)
<civodul>i know it's an old story for you now
<janneke>civodul: i started a draft yesterday night!
<janneke>not ready to push it yet
<civodul>janneke: yay, thanks a lot!
<bdju>I'm trying to run a python script and it's saying I don't have openssl installed. Is this likely, or is it just unable to find it?
<bdju>I'm seeing results for openssl in the store if I search with find
<mbakke>bdju: did you try installing it? it's not installed by default.
<bdju>mbakke: I thought it would be for some reason, and installing it did work. that's interesting. thanks!
<NieDzejkob>does guix refresh -u actually work for any package? git-fetch ones "cannot download for this method", url-fetch ones don't have an updater
*rekado_ uses guix refresh -t cran,bioconductor -u regularly
<efraim>It doesn't work on as many packages at it might possibly, but for the ones it does work on it's really nice
<roptat_>hi guix!
<roptat_>I'm trying to run cuirass on a server of mine, but it doesn't seem to do anything
<roptat_>I initially had an issue where it didn't start because it didn't have permission to create some directory, I fixed that by creating it (/var/guix/gcroots/cuirass)
<roptat_>now it's running, but it doesn't do anything: I only see "2020-06-11T14:05:02 next evaluation in 60 seconds" every minute in the log
<roptat_>I've adapted the configuration from the maintenance repo, I'd like to run master and guix-modular-master: https://framagit.org/tyreunom/system-configuration/-/blob/master/modules/config/cuirass.scm
<roptat_>ah! I was missing a . in the configuration, it seems to be working now!
<roptat_>success: https://guix.lepiller.eu/ !
<efraim>congrats!
<roptat_>now that's only a small machine, so I'm not sure it can follow the rate of updates in guix, but at least it's a fun experiment :)
<efraim>I think the trick is to feed it your manifest and/or any extra repos you want and have it build just those :)
<civodul>NieDzejkob: thanks for the bug report and nice reproducer for grafts, i'm looking into it!
<jonsger>roptat_: nice. can you share your configuration? I wasn't successfull
<civodul>roptat_: yay, another build farm!
<NieDzejkob>civodul: Thanks! If you figure it out, could you bump nghttp2 and mark the commit as fixing CVE-2020-11080?
<roptat_>jonsger, https://framagit.org/tyreunom/system-configuration/-/blob/master/modules/config/cuirass.scm
<civodul>NieDzejkob: ah sure, that's how you found out about it?
<roptat_>it's heavily inspired from the config in the maintenance repo :)
<jonsger>thx
***rekado_ is now known as rekado
<roptat_>I see that some derivations of guix-modular are not reproducible, is that expected?
<roptat_>(eg. guix-packages-base)
<civodul>roptat_: yeah, unfortunately macro expansion is not deterministic
<civodul>unless the compilation order is fixed
<civodul>so when compiling in parallel, we can end up with different .go files
<mbakke>is it possible to extend shepherd-root-service-type multiple times in the same service-type? i.e. one service-type starting several shepherd services?
<PurpleSym>civodul: Wrt your pager patch: less does not seem to be capable of stripping URL control sequences correctly and shows some parts of these sequences for me.
<AMDmi3>Hi! I've a question about CPE support in Guix
<AMDmi3>I see some packages define `cpe-name`; is it really used for something?
<rekado>AMDmi3: yes, by “guix lint”
<AMDmi3>sorry, I'm in fact not guix user; what does it do?
<AMDmi3>aha, I've found docs, I see now
<AMDmi3>well then it would make sense to tell that I've added CPE support to repology some time ago, and it's now capable of reporting missing CPE information
<AMDmi3>see https://repology.org/repository/gnuguix/problems
<AMDmi3>also note that in ordere to have complete CVE search, you'd need a way to define multiple CPEs per package, and also be able to specify any CPE field, including, most importantly, vendor
<roptat_>that's not really useful, because guix lint will use the package name if no cpe-name is provided
<roptat_>at least, you have too many false positive
<roptat_>for instance, the first item in the list is "acl" and you suggest using "acl" as the product name, which is great, but guix lint already does that
<AMDmi3>uh huh, I can take this into account
<roptat_>that would make the page more interesting :)
<AMDmi3>although no: it would produce a bunch of false positives of another kind, CPEs without matches in NVD or CPE dictionary
<roptat_>just ignore those?
<roptat_>currently guix can only associate one cpe name to a package, it's either cpe-name if it is present, or the package's name
<roptat_>if you detect a cpe-name that does not correspond to any actual name, that's not really an issue
<roptat_>an issue would be if a package has the wrong cpe name (implicit or explicit)
<AMDmi3>this way there's no telling whether assumed CPE is incorrect or there are just no CVEs for the product
<AMDmi3>well I've just wanted to inform that there's now a tool
<AMDmi3>if you want CPE matching to be reliable you'd probably need to always specify them explicitly, allow multiple of them and support all fields
<civodul>PurpleSym: it works for me; could you report a bug, including the version of less and $LESS?
<PurpleSym>Sure, will do.
<civodul>normally the "r" option has it do the right thing
<_pm>Hi, I installed guix on Ubuntu 16.04 and when I do 'guix package -u' I get a warning 'guile: warning: failed to install locale' and then it returns without upgrading anything. I found lots of search hits but none of those helped me.
<lle-bout>pm: hello! this means that your packages are already up to date! the locale issue is unrelated. You can find more information about locates in the manual: https://guix.gnu.org/manual/en/html_node/Locales.html
<sneek>lle-bout, you have 1 message!
<sneek>lle-bout, marusich says: I intend to keep poking at this as time goes on. If we can't figure out how to make gcc reproducible, we may want to consider just biting the bullet and getting the bootstrap binaries in, but we can discuss that on guix-devel a bit, too.
<lle-bout>pm: if you want to upgrade packages you need to do: guix pull - then: guix package -u or guix upgrade - if upgrade does nothing then everything is up to date already!
<_pm>thanks for those responses. I know for sure that there is something to upgrade because I have another vm running guixsd and when I ran 'guix package -u' there it did do a lot up upgrades. This Ubuntu machine has not been updated in last 1 month so I am certain that there is some other issue. And yes I did 'guix pull' followed by guix package -u.
<lle-bout>pm: what is the return code of: guix package -u? You can check by running: echo $? - just after that
<lle-bout>If it's non-zero it means there was an error, otherwise everything is fine
<lle-bout>GNU Guix installed over Ubuntu would only update packages that are installed if you use: guix package -u
<civodul>NieDzejkob: do you confirm that nghttp2 1.40.0 and 1.41.0 are ABI-compatible?
<_pm>ll-about echo $? returns 0. So there is nothing to upgrade. Hmm. Okay I will take that for now.
<_pm>lle-bout: thanks
<guix-vits>_pm: Is guix package -I return something?
<_pm>guix-vits: yes it does. there is guile 3.0.2 but nothing else much
<guix-vits>_pm: and guix pull also returns 0? Not that i'm understand those things, but one month and no upgrades is indeed strange.
<NieDzejkob>civodul: I'm not sure, tbh :/
<roptat_>pm, you should check that you are running the correct guix (type guix should return something like /home/pm/.config/guix/current/bin/guix)
<roptat_>if not, run "hash guix" after "guix pull"
<_pm>guix-vits: thats exactly my thought as well. I am looking for packages that gets upgraded frequently so test something changes in another week or so.
<_pm>roptat_: I can confirm that is indeed where guix is pointing to
<roptat_>(I mean not with "which" but with "type", because which doesn't use your terminal's cache for binary locations)
<roptat_>but if that's where your terminal finds guix, that's fine, then there's no upgrade, as long as you ran "guix pull" recently
<_pm>guix-vits: and yes 'guix pull' also returns 0. I will bug this thread again in a week I guess
<Gooberpatrol66>How can I stop pulseaudio temporarily? It restarts if I kill it.
<NieDzejkob>herd stop pulseaudio?
<Gooberpatrol66>herd: service 'pulseaudio' could not be found
<NieDzejkob>Hmm, I think a program that needs pulseaudio will spawn it, actually
<roptat_>well, sudo chown root: ~/.esd_auth might actually force it to crash at startup
<Gooberpatrol66>autospawn=no in client.conf worked
<guix-vits>btw, i've a %desktop-services and have'nt pulseaudio too. Probably not a default?
<guix-vits>Trough itself there.
<mbakke>NieDzejkob: you can use 'abidiff' from 'libabigail' to check for ABI compatibility, invaluable tool when adding grafts :-)
<leoprikler>pulseaudio is not started through shepherd, but through your WM as local user
<guix-vits>oh, i'll think about that; noted, thanks.
<guix-vits>though `ps -e| grep -i pulse` -> ""
*guix-vits also, as RH spread their Cloud Services, probably this flaw ("started .. as local user") will be fixed some day ... `(boo! Guix)`
*guix-vits program that spawns..
<NieDzejkob>mbakke: It might be a good idea to add a paragraph or two on this in the manual section about grafts
<mbakke>NieDzejkob: agreed
<civodul>mbakke: actually i had forgotten about abidiff (oops!) so i relied on the release notes
<civodul>silly me
<civodul>but i've just tried and it looks good
<civodul>"1 Added function symbol not referenced by debug info:"
<civodul>janneke: just got around to looking at the hurd-vm service
<civodul>i fell off the keyboard yesterday :-)
<janneke>civodul: great, i imagined something like that
<janneke>i re-read mothacehe's reply and it makes more sense now
*janneke reads civoduls reply -- thanks => ah, yes -- exactly
<romulas>Mesa 20.1.1 Release Notes / 2020-06-10
<romulas>Are you guys waiting on the kernel being updated?
<civodul>hi romulas!
<civodul>s/guys/people/ :-)
<civodul>changing Mesa implies rebuilding lots of things
<civodul>so usually we do a batch of similar updates on a branch
<civodul>does this version include critical changes?
<janneke>civodul: oh, thanks for the review ...that's "almost done", pending on mothacehe's contribution -- and he's often pretty fast :-)
*janneke was looking for a good reason to procrastinate writing a certaing blog post
<romulas>20.1.0 is a major change, yes.
<romulas>critial changes for the latest mesa, yes.
<romulas>Once you get in the latest kernel I mean.
<ryanprior>Guix has said for days that there's a new ungoogled-chromium but weather says it's not available and I refuse to build it on my laptop I'd rather switch to a flatpak or some other distribution mechanism rather than have to build the thing myself to get updates.
<ryanprior>Any other ungoogled-chromium users notice going a long time without substitutes? Are there other substitute servers that provide it more reliably?
<NieDzejkob>I wish we had a way of prioritising CI builds by how "important" a package is.
<jackhill>nckx's substitute server doesn't have it eaither
<jackhill>NieDzejkob: that would be cool.
<jackhill>It does build, as I've built it locally.
<NieDzejkob>(I believe a good proxy for that is either how many times previous builds of the package were downloaded (perhaps corrected for how long a given version was available) or how long a build for a package took last time)
<NieDzejkob>I didn't know nckx runs a substitute server. Where could I read about it?
<jackhill> https://guix.tobias.gr
<guix-vits>jackhill: "Malware such as Google's Chromium will never be distributed. That's a promise." -- your link :D
<jackhill>but what about ungoogled-chormium? :þ
<ryanprior>I've been thinking for a time about building a cluster but didn't know what to run on it. I'm thinking maybe guix builds is the answer.
<ryanprior>I'm picturing a heuristic involving popularity of the software, number of related CVEs, time since latest CVE, price of exploits for that software on the market.
<ryanprior>That ought to ensure things I care about get built quickly as possible.
<civodul>janneke: heheh :-)
<NieDzejkob>heh, we could grep the commit messages for 'CVE|security' :P
***slyfox_ is now known as slyfox
<janneke>crap, i thought i had it working ... but i must have been fooling myself given the message i see
*janneke -> zZzzz