<rekado>I’m not serious about the bash extension. <rekado>but I played with this because I was looking for a way to wrap binaries without having to write to a separate file. <rekado>our shell wrappers for binaries have the unfortunate effect of adding a bunch of dot-prefixed executables to the bin directory, and they mess with the name that the executable sees. ***caleb__ is now known as KE0VVT
<rekado>wrap-script was the attempt to get rid of these separate shell wrapper files for text files (e.g. scripts that use # as a comment character). <nckx>(Nah, actually I like it, but it's becoming hard to remember what does what how.) <nckx>Is this at all reliable? <rekado>I’m just happy that this actually works. Today I stumbled upon memfd_create while searching for something entirely unrelated, and it made me all giddy. <rekado>I don’t think we’d really want to use it as is. We’d probably want a bunch of additional features which would complicate all this. <rekado>e.g. an escape hatch to disable the added env vars at runtime; a way to specify appending, prepending, replacing existing vars, etc <rekado>and I don’t know if this works better or worse with gdb <rekado>gdb configuration with shell wrappers is a drag, but it’s also trivial to just run the unwrapped binary. Would be harder with a baked-in binary wrapper. <rekado>the wrapper blob is also obscenely large for what it is. <nckx>I'm kinda reassured that it's ‘here's a crazy thing I dreamt up for no reason’ rather than ‘here's the best thing I came up with to fix a vital use case I need’. <rekado>it’s reliable only if we assume a certain minimum runtime kernel version. A graceful fallback (on a system where memfd_create and fexecve don’t exist) would require copying, which would make this a worse wrapper than a shell wrapper in the bin directory. <rekado>‘guix pack’ already uses some binary launchers with a number of execution engines; if we really wanted to we could probably cook up a better launcher with whatever we already have there, without debasing ourselves with this fexecve hack. <rekado>but it’s not like anyone *really* cares much about this anyway. <muradm>any better way to write: (if (not (null? enabled)) (string-append "enabled = " (if backend "true" "false") "\n") "") <lilyp>I'm pretty sure that there's a boolean->string conversion somewhere <lilyp>the next question is why enabled is a list or backend a boolean <lilyp>why not a map over the backends? <muradm>lilyp: backend is a field match-lambda'ed from record, where (default '()) because #t and #f are intended values <muradm>so boolean can't be used as control <muradm>basically it is record serialization code <lilyp>that just raises more questions <lilyp>why does it carry the value of enabled? <lilyp>why is '() the default and not, idk, *unspecified* <muradm>(record-1 (backend #t)) (record-1 (backend #f)) (record-1) should produce different outputs "backed = true" "backend = false" and "" respectively <Guest99>Running 'guix pull' on brand new qemu v1.3.0 downloaded from the guix website results in an error, "cannot build derivation ... dependencies couldn't be built ... build of ____ failed". Is this something that is known to happen with the v1.3.0 image? <muradm>ah and there was typo: (if (not (null? enabled)) (string-append "enabled = " (if enabled "true" "false") "\n") "") <lilyp>I still fail to see the need for null? <muradm>lilyp: (define-record-type* <record-1> .... (enabled (default '()))) <muradm>(record-1 (backend #t)) (record-1 (backend #f)) (record-1) <muradm>"backed = true" "backend = false" and "" <muradm>any way, i will figure out my self <lilyp>it still isn't a meaningful value <lilyp>*unspecified* on the other hand is <muradm>(string-append "aa" #<unspecified> "bb") fails in the end <muradm>have to filter out those #<unspecified> <lilyp>you mean like you have to filter out those lists? <lilyp>yeah, sure, but the result will still be less confusing than if you use a list for something that shouldn't be a list <muradm>imagine there are many similar fields not just one enabled <muradm>i don't use list, i use empty list as empty <lilyp>and I'm telling you that you shouldn't <lilyp>use empty list if you actually mean unspecified value <muradm>what should be default value for record field if unspecified? <lilyp>anyway, re: "what do I do if I have more than one field that works like that?" – idk, maybe use a function or something? <lilyp>I told you before about the existence of *unspecified*, did I not? <nckx>And its handy sibling, unspecified?. <nckx>I just wanted to specify that it wouldn't complicate anything, it's a simple null? → unspecified? → done. <lilyp>well, the task wasn't "equally complicated", but "better", which null? → unspecified? doesn't achieve unless you read the code a few times <nckx>Are you handing out tasks again? <lilyp>I mean for full clarity one could also (cond ((unspecified? val) "") ((not val) "enabled = false") (else "enabled = true")) <lilyp>I'm not handing out tasks, muradm was asking for pointers and 0xdeadbeef was not in the freelist :( <lilyp>why tf do you still have '() and null? in there? <muradm>(face palm) becuase i need 3 states, when field is not set, when set to #t or when set to #f <nckx>That doesn't really answer the reasonable question. <muradm>(config-1->string (config-1)) (config-1->string (config-1 (enabled #t))) (config-1->string (config-1 (enabled #f))) <muradm>should produce 3 different results <lilyp>and yes, that doesn't handle the fancy conversion of #t to "true", but it serves to make a point <nckx>(if val (or (null? '()) "true") "false") <nckx>muradm: Wouldn't that be 4 states (true, false, unspecified, null)? <muradm>lilyp: there are 3 states: (config-1->string (config-1)) (config-1->string (config-1 (enabled <muradm> #t))) (config-1->string (config-1 (enabled #f))) <muradm>(config-1->string (config-1)) provides wrong output <lilyp>and do you know why it does that? <lilyp>have a good hard look at your default <muradm>any way i will make custom syntax to simplify <lilyp>p sure that'd be an error without evaluating it <lilyp>hint: I already gave you the solution <nckx>muradm: Why don't you want to use *unspecified* as suggested? <nckx>If we understand why not, perhaps better advice (even: tasks) can be given. <mroh>can someone confirm "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (chicken-srfi-37)) (value #f))" on building guix-package-cache? Seems like chicken-args is broken?! <nckx>Somebody mentioned it earlier. <nckx>They said a patch was merged that depended on another one that wasn't. I guess nobody jumped on it in the meantime, so I'll take a look. <muradm>but i was asking for simplified version of that if <nckx>You kept pasting buggy code with (default '()). <muradm>otherwise what is the difference '()/null? *unspecified*/unspecified? <nckx>What needs to be ‘simplified’? <nckx>muradm: Because one uses values properly and one doesn't. <nckx>You could write code that uses 'unspecified and it would be equally iffy. <muradm>nckx: my original question was: what is the better way to write (if (unspecified? enabled) "" (format #f "enabled = ~a\n" (if enabled "true" "false"))) <nckx>I'll leave the why as a (trivial) exercise for the reader. <muradm>with unspecified? of course, but not whith null? (which is the original version of mine). buggy one i put intentionally in order to understand why do you keep asking for unspecified <nckx>And then expect people to still help you. <lilyp>I very much doubt the intentionality behid that. <muradm>i understand clearly how both '()/null? and *unspecified*/unspecified? work <muradm>my question was on simplifying if, if there is a way <muradm>nckx: sorry, i was asking one thing, but i was dragged to another which caused misunderstanding <lilyp>In the end, you'll always have three cases, so there's little room to hide the complexity <lilyp>case statements are nice if you like them <lilyp>if you need more than just booleans, then you might want ice-9 match <lilyp>otherwise you can (boolean->string) for the #t → true and #f → false to save one if <nckx>I guess I'd use cond like lilyp, because (ice-9 match) is a bit overkill IMO (but then IMO Guix uses match very eagerly in places where I might not, so it is very Guixy). <lilyp>you do have to define boolean->string, though <nckx>There was definitely no need for the match-lambda I vaguely remember from a previous paste. <nckx>I mean, if rewriting (if foo? "true" "false") as a procedure is one's idea of simplifying, sure. <nckx>That's the great thing about doing things the best way — so many options. <nckx>Yay, guix pull failed, as exp— uhm: gnu/packages/image-processing.scm:502:15: missing close paren: " <lilyp>for the record, we do have a similar problem in the linux config, where #t, #f and m are valid values <muradm>(if (null? enabled) "" (format #f "enabled = ~a\n" (if enabled "true" "false"))) <muradm>this is fine, i will go with this for now <nckx>Whoa, I just got tree(1) to segfault. *nckx starts to eye new laptop… worriedly. <muradm>nckx: *unspecified*/unspecified? later for you :) <muradm>suppose somewhere in configuration records->string i have to (error ...) is this fine for you? <nckx>If it makes sense, display-hint for extra credit. <nckx>(Super-nitpick: I'd keep ‘unknown’ over ‘invalid’ in the message, it's more accurate.) <muradm>(display-hint (G_ "webssh: reject policy requires `known-hosts'.")) <lilyp>nckx: Interestingly the checkout compiles locally with the warning about chicken-srfi-37 <nckx>guix pull: gnu/packages/gnome.scm:3324:10: Unknown # object: "#g" <nckx>I guess we're running memtest tonight. <lilyp>What's the template for revert messages? <nckx>The git default (nobody seems to mind that they aren't changelogs) with a human-readable rationale added. <lilyp>Before or after "This reverts ..."? <nckx>This reverts commit xxx, which introduced a back door into nginx. Or a new paragraph. Whatever you think best fits. <lilyp>IIUC that's just a handy example, not something that happened <lilyp>though I wouldn't be surprised if someone tried to backdoor nginx upstream <nckx>Yes, jeez, please delete your HN posts. <nckx>I should've gone for ‘This reverts commit xxx, which accidentally removed all back doors in linux-libre’ anyway. <muradm>nckx: i have to (let ((err (... ))) (display-hint err) (error err)) something like that? <nckx>Eh, no, that's not what I meant. Sorry if I was unclear. Just call error directly, no need for helpers. <nckx>Since the list is so short I would *also* add a hint with the valid values. <lilyp>This reverts commit xxx, which accidentally added alcohol to wine. <nckx>now that I've had time to think about it <nckx>so it's probably not worth the maintenance hassle. Just use (error "unknown blahdiblah bad user"), ignore the hint stuff, muradm. <lilyp>I'm pretty sure there's a format string for iteration you could use to provide valid values as a list without fucking up i18n <nckx>Great if true. If not the user will have to open the manual to check the valid values, which is definitely suboptimal. Is it a gettext thing or a Guile thing, lilyp? <nckx>I kind of… steer clear of gettext TBH. <lilyp>I mean (ice-9 format)'s iteration <nckx>~{ ~a~} apparently works. <lilyp>which would cleverly evade gettext <nckx>I forgot translators are just expected to see stuff like ~a~{ ~a~}~% in strings and dutifully copy them. <nckx>Anyway, back to recommending error + display-hint with a list of valid values I go. <nckx>mbsync[5563]: segfault at 29024ea230 ip 000000000040be95 sp 00007ffc1127a500 error 6 cpu 3 in mbsync[404000+1c000] <nckx>I am going to… reboot, for… reasons… good night, #guix. <char[m]>PurpleSym: I got the wip-haskell branch. I think I successfuly packaged ghc@9.2.3. It keeps failing though (I think out of memory). Could I send you the package and you try it? <apteryx>(/gnu/store is still on an old ext4 drive/file system) <muradm>what in-vicinity does? where does it defined? <roptat>mh, clang-6 tries to use ld instead of aarch64-linux-gnu-ld, and using strace I can see it's trying to look for aarch64--linux-gnu-ld instead :/ <roptat>clang-9 is able to find the correct ld though <roptat>oh "Target: aarch64--linux-gnu" it says :/ <roptat>ah it looks like it's llvm's fault <PurpleSym>char: I’ll try to build it and see what happens. <PurpleSym>char: It’s just looping infinitely at `make --no-print-directory -f ghc.mk phase=0 phase_0_builds` for me. <PurpleSym>If I remember correctly they added a new build system with 9.0. Maybe that broke the old way? <yarl>I will use a concrete example for a general question. <yarl>The package artanis has input guile-3.0 among others. <yarl>I used guix shell with artanis. <yarl>I also installed artanis in my current profile. <yarl>artanis, as reported by `guix show` uses guile@3.0.7 <yarl>guile-3.0.8 is currently available. <yarl>I would like artanis to use guile-3.0.8 . <jpoiret>can you try `guix shell --with-input=guile=guile@3.0.8 artanis`? <yarl>jpoiret: thank you this will be useful I will try. I continue to follow my questionning. <yarl>My reasoning is that if I garbage collect everything about artanis, the next time I install it, it will use guile-3.0.8. <yarl>I then deleted old profiles and garbage collected everything. <yarl>But, there is still guix shell cache, right? <yarl>Then you can get stuck with a package with "old" inputs because of a guix shell you ran once. And guix gc does not take care of this. Am I right? <jpoiret>if a version of guix builds artanis with guile 3.0.7, it will do so every tim <jpoiret>since dependencies are managed separately, you don't have a "global" guile <jpoiret>ie artanis could use guile 3.0.7 while another package you installed uses 3.0.8 <yarl>jpoiret: of course, I got that <yarl>That's not the point I wanted to shed light on, I might have misexplain or I am completely wrong. <yarl>In the package definition of artanis, the input for guile is guile-3.0 . I assume so that when the package is build it will take the latest guile-3.0.x <yarl>Now, when you `guix install artanis` if artanis is already in the store somewhere, it wont being build (or substituted), because it's here cached. <yarl>Let's call this point 1. I might be wrong here. <yarl>Assuming this, I tried (and failed) to remove everything about artanis in the store. (But I didn't used `guix gc -D`. While if my assumption is right this should work, that shouldn't be the way, I think. It's too manual). <yarl>The reason I couldn't garbage collect everything, I think (and this is point 2), is because, according to the manual for guix shell, it uses a cache (of it's own?). <yarl>jpoiret: What do you think? <jpoiret>yarl: `guix install artanis` will re-use the artanis in the store only if it would be *exactly* the same as the one it would build <jpoiret>if you want guile@3.0.8, you need to use the variable guile-3.0-latest <yarl>Where this "guile-3.0 points to a 3.0.7 guile" is specified? <jpoiret>since it added cross-module inlining, it might introduce some bugs. Guix for example disables cross-module inlining iirc <jpoiret>yarl: I just looked at the package definition in gnu/packages/guile.scm <yarl>Oh jpoiret, sorry about that.. <jpoiret>no worries, everyone has to learn things at some point <yarl>jpoiret: Anyway! There is still a problem. Why after removing artanis, deleting old revisions, garbage collecting, artanis is still in the store? <jpoiret>you can use `guix gc --referrers /gnu/store/XXXXX-artanis` to see which other store entries refer to it <jpoiret>most likely a reference is kept by something <yarl>Yes, I tried this and the artanis itself (same hash) is it's own referrers and a couple of profiles. <jpoiret>then those profiles are retaining a reference to artanis <jpoiret>most likely, you have old profile generations that still retain a reference to the artanis package <yarl>jpoiret: still, those profiles seem to correspond to those used by guix shell. <yarl>Where could I check that? <jpoiret>roptat: i think they are, temporarily <jpoiret>you can manually inspect the cache at ~/.cache/guix/profiles/ <roptat>you'll find gc roots in /var/guix/gcroots <roptat>(removing any from there is *dangerous*) <jpoiret>I liked the selective ability of manually creating a gc-root <yarl>That guix shell is not using the same mechanism. <jpoiret>well it is using the same mechanism, but there is no common interface for all of them <yarl>I mean the same cache mechanism <yarl>well I do not master what I'm talking about.. <yarl>roptat: I think I meant what jpoiret just said. In my own words : <jpoiret>as keeping old profile generations around for eg `guix package` <yarl>(If I understand correctly) guix shell uses whatever as been already build in the store (to avoid rebuild). But, it stores roots somewhere else that `guix gc` does not fully know about. <yarl>So paths stay live while they are not references to roots visible with --list-roots <yarl>Is what I just said confuse? <minima>hi, i've just sent a patch titled '[PATCH] gnu: Add texlive-mdframed.' - i haven't done much other than copying the output of guix import, adjusting a minor thing, and checking that everything was working fine <yarl>The point I think is that `guix gc` then does not fully garbage collect. There is still roots owned by previous `guix shell` uses. <minima>it's my first guix patch though, if anyone spots any mistake i might have made in sending the patch, i'd love to know and fix it <yarl>oh! I am at least partially wrong, they are ~/.cache/guix/profile are visible using --list-roots <yarl>That's why their references are not GC. <yarl>roptat, jpoiret and everybody : Sorry for this monolog. How can I remove those roots? Don't you think there is a missing option on `guix shell` (--clean-cache?) or `guix gc` (--clean-shell-cache?)? <jpoiret>you can simply rm the links in .cache/guix/profiles/ <jpoiret>there's unfortunately no --delete-cache option from what I could see <NaturalNumber>guix home reconfigure fails and the log says "error: path '/var/log/guix/drvs/j3/8rfkr21cwnr9nmhl6bhbji409dixdg-setup-environment.drv.gz' is not a flake (because it's not a directory) <NaturalNumber>obviously it has to do with nix, right? it's a system service <NaturalNumber>before it said "requires experimental features" so i added that option <roptat>fwiw, 'is not a flake' is not a string you can find in Guix <roptat>maybe sharing your home config could help? <jpoiret>minima: was that your first mail to guix-patches@gnu.org? <jpoiret>if so, it'll need to pass moderation first i think <minima>jpoiret: yeah, my first one; ah right, i can see it already but that's simply because git-send-email CCed me in... right... <jpoiret>after your first mail gets approved, the subsequent ones should go through directly <NaturalNumber>roptat: i think my guile syntax was off. it seems to be working now <minima>now let me indulge in a flight of fantasy for a minute and that my small patch makes sense... if i had some more texlive package definitions to submit, i suppose i should keep sending them as separate patches (and in separate git send-email threads)? <roptat>you could group them together, especially if there are dependencies between them <minima>roptat: awesome, thanks - there are no dependencies other than the fact that i'd be adding them one after the other to tex.scm <roptat>yeah, it's probably best to group them, because applying patch 3 will not work immediately if you don't have patches 1 and 2 <minima>so, if handled separately they'd need some additional work to be merged/rebased one on top of the other if i understand it correctly? <minima>yeah, brill, that seems to confirm my understanding <roptat>it's still possible to work on them one by one, but it's more practical to treat them a as a patch series *roptat is still working on the French translation <roptat>I'm getting to the less interesting but easier part, about all the system services <minima>roptat: locally, i've been working on a feature/branch that comes out of master, is that what one would usually do? <roptat>rebase it on top of master before you send your patches, to be sure there's no conflict <roptat>I mean, pull --rebase master in your branch <roptat>I also use worktrees to work on my branches, so I don't have to remake stuff when I switch branch <minima>oh, not sure what a worktree is, but i'll look it up, thanks! <jpoiret>minima: also, it's good practice to include your base-commit in the patches, using --base=auto <jpoiret>i personally use worktrees for branches that differ greatly, eg staging vs. master vs. core-updates <minima>oh... that's good to know re --base=auto <jpoiret>it lets maintainers that want to merge your patches work out the merge conflicts themselves <minima>and sorry, since i have you here, is that an option for what exactly? git format-patch? <jpoiret>format-patch and send-email (the latter if you directly use it instead of format-patch -> send-email) <minima>ok cool, it says i need to set an upstream branch... <minima>not sure, maybe that should be master? locally i've been working out of a feature branch <minima>no, i think it might have to be the local feature branch itself? <minima>nope, it has to be a remote branch... and rightfully so i guess :) <jpoiret>muradm: are you in the special subshell that runs everything in the store monad? <jpoiret>(plain-file ...) is not a monadic value <muradm>jpoiret: yes after ,enter-store-monad <jpoiret>you'll want (lower-object (plain-file ...)) <cbaines>also muradm, plain-file is the declarative counterpart of text-file (from (guix store)), there's also text-file* <cbaines>reading the docstrings for these procedures can be quite useful <muradm>i added a package fail2ban, now it contains etc/fail2ban/* stuff, is there short way to make derivation that will contain only etc from that package <muradm>(filtered-derviation (lambda (f) ...) package) something like that <cbaines>derivations are the .drv files, they describe how to build things, rather than containing files <jpoiret>you can create a new package that hardlinks the /etc from the input package to its output <cbaines>why do you want to split the etc/ files out muradm ? <jpoiret>or you could look at the build system to determine what you need to do in order to only get the /etc files <muradm>cbaines: fail2ban includes tones of config files, which i package with it. then for fail2ban-service-type i want to create (directory-union "runtime-config" (list default-config-from-package extra-config-from-services)) <muradm>then i can point runtime-config to daemon <cbaines>a derivation can have multiple outputs, but what that's generally used for is when there's some subset of the files which are both large and often unnecessary <cbaines>unless these config files are particularly large, I'd just use one output for simplicity <cbaines>you can still do the union thing in the service <cbaines>file-append might come in useful, since you can union (file-append fail2ban "/etc/fail2ban") with the extra service config <cbaines>there's probably some bits that could be tweaked to be more consise, but it looks OK to me. I'd suggest just getting something working so that you can get a system test written. ***jackhill is now known as KM4MBG
***KM4MBG is now known as jackhill
<kitzman>does weston fail to build only for me? I didn't find an issue about it <nckx>Seems so, as there's a substitute. <nckx>kitzman: Builds fine locally, too. What fails? <kitzman>hm, it doesn't use the substitute. a "weston-desktop-shell" test fails. but i last pulled 27 days ago. maybe i should try a pull first. <fnstudio>hi, i have a system definition called base-operating-system that i was able to deploy on a remote server <fnstudio>it works and i'm now playing with it a bit, e.g. to try and install some additional service <muradm>ok, had to put one more import within gexp <fnstudio>i can no longer ssh into the remote machine and i had to roll-back <fnstudio>well, i see why... i used 'operating-system-packages' but that's not a thing apparently <fnstudio>anyone knows from the tip of their head how to extend a base system def? <dominicm>fnstudio: 'operating-system-packages' is a thing; did you import the '(gnu system)' module? <muradm>dominicm: may be (packages (cons tmux (this-operating-system))) ? <dominicm>no problem; (cons* package1 package2 ... (operating-system-packages os)) works for me <dominicm>muradm: I don't think that would work right? (this-operating-system) doesn't return a package list <muradm>fnstudio: supposedly refersto the current record <fnstudio>hm... if i use '(cons tmux (operating-system-packages this-operating-system))' i'm told that 'this-operating-system: cannot be used outside of a record instantiation' <dominicm>fnstudio: I think what you're looking for is 'base-operating-system' anyway; otherwise, you're recursively referring to the packages of the record in the package definition of the record <kitzman>nckx: i see that cuirass builds for weston x86_64 are failing since a while with the same issue, the last success being on 8th of June. i can do without weston for now <nckx>I'd assume the recursion was the point. <fnstudio>dominicm: ah i see, good to know, thanks - i still seem to have issues with 'base-operating-system', even after adding the '(gnu system)' module, i'm investigating... :) <nckx>kitzman: I'm on a commit from 16 June, though (f6904). Although I didn't investigate. <nckx>dominicm: What is base-operating-system? <nckx>Yes, (field (cons something this-field)) can never work. <nckx>It's like (define x (+ 1 x)). ***califax_ is now known as califax
<fnstudio>nckx: sorry, does that mean that '(packages (cons tmux (operating-system-packages base-operating-system)))' is incorrect? or only that i can't use 'this-operating-system'? <fnstudio>context: 'base-operating-system' is an another (working) os definition of mine <roptat>how do you specify a cross-compiled package in guile? <nckx>What's weird (well, surprising) was that I got that error message in a *different* field than package: (package (list foo)) (something-else (operating-system-package this-operating-system)) <nckx>fnstudio: Yes, my bad, I skimmed the backlog but missed that crucial line. <fnstudio>as soon as i 'system reconfigure' my (remote) system using the "extended" definition... then i can no longer ssh into it <fnstudio>interestingly... tmux gets installed correctly, it seems <nckx>My test case was pretty contrived though (making all system packages setuid, for extra security). Still, was surprised. <fnstudio>hm... the term service doesn't get restarted though - which i'm hesitant to restart manually as that'd cut the branch i'm sitting on <yarl>jpoiret: I tried guix shell --with-input=guile=guile@3.0.8 artanis . I failed with "Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS". <yarl>(I think, I'm dumb I rebooted without keeping the log, retrying right now) <fnstudio>the first image seems to be working fine and i can connect to the remote machine where that gets deployed; if i reconfigure to 'super-operating-system' though, i seem to lose ssh access ***Dynom_ is now known as Guest9823
<f1refly>I tried putting swaylock-effects as screen-locker-service, but when I try executing swaylock it tells me it needs to be setuid and swaylock-effects is not in $PATH, am I doing something wrong? <fnstudio>i don't understand... if i somehow "force" the services in again in my extended os definition, like here https://bpa.st/TERQ, and then i reconfigure, i get this error: guix system: error: more than one target service of type 'system' <mbakke>any rustaceans around who would like to try updating librsvg? :-) <singpolyma>mbakke: is there a dependency the importer doesn't work for? <singpolyma>IME most rust packages "just work" with guix. But of course the importer is not 100% <nckx>f1refly: Did you add it (presumably swaylock, as I read your message) to setuid-programs? <tewi>i tried qtbase-5 gtk+ gtk+-2 libx11 pango (inputs and native-inputs), but after finally getting the package to work, it's missing the gtk2 theme in qt5ct (other themes from qtstyleplugins are available). so i'm thinking if i'm missing some gtk thing? <fnstudio>'guix system list-generations' and 'guix describe' seem to give different results (different generation numbers and timestamps) - i suppose that's fine and that it's just me not fully catching the difference between the two commands? <f1refly>nckx: I did not know that was a thing. I'll try adding the program and see if it works then <nckx>f1refly: Since anyone can add any content to the store (this is a feature), we can't allow packages to say ‘make me setuid please’. Only root can do that through the Guix System configuration. <nckx>fnstudio: ‘guix describe’ describes Guix itself (i.e., when and which commit{s,} you ‘guix pull’ed, for each channel), ‘guix system list-generations’ list each time and from which Guix channel commit{s,} you ran ‘guix system reconfigure’. <nckx>If you didn't guix pull since you last ran ‘guix system reconfigure’ the commits should match, though. <fnstudio>nckx: oh ok, trying to digest that properly... <nckx>You could imagine it as if the contents of ‘guix describe’ are copied to each system generation (everything under ‘channels:’ in ‘guix system describe’) so you can later see which Guix created that system generation. <fnstudio>so 'guix pull' will modify the output of 'guix describe', but not the output of 'guix system list-generations', iiuc - i'm trying on my machine <nckx>You have systems and guixes, and each has monotonically increasing generations (‘guix describe’ will change on each ‘guix pull’, and ‘guix system describe’ on each ‘guix system reconfigure’ — the two sets of generations are completely independent, as you'll notice). <fnstudio>so in other words, 'guix describe' (well, as the name implies!) describes the status of guix as a "repository" on my computer? but it doesn't say anything on the status of my system? <nckx>‘guix system describe’ is like ‘guix system list-generations | head --most-recent-generation’, it is the system equivalent to ‘guix describe’. <fnstudio>ah i see... this is... well... enlightening! thanks nckx! <nckx>fnstudio: <so in other words> Exactly! <nckx>As you probably know, the guix command and ‘repository’ are not separate in Guix, but otherwise correct. <char[m]>PurpleSym Thanks for trying it. Good catch with the looping; that is very confusing to me. <fnstudio>i like the distinction between systems and guixes!! and again, it's actually kind of clear if i think of it by looking at the guix api (api as in command structure/interface) <fnstudio>nckx: <the guix command and 'repository' are not separate>... hm wait... don't i need to do a upgrade to end up with a new guix command though? and what about guix as a daemon? <userix>Hey guys. Is it true that Guix blocked the users from Russia??! <nckx>I do not want to confuse you further, but just to illustrate that all profiles are versioned in guix: there's also ‘guix package --list-generations’, which does something similar for your user profile — the place where ‘guix install’ and friends manage packages. Again, all generations of each type are independent, in their own namespace, but they all increase over time and allow rolling back what you haven't yet GC'd. <nckx>userix: That is a very malicious way of phrasing the reality, yes. The academic institute which provides us with free hosting and (a ridiculously generous amount of) hardware has filtered some Russian IP space because they observed malicious activity, apparently. <nckx>It is based on that, not nationality. <nckx>Also, there was some work to create mirrors but I've been out of the loop the last few weeks. <char[m]>Could someone help me understand bootstraping (under guix). Say I'm building compiler for language X, written in X. It also uses some X libraries. It makes sense to me to build version 2 of X using version 1 of X. That would mean the X libraries need to be built using version 1, but that doesn't seem possible under guix where all libraries are built using the latest version. <userix>nckx, thank you for clarify the things! <nckx>fnstudio: <don't i need to do a upgrade to end up with a new guix command> Depends… An upgrade of what? <two[m]>char[m]: i don't know that, but you should probably see "--with-inputs" in the manual <nckx>userix: You're welcome, and assuming you're Russian, you're just as welcome as anyone :) We're just tremendously understaffed when it comes to competent infra people with time, it seems. <userix>actually ucrainian, but anyway, very aware of divide politics and other things <userix>free software is free for everyone <nckx>Well, same thing applies. <nckx>char[m]: You can package multiple versions of X. <nckx>This is what we do for Rust, to a ridiculous degree. <fnstudio>nckx: no no, you never confound me, it's always helpful; sorry, i meant a 'guix upgrade' that i thought it was short for 'guix package --upgrade'? <char[m]>nckx: I am aware of the different comiler versions. I'm specifically asking about the library version which use the x-build-system which tends to use the latest version of X <nckx>You can probably convince any build system not to use any of its implicit inputs, or basically replace everything to make it do so, or a combination. <nckx>I'd say that we should discuss a concrete language + build-system rather than an abstract, so we can say more than vague generalities, but the result would probably be me saying ‘I don't know that language, sorry’ ☺ Still, it would help to provide details. <lfam>Many of the build-systems in Guix have a key with which you can choose a specific package for the compiler <lfam>For example, in python-build-system, there is the #:python key <char[m]>lfam: I see. Is it common to do that for bootstraping? <nckx>fnstudio: So… ‘guix upgrade’ upgrades all packages installed with ‘guix install’ (or a synonym like ‘guix package -i’). That's correct. However, ‘guix’ itself is special: to prevent a Russian nesting chicken egg-doll situation, it sits *outside* the user profile (~/.guix-profile, with all your user software) in its own special private profile (~/.config/guix/current, with *only* guix, updated with ‘guix pull’). <lfam>char[m]: That's a question where you need to get a lot more specific <nckx>Updating the latter ‘updates’ the list of available packages; running ‘guix upgrade’ after that actually applies the updates so you get the newest GIMP & HexChat. <char[m]>lfam: I guess what I mean to ask is: is it an intended use case? <lfam>No. The intended use case is to use a different version of the compiler for a package that happens to need that compiler version <nckx>userix: I'll probably regret asking, but where did you hear that anyway? I can understand people being frustrated, it's just not a deliberate choice we made as a project. <nckx>fnstudio: On Guix Systems, the guix-daemon is a regular operating-system service (guix-service-type), so it is upgraded each time you ‘guix pull && sudo guix system reconfigure’ or equivalent. <nckx>The daemon is hella stable (because nobody dares touch C++), and is not required to run the system, only to build packages, so it's generally OK if it's a bit out-of-date compared to your ‘guix’ command. <nckx>It will get updated in time when you decide to update your kernel, or add a new option to the cups-service-type, or… Not something you should worry much about. <nckx>Aside: guix-service sounds like an ideal case for socket activation, unless I'm missing something. <fnstudio>nckx: what do you mean socket activation? is that meant as something that i should <nckx>userix: Is there a way we could add a comment to that self-righteous page to say ‘help & mirror operators welcome’? <char[m]>lfam: I see. Would It be okay to use it anyway? like would a bootstraping patch with that make be able to make it upstream? <nckx>Oh, Добавить запись, my bad. <lfam>char[m]: Again, it depends on the specifics. My advice is to get your packages working, and then deal with fine points like this later <userix>they say that any contact could be done through telegram-channel <nckx>fnstudio: That bit was not directly aimed at you, just occurred to me when I wrote that the daemon is used only during builds. The rest of the time it sits unused. Socket activation is something popularised by systemd, where the init system (remember those?) listens on a port or socket and only launches the associated service when something actually connects. <nckx>The Shepherd now supports a basic form of it AFAICT. <nckx>I haven't played with it yet. <yarl>What can I do against "Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS" error? <fnstudio>on a different note, i think i might have an idea on what's wrong with my os inheritance here https://bpa.st/TERQ - since base-operatin-system is not exported then guix doesn't know where super-operating-system should inherit from? <yarl>I tried `guix shell --with-input=guile=guile@3.0.8 artanis` <lfam>yarl: It means you ran out of memory. Either you don't have enough memory or some code has an infinite loop <nckx>userix: I'm oscillating between contacting them and not :) If they'd spent the effort they spent on that silly shame list on actually helping projects set up mirrors… <lfam>Motivation is not fungible! <nckx>I agree, but motivation to set up an ‘omg foo doesn't bother to bar!’ is a special case. <userix>nckx setting up mirrors is the other task. But you could wait before asking. Guix can gain some popularity on this :) <yarl>lfam: hmm. I got only 4G but added 16G of swap. I know I need something more powerful but 20G is not enough? :( <tewi>are you building on tmpfs? <lfam>Um that's way more than enough! <char[m]>I do have one more question about using libraries for bootstrapping. It seems that when I have a circular dependency graph (compiler file depending on libraries file which depends on the compiler), I get all sorts of strange unrelated errors. <userix>the list is actually very useful. It can save your data sometimes <nckx>I'm also a bit weary of inviting the wrong type of motivated person. I don't want Guix to be swamped by Z-heads thinking we in any way support *them*. <lfam>yarl: Since you have enough memory, I think there is an infinite loop in the code. Are you just using Guix, or are you doing some development? <nckx>4G should be more than enough to run all parts of Guix itself, assuming it's not all being eaten by IceCat. <lfam>char[m]: Yeah, the error messages will not be very clear in that case. You'll have to understand the dependency graph manually and figure out how to bootstrap it <char[m]>lfam: Am I correct in saying: circular dependencies are not allowed? <lfam>Often, that means creating a bootstrap path using old versions, with which you build new versions <lfam>Packages in Guix are modeled as a directed acyclic graph. "Acyclic" is the key word here <lfam>No cycles aka circular dependencies <char[m]>lfam: That makes sense. How then can the X library (build with any version of the compiler), be used to build the next X compiler since X library needs the x-build-system. <lfam>That is indeed the question <lfam>Like I said, you often have to create a bootstrap path using old versions, with which you build new versions <lfam>If that's not possible, then it gets even more interesting <lfam>Some language implementations have alternative and very simplistic compilers written in C with which you can begin the bootstrap <lfam>Or, you might even have to start with a binary of the compiler <lfam>It really depends on the specifics of the compiler / language you are trying to package <lfam>There are people here and in the #bootstrappable channel who are basically the global experts on this stuff <lfam>And the <guix-devel@gnu.org> is a good way to have more long-term conversations with those experts <char[m]>lfam: I'm not working with the start of the bootstrap process. I already have ghc@9.0.2. I'm trying to build ghc@9.2.3 which requires some random ghc-* library. <lfam>Let me guess... that random ghc-* library requires ghc@9.2.3? Or what's the problem? <f1refly>interestingly the setuid record seems to have worked, but now I get an error regarding something with swaylock on boot, but I don't see anything in /var/logs/debug <orneb>Hi! I still can't login as user <muradm>orneb: can't login as user meaning? <orneb>Sorry, I meant I can't login with the user I declared in my config file. I can only login as root. <muradm>orneb: is it first time you are installing? may be you forgot loging in with root without password and then setting both your user and root passwords? <two[m]>/home/user/.guix-profile/bin/bash not installed? <orneb>Yes it was the first time but I'm familiar with the command line and with Lisp being an Emacs user even if not a programmer. I set the root password with passwd root then passwd username. <muradm>orneb: two[m] could be right, try simpler shell <muradm>or keep default to see if it works that way <orneb>Do you mean I should declare the sh shell in my config file? <muradm>i didn't evan have (shell ..) in my config <muradm>thing you are writing /home/user/.guix-profile/bin/bash is kinda ephemereal <jpoiret>orneb: your shell should be (shell (file-append bash "/bin/bash")) <jpoiret>but i think the default is already that <orneb>I tried with the default removing this line (shell "/home/user/.guix-profile/bin/bash") but still can't login. <rekado_>FYI: the *Guix project* does *not* block access to its website based on the location of visitors. <muradm>i'm running guix environment guix --pure --ad-hoc .... -- make check-system TESTS="..." is there any way to set substitute-urls for whatever is runing in make? <jpoiret>just modifying config.scm is not enough, you need to `guix system reconfigure /path/to/your/config.scm` <orneb>Yes I run that command after modifying my config.scm. <jpoiret>can you check your /etc/passwd and see what shell you have there? <jpoiret>and see if that shell exists on your system <orneb>They do. I have these lines: /home/orneb:/gnu/store/xxxxxxxxxxxxxxxx-bash-5.1.8/bin/bash <orneb> /root:/gnu/store/xxxxxxxxxxxxxxxx-bash-5.1.8/bin/bash <orneb>then a bunch of lines with /var/empty:/gnu/store/xxxxxxxxx-shadow-4.9/sbin/nologin <char[m]>@lfam:libera.chat: The problem is that the library needs to use-module (guix build-system-haskell) (which needs haskell compiler in (gnu packages haskell)). Therefore the new compiler in (gnu packages haskell) cannot include the library. <nckx>rekado_: Funny, that would imply a level of administration we don't even have. (Also… was I not sufficiently clear about that? Sorry, then.) <nckx>We don't even have geoip data packaged AFAICT. <muradm>answering my question: make check-system calls ./pre-inst-env guix build .... which can be executed manually (not with make target) then --substitute-urls can be specified <jpoiret>orneb: very weird then, I have no idea <rekado_>nckx: I just wanted to clarify that it’s not *us* blocking anyone. (I haven’t read the whole backlog; just saw the website claiming that we block.) <nckx>Do you happen to know how long these blocks last, rekado_? I wasn't expecting it to take this long, but maybe the ‘activity’ is simply ongoing? <orneb>jpoiret: I'm not and I prefer not to have one to speed the boot process. At this point I think I messed something up with that line during the install process. I will try a new installation and let you know. <andrzejku>I was looking for the running services but herd status returns error: connect: /run/user/1000/shepherd/socket: No such file or directory <andrzejku>I am not sure but it looks like that I have no any service for auto mouting <char[m]>andrzejku: most herd commands need sudo <muradm>(string-append ((@ (guile) getenv) "out") "/fail2ban.log") <cbaines>muradm, I'm not sure the VM where the copy-file is running will have write access to the #$output of the test derivation <cbaines>you'll probably need to read the file via the marionette, and then write it in the test code <muradm>althouth it uses marionette-control, i could not figure out other commands than sendkey/screendump <cbaines>I'm not very familiar with this interface, but I think that marionette-control and marionette-eval do different things <cbaines>from reading the docstring, marionette-control runs QEMU commands outside the VM, so it probably has no trouble writing to the output <muradm>realized when wrote sendkey/screendump above, these are done from outside of vm <rekado_>nckx: no idea how long this will last. Nobody told me about it. I don’t even know if this is at the level of the DFN (providing network infrastructure for research institutes in Germany) or just the MDC. <unmatched-paren>but to use herd as user you have to launch user-shepherd first (just `shepherd` should do the trick) <unmatched-paren>without it, it'll operate on user services (like the guix home services) <muradm>there is open-pipe-with-stderr in (guix build utils) but it is not exported. is there a convinience procedure to execute command and return stdout+stderr out of the box ? <unmatched-paren>muradm: you could (@@ (guix build utils) open-pipe-with-stderr) i guess <muradm>just writing test cases, and need to run commands in vm and capture output <cbaines>unmatched-paren, note that modifying guix/build/utils.scm will affect pretty much every package, since that module is imported in most (all?) build systems <cbaines>so it may seem like a simple change, until everyone has to build everything from source <muradm>i don't remember how many times i wronte open-input-output-pipe dup2 dup2... and still there is no convinience method to run someting to string... <muradm>which section to put fail2ban documentation? <muradm>fail2ban-service-type added in (gnu services security) <muradm>networking, misc or start new "Security Services"?