pls no

I get 3f2ea03affdc75ccccbee148d03af9ad92da4af012c91a84a447863aa48f5b36 here.

ok got the same message

db55aa2ac8c7b8d8f9e471c09b0d3b7214360e24e94558f120124a1b3d84b336 osslsigncode-1.7.1.tar.gz

bitcoin uses osslsigncode 2.0 github.com/bitcoin/bitcoin/blob/master/contrib/gitian-build.py

It's a different SHA256 hash on every run here.

why is tor gateway +q here?

It's not a tar.gz archive, it's a web page.

I'm currently testing with the 2.0 version

elFado: spam, though should get removed again

somethingUniqueR: kastelo was a scam afaik

why do we even use osslsigncode, we don't sign our .exe

guess we can just delete that from gitian-build.py

iDunk: I'm building now with line 97-100 removed

would it be fine if everyone does that for this release or should we tag v0.17.2.1?

removing line 97-100 does not change the resulting hashes so should be fine without retagging

built 0.17.2.0 on fedora with cmake -DMANUAL_SUBMODULES=1; make

regular make fails with Submodule 'external/miniupnp' is not up-to-date.

FYI

git submodule sync

git submodule update

ok those two seem to do the track after git checkout release-v0.17

trick

github lists boost dependency as 1.58 - has that changed? now i see:

monero/tests/unit_tests/node_server.cpp:355:21: error: max_listen_connections is not a member of boost::asio::socket_base

i have boost 1.60

(i didn't see that error when i did cmake -DMANUAL_SUBMODULES=1

that is in unit tests

which afaik do not get build if you execute cmake manually

ah ok

guess that is something we should fix

so that minimum dependency is 1.58 again

i also tried to build with a private openssl 1.1.1k library and got a lot

of boost related ssl issues

tomorrow i'll try with a newer boost

thanks

iDunk: paste.debian.net/hidden/502c34a4

two don't match so far :/

did you do apt-get update and apt-get upgrade? we had issues with a gcc update once

That host is always up to date.

android hashes match again

FUK has bееn intеnsеly hostilе to Monеro for ovеr 4 yеars. Making minеrs for Monеro, making a pool for Monеro, making codе that Monеro copiеd, not using bugs to stеal millions from еxchangеs. Wow. Such grеat hostility.

selsta, may you point me to some info how to make such a reproducible build? I already was able to create a couple of "depends"

or iDunk

./contrib/gitian/gitian-build.py ?

buenas tardes a todos

hola

mj-xmr: there's a README.md with instructions in contrib/gitian

Thanks

just a heads up re: boost. I see on Actions, that "Perfect-daemon" is building a fix for the Boost 1.58

hmm it is already PRed I think

Should I reproduce 0.17.2.0 or wait?

Want to be sure before I kick it off.

sethsimmons: I guess a third result would be helpful

I don't have my env anymore so will take some time

But I can

2 of my hashes don't match

and I don't know how to proceed lol

I will prepare it for the next time.

sethsimmons: you have to change the gitian-build.py like this: monero-project/monero #7652/files

before building

Ok will take a stab at that shortly

Running now with those lines removed

mostly interested in linux hashes

Running now too

I had to reinstall everything from scratch, it's been a while since 0.17.1.9 :D

my hashes: paste.debian.net/1192772

yours match iDunk

so whats the deal? is the thing all comboobled or can i just follow the same instructions as before?

Linux hashes ^

sethsimmons: yours match mine again

scoobybejesus: iDunk: did you have the old cache?

Yeah don't match scoobys

weird

Mine was completely from scratch, had never built on this host before

both sethsimmons and me did it from scratch

i did not do from scratch

seems like "something" changed that causes inconsistencies if not done from scratch

I had the old cache.

I did this but edited the gitian-build.py: reddit.com/r/Monero/comments/heng91…e=reddit&utm_medium=web2x&context=3

Silly question: do I need to follow this step: git clone git⊙gc:monero-project/gitian.sigs.git

?

Only to push sigs in a PR

Not to generate the hashes and compare FWIW

thx

but pushing sigs via PR is important for those who can (I need to)

We are not at the point where I can deploy a docker container, git clone, build and get a hash?

Thats what this does

It's a script to automate that for you

ooooh

<sethsimmons "I did this but edited the gitian"> The steps here create the user needed, install dependencies, run the build script, and outputs all hashes

I'm building on one slow machine, but I will plug a faster one soon.

Just edit user and version to match

hm so still have to run gitian-build.py outside docker. I was kind of hoping it would be even more containerized so everything happened inside docker :)

