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
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
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
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
> > 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
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
> 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
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
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
>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.
> 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
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*.
>
>
# 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
>
> 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
# 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
> 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.
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
> 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
> >
> > 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
Am Donnerstag, 12. März 2020, 20:23:56 CET schrieb Michał Górny:
> On Thu, 2020-03-12 at 11:44 -0700, Alec Warner wrote:
> > On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel
> >
> > wrote:
> > > Someone needs to grow up here.
> >
> > Meh, to me (so
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
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:
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>
>
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
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
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
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
> > 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
# @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
# 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
> >
> > 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
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
# 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
# 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
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,
# 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,
# 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)
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
# 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:
# 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
, 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,
>
> a
# 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
# 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
# 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
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,
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
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,
ang
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.
# 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
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
# 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
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
# 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)
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.
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.
>
> -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
# 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
> 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
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
> 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
> 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
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
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.
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
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):
>
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,
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
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
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
# 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
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
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
> >
> > * 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
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
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
# 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,
# 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)
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 b
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.
> >
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
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
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
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
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
> 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,
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
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.
*
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
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
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
# 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.
# 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
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
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
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
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
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
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
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
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,
1 - 100 of 670 matches
Mail list logo