Created attachment 331515 [details] Miro spec for version 2.0 Description of problem: Miro 2.0 has just been released, and the interface looks much cleaner. I've been able to compile it without most of the patches, but as it generates some rpmlint errors, I'm not ready to check this into Rawhide just yet. Version-Release number of selected component (if applicable): 1.2.8-5 RPMlint warnings: Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/plat/frontends/widgets/windowcreator.so Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/xine.so Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/plat/frontends/widgets/pluginsdir.so Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/sorts.so Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/database.so Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/fasttypes.so Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/plat/xlibhelper.so Miro.x86_64: W: unstripped-binary-or-object /usr/libexec/xine_extractor Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/plat/frontends/widgets/httpobserver.so Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/libtorrent.so Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/plat/frontends/widgets/mozprompt.so Miro.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.5/site-packages/miro/frontends/widgets/gtk/pygtkhacks.so Miro.x86_64: W: file-not-in-%lang /usr/share/miro/resources/testdata/locale/fr/LC_MESSAGES/miro.mo 1 packages and 0 specfiles checked; 0 errors, 13 warnings. The last one can probably be ignored -- it's just test data. Should we remove the entire testdata directory, even? The stripping, I'm not sure why it's not done automatically. This is tested on Fedora 10 -- still installing my Rawhide virtual machine, after downgrading the physical box back to F-10 to get a functioning Mono stack.
Created attachment 331516 [details] Patch to install helper binary in libexec, not /usr/lib/miro
This release allows building against system rb_libtorrent: http://bugzilla.pculture.org/show_bug.cgi?id=10263 we should also modify the spec file to add the appropriate Requires: +BuildRequires: rb_libtorrent-devel rb_libtorrent-python +Requires: rb_libtorrent-python and ensure that it doesn't build the bundled bindings. The lack of stripping is odd. Also not sure about the testdata directory if it's needed, perhaps Will can weigh in.
Created attachment 331526 [details] Updated patch to use system rb_libtorrent I updated the patch and did a scratch koji build in rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=1118843 We can also drop the boost patch as that was only needed for building libtorrent rasterbar (rb_rasterbar).
Note that we may have to conditionalize the support for system rb_libtorrent for F11+ as it appears it requires at least version 0.14 but F-10 and earlier are still on 0.13.
Look at this bug which has a patch to allow Miro 2.0 to use system libtorrent 0.13: http://bugzilla.pculture.org/show_bug.cgi?id=11385 I hope to apply it in 2.0.1, but it didn't make it into 2.0. You can remove resources/testdata/. Unit tests won't run without it, but that probably doesn't matter. I really appreciate how fast you guys move on this. If you need me, I'm on #miro-hackers on freenode and I'm monitoring F9 and F10 bugs in your system, too.
Ah. We don't currently use the unit tests, as far as I know. We should probably enable it, however, it currently fails on my machine: ====================================================================== ERROR: testRestore (miro.test.httpdownloadertest.HTTPDownloaderTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python2.5/site-packages/miro/test/httpdownloadertest.py", line 138, in testRestore self.runEventLoop() File "/usr/lib64/python2.5/site-packages/miro/test/framework.py", line 135, in runEventLoop raise HadToStopEventLoop() HadToStopEventLoop ---------------------------------------------------------------------- Ran 314 tests in 46.403s FAILED (errors=1) If the test really requires HTTP connection, I wonder if it's safe to use in the Koji build system. What are the guidelines about such cases?
(In reply to comment #6) > If the test really requires HTTP connection, I wonder if it's safe to use in > the Koji build system. What are the guidelines about such cases? Packages should never rely on having network connectivity during a build, as far as I know, although I'm not sure if that's codified in the packaging guidelines. I have had to disable them in other packages (e.g. Perl packages that have test cases that want to download data from webpages).
Looks like the non-stripping of files is only when I'm doing local builds; Koji output is clean. I've made a few more changes: - use Will's patch for compiling against libtorrent 0.13 - change default download directory to ~/Videos/Miro. ~/Videos is present on the default Fedora desktop, whereas ~/Movies is a Mac/Windows folder - Exclude testdata directory from file listing Committing the changes to -devel, but not tagging yet. Please take a look and, if you're fine with it, tag and build? It works fine for me on F-10, so after a few days perhaps we can consider pushing an update there too.
Koji build for F-10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1129253
(In reply to comment #8) > Looks like the non-stripping of files is only when I'm doing local builds; Koji > output is clean. > > I've made a few more changes: > - use Will's patch for compiling against libtorrent 0.13 > - change default download directory to ~/Videos/Miro. ~/Videos is present on > the default Fedora desktop, whereas ~/Movies is a Mac/Windows folder > - Exclude testdata directory from file listing > > Committing the changes to -devel, but not tagging yet. Please take a look and, > if you're fine with it, tag and build? It works fine for me on F-10, so after a > few days perhaps we can consider pushing an update there too. Looks like Miro-2.0-videodir.patch wasn't committed to CVS. Can you add and then I can test (and ultimately tag and build). The other changes you suggest seem fine to me.
Patch now added.
Built for rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=82875 We should leave this bug open and let the F-10 build close it via a bodhi update.
We can probably close the other two Miro bugs too: screensaver not inhibited and crash with Xine: I'm making them block on this, so that when we push the F-10 build we don't forget to mark the update as closing those bugs too.
We should also note in the bodhi notes for updates-testing that Miro 2.0 changes the configuration files in ~/.miro in a way that's backwards-incompatible with Miro 1.2.x and warn them to backup their ~/.miro directory if they want to downgrade to Miro 1.2.x after testing 2.0.
I made the F-10 spec file changes and rebuilt and tested the F-10 build on my local system. It seems to work fine. However, I'm still getting occasional crashes with the xine backend, but this isn't any worse than previous, so I'm going to push to updates-testing.
Miro-2.0-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/Miro-2.0-1.fc10
Miro-2.0-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update Miro'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2084
Miro-2.0-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/Miro-2.0-2.fc10
Miro-2.0-3.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update Miro'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2139
Miro-2.0-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.