Bug 248277 - Review Request: mt-daapd - An iTunes-compatible media server
Review Request: mt-daapd - An iTunes-compatible media server
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Sergio Pascual
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-14 22:52 EDT by W. Michael Petullo
Modified: 2008-04-29 11:14 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-25 07:31:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
sergio.pasra: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
Avoids mt-daapd being started by default (444 bytes, patch)
2007-12-23 14:17 EST, Sergio Pascual
no flags Details | Diff

  None (edit)
Description W. Michael Petullo 2007-07-14 22:52:51 EDT
Spec URL: http://flyn.org/SRPMS/mt-daapd.spec
SRPM URL: http://flyn.org/SRPMS/mt-daapd-0.2.4-1.fc7.src.rpm
Description: The purpose of this project is built the best server software to serve digital music to the Roku Soundbridge and iTunes; to be able to serve the widest variety of digital music content over the widest range of devices.
Comment 1 Peter Gordon 2007-07-14 23:03:19 EDT
Not a full review, but there are some things that need fixing in your spec:

(1) Don't use the %makeinstall macro if at all possible. Use '%make
DESTDIR=%{buildroot} install' instead. See
http://fedoraproject.org/wiki/PackagingDrafts/MakeInstall for more information.

(2) Your cp invocations in %install should use the '-P' parameter to preserve
timestamp information.

(3) You are using hardcoded paths instead of macro-based paths: E.g.,
"/usr/sbin" instead of "%{_sbindir}" and the like. See
http://fedoraproject.org/wiki/Packaging/RPMMacros for a full list.
Comment 2 Peter Lemenkov 2007-07-15 16:13:05 EDT
Package name doesn't match upstream (mt-daapd not so long ago was renamed to
Firefly).

You should add 

Provides: mt-daapd

instead of using old project name.
Comment 3 W. Michael Petullo 2007-07-15 21:35:44 EDT
Spec URL: http://flyn.org/SRPMS/mt-daapd.spec
SRPM URL: http://flyn.org/SRPMS/mt-daapd-0.2.4-2.fc7.src.rpm
This version fixes the issues raised in comment #1.  As far as comment #2, as of
version 0.2.4 (the latest stable version) this project was still called
mt-daapd.  I will change the package name to firefly when a stable version is
released that bears that name.
Comment 4 W. Michael Petullo 2007-07-21 21:44:12 EDT
Spec URL: http://flyn.org/SRPMS/mt-daapd.spec
SRPM URL: http://flyn.org/SRPMS/mt-daapd-0.2.4-3.fc7.src.rpm
Comment 5 W. Michael Petullo 2007-12-10 04:36:15 EST
Spec URL: http://flyn.org/SRPMS/mt-daapd.spec
SRPM URL: http://flyn.org/SRPMS/mt-daapd-0.2.4.1-1.fc8.src.rpm

A new upstream version was released. The upstream package name is still mt-daapd.
Comment 6 Sergio Pascual 2007-12-12 11:42:39 EST
Hello, I have tried to build it in koji, but it fails:

http://koji.fedoraproject.org/koji/taskinfo?taskID=289680
Comment 7 W. Michael Petullo 2007-12-13 06:27:04 EST
Spec URL: http://flyn.org/SRPMS/mt-daapd.spec
SRPM URL: http://flyn.org/SRPMS/mt-daapd-0.2.4.1-2.fc8.src.rpm

BuildRequire zlib-devel. This should fix the error in comment #6.
Comment 8 Sergio Pascual 2007-12-14 20:53:37 EST
* rpmlint says the following in my system:

 - mt-daapd.i386: W: incoherent-version-in-changelog 0.4.2.1-2 0.2.4.1-2.fc7

 - mt-daapd.i386: W: invalid-license GPL
   GPL alone is not valid:
   http://fedoraproject.org/wiki/Packaging/LicensingGuidelines

 - mt-daapd.i386: W: conffile-without-noreplace-flag /etc/mt-daapd.conf 
   mt-daapd.i386: W: conffile-without-noreplace-flag /etc/mt-daapd.playlist
    This can be fixed changing:
    %config %{_sysconfdir}/mt-daapd.conf
    %config %{_sysconfdir}/mt-daapd.playlist
    by
    %config(noreplace) %{_sysconfdir}/mt-daapd.conf
    %config(noreplace) %{_sysconfdir}/mt-daapd.playlist

  - mt-daapd.i386: W: service-default-enabled /etc/rc.d/init.d/mt-daapd:
  
   Only services, which are really required for a vital system, should define  
           runlevels here. Please review the guidelines for initscripts:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-a6d7a1ed9d77dbb8d4af067378a79b838aebb20a
And there is also a packaging draft:
http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript

* I would change the Group to Applications/Multimedia, if you don't have a
better idea

