[gentoo-dev] RFC: Update bitcoin eclass to default to knots

[gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Anthony G. Basile]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

Hi everyone,

I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
against the bitcoin eclass.  The following is his proposed change.  I'll
commit it after review.

--Tony


Bitcoin Knots includes a number of enhancements users may find useful. I
think  it would be a good idea to make it the default for Bitcoin
ebuilds (net-p2p/bitcoin-qt, net-p2p/bitcoind, and dev-util/bitcoin-tx).

Note that:
- The USE flag is being renamed from the old "ljr" to "knots" to reflect
the current naming.
- This does NOT enable the historically-controversial spamfilte 
BITCOIN_POLICY.
- Knots has since 0.12 (over a year old) included a clearly different
splash   screen and branding, so even if the user somehow misses the USE
flag change   and explicit src_prepare warning, it is clear upfront at
startup and runtime   that they are running Knots rather than Core.
- Old ebuilds are not being updated to minimise impact.

A patch against the current Portage tree is attached.

A bug tracker for this has been open for 2 months with no objections:
    https://bugs.gentoo.org/show_bug.cgi?id=604520

If there are no objections in the next week, we will move forward with 
deploying this change to the main Portage tree.

Please CC me on any replies, as I am not presently subscribed to the
mailing  list.

Thanks,

Luke

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : basile@freeharbor.net
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA


[-- Attachment #2: bitcoin-ebuilds-knots-default.patch --]
[-- Type: text/plain, Size: 9068 bytes --]

diff --git a/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild b/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
index ea538a2..1d56874 100644
--- a/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
+++ b/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
@@ -5,7 +5,7 @@ EAPI=5
 
 BITCOINCORE_COMMITHASH="0d719145b018e28d48d35c2646a5962b87c60436"
 BITCOINCORE_LJR_DATE="20170102"
-BITCOINCORE_IUSE="ljr"
+BITCOINCORE_IUSE="+knots"
 BITCOINCORE_NEED_LIBSECP256K1=1
 BITCOINCORE_NO_DEPEND="libevent"
 inherit bitcoincore
diff --git a/dev-util/bitcoin-tx/metadata.xml b/dev-util/bitcoin-tx/metadata.xml
index a686a21..16e544a 100644
--- a/dev-util/bitcoin-tx/metadata.xml
+++ b/dev-util/bitcoin-tx/metadata.xml
@@ -10,6 +10,7 @@
 		<name>Luke Dashjr</name>
 	</maintainer>
 	<use>
+		<flag name="knots">Build enhanced Bitcoin Knots version, rather than Bitcoin Core</flag>
 		<flag name="ljr">Enable Luke Dashjr's patches</flag>
 	</use>
 	<upstream>
diff --git a/eclass/bitcoincore.eclass b/eclass/bitcoincore.eclass
index 74cb2a3..6144fb8 100644
--- a/eclass/bitcoincore.eclass
+++ b/eclass/bitcoincore.eclass
@@ -37,7 +37,7 @@ fi
 
 EXPORT_FUNCTIONS src_prepare src_test src_install
 
-if in_bcc_iuse ljr || in_bcc_iuse 1stclassmsg || in_bcc_iuse zeromq || [ -n "$BITCOINCORE_POLICY_PATCHES" ]; then
+if in_bcc_iuse ljr || in_bcc_iuse knots || in_bcc_iuse 1stclassmsg || in_bcc_iuse zeromq || [ -n "$BITCOINCORE_POLICY_PATCHES" ]; then
 	EXPORT_FUNCTIONS pkg_pretend
 fi
 
@@ -53,7 +53,7 @@ if [[ ! ${_BITCOINCORE_ECLASS} ]]; then
 
 # @ECLASS-VARIABLE: BITCOINCORE_LJR_DATE
 # @DESCRIPTION:
-# Set this variable before the inherit line, to the datestamp of the ljr
+# Set this variable before the inherit line, to the datestamp of the Knots
 # patchset.
 
 # @ECLASS-VARIABLE: BITCOINCORE_POLICY_PATCHES
@@ -72,6 +72,7 @@ WALLET_DEPEND="sys-libs/db:$(db_ver_to_slot "${DB_VER}")[cxx]"
 LIBEVENT_DEPEND=""
 UNIVALUE_DEPEND=""
 BITCOINCORE_LJR_NAME=ljr
+BITCOINCORE_KNOTS_USE=knots
 [ -n "${BITCOINCORE_LJR_PV}" ] || BITCOINCORE_LJR_PV="${PV}"
 
 case "${PV}" in
@@ -87,8 +88,11 @@ case "${PV}" in
 	LIBSECP256K1_DEPEND="=dev-libs/libsecp256k1-0.0.0_pre20151118[recovery]"
 	UNIVALUE_DEPEND="dev-libs/univalue"
 	BITCOINCORE_LJR_NAME=knots
+	if in_bcc_iuse ljr; then
+		BITCOINCORE_KNOTS_USE=ljr
+	fi
 	if in_bcc_policy spamfilter; then
-		REQUIRED_USE="${REQUIRED_USE} bitcoin_policy_spamfilter? ( ljr )"
+		REQUIRED_USE="${REQUIRED_USE} bitcoin_policy_spamfilter? ( ${BITCOINCORE_KNOTS_USE} )"
 	fi
 	;;
 9999*)
