IRC channel logs
2023-02-08.log
back to list of logs
<unmatched-paren>now there's a post you definitely don't want taken out of context... <oriansj>unmatched-paren: oooh, you should see the analogies and metaphor examples we were given. <oriansj>it literally starts with: "Her face was a perfect oval, like a circle that had its two other sides gently compressed by a Thigh Master." <mirai>were these examples distributed in (electronic) green text form <oriansj>and ends with: "It hurts the way your tongue hurts after you accidentially staple it to the wall." <mirai>it has that characteristic writing style <oriansj>mirai: no, this was printed on paper back in the early 1990s <oriansj>but I can imagine it probably be green text material <oriansj>hard to know if your teacher is a chan troll when one is in 4th grade <oriansj>and it was back in the old days before 4chan existed and dial up BBS systems were all the rage <oriansj>unmatched-paren: possibly, I don't honestly know. <oriansj>I just know it included such wisdom as: "John and Molly never met. They were like two hummingbirds who had also never met." <oriansj>and "It was an American tradition, like fathers chasing kids around with power tools." <oriansj>And "He was as lame as a duck. Not the metaphorical duck either, but a real duck that was actually lame. Maybe from stepping on a land mine or something." <clh3>Anybody booting Guix System from an HDD connected to a RockPro64? <gnucode>clh3: that is a 64 bit arm machine right? How much memory do you have? <clh3>gnucode: I don't have the hardware yet, just planning out a purchase. RockPro has 4 GB at most. <clh3>which is more than my current machine <clh3>I'm considering the board for its open boot firmware <gnucode>your current machine has less than 4GB? Man. 8GB is the lowest I try to go for now. <clh3>the guix channel logs show other rockpro64 guix users, but SSD and eMMC storage seems more popular despite the write limit limitation <clh3>gnucode: true, this would eliminate swapping <gnucode>clh3: I personally would recommend a T400. You can libreboot it, and it has 8GB max ram. <gnucode>Librebooting my T400 was super hard. The guys in irc had to hold my hand the whole way through the process. <gnucode>whereiseveryone: T200 is pretty easy to libreboot. :<) I use guix system on sway, and it works really well. xfce would be great too, but I prefer to be a hipster and use wayland <gnucode>I actually read a blog post somewhere recently that claimed that xfce only used 1MB shortly after starting the computer. That's pretty low resources! <gnucode>no sorry. I think it was 100MB... 1/10 of a GB. <oriansj>well that is more because X11 is holding 300+MB of State <oriansj>well if one does the math: w pixels high times x pixels wide time y bytes per pixel times z number of buffers and on even a screen the size of that on the x200; you can pretty close to that number pretty fast <apteryx>rekado: re jami, it's down from 2791.8 MiB to 1888.5 MiB on master! <oriansj>i3 clocks in at 174.1MB virtual and only 13.9MB resident <oriansj>I found dwm to have the lowest memory footprint but if one isn't careful can have a memory leak. <apteryx>oriansj: top says my ratpoison process is using 3.0m of resident memory <oriansj>apteryx: well if I do monochrome 640x480; 1 buffer and compile with -Os one can get dwm to under 512KB <oriansj>after which one starts to know a better Window manager experience is worth a little bit of RAM <oriansj>then if they go too far the other way; KDE/GNOME can be cranked up over 11GB <oriansj>spectrwm is pretty light and is rather comfortable if one works with reasonable GUI applications <oriansj>dwl looks interesting but I haven't seen anyone on Guix use it yet to know if it is in a working enough state to spend time to get it to mirror my GUI standard. (Single screen at a time, alt-tab/alt-shift-tab to move between apps in a ring buffer) <oriansj>(as I have no need for screen splits or any extras) <mfg[m]><ieugen[m]> "thanks, but is there a tool I..." <- I don't know of such a feature 😞 <Parnikkapore_m>Hi Guix! I've been trying to update the Dino package; it now requires libadwaita, I've added it to inputs, but the build failed with "`Could NOT find Adwaita (missing: Adwaita_LIBRARY)`" <Parnikkapore_m>I've looked around, and other packages using libadwaita use meson-build-system and did not have to do anything special. Dino is stuck with a heavily customized cmake script <iyzsong>Parnikkapore_m: you can try read the cmake file that "find Adwaita" and reason about why it fails.. <Parnikkapore_m>found it by running pkg-config manually: gtk4 wants pango 1.50 but inputs also had pango 1.48; pkg-config silent fails <bdju>sound working again after a reboot... not sure what the problem really was. oh well. <bdju>gnucode: T200 doesn't exist, maybe you meant X200 <ieugen[m]>since guix channels is Scheme code that gets executed on a machine, how can someone enforce some security with regards to what the code can or can't do on a system? <ieugen[m]>it has a list of channels that it scans periodically and let's say a channel is compromised and someone updates some pacakge code. <ieugen[m]>I know guile is a lisp and it's source code is data, but I am not familiar with how this is used in guix <ieugen[m]>and if it's possible to compromise a system by having a full fledged language for packaging <iyzsong>i think it definited is an attack vector. the code (from channels) are compiled in a sandbox when pull, but then will be evaluated as a normal user when you access its modules. <iyzsong>well we do need and verify the channel code (every commit in git repository) to be signed by trusted gpg keys. <BitPuffin>is there a peer review process for the main guix channel? <ieugen[m]>and to me this looks like an inherent design flaw. <ieugen[m]>having a full fledged languages as a basis has many benefits but in this case a big drawback: unlimitted power <BitPuffin>I guess when it comes to third party channels it comes down to trust (or guix channel for that matter too), since even if the package code itself is a potential threat vector, so is the package that you install <ieugen[m]>yes, you need to trust things - but this is a limiting factor for growth IMO <ieugen[m]>also, people should be aware of this as a security implication <ieugen[m]>and while you can get compromised by installing a package, getting compromised by scanning the packages is a bit worse IMO. <ieugen[m]>imagine you manage a channel with packages as many as guix or nix - 20k-90k . It's hard to review every addition in this case. <ieugen[m]>so the only option is to limit the number of people who can commit add packages to the repo - thus limitting it's ability to grow and evolve <rekado>Guile has a sandbox feature, which could probably be used to limit the kinds of things a channel can do <BitPuffin>also you could probably develop scanning tools that don't expect the code but just analyze its content <sneek>jonsger, you have 1 message! <jonsger>Parnikkapore_m: will have a look at it. That version should be responsive afaik :) <zimoun>efraim: about “julia-fiosio“, you mean #60793 right? <ArneBab_>Has anyone already packaged yacy for guix? https://yacy.net/ — results from duckduckgo have been degrading for years and I want to stay away from Google. <unmatched-paren>ArneBab_: doesn't look like it's there yet, but it seems to be a simple Java package built with Ant, so it probably shouldn't be too hard :) <ArneBab_>maybe I should … is there some tutorial for creating system services, so people can just do herd start yacy? <rekado>Parnikkapore_m: I just built it. ‘guix size’ says that the closure is now 3390.1 MiB; version 0.3.1 was 1420.3 MiB. <mfg[m]>What library provides the GLX component of OpenGL? I thought all necessary OpenGL things are contained within mesa? <rekado>it is suspicious that there are references to different variants of large packages <rekado>dino now also retains references to three different versions of GTK <mfg[m]>Also: What is the reasoning behind not having static versions of libraries in a static output per default? <jonsger>rekado: for me it says 2034.4 MiB :) <mfg[m]>Which package does provide libgfortran.so? it seems it's not part of gfortran-toolchain nor gcc:lib... <mfg[m]>at least on arch linux it's part of gcc-libs <rekado>jonsger: I applied it on top of a545d0adbbba7df2d328c3b7f1d5b327a07c9232 <rekado>I posted my comments to the issue <rekado>are you seeing the same output file name? <jonsger>rekado: ah, I have used ./pre-inst-env guix size dino. That may explain the difference... <jonsger>rekado: do you know why they differ so much? guix size /gnu/store/*dino vs ./pre-inst-env guix size dino <Parnikkapore_m>Dino closure size for me is 2034.4 MiB for 0.4 and 1420.3 MiB for 0.3 to me too <Parnikkapore_m>Although the size of gtk for me is similarly weird... 1961.3 MiB for gtk (gtk4) and 1002.2 MiB for gtk+ (gtk3)?? <Parnikkapore_m>and gtk4 has both gtk+-3.24.30 and gtk+-2.24.33 in its closure?? <jonsger>Parnikkapore_m: I posted to the ticket. The updated dino crashes on my aarch64 system... <rekado>jonsger: the difference could be due to an older Guix I’m using. <apteryx>wouldn't it be useful to have 'guix graph' but for runtime (referenced) dependencies? <apteryx>currently the best tool we have is 'guix size' and 'guix gc --referrers' <apteryx>ah, we already can do this with -t references <apteryx>in libexec/gstreamer-1.0/gst-plugins-doc-cache-generator <apteryx>the patch-source-shebangs has this nasty tendency to capture native-inputs <apteryx>I guess it could be fixed by keeping the native-inputs populated even for native builds (instead of merging them into inputs as currently done), like I did in #60847 <il[m]>Hi everybody! I am playing around with `guix shell --container`, specifically the `--root` and `--profile` options. It does not seem possible to combine them with `--emulate-fhs`, is that the way it's supposed to be? <il[m]>I am trying to use `--root=$HOME/.config/guix/mydev --emulate-fhs` with some packages, and to re-use the same profile later with `--profile=$HOME/.config/guix/mydev`. If I try to add `--emulate-fhs` to the latter call, it tells me that --profile cannot be used with "package options", if I omit it, I do not have /lib, /usr etc, and shared binaries from outside cannot work. <apteryx>il[m]: podiki[m]1 is the local FHS expert :-) <podiki[m]1>Yeah, it doesn't work with the profile option since the fhs option adds a glibc to the profile ... We should be able to work around it but I haven't thought about the details <podiki[m]1>Ideas and patches welcome, or at least a bug report if there isn't one to track this <podiki[m]1>Maybe fhs option needs to check what's in the profile and error or warn if it doesn't have the glibc for fhs <il[m]>my guix knowledge is very limited, it seems --emulate-fhs is doing two things at once, and that's where the issue originates <il[m]>1) it adds the special glibc variant, and 2) it sets up the different folder structure <podiki[m]1>The glibc is not strictly needed but helps with compatibility expectations <podiki[m]1>Would an error or warning (proceeding with 2) be preferred? <apteryx>I think an error with 'is not currently implement' or the likes would be better than the status quo <il[m]>I guess a warning (if the profile does not have the glibc variant, right?) would be ok. Or there could be a sep. option to only set up the folders. Although I am not sure that is all that's missing -- but that's how I understand you. <podiki[m]1>Yeah, was thinking a warning to let you know not full fhs in the container but can let you proceed with the rest with that profile <il[m]>is there an easy way to test this? creating a symlink in the container environment to make it use the proper elf loader? sorry if the Q already seems weird, my knowledge of lower-level linking stuff is mostly... accidental <podiki[m]1>But also should be able to use a profile that does have the glibc variant as expected of course <podiki[m]1>You could try that, pointing to the glibc-for-fhs variant (you'll need to dig a little too find that, maybe in an FHA container we what store link is used) <podiki[m]1>Welcome! And I have to run now will check in later <apteryx>hm, cups keeps a reference to cups-minimal <apteryx>rekado: now at 1844.3 on master, less on staging, and less on core-updates I'm sure (due to polkit being much smaller there). I think that's all the low hanging fruits for now. <apteryx>cbaines: does QA checks the package size variations? <cbaines>this is something that came up last week at the Guix Days in Brussels <apteryx>that'd be fun; it's easy to regress on that front I feel <apteryx>we can guard against regressions with #:disallowed-references, but sadly not all build systems support it <cbaines>there's a sort of road map in the qa-frontpage repo <cbaines>if/when we get that on to Savannah, you'll be able to easily add to it :) <apteryx>OK! I think nckx was looking into that <lfam>Looks like the Berlin build farm is stuck for the last two days <sneek>Welcome back lfam, you have 1 message! <apteryx>lfam: I noticed from the web page; but the logs of Cuirass don't reveal any problem <lfam>Do you mean, the logs make it appear that things are building? Or just that there is no obvious error? <lfam>I ask because the kernel-updates job is definitely not being run, based on `guix weather` <lfam>This happened roughly a week ago, too. IIRC, nckx did `herd restart cuirass` it seemed to work <lfam>Thinking of recent changes: the more frequent GC <lfam>Could it be stuck in GC? <apteryx>jjjjjxiiiej.d.x.gndjkec.x.gji..xtjepeitt.udy <lfam>I see you are logging in <Lumine>Or a domesticated pet walking through :) <apteryx>I'm not sure I like this Yubikey thing <apteryx>lfam: perhaps we should just restart cuirass? and kick its workers (I think that's needed for some reason) <lfam>Do you know how to restart it? I don't <lfam>I mean, I could run the command. But I don't know if that's sufficent <apteryx>right. the 'kicking its workers' part is the part I'm not so sure about; there's a script in mathieu's home <lfam>Well, it's already not working. I doubt we can make it worse by restarting it <apteryx>it's evaluating the specifications, per the log <jonsger>Parnikkapore_m: do you know an application we build against gtk@4.8? <ArneBab_>unmatched-paren: maybe I’ll try that — last time I followed directions in the manual for services, it took me a long time to get it right. <lechner>Hi, is it possible to use Haskell's cabal in Guix? <Lumine>lechner: it's in guix packages no? <lechner>Lumine / yeah, but it does not like the environment variable GHC_PACKAGE_PATH, which is used to relate the Guix profile to the compiler. I get the error cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times). <Lumine>lechner: what happens if you `unset GHC_PACKAGE_PATH' temporarily? <lechner>okay, i feel a bit stupid but thank you. the command at least lists the installed packages with cabal --package-db=/home/lechner/.guix-home/profile/lib/ghc-8.10.7/package.conf.d list --installed it seems like step forward <Lumine>You can also try `export CABAL_SANDBOX_CONIFG=path/to/cabal/sandbox.config` in your env vars after unsetting it <lechner>Lumine / are you involved in packaging (or maybe even bootstrapping) Haskell in Guix? <Lumine>No, I'm just a learner :) But to be honest, guix import has access to hundreds of Haskell packages through hackage, so I don't use cabal or stack myself <lechner>how do you build your own software though? i think that kind of requires cabal <Lumine>lechner: I've never really had to build a Haskell package, so I don't know. I'm just learning Scheme, and I'm a slow learner on top of that. D: <lechner>Lumine / well, thank you for your help. it's good to have you around! <Lumine>But since through guix import you have access to all the main building packages in Haskell I would think it's feasable <old>Hi. Is there a way to keep a successfull build tree? <old>Something like `--keep-failed' but even if successfull <old>I need to inspect some generated data in the source tree a compilation <lechner>old / can you provoke a build failure at the end, like a patch with 'exit 1'? <old>I could yes. That would be my ad-hoc solution <old>But it would be nice perhaps to have such a thing no? <old>something like `--keep Keep build tree no matter what' <lechner>maybe you can send a SIGBUS to the build process, but you have to be fast <old>Just adding a phase at the end with a failure should suffice for now :-) <apteryx>lfam: is there value to computing the checksums for the vendored cargo tarballs? it takes a long time <apteryx>wouldn't they be unpacked then built the next instant? <efraim>apteryx: the ones we place in the guix-vendor directory? We could actually speed it up by some hackery of not really hashing them if we chose to <podiki[m]1>is there any way to get the hash of a package's origin? of course you can inherit, but what if you just want to get the actual hash string? <rekado>podiki[m]1: do you mean at the REPL? <apteryx>efraim: they are not part of any output, right? <rekado>podiki[m]1: (origin-hash (package-source (@ (gnu packages statistics) r-minimal))) <apteryx>I think they don't really need to be hashed IIRC, but it was chosen to for preserving the useful properties (data integrity checks). But if they are used only at build time at around the same time, there's no benefit, right? <apteryx>tried to update rav1e to 0.6.3 on staging, it barfs with: consider adding `cargo-features = ["edition2021"]` to the manifest), exit_code: 101 <podiki[m]1>rekado: thanks. though this is in the context of the recent discussion of computed-file-origin so I'm trying to learn what that is about <acrow`>apteryx: Earlier you had asked about using hplip with cups and I noticed that I had long ago settled on using hplip-minimal. Maybe it's worth a try. IDR why. <podiki[m]1>I think the summary is that you can't inherit a computed-origin? well you can but there's no source hash so the download of the source will fail (e.g. trying to inherit/modify source with customize-linux) <apteryx>acrow`: how did you add the printer? <apteryx>is there something to do to have cameras visible from GNOME's file browser? Some udev rules to install, perhaps? <acrow`>apteryx: paste.debian.net/1270056 worked for me, with a similar HP printer. <acrow`>apteryx: or, at least, without it you are limited to a pretty restrictive set of printable file types. <jlicht>just finished the 12th (and hopefully last) rebuild of node :) <oriansj>I finally figured out a working sway config for guix (probably should be cleaned up more but finally) <oriansj>Turns out the documentation is very very wrong in regards to not needing login-service-type when using greetd <oriansj>and as it required a full reboot of the system and selecting a previous system image (or booting from a recovery image to correct that issue); that seems like something that should be fixed.