[gentoo-dev] base-system team meeting 15/May 19:00 utc, #gentoo-base

2022-05-08 Thread Andreas K. Huettel
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,

Re: [gentoo-dev] Deprecating repoman

2022-03-10 Thread Andreas K. Huettel
> > > > 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

[gentoo-dev] last rites: net-libs/libnfsidmap

2022-02-27 Thread Andreas K. Huettel
# 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,

Re: [gentoo-dev] [PATCH 01/12] toolchain.eclass: remove EAPI 5 and 6

2022-02-01 Thread Andreas K. Huettel
> 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 >

[gentoo-dev] stable users: sys-libs/glibc-2.33-r10 needs testers

2022-01-27 Thread Andreas K. Huettel
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 th

[gentoo-dev] stable users: sys-libs/glibc-2.33-r9 needs testers

2022-01-25 Thread 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). Please, if you're still running glibc-2.33, consider testing it! We want to stabilize it rather soon. Building and normal use...

[gentoo-dev] last rites: sys-devel/prelink, app-crypt/hmaccalc

2022-01-21 Thread Andreas K. Huettel
# 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

Re: [gentoo-dev] Looking for a solution to the distutils/setuptools .egg-info mess

2022-01-11 Thread Andreas K. Huettel
> > 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

Re: [gentoo-dev] [PATCH] multilib.eclass: add initial defaults for ARCH=loong

2021-12-25 Thread Andreas K. Huettel
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

[gentoo-dev] last rites: app-emulation/qemu-riscv64-bin

2021-12-19 Thread Andreas K. Huettel
+# 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,

Re: [gentoo-dev] Printer drivers and net-print

2021-12-18 Thread Andreas K. Huettel
> 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,

