Bug 973069 - Review Request:lpf-spotify-client - build and install spotify-client rpm
Review Request:lpf-spotify-client - build and install spotify-client rpm
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Simone Caronni
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-11 04:28 EDT by Alec Leamas
Modified: 2014-02-28 09:58 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-28 09:58:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
negativo17: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Alec Leamas 2013-06-11 04:28:11 EDT
Spec URL: http://leamas.fedorapeople.org/lpf-spotify-client/2/lpf-spotify-client.spec
SRPM URL: http://leamas.fedorapeople.org/lpf-spotify-client/2/lpf-spotify-client-0.9.0.133.gd18ed58.259-1.fc18.src.rpm
Description:
Bootstrap package allowing the lpf system to build the
non-redistributable spotify-client package.

Fedora Account System Username: leamas

The spotify-client is a binary application which I originally submitted to rpmfusion [1]. After the license conditions was clarified as non-redistributable a recipe was published to build a rpm from the spec in [2]. This recipe has now been used through one upstream and two Fedora releases. 

Instead of creating a specific package which downloads and builds the spotify package I tried to create a more general framework in lpf (see dependencies). Basically, this package is a lpf recipe how to build the non-redistributable, binary blob application spotify-client. The spotify-client.spec, the target package otherwise in the srpm is in [3]

