Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, 2017-02-02 at 15:35 -0500, james wrote: > On 02/02/2017 01:01 PM, Rich Freeman wrote: > > On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky > > wrote: > > > > > > If (base == minimal), then all of the upstream defaults need to > > > be added > > > to package.use for the upstream-defaults profile. That's bad, > > > > I'll go further and say that it is unacceptably bad. > > > > > but if > > > (base == upstream-defaults), then the important IUSE defaults > > > need to be > > > copy/pasted from our ebuilds into the minimal profile. The latter > > > is > > > more spiritually damning =) > > > > > > > So, I'll admit I've never been one that cared a great deal about > > minimalism so I appreciate that I may not be the best one to judge > > this, so let's go ahead and embrace your statement for the purpose > > of > > debate. > > > > Is there a better way we can have our cake and eat it too? I'll > > admit > > that a huge package.use on the minimal profile isn't a whole lot > > better than a huge package.use on all the other profiles. > > > > Do we need another form of syntax in individual ebuilds to try to > > separate out the various cases you cite? Does anybody care to > > actually suggest one? > > I think that unikernels are something everyone should be aware of > as they purport to be the latest trend in securing all sorts of > systems. > (a brief read). > > http://unikernel.org/ > > > Perhaps we should not have a 'minimal profile', as it means so many > different things to so many different people. We have not even > surveyed > the user base... > > So if we think of all the possible profiles and sub-profiles as being > organized in a tree structure, it is better to figure out logical > organization of all profiles, imho. > > So how about profiles that are either under the embedded or basic > 'moniker' in the profile tree. So embedded is the least number of > packages possible, regardless of upstream, where folks build up > from > there to what they want as a finished system. Embedded, clusters, > HPC, > and such are compatible enough for what I'm building to be under the > same branch of the profile tree. If other folks want their cluster > works > under the basic part of the profile tree that is concerned with > upstream, then they have their part of the profile tree located > there. > > And the 'basic' part of the tree is similar to what we now call > 'default' and the names build up in whatever schema those target > builds > desire, like basic+headless, basic+kde, basic+?+whatever. ? > > And is there any reason, if necessary that other needs cannot be > branched off, as necessary form the profile tree? Perhaps the main > root > is a state diagram of what is need and has links to relevant > documents. > That way the profile tree is a live system that can be enhance or > modified to serve all of Gentoo's diverse visions. > > > > I still think that we shouldn't encourage users to lightly deviate > > from all the upstream defaults. There are of course legitimate > > reasons for doing so, and you and I can probably appreciate when we > > should do this, but for somebody starting out we're giving them a > > lot > > of rope to hang themselves with. > > This is only the case because profiles are in general in a mess and > there are little in the way of conventions. What is so sacrosanct > about > upstream for a truly embedded gentoo system or a gentoo based IoT > device? How many of the gentoo-embedded devs even bother to read > gentoo-dev? Your vision seems to me to be tainted by the major > distros > and their visions, not be impolite, but they are way off course for h > ttp://www.easyjet.com/en/ > secure systems, embedded systems, IoT, HPC and numerous other active > areas of Linux, imho. > > > Think about it, if upstream is so brilliant, and has our needs 'at > heart' then why have not the kernel-geniuses bothered to build a > logical, coherent semantic for kernel configurations, management, > security testing and such? If fact, if I were to be critical of > upstream, I'd say those and many other issues should have been > addressed > before the adventures of systemd were dictated upon the larger user > base. Upstream is an 'ad-hoc' mess, in the old days we called such > entities a clusterF*. > > > So those of us going back to minimal and basics and such venues, even > with clusters, could not care less about Mozilla, systemd and > thousands > of other upstream folks that have lost their pathway forward. > (deepest > apologies, but I have very strong feelings about "upstream*". > > > Many of the profiles in this and other recent threads, are just 'ad- > hoc' > naming structures and locations, and that historical flexibility > extend > to the devs is fantastic. This enhance/cleaning need of gentoo > profiles > needs to be well thought out and as flexible semantically as > possible. > > > It is absolutely a superior approach to not care
[gentoo-dev] Last rites: games-puzzle/kiki
# David Seifert (18 Feb 2017) # Awful codebase, pointer-to-int-casts, SDL1 # Masked for removal in 30 days games-puzzle/kiki
[gentoo-dev] Last rites: app-i18n/x-unikey
# David Seifert (12 Mar 2017) # Awful codebase, lots of widechars stored in chars, # invokes undefined behaviour, last release in 2004. # Masked for removal in 30 days. Bug #593976. app-i18n/x-unikey
[gentoo-dev] Last rites: www-plugins/nspluginwrapper
# David Seifert (12 Mar 2017) # Bundles half of glibc, unmaintained upstream, # not really necessary anymore with 64-bit flash # Masked for removal in 30 days. Bug #609258. www-plugins/nspluginwrapper
[gentoo-dev] Last rites: app-text/uvconv
# David Seifert (12 Mar 2017) # Awful codebase, lots of widechars stored in chars, # invokes undefined behaviour, last release in 2004. # Masked for removal in 30 days. Bug #593942, #593976. app-text/uvconv
[gentoo-dev] Last rites: sci-libs/acml
# David Seifert (19 Mar 2017) # EOL'd upstream, fetch restricted, digests missing # Masked for removal in 30 days. Bug #612746. sci-libs/acml
[gentoo-dev] Review: aspell-dict-r1.eclass
This is a revbump of aspell-dict.eclass, in order to bring it up to EAPI 6
standards.
Comment here or on https://github.com/gentoo/gentoo/pull/4237
--- eclass/aspell-dict.eclass
+++ eclass/aspell-dict-r1.eclass
@@ -1,77 +1,89 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# @ECLASS: aspell-dict.eclass
+# @ECLASS: aspell-dict-r1.eclass
# @MAINTAINER:
# maintainer-nee...@gentoo.org
# @AUTHOR:
# Original author: Seemant Kulleen
+# -r1 author: David Seifert
# @BLURB: An eclass to streamline the construction of ebuilds for new aspell
dicts
# @DESCRIPTION:
-# The aspell-dict eclass is designed to streamline the construction of
+# The aspell-dict-r1 eclass is designed to streamline the construction of
# ebuilds for the new aspell dictionaries (from gnu.org) which support
# aspell-0.50. Support for aspell-0.60 has been added by Sergey Ulanov.
# @ECLASS-VARIABLE: ASPELL_LANG
# @REQUIRED
# @DESCRIPTION:
-# Which language is the dictionary for? It's used for the DESCRIPTION of the
-# package.
+# Pure cleartext string that is included into DESCRIPTION. This is the name
+# of the language, for instance "Hungarian". Needs to be defined before
+# inheriting the eclass.
+
+# @ECLASS-VARIABLE: ASPELL_VERSION
+# @DESCRIPTION:
+# What major version of aspell is this dictionary for? Valid values are 5, 6
or undefined.
+# This value is used to construct SRC_URI and *DEPEND strings. If defined to 6,
+# >=app-text/aspell-0.60 will be added to DEPEND and RDEPEND, otherwise,
+# >=app-text/aspell-0.50 is added to DEPEND and RDEPEND. If the value is to be
overridden,
+# it needs to be overridden before inheriting the eclass.
+
+case ${EAPI:-0} in
+ [0-5])
+ die "aspell-dict-r1.eclass is banned in EAPI ${EAPI:-0}"
+ ;;
+ 6)
+ ;;
+ *)
+ die "Unknown EAPI ${EAPI:-0}"
+ ;;
+esac
-# @ECLASS-VARIABLE: ASPOSTFIX
-# @REQUIRED
-# @DESCRIPTION:
-# What major version of aspell is this dictionary for?
+EXPORT_FUNCTIONS src_configure src_install
-case ${EAPI} in
- 0|1) EXPORT_FUNCTIONS src_compile src_install ;;
- *) EXPORT_FUNCTIONS src_configure src_compile src_install ;;
-esac
+if [[ ! ${_ASPELL_DICT_R1} ]]; then
+
+# aspell packages have an idiosyncratic versioning scheme, that is
+# the last separating version separator is replaced by a '-'.
+_ASPELL_P=aspell${ASPELL_VERSION}-${PN/aspell-/}-${PV%.*}-${PV##*.}
+
+# @ECLASS-VARIABLE: ASPELL_SPELLANG
+# @DESCRIPTION:
+# Short (readonly) form of the language code, generated from ${PN}
+# For instance, 'aspell-hu' yields the value 'hu'.
+readonly ASPELL_SPELLANG=${PN/aspell-/}
+S="${WORKDIR}/${_ASPELL_P}"
-#MY_P=${PN}-${PV%.*}-${PV#*.*.}
-MY_P=${P%.*}-${PV##*.}
-MY_P=aspell${ASPOSTFIX}-${MY_P/aspell-/}
-SPELLANG=${PN/aspell-/}
-S="${WORKDIR}/${MY_P}"
DESCRIPTION="${ASPELL_LANG} language dictionary for aspell"
HOMEPAGE="http://aspell.net";
-SRC_URI="mirror://gnu/aspell/dict/${SPELLANG}/${MY_P}.tar.bz2"
+SRC_URI="mirror://gnu/aspell/dict/${ASPELL_SPELLANG}/${_ASPELL_P}.tar.bz2"
+unset _ASPELL_P
IUSE=""
SLOT="0"
-if [ x${ASPOSTFIX} = x6 ] ; then
- RDEPEND=">=app-text/aspell-0.60"
- DEPEND="${RDEPEND}"
-else
- RDEPEND=">=app-text/aspell-0.50"
- DEPEND="${RDEPEND}"
-fi
+_ASPELL_MAJOR_VERSION=${ASPELL_VERSION:-5}
+[[ ${_ASPELL_MAJOR_VERSION} != [56] ]] && die "{ASPELL_VERSION} is not a valid
version"
-# @FUNCTION: aspell-dict_src_configure
-# @DESCRIPTION:
-# The aspell-dict src_configure function which is exported.
-aspell-dict_src_configure() {
+RDEPEND=">=app-text/aspell-0.${_ASPELL_MAJOR_VERSION}0"
+DEPEND="${RDEPEND}"
+unset _ASPELL_MAJOR_VERSION
+
+# @FUNCTION: aspell-dict-r1_src_configure
+# @DESCRIPTION:
+# The aspell-dict-r1 src_configure function which is exported.
+aspell-dict-r1_src_configure() {
+ # non-autoconf based script, cannot be used with econf
./configure || die
}
-# @FUNCTION: aspell-dict_src_compile
+# @FUNCTION: aspell-dict-r1_src_install
# @DESCRIPTION:
-# The aspell-dict src_compile function which is exported.
-aspell-dict_src_compile() {
- case ${EAPI} in
- 0|1) aspell-dict_src_configure ;;
- esac
- emake || die
+# The aspell-dict-r1 src_install function which is exported.
+aspell-dict-r1_src_install() {
+ default
+ [[ -s info ]] && dodoc info
}
-# @FUNCTION: aspell-dict_src_install
-# @DESCRIPTION:
-# The aspell-dict src_install function which is exported.
-aspell-dict_src_install() {
- make DESTDIR="${D}" install || die
-
- for doc in README info ; do
- [ -s "$doc" ] && dodoc $doc
- done
-}
+_ASPELL_DICT_R1=1
+fi
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Thu, 2017-03-23 at 22:42 +0100, Alexis Ballier wrote:
> On Thu, 23 Mar 2017 17:20:59 -0400
> Michael Orlitzky wrote:
>
> > On 03/23/2017 04:22 PM, Alexis Ballier wrote:
> > >
> > > Indeed, according to pms.git commit log, the rule was laxed
> > > because
> > > it was clearly an oversight in EAPI6 [1] and was the standard
> > > behavior in previous EAPIs. But in the same commit, an "harmless
> > > note" was added that "Ebuilds must not access the directory in
> > > global scope." in addition to the "May or may not exist"
> > > statement
> > > and "Not necessarily present when installing from a binary
> > > package"
> > > footnote. Please explain how this last addition is not a
> > > backwards-breaking change. PMS is not a tool to push your
> > > personal
> > > agenda of cleaning up the deve^^err tree.
> > >
> > >
> > > [1]
> > > https://gitweb.gentoo.org/proj/pms.git/commit/?id=fa4ac9474048ec7
> > > 5af138fc61f22485c06aac5b7
> > >
> >
> > Read that diff again. Before the commit, FILESDIR was invalid in
> > global scope (only valid in src_*). This commit makes it valid in
> > global scope, but adds the "... don't access it there" clause.
> >
> > It's not a breaking change because any behavior affected by the
> > clause was already illegal before the commit.
>
>
> If we were to stop thinking and follow the rule by the letter: What
> are
> we waiting for to file bugs for every package having ${FILESDIR}
> somewhere in global scope then ?
> After all, those are the council approved versions and EAPIs cannot
> change.
>
> Or you can read again the first sentence in the part you quoted.
>
https://bugs.gentoo.org/show_bug.cgi?id=586416
Re: [gentoo-dev] Review: aspell-dict-r1.eclass
On Sun, 2017-03-19 at 22:22 +0100, David Seifert wrote: > This is a revbump of aspell-dict.eclass, in order to bring it up to > EAPI 6 standards. > Comment here or on https://github.com/gentoo/gentoo/pull/4237 > > --- eclass/aspell-dict.eclass > +++ eclass/aspell-dict-r1.eclass Merged.
[gentoo-dev] Last rites: aspell-dict.eclass
All ebuilds have been ported to aspell-dict-r1.eclass, with no consumers left in the tree. Overlays should either port to -r1 or copy the old eclass. commit 7a012b599b0b037bf56e3da6c690b7a7045810c5 Author: David Seifert Date: Sat Apr 1 19:34:04 2017 +0200 aspell-dict.eclass: Mark @DEAD for removal
[gentoo-dev] Review: xemacs-packages-r1.eclass
Hi,
so one big swath of EAPI 0 ebuilds sits in app-xemacs/. The current
eclass, xemacs-packages.eclass is from days gone by and does little in
terms of modern eclass/ebuild best-practices. I have rewritten it, and
with it will port all ebuilds to it and EAPI 6 (which can be automated,
due to the regular structure of app-xemacs/). The following
improvements have been made:
* Eclass is EAPI 6 (and above) only.
* The eclass now uses the phase functions properly, that is, it doesn't
just unpack the tarball into ${D} in src_install(). This also leads to
a situation where only src_install is EXPORT_FUNCTIONSd, instead of
src_unpack and src_compile too.
* As a result of using doins/insinto and separating the phases cleanly,
all packages automatically become Prefix-compatible.
* All variables are now namespaced, which is how modern eclasses should
be written.
* The package category is checked for consistency between definition in
global scope and its use in src_install().
---
# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: xemacs-packages-r1.eclass
# @MAINTAINER:
# xem...@gentoo.org
# @BLURB: Eclass to support elisp packages distributed by XEmacs.
# @DESCRIPTION:
# This eclass supports ebuilds for packages distributed by XEmacs.
# Ebuilds have to support EAPI 6 at a minimum.
case ${EAPI:-0} in
[0-5])
die "xemacs-packages-r1.eclass is banned in EAPI ${EAPI:-0}"
;;
6)
;;
*)
die "Unknown EAPI ${EAPI}"
;;
esac
EXPORT_FUNCTIONS src_install
if [[ ! ${_XEMACS_PACKAGES_R1} ]]; then
RDEPEND="app-editors/xemacs"
DEPEND="${DEPEND}"
HOMEPAGE="http://xemacs.org/";
LICENSE="GPL-2"
S="${WORKDIR}"
# @ECLASS-VARIABLE: XEMACS_PKG_CAT
# @REQUIRED
# @DESCRIPTION:
# The package category that the package is in. Can be either standard,
# mule, or contrib. Has to be defined before inheriting the eclass.
# Take care not to modify this variable later on.
[[ ${XEMACS_PKG_CAT} ]] || die "XEMACS_PKG_CAT was not defined before
inheriting xemacs-packages-r1.eclass"
case ${XEMACS_PKG_CAT} in
standard|mule|contrib)
;;
*)
die "Unsupported package category in XEMACS_PKG_CAT"
;;
esac
readonly _XEMACS_INITIAL_PKG_CAT=${XEMACS_PKG_CAT}
# @ECLASS-VARIABLE: XEMACS_EXPERIMENTAL
# @DEFAULT_UNSET
# @DESCRIPTION:
# If set then the package is downloaded from the experimental packages
# repository, which is the staging area for packages upstream. Packages
# in the experimental repository are auto-generated from XEmacs VCS, so
# they may not be well-tested. Has to be defined before inheriting the
# eclass.
if [[ -n ${XEMACS_EXPERIMENTAL} ]]; then
SRC_URI="http://ftp.xemacs.org/pub/xemacs/beta/experimental/packages/${P}-pkg.tar.gz";
else
SRC_URI="http://ftp.xemacs.org/pub/xemacs/packages/${P}-pkg.tar.gz";
fi
# @FUNCTION: xemacs-packages-r1_src_install
# @DESCRIPTION:
# xemacs-packages-r1_src_install install the package in a Prefix-aware
# manner.
xemacs-packages-r1_src_install() {
debug-print-function ${FUNCNAME} "${@}"
[[ ${_XEMACS_INITIAL_PKG_CAT} != ${XEMACS_PKG_CAT} ]] && \
die "XEMACS_PKG_CAT has been changed between the initial
definition and src_install"
local xemacs_subdir
case ${XEMACS_PKG_CAT} in
standard)
xemacs_subdir=xemacs-packages
;;
mule)
xemacs_subdir=mule-packages
;;
contrib)
xemacs_subdir=site-packages
;;
esac
debug-print "XEmacs package install dir =
/usr/lib/xemacs/${xemacs_subdir}"
insinto /usr/lib/xemacs/${xemacs_subdir}
doins -r .
}
_XEMACS_PACKAGES_R1=1
fi
Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them
On Mon, 2017-04-03 at 19:09 +0200, Michał Górny wrote: > Therefore, my proposal would be to use the following set once their > support reaches the stable version of Portage: > > manifest-hashes = SHA512 SHA3-512 WHIRLPOOL > > > Your thoughts? > > > > [1]:https://bugs.gentoo.org/612716 > [2]:https://bugs.gentoo.org/611568 > > -- > Best regards, > Michał Górny +5 Let's not repeat the git mistake of delaying this until it's too late.
[gentoo-dev] Last rites: dev-libs/STLport
If you need a non-copyleft alternative, use sys-libs/libcxx instead. # David Seifert (05 Apr 2017) # Abandoned, no releases since 2008, only partially # compatible with C++11, multiple bugs, upstream dead # Masked for removal in 30 days. # Bugs #359247, #400547, #409119, #594144 dev-libs/STLport
[gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
TL;DR ia64/ppc/sparc teams are pretty much dead. They have been for a long time and this won't change any time soon. Gentoo should focus its resources on archs that are important and has the manpower to support. Let us please drop these 3 archs to dev profiles to ease maintenance. Dear all, I'd like to request Council to consider my motion to drop the ia64/ppc/sparc profiles to dev (or exp). These arches are pretty much dead, minus the automated workflows of ago. Two months ago I have written to these 3 archs, and only received one reply from ppc agreeing with my sentiment, with no response from ia64 or sparc, which in itself is pretty telling. Currently, architecture projects think adding their keywords is a right, which I strongly disagree with. I believe being able to add (and stable) your keywords is a privilege - namely it carries with it the duty to react to keywording and stabilization requests in a timely manner. Let's compare the state of ia64/ppc/sparc to, say alpha: https://bugs.gentoo.org/show_bug.cgi?id=605278 alpha was keyworded within 6 hours. To date ia64/ppc/sparc are still not keyworded (the bot had some breakages due to jer again shifting around all the bugs). Within 4 months these arches have not managed to keyword those 4 packages. This is I believe the most striking example of how the only work done for these archs are ago's automated stablereq scripts. Why do I saw that keywording+stabling your arch is a privilege? Maintenance of packages is hampered by archs not stabling, because we cannot clean up broken packages. Adding keywords is a two- way street - if you don't act speedily, you're breaking part of the maintainer-arch social contract. Please don't turn this into a massive bikeshedding contest and just admit that it is extremely unlikely that these archs will see more activity in the near future. We should focus our resources on more important archs (arm64 maybe?) instead of these. I know you have that old Mac G4 or UltraSPARC sitting in your closet that you're 2 days away from installing Gentoo on, but the pain for maintainers and the rest of the community is just too great. If someone steps up to do the work, we can then move archs back to a stable profile, but so long as they linger in their present state, let's call a spade a spade. Anyhow, I formally request the Council to vote on dropping these archs to unstable/exp profiles for the next Council meeting, explicitly overriding any arch concerns that are likely to awake now and going to be running around like headless chicken. David
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Sun, 2017-05-07 at 22:24 +0200, Michał Górny wrote: > I'm against. Turning more arches into dev/exp only introduces hidden > depgraph breakages. I think it'd be better if we looked into > the arch.desc proposal and just disabled stable keywords for those > architectures. > This is probably the smaller problem. The link shows a bug where none of the aforementioned arch teams have keyworded the requested packages in 4 months. How would the arches.desc proposal fix "dead arch teams"? Sure, it will make maintenance easier for pure stablereqs, but the other half of keywording does not happen. All the ia64/ppc/sparc KEYWORDREQs I have filed for sci-* packages I have closed and dekeyworded for revdeps. We have had KEYWORDREQs open for over a year with 0 activity. If the keywording inactivity continues, I will also continue to dekeyword packages.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Mon, 2017-05-08 at 13:49 +0300, Mikle Kolyada wrote: > Against. Do not touch things you are not working on, council has > already > dropped m68k s390 and sh to exp few years ago. Now we have a big mess > there and only, while ia64 sparc and co have slow but progress and > mature enough stable profiles. Again, I have had KEYWORDREQs open for more than a year with 0 activity. The only way to get any activity on these arches is to trigger the easteregg of going straight-to-stable, which ago's scripts catch (unlike KEYWORDREQs). This is ofc the total antithesis of using ~arch as a staging ground for stable keywords, but apparently that seems to be desired. I am absolutely willing to postpone the vote on this to after the arches.desc GLEP is finished, but being in denial over dead archs is helping no-one. If all of this ends in one big bikeshedding fest again, I will start dekeywording packages. Fortunately for me, I won't get any complaints (because the arch teams are dead). If the walls are mouldy, do you just paint over them and pretend everything is fine?
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Mon, 2017-05-08 at 22:08 +0300, Mikle Kolyada wrote: > We have appropriate hardware if people wanna do the work, jut go & > make > things better :), I do not think someone from existing arch teams has > something against that Ok so let me get the logic right: 1) Arch teams can add their keywords to ebuilds in general, without the maintainer having a say in that. 2) Arch team goes MIA because . 3) Now the maintainer has to chase down machines and do KEYWORDREQ testing on other arches because we cannot admit that some archs are not maintained. Please confirm the above logic. If that logic is about right, I am sorry, but I disagree. I will rather dekeyword unmaintained archs. I am not going to babysit arch teams in doing their work for them.
Re: [gentoo-dev] Bugzilla package list editing
On Wed, 2017-05-10 at 18:22 +0300, Mart Raudsepp wrote: > Ühel kenal päeval, T, 02.05.2017 kell 02:31, kirjutas Andreas K. > Huettel: > > Am Sonntag, 30. April 2017, 12:29:46 CEST schrieb Mart Raudsepp: > > > > > > Please stop editing package lists when you are not the maintainer > > > and > > > arches are already CCed. > > > > > > > +1 > > > > Please stop it. > > And yes that's also true for arch team members. > > > > Package list is maintainer territory. > > He keeps messing with this. > Can we please remove his editbugs privileges until he learns to be > more > considerate towards others? > > I'm sick and tired of seeing these non-maintainer package list > editing > e-mails that I need to spend time on to validate what was changed > again. > As-is, one person is constantly generating lots of small amount of > extra checking work for everyone else due to being stubborn and not > simply prepending a = in front of the package list lines, if not > present yet, as he must have a script already to filter out the > packages that are needed for hppa (and no, it's not just a grep > hppa). > (and it's not always just prepending of =, there can always be other > easter eggs in longer package lists without as much as a comment, as > many have experienced, so you do need to really carefully check what > the heck was changed again). > > > Mart > He doesn't stop: https://bugs.gentoo.org/show_bug.cgi?id=617694 Please drop editbugs privileges for some time. Everyone agrees that this maintainer-specific metadata is not to be touched.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Wed, 2017-05-10 at 22:24 +0300, Mart Raudsepp wrote: > Ühel kenal päeval, K, 10.05.2017 kell 15:01, kirjutas Anthony G. > Basile: > > On 5/10/17 11:08 AM, William Hubbs wrote: > > > On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote: > > > > On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile > > > to > > > > o.org> wrote: > > > > > I maintain quite a few ppc stage3's for uclibc and musl. I > > > > > would > > > > > appreciate keeping ppc as is. It is still a useful arch for > > > > > many > > > > > devices today, eg. some high end Mikrotik routers. > > > > > > > > So are you willing to do the work? There are currently 68 open > > > > keyword > > > > requests (oldest one reported in 2011) and 48 open stable > > > > requests > > > > (oldest one reported in November). > > > > > > +1000 > > > > > > If we are going to keep ppc as a stable profile, someone needs to > > > do the > > > keywording and stabilization for it. > > > > > > William > > > > > > > the current plan by Soap et al is to drop all keywords except for > > @system and leave the profiles stable. this works for me and > > addresses > > your concern. > > Are we talking about dropping all keywords besides @system things > from > ppc to ~ppc or completely? > I guess the latter as the former doesn't solve keywording lag? > > > Mart > The latter, as that is the only way to restore sanity. I will be preparing a list.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Wed, 2017-05-10 at 15:40 -0400, Anthony G. Basile wrote: > On 5/10/17 3:29 PM, David Seifert wrote: > > On Wed, 2017-05-10 at 22:24 +0300, Mart Raudsepp wrote: > > > Ühel kenal päeval, K, 10.05.2017 kell 15:01, kirjutas Anthony G. > > > Basile: > > > > On 5/10/17 11:08 AM, William Hubbs wrote: > > > > > On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman > > > > > wrote: > > > > > > On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile > > > > > @gen > > > > > > to > > > > > > o.org> wrote: > > > > > > > I maintain quite a few ppc stage3's for uclibc and > > > > > > > musl. I > > > > > > > would > > > > > > > appreciate keeping ppc as is. It is still a useful arch > > > > > > > for > > > > > > > many > > > > > > > devices today, eg. some high end Mikrotik routers. > > > > > > > > > > > > So are you willing to do the work? There are currently 68 > > > > > > open > > > > > > keyword > > > > > > requests (oldest one reported in 2011) and 48 open stable > > > > > > requests > > > > > > (oldest one reported in November). > > > > > > > > > > +1000 > > > > > > > > > > If we are going to keep ppc as a stable profile, someone > > > > > needs to > > > > > do the > > > > > keywording and stabilization for it. > > > > > > > > > > William > > > > > > > > > > > > > the current plan by Soap et al is to drop all keywords except > > > > for > > > > @system and leave the profiles stable. this works for me and > > > > addresses > > > > your concern. > > > > > > Are we talking about dropping all keywords besides @system things > > > from > > > ppc to ~ppc or completely? > > > I guess the latter as the former doesn't solve keywording lag? > > > > > > > > > Mart > > > > > > > The latter, as that is the only way to restore sanity. I will be > > preparing a list. > > > > So let's make sure we're on the same page -- here's my understanding. > > 1) For @system packages, we will have KEYWORDS="ppc" for the stable > versions and KEYWORDS="~ppc" for the rest. > > 2) For non @system packages we will remove both ppc and ~ppc > keywords. > > 3) If for some reason I need to add back a package to build/maintain > stage3/4, I will rekeyword myself, but other than that, we will *not* > balloon the keywords. > > 4) I will take on the responsibility of stabilizing ppc @system > packages > if need be. > That's the plan, correct.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Wed, 2017-05-10 at 22:01 -0700, Yury German wrote: > > On 5/10/17 12:40 PM, Anthony G. Basile wrote: > > On 5/10/17 3:29 PM, David Seifert wrote: > > So let's make sure we're on the same page -- here's my > > understanding. > > > > 1) For @system packages, we will have KEYWORDS="ppc" for the stable > > versions and KEYWORDS="~ppc" for the rest. > > So is this only for PPC or PPC64 as well? > Both are security supported arches, but if you are going this route > they > will be dropped to non-secured arches leaving: > > alpha, amd64, hppa, x86. > > > > > 2) For non @system packages we will remove both ppc and ~ppc > > keywords. > > > > 3) If for some reason I need to add back a package to > > build/maintain > > stage3/4, I will rekeyword myself, but other than that, we will > > *not* > > balloon the keywords. > > > > 4) I will take on the responsibility of stabilizing ppc @system > > packages > > if need be. > > > > So just to be clear, any developer can rekeyword a package to ~ppc? > > 1. ppc(= 32 bit) will be massively dekeyworded, ppc64 will stay unchanged (also given that it is an active arch in general and gets CPU upgrades from IBM/OpenPOWER). 2. In general, no. The proposal will be such that keywording should only be done to aid bootstrapping, not randomly add packages you think might be nice. The whole point of this exercise is to not have to repeat this whole thing again in 2 years, just because someone found a bunch of packages interesting. If there really is a dedicated team up to the task and demonstrably active in keywording/stablereq'ing, we can reconsider.
[gentoo-dev] Last rites: sys-fabric/libibvpp
# David Seifert (14 May 2017) # Unmaintained upstream, awful codebase. No reverse # dependencies. See #594134. To be removed in 30 days. sys-fabric/libibvpp
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Sun, 2017-05-14 at 12:38 +0200, Michael Weber wrote: > On 05/08/2017 09:13 PM, David Seifert wrote: > > If all of this ends in one big bikeshedding fest again, I will > > start > > dekeywording packages. Fortunately for me, I won't get any > > complaints > > (because the arch teams are dead). > > formal complaint, powerpc team is alive, and I'm lead. https://bugs.gentoo.org/show_bug.cgi?id=546082 You call that alive?
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Mon, 2017-05-15 at 15:33 -0400, Yury German wrote: > I would prefer PPC and for that matter arm (which are no longer > security > supported) going the Non-stable route. This would prevent the need > for > stabilization and everything but @system we can instruct the users to > use ~ppc. > > This would also allow for security to not drop it from security > supported arches and just follow a more relaxed policy for non-stable > packages. > > For those not familiar, we (security) only need to have the package > in > tree and the vulnerable packages dropped, which is easily > accomplished > by the maintainer with no need for arches to get involved. > > Yury German (BlueKnight) This solution doesn't go far enough for me - mainly because it still makes KEYWORDREQs a pain.
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
On Sun, 2017-06-11 at 17:12 +0200, Kristian Fiskerstrand wrote:
> On 06/11/2017 05:07 PM, Mart Raudsepp wrote:
> > Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William
> > Hubbs:
> > > On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich
> > > wrote:
> > > > On Sat, 10 Jun 2017 13:28:19 +0200
> > > > Jeroen Roovers wrote:
> > > >
> > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > > > > + mv configure.{in,ac} || die
> > > >
> > > > Looks good.
> > > >
> > > > --
> > > >
> > > > Sergei
> > >
> > > -1
> > >
> > > I think this should be handled by the packages, not at the eclass
> > > level.
> > >
> > > https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
> > >
> > > The packages should either mv the configure.in to configure.ac
> > > internally, or better yet, the maintainers should ask upstream
> > > for
> > > their
> > > packages to fix it.
> >
> > +1, otherwise we will never be able to add/unmask a newer autoconf
> > that
> > doesn't look at configure.in anymore, once such a version
> > eventually
> > happens.
> >
>
> We can always patch the eclass at that point if that is still a big
> concern, but I fundamentally agree with William on this, starting
> point
> should be fixing it upstream, so can start with a tracking bug on
> affected packages.
>
Here's a deal: you can start filing + fixing them.
David
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Fri, 2017-07-28 at 15:59 -0400, William L. Thomson Jr. wrote: > On Fri, 28 Jul 2017 23:10:35 +1000 > "Sam Jorna (wraeth)" wrote: > > > On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel" > > wrote: > > > > > That's not feasible. It would kill off any semi-professional or > > > professional > > > Gentoo use, where a minimum of stability is required. > > > > > > (Try keeping ~10 machines on stable running without automation. > > > That's already > > > quite some work. Now try the same with ~arch. Now imagine you're > > > talking about > > > 100 or 1000 machines.) > > > > And further, try proposing that to management - that you'll be > > managing hosts on a platform that has no "stable" to speak of. > > The professional/management argument is silly. Most avoid Gentoo. > Most companies, want to be able to pay for support. Not to mention > certifications and such for those they hire. None of which Gentoo has > regardless of stability. Not to mention reputation... > > Those that tend to run Gentoo have their own interest in such. I > have > seen many migrate from rather than to Gentoo. Large companies, who's > names we would all know. One of the few left is Meetup.com. They run > Gentoo as do some others. Seems Tivo does stuff with Gentoo, Google, > Sony, etc. Some tend to hire Gentoo devs... > Seriously, can you please stop your diatribes. I am so absolutely fed up by your DoS'ing of the ML with your pointless points.
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Sat, 2017-07-29 at 19:41 +0300, Mart Raudsepp wrote: > > why take away the stable choice? > > I think it is rather clear that stable keywords aren't going anywhere > for architectures like amd64. I suggest we drop all of the subthreads > on this topic and get back to other interesting thoughts (which may > include dropping stable for some other arches of course; I mean doing > it for all doesn't deserve e-mails imo). > > > Mart > I demand you stop asking for dropping stable for "some other arches", otherwise I might have to stop arch testing on ppc and sparc.
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Mon, 2017-07-31 at 10:43 -0400, William L. Thomson Jr. wrote: > On Mon, 31 Jul 2017 14:59:25 +0200 > "Andreas K. Huettel" wrote: > > > Am Montag, 31. Juli 2017, 04:44:58 CEST schrieb William L. Thomson > > Jr.: > > > > > > How about no foundation. Not even a legal entity. No > > > certifications > > > from vendors, nor for employees. No one to hire for official > > > support. There are so many things far beyond anything having to > > > do > > > with a stable tree or not. > > > > I was *this* close to nominaing you for Trustee, until I realized > > you're not even a foundation member... > > Wait what? You blocked me from returning as a developer. Based on my > human relation skills, or in your opinion lack there of > https://bugs.gentoo.org/show_bug.cgi?id=135927#c43 > > How would you think I be fit for foundation Trustee? Which is a > liason > type role, at least with outside entities. That makes little to no > sense. A developer need technical skills more than personal. A > Trustee > needs personal and not so much technical Great logic! > > It seems that foundation membership been messed up pretty bad. This > seems to be the list of members. Which seems to only be developers. > https://wiki.gentoo.org/wiki/Foundation:Member_List > > Per the by laws, one is only removed from membership via voluntary > request, and/or majority vote of the trustees to remove a member. > https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.4._Continuat > ion_of_Membership > https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.8._Voluntary > _Withdrawal_from_Membership > https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.9._Terminati > on_from_Membership > > I may have requested removal, I seem to recall such. Though I am not > sure others have. Seems the foundation is missing many members. > Unless > the trustees voted to remove many others. > > Also developers are not automatically added per bylaws. They must > apply for such. > https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.3._Admission > _of_Members > https://en.wiktionary.org/wiki/sarcasm
Re: [gentoo-dev] [PATCH 02/12] dev-util/ccache: Convert to EAPI=6
On Thu, 2017-08-17 at 10:36 +0200, Michał Górny wrote:
> ---
> dev-util/ccache/ccache-3.3.4-r1.ebuild | 68
> ++
> 1 file changed, 68 insertions(+)
> create mode 100644 dev-util/ccache/ccache-3.3.4-r1.ebuild
>
> diff --git a/dev-util/ccache/ccache-3.3.4-r1.ebuild b/dev-
> util/ccache/ccache-3.3.4-r1.ebuild
> new file mode 100644
> index ..1ef1d45179d1
> --- /dev/null
> +++ b/dev-util/ccache/ccache-3.3.4-r1.ebuild
> @@ -0,0 +1,68 @@
> +# Copyright 1999-2017 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=6
> +
> +inherit readme.gentoo-r1
> +
> +DESCRIPTION="fast compiler cache"
> +HOMEPAGE="http://ccache.samba.org/";
> +SRC_URI="https://samba.org/ftp/ccache/${P}.tar.xz";
> +
> +LICENSE="GPL-3"
> +SLOT="0"
> +KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc
> ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-
> macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~x64-solaris
> ~x86-solaris"
> +IUSE=""
> +
> +DEPEND="app-arch/xz-utils
> + sys-libs/zlib"
> +RDEPEND="${DEPEND}
> + sys-apps/gentoo-functions"
> +
> +src_prepare() {
> + # make sure we always use system zlib
> + rm -rf zlib || die
> + eapply "${FILESDIR}"/${PN}-3.3-size-on-disk.patch #456178
> + eapply_user
> + sed \
> + -e "/^EPREFIX=/s:'':'${EPREFIX}':" \
> + "${FILESDIR}"/ccache-config-3 > ccache-config || die
> +}
> +
> +src_install() {
> + DOCS=( AUTHORS.txt MANUAL.txt NEWS.txt README.md )
> + default
> +
> + dobin ccache-config
> +
> + DOC_CONTENTS="
> +To use ccache with **non-Portage** C compiling, add
> +${EPREFIX}/usr/lib/ccache/bin to the beginning of your path, before
> ${EPREFIX}/usr/bin.
> +Portage 2.0.46-r11+ will automatically take advantage of ccache with
> +no additional steps. If this is your first install of ccache, type
> +something like this to set a maximum cache size of 2GB:\\n
> +# ccache -M 2G\\n
> +If you are upgrading from an older version than 3.x you should clear
> all of your caches like so:\\n
> +# CCACHE_DIR='${CCACHE_DIR:-${PORTAGE_TMPDIR}/ccache}' ccache -C\\n
> +ccache now supports sys-devel/clang and dev-lang/icc, too!"
> +
> + readme.gentoo_create_doc
> +}
> +
> +pkg_prerm() {
> + if [[ -z ${REPLACED_BY_VERSION} ]] ; then
> + "${EROOT}"/usr/bin/ccache-config --remove-links
> + "${EROOT}"/usr/bin/ccache-config --remove-links
> ${CHOST}
> + fi
> +}
> +
> +pkg_postinst() {
> + "${EROOT}"/usr/bin/ccache-config --install-links
> + "${EROOT}"/usr/bin/ccache-config --install-links ${CHOST}
> +
> + # nuke broken symlinks from previous versions that shouldn't
> exist
> + rm -f "${EROOT}"/usr/lib/ccache/bin/${CHOST}-cc || die
> + rm -rf "${EROOT}"/usr/lib/ccache.backup || die
> +
> + readme.gentoo_print_elog
> +}
While I personally am not as uptight about 'local'ising variables, I
believe making DOC_CONTENTS local serves an important purpose: to dodge
any chance of people thinking it is allowed to leak into pkg_* phases
(i.e. the whole rationale of readme.gentoo-r1 in the first place). For
DOCS and friends its irrelevant, as their semantics are only import in
src_* phases.
Re: [gentoo-dev] [PATCH 02/12] dev-util/ccache: Convert to EAPI=6
On Thu, 2017-08-17 at 11:00 +0200, Michał Górny wrote:
> W dniu czw, 17.08.2017 o godzinie 10∶48 +0200, użytkownik David
> Seifert
> napisał:
> > On Thu, 2017-08-17 at 10:36 +0200, Michał Górny wrote:
> > > ---
> > > dev-util/ccache/ccache-3.3.4-r1.ebuild | 68
> > > ++
> > > 1 file changed, 68 insertions(+)
> > > create mode 100644 dev-util/ccache/ccache-3.3.4-r1.ebuild
> > >
> > > diff --git a/dev-util/ccache/ccache-3.3.4-r1.ebuild b/dev-
> > > util/ccache/ccache-3.3.4-r1.ebuild
> > > new file mode 100644
> > > index ..1ef1d45179d1
> > > --- /dev/null
> > > +++ b/dev-util/ccache/ccache-3.3.4-r1.ebuild
> > > @@ -0,0 +1,68 @@
> > > +# Copyright 1999-2017 Gentoo Foundation
> > > +# Distributed under the terms of the GNU General Public License
> > > v2
> > > +
> > > +EAPI=6
> > > +
> > > +inherit readme.gentoo-r1
> > > +
> > > +DESCRIPTION="fast compiler cache"
> > > +HOMEPAGE="http://ccache.samba.org/";
> > > +SRC_URI="https://samba.org/ftp/ccache/${P}.tar.xz";
> > > +
> > > +LICENSE="GPL-3"
> > > +SLOT="0"
> > > +KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc
> > > ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd ~amd64-linux ~x86-linux
> > > ~ppc-
> > > macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~x64-
> > > solaris
> > > ~x86-solaris"
> > > +IUSE=""
> > > +
> > > +DEPEND="app-arch/xz-utils
> > > + sys-libs/zlib"
> > > +RDEPEND="${DEPEND}
> > > + sys-apps/gentoo-functions"
> > > +
> > > +src_prepare() {
> > > + # make sure we always use system zlib
> > > + rm -rf zlib || die
> > > + eapply "${FILESDIR}"/${PN}-3.3-size-on-disk.patch
> > > #456178
> > > + eapply_user
> > > + sed \
> > > + -e "/^EPREFIX=/s:'':'${EPREFIX}':" \
> > > + "${FILESDIR}"/ccache-config-3 > ccache-config ||
> > > die
> > > +}
> > > +
> > > +src_install() {
> > > + DOCS=( AUTHORS.txt MANUAL.txt NEWS.txt README.md )
> > > + default
> > > +
> > > + dobin ccache-config
> > > +
> > > + DOC_CONTENTS="
> > > +To use ccache with **non-Portage** C compiling, add
> > > +${EPREFIX}/usr/lib/ccache/bin to the beginning of your path,
> > > before
> > > ${EPREFIX}/usr/bin.
> > > +Portage 2.0.46-r11+ will automatically take advantage of ccache
> > > with
> > > +no additional steps. If this is your first install of ccache,
> > > type
> > > +something like this to set a maximum cache size of 2GB:\\n
> > > +# ccache -M 2G\\n
> > > +If you are upgrading from an older version than 3.x you should
> > > clear
> > > all of your caches like so:\\n
> > > +# CCACHE_DIR='${CCACHE_DIR:-${PORTAGE_TMPDIR}/ccache}' ccache
> > > -C\\n
> > > +ccache now supports sys-devel/clang and dev-lang/icc, too!"
> > > +
> > > + readme.gentoo_create_doc
> > > +}
> > > +
> > > +pkg_prerm() {
> > > + if [[ -z ${REPLACED_BY_VERSION} ]] ; then
> > > + "${EROOT}"/usr/bin/ccache-config --remove-links
> > > + "${EROOT}"/usr/bin/ccache-config --remove-links
> > > ${CHOST}
> > > + fi
> > > +}
> > > +
> > > +pkg_postinst() {
> > > + "${EROOT}"/usr/bin/ccache-config --install-links
> > > + "${EROOT}"/usr/bin/ccache-config --install-links
> > > ${CHOST}
> > > +
> > > + # nuke broken symlinks from previous versions that
> > > shouldn't
> > > exist
> > > + rm -f "${EROOT}"/usr/lib/ccache/bin/${CHOST}-cc || die
> > > + rm -rf "${EROOT}"/usr/lib/ccache.backup || die
> > > +
> > > + readme.gentoo_print_elog
> > > +}
> >
> > While I personally am not as uptight about 'local'ising variables,
> > I
> > believe making DOC_CONTENTS local serves an important purpose: to
> > dodge
> > any chance of people thinking it is allowed to leak into pkg_*
> > phases
> > (i.e. the whole rationale of readme.gentoo-r1 in the first place).
> > For
> > DOCS and friends its irrelevant, as their semantics are only import
> > in
> > src_* phases.
> >
>
> Are you saying that I should move it to pkg_setup()?
>
No, all I'm saying is make DOC_CONTENTS local in src_install().
Re: [gentoo-dev] [PATCH] out-of-source.eclass: A new eclass to help with out-of-source builds
On Thu, 2017-11-16 at 14:48 +0100, Michał Górny wrote: > // NB: I'm not sure if I haven't submitted it already but that was > // a long time ago, so let's try again. Requested by soap. > > The out-of-source.eclass is a simple multilib-minimal-style wrapper > to perform out of source builds of autotools (and other) packages. It > is > mostly derived from the function served in the past by autotools- > utils > since a number of developers found it useful. However, in order to > avoid > the mistakes of autotools-utils, it is meant to be focused on a > single > feature and have a better API. > > This eclass has two use cases: > > 1. Ensuring that packages are tested with out-of-source builds. > > 2. Improving consistency between multilib and non-multilib packages. > > In the most basic form, it just redefines the phases from > src_configure() > to src_install() with out-of-source wrappers. However, each phase can > be overriden using my_src_*() sub-phase that is run inside build dir > (alike multilib_src_*() in multilib-minimal). There is also > my_src_install_all() for the trailing source-dir actions. +1
[gentoo-dev] NEWS item for games destabling
NEWS item for de-stabled games Title: No stable KEYWORDS for Gentoo Games Author: David Seifert <s...@gentoo.org> Content-Type: text/plain Posted: 2017-11-19 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: amd64 x86 As the Games team does not have enough manpower to keep tabs on all games packages, we have dropped all games-* ebuilds to unstable KEYWORDS (modulo those required by stable non-games packages). If you have any of these stable games packages installed, you will have to add them to /etc/portage/package.accept_keywords/ manually. Failures related to missing stable KEYWORDS will show up like The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by @selected # required by @world (argument) =games-action/0verkill-0.16-r4 ~amd64 While we accept that this will cause some irritation for the community, pretending we have a well supported games collection by having a wealth of stable games packages is misleading at best. By having 99% of games be unstable, we convey the expectation users should have - namely that games in Gentoo are not part of crucial Tier 1 packages. We welcome contributions from outsiders willing to polish up the games landscape in Gentoo.
Re: [gentoo-dev] NEWS item for games destabling
Round 2 (with correct whitespace this time): Title: No stable KEYWORDS for Gentoo Games Author: David Seifert Content-Type: text/plain Posted: 2017-11-20 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: amd64 x86 As the Games team does not have enough manpower to keep tabs on all games packages, we have dropped all ebuilds maintained by the games project to unstable KEYWORDS (without those required by other stable packages). If you have any of these stable games packages installed, you will have to add them to /etc/portage/package.accept_keywords/ manually. Failures related to missing stable KEYWORDS will show up as The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by @selected # required by @world (argument) =games-action/0verkill-0.16-r4 ~amd64 While we accept that this will cause some irritation for the community, pretending we have a well supported games collection by having a wealth of stable games packages is misleading at best. We welcome contributions from outsiders willing to polish up the games landscape in Gentoo via the Proxy Maintainers.
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
On Thu, 2017-12-14 at 15:04 +0100, Chí-Thanh Christopher Nguyễn wrote: > Michał Górny schrieb: > > Breaking the dependency tree was a *honest* mistake on the person > > who > > reverted this commit. > > > > Andrey pretty clearly stated that he did this *on purpose*. > > The removal of the package in violation of Gentoo policy was fully > intentional from what I can see. There was no 30-day prior notice + > p.mask which is required before removing a package. > > But even that it is not bad, just fix that mistake. > > > Best regards, > Chí-Thanh Christopher Nguyễn > > > So I can add tons of broken packages, sprinkled over different days, hidden between other valid bumps, and can then tell people they need to lastrite this stuff first and do the 30-day rain dance? Come on, even for Gentoo standards, that's absolutely ridiculous.
[gentoo-dev] Last rites: x-modular.eclass
x-modular.eclass: Mark @DEAD for removal Last consumers have been removed, the eclass has been deprecated, still uses awful built_with_use constructs.
Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.
On Thu, 2018-01-04 at 10:43 +, M. J. Everitt wrote:
> On 04/01/18 10:23, Pacho Ramos wrote:
> > El mié, 03-01-2018 a las 17:13 +0100, Ulrich Müller escribió:
> > > Split off functions preserve_old_lib and preserve_old_lib_notify
> > > from
> > > eutils.eclass into a dedicated preserve-libs.eclass. These
> > > functions
> > > are rarely used and are independent of the rest of eutils,
> > > therefore
> > > moving them into their own eclass will help clarifying eclass
> > > inheritance in ebuilds.
> > >
> > > For backwards compatibility, eutils inherits the new eclass in
> > > existing EAPIs.
> > > ---
> > > eclass/eutils.eclass| 65 ++-
> > >
> > > eclass/preserve-libs.eclass | 74
> > > +
> > > 2 files changed, 76 insertions(+), 63 deletions(-)
> > > create mode 100644 eclass/preserve-libs.eclass
> > >
> > > diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> > > index 7d4193e76b51..91d329e99c9e 100644
> > > --- a/eclass/eutils.eclass
> > > +++ b/eclass/eutils.eclass
> > > @@ -1,4 +1,4 @@
> > > -# Copyright 1999-2017 Gentoo Foundation
> > > +# Copyright 1999-2018 Gentoo Foundation
> > > # Distributed under the terms of the GNU General Public License
> > > v2
> > >
> > > # @ECLASS: eutils.eclass
> > > @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1
> > > # implicitly inherited (now split) eclasses
> > > case ${EAPI:-0} in
> > > 0|1|2|3|4|5|6)
> > > - inherit desktop epatch estack ltprune multilib
> > > toolchain-funcs
> > > + inherit desktop epatch estack ltprune multilib preserve-
> > > libs
> > > toolchain-funcs
> > > ;;
> > > esac
> > >
> > > @@ -172,67 +172,6 @@ _eutils_eprefix_init() {
> > > has "${EAPI:-0}" 0 1 2 && : ${ED:=${D}} ${EPREFIX:=}
> > > ${EROOT:=${ROOT}}
> > > }
> > >
> > > -# @FUNCTION: preserve_old_lib
> > > -# @USAGE: [more libs]
> > > -# @DESCRIPTION:
> > > -# These functions are useful when a lib in your package changes
> > > ABI SONAME.
> > > -# An example might be from libogg.so.0 to libogg.so.1. Removing
> > > libogg.so.0
> > > -# would break packages that link against it. Most people get
> > > around this
> > > -# by using the portage SLOT mechanism, but that is not always a
> > > relevant
> > > -# solution, so instead you can call this from pkg_preinst. See
> > > also the
> > > -# preserve_old_lib_notify function.
> > > -preserve_old_lib() {
> > > - _eutils_eprefix_init
> > > - if [[ ${EBUILD_PHASE} != "preinst" ]] ; then
> > > - eerror "preserve_old_lib() must be called from
> > > pkg_preinst()
> > > only"
> > > - die "Invalid preserve_old_lib() usage"
> > > - fi
> > > - [[ -z $1 ]] && die "Usage: preserve_old_lib > > preserve>
> > > [more libraries to preserve]"
> > > -
> > > - # let portage worry about it
> > > - has preserve-libs ${FEATURES} && return 0
> > > -
> > > - local lib dir
> > > - for lib in "$@" ; do
> > > - [[ -e ${EROOT}/${lib} ]] || continue
> > > - dir=${lib%/*}
> > > - dodir ${dir} || die "dodir ${dir} failed"
> > > - cp "${EROOT}"/${lib} "${ED}"/${lib} || die "cp
> > > ${lib} failed"
> > > - touch "${ED}"/${lib}
> > > - done
> > > -}
> > > -
> > > -# @FUNCTION: preserve_old_lib_notify
> > > -# @USAGE: [more libs]
> > > -# @DESCRIPTION:
> > > -# Spit helpful messages about the libraries preserved by
> > > preserve_old_lib.
> > > -preserve_old_lib_notify() {
> > > - if [[ ${EBUILD_PHASE} != "postinst" ]] ; then
> > > - eerror "preserve_old_lib_notify() must be called
> > > from
> > > pkg_postinst() only"
> > > - die "Invalid preserve_old_lib_notify() usage"
> > > - fi
> > > -
> > > - # let portage worry about it
> > > - has preserve-libs ${FEATURES} && return 0
> > > -
> > > - _eutils_eprefix_init
> > > -
> > > - local lib notice=0
> > > - for lib in "$@" ; do
> > > - [[ -e ${EROOT}/${lib} ]] || continue
> > > - if [[ ${notice} -eq 0 ]] ; then
> > > - notice=1
> > > - ewarn "Old versions of installed
> > > libraries were
> > > detected on your system."
> > > - ewarn "In order to avoid breaking
> > > packages that
> > > depend on these old libs,"
> > > - ewarn "the libraries are not being
> > > removed. You need
> > > to run revdep-rebuild"
> > > - ewarn "in order to remove these old
> > > dependencies. If
> > > you do not have this"
> > > - ewarn "helper program, simply emerge the
> > > 'gentoolkit'
> > > package."
> > > - ewarn
> > > - fi
> > > - ewarn " # revdep-rebuild --library '${lib}' &&
> > > rm '${lib}'"
> > > - done
> > > -}
> > > -
> > > # @FUNCTION: built_with_use
> > > # @USAGE: [--hidden] [--missing ] [-a|-o]
> > > > > flags>
> > > # @DESCRIPTION:
> > > diff --git a/eclass/preserve-libs.eclass b/eclass/preserve-
> > > libs.eclass
> > > new file mode 100644
> > > index ..548c6411fcf0
> > > --- /dev/null
> >
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Wed, 2018-01-10 at 08:55 +0100, Lars Wendler wrote: > On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote: > > > On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote: > > > * Posting to the list will only be possible to Gentoo developers > > > and > > > whitelisted additional participants. > > > > This is so contrary to what I and I thought Gentoo stands for: > > openness, transparency, inclusiveness even when these require a > > rather > > thick skin and result in high noise. It's a price worth paying. > > > > I guess I should a) pay more attention to council elections b) > > consider > > the idea that the whole council thing as it stands now is just not > > working. > > > > Wow. I couldn't have said it better. > Seems we're turning into an elitist club or something... > I wonder how many users we're going to loose on this one. Well done > council :-( > If your only reason to use Gentoo is because you can post to the main developer ML, and not because we try to provide a great distribution with lots of choice, a current toolchain and lots of customization, then you're likely using the wrong distribution.
Re: [gentoo-dev] [PATCH v2] vcs-snapshot.eclass: set -o (--no-same-owner) when unpacking, bug #645182
On Sun, 2018-01-21 at 00:26 +, Sergei Trofimovich wrote:
> Fixes build failures in unprivileged containers like bug #645182:
> Package:dev-python/pycparser-2.14
> >>> Unpacking source...
> tar: CHANGES: Cannot change ownership to uid 1000, gid 1000:
> Invalid argument
>
> In such containers uid=0 can't really change file ownership.
>
> Closes: https://bugs.gentoo.org/645182
> Signed-off-by: Sergei Trofimovich
> ---
> eclass/vcs-snapshot.eclass | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/vcs-snapshot.eclass b/eclass/vcs-snapshot.eclass
> index 3eff6995fae..2b3f73897ce 100644
> --- a/eclass/vcs-snapshot.eclass
> +++ b/eclass/vcs-snapshot.eclass
> @@ -67,7 +67,8 @@ vcs-snapshot_src_unpack() {
> # XXX: check whether the directory
> structure inside is
> # fine? i.e. if the tarball has
> actually a parent dir.
> mkdir "${destdir}" || die
> - tar -C "${destdir}" -x --strip-
> components 1 \
> + # -o (--no-same-owner) to avoid
> restoring original owner
> + tar -C "${destdir}" -x -o --strip-
> components 1 \
> -f "${DISTDIR}/${f}" || die
> ;;
> *)
Also, ultra-bikeshed: I think using "Signed-off-by" with yourself in it
is generally frowned upon and adds no real value.
Re: [gentoo-dev] [PATCH] cmake-utils.eclass: Override CMAKE_INSTALL_DOCDIR in EAPI 7
On Thu, 2018-03-29 at 21:14 +0200, Michał Górny wrote:
> Pass the correct docdir for GNUInstallDirs in EAPIs starting with 7.
> We do not need add it retroactively to avoid breaking something
> accidentally.
> ---
> eclass/cmake-utils.eclass | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index 3302f27608b3..b21822fc03e9 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -614,6 +614,12 @@ cmake-utils_src_configure() {
> _EOF_
> [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo 'SET
> (CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make"
> FORCE)' >> "${common_config}"
>
> + if [[ ${EAPI} != [56] ]]; then
> + cat >> "${common_config}" <<- _EOF_ || die
> + SET (CMAKE_INSTALL_DOCDIR
> "${EPREFIX}/usr/share/doc/${PF}" CACHE PATH "")
> + _EOF_
> + fi
> +
> # Wipe the default optimization flags out of CMake
> if [[ ${CMAKE_BUILD_TYPE} != Gentoo && ${EAPI} != 5 ]]; then
> cat >> ${common_config} <<- _EOF_ || die
Consider whether adding the full absolute path is the way we want to
go. Setting CMAKE_INSTALL_DOCDIR to "share/doc/${PF}" should suffice.
Re: [gentoo-dev] Re: RFC: intel-sdp-r1.eclass
On Mi, 2016-02-17 at 10:53 +, Duncan wrote: > Michał Górny posted on Wed, 17 Feb 2016 07:47:06 +0100 as excerpted: > > > On Tue, 16 Feb 2016 22:48:08 -0600 Ryan Hill > > wrote: > > > > > On Mon, 15 Feb 2016 15:35:12 +0100 Michał Górny > > g> > > > wrote: > > > > On Mon, 15 Feb 2016 14:37:41 +0100 "Justin Lecher (jlec)" > > > > wrote: > > > > > On 15/02/16 13:59, Michał Górny wrote: > > > > > > > Don't mix echo with ewarn. > > > > > Why? > > > > Because they won't go through the same output channels. > > > > > > That's kinda the point. You want a blank (unstarred) space to > > > separate > > > out the "important" messages from the generic spew put out by the > > > package manager/eclasses/build system that you have no control > > > over. > > > > This is not just that. Different output channels mean that: > > > - There is no guarantee of correct output order! The empty lines > > may > > move randomly over the text. > > Good point! (Of course the others are too, but this one could be > particularly damaging to the intended communication.) > > > > If you have several different messages you want a blank space in > > > between them so you can use e* to create whitespace within the > > > message > > > to avoid the wall of text syndrome while still making it clear > > > where it > > > begins and ends. > > > > You're right that using echo means the whitespace doesn't get > > > saved by > > > the elog system. A while back someone proposed we add espace for > > > exactly this reason but IIRC they were laughed down, which is a > > > shame. > > > > So... to summarize your point. You shouldn't use the correct > > function > > that is saved in elog which is primary way of getting info because > > you > > find it more convenient to have empty non-'starred' lines that > > don't > > actually get to elog and make elog a mess? > > > > If you really don't like empty 'starred' lines (and I actually like > > them > > since they make separation between packages cleaner), why not > > submit a > > patch for Portage and make 'elog' with no arguments output log line > > without a star? That's a trivial solution that doesn't require > > extra > > functions for the sake of inventing elogspace, ewarnspace, ... > > It is at least possible to use say blank ewarn between elog lines, or > the > reverse, so while there's no totally blank separator, there's at > least a > different color to the star on the starred-blank-line separator. > > Similarly, if there's more than one "topic" to the messages, and > they're > of different severity, the severities can be interspersed to get > color > separation. > > I believe I've seen both techniques used to good effect in a few > packages > in the past, but I can't name any off the top of my head. > For all those who care, I've updated the eclass under: https://github.com/gentoo-science/sci/pull/588
Re: [gentoo-dev] BOINC needs maintainer
On Do, 2016-02-18 at 09:29 +0100, Sven Eden wrote: > Am Mittwoch, 17. Februar 2016, 15:20:56 CET schrieb Justin Lecher > (jlec): > > currently BOINC supposed to be maintained by the science team, but > > we > > are not really carrying about it. Is there anyone around whole > > likes to > > take this over? > > I have a sci-misc/boinc-7.6 ebuild in my overlay "seden" (via > layman). > > Feel free to use it. Works fine, at least on my system. > > Cheers > > Sven Sven, would you be willing to maintain it as a proxy maintainer? David
[gentoo-dev] RFC: intel-sdp-r1.eclass, Take #2
@]}"; do
- for a in ${arch}; do
- if [ ${p} == $(basename ${p}) ]; then
+ # Expand components into full RPM filenames
+ expand_component_into_full_rpm() {
+ local deref_var="${1}[@]"
+ local arch="${2}"
+
+ local p a rpm_prefix rpm_suffix
+
+ for p in "${!deref_var}"; do
+ for a in ${arch}; do
+# check if a directory is prefixed
+if [[ "${p}" == "${p##*/}" ]]; then
+ rpm_prefix="${INTEL_RPMS_DIR}/intel-"
+else
+ rpm_prefix=""
+fi
+
# check for variables ending in ".rpm"
# these are excluded from version expansion, due to Intel's
# idiosyncratic versioning scheme beginning with their 2016
-# suite of tools.
-if [[ "${p}" == *.rpm ]]; then
- INTEL_RPMS+=( intel-${p} )
-else
- INTEL_RPMS+=( intel-${p}-${_INTEL_PV}.${a}.rpm )
-fi
- else
+# suite of tools. For instance
+#
+# intel-ccompxe-2016.1-056.noarch.rpm
+#
+# which is completely unpredictable using versions
if [[ "${p}" == *.rpm ]]; then
- INTEL_RPMS_FULL+=( ${p} )
+ rpm_suffix=""
else
- INTEL_RPMS_FULL+=( ${p}-${_INTEL_PV}.${a}.rpm )
+ rpm_suffix="-${_INTEL_PV}.${a}.rpm"
fi
- fi
+
+INTEL_RPMS+=( "${rpm_prefix}${p}${rpm_suffix}" )
+ done
done
- done
+ }
+
+ local vars_to_expand=("INTEL_BIN_RPMS" "INTEL_X86_RPMS" "INTEL_DAT_RPMS")
+ local vars_to_expand_suffixes=("${arch}" "${INTEL_X86}" "noarch")
if use amd64; then
- for p in "${INTEL_AMD64_RPMS[@]}"; do
- if [ ${p} == $(basename ${p}) ]; then
-if [[ "${p}" == *.rpm ]]; then
- INTEL_RPMS+=( intel-${p} )
-else
- INTEL_RPMS+=( intel-${p}-${_INTEL_PV}.x86_64.rpm )
-fi
- else
-if [[ "${p}" == *.rpm ]]; then
- INTEL_RPMS_FULL+=( ${p} )
-else
- INTEL_RPMS_FULL+=( ${p}-${_INTEL_PV}.x86_64.rpm )
-fi
- fi
- done
+ vars_to_expand+=("INTEL_AMD64_RPMS")
+ vars_to_expand_suffixes+=("x86_64")
fi
- for p in "${INTEL_X86_RPMS[@]}"; do
- if [ ${p} == $(basename ${p}) ]; then
- if [[ "${p}" == *.rpm ]]; then
-INTEL_RPMS+=( intel-${p} )
- else
-INTEL_RPMS+=( intel-${p}-${_INTEL_PV}.${INTEL_X86}.rpm )
- fi
- else
- if [[ "${p}" == *.rpm ]]; then
-INTEL_RPMS_FULL+=( ${p} )
- else
-INTEL_RPMS_FULL+=( ${p}-${_INTEL_PV}.${INTEL_X86}.rpm )
- fi
- fi
- done
-
- for p in "${INTEL_DAT_RPMS[@]}"; do
- if [ ${p} == $(basename ${p}) ]; then
- if [[ "${p}" == *.rpm ]]; then
-INTEL_RPMS+=( intel-${p} )
- else
-INTEL_RPMS+=( intel-${p}-${_INTEL_PV}.noarch.rpm )
- fi
- else
- if [[ "${p}" == *.rpm ]]; then
-INTEL_RPMS_FULL+=( ${p} )
- else
-INTEL_RPMS_FULL+=( ${p}-${_INTEL_PV}.noarch.rpm )
- fi
- fi
+ _isdp_set-version-vars
+ local i
+ for ((i=0; i<${#vars_to_expand[@]}; i++)); do
+ expand_component_into_full_rpm "${vars_to_expand[i]}" "${vars_to_expand_suffixes[i]}"
done
+ _isdp_unset-version-vars
}
# @FUNCTION: intel-sdp-r1_src_unpack
# @DESCRIPTION:
# Unpacking necessary rpms from tarball, extract them and rearrange the output.
intel-sdp-r1_src_unpack() {
- local l r subdir rb t list=() debug_list
-
+ local t
for t in ${A}; do
+ local r list=()
for r in "${INTEL_RPMS[@]}"; do
- rpmdir=${t%%.*}/${INTEL_RPMS_DIR}
- list+=( ${rpmdir}/${r} )
- done
-
- for r in "${INTEL_RPMS_FULL[@]}"; do
list+=( ${t%%.*}/${r} )
done
+ local debug_list
debug_list="$(IFS=$'\n'; echo ${list[@]} )"
debug-print "Adding to decompression list:"
debug-print ${debug_list}
- tar xvf "${DISTDIR}"/${t} ${list[@]} &> "${T}"/rpm-extraction.log
+ tar -xvf "${DISTDIR}"/${t} ${list[@]} &> "${T}"/rpm-extraction.log
for r in ${list[@]}; do
- rb=$(basename ${r})
- einfo "Unpacking ${rb}"
- rpm2tar -O ${r} | tar xvf - | sed -e \
-"s:^\.:${EROOT#/}:g" > /dev/null; assert "unpacking ${r} failed"
+ einfo "Unpacking ${r}"
+ echo "Unpacking ${r}" >> "${T}"/rpm-extraction.log
+ rpm2tar -O ${r} | tar -xvf - &>> "${T}"/rpm-extraction.log; assert "Unpacking ${r} failed"
done
done
}
@@ -494,9 +488,9 @@ intel-sdp-r1_src_install() {
debug-print-function ${FUNCNAME} "${@}"
# remove uninstall information
- if path_exists opt/intel/"${INTEL_DPN}"*/uninstall; then
+ if path_exists opt/intel/"${INTEL_DIST_NAME}"*/uninstall; then
ebegin "Cleaning out uninstall"
- rm -r opt/intel/"${INTEL_DPN}"*/uninstall || die
+ rm -r opt/intel/"${INTEL_DIST_NAME}"*/uninstall || die
ee
[gentoo-dev] Last-rites: dev-libs/ptypes
# David Seifert (05 Apr 2016) # No upstream release since 2007, no revdeps in tree, # version in tree outdated, bug #454702. # Masking for removal in 30 days dev-libs/ptypes
Re: [gentoo-dev][PATCH v1 ] sys-fs/hfsplusutils with gcc-5: blockiter.c:148:8: error: redefinition of blockiter_curr #580620
I generally prefer using -std=gnu89 instead of -fgnu89-inline, as GCC might
change some C11 semantics later on. To me -std=gnu89 seems more robust.
David
> On 22 Apr 2016, at 23:39, Mike Frysinger wrote:
>
> On 22 Apr 2016 03:57, Leno Hou wrote:
>> +-extern inline UInt32 blockiter_curr(blockiter *b)
>> +-{
>> +-return b->e->start_block + b->block;
>> +-}
>> +-
>> +-
>> ++extern inline UInt32 blockiter_curr(blockiter *b);
>
> i don't think that's how you want to handle extern inline.
> it doesn't make sense when it's declared this way as there
> is no actual body for gcc to optimisitcally inline.
>
> instead, we should go with what Ubuntu/Debian have: use the
> -fgnu89-inline flag to build since those are the semantics
> this code expects. i've pushed that fix now.
> -mike
[gentoo-dev] Last-rites: sci-libs/torch
# David Seifert (15 May 2016) # Masked for removal. Deprecated, relies on ancient CUDA APIs, # does not build with current CUDA releases. See bug #583068. sci-libs/torch
Re: [gentoo-dev] [RFC] Global USE=gui
On Di, 2016-06-07 at 12:03 -0700, Brian Dolbec wrote: > On Tue, 7 Jun 2016 14:29:58 -0400 > Michael Orlitzky wrote: > > > > > On 06/07/2016 12:20 PM, Michał Górny wrote: > > > > > > > > > So many weird ideas... while the simplest one is a proper > > > REQUIRED_USE with gui being the control flag, and IUSE defaults > > > to > > > select the preferred toolkit. > > > > > This is what came to my mind. > > > > The underlying problem that we are hitting (a la Patrick) is that > > USE > > flags are supposed to be a user-interface for building software > > from > > source, but implementation details are an important part of > > configuring the software to be built. > > > > It would be nice if USE=gui meant "build a GUI" and that was all > > the > > input that we needed from the user. But if the upstream package > > supports both QT and GTK and we need to pass either --with-qt or > > --with-gtk to the build system, then there is an unavoidable choice > > to be made. We can prefer one, but both options need to be > > available. > > > > If we want the best of both worlds -- a nice user-interface and > > full > > configurability -- then we can use "the user wants a GUI" as a > > trigger > > for the implementation choice. If there's a default implementation > > and > > the user doesn't care, no further interference should be necessary. > > Otherwise the presence of the generic USE=gui will let us know, so > > we > > can let the user know, that he needs to pick one. > > > > > This is where my thought from a few days ago kicks in... > I had started to discuss it with Kristian. > > > I propose to help alleviate the __MESS__ from all this force-foo and > other complicated USE flag REQUIRED_USE madness... > > We instead implement something along the lines of: > > an ordered list of the gui toolkits in their preferred order of > desirability. This should be an all inclusive list. Note: these are > subject to package.use setting overrides. > > PREFERRED_GUIS="gtk2 qt4 qt5 x wxwidgets X ... ncurses tty -gkt3" > > In the above it means that if gtk2 is an option, then choose it, mask > (de-select) the others. > In there it also means DO NOT SELECT gtk3 So if you want a pkg > and > it NEEDS gtk3, then the PM will puke it back at you saying you can't > have one without the other... > So, then you have to fix it manually via package.use > settings. Accept > gtk3 for this pkg only (not that it doesn't likely have other gtk3 > deps that will also need this...) > > In the general case it will pick the first toolkit in order of > preference (left to right) and only that toolkit that the pkg is > capable > of using. > > For pkgs capable of multiple simultaneous toolkits installed, then > again, manual intervention would be needed to set package.use. > > This would also have to be a package manager feature and run similar > to > the auto-unmask feature. > > FEATURES="preferred-guis" > > Let's try and keep things as simple as possible. > From what I've gleaned form the emails I have read, is that what the > general user wants to happen, select the toolkit in the order of > their > preference. +1 Personally I see this as the only tractable option to stop the insanity. David
[gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM
Dear friends, while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86 list could be expanded a bit: avx512 - introduced with Skylake and Knights Landing I also propose creating a CPU_FLAGS_PPC variable containing (at least): altivec - PowerPC's SSE vsx - PowerPC's AVX Finally, I also propose creating CPU_FLAGS_ARM variable containing: neon Any ideas? Currently cpu-feature flags for non-x86 are package local, whereas making them globally available makes masking easier for non- applicable archs etc. and makes enabling them easier for users. David
[gentoo-dev] Last-rite net-libs/socket++
David Seifert (01 Oct 2016) Masked for failing to build with C++11, ancient codebase, dead upstream, no updates in 5 years. No revdeps. Mask for removal in 30 days. Bug #595754
[gentoo-dev] Last rite dev-libs/dbxml
David Seifert (18 Sep 2016) Masked for failing to build with GCC 6, still using ancient distutils.eclass, tightly coupled to dev-libs/xqilla-2.2*. Purged by Debian and Fedora more than 5 years ago. Mask for removal in 30 days. Bug #594236
[gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-check-openmp() function
Hey all,
I'd like to add a new function to toolchain-funcs, which presents a
consist interface to users of packages somehow relying on OpenMP.
Currently, (most) ebuilds relying on OpenMP test with tc-has-openmp and
if OpenMP is not available, do something, like print a message and die,
just print a warning, or change some flags implicitly without warning.
This new function, tc-check-openmp, checks for OpenMP, dies if it is
non-functional, and tells the user how to rectify the situation. This
is better than all the current solutions, which, for instance, do not
take CC=clang into account. It also makes extending the messages easier
for new compilers. In most cases, this should obviate the direct use of
tc-has-openmp.
>From eaab3e443da8ee1970679b3d4016f12541d84344 Mon Sep 17 00:00:00 2001
From: David Seifert
Date: Wed, 12 Oct 2016 22:15:03 +0200
Subject: [PATCH] toolchain-funcs.eclass: Add tc-check-openmp() function
---
eclass/toolchain-funcs.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-
funcs.eclass
index 5bac36b..d8a28af 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -421,6 +421,25 @@ tc-has-openmp() {
return ${ret}
}
+# @FUNCTION: tc-check-openmp
+# @DESCRIPTION:
+# Test for OpenMP support with the current compiler and error out with
+# a clear error message, telling the user how to rectify the missing
+# OpenMP support that has been requested by the ebuild.
+tc-check-openmp() {
+ if ! tc-has-openmp; then
+ ewarn "Your current compiler does not support OpenMP"
+
+ if tc-is-gcc; then
+ ewarn "Enable OpenMP support by building sys-
devel/gcc with USE=\"openmp\"."
+ elif tc-is-clang; then
+ ewarn "OpenMP support in sys-devel/clang is
provided by sys-libs/libomp."
+ fi
+
+ die "Active compiler does not have required support
for OpenMP"
+ fi
+}
+
# @FUNCTION: tc-has-tls
# @USAGE: [-s|-c|-l] [toolchain prefix]
# @DESCRIPTION:
--
2.10.1
Re: [gentoo-dev] RFC: Ban dolib and libopts in EAPI 7
On Do, 2016-10-13 at 15:53 +0200, Ulrich Mueller wrote:
> Hi all,
>
> I suggest that we ban the dolib and libopts commands in EAPI 7.
>
> Rationale:
> 1. There are about 60 instances of dolib in the tree. At least one
> third of them appears to be wrong (e.g., should be replaced by
> dolib.so for correct mode).
> 2. libopts affects only dolib, while the more special commands
> dolib.a
> and dolib.so install libraries with fixed modes 0644 and 0755,
> respectively. (The latter is also consistent with dobin installing
> with fixed mode 0755, i.e., there is no binopts command.)
> 3. There is no newlib command corresponding to dolib, whereas
> newlib.{a,so} commands exist.
> 4. libopts is not used at all in the tree, which strongly indicates
> that there is no need for it.
>
> Replacement:
> Use dolib.a or dolib.so instead.
>
> Comments?
>
> Ulrich
+1
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-check-openmp() function
On Do, 2016-10-13 at 16:40 -0400, Michael Orlitzky wrote: > On 10/13/2016 04:35 PM, David Seifert wrote: > > > > + ewarn "Your current compiler does not support > > OpenMP" > > + > > + ... > > + > > + die "Active compiler does not have required > > support > > Hey, a message that isn't about comrel. Since you're going to die(), > isn't eerror more accurate than ewarn? > > > Merged, with ewarn replaced by eerror as requested. Please use this function in future if you need to assert a working OpenMP toolchain, and not check for OpenMP yourself and print some self-built error message (think of the clang users!).
Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m
On Sa, 2016-10-08 at 13:57 +0200, Pacho Ramos wrote: > # Pacho Ramos (08 Oct 2016) > # Uses get_libdir at global scope (#593382). Dead for ages. Removal > in > a > # month. > app-cdr/nero I'd like to keep this package, hence fixed the issues, bumped to EAPI=6, took over maintainership.
[gentoo-dev] Lastrites: net-libs/libkolab
# David Seifert (29 Oct 2016) # Unmaintained, depends on ancient and broken C++ libraries # Removal in 30 days. net-libs/libkolab net-libs/libkolabxml
[gentoo-dev] Lastrites: dev-cpp/{libfrontend-elements,libbackend-elements,libcult}
# David Seifert (29 Oct 2016) # Unmaintained, broken, do not work with GCC 6 # Bugs #594506, #597780, removal in 30 days.
[gentoo-dev] Last rites: net-analyzer/snips
# David Seifert (20 Dec 2016) # Masked for being completely broken and unusable (bug 586356). # No reverse dependencies. Masked for removal in 30 days. net-analyzer/snips
[gentoo-dev] Re: Packages up for grabs due to retirement
On Sat, 2016-12-31 at 22:54 +0100, Thomas Kahle wrote:
> Hi,
>
> I will retire, so here are my remaining packages. Feel free to
> e-mail me any questions re this. sci-math is in CC because there
> are quite a few math packages.
>
> app-emacs/undo-tree
> app-misc/anki
> app-portage/tatt
> app-text/tesseract
> app-text/pdfsandwich
> dev-cpp/gtest
> dev-python/python-wpactrl
> dev-python/python-iwscan
> media-sound/gmtp
> net-misc/wicd
> sci-libs/bliss
> sci-libs/mpir
> sci-libs/lrslib
> sci-mathematics/gfan
> sci-mathematics/nauty
> sci-mathematics/singular
> sci-mathematics/frobby
> sci-mathematics/normaliz
> sci-mathematics/polymake
> sci-mathematics/4ti2
> sci-mathematics/bertini
> sci-mathematics/topcom
> sci-mathematics/gimps
> sci-mathematics/xmds
> sci-mathematics/Macaulay2
> sci-misc/flashdot
> www-apps/tt-rss
>
> Cheers,
> Thomas
>
>
Sad to see you go Thomas. As a finalising act, could you please assign
sci-{libs,misc}/* -> sci project
sci-mathematics/* -> sci-mathematics project
We will then maintain those packages as part of the project.
Regards
David
[gentoo-dev] Last rites: games-emulation/visualboyadvance
# David Seifert (29 Dec 2016) # Ancient codebase, maintenance nightmare, dead # upstream, games-emulation/vbam is spiritual successor # Removal in 30 days, #598607 games-emulation/visualboyadvance
Re: [gentoo-dev] RFC: toolchain.eclass prefix support
On Sun, 2017-01-08 at 00:25 +0900, Benda Xu wrote: > James Le Cuirot writes: > > > Why? All the ebuilds using this eclass that I can find are at least > > EAPI 4. > > Okay! I will remove this. > > Benda https://qa-reports.gentoo.org/output/eapi-per-eclass/toolchain.eclass/S TATS.txt Chewi seems right, no use in defining them.
[gentoo-dev] Last rites: dev-ml/ocamlgsl
# David Seifert (18 Jan 2017) # Dead upstream, spiritual successor is dev-ml/gsl-ocaml # Masked for removal in 30 days. Bug #574564, #593248, #601912. dev-ml/ocamlgsl
[gentoo-dev] Last rites: leechcraft
Please do not resurrect leechcraft unless you're willing to fix the bugs with GCC 5 (and GCC 6) and newer dependencies. Personally, I feel leechcraft should probably live in an overlay instead of the tree. # David Seifert (30 Jan 2017) # No maintainer activity since git migration, dated eclass # Multiple open bugs, with no activity: # 499176, 501170, 521072, 538156, 562300, 562476, 563714, # 586464, 587862, 588890, 602294, 603556, 607004 # Masked for removal in 30 days. app-leechcraft/laretz app-leechcraft/lc-advancednotifications app-leechcraft/lc-aggregator app-leechcraft/lc-anhero app-leechcraft/lc-auscrie app-leechcraft/lc-azoth app-leechcraft/lc-bittorrent app-leechcraft/lc-blasq app-leechcraft/lc-blogique app-leechcraft/lc-certmgr app-leechcraft/lc-core app-leechcraft/lc-cpuload app-leechcraft/lc-cstp app-leechcraft/lc-dbusmanager app-leechcraft/lc-deadlyrics app-leechcraft/lc-devmon app-leechcraft/lc-dolozhee app-leechcraft/lc-eleeminator app-leechcraft/lc-fenet app-leechcraft/lc-gacts app-leechcraft/lc-glance app-leechcraft/lc-gmailnotifier app-leechcraft/lc-historyholder app-leechcraft/lc-hotsensors app-leechcraft/lc-hotstreams app-leechcraft/lc-htthare app-leechcraft/lc-imgaste app-leechcraft/lc-intermutko app-leechcraft/lc-kbswitch app-leechcraft/lc-kinotify app-leechcraft/lc-knowhow app-leechcraft/lc-krigstask app-leechcraft/lc-lackman app-leechcraft/lc-lastfmscrobble app-leechcraft/lc-laughty app-leechcraft/lc-launchy app-leechcraft/lc-lemon app-leechcraft/lc-lhtr app-leechcraft/lc-liznoo app-leechcraft/lc-lmp app-leechcraft/lc-mellonetray app-leechcraft/lc-monocle app-leechcraft/lc-musiczombie app-leechcraft/lc-nacheku app-leechcraft/lc-netstoremanager app-leechcraft/lc-networkmonitor app-leechcraft/lc-newlife app-leechcraft/lc-ooronee app-leechcraft/lc-otlozhu app-leechcraft/lcpackgen app-leechcraft/lc-pintab app-leechcraft/lc-pogooglue app-leechcraft/lc-popishu app-leechcraft/lc-poshuku app-leechcraft/lc-qrosp app-leechcraft/lc-rosenthal app-leechcraft/lc-sb2 app-leechcraft/lc-scroblibre app-leechcraft/lc-secman app-leechcraft/lc-seekthru app-leechcraft/lc-summary app-leechcraft/lc-sysnotify app-leechcraft/lc-tabsessmanager app-leechcraft/lc-tabslist app-leechcraft/lc-touchstreams app-leechcraft/lc-tpi app-leechcraft/lc-vgrabber app-leechcraft/lc-vrooby app-leechcraft/lc-xproxy app-leechcraft/lc-xtazy app-leechcraft/leechcraft-meta app-leechcraft/liblaretz virtual/leechcraft-browser virtual/leechcraft-downloader-http virtual/leechcraft-notifier virtual/leechcraft-quark-sideprovider virtual/leechcraft-search-show virtual/leechcraft-storage-device-manager virtual/leechcraft-task-show virtual/leechcraft-trayarea virtual/leechcraft-wysiwyg-editor
Re: [gentoo-dev] Last rites: leechcraft
On Mon, 2017-01-30 at 17:43 -0500, Georg Rudoy wrote: > 2017-01-30 13:35 GMT-05:00 David Seifert : > > Please do not resurrect leechcraft unless you're willing to fix the > > bugs with GCC 5 (and GCC 6) and newer dependencies. Personally, I > > feel > > leechcraft should probably live in an overlay instead of the tree. > > I was previously proxy-maintaining it via Maxim Koltsov aka > maksbotan. > What's the best way for me to step up and maintain it more directly? > Would PRs on github work? > > Proxy-maint has always been there, so no real excuse for all those bugs rotting away. Here's the deal: If you fix all those bugs within the 30 day time period, we'll keep it in the tree. Please also modernize the eclass a bit, and preferably drop all ebuilds to unstable. Send all your PRs via Github, mentioning my handle @SoapGentoo. Given that this leechcraft ecosystem has a very small, dedicated community, I think maintaining it in a separate overlay, pulled in by layman or whatever would still be a better approach.
Re: [gentoo-dev] Last rites: leechcraft
On Tue, 2017-01-31 at 17:34 +0100, Kristian Fiskerstrand wrote: > On 01/31/2017 03:50 PM, Georg Rudoy wrote: > > I'll make a new release of leechcraft itself and bump the version > > to > > that new one, so they'll naturally be dropped to unstable, 0.6.70 > > and > > earlier (if any) indeed could be removed. Most of the bugs, as I > > saw > > them, are due to the current last released version being 2.5 years > > old > > and obviously bitrotten somewhat since then. > > I'd still recommend spending a bit of time to consider whether this > doesn't fit better in an overlay, which would also make it easier to > maintain without overburdening proxy maint given the number of > packages > involved. > I really second this - we can ask infra to get you an overlay. Should it turn out that you are truly maintaining stuff, we can then merge it into the tree.
[gentoo-dev] Last rites: emboss-r2.eclass
# @DEAD # Removal on 2022-03-15. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dev-util/cmake needs a (co-)maintainer
On Thu, 2022-02-24 at 19:11 +0100, Andreas Sturmlechner wrote: > The de facto maintainer for many years has effectively quit doing so. > > While kde project is the main user of cmake, I don't have the time to > care for > every package that is part of KDE packages' dependency graph. > > This means that without a more dedicated co-maintainer, cmake version > bumps > will occur much less often in the future. > > Regards, > Andreas I will add base@ as a maintainer, given the wide impact CMake has on the ecosystem. David
[gentoo-dev] Last rites: net-fs/smbtad
# David Seifert (2022-02-27) # Last release 10 years ago, no other distro packages this, # stuck on cmake-utils.eclass and QA issues. # Bug #711880, #774519, removal on 2022-03-27. net-fs/smbtad signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-wireless/rtl_power_fftw
# David Seifert (2022-03-12) # Unmaintained, no revdeps in tree, no other distro packages this, # wrong dependencies, out of date, stuck on deprecated # (and soon-to-stop-working) cmake-utils. bug #702980, #834121. # Removal on 2022-04-11. net-wireless/rtl_power_fftw signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sys-apps/rtl-entropy
# David Seifert (2022-03-12) # Unmaintained, no revdeps in tree, no other distro packages this, # HOMEPAGE gone, stuck on deprecated (and soon-to-stop-working) # cmake-utils. bug #725610, #732056, #834117. # Removal on 2022-04-11. sys-apps/rtl-entropy signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sci-biology/GBrowse
# David Seifert (2022-03-19) # Unmaintained, no revdeps in tree, not even on latest version, EAPI 5, # typical 'webapp' smell, last upstream release more than 9 years ago. # Bug #402849, #513594, #690042, #828702, removal on 2022-04-18. sci-biology/GBrowse signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sys-block/megarc
# David Seifert (2022-03-19) # Unmaintained, no revdeps in tree, EAPI 5, upstream tarball disappeared # and ebuild is mirror-restricted. # Bug #672324, #689770, #835360, removal on 2022-04-18. sys-block/megarc signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: net-wireless/yatebts, net-wireless/srslte, net-wireless/nanovna-saver, net-wireless/gr-scan
On Sun, 2022-03-20 at 18:44 +0100, tom...@gentoo.org wrote: > I would like to keep net-wireless/nanovna-saver. I pushed version > 0.3.10 to > the tree which should fix the problems. > > Shall I drop it from package mask or do you want to do it yourself > Jakov. > > - Thomas > > > On Wed, Mar 16, 2022 at 11:08:05PM +0100, Jakov Smolić wrote: > > # Jakov Smolić (2022-03-16) > > # Unmaintaned, broken packages with no revdeps. > > # Bugs 822234, 809539, 809536, 832618, 731720, 713684, > > # 733662, 741082, and many others. > > # Removal on 2022-04-16. > > net-wireless/yatebts > > net-wireless/srslte > > net-wireless/nanovna-saver > > net-wireless/gr-scan > > -- > > Jakov > Your new ebuild still doesn't support python 3.10, without which it would be lagging again.
[gentoo-dev] Last rites: sys-cluster/lustre
# David Seifert (2022-03-20) # Added and then left unmaintained by author, no revdeps in tree, # stuck on kernel 4.19, distribution model unlikely a good fit for # Gentoo, QA issues, blocks automake-1.15 removal, build issues. # Bug #725746, #728154, #835693, removal on 2022-04-19. sys-cluster/lustre signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: media-video/mplayer-sh
# David Seifert (2022-03-21) # EAPI 5, last release 15 years ago, QA permission issues, no other # distro packages this. # Bug #553404, #835364, removal on 2022-04-20. media-video/mplayer-sh signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-java/* EAPI 5 packages
# David Seifert (2022-03-21) # Unmaintained, EAPI 5, no revdeps in tree. # Bug #786093, removal on 2022-04-20. dev-java/freehep-graphicsbase dev-java/freehep-io dev-java/glassfish-interceptor-api dev-java/gnu-classpath dev-java/invokebinder dev-java/java-apicheck dev-java/jboss-marshalling-river dev-java/jboss-marshalling-serial dev-java/jrobin signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: media-libs/libtaginfo and media-sound/xnoise
# David Seifert (2022-03-27) # Long abandoned upstreams, segfaults, bunch of tests fail, # no other major distro carries this anymore. # Bug #631320, #740484, #830090, #836278, removal on 2022-04-26. media-libs/libtaginfo media-sound/xnoise signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sys-devel/automake:1.13+1.15
# David Seifert (2022-04-06) # Unsupported branches, no consumers left, removal on 2023-01-01. sys-devel/automake:1.13 sys-devel/automake:1.15 **NOTE**: Slot 1.11 remains masked and will *not* be removed for the foreseeable future, since developers may need it for de-ANSI-fication (ansi2knr) support. signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-p2p/syrep
# David Seifert (2022-04-10) # Unmaintained, last release upstream 16 years ago, Fedora dropped it, # relies on sys-libs/db, low quality port to EAPI 6, removal on 2022-05- 10. net-p2p/syrep signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 1/2] kernel-2.eclass: remove EAPI 6
Signed-off-by: David Seifert
---
eclass/kernel-2.eclass | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index bd982d3a52c..51dabc4562d 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: kernel-2.eclass
@@ -8,7 +8,7 @@
# John Mylchreest
# Mike Pagano
#
-# @SUPPORTED_EAPIS: 6 7 8
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: Eclass for kernel packages
# @DESCRIPTION:
# This is the kernel.eclass rewrite for a clean base regarding the 2.6
@@ -282,10 +282,9 @@
# that of course does not mean we're not willing to help.
inherit estack toolchain-funcs
-[[ ${EAPI} == 6 ]] && inherit eapi7-ver
case ${EAPI} in
- 6|7|8) ;;
+ 7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -657,7 +656,6 @@ kernel_is() {
# Capture the sources type and set DEPENDs
if [[ ${ETYPE} == sources ]]; then
- [[ ${EAPI} == 6 ]] && DEPEND="!build? ( sys-apps/sed )" ||
BDEPEND="!build? ( sys-apps/sed )"
RDEPEND="!build? (
app-arch/cpio
@@ -863,10 +861,10 @@ install_headers() {
local ddir=$(kernel_header_destdir)
env_setup_xmakeopts
- emake headers_install INSTALL_HDR_PATH="${ED%/}"${ddir}/.. ${xmakeopts}
+ emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/.. ${xmakeopts}
# let other packages install some of these headers
- rm -rf "${ED%/}"${ddir}/scsi || die #glibc/uclibc/etc...
+ rm -rf "${ED}"${ddir}/scsi || die #glibc/uclibc/etc...
return 0
}
@@ -893,7 +891,7 @@ install_sources() {
done
fi
- mv "${WORKDIR}"/linux* "${ED%/}"/usr/src || die
+ mv "${WORKDIR}"/linux* "${ED}"/usr/src || die
if [[ -n ${UNIPATCH_DOCS} ]]; then
for i in ${UNIPATCH_DOCS}; do
@@ -933,15 +931,15 @@ postinst_sources() {
# if we are to forcably symlink, delete it if it already exists first.
if [[ ${K_SYMLINK} -gt 0 ]]; then
- if [[ -e ${EROOT%/}/usr/src/linux && ! -L
${EROOT%/}/usr/src/linux ]] ; then
- die "${EROOT%/}/usr/src/linux exist and is not a
symlink"
+ if [[ -e ${EROOT}/usr/src/linux && ! -L ${EROOT}/usr/src/linux
]] ; then
+ die "${EROOT}/usr/src/linux exist and is not a symlink"
fi
- ln -snf linux-${KV_FULL} "${EROOT%/}"/usr/src/linux || die
+ ln -snf linux-${KV_FULL} "${EROOT}"/usr/src/linux || die
fi
# Don't forget to make directory for sysfs
- [[ ! -d ${EROOT%/}/sys ]] && kernel_is 2 6 && { mkdir "${EROOT%/}"/sys
|| die ; }
+ [[ ! -d ${EROOT}/sys ]] && kernel_is 2 6 && { mkdir "${EROOT}"/sys ||
die ; }
elog "If you are upgrading from a previous kernel, you may be
interested"
elog "in the following document:"
@@ -1537,10 +1535,10 @@ kernel-2_pkg_postrm() {
[[ ${ETYPE} == headers ]] && return 0
# If there isn't anything left behind, then don't complain.
- [[ -e ${EROOT%/}/usr/src/linux-${KV_FULL} ]] || return 0
+ [[ -e ${EROOT}/usr/src/linux-${KV_FULL} ]] || return 0
ewarn "Note: Even though you have successfully unmerged "
ewarn "your kernel package, directories in kernel source location: "
- ewarn "${EROOT%/}/usr/src/linux-${KV_FULL}"
+ ewarn "${EROOT}/usr/src/linux-${KV_FULL}"
ewarn "with modified files will remain behind. By design, package
managers"
ewarn "will not remove these modified files and the directories they
reside in."
ewarn "For more detailed kernel removal instructions, please see: "
--
2.35.1
[gentoo-dev] [PATCH 2/2] kernel-2.eclass: fix spelling
Signed-off-by: David Seifert
---
eclass/kernel-2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 51dabc4562d..02c70422ee0 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -670,7 +670,7 @@ if [[ ${ETYPE} == sources ]]; then
)"
SLOT="${PVR}"
- DESCRIPTION="Sources based on the Linux Kernel."
+ DESCRIPTION="Sources based on the Linux Kernel"
IUSE="symlink build"
# Bug #266157, deblob for libre support
@@ -932,7 +932,7 @@ postinst_sources() {
# if we are to forcably symlink, delete it if it already exists first.
if [[ ${K_SYMLINK} -gt 0 ]]; then
if [[ -e ${EROOT}/usr/src/linux && ! -L ${EROOT}/usr/src/linux
]] ; then
- die "${EROOT}/usr/src/linux exist and is not a symlink"
+ die "${EROOT}/usr/src/linux exists and is not a symlink"
fi
ln -snf linux-${KV_FULL} "${EROOT}"/usr/src/linux || die
--
2.35.1
Re: [gentoo-dev] [PATCH] java-utils-2.eclass: remove ebegin calls that lack eend calls
On Fri, 2022-04-15 at 10:11 -0400, Mike Gilbert wrote:
> Instead, echo the command we are about to run.
>
> Closes: https://bugs.gentoo.org/838475
> Closes: https://bugs.gentoo.org/838478
> Closes: https://bugs.gentoo.org/838481
> Closes: https://bugs.gentoo.org/838487
> Closes: https://bugs.gentoo.org/838490
> Closes: https://bugs.gentoo.org/838493
> Signed-off-by: Mike Gilbert
> ---
> eclass/java-utils-2.eclass | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
> index 11798908dae..2a649942550 100644
> --- a/eclass/java-utils-2.eclass
> +++ b/eclass/java-utils-2.eclass
> @@ -2099,8 +2099,9 @@ ejavac() {
> einfo "${compiler_executable} ${javac_args} ${@}"
> fi
>
> - ebegin "Compiling"
> - ${compiler_executable} ${javac_args} "${@}" || die "ejavac
> failed"
> + local args=( ${compiler_executable} ${javac_args} "${@}" )
> + echo "${args[@]}" >&2
> + "${args[@]}" || die "ejavac failed"
> }
>
> # @FUNCTION: ejavadoc
> @@ -2125,8 +2126,9 @@ ejavadoc() {
> einfo "javadoc ${javadoc_args} ${@}"
> fi
>
> - ebegin "Generating JavaDoc"
> - javadoc ${javadoc_args} "${@}" || die "ejavadoc failed"
> + local args=( javadoc ${javadoc_args} "${@}" )
> + echo "${args[@]}" >&2
> + "${args[@]}" || die "ejavadoc failed"
> }
>
> # @FUNCTION: java-pkg_filter-compiler
Another nice example of "edo" being reinvented. LGTM
[gentoo-dev] Last rites: sys-libs/e2fsprogs-libs
# David Seifert (2022-04-17) # Dead library, part of >=sys-fs/e2fsprogs-1.46.5 now, bug #806875, # removal on 2022-05-17. # (If you hit blockers, please run: # $ emerge --deselect sys-libs/e2fsprogs-libs # This is necessary as your world file should not contain dependencies.) sys-libs/e2fsprogs-libs signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v4 0/1] Add edo.eclass
On Sun, 2022-04-17 at 18:34 +0100, Sam James wrote: > Changes since v3: > - EAPI check cleanup > - Fix long line in eclassdoc > > Changes since v2: > - Fix typo in eclass guard > - Rework description of edob > - Use 'einfo', not 'elog' > - Change die message for clarity > > Changes since v1: > - Add EAPI 7 support (useful for e.g. base-system@ ebuilds) > - Add 'edob' (edo with ebegin/eend for better logs log-running > commands, UX) > > Sam James (1): > edo.eclass: add new eclass > > eclass/edo.eclass | 45 + > 1 file changed, 45 insertions(+) > create mode 100644 eclass/edo.eclass > LGTM, let's get this in
[gentoo-dev] Last rites: media-gfx/nvidia-texture-tools
# David Seifert (2022-05-11) # Declared EOL by upstream at the end of 2020, no revdeps, last version # has many issues. Removal on 2022-06-10. Bug #741846, #770760. media-gfx/nvidia-texture-tools signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] multilib.eclass: Avoid reserved variable names
On Sun, 2022-05-15 at 09:28 +0200, Ulrich Müller wrote:
> Names that begin with __ are reserved for package manager use.
>
> Closes: https://bugs.gentoo.org/843722
> Signed-off-by: Ulrich Müller
> ---
> eclass/multilib.eclass | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index ec2676cb6cfb..8590bbdfbff0 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -422,9 +422,9 @@ multilib_env() {
>
> # the default abi is set to the 1-level libdir
> default
>
> - local
> __libdir_riscvdefaultabi_variable="LIBDIR_${DEFAULT_ABI}"
> - local
> __libdir_riscvdefaultabi=${!__libdir_riscvdefaultabi_variable}
> - export
> ${__libdir_riscvdefaultabi_variable}=${__libdir_riscvdefaultabi:-
> lib64}
> + local
> _libdir_riscvdefaultabi_variable="LIBDIR_${DEFAULT_ABI}"
> + local
> _libdir_riscvdefaultabi=${!_libdir_riscvdefaultabi_variable}
> + export
> ${_libdir_riscvdefaultabi_variable}=${_libdir_riscvdefaultabi:-lib64}
>
> # all other abi are set to the 2-level libdir
> default
>
> @@ -454,9 +454,9 @@ multilib_env() {
>
> # the default abi is set to the 1-level libdir
> default
>
> - local
> __libdir_riscvdefaultabi_variable="LIBDIR_${DEFAULT_ABI}"
> - local
> __libdir_riscvdefaultabi=${!__libdir_riscvdefaultabi_variable}
> - export
> ${__libdir_riscvdefaultabi_variable}=${__libdir_riscvdefaultabi:-lib}
> + local
> _libdir_riscvdefaultabi_variable="LIBDIR_${DEFAULT_ABI}"
> + local
> _libdir_riscvdefaultabi=${!_libdir_riscvdefaultabi_variable}
> + export
> ${_libdir_riscvdefaultabi_variable}=${_libdir_riscvdefaultabi:-lib}
>
> # all other abi are set to the 2-level libdir
> default
>
LGTM
[gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: deprecate tc-has-openmp
Signed-off-by: David Seifert
---
eclass/toolchain-funcs.eclass | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 77fb304940b..9ad5e224b03 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -1,4 +1,4 @@
-# Copyright 2002-2021 Gentoo Authors
+# Copyright 2002-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: toolchain-funcs.eclass
@@ -569,11 +569,12 @@ tc-ld-force-bfd() {
fi
}
-# @FUNCTION: tc-has-openmp
+# @FUNCTION: _tc-has-openmp
+# @INTERNAL
# @USAGE: [toolchain prefix]
# @DESCRIPTION:
# See if the toolchain supports OpenMP.
-tc-has-openmp() {
+_tc-has-openmp() {
local base="${T}/test-tc-openmp"
cat <<-EOF > "${base}.c"
#include
@@ -593,6 +594,16 @@ tc-has-openmp() {
return ${ret}
}
+# @FUNCTION: tc-has-openmp
+# @DEPRECATED: tc-check-openmp
+# @USAGE: [toolchain prefix]
+# @DESCRIPTION:
+# See if the toolchain supports OpenMP. This function is deprecated and will
be
+# removed on 2023-01-01.
+tc-has-openmp() {
+ _tc-has-openmp "$@"
+}
+
# @FUNCTION: tc-check-openmp
# @DESCRIPTION:
# Test for OpenMP support with the current compiler and error out with
@@ -601,7 +612,7 @@ tc-has-openmp() {
# to test for OpenMP support should be preferred over tc-has-openmp and
# printing a custom message, as it presents a uniform interface to the user.
tc-check-openmp() {
- if ! tc-has-openmp; then
+ if ! _tc-has-openmp; then
eerror "Your current compiler does not support OpenMP!"
if tc-is-gcc; then
--
2.35.1
[gentoo-dev] [PATCH 2/2] toolchain-funcs.eclass: document proper tc-check-openmp use
Signed-off-by: David Seifert
---
eclass/toolchain-funcs.eclass | 13 +
1 file changed, 13 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 9ad5e224b03..54d4b0912a6 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -611,6 +611,19 @@ tc-has-openmp() {
# OpenMP support that has been requested by the ebuild. Using this function
# to test for OpenMP support should be preferred over tc-has-openmp and
# printing a custom message, as it presents a uniform interface to the user.
+#
+# You should test for any necessary OpenMP support in pkg_pretend in order to
+# warn the user of required toolchain changes. You must still check for OpenMP
+# support at build-time, e.g.
+# @CODE
+# pkg_pretend() {
+# [[ ${MERGE_TYPE} != binary ]] && use openmp && tc-check-openmp
+# }
+#
+# pkg_setup() {
+# [[ ${MERGE_TYPE} != binary ]] && use openmp && tc-check-openmp
+# }
+# @CODE
tc-check-openmp() {
if ! _tc-has-openmp; then
eerror "Your current compiler does not support OpenMP!"
--
2.35.1
[gentoo-dev] [PATCH] meson.eclass: remove EAPI 6
Signed-off-by: David Seifert
---
eclass/meson.eclass | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 905c4d89f50..7ba6501688b 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -5,7 +5,7 @@
# @MAINTAINER:
# William Hubbs
# Mike Gilbert
-# @SUPPORTED_EAPIS: 6 7 8
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: common ebuild functions for meson-based packages
# @DESCRIPTION:
# This eclass contains the default phase functions for packages which
@@ -35,29 +35,22 @@
# @CODE
case ${EAPI} in
- 6|7|8) ;;
+ 7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
if [[ -z ${_MESON_ECLASS} ]]; then
_MESON_ECLASS=1
-[[ ${EAPI} == 6 ]] && inherit eapi7-ver
inherit multiprocessing ninja-utils python-utils-r1 toolchain-funcs
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
-_MESON_DEPEND=">=dev-util/meson-0.59.4
+BDEPEND=">=dev-util/meson-0.59.4
${NINJA_DEPEND}
dev-util/meson-format-array
"
-if [[ ${EAPI} == 6 ]]; then
- DEPEND=${_MESON_DEPEND}
-else
- BDEPEND=${_MESON_DEPEND}
-fi
-
# @ECLASS_VARIABLE: BUILD_DIR
# @DEFAULT_UNSET
# @DESCRIPTION:
--
2.35.1
[gentoo-dev] Last rites: bunch of py3.9-only packages
# David Seifert (2022-07-02) # Unmaintained, no response on bugs, stuck on python 3.9. If you # want to unmask these, you have to at least port them to python 3.10. # Bugs #809524, #809527, #809530, #809533, #809833, #845729, #845816, # #846017, #846200, #846203, #846206, #853844, removal on 2022-08-01. app-misc/siglo dev-python/gatt-python dev-python/pynput media-libs/elgato-streamdeck media-video/streamdeck-ui net-wireless/jackit net-wireless/kismet-rest net-wireless/kismetdb signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 1/3] perl-module.eclass: remove EAPI 5
Signed-off-by: David Seifert
---
eclass/perl-module.eclass | 209 ++
1 file changed, 56 insertions(+), 153 deletions(-)
diff --git a/eclass/perl-module.eclass b/eclass/perl-module.eclass
index 273cc2bc805..f243be201ce 100644
--- a/eclass/perl-module.eclass
+++ b/eclass/perl-module.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: perl-module.eclass
@@ -7,7 +7,7 @@
# @AUTHOR:
# Seemant Kulleen
# Andreas K. Hüttel
-# @SUPPORTED_EAPIS: 5 6 7 8
+# @SUPPORTED_EAPIS: 6 7 8
# @PROVIDES: perl-functions
# @BLURB: eclass for installing Perl module distributions
# @DESCRIPTION:
@@ -19,11 +19,7 @@
# ExtUtils::MakeMaker or Module::Build), we recommend to use
perl-functions.eclass
# instead.
-case ${EAPI:-0} in
- 5)
- inherit eutils multiprocessing unpacker perl-functions
- PERL_EXPF="src_unpack src_prepare src_configure src_compile
src_test src_install"
- ;;
+case ${EAPI} in
6|7)
inherit multiprocessing perl-functions
PERL_EXPF="src_prepare src_configure src_compile src_test
src_install"
@@ -33,7 +29,7 @@ case ${EAPI:-0} in
PERL_EXPF="src_prepare src_configure src_compile src_test
src_install"
;;
*)
- die "EAPI=${EAPI} is not supported by perl-module.eclass"
+ die "${ECLASS}: EAPI ${EAPI:-0} not supported"
;;
esac
@@ -48,37 +44,7 @@ esac
# a use-conditional build time dependency on virtual/perl-Test-Simple, and
# the required RESTRICT setting.
-case ${EAPI:-0} in
- 5)
- [[ ${CATEGORY} == perl-core ]] && \
- PERL_EXPF+=" pkg_postinst pkg_postrm"
-
- case "${GENTOO_DEPEND_ON_PERL:-yes}" in
- yes)
- case "${GENTOO_DEPEND_ON_PERL_SUBSLOT:-yes}" in
- yes)
- DEPEND="dev-lang/perl:=[-build(-)]"
- ;;
- *)
- DEPEND="dev-lang/perl[-build(-)]"
- ;;
- esac
- RDEPEND="${DEPEND}"
- ;;
- esac
-
- case "${PERL_EXPORT_PHASE_FUNCTIONS:-yes}" in
- yes)
- EXPORT_FUNCTIONS ${PERL_EXPF}
- ;;
- no)
- debug-print "PERL_EXPORT_PHASE_FUNCTIONS=no"
- ;;
- *)
- die
"PERL_EXPORT_PHASE_FUNCTIONS=${PERL_EXPORT_PHASE_FUNCTIONS} is not supported by
perl-module.eclass"
- ;;
- esac
- ;;
+case ${EAPI} in
6)
[[ ${CATEGORY} == perl-core ]] && \
PERL_EXPF+=" pkg_postinst pkg_postrm"
@@ -170,46 +136,43 @@ LICENSE="${LICENSE:-|| ( Artistic GPL-1+ )}"
# @ECLASS_VARIABLE: DIST_NAME
# @DEFAULT_UNSET
# @DESCRIPTION:
-# (EAPI=6 and later) This variable provides a way to override PN for the
calculation of S,
+# This variable provides a way to override PN for the calculation of S,
# SRC_URI, and HOMEPAGE. If unset, defaults to PN.
# @ECLASS_VARIABLE: DIST_VERSION
# @DEFAULT_UNSET
# @DESCRIPTION:
-# (EAPI=6 and later) This variable provides a way to override PV for the
calculation of S and SRC_URI.
+# This variable provides a way to override PV for the calculation of S and
SRC_URI.
# Use it to provide the non-normalized, upstream version number. If unset,
defaults to PV.
-# Named MODULE_VERSION in EAPI=5.
# @ECLASS_VARIABLE: DIST_A_EXT
# @DEFAULT_UNSET
# @DESCRIPTION:
-# (EAPI=6 and later) This variable provides a way to override the distfile
extension for the calculation of
-# SRC_URI. If unset, defaults to tar.gz. Named MODULE_A_EXT in EAPI=5.
+# This variable provides a way to override the distfile extension for the
calculation of
+# SRC_URI. If unset, defaults to tar.gz.
# @ECLASS_VARIABLE: DIST_A
# @DEFAULT_UNSET
# @DESCRIPTION:
-# (EAPI=6 and later) This variable provides a way to override the distfile
name for the calculation of
-# SRC_URI. If unset, defaults to ${DIST_NAME}-${DIST_VERSION}.${DIST_A_EXT}
Named MODULE_A in EAPI=5.
+# This variable provides a way to override the distfile name for the
calculation of
+# SRC_URI. If unset, defaults to ${DIST_NAME}-${DIST_VERSION}.${DIST_A_EXT}.
# @ECLASS_VARIABLE: DIST_AUTHOR
# @DEFAULT_UNSET
# @DESCRIPTION:
-# (EAPI=6 and later) This variable sets the module author name for
[gentoo-dev] [PATCH 2/3] perl-functions.eclass: remove EAPI 5
Signed-off-by: David Seifert
---
eclass/perl-functions.eclass | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/eclass/perl-functions.eclass b/eclass/perl-functions.eclass
index 4adba921485..c1b67f54fa7 100644
--- a/eclass/perl-functions.eclass
+++ b/eclass/perl-functions.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: perl-functions.eclass
@@ -8,7 +8,7 @@
# Seemant Kulleen
# Andreas K. Huettel
# Kent Fredric
-# @SUPPORTED_EAPIS: 5 6 7 8
+# @SUPPORTED_EAPIS: 6 7 8
# @BLURB: helper functions eclass for perl modules
# @DESCRIPTION:
# The perl-functions eclass is designed to allow easier installation of perl
@@ -16,16 +16,16 @@
# It provides helper functions, no phases or variable manipulation in
# global scope.
-[[ ${CATEGORY} == "perl-core" ]] && inherit alternatives
-
-case "${EAPI:-0}" in
- 5|6|7|8)
+case ${EAPI} in
+ 6|7|8)
;;
*)
- die "EAPI=${EAPI} is not supported by perl-functions.eclass"
+ die "${ECLASS}: EAPI ${EAPI:-0} not supported"
;;
esac
+[[ ${CATEGORY} == "perl-core" ]] && inherit alternatives
+
perlinfo_done=false
# @FUNCTION: perl_set_version
@@ -237,9 +237,7 @@ perl_rm_files() {
# only sense for perl-core packages.
perl_link_duallife_scripts() {
debug-print-function $FUNCNAME "$@"
- if [[ ${CATEGORY} != perl-core ]] || ! has_version
">=dev-lang/perl-5.8.8-r8" ; then
- return 0
- fi
+ [[ ${CATEGORY} != perl-core ]] && return 0
local i ff
if has "${EBUILD_PHASE:-none}" "postinst" "postrm" ; then
--
2.35.1
[gentoo-dev] [PATCH 3/3] perl-functions.eclass: [QA] use bash [[ ... ]] brackets
Signed-off-by: David Seifert
---
eclass/perl-functions.eclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/eclass/perl-functions.eclass b/eclass/perl-functions.eclass
index c1b67f54fa7..106394afa15 100644
--- a/eclass/perl-functions.eclass
+++ b/eclass/perl-functions.eclass
@@ -161,7 +161,7 @@ perl_fix_packlist() {
# remove files that dont exist
cat "${f}" | while read -r entry; do
- if [ ! -e "${D}/${entry}" ]; then
+ if [[ ! -e ${D}/${entry} ]]; then
einfo "Pruning surplus packlist entry
${entry}"
grep -v -x -F "${entry}" "${f}" >
"${packlist_temp}"
mv "${packlist_temp}" "${f}"
@@ -276,12 +276,12 @@ perl_check_env() {
for i in PERL_MM_OPT PERL5LIB PERL5OPT PERL_MB_OPT PERL_CORE
PERLPREFIX; do
# Next unless match
- [ -v $i ] || continue;
+ [[ -v $i ]] || continue;
# Warn only once, and warn only when one of the bad values are
set.
# record failure here.
- if [ ${errored:-0} == 0 ]; then
- if [ -n "${I_KNOW_WHAT_I_AM_DOING}" ]; then
+ if [[ ${errored:-0} == 0 ]]; then
+ if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]]; then
elog "perl-module.eclass: Suspicious
environment values found.";
else
eerror "perl-module.eclass: Suspicious
environment values found.";
@@ -293,7 +293,7 @@ perl_check_env() {
value=${!i};
# Print ENV name/value pair
- if [ -n "${I_KNOW_WHAT_I_AM_DOING}" ]; then
+ if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]]; then
elog "$i=\"$value\"";
else
eerror "$i=\"$value\"";
@@ -301,10 +301,10 @@ perl_check_env() {
done
# Return if there were no failures
- [ ${errored:-0} == 0 ] && return;
+ [[ ${errored:-0} == 0 ]] && return;
# Return if user knows what they're doing
- if [ -n "${I_KNOW_WHAT_I_AM_DOING}" ]; then
+ if [[ -n ${I_KNOW_WHAT_I_AM_DOING} ]]; then
elog "Continuing anyway, seems you know what you're doing."
return
fi
--
2.35.1
[gentoo-dev] Up for grabs: dev-db/tora
Up for grabs because of dropped proxied maintainer: - dev-db/tora I've fixed all open bugs, but the package overall hasn't seen a recent release and likely requires more boost build system fixes. The next maintainer should work with upstream on fixing the remaining CMake bugs. David signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-pda/jpilot and app-pda/pilot-link
# David Seifert (2022-07-02) # Unmaintained, broken configure script, upstream disappeared, EAPI 6, # Bugs #744046, #750203, removal on 2022-08-01. app-pda/jpilot app-pda/pilot-link signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] optfeature.eclass: remove EAPI 6
Signed-off-by: David Seifert
---
eclass/optfeature.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/optfeature.eclass b/eclass/optfeature.eclass
index acf8584e6db..b44fc1b8525 100644
--- a/eclass/optfeature.eclass
+++ b/eclass/optfeature.eclass
@@ -1,14 +1,14 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: optfeature.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
-# @SUPPORTED_EAPIS: 6 7 8
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: Advertise optional functionality that might be useful to users
case ${EAPI} in
- 6|7|8) ;;
+ 7|8) ;;
*) die "${ECLASS}: EAPI=${EAPI:-0} is not supported" ;;
esac
--
2.35.1
Re: [gentoo-dev] [PATCH 0/7] Drop support for EAPI 5 in eutils and its friends
On Tue, 2022-06-28 at 19:24 +0200, Ulrich Müller wrote: > Obviously, the series can only be merged when the last EAPI 5 ebuild > is gone. Current status is that we're down to 3 packages with EAPI 5 > which are all last-rited. > > Ulrich Müller (7): > eutils.eclass: Drop support for EAPI 5 > eutils.eclass: Remove use_if_iuse > eutils.eclass: Remove emktemp > autotools.eclass: Drop support for EAPI 5 > flag-o-matic.eclass: Drop support for EAPI 5 > multilib.eclass: Drop support for EAPIs 0 and 5 > toolchain-funcs.eclass: Drop support for EAPIs 0 and 5 > > eclass/autotools.eclass | 14 ++-- > eclass/eutils.eclass | 152 +++-- > - > eclass/flag-o-matic.eclass | 17 ++-- > eclass/multilib.eclass | 33 +--- > eclass/toolchain-funcs.eclass | 7 +- > 5 files changed, 33 insertions(+), 190 deletions(-) > The whole series looks good, let's merge it ASAP.
Re: [gentoo-dev] proposal
On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote: > I'd like to propose a new metadata XML element for packages: > > > > Maintainers can signal to other developers (and of course contributors > in general) that they are happy with others to make changes to the > ebuilds without prior consultation of the maintainer. > > Of course, this is not a free ticket to always make changes to > packages > that you do not maintain without prior consultation of the maintainer. > I > would expect people to use their common sense to decide if a change > may > require maintainer attention or not. In general, it is always a good > idea to communicate changes in every case. > > The absence of the flag does not automatically allow the conclusion > that > the maintainer is opposed to non-maintainer commits. It just means > that > the maintainer's stance is not known. I do not believe that we need a > flag, but if the need arises, we > could always consider adding one. Although, in my experience, people > mostly like to communicate the "non-maintainer commits welcome" policy > with others. > > WDYT? > > - Flow > Ultimately, all these things really matter when only the defaults change. Turn-right-on-red in the US is such a thing, because unless otherwise stated, it's the norm. Knowing our devbase, with roughly 75% mostly AWOL and barely reading the MLs, I don't think this idea will bring about the desired change. Instead, we should really just go for the tag, because my feeling is that the default will be that most maintainers don't mind non-maintainer commits, except a select few territorial ones. David
Re: [gentoo-dev] GLEP-81 migration done
On Sun, 2022-07-10 at 09:26 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 10 Jul 2022, Anna wrote:
>
> > On 2022-07-09 23:37, Conrad Kostecki wrote:
> > > I would like to inform you all, that GLEP-81 migration has been
> > > finally done. All existing packages got migrated and no ones left.
>
> Great work, thank you!
>
> > What to do with user.eclass now? It's already marked @DEPRECATED, do
> > we want it @DEAD and eventually removed?
>
> The eclass dies in EAPI 8 if called from an ebuild outside the acct-*
> category. We could extend this to EAPIs 6 and 7 (but it might cause
> problems for overlays).
>
> Also, not sure if the @DEPRECATED tag should be used for an eclass
> that
> is still indirectly inherited by other eclasses.
>
> How about attached patch?
>
> Ulrich
>
>
> From 49006bdb82f321c359dcf8f0f78893ccdf0e6be7 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ulrich=20M=C3=BCller?=
> Date: Sun, 10 Jul 2022 09:14:19 +0200
> Subject: [PATCH] user.eclass: Warn about eclass usage in all EAPIs
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Remove @DEPRECATED tag because this is not a removal candidate.
>
> Signed-off-by: Ulrich Müller
> ---
> eclass/user.eclass | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/eclass/user.eclass b/eclass/user.eclass
> index d5b827d2e76b..b4f63ffab4a2 100644
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -7,25 +7,27 @@
> # Michał Górny (NetBSD)
> # @SUPPORTED_EAPIS: 6 7 8
> # @BLURB: user management in ebuilds
> -# @DEPRECATED: acct-user/acct-group packages
> # @DESCRIPTION:
> # The user eclass contains a suite of functions that allow ebuilds
> # to quickly make sure users in the installed system are sane.
>
> case ${EAPI} in
> - 6|7) ;;
> - 8)
> - if [[ ${CATEGORY} != acct-* ]]; then
> - eerror "In EAPI ${EAPI}, packages must not
> inherit user.eclass"
> - eerror "unless they are in the acct-user or
> acct-group category."
> - eerror "Migrate your package to GLEP 81
> user/group management,"
> - eerror "or inherit user-info if you need only
> the query functions."
> - die "Invalid \"inherit user\" in EAPI ${EAPI}"
> - fi
> - ;;
> + 6|7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> +if [[ ${CATEGORY} != acct-* ]]; then
> + eerror "Packages must not inherit user.eclass unless they are"
> + eerror "in the acct-user or acct-group category."
> + eerror "Migrate your package to GLEP 81 user/group
> management,"
> + eerror "or inherit user-info if you need only the query
> functions."
> + if [[ ${EAPI} != [67] ]]; then
> + die "Invalid \"inherit user\""
> + else
> + eerror "This message will become fatal in EAPI ${EAPI}
> on 2023-01-01"
> + fi
> +fi
> +
> if [[ -z ${_USER_ECLASS} ]]; then
> _USER_ECLASS=1
>
sounds good
[gentoo-dev] Last rites: games-engines/nazghul
# David Seifert (2022-07-10) # Unmaintained, last release in 2010, ebuild added by author and then # abandoned, terrible macros break compiling with GCC 12. # Bugs #851867, removal on 2022-08-09. games-engines/nazghul signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sci-biology/transfac
# David Seifert (2022-07-11) # Crashes with latest emboss, no other distro packages this, # ancient release, bug #361411, removal on 2022-08-10. sci-biology/transfac signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-libs/ucommon
# David Seifert (2022-07-11) # Unmaintained, companion lib of dev-cpp/commoncpp2 which has already # been removed, fails with USE=-ssl, no revdeps, upstream mostly dead. # Bug #830581, removal on 2022-08-10. dev-libs/ucommon signature.asc Description: This is a digitally signed message part
