IRC channel logs
2022-11-19.log
back to list of logs
<jonsger>rekado: uff, I feel the pain. And I guess there is no fwupd at the firmware update party :( <nckx>I don't think fwupd handles updates like that. <nckx>Isn't it more for consumer machines that need, like, their SSD firmware or whatever updated? (Actually, I've idly wondered how fwupd handles the actual upload/flash. Does it just run bundled vendor code on the host?) <rekado>fwupd has “plugins” for different targets <nckx>Yes, I've seen the Web UI, it is very enterprisey. <rekado>they could have just called it “Manage” <nckx>Oh good, it's open, that's good. <rekado>(I kinda miss the “2000” suffix in names) <rekado>no no no, it’s “OpenManage”, not “Open Manage” <rekado>“© 2017-2022 Dell Inc. or its subsidiaries. All Rights Reserved” <rekado>“A portion of the software below may consist of open source software, which you can use as per the terms and conditions of the specific license under which the open source software is distributed. For certain open source software license, you are also entitled to obtain the corresponding source files. You may find corresponding source files for this program at opensource.dell.com.” <nckx>I genuinely noticed that it says 2022. Not quite suprised, but it was 50-50. <nckx>How frequent are these updates on average? <rekado>I haven’t been following this much. <rekado>someone else took care of this in the past <nckx>I don't remember this affecting berlin before (which is not saying that much). <rekado>we didn’t apply disruptive firmware upgrades in the past. <rekado>the release notes often just mention Windows-related bug fixes <rekado>but if we want to keep them in service with Dell (and we do pay for that) we must have a certain baseline of firmware versions installed <rekado>so here we are swallowing this turd burger <lechner>sneek / later tell unmatched-paren: Hi, would you please remind me how I may fix the packaging of go-github-com-hebcal-hebcal-go here? I marked it as "source-only" but the build system for 'hebcal' still cannot find the submodules. Thanks! https://www.pastery.net/nzafyu/ <mekeor[m]>rekado: i dunno about "popular editors". it'd be nice if emacs had some sort of tree-like navigation for texinfo-mode, a nested imenu, somehow <lechner>sneek / later tell unmatched-paren: nvm, i did not specify all prerequisites, but for 'hebcal' the set of native-inputs is now larger than those in go.mod. do i need to propagate the native-inputs in go-github-com-hebcal-hebcal-go? Thanks! <elevenkb>I would love to learn enough about scheme macros to hack on guix. Any pointers? <elevenkb>I've read SICP and did most of the exercises. <apteryx>the best reference for macros that I know is from the author of the syntax-case macro system for scheme; The Scheme Programming Language (TSPL). <apteryx>wow, gtk+@2 is broken by updating mesa to 22.1.2 <lechner>apteryx / thanks for that book link! <Guest3744>Alright, I just copied the completely basic example "static netorking" example block from the user guide into my services list, and it fails with "error: static-networking: unbound variable" <Guest3744>I find it unlikely that static netwoking would be broken... <Guest3744>Anyone have any ideas before I make a bug report? <Guest37100>alright, I'm back but I forgot which number I was (so I'm the one that just left) <tricon>Guest37100: The Guest formerly known as Guest3744 <apteryx>Guest37100: it's from (gnu services base): static-networking <apteryx>but that should already be in scope when using guix system reconfigure <Guest3744>apteryx: I tried a few things (running as root instead of sudo, including (gnu services)), and no matter what, I needed to import (gnu services base) for me to add a static networking section <Guest3744>Maybe this is OK, but the documentation for static networking should mention (gnu services base) <Guest3744>(I'm still skeptical that this is a bug as I'm sure MANY people are using static networking right now) <podiki[m]>the service modules should all say they module at the top of the page at least <nckx>‘guix system search’ says (gnu services base). <apteryx>(gnu services networking) is already re-exporting static-networking-service(-type) for convenience; perhaps it should re-export more <nckx>apteryx: I'm not sure what the ‘rules’ (if any) are for re-exporting, but a service being totally reliant on a constructor from another module (static-networking) seem a logical yes to me. <nckx>apteryx: I'm not sure what convenience is being served here. <podiki[m]>yeah, from the manual page i would expect just (gnu services networking) to be needed, though maybe anyone not using base is assumed to know what they need specifically? <Guest3744>nckx: thanks, I should have thought of that. <podiki[m]>I don't know anything about exporting/inheritance etc here though, so my expectations are uninformed <nckx>‘guix system search static-networking’ says base, it's defined in base, re-exporting it from network is nice & all & saved someone a line once, but really, just document base instead, it's the canonical and actual location… no? <nckx>Unless there's some convention to re-export all base services from a more specific ‘category’ module (so base is an implementation detail or whatever), the manual claiming it's in network is the unexplained outlier. <podiki[m]>I find finding services in the manual by page (rather than searching say the full manual) to be surprising <nckx>What does ‘by page’ mean? <podiki[m]>right, looking at the list of service pages I would probably click networking, or at least have a note there referring to base <podiki[m]>I mean the manual html page sections, or I guess the info sections? <nckx>I'm not using HTML. I just have ‘Base Services’, ‘Networking Services’, ‘Mail Services’, … sections here. <nckx>I don't see how that affects searching though? <podiki[m]>maybe "info guix services" and going from there for instance <podiki[m]>(which is why I usually do a full text search for stuff especially in services) <nckx>That's how I find services: by typing / followed by static-networking-service <podiki[m]>yes, I usually search for text, but if you wanted to just browse and expect to find it on the page about networking services <podiki[m]>categorizing is hard, there's bound to be overlap anyway <nckx>OK, I finally understand what you meant. <nckx>‘I find finding services in the manual by page (rather than searching say the full manual) to be surprising’ → ‘If that *were* my habit, I would find it surprising if it were moved to base’? Do I get it right this time? 😛 <nckx>If not, I'm going to bed; seems fair. <podiki[m]>a cross reference would be handy, in fact for probably other things in "base" as that is ambiguous <nckx>Problem is, if we want regexp searchers to see the module without scrolling up at all, we have to add it to the blurb under each ‘Scheme variable’ section. For each service. I find that noise. Noise that must manually be kept in sync. Especially when ‘guix system search’ already exists, and queries the actual source of truth. <nckx>But I am clearly tired, and the little hand is somewhere between 4 and 5, and I think that means bed time. <nckx>Thank you for your patience, and good night! <apteryx>nckx: I haven't checked the problem carefully or why it's defined in base, but it seems using (gnu services networking) should be enough; (gnu services base) is 1. not documented 2. vague <Fare>Weird: I tried to install a pretty minimal system, and I see lots of java and ruby and tex packages being built, which takes forever. <Fare>there is nonguix for that kind of off topic, and lots of channels of other topics. <dirtcastle>(offtopic) I have a laptop. I want to ssh into it from my phone when I'm at University. I am not running any services that a internet facing service would run. I want to hack on guix through ssh. guix system config , home config , writing package and service definitions. (I have a way to expose ssh port to internet) my question is is it ok to keep my laptop running constantly for 8hrs? my laptop is heavy and I'm too lazy to carry. also last <dirtcastle>time ssd kind of came out of socket and my lap didn't detect it because my laptop shaked too much when i5 was traveling in public transport. <tricon>dirtcastle: i can't give a definitive answer, but i don't see a problem with leaving it running as a server. <AwesomeAdam54321>dirtcastle: The only main concern with the laptop is to make sure it doesn't overheat, including when charging <dirtcastle>AwesomeAdam54321: I heard that batteries don't overheat by charging these days because they are smart now and laptop cuts off connection from battery to power supply once charge is full. so battery heating won't be a problem right? <dirtcastle>I have a cooling pad. the fan on cooling pad don't work well but atleast the laptop is elevated and whenever I compile something the laptop fans start spinning. so the fans must be working well, ryt? <Fare>wow, I'm trying to install guix on a new computer, and it's currently recompiling gcc... isn't there a cache somewhere I should be using? <AwesomeAdam54321>Fare: Yes, there are usually substitutes available (they're like a cache in the sense that they substitute building it yourself) <ph03n1xaimverncc>Is there a way for me to prevent the xfce power manager backlight helper to not show the sudo prompt? <Fare>AwesomeAdam54321, how do I use substitutes? And why is guix building N versions of the openjdk when I'm not trying to install anything Java? <AwesomeAdam54321>Fare: Guix already has a default substitute server ci.guix.gnu.org, but bordeaux should also be included in the next release <Fare>How do I tell whether guix is currently using the server? <Fare>and/or how do I ensure it is in my channels.scm ? <AwesomeAdam54321>Fare: Guix is building openjdk because it's in a package's closure, so it's one of the dependencies somewhere in the chain <dirtcastle>is guix container good enough for using on servers? <AwesomeAdam54321>Fare: I'm not sure how to list all the substitute servers using guix, but the list of authorised keys are in /etc/guix/acl <sneek>Welcome back unmatched-paren, you have 3 messages! <sneek>unmatched-paren, lechner says: Hi, would you please remind me how I may fix the packaging of go-github-com-hebcal-hebcal-go here? I marked it as "source-only" but the build system for 'hebcal' still cannot find the submodules. Thanks! https://www.pastery.net/nzafyu/ <sneek>unmatched-paren, lechner says: nvm, i did not specify all prerequisites, but for 'hebcal' the set of native-inputs is now larger than those in go.mod. do i need to propagate the native-inputs in go-github-com-hebcal-hebcal-go? Thanks! <unmatched-paren>lechner: that only applies if it's a library though, for executables just put them in regular inputs <PotentialUser-30>scheme@(guix-user)> (package-arguments gst-plugins-base) gives now $5 = (#:phases #<gexp gnu/packages/gstreamer.scm:586:6 7f8c8184bc60>) <PotentialUser-30>But: scheme@(guix-user)> (member 'phases (package-arguments gst-plugins-base)) gives only $6 = #f <yewscion>PotentialUser-30: #:phases is a keyword, not an argument. You are testing if the symbol "phases" is a member of the list, when (#:phases #<gexp>) is a keyword-argument pair. <yewscion>unmatched-paren: beat me to it, haha, sorry for the echo. <PotentialUser-30>But i dont understand what exactly do i have to type in for this "keyword-ref" thing? <unmatched-paren>I *think* it's either (keyword-ref 'foo LIST) or (keyword-ref #:foo LIST) <bricewge>Are they other unannonced Guixers at Capitole du Libre this week-end? <bricewge>I know zimoun and rotpat should ne there <PotentialUser-30>I did: ,use (ice-9 optargs) (let-keywords args #t ((phases '())) gst-plugins-base) and got: In procedure symbol->string: Wrong type argument in position 1 (expecting symbol): #t <rekado>why use goops if all you want is match on a keyword? <unmatched-paren>PotentialUser-30: you need to replace args with (package-arguments gst-plugins-base) and gst-plugins-base with phases <rekado>you *can* use “member” with keywords <unmatched-paren>rekado: but how does that work? i thought ``member'' was for checking if something was in a list <yewscion>O/T: Does anyone know a way to force cuirass to do a new evaluation? My local instance has been stuck at 5b555d639d05f0df7b26da459c69680ba35921bd for ~48 hours at this point. <rekado>member returns the list at the point where the searched value is <PotentialUser-30>I did: ,use (ice-9 optargs) (let-keywords (package-arguments gst-plugins-base) #t ((phases '())) phases) i got: In procedure symbol->string: Wrong type argument in position 1 (expecting symbol): (package-arguments gst-plugins-base) <unmatched-paren>PotentialUser-30: hm. maybe bind (define args (package-arguments ...)) and try with that? <unmatched-paren>just define (package-arguments ...) as args, and use that variable in the let-keywords <rekado>(let-keywords (package-arguments gst-plugins-base) #t ((phases '())) phases) <PotentialUser-30>This produces: $7 = #<gexp gnu/packages/gstreamer.scm:586:6 7f8c80346f60> <PotentialUser-30>This gives: <unknown-location>: warning: possibly unbound variable `phases' . Or should i replaces 2 times the "phases" in your command above? <rekado>use ,pp before your expression to pretty print the result <PotentialUser-30>Thank you. With ,pp it looks much better. No it does, what i want, BUT: Does it really has to be so complicated?? (let-keywords (package-arguments gst-plugins-base) #t ((phases '())) phases) <rekado>e.g. (and=> (member #:phases (package-arguments gst-plugins-base)) cadr) <PotentialUser-30>Fine! and= works. With memq i got: warning: possibly unbound variable `memq=> <unmatched-paren>the difference, i think, is that member compares using the slower equal? rather than eq? <rekado>with keywords you can just use eq?. <rekado>and=> returns #false if the first argument is #false; otherwise it passes the result to the procedure in the second argument <PotentialUser-30>Aaah. Works also. Sorry for my incompetence. I'm completely new to scheme ... Is there a chance to learn this "from zero" if one is not a student? <rekado>with srfi-1 you can replace the ugly cadr (equivalent to (compose car cdr)) with “second” <rekado>PotentialUser-30: the scheme tutorial in the cookbook is a good way to start <PotentialUser-30>Thank you for all your INPUT. I think i have to "digest" all this a little bit. There's much to read... <PotentialUser-30>I already scrolled a lot in the guix reference and the guile reference and of course the cookbook. I think it takes some time to understand what they are talking about there :-) <kitty1>PotentialUser-30: the scheme primer is amazing and I highly reccomend it to anyone interested in guile! really hope they make some more of those! I think cwebber was largely responsible for that one? <pkill9>what we need is a tool that takes a guix system configuration and formats and partitions the hard drive according to the system configuration <f1refly>how does interacting with bluetooth devices work on guix? I have started and enabled the bluetooth herd service and added my user to the 'lp' group, but when I run 'bluetoothctl list' it returns nothing, so no adapters where found <f1refly>running lsusb gives me the line 'Bus 003 Device 003: ID 8087:0032 Intel Corp. AX210 Bluetooth', so the device is recognized by the system. <f1refly>rfkill tells me the device is unblocked. <f1refly>My system is sway on wayland if that matters <nckx>Most Bluetooth hardware doesn't support Guix. <nckx>No, your windowing system doesn't matter :) <pkill9>AwesomeAdam54321: well the entire feature <nckx>AwesomeAdam54321: If it doesn't, throw it away. <nckx>They used to have a little ball you could take out & play with but they stopped providing that so they are now worthless when they beak. <nckx>pkill9: I agree (I've always seen it as part of ‘guix deploy’, but maybe that's not the right place either). The problem is that storage is inherently stateful and will contain valuable data, while the ‘guix system init’/‘guix deploy’ promise is ‘this is the system you will get, no weird exceptions’. Applying the new partition layout fields only on first init is not acceptable IMO. What to do? <nckx>So I've punted to ‘eh, let someone write an external tool not bound by such promises’. <pkill9>it could just be a guix subcommand? <pkill9>guix system format, or something <nckx>That ‘just’ is hiding a lot of work. I didn't mean the name of the command. <nckx>Since that data isn't part of the operating-system, what you end up with is ‘sfdisk but it's in Guile and reads a sexp’. Which, eh. <nckx>That's why I associated it with ‘guix deploy’, because it does (at least nominally, it doesn't do much with it) have the notion of machines. <nckx>Is berlin safe to reconfigure? <mekeor[m]>pkill9: sounds good! shouldnt be too hard to implement, no? <mekeor[m]>"guix system format system.scm" would then lead to "The disks already formatted and partitioned in exactly that way. Do you really want to reformat?" or "The disks are already formatted and partitioned in this way: .... Do you really want to overwrite it?" <mekeor[m]>maybe "format" is not the perfect wording because it would include (1) mbr vs gpt (or bios vs efi?), (2) partitioning, and (3) file system formats <yarl>Is Nicolas Goaziou here? <unmatched-paren>yarl: i don't think they are right now (pretty sure their username is ngz) <yarl>(Or) Is someone experienced with packaging texlive packages? <yarl>unmatched-paren: ok, thank you. <yarl>But it seems to me that because (list "doc/generic/mathdots/" "source/generic/mathdots/" "tex/generic/mathdots/") are imported, then it is a trivial package. If I build it, "mathdots.sty" "and mathdots.tex" are there because they are present on tug.org repo. <yarl>Also, when he says "The first sentence should contain a subject". This means "mathdots" must appear, right? <yarl>That's actually the first time I package. And I used guix import texlive. I had to amend the package definition by reading other texlive package definitions. <nckx>yarl: What they mean by ‘a subject’ is actually ‘must be a valid sentence. ‘Redefines blah’ isn't. <nckx>Popular subjects are ‘This [TeX] package redefines…’, and indeed just ‘Mathdots redefines…’. <zamfofex>civodul: I noticed you applied my changes adding wld to Guix, but you closed the issue for adding velox while at it. Is there any reason for that? (Note that velox was what I was actually hoping to be able to use! I just made a mistake while sending the emails.) <nckx>zamfofex: Merged bugs are the same bug from that point on. This isn't always exposed (clearly) in every single interface, though. I'm confident guessing that Ludo didn't notice, and it was an accident. <nckx>sneek: later tell mothacehe: I've added the public key on berlin. <nckx>I assume the 2 other patches are unapplied as well, but didn't check. <PotentialUser-30>Hi, i did a gst-plugins-good variation with qt (needed for nheko with video) It compiles. Could you guys please have a quick look over the scm file for obvious mistakes / deficiencies (I'm a noob) Here is the link: http://dpaste.com/5L566NSMP <nckx>zamfofex: You can reopen them, by sending, I believe a mail to NNN-reopen@debbugs.gnu.org. In that mail you can add a human-readable explanation of which patches still need to be handled. <nckx>PotentialUser-30: For a self-declared ‘noob’, that looks great, no? You can probably access the common phases with (@@ (gnu packages gstreamer) %common-gstreamer-phases), so you don't need your own copy. Also (add-after 'unpack 'foo should conventionally be a single line, and you don't need two phases here. You don't even need 2 substitute* calls: you can use (substitute* FILE ((REGEX1) REPLACEMENT1) ((REGEX2) REPLACEMENT2) …). <nckx>But what matters most: does it work? <nckx>Oh, the two phases also have the same name. <PotentialUser-30>Work? Its only a "library". For real testing i need to create an adapted version of nheko which pulls this special library. I'll do that as next step. <nckx>That's what I meant by work. <nckx>zamfofex: To be clear, I mean ‘which patches’ by *name* (subject/package), not bug number. <PotentialUser-30>Dont know if i really understand your comments. Most of the thinks i "copied" from guix edit gstreamer. But anyway it took me a very long time to do it right. <PotentialUser-30>nckx: The (@@ (gnu packages gstreamer) %common-gstreamer-phases) substitutes which "segment" ?? <nckx>Oh, \[ is also suspect. Should be \\[, no? <nckx>It substitutes %common-gstreamer-phases. That's the variable name. #$@ is a separate ‘operation’ on it, and should remain. <nckx>PotentialUser-30: ‘guix build’ does not ‘install’ packages. You can reclaim the used disc space of the /gnu/store/xxx directory (last line of ‘guix build’ output) with ‘guix gc -D’, but don't bother with that now unless you sorely need the space. <PotentialUser-30>nckx: the \[ its the same as with flvmux wich i copied from gstreamer.scm <nckx>Did the pastebin bork this up? <nckx><Did the pastebin bork this up?> Which is plausible, by the way, because trying to build \[ *should* give you an ‘invalid character in escape sequence’ error. And yet it built. <PotentialUser-30>Interesting! The pastebin changes the file !! Original its (("\\[ 'elements/flvmux' \\]") and (("\\[ 'elements/souphttpsrc'.*\\]") <nckx>I don't own stock in paste.debian.net, but it doesn't do that :) <PotentialUser-30>Regarding /gnu/store/xxx there is no need for removal? No "corruption" in the packages possible i guess? <PotentialUser-30>nckx: Your downloaded pastebin looks good. Perhaps it's only the display ?? <nckx>PotentialUser-30: <corruption> Not one bit! Any change to your package definition will cause the hash (the part before ‘-gstreamer’) to change. The old build is never touched again. <nckx>So old builds will always end up in a new directory, and use a bit of space (but duplicate files are stored only once), but can do no harm. <nckx>We can discuss ‘guix gc’ later if (1) you want to and (2) it's needed, but it's just a distraction now. <nckx>Good luck with nheko-qt, I'm going AFK for a while o/ <nckx>Er, s/old builds will/new builds will/ above. Anyway. Bye! <gnucode>unmatched-paren: you must be on the other side of the pond. :) <civodul>shepherd.scm and pack.scm don't really count <civodul>though yeah, we can also get rid of the one in pack.sm <PotentialUser-91>Hi, I'm having issues with cursor size on a foreign distro. At first, I was only having issues with my cursor size in emacs, which wasn't that big of a deal. However, after transitioning from using a manifest file to using guix home, my mouse cursor has appeared to have gotten extremely smaller on my entire OS now. I've tried doing some research <PotentialUser-91>online, but nothing seems to be working (I've tried adding xsetroot -cursor_name left_ptr to my xinitrc + changing my cursor path per the stack overflow thread linked below). The last thing I tired to do was put my xinitrc and Xsessions file into guix home's files directly to see if that would work, but it doesn't seem to be doing anything. Mainly <PotentialUser-91>I just need to see how to modify the cursor size so it's respected while guix home is in use. My configuration.scm is in the pastebin below, in case that helps in any way. <apteryx>PotentialUser-91: I don't modify the cursor size myself, but I use an X theme for it (hackneyed) <apteryx>I have "Xcursor.theme: Hackneyed" and "XCursor.theme: whiteglass" in my ~/.Xresources <reyman>i'm looking for php >= 8.1, seems there is only php 7.4.3 <matta>Anyone have a working minimal guix home .scm that works for a foreign distro using Gnome? In Debian a user that has "guix home'd" consistently fails to log in. Something gets borked and gnome session dies at login. <matta>One thing I've noticed: Guix home fails to set up GUIX_LOCPATH, so when I log in at a terminal guile prints "unable to install locale". <matta>This is the guile run that runs from .bash_profile -> .profile -> $HOME_ENVIRONMENT/on-first-login. <matta>There doesn't seem to be a way to configure guix home's home-bash-configuration to tweak what happens before ~/.profile is sourced. <apteryx>rekado, nckx, civodul: I'm taking berlin down to make the 2 HDDs attached to the PERC controller available. <nckx>I just saw the mail. All going as planned? <apteryx>yes; but I realized that was not needed. a RAID1 of two HDD is just dandy for the boot device <apteryx>at least seeing the menus made things a bit clearer <apteryx>I'll jolt something down the handbook <apteryx>I'll partition it, reconfigure, reboot and the 8 large SSDs should then be all free <gabber>hi! is issues.guix.gnu.org reachable for you? <apteryx>gabber: Hi! some maintenance is undergoing. <nckx>apteryx: Thanks for taking care of it. <nckx>And this requires bringing down the machines? <apteryx>yes, these menus are only accessible from the BIOS-like setup screens <zamfofex>Ah, I keep forgetting to say this, but since now it actually came to bite me, I wanted to report that the caching of ‘guix shell’ seems to ignore the argument passing in to ‘-f’. <apteryx>good to know: 2022-11-19 15:00:31 35074 guix gc -F 150G: completed in 30.585s on node 129 <zamfofex>Also, on a different news, in case anyone finds interest in it, I decided to keep working on my npm endeavors, and I was able to create a Guix package for sucrase! (Note that sucrase depends on … sucrase. So I had to bootstrap it using esbuild.) In the end, it seems to work for bootstrapping itself, and the bootstrapped one seems to work correctly too! <apteryx>I hope your work finds its way into guix proper :-) <nckx>apteryx: Belated 'I see' 🙂. Strangely unenterprisey. <rekado>it is an unusual crack in the enterprise veneer <apteryx>now if only offloading /gnu/store/pib5z24rmcq0kzcyc91z7xpgljvc89m9-guix-config.drv to '141.80.167.187' didn't take forever... <nckx>zamfofex: Could (or did) you report this on the bug tracker? Sometimes things get lost here. <rekado>apteryx: sorry I didn’t see this earlier; I would have retried the PERC firmware update. <apteryx>rekado: I'll still have to reboot post reconfiguration <nckx>zamfofex: Or, if you plan on fixing it yourself, never mind of course. <zamfofex>I can report it, I suppose! (Though note that I usually postpone things a lot, so maybe it might take a few weeks or months.) <apteryx>rekado: when I rebooted earlier I faced again weird kernel traces related to the fiber adapters <apteryx>after a complete shutdown, waiting a bit, and rebooting it proceeded normally <apteryx>I feel multipath shouldn't be *necessary* to avoid these, right? <podiki[m]>zamfofex: I believe I've noticed that too, not sure how consistently. there's the --rebuild-cache option at least <rekado>apteryx: PERC firmware has been applied with your last reboot <apteryx>hmm, waiting on '141.80.167.187', but it's idling at 0 load <apteryx>I guess I'll retry my offloaded 'guix pull' <rekado>but: multipath should allow us to keep using the SAN even in the face of a failing controller <rekado>it would error out and be disabled <rekado>apteryx: that’s node 130, which has been acting strange in the past <rekado>lots of segfaults in the logs of 130 <rekado>I think there was an open case with Dell <rekado>will have to ask Madalin about this <rekado>something wrong with the disk controller <rekado>it’s a surprise we managed to install the system at all <rekado>don’t know what the hold up is here <rekado>it’s been like this for quite some time, and Dell wanted us to run some diagnostics and replace some hardware <rekado>guess nothing has happened since then <apteryx>I've removed it from our version machines-for-berlin.scm <apteryx>it's interesting that in case of a crash on the remote, "offload" just hangs <apteryx>rekado: I'm ready to reboot berlin again <apteryx>oh wait, before I reconfigure I need to shadow /boot/{efi,boot} with the new file systems, right? <apteryx>OK, reconfigured again with new /boot and /boot/efi mounted <apteryx>I changed the boot device on the PERC card in case that matters <apteryx>ACTION goes through the exits prompts N times, because? <omlet[m]>in 2019/2020 declared war on the leader of the movement and led an uprising to take control over the gnu <apteryx>rekado: success! the 6x 8TiB SSDs will be ready to be moved to node 129, at your leisure <zamfofex>apteryx: Sorry to bring it up again, but I suppose you were busy when I asked last time: What do you think I ought to do to continue my efforts towards bringing more npm packages to Guix? Is there any interest in that? <zamfofex>Also: Does my sucrase package serve as some kind of indication that my approach of “just don’t recurse into devDependencies” is worthwhile investigating? That was my hope, but I feel like sucrase just doesn’t have many dependencies, so maybe it’s just not a big enough sample size. If anyone has a different package in mind that I could use to try out, feel free to let me know. <nckx>rekado: Does node 130 have any special functions or was it just a build node? (I assumed the latter, but 129 is a bit of an odd number, pun intended. Was 130 already flakey when it was chosen?) <mfg>Hi, i'm having trouble running `guix shell -C' on a foreign distro. I get: guix shell: error: mount: mount "/home/mfg" on "/tmp/guix-directory.aI74Jj//home/mfg": Invalid argument <nckx>oriansj: But you can fit 18 one-gigabyte rescue initrds on it. ☹ <nckx>Oh no. This isn't some new bug spreading, is it…? <oriansj>nckx: you don't need those in /boot; those belong in /srv/emergency/${specification} <nckx>oriansj: Where /srv is an NFS mount, of course. <nckx>Otherwise our Enterprise contract will be revoked. <nckx>mfg: I suspect the kernel now. Same question: does your distro use SELinux or other hardening options? <nckx>*I* like sshfs, so probably not, if patterns are a thing. <oriansj>nckx: i'm surprised they are not evil enough to demand cifs <mfg>nckx: nope it doesn't use selinux. <mfg>ah let me read the mail you linked to <nckx>Meh, it's mainly me barking up a wrong tree. <nckx>I don't think the distro is explicitly mentioned. I'll add that question. <oriansj>or dumbly evil enough to demand tftp <mfg>Hm, i use zfs as the main filesystem here and /home/mfg is actually a zfs dataset. You can't just mount zfs datasets. That could be the problem here. <cbaines>we really need a better way to see what's going on in real time <mfg>nckx: yep pretty sure it's because of zfs. <mfg>Hm reading guix/scripts/environment.scm it seems the used filesystem shouldn't matter as everything is supposed to be bind-mounted anyway or am i misunderstanding this? <FareTower>OK, so I have a "fixup" script to properly boot grub on crypt+lvm. How do I insert it in the installation pipeline? <nckx>mfg: Sigh, the user in that mail thread uses Guix System. I'm really out of ideas. <FareTower>Is this the right place to discuss Guix issues? <oriansj>FareTower: if you think it might be quick here is generally able to cover many quick and the mailing list tends to be much more in depth discussion (ideally) <nckx>I was hoping for Red Hat style SELinux-all-the-things, or at least a Debian-style kernel patched with some paranoid default sys.kernel.bind.mounting.scares.me = 1 we could disable. <mfg>nckx: on guix system it works perfectly for me :D <FareTower>oriansj, I fear my questions might be in between the two... I'll take my chances... <apteryx>zamfofex: of course there is interest! the question gets asked often <apteryx>as to what I think you ought to do, perhaps share what you've done so far on guix-devel, with a recap of what you think would need to be done before this work is acceptable to be merged in guix proper <rekados-thumb>nckx I've seen this on systems with "unusual" mounts, e.g. home on a remote zfs or nfs <oriansj>FareTower: when it doubt, ask here and if you don't get a good answer you can always send to the mailing list <apteryx>nckx: re 18 GiB /boot, it's sitting on a 1 TB RAID array that'll probably never get used, so why not ;-) <FareTower>Also, ungoogled-chromium seems to have issues accessing the yubikey, which was working "well" under NixOS (i.e. was outputting a nonce string as a keyboard event, which is suboptimal but works) <apteryx>we can accumulate 5 years of guix system generations without giving it a thought <FareTower>do I need to add permissions or configure something to get the yubikey running? it actually looks like it's working as a keyboard device too, but Google rejects me immediately when trying to use it <podiki[m]>FareTower: on guix system? you probably need the pcsc service and libfido2 udev rules in your system configuration <nckx>FareTower: Put differently: there is no wrong place; there is no risk. Only 2 styles of discourse, each better suited so some problems than others. Post wherever you feel most comfortable. If needed, migrate. <nckx>I meant it as an example of something we could blame for a bug, not as a suggestion :) <mfg>nckx: also: even though it seems guix should be bind mounting things i can't see any actual mount calls with strace. Neither on the system where it doesn't work nor on the system where it does <nckx>Feel free to SELinux all the things. <nckx>apteryx: Actually, the only reason I checked was your e-mail mentioning ‘…/boot is now on a 1 TB RAID array…’ and thinking ‘surely he doesn't mean… no, that can't…’. You didn't, and it wasn't, but indeed, no fear of running out of generations any time soon. <nckx>rekados-thumb: I can reproduce *a* (I'm no longer convinced it's the same bug) EINVAL when mounting nested mounts, e.g., /proc/sys/fs/binfmt_misc blocks --expose=/proc until unmounted. <nckx>What seems to have become clear is that there is no lack of ways to make Guix containers throw EINVAL with --expose=. So many ways. <nckx>That's almost more interesting, if not quite worrying. <nckx>I'm guessing things like Docker don't share most of them. <mfg>the dir that gets appended to shell-authorized-dirs is the cwd <mfg>nckx: as you also suspected the kernel, the kernel version on the system where it doesn't work is 5.15.77 and it works on Guix System with 6.0.x (whatever is the most recent) <nckx>I'm not sure my suspicions mean anything anymore, I'm so out of ideas I might be seeing ghosts. <nckx>rekados-thumb: (Why not use both thumbs at least?) I think I missed a detail: what's a ‘remote zfs’ file system? <rekado>nckx: oh, I don’t know. We’re using zfs appliances and they’re mounted strangely in ways that I keep remembering just as “strange’. <rekado>(I can only use my righht thumb when my kid only falls asleep while lying awkwardly on my left arm…) <rekado>I just got this: guix shell -C --expose=/=/elsewhere coreutils hello <rekado>guix shell: error: mount: mount "/" on "/tmp/guix-directory.yBdmZz//elsewhere": Invalid argument <rekado>I haven’t been able to reproduce any other errors that I was sure I could trigger by involving other mounted file system. <rekado>guix shell -C --expose=/data=/elsewhere coreutils hello <rekado>guix shell: error: mount: mount "/data" on "/tmp/guix-directory.SxiNxB//elsewhere": Invalid argument <rekado>mount says: /etc/auto.data on /data type autofs (rw,relatime,fd=12,pgrp=35974,timeout=120,minproto=5,maxproto=5,indirect,pipe_ino=18354773) <nckx>The reporter used ‘guix shell -C --expose=$HOME=/elsewhere coreutils’ and got -EINVAL. <nckx>And says it's on /, not mounted at any point. <nckx>You peeps all have these fancy set-ups. <rekado>wasn’t there something about FUSE? <nckx>rekado: I mentioned FUSE… did they? Not IIRC. <nckx>Does that $HOME example at least work for you? <rekado>I tested all the other autofs things; /data is the only one that has ‘indirect’, and the only one of the autofs mounts that triggers the error <rekado>yes, the $HOME thing works for me <nckx>OK, that's my baseline for sanity (mainly because it works on my Guix System too :) and it's what breaks for the reporter. So, as tempting as it is to dive into indirect autofs (not sarcastic), their problem is not that exotic. <rekado>I have been able to get EINVAL for more locations on a cluster node <rekado>all directories that are mounted from a mapped device like /dev/mapper/vg_max007-lv_var trigger the error <nckx>Is anything mounted further*under* those directories? <rekado>on my Guix System, for example, I can’t expose /, and /gnu/store is mounted there. <rekado>on the cluster node, I can’t expose /var, and /var/guix/profiles is mounted on it. <nckx>Hm, good point. My example (in the mail) was proc: there's one submount, binfmt_misc, and unmounting & re-mounting that reliably {un,}breaks Guix. <nckx>So that is a big hint I think. <nckx>That unmounting the submount fixes it? <rekado>while mounted I can’t expose /mnt <rekado>I haven’t tried unmounting anything on the servers at work :) <nckx>And thanks for pointing out that / is just a special case of this, that is obvious in retrospect. <rekado>civodul: I’m using a more recent Guix <rekado>ACTION looks at gnu/build/file-systems.scm <nckx>ACTION is also winding down for the night, after noticing they can't think good. Maybe a walk to the woodshed will wake me up, else it's for tomorrow. <rekado>ACTION looks for something like rbind <civodul>does "unshare -U -m --map-user=0 mount --bind /data /elsewhere" work? <civodul>if so, how does it differ (in strace) from what we're doing? <rekado>with this patch I can do ‘./pre-inst-env guix shell -C --expose=/=/elsewhere coreutils’ on Guix System <rekado>this is the equivalent of ‘mount --rbind’ <podiki[m]>is this related to say trying to share /dev as a whole in a container? I assumed that was when flags like -N share something already in there though 