date:20081217

http://bugzilla.rpmfusion.org/show_bug.cgi?id=151





--- Comment #24 from Orcan Ogetbil   2008-12-18 01:52:45 
---
OK, I finally got everything together.

BR: gcc-c++ is not required (you must remove it)
R: gcc-c++ is not required either (which you already removed)

We came to the point where we have to discuss about the license.
Section 5 describes the responsibilities of the distributor. And the last
sentence scares me. Let's talk this in the mailing list.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165





--- Comment #18 from Conrad Meyer   2008-12-18 01:01:35 ---
New Package CVS Request
===
Package Name: cmus
Short Description: Ncurses-Based Music Player
Owners: konradm
Branches: F-10 F-9
InitialCC:


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: x264 and ffmpeg updates coming to rawhide

On Thursday, 04 December 2008 at 21:31, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 04 December 2008 at 21:15, Dominik 'Rathann' Mierzejewski wrote:
> > On Thursday, 04 December 2008 at 14:17, Dominik 'Rathann' Mierzejewski 
> > wrote:
> > > On Wednesday, 03 December 2008 at 19:06, Dominik 'Rathann' Mierzejewski 
> > > wrote:
> > > > In the long-standing tradition of breaking stuff right after a new 
> > > > release,
> > > > I'm going to update x264 and ffmpeg in the devel branch.
> > > > 
> > > > x264 brings ABI and API changes (albeit minor). I haven't checked ffmpeg
> > > > yet, but there's certainly an ABI version bump in libavcodec and 
> > > > probably
> > > > some API changes as well.
> > > > 
> > > > Right now x264 is blocked on some ppc compilation issue which I'm 
> > > > currently
> > > > trying to fix with the help of one x264 developer. I'll keep you posted.
> > > 
> > > OK, x264 build succeeded. Could someone test it on ppc/ppc64?
> > 
> > ffmpeg build coming soon, too. It brings libavcodec ABI version bump and 
> > some
> > API changes.
> 
> Affected packages:
> 
> ffmpeg2theora

Still to do.

> kino

Rebuilds cleanly.

> qmmp-plugins-freeworld

Rebuilds cleanly.

> transcode

Fails on rawhide's libtool.

> mencoder (mplayer)

Still to do.

So, to sum up. Everything except ffmpeg2theora, transcode and mplayer is ready
(either rebuilds cleanly or fixes have been provided). I'll handle mplayer
and take a look at ffmpeg2theora later.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Re: apt and smart support for RPM Fusion and Livna

2008-12-17 Thread Kevin Kofler

Conrad Meyer wrote:
> apt-rpm doesn't work in current Fedora anyways.

To be more precise, command-line apt-rpm is completely broken in F10 and
higher, Synaptic already in F9.

So if somebody cares strongly about apt, they'll have to fix apt first!

Kevin Kofler

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165





--- Comment #17 from Kevin Kofler   2008-12-17 23:29:39 
---
> Probably we have some kind of misunderstanding Kevin. The makefile suppress 
> the
> output when calling many commands including the compiler. In this way neither
> the submitter nor the reviewer can see how the files are complied, linked and
> so on.

I understood this pretty well, still I think looking at what CFLAGS are being
passed in the specfile is usually sufficient. (Yes, there can be typos like
CFALGS, but normally you notice them when reading the specfile. :-) )

But anyway, it turns out getting the output was trivial:
> Actually I didn't have to patch the makefile at all. Just passed V=2.
so it's all set now.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: another linksys rt2870 device

2008-12-17 Thread Orcan Ogetbil

--- On Wed, 12/17/08, Jarod Wilson wrote:
> A buddy of mine just got a Linksys WUSB600N usb 802.11n
> stick, and it
> works w/the rt2870 driver, after its device id is added. I
> prepped
> everything for the rt2870-kmod, but found I don't have
> permission to
> check stuff in there... I guess I should request commit
> access there, or
> just post patches in bugzilla...
> 
> Orcan, seems you're the package owner, what's your
> pref?
> 
I am fine with having co-maintainers. However I don't think I have the 
permissions to give you permissions. One of our cvs folks can help with that.

-Orcan

Re: x264 and ffmpeg updates coming to rawhide

On Thursday, 04 December 2008 at 21:31, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 04 December 2008 at 21:15, Dominik 'Rathann' Mierzejewski wrote:
> > On Thursday, 04 December 2008 at 14:17, Dominik 'Rathann' Mierzejewski 
> > wrote:
> > > On Wednesday, 03 December 2008 at 19:06, Dominik 'Rathann' Mierzejewski 
> > > wrote:
> > > > In the long-standing tradition of breaking stuff right after a new 
> > > > release,
> > > > I'm going to update x264 and ffmpeg in the devel branch.
> > > > 
> > > > x264 brings ABI and API changes (albeit minor). I haven't checked ffmpeg
> > > > yet, but there's certainly an ABI version bump in libavcodec and 
> > > > probably
> > > > some API changes as well.
> > > > 
> > > > Right now x264 is blocked on some ppc compilation issue which I'm 
> > > > currently
> > > > trying to fix with the help of one x264 developer. I'll keep you posted.
> > > 
> > > OK, x264 build succeeded. Could someone test it on ppc/ppc64?
> > 
> > ffmpeg build coming soon, too. It brings libavcodec ABI version bump and 
> > some
> > API changes.
> 
> Affected packages:
> 
> ushare-freeworld

