IRC channel logs
2023-07-25.log
back to list of logs
<ulfvonbelow>I wonder if removing read permission from /gnu/store (the directory) for everyone but root would break anything. <ulfvonbelow>that way you could put secrets in there, and only someone who knew the hash could access them <ulfvonbelow>but then you'd have a headache keeping track of which references to them are visible and by whom <ulfvonbelow>also, do we actually have any way to read or write signed types in (guix build syscalls)? <oriansj>ulfvonbelow: well you need the read permission along with the execute permission to actually run the programs as a user <ulfvonbelow>since you can still access the files in a directory without read permission just fine as long as you have execute permissions <oriansj>ulfvonbelow: yet, one has to read the content of the files into memory to run them. <ulfvonbelow>yes, and you don't need read permission on the containing directory to do that. <oriansj>note it is possible for improperly setup linux systems to execute programs without read permissions and just dump that process memory into a file (thus defeating that missing read permission bit) <ulfvonbelow>yes, but executing a directory doesn't create a process image at all. <oriansj>ulfvonbelow: true but I am just talking about the files themselves <oriansj>the execute bit in directories is actually the search bit and means that entries within the directory can be accessed <oriansj>well assuming one doesn't need to know the contents of the directory (ls -hal /$path would break) it would continue to function as long as guix doesn't need to know the contents of the directories for previously built packages <RavenJoad>So I am having the same issue that yewscion had on 2023-07-22, where guix home was propagating a guix install (which does not respect things). They removed guile-imanifest, but I do not have that. Can I see which package is requesting that the guix binary be installed into that profile? <lilyp>RavenJoad: you can use guix graph to visualize it, but I'm not sure whether manifests support --path <RavenJoad>lilyp: That is quite a large graph. I am using "~/.config/.../bin/guix graph guix | xdot -", like the manual suggests. Is there a better way? Just bisect the package list to narrow it down? <lilyp>use each root in the manifest to construct the path maybe? <RavenJoad>With the number of packages in this manifest, it would be easier to just bisect. <RavenJoad>lilyp: Found it. guix-data-service is the culprit, I believe. <RavenJoad>Should the guix-data-service package propagate guix like that? <RavenJoad>It looks like a minor update made that happen, namely f6fa20f9237c185b4e887a343cd19aa37855aed9. Should I open a bug/issue? <RavenJoad>Also, for the IRC logs, I found out which package was propagating guix in guix home with "guix gc --referrers ~/.guix-home/profile/bin/guix". <lilyp>I mean, common advise is to not put guix-* anything into your profile but use shells instead <RavenJoad>There are some guix-* things that are fine though, like guix-icons, hence my confusion. <RavenJoad>But also, should a package really have guix as a propagated-input? <ecraven>hm.. I see gcc from guix in my path, however it doesn't show up under guix package --list-installed.. how do I remove it? guix remove gcc-toolchain doesn't let me remove it either <juliana[m]>it's probably propagated by some other package you have installed <ecraven>I don't want it.. is there no way to get *just* the package, but *not* dependencies? <Martin[m]>maybe you have installed it system wide in your configuration.scm if not then you can try guix gc or just `guix shell --container' <ecraven>I'm using foreign guix, I have no configuration.scm <ecraven>(thus I don't want gcc11 on my gcc13 arch :-/) <bumble[m]>whenever guix pull and then guix system reconfigure are used, my system never shuts down all the way and I always need to press and hold the power button to shut it off <bumble[m]>the system is always shutdown with sudo halt <juliana[m]>I vaguely remember someone discussing a bug in shepherd that causes the behavior you've described <bumble[m]>thanks for sharing that info will be useful for searching solutions a bit better <xelxebar>Dang, the last few times I've pulled, massive amounts of texlive packages have been added. Clearly some solid work being done!! <mfg[m]>Ah i have the same problem rebooting, but my solution is to reboot less often, so it's not that annoying :D <xelxebar>Ah, I've been seeing the same issue. Always pauses right after saying that it's shutting down user-file-systems. <xelxebar>First time this happened and I hard powered off, it actually ended up borking my filesystem. Had to to a full reinstall. <xelxebar>Luckily it is Guix, and a full reinstall isn't a disaster, but it's still a huge pain. <xelxebar>Still haven't gotten Anthy working again, despite system and home directory being ostensibly exactly the same as previous install. <mfg[m]>FeelsBadMan, i've had luck then i guess. I haven't had a single problem just disconnecting the power to shut the system off... <bumble[m]>I'm "glad" to see that other people are also encountering the shutdown problem <iyzsong>i have the shutdown issue too, thinking it as linux kernel's fault, maybe i'm wrong😂 <mobius_>so i got protonvpn up and running. protonvpn-cli is a guix package, but there's no instructions on how to configure, even on website. i figured it out though if anyone's interested. pretty simple really <pjals_fox>ooh, let me guess, you made a protonvpn-service-type? <mobius_>nope, you just have to initialize from the binary executable directory with: protonvpn init <mobius_>there might be a simplier way, but i'm brand new to guix <mobius_>like maybe putting the binary in the path or something <mobius_>then once you initialize, just follow the instructions for protocol (tcp/udp) and login credentials, which can be found by logging into your proton account. <xelxebar>mobius_: Oh cool! Good work. Sounds like a perfect fit for a service. Have you written package definitions before? Service definitions are pretty darn easy, too. <xelxebar>If you can figure out what the init command does (like just setting up a config file?) and map that to some protonvpn-configuration structure, then I'm sure people would be willing to help you with converting it into a service. <pjals_fox>if your gonna make a service, make sure to make it a home service, not a system service :P <mobius_>over my beginner's head people lol. let me write some of what you said down though so i can figure it out more <mobius_>as far as converting it into a service, what do you mean? <xelxebar>mobius_: Well, yeah, so you can declaratively define the configuration and have shepherd manage the starting and stoping of it. <xelxebar>Granted, if you're just starting out, it can be way too overwhelming to try doing everything at once. <xelxebar>Just getting your first package definition down gives a really nice sense of accomplishment itself! <abcdw> I'm proxying ci.guix.gnu.org via ci.guix.trop.in and ci.guix.ygg.trop.in, so people in countries where it's blocked can access substitute server, but ci.guix.gnu.org is blocking my vps. Can we workaround it somehow? <cbaines>abcdw, I doubt ci.guix.gnu.org is blocking anything, but I know that the MDC (which provide hosting) do block things <cbaines>from my experiences talking to issues.guix.gnu.org (which is on the same machine), the blocking is dependent on opening new connections, so maybe you could configure your reverse proxy to keep connections open/reuse them? <cbaines>anyway, bordeaux.guix.gnu.org generally has more substitutes, as well as a faster and unrestricted internet connection <abcdw>cbaines, ok, I'll try to add keepalive to nginx config, thank you for the tip. <efraim>I actually moved my substitutes list around to check bordeaux before ci <minima>hi, i'm looking at ublock-origin-chromium, the package description mentions Icecat, as well as chromium of course; am i understanding correctly, does that imply i should be able to use the plugin with Icecat too? <minima>i tried to manually feed the plugin's js blob to Icecat but it didn't seem to like it, it muttered something about invalid format or something <nckx>uBlock Origin supports both, and there's a non-public ublock-origin package, but ublock-origin-chromium is the Chromium plug-in. <nckx>I don't know why the main package isn't public. <nckx>You could build it with ‘guix build -e '(@@ (gnu packages browser-extensions) ublock-origin)'’ and see if you manually feed the -firefox output. <minima>hey nckx, thanks! sorry, what do you mean by non public exactly? oh and brilliant re the 'guix build' command, i'll try that straightaway <minima>oh, non public as in not exposed by the guile code? <nckx>It's not explicitly marked as hidden, but it's not exported either in the module header or by using define-public. <nckx>minima: The '(@@ (my module) foo)' is just a hack to forcibly extract private variables. It doesn't always work. <nckx>apteryx <pygobject>: Nice find. You, er, can keep it… :-/ <apteryx>at the moment I'm leaning towards the .typelib introspection objects not being graftable <minima>nckx, oh i was lucky, your oneliner worked brilliantly - i'm still unable to load the generated xpi into icecat as it's not verified, but i'm working on it now <apteryx>nckx: hm, nevermind, I've verified the .typelib and it's correctly grafted <nckx>minima: Maybe you'll submit a ublock-origin-icecat package. 😉 <nckx>apteryx: I'm of little use debugging Gthings and tend to avoid them whenever possible. <rekado>it’s a bit slow, but it does work on my laptop, and with considerable delay it also works on a different server on the MDC network <rekado>times out on ci.guix.gnu.org though <RavenJoad> I ran into this yesterday where the guix-data-service package is using guix as a propagated-input, which was made as a change during an update. Should a package ever have guix as a propagated-input? <jpoiret>RavenJoad: as a propagated-input I don't think it's wise <rekado>nckx: no, that’s not explicitly unblocked. <RavenJoad>jpoiret: guix-lint does not catch that either. Perhaps a pass that checks propagated-inputs and puts out a warning message asking the packager to think about what they are doing? Since there is no way to always say that guix should not be propagated. <podiki[m]>is someone able to cancel the current mesa-updates build? looks like it wants to build more than expected so I might as well throw in some more patches and mesa just updated again today <mfg[m]>has someone tried to sue xournalpp with guix? It doesn't start for me and i believe this is due to missing icons in the adwaita theme. Would be nice if this is actually the case or something else <nckx>podiki[m]: Eh, I tried, but now builds are going from the Failed state back into Pending, one by one. Weird. <nckx>(It's pending in some places, scheduled elsewhere, but it's the same state.) <podiki[m]>i may delete the branch to rebase it, but i guess that doesn't matter since there's an evaluation already? <nckx><Weird> That's Cuirass for me nowadays. <nckx>It won't break the specification, but nor should it ‘fix’ the undead builds. <podiki[m]>right (meant "matter to cuirass's evaluation") <podiki[m]>i don't think a rebase is strictly needed since I did that end of last week, but maybe might as well <nckx>ACTION away, probably for the rest of the evening, although I might pop in on a 'phone. <cbaines>podiki[m], I restarted Cuirass on berlin earlier, and that seems to have helped <podiki[m]>mesa-updates has ~11k rebuilds vs ~15k originally, so I think i'll bump mesa to the newer release and add some waiting patches <cbaines>podiki[m], make sure you interpret the numbers from Cuirass correctly <podiki[m]>i was looking at total builds, which is across all architectures, right? <cbaines>I think the changes only affect ~4000 packages at most <cbaines>podiki[m], pretty much, it's across 4 architectures currently (which you can see if you go to edit the specification) <cbaines>and ci.guix.gnu.org isn't really building for aarch64-linux and powerpc64le-linux despite those being enabled, so it's really only two ssystems <podiki[m]>i was just thinking if it is similar in size to the original building for mesa being updated then we are back to square one <podiki[m]>what do you think then? patches waiting would be to ungraft mesa (change in master), again update mesa, and I see libdrm, libva and maybe others waiting (though those are bigger than mesa's graft) <cbaines>it's really up to you. bordeaux has build pretty much everything for aarch64-linux and armhf-linux, but the builds for other systems are going to take a long time to happen regardless <podiki[m]>qa page isn't loading for me currently, but that was for the most recent version of mesa-updates right? (there was a graft on master so I updated the branch) <podiki[m]>anyway, if it is all the same I guess I might as well do the merge (I was just going to cherry pick the 2 commits from mesa-updates) and then start on the next version with these other patches later <podiki[m]>cbaines: thanks for the guidance, I'll figure it out later today then <Guest28>Does AMD iGPU require additional drivers? I booted a guix system image which outputs errors from amdgpu and the desktop isn't in high resolution. I thought stuff like this is automatically loaded from the kernel and amd has open drivers <apteryx>Guest28: amdgpu requires blobs... it's sad <Guest28>Ah, so it is like nouevau? Requires proprietary code to load the actual driver? <apteryx>you've fallen for the 'open drivers' catch (I did once too). Free drivers tightly couple to nonfree proprietary firmware blobs that the kernel needs to load. <apteryx>nouveau doesn't require proprietary code for old cards, I guess it does for newer ones. <apteryx>I'm running a very old 'GTS 8800' on linux-libre <Guest28>Okay, good to know. Does that mean with linux libre I can't use AMD AND Nvidia gpus? <apteryx>the best resources to know is mesa3d.org or h-node.org, IIRC <apteryx>that reports suggests so, but I'm doubtful, I thought nvidia cards as recent as 2020 would required a signed firmware <apteryx>I'd suggest double checking this with the mesa folks or in #parabola <apteryx>code name for that card is NV168 (TU116) <Guest28>Okay, thanks for the help. I always thought at least AMD is open but turns out the gpu market is as horrible as everything else for libre <apteryx>it looks like it may work from the featurematrix page I shared above <apteryx>but the 2D features are marked as TODO <apteryx>not sure how that impacts 2D graphics such as running an old fashion desktop <Guest28>should have studied hardware engineering... <apteryx>I think you can trust that h-node.org page <apteryx>the problem with hardware engineering is that most tools are proprietary as well... <Guest28>This community (whole GNU) is in my opinion not small and has so many talented people. I never understood why we can't develop our own hardware. Sure, those companies have big fabs, but you need to start somewhere <Guest28>My naive point of view leads to a strong motivation <glin76[m]>Hello, does someone know how to toggle on NumLock at the login page of Guix ? I use numlockx to toggle it when launching i3, but I don't know how to do for the login screen <RavenJoad>glin76[m]: There is usually a BIOS/UEFI option for that, in my experience. <RavenJoad>Guest28: As someone who has some knowledge in this area, the problem I see is the lack of a unified goal. HW design is slow, hard to get right, and rife with anachronisms. All of that combined with no single vision for a product complicates things. <Guest28>RavenJoad: That thing with the unified goal was my theory as well. I wonder how this puzzle can be solved. Especially with so many people with different opinions on what is right or wrong, like you mentioned. (isn't the same with software as well? I mean how did Guix or Emacs manage it?) <bjc>the startup costs for software are effectively 0 <Guest28>Yes, this is an additional problem. Finance. I read that Google fabs CPUs for free. You need to have a good idea and if they like it, they apparently produce it. I mean. better than nothing I guess. <apteryx>Guest28: my opinion is that free hardware will really take off when we aren't bound to fabs anymore (e.g. a chip or circuit can be cheaply produced at home via 3D printing, say) <bjc>we are a long, long, long way away from 3d printing something like a cpu <RavenJoad>Guest28: I would say Emacs and Guix managed to handle everyone's wildly different opinions by using an easily understood language, that allows for easy rewriting and extension, whose extensions become the same class citizens as the original, along with providing well-thought-out APIs for common usage. <cnx>is guixsd getting zenbleed workaround patches anytime soon? linux-libre has released them for 6.4 and all LTSes <viaken>Is there a Guix equivalent to arch-chroot? <viaken>apteryx: If we don't demand current-gen performance, hobby/small-scale fabs are workable. <glin76[m]>I am sorry : is my question is inapropriate in this room ? <viaken>glin76[m]: Seems fine, but I'm not sure how to help you. Which login manager are you using? <viaken>Anyway, let me make sure I understand. Numlock is off when GDM launches and you want to turn it on? Or you want to detect numlock state to toggle which DM it launches? <glin76[m]>The first one, i would like NumLock is on when i put my password <glin76[m]>Thank you but I've already seen this page, try it but doesn't work <viaken>And numlockx is part of your system packages? <glin76[m]>Yes, I've installed it, and it works fine when launching i3 <viaken>numlockx works fine within i3? Then I'm out of ideas. <glin76[m]>Ok thank you anyway. But you, in your Guix, you have NumLock on by default at startup ? <jpoiret>however, arch-chroot is pretty easy to replicate <grim`>Good evening. I'm planing to submit some packages I've been used on my personal machine. If among those packages I want to commit 2 sddm themes should they be in separated commits or could they be in the same one? <jpoiret>you only have to bind mount /dev /sys and /proc iirc <jpoiret>grim`: they should be in separate commits <jpoiret>viaken: additionally, there are some instructions for chroot'ing into a guix system in the manual <efraim>I think numlock is enabled by default with sddm, I still need to figure out how to turn it off on my laptop without a separate numpad <efraim>glin76[m]: thanks. it looks like that is what I did in the end with my laptop <glin76[m]>unfortunately for me the configuration for GDM does not have this option, so I may have to switch to sddm <grim`>please, could anyone point me how could I install the git info manual in guix? The `git` package does not seem to provided. <mfg[m]>my guess would be that you need git and the info reader in the same profile <mfg[m]>guix shell --pure git texinfo -- info git works while guix shell --pure git -- info git doesn't <mfg[m]>and well `guix shell --pure texinfo -- info git` -> `info: No menu item 'git' in node '(dir)Top'` <grim`>mfg[m]: right. me dummy. I forgot about that one. Thanks! <juliana[m]>anyone know a guix shell command for launching ungoogled-chromium in a container when running wayland? i've played around with it a few times and never quite seem to get it right... <juliana[m]>I avoid chromium-based browsers like the plague, but sometimes i need to use... proprietary GPS services... because the open source transit apps don't support my city <juliana[m]>and for some reason proprietary GPS services won't work in my locked-down browser <zamfofex>juliana[m]: Have you tried using IceCat? I never really had any trouble with web compatibility with it. <zamfofex>juliana[m]: Do you need Chromium to use the Wayland backend? Maybe it’d be easier to use it with the X11 backend by using Xwayland. <rrobin>juliana[m]: i have some guix shell shenanigans here, but not sure if they work (been a while). But my setup used X11 and relied on a guix profile being prepopulated <juliana[m]>zamfofex: the main issue is knowing what to pass for --expose. There's an example in the manual of exposing the screen to an X client, but I guess Wayland doesn't use the same syntax <nckx>cbaines, podiki[m]: Merely restarting cuirass isn't sufficient IME. It restarts parts (jobs) but not everything (evaluations). Unless you restart more than the cuirass* shepherd services? <d00s>can anyone point me to info on statfs? guix shell says no such file/or directory <nckx>The… statsfs(2) system call? The stasfs.h header file? <nckx>The latter being part of the glibc package. <d00s>i assume it's related to proc/stat <nckx>‘It’ is underdefined here. :) Which exact ‘guix shell’ command, and what does it say? <grim`>If I'm packaging something which does not have a version on the upstream git repo (only arbitrary commits and master branch). What should I put for the version field? Just the commit? <nckx>There's paste.debian.net for long ones. <d00s> 3 guix shell --container --network --emulate-fhs \ <d00s> 4 --development ungoogled-chromium gcc-toolchain glibc \ <d00s> 5 --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \ <d00s> 6 --preserve='^DBUS_' --expose=/var/run/dbus \ <nckx>Or you'll be sniped by a bot in 1… 2… <d00s> 7 --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \ <d00s> 8 -- ./VSCodium-1.80.1.23194.glibc2.17-x86_64.AppImage --appimage-extract-and-run <nckx>grim`: Use something like (let ((version "0.0.0") (revision "0") (commit "abcd…")) (package … (version (git-version version revision commit)) …). If you grep for ‘(revision "0")’ in the repository you'll find examples. <d00s>anywho, i'll keep looking for clues :-) <nckx>I'm downloading the prerequisites. <nckx>But I'm guessing that statfs is the failing system call because $something is missing, not that it's the actual thing that is missing. <nckx>I tried very briefly to ‘--appimage-extract-and-run’ once, without success, but I didn't put much effort in. <nckx>This was before --emulate-fhs though. <nckx>‘guix shell: error: statfs: : No such file or directory’ <nckx>Well that's certainly something. <nckx>Note the offending ‘file name’: the empty string. <nckx>--expose=$XAUTHORITY looked suspect to me when I copied it… <d00s>heh... i use guix as my daily driver on my lappy, so it would be nice to have appimages sorted out. but it won't rin my day <nckx>$XAUTHORITY is empty here, I expect it's empty there as well. I think you might have meant something else than --expose? <nckx>Or copied this from a tutorial making 🦇 assumptions 🦇 ? <d00s>ah, i didn't notice empty string. yea, it's from tutorial <nckx>‘--expose=$XAUTHORITY’ evaluates to ‘--expose=’, i.e., nothing, which Guix can't find. <nckx>They could write ${XAUTHORITY:+--expose=$XAUTHORITY} instead. <nckx>Now, VSCodium-1.80.1.23194.glibc2.17-x86_64.AppImage still fails to launch… <d00s>but the new error looks familiar, something related to fuse or squashfs <d00s>when it fails to extract properly <nckx>Oh, good, you're getting a better error than I am. <nckx>ACTION got guix shell: error: /tmp/VSCodium-1.80.1.23194.glibc2.17-x86_64.AppImage: command not found <nckx>Which usually means missing interpreter or so. <nckx>I'll let you debug your superior error message :) <d00s>hehehe... if i ever sort it out... i'll be sure to tell you first :-D <podiki[m]>but the same still applies: don't think you can run the appimage as is since it will try to mount with fuse which you can't (probably) in a container like this <d00s>thank you, i'm trying to use your suggestion, podiki <podiki[m]>figuring out dependencies can be tricky (appimages are not so self-contained after all) but should work <podiki[m]>what's the right way to correct a local checkout when you run into contributing.*.texi nonexistent node errors? <podiki[m]>(i ended up resetting doc, then bootstrap, configure; probably something easier?) <podiki[m]>nckx cbaines: I think you are right, seems new evaluations aren't being picked up; just the couple of evaluations from earlier today but seems stuck again