(but it does look like java people just like making everything complicated)
2024-01-11 01102, 2024
yvanzo
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).
2024-01-11 01144, 2024
yvanzo
reosarevok: It isn’t a trivial, because the old version was in the JDK, not the new one.
2024-01-11 01142, 2024
yvanzo
(It’s in the section about JAXB.)
2024-01-11 01153, 2024
reosarevok
Oh, yeah, I remember that now
2024-01-11 01100, 2024
yvanzo
Also we use JAXB 2 at the moment, but the latest version is 4.
2024-01-11 01127, 2024
reosarevok
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
2024-01-11 01100, 2024
reosarevok
In theory, that wouldn't seem super difficult, but is the problem that things are now updated at different rates so versions clash?
2024-01-11 01143, 2024
yvanzo
Yes but hopefully this transition period seems to be over for some time already.
2024-01-11 01141, 2024
reosarevok
Ok, but still the latest versions don't really work
2024-01-11 01118, 2024
reosarevok
Do we know why?
2024-01-11 01122, 2024
yvanzo
They should, we just don’t combine them correctly.
2024-01-11 01154, 2024
reosarevok
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?
2024-01-11 01153, 2024
yvanzo
I don’t know if it is needed to have the same JAXB version everywhere.
2024-01-11 01149, 2024
yvanzo
(For example, does JAXB 4 implementation supports JAXB 2.3 specs?)
(it "drops compatibility with JAXB 1.0" but that shouldn't matter)
2024-01-11 01132, 2024
reosarevok
Wonder why they keep 2.3 alive though then
2024-01-11 01124, 2024
yvanzo
Remember that there is a specification and many implementations.
2024-01-11 01129, 2024
reosarevok
Argh :)
2024-01-11 01117, 2024
yvanzo
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#dis…
2024-01-11 01121, 2024
yvanzo
Just to say: don’t consider the current dependencies as an ideal of how it had to be used.
2024-01-11 01108, 2024
reosarevok
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?
2024-01-11 01129, 2024
reosarevok
(for example, that same last PR that removes some seemingly unneeded dependencies, which would hopefully make things less confusing)
2024-01-11 01116, 2024
yvanzo
Each PR has its own issues, but there is something to learn from each too.
2024-01-11 01137, 2024
reosarevok
Ok, so can we try to leave comments in the different PRs specifying the issues? :)
2024-01-11 01154, 2024
reosarevok
Then we can try to fix some of those and see if we end up with something that does just improve things
2024-01-11 01100, 2024
yvanzo
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.
2024-01-11 01129, 2024
yvanzo
reosarevok: We can use the wiki page for summary notes instead, because the changes are across 3 repositories at once.
2024-01-11 01111, 2024
reosarevok
So we're certain we can't just improve one repo fully first, then the others, because the compatibility will break, then?
2024-01-11 01127, 2024
yvanzo
Mostly, yes.
2024-01-11 01149, 2024
reosarevok
Argh.
2024-01-11 01133, 2024
reosarevok
So, given you've tried "update all fully and fix stuff" and it didn't seem particularly trivial (otherwise you would have done it :) )
2024-01-11 01149, 2024
lusciouslover has quit
2024-01-11 01157, 2024
reosarevok
It sounds like "update one version of a thing, see if it still works, repeat" might be the least horrible option?
2024-01-11 01100, 2024
lusciouslover joined the channel
2024-01-11 01145, 2024
yvanzo
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.
2024-01-11 01116, 2024
yvanzo
reosarevok: Ok, I think we can try this.
2024-01-11 01109, 2024
reosarevok
What seems like the easiest place to start from?
2024-01-11 01138, 2024
reosarevok
mmd-schema again?
2024-01-11 01139, 2024
yvanzo
JDK8 to 11 is a big step, 11 to 17 should be straightforward.
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.
2024-01-11 01108, 2024
lucifer
the `metabrainz/mb-solr` docker image is based on `metabrainz/solr` docker image.
monkey: Thanks re. dual Spotify submissions! How are you feeling by the way? Hope you didn’t have too awful a time
2024-01-11 01123, 2024
lucifer
aerozol: afaiu, the issue is from the mobile app not web brainzplayer?
2024-01-11 01137, 2024
aerozol
lucifer: both
2024-01-11 01154, 2024
lucifer
ah oka
2024-01-11 01154, 2024
aerozol
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
2024-01-11 01109, 2024
lucifer
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
2024-01-11 01117, 2024
aerozol
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
2024-01-11 01143, 2024
lucifer
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
2024-01-11 01156, 2024
lucifer
it was easier to show on mayhem's laptop during the summit.
2024-01-11 01107, 2024
bitmap
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?
2024-01-11 01108, 2024
lucifer
once i have a workable solution, i'll share the link with you.
2024-01-11 01116, 2024
aerozol
Okay cool, as long as we can still change workflow! Thanks lucifer
2024-01-11 01129, 2024
bitmap
I'm around tomorrow too but maybe lucifer needs some time to update the development document
2024-01-11 01133, 2024
lucifer
yup, ofc not deploying to prod without sign off.
2024-01-11 01136, 2024
aerozol
And great job, I know this is a boring one
2024-01-11 01114, 2024
lucifer
bitmap: tomorrow or mon/tue both work for me.
2024-01-11 01133, 2024
bitmap
ok cool. does this also relate to the oauth migration?
2024-01-11 01149, 2024
yvanzo
bitmap: no worry, it was just about planning a meeting about oauth.
2024-01-11 01106, 2024
yvanzo
bitmap: I just had a working session about solr with reosarevok.
2024-01-11 01133, 2024
bitmap
yeah, I was trying to catch up on the conversation, I'd like to help with testing the solr changes too
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?
2024-01-11 01144, 2024
bitmap
elomatreb: if you know how to connect with psql, then select last_replication_date from replication_control;
2024-01-11 01157, 2024
petitminion has quit
2024-01-11 01111, 2024
elomatreb
ah yeah, that's exactly what I wanted
2024-01-11 01112, 2024
elomatreb
thanks
2024-01-11 01134, 2024
petitminion joined the channel
2024-01-11 01133, 2024
aabbi15 joined the channel
2024-01-11 01153, 2024
petitminion has quit
2024-01-11 01130, 2024
petitminion joined the channel
2024-01-11 01121, 2024
abhis_ joined the channel
2024-01-11 01152, 2024
aabbi15 has quit
2024-01-11 01118, 2024
petitminion has quit
2024-01-11 01129, 2024
abhis_ has quit
2024-01-11 01115, 2024
outsidecontext
aerozol: thanks
2024-01-11 01102, 2024
aerozol
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)
2024-01-11 01143, 2024
opal has quit
2024-01-11 01156, 2024
opal joined the channel
2024-01-11 01129, 2024
zas
aerozol: not sure to understand the question, but isn't https://picard-docs.musicbrainz.org/en/config/opt… "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
2024-01-11 01123, 2024
aerozol
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
