*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>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/FileUtils.pm 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? ***rekado_ is now known as rekado
<rekado>civodul: for attached Scheme files (with filenames ending on “.scm”) there’s now syntax highlighting in mumi. <rekado>the CSS could still be tweaked somewhat; I took it from the Guix blog. <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... <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>jonsger: should be a bit better now <civodul>i had a look weeks ago, thought i had understood, but actually no :-) <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 <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 <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 <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 <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>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>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 <efraim>I'd take devuan out of the list and add trisquel and parabola, as being FSF approved <roptat>so, in the sense that we try to be easily hackable and extensible <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 :) <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? <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 <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 <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>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: hpc.guixsd.org/browse <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>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>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>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 <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 <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 <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 <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 <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 <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>this is in a guix package -u <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 <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". <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 hydra.gnu.org in "best effort" mode from now on <civodul>and push a 0.15.1(?) release real soon that has berlin as its default <efraim>We should bump for 0.15-3 with the channels update <mbakke>Hopefully Hydra becomes faster with less traffic, so we can keep using it's CI features until Cuirass catches up. <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>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. <snape>civodul: hmm right, we're in a hurry <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>i think it should be handy for your use cases <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. <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>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>“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. <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>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
<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 <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 <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: we can even generate the graph on x64_64 using the -e (%current-system i686-linux) trick ***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. ***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>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. <lfam>rekado: Oh, is there a public URL? I'll add it to the topic if so <lfam>Okay, for now I'll just remove the link ***lfam changes topic to 'Guix | https://gnu.org/s/guix/ | 0.15.0 is out! https://gnu.org/s/guix/blog/2018/gnu-guix-and-guixsd-0.15.0-released | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guixsd.org'
<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 | https://gnu.org/s/guix/ | 0.15.0 is out! https://gnu.org/s/guix/blog/2018/gnu-guix-and-guixsd-0.15.0-released | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guixsd.org'
<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 <bavier`>riscv was added in a recent qemu version, right? <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>... 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 <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? <civodul>apteryx: sure, you need to run "guix package -i mypackage --with-source=..." <rekado>it isn’t pretty, but it seems to work <lfam>We need to set up a cron job to renew the TLS cert :) <civodul>the code seems to be quite compact, that's nice <rekado>lfam: nginx needed to be restarted. *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>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>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>re manifests, did you consider making a Merkle tree? :-) <dustyweb>civodul: I did but then I thought it was too much work! <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>(manifest <chunk-size> <file-size> <url1> <url2> ...) <dustyweb>civodul: it rounds up to the nearest multiple of the chunk size <dustyweb>so, you might find out *some* size information <civodul>at least you can find out which thing is a manifest since only manifests can exceed the chunk size <civodul>and from that you can deduce the file size <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/libgcrypt.so 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>PATH=/bin:${ZTST_testdir} <lfam>How do I properly escape 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 <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>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... <civodul>dustyweb: LGTM; i think the document is thorough, which is nice <civodul>given that i'm a professional nitpicker? ;-)