<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
<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
<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
<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)
<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
<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)