Re: [gentoo-dev] New project: binhost

[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 developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Towards getting GCC 10 stable

[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 lot in advace :)
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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 to enable unicode unconditionally whereever that is possible 
without much impact.
2) If that pulls in large libraries like icu, a useflag remains useful.

So maybe instead of any use.forcing we should just go through the ebuilds and 

a) reduce the number of occurences of IUSE=unicode as much as possible
b) switch to IUSE=icu or similar where that makes sense

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Getting rid of USE=unicode

[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 step, modify ebuilds to enable the functionality unconditionally 
(and if necessary fix depstrings)

3) at some point the flag is gone

Opinions?

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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 require even more hacks. Given how many different 
and more or less hackish build systems exist in the Gentoo tree, this is just 
not feasible.

> > -> all relevant ssl consumers on the user's system must be linked against
> > the one selected
> 
> Also not the case. Considering the two installed in different paths
> with same names it's still easy for consumers to use one or the other
> with -rpath at link time.

Dito...

Please remember, the point is to keep this somewhat maintainable.

> > c) If a single package that the user wants to install is not "fixed" for
> > one ssl library, it blocks that option for all packages.
> 
> Please think of a libressl ebuild in a new way.

Well, if it just drops the library somewhere where nothing can use it... that 
can for sure be done, but also does not really help anyone.

> > I guess if you can come up with a solution that
> > * provides secure usage of the libraries,
> > * provides choice to the user, and
> > * doesn't lead to unupgradeable systems or unresolvable dependencies
> > we'd all be happier. So far we haven't found one.
> 
> Right! I think letting a libressl ebuild install only libtls could be a
> good start, because it provides a stable situation, without risking
> conflicts. Would you agree?

No idea to be honest, and not much opinion on this.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

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

[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 that is possible without patches, even
> if that's only openntpd and one other package.

a) The two cannot be installed concurrently. To fix that would require even 
more hacks. 
-> all relevant ssl consumers on the user's system must be linked against the 
one selected

b) The libraries are not guaranteed to be binary compatible, so switching 
implementation requires rebuilding consumers. Especially since this is a 
security-sensitive package.
-> all relevant ssl consumers on the user's system must be *built* against the 
one selected

Which leads us to 

c) If a single package that the user wants to install is not "fixed" for one 
ssl library, it blocks that option for all packages.
-> horrible (but real and justified) emerge blockers and general hilarity ensue

I guess if you can come up with a solution that
* provides secure usage of the libraries,
* provides choice to the user, and
* doesn't lead to unupgradeable systems or unresolvable dependencies
we'd all be happier. So far we haven't found one.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

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

