00:57:44 <m-relay> <t​zadiko:matrix.org> I've addressed comments on this. If anyone is free, can I get a set of eyes over this PR, please? It's a simply code-cleanup PR, no logic changes.
00:57:44 <m-relay> <t​zadiko:matrix.org> https://github.com/monero-project/monero/pull/9838
00:58:12 <m-relay> <t​zadiko:matrix.org> Going to look through the PRs and review some folk's PRs. If you have one that you find important, please send it my way, I'll prioritise.
01:01:22 <luigi1111> what's the tag
01:02:50 <luigi1111> 18.4?
01:03:59 <m-relay> <s​yntheticbird:monero.social> v18.4.0 yes
01:07:44 <luigi1111> done
01:08:33 <m-relay> <s​yntheticbird:monero.social> 🫡
01:08:50 <m-relay> <s​yntheticbird:monero.social> selsta
01:10:03 <nioc> v0.18.4.0  ( ͡° ͜ʖ ͡°)
01:10:15 <selsta> too late for me to do GUI, let's do that tag tomorrow
01:50:20 <m-relay> <t​zadiko:matrix.org> What another high priority issue a noob can tackle?
02:08:56 <m-relay> <g​ingeropolous:monero.social> it wasn't the node with the potential hardware issue. thats my seed node. this is the xmrchain node. but yes, yay tag! cause yeah, this coulda been existing for a while, i just run monerod managed by systemd so it just restarts. because internet.
02:39:59 <m-relay> <r​4v3r23:monero.social> release notes?
02:50:51 <m-relay> <o​frnxmr:xmr.mx> Build party first :P
03:08:37 <m-relay> <t​zadiko:matrix.org> Release notes: "Things were changed"
11:52:19 <m-relay> <t​obtoht:monero.social> build party sounds way more fun than verified reproduction
12:27:40 <m-relay> <m​onero.arbo:matrix.org> build seems to have failed somehow, only giving Linux binaries https://paste.debian.net/1366203/
12:31:16 <m-relay> <m​onero.arbo:matrix.org> I'm looking at the build log and I don't see anything that looks particularly weird. end of the build log looks like this (https://paste.debian.net/1366204/), lots of boost errors but the riscv64 build finished, they don't seem relevant
12:35:57 <m-relay> <p​lowsof:matrix.org> why am i seeing a ruby like error that -site had https://stackoverflow.com/a/75353113
12:36:51 <m-relay> <p​lowsof:matrix.org> from bin/gsign* in Lyza s pastebin
12:39:27 <m-relay> <m​onero.arbo:matrix.org> great question, I thought it seemed weird but was maybe just complaining about missing file. gonna delete stuff and re-try building in the meantime
12:57:25 <scoobybejesus> mine built fine: https://paste.debian.net/plain/1366210
12:58:26 <m-relay> <o​frnxmr:xmr.mx> Prob have to use docker method bcuz your os is too new
13:13:30 <scoobybejesus> dockrun.sh for me
13:35:38 <m-relay> <m​onero.arbo:matrix.org> that was docker
13:36:22 <m-relay> <o​frnxmr:xmr.mx> dockrun.sh?
13:36:43 <m-relay> <m​onero.arbo:matrix.org> ah no I'm still using this guide https://github.com/monero-project/monero/blob/v0.18.4.0/contrib/gitian/README.md
13:37:57 <m-relay> <m​onero.arbo:matrix.org> "For a shortcut using docker follow the instructions in DOCKRUN.md instead of following the rest of this document.."
13:37:58 <m-relay> <m​onero.arbo:matrix.org> BRUH
13:38:16 <m-relay> <m​onero.arbo:matrix.org> maybe we should remove the old docker instructions form this document? :-/
13:49:02 <sech1> "Gitian host OS should be Ubuntu 18.04 "Bionic Beaver""
13:49:06 <m-relay> <o​frnxmr:xmr.mx> 🤷‍♂️
13:49:15 <sech1> Well, I tried it on Ubuntu 24.04 and it failed quickly
13:49:27 <m-relay> <o​frnxmr:xmr.mx> had to edit dockrun.sh anyway, since `command -v apt-cache-ng` fails in my sys
13:49:27 <sech1> Time to spin up my VM, as before
13:50:41 <m-relay> <o​frnxmr:xmr.mx> (i edited it to `command -v apt-cache`)
13:51:16 <m-relay> <m​onero.arbo:matrix.org> bleh I guess I fucked up updating the VM I use for building when guix was added to master
13:52:55 <m-relay> <o​frnxmr:xmr.mx> Dven after installing apt-cache-ng on debian 12, the command doesnt exist. So.. i basically just told the script to check for something that does. Build working np
13:54:04 <selsta> gitian was successful on CI https://github.com/monero-project/monero/actions/runs/14140602581
14:10:28 <m-relay> <t​obtoht:monero.social> gitian ci runs will break after github removes the 20.04 runner in two weeks
14:10:35 <m-relay> <t​obtoht:monero.social> i guess we'll have to dockerize that too unless we branch from master soon :D
14:13:36 <scoobybejesus> my host is on 22.04, but it seems weird that it would matter. the container is 18.04.6 LTS. I did not edit dockrun.sh at all.  git pull, git submodule update --init --force, git checkout v0.18.4.0, cd contrib/gitian, OPT="-j 12" ./dockrun.sh v0.18.4.0, go to bed, wake up and done
14:15:53 <m-relay> <o​frnxmr:xmr.mx> I'm on debian 12
14:16:22 <m-relay> <o​frnxmr:xmr.mx> `command -v apt-cache-ng` probably stikl works for you on ubuntu 22
14:16:55 <m-relay> <o​frnxmr:xmr.mx> The dockrun script checks if that command works before proceeding to do anything in a container
14:21:30 <scoobybejesus> ah okay, yeah
14:57:26 <m-relay> <o​frnxmr:xmr.mx> https://github.com/monero-project/monero/pull/8105
14:57:40 <m-relay> <o​frnxmr:xmr.mx> relevant
14:59:17 <m-relay> <p​lowsof:matrix.org> good luck dealing with ruby without docker :P
15:05:17 <m-relay> <o​frnxmr:xmr.mx> `sed -i "s/file.exists/file.exist/g" *` 😂
15:06:10 <m-relay> <o​frnxmr:xmr.mx> i only see ruby as dependency for lxc build, but idk
15:06:45 <m-relay> <o​frnxmr:xmr.mx> I used dockrun -> didnt sign -> copied asserts to signing host
15:16:24 <m-relay> <m​onero.arbo:matrix.org> dockrun.sh has def made it past where the old docker directions failed, looks like it will probably finish
15:18:15 <scoobybejesus> I also didn't sign, copied asserts to signing host
15:43:14 <m-relay> <m​onero.arbo:matrix.org> spoke too soon https://paste.debian.net/1366267/ 🤷‍♀️
15:51:36 <m-relay> <o​frnxmr:monero.social> Did you use any OPTs?
15:53:45 <m-relay> <m​onero.arbo:matrix.org> ya, OPT="-j 15"  ./dockrun.sh v0.18.4.0
15:54:43 <m-relay> <o​frnxmr:monero.social> Reduce the 15 and try again
15:55:47 <m-relay> <o​frnxmr:monero.social> Just a wild guess, bcuz monero will fail to build for me if i set too high of a # on normal builds
15:56:34 <m-relay> <m​onero.arbo:matrix.org> running it with 12 now since that seemed to work for scoob
15:57:56 <m-relay> <o​frnxmr:monero.social> From readme, xmr can use 2gb ram per thread, so ya
15:58:11 <scoobybejesus> I used to do OPT="-j 4 -m 12000" because you ideally want >2G RAM per core, but I added more RAM recently
16:07:07 <m-relay> <m​onero.arbo:matrix.org> my VM has 16 threads and 36 GB of RAM 😤
16:09:10 <m-relay> <m​onero.arbo:matrix.org> > "-j 4 -m 12000"
16:09:10 <m-relay> <m​onero.arbo:matrix.org> ah shit I did -j 15 and it probably defaulted to -m 2000
16:40:05 <m-relay> <t​zadiko:matrix.org> selsta, this is no longer "in progress": https://github.com/monero-project/monero/pull/9831
16:40:50 <selsta> updated the label
17:41:28 <ofrnxmr> scoobybejesus probably need to drop your merge commit on gitian.sigs pr
17:42:03 <scoobybejesus> oh shoot, that's so annoying.. okay, thanks
17:58:33 <scoobybejesus> I'm reverting and force pushing changes and github is ignoring me.. gonna have to look at it later
18:00:54 <m-relay> <o​frnxmr:xmr.mx> `git reset --hard HEAD~1 ` should drop the merge commit (be careful not to drop your main commit :D)
20:38:15 <m-relay> <t​zadiko:matrix.org> vtnerd: I was looking at TransactionHistory after your comment and see the lock in Refresh and GetAll. I agree that exposing protected state outside of the class is poor design and a bad idea. The change here would be to revert this method to returning by copy, which I don't like. In this copy case, each item in the vector will also be copied, and each item is definitely more than<clipped message>
20:38:16 <m-relay> <t​zadiko:matrix.org>  the size of a pointer. I bring up the size of a pointer because the alternative is to just return shared_ptr so only a copy of a pointer will be made - when that is done, clients won't need to change their usage (from -> to .) either. What do you think?
20:46:39 <m-relay> <t​zadiko:matrix.org> I was initially opposed to the shared_ptr idea until I saw the lock and reconciled it with TransactionInfos no longer being pointers.
20:47:17 <m-relay> <t​zadiko:matrix.org> The memory leak / dangling pointer issue exists if I was to revert this to use raw pointers, which I don't want to do
22:12:29 <m-relay> <v​tnerd:monero.social> The lock in `TransactionHistoryImpl` can likely be removed. Every downstream project had to use `TransactionHistory` in a single thread because of the dangling pointers you mentioned
22:13:11 <m-relay> <v​tnerd:monero.social> This allows for `const std::vector<…>&` in that function signature
22:17:59 <m-relay> <v​tnerd:monero.social> whether you remove the pointers from that vector is another topic. removing those pointers is definitely safer than the current design, but requires a copy of every field at construction time.
22:19:09 <m-relay> <v​tnerd:monero.social> one issue is that the design does not allow filtering by subaddress. So you have to get the entire history (from `TransactionHistory`) then iterate over every transaction, and filter on `TransactionInfo::subaddrAccount()`.
22:19:27 <m-relay> <v​tnerd:monero.social> so in the worse case, you’ve just copied tons of data even though only a subset of the history is needed per UI window
22:24:50 <m-relay> <v​tnerd:monero.social> https://github.com/monero-project/monero-gui/blob/47f0047c9f7ec991abfabc89d4f1435a28bbedfc/src/libwalletqt/TransactionHistory.cpp#L83
22:25:27 <m-relay> <v​tnerd:monero.social> as an example, the GUI currently requests all history, filters on this one field, and then finally copies every field it needs.
22:25:43 <m-relay> <t​zadiko:matrix.org> I can follow up in a PR with a getTransactionBySubAddressAccount Api.
22:26:12 <m-relay> <t​zadiko:matrix.org> Im just concerned a future downstream application will call Refresh and GetAll at the same time, but I guess it's up to them to syncrhonize properly / ensure thread safety.
22:26:26 <m-relay> <t​zadiko:matrix.org> Relaxing that constraint on our end makes sense to me (removing the lock).
22:26:38 <m-relay> <t​zadiko:matrix.org> getTransaction**s**BySubAddressAccount
22:34:55 <m-relay> <v​tnerd:monero.social> adding that function is only addressing a particular symptom and not the general problem. removing the pointers forces the backend to make a copy of every field or use `vector<monero::TransactionInfo>` directly. My lwsf implementation is currently storing things in a `map<public_key, …>` because its quicker for merging the info from the LWS REST API
22:35:52 <m-relay> <v​tnerd:monero.social> or in other words, if another UI wants to filter on another field, another function would have to be added, etc
22:36:39 <m-relay> <v​tnerd:monero.social> luckily the major_index of a subaddress is probably the filter 99% of the time
22:37:43 <m-relay> <t​zadiko:matrix.org> Following up with the PR as it stands (ignoring subaddress for now), Ill remove the locks.