Rebuilds cleanly after libdlna is built.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Re: x264 and ffmpeg updates coming to rawhide

On Thursday, 04 December 2008 at 21:31, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 04 December 2008 at 21:15, Dominik 'Rathann' Mierzejewski wrote:
> > On Thursday, 04 December 2008 at 14:17, Dominik 'Rathann' Mierzejewski 
> > wrote:
> > > On Wednesday, 03 December 2008 at 19:06, Dominik 'Rathann' Mierzejewski 
> > > wrote:
> > > > In the long-standing tradition of breaking stuff right after a new 
> > > > release,
> > > > I'm going to update x264 and ffmpeg in the devel branch.
> > > > 
> > > > x264 brings ABI and API changes (albeit minor). I haven't checked ffmpeg
> > > > yet, but there's certainly an ABI version bump in libavcodec and 
> > > > probably
> > > > some API changes as well.
> > > > 
> > > > Right now x264 is blocked on some ppc compilation issue which I'm 
> > > > currently
> > > > trying to fix with the help of one x264 developer. I'll keep you posted.
> > > 
> > > OK, x264 build succeeded. Could someone test it on ppc/ppc64?
> > 
> > ffmpeg build coming soon, too. It brings libavcodec ABI version bump and 
> > some
> > API changes.
> 
> Affected packages:
> 
> vdr-dxr3

Rebuilds cleanly.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Re: x264 and ffmpeg updates coming to rawhide

On Thursday, 04 December 2008 at 21:31, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 04 December 2008 at 21:15, Dominik 'Rathann' Mierzejewski wrote:
> > On Thursday, 04 December 2008 at 14:17, Dominik 'Rathann' Mierzejewski 
> > wrote:
> > > On Wednesday, 03 December 2008 at 19:06, Dominik 'Rathann' Mierzejewski 
> > > wrote:
> > > > In the long-standing tradition of breaking stuff right after a new 
> > > > release,
> > > > I'm going to update x264 and ffmpeg in the devel branch.
> > > > 
> > > > x264 brings ABI and API changes (albeit minor). I haven't checked ffmpeg
> > > > yet, but there's certainly an ABI version bump in libavcodec and 
> > > > probably
> > > > some API changes as well.
> > > > 
> > > > Right now x264 is blocked on some ppc compilation issue which I'm 
> > > > currently
> > > > trying to fix with the help of one x264 developer. I'll keep you posted.
> > > 
> > > OK, x264 build succeeded. Could someone test it on ppc/ppc64?
> > 
> > ffmpeg build coming soon, too. It brings libavcodec ABI version bump and 
> > some
> > API changes.
> 
> Affected packages:
> 
> xine-lib-extras-freeworld

