Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

media-libs/libgroove: new ebuild #22

Merged
merged 1 commit into from
Aug 20, 2015
Merged

Conversation

diogocp
Copy link
Contributor

@diogocp diogocp commented Aug 19, 2015

A streaming audio processing library (andrewrk/libgroove).
Gentoo-Bug: 558190

KEYWORDS="~amd64"
IUSE="+chromaprint +loudness +sound"

DEPEND="media-video/ffmpeg
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • no USE flags needed for ffmpeg? sure?
  • does it not work with media-video/libav?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Upstream has some suggested flags, but from my tests they are all optional runtime dependencies.
  • Support for libav was recently removed, but it looks like this version still supports it. I think the default should be ffmpeg, to minimize problems when upgrading to the next version, unless @andrewrk thinks libav is better for 4.3.0.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ffmpeg should be fine for 4.3.0. The next release of libgroove will officially only support ffmpeg.

@hasufell
Copy link
Contributor

You should reference this bug report https://bugs.gentoo.org/show_bug.cgi?id=558190 somewhere in your commit message. Since there is no consensus on how to do that, just do something (e.g. wrt bug 558190 in the summary or Gentoo-Bug: 558190 in the multiline commit description or whatever)

@diogocp
Copy link
Contributor Author

diogocp commented Aug 19, 2015

OK, I think that's all. Please take another look.

@hasufell
Copy link
Contributor

The build system unfortunately uses -Werror. We will have to fix/patch that, also see https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html under -Werror compiler flag not removed

Here are the offending lines https://github.com/andrewrk/libgroove/blob/master/CMakeLists.txt#L126 ...which also reveal -g in the compiler flags. That has to go out as well.

@hasufell
Copy link
Contributor

We should probably provide a static-libs USE flag and rm the foo.a files when it is turned off in src_install.

SRC_URI="https://github.com/andrewrk/libgroove/archive/${PV}.tar.gz -> ${P}.tar.gz"

LICENSE="MIT"
SLOT="0"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably provide a SUBSLOT, in this case SLOT="0/4" also see https://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that it installs both libgroove.so.4 and libgroove.so.4.3.0. How do we decide between 0/4 and 0/4.3.0?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

# objdump -p /usr/lib64/libgrooveplayer.so.4.3.0 | grep SONAME
SONAME libgrooveplayer.so.4

This reflects ABI compatibility.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, thanks.

@andrewrk
Copy link

The build system unfortunately uses -Werror. We will have to fix/patch that, also see https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html under -Werror compiler flag not removed

Here are the offending lines https://github.com/andrewrk/libgroove/blob/master/CMakeLists.txt#L126 ...which also reveal -g in the compiler flags. That has to go out as well.

Upstream maintainer here. My goal is to be friendly to package maintainers like you. I believe that cmake will handle the -g flag correctly depending on the build type, so I'm happy to simply remove that upstream.

As for -Werror, I do want that on for development, but is there a way I could prevent gentoo from having to patch it away? Perhaps if I enabled -Werror only for debug builds and not for release builds?

@hasufell
Copy link
Contributor

Perhaps if I enabled -Werror only for debug builds and not for release builds?

Gentoo hacks it's own cmake build type in (although we sometimes fall back to release build type if that causes trouble), so yes, that would probably work.

@andrewrk
Copy link

ok. I made this change upstream: andrewrk/libgroove@0b619fa and andrewrk/libgroove@856c260

If it would really help to make a new release I could do that. Otherwise I'd rather wait until some other stuff I'm presently working on is done to make a new release.

@hasufell
Copy link
Contributor

@andrewrk
Copy link

don't forget the second commit there. Sorry, I missed the -Werror and -pedantic in the example flags at first.

@diogocp
Copy link
Contributor Author

diogocp commented Aug 20, 2015

I had to make another patch because that one failed. :/


src_install() {
cmake-utils_src_install
use static-libs || rm "${D}"/usr/lib/*.a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nah, this needs improvement, it should be

use static-libs || { rm "${ED%/}"/usr/$(get_libdir)/*.a || die "failed to remove static libs!" ;}

and then we have to inherit multilib cmake-utils

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or inherit cmake-utils multilib? I noticed this discussion before, but have not seen any guidelines.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally order them by priority, to minimalize the chance that something weird happens when exported phases change. So something like inherit <utility.eclass> <heavy-phase-export.eclass>. But I don't really care here, as long as the end result works.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's failing because get_libdir returns lib64 but they are installed in /usr/lib.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a bug then that needs to be fixed/patched.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hasufell
Copy link
Contributor

excellent, I think this is good to merge, almost..

@diogocp could you rebase your libgroove against latest gentoo master?
Something like:

git pull --rebase=preserve https://anongit.gentoo.org/git/repo/gentoo.git master
git push -f origin libgroove

@diogocp
Copy link
Contributor Author

diogocp commented Aug 20, 2015

Done

@mgorny mgorny merged commit 99a5d23 into gentoo:master Aug 20, 2015
mgorny pushed a commit that referenced this pull request Aug 20, 2015
Adds media-libs/libgroove.

Reviewed-by: Julian Ospald <hasufell@gentoo.org>
Suggested-by: Diogo Pereira
Github-PR: #22
Gentoo-Bug: 558190
@diogocp
Copy link
Contributor Author

diogocp commented Aug 20, 2015

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants