#metabrainz

yes indeed.

Some changes in some stuff made some other stuff temporarily incompatible.

understood.

So do we have any version of anything we're relatively confident on rn?

The move of J2EE to EE4J made it worse because it changed the naming of packages too.

I expect the naming is a trivial fix though? Unless there's more to it than that

[listenbrainz-server] 14dependabot[bot] opened pull request #2709 (03master…dependabot/pip/jinja2-3.1.3): Bump jinja2 from 2.11.3 to 3.1.3 https://github.com/metabrainz/listenbrainz-serv...

(but it does look like java people just like making everything complicated)

reosarevok: It’s either you upgrade gradually or by part (as in the first try), or you upgrade everything at once (as in the second try).

reosarevok: It isn’t a trivial, because the old version was in the JDK, not the new one.

(It’s in the section about JAXB.)

Oh, yeah, I remember that now

Also we use JAXB 2 at the moment, but the latest version is 4.

But Java is always confusing to me. So, this used to be mostly bundled in, but no longer is, so we need to specify the stuff we need separtely

In theory, that wouldn't seem super difficult, but is the problem that things are now updated at different rates so versions clash?

Yes but hopefully this transition period seems to be over for some time already.

Ok, but still the latest versions don't really work

Do we know why?

They should, we just don’t combine them correctly.

So, is JAXB 2 even still supposed to be supported, or should we really be moving to 4? The page does not mention JAXB 4 so I understand that means 2 is still fine and changing that can be left for later?

I don’t know if it is needed to have the same JAXB version everywhere.

(For example, does JAXB 4 implementation supports JAXB 2.3 specs?)

Also there is a connection between JAXB version and Jakarta EE version: See https://jakarta.ee/specifications/xml-binding/

JAXB 2.3 seems to be supported in parallel of versions 3 and 4: See https://projects.eclipse.org/projects/ee4j.jaxb...

(All of these links come from https://en.wikipedia.org/wiki/JAXB linked from the page.)

4.0 says "Supports usage of JAXB 2.x schema bindings customizations"

In https://eclipse-ee4j.github.io/jaxb-ri/4.0.1/do...

So that answers that question at least

(it "drops compatibility with JAXB 1.0" but that shouldn't matter)

Wonder why they keep 2.3 alive though then

Remember that there is a specification and many implementations.

Argh :)

For example, the current dependencies (that work) are not necessarily used appropriately. For example it seems that the runtime (so the implementation) might not be needed everywhere: https://github.com/metabrainz/mb-solr/pull/49#d...

Just to say: don’t consider the current dependencies as an ideal of how it had to be used.

So, of all these open PRs, are there any that seem to be an improvement and still work, even if they don't yet migrate everything?

(for example, that same last PR that removes some seemingly unneeded dependencies, which would hopefully make things less confusing)

Each PR has its own issues, but there is something to learn from each too.

Ok, so can we try to leave comments in the different PRs specifying the issues? :)

Then we can try to fix some of those and see if we end up with something that does just improve things

There are two ways to do it: either (a) trying to update dependencies to their latest versions and addressing issues gradually for each step, or (b) trying to update versions gradually for some dependencies that we can make work together confidently thus unlocking some compatible versions of other dependencies.

reosarevok: We can use the wiki page for summary notes instead, because the changes are across 3 repositories at once.

So we're certain we can't just improve one repo fully first, then the others, because the compatibility will break, then?

Mostly, yes.

Argh.

So, given you've tried "update all fully and fix stuff" and it didn't seem particularly trivial (otherwise you would have done it :) )

It sounds like "update one version of a thing, see if it still works, repeat" might be the least horrible option?

lucifer had some success with only updating mmd-schema in 2020 but it's probably outdated now, we also succeeded to updating everything in 2022 but it’s probably outdated too and we don’t know how it worked really.

reosarevok: Ok, I think we can try this.

What seems like the easiest place to start from?

mmd-schema again?

JDK8 to 11 is a big step, 11 to 17 should be straightforward.

yes

So, first we should check whether https://github.com/metabrainz/mb-solr/pull/38 still works?

Without changing anything else

Or have you already made sure it's outdated?

It’s not mmd-schema though.

oh. I'm blind. I saw "2020, lucifer" and I didn't check what it changed 🤦‍♂️

