01:18:58 <gingeropolous> would changing --public-node to --public-rpc-node muck things up much?
08:24:02 <dEBRUYNE> luigi1111: When tag? :-P
08:34:26 <dEBRUYNE> fluffypony, Snipa: Perhaps available to set the tag?
08:40:52 <M5M400> tag tag tag
08:42:10 <hyc> you're it
08:42:13 <mj-xmr> Guten Tag.
08:43:23 <M5M400> ideally.
09:40:28 <selsta> tag is up for those doing reproducible builds
09:40:38 <binaryFate> yay
10:02:17 <dgcigbbxfbv> What kind of person steals from own community?https://www.reddit.com/r/Monero/comments/6d5yt5/what_fluffypony_just_did_is_not_ok/ Your own leaders are laughing at how moronic you are for falling for thier 'Magical Crypto Friendship'.
11:17:25 <sech1> Has anyone started reproducible builds yet? I want to try it today, any link to instructions?
11:31:33 <hyc> mine just finished
11:31:44 <hyc> just read contrib/gitian/README.md
11:32:43 <sech1> Ok, I'll try today with Ubuntu 18.04 VM
11:34:46 <hyc> https://paste.debian.net/1178958/
11:35:16 <hyc> gitian supports docker and lxc, but I think it's easiest to use docker
11:43:00 <wowario[m]> sech1: half way
12:11:24 <sech1> hyc wowario I'm running the build in a VM (6 cores of Ryzen 5600X). How long should it normally take?
12:21:47 <hyc> 2 hours ~
13:04:00 <sethsimmons> <selsta "tag is up for those doing reprod"> Started, will try to PR signed hashes for the first time today!
13:20:03 <sech1> still running, but at least I have the same hash for monero-x86_64-linux-gnu-v0.17.1.8.tar.bz2 (I haven't checked others yet)
13:20:21 <sech1> Running v0.17.1.8 without the ban list on my node now
13:49:11 <iDunk> https://paste.debian.net/hidden/37477499/
13:59:54 <sech1> my hashes: https://paste.debian.net/1179027/
14:34:47 <binaryFate> thanks hyc, iDunk, sech1
14:39:27 <sech1> I just noticed I don't have Apple build. Do I need to do something more to build it?
14:40:14 <coffeeroaster> Is the block height off by 2 issue still around? Still seeing it with commit 36dfd41e0 (and no ban list)
14:41:03 <sech1> looks like it
14:42:59 <sech1> yes, my 0.17.1.8 node got +2 issue and hasn't banned any IP so far
14:43:52 <sech1> hmm, and it's back to normal again
14:44:08 <sech1> Height: 2263568/2263568 (100.0%) on mainnet, not mining, net hash 1.67 GH/s, v14, 64(out)+22(in) connections, uptime 0d 1h 24m 25s
14:44:10 <moneromooo> We don't care much now since the gui was fixed.
14:44:34 <sech1> I'll apply the ban list anyway (the one without tor IPs)
14:47:28 <binaryFate> Probably helps to apply ban list for everyone else, so you don't advertise bad nodes to people who might not be on latest version
14:48:15 <coffeeroaster> moneromooo: you mean the gui,cli wallets can tolerate the off by two? If so can you explain how?
14:48:54 <binaryFate> I'm using the ban list that does not include tor nodes, to help tor users. No issue so far with latest tag
14:49:32 <coffeeroaster> binaryFate: where is that list?
14:50:16 <binaryFate> coffeeroaster: https://gui.xmr.pm/files/block.txt for bad nodes, and https://gui.xmr.pm/files/block_tor.txt for bad nodes + tor exit nodes
14:54:59 <selsta> 15:44 <moneromooo> We don't care much now since the gui was fixed. <-- it was not fixed yet, we wrote some code for it but with the memory attack I did not look into it further
14:55:27 <selsta> coffeeroaster: did you check if the +2 nodes get kicked after a while?
14:57:31 <coffeeroaster> selsta: I had it running for the past 9 hours or so and off by one still there. Didn't see any evidence of bans. Btw how do I check the block height of each peer?
14:57:45 <selsta> sync_info
14:58:35 <selsta> we had to revert a fix that was related to the +2 attack because it had issues with reorgs
14:58:55 <selsta> we focused on getting a release out because of the oom attack
15:05:05 <coffeeroaster> selsta: makes sense. wow 10/13 of  peers (from sync_info) are in the ban list
15:07:04 <coffeeroaster> 10/12 rather
15:08:25 <selsta> It did kick +2 nodes in the past days so I wonder if they changed behaviour again
15:21:50 <coffeeroaster> selsta: might be interesting to add more detail in "sync_info". Are there other tools to detect anomalies?
15:31:12 <selsta> coffeeroaster: weird... they do get kicked on my node
15:31:22 <selsta> after like 15 seconds
15:32:11 <binaryFate> Same here, I see the +2 only intermittently, doesn't last long (~15s)
15:33:00 <sech1> yes, I saw +2 and then it vanished. Running with the ban list now
15:34:22 <luigi1111> whoops sorry team
15:34:55 <coffeeroaster> huh I'll do a new build to be sure then.
15:52:36 <selsta> Love Windows anti virus deleting stuff while I’m trying to do binaries :D
15:57:06 <gingeropolous> i just compiled v0.17.1.8 and i still get synchronized OK spam
15:57:20 <gingeropolous> 4000 lines outta the last 10k lines
15:57:42 <selsta> 4000 times?
15:57:47 <gingeropolous> yep
15:58:15 <selsta> maybe these are old logs?
15:58:37 <gingeropolous> i noticed it cause i'm tail -f bitmonero.og
15:59:05 <selsta> I have been running it for the past days without ban list and don’t get it.
15:59:31 <selsta> which log level are you running?
15:59:58 <gingeropolous> an ip just got blocked
16:01:46 <gingeropolous> yeah sorry old logs. but i was getting it recently, and then it got blocked, and it stopped, so yay
16:12:21 <sech1> Running without the ban list again, so far so good. No synchronized OK spam, no +2 issue.
16:25:53 <Inge-> is it easy to try out a reproducible build under docker?
16:30:37 <sech1> Inge- not that hard, just create Ubuntu 18.04 VM and follow the instructions https://github.com/monero-project/monero/blob/master/contrib/gitian/README.md
16:31:18 <sech1> I had one small issue when the script couldn't connect to /var/run/docker.sock (permission denied), but I solved it by chmod 666 /var/run/docker.sock
16:31:28 <selsta> https://www.irccloud.com/pastebin/m3f2mEuk/
16:31:39 <selsta> I use ^ in a fresh 18.04 VM
16:32:36 <sech1> And this VM will need more than 10 GB space (VirtualBox default), mine ran fine with 25 GB
16:48:30 <Inge-> sech1: so I can't just run a docker container in say a 20.04 box
16:53:38 <sech1> Inge- I don't know, the instructions say 18.04 specifically
16:53:49 <sech1> maybe it will compile fine in 20.04, but with different hashes
16:54:19 <Inge-> yeah that would kind of defeat the purpose.
16:54:21 <selsta> afaik some people use 20.04 for host
16:56:34 <Inge-> I
16:56:43 <Inge-> I'll give it a spin. won't hurt to try.
16:59:23 <coffeeroaster> update: clean build looks much better. Haven't seen the +2 error yet
17:00:29 <selsta> still probably only  a matter of time until the attacker changes his method and it comes back
17:01:54 <sech1> But what's the point of continuing +2 attack if GUI has been fixed?
17:02:13 <sech1> I'm expecting something new on New Year's eve :D
17:02:14 <selsta> it does not have it fixed
17:02:22 <selsta> we have the code but I did not have time to fully test it
17:02:36 <selsta> and the ui was not optimized for it
17:02:45 <selsta> so it looked weird
17:02:49 <sech1> But but <moneromooo> We don't care much now since the gui was fixed.
17:04:24 <selsta> we didn’t include it in the release
17:06:23 <coffeeroaster> seeing regular stack traces in the logs with "allocLargePagesMemory". (also running on non-standard hw RPI4 64 bit)
17:07:07 <sech1> you need to allocate more huge pages to fix these stack traces
17:08:31 <sech1> selsta then +2 attack will probably continue. I don't really care since I use CLI, but I'm curious how the attack will be carried out this time.
17:08:45 <sech1> Height: 2263636/2263636 (100.0%) on mainnet, not mining, net hash 1.65 GH/s, v14, 64(out)+20(in) connections, uptime 0d 1h 29m 9s
17:08:50 <sech1> This is without ban list, so far
17:09:08 <sech1> Looks like +2 attack doesn't work on 0.17.1.8
17:10:28 <sech1> But I don't see any banned IPs either
17:13:25 <coffeeroaster> sech1: I'm seeing the same (with no bans). Can you elaborate on how to "allocate more huge pages"?
17:14:12 <selsta> sech1: like I said, we had to revert the +2 fix so they might get kicked because they also try to do the "synchronized ok" spam.
17:14:21 <selsta> we will see
17:14:45 <sech1> coffeeroaster sysctl -w vm.nr_hugepages=2048
17:14:55 <sech1> I use this on my node, but I run both xmrig and monerod
17:15:40 <sech1> you need to allocate as few huge pages as possible because unused pages will just sit in memory, leaving less free
17:16:52 <moneromooo> They only get allocated if the mmap flag is set ?
17:17:56 <sech1> if you change vm.nr_hugepages, they'll be always in the memory, just not used by any process
17:19:15 <coffeeroaster> and of course my kernel doesn't it
17:57:13 <wowario[m]> my hashes: https://paste.debian.net/1179051/
17:59:25 <selsta> everyone doing hashes please also submit to https://github.com/monero-project/gitian.sigs/pulls
18:12:18 <Snipa> Is there latest instructions for the gitian builds?
18:12:21 <Snipa> I'll kick one off today.
18:13:01 <selsta> I use https://www.irccloud.com/pastebin/m3f2mEuk/
18:13:11 <selsta> but I run that inside a VM that I later delete again
18:13:31 <Snipa> Thanks.
18:45:34 <mfoolb> trying to gitian build monero but something didn't work out: https://paste.debian.net/1179056/
18:48:50 <selsta> mfoolb: did you follow the readme or the steps I posted?
18:49:35 <mfoolb> I followed this: https://github.com/monero-project/monero/tree/master/contrib/gitian
18:49:53 <selsta> can you compare with https://www.irccloud.com/pastebin/m3f2mEuk/ to see if you did anything different?
18:51:05 <mfoolb> I'm using Ubuntu 18.04
18:51:35 <mfoolb> I forked and cloned the gitian.sigs too
18:52:05 <mfoolb> didn't do your 11 and 12
18:52:24 <selsta> ?
18:52:36 <selsta> 11?
18:52:46 <selsta> ah sorry, misread
18:53:05 <mfoolb> row number on your paste
18:53:42 <mfoolb> that's what I did: https://paste.debian.net/1179059/
19:02:47 <sech1> I think you need to add --docker to the last line
19:03:41 <mfoolb> sure I do
19:03:44 <mfoolb> sorry about that
19:46:02 <Snipa> Man that OSX cross-compile takes awhile.
19:50:42 <mfoolb> Snipa: it's probably me but I started from scratch again just to be sure and it stops a bit later: https://paste.debian.net/1179066/
19:53:42 <mfoolb> in builder/var/base-bionic-amd64.manifest I find: Reinstallation of linux-modules-extra-4.15.0-126-generic is not possible, it cannot be downloaded. + linux-modules-4.15.0-126-generic and linux-image-4.15.0-126-generic)
19:54:12 <Snipa> Mine's working fine, just not running the build in parallel for some reason.
19:54:48 <Mmmmmmmmmm> https://github.com/monero-project/monero/blob/master/src/rpc/core_rpc_server_commands_defs.h#L217
19:54:58 <Mmmmmmmmmm> How do I know what the actual method name is for that request?
19:55:20 <Mmmmmmmmmm> I tried curl http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"blocks_by_height","params":[1,2]}' -H 'Content-Type: application/json' and curl http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_blocks_by_height","params":[1,2]}' -H 'Content-Type: application/json'
19:55:34 <Snipa> Or more correctly, it is, just not in an obvious way.
19:55:57 <moneromooo> grep this in core_rpc_server.h
19:58:10 <ndorf> Mmmmmmmmmm: see https://web.getmonero.org/resources/developer-guides/daemon-rpc.html
19:58:19 <mfoolb> I tried thinking the more doing gitian builds the better but I failed for different reasone with 0.17.1.6 0.17.1.7 and 0.17.1.8..
19:59:02 <Mmmmmmmmmm> Oh, "Not all daemon RPC calls use the JSON_RPC interface." That part is key. Thanks ndorf
19:59:34 <selsta> mfoolb: can you post the exact command you used?
20:00:13 <mfoolb> ./gitian-build.py -j 3 --memory 6000 --docker --detach-sign --no-commit --build mfoolb v0.17.1.8
20:05:59 <SellLast> mfoolb, what is your host system?
20:06:44 <mfoolb> ubuntu 18.04 on a vm
20:07:22 <SellLast> is the ubuntu on bare metal?
20:08:03 <SellLast> people have had issues with using virtualbox on a mac... that's what i'm getting at
20:08:14 <mfoolb> vm with qemu on ubuntu 20
20:09:22 <mfoolb> vm with 18.04.5 LTS over 20.04.1 LTS to be precise
20:14:42 <sethsimmons> Why not just do it natively instead of in a VM?
20:14:53 <sethsimmons> If you’re running Ubuntu already its simple to just do it natively.
20:15:17 <sethsimmons> It all happens in Docker containers so the host doesn’t matter as long as you have Docker.
20:15:57 <mfoolb> I use a VM so every time I can start again from zero and I prefer not to mix those two systems
20:16:15 <mfoolb> anyway I thought most of you used vm's for gitian builds
20:16:29 <sethsimmons> You can always start from zero if you just clear out Docker afterwards.
20:16:46 <sethsimmons> I build reproducible on an Ubuntu 20.04 server with no issues.
20:16:52 <ndorf> i use VM because i don't want to install docker on my host. but i haven't tried .8 yet
20:17:30 <ndorf> didn't have any issues with earlier releases, though
20:17:39 <ndorf> also using qemu/kvm
20:17:45 <mfoolb> and last but not least in github it states clearly: Gitian host OS should be Ubuntu 18.04 "Bionic Beaver".
20:18:07 <sethsimmons> Thats what the Docker containers use as a base — that doesn’t need to be the host for Docker itself.
20:18:15 <mfoolb> ndorf: 0.17.1.7 couldn't work.. was missing some packages giving 404
20:18:28 <selsta> yea that was fixed
20:18:34 <sethsimmons> Thats the whole point of doing it in Docker — the host OS doesn’t matter.
20:19:08 <selsta> afaik there are some things done on host OS but 20.04 is fine
20:19:45 <mfoolb> well I can surely stay away from vm's but not in that system.. I could try on another one tomorrow
20:20:36 <selsta> next time you try ignore the readme and try following the paste I posted line by line
20:20:45 <sethsimmons> My exact commands from an Ubuntu 20.04 base: https://paste.centos.org/view/c745d210
20:20:49 <selsta> that is what I usually do
20:21:16 <mfoolb> selsta: that was for MAC OSX, wasn't it?
20:21:16 <mfoolb> I mean the last curl
20:23:22 <mfoolb> selsta: thanks I'll try those..
20:23:45 <mfoolb> sethsimmons: could you explain to me this one curl -O https://bitcoincore.org/depends-sources/sdks/MacOSX10.11.sdk.tar.gz ?
20:24:21 <sethsimmons> It’s a necessary dependency for the OSX builds AFAIK
20:24:41 <sethsimmons> Should only need to download it once unless you wipe all the directories after building for some reason.
20:24:45 <mfoolb> ok
20:24:48 <mfoolb> not trace of this on github
20:24:50 <sethsimmons> If you don’t build OSX you don’t need it.
20:26:04 <wowario[m]> i did the build on a fresh 18.04 ubuntu droplet on digital ocean
20:26:13 <selsta> it does say "Note: if you intend to build MacOS binaries, please follow these instructions to get the required SDK." but yea could be explained better
20:26:53 <ndorf> mfoolb: i'll fire it up in my VM shortly and let you know if i run into any trouble
20:27:46 <mfoolb> ok thanks.. consider I started from scratch.. I mean gitian.sigs fork and clone too
20:28:13 <ndorf> oh this is interesting, my old .7 daemon doesn't seem to want to exit on SIGTERM
20:32:45 <selsta> mfoolb: you can fork gitian.sigs after you are done with building the binaries
20:33:01 <mfoolb> ok
21:25:07 <mfoolb> sethsimmons: it surely is me .. I tried on Ubuntu 20.04 LTS.. you exact commands.. I received: bin/gbuild:23:in `system!': failed to run on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)
21:26:26 <mfoolb> build.log shows: https://paste.debian.net/1179081/
21:27:14 <sethsimmons> Hmm not sure what to make of that, the builds worked fine for me on .8 but I don’t know how to debug actual build issues
21:27:58 <selsta> mfoolb: there's no error message in your build logs
21:28:08 <mfoolb> https://paste.debian.net/1179082/
21:28:08 <selsta> hmm
21:28:23 <mfoolb> addedd some lines on top
21:28:23 <selsta> ok yea you are running out of ram
21:28:50 <selsta> try less parallel jobs
21:29:00 <selsta> -j2
21:29:34 <mfoolb> I'll do.. I used -j7 --memory 14000 on a 3900x with 16gb
21:29:50 <selsta> what did you set your VM to?
21:29:54 <selsta> or no VM?
21:30:00 <mfoolb> no VM this time
21:30:11 <selsta> ok, yea try -j4
21:30:53 <mfoolb> rebuild or still build?
21:31:21 <selsta> I don't know. Never used rebuild
21:31:29 <mfoolb> ok
22:30:16 <binaryFate> Binaries for new version 0.17.1.8 are available on getmonero.org
22:30:41 <binaryFate> Thanks to everyone who contributed to this one way or another!
22:31:47 <agentpatience007> :o
22:49:36 <mfoolb> binaryFate: thanks to you
22:51:20 <binaryFate> I'm merely stamping the crazy work of others
22:52:55 <binaryFate> "crazy" as in impressive, and "crazy" as in actually crazy round the clock in the last days and nights
22:53:44 <mfoolb> yes, we followed the situation and hard work put into it
22:53:51 <sech1> Interesting, +2 malicious nodes connect and get kicked quickly: https://paste.debian.net/1179092/
22:54:38 <selsta> I assume they get kicked because they also do "syncrhonized ok" spam
22:54:51 <selsta> we will see
23:15:25 <tevador> satisfying: https://paste.debian.net/hidden/e8896752/
23:26:23 <mnt_grrrl> looks like the cli linux 64 version has not been updated on the website
23:26:46 <mnt_grrrl> https://downloads.getmonero.org/cli/linux64 give you .7 not .8
23:26:51 <selsta> you might have the old version cached
23:27:25 <selsta> we still have the website setup wrong, we should remove local caching for redirect
23:28:01 <mnt_grrrl> that was it.
23:29:51 <mnt_grrrl> thank you!