00:03:24 <luigi1111w> travis says "You have used 11370 of 10000 credits"
00:04:43 <luigi1111w> I turned off the setting to use credits for OSS projects but it doesn't seem to do anything
00:06:45 <selsta> https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
00:06:50 <selsta> looks like we have to manually request more credits
00:08:18 <selsta> that’s annoying
00:09:45 <selsta> "We will be offering an allotment of OSS minutes that will be reviewed and allocated on a case by case basis. Should you want to apply for these credits please open a request with Travis CI support stating that you’d like to be considered for the OSS allotment."
00:33:50 <selsta> looks like Travis stopped supporting OSS completely https://news.ycombinator.com/item?id=25338983
00:36:03 <Snipa> Well, that's annoying.
00:39:27 <locustlord> selsta, what is this?
00:39:31 <locustlord> credit allocation?
00:39:37 <locustlord> what are credits in this context?
00:42:27 <selsta> CI for testing development builds (e.g. does it compile?)
00:44:46 <locustlord> isn't it best to compile on real hardware anyway?
00:45:06 <locustlord> surely someone has a spare laptop that can be used
00:46:14 <Snipa> Travis CI runs on every merge, and runs on "real" hardware for all that "real" matters in the CI processes with replicable builds.
00:46:36 <selsta> it runs on every PR and every merge
00:46:37 <Snipa> Up until now, they happened to support OSS pretty well, so easier than relying on someone to have 24/7 abilable hardware.
00:46:46 <selsta> yep
00:46:50 <locustlord> I see
00:46:55 <locustlord> so now what?
00:47:22 <Snipa> We'll figure something out, couple people in that HN thread moved to Circle CI, IIRC we use GH actions, which might be a solution as well.
00:47:33 <iDunk> GH Actions for depends targets ?
00:48:32 <selsta> Should not be too difficult to port to GH Actions, but we will end up with a lot of jobs per PR.
00:51:11 <selsta> CircleCI looks nice too
00:53:48 <selsta> GH Actions + caching will be fine
00:54:30 <selsta> will look into porting it
00:56:03 <TheCharlatan> should be easy enough. Ping me if you need help selsta. I can't seem to find information on what the actual parallel job limit is on GH actions.
00:56:46 <selsta> 20 concurrent builds
01:00:23 <TheCharlatan> nice, should be plenty.
02:08:18 <selsta> mining and p2p functional tests still occasionally fail, and I was not able to figure out which timeout to bump yet
02:08:23 <selsta> (on CI)
02:08:54 <selsta> AssertionError: Failed to mine successor to block 13 (initial block = 11)
02:09:24 <moneromooo> Not sure I want to care. We'd really need a way to ask it "are you still working on it", and there's no such thing.
02:09:37 <moneromooo> No sane one anyway :)
02:10:20 <moneromooo> Oh, or bump all timeouts to silly values, but test every couple seconds whether we're in the state we want.
02:10:31 <moneromooo> That's better.
14:38:38 <Lyza> morning y'all
14:39:25 <Lyza> working on doing deterministic builds for the new version. seems like everything went right, but the .zip files for the Windows versions can't be opened, as if the archives are corrupt. all of the tar.bz2 files are fine
14:39:55 <Lyza> hashes seem to match though
14:42:43 <Lyza> mmmm never mind, unzip in Linux will unpack them but Windows can't handle them and neither can 7zip. so.... that's weird. but not a huge deal I guess?
14:44:56 <Lyza> but I mean, they're Windows releases, so maybe it is an issue. if I were to unpack and repack it in Windows or something the hashes would stop matching I presume
14:55:37 <fluffypony> that's weird
14:55:40 <fluffypony> 7zip is pretty robust
15:02:52 <Lyza> 7zip just gives some generic "cannot open as archive" while windows gives me a real interesting "Please inset the last disk of the Multi-Volume set"
15:20:43 <webname888> Why lie about something that can be easily disproven?
15:20:44 <webname888> https://monerologs.net/monero/20201207#c165563
15:20:44 <webname888> https://github.com/fireice-uk/cryptonote-speedup-demo/blob/master/ecops64/ecops64-c.c#L4
15:20:45 <webname888> Why steal from your community and then laugh at them?
15:20:45 <webname888> https://www.reddit.com/r/Monero/comments/6d5yt5/what_fluffypony_just_did_is_not_ok/
15:20:46 <webname888> Reason is the same - to laugh at morons that are gullible enough to believe you and repeat your lies.
15:46:56 <Lyza> update: I am dumb
15:47:38 <Lyza> like 4 of the files got corrupted copying them over to the Windows machine somehow, everything is good now
15:54:44 <sethsimmons> Thats the struggle — report something that could be serious and just turns out to be bad luck 😅
20:01:26 <aubergine> hi
20:01:42 <aubergine> is monero nodejs library still maintained?
20:07:45 <aubergine> ?
20:16:04 <gingeropolous> much less cpu load in 17.1.6. thanks devs
20:16:45 <sethsimmons> <gingeropolous "much less cpu load in 17.1.6. th"> Oh, really? Any specific idea why?
20:17:00 <moneromooo> Dropping some cunt's spam.
20:17:13 <gingeropolous> i saw some conversation about a race condition. and what mooo said
20:19:22 <kinghat[m]> its a technical term
20:24:04 <sethsimmons> Ah the spam reduction, didn’t even think about the effect that will have on load and bandwidth
20:25:07 <aubergine> sethsimmons I always get 401 error upon connection
20:25:20 <aubergine> despite setting the rpc login values correctly
20:25:32 <sethsimmons> I’m not sure why you mentioned me I know nothing about that library.
20:25:44 <sethsimmons> You may want to reach out to the author if possible or in #monero
20:25:58 <sethsimmons> That is managed by a third party AFAIK and so isn’t likely to be a good topic for this room
20:26:15 <aubergine> ok thank you
20:26:34 <aubergine> monero should start to be more dev-friendly btw
20:26:57 <aubergine> tons of third party libraries outdated or poorly supported
20:27:11 <moneromooo> What could monero do about it ?
20:27:15 <sethsimmons> Monero is a decentralized community.
20:27:35 <sethsimmons> It’s up to the devs of the repos to keep it up to date or not, or newcomers to take them over as needed.
20:27:48 <sethsimmons> There’s no company or anything to be more dev-friendly.
20:28:03 <sethsimmons> Hundreds of devs work on Monero out of their own choice and seem to enjoy it!
20:28:19 <aubergine> redirect part of the funding from developing the core to the ecosystem
20:28:30 <Lyza> people can request funding for things
20:28:31 <gingeropolous> what funding?
20:28:31 <aubergine> otherwise monero will be a nice expensive toy that nobody can fully use
20:28:48 <Lyza> funding for doing work, I should say
20:29:02 <gingeropolous> looks like someone wants to open a ccs!
20:31:59 <sethsimmons> There is no central funding, aubergine. Each dev is funded individually if they request it and if the Monero community decides to donate to it.
20:32:17 <sethsimmons> I don’t think you understand how Monero works, this isn’t some corporate coin with vast treasuries siphoned from the block reward.
20:32:24 <sethsimmons> The community funds devs of their own free will.
20:32:39 <gingeropolous> and if u see a problem, fix it :)
20:32:42 <gingeropolous> if you can
20:32:57 <aubergine> I did, for free
20:33:29 <aubergine> but it is a tiresome process and with the older libs the maintainer is no longer interested in helping
20:34:02 <kinghat[m]> how can you tell an ecosystem how to operate if you dont understand how it operates?
20:34:28 <aubergine> sethsimmons I know, it's just apparently the community has been educated to support core development while neglecting the surrounding ecosystem
20:38:21 <sethsimmons> I don’t think we’re neglecting the surrounding ecosystem — if the dev wanted to be funded and showed why it was a good idea the community could fund continued development
20:38:32 <Lyza> folks just filled a huge CCS for an atomic swap implementation so I wouldn't say the ecosystem is being ignored. there's just, limited manpower. limited people who are both interested in and capable of the work. it'll change as the ecosystem grows but it is a bit of a chick and egg thing
20:38:42 <sethsimmons> Libraries are normally maintained by those using them for their own products — as more products get built on Monero more will be consistently maintained
20:41:52 <aubergine> it's like selling a car engine and expecting people to build around it
20:42:32 <scoobybejesus> dude, just talk to woodser
20:42:53 <selsta> last commit was 20 hours ago, what do you expect from "actively maintained"?
20:49:31 <binaryFate> New binaries (CLI and GUI) for v0.17.1.6 are available on getmonero.org
21:21:39 <kayabaNerve_> Aw :( aubergine already left. I was going to bring up the Rust and Python libraries
21:32:10 <sethsimmons> We may want to add a note to the release notes about needing to specify —restricted-rpc-bind-ip in order to keep exposing restricted rpc to non-localhost IPs
21:32:34 <sethsimmons> The default behavior changed and merely updating a node with —restricted-rpc-bind-port in use breaks outside accessibility.
21:35:38 <selsta> it should only be necessary if you have both restricted-rpc-bind-port and rpc-bind-port
21:36:35 <hyc> hm, it shouldn't have broken backward compay
21:36:38 <hyc> compat
21:39:28 <sethsimmons> <selsta "it should only be necessary if y"> This is my setup, so I guess that’s it — but that seems like the normal way users would operate with a distinct restricted port
21:39:36 <sethsimmons> gingeropolous noticed the same behavior
21:39:55 <sethsimmons> The new version drops restricted-rpc to localhost only unless you add the new flag and specificy IP/0.0.0.0
21:40:16 <selsta> yea, I did not have this setup so I did not notice it during testing
21:40:32 <selsta> I usually do restricted only with tmux
21:45:54 <hyc> ok, I see. the code in src/rpc/rpc_args.cpp sets config.restricted_bind_ip unconditionally; if the arg wasn't provided it defaults to localhost
21:46:12 <hyc> and it sounds like you would have expected it to default to <current rpc_bind_ip> instead
21:48:18 <selsta> I think current behaviour makes more sense, only issue is backwards compatibility.
21:48:50 <hyc> agreed
21:57:22 <sethsimmons> Yes the current behavior is safest and correct, just needs to be clear to those updating that they now have to specify that flag if they’re previously used the same config as me and many others.
21:57:57 <selsta> do you have a suggestion for the release notes?
22:00:06 <sethsimmons> Maybe something similar to this:
22:00:06 <sethsimmons> “A note for public RPC node operators upgrading to v0.17.1.6 — if you’re using the —restricted-rpc-bind-port option along with —rpc-bind-ip currently you will need to add the new —restricted-rpc-bind-ip arg or else the daemon will bind restricted RPC only to localhost.”
22:07:56 <needmoney90> deb
22:07:58 <needmoney90> oops
22:08:10 <needmoney90> debruyne can we repin?
22:08:15 <needmoney90> and add that note
22:12:22 <selsta> sethsimmons: ok will make sure to add it to release notes
22:14:19 <hyc> sounds good
22:15:51 <Inge-> did BTC see similar kinds of shenanigans they had to harden against?
22:27:06 <sethsimmons> Not that I’ve ever heard of but I would love to know more if so.
22:30:48 <selsta> BTC does not have privacy to begin with so a lot of the attacks don't apply
22:31:53 <selsta> there is software to sybil attack BTC
22:32:48 <selsta> would be interesting to know how bitcoin handles target height
22:33:15 <Inge-> I know it has some logic to ban misbehaving nodes
22:33:33 <Inge-> anyway, good job on being light-footed in getting mitigations in.
22:36:48 <dEBRUYNE> needmoney90: Can just edit the post?
22:37:19 <needmoney90> considering the title is > v0.17.1.5 as soon as possible and the latest version is 17.1.6
22:37:31 <needmoney90> we prolly need a new title to avoid confusion
22:37:35 <needmoney90> and reddit does not allow editing that
22:38:27 <needmoney90> debruyne
22:39:03 <needmoney90> I'm speaking specifically about our current pin #2
22:39:07 <needmoney90> not seth's post
22:44:08 <rehrar> dEBRUYNE selsta if we think that this has all of the mitigations that are necessary, perhaps it might have been best to make it 17.2 so it seems like a very important thing to update to rather than just a .6
22:44:40 <selsta> Ledger version locks their software
22:44:57 <rehrar> as a whole the third digit isn't used as much as it could be
22:45:10 <moneromooo> Unlikely it's the last of it.
22:45:11 <selsta> then we would have to reach out to Ledger again, tell all users to update the Ledger monero app and it always results in huge amount of support threads
22:46:07 <needmoney90> Yeah but if that happens selsta will deal with it and I dont have to think about it 👀
22:46:18 <rehrar> something I've discussed with selsta before that maybe I can get some other opinions on, is the Whonix guy who's doing packaging for us recommends some sort or ESR for Monero, but it doesn't seem that this is feasible for us right?
22:46:29 <selsta> no it is not feasible
22:46:38 <selsta> IMO
22:46:44 <needmoney90> ESR?
22:46:50 <rehrar> extended support release
22:47:02 <needmoney90> ah. Give it two years.
22:47:15 <selsta> We already mostly only add bug fixes in point releases
22:48:10 <rehrar> I totally understand that nothing about the past few months of releases was typical.
22:49:55 <selsta> Afaik even bitcoin does not have ESR / LTS releases and bitcoin is way more stable
22:57:26 <selsta> luigi1111w:  can you add "A note for public RPC node operators upgrading to v0.17.1.6 - if you’re using the --restricted-rpc-bind-port option along with --rpc-bind-ip currently you will need to add the new --restricted-rpc-bind-ip arg or else the daemon will bind restricted RPC only to localhost." to CLI release notes? similar to https://github.com/monero-project/monero-site/pull/1363
23:01:21 <luigi1111w> like that?
23:03:01 <selsta> yes, thanks
23:04:10 <dEBRUYNE> <needmoney90> I'm speaking specifically about our current pin #2 <= Oh I see
23:04:13 <dEBRUYNE> We can depin that I guess
23:04:34 <selsta> luigi1111w: also please also update hashes.txt.sig sometime later, not urgent
23:50:01 <moneromooo> Fingerprinting.
23:50:09 <lza_menace> seems like it would be useful to be available to crawl the network and determine what versions nodes are
23:54:57 <lza_menace> anywho - thanks contributors, great work on the attack mitigations