[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 "believer", yes please. 
Libressl turns out to be more pain than gain.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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
>everything,
>which (regardless of the individual) can't be a good thing..
>

Please wait a bit longer, I'm still working on my evil world domination plans! 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[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 versions in new
>installs
 and accidentally downgrading to 17.0 with some saying they see it
>first.

 A simple reordering could help new installs.
>> 
>> Independent of this useful change, it's probably time to deprecate
>the amd64 
>> 17.0 profiles!
>> 
>
>Prefix bootstrap script still makes new installations to use it

Meh. Time to change that then...
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[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

[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
Description: This is a digitally signed message part.

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

[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*.
> 
> Yours sincerely,
> 
> Xianwen


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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 signed message part.

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

[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 to the bug is easiest, feel free! -A 


> 
> Kind Regards,
> Jaco


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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
Description: This is a digitally signed message part.

Re: [gentoo-dev] rfc: noarch keyword

[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. What's different now?

Sorry, but for the moment your mail is a bit big on fluffy ideas and a bit thin 
on details how it's going to work... as unsorted examples,
* how is allarches supposed to interact with use.stable.mask?
* who is doing allarches stabilizations?
* what are the allowed dependencies? obviously an allarches package can only 
depend on other allarches packages...
* what happens if an allarches package gets, e.g., masked on one arch?

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] rfc: noarch keyword

[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 developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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 lists is 
a serious pain. Also true, additional automation could help here. 

In the end this boils down to the question, can we do something better than 
bugzilla for stabilization and keywording tracking? A dedicated webapp (which 
still needs to be integrated with bugzilla somehow to process blockers)?

Obviously this is work. I am tempted to suggest Google Summer of Code, except 
that experience tells me that's the fastest way to get a half-functional pile 
of code that never goes into production. Any better ideas?

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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 without precedent.

It was a long discussion to get ALLARCHES finalized and accepted, and now 
barely anyone is using it. (Most arch teams never bothered to adapt their 
workflow.) Maybe we should do that for a start? 

Anyway, ALLARCHES only affects stabilization, not keyword requests.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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 (someone who can't commit to ::gentoo) I have a few concerns
> > here. First, I don't see a lot of QA reverts on the gentoo-dev list. Is it
> > common practice to post reverts publicly?
> 
> I suppose that a part of the problem is the default Reply-To in these
> mails.

Which was deliberately added...

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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 see a lot of QA reverts on the gentoo-dev list. Is it
> common practice to post reverts publicly? 

It somehow depends on
* how abysmal, and
* how typical

> I'm also not sure intimating that people are acting like children is
> helpful.

You seem to to have not much interaction with the person in question.



-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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: 81a65d7da5b5e8b9e48323d13da05525d08b9551
Author: Patrice Clement  gentoo  org>
AuthorDate: Wed Mar 11 08:21:58 2020 +
Commit: Patrice Clement  gentoo  org>
CommitDate: Wed Mar 11 08:24:03 2020 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=81a65d7d

app-office/calcurse: drop package to m-n.

Package-Manager: Portage-2.3.89, Repoman-2.3.20
Signed-off-by: Patrice Clement  gentoo.org>

 app-office/calcurse/metadata.xml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/app-office/calcurse/metadata.xml b/app-office/calcurse/metadata.xml
index d5b9396fdc3..aa7b56c65ee 100644
--- a/app-office/calcurse/metadata.xml
+++ b/app-office/calcurse/metadata.xml
@@ -1,9 +1,7 @@
 
 http://www.gentoo.org/dtd/metadata.dtd;>
 
-
-   monsie...@gentoo.org
-
+
 Calcurse is a text-based personal organizer which helps 
keeping
 track of events and everyday tasks. It contains a calendar, a 'todo' list, 
and
 puts your appointments in order. The user interface is configurable, and one 
can


-
-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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>
> CommitDate: Tue Mar 10 11:28:15 2020 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34217564
> 
> app-office/calcurse: version bump.
> 
> Package-Manager: Portage-2.3.89, Repoman-2.3.20
> Signed-off-by: Patrice Clement  gentoo.org>
> 
>  app-office/calcurse/Manifest  |  1 +
>  app-office/calcurse/calcurse-4.5.0.ebuild | 47
> +++ 2 files changed, 48 insertions(+)
> 
> diff --git a/app-office/calcurse/Manifest b/app-office/calcurse/Manifest
> index a709a800e0c..d61266faf9b 100644
> --- a/app-office/calcurse/Manifest
> +++ b/app-office/calcurse/Manifest
> @@ -1 +1,2 @@
>  DIST calcurse-4.4.0.tar.gz 620263 BLAKE2B
> 8fbe875f5e757ec3c11b9c23a994260403ee990bfcb3d4c41eefbf06a6db9e76cd5157e32b1
> 1c3fdc049896d5db3a9856862724902dab1cb48e0b00ef5df6f73 SHA512
> 43d30ad68bb39aaa9460644a691e66cbb15b9930737581583da65d00214c70fb1148a0edeca
> 4430abb7a5cef2821b0f4c6fdbed8188d9ea5da5fedc4f95fa07c +DIST
> calcurse-4.5.0.tar.gz 657976 BLAKE2B
> 5cad43340cb973d402c92b7963f9c13e46acbb2f802df2ab447221913daa6b28872a323b743
> bc31be0c7358ea8e7d51d08054c81f3376d3dc07f5837d41be45f SHA512
> 795eae7c62b89c733049f0c137da398ce3dd5fba78f9a2c323aacdf8b176cf37bd9d0768dbd
> ac0bb1cb64cd248b1d851efd059836fbbbdd9665fa47beff3b872
> 
> diff --git a/app-office/calcurse/calcurse-4.5.0.ebuild
> b/app-office/calcurse/calcurse-4.5.0.ebuild new file mode 100644
> index 000..46600edc61f
> --- /dev/null
> +++ b/app-office/calcurse/calcurse-4.5.0.ebuild
> @@ -0,0 +1,47 @@
> +# Copyright 1999-2020 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit autotools eutils multilib-minimal

eutils is not used anywhere.

> +
> +DESCRIPTION="a text-based calendar and scheduling application"
> +HOMEPAGE="https://calcurse.org/;
> +SRC_URI="https://calcurse.org/files/${P}.tar.gz;
> +
> +LICENSE="BSD-2"
> +SLOT="0"
> +KEYWORDS="~amd64 ~ppc ~ppc64 ~x86"
> +IUSE="doc"

Is that "doc" doing anything ...

> +
> +RDEPEND="
> + dev-python/httplib2

As far as I can see, httplib2 installs only python packages specific for python 
versions, no utilities to be called from shell. How do you make sure that it's 
installed for currently active python?

> + sys-libs/ncurses:0="
> +
> +DEPEND="
> + ${RDEPEND}
> + doc? ( app-text/asciidoc )"

... except adding a DEPEND?
Also, with EAPI=7 asciidoc should probably be a BDEPEND.

> +
> +PATCHES=(
> + "${FILESDIR}"/${PN}-4.2.1-tinfo.patch
> +)
> +
> +# Most tests fail.
> +RESTRICT="test"

is there an open bug about it?

> +
> +src_prepare() {
> + default
> + eautoreconf
> +}
> +

> +multilib_src_configure() {
> + ECONF_SOURCE="${S}" econf
> +}
> +

Likely redundant.

> +src_compile() {
> + multilib-minimal_src_compile
> +}
> +
> +src_install() {
> + multilib-minimal_src_install
> +}

Completely pointless redefinition of src_compile and src_install (both are 
exported by multilib-minimal.eclass)...

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

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

[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 useful to be dropped. I'll take it and see what I can do.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

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

[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 home directory. Using /home is allowed and encouraged
> by the FHS, and there are no real technical obstacles to it aside from
> an install-time QA warning about the path.

Why *isn't* some /var/lib/... possible here?

I mean, user configuration works perfectly fine there, even if you have to 
log in. And the purpose of the account is closer to, say, root (with its 
nonstandard home directory location) than a normal user.

I've seen all possible site-specific changes to /home layout, including, 
e.g., 
* /home/server1/username
* /home/large/username
* /home/u/username
...
which would all get somehow messy if a system account with a fixed path is 
forced in there.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

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

[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 will be highly useful.

So, yes++

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[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
> b5768cc6f38ac
> 
> There are quite a few useful packages in here.
> 
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon. Many of those packages are
> actively maintained upstream packages. abcde, beets, and tahoe-lafs
> immediately jump out.
> 
> Thanks,
> Jason


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

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

[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 the point. No
> one else wants to remove this check ...

If that really were the case, we wouldnt have this discussion.

And as we all know *any* action by QA will immediately lead to complaints 
about abuse of QA powers...

FTR, yes I consider that these old QA checks embody QA policy. 14 years of it.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

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

[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 637836.  Removal in 14 days.

-- 
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/NetxAP

[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
Description: This is a digitally signed message part.

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

[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 
official? [+]

And, if that's OK with both of you, move it onto infra hardware?

Happy to sponsor both for the next council meeting agenda.


[+] At some point the one remaining whiner doesnt count anymore.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

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

[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 b/eclass/perl-app.eclass
> index 6b762dd83b3..074902294e5 100644
> --- a/eclass/perl-app.eclass
> +++ b/eclass/perl-app.eclass
> @@ -21,7 +21,6 @@ case "${EAPI:-0}" in
>  esac
> 
>  # @FUNCTION: perl-app_src_prep
> -# @USAGE: perl-app_src_prep
>  # @DESCRIPTION:
>  # This is a wrapper function to perl-app_src_configure().
>  perl-app_src_prep() {
> @@ -29,7 +28,6 @@ perl-app_src_prep() {
>  }
> 
>  # @FUNCTION: perl-app_src_configure
> -# @USAGE: perl-app_src_configure
>  # @DESCRIPTION:
>  # This is a wrapper function to perl-module_src_configure().
>  perl-app_src_configure() {
> @@ -37,7 +35,6 @@ perl-app_src_configure() {
>  }
> 
>  # @FUNCTION: perl-app_src_compile
> -# @USAGE: perl-app_src_compile
>  # @DESCRIPTION:
>  # This is a wrapper function to perl-module_src_compile().
>  perl-app_src_compile() {


-- 
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: sci-libs/openfoam-bin

[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 a digitally signed message part.

[gentoo-dev] Last rites: dev-java/jlayer

[Andreas K. Huettel]

# Andreas K. Hüttel  (2019-08-14)
# EAPI=2, ages old, effectively unmaintained. Gone in
# 30 days. Bug 688154
dev-java/jlayer

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 2/6] profiles: enable USE="split-usr" in base

[Andreas K. Huettel]

Am Montag, 15. Juli 2019, 03:49:00 CEST schrieb Michael Orlitzky:
>(This will be especially bad for the people who start
> with USE="-*")

Not recommended, not supported. Garbage in, garbage out.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: sys-apps/cobalt-panel-utils

[Andreas K. Huettel]

# Andreas K. Hüttel  (23 Jun 2019)
# EAPI2, broken HOMEPAGE, maintainer-needed, lots of QA warnings,
# for hardware that was EOL'ed <=2007. Removal in 30 days. Bug 681060
sys-apps/cobalt-panel-utils


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: www-apache/mod_tidy

[Andreas K. Huettel]

# Andreas K. Hüttel  (23 Jun 2019)
# last release was 2006, EAPI2, maintainer-needed, depends on
# app-text/htmltidy; removal in 30 days, bug 686324
www-apache/mod_tidy

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] EAPI 2 must die

[Andreas K. Huettel]

Hi all, 

for the package maintainers among you, here's the list of remaining EAPI=2 
packages. Please help getting the number down to zero soon!!!

Cheers, 
Andreas

app-emulation/ganeti-instance-debootstrap-0.11
app-misc/dnetc-2.9108.517
app-misc/dnetc-2.9110.519b
dev-dotnet/flickrnet-bin-2.2-r1
dev-java/glassfish-jms-api-1.1.2.2.04
dev-java/jlayer-1.0.1
dev-java/resin-servlet-api-3.1.12
dev-libs/bglibs-1.106-r1
dev-lisp/clisp-2.48-r1
dev-lua/toluapp-1.0.93
dev-tex/culmus-latex-0.7
dev-tex/dvipost-1.1-r2
media-fonts/culmus-0.120-r4
net-analyzer/nagtrap-0.1.3
net-libs/cvm-0.76
net-misc/adjtimex-1.29-r1
net-misc/asterisk-extra-sounds-1.4.11
net-misc/asterisk-moh-opsound-2.03
net-misc/cfengine-2.2.10-r4
net-misc/tokyotyrant-1.1.41-r1
sci-libs/openfoam-bin-1.6
sys-apps/cobalt-panel-utils-1.0.2
sys-apps/powerpc-utils-1.1.3.18-r2
sys-boot/netboot-0.10.2
sys-process/fuser-bsd-1142334561
www-apache/mod_tidy-0.5.5-r1

Already masked for removal:

app-accessibility/festival-2.1-r1
dev-java/glassfish-connector-api-1.1.2.2.04
dev-util/antlrworks-1.2.3
dev-util/pmd-4.2.5
net-mail/qmail-qfilter-2.1-r1
net-misc/mindterm-3.4

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

[gentoo-dev] last rites: dev-util/antlrworks

[Andreas K. Huettel]

# Andreas K. Hüttel  (5 Jun 2019)
# Unhandled version bumps since 2015, bug 293306. EAPI=2.
# Removal in 30 days unless updated.
dev-util/antlrworks

-- 
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-java/glassfish-connector-api

[Andreas K. Huettel]

# Andreas K. Hüttel  (5 Jun 2019)
# Fails to build, bug 680252. EAPI=2. Removal in 30 days
# unless fixed.
dev-java/glassfish-connector-api

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: Announcing RISC-V

[Andreas K. Huettel]

So here's a small update:

* An initial stage is available at 
  https://dev.gentoo.org/~dilfridge/stages/rv64gc-multilib/
  It's verified working, in the sense that I can unpack it, chroot
  into it, and have it rebuild itself (emerge -eav world) without errors.

* @system is keyworded, and the multilib profile has been marked stable
  (i.e. repoman will enforce dependency-tree consistency).
  A lot of useflags are still masked though. Also, *only* python-3.7 is
  available.

Cheers, 
Andreas

Am Freitag, 3. Mai 2019, 23:34:40 CEST schrieb Andreas K. Huettel:
> Hi all,
> 
> after some preparations, we're happy to announce (initially experimental)
> support for a new arch: riscv
> 
> * The project page is at https://wiki.gentoo.org/wiki/Project:RISC-V
>   Feel free to join if you want to help and/or even have hardware.
>   We also have a dedicated IRC channel, #gentoo-riscv
> 
> * The keyword is "~riscv"; no stable keyword will be used in the beginning.
> 
> * We will initially add two profiles to profile.desc:
>   default/linux/riscv/17.0/rv64gc/lp64d (non-multilib, 64bit hardfloat)
>   default/linux/riscv/17.0/rv64gc (multilib lp64d/lp64, i.e. hard/softfloat)
> 
> * Stage builds have been tested with an overlay and work fine.
>   I'll publish initial stage3 images soon and will work with releng to get
>   autobuilds running.
> 
> * Once this all is done I'll draft an announcement for the main web page.
> 
> Cheers,
> Andreas


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: dev-lang/confluence

[Andreas K. Huettel]

# Andreas K. Hüttel  (11 May 2019)
# Severely outdated, no commits since 2009, EAPI=2.
# Bug 679686. Removal in 30 days.
dev-lang/confluence

-- 
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-embedded/tavrasm

[Andreas K. Huettel]

# Andreas K. Hüttel  (11 May 2019)
# Build failures, other QA issues, EAPI=2. See bug 681046
# Removal in 30 days.
dev-embedded/tavrasm

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: app-accessibility/festival and reverse dependencies

[Andreas K. Huettel]

# Andreas K. Hüttel  (11 May 2019)
# Outdated, EAPI=2, unmaintained, segfaults immediately.
# See bug 634928 and bug 612980. Removal in 30 days.
app-accessibility/festival
app-accessibility/festival-freebsoft-utils
app-accessibility/festival-hts
app-accessibility/festival-it
app-accessibility/festival-ru
app-accessibility/perlbox-voice
app-accessibility/pidgin-festival
dev-ros/sound_play


-- 
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] Announcing RISC-V

[Andreas K. Huettel]

Hi all, 

after some preparations, we're happy to announce (initially experimental) 
support for a new arch: riscv

* The project page is at https://wiki.gentoo.org/wiki/Project:RISC-V
  Feel free to join if you want to help and/or even have hardware.
  We also have a dedicated IRC channel, #gentoo-riscv

* The keyword is "~riscv"; no stable keyword will be used in the beginning.

* We will initially add two profiles to profile.desc: 
  default/linux/riscv/17.0/rv64gc/lp64d (non-multilib, 64bit hardfloat)
  default/linux/riscv/17.0/rv64gc (multilib lp64d/lp64, i.e. hard/softfloat)

* Stage builds have been tested with an overlay and work fine.
  I'll publish initial stage3 images soon and will work with releng to get
  autobuilds running.

* Once this all is done I'll draft an announcement for the main web page.

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: dev-libs/elfutils/

[Andreas K. Huettel]

Public service announcement: Calling for stabilization requires maintainer 
acknowledgment.

While there may be parts of Gentoo where this requirement is seen a bit more 
loosely, it is definitely true for TOOLCHAIN and BASE-SYSTEM.

Cheers, 
Andreas

--  Weitergeleitete Nachricht  --

Betreff: [gentoo-commits] repo/gentoo:master commit in: dev-libs/elfutils/
Datum: Samstag, 6. April 2019, 17:25:11 CEST
Von: Andreas K. Hüttel 
An: gentoo-comm...@lists.gentoo.org

commit: 7ef6ada6d119ed6afccc9d6fb2006bc3e2814b40
Author: Andreas K. Hüttel  gentoo  org>
AuthorDate: Sat Apr  6 15:23:54 2019 +
Commit: Andreas K. Hüttel  gentoo  org>
CommitDate: Sat Apr  6 15:24:59 2019 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7ef6ada6

dev-libs/elfutils: Undo stabilization of 0.176

Stabilization was initiated without acknowledgment by toolchain

The result of the stabilization is a configuration in stable that is
unable to build the kernel, see bug 671760.

Bug: https://bugs.gentoo.org/676794
Bug: https://bugs.gentoo.org/671760
Package-Manager: Portage-2.3.62, Repoman-2.3.12
Signed-off-by: Andreas K. Hüttel  gentoo.org>

 dev-libs/elfutils/elfutils-0.176.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dev-libs/elfutils/elfutils-0.176.ebuild b/dev-libs/elfutils/
elfutils-0.176.ebuild
index 1c62b617a25..4c75e71b437 100644
--- a/dev-libs/elfutils/elfutils-0.176.ebuild
+++ b/dev-libs/elfutils/elfutils-0.176.ebuild
@@ -11,7 +11,7 @@ SRC_URI="https://sourceware.org/elfutils/ftp/${PV}/$
{P}.tar.bz2"
 
 LICENSE="|| ( GPL-2+ LGPL-3+ ) utils? ( GPL-3+ )"
 SLOT="0"
-KEYWORDS="~alpha amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 
~sh sparc ~x86 ~amd64-linux ~x86-linux"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 
~sh ~sparc ~x86 ~amd64-linux ~x86-linux"
 IUSE="bzip2 lzma nls static-libs test +threads +utils"
 
 RDEPEND=">=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}]


-
-- 
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] the state of dev-lang/lua

[Andreas K. Huettel]

Am Samstag, 23. März 2019, 22:23:27 CET schrieb William Hubbs:
> Hi all,
> 
> Soon I will be working on fixing up the state of dev-lang/lua, and there
> are a couple of things I want to mention.
> 
> The first thing is liblua as a shared library. If you are using lua
> internally in a program, upstream strongly recommends not linking it
> this way; it is supposed to be statically linked into the executable.
> Because of this, and because of the amount of custom patching we do to
> maintain liblua as a shared library, I plan to stop creating the shared
> library.
> 

Please dont. Static linking is a security nightmare.

I'd much rather consider removing the static library, and fix programs broken 
by that. (No matter what silly opinions lua upstream has.)

-- 
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] glibc-2.28 stabilization

[Andreas K. Huettel]

Hi all, 

it's that time again, glibc-2.28 will go stable soon. As a developer, if you 
haven't updated your box already anyway, feel free to do so and start testing.

You need

=sys-libs/glibc-2.28-r5
=net-dns/libidn2-2.1.1a

If you encounter serious problems, please make them block bug 674126.

Known issues:

* https://wiki.gentoo.org/wiki/Project:Toolchain#glibc-2.28
  Things listed here should essentially be fixed in the tree (well, except 
  tests on smaller arches).

* Rumors that glusterfs needs a reboot after update. 
  No I dont know more either.

* Bug 672918: sys-apps/sandbox segfaults in sb_check_exec() for programs
  compiled with sys-devel/clang-7.0.1, >=sys-libs/glibc-2.28, -fuse-ld=lld and
  -Wl,--hash-style=gnu
  I've tried multiple times to find someone who knows more here. All my pings
  were essentially ignored, which is why I'm now assuming that clang
  is unmaintained and unsupported. If breaking clang-7 is a problem, please
  prove me otherwise; I'm not waiting anymore.

Cheers, 
Andreas

-- 
PD Dr. Andreas K. Huettel
Institute for Experimental and Applied Physics
University of Regensburg
93040 Regensburg
Germany

tel. +49 151 241 67748 (mobile)
tel. +49 941 943 1618 (office)
fax +49 941 943 3196
e-mail andreas.huet...@ur.de
http://www.akhuettel.de/


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: app-arch/freeze

[Andreas K. Huettel]

# Andreas K. Huettel  (23 Feb 2019)
# Fails to build with glibc-2.28, bug 669206.
# Removal in 30 days.
app-arch/freeze

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] EAPI=2 must die!!!

[Andreas K. Huettel]

Hey all, 

there are only 92 ebuilds with EAPI=2 left in the tree. Let's make sure this 
number goes down faaast!

Cheers, 
Andreas

app-accessibility/festival-2.1-r1
app-emulation/ganeti-htools-0.3.1
app-emulation/ganeti-instance-debootstrap-0.11
app-misc/bottlerocket-0.04c-r1
app-misc/dnetc-2.9108.517
app-misc/dnetc-2.9110.519b
app-text/bibutils-4.12
app-text/refbase-0.9.5
dev-dotnet/flickrnet-bin-2.2-r1
dev-embedded/tavrasm-1.22-r1
dev-java/dbus-java-2.7-r1
dev-java/echo2-2.1.1
dev-java/glassfish-connector-api-1.1.2.2.04
dev-java/glassfish-jms-api-1.1.2.2.04
dev-java/idm-console-framework-1.1.7
dev-java/jgroups-2.9.0
dev-java/jicmp-1.0.2
dev-java/jinklevel-0.1
dev-java/jlayer-1.0.1
dev-java/jline-1.0
dev-java/jvyamlb-0.2.5
dev-java/libmso-0.1
dev-java/libreadline-java-0.8.0-r3
dev-java/matrix-toolkits-java-0.9.12
dev-java/nailgun-0.7.1-r1
dev-java/proguard-4.5
dev-java/resin-servlet-api-3.1.12
dev-java/sat4j-core-2.2.0
dev-java/sat4j-core-2.3.1-r1
dev-java/sat4j-pseudo-2.2.0
dev-java/sat4j-pseudo-2.3.1
dev-java/tijmp-0.8
dev-java/xjavac-20110814
dev-java/zemberek-2.1.1
dev-lang/confluence-0.10.6
dev-lang/mozart-stdlib-1.4.0-r1
dev-libs/bglibs-1.106-r1
dev-lisp/clisp-2.48-r1
dev-lua/toluapp-1.0.93
dev-ml/ocaml-autoconf-1.1
dev-scheme/guile-cairo-1.4.0
dev-tex/culmus-latex-0.7
dev-tex/curve-1.16
dev-tex/dvi2gr-0.4
dev-tex/dvipost-1.1-r2
dev-tex/revtex-4.1_p2-r1
dev-util/antlrworks-1.2.3
dev-util/btyacc-3.0-r2
dev-util/ftnchek-3.3.1-r1
dev-util/pmd-4.2.5
dev-vcs/easygit-1.6.5.5
mail-filter/libmilter-1.0.2
media-fonts/culmus-0.120-r4
media-gfx/flam3-
media-gfx/openclipart-0.20
media-gfx/pixie-2.2.6-r1
media-gfx/xloadimage-4.1-r11
media-sound/id3ed-1.10.4
media-sound/mt-daapd-0.2.4.2
media-sound/peercast-0.1218-r2
media-sound/vkeybd-0.1.18d
net-analyzer/barnyard-0.2.0-r3
net-analyzer/barnyard2-1.9
net-analyzer/nagtrap-0.1.3
net-libs/cvm-0.76
net-libs/cvm-0.96
net-mail/mailfront-1.16
net-mail/qmail-autoresponder-0.97-r1
net-mail/qmail-autoresponder-0.97-r2
net-mail/qmail-qfilter-2.1-r1
net-misc/adjtimex-1.29-r1
net-misc/asterisk-extra-sounds-1.4.11
net-misc/asterisk-moh-opsound-2.03
net-misc/cfengine-2.2.10-r4
net-misc/mindterm-3.4
net-misc/secpanel-0.6.1-r1
net-misc/smbc-1.2.2-r2
net-misc/tokyotyrant-1.1.41-r1
sci-electronics/gnucap-0.35.20091207
sci-libs/openfoam-bin-1.6
sys-apps/cobalt-panel-utils-1.0.2
sys-apps/makedev-3.23.1
sys-apps/powerpc-utils-1.1.3.18-r2
sys-block/scsiadd-1.97
sys-boot/netboot-0.10.2
sys-process/fuser-bsd-1142334561
sys-process/supervise-scripts-4.0
www-apache/mod_tidy-0.5.5-r1
www-misc/visitors-0.7-r1
x11-terms/root-tail-1.2-r3
x11-themes/fluxbox-styles-fluxmod-20050128-r1
x11-wm/vtwm-5.4.7-r1

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: app-misc/ckermit

[Andreas K. Huettel]

# Andreas K. Hüttel  (1 Jan 2019)
# Fails to build with glibc-2.28. Removal in 30days (unless
# fixed). Bug 669332
app-misc/ckermit

-- 
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] vmware project "empty"

[Andreas K. Huettel]

Hi all, 

after me leaving (*), there are no members in the vmware project anymore. 
Luckily it only maintains one remaining package in the tree, app-emulation/
open-vm-tools. 

We still have the vmware overlay, which is mainly user-maintained at the 
moment.

So, either join if you're interested in reviving Gentoo vmware, or we'll 
disband the project at some point. 

Cheers, 
Andreas

(*) I didn't pay for participation in the academic license program anymore, 
since qemu/kvm fulfills all my virtualization needs.

-- 
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-tex/revtex

[Andreas K. Huettel]

# Andreas K. Hüttel  (25 Dec 2018)
# Included in dev-tex/texlive-publishers-2017; there is no
# need for a separate package anymore. Removal in 30 days.
dev-tex/revtex

-- 
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] up for grabs: www-misc/zoneminder

[Andreas K. Huettel]

www-misc/zoneminder is up for grabs since I dont use it anymore and have no 
time for maintaining it...

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs from xmw@g.o

[Andreas K. Huettel]

Am Montag, 26. November 2018, 02:37:14 CET schrieb Benda Xu:
> Michał Górny  writes:
> 
> 
> > x11-wm/xpra
> 
> 
> I take this, the "X Persistent Remote Apps".

Happy to help, I'm also using this. 

(Awesome unknown app of the year. The one thing that makes Mathematica useful 
over a network link. :)

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH] fortran-2.eclass: support EAPI 7

[Andreas K. Huettel]

> 
> -inherit eutils toolchain-funcs
> +inherit toolchain-funcs
> 
>  case ${EAPI:-0} in
> - 4|5|6) EXPORT_FUNCTIONS pkg_setup ;;
> + 4|5|6|7) EXPORT_FUNCTIONS pkg_setup ;;
>   *) die "EAPI=${EAPI} is not supported" ;;
>  esac
> 

^ The disadvantage of this is that eutils inheritance then suddenly disappears 
for all ebuilds. And you don't know who assumed implicitly somewhere that 
inheriting fortran-2 makes epatch available...

So how about still inheriting eutils for EAPI 4,5,6 and only dropping it for 
EAPI 7 ?!


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: dev-tcltk/ck

[Andreas K. Huettel]

# Andreas K. Hüttel  (20 Oct 2018)
# Fails to build with glibc-2.27, bug 648620. No reverse
# dependencies. Removal in 30 days.
dev-tcltk/ck

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Is there any way I can help with pull requests?

[Andreas K. Huettel]

> I've always considered the entry barrier to become a dev too much work for
> keeping a small involvement. I might just be lazy or not interested enough
> I agree. Still I must not be the only one. I might also just have a wrong
> impression of what's needed.

Well, in the end the quizzes mostly reflect what you're supposed to know as a 
dev. If you are ready to become one, writing them down shouldn't take more 
than a day. 

(Hey, even if not, researching the answers and writing a first version down 
shouldn't take more than a day.)


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] tcltk project has no members

[Andreas K. Huettel]

Dear all, 

the tcltk project has no members, and noone is cc'ed on the tcltk@ alias. 

If you want to help maintaining this, please sign up for project and alias.

If both are still empty in two weeks, the 39 packages become maintainer-needed 
(so there is no "illusion of maintainership") and the project is removed.

Cheers,
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Changing policy about -Werror

[Andreas K. Huettel]

> If a package really ought to have
> -Werror due to a very good reason and is properly maintained to support it,
> then there is nothing wrong with inventing a USE flag to give users the
> option of enforcing that.

There is something very *much* wrong with that.

1) It's trivial to enforce -Werror via the packages.env mechanism on specific 
packages (e.g. those that you maintain).

2) Compared to that, an additional useflag introduces a lot of unnecessary 
overhead at the package manager level *and* requires yet another level of 
policies and Gentoo-specific definitions.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

Re: [gentoo-dev] Changing policy about -Werror

[Andreas K. Huettel]

> So, if maintainer has enough manpower to support this flag, we
> should allow to keep it.

No.

[Unless maintainer also joins toolchain team and tests everything with every 
release candidate of the compiler.]

You have no idea how much unneccessary pain -Werror caused when gcc started 
warning on "misleading indentation".

Also, I do not see the connection between security and -Werror. No new 
warnings are created and a simple grep finds things.

Finally, any maintainer can add this to his CFLAGS him/herself if s/he wishes 
so.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

Re: [gentoo-dev] Adding USE=udev to linux profiles

[Andreas K. Huettel]

Am Donnerstag, 19. Juli 2018, 23:51:17 CEST schrieb Ben Kohler:
> Hello,
> 
> I'd like to propose adding USE=udev to our linux profiles (in
> profiles/default/linux/make.defaults probably).  This flag is already
> enabled on desktop profiles but it also affects quite a few packages
>
> Any objections to this idea?

We removed the dedicated "server profiles" and told everyone 
"Don't ever use -*"; if you want to have a sane minimal set of features use 
the base profile as e.g. default/linux/amd64/17.0".

If with USE=udev this profile still fulfills the definition of "sane minimal 
set of features", then it's fine. 

(Keep in mind, we have all sorts of people out there running gentoo not only 
on desktops or beefy servers.)

Otherwise it should stay in desktop profile.

Cheers A

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: What means bup?

[Andreas K. Huettel]

Am Freitag, 20. Juli 2018, 02:55:51 CEST schrieb Mikle Kolyada:

> > I think more recently I've been following this format.
> > 
> > cat/pkg: x.y.z bup
> 
> But can you please *stop* doing this as well? It is neither clear
> language *nor* useful reduction.

++

Please stop it.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

[gentoo-dev] gcc-7 going stable now

[Andreas K. Huettel]

Hi all, 

just to give a general heads up, sys-devel/gcc-7.3.0-r3 is now getting 
stabilized on all arches in bug 658444. 

Cheers from the toolchain team, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 0/2] drop git logic from toolchain eclasses

[Andreas K. Huettel]

Am Sonntag, 3. Juni 2018, 03:47:14 CEST schrieb Marty E. Plummer:
> In the live ebuilds using this eclass, the git logic is handled in the
> ebuild itself and not the eclass. Drop the git logic as it uses git-2
> which has been deprecated for quite some time.
> 
> Marty E. Plummer (2):
>   toolchain-binutils.eclass: drop git-2
>   toolchain-glibc.eclass: remove git logic
> 
>  eclass/toolchain-binutils.eclass | 16 +---
>  eclass/toolchain-glibc.eclass| 11 +--
>  2 files changed, 2 insertions(+), 25 deletions(-)

As already discussed in private, this doesnt really make sense... 

Both eclasses are only used in old, stable ebuilds that are being phased out, 
and are in freeze.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] glibc-2.26 just went stable (on amd64)

[Andreas K. Huettel]

As a heads-up, glibc-2.26 just went stable on amd64. 

If you still have open bugs, they now mutate from "doesn't build with 
glibc-2.26" to "doesn't build, treecleaning candidate".

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] glibc-2.26 stabilization soon

[Andreas K. Huettel]

The number of blocker bugs has decreased a lot, so unless something both new 
and serious is coming up I'm going to ask for glibc-2.26 stabilization on
   6/June/2018 
(that is a month after uploading the latest patchset). We really need to get 
this rolling, since the glibc-2.28 release is already approaching. 

If you still have glibc-2.26 related bugs for your packages, please have a 
look at the following link, and contact me if you encounter unsolvable 
problems.

https://wiki.gentoo.org/wiki/Project:Toolchain#glibc-2.26

The biggest trend in the blockers seems to be a delay in ppc stabilizations.

2.27 will be rekeyworded when 2.26 is stable. The impact of 2.27 and 2.28 will 
hopefully be smaller, since then we've successfully made the RPC transition, 
and since these releases contain less breaking changes.

2.25 and earlier will remain available, but be masked because of unresolved 
security issues.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] bug queue size over time

[Andreas K. Huettel]

Am Mittwoch, 2. Mai 2018, 19:45:21 CEST schrieb Matt Turner:
> > 
> > some graphs already exist (and I'm doing it the dumb way, ask me about the
> > details if interested). E.g.,
> > https://www.akhuettel.de/gentoo-bugs/arches.php
> > 
> > Feel free to send me any e-mail addresses you want on a similar page; it's
> > fairly easy to add. I'm only adding fresh data, though, so if I dont have
> > it yet your line will start today.
> 
> Please add mips@ and x11@. Thank you!

mips: is now added to the arches page (as is m68k, sh, s390, sparc), just 
scroll down for the experimental ones
https://www.akhuettel.de/gentoo-bugs/arches.php

x11:
https://www.akhuettel.de/gentoo-bugs/x11.php


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

Re: [gentoo-dev] bug queue size over time

[Andreas K. Huettel]

Am Mittwoch, 2. Mai 2018, 18:42:32 CEST schrieb Paweł Hajdan, Jr.:
> 
> Just checking back here - what would be the best way to graph number of
> bugs with given assignee, preferably with historical backfill?
> 
> I'm not necessarily looking for something ready to use right away. If
> there's some work to be done or code to implement, I may be willing to
> do so.
> 
> Paweł

Hi Pawel, 

some graphs already exist (and I'm doing it the dumb way, ask me about the 
details if interested). E.g., 
https://www.akhuettel.de/gentoo-bugs/arches.php

Feel free to send me any e-mail addresses you want on a similar page; it's 
fairly easy to add. I'm only adding fresh data, though, so if I dont have it 
yet your line will start today.

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: dev-scheme/ikarus

[Andreas K. Huettel]

# Andreas K. Hüttel  (30 Mar 2018)
# Fails to build (bug 408463). EAPI=3 (bug 648452).
# Masked for removal in 30 days.
dev-scheme/ikarus


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Getting glibc-2.26 stable (reminder)

[Andreas K. Huettel]

Am Freitag, 30. März 2018, 19:15:16 CEST schrieb Andreas K. Huettel:
> 
> Hey all,
> 
> now that upstream has already released glibc-2.27, we should think about
> getting glibc-2.26 stable soon. That, however, means work for all of us.
> 

And, as this seems to be a frequently asked question: My plan is to re-add 
keywords to 2.27 once the stable request for 2.26 has arches in cc. 


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Getting glibc-2.26 stable (reminder)

[Andreas K. Huettel]

Re-sending this as a reminder...

-

Hey all, 

now that upstream has already released glibc-2.27, we should think about 
getting glibc-2.26 stable soon. That, however, means work for all of us.

Typical problems:

* Build failures because xlocale.h is gone
  https://bugs.gentoo.org/638010
  Fix: include locale.h instead

* Build failures, undefined reference to 'minor' / 'major'
  https://bugs.gentoo.org/575232
  Fix: additionally include sys/sysmacros.h
  No, we can't delay this further; the inclusion is (finally) 
  also upstream gone in 2.28. Everything we fix now will for
  sure save us trouble later.

* Build failures because of missing rpc support in glibc
  https://bugs.gentoo.org/381391
  See the following wiki page for information:
  https://wiki.gentoo.org/wiki/Project:Toolchain/RPC_implementation

* Build failures because of missing NIS support
  After fixing rpc support, add a dependency on net-libs/libnsl
  (unconditionally).

* Some internal type definitions have changed, which may lead
  to more obscure build problems (rare).

Please test and fix bugs!!! 

If you want to update your otherwise stable system, please
keyword the following (otherwise you'll get blockers):

~sys-libs/glibc-2.26
=net-libs/libnsl-1*
=net-libs/rpcsvc-proto-1*

Feel free to try emerging sys-libs/glibc with FEATURES=test 
(that takes a while). On amd64/x86, nearly all of the ~4000 tests succeed; I 
know of the following problems:
* elf/tst-prelink-cmp fails, still needs analysis
* only with gcc-7.3.0, six tests math/test-?float128* fail (with my CFLAGS)
  This is a gcc regression (miscompilation of truncf128), already submitted
  upstream.
In any case, I think this still looks nice:
Summary of test results:
  7 FAIL
   4109 PASS
 11 UNSUPPORTED
 29 XFAIL
  2 XPASS
Other arches may show more test failures; please file separate bugs per arch;
see https://bugs.gentoo.org/634988#c1 for what is needed for a useful report.

Stabilization tracker (fresh and largely yet empty): 
https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.26-stable

General issue tracker: 
https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.26

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Andreas K. Huettel]

> > 
> > * Mainly, less stuff to memorize. I'll be throwing a party on the day when
> > the last EAPI=0 ebuild is gone. (In the retirement home, probably.)
> 
> This is the argument made by others about the cognitive overhead of
> remembering all the EAPI differences. If the packages are untouched
> for ages and don't require maintenance, my claim is that there is no
> cognitive load to begin with.

That stops the moment something could use a USE- or slot operator dependency 
(because of a tree-wide change that also affects the old package). Then the 
EAPI bump suddenly becomes urgent (and a minor QA-like commit becomes a major 
change).

And no bugs probably just means no users that could file bugs. We really need 
something like gentoostats...

> > [Interestingly, as long as no specific efforts are made, the number of
> > ebuilds in all deprecated EAPI decreases roughly equally and
> > exponentially. That means the probability of any old ebuild to be removed
> > within a certain time interval is a constant as function of time...]
> 
> This is a great point in favor of *not* bothering to proactively bump EAPI.

Not really. It's an asymptotic curve. *If* you want to have it gone 
*completely* at some point, you have to start actively working on that. The 
only question is when, earlier or later... 

I'd guess having an EAPI approach <~ 1% of the tree is probably as good as any 
other criterion.

[[What is interesting but offtopic is that the exponential decay is the same 
for a long timeframe, see [*] third panel... the downward slope of the white 
line for EAPI=0 barely changes, and the other EAPI run parallel to it as long 
as nothing special happens... This means that Gentoo isn't dying after all, 
since the same developer activity takes place!]]

[*] https://www.akhuettel.de/~huettel/plots/eapi.php

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Andreas K. Huettel]

