[gentoo-dev] Re: RANT: Upgrade icu and KDE at once
Tom Wijsman posted on Thu, 02 May 2013 07:09:10 +0200 as excerpted: Duncan 1i5t5.dun...@cox.net wrote: After some early issues with too much magic re preserved-libs Why is it magic? It is well explained what it does (eg. man make.conf). I originally would rather let the upgrades happen as they always did and simply run revdep-rebuild afterward You know that if you enable preserve-libs that you have to instead run `emerge @preserved-rebuild`, which has a much shorter runtime. and preserved-libs interfered with that as the libs were still there so revdep-rebuild didn't find anything to rebuild. `emerge @preserved-rebuild` will find and rebuild them. To those who say I'm too verbose, this is what happens when I try to shortcut things... I invariably end up spelling it all out anyway in a followup, when someone doesn't understand the shortcut and needs the full explanation... It happens frequently enough that I had learned to avoid it by covering what I could the first time around. Now with some friendly urging, I'm trying to unlearn that, but... Just sayin'... Yes. I understand all about @preserved-libs and was in fact an early feature tester... which is actually likely part of the problem. The problem, which as I said earlier I expect has long since been fixed, was in the magic bit of old libraries being temporarily reassigned as owned by the newer versions that replaced them, even tho they weren't actually part of that version of the package at all, but a previous version. What happened was that the emerge @preserved-libs failed for some reason, leaving some of these stale libs that had been artificially reassigned as owned by the new version, now owned by no one and untracked. But because they were still there, revdep-rebuild wouldn't detect the problem, and because they were now orphaned, I couldn't find them by looking at the files owned by the new versions, so I was a bit stuck. Fortunately in that instance I had only updated a few packages that I had to go manually comparing old binpkg contents with new binpkg contents to track down the orphan libs to delete manually, after which revdep-rebuild worked as it should, but I decided that was too much magic to rely on in the future, when the old remove it and let revdep- rebuild detect and handle the resulting rebuilds was a well proven method that just worked. Magic in this case being defined simply as too much hassle for me to figure out what it did manually and fix things up when it screwed up, when there was a well tested tool that might be a bit slower, but that uses a method known to be /very/ reliable at finding and fixing the sort of library-dependency issues it dealt with. Meanwhile, revdep-rebuild isn't /that/ slow. As I found out by experience, it's MUCH faster than rooting out problems manually when @preserved-libs fails its magic for whatever reason. Actually, most of the wait on revdep-rebuild on conventional/legacy spinning rust systems is due to the I/O latency of actually reading in all the files it scans. Which is quite convenient, since it only needs run after a normally heavily CPU bound world update... such that an I/O bound process conveniently runnable at the same time won't significantly slow down either one! =:^) For those with sufficient memory (@16 gigs I rarely zero-out free memory and dump cache), simply start the emerge update, then in another VT or terminal window, start an initial revdep- rebuild --pretend. By the time the update is done, the revdep-rebuild has generally finished as well, so all the files it scans are in cache. And with a hot cache, revdep-rebuild runs **MUCH** faster the second time around, after the update's done so any needed rebuilds can actually be detected and the rebuild done. =:^) I generally run the emerge --jobs --update..., then run the revdep- rebuild in parallel, since the first is generally CPU bound and the second disk bound. Then when the update is done, I run revdep-rebuild for-real this time, while running etc-update and emerge --ask --depclean (serially) in the other terminal. By the time the etc-update and depclean are done, the (hot-cached) revdep-rebuild is generally done too (thanks to being run routinely so there's never a backlog, and thanks to lddflags as-needed and now subslots as well, taking away most of the work revdep- rebuild used to need to do), so it really didn't take me much more time at all, since otherwise I'd have been waiting first on the update, and then would have been managing the etc-update and waiting on the depclean. Meanwhile, I've finally decided it's time to leave the legacy spinning- rust world behind (for the frequently accessed stuff like the OS, much of /home, and the tree, anyway) and should be upgrading to SSDs soon. With luck, that'll solve much of the current spinning rust latency bottlenecks, leaving me an entirely new set of bottlenecks to learn to to deal
[gentoo-dev] gnome-games.eclass: Eclass for installing all gnome-games
gnome-games was splitted in separate packages per game and, then, we
need an eclass to also set proper settings inherited from gnome2 and
games eclasses. This should also solve:
https://bugs.gentoo.org/show_bug.cgi?id=432848
eclass and ebuild (games-puzzle/five-or-more) to try attached
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/python-single-r1.eclass,v 1.16
2013/04/07 17:02:52 mgorny Exp $
# @ECLASS: gnome-games
# @MAINTAINER:
# Gnome team gn...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass to build gnome-games.
# @DESCRIPTION:
# An eclass to build gnome-games using proper phases from gnome2 and
# games eclasses.
case ${EAPI:-0} in
0|1)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
2|3|4|5)
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
inherit games gnome2
EXPORT_FUNCTIONS pkg_setup src_prepare src_configure src_compile src_install
pkg_preinst pkg_postinst pkg_postrm
if [[ ! ${_GNOME_GAMES} ]]; then
RDEPEND=!gnome-extra/gnome-games
# @FUNCTION: gnome-games_pkg_setup
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_pkg_setup() {
debug-print-function ${FUNCNAME} ${@}
games_pkg_setup
}
# @FUNCTION: gnome-games_src_prepare
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_src_prepare() {
debug-print-function ${FUNCNAME} ${@}
gnome2_src_prepare
}
# @FUNCTION: gnome-games_src_configure
# @DESCRIPTION:
# Set proper phase defaults, relying on gnome2_src_configure
# and passing extra arguments from egamesconf (games.eclass)
gnome-games_src_configure() {
debug-print-function ${FUNCNAME} ${@}
gnome2_src_configure \
--bindir=${GAMES_BINDIR} \
--libdir=$(games_get_libdir) \
--sysconfdir=${GAMES_SYSCONFDIR} \
--localstatedir=${GAMES_STATEDIR} \
$@
# GAMES_DATADIR causes games to fail to run due schemas and other
# files getting installed in unexpected places
# --datadir=${GAMES_DATADIR}
#
# We need to not set GAMES_PREFIX to get translations working
# --localedir=${EPREFIX}/usr/share/locale is not enough
# --prefix=${GAMES_PREFIX} - setting bindir instead
}
# @FUNCTION: gnome-games_src_compile
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_src_compile() {
debug-print-function ${FUNCNAME} ${@}
gnome2_src_compile
}
# @FUNCTION: gnome-games_src_install
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_src_install() {
debug-print-function ${FUNCNAME} ${@}
gnome2_src_install
}
# @FUNCTION: gnome-games_pkg_preinst
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_pkg_preinst() {
debug-print-function ${FUNCNAME} ${@}
gnome2_pkg_preinst
games_pkg_preinst
}
# @FUNCTION: gnome-games_pkg_preinst
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
gnome2_pkg_postinst
games_pkg_postinst
}
# @FUNCTION: gnome-games_pkg_postrm
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_pkg_postrm() {
debug-print-function ${FUNCNAME} ${@}
gnome2_pkg_postrm
}
_GNOME_GAMES=1
fi
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=5
GCONF_DEBUG=no
inherit gnome-games
DESCRIPTION=Five or More Game for GNOME
HOMEPAGE=https://live.gnome.org/Five%20or%20more;
LICENSE=GPL-2+
SLOT=0
KEYWORDS=~amd64
IUSE=
RDEPEND=
dev-libs/glib:2
=gnome-base/librsvg-2.32.0
=x11-libs/gtk+-3.4.0:3
DEPEND=${RDEPEND}
=dev-util/intltool-0.35.0
dev-util/itstool
virtual/pkgconfig
[gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils autotools-multilib
Hi,
I've thought for a bit and got the conclusion that the best solution
for quite an irritating syntax of autotools-multilib is to use
sub-phase functions. To increase consistency between ebuilds, the same
phases can be used in autotools-utils directly.
The idea is that current ebuild looking like:
src_prepare() {
sed ...
autotools-utils_src_prepare
}
src_configure() {
local myeconfargs=(
--with-foo
--with-bar
)
autotools-utils_src_configure
}
src_install() {
use doc local HTML_DOCS=...
autotools-utils_src_install
doinitd ...
dobin ${BUILD_DIR}/something/something
}
could be written as:
autotools_configure() {
local myeconfargs=(
--with-foo
--with-bar
)
edefault
}
autotools_install() {
edefault
dobin something/something
}
autotools_install_all() {
use doc local HTML_DOCS=...
edefault
doinitd ...
}
While this seems rather cosmetic, it becomes incredibly helpful when it
comes to multilib or working inside BUILD_DIR.
The sub-phases without '_all' suffix are run inside BUILD_DIR, and
repeated for each multilib ABI. The sub-phases with '_all' are always
run only once, and inside S.
This provides a meaningful split between the two parts
of autotools-utils_src_install (and default_src_install too), and makes
it possible to hack stuff in multilib without having to rewrite
the 'multilib_foreach_impl' lines all the time.
For example:
src_configure() {
my_configure() {
local myeconfargs=(
... # something ABI-conditional here
)
autotools-utils_src_configure
}
multilib_parallel_foreach_abi my_configure
}
can be replaced with much simpler:
autotools_configure() {
local myeconfargs=(
... # something ABI-conditional here
)
edefault
}
What are your thoughts? The patch is sent in reply to this mail.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] Introduce autotools_* sub-phase functions to make overriding easier.
More details in the mail preceding the patch.
---
gx86/eclass/autotools-multilib.eclass | 47 --
gx86/eclass/autotools-utils.eclass| 157 +-
2 files changed, 158 insertions(+), 46 deletions(-)
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
index 5ca8112..6156610 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -38,27 +38,62 @@ autotools-multilib_src_prepare() {
}
autotools-multilib_src_configure() {
- multilib_parallel_foreach_abi autotools-utils_src_configure ${@}
+ if declare -f autotools_configure /dev/null; then
+ multilib_parallel_foreach_abi \
+ _autotools-utils_run_phase autotools_configure ${@}
+ else
+ multilib_parallel_foreach_abi \
+ _autotools-utils_run_phase \
+ autotools-utils_autotools_configure ${@}
+ fi
}
autotools-multilib_src_compile() {
- multilib_foreach_abi autotools-utils_src_compile ${@}
+ if declare -f autotools_compile /dev/null; then
+ multilib_foreach_abi \
+ _autotools-utils_run_phase autotools_compile ${@}
+ else
+ multilib_foreach_abi \
+ _autotools-utils_run_phase \
+ autotools-utils_autotools_compile ${@}
+ fi
}
autotools-multilib_src_test() {
- multilib_foreach_abi autotools-utils_src_test ${@}
+ if declare -f autotools_test /dev/null; then
+ multilib_foreach_abi \
+ _autotools-utils_run_phase autotools_test ${@}
+ else
+ multilib_foreach_abi \
+ _autotools-utils_run_phase \
+ autotools-utils_autotools_test ${@}
+ fi
}
autotools-multilib_src_install() {
- autotools-multilib_secure_install() {
- autotools-utils_src_install ${@}
+ _autotools-multilib_wrap_install() {
+ ${@}
multilib_prepare_wrappers
# Make sure all headers are the same for each ABI.
multilib_check_headers
}
- multilib_foreach_abi autotools-multilib_secure_install ${@}
+ if declare -f autotools_install /dev/null; then
+ multilib_foreach_abi _autotools-multilib_wrap_install \
+ _autotools-utils_run_phase autotools_install ${@}
+ else
+ multilib_foreach_abi _autotools-multilib_wrap_install \
+ _autotools-utils_run_phase \
+ autotools-utils_autotools_install ${@}
+ fi
+
+ if declare -f autotools_install_all /dev/null; then
+ _autotools-utils_run_phase autotools_install_all ${@}
+ else
+ _autotools-utils_run_phase \
+ autotools-utils_autotools_install_all ${@}
+ fi
# merge the wrappers
multilib_install_wrappers
diff --git a/gx86/eclass/autotools-utils.eclass
b/gx86/eclass/autotools-utils.eclass
index e6bf526..b0a299c 100644
--- a/gx86/eclass/autotools-utils.eclass
+++ b/gx86/eclass/autotools-utils.eclass
@@ -14,8 +14,15 @@
# handling, libtool files removal.
#
# Please note that autotools-utils does not support mixing of its phase
-# functions with regular econf/emake calls. If necessary, please call
-# autotools-utils_src_compile instead of the latter.
+# functions with regular econf/emake calls in src_*. If necessary, please
+# declare autotools_* sub-phases instead which will be run in ${BUILD_DIR}.
+#
+# autotools-utils uses the following sub-phases:
+#
+# - autotools_prepare_all, autotools_install_all -- run in ${S}, once.
+#
+# - autotools_configure, autotools_compile, autotools_test,
+# autotools_install -- run in ${BUILD_DIR}, may be run multiple times.
#
# @EXAMPLE:
# Typical ebuild using autotools-utils.eclass:
@@ -60,26 +67,26 @@
# ${FILESDIR}/${P}-unbundle_libpng.patch
# )
#
-# src_configure() {
+# autotools_configure() {
# local myeconfargs=(
# $(use_enable debug)
# $(use_with qt4)
# $(use_enable threads multithreading)
# $(use_with tiff)
# )
-# autotools-utils_src_configure
+# edefault
# }
#
-# src_compile() {
-# autotools-utils_src_compile
-# use doc autotools-utils_src_compile docs
+# autotools_compile() {
+# edefault
+# use doc emake docs
# }
#
-# src_install() {
-# use doc HTML_DOCS=(${BUILD_DIR}/apidocs/html/)
-# autotools-utils_src_install
+# autotools_install_all() {
+# use doc HTML_DOCS=( apidocs/html/. )
+# edefault
# if use examples; then
-# dobin ${BUILD_DIR}/foo_example{1,2,3} \\
+# dobin foo_example{1,2,3} \\
# || die 'dobin examples failed'
# fi
# }
@@ -228,6 +235,8 @@
Re: [gentoo-dev] gnome-games.eclass: Eclass for installing all gnome-games
On 05/02/2013 12:41 PM, Pacho Ramos wrote: gnome-games was splitted in separate packages per game and, then, we need an eclass to also set proper settings inherited from gnome2 and games eclasses. This should also solve: https://bugs.gentoo.org/show_bug.cgi?id=432848 eclass and ebuild (games-puzzle/five-or-more) to try attached This does not honour GAMES_DATADIR afais. prepgamesdirs is missing completely too. So those games will not be compliant with the games.eclass standard.
Re: [gentoo-dev] gnome-games.eclass: Eclass for installing all gnome-games
El jue, 02-05-2013 a las 14:34 +0200, hasufell escribió: On 05/02/2013 12:41 PM, Pacho Ramos wrote: gnome-games was splitted in separate packages per game and, then, we need an eclass to also set proper settings inherited from gnome2 and games eclasses. This should also solve: https://bugs.gentoo.org/show_bug.cgi?id=432848 eclass and ebuild (games-puzzle/five-or-more) to try attached This does not honour GAMES_DATADIR afais. They cannot honor it since installing all stuff under /usr/share/games will lead to them even failing to start (I tried it before). prepgamesdirs is missing completely too. So those games will not be compliant with the games.eclass standard. In games.eclass I see you have prepgamesdirs but don't call it on any exported phase from games.eclass :-/, how are other games calling it?
Re: [gentoo-dev] gnome-games.eclass: Eclass for installing all gnome-games
On 05/02/2013 03:40 PM, Pacho Ramos wrote: El jue, 02-05-2013 a las 14:34 +0200, hasufell escribió: On 05/02/2013 12:41 PM, Pacho Ramos wrote: gnome-games was splitted in separate packages per game and, then, we need an eclass to also set proper settings inherited from gnome2 and games eclasses. This should also solve: https://bugs.gentoo.org/show_bug.cgi?id=432848 eclass and ebuild (games-puzzle/five-or-more) to try attached This does not honour GAMES_DATADIR afais. They cannot honor it since installing all stuff under /usr/share/games will lead to them even failing to start (I tried it before). Why? It's a common problem that people hardcode data dir destination in their source files, assuming that people only want to install into /usr/share. That is simply a bug and needs to be fixed in the package (it also means it will probably fail for /usr/local and many other usecases, so this is not even a gentoo specific bug). You cannot fix that on eclass level and it is not a reason to drop supporting GAMES_DATADIR variable. That is inconsistent and does not make sense. You would even get mixed permissions unless you fix that up too. prepgamesdirs is missing completely too. So those games will not be compliant with the games.eclass standard. In games.eclass I see you have prepgamesdirs but don't call it on any exported phase from games.eclass :-/, how are other games calling it? You call it explicitly.
Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?
On Wed, 1 May 2013 19:40:06 -0600 Ryan Hill dirtye...@gentoo.org wrote: On Wed, 1 May 2013 08:57:35 +0200 Ulrich Mueller u...@gentoo.org wrote: On Tue, 30 Apr 2013, Ryan Hill wrote: Then the person implementing the code for Paludis is either a monkey or a robot*. Anyone capable of reasoning could puzzle out the implications of not allowing user-given options to override the defaults. Obviously you can write code that follows a spec but is still broken or useless. *or both (?!) Oh please... The person simply made a mistake, which happens when programming, and which he fixed. No reason for calling him names. Sorry, I was under the impression that they were refusing to acknowledge it as a mistake on the grounds that it was allowed by the spec, despite the consequences, and demanding ebuilds to be fixed instead. I have other names for those people I could use but I doubt Er, we are. Following the spec is not a mistake. If there's a mistake, it was made by the Council when they approved the wording. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?
On Thu, May 2, 2013 at 9:55 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Er, we are. Following the spec is not a mistake. If there's a mistake, it was made by the Council when they approved the wording. Both Portage and Paludis are following the spec. The spec isn't incorrect, it just doesn't fully describe the necessary behavior. At worst it is incomplete. Virtually all specs are. The only way you'll ever have a complete spec is if you call your implementation the spec, and then you lose the benefit of having specs in the first place. However, it is a moot point - a proposed improvement has already been made, and the matter of adopting it is before the council. Rich
Re: [gentoo-dev] gnome-games.eclass: Eclass for installing all gnome-games
El jue, 02-05-2013 a las 15:54 +0200, hasufell escribió: On 05/02/2013 03:40 PM, Pacho Ramos wrote: El jue, 02-05-2013 a las 14:34 +0200, hasufell escribió: On 05/02/2013 12:41 PM, Pacho Ramos wrote: gnome-games was splitted in separate packages per game and, then, we need an eclass to also set proper settings inherited from gnome2 and games eclasses. This should also solve: https://bugs.gentoo.org/show_bug.cgi?id=432848 eclass and ebuild (games-puzzle/five-or-more) to try attached This does not honour GAMES_DATADIR afais. They cannot honor it since installing all stuff under /usr/share/games will lead to them even failing to start (I tried it before). Why? It's a common problem that people hardcode data dir destination in their source files, assuming that people only want to install into /usr/share. That is simply a bug and needs to be fixed in the package (it also means it will probably fail for /usr/local and many other usecases, so this is not even a gentoo specific bug). You cannot fix that on eclass level and it is not a reason to drop supporting GAMES_DATADIR variable. That is inconsistent and does not make sense. You would even get mixed permissions unless you fix that up too. I don't understand why games team makes all this prefix work, isn't changing permissions of installed files enough? I doubt if upstream will be ok with installing schemas/translations/gtk-doc stuff under this prefix :/ prepgamesdirs is missing completely too. So those games will not be compliant with the games.eclass standard. In games.eclass I see you have prepgamesdirs but don't call it on any exported phase from games.eclass :-/, how are other games calling it? You call it explicitly. In src_install, no?
Re: [gentoo-dev] gnome-games.eclass: Eclass for installing all gnome-games
On 05/02/2013 05:12 PM, Pacho Ramos wrote: El jue, 02-05-2013 a las 15:54 +0200, hasufell escribió: On 05/02/2013 03:40 PM, Pacho Ramos wrote: El jue, 02-05-2013 a las 14:34 +0200, hasufell escribió: On 05/02/2013 12:41 PM, Pacho Ramos wrote: gnome-games was splitted in separate packages per game and, then, we need an eclass to also set proper settings inherited from gnome2 and games eclasses. This should also solve: https://bugs.gentoo.org/show_bug.cgi?id=432848 eclass and ebuild (games-puzzle/five-or-more) to try attached This does not honour GAMES_DATADIR afais. They cannot honor it since installing all stuff under /usr/share/games will lead to them even failing to start (I tried it before). Why? It's a common problem that people hardcode data dir destination in their source files, assuming that people only want to install into /usr/share. That is simply a bug and needs to be fixed in the package (it also means it will probably fail for /usr/local and many other usecases, so this is not even a gentoo specific bug). You cannot fix that on eclass level and it is not a reason to drop supporting GAMES_DATADIR variable. That is inconsistent and does not make sense. You would even get mixed permissions unless you fix that up too. I don't understand why games team makes all this prefix work, isn't changing permissions of installed files enough? I doubt if upstream will be ok with installing schemas/translations/gtk-doc stuff under this prefix :/ schemas/translations/gtk-doc don't need to be installed under that prefix. Sometimes you have to seperate install locations, otherwise you would end up getting pixmaps in /usr/share/games/pixmaps and such. That sometimes needs some micro-management. Datafiles should _always_ have a seperate switch to choose the destination. prepgamesdirs is missing completely too. So those games will not be compliant with the games.eclass standard. In games.eclass I see you have prepgamesdirs but don't call it on any exported phase from games.eclass :-/, how are other games calling it? You call it explicitly. In src_install, no? Yes
Re: [gentoo-dev] gnome-games.eclass: Eclass for installing all gnome-games
El jue, 02-05-2013 a las 17:16 +0200, hasufell escribió:
On 05/02/2013 05:12 PM, Pacho Ramos wrote:
El jue, 02-05-2013 a las 15:54 +0200, hasufell escribió:
On 05/02/2013 03:40 PM, Pacho Ramos wrote:
El jue, 02-05-2013 a las 14:34 +0200, hasufell escribió:
On 05/02/2013 12:41 PM, Pacho Ramos wrote:
gnome-games was splitted in separate packages per game and, then, we
need an eclass to also set proper settings inherited from gnome2 and
games eclasses. This should also solve:
https://bugs.gentoo.org/show_bug.cgi?id=432848
eclass and ebuild (games-puzzle/five-or-more) to try attached
This does not honour GAMES_DATADIR afais.
They cannot honor it since installing all stuff under /usr/share/games
will lead to them even failing to start (I tried it before).
Why?
It's a common problem that people hardcode data dir destination in their
source files, assuming that people only want to install into /usr/share.
That is simply a bug and needs to be fixed in the package (it also means
it will probably fail for /usr/local and many other usecases, so this is
not even a gentoo specific bug).
You cannot fix that on eclass level and it is not a reason to drop
supporting GAMES_DATADIR variable. That is inconsistent and does not
make sense. You would even get mixed permissions unless you fix that up
too.
I don't understand why games team makes all this prefix work, isn't
changing permissions of installed files enough?
I doubt if upstream will be ok with installing
schemas/translations/gtk-doc stuff under this prefix :/
schemas/translations/gtk-doc don't need to be installed under that
prefix. Sometimes you have to seperate install locations, otherwise you
would end up getting pixmaps in /usr/share/games/pixmaps and such.
That sometimes needs some micro-management. Datafiles should _always_
have a seperate switch to choose the destination.
This is another attempt, some pending problems are:
- localedir is wrongly chosen
- it installs /var stuff under /var/games/games instead of /var/games :S
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/python-single-r1.eclass,v 1.16
2013/04/07 17:02:52 mgorny Exp $
# @ECLASS: gnome-games
# @MAINTAINER:
# Gnome team gn...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass to build gnome-games.
# @DESCRIPTION:
# An eclass to build gnome-games using proper phases from gnome2 and
# games eclasses.
case ${EAPI:-0} in
0|1)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
2|3|4|5)
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
inherit games gnome2
EXPORT_FUNCTIONS pkg_setup src_prepare src_configure src_compile src_install
pkg_preinst pkg_postinst pkg_postrm
if [[ ! ${_GNOME_GAMES} ]]; then
RDEPEND=!gnome-extra/gnome-games
# @FUNCTION: gnome-games_pkg_setup
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_pkg_setup() {
debug-print-function ${FUNCNAME} ${@}
games_pkg_setup
}
# @FUNCTION: gnome-games_src_prepare
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_src_prepare() {
debug-print-function ${FUNCNAME} ${@}
gnome2_src_prepare
}
# @FUNCTION: gnome-games_src_configure
# @DESCRIPTION:
# Set proper phase defaults, relying on gnome2_src_configure
# and passing extra arguments from egamesconf (games.eclass)
gnome-games_src_configure() {
debug-print-function ${FUNCNAME} ${@}
gnome2_src_configure \
--bindir=${GAMES_BINDIR} \
--libdir=$(games_get_libdir) \
--sysconfdir=${GAMES_SYSCONFDIR} \
--localstatedir=${GAMES_STATEDIR} \
--prefix=${GAMES_PREFIX} \
--localedir=/usr/share/locale \
$@
# GAMES_DATADIR causes games to fail to run due schemas and other
# files getting installed in unexpected places
# --datadir=${GAMES_DATADIR}
#
# We need to not set GAMES_PREFIX to get translations working
# --localedir=${EPREFIX}/usr/share/locale is not enough
# --prefix=${GAMES_PREFIX} - setting bindir instead
}
# @FUNCTION: gnome-games_src_compile
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_src_compile() {
debug-print-function ${FUNCNAME} ${@}
gnome2_src_compile
}
# @FUNCTION: gnome-games_src_install
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_src_install() {
debug-print-function ${FUNCNAME} ${@}
gnome2_src_install
prepgamesdirs
}
# @FUNCTION: gnome-games_pkg_preinst
# @DESCRIPTION:
# Set proper phase defaults
gnome-games_pkg_preinst() {
debug-print-function ${FUNCNAME} ${@}
gnome2_pkg_preinst
games_pkg_preinst
}
# @FUNCTION: gnome-games_pkg_preinst
# @DESCRIPTION:
# Set proper phase defaults
[gentoo-dev] [PATCH] multilib-minimal.eclass: allow relative paths to $S for DOCS variable wrt #468092
currently default_src_install is carried out in $BUILD_DIR and not in $S
that means people have to do something like this:
DOCS=( ${S}/ChangeLog{,.libffi,.libgcj,.v1} ${S}/README )
The attached patch is a bit ugly, but I don't see a better way. It will
allow:
DOCS=( ChangeLog{,.libffi,.libgcj,.v1} README )
--- eclass/multilib-minimal.eclass
+++ eclass/multilib-minimal.eclass
@@ -84,7 +84,7 @@
if declare -f multilib_src_install /dev/null ; then
multilib_src_install
else
- default_src_install
+ DOCS= default_src_install
fi
multilib_prepare_wrappers
multilib_check_headers
@@ -96,4 +96,18 @@
if declare -f multilib_src_install_all /dev/null ; then
multilib_src_install_all
fi
+
+ # install docs from ${S} as basedir, see #468092
+ # this is synced with __eapi4_src_install
+ if ! declare -p DOCS /dev/null ; then
+ local d
+ for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
+THANKS BUGS FAQ CREDITS CHANGELOG ; do
+ [[ -s ${d} ]] dodoc ${d}
+ done
+ elif [[ $(declare -p DOCS) == declare -a * ]] ; then
+ dodoc ${DOCS[@]}
+ else
+ dodoc ${DOCS}
+ fi
}
Re: [gentoo-dev] [PATCH] multilib-minimal.eclass: allow relative paths to $S for DOCS variable wrt #468092
On Thu, 02 May 2013 18:24:19 +0200
hasufell hasuf...@gentoo.org wrote:
currently default_src_install is carried out in $BUILD_DIR and not in $S
that means people have to do something like this:
DOCS=( ${S}/ChangeLog{,.libffi,.libgcj,.v1} ${S}/README )
The attached patch is a bit ugly, but I don't see a better way. It will
allow:
DOCS=( ChangeLog{,.libffi,.libgcj,.v1} README )
Erm, now you're hacking default_src_install in one place, and inlining
it in the other. Please keep it consistent and either inline it in both
places, or hack in both places.
Also, HTML_DOCS suffer the same issue.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] multilib-minimal.eclass: allow relative paths to $S for DOCS variable wrt #468092
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2013 06:31 PM, Michał Górny wrote:
On Thu, 02 May 2013 18:24:19 +0200 hasufell hasuf...@gentoo.org
wrote:
currently default_src_install is carried out in $BUILD_DIR and
not in $S
that means people have to do something like this: DOCS=(
${S}/ChangeLog{,.libffi,.libgcj,.v1} ${S}/README )
The attached patch is a bit ugly, but I don't see a better way.
It will allow: DOCS=( ChangeLog{,.libffi,.libgcj,.v1} README )
Erm, now you're hacking default_src_install in one place, and
inlining it in the other. Please keep it consistent and either
inline it in both places, or hack in both places.
why?
Also, HTML_DOCS suffer the same issue.
not a PMS function afais
what I don't know for sure is: do all PMs accept empty string as
argument for dodoc without failing?
Otherwise I could just use a second variable and unset DOCS.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRgpmsAAoJEFpvPKfnPDWz5V4IAIe3lOIYMFU4j9i3qJ/roR/G
Z9qZFNDDHBzGhq8ycQ7rswrIE54FhTJ56Y/9l1ng4eutvRly4DCCBd9wT3FISPCq
3W3ltA/l78vd+iFsFHrUqnyUBCpi9gVEp59uvZrWzjRquVsnUuYv72wpVl2k4+2z
PV4iP6SbUBQJzMlQSsixAnMbJKtPstMFRAG83bLhy4IrvNBC9bRaFqO09De07IX+
VFcKoSJMy+NrVblrm9E9HjaxA48z0Od0EcLHvODAPscv9+auSsF9boWZyjCY2iZ0
lKhthUv7ymZExpYE7tBtq13ykw1g7irID8UxVZdg53FOihO8TjIB0kxkAFDjK7I=
=jBrb
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] multilib-minimal.eclass: allow relative paths to $S for DOCS variable wrt #468092
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Otherwise I could just use a second variable and unset DOCS. Hm no, that would suck too, cause it will jump into the the first if clause. I'll probably inline it all then. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRgprMAAoJEFpvPKfnPDWzquEIAJawL43muyuL2M8HWrNBNmIS /ZbmcMes1ZeOw9D05saznZWNNVkUm4IxPv2xYMUsUjqiIm29gi41cMWn+Oxk1IiJ E75/RnaYcHVxh9zV1m05N7a9Q74xkbYE7aAB/CDikL2QP76RKtC5cGjyYlV6Ewg4 1brgmMGcayVNvQM/7JyjU0lOEf8jGBnoAMZ4iBJUxV3Kn8sZrYPK28mUdMfQ568T lK51XGYS9UIsJkPYgYQhxfI+b0E1fgaNgw+dm16kYUSYCjO5rTCe3Oypa/T/oWt0 +VPug+pfjOJVCHcjK3TwueS4FFGx7xxGTUsatMMqbsCQGDkjv1SF2xxKxMgcKP8= =woGL -END PGP SIGNATURE-
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote: - its a consistent approach that is bootloader agnostic - it doesn't require you to understand your bootloaders scripting system to add it to the init= line - its no brains required, and hard to mess up Why should we do something boot loader agnostic for the init system when editing config files is something that all gentoo users/sysadmins are expected to understand? bootloader configuration under grub1 for instance, was quite straight-forward. Now with grub-2, its quite convoluted, for me at least. I haven't looked at grub2 yet, but I can't imagine it being convoluted based on the documentation I have read. Its also sometimes a bit confusing if you need something other than /sbin/init as your init, because sometimes you need some pre-init stuff ( like genkernel does ), and you need some /other/ parameter other than init= so that the pre-init still runs and then passes over to init Now you are talking about an initramfs, and no symlink is going to take care of that. You also still have to keep your boot loader configuration up to date whenyou upgrade your kernel. Having a symlink that will just do the right thing is helpful for these cases. I don't see how the symlink is going to help anything since it doesn't preclude you editing your boot loader configuration. Against, the symlink may introduce parts that are breakable, like if user messes up and places the destination of the symlink on a different partition ( shouldn't be a problem, but might be ), or if you're doing an initird that has init baked into it, you'd have to regenerate that initrd after changing the symlink ( I think, maybe not, its probably not even a problem, its just something I'd have to check ) And also, if for whatever reason systemd becomes unbootable it might be slightly hard to boot with the right init if you can't change kernel parameters during boot time. But noted, those last 2 against reasons are edge cases, where the arguments for it are majority cases, so collectively I'm still in favour of the eselect + symlinks approach. If this does ever hit the tree, I think it should be defaulted to off and users should be able to turn it on if they want. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 2:05 PM, William Hubbs willi...@gentoo.org wrote: On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote: bootloader configuration under grub1 for instance, was quite straight-forward. Now with grub-2, its quite convoluted, for me at least. I haven't looked at grub2 yet, but I can't imagine it being convoluted based on the documentation I have read. If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. If you use grub-mkconfig to generate a configuration file, you can append the init option by setting GRUB_CMDLINE_LINUX=init=/usr/lib/systemd/systemd in /etc/default/grub. Either way, it's pretty simple.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert flop...@gentoo.org wrote: If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. If you use grub-mkconfig to generate a configuration file, you can append the init option by setting GRUB_CMDLINE_LINUX=init=/usr/lib/systemd/systemd in /etc/default/grub. Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. Either way, it's pretty simple. If it's that simple, why on earth do we have all the eselect modules we have!? Extra modules: audicle Manage /usr/bin/audicle audio engine bashcomp Manage contributed bash-completion scripts binutils Manage installed versions of sys-devel/binutils blas Manage installed BLAS implementations bzimage Switch bzImage default kernel by updating /boot/bzImage symlink cblas Manage installed CBLAS implementations cdparanoiaManage /usr/bin/cdparanoia implementation chuck Manage /usr/bin/chuck audio engine ctags Manage /usr/bin/ctags implementations ecj Manage ECJ targets editorManage the EDITOR environment variable emacs Manage /usr/bin/emacs version env Manage environment variables set in /etc/env.d/ esd Select esound daemon or wrapper etags Manage /usr/bin/etags implementations fontconfigManage fontconfig /etc/fonts/conf.d/ symlinks gnat Manage the installed gnat compilers gnome-shell-extensionsManage default settings for systemwide GNOME Shell extensions infinalityManage the /etc/fonts/infinality/conf.d symlink java-nsplugin Manage the Java plugin for Netscape-like Browsers java-vm Manage the Java system and user VM kernelManage the /usr/src/linux symlink lapackManage installed LAPACK implementations lcdfilter Manage the /etc/env.d/99lcdfilter symlink lightdm Switch between LightDM greeters localeManage the LANG environment variable maven Manage Maven targets mesa Manage the OpenGL driver architecture used by media-libs/mesa miniaudicle Manage /usr/bin/miniAudicle audio engine modules Query eselect modules mpg123Manage /usr/bin/mpg123 implementation mpost Manage /usr/bin/mpost implementations news Read Gentoo (GLEP 42) news items notify-send Manage /usr/bin/notify-send implementation nxserver Manages the configuration of NX servers oodictManage the configuration of dictionaries for OpenOffice.Org. openclManage the OpenCL implementation used by your system openglManage the OpenGL implementation used by your system package-manager Manage the PACKAGE_MANAGER environment variable pager Manage the PAGER environment variable pdftexManage /usr/bin/pdftex implementations php Manage php installations pinentry Manage /usr/bin/pinentry implementation postgresqlManage active PostgreSQL client applications and libraries profile Manage the make.profile symlink pythonManage Python symlinks qtgraphicssystem Manage the system-wide active Qt Graphics System rails Manage Ruby on Rails versions rcManage /etc/init.d scripts in runlevels ruby Manage Ruby symlinks settingsd Switch between settingsd implementations shManage /bin/sh (POSIX shell) implementations sndpeek Manage /usr/bin/sndpeek audio engine sysvinit Switch between sysvinit implementations timidity Select default system patchset for TiMidity++ unisonManage /usr/bin/unison versions vdr-pluginManage VDR plugins viManage /usr/bin/vi implementations visualManage the VISUAL environment variable wxwidgets Manage the system default wxWidgets profile. xvmc Manage the XvMC implementation used by your system Why aren't we telling people to just edit config files!? -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
Fabio Erculiani schrieb: Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. Another bootloader agnostic way is to pass init=.. via CONFIG_CMDLINE. Not carrying more deviations from upstream than necessary is a worthwhile goal for any sane distro. Especially when it has not even been attempted to get this change merged upstream. Either way, it's pretty simple. If it's that simple, why on earth do we have all the eselect modules we have!? [...] Why aren't we telling people to just edit config files!? I don't see your point? Besides eselect modules which manage symlinks when users could instead edit configuration files, there exist eselect modules which modify config files for the user, or those where symlinks are managed without an equivalent editing of configuration files, or where symlinks are managed in an upstream approved way. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani lx...@gentoo.org wrote: Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. Well, there is no reason that an eselect module couldn't edit the boot configuration, but not with the current way that everybody generates them manually anyway. Keep in mind that any Gentoo user who can't edit a boot loader configuration is limited to booting from LiveCDs. The bootloader is installed and configured manually in Gentoo, following the handbook. Running openrc and systemd in parallel under grub legacy (the config anybody without more exotic requirements and knowledge uses) is just a matter of duplicating a few lines of the config file, renaming the menu item name, and setting init= on one of them. Now you can boot into either from the boot menu. As I mentioned before on this list I'm all for having some packages that actually install a working default kernel, initramfs, boot config, etc. They might even be part of a profile, so that if a user eselects that profile at install-time and does an emerge -uDN world they can then just type reboot when it finishes and get a working system. However, none of that exists now. If it did exist, then manipulating those standardized files via eselect would be quite possible as well (most likely the boot config would be built from some kind of conf.d directory with a script that updates it when needed, and eselect and other packages coudl dump stuff in that conf.d directory as needed just as we do with env.d and so on). I should probably take a few minutes to learn how all this was implemented in Sabayon as it is likely a solved problem. Of course, the handbook would just list this as another option and gentoo-sources and such would never go away. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani lx...@gentoo.org wrote: On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert flop...@gentoo.org wrote: If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. If you use grub-mkconfig to generate a configuration file, you can append the init option by setting GRUB_CMDLINE_LINUX=init=/usr/lib/systemd/systemd in /etc/default/grub. Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. I was just providing some technical insight as the maintainer of that package; I didn't mean to set off another tangent, but oh well. Editing a configuration file does not require some great level of skill. I think you give our users too little credit. Give them good/simple documentation, and they can run with it. I am not strongly opposed your eselect module for init; I just think it is unnecessary. Adjusting a bootloader config is not the mystical impossibility that you seem to make it out to be. If it were, we would have automated it along with kernel building and initramfs generation. Either way, it's pretty simple. If it's that simple, why on earth do we have all the eselect modules we have!? Why aren't we telling people to just edit config files!? I guess people like writing eselect modules for no good reason? ;-) Note that many of them do more than simply edit a configuration file. Many do quite a bit of symlink manipulation, which is a good application of eselect IMO.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 02, 2013 at 03:39:25PM -0400, Mike Gilbert wrote: On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani lx...@gentoo.org wrote: On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert flop...@gentoo.org wrote: If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. If you use grub-mkconfig to generate a configuration file, you can append the init option by setting GRUB_CMDLINE_LINUX=init=/usr/lib/systemd/systemd in /etc/default/grub. Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. I was just providing some technical insight as the maintainer of that package; I didn't mean to set off another tangent, but oh well. Editing a configuration file does not require some great level of skill. I think you give our users too little credit. Give them good/simple documentation, and they can run with it. Agreed. All of our users who have installed Gentoo by following the handbook know how to edit configuration files since there are several they are required to edit as part of the installation process. You have to do some work to maintain a Gentoo system. We are not and do not claim to be a distro where everything just works out of the box. I am not strongly opposed your eselect module for init; I just think it is unnecessary. Adjusting a bootloader config is not the mystical impossibility that you seem to make it out to be. If it were, we would have automated it along with kernel building and initramfs generation. Right. I think it is completely unnecessary given what we consider the basic knowledge level of our users. It causes more work for the developers with no gain for users. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On 3 May 2013 07:01, Fabio Erculiani lx...@gentoo.org wrote: If it's that simple, why on earth do we have all the eselect modules we have!? Hm, upon reading that list and seeing what they do, it raises another argument in favour of eselect: If there needs to be more things changed prior to reboot than simply changing which init is invoked, having an eselect module gives a good place to put relevant related changes to make it work. It also gives a good place to do sanity checks on your system so it knows that the change of init invocation will actually work on your machine. -- Kent
[gentoo-dev] Re: Making systemd more accessible to normal users
Mike Gilbert posted on Thu, 02 May 2013 14:13:30 -0400 as excerpted: On Thu, May 2, 2013 at 2:05 PM, William Hubbs willi...@gentoo.org wrote: On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote: bootloader configuration under grub1 for instance, was quite straight-forward. Now with grub-2, its quite convoluted, for me at least. I haven't looked at grub2 yet, but I can't imagine it being convoluted based on the documentation I have read. If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. FWIW, this is the key to getting along with grub2. Its automated configuration might arguably make simple things simple, but it makes the (somewhat) complex /horribly/ complex and /terribly/ convoluted, to the point it's nearly impossible. So for those doing anything beyond the basics, just dumping the automated config is from my experience the easiest way to go. FWIW, here I even install-masked the automated config install app (grub2-mkconfig IIRC) along with some of the then useless boilerplate config it installs for it, so there's /no/ /possibility/ of it getting run accidentally, overwriting my custom manual config. FWIW, reminds me a lot of iptables, where there's all these tools that promise to simplify things, but I found I was only more mixed up, until I took the time to learn iptables itself, and write in its language myself, thus eliminating all the convoluted middleware that attempted to simplify the simple but ended up horribly convoluting anything beyond the already simple. The automated grub2 stuff is IMO similar middleware that only makes anything beyond the basics harder than it should be, without simplifying the simple (at least to a gentooer) much at all. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Making systemd more accessible to normal users
On Fri, May 03, 2013 at 08:27:36AM +1200, Kent Fredric wrote: On 3 May 2013 07:01, Fabio Erculiani lx...@gentoo.org wrote: If it's that simple, why on earth do we have all the eselect modules we have!? Hm, upon reading that list and seeing what they do, it raises another argument in favour of eselect: If there needs to be more things changed prior to reboot than simply changing which init is invoked, having an eselect module gives a good place to put relevant related changes to make it work. There are no other changes in this case though; that's the point of this discussion. You just emerge systemd and switch init= to the appropriate path in your boot loader configuration, , or better yet, add a separate entry to your boot loader configuration that boots you up with systemd so that you can recover if things do not work. If you use this symlink approach to actually switch your init to point to systemd, then you boot and things don't work, you are hosed. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
William Hubbs schrieb: If you use this symlink approach to actually switch your init to point to systemd, then you boot and things don't work, you are hosed. Well, not fully hosed. You could still edit your kernel command line from the boot loader pointing init=.. to the actual location and not the symlink (or have a backup entry ready, but then any gains from switching symlinks are negated). Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Packages using -Werror
Most of the bugs filed on the gcc 4.8 tracker so far have been caused by packages being built with -Werror. I just noticed one package where the Makefile was being patched to remove -g from CXXFLAGS but -Werror on the same line was left in. Just in case people weren't aware, building with -Werror is a bad idea and against policy*. If you're fixing one of these bugs by silencing the warning be sure to remove the flag also. Thanks! https://bugs.gentoo.org/show_bug.cgi?id=werror http://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror * said policy might not actually exist in writing outside of the mailing list. still a bad idea though. -- gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Packages using -Werror
Ryan Hill wrote: If you're fixing one of these bugs by silencing the warning be sure to remove the flag also. How about sending the fix upstream instead? Thanks, from an upstream //Peter pgpHGm3ZpE6z3.pgp Description: PGP signature
