RPM Fusion (EL - free) Package Build Report 2008-12-01
Packages built and released for RPM Fusion (EL - free) testing/5: 2 NEW mjpegtools-1.9.0-0.6.rc3.el5 : Tools to manipulate MPEG data NEW transcode-1.0.7-1.el5 : Video stream processing tool Changes in RPM Fusion (EL - free) testing/5: mjpegtools-1.9.0-0.6.rc3.el5 * Sat Jul 26 2008 Hans de Goede <[EMAIL PROTECTED]> 1.9.0-0.6.rc3 - Release bump for rpmfusion - Sync with freshrpms (no changes) transcode-1.0.7-1.el5 - * Fri Nov 28 2008 Orion Poplawski <[EMAIL PROTECTED]> - 1.0.7-1 - upgrade to 1.0.7 - Rework patches to avoid autotools (because of older autotools on EL-5) - Drop ImageMagick patch and BR version - drop libdvdread patch
[Bug 187] Review Request: larabie-fonts - A Collection of High Quality TrueType Fonts
http://bugzilla.rpmfusion.org/show_bug.cgi?id=187
Orcan Ogetbil <[EMAIL PROTECTED]> changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment #2 from Orcan Ogetbil <[EMAIL PROTECTED]> 2008-12-01 01:43:56 ---
(In reply to comment #1)
> #001: please a notice / url nearby source0: where you have downloaded the
> fonts.
>
done
> #002: add timestamps to your install : -p
>
done
> #003: %dir %{_datadir}/fonts/larabie
> I'm not at ease that all the packages require this ownership.
>
Eliminated the meta-package. The fonts are installed now in
%{_datadir}/fonts/larabie-fonts-deco
%{_datadir}/fonts/larabie-fonts-straight
%{_datadir}/fonts/larabie-fonts-uncommon
No %{_datadir}/fonts/larabie directory at all.
> #004: Buildroot:
> it should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>
Actually, I used one of the Fedora-approved buildroot tags:
http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag
> #005: more verbose
> I wish to see more verbose on the extract and the restructuring of the
> source0:
> into subpackages such as deco,.. during the build
> I believe its in the debian scripts
>
I extracted the relevant parts of the Ubuntu build script and put them in the
SPEC.
> #006: tested under OOo word.
>
Thanks!
New files are:
SPEC: http://6mata.com:8014/review/larabie-fonts.spec
SRPM: http://6mata.com:8014/review/larabie-fonts-0-0.2.20011216.fc10.src.rpm
--
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: package review: Is it a must to use system libraries ?
Julian Sikorski wrote: I'm not an expert here by any means, so I'll just sum up what we know. David Timms checked what the differences are, and found out the following (quoting the bugzilla comment). The diffs are in https://bugzilla.rpmfusion.org/attachment.cgi?id=36 So the actual diffs are minimal: - change the bpp from 16 to 32 - set the output type to BRG15 However, my reading of it is these are used at build time of the library, like they provide a hard configuration, rather than allowing a user of the lib to call functions to configure the library. In fact if I remember, the library was probably not designed as such. - modify the actual video processing algorithm Actually the colortable[ ] ?macro? is a call back into bsnes code itself, ie code that isn't available to the library. snes_ntsc.h:/* custom bsnes routine -- hooks into bsnes colortable */ snes_ntsc.h:rgb_out = colortable[rgb_out];\ snes_ntsc.h:rgb_out = colortable[rgb_out];\ snes_ntsc.h:rgb_out = colortable[rgb_out];\ Best regards, David Timms.
Re: package review: Is it a must to use system libraries ?
Julian Sikorski wrote: David Juran pisze: On Sun, 2008-11-30 at 20:15 +0100, Julian Sikorski wrote: I've been working on review of bsnes [1]. One of the issues raised before I began was the upstream source includes some libraries, some of which are already packaged and included in either fedora or rpmfusion. The fedora packaging guidelines are quite clear on this point, https://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries IMHO, this is a very good principle and should apply to rpmfusion as well. Is the fact that bsnes uses patched snes_ntsc, and that the said patch is not necessarily compatible with other apps using the lib a good enough reason? Without knowing any details of the particulars, it seems we really are talking about a fork here. So what the question boils down to, are the patches to snes_ntsc really incompatible or can they be pushed upstream? And if they can't be pushed upstream, is the fork well-maintained and of quality enough to merit it to be included in rpmfusion? /David I'm not an expert here by any means, so I'll just sum up what we know. David Timms checked what the differences are, and found out the following (quoting the bugzilla comment). So the actual diffs are minimal: - change the bpp from 16 to 32 - set the output type to BRG15 - modify the actual video processing algorithm byuu, bsnes author, said the following [1]: Second, I don't think ZSNES uses BGR15 internal mode. So you probably won't be able to use the system snes_ntsc library. I also highly doubt the ”fork” will be maintained anywhere else apart from inside bsnes itself. Ok, that seems enough of a diversion from the standard snes_ntsc libraray to warrant an exception. Regards, Hans
Re: package review: Is it a must to use system libraries ?
David Juran pisze: > On Sun, 2008-11-30 at 20:15 +0100, Julian Sikorski wrote: > I've been working on review of bsnes [1]. One of the issues raised before I began was the upstream source includes some libraries, some of which are already packaged and included in either fedora or rpmfusion. > > The fedora packaging guidelines are quite clear on this point, > https://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries > IMHO, this is a very good principle and should apply to rpmfusion as well. > >> Is the fact that bsnes uses patched snes_ntsc, and that the said patch >> is not necessarily compatible with other apps using the lib a good >> enough reason? > > Without knowing any details of the particulars, it seems we really are > talking about a fork here. So what the question boils down to, are the > patches to snes_ntsc really incompatible or can they be pushed upstream? > And if they can't be pushed upstream, is the fork well-maintained and of > quality enough to merit it to be included in rpmfusion? > > /David > I'm not an expert here by any means, so I'll just sum up what we know. David Timms checked what the differences are, and found out the following (quoting the bugzilla comment). So the actual diffs are minimal: - change the bpp from 16 to 32 - set the output type to BRG15 - modify the actual video processing algorithm byuu, bsnes author, said the following [1]: Second, I don't think ZSNES uses BGR15 internal mode. So you probably won't be able to use the system snes_ntsc library. I also highly doubt the ”fork” will be maintained anywhere else apart from inside bsnes itself. Regards, Julian [1] http://board.zsnes.com/phpBB2/viewtopic.php?p=182235#182235
[Bug 163] Review request: gambatte - An accuracy-focused Game Boy / Game Boy Color emulator
http://bugzilla.rpmfusion.org/show_bug.cgi?id=163
--- Comment #24 from Andrea Musuruane <[EMAIL PROTECTED]> 2008-11-30 21:52:42
---
(In reply to comment #23)
> * For instance, if you do a
>"s|conf.CheckLib('z', autoadd=1) and||"
> on your patch you will get rid of one of them. For the other one, do something
> similar (find the unnecessary linking and get rid of it).
If I do that, it won't build minizip support.
Regarding for the other library, I cannot find where it is linked with.
> * Here are my mock buildlogs for F-9 and F-10:
>http://6mata.com:8014/review/build.log.f9
>http://6mata.com:8014/review/build.log.f10
> (Search for the words 'alsa' and 'asound' in them, no hits, but "oss" will
> give
> hits) The alsa engine is definitely not built in my case, but only oss engine
> is. I can also tell this form the fact that there is an object file
> "ossengine.o" created in the gambatte_qt/src build directory but no object
> file
> like "alsaengine.o".
>
> Btw, I found a way to make the oss engine work. That one was my bad. But
> still,
> we need to have the alsa engine built for sure. Can you upload your buildlog?
Strange thing. I just compiled gambatte under my new x86_64 PC and I have the
same problem. Maybe this problem is arch dependant. The other PC where I tried
it is a i386.
--
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: package review: Is it a must to use system libraries ?
On Sun, 2008-11-30 at 20:15 +0100, Julian Sikorski wrote: > >> I've been working on review of bsnes [1]. One of the issues raised > >> before I began was the upstream source includes some libraries, some > >> of which are already packaged and included in either fedora or rpmfusion. The fedora packaging guidelines are quite clear on this point, https://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries IMHO, this is a very good principle and should apply to rpmfusion as well. > > > Is the fact that bsnes uses patched snes_ntsc, and that the said patch > is not necessarily compatible with other apps using the lib a good > enough reason? Without knowing any details of the particulars, it seems we really are talking about a fork here. So what the question boils down to, are the patches to snes_ntsc really incompatible or can they be pushed upstream? And if they can't be pushed upstream, is the fork well-maintained and of quality enough to merit it to be included in rpmfusion? /David signature.asc Description: This is a digitally signed message part
[Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151 --- Comment #10 from Orcan Ogetbil <[EMAIL PROTECTED]> 2008-11-30 21:05:18 --- Good, let's find a way to solve this debuginfo issue. I am working on it too. Everything seems good, except I have to warn you at one point. Never use the output of "ls" for parsing. "ls" gives a human-friendly output, but that's all. It is not intended to be used in bash scripts. You will get into trouble in many places if you do. For instance you'll get screwed up if there are files that have whitespaces (space,tab,newline etc) in their names. -- 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 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151 --- Comment #9 from Chitlesh GOORAH <[EMAIL PROTECTED]> 2008-11-30 20:49:04 --- > Note I'm willing to help with getting things to compile with 4x, although I > don't have time to do the main effort here, I can assist where you encounter > errors you cannot solve yourself. Hello Hans, I have updated it for gcc4. I would appreciate if you take some time to fix the warnings as they now spits a lot of warnings, with the examples. The debug-info has not yet been solved. Updated: Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-5.fc10.src.rpm -- 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: package review: Is it a must to use system libraries ?
Hans de Goede pisze: > David Timms wrote: >> Hi all, >> >> I've been working on review of bsnes [1]. One of the issues raised >> before I began was the upstream source includes some libraries, some >> of which are already packaged and included in either fedora or rpmfusion. >> >> Since I'm not an experienced packager or reviewer, if there are other >> reviewers who believe further work should be done on the "use system >> libraries" item, can you please speak up now ? >> > > Unless there are strong reasons not to use the system versions, all > libraries used should be system versions. If there are strong reasons > not to this should be documented case by case with comments in the spec > file. > > Regards, > > Hans > Is the fact that bsnes uses patched snes_ntsc, and that the said patch is not necessarily compatible with other apps using the lib a good enough reason? Julian
[Bug 163] Review request: gambatte - An accuracy-focused Game Boy / Game Boy Color emulator
http://bugzilla.rpmfusion.org/show_bug.cgi?id=163
--- Comment #23 from Orcan Ogetbil <[EMAIL PROTECTED]> 2008-11-30 18:12:50 ---
* For instance, if you do a
"s|conf.CheckLib('z', autoadd=1) and||"
on your patch you will get rid of one of them. For the other one, do something
similar (find the unnecessary linking and get rid of it).
* Here are my mock buildlogs for F-9 and F-10:
http://6mata.com:8014/review/build.log.f9
http://6mata.com:8014/review/build.log.f10
(Search for the words 'alsa' and 'asound' in them, no hits, but "oss" will give
hits) The alsa engine is definitely not built in my case, but only oss engine
is. I can also tell this form the fact that there is an object file
"ossengine.o" created in the gambatte_qt/src build directory but no object file
like "alsaengine.o".
Btw, I found a way to make the oss engine work. That one was my bad. But still,
we need to have the alsa engine built for sure. Can you upload your buildlog?
--
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 163] Review request: gambatte - An accuracy-focused Game Boy / Game Boy Color emulator
http://bugzilla.rpmfusion.org/show_bug.cgi?id=163 --- Comment #22 from Andrea Musuruane <[EMAIL PROTECTED]> 2008-11-30 16:18:00 --- (In reply to comment #19) > I found out that the rpmlint on the installed libgambatte package gives: >$ rpmlint libgambatte >libgambatte.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libgambatte.so.0 /lib64/libz.so.1 >libgambatte.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libgambatte.so.0 /lib64/libm.so.6 > > See if these can be fixed. > I've no experience in removing those warning. Help appreciated. -- 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 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151 Hans de Goede <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #8 from Hans de Goede <[EMAIL PROTECTED]> 2008-11-30 16:10:35 --- (In reply to comment #7) > > * I am worried about the Requires. You are building this with g++34. Don't > > you > > think we need to require g++34 for this package? If someone writes a code > > with > > this library he needs to compile the code with g++34, right? And what about > > other (possible) dependencies? > > > > true, Requires: compat-gcc-34-c++ was missing. But no other requires are > needed. > Ugh, ok so you are going to hate me (or atleast dislike), but compiling with compat-gcc34 is not an acceptable solution to compile issues with a newer gcc. This not only means that apps using systemc libs need to be compiled with gcc34, it also means they cannot use any other c++ libraries compiled with gcc4x, the proper solution is to fix the code to compile with 4x, even though that may be painful. compat-gcc34 only exist so that some libraries can be compiled with it, so that old (binary only / blob) applications compiled with gcc34 can stay functioning, iow compat-gcc34 is only there to compile compat-foo packages, not to compile new packages. Note I'm willing to help with getting things to compile with 4x, although I don't have time to do the main effort here, I can assist where you encounter errors you cannot solve yourself. -- 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: package review: Is it a must to use system libraries ?
David Timms wrote: Hi all, I've been working on review of bsnes [1]. One of the issues raised before I began was the upstream source includes some libraries, some of which are already packaged and included in either fedora or rpmfusion. Since I'm not an experienced packager or reviewer, if there are other reviewers who believe further work should be done on the "use system libraries" item, can you please speak up now ? Unless there are strong reasons not to use the system versions, all libraries used should be system versions. If there are strong reasons not to this should be documented case by case with comments in the spec file. Regards, Hans
Re: package review: Is it a must to use system libraries ?
2008/11/30 David Timms <[EMAIL PROTECTED]>: > I've been working on review of bsnes [1]. One of the issues raised before I > began was the upstream source includes some libraries, some of which are > already packaged and included in either fedora or rpmfusion. > > Since I'm not an experienced packager or reviewer, if there are other > reviewers who believe further work should be done on the "use system > libraries" item, can you please speak up now ? I do think the packager should at least trace (e.g. in comments) which system libraries are not used and why. Regards, Andrea.
[Bug 151] Review Request: systemc - Design and verification language for Hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=151
--- Comment #7 from Chitlesh GOORAH <[EMAIL PROTECTED]> 2008-11-30 15:49:51 ---
(In reply to comment #6)
> * Then I think we should follow the gcc scheme rather than creating a systemc
> directory directly inside /usr . gcc is installed in the path:
>/usr/lib/gcc/x86_64-redhat-linux/4.3.2/
Now: /usr/lib/systemc/2.2.0/
> I don't like putting %{buildroot} into the prefix. You can use a
>sed 's|\$(prefix)|\$(DESTDIR)/\$(prefix)|g'
> on the Makefile* and then use the DESTDIR trick you just removed. e.g.
>%configure --prefix=%{_libdir}/%{name}/%{version}
> (or something similar) and then
>%{__make} INSTALL="install -p" DESTDIR=%{buildroot} install
done
> * I also wonder why you don't use
>gmake install
done
> * There are more precompiled binary files. e.g. .ncb files
> * Do we need to package the .vcproj files? They are for use of MS' visualC.
*.ncb and *.vcproj removed
> * The files README and doc/README are different. You are overwriting one the
> way you package the doc files. (Maybe you should use docs instead of docs/* in
> %doc or just rename one of these README files)
done
> * This one is for making the SPEC file plainer: Check
> rpm --eval %{optflags}
> to see what flags need to be there for compilation. You are removing some of
> these flags from the configure script. Removing them is unnecessary.
Because the build fails with the following :
cc1plus: error: unrecognized command line option "-fstack-protector"
cc1plus: error: invalid parameter `ssp-buffer-size'
cc1plus: error: invalid parameter `ssp-buffer-size'
warning: #warning _FORTIFY_SOURCE supported only with GCC 4.1 and later
> ? The debuginfo package is empty?
I have no clue how to fix this.
> * I am worried about the Requires. You are building this with g++34. Don't you
> think we need to require g++34 for this package? If someone writes a code with
> this library he needs to compile the code with g++34, right? And what about
> other (possible) dependencies?
>
true, Requires: compat-gcc-34-c++ was missing. But no other requires are
needed.
Updated
Spec URL: http://chitlesh.fedorapeople.org/systemC/systemc.spec
SRPM URL: http://chitlesh.fedorapeople.org/systemC/systemc-2.2.0-4.fc10.src.rpm
--
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 15] Review Request: bsnes - SNES emulator focused on accuracy
http://bugzilla.rpmfusion.org/show_bug.cgi?id=15
--- Comment #44 from Julian Sikorski <[EMAIL PROTECTED]> 2008-11-30 15:48:47
---
(In reply to comment #43)
> (In reply to comment #42)
> > (In reply to comment #41)
> > > Spec URL: http://belegdol.republika.pl/rpmstuff/bsnes.spec
> > > SRPM URL:
> > > http://belegdol.republika.pl/rpmstuff/bsnes-0.037a-4.fc10.src.rpm
> > >
> > > Changes:
> > > - Fixed README.Fedora permissions
> > > - Added information concerning pulseaudio issues
> > Done as requested.
> >
> > Full review:
> >
> > [ OK] rpmlint is clean:
> > $ rpmlint /home/davidt/rpmbuild/SRPMS/bsnes-0.037a-4.fc9.src.rpm
> > /home/davidt/rpmbuild/RPMS/i386/bsnes-0.037a-4.fc9.i386.rpm
> > /home/davidt/rpmbuild/RPMS/i386/bsnes-debuginfo-0.037a-4.fc9.i386.rpm
> > 3 packages and 0 specfiles checked; 0 errors, 0 warnings.
> >
> > [ OK] name meets guidelines
> > [ OK] spec filename is correct
> > [ OK] meets package quidelines
> > [ OK] license is non-free => rpmfusion not fedora
> > [ OK] license field matches upstream redistributable, no mods.
> > [ OK] license text file is included
> > [ OK] spec file is legible, easy to understand
> >
> > [ x ] source URL is incorrect:
> > think it should be: ...%{name}_v0.%{vernumber}...
> > upstream calls it 037a but compresses source to v0.037a
>
> I'm not sure what you mean here, that's how the upstream tarball is called
> (I'm
> aware it uncompresses to a folder of slightly different name. Besides, if the
> Source0 URL would be incorrect, the package won't build, would it?
What an awful grammar. Should be: “Besides, if the Source0 URL were
incorrect, the package wouldn't build, would it?”
> > [ OK] upstream md5sum matches .src.rpm
> > $ md5sum bsnes_v037a.tar.bz2
> > 9fa2fbae8a09a747f9b4a44123bde0bb bsnes_v037a.tar.bz2
> > $ md5sum bsnes-0.037a-4.fc10.src/bsnes_v037a.tar.bz2
> > 9fa2fbae8a09a747f9b4a44123bde0bb
> > bsnes-0.037a-4.fc10.src/bsnes_v037a.tar.bz2
> >
> > [ OK] rpmbuild binary rpms built.
> >
> > [ x ] ExcludeArch not used in favour of ExclusiveArch: i386 x86_64
> > is there no possibility of this working on ppc etc. If so, I believe a
> > comment
> > above this field to briefly indicate why it's x86 only, could be
> > "application
> > uses x86 CPU machine code, so needs an x86 CPU" {if that is the reason}.
> > [Not sure if we want to make a bugzilla/block tracker bug - depends on the
> > reason why no ppc/other architectures]
>
> OK, I'll add an explanation then. The reason is that libco only supports these
> two architectures.
>
> > [ OK] BuiildRequires are specified.
> >
> > [ ? ] No localization is provided in the main source. I am not sure what
> > work
> > would be required to use the available individual locale.cfg files
> > automatically. It seems you would simply copy a single one of them into the
> > bin
> > dir as locale.cfg, and bsnes would only use that translation ?
>
> AFAIK, bsnes can use only one locale.cfg at a time, so packaging several at
> once seems impossible.
>
> > [ NA] no shared libraries are compiled or installed
> > [ OK] No relocatable (Prefix: is not used)
> > [ OK] owns directories it creates, disowns other dirs.
> > [ OK] no duplicates in the %files stanza
> > [ OK] permissions defattr included, other files have their perms fixed in
> > %prep
> > [ OK] %clean matches required content
> > [ OK] code versus content: this is a hardware emulator, no roms included.
> > [ OK] doc is small -> no separate -doc package
> > [ OK] no %doc files are not required at runtime
> > [ NA] no header files, no static libraries, no pkgconfig, no libaries,
> > no -devel, no libtool archives.
> > [ OK] gui app and has legit .desktop file, installed by
> > desktop-file-install,
> > and BRs: desktop-file-utils
> > [ OK] source filenames appear to be valid utf-8
> > [ OK] package functions as described.
> > [ ? ] an icon provided at /usr/share/icons/, yet the GTK+ icon cache update
> > scriptlet isn't used - why not ? why was it removed when it was previously
> > included ?
>
> It was removed because the icon was installed to datadir/pixmaps at the time
> upstream was not installing it at all. I pointed out to byuu that
> datadir/icons
> is a place for themed icons and bsnes one should go to datadir/pixmaps, but
> that was left without response. Also, packaging guidelines are only saying
> about subdirs of datadir/icons.
>
> > [ ? ] (In reply to comment #8)
> > > It seems that bsnes is using its own versions of system libraries. This
> > > should
> > > be avoided.
> > my opinion on use of included rather than system library for snes_ntsc
> > is
> > it would be a lot of effort, and the included version calculates the
> > values
> > differently, so we would need to decide if those changes could get
> > pushed
> > upstream. Also given byuu's opinion on the zlib that you worked on
> > already,
> > it would be unlikely to be included upstream.
> >
> > Julian: I think we a
[Bug 15] Review Request: bsnes - SNES emulator focused on accuracy
http://bugzilla.rpmfusion.org/show_bug.cgi?id=15
--- Comment #43 from Julian Sikorski <[EMAIL PROTECTED]> 2008-11-30 15:47:11
---
(In reply to comment #42)
> (In reply to comment #41)
> > Spec URL: http://belegdol.republika.pl/rpmstuff/bsnes.spec
> > SRPM URL: http://belegdol.republika.pl/rpmstuff/bsnes-0.037a-4.fc10.src.rpm
> >
> > Changes:
> > - Fixed README.Fedora permissions
> > - Added information concerning pulseaudio issues
> Done as requested.
>
> Full review:
>
> [ OK] rpmlint is clean:
> $ rpmlint /home/davidt/rpmbuild/SRPMS/bsnes-0.037a-4.fc9.src.rpm
> /home/davidt/rpmbuild/RPMS/i386/bsnes-0.037a-4.fc9.i386.rpm
> /home/davidt/rpmbuild/RPMS/i386/bsnes-debuginfo-0.037a-4.fc9.i386.rpm
> 3 packages and 0 specfiles checked; 0 errors, 0 warnings.
>
> [ OK] name meets guidelines
> [ OK] spec filename is correct
> [ OK] meets package quidelines
> [ OK] license is non-free => rpmfusion not fedora
> [ OK] license field matches upstream redistributable, no mods.
> [ OK] license text file is included
> [ OK] spec file is legible, easy to understand
>
> [ x ] source URL is incorrect:
> think it should be: ...%{name}_v0.%{vernumber}...
> upstream calls it 037a but compresses source to v0.037a
I'm not sure what you mean here, that's how the upstream tarball is called (I'm
aware it uncompresses to a folder of slightly different name. Besides, if the
Source0 URL would be incorrect, the package won't build, would it?
> [ OK] upstream md5sum matches .src.rpm
> $ md5sum bsnes_v037a.tar.bz2
> 9fa2fbae8a09a747f9b4a44123bde0bb bsnes_v037a.tar.bz2
> $ md5sum bsnes-0.037a-4.fc10.src/bsnes_v037a.tar.bz2
> 9fa2fbae8a09a747f9b4a44123bde0bb bsnes-0.037a-4.fc10.src/bsnes_v037a.tar.bz2
>
> [ OK] rpmbuild binary rpms built.
>
> [ x ] ExcludeArch not used in favour of ExclusiveArch: i386 x86_64
> is there no possibility of this working on ppc etc. If so, I believe a
> comment
> above this field to briefly indicate why it's x86 only, could be
> "application
> uses x86 CPU machine code, so needs an x86 CPU" {if that is the reason}.
> [Not sure if we want to make a bugzilla/block tracker bug - depends on the
> reason why no ppc/other architectures]
OK, I'll add an explanation then. The reason is that libco only supports these
two architectures.
> [ OK] BuiildRequires are specified.
>
> [ ? ] No localization is provided in the main source. I am not sure what work
> would be required to use the available individual locale.cfg files
> automatically. It seems you would simply copy a single one of them into the
> bin
> dir as locale.cfg, and bsnes would only use that translation ?
AFAIK, bsnes can use only one locale.cfg at a time, so packaging several at
once seems impossible.
> [ NA] no shared libraries are compiled or installed
> [ OK] No relocatable (Prefix: is not used)
> [ OK] owns directories it creates, disowns other dirs.
> [ OK] no duplicates in the %files stanza
> [ OK] permissions defattr included, other files have their perms fixed in
> %prep
> [ OK] %clean matches required content
> [ OK] code versus content: this is a hardware emulator, no roms included.
> [ OK] doc is small -> no separate -doc package
> [ OK] no %doc files are not required at runtime
> [ NA] no header files, no static libraries, no pkgconfig, no libaries,
> no -devel, no libtool archives.
> [ OK] gui app and has legit .desktop file, installed by desktop-file-install,
> and BRs: desktop-file-utils
> [ OK] source filenames appear to be valid utf-8
> [ OK] package functions as described.
> [ ? ] an icon provided at /usr/share/icons/, yet the GTK+ icon cache update
> scriptlet isn't used - why not ? why was it removed when it was previously
> included ?
It was removed because the icon was installed to datadir/pixmaps at the time
upstream was not installing it at all. I pointed out to byuu that datadir/icons
is a place for themed icons and bsnes one should go to datadir/pixmaps, but
that was left without response. Also, packaging guidelines are only saying
about subdirs of datadir/icons.
> [ ? ] (In reply to comment #8)
> > It seems that bsnes is using its own versions of system libraries. This
> > should
> > be avoided.
> my opinion on use of included rather than system library for snes_ntsc is
> it would be a lot of effort, and the included version calculates the
> values
> differently, so we would need to decide if those changes could get pushed
> upstream. Also given byuu's opinion on the zlib that you worked on
> already,
> it would be unlikely to be included upstream.
>
> Julian: I think we are really close here, just a few items above {x and ?} to
> either fix or provide reasoning for. Reading back over the review, it seems
> you
> have completed pretty well all requests reviewers have made, beside the "make
> it use all system libaries". If there are other reviewers who believe further
> work should be done on the "use system libraries" item, can you please speak
> up
>
package review: Is it a must to use system libraries ?
Hi all, I've been working on review of bsnes [1]. One of the issues raised before I began was the upstream source includes some libraries, some of which are already packaged and included in either fedora or rpmfusion. Since I'm not an experienced packager or reviewer, if there are other reviewers who believe further work should be done on the "use system libraries" item, can you please speak up now ? Cheers, DaveT [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=15
[Bug 15] Review Request: bsnes - SNES emulator focused on accuracy
http://bugzilla.rpmfusion.org/show_bug.cgi?id=15
--- Comment #42 from David Timms <[EMAIL PROTECTED]> 2008-11-30 15:19:42 ---
(In reply to comment #41)
> Spec URL: http://belegdol.republika.pl/rpmstuff/bsnes.spec
> SRPM URL: http://belegdol.republika.pl/rpmstuff/bsnes-0.037a-4.fc10.src.rpm
>
> Changes:
> - Fixed README.Fedora permissions
> - Added information concerning pulseaudio issues
Done as requested.
Full review:
[ OK] rpmlint is clean:
$ rpmlint /home/davidt/rpmbuild/SRPMS/bsnes-0.037a-4.fc9.src.rpm
/home/davidt/rpmbuild/RPMS/i386/bsnes-0.037a-4.fc9.i386.rpm
/home/davidt/rpmbuild/RPMS/i386/bsnes-debuginfo-0.037a-4.fc9.i386.rpm
3 packages and 0 specfiles checked; 0 errors, 0 warnings.
[ OK] name meets guidelines
[ OK] spec filename is correct
[ OK] meets package quidelines
[ OK] license is non-free => rpmfusion not fedora
[ OK] license field matches upstream redistributable, no mods.
[ OK] license text file is included
[ OK] spec file is legible, easy to understand
[ x ] source URL is incorrect:
think it should be: ...%{name}_v0.%{vernumber}...
upstream calls it 037a but compresses source to v0.037a
[ OK] upstream md5sum matches .src.rpm
$ md5sum bsnes_v037a.tar.bz2
9fa2fbae8a09a747f9b4a44123bde0bb bsnes_v037a.tar.bz2
$ md5sum bsnes-0.037a-4.fc10.src/bsnes_v037a.tar.bz2
9fa2fbae8a09a747f9b4a44123bde0bb bsnes-0.037a-4.fc10.src/bsnes_v037a.tar.bz2
[ OK] rpmbuild binary rpms built.
[ x ] ExcludeArch not used in favour of ExclusiveArch: i386 x86_64
is there no possibility of this working on ppc etc. If so, I believe a
comment
above this field to briefly indicate why it's x86 only, could be "application
uses x86 CPU machine code, so needs an x86 CPU" {if that is the reason}.
[Not sure if we want to make a bugzilla/block tracker bug - depends on the
reason why no ppc/other architectures]
[ OK] BuiildRequires are specified.
[ ? ] No localization is provided in the main source. I am not sure what work
would be required to use the available individual locale.cfg files
automatically. It seems you would simply copy a single one of them into the bin
dir as locale.cfg, and bsnes would only use that translation ?
[ NA] no shared libraries are compiled or installed
[ OK] No relocatable (Prefix: is not used)
[ OK] owns directories it creates, disowns other dirs.
[ OK] no duplicates in the %files stanza
[ OK] permissions defattr included, other files have their perms fixed in %prep
[ OK] %clean matches required content
[ OK] code versus content: this is a hardware emulator, no roms included.
[ OK] doc is small -> no separate -doc package
[ OK] no %doc files are not required at runtime
[ NA] no header files, no static libraries, no pkgconfig, no libaries,
no -devel, no libtool archives.
[ OK] gui app and has legit .desktop file, installed by desktop-file-install,
and BRs: desktop-file-utils
[ OK] source filenames appear to be valid utf-8
[ OK] package functions as described.
[ ? ] an icon provided at /usr/share/icons/, yet the GTK+ icon cache update
scriptlet isn't used - why not ? why was it removed when it was previously
included ?
[ ? ] (In reply to comment #8)
> It seems that bsnes is using its own versions of system libraries. This should
> be avoided.
my opinion on use of included rather than system library for snes_ntsc is
it would be a lot of effort, and the included version calculates the values
differently, so we would need to decide if those changes could get pushed
upstream. Also given byuu's opinion on the zlib that you worked on already,
it would be unlikely to be included upstream.
Julian: I think we are really close here, just a few items above {x and ?} to
either fix or provide reasoning for. Reading back over the review, it seems you
have completed pretty well all requests reviewers have made, beside the "make
it use all system libaries". If there are other reviewers who believe further
work should be done on the "use system libraries" item, can you please speak up
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.
[Bug 19] Review request: blcr - Berkeley Lab Checkpoint/Restart for Linux
http://bugzilla.rpmfusion.org/show_bug.cgi?id=19 --- Comment #7 from Neal Becker <[EMAIL PROTECTED]> 2008-11-30 14:16:22 --- Please try: http://nbecker.dyndns.org:8080/RPM/blcr-0.7.3-1.src.rpm http://nbecker.dyndns.org:8080/RPM/blcr.spec http://nbecker.dyndns.org:8080/RPM/blcr-kmod.spec http://nbecker.dyndns.org:8080/RPM/blcr-kmod-0.7.3-1.fc9.src.rpm Build is simply rpmbuild -ba. rpmlint ~/RPM/RPMS/x86_64/blcr*0.7.3* blcr-devel.x86_64: W: no-documentation blcr-kmod-debuginfo.x86_64: E: empty-debuginfo-package blcr-testsuite.x86_64: W: no-documentation blcr-testsuite.x86_64: E: script-without-shebang /usr/libexec/blcr-testsuite/shellinit -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 163] Review request: gambatte - An accuracy-focused Game Boy / Game Boy Color emulator
http://bugzilla.rpmfusion.org/show_bug.cgi?id=163 --- Comment #21 from Andrea Musuruane <[EMAIL PROTECTED]> 2008-11-30 13:52:04 --- (In reply to comment #18) > Thank you. We are almost there. > I downloaded some roms and checked the application itself. Apparently only the > null and oss engines [1] are getting built inside the qt application and in > Fedora 10, I was not able to get any sound out of it. You should make sure > that > at least alsa [2] engine is built too. > > [1] You can see the available sound engines in Settings->Sound. > [2] Ideally, if possible, you should also build the openal engine. Are you sure about this? In F9 and F10 alsa-lib-devel is a dependency of SDL-devel (which is among the BR). Therefore alsa engine should always be built. It is built in my case and it works (on F9). I must add that even OSS engine works too. Openal it is not supported AFAIK. -- 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.
Building a healthy RPM Fusion contributor community (was: Re: "RPM Fusion is ready for F10 announcement" for fedora-announce-list)
On 25.11.2008 13:37, Michael Schwendt wrote: Sorry, I wanted to find a bit more time to write a proper answer, which took me a while to find time for. On Tue, 25 Nov 2008 12:15:59 +0100, Thorsten Leemhuis wrote: What RPM Fusion really needs is IMHO not an announce writer. RPM Fusion for a healthy and hopefully growing project afaics need way more people that take care of all those "other things" How about a fat "Help needed" section on the main web page? Yeah, I had thought about that as well. But: Just a few lines that explain what kind of help is needed and how contributors may join and become productive. That and someone they can talk to that helps with the first steps -- e.g. a mentor. Leaving people working alone/sending them straight to the lists afaics only works if the one that wants to help really is pushing forward -- otherwise people offer to help but nobody tells them "hey, would you want to work on foo or bar". Or people try something and run into issues that are not getting solved -- like Chris with the planet/blog stuff, that now waits for thias to adjust the DNS :-/ The lack of information is not specific to RPM Fusion, it is a growing problem also for Fedora. +1 IRC-centric organisation and desolate Wiki pages. The latter IMHO is the bigger problem, and it's results in a higher hurdle to climb when trying to get involved. And that is not good for us in the long term. Livna showed that, as the entry-hurdle was way to high. Few people in key positions (approx. the same people who are praised in official announcements) with not enough time to handle everything. Hurdles for potential contributors. Yeah. - infrastructure (that is a whole big field with lots of sub-points I won't list here; Still you need to start somewhere if you're overwhelmed and seeking for help. What can potential contributors expect? What target OS? SSH access? What privileges? Any issues with trusting strangers? Sure. And as you said: start somewhere is the point. For infrastrucuture that would be up to our infrastructure leader -- Xavier. But lead is likely the wrong word, as we is the only real contributor that takes care of our infrastructure (with a bit help from me -- but as I said months ago on this list: I don't really want to spend my time on infrastructure things, so I try to keep it to a minimum). I don't want to think what might happen to RPM Fusion if Xavier gets hit my a bus tomorrow :-/ dep-checker script is one example) It's not rocket-science. [...] I know. I actually considered to work on it. But then I said to myself "I did so many things over the past few months for RPM Fusion; I won't touch that and just wait if or when somebody else steps up to do it; maybe then others get more involved" However, the "somebody" to do it is missing. Not just at RPM Fusion. Look at EPEL! EPEL is a really good example, as it's one of the reasons why I'm a bit worried about RPM Fusion in the long run. EPEL's self-organization was far from perfect when I ran the steering committee, but it afaics got a lot whole lot worse since I said "okay, I want to have some more free time to get RPM Fusion running; can somebody else please take care of EPEL" and handled the position over. Since then EPEL afaics is lingering and not really working towards a better and brighter future. Sure, EPEL grew a lot since I moved away from it -- but that's mainly due to more and more Fedora contributors starting to build their package for EL. But nobody really cares of EPEL as a whole afaics. The steering committee for example not even asked me "Why didn't you do the testing->stable move as usually" when I stopped doing them for the first time at the end August this year (it just happened due to me vacationing; it wasn't on purpose). I'm sure that things in EPEL land sooner or later will improve again, as it already has a big community -- sooner or later someone from that community will step up and work towards improving things. But the contributor community for RPM Fusion is a whole lot smaller; and most contributors seems to be focused on packaging (just like in EPEL). Nearly nobody seems to be interested in "keeping things together and running well" or "improving things/creating a healthy project that attracts new contributors and grows". The long time it took us to start for real proves that from my point of view. But maybe it's just me and I'm expecting to much... > [...] - make sure things are documented properly - keep the wiki in shape I think the German "Weniger is mehr!" translates to something like "Do no more than what is absolutely necessary". Focus on brief information that's easy to find instead of creating a maze like the Fedora Wiki. Strong +1 (that's also the reason why I put the first sentence on http://rpmfusion.org/Guidelines ) - make sure people get answers to their questions Make sure people ask in places where you can guar
[Bug 187] Review Request: larabie-fonts - A Collection of High Quality TrueType Fonts
http://bugzilla.rpmfusion.org/show_bug.cgi?id=187
Chitlesh GOORAH <[EMAIL PROTECTED]> changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Chitlesh GOORAH <[EMAIL PROTECTED]> 2008-11-30 12:58:45 ---
#001: please a notice / url nearby source0: where you have downloaded the
fonts.
#002: add timestamps to your install : -p
#003: %dir %{_datadir}/fonts/larabie
I'm not at ease that all the packages require this ownership.
#004: Buildroot:
it should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
#005: more verbose
I wish to see more verbose on the extract and the restructuring of the source0:
into subpackages such as deco,.. during the build
I believe its in the debian scripts
#006: tested under OOo word.
--
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 187] Review Request: larabie-fonts - A Collection of High Quality TrueType Fonts
http://bugzilla.rpmfusion.org/show_bug.cgi?id=187 Chitlesh GOORAH <[EMAIL PROTECTED]> changed: What|Removed |Added AssignedTo|rpmfusion-package- |[EMAIL PROTECTED] |[EMAIL PROTECTED]| 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 187] Review Request: larabie-fonts - A Collection of High Quality TrueType Fonts
http://bugzilla.rpmfusion.org/show_bug.cgi?id=187 Chitlesh GOORAH <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] 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: Did some bugzilla cleanups
On 29.11.2008 22:09, Michael Schwendt wrote: On Mon, 10 Nov 2008 21:47:00 +0100, Michael Schwendt wrote: So, everyone (but merely the infrastructure dudes), here's another status update WITH source code. *ping* Moving forward here would be appreciated. Xavier? At least, please fix the owners list, so the cron job will be quiet again: free-rawhide - Duplicate entry: gstreamer-ffmpeg free-rawhide - Duplicate entry: gstreamer-plugins-ugly Sorry, I thought I did that already. Seems I didn't. Fixed now. CU knurd
Re: cannot access cvs
Xavier Lamien wrote: On Sat, Nov 29, 2008 at 8:06 PM, Denis Leroy <[EMAIL PROTECTED]> wrote: On that topic, could somebody grant me cvs access ? I'd like to update open-vm-tools to the latest version... I just approve you in packagers group. your cvs access will be granted within an hours or so. Thanks Xavier,
[Bug 15] Review Request: bsnes - SNES emulator focused on accuracy
http://bugzilla.rpmfusion.org/show_bug.cgi?id=15 --- Comment #41 from Julian Sikorski <[EMAIL PROTECTED]> 2008-11-30 09:55:15 --- New release: Spec URL: http://belegdol.republika.pl/rpmstuff/bsnes.spec SRPM URL: http://belegdol.republika.pl/rpmstuff/bsnes-0.037a-4.fc10.src.rpm Changes: - Fixed README.Fedora permissions - Added information concerning pulseaudio issues -- 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.
