Bug 453422 (songbird) - Review Request: songbird - Mozilla based multimedia player
Summary: Review Request: songbird - Mozilla based multimedia player
Keywords:
Status: CLOSED NOTABUG
Alias: songbird
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-30 15:10 UTC by David Halik
Modified: 2023-07-21 09:29 UTC (History)
59 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-05 16:06:47 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Songbird trace, seg fault when playing (68.75 KB, text/plain)
2010-01-28 06:39 UTC, Scott Williams
no flags Details

Description David Halik 2008-06-30 15:10:06 UTC
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.

Comment 1 David Halik 2008-06-30 18:12:01 UTC
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.

Comment 2 David Halik 2008-07-01 12:50:11 UTC
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


Comment 3 David Halik 2008-07-05 21:36:19 UTC
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


Comment 4 Casey Dahlin 2008-07-15 20:05:29 UTC
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.

Comment 5 David Halik 2008-07-15 20:14:10 UTC
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.

Comment 6 Casey Dahlin 2008-07-15 20:31:49 UTC
Upstream is the preferred option.

Shoot off an email to gecko-maint and see what they think.


Comment 7 David Halik 2008-07-15 20:41:12 UTC
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...

Comment 8 Casey Dahlin 2008-07-15 21:39:11 UTC
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.

Comment 9 Peter Robinson 2008-08-11 11:46:06 UTC
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.

Comment 10 Stephen Lau 2008-08-12 23:26:39 UTC
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

Comment 11 Peter Robinson 2008-08-13 08:25:22 UTC
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.

Comment 12 David Halik 2008-08-27 02:04:39 UTC
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

Comment 13 Peter Robinson 2008-08-30 13:44:24 UTC
Songbird now has a tracking bug in upstream Mozilla BZ to track their xulrunner issues. https://bugzilla.mozilla.org/show_bug.cgi?id=357052

Comment 14 David Halik 2008-12-08 16:44:13 UTC
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

Comment 15 Peter Robinson 2008-12-08 16:49:18 UTC
What is the status of being about to build it with the distro gstreamer/xulrunner?

Comment 16 Stephen Lau 2008-12-08 16:59:49 UTC
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.

Comment 17 David Halik 2008-12-08 18:04:58 UTC
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.

Comment 18 Peter Robinson 2008-12-08 18:59:19 UTC
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

Comment 19 Stephen Lau 2008-12-08 19:03:48 UTC
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.

Comment 20 Nicolas Chauvet (kwizart) 2009-01-30 12:54:15 UTC
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

