IRC channel logs
2022-11-26.log
back to list of logs
<stevenroose>How do I make sure slock is called when waking up from (or right before going into) suspend or hibernation? In Arch I used a systemd service for that.. <nckx>stevenroose: How do you hibernate/suspend? <nckx>I wanted to fix /etc/elogind/system-sleep on Guix System but it's completely broken in elogind; literally commented out. <nckx>Yes, you're not the first person I hear using loginctl for that. <nckx>I always suggest not using a third-party front-end, but just writing your own ‘suspend’/‘hibernate’ script and doing the needful there. <stevenroose>nckx: But is there a "better way"? Like catting things into /sys doesn't seem more idiomatic <stevenroose>I guess because that's what elogind is for? To not require people to know how they should do that haha <nckx>I think the only thing that loginctl adds is some d-bus announcements, but shoot me not dead. I don't use the desktoppy stuff much. <nckx>stevenroose: I don't understand the logic, but OK :) <stevenroose>So let's say I have my own script, would I call slock& right before the rest of the script then? <nckx>You'd lock the screen, then suspend. <nckx>Whether that's to RAM or to disc shouldn't matter. <jackhill>I think I agree, at least in part, iwth stevenroose. The dbus adn loginctl interfaces are useful abstractions for destkop-environment builders. The distros can worry about distro-specific stuff, and put it behind that interface. Maybe with guix home this is less of an issue for us. <nckx>Again, I don't use or care about the stuff desktop builders build… But sure. <jackhill>sure, one may not need all the loginctl features for any one case, but I'd rather use that than building my own hacky, less well tested partial solution. If guix provided a more guixy way to do that, then it could be surperior to both. <nckx>(The obvious counterpoint is ‘if you use a desktop, it will provide a hibernate button, you won't invoke loginctl in a terminal’). <nckx>jackhill: And these features are broken in Guix, or I would suggest them. <jackhill>heh, yeah, we can't use them if they don't work! <nckx>We are masochists, not fools. <jackhill>I'd really like to get the gnome screen locker working from non-gnome sessions, to support user switching in the house when I get up from my computer <jackhill>but I don't yet know how it's supposed to work, so… <nckx>So yes, the ‘correct’ answer is ‘please fix elogind and we'll all benefit’, but that won't help anyone hibernate today ☹ And actively undoing upstream's ifdefs sounds like a recipe for pain. The fact that upstream is ifdeffing out entire blocks of code ‘because too hard to convert’ is already worrying. <jackhill>indeed. For my hibernation needs, which I mostly use on my laptop, I don't worry about the screen locker and just treat the full disk encryption password as the lock <twopubsolar[m]><nckx> "Why not?" <- i think catting into /sys doesn't lock the screen? <jackhill>althoguh I might be overselling, I don't think I've tried it recently <nckx>twopubsolar[m]: Correct. Neither does elogind. <nckx>jackhill: I'm just glad someone has a confirmed working Guix + LUKS + hibernation set-up. Or had :) <jackhill>Yep, it has worked for me. I just tend to do it when leaving home with my laptop, which I just don't do that much any more <stevenroose>It seems that slock takes a command as argument that is to be run when the screen is locked (their manpage example showing s2ram), but it doesn't seem to work for `loginctl suspend`, neither using loginctl's full binary path. <nckx>jackhill: 👍 (I remember merging your patch, but I either forgot to ask whether it reliably worked for you, or I forgot the answer…) <jackhill>works and no data eaten yet! Not only that, I also nest LVM in LUKS and that works too! <nckx>stevenroose: Pure guess, but could it be that slock is (1) setuid, most X11 lockers are (2) runs loginctl as root (3) this messes with, say, polkit's weird view of the world where everything's a desktop machine with seats & other nonsense, and refuses to run? It's a bit of a stretch, but one that fits my prejud^Wexperience with freedesktop products. <nckx>jackhill: I'm genuinely impressed. <nckx>jackhill: Not really related to this, but what does your resume= look like? <jackhill>huh, looks like I've been using it with zswap enabled too. <nckx>Now that I do as well :) <jackhill>I'm just careful to reboot anytime I reconfigure just so I don't accidentaly try to reume with a different kernel. I don't know what protections linux has build in, and I'd rather not find out <nckx>I can't get slock to do anything but spit out ‘slock: unable to disable OOM killer. Make sure to suid or sgid slock.’. <nckx>jackhill: The kernel itself is much, much more strict & paranoid about that than it needs to be. <nckx>So it will eagerly refuse to resume, but that does mean your image will be invalidated and you'll lose unsaved data, as if there'd been a power cut. <nckx>It's not good, and avoid it, but don't fear that your entire RAM will be randomised or whatever if you resume with the wrong kernel :) <nckx>I… I might have disabled that check in my own kernel (◍•ᴗ•◍) <nckx>…yep. I have. But my hibernation header format is incompatible with Linux's anyway, and I obviously choose when it changes. <stevenroose>nckx: there's some modern alternative to slock that supports both X and wayland, might check that out <stevenroose>Oh something else I've been wondering about for a many years. Is there a way to make Linux automatically mount external drives when they are plugged in? Like, any device I configure in the filesystems option I configure will cause trouble if it's not present at boot. <stevenroose>IIRC fstab has some way to do it, but I've never understood how <stevenroose>I've never bothered because systems have always been more or less ephemeral for me, but now that I'm on Guix, I'd like to setup a more long-term system, so it seems worth it <nckx>Guix has a (mount? #f) file-system field that will add it to fstab (so you can manually ‘mount /my/mount/point’ later). But if you mean ‘mount as soon as I plug it in’: I think udisks does this (see Desktop Services) but have no experience with it. There's also the old-school autofs, which at least one Guixer successfully uses, but is a bit more elaborate to set up. <nckx>There might well be other/better options I'm unaware of. <rothari>Hi guys. For some reason I keep getting this error: "error: unsupported manifest format" every time I run guix package. I also noticed that ~/.guix_profile/manifest is empty. How can I fix this? I am really stuck because anything involving running guix package does not work. <rothari>Hi guys. For some reason I keep getting this error: "error: unsupported manifest format" every time I run guix package. I also noticed that ~/.guix_profile/manifest is empty. How can I fix this? I am really stuck because everything involving running guix package does not work. <kaelyn>nckx: I can add comments for both configure options. And were you building for i686-linux (I was building from an x86_64 machine, if that affects things)? <podiki[m]>rothari: can you do a roll-back? or else can try to manually change ~/.guix-profile link to another generation <nckx>kaelyn: Yes, x86_64 → i686. <podiki[m]>(not sure if that is the best way, but all it is is a link to a profile in /var/guix/profiles/per-user/username/) <kaelyn>nckx: obvious question: did you have both patches applied (the two configure flags and the extra zip file extension)? <nckx>Two patches in total, right? <nckx>Thanks for reminding me that it had finished building, though. I don't get the same hash as you did. I'll test, at least, whether it's reproducible here. <kaelyn>you're welcome, and thank you for checking if it is at least reproducible for you <nckx>That'll be for tomorrow. 3:06, time for 😴💤 <kaelyn>No worries. I'm also going to try the build on another system to see what I get <lechner>Hi, is it possible that auto-discovery of nearby 'guix publish' hosts depends on dbus, via avahi-service-type? <mirai>does 'Maxim Cournoyer' use this channel? <rothari>podiki[m]: turns out I just had to go back one generation, thank you <robin>lechner, i think "Screen lockers are a pretty useful thing and these are small" is an adequate reason, but see the screen-locker-service entry at the end of (info "(guix) X Window") <robin>...it goes in the system configuration because screenlockers need extra PAM configuration and some (all?) need the setuid flag <robin>(not sure how DE screenlockers like gnome-screensaver usually work, i'd guess they're integrated with display managers or use elogind or something along those lines) <xd1le>anyone know how to get the emacs package to bundle the source too? So that we can navigate to the C source files from emacs help. <robin>mirai, iianm maxim's irc nick is apteryx <robin>xd1le, idk if there's a particularly convenient way of doing it, but if you have a local copy of the source code (from git or "guix build -S") you can then set find-function-C-source-directory to $emacs_checkout/src <xd1le>robin, thanks, yes I know, I just want guix to automatically set this up as part of the build. <xd1le>especially convenient in a container <robin>xd1le, would definitely be nice to have as an option <robin>maybe doable using package/inherit, copying the emacs src directory somewhere, and setting the c source dir variable in lisp/site-{load,init}.el or default.el or wherever things like that go <robin>(extra points for using guile-elisp to serialize that setq ;)) <robin>xd1le, i'll ping you if i implement it before you or someone else does :) <xd1le>robin, haha thanks, yeah I was trying to figure out how nix does it actually. They copy the source code but I'm not sure how they end up setting find-function-C-source-directory <xd1le>at least that's what I was trying to figure out <xd1le>it's not terribly important for me though, just a would be nice to have. I'll probably just put it on my backlog and then maybe end up implementing some other day <podiki[m]>rothari: glad it worked! good ol guix features :) <robin>xd1le, interesting; i don't see how that would help (beyond having the source installed somewhere), but then i don't really know how find-function works either, maybe there's some etags-related magic <xd1le>robin, yeah I don't know either but when I used to use nix it worked, it could see the C sources from help <itd>Oh, that looks like the Guix manual. <PotentialUser-30>Send a third patch to the system? Send those two patches again (the first modified?) <unmatched-paren>roptat: hello! would you consider vouching for me for commit access? :) (I did send you an email to ask, but I recently realised I forgot to add a subject line, so you may have missed it.) <roptat>unmatched-paren, oh I did read it, but forgot about it, sorry :/ <roptat>unmatched-paren, actually it's hard for me to find your emails, can you send it again? <unmatched-paren>roptat: the email was basically just "could you please send a vouch email to the guix maintainers" <yarl>I am learning about system services. I have a couple of questions regarding it. If I understand correctly, you have the possibility to create at activation (during system reconfigure) files anywhere on the system (outside the store), by extending 'activation-service-type'. Right? Is there such thing as "deactivation"? I guess no because the way I think guix works is that it is supposed to be pure, it does not take s <yarl>tate (or past invocations) into account. But there, on system services, because you can work on the filesystem outside the store, I guess it is just "non destructive". Right?. <roptat>activation procedures can be destructive <yarl>roptat: yeah right, sure. Let me rephrase then. <roptat>it's the little bit of impurity we need in order to make "procedural" services work <roptat>and no, there's no deactivation, so files might stay around <yarl>roptat: Ok yes, thank you, that's what I thought. <lilyp>jgart[m]: could you please configure your editor so as to not drop the leading indentation of descriptions? <unmatched-paren>alright, i've sent a commit access request to guix-maintainers@gnu.org :) thanks to the three people who agreed to vouch! :) <jgart[m]>lilyp: you mean description fields in the packages? <jgart[m]>I'm not entirely sure if I understand what lilyp is referring to <jgart[m]>unmatched-paren: Do you have a patch I sent where I did that <unmatched-paren>jgart[m]: sometimes when you add a package the description field looks like this: <mirai>automatically corrects it (mostly) <civodul>jgart[m]: it handles everything! sometimes suboptimally, but at least you can blame it <mirai>if you try and force it you'll get some nasty results <civodul>jgart[m]: that is, you have to use "guix style -f gnu/services/whatever.scm" <mirai>unmatched-paren: this is the code that already exists <civodul>and again, if you get nasty results, you can report them and say it's not your fault ;-) <mirai>It would be interesting to explore using define-configuration for nginx but that should be more carefully planned <unmatched-paren>mirai: i would either add another space to the alignment of the other fields or use one space more than the others on that line <mirai>as the "fields" can appear under various contexts (as nginx calls it). I presume the contexts would be represented with define-configuration as well <mirai>unmatched-paren: is there some emacs incantation for it or do I have to do it manually <unmatched-paren>i don't quite understand what you mean; but it'd be pretty trivial to convert that to define-configuration <mirai>unmatched-paren: do you happen to be familiar with nginx? <mirai>the issue I see with a full define-configuration conversion (assuming you want to cover the entirety of nginx) is that you will need to duplicate fields <mirai>say, a field named "access_log" <mirai>it can appear in contexts: http, server, location, if in location, limit_except <mirai>you want each 'context' to be a define-configuration as well <unmatched-paren>how would it make it harder to do... whatever is being done there now? <mirai>the current one isn't a "complete" implementation <mirai>in that case yes, I agree with you that it's mostly a straightforward process <jgart[m]>mirai: you can always write a macro to write the code you don't want to write ™️ <mirai>jgart[m]: it's macro's all the way down :)) <unmatched-paren>PotentialUser-30: i think mumi does take a moment to notice that debbugs.gnu.org has a new comment/issue <nckx>unmatched-paren: Yep. It's rsync $mbox in a loop. <jgart[m]>PotentialUser-30: That feature of mumi is buggy <nckx>But the lag between debbugs → issues is usually insignificant compared to the lag between you → debbugs (i.e., the mail arriving). <nckx>Oh, did you use the form? ☹ <jgart[m]>PotentialUser-30: I've tried before to no success on various occasions <jgart[m]>But that's for sending new versions of a patch set to an existing ticket in a lazy way <nckx>PotentialUser-30: I've disabled that form in the past because it just didn't work. God knows how many replies have been lost by it. <jgart[m]>Would be cool to have mumi submit form failure analytics <nckx>I'd say it would be more than cool. <jgart[m]>PotentialUser-30: How's the video quality in nehko? neh or yeh? <nckx>Berlin's still running revision 1. <unmatched-paren>it's annoyingly easy to make that sort of mistake when you aren't testing it... <PotentialUser-30>unmatched-paren: Is there a rule about the indentation? 1 or 2 ? (see above) <unmatched-paren>macros with "bodies" like modify-inputs and begin also use two spaces <unmatched-paren>since there a dir-locals.el which sets that all up when you edit a file in it <jgart[m]>PotentialUser-30: Or just look at how people do indentation in the codebase currently and follow the pattern <jgart[m]>Now I just have to practice what I'm preaching <PotentialUser-30>From Manual: To automatically indent a package definition, you can also run: ./pre-inst-env guix style package sounds promising. Does anyone use that? <PotentialUser-30>It's easy to test (if you want yourself) - it's displayed after configure phase as "User defined options". With your suggestion the "qt5 enabled" is missing... <kaelyn>nckx: Good morning! I saw your build output (https://paste.debian.net/plainh/9fa3d7dd) and while it has different hashes from my big computer, the other computer I built on has the same hashes as you: 0ivsy225wa75i96i5kd7brn28cncrg18r0j1mcqg5prfyphklmwk for /gnu/store/y2jydm8l05k403dqk1zg9valmfq93zqx-libreoffice-7.3.5.2 <kaelyn>This also isn't the first time that I've had local builds on that big system end up with different hashes (which is also a little frustrating when it pops up since I have it building and serving substitutes for my other computers, such as my laptop). <jgart[m]>PotentialUser-30: If you're not sure what to do about indentation in the beginning then just use `guix style ...` <jgart[m]>If it produces bad formatting then open a discussion as to why <nckx>kaelyn: Hmm. (Well, hashes differing isn't really a blocker for sharing substitutes, just FYI.) I'm not available tonight because of belated thanksgiving din-dins, but could you run diffoscope or so against both & share the results? Thanks for the work so far! <jgart[m]>Would be cool if guix style gets to the level of python-black for automated code formatting <nckx>kaelyn: I'll point out the utility ‘guix copy’ here, just because it's less well known for some reason. o/ <unmatched-paren>jgart[m]: i think the main thing we need to do is get a newline inserted between ``#:phases'' and the value <PotentialUser-30>unmatched-paren: Seems like the qmlgl plugin is built when we have all the qt5 inputs - it seems the configure flag is not really necessary. I'll try without it... <unmatched-paren>jgart[m]: and also possibly generalise that to "if a keyword's value is multiple lines long, insert a newline after the keyword <jgart[m]>I should get better at parsing scheme code <unmatched-paren>the problem is the (guix read-print) stuff might not be powerful enough for the second thing <jgart[m]>So I don't become a hash bumper my whole life <jgart[m]>At least, I've learned how to use guix refresh -u efficiently and almost etc/committer.scm <jgart[m]>I think that etc/committer.scm will be to Guix package maintainers what Guix is to Guile if we can make it work awesomely. <jgart[m]>1. auto-commit any time of Guix maintenance chore <kaelyn>nckx: I do believe I was overthinking the has difference. The difference in the hashes was from --no-grafts (when I do --no-grafts on my first machine, it has the same hash as both you and my second machine) <jgart[m]>Do you happen to know offhand how to set that in meson? <jgart[m]>It's a comfy bloaty terminal. It's like tmux if it was a GUI <lilyp>I wondered what the problem was given that IIRC it was GTK/VTE <lilyp>which should be easy to package, but perhaps not with dlang <jgart[m]>Has anyone tried doing stuff with the mumi graphql API? <jgart[m]>Darn, anything following the Gnome Human Interface Guidelines takes forever to build <itd>running `guix import json` twice can result in packages with 'different' inputs; that confused me a bit; example (see "openssl"): https://paste.debian.net/plainh/8ea0aeeb (probably due to "(define-public openssl openssl-1.1)") <jgart[m]>Is a thunk a function of no arguments. so called because you can use it to encapsulate a "thought" (calculation)? <whereiseveryone>Kabouik: Is that how we think of it as Guixers? Or something different than what jgart described? <mirai>(make check-system TEST=nginx) <jgart[m]>Is there a way to get guix to always download the source code to the repo even when it is pulling a tarball or something else? <jgart[m]>guix already always downloads the source code to the store? <unmatched-paren>ah, right, so you want to download the source? ``guix build -S PKG'' <jgart[m]>Oh ok, so that download the tar.gz and then I unpack it <jgart[m]>would be cool if it just unpacked it for me but ok <nckx>There is some tension between 'guix build --source' always returning a directory, which has its perks, and returning the upstream sourceball when possible (the one upstream might have signed). <nckx>kaelyn: Oh :-). I'm pretty sure I tried both and still got a different derivation (not output) hash, but as long as the output matches I think we're good to go. <rekado>installed a honeycomb machine, but something’s not quite right <rekado>I don’t get a prompt. Instead I see “can't open /dev/AMA0: No such file or directory” and similar for all ttys — the “tty” string is missing <omlet[m]>Libreoffice not have portuguese interface <omlet[m]>unmatched-paren: And rivertile/rivercarro <omlet[m]>I think the fork developer is portuguese speaker why carro is car in portuguese <omlet[m]>With distrobox its easy use fedora without kernel blobs <kaelyn>nckx: is there anything I should do or that is needed from me for the libreoffice changes? <omlet[m]><kaelyn> "nckx: is there anything I should..." <- Its more compatiblity with ms docx <omlet[m]><kaelyn> "nckx: is there anything I should..." <- And onlyoffice is freedom software <nckx>kaelyn: I don't think so, if you added those comments. Not at PC now but will be later. <omlet[m]>nckx: Onlyoffice use ooxml but woth more compatiblity for default <nckx>I'm sorry. I have not the faintest clue what you're on about. <nckx>I'm also going out of Wi-Fi range, so adieu, my pretties. <omlet[m]>I'm asking why onlyoffice hasn't been packaged for guix yet <kaelyn>omlet[m]: my comment to nckx was about fixing a build and reproducibility issue with the existing libreoffice package (the build issue being a release blocker for Guix 1.4.0) <kaelyn>Anywho... I'm stepping away from my computer for a while. Cheers everyone! <florhizome[m]>Onlyoffice is basically pure JavaScript. I think it will take a while to land in guix proper. <omlet[m]>is because the onlyoffoce is the most like the ms office <unmatched-paren>omlet[m]: yeah, almost every large desktop application is a massive pain to package... <unmatched-paren>at least, libreoffice requires tons of libraries and uses multiple languages <omlet[m]>I can use onlyoffice in fedora container <omlet[m]>unmatched-paren: portuguese interface not have <unmatched-paren>javascript packaging will obliterate your will to live upon contact :) <unmatched-paren>omlet[m]: that's pretty surprising that libreoffice doesn't have a translation into portuguese <omlet[m]>unmatched-paren: Not have time now,but after <zamfofex>omlet[m]: I have trying to get more people motivated into helping bring JavaScript packages from npm to Guix! (Which I kinda wish more people paid attention to, since I still sincerely believe my approach can help make that much easier than other approaches tried before — and I’d love to know if it doesn’t and why in case people have tried similar things.) <zamfofex>(Also, I can speak in Portuguese too, if you feel like you want to send me a private message!) <omlet[m]>If your have telegram i am create a group about guix for portuguese speakers <omlet[m]>Too i want create portuguese group in natrix and xmpp <zamfofex>Also, I’m currently a little caught up trying to update some of the Hurd packages. 🤔 I’m running into an issue where ‘libstdc++’ refers to some ‘pthread_*’ symbols, and thus GMP is failing to cross‐build during linking. 🤔 (If anyone has seen anything like this, I’d love some kind of assistance!) <zamfofex>And when I say “failing to cross build during linking”, I mean “while making sure the compiler works during the ‘configure’ phase”. <mbakke>so the latest audacity source release is only available as a .zip ... with a single tarball inside <cbaines>nckx, regarding the mumi update, I was specifically looking at a change Arun made to show QA badges <cbaines>I think it brings in a commit from you as well though <mbakke>oh good, I was half expecting to find a ISO or something inside the tarball <mbakke>ACTION bravely went with git-fetch despite the comments in guix source <zamfofex>So, I decided to investigate it further, and it seem libstdc++ has a dependency on a symbol such as ‘pthread_create’, but glibc only exports ‘__pthread_create’! So it seems like libstdc++ is being built wrongly for some reason… Hrmph. <civodul`>zamfofex: libstdc++ is being built as part of GCC or as a standalone package? <civodul`>it could be that recent Hurd expects recent glibc, whereas Guix master has 2.33 <zamfofex>It seems that it’s part of GCC, given that it has the following file name: ‘/gnu/store/…-gcc-cross-i586-pc-gnu-11.3.0-lib/…/libstdc++.so’ <zamfofex>(Yeah, I’ve been waiting for over two days now for the whole thing to even get to this point! 😅 Since it seems substitutes are currently unavailable for ‘core-updates’.) <mbakke>hm, audacity now requires a "VST3 SDK" ... the code for which is seemingly available as GPL, but actually developing with it requires signing a dubious license agreement <mbakke>ACTION is not in the mood for legalese, tries backporting wxwidgets compatibility patch instead <unmatched-paren>mbakke: wasn't there some crazy corporate takeover stuff going on with audacity or something? <mbakke>ah, there's a cmake toggle for vst3, phew <mbakke>unmatched-paren: yes, I remember some kerfuffle around that ... I think there is a fork somewhere <minima>hi, i'd like to add a channels.scm file to my ~/.config/guix/current folder, but that appears to be a symlink to the store and hence read-only... any standard/recommended way to deal with this? <zamfofex>minima: Why do you need that? I don’t think it’s usually a normal thing to want. <mbakke>anyone know why cuirass have not evaluated any specs in two days? <mbakke>it seems to be processing queued builds still <mbakke>ACTION does not want to update ungoogled-chromium without a working cuirass, considers global warming <mbakke>I suppose most users would experience memory thrashing and ultimately lockups before having any considerable impact on the environment, but that's not a bunch of fun either <minima>so, i added a new channel to '.config/guix/channels.scm', run 'guix pull' and now i'm looking for some of the packages that i'd expect from the new channel, but i can't see any of them - i.e. 'guix search ...' returns nothing <minima>what could i be missing? i've tried with 'hash' already, just in case <jlicht>minima: does running `guix describe' show you the channels you expect? <minima>unmatched-paren: what should i expect to see in ~/.config/guix/current? anything in particular re my channels.scm? i put channels.scm in ~/.config/guix/ (the parent folder) <unmatched-paren>minima: specifically it should contain the channel's modules in ~/.config/guix/current/share/guix/site/3.0 <unmatched-paren>oh, in that case... maybe you need to source ~/.config/guix/current/etc/profile? <minima>oh - that did it unmatched-paren <minima>on a slightly more general level, i've created this system definition that includes '(extra-special-file "/etc/guix/channels.scm" (local-file "channels.scm"))' <minima>if i create an image for that and install it, i understand i then need to copy channels.scm to the user's (and root's) guix config folder if i want to use the extra channels?