Re: [gentoo-dev] [ebuild] How to do make install while in compilation stage

[Andrew Ammerlaan]

Hi,

On 11/07/2022 05:17, Xi Shen wrote:

Hi,

I am trying to create an ebuild file for 
https://github.com/NVIDIA/libnvidia-container 
. It has a few other 
dependencies which will be built by itself.


Such an ebuild already exists in the ::guru overlay (maintainer in CC). 
I see it is one version behind though. Feel free to bump it to the 
latest version if you want, probably a simple copy and renaming of the 
ebuild will do the trick.


My ebuild can download and compile those dependencies. But one of the 
dependency "libtirpc-1.3.2" needs to install itself in the temporary 
portage environment. Its Makefile allows me to pass in the "DESTDIR" 
variable which I passed in 
"/var/tmp/portage/sys-libs/libnvidia-container-1.10.0/work/libnvidia-container-1.10.0/deps", 
but when it installs, the package is installed to 
"/var/tmp/portage/sys-libs/libnvidia-container-1.10.0/work/libnvidia-container-1.10.0/deps/var/tmp/portage/sys-libs/libnvidia-container-1.10.0/work/libnvidia-container-1.10.0/deps/usr/local", 
the working director got repeated after the "deps" directory.


I checked the makefile, but could not figure out where that path got 
replicated. I guess when running inside the portage build environment, 
there's some "chroot" trick that prevents packages from writing the root 
file system.


So I want to ask if I need to do a "make install" during compilation, 
how should I pass the destination directory?


Don't try to install things to the installation directory (${ED}) during 
the compile phase. If you really have something that insists on being 
installed somewhere to complete the compilation, then install it to some 
temporary directory, e.g. ${T} and then if necessary copy it from the 
temporary directory into the installation directory during the install 
phase. The ebuild in ::guru seems to solve your problem with a bunch of 
patches, which I think is a better solution.


Best regards,
Andrew

[gentoo-dev] [PATCH] python-utils-r1.eclass: avoid nested ebegin calls

[Mike Gilbert]

It's common for python_check_deps to call python_has_version, which
calls ebegin itself.

Signed-off-by: Mike Gilbert 
---
 eclass/python-utils-r1.eclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index a18ca58475f..acfa83d5e18 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1399,9 +1399,8 @@ _python_run_check_deps() {
 
local PYTHON_USEDEP="python_targets_${impl}(-)"
local PYTHON_SINGLE_USEDEP="python_single_target_${impl}(-)"
-   ebegin "  python_check_deps"
+   einfo "  python_check_deps"
python_check_deps
-   eend ${?}
 }
 
 # @FUNCTION: python_has_version
-- 
2.37.0

[gentoo-dev] [ebuild] How to do make install while in compilation stage

[Xi Shen]

Hi,

I am trying to create an ebuild file for
https://github.com/NVIDIA/libnvidia-container. It has a few other
dependencies which will be built by itself.

My ebuild can download and compile those dependencies. But one of the
dependency "libtirpc-1.3.2" needs to install itself in the temporary
portage environment. Its Makefile allows me to pass in the "DESTDIR"
variable which I passed in
"/var/tmp/portage/sys-libs/libnvidia-container-1.10.0/work/libnvidia-container-1.10.0/deps",
but when it installs, the package is installed to
"/var/tmp/portage/sys-libs/libnvidia-container-1.10.0/work/libnvidia-container-1.10.0/deps/var/tmp/portage/sys-libs/libnvidia-container-1.10.0/work/libnvidia-container-1.10.0/deps/usr/local",
the working director got repeated after the "deps" directory.

I checked the makefile, but could not figure out where that path got
replicated. I guess when running inside the portage build environment,
there's some "chroot" trick that prevents packages from writing the root
file system.

So I want to ask if I need to do a "make install" during compilation, how
should I pass the destination directory?


Thanks

[gentoo-dev] Last rites: games-engines/nazghul

[David Seifert]

