Re: [gentoo-dev] New project: binhost
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
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
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
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?
> > 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?
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?
> 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?
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?
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
>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
> 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
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. 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, 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. 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
> 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
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
> 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
> > > > 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/
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/
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/
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/
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
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.
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
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
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?
> > 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
# @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. 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?
> > > > 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
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. 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. 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
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. 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. 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
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. 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. 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
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. 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. 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. 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
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/
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
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
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 (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!!!
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. 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"
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. 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
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
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
> > -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. 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?
> 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
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
> 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
> 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
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?
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
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
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)
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
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
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
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. 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)
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)
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?
> > > > * 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?
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
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. 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. 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
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
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
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
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
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
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
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
> 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
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
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
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
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
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. 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. 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
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
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/
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)
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
Am Mittwoch, 6. Dezember 2017, 00:40:11 CET schrieb William L. Thomson Jr.: > On Wed, 6 Dec 2017 00:25:46 +0100 > > Kristian Fiskerstrandwrote: > > 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
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
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
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.