Plus4emu now shipping ROMs in the sources
by Andrea Musuruane
Hi all,
I've noticed that the latest version of plus4emu now ships
copyrighted ROMs in the sources. These ROMs are not installed and the
only place where the user can put them is, as usual, a hidden
directory in his homedir.
I think that we should move plus4emu from free to nonfree because of
this change. But other options can be made too. For example, I could
ask upstream to remove the ROMs from source and wait to package the
next release.
I'd like to hear what you think about.
Bye,
Andrea.
15 years, 4 months
[Bug 83] New: Review request: barry - BlackBerry(tm) Desktop for Linux
by RPM Fusion Bugzilla
http://bugzilla.rpmfusion.org/show_bug.cgi?id=83
Summary: Review request: barry - BlackBerry(tm) Desktop for Linux
Product: Package Reviews
Version: Current
Platform: All
URL: http://cid-
f723c571e9e6d51f.skydrive.live.com/browse.aspx/Public?vi
ew=details
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: quantumburnz(a)hotmail.com
CC: rpmfusion-package-review(a)rpmfusion.org
Blocks: 2
Estimated Hours: 0.0
URL to SPEC file & RPMs:
http://cid-f723c571e9e6d51f.skydrive.live.com/browse.aspx/Public?view=det...
Description: Barry is a desktop toolset for managing your BlackBerry(tm)
device. (BlackBerry is a registered trademark of Research in Motion Limited.)
I don't think this can be included in Fedora because RIM uses closed source
applications for their phones.
Output from rpmlint:
[Chris@localhost SPECS]$ rpmlint ../RPMS/i386/*
libbarry0.i386: W: devel-file-in-non-devel-package /usr/lib/libbarry.so
5 packages and 0 specfiles checked; 0 errors, 1 warnings.
I'm ignoring this warning because I believe the purpose of libbarry0 is to
create this shared library for the other applications.
This is my first RPM Fusion package as well as the first set of RPMs I've ever
built. Hence, I also need a sponsor. Thanks.
Chris
--
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.
15 years, 4 months
Did some bugzilla cleanups
by Thorsten Leemhuis
Hi!
Just fyi, I did some cleanups in bugzilla; if I did something wrong yell
and/or just reopen please.
Some things to note:
- There are a lot of packages awaiting review; see
https://bugzilla.rpmfusion.org/showdependencytree.cgi?id=2&hide_resolved=1
for a list. I suppose those packagers that have packages in the review
queue try to get review exchanges organized; maybe via the wiki somehow?
- matthias seems to be the default owner for infrastructure bugs; Xavier
is doing most infr things these days, so that IMHO should be changed;
who has permissions to do that
- while at it: a lot of packages that are listed in owners.list are not
in the package list in bugzilla; how to we get that working?
Cu
knurd
15 years, 4 months
Introduction
by Orion Poplawski
Hello. I'm a long time Fedora contributor and sponsor, and long time
livna user. I'm interested in seeing more rpmfusion packages available
on EL, and looking to help co-maintain those packages.
Account name: orion
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
15 years, 4 months
package review: Is it a must to use system libraries ?
by Agnes Jones
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
15 years, 5 months
[Bug 15] Review Request: bsnes - SNES emulator focused on accuracy
by RPM Fusion Bugzilla
http://bugzilla.rpmfusion.org/show_bug.cgi?id=15
--- Comment #44 from Julian Sikorski <belegdol(a)gmail.com> 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 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.
15 years, 5 months
[Bug 15] Review Request: bsnes - SNES emulator focused on accuracy
by RPM Fusion Bugzilla
http://bugzilla.rpmfusion.org/show_bug.cgi?id=15
--- Comment #43 from Julian Sikorski <belegdol(a)gmail.com> 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
> 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.
15 years, 5 months
[Bug 15] Review Request: bsnes - SNES emulator focused on accuracy
by RPM Fusion Bugzilla
http://bugzilla.rpmfusion.org/show_bug.cgi?id=15
--- Comment #42 from David Timms <dtimms(a)iinet.net.au> 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.
15 years, 5 months
"RPM Fusion is ready for F10 announcement" for fedora-announce-list
by Thorsten Leemhuis
Hi!
I prepared a "RPM Fusion free and nonfree repositories for Fedora 10
(Cambridge) now available" mail that I'll send to fedora-announce-list
later today. Feel free to review and improve it:
http://rpmfusion.org/tmp
You have about four our left before I send it out.
CU
knurd
P.S.: I really had hoped someone else would take care of this, but seems
it's one more thing that somehow got onto my (already quite long) todo
list :-/
15 years, 5 months
