Re: [gentoo-dev] Common Lisp project is empty

On Wed, 2021-11-03 at 16:25 +0100, Max Zettlmeißl wrote: > On Wed, 3 Nov 2021 at 14:15, Michael Orlitzky wrote: > > If no one intends to join, we should drop the following to maintainer- > > needed: > > I use some of those packets daily. Is there a way to join the Common &

[gentoo-dev] Common Lisp project is empty

If no one intends to join, we should drop the following to maintainer- needed: app-misc/rlwrap dev-libs/ffcall dev-libs/libsigsegv dev-lisp/alexandria dev-lisp/asdf dev-lisp/cl-ppcre dev-lisp/cl-ppcre-unicode dev-lisp/clisp dev-lisp/clozurecl dev-lisp/clx dev-lisp/cmucl dev-lisp/ecls

Re: [gentoo-portage-dev] [RFC] LTS branch of Portage

On Tue, 2021-10-05 at 17:13 +0200, Michał Górny wrote: > > > 2. What happens to the LTS branch when the next EAPI is released? > > > > I haven't really thought about it. Are you suggesting that we could > bump 'master' Portage to newer EAPI earlier or...? > I just mean that, a priori, the

Re: [gentoo-portage-dev] [RFC] LTS branch of Portage

On Tue, 2021-10-05 at 10:31 +0200, Michał Górny wrote: > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > I think this is healthy for most software projects, but

Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

On Mon, 2021-09-27 at 15:44 -0400, Mike Gilbert wrote: > On Mon, Sep 27, 2021 at 3:11 PM Peter Stuge wrote: > > > > Mike Gilbert wrote: > > > It's a waste of time and effort to pepper random ebuilds with checks > > > for options that everyone should have enabled in the first place. > > > > It's

Re: [gentoo-dev] [PATCH 02/44] apache-module.eclass: Set @PROVIDES

On Thu, 2021-09-02 at 14:58 +0200, Michał Górny wrote: > > > Apparently, need_apache* is the problem. Most of the ebuilds in www- > apache/* are calling it: > The apache-module eclass tells you to do that because it needs some of those APACHE_* paths. It should really be figuring them out

Re: [gentoo-dev] [PATCH 02/44] apache-module.eclass: Set @PROVIDES

On Thu, 2021-09-02 at 12:46 +0200, Michał Górny wrote: > Signed-off-by: Michał Górny > --- > eclass/apache-module.eclass | 1 + > 1 file changed, 1 insertion(+) > ... > # @SUPPORTED_EAPIS: 5 6 7 > +# @PROVIDES: depend.apache I'm not sure about this one. The depend.apache eclass is junk and we

[gentoo-dev] Infra support for mail submission with implicit TLS on port 465

There have been some attacks on STARTTLS lately, so I'm finally getting around to using implicit TLS for mail submission on port 465. I tried this on dev.gentoo.org, and it seems to work. For example: I just switched Evolution to port 465, with always-on TLS, and am sending this message. Is this

Re: [gentoo-dev] [PATCH 2/3] qmail.eclass: remove magic to query root group

On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote: > The default owner is root:root anyway. > This is only true of you don't call insopts earlier with some other value. I see "insopts -o root -g qmail -m 700" in there so you might want to double check.

Re: [gentoo-dev] [PATCH] eclass/postgres.eclass: migrate to GLEP 81

On Fri, 2021-07-23 at 00:20 +0200, Conrad Kostecki wrote: > This update drops the function 'postgres_new_user', which was used to > create the 'postgres' user and group. > > ... > > Since many other packages depend on the 'postgres' and 'postgres-multi' > eclass, adding the core acct-*/postgres

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

On Mon, 2021-07-12 at 10:46 -0500, Ben Kohler wrote: > > Nobody is "disabling choice" here, a change in defaults doesn't remove > your ability to choose something else. I think what you're suggesting is that default-on is not any worse for choice than default-off, since both can be changed?

Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item

On Sun, 2021-07-11 at 15:53 +0200, Thomas Deutschmann wrote: > > Furthermore, tmpfiles.d settings are only supposed for creation, > deletion and cleaning of volatile and temporary files. Any package which > will install tmpfiles.d settings which will create files in persistent > locations

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

