[gentoo-dev] Re: [PATCH] stardict.eclass: Rename IUSE=gzip->zlib
I've included this in a larger PR that contains some other compression flag simplifications: https://github.com/gentoo/gentoo/pull/21558 Wow, also noticed that this eclass says its maintainer is someone who retired in 2007. Feel free to drop him from replies :)
[gentoo-dev] Re: [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
I've included this in a larger PR that contains some other compression flag simplifications: https://github.com/gentoo/gentoo/pull/21558
[gentoo-dev] [PATCH] stardict.eclass: Rename IUSE=gzip->zlib
The flag actually controls a dependency on app-arch/gzip, but you
already have that too. Name the flag IUSE=zlib so it'll be enabled by
default.
Signed-off-by: Matt Turner
---
eclass/stardict.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/stardict.eclass b/eclass/stardict.eclass
index 0061353f4ab..4a012fb500a 100644
--- a/eclass/stardict.eclass
+++ b/eclass/stardict.eclass
@@ -39,7 +39,7 @@ S="${WORKDIR}"/${DICT_P}
LICENSE="GPL-2"
SLOT="0"
-IUSE="gzip"
+IUSE="zlib"
DEPEND="
|| (
@@ -47,7 +47,7 @@ DEPEND="
app-text/sdcv
app-text/goldendict
)
- gzip? (
+ zlib? (
app-arch/gzip
app-text/dictd
)"
--
2.31.1
[gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
Enable these flags by default, since they effectively add no additional
dependencies:
USE=bzip2 only ever adds a dependency on:
app-arch/bzip2 - part of @system
dev-ml/camlbz2 - to dev-ml/dose3's RDEPEND
USE=lzma only ever adds a dependency on:
app-arch/xz-utils - part of @system
virtual/pkgconfig - to sys-apps/kmod's BDEPEND
USE=zstd only ever adds a dependency on:
app-arch/zstd - an unconditional RDEPEND of sys-apps/portage
virtual/pkgconfig - to kde-frameworks/karchive's BDEPEND
Signed-off-by: Matt Turner
---
profiles/default/linux/make.defaults | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/profiles/default/linux/make.defaults
b/profiles/default/linux/make.defaults
index 168f895eaf7..cbc5092cb2b 100644
--- a/profiles/default/linux/make.defaults
+++ b/profiles/default/linux/make.defaults
@@ -11,7 +11,7 @@
# Default starting set of USE flags for all default/linux profiles.
-USE="crypt ipv6 ncurses nls pam readline ssl tcpd zlib"
+USE="bzip2 crypt ipv6 lzma ncurses nls pam readline ssl tcpd zlib zstd"
# make sure toolchain has sane defaults
USE="${USE} fortran openmp"
--
2.31.1
[gentoo-dev] libffi-3.4 is on the horison (unkeyworded for now, ~arch soon)
Tl;DR - libffi-3.4 entered ::gento without KEYWORDS today. After some testing it will be promoted into ~arch. libffi has two modes: 1. USE=-exec-static-trampoline: old (default, safe) 2. USE=exec-static-trampoline: new (cool, might expose latent bugs) +toralf@ (CC): Toralf, can we set a tinderbox run for [1.] >=dev-libs/libffi-3.4[-exec-static-trampoline] case? [2.] would also be nice: >=dev-libs/libffi-3.4[exec-static-trampoline] My worry is that it will generate a lot of collateral breakage (at least some percentage of dev-haskell/*). Tracker: https://bugs.gentoo.org/801109 Known examples: https://wiki.gentoo.org/index.php?title=Project:Toolchain#libffi-3.4 More help - If you happen to maintain a Gentoo package that uses libffi you can try libffi-3.4 early to see how it behaves. - Try [1.] on packages you maintain. - If you are brave try [2.] as well but be ready to recover your system! A few packages are already known to be affected: https://wiki.gentoo.org/index.php?title=Project:Toolchain#libffi-3.4 Add new bugs you found as blockers to the libffi-3.4 tracker: https://bugs.gentoo.org/801109 More words -- In this release most probably impactful change is a trampoline code handling change. Before 3.4 libffi generated all code at runtime in a single executable chunk of executable memory. Since 3.4 libffi uses does not use runtime code generation and uses statically defined trampoline in a very clever way: https://sourceware.org/pipermail/libffi-discuss/2021/002579.html This should not be a problem for most applications, but two are already known to fail: - ghc: https://gitlab.haskell.org/ghc/ghc/-/issues/20051 - gobject-introspection: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/283 The symptoms are SIGSEGVs and erratic behaviour. To workaround widespread breakage libffi-3.4 provides a fallback mode that reuses libffi-3.3 style trampoline layout via USE=-exec-static-trampoline. Also note that libffi-3.4 also changes SONAME from libffi.so.7 to libffi.so.8. It will rebuild a few packages as a result. It's a good time to check for missing rebuild slot operator in depends. If you broke your system with USE=exec-static-trampoline try to recover with USE=-exec-static-trampoline first. It should avoid rebuilding revdeps back to .so.7. Debugging help -- If you suspect your package is affected then CC toolchain@ to the relevant bug and we'll try to sort it out together. Have fun! -- Sergei
Re: [gentoo-dev] 'pax_kernel' USE flag
On 2021-07-07 05:05, Matt Turner wrote: On Tue, Jul 6, 2021 at 7:41 PM Thomas Deutschmann wrote: As you probably know, I am not a Linux desktop user (yet). My complete experience with that PaX stuff is limited to servers. Maybe I've misunderstood what you meant. You don't use Linux on the desktop? But, you maintain Firefox? I'm definitely confused :) No, I became Firefox maintainer by accident via security project when former devs weren't available and I started to help out. I actually bought a notebook a few years ago just to be able to do more testing (I have a lot of experience with Selenium where I am using the browser in headless mode but when you want to improve desktop integration...). This also enabled me to become a test user for leio's GNOME 3.30 work which was a great experience. My Gentoo desktop usage has increased a lot since then but Linux still isn't my *primary* desktop platform (yet). -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables
On 2021-07-06 22:59, William Hubbs wrote: Change the _R0 suffix on these variable names to _ECLASS. Any non-cosmetic reasons for doing this? -- Marecki OpenPGP_signature Description: OpenPGP digital signature