Comment 21 Stephen Lau 2009-01-30 14:31:57 UTC
(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. :(

Comment 22 David Halik 2009-01-30 15:11:16 UTC
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

Comment 23 Nikolay Vladimirov 2009-01-31 21:08:29 UTC
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.

Comment 24 Peter Robinson 2009-02-01 07:44:56 UTC
> 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.

Comment 25 Nicolas Chauvet (kwizart) 2009-02-02 11:04:56 UTC
(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.

Comment 26 David Halik 2009-02-02 18:33:47 UTC
@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.

Comment 27 David Halik 2009-02-12 22:30:10 UTC
@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?

Comment 28 David Halik 2009-02-13 21:46:24 UTC
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

Comment 29 Nicolas Chauvet (kwizart) 2009-03-02 13:53:56 UTC
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.

Comment 30 David Halik 2009-03-12 19:28:46 UTC
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

Comment 31 David Halik 2009-03-13 17:36:14 UTC
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

Comment 32 Nicolas Chauvet (kwizart) 2009-03-16 20:28:48 UTC
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.

Comment 33 Vladimir Kotal 2009-03-19 10:02:25 UTC
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

Comment 34 Nicolas Chauvet (kwizart) 2009-03-19 10:44:01 UTC
(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 ?

Comment 35 David Halik 2009-03-19 11:07:19 UTC
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?

Comment 36 Rex Dieter 2009-03-19 13:17:29 UTC
hi, I help maintain taglib in fedora, I can help with integration efforts here once taglib2 lands.

Comment 37 Stephen Lau 2009-03-21 22:26:08 UTC
(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.

Comment 38 David Halik 2009-03-24 18:49:15 UTC
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.

Comment 39 Rahul Sundaram 2009-03-28 03:26:37 UTC
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?

Comment 40 Stephen Lau 2009-03-28 16:43:00 UTC
(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

Comment 41 Rahul Sundaram 2009-03-28 17:26:59 UTC
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

Comment 42 Nicolas Chauvet (kwizart) 2009-04-04 08:42:19 UTC
@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 ?

Comment 43 Peter Robinson 2009-04-04 09:15:12 UTC
> 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

Comment 44 David Halik 2009-04-04 14:50:03 UTC
(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.

Comment 45 Nicolas Chauvet (kwizart) 2009-04-06 09:53:43 UTC
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 ?

Comment 46 David Halik 2009-04-07 00:05:45 UTC
@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

Comment 47 David Halik 2009-04-07 14:35:05 UTC
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?

Comment 48 Rex Dieter 2009-04-07 14:50:34 UTC
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.

Comment 49 David Halik 2009-04-07 15:09:05 UTC
FYI, host_ifparser.c is just an example of the compile options RPM_OPT_FLAGS was adding, not the specific problem.

Comment 50 David Halik 2009-04-07 16:46:51 UTC
For tracking the buffer overflow with RPM_OPT_FLAGS:

http://bugzilla.songbirdnest.com/show_bug.cgi?id=16022

Comment 51 David Halik 2009-04-07 20:42:47 UTC
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

Comment 52 Nicolas Chauvet (kwizart) 2009-04-11 01:08:23 UTC
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.

Comment 53 David Halik 2009-04-14 18:55:19 UTC
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?

Comment 54 Stephen Lau 2009-04-14 21:55:10 UTC
1.1.2 source tarballs are up now:
http://wiki.songbirdnest.com/Developer/Articles/Builds/Contributed_Builds

Comment 55 David Halik 2009-04-15 01:51:52 UTC
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.

Comment 56 Jasper Capel 2009-04-17 13:46:29 UTC
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?

Comment 57 David Halik 2009-04-17 14:29:08 UTC
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.

Comment 58 Jasper Capel 2009-04-17 14:58:52 UTC
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.

Comment 59 Nicolas Chauvet (kwizart) 2009-04-17 15:18:17 UTC
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.

Comment 60 Jasper Capel 2009-04-17 17:15:15 UTC
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.

Comment 61 David Halik 2009-04-18 16:04:13 UTC
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

Comment 62 David Halik 2009-05-04 13:50:57 UTC
Any recent thoughts kwizart? Haven't heard any updates from you since the rpmlint issues were fixed.

Comment 63 Nicolas Chauvet (kwizart) 2009-05-07 12:57:30 UTC
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.

Comment 64 Nicolas Chauvet (kwizart) 2009-05-07 16:22:34 UTC
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.

Comment 65 Stephen Lau 2009-06-04 23:58:25 UTC
(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

Comment 66 Matěj Cepl 2009-06-05 09:35:51 UTC
(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.

Comment 67 Tom "spot" Callaway 2009-06-05 14:33:13 UTC
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

Comment 68 Stephen Lau 2009-06-10 19:05:13 UTC
(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.

Comment 69 Stephen Lau 2009-06-10 19:07:20 UTC
(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

Comment 70 Matěj Cepl 2009-06-14 10:42:20 UTC
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)

Comment 71 Nicolas Chauvet (kwizart) 2009-06-14 15:40:36 UTC
(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.

Comment 72 David Halik 2009-06-15 16:23:28 UTC
1.2 is due out shortly. I'll remove the $ORIGIN rpath in the next build and repost.

Comment 73 David Halik 2009-06-22 16:45:54 UTC
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.

Comment 75 David Halik 2009-06-23 20:42:03 UTC
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

Comment 76 Nicolas Chauvet (kwizart) 2009-07-07 08:30:52 UTC
(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

Comment 77 Jakub Hrozek 2009-07-14 08:15:49 UTC
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.

Comment 78 David Halik 2009-07-14 11:35:31 UTC
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.

Comment 79 Scott Williams 2009-07-17 23:55:55 UTC
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.

Comment 80 Matěj Cepl 2009-07-18 09:43:14 UTC
(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).

Comment 81 Matěj Cepl 2009-07-18 09:51:38 UTC
(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.

Comment 82 Nicolas Chauvet (kwizart) 2009-09-17 22:29:42 UTC
Any NEWS from the SongBird Legals (and improvement on the rpath issue for the packaging side)?

Comment 83 David Halik 2009-09-18 14:59:05 UTC
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.

Comment 84 Scott Williams 2009-10-01 16:51:01 UTC
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.

Comment 85 David Halik 2009-10-01 16:59:42 UTC
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.

Comment 86 Scott Williams 2009-10-01 17:30:53 UTC
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.

Comment 87 Joel 2009-11-16 16:03:01 UTC
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.

Comment 88 Dean Mander 2009-11-24 12:57:26 UTC
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

Comment 89 Sebastian Krämer 2009-12-22 18:55:21 UTC
1.4 release?

Comment 90 David Halik 2009-12-22 18:59:48 UTC
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.

Comment 91 Scott Williams 2009-12-22 21:56:44 UTC
Looks like 1.4 source is available: http://publicsvn.songbirdnest.com/client/branches/Songbird1.4/

Comment 92 Scott Williams 2009-12-22 22:18:27 UTC
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.

Comment 93 Andreas Petzold 2009-12-23 10:54:42 UTC
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? :-)

Comment 94 David Halik 2009-12-23 17:36:41 UTC
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.

Comment 95 Andreas Petzold 2009-12-24 18:07:19 UTC
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.

Comment 96 Scott Williams 2009-12-25 06:29:41 UTC
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.

Comment 97 zhihengz 2010-01-05 23:30:57 UTC
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.

Comment 98 DuvJones 2010-01-22 07:45:57 UTC
(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.

Comment 99 David Halik 2010-01-26 20:25:03 UTC
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.

Comment 100 DuvJones 2010-01-27 23:27:46 UTC
That is good.... and thank you.

Comment 101 David Halik 2010-01-28 03:07:27 UTC
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.

Comment 102 Scott Williams 2010-01-28 03:53:33 UTC
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.

Comment 103 David Halik 2010-01-28 03:59:20 UTC
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

Comment 104 David Halik 2010-01-28 04:34:52 UTC
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

Comment 105 Scott Williams 2010-01-28 06:25:49 UTC
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?

Comment 106 Matěj Cepl 2010-01-28 06:31:20 UTC
(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.

Comment 107 Scott Williams 2010-01-28 06:38:47 UTC
I spoke too soon.  It crashes consistently about 2 seconds into playing any song.  Attaching debug trace.

Comment 108 Scott Williams 2010-01-28 06:39:33 UTC
Created attachment 387252 [details]
Songbird trace, seg fault when playing

Comment 109 Matěj Cepl 2010-01-28 06:43:36 UTC
I meant to say, please, file a bug against gstreamer-schroedinger about it.

Thank you

Comment 110 Scott Williams 2010-01-28 06:47:56 UTC
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.

Comment 111 Nicolas Chauvet (kwizart) 2010-01-28 08:38:52 UTC
have you tried to rebuild shroedinger ? (that provides a gstreamer-schroedinger subpacakge).

Comment 112 David Halik 2010-01-28 13:34:08 UTC
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.

Comment 113 gatlibs 2010-01-30 01:59:47 UTC
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?

Comment 114 gatlibs 2010-01-30 04:50:22 UTC
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?

Comment 115 David Halik 2010-01-30 05:00:00 UTC
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.

Comment 116 Matěj Cepl 2010-01-30 09:11:26 UTC
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?

Comment 117 Nicolas Chauvet (kwizart) 2010-01-30 09:53:46 UTC
(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 !

Comment 118 gatlibs 2010-01-30 22:48:42 UTC
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.

Comment 119 David Halik 2010-01-30 23:02:59 UTC
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*

Comment 120 gatlibs 2010-01-30 23:23:46 UTC
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?

Comment 121 David Halik 2010-01-30 23:43:20 UTC
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.

Comment 122 Matěj Cepl 2010-01-31 21:39:39 UTC
(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.

Comment 123 Scott Williams 2010-02-24 21:59:01 UTC
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.

Comment 124 gatlibs 2010-03-10 18:10:36 UTC
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.

Comment 125 Scott Williams 2010-03-15 19:51:16 UTC
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.

Comment 126 Matěj Cepl 2010-04-03 07:55:57 UTC
Does http://blog.songbirdnest.com/2010/04/02/songbird-singing-a-new-tune/ mean CLOSED/WONTFIX for this bug and for whole Songbird package?

Comment 127 Tom "spot" Callaway 2010-04-03 11:48:00 UTC
(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.

Comment 128 Jonas Wielicki 2010-04-03 16:49:46 UTC
Well, at least they want to continue the nightly builds. I don't know whether this is a solution though.

Comment 129 David Halik 2010-04-05 13:46:32 UTC
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.

Comment 130 Henrique C. S. Junior 2010-04-05 16:06:47 UTC
Done. Thank you for the hard work.

Comment 131 DuvJones 2010-04-06 04:33:57 UTC
David... Thank you.

Comment 132 Kamisamanou Burgess 2010-04-06 21:48:26 UTC
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

Comment 133 Rahul Sundaram 2010-04-07 05:42:52 UTC
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.

Comment 134 Matěj Cepl 2010-04-07 08:53:12 UTC
(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.

Comment 135 David Halik 2010-04-07 12:11:36 UTC
@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.

Comment 136 Rahul Sundaram 2010-04-07 12:33:25 UTC
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.

Comment 137 Tim Lauridsen 2010-04-09 14:20:49 UTC
Songbird is forked for Linux

http://getnightingale.org/

Comment 138 Matěj Cepl 2010-04-09 17:29:44 UTC
(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.

Comment 139 Scott Williams 2010-07-09 22:55:43 UTC
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.

Comment 140 Joel 2010-07-10 01:00:22 UTC
The obnoxious EULA for songbird must be removed from this version.  I'm pretty sure this is still blocked on legal.

Comment 141 Hicham HAOUARI 2010-07-18 12:07:09 UTC
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.

Comment 142 Casey Dahlin 2010-07-19 17:05:57 UTC
(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.

Comment 143 Hicham HAOUARI 2010-07-19 18:16:34 UTC
(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.

Comment 144 Rahul Sundaram 2010-07-19 18:35:28 UTC
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

Comment 145 Hicham HAOUARI 2010-07-19 18:48:00 UTC
(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.

Comment 146 Joel 2010-07-19 20:59:45 UTC
Then dev should fork xulrunner (songrunner?) and make a package out of it that songbird depends on.

Comment 147 Hicham HAOUARI 2010-07-20 01:22:04 UTC
(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 ...)

Comment 148 Matěj Cepl 2010-07-20 10:08:07 UTC
(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).

Comment 149 Matěj Cepl 2010-07-20 10:08:50 UTC
But, yes embedded XULRunner is probably not breaking Packaging Guildelines.

Comment 150 Scott Williams 2010-09-11 23:51:22 UTC
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.

Comment 151 Hicham HAOUARI 2010-09-11 23:58:15 UTC
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

Comment 152 Scott Williams 2010-09-12 07:15:20 UTC
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.

Comment 153 Hicham HAOUARI 2010-09-12 15:11:30 UTC
(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.

Comment 154 David Halik 2010-09-13 13:03:33 UTC
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.

Comment 155 oliviajohn 2020-04-17 18:28:38 UTC Comment hidden (spam)
Comment 156 Ketaval 2020-09-05 12:03:23 UTC Comment hidden (spam)
Comment 157 Jessica Brite 2020-09-21 11:15:29 UTC Comment hidden (spam)
Comment 158 Catoxi 2021-04-02 12:52:56 UTC Comment hidden (spam)
Comment 159 Julie Max 2021-07-18 11:22:40 UTC Comment hidden (spam)
Comment 160 dgdeepak000 2021-08-13 12:28:41 UTC Comment hidden (spam)
Comment 161 sam 2021-10-20 20:54:10 UTC Comment hidden (spam)
Comment 162 Julia Ash 2021-10-20 22:04:50 UTC Comment hidden (spam)
Comment 163 Rosie Will 2021-10-22 20:26:49 UTC Comment hidden (spam)
Comment 164 Rosie Will 2022-06-17 13:31:11 UTC Comment hidden (spam)
Comment 165 Mike Aiden 2022-09-19 21:15:16 UTC Comment hidden (spam)
Comment 166 Kate Aiden 2022-10-20 00:28:04 UTC Comment hidden (spam)
Comment 167 Glenn Riley 2022-11-10 00:00:15 UTC Comment hidden (spam)
Comment 168 Taha 2022-12-19 02:30:52 UTC Comment hidden (spam)
Comment 169 david 2023-01-11 18:09:11 UTC Comment hidden (spam)
Comment 170 david 2023-01-11 18:12:20 UTC Comment hidden (spam)
Comment 171 david 2023-01-11 18:15:19 UTC Comment hidden (spam)
Comment 172 david 2023-01-11 18:30:09 UTC Comment hidden (spam)
Comment 173 Cynthia Parker 2023-02-18 15:01:26 UTC Comment hidden (spam)
Comment 174 Sameer Siddiqui 2023-04-10 03:48:40 UTC Comment hidden (spam)
Comment 175 Hazel S. Ken 2023-04-15 20:30:48 UTC Comment hidden (spam)
Comment 176 Anna Huang 2023-05-25 21:39:40 UTC Comment hidden (spam)
Comment 177 david 2023-05-31 17:31:56 UTC Comment hidden (spam)
Comment 178 david 2023-05-31 18:06:51 UTC Comment hidden (spam)
Comment 179 david 2023-05-31 18:13:45 UTC Comment hidden (spam)
Comment 180 david 2023-05-31 18:27:29 UTC Comment hidden (spam)
Comment 181 david 2023-05-31 18:31:23 UTC Comment hidden (spam)
Comment 182 Karl Anderson 2023-07-05 13:24:26 UTC Comment hidden (spam)
Comment 183 Nancy Aiden 2023-07-10 08:27:49 UTC Comment hidden (spam)
Comment 184 Emma Clark 2023-07-13 08:31:32 UTC Comment hidden (spam)
Comment 185 rebbeca 2023-07-21 08:31:44 UTC Comment hidden (spam)

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