Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots
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: bluen...@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
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
Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots
> 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
Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots
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: bluen...@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
On Tue, Mar 7, 2017 at 1:34 PM, Matthias Maier 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
> 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
On Tue, Mar 7, 2017 at 12:56 PM, Matthias Maier wrote: > > On Tue, Mar 7, 2017, at 10:52 CST, Rich Freeman 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
On Tue, Mar 7, 2017, at 10:52 CST, Rich Freeman 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
On Mon, Mar 6, 2017 at 2:10 PM, Mathy Vanvoorden wrote: > > 2017-03-06 15:53 GMT+01:00 Anthony G. Basile : >> >> 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
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
2017-03-06 15:53 GMT+01:00 Anthony G. Basile : > 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
[gentoo-dev] RFC: Update bitcoin eclass to default to knots
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: bas...@freeharbor.net
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
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 @@
Luke Dashjr
+ Build enhanced Bitcoin Knots version, rather
than Bitcoin Core
Enable Luke Dashjr's patches
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
;;
*)
@@ -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 ]; }; the
