11:06 a.m.
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Bug #: 2565
Summary: Review-Request: spotify-client - streaming music
player
Classification: Unclassified
Product: Package Reviews
Version: Current
Platform: All
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: leamas.alec(a)gmail.com
CC: rpmfusion-package-review(a)rpmfusion.org
Native linux client for Spotify's streaming music service.
Spec: https://dl.dropbox.com/u/17870887/spotify/spotify-client.spec
Srpm:
https://dl.dropbox.com/u/17870887/spotify/spotify-client-0.8.4.103.g9cb17...
Description:
Think of Spotify as your new music collection. Your library. Only
this time your collection is vast: millions of tracks and counting.
Spotify comes in all shapes and sizes, available for your PC, Mac,
home audio system and mobile phone. Wherever you go, your music
follows you. And because the music plays live, there’s no need to wait
for downloads and no big dent in your hard drive.
Why not Fedora: closed source.
Section: nonfree (closed source)
rpmlint ~/Dropbox/Public/spotify/*
1 packages and 1 specfiles checked; 0 errors, 0 warnings
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
11:08 a.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Alec Leamas <leamas.alec(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |2
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
11:16 a.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Jussi Lehtola <jussi.lehtola(a)iki.fi> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jussi.lehtola(a)iki.fi
--- Comment #1 from Jussi Lehtola <jussi.lehtola(a)iki.fi> 2012-11-08 12:16:30 CET
---
I don't think there's a need to bundle any libraries. I've solved the issue
with symlinks:
# Install library symlinks
mkdir -p %{buildroot}%{_libdir}/spotify/
ln -s %{_libdir}/libnssutil3.so
%{buildroot}%{_libdir}/spotify/libnssutil3.so.1d
ln -s %{_libdir}/libnss3.so %{buildroot}%{_libdir}/spotify/libnss3.so.1d
ln -s %{_libdir}/libssl.so.1.0.0j
%{buildroot}%{_libdir}/spotify/libssl.so.0.9.8
ln -s %{_libdir}/libsmime3.so %{buildroot}%{_libdir}/spotify/libsmime3.so.1d
ln -s /%{_lib}/libnspr4.so %{buildroot}%{_libdir}/spotify/libnspr4.so.0d
ln -s /%{_lib}/libplc4.so %{buildroot}%{_libdir}/spotify/libplc4.so.0d
ln -s %{_libdir}/libpng12.so.0 %{buildroot}%{_libdir}/spotify/libpng12.so.0
ln -s %{_libdir}/libcrypto.so.1.0.0j
%{buildroot}%{_libdir}/spotify/libcrypto.so.0.9.8
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
11:42 a.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #2 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-08 12:42:41 CET ---
I used to do it this way way, and still does for all libs except libcef.so
(part of .deb package), libcrypto and libssl. Reason is that once upon a time
(6.4.4) there was stability problems when linking to
libssl-1.0.0/libcrypto-1.0.0 instead of using the 0.9.8 versions.
Still, I see that you are not the only one doing this. Honestly, I'm not sure
what to do. Using the "real" 0.9.8 feels "safer" in a way, and since
we're
packaging a binary blob anyway... But obviously, it's an advantage to get rid
of the bundled extra libs.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
12:19 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #3 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-08 13:19:46 CET ---
At a second thought, I think "my" way is correct for two reasons:
- Practically, at last release upstream apologized for still using 0.9.8 i. e.,
they will shift to 1.0.0 quite soon.
- The links used all points to an object with the same soname as the original.
However, the libssl 0.9.8 has not the same soname as 1.0.0, same applies to
libssl.
Together with the stability problems (above) I think this boils down to
keeping the bundled libssl/libcrypto until upstream upgrades to 1.0.0 - which
probably isn't that long.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
6:05 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Jonathan Dieter <jdieter(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |jdieter(a)gmail.com
AssignedTo|rpmfusion-package-review@rp |jdieter(a)gmail.com
|mfusion.org |
--- Comment #4 from Jonathan Dieter <jdieter(a)gmail.com> 2012-11-08 19:05:06 CET ---
I'll go ahead and take this.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
6:07 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #5 from Jonathan Dieter <jdieter(a)gmail.com> 2012-11-08 19:07:14 CET ---
(In reply to comment #3)
At a second thought, I think "my" way is correct for two
reasons:
- Practically, at last release upstream apologized for still using 0.9.8 i. e.,
they will shift to 1.0.0 quite soon.
- The links used all points to an object with the same soname as the original.
However, the libssl 0.9.8 has not the same soname as 1.0.0, same applies to
libssl.
Together with the stability problems (above) I think this boils down to
keeping the bundled libssl/libcrypto until upstream upgrades to 1.0.0 - which
probably isn't that long.
Agreed. There are generally good reasons for soname changes, so, while a
symlink might work for a while, there's no guarantee that the application won't
call some function that has changed and segfault.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
5:12 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Magnus Tuominen <magnus.tuominen(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |magnus.tuominen(a)gmail.com
--- Comment #6 from Magnus Tuominen <magnus.tuominen(a)gmail.com> 2012-11-10 18:12:52
CET ---
Requires: libpng12 on fedora 18 x86_64, other than that installs fine and seems
to be working.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9:08 a.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #7 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-11 10:08:02 CET ---
Thanks for input! And indeed, on F-18 Requires:libpng12 and also
Requires:GConf2 seems to be needed.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
11:57 a.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #8 from Jonathan Dieter <jdieter(a)gmail.com> 2012-11-12 12:57:15 CET ---
Ok, I've looked at this and found a number of things that I think need to be
changed and have tested to make sure the changes make sense:
1. I'm not a huge fan of %ghosted files and installing symlinks in %post. I
think it makes more sense to install the symlinks in %install, have them
dangle, and just make sure we require the right files (which we have to do
anyway).
2. Rather than owning each individual file in %{_libdir}/spotify-client, I
think it makes the more sense to just own the directory.
3. The problems listed in comments #6 and #7 were mainly because libcef.so
wasn't marked as executable, so rpmbuild wasn't properly generating the
automatic build requires. By making libcef.so executable and creating custom
requires and provides scripts, we get all the requires listed properly, and, as
a bonus, no longer have to manually require the symlinked libraries.
4. Rpaths are bad. See
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath. To top it
off, chrpath only works on the arch that the binary was built for, so you can
use x86_64 chrpath to change a i686 binary's rpath. This may or may not cause
problems with RPM Fusion's builders. At the very least, it prevents a user
from building a i686 package on an x86_64 system. Using LD_LIBRARY_PATH in
spotify.sh achieves the same result without needing chrpath.
5. I think it makes sense to have spotify.sh as a separate %SOURCE rather than
embedded in the spec, mainly for neatness' sake.
An updated SPEC which incorporates all of the above is here:
Spec: http://lesloueizeh.com/jdieter/spotify-client.spec
SRPM:
http://lesloueizeh.com/jdieter/spotify-client-0.8.4.103.g9cb177b.260-2.fc...
rpmlint output:
$ rpmlint spotify-client.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
$ rpmlint spotify-client-0.8.4.103.g9cb177b.260-2.fc18.src.rpm
spotify-client.src: W: strange-permission spotify_find_provides.sh 0755L
spotify-client.src: W: strange-permission spotify_find_requires.sh 0755L
1 packages and 0 specfiles checked; 0 errors, 2 warnings.
$ rpmlint spotify-client-0.8.4.103.g9cb177b.260-2.fc18.x86_64.rpm
spotify-client.x86_64: E: binary-or-shlib-defines-rpath
/usr/lib64/spotify-client/spotify ['/usr/share/spotify']
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libsmime3.so.1d ../libsmime3.so
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libplc4.so.0d ../libplc4.so
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libnspr4.so.0d ../libnspr4.so
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libnssutil3.so.1d ../libnssutil3.so
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libnss3.so.1d ../libnss3.so
spotify-client.x86_64: W: no-manual-page-for-binary spotify
1 packages and 0 specfiles checked; 1 errors, 6 warnings.
The strange-permission warnings can be ignored as the spotify_find_* scripts
need to have permissions of 755. I don't know if we should deal with the
binary-or-shlib-defines-rpath error as that would involve running chrpath on
%{_libdir}/spotify-client/spotify to remove the rpath. The
dangling-relative-symlink warnings can be ignored as the necessary files are
required by the package. And, finally, no-manual-page-for-binary can be
ignored as no man page exists.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
3:45 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #9 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-12 16:45:26 CET ---
(In reply to comment #8)
Thanks for taking time for this! Here we go:
Ok, I've looked at this and found a number of things that I think
need to be
changed and have tested to make sure the changes make sense:
1. I'm not a huge fan of %ghosted files and installing symlinks in %post. I
think it makes more sense to install the symlinks in %install, have them
dangle, and just make sure we require the right files (which we have to do
anyway).
I have considered a (and actually implemented() both ways. To me it seems
that
the risk with using dangling symlinks is a run-time failure whereas the risk
with creating links in %post is an install-time one; of these I preferred the
last. The obvious downside is added complexity in the spec. Given this, if you
still insist to use the "dangling symlinks" approach I'm certainly open to
that.
2. Rather than owning each individual file in
%{_libdir}/spotify-client, I
think it makes the more sense to just own the directory.
Agreed if we goes for the
dangling symlinks approach.
3. The problems listed in comments #6 and #7 were mainly because
libcef.so
wasn't marked as executable, so rpmbuild wasn't properly generating the
automatic build requires.
Ah... nice finding!
By making libcef.so executable and creating custom requires
and provides scripts, we get all the requires listed properly, and, as
a bonus, no longer have to manually require the symlinked libraries.
What's
the advantage to use separate find_provides/find_requires scripts
instead of using rpm's built-in filtering?
4. Rpaths are bad. See
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath.
Actually, I
disagree. Rpaths to *private* as this libs are not bad, see next
chapter
https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Li...
To top it
off, chrpath only works on the arch that the binary was built for, so you can
use x86_64 chrpath to change a i686 binary's rpath. This may or may not cause
problems with RPM Fusion's builders. At the very least, it prevents a user
from building a i686 package on an x86_64 system. Using LD_LIBRARY_PATH in
spotify.sh achieves the same result without needing chrpath.
OTOH, using
LD_LIBRARY_PATH is generally frowned upon. Still, I have considered
using it anyway for the simple reason that using chrpath means that we actually
change the binary which might become a licensing issue if the licensing
conditions are clarified upstream.
Bottom line: I buy your conclusion, but not the argument that a rpath is bad in
this case.
5. I think it makes sense to have spotify.sh as a separate %SOURCE
rather than
embedded in the spec, mainly for neatness' sake.
Agreed.
An updated SPEC which incorporates all of the above is here:
Spec: http://lesloueizeh.com/jdieter/spotify-client.spec
SRPM:
http://lesloueizeh.com/jdieter/spotify-client-0.8.4.103.g9cb177b.260-2.fc...
Thanks. Will incorporate those changes in a new version after sorting out open
issues above. Also have some other changes pending (updated wrapper script,
manpage).
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
4:18 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #10 from Jonathan Dieter <jdieter(a)gmail.com> 2012-11-12 17:18:40 CET
---
(In reply to comment #9)
(In reply to comment #8)
Thanks for taking time for this! Here we go:
> Ok, I've looked at this and found a number of things that I think need to be
> changed and have tested to make sure the changes make sense:
>
> 1. I'm not a huge fan of %ghosted files and installing symlinks in %post. I
> think it makes more sense to install the symlinks in %install, have them
> dangle, and just make sure we require the right files (which we have to do
> anyway).
I have considered a (and actually implemented() both ways. To me it seems that
the risk with using dangling symlinks is a run-time failure whereas the risk
with creating links in %post is an install-time one; of these I preferred the
last. The obvious downside is added complexity in the spec. Given this, if you
still insist to use the "dangling symlinks" approach I'm certainly open to
that.
The thing is, the target files of the symlinks are required in the rpm, so I
think both ways the risk is install-time. If that's the case, I'd definitely
prefer the dangling symlinks.
> 2. Rather than owning each individual file in
%{_libdir}/spotify-client, I
> think it makes the more sense to just own the directory.
Agreed if we goes for the dangling symlinks approach.
> 3. The problems listed in comments #6 and #7 were mainly because libcef.so
> wasn't marked as executable, so rpmbuild wasn't properly generating the
> automatic build requires.
Ah... nice finding!
> By making libcef.so executable and creating custom requires
> and provides scripts, we get all the requires listed properly, and, as
> a bonus, no longer have to manually require the symlinked libraries.
What's the advantage to use separate find_provides/find_requires scripts
instead of using rpm's built-in filtering?
Rpm's built-in filtering tries to require the libraries ending in .0d and .1d
because that's what they are in spotify and libcef.so. My scripts call rpm's
built in scripts and then filter out the .0d and .1d, making the file requires
match what's provided by the nss and nspr packages.
> 4. Rpaths are bad. See
> https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath.
Actually, I disagree. Rpaths to *private* as this libs are not bad, see next
chapter
https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Li...
> To top it
> off, chrpath only works on the arch that the binary was built for, so you can
> use x86_64 chrpath to change a i686 binary's rpath. This may or may not cause
> problems with RPM Fusion's builders. At the very least, it prevents a user
> from building a i686 package on an x86_64 system. Using LD_LIBRARY_PATH in
> spotify.sh achieves the same result without needing chrpath.
OTOH, using LD_LIBRARY_PATH is generally frowned upon. Still, I have considered
using it anyway for the simple reason that using chrpath means that we actually
change the binary which might become a licensing issue if the licensing
conditions are clarified upstream.
Bottom line: I buy your conclusion, but not the argument that a rpath is bad in
this case.
Fair enough. Honestly, I was just going to ignore it until I realized that I
couldn't build the i686 rpm on my x86_64 laptop with x86_64 chrpath installed.
> 5. I think it makes sense to have spotify.sh as a separate
%SOURCE rather than
> embedded in the spec, mainly for neatness' sake.
Agreed.
> An updated SPEC which incorporates all of the above is here:
> Spec: http://lesloueizeh.com/jdieter/spotify-client.spec
> SRPM:
> http://lesloueizeh.com/jdieter/spotify-client-0.8.4.103.g9cb177b.260-2.fc...
Thanks. Will incorporate those changes in a new version after sorting out open
issues above. Also have some other changes pending (updated wrapper script,
manpage).
Great!
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
11:20 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #11 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-13 00:20:26 CET
---
Updated, new urls:
spec: https://dl.dropbox.com/u/17870887/spotify-client/spotify-client.spec
srpm:
https://dl.dropbox.com/u/17870887/spotify-client/spotify-client-0.8.4.103...
Changelog should say it all. However, the links could be done in many ways,
none of which feels without drawbacks. I have settled for explicit filtering,
explicit requires and a check in %build that the versioned libraries are
actually symlinked. Too much code, but reasonable failsafe when dependencies
change. In this respect it's better than both my and your first approach IMHO.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
12:18 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #12 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-13 13:18:49 CET
---
After a night's sleep I can see two errors here:
- BR: chrpath (should be removed)
- Missing Provides: bundled(...) for libcrypto and libssl
Waiting for inpout before updating, though.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
1:36 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #13 from Jonathan Dieter <jdieter(a)gmail.com> 2012-11-13 14:36:39 CET
---
(In reply to comment #11)
Updated, new urls:
spec: https://dl.dropbox.com/u/17870887/spotify-client/spotify-client.spec
srpm:
https://dl.dropbox.com/u/17870887/spotify-client/spotify-client-0.8.4.103...
Changelog should say it all. However, the links could be done in many ways,
none of which feels without drawbacks. I have settled for explicit filtering,
explicit requires and a check in %build that the versioned libraries are
actually symlinked. Too much code, but reasonable failsafe when dependencies
change. In this respect it's better than both my and your first approach IMHO.
The one area where I'm still not happy with it is that it's still not properly
getting the requires for the symlinked libraries.
The following is a diff of requires for -2.fc17 versus my test package:
$ diff -urb list1.s list2.s
--- list1.s 2012-11-13 15:16:03.556731030 +0200
+++ list2.s 2012-11-13 15:16:08.359561375 +0200
@@ -1,7 +1,5 @@
/bin/sh
/bin/sh
-/bin/sh
-GConf2
libasound.so.2()(64bit)
libasound.so.2(ALSA_0.9.0rc4)(64bit)
libasound.so.2(ALSA_0.9)(64bit)
@@ -33,13 +31,29 @@
libgtk-x11-2.0.so.0()(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
-libnspr4.so
-libnss3.so
-libnssutil3.so
+libnspr4.so()(64bit)
+libnss3.so()(64bit)
+libnss3.so(NSS_3.10)(64bit)
+libnss3.so(NSS_3.11.1)(64bit)
+libnss3.so(NSS_3.11.2)(64bit)
+libnss3.so(NSS_3.11)(64bit)
+libnss3.so(NSS_3.12.1)(64bit)
+libnss3.so(NSS_3.12.3)(64bit)
+libnss3.so(NSS_3.12)(64bit)
+libnss3.so(NSS_3.2)(64bit)
+libnss3.so(NSS_3.3)(64bit)
+libnss3.so(NSS_3.4)(64bit)
+libnss3.so(NSS_3.5)(64bit)
+libnss3.so(NSS_3.6)(64bit)
+libnss3.so(NSS_3.8)(64bit)
+libnss3.so(NSS_3.9.2)(64bit)
+libnss3.so(NSS_3.9.3)(64bit)
+libnss3.so(NSS_3.9)(64bit)
+libnssutil3.so()(64bit)
+libnssutil3.so(NSSUTIL_3.12)(64bit)
libpango-1.0.so.0()(64bit)
libpangocairo-1.0.so.0()(64bit)
-libplc4.so
-libpng12
+libplc4.so()(64bit)
libpng12.so.0()(64bit)
libpng12.so.0(PNG12_0)(64bit)
libpthread.so.0()(64bit)
@@ -55,7 +69,9 @@
libresolv.so.2(GLIBC_2.9)(64bit)
librt.so.1()(64bit)
librt.so.1(GLIBC_2.2.5)(64bit)
-libsmime3.so
+libsmime3.so()(64bit)
+libsmime3.so(NSS_3.10)(64bit)
+libsmime3.so(NSS_3.2)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
@@ -74,4 +90,3 @@
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
-zenity
Note that if you're going to go the route of explicit requires, you need to
have libfoo.so()(64bit) for 64-bit packages (while it stays libfoo.so for
32-bit). Also notice that libnss and libnss-util add some funky requires which
may or may not be important.
I still think it makes more sense to use automatically generated requires to
get the information and possibly create a check that verifies that all library
links in the binary ending in .0d or .1d have a symlink. But if you really
want to go down the explicit route, at the very least you need to require the
64-bit versions of the libraries when building for 64bit.
Also note that you can drop both the GConf2 and libpng12 requires as the
libraries they provide are automatically being required already.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
1:37 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #14 from Jonathan Dieter <jdieter(a)gmail.com> 2012-11-13 14:37:36 CET
---
(In reply to comment #12)
After a night's sleep I can see two errors here:
- BR: chrpath (should be removed)
- Missing Provides: bundled(...) for libcrypto and libssl
Waiting for inpout before updating, though.
I agree on both of these. Thanks for your patience as we go back and forth on
this. ;)
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
2:20 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #15 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-13 15:20:16 CET
---
(In reply to comment #13)
[cut]
The one area where I'm still not happy with it is that it's
still not properly
getting the requires for the symlinked libraries.
The following is a diff of requires for -2.fc17 versus my test package:
$ diff -urb list1.s list2.s
--- list1.s 2012-11-13 15:16:03.556731030 +0200
+++ list2.s 2012-11-13 15:16:08.359561375 +0200
@@ -1,7 +1,5 @@
/bin/sh
/bin/sh
-/bin/sh
-GConf2
The GConf requirement is not there in "your" version?
[cut]
I still think it makes more sense to use automatically generated
requires to
get the information and possibly create a check that verifies that all library
links in the binary ending in .0d or .1d have a symlink. But if you really
want to go down the explicit route, at the very least you need to require the
64-bit versions of the libraries when building for 64bit.
Also note that you can drop both the GConf2 and libpng12 requires as the
libraries they provide are automatically being required already.
It would be easy to add (64bit) suffix as required. Still, isn't a dependency
like libpng12.so.0 always resolved to a 64-bit library on a 64-bit host? I have
no reference, but since it works...
(In reply to comment #14)
(In reply to comment #12)
[cut]
Thanks for your patience as we go back and forth on
this. ;)
Same to you. Improving a package while learning some is not bad. :)
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
2:45 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #16 from Jonathan Dieter <jdieter(a)gmail.com> 2012-11-13 15:45:50 CET
---
(In reply to comment #15)
(In reply to comment #13)
> -GConf2
The GConf requirement is not there in "your" version?
No, not shown because it was in both of our packages was
libgconf-2.so.4()(64bit), so GConf2 isn't needed.
> I still think it makes more sense to use automatically generated
requires to
> get the information and possibly create a check that verifies that all library
> links in the binary ending in .0d or .1d have a symlink. But if you really
> want to go down the explicit route, at the very least you need to require the
> 64-bit versions of the libraries when building for 64bit.
It would be easy to add (64bit) suffix as required. Still, isn't a dependency
like libpng12.so.0 always resolved to a 64-bit library on a 64-bit host? I have
no reference, but since it works...
It may work most of the time, but this makes it a guarantee. People can do
crazy stuff, so we just make sure we're being *very* specific.
(Note that it's adding ()(64bit) as a suffix.)
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
4:31 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Alec Leamas <leamas.alec(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
--- Comment #17 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-13 17:31:59 CET
---
OK, updated package in-place, same links, no release bump. Changelog:
* Tue Nov 13 2012 Alec Leamas <leamas(a)nowhere.net> - 0.8.4.103.g9cb177b.260-2
- Removing BR: chrpath.
- Cleaning up some shell code.
- Removing explicit libpng12 and GConF2 requirement (ok when libcef.se is 755).
- Adding Provides: bundled(...) for libssl.
- Adding ()(64bit suffix to explicit Requires as needed.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
6:38 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Jonathan Dieter <jdieter(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #18 from Jonathan Dieter <jdieter(a)gmail.com> 2012-11-13 19:38:42 CET
---
Ok, I think we're almost there. I'll do a formal review, hopefully tomorrow.
Quick question, though. Why do you have a variable in a comment that hold the
first part of the url? I noticed you did it in both the spec and spotify.sh.
In the spec:
# board=http://community.spotify.com/t5/Desktop-Linux
# $board/What-license-does-the-linux-spotify-client-use/td-p/173356
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
7:27 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #19 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-13 20:27:01 CET
---
(In reply to comment #18)
Ok, I think we're almost there. I'll do a formal review,
hopefully tomorrow.
Quick question, though. Why do you have a variable in a comment that hold the
first part of the url? I noticed you did it in both the spec and spotify.sh.
In the spec:
# board=http://community.spotify.com/t5/Desktop-Linux
# $board/What-license-does-the-linux-spotify-client-use/td-p/173356
I really don't like long lines... this is a way to split such while still
being able to copy-paste them.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
11:04 a.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #20 from Alec Leamas <leamas.alec(a)gmail.com> 2012-11-20 12:04:22 CET
---
There is some kind of upstream clarification on the license terms at
http://community.spotify.com/t5/Desktop-Linux/What-license-does-the-linux....
Basically, this means that the client isn't re-distributable and that this
review thus is stalled.
Rumour is that licensing conditions are under way, so I propose that we leave
this review as-is, returning to it if/when something happens with the
licensing.
There are options: one could e. g., create a package which downloads and
installs the client, this should be fine with the licensing. Spotify also seems
to develop a web-based service which should be platform-neutral.
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
1:49 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Nicolas Chauvet <kwizart(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|2 |
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
1:50 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
--- Comment #21 from Nicolas Chauvet <kwizart(a)gmail.com> 2013-05-20 15:50:02 CEST
---
Please block #2 again if licensing condition issue is solved
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
3:44 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Jakub Hrozek <jhrozek(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhrozek(a)redhat.com
--- Comment #22 from Jakub Hrozek <jhrozek(a)redhat.com> 2013-12-18 16:44:54 CET ---
Not sure if anyone is still working on this package but it crashes on start for
me on a Fedora 20 machine..
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
4:49 p.m.
New subject: [Bug 2565] Review-Request: spotify-client - streaming music player
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565
Alec Leamas <leamas.alec(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |WONTFIX
--- Comment #23 from Alec Leamas <leamas.alec(a)gmail.com> 2013-12-18 17:49:57 CET
---
This package is obsoleted by lpf-spotify-client (bug # #3033).
Closing as wontfix, a package like this is not possible due to legal concerns
(upstream is not re-distributable).
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
3775
days inactive
4180
days old
rpmfusion-developers@lists.rpmfusion.org
25 comments
1 participants
participants (1)
-
RPM Fusion Bugzilla