[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
[2] http://community.spotify.com/t5/Help-Desktop-Linux-Mac-and/Linux-Fedora-RPM-package-for-F17-F18/m-p/191612
[3] http://leamas.fedorapeople.org/lpf-spotify-client/2/spotify-client.spec
Comment 1 Alec Leamas 2013-06-11 04:40:55 EDT
Since the legal aspect of this will come up sooner or later, and I frankly don't know myself I'm blocking this on FE-Legal. 

The issue: can a package which is OK by itself but has the sole purpose to build a package which contains binary code (thus violating the guidelines) and is non-redistributable go into fedora?
Comment 2 Tom "spot" Callaway 2013-06-26 13:07:27 EDT
In this specific case, Red Hat is uncomfortable with including this "recipe" without explicit confirmation from Spotify that it is acceptable.
Comment 3 Alec Leamas 2013-06-26 14:58:40 EDT
I certainly understand that. What I've got so far is [1]. Do you think this is clear enough (it could certainly be more clear...) ?

A sidenote: in their forum I have a thread [2] with a manual recipe how to build a rpm using the spec + some CLI magic. This thread is well-known and obviously accepted. The lpf package basically just automates this recipe, which in my (non-lawyer) eyes seems like more or less the same thing from a law perspective. (?)


--alec

PS: Sorry, I'm no native English speaker. It becomes just so embarrassing clear when trying to discuss legal stuff "blushes"

[1]: http://community.spotify.com/t5/Help-Desktop-Linux-Mac-and/What-license-does-the-linux-spotify-client-use/td-p/17335[

[2]: http://community.spotify.com/t5/Help-Desktop-Linux-Mac-and/Linux-Fedora-RPM-package-for-F17-F18/m-p/191612#M8425
Comment 4 Tom "spot" Callaway 2013-06-26 15:12:32 EDT
You need to explain to Spotify clearly and simply, what you are doing and how Fedora would be distributing it (and not the Spotify client), then ask for someone from Spotify to confirm that they are okay with it.

Show us that and we'll let this proceed.
Comment 5 Alec Leamas 2013-06-26 15:18:02 EDT
OK, fair enough, I'll  try to do that. However, it might take some time. They are not to responsive in general, and since they are Swedes a lot of them are on long summer holidays now. We'll see...
Comment 6 Alec Leamas 2013-10-11 07:26:37 EDT
Three months... but at last a reply [1]. In my eyes, this looks good. And in yours?


[1] http://community.spotify.com/t5/Help-Desktop-Linux-Mac-and/What-license-does-the-linux-spotify-client-use/m-p/557782?nobounce#M63523
Comment 7 Tom "spot" Callaway 2013-10-11 07:34:16 EDT
The only concern I have is "for personal use". I'm not sure it is possible for us to comply with that license restriction.
Comment 8 Alec Leamas 2013-10-11 07:44:15 EDT
Note that the limitation is about what's produced by lpf-spotify, not lpf-spotify  itself. We distribute an open-source tool which produces non-free software. Isn't this somewhat similar to an open-sourced client to a service which is not free?
Comment 9 Tom "spot" Callaway 2013-10-11 07:47:33 EDT
Yes, but they have only granted permission for lpf-spotify to perform "automatic downloading and repackaging of the spotify software for personal use"

They're effectively imposing a use restriction on the act of downloading/repackaging, and I don't think we can do that.
Comment 10 Alec Leamas 2013-10-11 08:10:34 EDT
Hm...I take your message as this can't be hosted on fedora with this limitation ("maybe" is worst possible outcome here). 

Since this is not what they intend: Can you think of any wording which resolves this while still enforcing a non-redistribution condition on the created rpms?
Comment 11 Tom "spot" Callaway 2013-10-11 09:11:43 EDT
I need to think about this some more. This is an entirely new case. We'd be telling consumers of Fedora "this file must only be executed/run for personal use", which is generally incompatible with every other file in Fedora.
Comment 12 Alec Leamas 2013-10-16 06:22:45 EDT
Ping. And a thought: isn't this just like it always is when you  have a tool which uses material from someone to build something else: you have to respect the original copyright owner? 

E. g., if you use gcc to compile some sources you might very well end up in that the compiled program is restricted one way or another and even being non-free. But this is certainly not being seen as a problem with gcc. To be frank, lpf-spotify looks similar to me - it's just that the usecase is much more restricted  than that for a general tool such as a compiler.
Comment 13 Tom "spot" Callaway 2013-10-16 19:03:15 EDT
The catch is that they are saying that the script may only be used for personal use, _not_ just the files it downloads.

It is different from gcc, because the script only does one thing, and the Spotify folks are saying it is only okay to do that one thing if there is a restriction on personal use.

I think it might be possible that what they meant to say is that unrestricted use of the download/packaging script is fine as long as the end-user complies with the spotify EULA, but that's not quite what they said, or at least, it could be interpreted either way.

If you can have them clarify that they meant for the "personal use" restriction to apply to the spotify client bits (and not for the script), I think I'd be okay to clear this. Otherwise, I'm going to have to assume the opposite was their intention, and block it.
Comment 14 Alec Leamas 2013-10-24 07:21:19 EDT
Spotify is ready to amend their license statement with (private message):

----
Spotify confirms that the personal use restriction does not apply for the open-source downloader. The repackaged Spotify software is for personal use only and in accordance with the Spotify end user agreement.
----

Would this make lpf-spotify legally OK?
Comment 15 Tom "spot" Callaway 2013-10-24 08:04:42 EDT
Yes. Lifting FE-Legal.
Comment 17 Simone Caronni 2013-10-24 09:34:04 EDT
Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed

Issues:
=======
- Package does not contain duplicates in %files.
  Note: warning: File listed twice: /var/lib/lpf/packages/spotify-client/state
  See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles

===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[!]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[!]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. No licenses
     found. Please check the source files for licenses manually.
[x]: Package requires other packages for directories it uses.
     Note: No known owner of /usr/share/lpf, /var/lib/lpf/packages,
     /var/lib/lpf, /usr/share/lpf/packages
[x]: Package must own all directories that it creates.
     Note: Directories without known owners: /var/lib/lpf,
     /var/lib/lpf/packages, /usr/share/lpf, /usr/share/lpf/packages
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[!]: Package consistently uses macros (instead of hard-coded directory names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package contains desktop file if it is a GUI application.
[x]: Package installs a %{name}.desktop using desktop-file-install or desktop-
     file-validate if there is such a file.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 0 bytes in 0 files.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[!]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Package functions as described.
[x]: Latest version is packaged.
[!]: Package does not include license text files separate from upstream.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[-]: Packages should try to preserve timestamps of original installed files.
[x]: Spec use %global instead of %define unless justified.
     Note: %define requiring justification: %define target_pkg %(t=%{name};
     echo ${t#lpf-})
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present (not strictly required in GL).
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Fully versioned dependency in subpackages if applicable.
[!]: SourceX tarball generation or download is documented.
[!]: SourceX is a working URL.

===== EXTRA items =====

Generic:
[!]: Spec file according to URL is the same as in SRPM.
     Note: 0 or more than one spec file in srpm(!)
     See: (this test has no URL)
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.

Rpmlint
-------
Checking: lpf-spotify-client-0.9.4.183.g644e24e.428-1.fc19.noarch.rpm
          lpf-spotify-client-0.9.4.183.g644e24e.428-1.fc19.src.rpm
lpf-spotify-client.noarch: W: spelling-error %description -l en_US redistributable -> redistribute, redistribution, attributable
lpf-spotify-client.noarch: W: invalid-url URL: http://leamas.fedorapeople.org/spotify/0.9.0/lpf-spotify-client.spec HTTP Error 404: Not Found
lpf-spotify-client.noarch: W: no-documentation
lpf-spotify-client.noarch: W: non-standard-uid /var/lib/lpf/packages/spotify-client pkg-build
lpf-spotify-client.noarch: W: non-standard-gid /var/lib/lpf/packages/spotify-client pkg-build
lpf-spotify-client.noarch: E: non-standard-dir-perm /var/lib/lpf/packages/spotify-client 0775L
lpf-spotify-client.noarch: W: non-standard-uid /var/lib/lpf/packages/spotify-client/state pkg-build
lpf-spotify-client.noarch: W: non-standard-gid /var/lib/lpf/packages/spotify-client/state pkg-build
0 packages and 0 specfiles checked; 1 errors, 7 warnings.

Rpmlint (installed packages)
----------------------------
# rpmlint lpf-spotify-client
lpf-spotify-client.noarch: W: spelling-error %description -l en_US redistributable -> redistribute, redistribution, attributable
lpf-spotify-client.noarch: W: invalid-url URL: http://leamas.fedorapeople.org/spotify/0.9.0/lpf-spotify-client.spec HTTP Error 404: Not Found
lpf-spotify-client.noarch: W: no-documentation
lpf-spotify-client.noarch: W: non-standard-uid /var/lib/lpf/packages/spotify-client pkg-build
lpf-spotify-client.noarch: W: non-standard-gid /var/lib/lpf/packages/spotify-client pkg-build
lpf-spotify-client.noarch: E: non-standard-dir-perm /var/lib/lpf/packages/spotify-client 0775L
lpf-spotify-client.noarch: W: non-standard-uid /var/lib/lpf/packages/spotify-client/state pkg-build
lpf-spotify-client.noarch: W: non-standard-gid /var/lib/lpf/packages/spotify-client/state pkg-build
1 packages and 0 specfiles checked; 1 errors, 7 warnings.
# echo 'rpmlint-done:'

Requires
--------
lpf-spotify-client (rpmlib, GLIBC filtered):
    /bin/sh
    lpf

Provides
--------
lpf-spotify-client:
    lpf-spotify-client

Generated by fedora-review 0.5.0 (920221d) last change: 2013-08-30
Command line :/usr/bin/fedora-review --mock-config fedora-19-x86_64 -b 973069 -L .
Buildroot used: fedora-19-x86_64
Active plugins: Generic, Shell-api
Disabled plugins: Java, C/C++, Python, SugarActivity, Perl, R, PHP, Ruby
Disabled flags: EPEL5, EXARCH, DISTTAG

Built with local dependencies:
    /home/slaanesh/Documents/fedora/./lpf-0-3.46ae0c3.fc19.src.rpm
    /home/slaanesh/Documents/fedora/./lpf-0-3.46ae0c3.fc19.noarch.rpm
Comment 18 Simone Caronni 2013-10-24 09:34:27 EDT
Issues:

> [!]: If (and only if) the source package includes the text of the license(s)
>      in its own file, then that file, containing the text of the license(s)
>      for the package is included in %doc.
> [!]: License field in the package spec file matches the actual license.
>      Note: Checking patched sources after %prep for licenses. No licenses
>      found. Please check the source files for licenses manually.
> [!]: If the source package does not include license text(s) as a separate file
>      from upstream, the packager SHOULD query upstream to include it.
> [!]: Package does not include license text files separate from upstream.

The license is MIT, but there's no license file installed. Please provide one in %doc.

> [!]: Package consistently uses macros (instead of hard-coded directory names).

On line 33, please use %{_datadir} instead of /usr/share.
On line 47 and 48 please use %{_sharedstatedir} instead of /var/lib.

> [!]: SourceX tarball generation or download is documented.
> [!]: SourceX is a working URL.
> [!]: Spec file according to URL is the same as in SRPM.
>      Note: 0 or more than one spec file in srpm(!)
>      See: (this test has no URL)

There is no documentation nor procedure on how to regenerate the source tarball.

Please provide an external script in the source (like Mesa) or provide comments in the SPEC file. Also the versioning needs documenting, where does 0.9.4.183.g644e24e.428 come from? I assume it's a snapshot, so if you paste commands to regenerate the tarball that would be ok.

I assume you can move the URL to Source0, etc.

> Group:          Development/Tools

Please remove the Group tag, is needed only on EPEL 5.

> %description

Please make the first description line a bit longer so that it goes nearer to the 80 columns limit.

> Package does not contain duplicates in %files.
>  Note: warning: File listed twice: /var/lib/lpf/packages/spotify-client/state
>  See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles

You can remove line 48; line 47 already includes everything beneath the directory listed. To make it list only one directory (so you can keep line 48) please use the %dir macro which only adds the directory and not the contents.

Rpmlint issues:
> lpf-spotify-client.noarch: W: invalid-url
> URL: http://leamas.fedorapeople.org/spotify/0.9.0/lpf-spotify-client.spec
> HTTP Error 404: Not Found

Please fix, see above comment for source. All the other warnings do not apply here so packages are ok.
Comment 19 Alec Leamas 2013-10-24 10:22:57 EDT
(In reply to Simone Caronni from comment #18)
> Issues:
[cut]
> The license is MIT, but there's no license file installed. Please provide
> one in %doc.
Done.

> > [!]: Package consistently uses macros (instead of hard-coded directory names).
> 
> On line 33, please use %{_datadir} instead of /usr/share.
> On line 47 and 48 please use %{_sharedstatedir} instead of /var/lib.
I'd prefer not to:  http://fedoraproject.org/wiki/Packaging:Guidelines#macros

> 
> > [!]: SourceX tarball generation or download is documented.
> > [!]: SourceX is a working URL.
> > [!]: Spec file according to URL is the same as in SRPM.
> >      Note: 0 or more than one spec file in srpm(!)
> >      See: (this test has no URL)
> 
> There is no documentation nor procedure on how to regenerate the source
> tarball.

I guess this is about spotify-client.spec? If so, there is no need for this since the Source: url is OK: 
http://fedoraproject.org/wiki/Packaging:SourceURL#Github


> Please provide an external script in the source (like Mesa) or provide
> comments in the SPEC file. Also the versioning needs documenting, where does
> 0.9.4.183.g644e24e.428 come from? I assume it's a snapshot, so if you paste
> commands to regenerate the tarball that would be ok.

The version field is the upstream spotify version, I don't really see what kind of comment that would be? Added the fact that this is indeed upstream version.

[cut]

> > Group:          Development/Tools
Isn't Group: tag allowed?:
http://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag

> > %description
> 
> Please make the first description line a bit longer so that it goes nearer
> to the 80 columns limit.
Done.

> 
> > Package does not contain duplicates in %files.
> >  Note: warning: File listed twice: /var/lib/lpf/packages/spotify-client/state
> >  See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles
> 
> You can remove line 48; line 47 already includes everything beneath the
> directory listed. To make it list only one directory (so you can keep line
> 48) please use the %dir macro which only adds the directory and not the
> contents.
Yes, but I need to set the permissions correct. If I remove that line I need to add a %defattr(664)+ %attr(644)  to all files. Certainly possible, but better? "scratches my head"

BTW, on f20 rpmlint crashes on this ;)

> Rpmlint issues:
> > lpf-spotify-client.noarch: W: invalid-url
> > URL: http://leamas.fedorapeople.org/spotify/0.9.0/lpf-spotify-client.spec
> > HTTP Error 404: Not Found> 
> Please fix, see above comment for source. All the other warnings do not
> apply here so packages are ok.

Fixed for now, need to create a better upstream on github before importing, though.

In future, it would be good you mentioned which spec you are referring to.. New problem ,for sure.

Updated in-place, same links, changelog updated.
Comment 20 Simone Caronni 2013-10-24 10:37:37 EDT
(In reply to Alec Leamas from comment #19)
> > On line 33, please use %{_datadir} instead of /usr/share.
> > On line 47 and 48 please use %{_sharedstatedir} instead of /var/lib.
> I'd prefer not to:  http://fedoraproject.org/wiki/Packaging:Guidelines#macros

Ok, no problem.

> > > Group:          Development/Tools
> Isn't Group: tag allowed?:
> http://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag

Ok, as you prefer. Are you planning to build this also in EPEL?

> > > Package does not contain duplicates in %files.
> > >  Note: warning: File listed twice: /var/lib/lpf/packages/spotify-client/state
> > >  See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles
> > 
> > You can remove line 48; line 47 already includes everything beneath the
> > directory listed. To make it list only one directory (so you can keep line
> > 48) please use the %dir macro which only adds the directory and not the
> > contents.
> Yes, but I need to set the permissions correct. If I remove that line I need
> to add a %defattr(664)+ %attr(644)  to all files. Certainly possible, but
> better? "scratches my head"

Ok.
Comment 21 Simone Caronni 2013-10-24 10:48:34 EDT
> The version field is the upstream spotify version, I don't really see what
> kind of comment that would be? Added the fact that this is indeed upstream
> version.

Ok after the comment you've added.

I'm not following you on these comments, can you explain a bit more?

> > > [!]: SourceX tarball generation or download is documented.
> > > [!]: SourceX is a working URL.
> > > [!]: Spec file according to URL is the same as in SRPM.
> > >      Note: 0 or more than one spec file in srpm(!)
> > >      See: (this test has no URL)
> > 
> > There is no documentation nor procedure on how to regenerate the source
> > tarball.
> 
> I guess this is about spotify-client.spec? If so, there is no need for this
> since the Source: url is OK: 
> http://fedoraproject.org/wiki/Packaging:SourceURL#Github

I haven't look at the spec file inside the package, I'm referring to the contents of the package, in particular:

Source0:        spotify-client.spec
Source1:        eula.txt

Where do they come from? Handwritten? Taken from a website? Usually Source files have a URL for downloading or comments in the SPEC file or instructions on how to generate them (http://fedoraproject.org/wiki/Packaging:SourceURL).

> In future, it would be good you mentioned which spec you are referring to..
> New problem ,for sure.

I haven't looked at the bundled spec file; but I assume the review is only for the package that is actually built and assembled in the Fedora infrastructure. Should I also look at the lpf spec file (Source0)?
Comment 22 Alec Leamas 2013-10-24 11:17:09 EDT
(In reply to Simone Caronni from comment #21)


> > 
> > I guess this is about spotify-client.spec? If so, there is no need for this
> > since the Source: url is OK: 
> > http://fedoraproject.org/wiki/Packaging:SourceURL#Github
> 
> I haven't look at the spec file inside the package, I'm referring to the
> contents of the package, in particular:
> 
> Source0:        spotify-client.spec
> Source1:        eula.txt
> 
> Where do they come from? Handwritten? Taken from a website? Usually Source
> files have a URL for downloading or comments in the SPEC file or
> instructions on how to generate them
> (http://fedoraproject.org/wiki/Packaging:SourceURL).
>

OK, see your point and yes, this is the very thing here. Normally, you don't ask for the upstream for the spec, it just exists somehow. However, in this case we cant allow spotify-client to go into fedora, so I sort of wrap it into lpf-spotify-client. And spotify-client.spec becomes Source0:. From my perspective, this is just how it is, but it's not obvious. 

I suggest that we see this package as the spotify-client package with a lpf wrapper. From this perspective spotify-client.spec "just exists". There is no other upstream for this spec, for sure. Given this, I'll gladly accept any proposal for a comment to Source0. I just can't come up with something sensible to write.

The eula needs a comment, for sure. Added. Long links is  a pain.

Same links, changelog updated.
Comment 23 Simone Caronni 2013-10-25 05:41:12 EDT
It's ok, now it's clear.

I think that if you add something along the line of:

# There is no source, only the spec file which allows building the
# non-redistributable package.

or anything like that, it would be ok.

Thanks for the package.

APPROVED.
Comment 24 Alec Leamas 2013-10-25 05:59:40 EDT
Thanks for the review. Will fix the source comment and add a README - how to actually use this is not really obvious :)
Comment 25 Alec Leamas 2013-10-25 06:03:58 EDT
New Package SCM Request
=======================
Package Name: lpf-spotify-client
Short Description: Spotify music player native client package bootstrap
Owners: leamas
Branches: f19 f20
InitialCC:
Comment 26 Jon Ciesla 2013-10-25 07:55:09 EDT
Git done (by process-git-requests).
Comment 27 Simone Caronni 2014-02-28 09:58:56 EST
Closing, package was imported in RPMFusion months ago.

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