[gentoo-dev] news item and patch series: 2024-05-10-perl-features-use-expand.en.txt
Newsitem for review... This goes back to discussions long ago with Kent. We weren't sure then if Portage can handle it. However, since it can handle Python... :P Binary package support now makes the USE_EXPAND hard-necessary. The corresponding patch series is following in a few minutes as reply. Title: dev-lang/perl useflags become a PERL_FEATURES use-expand Author: Andreas K. Huettel Posted: 2024-05-10 Revision: 1 News-Item-Format: 2.0 Starting with dev-lang/perl-5.38.2-r3, the three use flags "debug", "ithreads", and "quadmath" of Perl are renamed into a common use-expand variable, PERL_FEATURES, which should be set *globally* in make.conf. If you do *not* want to change the settings of your Perl, make sure that the new variable PERL_FEATURES contains the same settings that were applied to your Perl all along. I.e., if you have dev-lang/perl[ithreads] installed, make sure to now set in make.conf PERL_FEATURES="ithreads" If you *want* to change the settings of your Perl, make sure to run perl-cleaner after rebuilding dev-lang/perl: perl-cleaner --modules ; perl-cleaner --force --libperl Background: This change in the structure of the useflags is a first step towards a solution of bug 930123. The three useflags influence not only how Perl itself is installed, but also all Perl modules... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Update on the 23.0 profiles
> I see no way of migrating to 23.0 profile because of not-recompilable > packages that are installed (over 4 years) which block --emptytree, > and do not wish to be forced to migrate to merged-usr on an openrc box > without a compelling need (on principle). That sounds a bit like self-inflicted pain. > Will patching back the 17.0 profile files into the portage tree if and > when they are removed work? Unknown. > Are there any options at all for this situation (like freezing the the > last supported tree protecting it from emerge-syncs, and using an > overlay for further updates?) You can try to just skip these packages (with --exclude) during the "emerge --emptytree ..." step. It should work, but no guarantees given. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Update on the 23.0 profiles
Am Sonntag, 7. April 2024, 14:51:55 CEST schrieb Michael Orlitzky: > On Sun, 2024-04-07 at 14:35 +0200, Andreas K. Huettel wrote: > > > > Uhh, I dont really remember, I think some Chinese-sounding guy asked > > me for it... (j/k) > > It is remarkably bad timing. How it looks: Gentoo's response to the xz > incident is to have me rebuild my entire system with everything that > could possibly be linked to liblzma, linked to liblzma. Even on the > hardened profiles, and with no easy way to prevent it. Well, we're now working with the best-audited compression library ever, I guess. > tl;dr can we turn them back off in the profile? In any scenario where > they are beneficial, there's a better place to put them. Easily doable with lzma, if there is consensus for it. Slightly more complex for zstd since this affects gcc and binutils. Still doable though. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Update on the 23.0 profiles
Am Sonntag, 7. April 2024, 04:03:01 CEST schrieb Michael Orlitzky: > On Sat, 2024-04-06 at 17:06 +0200, Andreas K. Huettel wrote: > > Hi all, > > > > so here's a small update on the state of the 23.0 profiles: > > > > Why was this silently added to make.defaults for all 23.0 profiles? > > > # This just makes sense nowadays, if only for distfiles... > > USE="lzma zstd" Uhh, I dont really remember, I think some Chinese-sounding guy asked me for it... (j/k) Jokes aside, we did have bz2 in the default useflags for ages, and at the time this made a lot of sense since xz/lzma and zstd were steadily becoming the most prevalent compression algorithms. And for anyone interested in the timeline, this was one of the first additions. commit 99a7cb9e0b1728ca75242ddfee6357dc008bd1cd Author: Andreas K. Hüttel AuthorDate: Sun Nov 13 19:26:40 2022 +0100 Commit: Andreas K. Hüttel CommitDate: Sun Nov 13 19:27:36 2022 +0100 profiles: Set USE="xz zstd" in 23.0 -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Update on the 23.0 profiles
> > Most 17.x profiles have been downgraded to "exp". > > I could imagine there is a reason to downgrade those back to 'exp', > could you elaborate a bit on that? > > Isn't it bit strange that a 'stable' profiles gets downgraded back to > 'exp'? Then again, I am not sure about the implications of this nor > about the rationale behind it. Mostly so the load on the CI does not suddenly double. There's no real reason why we can't keep a few of the profiles stable. Also not much reason to do that though... > > However, I also notice that there is a outstanding PR that reverts that > [1]. Maybe we should introduce a new state 'oldstable' or so? > > - Flow > > > 1: https://github.com/gentoo/gentoo/pull/35871 > -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Update on the 23.0 profiles
Hi all, so here's a small update on the state of the 23.0 profiles: * For all arches, the 23.0 profiles are now marked at the same stability status (mostly for the CI and pkgcheck) as before the 17.x profiles. Most 17.x profiles have been downgraded to "exp". * All stage downloads (with the exception of hppa, where our builder is a tad slow) are now based on 23.0. * For all ISO / other boot media, the specs have been changed as of today, so that the next succeeding build will also be based on 23.0. The new builds need testing, so if you happen to have suitable hardware around... * With that we can nail down the timetable for the next steps: 2024-06-06 (in 2 months): deprecation of the 17.x profiles; binpkg builders for the 17.x profiles are stopped 2025-06-06 (1 year later): removal of the 17.x profiles from profiles.desc -??-?? (when infra has moved :o): removal of the 17.x profile trees in gentoo.git Comments and feedback welcome. I would really prefer to *not* extend the time until deprecation though, since maintenance (and CPU time) goes down as soon as we don't build twice the amount of packages... In general, our installation ISO need in my opinion some review regarding the package set and the detailed build instructions. As long as they work that is not really urgent though. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Profile 23.0 testing with stages and binhost (part 2 of 2)
Am Samstag, 16. März 2024, 13:12:04 CET schrieb Duncan: > Andreas K. Huettel posted on Fri, 15 Mar 2024 19:12:54 +0100 as excerpted: > > > Note 3: amd64 now has CET turned on by default. > > https://docs.kernel.org/next/x86/shstk.html If you have already used the > > unannounced 23.0 profiles, you should wipe your package cache and emerge > > -ev world now. > > There's not much about CET in any of the links. While the kernel.org link > describes what it does (in a line, "yese": yet another security > enhancement) a bit, it doesn't say how to actually find whether your > hardware supports it, and the gentoo wiki and bug links say even less -- > in particular, unless I missed it, the changes and update instructions > links don't appear to mention CET or shadow-stacks AT ALL. That's because it was a last-minute addition, and not particularly well thought through. :| Ignore Note 3. The part about emerge -ev world is just plain wrong for now. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Profile 23.0 testing with stages and binhost (part 2 of 2)
> > Note 2: While there are 23.0 split-usr profiles, the *stage* downloads > > are *all* of the merged-usr type. Why? Not because I'm a big fan of that, > > but because we should try to unify and standardize a bit again - to > > avoid too many different build configurations leading to too many > > Heisenbugs. > > I don't think this is a good idea. > > We've promised people that they can keep unmerged-usr if they want, And they can. [However, I don't see the point for it. Apart from ideological considerations, there is no obvious advantage to the split-usr layout anymore.] > but not having stages means new installs aren't doable, Yes. > and it also makes testing a pain because you can't easily unmerge. > You can easily merge, but you can't easily unmerge. That is the imho more important and valid point, maintaining the remaining split-usr installs will get harder. > What you can do is provide a limited number of non-merged-usr variants > given it's just about saving people rebuilds. For amd64 and arm64 that's doable (since builds are cheap there). I would very much discourage using these variants for new installs though. [And yes I would prefer to deprecate the split-usr profiles and remove them at some point in the not-so-far future. That is however a topic that needs separate debate.] > (I also think it's the wrong way to do such a change anyway - the releng > part should be last after decision-making, not first.) The decision where this is going has been made long ago... just not by us because we've been lagging behind. But I get what you mean. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] mirror storage growth rate
Hi Jaco, * we have more stages * the binary packages have to go somewhere * and, temporarily, things are duplicated due to the 17.x / 23.0 profile transition The third point will eventually go away. However, I'm not sure how much it actually contributes. https://www.akhuettel.de/~huettel/plots/mirrors.php If you look at the plots, the distfiles part is surprisingly large. Binary packages (17.x and 23.0) and 17.x stages are under "releases". The 23.0 stages for testing are under "experimental". Lastly, I'm still working on an automated cleanup for outdated "small arches" binary packages (i.e. not arm64 and amd64, these are cleaned automatically already). This just wasn't a priority so far. Hope this helps. -a Am Freitag, 15. März 2024, 09:06:36 CET schrieb Jaco Kroon: > Hi All, > > I was messing with some storage related caching on some of our hosts > this morning when I wondered about how much storage the gentoo mirrors > were consuming. I'm not too worried about the current storage, but I am > noticing that the storage requirements are creeping quite a bit (as per > attached), and if that growth rate continues it may become a problem > *eventually*. > > Can this growth be explained? > > Is it expected to continue at this rate? > > Kind regards, > Jaco > -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Profile 23.0 testing with stages and binhost (part 2 of 2)
Hi all, the 23.0 profiles are ready for testing, including stage downloads, binary packages, and update instructions for existing installations, for all arches. IMPORTANT Exception IMPORTANT ** musl on (32bit) arm and x86 does NOT work yet (gcc build failure) ** IMPORTANT Update instructions IMPORTANT https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions Stage downloads (temporarily, for all arches): [preferably] https://distfiles.gentoo.org/experimental/x86/23.0_stages/ [direct/osu] https://gentoo.osuosl.org/experimental/x86/23.0_stages/ The changes can be seen here https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_transition and the timeline so far here https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_timeline The update instructions also double as the news item that should be published max. 1-2 weeks from now. They are mostly unchanged compared to my last e-mail, just some wording has been clarified. Note 1: The next steps are, now really in 1-2 weeks max: * make 23.0 profiles the same stability level as 17.x profiles, * degrade 17.x profiles all to exp (so the CI doesn't explode) * publish news item * replace stage downloads with 23.0 version (in situ) Note 2: While there are 23.0 split-usr profiles, the *stage* downloads are *all* of the merged-usr type. Why? Not because I'm a big fan of that, but because we should try to unify and standardize a bit again - to avoid too many different build configurations leading to too many Heisenbugs. Note 3: amd64 now has CET turned on by default. https://docs.kernel.org/next/x86/shstk.html If you have already used the unannounced 23.0 profiles, you should wipe your package cache and emerge -ev world now. Note 4: arm64 does *not* have its equivalent turned on yet since we encountered last-minute problems (guess what, gcc build failure). Note 5: There are no hppa builds yet since our machine is still busy. One gcc build takes about a week there. Cheers & have fun, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
Am Dienstag, 27. Februar 2024, 15:45:17 CET schrieb Michał Górny: > Hello, > > Given the recent spread of the "AI" bubble, I think we really need to > look into formally addressing the related concerns. In my opinion, > at this point the only reasonable course of action would be to safely > ban "AI"-backed contribution entirely. In other words, explicitly > forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to > create ebuilds, code, documentation, messages, bug reports and so on for > use in Gentoo. Fully agree and support this. > > Just to be clear, I'm talking about our "original" content. We can't do > much about upstream projects using it. [...] or implementing it. So, also, no objections against someone (a real person, by his own mental means) packaging AI software for Gentoo. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Profile 23.0 news item (was: Re: Profile 23.0 testing with stages and binhost (part 1 of 2))
News item / update instructions draft:
Title: Profile upgrade to version 23.0 available
Author: Andreas K. Huettel
Posted: -mm-dd
Revision: 1
News-Item-Format: 2.0
Display-If-Keyword: alpha
Display-If-Keyword: arm
Display-If-Keyword: ia64
Display-If-Keyword: loong
Display-If-Keyword: m68k
Display-If-Keyword: ppc
Display-If-Keyword: ppc64
Display-If-Keyword: riscv
Display-If-Keyword: s390
Display-If-Keyword: sparc
Display-If-Keyword: x86
[*** Ignore this message for now if you are using musl.
musl profiles and stages are not ready yet. ***]
A profile upgrade to version 23.0 is available for your architecture.
The new 23.0 profiles enable some toolchain hardening features and
performance enhancements by default, and standardize settings.
You can find the list of changes on the wiki tracking page [1].
We strongly advise to precisely follow the upgrade instructions found
below. The 17.0, 17.1, 20.0, and 22.0 profiles will be marked deprecated
in 2 months and removed a year later. The exact dates depend on the
architecture, see [2].
Upgrade instructions
Note 1: The use of binary packages is completely optional, and also not
as much tested as the source-based upgrade path yet. If you prefer to
only use the traditional source-based installation, omit the "--getbinpkg"
parameter in all emerge invocations.
Note 2: If you have manually changed your CHOST to a value different from
what the stages and profiles set, you may have to do that in the future too.
In that case you should know what you are doing, hopefully; please read the
instructions with a critical eye then.
1. Ensure your system backups are up to date. Please also update
your system fully and depclean before proceeding.
glibc older than 2.36 and musl older than 1.2.4 is not supported anymore.
2. If you are still using one of the long-deprecated amd64 17.0 profiles
(other than x32 or musl), then first complete the migration to the
corresponding 17.1 profile. Instructions can be found at [3].
3. If you are currently using systemd in a split-usr configuration, then first
complete the migration to the corresponding merged-usr profile of the
same profile version. Details on how to do this can be found in the news
item [4].
4. Run "emerge --info" and note down the value of the CHOST variable.
5. Edit /etc/portage/make.conf; if there is a line defining the CHOST variable,
remove it. Also delete all lines defining CHOST_... variables.
6. Select the 23.0 profile corresponding to your current profile, either using
"eselect profile" or by manually setting the profile symlink.
Note that old profiles are by default split-usr and the 23.0 profiles by
default merged-usr, i.e. example upgrades are
default/linux/amd64/17.1==>
default/linux/amd64/23.0/split-usr
default/linux/amd64/17.1/systemd/merged-usr ==>
default/linux/amd64/23.0/systemd
A detailed table can be found at [5].
In rare cases (hppa, x86) the table will tell you to pick between two
choices.
What you need should be obvious from your *OLD* CHOST value (from step 4).
7. Delete the contents of your binary package cache at ${PKGDIR}
rm -r /var/cache/binpkgs/*
8. In the file or directory /etc/portage/binrepos.conf (if existing), update
the URI in all configuration such that they point to 23.0 profile binhost
directories. The exact paths can be found in the table at [5], too.
9. Rebuild or reinstall from binary (if available) the following packages in
this order, with the same version as already active:
emerge --ask --oneshot --getbinpkg sys-devel/binutils
(you may have to run binutils-config and re-select your binutils now)
emerge --ask --oneshot --getbinpkg sys-devel/gcc
(If this command fails because of mismatched "openmp" useflag requirements,
make sure you have FEATURES=preserved-libs enabled, ignore the advice given
by emerge, and try again with only --nodeps added to the command line.)
(you may have to run gcc-config and re-select your gcc now)
and the C library, i.e. for glibc-based systems
emerge --ask --oneshot --getbinpkg sys-libs/glibc
or for musl-based systems
emerge --ask --oneshot --getbinpkg sys-libs/musl
10. Re-run "emerge --info" and check if CHOST has changed compared to step 3.
If the CHOST has NOT changed, skip to step 13 (env-update). Otherwise,
11. Recheck with binutils-config and gcc-config that valid installed versions
of binutils and gcc are selected.
12. Check /etc/env.d, /etc/env.d/binutils, and /etc/env.d/gcc for files that
refer to the *OLD* CHOST value, and remove them.
Examples how to do this can be found in the similar procedure at [6].
13. Run env-update && source /etc/profile
14. Re-emerge libtool:
emerge --ask --oneshot --getbinpkg libtool
15. Just for safety, delete the contents of your binary package ca
[gentoo-dev] Profile 23.0 testing with stages and binhost (part 1 of 2)
Hi all, for the following arches (and only these) ** GLIBC: ** alpha, arm, ia64, loong, m68k, ppc, ppc64, riscv, s390, sparc, x86 ** MUSL: ** riscv the 23.0 profiles are ready for testing, including stage downloads, binary packages, and update instructions for existing installations. IMPORTANT Draft update instructions IMPORTANT https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions Stage downloads (temporarily, for all listed arches): [preferably] https://distfiles.gentoo.org/experimental/x86/23.0_stages/ [direct/osu] https://gentoo.osuosl.org/experimental/x86/23.0_stages/ The changes can be seen here https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_transition and the timeline so far here https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_timeline Please try things out, and file bugs if you encounter problems. In particular, also double-check the documentation - the update path table was a lot of manual work, and it's not impossible that C-C / C-V went wrong somwhere. The update instructions also double as the news item that should be published 2 weeks from now on these arches (unless there are unexpected problems). I'll reply to this e-mail with a separate mail containing the full text, for easier discussion. Note 1: The next steps are, in 2 weeks: * make 23.0 profiles the same stability level as 17.x profiles, * degrade 17.x profiles all to exp (so the CI doesn't explode) * publish news item * replace stage downloads with 23.0 version (in situ) Note 2: Musl is still missing out on *stable* arches, since this requires musl-1.2.4 stable. Note 3: The remaining arches follow when they are ready. Why are they not ready? * amd64: comes last :) * arm64: bug #916381 still needs to be implemented * hppa: slow hardware (one gcc build takes ~1 week) * mips: slow qemu emulation (one gcc build takes ~1 day), many variants and complex profile structure * musl on stable arches: needs musl-1.2.4 stable Cheers & have fun, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Block ebuilds installing tests to ${D} by default
Am Donnerstag, 1. Februar 2024, 09:15:39 CET schrieb Robin H. Johnson:
> TL;DR:
> I'd like to propose a change where packages should NOT install their
> tests to ${D} by default. Such an install may optionally enabled with
> USE=test, which should be decoupled from FEATURES=test. Or depending on
> the color of the bikeshed, we add something new like USE=install-tests.
I see where you come from, but the decision what precisely to install
(when we do not follow upstream) can be very non-trivial.
I'm not familiar with Python, but for Perl there is quite some test
infrastructure in the main Perl package... Then there are regular
Perl packages that are extensions to the test suite. These would require
the test modules from core Perl then? I really wouldnt want to figure
out what to keep and what to drop, and spend a lot of effort getting
the dependencies right.
Also this is an infinite source of upstream "It's Gentoo, we don't
support that because they do weird stuff" bugs.
tl;dr: no
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] global USE=gpg
> > we have many local gpg useflags which basically just enable gpg. > > Should we merge these to one global useflag? > > > > Additionally we have a few gpgme useflags. > > See also https://bugs.gentoo.org/679634 > > > > What are your ideas? > > > > We have also have a bunch of USE=pgp and USE=openpgp, both of which are > more correct than USE=gpg. Yeah, typical case of "formally correct thing being way more difficult to understand than colloquially practical thing" ... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Official binary package hosting
Hi all, you may have already seen the announcement on the www.gentoo.org front page- our binary package hosting finally went "officially live". https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html From the announcement: "To speed up working with slow hardware and for overall convenience, we’re now also offering binary packages for download and direct installation! For most architectures, this is limited to the core system and weekly updates - not so for amd64 and arm64 however. There we’ve got a stunning >20 GByte of packages on our mirrors, from LibreOffice to KDE Plasma and from Gnome to Docker. Gentoo stable, updated daily." If you would like to have a package included in the amd64/arm64 builders, please check if it builds on one of the named profiles without any useflag changes. If yes, drop me an e-mail or suggest it on #gentoo-binhost. At this place I'd also like to thank everyone who contributed and helped to make this possible, from the GPG signature support and Portage improvements all the way to the implementation on the Infra side. Cheers & Enjoy! -a -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Update on 23.0 profiles
> > Wait, does this mean that split-usr will be gone soon? > Define soon. It took us 6 years to come up with new profiles. Guess how long the next ones will take. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] Update on 23.0 profiles
> 1. The [4]/[5] probably should list full domain name rather than g.o Yes, but the wiki does not allow full links into itself. Will be fixed in the final news item. > 2. According to 23.0_update_table, my non-systemd > default/linux/amd64/17.1/desktop/plasma should now be > default/linux/amd64/23.0/split-usr/desktop/plasma. Correct. > But that name looks > like merged-usr is now considered "better" than split-usr, as it has to > be specifically mentioned in the profile name. I'd prefer "more standard", "more common", "more usual" ... It'll definitely soon be the configuration where software is (globally) more tested, independent of what Gentoo does. (if that is not already the case now...) > Therefore I probably should migrate to merged-usr. You can migrate after the profile upgrade, but you don't have to. No hurry. > But the only instruction how to do that > assumes systemd. https://wiki.gentoo.org/wiki/Merge-usr Doesn't mention systemd anywhere. I'll update this page a bit mentioning the new naming scheme in 23.0, and link it in the news item. > And there's no plasma profile with merged-usr but > without systemd anyway... except that there is: > default/linux/amd64/23.0/desktop/plasma, it's just not mentioned in the > table. It's fairly simple: * In 17.x, every systemd split-usr profile has a corresponding merged-usr profile * In 23.0, every split-usr profile has a corresponding merged-usr profile Cheers -a -- PD Dr. Andreas K. Huettel Institute for Experimental and Applied Physics University of Regensburg 93040 Regensburg Germany tel. +49 151 241 67748 (mobile) tel. +49 941 943 1618 (office) e-mail andreas.huet...@ur.de https://www.akhuettel.de/ https://www.akhuettel.de/group/
Re: [gentoo-dev] Update on 23.0 profiles
Am Sonntag, 26. November 2023, 17:50:22 CET schrieb Alex Boag-Munroe: > On Sat, 25 Nov 2023 at 23:27, Andreas K. Huettel wrote: > > > * A draft upgrade document exists. > > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions > > I can't edit the draft so just to mention here, there's references > made to an update table at > https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_table > however in the text the cited source is tagged as [4] but it should be ... Thank you, fixed! -a -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Update on 23.0 profiles
Hi all, here's a brief update on the upcoming 23.0 profiles. * All planned features are implemented (but not necessarily tested). https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_transition * A draft upgrade document exists. https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_instructions Unless something important comes up over the next 7 days (and I mean you, worthy mailing list readers :), I consider the feature set now frozen. Which means, in a week we can start testing this in earnest. The next step will be to create "exp" profile entries, migrate seeds, and start up stage builds on all arches (in parallel to the existing builds and for now not linked on the webpages yet). Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] media-video/mpv removed USE flag
Am Mittwoch, 22. November 2023, 00:33:18 CET schrieb stefan1@shitposting.expert: > I've noticed that on my last @world update, mpv's libplacebo USE flag > got removed and portage pulled in libplacebo. > Was there any reason behind this change? Special request by Placebo Domingo. > Mpv has been working perfectly > fine so far without libplacebo. > > -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: app-editors/fte
+# Andreas K. Hüttel (2023-10-28) +# Fails to build with glibc-2.38 (and musl). No maintainer. +# Removal on 2023-11-28. Bug #713402 +app-editors/fte + -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites (kinda, long masked): sys-apps/opentmpfiles
# Andreas K. Hüttel (2021-07-06, 2023-09-15) # No longer maintained upstream; masked everywhere for two years now. # Please see also the 2021-07-15-opentmpfiles-deprecation news item. # https://www.gentoo.org/support/news-items/2021-07-15-opentmpfiles-deprecation.html # # The replacement is sys-apps/systemd-utils[tmpfiles]; new name # but otherwise identical to the solution described in the news item. # Removal on 2023-10-15. sys-apps/opentmpfiles -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] last rites: sys-fs/eudev
> >> I'm an outsider to Gentoo development (just a heavy user for over a > >> decade both personally and professionally) so I might have missed > >> something. I just find it puzzling. > > > > I'm not puzzled by what is going on, or by your email, because it > > happens basically anytime a high-profile package is treecleaned. Yes, > > Gentoo is about choice, but somebody has to actually do work to make > > the choices viable. There are always more people interested in using > > software than maintaining it. The frustration is completely > > understandable, but also kinda unavoidable. > > It starts to bother me that so many people straight away assume that when > someone questions things it's because they are a frustrated user The eudev experiment has failed. * It was false labeling from the start.[*] * It's barely alive and not keeping up with udev upstream. * It's effectively unmaintained in Gentoo. * You don't gain anything from using it instead of udev. (Nobody does.) So why should anyone put up the effort to package it? [*] Take something out of the systemd tarball, reapply every commit, make tiny changes so it looks different, sell it to the anti-systemd crowd. Sadly no profit, since open source... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] last rites: sys-fs/eudev
Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: > Upstream is maintained still. > > https://github.com/eudev-project/eudev > No, it's not. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: sys-fs/eudev
# Andreas K. Hüttel (2023-09-11) # Dead project accumulating open bugs and incompatibilities. # No maintainer commits since February 2021. # Bugs 673834, 713106, 753134, 667686, 771705, 668880, 770358, 851255, # 711462, 904741, ... Removal in 30 days. sys-fs/eudev -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] adding sec-keys/openpgp-keys-gentoo-release to @system
Dear all, I'd like to add sec-keys/openpgp-keys-gentoo-release to @system - any objections? The package contains a single file (~20k) with the public keys used for stage, manifest, and binpackage signing. This is more of a formal request since portage already depends on it anyway, and the package is present in every stage3. However, it in my opinion makes sense to explicitly state that it needs to be present. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What happened to gcc-12.3.0?
Am Donnerstag, 15. Juni 2023, 06:02:14 CEST schrieb Joshua Kinard: > > Noticing that the ebuild for gcc-12.3.0 got dropped with little explanation. > It is the upstream stable > release. I am eyeballing #906310 as what may have triggered the drop, but I > find it a bit of a stretch ... This is for exactly the same reason as why we don't have glibc-2.36(-r0) or 2.37(-r0) in the tree anymore. There's a stable upstream branch which accumulates bug and security fixes. The only real difference is naming, but I could switch to glibc-2.36_p20230615 too... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-announce] Gentoo Services Migration: Bugzilla, Forums, Wiki
> > Just keep in mind that CI can't search for open bugs on bugzilla (because of > a down of > course), so bugs that have already been reported in the past, may be reported > on github > too, but from my perspective is better have few duplicates rather than > unnoticed bugs > that may reach the end users. > Jesus. Please just stop it for three days, instead of wasting everyone's time. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Various packages up for grabs (avahi, curl, fcron, tor...)
> > acct-group/cron > acct-group/fcron > acct-user/cron > acct-user/fcron > dev-libs/libelf > net-misc/curl > sys-process/cronbase > sys-process/fcron > virtual/cron > virtual/libelf > These should probably go to base-system -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] 23.0 profiles - which features?
Hey all, in the past I already sent a mail about features for a next profile version. The feedback was rather limited, but anyway we got quite a list of ideas. The general tracker is bug 876891. In the following I would like to put up the various features for discussion, in order of bug number... Feedback very welcome. Cheers Andreas https://bugs.gentoo.org/515694 Bug 515694 - Update MIPS profiles to use ABI-specific CHOST values for clang/llvm compatibility Affects only mips profiles. Should eventually be done, I guess? https://bugs.gentoo.org/675050 Bug 675050 - [toolchain] Enable GCC's -fstack-clash-protection for all profiles in Gentoo by default https://bugs.gentoo.org/792081 Bug 792081 - rename no-multilib to nomultilib, also in profile names Apparently this simplifies things for some people, and a new profile is a good chance to do the cosmetic change. https://bugs.gentoo.org/818376 Bug 818376 - [toolchain] Adopt SHT_RELR/DT_RELR relative relocation format *very* new feature... https://bugs.gentoo.org/831045 Bug 831045 - profiles: remove USE=cli default and inline into ebuilds Easy. https://bugs.gentoo.org/849875 Bug 849875 - profiles: remove USE=dri default, clean up make.defaults Also easy. https://bugs.gentoo.org/876879 Bug 876879 - separate openrc and systemd features, not one overriding the other Right now all profiles inherit openrc-specific settings, and these are then again negated and/or overridden in the systemd profiles. Sorting this more cleanly would be nice. https://bugs.gentoo.org/876881 Bug 876881 - make merged usr the default configuration With the next profile version, the "default" setting (default/linux/XX.X/amd64) is a merged usr profile, while the old layout is still present as a split-usr feature. Not sure if this is worth the trouble. https://bugs.gentoo.org/876883 Bug 876883 - [tracker] time64 migration Needed. https://bugs.gentoo.org/876893 Bug 876893 - [toolchain] Adopt -D_FORTIFY_SOURCE=3 for hardened by default https://bugs.gentoo.org/876895 Bug 876895 - [toolchain] Adopt -D_GLIBCXX_ASSERTIONS for hardened by default -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
> Once again new council has been elected: congratulations to the chosen > members! And once again many nominees expressed their wishes to see more > non-developer contributors to become official developers. Yet, only very > few people (if any) are interested in mentoring them. I get it, the > relationship between a mentor and their mentee is very intimate, and > mentoring takes a lot of time. While the Github PRs are helping us > increase the user contributions merged, perhaps it's distancing us from > creating stronger bonds with the contributors? But more about this topic > later. Actually, we are doing quite well in terms of recruiting at the moment. I would love to see this continue. And yes, mentors are important for that. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
> > 2nd RFC: Recruiting proven contributors without a mentor > > I'm aware recruiters don't really need to ask a permission here, but I > believe it's great to gauge the general feelings about this beforehand. > What would you say if recruiters started more actively approaching > potential developers? And currently I'm talking about people who have > been active for a very long time (+year or two), who keep up with > development-wise changes in Gentoo (eclasses, EAPI, virtuals...), > participate in the community, and always provide top-quality > contributions, but for some reason never got a mentor? I'd like to point > out that this method would only be for the very few ones and recruiting > through mentoring would still be the desired method. > Recruiting through > recruiters would still require the candidate to fill the > ebuild/developer quiz, and they'd have to pass it without a mentor. So > I'll emphasize: Currently only few special ones would qualify. These who would fit here are the people where mentoring takes literally no effort. So someone could be mentor in name - which would also have the advantage that the future developer has someone to talk to if there are any problems or questions. I dont think this actually brings an improvement. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: mail-client/novell-groupwise-client
# Andreas K. Hüttel (2022-06-05) # Ages old, abandoned upstream, and server installs now provide an # actually useful webmail interface. Removal in 30 days. mail-client/novell-groupwise-client -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] it's time for 22.0 profiles
Hi all, it's time for introducing 22.0 profiles [1] - so if you have any things that need to be switched in an incompatible way tree-wide, or if you have any suggestions on how to change our default settings, please reply to this mail with details! Cheers, Andreas [1] Why? That's a quite long e-mail in itself. Very short summary... * All 32bit arches (except riscv32) have a problem. They by default use some datatypes in 32bit, but need to move to 64bit (think timestamps). That's fine for applications, but what do you do if the ABI of some library changes this way? * Plan is to keep the 32bit types as long as possible, and switch to 64bit with the new profile. Details are still being discussed. Pop into #g-toolchain if interested and poke Sam or me... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] base-system team meeting 15/May 19:00 utc, #gentoo-base
Hey all, we'll do a base-system team meeting 15/May 19:00 utc, on #gentoo-base. There will be only one agenda item, lead election (since I'm stepping down as base lead and will not seek re-election). Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Deprecating repoman
> > > > I wouldn't block anyone from doing this, but it's not something I'm > > personally interested in pursuing. I see very little value here. > > First, you're trying to justify replacing repoman on an entirely subjective > opinion of "I think is superior" ... Well, if you've ever tried it you'll notice that for != repoman actually finishes the checks within a finite amount of time. Kind of, the most blatant argument for ditching repoman, actually. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: net-libs/libnfsidmap
# Andreas K. Hüttel (2022-02-27) # Outdated, fails to build with glibc-2.34, bug 806755 # Has been integrated into net-fs/nfs-utils, please use that instead. # Removal in 30 days. net-libs/libnfsidmap -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 01/12] toolchain.eclass: remove EAPI 5 and 6
> Dilfridge had a proposal to ensure 3/6/12 month old systems could still > upgrade, and I'm wondering if this could break those systems. > > There are 3 commits in the last year that finally removed the EAPI 5/6 > toolchain consumers: > 486b77ab8d28c5bfd5a4bdfc5f9a5f432ffde563 > b0a39e54065f7eda2dfc719ec05e270fa7e23e38 > 26f684adecb5b9135f9eba9f1b63c83e3d5e5722 > > The latest of those was in September 2021. > > Do we need to wait X months after those removals, to be able to commit > this change? Hmm. Portage saves and reuses the ebuild environment, so each installed package has its phases and related eclass code stored. Which means this is probably fine, since 1) after syncing, the ebuilds are gone, so you'll never be able to rebuild the consumer 2) and unmerging the consumer is done using the saved environment. More opinions welcome... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] stable users: sys-libs/glibc-2.33-r10 needs testers
Am Mittwoch, 26. Januar 2022, 00:11:42 CET schrieb Andreas K. Huettel: > Hey all, > > I just added sys-libs/glibc-2.33-r9 which is a security fix for the 2.33 > series > (and also adds ebuild improvements backported from the 2.34 series). This just became 2.33-r10 - but the message stays the same! > > Please, if you're still running glibc-2.33, consider testing it! We want to > stabilize it rather soon. Building and normal use... > > (~arch users are already at glibc-2.34, and as you certainly know downgrading > glibc is not possible.) > > Thanks, > Andreas > > -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] stable users: sys-libs/glibc-2.33-r9 needs testers
Hey all, I just added sys-libs/glibc-2.33-r9 which is a security fix for the 2.33 series (and also adds ebuild improvements backported from the 2.34 series). Please, if you're still running glibc-2.33, consider testing it! We want to stabilize it rather soon. Building and normal use... (~arch users are already at glibc-2.34, and as you certainly know downgrading glibc is not possible.) Thanks, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: sys-devel/prelink, app-crypt/hmaccalc
# Andreas K. Hüttel (2022-01-22) # Prelink support is being removed from glibc and was # already somewhat broken for a while... # hmaccalc hard-depends on it (?). # Removal in 30 days. sys-devel/prelink app-crypt/hmaccalc -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Looking for a solution to the distutils/setuptools .egg-info mess
> > TL;DR: how to deal with setuptools (and newer distutils vendored by > setuptools) replacing .egg-info files with directories? > I should probably emphasize here that the .egg-info path contains > the package version, so this is a problem only if the same upstream > version is being reinstalled. > > You can easily reproduce the problem by playing with: > > SETUPTOOLS_USE_DISTUTILS=stdlib > SETUPTOOLS_USE_DISTUTILS=local # vendored > 2. We could control the distutils version in ebuilds directly, > i.e. force "stdlib" for the current versions and have developers switch > to "local" on version bumps. Combined with 1., this will probably > increase the coverage a bit but dead packages will remain in the way. > It also relies on all devs understanding the problem. How about switching it with a new Python version? (since that is also in the path...) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] multilib.eclass: add initial defaults for ARCH=loong
Thank you! Pushed.
Am Samstag, 25. Dezember 2021, 05:23:41 CET schrieb WANG Xuerui:
> From: WANG Xuerui
>
> There is only full support for the LP64D ABI in the initial upstream
> submissions for the various low-level pieces, so full multilib
> combinations are not pursued at the moment; but the expected library
> search path of gcc (`lib64`) means the default of `lib` does not work
> in our case.
>
> Signed-off-by: WANG Xuerui
> ---
> eclass/multilib.eclass | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 483f8d10c72..b14b0ef7785 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -368,6 +368,15 @@ multilib_env() {
> ;;
> esac
> ;;
> + loongarch64*)
> + export CFLAGS_lp64d=${CFLAGS_lp64d--mabi=lp64d}
> + export CHOST_lp64d=${CTARGET}
> + export CTARGET_lp64d=${CTARGET}
> + export LIBDIR_lp64d=${LIBDIR_lp64d-lib64}
> +
> + : ${MULTILIB_ABIS=lp64d}
> + : ${DEFAULT_ABI=lp64d}
> + ;;
> mips64*|mipsisa64*)
> export CFLAGS_o32=${CFLAGS_o32--mabi=32}
> export CHOST_o32=${CTARGET/mips64/mips}
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] last rites: app-emulation/qemu-riscv64-bin
+# Andreas K. Hüttel (2021-12-19) +# Outdated and not needed anymore (this was a releng workaround) +# Removal in 30 days, please compile it yourself from app-emulation/qemu +app-emulation/qemu-riscv64-bin + -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Printer drivers and net-print
> Maybe consider three new top-level categories?: > - print-drivers > - print-filters > - print-misc Only if you take care of them. printing project is somewhat understaffed. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: several perl-core/*
# Andreas K. Hüttel (2021-12-13) # Outdated, all versions in core Perl are newer. Removal in 30 days. perl-core/IO-Zlib perl-core/Module-CoreList perl-core/Test perl-core/Text-Balanced perl-core/Text-ParseWords perl-core/Thread-Semaphore perl-core/Time-HiRes perl-core/version -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Clang/LLVM profile
> Honestly, I think this is pretty on-topic for gentoo-dev given a lot of us > are quite interested in this. ^ this > - I'm not sure why you would need virtual/toolchain or virtual/binutils > unless it's just for usage within bootstrapping scripts? Seems more like > you could just remove gcc from @system and such? ^ this too FWIW, a minimal chroot (corresponding to a stage3) rebuilds quite nicely with clang, with one exception (sys-libs/glibc obviously). Being able to build glibc with clang is seen as a desirable long-term goal by glibc upstream, seems to be nontrivial to implement though. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] 2021 retrospective
Hey all, in the spirit of our "2020 in retrospect & happy new year 2021!" front page article, https://www.gentoo.org/news/2021/01/15/new-year.html which was rather well received, I'd already like to start collecting news from 2021! Suggestions, text snippets, illustrations welcome- either as a reply here on-list, or directly to me. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: several perl-core/*
# Andreas K. Huettel (2021-11-04) # Unused and outdated packages; the version in core Perl is # newer. Removal in 30 days. perl-core/Module-Metadata perl-core/parent perl-core/podlators perl-core/Pod-Simple perl-core/Sys-Syslog perl-core/Term-ANSIColor -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Basic upgrade CI testing
> I think the obvious easy solution here is to run a CI that is using > older stuff, and report problems when commits break that. Something that's been bouncing around my head: * archive stage3 files somewhere official * run a weekly CI job that attempts to upgrade a N-weeks old stage3 to current, with "emerge -uDNav world" * for N=1,2,4,8,16,32 etc * if it fails, annoy people Limitations: 1) covers only stage3 2) solutions may not always be obvious 3) culprits may not always be obvious -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
Am Mittwoch, 3. November 2021, 22:39:41 CET schrieb Ulrich Mueller: > >>>>> On Wed, 03 Nov 2021, Andreas K Huettel wrote: > > > The mistake was to allow the use of EAPI=8 too early. In the future, > > we should have a new EAPI supported by portage for at least some > > months before the EAPI is even used in the main tree. Not even > > speaking about stable here. > > I tend to disagree. Adding an ebuild with a new EAPI cannot break > anything, because it will simply be invisible to old package managers. Except that you need to keep track of version dependencies across the whole tree. So, yes, this is in principle correct, and in practice with our current tooling more or less impossible to do reliably. [Part of the output Whissi pasted was (more or less) that a Perl upgrade required a rebuild of Perl modules. Unfortunately, even a single one that is not available for rebuild makes the emerge bail out.] -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
Am Mittwoch, 3. November 2021, 16:03:37 CET schrieb Thomas Deutschmann: > Hi, > > it is currently not possible to smoothly run a world upgrade on a 4 > months old system which doesn't even have a complicated package list: > [snip] Yup. We know. It's actually way worse than you describe [*] and was noticed already quite some time ago. Unfortunately this is a situation that can IMHO not be easily fixed, and we can only strive to do it better next time. The mistake was to allow the use of EAPI=8 too early. In the future, we should have a new EAPI supported by portage for at least some months before the EAPI is even used in the main tree. Not even speaking about stable here. From there on all the trouble cascades. And no, disallowing a new EAPI for only a part of the tree does not help. (Which part?) An alternative, which we should seriously consider (and which I've been advocating for several months now) is to make Portage more robust, so it can more easily upgrade itself, and keep the Portage ebuild at old EAPI. This means, * making Portage independent of the python eclasses, so it runs as long as any python3 interpreter exists * and bundling all Python dependencies it needs for functioning in it [*] Of course there are ways around this to upgrade the system. However, that is not the point. It should work out of the box. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/sandbox/
> > PS. > checking whether the C compiler works... * > /var/tmp/portage/sys-apps/sandbox-2.25/work/sandbox-2.25/libsandbox/trace.c:_do_ptrace():83: > failure (Function not implemented): > * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x, > 0x): Function not implemented > configure: error: cannot run C compiled programs. > (and yes this is in qemu-alpha user space emulation) > Oops, sorry, this was the bump to sandbox-2.28 (?), not the stabilization. Main point still holds though. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/sandbox/
Mike,
could you please do this just like everyone else, i.e. file a bug and give
arch teams a go? Even if you're on all the arch teams? Even if you know the
code best? More eyes do not hurt.
(I am absolutely not in the mood right now for hunting down why alpha stage
builds now fail.)
TIA
Andreas
PS.
checking whether the C compiler works... *
/var/tmp/portage/sys-apps/sandbox-2.25/work/sandbox-2.25/libsandbox/trace.c:_do_ptrace():83:
failure (Function not implemented):
* ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x,
0x): Function not implemented
configure: error: cannot run C compiled programs.
(and yes this is in qemu-alpha user space emulation)
Am Freitag, 22. Oktober 2021, 01:01:01 CEST schrieb Mike Frysinger:
> commit: 9aac75c0adaf470a9c8605aa4aee59f37f625040
> Author: Mike Frysinger gentoo org>
> AuthorDate: Thu Oct 21 22:47:40 2021 +
> Commit: Mike Frysinger gentoo org>
> CommitDate: Thu Oct 21 22:57:23 2021 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9aac75c0
>
> sys-apps/sandbox: stabilize 2.25
>
> Signed-off-by: Mike Frysinger gentoo.org>
>
> sys-apps/sandbox/sandbox-2.25.ebuild | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sys-apps/sandbox/sandbox-2.25.ebuild
> b/sys-apps/sandbox/sandbox-2.25.ebuild
> index d35f5327d29..70179abd1b9 100644
> --- a/sys-apps/sandbox/sandbox-2.25.ebuild
> +++ b/sys-apps/sandbox/sandbox-2.25.ebuild
> @@ -11,7 +11,7 @@ SRC_URI="https://dev.gentoo.org/~mgorny/dist/${P}.tar.xz;
>
> LICENSE="GPL-2"
> SLOT="0"
> -KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64
> ~riscv ~s390 ~sparc ~x86"
> +KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv
> ~s390 sparc x86"
> IUSE=""
>
> DEPEND="app-arch/xz-utils
>
>
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI=5 must go -- final sprint! :)
Am Sonntag, 17. Oktober 2021, 21:43:40 CEST schrieb Oskari Pirhonen: > On Sun, Oct 17, 2021 at 08:57:26PM +0200, Andreas K. Huettel wrote: > > So, let's make that number go down further fast! :D Cheers! > > What is the best way to help with that? Should I just grep for "EAPI=5" > in /var/db/repos/gentoo and submit a pr with an updated ebuild? Is the > new target EAPI 8? Moikka! Yes, and yes ... in many cases PR's are best, and the new target is EAPI=8. Not all Gentoo devs work with Github, but many do. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] EAPI=5 must go -- final sprint! :)
We've reached the number of only 1000 EAPI=5 ebuilds left in the gentoo repository today! So, let's make that number go down further fast! :D Cheers! -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: virtual/perl-Pod-Parser
# Andreas K. Hüttel (2021-10-16) # Outdated virtual; the respective module was removed # from core Perl with Perl 5.32. Use dev-perl/Pod-Parser # instead. Removal in 30days. virtual/perl-Pod-Parser -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: net-im/webex
# Andreas K. Hüttel (2021-10-16) # Binary-only package, cannot be distributed, download # is an unversioned URL which changes content. In brief, # a pain. Unmaintained from now on. If you pick it up, # you'll have to watch it closely. Removal in 30 days # otherwise. Bug 794700. net-im/webex -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: various perl-core/*
# Andreas K. Huettel (2021-10-14) # Unused and outdated packages; the version in core Perl is # newer. Removal in 30 days. perl-core/Locale-Maketext-Simple perl-core/Math-BigInt perl-core/Math-Complex perl-core/Memoize perl-core/MIME-Base64 -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions
> > I generally agree that comments are more visible/noticeable than > metadata, however, I also think that this could be a good step forward > for overall maintainability. The issue with documenting these things > in comments is that the comment lives only within the specific version > of the ebuild in which it is authored: it is up to the maintainer to > carry those comments over when version bumping. While this is > generally not a problem due to copy/paste, I think it is messy - there > could be an update to the comment from one version to the next, > meaning I now have two version of the comment floating around. > > With , there is one localized "source of truth" for this > documentation, which should remove any ambiguity. > > I would hope that after launching the feature, there would be > a gradual (or sudden?!) shift away from the current comments towards > the tag, maybe even including this in the dev manual. > That makes no sense, since the notes could be version-dependent. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Experimental binary package hosting
Hi Vadim, > Finally it happened! > I already planned to try to ask infra/council about sponsoring few > servers for build farm for "official gentoo binhosts" when I had > enough time, but fortunately, you've already did that. > It's very good news. Thanks! Nice to see that this is appreciated :) So far I'm only using "spare time" on the machine that builds the releng stages (amd64, x86, m68k, riscv). So no need for a big server farm. > Btw, do you need any help with that? > I'd be very happy to help with that project. Sure! Feel free to add yourself to the Project:Binhost wiki page. I'll ask for an alias and a channel soon. The most useful steps now are only half related to actual building. I barely know any python and am not very familiar with portage internals... this is what in my opinion we'd need next: 1) a tool to manage and manipulate a binpkg/ directory tree The main functions that I see needed are * delete packages/versions that are not in the gentoo repository anymore (xpak and in index file), maybe with some grace time * merge xpak files built elsewhere into the directory (also in the index file) (imagine you have a second container that builds with same CFLAGS, but with use settings for gnome, not plasma... or with updated dependencies because of changes in gentoo.git... you want to merge the trees for distribution without having duplicate builds) 2) binary package cryptographic signing and verification Essentially we need to finish support for GLEP78; this is being worked on in RinCat's pull request https://github.com/gentoo/portage/pull/562 See also https://www.gentoo.org/glep/glep-0078.html 3) an easy way to figure out if a binary package repo is suitable for a profile / arch / ... or not, and a standard for path names This is not so important right now, and partially also already present I guess. The actual builder right now is very simple and wired up with a single daily cron job; the mirrors are only updated manually by me until bug 813528 is handled. Cheers Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Experimental binary package hosting
Am Mittwoch, 22. September 2021, 10:20:10 CEST schrieb Torokhov Sergey: > Sorry for previous html message. I tried to recend it as plaintext. > > I have repos configs placed into /etc/portage/repos.conf with > "rsync-type = git" fo all repos so I created binhost.cond file here > instead of /etc/portage/ as mentioned in blog post. Nope. As the blog post says, you need to put that text into a *file* with name -->>> /etc/portage/binrepos.conf <<<--- ... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Experimental binary package hosting
> Andreas, > > How is USE=bindist treated? > Its on for stage building and off in profiles. USE=bindist is switched on, and in addition we have ACCEPT_RESTRICT="* -bindist" -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Experimental binary package hosting
So let's experiment with this... :) announcing: https://gentoo.osuosl.org/experimental/amd64/binpkg/default/linux/17.1/x86-64/ More information can be found in a blog post, which will also be on planet.g.o soon: https://dilfridge.blogspot.com/2021/09/experimental-binary-gentoo-package.html Cheers -A -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Guidance on distributed patented software
Am Montag, 20. September 2021, 19:27:37 CEST schrieb Rich Freeman: > On Mon, Sep 20, 2021 at 12:46 PM Alec Warner wrote: > > Could we add some text to the license concepts covering patents? It > > seems to have been omitted? > > Is my understanding of how we manage patented software correct? > > I think you have the gist of it. Is there actually anything in the > repo these days which is patent-encumbered? media-libs/openh264 for example (It right now prevents me from building firefox and chromium for the experimental binary package hosting [1], since I blanket mask everything with bindist restriction. That is likely a bit of overkill, it would be enough to not make any binary package from it (which ends up being distributed), but that function needs to still be programmed in portage.) [1] Blog post with details coming soon. Please wait for it before asking questions. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites : toolchain-glibc.eclass
toolchain-glibc.eclass is long obsolete and not used anymore since glibc-2.26. Last ebuild is gone now, so removing the eclass in 30 days. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-perl/POE-API-Peek
# Andreas K. Hüttel (2021-08-15) # Broken since Perl 5.22, bug 662318. Removal in 30 days. dev-perl/POE-API-Peek -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-perl/MooseX-Types-DateTime-ButMaintained dev-perl/MooseX-Types-DateTimeX
# Andreas K. Hüttel (2021-08-15) # Broken-ish, upstream unmaintained, only one un-used revdep. # Removal in 30 days. Bug 623674. dev-perl/MooseX-Types-DateTime-ButMaintained dev-perl/MooseX-Types-DateTimeX -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-perl/Perlbal-XS-HTTPHeaders
# Andreas K. Hüttel (2021-08-15) # Broken for years, see bug 642466. No reverse dependencies, # no easy fix. Removal in 30 days. dev-perl/Perlbal-XS-HTTPHeaders -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation
> > Categories themselves were not a design mistake. The design mistake is > using categories to permit conflicting package names. > > Categories are convenient. Sure, they're not perfect but they serve > their purpose to some degree and there's little harm in having them. > If you want to organize packages better, nobody's stopping you. Until > you've got a better and widespread replacement, I don't see why people > shouldn't be using categories as they see fit. > > The other part is something we could aim for fixing but so far most > developers seems to disagree with me, so there's no point in pursuing > that. > So how about improving categories instead? Rough idea: * introduce 1st, 2nd, 3rd class categories, categorized in metadata somewhere * 1st class is what you want in your world file (and default setting) * 2nd class is everything else * 3rd class is stuff that should never be in your world file (but still can be, if you want) Then tooling can (maybe output a warning but) default to highest class category if none is given. Examples: * 1st class: app-*, dev-lang, games-*, ... * 2nd class: dev-haskell, dev-perl, dev-php, dev-python, dev-texlive, media-libs, net-libs, sci-libs, ... * 3rd class: acct-*, perl-core, virtual -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation
Am Donnerstag, 5. August 2021, 23:44:40 CEST schrieb Georgy Yakovlev: > Hi, > > We've been collecting more and more container related packages in > app-emulation/* > > What do you think about finally moving those packages to separate category? > > probably app-containers/ > > Here's the tentative list, most tools have description attached for easier > review, 36 candidates so far, there may be more around, I only looked at > app-emulation. Sounds like a good idea! -a -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: various perl-core/*
# Andreas K. Hüttel (2021-07-31) # Obsolete; all versions in current Perl core distributions # are newer, and no virtuals currently pull these packages. # Removal in 30 days. perl-core/ExtUtils-MakeMaker perl-core/ExtUtils-Manifest perl-core/File-Path perl-core/Getopt-Long perl-core/HTTP-Tiny perl-core/JSON-PP perl-core/libnet -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Am Samstag, 24. Juli 2021, 17:16:23 CEST schrieb Michał Górny: > Hi, everyone. > > I've been asked to repost the idea of removing SHA512 hash from > Manifests, effectively limiting them to BLAKE2B. Just keep things as they are for now. Even reading this bike^H^H^H^Hthread is more effort than the potential gain. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> My modest opinion on the topic is: > As far that is free software and there are users that use deblob, I > don't see any reason on why we should not support this and give them > the > choice. Gentoo is about choice. [snip] > deblob is only supported for rt-sources. > gentoo-sources currently doesn't have deblob. So deblob is highly important for choice, you say. Also, the kernel sources that everyone uses don't offer deblob. Somehow this discussion is getting ridiculous. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> > Gentoo is about choice. if there are users that want to use deblob I > don't see why we don't have to add the option. > Errr how is *removing the firmware loader* about choice? You have all the choice of the world by just not providing any firmware to load. Removing the loader removes that choice. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: several perl-core/*
# Andreas K. Hüttel (2021-07-17) # Obsolete; all versions in current Perl core distributions # are newer, and no virtuals currently pull these packages. # Removal in 30 days. perl-core/Archive-Tar perl-core/CPAN-Meta perl-core/CPAN-Meta-Requirements perl-core/Data-Dumper perl-core/Digest perl-core/Digest-MD5 perl-core/Digest-SHA perl-core/Dumpvalue perl-core/Encode perl-core/ExtUtils-Constant -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: virtual/perl-Pod-Parser
# Andreas K. Hüttel (2021-07-17) # Obsolete virtual; package was removed from the Perl # core distribution. Please depend on dev-perl/Pod-Parser # instead. Removal in 30 days. virtual/perl-Pod-Parser -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
> > > > 1) either the severity assignment of this bug by the Security project as B1 > > wrong (i.e. it should have been classified "harmless") > > > > The Gentoo model is not perfect and should be overhauled. However, it > works for most things and sometimes bugs fall between the cracks. > > The package shouldn't have been masked either based on a bug that was > purposely ignored for many years simply because they want to disband the > package now and found a "security reason" to add to the mask. Well, over the last year or so every 2-3 months the (uninformed) discussion came up, "don't use openrc stages because you are automatically rooted". That leaves a rather bad impression of Gentoo, independent of whether it is true or not. If noone from sec team noticed the discussions... > > 2) or the entire classification of severity levels according to the > > Security project pointless (i.e. you can't base any actions on them because > > a mystery onion needs to be taken into account). > > > > I am not sure if this is sarcasm, but every bug must be considered > through the correct aperture. That is, based on your environment, > protections in place, defense in depth, and other buzzwords... hence the > onion analogy. It's not sarcasm. The point of the classification is to give clear rules (why else would you list, e.g., required response times on the vulnerability treatment page (no matter how illusory they are)). If you don't take all factors into account when *making* the classification, then all gain you have from the classification is lost. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
> The package was masked due to a miscommunication with the Gentoo > Security project. > > While it is true that the way opentmpfiles is currently implemented > allows for certain races, from the security point of view, you always > have to classify the vulnerability in context of your threat model > because security depends on multiple layers (onion model). I would like to respectfully point out that this makes 1) either the severity assignment of this bug by the Security project as B1 wrong (i.e. it should have been classified "harmless") 2) or the entire classification of severity levels according to the Security project pointless (i.e. you can't base any actions on them because a mystery onion needs to be taken into account). https://www.gentoo.org/support/security/vulnerability-treatment-policy.html -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 'pax_kernel' USE flag
> > The PaX community in Gentoo is still big and active. > > > > Many Gentoo users received free access to upstream sources or became > > paying customers. > > > > It's just not available for everyone for free/without registration > > anymore. But it is still a thing in Gentoo. > > Can you substantiate that claim? > > There was a pax-kernel USE flag on Mesa and I don't recall anyone > saying a word when I removed it. > > If there are paying customers that have PaX kernels, perhaps they'd be > interested in providing some support for Gentoo if we're being asked > to retain support for something we cannot test. Summary from the replies so far: * either noone is using it, * or noone is willing to admit using it. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New Developer: Florian Schmaus (flow)
Welcome Florian!!! Where in Franconia are you from?! Regensburg here, so just "south beyond the border"... :D (Arcobräu!) Am Dienstag, 22. Juni 2021, 21:27:11 CEST schrieb Gokturk Yuksek: > Hello everyone, > > I'd like to announce with great pleasure our latest addition to the > developer community. Florian Schmaus is joining us from Germany. > > He is a computer scientist focusing on operating systems and runtime > systems for future many-core systems. His FOSS contributions include > participating in developing the XMPP protocol and maintaining an XMPP > client-side library Smack. In his free time, besides being a full-time > dad, he enjoys running and the cold beverages of his home region, > Franconia. > > Please give him a warm welcome! > > -- > gokturk -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] news item: riscv upgrade to 20.0 profiles
Feedback welcome... Title: riscv upgrade to 20.0 profiles Author: Andreas K. Hüttel Posted: 2021-06-25 Revision: 1 News-Item-Format: 2.0 Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64d Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64d/systemd Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64 Display-If-Profile: default/linux/riscv/17.0/rv64gc/lp64/systemd On RISC-V we are switching from two-level library directories (e.g., /usr/lib64/lp64d) to a more traditional directory architecture. This is done via the profile upgrade from 17.0 to 20.0 profiles. We recommend to re-install from scratch using a 20.0 profile based stage. 17.0 profiles will be deprecated immediately and removed in 6 months. If you want to upgrade an existing installation, the following steps should be taken. Please read all commands carefully first and make sure you understand them, since the procedure is risky. The commands are given for a lp64d profile; in case of a lp64 profile, always replace lp64d with lp64. # cd /usr/local/lib64 # cp -av lp64d/. . # rm -rf lp64d # ln -s . lp64d # cd /usr/lib64 # cp -av lp64d/. . # rm -rf lp64d # ln -s . lp64d # cd /lib64 # cp -av lp64d/. . # rm -rf lp64d # sln . lp64d Note that the last command uses "sln" instead of "ln -s". Then switch from your 17.0 profile to the corresponding 20.0 profile, either by using "eselect profile" or by manually changing the /etc/portage/make.profile symlink. Next, rebuild all packages: # emerge -eav world As last step, check if portage has removed any of the symlinks created above, and if yes, recreate them. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Need help with perl-cleaner (and app-admin/gentoo-perl-helpers)
> > https://github.com/gentoo-perl/gentoo-perl-helpers > > I believe infra were the inspiration for it and are the main > consumers. Worth speaking to them? Yes I will... It's not that I dont want to help them, but... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Need help with perl-cleaner (and app-admin/gentoo-perl-helpers)
Am Donnerstag, 13. Mai 2021, 12:02:32 CEST schrieb Andreas K. Huettel: > Hi all, > > due to having somewhat too many Gentoo projects and not enough time > at the moment, I'd like to ask for help with perl-cleaner here. > PS. app-admin/gentoo-perl-helpers also needs a new maintainer, both in Gentoo and upstream. I have never touched it so far and am completely unfamiliar with the code and its usage. https://github.com/gentoo-perl/gentoo-perl-helpers -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Need help with perl-cleaner
Hi all,
due to having somewhat too many Gentoo projects and not enough time at
the moment, I'd like to ask for help with perl-cleaner here.
It is in most cases not necessary anymore, and I personally have not
used it for ages, since the automated rebuilds via subslots make it
obsolete. Still...
* The change in path structure with Perl 5.32 (from, e.g., /usr/lib64
perl5/5.30.3 to /usr/lib64/perl5/5.32) broke the rebuild functionality
[1]
* There are issues with the 17.1 profiles [2]
* There are several unrelated bugs and github issues.
* Testing is nontrivial since you basically need a snapshotted
install, where you can roll back a Perl upgrade.
* The code is, well, horrible. [3]
In any case, please have a look and file bugs and even better patches
and/or pull-requests...
https://github.com/gentoo-perl/perl-cleaner/
If no help materializes, my plan is to lobotomize perl-cleaner so it
only cleans out "known leftover files" and otherwise recommends a
portage command to rebuild all reverse dependencies of dev-lang/perl.
Unfortunately this kind of blocks Perl 5.32 stable.
Cheers,
Andreas
[1] https://bugs.gentoo.org/763021
[2] https://bugs.gentoo.org/589874
[3]
broken_libs="$(${scanelf} -qBn < <(awk '/^(obj|sym) [^ ]*\/(s?bin|
lib(32|64|x32)?)\// && ! /^obj [^ ]*\/usr\/lib\/debug\//{ print $2 }'
${content} ) | grep -o 'libperl\.\(so\|dylib\)\.[0-9.]*' | sort -u )"
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] removal: dev-perl/PortageXS app-portage/demerge app-portage/perl-info
# Andreas K. Hüttel (2021-05-09) # PortageXS saw its last release in 2016 and would need # a new upstream maintainer. Multiple bugs, e.g., # 688238, 625536, 613114, 473394, 332611, 289524, 264680 # Masked for removal in 30 days, including reverse deps. dev-perl/PortageXS app-portage/demerge app-portage/perl-info -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support -- Summary
So, here's what I took away from the thread. Please shout if you disagree. 1) Advertised riscv profiles will all be non-multilib and use /usr/ lib64 (or /usr/lib if we ever get around to riscv32). [A] 2) The standard for keywording and stabilization is rv64gc/lp64d. We keep stages for other variants [B] around if feasible, but on these important packages may be masked and unavailable [C]. 3) We try to internally keep the multilib variant with the two-stage path going for now, as very low-priority thing. [D] 4) Medium term we discuss with the RISC-V, glibc, gcc people how multilib could be simplified, and then switch the multilib settings once this comes to a conclusion. If there are no protests I'll start planning the path migration for 1). (Maybe making a riscv-specific new profile version is best.) Cheers, Andreas [A] Note that the actual specs use /usr/lib32/... [B] Other ABI (lp64) or other ISA (riscv32...) [C] See rust etc. [D] Low priority means, it pretty much won't build every now and then, as, e.g., right now [E]. [E] Our monkeypatched glibc-2.32 rv32 support was experimental enough so it didnt survive the transition to official upstream glibc-2.33 support, so the multilib stages will have to be re-bootstrapped. > So, I would like to bring two proposals up for discussion. > > 1) We stop caring about anything except rv64gc/lp64d. > People can still bootstrap other stuff with crossdev etc, but the > Gentoo tree and the riscv keyword reflect that things work with > above -mabi and -march settings. > > 2) We drop the multilib paths and use "normal" lib64, with > additional "safety symlinks" (/usr)/lib64/lp64d -> . > This is what SuSE and (I think) Fedora already does. The symlink > should be there since "lib64" is NOT an official fallback coded into > gcc/glibc/binutils; the only fallback present is "lib" ... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
Am Donnerstag, 6. Mai 2021, 22:34:52 CEST schrieb Palmer Dabbelt: > > TBH: I'm not really going to come up with something better beacuse I > came up with the current (and likely broken) scheme and I still > don't fully understand why. So if you have suggestions as to > something that would actually work that would be great, as > otherwise I'm just going to come up with something broken again ;) > Heh. No worries. I actually liked the idea, just until the moment when I remembered that we had been campaigning for months to replace all absolute symlinks in Gentoo with relative ones. And suddenly there is only on riscv not enough "../" in the link. > Is the constraint just "no sub-directories for libraries"? IIRC we > did that because someone else was already doing it and it seems to > be less of a FHS break that adding a bunch of first-level > directories. I need to read up on FHS. Time... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
> I'm fine with rust masked in lp64/other profile.. > but in my opinion: it's really up to upstream should fix/support it > > > (Unless Palmer et al come up with a fix for the libdirs on the > > upstream side of things. Already e.g. libdir=lib64-lp64d would be > > much easier to handle I suspect.) > > using one level path (eg. lib64-lp64d) won't fix the problem, > the root cause is that we use a 'non-standard' lib path (QT5, Cmake > issue), not matter it's one level or two level path, see bug here I suspect this may need some more analysis. But, if we transition in non-multilib cases to normal lib64, then we have all the time in the world to figure it out. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
> > 1) We stop caring about anything except rv64gc/lp64d. > > People can still bootstrap other stuff with crossdev etc, but the > > Gentoo tree and the riscv keyword reflect that things work with > > above -mabi and -march settings. > > fine by me, for current software/upstream state, it's probably the > most practical way to only support lp64d, this will significantly > ease our life .. besides, it's relatively easy if people want to > support more (lp64/lp32..) later > ++ > > 2) We drop the multilib paths and use "normal" lib64, with > > additional "safety symlinks" (/usr)/lib64/lp64d -> . > > This is what SuSE and (I think) Fedora already does. The symlink > > should be there since "lib64" is NOT an official fallback coded > > into gcc/glibc/binutils; the only fallback present is "lib" ... > can we use different scheme for non-multilib vs multilib? > 1) non-multilibe: just use "normal" lib64, keep align with other > ARCHs (amd64)? ++ > 2) multilib: just stick to current two level lib path We can try that but it doesn't solve any of our problems (and we'd have to keep carrying the two-level dir patches). (I've already decided some time ago that supporting real multilib stages is too much effort for insufficient gain and stopped publishing them. Until recently I still built them; since glibc-2.33 they broke and while I know how to fix things I haven't had time to do it yet.) So if we keep the multilib scheme around, then IMHO only as internal workaround until we/upstream/... have figured out a better directory scheme. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
> > Haven't I told you using two-level libdirs is stupid? So yes, > please do that and let us be happy once again. > > That said, where does lp64gc land? Or isnon-multilib > one-or-the-other the goal? It would be non-multilib one-or-the-other then for us. The main relevant combination is rv64gc/lp64d, which is arguably what a linux machine "should have". (I could also imagine to keep rv64imac/lp64 profile and stages (also using lib64), these would have to mask stuff like rust then though.) (Unless Palmer et al come up with a fix for the libdirs on the upstream side of things. Already e.g. libdir=lib64-lp64d would be much easier to handle I suspect.) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to structure our RISC-V support
>
> -mabi=rv64gc -march=lp64d
should be -march=rv64gc -mabi=lp64d
> libdir = lib64/lp64d
> ("hardfloat")
>
> -mabi=rv64imac -march=lp64
should be -march=rv64imac -mabi=lp64
> libdir = lib64/lp64
> ("softfloat")
>
(but that doesnt change the rest of the argument)
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] How to structure our RISC-V support
Howdy.
I'm sending this not only to the team members on the alias, but also
to the whole dev list for discussion.
So far I've been trying to support in Gentoo the full risc-v multilib
directory structure and the ABI sets supported by glibc. According to
specs this means for riscv64
-mabi=rv64gc -march=lp64d
libdir = lib64/lp64d
("hardfloat")
-mabi=rv64imac -march=lp64
libdir = lib64/lp64
("softfloat")
and theoretically similar for riscv32 (which just landed in glibc and
is still broken in qemu-user).
However, this leads to several levels of pain (and I definitely dont
have time to deal with it myself):
a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads
to difficulties in build systems. Right now Qt5 and CMake are still
somewhat broken (in *Gentoo*).
b) Rust only supports rv64gc/lp64d. (Which is arguably what you should
have for decent Linux support.)
I'm pretty sure these are not the only things, but they are somewhat
symptomatic.
So, I would like to bring two proposals up for discussion.
1) We stop caring about anything except rv64gc/lp64d.
People can still bootstrap other stuff with crossdev etc, but the
Gentoo tree and the riscv keyword reflect that things work with above
-mabi and -march settings.
2) We drop the multilib paths and use "normal" lib64, with additional
"safety symlinks" (/usr)/lib64/lp64d -> .
This is what SuSE and (I think) Fedora already does. The symlink
should be there since "lib64" is NOT an official fallback coded into
gcc/glibc/binutils; the only fallback present is "lib" ...
Opinions?
Cheers,
Andreas
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted
Am Sonntag, 2. Mai 2021, 11:56:34 CEST schrieb Fabian Groffen: > Title: Exim >=4.94 disallows tainted variables in transport > configurations Author: Fabian Groffen > Posted: 2021-05-?? > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: mail-mta/exim > > Since the release of Exim-4.94, transports refuse to use tainted > data in constructing a delivery location. If you use this in your > transports, your configuration will break, causing errors and > possible downtime. > > Particularly, the use of $local_part in any transport, should likely > be updated with $local_part_data. Check your local_delivery > transport, which historically used $local_part. > > Unfortunately there is not much documentation on "tainted" data for > Exim[1], and to resolve this, non-official sources need to be used, > such as [2] and [3]. This is a safety mechanism that is part of Perl (essentially a way of tracking data that is derived from "insecure" sources). So it probably would make sense to at least point towards that concept in Perl. https://perldoc.perl.org/perlsec -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-perl/Sane
# Andreas K. Hüttel (2021-04-30) # Superceded by dev-perl/Image-Sane. Tests hang, bug 626594 # Removal in 30 days. dev-perl/Sane -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: some outdated perl-core/*
# Andreas K. Hüttel (2021-04-30) # Outdated, not pulled in by any virtuals anymore, no # keywords. Removal in 30 days. perl-core/Devel-PPPort perl-core/Time-Local perl-core/Unicode-Normalize -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-perl/HTTPD-User-Manage
# Andreas K. Hüttel (2021-04-25) # Broken, bug 616986; removal in 30 days dev-perl/HTTPD-User-Manage -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-perl/Text-Unaccent
# Andreas K. Hüttel (2021-04-25) # Broken, bug 663274; removal in 30 days dev-perl/Text-Unaccent -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
> > Council decided years ago that we don't support separate /usr without > > an initramfs, but we haven't completed that transition yet. > > Which doesn't imply that we deliberately break things. That's right. Though we should at some point start thinking about an end of support for separate usr without initramfs. Why? Because the number of required hacks and complexity will only increase, as will the number of uncooperative upstreams. It's called a strategic retreat. :D My suggestion would be that the next profile version (21? 22?) declares separate /usr a broken configuration, and explicitly encourages devs to introduce all ebuild simplifications that are made possible by this. (Like this symlink - no more conditional code.) No more discussions about "not breaking things" at that point. (Or to put it another way, I think we should stop wasting time and effort here just to be able to live in the past.) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
