It seems like there has been a lot of discussion here that indicates
people are happy with the way it is. There seems to be differences in
how packages are updated based on their purpose - desktop packages
move very fast, a lot of server infrastructure moves more slowly. It
seems like the "best" so
On 17-07-30 14:24:50, Daniel Campbell wrote:
> On 07/23/2017 07:13 AM, Manuel Rüger wrote:
> > The following packages are up for grabs:
> >
> > app-admin/gixy
> > app-admin/mei-amt-check
> > app-admin/ngxtop
> > app-admin/passwordsafe
> > app-arch/lz5
> > app-crypt/acme
> > app-crypt/certbot
> > a
On Sun, Jul 30, 2017 at 10:44:58PM -0400, William L. Thomson Jr. wrote:
> On Mon, 31 Jul 2017 10:28:31 +1000
> Sam Jorna wrote:
> >
> > Wouldn't it make more sense to make Gentoo *more* attractive to run in
> > corporate environments, rather than simply saying "We're not RHEL so
> > why bother"?
>
On Mon, 31 Jul 2017 10:28:31 +1000
Sam Jorna wrote:
>
> Wouldn't it make more sense to make Gentoo *more* attractive to run in
> corporate environments, rather than simply saying "We're not RHEL so
> why bother"?
No disagreement. That has always been my interest. Though has not been
others. It wa
On 07/19/2017 02:33 AM, Amy Liffey wrote:
> The following package is up for grabs:
>
> dev-lang/gforth
>
> Best regards,
> Amy Liffey
>
I can take this one; I'd hate to see Forth support go missing on Gentoo.
I'm open to co-maintainers as well.
~zlg
--
Daniel Campbell - Gentoo Developer
OpenP
Hi,
Sam Jorna writes:
> Wouldn't it make more sense to make Gentoo *more* attractive to run in
> corporate environments, rather than simply saying "We're not RHEL so why
> bother"?
>
> People do use Gentoo in production environments, both personally and
> professionally, even if it is those that
On Fri, Jul 28, 2017 at 03:59:36PM -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
> > >professi
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2017-07-30 23:59 UTC.
Removals:
app-cdr/acetoneiso 20170730-07:10 mgorny aa0b56de836
app-crypt/mdcrack20170730-07:13 mgorny 1f6ac435ca6
app-eselect/eselect
On 07/23/2017 07:13 AM, Manuel Rüger wrote:
> The following packages are up for grabs:
>
> app-admin/gixy
> app-admin/mei-amt-check
> app-admin/ngxtop
> app-admin/passwordsafe
> app-arch/lz5
> app-crypt/acme
> app-crypt/certbot
> app-crypt/certbot-apache
> app-crypt/certbot-nginx
> app-crypt/easy-
On Sun, 30 Jul 2017 14:32:53 +0300
Andrew Savchenko wrote:
> For EAPI 6+ java-pkg-opt-2_src_prepare() has eapply_user call via
> java-utils-2_src_prepare() from java-utils-2.eclass. But
> java-utils-2_src_prepare() call is conditional and in case when
> package is build with USE=-java java-utils-
++
On Sun, Jul 30, 2017, at 02:46 CDT, Sergei Trofimovich
wrote:
> On Sat, 29 Jul 2017 19:12:23 -0400
> Joshua Kinard wrote:
>
>> The following kludge is present in toolchain.eclass, in
>> toolchain_pkg_pretend():
>>
>> [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
>>
Hi all,
For EAPI 6+ java-pkg-opt-2_src_prepare() has eapply_user call via
java-utils-2_src_prepare() from java-utils-2.eclass. But
java-utils-2_src_prepare() call is conditional and in case when
package is build with USE=-java java-utils-2_src_prepare() is not
called, hence eapply_user is not call
On 2017-07-23 16:13, Manuel Rüger wrote:
> The following packages are up for grabs:
> dev-util/cookiecutter
I will take this one as I used it.
--
Cédric Krier
signature.asc
Description: Digital signature
On Sat, 29 Jul 2017 19:12:23 -0400
Joshua Kinard wrote:
> The following kludge is present in toolchain.eclass, in
> toolchain_pkg_pretend():
>
> [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
> die "Sorry, this version does not support uClibc"
>
> The below pa
14 matches
Mail list logo
