00:20:02 <escapethe3ra[m]> <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.
02:53:43 <kayabanerve[m]> > <@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).
02:53:43 <kayabanerve[m]> > 
02:53:43 <kayabanerve[m]> > I could post a community message on monero.observer for more exposure, pm me with a headline/message if you think that would help.
02:53:43 <kayabanerve[m]> Thanks for the offer. I may take you up on that in a week or so when I'm a bit more organized :)
08:03:45 <ian_niculescu[m]> <woodser[m]> "please do enable logging in..." <- ok I will do this when i'm back from school
14:38:30 <luigi1112> .merges
14:38:30 -xmr-pr- 8178 8248 8249 8260 8273 8275 8276
15:22:48 <luigi1112> selsta done
15:23:06 <selsta> oki ty gui too
15:23:40 <selsta> will wait a bit before tag
15:39:21 <mj-xmr[m]> Reproducible Builds Party tonight then?
15:40:20 <plowsof[m]> pinging monerobull 
15:52:01 <selsta> I need someone to test if reproducible builds build fine for release-v0.17 branch
15:52:09 <selsta> that's why I didn't want to tag yet
15:58:35 <monerobull[m]> Oh god
15:59:46 <monerobull[m]> <plowsof[m]> "pinging monerobull..." <- I don't know if 6 months has been enough for me to recover from last time
16:00:15 <monerobull[m]> Didn't even get merged in the end 😪
16:07:02 <jeffro256[m]> 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
16:30:25 <moneromooo> Did you git log and grep for [bB]oost ?
16:32:05 <moneromooo> 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.
16:36:57 <jeffro256[m]> Thanks that's what I thought, I just wanted someone to confirm b/c I saw a conflicting statement in some PR discussion
16:37:58 <jeffro256[m]> 1.58 I mean, there's a bunch of other compatibility commits but the req seems to be at 1.58
16:38:30 <jeffro256[m]> Maybe they were talking about compat with 1.64? Anyways nevermind me
16:39:28 <moneromooo> It's very possible someone pushed some code which broke 1.58 in the last year. That happened before.
16:41:59 <cryptogrampy[m]> Noticed this when building the latest 0.17:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/95be974870f8b2f897f00e16ad3805a0f7ce1c0e)
16:43:27 <mj-xmr[m]> <selsta> "I need someone to test if..." <- I'll try
16:52:38 <jeffro256[m]> cryptogrampy I see why the compiler is complaining about that, but which compiler are you using?
16:57:19 <cryptogrampy[m]> I'm using Seth's Alpine Docker build (edited slightly to use the latest 0.17 branch): https://github.com/sethforprivacy/simple-monerod-docker/blob/main/Dockerfile
16:57:52 <hyc> I can kick off a build here
16:58:28 <cryptogrampy[m]> Also:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/07f07664d8dfb77b6ab18f144e4b72a77d049e98)
17:01:12 <hyc> blows up fairly early on
17:03:04 <hyc> hm, it's missing a git submodule update
17:08:43 <selsta> cryptogrampy[m]: these are just warnings
17:09:10 <selsta> i mean it would be good to fix them but not important for the release build bow
17:09:12 <selsta> now*
17:09:31 <cryptogrampy[m]> Okay thanks!  I see red text and i get flashbacks to the great war.  I don't usually pay much attention to the build :) 
17:09:47 <selsta> jeffro256[m]: as far as I know we still support 1.58
17:10:18 <selsta> though I wouldn't have a problem with bumping the min version at this point if it simplifies things
17:11:17 <mj-xmr[m]> 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?
17:11:53 <selsta> yes but it still worked on older Ubuntu versions
17:12:08 <mj-xmr[m]> That's true.
17:12:08 <mj-xmr[m]> We decided to stay with supporting 1.58 and shutting one eye on the SSL.
17:12:28 <mj-xmr[m]> But maybe even they upgraded the OpenSSL version in meantime?
17:14:10 <selsta> Ubuntu 18.04 ships with 1.65, so that would be a suitable min version.
17:34:15 <mj-xmr[m]> I think that was my argument back then.
17:35:43 <mj-xmr[m]> https://github.com/monero-project/monero/pull/7768/files#diff-5c3fa597431eda03ac3339ae6bf7f05e1a50d6fc7333679ec38e21b337cb6721R198
17:35:49 <mj-xmr[m]> selsta:  ^
17:36:55 <mj-xmr[m]> https://github.com/monero-project/monero/pull/7768#issuecomment-873441298
17:38:40 <selsta> not sure what you mean :D
17:39:29 <selsta> 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.
17:42:25 <mj-xmr[m]> 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.
17:42:25 <mj-xmr[m]> I mean: I don't care, but 1.58 should go completely off the discussion, is what I mean.
17:43:40 <mj-xmr[m]> Anyway, I'm updating my Ubuntu 18 VM and will be ready for some build testing soon.
17:49:19 <moneromooo> The minimum should be what we can make it build with without too much trouble, rather than what your prefered distro uses.
17:49:48 <moneromooo> s/build/work/
17:50:36 <moneromooo> "too much trouble" being defined as "whatever effort someone does to make it support it", which means it varies with time :)
17:52:04 <moneromooo> 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.
17:52:39 <moneromooo> 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.
17:53:09 <moneromooo> Granted, most people nowadays use prebuilt distros so this issue is lesser and lesser.
17:53:37 <moneromooo> But, IMHO, if it doesn't cost you much, keeping compat with old versions is good.
17:54:12 <moneromooo> Bumping min requirement because some distro uses a newer one is being a bit of a jerk.
17:54:20 <selsta> 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.
17:54:42 <selsta> I used Ubuntu 18.04 as an example because it's the last Ubuntu version that isn't end of life.
17:54:58 <selsta> but it's not that important, I only thought about now because jeffro256[m] brought it up
18:32:44 <mj-xmr[m]> <moneromooo> "Bumping min requirement because..." <- I follow. My other software still works under Windows XP.
18:32:44 <mj-xmr[m]> 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.
19:46:09 <monerobull[m]> forking the ccs proposal git repo doesnt seem to work for some reason
19:48:31 <plowsof[m]> 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 
19:49:47 <monerobull[m]> but i did that
19:51:44 <monerobull[m]> guess i wont do it then
19:57:41 <GuruJi[m]> 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? 
20:11:03 <moneromooo> If there is a good reason, surely it is good :)
20:11:13 <moneromooo> monerobull[m]: what is your account name there ?
20:11:47 <moneromooo> GuruJi[m]: if you do not have many outputs, maybe sweep_single a few times ?
20:12:12 <moneromooo> Otherwise, I don't think you can do anything in particular if you want to use sweep_all.
20:12:13 <monerobull[m]> I made a new gitlab account and forked it keeping everything default and it worked
20:19:11 <GuruJi[m]> <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? 
20:31:39 <mj-xmr[m]> <selsta> "I need someone to test if..." <- Building so far. I'll have more to say in about 8 hours from now.
20:32:56 <monerobull[m]> i dont care that its ugly, rehrar to 36C3 got funded too :P https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/315
20:33:40 <moneromooo> Yes. Though, again, sweep_single of your inputs first could help with privacy. How much this'd help is hard to quantify.
23:25:00 <selsta> hyc: did the gitian process  finish?
23:50:03 <plowsof[m]> 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) https://github.com/monero-project/meta/issues/695