1 2012-06-28 00:01:17 <sipa> all normal operations are covered by the first two (requesting block data, or requesting a block's parents when an orphan is received again)
  2 2012-06-28 00:18:08 <midnightmagic> gmaxwell: I'm not grokking why everybody has such a problem with you. :(
  3 2012-06-28 00:18:21 <midnightmagic> and that's not even sarcasm
  4 2012-06-28 00:19:19 <gmaxwell> well this guy is after me because I was the person who banned him in #bitcoin-mining
  5 2012-06-28 00:19:35 <gmaxwell> But ... he was crapflooding... so.. it's not like it was anything personal.
  6 2012-06-28 00:20:07 <midnightmagic> gmaxwell: we need one level of removal..  like have chanserv ban him or something instead.
  7 2012-06-28 00:38:47 <D34TH> is there a flag i can set to static link bitcoin-qt?
  8 2012-06-28 00:39:34 <gmaxwell> You probably don't want to do that... it'll make it use more memory, operate less securely, and many distros make it hard to statically link anything now.
  9 2012-06-28 00:40:21 <D34TH> darn
 10 2012-06-28 00:40:27 <gribble> New news from bitcoinrss: dooglus opened issue 1528 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1528>
 11 2012-06-28 00:42:44 <D34TH> bitcoinrpc.cpp:2771: error: reference to ???error??? is ambiguous
 12 2012-06-28 00:42:46 <D34TH> D:
 13 2012-06-28 01:36:48 <gribble> New news from bitcoinrss: fanquake opened pull request 44 on bitcoin/bitcoin.org <https://github.com/bitcoin/bitcoin.org/pull/44>
 14 2012-06-28 03:04:19 <jgarzik> 'git bisect' precisely identifies the already-likely suspect, fbf9df2ea32528c71b58160283b4eb2c52e30ccb (Use the QueueShutdown signal to stop accepting new RPC connections)
 15 2012-06-28 03:24:15 <wump> well that used to work, the problem is that that commit conflicts with https://github.com/bitcoin/bitcoin/commit/9247134, which effectively disables the uiInterface for non-ui...
 16 2012-06-28 03:33:34 <wump> so probably it was developed and tested on an earlier branch, then never tested on the current one after merging
 17 2012-06-28 03:37:27 <wump> I think it's a nice use of signals, but he shouldn't use the uiInterface signal, it's only for communicating with the ui
 18 2012-06-28 05:39:20 <cande> can you do a getreceivedbyaddress 1xxxxxxx on an address you do not own?
 19 2012-06-28 05:48:57 <weex> cande: no
 20 2012-06-28 05:49:32 <weex> you might be able to use another tool though
 21 2012-06-28 05:50:00 <weex> like txradar or blockchain.info's api
 22 2012-06-28 08:28:43 <sipa> jgarzik, wump: quite sure i tested it after that commit
 23 2012-06-28 08:29:07 <sipa> but i didn't test right before merge
 24 2012-06-28 10:40:51 <BlueMatt> bitcointalk down?
 25 2012-06-28 10:41:09 <sipa> seems so
 26 2012-06-28 10:41:36 <genjix> but i need my fix
 27 2012-06-28 10:41:48 <sipa> ;;isitdown bitcointalk.org
 28 2012-06-28 10:41:54 <gribble> http://bitcointalk.org Is Down -> Check if your website is up or down?
 29 2012-06-28 11:11:53 <jgarzik> wump: that's almost exactly what I said in-channel... he shouldn't use uiinterface signals for non-UI :)
 30 2012-06-28 11:15:53 <wump> heh
 31 2012-06-28 11:34:19 <BlueMatt> is anyone currently working on fixing the master issues, or should I jump in?
 32 2012-06-28 11:34:21 <BlueMatt> wump: ?
 33 2012-06-28 11:37:39 <wump> I'm not, currently
 34 2012-06-28 11:38:33 <BlueMatt> ok, Ill go look
 35 2012-06-28 11:54:12 <jgarzik> BlueMatt: ask sipa, he merged it...
 36 2012-06-28 11:54:52 <BlueMatt> wow...there are a ton of vnThreadsRunning[THREAD_RPCLISTENER]++/--s that arent locked and could run simultaneously...
 37 2012-06-28 11:55:57 <jgarzik> BlueMatt: none of the vnThreadsRunning[] uses are locked AFAIK
 38 2012-06-28 11:56:29 <BlueMatt> jgarzik: but most of them only ever get modified by one thread
 39 2012-06-28 11:56:50 <BlueMatt> the rpc stuff gets touched by, afaict, quite a bunch of threads...
 40 2012-06-28 11:57:14 <jgarzik> BlueMatt: yep
 41 2012-06-28 11:57:46 <jgarzik> BlueMatt: doubtful that is the crashing problem though.
 42 2012-06-28 11:58:45 <BlueMatt> jgarzik: no, but it could cause a different, so far unseen problem
 43 2012-06-28 12:29:49 <wump> it could cause misreporting on shutdown, at the least... maybe atomic increment/decrements could be used
 44 2012-06-28 12:32:19 <wump> though it's never performance critical so I guess a single lock for the structure would work just as well
 45 2012-06-28 14:02:19 <helo> when hd wallets are introduced, will it be easy to send all coin from old wallet addresses to the new wallet?
 46 2012-06-28 14:02:48 <copumpkin> 1080p?
 47 2012-06-28 14:03:31 <BlueMatt> copumpkin: 4k
 48 2012-06-28 14:03:41 <BlueMatt> helo: sure
 49 2012-06-28 14:03:47 <BlueMatt> copumpkin: no, sorry, 8k
 50 2012-06-28 14:04:07 <copumpkin> :)
 51 2012-06-28 14:25:44 <BlueMatt> wait...so now we spawn a new thread every time we get a new rpc connection. that seems...excessive
 52 2012-06-28 14:26:37 <jgarzik> BlueMatt: perhaps... but it was the easiest transition away from the Old Way
 53 2012-06-28 14:26:48 <jgarzik> BlueMatt: you're welcome to implement a thread pool or other fun
 54 2012-06-28 14:27:09 <luke-jr> BlueMatt: I think only after authentication?
 55 2012-06-28 14:27:23 <jgarzik> thread is starting after IP filter passes
 56 2012-06-28 14:27:26 <jgarzik> *started
 57 2012-06-28 14:27:32 <luke-jr> ah, right, that was it
 58 2012-06-28 14:27:34 <jgarzik> but before auth
 59 2012-06-28 14:27:44 <BlueMatt> luke-jr: nope
 60 2012-06-28 14:27:49 <BlueMatt> yea
 61 2012-06-28 14:28:02 <luke-jr> is threading really that heavy?
 62 2012-06-28 14:28:09 <BlueMatt> luke-jr: no, but its kinda ugly
 63 2012-06-28 14:28:19 <BlueMatt> its not like its a big deal its just...excessive
 64 2012-06-28 14:28:33 <jgarzik> it's not ugly, it's slack :)
 65 2012-06-28 14:29:11 <BlueMatt> ok, whatever you wanna call it
 66 2012-06-28 14:29:26 <jgarzik> lack of connection scaling is the main problem, but with HTTP/1.1 pipelining from IP filtered connections, that is less of an issue
 67 2012-06-28 14:29:29 <luke-jr> I had to give up one-thread-per-connection in Eloipool when I deployed it to Eligius :P
 68 2012-06-28 14:29:32 <luke-jr> but that's much higher traffic
 69 2012-06-28 14:29:43 <BlueMatt> it does make watching gdb fun while [true]; do ./bitcoind ...; done fun...
 70 2012-06-28 14:29:54 <jgarzik> thread-per-connection is DoS-able
 71 2012-06-28 14:30:06 <jgarzik> of course, thread pool is DoS-able in other ways
 72 2012-06-28 14:31:56 <BlueMatt> jgarzik: what was that about the vnThreadsRunning[THREAD_RPCHANDLER]++ stuff not being an issue? I just hit it
 73 2012-06-28 14:40:16 <sipa> BlueMatt: i doubt that counter stuff is the problem
 74 2012-06-28 14:46:26 <maaku> i'm trying to build qt-win32-4.7.4-gitian.zip, but Qt is trying to do a 64-bit build which obviously fails
 75 2012-06-28 14:46:31 <maaku> anyone experienced this?
 76 2012-06-28 14:47:52 <luke-jr> maaku: try an older gitian?
 77 2012-06-28 14:48:34 <maaku> hrm. ok. does anyone maintain a stable branch?
 78 2012-06-28 14:48:52 <luke-jr> of gitian? not afaik
 79 2012-06-28 14:49:29 <luke-jr> I use 5a2986fd
 80 2012-06-28 14:49:42 <luke-jr> it doesn't have some nicer features, but it works
 81 2012-06-28 14:49:43 <maaku> luke-jr: thanks, I'll try that
 82 2012-06-28 14:58:18 <EricLombrozo> how are multisig addresses constructed?
 83 2012-06-28 14:59:01 <maaku> agh that won't work--i'm doing a LXC setup
 84 2012-06-28 14:59:10 <maaku> i'll try one of the early LXC releases
 85 2012-06-28 14:59:18 <luke-jr> >_<
 86 2012-06-28 15:01:08 <EricLombrozo> more specifically, how is 33QdBYMcN4UwFHTfBza7JQxSTLjhGudYtr generated from scriptSig = 00493046022100dab4a89d95ff6571d6ae24917f4b7adb909195d9c601d3c81b9d13483ffab1e0022100db13d574079cb0aed1eb41038660e9408f9f0932d5256f33e0ad9130e786f7e90148304502203d6336e409b058d0d4512bc507ce8f3f8bb5b45fc24610acab3e0c92bf020d8b022100f4cdb54a47ee1689c3d5f1211536e275903cdeab8d2900eb069078c8619245a30147522103ab115da6df4f540bd6c9c4be5fddcc24588e
 87 2012-06-28 15:01:54 <EricLombrozo> or from OP_HASH160 12d69cd338a38d0d7783cf226497633d3c2079ea OP_EQUAL
 88 2012-06-28 15:02:14 <EricLombrozo> is this documented anywhere?
 89 2012-06-28 15:03:46 <EricLombrozo> seems that https://en.bitcoin.it/wiki/List_of_address_prefixes and https://en.bitcoin.it/wiki/Base58Check_encoding need to be updated
 90 2012-06-28 15:12:06 <EricLombrozo> so bitcoin addresses are now supposed to start with version byte 0x05?
 91 2012-06-28 15:12:16 <EricLombrozo> all new addresses? multisig or not?
 92 2012-06-28 15:30:33 <BlueMatt> sipa: its not /the/ problem, but its a problem, it will cause "ThreadsRPCServer still running" and keep bitcoin from exiting
 93 2012-06-28 15:41:18 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1529 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1529>
 94 2012-06-28 15:43:04 <gmaxwell> EricLombrozo: No, they do not.
 95 2012-06-28 15:44:02 <gmaxwell> EricLombrozo: and see BIP 13 for the address description.
 96 2012-06-28 15:50:06 <jgarzik> BlueMatt: do all platforms guarantee that unlocked accesses to a 32-bit int do not interfere with unlocked accesses to adjacent 32-bit ints?
 97 2012-06-28 15:50:21 <jgarzik> er, s/unlocked/locked/ for one of those
 98 2012-06-28 15:51:01 <jgarzik> no clue how boost semantics wind up behaving WRT memory barriers and LOCK prefix, underneath all that
 99 2012-06-28 15:51:36 <BlueMatt> jgarzik: thats a good point...I cant say I know, though if its an issue, Id think we should have been seeing that more often already