But the mmd-schema PR I see is alastair's from 2022 (https://github.com/metabrainz/mmd-schema/pull/30)

Is that what you were thinking of earlier instead?

zas: unrelated to all this but there's another "plz unblock my IP" email at support for when you have a moment

lucifer: btw, the editor whose LB account you fixed says thanks :)

reosarevok: I'm on it right now

I just found out that the first try uses a different version of mmd-schema. Fixing it.

reosarevok: Ok, fixed it, the only difference is: it was still using the version 0.14.0 of maven-jaxb2-plugin.

lucifer: what do you mean?

lucifer: This image only exists because official Solr images moved to JDK 11 a long time ago, we can just use official images if we switch to JDK 11 or upper.

the `metabrainz/mb-solr` docker image is based on `metabrainz/solr` docker image.

ah awesome then

Official Solr 7 image using JDK 11 is still available: https://hub.docker.com/layers/library/solr/7.7....

monkey: Thanks re. dual Spotify submissions! How are you feeling by the way? Hope you didn’t have too awful a time

aerozol: afaiu, the issue is from the mobile app not web brainzplayer?

lucifer: both

ah oka

lucifer: mayhem: monkey: is that centralized login progress I see? Amazing! But I got dropped out of the loop on this thing as well. If it is implemented and it’s still convoluted I will throw my computer out the window

aerozol: it isn't exactly there yet, it should be simple once everything has been implemented but can be covuluted during the temporary migration period

lucifer: We started looking at the login workflow, but you were going to update me on how it was going? Hopefully the UX is good

aerozol: yup, but to share it with you need to put it on a public ip which is a bit complex to do at the moment

it was easier to show on mayhem's laptop during the summit.

lucifer: reosarevok: yvanzo: sorry I didn't realize there was gonna be a meeting and overslept a bit. would mon/tue work for the login/signup page discussion?

once i have a workable solution, i'll share the link with you.

Okay cool, as long as we can still change workflow! Thanks lucifer

I'm around tomorrow too but maybe lucifer needs some time to update the development document

yup, ofc not deploying to prod without sign off.

And great job, I know this is a boring one

bitmap: tomorrow or mon/tue both work for me.

ok cool. does this also relate to the oauth migration?

bitmap: no worry, it was just about planning a meeting about oauth.

bitmap: I just had a working session about solr with reosarevok.

yeah, I was trying to catch up on the conversation, I'd like to help with testing the solr changes too

bitmap: https://wiki.musicbrainz.org/Development/Upgrad... is meant to be the hub

thanks

bitmap: yes, this is half part of the OAuth migration.

reosarevok: I changed the background color to chocolate, so that every time you change dependencies you get a piece of chocolate.

lucifer: aight, I had some comments/questions about the oauth document that we haven't discussed yet related to compatibility with old applications

makes sense. we can discuss those too during the meet.

sounds good

outsidecontext: I shared the Picard pre-release post on the socials btw

[critiquebrainz] 14dependabot[bot] opened pull request #508 (03master…dependabot/pip/jinja2-3.1.3): build(deps): Bump jinja2 from 3.1.2 to 3.1.3 https://github.com/metabrainz/critiquebrainz/pu...

[metabrainz.org] 14dependabot[bot] opened pull request #454 (03master…dependabot/pip/jinja2-3.1.3): Bump jinja2 from 3.1.2 to 3.1.3 https://github.com/metabrainz/metabrainz.org/pu...

I have a Musicbrainz DB replication setup with musicbrainz-docker, is there a way to get the timestamp of the last replication update from the database?

elomatreb: if you know how to connect with psql, then select last_replication_date from replication_control;

ah yeah, that's exactly what I wanted

thanks

aerozol: thanks

outsidecontext: if you’re still up, is there a Picard setting or script to only set recording level tags/genres for files? I believe currently it puts the album tags on all the tracks, and then also the track specific ones? (this is a question on reddit)

aerozol: not sure to understand the question, but isn't https://picard-docs.musicbrainz.org/en/config/o... "Fall back on album’s artists genres if no genres are found for the release or release group" option enough for this? If it is unchecked, it should only use recording tags/genres

zas: Not quite, that’s going ‘up’ to use artist genres - the question is if you can go ‘down’ to only use recording level genres