Spec URL: http://rpm.rutgers.edu/fedora/songbird.spec SRPM URL: http://rpm.rutgers.edu/fedora/songbird-0.6.1-1.fc9.src.rpm Description: Songbird provides a public playground for Web media mash-ups by providing developers with both desktop and Web APIs, developer resources and fostering Open Web media standards. Songbird is listed on the Package Maintainers wish list. It has come a long way since early development, does not require mp3 support, and any browser plugins are optional to the user. Note: This is my first package submission and I am seeking a sponsor. I am aware of a couple .spec/build issues, but I thought it best to begin the review process now.
To clarify on the x86_64 debug comment in the spec file: /usr/lib/rpm/debugedit is called during the debug creation process and it fails to read the x86_64 binaries. extracting debug info from /var/tmp/songbird-0.6.1-1-root-mockbuild/usr/lib64/songbird-0.6.1/xulrunner/xulrunner-bin Failed to write file: invalid section entry size This is not an issue in i386. I verified that the packages still work as intended, but the debug info is somehow maligned. This issue is definitely upstream, so I will be posting a bug when I have one. For more info I found the same issue in bug 187243 As for rpmlint, there are some issues, but all are upstream: $ rpmlint /usr/src/redhat/RPMS/i386/songbird-0.6.1-1.fc9.i386.rpm songbird.i386: E: script-without-shebang /usr/lib/songbird-0.6.1/xulrunner/README.txt songbird.i386: E: script-without-shebang /usr/lib/songbird-0.6.1/xulrunner/icons/mozicon16.xpm songbird.i386: E: script-without-shebang /usr/lib/songbird-0.6.1/searchplugins/google-lyrics.xml songbird.i386: W: wrong-file-end-of-line-encoding /usr/share/doc/songbird-0.6.1/README.txt songbird.i386: E: script-without-shebang /usr/lib/songbird-0.6.1/xulrunner/icons/mozicon50.xpm songbird.i386: W: hidden-file-or-dir /usr/lib/songbird-0.6.1/.autoreg songbird.i386: E: zero-length /usr/lib/songbird-0.6.1/.autoreg songbird.i386: E: script-without-shebang /usr/lib/songbird-0.6.1/xulrunner/components/nsContentPrefService.js songbird.i386: W: file-not-utf8 /usr/share/doc/songbird-0.6.1/TRADEMARK.txt songbird.i386: E: script-without-shebang /usr/lib/songbird-0.6.1/components/sbAddonMetadata.js songbird.i386: E: script-without-shebang /usr/lib/songbird-0.6.1/xulrunner/components/nsHandlerService.js songbird.i386: E: script-without-shebang /usr/lib/songbird-0.6.1/xulrunner/LICENSE songbird.i386: E: binary-or-shlib-defines-rpath /usr/lib/songbird-0.6.1/components/sbMetadataHandlerTaglib.so ['$ORIGIN/../xulrunner'] songbird.i386: W: no-soname /usr/lib/songbird-0.6.1/lib/sbGStreamer.so songbird.i386: E: binary-or-shlib-defines-rpath /usr/lib/songbird-0.6.1/xulrunner/mangle ['$ORIGIN/../lib'] songbird.i386: E: binary-or-shlib-defines-rpath /usr/lib/songbird-0.6.1/xulrunner/shlibsign ['$ORIGIN/../lib'] 1 packages and 0 specfiles checked; 12 errors, 4 warnings. The only one I was really concerned with is the RPATH error, but this seems to be completely internal in order to direct songbird to its own xulrunner libs. If it were to ask LD for information I'm guessing songbird would receive local xulrunner libs which are not patched by upstream. Feedback is appreciated.
I was able to fix the debugedit issue by removing -gstabs+ flags from the build process. Apparently, the stripper get caught up on those in x86_64, see bug 453506 The package has now been rebuilt with this fix, and some other small tweaks. Note, ppc building is not possible at the moment: http://rpm.rutgers.edu/fedora/songbird-0.6.1-2.fc9.src.rpm http://rpm.rutgers.edu/fedora/songbird.spec * Mon Jun 30 2008 David Lee Halik <auralvance> - 0.6.1-2 - Removed flag -gstabs+ from configure.ac to enable debuginfo, bug 453506 - Removed manual stripping for binaries - Removed xulrunner source arch macros
Songbird 0.6.1 now builds under ppc/ppc64 with minimal tweaking and the patch has been sent upstream. See below for the new links and changelog: http://rpm.rutgers.edu/fedora/songbird-0.6.1-3.fc9.src.rpm http://rpm.rutgers.edu/fedora/songbird.spec * Tue Jul 05 2008 David Lee Halik <auralvance> - 0.6.1-3 - Set -gstabs+ removal to only 64 bit - Enable ppc and ppc64 building - Added -mminimal-toc for ppc64 building
I wouldn't mind seeing this in Fedora One big thing: XULRunner is in Rawhide as its own package, so you should definitely attempt to build against it as shipped there, rather than stuffing it into this package.
I'd be fine with that, but upstream they heavily patch xulrunner which kills that option. The Songbird dev's would have to either use the unmodified release, or the patches would have to be applied to either the upstreamed xulrunner or in rawhide. Unless one of these changes, the modified version needs to be packaged for Songbird to build against and run.
Upstream is the preferred option. Shoot off an email to gecko-maint and see what they think.
I would agree that upstream is always nice. For reference, these are the patches. http://src.songbirdnest.com/source/xref/patches/mozilla/ According to the devs, the six digit bug numbers are upstreamed mozilla, the others are Songbird specific. It sounds like they're pushing for using the system wide installation due to issues in Ubuntu and OpenSolaris, so this might actually happen, but I'm not sure on what kind of time frame. I'll run it by gecko-maint though...
The ones that are fixes for upstream bugs are the easiest to justify. The gecko people might agree to carry most of them if they're quality. The other ones probably need to go into upstream XULRunner.
I've looked at building this in the past and found it to be in the too hard basket because it builds against its own copy of xulrunner and gstreamer. Having gone through most of the patches that they apply to the xulrunner code base quite a few of them have upstream bugs and most of the patches that apply to the linux build are fairly trivial bug fixes but the SongBird devs aren't pushing them for upstream. They all easily will apply and build against the Fedora XULrunner and don't affect firefox and other apps but Fedora would more than likely want them upstream first. The other issue is that most of the build scripts are hardcoded for the locally included copies of the source code and don't use auto* for locating include files etc so as to be able to build against the OS versions. They have said they'll happily accept patches but haven't the time or expertise to do it themselves.
A bunch of us from various XULRunner projects (representing Songbird, Komodo/ActiveState, Mozilla, Mozdev, and others) are hashing out some XULRunner issues on a xulcentral mailing list @ Mozdev. One common theme that is coming up is the importance of a shared XULRunner to distribution adoption. Would someone from Fedora/Red Hat be interested in participating in these discussions? The list page is here if you'd like to signup: https://www.mozdev.org/mailman/listinfo/xulcentral
I would suggest sending an email to the fedora-devel mailing list or to the xulrunner/firefox maintainers directly regarding this. I know the fedora maintainers work closely with the Mozilla guys regarding various bits to do with the linux version of mozilla code so I'm sure they can assist.
In keeping with the Songbird release of 0.7, I've bumped the package version and spec file. Both can be found here along with stable builds from koji: http://rpm.rutgers.edu/fedora/songbird-0.7.0-1.fc9.src.rpm http://rpm.rutgers.edu/fedora/songbird.spec
Songbird now has a tracking bug in upstream Mozilla BZ to track their xulrunner issues. https://bugzilla.mozilla.org/show_bug.cgi?id=357052
In keeping with the Songbird release of 1.0, I've bumped the package version and spec file. Both can be found here along with stable builds from koji: http://rpm.rutgers.edu/fedora/songbird-1.0.0-1.fc10.src.rpm http://rpm.rutgers.edu/fedora/songbird.spec
What is the status of being about to build it with the distro gstreamer/xulrunner?
It should build fine with a distribution GStreamer as long as it's up to date enough. It still has local XULRunner patches that haven't yet made it upstream though.
Exactly. In Fedora, the only packages that I need to build against locally are taglib and xulrunner. System gstreamer works just fine. The localized xulrunner though is a blocker until its either accepted as is or the patches are fully upstreamed. I think the larger issue is whether or not all the patches can be upstreamed without changing core mozilla functionality. Stevel would know better, but I'm guessing that all the patches that could easily be implemented have been and the rest are sensitive.
The upstream songbird tracking bug is 357052. I'm not sure how many of them are Linux dependant or even Fedora dependant bugs but the last time I tried I couldn't even build Songbird against out of tree libraries, it seems that it has improved on the gstreamer front. What's the issues with taglib. https://bugzilla.mozilla.org/show_bug.cgi?id=357052
We have patches to taglib for writing back metadata, as well as out-of-order reading of tags from remote files. Additionally, we've applied the community patches for m4a/m4p tag parsing. Scott is working on taglib 2.0 which will (hopefully) contain all these patches, but he isn't merging them into the stable taglib release tree... so until taglib 2.0 is released, we need a private taglib.
Hi! What is the status of this package ? Is this the last package version ! Just one note for now: * Why is it using zlib-static ? zlib doesn't change that much nor produce a circle dependency. So the needs of static linking doens't make sense IMO. * The source rpm is definitely enormous it would seems easier to repack the %{tarname}%{version}-860-vendor.tar.bz2 with cherry picking only what is needed to be built internally for the given Fedora version(xulrunner/taglib/other?). This can be made using a script that will have to be provided within the source package. (as source100: for example). *BTW you need to use Source0: instead of Source: But having a script to repack the source dependencies isn't that a real solution. The best way would be to have a script provided from the Songbird upstream(hi Stephen) To download a given (vanilla) version of a Songbird dependency, with only the related patch needed by Songbird (if there is). And That for each Songbird dependency. (following the VideoLan example, with vlc) This will allow for the packager (and the other packagers, that will check the Songbird Packager commits during the whole live for the package), to control which will be the difference between the system package and eventually, to override the use of an internal dependency if the Songbird patch is for another platform or already merged in the new system version... For now, I think we will need to use xulrunner internally, but what the current status of the (system) xulrunner 3.1 usability with SongBird ? (xulrunner 3.1 is already present in Rawhide/F-11). We could also ask the feodra taglib package maintainer if he will allow to backport the needed patch for F-11 (unless it breaks the taglib ABI). /me is still rpmbuilding Songbird for F-10 x86_64
(In reply to comment #20) > Hi! > > What is the status of this package ? > Is this the last package version ! David (auralvance) has spun 1.0 Fedora RPMs here: http://wiki.songbirdnest.com/Developer/Articles/Builds/Contributed_Builds > Just one note for now: > * Why is it using zlib-static ? > zlib doesn't change that much nor produce a circle dependency. So the needs of > static linking doens't make sense IMO. It can use the system zlib. > For now, I think we will need to use xulrunner internally, but what the current > status of the (system) xulrunner 3.1 usability with SongBird ? (xulrunner 3.1 > is already present in Rawhide/F-11). Still not possible... unless the XULRunner has the patches we depend on, Songbird will not likely work. :(
My mistake. I forgot to log in and update the ticket after the 1.0 release. :) Yes, the 1.0 rpm's have been out for sometime. Here's the direct link to the src.rpm and spec, all of which you can find in the url stevel pointed out. As of the latest release we use system zlib. http://rpm.rutgers.edu/fedora/songbird-1.0.0-1.fc10.src.rpm http://rpm.rutgers.edu/fedora/songbird.spec
Several things: 1) Is anyone going to make a full review for this + sponsoring the packager? 2) There is an issue with the package. When installed it places the binary executable in /usr/bin/songbird which leads to: songbird: error while loading shared libraries: libjemalloc.so: cannot open shared object file: No such file or directory Running songbird-bin from /usr/lib64/songbird-1.0.0 raises the same error. I guess that the start up script "songbird" must be used. As far as I know it's some generic mozilla script that's used for starting their apps. For example firefox uses something similar.
> 1) Is anyone going to make a full review for this + sponsoring the packager? I unfortunately don't believe due to packaging policies that songbird can be included until it can be compiled against the Fedora xulrunner rather than its own.
(In reply to comment #24) > > 1) Is anyone going to make a full review for this + sponsoring the packager? > > I unfortunately don't believe due to packaging policies that songbird can be > included until it can be compiled against the Fedora xulrunner rather than its > own. We are definitely not expecting songbird to use the "vanilla" libxul in order to be acceptable. (even thunderbird use it owns libxul, and it is very important for the songbird fedora package maintainer to look at how the thunderbird package is done. Specially about how to filter the provides of the internal libxul) BUT, using the system libxul should be doable at some later point. I will forward an email to remi who could do the final review and sponsorship (specially as he's experienced in mozilla apps packaging). Hence, I could assist him with a preliminary review. @David you seems to have done a release: 2, but the corresponding srpm isn't here. Can you implement the contribs dependencies source package to be smaller, as requested in #c20 ? I will start review then.
@kwizart Thanks for the help. I'm looking at some of the suggestions you posted as well as trimming down the tarball. I'll post revision 3 soon with the changes and updated src rpm. Once that happens having remi look it over would definitely be beneficial. Let me work on it a bit first before we move forward. @Nikolay /usr/bin/songbird is just a sym link to songbird-bin, but it appears as though I missed the scriplet that you pointed out. Songbird should ideally be run with /usr/lib/songbird-1.0.0/songbird which in turn runs songbird-bin and sets up the dependency paths properly. libjemalloc is provided by the patched internal xulrunner, but it looks as if running the binary directly causes songbird to look for the dependency on the system, not in the songbird root. If xulrunner is not installed it then breaks. Thanks for pointing this out. Songbird running against the system xulrunner is not a good idea since all the internal fixes Songbird relies upon are missing. I'll fix this in the upcoming release I mentioned.
@Nikolay I looked into the symlinking issue. There was a bug open on this upstream that has now been fixed and allows for proper symlinking to the mozilla wrapper script. http://bugzilla.songbirdnest.com/show_bug.cgi?id=13265 1.1 is due out in the next week or two and this fix will be in it. @kwizart I implemented some more fixes and spun rev 3. It's located here: http://rpm.rutgers.edu/fedora/songbird.spec http://rpm.rutgers.edu/fedora/songbird-1.0.0-3.fc10.src.rpm The mozilla startup script I just discussed sets up the proper LD paths to ensure that songbird only uses the provided internal libraries, but I see what you're getting at with the other package provides. I'm looking at the other mozilla packages to ensure that songbird is filtered and doesn't end up providing libxul.so (and others) to the general package population. I also trimmed the vendor source ball to only the required packages. The src.rpm is a much more managable size now. With the next release coming out soon I'm going to try and work with upstream (stevel) to get a reduced size tarball next time. Right now the two major bugs I see are the symlinking wrapper issue in 13265 (which will be fixed soon) and filtering the internal provides to only the necessary ones. Anything else stand out as an obvious problem?
Based off of the method used in the Thunderbird package, the internal provides are now filtered out properly. This avoids any potential conflicts between system libraries, such as libxul, and those packaged with Songbird. http://rpm.rutgers.edu/fedora/songbird.spec http://rpm.rutgers.edu/fedora/songbird-1.0.0-4.fc10.src.rpm
Well, since there is a 1.1 beta2 release two days ago, I wonder if it wouldn't be suitable to concentrate a this 1.1 pre-release while targeting Fedora-11. That would be easier to have fix merged if any. Then you should be able to backport changes to 1.0 eventually for F9/F10. Just a quick notes,(don't update the spec just for this at this time): Uses Source0: instead of Source: While using desktop-file-install, please don't use "fedora" as vendor leaving it empty ("") for now. See http://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files (that's a rather new guideline whereas it was common practice earlier). Use cp -p to prevent timestamps changes while copying various files/directory. Don't hardcode the parallel build macro: make -f songbird.mk MOZ_MAKE_FLAGS=-j4 make -f songbird.mk MOZ_MAKE_FLAGS=%{?_smp_mflags} It should allow our builder to build at the maximum speed, If the parallel build aren't safe, you should have a comment. same if the jobserver isn't supported from a given makefile. %post and %postun. Are you really sure you need to run ldconfig at %post and %postun (thunderbird doesn't do that at least). Having update-desktop-database there is good since you have mime type Can you see this http://fedoraproject.org/wiki/Packaging/ScriptletSnippets Specially, you should try to use GTK+ icon cache (with various icons size if possible) and avoid using the pixmap directory. Please use "|| :" to avoid scriplet failure if something went wrong for any reason. Do you really need "BuildRequires: zip" ? I guess this is a compression utility. You shouldn't need it to decompress anything, aren't you ? Unless it is used within the buildsystem... I haven't checked yet. At this step, it was still a preliminary review at the "looking at the spec" level.
Songbird 1.1.1 stable is now out and the srpm has been updated accordingly. I very happy with the progress of the package so far thanks to everyone's help. I think all of the issues that were raised have been addressed. I'm going to post the spec and srpm as soon as a few issues are worked out. There seems to be a xulrunner bug when building under F11 which might need a patch. There is also a hanging issue that is effecting Songbird *NIX users and we're debugging it. Initial guessing points to the latest gstreamer patches from Songbird that aren't in the system libraries yet. (In reply to comment #29) > Well, since there is a 1.1 beta2 release two days ago, I wonder if it wouldn't > be suitable to concentrate a this 1.1 pre-release while targeting Fedora-11. > That would be easier to have fix merged if any. Beginning with this release I'll targert F11 as suggested. > Just a quick notes,(don't update the spec just for this at this time): > Uses Source0: instead of Source: Done. > While using desktop-file-install, please don't use "fedora" as vendor leaving > it empty ("") for now. Done. > Use cp -p to prevent timestamps changes while copying various files/directory. Done. > > Don't hardcode the parallel build macro: Done. > > %post and %postun. Are you really sure you need to run ldconfig at %post and > %postun (thunderbird doesn't do that at least). I did some researching and you're correct. Since we're not sharing out any libraries ldconfig is not necessary. Removed. > you should try to use GTK+ icon cache (with various icons size if > possible) and avoid using the pixmap directory. Done. I followed the Thunderbird example which also seems to be correct for Songbird. One thing I wanted to note, I spoke with stevel and opened an enhancement bug for the icons. Right now they have very few png's included with the upstreamed tarball, but it's a trivial matter to add a few more. Songbird bugzilla 15652 > Please use "|| :" to avoid scriplet failure if something went wrong for any > reason. Done. > Do you really need "BuildRequires: zip" ? I guess this is a compression > utility. You shouldn't need it to decompress anything, aren't you ? > Unless it is used within the buildsystem... I haven't checked yet. Unfortunately, xulrunner's autoconfig requires zip or it dies, so I'm leaving it in for now: checking for zip... no configure: error: zip not found in $PATH
Here is the latest spec and srpm built against F11. There are a few open Linux bugs there are affecting the 1.1.1 release, but the build part of the equation has been worked out successfully. http://rpm.rutgers.edu/fedora/songbird.spec http://rpm.rutgers.edu/fedora/songbird-1.1.1-1.fc11.src.rpm
Build failed on F-10 http://koji.fedoraproject.org/koji/getfile?taskID=1244213&name=build.log But worked on F-11 (so probably that was expected). http://koji.fedoraproject.org/koji/taskinfo?taskID=1244393 This package doesn't use our CFLAGS: - some part uses -O3 - other parts uses ... -fPIC -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions Instead, the package have to obbey to the $RPM_OPT_FLAGS macro. Once that said, according to thunderbird 3: http://kojipkgs.fedoraproject.org/packages/thunderbird/3.0/1.beta2.fc11/data/logs/i586/build.log the -O2 compiler optimization doesn't seems compatible with xulrunner and thunderbird have it changed to -Os. This is the same with stable release. So we may need to do the same. Actually only ppc64 use our CFLAGS since it is tweaked from the spec for minimal toc, but it is added twice since this is now in the default RPM_OPT_FLAGS for ppc64 by F-11 See in http://koji.fedoraproject.org/koji/getfile?taskID=1244397&name=build.log - Internal taglib - I've thought works was done to have it use the system version. Why is it still internally used by F-11 ? - Weird conditionals %ifnarch i586 and %ifarch i586 better to use: %ifarch %{ix86} %define sb_arch i686 %else %define sb_arch %{_arch} %endif That will make the spec to work on F-10 and F-11. - It seems to be better to have "sed -i s/-gstabs+//g configure.ac " for all arches unless there are good reason to override -g from our RPM_OPT_FLAGS. - Icons sizes: "cp -p ../app/branding/icon64.png " etc Only the 64 pixels is available upstream. It could be nicer to use the .xpm icon pixelated to png with differents size, or to use the .xpm icon directly.
The latest RPM package (1.1.1 on i386) suffers from a hangs making it unusable because it delivers its own copy of Gstreamer: http://bugzilla.songbirdnest.com/show_bug.cgi?id=15698
(In reply to comment #33) > The latest RPM package (1.1.1 on i386) suffers from a hangs making it unusable > because it delivers its own copy of Gstreamer: > http://bugzilla.songbirdnest.com/show_bug.cgi?id=15698 Well, indeed, this isn't acceptable at all to have gstreamer internally, so how goes the work to get the patches merged in next gstreamer-libs ?
Yes, I am aware of this and another bug. Please see the following threads: http://bugzilla.songbirdnest.com/show_bug.cgi?id=15401 http://bugzilla.songbirdnest.com/show_bug.cgi?id=15432 I have been using the gstreamer system library all along, and continue to do so. Even with the latest 0.10.22 gstreamer package the freezing issue is still there. At this point we're going to have to wait on the upstreamed patches. Stevel, comments?
hi, I help maintain taglib in fedora, I can help with integration efforts here once taglib2 lands.
(In reply to comment #35) > Yes, I am aware of this and another bug. Please see the following threads: > > http://bugzilla.songbirdnest.com/show_bug.cgi?id=15401 > http://bugzilla.songbirdnest.com/show_bug.cgi?id=15432 > > I have been using the gstreamer system library all along, and continue to do > so. Even with the latest 0.10.22 gstreamer package the freezing issue is still > there. > > At this point we're going to have to wait on the upstreamed patches. > > Stevel, comments? Yeah - I'll try to find out more detail this week on what exactly our upstreamed patches are that are missing from the 0.10.22 packages, and what the ETA is on landing them.
Good news and bad news. The good news is that both the above mentioned bugs are fixed. Songbird bug 15401 is indeed fixed in 0.10.22 and Songbird bug 15432 has been patched. The bad news is that it's looking like building an internal gstreamer is going to have to happen. Each Songbird stable release has any number of gstreamer patches applied, and if we continue to build against the system libraries we will be missing anything that has been upstreamed by Songbird. In order to offer a stable product I don't see how we can run with system libraries since the system gstreamer will always be behind what has been checked in.
Why are those gstreamer patches not been upstreamed? Using system components is very important for Fedora and if songbird includes their own copy, how will it work with additional codecs installed by the user?
(In reply to comment #39) > Why are those gstreamer patches not been upstreamed? Using system components is > very important for Fedora and if songbird includes their own copy, how will it > work with additional codecs installed by the user? They have been upstreamed, they are in GStreamer 0.10.22 which, I believe, is slated for F11. It's just not in F10
You can then branch only for Fedora 11 and meanwhile work with gstreamer maintainers in Fedora to see if a updated version could be pushed in for Fedora 10. Including a local copy is (usually) not allowed
@David Please work with the gstreamer maintainer to get the patch merged in gstreamer upstream. Once done we can eventually have it backported in our current version of gstreamer for F-11 (if allowed by the maintainer ). What would you do if gstreamer is later updated with the needed fix (along with others gstreamer bugfixes). You will have to rebuild again SB to an internally QA gstreamer ? quoting from SB #15401 > I don't think the Fedora peeps are going to take this very well, but they won't > have a choice if Songbird is to be stable. Remember that the choice is our. Either to have songbird compliant with the Fedora guidelines either to have it not in repository. And it is more important to have packages that can be maintained easily (without using it own copies) than having packages to "just work". You really need to be convinced by this in order to get sponsored as a Fedora contributor, because there is no other choice. F-11 isn't frozen until then, so please work with gstreamer upstream/maintainer to have the probmem solved. Then, what is the last version of the src.rpm ?
> quoting from SB #15401 > > I don't think the Fedora peeps are going to take this very well, but they won't > > have a choice if Songbird is to be stable. > Remember that the choice is our. Either to have songbird compliant with the > Fedora guidelines either to have it not in repository. > And it is more important to have packages that can be maintained easily > (without using it own copies) than having packages to "just work". By shipping an extra copy of gstreamer it also becomes a security risk if there's a exploit that's fixed in the mainline gstreamer and is missed being updated in the songbird copy. That is why there was an effort a number of releases ago to strip out all the included copies of db4/zlib/etc. EG there was a gstreamer CVE just recently. See RHBZ 481267
(In reply to comment #42) > @David > Please work with the gstreamer maintainer to get the patch merged in gstreamer > upstream. Once done we can eventually have it backported in our current version > of gstreamer for F-11 (if allowed by the maintainer ). > What would you do if gstreamer is later updated with the needed fix (along with > others gstreamer bugfixes). You will have to rebuild again SB to an internally > QA gstreamer ? > AS I said in the above post, gstreamer 0.10.22, which is already in F11, has the necessary patches. > quoting from SB #15401 > > I don't think the Fedora peeps are going to take this very well, but they won't > > have a choice if Songbird is to be stable. > Remember that the choice is our. Either to have songbird compliant with the > Fedora guidelines either to have it not in repository. > And it is more important to have packages that can be maintained easily > (without using it own copies) than having packages to "just work". > You really need to be convinced by this in order to get sponsored as a Fedora > contributor, because there is no other choice. > You're missing the point of my statement. Yes, I totally agree that the package should be compliant with Fedora guidelines and easily maintainable, but my point was that in doing so Fedora Songbird builds will be missing developer patches to vendor packages. Each time a new version of Songbird is release a Fedora build will not be possible until all patches are verified as upstreamed to gstreamer, or risk having a non-functioning Songbird. This last release was a perfect example. Are you ok with this? If so, then so am I and we can move on. > F-11 isn't frozen until then, so please work with gstreamer upstream/maintainer > to have the probmem solved. > As I stated, the F11 Songbird doesn't have the issues. All the issues reported were from my F10 backport. SO no problem there. > Then, what is the last version of the src.rpm ? I'll update the src.rpm for F11 with all the fixes above and post it this weekend.
Okay, so we are focusing on F-11 for now, once the 1.1.1 package will be good, you will be allowed to backport the needed changes to the Songbird 1.0.0 package which may be more suitable for F-9/F-10. (there is no stric policy about reviewing a package twice, different version for different branches. So I'm only pre-reviewing 1.1.1 for F-11). Given the number of improvements and quality assurance that a songbird version needs, It would be better to only update the Rawhide version as a consequence (so, as you said, you can verify the patches to be upstreamed). As we are good for gstreamer by F-11, taglib is waiting for a future 2.0 release to get built on shared, do you have a newer src.rpm so i can look at SongBird 1.1.1 for F-11 ?
@kwizart: Ok, I think I made all the changes you requested. The RPM_OPT_FLAGS and some other xulrunner options were carried over from the new thunderbird 3 spec. I also got rid of the unnecessary minimal-toc issue and fixed a few other things. As discussed, this build currently uses the included taglib until the upcoming taglib release is available, but all gstreamer libraries are from the system. I'm focusing soley on the F11 release at this point. Backporting 1.0.0 to F10 should be trivial later. This current F11 release builds fine on all archs, however I installed F11 beta today and I was not able to get it to run. There is a buffer overflow immediately upon run in both i386 and x86_64. I'm currently submitting the bug and backtrace to the Songbird developers and will get back to you. http://rpm.rutgers.edu/fedora/songbird.spec http://rpm.rutgers.edu/fedora/songbird-1.1.1-2.fc11.src.rpm
kwizart: Forcing the RPM_OPT_FLAGS is the cause for the buffer overflow. Allowing it to build normally results in a working SB 1.1.1 on F11. Without RPM_OPT_FLAGS: gcc -o host_ifparser.o -c -DXP_UNIX -O3 With RPM_OPT_FLAGS: gcc -o host_ifparser.o -c -DXP_UNIX -Os -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables Is it mandatory that we build with the RPM_OPT_FLAGS? I'm going to try a few things and see which option is causing the overflow, but it would be much simpler if we didn't have to modify them. Recommendations?
More than likely, the stricter RPM_OPT_FLAGS are simply exposing an already-present coding problem. recommendation: fix the code, don't work-around it via different compiler flags than act only as a band-aid. May require some down-n-dirty debugging of host_ifparser.c though.
FYI, host_ifparser.c is just an example of the compile options RPM_OPT_FLAGS was adding, not the specific problem.
For tracking the buffer overflow with RPM_OPT_FLAGS: http://bugzilla.songbirdnest.com/show_bug.cgi?id=16022
The buffer overflow is patched. src.rpm and spec have been updated and tested. 1.1.1 works nicely in F11 now. http://rpm.rutgers.edu/fedora/songbird.spec http://rpm.rutgers.edu/fedora/songbird-1.1.1-3.fc11.src.rpm
I won't be able to test during the week-end, so if you have a 1.1.2 being prepared ... There is also a need to think about David sponsorship.
1.1.2 source tar balls haven't been released yet, but as soon as they are I'll post updates. As a side note, I just wanted to say thanks to Toni of SUSE who has been giving me rpm feedback in his efforts to port the src.rpm. They now have a nicely working rpm as well. kwizart, anything else in particular that needs to be done for sponsorship that I can help with?
1.1.2 source tarballs are up now: http://wiki.songbirdnest.com/Developer/Articles/Builds/Contributed_Builds
Thanks stevel. 1.1.2 src.rpm and spec: http://rpm.rutgers.edu/fedora/songbird-1.1.2-1.fc11.src.rpm http://rpm.rutgers.edu/fedora/songbird.spec As always, compiled Koji rpms are also located at the same address.
I've tried building the source rpm in mock on my machine. How long is this build supposed to take? I've aborted it after 5 hours, and ended up with a cp process I can't kill which is eating my cpu cycles: jasper 9423 90.6 0.0 12364 204 pts/2 R 10:44 272:01 cp -RLfp bin idl include lib /builddir/build/BUILD/Songbird1.1.2/dependencies/linux-x86_64/mozilla/release/frozen That "cp" has been running for at least a couple of hours, could it be in a symlink dereferencing loop?
The build should only take 20-30 minutes. Have you tried multiple builds, or was that the only one? This is the first that I have heard of such an issue despite many many builds, both locally and and on Koji.
This was the only build, on a rawhide machine and rawhide buildroot. I will try again later then, with a clean buildroot, after I get a chance to reboot my machine.
rpmlint on rpm package (not installed) built for local mock for F-11 x86_64. 2 packages and 0 specfiles checked; 377 errors, 5 warnings. There is 3 common cases for the errors: 1/ songbird.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/songbird-1.1.2/xulrunner/mangle ['/usr/lib64/songbird-1.1.2', '$ORIGIN/../lib64', '$ORIGIN/../lib'] Whereas the /usr/lib64/songbird-1.1.2 rpath was expected to use the internal xulrunner, the others are what the rpath policy expect to have removed. There is a need to track why thoses additionals rpathes are added. 2/ songbird.x86_64: E: script-without-shebang /usr/lib64/songbird-1.1.2/xulrunner/dictionaries/en-US.aff Thoses files need to be chmod -x 3/songbird-debuginfo.x86_64: E: non-readable /usr/src/debug/Songbird1.1.2/dependencies/vendor/xulrunner/mozilla/xpcom/glue/pldhash.c 0640 The source code (ending in -debuginfo sub-package) need to be publicly accessible (0644) 4/songbird.x86_64: W: no-soname /usr/lib64/songbird-1.1.2/lib/sbGStreamerMediacore.so This one is a warning only... As I understand, it is meant to be dlopened and isn't registered as a system library; also, it doesn't have a SOVERSION. So this is acceptable for me. I still need to have rpmlint on installed files and runtime testing on F-11 x86_64 @Jasper I never experienced such problem in my case, either rpmbuild, mock or koji built.
My apologies, it builds just fine. :) It's a mystery to me what caused this. Anyway, I'll be testing songbird on my F11 x86_64 workstation.
Ok, I reworked the files section and all of the rpmlint perm errors are fixed, this includes the debuginfo package. Below is the new rpmlint output: # rpmlint songbird-1.1.2-2.fc11.x86_64.rpm songbird.x86_64: W: hidden-file-or-dir /usr/lib64/songbird-1.1.2/.autoreg songbird.x86_64: E: zero-length /usr/lib64/songbird-1.1.2/.autoreg songbird.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/songbird-1.1.2/xulrunner/mangle ['/usr/lib64/songbird-1.1.2', '$ORIGIN/../lib64', '$ORIGIN/../lib'] songbird.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/songbird-1.1.2/xulrunner/shlibsign ['/usr/lib64/songbird-1.1.2', '$ORIGIN/../lib64', '$ORIGIN/../lib'] songbird.x86_64: W: no-soname /usr/lib64/songbird-1.1.2/lib/sbGStreamerMediacore.so songbird.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/songbird-1.1.2/components/sbMetadataHandlerTaglib.so ['/usr/lib64/songbird-1.1.2', '$ORIGIN/../xulrunner'] 1 packages and 0 specfiles checked; 4 errors, 2 warnings. Everything above is accounted for. The .autoreg warning and error are expected. The zero byte file needs to be there for XPCOM registration to happen on first run (I checked with the devs). kwizart, I'm not sure which other RPATH errors you were seeing, but the above three (mangle, shlibsign, sbMetadataHandlerTaglib.so) are the only ones I have seen and all are correct. These three should be pointing back to the internal lib area rather than outside. # rpmlint songbird-debuginfo-1.1.2-2.fc11.x86_64.rpm /usr/share/rpmlint/Pkg.py:16: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import popen2 1 packages and 0 specfiles checked; 0 errors, 0 warnings. debuginfo perms are now correct. I posted the update spec and src.rpm: http://rpm.rutgers.edu/fedora/songbird.spec http://rpm.rutgers.edu/fedora/songbird-1.1.2-2.fc11.src.rpm
Any recent thoughts kwizart? Haven't heard any updates from you since the rpmlint issues were fixed.
About $ORIGIN, quoting songbird run script: --------- ## On Solaris we use $ORIGIN (set in RUNPATH) instead of LD_LIBRARY_PATH ## to locate shared libraries. -------- So the ORIGIN rpath seems only used on Solaris System Sorry for the late answear... I miss time. TODO List: review the xulrunner options.
songbird once first install wants to install fonts. On my system (F-11 installed from a customized livecd) Not all fonts are installed while running the first time license file. This make songbird to request bengali and other asian fonts (via packagekit) which aren't available while watching the license. Once the installation of the fonts is refused with PackageKit, gpk-update-icon crash with this possible indication: (songbird-bin:2333): PkGtkModule-DEBUG: InstallFontconfRessources method invoked. In my opinion, there is a problem both with the license advertising and the installation of recommended plugins. That's rather annoying for a newly created users to have all sort of advertising, specially if the user known well the sunbird license and/or other well known modules. I think that previously, the same kind of problem was raised with firefox which ends to have a less "interactive with end-user" advertise. (I remember some discussion on GPL not been an EULA that end-user need to accept/reject to use the software but a pure information). The problem about recommended modules is that: in a ideal packagekit world, they should be provided in an safer way (trusted gpg signed package, such as rpm or whatever, from trusted repositories). But since our firefox package doesn't prevent installation of such extension as end-users level, i think it should be perfectly fine. So to sum-up, I would appreciate to have less interactive information on newly created user (so songbird could be usable directly). But this shouldn't prevent this package to be approved. @David Halik, Usually, in order for you to be sponsored, you need to provide a second review, this review was rather big, so this could be optional but remains at the discretion of the sponsort.
(In reply to comment #64) > In my opinion, there is a problem both with the license advertising and the > installation of recommended plugins. > > That's rather annoying for a newly created users to have all sort of > advertising, specially if the user known well the sunbird license and/or other > well known modules. I think that previously, the same kind of problem was > raised with firefox which ends to have a less "interactive with end-user" > advertise. > (I remember some discussion on GPL not been an EULA that end-user need to > accept/reject to use the software but a pure information). (full disclosure: I'm a POTI employee working on Songbird - I think I said that up above too, but worth refreshing here so it's clear) The EULA is displayed to the user here since it's possible they might be downloading some closed-source/binary-only add-ons. The EULA also notes that while the player is open source and free, the branding (Songbird icon, name, etc.) are trademarks of POTI, Inc. While this second part is similar to Firefox/Mozilla and arguably could be moved to a "hat"-like notification system like Mozilla has done with Firefox, it was still worth having the EULA agreement for the user to protect them and give them the rights to use the binary-only add-ons for free (since Songbird can and does license them to partners who build their own players on top of the Songbird source) The binary only add-ons in question are Quicktime, Windows Media, and iPod. The Quicktime & Windows Media add-ons are platform-specific to Windows & Mac - so they won't be exposed to RH/Fedora users, and the iPod add-on is soon to be open sourced... so this might be a non-issue in a matter of weeks once I'm done open sourcing the iPod add-on. So all that aside, POTI would feel more comfortable having the EULA window and agreement there... it's a requirement for us on Windows/Mac due to the proprietary binary only components, and we'd rather not get into special casing stuff just for Linux since it's entirely possible we could deliver binary-only components again in the future for Linux users. (And, as always, these add-ons will always be optional... the user is free to opt-out of not installing any of them) > So to sum-up, I would appreciate to have less interactive information on newly > created user (so songbird could be usable directly). But this shouldn't prevent > this package to be approved. cheers.. and thanks for the review! -steve
(In reply to comment #65) > stuff just for Linux since it's entirely possible we could deliver binary-only > components again in the future for Linux users. I don't want to get much involved with this review, but why not just let gstreamer deal with the codecs mess? And if you want to provide some binary-only codecs, why not to make repository of them and let PackageKit use it as (optional of course) additional source of codecs? But, that's just off-topic to the issue of EULA.
Well, I've got a few concerns here: * The License for Songbird appears to be GPLv2, which says: " 5. You are not required to accept this License, since you have not signed it. " The EULA would seem to add this additional requirement that you accept the GPL terms. "POTI IS WILLING TO LICENSE THE SONGBIRD MEDIA PLAYER AND SONGBIRD ADD-ONS TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL THE TERMS CONTAINED IN THIS AGREEMENT." * The EULA covers "Songbird Add-Ons" without specifying what those are. In addition, you mention that there are Free/Open Source add-ons coming, but this EULA clearly states that all add-ons may not be copied or modified, and imposing commercial use restrictions. All of these EULA overlay restrictions render otherwise Free/Open Source addons non-free. * The EULA requires that the end-user agree to the Fluendo EULA terms, which are most certainly non-free. These three items are showstoppers. While this isn't as bad as what Mozilla originally tried to do with Firefox, the problem is the same. I would suggest that we take a big step back from things and look at specifically what problems that you (Songbird's copyright holder(s)) seem to be trying to solve with this EULA. 1. The source code for the base songbird product is under the GPLv2. No agreement is necessary for anyone to use, copy, modify, distribute, or sell the songbird code. 2. The base songbird product does not come with any addons. Thus, there should not be a need to specify terms for these addons. If a user installs an addon through songbird directly, they should be prompted to agree to downloaded terms before downloading the addon, not at the initial use of songbird. (If addons are manually installed by the user outside of songbird, it is the responsibility of the addon provider to ensure that the terms of that specific addon are either presented to the user before download or before installation). 3. "Proprietary Rights": The GPL is effective in providing this coverage, nothing in the GPL takes away the rights that are preserved by copyright law. There is no need for the user to agree to this explicitly. 4. "Disclaimer of Warranty": The GPL is effective in providing this coverage, it has a thorough disclaimer of warranty. There is no need for the user to agree to this explicitly. 5. "Third-Party Add-Ons": This covers the fact that third-party addons available at the songbird website may have different terms and disclaims warranty. If deemed absolutely necessary, this is something that could be presented in a non-obtrusive way, similar to how firefox handles its third party services, where the user is made aware of these facts, but is not required to agree to them. Realistically, this should be on the songbird website, not embedded in the client. 6. "Term and Termination": This legal boilerplate in the EULA arguably conflicts with the GPL, thus, according to the beginning of the EULA ("To the extent that any of the terms and conditions of this Agreement conflict with the GPLv2 and POTI's exception, the conflicting terms and conditions of this Agreement shall not apply to the Songbird Media Player."), they don't apply anyway, and serve no purpose. 7. "Representations and Warranties." This states that songbird users must comply with the law when using addons (but not the base songbird player?), and that they cannot use the code to infringe other's copyrights. This technically constitutes a use restriction, and conflicts with the GPLv2. In addition, you do not need to force people to agree to follow applicable laws, they're required to do that anyways, no prior agreement necessary. Thus, this entire section is not required. 8. "No Obligation": Already covered adequately in GPLv2, not necessary. 9. "Government Users." These appear to impose additional rights restrictions upon US goverment use, which may conflict with the GPLv2 and thus be irrelevant. If there are additional US government policies covering the use of specific types of software (I'm assuming this is primarily for cryptographic related matters), you could certainly inform the goverment user in an unobtrusive way that these policies may apply, but this is not something that mandates acceptance. (Alternately, the Mozilla Public License 1.1 (Section 10) has this as part of its license, thus, it may be a better fit for Songbird: http://www.mozilla.org/MPL/MPL-1.1.html ) 10. "Export Laws." Requiring people to follow US export laws in order to use GPLv2 licensed software might be a restriction on the GPL as worded in the EULA. However, the GPLv2 provides a mechanism to handle this: " 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License." I would suggest that along with your gstreamer exception, you can accomplish this by adding a export limitation excluding any countries where songbird could not be distributed in accordance with US export laws. Fedora has similar US export requirements, but we only impose them on our distributors (e.g. mirrors), not via EULA to our users. 11. "Indemnity" and "Limitations of Liability": Covered adequately by the GPLv2, no need for additional user agreement. 12. "General Provisions": More legal boilerplate. GPLv2 conflicts with forced jurisdictional clauses, such as "This Agreement will be governed by and construed in accordance with the laws of the State of California", so it doesn't apply. (It is worth noting that the Mozilla Public License v1.1 contains virtually identical boilerplate, so, if you cannot move forward without it, switching to that license may be a better fit for you.) 13. "Third-party software": It is good to have this listed, but the user does not need to agree to it, nor be required to review it in order to leverage the rights granted by copyright and the GPLv2 (use, copy, distribute, modify). To put it bluntly, the EULA is entirely unnecessary, and in my opinion, the impact of requiring the user to agree to the EULA's additional terms and restrictions in order to use the songbird base client (and removing all rights granted by the GPLv2 if it is not agreed to) renders this non-free. Please realize that I'm not trying to be a roadblock here because I enjoy it, or because I have anything personally against Songbird. It looks rather cool, so I would encourage you to make the attempt to move away from the failed Windows EULA legal model and have faith in the GPL (which, unlike boilerplate EULAs, has never failed to be upheld in international courts). If you have further questions or improvement suggestions, I would be happy to discuss them, either publicly or privately. Blocking FE-Legal
(In reply to comment #66) > (In reply to comment #65) > > stuff just for Linux since it's entirely possible we could deliver binary-only > > components again in the future for Linux users. > > I don't want to get much involved with this review, but why not just let > gstreamer deal with the codecs mess? And if you want to provide some > binary-only codecs, why not to make repository of them and let PackageKit use > it as (optional of course) additional source of codecs? > > But, that's just off-topic to the issue of EULA. Sorry for the confusion, but I was talking about proprietary/binary-only add-ons (in the sense of Songbird add-ons which are like Firefox add-ons... packaged in .xpis, that augment the app by giving it new skins, or new functionality). The codecs themselves are all managed by GStreamer as you'd expect.
(In reply to comment #67) ... Hey Tom, Thanks very much for the detailed reply and points... I'm bringing them up with our lawyers and execs to see what we can and can't address. I expect this will take a while (as anything involving management and/or legal seems to do), but just wanted to let you know I'm looking into it and not ignoring it. cheers, steve
Tried to rebuild http://rpm.rutgers.edu/fedora/songbird-1.1.2-2.fc11.src.rpm on Fedora 11 and this is what I get. IMHO, it HAS to go before the review ends: + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot ******************************************************************************* * * WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild' * to fail. To ignore these errors, you can set the '$QA_RPATHS' * environment variable which is a bitmask allowing the values * below. The current value of QA_RPATHS is 0x0000. * * 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor * issue but are introducing redundant searchpaths without * providing a benefit. They can also cause errors in multilib * environments. * 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute * nor relative filenames and can therefore be a SECURITY risk * 0x0004 ... insecure RPATHs; these are relative RPATHs which are a * SECURITY risk * 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other * RPATHs; this is just a minor issue but usually unwanted * 0x0010 ... the RPATH is empty; there is no reason for such RPATHs * and they cause unneeded work while loading libraries * 0x0020 ... an RPATH references '..' of an absolute path; this will break * the functionality when the path before '..' is a symlink * * * Examples: * - to ignore standard and empty RPATHs, execute 'rpmbuild' like * $ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild my-package.src.rpm * - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like * $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths * ******************************************************************************* ERROR 0008: file '/usr/lib64/songbird-1.1.2/components/sbMetadataHandlerTaglib.so' contains the $ORIGIN rpath specifier at the wrong position in [/usr/lib64/songbird-1.1.2:$ORIGIN/../xulrunner] ERROR 0008: file '/usr/lib64/songbird-1.1.2/xulrunner/mangle' contains the $ORIGIN rpath specifier at the wrong position in [/usr/lib64/songbird-1.1.2:$ORIGIN/../lib64:$ORIGIN/../lib] ERROR 0008: file '/usr/lib64/songbird-1.1.2/xulrunner/mangle' contains the $ORIGIN rpath specifier at the wrong position in [/usr/lib64/songbird-1.1.2:$ORIGIN/../lib64:$ORIGIN/../lib] ERROR 0008: file '/usr/lib64/songbird-1.1.2/xulrunner/shlibsign' contains the $ORIGIN rpath specifier at the wrong position in [/usr/lib64/songbird-1.1.2:$ORIGIN/../lib64:$ORIGIN/../lib] ERROR 0008: file '/usr/lib64/songbird-1.1.2/xulrunner/shlibsign' contains the $ORIGIN rpath specifier at the wrong position in [/usr/lib64/songbird-1.1.2:$ORIGIN/../lib64:$ORIGIN/../lib] chyba: Špatný návratový kód z /var/tmp/rpm-tmp.b5Kpm5 (%install)
(In reply to comment #70) > Tried to rebuild http://rpm.rutgers.edu/fedora/songbird-1.1.2-2.fc11.src.rpm on > Fedora 11 and this is what I get. IMHO, it HAS to go before the review ends: I've made a similar comment as https://bugzilla.redhat.com/show_bug.cgi?id=453422#c59 and #c63 Whereas using rpath is appropriate for the current package (as an application that bundle it own xulrunner - thunderbird does the same for exemple), the $ORIGIN rpath seems only needed for Solaris. Hence, there is a need to clean the $ORIGIN rpath.
1.2 is due out shortly. I'll remove the $ORIGIN rpath in the next build and repost.
Can anyone give me some pointers on how to scrub the extra $ORIGIN that keeps getting added on? I spent a bunch of time this weekend trying to remove it from the rpath, but it is continually tacked on at some point. Alfred who runs the Solaris rpm for Songbird essentially disables the rpath, then sets his own afterwards in order to clean anything being added automatically: LDFLAGS="-norunpath -z ignore -R'\$\$ORIGIN:\$\$ORIGIN/..'" Is there a way to accomplish this with gcc? -norunpath and -z ignore are Solaris-isms I believe. Any help would be appreciated.
http://fedoraproject.org/wiki/Extras/Schedule/RpathCheckBuildsys
Thanks for the link, but most of what is in there I was already aware of. It looks like some makefile and cmake hacking will be needed to remove the extra ORIGIN path. I've tried multiple different tricks and I haven't been able to remove it. Unless someone else has a better idea of how to clean the path, I'm leaving this as is for now. Update 1.2.0 links: http://rpm.rutgers.edu/fedora/songbird-1.2.0-1.fc11.src.rpm http://rpm.rutgers.edu/fedora/songbird.spec
(In reply to comment #73) > Can anyone give me some pointers on how to scrub the extra $ORIGIN that keeps > getting added on? grep \$ORIGIN * -R This will help to find potential place where $ORIGIN rpath will be set. > Alfred who runs the Solaris rpm for Songbird essentially disables the rpath, > then sets his own afterwards in order to clean anything being added > automatically: > > LDFLAGS="-norunpath -z ignore -R'\$\$ORIGIN:\$\$ORIGIN/..'" Overriding environnement value do not always work and may provide undesired effects. You need to patch the Makefile.am or configure.in to have the rpath usage conditionalized as needed. Building in mock for F-11... http://koji.fedoraproject.org/koji/taskinfo?taskID=1458403
FWIW, while the package Nicolas built installs fine, it segfaults immediately after you start playing just about any song (this is on x86_64 F11). I experienced the very same behaviour with upstream 1.2.0, so I don't suspect any packaging issue.
I've been testing the last couple of release on x86_64 F11 and have not seen this problem. If you're also having the segfault from the upstream binaries, it sounds like an issue with the gstreamer installation. If the plugin compliment isn't correct the program does get cranky, although it shouldn't crash, so I suggest opening a bug upstream.
One thing I would like to recommend, in the interest of keeping Fedora F/OSS, while providing functionality to those who want it. Could we package songbird without the proprietary plugins, but package those in a separate package and submit that to RPMFusion-nonfree? For what it's worth, I've been using Sonbgbird through several songbird releases on Fedora and I have very little to complain about. Generally works and works well here.
(In reply to comment #79) > One thing I would like to recommend, in the interest of keeping Fedora F/OSS, > while providing functionality to those who want it. Could we package songbird > without the proprietary plugins, but package those in a separate package and > submit that to RPMFusion-nonfree? Read comment 68, codecs themselves (proprietary or free) should not be part of this package. It just uses GStreamer as rhythmbox or totem do. Just apparently upstream wanted to deliver some codecs later and wanted to have approved agreement for its users (read comment 67 for longer tract on the legalese).
(In reply to comment #76) > Building in mock for F-11... > http://koji.fedoraproject.org/koji/taskinfo?taskID=1458403 Unfortuantely, it seems that RPMs got already garbage collected.
Any NEWS from the SongBird Legals (and improvement on the rpath issue for the packaging side)?
The only place ORIGIN is used is within the xulrunner package itself and only when SunOS is detected. As I stated before, I'm not sure how to fix this if it's not supposed to be used in the first place. I've tried many methods, but none have helped. I can remove the appropriate sections, but considering it's for solaris, I doubt it will make a difference. Someone with more expertise than me would probably be better at fixing the ORIGIN issue.
With the RPM you've provided for 1.2.0-1, any playback causes a segfault: (songbird-bin:20179): GStreamer-WARNING **: Failed to load plugin '/home/scott/.gstreamer-0.10/plugins/libgstflump3dec.so': /home/scott/.gstreamer-0.10/plugins/libgstflump3dec.so: wrong ELF class: ELFCLASS32 /usr/lib64/songbird-1.2.0/songbird: line 134: 20175 Segmentation fault "$prog" ${1+"$@"} The seg fault does not just happen with mp3 format.
That looks like an issue with whatever gst plugins you're using. It's basically saying that you're running a 64bit songbird against a 32bit libgstflump3dec.so. Make sure that all your gstreamer packages are 64bit and the latest release if you're on a x86_64 install and try it again.
I regressed to 1.1.2 with the same plugin set and it's working. Looks related to the upstream bug: http://www.getsatisfaction.com/songbird/topics/songbird_segfault_on_fedora_10 I am running fedora 11 x86_64.
Any progress on songbird? I tried building the latest src.rpm on fc11 but it doesn't go through (can post if not common knowledge). I'm really looking forward to this package in fedora.
Hi guys, since the last build of F11 wasn't working on my F12 (i686) I've rebuilt the source rpm: http://people.fedoraproject.org/~knol/rpms/songbird/songbird-1.2.0-1.fc12.i686.rpm
1.4 release?
The source ball hasn't been released yet. When it is I'll start working on it, but it's going to take time some I'm sure since it's been so long since the last stable release.
Looks like 1.4 source is available: http://publicsvn.songbirdnest.com/client/branches/Songbird1.4/
For what it's worth, songbird 1.4 appears to work in f12 by extracting the tarball'd binary and running it, if that's any hope for your packaging of it.
Reply to comment 92: I've downloaded the binary tarball Songbird_1.4.2-1434_linux-i686.tar.gz yesterday, but it's not working for me on F12: (songbird-bin:21336): GLib-WARNING **: g_set_prgname() called multiple times (songbird-bin:21343): GStreamer-WARNING **: Failed to load plugin '/home/petzold/download/Songbird/gst-plugins/libgstpulse.so': /usr/lib/libsndfile.so.1: undefined symbol: vorbis_version_string (songbird-bin:21343): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstjpeg.so': /usr/lib/gstreamer-0.10/libgstjpeg.so: undefined symbol: _gst_debug_get_category (songbird-bin:21343): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstvideo4linux2.so': /usr/lib/gstreamer-0.10/libgstvideo4linux2.so: undefined symbol: _gst_debug_get_category (songbird-bin:21343): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstapp.so': /usr/lib/libgstapp-0.10.so.0: undefined symbol: gst_buffer_list_get_type (songbird-bin:21343): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstdeinterlace.so': /usr/lib/gstreamer-0.10/libgstdeinterlace.so: undefined symbol: gst_video_format_parse_caps_interlaced (songbird-bin:21343): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstmatroska.so': /usr/lib/gstreamer-0.10/libgstmatroska.so: undefined symbol: gst_util_array_binary_search (songbird-bin:21343): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstpulse.so': /usr/lib/gstreamer-0.10/libgstpulse.so: undefined symbol: gst_message_new_request_state (songbird-bin:21343): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstdv.so': /usr/lib/gstreamer-0.10/libgstdv.so: undefined symbol: gst_tag_list_new_full ././songbird-bin: symbol lookup error: /usr/lib/python2.6/site-packages/gst-0.10/gst/_gst.so: undefined symbol: gst_task_pool_get_type Could not initialize GStreamer: Error re-scanning registry , child terminated by signal Googling these error messages, I've found the advise to set LD_BIND_NOW=1 when running songbird. This seems to help a bit, but songbird is still crashing randomly. Scott, what did you do to make it work for you? :-)
1.4.3 is on it's way to being released, so I'm going to wait for that. @Scott the svn checkout isn't the same as their officially released source ball (different paths, structure, etc), so I wait for that. Otherwise I have to change the build process to cope and it's a bunch of extra work for nothing. Songbird dev stevel will notify me when the ball is out, so I'll get on it soon after. @Andreas You should probably post your issues on the songbird help list, because what I do here with the respin is very different than what they provide. I use almost all system components from Fedora, except for xulrunner and tagib, they package everything to their own patched copies. It's very likely that gstreamer bugs will not be the same because of the different versions involved.
David, I'm aware of your great effort over the last 1.5 years. Keep on and good luck! I was just wondering why the upstream binary tarball seems to work for some and not for others on f12. Anyway, I'll wait for your rpm to make things work.
my best guess as to why it would work for one and not the other from tarball is a dependency issue. Thus an RPM will be nice to have.
all gstreamer libs under lib/ are fault, you need delete all of them to make songbird 1.4.3 to start up, not sure what functions you lost, most likely it will find system gstreamer libs.
(In reply to comment #94) > 1.4.3 is on it's way to being released, so I'm going to wait for that. Given that it's been a few weeks, I was wondering if there was any update to 1.4.3? Or any activity to the request itself.
Sorry for the delay everyone. 1.4.3 came out just before the holidays and I was not able to find much time to work on it until recently. There was also a large jump between 1.2 an 1.4, so there were a ton of build changes that had to be made. I should have the final product up this week. I just finished building and installing an almost finished version and it is working nicely, there are only a few little things to fix. One thing that I was very happy about is finally being able to get rid of $ORIGIN, rpmlint is looking great. I'll post the final 1.4.3-1 update soon.
That is good.... and thank you.
I'm happy to say as promised, 1.4.3-1 has been finished. A couple of notes before you download and install: 1) i686 and x86_64 were fully tested on clean F12 installs and worked without any issues, so I am satisfied. However, I spent hours trying to debug an "audiosink" issue on my x86_64 install and it turned out to be a leftover config from when I was running F11 and my X-Fi sound card, which was not supported properly and not using autoaudiosink. The point is, songbird is very sensitive to which audio engine you are using. If you have playback issues on a system that has been upgraded F10->F11->F12, etc, most likely that is your problem and you're not running the same way as a fresh F12 install Example: Something along these lines... https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/442157 2) I do not have a PPC/PPC64 system any more, so the builds are untested. They completed successfully, but I can't verify functionality. 3) I recommend using the absolute latest gstreamer and gstreamer-plugins available in the repo, Songbird constantly upstreams patches. Old gstreamer versions can lead to playback issues. As always, mp3 support is through the full suite of gstreamer-plugins not available or licensed from Fedora. 4) To take the load off the devs, when reporting bugs back to Songbird please try their binary blob to verify the bug on your system first if you're not sure whether it's a problem with this package or a core player problem. I've seen lots of people reporting "my F11 rpm doesn't work in F12". That's not their problem if their website's release does in fact work, that's my problem. Just a heads up to keep this in mind. OK, had to get that out of the way! Here is the current src.rpm, and songbird.spec: http://rpm.rutgers.edu/fedora/songbird-1.4.3-1.fc12.src.rpm http://rpm.rutgers.edu/fedora/songbird.spec and compiled working koji builds: http://rpm.rutgers.edu/fedora/songbird-1.4.3-1.fc12.i686.rpm http://rpm.rutgers.edu/fedora/songbird-1.4.3-1.fc12.x86_64.rpm http://rpm.rutgers.edu/fedora/songbird-1.4.3-1.fc12.ppc.rpm http://rpm.rutgers.edu/fedora/songbird-1.4.3-1.fc12.ppc64.rpm For the Fedora devs, $ORIGIN has been removed and rpmlint currently looks like this: $ rpmlint songbird-1.4.3-1.fc12.i686.rpm songbird.i686: W: no-soname /usr/lib/songbird-1.4.3/lib/sbGStreamerMediacore.so songbird.i686: W: hidden-file-or-dir /usr/lib/songbird-1.4.3/.autoreg songbird.i686: E: zero-length /usr/lib/songbird-1.4.3/.autoreg 1 packages and 0 specfiles checked; 1 errors, 2 warnings. As explained in comment #61, the zero byte file needs to be there for XPCOM registration to happen on firstrun, so I see no issue with the above.
The new binary for 1.4.3-1 fails to start on x86_64 f12. I have rm -rf'd my .songbird2 and .gstreamer folders in $HOME just to make sure it wasn't caused by settings or plugins. Here's the output: (songbird-bin:15878): GLib-WARNING **: g_set_prgname() called multiple times Warning: Unable to create "trees" RDF storage. Performance can be improved by upgrading librdf. (plugin-scanner:15882): GLib-GObject-WARNING **: cannot register existing type `GstBaseVideoCodec' (plugin-scanner:15882): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (plugin-scanner:15882): GLib-GObject-CRITICAL **: g_type_register_static: assertion `parent_type > 0' failed (plugin-scanner:15882): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (plugin-scanner:15882): GLib-GObject-CRITICAL **: g_type_register_static: assertion `parent_type > 0' failed (plugin-scanner:15882): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (plugin-scanner:15882): GStreamer-CRITICAL **: gst_element_register: assertion `g_type_is_a (type, GST_TYPE_ELEMENT)' failed Songbird doesn't die at this point, but remains running in the background. GUI is never shown, and songbird needs to be killed by process.
I'm sitting in front of a freshly installed x86_64 F12 and I'm not seeing the same problem, so you must have something on there it doesn't like. I think I know what your problem is though since I ran into something similar last week and though it was a bad build. Do you have gstreamer-plugins-schroedinger installed? Try removing it, rm -rf .songbird2 and start again. songbird is dying on one of your video gstreamer plugins
I did some more research and it's definitely your particular setup. Make sure every gstreamer rpm is the latest version available from fedora. People have run into this exact problem with rythmbox, totem, pidin, etc etc. You are more likely to be susceptible to it if you're upgraded from an older Fedora release. There is definitely a gstreamer package causing issues with your runtime which doesn't plauge clean F12 installs. See here: http://forums.fedoraforum.org/archive/index.php/t-235764.html http://www.mail-archive.com/fedora-list@redhat.com/msg61371.html http://fedoraforum.org/forum/showthread.php?t=237718
Looks like you were right that it is a gstreamer problem. I get the same output in terminal when running gst-launch-0.10. Also, removing gstreamer-schroedinger and removing the .songbird2 caused songbird to launch, with a few gdk warnings output in terminal. May I suggest, for now, having gstreamer-schroedinger in Conflicts in the spec?
(In reply to comment #105) > May I suggest, for now, having gstreamer-schroedinger in Conflicts in the spec? Please no, spec file should be something much more permanent than time somebody will need to fix one bug in gstreamer-schroedinger.
I spoke too soon. It crashes consistently about 2 seconds into playing any song. Attaching debug trace.
Created attachment 387252 [details] Songbird trace, seg fault when playing
I meant to say, please, file a bug against gstreamer-schroedinger about it. Thank you
Ah, that trace is *after* gstreamer-schroedinger is removed, Songbird is now up and running. Playing any music causes this error, *without* gstreamer-schroedinger installed.
have you tried to rebuild shroedinger ? (that provides a gstreamer-schroedinger subpacakge).
What bothers me is that this only happens on certain systems that have been used for awhile, which means there have been updates that affected the machine differently from a fresh install, or there are additional libraries that are installed by default. This would explain why I can't reproduce this on either of my i686 or x86_64 fresh installs, but did see it once on a crufty old upgraded machine. I currently have an x86_64 with schroedinger and all the other gstreamer libs, yet no crash. Adding a Conflicts won't help, we have to find the underlying problem. I would also open this bug with Songbird, might as well. By the way, two more things you can try. Start with: LD_BIND_NOW=1 ./songbird I don't think that will fix anything since you're using system gstreamer, but it was a F12 issue they experienced when 1.4.3 came out. Also, I doubt this is the problem, but some people had a major problem starting songbird with flash linking in from outside their songbird home: http://getsatisfaction.com/songbird/topics/songbird_wouldnt_start_on_ubuntu_jaunty Since flash is something you won't on a fresh system, it can't hurt to try. I would temporarily move your .mozilla and see what happens on a fresh firstrun. I definitely saw your flash plugin getting detected in the trace. Also, you can try doing a first run without installing any of the addons, just to make sure it's none of them.
I removed shroedinger and .songbird2 and continue to have songbird die. This also happened in Songbird 1.2 (or whatever the last contributed build was for Fedora 11), but I thought that this was simply because I was running Fedora 12. I installed Fedora twelve on a new partition, but that was over a month ago. My installation is most definitively not "fresh". This crash after about 7 seconds of playing continues to occur. What information can I give to help to solve this problem?
I got this problem when I tried to play something the first time. LoadPlugin: failed to initialize shared library /home/gat/.mozilla/plugins/nppdf.so [/home/gat/.mozilla/plugins/nppdf.so: wrong ELF class: ELFCLASS32] /usr/lib64/songbird-1.4.3/songbird: line 134: 31663 Segmentation fault (core dumped) "$prog" ${1+"$@"} So I simply moved it so that it wouldn't be detected. (The flashplayer plug-in next to it should be the linux alpha 64bits version, if that matters) Then I received this error report. /usr/lib64/songbird-1.4.3/songbird: line 134: 31765 Segmentation fault (core dumped) "$prog" ${1+"$@"} --The line number remains constant, but the segmentations fault number changes. This error was just discouraging. What do I do about that?
Can you get a backtrace of the core dump and post a link to it? Honestly, there's nothing I can really do about all the crashes and core dumps unless it's something specific to the packaging that's causing it. 1.4.3 has been giving people problems even from the developers site downloads. Most likely it's because of the gstreamer setup on your install, as always. I'm really starting to wonder if we're going to even be able to run this with system gstreamer libraries... it's a shame. Post a backtrace and I'll look it over. Unfortunately, the developers won't really look at a bug report unless we're using their gstreamer libraries, and we're not.
Is there anybody who would take on this review and completed it? AFAIK (and I haven't checked) the package should be OK as far as packaging goes, and we can deal with crashes in separate bugs. Any volunteers?
(In reply to comment #116) > Is there anybody who would take on this review and completed it? AFAIK (and I > haven't checked) the package should be OK as far as packaging goes, and we can > deal with crashes in separate bugs. Any volunteers? We are still bloking FE-Legal !
My backtrace... http://www.filedropper.com/backtracesongbird Is there a way that I could create a local folder in /home/user to store the gstreamer that songbird "wants"? This application would actually be worth doing this, though it is against the whole Linux structure.
Unfortunately, what you're asking is much more complicated than you might realize. Traditionally Songbird comes with it's own hacked and patched gstreamer and plugins. So you can't just point it at the proper place, gstreamer/songbird both have to be recompiled properly. We've been able to get away with using the system supplied gstreamer in the past, but this latest release is just can't handle it on many systems. It does in fact work great on fully vanilla i686/x86_64 installs that are fully patched, but most people's systems are not that. I had my own issues using an install that I had upgrade F10->F11->F12, the gconf files were all wrong and songbird was pissed. It's not just this package though, go try and run the Songburd supplied binary off their website on F12. I believe it crashes on stock systems without the write variables. *sigh*
I have tried the Mozilla build folder and it failed. I really hate how Mozilla based projects are packaged that way. I also have tried nightly releases, and they have failed as well. With the non-rpm builds I cannot even get a window to be displayed. Usually I get a segmentation fault as libgstlv2.so. If I had installed this when my system was fresh, would Songbird still be preserved after I had altered the system to "end-user usability"/"normal operating conditions"? Is this really only a problem on Fedora 12, I cannot believe that Fedora did something special to create a super special circumstance. No other distributions have this problem?
This is a problem on any distribution because of the way they customize xulrunner, gstreamer, taglib, etc etc etc. You'll find the same problems on Ubuntu threads. Have you seen this and did it for the Songbird released binaries? http://getsatisfaction.com/songbird/topics/songbird_fails_to_start_on_fedora_11_with_undefined_symbol_in_libgstdeinterlace_so Another issues I've been reading about is Songbird under SELinux. Try switching it to permissive mode.
(In reply to comment #121) > Another issues I've been reading about is Songbird under SELinux. Try switching > it to permissive mode. This actually shouldn't be an issue... I have here songbird with SELinux in the Enforcing mode, and it works well. And certainly what SELinux does shouldn't lead to the crash anywhere.
Just a followup. Songbird is working with this setup: -Updated default i686 install from Installation media. -Enabled RPMFusion free/non-free -groupinstall'd "Sound and Video" to bring in 3rd party codecs -installed songbird If I get a chance today I'll try to compare this against my x86_64 setup where songbird is crashing.
When Fedora 13 comes out (the final version out of Beta and past the release candidates) if I install Songbird immediately do you believe that Songbird will work, or not? I tried to install Songbird 1.4 about a month after I had Fedora 12 installed, and a boat load of installations after installing the operating system I install Songbird, but for whatever reason it won't work correctly on non-fresh installations of Fedora. Songbird is the last component that I need to make Fedora my new GNU/Linux operating system and my laptop media center.
Found the gstreamer problem! Removing gstreamer-plugins-ugly fixed it here. Not sure if it matters, but I also have no 32-bit gstreamer plugins installed. Otherwise, I haven't found any other problems with the recent build.
Does http://blog.songbirdnest.com/2010/04/02/songbird-singing-a-new-tune/ mean CLOSED/WONTFIX for this bug and for whole Songbird package?
(In reply to comment #126) > Does http://blog.songbirdnest.com/2010/04/02/songbird-singing-a-new-tune/ mean > CLOSED/WONTFIX for this bug and for whole Songbird package? One would hope that before they abandon the codebase entirely, they would at least get rid of that terrible EULA, so someone else could pickup the code and actually keep it alive.
Well, at least they want to continue the nightly builds. I don't know whether this is a solution though.
At this point it is useless to go on with this thread, IMO. The EULA isn't changing, which is a no-go alone, and now that they're dropping official Linux support, updates and bug fixes are going to be few and far between (if at all). I'm not going to spend my time reverse engineering their builds every release only to find out the software has issues on Linux... which we've seen it already does. Sorry to say it, but they've had a good run and there's no need to beat a dead horse. Almost two years on this bug thread, not bad! :) There's talk that some of the developers might fork and continue to release a parallel player called "Lyrebird" or "Freebird" that keeps closer to the base Linux player tradition. If that happens I'll open a second bug ticket and start there as a new project based off of this one. Can someone with privs please close this ticket? I see no need to continue it. Thanks to everyone who helped along the way.
Done. Thank you for the hard work.
David... Thank you.
Hello, I wanted to let everyone here know that Nightingale(formerly Lyrebird, formerly Songbird for Linux) is in early planning stages and that Linux is our primary focus. That said, as we fill the todo list for the project, we need to know what is wrong with Songbird/Nightingale that prevents it's entry into Fedora repositories. I would like an organized, definitive list that I can easily pass on to the others if at all possible. Contact: kamisamanou kamisamanou on #nightingale at irc.mozilla.org
My understanding that it was primarily blocked on use of a EULA and use of bundled libraries with patches instead of using system libraries. For Fedora to accept it, it needs to be stable and work with features like SELinux properly.
(In reply to comment #133) > My understanding that it was primarily blocked on use of a EULA and use of > bundled libraries with patches instead of using system libraries. For Fedora > to accept it, it needs to be stable and work with features like SELinux > properly. For package (we don't care that much about program per se in the Packaging Review, more about how it is packaged) the definitive list is https://fedoraproject.org/wiki/Packaging/ReviewGuidelines which includes by reference https://fedoraproject.org/wiki/Packaging/Guidelines. What Rahul was mentioning were two biggest issues with this package (EULA and bundled libraries). Of course, Fedora expects people willing to fix bugs and non-conformance with its platform, but for example SELinux issues are not something which would break package review IMHO. Even package with SELinux problems should come in, and all issues should be filed as bugs and fixed in normal course.
@kamisamanou So what you're looking for is: 1) The EULA has to be removed. My understanding is that all Fedora packages should be covered under the same licensing and Nightingale having a separate EULA that the user must accept is not allowed. 2) Currently Songbird requires its own custom bundled xulrunner and taglib (with heavy reliance on gstreamer as well). All of these dependencies should be shifted to the system libs. I realize that there are a large amount of custom patches that don't exist upstream, but if Nightingale is to be seriously considered and work properly you should work towards a more system friendly release and less of a monolithic package. As we've seen with the last release, if the system version of gstreamer was even slightly different all hell broke loose because it was designed to be used with an internal version. Songbird has always been built as it's own universe, which might work well on Windows, but not here in an packaged environment. By the way, I'd be willing to keep this process going with Nightingale since I already have been involved in packaging Songbird for two years, but I'd like to see some commitment to these changes first before jumping back into it. Without them there's no reason to proceed.
David Halik, Pedantic correction: Same licensing is not required. Any acceptable free and open source license is ok for Fedora. Detailed list is at http://fedoraproject.org/wiki/Licensing:Main A major problem with EULA is that it breaks RPM's requirement of a non interactive installation and is in shaky grounds in a muti-user environment since a license agreement if at all one is required should be prompted post-installation on a per user basis.
Songbird is forked for Linux http://getnightingale.org/
(In reply to comment #137) > Songbird is forked for Linux > > http://getnightingale.org/ yes, we have been talking about it since comment 132, but it is relevant for this bug. Please, do not reopen this, but when Nightingale actually happens and is packaged for Fedora open new bug. Packaging issues of Nightingale should have not much common with ones for Songbird.
If I may impose that this be brought back from the dead, some things have chaged since this was closed: *Nightingale is no longer a linux port but merely an add-on community. *Songbird has killed linux support from their download page, yet there continue to be releases for Linux at http://wiki.songbirdnest.com/Developer/Articles/Builds/Contributed_Builds#Linux . According to this page "The Songbird project currently has limited resources, so we can only provide Windows and Mac OS X builds. Fortunately, our developer community rocks and has stepped up", so the project is still alive for Linux in some form (which is why FOSS is cool). *Simply unpacking the generic binary tarball for x86_64 seems to work almost flawlessly here on my Fedora 13 machine for version 1.7.3 so far. If the requesting maintainer is still interested in packaging this, then I recommend re-opening this review.
The obnoxious EULA for songbird must be removed from this version. I'm pretty sure this is still blocked on legal.
Bundling its own runtime libs instead of system ones isn't a problem, since other packages do it. And btw, songbird uses a heavily patched xulrunner.
(In reply to comment #141) > Bundling its own runtime libs instead of system ones isn't a problem, since > other packages do it. That logic is questionable at best.
(In reply to comment #142) > (In reply to comment #141) > > Bundling its own runtime libs instead of system ones isn't a problem, since > > other packages do it. > > That logic is questionable at best. You missed the last sentence which explains why. Of course, we can build songbird against the system's xulrunner (with some patches), but we will get some ridiculous bugs to resolve then.
If you have patches, have you talked to XULRunner upstream to try and get it merged? Every project bundling its own patched library is a disaster from the distro point of view and the reasons are outlined at https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
(In reply to comment #144) > If you have patches, have you talked to XULRunner upstream to try and get it > merged? Every project bundling its own patched library is a disaster from the > distro point of view and the reasons are outlined at > > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Mozilla refused a lot of patches from SongBird devs, though some have been merged. Using a vanilla xulrunner for songbird will create problems for the packager ( linux support is very limited upstream if not dead completeley ), since upstream will request reproducing the bug with their binaries, which can't be for sure for the mentioned reason.
Then dev should fork xulrunner (songrunner?) and make a package out of it that songbird depends on.
(In reply to comment #146) > Then dev should fork xulrunner (songrunner?) and make a package out of it that > songbird depends on. Seriously Here is the list of patches that songbird applies to xulrunner : http://wiki.songbirdnest.com/User:Stevel/XULRunner_Patches And to add up, firefox is AFAIK the only mozilla application using xulrunner in the repos. The other applications have their own bundled libs ( Seamonkey, Thunderbird, Sunbird, Spicebird ...)
(In reply to comment #147) > And to add up, firefox is AFAIK the only mozilla application using xulrunner in > the repos. The other applications have their own bundled libs ( Seamonkey, > Thunderbird, Sunbird, Spicebird ...) I don't think you are right: [root@muentzer ~]# repoquery -q --whatrequires xulrunner xulrunner-0:1.9.2.4-1.fc14.i686 azureus-0:4.3.1.4-1.fc13.noarch eclipse-rcp-1:3.6.0-3.fc14.i686 eclipse-swt-1:3.6.0-3.fc14.i686 entangle-0:0.1.0-7.fc14.i686 esc-0:1.1.0-12.fc14.i686 ethos-0:0.2.2-6.fc14.i686 firefox-0:3.6.4-2.fc14.i686 galeon-0:2.0.7-29.fc14.i686 gecko-sharp2-0:0.13-13.fc13.i686 gjs-0:0.7.1-3.fc14.i686 gnome-python2-gtkmozembed-0:2.25.3-19.fc14.i686 gnome-shell-0:2.31.5-5.fc14.i686 gnome-web-photo-0:0.9-10.fc14.i686 gxine-0:0.5.905-3.fc13.i686 hulahop-0:0.7.1-2.fc14.i686 java-1.6.0-openjdk-plugin-1:1.6.0.0-41.b18.fc13.i686 kazehakase-0:0.5.8-8.svn3873_trunk.fc14.i686 libproxy-mozjs-0:0.4.4-6.fc14.i686 mozvoikko-0:1.0-11.fc14.i686 openvrml-javascript-0:0.18.6-1.fc14.i686 perl-Gtk2-MozEmbed-0:0.08-6.fc14.15.i686 pyjamas-desktop-0:0.7-5.fc14.noarch pytrainer-0:1.6.0.8-1.fc12.noarch ruby-gtkmozembed-0:0.19.4-3.fc14.i686 xulrunner-devel-0:1.9.2.4-1.fc14.i686 xulrunner-python-0:1.9.2-3.20100111hg.fc14.i686 [root@muentzer ~]# Besides, thunderbird is working really hard to get there as well (https://bugzilla.mozilla.org/show_bug.cgi?id=377319).
But, yes embedded XULRunner is probably not breaking Packaging Guildelines.
Just thought I'd chime in and say I'm now running songbird 1.8 in Fedora 13 from the compiled build at http://wiki.songbirdnest.com/Developer/Articles/Builds/Contributed_Builds#Linux and it's running just fine here.
Sure it works, but : 1) Buildsystem is a real pain if you want to use the system's libs 2) Doesn't look like a native GTK application
1. This has already been compiled as an RPM for Fedora (see above contributed builds). This bug was closed since Songbird announced they were no longer going to do Linux. They have since reversed course. The "Generic Linux" on that page is cited as being contributed by Songbird. The project has in fact not ceased for Linux, and they are still providing the source. 2. Who cares? What does it matter if it uses GTK, Qt, or Tk for the GUI? That has never been a package requirement. If David Halik wishes to package this for Fedora, I suggest we re-open this Review.
(In reply to comment #152) > 1. This has already been compiled as an RPM for Fedora (see above contributed > builds). This bug was closed since Songbird announced they were no longer > going to do Linux. They have since reversed course. The "Generic Linux" on > that page is cited as being contributed by Songbird. The project has in fact > not ceased for Linux, and they are still providing the source. > Everything can be packaged in rpm format, that is not an issue. What matters is if the package follows fedora packaging guidelines or not. This one bundles its own xulrunner, which is really ugly and creates security problems ( unless the packager backports the patches to the bundled xulrunner ). > 2. Who cares? What does it matter if it uses GTK, Qt, or Tk for the GUI? > That has never been a package requirement. It is not a package requirement, but I think ( IMHO ) that applications which respect the DE theme fit better. > > If David Halik wishes to package this for Fedora, I suggest we re-open this > Review. If he can fix the issues, it is up to him.
At this point I have no interest in restarting the process. POTI has specifically said they will not remove the EULA, which is a major blocker, plus the xulrunner, taglib, gstreamer, etc etc, internal deps that are a major problem. I spent a ton of time on each release trying to get a stable build and there were always issue due to the different range of system deps versus internal deps. For all intents and purposes they *have* stopped Linux development. Source is still being release, but there is no attempt at fixing the numerous bugs and problems. It is what it is, and that is not a very solid Linux product at the moment. Plus my contact at POTI who was involved in the *NIX aspects has also left. So, I really don't see the point in spending time trying to maintain this package. For stability and an sanity I highly recommend someone build a nice binary blob using all internal deps and offer it up as a third party package to anyone who wants it.
I could create a local folder in /home/user to store the gstreamer is that the right was ? kindly specify me here https://thelifefoundry.com/hotmail/
I tried to install redhat and I receive multiple errors in my root directory as well. Please help me out. https://www.krishgen.com/en/yahoo-mail-login/
How about changing the contents of the directory is it gonna help? I am new to it so please do leet me know if I am wrong. http://herambachandracollege.ac.in/blog/hotmail-login/
I am not sure but try changing the directory it fixed the problem that I was having. https://www.elkjournals.com/blogs/hotmail-login/
I changed the directory and it really worked. You should also try that, I really hope it works for you as well. https://www.elkjournals.com/eng/hotmail-login/ https://webwiztech.com/blog/kisscartoon/ https://efpm.isb.edu/blog/en/gmail-signup/
Thank you for you help and these useful resource: https://techshali.com/hotmail-sign/ https://techshali.com/facebook-login/ https://techshali.com/login-sign-in-gmail/
done. thanks for the hard work. <a href="https://sites.google.com/view/onewebtech/home">gmail.com</a>
Does there have any other version then this one? I really wanted to try. https://www.first-recruitment.com/online/blog/intl-en/icloud-login/
Can i get more details on this one? https://www.gmswindows.org/blogs/snapchat-login/
Well if it isn't a bug then what is it? Please explain briefly. https://www.aios.org/blogs/facebook-login/
Thanks, this review helps a lot, I'll try to use the songbird now. Hope it will work fine. https://www.ijcseonline.org/blogs/facebook-login/
Thanks for the info, btw is Songbird still the best media player for Firefox? https://www.ijcseonline.org/blogs/facebook-login/
Is there any application of Songbird for Android as well? https://paradipport.gov.in/en/hotmail-login/
This bug is being fixed? or it's still there? please elaborate. https://yt2mp3.id/es/
https://www.brownbooks.com/blogs/assignment-help.html free and if you are Looking out for your assessment answers online Grab the opportunity to find free assignment answers related to all subjects in your Academic.
https://www.brownbooks.com/blogs/msn-login.html this article help me out for making my new msn account
https://clinmedjournals.org/articles/cmil/cricbuzz.html is very helpful for me because i am a cricket fan
What was the last version of songbird that was released? And did they patch the bug in that version? https://geospatialworldforum.org/blogs/hotmail-signup/
(In reply to Cynthia Parker from comment #173) > What was the last version of songbird that was released? And did they patch > the bug in that version? > https://geospatialworldforum.org/blogs/hotmail-signup/ Yes, I believe the bug was patched on that version. But I am looking for more information on their usage. It will be appreciated if you help me in this matter. You can contact me via : https://www.baidoauniversity.edu.so/intl/blogs/icloud-login/ https://www.corazonhomes.com/intl/blog/instagram-login/ https://iwra.org/intl/blog/gmail-login/ https://www.bestbookcentre.com/pages/blog/snapchat-login/ https://www.bestbookcentre.com/pages/blog/outlook-login/
Does Mozilla Firefox still support this app namely songbird in its newer versions? https://geospatialmedia.net/blogs/192-168-0-1/
I heard that Firefox discontinued the Songbird in the latest versions. is it true? If yes, then what are they using now instead of the Songbird? https://www.jcreview.com/blogs/hotmail-login/
This is really frustrating since all of my notifications are turned on, and after uninstalling <a href="http://iyogi.com/eng/facebook-login/" >www.facebook.com</a> and redownloading it, I am still unable to access my account.
No, everything you store in a PST file stays on your computer. If you delete the PST file from the computer that isn't yours without closing it "inside" Outlook, Outlook will still be looking for the file but won't have any of its data. http://iyogi.com/eng/outlook-login/
Email would not allow me in, and http://iyogi.com/eng/aol-mail/ will not assist me since the account was a waste of time.
Recently, I used iCloud to remove almost 2000 images from my phone; yet, the total amount of storage space that my photos take up on my phone has remained virtually same at roughly 1.3 gigabytes. http://iyogi.com/eng/icloud-login/
Hello everyone. I am attempting to use the deployment tool in order to install <a href="http://iyogi.com/eng/office-365-login/" >www.office365.com</a> on a number of different customers.
If you're encountering difficulties with Songbird, it's important to note that it may not be compatible with current versions of Mozilla Firefox or other modern web browsers. As a result, it's recommended to explore alternative media players that are actively maintained and compatible with the latest browser versions. There are numerous media players available that offer similar functionality to Songbird, such as VLC, foobar2000, Winamp, and MusicBee. These players are regularly updated and provide a wide range of features to enhance your music listening experience. https://medcraveonline.com/articles/hotmail-signup/
Hotmail, a groundbreaking email service that forever changed the way we communicate, deserves profound appreciation for its transformative impact. Introduced in 1996, Hotmail revolutionized the concept of electronic correspondence by providing individuals with a web-based platform accessible from anywhere in the world. With its user-friendly interface, generous storage capacity, and innovative features, Hotmail enabled seamless communication and connectivity on a global scale. It played a pivotal role in shaping the modern digital landscape, empowering millions of users to effortlessly exchange messages, share files, and forge connections that transcend borders. Hotmail's visionary leap and enduring legacy deserve heartfelt recognition for revolutionizing the way we stay connected in the digital age. https://medcraveonline.com/articles/hotmail-login/
Is songbird compatible with the latest versions of Mozilla Firefox? or is it discontinued? https://medcraveonline.com/articles/fb-login/
You greatly aided me. I'm grateful for this webpage. Your website has to be upgraded for your users to feel grateful and satisfied. https://medcraveonline.com/new/en-us/whatsapp-web-login/