100 2012-06-28 15:51:48 <BlueMatt> not to say thats an argument for not researching and (potentially) fixing
101 2012-06-28 15:52:08 <BlueMatt> (assuming you're talking about vnThreadsRunning)
102 2012-06-28 15:52:12 <jgarzik> seems like it would make each code line in the vnThreadsRunning[] change smaller, if the lock were simply encapsulated
103 2012-06-28 15:52:28 <BlueMatt> if it needs a lock, yea Id say encapsulate it
104 2012-06-28 15:52:51 <jgarzik> threadman.inc(THREAD_RPCLISTENER) or whatever
105 2012-06-28 15:52:59 <BlueMatt> yep
106 2012-06-28 15:53:16 <BlueMatt> if its only one thread that needs locks, its not really worth it...but yea, if they all need locks, encapsulation would be nice
107 2012-06-28 15:57:05 <luke-jr> could possibly just subclass and overload operator++ too <.<
108 2012-06-28 15:59:17 <BlueMatt> jgarzik: I may be wrong, but could it be possible that we break that rule in ways that we cant control if there is such a rule (object allocation adjacent to other objecs)?
109 2012-06-28 17:49:54 <cande> hi
110 2012-06-28 17:50:17 <cande> bitcoind sendtoaddress, what is 'comment' and 'comment-to' used for?
111 2012-06-28 17:59:16 <ersi> I have two nodes - one with the full blockchain already synced and one which I've sat up to -connect to the fully synced node. It'll go very quickly until an external node get's connected - Is there anything special besides possible bandwidth and speed that'd slow *everything* down while syncing?
112 2012-06-28 18:00:00 <BlueMatt> cande: its just stored in your wallet with the transaction, use it for whatever you want...its never transmitted to other nodes
113 2012-06-28 18:00:10 <ersi> I'm not saying there's anything wrong, it's just that I observed the syncronisation going a *lot* slower
114 2012-06-28 18:00:36 <BlueMatt> ersi: while one gets an external connection?
115 2012-06-28 18:00:59 <BlueMatt> ersi: that said, bitcoin is absolutely terrible about overzealous locking...it locks a cs_main when it does just about anything
116 2012-06-28 18:01:05 <BlueMatt> could have something to do with that
117 2012-06-28 18:01:12 <ersi> Hmm
118 2012-06-28 18:01:25 <BlueMatt> ersi: can you elaborate on the situation?
119 2012-06-28 18:02:12 <ersi> Well, all I know is that when connection > 1 while syncing - it'll go exceptionally slower than when I only was connected to my fully-synced LAN (actually remote over VPN) node
120 2012-06-28 18:02:35 <BlueMatt> which node is getting the connection, was my question?
121 2012-06-28 18:02:52 <ersi> Oh, heh. The not-synced one
122 2012-06-28 18:04:22 <ersi> I got "node A" which is syncing up from "node B", which is fully synced. When "node A" gets more than the connection to "node B" - the syncing will go slower (Only measured subjectively though)
123 2012-06-28 18:04:42 <ersi> Or well, I've noticed that the overall bandwidth use goes down a lot as well
124 2012-06-28 18:04:46 <cande> BlueMatt, thx
125 2012-06-28 18:05:27 <BlueMatt> Id bet that node c (the one making the connection to a) sends a a new block, and then a will start syncing from c instead of b, did you say you were using just -connect on a? in that case there shouldn't be a possibility of a getting any other connections
126 2012-06-28 18:06:21 <ersi> I am, but apparently -connect doesn't set -dnsseed=0 (defaults to 1) or -upnp=0 (defaults to 1)
127 2012-06-28 18:06:53 <ersi> I've fixed it for my part (I explicitly handed bitcoin-qt -upnp=0 -dnsseed=0 on node A) - just got curious :)
128 2012-06-28 18:07:28 <BlueMatt> thats not right...
129 2012-06-28 18:07:38 <ersi> I'll make a issue at GitHub then
130 2012-06-28 18:07:42 <BlueMatt> afaik it should be setting -nolisten and not making outgoing connections...
131 2012-06-28 18:07:47 <BlueMatt> but yea may be broken
132 2012-06-28 18:08:03 <ersi> sweet, at least something possibly found :-)
133 2012-06-28 18:08:04 <BlueMatt> (-nolisten should also set upnp to false)
134 2012-06-28 18:08:26 <ersi> and -nolisten is default I take it, if one starts ./bitcoin-qt?
135 2012-06-28 18:09:04 <BlueMatt> no, -nolisten is default if you have -connect set, otherwise its not
136 2012-06-28 18:09:15 <ersi> ah, alright
137 2012-06-28 18:10:49 <BlueMattBot> Yippie, build fixed!
138 2012-06-28 18:12:20 <BlueMattBot> gmaxwell you may not issue bot commands in this chat!
139 2012-06-28 18:12:20 <gmaxwell> BlueMattBot: careful to distinguish between 0.7.0 and 0.6.2/3 behavior, because it changed a fair bit. I dunno which ersi is talking about.
140 2012-06-28 18:12:29 <gmaxwell> stupid tab complete.
141 2012-06-28 18:13:04 <ersi> gmaxwell: I'll specify all details in the issue report (It's 0.6.3 by the way)
142 2012-06-28 18:13:27 <gmaxwell> ersi: then it's probably not useful to report it.
143 2012-06-28 18:13:37 <ersi> Don't know if it's valid for "trunk"/latest.. worst case, it'll be a known issue without any actions.
144 2012-06-28 18:14:02 <ersi> Meh, doesn't hurt to type it up anyhow
145 2012-06-28 18:15:07 <luke-jr> ersi: um, you can't get more connections if you use -connect
146 2012-06-28 18:15:19 <gmaxwell> I mean, I'm just going to close it right after you do. -connect now implies dnsseed=false and listen=false unless you've specified otherwise.
147 2012-06-28 18:16:13 <gmaxwell> (and listen=false implies upnp=false, discover=false)
148 2012-06-28 18:16:34 <ersi> Is that expected behaviour in 0.6.X? Or is that new for 0.7.X?
149 2012-06-28 18:17:12 <gmaxwell> Thats new behavior in 0.7.x.
150 2012-06-28 18:17:29 <ersi> Alrighty, funky.
151 2012-06-28 18:19:13 <luke-jr> ersi: it's a bug in 0.6.x I guess I need to check on
152 2012-06-28 18:19:34 <gmaxwell> luke-jr: no, it's not a bug. It's documented behavior.
153 2012-06-28 18:19:42 <luke-jr> gmaxwell: it is?
154 2012-06-28 18:20:24 <luke-jr> where is it documented? why? O.o
155 2012-06-28 18:20:25 <ersi> I would like to argue semantics about that, but I'll just skip that
156 2012-06-28 18:20:37 <sturles> Shouldn't 0.6.2 listen to IPv6 by default?  Just discovered that mine don't.
157 2012-06-28 18:20:49 <BlueMatt> gmaxwell: Im pretty sure that was always the behavior
158 2012-06-28 18:21:22 <BlueMatt> sturles: ipv6 is in 0.7
159 2012-06-28 18:21:42 <sturles> OK.  Upgrade then..
160 2012-06-28 18:21:48 <BlueMatt> gmaxwell: in any case -connect has always implied -nolisten, which is whats discussed here
161 2012-06-28 18:21:51 <luke-jr> sturles: 0.7 is not released yet
162 2012-06-28 18:22:09 <luke-jr> BlueMatt: no, -dnsseed is apparently the problem?
163 2012-06-28 18:22:23 <BlueMatt> luke-jr: dnsseed doesnt make you make new connections, it only adds addresses
164 2012-06-28 18:22:37 <BlueMatt> (and connect doesnt make them)
165 2012-06-28 18:23:02 <luke-jr> BlueMatt: it does do a useless DNS lookup, at least
166 2012-06-28 18:24:02 <BlueMatt> luke-jr: but the real issue is that ersi's node made a new connection while running with -connect
167 2012-06-28 18:24:05 <gmaxwell> BlueMatt: I think you're on drugs.
168 2012-06-28 18:24:14 <BlueMatt> (which afaik it hasnt since before my time)
169 2012-06-28 18:24:32 <gmaxwell> BlueMatt: It made a new connection while running -connect?
170 2012-06-28 18:24:46 <ersi> It didn't do that when I last fiddled with Bitcoin, but we didn't have -upnp nor did we have -dnsseed back then. :-P
171 2012-06-28 18:24:53 <BlueMatt> gmaxwell: or it was connected to, one of the two
172 2012-06-28 18:24:57 <gmaxwell> That isn't even possible. -connect triggers an infinite loop in the connections thread.
173 2012-06-28 18:25:04 <gmaxwell> BlueMatt: Thats not the same thing.
174 2012-06-28 18:25:19 <BlueMatt> gmaxwell: s/it made a new connection/it ended up with 2 total connections/
175 2012-06-28 18:25:29 <gmaxwell> Right.
176 2012-06-28 18:25:36 <gmaxwell> Go read the 0.6.3 code.
177 2012-06-28 18:26:07 <ersi> I don't know which client/node connected to which. I just know that the connection indicator in the GUI increased.
178 2012-06-28 18:29:46 <gmaxwell> BlueMatt: are you enlightened yet?
179 2012-06-28 18:29:56 <BlueMatt> gmaxwell: yep, you're right...
180 2012-06-28 18:30:04 <BlueMatt> damn, dunno how the hell I remembered that one wrong
181 2012-06-28 18:30:19 <BlueMatt> sorry for all the fuss
182 2012-06-28 18:30:22 <gmaxwell> well, I'm guilty of that too... which is one of the reasons it got changed.
183 2012-06-28 18:31:37 <luke-jr> gavinandresen: re your comment on checknewblock: do you want/expect me to change that, or is it okay to leave it how it is?
184 2012-06-28 18:32:24 <gavinandresen> luke-jr: I'm trying to figure out how to safely get from where we are to where I want to be, and haven't decided whether a big refactor of the database stuff is the right path or not.
185 2012-06-28 18:33:41 <luke-jr> even if it is, I'm not sure fMockDb makes such a refactor harder
186 2012-06-28 18:33:46 <jgarzik_> gavinandresen: indeed.  that's why I closed the block split pullreq
187 2012-06-28 18:34:03 <jgarzik> (though that is stored locally, and can always be recreated)
188 2012-06-28 18:34:24 <gavinandresen> fMockDb just makes the old C++ programmer in me go "ewwwww...."
189 2012-06-28 18:34:41 <jgarzik> yep
190 2012-06-28 21:33:40 <galambo__> why does bitcointalk keep going down
191 2012-06-28 21:45:29 <yellowhat> apparently some kind of DOS not yet clear.
192 2012-06-28 21:45:46 <yellowhat> its troll and dos season. did you get the memo?
193 2012-06-28 22:13:06 <jgarzik> gmaxwell, sipa: anybody ever benched a -loadblock import, whose contents are sorted most-recent-first?
194 2012-06-28 22:13:42 <jgarzik> it would import a bunch of orphans (pass 1), then recursively SetBestChain all at once
195 2012-06-28 22:13:50 <Diablo-D3> hahah oh shit
196 2012-06-28 22:14:01 <Diablo-D3> worst case senario
197 2012-06-28 22:16:43 <theodore> Hey guys, would there be a way to access chrome and direct to URL's via the command line?
198 2012-06-28 22:17:12 <sipa> jgarzik: quite sure you'll OOM
199 2012-06-28 22:17:24 <jgarzik> sipa: transaction too large?
200 2012-06-28 22:17:36 <sipa> no, just orphan blocks in memory
201 2012-06-28 22:17:43 <sipa> it won't touch DB code
202 2012-06-28 22:18:17 <sipa> oh, unless you have enough RAM, and I suppose 2 GB worth of blocks is still doable on semi-recent hardware
203 2012-06-28 22:20:05 <jgarzik> ahh, ProcessBlock() shoves into mapOrphanBlocks just before ProcessBlock() would write the block to disk
204 2012-06-28 22:20:31 <jgarzik> guess not
205 2012-06-28 22:21:34 <sipa> they're written to disk as soon as they get connected to the block tree
206 2012-06-28 22:21:44 <sipa> so after their difficulty has been verified
207 2012-06-28 22:21:54 <sipa> though PoW is checked earlier
208 2012-06-28 22:23:50 <maaku> anyone by chance know how to tell if a LXC is i386 or amd64 from within the container?
209 2012-06-28 22:24:11 <sipa> lsb_release -a
210 2012-06-28 22:24:12 <sipa> ?
211 2012-06-28 22:24:35 <BlueMatt> uname -a
212 2012-06-28 22:24:57 <BlueMatt> if (i386) install am64 kernel; if (doesnt boot) go back to i386
213 2012-06-28 22:26:28 <maaku> ok thanks i'll see if that works; wasn't sure if 32-bit guest on 64-bit host would show i386 or amd64/x86_64
214 2012-06-28 22:27:16 <dicksuckersrus> hello
215 2012-06-28 22:27:22 <dicksuckersrus> I am new to bitcoin
216 2012-06-28 22:27:28 <dicksuckersrus> I am looking for the gayboy bitcoin channel
217 2012-06-28 22:27:31 <dicksuckersrus> is this it?
218 2012-06-28 22:27:52 <JFK911> BlueMatt: oh hey, you made me realize that stupid linux forgot to implement i386(1) from sysv.
219 2012-06-28 22:28:11 <JFK911> solaris has it still
220 2012-06-28 22:28:48 <BlueMatt> maaku: oh...containers, meh just run uname or lsb_release
221 2012-06-28 22:29:15 <BlueMatt> maaku: maybe /proc/cpuinfo, otherwise probably cant tell, aside from host kernel
222 2012-06-28 22:48:53 <gribble> New news from bitcoinrss: fanquake opened pull request 1530 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1530>
223 2012-06-28 23:07:10 <maaku> uname -p seems to have done the trick :)
224 2012-06-28 23:35:38 <D34TH> what is this wizardry, gitian-updater.exe
225 2012-06-28 23:39:36 <BlueMatt> D34TH: py2exe/cx_Freeze version of https://github.com/devrandom/gitian-builder/blob/master/share/gitian-updater
226 2012-06-28 23:40:51 <BlueMatt> and before you ask, you have to get the gpg2.exe binary from http://www.gpg4win.org/ (or their sources, if you feel like building)
227 2012-06-28 23:41:02 <D34TH> dont worry i have gpg
228 2012-06-28 23:42:02 <D34TH> darn i dont have gpg2
229 2012-06-28 23:42:13 <BlueMatt> whered you get gpg on windows?
230 2012-06-28 23:42:31 <D34TH> damn good question
231 2012-06-28 23:42:42 <D34TH> gpg4win
232 2012-06-28 23:43:08 <BlueMatt> heh...thought so
233 2012-06-28 23:43:12 <D34TH> but i have 1.1.4 of gpg4win
234 2012-06-28 23:43:24 <BlueMatt> not sure if it matters, you can try with gpg v1, may work
235 2012-06-28 23:43:45 <BlueMatt> gpg2 is just the exe name of a binary that worked when I tested it with some recent version a week or so ago
236 2012-06-28 23:45:30 <D34TH> me right now : http://britfa.gs/b/src/133947372769.jpg