09:37:19 I see we are still having double PRs (one for branch one for master). Wouldn't be better to even branch and master? Having double PRs as a workflow looks very inconvenient and confusing 09:40:30 This is probably stuff that should be organized by the lead maintainer, but snipa is rarely around and in general not really active. Isn't it time to find a new lead maintainer? 11:07:28 snipa is gone, luigi1111 is doing interim until new maintainer is confirmed 11:19:41 I think we talked about this already, we only merge bug fixes to branch. 11:20:01 binaryFate: i didn't know. Thanks for the update 11:20:24 selsta: I thought that was only temporary 11:21:03 and after some time branch and master would have been even again 11:21:04 Master has all the newest features + bug fixes, branch has bug fixes 11:22:48 If the plan is to keep it that way, would be important to point it out somewhere if it's not there already, so that contributors know there is a difference 11:24:56 The readme should be updated with some minimal guidelines for contributors. The fact that development happens in two branches is an important detail that people should be aware of. 11:26:48 mmmh the readme definitely needs a general refresh. 11:31:52 I usually make sure to comment on PRes that also need to get submitted against branch 12:21:03 How important is it to be able to spend pre-triptych and triptych outputs in the same tx ? 12:26:00 if they can't be spent together it'll be possible to tell when someone spends a pre-triptych output, forever and ever 12:26:17 but it's kind of the same situation as with pre-RingCT outputs? 12:26:19 True. But since it's also possible otherwise, it doesn't matter. 12:27:09 is it technically possible to spend them together? 12:27:14 Yes. 12:28:18 I think Monero philosophy is to leak as little data as possible and allowing to spend them together leaks less data 12:28:31 Why 5? 12:28:31 But does it complicate implementation a lot? 12:28:54 Depends how you define "a lot" I guess. 12:29:24 Any research needed for this? 12:29:36 Doing it. 12:29:45 one "if...else" somewhere in the code or bigger refactoring? 12:29:53 Lots more changes. 12:31:53 I don't know then, we have almost 30M transactions and not being able to use them in rings together with triptych also looks like reducing anonymity set 12:32:22 pre-RingCT vs RingCT had much smaller scale 12:33:17 Maybe I'm missing your point, so give a detailed example. 12:34:17 you selection for ring members will be limited to only triptych transactions after the fork, if you spend new outputs 12:34:37 maybe it doesn't matter much 12:34:47 Yes. 12:35:06 This is not relevant to whether it's important to be able to spend T and !T outputs in the same tx though. 12:35:31 forget everything I said :D 12:35:42 I thought about ring selection the whole time 12:35:51 spending them together is not important 12:36:46 For the record, the case I'm thinking about is someone who wants to spend 10, has a T out of 8 and a pre-T out of 5. They'd have to self spend the 5 first, which is a bit annoying. 12:37:12 not a problem if it has to be done only once to convert to Triptych 12:37:26 it can even be automated in the wallet 12:40:25 btw even now my wallet works funny. I want to send X Monero and it selects two outputs to do it, each output much larger than X. 12:40:40 if it keeps like that after Triptych each spend will eventually convert 2 or more outputs 12:44:57 maybe wallet could analyze all outputs after Triptych fork and suggest a user to churn all pre-Triptych outputs together or separately? 12:45:36 I would not want that myself. 12:46:08 The only reason I see is if you want to be prepared to make a large spend without notice. 12:46:10 it really depends on the set of outputs. People who use it actively usually have many outputs 12:46:33 so they don't run into "not enough funds in a single output" situation you described 12:47:12 but for that situation wallet needs to print something meaningful and suggest auto-churn? 12:47:37 Yes, that sounds like a good idea. 12:48:48 something like "you don't have enough funds in either pre-fork or post-fork outpus to send this tx, you need to churn pre-fork outputs first. Churn (y/n)" 13:59:47 i am superconfused - if i use the Dockerfile to build monero it's all good - but builds without trezor because no python. if i apt install python-minimal, make release-static gives errors concerning multiple definitions linking monero-wallet-cli : https://paste.debian.net/1186208/ - apt remove python-minimal && make release-static restores a successful build 14:00:17 (v0.17.1.9) 14:05:21 Your libzmq is built with symbols that clash with libsodium. Rebuild libzmq with the appropriate flags. Something like external-libsodium or whatever it is. 14:05:56 Or no-tweetnacl maybe. It just needs to use libsodium, not its internal conflicting code. 14:08:07 https://github.com/monero-project/monero/issues/6799#issuecomment-707208779 14:09:32 1thanks 14:10:45 but why does having python installed make this happen? 14:12:49 You might see clues in the cmake log. It might find different libs. 14:13:34 will check that 14:14:27 If you make with VERBOSE=1, it will also print the compile/link command lines. Spot the differences. 15:15:52 vtnerd: could you take a look at 7389? you reviewed the previous related PRs 18:29:24 #7358 had been updated 19:40:16 “I thought, ‘I’m going to pump it and dump it,’ because I was interested and taking the ideas and implementing them in bitcoin. The bitcoin code base was far more interesting to me than monero, and I thought, ‘I’m not going to work on this codebase, it’s terrible,'” he recalls - fluffypony in an interview about Monero 19:56:35 If a notable developer (e.g. moo) can comment on their support for getting Monero into FlatHub, it would be appreciated: https://github.com/flathub/flathub/pull/2124 19:57:21 It seems like BigmenPixel0 hasn't been able to get ahold of any notable devs 19:57:35 "[Cant contact with developers ] I am an upstream contributor to the project. If not, I contacted upstream developers about submitting their software to Flathub." 20:41:56 I'm not sure what the question is. To ignore arm, just don't build it. The Makefile has several targets for various arches, just make tje ones you're interested in. 22:05:39 I'm mainly referring to the checklist FlatHub, with this particular item: I am an upstream contributor to the project. If not, I contacted upstream developers about submitting their software to Flathub. 22:06:17 moneromooo: There's no issue with you having Monero CLI+GUI distributed via FlatHub, right? 22:06:54 Is there any reason to believe they would not abide by the licence ? 22:06:55 s/checklist FlatHub/PR checklist FlatHub has 22:07:28 None, the Flatpak manifest itself is just pointed at the binary on getmonero basically w/ a flatpak wrapper 22:08:55 ( https://github.com/flathub/flathub/pull/2124/commits/de305dd9390d12c68a2b6d535f9ec51258131a4f#diff-a1a1124a775bdbeb042b418e88f77c36e0b832e120d35e222c128f5d18064c9a ) 22:09:21 If it's just permission, this is open source software. As long as you abide by the license, you can redistribute it freely. 22:09:34 Ok, thanks for the comments 22:18:00 is the flathub thing only a licensing issue or is it also that they want repo maintainers to give blessing that the software isnt being jacked with during packaging? 22:38:47 xmrscott[m]1: I don't remember anyone reaching out re flatpak 22:50:34 selsta: Yeah, have no clue how they reached out 22:52:06 Partly the latter. I think mainly they just want an ack that the developers are aware of the distribution through FlatHub being a thing 22:54:39 So that if the developers get messaged by users using FlatHub, it doesn't completely come out of left field