Search
1000 results for “Gentoo_eV”
-
@mgorny The #OpenPGP situation is really sad especially because there is no alternative in sight.
This was also the topic of the round table discussion in the #GentooWorkshop 2025-06-14. Dear community, what do you think? Would you like another meeting to discuss #LibrePGP, #Sequioa-pgp and #GnuPG? Just let us know.
https://gentoo-ev.org/news/online-workshops-2025/ -
@mgorny The #OpenPGP situation is really sad especially because there is no alternative in sight.
This was also the topic of the round table discussion in the #GentooWorkshop 2025-06-14. Dear community, what do you think? Would you like another meeting to discuss #LibrePGP, #Sequioa-pgp and #GnuPG? Just let us know.
https://gentoo-ev.org/news/online-workshops-2025/ -
@mgorny The #OpenPGP situation is really sad especially because there is no alternative in sight.
This was also the topic of the round table discussion in the #GentooWorkshop 2025-06-14. Dear community, what do you think? Would you like another meeting to discuss #LibrePGP, #Sequioa-pgp and #GnuPG? Just let us know.
https://gentoo-ev.org/news/online-workshops-2025/ -
@mgorny The #OpenPGP situation is really sad especially because there is no alternative in sight.
This was also the topic of the round table discussion in the #GentooWorkshop 2025-06-14. Dear community, what do you think? Would you like another meeting to discuss #LibrePGP, #Sequioa-pgp and #GnuPG? Just let us know.
https://gentoo-ev.org/news/online-workshops-2025/ -
@Gentoo_eV Given that I get a KVM console in time, I will demonstrate my installation guide (https://gentoo.duxsco.de/) in English using a #Hetzner dedicated server.
- What? Beyond Secure Boot – Measured Boot on Gentoo Linux?
- When? Saturday, 2024-10-19 at 18:00 UTC (20:00 CEST)
- Where? Video call via BigBlueButton: https://bbb.gentoo-ev.org/
The final setup will feature:
- #SecureBoot: All EFI binaries and unified kernel images are signed.
- #MeasuredBoot: #clevis and #tang will be used to check the system for manipulations via #TPM 2.0 PCRs and for remote LUKS unlock (you don't need tty).
- Fully encrypted: Except for ESPs, all partitions are #LUKS encrypted.
- #RAID: Except for ESPs, #btrfs and #mdadm based #RAID are used for all partitions.
- Rescue System: A customised #SystemRescue (https://www.system-rescue.org/) supports SSH logins and provides a convenient chroot.sh script.
- Hardened #Gentoo #Linux for a highly secure, high stability production environment.
- If enough time is left at the end, #SELinux which provides Mandatory Access Control using type enforcement and role-based access control
-
@Gentoo_eV Given that I get a KVM console in time, I will demonstrate my installation guide (https://gentoo.duxsco.de/) in English using a #Hetzner dedicated server.
- What? Beyond Secure Boot – Measured Boot on Gentoo Linux?
- When? Saturday, 2024-10-19 at 18:00 UTC (20:00 CEST)
- Where? Video call via BigBlueButton: https://bbb.gentoo-ev.org/
The final setup will feature:
- #SecureBoot: All EFI binaries and unified kernel images are signed.
- #MeasuredBoot: #clevis and #tang will be used to check the system for manipulations via #TPM 2.0 PCRs and for remote LUKS unlock (you don't need tty).
- Fully encrypted: Except for ESPs, all partitions are #LUKS encrypted.
- #RAID: Except for ESPs, #btrfs and #mdadm based #RAID are used for all partitions.
- Rescue System: A customised #SystemRescue (https://www.system-rescue.org/) supports SSH logins and provides a convenient chroot.sh script.
- Hardened #Gentoo #Linux for a highly secure, high stability production environment.
- If enough time is left at the end, #SELinux which provides Mandatory Access Control using type enforcement and role-based access control
-
@Gentoo_eV Given that I get a KVM console in time, I will demonstrate my installation guide (https://gentoo.duxsco.de/) in English using a #Hetzner dedicated server.
- What? Beyond Secure Boot – Measured Boot on Gentoo Linux?
- When? Saturday, 2024-10-19 at 18:00 UTC (20:00 CEST)
- Where? Video call via BigBlueButton: https://bbb.gentoo-ev.org/
The final setup will feature:
- #SecureBoot: All EFI binaries and unified kernel images are signed.
- #MeasuredBoot: #clevis and #tang will be used to check the system for manipulations via #TPM 2.0 PCRs and for remote LUKS unlock (you don't need tty).
- Fully encrypted: Except for ESPs, all partitions are #LUKS encrypted.
- #RAID: Except for ESPs, #btrfs and #mdadm based #RAID are used for all partitions.
- Rescue System: A customised #SystemRescue (https://www.system-rescue.org/) supports SSH logins and provides a convenient chroot.sh script.
- Hardened #Gentoo #Linux for a highly secure, high stability production environment.
- If enough time is left at the end, #SELinux which provides Mandatory Access Control using type enforcement and role-based access control
-
@Gentoo_eV Given that I get a KVM console in time, I will demonstrate my installation guide (https://gentoo.duxsco.de/) in English using a #Hetzner dedicated server.
- What? Beyond Secure Boot – Measured Boot on Gentoo Linux?
- When? Saturday, 2024-10-19 at 18:00 UTC (20:00 CEST)
- Where? Video call via BigBlueButton: https://bbb.gentoo-ev.org/
The final setup will feature:
- #SecureBoot: All EFI binaries and unified kernel images are signed.
- #MeasuredBoot: #clevis and #tang will be used to check the system for manipulations via #TPM 2.0 PCRs and for remote LUKS unlock (you don't need tty).
- Fully encrypted: Except for ESPs, all partitions are #LUKS encrypted.
- #RAID: Except for ESPs, #btrfs and #mdadm based #RAID are used for all partitions.
- Rescue System: A customised #SystemRescue (https://www.system-rescue.org/) supports SSH logins and provides a convenient chroot.sh script.
- Hardened #Gentoo #Linux for a highly secure, high stability production environment.
- If enough time is left at the end, #SELinux which provides Mandatory Access Control using type enforcement and role-based access control
-
@Gentoo_eV Given that I get a KVM console in time, I will demonstrate my installation guide (https://gentoo.duxsco.de/) in English using a #Hetzner dedicated server.
- What? Beyond Secure Boot – Measured Boot on Gentoo Linux?
- When? Saturday, 2024-10-19 at 18:00 UTC (20:00 CEST)
- Where? Video call via BigBlueButton: https://bbb.gentoo-ev.org/
The final setup will feature:
- #SecureBoot: All EFI binaries and unified kernel images are signed.
- #MeasuredBoot: #clevis and #tang will be used to check the system for manipulations via #TPM 2.0 PCRs and for remote LUKS unlock (you don't need tty).
- Fully encrypted: Except for ESPs, all partitions are #LUKS encrypted.
- #RAID: Except for ESPs, #btrfs and #mdadm based #RAID are used for all partitions.
- Rescue System: A customised #SystemRescue (https://www.system-rescue.org/) supports SSH logins and provides a convenient chroot.sh script.
- Hardened #Gentoo #Linux for a highly secure, high stability production environment.
- If enough time is left at the end, #SELinux which provides Mandatory Access Control using type enforcement and role-based access control
-
@Gentoo_eV I linked your announcement at the top of every page at:
https://gentoo.duxsco.de/ -
@Gentoo_eV I linked your announcement at the top of every page at:
https://gentoo.duxsco.de/ -
@Gentoo_eV I linked your announcement at the top of every page at:
https://gentoo.duxsco.de/ -
@Gentoo_eV I linked your announcement at the top of every page at:
https://gentoo.duxsco.de/ -
@Gentoo_eV I linked your announcement at the top of every page at:
https://gentoo.duxsco.de/ -
Zwei Tage super-tolle @FrOSCon liegen hinter mir mit einem unglaublich erfolgreichen Workshop-Angebot von @Gentoo_eV und @TroLUG!
Die ansteckend-positive Stimmung hat mir unglaublich gut getan, und ich nehme viele Anregungen und Ideen mit.
Danke an @derRainer, @stefan, @thoker und die anderen MitstreiterInnen des DevRooms!
-
Ahoi!
Ich bin #neuhier und hänge gern ab im #suckless Terminal zum #shsex all night long.
Ich mag #turnschuhadministration über SASS & PASS Lösungen und Quellcode statt BLOBs & shell statt subscription traps!Ich SSH'e durch die Open-Source-Unterwelt, bin #bitreich, @Codeberg und @Gentoo_eV lover & pusher!
Ich entwickle und unterstütze #selfhost Softwareprojekte, um Selbstbestimmung, Freiheit und Sicherheit zu stärken.
Ich freue mich auf neue Bekanntschaften und einen konstruktiven Austausch.
-
📅 Saturday, 2025-10-25 at 18:00 UTC (20:00 CEST) #GentooWorkshop
👤 David Sardari (https://fedifreu.de/@duxsco) proposes: “Idea of secure 3rd party overlay use”
Gentoo’s #overlay system is powerful, but trusting 3rd party overlays has always been a risk. David’s idea? Introduce a secure framework for verifying and sandboxing overlays - think signed metadata and isolated build environments.
💬 Thoughts from fellow Gentoo users? Would you adopt overlays more freely with stronger #security guarantees?
-
Der #Gentoo e.V. bereitet sich mit Volldampf auf die #FrOSCon vor.
#DevRoom organisieren, #Workshops planen, Flyer neu erstellen, 📦Font paketieren.
😍 Gefällt Dir? Sende heute noch Deinen Mitgliedsantrag ab und unterstütze unsere Arbeit
💡 Gute Ideen zur Förderung von Gentoo?
💌 Schick sie schnell an den Vorstand! -
Juhu, der Schutz der :gentoo: Marke wurde für Europa verlängert – bis 2035! 👍 Eine der zentralen Aufgaben des Fördervereins Gentoo e.V. ist der Schutz der Marke Gentoo im Europäischen Wirtschaftsraum. 🇪🇺
Herzlichen Dank an Rechtsanwalt Martin Schick und unseren Vorsitzenden @ulm für ihren Einsatz! 💜
https://register.dpma.de/DPMAregister/marke/register/305460625/DE
-
Gentoo Linux: because who doesn't love spending New Year's Eve compiling their entire OS from scratch? 🎉🔧 Let's celebrate 2026 by pretending Gentoo is still relevant, while the rest of the world enjoys systems that just work™. 😂💻
https://www.gentoo.org/news/2026/01/05/new-year.html #GentooLinux #NewYearsEve #CompilingFromScratch #TechHumor #JustWorks #HackerNews #ngated -
The previous evening I was doing yet another experiment with safe transition from 32-bit to 64-bit #time_t in #Gentoo. This time I was trying a different approach — rather than changing libdir for the time64 ABI permanently, moving the time32 libraries into a temporary directory for the transition time.
The idea was that we move all old libraries to libt32, and we add RUNPATH to all old binaries to make them capable of finding these libraries. Then, as libraries were rebuilt, Portage would keep old copies in libt32 for as long as they were necessary (through preserved-libs), and then remove them as soon as all reverse dependencies were rebuilt. Unfortunately, even though I hacked hard, I wasn't able to convince Portage to stop treating time64 and time32 libraries as equivalent, and therefore remove the latter immediately after rebuilt.
I was close to thrashing the idea entirely, but near three o'clock in the morning I woke up with another idea — and one much simpler at that. Sure, add RUNPATH to binaries; sure, move the libraries — but without updating the vardb, leaving them out of Portage's control. As packages are rebuilt, Portage will not be removing anything from libt32, and newly built programs, no longer having the RUNPATH injected, would simply stop using libt32 libraries. And when all rebuilds are done, the user can just remove libt32 wholesale.
In the end, it's less work for me (no need to update vdb), and fewer moving parts. What remains is determining which binaries should have their RUNPATHs (already learned the hard way that you can't alter all of them), write a script to inject them and move the libraries, and then try another experiment.
-
One gentoo species, Nope Four
Scientists provided genetic evidence that what was once thought to be one widely dispersed species - including three subspecies - is actually four separate species of gentoo penguin. So, one of these was previously even unrecognised. Because, as it turns out they all look alike: a white underside and black back, but they are clearly genetically different. What scientists refer to as a cryptic species.
#biodiversity #gentoo #penguin #specieshttps://phys.org/news/2026-05-scientists-gentoo-penguins-species-totally.html
-
Every time #Emerge by #Fischerspooner comes up in my ears I think of #Gentoo.
> You don’t need to emerge from nothing 🎵
But you kinda do..
-
Our next Speaker Spotlight for #EverythingOpen is Alice Ferrazzi - @alicef - who works with @gentoo.
In this talk, Alice will provide a status update on the #kernelci project.
-
Testing the CalamaroOS on my old laptop.
For some reason, it sees EVERY single WiFi network around, EXCEPT of 2 networks at the office that I have access to 🙂 Strange.
Other than that, it's just a #gentoo
--- building package 25 of 27 - media-video/vlc
-
So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.
-
So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.
-
So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.
-
So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.