@@ -201,9 +205,9 @@ DEPEND="${DEPEND} ${BITCOINCORE_COMMON_DEPEND}
 if [ "${BITCOINCORE_NEED_LEVELDB}" = "1" ]; then
 	RDEPEND="${RDEPEND} virtual/bitcoin-leveldb"
 fi
-if in_bcc_iuse ljr; then
+if in_bcc_iuse ${BITCOINCORE_KNOTS_USE}; then
 	if [ "${BITCOINCORE_LJR_NAME}" = "knots" ]; then
-		DEPEND="${DEPEND} ljr? ( dev-lang/perl )"
+		DEPEND="${DEPEND} ${BITCOINCORE_KNOTS_USE}? ( dev-lang/perl )"
 	fi
 fi
 
@@ -220,7 +224,7 @@ bitcoincore_policymsg() {
 
 bitcoincore_pkg_pretend() {
 	bitcoincore_policymsg_flag=false
-	if use_if_iuse ljr || use_if_iuse 1stclassmsg || use_if_iuse addrindex || use_if_iuse xt || { use_if_iuse zeromq && [ "${BITCOINCORE_MINOR}" -lt 12 ]; }; then
+	if use_if_iuse ${BITCOINCORE_KNOTS_USE} || use_if_iuse 1stclassmsg || use_if_iuse addrindex || use_if_iuse xt || { use_if_iuse zeromq && [ "${BITCOINCORE_MINOR}" -lt 12 ]; }; then
 		einfo "Extra functionality improvements to Bitcoin Core are enabled."
 		bitcoincore_policymsg_flag=true
 		if use_if_iuse addrindex addrindex; then
@@ -279,7 +283,7 @@ bitcoincore_prepare() {
 	else
 		epatch "$(LJR_PATCH syslibs)"
 	fi
-	if use_if_iuse ljr; then
+	if use_if_iuse ${BITCOINCORE_KNOTS_USE}; then
 		if [ "${BITCOINCORE_LJR_NAME}" = "knots" ]; then
 			bitcoincore_predelete_patch "$(LJR_PATCH f)"
 			bitcoincore_predelete_patch "$(LJR_PATCH branding)"
diff --git a/net-p2p/bitcoin-cli/bitcoin-cli-0.13.2.ebuild b/net-p2p/bitcoin-cli/bitcoin-cli-0.13.2.ebuild
index 84491e7..3018bb9 100644
--- a/net-p2p/bitcoin-cli/bitcoin-cli-0.13.2.ebuild
+++ b/net-p2p/bitcoin-cli/bitcoin-cli-0.13.2.ebuild
@@ -5,7 +5,7 @@ EAPI=5
 
 BITCOINCORE_COMMITHASH="0d719145b018e28d48d35c2646a5962b87c60436"
 BITCOINCORE_LJR_DATE="20170102"
-BITCOINCORE_IUSE="+ljr"
+BITCOINCORE_IUSE="+knots"
 inherit bash-completion-r1 bitcoincore
 
 DESCRIPTION="Command-line JSON-RPC client specifically designed for talking to Bitcoin Core Daemon"
diff --git a/net-p2p/bitcoin-cli/metadata.xml b/net-p2p/bitcoin-cli/metadata.xml
index a686a21..16e544a 100644
--- a/net-p2p/bitcoin-cli/metadata.xml
+++ b/net-p2p/bitcoin-cli/metadata.xml
@@ -10,6 +10,7 @@
 		<name>Luke Dashjr</name>
 	</maintainer>
 	<use>
+		<flag name="knots">Build enhanced Bitcoin Knots version, rather than Bitcoin Core</flag>
 		<flag name="ljr">Enable Luke Dashjr's patches</flag>
 	</use>
 	<upstream>
diff --git a/net-p2p/bitcoin-qt/bitcoin-qt-0.13.2.ebuild b/net-p2p/bitcoin-qt/bitcoin-qt-0.13.2.ebuild
index e87a052..0abf440 100644
--- a/net-p2p/bitcoin-qt/bitcoin-qt-0.13.2.ebuild
+++ b/net-p2p/bitcoin-qt/bitcoin-qt-0.13.2.ebuild
@@ -5,7 +5,7 @@ EAPI=5
 
 BITCOINCORE_COMMITHASH="0d719145b018e28d48d35c2646a5962b87c60436"
 BITCOINCORE_LJR_DATE="20170102"
-BITCOINCORE_IUSE="dbus kde +libevent ljr +qrcode qt5 +http test +tor upnp +wallet zeromq"
+BITCOINCORE_IUSE="dbus kde +libevent +knots +qrcode qt5 +http test +tor upnp +wallet zeromq"
 BITCOINCORE_POLICY_PATCHES="+rbf spamfilter"
 LANGS="af af_ZA ar be_BY bg bg_BG ca ca@valencia ca_ES cs cs_CZ cy da de el el_GR en en_GB eo es es_AR es_CL es_CO es_DO es_ES es_MX es_UY es_VE et et_EE eu_ES fa fa_IR fi fr fr_CA fr_FR gl he hi_IN hr hu id_ID it it_IT ja ka kk_KZ ko_KR ku_IQ ky la lt lv_LV mk_MK mn ms_MY nb ne nl nl_NL pam pl pt_BR pt_PT ro ro_RO ru ru_RU sk sl_SI sq sr sr@latin sv ta th_TH tr tr_TR uk ur_PK uz@Cyrl vi vi_VN zh zh_CN zh_HK zh_TW"
 KNOTS_LANGS="et_EE nl_NL"
@@ -32,18 +32,18 @@ RDEPEND="
 "
 DEPEND="${RDEPEND}
 	qt5? ( dev-qt/linguist-tools:5 )
-	ljr? (
+	knots? (
 		gnome-base/librsvg
 		media-gfx/imagemagick[png]
 	)
 "
 REQUIRED_USE="
 	http? ( libevent ) tor? ( libevent ) libevent? ( http tor )
-	!libevent? ( ljr )
+	!libevent? ( knots )
 "
 
 for lang in ${KNOTS_LANGS}; do
-	REQUIRED_USE="${REQUIRED_USE} linguas_${lang}? ( ljr )"
+	REQUIRED_USE="${REQUIRED_USE} linguas_${lang}? ( knots )"
 done
 
 src_prepare() {
@@ -53,7 +53,7 @@ src_prepare() {
 
 	for lan in $LANGS; do
 		if [ ! -e src/qt/locale/bitcoin_$lan.ts ]; then
-			if has $lan $KNOTS_LANGS && ! use ljr; then
+			if has $lan $KNOTS_LANGS && ! use knots; then
 				# Expected
 				continue
 			fi
@@ -94,7 +94,7 @@ src_install() {
 	bitcoincore_src_install
 
 	insinto /usr/share/pixmaps
-	if use ljr; then
+	if use knots; then
 		newins "src/qt/res/rendered_icons/bitcoin.ico" "${PN}.ico"
 	else
 		newins "share/pixmaps/bitcoin.ico" "${PN}.ico"
diff --git a/net-p2p/bitcoin-qt/metadata.xml b/net-p2p/bitcoin-qt/metadata.xml
index 7952948..0c64d432c 100644
--- a/net-p2p/bitcoin-qt/metadata.xml
+++ b/net-p2p/bitcoin-qt/metadata.xml
@@ -13,6 +13,7 @@
 		<flag name="bitcoin_policy_rbf">Replace By Fee policy: Your node will preferentially mine and relay transactions paying the highest fee, regardless of receive order</flag>
 		<flag name="bitcoin_policy_spamfilter">Enhanced spam filter policy: Notorious spammers will not be assisted by your node</flag>
 		<flag name="http">Enable support for the JSON-RPC and REST HTTP server (builtin net-p2p/bitcoind)</flag>
+		<flag name="knots">Build enhanced Bitcoin Knots version, rather than Bitcoin Core</flag>
 		<flag name="libevent">Use dev-libs/libevent</flag>
 		<flag name="ljr">Enable Luke Dashjr's patches</flag>
 		<flag name="qrcode">Enable generation of QR Codes for receiving payments</flag>
diff --git a/net-p2p/bitcoind/bitcoind-0.13.2.ebuild b/net-p2p/bitcoind/bitcoind-0.13.2.ebuild
index f98a27f..10c8480 100644
--- a/net-p2p/bitcoind/bitcoind-0.13.2.ebuild
+++ b/net-p2p/bitcoind/bitcoind-0.13.2.ebuild
@@ -5,7 +5,7 @@ EAPI=5
 
 BITCOINCORE_COMMITHASH="0d719145b018e28d48d35c2646a5962b87c60436"
 BITCOINCORE_LJR_DATE="20170102"
-BITCOINCORE_IUSE="examples ljr test upnp +wallet zeromq"
+BITCOINCORE_IUSE="examples +knots test upnp +wallet zeromq"
 BITCOINCORE_POLICY_PATCHES="+rbf spamfilter"
 BITCOINCORE_NEED_LEVELDB=1
 BITCOINCORE_NEED_LIBSECP256K1=1
diff --git a/net-p2p/bitcoind/metadata.xml b/net-p2p/bitcoind/metadata.xml
index 542e126..6e41107 100644
--- a/net-p2p/bitcoind/metadata.xml
+++ b/net-p2p/bitcoind/metadata.xml
@@ -12,6 +12,7 @@
 	<use>
 		<flag name="bitcoin_policy_rbf">Replace By Fee policy: Your node will preferentially mine and relay transactions paying the highest fee, regardless of receive order</flag>
 		<flag name="bitcoin_policy_spamfilter">Enhanced spam filter policy: Notorious spammers will not be assisted by your node</flag>
+		<flag name="knots">Build enhanced Bitcoin Knots version, rather than Bitcoin Core</flag>
 		<flag name="ljr">Enable Luke Dashjr's patches</flag>
 		<flag name="upnp">Enable Universal Plug and Play</flag>
 		<flag name="wallet">Enable wallet support</flag>

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Mathy Vanvoorden]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

2017-03-06 15:53 GMT+01:00 Anthony G. Basile <basile@freeharbor.net>:

> Bitcoin Knots includes a number of enhancements users may find useful. I
> think  it would be a good idea to make it the default for Bitcoin
> ebuilds (net-p2p/bitcoin-qt, net-p2p/bitcoind, and dev-util/bitcoin-tx).
>

As a Bitcoin user I personally don't feel too happy with my experience
changing without me changing USE-flags. I'm not against changing the name
of the USE-flag, just against changing the default behavior and applying a
bunch of patches that Core might or might not support.

If you compare this to the kernel would it not make more sense to create
something like bitcoin-knots (vanilla-sources vs gentoo-sources)?

- This does NOT enable the historically-controversial spamfilte
> BITCOIN_POLICY.
>

That doesn't really matter, the default behavior changes, the application
is not what Bitcoin devs expect, especially when reporting bugs upstream.

- Knots has since 0.12 (over a year old) included a clearly different
> splash   screen and branding, so even if the user somehow misses the USE
> flag change   and explicit src_prepare warning, it is clear upfront at
> startup and runtime   that they are running Knots rather than Core.
>

This fortifies my point about the name change. If it is a separate product,
package it like that. Time will tell if the users choose to adopt the
-knots version.


> A bug tracker for this has been open for 2 months with no objections:
>     https://bugs.gentoo.org/show_bug.cgi?id=604520
>

That's not really a reference as I don't think anyone (at least not me) is
in the habit of checking all potential bugs for every package they have
installed on their system. If you would have posted this on -dev 2 months
ago without any objections things would be different.

br,
Mathy

[-- Attachment #2: Type: text/html, Size: 2862 bytes --]

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Rich Freeman]

On Mon, Mar 6, 2017 at 2:10 PM, Mathy Vanvoorden <mathy@vanvoorden.be> wrote:
>
> 2017-03-06 15:53 GMT+01:00 Anthony G. Basile <basile@freeharbor.net>:
>>
>> Bitcoin Knots includes a number of enhancements users may find useful. I
>> think  it would be a good idea to make it the default for Bitcoin
>> ebuilds (net-p2p/bitcoin-qt, net-p2p/bitcoind, and dev-util/bitcoin-tx).
>
>
> As a Bitcoin user I personally don't feel too happy with my experience
> changing without me changing USE-flags. I'm not against changing the name of
> the USE-flag, just against changing the default behavior and applying a
> bunch of patches that Core might or might not support.
>
> If you compare this to the kernel would it not make more sense to create
> something like bitcoin-knots (vanilla-sources vs gentoo-sources)?
>

Wouldn't this mean having 2^n packages if there are multiple optional
patches like this available?

I could see the argument for bitcoin-vanilla and bitcoin-gentoo,
assuming somebody wanted to maintain bitcoin-vanilla.  bitcoin-gentoo
would just be the current bitcoin ebuild in the tree.

-- 
Rich

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Peter Stuge]

Anthony G. Basile wrote:
> I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
> against the bitcoin eclass.  The following is his proposed change.
> I'll commit it after review.

Please do not do that, Anthony.


> Bitcoin Knots includes a number of enhancements users may find useful. I
> think  it would be a good idea to make it the default for Bitcoin
> ebuilds (net-p2p/bitcoin-qt, net-p2p/bitcoind, and dev-util/bitcoin-tx).

I can only interpret this patch one way: sshole takeover attempt

I disagree very strongly. >:( Matt's suggested approach (separate
bitcoin-knots ebuild) seems like the right thing to do. I assume
there is no binary incompatiblity between the two packages?


Luke-Jr: I hope you're not maintaining a patchset, but a separate
project. A patchset would be utterly silly, since it causes
completely unneccessary user confusion.


//Peter

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Matthias Maier]

On Tue, Mar  7, 2017, at 10:52 CST, Rich Freeman <rich0@gentoo.org> wrote:

>> As a Bitcoin user I personally don't feel too happy with my experience
>> changing without me changing USE-flags. I'm not against changing the name of
>> the USE-flag, just against changing the default behavior and applying a
>> bunch of patches that Core might or might not support.
>>
>> If you compare this to the kernel would it not make more sense to create
>> something like bitcoin-knots (vanilla-sources vs gentoo-sources)?
>>
>
> Wouldn't this mean having 2^n packages if there are multiple optional
> patches like this available?

No. 

The bitcoin client is a sercurity relevant packages where applying a
gigantic, third-party patchset isn't exactly something that should be
hidden behind a use flag. The comparison with the kernel sources makes a
lot of sense (vanilla-sources versus gentoo-sources).

I agree that a separate ebuild for the client with knots patches is a
much better approach.

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Rich Freeman]

On Tue, Mar 7, 2017 at 12:56 PM, Matthias Maier <tamiko@gentoo.org> wrote:
>
> On Tue, Mar  7, 2017, at 10:52 CST, Rich Freeman <rich0@gentoo.org> wrote:
>
>>> As a Bitcoin user I personally don't feel too happy with my experience
>>> changing without me changing USE-flags. I'm not against changing the name of
>>> the USE-flag, just against changing the default behavior and applying a
>>> bunch of patches that Core might or might not support.
>>>
>>> If you compare this to the kernel would it not make more sense to create
>>> something like bitcoin-knots (vanilla-sources vs gentoo-sources)?
>>>
>>
>> Wouldn't this mean having 2^n packages if there are multiple optional
>> patches like this available?
>
> No.
>
> The bitcoin client is a sercurity relevant packages where applying a
> gigantic, third-party patchset isn't exactly something that should be
> hidden behind a use flag. The comparison with the kernel sources makes a
> lot of sense (vanilla-sources versus gentoo-sources).
>
> I agree that a separate ebuild for the client with knots patches is a
> much better approach.
>

The kernel doesn't give you a choice of multiple independent patch
sets.  We have just a few options that bundle many patches.  You can't
selectively turn them on and off.

I'm not asking whether patching bitcoin is good or bad.

I'm pointing out that if you want to do the same thing with separate
packages that we currently do with 3 different USE flags (that I can
see offhand), you need a total of 8 packages.  If you want to make
knots an option and it isn't one already, then make that 16.

-- 
Rich

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Matthias Maier]

> The kernel doesn't give you a choice of multiple independent patch
> sets.  We have just a few options that bundle many patches.  You can't
> selectively turn them on and off.
>
> I'm not asking whether patching bitcoin is good or bad.
>
> I'm pointing out that if you want to do the same thing with separate
> packages that we currently do with 3 different USE flags (that I can
> see offhand), you need a total of 8 packages.  If you want to make
> knots an option and it isn't one already, then make that 16.

We were only talking about the "ljr" use flag here, weren't we?

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Rich Freeman]

On Tue, Mar 7, 2017 at 1:34 PM, Matthias Maier <tamiko@gentoo.org> wrote:
>
>> The kernel doesn't give you a choice of multiple independent patch
>> sets.  We have just a few options that bundle many patches.  You can't
>> selectively turn them on and off.
>>
>> I'm not asking whether patching bitcoin is good or bad.
>>
>> I'm pointing out that if you want to do the same thing with separate
>> packages that we currently do with 3 different USE flags (that I can
>> see offhand), you need a total of 8 packages.  If you want to make
>> knots an option and it isn't one already, then make that 16.
>
> We were only talking about the "ljr" use flag here, weren't we?
>

I assumed you'd also want to include bitcoin_policy_rbf and
bitcoin_policy_spamfilter as well (if not, why treat them
differently?). Also, I'm not sure if ljr is going to get refactored.

What the defaults should be is a different matter, but for small
self-contained patches I think USE flags generally make more sense.

-- 
Rich

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Anthony G. Basile]

