IRC channel logs
2022-12-08.log
back to list of logs
<oriansj>civodul: it does not appear with syslogd there is a way to configure it cleanly in guix to do something like: -m 0 <lechner>Hi, i did not believe it yesterday when someone else wrote here, but all the GTK icons are gone <oriansj>here is a rather basic question but guix has an info file for its reference manual and that info file isn't included by default for what reason? <oriansj>wait, what happened to the old info format of the manual? <lechner>oriansj / i think there may now be six of them <oriansj>lechner: perhaps more directly, how can one using guix have access to good documentation about guix from the terminal if the info file wasn't included by default and the man page provided is quite sparse <oriansj>even having a guix package providing the manual would be good enough <oriansj>(I then could just easily add it to my default packages) <gnucode>unmatched-paren: are you hoping to make that a guix blog post? <gnucode>I'm liking what I am reading so far... <gnucode>unmatched-paren: actually as dense as this is, it might belong in the manual. <oriansj>mirai: info is a commandline tool for reading documentation in the info format; many gnu packages have one (you can see a list installed on your machine by just typing info) and hence my question why guix doesn't include its own documentation by default (or provide a optional package to provide it) <mirai>oriansj: really? info guix shows the docs for me and I don't recall installing anything extra for it <Noisytoot>How long does it take for a patch sent to guix-patches@gnu.org to appear after being sent from an email address that has never sent anything to guix-patches@gnu.org before? <Tril[m]>what would be the guix system way to run qemu guest agent (qemu-ga) on startup? I have the package in the store and figured out what parameters are needed (-d -t /var/run). Not seeing a "Service" in the docs to add to config.scm. <mirai>Noisytoot: give it half a day <Tril[m]>is there a basic way to add commands equivalent to rc.local? <apteryx>oriansj: /etc/profile has some hard-coded values for INFOPATH <apteryx>otherwise you can install info-reader to benefit from its INFOPATH search path <PotentialUser-39>Hi everyone! I have problems with pulling my guix channel during the installation (my channel is on github). No problems with official channel and nonguix <apteryx>you'll have to show what is the actual error if you want someone to be able to help <lechner>oriansj / i also have the Guix manual available inside Emacs. When I search by manual with C-h R, it actually 130 (!) entries for many different languages, including Chinese, and also the Cookbook. I do not recall installing anything for it, but this is my daily workhorse with a comprehensive installation <oriansj>apteryx: you are correct, it appears my INFOPATH was missing ${HOME}/.config/guix/current/share/info <lechner>oriansj / no sweat, it won't be the last! <oriansj>it is included by default but I also had the infopath not set to see where guix puts it <lechner>i am glad you found it. thanks for checking on it! <Noisytoot>My spamfilter added a "X-Spam: yes" header to it <oriansj>lechner: I also use a custom bashrc; which doesn't inherit the guix profile. So I end up manually setting variables and sometimes a miss one or two <Noisytoot>Although I'm not sure if that's in the email that was sent to the mailing list or just in the copy git send-email sent to me. <attila_lendvai>installer: qemu output is garbled. i'd like to invoke a reset, but there's no ncurses. a simple `guix install ncurses` doesn't work. any other options? <attila_lendvai>ACTION suspects that it's garbled due to something guix prints in its welcome message <apteryx>how are system generations handled by u-boot bootloaders? <apteryx>apparently u-boot-bootloader inherits its configuration-file procedure from extlinux-bootloader <Aurora_v_kosmose>Does it need to handle them specially? I seem to recall u-boot providing a (partial) UEFI implementation. <Aurora_v_kosmose>That being said, I haven't used Guix on any platform that uses u-boot so I have no idea what is currently done with Guix & U-boot. <apteryx>Aurora_v_kosmose: on the board I'm trying to support, it uses a U-Boot from 2015 which lacks UEFI support <apteryx>I just need to put a .dtb and the kernel zImage under /boot <apteryx>where /boot is on the main partition on the sd card <apteryx>the bootloader itself lives in some SPI chip elsewhere, so Guix wouldn't be able to write it (it needs to be flashed manually at the u-boot prompt) <apteryx>my end use case is to use 'guix system image my-config.scm' and be able to flash this to the sd card <apteryx>I guess --image-type=raw-with-offset would do for that use case <apteryx>I guess I could even abuse the extra-special-file service to put my files under /boot <lechner>cwebber / Hi, and thanks for the pointer towards the Preserves interchange format and Syrup (on Mastodon)! Why is the Syrup binary encoding needed in addition to Preserves? Thanks! <Luchadoritos>Hey Guix! I was using the (python-)plotly package and one way it displays plots is to use a package called kaleido. Kaleido uses a binary wheel for pip so it's not on Guix. Here's the interesting part; <Luchadoritos>Python can import both plotly and kaleido, but plotly cannot call on kaleido. In one of the calls from plotly, it opens a subprocess.popen which lives in the store so the subprocess cannot see the user installed packages <Luchadoritos>So I get a FileNotFound error in this specific circumstance. I'm avoiding this issue by not using Plotly and using matplotlib. But I'm wondering if there is a future goal to support all the features of this package. <lilyp>Luchadoritos: I think packaging kaleido would fix this; you can't count on the importer to do so, so you need to do it the ol' manual style <lilyp>well, you would probably also need to fix plotly to call into your newly packaged kaleido, but that shouldn't be more difficult than actually packaging kaleido <Luchadoritos>I see! 1. Package kaleido 2. Edit plotly to have the new kaleido as an input. Makes sense! I wonder if I can make progress this weekend? Sometimes packaging really whoops me. Never made a dent in Bazel. <lilyp>bazel puzzles the best of us <lilyp>Thankfully, kaleido seems to only need cmake and the python build system <sepi>Stupid question: How do I easily get a base32 or base64 hash from a file? <lilyp>but fuck, do they have much to strip from the source <lilyp>if it's a directory add -r, if you need to exclude version control stuff -x <sepi>lilyp: ahh, that's what I wanted. Thanks <sepi>Whoo, I just built my first package :) <remsd1>Hi; is it possible to create a guix profile without specifying a manifest or a channel file ? <remsd1>that would simplify creation, activation, deactivation or switching between profiles <civodul>remsd1: hi! sure, when you run "guix install python" (say), you're "creating a profile", or creating a new "generation" of the profile at ~/.guix-profile if it already existed <civodul>if you want a virtualenv-like experience, probably "guix shell" is what you should try <civodul>"guix shell python python-numpy" gives you a new shell set up to use python and numpy, for example <remsd1>civodul, in the default profile ? <civodul>no, "guix shell" creates a profile on the fly <sepi>How can I inspect the nginx config that the service config generated? I cant start the nginx shepherd service and I guess the config is broken <sepi>Or alternatively, how can I get the store path of the packages installed for a service? <civodul>sepi: try "less $(sudo herd configuration nginx)" <civodul>(requires a relatively recent Guix System) <sepi>civodul: herd: service 'nginx' does not have an action 'configuration' <civodul>sepi: so, until you upgrade :-), you can resort to "ps aux|grep nginx", grab the PID, and run "sudo cat /proc/PID/cmdline | xargs -0" <ennoausberlin>Hello. I have a question regarding python build systems. There is the following sentence in the manual. "We currently package Python with setuptools and pip installed per default. This is about to change, and users are encouraged to use python-toolchain if they want a build environment for Python." What is the meaning of python-toolchain? <sepi>civodul: ok, so is upgrading just guix pull and guix system reconfigure ? <rekado>mrvdb: a way around the lack of reproducibility? <rekado>there’s no known way, because that would be effectively be a fix for this bug <mrvdb>i guess a rebuild is what I am asking, so sbcl can be upgraded (it complains about a mem file not being produced by the same clisp runtime) <rekado>mrvdb: I’m not sure I understand the problem. How is a reproducibility problem in clisp blocking your sbcl upgrade? <sepi>I get an exception when executing start of my nginx service using herd. Where can I see the details of the problem? I can't find anything in any of the logs I know of <mrvdb>rekado: building sbcl fails with the 'lispinit.mem' file mentioned in that bug report not being from the same clisp runtime <civodul>sepi: it depends on the error, but it could be in /var/log/messages <Metanoia>sorry client crashed again, please repeat any replies to my question if there were any <sepi>civodul: no mention of the exception there. I'll try running the binary manually maybe <sepi>Is it normal that guix system reconfigure downloads things even when just doing a trivial change in the config like removing a config parameter? <civodul>sepi: if you also ran 'guix pull', yes <civodul>nckx, efraim, apteryx: i guess we can remove things like 1.2.0rc* from alpha.gnu.org; objections? <civodul>ACTION trying to be nice to the sysadmins <cwebber>lechner: ah, it's just that syrup is dead simple! <Metanoia>is this an error in the pidgin package for guix? <civodul>Metanoia: hi! no idea; is this on Guix System? <civodul>"guix shell -CN -E ^DISPLAY pidgin -- pidgin" works for me with a recent Guix <civodul>that'll allow to determine whether the problem is related to state on your machine <civodul>you need to run this under X11, where the 'DISPLAY' environment variable should be set <Metanoia>do I need to install a different desktop environment for that? <cbaines>what desktop environment are you using Metanoia? <Metanoia>I think it's gnome 3 on wayland, but not 100% sure <cbaines>Metanoia, that's what I'm using, and pidgin seems to start at least <Metanoia>I am actually using pidgin right now but it could crash any moment. <Metanoia>I am not sure if the crash is triggered by a screensaver or just some random graphic event. <mirai>didn't notice your comment until I already hit git send-email <mirai>the first patch uses 'match' to match against pairs (which might not be exactly obvious as the (guile scheme) documentation doesn't explicitly show how) <mirai>the revised v2 uses existing (gnu services configuration) machinery <mirai>more concise but the first one could also serve as an example for matching against pairs in lists <efraim>civodul: I'm torn between we don't need them, and seeing all the old copies of libraries dating back to the early 90s and saying to leave it until they ask us for space back <efraim>it looks like openblas isn't built 64-bit on aarch64 <zamfofex>I know my work isn’t particularly impressive (as much as I wish I could be able to help further), but I’m kinda frustrated that it seems no‐one was able to directly help with <https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00059.html> 🙁 Even some kind of directioning would be helpful (i.e. where to look, whether I’m off). It’s difficult to try things out on my own because GCC takes a long time to build. <civodul>efraim: i'm only talking about release candidates, not actual releases <efraim>civodul: yeah I know. it's probably fine to remove them <rekado>zamfofex: re shepherd you can modify %base-packages/hurd <civodul>(for example, i wouldn't remove guix-0.1.tar.gz :-)) <efraim>civodul: oh, do we have the bootstrap binaries mirrored on one of the GNU servers? can you make sure we have a copy of the ones I'm hosting? <efraim>ACTION is happy to host them, but doesn't want to worry about losing them <civodul>efraim: that's a different copy, but in general bootstrap binaries should all be at ftp.gnu.org/gnu/guix/bootstrap <civodul>we're missing the powerpc ones i guess? <efraim>civodul: those are a little sparse. I'm only seeing i686-linux and i586-gnu <efraim>so we're missing armhf, aarch64, powerpc, ppc64le and riscv64 <civodul>alpha.gnu.org/gnu/guix/bootstrap has more <civodul>it has powerpc64le-linux, not sure how it ended up there <efraim>ok, so it's missing powerpc-linux and riscv64-linux <civodul>efraim: i can upload them to ftp.gnu.org <rekado>zamfofex: have you gone through commencement.scm to retrace the hurd bootstrap? <apteryx>is it possible to run 'guix system init' without having to worry about file systems backing devices? I just want to init to an NFS served directory <zamfofex>rekado: I have not, except briefly. I looked into ‘gcc.scm’, and investigated the cross‐compilation setup. It seems simple in principle, but the details are complicated. The closest I got to my conclusion was that the GMP build logs mention the native glibc was listed in ‘C_INCLUDE_PATH’ (or perhaps some other variable) alongside the cross‐built glibc, which seems wrong. <zamfofex>Also that the missing ‘pthread_*’ symbols are available in the native glibc library files, but not on the cross‐built ones. <civodul>apteryx: NFS has its own peculiarities, i'm not sure it's safe to "guix system init" over it <apteryx>civodul: ah, I meant to the rootfs directory I server over NFS. The actual local storage is Btrfs. <apteryx>I'm now runnig 'guix system init' to the target board (TS-7970) mounted SD card <apteryx>I had to use --skip-checks otherwise it'd suggest adding some initrd modules that are not part of linux-libre-generic-arm <apteryx>that seems like a bug, perhaps? rekado, I think you'd encountered that before, with "ahci" in %base-initrd-modules, perhaps? <apteryx>I have a basic operating-system definition with (kernel linux-libre-arm-generic) and (initrd-modules '()). When I try to 'guix system init' the thing to its mounted sd card (/mnt/rootfs), from my host system, using "guix system init --target=arm-linux-gnueabihf os.scm /mnt/rootfs", it fails like: error: you may need these modules in the initrd for /dev/sdh1: uas usb_storage <apteryx>if I add those, e.g. (initrd-modules '("uas" "usb_storage")), the linux-modules derivation fails with: kernel module not found "usb_storage" "/gnu/store/8x3kdgkvha0a1hhhqk90kp9mpl1wdwx3-linux-libre-arm-generic-6.0.10/lib/modules" <apteryx>so I had to use 'guix system init --skip-checks' to get passed that <civodul>"guix system init --target", is that even a thing? :-) <civodul>i guess it should imply --skip-checks <apteryx>I see; the checks were made assuming my host was the target system? <apteryx>ACTION doesn't know how the check mechanism works or what it checks for <civodul>that works for "normal" init, reconfigure, and deploy <civodul>those checks are to avoid common mistakes that would lead to an unbootable system <civodul>like missing modules in the initrd, referring to a non-existend file system UUID/label, etc. <apteryx>OK! I'll look into disabling them when --target is used; how about --system? would they work in that case? <civodul>so --target was added in "guix system" in 2020, bdbd8bf9054c88aaf694a08e49270c95e6adad27 <civodul>it was meant as an option for "guix system image" <civodul>wasn't part of the initial contract :-) <civodul>anyway, would those checks work with --system? in some cases yes (like i686/x86_64), in others no <civodul>it's only the initrd module checks that should be skipped actually <apteryx>does --target affect %current-system ? <apteryx>probably more like %current-target-system? <lilyp>%current-system should only be affected by --system <apteryx>hmm. --target=arm-linux-gnueabihf causes (%current-target-system) to be "arm-linux-gnueabihf". But that's a triplet, not a nix system? <apteryx>here's my pk for debugging cross-build problems with our make-u-boot-package procedure: ;;; (%current-target-system "arm-linux-gnueabihf" %current-system "x86_64-linux" triplet "arm-linux-gnueabihf" nix-system "armhf-linux" same-arch #f) <mbakke>apteryx: did you get anywhere wrt. user-specified kernel config? <apteryx>it looks like I'd have had to make a correct config with 'make menuconfig' for it to be happy (e.g., fix all the dependency problems it found). there was too many, so I've punt on that for now, but I'll try it again. <apteryx>you could also probably get away with make-linux-libre* directly <mbakke>apteryx: wdym? `make menuconfig` will always generate a "sane" config without dependency issues. <apteryx>I meant the base config I was trying to start with was not generated with 'make menuconfig' <apteryx>so it had these dependency problems already in, which the new 'verify-config' used in 'customize-linux' is design to catch <apteryx>is %current-target-system supposed to be a GNU triplet or a nix system? Its name implies the later. <apteryx>ah, there's a comment below which says it's either #f or a GNU triplet... hm. <civodul>efraim: i uploaded a number of things but that eventually failed with... "4 slashes is too many, in guix/bootstrap/powerpc-linux/20200923/bin" <civodul>so i guess i'll upload them without "/bin"? <apteryx>could be handy to keep a 'gnu-build-system-next' around on master <mbakke>uhm, that did not work because of the cond clause, but you get the gist <apteryx>would that be any different compared to having a switch to skip "verify-config"? <apteryx>I find having 3 config-related arguments confusing <apteryx>my understanding is that without the checks, the #:defconfig argument should be usable just the same, right? <apteryx>and then you recover the ability to further specialize it via #:configs <apteryx>ah, not the same because "(invoke "make" "guix_defconfig")" will generate a .config from it, which is where issues in your kconfig could become apparent, I guess <mbakke>but I agree three config-related keys are confusing <apteryx>mbakke: I wonder if sanitizing your .config manually with a 'make olddefconfig' in a 'guix shell -D linux-libre ncurses' could make it usuable for teh #:defconfig argument of customize-linux <apteryx>if it does, we could refine the error message with a hint <mbakke>apteryx: the config is already sane since I generated it with `make oldconfig` against a recent kernel <mbakke>oldconfig (and menuconfig) warns if there are inconsistencies <apteryx>ok. that'd means verify-config is buggy? <mbakke>probably, my kconfig is pretty minimal, tailored to my hardware, and verify-config complains that I'm missing some options it expects to be present <mbakke>also that I'm using a different compiler.. <remsd1>manifest just contains python and python-numpy <remsd1>BTW, is there some file index of packages, like apt-file or yum whatprovides ? It seems my guix shell does not find `getpw` <mbakke>remsd1: are you on guix system or a foreign distro? does your user exist in the /etc/passwd file? <remsd1>It is almalinux. User does not exist in /etc/passwd. User is retrieved through sssd -> LDAP <mbakke>remsd1: try installing 'nscd' and starting the nscd service <remsd1>mbakke, I cannot do that. I am on a HTC cluster / multi-user system. <mbakke>remsd1: I don't think Guix can work in an LDAP environment without nscd :/ <remsd1>mbakke, it seems that this issue is only due to the `-C` option <civodul>now it's true that "shell -C" could do its work even when getpw fails <rekado>remsd1: I managed to build a Guix System container that speaks to the host system’s sssd. <rekado>so nscd on the host isn’t strictly necessary <rekado>(we use sssd from Guix to talk to the host system’s /var/lib/sss/pipes) <rekado>Metanoia: is this on a foreign distro? <lechner>cwebber / i use a lot of JSON but always keep an eye on protocol buffers. the "preserves" seem like a cool new format, but for large data sets the binary formats like syrup often do not make sense. a run through xz usually brings the size down to 5%. is syrup primarily intended for microservices? <remsd1>civodul, unfortunately we droped nscd for sssd a few years ago <Metanoia>rekado: I state in my question that it is guix <civodul>remsd1: ok; i've prepared a fix to let "guix shell -C" work even when getpw is dysfunctional (due to lack of nscd in this case) <civodul>(TLS on that server is all broken, "accept the risks" :-)) <remsd1>indeed, TLS is broken. Mismatch TLS version (too old) <mbakke>was there a new build node added recently? cuirass suspects that its signing key is unauthorized <remsd1>Ok, an old firefox has been able to access it :) <mbakke>ACTION snoops around in cuirass logs hoping to find out why evaluations are hanging <mbakke>ACTION did not find anything in particular, restarts cuirass as a last resort <civodul>mbakke: .14 is the new aarch64 node; where did you see hints that the signing key is unauthorized? <mbakke>civodul: /var/log/cuirass-remote-server.log <mbakke>probably berlin just needs to be reconfigured <mbakke>or the wrong key was added to machines.rec <civodul>machines.rec is purely informational <civodul>there's %build-node-keys in berlin.scm that picks keys/guix/berlin/*.pub <mbakke>I don't see 10.0.0.14 in machines-for-berlin.scm <civodul>there's now lieserl.lepiller.eu.pub (the new node) <mbakke>so not sure how cuirass offloads to there <mbakke>that hostname is not present either <civodul>cuirass doesn't use offloading, it uses its own "worker" mechanism <civodul>so the machine doesn't have to be in machines-for-berlin.scm (but it's a good idea to have it there) <civodul>cbaines: (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (perl-getopt-argvfile)) (value #f)) <cbaines>indeed, but I can't see that variable being undefined at that revision <gnucode>hmmm, i just found a project to make a C interperter. kind of cool. <civodul>mbakke: so i guess we need to check whether lieserl*.pub made it into /etc/guix/acl <mbakke>then I guess we need to check if it actually matches the signing key on the node <mbakke>in totally unrelated news, it would be good if DBus looked up interface files "/share/dbus-1/services/*.service" from user and 'guix home' profiles <mbakke>instead of having to extend dbus-root-service-type <unmatched-paren>mbakke: unfortunately i don't think there's anything like a DBUSPATH <unmatched-paren>if there was it'd be much easier to add support for dbus .services in home-dbus-service-type :( <mbakke>IIRC dbus service activation used to work from user profiles back in the day, did something change in recent years? <podiki[m]>(funny to read a bug report where i've had extensive bug report discussions with both participants 8 years later) <apteryx>weird, 'guix system init' on the mounted sd card caused my own system '/var/guix/gcroots/profiles/per-user/maxim' profile links to be registered at /mnt/rootfs/var/guix/gcroots/profiles/per-user/maxim <rekado>Metanoia: ‘guix’ is not necessarily ‘Guix System’. The question is whether you’re using Guix on top of a foreign distribution. <mbakke>ACTION emerged from a rabbit hole trying to get desktop notifications working in ungoogled-chromium; ultimately I had to extend dbus-root-service-type with a package that registers org.freedesktop.Notifications <apteryx>how to tell u-boot to boot from /boot/extlinux/extlinux.conf ? <rekado>apteryx: you can check with ‘env print’ to see what boot commands have been defined <rekado>some there are about finding efi, and others are about finding extlinux on available devices <sepi>How would you go about to deploy a php application like wordpress as a service. I've managed to get nginx and php-fpm working to some extent. Now I need to reference a directory with the wordpress sources (which I've packaged locally) in the nginx-server-configuration. The problem is that most php applications are a mix of code and mutable directories and maybe even mutable files. I guess this means that just <sepi>referencing the store is not the way to go. Should I create a new deployment directory where I symlink in the code? <rekado>sepi: maybe the definition of the zabbix services is of interest <rekado>zabbix is also a PHP application. <unmatched-paren>sepi: you probably want to create some kind of /var/wordpress directory, yeah. and try to patch the wordpress source to do all its mutable things in there <sepi>rekado: ahh, makes sense. I'll have a look there <unmatched-paren>oh, never mind, rekado's advice is definitely going to be better than mine <unmatched-paren>agh, i just realised that could be interpreted as incredibly passive-agressive. <sepi>unmatched-paren: let's see how good zabbix is implemented as service <unmatched-paren>ACTION fixed their issue with connecting to guix repl with geiser, is happy <unmatched-paren>ACTION also tried guix worktree with their guix checkout. it works really well! :) <jlicht>unmatched-paren: pray tell, what fixed your guix repl <--> geiser woes? <unmatched-paren>jlicht: turns out i'd configured emacs to automatically add ~/code/guix to the geiser load path <unmatched-paren>which caused all manner of bizarre errors when i tried to use some of its modules <apteryx>rekado: thanks, but I don't see anything related to extlinux; I'm trying to see if I can have the stock u-boot honor the guix-produced configuration (/boot/extlinux/extlinux.conf) <unmatched-paren>i presume there was some conflict because guix repl had a different load path to geiser...? or something... <unmatched-paren>anyway, ``guix repl --listen=tcp:37146 &'' and ``M-x geiser-connect RET RET RET'' works now <apteryx>rekado: seems it's controlled via the 'bootmeths' environment variable, which accepts a list of values, such as syslinux <apteryx>on my u-boot bootmeths is not define <mbakke>ACTION attempts to fix the zabbix setup on berlin <unmatched-paren>it matches a record of type <zabbix-front-end-configuration>, and binds its server and nginx fields to those same names <unmatched-paren>however, match's ($ ...) clause is quite annoying because the fields need to be in order <sepi>ok, I'll see to use that instead once I get this far <unmatched-paren>ideally all record-type matches should be replaced with match-record <apteryx>rekado: ah, 'syslinux' is supposed to be a thing <unmatched-paren>whenever you add a field to a record, unless it's at the bottom, you risk breaking ``match''es <sepi>unmatched-paren: yeah, sounds brittle <rekado>apteryx: FWIW on my rk3399 it eventually attempts to boot from USB where I have a Guix System image with /boot/extlinux/extlinux.conf <unmatched-paren>civodul: i'm really sorry for pestering you again, but i'm still not entirely sure what to write after "If `recursive?` is `#t`, ..." <civodul>unmatched-paren: setting recursive? to #t changes the way the hash is computed: it's now computed over a nar, rather than over file contents <civodul>since nars store file metadata, and in particular the executable bit <civodul>that allows fixed-output derivations to produce executable files <civodul>a feature that's used in only one place in all of Guix <mbakke>how to increase shepherd grace period? <unmatched-paren>civodul: kind of? why does it need to be different when computed over a nar, though? <unmatched-paren>why does it need to be computed over the nar when it's got the executable bit? <unmatched-paren>why couldn't we just unpack the nar, retaining the executable bit, and hash that? <unmatched-paren>tbh nobody's ever going to need to know; i'll just write "Explaining the purpose of `recursive?` is out of scope for this post." <rekado>I think call-with-file-lock should remove the lock file at the end <unmatched-paren>you'd define foo.scm as a module by adding ``(define-module (foo) ...)'' at the top <rekado>sepi: the manual page there is about channels and how to make it so that the package modules are not in the default location <unmatched-paren>i'd recommend just checking out the guix repo, starting a branch, and working there though <rekado>it should help to read the context of that node <rekado>but that’s all about how to publish a channel <sepi>unmatched-paren: ok, I'll try that. So I'd set GUIX_PACKAGE_PATH to use my local repo? <unmatched-paren>clone it to a directory, and use the Running Guix Before it is Installed section of the manual to build and run it from there <unmatched-paren>then you can just make changes, rebuild, and run ./pre-inst-env guix ... to do anything you want with the new version of the sources <sepi>ok, I'll try that. Tomorrow then :) Thanks for the patience <sepi>The docs are extensive but not always super easy to undestand and navigate. Some tutorial like parts would be nice. <unmatched-paren>sepi: indeed. tutorial-like parts are actually what i'm trying to write right now :) <unmatched-paren>and you've given me the idea to add a part for contributing to guix... <sepi>unmatched-paren: good initiative. Maybe I can contribute at some point <unmatched-paren>sepi: it's a series of blog posts for guix.gnu.org/blog called "Dissecting Guix" <apteryx>rekado: I've rebuilt the u-boot for my board with sysboot support, so that's that <podiki[m]>civodul: sorry just saw your email about fosdem now, not sure how that slipped past. will send a response today! <nckx>civodul: SGTM; I'd say x.y-rcs should be up for GC soon after x.y comes out. <podiki[m]>unmatched-paren: nice work, looking forward to reading that in detail soon! <rekado>apteryx: what does sysboot do and how do I do this? I’d like to give it a try on my rk3399 board. <rekado>ACTION tries to upgrade u-boot to 2022.10 <efraim>rekado: honestly I'd try using grub-efi and manually flashing u-boot on the card. Mostly worked for me with the pinebookpro, and that's an rk3399 also <efraim>u-boot is already set up to provide a UEFI base for grub and stuff <podiki[m]>I'm not sure if this is a guix thing or not, but anyone use fuse (fusermount to be specific, from fuse@2) and get "old style mounting not supported" error? <old>Yes. sshfs has been broken for me for quite a while <old>I don't have the same error though <podiki[m]>I'm just trying fusermount on any old file and it always gives that message <gnucode>unmatched-paren congrats on getting aerc merged! <gnucode>that's an insane amount of dependencies! <apteryx>rekado: on recent u-boot you should be able to simply add CONFIG_DISTRO_DEFAULTS=y to the config it if isn't already <apteryx>I haven't read about rk3399, but perhaps it is able to boot from a UEFI partition? <apteryx>in my case this support is not there yet (2015 u-boot), so the best there was at the time was some "standard" boot commands <nckx>old: And what does ‘yes’ refer to then? <apteryx>rekado: after some experiments I was able to have the standards boot commands included in that old u-boot fork <apteryx>so now my bootcmd defaults to something like bootcmd=run distro_bootcmd <apteryx>which ends up running boot_extlinux=sysboot ${devtype} ${devnum}:${bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf on a few devices <lechner>podiki[m] / hi, i use FUSE every day. will you share your command sequence? <apteryx>which should be compatible with a u-boot-bootloader derived bootloader <unmatched-paren>gnucode: thanks :) i then had to update zoxide to 0.8.3, which involved *50* patches... <podiki[m]>lechner: I was just trying fusermount on a file for instance (my eventual usecase is seeing if I can get appimages to mount themselves as they use fusermount, but there's some complications doing that in a container) <podiki[m]>lechner: what is your usual procedure or test case I should try? <gnucode>unmatched-paren you're developmental kong fu is super impressive! <lechner>podiki[m] / well, i use Gocryptfs for my home folder (and being Golang, it uses only syscalls and the kernel module). either way, i think the 'fusermount' command is only for unmounting (with -u). you can no longer use it to mount, if that's what you tried, hence the error. <nckx>Are you sure fusermount is supposed to work like that? <nckx>It looks like an internal tool, not for use by humans. <nckx>I'm not talking about unmounting, only mounting. <podiki[m]>and something that is using fuse to mount, how does it do this generally? <nckx>(I've noticed it happens to work when unmounting, but I wouldn't rely on it without upstream's blessing.) <lechner>podiki[m] / you have to supply the system calls <nckx>podiki[m]: It could set FUSE_COMMFD_ENV and call fusermount itself. <nckx>I'm not 100% sure about ‘should’, hence cowardly ‘could’ :) <podiki[m]>hmm...it really does seem appimage tries to use fusermount directly and get this error, but maybe it tries something else and this is an old fallback (that no longer works) <nckx>If fuse-using users are broken (and it seems like they might be, or people are just very good at breaking sshfs) let's debug that, but the more I look at fusermount the less I believe that ‘running it on random files and it fails’ is a bug. <nckx>podiki[m]: That sounds plausible. <podiki[m]>yeah, I was just looking for a simple test case since I'm doing something more complicated (appimages in an FHS container and getting out of the sandbox to mount) <podiki[m]>to be specific: I provide a wrapper that uses a flatpak tool (flatpak-spawn I have a patch pending for flatpak-xdg-utils that includes this) which can call to the host <nckx>podiki[m]: Is this a recent AppImage? <podiki[m]>lechner: do you have any system config related to fuse? <podiki[m]>nckx: from earlier this year, so yes, but I'll try newer <podiki[m]>I can run the appimage (with our shiny FHS container) but was seeing if I can get it to self-mount (I can mount it directly in another way, but appimages try to selfmount with fuse and then run) <lechner>podiki[m] / not usually, unless you require 'allow_other' or 'allow_root' for your mount. by default, root cannot peek into FUSE mounted folders <lechner>podiki[m] / are you sure libfuse2 is available in your case? i think it will solve your issue <nckx>podiki[m]: By ‘I can run…’ do you mean --extract and then run, or does ./appy.appimage really just work in the FHS container? <podiki[m]>so if I run the appimage in the container it will complain it can't read /etc/mstab and then operation not permitted (both prefixed with fusermount: in the message) <podiki[m]>I provide a wrapper to call (I believe) fusermount on the host side, then it fails with the old style mount not supported (leading me to believe I did get out the sandbox) <podiki[m]>lechner: yes, fuse@2 is provided, without it appimage will fail in trying to load libfuse <podiki[m]>nckx: ./something.appimage is what I'm trying to do, extract-and-run works yes :) <podiki[m]>this is an exercise of "it already works but I want it to work another way" <podiki[m]>I know appimage has some different formats, but this should be the latest type <nckx>ACTION is testing with an ancient 19-hour old GVim one. <podiki[m]>and appimage run with --appimage-extract-and-run should work in FHS, if you have some prereqs <nckx>podiki[m]: Forgive my ignorance, but… so you're trying to just invoke ./app.image, outside of any container, and have it just work, yes? So… are you patchelfing it first? <podiki[m]>apparently not all appimages are so self-contained, was helping someone with one the other day that needed a bunch of random libraries anyway <nckx>And fusermount doesn't need to be setuid for you? <nckx>That's where I got stuck. <podiki[m]>I thought the whole "appimage needs fuse" was a no go in containers, but thought there was a workaround aka ruin the security of the sandbox <podiki[m]>in a container with flatpak-xdg-utils should allow "flatpak-spawn --host fusermount" to work <podiki[m]>but I can't be sure that part (calling to host) is working <podiki[m]>oh it does, cool/scary: flatpak-spawn --host ls ~/ will show the hosts user directory, not the containers <nckx>podiki[m]: <fusermount is in my setuid> How does that work? <podiki[m]>nckx: I meant on the regular host I see fusermount as setuid <lechner>podiki[m] / you can also experiment with FUSE by mounting sshfs, if you like <nckx>I sure hope the container doesn't. <podiki[m]>the flatpak-spawn uses a portal (dbus service) to call to the host, so you do need access to the dbus socket (process?) of the host <podiki[m]>lechner: i meant flatpak-spawn does work for my little "ls ~/" test <podiki[m]>i'm not positive this will work in the end, but I think it is possible to run an appimage within the flatpak runtime, which must call to the host for fuse <lechner>sorry, i have no experience with appimages or flatpak. i tried vscodium once, but it was a short romance <nckx>uNiVeRsAl ApPs FoR LuNiX <podiki[m]>i have barely any experience with either too :) <podiki[m]>but did learn from both that neither are as good as they claim <podiki[m]>a lot of work goes on behind the scenes and assumptions <podiki[m]>ACTION has a few quick meetings and then back to playing <lechner>Being isolated, Guix may be well-positioned to support all those, as well as every other package manager in the world <nckx>I still can't get past ‘fusermount: mount failed: Operation not permitted’ 🤷 <lechner>for sshfs, you may have to be in the 'fuse' group <nckx>lechner: I have no idea. It supports multiple file systems. No idea how to check which is used without diving into a hex editor. <nckx>If forced to guess, I'd guess squashfs. It's hip. <jonscoresby>Is it possible for a build system to have implicit outputs? <lechner>nckx / What is "it" in "it supports multiple file systems" please <nckx>jonscoresby: Almost all of them do. <nckx>I wasn't really expecting it to, but --expose=/run/setuid-programs (and setting PATH) still doesn't change the error. <nckx>jonscoresby: I'm referring to the fact that I totally read over ‘implicit outputs’ as ‘implicit inputs’ :) Er, build systems can define default phases that create any output they want, sure. <nckx>An output must have something in it (you cannot have empty outputs), so any ‘implicit output’ would have to be connected with an installation of files, somehow. <jonscoresby>nckx: I've been experimenting with a build system that has an implicit output, but I cannot make it work. I don't understand guix under the hood that well, but it seem that whatever outputs I provide just get overwritten with '("out") unless I specify the outputs in the package definition. Hence my question <lechner>nckx / re "operation not permitted" it could be from modprobe. do you have the 'fuse' kernel module loaded? <nckx>jonscoresby: Hmm. Right. How are you defining this extra output? <nckx>ACTION got a bit distracted by wanting to prove that sshfs works just fine in a minimal VM, and it does. I suggest people reporting a broken sshfs first update all relevant profiles (system & user, probably), then try to create a minimal reproducer. Back to AppImage… <jonscoresby>nckx: I've tried adding it everywhere that seems obvious to me: the bag definition and the builder <podiki[m]>i add to PATH wherever I put the wrapper and that's my attempt to use flatpak-spawn for fusermount, but doesn't work (perhaps fusermount isn't called via PATH, and perhaps that's not what the appimage really wants to use) <nckx>I want to make it worth without that. <nckx>That's not true. I don't. I don't care about these blobs at all. <nckx>*I want to see if it can work without that, for morbid reasons. <podiki[m]>so you want to see if you can fuse mount something in a container <apteryx>efraim: the reason I don't use UEFI in my case is that I can't (the board is tied to a 2015 u-boot that lacks UEFI support) <nckx>podiki[m]: I mean, the answer is going to be no, but still. <podiki[m]>I would think you can't as setuid shouldn't work from the container, right? we hope? <lechner>it would be useful, though. it's nearly an ideal use case <nckx>podiki[m]: I don't expect setuid in the container to give me root on the host, no. <nckx>I'm not quite that evil. <podiki[m]>the strace of an appimage is surprisingly concise, up to it failing to mount <nckx>Good concise or bad concise? <podiki[m]>it is like libc, libgcc_s, libfuse, then error of fusermount; maybe I need some option to follow what it spawns <podiki[m]>bad in that for once it is not overwhelming detail that might be helpful eventually <nckx>jonscoresby: Hm, you're right, I wasn't expecting the builder's default to just be ignored/overwritten. I wonder what's up with that. <nckx>Not to say it's mysterious or anything, just haven't looked further. I wonder if that default's ever used. <nckx>podiki[m]: We're getting different errors, right? What's your command line? <podiki[m]>(from a pre-inst-env that has flatpak-xdg-utils) guix shell -NCF flatpak-xdg-utils --preserve='^DBUS_SESSION_BUS_ADDRESS$' glib:bin gcc:lib coreutils fuse@2 <nckx>And that gives the ‘old style’ error? <podiki[m]>then i do PATH=/where/my/wrapper/lives:$PATH ./VSCodium... <podiki[m]>without PATH for my wrapper it does the "operation not permitted" <nckx>ACTION was futzing about with guix shell -FC zlib fuse@2 bash --expose={/etc/mtab,/run/{setuid-programs,privileged/bin}} -- sh -c 'export PATH=/run/setuid-programs:$PATH; ./GVim-v9.0.1027.glibc2.15-x86_64.AppImage' <nckx>As much as I'd embrace the sheer nihilism of pulling in Flat ‘The Other Mistake’ Pak to run an AppImage some other day, I'm not in the mood. <podiki[m]>I need the DBUS env for flatpak-spawn as that wants to talk to a portal, and I use xdg-desktop-portal-gtk <jonscoresby>nckx: seems mysterious to me haha. Related question, where does the builder code get used? I think I understand a lot of the parts of the build process, like packages, bags, build systems, the store, etc. but I'm still struggling to grok the whole process. I think all of this stuff gets passed to guix daemon and it runs everything? How can a learn <podiki[m]>nckx: I'm not using the flatpak runtime though, just the flatpak-spawn utility from flatpak-xdg-utils, in case that wasn't clear. it just makes some dbus calls from what I understand <nckx>So it's bundled with FP but doesn't initiate the whole shebang? OK. <apteryx>oh, seems I can't (extra-special-file "/boot/zImage" (file-append linux-libre-arm-generic "/zImage")); it doesn't appear under /boot following 'guix system init' <podiki[m]>separate tool, the patch I referenced has it, lives as small project spearately <nckx>Sorry jonscoresby, hope someone can answer you, otherwise ping me when I get back & I'll owe you one. <podiki[m]>nckx: thanks for playing this round of containers! I'll let you know if I get it working <apteryx>rekado: for examples for boards using a DISTRO_DEFAULTS=y config, you could look at the rpi <apteryx>is it possible to boot guix sytem without its initrd? <apteryx>I was trying to easily test the rootfs created with 'guix system init', via nfs boot. Usually I'd load the .dtb, then the kernel, then boot it from memory via u-boot <lechner>PotentialUser-17 / which features do you need? <PotentialUser-17>i'm trying to figure things out, checking what's possible, i'm new here, hello btw <lechner>everything is possible, but some things require work <civodul>apteryx: the initrd essentially loads modules, mounts the real root fs, runs activation scripts, and spawns shepherd <PotentialUser-17>i mean should i go to c source of guix to extend it or is it possible to extend scheme functions? <lechner>PotentialUser-17 / having worked with both, i would stay with scheme <lechner>changing the init system is like going to the moon, though. you will have no services whatsoever. not even login <PotentialUser-17>what i'm asking is does guix itself has a low level functions implemented, like working directly with files, sudoing some shell scripts if neccessary? i've checked the services definitions and it seems it's very high level, dependent on shepherd <apteryx>and to know whih initrd I should invoke linux with I can look into /boot/extlinux/extlinux.cfg (that's with a u-boot boatloader) <PotentialUser-17>to do it i would need to escalate privilages, create some files, run some system commands <PotentialUser-17>get output from them, and decide on control flow depending on what i see there <lechner>PotentialUser-17 / all those things are comfortably possible from scheme, i think, but you may be better off installing the Guix package manager on host distribution that uses systemd, like Debian <PotentialUser-17>can you point me to the name of library in scm which could be useful for this? <apteryx>I was able to boot Guix System off NFS from U-boot, but I had defined an SD card partition which is not plugged, so it hung trying to detect that <lechner>PotentialUser-17 / do you have experience with scheme? <PotentialUser-17>i was there, hoping for little more in depth clue, would need to go through all of this to find ones, from what i checked this is very high level <PotentialUser-17>i appreciate this, i'm familiar with language itself, i'm looking for a way to work directly with system <lechner>PotentialUser-17 / i have to run, but hope you contribute whatever you end up building. sounds exciting <podiki[m]>on the fuse and containers...indeed the actual call is a mount one before fusermount, trying with a fuse filesystem I think. not sure why that fails <podiki[m]>lechner: any knowledge of the internals when a mount call is made that uses a fuse filesystem as argument? as in a mount call in strace output <rekado>efraim: does this mean that the whole system must be installed to the microsd card? <rekado>efraim: do you happen to know of any instructions I could follow? <rekado>I find myself continuously out of my depth <podiki[m]>PotentialUser-17: I'm using strace so just seeing the system calls <PotentialUser-17>podiki[m]: i would try first with running command manually from shell, then trying to replicate in scm with "(system ..." (not sure if this is the command) <wdkrnls>Dear Guix, is there a way to specify a channel when installing a package? <podiki[m]>thanks, but think you missed all the earlier discussion, not trying to do anything in scheme, just trying to run stuf fin guix containers <podiki[m]>but if you know about mounts and fuse...do share :) <rekado>wdkrnls: you can do ‘guix build -e '(@ (the module name) package-var)'’ <rekado>assuming that the channel has a uniquely named module you can pick the variable explicitly <wdkrnls>gotcha... just trying to find the easiest way to upgrade my existing system while trying to figure out how to actually use 2022 Guix. <wdkrnls>no plans for adding lexical priorities for the upgrade case? <rekado>wdkrnls: can you perhaps state the problem more clearly? <wdkrnls>My problem is that I went through the trouble of packaging the R gpg library, providing the native input to gpgme so that it actually works. However, I was really excited to see all the work you did with guix-cran so I added that to my channels. Unfortunately, guix-cran cannot yet resolve all native inputs yet. <wdkrnls>Ideally I could type something like: guix upgrade -p ~/my/profile/rstats --prefer '(my-channel guix guix-cran *other*)' <rekado>(I only just stumbled upon it yesterday when I wanted to check if there are any forgotten R patches) <wdkrnls>especially the sharing patches over emails stuff, but I'm trying :) <rekado>if you have a public git repo with a branch I’d gladly take it from there <rekado>the patches there are a little outdated by now (not your fault that nobody applied them); do you happen to have something more recent? <rekado>I can go over them and apply them soon <rekado>I just noticed r-diagrammer there: it’s also in guix-science <rekado>can’t be added to guix yet because of tons of minified JavaScript <rekado>I was hoping you’d have a fork of Guix there with the packages of interest added to cran.scm <rekado>that would make merging things a whole lot easier <wdkrnls>oh, yeah... sorry. I did have that at one point, but it's just on my machine. <wdkrnls>Sadly, it looks like those changes got lost in my local copy. <wdkrnls>I imagine you have many many clones of guix or actually know how to manage all of those patches on one clone in some intelligent way. <podiki[m]>sneek: later tell nckx upon better looking at the strace, before fusermount is a mount call and EPERM; not sure the approach to work around that <wdkrnls>It looks like at some point I was more interested in improving the Guix documentation and threw away my change. <wdkrnls>I guess I thought that was what the patch was. <isf>whats the poin of have different ISO's the latest and the standard? <podiki[m]>isf: the standard one should be tested more and was "frozen", but sometimes you need newer fixes. right now there is a 1.4.0 release candidate in testing that I would recommend first <isf>but the repositories are the same? <podiki[m]>not sure what you mean. Guix is a rolling distro, the version number is just a sort of snapshot that can be used to install from a known point to start (and should be better tested, the installer that is) <podiki[m]>the end system is the same once you do guix pull and upgrade/reconfigure the system, yes