Bug 554243 - (moovida) Review Request: moovida - Media Center
Review Request: moovida - Media Center
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
: Reopened
: 510965 530021 (view as bug list)
Depends On:
Blocks: 510965 moovida-plugins-good moovida-plugins-bad
  Show dependency treegraph
 
Reported: 2010-01-10 22:48 EST by Graeme Gillies
Modified: 2010-10-05 05:23 EDT (History)
18 users (show)

See Also:
Fixed In Version: moovida-plugins-bad-1.0.9-3.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-30 02:08:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Graeme Gillies 2010-01-10 22:48:03 EST
Hi,

I have made some packages for Moovida which is a rename of elisa media centre which is currently in Fedora. I have yet to be sponsored so I am looking for someone who can sponsor me as well as review this package.

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

moovida-1.0.9-2.fc12.src.rpm:
http://ggillies.fedorapeople.org/moovida-1.0.9-2.fc12.src.rpm

moovida-plugins-good.spec:
http://ggillies.fedorapeople.org/moovida-plugins-good.spec

moovida-plugins-good-1.0.9-2.fc12.src.rpm:
http://ggillies.fedorapeople.org/moovida-plugins-good-1.0.9-2.fc12.src.rpm

moovida-plugins-bad.spec:
http://ggillies.fedorapeople.org/moovida-plugins-bad.spec

moovida-plugins-bad-1.0.9-2.fc12.src.rpm:
http://ggillies.fedorapeople.org/moovida-plugins-bad-1.0.9-2.fc12.src.rpm

Thanks :)
Comment 1 Jason Tibbitts 2010-01-10 23:16:02 EST
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.
Comment 2 Alex Lancaster 2010-01-12 01:48:47 EST
*** Bug 530021 has been marked as a duplicate of this bug. ***
Comment 3 Alex Lancaster 2010-01-12 01:54:13 EST
(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).
Comment 4 Alex Lancaster 2010-01-12 01:56:11 EST
Graeme: don't forget you needed to add the FE-NEEDSPONSOR bug blocker. I did this for you just now.
Comment 5 Alex Lancaster 2010-01-12 01:58:27 EST
*** Bug 510965 has been marked as a duplicate of this bug. ***
Comment 6 Alex Lancaster 2010-03-04 18:28:20 EST
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.
Comment 7 Peter Robinson 2010-03-07 11:03:30 EST
I can review them if Matthias can't.
Comment 8 Alex Lancaster 2010-03-07 16:27:53 EST
(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).
Comment 9 Peter Robinson 2010-03-08 02:20:03 EST
(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.
Comment 10 Alex Lancaster 2010-03-08 02:36:01 EST
(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.
Comment 11 Mamoru TASAKA 2010-03-08 08:36:09 EST
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.
Comment 12 Alex Lancaster 2010-03-08 13:52:15 EST
(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.
Comment 13 Graeme Gillies 2010-03-08 17:29:33 EST
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?
Comment 14 Alex Lancaster 2010-03-08 22:58:55 EST
(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.
Comment 15 Alexander Boström 2010-03-21 06:13:21 EDT
(In reply to comment #13)

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

Yes.
Comment 16 Graeme Gillies 2010-03-24 23:55:59 EDT
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
Comment 17 Alex Lancaster 2010-03-25 01:07:35 EDT
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).
Comment 18 Alex Lancaster 2010-03-25 01:13:31 EDT
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).
Comment 19 Peter Robinson 2010-04-02 06:49:03 EDT
(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.
Comment 20 Alex G. 2010-04-05 03:41:43 EDT
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.
Comment 21 Alex Lancaster 2010-04-09 14:07:41 EDT
(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?
Comment 22 Peter Robinson 2010-05-07 03:10:09 EDT
> > 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?
Comment 23 Silvio Schneider 2010-05-07 03:48:15 EDT
it seems anyway that moovida is drifting away from a cool program to a program that look like any other media player :-(
Comment 24 Peter Robinson 2010-05-07 03:50:53 EDT
> 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.
Comment 25 Alex Lancaster 2010-05-30 15:05:25 EDT
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.
Comment 26 Peter Robinson 2010-05-31 12:01:28 EDT
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.
Comment 27 Sergio Monteiro Basto 2010-06-23 13:42:32 EDT
where are moovida packages for fedora 13  ? , since "elisa is obsoleted by moovida"
Comment 28 Alex Lancaster 2010-06-23 14:39:12 EDT
(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?
Comment 29 Alex Lancaster 2010-07-11 23:33:52 EDT
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.
Comment 30 Sergio Monteiro Basto 2010-07-12 12:41:17 EDT
(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 .
Comment 31 Alex Lancaster 2010-07-12 13:41:38 EDT
(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.
Comment 32 Graeme Gillies 2010-07-14 19:52:11 EDT
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
Comment 33 Alex Lancaster 2010-07-14 20:18:22 EDT
(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)
Comment 34 Mamoru TASAKA 2010-07-16 03:47:25 EDT
(Once setting the status to NEW)
Comment 35 Graeme Gillies 2010-07-18 18:39:16 EDT
(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/
Comment 36 Alex G. 2010-07-18 19:11:11 EDT
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.
Comment 37 Alex Lancaster 2010-07-18 20:30:29 EDT
(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.
Comment 38 Hans de Goede 2010-08-04 11:04:22 EDT
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.
Comment 39 Hans de Goede 2010-08-04 11:19:22 EDT
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!
Comment 40 Graeme Gillies 2010-09-13 20:14:26 EDT
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:
Comment 41 Kevin Fenzi 2010-09-14 00:37:24 EDT
Git done (by process-git-requests).
Comment 42 Peter Robinson 2010-09-21 16:03:15 EDT
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?
Comment 43 Sergio Monteiro Basto 2010-09-21 17:23:30 EDT
(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,
Comment 44 Fedora Update System 2010-09-21 21:36:10 EDT
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
Comment 45 Fedora Update System 2010-09-21 21:39:15 EDT
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
Comment 46 Fedora Update System 2010-09-22 14:42:54 EDT
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
Comment 47 Sergio Monteiro Basto 2010-09-22 17:36:32 EDT
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,
Comment 48 Fedora Update System 2010-09-30 02:08:13 EDT
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.
Comment 49 Fedora Update System 2010-10-05 05:23:24 EDT
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.

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