Re: [gentoo-dev] News item for upcoming Bitcoin consensus protocol change (Taproot)
On 2021-11-04 17:59, Luke Dashjr wrote: From 2ca9bb266d18e35e0dd5d14149bb9aa7f9eae792 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Thu, 4 Nov 2021 21:32:55 + Subject: [PATCH] 2021-11-04-bitcoin-taproot: add news item Signed-off-by: Luke Dashjr --- Due to the sensitive nature of changes to the Bitcoin consensus protocol[1], Bitcoin node software[2] implementing such a proposed change has been masked[3][4] since release and should remain such until it becomes clear that the upgrade has been accepted, activated, and is being enforced by users without any contentious disagreeing faction. This news item should ensure that users are aware of the change, and how to upgrade when/if they consent to it. Luke [1] users must actively act to change what they enforce; potentially significant financial risk; etc [2] net-p2p/bitcoind, net-p2p/bitcoin-qt, and net-libs/libbitcoinconsensus [3] the mask was erroneously removed a few weeks ago; this will hopefully be corrected ASAP, perhaps even before the news item gets posted. [4] Yes, there are probably better ways to handle things like this (and quite a few good suggestions at https://github.com/gentoo/gentoo/pull/21490), but using a mask is what we got stuck with this time. diff --git a/2021-11-04-bitcoin-taproot/2021-11-04-bitcoin-taproot.en.txt b/2021-11-04-bitcoin-taproot/2021-11-04-bitcoin-taproot.en.txt new file mode 100644 index 000..2136ec4 --- /dev/null +++ b/2021-11-04-bitcoin-taproot/2021-11-04-bitcoin-taproot.en.txt @@ -0,0 +1,30 @@ +Title: Bitcoin protocol change Taproot +Author: Luke Dashjr +Posted: 2021-11-04 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: || ( net-libs/libbitcoinconsensus net-p2p/bitcoin-qt net-p2p/bitcoind ) + +In a few weeks, the Bitcoin community will be attempting a change to the +consensus protocol, called "Taproot". Protocol changes to Bitcoin activate +contingent on the users of the network all agreeing together and enforcing +the new rules on each other. Failure to enforce new rules, or enforcing them +when others do not, compromises your security and may lead to using a +different currency than the rest of Bitcoin. Bitcoin users must each decide +if they will enforce the new Taproot changes, or reject them. + +To learn more about Taproot, see https://bitcointaproot.cc + +If you wish to enforce Taproot, you should unmask version 0.21.1 and/or 22.0. +For example: echo '~net-p2p/bitcoin-qt-0.21.1' >>/etc/portage/package.unmask + +If you wish to reject Taproot, neither Bitcoin Core or Knots intends to +support this, so you will need to create an upgrade path or find likeminded +developers who have already done so. Note that simply using an older version +is not a safe alternative: that will be insecure under all scenarios. + +When it becomes clear that Taproot has activated successfully and there is no +alternative, older versions will be removed and Taproot-enforcing versions +will be unmasked for all Gentoo users. If you wish to continue without +enforcing Taproot for whatever reason (but, again, this is NOT a secure way +to reject Taproot), ensure you have explicitly masked >=0.21.1 yourself. As previously discussed at https://github.com/gentoo/gentoo/pull/21490 we agreed that users would be kept informed via logs in the ebuilds and a package mask that would be lifted before the November 16 taproot activation date so users have time to upgrade. That mask was lifted as agreed in commit ae7251a476 on October 13, giving users just over a month to upgrade their bitcoin nodes. This news item is, in my opinion, useless, and should not be added. It basically says, "you must upgrade, as not upgrading is insecure and you have no other options to be secure. However, we made it hard for you to upgrade, so now you have to jump through these hoops." Also, the mask was just re-added ~10 minutes ago: https://github.com/gentoo/gentoo/pull/22818 I find the re-addition of the mask to be very frustrating. Now users who upgraded since October 13 may now be _downgraded_ and unexpectedly find themselves in an insecure state. Taproot is happening on November 16. The bitcoin project followed its defined process that took over a year to get this point. And yet, Luke is apparently now proposing that we have a package mask, a news item, and ebuild logs, all for a bitcoin version upgrade that the user must do to remain secure. Having this debate now, in Gentoo, 12 days before a cut-over that has been in the works - coordinated and approved by upstream for a year - is purely FUD and a disservice to our users. I say we remove the just re-added package mask immediately and not publish this news item. Thank you, ~Craig
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] 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] Last rites: media-plugins/kodi-vfs-sacd
# Craig Andrews (2021-07-09) # deprecated; replaced by media-plugins/kodi-audiodecoder-sacd # No reverse dependencies # See https://bugs.gentoo.org/801406 # Masked for removal in 30 days. media-plugins/kodi-vfs-sacd signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-p2p/xmr-stak
# Craig Andrews (2021-03-29) # Unmaintained upstream. # Project is also not useful due to changes in cryptocurrency mining. # Open security issue, bug #779004 # Removal on 2021-04-29, bug #779166 net-p2p/xmr-stak Thanks, ~Craig signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/3] dev-libs/rocm-opencl-runtime: do not force use of specific ICD loader
On 2020-04-08 11:28, Marek Szuba wrote:
Pending maintainer's approval.
Signed-off-by: Marek Szuba
---
dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild | 2 +-
dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild | 2 +-
dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild
b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild
index d965949c197..390f4de5e07 100644
--- a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild
+++ b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild
@@ -25,7 +25,7 @@ SLOT="0/$(ver_cut 1-2)"
RDEPEND=">=dev-libs/rocr-runtime-${PV}
>=dev-libs/rocm-comgr-${PV}
>=dev-libs/rocm-device-libs-${PV}
- dev-libs/ocl-icd[khronos-headers]
+ >=virtual/opencl-3
media-libs/mesa"
DEPEND="${RDEPEND}
dev-lang/ocaml
diff --git
a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild
b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild
index ec654ae4857..45a3fcd5324 100644
--- a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild
+++ b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild
@@ -25,7 +25,7 @@ SLOT="0/$(ver_cut 1-2)"
RDEPEND=">=dev-libs/rocr-runtime-${PV}
>=dev-libs/rocm-comgr-${PV}
>=dev-libs/rocm-device-libs-${PV}
- dev-libs/ocl-icd[khronos-headers]
+ >=virtual/opencl-3
media-libs/mesa"
DEPEND="${RDEPEND}
dev-lang/ocaml
diff --git
a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild
b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild
index ec654ae4857..45a3fcd5324 100644
--- a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild
+++ b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild
@@ -25,7 +25,7 @@ SLOT="0/$(ver_cut 1-2)"
RDEPEND=">=dev-libs/rocr-runtime-${PV}
>=dev-libs/rocm-comgr-${PV}
>=dev-libs/rocm-device-libs-${PV}
- dev-libs/ocl-icd[khronos-headers]
+ >=virtual/opencl-3
media-libs/mesa"
DEPEND="${RDEPEND}
dev-lang/ocaml
Assuming that you've compile-tested this change, I approve.
Thanks,
~Craig
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-admin/needrestart/
On 2020-03-09 01:46, Robin H. Johnson wrote:
Can you please clarify why you removed the last stable version of
app-admin/needrestart? Repoman used to warn about this, and I think
pkgcheck does as well.
On Sun, Mar 01, 2020 at 04:12:05PM +, Craig Andrews wrote:
commit: 50f6c4ac7c78b6c293308c84dbbeb30a5ebf1e05
Author: Craig Andrews gentoo org>
AuthorDate: Sun Mar 1 16:06:23 2020 +
Commit: Craig Andrews gentoo org>
CommitDate: Sun Mar 1 16:11:57 2020 +
URL:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=50f6c4ac
app-admin/needrestart: Cleanup old versions
...
diff --git a/app-admin/needrestart/needrestart-3.3.ebuild
b/app-admin/needrestart/needrestart-3.3.ebuild
deleted file mode 100644
index 2ba6e13ba34..000
--- a/app-admin/needrestart/needrestart-3.3.ebuild
+++ /dev/null
@@ -1,41 +0,0 @@
-# Copyright 1999-2018 Gentoo Foundation
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=6
-
-if [[ ${PV} == "" ]] ; then
- EGIT_REPO_URI="https://github.com/liske/${PN}.git;
- inherit git-r3
- SRC_URI=""
- KEYWORDS="amd64 x86"
-else
- SRC_URI="https://github.com/liske/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz"
- KEYWORDS="amd64 x86"
-fi
-
-DESCRIPTION="Restart daemons after library updates"
-HOMEPAGE="https://fiasko-nw.net/~thomas/tag/needrestart.html
https://github.com/liske/needrestart;
-
-SLOT="0"
-LICENSE="GPL-2+"
-
-RDEPEND="
- >=sys-apps/sed-4.2.2
- dev-lang/perl:=
- dev-perl/libintl-perl
- dev-perl/Module-Find
- dev-perl/Module-ScanDeps
- dev-perl/Proc-ProcessTable
- dev-perl/Sort-Naturally
- dev-perl/TermReadKey
- sys-apps/init-system-helpers
-"
-DEPEND="${RDEPEND}
- sys-devel/gettext
-"
-
-src_install() {
- default
- doman man/*.1
- dodoc -r ex
-}
Removal of that version was a mistake. Thank you for pointing it out.
Here's the commit re-adding it:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f3fa1c548
I checked, and repoman doesn't seem to be warning about removing the
last stable version of a package.
~Craig
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last-rites: dev-libs/rocm-opencl-driver
# Craig Andrews (2020-03-03) # Deprecated upstream in favor of dev-libs/rocm-comgr # Masked for removal in 30 days. Bug #711398 dev-libs/rocm-opencl-driver Thanks, ~Craig signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: UID/GID assignment for shellinabox (139)
I would like to reserve UID/GID 139 for shellinabox (www-misc/shellinabox) Debian, Fedora, and Red Hat do not have UID/GIDs reserved for shellinabox. FreeBSD [1] uses 139 so that's what I'm requesting. Gentoo API [2] shows these numbers are currently unused. Here's a PR for this change: https://github.com/gentoo/gentoo/pull/14046 [1] https://svnweb.freebsd.org/ports/head/GIDs?view=co [2] https://api.gentoo.org/uid-gid.txt Thanks, ~Craig signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: net-misc/curl: HTTP/3 support
On 10.10.2019 16:38, Mike Gilbert wrote: On Thu, Oct 10, 2019 at 4:03 PM Craig Andrews wrote: I'm working on getting HTTP/3 support in place for curl: https://github.com/gentoo/gentoo/pull/12920 Yes, HTTP/3 isn't final yet. But we're Gentoo - that shouldn't stop us! My proposal involves: * A new USE_EXPAND, CURL_HTTP3, with two values: nghttp3 and quiche Why do we need a USE_EXPAND for this? Will more than one package ever use it? If it's only ever going to be referenced by net-misc/curl, just add local USE flags. Since I've received such a response from a few folks, I've updated the PR to not use USE_EXPAND and instead use local USE flags. Thanks for the feedback, ~Craig signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: UID/GID assignment for deluge (545/545)
On 10.10.2019 04:59, Ulrich Mueller wrote: On Wed, 09 Oct 2019, Craig Andrews wrote: I would like to reserve UID/GID 545 for deluge (net-p2p/deluge). We currently use dynamic UID/GIDs. As far as I can tell, UID/GID 545 is free [1] [1] https://api.gentoo.org/uid-gid.txt No, there's this line: - 500..999 500..999 reserved I noticed that just after sending the email. Thank you for pointing it out. 454/454 is free, let's go with that. I've updated the PR as well. Thanks, ~Craig signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: UID/GID assignment for deluge (545/545)
I would like to reserve UID/GID 545 for deluge (net-p2p/deluge). We currently use dynamic UID/GIDs. As far as I can tell, UID/GID 545 is free [1] Here's a PR for this change [2] [1] https://api.gentoo.org/uid-gid.txt [2] https://github.com/gentoo/gentoo/pull/13241 Thanks, ~Craig signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: UID/GID assignment for netdata (290/290)
I would like to reserve UID/GID 290 for netdata (net-analyzer/netdata) We currently use dynamic UID/GIDs. Upstream uses 201/201 [1] but Gentoo already uses that for qmail [2], so I've randomly selected new UIDs/GIDs (290/290). Here's a PR for this change [3]. [1] https://github.com/netdata/netdata/blob/e2e20dad1fc29dcd6bd76b6dc50c80045d0a2956/packaging/docker/Dockerfile#L59 [2] https://api.gentoo.org/uid-gid.txt [3] https://github.com/gentoo/gentoo/pull/12910 Thanks, ~Craig signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: UID/GID assignment for ntp (123)
I would like to reserve UID/GID 123 for ntp (net-misc/ntp) These fixed IDs are what we are currently using. Here's a PR for this change: https://github.com/gentoo/gentoo/pull/12802 Thanks, ~Craig signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: www-apache/mod_authnz_external
On 31.03.2019 04:15, Michał Górny wrote: # Michał Górny (31 Mar 2019) # Unmaintained. The current version is apparently broken, and it is # unclear if the problem was ever fixed upstream. Last release in 2011, # with low commit activity since. # Removal in 30 days. Bug #389391. www-apache/mod_authnz_external I'm pretty sure that https://bugs.gentoo.org/389391 was resolved years ago. I actually recall encountering it way back when and I definitely do not experience that issue now. With that said, I use this package, it works, and I don't think it really needs much maintenance. So I'll take it over. Thanks, ~Craig signature.asc Description: OpenPGP digital signature
[gentoo-dev] How to handle ROC forks of llvm and clang
I'm working on packaging the Radeon Open Compute (ROC) packages for Gentoo with first goal being to get the OpenCL runtime working. The OpenCL runtime can be found at: https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime It has a mess of dependencies; I can handle most of them (not that it'll be easy, but at least I know what to do). The 3 troublemakers I'd like to discuss are the ROC forks of: llvm: https://github.com/RadeonOpenCompute/llvm/ clang: https://github.com/RadeonOpenCompute/clang/ ldd: https://github.com/RadeonOpenCompute/ldd/ Potential approaches include: 1) Create new packages for each: sys-devel/radeon-open-compute-llvm, sys-devel/radeon-open-compute-clang, sys-devel/radeon-open-compute-lld 2) Add use flags to existing packages that apply the ROC changes as a patch 3) Add use flags to existing packages that use ROC archives as the SRC_URIs 4) Take the approach justxi did in his overlay which is to bundle these dependencies wherever they're needed; for example, take a look at https://github.com/justxi/rocm/blob/master/media-libs/ROCm-OpenCL-Runtime/ROCm-OpenCL-Runtime-1.7.0-r3.ebuild Personally, I dislike (4), as it's contrary to the bundling policy that Gentoo tries to follow. For (2), I'm concerned that generating and maintaining that patch may be really annoying and a lot of work. For (3), it's not great to have different base archives. Since ROC will eventually upstream all of it's work, (2) is ideal - but I have no idea what the timeline on that upstreaming effort may be, and I can't find anything that gives a hint. What is the best way forward? And what would be acceptable to the Gentoo LLVM project? Thanks, ~Craig signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking =dev-libs/openssl-1.1*
On 06.11.2018 12:53, Craig Andrews wrote: =dev-libs/openssl-1.1* has been masked since 26 Aug 2016 - that's over 2 years ago. I think it's time to talk about dropping the mask. The tracker issue https://bugs.gentoo.org/592438 currently has 12 open issues. Some will be closed by tree cleaning. package.mask also shows a number of packages being masked because their latest versions require >=dev-libs/openssl-1.1 What's the plan for removing this mask? Thanks, ~Craig I think we should make a plan for removing this mask. I'm not saying we do it today or tomorrow - but we should do it someday. Should we set a date for removing the mask? Should the tracker have 0 issues blocking it? Something else? Thanks, ~Craig signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] AUTHORS file for portage repository
On 27.11.2018 15:23, William Hubbs wrote: On Tue, Nov 27, 2018 at 09:15:08PM +0100, Michał Górny wrote: On Tue, 2018-11-27 at 14:07 -0600, William Hubbs wrote: > All, > I just picked a random msg to reply to on the thread. > > Here is the updated AUTHORS file I would like to commit. > You should include at least all current developers with commit access. Because otherwise, this really looks like all Gentoo work was done by the Foundation (which didn't do any work at all) and Sony, entirely neglecting the huge effort done by many individuals. No, that is definitely not the case. all devs aren't required to be listed; only those who want to be [1]. There is no way to contact everyone and see who wants to be listed, if someone wants to be listed they can let us know. William [1] https://opensource.google.com/docs/releasing/authors/ I think an AUTHORS file is very much a less than ideal solution. To point out the absurdity, please include me - It'll be nice to see only 3 names in the AUTHORS file with mine being first (hooray for alphabetical order!) Thanks, ~Craig signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: app-benchmarks/wrk, app-misc/gourmet, dev-python/elib-intl, games-misc/doge, net-misc/{httpie,proxytunnel}, sys-block/rts*
On 08.11.2018 07:15, Michał Górny wrote: Hello, The following packages are up for grabs after package reassignment of inactive developers: I'll take net-misc/proxytunnel Thanks, ~Craig signature.asc Description: OpenPGP digital signature
[gentoo-dev] Unmasking =dev-libs/openssl-1.1*
=dev-libs/openssl-1.1* has been masked since 26 Aug 2016 - that's over 2 years ago. I think it's time to talk about dropping the mask. The tracker issue https://bugs.gentoo.org/592438 currently has 12 open issues. Some will be closed by tree cleaning. package.mask also shows a number of packages being masked because their latest versions require >=dev-libs/openssl-1.1 What's the plan for removing this mask? Thanks, ~Craig
Re: [gentoo-dev] Unmasking >=media-video/ffmpeg-4.0
On 06.11.2018 06:00, Alexis Ballier wrote: On Mon, 05 Nov 2018 20:38:58 -0500 Craig Andrews wrote: I think it's time to remove the mask on >=media-video/ffmpeg-4.0 ffmpeg 4 is in many distros (including Debian, Arch) and FreeBSD. Upstreams are starting to require it, too. For example, Kodi 18 and media-plugins/gst-plugins-libav-16 will require it. The blocker issue https://bugs.gentoo.org/653678 has only 5 blockers against it right now: * 654628 has a pull request out to fix it: https://github.com/gentoo/gentoo/pull/10341 * 655170 is for a package that (IMHO) should be last-rited: media-libs/mediastreamer * 666166 is for a package that (IMHO) should be last-rited: media-plugins/vdr-image * 655442 and 658128 are for media-video/mplayer and fixed upstream, requiring a new snapshot release What do we say? Can we set a date when the hard mask will be removed? I think 6 months qualifies for ETIMEOUT, so go ahead and unmask it :) merge the github PR; I'll take care of mplayer Since Alexis added the mask I believe he can authorize its removal, so I have done so: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=deb9d06fb461dc57291498b327e2eeb667444a5f Thanks, ~Craig
[gentoo-dev] Unmasking >=media-video/ffmpeg-4.0
I think it's time to remove the mask on >=media-video/ffmpeg-4.0 ffmpeg 4 is in many distros (including Debian, Arch) and FreeBSD. Upstreams are starting to require it, too. For example, Kodi 18 and media-plugins/gst-plugins-libav-16 will require it. The blocker issue https://bugs.gentoo.org/653678 has only 5 blockers against it right now: * 654628 has a pull request out to fix it: https://github.com/gentoo/gentoo/pull/10341 * 655170 is for a package that (IMHO) should be last-rited: media-libs/mediastreamer * 666166 is for a package that (IMHO) should be last-rited: media-plugins/vdr-image * 655442 and 658128 are for media-video/mplayer and fixed upstream, requiring a new snapshot release What do we say? Can we set a date when the hard mask will be removed? Thanks, ~Craig signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH v2] libretro-core.eclass: An eclass to streamline the construction of Libretro core ebuilds
On 09.08.2018 16:58, Craig Andrews wrote:
I'm proposing the addition of a new eclass, libretro-core.eclass,
which I'll use when adding a number of libretro ebuilds.
This version incorporates all the changes and suggestions posed so far.
The pull request which includes this eclass as well as a few ebuilds
using it (with more to come) can be found at
https://github.com/gentoo/gentoo/pull/9330
Thanks,
~Craig
---
eclass/libretro-core.eclass | 197
1 file changed, 197 insertions(+)
create mode 100644 eclass/libretro-core.eclass
diff --git a/eclass/libretro-core.eclass b/eclass/libretro-core.eclass
new file mode 100644
index ..510f905111ce
--- /dev/null
+++ b/eclass/libretro-core.eclass
@@ -0,0 +1,197 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: libretro-core.eclass
+# @MAINTAINER:
+# candr...@gentoo.org
+# @AUTHOR:
+# Cecil Curry
+# Craig Andrews
+# @BLURB: Simplify libretro core ebuilds
+# @DESCRIPTION:
+# The libretro eclass is designed to streamline the construction of
+# ebuilds for Libretro core ebuilds.
+#
+# Libretro cores can be found under https://github.com/libretro/
+#
+# They all use the same basic make based build system, are located
+# in the same github account, and do not release named or numbered
+# versions (so ebuild versions for git commits are keys).
+# This eclass covers those commonalities reducing much duplication
+# between the ebuilds.
+# @EXAMPLE:
+# @CODE
+# EAPI=7
+#
+# LIBRETRO_CORE_NAME="2048"
+# LIBRETRO_COMMIT_SHA="45655d3662e4cbcd8afb28e2ee3f5494a75888de"
+# KEYWORDS="~amd64 ~x86"
+# inherit libretro-core
+#
+# DESCRIPTION="Port of 2048 puzzle game to the libretro API"
+# LICENSE="Unlicense"
+# SLOT="0"
+# @CODE
+
+if [[ -z ${_LIBRETRO_CORE_ECLASS} ]]; then
+_LIBRETRO_CORE_ECLASS=1
+
+IUSE="debug"
+
+# @ECLASS-VARIABLE: LIBRETRO_CORE_NAME
+# @REQUIRED
+# @DESCRIPTION:
+# Name of this Libretro core. The libretro-core_src_install() phase
function
+# will install the shared library
"${S}/${LIBRETRO_CORE_NAME}_libretro.so" as a
+# Libretro core. Defaults to the name of the current package excluding
the
+# "libretro-" prefix (e.g., "mgba" for the package "libretro-mgba").
+: ${LIBRETRO_CORE_NAME:=${PN#libretro-}}
+
+# @ECLASS-VARIABLE: LIBRETRO_COMMIT_SHA
+# @DESCRIPTION:
+# Commit SHA used for SRC_URI will die if not set in < ebuilds.
+# Needs to be set before inherit.
+
+# @ECLASS-VARIABLE: LIBRETRO_REPO_NAME
+# @REQUIRED
+# @DESCRIPTION:
+# Contains the real repo name of the core formatted as
"repouser/reponame".
+# Needs to be set before inherit. Otherwise defaults to
"libretro/${PN}"
+: ${LIBRETRO_REPO_NAME:="libretro/libretro-${LIBRETRO_CORE_NAME}"}
+
+: ${HOMEPAGE:="https://github.com/${LIBRETRO_REPO_NAME}"}
+
+if [[ ${PV} == * ]]; then
+ : ${EGIT_REPO_URI:="https://github.com/${LIBRETRO_REPO_NAME}.git"}
+ inherit git-r3
+else
+ [[ -z "${LIBRETRO_COMMIT_SHA}" ]] && die "LIBRETRO_COMMIT_SHA must
be set before inherit."
+ S="${WORKDIR}/${LIBRETRO_REPO_NAME##*/}-${LIBRETRO_COMMIT_SHA}"
+ :
${SRC_URI:="https://github.com/${LIBRETRO_REPO_NAME}/archive/${LIBRETRO_COMMIT_SHA}.tar.gz
-> ${P}.tar.gz"}
+fi
+inherit flag-o-matic
+
+# @ECLASS-VARIABLE: LIBRETRO_CORE_LIB_FILE
+# @REQUIRED
+# @DESCRIPTION:
+# Absolute path of this Libretro core's shared library.
+: ${LIBRETRO_CORE_LIB_FILE:="${S}/${LIBRETRO_CORE_NAME}_libretro.so"}
+
+case "${EAPI:-0}" in
+ 6|7)
+ EXPORT_FUNCTIONS src_unpack src_prepare src_compile src_install
+ ;;
+ *)
+ die "EAPI=${EAPI} is not supported" ;;
+esac
+
+# @FUNCTION: libretro-core_src_unpack
+# @DESCRIPTION:
+# The libretro-core src_unpack function which is exported.
+#
+# This function retrieves the remote Libretro core info files.
+libretro-core_src_unpack() {
+ # If this is a live ebuild, retrieve this core's remote repository.
+ if [[ ${PV} == * ]]; then
+ git-r3_src_unpack
+ # Add used commit SHA for version information, the above could also
work.
+ LIBRETRO_COMMIT_SHA=$(git -C "${WORKDIR}/${P}" rev-parse HEAD)
+ # Else, unpack this core's local tarball.
+ else
+ default_src_unpack
+ fi
+}
+
+# @FUNCTION: libretro-core_src_prepare
+# @DESCRIPTION:
+# The libretro-core src_prepare function which is exported.
+#
+# This function prepares the source by making custom modifications.
+libretro-core_src_prepare() {
+ ebegin "Attempting to hack Makefiles to use custom cflags"
+ # Populate COMMIT for GIT_VERSION
+ CUSTOM_LIBRETRO_COMMIT_SHA="\" $
[gentoo-dev] [PATCH v2] libretro-core.eclass: An eclass to streamline the construction of Libretro core ebuilds
I'm proposing the addition of a new eclass, libretro-core.eclass, which
I'll use when adding a number of libretro ebuilds.
This version incorporates all the changes and suggestions posed so far.
The pull request which includes this eclass as well as a few ebuilds
using it (with more to come) can be found at
https://github.com/gentoo/gentoo/pull/9330
Thanks,
~Craig
---
eclass/libretro-core.eclass | 197
1 file changed, 197 insertions(+)
create mode 100644 eclass/libretro-core.eclass
diff --git a/eclass/libretro-core.eclass b/eclass/libretro-core.eclass
new file mode 100644
index ..510f905111ce
--- /dev/null
+++ b/eclass/libretro-core.eclass
@@ -0,0 +1,197 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: libretro-core.eclass
+# @MAINTAINER:
+# candr...@gentoo.org
+# @AUTHOR:
+# Cecil Curry
+# Craig Andrews
+# @BLURB: Simplify libretro core ebuilds
+# @DESCRIPTION:
+# The libretro eclass is designed to streamline the construction of
+# ebuilds for Libretro core ebuilds.
+#
+# Libretro cores can be found under https://github.com/libretro/
+#
+# They all use the same basic make based build system, are located
+# in the same github account, and do not release named or numbered
+# versions (so ebuild versions for git commits are keys).
+# This eclass covers those commonalities reducing much duplication
+# between the ebuilds.
+# @EXAMPLE:
+# @CODE
+# EAPI=7
+#
+# LIBRETRO_CORE_NAME="2048"
+# LIBRETRO_COMMIT_SHA="45655d3662e4cbcd8afb28e2ee3f5494a75888de"
+# KEYWORDS="~amd64 ~x86"
+# inherit libretro-core
+#
+# DESCRIPTION="Port of 2048 puzzle game to the libretro API"
+# LICENSE="Unlicense"
+# SLOT="0"
+# @CODE
+
+if [[ -z ${_LIBRETRO_CORE_ECLASS} ]]; then
+_LIBRETRO_CORE_ECLASS=1
+
+IUSE="debug"
+
+# @ECLASS-VARIABLE: LIBRETRO_CORE_NAME
+# @REQUIRED
+# @DESCRIPTION:
+# Name of this Libretro core. The libretro-core_src_install() phase
function
+# will install the shared library
"${S}/${LIBRETRO_CORE_NAME}_libretro.so" as a
+# Libretro core. Defaults to the name of the current package excluding
the
+# "libretro-" prefix (e.g., "mgba" for the package "libretro-mgba").
+: ${LIBRETRO_CORE_NAME:=${PN#libretro-}}
+
+# @ECLASS-VARIABLE: LIBRETRO_COMMIT_SHA
+# @DESCRIPTION:
+# Commit SHA used for SRC_URI will die if not set in < ebuilds.
+# Needs to be set before inherit.
+
+# @ECLASS-VARIABLE: LIBRETRO_REPO_NAME
+# @REQUIRED
+# @DESCRIPTION:
+# Contains the real repo name of the core formatted as
"repouser/reponame".
+# Needs to be set before inherit. Otherwise defaults to
"libretro/${PN}"
+: ${LIBRETRO_REPO_NAME:="libretro/libretro-${LIBRETRO_CORE_NAME}"}
+
+: ${HOMEPAGE:="https://github.com/${LIBRETRO_REPO_NAME}"}
+
+if [[ ${PV} == * ]]; then
+ : ${EGIT_REPO_URI:="https://github.com/${LIBRETRO_REPO_NAME}.git"}
+ inherit git-r3
+else
+ [[ -z "${LIBRETRO_COMMIT_SHA}" ]] && die "LIBRETRO_COMMIT_SHA must be
set before inherit."
+ S="${WORKDIR}/${LIBRETRO_REPO_NAME##*/}-${LIBRETRO_COMMIT_SHA}"
+ :
${SRC_URI:="https://github.com/${LIBRETRO_REPO_NAME}/archive/${LIBRETRO_COMMIT_SHA}.tar.gz
-> ${P}.tar.gz"}
+fi
+inherit flag-o-matic
+
+# @ECLASS-VARIABLE: LIBRETRO_CORE_LIB_FILE
+# @REQUIRED
+# @DESCRIPTION:
+# Absolute path of this Libretro core's shared library.
+: ${LIBRETRO_CORE_LIB_FILE:="${S}/${LIBRETRO_CORE_NAME}_libretro.so"}
+
+case "${EAPI:-0}" in
+ 6|7)
+ EXPORT_FUNCTIONS src_unpack src_prepare src_compile src_install
+ ;;
+ *)
+ die "EAPI=${EAPI} is not supported" ;;
+esac
+
+# @FUNCTION: libretro-core_src_unpack
+# @DESCRIPTION:
+# The libretro-core src_unpack function which is exported.
+#
+# This function retrieves the remote Libretro core info files.
+libretro-core_src_unpack() {
+ # If this is a live ebuild, retrieve this core's remote repository.
+ if [[ ${PV} == * ]]; then
+ git-r3_src_unpack
+ # Add used commit SHA for version information, the above could also
work.
+ LIBRETRO_COMMIT_SHA=$(git -C "${WORKDIR}/${P}" rev-parse HEAD)
+ # Else, unpack this core's local tarball.
+ else
+ default_src_unpack
+ fi
+}
+
+# @FUNCTION: libretro-core_src_prepare
+# @DESCRIPTION:
+# The libretro-core src_prepare function which is exported.
+#
+# This function prepares the source by making custom modifications.
+libretro-core_src_prepare() {
+ ebegin "Attempting to hack Makefiles to use custom cflags"
+ # Populate COMMIT for GIT_VERSION
+ CUSTOM_LIBRETRO_COMMIT_SHA="\" ${LIBRETRO_COMMIT_SHA:0:7}\""
+ local makefil
[gentoo-dev] [PATCH] libretro-core.eclass: An eclass to streamline the construction of Libretro core ebuilds
I'm proposing the addition of a new eclass, libretro-core.eclass, which
I'll use when adding a number of libretro ebuilds.
The pull request which includes this eclass as well as a few ebuilds
using it (with more to come) can be found at
https://github.com/gentoo/gentoo/pull/9330
Thanks,
~Craig
---
eclass/libretro-core.eclass | 168
1 file changed, 168 insertions(+)
create mode 100644 eclass/libretro-core.eclass
diff --git a/eclass/libretro-core.eclass b/eclass/libretro-core.eclass
new file mode 100644
index ..c82420ac98cc
--- /dev/null
+++ b/eclass/libretro-core.eclass
@@ -0,0 +1,168 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: libretro-core.eclass
+# @MAINTAINER:
+# candr...@gentoo.org
+# @AUTHOR:
+# Cecil Curry
+# Craig Andrews
+# @BLURB: An eclass to streamline the construction of Libretro core
ebuilds
+# @DESCRIPTION:
+# The libretro eclass is designed to streamline the construction of
+# ebuilds for low-level Libretro core ebuilds.
+
+if [[ -z ${_LIBRETRO_CORE_ECLASS} ]]; then
+_LIBRETRO_CORE_ECLASS=1
+
+IUSE="debug"
+RDEPEND=" games-emulation/libretro-info"
+
+# @ECLASS-VARIABLE: LIBRETRO_CORE_NAME
+# @REQUIRED
+# @DESCRIPTION:
+# Name of this Libretro core. The libretro-core_src_install() phase
function
+# will install the shared library
"${S}/${LIBRETRO_CORE_NAME}_libretro.so" as a
+# Libretro core. Defaults to the name of the current package excluding
the
+# "libretro-" prefix (e.g., "mgba" for the package "libretro-mgba").
+: ${LIBRETRO_CORE_NAME:=${PN#libretro-}}
+
+# @ECLASS-VARIABLE: LIBRETRO_COMMIT_SHA
+# @DESCRIPTION:
+# Commit SHA used for SRC_URI will die if not set in < ebuilds.
+# Needs to be set before inherit.
+
+# @ECLASS-VARIABLE: LIBRETRO_REPO_NAME
+# @REQUIRED
+# @DESCRIPTION:
+# Contains the real repo name of the core formatted as
"repouser/reponame".
+# Needs to be set before inherit. Otherwise defaults to
"libretro/${PN}"
+: ${LIBRETRO_REPO_NAME:="libretro/libretro-${LIBRETRO_CORE_NAME}"}
+
+: ${HOMEPAGE:="https://github.com/${LIBRETRO_REPO_NAME}"}
+
+if [[ ${PV} == * ]]; then
+ : ${EGIT_REPO_URI:="https://github.com/${LIBRETRO_REPO_NAME}.git"}
+ inherit git-r3
+else
+ [[ -z "${LIBRETRO_COMMIT_SHA}" ]] && die "LIBRETRO_COMMIT_SHA must be
set before inherit."
+ S="${WORKDIR}/${LIBRETRO_REPO_NAME##*/}-${LIBRETRO_COMMIT_SHA}"
+ :
${SRC_URI:="https://github.com/${LIBRETRO_REPO_NAME}/archive/${LIBRETRO_COMMIT_SHA}.tar.gz
-> ${P}.tar.gz"}
+fi
+inherit flag-o-matic
+
+# @ECLASS-VARIABLE: LIBRETRO_CORE_LIB_FILE
+# @REQUIRED
+# @DESCRIPTION:
+# Absolute path of this Libretro core's shared library.
+: ${LIBRETRO_CORE_LIB_FILE:="${S}/${LIBRETRO_CORE_NAME}_libretro.so"}
+
+case "${EAPI:-0}" in
+ 6)
+ EXPORT_FUNCTIONS src_unpack src_prepare src_compile src_install
+ ;;
+ *)
+ die "EAPI=${EAPI} is not supported" ;;
+esac
+
+# @FUNCTION: libretro-core_src_unpack
+# @DESCRIPTION:
+# The libretro-core src_unpack function which is exported.
+#
+# This function retrieves the remote Libretro core info files.
+libretro-core_src_unpack() {
+ # If this is a live ebuild, retrieve this core's remote repository.
+ if [[ ${PV} == * ]]; then
+ git-r3_src_unpack
+ # Add used commit SHA for version information, the above could also
work.
+ LIBRETRO_COMMIT_SHA=$(git -C
"${EGIT3_STORE_DIR}/${LIBRETRO_REPO_NAME//\//_}.git" rev-parse HEAD)
+ # Else, unpack this core's local tarball.
+ else
+ default_src_unpack
+ fi
+}
+
+# @FUNCTION: libretro-core_src_prepare
+# @DESCRIPTION:
+# The libretro-core src_prepare function which is exported.
+#
+# This function prepares the source by making custom modifications.
+libretro-core_src_prepare() {
+ local flags_modified=0
+ ebegin "Attempting to hack Makefiles to use custom-cflags"
+ for makefile in "${S}"/?akefile* "${S}"/target-libretro/?akefile*; do
+ # * Convert CRLF to LF
+ # * Expand *FLAGS to prevent potential self-references
+ # * Where LDFLAGS directly define the link version
+ # script append LDFLAGS and LIBS
+ # * Where SHARED is used to provide shared linking
+ # flags ensure final link command includes LDFLAGS
+ # and LIBS
+ # * Always use $(CFLAGS) when calling $(CC)
+ sed \
+ -e 's/\r$//g' \
+ -e "/flags.*=/s/-O[[:digit:]]/${CFLAGS}/g" \
+ -e "/CFLAGS.*=/s/-O[[:digit:]]/${CFLAGS}/g" \
+
