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

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?

snipa is gone, luigi1111 is doing interim until new maintainer is confirmed

I think we talked about this already, we only merge bug fixes to branch.

binaryFate: i didn't know. Thanks for the update

selsta: I thought that was only temporary

and after some time branch and master would have been even again

Master has all the newest features + bug fixes, branch has bug fixes

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

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.

mmmh the readme definitely needs a general refresh.

I usually make sure to comment on PRes that also need to get submitted against branch

How important is it to be able to spend pre-triptych and triptych outputs in the same tx ?

if they can't be spent together it'll be possible to tell when someone spends a pre-triptych output, forever and ever

but it's kind of the same situation as with pre-RingCT outputs?

True. But since it's also possible otherwise, it doesn't matter.

is it technically possible to spend them together?

Yes.

I think Monero philosophy is to leak as little data as possible and allowing to spend them together leaks less data

Why 5?

But does it complicate implementation a lot?

Depends how you define "a lot" I guess.

Any research needed for this?

Doing it.

one "if...else" somewhere in the code or bigger refactoring?

Lots more changes.

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

pre-RingCT vs RingCT had much smaller scale

Maybe I'm missing your point, so give a detailed example.

you selection for ring members will be limited to only triptych transactions after the fork, if you spend new outputs

maybe it doesn't matter much

Yes.

This is not relevant to whether it's important to be able to spend T and !T outputs in the same tx though.

forget everything I said :D

I thought about ring selection the whole time

spending them together is not important

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.

not a problem if it has to be done only once to convert to Triptych

it can even be automated in the wallet

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.

if it keeps like that after Triptych each spend will eventually convert 2 or more outputs

maybe wallet could analyze all outputs after Triptych fork and suggest a user to churn all pre-Triptych outputs together or separately?

I would not want that myself.

The only reason I see is if you want to be prepared to make a large spend without notice.

it really depends on the set of outputs. People who use it actively usually have many outputs

so they don't run into "not enough funds in a single output" situation you described

but for that situation wallet needs to print something meaningful and suggest auto-churn?

Yes, that sounds like a good idea.

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)"

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 : paste.debian.net/1186208 - apt remove python-minimal && make release-static restores a successful build

(v0.17.1.9)

Your libzmq is built with symbols that clash with libsodium. Rebuild libzmq with the appropriate flags. Something like external-libsodium or whatever it is.

Or no-tweetnacl maybe. It just needs to use libsodium, not its internal conflicting code.

1thanks

but why does having python installed make this happen?

You might see clues in the cmake log. It might find different libs.

will check that

If you make with VERBOSE=1, it will also print the compile/link command lines. Spot the differences.

vtnerd: could you take a look at 7389? you reviewed the previous related PRs

#7358 had been updated

“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

If a notable developer (e.g. moo) can comment on their support for getting Monero into FlatHub, it would be appreciated: flathub/flathub #2124

It seems like BigmenPixel0 hasn't been able to get ahold of any notable devs

"[Cant contact with developers ] I am an upstream contributor to the project. If not, I contacted upstream developers about submitting their software to Flathub."

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.

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.

moneromooo: There's no issue with you having Monero CLI+GUI distributed via FlatHub, right?

Is there any reason to believe they would not abide by the licence ?

s/checklist FlatHub/PR checklist FlatHub has

None, the Flatpak manifest itself is just pointed at the binary on getmonero basically w/ a flatpak wrapper

( flathub/flathub #2124/commits/de305dd9390d12c68a2b6d535f9ec51258131a4f#diff-a1a1124a775bdbeb042b418e88f77c36e0b832e120d35e222c128f5d18064c9a )

If it's just permission, this is open source software. As long as you abide by the license, you can redistribute it freely.

Ok, thanks for the comments

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?

xmrscott[m]1: I don't remember anyone reaching out re flatpak

selsta: Yeah, have no clue how they reached out

<kinghat[m] "is the flathub thing only a lice"> Partly the latter. I think mainly they just want an ack that the developers are aware of the distribution through FlatHub being a thing

So that if the developers get messaged by users using FlatHub, it doesn't completely come out of left field