IRC channel logs
2023-01-04.log
back to list of logs
<ham5urg>The next problem I have with that nasty VPS/container is, that it mounts '/' at boot. No entry in /etc/fstab in the original OS. Some kernel command line at boot time I guess if it is a VPS. Now I get 'gnu/system.scm:835:2: error: missing root file system', can I let this unconfigured too? <bjc>it's been a while since i messed with this stuff, but i think you need a root file system or guix will yell at you. however, since the bootloader is what's responsible for mounting it, guix assumes that by the time shepherd has started the root has been mounted <bjc>so if you don't go through grub, then something has to be responsible for starting pid 1. and i don't think that exists in the standard location (ie /sbin/init) on guix, but buried somewhere in the store <bjc>about a year ago i had some experiments that i abandoned for creating a stable location for shepherd so i could start it from nspawn containers, and made some progress, but i stopped using nspawn since then, and abandoned the project as a result <ham5urg>bjc, yes, I believe too that GUIX will not start as /sbin/init is not at the place where the hosts kernel will expect it. I can close this silly VPS and look out for another host. <oriansj>jgart[m]: the answer to your qutebrowser problem is a known defect with an easy work around: --qt-arg disable-seccomp-filter-sandbox true <mroh>ah, that explains why I have no fonts in kiwix-desktop. thx! <apteryx>hm. the Windows / Firefox 83 user-agent trick stopped working to sign-in gitlab from Icecat <apteryx>hm. security-key 2FA doesn't seem to work with Google using ungoogle-chromium <KarlJoad>What is the syntax to specify a specific package output by name? I want the utils output of the "bind" package, without using specification->package. <lfam>"git:send-email" or "bind:utils" <lfam>Oh, you want to avoid using specification->package <KarlJoad>lfam: Yeah. This is for a system definition, so I want to avoid specification->package, in favor of getting compile-time failures about my missing package definition. <KarlJoad>It might be worthwhile to add into the section exactly how to specify a particular package's output to use. Mayhaps I will send a patch?... But I do not want to duplicate the manifest section. <KarlJoad>ACTION is back after getting their Emacs server restarted... <trevdev>Evening 3 of trying to package the most recent LTS version of nodejs. My teeth are getting shorter <trevdev>I did get this thing to build on my system, but in the guix build environment nothing can be found <trevdev>gyp: SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash not found <-- this error message is what I'm working on now <trevdev>"I cannot find the explicit shell you need me to find" <devmsv>Hi, why could it be that'guix home' is not sourcing .profile on foreign distro? <devmsv>if I do . ./profile after 'guix home reconfigure' I get my guix-home profile/env. launching another shell still uses my '.guix-profile' <devmsv>I did read *13.2 Configuring the Shell* top to bottom but I assumed that having your shell managed by guix-home is having 'service home-bash-service-type' in 'home-config.scm'. Guess I'm wrong. *How can I manage my shell with guix home?* <SUPERB[m]>Shall we consider Guix OS as a testing one like Arch or a stable using the latest packages like fedora? <lechner>SUPERB[m] / it's both. cutting edge packages that run super stable! <SUPERB[m]>lechner: You mean itâs stable like fedora? <lechner>SUPERB[m] / not sure about Fedora; i only know Debian <SUPERB[m]>> <@lechner:libera.chat> SUPERB / not sure about Fedora; i only know Debian <rekado>nalaginrut: with the gcc-toolchain package <nalaginrut>I've installed gcc-toolchain, but it still can't find libgcc_s <rekado>SUPERB[m]: stability differs across branches in Guix <rekado>nalaginrut: can you provide more context please? <rekado>SUPERB[m]: Guix from the master branch is generally fit for productive use; most packages build fine, security problems to high profile packages are patched as they become known, etc. <rekado>SUPERB[m]: breaking changes are developed on the core-updates branch, which eventually will be merged into the master branch once it has stabilized. <nalaginrut>I use rustup to install the latest rust stable, but the compiled binary complains libgcc_s.so is missing <rekado>Iâm guessing that youâre not on Guix System, and your systemâs toolchain is also accessible <rekado>perhaps cargo ends up using your systemâs toolchain (with its linker)? <rekado>are the generated binaries linked with your systemâs libraries? <rekado>(you can avoid problems like that by using âguix shell --container --network gcc-toolchain âŚâ, which effectively hides system libs and toolchain.) <rekado>the â--containerâ option causes the process to end up in its own separate namespaces (pid, mount, user, etc); the mount namespace effectively hides the rest of your file system. <SUPERB[m]>I wanna find out if itâs a proper choice just for a regular daily usage or not <rekado>SUPERB[m]: many of us are using it daily <rekado>I use it on any server, workstation, SBC, and laptop <rekado>itâs a very flexible and reliable system <rekado>no other distro ever made me feel like the complexity of configuring and maintaining a system was manageable. <rekado>with Guix System my systems become understandable, the complexity manageable, problems are no longer sudden surprises, rollbacks makes solving problems less urgent <rekado>I can never go back to another distro. <jpoiret>the only hurdle is using not-yet-packaged software, but fhs containers should make that doable pretty easily (haven't tries those yet) <ennoausberlin>Hi Guix. I can not figure out how to install / use emacs-tree-sitter on Guix <ennoausberlin>jpoiret: There is lots of software that is not easily packaged for Guix. But I always look for alternatives then and usually can replace it with better reproducible software (but lose features sometimes) <nalaginrut>rekado: I can find libgcc_s.so with "guix environment gcc-toolchain", but it still SEGFAULT... <rekado>segfault often is the result of forcing together ABI-incompatible libraries. <rekado>if youâve got binaries that have already been linked with your system libraries and then you combine them with libraries from Guix (which are *not* linked with your system libraries) youâll have a bad time. <nalaginrut>rekado: but I saw all libs in ldd are linked to guix-profile stuff <rekado>can you tell us more about the segfault? <rekado>another common source of problems is the use of LD_LIBRARY_PATH or other variables that force incompatible libraries to be used together. <nalaginrut> libgcc_s.so.1 => /home/nalaginrut/.guix-profile/lib/../lib/libgcc_s.so.1 (0x00007fbccce81000) <nalaginrut> libpthread.so.0 => /home/nalaginrut/.guix-profile/lib/../lib/libpthread.so.0 (0x00007fbccce61000) <nalaginrut> libdl.so.2 => /home/nalaginrut/.guix-profile/lib/../lib/libdl.so.2 (0x00007fbccce5c000) <nalaginrut> libc.so.6 => /home/nalaginrut/.guix-profile/lib/../lib/libc.so.6 (0x00007fbcccc9a000) <civodul>unmatched-paren: should we publish your first blog post today? <rekado>nalaginrut: unfortunately, thatâs not a lot of info to recommend anything. Are you sure that this is a problem with Guix? <nalaginrut>rekado: thanks, my original issue is to find libgcc_s, and it's solved with "guix environment" now <ennoausberlin>telmo[m]: It should have a dependency to glibc, I think. But has not. Feel free to send a patch <nckx>telmo[m]: You can use wrap-program after the 'install phase to wrap bashtop's PATH to contain /bin from the build glibc. <ennoausberlin>telmo[m]: python-psutil might be another *optional?* dependency <jlicht>does anyone have mozphab packaged locally? Or some other way to run it on a Guix System? <jlicht>Guix horror stories: "build of /gnu/store/....-python-... failed: No such file or directory: cargo" <yarl>I tried (let's say for fun) to move some macros 'define-enumerate-type', 'operation-id' from guix/store.scm to guix/store-protocol.scm and exported thoses. Then #:use-module (guix store-protocol) and add it to MODULES in Makefile.ac but it doesn't compile ("source expression failed to match any pattern in form (operation-id valid-path?)") <yarl>I am annoyed because I don't understand. <yarl>Can someone give me some help on this? <nckx>You don't sound like you're having fun. <nckx>yarl: I'm not in a position to help, but pasting the *exact* diff somewhere will be helpful to those who are. <yarl>nckx: The fun may eventually be :) <yarl>nckx: paste.debian.net/1266107 <flypaper-ultimat>hey guix! is there a way to silence the progress marker when doing a e.g guix build? I'd like to keep the other information, but not the [### ... ] lines. <sughosha>flypaper-ultimat: is -q or --quiet what you want? <yarl>Hmm I can't reproduce this problem with a minimal example. <yarl>Maybe this comes from how guix compiles? compile-all.scm and stuff? <flypaper-ultimat>sughosha: that seems according to guix/scripts/build.scm the same as setting verbosity to 0,which hides all info. <nckx>Did you actually adjust all consumers of your moved syntax to import the right module? <nckx>What a wonderful time for guix.tobias.gr to lie in pieces on a table. I'll try to get it back up. <yarl>nckx: Well, the only consumers are in guix/store.scm <flypaper-ultimat>(its a thing were ^K ansi escape-code does nothing, and thus the log becomes quite long, ill think for now ill just sed kill kill all lines that have '\r\x1b[K') <yarl>I properly use-module this there and exported from store-protocol.scm <flypaper-ultimat>for future people that check the logs; piping into "col -b" (from the `util-linux` package, re <yarl>Ok I got a minimal working (thus non-working) example. <yarl>It seems it's not always non-working... <yarl>Now `guile --no-auto-compile -L . main.scm` fails. <telmo[m]>for view the battery in window manager in computers, whats is the better option? <yarl>Now, if insteal of #:export in (define-module ...) I (export valid-path?) after (define-operation (valid-path?)) it works. <yarl>So, there is a difference between #:export and (export ...)? <acrow>The new ci/qa system for patches is super nice. And so, I see I need a patch for my patch. My question is how to best submit it and keep the automation flowing? Should I invoke git format-patch ... -n2 or do a git rebase, squash and resubmit a single patch? All against the established issue or just abandon the failure and make a fresh submission to guix-patches with the corrected patch? <ennoausberlin>telmo[m]: It depends on your window manager. For i3 there is i3status or i3status-rs <elb>Hi all, happy new year. I'm trying to run esphome in a guix container, and I'm running into trouble due to missing gnu/stubs-32.h. There's a bug from 2018 about this (#32087) with no resolution. I'm hoping someone knows of a workaround. <apteryx>is there a means by which keyboard layouts are exposed on Guix? (environment variable?) <elb>I tried running a 32-bit environment with guix shell --system=i686-linux, but it reports being x86-64, so esphome is installing a 64-bit platformio, which breaks <apteryx>seems like /run/current-system/profile/share/keymaps is the place <sughosha>Is it possible to have an executable script in `(home-files-service-type)`? I tried to make the original file executable, but after installing in the store it is read-only. I created the script for updating all profiles in my $GUIX_EXTRA_PROFILES, and want it to be in ~/.local/bin. <telmo[m]>ennoausberlin: i trying begedora but not help me <bjc>sughosha: yes, but you need to use âcomputed-fileâ <lechner>sneek / later tell rekado / thank you for that erudite summary. your wording belongs on the website as a "customer" testimonial. at this point, i likewise find it hard to envision switching distros again <nckx>elb: Containers don't imply virtualisation, nor does --system= when there's no need for it. You can try setarch(8), specifically the linux32 command, to change the reported personality, on the chance that that's what esphome is sniffing. <nckx>Or just ask esphome to install the right one, however one does that. <elb>correct, I don't want virtualization; I'll try setarch <elb>I think maybe there's not a "right one", I'm not currently sure <nckx>âbut it reports being x86-64â implied otherwise. <elb>I think platformio expects a 64-bit environment and may fail if I can convince it the environment is 32-bit <elb>(but so far it just happily installs 64-bit stuff) <sughosha>bjc: Is it possible to just include already created file, instead of creating within the config file? <elb>I'm ... surprised that apparently nobody does 32-bit cross-compilation on guix, though <elb>or maybe they just jail or virtualize something <bjc>sughosha: you should be able to use mixed-text-file or plain-file inside computed-file, but i haven't tried it <elb>right now I'm working around this by just using a debian box, which worked with zero fuss <nckx>elb: Doesn't Debian use multilib though? <elb>(which is what I wanted in guix) <nckx>IC. I'm just less surprised than you are that nobody bothered adding it (per your linked bug report). <elb>that just means probably very few people are using guix for serious embedded development <elb>which is what surprised me <elb>that or they're simply building their own toolchains, but one of the attractions of guix in this environment is reproducible toolchains, so <nckx>I don't know (of) anyone who does. <nckx>To your previous message. <lechner>alas, there are many other hurdles to using Guix in embedded environmenta, such as early boot abstraction and storage limits <bjc>i use guix for aspects of embedded dev, but not much <elb>oh I don't mean running guix on embedded systems, I mean using guix as a local platform, doing embedded dev <nckx>Don't get me wrong, I'm stoked that you are, elb, I'm just not surprised at all that you're encountering untread ground (at least untread by upstream Guix; if somebody has such a fixed toolchain they aren't sharing it). <elb>oh, I probably won't be, sadly <nckx>Oh. Oh well. And so it remains open. <elb>this is an I-had-thirty-minutes hobby thing, I burned 28 minutes trying to get guix to work, and did what I needed to do in debian in 32 seconds of the remaining two <nckx>Adding support for X != using something that already supports X. <elb>I'm quite sure the reason no one has done is is that toolchain configuration is deeply painful <elb>so it's going to take someone with more commitment than I can muster at this momen <elb>but one of the big problems in embedded dev is stable and predictable toolchains, it seems like guix has a perfect story for that ... once someone tackles the packaging <bjc>guix is appealing as a dev environmest for embedded mostly because the toolchain setup is always so janky, but it's a lot of work <nckx>elb: Agreed (including with your decision to use what exists, as much as would be nice to've had a Guix hero :). <bjc>fwiw, until i can use guix for it, i've just taken to using docker containers. it's close enough to what i want <elb>I use guix relatively little in terms of packages, on a foreign system (usually Debian), but for some relatively critical things (tools I use absolutely every day) <elb>but I would prefer to move more things into it <elb>this seemed like a candidate <lechner>one day inspiration may strike again <elb>sometimes I move things over :-) <elb>I have a system running a bunch of services that is currently nix, that I'd really like to move to guix, that's probably my next big tackle <elb>I'm using nix because it has an asterisk package, but ... I'm considering finding a different solution for asterisk specifically <nckx>yarl: I give up, I can't say. Each hypothesis I come up with ends with âoh but it wouldn't work in <successful case> then, eitherâ. <nckx>It would be a slightly more fun puzzle if someone already knew the answer and could reassure me it's not just an expansion bug in Guile. <civodul>so the web site won't build on bayfront because it lacks substitutes and whatnot <nckx>But WDYM âbecause it lacks substitutesâ (let alone that tittilating âwhatnotâ :) civodul? Why is that a blocker? <ecbrown>in my limited experience, i can't think of anything that requires `sudo' <lechner>as long as your root password is unlocked <ecbrown>iirc `doas' is an openbsd proprietary application <nckx>leg7[m]: Answer whatever you would on your previous distribution. <ecbrown>don't think opendoas comes in the default install, so it is probably not required <podiki[m]1>neat. and 30% smaller according to guix size (though the difference I think is small as likely you'll have things like coreutils anyway) <leg7[m]>ecbrown: OpenBSD doesn't develop proprietary code <nckx>Proprietary != non-free. <nckx>ACTION doesn't want to tell leg7[m] about âthe Open groupâ, âOpenAIâ, ⌠<ecbrown>leg7[m]: it was proprietary (only found on OpenBSD) <lechner>Hi, is there a schedule for pending merges of the staging branch? <ecbrown>that's not what proprietary means in my definition <ecbrown>it means exclusive to something or someone <lechner>this sounds like an argument over words <nckx>leg7[m]: If my âProprietary != non-free.â message was unclear, let's discuss it elsewhere (such as #guix-offtopic), but this isn't going anywhere productive. <nckx>It is an unfortunate truth that the Free software community has chosen some particularly poor, uh, choices of words to rally behind & vilify, and âfreeâ and âproprietaryâ are probably the worst. <leg7[m]>ecbrown: Your interpretation of the meaning of proprietary <nckx>leg7[m]: Please just drop it. <lechner>well, the use of the word proprietary was potentially inflammatory but none of this makes Guix better <ecbrown>my use was not intended as inflammatory. i meant to say that `doas' was ehem "exclusive" to openbsd <lechner>let's not explore the reasons for its unpopularity elsewhere, please <graywolf>Hello, is there something like linux-libre-lts package? <podiki[m]1>for building the guix website locally with haunt, is there some live reload option? (rebuild on file change) <podiki[m]1>as I'm not seeing one but thought as a static site generator it would... <ecbrown>graywolf: yes, i run it with (kernel linux-libre-lts) <ecbrown>you have to add `linux' to your package modules <rekado>efraim: good news: using openjdk9 by default (instead of icedtea-8) I got java-testng to build on aarch64. <sneek>Welcome back rekado, you have 1 message! <sneek>rekado, lechner says: / thank you for that erudite summary. your wording belongs on the website as a "customer" testimonial. at this point, i likewise find it hard to envision switching distros again <rekado>efraim: I wasnât brave enough for openjdk10, 11, or 12. <rekado>had to explicitly use icedtea-8 in some ancient packages, but the number is pretty low. <rekado>I got to build right up to the foot of the groovy mountain. <graywolf>And second question, is there a way to unlock dm-crypt with a keyfile instead of a password? I do not see anything documented, but I would hope it is possible. <rekado>efraim: actually⌠no, the build output was just buried. testng did not succeed. <ecbrown>graywolf: my answer is not authoratative but note: there are *two* places to type password <ecbrown>one before grub, the second where i think you are with dm-crypt <nckx>graywolf: Nope, not yet. <nckx>Code just needs to be written. <graywolf>nckx: I can give that a try since this is a blocker for me (no, I'm not entering 10 separate passwords on each boot). Could you point be to 1. where that code should be located (at least correct git repo) 2. how this is usually tested? I'm currently using qemu to play with quix, so I guess I need to somehow tell guix system init to use my version instead of the official one <nckx>I guess I'd init to a loop-mounted image or partition, then pass that + a test LUKS image/partition to QEMU. <nckx>I guess that's the least work⌠<nckx>(Because Guix's built-in VM functionality ignores file-systems.) <nckx>(Maybe it doesn't ignore mapped-devices, and you can get by with just âguix system vmâ after all; I've never tried.) <graywolf>I'm currently not running guix yet (as stated, this is kinda blocker for me), so I will give this a try <nckx>You don't need to be running Guix to build it (although it's more convenient, because you can âguix shell -D guixâ rather than install all requirements by hand). <graywolf>Yeah I've tried it once, getting all the dependencies was... pain. So I've decided to just switch to GuixSD and I've run into this during my attempts. <graywolf>For time being I'll just use the Guix VM image for this <graywolf>Hm, or maybe I'll get guix into my laptop first, after all this is real blocker only for my server <ecbrown>ACTION winces at guixsd and laptops ;-) <rekado>ACTION uses Guix System on laptops <graywolf>ACTION wonders if he should be afraid... <nckx>ecbrown: What's wrong with laptops? <ecbrown>oh i'm just waiting for the "my wifi doesn't work!" <graywolf>Oh that would be annoying but the driver is upstreamed (not sure if guix enables it), so that should be reasonably easy to figure out <ecbrown>i have a mason jar full of various dongles :-) <nckx>Not all upstreamed Linux drivers work without non-free blobs. <nckx>This is also common for GPUs. <civodul>ecbrown: the installer in 1.4.0 warns you upfront if it detects hardware that's known not to work OOB with free software/firmware <graywolf>Is that displayed during installation or on the install usb boot? I am curious if I can check before even starting the installation. <civodul>graywolf: it's displayed right after the welcome screen of the installation medium <civodul>so you have to actually boot it, but it won't touch your hard disk or whatever <katco>heyo guix friends. i need to use mesa >= 22 in my `operating-system`. what's the easiest and least-impactful way to temporarily diverge from guix proper until `core-staging` is merged? <ecbrown>katco: do you know if the git commit for mesa 22 revbump is sufficiently localized for a cherry pick? <katco>from a code perspective, yes, it's very constrained (as is GNU standard i think?) <apteryx>jjjjjxiiiej.jgujpcjnpeugd.ee.cyycbbxykigtnhj <ham5urg> Is it possible to have multiple systemprofiles? Running daemons, namespacing, etc. at the same time? E.g. having multiple customers sharing one Guix-server. <katco>e5af53c51d71620fa71ebe220aac1d4dd1b3d04a only bumps the mesa package. i'm unsure if it's as easy as copying the new mesa package to a channel and using with-input or something. <apteryx>the inspiring message above courtesy of a yubico key <gnucode>hey guix! My goal for today is to try to set up nextcloud. Anyone doing that with guix system? Would you recommend guix for this task? <apteryx>building guix seems to fail on a 2 GiB armhf machine (it reboots after memory reaches near 100%) <gnucode>This nextcloud installing will only need to have 2-3 users using it at a time. I'll probably spin up a linode instance. <ecbrown>gnucode: nextcloud is so complicated that i run it in a debian container under guix system's virt-manager <apteryx>possibly caused by my swapfile on NFS setup, but still <gnucode>Do you have a blog post or config that I can take a look at? <katco>ecbrown: oh, did you mean to suggest a maintainer would cherry-pick the commit into master? <gnucode>apteryx: has guix always struggled with 32 bit arm? <katco>oh. no, i don't think that will happen. it's in core-updates because it impacts 4k+ packages. i would be delighted to be wrong! <ecbrown>gnucode: i don't have a blog post. the concept is straightforward: outsource nextcloud to a dedicated gnu/linux distro that has nextcloud packaged <ecbrown>that you could run inside of a virtual machine, using guix system's virtualization <ecbrown>otherwise you need a bunch of maria, php, webserver, etc. <gnucode>ecbrown oh. I didn't know debian had nextcloud packaged. That's kind of awesome! <apteryx>gnucode: I think it used to be possible to build it, but armhf seems seldom used (perhaps a chicken and egg problem) <gnucode>apteryx: well I'm glad it still has a few users. There are some cool 32 bit arm machines. and cheap! <ecbrown>gnucode: in my view a guix package of nextcloud would be a valuable contribution <rekado>apteryx: I remember spamming the channel with messages like that⌠:) <apteryx>I'm surprised that the key code comes out as stdin; that's not super convenient <gnucode>ecbrown I suppose the first step toward that goal is to merge the php-build system. It's maybe 75% done already. <katco>speaking of mesa, why do we do that in core-updates and not its own branch? it seems like something we'd want to land into master on a quick cadence <podiki[m]1>katco: you may be aware of another channel that has pulled the core-updates version of mesa, that may be helpful for you; as you said it is just a few isolated package updates <graywolf>I'm getting "Invalid volume group name playground/store0" when trying to boot VM after install, but funny thing is, that is no such volume. Both the install script and the (operating-system ...) reference only playground-store0. Any idea what could be mangling it? <podiki[m]1>katco: agreed! :) perhaps time to bring that up on the mailing list as I've also wanted that <podiki[m]1>I'm not sure, but likely just using the newer mesa for any X related packages (server mostly) would be mostly what you want? <katco>i'll start a thread! and yes, i got a new GPU which needs >= v22. i want to rotate my screen again XD <podiki[m]1>I'm thinking with 1.4.0 out now we can re-evaluate our core-updates/staging to move more towards feature branches <katco>yeah, and drivers are something that, at least imo, should move as quickly as possible. <podiki[m]1>mesa I think is a good example: self contained packages but affects many dependents, should be quite stable in any changes though <katco>(once they're known to be stable of course) <podiki[m]1>otherwise using your own guix checkout for your system, with just the cherry-picked mesa updates maybe is easiest <podiki[m]1>right. and a change to something like chromium (necessary for security) might take as long to build as mesa + a good chunk of its dependents anyway <podiki[m]1>I think more feature branches, using what we get now from QA and cuirass, will be something with broader support. should make everyone's lives easier <podiki[m]1>yes, which hits so much with librsvg for instance <podiki[m]1>I think the question is who is impacted in which ways? people not using substitutes? (we have inferiors though, and probably things like browser changes still lead to lots of building time) <civodul>next up, the FHS post by podiki[m]1 :-) <mvnx>I booted from the QEMU 1.4.0 qcow2 image then used `guix system reconfigure bare-bones.scm` where `bare-bones.scm` is the source example `bare-bones.tmpl` with bootloader and filesystems modified as a copy from `/run/current-system/configuration.scm`. It runs fine but next time I boot the qcow2 and pass GRUB it is just a black screen. Any idea why <podiki[m]1>I thought there was a typo on the date line..... đ <podiki[m]1>civodul: on that note, another quick update on the FHS post thanks to a quick response from Jim on the Tor example <Guest46>If I want to run a gameserver that requires Java icedtea. Would I just change the system Java or differently? <podiki[m]1>sneek: later tell unmatched-paren looking forward to reading your blog post in full detail with a nice cup of tea today :) great work! <ekaitz>unmatched-paren: Really cool blogpost, mate. Thank you for writing it <lfam>But, there's a few thousand shell scrollback lines of this map1 srfi1 stuff <lfam>This seems related to commits e84f17e..8e883dc (Kodi and Wayland stuff) <Guest46>Can I use guix edit with a service type? <tremon>(fold-right cons* '() '(a b c) '(1 2 3 4 5)) => (a 1 b 2 c 3) -- this is not the output that guile produces, it outputs (a 3 b 4 c 5) <tremon>is it a known difference between guile scheme implementation and what srfi.schemers.org says? <Guest46>If I want to run a gameserver on a Guix machine I need to create a service for that? <SeerLite[m]>Hi Guix! How can I add a polkit rule on a Guix System? <rekado>ACTION comments kodi/wayland, the suspected culprit <nckx>tremon: Better ask in #guile, but yes, surprising. <lfam>rekado: `make cuirass-jobs` does succeed when I reverted that range of commits <lfam>Not sure what could be wrong, but it does have an effect <davidl>Is anyone using Sway and think it's better or worse than i3? <davidl>Any particular problems you have come across when using Sway, vs i3 in particular? <davidl>I have stopped using Gnome, cuz it's just too sensitive and hard to restore it to a workable state once broken, and have currently got into using Sway. <Guest46>isn't Sway just i3 but with Wayland support? <davidl>Guest46: I think it's trying to resemble the configuration, but it's not exactly the same. <Guest46>Ah okay. I always thought it is i3 with Wayland. Saw on the website it has additional features. Did not know that <nckx>Sway deliberately emulates i3 where possible, including configuration, but i3 is just a window manager. <Guest46>Is there something like a Raspberry Pie but it can run Guix? <vagrantc>there are lots of somethings that can run guix ... including raspberry pi <Guest46>I thought it can not run on a rpi since the bootloader has proprietary code. Is that not the case? <vagrantc>you have to bring your own boot firmware, sure <katco>unmatched-paren: amazing blog post, ty! <vagrantc>just like most laptops have their own bios or EFI ... guix doesn't need to provide boot firmware <vagrantc>(though in some exceptional cases, it can actually provide boot firmware too) <vagrantc>Guest46: there were some recent patches merged into guix improving support for raspberry pi family stuff ... <vagrantc>i've also used it on a handful of other arm and arm64 platforms <bjc>is guix bootable on the raspberry pi now? <Guest46>katco: Do you have a link so I can read the post as well? <bjc>cool. i had the impression that the rpi was a huge mess of firmware blobs, so i assumed guix was out <panosalevro>is it possible to get an "unbound variable" error despite having the correct 'use-modules' form? <vivien>If there is a circular dependency somewhere, you will get at least one of these <vivien>I only know that case because Iâm not a guile expert <katco>panosalevro: yes, to my frustration. if the module you are trying to use contains errors, the variable you're trying to use may not be bound <katco>panosalevro: a kludge i use when i'm writing a new module is to sprinkle `(format #t "1~%")` after each top-level form to make sure the file is getting compiled all the way through <apteryx>bjc: rpi requires a couple binary blobs to be present on its sdcard (it has its own bootloader), but after its booted it doesn't require any for basic operation (including gpu acceleration) <apteryx>so the firmware is akin to the BIOS on your PC <panosalevro>katco: im not good with guile. can i see an example somewhere? im curious to use it <apteryx>so far I've only tested that our u-boot-rpi-arm64 u-boot package worked with it, but I'm working toward trying the full Guix System on it. <katco>panosalevro: sorry, no. intrinsically, it's not something i'd ever check in. i'm not great with guile either. i just stick that s-exp after top-level forms to see how far through the file guile got <sneek>unmatched-paren was in #whereiseveryone one day and 4 hours ago, saying: aborting update of channel 'guixrus' to ... which is not a descendant of .... <vagrantc>bjc: that impression is not wrong! but you can provide your own mess and guix will likely work fine. there may be some features missing if they are not compatible with linux-libre <rekado>lfam: it was enough for me to comment kodi/wayland <rekado>and now Iâm trying again with kodi/wayland, but without package/inherit <lfam>I'm not sure how it could cause this, but we probably don't want to use package/inherit here <rekado>yes, Iâm trying with a regular old (package (inherit kodi) âŚ) <rekado>one thing that changed in my commits was to use âmodify-inputsâ instead of splicing inputs with labels <apteryx>are people able to sign in gitlab using our icecat package? <podiki[m]1>civodul: I also saw that linked recently, interesting idea though, sort of defining a patchelf/wrapping of a binary <apteryx>it's supposedly been fixed, but it doesn't work for me <rekado>lfam: interestingly, using (package (inherit kodi) âŚ) did not fix it. <podiki[m]1>apteryx: just tried now and it worked, including 2 factor (u2f with my yubikey) <rekado>apteryx: only when setting a different user agent string <lfam>rekado: Since it's blocking Cuirass builds on the master branch, I'd like to revert the commits for now <apteryx>rekado: that used to do it for me, but not anymore <yarl>Hey civodul, I saw your answer about bug 59845. I'll rework it when I have time and send another clean patch and you'll tell me :) Thank you anyway. <podiki[m]1>I don't think I've changed much on my icecat configuration, but I also don't use it much. still it did work <apteryx>podiki[m]1: thanks for checking... perhaps I need to update <rekado>(prepend âŚ) should take any number of arguments, not a single list of packages. <apteryx>I was using /gnu/store/n5pr86b61xj8i1bgk6bnhn72hi7lrp1p-icecat-102.5.0-guix0-preview1 from a couple weeks back <rekado>Iâm trying to confirm the fix right now, and will push as soon as itâs done <apteryx>normally no more user-agent fix is required; it used to be that icecat would spoof the oscu info which would mismatch with the user agent and cause the cloudfare check to fail <podiki[m]1>mine shows /gnu/store/3smajr0awz0k1m6yhc4zz0q52z3smgrs-icecat-102.6.0-guix0-preview1 (haven't updated recently but that is newer) <podiki[m]1>oh, so it is the cloudflare protection (or "protection" i guess) that is triggered? <apteryx>yes; it creates an infinite loop on the login page <rekado>apteryx: FWIW whenever I use icecat I get held up by cloudflare. I also get to solve infuriating numbers of captchas. <apteryx>OK; if 102.6.0 fixes gitlab it should fix many occurrences of the same cloudfare issue <davidl>apteryx: reg. icecat and gitlab - I haven't been able to for as long as I remember. I can try upgrading my icecat and check it again. <apteryx>I'm seeing some odd output while offloading, such as "(repl-version 0 1 1)" and "(values (value "/gnu/store/8yra4l6vifb615g0xx9gzx7dlz8v341s-guix-package-cache/lib/guix/package.cache"))" <rekado>itâs not done yet, but itâs clearly an improvement over the syntax error. <rekado>âŚand it just completed without errors. <apteryx>doesn't work even in troubleshoot mode and/or private browsing mode <apteryx>phodina[m]1: any modifications made to your icecat config that could explain it works for you and not for me? <apteryx>ah, could it be related to the wrong TZ bug <podiki[m]1>also just tried on a private browsing instance of icecat, does go through the cloudflare check really quick and to the login page <podiki[m]1>do they do any ip tracking or anything else? maybe some other residual state? <apteryx>I haven't defined a TZ environment variable to workaround it yet... I was hoping to fix it. <mirai>Does guile or guix offer a way to get the amount of CPU cores available? I'd like to calculate this value to pass as a command-line argument for a shepherd service <civodul>mirai: there's current-processor-count in (ice-9 threads) <apteryx>(continuing gitlab saga) nope, it's not the wrong date... <civodul>oops, guix.gnu.org temporary down, working on it... <apteryx>ah! found the remaining icecat issue; it's the general.appversion.override that was set to 5 <apteryx>setting that to 102.6.0 in about:config makes it work <apteryx>perhaps some cruft that persisted in my ~/.mozilla profile <lebowski>hi guix! i am trying to package a newer version of a python library which already in guix. the thing is - the newer version removed setup.py, so now guix gives me this error "misc-error #f "no setup.py found" () #f ". what i can do to resolve this issue? <lebowski>maybe i am missing something obvious here <jlicht>lebowski: Does it perhaps have a pyproject.toml file instead? We do have a pyproject-build-system if I recall <jlicht>ACTION is not a pythonista though ... <jman>Hello, I tried adding a comment to https://issues.guix.gnu.org/60112 and sent an email a few hours ago to 60112@debbugs.gnu.org but I don't see my comment. I noticed also a delay (a few days) for an email sent to help-guix@ <jman>Are email sent to the Guix mailing list moderated/approved? <jman>oh, the comment on issue #60112 appeared just now :) thanks to whoever fixed <podiki[m]1>jman: how are you checking? note that just emailing the bug number I don't think goes to only debbugs; I see it on the issues frontend but didn't receive it <podiki[m]1>jman: at a quick look, might be a bug? the fhs option does modify PATH so might be interefering with preserving it <podiki[m]1>I didn't do anything, maybe was with some frontends being down just now <jman>no worries podiki[m]1 thanks for the feedback <podiki[m]1>jman: I would open a bug report, this looks like a bug. I'll see if there is an obvious fix, but might as well report <jman>btw, about the issue page: on that page I read that to comment an email to the <issue-#> at debbugs dot gnu.org should be enough <jman>is that the correct procedure to comment on issues? <podiki[m]1>sort of, but I'm not sure who gets that email exactly (I don't subscribe to the bug list but as author of the issue I didn't get your response) <podiki[m]1>you can use e.g. emacs debbugs interface or I think from looking at debbugs on the web to see email addresses for people directly <podiki[m]1>but maybe a debbugs expert can comment, I was always confused about this <rekado>emailing people directly is ⌠not commonly done. <rekado>thatâs one of the reasons why issues.guix.gnu.org doesnât prominently show email addresses <rekado>(they are there, though, just hidden) <rekado>debbugs archives some issues and then you cannot just send email to comment <rekado>itâs frustrating, but the issue would first need to be unarchived <panosalevro>hi, is there a way to see the system's config.scm? even if one overwrites /etc/config.scm? <rekado>(I ran into this problem last time; debbugs didnât inform me that the issue was archived.) <rekado>panosalevro: the effective configuration ends up in /run/current-system/configuration.scm <rekado>the location /etc/config.scm is not special <rekado>you can have a configuration file wherever it is comfortable <rekado>(I have all my configs in a git repo) <panosalevro>rekado: oh ok. what if i overwrite that file too? is it the config still retrievable? <nckx>(And even if you delete the symlink, which is possible, it should reappear when you rebootâit's set up by a service.) 