-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Samstag, 12. Dezember 2015, 13:06:59 schrieb Michał Górny:
> Dnia 12 grudnia 2015 13:05:12 CET, "Michał Górny"
napisał(a):
> >Dnia 11 grudnia 2015 22:03:07 CET, dilfri...@gentoo.org napisał(a):
> >>From: &q
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Samstag, 12. Dezember 2015, 12:50:29 schrieb Michał Górny:
> >+if [[ ${EAPI:-0} = 5 ]]; then
> >+[[ ${SRC_PREP} = yes ]] && return 0
> >+fi
>
> Why not combine this into single [[ ]]?
>
> >+esac
> >+RDEPEND="${DEPEND}"
> >+;;
> >+ esac
>
> Why don't you pack this stuff into a single trinary variable?
Good idea. Let's kill GENTOO_DEPEND_ON_PERL_SUB
t;
> Without spaces around the operator, this condition will always
> evaluate to true. ;-)
Ok will fix this. Reminds me why I keep getting puzzled by Bash... :D
- --
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de
[[ ${PATCHES[@]} ]] && epatch "${PATCHES[@]}"
> >+debug-print "$FUNCNAME: applying user patches"
> >+epatch_user
> >+else
> >+[[ ${PATCHES[@]} ]] && eapply "${PATCHES[@]}"
>
${MODULE_P}
> How likely is it that one would use MY_* without MODULE_*? Maybe it would
> be good to warn about this?
Well... the main usage of this input is calculation of SRC_URI and S.
So, I'm not so worried about it, since failing to update the settings will
lead to pr
xtensive
documentation about EAPI=5 seems to be counterproductive there.
- --
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1
iQJ8BAEBCgBmBQJWbIOqXxSAAC4AKGlzc3Vlc
ce the finetuning is done.
- --
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1
iQJ8BAEBCgBmBQJWbIQNXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI
uild system in the past.)
"Gentoo Perl" would lead to GPL_... as variable prefix, not really suitable.
Kent suggested GPLX_... which I find horrible. GPERL_? GP_? ...
- --
Andreas K. Huettel
Gentoo Linux developer
dilfri...@g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Samstag, 26. Dezember 2015, 12:53:20 schrieb Jeroen Roovers:
> On Fri, 11 Dec 2015 22:03:06 +0100
>
> dilfri...@gentoo.org wrote:
> > From: "Andreas K. Huettel (dilfridge)"
> >
> > ---
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
# Andreas K. Hüttel (9 Jan 2016)
# Errorneously added. Is already in perl-core. Please uninstall.
dev-perl/ExtUtils-Constant
Removal in 30 days
- --
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de
ltilib-20160108.iso.CONTENTS
http://releases.gentooligans.com/livedvd-amd64-multilib-20160108.iso.DIGESTS
--
Andreas K. Huettel
Gentoo Linux developer
perl, office, comrel, council
gt;
> http://releases.gentooligans.com/livedvd-amd64-multilib-20160108.iso
> http://releases.gentooligans.com/livedvd-amd64-multilib-20160108.iso.CONTENT
> S
> http://releases.gentooligans.com/livedvd-amd64-multilib-20160108.iso.DIGEST
> S
--
Andreas K. Huettel
Gentoo Linux devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
in case you haven't noticed yet, EAPI=6 capable =sys-apps/portage-2.2.26 is
now stable on all stable arches.
This means packages using EAPI=6 can be stabilized.
Happy EAPI bumping!
Andreas
- --
Andreas K. Huettel
Gentoo
t; ===
>
> Remaining question: how do get the timing of the news item to line up
> with the stabilization? Or do we just start by sending out the news
> item, then file the stabilization bugs so that people at least have
> advance notice?
>
> Cheers,
>
> Dirkjan
-
# Andreas K. Hüttel (2020-03-26)
# Fail to build with glibc-2.30; no maintainer. Removal in 30days.
# Bugs 691756, 691710
x11-terms/aterm
x11-terms/xvt
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
signature.asc
Descr
>
> Andreas, perhaps this should be added to the mask comment? Happy to
> push a PR or simply add this information to the bug report, at the very
> least I thing the bug report should be closed with WONTFIX, may I
> proceed with that? I'll same comments there if in order.
Sure, adding the info t
# Andreas K. Hüttel (2020-03-27)
# No consumers. Build problems, bug 668244. Removal in 30 days.
media-libs/openmoiv
--
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
Fixed, thank you!
Am Mittwoch, 1. Juli 2020, 12:35:09 EEST schrieb Xianwen Chen (陈贤文):
> Dear all,
>
> There is a typo in
> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/julia/julia-1.4.0-r2
> .ebuild.
>
>
> On line 82, instead of *llvm_pkg_setp*, it should be *llvm_pkg_setup*.
>
> Y
> I would like to propose that we switch the default udev provider on new
> systems from eudev to udev.
Well... maybe you could somewhat expand on the why?
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
signature.asc
D
>dev-util/dialog
>sys-block/parted
Im going to add base-system to these two later (in addition to dedicated
maintainers)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov
wrote:
>22.10.2020 20:16, Andreas K. Hüttel пишет:
>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
Users frequently are choosing the wrong profile ver
On November 9, 2020 1:54:33 PM GMT+02:00, Peter Stuge wrote:
>Andreas K. Hüttel wrote:
>> it's probably time to deprecate the amd64 17.0 profiles!
>
>I for one am not so excited about the amd64 17.1 profiles. On the
>surface
>it appeared to me that one developer has "taken over" just about
>eve
> TL;DR: is there really a point in continuing the never-ending always-
> regressing struggle towards supporting LibreSSL in Gentoo?
>
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.
From a team member and initial "believ
Am Dienstag, 29. Dezember 2020, 13:29:35 EET schrieb Peter Stuge:
> I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> to continuosly patch the entire world for libressel.
>
> I'm asking to stop doing that, yet still enable the choice between
> openssl and libressl where tha
> > a) The two cannot be installed concurrently. To fix that would require
> > even
> > more hacks.
>
> As we've discussed in another part of the thread, that's not really true.
> Both can for sure be installed, just not in the same place and/or
> with same names.
Exactly that is what would requi
Hi all,
since utf8 encoding is everywhere by now, and since switching the useflag
unicode off without taking precautions is a way to hose your installation, I
would propose to medium-term get rid of this flag.
Suggestion:
1) use.force unicode now/soon in the default profiles
2) step by step,
Am Mittwoch, 30. Dezember 2020, 19:53:25 EET schrieb Aisha Tammy:
>
> Yes, this sounds nice.
> What about packages which rely on/give unicode support outside of this flag?
> Like the global icu flag, which supposedly needs dev-libs/icu ?
>
Hmmm... good point. I thought too simple.
1) We want to
Hey all,
it would be great if we could get gcc-10 stable at some point in the near
future... For that purpose we now have a new tracker:
https://bugs.gentoo.org/762907 ("gcc-10-stable", depends on 127 open bugs).
Please have a look if you can help anywhere with the blocking bugs.
Thanks a lo
Replying to a random post here- I'm sorry, briefly after I started this thread
real life got in the way and a lot of other things became more urgent.
As soon as I have time (next weekend?) I'll reply to the many e-mails here.
Thanks -A
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux de
# Andreas K. Hüttel (2021-03-06)
# Fails to build, multiple bugs, outdated, nontrival, unmaintained
# Bug 729876 and several others; removal in 30days
dev-libs/klibc
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
sign
Hi all,
why do we *copy* the timezone file to /etc/localtime, instead of symlinking it
like everyone else?
1) Our handbook recommends:
echo "Europe/Brussels" > /etc/timezone
emerge --config sys-libs/timezone-data
which is effectively doing
echo "Europe/Brussels" > /etc/timezone
cp -f /usr/s
> > 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 us
# 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.
# 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.
# 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,
# 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 s
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,
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=r
>
> -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
>
> 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 rv64g
> > 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 probabl
> 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.)
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 actuall
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 var
# 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-po
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.
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
> > 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, to
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/r
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 com
> > 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 subst
> 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
> >
> > 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
# 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
# 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
>
> 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
> 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
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
# 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 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
>
> 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
# 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
# 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 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
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
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?
>
>
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
> 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
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
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 :)
>
> 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
# 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
# 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 (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,
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:
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
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
>
> 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
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
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
> 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
# 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
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
> 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
# 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
> 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-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
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
>
> 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
# 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,
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
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
> 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
701 - 794 of 794 matches
Mail list logo
