Re: [gentoo-dev] Packages up for grabs: x11-misc/lightdm-mini-greeter and x11-misc/xautolock
Hi Orbea, My time availability is somewhat constrained at the moment, but, also given Hans's response to my email, happy to assist or even co-maintain. Kind regards, Jaco On 2023/06/21 18:36, orbea wrote: On Wed, 21 Jun 2023 16:23:38 +0200 Jaco Kroon wrote: Hi Hans, On 2023/06/17 10:12, Hans de Graaff wrote: After migrating to Wayland I no longer have a need for these X packages. I have already removed myself as maintainer. x11-misc/xautolock Has one open bug that should be addressed upstream, but upstream is pretty much dead: https://bugs.gentoo.org/634766 I refer to an email 2022/07/19 where you took over xautolock from Jonas, now you're dropping it. Doesn't look like much work was required since I use xautolock and am willing to look at any pressing build issues if they arise. I'm still using this - you have moved to wayland so no longer a problem for you. From the referenced bug report it looks like there isn't much "care" for the package any more? Assuming m...@scarlet.be is no longer responsive either? From commit 0da382f0a5c38cce6e70a3724471a6c7981730d7 it looks like there's some possible compile/build issues. This commit talks about how using imake is problematic and while I entirely agree with that, it may not be trivial to write a new build system. I'll take a look later if I find time and motivation. Kind regards, Jaco
[gentoo-dev] Re: [gentoo-dev-announce] Migrating ebuilds to "optimized" cargo.eclass API
On 19/06/2023 18.01, Michał Górny wrote:
> Hi,
>
> The migration requires two changes:
>
> 1. `$(cargo_crate_uris)` (or `$(cargo_crate_uris ${CRATES})`) in SRC_URI
> needs to be replaced by `${CARGO_CRATE_URIS}`. This requires that
> CRATES and GIT_CRATES are declared pre-inherit (this is already enforced
> for CRATES in EAPI 8, but it is not for GIT_CRATES).
>
> 2. The CRATES variable (and other crate lists) need to use `@`
> as the separator between crate name and version instead of `-`.
> The easiest way to do this is to use >=app-portage/pycargoebuild-0.7 to
> generate the variable. You can use the in-place mode to update
> the ebuild, then it will substitute the list in place:
>
> pycargoebuild -i foo-1.2.3.ebuild /directories/with/cargo-lock
>
> Note that pycargoebuild won't replace $(cargo_crate_uris) automatically
> though.
>
I want to add here, that since yesterday, pkgcheck live () is
warning about the "old less optimal" usage and recommends the replacement.
While I know the distrust people have to live ebuilds, the pkgcore stack
is very serious about the live state. As long as you rebuild
periodically the live version (for example using smart-live-rebuild, so
you aren't left with a version from years ago) this is considered
supported by upstream and very stable. I try to cut new pkgcheck
releases every month, but until then feel free to use live.
--
Arthur Zamarin
arthur...@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU)
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] [PATCH] acct-user.eclass: improve error message when usermod fails
usermod refuses to update the home directory for a user with running
processes. Output a more helpful message and avoid calling die for this.
For other usermod failures, output stderr as an eerror message and die.
Example output:
* Failed to update user portage
* This user currently has one or more running processes.
* Please update this user manually with the following command:
* usermod '--comment' 'System user; portage' '--home'
'/var/lib/portage/home' '--shell' '/bin/bash' '--gid' 'portage' '--groups' ''
portage
Bug: https://bugs.gentoo.org/888189
Signed-off-by: Mike Gilbert
---
eclass/acct-user.eclass | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index f8a51ebf9c6b..88d7d354c8e6 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -432,12 +432,30 @@ acct-user_pkg_postinst() {
fi
elog "Updating user ${ACCT_USER_NAME}"
- if ! usermod "${opts[@]}" "${ACCT_USER_NAME}"
2>"${T}/usermod-error.log"; then
- # usermod outputs a warning if unlocking the account would
result in an
- # empty password. Hide stderr in a text file and display it if
usermod
- # fails.
+ # usermod outputs a warning if unlocking the account would result in an
+ # empty password. Hide stderr in a text file and display it if usermod
fails.
+ usermod "${opts[@]}" "${ACCT_USER_NAME}" 2>"${T}/usermod-error.log"
+ local status=$?
+ if [[ ${status} -ne 0 ]]; then
cat "${T}/usermod-error.log" >&2
- die "usermod failed"
+ if [[ ${status} -eq 8 ]]; then
+ # usermod refused to update the home directory
+ # for a uid with active processes.
+ eerror "Failed to update user ${ACCT_USER_NAME}"
+ eerror "This user currently has one or more running
processes."
+ eerror "Please update this user manually with the
following command:"
+
+ # Surround opts with quotes.
+ # With bash-5 (EAPI 8), we can use "${opts[@]@Q}"
instead.
+ local q="'"
+ local optsq=( "${opts[@]/#/$q}" )
+ optsq=( "${optsq[@]/%/$q}" )
+
+ eerror " usermod ${optsq[@]} ${ACCT_USER_NAME}"
+ else
+ eerror "$(<"${T}/usermod-error.log")"
+ die "usermod failed"
+ fi
fi
}
--
2.41.0
Re: [gentoo-dev] Eselect repository feature request
On 21/06/2023 19.59, TOMAS FABRIZIO ORSI wrote:
I think flow's idea to make the sync command configurable somehow
would be sufficient, assuming there is demand for it.
I agree.
I'm glad Flow has their ideas straight.
By the way Flow, could you share the links of the repo/PR so that we can
follow the development along? I would love to see it! ^_^
https://github.com/projg2/eselect-repository/pull/23
Unlike I previously assumed, this currently shells out twice to portage:
1. to query the list of currently available repositories, via "portageq
get_repos /"
2. to sync a repository, via "emaint sync -r ${repo}"
Feedback welcomed. :)
- Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
