Am Donnerstag, 6. Mai 2021, 22:34:52 CEST schrieb Palmer Dabbelt:
>
> TBH: I'm not really going to come up with something better beacuse I
> came up with the current (and likely broken) scheme and I still
> don't fully understand why. So if you have suggestions as to
> something that would actuall
> I'm fine with rust masked in lp64/other profile..
> but in my opinion: it's really up to upstream should fix/support it
>
> > (Unless Palmer et al come up with a fix for the libdirs on the
> > upstream side of things. Already e.g. libdir=lib64-lp64d would be
> > much easier to handle I suspect.)
> > 1) We stop caring about anything except rv64gc/lp64d.
> > People can still bootstrap other stuff with crossdev etc, but the
> > Gentoo tree and the riscv keyword reflect that things work with
> > above -mabi and -march settings.
>
> fine by me, for current software/upstream state, it's probabl
>
> Haven't I told you using two-level libdirs is stupid? So yes,
> please do that and let us be happy once again.
>
> That said, where does lp64gc land? Or isnon-multilib
> one-or-the-other the goal?
It would be non-multilib one-or-the-other then for us.
The main relevant combination is rv64g
>
> -mabi=rv64gc -march=lp64d
should be -march=rv64gc -mabi=lp64d
> libdir = lib64/lp64d
> ("hardfloat")
>
> -mabi=rv64imac -march=lp64
should be -march=rv64imac -mabi=lp64
> libdir = lib64/lp64
> ("softfloat")
>
(but that doesnt change the rest of the argument)
--
Andreas K. Hüttel
Howdy.
I'm sending this not only to the team members on the alias, but also
to the whole dev list for discussion.
So far I've been trying to support in Gentoo the full risc-v multilib
directory structure and the ABI sets supported by glibc. According to
specs this means for riscv64
-mabi=r
Am Sonntag, 2. Mai 2021, 11:56:34 CEST schrieb Fabian Groffen:
> Title: Exim >=4.94 disallows tainted variables in transport
> configurations Author: Fabian Groffen
> Posted: 2021-05-??
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: mail-mta/exim
>
> Since the release of Exim-4.94,
# Andreas K. Hüttel (2021-04-30)
# Superceded by dev-perl/Image-Sane. Tests hang, bug 626594
# Removal in 30 days.
dev-perl/Sane
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally s
# Andreas K. Hüttel (2021-04-30)
# Outdated, not pulled in by any virtuals anymore, no
# keywords. Removal in 30 days.
perl-core/Devel-PPPort
perl-core/Time-Local
perl-core/Unicode-Normalize
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl,
# Andreas K. Hüttel (2021-04-25)
# Broken, bug 616986; removal in 30 days
dev-perl/HTTPD-User-Manage
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
# Andreas K. Hüttel (2021-04-25)
# Broken, bug 663274; removal in 30 days
dev-perl/Text-Unaccent
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
> > Council decided years ago that we don't support separate /usr without
> > an initramfs, but we haven't completed that transition yet.
>
> Which doesn't imply that we deliberately break things.
That's right. Though we should at some point start thinking about an end of
support for separate us
Hi all,
why do we *copy* the timezone file to /etc/localtime, instead of symlinking it
like everyone else?
1) Our handbook recommends:
echo "Europe/Brussels" > /etc/timezone
emerge --config sys-libs/timezone-data
which is effectively doing
echo "Europe/Brussels" > /etc/timezone
cp -f /usr/s
# Andreas K. Hüttel (2021-03-06)
# Fails to build, multiple bugs, outdated, nontrival, unmaintained
# Bug 729876 and several others; removal in 30days
dev-libs/klibc
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
sign
Replying to a random post here- I'm sorry, briefly after I started this thread
real life got in the way and a lot of other things became more urgent.
As soon as I have time (next weekend?) I'll reply to the many e-mails here.
Thanks -A
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux de
Hey all,
it would be great if we could get gcc-10 stable at some point in the near
future... For that purpose we now have a new tracker:
https://bugs.gentoo.org/762907 ("gcc-10-stable", depends on 127 open bugs).
Please have a look if you can help anywhere with the blocking bugs.
Thanks a lo
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
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,
> > a) The two cannot be installed concurrently. To fix that would require
> > even
> > more hacks.
>
> As we've discussed in another part of the thread, that's not really true.
> Both can for sure be installed, just not in the same place and/or
> with same names.
Exactly that is what would requi
Am Dienstag, 29. Dezember 2020, 13:29:35 EET schrieb Peter Stuge:
> I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> to continuosly patch the entire world for libressel.
>
> I'm asking to stop doing that, yet still enable the choice between
> openssl and libressl where tha
> TL;DR: is there really a point in continuing the never-ending always-
> regressing struggle towards supporting LibreSSL in Gentoo?
>
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.
From a team member and initial "believ
On November 9, 2020 1:54:33 PM GMT+02:00, Peter Stuge wrote:
>Andreas K. Hüttel wrote:
>> it's probably time to deprecate the amd64 17.0 profiles!
>
>I for one am not so excited about the amd64 17.1 profiles. On the
>surface
>it appeared to me that one developer has "taken over" just about
>eve
On November 7, 2020 1:42:44 PM GMT+02:00, Alexey Sokolov
wrote:
>22.10.2020 20:16, Andreas K. Hüttel пишет:
>> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
Users frequently are choosing the wrong profile ver
>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
D
Fixed, thank you!
Am Mittwoch, 1. Juli 2020, 12:35:09 EEST schrieb Xianwen Chen (陈贤文):
> Dear all,
>
> There is a typo in
> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/julia/julia-1.4.0-r2
> .ebuild.
>
>
> On line 82, instead of *llvm_pkg_setp*, it should be *llvm_pkg_setup*.
>
> Y
# 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
>
> Andreas, perhaps this should be added to the mask comment? Happy to
> push a PR or simply add this information to the bug report, at the very
> least I thing the bug report should be closed with WONTFIX, may I
> proceed with that? I'll same comments there if in order.
Sure, adding the info t
# Andreas K. Hüttel (2020-03-26)
# Fail to build with glibc-2.30; no maintainer. Removal in 30days.
# Bugs 691756, 691710
x11-terms/aterm
x11-terms/xvt
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
signature.asc
Descr
> 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 developer
> 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 li
> >
> > 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 (some
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
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: 81a65d7da5b5e8b9e48323d
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>
> Comm
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 u
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 ho
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 w
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 th
# @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 6
# 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
Descript
> >
> > 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
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
# 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 signe
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, pe
# 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
# 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
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: T
# 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
d, 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,
&g
# 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 digi
# 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/festi
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
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, upst
ssuming 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
# 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
app-misc/dnetc-2.910
# 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 digitall
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 i
# 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
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 th
# 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 digit
> 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 r
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 -Werro
> 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 o
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 objectio
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ütt
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
Desc
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):
> toolchai
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, libr
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
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 sim
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
Description: This is a digital
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 fail
> >
> > * 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 bum
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, libreoffice, comrel)
signatu
# 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 i
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 gen
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" wrote:
> > another option would be to (try to) revive glibc-2.5, 2.12, and 2.17
> > instead.
> >
>
> You maybe won&#x
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 ev
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 abou
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 fail
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 upda
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
> 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, d
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
101 - 200 of 794 matches
Mail list logo