On Fri, 2021-07-09 at 12:05 +0200, Ulrich Mueller wrote: > > > > > > > > Sorry, but that doesn't make sense. These are global USE flags, and > the aim here is to set a _global_ default for them, based on the fact > that these libraries are present on every Gentoo system. > > So if we agree that

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

On Thu, 2021-07-08 at 13:17 -0700, Matt Turner wrote: > > I hear you, and I appreciate the theoretical concerns. > > I could maybe even support this position if you were actively working > towards this new and glorious future, but the only time I hear > anything about it is when you're arguing

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

On Thu, 2021-07-08 at 11:15 -0700, Matt Turner wrote: > > So, the thing about running a minimal system is... you already have > these dependencies installed. This doesn't change that... > > I could of course change the default of every bzip2/lzma/zstd in IUSE > (and might as well handle zlib too

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

On Thu, 2021-07-08 at 07:19 -0500, Ben Kohler wrote: > On 7/8/21 6:54 AM, Michael Orlitzky wrote: > > On Wed, 2021-07-07 at 22:01 -0700, Matt Turner wrote: > > > Enable these flags by default, since they effectively add no additional > > > dependencies: > > Why? Th

[gentoo-dev] [PATCH] qmake-utils.eclass: EAPI 8 support

Signed-off-by: David Michael --- Hi, Maybe the banned functions can be dropped? I don't see a removal date, and it's been over half a year since they were made unusable. Thanks. David eclass/qmake-utils.eclass | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

[gentoo-dev] [PATCH] db-use.eclass: EAPI 8 support

conventions. Signed-off-by: David Michael --- eclass/db-use.eclass | 159 --- 1 file changed, 58 insertions(+), 101 deletions(-) diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass index d23b08d1999..1df07a8a7ac 100644 --- a/eclass/db-use.eclass +++ b

Re: [gentoo-dev] Declare the type of source

On Mon, 2021-06-28 at 16:52 +0200, Michał Górny wrote: > > > > This is long overdue, for many reasons, but in particular it would > > force us to declare a dependency on a C compiler if one is needed and > > allow you to re-test only those packages that use a C compiler. > > > > Which C

Re: [gentoo-dev] Declare the type of source

On Mon, 2021-06-28 at 16:31 +0200, Gerion Entrup wrote: > > This should only build, if _all_ build dependencies are present > (including every compiler and base system tool). Of course, it needs a > bigger rework of the portage build process. We had a GSoC project that aimed to do something like

Re: [gentoo-dev] Declare the type of source

On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote: > > Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or > similar, or in metadata.xml if you prefer ) and with a tool like equery/eix > we > are able to get the list of all packages that compiles C code. > I

[gentoo-dev] [PATCH] udev.eclass: EAPI 8 support

This also drops EAPIs < 5 to match toolchain-funcs.eclass. Signed-off-by: David Michael --- This probably could have been sent in a series with https://archives.gentoo.org/gentoo-dev/message/22db5157cab5d6d173483fbc16377081 eclass/udev.eclass | 25 +++-- 1 file changed,

[gentoo-dev] [PATCH] autotools.eclass: EAPI 8 support

Signed-off-by: David Michael --- Hi, Here is a simple update that is blocking a lot of stuff. It moves the EAPI check outside the inherit guard for bash future-proofing. Thanks. David eclass/autotools.eclass | 22 +- 1 file changed, 9 insertions(+), 13 deletions

[gentoo-dev] Re: [PATCH 1/2] xdg-utils.eclass: EAPI 8 support

On Fri, Jun 25, 2021 at 12:33 PM David Michael wrote: > @@ -17,9 +17,9 @@ > # * XDG .desktop files cache management > # * XDG mime information database management > > -case "${EAPI:-0}" in > - 0|1|2|3|4|5|6|7) ;; > - *) die "EAPI=${EAPI}

[gentoo-dev] [PATCH 2/2] gnome.org.eclass: EAPI 8 support

Signed-off-by: David Michael --- eclass/gnome.org.eclass | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/eclass/gnome.org.eclass b/eclass/gnome.org.eclass index dba26155d74..7efd03bfa94 100644 --- a/eclass/gnome.org.eclass +++ b/eclass/gnome.org.eclass @@ -7,13 +7,13