# David Seifert  (2022-07-10)
# Unmaintained, last release in 2010, ebuild added by author and then
# abandoned, terrible macros break compiling with GCC 12.
# Bugs #851867, removal on 2022-08-09.
games-engines/nazghul


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more

[Bernard Cafarelli]

I can help with packages I use (resources and time permitting), but
co-maintainers are more than welcome!

On Wed, 29 Jun 2022 10:15:03 +0300
Joonas Niilola  wrote:
> app-text/convmv
Should be low maintenance

> mail-client/claws-mail
> mail-client/clawsker
My main mail client and a related configuration program

> net-libs/libetpan
A dependency for claws-mail

> net-libs/nghttp2
HTTP/2 support is nice

> net-mail/ytnef
Another one claws-mail depends on

> net-misc/wget2
Usage depending if muscle memory makes me forget the "2" or not

> x11-themes/claws-mail-themes
Not updated for a while but they still work fine

-- 
Bernard Cafarelli (Voyageur)
Gentoo developer

[gentoo-dev] Last rites: dev-python/pydispatcher

[Michał Górny]

# Michał Górny  (2022-07-10)
# The original package was discontinued in 2015.  This is a fork that
# lived for two months in 2017, and is not name-compatible with
# the original.  The last revdep was removed in 2018.
# Removal on 2022-08-09.  Bug #857252.
dev-python/pydispatcher

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] GLEP-81 migration done

[David Seifert]

On Sun, 2022-07-10 at 09:26 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 10 Jul 2022, Anna  wrote:
> 
> > On 2022-07-09 23:37, Conrad Kostecki wrote:
> > > I would like to inform you all, that GLEP-81 migration has been
> > > finally done. All existing packages got migrated and no ones left.
> 
> Great work, thank you!
> 
> > What to do with user.eclass now? It's already marked @DEPRECATED, do
> > we want it @DEAD and eventually removed?
> 
> The eclass dies in EAPI 8 if called from an ebuild outside the acct-*
> category. We could extend this to EAPIs 6 and 7 (but it might cause
> problems for overlays).
> 
> Also, not sure if the @DEPRECATED tag should be used for an eclass
> that
> is still indirectly inherited by other eclasses.
> 
> How about attached patch?
> 
> Ulrich
> 
> 
> From 49006bdb82f321c359dcf8f0f78893ccdf0e6be7 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
> Date: Sun, 10 Jul 2022 09:14:19 +0200
> Subject: [PATCH] user.eclass: Warn about eclass usage in all EAPIs
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Remove @DEPRECATED tag because this is not a removal candidate.
> 
> Signed-off-by: Ulrich Müller 
> ---
>  eclass/user.eclass | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/eclass/user.eclass b/eclass/user.eclass
> index d5b827d2e76b..b4f63ffab4a2 100644
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -7,25 +7,27 @@
>  # Michał Górny  (NetBSD)
>  # @SUPPORTED_EAPIS: 6 7 8
>  # @BLURB: user management in ebuilds
> -# @DEPRECATED: acct-user/acct-group packages
>  # @DESCRIPTION:
>  # The user eclass contains a suite of functions that allow ebuilds
>  # to quickly make sure users in the installed system are sane.
>  
>  case ${EAPI} in
> -   6|7) ;;
> -   8)
> -   if [[ ${CATEGORY} != acct-* ]]; then
> -   eerror "In EAPI ${EAPI}, packages must not
> inherit user.eclass"
> -   eerror "unless they are in the acct-user or
> acct-group category."
> -   eerror "Migrate your package to GLEP 81
> user/group management,"
> -   eerror "or inherit user-info if you need only
> the query functions."
> -   die "Invalid \"inherit user\" in EAPI ${EAPI}"
> -   fi
> -   ;;
> +   6|7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
>  esac
>  
> +if [[ ${CATEGORY} != acct-* ]]; then
> +   eerror "Packages must not inherit user.eclass unless they are"
> +   eerror "in the acct-user or acct-group category."
> +   eerror "Migrate your package to GLEP 81 user/group
> management,"
> +   eerror "or inherit user-info if you need only the query
> functions."
> +   if [[ ${EAPI} != [67] ]]; then
> +   die "Invalid \"inherit user\""
> +   else
> +   eerror "This message will become fatal in EAPI ${EAPI}
> on 2023-01-01"
> +   fi
> +fi
> +
>  if [[ -z ${_USER_ECLASS} ]]; then
>  _USER_ECLASS=1
>  

