Re: [gentoo-dev] Re: RFC: c++14 global USE flag
On Tue, Apr 28, 2015 at 4:07 PM, Anthony G. Basile wrote: > On 04/26/15 23:21, Duncan wrote: >> >> Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted: >> >>> On 25 April 2015 at 16:57, Duncan <1i5t5.dun...@cox.net> wrote: >>> Of course, one thing that could make the process faster would be if C++ based packages were marked some way. >>> >>> >>> revdep-rebuild --soname 'libstdc\+\+.so.*' >>> >>> should do the trick. Stuff that does not link the library (statically >>> linked or using libsupc++) should not really matter. >> >> Thanks. Obvious in hindsight. =:^) >> > > just saw this. This works unless you have two versions of gcc installed. > The c++11 abi emitted by gcc-4.7 and 4.8 are different and since you link > against the latest version (see the ordering of directories in > /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf), building with the earlier > gcc can cause breakage. We may not want to support such a situation but I'd > like to. As I understand it, a given version of gcc links objects against its own version of libstdc++, but the "latest" version of libstdc++ is loaded by ld.so at runtime. Maybe that's what you meant, but I wanted to clarify that. And if I am wrong on that, please correct me. ^_^
Re: [gentoo-dev] Re: Importance of SLOTs on Java dependencies
On Sun, 19 Apr 2015 03:38:09 -0600
Ryan Hill wrote:
> On Wed, 8 Apr 2015 16:25:20 +0100
> James Le Cuirot wrote:
>
> > On Wed, 8 Apr 2015 17:10:30 +0200
> > Patrice Clement wrote:
> >
> > > Tuesday 07 Apr 2015 20:41:05, Pacho Ramos wrote :
> > > > Wouldn't be possible to show a repoman warning when a
> > > > dependency on any dev-java/${PN} doesn't specify a SLOT? That
> > > > would save of from forgetting this in some years ;)
> > > >
> > > Chewi suggested a similar solution in #gentoo-java. How do we get
> > > started with contributing to repoman?
> >
> > The change I intend to make is not to repoman but
> > java-utils-2.eclass where there is already a check to ensure that a
> > dependency has been added, it just doesn't check the SLOT at the
> > moment. It outputs an error message by default but dies if you have
> > JAVA_PKG_STRICT set, which all Java devs should do.
>
> I just got this warning and had to do some digging to figure out
> where it came from and what it wanted me to do. Can you add a comment
> to the eclass (maybe a link to your mail which explained things well)
> and a pointer to the eclass in the message?
Done! :)
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpEL2DHuf_JF.pgp
Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-tex/mh
# Ulrich Müller (28 Apr 2015) # Superseded by the newer "breqn" and "mathtools" # modules in dev-texlive/texlive-latexrecommended. # mh is no longer maintained upstream. Bug 524114. # Masked for removal in 30 days. dev-tex/mh pgpqLx2CHD8_j.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
On 04/26/15 23:21, Duncan wrote: Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted: On 25 April 2015 at 16:57, Duncan <1i5t5.dun...@cox.net> wrote: Of course, one thing that could make the process faster would be if C++ based packages were marked some way. revdep-rebuild --soname 'libstdc\+\+.so.*' should do the trick. Stuff that does not link the library (statically linked or using libsupc++) should not really matter. Thanks. Obvious in hindsight. =:^) just saw this. This works unless you have two versions of gcc installed. The c++11 abi emitted by gcc-4.7 and 4.8 are different and since you link against the latest version (see the ordering of directories in /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf), building with the earlier gcc can cause breakage. We may not want to support such a situation but I'd like to. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Re: RFC: c++14 global USE flag
Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted: > On 25 April 2015 at 16:57, Duncan <1i5t5.dun...@cox.net> wrote: > >> Of course, one thing that could make the process faster would be if C++ >> based packages were marked some way. > > > revdep-rebuild --soname 'libstdc\+\+.so.*' > > should do the trick. Stuff that does not link the library (statically > linked or using libsupc++) should not really matter. Thanks. Obvious in hindsight. =:^) Answering my own toolchain question then, for folks using portage as PM... [wow, portage takes /awhile/ evaluating order!]... Looks like dev-libs/gmp could be a problem. Back in the day we didn't have it to worry about, but coreutils uses it with USE=gmp, which I'd guess quite a few folks would have set for multi-processing support. But gmp appears to have a C and a C++ lib (libgmpxx.so.*), and coreutils wasn't in the above list on its own, so it would appear to be fine even if libgmpxx.so.* is broken, so... But obviously worth testing before each new gcc compatibility bump gets unmasked... Other than gmp, it looks like the old rules still apply just fine. Upgrade gcc, gcc-config switch to the new version, and emerge --emptytree @world, or at least revdep-rebuild --soname 'libstdc\+\+.so.*' as Diego points out. And as I already said, with modern hardware that takes... a morning... well, maybe a day if you've lots of packages installed or are on a slow (if modern) machine, not the two days plus it used to take when that was simply accepted as the way it was. So shouldn't be a big deal. Other than the usual upgrade bugs, then, the problem should be pretty well restricted to servantware which can't be rebuilt; more specifically, to C++ using servantware that can't be rebuilt. And that has always been a problem, which the people choosing to use it have chosen to live with, but which shouldn't hold back the free world that has chosen not to live in such bondage. For these people, what? Of course they used to get along when gcc's C++ was unstable before, so I guess they still can. Does libstdc++ get builtin as static? If so it shouldn't be an issue. If not... I guess they can preload libstdc++ from an older gcc. So maybe a news item explaining both the gcc upgrade procedure, and how to preload an old libstdc++, if they need to for binary-only servantware or whatever. -- 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
[gentoo-dev] New ruby-single eclass
Hi,
The current ruby eclasses work fairly well for ruby-only packages, but
support for packages where ruby is only part of the package are not well
served. As a start the ruby team proposes the following new eclass,
ruby-single.eclass. The purpose of this eclass is to provide support for
the case where a working ruby version needs to be accessed
via /usr/bin/ruby. Examples of such packages are net-libs/webkit-gtk and
sys-block/thin-provisioning-tools.
The eclass is loosely modeled after the python-single eclass-r1,
although not all the functionality available there can be or has been
provided for ruby at the moment. We've tried to keep variable and method
names compatible, though.
Also contained in this email is a new ruby-utils eclass which contains
code factored out of the current ruby-ng eclass, so that it can used by
both eclasses. ruby-utils.eclass is not meant to be used in ebuilds.
Full example code including an ebuild (app-admin/pwstore) is available
in the "ruby" repository.
Thanks,
Hans
# Copyright 1999-2014 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.26
2014/05/26 16:13:35 mgorny Exp $
# @ECLASS: ruby-single
# @MAINTAINER:
# Ruby team
# @AUTHOR:
# Author: Hans de Graaff
# Based on python-single-r1 by: Michał Górny
# @BLURB: An eclass for Ruby packages not installed for multiple
implementations.
# @DESCRIPTION:
# An eclass for packages which don't support being installed for
# multiple Ruby implementations. This mostly includes ruby-based
# scripts.
case "${EAPI:-0}" in
0|1|2|3)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
4|5)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac
inherit ruby-utils
# @ECLASS-VARIABLE: USE_RUBY
# @DEFAULT_UNSET
# @REQUIRED
# @DESCRIPTION:
# This variable contains a space separated list of targets (see above) a package
# is compatible to. It must be set before the `inherit' call. There is no
# default. All ebuilds are expected to set this variable.
# @ECLASS-VARIABLE: RUBY_DEPS
# @DESCRIPTION:
#
# This is an eclass-generated Ruby dependency string for all
# implementations listed in USE_RUBY. Any one of the supported ruby
# targets will satisfy this dependency.
#
# Example use:
# @CODE
# RDEPEND="${RUBY_DEPS}
# dev-foo/mydep"
# BDEPEND="${RDEPEND}"
# @
#
# Example value:
# @CODE
# || ( dev-lang/ruby:2.0 dev-lang/ruby:1.9 )
# @CODE
_ruby_single_implementations_depend() {
local depend
for _ruby_implementation in ${RUBY_TARGETS_PREFERENCE}; do
if [[ ${USE_RUBY} =~ ${_ruby_implementation} ]]; then
depend="${depend} $(_ruby_implementation_depend
$_ruby_implementation)"
fi
done
echo "|| ( ${depend} )"
}
_ruby_single_set_globals() {
RUBY_DEPS=$(_ruby_single_implementations_depend)
}
_ruby_single_set_globals
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/ruby-ng.eclass,v 1.53 2013/12/26
07:11:48 graaff Exp $
# @ECLASS: ruby-utils.eclass
# @MAINTAINER:
# Ruby team
# @AUTHOR:
# Author: Hans de Graaff
# @BLURB: An eclass for supporting ruby scripts and bindings in non-ruby
packages
# @DESCRIPTION:
# The ruby-utils eclass is designed to allow an easier installation of
# Ruby scripts and bindings for non-ruby packages.
#
# This eclass does not set any metadata variables nor export any phase
# functions. It can be inherited safely.
case ${EAPI} in
0|1|2)
die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}" ;;
3|4|5) ;;
*)
die "Unknown EAPI=${EAPI} for ${ECLASS}"
esac
if [[ ! ${_RUBY_UTILS} ]]; then
# @ECLASS-VARIABLE: RUBY_TARGETS_PREFERENCE
# @DESCRIPTION:
# This variable lists all the known ruby targets in preference of use as
# determined by the ruby team. By using this ordering rather than the
# USE_RUBY mandated ordering we have more control over which ruby
# implementation will be installed first (and thus eselected). This will
# provide for a better first installation experience.
# All RUBY_TARGETS
RUBY_TARGETS_PREFERENCE="ruby20 ruby19 "
# All other active ruby targets
RUBY_TARGETS_PREFERENCE+="ruby21 rbx jruby "
_ruby_implementation_depend() {
local rubypn=
local rubyslot=
case $1 in
ruby18)
rubypn="dev-lang/ruby"
rubyslot=":1.8"
;;
ruby19)
rubypn="dev-lang/ruby"
rubyslot=":1.9"
;;
ruby20)
rubypn="dev-lang/ruby"
rubyslot=":2.0"
;;
ruby21)
[gentoo-dev] Last rites: dev-lang/rubinius-1*
# Hans de Graaff (27 Apr 2015) # This version of rubinius is old and only very few # packages ever got the associated "rbx" RUBY_TARGET. # If you would like to keep rubinius in Gentoo, please # help us to get the currently masked rubinius 2.x # versions ready. Masked for removal in 30 days. =dev-lang/rubinius-1* signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-ruby/echoe, dev-ruby/rubyforge
# Hans de Graaff (27 Apr 2015) # rubyforge.org has not been available for almost a year, making the # rubyforge package obsolete. echoe is a leaf package that still # depends on it. Masked for removal in 30 days. dev-ruby/echoe dev-ruby/rubyforge signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Hey arch teams, we need your input!
Hi! On Sun, 26 Apr 2015, Jeroen Roovers wrote: > On Sun, 26 Apr 2015 08:04:11 -0400 > Rich Freeman wrote: > > If we're talking about human parsing, can you give an example of how > > variation makes your life more difficult today? I'm just trying to > > understand what we're trying to fix... > > Reading through hundreds of Summaries. If the atoms and the request > variant are always in the same place, parsing by humans is MUCH quicker. Look at security bugs that ask for stabilization with the goal of having a GLSA. The bugs all look the same and I wish all stabilization and keywording bugs adopted the same format. There is one corner case where that format is not enough: multiple ebuilds/versions with non-homogenic archs, i.e.: cat-egory/packageA-1.2.3amd64 x86 alpha cat-egory/packageB-2.3.9amd64 alpha cat-egory/packageC-3.99 amd64 x86 ppc64 cat-egory/packageD-10.2.5a alpha The format I used here seemes to be slightly more common than others and it is good enough for me™. Any add-on prose should be _after_ the standardized bit. And while we're talking about ponies: Let's make it trivial for the requester to also specify the _correct and complete_ list of per-arch dependencies that also need to be tested and keyworded. It is one of the most annoying things about stabilization bugs: having to hunt dependencies. Side note: please make sure to include all FEATURES=test gated dependencies, too. The prose should also mention if there are circular ones (I'm looking at you, dev-ruby/*). There, now that's off my chest. Regards, Tobias -- Sent from aboard the Culture ship GCU Sacrificial Victim
