<roptat>I feel efficient this morning :) <pkill9>is there a substitute command that takes a raw string instead of regex? <brendyyn> Transliterate the characters in the pattern space which appear in source to the corresponding character in dest. <pkill9>i managed to replace the string i needed to replace <brendyyn>I wonder if scheme regex's are worth using <roptat>mh... this groovy update is going to need junit5 <roptat>which is the reason why I need junit5 in the first place... <roptat>and it's going to add a lot of other packages to this dependency cycle <pkill9_>how do I apply a patch that's stored in a variable as raw text? <efraim>if 'git am' doesn't work then I go for 'git apply' <efraim>unless you mean as part of the build process <efraim>if 'git am' doesn't work then I go for 'git apply' <efraim>I think I have a workaround for the glib-networking test failure on armhf on staging <efraim>also I want to change meson-build-system's 'check phase to (invoke "meson" "test" "--print-errorlogs") <efraim>i'll have to look at 'meson test -h' some more to figure out how I'd want that to look <pkill9_>efraim: I mena as part of the build process yeah <efraim>pkill9_: I think then you'd use 'patch' directly, IIRC afl does something like that <roptat>is there a procedure to remove the last 5 characters of a string in guile? <roptat>string-drop-right it seems, thank you! <efraim>civodul: 'guix pull --system=%arch' builds 'the outputs of 'guix pull' for %arch or actually changes the installed architecture? <efraim>"Parse the @code{source} URL to determine if a tarball from GitHub is autogenerated or if it is a purposefully prepared tarball. Unfortunately GitHub's autogenerated tarballs are sometimes regenerated." <efraim>I'm thinking s/purposefully prepared/release/ <roptat>junit5 ultimately depends on kotlin <roptat>oh no, another cyclic dep involving junit5 :/ <roptat>ok, I'm going to work on my scala compiler instead <civodul>efraim: it builds for ARCH, which is generally not useful but could be useful in some cases <civodul>rekado_: x15.sjd.se is back behind berlin (it lacks 'guix repl' until now so i had to pull, which isn't easy on that machine...) <civodul>efraim: do you think you could find a way to make the overdrive reliably available? <civodul>it would help a lot to have it behind berlin <archetyp>Hi, onother fresh GuixSD installation! 8-) <civodul>rekado_: FYI i've just reconfigured berlin <pkill9_>is it possible to specify required channels within a channel repository so that guix automatically gets the additional channel as well when you add the main channel? I *think* I read somewhere that that was added but I can't seem to find any mentions of it, so I dunno <civodul>pkill9_: yes there are now "channel dependencies" <civodul>channel authors can drop a .guix-channel file that specifies the channel's dependencies <civodul>ah it's not in the on-line copy of the manual, which is for 0.16 <civodul>you should see it if you run "info guix" on a recent install, though <pkill9_>ahh that must have been where I saw it, thanks <pkill9_>my second question is, do these channel dependencies augment the user's whole guix, or just the channel itself, so for example, would you be able to install the packages from the channel dependency when you run `guix package -i ___` and see them with `guix package --search`, etc? <allana>Is there a way to do a reverse lookup for an executable installed by guix? I want to know how a package on my path was installed. For example, what package includes basic commands like "cat" or "pwd"? ***rekado_ is now known as rekado
<rekado>allana: the answer for this particular question is “coreutils”, but there’s no generic way to do a reverse lookup (yet). <rekado>civodul: all of the x86 build nodes attached to berlin have been reconfigured with a recent-ish version of Guix yesterday. <rekado>I hope I can do the next reconfiguration with a script. <rekado>I tried to build the system on berlin (using offloading), copy it over along with the same version of Guix that built it on berlin, and then reconfigure the same system on the remote, but that wasn’t as successful as I hoped. <rekado>without grafts it would almost be what I wanted. A few packages unexpectedly needed to be built locally. <rekado>but with grafts enabled quite a few packages had to be built on the target, which was unexpected. <rekado>even after transferring the outputs to the target with “guix copy” more derivations had to be built than I would have thought. <bonfus>Hi, I'm still playing with guix on Sailfish OS on my arm phone. I tried to `guix pull` but it fails while testing python3.7. The problem seems to be related to os.openpty() (which apparently raises FileNotFoundError). Ever seen anything like that? Why python 3.7 is built from source instead of taken as binary? <rekado>bonfus: a binary substitute may not be available for your architecture and the version of Guix you are using. <rekado>this might be a temporary problem (i.e. the package is still being built) or it could have been a build failure that has been cached. <rekado>or it could be that you are the first to request the substitute and it has not been “baked” yet. In that case you can retry after a few minutes. <allana>Is there a canonical way to handle tests that expect root permissions? I'm guessing that there isn't. <allana>And that those test should be skipped <civodul>that'd mean reconfiguring them again :-) <rekado>I wanted to play with it, but a dependency has failed tests on berlin. <rekado>net-snmp has one failing test on berlin, but it passes elsewhere. <rekado>I decided not to shave that yak at that time :) <civodul>offloading seems to be working well now <civodul>we're spending quite some time waiting for the arm machines to build useless stuff though <civodul>like disk images, system tests, etc. <civodul>we should disable those, probably once wip-ci-inferior is merged <rekado>oh, net-snmp built fine with the current version of Guix on berlin.