Am Dienstag, 6. März 2018, 02:52:54 CET schrieb Matt Turner:
> EAPI 2 removal bug: https://bugs.gentoo.org/648050
> 
> It seems like tons of churn to update old stable ebuilds to a new
> EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for
> example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise
> functionally identical. Now asking arch teams to retest and
> restabilize. Multiply by 100 or more.

OK so here's my personal opinion: 

Is it worth the effort? Yes, see below.
Is it a high priority task? No.

Is it really that much effort? Well, we're even in the case of EAPI=2 talking 
about only 400 ebuilds of 35000 in total. That's roughly 1% of the tree. And 
I'd strongly suspect that even without the EAPI update it would make very much 
sense to check these 400 old ebuilds and test whether they still work as 
intended. 

What do we gain? 

* Mainly, less stuff to memorize. I'll be throwing a party on the day when the 
last EAPI=0 ebuild is gone. (In the retirement home, probably.)

* Also, it's not just having a bigger number, but also useful features...

Why now EAPI=2? 

* EAPI=3 is nearly gone (27 ebuilds left, scheme & java please get a move! :)
* EAPI=2 is the one with the next-least ebuilds.

While it would be very nice to remove EAPI=0, let's go for easier targets 
first; the number of EAPI=0 ebuilds will decrease organically in the meantime.

