#musicbrainz-devel

bah, I wish codereview was smarter about the diffs between diffs :/

(as in I wish I could exclude the things that happen as a result of people pulling in master/beta)

ianmcorvidae: huh…make pot on rika blows up with *** glibc detected *** xgettext: double free or corruption (fasttop): 0x000000000079da90 ***

yeah

gettext is borked as hell on rika :/

I guess the thing to do in that case would be to just run the command for the templates that it's running (that doesn't actually use xgettext, that's just for perl code)

which would be find ../root -path ../root/statistics -prune -o -type f -name \*.tt -print | sort | ./extract_pot_templates | msguniq -s > mb_server.pot;

or direct it into whatever, since you're just testing to make sure the strings end up in there :)

err

yeah that's right, that's *pruning* root/statistics, as it should

yay, that works (after installing a bunch of missing perl modules)

oh, heh

and the <!-- [% %] --> thing works too (but I guess you already knew that or you wouldn't have suggested it :P)

haha

well, I didn't actually try it, but I figured as much :)

hey, the rel editor actually keeps the header intact

:D

I guess it doesn't have the problem the release editor does where sometimes it doesn't know the title :P

thanks to my strategy of "avoid templatetoolkit as much as possible," I did something right then :)

heh

bah, carton plus the po makefile is sort of a terrible combination

have to manually PERL5OPT=-Mlocal::lib in the carton directory to make it work

(or install a second copy of the dependencies outside of carton, which is silly)

heh, wow, that's a twiddly formatting bug in codereview/my browser

the highlighting for the highlighted-because-removed 'n' in 'unnaccent' is covering up part of the 'u'

ocharles: the fix for http://tickets.musicbrainz.org/browse/MBS-5177 is insufficient. it doesn't do anything about the editors who've already removed their email address

ocharles: at least, that's what my testing suggests. if I remove my email address on mb.org (emulating someone who's already removed theirs), I can still edit on beta

ocharles: also if I (as an admin) remove someone else's email address on beta, they can still edit on beta

ianmcorvidae: I never remember how we start this "private" channel in IRC…

jesus2099: /msg ianmcorvidae should do it :)

ah thanks (’-_-`)

hello internet

good morning

nikki: I believe that's a bug fixed by another ticket

(that clearing your email address doesn't clear the confirmation date)

i'll look into that

hm, no, maybe not

nikki: with your first scenario, did you have to re-login to beta?

no

ok, so that bug would be fixed with shipping it to production

how?

because when you clear your email address on musicbrainz.org it sets your email details in the session

but currently it doesn't set the confirmation date, so beta doesn't pick it up

but the general problem is that we store stuff in the session and that leads to duplicate state that we forget to update, so I may just improve that patch to stop doing that

your second bug with the admin stuff is certainly still going to happen with this patch

so you're saying once this ships to master, everyone who's still logged in after removing their email address at some point in the past will suddenly not be able to edit any more, even if they don't touch their profile?#

no, they would still have to log out and back in

then the bug is not fixed

well, not quite that explicitly

their session needs to expire

they will 'log in' with a cookie too

i don't know how long sessions last at the monte

moment*...

but I agree, fixing this more robustly is a good idea

Pretty much forever

I haven't had to log in in aaaages

do you have 'remember me' checked?

Sure

that'd be why then

Doesn't everyone?

your session can expire, but the site will still automatically log you in

Oh

But it wouldn't let them edit if they have this

I see

when their session expires, the site would log them back in, but pick up the cleared email address. i imagine this much already happens though

on beta or on the main site?

I have a guy whose mail address we removed years ago, yet he is still doing the same shit edits we removed the mail for to begin with

So certainly not on the main site

ianmcorvidae: hey I found another WOWMG REGRESSION again ! (not)

Project musicbrainz-server_beta build #98: SUCCESS in 13 min: http://ci.musicbrainz.org/job/musicbrainz-serve...

ollie: Revert "Merge branch 'mbs-5177' into beta"

aw, you changed the title.

heh

grmbl html

heh ocharles you seem to have asked some of my questions for me on Web Service Moticvation Doc

ijabz: :)

ok, I'm off now - it's Last.fm sports day :)

ping ianmcorvidae

lol @ ocharles

chatting through google docs is kind of silly :)

er, I guess that's ijabz. Silly cursor colours.

I guess that's why we all picked text colours ;)

kepstin-work chatting through doc mesa things get recorded in the right place

hmm. if you want to show up in the viewers list by name, you can share the document with yourself, apparently.

hello

in the web service, is it possible that a recording has a global artist-credit, and then a different one (maybe with a "feat." added) in one of its track-lists?

i need to know this as i'm writing a massive update to amarok tagger

so far i'm fetching artist information from the global tag (while searching for a recording, the main <artist-credit/>)

but i've seen that in certain cases there are also <artist-credit/> tags defined inside the <track-list/> tags (i.e., per release)

but, so far, nothing changed (mostly nothing... not the artist ids nor the "joinphrase" attributes)

ideas?

avilla, if I understand your question, yes. An artist credit on a specific tracklist may not match the artist credit on the associated recording.

ok

That will be true especially in classical.

can it be that it features different artist IDs, or the difference can only be, for example, in the language of the "joinphrase" attr or in the order of the artists?

ah

in classical, for instance, the track artist will generally be the composer, while the recording artist will be a list of performers.

uhm

not the opposite?

track is per release

recording is general

Sure, but the performer for a recording will always be the same

(works are more general, and have an actual composer credit)

so there will be multiple "symphony n. 5", one per performer

but in the album it will be credited to beethoven

right?

Yes