#TIL: A #Xen #Dom0 running #Debian 12 Bookworm or #Gentoo may crash xenconsoled or xenstored upon #DomU boot if the Dom0 initially has too much RAM:
kernel BUG at arch/x86/xen/p2m.c:542!
In my case it happened with #DebianBookworm's kernel 6.1.0-21-amd64 and in the case of https://bugs.gentoo.org/920747 (via https://lists.xenproject.org/archives/html/xen-users/2023-12/msg00005.html) it was Gentoo's 6.1.67-gentoo-x86_64, both with 64 GB.
Fix:
/etc/default/grub += GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M,max:1024M"
/etc/xen/xl.conf += autoballoon=0
Test by test the list is dwindling on my trials in throwing my desktop stack on random OSs I never ran on my main machine, but next up are Alpine, NetBSD, Void, Devuan, ... Gentoo?
🙀🚂🐧
@justsoup
I follow it with interest. I tend to think of #Gentoo as the the spirit of #BSD brought over to Linux. But Chimera has literally brought over BSD components and clang/llvm tooling. And ZFS support by default. Not production ready yet, so it's unlikely to unseat #Debian when I need to spin up Linux in Bhyve. But it would be fun to do some benchmarking with phoronix to compare performance against the usual suspects.
[1] https://www.phoronix.com/news/BSD-LLVM-Linux-Alpha-Coming
What is the simplest web-based issue tracker to set up on #Gentoo? There are a couple in the repos, but they all seem to require FastCGI and I wasn’t able to find decent instruction as to how to make that work. 
Am I missing something or is it basically impossible to have `cargo update` actually select dependencies that are acceptable for the specific minimal `rust-version`? Like, even if you install old #RustLang version, `cargo update` from this version will update `Cargo.lock` to dependencies that require a newer Rust version and render the package non-buildable?
So yeah, I suppose you either end up requiring newer Rust (but you don't really know which version, since you don't know what's the highest minimal requirement in your dependencies), or you update `Cargo.lock` by hand. Such a great tooling!
https://github.com/samuelcolvin/watchfiles/pull/267#issuecomment-2094753389
Time for your daily dose of #RustLang complaints. Yep, the ecosystem is doing great.
#UV depends on tokio-tar library. Tokio-tar is broken on #PowerPC, doesn't have a bug tracker (!) and seems to be quite dead, with a bunch of PRs ignored since 2022 (last activity mid-2023). Nevertheless, I've filed a PR to fix PowerPC, with little hope that it'll be merged, released and that we could get UV working on PowerPC.
On top of that, it seems that tokio-tar was forked in early 2021 from async-tar. It doesn't seem to have synced the few commits from 2021, and async-tar is dead since late 2021. But at least it has a bug tracker to keep track of how dead it is.
Rewriting stuff in Rust is great. Maintaining it afterwards for the sake of reverse dependencies isn't.
@bdiederik @pbarker those are not mutually exclusive - one can be addicted and enjoy tinkering with #Gentoo and #homeassistant at the same time! :)
This is against TOS. You've been reported.
I get that you're excited to be here, but you gotta follow the rules.
And this isn't it. You're not on AUR. We're building a high quality and well-maintained repository here. This kind of ebuild isn't the vibe we want.
I suppose everyone and their grandmother is now using the xz/sshd exploit to further their own agenda, so I am going to take this opportunity to further mine as well.
1. #Autotools are a bad build system. If configure scripts are completely unreadable, there should be no surprise that people won't notice obfuscated malicious code in there, provided that everything else is obfuscated by design.
2. Static linking and vendoring is bad. Do you know why the prompt #security response was possible? Because we just had to revert to older liblzma. We didn't have to check, patch and re-release hundreds of projects. It wouldn't be this easy with #RustLang and cargo.
3. You can blame #OpenSource for being underfunded and open to abuse in core system packages. However, no IT project can be resilient to a sufficiently powerful bad actor, and that it happened to xz is just an incident. Corporate projects aren't resilient to it, neither is proprietary, closed-source software.
So, embrace #Meson, embrace dynamic linking, embrace distribution packaging and donate to open source developers.
Thank you for giving Arch Linux a run for its money on the intimidation front! You do so well to give users the chance to build a system the way they want to build it. And you’re named after a penguin!
To: @gentoo
From: Fedora
If you want to experience #Gentoo Linux for the first time, or if you are bored with your computer and you miss Gentoo
Let's use Gentoo together, or should I say #GentooGether ? 
It has always be for me the most versatile and performant Linux distro around, it teaches Linux when using it.
Binary packages are now offered but don't cover all needs, so you still compile a bit. 
Gentoo provides great customization, you can enable the exact features you want in your system, which from experience make loading a bit faster (less libs to load).
It's the system where I was able to build the most frankenstein system like a root btrfs system spread across two different LUKS disks 
or where my external GPU just works © all the time
Today in #Gentoo: I've finally tried figuring out why we have so many test failures in #pip with #PyPy. Well, I haven't figure out much — except that pip doesn't respect the temporary test directories somehow (i.e. it's seems to be a bug specific to Gentoo/PyPy, not intentional behavior), and instead wreaks havoc in the venv it installed to. Sigh.
Fun bug in #ZBar discovered while debugging a #SegNo (#Python #QRCode generator library) test failure on #Gentoo with #musl libc.
SegNo defaults to attempting to encode strings as ISO-8859-1 if possible. ZBar defaults to trying to decode them as Big5 first. Most of the time everything works fine.
Let's take a test string from ZBar: "Märchenbücher". When we encode it as ISO-8859-1, we're going to get two high-byte, low-byte sequences: E4 72 for "är" and FC 63 for "üc". The latter sequence maps to a "user defined" character in Big5, and therefore glibc refuses to convert it. However, musl converts it just fine. As a result, ZBar decodes the string as Big5, to "M酺chenb𡡷her".
You could argue that musl behaves wrong. However, note that the former sequence is valid in Big5. So if you shorten the string to just "Märchen", glibc would happily decode its ISO-8859-1 #encoding as Big5, giving you "M酺chen". And yes, if I put that test string into SegNo, I get a QRCode that reproduces the problem on a glibc system.
Does ZBar behave wrong here? Or perhaps SegNo should avoid ISO-8859-1 altogether, and use safer UTF-8 encoding?
https://bugs.gentoo.org/923233
https://github.com/heuer/segno/issues/134
https://github.com/mchehab/zbar/issues/281
It was just an email, rather than an issue or bug and someone took some efforts to look up my mail and to write me. It made me very happy & we should much more honour the work of others! It reminded me of how much we now take software for granted in our daily life. Things we do and handle our daily business... Even if we don't donate anything or only small amounts, we should always show respect for the time and effort of the author and maintainer. Even a small personalized email can bring great joy :)
#opensource #honour #contribute #work #efforts #time
#Salt is true quality software. It even comes with a time bomb that makes old versions suddenly stop working in 2024:
https://github.com/saltstack/salt/blob/d02e2013bebaa55dce0fd54c2c5082d1b5e546f7/salt/log/setup.py#L33-L43
https://922584.bugs.gentoo.org/attachment.cgi?id=882712
(spotted by matoro, thanks!)
Focussing on #FreeBSD, #NETBSD, #OpenBSD, #DragonflyBSD and #helloSystem in the discussions, also all other flavors like #PFSense, #Illumos (#OpenIndiana) are welcome! You’re a #Linux fan (#Ubuntu, #Debian, #RedHat, #NixOS, #Gentoo,…) - just jump in: #BSDCafe:bsd.cafe
More on my blog:
https://gyptazy.ch/blog/bsd-cafe-the-community-for-bsd-systems-freebsd-openbsd-netbsd/