<kayabanerve[m]> "If there's any Rust developers..." <- I could post a community message on monero.observer for more exposure, pm me with a headline/message if you think that would help.

> <@escapethe3ra[m]:libera.chat> > <@kayabanerve[m]:libera.chat> If there's any Rust developers interested in picking up a Monero ecosystem project as their work over the next few months, let me know on matrix (this account).

>

> I could post a community message on monero.observer for more exposure, pm me with a headline/message if you think that would help.

Thanks for the offer. I may take you up on that in a week or so when I'm a bit more organized :)

<woodser[m]> "please do enable logging in..." <- ok I will do this when i'm back from school

.merges

selsta done

oki ty gui too

will wait a bit before tag

Reproducible Builds Party tonight then?

pinging monerobull

I need someone to test if reproducible builds build fine for release-v0.17 branch

that's why I didn't want to tag yet

Oh god

<plowsof[m]> "pinging monerobull..." <- I don't know if 6 months has been enough for me to recover from last time

Didn't even get merged in the end 😪

Hey we're on Boost 1.64 right ? I know the README says 1.58, but shouldn't we be be past 1.62 b/c of the openSSL linking problem? I keep seeing people mention that we're on 1.64

Did you git log and grep for [bB]oost ?

I just did, I see a 1.58 fix about a year ago, no mention of bumps after that. You'll have to try it if you want to know.

Thanks that's what I thought, I just wanted someone to confirm b/c I saw a conflicting statement in some PR discussion

1.58 I mean, there's a bunch of other compatibility commits but the req seems to be at 1.58

Maybe they were talking about compat with 1.64? Anyways nevermind me

It's very possible someone pushed some code which broke 1.58 in the last year. That happened before.

Noticed this when building the latest 0.17:... (full message at libera.ems.host/_matrix/media/r0/do…74870f8b2f897f00e16ad3805a0f7ce1c0e)

<selsta> "I need someone to test if..." <- I'll try

cryptogrampy I see why the compiler is complaining about that, but which compiler are you using?

I'm using Seth's Alpine Docker build (edited slightly to use the latest 0.17 branch): github.com/sethforprivacy/simple-monerod-docker/blob/main/Dockerfile

I can kick off a build here

Also:... (full message at libera.ems.host/_matrix/media/r0/do…664d8dfb77b6ab18f144e4b72a77d049e98)

blows up fairly early on

hm, it's missing a git submodule update

cryptogrampy[m]: these are just warnings

i mean it would be good to fix them but not important for the release build bow

now*

Okay thanks! I see red text and i get flashbacks to the great war. I don't usually pay much attention to the build :)

jeffro256[m]: as far as I know we still support 1.58

though I wouldn't have a problem with bumping the min version at this point if it simplifies things

selsta: We "support" but remember when I was trying to improve the configuration combination coverage on the CI and I figured out that 1.58 didn't work anymore on Ubuntu 20.04?

yes but it still worked on older Ubuntu versions

That's true.

We decided to stay with supporting 1.58 and shutting one eye on the SSL.

But maybe even they upgraded the OpenSSL version in meantime?

Ubuntu 18.04 ships with 1.65, so that would be a suitable min version.

I think that was my argument back then.

selsta: ^

not sure what you mean :D

I meant setting 1.65 as the min version in CMake and removing all code that was for backwards compatibility. Your PR is about CI.

These links don't reflect the whole discussion, that I admit is in my memory only now, but I recall that somebody (probably you) told specifically, that even though Ubuntu 18 shipped Boost 1.62 as the minimum back then, and I told that we should make 1.62 as the official minimum, the official minimum (in README.md) should remain the outdated 1.58, which is now bringing confusion.

I mean: I don't care, but 1.58 should go completely off the discussion, is what I mean.

Anyway, I'm updating my Ubuntu 18 VM and will be ready for some build testing soon.

The minimum should be what we can make it build with without too much trouble, rather than what your prefered distro uses.

s/build/work/

"too much trouble" being defined as "whatever effort someone does to make it support it", which means it varies with time :)

There is an advantage to people to not being too much of an asshole with keeping old version compat: it allows the software to build with a wider range of lib versions, which removes a constraint when someone has a set of libs and is trying to build various software, each of which has their own restrictions.

So the fewer restrictions we add (within limits of reasonable hassle for us to maintain) means we don't piss of people trying to make various software coexist.

Granted, most people nowadays use prebuilt distros so this issue is lesser and lesser.

But, IMHO, if it doesn't cost you much, keeping compat with old versions is good.

Bumping min requirement because some distro uses a newer one is being a bit of a jerk.

1.58 is from Apr 2015, I guess now that we already have support for it we don't have to remove it, but we could remove some ifdefs and CMake compatibility code when setting the minimum to something more recent.

I used Ubuntu 18.04 as an example because it's the last Ubuntu version that isn't end of life.

but it's not that important, I only thought about now because jeffro256[m] brought it up

<moneromooo> "Bumping min requirement because..." <- I follow. My other software still works under Windows XP.

It's just that here the outdated Boost pulls the outdated SSL with security issues. I'm not sure if it's being so much of a jerk by enforcing users to avoid security issues, whose existence they even don't know about.

forking the ccs proposal git repo doesnt seem to work for some reason

if i remember correctly, you can't fork it if you have a gitlab account? i vaguely remember needing to sign in with my github account

but i did that

guess i wont do it then

Regarding the functionality of the sweep_all comand. How to minimize the privacy leaks while using this comand? What options and parameters to use to minimize the privacy leaks when sweep_all even at the cost of hither fees?

If there is a good reason, surely it is good :)

monerobull[m]: what is your account name there ?

GuruJi[m]: if you do not have many outputs, maybe sweep_single a few times ?

Otherwise, I don't think you can do anything in particular if you want to use sweep_all.

I made a new gitlab account and forked it keeping everything default and it worked

<moneromooo> "Otherwise, I don't think you can..." <- So if I use just sweep_all address, it is enough? No need to set any other parameters to prevent compromise the privacy?

<selsta> "I need someone to test if..." <- Building so far. I'll have more to say in about 8 hours from now.

i dont care that its ugly, rehrar to 36C3 got funded too :P repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/315

Yes. Though, again, sweep_single of your inputs first could help with privacy. How much this'd help is hard to quantify.

hyc: did the gitian process finish?

Polite notice of a not yet confirmed community meeting perhaps this Sunday. If there is something important on your mind you'd like to share with the community let me know (ccs updates... how the hard fork effects your work perhaps) monero-project/meta #695