#musicbrainz-devel

dhess: I bet you don't have the mbdump-derived tarball imported

warp: I guess we can just do a basic "is it up" test, though I actually have one of those set up with pingdom

ianmcorvidae: right, checking a publicly visible URL wouldn't need anything on the machine itself.

luks: http://pastebin.com/imQuZ3Qc

warp: I suppose things like critical processes matter too

warp: making sure elasticsearch and the geordi FCGI script is running in other words

ianmcorvidae: is that running through daemontools?

warp: it's not, no

it probably should be

this is from a user emailing support@

usually daemontools keeps everything running, and stuff doesn't suddenly break as long as you don't touch it.

da fug?

Indeed

ruaok: nice

not sure what to say.

That sounds like a verification mail thing

he can log into his account.

ya, that might be it.

Well, it *somehow reminds me* of a verification mail thing :p

"sounds like" is too kind

But still

lol

ianmcorvidae: http://jsbin.com/itehel/1

that's the output with the change. I'm not sure what I'm looking for so I dunno if the stderr is included in the dump

dhess: it should be in the console where you started the server

yeah ok

presumably you called 'plackup <etc>' somewhere, it'll be in that :)

I should get some sleep. goodnight #musicbrainz-devel!

nn warp

ruaok: tell him to check his spam folder, if there's nothing there to enter his mail again on http://musicbrainz.org/account/edit

on it, reosarevok

Ok

We really should write a template for this case

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

another HUGE SUCCESS

although it feels like rewriting more or less the same we say when telling them about verification mails

But I guess people don't read the site but do read answers to their mails :p

reosarevok: or make the UI more clear so we dont get these emails in the first palce

just waiting for pastebin...

screw it, I'll use pastebin.ca

ianmcorvidae: http://pastebin.ca/2311633

ruaok: lol. Ok.

ruaok: we do have "Your profile has been updated. We have sent you a verification email to exampleish [at exampleish.co.uk.] Please check your mailbox and click on the link in the email to verify the new email address" which we tell users when they add an email through account/edit

Buuuut it seems we don't mention anything like that from /register

ya, but stupid users can outwit us there. :)

djce: hi. bai. zzz

heh

dhess: okay, yeah, so it's failing to load the release group, as I thought

not sure why not though -- I'd guess the collate extension thing though, it may dislike you using a different version of gcc than was used to compile postgres?

ianmcorvidae: how can you tell it's failing to load the release group?

ianmcorvidae: oh, I suppose because the release is defined

dhess: well, it tries to the line above that one, but there's no release group in that output to STDERR, just the release group ID (which is always loaded, since that's in the release table)

basically because 'release_group_id' => 352638, is the only reference to a release group

ianmcorvidae: sorry, just to be sure I made that hack correctly, you wanted me to do this, right?

(small flood coming)

$c->model('ReleaseGroup')->load($release);

use Data::Dumper qw( Dumper );

warn Dumper($release);

$c->model('ReleaseGroup')->load_meta($release->release_group);

yeah, that's right

that last line there is the one that's failing, and it's saying that it's getting no object

right

which would be because the release group failed to load from $c->model('ReleaseGroup')->load($release); (which is what would ordinarily do that)

ianmcorvidae: so if the collate extension is the problem, assuming I recompile, do I need to drop the db and re-import?

or is the collation done at runtime?

uh... I *think* you could maybe do it without needing to reimport, I'm not sure about that

ianmcorvidae: BTW, here is the error I get when compiling with gcc-4.4 on Debian sid:

$ CC=gcc-4.4 make -e

-I/usr/include/tcl8.5 -c -o musicbrainz_collate.o musicbrainz_collate.c

cc1: error: unrecognized command line option "-fexcess-precision=standard"

make: *** [musicbrainz_collate.o] Error 1

which is odd

yeah

I doubt Debian compiled postgresql-9.1 in sid with an old version of gcc in any case. What's the issue with the collate extension and gcc-4.6?

I don't know of any particular issue, I just assume it should be done with the same version as the postgres/icu packages

mostly I'm not sure exactly what's going on, heh

ianmcorvidae: it's easy enough for me to rebuild this MusicBrainz server VM from scratch. Which version of Ubuntu are you guys using on production servers?

No particular reason I need to use Debian sid

we're actually on 10.04, heh, wich a hand-compiled postgres -- I'd generally recommend using 12.04 though, there's also a PPA that will have a lot of the dependencies and things

a mb server ppa?

this one? https://launchpad.net/~luks/+archive/musicbrain...

no, not sure what that one is

that's luks's, presumably :)

ah there it is

ok I'll use that

https://github.com/metabrainz/vagrant-images also

I tried the ova, had problems getting nginx going with it

decided I'd just build my own

so much for that :)

Anyway I'll try with 12.04. Do you recommend I use psql-9.1 or 8.x with that?

use 9.x whenever possible, 8.x is probably going to stop being supported soon

ok cool

thanks for your help!

sure, good luck getting it working :)

cya

hello

Project musicbrainz-server_master build #370: STILL FAILING in 29 min: http://ci.musicbrainz.org/job/musicbrainz-serve...

Yippie, build fixed!

Project search_server build #203: FIXED in 1 min 47 sec: http://ci.musicbrainz.org/job/search_server/203/

woo

\o/ hawke_1, reoafk: Updated Ubuntu and Windows binaries: http://pi.ockmore.net:19048/download

all code on github :)

Ben\Sput: did you delete the bad images?

and all source on the downloads page updated

hawke_1: no, not yet

hawke_1: however, if just the thumbnails are bad, rescanning the audio will automatically fix them

oh, hawke_1: haven't pulled your mutagen.File code yet though

you can probably cut/paste it into the new scanner.py for now though

and yeah, a lot of yours are just corrupt thumbnails, so rescanning will fix them :)

Ben\Sput: I’m just running off my own fork anyway.

Looks like it can’t find waveplotimager though

oh, duh

I didn’t copy it there.

:P

it looks in same directory now, not subdirs

Should probably error properly instead of giving a traceback though

if it doesn't find it, it uses path

yeah i was going to catch that, but forgot

would it be feasible to have it check for the existence of the waveplot before calculating it?

I assume that’s the time-consuming bit

i was acta

...

i was actually just thinking about that

it's quite difficult, because you can't know if it exists until you've calculated it

once we have track ids, I could see if there's one already there

How’s that?

I could also generate thumbnails first, and check the larger thumbnail, which may be quicker

well, I'd get the track id, look it up on waveplot, and see if there's a plot attached

yes, that seems right

(aside from false/bad submissions)

I could probably do a similar thing with release/disc/track now

yeah

hawke_1: although then we'd want to somehow mark that on the site, so it gets replaced by a future scan

How would you know? :-p

idk :P magic

I think the only real way is similar to what acoustID does with submission counts

yeah could do that

it should probably be that it only counts submissions from each editor once though

anyway, i'm off, is it uploading and everything now?

also, when it says WavePlot already submitted... blah blah blah, it's also updating thumbnails then if they're corrupt