The latest update fails to build, unfortunately... I will attach the log file and my env-info, in a moment...
Created attachment 92736 [details] portage log file for the latest build
Created attachment 92738 [details] 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 attachment 92816 [details] new crash-log for the current version
Created attachment 92818 [details, diff] 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 attachment 92884 [details] modified ebuild with amd64-fpic.patch
Created attachment 92885 [details] 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 attachment 92890 [details] Proposed ebuild Okay, this is a proposed ebuild which will apply a patch to the Makefile.
Created attachment 92891 [details, diff] 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 attachment 92942 [details] `let-it-be' log
Created attachment 92947 [details] 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 attachment 92948 [details, diff] 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 attachment 92953 [details] `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".
