<selsta> "hyc: did the gitian process..." <- I confirm that the build is broken at the same moment, namely during submodule synch. I'll fix and PR it very soon.

Don't think we changed anything submodule related, weird

`Submodule 'external/miniupnp' is not up-to-date.`

aight. It's rollin'.

hyc: maybe for you?

mj-xmr[m]: still don't understand why this didn't show up last time, the submodule change was 8 months ago

Suspicious it is.

Anyway, I'll test if the build works, which will take some time, and in parallel we may investigate the submodule.

Perhaps we have something in common with hyc: I remember not being able to take part in the last Rep. Builds party. This could mean, that my existing checked out clone was outdated by more than 8 months.

that could be it

So I was dealing with the leftovers.

and for the record: the git clone doesn't overwrite the existing clone.

hmmm.. I'm not yet sure if my PR fixes the problem, because the gitian insists on rebuilding the depends. Let's give it some time.

So the current status is that I'm compiling the 3rd `dependency` so far, but not Monero yet. I could imagine, that running `make depends` would fail, if there were submodules missing

OK. It didn't work. Still trying.

Anyone know if Xiphon is alive? i've sent a reddit msg (his last post was 1 year ago)

selsta: I nailed the problem and updated the PR. Now testing for FreeBSD only, to speed up the whole process.

<plowsof[m]> "Anyone know if Xiphon is alive..." <- And the last Github contribution is in last May:

If this is a break, then quite a long one.

thnx, sorry for offtopic msg 👍️

It didn't work. I had to fork and patch the gbuild. Testing now.

Still need gitian builds of release-v0.17, selsta?

Just fired one up from scratch

I have one solution that works. I'll update the PR

Then I'll open another, alteternative solution

sethforprivacy[m]: It wouldn't hurt to check if it breaks at your end and if my fix afterwards is of any help

For simplicity I advice to add the `--os f` flag to the gitian-build.py

This will omit so many OSes if it's to fail.

sethforprivacy[m]: if it doesn't work pristine, then the following version should:

<plowsof[m]> "thnx, sorry for offtopic msg 👍️" <- You shall live...

<mj-xmr[m]> "Then I'll open another, altetern..." <- Nah... the alternative solution won't work. Actually I checked it earlier, without realizing.

in my case the bad submodule was because I was building from an unclean tree

It is still a valid use case.

the gitian process already does a submodule update --init --force, it wasn't fixing it here because it was updating to my stale tree

once I did a git reset --hard everything built to completion

so I got a clean build of release-v0.17 on all platforms.

afaics gitian-build.py is fine as-is.

who is this web-sharp clown

"hey, nobody knows me but here's official Mac M1 binaries" wtf

It would appear that jeffro256[m] knows :)

OK. FreeBSD as a small test sample finished here.

mine paste.debian.net/1239088

oh, it's got outputs from a previous build of the branch. the -424e4d16 is the current rev

My FreeBSD, which is the same:

hyc: ok, so all platforms compiled?

yes

guess then we can tag

luigi1111w: ^^

v0.17.3.2

Building v0.17.3.2 reproducible binaries now

sethforprivacy: we didn't tag yet

I see a tag 🤔

hmm ok maybe luigi is too fast

w0w ok

haha

Just got a notification 😄

10 minutes ago.

sethforprivacy[m]: Same :)

Mine will take a while, for some reason setting number of threads keeps crashing my comps lol, RAM usage I think

But will share once I have them.

sethforprivacy[m]: You have to assume 2.5 GB RAM per core.

> <@mj-xmr[m]:libera.chat> > <@sethforprivacy[m]:libera.chat> Mine will take a while, for some reason setting number of threads keeps crashing my comps lol, RAM usage I think

>

> You have to assume 2.5 GB RAM per core.

Ahhh, thought it was 2GB

> <@sethforprivacy[m]:libera.chat> > <@mj-xmr[m]:libera.chat> > <@sethforprivacy[m]:libera.chat> Mine will take a while, for some reason setting number of threads keeps crashing my comps lol, RAM usage I think... (full message at libera.ems.host/_matrix/media/r0/do…171292f14ca03157e55308d62d4e6437285)

Nice

That Gitian howto was written before I made these statistics.

sethforprivacy[m]: What I like is that the memory requirements decrease even though we add functionality.

selsta: should i update my pr from `17.3.0` to `17.3.2`?

mj-xmr[m] I have no idea who he is lol idk why he listens to me

I'm respectful to anybody until I have to strike :)

hinto[m]: yes

mine: paste.debian.net/1239129

and mine. matches up paste.debian.net/1239130

mj-xmr[m] Can you see my comments on monero-project/monero #8264?

I'm just gonna readd it

Build results: paste.sethforprivacy.com/?0f325e609…8eQNSmdMQMgDAbM83K1PCN8EhjaK4237rX1

All match 🙂 PRing now.

OK so I typed "sign" and it just said "Not signing, bye" -- is there a way I can sign/publish without rebuilding?

hyc mj-xmr[m] selsta (Using the dockrun.md approach)

sethforprivacy: try typing something else

it already exited out

Of the script

dockrun.sh doesn't seem to have a "just sign built binaries" option, either

can you copy out the signatures and binaries?

Suppose so, just a bit of a PITA from the containers

Will figure it out and PR in a bit ☹️

docker cp gitrun:/home/ubuntu/out/v0.17.3.0 out

that's what it says for the binaries

Yeah just saw the nice command 😄

Thanks

I really should read to the end

This look OK? monero-project/gitian.sigs #180

Haven't had to do it manually in a long time

Seems good! github.com/monero-project/gitian.si…s/6185173763?check_suite_focus=true