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.
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.
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.
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.
Spec URL: http://flyn.org/SRPMS/mt-daapd.spec SRPM URL: http://flyn.org/SRPMS/mt-daapd-0.2.4-3.fc7.src.rpm
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.
Hello, I have tried to build it in koji, but it fails: http://koji.fedoraproject.org/koji/taskinfo?taskID=289680
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.
* 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
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.
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
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.
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.
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.
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.
FYI, this package is working well for me on a F-8 x86_64 system with the aforementioned changes.
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?
(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.
(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.
(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 There are some guidelines about packaging software with offending licenses here: http://fedoraproject.org/wiki/PackagingDrafts/SourceUrl
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.
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
Created attachment 290310 [details] Avoids mt-daapd being started by default
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
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
New Package CVS Request ======================= Package Name: mt-daapd Short Description: An iTunes-compatible media server Owners: mikep Branches: F-8 InitialCC: Cvsextras Commits: yes
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.
cvs done.
(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?
Package Change Request ====================== Package Name: mt-daapd New Branches: EL-5