[gentoo-dev] Last rites: www-misc/log-toolkit

2024-06-13 Thread Arthur Zamarin
# Arthur Zamarin (2024-06-14) # EAPI=6, maintainer-needed, no reverse dependencies. # Removal on 2024-07-14. Bugs #934227, #898840. www-misc/log-toolkit OpenPGP_signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function

2024-06-13 Thread Lucio Sauer
On Thu, Jun 13, 2024 at 04:03:44PM +0100, James Le Cuirot wrote: > Several Cargo-based ebuilds cannot use cargo_src_install for various > reasons and manually install binaries from within the target directory > instead. It is common to see `target/$(usex debug debug release)`, but > this lacks the

[gentoo-dev] [PATCH v2] toolchain-funcs.eclass: Add tc-has-64bit-time_t

2024-06-13 Thread Michał Górny
Add a helper function to check whether time_t is 64-bit. This could be used e.g. to deselect tests that rely on timestamps exceeding Y2k38. It is meant to be more future-proof than hardcoding a list of 32-bit architectures, given the necessity of switching to 64-bit time_t in the future. Signed-o

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-has-64bit-time_t

2024-06-13 Thread Michał Górny
On Thu, 2024-06-13 at 17:44 +0100, James Le Cuirot wrote: > On Thu, 2024-06-13 at 17:23 +0200, Michał Górny wrote: > > Add a helper function to check whether time_t is 64-bit. This could > > be used e.g. to deselect tests that rely on timestamps exceeding Y2k38. > > It is meant to be more future-p

[gentoo-dev] Last rites: app-misc/blink1

2024-06-13 Thread Arthur Zamarin
# Arthur Zamarin (2024-06-13) # EAPI=6, maintainer-needed, waiting for a bump, various failures # with modern C. # Removal on 2024-07-13. Bugs #934200, #711348, #726634, #831750. app-misc/blink1 OpenPGP_signature.asc Description: OpenPGP digital signature

[gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function

2024-06-13 Thread James Le Cuirot
Several Cargo-based ebuilds cannot use cargo_src_install for various reasons and manually install binaries from within the target directory instead. It is common to see `target/$(usex debug debug release)`, but this lacks the target ABI when cross-compiling, so provide a helper function. There are

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-has-64bit-time_t

2024-06-13 Thread Ulrich Mueller
> On Thu, 13 Jun 2024, Michał Górny wrote: > + "$(tc-getCC)" ${CFLAGS} ${CPPFLAGS} -c -x c - -o /dev/null <<-EOF > &>/dev/null IIUC, tc-getCC can return values like "x86_64-pc-linux-gnu-gcc -m32 -mfpmath=sse", so probably you want to lose the quotes there. Ulrich signature.asc Descrip

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-has-64bit-time_t

2024-06-13 Thread James Le Cuirot
On Thu, 2024-06-13 at 17:23 +0200, Michał Górny wrote: > Add a helper function to check whether time_t is 64-bit. This could > be used e.g. to deselect tests that rely on timestamps exceeding Y2k38. > It is meant to be more future-proof than hardcoding a list of 32-bit > architectures, given the n

[gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-has-64bit-time_t

2024-06-13 Thread Michał Górny
Add a helper function to check whether time_t is 64-bit. This could be used e.g. to deselect tests that rely on timestamps exceeding Y2k38. It is meant to be more future-proof than hardcoding a list of 32-bit architectures, given the necessity of switching to 64-bit time_t in the future. Signed-o

Re: [gentoo-dev] [PATCH v3 0/1] greadme.eclass: new eclass

2024-06-13 Thread Florian Schmaus
On 13/06/2024 13.59, Ionen Wolkens wrote: On Thu, Jun 13, 2024 at 10:39:24AM +0200, Florian Schmaus wrote: Following up on the discussion of the last patchset, this - moves the functionally into a new eclass, as adjusting the existing eclass to export new phase functions is not viable. - excl

Re: [gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass

2024-06-13 Thread Florian Schmaus
On 13/06/2024 11.31, Ulrich Mueller wrote: On Thu, 13 Jun 2024, Florian Schmaus wrote: +# Copyright 1999-2024 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +# @ECLASS: greadme.eclass +# @MAINTAINER: +# Florian Schmaus +# @AUTHOR: +# Author: Florian Schmaus

Re: [gentoo-dev] [PATCH v3 0/1] greadme.eclass: new eclass

2024-06-13 Thread Ionen Wolkens
On Thu, Jun 13, 2024 at 10:39:24AM +0200, Florian Schmaus wrote: > Following up on the discussion of the last patchset, this > - moves the functionally into a new eclass, as adjusting the existing > eclass to export new phase functions is not viable. > - excludes the README.gentoo from decompress

Re: [gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass

2024-06-13 Thread Ulrich Mueller
> On Thu, 13 Jun 2024, Ulrich Mueller wrote: >> +if $append; then > Please use the conventional coding style, i.e. ${append}. Or rather, assign the variable to empty or non-empty and test for [[ -n ${append} ]] instead of executing it as a true or false command. (I'm pretty sure that th

Re: [gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass

2024-06-13 Thread Florian Schmaus
On 13/06/2024 12.42, Ulrich Mueller wrote: On Thu, 13 Jun 2024, Florian Schmaus wrote: +_GREADME_DOC_DIR="usr/share/doc/${PF}" It is somewhat unusual to call insinto or docompress with a relative path. I'd use "/usr/share/doc/${PF}" here. +_GREADME_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_FIL

Re: [gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass

2024-06-13 Thread Ulrich Mueller
> On Thu, 13 Jun 2024, Florian Schmaus wrote: >>> +_GREADME_DOC_DIR="usr/share/doc/${PF}" >> It is somewhat unusual to call insinto or docompress with a relative >> path. I'd use "/usr/share/doc/${PF}" here. >> >>> +_GREADME_REL_PATH="${_GREADME_DOC_DIR}/${_GREADME_FILENAME}" >> Why must this

Re: [gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass

2024-06-13 Thread Ulrich Mueller
> On Thu, 13 Jun 2024, Florian Schmaus wrote: > +# Copyright 1999-2024 Gentoo Authors > +# Distributed under the terms of the GNU General Public License v2 > + > +# @ECLASS: greadme.eclass > +# @MAINTAINER: > +# Florian Schmaus > +# @AUTHOR: > +# Author: Florian Schmaus > +# @SUPPORTED_EAPIS

[gentoo-dev] [PATCH v3 0/1] greadme.eclass: new eclass

2024-06-13 Thread Florian Schmaus
Following up on the discussion of the last patchset, this - moves the functionally into a new eclass, as adjusting the existing eclass to export new phase functions is not viable. - excludes the README.gentoo from decompression, as all other presented approaches add complexity and cause additio

[gentoo-dev] [PATCH v3 1/1] greadme.eclass: new eclass

2024-06-13 Thread Florian Schmaus
This new eclass includes various improvements over the existing readme.gentoo-r1.eclass. First, the content of README.gento will only be shown on new installations or if it has changed between updates. Second, it allows the composition of readme via bash's heredoc. Third, it exports phase functi