sounds good

Re: [gentoo-dev] [PATCH] ruby-ng.eclass: replace ebegin with einfo in _ruby_invoke_environment

[Hans de Graaff]

On Sun, 2022-07-03 at 15:45 -0400, Mike Gilbert wrote:
> Calling ebegin here makes no sense because it is likely that the
> called
> function will also generate output. This will lead to the "[ ok ]"
> potentially appearing many lines later.
> 
> It also leads to nested ebegin calls, which make no sense for the
> same
> reason.

I looked at this earlier and left this in because it makes sense to me
to do it this way conceptually. That implies that our tools should
supported nested ebegin calls and deal with multiline output, so for me
the real issue to fix is there.

Right now that support isn't there, though, and if that isn't
forthcoming soonish I have no objections to this patch if people feel
that is the better approach (for now).

Hans


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] GLEP-81 migration done

[Ulrich Mueller]

> On Sun, 10 Jul 2022, Anna  wrote:

> On 2022-07-09 23:37, Conrad Kostecki wrote:
>> I would like to inform you all, that GLEP-81 migration has been
>> finally done. All existing packages got migrated and no ones left.

Great work, thank you!

> What to do with user.eclass now? It's already marked @DEPRECATED, do
> we want it @DEAD and eventually removed?

The eclass dies in EAPI 8 if called from an ebuild outside the acct-*
category. We could extend this to EAPIs 6 and 7 (but it might cause
problems for overlays).

Also, not sure if the @DEPRECATED tag should be used for an eclass that
is still indirectly inherited by other eclasses.

How about attached patch?

Ulrich


From 49006bdb82f321c359dcf8f0f78893ccdf0e6be7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
Date: Sun, 10 Jul 2022 09:14:19 +0200
Subject: [PATCH] user.eclass: Warn about eclass usage in all EAPIs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Remove @DEPRECATED tag because this is not a removal candidate.

Signed-off-by: Ulrich Müller 
---
 eclass/user.eclass | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/eclass/user.eclass b/eclass/user.eclass
index d5b827d2e76b..b4f63ffab4a2 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -7,25 +7,27 @@
 # Michał Górny  (NetBSD)
 # @SUPPORTED_EAPIS: 6 7 8
 # @BLURB: user management in ebuilds
-# @DEPRECATED: acct-user/acct-group packages
 # @DESCRIPTION:
 # The user eclass contains a suite of functions that allow ebuilds
 # to quickly make sure users in the installed system are sane.
 
 case ${EAPI} in
-   6|7) ;;
-   8)
-   if [[ ${CATEGORY} != acct-* ]]; then
-   eerror "In EAPI ${EAPI}, packages must not inherit 
user.eclass"
-   eerror "unless they are in the acct-user or acct-group 
category."
-   eerror "Migrate your package to GLEP 81 user/group 
management,"
-   eerror "or inherit user-info if you need only the query 
functions."
-   die "Invalid \"inherit user\" in EAPI ${EAPI}"
-   fi
-   ;;
+   6|7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
+if [[ ${CATEGORY} != acct-* ]]; then
+   eerror "Packages must not inherit user.eclass unless they are"
+   eerror "in the acct-user or acct-group category."
+   eerror "Migrate your package to GLEP 81 user/group management,"
+   eerror "or inherit user-info if you need only the query functions."
+   if [[ ${EAPI} != [67] ]]; then
+   die "Invalid \"inherit user\""
+   else
+   eerror "This message will become fatal in EAPI ${EAPI} on 
2023-01-01"
+   fi
+fi
+
 if [[ -z ${_USER_ECLASS} ]]; then
 _USER_ECLASS=1
 
-- 
2.35.1



signature.asc
Description: PGP signature