Builds against current ffmpeg with Rex's patches. I'm attaching a cleaned-up
version of Rex's patch that is a bit smaller because it avoids changing 
whitespace.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
diff -up xine-lib-1.1.15/src/combined/ffmpeg/ff_audio_decoder.c.ffmpeg_api 
xine-lib-1.1.15/src/combined/ffmpeg/ff_audio_decoder.c
--- xine-lib-1.1.15/src/combined/ffmpeg/ff_audio_decoder.c.ffmpeg_api   
2008-07-16 01:13:03.0 +0200
+++ xine-lib-1.1.15/src/combined/ffmpeg/ff_audio_decoder.c  2008-12-17 
22:54:15.0 +0100
@@ -269,7 +269,11 @@ static void ff_audio_decode_data (audio_
* bits/sample for some codecs (e.g. MS ADPCM) */
   this->audio_bits = 16;  
   
+#if LIBAVCODEC_VERSION_INT < ((52<<16)+(0<<8)+0)
   this->context->bits_per_sample = this->audio_bits;
+#else
+ this->context->bits_per_coded_sample = this->audio_bits;
+#endif
   this->context->sample_rate = this->audio_sample_rate;
   this->context->channels= this->audio_channels;
   this->context->codec_id= this->codec->id;
@@ -322,12 +326,21 @@ static void ff_audio_decode_data (audio_
 
 if (!this->output_open) {
   if (!this->audio_bits || !this->audio_sample_rate || 
!this->audio_channels) {
+#if LIBAVCODEC_VERSION_INT < ((52<<16)+(0<<8)+0)
 avcodec_decode_audio (this->context,
   (int16_t *)this->decode_buffer,
   &decode_buffer_size,
   &this->buf[0],
   this->size);
this->audio_bits = this->context->bits_per_sample;
+#else
+avcodec_decode_audio2 (this->context,
+  (int16_t *)this->decode_buffer,
+  &decode_buffer_size,
+  &this->buf[0],
+  this->size);
+this->audio_bits = this->context->bits_per_coded_sample;
+#endif
this->audio_sample_rate = this->context->sample_rate;
this->audio_channels = this->context->channels;
if (!this->audio_bits || !this->audio_sample_rate || 
!this->audio_channels)
diff -up xine-lib-1.1.15/src/combined/ffmpeg/ff_video_decoder.c.ffmpeg_api 
xine-lib-1.1.15/src/combined/ffmpeg/ff_video_decoder.c
--- xine-lib-1.1.15/src/combined/ffmpeg/ff_video_decoder.c.ffmpeg_api   
2008-07-16 23:01:56.0 +0200
+++ xine-lib-1.1.15/src/combined/ffmpeg/ff_video_decoder.c  2008-12-17 
22:54:56.0 +0100
@@ -939,7 +939,11 @@ static void ff_handle_header_buffer (ff_
   this->context->extradata_size);
   }
   
+#if LIBAVCODEC_VERSION_INT < ((52<<16)+(0<<8)+0)
   this->context->bits_per_sample = this->bih.biBitCount;
+#else
+  this->context->bits_per_coded_sample = this->bih.biBitCount; 
+#endif
 
 } else {

Re: ffmpeg pkgconfig deps broken, it would appear

On Wednesday, 17 December 2008 at 21:00, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 17 December 2008 at 20:50, Dominik 'Rathann' Mierzejewski wrote:
> > On Wednesday, 17 December 2008 at 18:36, Rex Dieter wrote:
> > > Trying to respin xine-lib:
> > > 
> > > checking for FFMPEG... configure: error: Package requirements 
> > > (libavcodec >= 51.20.0) were not met:
> > > 
> > > Package libraw1394 was not found in the pkg-config search path.
> > > Perhaps you should add the directory containing `libraw1394.pc'
> > > to the PKG_CONFIG_PATH environment variable
> > > Package 'libraw1394', required by 'libavcodec', not found
> > 
> > That shouldn't happen with current ffmpeg package (the one in CVS
> > and on buildsys, not the one in the repos).
> > It no longer has external libs in Requires.private.
> 
> Scratch that. Somehow the package on the buildsys is different then
> the one in my local mock repo. Investigating...

Looks like I picked the wrong snapshot for dropping the patch that fixed
the pkgconfig files and my local build still had that patch applied.
Fixed in 0.4.9-0.57.20081217.fc11.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

another linksys rt2870 device

2008-12-17 Thread Jarod Wilson

A buddy of mine just got a Linksys WUSB600N usb 802.11n stick, and it
works w/the rt2870 driver, after its device id is added. I prepped
everything for the rt2870-kmod, but found I don't have permission to
check stuff in there... I guess I should request commit access there, or
just post patches in bugzilla...

Orcan, seems you're the package owner, what's your pref?


-- 
Jarod Wilson
ja...@wilsonet.com

Re: Broken deps - RPM Fusion free Fedora development - 2008-12-15

2008-12-17 Thread Michael Schwendt

On Wed, 17 Dec 2008 07:42:18 +0100, Thorsten wrote:

>  libfaac.so.0
> >>> Got it, faac did not get picked to be multilib :)
> >> +1 points. :)
> >> 
> >> Mission objective now is to find out the culprit: faac on multilib
> >> blacklist?
> > 
> > Nope.
> > 
> >> Misconfigured pushscripts? (== couldn't load the i386 repo metadata
> >>  directly after pushing to it and while resolving for x86_64?)
> > 
> > Don't think so, as 
> > http://download1.rpmfusion.org/free/fedora/development//x86_64/os/freetype-freeworld-2.3.7-2.fc11.i386.rpm
> >  (pushed on 2008-Dec-10) got properly multilibed. I'll take a closer
> > look at the output during the next push and report back.
> 
> faac was multilibed properly now; not sure why it didn't happen during
> the last push.

That confirms my speculations made in yesterday's reply, that the
pushscript accesses repos in /srv/local_repo/... not /srv/rpmbuild/...

Re: ffmpeg pkgconfig deps broken, it would appear

On Wednesday, 17 December 2008 at 20:50, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 17 December 2008 at 18:36, Rex Dieter wrote:
> > Trying to respin xine-lib:
> > 
> > checking for FFMPEG... configure: error: Package requirements 
> > (libavcodec >= 51.20.0) were not met:
> > 
> > Package libraw1394 was not found in the pkg-config search path.
> > Perhaps you should add the directory containing `libraw1394.pc'
> > to the PKG_CONFIG_PATH environment variable
> > Package 'libraw1394', required by 'libavcodec', not found
> 
> That shouldn't happen with current ffmpeg package (the one in CVS
> and on buildsys, not the one in the repos).
> It no longer has external libs in Requires.private.

Scratch that. Somehow the package on the buildsys is different then
the one in my local mock repo. Investigating...

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

Re: ffmpeg pkgconfig deps broken, it would appear

On Wednesday, 17 December 2008 at 18:36, Rex Dieter wrote:
> Trying to respin xine-lib:
> 
> checking for FFMPEG... configure: error: Package requirements 
> (libavcodec >= 51.20.0) were not met:
> 
> Package libraw1394 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libraw1394.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libraw1394', required by 'libavcodec', not found

That shouldn't happen with current ffmpeg package (the one in CVS
and on buildsys, not the one in the repos).
It no longer has external libs in Requires.private.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[Bug 151] Review Request: systemc - Design and verification language for Hardware

http://bugzilla.rpmfusion.org/show_bug.cgi?id=151





--- Comment #23 from Chitlesh GOORAH   2008-12-17 
20:15:04 ---
Updated
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-3.fc10.src.rpm

Mock i386: http://chitlesh.fedorapeople.org/systemC/build.log


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
You are the assignee for the bug.

Re: xine-lib in need of ffmpeg love


Hans de Goede wrote:

Rex Dieter wrote:

yay.

make[3]: *** [xineplug_decode_ff_la-ff_video_decoder.lo] Error 1
make[3]: *** Waiting for unfinished jobs
ff_audio_decoder.c: In function 'ff_audio_decode_data':
ff_audio_decoder.c:272: error: 'AVCodecContext' has no member named 
'bits_per_sample'

...
ff_audio_decoder.c:330: error: 'AVCodecContext' has no member named 
'bits_per_sample'




bits_per_sample has been renamed to bits_per_coded_sample


thanks

Thanks for the pkgconfig solution, have you done a rebuild in plague, 
iow can I requeue gstreamer-ffmpeg (which is hitten by this too) ?


No, I just added
BR: dirac-devel libraw1394-devel libtheora-devel libvorbis-devel
to workaround it for now.

If I can get xine-lib working, I'll give a ffmpeg a whirl.

-- Rex

Re: xine-lib in need of ffmpeg love


Rex Dieter wrote:

yay.

make[3]: *** [xineplug_decode_ff_la-ff_video_decoder.lo] Error 1
make[3]: *** Waiting for unfinished jobs
ff_audio_decoder.c: In function 'ff_audio_decode_data':
ff_audio_decoder.c:272: error: 'AVCodecContext' has no member named 
'bits_per_sample'

...
ff_audio_decoder.c:330: error: 'AVCodecContext' has no member named 
'bits_per_sample'




bits_per_sample has been renamed to bits_per_coded_sample

Regards,

Hans

p.s.

Thanks for the pkgconfig solution, have you done a rebuild in plague, iow can I 
requeue gstreamer-ffmpeg (which is hitten by this too) ?

xine-lib in need of ffmpeg love


yay.

make[3]: *** [xineplug_decode_ff_la-ff_video_decoder.lo] Error 1
make[3]: *** Waiting for unfinished jobs
ff_audio_decoder.c: In function 'ff_audio_decode_data':
ff_audio_decoder.c:272: error: 'AVCodecContext' has no member named 
'bits_per_sample'

...
ff_audio_decoder.c:330: error: 'AVCodecContext' has no member named 
'bits_per_sample'


-- Rex

Re: ffmpeg pkgconfig deps broken, it would appear


Rex Dieter wrote:

Trying to respin xine-lib:

checking for FFMPEG... configure: error: Package requirements 
(libavcodec >= 51.20.0) were not met:


Package libraw1394 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libraw1394.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libraw1394', required by 'libavcodec', not found


probably fallout from
1.  rpm auto req/prov'ing pkgconfig deps (f11+)
2.  the reintroduction of Requires.private deps, see also:
https://bugzilla.redhat.com/show_bug.cgi?id=224148#c19
https://bugzilla.redhat.com/show_bug.cgi?id=426106#c6

Rebuilding ffmpeg against the newer/fixed pkgconfig make things happy again.

-- Rex

ffmpeg pkgconfig deps broken, it would appear


Trying to respin xine-lib:

checking for FFMPEG... configure: error: Package requirements 
(libavcodec >= 51.20.0) were not met:


Package libraw1394 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libraw1394.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libraw1394', required by 'libavcodec', not found

-- Rex

Re: x264 and ffmpeg updates coming to rawhide

2008-12-17 Thread Orcan Ogetbil

--- On Wed, 12/17/08, Hans de Goede wrote:
> Hmm,
> 
> Build fails on ppc? :
> http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/2089-gstreamer-ffmpeg-0.10.6-1.fc11/
> 
> It claims it cannot find ffmpeg any idea why that would be
> ?
> 

This is an arch-independent error. The same thing happened yesterday for 
xmms2-freeworld build. I believe that there's a problem with ffmpeg's .pc file. 
The stable branches don't have this issue. Only the devel branch does.

-oget

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165





--- Comment #16 from Andrea Musuruane   2008-12-17 16:34:28 
---
Can you return the favour and do a review? I have #476357 in Fedora ;)


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165


Andrea Musuruane  changed:

   What|Removed |Added

 Blocks|3   |4




--- Comment #15 from Andrea Musuruane   2008-12-17 16:18:22 
---
Here is the review:

 +:ok, =:needs attention, -:needs fixing, N:not applicable.

MUST Items:
[+] MUST: rpmlint must be run on every package.
Output is clean
[+] MUST: The package must be named according to the Package Naming Guidelines.
[+] MUST: The spec file name must match the base package %{name}
[+] MUST: The package must meet the Packaging Guidelines.
[=] MUST: The package must be licensed with a Fedora approved license and meet
the Licensing Guidelines.
No problem because this is RPM Fusion.
[+] MUST: The License field in the package spec file must match the actual
license.
[+] MUST: If (and only if) the source package includes the text of the
license(s) in its own file, then that file, containing the text of the
license(s) for the package must be included in %doc.
[+] MUST: The spec file must be written in American English.
[+] MUST: The spec file for the package MUST be legible.
[+] MUST: The sources used to build the package must match the upstream source,
as provided in the spec URL.
7a9895ecfc10cd16577c73051436962f  cmus-2.2.0.tar.bz2
[+] MUST: The package must successfully compile and build into binary rpms on
at least one supported architecture.
Tested on F9/i386
[+] MUST: If the package does not successfully compile, build or work on an
architecture, then those architectures should be listed in the spec in
ExcludeArch.
[+] MUST: All build dependencies must be listed in BuildRequires
[N] MUST: The spec file MUST handle locales properly. This is done by using the
%find_lang macro.
[N] MUST: Every binary RPM package which stores shared library files (not just
symlinks) in any of the dynamic linker's default paths, must call ldconfig in
%post and %postun.
[N] MUST: If the package is designed to be relocatable, the packager must state
this fact in the request for review
[+] MUST: A package must own all directories that it creates. If it does not
create a directory that it uses, then it should require a package which does
create that directory.
[+] MUST: A package must not contain any duplicate files in the %files listing.
[+] MUST: Permissions on files must be set properly. Executables should be set
with executable permissions, for example. Every %files section must include a
%defattr(...) line.
[+] MUST: Each package must have a %clean section, which contains rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).
[+] MUST: Each package must consistently use macros, as described in the macros
section of Packaging Guidelines.
[=] MUST: The package must contain code, or permissible content. This is
described in detail in the code vs. content section of Packaging Guidelines.
This is not a problem since we are in RPM Fusion.
[N] MUST: Large documentation files should go in a doc subpackage.
[+] MUST: If a package includes something as %doc, it must not affect the
runtime of the application.
[N] MUST: Header files must be in a -devel package.
[N] MUST: Static libraries must be in a -static package.
[N] MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'
(for directory ownership and usability).
[N] MUST: If a package contains library files with a suffix (e.g.
libfoo.so.1.1), then library files that end in .so (without suffix) must go in
a -devel package.
[N] MUST: In the vast majority of cases, devel packages must require the base
package using a fully versioned dependency: Requires: %{name} =
%{version}-%{release} 
[+] MUST: Packages must NOT contain any .la libtool archives, these should be
removed in the spec.
[N] MUST: Packages containing GUI applications must include a %{name}.desktop
file, and that file must be properly installed with desktop-file-install in the
%install section.
[+] MUST: Packages must not own files or directories already owned by other
packages.
[+] MUST: At the beginning of %install, each package MUST run rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).
[+] MUST: All filenames in rpm packages must be valid UTF-8.

