>
> This appears to leave us with sci-ai/* because:
>
> First, 'AI' seems to be the term that is commonly used (just look at
> this mail's subject) and understood.
>
> Secondly, while others may find sci-ai to buzzwordy, that could also
> been seen as an advantage.
This.
Buzzwordy is kinda
This is the first batch. More probably sometime later.
# Andreas K. Hüttel (2025-02-27)
# We have collected a lot of barely used Perl virtuals over time
# (they effectively only make sense with version dependencies).
# Time to clean up. In ebuilds, just depend on dev-lang/perl.
# The following ar
# Andreas K. Hüttel (2025-02-27)
# We have collected a lot of barely used Perl virtuals over time
# (they effectively only make sense with version dependencies).
# Time to clean up. In ebuilds, just depend on dev-lang/perl.
# The following are masked for eventual removal:
virtual/perl-Memoize
virt
# Andreas K. Hüttel (2025-02-27)
# We have collected a lot of barely used Perl virtuals over time
# (they effectively only make sense with version dependencies).
# Time to clean up. In ebuilds, just depend on dev-lang/perl.
# The following are masked for eventual removal:
virtual/perl-Net-Ping
**
# Andreas K. Hüttel (2025-02-16)
# Discontinued, please use xournal++ instead.
# Removal on 2025-03-16. Bug 948200.
app-text/xournal
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digita
Libreoffice can't be built with Java or KDE support on x86 stable anymore
at the moment.
Since this becomes more and more hard to maintain, Matthias (tamiko) and me
are going to restrict the libreoffice-bin build in the future to amd64 only.
Future versions will not have x86 keyword, and soon th
# Andreas K. Hüttel (2024-11-17)
# Needs a header from libusb that doesnt exist anymore. Will never build.
# Furthermore, modern C problems. Bug 874645. No maintainer.
# Removal in 30 days.
dev-util/usb-robot
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain,
# Andreas K. Hüttel (2024-11-17)
# Fails to build on modern compilers, bug 874291. Various open bugs.
# No maintainer. Removal in 30 days.
app-emulation/spim
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Desc
Hi all,
gcc 14 is nearing stabilization. This, however also means that the changed
defaults in that version now become an urgent issue for many packages...
Here's the stable tracker: https://bugs.gentoo.org/941869
Please, please, please help by fixing the bugs listed there.
Ionen and Sam have
And committed. 31 new warnings (compared to 400 preexisting ones). :)
Am Montag, 2. September 2024, 23:14:50 CEST schrieb Andreas K. Huettel:
> Dear all,
>
> the number of packages with unfulfilled dependencies in mips has decreased a
> lot,
> mostly, as far as I know, due
Dear all,
the number of packages with unfulfilled dependencies in mips has decreased a
lot,
mostly, as far as I know, due to the tireless work of matoro and arturzam.
Right now we're at 38.
As such I would like to switch one of the mips profiles from exp to
dev. This makes such breakage visib
Am Montag, 5. August 2024, 00:39:13 CEST schrieb Robin H. Johnson:
> > Step 2: Formally introduce the new keywords in ebuilds by duplication.
> > Any "ppc64" in keywords becomes "ppc64 ppc64le".
> > Any "riscv" becomes "riscv riscv32 riscv64".
> > No exceptions. Can be done automatically. Until th
Hi Arthur,
> a. Splitting ppc64 keyword into ppc64 and ppc64le
> b. Splitting riscv keyword into riscv(64?) and riscv32
So in principle these steps both make sense.
The problem is mostly that such an operation on the living Gentoo
has not been attempted in recorded history. There is no precede
> > mips stage builds are currently broken since needed dependencies lack the
> > mips keyword.
> >
[...]
> >
> Can you share what exactly is missing? This is a longterm project of mine,
> but ever since the mail archives went out I can no longer see failed stage
> builds to check.
>
Sure, n
Hi all,
mips stage builds are currently broken since needed dependencies lack the mips
keyword.
If we want to continue building mips stages, then someone will need to work on
open keyword requests and verification of the dependency tree.
I started looking at it, but with already way too many Ge
> I would hope to split this arch into the two endianness, but I suspect
> nobody has the energy to do it. Oh well.
[...]
> Dev arch. I don't have much info on it, but I heard some mess with
> riscv32 and riscv64, so maybe time to split it? I leave it to riscv arch
> team, which works quite well, b
> 32-bit arches
>
> This includes stable arches x86, arm, ppc, sparc32, dev arches s390, and
> maybe more. Those are in much worse situation, with a mess on various
> fronts, some of them super hard to continue support. For example
> qtwebengine is less and less likely to manage
> > ia64
> >
> > Dev 64-bit arch. Kernel dropped support, glibc dropped support, devbox
> > died - days are short before full exp status or full removal of arch.
>
> Yeah, no interest in ia64, sorry. I'd like it to just go.
This is probably unavoidable given that our devbox and
> riscv
>
> Dev arch. I don't have much info on it, but I heard some mess with
> riscv32 and riscv64, so maybe time to split it? I leave it to riscv arch
> team, which works quite well, but I'll be happy to open discussion for it.
riscv is something new and growing, but for now
> alpha
>
> Exp arch, with nearly (or maybe already) full correct dep-tree. matoro
> did a lot of great work here, so I think we should promote it to dev
> arch, so dep-tree remains unbroken. We dekeyworded a lot of stuff,
> cleaned it up, so a nice "completion bonus".
>
> =
> As you all know, Gentoo supports many various arches, in various degrees
> (stable, dev, exp). Let me explain those 3 statuses fast:
>
> * stable arch - meaning we have stable profile for this arch, and stable
> keywords across base-system + varying degree of seriousness. We stable
> stuff after
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 rename
> 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 p
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
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
> > 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
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 th
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
> > u
> > 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
>
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/plot
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 IM
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 "
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
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.
IMPORTAN
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
>
> > 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=
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,
>
> 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)
7;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
pr
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
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_upd
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
+# 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
Descrip
# 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-a
> >> 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-pro
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
Descript
# 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...@
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
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
>
> 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
>
> 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
(cou
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.
> 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
> rela
>
> 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 develo
# 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,
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 lon
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,
> >
> > 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 y
# 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-syst
> 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
> b0a39e54065f7eda2
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 me
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
# 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,
>
> 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 reinstalle
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
+# 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, ba
> 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, libreoffic
# 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ütt
> 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
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 a
# 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
> 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 curr
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 s
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
>
> 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 imp
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
Andre
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 "E
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:
# 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,
# 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. 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
>
> 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 ebu
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 :)
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/p
> 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
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
Cheer
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?
>
>
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
# 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 p
# 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, bas
# 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
De
>
> 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 orga
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 tentat
# 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
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
> 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.
> ge
>
> 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
# 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
# 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-syst
> >
> > 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.
>
> Th
1 - 100 of 803 matches
Mail list logo