[gentoo-dev] [PATCH 1/2] xdg-utils.eclass: EAPI 8 support

Also standardize on one conditional block spacing syntax and drop some redundant local variables. Signed-off-by: David Michael --- Hi, Here are some EAPI updates for GNOMEy eclasses. This one in particular would benefit from IDEPEND as most of its functions run native programs at pkg_post

[gentoo-dev] [PATCH] systemd.eclass: EAPI 8 support

This also drops EAPIs < 5 to match toolchain-funcs.eclass. (Its support for EAPI 0 is an implementation detail so crossdev can source it, which is not relevant here.) Signed-off-by: David Michael --- Hi, Here is a simple eclass EAPI cleanup with no dependencies. There are also small twe

Re: [gentoo-dev] [PATCH 1/2] ninja-utils.eclass: EAPI 8 support

On Thu, Jun 24, 2021 at 12:51 PM Ulrich Mueller wrote: > >>>>> On Thu, 24 Jun 2021, David Michael wrote: > > --- a/eclass/ninja-utils.eclass > > +++ b/eclass/ninja-utils.eclass > > @@ -1,4 +1,4 @@ > > -# Copyright 1999-2018 Gentoo Foundation > > +#

[gentoo-dev] [PATCH 2/2] meson.eclass: EAPI 8 support

Signed-off-by: David Michael --- Hi, This updates meson.eclass to conform to conventions that other eclasses seem to follow. E.g. conditional inherits are first (presumably for function precedence), and defining the inherit guard at the end. It also removes the split inherit guard. The only

[gentoo-dev] [PATCH 1/2] ninja-utils.eclass: EAPI 8 support

Also drop support for EAPIs < 5 to match multiprocessing.eclass. Signed-off-by: David Michael --- Hi, Here are a couple patches to support EAPI 8 with meson packages. I also posted this to https://github.com/gentoo/gentoo/pull/21409 for review. Thanks. David eclass/ninja-utils.eclass |

Re: [gentoo-dev] [PATCH 3/4] acct-group.eclass: EAPI 8 support

On Tue, Jun 22, 2021 at 1:15 PM Ulrich Mueller wrote: > >>>>> On Tue, 22 Jun 2021, David Michael wrote: > > -# Then you add appropriate dependency to your package. The dependency > > -# type(s) should be: > > -# - DEPEND (+ RDEPEND) if the group is already ne

[gentoo-dev] [PATCH 4/4] acct-user.eclass: EAPI 8 support

resolve names when building packages in nonempty $SYSROOT at src_install time. - IDEPEND so the build system can resolve names when installing binary packages in nonempty $ROOT at pkg_preinst time. - RDEPEND so the target system can use the accounts. Signed-off-by: David Michael

[gentoo-dev] [PATCH 3/4] acct-group.eclass: EAPI 8 support

resolve names when building packages in nonempty $SYSROOT at src_install time. - IDEPEND so the build system can resolve names when installing binary packages in nonempty $ROOT at pkg_preinst time. - RDEPEND so the target system can use the accounts. Signed-off-by: David Michael

[gentoo-dev] [PATCH 2/4] user.eclass: EAPI 8 support

Signed-off-by: David Michael --- eclass/user.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/user.eclass b/eclass/user.eclass index e1f87a383ad..a1fb2a9bbaf 100644 --- a/eclass/user.eclass +++ b/eclass/user.eclass @@ -5,7 +5,7 @@ # @MAINTAINER: # base-sys

[gentoo-dev] [PATCH 1/4] user-info.eclass: EAPI 8 support

Signed-off-by: David Michael --- eclass/user-info.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/user-info.eclass b/eclass/user-info.eclass index d349fc17476..8b8538bf843 100644 --- a/eclass/user-info.eclass +++ b/eclass/user-info.eclass @@ -5,11 +5,11

Re: [gentoo-dev] [PATCH] qmail.eclass: simplify is_prime()

> > This depends on the actual domain of numbers. If the primes involved > have 20 digits as in your example, then factor should be used of course. > > I suspect though that we're talking about small numbers (below 100?) > here, in which case a solution in pure bash would be preferable. > If

