Created attachment 375868 [details] emerge --info The ebuild fails to assemble the final binary because -logg and -lvorbis are not specified after libencoder_plugins.a. This issue is apparently fixed in later, unstable versions of mpd. To get around this issue, I would: ebuild /usr/portage/media-sound/mpd/mpd-0.17.6.ebuild compile cd /var/tmp/portage/media-sound/mpd-0.17.6/work/mpd-0.17.6 and rerun x86_64-pc-linux-gnu-g++ -O2 -march=k8 -pipe -Wl,-O1 -Wl,--as-needed -L/usr/lib64/sidplay/builders -L/usr/lib64/sidplay/builders -o src/mpd (...) libencoder_plugins.a -logg -lvorbis (...) After that ebuild mpd-0.17.6.ebuild merge would finish the job. If it's not too much trouble I'd ask someone to give me some pointers on who (autoconf? ./configure ?) is responsible for generating the pkg-config stuff that makes up the final Makefile. If I understood the process of how the Makefile is generated I would be better equipped to propose patches that fix small issues like this.
Created attachment 375870 [details] build.log
Created attachment 375872 [details] config.log
(In reply to Jaroslav Rakhmatoullin from comment #2) > Created attachment 375872 [details] > config.log conftest.c:(.text.startup+0x7): undefined reference to `getpeereid'
Please try current ~arch
Yes, not happened in 0.18.10-r1
(In reply to Christoph Mende from comment #4) > Please try current ~arch Yes, that works fine, but the stable version is still broken.
(In reply to Michal Plichta from comment #5) > Yes, not happened in 0.18.10-r1 Had same problem (amd64), the current arch, 0.18.10-r1 fixes it for me as well.
Created attachment 376326 [details, diff] mpd-0.17.6-opus-linking.patch not a reason to wait for stabilization, I will apply this today
Created attachment 376328 [details, diff] mpd-0.17.6.ebuild.diff
we are in habit of closing bugs 'RESOLVED, FIXED' once they have been fixed in ~arch, followed by new STABLEREQ bugs like bug 509502 close this useless bug ->
(In reply to Samuli Suominen from comment #10) > we are in habit of closing bugs 'RESOLVED, FIXED' once they have been fixed > in ~arch, followed by new STABLEREQ bugs like bug 509502 > > close this useless bug -> That sounds wrong. STABLE arch is broken and no one knows yet if arch teams will give their OK for the new version. Let's not randomly assume stuff.
(In reply to Julian Ospald (hasufell) from comment #11) > (In reply to Samuli Suominen from comment #10) > > we are in habit of closing bugs 'RESOLVED, FIXED' once they have been fixed > > in ~arch, followed by new STABLEREQ bugs like bug 509502 > > > > close this useless bug -> > > That sounds wrong. STABLE arch is broken and no one knows yet if arch teams > will give their OK for the new version. Let's not randomly assume stuff. Samuli is right. If the bug is fixed in ~arch, then we close it. Please request a new stabilization of the mpd package. Since I am one of the maintainers, I'd rather see a new version being stabilized rather than fixing the existing one. There is no good reason why the new mpd can't go stable
(In reply to Markos Chandras from comment #12) > (In reply to Julian Ospald (hasufell) from comment #11) > > (In reply to Samuli Suominen from comment #10) > > > we are in habit of closing bugs 'RESOLVED, FIXED' once they have been fixed > > > in ~arch, followed by new STABLEREQ bugs like bug 509502 > > > > > > close this useless bug -> > > > > That sounds wrong. STABLE arch is broken and no one knows yet if arch teams > > will give their OK for the new version. Let's not randomly assume stuff. > > Samuli is right. If the bug is fixed in ~arch, then we close it. Please > request a new stabilization of the mpd package. Since I am one of the > maintainers, I'd rather see a new version being stabilized rather than > fixing the existing one. There is no good reason why the new mpd can't go > stable Is there any good reason why I can not apply the above patch (which is a simple backport from upstream)? Stabilization can and sometimes does take multiple weeks.
(In reply to Julian Ospald (hasufell) from comment #13) > Is there any good reason why I can not apply the above patch (which is a > simple backport from upstream)? Stabilization can and sometimes does take > multiple weeks. I don't mind either way. If you feel like applying it, go for it.
(In reply to Julian Ospald (hasufell) from comment #13) > (In reply to Markos Chandras from comment #12) > > (In reply to Julian Ospald (hasufell) from comment #11) > > > (In reply to Samuli Suominen from comment #10) > > > > we are in habit of closing bugs 'RESOLVED, FIXED' once they have been fixed > > > > in ~arch, followed by new STABLEREQ bugs like bug 509502 > > > > > > > > close this useless bug -> > > > > > > That sounds wrong. STABLE arch is broken and no one knows yet if arch teams > > > will give their OK for the new version. Let's not randomly assume stuff. > > > > Samuli is right. If the bug is fixed in ~arch, then we close it. Please > > request a new stabilization of the mpd package. Since I am one of the > > maintainers, I'd rather see a new version being stabilized rather than > > fixing the existing one. There is no good reason why the new mpd can't go > > stable > > Is there any good reason why I can not apply the above patch (which is a > simple backport from upstream)? Stabilization can and sometimes does take > multiple weeks. For one thing, your patch calls eautoreconf which effectively modifies the build system that was originally used by arch teams to stabilize this package. And as you know, per policy, such changes (eautoreconf etc) need a revbump because it may work for you but not for every stable system out there. Requesting a stabilization of new version should take a couple of days for amd64/x86 to happen. It should not be a major problem. For the rest of the arches, well, it has always been the case.
(In reply to Christoph Mende from comment #14) > (In reply to Julian Ospald (hasufell) from comment #13) > > Is there any good reason why I can not apply the above patch (which is a > > simple backport from upstream)? Stabilization can and sometimes does take > > multiple weeks. > > I don't mind either way. If you feel like applying it, go for it. I don't quite mind either, I am just pointing out that fixing the stable package like this is, it sort-of violates the policy for the sake of keeping the stable tree working. My preference is to push the new version to stable because this is what we traditionally do, but I don't want to push this too much.
(In reply to Markos Chandras from comment #16) > (In reply to Christoph Mende from comment #14) > > (In reply to Julian Ospald (hasufell) from comment #13) > > > Is there any good reason why I can not apply the above patch (which is a > > > simple backport from upstream)? Stabilization can and sometimes does take > > > multiple weeks. > > > > I don't mind either way. If you feel like applying it, go for it. > > I don't quite mind either, I am just pointing out that fixing the stable > package like this is, it sort-of violates the policy for the sake of keeping > the stable tree working. My preference is to push the new version to stable > because this is what we traditionally do, but I don't want to push this too > much. exactly. i don't mind either if the patch is applied, that's just fine, but this is how bugzilla works within gentoo. :)