On 3/7/17 12:18 PM, Peter Stuge wrote:
> Anthony G. Basile wrote:
>> I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
>> against the bitcoin eclass.  The following is his proposed change.
>> I'll commit it after review.
> 
> Please do not do that, Anthony.
> 

I don't have time nor the familiarity to properly maintain bitcoins
myself.  Every time Luke wants to make a change, I get nothing but
negative advice - what not to do, but not what to do.  If there were an
unpopular package I would just drop it to maintainer-needed.  But do we
really want a distro that doesn't provide bitcoins?

I will ignore all negative advice regarding this package unless it is
balanced with positive advice.  Please point out what lines of the patch
should be changed and what they should be changed to, else I will commit
the patch as provided.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Mathy Vanvoorden]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

> I don't have time nor the familiarity to properly maintain bitcoins
> myself.  Every time Luke wants to make a change, I get nothing but
> negative advice - what not to do, but not what to do.  If there were an
> unpopular package I would just drop it to maintainer-needed.  But do we
> really want a distro that doesn't provide bitcoins?
>

I suspect that it is because every time Luke wants to make a change, he
wants to push his patchset as default enabled on Gentoo while nobody seems
to be interested in this.

I will ignore all negative advice regarding this package unless it is
> balanced with positive advice.  Please point out what lines of the patch
> should be changed and what they should be changed to, else I will commit
> the patch as provided.
>

