Re: [gentoo-dev] [PATCH 5/7] cargo.eclass: use custom profile for all builds
On Thu, 2023-02-09 at 16:35 -0500, Ionen Wolkens wrote: > On Thu, Feb 09, 2023 at 12:48:45PM -0800, Georgy Yakovlev wrote: > > + strip = "none" > > strip was stabilized in rust-1.59, this will likely fail without > USE=nightly on older rusts and other patch is only setting >=1.57 > > Haven't checked other options, I just happened to remember this one. might have missed one, thanks. Will re-check and if it's the case - document it above minimum req line and bump it.
Re: [gentoo-dev] [PATCH 4/7] cargo.eclass: set progress.when = "never" in config
On Fri, 2023-02-10 at 07:03 +0100, Michał Górny wrote:
> On Thu, 2023-02-09 at 12:48 -0800, Georgy Yakovlev wrote:
> > to avoid possible log file pollution
> >
> > Signed-off-by: Georgy Yakovlev
> > ---
> > eclass/cargo.eclass | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> > index 9c624d607cdd..0ab7ee0dc9b2 100644
> > --- a/eclass/cargo.eclass
> > +++ b/eclass/cargo.eclass
> > @@ -273,6 +273,7 @@ cargo_gen_config() {
> > [term]
> > verbose = true
> > $([[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo
> > "color = 'never'")
> > + progress.when = "never"
> > $(_cargo_gen_git_config)
> > _EOF_
> >
>
> What's that and why don't we want it? I thought we generally
> preferred
> more verbosity.
>
This knob controls progress bar that can pollute logs in rare cases,
not build verbosity. verbose is set just above.
[gentoo-dev] [PATCH 6/7] cargo.eclass: set codegen-units = 1
This might increase build and lto times a bit,
but may result in faster and better optimized result.
It also honors resource limits properly.
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index a7c7bffd3c0c..00b8078f80ea 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -279,6 +279,11 @@ cargo_gen_config() {
$(usex debug 'opt-level = 0' '')
$(usex debug 'lto = false' '')
+ #
https://doc.rust-lang.org/rustc/codegen-options/index.html#codegen-units
+ # We use single codegen unit for most optimized code and to honor -j
from MAKEOPTS.
+ # Users can override via e.g. CARGO_PROFILE_gentoo_CODEGEN_UNITS="16"
in make.conf.
+ codegen-units = 1
+
[build]
jobs = $(makeopts_jobs)
incremental = false
--
2.39.1
[gentoo-dev] [PATCH 5/7] cargo.eclass: use custom profile for all builds
also move install path to config file, so it can be
overriden via command line arg if required.
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 0ab7ee0dc9b2..a7c7bffd3c0c 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -266,10 +266,26 @@ cargo_gen_config() {
[net]
offline = true
+ [profile.gentoo]
+ #
https://doc.rust-lang.org/cargo/reference/profiles.html#custom-profiles
+ inherits = "release"
+
+ # emulate dev profile with USE=debug
+ # https://doc.rust-lang.org/cargo/reference/profiles.html#dev
+ debug = $(usex debug true false)
+ debug-assertions = $(usex debug true false)
+ overflow-checks = $(usex debug true false)
+ strip = "none"
+ $(usex debug 'opt-level = 0' '')
+ $(usex debug 'lto = false' '')
+
[build]
jobs = $(makeopts_jobs)
incremental = false
+ [install]
+ root = "${ED}/usr"
+
[term]
verbose = true
$([[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color =
'never'")
@@ -506,7 +522,7 @@ cargo_src_compile() {
tc-export AR CC CXX PKG_CONFIG
- set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
+ set -- cargo build --profile gentoo ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
"${@}" || die "cargo build failed"
}
@@ -524,14 +540,17 @@ cargo_src_install() {
die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
set -- cargo install $(has --path ${@} || echo --path ./) \
- --no-track \
- --root "${ED}/usr" \
- ${GIT_CRATES[@]:+--frozen} \
- $(usex debug --debug "") \
- ${ECARGO_ARGS[@]} "$@"
+ --profile gentoo --no-track \
+${GIT_CRATES[@]:+--frozen} ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
"${@}" || die "cargo install failed"
+ # HACK: compat symlinks until old ebuilds migrate.
+ # create target/{debug,release} symlinks that some ebuilds rely on.
+ # This only affects ebuilds that pick extra generated files from target
directory, that's rare.
+ ln -s gentoo "${S}"/target/debug || :
+ ln -s gentoo "${S}"/target/release || :
+
# it turned out to be non-standard dir, so get rid of it future EAPI
# and only run for EAPI=7
# https://bugs.gentoo.org/715890
@@ -553,7 +572,7 @@ cargo_src_test() {
[[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
- set -- cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
+ set -- cargo test --profile gentoo ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
"${@}" || die "cargo test failed"
}
--
2.39.1
[gentoo-dev] [PATCH 4/7] cargo.eclass: set progress.when = "never" in config
to avoid possible log file pollution
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 9c624d607cdd..0ab7ee0dc9b2 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -273,6 +273,7 @@ cargo_gen_config() {
[term]
verbose = true
$([[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color =
'never'")
+ progress.when = "never"
$(_cargo_gen_git_config)
_EOF_
--
2.39.1
[gentoo-dev] [PATCH 7/7] cargo.eclass: filter out lto flags for C/CXX compilers
we do it in src_compile to avoid excessive flag stripping in projects
using cargo.eclass just to fetch crates.
Closes: https://bugs.gentoo.org/893658
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 00b8078f80ea..27ccee1295b3 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -49,7 +49,7 @@ case "${EAPI:-0}" in
;;
esac
-inherit multiprocessing toolchain-funcs
+inherit flag-o-matic multiprocessing toolchain-funcs
if [[ ! ${CARGO_OPTIONAL} ]]; then
BDEPEND="${RUST_DEPEND}"
@@ -525,6 +525,7 @@ cargo_src_compile() {
[[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+ filter-lto
tc-export AR CC CXX PKG_CONFIG
set -- cargo build --profile gentoo ${ECARGO_ARGS[@]} "$@"
--
2.39.1
[gentoo-dev] [PATCH 3/7] cargo.eclass: document undocumented variables, mark as readonly
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 1a8d665fdad2..9c624d607cdd 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -58,8 +58,15 @@ fi
IUSE="${IUSE} debug"
-ECARGO_HOME="${WORKDIR}/cargo_home"
-ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
+# @ECLASS_VARIABLE: ECARGO_HOME
+# @DESCRIPTION:
+# Directory for CARGO_HOME used by build process.
+readonly ECARGO_HOME="${WORKDIR}/cargo_home"
+
+# @ECLASS_VARIABLE: ECARGO_VENDOR
+# @DESCRIPTION:
+# Directory for 'cargo vendor' subcommand output.
+readonly ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
# @ECLASS_VARIABLE: CRATES
# @DEFAULT_UNSET
--
2.39.1
[gentoo-dev] [PATCH 2/7] cargo.eclass: pass --no-track to cargo install
and drop file removal hack.
with --no-track those files are never created.
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index d37293ada136..1a8d665fdad2 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -516,6 +516,7 @@ cargo_src_install() {
die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
set -- cargo install $(has --path ${@} || echo --path ./) \
+ --no-track \
--root "${ED}/usr" \
${GIT_CRATES[@]:+--frozen} \
$(usex debug --debug "") \
@@ -523,9 +524,6 @@ cargo_src_install() {
einfo "${@}"
"${@}" || die "cargo install failed"
- rm -f "${ED}/usr/.crates.toml" || die
- rm -f "${ED}/usr/.crates2.json" || die
-
# it turned out to be non-standard dir, so get rid of it future EAPI
# and only run for EAPI=7
# https://bugs.gentoo.org/715890
--
2.39.1
[gentoo-dev] [PATCH 1/7] cargo.eclass: bump minimum rust to 1.57.0
and mark RUST_DEPEND as readonly
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index a92fe97ec502..d37293ada136 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -13,28 +13,32 @@
if [[ -z ${_CARGO_ECLASS} ]]; then
_CARGO_ECLASS=1
-# check and document RUST_DEPEND and options we need below in case conditions.
+# @ECLASS_VARIABLE: RUST_DEPEND
+# @INTERNAL
+# @DESCRIPTION:
+# Minimum rust/cargo version that should be used with this eclass.
+# Versions below that may not provide functionality we rely on.
+# This variable should not be overriden by ebuilds, just manually
+# add more recent version if package requires it.
# https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md
-RUST_DEPEND="virtual/rust"
+# 1.37 added 'cargo vendor' subcommand and net.offline config knob
+# 1.39 added --workspace
+# 1.46 added --target dir
+# 1.48 added term.progress config option
+# 1.51 added split-debuginfo profile option
+# 1.52 may need setting RUSTC_BOOTSTRAP envvar for some crates
+# 1.53 added cargo update --offline, can be used to update vulnerable crates
from pre-fetched registry without editing toml
+# 1.57 added named profile support in stable
+readonly RUST_DEPEND=">=virtual/rust-1.57"
case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
7)
- # 1.37 added 'cargo vendor' subcommand and net.offline config
knob
- RUST_DEPEND=">=virtual/rust-1.37.0"
;;
8)
- # 1.39 added --workspace
- # 1.46 added --target dir
- # 1.48 added term.progress config option
- # 1.51 added split-debuginfo profile option
- # 1.52 may need setting RUSTC_BOOTSTRAP envvar for some crates
- # 1.53 added cargo update --offline, can be used to update
vulnerable crates from pre-fetched registry without editing toml
- RUST_DEPEND=">=virtual/rust-1.53"
-
if [[ -z ${CRATES} && "${PV}" != ** ]]; then
eerror "undefined CRATES variable in non-live EAPI=8
ebuild"
die "CRATES variable not defined"
--
2.39.1
[gentoo-dev] cargo.eclass improvements
Series of patches to cargo.eclass most important chages are: 1. minimum rust/cargo version bump, which will propogate to all consumers. 2. introduction of custom build profile (similar to what we do in Cmake) This will allow to consistently specify build options, yeat allows overrides from users or developers via envvars and/or args. PR: https://github.com/gentoo/gentoo/pull/29510 PS: still WIP, but most changes are ready. Another upcoming change is to allow running 'cargo update' to be able to bump vulnerable/outdated pkgs listed in CRATES.
Re: [gentoo-dev] 23.0 profiles - which features?
On Wed, 2022-10-12 at 23:56 +0200, Andreas K. Huettel wrote: > > Hey all, > > > > in the past I already sent a mail about features for a next profile > > > version. > > The feedback was rather limited, but anyway we got quite a list of > > > ideas. > > The general tracker is bug 876891. > > > > In the following I would like to put up the various features for > > > discussion, > > in order of bug number... Feedback very welcome. To me usrmerge alone would be sufficient to provide new release, but adding more changes in is a good idea too. I would like to switch ppc64le profiles to 128-bit IEEE long double ABI 23.0 seems like a good cause to finally tackle it. This will need some toolchain magic, I will open a bug and block profile-23.0 tracker. Fedora finally switched recently https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition I tried the switch about a year ago and ran into some trouble with projects that bundle gnulib. I'll open a bug and block the tracker. > > > > Cheers > > Andreas > > > > > > https://bugs.gentoo.org/515694 > > Bug 515694 - Update MIPS profiles to use ABI-specific CHOST values > > > for > > clang/llvm compatibility > > Affects only mips profiles. Should eventually be done, I guess? > > > > https://bugs.gentoo.org/675050 > > Bug 675050 - [toolchain] Enable GCC's -fstack-clash-protection for > > > all > > profiles in Gentoo by default > > > > https://bugs.gentoo.org/792081 > > Bug 792081 - rename no-multilib to nomultilib, also in profile > > names > > Apparently this simplifies things for some people, and a new > > profile > > is a good chance to do the cosmetic change. > > > > https://bugs.gentoo.org/818376 > > Bug 818376 - [toolchain] Adopt SHT_RELR/DT_RELR relative relocation > > > format > > *very* new feature... > > > > https://bugs.gentoo.org/831045 > > Bug 831045 - profiles: remove USE=cli default and inline into > > ebuilds > > Easy. > > > > https://bugs.gentoo.org/849875 > > Bug 849875 - profiles: remove USE=dri default, clean up > > make.defaults > > Also easy. > > > > https://bugs.gentoo.org/876879 > > Bug 876879 - separate openrc and systemd features, not one > > overriding > the > > other > > Right now all profiles inherit openrc-specific settings, and these > > > are > > then again negated and/or overridden in the systemd profiles. > > Sorting > > this more cleanly would be nice. > > > > https://bugs.gentoo.org/876881 > > Bug 876881 - make merged usr the default configuration > > With the next profile version, the "default" setting > > > (default/linux/XX.X/amd64) > > is a merged usr profile, while the old layout is still present as a > > split-usr feature. Not sure if this is worth the trouble. > > > > https://bugs.gentoo.org/876883 > > Bug 876883 - [tracker] time64 migration > > Needed. > > > > https://bugs.gentoo.org/876893 > > Bug 876893 - [toolchain] Adopt -D_FORTIFY_SOURCE=3 for hardened by > > > default > > > > https://bugs.gentoo.org/876895 > > Bug 876895 - [toolchain] Adopt -D_GLIBCXX_ASSERTIONS for hardened > > by > default > > > >
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Wed, 2022-09-28 at 17:28 +0200, Florian Schmaus wrote: > > I would like to continue discussing whether we should entirely > > > deprecate > > EGO_SUM without the desire to offend anyone. > > > > We now have a pending GitHub PR that bumps restic to 0.14 [1]. > > Restic > is > > a very popular backup software written in Go. The PR drops EGO_SUM > > in > > favor of a vendor tarball created by the proxied maintainer. > > However, > I > > am unaware of any tool that lets you practically audit the 35 MiB > > > source > > contained in the tarball. And even if such a tool exists, this > > would > > mean another manual step is required, which is, potentially, > > skipped > > most of the time, weakening our user's security. This is because I > > believe neither our tooling, e.g., go-mod.eclass, nor any Golang > > tooling, does authenticate the contents of the vendor tarball > > against > > upstream's go.sum. But please correct me if I am wrong. > > > > I wonder if we can reach consensus around un-depreacting EGO_SUM, > > but > > discouraging its usage in certain situations. That is, provide > > > EGO_SUM > > as option but disallow its use if > > 1.) *upstream* provides a vendor tarball > > 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo > > developer > > maintains the package > > 3.) the number of EGO_SUM entries exceeds 1500 and a proxied > > > maintainer > > maintains the package > > > > In case of 3, I would encourage proxy maintainers to create and > > > provide > > the vendor tarball. > > > > The suggested EGO_SUM limits result from a histogram that I created > > analyzing ::gentoo at 2022-01-01, i.e., a few months before EGO_SUM > > > was > > deprecated. I think those numbers are too large but overall I think bringing back EGO_SUM in limited form is a good move, because it allows packaging go ebuilds in an easy and audit-able way. If you have vendor tarball - it's completely opaque before you unpack. With EGO_SUM you could parse ebuilds using that and scan for vulnerable go modules. and ofc vendored source hosting is a problem >From rust's team perspective ( we use CRATES, which is EGO_SUM inspiration, but _much_ more compact one) - I'd say take largest rust ebuild and allow as much as that or slightly more. x11-terms/alacritty is one of largest and CRATES number of lines is about 210 per 1 ebuild. So I'd say set maximum EGO_SUM size to 256 for ::gentoo, or maybe 512, remove limit for overlays completely. and introduce a hard die() in eclass if EGO_SUM is larger than that. not sure if you can detect repo name in eclass. In that case pkgcheck and CI could enforce that as fat warnings or errors. 256/512 limitation will not impose limit on manifest directly, but if you have 5 versions of max 256/512 EGO_SUM loc - it'll be more reasonable than 5 versions of max 1500 EGO_SUM loc. rust/cargo ebuild will still produce more compact Manifest given same amount of lines though, so it's still not directly comparable. currently we have 3 versions of alacritty which uses 407 unique crates across 3 versions. Manifest size is about 120K, which is 20th largest in ::gentoo It's nothing compared to 2.5MB manifests we used to have in some of the largest go packages. > > > > - Flow > > > > 1: https://github.com/gentoo/gentoo/pull/27050 > >
[gentoo-dev] Packages up for grabs: dev-lang/typescript, gnome-extra/gnome-shell-extension-pop-shell
Hi, Following package up for grabs: gnome-extra/gnome-shell-extension-pop-shell dev-lang/typescript I no longer uses pop-shell and it's > 1y outdated. typescript is a build dependency and pop-shell is it's only revdep. However, there are plenty of typescript users and package is popular. Yes, it's npm package, but it's unique because it has no external deps. Easy to maintain too, no bugs open, only dependency is nodejs[npm] May use eapi8 bump. As for pop-shell, bump will require packaging 2 extra deps: pop-launcher pop-shortcuts Both are rust, the latter uses justfile instead of makefile. It also uses rustls with ring crate, which is not portable and had no commits since april 2022. So my recommendation is to drop pop-shell or move to guru. And keep typescript in repo, it's popular. Thanks for reading! -- Best regards, Georgy
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
...snip > > > In that case, I think the only viable way to make this work is to > > disable automatic stripping and handle stripping via custom code in > > the ebuild/eclass. > > > might work indeed if we do something like (pseudo-bash) > > if [[ module_sign == yes ]]; then > dostrip -x /lib/modules # to stop portage stripping .ko objects > manual-strip-respecting-features-nostrip -r /lib/modules > sign-all-modules -r /lib/modules > fi > [[ compress_modules == yes ]] && compress-modules -r /lib/modules > > > this will equire eapi-bumping couple of packages > https://qa-reports.gentoo.org/output/eapi-per-eclass/linux-mod.eclass/6.txt > and restricting linux-mod.eclass to eapi7 or later. > > > started playing with my old code and got blocked right away: looks like dostrip just creates a list of files/directories to strip and processed at the very end of install phase. so skipping strip and doing manual one might be problematic. internally portage uses estrip https://github.com/gentoo/portage/blob/master/bin/estrip which contains quite a lot of logic and code and I don't think partially re-implementing this in eclass code is appropriate.
[gentoo-dev] Looking for co-maintainers for number of packages
I've been rather busy lately and can't keep up with all of my packages. There are pending bumps, some bugs, but nothing too crazy or hard. So I'm looking for someone to co-maintain (or even take over if you insist) the following packages: * net-mail/notmuch pseudo-autoconf NIH build system that can be PITA to work with, responsive upstream. High profile package. proxied maintainer in metadata has not been active lately and probably should be dropped. * net-irc/weechat Regular but not very frequent releases, responsive upstream, cmake, pretty sane and very popular. * dev-cpp/abseil-cpp Googleware, it's usually bundled into source, like gnulib, but some projects use system copy. Hardcoded flags, broken abi every other bump, may require slotting in the future, some revdeps rely on older versions. Not hard to maintain, but has more that usual blast radius. * net-libs/grpc * dev-python/grpcio * dev-python/grpcio-tools * dev-python/grpcio-testing grpc stack, googleware again. rather frequent releases, lack of portage-able tests, as tests insist on downloading gtest stack git master in src_test phase. Technically it's already co-maintained, but I't be beneficial if we have more hands and eyes on this one. python project has been helping with python packages, but lack of tests makes the package somewhat risky. bonus points if you can test it with tensorflow. * dev-util/bear Responsive upstream. Tests work but require disabling sandboxing (check ebuild on how to run it). Not too hard, pretty popular. * app-arch/dpkg debian upstream, easy to maintain. just need extra eyeballs. * app-shells/fish Responsive upstream, not very frequent releases, cmake. Requires some attention on non-x86 as arch bugs are rather frequent. But nothing too crazy. * sys-process/glances Responsive upstream, easy package. Just need extra pair of eyes/hands. * dev-util/google-perftools Another google package, very arch-specific, big blast radius if broken. Not hard to maintain, but need to be extra careful with revdeps, requires alt-arch testing. * app-admin/sysstat pretty easy but important package. I will also offer base-system to take it, as it's kinda important one. * app-admin/tmpreaper debian upstream, easy. * x11-misc/xwallpaper sane upstream, easy package. just need extra hands. probably most secure wallpaper setter out there ;-) Thanks, Georgy. PS. Huge bonus if you can test packages not only on x86_64. Ofc I can help with some gotchas in packages and have no plans on abandoning those completely, but realistically I'm not doing enough to keep those properly maintained at the moment.
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On Mon, 2022-06-27 at 17:50 -0400, Mike Gilbert wrote: > On Mon, Jun 27, 2022 at 5:11 PM Georgy Yakovlev > wrote: > > > > On Mon, 2022-06-27 at 15:49 -0400, Mike Gilbert wrote: > > > On Mon, Jun 27, 2022 at 3:42 PM Georgy Yakovlev > > > wrote: > > > > > > > > On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote: > > > > > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge > > > > > wrote: > > > > > > > so looks like we need to combine both methods and do the > > > > > > > following: > > > > > > > - if signing requested without compression - sign in > > > > > > > pkg_preinst. > > > > > > > - if signing requested with compression - sign in > > > > > > > src_install > > > > > > > > > > > > > > > > > > > Why can't we do both in pkg_preinst? I am thinking it would > > > > > > be > > > > > > best > > > > > > if > > > > > > we drop the current compression implementation and rework > > > > > > your > > > > > > old > > > > > > code > > > > > > to handle both compression and signing since the signing > > > > > > code > > > > > > is > > > > > > more or > > > > > > less already complete. > > > > > > > > > > Signing modules in pkg_preinst seems like a bad idea to me. > > > > > That > > > > > means > > > > > you need to copy your private keys around to every host where > > > > > the > > > > > package might be installed. > > > > > > > > > > If you sign in src_compile or src_install, you only need > > > > > private > > > > > keys > > > > > on the system building your binpkg. > > > > > > > > > > > > > unfortunately portage will unconditionally strip .ko objects, > > > > rendering > > > > modules unloadable by stripping signature, unless we do > > > > dostrip -x > > > > (requires EAPI7+, which should not be a problem nowadays, but > > > > was a > > > > problem back in 2018), which can be quite unfortunate on debug > > > > enabled > > > > kernels. > > > > > > Sounds like something to fix/change in Portage. It could probably > > > be > > > updated to not strip the signature. However, I would guess the > > > signature needs to be updated after the binary is modified in any > > > case. > > > > > > Or as a workaround you could disable automatic striping via > > > dostrip - > > > x > > > and run the proper commands to strip the modules in src_install > > > as > > > well. > > > > > I think even strip itself does not have proper options not to break > > module. Several years back it was the case, basically one has to > > strip > > first, sign second, otherwise module will be unloadable. > > > > "Signed modules are BRITTLE as the signature is outside of the > > defined > > ELF container. Thus they MAY NOT be stripped once the signature is > > computed and attached. Note the entire module is the signed > > payload, > > including any and all debug information present at the time of > > signing." > > > > https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html#signed-modules-and-stripping > > > > In that case, I think the only viable way to make this work is to > disable automatic stripping and handle stripping via custom code in > the ebuild/eclass. > might work indeed if we do something like (pseudo-bash) if [[ module_sign == yes ]]; then dostrip -x /lib/modules # to stop portage stripping .ko objects manual-strip-respecting-features-nostrip -r /lib/modules sign-all-modules -r /lib/modules fi [[ compress_modules == yes ]] && compress-modules -r /lib/modules this will equire eapi-bumping couple of packages https://qa-reports.gentoo.org/output/eapi-per-eclass/linux-mod.eclass/6.txt and restricting linux-mod.eclass to eapi7 or later.
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On Mon, 2022-06-27 at 16:02 -0400, Kenton Groombridge wrote: > > > Why can't we do both in pkg_preinst? I am thinking it would be > > > best > > > if > > > we drop the current compression implementation and rework your > > > old > > > code > > > to handle both compression and signing since the signing code is > > > more > > > or > > > less already complete. > > > > i'm not sure if sign-file can sign compressed modules. > > sign-file will not error when signing a compressed module, but the > kernel will not be able to load it. so we pretty much HAVE to strip->sign->compress, strictly in this order. nothing else will work. > > > if we let kernel build handle compression - we have to sign prior > > to > > compression. > > if we compress modules ourselves then yes, we could sign first > > indeed. > > > > but preinst has it's own issues, you've already seen floppym's > > remark. > >
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On Mon, 2022-06-27 at 15:49 -0400, Mike Gilbert wrote: > On Mon, Jun 27, 2022 at 3:42 PM Georgy Yakovlev > wrote: > > > > On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote: > > > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge > > > wrote: > > > > > so looks like we need to combine both methods and do the > > > > > following: > > > > > - if signing requested without compression - sign in > > > > > pkg_preinst. > > > > > - if signing requested with compression - sign in > > > > > src_install > > > > > > > > > > > > > Why can't we do both in pkg_preinst? I am thinking it would be > > > > best > > > > if > > > > we drop the current compression implementation and rework your > > > > old > > > > code > > > > to handle both compression and signing since the signing code > > > > is > > > > more or > > > > less already complete. > > > > > > Signing modules in pkg_preinst seems like a bad idea to me. That > > > means > > > you need to copy your private keys around to every host where the > > > package might be installed. > > > > > > If you sign in src_compile or src_install, you only need private > > > keys > > > on the system building your binpkg. > > > > > > > unfortunately portage will unconditionally strip .ko objects, > > rendering > > modules unloadable by stripping signature, unless we do dostrip -x > > (requires EAPI7+, which should not be a problem nowadays, but was a > > problem back in 2018), which can be quite unfortunate on debug > > enabled > > kernels. > > Sounds like something to fix/change in Portage. It could probably be > updated to not strip the signature. However, I would guess the > signature needs to be updated after the binary is modified in any > case. > > Or as a workaround you could disable automatic striping via dostrip - > x > and run the proper commands to strip the modules in src_install as > well. > I think even strip itself does not have proper options not to break module. Several years back it was the case, basically one has to strip first, sign second, otherwise module will be unloadable. "Signed modules are BRITTLE as the signature is outside of the defined ELF container. Thus they MAY NOT be stripped once the signature is computed and attached. Note the entire module is the signed payload, including any and all debug information present at the time of signing." https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html#signed-modules-and-stripping
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On Mon, 2022-06-27 at 14:35 -0400, Kenton Groombridge wrote:
> On 22/06/26 04:15AM, Georgy Yakovlev wrote:
> > On Sun, 2022-06-26 at 03:52 -0700, Georgy Yakovlev wrote:
> > > On Tue, 2022-06-21 at 14:19 -0400, Kenton Groombridge wrote:
> > > > eee74b9fca1 adds support for module compression, but this
> > > > breaks
> > > > loading
> > > > out of tree modules when module signing is enforced because
> > > > modules
> > > > must
> > > > be signed before they are compressed. Additionally, the
> > > > recommended
> > > > Portage hook[1] no longer works with this change.
> > > >
> > > > Add module signing support in linux-mod.eclass which more or
> > > > less
> > > > does
> > > > exactly what the aforementioned Portage hook does. If the
> > > > kernel
> > > > configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash
> > > > and
> > > > keys
> > > > from the kernel configuration and call the sign_file tool to
> > > > sign
> > > > the
> > > > module before it is compressed.
> > > >
> > > > Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> > > > Signed-off-by: Kenton Groombridge
> > > > ---
> > > > eclass/linux-mod.eclass | 16
> > > > 1 file changed, 16 insertions(+)
> > > >
> > > > diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> > > > index b7c13cbf7e7..fd40f6d7c6c 100644
> > > > --- a/eclass/linux-mod.eclass
> > > > +++ b/eclass/linux-mod.eclass
> > > > @@ -712,6 +712,22 @@ linux-mod_src_install() {
> > > > cd "${objdir}" || die "${objdir} does not
> > > > exist"
> > > > insinto
> > > > "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
> > > >
> > > > + # check here for CONFIG_MODULE_SIG_ALL and sign
> > > > the
> > > > module being built if enabled.
> > > > + # modules must be signed before they are
> > > > compressed.
> > > > +
> > > > + if linux_chkconfig_present MODULE_SIG_ALL; then
> > > > + local
> > > > module_sig_hash="$(linux_chkconfig_string MODULE_SIG_HASH)"
> > > > + local
> > > > module_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> > > > + module_sig_key="${module_sig_key:-
> > > > certs/signing_key.pem}"
> > > > + if [[ "${module_sig_key#pkcs11:}" ==
> > > > "${module_sig_key}" && "${module_sig_key#/}" ==
> > > > "${module_sig_key}"
> > > > ]]; then
> > > > + local
> > > > key_path="${KERNEL_DIR}/${module_sig_key}"
> > > > + else
> > > > + local
> > > > key_path="${module_sig_key}"
> > > > + fi
> > > > + local
> > > > cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> > > > + "${KERNEL_DIR}"/scripts/sign-file
> > > > ${module_sig_hash//\"} ${key_path//\"} ${cert_path}
> > > > ${modulename}.${KV_OBJ}
> > > > + fi
> > > > +
> > > > # check here for
> > > > CONFIG_MODULE_COMPRESS_ > > > option> (NONE, GZIP, XZ, ZSTD)
> > > > # and similarily compress the module being
> > > > built if
> > > > != NONE.
> > > >
> > >
> > >
> > > Hi,
> > >
> > > I've spent some time in the past ( circa 2018 ) to get this in,
> > > but
> > > gave up due to various reasons, I was not a gentoo dev yet at the
> > > time.
> > >
> > > I can't see how posted implementation will work tbh.
> > > portage will strip signature out of the module, unless you
> > > prevent
> > > stripping completely or package uses EAPI>=7, and omits stripping
> > > modules via dostrip -x on the ko object.
> > > kernel will NOT load module with stripped signature.
> > >
> > > so either you have to sign i
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote: > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge > wrote: > > > so looks like we need to combine both methods and do the > > > following: > > > - if signing requested without compression - sign in > > > pkg_preinst. > > > - if signing requested with compression - sign in src_install > > > > > > > Why can't we do both in pkg_preinst? I am thinking it would be best > > if > > we drop the current compression implementation and rework your old > > code > > to handle both compression and signing since the signing code is > > more or > > less already complete. > > Signing modules in pkg_preinst seems like a bad idea to me. That > means > you need to copy your private keys around to every host where the > package might be installed. > > If you sign in src_compile or src_install, you only need private keys > on the system building your binpkg. > unfortunately portage will unconditionally strip .ko objects, rendering modules unloadable by stripping signature, unless we do dostrip -x (requires EAPI7+, which should not be a problem nowadays, but was a problem back in 2018), which can be quite unfortunate on debug enabled kernels.
Re: [gentoo-dev] [PATCH] java-vm-2.eclass: use "eselect java-vm update" if available
On Mon, 2022-06-27 at 21:21 +0200, Florian Schmaus wrote:
> Thanks to Mike Gilbert (floppym) for valuable feedback.
>
> Closes: https://bugs.gentoo.org/853928
> Closes: https://github.com/gentoo/gentoo/pull/26069
> Signed-off-by: Florian Schmaus
> ---
> eclass/java-vm-2.eclass | 30 --
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/java-vm-2.eclass b/eclass/java-vm-2.eclass
> index 8196b1cdc72a..dc0d87f4caf5 100644
> --- a/eclass/java-vm-2.eclass
> +++ b/eclass/java-vm-2.eclass
> @@ -25,6 +25,7 @@ RDEPEND="
> "
> DEPEND="${RDEPEND}"
> BDEPEND="app-arch/unzip"
> +IDEPEND="app-eselect/eselect-java"
IDEPEND here will not do anything to current jdk source ebuilds.
openjdk source ebuilds are EAPI7 at the moment and can't be updated to
EAPI8 due to econf unconditionally passing '--disable-static'
configure: error: unrecognized options: --disable-static
configure exiting with result code 1
so befire IDEPEND works we either have to fix portage/EAPI8 econf, or
roll custom econf in source packages of jdk.
https://bugs.gentoo.org/814380 - looks like the following jdk
./configure option triggers it:
--enable-static-build
>
> if [[ ${EAPI} == 6 ]]; then
> DEPEND+=" ${BDEPEND}"
> @@ -88,14 +89,35 @@ java-vm-2_pkg_postinst() {
> xdg_desktop_database_update
> }
>
> +# @FUNCTION: has_eselect_java-vm_update
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Checks if an eselect-java version providing "eselect java-vm
> update"
> +# is available.
> +# @RETURN: 0 if >=app-eselect/eselect-java-0.5 is installed, 1
> otherwise.
> +has_eselect_java-vm_update() {
> + local has_version_args="-b"
> + if [[ ${EAPI} == 6 ]]; then
> + has_version_args="--host-root"
> + fi
> +
> + has_version "${has_version_args}" ">=app-eselect/eselect-
> java-0.5"
> +}
>
> # @FUNCTION: java-vm-2_pkg_prerm
> # @DESCRIPTION:
> # default pkg_prerm
> #
> -# Warn user if removing system-vm.
> +# Does nothing if eselect-java-0.5 or newer is available.
> Otherwhise,
> +# warn user if removing system-vm.
>
> java-vm-2_pkg_prerm() {
> + if has_eselect_java-vm_update; then
> + # We will potentially switch to a new Java system VM
> in
> + # pkg_postrm().
> + return
> + fi
> +
> if [[ $(GENTOO_VM= java-config -f 2>/dev/null) == ${VMHANDLE}
> && -z ${REPLACED_BY_VERSION} ]]; then
> ewarn "It appears you are removing your system-vm!
> Please run"
> ewarn "\"eselect java-vm list\" to list available
> VMs, then use"
> @@ -108,10 +130,14 @@ java-vm-2_pkg_prerm() {
> # @DESCRIPTION:
> # default pkg_postrm
> #
> -# Update mime database.
> +# Invoke "eselect java-vm update" if eselect-java 0.5, or newer, is
> +# available. Also update the mime database.
>
> java-vm-2_pkg_postrm() {
> xdg_desktop_database_update
> + if has_eselect_java-vm_update; then
> + eselect --root="${EROOT}" java-vm update
> + fi
> }
>
>
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On Sun, 2022-06-26 at 03:52 -0700, Georgy Yakovlev wrote:
> On Tue, 2022-06-21 at 14:19 -0400, Kenton Groombridge wrote:
> > eee74b9fca1 adds support for module compression, but this breaks
> > loading
> > out of tree modules when module signing is enforced because modules
> > must
> > be signed before they are compressed. Additionally, the recommended
> > Portage hook[1] no longer works with this change.
> >
> > Add module signing support in linux-mod.eclass which more or less
> > does
> > exactly what the aforementioned Portage hook does. If the kernel
> > configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and
> > keys
> > from the kernel configuration and call the sign_file tool to sign
> > the
> > module before it is compressed.
> >
> > Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> > Signed-off-by: Kenton Groombridge
> > ---
> > eclass/linux-mod.eclass | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> > index b7c13cbf7e7..fd40f6d7c6c 100644
> > --- a/eclass/linux-mod.eclass
> > +++ b/eclass/linux-mod.eclass
> > @@ -712,6 +712,22 @@ linux-mod_src_install() {
> > cd "${objdir}" || die "${objdir} does not exist"
> > insinto
> > "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
> >
> > + # check here for CONFIG_MODULE_SIG_ALL and sign the
> > module being built if enabled.
> > + # modules must be signed before they are
> > compressed.
> > +
> > + if linux_chkconfig_present MODULE_SIG_ALL; then
> > + local
> > module_sig_hash="$(linux_chkconfig_string MODULE_SIG_HASH)"
> > + local
> > module_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> > + module_sig_key="${module_sig_key:-
> > certs/signing_key.pem}"
> > + if [[ "${module_sig_key#pkcs11:}" ==
> > "${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}"
> > ]]; then
> > + local
> > key_path="${KERNEL_DIR}/${module_sig_key}"
> > + else
> > + local key_path="${module_sig_key}"
> > + fi
> > + local
> > cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> > + "${KERNEL_DIR}"/scripts/sign-file
> > ${module_sig_hash//\"} ${key_path//\"} ${cert_path}
> > ${modulename}.${KV_OBJ}
> > + fi
> > +
> > # check here for
> > CONFIG_MODULE_COMPRESS_ > option> (NONE, GZIP, XZ, ZSTD)
> > # and similarily compress the module being built if
> > != NONE.
> >
>
>
> Hi,
>
> I've spent some time in the past ( circa 2018 ) to get this in, but
> gave up due to various reasons, I was not a gentoo dev yet at the
> time.
>
> I can't see how posted implementation will work tbh.
> portage will strip signature out of the module, unless you prevent
> stripping completely or package uses EAPI>=7, and omits stripping
> modules via dostrip -x on the ko object.
> kernel will NOT load module with stripped signature.
>
> so either you have to sign in pkg_postinst phase, or prevent
> stripping.
> signing in postinst is not ideal, because if breaks recorded file
> checksums in vdb.
>
> here's old fork of eclass I made, maybe you can find some helpful
> code
> in there
>
> https://github.com/gyakovlev/linux-mod.eclass/blob/master/linux-mod.eclass
>
> old ML discussion we had:
> https://archives.gentoo.org/gentoo-dev/message/4b15b1c851f379a1f802e2f2895cdfa8
>
> You will also need a dependency on openssl, since sign-file uses it.
>
> lmk if you need more info, I might remember more details, but for now
> that's all I have. I'll try to help get it done, but my availability
> is
> spotty due to limited time.
after reading my old code again and thinking more I think I know what's
going on.
1. I've actually solved checksum/strip problem by signing in pkg-
preinst
2. my method will likely fail with compressed modules.
3. your method likely works only if modules are compressed - because
portage does not strip those I think.
so looks like we need to combine both methods and do the following:
- if signing requested without compression - sign in pkg_preinst.
- if signing requested with compression - sign in src_install
Do I make sense? I still haven't tested it, just guessing as I read my
old bash code.
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On Tue, 2022-06-21 at 14:19 -0400, Kenton Groombridge wrote:
> eee74b9fca1 adds support for module compression, but this breaks
> loading
> out of tree modules when module signing is enforced because modules
> must
> be signed before they are compressed. Additionally, the recommended
> Portage hook[1] no longer works with this change.
>
> Add module signing support in linux-mod.eclass which more or less
> does
> exactly what the aforementioned Portage hook does. If the kernel
> configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and
> keys
> from the kernel configuration and call the sign_file tool to sign the
> module before it is compressed.
>
> Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> Signed-off-by: Kenton Groombridge
> ---
> eclass/linux-mod.eclass | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> index b7c13cbf7e7..fd40f6d7c6c 100644
> --- a/eclass/linux-mod.eclass
> +++ b/eclass/linux-mod.eclass
> @@ -712,6 +712,22 @@ linux-mod_src_install() {
> cd "${objdir}" || die "${objdir} does not exist"
> insinto
> "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
>
> + # check here for CONFIG_MODULE_SIG_ALL and sign the
> module being built if enabled.
> + # modules must be signed before they are compressed.
> +
> + if linux_chkconfig_present MODULE_SIG_ALL; then
> + local
> module_sig_hash="$(linux_chkconfig_string MODULE_SIG_HASH)"
> + local
> module_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> + module_sig_key="${module_sig_key:-
> certs/signing_key.pem}"
> + if [[ "${module_sig_key#pkcs11:}" ==
> "${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}"
> ]]; then
> + local
> key_path="${KERNEL_DIR}/${module_sig_key}"
> + else
> + local key_path="${module_sig_key}"
> + fi
> + local
> cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> + "${KERNEL_DIR}"/scripts/sign-file
> ${module_sig_hash//\"} ${key_path//\"} ${cert_path}
> ${modulename}.${KV_OBJ}
> + fi
> +
> # check here for CONFIG_MODULE_COMPRESS_ option> (NONE, GZIP, XZ, ZSTD)
> # and similarily compress the module being built if
> != NONE.
>
Hi,
I've spent some time in the past ( circa 2018 ) to get this in, but
gave up due to various reasons, I was not a gentoo dev yet at the time.
I can't see how posted implementation will work tbh.
portage will strip signature out of the module, unless you prevent
stripping completely or package uses EAPI>=7, and omits stripping
modules via dostrip -x on the ko object.
kernel will NOT load module with stripped signature.
so either you have to sign in pkg_postinst phase, or prevent stripping.
signing in postinst is not ideal, because if breaks recorded file
checksums in vdb.
here's old fork of eclass I made, maybe you can find some helpful code
in there
https://github.com/gyakovlev/linux-mod.eclass/blob/master/linux-mod.eclass
old ML discussion we had:
https://archives.gentoo.org/gentoo-dev/message/4b15b1c851f379a1f802e2f2895cdfa8
You will also need a dependency on openssl, since sign-file uses it.
lmk if you need more info, I might remember more details, but for now
that's all I have. I'll try to help get it done, but my availability is
spotty due to limited time.
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On Mon, 2022-01-17 at 21:58 -0500, Ionen Wolkens wrote:
> On Mon, Jan 17, 2022 at 03:24:23PM -0800, Georgy Yakovlev wrote:
> > Hi,
> >
> > I've been approached multiple times with that request, and a lot of
> > time I see new users completely destroyed by rust build time and
> > disk
> > space requirements.
>
> fwiw it may be a bit mitigated by the new desktop stages that come
> with
> rust, or at least it won't be the first thing they see when they try
> to build their brand new desktop install until a rust update.
>
> It's nice if users can get a basic desktop before worrying about how
> to
> handle rust. Not that desktop stages are heavily visible/known so new
> users may not always pick them.
indeed it helps, but it takes time for users to discover/consider this.
it mostly hits very new users or users of containers/vms, who don't
have enough disk space or ram.
>
> >
> > WDYT about switching order of rusts in a virtual?
> >
> > RDEPEND="|| (
> > ~dev-lang/rust-${PV}
> > ~dev-lang/rust-bin-${PV}
> > )"
> >
> >
> > becomes
> >
> > RDEPEND="|| (
> > ~dev-lang/rust-bin-${PV}
> > ~dev-lang/rust-${PV}
> > )"
> >
> >
> > Existing installs should be unaffected ofc.
> > But portage may prefer to depclean rust and not rust-bin if both
> > are
> > present.
>
> Haven't tested how it reacts, but wouldn't that be an issue with
> system-bootstrap in situations where it pulls rust-bin to build
> itself?
it can build itself with non-bin too. as long as it's same or ver-
minus-1 and is installed, if not installed it will pull rust-bin of
matching version.
also system-bootstrap is stable-masked (for various reasons), so I'm
not too worried about it. ~kw users know their way around.
>
> > Users who wish to use source version at all times can just add it
> > to
> > world file.
> >
> > I see both positives and negatives of doing that, but would like to
> > reach out to community first.
>
> Unsure what I like best, I generally agree should default to sources
> but I do see new users complaining about building rust every few
> days.
> Not that the step of telling them that rust-bin exists is that bad
> (part of the issue is that they don't know it's an option).
>
If I had clear answer myself I would not be asking opinions here =)
just trying to understand if I'm missing something or my view is too
different.
developer and user opinions all are helpful to build picture.
I receive at least weekly complaint about how resource-intensive rust
build is, that counts too.
for now on stable systems, if user types, let's say,
$ emerge ripgrep
with USE=-system-bootsrap (the default):
portage will pull virtual/rust, which will pull dev-lang/rust, which
will bootstrap itself by downloading proper rust-bin tarball, but not
as a package, just as a tarball behind the scenes.
with USE=system-bootstrap:
portage will pull virtual/rust, which will pull dev-lang/rust-bin, and
build dev-lang/rust, to build ripgrep.
USE=system-llvm (also stable-masked) complicates picture even more.
We've had openjdk-bin and icedtea-bin as default provider for as long
as I can remember, before I started to maintain it. works fine.
PS:
and just to be clear - I'm not pushing for it, just asking for input.
[gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
Hi,
I've been approached multiple times with that request, and a lot of
time I see new users completely destroyed by rust build time and disk
space requirements.
WDYT about switching order of rusts in a virtual?
RDEPEND="|| (
~dev-lang/rust-${PV}
~dev-lang/rust-bin-${PV}
)"
becomes
RDEPEND="|| (
~dev-lang/rust-bin-${PV}
~dev-lang/rust-${PV}
)"
Existing installs should be unaffected ofc.
But portage may prefer to depclean rust and not rust-bin if both are
present.
Users who wish to use source version at all times can just add it to
world file.
I see both positives and negatives of doing that, but would like to
reach out to community first.
Thanks!
--
Georgy
Re: [gentoo-dev] Package up for grabs: app-shells/kshdb
On Sun, 2022-01-16 at 12:42 -0500, Mike Gilbert wrote: > I no longer wish to maintain this. Please take it if you are > interested. > adopted.
[gentoo-dev] Last rites: ~sys-fs/zfs{,-kmod}-0.8.6
# Georgy Yakovlev (2022-01-15) # Last branch update happened ~ 12 month ago. # Maximum kernel supported is 5.9, which we no longer package. # So 5.10 LTS users can't use it. only 4.x LTS and 5.4 LTS. # ebuild is effectively unmaintained/untested, so is upstream branch. # Removal date: sometime around June 2022 # Bug: https://bugs.gentoo.org/830020 ~sys-fs/zfs-0.8.6 ~sys-fs/zfs-kmod-0.8.6 Feel free to reach out if you think this should not happen or be delayed. 2.0.x is stable for quite some time. 2.1.x is going stable today too, and it's the upstream LTS branch.
Re: [gentoo-dev] [PATCH] profiles/targets/desktop: disable USE=xvid by default
On Wed, 2022-01-12 at 20:25 -0500, Matt Turner wrote: > On Tue, Jan 11, 2022 at 9:45 PM Georgy Yakovlev > wrote: > > > > it's an ancient codec that is barely used nowadays > > so let's disable it by default. > > Users are free to re-enable if required. > > > > Bug: https://bugs.gentoo.org/831044 > > Heh, looks like you want to leave it disabled by default because it > fails to compile on arm? :) > > I don't have a preference. I would note that a few packages depend on > it being enabled in ffmpeg: > > media-gfx/blender > media-libs/libopenshot > media-plugins/mythplugins Thanks for actually checking it =) I'm not on a crusade to disable it, just thought it's a sensible thing to do in 2022. I've opened a bug and asked maintainers for those packages to double- check if possible. My initial investigation (very brief) showed that it might be a catch- all dep or simply a historical dep that never got re-verified. https://bugs.gentoo.org/831211
[gentoo-dev] [PATCH] profiles/targets/desktop: disable USE=xvid by default
it's an ancient codec that is barely used nowadays so let's disable it by default. Users are free to re-enable if required. Bug: https://bugs.gentoo.org/831044 Signed-off-by: Georgy Yakovlev --- profiles/targets/desktop/make.defaults | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/profiles/targets/desktop/make.defaults b/profiles/targets/desktop/make.defaults index d7eab4cd0587..34470e021ca0 100644 --- a/profiles/targets/desktop/make.defaults +++ b/profiles/targets/desktop/make.defaults @@ -1,4 +1,4 @@ -# Copyright 1999-2020 Gentoo Authors +# Copyright 1999-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -USE="a52 aac acpi alsa bluetooth branding cairo cdda cdr cups dbus dri dts dvd dvdr elogind emboss encode exif flac gif gpm gtk gui icu jpeg lcms libnotify mad mng mp3 mp4 mpeg ogg opengl pango pdf png policykit ppds qt5 sdl spell startup-notification svg tiff truetype vorbis udev udisks unicode upower usb wxwidgets X xcb x264 xml xv xvid" +USE="a52 aac acpi alsa bluetooth branding cairo cdda cdr cups dbus dri dts dvd dvdr elogind emboss encode exif flac gif gpm gtk gui icu jpeg lcms libnotify mad mng mp3 mp4 mpeg ogg opengl pango pdf png policykit ppds qt5 sdl spell startup-notification svg tiff truetype vorbis udev udisks unicode upower usb wxwidgets X xcb x264 xml xv" -- 2.34.1
Re: [gentoo-dev] [PATCH] kernel-2.eclass: fix minor OBOBJCOPY -> OBJCOPY typo
merged with minor edit ( NM dupe removed in parent commit )
thanks!
On Wed, 2022-01-05 at 17:59 +0200, Adrian Ratiu wrote:
> Fixes:55f5c68c01e791c7339144aadc1f20802791551e
> Suggested-by: Manoj Gupta
> Signed-off-by: Adrian Ratiu
> ---
> eclass/kernel-2.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 865c43d3153..d1784717e41 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -692,7 +692,7 @@ env_setup_xmakeopts() {
> elif type -p ${CHOST}-ar >/dev/null; then
> xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> fi
> - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-
> getCC) LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) NM=$(tc-getNM)
> OBOBJCOPY=$(tc-getOBJCOPY) READELF=$(tc-getREADELF) STRIP=$(tc-
> getSTRIP)"
> + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-
> getCC) LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) NM=$(tc-getNM)
> OBJCOPY=$(tc-getOBJCOPY) READELF=$(tc-getREADELF) STRIP=$(tc-
> getSTRIP)"
> export xmakeopts
> }
>
[gentoo-dev] [PATCH 2/2] EXAMPLE, NOMERGE sys-kernel/gentoo-kernel: use ppc_pagesize expand
Signed-off-by: Georgy Yakovlev
---
.../gentoo-kernel/gentoo-kernel-5.15.11.ebuild | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
index e4ac32a7019..05ae8331c84 100644
--- a/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
+++ b/sys-kernel/gentoo-kernel/gentoo-kernel-5.15.11.ebuild
@@ -1,123 +1,135 @@
-# Copyright 2020-2021 Gentoo Authors
+# Copyright 2020-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=7
inherit kernel-build toolchain-funcs
MY_P=linux-${PV%.*}
GENPATCHES_P=genpatches-${PV%.*}-$(( ${PV##*.} + 2 ))
CONFIG_VER=5.15.10
CONFIG_HASH=4882b85cc85fb2b7df396c4d671cc6432596eca0
GENTOO_CONFIG_VER=5.15.5
DESCRIPTION="Linux kernel built with Gentoo patches"
HOMEPAGE="https://www.kernel.org/";
SRC_URI+=" https://cdn.kernel.org/pub/linux/kernel/v$(ver_cut
1).x/${MY_P}.tar.xz
https://dev.gentoo.org/~mpagano/dist/genpatches/${GENPATCHES_P}.base.tar.xz
https://dev.gentoo.org/~mpagano/dist/genpatches/${GENPATCHES_P}.extras.tar.xz
https://github.com/mgorny/gentoo-kernel-config/archive/v${GENTOO_CONFIG_VER}.tar.gz
-> gentoo-kernel-config-${GENTOO_CONFIG_VER}.tar.gz
amd64? (
https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-x86_64-fedora.config
-> kernel-x86_64-fedora.config.${CONFIG_VER}
)
arm64? (
https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-aarch64-fedora.config
-> kernel-aarch64-fedora.config.${CONFIG_VER}
)
ppc64? (
https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-ppc64le-fedora.config
-> kernel-ppc64le-fedora.config.${CONFIG_VER}
)
x86? (
https://src.fedoraproject.org/rpms/kernel/raw/${CONFIG_HASH}/f/kernel-i686-fedora.config
-> kernel-i686-fedora.config.${CONFIG_VER}
)"
S=${WORKDIR}/${MY_P}
LICENSE="GPL-2"
KEYWORDS="amd64 ~arm arm64 ~ppc ppc64 ~x86"
-IUSE="debug hardened"
-REQUIRED_USE="arm? ( savedconfig )"
+IUSE="debug hardened ppc_pagesize_4K +ppc_pagesize_64K"
+REQUIRED_USE="
+ arm? ( savedconfig )
+ ppc64? ( ^^ ( ppc_pagesize_4K ppc_pagesize_64K ) )
+"
RDEPEND="
!sys-kernel/gentoo-kernel-bin:${SLOT}"
BDEPEND="
debug? ( dev-util/pahole )"
PDEPEND="
>=virtual/dist-kernel-${PV}"
QA_FLAGS_IGNORED="
usr/src/linux-.*/scripts/gcc-plugins/.*.so
usr/src/linux-.*/vmlinux
usr/src/linux-.*/arch/powerpc/kernel/vdso.*/vdso.*.so.dbg
"
src_prepare() {
local PATCHES=(
# meh, genpatches have no directory
"${WORKDIR}"/*.patch
)
default
local biendian=false
# prepare the default config
case ${ARCH} in
amd64)
cp
"${DISTDIR}/kernel-x86_64-fedora.config.${CONFIG_VER}" .config || die
;;
arm)
return
;;
arm64)
cp
"${DISTDIR}/kernel-aarch64-fedora.config.${CONFIG_VER}" .config || die
biendian=true
;;
ppc)
# assume powermac/powerbook defconfig
# we still package.use.force savedconfig
cp
"${WORKDIR}/${MY_P}/arch/powerpc/configs/pmac32_defconfig" .config || die
;;
ppc64)
cp
"${DISTDIR}/kernel-ppc64le-fedora.config.${CONFIG_VER}" .config || die
biendian=true
;;
x86)
cp "${DISTDIR}/kernel-i686-fedora.config.${CONFIG_VER}"
.config || die
;;
*)
die "Unsupported arch ${ARCH}"
;;
esac
local myversion="-gentoo-dist"
use hardened && myversion+="-hardened"
echo "CONFIG_LOCALVERSION=\"${myversion}\"" > "${T}"/version.config ||
die
local
dist_conf_path="${WORKDIR}/gentoo-kernel-config-${GENTOO_CONFIG_VER}"
local merge_configs=(
"${T}"/version.config
"${dist_conf_path}"/base.config
)
use debug || merge_configs+=(
"${dist_conf_path}"/no-debug.config
)
[gentoo-dev] [PATCH 1/2] profiles: add PPC_PAGESIZE use expand
Hardware can use either size, it's a built time option.
64K is standard and is what we use by default and 99% of distros use.
4K is more compatible with desktop applications and GPU drivers,
which often assume 4K page size.
Problem from switching page sizes on reboot:
btrfs and swaps break, other filesystems like ext4 may become
unmountable, sepending on direction of switch 4K <-> 64K.
Our installcd provides both kernel options, so users can choose which
one to boot.
Planned consumers of this flag:
sys-kernel/gentoo-kernel
sys-kernel/gentoo-kernel-bin ( in the future )
sys-kernel/vanilla-kernel
dev-util/google-perftools
any other application that has a build time switch to optimize for or
set page size.
Also can be used by applications that are known to be broken with
specific page size.
Mesa and amdgpu drivers used to have some problems in the past, but it
was fixed, however broken apps still exist.
Signed-off-by: Georgy Yakovlev
---
profiles/arch/powerpc/ppc64/make.defaults | 6 +-
profiles/base/make.defaults | 4 ++--
profiles/desc/ppc_pagesize.desc | 5 +
profiles/embedded/make.defaults | 4 ++--
4 files changed, 14 insertions(+), 5 deletions(-)
create mode 100644 profiles/desc/ppc_pagesize.desc
diff --git a/profiles/arch/powerpc/ppc64/make.defaults
b/profiles/arch/powerpc/ppc64/make.defaults
index ff2526a2530..6555ec277b7 100644
--- a/profiles/arch/powerpc/ppc64/make.defaults
+++ b/profiles/arch/powerpc/ppc64/make.defaults
@@ -1,41 +1,45 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# All extra USE/etc should be specified in sub-profiles.
# DO NOT POLLUTE USE ON THIS PROFILE.
+# Georgy Yakovlev (2022-01-04)
+# Unhide PPC specific USE_EXPANDs.
+USE_EXPAND_HIDDEN="-PPC_PAGESIZE"
+
ARCH="ppc64"
ACCEPT_KEYWORDS="${ARCH}"
CHOST="powerpc64-unknown-linux-gnu"
CFLAGS="-O2 -pipe"
CXXFLAGS="${CFLAGS}"
FFLAGS="${CFLAGS}"
FCFLAGS="${CFLAGS}"
USE="ibm"
MULTILIB_ABIS="ppc64"
DEFAULT_ABI="ppc64"
KERNEL_ABI="ppc64"
PROFILE_ARCH="ppc64"
ABI="ppc64"
#CFLAGS_ppc64="-m64"
LDFLAGS_ppc64="-m elf64ppc"
CHOST_ppc64="powerpc64-unknown-linux-gnu"
CFLAGS_ppc="-m32"
LDFLAGS_ppc="-m elf32ppc"
CHOST_ppc="powerpc-unknown-linux-gnu"
# Michał Górny (2014-06-27)
# Make the ABI flag implicit for compatibility with native ebuilds.
IUSE_IMPLICIT="abi_ppc_64"
# Donnie Berkholz (2006-08-18)
# Defaults for video drivers
VIDEO_CARDS="fbdev mga nv r128 radeon"
# Enable abi_ppc_64 for packages that don't have it forced.
ABI_PPC="64"
diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index 547c7b31e83..0056543be29 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -1,179 +1,179 @@
# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
#
# System-wide defaults for the Portage system
# See portage(5) manpage
# Profile IUSE injection (applies only to ebuilds which use EAPI 5 or later)
IUSE_IMPLICIT="prefix prefix-guest prefix-stack"
USE_EXPAND_IMPLICIT="ELIBC KERNEL USERLAND"
USE_EXPAND_VALUES_ELIBC="AIX bionic Cygwin Darwin DragonFly glibc HPUX Interix
mingw musl NetBSD OpenBSD SunOS Winnt"
USE_EXPAND_VALUES_KERNEL="AIX Darwin FreeBSD freemint HPUX linux NetBSD
OpenBSD SunOS Winnt"
USE_EXPAND_VALUES_USERLAND="BSD GNU"
# Env vars to expand into USE vars. Modifying this requires prior
# discussion on gentoo-dev@lists.gentoo.org.
-USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS
APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS
CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC FFTOOLS GPSD_PROTOCOLS
GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS
LLVM_TARGETS LUA_SINGLE_TARGET LUA_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP
NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION
OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS
PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS
ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS
VOICEMAIL_STORAGE XTABLES_ADDONS"
+USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS
APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS
CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC FFTOOLS GPSD_PROTOCOLS
GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS
LLVM_TARGETS LUA_SINGLE_TARGET LUA_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP
NGINX_MO
[gentoo-dev] [PATCH] toolchain.eclass: fix crossdev powerpc-*-musl builds
otherwise initial build may fail with:
unknown long double size, cannot define BFP_FMT
Signed-off-by: Georgy Yakovlev
---
eclass/toolchain.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index fd03ba176276..1102c4fc5d56 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1099,6 +1099,11 @@ toolchain_src_configure() {
# Set up defaults based on current CFLAGS
is-flagq -mfloat-gprs=double && confgcc+=( --enable-e500-double
)
[[ ${CTARGET//_/-} == *-e500v2-* ]] && confgcc+=(
--enable-e500-double )
+ if [[ ${CTARGET} == powerpc-*-musl ]]; then
+ # fix: unknown long double size, cannot define BFP_FMT
+ confgcc+=( --disable-decimal-float )
+ export gcc_cv_target_ldbl128=no
+ fi
;;
ppc64)
# On ppc64 big endian target gcc assumes elfv1 by default,
--
2.34.1
[gentoo-dev] [PATCH] profiles/base/make.defaults: treat dtbs like modules
when dist-kernel gets uninstalled, /lib/modules/
is left behind on purpose. However, on some systems kernels also install
device-tree files to /boot/dtbs/
leaving /lib/modules, but removing device-tree file may leave system
unbootable, so let's treat dtbs directory similar to modules.
Signed-off-by: Georgy Yakovlev
---
profiles/base/make.defaults | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index f25074f9d81a..be5651f0ac43 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -134,11 +134,11 @@ PYTHON_SINGLE_TARGET="python3_9"
# Michał Górny (2013-08-10)
# Moved from portage's make.globals.
-# 1) do not uninstall kernel modules and therefore allow replacing them,
+# 1) do not uninstall kernel modules/dtbs and therefore allow replacing them,
# 2,3) removed wrt bug #663170,
# 4) protect /var/{run,lock} symlinks for bug 519620
-COLLISION_IGNORE="/lib/modules/*"
-UNINSTALL_IGNORE="/lib/modules/* /var/run /var/lock"
+COLLISION_IGNORE="/boot/dtbs/* /lib/modules/*"
+UNINSTALL_IGNORE="/boot/dtbs/* /lib/modules/* /var/run /var/lock"
# Andreas K. Hüttel (2013-08-23)
# Make emerge messages default to English as per Council decision
--
2.34.1
[gentoo-dev] Re: [PATCH] app-containers: new category
On 01.12.2021 04:46, Georgy Yakovlev wrote: > Discussed in > https://archives.gentoo.org/gentoo-dev/message/67ecdd21af5eaddffd87e6707d54de61 > Signed-off-by: Georgy Yakovlev > --- > app-containers/metadata.xml | 7 +++ > 1 file changed, 7 insertions(+) > create mode 100644 app-containers/metadata.xml > > diff --git a/app-containers/metadata.xml b/app-containers/metadata.xml > new file mode 100644 > index ..c1a2b4e9a74a > --- /dev/null > +++ b/app-containers/metadata.xml > @@ -0,0 +1,7 @@ > + > +https://www.gentoo.org/dtd/metadata.dtd";> > + > + > + The app-containers category contains container related software. > + > + > -- > 2.34.1 > -- Best regards, Georgy modified variant of this merged, also moved: containerd docker-proxy
[gentoo-dev] Last rites: app-shells/ksh-2020.0.0
# Georgy Yakovlev (2021-12-14) # AT&T decided to roll back community changes in March 2020 # for version 2020.x.x # This version is no longer maintained. # New version is maintained at https://github.com/ksh93/ksh # and is available as app-shells/ksh-1.0.0_beta1 at time of writing. ~app-shells/ksh-2020.0.0 -- Best regards, Georgy
[gentoo-dev] [PATCH] app-containers: new category
Discussed in https://archives.gentoo.org/gentoo-dev/message/67ecdd21af5eaddffd87e6707d54de61 Signed-off-by: Georgy Yakovlev --- app-containers/metadata.xml | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 app-containers/metadata.xml diff --git a/app-containers/metadata.xml b/app-containers/metadata.xml new file mode 100644 index ..c1a2b4e9a74a --- /dev/null +++ b/app-containers/metadata.xml @@ -0,0 +1,7 @@ + +https://www.gentoo.org/dtd/metadata.dtd";> + + + The app-containers category contains container related software. + + -- 2.34.1
Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
On 25.11.2021 04:21, Thomas Deutschmann wrote:
> Bug: https://bugs.gentoo.org/825234
> Signed-off-by: Thomas Deutschmann
> ---
> ...adb-database-restore-maybe-required.en.txt | 46 +++
> 1 file changed, 46 insertions(+)
> create mode 100644
> 2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
>
> diff --git
> a/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
>
> b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
> new file mode 100644
> index 000..c4a698e
> --- /dev/null
> +++
> b/2021-11-23-mariadb-database-restore-maybe-required/2021-11-23-mariadb-database-restore-maybe-required.en.txt
> @@ -0,0 +1,46 @@
> +Title: Full MariaDB database restore maybe required
> +Author: Thomas Deutschmann
> +Posted: 2021-11-23
> +Revision: 1
> +News-Item-Format: 2.0
> +Display-If-Installed: dev-db/mariadb
> +Display-If-Installed: sys-cluster/galera
> +
> +On 2021-11-21, a member of the QA project accidentially de-keyworded
Agreed with others in the thread, this is not professional.
> +MariaDB 10.6 to address a file collision, users, who also had latest
> +dev-db/mariadb-connector-c installed, experienced (NOTE: The default
> +MySQL connector in Gentoo Linux is provided by
> +dev-db/mysql-connector-c) [Link 1].
This ^ is a very confusing sentence and is way too long. Needs shortening and
re-wording, too much commas.
> +
> +However, downgrades are not supported in MySQL/MariaDB [Link 2].
> +
> +In case you already fully upgraded to MariaDB 10.6 (which includes
> +executing mysql_upgrade command) and forcefully downgraded your
> +MariaDB instance afterwards during the time window when keywords were
> +removed, you maybe experiencing different problems:
> +
> +At best, your forcefully downgraded MariaDB instance prevented startup
> +so all you have to do is upgrade to MariaDB 10.6 again to resume
> +services.
> +
> +In case previous MariaDB version was able to start, you are encouraged
> +to do a full backup as soon as possible using mysqldump command and
> +manually restore each database ("logical downgrade") to prevent any
> +data corruption.
> +
> +Depending on used feature set and from which version you upgraded,
> +it is maybe required to do a full restore from a previous backup before
> +MariaDB 10.6 upgrade to restore services and prevent any data loss or
> +future runtime errors.
> +
> +In case you are using MariaDB in a cluster and/or Galera setup you
> +probably have to rebuild the entire cluster in case the upgrade to
> +MariaDB 10.6 was already replicated (using pt-table-checksum from
> +dev-db/percona-toolkit can help you to validate your cluster).
> +
> +Keep in mind that due to the forced downgraded, point-in-time recovery
> +may not be available to the extent that you are used to.
> +
> +Link 1: https://bugs.gentoo.org/825234#c8
> +
> +Link 2:
> https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/
> --
> 2.34.0
>
>
--
Best regards,
Georgy
Re: [gentoo-dev] [RFC] Un-slotting LLVM
On 08.11.2021 12:18, Michał Górny wrote: > Hi, > > A few years back I've slotted LLVM and Clang to make the life with > revdeps easier. Long story short, every major LLVM release (which > happens twice a year) breaks API and it takes some time for revdeps to > adjust. Slotting made it possible to install multiple versions > simultaneously, and therefore let "faster" packages use newer LLVM > without being blocked by "slower" packages on the user's system. > > Unfortunately, this ended up pretty bothersome to maintain. Besides > making ebuilds quite complex (and prone to mistakes), I'm hearing more > and more reports of programs being broken through getting multiple LLVM > versions in the link chain. > > This is not something that can be easily solved. In other words, it's > a mess and I don't think we're really getting anywhere. For this > reason, I'm considering dropping slotting and going back to permitting > only a single version of LLVM and Clang being installed. > > This would have two major implications: > > 1. If you installed any package that requires older LLVM, it'd block all > other packages from updating. If you hit two packages that do not have > a common supported LLVM version, you won't be able to install them > at all. > > On the plus side, this will motivate developers to actually start fixing > these packages rather than letting them rot until I start removing old > LLVM versions. > > 2. We will no longer support having multiple clang versions installed. > While it was convenient for testing stuff, it's not really a killer > feature though. > > The only real alternative I see is actively limiting supported LLVM > versions in packages to ensure that all libraries in the depgraph end up > using the same LLVM version. However, I don't think it's really worth > the effort. > > I don't have a ready unslotting plan yet. > > WDYT? > > -- > Best regards, > Michał Górny > > This can block rust and consumers quite badly. Currently in rust source ebuild we lock llvm version for system llvm to exact one bundled by upstream, for example 1.55 - llvm12 (with/without system-llvm set) 1.56 - llvm13 (with/without system-llvm set) that's effective with both system-llvm set or unset, and for rust-bin. in theory I can unlock rust version and provide compatibility with multiple, but we run into next problem: rust-1.56 can come with llvm12 and llvm13, but only llvm13 if -system-llvm rust-bin only can use llvm13 (internal one, pre-compiled by upstream) this will break firefox and spidermonkey and thunderbird on some systems. mozilla products need to be compiled and linked with the same llvm version in all components. compiling/linking firefox with llvm13/clang13, but rust-1.55 will not be possible, because of mis-matched llvm versions. or it may work but break at runtime. and if we have multiple llvm possible in firefox it will not be able to enforce dependency chain via portage. well, we could introduce llvm-ver useflags for rust, and clang, so firefox can require rust[llvm13(-)] clang[llvm13(-)] with a lot of required-use boilerplate, but that's _very_ ugly. -- Best regards, Georgy
[gentoo-dev] RFC: new category for container related packages, instead of app-emulation
Hi, We've been collecting more and more container related packages in app-emulation/* What do you think about finally moving those packages to separate category? probably app-containers/ Here's the tentative list, most tools have description attached for easier review, 36 candidates so far, there may be more around, I only looked at app-emulation. app-emulation/buildah - A tool that facilitates building OCI images app-emulation/cadvisor - container analyzer app-emulation/conmon - An OCI container runtime monitor app-emulation/containerd - A daemon to control runC app-emulation/containers-storage - containers/storage library app-emulation/cri-o - OCI-based implementation of Kubernetes CRI app-emulation/cri-tools - CLI and validation tools for CRI app-emulation/crun - OCI Container Runtime fully written in C app-emulation/distrobuilder - System container image builder for LXC and LXD app-emulation/docker - Main offender app-emulation/docker-bench-security - Test for best docker practices app-emulation/docker-cli - Main offender cli app-emulation/docker-compose - Multi-container orchestration for Docker app-emulation/docker-credential-helpers - app-emulation/docker-gc - Docker garbage collection of containers and images app-emulation/docker-proxy - Docker container networking app-emulation/docker-registry - app-emulation/docker-swarm - app-emulation/flannel - An etcd backed network fabric for containers app-emulation/go-secbench - run and evaluate the docker security benchmark app-emulation/img - Standalone Dockerfile and OCI container image builder app-emulation/k3d - creates k3s clusters in docker app-emulation/kompose - Tool to move from docker-compose to Kubernetes app-emulation/lxc - A userspace interface for the Linux kernel containment app-emulation/lxc-templates - app-emulation/lxd - Fast, dense and secure container management app-emulation/nerdctl - Docker-compatible CLI for containerd app-emulation/podman - Main offender killer app-emulation/reg - Docker registry v2 command line client app-emulation/runc - another docker thing app-emulation/s6-overlay - an s6-based init system for containers app-emulation/sen - Terminal User Interface for docker engine app-emulation/skopeo - Utility for operations on container images/repositories app-emulation/slirp4netns - User-mode networking for unpriv network namespaces app-emulation/snapd - Service and tools for management of snap packages app-emulation/umoci - Manipulation tool for OCI images Those 4 are technically emulation related, so I'm not sure about category: app-emulation/docker-machine app-emulation/docker-machine-kvm app-emulation/hyperd app-emulation/runv signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Monday, August 2, 2021 1:30:07 AM PDT Michał Górny wrote:
> On Mon, 2021-08-02 at 01:28 -0700, Georgy Yakovlev wrote:
> > it can actually check if ebuild calls tmpfiles_process, not only
> > inherit.
> > something like:
> >
> > local pkg_postinst_body="$(declare -fp pkg_postinst)"
> > if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
> > eqawarn "QA Notice: package is installing tmpfiles without
> > calling
> > eqawarn "tmpfiles_process in pkg_postinst phase"
> > fi
> >
> > ofc accounting for edge cases floppym mentioned.
>
> This is going to cause false positives if tmpfiles_process is called via
> another function.
ineed, but seems there are no such cases yet.
simple test (via ripgrep): prints all files calling tmpfiles_process at any
point, and checks if any files from the list do not have a string ^pkg_postinst
it may not catch all ofc, because it does not check where call happens or if
it's actually defined, but I think it's good enough.
rg tmpfiles_process --files-with-matches | xargs rg ^pkg_postinst --files-
without-match
1 result, eclass/tmpfiles.eclass, which is fine.
I think adding body checker outweighs possible edge case yet to happen.
ebuilds not calling it already happened, we fixed some.
for example, logrotate was broken out of the box on systemd.
--
Best regards,
Georgy
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Saturday, July 31, 2021 4:56:34 PM PDT Sam James wrote:
> This adds two tmpfiles related QA checks:
> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> is a deprecated location;
>
> 2) Check whether packages inherit tmpfiles.eclass if they're
> installing files to /usr/lib/tmpfiles.d.
>
> (This helps to catch packages not calling tmpfiles_process
> in pkg_postinst).
>
> Signed-off-by: Sam James
> ---
> metadata/install-qa-check.d/60tmpfiles-paths | 37
> 1 file changed, 37 insertions(+)
> create mode 100644 metadata/install-qa-check.d/60tmpfiles-paths
>
> diff --git a/metadata/install-qa-check.d/60tmpfiles-paths
> b/metadata/install-qa-check.d/60tmpfiles-paths new file mode 100644
> index 0..2c56c031bd1e3
> --- /dev/null
> +++ b/metadata/install-qa-check.d/60tmpfiles-paths
> @@ -0,0 +1,37 @@
> +# Copyright 2021 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# QA check: ensure that packages installing tmpfiles configuration inherit
> the eclass +# Maintainer: Sam James
> +
> +# Implements two checks:
> +# 1) Installation to /etc/tmpfiles.d (which is a deprecated location);
> +# 2) Installation of any tmpfiles to /usr/lib/tmpfiles.d without inheriting
> the eclass +#(needed for tmpfiles_process in pkg_postinst)
> +tmpfiles_check() {
> + # Check 1
> + # Scan image for files in /etc/tmpfiles.d which is a deprecated
location
> + if [[ -d "${ED}"/etc/tmpfiles.d/ ]] ; then
> + eqawarn "QA Notice: files installed to the deprecated /etc/
tmpfiles.d
> location" + eqawarn "tmpfiles configuration files must be
installed to
> /usr/lib/tmpfiles.d!" + fi
> +
> + # Check 2
> + # We're now going to check for whether we install files to
> /usr/lib/tmpfiles.d without + # inheriting the eclass (weak catch for
> ebuilds not calling tmpfiles_process in pkg_postinst) +
> + # No need to carry on if we're inheriting the eclass
> + if has tmpfiles ${INHERITED} ; then
> + return
it can actually check if ebuild calls tmpfiles_process, not only inherit.
something like:
local pkg_postinst_body="$(declare -fp pkg_postinst)"
if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
eqawarn "QA Notice: package is installing tmpfiles without calling
eqawarn "tmpfiles_process in pkg_postinst phase"
fi
ofc accounting for edge cases floppym mentioned.
> + fi
> +
> + if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
> + eqawarn "QA Notice: package is installing tmpfiles without
inheriting
> tmpfiles.eclass!" + eqawarn "Packages must inherit tmpfiles.eclass
then
> call tmpfiles_process in pkg_postinst." + fi
> +}
> +
> +tmpfiles_check
> +: # guarantee successful exit
> +
> +# vim:ft=sh
--
Best regards,
Georgy
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH v2 5/5] check-reqs.eclass: Repl. I_KNOW_WHAT_I_AM_DOING w/ CHECKREQS_DONOTHING
On 23.07.2021 08:58, Andreas Sturmlechner wrote: > Signed-off-by: Andreas Sturmlechner > --- > eclass/check-reqs.eclass | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass > index 39e4bad1363..836dd0d4a1f 100644 > --- a/eclass/check-reqs.eclass > +++ b/eclass/check-reqs.eclass > @@ -68,6 +68,13 @@ _CHECK_REQS_ECLASS=1 > # @DESCRIPTION: > # How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M > > +# @ECLASS-VARIABLE: CHECKREQS_DONOTHING > +# @USER_VARIABLE > +# @DEFAULT_UNSET > +# @DESCRIPTION: > +# Do not error out in _check-reqs_output if requirements are not met. > +# This is a user flag and should under _no circumstances_ be set in the > ebuild. ...snip... note that developer profiles set I_KNOW_WHAT_I_AM_DOING="yes" by default in profiles/targets/developer/make.defaults I don't know if anyone seriously using this profile though. -- Best regards, Georgy
[gentoo-dev] [PATCH] 2021-07-17-new-ppc64-profiles: add new item
a lot of text taken from 17.1 profile news item: 2019-06-05-amd64-17-1-profiles-are-now-stable.en.txt Bug: https://bugs.gentoo.org/640184 Bug: https://bugs.gentoo.org/715680 --- .../2021-07-17-new-ppc64-profiles.en.txt | 78 +++ 1 file changed, 78 insertions(+) create mode 100644 2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt diff --git a/2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt b/2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt new file mode 100644 index 000..6344963 --- /dev/null +++ b/2021-07-17-new-ppc64-profiles/2021-07-17-new-ppc64-profiles.en.txt @@ -0,0 +1,78 @@ +Title: new ppc64 profiles +Author: Georgy Yakovlev +Posted: 2021-07-17 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/desktop +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome/systemd +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/developer + +A new set of ppc64 profiles has been added to the Gentoo +repository in Jan 2020. These profiles switch to a more standard +'no SYMLINK_LIB' multilib layout, and require explicit migration as +described below. They are considered stable at the moment, and we would +like to request all users to upgrade their systems. The old profiles +will be deprecated in the near future. + +In the new profiles, the lib->lib64 compatibility symlink is removed. +64-bit libraries need to be installed directly to lib64. /lib +and /usr/lib become real directories, that are used for cross-arch +and native non-library packages (gcc, clang). + +The migration is performed using app-portage/unsymlink-lib tool. +The following steps can be used to upgrade your system: + +1. Sync and upgrade your system to the newest package versions + to reduce the risk of issues. + +2. Install the tool: + + # emerge -1v app-portage/unsymlink-lib + +3. Run 'unsymlink-lib --analyze' and check the output for obvious + mistakes. If you need to perform any changes to the system, remember + to run 'unsymlink-lib --analyze' again afterwards. + +[past this point do not call emerge or modify /usr manually] + +4. This is a very good time to make a backup. + +5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see + what is going to happen. + +6. Reboot your system. Check if important programs work. + In particular, verify that e.g. 'emerge --info' works (but do not + install anything). If you hit any serious problems, you can use + 'unsymlink-lib --rollback' to revert the changes and return to + step 4. + +7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see + what is going to happen but note that you're going to see a very long + list of files to remove. + +8. Switch the profile, e.g.: + + # eselect profile set default/linux/ppc64/17.0 + +[at this point you can start using emerge again] + +9. Rebuild the toolchain: + + # emerge -1v sys-devel/gcc:10 + [ repeat for other slots you will be using ] + # emerge -1v sys-devel/binutils + # emerge -1v sys-libs/glibc + +For known issues, please see bugs #506276 [2] and #640184[3] . +If you have any problems with the new profiles or the migration procedure, +please report a bug and make it block the tracker. + +For more information on the layout, please see the wiki article +on AMD64 multilib layouts [4], it applies to PPC64 as well. + +[1] https://gentoo.org/support/news-items/2017-11-30-new-17-profiles.html +[2] https://bugs.gentoo.org/506276 +[3] https://bugs.gentoo.org/640184 +[4] https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout -- 2.32.0
[gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
This reverts commit a93dbc1701de3b983c6f791391f7967d4b919b4a. and addresses some feedback items --- .../2021-07-09-systemd-tmpfiles.en.txt| 66 +++ 1 file changed, 66 insertions(+) create mode 100644 2021-07-09-systemd-tmpfiles/2021-07-09-systemd-tmpfiles.en.txt diff --git a/2021-07-09-systemd-tmpfiles/2021-07-09-systemd-tmpfiles.en.txt b/2021-07-09-systemd-tmpfiles/2021-07-09-systemd-tmpfiles.en.txt new file mode 100644 index 000..e902a3b --- /dev/null +++ b/2021-07-09-systemd-tmpfiles/2021-07-09-systemd-tmpfiles.en.txt @@ -0,0 +1,66 @@ +Title: opentmpfiles deprecation +Author: Georgy Yakovlev +Author: Sam James +Posted: 2021-07-09 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/opentmpfiles +Display-If-Installed: sys-apps/systemd-tmpfiles + +A tmpfiles [0] implementation provides a generic mechanism to define +the creation of regular files, directories, pipes, and device nodes, +adjustments to their access mode, ownership, attributes, quota +assignments, and contents, and finally their time-based removal. +It is commonly used for volatile and temporary files and directories +such as those located under /run/, /tmp/, /var/tmp/, the API file +systems such as /sys/ or /proc/, as well as some other directories +below /var/. [1] + +On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a +root privilege escalation vulnerability (CVE-2017-18925 [2], +bug #751415 [3], issue 4 [4] upstream). + +The use of opentmpfiles is discouraged by its maintainer due to the +unpatched vulnerability and other long-standing bugs [5]. + +Users will start seeing their package manager trying to replace +sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is +another provider of virtual/tmpfiles. + +Despite the name, 'systemd-tmpfiles' does not depend on systemd, does +not use dbus, and is just a drop-in replacement for opentmpfiles. It is +a small binary built from systemd source code, but works separately, +similarly to eudev or elogind. It is known to work on both glibc and +musl systems. + +Note that systemd-tmpfiles is specifically for non-systemd systems. It +is intended to be used on an OpenRC system. + +If you wish to selectively test systemd-tmpfiles, follow those steps: + + 1. # emerge --oneshot sys-apps/systemd-tmpfiles + 2. # reboot + 3. # rm /etc/runlevels/boot/opentmpfiles-setup + 4. # rm /etc/runlevels/sysinit/opentmpfiles-dev + +No other steps required. + +If, after reviewing the linked bug reference for opentmpfiles, you feel +your system is not vulnerable/applicable to the attack described, you +can unmask [6] opentmpfiles at your own risk: + + 1. In /etc/portage/package.unmask, add a line: + sys-apps/opentmpfiles + 2. # emerge --oneshot sys-apps/opentmpfiles + +Note that opentmpfiles is likely to be removed from gentoo repository +in the future. + +[0] https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html +[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html +[2] https://nvd.nist.gov/vuln/detail/CVE-2017-18925 +[3] https://bugs.gentoo.org/751415 +[4] https://github.com/OpenRC/opentmpfiles/issues/4 +[5] https://archives.gentoo.org/gentoo-dev/message/bce91b9d37db0b1e0980eb923a8607c9 +[6] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package + -- 2.32.0
[gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: restore news item
This reverts commit a93dbc1701de3b983c6f791391f7967d4b919b4a. and addresses some feedback items --- .../2021-07-07-systemd-tmpfiles.en.txt| 66 +++ 1 file changed, 66 insertions(+) create mode 100644 2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt diff --git a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt new file mode 100644 index 000..7167985 --- /dev/null +++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt @@ -0,0 +1,66 @@ +Title: opentmpfiles deprecation +Author: Georgy Yakovlev +Author: Sam James +Posted: 2021-07-09 +Revision: 2 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/opentmpfiles +Display-If-Installed: sys-apps/systemd-tmpfiles + +A tmpfiles [0] implementation provides a generic mechanism to define +the creation of regular files, directories, pipes, and device nodes, +adjustments to their access mode, ownership, attributes, quota +assignments, and contents, and finally their time-based removal. +It is commonly used for volatile and temporary files and directories +such as those located under /run/, /tmp/, /var/tmp/, the API file +systems such as /sys/ or /proc/, as well as some other directories +below /var/. [1] + +On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a +root privilege escalation vulnerability (CVE-2017-18925 [2], +bug #751415 [3], issue 4 [4] upstream). + +The use of opentmpfiles is discouraged by its maintainer due to the +unpatched vulnerability and other long-standing bugs [5]. + +Users will start seeing their package manager trying to replace +sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is +another provider of virtual/tmpfiles. + +Despite the name, 'systemd-tmpfiles' does not depend on systemd, does +not use dbus, and is just a drop-in replacement for opentmpfiles. It is +a small binary built from systemd source code, but works separately, +similarly to eudev or elogind. It is known to work on both glibc and +musl systems. + +Note that systemd-tmpfiles is specifically for non-systemd systems. It +is intended to be used on an OpenRC system. + +If you wish to selectively test systemd-tmpfiles, follow those steps: + + 1. # emerge --oneshot sys-apps/systemd-tmpfiles + 2. # reboot + 3. # rm /etc/runlevels/boot/opentmpfiles-setup + 4. # rm /etc/runlevels/sysinit/opentmpfiles-dev + +No other steps required. + +If, after reviewing the linked bug reference for opentmpfiles, you feel +your system is not vulnerable/applicable to the attack described, you +can unmask [6] opentmpfiles at your own risk: + + 1. In /etc/portage/package.unmask, add a line: + -sys-apps/opentmpfiles- + 2. # emerge --oneshot sys-apps/opentmpfiles + +Note that opentmpfiles is likely to be removed from gentoo repository +in the future. + +[0] https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html +[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html +[2] https://nvd.nist.gov/vuln/detail/CVE-2017-18925 +[3] https://bugs.gentoo.org/751415 +[4] https://github.com/OpenRC/opentmpfiles/issues/4 +[5] https://archives.gentoo.org/gentoo-dev/message/bce91b9d37db0b1e0980eb923a8607c9 +[6] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package + -- 2.32.0
Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item
On 09.07.2021 13:57, Ulrich Mueller wrote: > >>>>> On Fri, 09 Jul 2021, Georgy Yakovlev wrote: > > > Already pushed as is. > > So as far as I can see, you've posted it for review at 02:38:05 today, > and pushed it at 08:25:55? > > That is less than the 72 hours mandated by GLEP 42, so definitely > not OK. That pr@ wasn't CCed isn't helpful either. > > Ulrich Sorry about not CC-ing and making title longer than 50. But sure, let's revert and wait 3 days, instead of sending an explanation to users who may need it now. Let's wait till more topics on forums created, and let our IRC support guys do more work explaining it to people. Makes sense. -- Best regards, Georgy signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item
On 09.07.2021 08:50, Tomas Mozes wrote: > On Fri, Jul 9, 2021 at 4:38 AM Georgy Yakovlev wrote: > > > Signed-off-by: Sam James > > Signed-off-by: Georgy Yakovlev > > --- > > .../2021-07-07-systemd-tmpfiles.en.txt| 48 +++ > > 1 file changed, 48 insertions(+) > > create mode 100644 > > 2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt > > > > diff --git > > a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt > > b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt > > new file mode 100644 > > index 000..0960663 > > --- /dev/null > > +++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt ...snip > > + > > + 1. # emerge --oneshot sys-apps/systemd-tmpfiles > > + 2. # reboot > > + > > +No other steps required. > > + ...snip > Plus maybe removing these dead symlinks: > /etc/runlevels/boot/opentmpfiles-setup > /etc/runlevels/sysinit/opentmpfiles-dev added, thanks. -- Best regards, Georgy signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item
On 09.07.2021 09:11, Michał Górny wrote: > On Thu, 2021-07-08 at 21:43 -0700, Georgy Yakovlev wrote: > > Signed-off-by: Sam James > > Signed-off-by: Georgy Yakovlev > > --- > > .../2021-07-07-systemd-tmpfiles.en.txt| 64 +++ > > 1 file changed, 64 insertions(+) > > create mode 100644 > > 2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt > > > > diff --git a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt > > b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt > > new file mode 100644 > > index 000..e946c89 > > --- /dev/null > > +++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt ... snip > > +Note that systemd-tmpfiles is specifically for non-systemd systems. It > > +is intended to be used on an OpenRC system. > > Maybe it'd be worth adding a sentence that systemd itself provides > the utility on systemd systems. Already pushed as is. It should not be shown to systemd users anyway, so no big losss. > -- > Best regards, > Michał Górny > > -- Best regards, Georgy signature.asc Description: PGP signature
[gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item
Signed-off-by: Sam James Signed-off-by: Georgy Yakovlev --- .../2021-07-07-systemd-tmpfiles.en.txt| 64 +++ 1 file changed, 64 insertions(+) create mode 100644 2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt diff --git a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt new file mode 100644 index 000..e946c89 --- /dev/null +++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt @@ -0,0 +1,64 @@ +Title: systemd-tmpfiles replaces opentmpfiles due to security issues +Author: Georgy Yakovlev +Author: Sam James +Posted: 2021-07-07 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/opentmpfiles +Display-If-Installed: sys-apps/systemd-tmpfiles + +A tmpfiles [0] implementation provides a generic mechanism to define +the creation of regular files, directories, pipes, and device nodes, +adjustments to their access mode, ownership, attributes, quota +assignments, and contents, and finally their time-based removal. +It is commonly used for volatile and temporary files and directories +such as those located under /run/, /tmp/, /var/tmp/, the API file +systems such as /sys/ or /proc/, as well as some other directories +below /var/. [1] + +On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a +root privilege escalation vulnerability (CVE-2017-18925 [2], +bug #751415 [3], issue 4 [4] upstream). + +The use of opentmpfiles is discouraged by its maintainer due to the +unpatched vulnerability and other long-standing bugs [5]. + +Users will start seeing their package manager trying to replace +sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is +another provider of virtual/tmpfiles. + +Despite the name, 'systemd-tmpfiles' does not depend on systemd, does +not use dbus, and is just a drop-in replacement for opentmpfiles. It is +a small binary built from systemd source code, but works separately, +similarly to eudev or elogind. It is known to work on both glibc and +musl systems. + +Note that systemd-tmpfiles is specifically for non-systemd systems. It +is intended to be used on an OpenRC system. + +If you wish to selectively test systemd-tmpfiles, follow those steps: + + 1. # emerge --oneshot sys-apps/systemd-tmpfiles + 2. # reboot + +No other steps required. + +If, after reviewing the linked bug reference for opentmpfiles, you feel +your system is not vulnerable/applicable to the attack described, you +can unmask [6] opentmpfiles at your own risk: + + 1. In /etc/portage/package.unmask, add a line: + -sys-apps/opentmpfiles- + 2. # emerge --oneshot sys-apps/opentmpfiles + +Note that opentmpfiles is likely to be removed from gentoo repository +in the future. + +[0] https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html +[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html +[2] https://nvd.nist.gov/vuln/detail/CVE-2017-18925 +[3] https://bugs.gentoo.org/751415 +[4] https://github.com/OpenRC/opentmpfiles/issues/4 +[5] https://bugs.gentoo.org/741216 +[6] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package + -- 2.32.0
[gentoo-dev] [PATCH] 2021-07-07-systemd-tmpfiles: add news item
Signed-off-by: Sam James Signed-off-by: Georgy Yakovlev --- .../2021-07-07-systemd-tmpfiles.en.txt| 48 +++ 1 file changed, 48 insertions(+) create mode 100644 2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt diff --git a/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt new file mode 100644 index 000..0960663 --- /dev/null +++ b/2021-07-07-systemd-tmpfiles/2021-07-07-systemd-tmpfiles.en.txt @@ -0,0 +1,48 @@ +Title: systemd-tmpfiles replaces opentmpfiles due to security issues +Author: Georgy Yakovlev +Author: Sam James +Posted: 2021-07-07 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: virtual/tmpfiles + +On 2021-07-06, the sys-apps/opentmpfiles package was masked due to a +root privilege escalation vulnerability (CVE-2017-18925 [0], +bug #751415 [1], issue 4 [2] upstream). + +The use of opentmpfiles is discouraged by its maintainer due to the +unpatched vulnerability and other long-standing bugs [3]. + +Users will start seeing their package manager trying to replace +sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is +another provider of virtual/tmpfiles. + +Despite the name, 'systemd-tmpfiles' does not depend on systemd, does +not use dbus, and is just a drop-in replacement for opentmpfiles. It is +a small binary built from systemd source code, but works separately, +similarly to eudev or elogind. It is known to work on both glibc and +musl systems. + +Note that systemd-tmpfiles is specifically for non-systemd systems. It +is intended to be used on an OpenRC system. + +If you wish to selectively test systemd-tmpfiles, follow those steps: + + 1. # emerge --oneshot sys-apps/systemd-tmpfiles + 2. # reboot + +No other steps required. + +If, after reviewing the linked bug reference for opentmpfiles, you feel +your system is not vulnerable/applicable to the attack described, you +can unmask[4] opentmpfiles at your own risk: + +1. In /etc/portage/package.unmask, add: +-sys-apps/opentmpfiles +2. # emerge --oneshot sys-apps/opentmpfiles + +[0] https://nvd.nist.gov/vuln/detail/CVE-2017-18925 +[1] https://bugs.gentoo.org/751415 +[2] https://github.com/OpenRC/opentmpfiles/issues/4 +[3] https://bugs.gentoo.org/741216 +[4] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package -- 2.32.0
[gentoo-dev] [PATCH 2/2] cargo.eclass: make CRATES an eclass variable
it's needed to be present in all ebuilds for
crate auditing tools to work properly.
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 17 +
1 file changed, 17 insertions(+)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 9923b1c9deb2..50237d302ce6 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -1,409 +1,426 @@
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: cargo.eclass
# @MAINTAINER:
# r...@gentoo.org
# @AUTHOR:
# Doug Goldstein
# Georgy Yakovlev
# @SUPPORTED_EAPIS: 7 8
# @BLURB: common functions and variables for cargo builds
if [[ -z ${_CARGO_ECLASS} ]]; then
_CARGO_ECLASS=1
# check and document RUST_DEPEND and options we need below in case conditions.
# https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md
RUST_DEPEND="virtual/rust"
case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
7)
# 1.37 added 'cargo vendor' subcommand and net.offline config
knob
RUST_DEPEND=">=virtual/rust-1.37.0"
;;
8)
# 1.39 added --workspace
# 1.46 added --target dir
# 1.48 added term.progress config option
# 1.51 added split-debuginfo profile option
# 1.52 may need setting RUSTC_BOOTSTRAP envvar for some crates
# 1.53 added cargo update --offline, can be used to update
vulnerable crates from pre-fetched registry without editing toml
RUST_DEPEND=">=virtual/rust-1.53"
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac
inherit multiprocessing toolchain-funcs
if [[ ! ${CARGO_OPTIONAL} ]]; then
BDEPEND="${RUST_DEPEND}"
EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install
src_test
fi
IUSE="${IUSE} debug"
ECARGO_HOME="${WORKDIR}/cargo_home"
ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
+# @ECLASS-VARIABLE: CRATES
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# bash string containing all crates package wants to download
+# used by cargo_crate_uris()
+# Example:
+# @CODE
+# CRATES="
+# metal-1.2.3
+# bar-4.5.6
+# iron_oxide-0.0.1
+# "
+# inherit cargo
+# ...
+# SRC_URI="$(cargo_crate_uris ${CRATES})"
+# @CODE
+
# @ECLASS-VARIABLE: CARGO_OPTIONAL
# @DEFAULT_UNSET
# @PRE_INHERIT
# @DESCRIPTION:
# If set to a non-null value, before inherit cargo part of the ebuild will
# be considered optional. No dependencies will be added and no phase
# functions will be exported.
#
# If you enable CARGO_OPTIONAL, you have to set BDEPEND on virtual/rust
# for your package and call at least cargo_gen_config manually before using
# other src_ functions of this eclass.
# note that cargo_gen_config is automatically called by cargo_src_unpack.
# @ECLASS_VARIABLE: myfeatures
# @DEFAULT_UNSET
# @DESCRIPTION:
# Optional cargo features defined as bash array.
# Should be defined before calling cargo_src_configure().
#
# Example package that has x11 and wayland as features, and disables default.
# @CODE
# src_configure() {
# local myfeatures=(
# $(usex X x11 '')
# $(usev wayland)
# )
# cargo_src_configure --no-default-features
# }
# @CODE
# @ECLASS-VARIABLE: ECARGO_REGISTRY_DIR
# @USER_VARIABLE
# @DEFAULT_UNSET
# @DESCRIPTION:
# Storage directory for cargo registry.
# Used by cargo_live_src_unpack to cache downloads.
# This is intended to be set by users.
# Ebuilds must not set it.
#
# Defaults to "${DISTDIR}/cargo-registry" it not set.
# @ECLASS-VARIABLE: ECARGO_OFFLINE
# @USER_VARIABLE
# @DEFAULT_UNSET
# @DESCRIPTION:
# If non-empty, this variable prevents online operations in
# cargo_live_src_unpack.
# Inherits value of EVCS_OFFLINE if not set explicitly.
# @ECLASS-VARIABLE: EVCS_UMASK
# @USER_VARIABLE
# @DEFAULT_UNSET
# @DESCRIPTION:
# Set this variable to a custom umask. This is intended to be set by
# users. By setting this to something like 002, it can make life easier
# for people who use cargo in a home directory, but are in the portage
# group, and then switch over to building with FEATURES=userpriv.
# Or vice-versa.
# @FUNCTION: cargo_crate_uris
# @DESCRIPTION:
# Generates the URIs to put in SRC_URI to help fetch dependencies.
cargo_crate_uris() {
local -r regex='^([a-zA-Z0-9_\-]+)-([0-9]+\.[0-9]+\.[0-9]+.*)$'
local crate
for crate in "$@"; do
local name version url
[[ $crate =~ $regex ]] || die "Could not parse name and version
from crate: $crate"
name="${BASH_REMATC
[gentoo-dev] [PATCH 1/2] cargo.eclass: support EAPI=8, misc changes
remove cargo-snapshot* unpacker, it was needed
for separate dev-util/cargo we used to have.
Bug: https://bugs.gentoo.org/715890
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 15b9d455bdef..9923b1c9deb2 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -1,396 +1,409 @@
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: cargo.eclass
# @MAINTAINER:
# r...@gentoo.org
# @AUTHOR:
# Doug Goldstein
# Georgy Yakovlev
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: common functions and variables for cargo builds
if [[ -z ${_CARGO_ECLASS} ]]; then
_CARGO_ECLASS=1
-# we need this for 'cargo vendor' subcommand and net.offline config knob
-RUST_DEPEND=">=virtual/rust-1.37.0"
+# check and document RUST_DEPEND and options we need below in case conditions.
+# https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md
+RUST_DEPEND="virtual/rust"
case "${EAPI:-0}" in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
7)
+ # 1.37 added 'cargo vendor' subcommand and net.offline config
knob
+ RUST_DEPEND=">=virtual/rust-1.37.0"
+ ;;
+
+ 8)
+ # 1.39 added --workspace
+ # 1.46 added --target dir
+ # 1.48 added term.progress config option
+ # 1.51 added split-debuginfo profile option
+ # 1.52 may need setting RUSTC_BOOTSTRAP envvar for some crates
+ # 1.53 added cargo update --offline, can be used to update
vulnerable crates from pre-fetched registry without editing toml
+ RUST_DEPEND=">=virtual/rust-1.53"
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac
inherit multiprocessing toolchain-funcs
if [[ ! ${CARGO_OPTIONAL} ]]; then
BDEPEND="${RUST_DEPEND}"
EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install
src_test
fi
IUSE="${IUSE} debug"
ECARGO_HOME="${WORKDIR}/cargo_home"
ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
# @ECLASS-VARIABLE: CARGO_OPTIONAL
# @DEFAULT_UNSET
# @PRE_INHERIT
# @DESCRIPTION:
# If set to a non-null value, before inherit cargo part of the ebuild will
# be considered optional. No dependencies will be added and no phase
# functions will be exported.
#
# If you enable CARGO_OPTIONAL, you have to set BDEPEND on virtual/rust
# for your package and call at least cargo_gen_config manually before using
# other src_ functions of this eclass.
# note that cargo_gen_config is automatically called by cargo_src_unpack.
# @ECLASS_VARIABLE: myfeatures
# @DEFAULT_UNSET
# @DESCRIPTION:
# Optional cargo features defined as bash array.
# Should be defined before calling cargo_src_configure().
#
# Example package that has x11 and wayland as features, and disables default.
# @CODE
# src_configure() {
# local myfeatures=(
# $(usex X x11 '')
# $(usev wayland)
# )
# cargo_src_configure --no-default-features
# }
# @CODE
# @ECLASS-VARIABLE: ECARGO_REGISTRY_DIR
# @USER_VARIABLE
# @DEFAULT_UNSET
# @DESCRIPTION:
# Storage directory for cargo registry.
# Used by cargo_live_src_unpack to cache downloads.
# This is intended to be set by users.
# Ebuilds must not set it.
#
# Defaults to "${DISTDIR}/cargo-registry" it not set.
# @ECLASS-VARIABLE: ECARGO_OFFLINE
# @USER_VARIABLE
# @DEFAULT_UNSET
# @DESCRIPTION:
# If non-empty, this variable prevents online operations in
# cargo_live_src_unpack.
# Inherits value of EVCS_OFFLINE if not set explicitly.
# @ECLASS-VARIABLE: EVCS_UMASK
# @USER_VARIABLE
# @DEFAULT_UNSET
# @DESCRIPTION:
# Set this variable to a custom umask. This is intended to be set by
# users. By setting this to something like 002, it can make life easier
# for people who use cargo in a home directory, but are in the portage
# group, and then switch over to building with FEATURES=userpriv.
# Or vice-versa.
# @FUNCTION: cargo_crate_uris
# @DESCRIPTION:
# Generates the URIs to put in SRC_URI to help fetch dependencies.
cargo_crate_uris() {
local -r regex='^([a-zA-Z0-9_\-]+)-([0-9]+\.[0-9]+\.[0-9]+.*)$'
local crate
for crate in "$@"; do
local name version url
[[ $crate =~ $regex ]] || die "Could not parse name and version
from crate: $crate"
name="${BASH_REMATCH[1]}"
version="${BASH_REMATCH[2]}"
url="https://c
[gentoo-dev] [PATCH] metadata/install-qa-check.d: add virtual/libcrypt dep check
Bug: https://bugs.gentoo.org/699422
Signed-off-by: Georgy Yakovlev
---
metadata/install-qa-check.d/60libcrypt-deps | 38 +
1 file changed, 38 insertions(+)
create mode 100644 metadata/install-qa-check.d/60libcrypt-deps
diff --git a/metadata/install-qa-check.d/60libcrypt-deps
b/metadata/install-qa-check.d/60libcrypt-deps
new file mode 100644
index ..fd915fb852d7
--- /dev/null
+++ b/metadata/install-qa-check.d/60libcrypt-deps
@@ -0,0 +1,38 @@
+# Copyright 2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that package specifies a dependency on virtual/libcrypt
+# Author: Georgy Yakovlev
+# Maintainer Sam James
+
+libcrypt_check() {
+ if ! type -P scanelf >/dev/null || has binchecks ${PORTAGE_RESTRICT};
then
+ return
+ fi
+
+ # nothing to do here
+ if grep -q virtual/libcrypt <<<${RDEPEND}; then
+ return
+ fi
+
+ local libcrypt_consumers
+ # grep outputs newline separated list of files, so it's ok to skip
specifying delimiter
+ IFS= mapfile libcrypt_consumers < <(find "${ED}" -type f -executable \
+ -print0 | xargs -0 scanelf -qyRF '%F %n' | grep 'libcrypt.so'
2>/dev/null )
+
+ if [[ -n ${libcrypt_consumers[@]} ]]; then
+ eqawarn "Binary files linked to libcrypt.so found"
+ eqawarn "But dependency on virtual/libcrypt is not declared"
+ eqawarn
+ eqatag -v virtual-libcrypt.missing "${libcrypt_consumers[@]%%
*}"
+ eqawarn
+ eqawarn "Please add virtual/libcrypt dependency"
+ eqawarn "Gentoo Bug: https://bugs.gentoo.org/699422";
+ fi
+
+}
+
+libcrypt_check
+: # guarantee successful exit
+
+# vim:ft=sh
--
2.32.0
[gentoo-dev] [PATCH] metadata/install-qa-check.d: add virtual/libcrypt dep check
Bug: https://bugs.gentoo.org/699422
Signed-off-by: Georgy Yakovlev
---
metadata/install-qa-check.d/60libcrypt-deps | 38 +
1 file changed, 38 insertions(+)
create mode 100644 metadata/install-qa-check.d/60libcrypt-deps
diff --git a/metadata/install-qa-check.d/60libcrypt-deps
b/metadata/install-qa-check.d/60libcrypt-deps
new file mode 100644
index ..bc7b8d3dced2
--- /dev/null
+++ b/metadata/install-qa-check.d/60libcrypt-deps
@@ -0,0 +1,38 @@
+# Copyright 2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that package specifies a dependency on virtual/libcrypt
+# Author: Georgy Yakovlev
+# Maintainer Sam James
+
+libcrypt_check() {
+ if ! type -P scanelf >/dev/null || has binchecks ${PORTAGE_RESTRICT};
then
+ return
+ fi
+
+ # nothing to do here
+ if grep -q virtual/libcrypt <<<${RDEPEND}; then
+ return
+ fi
+
+ local libcrypt_consumers
+ # grep outputs newline separated list of files, so it's ok to skip
specifying delimiter
+ IFS= mapfile libcrypt_consumers < <(find "${ED}" -type f -executable \
+ -print0 | xargs -0 scanelf -qyRF '%F %n' {} + | grep
'libcrypt.so' 2>/dev/null )
+
+ if [[ -n ${libcrypt_consumers[@]} ]]; then
+ eqawarn "Binary files linked to libcrypt.so found"
+ eqawarn "But dependency on virtual/libcrypt is not declared"
+ eqawarn
+ eqatag -v virtual-libcrypt.missing "${libcrypt_consumers[@]%%
*}"
+ eqawarn
+ eqawarn "Please add virtual/libcrypt dependency"
+ eqawarn "Gentoo Bug: https://bugs.gentoo.org/699422";
+ fi
+
+}
+
+libcrypt_check
+: # guarantee successful exit
+
+# vim:ft=sh
--
2.32.0
[gentoo-dev] Last-rites: sys-apps/timer_entropyd
# Georgy Yakovlev (2011-05-15) # Dead upstream, homepage missing, EAPI=5, no systemd units. # https://bugs.gentoo.org/790413 , #434900, #552760 # Use any of or combination of the following instead: # sys-apps/rng-tools # sys-apps/haveged # app-crypt/jitterentropy-rngd sys-apps/timer_entropyd -- Best regards, Georgy signature.asc Description: PGP signature
Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)
On 22.04.2021 10:22, Miroslav Šulc wrote: > Dne 22. 04. 21 v 8:37 Kaibo Ma napsal(a): > > Is there a tracking issue for Java 11 on Bugzilla? > > > > Kaibo Ma > > this is it: https://bugs.gentoo.org/697014 created an alias for it, also can be found as https://bugs.gentoo.org/show_bug.cgi?id=jdk11 and simply searching for jdk11 in the search field > > fordfrog > > > -- Best regards, Georgy signature.asc Description: PGP signature
[gentoo-dev] [PATCH 2/2] profiles/info_pkgs: print rust{,-bin} versions
Bug: https://bugs.gentoo.org/756340 Signed-off-by: Georgy Yakovlev --- profiles/info_pkgs | 2 ++ 1 file changed, 2 insertions(+) diff --git a/profiles/info_pkgs b/profiles/info_pkgs index 9c12cc958ac7..650516bcf853 100644 --- a/profiles/info_pkgs +++ b/profiles/info_pkgs @@ -17,6 +17,8 @@ sys-devel/libtool sys-devel/make dev-lang/python dev-lang/perl +dev-lang/rust +dev-lang/rust-bin sys-apps/sandbox dev-util/ccache sys-devel/gcc -- 2.31.1
[gentoo-dev] [PATCH 1/2] profiles/info_vars: print RUSTFLAGS as well
Bug: https://bugs.gentoo.org/756340 Signed-off-by: Georgy Yakovlev --- profiles/info_vars | 1 + 1 file changed, 1 insertion(+) diff --git a/profiles/info_vars b/profiles/info_vars index b578103d116a..051948c1e8ef 100644 --- a/profiles/info_vars +++ b/profiles/info_vars @@ -34,6 +34,7 @@ PORTAGE_CONFIGROOT PORTAGE_TMPDIR PORTDIR PORTDIR_OVERLAY +RUSTFLAGS SYNC USE PORTAGE_RSYNC_OPTS -- 2.31.1
Re: [gentoo-dev] Packages up for grabs: telegram-desktop & deps
On 28.02.2021 12:21, Georgy Yakovlev wrote: > The following packages are for grabs: > > net-im/telegram-desktop > media-libs/libtgvoip ( no other revdeps ) > media-libs/tg_owt ( no other revdeps ) > dev-cpp/range-v3 ( has another revdep, not only tg ) > > Many bugs open and many issues. > > Before you try to take it over, here's some info for future maintainers: > 0. you better speak Russian to be able to reach devs =) optional, but VERY > beneficial. I can connect you to developer group. > > 1. expect to deal with a lot of bundling, no releases, submodules and all > related packaging issues with this approach. > > 2. expect pretty aggressive userbase, very direct, even brutally so. > > 3. expect dependency fights between wayland-only crowd and x11-only crowd. > > 4. same as above but for pulse vs alsa. > > 5. same as above but openssl vs libressl (this one should be easier nowadays > as support is going away) > > 6. project is split into 4 repos basically, 1 for app, 1 for webrtc, 1 for > cmake files, 1 for audio lib. there are no releases for any except tdesktop > itself. > > 7. expect to read a lot of cmake cross-referenced across all those 4 repos. > > 8. expect to be able to patch cmake a lot. for example one can't toggle off > automagic deps. > > 9. expect to collaborate with other disto developers, who also work on > mentioned tasks. rpmfusion and freebsd guys are very helpful and solve same > problems as we do. > > > If you are still reading - reach out, I'll help to get started. > I don't have time to maintain it anymore, so it either should be removed or > go into caring hands, as it needs A LOT OF CARE. > > https://bugs.gentoo.org/buglist.cgi?quicksearch=telegram-desktop > -- > Best regards, > Georgy Since this message made it to some news websites, I'd like to send a follow-up with a positive resolution. tdesktop have finally found a caring person and is now proxy-maintained. we've got an update that fixes quite a lot of issues, including audio call crashes under some conditions and work on unbundling critical libraries is in progress. it will remain in the tree, I'm proxying and still testing it on non-amd64 arches (forcing SSE2 is not nice). stabilization of new versions will happen sooner than later. Have a nice day ;-) -- Best regards, Georgy signature.asc Description: PGP signature
[gentoo-dev] Packages up for grabs: telegram-desktop & deps
The following packages are for grabs: net-im/telegram-desktop media-libs/libtgvoip ( no other revdeps ) media-libs/tg_owt ( no other revdeps ) dev-cpp/range-v3 ( has another revdep, not only tg ) Many bugs open and many issues. Before you try to take it over, here's some info for future maintainers: 0. you better speak Russian to be able to reach devs =) optional, but VERY beneficial. I can connect you to developer group. 1. expect to deal with a lot of bundling, no releases, submodules and all related packaging issues with this approach. 2. expect pretty aggressive userbase, very direct, even brutally so. 3. expect dependency fights between wayland-only crowd and x11-only crowd. 4. same as above but for pulse vs alsa. 5. same as above but openssl vs libressl (this one should be easier nowadays as support is going away) 6. project is split into 4 repos basically, 1 for app, 1 for webrtc, 1 for cmake files, 1 for audio lib. there are no releases for any except tdesktop itself. 7. expect to read a lot of cmake cross-referenced across all those 4 repos. 8. expect to be able to patch cmake a lot. for example one can't toggle off automagic deps. 9. expect to collaborate with other disto developers, who also work on mentioned tasks. rpmfusion and freebsd guys are very helpful and solve same problems as we do. If you are still reading - reach out, I'll help to get started. I don't have time to maintain it anymore, so it either should be removed or go into caring hands, as it needs A LOT OF CARE. https://bugs.gentoo.org/buglist.cgi?quicksearch=telegram-desktop -- Best regards, Georgy signature.asc Description: PGP signature
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
On 25.11.2020 13:57, Georgy Yakovlev wrote: > Hi, > > In case you don't know, opentmpfiles has an open CVE > CVE-2017-18925: root privilege escalation by symlink attack > https://github.com/OpenRC/opentmpfiles/issues/4 > It has been an issue for quite a while, reported 3 years ago, > and not much changed since. > Also it lacks any sort of testing, and master branch is in a non-working > state at time of writing, latest version is masked.[0] > > Due to nature of opentmpfiles (it's a POSIX sh script), > it may be impossible to fix symlink handling and TOCTOU races. > As a consequence I'll be switching default tmpfiles > provider to sys-apps/systemd-tmpfiles by the end of the week by updating > virtual/tmpfiles ebuild. > > pros of systemd-tmpfiles: > 0) Secure. > 1) Reference implementation. > 2) Supports all features, because ^. > 3) Has working tests. > 4) Has millions of users as part of systemd. > 5) upstream supports standalone usecase/build our ebuild uses. [1][2] > 6) drop-in replacement, just emerge and forget. > > systemd-tmpfiles does not depend on any systemd-isms, does not need dbus, > and is just a drop-in replacement, the only step needed is to emerge the > package. > it's a simple single binary + manpage, binary links to libacl and couple other > system libs. > > existing installations will not be affected, but openrc users are welcome to > opt-in by running 'emerge --oneshot systemd-tmpfiles' > > [0] https://bugs.gentoo.org/751739 > [1] https://github.com/systemd/systemd/pull/16061 > [2] > https://github.com/systemd/systemd/pull/16061/commits/db64ba81c62afa0e0d3e95c4a3e1ec3dd9a471a4 This is done in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab23417927d8454c8bb1c0ae52a5cac79d140b94 signature.asc Description: PGP signature
[gentoo-dev] PSA: switching default tmpfiles virtual provider
Hi, In case you don't know, opentmpfiles has an open CVE CVE-2017-18925: root privilege escalation by symlink attack https://github.com/OpenRC/opentmpfiles/issues/4 It has been an issue for quite a while, reported 3 years ago, and not much changed since. Also it lacks any sort of testing, and master branch is in a non-working state at time of writing, latest version is masked.[0] Due to nature of opentmpfiles (it's a POSIX sh script), it may be impossible to fix symlink handling and TOCTOU races. As a consequence I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles by the end of the week by updating virtual/tmpfiles ebuild. pros of systemd-tmpfiles: 0) Secure. 1) Reference implementation. 2) Supports all features, because ^. 3) Has working tests. 4) Has millions of users as part of systemd. 5) upstream supports standalone usecase/build our ebuild uses. [1][2] 6) drop-in replacement, just emerge and forget. systemd-tmpfiles does not depend on any systemd-isms, does not need dbus, and is just a drop-in replacement, the only step needed is to emerge the package. it's a simple single binary + manpage, binary links to libacl and couple other system libs. existing installations will not be affected, but openrc users are welcome to opt-in by running 'emerge --oneshot systemd-tmpfiles' [0] https://bugs.gentoo.org/751739 [1] https://github.com/systemd/systemd/pull/16061 [2] https://github.com/systemd/systemd/pull/16061/commits/db64ba81c62afa0e0d3e95c4a3e1ec3dd9a471a4 signature.asc Description: PGP signature
Re: [gentoo-dev] Pushing to distfiles?
On 11.11.2020 19:23, Joshua Kinard wrote: > Forgive me for being a dunce, but what is the current procedure to push > files to distfiles for distribution to the mirrors? The devmanual is blank > on this topic, and GLEP75 just talks about the motivations behind the change > away from the flat directory format. I am not easily finding anything that > details how to get new distfiles onto the mirrors. Hi, Just put to devspace. for example I keep distfiles in ~/public_html/distfiles This is preferred of having file on mirrors only. And it will be automatically mirrored from devspace, so no extra steps required. > > Thanks, > > -- > Joshua Kinard > Gentoo/MIPS > ku...@gentoo.org > rsa6144/5C63F4E3F5C6C943 2015-04-27 > 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 > > "The past tempts us, the present confuses us, the future frightens us. And > our lives slip away, moment by moment, lost in that vast, terrible > in-between." > > --Emperor Turhan, Centauri Republic > signature.asc Description: PGP signature
[gentoo-dev] [PATCH] eclass/cargo.eclass: add CARGO_OPTIONAL condition
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index e6fec844d274..03dfbfebd1d7 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -15,20 +15,40 @@ _CARGO_ECLASS=1
# we need this for 'cargo vendor' subcommand and net.offline config knob
RUST_DEPEND=">=virtual/rust-1.37.0"
-case ${EAPI} in
- 7) BDEPEND="${RUST_DEPEND}";;
- *) die "EAPI=${EAPI:-0} is not supported" ;;
+case "${EAPI:-0}" in
+ 0|1|2|3|4|5|6)
+ die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+ 7)
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
esac
inherit multiprocessing toolchain-funcs
-EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
+if [[ ! ${CARGO_OPTIONAL} ]]; then
+ BDEPEND="${RUST_DEPEND}"
+ EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install
src_test
+fi
IUSE="${IUSE} debug"
ECARGO_HOME="${WORKDIR}/cargo_home"
ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
+# @ECLASS-VARIABLE: CARGO_OPTIONAL
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# If set to a non-null value, before inherit cargo part of the ebuild will
+# be considered optional. No dependencies will be added and no phase
+# functions will be exported.
+#
+# If you enable CARGO_OPTIONAL, you have to set BDEPEND on virtual/rust
+# for your package and call at least cargo_gen_config manually before using
+# other src_ functions of this eclass.
+
# @VARIABLE: myfeatures
# @DEFAULT_UNSET
# @DESCRIPTION:
--
2.29.2
[gentoo-dev] RFC: introduce RUST_TARGETS use-expand (take2)
Hi, sending again, accidentally sent from personal email first time and it's stuck somewhere. I would like to introduce new USE_EXPAND in profiles for rusts 3 consumers in the tree: dev-lang/rust dev-lang/rust-bin sys-devel/rust-std and maybe virtual, but not sure yet, may be required for firefox. The idea: Rust supports building as many targets as one wants, as long as C toolchan can do it and matching llvm target is enabled on rust or llvm. There are some special rust targets that require same host toolchain but are treated like separate targets in rust. For example x86_64-unknown-linux-gnu target is primary on amd64, but on multilib profiles we can easily enable i686-unknown-linux-gnu target and it will just work (that's how multilib in rust works now) Another example is arm: armv7-unknown-linux-gnueabihf is primary toolchain. but rust supports additional target thumbv7neon-unknown-linux-gnueabihf, which requires exactly same host toolchain, but is capable of emitting thumb-neon binaries. This is required by firefox if --enable-neon is passed in firefox build. Another example: ppc64 We can easily build both ppc64 and ppc64le targets in a single bootstrap with host toolchain, and rust will support emitting code for both endians. Another example: musl On musl we need 1 extra target with gentoo vendor field. So installing both x86_64-unknown-linux-musl x86_64-gentoo-linux-musl will be very easy, as both targets use same C toolchain, but slightly different settings. And last, but not the least, it allows cross support if matching toolchain is installed (tested with crossdev) A user can unmask the following targets on amd64 rust_targets_thumbv7neon-unknown-linux-gnueabihf rust_targets_armv7-unknown-linux-gnueabihf And as long as they have /usr/armv7a-unknown-linux-gnueabihf toolchain available at build time, and llvm_targets_ARM enabled, rust will bootstrap itself in a way that it will be able to emit code for any of 3 targets enable. This is optional opt-in functionality. And just to clarify, native host toolchain is not going to be a use-expand, at least that's how I imagine it now. Native target matching CHOST is always build without any flags, and is the default target for rust. But I may re-evaluate it and introduce requirements like abi_x86_64?? ( rust_targets_x86_64-unknown-linux-gnu ) abi_x86_32? ( rust_targets_i686-unknown-linux-gnu ) for multilib profiles. and something like this for non-multilib arches. ppc64? ( || rust_targets_powerpc64le-unknown-linux-gnu rust_targets_powerpc64-unknown-linux-gnu ) for example, similar to as llvm does with LLVM_TARGETS. Of course default targets will be use-forced via profiles. But if possible I'd avoid it. Proof of concept exists (without using expand flags for now) in both rust and rust-bin ebuilds. Multilib is implemented that way and has been working great for more than a year, also experimental cross support in rust implemented that way, and users are already able to define as many targets as they want, but it feels hacky and I would like to move forward to targets approach and make it trackable via flags, and not magic variables nobody knows about. Initial rollout will require a bit of arch profile masking (like llvm does it) and maybe new eclass to reduce boilerplate code in ebuilds, but nothing to complex. WDYT? tracking bug https://bugs.gentoo.org/747760 cross bugs: https://bugs.gentoo.org/679878 https://bugs.gentoo.org/680652 https://bugs.gentoo.org/689336 Regards, Georgy.
[gentoo-dev] Re: RFC: introduce RUST_TARGETS use-expand
On 10/10/20 7:17 PM, Georgy Yakovlev wrote: Hi, Sorry, thunderbird used personal mailfrom for some reason. Probably an issue after update. OpenPGP_0xA5EDB076475B46A6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH 2/2] eclass/cargo.eclass: require cargo_gen_config in cargo_src* functions
cargo_gen_config sets required config values and env vars, which
cargo_src_{compile,test,install} rely on.
it should be called as last step of src_unpack normally, so check it did.
Crate sources may have been vendored or cargo is wrapped by other build
system and pre-fetched, so cargo_*unpack may be not used.
In that case we can't guarantee our config will work, so src_ functions
should not be used.
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index dde601ec4e3c..3e0bb443 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -267,6 +267,7 @@ cargo_gen_config() {
_EOF_
export CARGO_HOME="${ECARGO_HOME}"
+ _CARGO_GEN_CONFIG_HAS_RUN=1
}
# @FUNCTION: cargo_src_configure
@@ -323,6 +324,9 @@ cargo_src_configure() {
cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
+ [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+ die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+
tc-export AR CC CXX
set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
@@ -340,6 +344,9 @@ cargo_src_compile() {
cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
+ [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+ die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+
set -- cargo install $(has --path ${@} || echo --path ./) \
--root "${ED}/usr" \
$(usex debug --debug "") \
@@ -359,6 +366,9 @@ cargo_src_install() {
cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
+ [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+ die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+
set -- cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
"${@}" || die "cargo test failed"
--
2.28.0
[gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: support cached downloads for live ebuilds
Also honor ECARGO_OFFLINE/EVCS_OFFLINE
Good portion of the code/logic inspired by git-r3.eclass.
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 115 +---
1 file changed, 108 insertions(+), 7 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 6d341601a112..dde601ec4e3c 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -46,6 +46,35 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
# }
# @CODE
+# @ECLASS-VARIABLE: ECARGO_REGISTRY_DIR
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Storage directory for cargo registry.
+# Used by cargo_live_src_unpack to cache downloads.
+# This is intended to be set by users.
+# Ebuilds must not set it.
+#
+# Defaults to '${DISTDIR}/ecargo-registry' it not set.
+
+# @ECLASS-VARIABLE: ECARGO_OFFLINE
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty, this variable prevents online operations in
+# cargo_live_src_unpack.
+# Inherits value of EVCS_OFFLINE if not set explicitly.
+
+# @ECLASS-VARIABLE: EVCS_UMASK
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Set this variable to a custom umask. This is intended to be set by
+# users. By setting this to something like 002, it can make life easier
+# for people who use cargo in a home directory, but are in the portage
+# group, and then switch over to building with FEATURES=userpriv.
+# Or vice-versa.
+
# @FUNCTION: cargo_crate_uris
# @DESCRIPTION:
# Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -122,13 +151,84 @@ cargo_live_src_unpack() {
[[ "${EBUILD_PHASE}" == unpack ]] || die "${FUNCNAME} only allowed in
src_unpack"
mkdir -p "${S}" || die
+ mkdir -p "${ECARGO_VENDOR}" || die
+ mkdir -p "${ECARGO_HOME}" || die
+
+ local distdir=${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}}
+ : ${ECARGO_REGISTRY_DIR:=${distdir}/ecargo-registry}
+
+ local offline="${ECARGO_OFFLINE:-${EVCS_OFFLINE}}"
+
+ if [[ ! -d ${ECARGO_REGISTRY_DIR} && ! ${offline} ]]; then
+ (
+ addwrite "${ECARGO_REGISTRY_DIR}"
+ mkdir -p "${ECARGO_REGISTRY_DIR}"
+ ) || die "Unable to create ${ECARGO_REGISTRY_DIR}"
+ fi
+
+ if [[ ${offline} ]]; then
+ local subdir
+ for subdir in cache index src; do
+ if [[ ! -d ${ECARGO_REGISTRY_DIR}/registry/${subdir}
]]; then
+ eerror "Networking activity has been disabled
via ECARGO_OFFLINE or EVCS_OFFLINE"
+ eerror "However, no valid cargo registry
available at ${ECARGO_REGISTRY_DIR}"
+ die "Unable to proceed with
ECARGO_OFFLINE/EVCS_OFFLINE."
+ fi
+ done
+ fi
+
+ if [[ ${EVCS_UMASK} ]]; then
+ local saved_umask=$(umask)
+ umask "${EVCS_UMASK}" || die "Bad options to umask:
${EVCS_UMASK}"
+ fi
pushd "${S}" > /dev/null || die
- # need to specify CARGO_HOME before cargo_gen_config fired
- CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
- CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
+
+ # Respect user settings befire cargo_gen_config is called.
+ if [[ ! ${CARGO_TERM_COLOR} ]]; then
+ [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && export
CARGO_TERM_COLOR=never
+ local unset_color=true
+ fi
+ if [[ ! ${CARGO_TERM_VERBOSE} ]]; then
+ export CARGO_TERM_VERBOSE=true
+ local unset_verbose=true
+ fi
+
+ # Let cargo fetch to system-wide location.
+ # It will keep directory organized by itself.
+ addwrite "${ECARGO_REGISTRY_DIR}"
+ export CARGO_HOME="${ECARGO_REGISTRY_DIR}"
+
+ # Absence of quotes around offline arg is intentional, as cargo bails
out if it encounters ''
+ einfo "cargo fetch ${offline:+--offline}"
+ cargo fetch ${offline:+--offline} || die #nowarn
+
+ # Let cargo copy all required crates to "${WORKDIR}" for offline use in
later phases.
+ einfo "cargo vendor ${offline:+--offline} ${ECARGO_VENDOR}"
+ cargo vendor ${offline:+--offline} "${ECARGO_VENDOR}" || die #nowarn
+
+ # Users may have git checkouts made by cargo.
+ # While cargo vendors the sources, it still needs git checkout to be
present.
+ # Copying full dir is an overkill, so just symlink it.
+ if [[ -d ${ECARGO_REGISTRY_DIR}/git ]]; then
+ ln -sv "${ECARGO_REGISTRY_DIR}/git" "${ECARGO_HOME}/git" || die
+ fi
+
Re: [gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps
took a while, removed. I was able to save jabref-bin, works fine with openjdk:8 geogebra now availabie as geogebra-bin and works with openjdk8 and 11. sleuthkit was spared. rest is gone, but if someone wants to restore - patches welcome. On 4/18/20 9:10 PM, Georgy Yakovlev wrote: > # Georgy Yakovlev (2020-04-18) > # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles > # requires agreement to restrictive license > # Revdeps that still depend on oracle variants require javafx > # Please use icedtea or openjdk instead. > # Removal in 30 days. > # https://bugs.gentoo.org/681828 > dev-java/oracle-jdk-bin > dev-java/oracle-jre-bin > app-forensics/sleuthkit > app-text/jabref-bin > dev-java/netbeans-platform > dev-java/netbeans-harness > games-util/pogo-manager-bin > net-p2p/bisq > sci-mathematics/geogebra > > > > Oracle java has been maintainer-needed since august 2019, > no one stepped up. > Removal in 30 days. > > If someone wants to save the javafx revdeps, best way will be > packaging zulufx community [1], I can provide some guidance > on packaging it, should not be too hard. >
[gentoo-dev] Last rites: dev-python/ansimarkup
# Georgy Yakovlev (2020-09-02) # Masked for removal. No revdeps. dev-python/ansimarkup
[gentoo-dev] Re: [PATCH] profiles/base/make.defaults: ENV_UNSET CARGO_HOME
On 8/28/20 2:09 PM, Georgy Yakovlev wrote: > CARGO_HOME may leak into ebuild environment and lead to > write attempts to directory specified. > This is explicitly taken care of in cargo.eclass, but > ebuilds that don't use the eclass can still be affected. > > Signed-off-by: Georgy Yakovlev > --- > profiles/base/make.defaults | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults > index 1ac69f51ec9..9f570d905c8 100644 > --- a/profiles/base/make.defaults > +++ b/profiles/base/make.defaults > @@ -40,7 +40,7 @@ CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf" > # GOBIN needs to be cleaned as random values in GOBIN can affect the > # building of some packages: > # > https://archives.gentoo.org/gentoo-dev/message/163010f83ae7819d80c0cfdf797cbfe0 > -ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME > XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT > PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH" > +ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME > XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT > PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH CARGO_HOME" > > # Variables that are set exclusively by the profile > # and not by user configuration files. > Pushed.
[gentoo-dev] [PATCH] profiles/base/make.defaults: ENV_UNSET CARGO_HOME
CARGO_HOME may leak into ebuild environment and lead to write attempts to directory specified. This is explicitly taken care of in cargo.eclass, but ebuilds that don't use the eclass can still be affected. Signed-off-by: Georgy Yakovlev --- profiles/base/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults index 1ac69f51ec9..9f570d905c8 100644 --- a/profiles/base/make.defaults +++ b/profiles/base/make.defaults @@ -40,7 +40,7 @@ CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf" # GOBIN needs to be cleaned as random values in GOBIN can affect the # building of some packages: # https://archives.gentoo.org/gentoo-dev/message/163010f83ae7819d80c0cfdf797cbfe0 -ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH" +ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH CARGO_HOME" # Variables that are set exclusively by the profile # and not by user configuration files. -- 2.28.0
Re: [gentoo-dev] News item: Multiple root kernel command-line arguments
On 8/5/20 5:02 AM, Thomas Deutschmann wrote: > Hi, > > please review the news item below: > Not all arches support --reuse-cmdline btw. It may be only x86 which supports it. This looks like a candidate wiki page or a word of warning in a handbook, not a news item.
[gentoo-dev] Packages up for grabs (aerc, vagrant, rust utils and others)
Hello People, The following packages are up for grabs: # untested with plundervolt mitigations, please test. sys-power/intel-undervolt | need intel CPU machine to maintain # rust stuff app-misc/skim | needs bump, cleanup and new stable app-shells/mcfly | needs minor bump app-text/fblog | needs major bump sys-apps/bat | great upstream, very friendly sys-apps/exa | may be abandoned, check upstream # vagrant bundle. take all 3 together. app-emulation/vagrant | low prio bug [1] dev-ruby/hashicorp-checkpoint | tests fail bug [2] dev-ruby/vagrant_cloud # random stuff app-shells/loksh | release syned with openbsd releases mail-client/aerc | go package, great upstream - Regards, Georgy. [1] https://bugs.gentoo.org/589114 [2] https://bugs.gentoo.org/723820 signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] eclass/cargo.eclass: add cargo_src_configure (revised)
simple src_configure implementation inspired by cmake.eclass
Closes: https://bugs.gentoo.org/721936
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 77 -
1 file changed, 70 insertions(+), 7 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ccbf87aa9a6..77c8e90755b 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -22,7 +22,7 @@ esac
inherit multiprocessing toolchain-funcs
-EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
+EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
IUSE="${IUSE} debug"
@@ -34,6 +34,29 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
# Allows overriding the default cwd to run cargo install from
: ${CARGO_INSTALL_PATH:=.}
+# @VARIABLE: myfeatures
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Optional cargo features defined as bash array. Should be defined before
calling
+# src_configure.
+# If this array is not empty, --no-default-features is passed to cargo.
+# To enable default crate features in that case you can add 'default' to the
array.
+# Extra positional arguments supplied to this function
+# will be passed to cargo in all phases.
+# Make sure all cargo subcommands support flags passed here.
+#
+# Example for package that has x11 and wayland as features, and enables
default set.
+# @CODE
+# src_configure() {
+# local myfeatures=(
+# default
+# $(usex X x11 '')
+# $(usev wayland)
+# )
+# cargo_src_configure
+# }
+# @CODE
+
# @FUNCTION: cargo_crate_uris
# @DESCRIPTION:
# Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -112,6 +135,7 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
pushd "${S}" > /dev/null || die
+ # need to specify CARGO_HOME before cargo_gen_config fired
CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
@@ -151,6 +175,47 @@ cargo_gen_config() {
EOF
# honor NOCOLOR setting
[[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color =
'never'" >> "${ECARGO_HOME}/config"
+
+ export CARGO_HOME="${ECARGO_HOME}"
+}
+
+# @FUNCTION: cargo_src_configure
+# @DESCRIPTION:
+# Configure cargo package features and arguments.
+# Example for package that explicitly builds only 'foo' binary and
+# enables single feature 'barfeature', disabling default feature set.
+# will pass '--no-default-features --features barfeature --bin foo'
+# in src_{compile,test,install}
+# @CODE
+# src_configure() {
+# local myfeatures=(
+# barfeature
+# )
+# cargo_src_configure --bin foo
+# }
+# @CODE
+
+cargo_src_configure() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ [[ -z ${myfeatures} ]] && declare -a myfeatures=()
+ local myfeaturestype=$(declare -p myfeatures 2>&-)
+ if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
+ die "myfeatures must be declared as array"
+ fi
+
+ # transform array from simple feature list
+ # to multiple cargo args:
+ # --features feature1 --features feature2 ...
+ # this format is chosen because 2 other methods of
+ # listing features (space OR comma separated) require
+ # more fiddling with strings we'd like to avoid here.
+ myfeatures=( ${myfeatures[@]/#/--features } )
+
+ # prepend --no-default features if myfeatures array is not empty,
append extra args
+ readonly ECARGO_ARGS=( ${myfeatures:+--no-default-features
${myfeatures[@]}} ${@} )
+
+ [[ ${ECARGO_ARGS[@]} ]] && einfo "Configured with: ${ECARGO_ARGS[@]}"
}
# @FUNCTION: cargo_src_compile
@@ -159,11 +224,9 @@ cargo_gen_config() {
cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
- export CARGO_HOME="${ECARGO_HOME}"
-
tc-export AR CC
- cargo build $(usex debug "" --release) "$@" \
+ cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@" \
|| die "cargo build failed"
}
@@ -173,8 +236,8 @@ cargo_src_compile() {
cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
- cargo install --path ${CARGO_INSTALL_PATH} \
- --root="${ED}/usr" $(usex debug --debug "") "$@" \
+ cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
+ $(usex debug --debug "") ${ECARGO_ARGS[@]} "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
rm -f "${ED}/usr/.crates2.json"
@@ -188,7 +251,7 @@ cargo_src_install() {
cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
- cargo test $(usex debug "" --release) "$@" \
+ cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@" \
|| die "cargo test failed"
}
--
2.27.0
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 6/12/20 11:59 AM, Luca Barbato wrote: > On 12/06/2020 18:24, Georgy Yakovlev wrote: >> On 6/12/20 4:16 AM, Luca Barbato wrote: >>> On 12/06/2020 11:04, Georgy Yakovlev wrote: >>>> +# cargo_src_configure --no-default-features >>> >>> Shall we default in not-defaulting so we can spare some boilerplate? >> I don't think so. Let me explain. >> >> First of all, this will force to explicitly micro-manage all the >> features for all the packages in the tree. >> > > The idea is: > - if myfeatures is empty, do not pass --no-default-features. > - if myfeatures has content, automatically pass --no-default-features. > I realized that was the intention after sending the email. That makes more sense, I'll scout toml files a bit and probably will implement it. I certainly remember scenarios where turning off default features is highly undesirable, but toggling extras makes sense. > --no-default-features --features default seems working as intended btw. > in that case local myfeatures=( default $(usex flagX featureX '') ) -> --no-default-features --features default --features featureX looks quite good actually. just need to make sure we pass --no-default-features first in order in that scenario. > lu
[gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support
On 6/11/20 8:11 PM, Georgy Yakovlev wrote:
> no consumers left in the tree
>
> Signed-off-by: Georgy Yakovlev
> ---
> eclass/cargo.eclass | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..ccbf87aa9a6 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -16,7 +16,6 @@ _CARGO_ECLASS=1
> RUST_DEPEND=">=virtual/rust-1.37.0"
>
> case ${EAPI} in
> - 6) DEPEND="${RUST_DEPEND}";;
> 7) BDEPEND="${RUST_DEPEND}";;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
> esac
>
merged c30b9bed5d16025c59b878e9dff69b90af41bf4d
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 6/12/20 6:03 AM, Kent Fredric wrote:
I've replied privately by mistake, replying to the list again.
> On Fri, 12 Jun 2020 02:04:51 -0700
> Georgy Yakovlev wrote:
>
>> +# cargo_src_configure --no-default-features
>
> Looking at the source, I don't see how this is passed from this command to
> anything.
yeah I caught it later, will just pass it as
readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } ${@} )
>
>> +# transform array from simple feature list
>> +# to multiple cargo args:
>> +# --features feature1 --features feature2 ...
>> +readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
>
> Is this really necessary?
>
>> cargo --features "feature1 feature2"
>
> is perfectly legal.
>
cargo is very picky about how multiple features are quoted in your example.
like REALLY picky, and it breaks depending on how array is passed.
I had that initially but found that just not worth it because it may break.
multiple toggles is perfectly legal way to pass features as well and is
more robust in this situation IMO.
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 6/12/20 4:16 AM, Luca Barbato wrote: > On 12/06/2020 11:04, Georgy Yakovlev wrote: >> +# cargo_src_configure --no-default-features > > Shall we default in not-defaulting so we can spare some boilerplate? I don't think so. Let me explain. First of all, this will force to explicitly micro-manage all the features for all the packages in the tree. Like 90% of crates I've seen ship working choice and there's no benefit of micro-management, and no benefit of enabling non-default features at all. Not all features need to be exposed as use-flags, and this was quite consistent situation so far. I know it may sound a bit strange but automagic in this case works with no downsides, unlike other languages/frameworks/build-systems. Also it will break all the tree packages which do not manage features directly if merged as is. Not sure if --features=default will activate default set and how it will react to being passed along. --no-default-features --features default IDK, looks kinda unnatural. I have a feeling that we'll get more boilerplate if we pass --no-default-features than if we don't. We can re-evaluate as time goes by, but for now I see no major benefit and only downsides. > > lu >
[gentoo-dev] Re: [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
On 6/12/20 2:04 AM, Georgy Yakovlev wrote:
> simple src_configure implementation inspired by cmake.eclass
>
> Closes: https://bugs.gentoo.org/721936
>
> Signed-off-by: Georgy Yakovlev
> ---
> eclass/cargo.eclass | 51 ++---
> 1 file changed, 44 insertions(+), 7 deletions(-)
>
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..b084e082730 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -23,7 +23,7 @@ esac
>
> inherit multiprocessing toolchain-funcs
>
> -EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
> +EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
>
> IUSE="${IUSE} debug"
>
> @@ -35,6 +35,24 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
> # Allows overriding the default cwd to run cargo install from
> : ${CARGO_INSTALL_PATH:=.}
>
> +# @VARIABLE: myfeatures
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Optional cargo features defined as bash array. Should be defined before
> calling
> +# src_configure.
> +# Example for package that has x11 and wayland as features.
> +# Also disables default features, as optional parameter is passed.
> +# @CODE
> +# src_configure() {
> +#local myfeatures=(
> +#$(usex X x11 '')
> +#$(usev wayland)
> +#)
> +#
> +#cargo_src_configure --no-default-features
> +# }
> +# @CODE
> +
> # @FUNCTION: cargo_crate_uris
> # @DESCRIPTION:
> # Generates the URIs to put in SRC_URI to help fetch dependencies.
> @@ -113,6 +131,7 @@ cargo_live_src_unpack() {
> mkdir -p "${S}" || die
>
> pushd "${S}" > /dev/null || die
> + # need to specify CARGO_HOME before cargo_gen_config fired
> CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
> CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
> popd > /dev/null || die
> @@ -152,6 +171,26 @@ cargo_gen_config() {
> EOF
> # honor NOCOLOR setting
> [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color =
> 'never'" >> "${ECARGO_HOME}/config"
> +
> + export CARGO_HOME="${ECARGO_HOME}"
> +}
> +
> +# @FUNCTION: cargo_src_configure
> +# @DESCRIPTION:
> +# Configure cargo package features
> +cargo_src_configure() {
> + debug-print-function ${FUNCNAME} "$@"
> +
> + [[ -z ${myfeatures} ]] && declare -a myfeatures=()
> + local myfeaturestype=$(declare -p myfeatures 2>&-)
> + if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
> + die "myfeatures must be declared as array"
> + fi
> +
> + # transform array from simple feature list
> + # to multiple cargo args:
> + # --features feature1 --features feature2 ...
> + readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
missed ${@}, fixed locally, this should be,
readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } ${@} )
> }
>
> # @FUNCTION: cargo_src_compile
> @@ -160,11 +199,9 @@ cargo_gen_config() {
> cargo_src_compile() {
> debug-print-function ${FUNCNAME} "$@"
>
> - export CARGO_HOME="${ECARGO_HOME}"
> -
> tc-export AR CC
>
> - cargo build $(usex debug "" --release) "$@" \
> + cargo build $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
> || die "cargo build failed"
> }
>
> @@ -174,8 +211,8 @@ cargo_src_compile() {
> cargo_src_install() {
> debug-print-function ${FUNCNAME} "$@"
>
> - cargo install --path ${CARGO_INSTALL_PATH} \
> - --root="${ED}/usr" $(usex debug --debug "") "$@" \
> + cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
> + $(usex debug --debug "") ${ECARGO_FEATURES[@]} "$@" \
> || die "cargo install failed"
> rm -f "${ED}/usr/.crates.toml"
> rm -f "${ED}/usr/.crates2.json"
> @@ -189,7 +226,7 @@ cargo_src_install() {
> cargo_src_test() {
> debug-print-function ${FUNCNAME} "$@"
>
> - cargo test $(usex debug "" --release) "$@" \
> + cargo test $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
> || die "cargo test failed"
> }
>
>
[gentoo-dev] Re: [PATCH 2/2] x11-terms/alacritty: use new cargo_src_configure
On 6/12/20 2:04 AM, Georgy Yakovlev wrote:
> Signed-off-by: Georgy Yakovlev
> ---
> x11-terms/alacritty/alacritty-0.4.3.ebuild | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/x11-terms/alacritty/alacritty-0.4.3.ebuild
> b/x11-terms/alacritty/alacritty-0.4.3.ebuild
> index ac4d768d09b..2efc1a6dd0a 100644
> --- a/x11-terms/alacritty/alacritty-0.4.3.ebuild
> +++ b/x11-terms/alacritty/alacritty-0.4.3.ebuild
> @@ -328,19 +328,20 @@ src_unpack() {
> }
>
> src_configure() {
> - myfeatures=(
> + local myfeatures=(
> $(usex X x11 '')
> $(usev wayland)
> )
> + cargo_src_configure
> }
>
> src_compile() {
> cd alacritty || die
> - cargo_src_compile ${myfeatures:+--features "${myfeatures[*]}"}
> --no-default-features
> + cargo_src_compile --no-default-features
> }
^ --no-default-features should be passed to configure, missed it before
push, fixed locally.
>
> src_install() {
> - CARGO_INSTALL_PATH="alacritty" cargo_src_install
> ${myfeatures:+--features "${myfeatures[*]}"} --no-default-features
> + CARGO_INSTALL_PATH="alacritty" cargo_src_install
>
> newman extra/alacritty.man alacritty.1
>
> @@ -368,5 +369,5 @@ src_install() {
>
> src_test() {
> cd alacritty || die
> - cargo_src_test ${myfeatures:+--features "${myfeatures[*]}"}
> --no-default-features
> + cargo_src_test
> }
>
[gentoo-dev] PATCH: cargo.eclass src_configure function
Add simple src_configure implementation, based on cmake.eclass. 2nd patch is an example of migrated ebuild.
[gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
simple src_configure implementation inspired by cmake.eclass
Closes: https://bugs.gentoo.org/721936
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 51 ++---
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ad90a0c7dd8..b084e082730 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -23,7 +23,7 @@ esac
inherit multiprocessing toolchain-funcs
-EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
+EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
IUSE="${IUSE} debug"
@@ -35,6 +35,24 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
# Allows overriding the default cwd to run cargo install from
: ${CARGO_INSTALL_PATH:=.}
+# @VARIABLE: myfeatures
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Optional cargo features defined as bash array. Should be defined before
calling
+# src_configure.
+# Example for package that has x11 and wayland as features.
+# Also disables default features, as optional parameter is passed.
+# @CODE
+# src_configure() {
+# local myfeatures=(
+# $(usex X x11 '')
+# $(usev wayland)
+# )
+#
+# cargo_src_configure --no-default-features
+# }
+# @CODE
+
# @FUNCTION: cargo_crate_uris
# @DESCRIPTION:
# Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -113,6 +131,7 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
pushd "${S}" > /dev/null || die
+ # need to specify CARGO_HOME before cargo_gen_config fired
CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
@@ -152,6 +171,26 @@ cargo_gen_config() {
EOF
# honor NOCOLOR setting
[[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color =
'never'" >> "${ECARGO_HOME}/config"
+
+ export CARGO_HOME="${ECARGO_HOME}"
+}
+
+# @FUNCTION: cargo_src_configure
+# @DESCRIPTION:
+# Configure cargo package features
+cargo_src_configure() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ [[ -z ${myfeatures} ]] && declare -a myfeatures=()
+ local myfeaturestype=$(declare -p myfeatures 2>&-)
+ if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
+ die "myfeatures must be declared as array"
+ fi
+
+ # transform array from simple feature list
+ # to multiple cargo args:
+ # --features feature1 --features feature2 ...
+ readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
}
# @FUNCTION: cargo_src_compile
@@ -160,11 +199,9 @@ cargo_gen_config() {
cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
- export CARGO_HOME="${ECARGO_HOME}"
-
tc-export AR CC
- cargo build $(usex debug "" --release) "$@" \
+ cargo build $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo build failed"
}
@@ -174,8 +211,8 @@ cargo_src_compile() {
cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
- cargo install --path ${CARGO_INSTALL_PATH} \
- --root="${ED}/usr" $(usex debug --debug "") "$@" \
+ cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
+ $(usex debug --debug "") ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
rm -f "${ED}/usr/.crates2.json"
@@ -189,7 +226,7 @@ cargo_src_install() {
cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
- cargo test $(usex debug "" --release) "$@" \
+ cargo test $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo test failed"
}
--
2.27.0
[gentoo-dev] [PATCH 2/2] x11-terms/alacritty: use new cargo_src_configure
Signed-off-by: Georgy Yakovlev
---
x11-terms/alacritty/alacritty-0.4.3.ebuild | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/x11-terms/alacritty/alacritty-0.4.3.ebuild
b/x11-terms/alacritty/alacritty-0.4.3.ebuild
index ac4d768d09b..2efc1a6dd0a 100644
--- a/x11-terms/alacritty/alacritty-0.4.3.ebuild
+++ b/x11-terms/alacritty/alacritty-0.4.3.ebuild
@@ -328,19 +328,20 @@ src_unpack() {
}
src_configure() {
- myfeatures=(
+ local myfeatures=(
$(usex X x11 '')
$(usev wayland)
)
+ cargo_src_configure
}
src_compile() {
cd alacritty || die
- cargo_src_compile ${myfeatures:+--features "${myfeatures[*]}"}
--no-default-features
+ cargo_src_compile --no-default-features
}
src_install() {
- CARGO_INSTALL_PATH="alacritty" cargo_src_install
${myfeatures:+--features "${myfeatures[*]}"} --no-default-features
+ CARGO_INSTALL_PATH="alacritty" cargo_src_install
newman extra/alacritty.man alacritty.1
@@ -368,5 +369,5 @@ src_install() {
src_test() {
cd alacritty || die
- cargo_src_test ${myfeatures:+--features "${myfeatures[*]}"}
--no-default-features
+ cargo_src_test
}
--
2.27.0
[gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support
This will also allow me to start adding cross support to cargo.eclass
with new cross-friendly variables.
experimental cross support landed in rust-1.44.0 today [1]
[1] https://bugs.gentoo.org/679878
On 6/11/20 8:11 PM, Georgy Yakovlev wrote:
> no consumers left in the tree
>
> Signed-off-by: Georgy Yakovlev
> ---
> eclass/cargo.eclass | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..ccbf87aa9a6 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -16,7 +16,6 @@ _CARGO_ECLASS=1
> RUST_DEPEND=">=virtual/rust-1.37.0"
>
> case ${EAPI} in
> - 6) DEPEND="${RUST_DEPEND}";;
> 7) BDEPEND="${RUST_DEPEND}";;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
> esac
>
[gentoo-dev] [PATCH] eclass/cargo.eclass: drop EAPI=6 support
no consumers left in the tree
Signed-off-by: Georgy Yakovlev
---
eclass/cargo.eclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ad90a0c7dd8..ccbf87aa9a6 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -16,7 +16,6 @@ _CARGO_ECLASS=1
RUST_DEPEND=">=virtual/rust-1.37.0"
case ${EAPI} in
- 6) DEPEND="${RUST_DEPEND}";;
7) BDEPEND="${RUST_DEPEND}";;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
--
2.27.0
Re: [gentoo-dev] cmake-utils.eclass: DEPRECATED notice
opened a PR to add it to repoman: https://github.com/gentoo/portage/pull/554 On 6/8/20 2:09 AM, Sergei Trofimovich wrote: > On Mon, 08 Jun 2020 10:13:24 +0200 > Andreas Sturmlechner wrote: > >> This eclass no longer receives any changes. >> Everyone must port to cmake.eclass. > > We have quite a few ebuilds that still use it: > $ git grep -E 'inherit.*cmake-utils' | wc -l > 1338 > > I don't see any warnings reported by repoman to suggest users > to migrate away. Should we have one? >
Re: [gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps
On Sun, 19 Apr 2020 11:30:25 +0200 "Haelwenn (lanodan) Monnier" wrote: > [2020-04-18 21:10:45-0700] Georgy Yakovlev: > > # Georgy Yakovlev (2020-04-18) > > # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles > > # requires agreement to restrictive license > > # Revdeps that still depend on oracle variants require javafx > > # Please use icedtea or openjdk instead. > > # Removal in 30 days. > > # https://bugs.gentoo.org/681828 > > dev-java/oracle-jdk-bin > > dev-java/oracle-jre-bin > > app-forensics/sleuthkit > > app-text/jabref-bin > > dev-java/netbeans-platform > > dev-java/netbeans-harness > > games-util/pogo-manager-bin > > net-p2p/bisq > > sci-mathematics/geogebra > > The mask on app-forensics/sleuthkit seems to be faulty/overkill: > optionally depends on java, only uses oracle-jdk on 4.7.0. > Thanks! my grep misfired. I removed it from package.mask, and masked java useflag for 4.7.0 instead. -- Georgy Yakovlev pgpAH_4mWfNs3.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps
# Georgy Yakovlev (2020-04-18) # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles # requires agreement to restrictive license # Revdeps that still depend on oracle variants require javafx # Please use icedtea or openjdk instead. # Removal in 30 days. # https://bugs.gentoo.org/681828 dev-java/oracle-jdk-bin dev-java/oracle-jre-bin app-forensics/sleuthkit app-text/jabref-bin dev-java/netbeans-platform dev-java/netbeans-harness games-util/pogo-manager-bin net-p2p/bisq sci-mathematics/geogebra Oracle java has been maintainer-needed since august 2019, no one stepped up. Removal in 30 days. If someone wants to save the javafx revdeps, best way will be packaging zulufx community [1], I can provide some guidance on packaging it, should not be too hard. -- Georgy Yakovlev [1] https://www.azul.com/downloads/zulu-community/?version=java-8-lts&os=linux&package=jdk-fx pgpQeTto78oDk.pgp Description: PGP signature
[gentoo-dev] package up for grabs: net-news/newsboat
No longer use it. Needs a minor bump, upstream changed doc dependency to asciidoctor. Uses custom build system and rust, may be tricky to maintain, but I can help. Couple of open bugs: arm keywording and musl related build falure. net-news/newsboat -- Georgy Yakovlev pgpTpfceqLlmO.pgp Description: PGP signature
[gentoo-dev] Re: [PATCH] 2020-04-04-new-ppc64le-profiles: Add news item
Clarification: this is just news item for review. Profiles need to be marked stable, before posting news item, but I see no reason not to. Old profiles will be deprecated and removed on June 1st 2020. Tracking bug: https://bugs.gentoo.org/715680 On Sat, 4 Apr 2020 19:37:32 -0700 Georgy Yakovlev wrote: > Signed-off-by: Georgy Yakovlev > --- > .../2020-04-04-new-ppc64le-profiles.en.txt| 25 +++ > 1 file changed, 25 insertions(+) > create mode 100644 > 2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt > > diff --git > a/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt > b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt > new file mode 100644 > index 000..c496154 > --- /dev/null > +++ b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt > @@ -0,0 +1,25 @@ > +Title: new ppc64le (little-endian) profiles > +Author: Georgy Yakovlev > +Posted: 2020-04-04 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Profile: > default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian > +Display-If-Profile: > default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd > + > +A new set of 17.0 ppc64le profiles has been added to the Gentoo repository. > +New profiles are compatible with existing ppc64 little-endian profiles, > +and no additional action required after switching the profile. > + > +Please migrate away from the old profiles: > + > +* Old profiles: > +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian > +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd > + > +* Replaced by: > +default/linux/ppc64le/17.0 > +default/linux/ppc64le/17.0/systemd > + > +Desktop profiles are now also available. > + > +Refer to `eselect profile list` output. > -- > 2.26.0 > -- Georgy Yakovlev pgp4vCSLEyCeW.pgp Description: PGP signature
[gentoo-dev] [PATCH] 2020-04-04-new-ppc64le-profiles: Add news item
Signed-off-by: Georgy Yakovlev --- .../2020-04-04-new-ppc64le-profiles.en.txt| 25 +++ 1 file changed, 25 insertions(+) create mode 100644 2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt diff --git a/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt new file mode 100644 index 000..c496154 --- /dev/null +++ b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt @@ -0,0 +1,25 @@ +Title: new ppc64le (little-endian) profiles +Author: Georgy Yakovlev +Posted: 2020-04-04 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian +Display-If-Profile: default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd + +A new set of 17.0 ppc64le profiles has been added to the Gentoo repository. +New profiles are compatible with existing ppc64 little-endian profiles, +and no additional action required after switching the profile. + +Please migrate away from the old profiles: + +* Old profiles: +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd + +* Replaced by: +default/linux/ppc64le/17.0 +default/linux/ppc64le/17.0/systemd + +Desktop profiles are now also available. + +Refer to `eselect profile list` output. -- 2.26.0
Re: [gentoo-dev] musl doesn't provide execinfo.h
On Mon, 23 Mar 2020 21:09:15 +0200 Jaco Kroon wrote: > Hi Michał, > > On 2020/03/23 18:25, Michał Górny wrote: > > > On Mon, 2020-03-23 at 10:21 +0200, 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 musl team could possibly assist on how to > >> get the backtrace() set of calls on musl please? > >> > > As someone not on musl team, I think libunwind provides > > an implementation of backtrace(). > > > Thanks. That indeed looks interesting. > > Let's say I do go that route rather than simply no-opping it, would I > add a BDEPEND + RDEPEND of the form: > > || ( sys-libs/glibc sys-libs/libunwind ) > > To the ebuild? > > The code (./configure and actual "C" I'll manage). > > Kind Regards, > Jaco > > if libunwind can be used, you should use this dep elibc_musl? ( sys-libs/libunwind:= ) but idk if it's usable as is on musl. best way to check is to get musl stage3 tarball and test it. alpine does have a musl patch, but it seems they just patch it out completely. https://git.alpinelinux.org/aports/tree/main/dahdi-tools/fix-musl.patch -- Georgy Yakovlev pgpb0FaDXw7ig.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] metadata/policy.conf: Introduce QA check configuration
On Wed, 26 Feb 2020 11:23:49 +0100 Michał Górny wrote: > Introduce a new configuration file for assigning QA check significance > levels to PG policies. Long-term goal is that this will permit > unified configuration of various QA tools, including pkgcheck, repoman > and install-qa-check.d. > > Signed-off-by: Michał Górny > --- > metadata/policy.conf | 61 > 1 file changed, 61 insertions(+) > create mode 100644 metadata/policy.conf > > diff --git a/metadata/policy.conf b/metadata/policy.conf > new file mode 100644 > index ..824598063cc1 > --- /dev/null > +++ b/metadata/policy.conf > @@ -0,0 +1,61 @@ > +# Copyright 2020 Gentoo Authors > +# Distributed under the terms of the GNU General Public License v2 > + > +# The policy section assigns significance levels to various policies. > +# Keys are identifiers from the Policy Guide, values are either > +# 'notice', 'warninging' or 'error'. extra ing here > +# > +# The rule of thumb is that 'error' indicates a serious problem that > +# may cause serious problem to the end users and therefore should block > +# committing / deployment. 'Warning' should be fixed by developer capital W probably should be w > +# but does not need to immediately prevent committing. > +# > +# https://projects.gentoo.org/qa/policy-guide/std-policy-index.html > + Looks really interesting. Will overlays be able to define their own policy ? Maybe rename file to metadata/qa-policy.conf ? just policy.conf is ambiguous. -- Georgy Yakovlev
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d/60appdata-path: new check
On Thu, 13 Feb 2020 08:11:09 -0800 Christopher Head wrote: > On Wed, 12 Feb 2020 23:39:11 -0800 > Georgy Yakovlev wrote: > > > + eqawarn "For more details, please see the > > freedesktop Upstrem Metadate guidelines" > > Couple of typos here: s/Upstrem/Upstream/, s/Metadate/Metadata/. Thanks! Fixed and pushed now. Tracker bug is https://bugs.gentoo.org/709450 pgpaI8vnwCbLs.pgp Description: OpenPGP digital signature
[gentoo-dev] [PATCH] metadata/install-qa-check.d/60appdata-path: new check
this will warn if package installs xml files to /usr/share/appdata
this location is deprecated, files should be installed to
/usr/share/metainfo
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
Signed-off-by: Georgy Yakovlev
---
metadata/install-qa-check.d/60appdata-path | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 metadata/install-qa-check.d/60appdata-path
diff --git a/metadata/install-qa-check.d/60appdata-path
b/metadata/install-qa-check.d/60appdata-path
new file mode 100644
index 000..c4878949b0e
--- /dev/null
+++ b/metadata/install-qa-check.d/60appdata-path
@@ -0,0 +1,33 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that metadata files are installed in /usr/share/metainfo
+# Maintainer: Georgy Yakovlev
+
+appdata_path_check() {
+ [[ -d ${ED%/}/usr/share/appdata ]] || return
+
+ local found=() f
+ while read -d '' -r f; do
+ found+=( "${f%/*}" )
+ done < <(find "${ED%/}/usr/share/appdata" -name '*.xml' -print0 || die)
+
+ if [[ ${found[@]} ]]; then
+ eqawarn
+ eqawarn "This package seems to install metainfo files into the
following"
+ eqawarn "location(s):"
+ eqawarn
+ eqatag -v appdata.invalid-path "${found[@]#${D%/}}"
+ eqawarn
+ eqawarn "This location is deprecated, it should not be used
anymore by new software"
+ eqawarn "Appdata/Metainfo files should be installed into
/usr/share/metainfo directory"
+ eqawarn "For more details, please see the freedesktop Upstrem
Metadate guidelines"
+ eqawarn
"https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html";
+ eqawarn
+ fi
+}
+
+appdata_path_check
+: # guarantee successful exit
+
+# vim:ft=sh
--
2.25.0
Re: [gentoo-dev] Last rites: virtual/cargo
On Mon, 27 Jan 2020 10:48:51 +0100 David Seifert wrote: > On Sun, 2020-01-26 at 21:53 -0500, Michael Orlitzky wrote: > > On 1/26/20 9:46 PM, Georgy Yakovlev wrote: > > > # update your rust packages running emerge with the > > > # --changed-deps option if you have problems > > > > If this advice helps, you have violated the PMS. > > > > Agreed, if possible revbump any critical ebuilds, so we can avoid the > virtual/pam disaster this time round. > > All critical explicit consumers switched a while ago (mozilla & co). Consumers via eclass switched about 1 month ago. I considered revbumps, there were 44 ebuilds and 23 unique packages,about half of that with stable keywords. not that much, it's not pam after all. I did bump some meanwhile. There will be no disaster. pgpoJ8exDAmlk.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: virtual/cargo
# Georgy Yakovlev (2020-01-26) # Not needed anymore, feel free to remove from your system # emerge -C virtual/cargo # update your rust packages running emerge with the # --changed-deps option if you have problems # https://bugs.gentoo.org/695698 virtual/cargo pgpq8isLKhJsg.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-plugins/passff
# Georgy Yakovlev (2020-01-26) # Starting with Firefox 74 Mozilla removes xpi sideloading support # install from addons.mozilla.org # passff-host remains in the tree www-plugins/passff pgpMRWkCmo2fK.pgp Description: OpenPGP digital signature
