05:51:25 <mj-xmr> The first automated Valgrind report has been generated:
05:51:26 <mj-xmr> http://enjo.hopto.org/pub/monero/
06:01:07 <mj-xmr> memcheck cachegrind and callgrind for core_tests and unit_tests
06:34:11 <usamat> Hi.
06:34:12 <usamat>  "rct_signatures": {
06:34:12 <usamat>     "type": 5,
06:34:13 <usamat>     "txnFee": 60930000,
06:34:13 <usamat>     "ecdhInfo": [ {
06:34:14 <usamat>         "amount": "618ca40e12c5c809"
06:34:14 <usamat>       }, {
06:34:15 <usamat>         "amount": "1e896a93742349d5"
06:34:15 <usamat>       }],
06:34:16 <usamat>     "outPk": [ "30e3be026c87d7c1b8ae41b5ddfa6ceb1a9a9f9d728e8e73e79d96b4d0f15f44", "45e374a3f98af5b6c2f2905cbc4968a3cd282fc32c48870bf0d2f15fe75924e0"]
06:34:16 <usamat>   }
06:34:17 <usamat> > the "amount" in ecdhInfo is the Pedersen Commitment?
06:34:17 <usamat> > and if "key" in "vout" is the output public key, what is "outPk"?
06:35:53 <usamat> the terms and names in the docs and the c++ source are not consistent =(
08:58:15 <Guest20897> Thanks a lot mj-xmr 🙂 moneromooo xiphon do we need to explore more alternatives or mj-xmr's solution is enough?
09:16:58 <mj-xmr> NP.
09:26:19 <ErCiccione[m]> i was probably showing as guest again. It went so well for some time :(
09:36:42 <xmrscott[m]> So now that I'm a little more free, concerning the matter of getting Monero onto Tails (https://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
09:38:23 <xmrscott[m]> However, official documentation isn't perhaps as quite as verbose as I would like concerning all the possible syntax for the manifest (https://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
09:41:53 <xiphon> "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.
09:42:40 <xiphon> also i'm sure it is installed as a dependency
09:43:10 <xiphon> for example, they have libboost-chrono-dev in their package list and it depends on libboost-dev
09:43:52 <xiphon> thus i don't think the issue is caused by missing boost::optional
09:44:34 <xiphon> it might be another reason, version mismatch or something... But looking at the test case, i would just do something like https://paste.debian.net/plain/1182819
09:44:44 <xiphon> should fix the issue
09:49:10 <ErCiccione[m]> mj-xmr ^. Waiting mooo's opinion as well
09:50:33 <ErCiccione[m]> 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
09:50:45 <xmrscott[m]> Yeah, looks like someone already has a manifest
09:50:49 <xmrscott[m]> https://github.com/monero-project/monero-gui/issues/2806
09:51:07 <xmrscott[m]> Commenting now to encourage them to submit to Flathub for review by Flathub
09:51:39 <ErCiccione[m]> nice
09:58:16 <xmrscott[m]> Found what looks like the manifest in question for anyone curious: https://github.com/BigmenPixel0/flathub
09:59:06 <xmrscott[m]> 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
10:16:48 <ErCiccione[m]> 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
10:21:21 <jakoson0> 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?
10:43:46 <moneromooo> I've not seen mj-xmr's solution, but xiphon's appear good to me, assuming it fixes the problem for them.
11:03:19 <ErCiccione[m]> alright. I sent the patch and an email directly to the guy. Let's see
11:16:37 <skengdaddy> 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?  https://www.darknetstats.com/us-department-of-homeland-security-gets-the-ability-to-track-monero-transactions/
11:17:44 <moneromooo> This channel is for monero development. Try #monero.
11:19:30 <skengdaddy> 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?
11:20:40 <moneromooo> AFAIK yes. There was recently a discussion about a problem that prevented this, and it's not yet fixed.
11:21:29 <skengdaddy> aha interesting, what was the problem?
11:21:38 <moneromooo> It doesn't compile.
11:22:47 <moneromooo> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973196 if you want details.
11:22:50 <skengdaddy> many thanks!
11:29:24 <mj-xmr> 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.
11:30:05 <mj-xmr> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973196#22
11:35:19 <mj-xmr> I'll try to explain him.
11:54:21 <mj-xmr> I replied him. The message is logged int the list.
11:54:42 <mj-xmr> There are still some differences between Dockerfile and his build script:
11:54:51 <mj-xmr> 1) He applies some patches
11:55:29 <mj-xmr> 2) I did submodule init before transferring the files into a Docker image.
11:55:42 <mj-xmr> Just to say, that there's some more work to do.
12:48:02 <selsta> mj-xmr: https://github.com/google/googletest/commit/0555b0eacbc56df1fd762c6aa87bb84be9e4ce7e
12:49:37 <selsta> debian testing uses master branch version of gtest which includes this commit and is incompatible with latest release version
12:50:15 <selsta> xiphon's patch or https://paste.debian.net/hidden/6f2ce9c8/ should solve it
12:56:51 <mj-xmr> aaaaah!
13:00:19 <mj-xmr> 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.
13:05:55 <xiphon> i don't get it, what problem do you mean?
13:06:52 <mj-xmr> xiphon: imagine, that for another release another developer writes again a test like:
13:06:53 <mj-xmr> ASSERT_EQ(*s, "");
13:06:56 <mj-xmr> instead of
13:07:01 <mj-xmr> ASSERT_TRUE(*s == "");
13:07:31 <mj-xmr> Our CI doesn't catch it as a bug, but the Debian maintainer catches it, which is too late.
13:08:26 <mj-xmr> Add to this, that it's typically associated with tight deadlines on their side.
13:08:46 <usamat> hello.
13:08:46 <usamat> we add the nonce in the extra field on the tx.
13:08:47 <usamat> do we get the nonce from the block explorer?
13:08:47 <usamat> thanks
13:08:57 <xiphon> i don't expect any developer will wrire any more wipeable string tests anytime soon
13:10:34 <mj-xmr> To your patch, I'd probably write a static assertion, that is able to catch it, before it leaves our CI.
13:10:57 <mj-xmr> but that's it.
13:11:28 <xiphon> catches what?
13:11:35 <xiphon> catches ASSERT_TRUE internal behavior?
13:11:50 <mj-xmr> The bug, that would otherwise occur at the Debian maintainer's place.
13:12:10 <mj-xmr> But now that I think of it, I can't figure out how I would write such an assertion.
13:12:24 <xiphon> indeed
13:12:54 <xiphon> and this is not a bug
13:13:00 <xiphon> at all.
13:13:11 <xiphon> it is expected behavior
13:13:25 <xiphon> code that streams wipeable string's contents shouldn't compile
13:13:41 <xiphon> and that's what happened
13:15:18 <mj-xmr> Constructs which might force other software to stream shouldn't compile on our CI.
13:15:45 <mj-xmr> But as I said, I'd need to think a bit more about this.
13:15:56 <mj-xmr> I'm theorizing a bit.
13:16:33 <mj-xmr> Especially since this is GTest, that we're talking about.
13:24:39 <mj-xmr> 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.
13:25:15 <mj-xmr> If it's worth it, is a different thing. But that's how you'd solve it.
13:28:02 <xiphon> "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
13:32:11 <xiphon> "that is able to catch it, before it leaves our CI" -> just use the latest GTest on the CI then
14:20:01 <ErCiccione[m]> xiphon's patch seem to have worked FYI
14:22:21 <ErCiccione[m]>  * xiphon's patch seems to have worked FYI
16:57:28 <skengdaddy> looks like that debian compile error issue is fixed now?! I was gonna get some friends to take a look :)
17:32:19 <skengdaddy> 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)
17:33:31 <moneromooo> Dunno. Check the link I gave you yesterday.
17:35:02 <skengdaddy> yup, thats where I saw
17:48:47 <UkoeHB> 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) https://github.com/monero-project/monero/issues/7353
17:48:57 <UkoeHB> InProofV3 ^
18:53:35 <ErCiccione[m]> skengdaddy: It is fixed, now 0.17.1.9 will be released and hopefully soon will be included in testing