| 00:02:13 | randy-waterhouse: | petertodd: maybe there is an unmet demand (and wiggle room) for a system built on bitcoin that has "slightly less" security than bitcoin yet provides for faster, cheaper, etc ... ? |
| 00:02:41 | petertodd: | randy-waterhouse: of course there is, that's how alt-coins have come to exist for instance |
| 00:03:04 | petertodd: | randy-waterhouse: but people should be honest that such systems have quite a bit less ecurity than bitcoin; I'm not seeing that |
| 00:03:43 | randy-waterhouse: | i said slightly less ... not quite a bit less |
| 00:04:18 | petertodd: | randy-waterhouse: there's not much wiggle room between full and less unfortunately - merge mining makes all of bitcoin less secure, yet gives fairly poor security |
| 00:04:34 | petertodd: | randy-waterhouse: the whole idea behind tree-chains is to offer "slightly-less", but it requires a soft-fork at least |
| 00:06:17 | randy-waterhouse: | http://satoshi.nakamotoinstitute.org/posts/bitcointalk/532/ |
| 00:06:25 | randy-waterhouse: | http://satoshi.nakamotoinstitute.org/posts/bitcointalk/533/ |
| 00:06:36 | petertodd: | bbl |
| 01:03:42 | phantomcircuit: | blargh |
| 01:03:47 | phantomcircuit: | stupid office buildings |
| 01:03:53 | phantomcircuit: | turn off the central ac on the weekend |
| 01:04:45 | sipa: | i hope your office doesn't double as a datacenter, in that case :p |
| 01:07:07 | phantomcircuit: | sipa, there is an electronics room |
| 01:07:17 | phantomcircuit: | it was 85F when i went in there |
| 01:07:19 | phantomcircuit: | >.> |
| 01:07:38 | phantomcircuit: | fortunately we have a portable ac unit in there |
| 01:34:50 | phantomcircuit: | sipa, oh god |
| 01:34:57 | phantomcircuit: | the exhaust just goes into the drop ceiling |
| 01:34:58 | phantomcircuit: | lol |
| 01:35:05 | phantomcircuit: | this is worse than useless |
| 01:41:44 | nsh: | nsh has left #bitcoin-wizards |
| 02:31:42 | phantomcircuit: | gmaxwell, that tor node is kind of interesting |
| 02:31:54 | phantomcircuit: | i wonder if someone is using it explicitly to exit the network |
| 02:32:41 | gmaxwell: | yea, I don't see how anyone else would use it. |
| 02:33:10 | gmaxwell: | my thinking was that someone is using it as an explicit exit to pretend to be "from tor" when it really isn't, not realizing that actual tor users wouldn't use it as an exit. |
| 02:33:39 | gmaxwell: | e.g. to make an attack that the tor network doesn't really have bandwidth for, but then plausably claim it wasn't them. |
| 02:34:35 | gmaxwell: | phantomcircuit: any of your nodes connected to that IP? |
| 02:35:20 | phantomcircuit: | gmaxwell, probably not i haven't restarted any of them in about a month |
| 02:38:12 | phantomcircuit: | gmaxwell, 40Gh/s @ diff 256 should be 1 share every ~30 seconds right |
| 02:38:39 | phantomcircuit: | hmm that's only 60 shares/hour |
| 02:38:45 | dsnrk: | ;;gentime 400000 256 |
| 02:38:45 | gribble: | The average time to generate a block at 400000.0 Mhps, given difficulty of 256.0, is 2 seconds |
| 02:38:58 | dsnrk: | ;;gentime 40000 256 |
| 02:38:58 | gribble: | The average time to generate a block at 40000.0 Mhps, given difficulty of 256.0, is 27 seconds |
| 02:39:03 | dsnrk: | better. |
| 02:39:44 | phantomcircuit: | it's so much easier to do target checks for multiples of 256 |
| 02:43:23 | phantomcircuit: | petertodd, none of the mining pools would bother pretending like they were a tor exit node |
| 02:44:14 | petertodd: | phantomcircuit: I said that in the spirit of "don't assume malice when stupidity might be the case" |
| 02:44:17 | dsnrk: | if they were doing port 3333 I would say they are stealing stratum shares.. but 8333? |
| 02:44:49 | petertodd: | phantomcircuit: anyway, the lack of an exit flag is a nice gotcha in that plan, assuming they're trying to accomplish plausible deniability |
| 02:46:11 | dsnrk: | https://twitter.com/puellavulnerata/status/493566933888159744 < hearn? |
| 02:47:28 | gmaxwell: | petertodd: I perhaps shouldn't have mentioned that so obviously, I've slain a fair amount of bad behavior in the past from people who didn't know about that detail. |
| 02:47:55 | petertodd: | gmaxwell: yeah, that's why I didn't mention it :) |
| 02:48:12 | petertodd: | gmaxwell: I already tried that on one of my tor relay nodes to see if it'd work |
| 02:48:33 | gmaxwell: | there is also a 'exploit' to get the flag when you shouldn't really. I reported it, but I don't think they've fixed it. |
| 02:49:08 | gmaxwell: | if you feel like testing it, add to your allowed list exiting 80/443 to the multicast address space. |
| 02:49:23 | petertodd: | gmaxwell: oh, that's all it takes? lame |
| 02:49:31 | gmaxwell: | (you still will mostly not get selected as an exit, but you'll get the flag if they haven't fixed that) |
| 02:49:54 | gmaxwell: | petertodd: the test is that you exist to 80/443 at least a /8, I believe.. but no test that the /8 is routable. |
| 02:50:16 | petertodd: | huh, would have expected the test to be that you actually exit, via trying some test ips |
| 02:50:29 | gmaxwell: | thats what badexit flag is for. |
| 02:50:57 | gmaxwell: | you'd think that you wouldn't get exit unless you exited enough for the badexit tests to work, but at least two years ago that wasn't the case; it might have been fixed. |
| 02:51:02 | gmaxwell: | (as I did report it) |
| 02:52:12 | petertodd: | well there's some documentation on torproject.org that suggested operating exits that didn't exit to 80/443 as a way to provide exiting without getting in trouble |
| 02:52:36 | petertodd: | dsnrk: that tweet it from a tor core dev, but I dunno if it's joking or not |
| 02:52:49 | gmaxwell: | Yea, I think thats just outdated or wrong. But maybe I'm outdated. |
| 02:53:25 | petertodd: | in any case, it's not all that interesting of an attack - would make more sense to split up the capacity across multiple exits/nodes |
| 02:53:29 | gmaxwell: | At least at one point it wouldn't ever select an exit without the exit flag, and you couldn't ever get the exit flag without exiting either 80 or 443 to a pretty big chunk of space (I believe a /8) |
| 02:53:32 | dsnrk: | petertodd: I don't think she would make a joke like that |
| 02:53:53 | petertodd: | dsnrk: yeah, it is a bit too specific... |
| 02:54:13 | dsnrk: | I mean I don't know her, but from the two comments she made about mike neither of them are amusing, more scathing. |
| 02:54:19 | kazcw: | I have an inbound connection to the spooky node. /Satoshi:0.9.2/, bytessent=11MB, bytesrecv=86k |
| 02:54:33 | kazcw: | from the node, rather |
| 02:54:33 | petertodd: | dsnrk: well, you can do both at once :) |
| 02:55:17 | dsnrk: | kazcw: that seems a little asymmetric doesn't it? |
| 02:55:30 | petertodd: | kazcw: got logs on what it's sending? |
| 02:55:37 | gmaxwell: | kazcw: sweet. hm. can you spin up wireshark and see what its doing? is the bytessent=11MB unusual compared to your other peers (factoring in uptimes?) |
| 02:56:01 | kazcw: | I have other peers with both sent and recv in the same ballpark |
| 02:56:03 | mr_burdell: | I have it connected to two of my nodes |
| 02:56:21 | gmaxwell: | mr_burdell: same questions to you |
| 02:56:35 | dsnrk: | I'm not seeing it on my IPV6 node so I can't cap it. super curious to know what it's doing though. |
| 02:56:41 | gmaxwell: | it might be some jackass trying to get bitcoin to ban tor, but made a mistake in the exit flag, so we know that it's the actual host operator and not to users. |
| 02:57:04 | mr_burdell: | "bytessent" : 107898, |
| 02:57:04 | mr_burdell: | "bytesrecv" : 241, |
| 02:57:18 | dsnrk: | gmaxwell: I think they might be trying to connect to every single node and do the whole "sniff every transaction and not send anything back" deal. |
| 02:57:28 | dsnrk: | mr_burdell's message backs that up. |
| 02:57:47 | mr_burdell: | "bytessent" : 349301, |
| 02:57:47 | mr_burdell: | "bytesrecv" : 851, |
| 02:58:26 | dsnrk: | what's the IP address of the node? |
| 02:58:45 | gmaxwell: | do you have only one connection to it? |
| 02:58:49 | dsnrk: | wait i know that. |
| 02:59:00 | dsnrk: | idiot. |
| 02:59:18 | mr_burdell: | "bytessent" : 62454, |
| 02:59:18 | mr_burdell: | "bytesrecv" : 180, |
| 02:59:29 | mr_burdell: | it's connected to three of my nodes |
| 03:00:06 | mr_burdell: | I don't really have a good interface to run wireshark on those |
| 03:00:07 | kazcw: | I'm not hearing anything from it but pongs |
| 03:02:03 | gmaxwell: | maybe someday the whitelisting thing could be used to exchange adjacency information— e.g. mutually whitelisting peers share their non-whitelisted inbound connections, and if someone shows up on both they get banned with some probablity that depends on the number of whitelisted connections you have... such that connecting out to more than a small number of hosts is negative ev in connection count. |
| 03:02:15 | dsnrk: | I'd be willing to bet everybody on IPv4 is connected to that node currently. |
| 03:02:28 | gmaxwell: | dsnrk: nope. I have two nodes that aren't. |
| 03:02:49 | dsnrk: | alright, so I'm not just an outlier. |
| 03:02:52 | dsnrk: | weird. |
| 03:02:55 | gmaxwell: | but maybe it couldn't make it in or ... oh, hey, i've iptables banned that subnet already. |
| 03:03:07 | gmaxwell: | man, wish I kept notes on why. |
| 03:03:18 | dsnrk: | it's on a super dodgy VPS host |
| 03:03:23 | mr_burdell: | gmaxwell: it's hetzner |
| 03:03:39 | mr_burdell: | very cheap systems |
| 03:04:30 | dsnrk: | wonder why I'm not seeing it. |
| 03:04:45 | gmaxwell: | v6 only? |
| 03:07:16 | dsnrk: | it's meant to be both but seems to be only getting v6 peers. unrelated problem. |
| 03:07:26 | dsnrk: | http://blockchain.info/ip-address/5.9.93.101 < that's interesting |
| 03:07:37 | mr_burdell: | https://blockchain.info/blocks/5.9.24.81 |
| 03:08:21 | dsnrk: | mr_burdell: that's a different hetzner IP though, could be anybody |
| 03:08:26 | mr_burdell: | but that just shows that hetzner has a lot of bitcoin nodes |
| 03:08:28 | mr_burdell: | yeah |
| 03:08:50 | dsnrk: | the one you linked to is nogleg, one of the bigger nodes |
| 03:09:02 | gmaxwell: | dsnrk: what that shows is that bc.i is also tracking people that make inbound connections, since you can't connect into 5.9.93.101. |
| 03:09:03 | mr_burdell: | doesn't surprise me that they relay a lot of transactions first if they connect to every node |
| 03:09:28 | gmaxwell: | kazcw's pong comment isn't consistent with that. |
| 03:09:30 | kazcw: | it surprises me, they don't seem to relay me any transactions |
| 03:10:00 | dsnrk: | gmaxwell: maybe their earlier setup listened and now it doesn't? the bc.i stuff looks old. |
| 03:10:07 | dsnrk: | let me see what bitnodes says about it. |
| 03:10:16 | gmaxwell: | dsnrk: or it was just a different user on that host. |
| 03:10:20 | mr_burdell: | maybe it's bc.i's node |
| 03:10:30 | dsnrk: | no, I know their rage. |
| 03:10:40 | gmaxwell: | yea, it's not bc.i's normal range. |
| 03:10:47 | gmaxwell: | (I have that banned too…) |
| 03:10:56 | mr_burdell: | ah, i see |
| 03:11:13 | mr_burdell: | oh, right, it stopped in june |
| 03:11:39 | dsnrk: | gmaxwell: that might be right, bitnodes.io doesn't seem to have crawled that IP address which suggests it was never listening. |
| 03:12:23 | gmaxwell: | it's not surprising that bc.i monitories people who connect inbound, but I don't think I previously had evidence of that. |
| 03:12:45 | dsnrk: | hold on, google is showing they do exist. bitnodes search is just funky. |
| 03:12:55 | dsnrk: | let me find their data and process it manually. |
| 03:13:36 | dsnrk: | there's a record on bitnodes.io from 6 days ago at least. |
| 03:14:02 | dsnrk: | 2 weeks. |
| 03:14:07 | mr_burdell: | does bitnodes only do outbound crawling? |
| 03:14:12 | dsnrk: | yes. |
| 03:14:27 | gmaxwell: | yea, so it was previously running bitcoin, I'm guessing the tor thing really is just an operating cover. |
| 03:14:30 | gmaxwell: | which failed |
| 03:14:44 | gmaxwell: | which suggests that the control of the host is not solidly anonymous. |
| 03:14:49 | dsnrk: | wish I could find the bitnodes.io data dump, they seem to have moved it or hidden it. |
| 03:14:53 | gmaxwell: | and that the operator doesn't want people knowing who they are. |
| 03:15:07 | dsnrk: | which suggests something shady. |
| 03:16:38 | mr_burdell: | https://getaddr.bitnodes.io/nodes/1406517300.json |
| 03:17:32 | dsnrk: | so for the last 2-3 weeks it has listened on 8333, then 3 days ago it switched to a "cover" of Tor. |
| 03:17:41 | dsnrk: | it doesn't relay anything, just listens. |
| 03:18:11 | dsnrk: | it runs Satoshi 0.9.2. |
| 03:18:15 | dsnrk: | *0.9.1 |
| 03:18:32 | mr_burdell: | 0.9.2 in my logs |
| 03:18:35 | kazcw: | its connection to my node opened at 2014-07-24 10:29:37 utc |
| 03:21:12 | kazcw: | I have connections from 5 other peers with version=0.9.2 and startingheight=302684, which seems suspicious though far from conclusive. unfortunately no IPs or other details because none of them are active connections and none have done anything my node felt log-worthy (current git, no extra debugging) |
| 03:21:12 | mr_burdell: | 2014-07-15 05:37:02 receive version message: /Satoshi:0.9.1/: version 60002, blocks=302684, us=ip:8333, them=0.0.0.0:0, peer=5.9.93.101:48793 |
| 03:21:12 | mr_burdell: | 2014-07-15 10:09:38 receive version message: /Satoshi:0.9.2/: version 70002, blocks=302684, us=ip:8333, them=0.0.0.0:0, peer=5.9.93.101:52739 |
| 03:21:40 | gmaxwell: | can someone try to exit 8333 through it and see if it intercepts the connection locally? |
| 03:21:49 | gmaxwell: | I bet thats what it does. |
| 03:21:55 | mr_burdell: | it seems to have updated from 0.9.1 to 0.9.2 on 7/15 |
| 03:23:04 | dsnrk: | the version number is odd isn't it? |
| 03:23:36 | mr_burdell: | the 60002? |
| 03:23:39 | dsnrk: | mm |
| 03:23:52 | kazcw: | its startingheight is from 05/26, and strangely fixed |
| 03:23:58 | gmaxwell: | cute. |
| 03:24:32 | dsnrk: | so maybe it's not bitcoind at all? |
| 03:26:04 | gmaxwell: | the 60002 says its not, it's a poor immitation. |
| 03:27:29 | dsnrk: | sad we can't connect to it and fingerprint it's responses. |
| 03:27:37 | gmaxwell: | we might be able to |
| 03:27:39 | gmaxwell: | one sec |
| 03:27:48 | mr_burdell: | from the other side... |
| 03:27:59 | dsnrk: | trying to set bloom filters for example would be very informative |
| 03:29:56 | mr_burdell: | so what would be the end goal to track this down... to see if there's a real bug they may be trying to exploit? |
| 03:30:20 | dsnrk: | looks like it could be protocoin, a python bitcoin node which uses version 60001 as well. |
| 03:30:24 | gmaxwell: | can someone tell me a reachable ipv4 peer I can try to addnode? |
| 03:30:28 | mr_burdell: | you can't just ban them though if it's just someone trying some dos or something |
| 03:30:53 | mr_burdell: | gmaxwell: electrum.thwg.org |
| 03:31:04 | mr_burdell: | is my electrum server... should work |
| 03:31:16 | dsnrk: | I don't think there's any aim in finding things out, but it's fun to try. |
| 03:31:40 | mr_burdell: | that's what I figured |
| 03:32:03 | dsnrk: | it's probably just trying to do what everybody else does, connect to every node and sniff hard. |
| 03:32:12 | gmaxwell: | looks like it's not actually working as an exit either. |
| 03:32:33 | kazcw: | I bet it won't respond to any other messages, if all it does is reply to pings and listen it could be very simple |
| 03:33:55 | kazcw: | otoh, it's possible they based it on something existing and didn't completely strip out the functionality they don't want |
| 03:34:27 | mr_burdell: | kazcw: it looks like they've modified it as it's been going |
| 03:34:38 | dsnrk: | the only thing I could find on github with that version number was the protocoin python client and a fork of it. |
| 03:34:45 | mr_burdell: | switched to 0.9.2 on 7/15 for example |
| 03:35:17 | jcorgan: | hmm, i have two circuits with that node as a middle node, but none as an exit |
| 03:36:54 | dsnrk: | mr_burdell: and the bit where they went from listening (probably a real node) to just sniffing. |
| 03:37:07 | dsnrk: | when they were lsitening they did relay transactions, now they don't. |
| 03:37:29 | mr_burdell: | dsnrk: my logs don't go back that far |
| 03:37:30 | gmaxwell: | what I'm trying to determine right now is if they're directly intercepting traffic that exits via them, but I can't even manually exit, it seems. |
| 03:37:41 | mr_burdell: | i think debug.log gets rotated? |
| 03:39:29 | dsnrk: | first record I can find of them is 29/5 when they related to blockchain.info about 300 transactions. |
| 03:40:21 | kazcw: | testable protocoin deviation from bitcoin: accept connection, say hi with version <= BIP0031_VERSION, protocoin would respond to pings (with nonce), bitcoin would ignore them |
| 03:41:32 | kazcw: | it looks like protocoin also will accept and verack a version regardless of whether it already received one |
| 03:43:43 | dsnrk: | the node was announcing itself as 0.8.5 on the 30th of may. |
| 03:44:51 | dsnrk: | (google cache of http://bitcoin-roulette.com/connected-nodes/ip/5.9.93.101/ ) |
| 03:46:24 | dsnrk: | 2 days ago it was announcing itself as 0.9.1 ver 700002 to bitnodes.io |
| 03:47:19 | kazcw: | hm, that'd be after it connected to me with version=0.9.2 |
| 03:47:45 | mr_burdell: | yeah... all of mine show the change from 0.9.1 to 0.9.2 at the same time |
| 03:52:51 | kazcw: | any of the versions "/Satoshi:0.9.1", no trailing slash? |
| 03:55:52 | mr_burdell: | not in my logs |
| 04:32:31 | gmaxwell: | https://lists.torproject.org/pipermail/tor-dev/2014-July/007167.html is the context for that tweet, fwiw. |
| 04:33:20 | gmaxwell: | also https://lists.torproject.org/pipermail/tor-relays/2014-March/004093.html |
| 04:46:40 | kazcw: | the anomaly just pinged me! |
| 04:47:15 | dsnrk: | ping? |
| 04:47:41 | kazcw: | it sent a single "ping" message, the only thing I've seen except for pongs |
| 04:51:19 | dsnrk: | still interesting that it tried to hide itself. if it was just sniffing it would have remained hidden if it hasn't tried. |
| 04:54:19 | kazcw: | I built a quirky bitcoind and set up a special NAT rule for our friend, let's see how it acts under unusual circumstances |
| 04:56:09 | Dr-G2: | Dr-G2 is now known as Dr-G |
| 06:09:09 | phantomcircuit: | gmaxwell, lol that is hilarious |
| 06:09:19 | phantomcircuit: | mike obviously has no idea how hidden services work |
| 09:32:42 | wallet421: | wallet421 is now known as wallet42 |
| 09:50:42 | wumpus: | I don't like mike's line of thinking at all, looks like he's trying to introduce censorship to tor hidden services (as if that makes sense at all, hidden services can generate new keys whenever they want) |
| 09:52:07 | wumpus: | but it seems diametrically opposed to what tor is trying to do in the first place |
| 09:56:00 | topynate_: | hi, i think i've come up with a way of trustlessly paying for a document based on a ZKP. Does anything like that exist currently? |
| 10:04:43 | topynate_: | same sort of setup as in paypub: the seller chunks the document, hashes them and reveals the hashes, then some random set of chunks |
| 13:05:05 | jgarzik: | jgarzik is now known as home_jg |
| 14:10:24 | gmaxwell: | topynate_: I'd suggested before a way of paying for an image 'trustlessly' where you cut-and-choose proof and reveal a subset of the pixels (then use techniques from compressed sensing to recover a low resolution image from it), so perhaps similar to what you were thinking? |
| 14:10:33 | gmaxwell: | It didn't sound terribly useful though. |
| 14:11:07 | justjoe: | http://uro.io/ |
| 14:15:22 | gmaxwell: | justjoe: please don't advertise altcoins in here. |
| 14:16:19 | justjoe: | apologies ... it wasn't an advert just an observation ... are they for real? 1 tonne of urea backed by a blockchain token? |
| 14:16:40 | justjoe: | seems like a strange new twist on alts ... |
| 14:16:48 | justjoe: | professional pumpers maybe? |
| 14:17:16 | gmaxwell: | more like the oldest twist on alts, see also beertoken. :) (first bitcoin altcoin, I believe :) ) |
| 14:17:19 | justjoe: | http://www.free-press-release-center.info/pr00000000000000278227_uro-completes-worlds-first-commodity-order-using-a-commodity-backed-cryptocurrency.html ? |
| 14:17:36 | justjoe: | but they seem to be putting their real names to it ... brazen if nothing else |
| 14:17:53 | justjoe: | yeah, beertoeksn and weeds, those were the cool days |
| 14:18:01 | justjoe: | where has that guy got to I wonder? |
| 14:18:54 | gmaxwell: | he showed up briefly in bitcoin-dev a few months ago. |
| 14:19:51 | justjoe: | the original altcoiner should get his name in folklore somewhere, he was first to produce a 'new' genesis block after satoshi i think |
| 14:21:28 | gmaxwell: | In any case, I thought the urea stuff wasn't anything new? See also https://bitcointalk.org/index.php?topic=687231.0 (of course, in the altcoin space the scam hunters are illiterate too) |
| 14:23:11 | justjoe: | maybe not ... first indication i have seen that legitamte trade maybe taking place with it seems to be the development here I guess. |
| 14:24:10 | gmaxwell: | the development here? |
| 14:24:14 | justjoe: | just brazen scammers ... |
| 14:24:19 | justjoe: | the scale |
| 14:44:35 | danielpbarron: | danielpbarron has left #bitcoin-wizards |
| 16:14:27 | maaku: | maaku is now known as Guest37940 |
| 16:46:05 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 17:50:04 | ryan`c: | ryan`c is now known as ryan-c |
| 17:54:40 | Guest37940: | Guest37940 is now known as maaku |
| 18:59:30 | davispuh: | davispuh is now known as _Peacekeeper |
| 18:59:37 | _Peacekeeper: | _Peacekeeper is now known as davispuh |
| 19:12:17 | home_jg: | home_jg is now known as jgarzik |
| 19:14:32 | regiuz: | regiuz has left #bitcoin-wizards |
| 19:22:57 | jgarzik: | atgreen, |
| 19:22:59 | jgarzik: | jgarzik@hum:~/local/build$ ~/clonerepo/binutils-gdb/configure --target=moxiebox --prefix=/home/jgarzik/local --disable-gdbtk |
| 19:22:59 | jgarzik: | configure: error: cannot run /bin/bash /home/jgarzik/clonerepo/binutils-gdb/config.sub |
| 19:23:13 | jgarzik: | atgreen, that's upstream binutils-gdb.git + your config.sub replaced |
| 20:43:54 | atgreen: | hrmmm |
| 20:44:14 | atgreen: | oh, permissions. just chmod +x it. |
| 20:44:39 | atgreen: | jgarzik: the config.sub was just accepted into the upstream config repo, and I pushed it into gcc. |
| 20:45:04 | atgreen: | so instead of shipping own own, we can just copy it from gcc into binutils-gdb and src until those repos get updated. |
| 20:46:09 | jgarzik: | atgreen, +x didn't work. that was the first thing I tried. same error before and after. |
| 20:46:15 | atgreen: | one sec |
| 20:46:28 | atgreen: | when did you pull your gcc sources? |
| 20:46:46 | jgarzik: | atgreen, this morning, Eastern Time |
| 20:47:02 | jgarzik: | atgreen, but I didn't get as far as gcc |
| 20:47:09 | jgarzik: | atgreen, binutils didn't go, so stopped there. |
| 20:47:15 | atgreen: | oh..hmm. |
| 20:49:03 | atgreen: | I'm just reproducing now |
| 20:51:37 | cluckj: | mitosis or meiosis? |
| 20:59:42 | jgarzik: | cellular mitosis |
| 20:59:53 | atgreen: | would you believe allogamy? |
| 21:01:32 | atgreen: | I did this the wrong way. GCC is huge. I can change the dl script to omit java, ada and friends. |
| 21:04:05 | cluckj: | nice |
| 21:32:49 | atgreen: | jgarzik: what platform are you on?? |
| 21:38:26 | jgarzik: | atgreen, Ubuntu 14 / Linux x86-64 |
| 21:39:38 | atgreen: | It worked for me, but I adjusted the script to reflect the fact that the patch isn't needed anymore for gcc. Let send a PR. You can get the latest config.sub from gcc and copy it into binutils-gdb and src for now. |
| 21:39:55 | atgreen: | I mean.. "Let me send a PR" |
| 21:47:26 | atgreen: | PR updated. And everything built cleanly for me. |
| 21:49:13 | atgreen: | make check worked just fine. |
| 22:17:55 | atgreen: | jgarzik: any luck? I just ran through everything from scratch, no problem. |
| 22:19:42 | jgarzik: | atgreen, -ENOTIME alas |
| 22:20:55 | jgarzik: | atgreen, as a general note, since it looks like things are going upstream quite quickly, waiting until everything is upstream in binutils+gcc before merging your PR seems like a reasonable course |
| 22:21:26 | jgarzik: | atgreen, and I'm interested in your comments RE newlib, I/O wrappers sent via email |
| 22:22:03 | atgreen: | ok |
| 22:39:00 | nsh: | * nsh investigates this moxiebox hoohah |
| 22:58:11 | eizh_: | eizh_ is now known as eizh |