Simple, do the rename by all means but don't enable it by default.

Mathy

[-- Attachment #2: Type: text/html, Size: 1417 bytes --]

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Anthony G. Basile]

On 3/11/17 3:13 PM, Peter Stuge wrote:
> 
> All lines containing +knots should say knots instead.
> 

Done.


I'm getting increasingly unsatisfied with where bitcoins* is going.  I
think I'd like to take full ownership of it and remove all unnecessary
patches.  If there's anyone that wants to co-maintain it with me, I'd
welcome the help.  I'm busy until summer at which time I revisit the
issue and try to clean up the eclass and ebuilds.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Peter Stuge]

Anthony G. Basile wrote:
> >> I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
> >> against the bitcoin eclass.  The following is his proposed change.
> >> I'll commit it after review.
> > 
> > Please do not do that, Anthony.
> 
> I don't have time nor the familiarity to properly maintain bitcoins
> myself.

Understood, and no problem. I think it's especially important to be a
bit conservative under those circumstances.


> I will ignore all negative advice regarding this package unless it is
> balanced with positive advice.

That's cool. I tried to also be constructive in my mail - sorry if
that didn't get through. I was saying that the patched version should
probably be a separate ebuild.

But Mathy's (sorry for the mistype in my last mail Mathy) suggestion
to go ahead with renaming the USE flag but *not* flipping it to
default on is also a good step.


> Please point out what lines of the patch should be changed and what
> they should be changed to, else I will commit the patch as
> provided.

All lines containing +knots should say knots instead.


Thanks!

//Peter