Bugzilla Bug 141729

The latest update fails to build, unfortunately...
I will attach the log file and my env-info, in a moment...

Created an attachment (id=92736) [edit]
portage log file for the latest build

Created an attachment (id=92738) [edit]
my `emerge --info' output

Looks to me like you have the wrong sources.
player.h and player.cpp don't even exist anymore.

Could you please try deleting /usr/portage/distfiles/svn-src/lastfmplayer
and trying again?

This appears to be the result of upstream switching SVN repositories, which
caused SVN to become confused.

It's weird though, because I didn't experiance this problem while writing the
ebuild. Unless anyone else has this problem as well, this bug should be marked
as invalid.

have seen it neither, so INVALID. Please remove your
/usr/portage/svn-src/lastfm.. directory

I have no interest in being insistence ... but inspect my next attachment
carefully, please!

Created an attachment (id=92816) [edit]
new crash-log for the current version

Created an attachment (id=92818) [edit]
Patch to ebuild to add -fPIC on amd64

Okay, this is a fPIC error. See
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3

Here's a proposed patch to the ebuild which will add the fPIC to C(XX)FLAGS on
AMD64. This will slightly increase the executable size on AMD64 but will
hopefully allow you to compile (I don't have a AMD64, that's what arch testing
is for). This is to be considered a temporary workaround until the Last.FM guys
get around to fixing this.

Actually, I followed your advice and looked at the log closer. It appears you
are using a static version of qt.

If that's the case, please ignore the previous attachment as it will not help.
Then procced to get a non-static version of qt.

Oh and next time, please comment out MAKEOPTS before making a log because that
really helps with reading the log ;D

(In reply to comment #9)
> Actually, I followed your advice and looked at the log closer. It appears you
> are using a static version of qt.

I don't think so...

> If that's the case, please ignore the previous attachment as it will not help.
> Then procced to get a non-static version of qt.

If you know a way of gathering the desired information about qt's health,
please instruct me how to ... I am ready to co-operate ;)

> Oh and next time, please comment out MAKEOPTS before making a log because that
> really helps with reading the log ;D

This [!] is a `portage' feature [not a bug] ... please contact the dev's with
your concern ;)

>> This [!] is a `portage' feature [not a bug] ... please contact the dev's with
your concern ;)
What I mean was, it's a great feature when the package works correctly.
However, it makes logs really difficult to read. So when making a log, it would
be kind to temporarily turn off that flag.

Anways, could you please try applying the patch to the ebuild? If you don't
know how, adding -fPIC to CFLAGS only for this emerge will effectively do the
same thing.

(In reply to comment #11)

Please ... forgive me, but I couldn't resist ... my bug about this lousy
logging behaviour is still open:

> What I mean was, it's a great feature when the package works correctly.
> However, it makes logs really difficult to read. So when making a log, it would
> be kind to temporarily turn off that flag.

What `flag', dear David?

> Anways, could you please try applying the patch to the ebuild? If you don't
> know how, adding -fPIC to CFLAGS only for this emerge will effectively do the
> same thing.

Done! ... To prove the state of my trial, I will attach the modified, i.e.
patched ebuild ... and the latest log file. Please bear in mind that I have had
previously cleaned out the local svn repository ... all, with no luck!

Created an attachment (id=92884) [edit]
modified ebuild with amd64-fpic.patch

Created an attachment (id=92885) [edit]
log for moded ebuild compile crash

Arg... that's what happens when people try to release a package without a
configure script. People's CFLAGS get completely ignored. Looks like the
Makefile has to be patched manually.

Anyways, thanks for bearing out with me and still being willing to find a
solution that works.

Created an attachment (id=92890) [edit]
Proposed ebuild

Okay, this is a proposed ebuild which will apply a patch to the Makefile.

Created an attachment (id=92891) [edit]
Patch for Makefile

This patch will add -fPIC when compiling Loqqer.c which is where you appear to
get stuck at the moment. Note that it's likely that the compile will get stuck
at whatever the next file that requires fPIC.

It goes in the files folder.

Here we go, again...

1. Cleaned out svn locals
2. Copied patch for makefile to //files dir
3. Copied proposed ebuild over original
4. Run `emerge' ... NOPE!
5. See below attached log: `let-it-be'

You are a polite young man ... relax, please ... the previous version of our
application works smooth, so there is no reason for any anxiety ... talk,
whenever you want to `upstream' ... in the meantime I would propose that you
might want to listen to some strong sound, like `Little Feat's `Trouble' ;)
Thank YOU, David!

Created an attachment (id=92942) [edit]
`let-it-be' log

Created an attachment (id=92947) [edit]
Proposed ebuild

Okay, good news is you are clearly past the previous problem.

The bad news is that the problem you have. Apperantly someone at last.fm made a
bad design decision to store a pointer address in a int. This works in x86, but
it needs to be a long long in amd64.

Anyways, please delete the previous patch and ebuild and try this new one that
should fix the latest problem.

Created an attachment (id=92948) [edit]
Patch for amd64 problems

lastfmplayer-amd64.patch

This should fix the latest problem.
Goes in the files folder.

Again ...

1. Cleaned out svn locals
2. Copied patch for makefile to //files dir
3. Copied proposed ebuild over original
4. Run `emerge' ... YEESSS!
5. See below attached log: `thats-it'

Hey Stefan, verliere diesen Jungen ja nicht aus den Augen ;)

Thank you, David ... it worked out in the end! I will attach the latest log for
your inspection ... and do not forget to merge these changes into the cvs-tree
... the honour of closing this bug belongs to you, my young friend ;)

Created an attachment (id=92953) [edit]
`thats-it' log

I'm glad to hear that the player built for you.

I'm not an offical gentoo developer and I thus I don't have cvs access nor can
I close the bug. Those actions are up to Stefan Schweizer.

Btw, Stefan, the relevant attachements are 92947 (the ebuild) and 92947 (the
patch).

thanks I have applied the patch. Can you please take care of sending them
upstream to the lastfm devs? It would actually also be nice to have the fPIC
patch applied before the Makefile is being generated.

Yeah, that would be a good idea. I'll go a head an inform upstream.

In my experience the lastfmplayer will not build when multiple make jobs are
allowed through MAKEOPTS=-jN in /etc/make.conf. This can be fixed by limiting
the the jobs to one in the ebuild by adding the line MAKEOPTS="${MAKEOPTS}
-j1".