travis says "You have used 11370 of 10000 credits"

I turned off the setting to use credits for OSS projects but it doesn't seem to do anything

looks like we have to manually request more credits

that’s annoying

"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."

looks like Travis stopped supporting OSS completely news.ycombinator.com/item?id=25338983

Well, that's annoying.

selsta, what is this?

credit allocation?

what are credits in this context?

CI for testing development builds (e.g. does it compile?)

isn't it best to compile on real hardware anyway?

surely someone has a spare laptop that can be used

Travis CI runs on every merge, and runs on "real" hardware for all that "real" matters in the CI processes with replicable builds.

it runs on every PR and every merge

Up until now, they happened to support OSS pretty well, so easier than relying on someone to have 24/7 abilable hardware.

yep

I see

so now what?

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.

GH Actions for depends targets ?

Should not be too difficult to port to GH Actions, but we will end up with a lot of jobs per PR.

CircleCI looks nice too

GH Actions + caching will be fine

will look into porting it

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.

20 concurrent builds

nice, should be plenty.

mining and p2p functional tests still occasionally fail, and I was not able to figure out which timeout to bump yet

(on CI)

AssertionError: Failed to mine successor to block 13 (initial block = 11)

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.

No sane one anyway :)

Oh, or bump all timeouts to silly values, but test every couple seconds whether we're in the state we want.

That's better.

morning y'all

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

hashes seem to match though

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?

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

that's weird

7zip is pretty robust

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"

Why lie about something that can be easily disproven?

Why steal from your community and then laugh at them?

Reason is the same - to laugh at morons that are gullible enough to believe you and repeat your lies.

update: I am dumb

like 4 of the files got corrupted copying them over to the Windows machine somehow, everything is good now

Thats the struggle — report something that could be serious and just turns out to be bad luck 😅

hi

is monero nodejs library still maintained?

?

much less cpu load in 17.1.6. thanks devs

<gingeropolous "much less cpu load in 17.1.6. th"> Oh, really? Any specific idea why?

Dropping some cunt's spam.

i saw some conversation about a race condition. and what mooo said

its a technical term

Ah the spam reduction, didn’t even think about the effect that will have on load and bandwidth

sethsimmons I always get 401 error upon connection

despite setting the rpc login values correctly

I’m not sure why you mentioned me I know nothing about that library.

You may want to reach out to the author if possible or in #monero

That is managed by a third party AFAIK and so isn’t likely to be a good topic for this room

ok thank you

monero should start to be more dev-friendly btw

tons of third party libraries outdated or poorly supported

What could monero do about it ?

Monero is a decentralized community.

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.

There’s no company or anything to be more dev-friendly.

Hundreds of devs work on Monero out of their own choice and seem to enjoy it!

redirect part of the funding from developing the core to the ecosystem

people can request funding for things

what funding?

otherwise monero will be a nice expensive toy that nobody can fully use

funding for doing work, I should say

looks like someone wants to open a ccs!

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.

I don’t think you understand how Monero works, this isn’t some corporate coin with vast treasuries siphoned from the block reward.

The community funds devs of their own free will.

and if u see a problem, fix it :)

if you can

I did, for free

but it is a tiresome process and with the older libs the maintainer is no longer interested in helping

how can you tell an ecosystem how to operate if you dont understand how it operates?

sethsimmons I know, it's just apparently the community has been educated to support core development while neglecting the surrounding ecosystem

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

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

Libraries are normally maintained by those using them for their own products — as more products get built on Monero more will be consistently maintained

it's like selling a car engine and expecting people to build around it

dude, just talk to woodser

last commit was 20 hours ago, what do you expect from "actively maintained"?

New binaries (CLI and GUI) for v0.17.1.6 are available on getmonero.org

Aw :( aubergine already left. I was going to bring up the Rust and Python libraries

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

The default behavior changed and merely updating a node with —restricted-rpc-bind-port in use breaks outside accessibility.

it should only be necessary if you have both restricted-rpc-bind-port and rpc-bind-port

hm, it shouldn't have broken backward compay

compat

<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

gingeropolous noticed the same behavior

The new version drops restricted-rpc to localhost only unless you add the new flag and specificy IP/0.0.0.0

yea, I did not have this setup so I did not notice it during testing

I usually do restricted only with tmux

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

and it sounds like you would have expected it to default to <current rpc_bind_ip> instead

I think current behaviour makes more sense, only issue is backwards compatibility.

agreed

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.

do you have a suggestion for the release notes?

Maybe something similar to this:

“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.”

deb

oops

debruyne can we repin?

and add that note

sethsimmons: ok will make sure to add it to release notes

sounds good

did BTC see similar kinds of shenanigans they had to harden against?

Not that I’ve ever heard of but I would love to know more if so.

BTC does not have privacy to begin with so a lot of the attacks don't apply

there is software to sybil attack BTC

would be interesting to know how bitcoin handles target height

I know it has some logic to ban misbehaving nodes

anyway, good job on being light-footed in getting mitigations in.

needmoney90: Can just edit the post?

considering the title is > v0.17.1.5 as soon as possible and the latest version is 17.1.6

we prolly need a new title to avoid confusion

and reddit does not allow editing that

debruyne

I'm speaking specifically about our current pin #2

not seth's post

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

Ledger version locks their software

as a whole the third digit isn't used as much as it could be

Unlikely it's the last of it.

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

Yeah but if that happens selsta will deal with it and I dont have to think about it 👀

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?

no it is not feasible

IMO

ESR?

extended support release

ah. Give it two years.

We already mostly only add bug fixes in point releases

I totally understand that nothing about the past few months of releases was typical.

Afaik even bitcoin does not have ESR / LTS releases and bitcoin is way more stable

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 monero-project/monero-site #1363

like that?

yes, thanks

<needmoney90> I'm speaking specifically about our current pin #2 <= Oh I see

We can depin that I guess

luigi1111w: also please also update hashes.txt.sig sometime later, not urgent

Fingerprinting.

seems like it would be useful to be available to crawl the network and determine what versions nodes are

anywho - thanks contributors, great work on the attack mitigations