Re: [gentoo-dev] [PATCH] fcaps.eclass: support EAPI 8

On Thu, Jun 17, 2021 at 7:02 AM Ulrich Mueller wrote: > >>>>> On Thu, 17 Jun 2021, Michał Górny wrote: > > On Thu, 2021-06-17 at 12:10 +0200, Ulrich Mueller wrote: > >> > > > > > On Thu, 17 Jun 2021, David Michael wrote: > >> > @@ -33

[gentoo-dev] [PATCH] fcaps.eclass: support EAPI 8

kgs in ROOTs. - EAPI > 7: IDEPEND Install native setcap at install-time; it works everywhere. Since all remaining users are EAPI 6 and above, declare eclass compatibility with EAPIs 6, 7, and 8. Signed-off-by: David Michael --- Hi, This is from https://github.com/gentoo/gentoo/pull

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: include riscv bitness in tc-arch

On Mon, May 3, 2021 at 4:41 AM Sergei Trofimovich wrote: > On Sun, 02 May 2021 18:22:43 -0400 fedora@gmail.com wrote: > > This makes tc-arch identify RISC-V systems as either "riscv64" or > > "riscv32". It will still return "riscv" for the kernel arch or if > > bitness is not given in the

[gentoo-dev] Packages up for grabs: oracle-instantclient and others

Hello! It turns out that I don't have enough time to maintain these packages any more: Has reverse dependencies: * dev-db/oracle-instantclient (no fetch restriction any more) Obsolete, updating revdeps not initiated yet: * dev-db/oracle-instantclient-basic * dev-db/oracle-instantclient-jdbc *

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

On Sat, 2021-04-10 at 00:32 +0100, Sam James wrote: > > > Yes, this is the part I find difficult too. The important > distinction here was *bootstrapping* (which I missed) > but I think at least we should make a list of packages generally considered > critical for bootstrap. > What is a

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

On Tue, 2021-04-06 at 20:32 +0100, Sam James wrote: > > > > > We usually don't add basic tools like grep to dependencies. > > Few points: > > ... 5) There are no clear rules about what @system packages can be left out of *DEPEND and when, so their presence is wildly inconsistent.

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Wed, 2021-03-03 at 13:09 +0100, Ulrich Mueller wrote: > > > > > > On Tue, 02 Mar 2021, Michael Orlitzky wrote: > > > Are you volunteering to fix all the tools to support the new format > > > correctly? > > The PMS says that KEYWORDS is whitespace-sep

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, 2021-03-02 at 20:42 +0100, Michał Górny wrote: > > Are you volunteering to fix all the tools to support the new format > correctly? > When you already spend all day fixing other peoples' software, this doesn't sound that scary. The PMS says that KEYWORDS is whitespace-separated.

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, 2021-03-02 at 14:02 -0500, Matt Turner wrote: > On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky wrote: > > why don't we just enforce putting each > > keyword on a separate line instead, so that we don't have this problem > > in the

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Mon, 2021-03-01 at 22:54 -0500, Matt Turner wrote: > tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote, > called merge-driver-ekeyword that can automatically resolve git merge > conflicts involving the KEYWORDS=... line in ebuilds. > > Since the KEYWORDS=... assignment is a

[gentoo-dev] Re: New project: binhost

On 2/10/21 6:57 PM, Andreas K. Hüttel wrote: > Hi all, > > I'm announcing a new project here - "binhost" > > "The Gentoo Binhost project aims to provide readily installable, precompiled > packages for a subset of configurations, via central binary package hosting. > Currently we are still in

Re: [gentoo-dev] New project: binhost

On Wed, Feb 10, 2021 at 11:58 AM Andreas K. Hüttel wrote: > Hi all, > > I'm announcing a new project here - "binhost" > > "The Gentoo Binhost project aims to provide readily installable, > precompiled > packages for a subset of configurations, via central binary package > hosting. > Currently we

Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip

On Tue, 2021-02-09 at 21:44 -0500, Michael Orlitzky wrote: > > ... games-arcade/xboing are also suspect. > (This one's fine, that's the documented way to do things now. Although I don't see why we couldn't use a separate group for each game's score file.)

Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip

On Tue, 2021-02-09 at 18:25 -0800, Manoj Gupta wrote: > > > > Root is the owner but often there is also a group that has access to the > files. > After stripping with llvm-strip, new ownership is root:root instead of > root:. > Therefore, the members of the group lose access to the files post

Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip

On Tue, 2021-02-09 at 17:53 -0800, Fāng-ruì Sòng wrote: > (I replied via https://groups.google.com/g/linux.gentoo.dev/c/WG-OLQe3yng > "Reply all" (which only replied to the list AFAICT) but I did not > subscribe to gentoo-dev via the official > https://www.gentoo.org/get-involved/mailing-lists/ so

Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

On Wed, 2021-02-10 at 08:51 +0800, Benda Xu wrote: > > > > The first big blocker we're going to hit is trustme [3] package that > > relies on cryptography API pretty heavily to generate TLS certs for > > testing. If we managed to convince upstream to support an alternate > > crypto backend, we'd

Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

On Mon, 2021-02-08 at 12:19 +0100, Michał Górny wrote: > > Since cryptography is a very important package in the Python ecosystem, > and it is an indirect dependency of Portage, this means that we will > probably have to entirely drop support for architectures that are not > supported by Rust. >

[gentoo-dev] Re: [PATCH] kernel-2.eclass: EAPI 7 support

On Fri, Feb 5, 2021 at 12:58 PM David Michael wrote: > This converts installation paths prefixed with EROOT or ED to have > a leading slash, switches DEPEND to BDEPEND for EAPI 7 so tools are > installed in BROOT and natively executable, and makes eapply_user > the default src_prep

[gentoo-dev] [PATCH] kernel-2.eclass: EAPI 7 support

Michael --- Hi, Can the kernel eclass support EAPI 7 now? It would help auditing dependencies to eventually support BDEPEND properly in the ebuilds using the eclass. The patch also corrects some whitespace issues that my editor was highlighting, like extra end-of-line space or random embedded

Re: [gentoo-dev] portage reliance on GNU objcopy ownership perseverance behavior in strip

On Thu, 2021-02-04 at 16:09 -0800, Manoj Gupta wrote: > > What does everyone think of modifying usages of calls to strip and > objcopy > inside estrip so that file ownership is manually restored. e.g > > owner=$(stat -U file) > group=$(stat -G file) > strip > chown owner:group file > This is

Re: [gentoo-dev] [RFC] Moving subslot-only virtuals to a separate category to reduce confusion

On Sat, 2021-01-30 at 18:35 +0100, Michał Górny wrote: > > To make this SOVERSION-virtual concept more visible and easily > distinguishable from regular virtuals, I'd like to propose that we > start > moving them into a dedicated category. For example, 'lib-sover' > comes > to my mind. While

[gentoo-dev] [PATCH] xorg-3.eclass: Call einstalldocs when not using XORG_MULTILIB

DOCS only got installed from the multilib-minimal_src_install call, so they were missing from non-multilib packages. This corrects a behavior difference from xorg-2.eclass where autotools-utils.eclass installed DOCS for the non-multilib case. Signed-off-by: David Michael --- eclass/xorg-3

Re: [gentoo-dev] [PATCH] vala.eclass: make has_version aware of ROOT for EAPI 7

On Thu, Jan 7, 2021 at 3:42 AM Mart Raudsepp wrote: > Ühel kenal päeval, K, 06.01.2021 kell 19:27, kirjutas Matt Turner: > > From: David Michael > > The vala dependencies are declared in BDEPEND since EAPI 7 so that > > the valac command is natively executabl

Re: [gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default

On 1/4/21 1:20 PM, Michał Górny wrote: Most importantly, it doesn't resolve the core issue of 'we need to update home before merging reverse dependencies'. Quoth the devmanual, "if your package requires a user, you can no longer be sure of that user's home directory or its ownership and

Re: [gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default

On 1/4/21 1:23 PM, Thomas Deutschmann wrote: People like me could just ignore changed users if changes won't go live until you run said users-update command or make use of INSTALL_MASK. Changes wouldn't go live until you ran etc-update, and *then* users-update.

Re: [gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default

On 1/4/21 11:45 AM, James Cloos wrote: "RHJ" == Robin H Johnson writes: RHJ> The best I can come up with at the moment, is that any packaging should RHJ> detect if there are user modifications, and provide control to users RHJ> based on that fact. Exactly. Akin to etc-update. We could

Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

On 1/4/21 9:46 AM, Thomas Deutschmann wrote: So the main problem I see with doing this is that it becomes impossible to reliably make changes to a user in later ebuild revisions. He is obviously looking for a way to allow maintainers to change users afterwards. But if we tell people, "If you

Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

On 1/3/21 8:35 PM, Thomas Deutschmann wrote: Modifying an existing user is a bad default and makes Gentoo special because it is common for system administrators to make modifications to user (i.e. putting an user into another service's group to allow that user to access service in question) and

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

On 12/23/20 6:18 PM, Michael Orlitzky wrote: Using pkg-config has a related problem. If lua-5.1 is eselected and if the upstream build system runs $(pkg-config ... lua), it's going to get the information for lua-5.1, even if you're trying to build against lua-5.2. So, first I have to patch

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

On 12/23/20 4:51 PM, Mart Raudsepp wrote: Ühel kenal päeval, K, 23.12.2020 kell 07:49, kirjutas Michael Orlitzky:    AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"]) How do I pass the name "lua5.2" to that, without hacking configure.ac and running autoreconf? The on

Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve

On 12/23/20 6:04 PM, Aisha Tammy wrote: Yes, this sounds doable and should work > Only problem is that if there is an actual liblua.so with the proper SONAME available in /usr/lib64 (I dunno if Gentoo has any provider of liblua.so with that SONAME, IIRC SLOT=0 currently does that) then it will

Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve

On 12/23/20 1:14 PM, Aisha Tammy wrote: I've recently had the same problem for TACC/Lmod which uses autotools to get lua versions and lua.cpath and lua.path and did infact manage to push the horrendously large patch upstream -

Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve

On 12/23/20 12:13 PM, Jonathan Callen wrote: One way this could be done without breaking things might be to create a subdirectory of /usr/$(get_libdir) for each version of Lua and creating a liblua.a and/or liblua.so symlink in that directory pointing to the liblua${VERSION}.* file in

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

On 12/23/20 8:35 AM, Jaco Kroon wrote: Michael, I'm busy disecting what Marek has done for asterisk as I need to make that work for multiple versions of net-misc/asterisk-16.14.0-r100, not merely the one he did it for - perhaps that would be helpful for you as well? I don't know lua at all

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

On 12/23/20 4:09 AM, Marek Szuba wrote: I think what you are looking for is lua_get_shared_lib() from lua-utils.eclass. We have already got ebuilds in the tree which use it. Knowing the library name only helps if I patch the build system; that's what I'm getting at. The few packages where

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

On 12/22/20 6:15 PM, Marek Szuba wrote: Dear all, mail-filter/opendkim - committed ebuild needs one extra fix One last design issue that I ran into during the migration. The slotted lua ebuilds install the headers into subdirectories like /usr/include/lua5.2, but otherwise with their

Re: [gentoo-dev] GPG key refresh

On 12/15/20 11:11 AM, Thomas Deutschmann wrote: What do you mean exactly? For Gentoo tooling, only Gentoo keyservers are important and Gentoo no longer synchronizes with any other pool. "The Gentoo developer tooling explicitly checks the Gentoo keyserver pool with a much higher frequency"

Re: [gentoo-dev] GPG key refresh

On 12/15/20 10:27 AM, Thomas Deutschmann wrote: https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys#Submit_your_new_key_to_the_keyserver And FWIW this sentence is a little misleading if the SKS refresh frequency is zero =) The SKS keyserver pool

Re: [gentoo-dev] GPG key refresh

On 12/15/20 10:27 AM, Thomas Deutschmann wrote: Hi, what exactly did you do already? Did you uploaded to our internal key server? You can only upload through dev.gentoo.org, see

Re: [gentoo-dev] GPG key refresh

On 12/14/20 2:17 PM, Alec Warner wrote: I think you need to push to hkps://keys.gentoo.org Ok, did that. The error message specifically states, remote: *** None of your keys comply with GLEP 63. and GLEP63 says to upload your keys to the SKS keyservers. Does the

[gentoo-dev] GPG key refresh

I'm still getting this, $ git push --signed ... remote: 1C49724D229E93A2 [Michael Orlitzky ] [E] expire:short Expiration date is too close, please renew (is 2020-12-26 23:30:47, less than 14 days) remote: 1C49724D229E93A2:6F48D3DA05C2DADB [Michael Orlitzky ] [E] expire:short

[gentoo-dev] Last rites: x11-misc/albert

# Michael Palimaka (2020-12-13) # Buggy. Uncooperative upstream. # Masked for removal in 30 days. x11-misc/albert

Re: [gentoo-dev] Slotted Lua: 2020-12-04 status update

On 12/9/20 10:10 AM, Marek Szuba wrote: LUA_DEPS itself will not but the change of LUA_SINGLE_TARGET in the package in question will, same way other packages can be rebuilt on USE-flag changes. So lua has inherited the python approach of requiring everyone to use portage? =/

Re: [gentoo-dev] Slotted Lua: 2020-12-04 status update

On 12/7/20 9:11 AM, Marek Szuba wrote: On 2020-12-04 13:16, Marek Szuba wrote: Since a week ago the number of open bugs blocking the slotted-Lua tracker has been reduced from 119 to under 80. Updated count as of a few minutes ago: 64 open tickets! Full list:

[gentoo-dev] [PATCH] gnome2-utils.eclass: skip executing cross-compiled tools

d to exist while cross-compiling (e.g. gtk+ can't BDEPEND on itself, so the cross-compiled gtk+ can be installed before the native gtk+, which fails from gtk-query-immodules not existing). Closes: https://bugs.gentoo.org/757483 Signed-off-by: David Michael --- Hi, Here is an eclass patch to fix b

Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

On 11/26/20 5:57 PM, Thomas Deutschmann wrote: > > I disagree here: Packages installing tmpfiles configs requiring > recursive chown on each boot are doing something wrong from  my P.O.V. No argument there, but me thinking they're wrong doesn't stop people from doing it. > Note that hardlinks

Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

On 11/26/20 5:37 PM, Peter Stuge wrote: > Georgy Yakovlev wrote: >> I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles >> by the end of the week by updating virtual/tmpfiles ebuild. > > Michael Orlitzky wrote: >> Corollary: the tmpfil

Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

On 11/26/20 10:07 AM, Thomas Deutschmann wrote: > > Only root is allowed to write to these directories. In other words: To > exploit this, a malicious local user (or a remote attacker who already > gained user access) would have to trick root into creating specially > crafted tmpfiles config

Re: [gentoo-dev] [PATCH 0/1] depend.apache.eclass: support EAPI-7

On 11/3/20 11:25 AM, Marek Szuba wrote: The fact this eclass does not support EAPI-7 yet blocks migration of www-apache/mod_security to Lua eclasses. Seems simple enough to address though, likely simpler than adding EAPI-6 support to lua.eclass. It's likely broken in EAPI=7, because it was in

[gentoo-dev] [PATCH v2 2/2] selinux-policy-2.eclass: drop EAPI 5

Signed-off-by: David Michael --- Changes since v1: - Dropped unnecessary EAPI default value - Fixed eapply array awareness eclass/selinux-policy-2.eclass | 47 +- 1 file changed, 12 insertions(+), 35 deletions(-) diff --git a/eclass/selinux-policy-2.eclass

Re: [gentoo-dev] [PATCH 1/2] selinux-policy-2.eclass: add EAPI 7

On Tue, Nov 3, 2020 at 2:46 AM Ulrich Mueller wrote: > >>>>> On Mon, 02 Nov 2020, David Michael wrote: > > > +if [[ ${EAPI:-0} == [56] ]]; then > > Substituting 0 is not necessary here. I wrote it that way to match all other EAPI conditions in the file. I'll re

[gentoo-dev] [PATCH 1/2] selinux-policy-2.eclass: add EAPI 7

Closes: https://bugs.gentoo.org/748483 Signed-off-by: David Michael --- Hi, Please start allowing EAPI 7 SELinux policy ebuilds. Thanks. David eclass/selinux-policy-2.eclass | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/eclass/selinux-policy-2

[gentoo-dev] [PATCH 2/2] selinux-policy-2.eclass: drop EAPI 5

Signed-off-by: David Michael --- Grepping through the ebuilds using this eclass shows that they're all on EAPI 6. A bunch of workarounds could be dropped along with EAPI 5, but it isn't necessary to fix anything, so feel free to ignore this patch. eclass/selinux-policy-2.eclass | 38

Re: [gentoo-dev] [infra] Anti-spam changes: removal of malware patrol and other older ClamAV rules

On 2020-09-11 15:09, Robin H. Johnson wrote: > Hi, > > As a result of a recent high-impact [1] false positive spam detection in > Gentoo mail, we've disabled using the MalwarePatrol ruleset in Clamav > for spam detection for all inbound mail to @gentoo.org > All of these services produce killer

Re: [gentoo-dev] Re: [PATCH 1/2] acct-group.eclass: declare the missing dependency on shadow

On Wed, Sep 9, 2020 at 5:37 AM Alexis Ballier wrote: > On Tue, 8 Sep 2020 15:54:14 -0400 > David Michael wrote: > > > Hi, > > > > This fix might not be so straightforward. A configuration I tested > > hit a dependency loop with shadow -> pambase -> sys

[gentoo-dev] Re: [PATCH 1/2] acct-group.eclass: declare the missing dependency on shadow

Hi, This fix might not be so straightforward. A configuration I tested hit a dependency loop with shadow -> pambase -> systemd -> a bunch of groups -> shadow. It is possible to bootstrap around by emerging shadow with no USE flags first, but I don't know how acceptable it is to introduce new

Re: [gentoo-dev] [PATCH 1/2] acct-group.eclass: declare the missing dependency on shadow

On Tue, Sep 8, 2020 at 12:04 PM Michał Górny wrote: > On Tue, 2020-09-08 at 11:57 -0400, David Michael wrote: > > Signed-off-by: David Michael > > --- > > eclass/acct-group.eclass | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > >

[gentoo-dev] [PATCH 2/2] acct-user.eclass: declare the missing dependency on shadow

Signed-off-by: David Michael --- eclass/acct-user.eclass | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass index 56a4e83e8bf..96a076e106e 100644 --- a/eclass/acct-user.eclass +++ b/eclass/acct-user.eclass @@ -42,8 +42,12

[gentoo-dev] [PATCH 1/2] acct-group.eclass: declare the missing dependency on shadow

Signed-off-by: David Michael --- eclass/acct-group.eclass | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass index 19a378e0b06..56e6391ef42 100644 --- a/eclass/acct-group.eclass +++ b/eclass/acct-group.eclass @@ -34,8

Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

On 2020-09-07 08:47, Alessandro Barbieri wrote: > Being consistent in decision is hard I see. You're missing some context. In October of last year, a QA team member broke dependency resolution on a lot of systems by making the same sort of change that this patch proposes:

Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

On 2020-09-07 08:10, Ulrich Mueller wrote: >> This has caused dependency resolution problems in the past. The PMS >> implies a new revision, > > PMS says nothing about new revisions or revision bumps: > That is indeed what the word "implies" implies. > The devmanual [1] says that a revbump

Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

On 2020-09-07 02:14, Michał Górny wrote: > + > +Update all ebuilds not to reference the virtual. Since there is > +no urgent need to remove the virtual from user systems > +and the resulting rebuilds would be unnecessary, do not bump ebuilds > +when replacing the dependency. > +

Re: [gentoo-dev] Please port your packages to Python 3.8

On 2020-09-04 09:22, Rich Freeman wrote: > > Current Gentoo policy: > > ...if the changes are likely to cause problems for end users." If you're willing to ignore the user reports of problems, and ignore the mailing list threads telling you that it will cause problems, and avoid running any

Re: [gentoo-dev] Please port your packages to Python 3.8

On 2020-09-04 08:54, Alexis Ballier wrote: > > py37 will (*) still be installed as it cannot be depcleaned because of > 1. emerge won't fail since deps are satisfied. > > > (*) or rather should, but I think the only case that matters is a valid > system state where noone forced uninstall of a

<    1   2   3   4   5   6   7   8   9   10   >