[Interestingly, as long as no specific efforts are made, the number of ebuilds 
in all deprecated EAPI decreases roughly equally and exponentially. That means
the probability of any old ebuild to be removed within a certain time interval 
is a constant as function of time...]

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Samstag, 3. März 2018, 15:39:50 CET schrieb Michał Górny:
>
> That's not a solution. That's cheap a cheap excuse that works for one
> package, for today. It does not solve the generic case, it does not mean
> that other members of toolchain or any other team will not end up having
> to remember extra rules like 'do not remove this ebuild because X wants
> it'.

We need to do that anyway, if only as a service to more technically oriented 
users. I think we should keep in mind that the corresponding audiences are 
where we draw our power users and potential developers. 

This idea for sure applies to toolchain packages and parts of base system.
Keeping track of old software we want to keep via, say, a wiki page is the 
easiest part.

As an example, I restored a specific old auto* version because it is required 
for gcc *development* (not usage). 

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: app-pda/p3nfs

[Andreas K. Huettel]

# Andreas K. Hüttel  (03 Mar 2018)
# Fails to build without rpc support in glibc (bug 631044);
# no maintainer, requires obsolete hardware. Removal in
# 30 days.
app-pda/p3nfs

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: app-text/noweb

[Andreas K. Huettel]

# Andreas K. Hüttel  (03 Mar 2018)
# Marked obsolete on CTAN. EAPI=3 ebuild. No consumers.
# Masked for removal in 30 days. Bug 644258
app-text/noweb

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Mittwoch, 28. Februar 2018, 11:57:37 CET schrieb Andreas K. Huettel:
>
> > https://git.centos.org/summary/rpms!glibc.git
> 
> 2.5 and 2.12 aren't there, but for 2.17 it looks good, this seems to be the
> complete patchset. We should be able to translate that into a gentoo branch.