* mt-daapd.conf contains passwords in clear text. For security reasons I think
is better to install it with at least 640 permissions
Comment 9 W. Michael Petullo 2007-12-15 09:27:24 EST
Spec URL: http://flyn.org/SRPMS/mt-daapd.spec
SRPM URL: http://flyn.org/SRPMS/mt-daapd-0.2.4.1-3.fc8.src.rpm

Addresses comment #8.
Comment 10 Sergio Pascual 2007-12-16 18:25:25 EST
There is a problem with the license, I'm afraid. Some of the files are licensed
under the Apple Public Source License Version 2.0 (mDNS.c for example) and other
are licensed under the GPL. But this two licenses are incompatible (see 
http://fedoraproject.org/wiki/Licensing#SoftwareLicenses).

I'm setting fe-legal tracker
Comment 11 Sergio Pascual 2007-12-18 04:41:44 EST
I've written a message to the fedora-legal list, asking about the situation of
mt-daapd. You can see the message and the answer here:

https://www.redhat.com/archives/fedora-legal-list/2007-December/msg00008.html

I'm sorry, but the combination of Apple GNU Licenses seems to be non distributable.
Comment 12 W. Michael Petullo 2007-12-18 07:52:34 EST
Okay. It looks like Apple has relicensed Bonjour (the Apple licensed source
files come from this package) to the Apache License, Version 2.0. This is
compatible with GPLv3, according to
http://fedoraproject.org/wiki/Licensing#SoftwareLicenses (but not GPLv2). That
may provide a solution. Another possibility is to replace Apple code with avahi
code. I will contact the author to see if we can find a solution.
Comment 13 Jeffrey C. Ollie 2007-12-19 09:52:22 EST
I'd recommend changing the BR on avahi-compat-howl-devel to avahi-devel and
using --enable-avahi --enable-mdns on the %configure line.  Also, BR
libogg-devel and libvorbis-devel and addding --enable-oggvorbis to the
%configure line will allow mt-daapd to stream OGG/Vorbis files and be able to
extract metadata.
Comment 14 Jeffrey C. Ollie 2007-12-19 10:02:06 EST
Hmm... nevermind about the --enable-mdns - it looks as if the mDNS code isn't
used  (or even compiled) if --enable-avahi is used.  Looks to me like the author
included the code in case a platform didn't have Avahi or Howl installed on the
system.
Comment 15 Jeffrey C. Ollie 2007-12-19 10:32:56 EST
FYI, this package is working well for me on a F-8 x86_64 system with the
aforementioned changes.
Comment 16 W. Michael Petullo 2007-12-19 12:40:11 EST
In reference to comment #14, I received a reply from the author and he
recommended using the avahi code as well. I have three questions:

1. Is it legally okay to ship an SRPM with license issues (a la GPLv2 + Apache)
if the corresponding code is disabled at compile time?

2. If the answer to 1 is no, then is it okay to ship an SRPM with license issues
if the correspoinding code is removed with a patch by the build process?

3. If the answer to 1 and 2 is no, then would we need to fork mt-daapd to get it
into Fedora?
Comment 17 Jeffrey C. Ollie 2007-12-19 13:40:14 EST
(In reply to comment #16)
> In reference to comment #14, I received a reply from the author and he
> recommended using the avahi code as well. I have three questions:
> 
> 1. Is it legally okay to ship an SRPM with license issues (a la
> GPLv2 + Apache) if the corresponding code is disabled at compile
> time?

I don't have a reference handy, but I think that the answer is no.

> 2. If the answer to 1 is no, then is it okay to ship an SRPM with
> license issues if the correspoinding code is removed with a patch by
> the build process?
> 
> 3. If the answer to 1 and 2 is no, then would we need to fork
> mt-daapd to get it into Fedora?

The Asterisk package faced similar issues (iLBC codecs).  Instead of
shipping the upstream tarball I made a script that removes the
offending source from the upstream tarball and creates a new tarball.
I then packaged the new tarball.  You need to package the script as
well.  So, I guess it's technically a fork but it's not like we're
making major changes to the code.
Comment 18 Jeffrey C. Ollie 2007-12-19 13:49:40 EST
(In reply to comment #17)
> (In reply to comment #16)
> > In reference to comment #14, I received a reply from the author and he
> > recommended using the avahi code as well. I have three questions:
> > 
> > 1. Is it legally okay to ship an SRPM with license issues (a la
> > GPLv2 + Apache) if the corresponding code is disabled at compile
> > time?
> 
> I don't have a reference handy, but I think that the answer is no.

Actually after thinking about this some more, I think that the answer
may be yes.  Since the Apple license is free enough to qualify for
Fedora, we can ship the code.  What's prohibited is combining the
Apple licensed code with GPL licensed code.  Since we can do that by
choosing our configure options properly I think that we're ok.  The
Asterisk situation was different in that some of the code in Asterisk
had a license that prohibited Fedora from shipping it.

It'd still be good to ping Tom Callaway about this since he deals with
this stuff more often.  It'd be even better for upstream to get the
licensing figured out properly.
Comment 19 Sergio Pascual 2007-12-19 14:07:30 EST
(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > In reference to comment #14, I received a reply from the author and he
> > > recommended using the avahi code as well. I have three questions:
> > > 
> > > 1. Is it legally okay to ship an SRPM with license issues (a la
> > > GPLv2 + Apache) if the corresponding code is disabled at compile
> > > time?
> > 
> > I don't have a reference handy, but I think that the answer is no.
> 
> Actually after thinking about this some more, I think that the answer
> may be yes.  Since the Apple license is free enough to qualify for
> Fedora, we can ship the code.  What's prohibited is combining the
> Apple licensed code with GPL licensed code.  Since we can do that by
> choosing our configure options properly I think that we're ok.  The
> Asterisk situation was different in that some of the code in Asterisk
> had a license that prohibited Fedora from shipping it.
> 
> It'd still be good to ping Tom Callaway about this since he deals with
> this stuff more often.  It'd be even better for upstream to get the
> licensing figured out properly.
> 

Probably the best is to ask in fedora-legal-list@redhat.com

There are some guidelines about packaging software with offending licenses here: 
http://fedoraproject.org/wiki/PackagingDrafts/SourceUrl



Comment 20 W. Michael Petullo 2007-12-19 15:15:41 EST
Spec URL: http://flyn.org/SRPMS/mt-daapd.spec
SRPM URL: http://flyn.org/SRPMS/mt-daapd-0.2.4.1-4.fc8.src.rpm

- Avoid licensing issues by building with avahi code.
- Sopport Vorbis.
Comment 21 Sergio Pascual 2007-12-23 14:16:10 EST
There are still some issues:

* License text in GPLed files says "version 2 of the License, or (at your
option) any later version". This implies that the License tag is GPLv2+ and not
GPLv2

* Requires(post): /sbin/chkconfig is missing

* mt-daapd.playlist is installed by default with 755 permissions. Please install
it with the usual 644

* This post rule is missing
%post
/sbin/chkconfig --add mt-daapd

* To avoid having mt-daapd started by default, you have to patch the init script
and change the line:
# chkconfig: 2345 85 15
by
# chkconfig: - 85 15
Comment 22 Sergio Pascual 2007-12-23 14:17:39 EST
Created attachment 290310 [details]
Avoids mt-daapd being started by default
Comment 23 W. Michael Petullo 2007-12-24 04:22:00 EST
Spec URL: http://flyn.org/SRPMS/mt-daapd.spec
SRPM URL: http://flyn.org/SRPMS/mt-daapd-0.2.4.1-5.fc8.src.rpm
Comment 24 Sergio Pascual 2007-12-24 05:55:57 EST
source files match upstream
package meets naming and versioning guidelines
specfile is properly named, is cleanly written and uses macros consistently
dist tag is present
the package must meet the  Packaging Guidelines
build root is correct:
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
license field matches the actual license 
license is open source-compatible.  GPL included in package. (COPYING)

latest version is being packaged
BuildRequires are proper
compiler flags are appropriate
%clean is present
package builds in mock ( )
package installs properly
debuginfo package looks complete
rpmlint is silent. NO, but the error is intended. OK
E: non-readable /etc/mt-daapd.conf 0640

final provides and requires are sane
%check is present and all tests pass: Not applicable
no shared libraries are added to the regular linker search paths.
owns the directories it creates.
doesn't own any directories it shouldn't.
no duplicates in %files.
file permissions are appropriate.

scriptlets present OK
code, not content.
documentation is small, so no -docs subpackage is necessary.
%docs are not necessary for the proper functioning of the package.
no headers.
no pkgconfig files.
no libtool .la droppings.
not a GUI app.

The INSTALL file in %doc contains generic installation instructions and it's not
needed, you may consider remove it. 

APPROVED
Comment 25 W. Michael Petullo 2007-12-24 12:23:31 EST
New Package CVS Request
=======================
Package Name: mt-daapd
Short Description: An iTunes-compatible media server
Owners: mikep
Branches: F-8
InitialCC:
Cvsextras Commits: yes
Comment 26 Tom "spot" Callaway 2007-12-24 15:12:44 EST
If you don't have a comment in the spec file explaining that you're working
around the license incompatibility issue by choosing a specific configure
option, please add it.
Comment 27 Tom "spot" Callaway 2007-12-24 15:17:34 EST
cvs done.
Comment 28 Peter Lemenkov 2007-12-25 04:35:51 EST
(In reply to comment #25)
> New Package CVS Request
> =======================
> Package Name: mt-daapd
> Short Description: An iTunes-compatible media server
> Owners: mikep
> Branches: F-8
> InitialCC:
> Cvsextras Commits: yes

Do you have plans to create branches for EPEL as well?
Comment 29 W. Michael Petullo 2008-04-28 15:47:46 EDT
Package Change Request
======================
Package Name: mt-daapd
New Branches: EL-5
Comment 30 Kevin Fenzi 2008-04-29 11:14:20 EDT
cvs done.

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