The build process includes only the previous version of Bitcoin XT patches when the optional xt flag is set. Reproducible: Always Steps to Reproduce: 1.USE="xt" emerge net-p2p/bitcoind 2. 3. Actual Results: Resulting binary only includes the BitcoinXT patches up to the 0.10 version Expected Results: A binary built using the BitcoinXT 0.11A patches Line 89 of /usr/portage/eclass/bitcoincore.eclass is: BITCOINCORE_XT_DIFF="047a89831760ff124740fe9f58411d57ee087078...d4084b62c42c38bfe302d712b98909ab26ecce2f" It should be pointing at the release tag of BitcoinXT 0.11A rather generating the diff by pointing at arbitrary commits.
"Bitcoin XT" is no longer Bitcoin as of their 0.11 release, so it would be inappropriate to include it in these packages. In theory, I suppose we could continue to offer the XT functionality changes (similar to USE=ljr), but calling it USE=xt might confuse users.
with reference to this post on Reddit by Luke-jr https://www.reddit.com/r/Bitcoin/comments/3h608a/why_bitcoinxt_is_considered_offtopic/cu4twyo Apparently, for his own reasons, Luke has removed support for the XT flag and the functionality it provides. I am prepared to become maintainer for net-p2p/bitcoinxtd net-p2p/bitcoinxt-cli net-p2p/bitcoinxt-qt as ebuilds which will re-instate this alternate implementation of the main bitcoin client. Can some one point in the direction of how I establish that as part of the basic portage tree. Equally, can someone volunteer to support the other alternate implementation - BitcoinJ and btcd
(In reply to Luke-Jr from comment #1) > "Bitcoin XT" is no longer Bitcoin as of their 0.11 release, so it would be > inappropriate to include it in these packages. In theory, I suppose we could > continue to offer the XT functionality changes (similar to USE=ljr), but > calling it USE=xt might confuse users. Luke - it IS Bitcoin as of their 0.11 release. Until such time as a supermajority triggers new consensus rules..
(In reply to Ron OHara from comment #2) > [snip] > > I am prepared to become maintainer for > > net-p2p/bitcoinxtd > net-p2p/bitcoinxt-cli > net-p2p/bitcoinxt-qt > > as ebuilds which will re-instate this alternate implementation of the main > bitcoin client. > > Can some one point in the direction of how I establish that as part of the > basic portage tree. > [snip] There are a few ways to get packages in the tree. If you wish to introduce the ebuild and maintain it, you could become a proxy-maintainer or go through our recruitment process. Contact recruiters@gentoo.org if you're interested in becoming a developer. They can help you find a mentor who can get you up to speed on what it takes to work on Gentoo. A great starting point is the portage docs (make sure to build it with USE=doc), the devmanual [0], and `man ebuild`. You can begin studying the ebuild quiz[1], which is required if you want to become a developer and work on ebuilds. More information can be found on the wiki page[2]. [0]: https://devmanual.gentoo.org [1]: https://projects.gentoo.org/comrel/recruiters/quizzes/ebuild-quiz.txt [2]: https://www.gentoo.org/get-involved/become-developer/
(In reply to Daniel Campbell from comment #4) > (In reply to Ron OHara from comment #2) > > [snip] > > > > I am prepared to become maintainer for > > > > net-p2p/bitcoinxtd > > net-p2p/bitcoinxt-cli > > net-p2p/bitcoinxt-qt > > > > as ebuilds which will re-instate this alternate implementation of the main > > bitcoin client. > > > > Can some one point in the direction of how I establish that as part of the > > basic portage tree. > > [snip] > > There are a few ways to get packages in the tree. If you wish to introduce > the ebuild and maintain it, you could become a proxy-maintainer or go > through our recruitment process. Contact recruiters@gentoo.org if you're > interested in becoming a developer. They can help you find a mentor who can > get you up to speed on what it takes to work on Gentoo. A great starting > point is the portage docs (make sure to build it with USE=doc), the > devmanual [0], and `man ebuild`. You can begin studying the ebuild quiz[1], > which is required if you want to become a developer and work on ebuilds. > > More information can be found on the wiki page[2]. > > [0]: https://devmanual.gentoo.org > [1]: https://projects.gentoo.org/comrel/recruiters/quizzes/ebuild-quiz.txt > [2]: https://www.gentoo.org/get-involved/become-developer/ Do we really need to polute the tree with nearly identical packages because of internecine squabblings in the bitcoin community? I'm going to ask people to figure out a way to do this without creating maintenance nightmare.
(In reply to Anthony Basile from comment #5) > (In reply to Daniel Campbell from comment #4) > [snip] > > Do we really need to polute the tree with nearly identical packages because > of internecine squabblings in the bitcoin community? I'm going to ask > people to figure out a way to do this without creating maintenance nightmare. Good point. This isn't the first time that there's been a scene over Bitcoin on Gentoo. It may be a better idea for those unhappy with Bitcoin's handling on Gentoo to pursue a community overlay to maintain the forks that they want, then add them to their systems with layman. Regular bitcoiners get what they want, forkers get what they want and don't have to bug developers to change things. Win/win imo.
(In reply to Anthony Basile from comment #5) > Do we really need to polute the tree with nearly identical packages because > of internecine squabblings in the bitcoin community? I'm going to ask > people to figure out a way to do this without creating maintenance nightmare. What about users who want to run bitcoin and xt simultaneously on their systems? I think there is nothing wrong with having net-p2p/bitcoind-xt, net-p2p/bitcoin-qt-xt and Co. if someone is willing to maintain it.
(In reply to Daniel Campbell from comment #6) > (In reply to Anthony Basile from comment #5) > > (In reply to Daniel Campbell from comment #4) > > [snip] > > > > Do we really need to polute the tree with nearly identical packages because > > of internecine squabblings in the bitcoin community? I'm going to ask > > people to figure out a way to do this without creating maintenance nightmare. > > Good point. This isn't the first time that there's been a scene over Bitcoin > on Gentoo. It may be a better idea for those unhappy with Bitcoin's handling > on Gentoo to pursue a community overlay to maintain the forks that they > want, then add them to their systems with layman. Regular bitcoiners get > what they want, forkers get what they want and don't have to bug developers > to change things. Win/win imo. There are now at least four distinct Bitcoin wallets. Bitcoin core - maintained by Luke-Jr BitcoinXT - which Luke used to support via a USE variable, but has now remove support.s - I am prepared to create and maintain ebuilds to support that wallet Btcd - a Golang implementation of Bitcoin - not yet supported in Gentoo BitcoinJ - A java implementation of Bitcon - not yet supported in Gentoo This is no different to to having multiple packages which implement SMTP ...
(In reply to Anthony Basile from comment #5) > Do we really need to polute the tree with nearly identical packages because > of internecine squabblings in the bitcoin community? I'm going to ask > people to figure out a way to do this without creating maintenance nightmare. I think "pollute" is putting it strongly. We have multiple forks in the tree (libav, mpv, libreoffice, and so on). I would think having separate ebuilds for this fork (or whatever you want to call it) is normal practice in Gentoo. Since Ron is stepping up to maintain these as separate packages, maybe we could re-assign this bug to proxy-maintainers?
(In reply to Ben de Groot from comment #9) > (In reply to Anthony Basile from comment #5) > > Do we really need to polute the tree with nearly identical packages because > > of internecine squabblings in the bitcoin community? I'm going to ask > > people to figure out a way to do this without creating maintenance nightmare. > > I think "pollute" is putting it strongly. We have multiple forks in the tree > (libav, mpv, libreoffice, and so on). I would think having separate ebuilds > for this fork (or whatever you want to call it) is normal practice in Gentoo. > > Since Ron is stepping up to maintain these as separate packages, maybe we > could re-assign this bug to proxy-maintainers? You're right. After speaking with people I realize that this is really a fork and should be its own package. If Ron wants, I'll proxy for him.
(In reply to Anthony Basile from comment #10) > (In reply to Ben de Groot from comment #9) > > (In reply to Anthony Basile from comment #5) > > > Do we really need to polute the tree with nearly identical packages because > > > of internecine squabblings in the bitcoin community? I'm going to ask > > > people to figure out a way to do this without creating maintenance nightmare. > > > > I think "pollute" is putting it strongly. We have multiple forks in the tree > > (libav, mpv, libreoffice, and so on). I would think having separate ebuilds > > for this fork (or whatever you want to call it) is normal practice in Gentoo. > > > > Since Ron is stepping up to maintain these as separate packages, maybe we > > could re-assign this bug to proxy-maintainers? > > You're right. After speaking with people I realize that this is really a > fork and should be its own package. > > If Ron wants, I'll proxy for him. Ok thanks. I will try to get the ebuilds done and tested today Tentatively called: (unless someone has a better suggestion) net-p2p/bitcoinxtd net-p2p/bitcoinxt-cli net-p2p/bitcoinxt-qt I will ensure that the binaries do not conflict with those of Lukes package so that people can install both at the same time if they wish. There will be nothing fancy about the ebuilds, and no extra 'ljr' style features. I just want the plain unvarnished BitcoinXT as released on Github
(In reply to Ron OHara from comment #11) > I will ensure that the binaries do not conflict with those of Lukes package > so that people can install both at the same time if they wish. Also make sure to use different data, config, etc. directories. For example /etc/bitcoin-xt /var/lib/bitcoin-xt
(In reply to Florian Schmaus from comment #12) > (In reply to Ron OHara from comment #11) > > I will ensure that the binaries do not conflict with those of Lukes package > > so that people can install both at the same time if they wish. > > Also make sure to use different data, config, etc. directories. For example > > /etc/bitcoin-xt > /var/lib/bitcoin-xt Good point, though I probably should support an option to migrate an existing setup for the case where someone wants to cut over without needing to download the blockchain again, and to copy their wallet over.
(In reply to Luke-Jr from comment #1) > "Bitcoin XT" is no longer Bitcoin as of their 0.11 release, so it would be > inappropriate to include it in these packages. In theory, I suppose we could > continue to offer the XT functionality changes (similar to USE=ljr), but > calling it USE=xt might confuse users. Luke - FYI. In both net-p2p/bitcoind and net-p2p/bitcoin-qt (1) You have not yet corrected the metatdata.xml file for bitcoind.. it still refers to the 'xt' flag. (2) The Changelog makes no mention of you removing the 'xt' flag
Created attachment 409762 [details] Initial ebuild and supporting files for net-p2p/bitcoinxtd For testing this ebuild, try unpacking it into your local portage area usually using something like this... download the archive to /tmp mkdir -p /usr/local/portage/net-p2p cd /usr/local/portage/net-p2p tar xzf /tmp/bitcoinxtd-0.11.0.tar.gz emerge bitcoinxtd edit /var/lib/bitcoinxtd/.bitcoinxtd/bitcoinxt.conf and adjust whatever you want /etc/init.d/bitcoinxtd start Feedback is appreciated
(In reply to Ron OHara from comment #14) > Luke - FYI. In both net-p2p/bitcoind and net-p2p/bitcoin-qt > (1) You have not yet corrected the metatdata.xml file for bitcoind.. it > still refers to the 'xt' flag. > (2) The Changelog makes no mention of you removing the 'xt' flag The USE flag remains on 0.10.2, which is the only version that ever had it. It was not removed from any ebuild where it was applicable, and such a minor loss is not otherwise noteworthy.
(In reply to Luke-Jr from comment #16) > (In reply to Ron OHara from comment #14) > > Luke - FYI. In both net-p2p/bitcoind and net-p2p/bitcoin-qt > > (1) You have not yet corrected the metatdata.xml file for bitcoind.. it > > still refers to the 'xt' flag. > > (2) The Changelog makes no mention of you removing the 'xt' flag > > The USE flag remains on 0.10.2, which is the only version that ever had it. > It was not removed from any ebuild where it was applicable, and such a minor > loss is not otherwise noteworthy. Minor? It is the most controversial item under discussion in the wider Bitcoin community .... removing it from 0.11.0 certainly warrants at least a Changelog entry.
@Ron. can you please attach the ebuild, patches and metadata.xml for each of the packages you wish to put on the tree. please attach each separately and do not compress them. i'll then put them on the tree. when new releases come out, open a bug with the new ebuilds/patches and cc me.
this is in the tree now. sorry it fell off my radar for a while. i also had to make a few corrections. please test!
