The first automated Valgrind report has been generated:

memcheck cachegrind and callgrind for core_tests and unit_tests

Hi.

 "rct_signatures": {

    "type": 5,

    "txnFee": 60930000,

    "ecdhInfo": [ {

        "amount": "618ca40e12c5c809"

      }, {

        "amount": "1e896a93742349d5"

      }],

    "outPk": [ "30e3be026c87d7c1b8ae41b5ddfa6ceb1a9a9f9d728e8e73e79d96b4d0f15f44", "45e374a3f98af5b6c2f2905cbc4968a3cd282fc32c48870bf0d2f15fe75924e0"]

  }

> the "amount" in ecdhInfo is the Pedersen Commitment?

> and if "key" in "vout" is the output public key, what is "outPk"?

the terms and names in the docs and the c++ source are not consistent =(

Thanks a lot mj-xmr 🙂 moneromooo xiphon do we need to explore more alternatives or mj-xmr's solution is enough?

NP.

i was probably showing as guest again. It went so well for some time :(

So now that I'm a little more free, concerning the matter of getting Monero onto Tails (gitlab.tails.boum.org/tails/tails/-/issues/17823), and personally making it easy to manage Monero packages on my Fedora system (not in Fedora / RPM Fusion), I'm interested in exploring in parallel getting Monero packaged w/ Flatpak

However, official documentation isn't perhaps as quite as verbose as I would like concerning all the possible syntax for the manifest (docs.flatpak.org/en/latest/first-build.html). I was wondering if anyone w/ Flatpak experience could recommend any documentation/guides around manifest building outside of the official docs

"Their package list is missing libboost-dev. This package contains boost::optional (and no other package does)" -> according to the Debian's build log, boost::optional is not missing.

also i'm sure it is installed as a dependency

for example, they have libboost-chrono-dev in their package list and it depends on libboost-dev

thus i don't think the issue is caused by missing boost::optional

it might be another reason, version mismatch or something... But looking at the test case, i would just do something like paste.debian.net/plain/1182819

should fix the issue

mj-xmr ^. Waiting mooo's opinion as well

xmrscott: can't help with that, but monero on flatpak was something a good amount of people requested some time ago (and there is an issue open somewhere in monero or monero-gui IIRC). Would be actually cool to have it there

Yeah, looks like someone already has a manifest

Commenting now to encourage them to submit to Flathub for review by Flathub

nice

Found what looks like the manifest in question for anyone curious: github.com/BigmenPixel0/flathub

I guess if they don't respond or submit to Flathub in two weeks I'll look into using their work to submit to Flathub myself and cite them

I won't be around this afternoon (i'll be back in the evening), so i already sent xiphon's patch, along with comment, on the issue tracker

Did you know that all witdraw-buyer-seller-depoist chains are trackable in Monero? No? You should have read Breaking Monero. How many people are you endangering with your 'privacy' coin?

I've not seen mj-xmr's solution, but xiphon's appear good to me, assuming it fixes the problem for them.

alright. I sent the patch and an email directly to the guy. Let's see

apologies, not sure if my message got through before I got disconnected: I saw what I suspect to be shilling in an article, is this now confirmed to be true or false?  darknetstats.com/us-department-of-h…bility-to-track-monero-transactions

This channel is for monero development. Try #monero.

apologies, will do. I had a dev question, last time I checked the monero wallet wasn't included in debian packages so it couldn't be implemented in Tails, is this still the case?

AFAIK yes. There was recently a discussion about a problem that prevented this, and it's not yet fixed.

aha interesting, what was the problem?

It doesn't compile.

bugs.debian.org/cgi-bin/bugreport.cgi?bug=973196 if you want details.

many thanks!

In that bug report I shown, that I can reproduce the problem with his list of packages using the same Dockerfile, but Jonas seems to have missed this point. I still think this is a packaging problem.

I'll try to explain him.

I replied him. The message is logged int the list.

There are still some differences between Dockerfile and his build script:

1) He applies some patches

2) I did submodule init before transferring the files into a Docker image.

Just to say, that there's some more work to do.

mj-xmr: google/googletest 0555b0e

debian testing uses master branch version of gtest which includes this commit and is incompatible with latest release version

xiphon's patch or paste.debian.net/hidden/6f2ce9c8 should solve it

aaaaah!

OK. If the deadline is tight, then the patch is a solution. I'm just afraid, that we'll be back to the same problem sooner or later.

i don't get it, what problem do you mean?

xiphon: imagine, that for another release another developer writes again a test like:

ASSERT_EQ(*s, "");

instead of

ASSERT_TRUE(*s == "");

Our CI doesn't catch it as a bug, but the Debian maintainer catches it, which is too late.

Add to this, that it's typically associated with tight deadlines on their side.

hello.

we add the nonce in the extra field on the tx.

do we get the nonce from the block explorer?

thanks

i don't expect any developer will wrire any more wipeable string tests anytime soon

To your patch, I'd probably write a static assertion, that is able to catch it, before it leaves our CI.

but that's it.

catches what?

catches ASSERT_TRUE internal behavior?

The bug, that would otherwise occur at the Debian maintainer's place.

But now that I think of it, I can't figure out how I would write such an assertion.

indeed

and this is not a bug

at all.

it is expected behavior

code that streams wipeable string's contents shouldn't compile

and that's what happened

Constructs which might force other software to stream shouldn't compile on our CI.

But as I said, I'd need to think a bit more about this.

I'm theorizing a bit.

Especially since this is GTest, that we're talking about.

OK. A solution would be to wrap the gtest ASSERTS and use only the wrappers. Whenever a MONERO_ASSERT_EQ() would be used on wipable string, a static assert would halt the compilation. Then prohibit any naked ASSERT_EQ, and you're done.

If it's worth it, is a different thing. But that's how you'd solve it.

"But that's how you'd solve it." -> till GTest changes its behavior again in some future release and you end up with unwanted MONERO_ASSERT_EQ macros

"that is able to catch it, before it leaves our CI" -> just use the latest GTest on the CI then

xiphon's patch seem to have worked FYI

* xiphon's patch seems to have worked FYI

looks like that debian compile error issue is fixed now?! I was gonna get some friends to take a look :)

moneromooo looks like debian compile is fixed? thats a weird coincidence that I randomly thought of it today and its fixed (unless I reminded someone etc)

Dunno. Check the link I gave you yesterday.

yup, thats where I saw

looks like inproofs might need to be updated, to add a signature proving knowledge of the private spend key (it could be a signature stored in anticipation of future need, don't have to generate one every time) monero-project/monero #7353

InProofV3 ^

skengdaddy: It is fixed, now 0.17.1.9 will be released and hopefully soon will be included in testing