SHOULD Items:
[N] SHOULD: If the source package does not include license text(s) as a
separate file from upstream, the packager SHOULD query upstream to include it.
[N] SHOULD: The description and summary sections in the package spec file
should contain translations for supported Non-English languages, if available.
[N] SHOULD: The reviewer should test that the package builds in mock.
[N] SHOULD: The package should compile and build into binary rpms on all
supported architectures.
[+] SHOULD: The reviewer should test that the package functions as described.
[+] SHOULD: If scriptlets are used, those scriptlets must be sane.
[N] SHOULD: Usually, subpackages other than devel should require the base
package using a fully versioned dep

Re: rpmfusion mockbuild service ?

2008-12-17 Thread Thorsten Leemhuis


On 16.12.2008 22:25, David Timms wrote:
As far as I'm aware, packagers don't have access to be able to request 
rebuild of a .src.rpm package in mock, aka fedora. Would it be difficult 
to setup/maintain ? 


You want to test-build srpms in the rpmfusion buildsys? That is not 
really supported in plague, as it either works from CVS tags or from 
srpms -- our plague server is configured to use CVS tags, hence it can#t 
build srpms.


CU
knurd

[Bug 19] Review request: blcr - Berkeley Lab Checkpoint/Restart for Linux

http://bugzilla.rpmfusion.org/show_bug.cgi?id=19





