Deadbeef 1.8/9999 ebuild fails with AM_GNU_GETTEXT without [external] argument is no longer supported

[danilovsergei]

I'm emerging latest deadbeef (either 1.8 or 9999) and get following error:
during aclocal

ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer supported.
configure.ac:20: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd

See full zipped logs.
deadbeef-logs.zip

After further research I found issue reproduced only when ebuild is using gentoo eautoreconf . Which seems not to be the same as authors own autogen.sh script.
Calling script directly instead of eautoreconf fixed the problem.

Following patch fixed issue for me:
https://gist.github.com/danilovsergei/1a329bb1af26caf33107f3bb8b66c265

My gettext version is sys-devel/gettext-0.20.1 . Probably vanilla ebuild still works on older versions

[damex]

'bt-overlay' ?
who's overlay is that ?

I think it is not very good idea to use upstream scripts to build instead of gentoo ones. it will have its own implications in a long run. we already switched from that autopen.sh to autotools eclass with eautoreconf once.

I am currently checking what exactly could go wrong there with auto tools.

[danilovsergei]

bt-overlay is my overlay to keep my own or modified ebuilds.

I agree eautoreconf sounds like a superior solution and it supposed to replace script supplied with deadbeef.
It's clearly a bug somewhere, not necessary in your ebuild.

[fff7d1bc]

@damex any news on this?

[sandikata]

Same problem on funtoo and gentoo.

[sandikata]

a little update by me.

https://gist.github.com/sandikata/fe46daee7e6ccd68478533b7f41439ea

[sandikata]

This dirty patch fix the problem.

[rindeal]

I've fixed this issue properly and created an upstream PR - DeaDBeeF-Player/deadbeef#2238.

Testers are welcome.

Patch is also already included in my ebuild repo.

[stefson]

gettext-0.20 has hit stable recently, so everyone is now going to hit this. #2238 fixes the issue, but there hasn't been any revbump yet!? .__.

[leycec]

Boom. I'm not @damex, but I have resolved all outstanding issues (including this one) and pull requests at raiagent, my personal overlay. I've added ebuilds for the most recent stable and live releases of DeaDBeeF, highly inspired by @damex's phenomenal work at this overlay. Since this overlay is now moribund and no longer builds against the modern Portage tree, my working ebuilds are intended as a temporary (...maybe permanent?) placeholder for the DeaDBeeF Gentoo community.

Significant improvements include:

• DeaDBeeF 1.8.2.
• Unified stable and live ebuilds.
• Resolved all outstanding issues and pull requests, including:
  * deadbeef-9999 & QA: This package installs one or more .desktop files that do not pass validation. #32.
  * Deadbeef 1.8/9999 ebuild fails with AM_GNU_GETTEXT without [external] argument is no longer supported #40.
  * media-sound/deadbeef-9999: fix missmatching desktop groups warnings #41.
  * media-sound/deadbeef-1.8.0 fails to compile with musl [patch] #42.
• Refactored all fragile version-specific diff patches into robust version-agnostic sed patches.
• Refactored the non-standard cover-imlib2 and cover-network USE flags into standard imlib2 and curl USE flags.
• Revised for compliance with Portage coding styles.

Sadly, I haven't had time to add any of the optional media-plugins/deadbeef-* plugins supported by this overlay. Most of those plugins are over half-a-decade old and unlikely to operate as expected on modern DeaDBeeF versions. Some of those plugins also suffer blocking issues and conflicts (e.g., #37). In short, they're a stagnant mess. If anyone would like me to add their favourite plugin, just submit me an issue request at raiagent and I'll promptly see to it.

Likewise, if anyone hits any stumbling blocks, just (wait for it) just submit me an issue request at raiagent. Thanks for all the tremendous work, @damex! These ebuilds are for you.

Lastly, unlike comparable ebuilds by @rindeal at rindeal/rindeal-ebuild-repo, these ebuilds are fully compliant with Portage standards and intended to be eventually incorporated into the Portage tree. Extreme caution is warranted when installing from that overlay, as noted by its frontmatter:

For this reason don't expect things to work smoothly if you use this repository just as a pure overlay. It shouldn't cause you data-loss, but emerge breakage and un-bootable system is very much possible. Mixing packages from both repos is strongly discouraged and you should avoid it using package.mask such as this one.

[stefson]

I think your approach is making my head spin, don't understand the sed magic you're using. But for your information only: you should remove adplug support, the lib is masked and will be removed from the tree soon.

[damex]

but I have resolved all outstanding issues

could you please make merge requests to this repository that solve outstanding issue(s) ?

DeaDBeeF 1.8.2.

okay, we can deal with a bump

Unified stable and live ebuilds.

that is the point. it has to be kept separate since they are different/solve different problems.

Resolved all outstanding issues and pull requests, including:

okay, we can accept the resolution(s) here.

Refactored all fragile version-specific diff patches into robust version-agnostic sed patches.

that is the point.
we keep it fragile and version specific so it won't touch something unnecessary and be version specific.

Refactored the non-standard cover-imlib2 and cover-network USE flags into standard imlib2 and curl USE flags.

okay, could be useful. that flags was never good.
it was a good trouble making them work inside a tree. would be nice to see the solution.

Revised for compliance with Portage coding styles.

that is nice.

you should remove adplug support, the lib is masked and will be removed from the tree soon.

good point.

[ghost]

I have the same issue with emerging deadbeef 1.8.0

https://gist.github.com/maxine2604/37a765d27027d3d82db270c95d5775ed

[fff7d1bc]

The overlay has not seen update in a year, however main ::gentoo tree got media-sound/deadbeef so this overlay might be no longer relevant.

[PF4Public]

@slashbeast Thanks for notifying us! It would be great if you could also get deadbeef plugins into ::gentoo.

[fff7d1bc]

I am not using any external plugins, if you see some that you'd prefer to have in tree, you are welcome to proxy maintain them. See https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

[PF4Public]

I am not using any external plugins

It's a pity.

Well, they might eventually find a new home in my overlay then…