... except that my personal motivation has dropped somewhat when noticing that 
the CentOS package applies 552 (!) patches on top of 2.17.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Mittwoch, 28. Februar 2018, 11:20:36 CET schrieb James Le Cuirot:
> On Wed, 28 Feb 2018 11:10:13 +0100
> 
> "Andreas K. Huettel" <dilfri...@gentoo.org> wrote:
> > another option would be to (try to) revive glibc-2.5, 2.12, and 2.17
> > instead.
> > 

> 
> You maybe won't get the full details of the changes but all the patches
> are here. This looks like a much better breakdown than you get with
> their kernel patches.
> 
> https://git.centos.org/summary/rpms!glibc.git

2.5 and 2.12 aren't there, but for 2.17 it looks good, this seems to be the 
complete patchset. We should be able to translate that into a gentoo branch.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Sonntag, 25. Februar 2018, 07:17:47 CET schrieb Benda Xu:
> Hi all,
> 
> Yes, it's 2018.  But there are still RHEL 4 and 5 systems running
> antique kernels such as 2.6.8 and 2.6.18...

Benda, 

another option would be to (try to) revive glibc-2.5, 2.12, and 2.17 instead.

Yes I know they are even older, but these are the versions that RHEL uses, and 
for which RH still provides support (until 2020 for 2.5, 2024 for 2.12)...
https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping

That however would require that the RHEL patchsets are public somehwere. Which 
I doubt... after all there's an "E" in RHEL...

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

[Andreas K. Huettel]

Am Sonntag, 25. Februar 2018, 07:17:47 CET schrieb Benda Xu:
> Hi all,
> 
> Yes, it's 2018.  But there are still RHEL 4 and 5 systems running
> antique kernels such as 2.6.8 and 2.6.18.  In my experience, many of
> them are data acquisition hubs or computing clusters.  No administrator
> cares about security as long as they "work".
> 
> Under the form "Prefix", Gentoo is set out to rescue users trapped in
> these abandoned wastelands of antiques.  After years of work, we have
> achieved that goal, except one minor thing: glibc periodically drop
> support for old linux kernels, the lastest glibc supporting linux 2.6.8
> is 2.16 and for linux-2.6.18 it is glibc-2.19.
> 
> With the recent reunion of the Toolchain Project, old glibc versions are
> masked and removed, accelerating the adoption of new versions.  This
> opens a new oppotunity for the Prefix: people stops caring about
> unsupported glibc versions, the Prefix Project can take them over
> without worrying about breaking other peoples' machines.

Well, in principle the idea is OK. We already/still keep some old glibc, gcc, 
and binutils versions for that reason.

However, I have a few conditions.

* Only masked. Only prefix keywords.
If you really must unmask them in a specific prefix profile, you must provide 
big fat warnings about the resulting security risks.
(I dont know how things went in prehistoric times, but recently there have 
been a LOT of glibc-related CVEs. Many fixes can be backported, but definitely 
not all of them.)

* No toolchain-glibc.eclass or eblits or similar abominations. Standard QA 
rules apply.