For a community that prides itself on manipulating people, you can't manage a single guy that spends most of his time in his underpants :D

OK, building on my best horse as well.

I'm still building somehow

Previous builds took less time

<Inge- "hm so still have to run gitian-b"> All of the building does, but still have to setup the build env for Docker

But yes, would be nice to have a pre-built container image that can be run to build the latest tag

my hashes: paste.debian.net/hidden/3a64f669

I don't remember how to build MacOS binaries

sech1: ^

My linux hashes didn't match with scoobybejesus - did you edit gitian-build.py as was recommended?

i commented out ilnes 97-100, yeah

me too

it seems to be an issue with the cache, maybe some compiler got updated or so

But I screwed up and restarted the build several times before it ran smoothly

mine: paste.debian.net/hidden/7dbf7c52

selsta your hashes match with mine. I'll start the build again to build MacOS binary

Docker image pushed if anyone wants to test/get ahead of the game running it.

Still building reproducible hashes.

I guess downloading some docker image to do the process for you also isn't ideal if you can't verify what the docker image does :D

(not familiar with docker so I can be wrong here)

heh

well ideally there is a github page with a Dockerfile that is used in the creation of said image

so you can inspect the Dockerfile, and use it to build your own image

Running v0.17.2.0 on my server already

are there release notes or something to see the main changes? or only commits at this point?

```

Inge-: mostly stability fixes

and some longer-term hardening against node attacks I presume

not yet in this release

k

I see quite a few P2P fixes from anon CCS

in v0.17.2.0

mostly seg fault / deadlock / race condition fixes

Oh, and my little bugfix PR (7615) is there too

GUI has more interesting changes this time

.merge+ 7652 7653 7654 7655

Added

have been running the anon CCS fixes for a while on multiple nodes and everything seems quite stable :)

though v0.17.1.9 also had 70 days update for me

selsta: with or without banlist?

do you mean 70 days uptime?

yes

typo

or thought about the right word and wrote the wrong one lol

yes, I've been running 0.17.1.9 non-stop pretty much since it was released

Inge-: most with, 1 without

Final hashes: paste.debian.net/1192802

Inge-: release notes paste.debian.net/hidden/80c091c8

"- Only print blocked nodes once with --enable-dns-blocklist (#7295)"

Thank God, my poor logs XD

im gettin this: /home/xmrchain/monero/tests/unit_tests/node_server.cpp: In lambda function:

acceptor.listen(boost::asio::socket_base::max_listen_connections, ec);

when trying to compile 17.2

gingeropolous: monero-project/monero #7654/files

or update boost

but that's just test, you can ignore it

daemon should built fine

build*

k. danke

Hashes late into the show: paste.debian.net/1192805

selsta "7 people who worked ..." and the list has 9 people

ty

xmrchain is on 17.2

hashes from me, this time with MacOS binaries: paste.debian.net/hidden/6d92502e

sech1: please post to gitian.sigs repo

if you have gpg installed :D

I don't...

Does anyone here know of a secure implementation of Ring Signatures. Specifically traceable Ring Signatures?

Monero's implementation is meant to be secure. At least for Monero's usage.

i know you guys are busy atm but maybe someone has help: monero-project/monero-gui #2806#issuecomment-816019049

> Can an @monero-project maintainer comment on why there is a requirement for a git clone in order to run make release as noted in the README.md file??

That's how it determines the version string. I don't think there's another reason.

kinghat[m], I'd propose to clone from a local repository.

So clone from outside their build system, pass the cloned local copy to the BS, and from within clone the passed one.

You're not the issue starter, are you?

no sorry, am just following along as I think monero should be packaged in flatpak for Linux.

I think best would be to add a NO_GIT_VERSION cmake option.

Set that and it uses... "unknown" as a version string.

I replied him. No problem.

thanks selsta

thanks for the replies all