#metabrainz

Thanks bitmap.

The other problem is that with Ubuntu 24.02 docker-compose produces the same issues I saw in #285 however if I remove the old docker-compose and install docker-compose-v2 I have to run it was "docker compose" which seems to break a lot of other things.

admin/create-amqp-extension: line 29: docker-compose: command not found

create-amqp-extension: cannot install: the Docker Compose service 'indexer' is not up

nelgin (IRC): try with `DOCKER_COMPOSE_CMD='docker compose' admin/create-amqp-extension`

in general you should be able to prefix any of the commands with that environment variable to get them working

(and there are plans to make docker compose v2 the default soon, IIRC)

I'll give that a try thanks. Also, how would I get that missing data if I didn't get it in the initial import?

Using the environment variable worked thank you.

groups: cannot find name for group ID 153

I'm seeing a bunch of these also

<sparksphereinspi> "Hey @jasje, I made the fix for..." <- I wasn’t facing any duplicate events issue but events just not loading after feb 19 + events disappearing when refreshing. Please look into these issues before initiating review.

WARNING: amqp could not commit tx mode on broker 1, reply_type=2, library_errno=4

Any ideas on this one during replication? There's a couple of issues, #142 but doesn't seem relevent since all my dockers are up and not #!50 since this isn't an upgrade.

hmm

=WARNING REPORT==== 27-Mar-2025::05:56:06 ===

closing AMQP connection <0.1358.0> (172.19.0.4:42368 -> 172.19.0.2:5672, vhost: '/search-index-rebuilder', user: 'sir'):

client unexpectedly closed TCP connection

I’ve fixed the issue on my local setup. Can you check if there facing any other issues?

s/facing//

holycow23: ansh looking through the stats proposal, some of the stats are suggested to be implemented directly on MB/LB db. we shouldn't be doing that. all the stats should be generated on the spark cluster unless there is a very strong reason not to do so.

mayhem: for notifications, i think we should skip BU and CB integration. just integrate them in LB. we intend to get rid of CB frontend at some point and then for just LB there is no need of a separate BU library.

<lucifer[m]> "holycow23: ansh looking through..." <- I’m not entirely sure yet, but my plan is to generate all of these items directly on the Spark cluster. They will leverage MB and LB for certain properties, though they will otherwise operate independently on Spark itself. If there’s anything specific that needs adjustment or further development, please let me know.

holycow23: ah cool then, i misunderstood it from the proposal.

[musicbrainz-server] 14reosarevok merged pull request #3497 (03master…MBS-10563): MBS-10563: Add autoselect + sidebar for AWA URLs https://github.com/metabrainz/musicbrainz-serve...

<lucifer[m]> "mayhem: for notifications, i..." <- agreed on CB, torn on BU. What if another python project comes along? move it then?

[@mayhem:chatbrainz.org](https://matrix.to/#/@mayhem:chatbrainz.org) yes move it later then

mayhem: about the notifications document (https://docs.google.com/document/d/1jK2OreDzYq_...), the service that sends emails would be on MeB side right?

yes.

and it would call the MB mailing service?

yes, that was my plan.

so then the digest settings will also need to be stored in MeB?

yes.

instead of in each project that is. okay cool.

though it was floated that people might want different settings for different projects.

it will become simpler once we migrate rest of user data to MeB from MB but should be doable even now.

but I have no idea how many people want this.

i was thinking one digest email for all projects.

agreed

let's start simple i think and go with unified settings and later split it if needed.

mayhem: in that case do we need to store the email in the notification table, can't we just get it from users table too?

we don't have a users table at the moment but we will have it in the future.

when data has been migrated from MB to MeB.

ideally we would not duplicate it, but look it up

yup makes sense

I see we already have two proposals for the subsonic project, which is great.

i haven't seen any

did we say that level of UI work (to setup a subsonic server) is ok?

except the message in the LB channel just a few mins ago

one was directly submitted to the gsoc site, the other will be posted on community soon.

i see, i'll check the gsoc site but unless the contributor shows up here we aren't considering it right?

correct, and I have not seen this person here yet.

but the proposal isn't terrible, so we'll see.

do you want to email them and ask them to show up here in time?

yeah, will do.

cool

as for the UI, i think the only user facing part would be forms to create/edit/delete subsonic servers?

integrating in BP is frontend work but not UI specifically.

imo the proposal is very general, and does not reference existing LB implementations so my issue is how to know if all the content was not just generated by some llm/ai.

<lucifer[m]> "as for the UI, i think the..." <- yes

<lucifer[m]> "integrating in BP is frontend..." <- ah ok. not sure I understand, but that sounds "its ok" enough. :)

lucifer[m]: the one on the gsoc site?

mayhem[m]: i mean its typescript/react code but doesn't require much css

mayhem[m]: yup

Not much in terms of 'design'

yup that

ok, thanks for the clarification.

OMG. ansh : after hours spent on debugging the issues with DOMPurify, and hours again with tinycolor, I finally found the one stupid config line that allows us to import ESM modules when running the test suite (i.e. in Node):