1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <showard314@gmail.com>) id 1V1kfE-0005P5-7W
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 22:02:36 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.41 as permitted sender)
client-ip=209.85.160.41; envelope-from=showard314@gmail.com;
helo=mail-pb0-f41.google.com;
Received: from mail-pb0-f41.google.com ([209.85.160.41])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V1kfC-00048r-Gm
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 22:02:36 +0000
Received: by mail-pb0-f41.google.com with SMTP id rp16so9029623pbb.28
for <bitcoin-development@lists.sourceforge.net>;
Tue, 23 Jul 2013 15:02:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.66.194.13 with SMTP id hs13mr7202797pac.163.1374616948624;
Tue, 23 Jul 2013 15:02:28 -0700 (PDT)
Received: by 10.70.15.66 with HTTP; Tue, 23 Jul 2013 15:02:28 -0700 (PDT)
In-Reply-To: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
References: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
Date: Tue, 23 Jul 2013 18:02:28 -0400
Message-ID: <CANg8-dAzc2ENivTpr6S=zoUkfGyBM6j=OUb8-_wLTFQqLRmnzw@mail.gmail.com>
From: Scott Howard <showard314@gmail.com>
To: Debian Bitcoin Packaging Team <pkg-bitcoin-devel@lists.alioth.debian.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(showard314[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (showard314[at]gmail.com)
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1V1kfC-00048r-Gm
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Linux packaging letter
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2013 22:02:36 -0000
On Tue, Jul 23, 2013 at 4:01 PM, Mike Hearn <mike@plan99.net> wrote:
> Hi,
>
> Some of us have put together an open letter to the Linux packaging
> community, outlining why Bitcoin is different to other programs and asking
> them to not patch or modify the upstream sources.
>
> Please consider signing it if you agree (I think the wording by now is fine,
> so don't edit the contents - use the comment feature if you want to though).
>
> https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit#heading=h.i7tz3gqh65mi
>
> The trigger for this is the discovery that Debian bitcoind's got split out
> of the consensus some time in April, for reasons that nobody yet figured out
> but is presumably related to a patch (eg it uses system leveldb).
Hi Mike,
Debian's bitcoin is maintained on an open and archived mailing list
and git repo:
Debian Bitcoin Packaging Team <pkg-bitcoin-devel@lists.alioth.debian.org>
If there is a problem or question, getting an answer should be really
easy. It would be good to include them in the discussion there (I
CC:ed the list). If the upstream developers have a consensus that
distribution packaging is not in the best interest of the project,
then I personally would defer to their judgement and request removal.
I'm leaving this open for other opinions from the Debian side.
That said, let me summarize the arguments and see if we can figure out
a permanent solution:
1) It appears that the consensus of upstream developers is that any
distributed binary should only be linked against libraries that the
bitcoin developers have tested and audited since any compatibility bug
is a risk to both the user and the network.
Response: Is there a way to "certify" the Debian libraries? Debian
bitcoind/bitcoin-qt runs the compile test during all architectures.
MIPS has been failing recently, but no one has looked into it yet.
Perhaps it's not worth developers efforts yet, but at some point the
technology should reach a point it can be redistributed.
2) Bitcoin is new technology, so any patches have the ability of
harming both the network and user.
Response: I, and I'm sure everyone else working on it, totally agrees.
All patches are public [1], you can see that the patches are only to
the build system (except for one adding a debug message). Is there a
specific patch or bug that is problematic? This seems to be
reiterating (1) above: don't patch the build system to use libraries
that were not audited by the developers.
The two solutions are: (1) no one besides the upstream developers
compiles and distributes binaries, ever, or (2) upstream comes up with
a system where someone besides them can compile working binaries for
distribution. Most likely the best solution is to do (1) until
upstream sets up a system to allow (2).
I'm curious as to other's opinions.
Thanks,
Scott
[1] http://anonscm.debian.org/gitweb/?p=collab-maint/bitcoin.git;a=tree;f=debian/patches;h=ba576f9f3ddad47a2f85dcbfb7a0b3482834f19f;hb=HEAD
|
