[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog
Dnia 2015-06-02, o godz. 03:58:35
"Michael Sterrett (mr_bones_)" napisał(a):
> mr_bones_15/06/02 03:58:35
>
> Modified: gnugo-3.9.1-r1.ebuild ChangeLog
> Log:
> add slot dep for repoman
>
> (Portage version: 2.2.18/cvs/Linux x86_64, unsigned Manifest commit)
>
> Revision ChangesPath
> 1.5 games-board/gnugo/gnugo-3.9.1-r1.ebuild
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild?rev=1.5&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild?rev=1.5&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild?r1=1.4&r2=1.5
>
> Index: gnugo-3.9.1-r1.ebuild
> ===
> RCS file: /var/cvsroot/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -u -r1.4 -r1.5
> --- gnugo-3.9.1-r1.ebuild 25 Mar 2015 13:51:47 - 1.4
> +++ gnugo-3.9.1-r1.ebuild 2 Jun 2015 03:58:35 - 1.5
> @@ -1,6 +1,6 @@
> # Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild,v
> 1.4 2015/03/25 13:51:47 ago Exp $
> +# $Header: /var/cvsroot/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild,v
> 1.5 2015/06/02 03:58:35 mr_bones_ Exp $
>
> EAPI=5
> inherit eutils games
> @@ -14,7 +14,7 @@
> KEYWORDS="amd64 ~arm ~ppc ~ppc64 x86 ~amd64-linux ~x86-linux ~ppc-macos"
> IUSE="readline"
>
> -DEPEND="readline? ( sys-libs/readline )
> +DEPEND="readline? ( sys-libs/readline:0 )
> >=sys-libs/ncurses-5.2-r3"
> RDEPEND=${DEPEND}
This should be actually := (or :0=) for both deps since gnugo links to
them. This also applies to your remaining 'warning silencing' commits.
--
Best regards,
Michał Górny
pgp4d5csnY1fD.pgp
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: linux-info.eclass
On 02 Jun 2015 08:11, Michał Górny wrote:
> Dnia 2015-06-02, o godz. 04:27:35
> "Mike Frysinger (vapier)" napisał(a):
> > + for OUTPUT_DIR in "${SYROOT}" "${ROOT}" "" ; do
>
> What's SYROOT? Did you mean SYSROOT?
thanks, fixed
-mike
signature.asc
Description: Digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog
On 02/06/15 17:04, Michał Górny wrote:
> Dnia 2015-06-02, o godz. 03:58:35
> "Michael Sterrett (mr_bones_)" napisał(a):
>
>> mr_bones_15/06/02 03:58:35
>>
>> Modified: gnugo-3.9.1-r1.ebuild ChangeLog
>> Log:
>> add slot dep for repoman
>>
>> (Portage version: 2.2.18/cvs/Linux x86_64, unsigned Manifest commit)
>>
>> Revision ChangesPath
>> 1.5 games-board/gnugo/gnugo-3.9.1-r1.ebuild
>>
>> file :
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild?rev=1.5&view=markup
>> plain:
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild?rev=1.5&content-type=text/plain
>> diff :
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild?r1=1.4&r2=1.5
>>
>> Index: gnugo-3.9.1-r1.ebuild
>> ===
>> RCS file: /var/cvsroot/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild,v
>> retrieving revision 1.4
>> retrieving revision 1.5
>> diff -u -r1.4 -r1.5
>> --- gnugo-3.9.1-r1.ebuild25 Mar 2015 13:51:47 - 1.4
>> +++ gnugo-3.9.1-r1.ebuild2 Jun 2015 03:58:35 - 1.5
>> @@ -1,6 +1,6 @@
>> # Copyright 1999-2015 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> -# $Header:
>> /var/cvsroot/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild,v 1.4
>> 2015/03/25 13:51:47 ago Exp $
>> +# $Header:
>> /var/cvsroot/gentoo-x86/games-board/gnugo/gnugo-3.9.1-r1.ebuild,v 1.5
>> 2015/06/02 03:58:35 mr_bones_ Exp $
>>
>> EAPI=5
>> inherit eutils games
>> @@ -14,7 +14,7 @@
>> KEYWORDS="amd64 ~arm ~ppc ~ppc64 x86 ~amd64-linux ~x86-linux ~ppc-macos"
>> IUSE="readline"
>>
>> -DEPEND="readline? ( sys-libs/readline )
>> +DEPEND="readline? ( sys-libs/readline:0 )
>> >=sys-libs/ncurses-5.2-r3"
>> RDEPEND=${DEPEND}
>
> This should be actually := (or :0=) for both deps since gnugo links to
> them. This also applies to your remaining 'warning silencing' commits.
>
Why? Blindly adding the subslot dep is a bad idea.
Re: [gentoo-dev] udev-init-scripts update
On 06/01/15 11:45, William Hubbs wrote: All, I have not released udev-init-scripts-28 yet. However, the latest version is set up the way I think we should go forward; it automatically adds the services to the sysinit runlevel. Take a look and let me know what you think. William I'll be testing today or tomorrow. Can you hang on to the news release until then? Not critical, but just in case there's some other issue that needs to be stated in the news item. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog
On 02 Jun 2015 20:47, Michael Palimaka wrote: > On 02/06/15 17:04, Michał Górny wrote: > > Dnia 2015-06-02, o godz. 03:58:35 > > "Michael Sterrett (mr_bones_)" napisał(a): > >> -DEPEND="readline? ( sys-libs/readline ) > >> +DEPEND="readline? ( sys-libs/readline:0 ) > > > > This should be actually := (or :0=) for both deps since gnugo links to > > them. This also applies to your remaining 'warning silencing' commits. > > Why? Blindly adding the subslot dep is a bad idea. in this particular case, the subslot usage is what we want since we're compiling+linking against it. using readline:0 vs readline is still an improvement though. we also want a subslot on ncurses since we compile+link against it. i think it's pretty uncommon to use readline in a package and not want a subslot. your package would have to be doing something uncommon like dlopening it since the only thing readline provides is a library ... -mike signature.asc Description: Digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog
On 02/06/15 21:38, Mike Frysinger wrote: > On 02 Jun 2015 20:47, Michael Palimaka wrote: >> On 02/06/15 17:04, Michał Górny wrote: >>> Dnia 2015-06-02, o godz. 03:58:35 >>> "Michael Sterrett (mr_bones_)" napisał(a): -DEPEND="readline? ( sys-libs/readline ) +DEPEND="readline? ( sys-libs/readline:0 ) >>> >>> This should be actually := (or :0=) for both deps since gnugo links to >>> them. This also applies to your remaining 'warning silencing' commits. >> >> Why? Blindly adding the subslot dep is a bad idea. > > in this particular case, the subslot usage is what we want since we're > compiling+linking against it. using readline:0 vs readline is still an > improvement though. > > we also want a subslot on ncurses since we compile+link against it. > > i think it's pretty uncommon to use readline in a package and not want a > subslot. your package would have to be doing something uncommon like > dlopening it since the only thing readline provides is a library ... > -mike > Neither readline nor ncurses define an explicit subslot, so I don't know what their future meaning might be. While this is not likely to ever present a problem for ncurses or readline, the trend of blindly adding := to all dependencies without knowing what it actually means is concerning. It would be nice to have some information first, for example: * readline subslot will be bumped when libreadline breaks, most packages want the operator * poppler has some libraries with stable interfaces, only use the operator if you link against unstable libpoppler (not libpoppler-qt4) * libfoo has an additional private, unstable api used only by specific packages - don't use the operator unless you know what you're doing
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog
On 02 Jun 2015 23:07, Michael Palimaka wrote: > On 02/06/15 21:38, Mike Frysinger wrote: > > On 02 Jun 2015 20:47, Michael Palimaka wrote: > >> On 02/06/15 17:04, Michał Górny wrote: > >>> Dnia 2015-06-02, o godz. 03:58:35 > >>> "Michael Sterrett (mr_bones_)" napisał(a): > -DEPEND="readline? ( sys-libs/readline ) > +DEPEND="readline? ( sys-libs/readline:0 ) > >>> > >>> This should be actually := (or :0=) for both deps since gnugo links to > >>> them. This also applies to your remaining 'warning silencing' commits. > >> > >> Why? Blindly adding the subslot dep is a bad idea. > > > > in this particular case, the subslot usage is what we want since we're > > compiling+linking against it. using readline:0 vs readline is still an > > improvement though. > > > > we also want a subslot on ncurses since we compile+link against it. > > > > i think it's pretty uncommon to use readline in a package and not want a > > subslot. your package would have to be doing something uncommon like > > dlopening it since the only thing readline provides is a library ... > > Neither readline nor ncurses define an explicit subslot, so I don't know > what their future meaning might be. their meaning would be the reasonable one -- to track the SONAME. while it hasn't been deployed yet (due to those packages being on EAPI=4), i don't know what other value you'd expect it to be. they've both broken their SONAMEs in the past. readline in particular has been every major version (4.x, 5.x, 6.x). -mike signature.asc Description: Digital signature
Re: [gentoo-dev] LFS QA warnings coming soon to a build near you
On 01 Jun 2015 10:15, Alexis Ballier wrote: > On Sun, 31 May 2015 11:17:50 -0400 Mike Frysinger wrote: > > (3) considering the glibc effort has been stalled for over a year, > > (1) is something we can help accomplish and make reasonable progress > > on (4) glibc isn't the only one that implements LFS in a transparent > > backwards compatible manner > > maybe the fact that some file operations are broken with glibc's > default settings on a somewhat popular fs would be a good argument to > un-stall it ? it isn't that black & white. while for many packages the change would be harmless, glibc is more conservative than that. it can be shown that a not uncommon coding style is to use long's everywhere when dealing with the fs. when sizeof(off_t)==sizeof(long), this works out. when off_t is suddenly twice as large, then you can get truncation at best (which is kind of the status quo) and random corruption at worse (like an API that takes pointers to off_t's but the caller passed in a long). if you want to join the list upstream and contribute to the discussion, you're more than welcome to. the maintainers aren't clueless -- they fully understand the trade-offs we're discussing here and know that 32bit fs accesses lead to failures (including stat). since sitting on our hands and hoping for the best continues to accomplish nothing, getting the various upstream packages to opt-in to LFS themselves can make real progress now. > > which leads me to the next part ... my first suggestion in the > > tracker is for autotool based projects to use AC_SYS_LARGEFILE > > because: (a) it supports a variety of systems > > (b) as new systems come up or bugs are found or whatever, the > > autoconf macro will improve and people eventually get those fixes for > > free (c) it does it all transparently for you -- add the macro and > > you're done (d) it fixes the package for all users, new & old > > > > the reason i listed only the raw CPPFLAGS and autoconf macros are > > because those are the two i'm familiar with. i don't know how other > > build systems (e.g. cmake) support this (assuming they do at all). > > if people have other recipes on hand, then it would be great to > > collect more there. > > yes, but that is not what i am discussing: unless i missed something, > they'll all end up one way or another adding the relevant defines; > whether it is done with an m4 macro, append-lfs-flags, a cmake function > or what else is an implementation detail of little interest to me trying > to understand why we don't simply change the default :) as i already said, changing the default in *glibc* doesn't help non-glibc systems. using portable build systems (like autotools) lets you easily enable features like this and the build system knows the various platform details. if you decided to roll your own build system or use one that isn't that portable, well that's kind of your fault isn't it ? if you've opted to only support a subset of systems, then that means adding these CPPFLAGS yourself. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] LFS QA warnings coming soon to a build near you
On 01 Jun 2015 09:51, Christopher Head wrote: > On May 31, 2015 7:33:28 AM PDT, Alexis Ballier wrote: > >I'm not sure what's best for every one: > >1. Push hundreds of patches upstream to add lfs flags; > >2. Apply your patch to our glibc ebuilds, fix the corner cases, and go > > back to glibc upstream with these data. > > If the changes are made to glibc, would these be under a new symbol version > for ABI compatibility, or just be changes to headers to make > _FILE_OFFSET_BITS=64 the default? If not, what about binary software? Not > saying you haven’t considered the relevant issues; I just haven’t seen binary > software brought up on this list yet. regardless of what the headers export as a default, glibc's ABI would not change. the CPPFLAGS merely control which set of symbols are used. any existing binary packages would continue to operate the same way they always have. -mike signature.asc Description: Digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog
On 02/06/15 23:52, Mike Frysinger wrote: > On 02 Jun 2015 23:07, Michael Palimaka wrote: >> On 02/06/15 21:38, Mike Frysinger wrote: >>> On 02 Jun 2015 20:47, Michael Palimaka wrote: On 02/06/15 17:04, Michał Górny wrote: > Dnia 2015-06-02, o godz. 03:58:35 > "Michael Sterrett (mr_bones_)" napisał(a): >> -DEPEND="readline? ( sys-libs/readline ) >> +DEPEND="readline? ( sys-libs/readline:0 ) > > This should be actually := (or :0=) for both deps since gnugo links to > them. This also applies to your remaining 'warning silencing' commits. Why? Blindly adding the subslot dep is a bad idea. >>> >>> in this particular case, the subslot usage is what we want since we're >>> compiling+linking against it. using readline:0 vs readline is still an >>> improvement though. >>> >>> we also want a subslot on ncurses since we compile+link against it. >>> >>> i think it's pretty uncommon to use readline in a package and not want a >>> subslot. your package would have to be doing something uncommon like >>> dlopening it since the only thing readline provides is a library ... >> >> Neither readline nor ncurses define an explicit subslot, so I don't know >> what their future meaning might be. > > their meaning would be the reasonable one -- to track the SONAME. while it > hasn't been deployed yet (due to those packages being on EAPI=4), i don't > know > what other value you'd expect it to be. they've both broken their SONAMEs in > the past. readline in particular has been every major version (4.x, 5.x, > 6.x). > -mike > Since you've clarified the future meaning for ncurses/readline, it's not a problem. The point was it's not a good idea to use the operator unless without knowing what it means for the package in question (since a subslot can be used to handle a number of different situations, as I wrote previously).
Re: [gentoo-dev] s6.eclass: new eclass for installing s6 services
All,
here is the updated version of the eclass; I believe I fixed all typos.
Thanks,
William
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: s6.eclass
# @MAINTAINER:
# William Hubbs
# @BLURB: helper functions to install s6 services
# @DESCRIPTION:
# This eclass provides helpers to install s6 services.
# @EXAMPLE:
#
# @CODE
# inherit s6
#
# src_install() {
# ...
# s6_install_service myservice "${FILESDIR}"/run-s6
"${FILESDIR}"/finish-s6
...
# If you want a service to be logged, install the log service as
# shown here.
# s6_install_service myservice/log "${FILESDIR}"/log-run-s6 \
# "${FILESDIR}"/log-finish-s6
# ...
# }
# @CODE
case ${EAPI:-0} in
5) ;;
*) die "${ECLASS}.eclass: API in EAPI ${EAPI} not yet established"
esac
# @FUNCTION: _s6_get_servicedir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed servicedir.
_s6_get_servicedir() {
echo /var/svc.d
}
# @FUNCTION: s6_get_servicedir
# @DESCRIPTION:
# Output the path for the s6 service directory (not including ${D}).
s6_get_servicedir() {
debug-print-function ${FUNCNAME} "${@}"
echo "${EPREFIX}$(_s6_get_servicedir)"
}
# @FUNCTION: s6_install_service
# @USAGE: servicename run finish
# @DESCRIPTION:
# Install an s6 service.
# servicename is the name of the service.
# run is the run script for the service.
# finish is the optional finish script for the service.
s6_install_service() {
debug-print-function ${FUNCNAME} "${@}"
local name="$1"
local run="$2"
local finish="$3"
[[ $name ]] ||
die "${ECLASS}.eclass: you must specify the s6 service name"
[[ $run ]] ||
die "${ECLASS}.eclass: you must specify the s6 service run
script"
(
local servicepath="$(_s6_get_servicedir)/$name"
exeinto "$servicepath"
newexe "$run" run
[[ $finish ]] && newexe "$finish" finish
)
}
# @FUNCTION: s6_service_down
# @USAGE: servicename
# @DESCRIPTION:
# Install the "down" flag so this service will not be started by
# default.
# servicename is the name of the service.
s6_service_down() {
debug-print-function ${FUNCNAME} "${@}"
local name="$1"
[[ $name ]] ||
die "${ECLASS}.eclass: you must specify the s6 service name"
(
touch "$T"/down || die
local servicepath="$(_s6_get_servicedir)/$name"
insinto "$servicepath"
doins "$T"/down
)
}
# @FUNCTION: s6_service_nosetsid
# @USAGE: servicename
# @DESCRIPTION:
# Install the "nosetsid" flag so this service will not be made a session
# leader.
# servicename is the name of the service.
s6_service_nosetsid() {
debug-print-function ${FUNCNAME} "${@}"
local name="$1"
[[ $name ]] ||
die "${ECLASS}.eclass: you must specify the s6 service name"
(
touch "$T"/nosetsid || die
local servicepath="$(_s6_get_servicedir)/$name"
insinto "$servicepath"
doins "$T"/nosetsid
)
}
signature.asc
Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog
On 03 Jun 2015 00:28, Michael Palimaka wrote: > On 02/06/15 23:52, Mike Frysinger wrote: > > On 02 Jun 2015 23:07, Michael Palimaka wrote: > >> On 02/06/15 21:38, Mike Frysinger wrote: > >>> On 02 Jun 2015 20:47, Michael Palimaka wrote: > On 02/06/15 17:04, Michał Górny wrote: > > Dnia 2015-06-02, o godz. 03:58:35 > > "Michael Sterrett (mr_bones_)" napisał(a): > >> -DEPEND="readline? ( sys-libs/readline ) > >> +DEPEND="readline? ( sys-libs/readline:0 ) > > > > This should be actually := (or :0=) for both deps since gnugo links to > > them. This also applies to your remaining 'warning silencing' commits. > > Why? Blindly adding the subslot dep is a bad idea. > >>> > >>> in this particular case, the subslot usage is what we want since we're > >>> compiling+linking against it. using readline:0 vs readline is still an > >>> improvement though. > >>> > >>> we also want a subslot on ncurses since we compile+link against it. > >>> > >>> i think it's pretty uncommon to use readline in a package and not want a > >>> subslot. your package would have to be doing something uncommon like > >>> dlopening it since the only thing readline provides is a library ... > >> > >> Neither readline nor ncurses define an explicit subslot, so I don't know > >> what their future meaning might be. > > > > their meaning would be the reasonable one -- to track the SONAME. while it > > hasn't been deployed yet (due to those packages being on EAPI=4), i don't > > know > > what other value you'd expect it to be. they've both broken their SONAMEs > > in > > the past. readline in particular has been every major version (4.x, 5.x, > > 6.x). > > Since you've clarified the future meaning for ncurses/readline, it's not > a problem. > > The point was it's not a good idea to use the operator unless without > knowing what it means for the package in question (since a subslot can > be used to handle a number of different situations, as I wrote previously). you make a reasonable point, but i'd consider some of your examples as (ab|mis)use of subslots. their purpose is to track ABI changes so as to signal rebuilds. if they've been appropriated for other uses, then perhaps those libraries are doing it wrong ? i expect subslots to do one thing (what PMS describes/intends) and would be surprised to find out that some packages are doing something else. -mike signature.asc Description: Digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/gnugo: gnugo-3.9.1-r1.ebuild ChangeLog
On 03/06/15 01:30, Mike Frysinger wrote: > On 03 Jun 2015 00:28, Michael Palimaka wrote: >> On 02/06/15 23:52, Mike Frysinger wrote: >>> On 02 Jun 2015 23:07, Michael Palimaka wrote: On 02/06/15 21:38, Mike Frysinger wrote: > On 02 Jun 2015 20:47, Michael Palimaka wrote: >> On 02/06/15 17:04, Michał Górny wrote: >>> Dnia 2015-06-02, o godz. 03:58:35 >>> "Michael Sterrett (mr_bones_)" napisał(a): -DEPEND="readline? ( sys-libs/readline ) +DEPEND="readline? ( sys-libs/readline:0 ) >>> >>> This should be actually := (or :0=) for both deps since gnugo links to >>> them. This also applies to your remaining 'warning silencing' commits. >> >> Why? Blindly adding the subslot dep is a bad idea. > > in this particular case, the subslot usage is what we want since we're > compiling+linking against it. using readline:0 vs readline is still an > improvement though. > > we also want a subslot on ncurses since we compile+link against it. > > i think it's pretty uncommon to use readline in a package and not want a > subslot. your package would have to be doing something uncommon like > dlopening it since the only thing readline provides is a library ... Neither readline nor ncurses define an explicit subslot, so I don't know what their future meaning might be. >>> >>> their meaning would be the reasonable one -- to track the SONAME. while it >>> hasn't been deployed yet (due to those packages being on EAPI=4), i don't >>> know >>> what other value you'd expect it to be. they've both broken their SONAMEs >>> in >>> the past. readline in particular has been every major version (4.x, 5.x, >>> 6.x). >> >> Since you've clarified the future meaning for ncurses/readline, it's not >> a problem. >> >> The point was it's not a good idea to use the operator unless without >> knowing what it means for the package in question (since a subslot can >> be used to handle a number of different situations, as I wrote previously). > > you make a reasonable point, but i'd consider some of your examples as > (ab|mis)use of subslots. their purpose is to track ABI changes so as > to signal rebuilds. if they've been appropriated for other uses, then > perhaps those libraries are doing it wrong ? i expect subslots to do > one thing (what PMS describes/intends) and would be surprised to find > out that some packages are doing something else. > -mike > They're still tracking ABI changes to signal rebuilds - they just don't apply to all consumers. poppler's subslot tracks the main libpoppler which frequently breaks, but the package also provides libpoppler-qt4 which is stable - these consumers never need rebuilding.
Re: [gentoo-dev] s6.eclass: new eclass for installing s6 services
This was committed just now since there was no further feedback. William signature.asc Description: Digital signature
