#musicbrainz

The login box looks "thinner" after logging out than it was when I first went there and had to log in.

firefox doesn't seem to either

and the orange bar saying "Log in" at the top of the box, that's ok too?

(Mozilla 1.7.5 on Linux)

Orange bar stuff seems okay

great. CSS rules :-)

Yeah, it rules. Until you open IE... :-P

I wish the form colours worked properly though :(

Can anyone test in it in IE for me?

I remember discussing it ages ago with you, but you insisted it was right.

Learning that the *very* hard way, trying to make a website content management system that's CSS-layout based (no tables).

it seems ok in Win98/IE5 AFAICT

My nomination for the worst colour scheme of the day: http://adblock.mozdev.org/

what were they thinking?

"Every time you use wine, a penguin whines."

They were thinking, "We don't really want people to read this."

HairMetalAddict: the subs page now shows the count (in the top paragraph)

IE6 on XP seems fine...

good

IE6 via wine seems fine

it seems like they accidentally bleached their page.

left in the sun too long

If you read their forums, half the posts are saying "Please fix the stupid colour scheme on the web site"

Damn, 239 artists. :-P

However they don't make it easy to help them (e.g. submit patches), so I didn't bother helping them.

118 for me

ok, thanks for the testing people! Time to commit to cvs....

but I keep finding artists I meant to subscribe to.

oh, which reminds me, is there any reason why the subscribe link on artist pages can't change to unsubscribe if you're already subscribed to that artist?

only that it's more work for the system to check that - extra load I mean.

ah

*grunt* More Power! *grunt*

somnout is now known as somniloquy

I've got some minor problems to get AR up and running. It seems the SESSION_COOKIE sub is missing on the AR branch

is it enough to define it like on the release branch or isn't it the only thing that has to be fixed?

hm, defining the sub was enough, it seems

Hello all. Is this an active channel ?

sometimes

Only when we wake up :-)

I'm looking for some advice on libtunepimp-0.3

would this be an appropriate place

Ideal

What's up?

basiclly I'm building tunepimp for use with kde

but later versions of glibc (threads) appear to be causing it problems at build time

I was wondering if other people had reported it and if there where patches

I haven't heard that, no. yalaforge, does this sounds familiar to you?

Do you know what library it might be which is causing the problem?

ikonia: wait until ruaok is here, he's the author of libtp

I couldn't find any patches so I was assuming I was either the first

it's always built just fine for me.

it seems a great product and I've never had any problems with it before

same here. except on netbsd :-)

but I've gone a little latest on my latest version of glibc and its complaining about threads

I'm trying to back trace it at the moment

what kind of complaints? compiler? linker?

compiler

hang on, I'll see if I can borrow a paste bin for a minute

I've narrowed the problem down to here

thanks guys

my glibc is 2.3.2.ds1-16. what's yours?

hang no

hang on

asdf___ is now known as g0llum

2.3.4

ok

where is it installed? in /usr or /usr/local?

/usr

try a grep in /usr/include for pthread_kill, it's defined in bits/sigthread.h

(at least here)

tp from cvs compiles fine here, btw

nothing in /usr/include

ok

which distribution?

I see it in /usr/include/bits as you said

but nothing direct in /usr/include

LFS 6.

ok. /usr/include/pthread.h should include bits/sigthread.h

I've got #include <bits/pthreadtypes.h>

but not the others

no sigthread.h

ok, then this is the problem

really ?

I bet glibc developers documented the change and the reasons for it

the reason why it doesn't compile is simply that pthread_kill isn't defined

as a quick hack you could define it in tp's source (thread.cpp)

either include bits/sigthread.h or copy and paste the prototype

that would be better as I'd rarther not change glibc headers, as they (as you say) have been changed for a reason

yes, you only change tp sources

trying to work out how to define the correct settings in thread.cpp

is it that easy to just include bits/sigthread.h

for a quick test, yes

#endif

you'll have to include it after pthread.h

pthread.h is not inclded in thread.cpp

ok, no problem. still try to include sigthread.h

bits/sigthread.h or just sigthread.h

bits/sigthread.h

coolio

just checking

testing now

I'll let you have a read

k

I'm a bit out of my deapth here

hm. I don't find glibc 2.3.4 on GNU's ftp server

no - its only in cvs

ohh. so you're using bleeding edge software

the glibc boys decided never to release anything after 2.3.2

then they changed their mind

the one I'm using is pretty much the stable 2.3.4 thats close to release

hm, the cvs version's pthread.h is a bit strange

really ?

in what way

short, very short

hm, sorry. don't know

not short on my box

962 lines

yes, I think it's generated by some script or preprocessor

:q!

oops

does anyone here use glibc-2.3.3?

when building it looks like sigthread does not offer the same functions

viewcvs is pretty useless when searching for a file. *sigh*

yes it is a pain