<gordon1>so graphviz is specified in the guix's native-inputs and it is used to build docs, why guix keeps it in the store after it had already compiled itself? <ulfvonbe`>gordon1: the store isn't cleaned of unused items until 'guix gc' is run. If you ran 'guix gc' and it's still there, it means that it's still reachable from a root. You can see what's referring to it using 'guix graph -t referrers graphviz | xdot -'. ***califax- is now known as califax
<badcodec>hi! I switched to Guix and I love it so far! <3 <badcodec>is there a way to debug log from the config during system reconfigure? <badcodec>I want to see what's in variables and such, would you perhaps connect to the guix daemon to explore the Guile code? <badcodec>the way you do with emacs, search for functions and suc <jgart>Do Guixers find themselves using the above commands in the debugger when working on a buggy Guix System config? <badcodec>I don't know what to do in emacs, essentially. So I can start a repl shell, but how would you place a breakpoint in the system config, you know <jgart>I haven't seen/heard of anyone doing something like that regularly with a Guix System config yet. Has anyone tried that before? In theory it should be possible like any other Guile code. Maybe first try to understand how you would incorporate that workflow in to some ordinary guile code that is not guix specific. <jgart>There is an undocumented macro that is mostly used for debugging. Try searching in the guile docs for `(define (box-set! x y) (set-car! x (pk y)))` <jgart>That's a racket implementation of the macro but the concept and usage should be the same <jgart>> What pk does is that it prints out the entire structure of its <jgart> arguments as a pretty-printed s-expression, but commented out via <jgart> #;. It also returns its last arguments. This makes it easy to <jgart> debug programs by “wrapping” some expression in pk. <badcodec>to see if there are any tips for hacking <jgart>I've heard of guilers using pk for debugging but not much regarding the debugger <jgart>I have heard the debugger is not that great compared to racket or common lisp, for example <badcodec>you'd essentially want a REPL in the Guix daemon, maybe. <jgart>Maybe it needs more dev love in the future <badcodec>it will take a while for me to reach that level, switched to Guix just a few days ago, first time I've heard of it <jgart>I think first step if you want to hack on Guix is to understand how to set up a guix checkout for contributing to the package collection or tool. <badcodec>jgart: for now, I just want to see if Guix can help me achieve my objectives, that involves debugging the system configuration to truly understand the possibilities <badcodec>I wanted pipewire for example, and the right way to learn fast seemed to be, to simply connect to Guix and do a (describe-function) what you do in emacs <jgart>Cool, feel free to share here what you discover regarding debugging guix/guile <jgart>Where'd you find the pipewire config? <jgart>systemcrafters, bqv, or somewhere else? <badcodec>jgart: I have none and no idea how to set it up, hence debugging the system config to even figure out where to do it <badcodec>I switched from Gentoo where I had pipewire, so I' <jgart>Have you set up a basic config first? <badcodec>so I'm aiming to get my Guix laptop to the same level as Gentoo ***califax- is now known as califax
<badcodec>jgart: yes I'm in guix and emacs exwm, so it's all working great! <jgart>maybe look at bqv or systemcrafters for the pipewire service <badcodec>it was just an example for what you might need day-to-day <badcodec>you're just staring blank at it if there's no reference config :) <jgart>oh, didn't realize pipewire was packaged <badcodec>debugging guix would also help with now to build things at all <jgart>errors are not always great sometimes when there are trivial issues <jgart>like a missing parens somewhere <jgart>the error might be a bit arcane <jgart>or a missing/invalid field in a record <jgart>I'd just watch out for those footguns <badcodec>I've noticed, haha. I didn't have anything set up in Guix at first and couldn't even format code; trying to balance paranthesis without formatted code turned out to be a pain :) <jgart>The error being reported to stdout/err might not be what you think it is <jgart>I mostly do that semi-manually but I've gotten used to it <jgart>emacs does it automatically in its own way <jgart>It's not too hard to do it manually once you get the practice/get used to it <badcodec>when experimenting and not knowing anything, it involves a lot of copy-paste, comment/uncomment, creates a mess <jgart>If you consider the repl to be self-documenting when you update the environment. Maybe geiser does what you're thinking of. <jgart>But, I've heard of people having issues with geiser <eonn>Does anyone else have tests/pypi.scm failing on the current HEAD with a pure environment? <drakonis>well, if it is failing on master and in a pure environment, then its happening to anyone else <eonn>drakonis: Just making sure I'm not missing something in setting up stuff for work <badcodec>jgart: I ran "guix repl --listen=1234" and then used (geiser-connect ...) in geiser in emacs, and it seems to spawn a REPL inside that guix <badcodec>jgart: but I don't understand the "inferior" processes in guix <badcodec>jgart: but this method of connecting to an exiting REPL process, may enable one to set breakpoints <lfam>`guix system vm` isn't working for me <lfam>Building the partition.img derivation fails with an error like 'Copying files into the device: __populate_fs: Could not allocate inode in ext2 filesystem while writing file "db.sqlite"' <lfam>mke2fs: Could not allocate inode in ext2 filesystem while populating file system <lfam>It's not deterministic, which file it fails on <dissoc>what is the best way to deploy with a service that needs a secret? is there a way to sepcify permissions on something in the stor <lfam>dissoc: Everything in the store has to be readable by all users <lfam>I'm not sure what the best practice is for handling secrets in services, but they can't be kept in the store <lfam>You might look at how the wireguard service handles private keys. It's a recent-ish service and it must handle secret keys <dissoc>gotcha.is there a way to just put a file somewhere without putting it in the store? <lfam>There is a way to do that, but I don't know what it is off-hand <eonn>Alright, it's been a while since I wrote it, but I submitted the python module I packaged for the software I was building. Thanks to everyone for their help in this channel ***sneek_ is now known as sneek
<char[m]>anyone else getting hash mismatch for clang? <attila_lendvai>how does the gc work? if i have a shepherd service, and i have a (string-append coreutils "/bin") in it, then it will be evaluated only at runtime, i.e. the resulting whepher scm file will not contain a reference into the store. is that a problem? <attila_lendvai>i guess ideally i should change my macro to evaluate it at expand time *attila_lendvai tries to turn this macro into a GEXP <attila_lendvai>so, scheme macros are transparent for the GEXP expander. too bad, i want the expansion to happen at the compile-side, not the build side <cbaines>attila_lendvai, given you're string-appending to coreutils, it's probably store /gnu/store/...-coreutils string, which will be taken in to account by the GC <attila_lendvai>cbaines, but it all depends on *when* that string-append happens. in my struggle in the jungle of GEXP, scheme macros, build-side compilation, and shepherd semantics... that string-append was called at runtime (it wasn't eventually, i couldn't make it work). i decided to rather copy-paste a little for the time being. <cbaines>the string-append, or when it happens isn't important. I'm more saying that I'm guessing coreutils will have been replaced by the /gnu/store/...-coreutils string, which will be taken in to account by the GC <attila_lendvai>right, what matters is not the string-append, but whether coreutils was lowered from the gexp into a string <cbaines>yeah, although coreutils probably isn't a gexp, but a package, still lowerable though <attila_lendvai>my issue was that it wasn't in a gexp context. it was in a scheme macro that did not get expanded until the builder was compiling the generated .scm for the shepherd service <attila_lendvai>i tried to use a scheme macro inside a gexp, hoping that it will be expanded on the "client side" (i don't know how to call these computation phases) <cbaines>in terms of shepherd services, gexp's are used to stage code to sit in the store, and be used by the shepherd <cbaines>in the case of a macro, it doesn't really matter, it can be inside the gexp, or outside <cbaines>I think the thing to be careful with is imports I think <cbaines>I think I've had problems with (begin (use-modules (foo)) (macro-from-foo)) <attila_lendvai>cbaines, yep, but with the warning that macros inside gexps must be available on the other side <cbaines>but (begin (use-modules (foo)) (begin (macro-from-foo))) worked <gordon1>ulfvonbe`: sorry, i forgot to mention but that's already after i did guix gc, i did guix graph and graphviz is a dependency of guix <attila_lendvai>cbaines, must wrap the whole thing with a with-imported-modules. it actually automatically adds the use-modules forms also. <cbaines>attila_lendvai, I wouldn't necessarily use "other side" here, but yes, if you're staging some code including a macro, you're going to need that macro to be defined <attila_lendvai>i think we badly need the lingo for designating these stages. to make it clear that some code will be loaded into an entirely different guile, including its version, and its available modules <civodul>attila_lendvai: i say "build-side code" for code staged for eventual execution, typically in package build processes <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, wingo says: when do you end up working in non-interned symbols?? <sneek>zimoun, roptat says: we need to talk about the guix days <cbaines>on the topic of macros in gexp's, I'm actually having that exact problem <cbaines>Wrong type to apply: ~S (#<syntax-transformer response-code>) (#<syntax-transformer response-code>) <zimoun>Let consider that my package depends on python-celery and python-scikit-bio. The issue is a conflict of python-prompt-toolkit as propagated-input by other dependencies of dependencies. What is the usual way for fixing? <cbaines>Guile docs say it's a "Scheme Procedure", so I'm not sure what's going on <cbaines>Ok, I've got no idea what Guile was doing, but replacing response-code with (@ (web response) response-code) seems to have fixed the issue <civodul>cbaines: define-record-type record accessors are actually macros, which makes inlining possible <civodul>so you have to make sure those are defined before you use them <cbaines>civodul, I did try moving the (use-modules (web response)) bit further away by adding some (begin bits, but it didn't seem to work <civodul>cbaines: can you share more context about the code? <cbaines>civodul, it's the guix build coordinator build success hook on bayfront <cbaines>I'm in the process of making some changes to the config to have the success hook check if a nar already exists in the nar-herder database before trying to import it <cbaines>and I'm doing that by making a HTTP request, and checking the response code <civodul>basically 'use-modules' must be done first-thing at the top level <civodul>so this is ok: (begin (use-modules ...) do things) <cbaines>I can pastebin it my failed attempt... <civodul>this is not: (begin do things (use-modules ...) do other things) <cbaines>the use-modules bit used to be inside the lambda, and I added the two begin's <abrenon>I've seen I've recently seen a tip showing how to use local-file as a source for a local development package that didn't use git-predicate <abrenon>but instead simply truncated the .git directory <abrenon>it seemed so simple and elegant and I can't find that snippet again so I came up with #:select? (lambda (x . _) (not (string=? (basename x) ".git")) <abrenon>any clue to find that other version or to simplify my attempt ? <civodul>cbaines: it's a gexp, so you need to look at the final expression where it occurs, and there all 'use-modules' must be the first thing at the top <civodul>use-modules in the middle of code is evil :-) <cbaines>is there an automatic way to have use-modules bits added right at the top of a gexp? <civodul>the problem comes up with you insert gexps within other gexps <civodul>i would love to have a scoped variant of use-modules in Guile <cbaines>if that isn't an option, maybe the guix-build-coordinator service should have a way to amend the use-modules bit at the start of the script <civodul>there are several ways around it though <civodul>one is to do like <shepherd-service> does, which is to add a 'modules' field <civodul>another one is to move those gexps to separate files and to load them *attila_lendvai is struggling with exactly this, with-imported-modules, gexps, and the modules field of <s-s> <attila_lendvai>e.g. i can't seem to write (shepherd-service (modules *my-global-var*)). i get an unbound variable error, even though it's a very simple module that #:use-module's where this var is defined and exported. <cbaines>attila_lendvai, I don't really follow. Are you saying that my-global-var is seen as unbound? Or some other variable used by a module you're using in the service? <attila_lendvai>cbaines, what i was doing to debug this is add --verbosity=10000 to guix build, and then follow through the store files. you eventually get to the generated scm file that shepherd will load as your service's config <cbaines>that sounds like a good way to debug <attila_lendvai>i have a (define my-var 42) in a module, exported. i #:use-module it from the module where i construct the (shepherd-service ...) instance. <attila_lendvai>(shepherd-service (modules my-var)) errors with an ubound variable error, and no matter how much a stare at it, i don't understand <attila_lendvai>it probably ends up getting evaluated at a phase where that module is not loaded <zimoun>civodul: Let consider that one package depends on python-celery and python-scikit-bio. The issue is a conflict of two versions of python-prompt-toolkit as propagated-input by other dependencies of dependencies. What is the usual way for fixing? <attila_lendvai>cbaines, yes (error: +default-service-modules+: unbound variable) <cbaines>attila_lendvai, can you share the code? *attila_lendvai looks at the code of define-record <cbaines>I don't think there's anything magical going on here, the variable should be evaluated when you construct the record <cbaines>attila_lendvai, does printing out the value of my-var/default-service-modules just before constructing the shpeherd-service record work? <civodul>zimoun: i would check whether there really needs to be two versions of python-prompt-toolkit <civodul>as it stands, these two packages cannot be used togehter <zimoun>civodul, thanks. But since one is @2 and the other is @3, I guess, both are required. Thanks, I would check. :-) <attila_lendvai>cbaines, wow. it's probably due to the way stuff is compiled. the problem was that in the (define my-var ...) i had an error (referenced an unimported variable). and instead of seein *this* error, i only saw the error the my-var is not defined. <attila_lendvai>cbaines, i'm running all this in: $(./pre-inst-env guix system --share=$HOME/workspace/guix/var-lib-swarm-of-guest-vm=/var/lib/swarm --no-graphic vm ../guix-crypto/tests/swarm-tests.scm) -m 2048 <cbaines>one tip is to just run things with guile when you're seeing an error <cbaines>as often that will cut out some of the confusing errors you might see at first <attila_lendvai>i was dismayed by seeing eaten up warning and errors multiple times in the codebase. this is a very bad idea... <attila_lendvai>cbaines, but running this with guile is not trivial, as it's a special env for the shepherd services <cbaines>attila_lendvai, I'm not saying invoke guile manually to run guix system, just have Guile evaluate the relevant scm file(s) <cbaines>that'll normally clearly point out issues with modules/variables *attila_lendvai listens to cbaines and makes sure his test file can be loaded with the standard module system <attila_lendvai>is there a geiser command to reload every module whose file.scm was touched? <civodul>abcdw: hi! i'll try to look at it, though i hope somebody else will beat me at it :-) <abcdw>civodul: Thank you! The more eyes will see this patch the better, as it security related. <badcodec>doesn't guix have a download cache? It feels like every time I do system reconfigure, it downloads several hundred megabytes <cbaines>are you reconfiguring from the same guix revision badcodec ? <badcodec>cbaines: I don't know, I do guix pull -C channels.scm and then guix system reconfigure .config/guix/system.scm, and today again it downloads several hundred megabytes <cbaines>doing guix pull suggests not, as that's updating guix <badcodec>cbaines: it should still have a download cache when a different version of guix is used, because the artifacts are already downloaded <cbaines>guix won't download things that are already in your store <cbaines>if it's downloading things, you don't have them locally <badcodec>ok then perhaps it download from the store <cbaines>do you have a specific example where you think it downloaded something you already had locally? <badcodec>and it goes through a list of packages, nautilus, python, etc and it looks like it downloads them again <badcodec>cbaines: no I just asked if there was a cache without further inspection <cbaines>note that changes in the dependency tree can mean that you get a new "version" of nautilus say, even though the nautilus code/version might not have changed <jpoiret>updates to package definitions without version bumping also force you to download the new ones <jpoiret>glibc 2.35 with support for C.UTF-8! <dlowe>I have a question: I have a tilde-like server with multiple users and thinking about migrating it to guix. However, it seems like guix is set up so that each user would have to pull and upgrade their own profile instead of me doing it? Is that correct? <rekado>it doesn’t need to be this way, but that’s the intended use, yes <dlowe>Okay, thanks. I was wondering if I was missing something. <dlowe>I guess I can set up a script to su each user and upgrade the guix channel for each. <rekado>you can also deny your users to have their own Guix <rekado>but that kinda goes against the intended use of Guix <gnusim_package>i submitted a patch to add a package and it seems to be forgotten :P <dlowe>I don't mind them using guix, I just don't want them to be forced to interact with it if they don't want <rekado>dlowe: I see. In that case you can manage a global default profile with software that everyone gets by default without having to use Guix. <rekado>and on top of that people *could* opt in to use Guix, and then they would be responsible for running “guix pull” and “guix upgrade” ***aya is now known as gyara
<florhizome[m]>I guess you can just have flatpak for everyone’s personal software <dlowe>Does the global profile get upgraded anytime any user upgrades? This isn't clear from the docs. The docs say explicitly that guix package operates on user profiles <dlowe>I tried guix upgrade -p /run/current-system/profile but it got cranky at me <dlowe>presumably guix system reconfigure would work but that seems heavy handed <florhizome[m]>what is the reason against having some mechanism couple’s or prepares user profiles from a system declaration? <florhizome[m]>There is a lot of stuff that is user configurable and installable but some part must be configured in the system. like every desktop environment... most packages in there do not need to be in the system profile. <singpolyma>Simple "de"s like dwm or awesomewm or whatever don't need to be in the system, but stuff like gnome is really designed to think of itself as part of the system <singpolyma>I wonder where the line is in that. Like I wonder how hard it would be to boot lxde without anything in the system. I bet not *too* hard <vldn>nice for payloading some tegra devices like the Nintendo Switch :D <florhizome[m]>If you want to be able to run dwm or awesome from a login manager, I think you need to install them in the system. <vldn>and finally finished packaging moonlight <singpolyma>florhizome[m]: no, you just put one line in .xsession <singpolyma>Login manager will have an option for "default session" or similar which runs ~/.xsession <florhizome[m]>singpolyma I don’t even think gnome is such a monolith; most of gnome does not necessarily need to be installed by root, and it still has customization. <florhizome[m]>I don’t like the concept of “good old unix” vs the rest, it just prevents talking about making good abstractions that, in guix can give users power to design their systems as they need. Esp. when good old Unix defaults to using X. <singpolyma>Yeah, maybe booting gnome from .xsession is not as hard as I guess. I haven't tried. <singpolyma>GNOME is just scary enough that I'm willing to allow it might be hard to do. But would be worth trying ***jonsger1 is now known as jonsger
<dlowe>this is headless, so desktops don't enter into it. I'd like everyone to have the same version of ls though <dlowe>guix system reconfigure it is <singpolyma>florhizome[m]: .xsession is the answer to the DE question. It's the way to make it so you don't put the DE into system <florhizome[m]>I don’t care about using x for myself, really, if I can avoid it. <dlowe>if that's the way to do it, it'd be a nice-to-have if you didn't have to specify a config file <vldn>there was some suckless alternative for xstartup i think singpolyma <florhizome[m]>singpolyma: it maybe was, but probably only for “powerusers” anyways. <florhizome[m]>we just don’t live in a world with a single display server anymore. <florhizome[m]>Anyways, how do people take local backups, especially white btrfs? I don’t want my next guix system to live without one again^^. <florhizome[m]>I just want to store a local backup on a separate partition or drive and have that automated I think. And manage that.. <singpolyma>Snapshot, then run any backup software (bup, borg, whoever) on the snapshot <singpolyma>That way you can backup the live system whenver you like so it can happen in cronjob <jpoiret>dlowe: re your system profile question with guix package -u, it won't work because /run/current-system itself is a symlink to somewhere in the store, the current system generation. The profile symlink in it is therefore read-only and guix package won't be able to operate on it <jpoiret>basically /run/current-system is managed by `guix system` and it alone (although you can inspect the contents of the /profile with guix package, which is pretty neat) <dlowe>does guix pull by any user update the channels for everyone? <jpoiret>guix pull first fetches the latest sources at ~/.cache/guix/checkouts/ <jpoiret>uses the build-aux/build-self.scm script in it to build itself in the store <dlowe>what's the equivalent for guix system then? <jpoiret>and finally updates the symlinks in /var/guix/profiles/per-user/<USER>/ and ~/.config/guix/current <dlowe>I promise I read and searched the docs <jpoiret>no worries, the docs can be a bit lacking on the guix system/guix the package manager differences <jpoiret>basically, when you do `guix pull`, you update the guix you're currently using (and for your user only, unless someone else explicitely uses your own ~/.config/guix/current/) <jpoiret>and guix-the-software contains the package definitions, unlike other distros where you have the package manager software, distinct from the package list <jpoiret>so, after having `guix pull`ed, your next guix invocations will use the latest and greatest code, and so subsequent `guix system reconfigure` calls will reconfigure your system wrt the latest guix sources <dlowe>so guix system reconfigure will use the versions that the running user is using? <jpoiret>basically, sudo searches for the command to run in your current PATH, not the PATH that the other user you want to run it as would have set in its .profile file <jpoiret>so when you do `sudo thing`, you're running thing just like you would find it yourself, but as another user <dlowe>I see why, but yeah, I wouldn't have thought of that <jpoiret>but that's (nearly) all that is retained by sudo, environment variables are cleaned up (and that can be annoying in some cases, like when running from a guix checkout) <jpoiret>i say that because some users will (rightfully so) think that since you're doing `sudo guix`, you have to update root's guix as well with `sudo guix pull` <dlowe>seems like guix could support a sudo which also swapped out the users' profiles <jpoiret>suid scripts/executables are a security nightmare most of the time <jpoiret>but yeah, it would be entirely possible to have something like `guix shell --as=<USER>` <jpoiret>although I think `sudo su` would have the same functionality :p <dlowe>yeah, but one-off privilege escalations are less evil than opening up a escalated shell <jpoiret>note although that `sudo -i` will run a shell somewhere <jpoiret>it really is mind-boggling how all these utilities rely on some version of sh <apteryx>civodul: hi! perhaps an easy thing to try is go back to post cuf pre 1.4.0 and see if it reproduces <apteryx>just to isolate whether the newly added addsitedir plays a role in it <apteryx>well, easy if you get substitutes... <apteryx>are the use of relative symlinks in relocatable pack something Guix-specific? <civodul>apteryx: yup, relocatable packs are unique! :-) <civodul>i guess the problem could occur if we do things like : os.abspath(dir) + '../foo' <apteryx>hehe :-). It seems a bit fragile though to rely on programs not canonicalizing any of their paths, if that's really the problem though :-/. <civodul>the problem is "wrong" code like showed above <civodul>the assumption that "DIR/.." is equivalent to dirname(DIR) <civodul>but it works, until DIR is a symlink *apteryx takes a closer peek <apteryx>civodul: a much cheaper when to try stuff with sitecustomize.py <apteryx>is to copy that file to the current directory, and then do something like: PYTHONPATH=. python -m yourtest <apteryx>PYTHONPATH overrides GUIX_PYTHONPATH hence your local sitecustomize.py copy can override the Guix-provided sitecustomize.py version. <apteryx>there's probably some ../../ somewhere in numpy used to refer to a relative directory, and when you are in a container or other environment such as packs lacking the expected directory hierarchy depth, it reaches a place that doesn't exist. <civodul>apteryx: ah yes, i'll try copying sitecustomize.py locally and fiddling with it <civodul>i don't think it's specific to numpy, but i haven't checked <apteryx>I'll try with another random python package <apteryx>at least 'robot' from python-robotframework runs fine <apteryx>in the same kind of environment (guix pack -RR with unshared /gnu/store) <apteryx>civodul: in the pack's etc/profile, I see: export GUIX_PYTHONPATH="${GUIX_PROFILE:-/gnu/store/ssvrlx4kpzrj73p9wnljg4fn2vlkyi54-profile}/lib/python3.9/site-packages${GUIX_PYTHONPATH:+:}$GUIX_PYTHONPATH" <apteryx>so it refers to /gnu/store... by what magic does this get rewritten to /tmp/pack ? <rekado>depends on the backend, but it’s either the glibc audit interface(?) or proot. <civodul>esseentially $PWD/gnu/store is "mapped" to /gnu/store <apteryx>the problem seems to originate at sys.prefix; it points to '/tmp/pack2/bin/../../zmv1alp7dzjd6hkc7l6fjz817n2mfzzw-python-3.9.9R', which is the later erroneous /tmp/zmv1... <apteryx>calling 'os.path.normpath' on it gives -> '/tmp/zmv1alp7dzjd6hkc7l6fjz817n2mfzzw-python-3.9.9R' <apteryx>or just: os.path.abspath(sys.prefix) <apteryx>so you are saying this is the wrong result in the presence of symlinks? <civodul>apteryx: ah ha! how's sys.prefix computed? as a function of /proc/self/exe? <apteryx>probably define in the C code of Python <apteryx>the source code is probably more useful <civodul>yeah 'reduce' is lexical dot-dot resolution :-/ <civodul>it's kinda crazy that such a bug exists here <jpoiret>I think 50%+ of devs would not consider this a bug <civodul>but it's objectively a bug, the assumption that "a/b/c/.." = "a/b" <jpoiret>maybe here the issue is more that the internal mechanisms for "import" use a non-POSIX conforming path manipulation function <jpoiret>ie os.path.normpath doesn't promise POSIX-conformity, but "import" semantics definitely should follow it <lilyp>podiki[m]: Thanks, attaching to my queue <nalaginrut>Thanks the reply to me, I can't find it anymore. But the pre-inst-env doesn't work for "guix refresh: error: mkstemp: Read-only file system" situation. <lilyp>oh wait, mkstemp probably wants to write a local file <lilyp>what's the full filename in the backtrace? <lfam>Looks like ci.guix.gnu.org is stuck on GC again <jpoiret>it happened to me a few times, mostly because I had to clean everything and start over or had not run a full `./bootstrap && ./configure --localstatedir=/var && make` <lfam>The last completed evaluations were about 28 hours ago <singpolyma>Based on how often I hear this, does the project want disk donations? 😅 <jpoiret>out with `guix gc`, in with trashing disk with old substitutes <lfam>We are in the process of copying the server to a new storage array. But it's enough data, on a live system, on slow storage, that it's taking a while <lfam>When you have many terabytes of small files, deleting is a bottleneck <lfam>I don't know the status of this copy, though <whound>I'm building a new package def and it need a newer lib version of a package that is present in Guix channel. So should first send a patch to the new version ? Or how should my problem be resolved. <whound>The new package will be submitted to Guix too. <lfam>whound: Does the library have many dependent packages? You can check with `guix refresh -l $library` <jpoiret>nalaginrut: you mentioned pre-inst-env though, right? <nalaginrut>since someone told me to try pre-inst-env, I found one and use it <jpoiret>pre-inst-env only makes sense if you're trying to use a local development checkout of guix <jpoiret>it lets you run guix from the checkout without installing anything <nalaginrut>yes, let's ignore this topic, since I just follow someone's solution to solve this issue <jpoiret>i think it'd be more helpful if you could describe your original issue instead <nalaginrut>I run "uix refresh -u solidity", and I got "guix refresh: error: mkstemp: Read-only file system" <jpoiret>you're running a precompiled guix, right? <jpoiret>i'm pretty sure -u only works in local checkouts <jpoiret>and that's what mkstemp is trying to tell you: you're running a guix in the store, which is read only <lfam>`guix refresh -u` is a development tool, used in source trees <lfam>We should make `guix refresh -u` give a hint when it fails like this. It's a common mistake when people are learning about that tool <rekado>maybe it’s a bad idea to include “guix refresh” in what “guix pull” installs. <rekado>we could have “guix refresh” provided as an extension that’s only available when using Guix from a git checkout. <lfam>`guix refresh -l` is still useful <lfam>I think that the situation would be improved by giving a hint along with the error message <ardon>Does anyone know what version of Android Platform introduced the 'pair' command to 'adb'? I want to debug a phone running A12 but Guix currently provides an Android Tools version from 2017. <platoxia>I have an all in one HP printer/scanner and finally got my config right for the printing to work but the scanner programs (xsane, simple-scan) need to be run as root or they don't find the scanner (xsane installed the sane-backends). <platoxia>This is clearly a permissions issue but I don't know what to do to fix it. <jpoiret>platoxia: do you know how these programs communicate with the scanner? most likely with a file in /dev, which won't have the proper permissions <jpoiret>if so, the easiest way to make them have proper permissions is via udev rules, and those packages might even contain some generic ones, you would only need to enable them <platoxia>jpoiret: sorry I don't know how the sane-backends work. <lfam>whound: Then, you have two options. You can either submit the update and wait until it hits master. That could take more than a year. Or you could make a package variant that inherits from the library but changes the versions. That would only have to wait for code review <lfam>There is a difference between 100s and 1000s, however <lfam>If it's like... 305, then we can cheat and do it on master, assuming it doesn't break anything <lilyp>platoxia: In that case Android 11 and newer, I'd guess <nalaginrut>it seems I've lost the connection, anyone ever answered me? <lfam>nalaginrut: `guix refresh -u` is a development tool meant to be used on a writeable source tree of Guix <lfam>If you are working on developing Guix, in a source tree (e.g. from Git), then you can use `guix refresh -u` <platoxia>lilyp: I think you are tagging the wrong person ;-) <nalaginrut>lfam: thanks, so how should I upgrade a package? <lilyp>wdym with upgrading a package? <lilyp>if you want to pull the latest guix and apply upgrades: `guix pull; guix package -u` <lilyp>if you use manifests instead `guix package -m your-manifest.scm` <lilyp>if you require "the latest" version for a given package, try --with-latest <nalaginrut>guix package -u told me nothing to do, but refresh -u can install a newer package <lilyp>guix refresh is meant for developers; it tells them when upstream has a new package not yet packaged in Guix <lilyp>for the record, which package are we talking about here? <djeis>Does anyone know how, when using a remote guix daemon and network-mounted store, the profiles get updated? The docs say it's unauthenticated, so what actually moves the profile symlinks around? <djeis>(Anyone on and up to inform me atm, I mean- I'm sure somebody knows) <lfam>nalaginrut: Can you clarify what you are trying to do? Are you trying to upgrade something that has been upgraded in GNU Guix distro, or are you trying to upgrade a package on your own, like if you were going to contribute it to the distro? <lfam>Then, you can use the `guix refresh -u` tool, but you need to have our Git repo checked out on your computer, and run the command within the repo <nalaginrut>is it the only method? people have to clone guix repo to upgrade a package? <lfam>That outlines the workflow that Guix developers use <nalaginrut>I just want to upgrade a package as a common user <lfam>It's not updated in GNU Guix, yet <lilyp>nalaginrut: you can define your package in a local scheme file <lfam>So, you are asking how to work as a developer on GNU Guix, basically <lilyp>but `guix refresh` doesn't help you maintain that 😜️ <lfam>Or that, but it could take infinitely long <nalaginrut>well, I saw it hints me there's new version with "guix refresh", so I thought I can upgrade directly <lfam>Guix is definitely a "help wanted" distro <lfam>The new version is upstream nalaginrut, not in Guix <lfam>`guix refresh` is a tool for Guix developers <lfam>"The primary audience of the guix refresh command is packagers." <jpoiret>although most of the time updating a package is a good first contribution, depending on how much work is needed <jpoiret>most of the time it's just a simple version bump <apteryx>nalaginrut: if you update the package locally and test that it works, sending a patch would allow everyone to benefit from your work :-) <apteryx>which I believe is the best course of action here <lilyp>Or if you don't like mailing list politics, you can still roll out your own channel :) <lilyp>but it's strongly preferred if people work together <drakonis>rolling your own channel is the real killer app <lfam>Doing simple updates in a channel is always going to create pain later on <lfam>Well, I don't follow channels closely, but my hunch is that, in the long run, "API" breaks create an incentive to upstream the work <lfam>I'm sure it starts out easy <Dan>Hello, I'm writing a package that connects to the Internet during its build phase. For some reason, it has a connection error. Does the build phase block connections for security purposes? <lilyp>okay, how tf do I unbreak Guix after those nls updates <lilyp>./bootstrap does not work if files are missing from git <lilyp>or rather should those file be committed to git? <Dan>Hi, how do I redownload the source when building a package? <lilyp>I don't quite see your use-case, but --source (perhaps with --check to be safe) should give you the source tarball or checkout <jgart>how does Guix keep track of what profiles you have already created? <jgart>Let's say I have 15 profiles I created. How can I list them all to see which ones have been created? <lilyp>do you literally mean 15 profiles or just 15 generations? <lilyp>it registers them as gc roots <jgart>each profile can have multiple generations <jgart>podiki[m], but thanks for sharing also <jgart>my goal is to make a script that leverages fzf/fzy/skim whatever to fuzzy select from all profiles and switch to it <jgart>I think `guix package --list-profiles` is the key <lilyp>yep, it should only list your own profiles <lilyp>gc-roots lists all roots IIRC <jgart>yup, I just saw the output but it is TMI <podiki[m]>I'm seeing at the end of building a package "Some deprecated features have been used. Set the environment variable GUILE_WARN_DEPRECATED to "detailed"..." <podiki[m]>what's the way to set that environment easily, just add a phase at the beginning to setenv? <lilyp>that setenv happens too late <podiki[m]>it needs to before guile is invoked for any of the building basically? how do I do that <lilyp>you could try setting SCM_WARN_DEPRECATED through FFI <char[m]>anyone else getting hash mismatch for clang? <podiki[m]>this is just a straightforward package using go-build-system (which I'm not familiar with), does that mean anything? <ardon>I've seen some comments on the web where it's mentioned one can run 'guix system reconfigure' without root privileges by using guix time-machine. I've attempted it but I get the following error 'Permission denied: "/var/guix/profiles/system-5-link.new"'. Is there a way to bypass having to use sudo? I have this rule in a makefile to update my system which I'd like to run via Emacs compilation-mode. <lilyp>paste your package definition or no support 😛️ <jgart>there's the guix-choose-profile script I described before in case anyone finds it useful <lilyp>jgart, you probably want to echo those commands so that you can $(guix-choose-profile) <lilyp>alternatively, you want to define guix-choose-profile as a bash function <jgart>lilyp, Can you share an example of a script prepared that way <lilyp>ardon and which of those packages causes the errorß <lilyp>char[m]: there's already substitutes for it, it seems. Which version of clang are we talking about here? <ardon>lilyp: AFAIK compilation-mode can't take user input, so there's no way for me to run a 'guix system reconfigure' rule without root privileges from Emacs' compilation mode, thereby having to resort to the shell. <lilyp>well, that's a reasonabe limitation <lilyp>oh, I pinged the wrong person again <lilyp>podiki[m]: which package causes the error? <lilyp>ardon: Perhaps you can circumvent that with pkexec? <podiki[m]>lilyp: building darkman outputs the warning about deprecated features being used, but does build and work <lilyp>i.e. it's only the darkman package, none of the others? <lilyp>jgart: skip the call at the end, you want to source that file <jgart>I source it from my bash_profile? <lilyp>yup, it defines choose_profile in your shel <lilyp>don't thank me before trying it out 😛️ <jgart>lilyp, what's the benefit of doing it that way instead of just making a script like I shared before? <podiki[m]>lilyp: ah, I think you are on to something, I see it in other go packages <jgart>that is, what is the benefit of making a bash function for it instead of just calling the script in path? <lilyp>I assume you want to change the environment of your currently running shell, no? <lilyp>You can't do that from a script you spawned <attila_lendvai>(define-configuration foo ...) also defines a foo-fields, but i would like to use it from a macro, and it's not available at expand-time. what is the idiosincratic solution to this in scheme? <attila_lendvai>a simple (eval-when (expand load eval) (define foo-fields ...)) doesn't work, because of some unbound variable errors, probably some helper <KE0VVT>abcdw: When will there be an RDE live image? <jpoiret>attila_lendvai: is define-configuration a macro? <podiki[m]>I feel like there were big go build changes in the recent past, I wonder if that is related <podiki[m]>unfortunately searching for things with "go" and the guile_warn_deprecated was not fruitful, I can report it then <jpoiret>do you want your own macro to transform into something using it or directly use it from inside the syntax transformer? <jpoiret>i don't really see how/why you would do that, but it should work as is if you (use-module ...). <attila_lendvai>jpoiret, the macro is with-foo-fields, i.e. it's expansion is alone the line (let ((foo-field1 ...) (foo-field2 ...))), with a (map configuration-field-name foo-fields) <attila_lendvai>jpoiret, and this works when i C-c C-c it in geiser, but not when i try to load the file <attila_lendvai>the issue is that at the time when with-openethereum-configuration-fields is expanded, openethereum-configuration-fields is not defined yet when the file is loaded, because first everything is expanded, and defining the toplevel forms happens only after that <unmatched-paren>would a `ci-priority` field (or something similar) be possible, to ask the beefy CI machines to prioritize certain packages that may be rather difficult to build on an average machine? currently i have to do `guix upgrade --do-not-upgrade=ungoogled-chromium`, since chromium is such a behemoth (thanks soooooo much, w3c....) <attila_lendvai>jpoiret, hrm. if i change the macro to define a foo-field2, that only holds the names of the fields, then it works when wrapped with (eval-when ). <unmatched-paren>when i used icecat, i had a similar problem, and had to leave the laptop on chugging away at the build for hours... <unmatched-paren>trivial things like various ocaml and emacs packages (which build quickly) do have substitutes, so i guess it just attacks the dependency graph semi-randomly? <podiki[m]>you could always check the weather; also, there were messages of the gc job going on for too long earlier (was it killed eventually?) which could be why things are behind <attila_lendvai>jpoiret, the error is %openethereum-configuration-openethereum-procedure: unbound variable, which looks like a record getter. <attila_lendvai>jpoiret, yep, it tries to store the getter in configuration-field as a direct value (as opposed to going through a binding lookup) <cbaines>unmatched-paren, are you not getting a substitute for ungoogled-chromium currently? <cbaines>by nope, do you mean you're not getting a substitute, or you are? <cbaines>if you're not, could you share the store paths or derivations? <unmatched-paren>/gnu/store/s3x7k2rhday13v9dfg85w2rg0y3442rf-ungoogled-chromium-97.0.4692.99-1.drv <unmatched-paren>/gnu/store/snn42xsqrsx3v614slhfnajnq15ri6cq-llvm-13.0.1.drv <- here's llvm too <cbaines>hmm, I don't have that derivation, can you share the output(s)? <unmatched-paren>/gnu/store/nnpafb0lxrzsi861ivcjjg4gghq9kkdq-clang-13.0.1.drv <- clang <unmatched-paren>i'm also using two other channels (`flat` for emacs pgtk, and my own `paren` for various other things that i can't remember), but neither has an ungoogled-chromium replacement package <attila_lendvai>jpoiret, oh, nice! looks like i can define a list of configuration-field instances that are half filled at (eval-when (expand) ...), and then redefine with full ones at (eval-when (load eval) ...) <podiki[m]>I think the CI also hasn't built anything in a while (gc-ing I heard) <cbaines>unmatched-paren, I thihk the issue here isn't one of prioritisation, just that both default build farms are a bit behind <cbaines>it's not that they're busy building other things, just that they don't know they need to build ungoogled-chromium yet <jacereda>Running make for guix yields "Makefile.am:797: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS" and "automake-1.16: error: cannot open < ./doc/guix.fi.texi: No such file or directory", any idea why? <podiki[m]>jacereda: possibly from the recent nls update (translations)? (not sure what you are supposed to do though) <jacereda>looks like the .fi translations are missing <rekado>jacereda: does ./bootstrap fix it? <jacereda>removing those from doc/local.mk seems to do the trick, at least for now <podiki[m]>earlier lilyp said something about touching files (maybe those need to just exist?) <jacereda>rekado: yes, is that a required step after each pull? <lilyp>no, it happens very rarely that we update the nls stuff <lilyp>and because it happens so rarely, it's almost always something that breaks stuff <podiki[m]>so it was just touch for those 2 missing .fi files? <jacereda>are those referenced in doc/local.mk because someone added them there and forgot to add the referenced files or is it simply that those translations don't exist at all? <jpoiret>attila_lendvai: sorry, I had to do something else halfway. Great if you managed to resolve your issue <jpoiret>although I still don't really understand the purpose of `with-openethereum-configuration-fields` <podiki[m]>(also not seeing subs for llvm etc., last CI build on master I see is from 32 hours ago) <jpoiret>most likely you don't need to eval-when though I'd wager, but if you do make sure to also check out what happens on compilation as well <attila_lendvai>jpoiret, the purpose of w-o-c-f is to avoid listing the field names in a (match-record ...). i know what's in the configuration, i want them available as lexical variables. <attila_lendvai>jpoiret, i'll test this change a bit more locally, and submit it as a patch if nothing breaks. <attila_lendvai>i'm pretty sure this eval-when is needed here. i'm not sure about my clever solution to define half-assed metadata at expand time, and then redefine with the full field instances *bsima is snowed in on friday night so trying out guix on a spare laptop <jpoiret>attila_lendvai: does the approach you sent above in a paste work? <jpoiret>that looks like an unhygenic macro to me <attila_lendvai>jpoiret, yes, it works (with my patch to define-configuration). it's unhygenic, but does that matter in this simple case? <jpoiret>i don't know what/if there's an official stance on it, but I bet you can do the same thing with hygienic macros <jpoiret>do getters not suit your use-case? they don't cost much but are much more readable imho <attila_lendvai>jpoiret, it's doable with getters, but it makes the code more verbose. these fields/variables are central concepts to this service code. there's no point in going through another indirection. these names are the exact same names as the config variables of this binary. <tschilptschilp23>Hi! Does anyone have a hint how to get a 'package' like ublock-origin-chromium into a guix home configuration? guix search returns gnu/build/chromium-extension as its location, but there's no package-definition (at least to my understanding) in there -- all looks like procedures and methods (forgive my unprecise formulation) 'how' to create these various extensions! I can even make out the point, where the ending '-chromium' gets put into <tschilptschilp23>the name of the resulting package, but all else looks very '???' to me... <jpoiret>tschilptschilp23: ublock-origin-chromium is a bit of an oddball here <jpoiret>the package definition can't point to its actual place of definition because the (package ...) part originates from gnu/build/chromium-extension.scm even though that's not where the specifics are actually defined <lfam>Can anyone build Audacity from the current master branch and tell me if it keeps a reference to ffmpeg? I thought that <https://issues.guix.gnu.org/53591> had been fixed, but now it's not working for me. Not sure if I'm going crazy or if the fix really didn't work, despite the fact that I thought I tested it <jpoiret>that's just because of how macros work in guile wrt syntax properties like location <bsima>dang, can't proceed b/c non-free wifi <jpoiret>tschilptschilp23: the package is actually defined (and the symbol available) at gnu/packages/browser-extensions.scm <tschilptschilp23>jpoiret: thanks, sounds like time for me to start up the guile-tutorial once more :) <jpoiret>ah, not sure the guile tutorial will cover syntax source properties though :) <tschilptschilp23>jpoiret: oh! great! I know, but I still have 20:80 win:fail to get these neat graphics drawn ;) <jpoiret>attila_lendvai: verbose > unhygienic macros though imo, you never know what might happen a year from now on <civodul>lfam: "guix graph audacity --path ffmpeg -t references" says there's no reference (and you don't need to have it in store to do that!) <civodul>it could be the wrong ffmpeg version though <lfam>I do have it in my store. I just feel a bit crazy, since I thought I tested it properly... <jpoiret>civodul: ??? how would you be able to check for references without having it in the store <lfam>I'm actually doing `guix gc --verify` and similar now <Zelphir>Does anyone else have issues with Geiser recently? Suddenly it seems to be looking for Guile 2.2, while I have 3.0.7 installed for a long time already. Cannot run geiser guile, cannot run scheme code blocks in org mode as guile code. Nothing. Always the same error: "geiser-repl--check-version: Geiser requires guile version 2.2 but detected bash: cannot set terminal process group (-1): Inappropriate ioctl for device <Zelphir>3.0.7" I have installed both, Emacs and Guile through Guix. <civodul>jpoiret: via substitutes; same for "guix size" <jpoiret>oh, right, you'd need to be able to know the references before downloading the needed substitutes, that makes sense <attila_lendvai>jpoiret, there are no surprises in that macro, hygienic or not. i've spent 10+ years writing very unhygenic macros in CL, and the more i learn about hygienic macros, the less convinced i am. they introduce *a lot* of extra complexity. but maybe i shouldn't open this can of worms... :) <fnstudio>Zelphir: it seems fine here (guix on foreign distro), i also seem to have guile 3.0.7 <Zelphir>Then I guess it must be something in my Emacs configuration or installed packages. <jpoiret>attila_lendvai: suppose your code looks like (let ((path "unrelated)) (your-unhygienic-macro do things with path)), and everything works fine <jpoiret>now, in a year, someone else adds a (path ) field to that configuration <jpoiret>now, you've got the original `path` shadowed because of an unhygienic macro <fnstudio>does anyone have any issue with emacs' notification-notify? if i eval (notifications-notify :title "hello" :body "world"), it says Error: (dbus-error "No connection to bus" :session) <fnstudio>i'm posting this here as opposed to #emacs as i think it might be related to some missing package at the system level <Zelphir>fnstudio: Ah and then install geiser-guile inside the emacs started that way, if it is not installed? <attila_lendvai>jpoiret, that's good point. but again, these values are very central to this service. no one should "just add a path" field. and this macro is on the toplevel at each use, i.e. the worst that can happen is that a new config field is not visible in the code. <unmatched-paren>`dllwt_unix_stubs.so: cannot open shared object file: No such file or directory` <jpoiret>Zelphir: I think guile itself works, but rather that geiser is using bash under the hood, and an error in the bash invocation ends up in output that should be parsed by geiser <jpoiret>you can see the 3.0.7 in that output, but also bash complaining about some things <Zelphir>jpoiret: yes, Guile works, I can run it just fine in a terminal and it is on the $PATH. I can run `command -v guile` it will show the guile installed via guix. <attila_lendvai>jpoiret, but the only alternative of this macro is not having it, and using accessors, no? (or using a match-record and keeping the field list updated) <unmatched-paren>so that file is in `$OUT/lib/ocaml/site-lib/stublibs/dllwt_unix_stubs.so`... <fnstudio>Zelphir: i don't think i even need to load/install anything, i just tried <jpoiret>attila_lendvai: i think "no one should" is a red flag here. <jpoiret>Maintainable code should not rely on those assumptions, people should not have to be aware of these kinds of pitfalls for it to be maintained in the future. <jpoiret>that's why verbose is better than implicit <jpoiret>well, I haven't seen much CL code, but if that's the case then yes <jpoiret>unmatched-paren: you should be able to try with LD_LIBRARY_PATH first <singpolyma>👋 What are people's feelings on how packages from npm with namespaces should be named in guix? For example, the type definitions for node are called @type/node should this just collapse to node-type-node ? <jpoiret>but still, does your approach actually work like what you posted above? I think guile tends to make unhygienic macros difficult to write because they're, uhh, hygienic by default <singpolyma>That could in theory clash with an npm package named type-node <jpoiret>define-macro should never be used, but rather define-syntax, define-syntax-rules <attila_lendvai>jpoiret, in my experience it's always clear which macros are those whose entire point is to introduce lexical bindings this way, and everyone is just fine. from the set of bugs that i was hunting in CL, these were not frequent at all. <jpoiret>I don't think we'll get any further in this discussion, but if Guile/Scheme developers emphasized hygienic macro, I'd tend to believe it's for a good reason <jpoiret>yes, I forgot you were using define-macro and not the define-syntax and friends <unmatched-paren>jpoiret: although i'm not really sure what you mean; is there some standard way to manipulate that variable in guix when you install a package? or do you mean i set it manually? <civodul>attila_lendvai: i think you'll find it hard to argue against hygienic macros here :-) <jpoiret>unmatched-paren: it's an env variable you need to set when running `utop` <jpoiret>it's used by the dynamic linker to find the shared libraries at runtime <jpoiret>basically whenever you launch a dynamically linked executable, ld is used and you can instruct it to do some things <lilyp>singpolyma: there's definitely room for typos between types-node and typed-node :P <jpoiret>(although here on guix there's a wrapper around the standard ld for, uhhh, guix reasons) <unmatched-paren>right, i knew what it was for, but for some reason wrapping the binary never occured to me... i'm a bit tired right now :) <jpoiret>attila_lendvai: I'd compare it with Rust safety features like the borrow checker. Can you avoid it and run unsafe code if you want to? Yes. Do you want to do it? No. <singpolyma>lilyp: i guess I'm just wondering if using @ or / would be allowed. I know we don't like capital letters and avoid dots <lilyp>no, dashes are the only special character allowed <lilyp>particularly @ conflicts with our version syntax <singpolyma>Right, ok. So just node-type-node and if there's an issue deal with it at that time <lilyp>so you could name it node--types-node or node-types-node <lfam>I'm sorry to cause this confusion *attila_lendvai happily dances along the pitfalls when that road is so much shorter, and the pitfalls are not deadly <attila_lendvai>jpoiret, i'd rather compare it to pure functional programming: it's preferrable for 90+% of the codebase, but sweating the last 10% may not be worth it. <Zelphir>Running emacs with `emacs -q` and then trying to run an org mode scheme source block results in "No org-babel-execute function for scheme!". I guess this is, because no default scheme for running scheme source blocks has been defined. <lfam>I could have sworn it worked <Zelphir>Trying to run `run-guile` results in "Symbol’s function definition is void: run-guile". <lilyp>there's an extra "L" that I forgot to strip <lilyp>I'm pretty sure that thing's introducing a wide string <lilyp>char[m]: ./pre-inst-env guix build clang -S <lilyp>/gnu/store/90k9bgx2aibdihbckirmbagzgq8bb9g6-clang-13.0.1.src.tar.xz <jpoiret>attila_lendvai: well, you can still try to reduce the places where you *really* need unsafe features to a minimum