The Wayback Machine - http://web.archive.org/web/20150915101853/http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-01/2012-01-03.html

IRC log of musicbrainz-devel on 2012-01-03

Timestamps are in UTC.

00:04:14 [ruaok]
ruaok has joined #musicbrainz-devel
00:22:11 [nikki]
* nikki sighs
00:22:35 [nikki]
I'm getting errors about musicbrainz_collate not existing
00:26:31 [ruaok]
did you install it?
00:26:35 [nikki]
yes
00:26:47 [nikki]
at least, I don't see any errors saying that it didn't install when I pasted the commands
00:27:34 [ruaok]
woo!
00:27:37 [ruaok]
32gb. :)
00:27:47 [ruaok]
nikki: do it again
00:28:48 [nikki]
I did, I also restart postgres with no luck :/
00:30:44 [ruaok]
what is the error?
00:33:23 [nikki]
http://pastebin.com/vJXniq5L
00:36:02 [ruaok]
in PG, is musicbrainz_collate shown when you do \df ?
00:36:54 [nikki]
no :/
00:37:07 [ianmcorvidae]
hm
00:37:14 [ianmcorvidae]
have you compiled it before this install?
00:37:29 [nikki]
what counts as an install?
00:37:44 [ianmcorvidae]
I sometimes have the issue of it not making a new version after libraries update (well, icu) when I do 'make'
00:38:19 [ianmcorvidae]
was there a .so, .o, etc. in the musicbrainz_collate directory when you started this process, potentially linked to an old version of icu?
00:38:31 [ruaok]
ianmcorvidae: did you pick a server name yet?
00:38:39 [ianmcorvidae]
ruaok: I have not, no
00:38:58 [ruaok]
ianmcorvidae: http://wiki.musicbrainz.org/User:Nikki/Server_names
00:38:58 [nikki]
I've just been pasting the commands from the install file, so I guess not
00:38:59 [ruaok]
do it!
00:39:03 [ruaok]
see Not in use yet.
00:39:25 [ruaok]
and are you willing to admin a box where mb contributors can have their sandboxes?
00:39:40 [ruaok]
because I'm about to make that a reality.
00:39:52 [ianmcorvidae]
I can admin that, sure
00:40:37 [ruaok]
sweet.
00:40:41 [ruaok]
here is what I am thinking.
00:41:01 [ruaok]
I'll put together an 8GB, quad core box with 1TB of RAID-1 storage for this.
00:41:16 [ruaok]
if we need another proc or more ram we can add that, but I have feeling that wont be needed.
00:41:43 [ruaok]
but: we're not going to back that machine up and it will live *outside* the firewall at MB.
00:42:01 [ruaok]
so, people should not do anything on the box that they really care about.
00:42:14 [ianmcorvidae]
or at least, they should back it up themselves :)
00:42:16 [ruaok]
it should primarily be used as a box to push stuff to for other to look at.
00:42:18 [ianmcorvidae]
but yes, sounds good
00:42:42 [ruaok]
and if the machine gets compromised, I'll just go over and splat a new OS on it and we start over.
00:43:06 [ruaok]
so now need a name for the box.
00:43:17 [ruaok]
something like papa, for papa smurf.
00:43:23 [ruaok]
he looks out for the other smurfs. :)
00:43:33 [ianmcorvidae]
haha
00:44:56 [ruaok]
opening each server is like opening an easter egg.
00:45:00 [ruaok]
you never know whats inside.
00:45:06 [ruaok]
I just opened a single proc 8GB server.
00:45:08 [ruaok]
funny that.
00:45:15 [ruaok]
* ruaok sets it aside until we have a name
00:45:38 [ianmcorvidae]
cool
00:45:51 [ruaok]
think fast. :)
00:46:01 [ianmcorvidae]
I'm reading over lists of characters from cartoons I like, looking for a good name :)
00:46:24 [ruaok]
awesome
00:46:47 [ianmcorvidae]
too many long-ish japanese names, gotta find something short
00:50:13 [nikki]
oh
00:50:43 [nikki]
there was an error in initdb.pl but it didn't stop it from continuing, so I didn't see it :/
00:52:52 [nikki]
http://pastebin.com/ccDJ3YGM is the error there
00:53:42 [ianmcorvidae]
hm
00:53:54 [nikki]
googling finds chatlogs saying to use a different version of gcc
00:53:59 [ianmcorvidae]
that seems to be the issue; seems like a version mismatch of some sort but
00:54:03 [ianmcorvidae]
ah
00:54:04 [ianmcorvidae]
well
00:54:07 [ianmcorvidae]
try that then :P
00:54:11 [BrianFreud_TO]
BrianFreud_TO has joined #musicbrainz-devel
00:55:03 [nikki]
* nikki notes that she has indeed managed to download the dumps and install them with mbslave before managing to get mbserver setup without any data, as she predicted :P
00:55:38 [ianmcorvidae]
heh
00:58:59 [nikki]
so... how do I make it use gcc-4.4?
00:59:48 [ianmcorvidae]
uh
00:59:57 [ianmcorvidae]
probably edit something like a CC line in the makefile
00:59:58 [ianmcorvidae]
possibly
01:01:28 [ianmcorvidae]
ruaok: also, I think I like 'rika' -- from Rika Furude in Higurashi no Naku Koro ni. Young character, but the series has cosmic resets, which seems appropriate, and she's the one that remembers things across resets, keeps an eye on the others, etc.
01:01:40 [ianmcorvidae]
Shall I edit the page to reflect that? :)
01:02:17 [ruaok]
plz
01:02:26 [ianmcorvidae]
okey-dokey then :)
01:04:23 [nikki]
finally
01:04:57 [ruaok]
20 machines, 184GB ram, 19 CPUs, 1 raid card, 0 drives
01:05:11 [nikki]
isn't ubuntu our recommended distro?
01:05:14 [ruaok]
I better pester them for drives tomorrow.
01:05:16 [ruaok]
nikki: yes
01:05:22 [nikki]
then our install needs updating :P
01:06:28 [ruaok]
submit a patch, pelase
01:06:48 [nikki]
well I don't even know the "proper" way to fix it
01:07:21 [Mineo]
* Mineo wonders who's giving us all that hardware
01:07:54 [ruaok]
Mineo: I dont think I'm supposed to talk about it. I think they prefer to remain anonymous.
01:08:02 [ruaok]
their parent company might object. :)
01:08:38 [Mineo]
fair enough. say thanks to them anyway :)
01:10:25 [ruaok]
will do. :)
01:18:19 [nikki]
nikki has joined #musicbrainz-devel
02:37:34 [Leftmost]
Leftmost has joined #musicbrainz-devel
05:02:24 [flamingspinach]
flamingspinach has joined #musicbrainz-devel
05:44:21 [reosarevok]
reosarevok has joined #musicbrainz-devel
05:57:19 [ruaok]
d00d.
05:57:24 [ruaok]
that was a tour de force.
05:57:36 [ruaok]
I just chewed my way through the pile of hardware.
05:58:35 [ruaok]
we have 10 new 8 core 16gb ram boxes ready to go. need raid controllers and hard drives.
05:58:54 [ruaok]
the drives are coming. but only a few raid controlelrs.
06:00:22 [ruaok]
ianmcorvidae: your machine got bumped to dual proc / 8 core, 12gb ram, but only software raid
06:07:58 [ruaok]
* ruaok heads to DWNI
06:11:56 [wpl]
wpl has joined #musicbrainz-devel
06:12:01 [wpl]
wpl has joined #musicbrainz-devel
06:53:18 [ruaok]
ruaok has joined #musicbrainz-devel
07:19:48 [reosarevok]
reosarevok has joined #musicbrainz-devel
08:09:30 [bitmap]
* bitmap doesn't see why review board needs to send out an email just 'cause I set a branch name, but okay
08:40:12 [ijabz]
ijabz has joined #musicbrainz-devel
09:06:09 [djce]
djce has joined #musicbrainz-devel
09:06:59 [djce]
djce has joined #musicbrainz-devel
09:16:15 [ijabz]
ijabz has joined #musicbrainz-devel
09:36:04 [ijabz]
ijabz has joined #musicbrainz-devel
10:00:43 [aylex]
aylex has joined #musicbrainz-devel
12:21:43 [ijabz]
ijabz has joined #musicbrainz-devel
12:55:41 [wpl]
wpl has joined #musicbrainz-devel
13:28:12 [warp]
hello!
13:56:39 [reosarevok]
Hola warp :)
14:09:12 [the_metalgamer]
the_metalgamer has joined #musicbrainz-devel
14:20:42 [ocharles]
* ocharles returns too
14:22:45 [warp]
warp has changed the topic to: Next meeting agenda: Week review, MBS-2676 (ocharles), CAA UI (nikki, reosarevok), CAA types (deciding), Picard/Acoustid (http://forums.musicbrainz.org/viewtopic.php?id=3245), pecastro reviews (warp)
14:59:49 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
16:15:46 [hawke_]
hawke_ has joined #musicbrainz-devel
16:21:16 [nikki]
ocharles: any idea why "entity" (line 7) on http://git.musicbrainz.org/gitweb/?p=musicbrainz-server.git;a=blob;f=root/release_group/merge.tt;h=d9465262c650613383db604815358015c66381b8;hb=HEAD doesn't contain the release group type?
16:22:06 [ocharles]
because there hasn't been a call to $c->model('ReleaseGroupType')->load() in the controller
16:22:07 [ocharles]
one mo
16:23:03 [ocharles]
http://git.musicbrainz.org/gitweb/?p=musicbrainz-server.git;a=blob;f=lib/MusicBrainz/Server/Controller/ReleaseGroup.pm;h=8d5c059ebad292794551148f9dc990e9873f4416;hb=HEAD#l111 if you add a call to $c->model('ReleaseGroupType')->load, like the ArtistCredit call, it should work
16:23:24 [ocharles]
(line 111)
16:24:45 [ocharles]
warp, you broke the build
16:24:57 [ocharles]
the user/register controller test doesn't pass because of the javascript stuff
16:25:05 [voiceinsideyou1]
voiceinsideyou1 has joined #musicbrainz-devel
16:27:12 [nikki]
ok
16:27:17 [nikki]
* nikki will try it
16:28:07 [warp]
ocharles: yay!
16:28:12 [warp]
ocharles: which build? master?
16:28:19 [voiceinsideyou2]
voiceinsideyou2 has joined #musicbrainz-devel
16:28:31 [ocharles]
warp: all of them, I'd guess
16:28:36 [ocharles]
but yea, I'm trying to build master
16:29:40 [warp]
ocharles: so which test exactly is failing?
16:29:43 [bbliss]
bbliss has joined #musicbrainz-devel
16:29:46 [ocharles]
t::MusicBrainz::Server::Controller::User::Register
16:30:42 [warp]
ah, with the spambot protection changes
16:30:59 [ocharles]
si
16:33:04 [warp]
ocharles: I'll look into it now.
16:33:37 [ocharles]
heh, luks broke it too
16:34:43 [reosarevok]
And thus ocharles got vindicated by being the only one who didn't break anything this time
16:34:49 [ocharles]
so far*
16:34:52 [nikki]
haha
16:35:00 [nikki]
quick ocharles, break something! ;)
16:35:43 [ocharles]
don't worry, haven't got to the end yet :P
16:38:35 [reosarevok]
Speaking of which, I apparently broke the JS for automatic YouTube user channel selection
16:38:42 [reosarevok]
* reosarevok should look into it
16:40:39 [bbliss]
mornin' ladies -- working on setting up a local musicbrainz mirror, and having some issues with the perl module that hooks up to memcached.
16:41:15 [bbliss]
this is the error I get:
16:41:19 [bbliss]
[ERROR] Unable to create a new distribution object for 'Cache::Memcached::Fast' -- cannot continue
16:41:40 [bbliss]
and that's when attempting to install Cache::Memcached::Fast with cpan
16:41:57 [bbliss]
the box is a fresh, vanilla ubuntu install, and memcached is installed and running.
16:42:09 [ocharles]
post the entire log from cpan
16:42:43 [luks]
ocharles: what did I break? :)
16:43:03 [ocharles]
luks: your 'rename artist credits' thing adds an edit note that the tests didn't expect to see. you didn't really break anything, but the tests don't pass
16:43:11 [ocharles]
so for now i've just changed the tests to not check any of the checkboxs
16:43:14 [luks]
ah
16:43:38 [luks]
I really need to fix the dev machine to be able to run all the tests
16:44:03 [bbliss]
ocharles: it's kinda big, i'll msg it to you first to make sure it's what you're looking for
16:44:09 [ocharles]
bbliss: gist.github.com
16:44:12 [ocharles]
don't paste it to me
16:44:35 [ocharles]
i'm ignoring you until someone tells me you've put it on gist.github.com or stopped pasting
16:45:47 [bbliss]
gotcha, will do that.
16:46:14 [bbliss]
https://gist.github.com/1555716
16:46:27 [nikki]
ocharles: https://gist.github.com/1555716
16:47:21 [luks]
heh, you know it's bad when even magic is failing :)
16:47:42 [luks]
I'd just "force install Cache::Memcached::Fast" it
16:47:46 [bbliss]
back to hogwards!
16:47:50 [bbliss]
tried it with the -f flag
16:48:08 [ocharles]
that test has failed for me too
16:48:16 [ocharles]
I ended up force installing it too
16:48:38 [ocharles]
http://www.cpantesters.org/distro/C/Cache-Memcached-Fast-CGI.html#Cache-Memcached-Fast-CGI-0.06 seems to indicate it's just use though :/
16:48:52 [bbliss]
well, when i actually run the musicbrainz.pl script to run the server, i get a memcached related error
16:48:56 [bbliss]
i'll make a gist for it
16:49:04 [luks]
personally I just use cpanm -n to not run any tests
16:49:58 [ocharles]
nikki: I think I found my breakage - it's that /artist/relationships bug you reported too :)
16:50:14 [bbliss]
here's the error that i get when running the musicbrainz-pl script: https://gist.github.com/1555731
16:50:37 [bbliss]
I had backtracked that to the failing install of Cache::Memcache::Fast -- maybe it's something else, though?
16:50:48 [luks]
is it installed?
16:50:50 [ocharles]
please paste entire log outputs
16:51:04 [ocharles]
but yes, you haven't got cache::Memcached::Fast installed still
16:52:03 [bbliss]
sure, where's the relevant log file at?
16:53:32 [ijabz_]
ijabz_ has joined #musicbrainz-devel
16:55:11 [ocharles]
right in front of you :)
16:55:20 [ocharles]
assuming you're running script/musicbrainz_server.pl
16:57:47 [reosarevok]
warp, I think you broke beta
16:57:48 [reosarevok]
:p
16:58:04 [reosarevok]
(ISE while going to the tracklist page of the RE)
16:58:29 [reosarevok]
Checked in two releases
16:58:34 [reosarevok]
So probably global
16:58:46 [warp]
yay.
16:58:55 [ocharles]
nikki already reported that
16:59:06 [reosarevok]
Wow, that was fast
16:59:06 [reosarevok]
:p
17:00:19 [nikki]
http://tickets.musicbrainz.org/browse/MBS-4100 and http://tickets.musicbrainz.org/browse/MBS-4106
17:00:42 [reosarevok]
Oh
17:00:45 [reosarevok]
So it didn't just break
17:00:57 [reosarevok]
* reosarevok just saw warp set some tickets to "in beta" and went check
17:01:00 [reosarevok]
(and couldn't)
17:03:36 [bbliss]
ocharles: i see a bunch of .pl files, and a shell script in the /script/ folder by musicbrainz_server, i must be missing something =o
17:04:22 [ocharles]
bbliss: have you installed Cache::Memcached::Fast yet? You can check with 'perl -MCache::Memcached::Fast -e "1"'
17:04:41 [ocharles]
if that works, then you have, if not, then you haven't
17:05:22 [bbliss]
nope, says it can't locate
17:05:36 [bbliss]
even with the -f option, it doesn't seem to install though
17:05:41 [ocharles]
what is "the -f option"
17:05:47 [bbliss]
i.e. cpan -f Cache::Memeached::Fast
17:05:57 [bbliss]
force install, mentioned in the install doc
17:05:58 [ocharles]
right, that's more useful
17:06:14 [ocharles]
so paste the output (to gist.github.com or something) of the above command
17:06:59 [bbliss]
https://gist.github.com/1555826
17:07:22 [ocharles]
of cpan -f...
17:09:08 [bbliss]
kk. sorry for the derp on my part =x not too well versed in perl. here it is: https://gist.github.com/1555833
17:10:14 [ocharles]
hm
17:10:19 [ocharles]
and you're trying to run the server as root too?
17:10:29 [bbliss]
yep, at least for now
17:10:33 [bbliss]
memcached has it's own user
17:10:37 [bbliss]
if that's also relevant
17:10:43 [ocharles]
nah, that shouldn't matter
17:10:53 [ocharles]
echo $PERL5LIB and paste the output of that (here is fine if it's only 1 line)
17:11:29 [bbliss]
output seems to be a blank line
17:12:20 [ocharles]
ok
17:12:32 [ocharles]
and: perl -MData::Dumper -e 'print Dumper(\%INC)'
17:12:41 [ocharles]
sorry
17:12:45 [ocharles]
perl -MData::Dumper -e 'print Dumper(\@INC)'
17:13:25 [bbliss]
https://gist.github.com/1555860
17:14:01 [ocharles]
and perl -MCache::Memcached::Fast -e '1' continues to say it can't find it?
17:14:14 [ocharles]
urgh
17:14:22 [ocharles]
you typed -Mcache::Memcached::Fast before
17:14:30 [ocharles]
case matters
17:15:45 [bbliss]
yep -- still no output, no blank line this time though.
17:16:33 [ocharles]
show me what you're typing and the output
17:16:36 [ocharles]
direct copy and paste
17:16:54 [bbliss]
typing: perl -MCache::Memcached::Fast -e "1"
17:17:18 [bbliss]
output: nothing, just comes back to my shell.
17:17:21 [reosarevok]
* reosarevok would guess " vs ' matters too
17:17:22 [ocharles]
then it's installed
17:17:24 [reosarevok]
Oh, ok
17:17:25 [reosarevok]
:)
17:17:37 [ocharles]
you should be able to start the server now
17:18:28 [bbliss]
yep, that took care of the error!
17:18:32 [ruaok]
ruaok has joined #musicbrainz-devel
17:18:46 [bbliss]
getting new errors now, but i'll see what I can do about fixing them myself before I trouble you any more
17:18:55 [bbliss]
instant-help much appreciated by the way!
17:20:27 [ocharles]
kewl
17:25:11 [BrianFreud_TO]
BrianFreud_TO has joined #musicbrainz-devel
17:26:51 [ruaok]
warp: you should send an invoice. ocharles needs monies
17:27:15 [warp]
ok, will do.
17:27:36 [warp]
* warp needs monies too.
17:27:53 [warp]
ruaok: also, goodmorning! happy new year! etc!
17:28:59 [ocharles]
ruaok: quite badly seeing how last.fm aren't paying me :)
17:29:24 [bbliss]
Woot! Got it all up and running. Last thing I had to do was snag some system XML packages. (libxml-dev, libxml-xpath-perl, libxml-semanticdiff-perl)
17:29:31 [ocharles]
bbliss: awesome!
17:30:15 [bbliss]
is there a particular donation that you guys are in need of right now? my company is pretty generous about helping to support the open source projects we use.
17:30:23 [warp]
ruaok: sent.
17:30:41 [ocharles]
bbliss: money is money, right? :)
17:30:48 [warp]
bbliss: developer time! :)
17:31:07 [bbliss]
if you're in need of some django or node.js development, sure :)
17:31:19 [bbliss]
but i'm not sure you'd want me writing any perl, heh
17:31:56 [ruaok]
happy new year to you too, warp!
17:32:32 [ocharles]
bbliss: we have templates that always need love, along with jquery
17:33:24 [warp]
bbliss: we use fair amounts of javascript in mb-server. and picard, our desktop application to tag mp3/m4a/etc.. is written in python.
17:35:27 [bbliss]
cool -- I found the recurring donation links on metabrainz.org, so I'll hook that up shortly. is there a consolidated "need devs to do this" list or project management system somewhere?
17:35:34 [bbliss]
(github?)
17:35:43 [ianmcorvidae]
bbliss: tickets.musicbrainz.org is our bugtracker
17:36:01 [ianmcorvidae]
which may include things that you could do; there's no other real system though
17:36:06 [bbliss]
excellent. do some work and make a pull request on github?
17:36:13 [ocharles]
bbliss: http://codereview.musicbrainz.org
17:36:19 [ianmcorvidae]
submit to... yeah, that
17:37:12 [ocharles]
warp: http://codereview.musicbrainz.org/r/1558/ with a commit by me works well, and resolves http://tickets.musicbrainz.org/browse/MBS-4099, so I think we should get that into beta
17:37:13 [ocharles]
sound good?
17:38:20 [reosarevok]
* reosarevok is wondering what bbliss' company is, if that's not a secret or something :)
17:38:22 [warp]
ocharles: yeah, sounds fine. ship it!
17:39:21 [ocharles]
warp, ruaok: also, saw https://metacpan.org/module/Tak today - might be handy for scripting our update process
17:39:26 [bbliss]
I work for a radio group, using musicbrainz as part of a setup to use websockets (and other socket.io fallbacks) to do real-time push of track changes, show changes, show announcements, etc.
17:39:33 [ocharles]
(write a tak script, and then run it on each machine)
17:39:42 [ocharles]
bbliss: sounds pretty sweet
17:39:45 [bbliss]
we own about 50 different radio stations
17:39:53 [bbliss]
yep :) it'll all be open sourced when it's all done
17:41:10 [bbliss]
but it gets its data from what's called an RDS box -- if you've ever seen radios in cars that show what artist and track are playing, that's where the input comes in
17:41:49 [ianmcorvidae]
I always wondered how that data got to those players :)
17:41:54 [bbliss]
as that text changes, requests get sent to the web server with the relevant strings, they get looked up on musicbrainz if they're new, etc :)
17:42:07 [bbliss]
yeah, special piece of hardware that connects to the music library management software
17:43:02 [bbliss]
but musicbrainz is a godly resource for these kinds of things, I can even see when a track is only available on a radio-only promo album
17:43:33 [bbliss]
anyhoo, that's the long and short of it :) pm me if you want more details.
17:46:51 [warp]
ocharles: User::Register test fixed and push to master.
17:47:21 [ocharles]
warp: thanks!
17:48:35 [warp]
+ed
17:51:21 [ocharles]
ruaok: is the rate limiter happy?
17:51:35 [ocharles]
the logs today are full of: GET http://musicbrainz.org/ws/1/track/?type=xml&limit=100&release=Medusa&title=Take%20Me%20to%20the%20River caused a warning: send() on closed socket GEN0
17:53:46 [ruaok]
no idea, lets look
17:54:55 [ruaok]
http://stats.musicbrainz.org/mrtg/drraw/drraw.cgi?Mode=view;Template=1262469754.29207;Base=%2Fvar%2Fwww%2Fmrtg%2F%2Flenny_ratelimit-default-wsuapy73-rate.rrd
17:55:09 [ruaok]
looks like its working, though our overall load is down.
17:55:18 [ocharles]
hm
17:55:48 [ijabz]
ijabz has joined #musicbrainz-devel
17:55:57 [hawke_]
Is it just me or is the red part of the graph shifted down from where it should be?
17:56:24 [hawke_]
er, of this graph: http://stats.musicbrainz.org/mrtg/drraw/drraw.cgi?Mode=view;Template=1262469543.28951;Base=%2Fvar%2Fwww%2Fmrtg%2F%2Flenny_ratelimit-default-wsuapy73-count.rrd
17:56:59 [ocharles]
hawke_: if you're expecting it to touch the blue line, that would mean every request had been rate limited
17:57:05 [ruaok]
hawke_: ideally they would be stacked, yes, but that not how they should be.
17:57:24 [ruaok]
I think hawke_ means that the red should be above the green.
17:57:27 [ruaok]
which would make sense.
17:57:29 [hawke_]
Yes.
17:57:32 [ruaok]
red + green = blue.
17:57:38 [hawke_]
Exactly
17:57:41 [ruaok]
not sure if that is possible.
17:57:53 [hawke_]
It would kind of mean that red == blue
17:57:54 [ocharles]
oh, so properly stacked
17:58:04 [nikki]
* nikki giggles at red + green = blue
17:58:07 [ocharles]
lol
17:58:51 [hawke_]
Anyway, it would make more sense to me that way…just sayin’
17:58:55 [ruaok]
the rate limiter looks fine to me.
17:58:59 [reosarevok]
Wow
17:59:08 [reosarevok]
So at some points we're even refusing less than we allow now?
17:59:27 [nikki]
most of the time, it would seem
17:59:45 [reosarevok]
Erm, no
17:59:46 [ruaok]
and at some points we fully meet demand. :)
18:00:04 [reosarevok]
Erm, do we?
18:00:10 [ruaok]
I can't wait to put lolo into rotation. just have to wait for drives.
18:00:10 [reosarevok]
There's always some red
18:00:33 [reosarevok]
Except for a moment there where there's nothing because someone broke the DB
18:00:40 [ruaok]
reosarevok: on the graph with 15 min increments, we always have too much.
18:00:43 [nikki]
the only period where we're not rejecting more than we allow is where the red line is below the green line - the 6 hours around midnight
18:00:55 [ruaok]
but in 10 second chunks I can see in the ratelimiter top, we sometimes can honor all of them.
18:01:15 [ruaok]
like now.
18:01:15 [reosarevok]
nikki: I said less
18:01:20 [reosarevok]
:)
18:01:21 [ruaok]
499 out of 500. :)
18:02:09 [nikki]
reosarevok: your sentence still means the opposite of what you meant to me then :/
18:02:25 [reosarevok]
Why?
18:02:46 [nikki]
if we refuse less than we allow, then we're allowing more than we're refusing
18:02:49 [reosarevok]
I thought we always refused more than we allowed, but now it seems sometimes we refuse less than we allow
18:02:56 [reosarevok]
Well, yes
18:03:02 [nikki]
and if we're allowing more than we're refusing, most requests are allowed
18:03:09 [nikki]
but most requests are actually refused
18:03:28 [reosarevok]
Not at some points :p
18:03:38 [warp]
I would not define "most" as > 50%
18:04:29 [nikki]
warp: fine, fine, "and if we're allowing more than we're refusing, more than 50% of the requests are allowed"
18:04:49 [reosarevok]
Which I thought never happened
18:04:52 [nikki]
and the graph suggests there's only ~6 hours where more than 50% of the requests are allowed
18:04:55 [reosarevok]
Until I now saw it does
18:05:19 [nikki]
but that's the opposite of what you said >_<
18:05:24 [nikki]
* nikki gives up and goes shopping :P
18:05:40 [warp]
:)
18:05:45 [warp]
tschuss!
18:06:03 [reosarevok]
"So at some points (not always) we're even refusing less than we allow now (so we allow a bigger % than we refuse)?"
18:06:07 [reosarevok]
I can't see the problem
18:06:08 [reosarevok]
But well
18:06:09 [reosarevok]
:)
18:08:38 [muesli]
muesli has joined #musicbrainz-devel
18:15:33 [ocharles]
* ocharles goes for a jog and hopes the slow cooker actually cooks his food sometime soon...
18:15:55 [ruaok]
slow cooker… soon?
18:15:58 [ruaok]
#facepalm
18:16:12 [ocharles]
it's been on for 4 hours!
18:16:31 [ruaok]
isn't 6 a usual number?
18:16:37 [ocharles]
yea
18:16:49 [ocharles]
it's on high, so hopefully it'll be ready for just after the meeting
18:52:09 [bbliss]
hmmmm, just one more issue yet -- replication. when I try to run the LoadReplicationChanges script, i seem to be missing some DB tables
18:52:14 [bbliss]
DBD::Pg::st execute failed: ERROR: relation "dbmirror_pending" does not exist
18:52:34 [bbliss]
oh, actually
18:52:40 [bbliss]
maybe i should be sure i grab -all- the dumps
18:52:54 [bbliss]
then those tables will get created. i only grabbed the main ones.
19:00:44 [ocharles]
no, that's cause when you ran initdb.pl, your dbdefs settings said you were standalone, not a slave
19:10:12 [alastairp]
alastairp has joined #musicbrainz-devel
19:25:41 [murdos]
murdos has joined #musicbrainz-devel
19:37:35 [Leftmost]
Leftmost has joined #musicbrainz-devel
19:37:35 [Leftmost]
Leftmost has joined #musicbrainz-devel
19:46:57 [tschwinge]
tschwinge has left #musicbrainz-devel
19:56:41 [ruaok]
ruaok has joined #musicbrainz-devel
20:00:29 [ruaok]
<BANG>
20:00:30 [ruaok]
meeting time!
20:00:42 [ruaok]
I'll go first, since I dont have much to say.
20:00:45 [ruaok]
:-)
20:01:07 [ruaok]
http://www.flickr.com/photos/mayhem/6596198901
20:01:16 [ruaok]
that's the most exciting thing.
20:01:22 [ocharles]
* ocharles hugs them all
20:01:32 [ruaok]
a local company who is moving their infrastructure to EC2 has donated 20 servers.
20:01:50 [ruaok]
these are pretty close to the spec that we spend $16k for 5 of them.
20:02:08 [ruaok]
ours were DDR3, these are DDR2. pretty much the same.
20:02:18 [ruaok]
I spent last night working through the pile and making them to our spec.
20:02:35 [ruaok]
we have 5 machines ready for deployment and
20:02:41 [ruaok]
5 more that need raid cards.
20:02:59 [ocharles]
and the remaining 10?
20:03:03 [ruaok]
and then we have 10 spare boxes that need ram/cpus, but loads more of those are promised to us.
20:03:07 [ocharles]
ah
20:03:11 [ruaok]
those should be coming later.
20:03:28 [ruaok]
I racked and installed one of the machines, lolo, last night/today.
20:03:40 [ruaok]
we can work to bring it into production this week.
20:03:45 [ruaok]
exceiting.
20:03:51 [ocharles]
do we have plans for these machines?
20:04:08 [ruaok]
what is even more exciting is that this donation may actually put us into the black for 2011.
20:04:25 [ruaok]
ocharles: at the rate at which traffic is growing, yes. :)
20:04:48 [ruaok]
one machine will be a sandbox for our community. the others will go toward expanding capacity as we need it.
20:05:09 [ruaok]
k, thats it from me. I'm stoked to not have to worry about hardware for a bit.
20:05:11 [ruaok]
ocharles, next?
20:05:25 [ocharles]
ok!
20:05:30 [ocharles]
* ocharles pops his stew to the side
20:05:52 [warp]
hello!
20:05:55 [ocharles]
ok
20:06:04 [ocharles]
so not much from me last week as somewhat expected
20:06:08 [ocharles]
with christmas and ny etc
20:06:28 [ocharles]
looking at my timesheets, it was just jira stuff, a bit more on the relationship editor, and that's about it
20:06:35 [ocharles]
nothing much to talk about
20:06:55 [ocharles]
so... that's it for me :)
20:07:03 [ruaok]
djce has some stuff to talk about, but will be here later.
20:07:11 [djce]
djce has joined #musicbrainz-devel
20:07:16 [ruaok]
ha!
20:07:18 [ruaok]
hi djce!
20:07:20 [djce]
hi
20:07:23 [ruaok]
wanna go next for our review?
20:07:27 [ruaok]
great timing!
20:07:33 [djce]
now?
20:07:40 [ruaok]
yep
20:07:47 [djce]
Sure.
20:08:07 [djce]
Well, 25th/26th december saw rather high load on asterix, and to a lesser extent astro and pingu too.
20:08:20 [djce]
Turned out to be Proc::ProcessTable
20:08:30 [djce]
load avg was ~ 60 instead of ~ 3, IIRC
20:08:42 [ocharles]
you mean we don't actually have 60 core machines?
20:08:43 [ocharles]
boo
20:08:48 [djce]
still no idea why the load avg was higher than normal
20:08:50 [ruaok]
was that that serious upward spike on astro only?
20:09:06 [hawke_]
ocharles: Is there a demo/mockup of the rel. editor available again/still?
20:09:14 [djce]
but it was obvious that Proc::PT was causing the la to be higher than it needed to be.
20:09:18 [ocharles]
hawke_: not atm
20:10:05 [ruaok]
ocharles: have you integrated djce's emergency patch?
20:10:19 [djce]
(sorry for the delay. just started laptop. fighting firefox)
20:10:47 [ruaok]
or was that patch just a config change?
20:10:47 [ocharles]
no, djce did that himself
20:10:55 [ocharles]
I haven't done anything with it since the bug report
20:10:55 [djce]
ruaok: two changes.
20:11:00 [djce]
one, to DBDefs.pm
20:11:08 [djce]
which AFAIK doesn't live in git
20:11:13 [ocharles]
correct
20:11:18 [djce]
two, to lib/MusicBrainz/Server.pm
20:11:35 [djce]
and on master, the code I commented out wasn't present in the first place
20:11:47 [ocharles]
yep, it's just for debugging production
20:11:48 [djce]
but it was present on whatever HEAD astro had checked out.
20:12:00 [djce]
s/debugging/killing/ I'm afraid
20:12:13 [ocharles]
ok, but it's been there since we launched
20:12:17 [ocharles]
so I'm not sure why it's killing now
20:12:20 [ocharles]
but at least we found it
20:12:23 [djce]
indeed. See my paragraph from about 5 yp
20:12:24 [djce]
up
20:12:28 [ocharles]
yep, saw
20:12:34 [ocharles]
tres odd
20:12:46 [djce]
but whatever, we can't have that running live.
20:12:50 [ruaok]
ocharles: can you please make sure these fixes get into our next release?
20:12:51 [djce]
it's just *horrible*
20:13:10 [djce]
anyway, sysadmin item #2 of 4:
20:13:25 [djce]
various apt-get updates on various servers, and reboots.
20:13:33 [ocharles]
ruaok: well they are in production now, so that's already done
20:13:41 [djce]
iirc, dora, roobarb, pingu, asterix, astro, and lenny.
20:13:47 [djce]
and hobbes, but not all packages.
20:14:07 [ruaok]
right, but incorporating that into our codebase proper. just want to make sure that gets nailed before then.
20:14:15 [ocharles]
ruaok: it needs more discussion before we can do that
20:14:19 [ocharles]
(see ticket for said discussion)
20:14:20 [djce]
It would be good if someone would look over "apt-get upgrade" on hobbes,
20:14:31 [djce]
and see if we can upgrade the remaining packages.
20:14:37 [djce]
so we can catch up.
20:14:40 [ruaok]
ocharles: ok, lets chat after the meeting.
20:14:50 [warp]
djce: I can have a look at that.
20:14:59 [ruaok]
thanks warp.
20:15:03 [ruaok]
djce: what else you got?
20:15:08 [djce]
3 of 4:
20:15:18 [djce]
high load average on astro only, a few days ago.
20:15:25 [djce]
I have no idea what caused it.
20:15:36 [djce]
the high LA persisted even when perl-fcgi was stopped
20:15:43 [djce]
and barely anything else running
20:15:49 [djce]
and nothing swapping.
20:15:54 [ruaok]
three finger salute!
20:15:58 [djce]
A reboot "fixed" it.
20:16:06 [djce]
So, odd and unexplained.
20:16:23 [ruaok]
and totoro crashed on us yesterday. also totally unexplained. :-(
20:16:26 [djce]
#4 of 4: ratelimit-server now lives in git, and has tests (t/*.t(
20:16:27 [djce]
)
20:16:28 [djce]
w00t.
20:16:31 [ocharles]
yay!
20:16:34 [djce]
end of sysadmin news
20:16:35 [djce]
.
20:16:35 [ruaok]
awesome.
20:16:39 [ruaok]
thanks djce.
20:16:42 [ianmcorvidae]
yay, git
20:16:47 [ruaok]
after this meeting you and I should chat a bit about new machiens.
20:16:58 [ruaok]
lolo and rika are racked and nearly ready for action.
20:17:03 [djce]
although the ratelimit-server has yet to be rolled out to live.
20:17:07 [djce]
sure
20:17:08 [ruaok]
lolo, ip .24 is ready for a new server setup now.
20:17:19 [djce]
http://stats.musicbrainz.org/mrtg/drraw/drraw.cgi?Mode=view;Dashboard=1218378978.7925;View=1;Filter=%28astro|asterix|pingu%29.*load for anyone who cares
20:17:31 [ruaok]
warp, how about you?
20:17:58 [warp]
I spent some time just fixing tickets from jira
20:18:54 [warp]
and I spent some time hacking together some way to "clone" our production environment
20:19:01 [ruaok]
oooh!
20:19:11 [ocharles]
sounds pretty cool
20:19:30 [warp]
as in, get a list of installed perl packages + versions, resolve those to urls which download those packages, and then install them in some fashion
20:20:15 [ocharles]
which is slightly reinventing puppet, but it sounds like a quicker solution
20:20:22 [warp]
it's all a bunch of ugly hacks, but hopefully it will work well enough to install the same packages on beta.musicbrainz.org and test.musicbrainz.org
20:20:53 [warp]
(we need that because beta is having weird crashing bugs which are not happening for me on my development machine)
20:21:23 [ocharles]
we really need to fix those bugs soon though, cause it won't help random devs who clone git
20:21:26 [ruaok]
yeah, and with many more machines coming in, we need that support for all of our production boxes.
20:21:57 [warp]
anyway, hopefully I'll finish that soon.
20:22:01 [ruaok]
[ot]: I just a got a notification that a $20k donation is being wired to us. :)
20:22:08 [ruaok]
awesome warp!
20:22:09 [reosarevok]
Yay monies!
20:22:27 [ruaok]
ok, anyone else for review?
20:22:44 [navap]
* navap is here
20:22:50 [ruaok]
hi navap !
20:22:57 [warp]
ruaok: I'll be away this week starting thursday. I should be able to catch up later this month.
20:22:58 [ruaok]
how is your world looking?
20:23:03 [ruaok]
warp: ok
20:23:05 [reosarevok]
nikki seems to have started posting summaries from style in the forum again, if that counts
20:23:47 [navap]
The past few weeks have seen me mainly working on jira things
20:24:21 [navap]
ocharles: What's the status of the MeB donation stuff?
20:24:49 [ruaok]
I think ocharles said that all was done and ready to go.
20:24:56 [ocharles]
yep
20:24:59 [navap]
I've got all the MeB pages into the MB wiki, and the financial reports are all in the git repo
20:25:06 [ruaok]
excellent.
20:25:26 [ruaok]
I think navap and I just need to finish the product stuff and we can release the new meb site.
20:26:27 [ruaok]
anything else navap?
20:26:41 [navap]
Nothing comes to mind
20:26:50 [ruaok]
ok.
20:27:07 [ruaok]
you and I should touch base this week to figure out what you should work on next.
20:27:15 [ruaok]
when you have time, grab me.
20:27:20 [ruaok]
I'm around all week.
20:27:32 [navap]
I'm free for the rest of the day today
20:27:36 [ruaok]
ok, lets move on to new topics.
20:27:48 [ruaok]
navap: I might be busy pushing machines around. lets see.
20:27:58 [ruaok]
MBS-2676, ocharles ?
20:28:07 [ocharles]
this has been sat in code review for ages
20:28:20 [ocharles]
so we need to decide what to do with it
20:28:42 [ocharles]
because we install postgresql from source, I don't know how to proceed
20:28:46 [ocharles]
esp. with beta
20:28:54 [warp]
http://codereview.musicbrainz.org/r/1461/
20:29:43 [ruaok]
is this the issue where plperl needs to be installed?
20:29:46 [ocharles]
yep
20:30:03 [ruaok]
do we *really* need to use perl for this?
20:30:16 [ocharles]
yes, we have to parse json
20:30:17 [warp]
Obviously I'm in favour of shipping it. It isn't much of an extra burden for those people installing postgresql from their distribution (instead of building it from source themselves).
20:30:39 [ruaok]
fine.
20:30:52 [ruaok]
more work for you guys when no one can install mb-server anymore because its too complicated.
20:30:58 [ocharles]
...
20:31:08 [ruaok]
nikki, reosarevok: CAA UI!
20:31:11 [ocharles]
wait
20:31:12 [warp]
:)
20:31:12 [reosarevok]
ruaok, I thought that happened already anyway? :p
20:31:14 [ocharles]
we're not even done!
20:31:18 [nikki]
hi
20:31:25 [ruaok]
ocharles: what else was left?
20:31:33 [ocharles]
working out how to deploy it on our own servers
20:31:39 [ruaok]
reosarevok: I'm trying to not beat a dead horse, but hey.
20:31:39 [ocharles]
it's going to need downtime for totoro
20:31:54 [ruaok]
srsly>
20:31:58 [ianmcorvidae]
aren't we building a hot-fallback DB server? there was talk about that
20:32:04 [ocharles]
yes, we have to rebuild postgresql from source
20:32:20 [warp]
warp has changed the topic to: agenda: MBS-2676 (ocharles), CAA UI (nikki, reosarevok), CAA types (deciding), Picard/Acoustid (http://forums.musicbrainz.org/viewtopic.php?id=3245), pecastro reviews (warp)
20:32:28 [ocharles]
(you don't *have* to do that, as warp said, but that's what we do, so we'll have to rebuild it again)
20:32:32 [ruaok]
this pretty much proves my point.
20:32:49 [ocharles]
in ubuntu, it's just apt-get install postgresql-plperl
20:32:50 [reosarevok]
Well, do it, and if someone asks, it's some kind of 502 o'clock
20:32:50 [reosarevok]
:p
20:33:02 [reosarevok]
Random, provoked... works anyway
20:33:03 [warp]
only because we insist on not using the distribution's packages. which is a considerable sysadmin burden we have chosen to bear, but most people will not make that choice.
20:33:38 [ruaok]
ocharles: lets wrap it into the jan 12 release then.
20:33:42 [ocharles]
ok
20:33:44 [ruaok]
since we have to have some downtime for that one.
20:33:48 [ocharles]
that sounds good
20:33:50 [warp]
sounds like a good idea.
20:33:52 [luks]
I haven't checked the patch, but I'd like if those scripts were in separate files
20:34:06 [ocharles]
luks: which are "those scripts"?
20:34:08 [luks]
so that people who don't need this functionality don't need pl/perl
20:34:13 [ocharles]
ah right
20:34:14 [ruaok]
luks: +100
20:34:16 [luks]
anything that uses pl/perl
20:34:17 [ocharles]
the create functions
20:34:23 [ocharles]
they already are
20:34:28 [luks]
ok, thanks
20:34:43 [ruaok]
can we move on to CAA?
20:34:45 [ocharles]
but i'll add some sort of flag to it too, because atm they are always bought in
20:34:52 [reosarevok]
Short OT: does http://wiki.musicbrainz.org/Discography_Relationship_Type and other wiki CSS work for everyone else?
20:34:56 [ocharles]
yep, I think we're done
20:35:08 [ruaok]
reosarevok, nikki: CAA UI
20:35:09 [reosarevok]
* reosarevok is having a weird fullscreen thingy
20:35:22 [reosarevok]
nikki, please find your tickets :)
20:35:30 [warp]
warp has changed the topic to: agenda: CAA UI (nikki, reosarevok), CAA types (deciding), Picard/Acoustid (http://forums.musicbrainz.org/viewtopic.php?id=3245), pecastro reviews (warp)
20:35:42 [navap]
reosarevok: CSS looks fine to me
20:35:49 [reosarevok]
Ok, must be something I did
20:35:54 [reosarevok]
Can be done later then
20:36:05 [reosarevok]
CAA UI: the UI right now is confusing
20:36:06 [reosarevok]
Very much so
20:36:26 [reosarevok]
Including a huge ease to overwrite existing files instead of adding new ones
20:36:44 [reosarevok]
nikki had a few tickets about that
20:37:02 [nikki]
there's a bunch of tickets :/
20:37:16 [reosarevok]
Well, paste the most important ones first :)
20:37:22 [ocharles]
they edit display ones are solved on our end, but need the IA guys to do there part
20:37:26 [ruaok]
ocharles: are we planning a release before jan 12?
20:37:38 [ocharles]
we're 10 days overdue, so I'd hope so
20:37:47 [nikki]
http://tickets.musicbrainz.org/browse/MBS-4028 "Accidentally replacing images is too easy to do"
20:37:51 [ruaok]
and then the next one will be jan 12?
20:37:58 [ocharles]
ruaok: sounds about right, yea
20:38:04 [ruaok]
ok, great.
20:38:16 [ruaok]
then lets get the current release out soon, and then focus on the CAA release.
20:38:17 [warp]
ruaok: we cannot release anything until beta stops crashing IMO
20:38:38 [nikki]
http://tickets.musicbrainz.org/browse/MBS-4026 "Add cover art edits never display images", http://tickets.musicbrainz.org/browse/MBS-4027 "Remove image pages don't limit image size", http://tickets.musicbrainz.org/browse/MBS-4023 "Allows any file type but stores it as .jpg"
20:38:44 [ruaok]
warp: sure. I'm not suggesting we release something that isn;'t ready.
20:38:51 [nikki]
http://tickets.musicbrainz.org/browse/MBS-4024" rel="nofollow">http://tickets.musicbrainz.org/browse/MBS-4024 "http://tickets.musicbrainz.org/browse/MBS-4024"
20:39:01 [reosarevok]
* reosarevok likes that one
20:39:02 [nikki]
err
20:39:09 [nikki]
http://tickets.musicbrainz.org/browse/MBS-4024 "Pending cover art does not show up on the cover art tab"
20:39:13 [ocharles]
MBS-4026 needs thumbnail's from the internet archive, so there's nothing to display atm
20:39:27 [ruaok]
I think it might be a good idea to have a quick triage meeting for CAA release after this meeting.
20:39:31 [ocharles]
MBS-4027 is by design, because I figured if you were going to remove it, you'd want to see what you were removing in full resolution
20:39:40 [nikki]
http://tickets.musicbrainz.org/browse/MBS-4029 http://tickets.musicbrainz.org/browse/MBS-4025 http://tickets.musicbrainz.org/browse/MBS-4030 http://tickets.musicbrainz.org/browse/MBS-4036 seem to be all the ones I reported
20:39:43 [ruaok]
go through all the bugs that nikki and reosarevok think are important and schedule what we want to do.
20:39:49 [ocharles]
4023 is perfectly valid, but brings up a problem by design
20:39:59 [ocharles]
in slo, we agreed to always use .jpg as an extension
20:40:02 [warp]
Regarding the cover art stuff, we're blocked by the internet archive not having their stuff ready. and I'm not very motivated to work on any of that until we know when that stuff is going to be available.
20:40:13 [ocharles]
or was it that we'd only accept .jpg uploads?
20:40:19 [ocharles]
warp: +1
20:40:29 [ruaok]
* ruaok sighs
20:40:40 [ocharles]
but there is stuff we can do without them
20:40:42 [ruaok]
well, the jan 12 release needs to push the schema changes out.
20:40:45 [ruaok]
regardless.
20:40:53 [ocharles]
we don't have any schema changes
20:40:56 [ruaok]
even if we do not push out the actual CAA feature.
20:40:56 [ocharles]
they all got cancelled, I thought?
20:41:21 [ruaok]
the CAA related change is the only one we're doing.
20:41:23 [warp]
ocharles: we don't need schema changes for cover art support?
20:41:44 [warp]
+archive
20:41:53 [ruaok]
we're adding a flag to the release_meta table that indicates that we have coverart at CAA.
20:42:02 [ruaok]
*that* change needs to go out.
20:42:11 [warp]
agreed.
20:42:18 [ocharles]
i'm not sure we actually have that
20:42:19 [ocharles]
heh
20:42:37 [ocharles]
this comes in with the triaging stuff
20:42:40 [warp]
that is quite removed from the UI tickets from nikki and reosarevok
20:42:40 [ocharles]
we need to review where we are
20:42:47 [ruaok]
yes.
20:42:49 [reosarevok]
Yeah
20:42:54 [reosarevok]
Let's talk all this post-meeting?
20:42:55 [ruaok]
lets table this discussion, until after this meeting.
20:43:07 [reosarevok]
I guess CAA types too then?
20:43:14 [ruaok]
I'll try and get some word from the archive in a minute.
20:43:32 [ruaok]
reosarevok: the CAA types needs someone to draft a compromise proposal.
20:43:50 [ruaok]
I clearly haven't gotten to it. does anyone else want to try and do that?
20:44:05 [reosarevok]
Well, warp said he was relatively OK with ours if we stored JSON
20:44:05 [ruaok]
its going to be a while longer if we're waiting on me, just saying.
20:44:24 [reosarevok]
I'd say if we're waiting on the archive, we should just use that time to get the in-MB part done
20:44:30 [warp]
yes, I wasn't aware we could store metadata at the archive.
20:44:37 [reosarevok]
(I mean, the one where we select said metadata)
20:44:58 [ruaok]
warp: we talked about it when we were in SF.
20:45:02 [ocharles]
* ocharles nods
20:45:10 [ocharles]
they have a key-value store inside their key-value fs
20:45:24 [ruaok]
reosarevok: can you draft that updated proposal?
20:45:32 [ruaok]
which shouldn't be much work, I think.
20:45:36 [warp]
I'd still prefer to have a slightly richer mapping from that to the filenames, but that's not terribly important.
20:45:36 [ruaok]
now that warp is ok with it.
20:45:54 [reosarevok]
I guess there's not much to update, but whatever needs to be updated will be probably technical
20:45:57 [reosarevok]
I nominate ianmcorvidae
20:46:05 [warp]
lol
20:46:07 [ruaok]
ianmcorvidae: ?
20:46:08 [reosarevok]
(who did most of the writing anyway)
20:46:29 [reosarevok]
In any case, who writes it is not urgent / meeting-ish
20:46:33 [reosarevok]
So, next? :)
20:46:40 [ruaok]
ok, its in your court to finish then.
20:46:44 [ruaok]
next.
20:47:08 [ruaok]
luks: I would be ok with picard having the fingerprinting stuff built in if picard wasn't downloaded off the musicbrainz.org domain.
20:47:21 [ruaok]
if we can host it for download elsewhere, go ahead.
20:47:22 [warp]
warp has changed the topic to: agenda: Picard/Acoustid (http://forums.musicbrainz.org/viewtopic.php?id=3245), pecastro reviews (warp)
20:47:40 [luks]
well, I suggested before to move picard from musicbrainz
20:48:04 [ruaok]
do you have a place to do that?
20:48:21 [ianmcorvidae]
(I can deal with the drafting, on previous topic)
20:48:27 [ruaok]
ianmcorvidae: thanks.
20:48:44 [luks]
why not just use github
20:49:07 [ruaok]
fine by me. as long as its not the metabrainz/musicbrainz account.
20:49:15 [luks]
but I personally don't see how the hosting site makes a difference if it's an official MB product
20:49:32 [reosarevok]
* reosarevok looks again at the post saying
20:49:32 [reosarevok]
A suggestion: rather than ask a question of your attorney like "should we include (insert capability here) in Picard", ask the question "under what conditions can we include (insert capability here)".
20:49:42 [ruaok]
I know you don't agree with any of this. I dont agree with it either.
20:49:52 [reosarevok]
Is the condition really "a separate hosting?"
20:49:56 [ruaok]
But, fact of the matter is that we have to abide by US laws.
20:50:15 [ruaok]
wait, github is a US company,isn't it?
20:50:22 [warp]
So, we need some entity which doesn't need to abide by US laws to distribute picard officially.
20:50:28 [ruaok]
we need to find a place in the EU, where there are no software patents, to download it from.
20:50:29 [luks]
does just moving it outside of the OSU servers make it ok?
20:50:41 [warp]
which then technically makes that particular version no longer an official MB product.
20:50:46 [ruaok]
luks: it needs to live outiside the US.
20:50:52 [luks]
ok, here is what I propose, disconnect picard from musicbrainz
20:50:52 [ocharles]
torrent!
20:50:53 [ocharles]
:P
20:51:41 [reosarevok]
"Disconnect Picard from MusicBrainz" sounds like a pretty damaging measure, taking into account that a lot of people know it as "MusicBrainz"
20:51:44 [ruaok]
luks: in what manner? no longer host cost or downloads on musicbrainz.org domains?
20:52:01 [luks]
yes, plus not call it MusicBrainz Picard, just Picard
20:52:03 [reosarevok]
Would seriously hurt its "brand"
20:52:11 [ruaok]
I agree with reosarevok.
20:52:15 [luks]
so that decisions like this don't affect MusicBrainz
20:52:21 [reosarevok]
* reosarevok sees more people on Twitter using MusicBrainz as a name than Picard
20:52:27 [luks]
I could easily host it in the EU
20:52:29 [ruaok]
reosarevok: agreed.
20:52:34 [luks]
but I really don't see how it makes a difference
20:52:40 [reosarevok]
Option 2: make the attorney find a second solution :p
20:52:42 [ianmcorvidae]
the question we're faced with is does removing the MB name or removing fingerprinting support hurt Picard more
20:52:51 [ianmcorvidae]
as I read it?
20:52:54 [reosarevok]
Hmm
20:53:10 [ruaok]
MBChatLogger: off
20:53:10 [MBChatLogger]
is not logging
20:58:41 [MBChatLogger]
is logging
20:58:45 [warp]
we have two 3 month old reviews by pecastro on code review
20:58:48 [ruaok]
thanks navap
20:58:52 [ocharles]
warp: one has already shipped
20:59:15 [warp]
we have one 3 month old review by pecastro on code review
20:59:22 [ocharles]
:)
20:59:25 [warp]
I was wondering if what we should do with that
20:59:37 [ocharles]
this is digitally signing replication packets
20:59:46 [ruaok]
I think I'm slacking on that.
20:59:51 [ruaok]
it needs testing.
20:59:52 [warp]
does anyone care enough to take over that work? or should we just discard it from code review for now.
21:00:01 [ruaok]
keep it open for now.
21:00:04 [ruaok]
its on my list of things to do.
21:00:13 [ruaok]
djce: have you checked the code signing patch?
21:00:40 [warp]
ruaok: alright, shall I assign the ticket to you then? (in ira)
21:00:43 [warp]
s/ira/jira/
21:00:45 [ruaok]
sure.
21:00:48 [warp]
great, thanks.
21:00:52 [ruaok]
ok, perfect timing.
21:00:58 [ruaok]
thanks for your time everyone!
21:01:00 [ruaok]
</BANG>
21:01:00 [MBChatLogger]
MBChatLogger has changed the topic to: http://musicbrainz.org/#devel
21:01:05 [ruaok]
djce: ping?
21:01:44 [warp]
:D
21:02:04 [hawke_]
luks / ruaok: Would it be reasonable to reduce the MB branding of Picard while still keeping it an MB “product” for now?
21:02:34 [ruaok]
hawke_: I'd really prefer to keep the MB brain in picard.
21:02:35 [hawke_]
So that way if we do have to remove it from MB-proper it’s a little less drastic?
21:02:44 [hawke_]
drastic/sudden
21:02:57 [ruaok]
because in the past I've negotiated free serivces for picard because it was our flagship product.
21:03:10 [ruaok]
(the whole PUID serivces were free because of that)
21:03:14 [hawke_]
gotcha
21:03:20 [ruaok]
not sure I can do that when Picard isn't an official MB product.
21:03:28 [hawke_]
Heh, and that turned out well. ;-)
21:03:46 [ruaok]
hawke_: hey, it got us fignerprinting after trm became useless. :)
21:04:07 [hawke_]
it got us useless fingerprinting after the first one turned out to be useless. ;-)
21:04:43 [nikki]
it got us pretty good fingerprinting for a few years :P
21:05:02 [kepstin]
kepstin has joined #musicbrainz-devel
21:05:17 [bitmap]
PUIDs aren't useless, when the servers actually work, just really slow compared to acoustid :)
21:05:21 [luks]
on the other hand, not having it could get us an open solution sooner
21:05:47 [hawke_]
Matter of opinion I guess. PUID was never more than an opaque number to me, and there was no effort to make sure the right PUIDs ended up on the right recordings (or tracks at the time)
21:06:12 [ruaok]
ocharles: http://tickets.musicbrainz.org/browse/MBS-4113
21:06:13 [luks]
not saying it was wrong at all, but I'm not sure MB should try to depend on any "free" commercial solutions in the future
21:06:21 [ruaok]
or warp, I guess.
21:06:35 [ruaok]
but we should really work on that ticket this week, so we can test early next week.
21:06:48 [ruaok]
please note the due date.
21:06:53 [ocharles]
* ocharles nods
21:06:59 [ruaok]
ok, thanks.
21:07:37 [warp]
that due date is in a really small font.
21:11:16 [ruaok]
ok, shall we triage CAA bugs?
21:11:32 [nikki]
* nikki is eating
21:11:42 [ruaok]
* ruaok is herding cats
21:12:36 [reosarevok]
* reosarevok is
21:13:40 [ocharles]
* ocharles will be free in 10 mins
21:15:25 [ruaok]
* ruaok will return shortly
21:21:03 [ruaok]
ruaok has joined #musicbrainz-devel
21:23:49 [ruaok]
* ruaok waits for people to arrive for the CAA meeting
21:23:56 [nikki]
* nikki is done
21:24:37 [ruaok]
ocharles, warp?
21:25:11 [warp]
* warp is here
21:25:24 [ocharles]
almost
21:26:16 [reosarevok]
* reosarevok is here
21:26:51 [ocharles]
ok!
21:27:06 [ruaok]
ok, lets go through the list of bugs one at a time.
21:27:10 [ruaok]
nikki: whats the first one?
21:27:28 [nikki]
http://tickets.musicbrainz.org/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html?jqlQuery=%28summary+%7E+%22cover+art+archive%22+OR+description+%7E+%22cover+art+archive%22+OR+comment+%7E+%22cover+art+archive%22%29+AND+resolution+%3D+Unresolved+AND+reporter+%3D+nikki+AND+created+%3E%3D+2011-12-01&tempMax=1000
21:27:30 [nikki]
this should be a list
21:27:50 [ruaok]
first up, 4026
21:28:18 [nikki]
ollie's comment suggests it's because we're using s3 rather than the archive stuff
21:28:23 [ocharles]
correct
21:28:27 [ocharles]
because that's not done yet
21:28:36 [ocharles]
well, that's only one part of it
21:28:41 [ocharles]
the accepted thing is correct
21:28:45 [ruaok]
ok, not much to do until the archive gets their shizzle going.
21:28:49 [ocharles]
(it will always say "cannot display history"
21:28:50 [ocharles]
)
21:29:04 [ruaok]
4024?
21:29:05 [ocharles]
oh wait, hang on...
21:29:15 [ocharles]
i misread the ticket
21:29:38 [ocharles]
the first part does sound odd... and I'm not sure why I wrote that message
21:30:20 [ocharles]
hmm
21:30:26 [ocharles]
Oh right
21:30:32 [ocharles]
it means you can't get that image from www.covertarchive.org
21:30:42 [ocharles]
there should be an image there, but that doesn't display as we don't have thumbnail generation
21:31:09 [ocharles]
so yes, I think my original comment still stands as the only bit missing is the IAs work
21:31:23 [nikki]
I don't really get it :/
21:31:27 [warp]
4024 does sound like something missing in the code.
21:31:31 [ocharles]
nikki: it means you can get it via the web service
21:31:34 [ocharles]
until the edit is accepted
21:31:52 [warp]
(or the template rather)
21:31:55 [nikki]
the edit doesn't seem like the right place to say that
21:31:55 [ocharles]
but there should be the uploaded image above that
21:32:09 [ruaok]
what are we doing with tickets that we accept?
21:32:19 [ruaok]
move to 3 months bin?
21:32:38 [ocharles]
depends when you want it done by :)
21:32:54 [reosarevok]
By release of the CAA? (do we know when that is?
21:32:55 [reosarevok]
)
21:33:13 [ruaok]
reosarevok is right.
21:33:14 [warp]
that bin doesn't have many tickets, so seems like a good place.
21:33:30 [ruaok]
we should have it done for the release of the CAA stuff, which is not necessarily the 12th.
21:33:45 [ruaok]
I haven't gotten a hold of alexis yet.
21:33:53 [ocharles]
that doesn't seem true
21:33:57 [ruaok]
but I will try and get them to have this done for the 12th.
21:33:58 [ocharles]
http://blog.musicbrainz.org/?p=1176
21:34:00 [ocharles]
see the linked ticket
21:34:00 [nikki]
if we're going to have a message saying that things aren't going to be available via the ws, that should be visible to anyone, not just anyone who's logged in and happens to be looking at the edit history
21:34:21 [ocharles]
nikki: that's the only place you'll see that image
21:34:37 [nikki]
why?
21:34:46 [reosarevok]
That turns into "show the pending images in the cover art tab"
21:34:52 [ocharles]
si
21:34:52 [nikki]
yeah
21:34:54 [reosarevok]
(which is also in the list)
21:35:54 [reosarevok]
And which seems pretty useful
21:36:05 [reosarevok]
After all, we automatically show ASIN covers
21:36:10 [nikki]
* nikki thinks it would be a disaster to do it any other way :P
21:36:26 [reosarevok]
Why should we ask people to make an extra effort only to punish them with 15 days of waiting? :p
21:36:28 [nikki]
if it doesn't show up, people will just upload it another 5 times before giving up and if we're lucky, asking for help
21:36:40 [reosarevok]
That too
21:36:48 [ocharles]
the reason we've done it this way, is because we use our own web service to display that cover art
21:36:59 [ocharles]
and at the moment, that doesn't show pending stuff
21:37:33 [reosarevok]
So is that supposed to change once the archive is there or anything?
21:37:39 [reosarevok]
If not, that needs to change
21:37:39 [ocharles]
no
21:37:42 [ocharles]
this is by design, atm
21:38:18 [ianmcorvidae]
then the design is bad
21:38:22 [ocharles]
coverartarchive.org does show the '.pending' images, but https://github.com/ocharles/CoverArtArchive/blob/master/lib/Net/CoverArtArchive.pm filters them back out
21:38:22 [ianmcorvidae]
:P
21:38:37 [nikki]
don't filter them out then :P
21:38:57 [ocharles]
sadly, we have no paper trail as to why this was decided
21:39:01 [ocharles]
but we discussed every bit of it
21:39:17 [reosarevok]
Then you discussed it with the wrong people
21:39:24 [ocharles]
you guys are really helping here
21:39:27 [reosarevok]
Now, we all use MB more than you three do
21:39:33 [reosarevok]
We all agree it's important
21:39:41 [reosarevok]
I think we might do it for a reason, apart from annoying you
21:40:12 [ocharles]
Anyway, when pending artwork is uploaded, it's named '.pending-{edit-id}' so there was no context for what type of artwork it was
21:40:24 [ocharles]
because we assumed we would use filename for the metadata
21:40:31 [ocharles]
so without that metadata, it doesn't make sense to serve it
21:40:33 [ocharles]
hence the filtering
21:40:42 [ocharles]
now that filename for metadata might not be used, things can change
21:41:00 [ocharles]
I wonder if documenting the design as it is atm, and how it all work, may be beneficial
21:41:09 [warp]
it's still using to show the thumbnails even without metadata, to prevent people from uploading images twice.
21:41:15 [warp]
s/using/useful/
21:41:21 [nikki]
warp: exactly
21:41:24 [ocharles]
sure
21:41:37 [ocharles]
but we talked about just this because of the lag from the internet archive
21:41:49 [ocharles]
ie: people submitting artwork from their media player and it not being available immediately
21:41:49 [warp]
so, for now, it seems perfectly fine to just display all the .pending-* images under a pending images heading without metadata.
21:42:26 [reosarevok]
Pending images heading, with links to the edits?
21:42:39 [warp]
right, but a minutes lag from the internet archive thumbnailer bot is a quite different from two weeks lag from our edit system.
21:42:42 [reosarevok]
If so, might work - at least until we can show the pending front one
21:42:52 [ocharles]
warp: it was more than a minute
21:42:56 [reosarevok]
ocharles: artwork from their media player? Do we even support that?
21:43:26 [ijabz_]
ijabz_ has joined #musicbrainz-devel
21:43:36 [warp]
ocharles: iirc it takes a few hours if their bot is behind, but generally takes a few minutes? or am I misrembering that conversation?
21:43:52 [ocharles]
i thought it was more like "within 30 minutes"
21:43:57 [ocharles]
which is still yes, much shorter than 2 weeks
21:44:34 [ocharles]
anyway, pending needs to show up, so lets acknowledeg that and move on
21:44:44 [ocharles]
i'm certainly not saying we shouldn't do that - just why it isn't done atm
21:45:24 [ruaok]
ok
21:45:25 [warp]
ok
21:45:36 [ruaok]
4023
21:46:08 [ocharles]
so, do we only allow jpg?
21:46:10 [ruaok]
right now the CAA only supports jpg.
21:46:22 [ruaok]
if we really need to support other formats later, we can.
21:46:24 [nikki]
if it only supports jpg, we should reject anything else
21:46:30 [ruaok]
for now, disallow all things not .jpg
21:46:40 [hawke_]
Does it only support jpg, or does it serve whatever and call it jpg?
21:46:45 [nikki]
hawke_: the latter
21:46:49 [hawke_]
facepalm
21:46:49 [nikki]
see the ticket :P
21:47:00 [nikki]
I uploaded a gif, a png and a txt file
21:47:19 [ocharles]
and it served with a content-type of jpeg?
21:47:22 [ocharles]
or renamed it jpg?
21:47:23 [nikki]
yep
21:47:24 [nikki]
both
21:47:25 [ocharles]
because we do the renaming
21:47:34 [ocharles]
I imagine that's s3 guessing based on the extension
21:47:37 [ocharles]
so this is more our fault
21:47:46 [ruaok]
4029
21:47:56 [ocharles]
we.. haven't made a decision...
21:48:00 [ocharles]
oh
21:48:02 [ocharles]
only .jpg?
21:48:05 [ruaok]
yes.
21:48:11 [ocharles]
it can certainly work with .png
21:48:15 [ocharles]
it's just that we rename .jpg
21:48:30 [ocharles]
the reason we did that is because it allows people to guess the front image
21:48:39 [ocharles]
is that really worth limiting file formats?
21:48:48 [ocharles]
(could be wrong on why we chose that renaming)
21:48:49 [warp]
for now, yes.
21:48:53 [nikki]
I'm sure some people have some digital releases with animated covers :P
21:48:58 [ruaok]
yes, because its more work for the archive to support more formats.
21:49:04 [warp]
let's not launch with more features than absolutely neccesary.
21:49:28 [nikki]
so I guess we fix this ticket by limiting it to only jpg and I can add new tickets for supporting other formats?
21:49:28 [ruaok]
their restriction is to only support jpg unless we have good reason to do otherwise.
21:49:35 [ruaok]
nikki: sure.
21:49:52 [ruaok]
ocharles: I'll let you decide when we move on to a new ticket.
21:50:02 [ruaok]
seeing as I am too quick to jump the gun.
21:50:25 [ocharles]
it sounds like we've made a decision now :), we can go to 4029
21:50:42 [ocharles]
4029 sounds fine to me, as it is
21:50:55 [ruaok]
if it were fine, there would be no ticket for it. :)
21:51:13 [ocharles]
fine as in it's a good idea and a clear ticket
21:51:19 [nikki]
to me the most obvious solution is a button next to the "remove" that says "replace"
21:51:21 [ruaok]
ah. ok.
21:51:43 [reosarevok]
That would probably also imply disabling the page numbers for new adds
21:51:46 [ruaok]
* ruaok tosses it into 30 months pile
21:51:52 [reosarevok]
(as in, only allowing them to be removed or replaced)
21:51:53 [ruaok]
*3
21:52:13 [reosarevok]
the USED page numbers that is
21:52:46 [reosarevok]
(that's if we go with page numbers at all, btw - but that's another issue)
21:53:04 [ocharles]
so how can we work on this stuff if we don't even know what we're storing?
21:53:10 [warp]
reosarevok: they're not page numbers.
21:53:21 [reosarevok]
warp: index numbers, whatever
21:53:50 [ruaok]
ocharles: come again?
21:53:57 [reosarevok]
The point is if we only use filenames for 1 front, 1 back and n other, we don't really need to show those n numbers for other anywhere, or do we?
21:54:02 [reosarevok]
They can be "hidden"
21:54:43 [ocharles]
dunno, just seems if we haven't decided if we have pages or don't have pages being one issue, or how the metadata is stored, so it's a bit tricky to work on these tickets.
21:55:04 [ocharles]
but regardless of the store, there needs to be a replace button :)
21:55:15 [ruaok]
well, since you two are stonewalling working on these tickets anyway, does it matter? :)
21:55:23 [warp]
lol
21:56:07 [warp]
taxi is early today. I'm packing my things.
21:56:09 [warp]
back tomorrow!
21:56:11 [warp]
bye
21:56:12 [ruaok]
if a ticket is unclear because of the pending CAA-types stuff, then least leave it out.
21:56:26 [ruaok]
ffs. its amazing we get anything done.
21:57:07 [reosarevok]
And yet things get done
21:57:17 [reosarevok]
So, from here, the replace button seems the first obvious thing
21:57:46 [reosarevok]
I'd say the next one is stop filtering pending stuff out, but maybe that's just me and we didn't agree on it :p
21:57:58 [ocharles]
no, we agree on doing that
21:58:03 [reosarevok]
Ok
21:58:26 [reosarevok]
Blocking the non-jpg thing
21:58:33 [reosarevok]
All those should be possible now, right?
21:58:42 [reosarevok]
And getting this compromise on the types and stuff so we can unlock the rest
21:59:08 [ocharles]
I just feel like I should actual post the design of how everything works right now, before working on this...
21:59:19 [ocharles]
the stuff seems like it should be fine
21:59:33 [ocharles]
but there's stuff here that I'm finding myself saying "that's by design" but no one other than me, ruaok and warp knows that
21:59:52 [reosarevok]
That + figure out why beta keeps failing should keep you busy for a while :p
22:00:36 [reosarevok]
As long as "by design" doesn't involve "set in stone", sure, write it
22:01:18 [ocharles]
sorry, my brain pretty much switches off when I end up working til 10pm
22:01:20 [reosarevok]
Do we have a 15MB cap in place?
22:01:38 [reosarevok]
I know there's supposed to be one but I don't know if it's done
22:01:45 [reosarevok]
* reosarevok didn't try to submit a hugeass file
22:01:52 [ruaok]
ocharles: shall we try to resume this tomorrow?
22:02:41 [ocharles]
that's fine with me :)
22:03:10 [ruaok]
ok, tomorrow it is.
22:07:01 [djce]
djce has joined #musicbrainz-devel
22:11:33 [ruaok]
hi djce
22:11:40 [djce]
hi
22:13:33 [ruaok]
djce: please see RikaServer and LoloServer in the syswiki.
22:13:42 [djce]
ok
22:13:50 [ruaok]
when you're done reading RikaServer, ping me.
22:19:18 [djce]
ruaok: read it
22:19:37 [ruaok]
any questions?
22:19:40 [warp]
ruaok: sorry for running off like that.
22:19:53 [warp]
when do we continue tomorrotw?
22:20:01 [ruaok]
warp: np, lets finish it tomorrow.
22:20:04 [ruaok]
when we're around.
22:20:11 [ruaok]
closer to my morning.
22:20:12 [warp]
hehe
22:20:22 [warp]
alright, I'll keep an eye on irc.
22:20:22 [djce]
ruaok: so, do you need me to do anything for Rika?
22:20:30 [djce]
set anything up? monitor anything?
22:20:39 [ruaok]
pick an ip first of all
22:20:40 [ruaok]
72.29.167.158
22:20:46 [ruaok]
should be free for us to use, right?
22:20:52 [djce]
I believe so, yes
22:20:53 [warp]
and now shower. afk. bye again :)
22:21:04 [ruaok]
djce: ok, I'll use that and setup some DNS for it.
22:21:21 [ruaok]
djce: can we get some basic nagios monitoring going?
22:21:35 [ruaok]
make sure the server is up, not overloaded.
22:21:50 [ruaok]
also, can we bandwidth limit the whole server somehow?
22:22:05 [djce]
nagios, yes
22:22:10 [djce]
bandwidth.... in or out?
22:22:11 [ruaok]
we should also install the firewall stuffs to protect the machine as much as possible.
22:22:18 [ruaok]
both.
22:22:39 [ruaok]
since we have random developers, not everyone is going to remember to conserve bandwidth.
22:22:41 [djce]
hmm. I'll have a think about that.
22:22:54 [ruaok]
ok. I'd set the limit at a mbit.
22:23:05 [MBChatLogger]
http://musicbrainz.org
22:23:05 [ruaok]
unless the connections are to mb.org
22:23:19 [ruaok]
read: anything that travels outbound needs throttling.
22:23:25 [djce]
nod
22:23:59 [ruaok]
and for the firewall, we should allow only SSH and HTTP.
22:24:02 [ruaok]
on port 80.
22:24:18 [ruaok]
all the sandboxes should have a vhosting front end proxy.
22:24:42 [ruaok]
we might get another domain for this box, so that ianmcorvidae can admin the DNS for the vhosts.
22:24:47 [ruaok]
mbsandbox.org ?
22:25:04 [djce]
the sandboxes are just musicbrainz-server instances?
22:25:11 [ruaok]
yes.
22:25:16 [djce]
against what database?
22:25:26 [ruaok]
all local DBs.
22:25:35 [ruaok]
I suspect that we'll run a replicated read only one.
22:25:45 [ruaok]
and each sandbox will likey have their own DB.
22:25:51 [ruaok]
I'll leave that to ianmcorvidae
22:25:54 [djce]
ok. I can't guarantee the setup, of course, if someone else is the admin :-)
22:26:00 [ruaok]
the box as 1TB for that reason.
22:26:06 [ruaok]
djce: understood.
22:26:17 [djce]
but I'll see what I can do
22:26:37 [ruaok]
thx.
22:26:55 [ruaok]
I'll go have lunch in a minute and then install the OS on that box.
22:27:31 [ruaok]
ianmcorvidae: ping
22:33:51 [ruaok]
djce: what is the IP of the DWNI DNS server we use?
22:34:09 [djce]
i'll check
22:34:33 [djce]
72.29.161.1 and .2
22:34:54 [ruaok]
thx
22:35:12 [ruaok]
ok, I have everything I need to get Rika going.
22:35:17 [ruaok]
lunch, then the install.
22:35:18 [ruaok]
ttfn
22:45:42 [Leftmost]
Leftmost has joined #musicbrainz-devel
22:45:42 [Leftmost]
Leftmost has joined #musicbrainz-devel
23:02:06 [Leftmost]
Leftmost has joined #musicbrainz-devel
23:02:06 [Leftmost]
Leftmost has joined #musicbrainz-devel
23:12:09 [ijabz]
ijabz has joined #musicbrainz-devel