<steggy[m]><guerrilla> "Ok, so I've had bluetoothctl..." <- Late but my 'dumb' answer would be to define your own package(or modify the rfkill package) to include chmod'ing after installing, e.g. ```(modify-phases %standard-phases <steggy[m]> (chmod "/dev/rfkill" #o755))))``` Whether that's a good idea I have no idea, but that's how I'd approach getting it in as part of the config <mbakke>civodul: those are some impressive sizes :-) <civodul>mbakke: yeah well ok, but they don't say what it contains <civodul>we do have impressive closure sizes too (just for the opposite reason) <civodul>look, we can fit coreutils in 92MiB, which is almost twice the size of "Debian" in their README <char>What package do I need to install to get ld.so? <raghavgururajan>mbakke: Are substitutes for core-updates-frozen served at ci and/or bordeaux? <mbakke>raghavgururajan: yes, but there was a recent world rebuild, so substitutes may not be available for the latest commits <lilyp>I lol'd at "Distroless images are based on Debian 10" <dstolfa>distroless is an extremely peculiar term, especially since it begins with a distro. <lilyp>Imagine we had used that term first. Then we'd have the Distroless System distro <dstolfa>distroless guix system (managed by guix, duh) <lilyp>Almost as funny as /homeless-shelter :P <roptat>char, that would be glibc, probably the 32-btis version? ***lukedashjr is now known as luke-jr
<singpolyma>Hello all! Noobing my way around guix land again, I have a question: is there any way to install a package "globally" instead of to a single user's profile when using guix on debian instead of as the whole system? <vagrantc>well ... i guess you could create /etc/profile.d that sources a specific guix profile amoung all users ... <singpolyma>Ok. So I just need to guix package -i as each user that wants to run a particular command? I guess that's basically free to do, yeah? <vagrantc>well, you could maybe work around by having userX also pull in userY's profile, and userY is where you'd install the "global" packages ... <vagrantc>or a specific profile, rather than a user's default profile <Hydragyrum>I'd think having a special user for system profiling would be better? that way you don't need to give read access on /root, and no normal user has write access to the profile <podiki[m]>anyone familiar with cmake and cmake-build-system? I have a package which runs the compiled binary to produce udev rules, trying to write to /etc <vagrantc>all sorts of ways you could hack around it ... <podiki[m]>but nothing happens (no error, warning, or files) <vagrantc>podiki[m]: runs the compiled binary at build time? <podiki[m]>I get the message it outputs in that phase to stdout so I know it tried at least <vagrantc>podiki[m]: might patch the binary to install somewhere in the profile? or patch out that cmake rule ... ? <vagrantc>er, not profile ... somewhere in the output <podiki[m]>I did patch it to output to lib/udev/... but still nothing... <podiki[m]>i would have thought guix would complain about that part trying to write to /etc, or automatically wrapped to be within the build dir. not sure what is happening <podiki[m]>I guess I could do this as a build phase in the package def, but seems silly to rewrite what cmake is (supposed to) be doing <podiki[m]>is it because cmake is not running an 'install' on this file? is that how it should be done? <podiki[m]>ok, had to make the directory (in package def) since I guess that incantation of cmake install code doesn't ***lukedashjr is now known as luke-jr
<EdLin>is there a way to upgrade your kernel besides guix system reconfigure /etc/config.scm? <EdLin>it seems to reinstall the whole system rather than upgrade <guerrilla>EdLin: That's what I did. If you've done a guix pull, then there will be more than just the kernel to update. <jackhill>EdLin: yep, I agree with guerrilla, that seems normal. If you wanted to just get at kernel from a different version of Guix, and leave the left of the system alone, there are ways to do that (search for inferiors in the documentation), but that's definitely a more advanced usage <muradm>civodul: oh great, thanks.. i gets i wasted night of cpu build load then :) <muradm>sneek: later tell cvodul: oh great, thanks.. i gets i wasted night of cpu build load then :) <muradm>how do you decide it is worth to use new commit to guix by looking at weather and/or ci.guix.gnu.org? <jackhill>theruran: I haven't. I'm wary the building it from source to be a difficult task, but it would be really neat to have so I'd be happy to be wrong :) ***lukedashjr is now known as luke-jr
<dhruvin>"guix build guix --with-branch=guix=master --without-tests" should always build right? <dhruvin>Alternatively, Do we push commits to guix's master branch that may prevent guix from building? <civodul>dhruvin: hi! commits that break things on master should be very rare <karmayogi>At present guix generates a docker container image, is it possible it can generate a LXD container image? <civodul>karmayogi: hi! "guix pack" has several backends so we could imagine implementing an LXD backend <civodul>however, could it be that LXD understands the Docker/OCI format? <karmayogi>LXD do not understands Docker/OCI format because it pre-dates Docker. Indeed Docker itself initially used lxc then built their own lib. LXD container acts like a full VM and supports multi-process along with init, in Docker/OCI world multiple process within a container is discouraged. <karmayogi>One can run Docker container within LXD by nesting, but its not elegant. <attila_lendvai>if i have a .envrc then emacs hangs whenever i switch buffers. is there a way to speed this up, or turn it off, so that i can initiate it manually? <attila_lendvai>nm, i have realized that it's cached. i was just modifying the file regularly. <attila_lendvai>err, well, it's not. i was just switching between buffers both under the same project *muradm tired compiling stuff... wandering when ci will do rust <attila_lendvai>oh, that's why i'm having so many local recompiles working off of master? <attila_lendvai>so, the bootscript.sh script of boost prints an error because it uses `which`, which is not recorded as a native-input. but then everything seems to work. is this a but that i should send a patch for, or should i just ignore it? <maximed>attila_lendvai: Does this cause a build failure of some package? <maximed>If you mean that "boost" fails to build because it is missing 'which' among its native-inputs, I would recommend adding 'which' to its native-inputs <maximed>(packages failing to build is a bug) <attila_lendvai>maximed, i haven't observed any failure besides the printed error *muradm frying some eggs on a laptop after 18 hours non stop compiling... :) <roptat>I'm waiting for the new rust chain, before I start compiling core-updates-frozen again ^^' <muradm>roptat: how do you check if it is ready? <roptat>I just wait for the email saying it's merged :p <muradm>:D i tough waiting for new rust chain to compile on ci :D <lfam>Does anybody know how to test if a string is a number (integer or with decimals) in Posix shell (ideal) or Bash? <lfam>Is the only solution a regex? <lfam>There is integer math built in to `test` but I need to handle decimals <nckx>lfam: I don't care about POSIX so would pass "${string//./}" to whatever ‘test’ test you're using. <lfam>I don't need POSIX, so I'm game <lfam>Can you give an example? <nckx>Well, for bash, I personally just test whether "${string//[0-9.]/}" is non-empty, because the first solution I found as a child and now it's a habit 😛 <muradm>lfam: if that number is very important, once i had to use bc <lfam>True, 1.2.3 is not technically a number <nckx>roptat: It's trivial to limit to a single . if you care. <lfam>Basically I need to distinguish between a software version such as 1.2.3 and a string <lfam>I suppose this use case is pretty weird and wouldn't be accounted for in the standard tools <lfam>And the right answer is to use getopts but I want to be lazy <nckx>What's wrong with a regex though? <nckx>I think that's the clearest unless you're trying to golf the system. <nckx>Especially if you want to accept negative and .style numbers… <lfam>Nothing is really wrong with a regex. I just won't be able to remember how it works later <lfam>But I will use a regex if necessary <lfam>And I don't need to handle negative or .style <nckx>I think a regex is 1% more readable than anything avoiding one, but that's certainly personal. <nckx>What are you making anyway? ☺ <nckx>roptat: I agree that the -security discussion should be brought to -devel (but thanks for erring on the side of caution!). <roptat>I'll send a message to -devel then :) <lfam>nckx: I'm extending the functionality of the "fetch kernel deblob script" thing to be able to handle the deblob revisions <lfam>So currently it's like `fetch 5.14.2 5.13.15 5.10.63` <lfam>And I want it to take an optional argument in $1 that would be the deblob revision <lfam>I figured that distinguishing between "string" and "numerals with decimals" would do the trick <lfam>Since these scripts must be passed down to new packagers, I want them to be as simple and unclever as possible <lfam>I want to avoid the common pitfall of making a shell script that is write-only <muradm>i run guix environment --ad-hoc dovecot, now dovecot has libexec/dovecot-lda executable <muradm>how do i refer to it from command line? <singpolyma>If I'm writing software and I want to work on it with guix and deploy it as a guix package in a custom channel, should I make a manifest.scm or just write a package definition? Is there any way to convert from one to the other? I think guix environment can accept either? <muradm>GUIX_ENVIRONMENT/libexec ... hmm <lfam>singpolyma: Manifests and package definitions are different things <lilyp>singpolyma: packages are for standalone packages, environments for package collections and system for... well, systems <nckx>$(command -v dovecot)/../../libexec/dovecot-lda 😈 <nckx>I'm honestly not sure whether GUIX_ENVIRONMENT is API. <singpolyma>Sure, but a project specific manifest just defines the dependencies same as a package definition must, so it's the same data <lfam>singpolyma: In any case, you'll need to define the package. Whether or not you use a manifest for deployment depends on your use case <lfam>So, it depends on if it makes sense to model your thing as a package, or if it instead a collection of packages <lfam>Like, there are "meta-packages", such as the gnome package <singpolyma>Right, so just define the package and feed that to guix environment when working on it <lfam>I think that would be what I try first <lfam>Especially during development <lfam>I think the ideal solution will depend on the details <nckx>lfam: I think regexes are the clearest way to ask ‘does x look like a y’. Especially if you put it in a well-named is_deblob_revision function I really don't think it qualifies as esoteric. <lfam>Thanks for thinking through it for me nckx :) <nckx>Compared to clever ways to avoid regexes I mean. <lfam>I just hoped there was something like `test -isnumber` but as roptat pointed out, 1.2.3 is not a number <singpolyma>It seems kind of like manifest is analogous to Gemfile and package is analogous to gemspec (for a ruby ecosystem example) -- it is common to write a Gemfile that just says "all the dependencies from this gemspec please" I guess I was thinking if some analogous scheme could ingest the package and be a manifest of the dependencies <nckx>lfam: Your question was interesting because it's not the usual (to me) ‘is this a number *bash* can operate on’. <nckx>And yet you have no need to operate on it and pull in bc. <nckx>I'm procrastinating again. o/ <lfam>Really I should just make it do `fetch --revision foo 1.2.3` <lfam>My laziness is making things harder <nckx>Bash and DWIM do not tend to mix well. <nckx>That's not true, they mix dangerously well, only the mixture is often explosive. <civodul>nckx: $GUIX_ENVIRONMENT is API, documented and all :-) <nckx>Thanks. Then it's obviously the way to go. <jackhill>singpolyma: that is clearly posible since `guix environment <package>` instantiates such a profiles, but I'd have to go looking to see how it is surfaced at the scheme level <nckx>guix system: error: all build users are currently in use; consider creating additional users and adding them to the `guixbuild' group <nckx>(This was during grafting, which tinkles a bell.) <lfam>I'm never sure why that situation arises <civodul>nckx: you have --max-jobs > 1, right? <lfam>What can cause Guix to try to spawn more processes than specified in --max-jobs? <civodul>lfam: --max-jobs is per-session (so per-client, roughly), so if you have several clients building things, you can run out of build users <nckx>Yeah, but no concurrent ‘guix’ invocations. <nckx>So guix is launching subguixes (to graft perhaps)? <civodul>perhaps looking at "sudo guix processes" could give hints <nckx>It doesn't run long enough or I missed it, but I'll keep doing so. <nckx>It's not a serious problem for me, I just thought this had been fixed. <podiki[m]>can anyone help with writing a shepherd (user) service? I have the basics, but trying to get the command it is running to redirect output to logger <podiki[m]>I don't think shepherd likes the long command with redirection (which would work in a shell), but I'm not finding the docs on log-file options <nckx>If you want to write shell script code, you need to launch a shell (untested): #~(make-forkexec-constructor (list #$(file-append bash "/bin/bash") "-c" "blah blah > foo foo")) <nckx>But if all you need the bash syntax for is to redirect output, make-forkexec-constructor has a #:log-file keyword specifically for that. <podiki[m]>I was looking for docs on that, will it just be doing that same redirect, so I can give log-file "logger --tag" etc.? <podiki[m]>no, then it takes that as a file name....so I must need to do something else <nckx>You mean pipe (|)? No, it won't do that. Use bash for that. <nckx>Or deal with Guile's baroque procedures to set up pipes. <nckx>I recommend launching bash. <podiki[m]>okay, thanks. so right now log-file will only redirect to an actual filename <nckx>‘right now’ - it always will. <podiki[m]>my goal btw is to get some user services and have the output to syslog so I can see it all together <podiki[m]>or is there a way to have sheherd output all go somewhere? can I just start shepherd with its output piped to logger? <nckx>Yeah, logging in Shepherd is… primitive at the moment :) <nckx>I've never tried that podiki[m]. <nckx>Some daemons provide their own --log-to-syslog switch, which Guix then uses. I've never heard of darkman but check its --help just in case. <podiki[m]>do we have any packages that provide sherherd service files for a user to run with shepherd? (as opposed to a full system service) <podiki[m]>I feel like that would fit as a nice replacement for systemd user services <dstolfa>i thought that's what guix home gave us? <nckx>I haven't tried guix home yet, but unless that's what it provides: no. <dstolfa>but my understanding was that it allowed for user shepherd <lilyp>Guix home allows users to specify some shepherd services and probably has some definitions out of the box <lilyp>As for packages that ship them by themselves... shepherd isn't that mainstream yet <nckx>dstolfa: User shepherd has always works, guix home just manages it for you. Just don't ask me how. <podiki[m]>I was thinking to provide the sherherd service through the package definition, at least until such a thing would make sense to submit upstream <dstolfa>nckx: yeah, poorly phrased by my part <nckx>Oh, I didn't mean it as criticism. <nckx>Shepherd user services were always a thing but not well-known at all. If guix home changes that it's already won. <podiki[m]>I'm not a heavy system user service person, but is nice for a few background stuff where I want to be able to stop/restart/see logs <podiki[m]>and writing in guile over systemd configs is a win to me too <nckx>So systemd does run everything through a shell? (Based on what I guess is your initial port of your systemd service above :) <podiki[m]>I'm not sure the internals, but it hooks into journalctl <podiki[m]>so all the output is available there, labeled by unit <nckx>…which I, in turn, don't know much about. :) <podiki[m]>if I remember, the systemd exec would just be "darkman" in this case, with all output captured by journalctl <podiki[m]>what I found nice is that it is central and has builtin tools to get messages just from a service, from last boot, a time frame <nckx>Shepherd definitely doesn't have that [yet]. <nckx>Frustratingly so, but I'm sure it will happen some day. <podiki[m]>perhaps it would make sense to have a separate (guile) logging tool? <podiki[m]>(I have no idea how tightly wound journalctl and systemd are) <dstolfa>there are lots of things that could be improved upon in shepherd, but it is a very easy codebase to modify in a way... i keep trying to, but i keep getting this weird error code every time i open shepherd's code: ENOTIME <nckx>Quite, from my limited understanding. <nckx>But in the same way that Guix and Shepherd are tightly wound. It's not a value judgment. *nckx feels need to distance self from vocal… people :/ <podiki[m]>side question, what is the preferred hashbang in guix? <lilyp>just use whatever you'd have on traditional distros and let guix patch it <podiki[m]>and for writing a script on a guix system (not in a package)? <nckx>If you mean for personal (e.g. ~/.local/bin) scripts: #!/usr/bin/env sh works on stock Guix Systems. <nckx>So does #!/bin/sh, but that's less supported on other distributions. <maximed>To test a patched daemon: "sudo herd stop guix-daemon && sudo ./pre-inst-env guix-daemon --build-users-group guixbuild"? <maximed>Anything special I should be aware of that could store corruption? <nckx>Make sure you've configured with --localstatedir=/var. <nckx>It should be a rather routine thing, BTW. It shouldn't be or feel risky or unsupported. If anything fails that doesn't otherwise, it's a valid bug! <maximed>Does someone know a command-line tool like the "time" shell built-in, automatically repeating the command a few times to compute the average and stddev? <dstolfa>yeah, hyperfine is a pretty good one *apteryx puzzled why 'guix refresh -u mailutils' can't fetch the key while 'gpg --receive-keys 325F650C4C2B6AD58807327A3602B07F55D0C732' works fine. <maximed>Can running "./pre-inst-env guix daemon ..." while there's still a guix-daemon unning cause problems? <maximed>Or starting "sudo herd start guix-daemon" while ./pre-inst-env guix daemon is still running? <maximed>(I didn't do that, but somehow guix-daemon appeared in htop even though I killed the ./pre-inst-env guix-daemon) <maximed>(And the substitute urls are different) <nckx>I thought it would choke on the socket in use? <maximed>I presume yes, since pulling the power cord didn't cause problems in the past <nckx>Sending TERM should be OK. <nckx>Note that the Shepherd will try to respawn its instance. <maximed>I ran "sudo herd stop guix-daemon" and "sudo herd disable guix-daemon" before "./pre-inst-env guix-daemon" <maximed>... maybe interrupting "./pre-inst-env guix-daemon" didn't kill the guix-daemon? <nckx>(It cleans up nicely here, is all that I can.) <lfam>apteryx: It's probably because %openpgp-key-server points to the defunct SKS network <lfam>There isn't a meaningful keyserver network anymore so we should use either Ubuntu's keyserver or keys.openpgp.org/ <lfam>I don't think it uses HTTPS <lfam><hkps://keyserver.ubuntu.com> <nckx>Did you get that https:// from anywhere in Guix? <attila_lendvai>so, i have two innocent looking commits on top of current master. a guix build some-package seems to be rebuilding the world. is that expected? if so, then is there a way to avoid this? e.g. base it off of another branch? <maximed>attila_lendvai: What files did the commit change? <lfam>Rather than files, what code was changed <maximed>guix/build/utils.scm is used (indirectly) by almost every package <maximed>changing wrap-program->wrap-script in python-build-system rebuilds every python package and their dependencies <attila_lendvai>and the other one changes wrap-script. so, this is my fate then... :) i wonder how long it will run on a 4 core laptop <lfam>It will probably take a few days <lfam>Although it depends what packages you want to build <attila_lendvai>lfam, i'm building serf because this was the first point where my change broke (use wrap-script where possible and fall back to wrap-program in python-build). that's why i applied the other fix to wrap-script, hoping that it'll fix it, and this led to the long rebuild. <lfam>If your package depends on rust it will probably take a couple weeks to build through the rust bootstrap <lfam>It's probably worth renting a powerful server for this <lfam>Or finding a way to avoid rebuilding everything while testing your change <lfam>You could make a copy of the functions you are changing and put them somewhere besides (guix build utils) and test them from there <lfam>For Python-only dependency graphs, the full rebuild time will not be too bad, maybe a day <lfam>It depends on what 4 cores you have <attila_lendvai>i'll just resort to patching the package instead of doing the right thing. i'm too new to all this for navigating through a change with such a big effect... <lfam>Yeah, changes like these have to go through the core-updates cycle <OJ[m]>I've been looking at package-input-rewriting for most of today, so I could replace jack-1 with jack-2 in packages and I haven't been able to figure out how. I'd like it if it worked automatically for every package that I have installed and has jack-1. <nckx>Fixes CVE-2021-33285, CVE-2021-35269, CVE-2021-35268, CVE-2021-33289, CVE-2021-33286, CVE-2021-35266, CVE-2021-33287, CVE-2021-35267, CVE-2021-39251, CVE-2021-39252, CVE-2021-39253, CVE-2021-39254, CVE-2021-39255, CVE-2021-39256, CVE-2021-39257, CVE-2021-39258, CVE-2021-39259, CVE-2021-39260, CVE-2021-39261, CVE-2021-39262, CVE-2021-39263 *nckx leaving, but maybe you can share the closest you think you got, and the errors (if any), OJ[m]. <OJ[m]>Well, really, the closest I got is using --with-inputs for an environment, but that's not what I want. :p <OJ[m]>Then again I put a file in GUIX_PACKAGE_PATH hoping it overrides a couple things. <OJ[m]>Somebody can probably tell me how dumb this is. <lfam>nckx: And that's only the 2021.8.22 release! Maybe intermediate releases fix some other CVEs too <attila_lendvai>wrap-script identifies guile by a keyword arg defaulting to (which "guile"), i.e. scanning the current $PATH. this is not smart... and unsurprisingly it fails in my --pure build env. <nckx>Yes, packages using wrap-script are expected to include guile(@3) in their inputs. <nckx>Doing anything else (🌈 magical 🌈) sounds like opening a family pack of wyrms, but I don't know if that's been explicitly discussed. <nckx>(Yes, wrap-program is magical already.) <attila_lendvai>nckx, guile.scm contains countless package definitions. which one? there's no 'guile' in there. *nckx eyes $partners NTFS thumbdrives with new-kindled fear; upgrades. <apteryx>Why does 'guix environment -C' leaves /bin/sh? should we fix this? *attila_lendvai is grateful for all the help, but gives up for today... o/ <apteryx>that's a constant thing to remember to do when troubleshooting build discrepancies between the build environment and that created by guix environment -C: rm /bin/sh <iskarian>apteryx, a comment in the source states: "Containers need a Bourne shell at /bin/sh" <civodul>apteryx, iskarian: it's mostly out of convenience: since "guix environment" spawns a shell, it needs to have one <civodul>or you mean it could have one but not link it to /bin/sh? <lfam>nckx: Can you check that you can still access those NTFS filesystems with the update <apteryx>civodul: right; I think it'd be nice if 'guix environment -C' was a look-alike as the build environment of the guix-daemon as possible <apteryx>/bin/sh seems the glarring exception so far <apteryx>it'd be ok if 'sh' was in PATH of the container, without having to appear at /bin/sh <apteryx>emacs doesn't seem to make use of its mailutils source <apteryx>*** Mailutils movemail will now be used if found at runtime. <apteryx>it'd add 20 something MiB to the closure. Perhaps wiser to remove it, leaving the Gnus users of such feature to install it themselves? <apteryx>but since that was added for security (Emacs has an internal movemail implementation which doesn't support secure POP), it's perhaps wiser to patch movemail <apteryx>nckx: does the gpm input really does something for Emacs? it doesn't seem to be recorded as a reference according to 'guix gc -R (guix build emacs)' <civodul>maximed: i keep getting distracted (in a good way) by the patches and ideas you send :-) <civodul>the other day it was source location, this time it's base32 <nckx>apteryx: It adds gpm support? But you knew that much since you git blamed me, so I'm confused 😛 <nckx>It's still working fine here, although I'm a few weeks or so behind master.