On Fri, 2020-03-27 at 01:16 +, Samuel Bernardo wrote:
> Dear all,
>
> Fulfilling the linting of ebuild code style design for software projects
> that loads their dependencies during build, such as go based projects or
> npm as an example, could be very nasty.
>
> Looking into source code of s
On Thu, 2020-03-26 at 22:12 +0100, Ulrich Mueller wrote:
> > > > > > On Thu, 26 Mar 2020, William Hubbs wrote:
> > If there's a way inside an eclass to check that the ebuild inheriting
> > it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
> > and this variable is set.
>
> Oh pl
On Thu, 2020-03-26 at 14:03 -0700, Patrick McLean wrote:
> This patch splits the definition of _PYTHON_ALL_IMPLS and
> _python_impl_supported to a separate eclass, this allows overlays
> to easily support a different set of python implementations than
> ::gentoo without having to fork the entire su
Hi,
On 2020/03/27 03:25, Joshua Kinard wrote:
> On 3/23/2020 04:21, Jaco Kroon wrote:
>> Hi,
>>
>> https://bugs.gentoo.org/713668 relates.
>>
>> * Searching for /usr/include/execinfo.h ...
>> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
>>
>> As I see I can either add an explicit depend on gl
On Fri, Mar 27, 2020 at 01:16:43AM +, Samuel Bernardo wrote:
> Dear all,
>
> Fulfilling the linting of ebuild code style design for software projects
> that loads their dependencies during build, such as go based projects or
> npm as an example, could be very nasty.
>
> Looking into source co
On Thu, Mar 26, 2020 at 7:19 PM Patrick McLean wrote:
>
> This patch splits the definition of _PYTHON_ALL_IMPLS and
> _python_impl_supported to a separate eclass, this allows overlays
> to easily support a different set of python implementations than
> ::gentoo without having to fork the entire su
[2020-03-27 01:16:43+] Samuel Bernardo:
> 2) For snapd I need to load previously the remote repositories
> dependencies into a tar.gz that need to be stored in ebuild files. This
> is ugly, I know, but there is no distfiles trusted repository
> alternative where I can place them.
> As a workaro
On 3/23/2020 04:21, Jaco Kroon wrote:
> Hi,
>
> https://bugs.gentoo.org/713668 relates.
>
> * Searching for /usr/include/execinfo.h ...
> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
>
> As I see I can either add an explicit depend on glibc which I'd prefer
> not to. Or someone from the mu
Dear all,
Fulfilling the linting of ebuild code style design for software projects
that loads their dependencies during build, such as go based projects or
npm as an example, could be very nasty.
Looking into source code of snapd or opennebula as two examples, I need
to break network sandbox to g
This patch splits the definition of _PYTHON_ALL_IMPLS and
_python_impl_supported to a separate eclass, this allows overlays
to easily support a different set of python implementations than
::gentoo without having to fork the entire suite of eclasses.
Changes from previous version (based on feedbac
Hi,
On 2020/03/26 23:34, Andreas K. Huettel wrote:
> # Andreas K. Hüttel (2020-03-26)
> # Fail to build with glibc-2.30; no maintainer. Removal in 30days.
> # Bugs 691756, 691710
> x11-terms/aterm
I'll take this via proxy-maint.
Kind Regards,
Jaco
# Andreas K. Hüttel (2020-03-26)
# Fail to build with glibc-2.30; no maintainer. Removal in 30days.
# Bugs 691756, 691710
x11-terms/aterm
x11-terms/xvt
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
signature.asc
Descr
> On Thu, 26 Mar 2020, William Hubbs wrote:
> If there's a way inside an eclass to check that the ebuild inheriting
> it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
> and this variable is set.
Oh please, not this again. An ebuild or eclass is supposed to work the
same e
This patch splits the definition of _PYTHON_ALL_IMPLS and
_python_impl_supported to a separate eclass, this allows overlays
to easily support a different set of python implementations than
::gentoo without having to fork the entire suite of eclasses.
diff --git a/eclass/python-impls-r1.eclass b/ecl
On 2020-03-23 20:33, Jonas Stein wrote:
> sys-apps/flashrom
I'll take this one, I still use it from time to time.
--
MS
signature.asc
Description: OpenPGP digital signature
On Thu, 2020-03-26 at 13:47 -0700, Patrick McLean wrote:
> On Thu, 26 Mar 2020 21:11:11 +0100
> Michał Górny wrote:
>
> > On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> > > There are situations in which downstream overlays need to have versions
> > > of python which Gentoo no longer su
On Thu, 26 Mar 2020 21:11:11 +0100
Michał Górny wrote:
> On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> > There are situations in which downstream overlays need to have versions
> > of python which Gentoo no longer supports in the tree.
> >
> > Currently, the only way to do this is fo
On Thu, Mar 26, 2020 at 08:37:17PM +0100, David Seifert wrote:
*snip*
> How do you prevent some extra clever Gentoo developer from doing the following
> in ::gentoo
>
> dev-python/foo/foo-1.ebuild:
>
> # don't have the time to port this right now, patches welcome
> PYTHON_COMPAT_ALLOW_EXT
On Thu, Mar 26, 2020 at 09:11:11PM +0100, Michał Górny wrote:
> I've already told you that if you want to fork, fork all eclasses. Then
> you wouldn't have to worry about internal API going out of sync.
>
> Or don't autoupdate ::gentoo when eclasses change.
I also suggested something that is a co
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> There are situations in which downstream overlays need to have versions
> of python which Gentoo no longer supports in the tree.
>
> Currently, the only way to do this is for the overlay author to fork
> python-utils-r1.eclass. This is high
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> This variable is meant to be set in downstream overlays when they need python
> implementations other than the ones we support in the tree.
> It should be a space-separated list of extra implementations.
>
> Signed-off-by: William Hubbs
>
On Thu, Mar 26, 2020 at 03:37:48PM -0400, Mike Gilbert wrote:
> On Thu, Mar 26, 2020 at 3:13 PM William Hubbs wrote:
> >
> > This variable is meant to be set in downstream overlays when they need
> > python
> > implementations other than the ones we support in the tree.
> > It should be a space-s
On Thu, Mar 26, 2020 at 3:13 PM William Hubbs wrote:
>
> This variable is meant to be set in downstream overlays when they need python
> implementations other than the ones we support in the tree.
> It should be a space-separated list of extra implementations.
This new variable should be document
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> There are situations in which downstream overlays need to have versions
> of python which Gentoo no longer supports in the tree.
>
> Currently, the only way to do this is for the overlay author to fork
> python-utils-r1.eclass. This is high
> +[[ -n ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[*]} ]] &&
Without string check:
[[ ${#PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[@]} -gt 0 ]]
> + _PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS} )
> readonly _PYTHON_ALL_IMPLS
Once array, always array:
_PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXT
This variable is meant to be set in downstream overlays when they need python
implementations other than the ones we support in the tree.
It should be a space-separated list of extra implementations.
Signed-off-by: William Hubbs
---
eclass/python-utils-r1.eclass | 2 ++
1 file changed, 2 inserti
There are situations in which downstream overlays need to have versions
of python which Gentoo no longer supports in the tree.
Currently, the only way to do this is for the overlay author to fork
python-utils-r1.eclass. This is highly undesirable since it creates a
very significant maintenance bur
Thank you Michal and Haelwenn for your advises.
I'm taking as reference the documentation about functions syntax in
devmanual[1] (very useful for a quickly review).
In the source code where autoreconf is being called I found a
configure.ac and Makefile.am.
Looking into autogen.sh[2] script prvid
[2020-03-26 17:47:35+] Samuel Bernardo:
> I send this email to ask you for your help for the better approach to
> translate the following autoreconf command to an ebuild:
>
> > |autoreconf -i -f ./configure \ --prefix=/usr \
> > --libexecdir=/usr/lib/snapd \
> > --with-snap-mount-dir=/var/lib/
On 26. 3. 2020 18:47, Samuel Bernardo wrote:
> Dear all,
>
> I send this email to ask you for your help for the better approach to
> translate the following autoreconf command to an ebuild:
>
>> |autoreconf -i -f ./configure \ --prefix=/usr \
>> --libexecdir=/usr/lib/snapd \
>> --with-snap-mount-
Dear all,
I send this email to ask you for your help for the better approach to
translate the following autoreconf command to an ebuild:
> |autoreconf -i -f ./configure \ --prefix=/usr \
> --libexecdir=/usr/lib/snapd \
> --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \
> --enable-n
# Michał Górny (2020-03-26)
# dev-python/aiohttp-cors is dead upstream and does not support
# Python 3.7 and newer.
#
# net-misc/gns3-* are effectively unmaintained and stuck with py3.6.
# gns3-server is the only revdep of aiohttp-cors, as well as the only
# blocker for removal of old dev-python/{
32 matches
Mail list logo