* Try to stick to a minimum of required features (and a minimum of required 
versions).
We want to strongly avoid adding conditionals to other packages. [#]

* Please use our gentoo glibc repo to keep track of branches and patchsets.
Happy to show you the details sometime soon.


[#] If not for such "old version" considerations, we could soon move the 
libtirpc headers to the place where the glibc headers used to live. That could 
save us a ...load of patching and bugfixing. By keeping flexibility and 
compatibility, that is unfortunately not possible.



-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Getting glibc-2.26 stable

[Andreas K. Huettel]

Hey all, 

now that upstream has already released glibc-2.27, we should think about 
getting glibc-2.26 stable soon. That, however, means work for all of us.

Typical problems:

* Build failures because xlocale.h is gone
  https://bugs.gentoo.org/638010
  Fix: include locale.h instead

* Build failures, undefined reference to 'minor' / 'major'
  https://bugs.gentoo.org/575232
  Fix: additionally include sys/sysmacros.h
  No, we can't delay this further; the inclusion is (finally) 
  also upstream gone in 2.28. Everything we fix now will for
  sure save us trouble later.

* Build failures because of missing rpc support in glibc
  https://bugs.gentoo.org/381391
  See the following wiki page for information:
  https://wiki.gentoo.org/wiki/Project:Toolchain/RPC_implementation

* Build failures because of missing NIS support
  After fixing rpc support, add a dependency on net-libs/libnsl
  (unconditionally).

* Some internal type definitions have changed, which may lead
  to more obscure build problems (rare).

Please test and fix bugs!!! 

If you want to update your otherwise stable system, please
keyword the following (otherwise you'll get blockers):

~sys-libs/glibc-2.26
=net-libs/libnsl-1*
=net-libs/rpcsvc-proto-1*

This should be safe for amd64 and x86; for other arches it doesn't hurt to ask 
in #gentoo-toolchain or test in a chroot first. DON'T UPGRADE WITH MIPS OR 
SPARC YET.

Feel free to try emerging sys-libs/glibc with FEATURES=test 
(that takes a while). On amd64/x86, nearly all of the ~4000 tests succeed; I 
know of the following problems:
* elf/tst-prelink-cmp fails, still needs analysis
* only with gcc-7.3.0, six tests math/test-?float128* fail (with my CFLAGS)
  This is a gcc regression (miscompilation of truncf128), already submitted
  upstream.
In any case, I think this still looks nice:
Summary of test results:
  7 FAIL
   4109 PASS
 11 UNSUPPORTED
 29 XFAIL
  2 XPASS
Other arches may show more test failures; please file separate bugs per arch;
see https://bugs.gentoo.org/634988#c1 for what is needed for a useful report.

Stabilization tracker (fresh and largely yet empty): 
https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.26-stable

General issue tracker: 
https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.26

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] News Item: Portage Dynamic Deps

[Andreas K. Huettel]

Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico:
>
> According to Gentoo policy, future ebuild dependency changes need to be
> accompanied by a revision bump in order to trigger rebuilds for users.
> Therefore, you should only need to use --changed-deps=y for a single
> deep @world update. After that, if you encounter installed packages with
> outdated dependencies in a future deep @world update, then you should
> report it as a bug.

Did you come up with a solution how to handle eclass-generated dependency 
changes then?

I'd loathe to have to do identical revision bumps for, say, all perl-
module.eclass consumers...

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Andreas K. Huettel]

Am Mittwoch, 10. Januar 2018, 18:16:33 CET schrieb Vincent-Xavier JUMEL:
> Le 2018-01-10 10:53, Michał Górny a écrit :
> > Last I checked, Gentoo was a Linux distribution. However, some people
> > prefer to turn it into open discussion forum that has nothing to do
> > with
> > making a distribution.
> 
> No it has. Giving power to a subset of users, denying interaction with
> future contributors unless they enroll is the eaxct way to kill Gentoo
> as a community !

We wouldn't have needed to go this far if not for a few outside trolls who
* keep pushing their personal agenda in endless threads,
* confuse their own inability to contribute with being a mistreated underdog,
* and keep commenting opinionated on technical things they plainly have no 
clue about (while whining when are told they sprout bulls##t).

We do not have a problem with "future contributors". I wager those will rather 
increase in numbers once the list spam is gone.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Andreas K. Huettel]

> Does being 'struck off' the list in this way apply to devs, including
> Council and comrel members?

So far noone has even considered "striking" devs off the list. If this even 
were to happen ever, it would have to be backed by a full comrel team decision 
/ vote. And these don't happen often, don't happen quickly, and don't happen 
lightly. (I much prefer fixing the glibc ebuilds, horrible as these may be.)

We have now an imperfect solution to an unneccessary problem. If anyone can 
come up with a better solution (that is still an improvement over doing 
nothing), I'm all ears. List moderation is not one, since a) it still hasn't 
been implemented technically, b) even if that were done, we would still 
require an active moderation team, and c) then we start bikeshedding about the 
moderation rules.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Andreas K. Huettel]

Am Mittwoch, 10. Januar 2018, 10:53:39 CET schrieb Michał Górny:
> 
> I guess you should have voiced your opinion back when discussion was
> taking place instead of being hostile *now* because the Council listened
> to what the developers requested.
> 
> And if you are curious, then I've been asked by multiple developers
> (and a few users) requesting the restriction, and I haven't been
> contacted by a single one who asked otherwise.

^ This. Same experience here.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Andreas K. Huettel]

During the last Gentoo council meeting, the decision was made to implement 
changes to the gentoo-dev mailing list [1].

These changes affect only the gentoo-dev mailing list, and will come into 
effect on 23 January 2018.

* Subscribing to the list and receiving list mail remains as it is now.
* Posting to the list will only be possible to Gentoo developers and
  whitelisted additional participants.
* Whitelisting requires that one developer vouches for you. We intend this
  to be as unbureaucratic as possible.
* Obviously, repeated off-topic posting as well as behaviour against the
  Code of Conduct [2] will lead to revocation of the posting permission.

If, as a non-developer, you want to participate in a discussion on 
gentoo-dev, 
- either reply directly to the author of a list mail and ask him/her to 
forward your message,
- or ask any Gentoo developer of your choice to get you whitelisted.

If, as a developer, you want to have someone whitelisted, please comment on 
bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are vouching 
for a contributor you are expected to keep an eye on their activity.

[1] https://projects.gentoo.org/council/meeting-logs/20171210-summary.txt
[2] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct
[3] https://bugs.gentoo.org/644070  (alias g-dev-whitelist)

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Improving the support for minor arches and less common profiles in CI

[Andreas K. Huettel]

Am Samstag, 6. Januar 2018, 12:10:53 CET schrieb Michał Górny:
> Hi, everyone.
> 
> I think most of us agree that support for minor arches in Gentoo
> is suboptimal, and that we've pretty much been focusing on avoiding
> the problem than really solving it.
> 

I think it would help here to get the arches.desc glep off the ground. Sorry, 
I've been busy with a lot of other things, but I'll try to get this done soon.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

[Andreas K. Huettel]

Am Samstag, 30. Dezember 2017, 13:22:52 CET schrieb Anthony G. Basile:
> Hi everyone,
> 
> We've been stuck on EAPI=4 with toolchain.eclass for a while.  This is
> causing problems with subslotting libraries like mpfr, mpc, gmp and isl
> that gcc depend on (see bug #642316).  I went through and made the
> changes necessary to get the eclass up to EAPI=5 and compile tested
> across the board (ie all dependent ebuilds) for amd64.  Everything looks
> good, so please review and I'll commit if we're okay.

-   confgcc+=( $(use_enable altivec) )
+   in_iuse altivec && confgcc+=( $(use_enable altivec) )

^ Just as an example, such a construct may change the "default setting" when 
no altivec useflag exists...

Imagine that upstream enables altivec by default (?). In earlier eapis, 
use_enable with a non-existing useflag returned --disable-altivec (?). Now, 
without the useflag, no setting is passed to configure, and it's enabled.

So, while this all works in principle, it may need careful per-flag review.

-- 
Dr. Andreas K. Hüttel
tel. +49 151 241 67748 (mobile)
e-mail m...@akhuettel.de
http://www.akhuettel.de/

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Dropping stable USE flags for 4.14

[Andreas K. Huettel]

Am Freitag, 29. Dezember 2017, 15:46:03 CET schrieb Toralf Förster:
> On 12/29/2017 02:58 PM, Alice Ferrazzi wrote:
> > While not all issues are present in gentoo-sources-4.14.8-r1 we are
> > concerned about the current stability/quality of the 4.14.x branch in
> 

I'd suggest dropping stable for 4.12 too for the moment and instead 
stabilizing newest 4.9. 

(I had some hard crashes of my laptop with 4.12... since then running 4.9 
everywhere and very happy with it...)

-- 
Dr. Andreas K. Hüttel
tel. +49 151 241 67748 (mobile)
e-mail m...@akhuettel.de
http://www.akhuettel.de/

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: dev-lang/swig:1 dev-python/apse

[Andreas K. Huettel]

# Andreas K. Hüttel  (27 Dec 2017)
# Ancient. EAPI=3. (Nearly) no consumers. Needs to go.
# Removal in 30 days.
dev-lang/swig:1

# Andreas K. Hüttel  (27 Dec 2017)
# Last remaining consumer of dev-lang/swig:1, which needs
# to go the way of the dinosaur. Removal in 30 days.
dev-python/apse

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] last rites: app-text/dvibook app-text/dvipdfm app-text/dvipdfmx app-text/xdvipdfmx

