Bug 554243 (moovida)

This looks like more than one package.  Please, one package per review ticket, and if the packages have interdependencies then use the "Depends On:" and "Blocks:" fields to indicate that.

*** Bug 530021 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> This looks like more than one package.  Please, one package per review ticket,
> and if the packages have interdependencies then use the "Depends On:" and
> "Blocks:" fields to indicate that.    

Is this really necessary?  With such an interrelated set of packages, it makes very difficult to track all the packages and since the plugins packages are required by the base package at install and runtime it doesn't really make sense to review them separately.  This is basically a rename of an existing package, elisa in any case (original review request: bug #233598).

Graeme: don't forget you needed to add the FE-NEEDSPONSOR bug blocker. I did this for you just now.

*** Bug 510965 has been marked as a duplicate of this bug. ***

Matthias: ping?    Please let Graeme know if you can do the review, otherwise this review will stall completely, if it hasn't already.

Graeme, if you're still interested, you may need to search for a new sponsor given that no response from Matthias for > 2 months.

I can review them if Matthias can't.

(In reply to comment #7)
> I can review them if Matthias can't.    

Hi Peter, thanks for the offer, but are you a sponsor?  Since this is Graeme's first package, he has to be reviewed by a sponsor, otherwise I would have reviewed this myself long ago.  That was why Matthias volunteered (since he is a sponsor).

(In reply to comment #8)
> (In reply to comment #7)
> > I can review them if Matthias can't.    
> 
> Hi Peter, thanks for the offer, but are you a sponsor?  Since this is Graeme's
> first package, he has to be reviewed by a sponsor, otherwise I would have
> reviewed this myself long ago.  That was why Matthias volunteered (since he is
> a sponsor).    

The reviewer and sponsor are generally different people. The sponsor helps Graeme through the process that the reviewer completes. I would ask the list for help.

Also as mentioned by Jason each package will need to be split out into a separate review as each package needs to go through the following guidelines https://fedoraproject.org/wiki/Packaging:ReviewGuidelines and then have a CVS request which will confuse things as to what package needs what fixed. See bug 553717 as an example.

Finally if its just a rename you can do a rename request for the package which is quicker. See 517300 for an example. Graeme will still need a sponsor for that.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > I can review them if Matthias can't.    
> > 
> > Hi Peter, thanks for the offer, but are you a sponsor?  Since this is Graeme's
> > first package, he has to be reviewed by a sponsor, otherwise I would have
> > reviewed this myself long ago.  That was why Matthias volunteered (since he is
> > a sponsor).    
> 
> The reviewer and sponsor are generally different people. The sponsor helps
> Graeme through the process that the reviewer completes. I would ask the list
> for help.

That's not my understanding:

"The Reviewer can be any Fedora account holder, who is a member of the packager group. There is one exception: If it is the first package of a Contributor, the Reviewer must be a Sponsor."

from:

https://fedoraproject.org/wiki/Package_Review_Process#Reviewer

but if others are OK with it, I'm fine with the sponsor doing the final sign-off, as I'm keen to get this package updated ASAP.

> Also as mentioned by Jason each package will need to be split out into a
> separate review as each package needs to go through the following guidelines
> https://fedoraproject.org/wiki/Packaging:ReviewGuidelines and then have a CVS
> request which will confuse things as to what package needs what fixed. See bug
> 553717 as an example.

I understand, but I think that because of the package interdependencies that it makes sense to review this as a single package.  How about opening up separate bugs for each tarball, but doing the main review/discussion (at least initially) in one bug to allow cross-package issues to be discussed in one plac?.  Then the final review checklist can be posted to the relevant bug and the CVS request done in the separate bug.

> Finally if its just a rename you can do a rename request for the package which
> is quicker. See 517300 for an example. Graeme will still need a sponsor for
> that.    

I think a full review is in order here because of the time since the last update.

Everyone can do informal reviews, even for review requests blocking
FE-NEEDSPONSOR, which can make review process faster and are always
welcomed. However review requests blocking FE-NEEDSPONSOR must finally
be reviewed and approved (formally) only by sponsor members.

(In reply to comment #11)
> Everyone can do informal reviews, even for review requests blocking
> FE-NEEDSPONSOR, which can make review process faster and are always
> welcomed. However review requests blocking FE-NEEDSPONSOR must finally
> be reviewed and approved (formally) only by sponsor members.    

Right, that is indeed my understanding.  So Peter, yes, please do go ahead and do the "informal" review if you're still interested.  We still need to recruit a sponsor for this.

Hi Guys,

Just wanted to let you know I am still here and reading all the comments. It's been bounced back and forward between people weather I need to open a ticket for each package or not, but I can't see a solid answer.

Should I be creating a new bug for each package?

(In reply to comment #13)
> Hi Guys,
> 
> Just wanted to let you know I am still here and reading all the comments. It's
> been bounced back and forward between people weather I need to open a ticket
> for each package or not, but I can't see a solid answer.
> 
> Should I be creating a new bug for each package?    

Probably a good idea.  Just make this bug for the main package (moovida) keep the initial overall discussion in this bug and all package-specific comments and reviews in the separate bugs for each of the plugin packages, then make all the moovida-plugin-* packages depend on this bug so they can be tracked.

(In reply to comment #13)

> Should I be creating a new bug for each package?    

Yes.

Hi,

I have created the following bugs to track each of the two plugin packages

moovida-plugins-good
https://bugzilla.redhat.com/show_bug.cgi?id=576757

moovida-plugins-bad
https://bugzilla.redhat.com/show_bug.cgi?id=576758

Add back the blocking bugs for bug #576757 and bug #576758 for tracking.  (Graeme: it's handy to use the bug #<number> which autogenerates links in comments).

Peter: any chance you could do the informal review while we recruit a new sponsor?  (I think we should give up on Matthias for the moment).

(In reply to comment #18)
> Peter: any chance you could do the informal review while we recruit a new
> sponsor?  (I think we should give up on Matthias for the moment).    

Yes, I'll try to get to it over the weekend.

Holy crap those packages were submitted three months ago. To think everything is moving at a snail's pace only because of bureaucracy...

Let me know if there's anything I can do to help as an outsider.

(In reply to comment #19)
> (In reply to comment #18)
> > Peter: any chance you could do the informal review while we recruit a new
> > sponsor?  (I think we should give up on Matthias for the moment).    
> 
> Yes, I'll try to get to it over the weekend.    

Ping?

> > Yes, I'll try to get to it over the weekend.    
> 
> Ping?    

Sorry. Things got a little crazy. Doing an informal review now. Still no sponsor?

it seems anyway that moovida is drifting away from a cool program to a program that look like any other media player :-(

> it seems anyway that moovida is drifting away from a cool program to a program
> that look like any other media player

That has nothing to do with the review. Please keep opinions off the bug. This is about the technical review to include it in Fedora.

Hi Peter, any chance you'll be able to look into doing a review?  Now that elisa has been completely removed from Fedora it would be great to get moovida back in.

From an initial look.
- plugins-bad has massive amounts of the following errors that need to be fixed. 
warning: File listed twice: /usr/lib/python2.6/site-packages/elisa/plugins/search/i18n/sk
warning: File listed twice: /usr/lib/python2.6/site-packages/elisa/plugins/search/i18n/sk/LC_MESSAGES
warning: File listed twice: /usr/lib/python2.6/site-packages/elisa/plugins/search/i18n/sk/LC_MESSAGES/elisa-plugin-search.mo
- Shouldn't use %exclude but rather just remove the files during the %install section. This is especially the case for the windows stuff.

I'm also not sure if it needs the various explicit python requires or whether the rpm auto requires will sort them out.

where are moovida packages for fedora 13  ? , since "elisa is obsoleted by moovida"

(In reply to comment #27)
> where are moovida packages for fedora 13  ? , since "elisa is obsoleted by
> moovida"    

Unfortunately moovida's replacement hasn't yet passed review (see above comments).   

Graeme: are you still interested in this package?  Have you had a chance to look into the error that Peter identified in comment #26, above?

I think this review might have to be considered stalled.

Last comment from Graeme was 2010-03-24, which is more than 3 months ago, I posted a request for status update over a week ago (2010-06-23), therefore according to policy:

https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews#Submitter_not_responding

I am closing this as NOTABUG and marking as FE-DEADREVIEW in the hope that somebody else can start a new review.

(In reply to comment #29)

> I posted a request for status update over a week ago (2010-06-23), therefore
> according to policy:

a week , if the guy is on holidays ? , IMHO you should wait a year .

(In reply to comment #30)
> (In reply to comment #29)
> 
> > I posted a request for status update over a week ago (2010-06-23), therefore
> > according to policy:
> 
> a week , if the guy is on holidays ? , IMHO you should wait a year .    

There's nothing to stop the submitter re-opening the bug and continuing the review.   We waited for over 3 months for an update, and still nothing, as per policy:

https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews#Submitter_not_responding

Closing it will allow somebody else to open a new review without thinking that somebody else is working on it, otherwise it might stay in this limbo state forever.

Hi,

I apologise for not replying to this ticket sooner. I was keeping an eye on it, but I was holding off doing any more work on packaging moovida as moovida 2.0 had been anounced and the linux port released to limited testing, and I wanted to see the feasibility of packaging that for fedora instead. Unfortunately due to licensing and fluendo's resistance to releasing pure tarballs, it looks like moovida 2.0 probably won't be making it into fedora anytime soon. On top of this, moovida 1.0 is no longer formerly supported by fluendo, so getting futher updates or bugs fixed in moovida may be tricky.

I was also away for the last 3 weeks on holiday which is why I didn't reply straight away.

Anyway I have had a look over the spec files and the comments above and have fixed the outstanding problems raised. I have created new rpms for both moovida, and the good and bad plugins packages (see the other bugs for the other packages).

moovida.spec
http://ggillies.fedorapeople.org/moovida.spec

moovida-1.0.9-3.fc13.src.rpm
http://ggillies.fedorapeople.org/moovida-1.0.9-3.fc13.src.rpm

I'm still keen to get 1.0 into fedora, and I am re-opening this review in the hopes of taking up Hans de Goede's offer of review and sponsorship

(In reply to comment #32)
> Hi,
> 
> I apologise for not replying to this ticket sooner. 

Hi Graeme,

Glad to hear you're still interested, sometimes closing a bug will elicit a response... :)

> I was keeping an eye on it,
> but I was holding off doing any more work on packaging moovida as moovida 2.0
> had been anounced and the linux port released to limited testing, and I wanted
> to see the feasibility of packaging that for fedora instead. Unfortunately due
> to licensing and fluendo's resistance to releasing pure tarballs, it looks like
> moovida 2.0 probably won't be making it into fedora anytime soon. 

Can you briefly outline the issues with Moovida 1.0?  Did they change the license?  Can we cherry-pick stuff from their SVN/Git repo or whatever they use even if they don't release proper tarballs?

> On top of
> this, moovida 1.0 is no longer formerly supported by fluendo, so getting futher
> updates or bugs fixed in moovida may be tricky.

If that's the case, perhaps we could consider moving moovida to RPM Fusion (assuming licensing would be OK for RPM Fusion)?  It seems like a lot of work to get 1.x into Fedora if it isn't going to be maintained upstream.

> I was also away for the last 3 weeks on holiday which is why I didn't reply
> straight away.
> 
> Anyway I have had a look over the spec files and the comments above and have
> fixed the outstanding problems raised. I have created new rpms for both
> moovida, and the good and bad plugins packages (see the other bugs for the
> other packages).
> 
> moovida.spec
> http://ggillies.fedorapeople.org/moovida.spec
> 
> moovida-1.0.9-3.fc13.src.rpm
> http://ggillies.fedorapeople.org/moovida-1.0.9-3.fc13.src.rpm
> 
> I'm still keen to get 1.0 into fedora, and I am re-opening this review in the
> hopes of taking up Hans de Goede's offer of review and sponsorship    

I guess there's no harm in getting into Fedora, however we may have to think about the long-term if we end up moving it to RPM Fusion later.

Aside: It was annoying that they changed the name from elisa for no good reason, creating churn (like the need for this re-review in the first place), now they are retooling again so soon?  What's fluendo's strategy here? (feel free to e-mail me offline since this is a bit off-topic for the review request)

(Once setting the status to NEW)

(In reply to comment #33)
> (In reply to comment #32)
> > Hi,
> > 
> > I apologise for not replying to this ticket sooner. 
> 
> Hi Graeme,
> 
> Glad to hear you're still interested, sometimes closing a bug will elicit a
> response... :)
> 
> > I was keeping an eye on it,
> > but I was holding off doing any more work on packaging moovida as moovida 2.0
> > had been anounced and the linux port released to limited testing, and I wanted
> > to see the feasibility of packaging that for fedora instead. Unfortunately due
> > to licensing and fluendo's resistance to releasing pure tarballs, it looks like
> > moovida 2.0 probably won't be making it into fedora anytime soon. 
> 
> Can you briefly outline the issues with Moovida 1.0?  Did they change the
> license?  Can we cherry-pick stuff from their SVN/Git repo or whatever they use
> even if they don't release proper tarballs?

Sorry Should have clarified. Moovida 1.0 is the same license and still has proper tarballs, nothing has changed, and thus there is nothing wrong with putting moovida 1.0 into Fedora.

> 
> > On top of
> > this, moovida 1.0 is no longer formerly supported by fluendo, so getting futher
> > updates or bugs fixed in moovida may be tricky.
> 
> If that's the case, perhaps we could consider moving moovida to RPM Fusion
> (assuming licensing would be OK for RPM Fusion)?  It seems like a lot of work
> to get 1.x into Fedora if it isn't going to be maintained upstream.

More than happy to move this into RPM Fusion if that's what people feel is the most appropriate place.

> 
> > I was also away for the last 3 weeks on holiday which is why I didn't reply
> > straight away.
> > 
> > Anyway I have had a look over the spec files and the comments above and have
> > fixed the outstanding problems raised. I have created new rpms for both
> > moovida, and the good and bad plugins packages (see the other bugs for the
> > other packages).
> > 
> > moovida.spec
> > http://ggillies.fedorapeople.org/moovida.spec
> > 
> > moovida-1.0.9-3.fc13.src.rpm
> > http://ggillies.fedorapeople.org/moovida-1.0.9-3.fc13.src.rpm
> > 
> > I'm still keen to get 1.0 into fedora, and I am re-opening this review in the
> > hopes of taking up Hans de Goede's offer of review and sponsorship    
> 
> I guess there's no harm in getting into Fedora, however we may have to think
> about the long-term if we end up moving it to RPM Fusion later.
> 
> Aside: It was annoying that they changed the name from elisa for no good
> reason, creating churn (like the need for this re-review in the first place),
> now they are retooling again so soon?  What's fluendo's strategy here? (feel
> free to e-mail me offline since this is a bit off-topic for the review request)    

I don't profess to know things 100%, buy understanding is the name change and the complete rewrite for 2.0 is part of a strategy that was developed when Fluendo was acquired by another company (not 100% sure of this). Although www.fluendo.com maintains their linux focus, representatives at Moovida have come out and said that they are primarily focussing on the windows platform for Moovida 2.0, and at the moment there is no source code available for either windows or linux platforms (just packages for Ubuntu).

On top of this, the rather confusing post at [1] (see comments) implies that their work on Moovida 2.0 won't have source code made available and it will be under a more closed license, meaning there is little chance of it getting into Fedora.

There seems to be enough general interest in Moovida 1.0 to get it packaged for Fedora, and I am constantly on the lookout for a project looking to fork Moovida 1.0 and continue, but ultimately if the lack of a real solid upstream for fixes etc. is an issue we may have to abandon this package review or move it into RPM Fusion

[1] http://www.moovida.com/blog/2010/04/30/moovida-2-0-a-new-beginning/

Sorry for just jumping in, but IMHO, Moovida 1.0 should be put into Fedora, at least until a proper media center program finds its way into the repositories.

At the moment, the only media center program that I'm aware of is XBMC (MythTV is rather difficult to set up), and that's in RPM Fusion.

I wouldn't mind seeing moovida in F13, and even F14. Until then, there will be time to get a replacement (maybe Enna) in.

(In reply to comment #35)

> > Can you briefly outline the issues with Moovida 1.0?  Did they change the
> > license?  Can we cherry-pick stuff from their SVN/Git repo or whatever they use
> > even if they don't release proper tarballs?
> 
> Sorry Should have clarified. Moovida 1.0 is the same license and still has
> proper tarballs, nothing has changed, and thus there is nothing wrong with
> putting moovida 1.0 into Fedora.


Sorry, actually I misspoke (mistyped?) I meant what were the issues with Moovida 2.0.  Since then I checked out the blogposts:

http://www.moovida.com/blog/2010/05/03/moovida-2-0s-stance-on-open-source-and-licensing/

and:

http://www.moovida.com/blog/2010/04/30/moovida-2-0-a-new-beginning/

and it does seem that 2.0 will (at least at first) have some proprietary components and that they're moving away from Linux...  Can you clarify any further about their long-range plans?

> > 
> > > On top of
> > > this, moovida 1.0 is no longer formerly supported by fluendo, so getting futher
> > > updates or bugs fixed in moovida may be tricky.
> > 
> > If that's the case, perhaps we could consider moving moovida to RPM Fusion
> > (assuming licensing would be OK for RPM Fusion)?  It seems like a lot of work
> > to get 1.x into Fedora if it isn't going to be maintained upstream.
> 
> More than happy to move this into RPM Fusion if that's what people feel is the
> most appropriate place.

RPM Fusion would only be appropriate for Moovida 2.x, and even then it would require source code if it went in to the free RPM Fusion repository and would need to be at least distributable as a binary for the non-free RPM Fusion repo.  It isn't clear how that would work at the moment.  So I think that getting 1.x into Fedora seems the best course at the moment until it's clear how 2.x could be distributed.

> > Aside: It was annoying that they changed the name from elisa for no good
> > reason, creating churn (like the need for this re-review in the first place),
> > now they are retooling again so soon?  What's fluendo's strategy here? (feel
> > free to e-mail me offline since this is a bit off-topic for the review request)    
> 
> I don't profess to know things 100%, buy understanding is the name change and
> the complete rewrite for 2.0 is part of a strategy that was developed when
> Fluendo was acquired by another company (not 100% sure of this). Although
> www.fluendo.com maintains their linux focus, representatives at Moovida have
> come out and said that they are primarily focussing on the windows platform for
> Moovida 2.0, and at the moment there is no source code available for either
> windows or linux platforms (just packages for Ubuntu).
> 
> On top of this, the rather confusing post at [1] (see comments) implies that
> their work on Moovida 2.0 won't have source code made available and it will be
> under a more closed license, meaning there is little chance of it getting into
> Fedora.
> 
> There seems to be enough general interest in Moovida 1.0 to get it packaged for
> Fedora, and I am constantly on the lookout for a project looking to fork
> Moovida 1.0 and continue, but ultimately if the lack of a real solid upstream
> for fixes etc. is an issue we may have to abandon this package review or move
> it into RPM Fusion
> 
> [1] http://www.moovida.com/blog/2010/04/30/moovida-2-0-a-new-beginning/    

Yep, I think go ahead with getting 1.x into Fedora.

Hi,

Sorry for the slow response I've been kept very busy by my dayjob and other
things, also I'm going on a short vacation tomorrow, returing Tue Aug 10th, so
my next reply will be a bit slow too.

(In reply to comment #37)
> 
> Yep, I think go ahead with getting 1.x into Fedora.    

I agree 2.x does not seem to be heading in a direction which results in a useful home theater / multimedia center UI for Linux in anyway.

As I offered in the -bad and -good plugins reviews I'll review this and when that is done sponsor you. I hope to finish reviewing atleast the base package today before my short vacation.

Full review:

Good:
- rpmlint checks return:
moovida.noarch: W: manual-page-warning /usr/share/man/man1/moovida.1.gz 165: warning: numeric expression expected (got `U')
moovida.noarch: W: no-manual-page-for-binary elisa
moovida-base.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/elisa/core/launcher.py 0644L /usr/bin/python
moovida-base.noarch: E: non-executable-script /usr/lib/python2.6/site-packages/elisa/core/tests/test_launcher.py 0644L /usr/bin/python
3 packages and 0 specfiles checked; 2 errors, 2 warnings.

You could fix the 1st one by adding a symlink to the manpage for elisa and
you could fix the last 2 by making these files executable (or removing the shebang), but I consider neither of these 3 to be blockers.
- package meets naming guidelines
- package meets packaging guidelines
- license (GPLv3) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- .desktop file installed for GUI parts

Approved!

New Package SCM Request
=======================
Package Name: moovida
Short Description: Moovida is much more than a simple media player... it is a cutting edge media center bringing the best of the internet to your TV screen.
Owners: ggillies
Branches: f13 f14
InitialCC:

Git done (by process-git-requests).

Yay its finally in F-15 rawhide! I see its even built for F-14. Any chance we can have it submitted? Even more importantly any chance of getting the new and very shiny 2.0.1.1 release?

(In reply to comment #42)
> Yay its finally in F-15 rawhide! I see its even built for F-14. Any chance we
> can have it submitted? Even more importantly any chance of getting the new and
> very shiny 2.0.1.1 release?

yah we already have the packages :
http://koji.fedoraproject.org/koji/packageinfo?packageID=10916

yah I all prefer latest versions !  

Thanks,

moovida-plugins-bad-1.0.9-3.fc14,moovida-plugins-good-1.0.9-3.fc14,moovida-1.0.9-3.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/moovida-plugins-bad-1.0.9-3.fc14,moovida-plugins-good-1.0.9-3.fc14,moovida-1.0.9-3.fc14

moovida-plugins-bad-1.0.9-3.fc13,moovida-plugins-good-1.0.9-3.fc13,moovida-1.0.9-3.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/moovida-plugins-bad-1.0.9-3.fc13,moovida-plugins-good-1.0.9-3.fc13,moovida-1.0.9-3.fc13

moovida-plugins-bad-1.0.9-3.fc14, moovida-plugins-good-1.0.9-3.fc14, moovida-1.0.9-3.fc14 has been pushed to the Fedora 14 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 moovida-plugins-bad moovida-plugins-good moovida'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/moovida-plugins-bad-1.0.9-3.fc14,moovida-plugins-good-1.0.9-3.fc14,moovida-1.0.9-3.fc14

it's better, yum install, instead yum update , no ?. 
3 questions .
1- many python Traceback on Fedora 13 , seems , that is for python 2.7 ? 
2- it is possible put this moovida in multemedia players , with busybox ? and built it for mipsel archs ? 
3 - why we have 3 different packages could be just one src.rpm to generate the 4 rpms ? 

Thanks,

moovida-plugins-bad-1.0.9-3.fc14, moovida-plugins-good-1.0.9-3.fc14, moovida-1.0.9-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

moovida-plugins-bad-1.0.9-3.fc13, moovida-plugins-good-1.0.9-3.fc13, moovida-1.0.9-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.