So we're breaking tradition and not re-tagging? Nice. :P Mine appear to be the same: paste.debian.net/1159128

first time for everything

is there anyone that reads and writes Chinese?

@realsexycyborg :P

there is also the monerocn TG group

lol

re-tagging ? Did the .3 replace an existing tag ?

my hashes also match paste.debian.net/1159169

I don't think it did. There is no .2 in my gitian out dir.

Good :)

TheCharl1: are you TheCharlatan ?

If so, mind commenting on monero-project/monero #6337, the last tweak to which removes an addition you made to fix cross compilation ?

It apparently breaks something for vtnerd.

my hashes also match paste.debian.net/hidden/8877b892

I'll kick off my build now

I'll stop mining for a bit 🥲

I think I had to ask this before and have forgotten the fix -- running into an isssue getting packages for the gitian build: `Unable to connect to 172.17.0.1:3142`

wasn’t it firewall related?

IIRC, it was the firewall last time.

ah I'll double check

yup fixed with `sudo ufw allow 3142/tcp`

Forgot I rebuilt fw since the last tagged release

Thanks!

monero-project/monero #6745 is the unlock time change I'd like to have for the fork.

ok

soo CLSAG + this need a review

moneromooo: would you also like monero-project/monero #6616 ?

If it gets reviewed, sure.

It's not a must have though.

.merges

Looks like the bot's a bit shot. 6536/6538 are both merged already

As is 6565

Snipa: Could you issue a .merges once more?

.merges

I've just merged 6571 and 6418

yep okay, thanks

Linux hashes match for gitian builds

Do we want a Reddit thread for the hashes/gitian for this tag?

I can create it cloning an old one if someone can tell me the main features/fixes in 16.0.3

DoS fixes.

Thanks

Is there a specific PR I can link to for that moneromooo

6728

Great, thanks.

6536

Was that a response to me caralho

nope, sry. Testing something out

ah ok, thanks :)

xmr-pr got rate limited by github, the bot will return later today

I've put him in the naughty corner.

Android/FreeBSD also match so far

Ran into an error building windows: paste.centos.org/view/1a15e3e7

Looks like OOM killer.

How many cores and how much memory?

Could anyone who wants to confirm the hashes for v0.16.0.3 CLI please commit to the gitian repo?

I build with -j5 and m12000.

16c/32t

Did -j32

lol

Should I change to -j16?

sethsimmons: how much ram have you got?

32G

But Monerod and a few other things are running and eating some RAM

-j24 works for me with 32g

I'll try with that

I've built fine with -j32 in the past

But might be hitting a cap slightly now

i think that the problem is just with linking. the llvm cmake scripts let you limit the max number of link jobs running at once. not sure how it works but maybe we can steal it? :D

or tell make that some of the bigger files need to be run alone

No idea how to change those

Restarting all builds with -j16 instead

wish me luck

You don't have to build everything from the start.

Just add -owm if Win and Mac builds are the only ones left.

How do I skip certain builds/only run Windows?

Comment out other platforms from gitian-build.py?

No

Insert -ow in your command if you only want to build for Windows.

-owm for windows and mac?

Mac had yet to run

Yes

nice that worked, thanks

any recommendations for the `--memory` flag?

Set it to 12000 at some point but could probably be refined

ThreadRipper 1950X 16c/32t w/ 32GB RAM

Use as much as you can spare, I guess.

I use -m12000 as I can spare ~12GB out of 16 GB on that machine.

sweet, thanks.

I never specify the memory flag

just lt it use as much as there is

of course, my laptop has 32GB RAM and 8 cores. 4GB per build thread is enough, so far

we really need to reign in all this header file madness

Someone did show up a couple months ago promising large gains in that area.

all those templates in the epee networking code are just totally unnecessary

There was a CCS for it.

yeah, I remember seeing that

I suspect it was overeager promises but decided to waut and see :)

frankly it galls me to see people come in out of nowhere and demand money before they pitch in and help

they should just stick to working for commercial software companies if that's their attitude

they did some contributions FWIW

ccache stuff

That's a weird one. I've been using ccache for years without any change.

I don't see anywhere ccache can help in this project

My sanity.

if you touch a header file and force a recompile, that's unavoidable

if you don't touch any header files, make already does the minimal required work

It still helps a lot. Changing defines for example. ccache also caches preprocessed source.

ccache is just superfluous. even more ludicrous, it's part of the gitian builds

And when you rebase and change branches. Oh boy does it help.

even though gitian spins up a fresh docker image for every build

thats hyperbole

there is nothing cacheable/reusable

It's definitely not superfluous. I love ccache ^_^

for gitian, it's useless. completely.

Well, if is in a fresh fs, sure. But that doens't mean it's superfluous. Just superflous in this partiuclar case.

But it's mostly irrelevant since it can be used without anything changing in monero anyway.

If I didn't have ccache, I'd probably have loads of "fixup this shit" commits :/

that would improve the codebase

:|

time for you to drop ccache from yout path for a while :P

I meant I would not squash them into the relevant earlier commit.

ohh

I thought you meant you would stop and fix all the annoying slowdowns as you encounter them

Ah. Well, I did that too a year or two back.

The dude who did hte ccache patch seemed to have more experience than me with this though.

I don't change branches much these days. I just have multiple worktrees from a single repo, one for each branch I'm working on

People who help with reproducible builds: please make a PR to the gitian repo. It provides a hash *signed* with your key (unlike confirming on IRC or reddit). And gives public auditability of the hashes confirmations.

I don't have PGP setup... Need to do that first.

(and makes monero-update see and use it)

It's ok to post hashes on IRC/reddit only (without signed PR), but I cannot rely only on that. That is not what users will expect me to have checked.

I need enough people to make the effort to PR to gitian, which provides PGP-signed vetting from them (not just their IRC account saying something) and auditability in the future on why I decided that sign off on certain hashes.

*to

I'll work on getting mine setup over the next couple of days when I have time.

Thanks for the push.

Right now I'm asked to sign something because selsta plus 3 people on IRC confirmed it. Apart from a small epsilon, it's basically the same as trusting selsta only. IRC is not PGP.

seems legit

added my sigs monero-project/gitian.sigs #61

Another set of sigs from a person on IRC is up.

.merges

bit late again with my build, but will have sigs up soon and then merge.

TheCharlatan: did you see moos message?

The one asking if me is me?

TheCharlatan: also FYI: monero-project/monero #6745

Yes.

14:17 <+moneromooo> If so, mind commenting on monero-project/monero #6337, the last tweak to which removes an addition you made to fix cross compilation ?

Btw, I tested with set(CMAKE_SYSTEM_PROCESSOR ${CMAKE_HOST_SYSTEM_PROCESSOR} CACHE STRING "" FORCE) today.

moneromooo do you mean the patch that iDunk commented?

Yes, I did.

moneromooo: I think you were talking about monero-project/monero #6337/files#diff-657e89b8cdcca8c4852e0f983b61ec17L66

not iDunk’s patch

Ah, I see

<hyc> added my sigs monero-project/gitian.sigs #61 <-- thanks hyc and iDunk

I meant the line vtnerd removed, but iDunk found a way to fix it since then.

Windows builds would not use supercop code anyway, with that (UNIX AND...) bit.

The benchmark with supercop code segfaults on Windows, from either MSYS2 or depends builds.