IRC channel logs


back to list of logs

*apteryx answering myself: the --docdir thing is supported by autoconf starting from 2.60, I can probably just delete the configure script and have autoreconf invoked to fix my problem.
<apteryx>emacs DJ:
<apteryx>hmm... could that be a autoconf bug?
<apteryx>Can't exec "autopoint": No such file or directory at /gnu/store/aqzb6lm1vmz14rp899lqmi6pr35ycgx6-autoconf-2.69/share/autoconf/Autom4te/ line 345.
<apteryx>autoreconf: failed to run autopoint: No such file or directory
<apteryx>autoreconf: autopoint is needed because this package uses Gettext
<apteryx>alternatively I can install gettext-minimal
***Guest23921 is now known as benny
<emacsomancer>what's a good solution for unlocking ssh-keys on login on guixsd?
<civodul>Hello Guix!
***rekado_ is now known as rekado
<rekado>civodul: hello!
<rekado>civodul: for attached Scheme files (with filenames ending on “.scm”) there’s now syntax highlighting in mumi.
*civodul looks
<rekado>the CSS could still be tweaked somewhat; I took it from the Guix blog.
<civodul>excellent, really nice!
<civodul>debbugs now has a completely different feel
<civodul>guile-syntax-highlight can do C and XML as well, but we don't use those very often...
<janneke>hello civodul!
<civodul>hey janneke!
<jonsger>rekado: sometimes it has false positives like here but I think thats not dramatic :)
<rekado>jonsger: yeah, it’s hard to avoid when doing simple line by line styling. We’d need something context-aware, but email bodies are so irregular that it would be hard to get right.
<jonsger>yes. I guess there is no simple solution for that problem :(
<rekado>in this case I could require that the word “diff” is found on one of the preceeding lines before styling lines starting with “-”.
<rekado>I’ll give that a try.
<rekado>jonsger: should be a bit better now
<jonsger>yes rekado. thanks :)
<roptat>hi guix!
<roptat>if someone could have a look at, I don't know what to do
<civodul>i had a look weeks ago, thought i had understood, but actually no :-)
<civodul>i'll give it another try
<roptat>thank you :)
<civodul>i thought this had to do with ~* (argument skipping)
<roptat>the internet thinks it's an ordering issue, but every example is for printf in C
<roptat>only the last arguments can be skipped, so there is a way to reorder them in C
<civodul>ordering of what?
<roptat>of ~d and others
<roptat>in our string, there is one ~d in the singular case, and two ~d in the plural case
<roptat>how does gettext know which argument to use in the singular case?
<roptat>it uses the first one by default, hence the need to reorder them
<civodul>i didn't gettext to understand format flags actually
<civodul>it doesn't have to
<roptat>actually, it's printf in C that does that
<roptat>not sure about how it works in guile
<roptat>but it seems gettext has some checks in place
<civodul>if we can't find a way around it, let's just add an 'if' and make it two separate strings
<civodul>that should solve the problem
<roptat>that's a bad solution
<roptat>because the rule for plural is different depending on languages
<roptat>some languages also have more than singular and plural
<dvn>i have not been able to run "guix package -u" with success in the past few weeks because it fails on building qtwebkit -- now i've tried disabling upgrading every package i can think of that might use qtwebkit, but it *still* tries (and fails)
<dvn>i mean by "disabling" eg. --do-not-upgrade=qtwebkit
<civodul>roptat: yeah i know, but i thought there was a way out in this case
<dvn>is there a way to see all the package `guix package -u` will try to upgrade?
<civodul>dvn: you can do "guix package -n -u"
<civodul>roptat: did you try moving ~* right before the word "package"?
<dvn>thanks civodul that's helpful
<baimafeima>is there anyone who could help make available in the repository?
<baimafeima>I'm also curious if guix package manager would work on Haiku:
<baimafeima>does anyone know if this would work?
<efraim>guix currently depends on the linux kernel (or the Hurd) and glibc
<efraim>does haiku support user namespaces? that'd make it the easiest for porting
<civodul>Haiku uses a kernel that glibc doesn't support, so Guix won't run on it
<efraim>ng0 looked into using musl or other libc's iirc, it might be possible
<baimafeima>mhmm I see
<baimafeima>I kind of wish or hope that in the future there'll be a universal package manager to be able to run free software even on Haiku
<baimafeima>if Haiku and GuixSD were to work together on such a project ...
<efraim>the seL kernel also looks interesting
<roptat>baimafeima: agreed, I like haiku too :)
<roptat>although their filesystem doesn't support adding directories at the top-level, so no /gnu
<roptat>civodul: do you know what manual page I should look for to understand ~* and others?
<civodul>roptat: info "(guile) Formatted Output"
<roptat>same error with ~* before "package"
<baimafeima>roptat, how do you evaluate haiku in terms of its values? open source vs free software, pragmatism vs ethics-freedom approach
<roptat>baimafeima: I don't think they have strong opinions on these subjects
<roptat>they have non-free drivers, but according to the devs, it should be easy not to add them
<roptat>they're more focused on "usability" and "ux" which is different from pragmatism
<baimafeima>roptat, I see, I'm attracted to projects such as Haiku and Solus (a linux-based one) for the out-of-the-box approach where there OS is not getting in your way, but ethically I'm much closer to GuixSD but cannot use it very well because it's too difficult
<baimafeima>roptat, usability and ux is different from pragmatism?
<roptat>it's a bit fuzzy in my mind, but they usually prefer to have their own integrated tools rather than using tools they can't controll
<baimafeima>roptat, I think then Solus and Haiku OS are very similar in that aspect
<roptat>I don't know Solus very much
<roptat>but Haiku always has its filesystem and yellow tabs :p
<baimafeima>and ethically, I guess Devuan, PureOS and GuixSD are in the same boat?
<roptat>they're following the fsdg, so I'd say yes
<roptat>but guixsd tries to give even more control to the user
<baimafeima>in which sense?
<efraim>I'd take devuan out of the list and add trisquel and parabola, as being FSF approved
<civodul>AIUI Haiku didn't start with an emphasis on user freedom:
<civodul>quite the opposite
<baimafeima>civodul, oh i see, thanks for bringing this up
<roptat>I didn't know
<roptat>so, in the sense that we try to be easily hackable and extensible
<baimafeima>what about nix?
<roptat>it's very similar, but they are more pragmatic :)
<roptat>actually, I'd be already very happy if people chose nixos over anything else :)
<wingo>love 2 build libreoffice
<baimafeima>roptat, I wish I knew more about these technical differences
<roptat>for instance, they don't follow the fsdg, they don't try too much to be reproducible or bootstrappable
<baimafeima>I asked in the Solus IRC last time to have Guix added but they refused
<roptat>baimafeima: do they have pip or other package managers?
<baimafeima>roptat, they use a package manager called eopkg
<roptat>I mean, beside the OS package manager, do they package other package managers?
<baimafeima>roptat, they support flatpak and snap out of the box
<roptat>then there's no real difference between that and supporting guix
<baimafeima>roptat, I suggested to have guix added so I could install a libre-kernel but they said it wouldn't work with clear boot manager they have in place
<roptat>I don't think you can easily use guix's kernel on a foreign distro
<roptat>you'd better use guixsd :p
<baimafeima>roptat, yeah i realized that
<efraim>there's also adelie linux
<jlicht>hiya guix
<baimafeima>roptat, Solus does have pip, yes
<baimafeima>efraim, interesting, never heard about adelie linux before
<baimafeima>roptat, so pip is also like a package manager but only for python packages?
<efraim>baimafeima: i only heard of it after looking around for a distro for my PPCs
<roptat>every language has its package manager nowadays
<baimafeima>roptat, isn't there a risk then that a package installed from another package manager such as pip conflicts with a natively packaged one?
<roptat>mostly because distros don't update their packages often enough, or there are too many packages to include them in a distro
<roptat>it can happen, and it's hard to debug, so they usually have some "environment" mechanism (setting/unsetting environment variables)
<roptat>(for python I think it's separate from pip though)
<roptat>it also allows you to work on incompatible projects
<baimafeima>roptat, I see, if I were to use guix (provided I get it to install without having it officially packaged), is there a risk that an application installed via guix would conflict with any native packages I have installed in solus?
<roptat>less than with pip, because guix package are completely independent from your host system
<baimafeima>are they sandboxed like in a flatpak and could I deinstall it without trace as well?
<roptat>no, they just don't know about /usr, /bin or /lib
<baimafeima>do you mean they guix is stateless?
<roptat>that's also how we can install two packages in the same profile that want different versions of glibc
<rekado>yes, you can uninstall all of Guix by removing a few directories (/gnu, /var/guix, /etc/guix)
<rekado>but you can’t just uninstall/remove a single store item directly
<rekado>because store items have links to other store items; but you can let “guix gc” figure this out for you and remove everything that you don’t need any more.
<roptat>baimafeima: I mean a store item can only reference other store items, no system global thing (well, packaging mistakes can happen)
<roptat>and since your system has no business knowing about guix either, they are pretty separate
<baimafeima>is there any way to search by typing a name?
<baimafeima>roptat, that's good to know, then the challenge for me is now how to get guix installed
<roptat>you can use the binary installation procedure
<rekado>baimafeima: you can find a searchable interface here:
<roptat>or the installation script
<rekado>(I don’t think that’s up to date; I think we are above 8000 packages by now)
<baimafeima>rekado, thanks, would be great to integrate this search function on the main site
<roptat>baimafeima: you can probably run as root
<roptat>I've never used it, but it should work fine :)
<rekado>mbakke: I finished running “guix pull --branch=core-updates”, now I’m installing icedtea to see if the JVM can be started on RHEL6.
<rekado>that should exercise enough syscalls.
<baimafeima>roptat, I see
<baimafeima>I am slowly reading my way into all things and just came across this post:
<baimafeima>I'm trying to understand what motives Solus as opposed to a system like GuixSD
<rekado>“I will stress here something that is very important to me - I am not a free software developer, I am an open source software engineer. I'm not in this to effect and implement a sociopolitical agenda.”
<rekado>every action is political.
<rekado>by acknowledging the political implications of what we do we can at least choose the direction of the political effect our actions have.
<baimafeima>rekado, I agree, every action is political, but many choose to stay away from politics because they don't care or because they don't want to associate themselves with a particular form of politics
<baimafeima>it seems to me that Ikey, the Solus founder, must have had bad interactions with free software activists or developrs
<jlicht>baimafeima: taking any action (or indeed, no action) is always political. "Staying away from politics" is impossible in that sense.
<baimafeima>but I am trying to understand why he thinks the way he does but I have trouble understanding because I feel ethically much closer to FSF
<baimafeima>but pragmatically close to Solus (this is the easiest system I have used as a beginner)
<baimafeima>jlicht, I absolutely agree, I'm just trying to understand his post
<civodul>i think we're slowly slipping off-topic :-)
<baimafeima>pragmatically, Solus is my operating system home, but ethically, it is not...which is sad..
<civodul>baimafeima: getting back to Guix ;-), i would love it to be a starting point to people who want to learn about GNU/Linux
<jlicht>getting ever-so-slightly more on-topic then, is there anyone who would be willing to share their (#guix)-IRC logs of the last ~8 days?
<civodul>so it's not "ease of use" in the sense of these GUIs
<rekado>jlicht: I can send them to you
<civodul>but it's hopefully ways by which people can easily dive in
<baimafeima>it'll be amazing if Guix would be accessible for people like me
<baimafeima>GuixSD I mean
<rekado>jlicht: bayfront-log logs this channel, but I haven’t gotten around to making the logs public yet.
<jlicht>baimafeima: Just try Guix (the package manager) on top of your favorite distro first
<civodul>hi bayfront-log!
<jlicht>you can even create VM's running GuixSD in a convenient way, so that also allows you to get started with an actual GuixSD system
<civodul>thanks for setting this up, rekado
<jlicht>rekado: amazing. I am in no hurry, but would appreciate it very much :-)
<baimafeima>jlicht, thanks, I think I'll try to run GuixSD in a virtual machine first
<baimafeima>thank you all for your ideas and support
<jlicht>baimafeima: guix (the package manager) allows you to do that easily
<rekado>baimafeima: if you install Guix on top of a foreign distro you can use Guix itself to build Guix virtual machine images.
<baimafeima>I thought of first installing GuixSD in gnome boxes or virtualbox
<baimafeima>wouldn't this be easier?
<roptat>it will be closer to actually installing it on a system, but the installation of the system is a bit harder than installing the package manager on a foreign distro
<roptat>you have to setup your hard disk, network, run a bunch of additional commands and then actually run the "guix system" command. From a foreign distribution, you can simply run that "guix system" command
<roptat>(it's a different command though: installing guixsd requires you to run "guix system init", but to build a vm, you can run "guix system vm")
<roptat>we don't have a fancy installer (yet?) for guixsd, so using guix from a foreign distro is definitely simpler
<baimafeima>roptat, oh i see, that's already too complicated for me to get it installed I think, I'll try to get Guix installed on top of a distribution then
<roptat>once you are more familiar with guix and the configuration system, you can move on to the full installation procedure :)
<wingo>stupid question:
<wingo> texlive-texmf-2017 2.76GiB
<wingo>how do i prevent this
<wingo>this is in a guix package -u
<baimafeima>roptat, ok, i hope so
<jlicht>wingo: you can pass a --do-not-upgrade pkg-name to `guix package`
<wingo>i think i just needed to "guix build texlive"
<wingo>considering as i had the source downloaded from some previous incantation
<ng0>efraim: I think rain1 spend more time with this than myself
<ng0>I've moved it to the very end of things I want to work on
<ng0>before I am off again: my guess is correct that Guix master would not be interested in an elfpatched tor-browser bundle?
<ng0>it could take a long time until I have it building from source, so I'm doing the elfpatch thing for the time being
<wingo>texlive makes me think a grafting progress bar would be ncie
<mbakke>civodul: Do you think it's safe to start a new Hydra evaluation? It failed pretty hard yesterday:
<civodul>mbakke: ouch
<civodul>mbakke: did you try monitoring berlin, and if so, how much is missing for it to be useful to you?
<mbakke>civodul: I'm mostly concerned for the users that have Hydra as their only substitute server!
<mbakke>The biggest missing feature in Cuirass for me is "newly failing jobs".
<civodul>snape: are you reading this? ;-)
<civodul>mbakke: do you use M-x build-farm?
<mbakke>civodul: Ooh, I haven't tested it yet! Trying now.
<civodul>it has a bit more than the web UI currently
<civodul>mbakke: re substitutes, i'm willing to switch to berlin as the main server real soon
<civodul>and keep in "best effort" mode from now on
<civodul>and push a 0.15.1(?) release real soon that has berlin as its default
<efraim>I love sorting by newly failing
<efraim>We should bump for 0.15-3 with the channels update
<civodul>(in other news: goodies at <>!)
<mbakke>civodul: Looks awesome indeed!
<mbakke>Re berlin, sounds reasonable.
<mbakke>Hopefully Hydra becomes faster with less traffic, so we can keep using it's CI features until Cuirass catches up.
<snape>civodul, mbakke: yes :-)
<snape>the biggest issue with Berlin right now, to me, is that it can't keep up
<mbakke>snape: With you, or with Guix? :P
<snape>haha, with Guix commits, of course
<civodul>we should do a Cuirass hackathon
<snape>at fosdem :-) ?
<civodul>why not, but it's a bit late!
<civodul>like, suppose we want to announce 1.0 at FOSDEM
<rekado>It seems to me that this is a problem not with number of build servers but with utilization by Cuirass; is this correct?
<civodul>then Cuirass must be in good shape months before
<rekado>I could add more hardware next week.
<civodul>rekado: definitely
<snape>civodul: hmm right, we're in a hurry
<civodul>i think we're doing good :-)
<civodul>but yeah, it's quite a bit of work
<rekado>civodul: I’m very excited about the new “guix pull” features you’ve been working on!
<civodul>rekado: i'd love to see how well it works for you at work
<civodul>channels, 'guix describe', etc.
<civodul>i think it should be handy for your use cases
<rekado>yes, absolutely
<rekado>I’ll have an opportunity to speak about Guix in October and I’d like to demo these things.
<civodul>these are things we've been discussing for ages, it's good to see it come to fruition
<civodul>i'm also giving a training session internally in October
<rekado>I like how this naturally follows from the new guix pull design.
<rekado>had we implemented some of the earlier plans I’m sure it wouldn’t seem as elegant.
<civodul>we'll never know :-)
<rekado>I’m revisiting the work on having a soft port for processing build output.
<rekado>Noticed that the output from grafts is hard to tame.
<rekado>when grafts cause a package other than the target package to be built I’m missing a line in the output that says what derivation is being built.
<civodul>rekado: you mean the "@" lines?
<civodul>these lines are not produced unless the client does (set-build-options #:print-build-trace #t)
<mbakke>How can I make `make check-system` respect $GUIX_BUILD_OPTIONS ?
<rekado>civodul: ah yes, I could use the @ lines.
<samplet>rekado: About GHC 8.4.3, ‘ghc-pandoc-1’ is proving difficult. Do
<samplet> have any thoughts about this:
<samplet> <>?
<samplet>“Do you have any thoughts,” is what I meant to say.
<rekado>samplet: let’s throw away ghc-pandoc-1 then.
<samplet>Great! I can’t really evaluate the R Markdown stuff. Other than making sure it builds.
<rekado>Rmarkdown was the only reason to keep it.
<rekado>I know of only one problem with Pandoc 2 when used with Rmarkdown: it wouldn’t generate tabs.
<rekado>I assume that this has been fixed by now.
<samplet>Assuming the R Markdown stuff works, I’m down to only a handful of failing builds.
<rekado>yes, it has been fixed:
<rekado>that’s great!
<samplet>I need to clean up the Git history a bit, but after that we could put it on a “wip-” branch that can be built on a build farm.
<samplet>Darcs builds, and all of Git-Annex’s dependencies build (but not Git-Annex itself).
<samplet>I haven’t sorted out Agda and Idris yet, but if I figure if I make the work more public I might get help with those. ;)
<samplet>In other news, I have an GNAT (GCC Ada compiler) package for Guix, but I’m not sure if it is acceptable. GNAT is not bootstrappable, so I use a binary from Debian.
<samplet>The binary is constructed by pulling in 26 “.deb” files from Jessie followed by a lot of patchelfing.
<atw>samplet: agda's dependencies?
<samplet>atw: I’m not sure. I haven’t tried building it. Let me check.
<efraim>samplet: I'd assume not. There's not an upstream static binary we can use as a base?
<atw>samplet: you may want to (delete 'haddock) as that phase takes forever
<samplet>atw: ghc-alex fails during testing.
<samplet>efraim: No. Ada Core Technologies provides a GNAT binary, but it is not static and there are license issues.
<samplet>I could build and provide a static binary, but that seems a lot less “official” than Debian.
<samplet>This was the cleanest and most “trust-worthy” approach I could come up with. I understand that it is not pretty.
***Server sets mode: +cnt
<atw>I have not yet found a good way to package Agda libraries ( so the agda standard library isn't packaged. Any ideas?
<janneke>civodul: just to let you know that i think wip-bootstrap is functionally finished. there's no hurry, just wondering about the next step, we probably want to collapse it into a few commits (or maybe 1?). how shall we go about that?
<atw>janneke: congrats! Today is John McCarthy's birthday, fun fact
<janneke>atw: thank! nice :-)
<civodul>janneke: awesome! i'll take a look, and probably we can squash commits, indeed
<civodul>is the "-s i686-linux" vs. real i686 discrepancy still here?
<civodul>mbakke: re "make check-system", perhaps you could hack the script directly to have your options honored
<janneke[cm]>civodul: thanks!
<rekado>mbakke: /gnu/store/k0mz0z5brhg50n102d6q9k2fvvddr5ny-wayland-1.16.0.drv from core-updates failed to build on my system where the store is on NFS
<rekado>I remember having the same problem in the past; something to do with file locking.
<rekado>mbakke: “hello” works fine (no “kernel too old” error), but I haven’t been able to build a program using qtbase (for “renameat2”).
<mbakke>rekado: That's too bad. If you can find the Wayland problem, i think it's okay to fix it still.
<mbakke>Otherwise maybe you can fetch the store item from berlin?
<rekado>hmm, I don’t get a substitute from berlin
<civodul>rekado: berlin is building only the "core" subset of packages
<rekado>mbakke: it’s just a test failure and it only happens when NFS is involved. Tried to debug this last time already and had to revert the changes because the build would fail everywhere else.
<janneke[cm]>civodul: no, there is just one i686-linux
<janneke[cm]>civodul: we can even generate the graph on x64_64 using the -e (%current-system i686-linux) trick
<janneke[cm]>%boot*inputs are now all functions
***thekyriarchy[m] is now known as thekyriarchy
***Guest25039 is now known as mattl
<rekado>I’d like to set up a Hurd build VM. I got myself the Debian Qemu image and I guess I’ll need to download or build all Guix dependencies, because the binary installation method won’t work.
<bavier`>rekado: I have a small shell script that installs most guix dependencies. idk if you'd be interested; it might need a bit of updating.
<rekado>bavier`: I’m interested
***ChanServ sets mode: +o lfam
<lfam>What do you call the text that gives information about the IRC channel? The thing that has all our URLs and other info
<lfam>I'm going to remove the part about the logs URL since that hasn't worked for several weeks now
<lfam>Ah, the topic
<rekado>lfam: thanks
<lfam>I'm also going to send a message to guix-devel announcing the change and asking for help getting a new logger set up
<bavier`>it could use a bit of work, but seems to get the job done
<rekado>lfam: I’ve got logs since Aug 22.
<rekado>bavier`: thanks
<lfam>rekado: Oh, is there a public URL? I'll add it to the topic if so
<rekado>lfam: not yet!
<lfam>Okay, for now I'll just remove the link
***lfam changes topic to 'Guix | | 0.15.0 is out! | videos: | bugs: | patches: | paste: | Guix in high-performance computing:'
<rekado>I wanted to do this whenever it is brought up, really, but then there’s always something coming between me and setting up the public URL :)
***lfam changes topic to 'GNU Guix | | 0.15.0 is out! | videos: | bugs: | patches: | paste: | Guix in high-performance computing:'
<reepca-laptop>Is there any particular reason riscv isn't in %qemu-platforms in (gnu packages virtualization), or is it just out of date?
<lfam>reepca-laptop: I think nobody has thought to add it so far
<reepca-laptop>ah. well, that provides some hope for it working, I guess
<bavier`>riscv was added in a recent qemu version, right?
<reepca-laptop>not sure, but it's in the version of the source we use
<reepca-laptop>Hmm, trying to run "sudo ./pre-inst-env guix system blah blah blah" but get guix: system: command not found. Any idea what's up with that?
<rekado>reepca-laptop: is guile-sqlite3 on the Guile load path?
<rekado>reepca-laptop: you won’t have this problem with Guix from “guix pull”; when using pre-inst-env, however, you may want to use “guix environment guix”
<reepca-laptop>already in "guix environment guix"
<reepca-laptop>... oh... sudo is overwriting the "guix environment guix" variables...
<tune>someone was telling me recently to use sudo -E to preserve the environment variables from the user
<reepca-laptop>aye, that's what I'm doing now and it's going smoothly so far
<reepca-laptop>thanks y'all
<apteryx>hello, I've built a modified package using the --with-source=mypackage=./mypackage.git successfully. Can I now update the mypackage found in my profile to this transformed version?
<dustyweb>civodul: heya
<dustyweb>civodul: preview of that paper thingy
<civodul>apteryx: sure, you need to run "guix package -i mypackage --with-source=..."
<rekado>channel logs:
<rekado>it isn’t pretty, but it seems to work
<lfam>We need to set up a cron job to renew the TLS cert :)
<janneke>rekado: pretty nice
<civodul>dustyweb: it's awesome!
<civodul>i like it
<civodul>the code seems to be quite compact, that's nice
<rekado>lfam: nginx needed to be restarted.
<lfam>Aha :)
*civodul wonders what the deal is in Racket with #"foo"
<rekado>hmm, apparently there’s no guild executable when I install guile on Debian
<dustyweb>civodul: :)
<dustyweb>is there anything you think I should change about the design?
<dustyweb>as said at the bottom, it's not doing some things like compression/mutability (those can be composed with it but aren't done in the spec itself) but I wonder if I've had any oversights in the design that should be corrected
<civodul>dustyweb: not having mutability is fine IMO, though it raises garbage-collection issues
<civodul>re convergent encryption, it might be worth noting that it's vulnerable to "confirmation attacks" (where you can tell whether a server stores an item you also have)
<civodul>which is OK in some cases, and maybe not in others
<dustyweb>civodul: ah yeah, I just pushed some information about that
<dustyweb>civodul: and also "learn-the-rest-of-the-information" attacks :)
<dustyweb>civodul: I think the way tahoe deals with GC issues *iirc* is that files are kept around based on how recently they've been accessed
<dustyweb>"touch" to renew lease, effectively
<dustyweb>or "fetch", more accurately
<dustyweb>or at least I think that's what zooko told me was the default years ago
<civodul>also as long as it's a centralized server, it's easier to do an LRU GC
<civodul>least-recently used, as you wrote
<dustyweb>ah yeah
<civodul>re manifests, did you consider making a Merkle tree? :-)
<dustyweb>probably worth mentioning the LRU stuff
<dustyweb>civodul: I did but then I thought it was too much work!
<dustyweb>civodul: but maybe I'm wrong?
<dustyweb>civodul: doing a linear list of chunks just felt so easy...
<civodul>one advantage of manifests is that you can fetch the whole thing in two round-trips only
<civodul>whereas with a Merkel tree you'd have O(log n) round-trips i think(?), where n is the number of chunks
<dustyweb>civodul: as you probably saw I also added some typing information so that if your file fits within the size of a chunk, there's an optimization where it's just one fetch :)
<civodul>so on http, you can (1) GET the manifest, and (2) pipeline all the GETs for the blocks
<civodul>dustyweb: oh cool, i had overlooked that :-)
<dustyweb>civodul: yeah, so you fetch one of two csexps:
<civodul>what if the manifest itself exceeds the chunk size?
<dustyweb>(raw <data>)
<dustyweb>(manifest <chunk-size> <file-size> <url1> <url2> ...)
<civodul>ah right
<dustyweb>civodul: it rounds up to the nearest multiple of the chunk size
<dustyweb>so, you might find out *some* size information
<dustyweb>but really it's very loose
<civodul>at least you can find out which thing is a manifest since only manifests can exceed the chunk size
<dustyweb>you can find that out!
<civodul>and from that you can deduce the file size
<dustyweb>for bigger files
<civodul>but yeah, it's very coarse
<dustyweb>well, deduce some range of megabytes
<dustyweb>I should mention this though
<dustyweb>and the GC stuff
<dustyweb>adding both of those!
<dustyweb>it was nice that this idea was simple enough to implement in one day though
<jonsger>civodul: do I need now guile-gcrypt at runtime? My package at opensuse just have libgcrypt at runtime (/usr/lib64/ et. al). guix hash/download seem to work fine
<jonsger>civodul: already answered that question
<civodul>dustyweb: you've very efficient! (and Racket has all the right libs maybe?)
<civodul>jonsger: it's needed at run time, but 'guix pull' pulls it
<jonsger>yeah. I somehow hat the guile-gcrypt package already installed because I packaged it :)
*ecbrown wonders if guile-ssh (for offload builds) is/ought to be installed by default
<civodul>ecbrown: 'guix pull' pulls it too :-)
<civodul>whatever the problem, 'guix pull' is part of the solution
<lfam>I'm trying to match a string like this for substitute*
<lfam>How do I properly escape this?
<civodul>you sure you want to do this? :-)
<lfam>No! I might rather just disable the tests
<civodul>my guess: "PATH=/bin:\\$\\{ZTST_testdir\\}"
<lfam>I've already spent too long on this
<lfam>Okay, thanks
<civodul>you can check at the REPL with string-match
<civodul>i was looking at gpgv, which takes a --keyring option; that thing must be a "keybox" file, i couldn't find a way in gpg to create such a file
<civodul>anyone know about this?
<civodul>apt uses gpgv so there must be something somewhere
<lfam>civodul: Check the docs of `kbxutil`
<lfam>you sure you want to do this? ;)
<civodul>i had seen this in the manual, but the manual doesn't mention --import-openpgp...
<dustyweb>civodul: what do you think of this update?
<civodul>dustyweb: LGTM; i think the document is thorough, which is nice
<dustyweb>civodul: means a lot coming from you :)
<civodul>given that i'm a professional nitpicker? ;-)
<dustyweb>civodul: and an expert in the topic!
*civodul -> zZz