should we be updating the version of OpenSSL in our builds? 1.0 is deprecated

newest OpenSSL security advisory (today) openssl.org/news/secadv/20201208.txt

bah. cmake can't find this version of openssl

pos

inv4 "Monero developer Howard Chu suggests switching to Proof of Stake with a one-line comment on IRC: pos"

*inb4

Why does the Saviour of NASA take a group achievement award and present it as a proof of individual glory? twitter.com/hyc_symas/status/1203709575226183683

so, apparently github is introducing a new "discussions" tab, where people could discuss things without open issues. Sounds interesting, could be a good alternative to /r/monerosupport (i have no idea how it works yet)

looks interesting, like a mini-forum to suggest/discuss ideas and features

seems like a stackexchange kind of thing

Actually, they recently added some features, like dark mode and more detailed github actions: github.blog/2020-12-08-new-from-uni…hub-sponsors-for-companies-and-more

seems like our gitian builds are a bit fragile, downloading additional pkgs from ubuntu repo on top of the base docker image

because the ubuntu repo may age out and disappear

we should instead grab all pkgs we need right now and freeze that in a new docker image

no?

TheCharlatan: wdy think?

hello, I think we've identified a reproducible builds issue in monero:

please share

it seems that if a new release is pushed the code that generates the version string generates a different string, so rebuilding old versions would be a problem

this was flagged by the rebuilder system we use for archlinux: reproducible.archlinux.org/api/v0/builds/10997/diffoscope

`0.17.1.5-release` vs `0.17.1.5-3942a1cd` in the rebuild

wtf is a Gnu Build ID

you can ignore that, it's deterministic and going to be the same if there are no other differences in the binary

the version strings have a different length, so the diff is a bit noisy because the offsets are different in the rebuild

The "release" part of the version string checks if there is a commit which is a parent to the current HEAD.

I think that's what you mean with "if a new release is pushed".

it checks if you're building the most recent tagged commit

so it won't set "release" if you're building an older tagged commit

perhaps that should be changed

yes, what hyc is saying

I'm reaonably sure it will not say release if your HEAD is tagged but there's a child to HEAD.

That bugged me for my TF builds before.

I think the first package was built before the 0.17.1.6 release and the second one afterwards

we could use something like "git describe" instead, to determine if we're on a tagged commit

I'll try to fix it.

should I open an issue for this on github?

ndorf: see 7102, I remember this being fiddly and I might have broken your test case.

I don't think it's needed, there's a patch already.

(7102)

cool, thanks!

moneromooo: do you mean the unit test? not sure how this change could break that, as it still seems to output either $ver-release or $ver-$commit as before?

I mean the make bit.

cmake

I'm not sure what you fixed it for, so I'm not sure whether I broke that fix.

oic. this should be good. the original fix was for not updating the string on incremental rebuild, this shouldn't affect that. i'll make sure

Ah. Yes, should not matter here. Thanks.

np, thanks for the heads up