[Andreas K. Huettel]

# Andreas K. Hüttel  (25 Dec 2017)
# Provided (and blocked) by app-text/texlive-core (since TL 2014)
# Removal in 30 days; bug 628820
app-text/dvibook
app-text/dvipdfm
app-text/dvipdfmx
app-text/xdvipdfmx


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] default-pie problem tracker

[Andreas K. Huettel]

Hi all, 

if you encounter bugs that are caused by the default-pie settings in the 17.0 
profiles, please make them block the "default-pie" tracker (bug 642232). 
Thanks!!!

(Please make a best effort to doublecheck though that the problem really is 
PIE. The world rebuild found many build issues that are unrelated, e.g. gcc-6 
or glibc-2.26 failures - and these probably make up 90% or more of the 
apparent "17.0 profile issues" ...)

Cheers,  & Merry rest-christmas, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

[Andreas K. Huettel]

Am Sonntag, 17. Dezember 2017, 14:21:10 CET schrieb Michał Górny:
> Hello, everyone.
> 
> It's my pleasure to announce that with a majority vote the QA team has
> accepted a new policy. The accepted wording is:
> 
>   Total size of 'files' subdirectory of a package should not be larger
>   than 32 KiB. If the package needs more auxiliary files, they should
>   be put into SRC_URI e.g. via tarballs.
> 
> (the total size being computed as a sum of apparent file sizes)
> 

This is hard (but not impossible I guess) for toolchain stuff, even though we 
have already most patches in external tarballs, since we want to keep some old 
versions of packages available.

E.g. 

huettel@pinacolada ~/Gentoo/gentoo/sys-libs/glibc/files $ find . -type f
./2.17/glibc-2.17-hardened-pie.patch
./2.18/glibc-2.18-gentoo-stack_chk_fail.c
./2.18/glibc-2.18-hardened-inittls-nosysenter.patch
./2.18/glibc-2.18-gentoo-chk_fail.c
./2.19/glibc-2.19-ia64-gcc-4.8-reloc-hack.patch
./2.19/glibc-2.19-hardened-configure-picdefault.patch
./2.20/glibc-2.20-gentoo-chk_fail.c
./2.20/glibc-2.20-gentoo-stack_chk_fail.c   

 
./2.20/glibc-2.20-hardened-inittls-nosysenter.patch 

 
./2.10/glibc-2.10-gentoo-chk_fail.c 

 
./2.10/glibc-2.10-hardened-inittls-nosysenter.patch 

 
./2.10/glibc-2.10-hardened-configure-picdefault.patch
./nscd.tmpfilesd
./2.25/glibc-2.25-gentoo-chk_fail.c
./nscd.service
huettel@pinacolada ~/Gentoo/gentoo/sys-libs/glibc/files $ du -sh .
152K.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

[Andreas K. Huettel]

Am Donnerstag, 14. Dezember 2017, 13:21:47 CET schrieb Fabian Groffen:
> Can we make it a policy to list /what/ QA issues are the justification
> for commits like these?  A description in the commit message would be
> preferred, but a pointer to a location where said issues can be found
> would do too.
> 
> Thanks,
> Fabian
> 
> On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34e2c43f

That would have been a good thing to do, yes. 

Unfortunately I was between two meetings, just saw the message on #gentoo-qa 
that someone had committed straight to m-n, and if it could be reverted by 
someone with tree access, and decided to quickly help out.

(And adding a new package straight to m-n is in my opinion enough reason for 
an immediate revert.)

That said I think we have sorted out things in the meantime.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

[Andreas K. Huettel]

Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson Jr.:
> 
> The day everyone wanted has come, after this message. I will
> unsubscribe not to return. You all won in 2008, and again in 2017.
> Though this time I will not be back. I tried more than most anyone else
> would for a very long time. Gentoo wins I lose, I am fine with that.
> 
> Please do not contact me off list in IRC or at all. I am done with the
> Gentoo community!


Independent of whether William now unsubscribed or not, he's now enjoying a 
lengthy (1 year until review) vacation from all Gentoo communication channels.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

[Andreas K. Huettel]

Am Mittwoch, 6. Dezember 2017, 00:40:11 CET schrieb William L. Thomson Jr.:
> On Wed, 6 Dec 2017 00:25:46 +0100
> 
> Kristian Fiskerstrand  wrote:
> > One of the primary issues recently is that you keep bringing up old
> > matters in a way that is a criticism of Gentoo overall, in various
> > channels. We've heard it already, and to keep bringing it up doesn't
> > add additional value to the discussion. So again, please reduce the
> > volume of such posts.
> 
> Most all still exist, plus new ones.

Well, it's like listening to a broken record, which keeps repeating the same 
snippet. At some point you stop listening, and at some point you realize you 
should maybe remove it from the player.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

Re: [gentoo-dev] RFC v2: news item for the 17.0 profiles

[Andreas K. Huettel]

Am Dienstag, 28. November 2017, 12:43:59 CET schrieb Dirkjan Ochtman:
> > =
> > Title: New 17.0 profiles in the Gentoo repository
> > Author: Andreas K. Hüttel 
> 
> So gcc-6.4.0 is now in stable on amd64, when do we expect the news item to
> land? I was looking at testing the procedure out, but noticed eselect still
> doesn't show the 17.0 profiles (I know I can twiddle the symlink instead,
> but would like to test the full procedure).

Over the next days, likely on the weekend. Just too busy with other (non-
gentoo) stuff atm...

-a

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Patch for toolchain.eclass for uclibc-ng

[Andreas K. Huettel]

Am Samstag, 25. November 2017, 15:01:20 CET schrieb Anthony G. Basile:
> Hi everyone,
> 
> With the stabilization of gcc-6.4.0, the uclibc build broke because the
> eclass requires UCLIBC_VER to be define on uclibc systems else it will
> die().  Since uclibc specific patches are no longer needed in gcc-6 and
> above, we don't want to error out in the eclass when the patchset is not
> found.
> 

I'd guard this so it only applies to gcc-6 and later... for the simple reason 
that 
otherwise people will try to emerge some historical gcc versions and fail..

Otherwise WFM

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 503f7dbe94f..58d859dfaf3 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -378,9 +378,6 @@ toolchain_pkg_pretend() {
"in your make.conf if you want to use this 
version."
fi
 
-   [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
-   die "Sorry, this version does not support uClibc"
-
if ! use_if_iuse cxx ; then
use_if_iuse go && ewarn 'Go requires a C++ compiler, 
disabled due to USE="-cxx"'
use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ 
compiler, disabled due to USE="-cxx"'
-- 
2.13.6




> Note that there are some musl specific patches which I would like to
> migrate out of the overlay and into the tree.  In a future patch, I'd
> like to duplicate the uclibc code for musl in toolchain.eclass.
> 
> Feedback welcome.


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] keywording ~sys-libs/glibc-2.26

[Andreas K. Huettel]

Am Sonntag, 12. November 2017, 20:53:15 CET schrieb Joshua Kinard:
> 
> I take it Python was fixed to handle this? 
>

Yes, newest ~arch in all python slots is fixed.

(That was the main blocker for keywording.)

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.