Bug 1018546 - Review Request: musepack-libmpc - Living audio compression
Summary: Review Request: musepack-libmpc - Living audio compression
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On: 1018541 1018544
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-13 06:07 UTC by Ankur Sinha (FranciscoD)
Modified: 2018-11-14 08:23 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1014468 None NEW Please update mpcdec to the newer SV8 versions 2019-06-08 07:31 UTC

Internal Trackers: 1014468

Description Ankur Sinha (FranciscoD) 2013-10-13 06:07:12 UTC
Spec URL: http://ankursinha.fedorapeople.org/musepack-libmpc/musepack-libmpc.spec
SRPM URL: http://ankursinha.fedorapeople.org/musepack-libmpc/musepack-libmpc-1.3.0-0.1.svn475.fc21.src.rpm

Description: 
Musepack is an audio compression format with a strong emphasis on high quality.
It's not lossless, but it is designed for transparency, so that you won't be
able to hear differences between the original wave file and the much smaller
MPC file.

It is based on the MPEG-1 Layer-2 / MP2 algorithms, but since 1997 it has
rapidly developed and vastly improved and is now at an advanced stage in which
it contains heavily optimized and patentless code.


Fedora Account System Username: ankursinha

rpmlint errors:
[asinha@ankur-laptop  SRPMS]$ rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/*.rpm
libmpcdec.x86_64: W: spelling-error Summary(en_US) Musepack -> Muse pack, Muse-pack, Mudpack
libmpcdec.x86_64: W: spelling-error %description -l en_US Musepack -> Muse pack, Muse-pack, Mudpack
libmpcdec.x86_64: W: no-manual-page-for-binary mpcdec
libmpcdec-devel.x86_64: W: spelling-error Summary(en_US) Musepack -> Muse pack, Muse-pack, Mudpack
libmpcdec-devel.x86_64: E: invalid-soname /usr/lib64/libmpcdec.so libmpcdec.so
libmpcdec-devel.x86_64: W: no-documentation
musepack-libmpc.src: W: spelling-error %description -l en_US lossless -> loss less, loss-less, loveless
musepack-libmpc.src: W: spelling-error %description -l en_US patentless -> patent less, patent-less, pathless
musepack-libmpc.src:4: W: macro-in-comment %{actual_name}
musepack-libmpc.src:115: W: macro-in-comment %{_libdir}
musepack-libmpc.src: W: invalid-url Source0: libmpc_r475.tar.gz
musepack-libmpc.x86_64: W: spelling-error %description -l en_US lossless -> loss less, loss-less, loveless
musepack-libmpc.x86_64: W: spelling-error %description -l en_US patentless -> patent less, patent-less, pathless
musepack-libmpc.x86_64: W: no-documentation
musepack-libmpc.x86_64: W: no-manual-page-for-binary mpccut
musepack-libmpc.x86_64: W: no-manual-page-for-binary mpcenc
musepack-libmpc.x86_64: W: no-manual-page-for-binary mpcchap
musepack-libmpc.x86_64: W: no-manual-page-for-binary wavcmp
musepack-libmpc.x86_64: W: no-manual-page-for-binary mpcgain
musepack-libmpc.x86_64: W: no-manual-page-for-binary mpc2sv8
musepack-libmpc-devel.x86_64: W: no-documentation
6 packages and 0 specfiles checked; 1 errors, 20 warnings.


Mailed upstream about soname versioning already.

Comment 1 Michael Schwendt 2013-10-19 22:05:20 UTC
> %package -n libmpcdec
> Summary:    Musepack audio decoding library
> Obsoletes:      libmpcdec < 1.2.6-13

Package libmpcdec is "License: BSD", because libmpcdec and mpcdec apply those licensing terms.

The "Obsoletes" tag here (and in the -devel package) is superfluous. This subpackage "libmpcdec" will update the older package "libmpcdec", because of the higher EVR already.

Is this lib from Musepack SV8 even ABI-compatible with SV7 libmpcdec? Isn't even the SONAME _supposed_ to be different already? The spec isn't ready, but the old lib is libmpcdec.so.5, and the spec uses .0 and asks which version is should be.

And what about all the dependencies?

# repoquery --whatrequires libmpcdec
cmus-0:2.5.0-4.fc20.x86_64
gstreamer-plugins-bad-free-0:0.10.23-19.fc20.i686
gstreamer-plugins-bad-free-0:0.10.23-19.fc20.x86_64
k3b-1:2.0.2-18.20130927git.fc20.x86_64
libmpcdec-devel-0:1.2.6-12.fc20.i686
libmpcdec-devel-0:1.2.6-12.fc20.x86_64
libtunepimp-0:0.5.3-23.fc20.i686
libtunepimp-0:0.5.3-23.fc20.x86_64
qmmp-0:0.7.2-1.fc20.i686
qmmp-0:0.7.2-1.fc20.x86_64
vlc-core-0:2.1.0-1.fc20.x86_64
xine-lib-0:1.1.21-8.fc20.i686
xine-lib-0:1.1.21-8.fc20.x86_64
xmms-musepack-0:1.2-13.fc20.x86_64
xmms2-0:0.8-13.fc20.i686
xmms2-0:0.8-13.fc20.x86_64

Comment 2 Ankur Sinha (FranciscoD) 2013-10-20 01:00:19 UTC
(In reply to Michael Schwendt from comment #1) 
> Is this lib from Musepack SV8 even ABI-compatible with SV7 libmpcdec? Isn't
> even the SONAME _supposed_ to be different already? The spec isn't ready,
> but the old lib is libmpcdec.so.5, and the spec uses .0 and asks which
> version is should be.

The website says it is: note: "Old. Refer to above SV8 lib (compatible with SV7)". Unfortunately upstream hasn't versioned the soname. I've already mailed them about this, but haven't received a reply. 

> 
> And what about all the dependencies?
> 
> # repoquery --whatrequires libmpcdec
> cmus-0:2.5.0-4.fc20.x86_64
> gstreamer-plugins-bad-free-0:0.10.23-19.fc20.i686
> gstreamer-plugins-bad-free-0:0.10.23-19.fc20.x86_64
> k3b-1:2.0.2-18.20130927git.fc20.x86_64
> libmpcdec-devel-0:1.2.6-12.fc20.i686
> libmpcdec-devel-0:1.2.6-12.fc20.x86_64
> libtunepimp-0:0.5.3-23.fc20.i686
> libtunepimp-0:0.5.3-23.fc20.x86_64
> qmmp-0:0.7.2-1.fc20.i686
> qmmp-0:0.7.2-1.fc20.x86_64
> vlc-core-0:2.1.0-1.fc20.x86_64
> xine-lib-0:1.1.21-8.fc20.i686
> xine-lib-0:1.1.21-8.fc20.x86_64
> xmms-musepack-0:1.2-13.fc20.x86_64
> xmms2-0:0.8-13.fc20.i686
> xmms2-0:0.8-13.fc20.x86_64

I could request rebuilds with the new soname version, just to be sure. I can't think of another way of handling this.

Comment 3 Michael Schwendt 2013-12-09 10:36:25 UTC
> I could request rebuilds with the new soname version, just to be sure.

Evaluating whether the dependencies would rebuild (with the new lib being API-compatible) is a prerequisite for any upgrade like this.

Comment 4 Ankur Sinha (FranciscoD) 2014-07-17 15:20:21 UTC
I finally got down to this. 

Here's the new spec:

http://ankursinha.fedorapeople.org/musepack-libmpc/musepack-libmpc.spec

New srpm:
http://ankursinha.fedorapeople.org/musepack-libmpc/musepack-libmpc-1.3.0-0.1.svn484.fc22.src.rpm

All dependent packages will need to be rebuilt since this version changes the version of the provided shared object: libmpcdec.so.6()(64bit). The older was libmpcdec.so.5()(64bit)

rpmlint errors:
[asinha@ankur-laptop  SRPMS]$ rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/*.rpm ./musepack-libmpc-1.3.0-0.1.svn484.fc20.src.rpm ../SPECS/musepack-libmpc.spec
libmpcdec.x86_64: W: spelling-error Summary(en_US) Musepack -> Muse pack, Muse-pack, Mudpack
libmpcdec.x86_64: W: spelling-error %description -l en_US Musepack -> Muse pack, Muse-pack, Mudpack
libmpcdec.x86_64: W: no-manual-page-for-binary mpcdec
libmpcdec-devel.x86_64: W: spelling-error Summary(en_US) Musepack -> Muse pack, Muse-pack, Mudpack
libmpcdec-devel.x86_64: W: only-non-binary-in-usr-lib
libmpcdec-devel.x86_64: W: no-documentation
musepack-libmpc.src: W: spelling-error %description -l en_US lossless -> loss less, loss-less, loveless
musepack-libmpc.src: W: spelling-error %description -l en_US patentless -> patent less, patent-less, pathless
musepack-libmpc.src:4: W: macro-in-comment %{actual_name}
musepack-libmpc.src: W: invalid-url Source0: libmpc_r484.tar.gz
musepack-libmpc.x86_64: W: spelling-error %description -l en_US lossless -> loss less, loss-less, loveless
musepack-libmpc.x86_64: W: spelling-error %description -l en_US patentless -> patent less, patent-less, pathless
musepack-libmpc.x86_64: W: no-documentation
musepack-libmpc.x86_64: W: no-manual-page-for-binary wavcmp
musepack-libmpc.x86_64: W: no-manual-page-for-binary mpccut
musepack-libmpc.x86_64: W: no-manual-page-for-binary mpc2sv8
musepack-libmpc.x86_64: W: no-manual-page-for-binary mpcgain
musepack-libmpc.x86_64: W: no-manual-page-for-binary mpcenc
musepack-libmpc-devel.x86_64: W: no-documentation
musepack-libmpc.src: W: spelling-error %description -l en_US lossless -> loss less, loss-less, loveless
musepack-libmpc.src: W: spelling-error %description -l en_US patentless -> patent less, patent-less, pathless
musepack-libmpc.src:4: W: macro-in-comment %{actual_name}
musepack-libmpc.src: W: invalid-url Source0: libmpc_r484.tar.gz
../SPECS/musepack-libmpc.spec:4: W: macro-in-comment %{actual_name}
../SPECS/musepack-libmpc.spec: W: invalid-url Source0: libmpc_r484.tar.gz
7 packages and 1 specfiles checked; 0 errors, 25 warnings.


Thanks,
Warm regards,
Ankur

Comment 5 Ankur Sinha (FranciscoD) 2015-12-21 11:56:57 UTC
Uhm, this one doesn't have a reviewer yet, does that make it a dead review or one waiting for a reviewer?

Comment 6 Michael Schwendt 2015-12-27 16:02:39 UTC
It is a normal review ticket that is still waiting for a reviewer.

It doesn't classify as a stalled review yet. The policy only covers the cases when either the submitter or the reviewer is not responding anymore:
https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews

Comment 7 Michael Schwendt 2015-12-29 18:26:57 UTC
> All dependent packages will need to be rebuilt since this version
> changes the version of the provided shared object:
> libmpcdec.so.6()(64bit). The older was libmpcdec.so.5()(64bit)

Are they API compatible?

If they are not compatible, the typical solution is to create packages that don't conflict with eachother.

[...]

$ rpmls -p musepack-libmpc-1.3.0-0.1.svn484.fc23.x86_64.rpm 
-rwxr-xr-x  /usr/bin/mpc2sv8
-rwxr-xr-x  /usr/bin/mpccut
-rwxr-xr-x  /usr/bin/mpcenc
-rwxr-xr-x  /usr/bin/mpcgain
-rwxr-xr-x  /usr/bin/wavcmp

I find the naming and subpackage split somewhat unfortunate.

The  musepack-libmpc  package does not contain a "libmpc". There hasn't been one before. libmpc is a common prefix for the project libs with MPC being an abbreviation of Musepack. In SVN, libmpc is sort of an umbrella, with the sub-projects stored in various subdirs.

There are only a couple of static libs built into the various tools. There is no shared libmpcenc, for example. The old encoder was called "mppenc" as a tool without a lib, too. The musepack-libmpc package contains only tools.

The  musepack-libmpc-devel  package doesn't contain any lib either, just unversioned base headers. How much can you do with these headers only? libmpcdec-devel needs them, but hey, everything is built from a single src.rpm, so why create separate subpackages already? Would anything want only musepack-libmpc-devel?

And  libmpcdec-devel  cannot be used standalone, as it needs headers from musepack-libmpc-devel.

Finally, libmpcdec  contains not only the single shared lib but also the "mpcdec" command-line tool. It's at 1.0.0, however, not 1.3.0.

That's because the official release date is not reflected in the built rpms except for the "r475" in %release. Upstream tells:

 | musepack_src_r475.tar.gz
 |
 | Musepack SV8 libs & tools (r475)
 |
 | Stable release of Musepack SV8 libraries and tools
 | 
 |    License: BSD/GNU LGPL
 |    Release date: 2011.08.10

I don't know how important the r475 revision is for upstream when doing future releases.

SVN trunk is at r485, but the internal version of libmpcdec is unchanged. It's at 1.3.0 since 2009. The same rpm also builds the tools, each with an own version. E.g. mpcenc is at 1.30.1, mpcdec at 1.0.0. 

It would be difficult to specify a strict dependency on "libmpcdec > r484", for example, because one cannot ignore everything at the left side of Fedora's %release value for that package.

Giving the tools package the internal version of libmpcdec is strange. Note that a strict subpackage split could set an own %version for each subpackage, if needed.

Will the "Stream Version" ever change again? It's at SV8 for several years.

As a suggestion, I would name the Source RPM "musepack-sv8" (or simply "musepack") and build subpackages in the same namespace:

  musepack-sv8-libs    <-- there's just one lib so far, however
  musepack-sv8-tools   <-- there's half a dozen tools
  musepack-sv8-devel

Easier to find for users searching for musepack. Currently, if you search for "musepack", you would get musepack-libmpc not giving any hint that it contains tools, and additionally, it pulls in libmpcdec as it doesn't work without that lib.

If there ever will be more shared libs to put into individual subpackages, that could still be done if necessary.


> musepack-libmpc-1.3.0-0.1.svn484.fc22.src.rpm

About the versioning here, it doesn't follow the guidelines.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages

As libmpc has been at 1.3.0 in 2009 already, this checkout cannot be a pre-release of 1.3.0. No "0." prefix in %release. It would either need to be a post-release snapshot, or a pre-release of whatever version would be released next, e.g. 1.3.1 or 1.4.0.

Then the guidelines want the checkout date be inserted:

  1.3.0-1.20140717svn484.fc22

If the upstream release versioning scheme is unknown, %version could be set to '0', which gives you much more freedom to squeeze details into %release.

Comment 8 Zbigniew Jędrzejewski-Szmek 2018-11-14 08:23:48 UTC
If this is still needed, please post an update. I'll try to review.


Note You need to log in before you can comment on or make changes to this bug.