[gentoo-dev] last rites: several perl-core/*

2021-12-12 Thread Andreas K. Huettel
# 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.

Re: [gentoo-dev] Clang/LLVM profile

2021-11-29 Thread Andreas K. Huettel
> 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

[gentoo-dev] 2021 retrospective

2021-11-19 Thread Andreas K. Huettel
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

[gentoo-dev] last rites: several perl-core/*

2021-11-04 Thread Andreas K. Huettel
# 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-dev] Basic upgrade CI testing

2021-11-03 Thread Andreas K. Huettel
> 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

Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

2021-11-03 Thread Andreas K. Huettel
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 leas

Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

2021-11-03 Thread Andreas K. Huettel
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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/sandbox/

2021-10-28 Thread Andreas K. Huettel
> > 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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/sandbox/

2021-10-28 Thread Andreas K. Huettel
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

Re: [gentoo-dev] EAPI=5 must go -- final sprint! :)

2021-10-18 Thread Andreas K. Huettel
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

[gentoo-dev] EAPI=5 must go -- final sprint! :)

2021-10-17 Thread Andreas K. Huettel
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

[gentoo-dev] last rites: virtual/perl-Pod-Parser

2021-10-16 Thread Andreas K. Huettel
# 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,

[gentoo-dev] last rites: net-im/webex

2021-10-16 Thread Andreas K. Huettel
# 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 --

[gentoo-dev] last rites: various perl-core/*

2021-10-13 Thread Andreas K. Huettel
# 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

Re: [gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions

2021-10-05 Thread Andreas K. Huettel
> > 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

Re: [gentoo-dev] Experimental binary package hosting

2021-09-23 Thread Andreas K. Huettel
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

Re: [gentoo-dev] Experimental binary package hosting

2021-09-22 Thread Andreas K. Huettel
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

Re: [gentoo-dev] Experimental binary package hosting

2021-09-21 Thread Andreas K. Huettel
> 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,

[gentoo-dev] Experimental binary package hosting

2021-09-21 Thread Andreas K. Huettel
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

Re: [gentoo-dev] Guidance on distributed patented software

2021-09-21 Thread Andreas K. Huettel
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? > >

[gentoo-dev] last rites : toolchain-glibc.eclass

2021-09-02 Thread Andreas K. Huettel
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:

[gentoo-dev] last rites: dev-perl/POE-API-Peek

2021-08-15 Thread Andreas K. Huettel
# 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

[gentoo-dev] last rites: dev-perl/MooseX-Types-DateTime-ButMaintained dev-perl/MooseX-Types-DateTimeX

2021-08-15 Thread Andreas K. Huettel
# 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,

[gentoo-dev] last rites: dev-perl/Perlbal-XS-HTTPHeaders

2021-08-15 Thread Andreas K. Huettel
# 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

Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation

2021-08-07 Thread Andreas K. Huettel
> > 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

Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation

2021-08-06 Thread Andreas K. Huettel
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

[gentoo-dev] last rites: various perl-core/*

2021-07-31 Thread Andreas K. Huettel
# 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

Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests

2021-07-25 Thread Andreas K. Huettel
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

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

2021-07-24 Thread Andreas K. Huettel
> 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. >

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

2021-07-23 Thread Andreas K. Huettel
> > 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

[gentoo-dev] last rites: several perl-core/*

2021-07-17 Thread Andreas K. Huettel
# 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

[gentoo-dev] last rites: virtual/perl-Pod-Parser

2021-07-17 Thread Andreas K. Huettel
# 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,

Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item

2021-07-14 Thread Andreas K. Huettel
> > > > 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. > >

Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item

2021-07-13 Thread Andreas K. Huettel
> 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

Re: [gentoo-dev] 'pax_kernel' USE flag

2021-06-25 Thread Andreas K. Huettel
> > 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

Re: [gentoo-dev] New Developer: Florian Schmaus (flow)

2021-06-22 Thread Andreas K. Huettel
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

[gentoo-dev] news item: riscv upgrade to 20.0 profiles

2021-06-19 Thread Andreas K. Huettel
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:

Re: [gentoo-dev] Need help with perl-cleaner (and app-admin/gentoo-perl-helpers)

2021-05-13 Thread Andreas K. Huettel
> > 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,

Re: [gentoo-dev] Need help with perl-cleaner (and app-admin/gentoo-perl-helpers)

2021-05-13 Thread Andreas K. Huettel
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 m

[gentoo-dev] Need help with perl-cleaner

2021-05-13 Thread 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. 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.

[gentoo-dev] removal: dev-perl/PortageXS app-portage/demerge app-portage/perl-info

2021-05-09 Thread Andreas K. Huettel
# 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

Re: [gentoo-dev] How to structure our RISC-V support -- Summary

2021-05-08 Thread Andreas K. Huettel
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

Re: [gentoo-dev] How to structure our RISC-V support

2021-05-07 Thread Andreas K. Huettel
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

Re: [gentoo-dev] How to structure our RISC-V support

2021-05-07 Thread Andreas K. Huettel
> 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

Re: [gentoo-dev] How to structure our RISC-V support

2021-05-07 Thread Andreas K. Huettel
> > 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

Re: [gentoo-dev] How to structure our RISC-V support

2021-05-06 Thread Andreas K. Huettel
> > 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

Re: [gentoo-dev] How to structure our RISC-V support

2021-05-06 Thread Andreas K. Huettel
> > -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.

[gentoo-dev] How to structure our RISC-V support

2021-05-06 Thread Andreas K. Huettel
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

Re: [gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted

2021-05-06 Thread Andreas K. Huettel
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

[gentoo-dev] last rites: dev-perl/Sane

2021-04-30 Thread Andreas K. Huettel
# 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

[gentoo-dev] last rites: some outdated perl-core/*

2021-04-30 Thread Andreas K. Huettel
# 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,

[gentoo-dev] Last rites: dev-perl/HTTPD-User-Manage

2021-04-25 Thread Andreas K. Huettel
# 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

2021-04-25 Thread Andreas K. Huettel
# 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 ?

2021-03-22 Thread Andreas K. Huettel
> > 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

[gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-20 Thread Andreas K. Huettel
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

[gentoo-dev] Last rites: dev-libs/klibc

2021-03-06 Thread Andreas K. Huettel
# 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)

Re: [gentoo-dev] New project: binhost

2021-02-21 Thread Andreas K. Huettel
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

[gentoo-dev] Towards getting GCC 10 stable

2021-01-06 Thread Andreas K. Huettel
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

Re: [gentoo-dev] Getting rid of USE=unicode

2020-12-30 Thread Andreas K. Huettel
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

[gentoo-dev] Getting rid of USE=unicode

2020-12-30 Thread Andreas K. Huettel
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-30 Thread Andreas K. Huettel
> > 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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Andreas K. Huettel
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

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Andreas K. Huettel
> 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

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-09 Thread Andreas K. Huettel
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

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-07 Thread Andreas K. Huettel
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

Re: [gentoo-dev] LiveCD Project disbanding: packages up for grabs

2020-11-07 Thread Andreas K. Huettel
>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.

Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Andreas K. Huettel
> 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

Re: [gentoo-dev] Typo in julia-1.4.0-r2.ebuild

2020-07-01 Thread Andreas K. Huettel
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*. > >

[gentoo-dev] last rites: media-libs/openmoiv

2020-03-28 Thread Andreas K. Huettel
# 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

Re: [gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt

2020-03-27 Thread Andreas K. Huettel
> > 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

[gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt

2020-03-26 Thread Andreas K. Huettel
# 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

Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread Andreas K. Huettel
> So, my question is, why can't we add a noarch/~noarch keyword and see > how things go? If it gets abused we can always nuke it later. I'm pretty sure we already discussed this in very much detail in the past at least once, and came to the conclusion that there are problems with that approach.

Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread Andreas K. Huettel
Am Mittwoch, 18. März 2020, 19:40:57 CET schrieb William Hubbs: > There would be no need to cc all arches on the bug, just make noarch@g.o > an alias that emails to all arch teams. We might as well just make an allarches@... alias. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux

Re: [gentoo-dev] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches

2020-03-16 Thread Andreas K. Huettel
> Perhaps we could write a tool that > looks up newer versions of installed ebuilds that have dropped keywords > for a given arch and report which dependencies also need keywording. I > guess we don't have something like that? True, keeping track of long-running stable requests with complicated

Re: [gentoo-dev] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches

2020-03-16 Thread Andreas K. Huettel
> > > > https://github.com/zmedico/portage/compare/master...zmedico:drobbins-track > > -keywords?expand=1 > That's kind of what ALLARCHES is for although IIRC the rules state that > packages should still be initially keyworded in the usual way. Other > distros do "noarch" though so the idea isn't

Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

2020-03-12 Thread Andreas K. Huettel
Am Donnerstag, 12. März 2020, 20:23:56 CET schrieb Michał Górny: > On Thu, 2020-03-12 at 11:44 -0700, Alec Warner wrote: > > On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel > > > > wrote: > > > Someone needs to grow up here. > > > > Meh, to me (so

Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

2020-03-12 Thread Andreas K. Huettel
Am Donnerstag, 12. März 2020, 19:44:15 CET schrieb Alec Warner: > On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel > > wrote: > > Someone needs to grow up here. > > Meh, to me (someone who can't commit to ::gentoo) I have a few concerns > here. First, I don't

[gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

2020-03-12 Thread Andreas K. Huettel
Someone needs to grow up here. -- Weitergeleitete Nachricht -- Betreff: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/ Datum: Mittwoch, 11. März 2020, 09:24:16 CET Von: Patrice Clement An: gentoo-comm...@lists.gentoo.org commit:

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

2020-03-10 Thread Andreas K. Huettel
Reverted [QA]. For reasons see below. Am Dienstag, 10. März 2020, 12:28:25 CET schrieb Patrice Clement: > commit: 34217564ddc5cd46762ffdaeb217aabd905dec6a > Author: Patrice Clement gentoo org> > AuthorDate: Tue Mar 10 10:32:00 2020 + > Commit: Patrice Clement gentoo org> >

Re: [gentoo-dev] Last rites: sci-visualization/gwyddion

2020-01-21 Thread Andreas K. Huettel
Am Mittwoch, 22. Januar 2020, 00:49:08 CET schrieb David Seifert: > # David Seifert (2020-01-21) > # No sign of py3 port, depends on EOL pygtk and gtkglext. > # Many open bugs, no revdeps. > # Bug #443088, #582454, #598682, #623314. Removal in 30 days. > sci-visualization/gwyddion Urgh. Way too

Re: [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.

2020-01-20 Thread Andreas K. Huettel
Am Montag, 20. Januar 2020, 04:43:50 CET schrieb Michael Orlitzky: > In rare cases, a system user will need a real home directory to store > per-user configuration data and/or be accessed interactively by a > human being. In those cases, /home/${username} is an appropriate place > for the user's

Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-05 Thread Andreas K. Huettel
Am Donnerstag, 5. Dezember 2019, 17:09:57 CET schrieb Michał Górny: [...] > +# This file specifies packages that are considered deprecated (but not > +# masked yet). It will trigger pkgcheck warnings whenever other > +# packages depend on them. Just saying, this is an awesome functionality, and

Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Andreas K. Huettel
How about adding yourself as maintainer then? :) Am Donnerstag, 5. Dezember 2019, 14:42:59 CET schrieb Jason A. Donenfeld: > Hi, > > Aaron has marked tons of important and useful Python 2.7 packages for > removal: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fb

Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Andreas K. Huettel
> > TL;DR: If a QA check is enforced by Portage for a reasonably long time, > > does it constitute policy? Or can it be changed unilaterally by Portage > > team? > To avoid these sorts of questions in the future, [snip since offtopic] > In this case, whether or not this is "policy" is beside

[gentoo-dev] last rites: perl-app.eclass

2019-10-23 Thread Andreas K. Huettel
# @DEAD # This eclass is dead and all its consumers have been removed from # the tree. # Please use perl-module.eclass if you need phase functions, and # perl-functions.eclass if you don't. # In overlays, perl-app.eclass usage can be replaced by # perl-module.eclass without further changes. # Bug

[gentoo-dev] last rites: dev-perl/NetxAP

2019-10-15 Thread Andreas K. Huettel
# Andreas K. Hüttel (2019-10-15) # Fails self-tests badly, no revdeps, upstream doesnt care # since 1999. Removal in 30 days. Bug 641530. dev-perl/NetxAP -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc

Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

2019-10-07 Thread Andreas K. Huettel
> > > > Is it appropriate to list services that are not managed by infra on this > > page? > > Yes, in the 'External-run' section of the page. I'll add a stub for > stable-bot now that we have some more details. In any case, since many people *do* rely on it, maybe we should declare it

[gentoo-dev] Re: [PATCH] perl-app.eclass: remove unneeded @USAGE lines

2019-09-27 Thread Andreas K. Huettel
Just do it. (But perl-app.eclass should die in a fire anyway.) Am Freitag, 6. September 2019, 21:02:21 CEST schrieb Ben Kohler: > Signed-off-by: Ben Kohler > --- > eclass/perl-app.eclass | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/eclass/perl-app.eclass

[gentoo-dev] last rites: sci-libs/openfoam-bin

2019-09-05 Thread Andreas K. Huettel
# Andreas K. Hüttel (2019-09-04) # EAPI 2. Brutally outdated and untouched for ages. Removal in # 30 days, bug 688504 sci-libs/openfoam-bin -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is

  1   2   3   4   5   6   7   8   >