Re: [gentoo-dev] Require opt-in for bitcoin upgrade?
On 2021-07-10 17:18, William Hubbs wrote: To update everyone involved in this, please read my last comment on the pr. Basically, this can be treated like a test version by adding it to package.mask with an appropriate message then maybe publishing a newsitem if the maintainer wants it to be known by other users. William IMHO, a news item is a bit much... I feel that the package.mask message is sufficient. Huge thank you to all participants for discussing the topic and coming up with the package.mask idea! Here's a PR which is hopefully agreeable: https://github.com/gentoo/gentoo/pull/21587 ~Craig
[gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables
Change the _R0 suffix on these variable names to _ECLASS.
Signed-off-by: William Hubbs
---
eclass/lua-single.eclass | 10 +++---
eclass/lua-utils.eclass | 8
eclass/lua.eclass| 12 +---
3 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index ab4fdb3c75a..5e1ee936c12 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.eclass
@@ -68,16 +68,15 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
-if [[ ! ${_LUA_SINGLE_R0} ]]; then
+if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
+_LUA_SINGLE_ECLASS=1
-if [[ ${_LUA_R0} ]]; then
+if [[ ${_LUA_ECLASS} ]]; then
die 'lua-single.eclass cannot be used with lua.eclass.'
fi
inherit lua-utils
-fi
-
EXPORT_FUNCTIONS pkg_setup
# @ECLASS-VARIABLE: LUA_COMPAT
@@ -275,8 +274,6 @@ _lua_single_set_globals() {
_lua_single_set_globals
unset -f _lua_single_set_globals
-if [[ ! ${_LUA_SINGLE_R0} ]]; then
-
# @FUNCTION: _lua_gen_usedep
# @USAGE: [...]
# @INTERNAL
@@ -531,5 +528,4 @@ lua-single_pkg_setup() {
[[ ${MERGE_TYPE} != binary ]] && lua_setup
}
-_LUA_SINGLE_R0=1
fi
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 278bbca58a3..52ba290e544 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -23,7 +23,7 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
-if [[ ! ${_LUA_UTILS_R0} ]]; then
+if [[ ! ${_LUA_UTILS_ECLASS} ]]; then
inherit toolchain-funcs
@@ -376,7 +376,7 @@ lua_enable_tests() {
busted)
test_directory="${2:-spec}"
test_pkg="dev-lua/busted"
- if [[ ! ${_LUA_SINGLE_R0} ]]; then
+ if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
eval "lua_src_test() {
busted --lua=\"\${ELUA}\"
--output=\"plainTerminal\" \"${test_directory}\" || die \"Tests fail with
\${ELUA}\"
}"
@@ -395,7 +395,7 @@ lua_enable_tests() {
local test_deps=${RDEPEND}
if [[ -n ${test_pkg} ]]; then
- if [[ ! ${_LUA_SINGLE_R0} ]]; then
+ if [[ ! ${_LUA_SINGLE_ECLASS} ]]; then
test_deps+=" ${test_pkg}[${LUA_USEDEP}]"
else
test_deps+=" $(lua_gen_cond_dep "
@@ -528,5 +528,5 @@ lua_get_version() {
echo "${LUA_VERSION}"
}
-_LUA_UTILS_R0=1
+_LUA_UTILS_ECLASS=1
fi
diff --git a/eclass/lua.eclass b/eclass/lua.eclass
index e9a5c117560..3b0816f9834 100644
--- a/eclass/lua.eclass
+++ b/eclass/lua.eclass
@@ -56,9 +56,10 @@ case ${EAPI} in
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
-if [[ ! ${_LUA_R0} ]]; then
+if [[ ! ${_LUA_ECLASS} ]]; then
+_LUA_ECLASS=1
-if [[ ${_LUA_SINGLE_R0} ]]; then
+if [[ ${_LUA_SINGLE_ECLASS} ]]; then
die 'lua.eclass cannot be used with lua-single.eclass.'
fi
@@ -196,8 +197,6 @@ fi
# lua_targets_lua5-1(-)?,lua_targets_lua5-2(-)?
# @CODE
-if [[ ! ${_LUA_R0} ]]; then
-
# @FUNCTION: _lua_validate_useflags
# @INTERNAL
# @DESCRIPTION:
@@ -313,9 +312,6 @@ lua_foreach_impl() {
multibuild_foreach_variant _lua_multibuild_wrapper "${@}"
}
-_LUA_R0=1
-fi
-
# @FUNCTION: _lua_set_globals
# @INTERNAL
# @DESCRIPTION:
@@ -374,3 +370,5 @@ _lua_set_globals() {
_lua_set_globals
unset -f _lua_set_globals
+
+fi
--
2.31.1
Re: [gentoo-dev] Require opt-in for bitcoin upgrade?
To update everyone involved in this, please read my last comment on the pr. Basically, this can be treated like a test version by adding it to package.mask with an appropriate message then maybe publishing a newsitem if the maintainer wants it to be known by other users. William signature.asc Description: PGP signature
Re: [gentoo-dev] Require opt-in for bitcoin upgrade?
Hey All, I'm responding again because I saw that I left Luke off of my original message and I cleaned up my steps a bit. We talked about this on the irc channel, and several of us feel that you don't need anything special in the ebuild at all, you can do this via package.mask and a newsitem. I suggest the following assuming that the older version will stop working when the network is fully upgraded. - Publish a newsitem explaining this issue. - After the newsitem is published, Commit the newer version under package.mask with the mask message being an explanation of the issue. - at this point, if people want to opt in, they can unmask the newer version and add it to package.accept_keywords. - Once the network is upgraded, unmask the newer version (and you might have to fast stable if the older version doesn't work). - If I understand correctly, at this point, opting in isn't optional since the network is upgraded, so if people don't want to use the new algo they can't use bitcoin. That will give everyone time to see the newsitem before the newer version hits. It seems like this is the best you can do since upstream is doing a hard switchover to the new algo. William signature.asc Description: PGP signature
Re: [gentoo-dev] Require opt-in for bitcoin upgrade?
On Sat, Jul 10, 2021 at 11:42:28AM -0400, Craig Andrews wrote: > Gentoo currently has a number of packages required to run a bitcoin node > in its tree, including: > * net-libs/libbitcoinconsensus > * net-p2p/bitcoin-qt > * net-p2p/bitcoind > > In version 0.21.1, bitcoin included a consensus algorithm changed call > taproot. There is no configuration opt-in with this change; bitcoin < > 0.21.1 does not include taproot, bitcoin >= 0.21.1 does include taproot. > > A PR [1] was created the bitcoin packaging proxy maintainer (Like > Dash-Jr, CC'ed) for the bitcoin 0.21.1 version bump. In that PR, Luke > insists that users must explicitly opt-in to the bitcoin 0.21.1 upgrade > because of the taproot consensus algorithm change. I encourage > interested parties to read the conversation in that PR to get the full > context. > > * This is a minor version bump (assuming semver, this is the "patch" > level version change in bitcoin), indicating that upstream does not > consider this to be a major/breaking change. > * Upstream does not have a mechanism for notifying users or requiring > them to opt-in to this change > * Upstream does not have a mechanism to opt out of this change. The > users only option is to develop their own fork of the bitcoin software > or never upgrade the package if they want to avoid taproot. > * Taproot was locked by miners, so the network will be upgrading [2] I suggest the following: 1) a newsitem explaining this issue. 2) at the same time, package.mask the newer version temporarily and keep the older version in the tree. 3) Once the network is upgraded, unmask the newer version and drop the older version. If people want the older version at that point and write a fork, you'll have to rename itt. > > Therefore, I have a few questions for the fellow Gentoo developers: > 1) Should we require users to explicitly opt-in to this upgrade beyond > the usual? > 2) If so, how do we do that? I have been unable to find any > documentation or examples of existing packages that require explicit > upgrade opt-in. A REQUIRED_USE or a LICENSE [3] were suggested as well > as PROPERTIES="interactive" [4], but such approaches seem like > unintended/unconventional abuses of those settings as well as annoying > to the user. If you do, I think you can do it the way I suggested without adding extra things to the ebuild. > > My suggested approach was to notifying the user of the change in the > pkg_pretend phase [5] so they're aware before they actually upgrade; > however, the proxy maintainer disagreed and force a revert. [6] As far as I know proxy maintainers can't force anything; they defer to developers because we are the ones who are more familiar with the way the tree works. That being said, I still think the cleaner solution is to use a temporary package.mask along with a newsitem. Thanks, William signature.asc Description: PGP signature
[gentoo-dev] [PATCH] python-utils-r1.eclass: Cleanup cache dirs after epytest
Make epytest clean up common cache directories .hypothesis
and .pytest_cache after the execution. If pytest is executed
in ${BUILD_DIR}/lib, these directories end up being wrongly installed,
and so far ebuilds had to handle cleaning them up.
Signed-off-by: Michał Górny
---
eclass/python-utils-r1.eclass | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 168c767a2eea..b104b6694ac3 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1272,7 +1272,12 @@ epytest() {
echo "${@}" >&2
"${@}" || die -n "pytest failed with ${EPYTHON}"
- return ${?}
+ local ret=${?}
+
+ # remove common temporary directories left over by pytest plugins
+ rm -rf .hypothesis .pytest_cache || die
+
+ return ${ret}
}
# @FUNCTION: eunittest
--
2.32.0
[gentoo-dev] Require opt-in for bitcoin upgrade?
Gentoo currently has a number of packages required to run a bitcoin node in its tree, including: * net-libs/libbitcoinconsensus * net-p2p/bitcoin-qt * net-p2p/bitcoind In version 0.21.1, bitcoin included a consensus algorithm changed call taproot. There is no configuration opt-in with this change; bitcoin < 0.21.1 does not include taproot, bitcoin >= 0.21.1 does include taproot. A PR [1] was created the bitcoin packaging proxy maintainer (Like Dash-Jr, CC'ed) for the bitcoin 0.21.1 version bump. In that PR, Luke insists that users must explicitly opt-in to the bitcoin 0.21.1 upgrade because of the taproot consensus algorithm change. I encourage interested parties to read the conversation in that PR to get the full context. * This is a minor version bump (assuming semver, this is the "patch" level version change in bitcoin), indicating that upstream does not consider this to be a major/breaking change. * Upstream does not have a mechanism for notifying users or requiring them to opt-in to this change * Upstream does not have a mechanism to opt out of this change. The users only option is to develop their own fork of the bitcoin software or never upgrade the package if they want to avoid taproot. * Taproot was locked by miners, so the network will be upgrading [2] Therefore, I have a few questions for the fellow Gentoo developers: 1) Should we require users to explicitly opt-in to this upgrade beyond the usual? 2) If so, how do we do that? I have been unable to find any documentation or examples of existing packages that require explicit upgrade opt-in. A REQUIRED_USE or a LICENSE [3] were suggested as well as PROPERTIES="interactive" [4], but such approaches seem like unintended/unconventional abuses of those settings as well as annoying to the user. My suggested approach was to notifying the user of the change in the pkg_pretend phase [5] so they're aware before they actually upgrade; however, the proxy maintainer disagreed and force a revert. [6] Thank you for your consideration and assistance with this issue, ~Craig [1] https://github.com/gentoo/gentoo/pull/21490 [2] https://taproot.watch/ [3] https://github.com/gentoo/gentoo/pull/21490#discussion_r663201705 [4] https://github.com/gentoo/gentoo/pull/21490#issuecomment-877542346 [5] https://github.com/gentoo/gentoo/commit/e62b85aae5a2dd70ff120ebc284bf6d461e34b88#diff-e5afbd0e114be010e271302d0807aba076083d0e623ddd611f7e80b4b02a1c82R91 [6] https://github.com/gentoo/gentoo/pull/21490#issuecomment-877531697 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH 0/6] haskell eclass update to EAPI=8, old EAPI={0..5} removal
On Mon, 5 Jul 2021 23:25:50 +0100
Sergei Trofimovich wrote:
> The changes are mostly code removal. And example ebuild.
>
> Sergei Trofimovich (6):
> haskell-cabal.eclass: drop EAPI={0..5} support
> ghc-package.eclass: drop EAPI={0..5} support
> ghc-package.eclass: allow EAPI=8
> haskell-cabal.eclass: allow EAPI=8
> haskell-cabal.eclass: foo
> dev-haskell/c2hs: bump up to 0.28.8, EAPI=8 example
>
> dev-haskell/c2hs/Manifest | 1 +
> dev-haskell/c2hs/c2hs-0.28.8.ebuild | 41 +++
> eclass/ghc-package.eclass | 6 ++--
> eclass/haskell-cabal.eclass | 43 -
> 4 files changed, 56 insertions(+), 35 deletions(-)
> create mode 100644 dev-haskell/c2hs/c2hs-0.28.8.ebuild
Pushed to ::gentoo as:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=891aa19d14688a95171dc6dcf14ce08d6ab237c5
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3feb01a7824b169ba1d35b997784c731fca9ac0f
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3cef7dc7c93537384dddf71cf96f57931467644d
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fa8928997d917f74894c7013708c7c177a7bfa23
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fff0ee1b6c74df5f1598f5a2874fb67cfe09250b
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ba01bd910d9667dbc7a1a80873ec3a23d897ed62
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df37ce46d2a17ed3c4225bce7c506931d98af59b
--
Sergei
Re: [gentoo-dev] [PATCH 1/5] haskell-cabal.eclass: drop EAPI={0..5} support
On Tue, 06 Jul 2021 09:34:14 +0200
Ulrich Mueller wrote:
> > On Tue, 06 Jul 2021, Sergei Trofimovich wrote:
>
> > case "${EAPI:-0}" in
>
> This could be just ${EAPI} now (and quotes were never necessary).
>
> > - 0|1) ;;
> > - 2|3|4|5|6|7) HASKELL_CABAL_EXPF+=" src_configure" ;;
> > + 6|7) ;;
> > *) die "EAPI ${EAPI} unsupported." ;;
>
>
> I'd suggest to update to die message to what is used in other eclasses
> (see toolchain-funcs.eclass for example):
>
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
>
> > esac
>
> Same comment for the other eclasses of this series.
>
> Ulrich
Sounds good. Done both as:
--- a/eclass/haskell-cabal.eclass
+++ b/eclass/haskell-cabal.eclass
@@ -40,11 +40,11 @@
# FEATURE can be removed once
https://github.com/haskell/cabal/issues/7213
# is fixed.
-case "${EAPI:-0}" in
+case ${EAPI} in
# eutils is for eqawarn
6|7) inherit eutils ;;
8) ;;
- *) die "EAPI ${EAPI} unsupported." ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
inherit ghc-package multilib toolchain-funcs
--
Sergei
pgpf8CE1FGmnS.pgp
Description: Цифровая подпись OpenPGP