--- Comment #12 from Thorsten Leemhuis   2008-12-17 
15:04:41 ---
(In reply to comment #11)
> What is the standard way to setup srpm to produce this result?

That will be done automatically by the push scripts if you have a -devel and a
-libs subpackage 


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 13] Review request: rpmfusion-package-config-smart - RPM Fusion configuration files for the Smart package manager

http://bugzilla.rpmfusion.org/show_bug.cgi?id=13





--- Comment #13 from David Timms   2008-12-17 13:45:58 ---
(In reply to comment #12)
> Okay, I've added (nonfree) or (free) to the summary and fixed the
> %descriptions:
>   SRPM:
> http://downloads.diffingo.com/rpmfusion/rpmfusion-free-package-config-smart-10-2.src.rpm

I'm hoping to get some feedback from a regular smart user, if not I'll get a
chance to fully test the split packages soonish.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 19] Review request: blcr - Berkeley Lab Checkpoint/Restart for Linux

http://bugzilla.rpmfusion.org/show_bug.cgi?id=19





--- Comment #11 from Neal Becker   2008-12-17 13:25:29 ---
(In reply to comment #10)
> This package surely needs some work. To start with:
> 
> * mock build fails on my x86_64. This is because you are trying to build and
> include 32 bit libraries in a 64 bit package, which is not allowed. If one
> needs 32 bit libraries (s)he can install blcr-libs.i386 in addition to
> blcr_libs.x86_64 . So you should remove the "libdir32" bits from the SPEC 
> file.
> 
> * Leave a comment in the SPEC file for why you are using ExclusiveArch.
> 
> * Try to avoid mixed ${ } %{_ } notation
> 
> * BR: "perl" and "sed" are not required since they are in the minimum build
> environment.
> 
> * Please remove the static library bits from the SPEC file.
> 
> * rpmlint complains:
>blcr-devel.x86_64: W: no-documentation
>blcr-testsuite.x86_64: W: no-documentation
>blcr-testsuite.x86_64: E: script-without-shebang
> /usr/libexec/blcr-testsuite/shellinit
> For the first two, at least put the license file(s) in those packages.
> The last one is actually about an empty files. Well it is not empty but when
> you open it, it says "#empty". Do you think we should include that file?
> 
> * Patches should be explained and be submitted to upstream if they are not
> strictly Fedora specific.
> 
> * The file tests/CountingApp.class is binary and should be removed during 
> %prep
> 
> * The file README.devel is not and should be packaged.
> 
> * Buildroot should be one of these:
>%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
>%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>%{_tmppath}/%{name}-%{version}-%{release}-root
> 
> * Why do you have:
># Ensure we don't build for a i386
>%ifarch i386
>  set +x
>  echo
> "=="
>  echo "ERROR: Cannot build BLCR for a generic i386." >&2
>  echo "ERROR: Add \"--target `uname -p`\" (or similar) to the rpmbuild
> command line." >&2
>  echo
> "=="
>  exit 1
>%endif
> in the SPEC file? Just remove i386 from ExclusiveArch and you should be fine.
> 
> * Please use
>   %post libs -p /sbin/ldconfig
>   %postun libs -p /sbin/ldconfig
> Afaik, they'll work more efficient.
> 
> * We prefer %defattr(-,root,root,-)
> 
> * Each package must consistently use macros, as described in the macros 
> section
> of Fedora Packaging Guidelines . Avoid inconsistencies such as:
>%clean
>rm -rf ${RPM_BUILD_ROOT}
> 
>%install
>rm -rf $RPM_BUILD_ROOT
> 
> * Disttag is missing.
> 
> * The Fedora-specific compilation flag -fstack-protector is not passed to the
> compiler. For a list of flags that should be passed to the compiler, please do
> a
>rpm --eval %optflags
> 
> * Parallel make must be supported whenever possible. If it is not supported,
> this should be noted in the SPEC file as a comment.
> 
> * Shall we package the examples, tests directories?
> 

Thank you.  I am working with upstream on these.

The 32bit is the most challenge.  I think what we want is that we wind up with
seperate 32bit and 64bit libs packages, blcr-libs.x86_64 and blcr-libs.i386. 
Consistent with other multi-arch packages, we want 32bit libs available on
64bit arch, but not installed by default.

What is the standard way to setup srpm to produce this result?


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

make mockbuild does not work

2008-12-17 Thread Julian Sikorski

Hi,

it seems that makefile.common wasn't updated to reflect the latest mock
changes:
$ LANG=C make mockbuild
rpmbuild --define "_sourcedir
/home/jsikorski/cvs/rpmfusion/nonfree/bsnes/F-10" --define "_builddir
/home/jsikorski/cvs/rpmfusion/nonfree/bsnes/F-10" --define "_srcrpmdir
/home/jsikorski/cvs/rpmfusion/nonfree/bsnes/F-10" --define "_rpmdir
/home/jsikorski/cvs/rpmfusion/nonfree/bsnes/F-10" --define "dist .fc10"
--define "fedora 10" --define "dist .fc10" --define "fedora 10" --nodeps
-bs bsnes.spec
Wrote:
/home/jsikorski/cvs/rpmfusion/nonfree/bsnes/F-10/bsnes-0.038-1.fc10.src.rpm
mock  -r fedora-10-x86_64.cfg
--resultdir=/home/jsikorski/cvs/rpmfusion/nonfree/bsnes/F-10/bsnes-0_038-1_fc10
/home/jsikorski/cvs/rpmfusion/nonfree/bsnes/F-10/bsnes-0.038-1.fc10.src.rpm
ERROR: Could not find required config file:
/etc/mock/fedora-10-x86_64.cfg.cfg
make: *** [mockbuild] Error 1

I have attached a simple patch which brings it up-to-date (with
mock-0.9.13, the one present in Fedora 10).

Regards,
Julian
? cvs-make-mockbuild.patch
Index: Makefile.common
===
RCS file: /cvs/nonfree/common/Makefile.common,v
retrieving revision 1.11
diff -u -r1.11 Makefile.common
--- Makefile.common	13 Oct 2008 12:44:47 -	1.11
+++ Makefile.common	17 Dec 2008 12:09:33 -
@@ -44,22 +44,22 @@
 MOCKDIR ?= $(WORKDIR)
 ifeq ($(DISTVAR),epel)
 DISTVAR := rhel
-MOCKCFG ?= fedora-$(DISTVAL)-$(BUILDARCH)-epel.cfg
+MOCKCFG ?= fedora-$(DISTVAL)-$(BUILDARCH)-epel
 else
-MOCKCFG ?= fedora-$(DISTVAL)-$(BUILDARCH).cfg
+MOCKCFG ?= fedora-$(DISTVAL)-$(BUILDARCH)
 ## 4, 5, 6 need -core
 ifeq ($(DISTVAL),4)
-MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core.cfg
+MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core
 endif
 ifeq ($(DISTVAL),5)
-MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core.cfg
+MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core
 endif
 ifeq ($(DISTVAL),6)
-MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core.cfg
+MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core
 endif
-## Devel builds use -devel mock config
+## Devel builds use -rawhide mock config
 ifeq ($(BRANCH),devel)
-MOCKCFG = fedora-devel-$(BUILDARCH).cfg
+MOCKCFG = fedora-rawhide-$(BUILDARCH)
 endif
 endif

Re: x264 and ffmpeg updates coming to rawhide

Hans de Goede wrote:

Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 04 December 2008 at 21:31, Dominik 'Rathann' Mierzejewski
wrote:
On Thursday, 04 December 2008 at 21:15, Dominik 'Rathann'
Mierzejewski wrote:
On Thursday, 04 December 2008 at 14:17, Dominik 'Rathann'
Mierzejewski wrote:
On Wednesday, 03 December 2008 at 19:06, Dominik 'Rathann'
Mierzejewski wrote:
In the long-standing tradition of breaking stuff right after a new
release,

I'm going to update x264 and ffmpeg in the devel branch.

x264 brings ABI and API changes (albeit minor). I haven't checked
ffmpeg
yet, but there's certainly an ABI version bump in libavcodec and
probably

some API changes as well.

Right now x264 is blocked on some ppc compilation issue which I'm
currently
trying to fix with the help of one x264 developer. I'll keep you
posted.

OK, x264 build succeeded. Could someone test it on ppc/ppc64?
ffmpeg build coming soon, too. It brings libavcodec ABI version bump
and some

API changes.

Affected packages:

[...]

gstreamer-ffmpeg

This needs the attached patch to build. I'm not sure what to do with the
removed CODEC_FLAG_TRELLIS_QUANT option, but see this mail:
http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2008-December/018101.html

Thanks!,

Actually upstream has recently done a new release and moved to a newer
ffmpeg snapshot with the new API. I've checked there changes against
your patch and you and them have fixed everything identical.

I've just fired of a build of the new gstreamer-ffmpeg-0.10.6 for devel,
which should build fine against the new ffmpeg (verified locally).
Actually, 0.10.6 won't build against the ffmpeg in F-10, but thats not
an issue 0.10.6 seems to contain some interesting changes, so its better
left to rawhide only anyways.

Hmm,

Build fails on ppc? :
http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/2089-gstreamer-ffmpeg-0.10.6-1.fc11/

It claims it cannot find ffmpeg any idea why that would be ?

Regards,

Hans

Regards,

Hans

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165


Andrea Musuruane  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165


Andrea Musuruane  changed:

   What|Removed |Added

 AssignedTo|rpmfusion-package-  |musur...@gmail.com
   |rev...@rpmfusion.org|
 Status|ASSIGNED|NEW




-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165


Andrea Musuruane  changed:

   What|Removed |Added

 CC||musur...@gmail.com
 Blocks|2   |3
 Status|NEW |ASSIGNED




-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
You are the assignee for the bug.

Re: gstreamer-pitfdll

2008-12-17 Thread Rahul Sundaram


Thorsten Leemhuis wrote:

> gstreamer-pitfdll
[...]
I think that this one is mostly obsolete. The gstreamer-ffmpeg package
supports most (all?) of the formats this one supported. I wouldn't
import it.
"""
I haven't found Real Player video (audio works fine) working with ffmpeg 
plugin. I think it still needs the DLL files.


Rahul

gstreamer-pitfdll (was: Re: x264 and ffmpeg updates coming to rawhide)

2008-12-17 Thread Thorsten Leemhuis


On 17.12.2008 11:52, Hans de Goede wrote:
[...] 
I've just fired of a build of the new gstreamer-ffmpeg-0.10.6 for devel, which 
should build fine against the new ffmpeg (verified locally). Actually, 0.10.6 
won't build against the ffmpeg in F-10, but thats not an issue 0.10.6 seems to 
contain some interesting changes, so its better left to rawhide only anyways.


While talking about gstreamer* just for everybody's information a quote 
from a recent wishlist addition ( 
http://rpmfusion.org/Wishlist?action=diff&rev1=116&rev2=117 ):


"""
+   Request: gstreamer-pitfdll
+   Summary: GStreamer plugin that allows the use of binary files, such 
as Quicktime QTX or Directshow/DMO DLL files.

+   URL: http://sourceforge.net/projects/pitfdll/
+   Why not in Fedora: Probably because of codecs
"""

Maybe someone wants to take care of that *or* add reasons to the wiki 
why it doesn't make sense to ship. I suppose the latter is needed:


http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/001702.html

"""
> gstreamer-pitfdll
[...]
I think that this one is mostly obsolete. The gstreamer-ffmpeg package
supports most (all?) of the formats this one supported. I wouldn't
import it.
"""

CU
knurd

Re: x264 and ffmpeg updates coming to rawhide


Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 04 December 2008 at 21:31, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 04 December 2008 at 21:15, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 04 December 2008 at 14:17, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 03 December 2008 at 19:06, Dominik 'Rathann' Mierzejewski wrote:

In the long-standing tradition of breaking stuff right after a new release,
I'm going to update x264 and ffmpeg in the devel branch.

x264 brings ABI and API changes (albeit minor). I haven't checked ffmpeg
yet, but there's certainly an ABI version bump in libavcodec and probably
some API changes as well.

Right now x264 is blocked on some ppc compilation issue which I'm currently
trying to fix with the help of one x264 developer. I'll keep you posted.

OK, x264 build succeeded. Could someone test it on ppc/ppc64?

ffmpeg build coming soon, too. It brings libavcodec ABI version bump and some
API changes.

Affected packages:

[...]

gstreamer-ffmpeg


This needs the attached patch to build. I'm not sure what to do with the
removed CODEC_FLAG_TRELLIS_QUANT option, but see this mail:
http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2008-December/018101.html



Thanks!,

Actually upstream has recently done a new release and moved to a newer ffmpeg 
snapshot with the new API. I've checked there changes against your patch and 
you and them have fixed everything identical.


I've just fired of a build of the new gstreamer-ffmpeg-0.10.6 for devel, which 
should build fine against the new ffmpeg (verified locally). Actually, 0.10.6 
won't build against the ffmpeg in F-10, but thats not an issue 0.10.6 seems to 
contain some interesting changes, so its better left to rawhide only anyways.


Regards,

Hans

Re: x264 and ffmpeg updates coming to rawhide


Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 04 December 2008 at 21:31, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 04 December 2008 at 21:15, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 04 December 2008 at 14:17, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 03 December 2008 at 19:06, Dominik 'Rathann' Mierzejewski wrote:

In the long-standing tradition of breaking stuff right after a new release,
I'm going to update x264 and ffmpeg in the devel branch.

x264 brings ABI and API changes (albeit minor). I haven't checked ffmpeg
yet, but there's certainly an ABI version bump in libavcodec and probably
some API changes as well.

Right now x264 is blocked on some ppc compilation issue which I'm currently
trying to fix with the help of one x264 developer. I'll keep you posted.

OK, x264 build succeeded. Could someone test it on ppc/ppc64?

ffmpeg build coming soon, too. It brings libavcodec ABI version bump and some
API changes.

Affected packages:

[...]

for x264:

[...]

gstreamer-plugins-bad


This needs a small patch to build (attached). Hans?



Thanks, applied and build.

Regards,

Hans

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165





--- Comment #14 from Conrad Meyer   2008-12-17 11:44:05 ---
Actually I didn't have to patch the makefile at all. Just passed V=2.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165





--- Comment #13 from Andrea Musuruane   2008-12-17 11:35:00 
---
(In reply to comment #8)
> > * There is no compile output. Makefile must be patched to see it. This is a
> > blocking issue. A reviewer must see the output of what is happening when
> > building (for example, to see the CFLAGS).
> 
> I don't see how this is a blocker nor why it warrants patching the makefile.

Probably we have some kind of misunderstanding Kevin. The makefile suppress the
output when calling many commands including the compiler. In this way neither
the submitter nor the reviewer can see how the files are complied, linked and
so on.

Using %{optflags} is mandatory and with the unpatched upstream makefile there
is no way to check them:
https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165





--- Comment #12 from Conrad Meyer   2008-12-17 11:23:14 ---
http://konradm.fedorapeople.org/fedora/SPECS/cmus.spec
http://konradm.fedorapeople.org/fedora/SRPMS/cmus-2.2.0-3.fc9.src.rpm

Sorry it took so long.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 165] Review Request: cmus - Ncurses-Based Music Player

http://bugzilla.rpmfusion.org/show_bug.cgi?id=165





--- Comment #11 from Andrea Musuruane   2008-12-17 11:12:04 
---
(In reply to comment #9)
> Using %{name} and %{version} macros is not mandated. I use %{version} macros,
> but prefer not to use %{name} especially when "%{name}" is longer than "cmus"
> (what it evaluates to). 

You are right. I should have used the world should and I agree that it is a
matter of style.

> I will fix the quiet makefile issue and fix what you
> described w.r.t. the Patch0, but I don't think %{name} is needed.

OK. Waiting for the fixes.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
You are the assignee for the bug.

Re: apt and smart support for RPM Fusion and Livna

2008-12-17 Thread Conrad Meyer

On Wednesday 17 December 2008 01:43:40 am Thorsten Leemhuis wrote:
> Hi!
>
> Just FYI, seems some people would like to have apt and smart support for
> RPM Fusion and Livna; see this mail (and the replies to it):
> https://www.redhat.com/archives/fedora-list/2008-December/msg02807.html
>
> Smart support for RPM Fusion is in the works
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=13
>
> Support for apt isn't afaics. Does anybody want to work on this?
>
> BTW, I guess the livna developers will also be gladly accept patches
> that enhance the current livna-release rpm from http://rpm.livna.org/ to
> support support apt or smart (SRPM can be found here:
> http://rpm.livna.org/repo/8/SRPMS/livna-release-1-1.src.rpm); the old
> release rpms did support smart and apt iirc, but I they ignored the
> directory ownership problem.
>
> Cu
> knurd

apt-rpm doesn't work in current Fedora anyways.

-- 
Conrad Meyer

apt and smart support for RPM Fusion and Livna

2008-12-17 Thread Thorsten Leemhuis


Hi!

Just FYI, seems some people would like to have apt and smart support for 
RPM Fusion and Livna; see this mail (and the replies to it):

https://www.redhat.com/archives/fedora-list/2008-December/msg02807.html

Smart support for RPM Fusion is in the works
https://bugzilla.rpmfusion.org/show_bug.cgi?id=13

Support for apt isn't afaics. Does anybody want to work on this?

BTW, I guess the livna developers will also be gladly accept patches 
that enhance the current livna-release rpm from http://rpm.livna.org/ to 
support support apt or smart (SRPM can be found here: 
http://rpm.livna.org/repo/8/SRPMS/livna-release-1-1.src.rpm); the old 
release rpms did support smart and apt iirc, but I they ignored the 
directory ownership problem.


Cu
knurd

[Bug 165] Review Request: cmus - Ncurses-Based Music Player