Bug 217197 (MyBashBurn)

the support of mp3 depends of the backends applications in fedora core this are
disable, like also the support for each one of the others formats.

Is this your first package to Fedora Extras? If yes then you need to add
FE-NEEDSPONSOR in textbox given below next to Bug 217197 blocks. Just had a look
at you SPEC and found they are not following
http://fedoraproject.org/wiki/Packaging/Guidelines
like macros,scriptlet rules then %files section included files twice
Just look at those guidelines and resubmit updated package

okay, it's good to hear from you, just now added myself on FE-NEEDSPONSOR.

I'm uploading the new SRPM and SPEC files, note that i decided change this
initial release to 1.0-1 for compatibility with the PackagingGuidelines and
NamingGuidelines.

In the spec file the line install -c -m666 this is needed to that every user can
to do read-write operations, in next realease i think to split it into of
program in some as: ~/.bashburnrc

CREDITS and HOWTO are duplicate as on %{doc} as %{buildroot}%{_datadir}/%{name}
In %{doc} for compatibility with the guidelines
In %{buildroot}%{_datadir}/%{name} why the program need read it there.

the new files uploaded:
Spec URL:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn.spec

SRPM URL:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn-1.0-1.src.rpm

Still packaging needs to be improved.

Got build error
install: cannot stat `etc/mybashburnrc.fedora': No such file or directory

Created attachment 142661 [details]
rpmlint error free SPEC file

Use this script bump release adding changelog as fixed SPEC file Version,added
build section and removed dot from summary.

Thx again, also i fix the location of man file in the SPEC file, added
/usr/lib/debug for build section and you was include in the global changelog file.

Please, check it out new updates:

Spec URL:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn.spec

SRPM URL:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn-1.0-1.src.rpm

Kindly remove my name from changelog its at all not necessary. If you got from
somebody modified SPEC then you write your own name in Chnagelog.

(In reply to comment #9)
> Kindly remove my name from changelog its at all not necessary. If you got from
> somebody modified SPEC then you write your own name in Chnagelog.

How you want, now, there are some more for check on review? 
when should the package be approved?
Greetings.

> %post
> ln -s %{_datadir}/%{name}/MyBashBurn.sh %{_bindir}/mybashburn > /dev/null 2>&1
> ln -s %{_datadir}/%{name}/MyBashBurn.sh %{_bindir}/bashburn > /dev/null 2>&1
> 
> %postun
> rm -f %{_bindir}/bashburn
> rm -f %{_bindir}/mybashburn

Why? This is extremely ugly. The files are not even %ghosted. They
are not tracked in the RPM database. Why not simply create these links
at build-time and include them in the package? That is the way it ought
to be.


> %files
> %defattr(-,root,root,0755)
> %{_datadir}/%{name}/*

Directory %{_datadir}/%{name} is not included. Correct would be:

%{_datadir}/%{name}/

Find one brief explanation in bug 165616 comment 8.


> %doc COPYING CREDITS ChangeLog FAQ FILES HOWTO INSTALL README TODO

Is the "INSTALL" file the typical NLS documentation which is irrelevant
to users of your RPM package? If so, don't include it. It is confusing.


> install -d %{buildroot}/usr/lib/debug

What's this?


Further, prefer "install" with option -p  (or "cp" with option -p)
to preserve timestamps wherever it is possible.

(In reply to comment #11)
> > %post
> > ln -s %{_datadir}/%{name}/MyBashBurn.sh %{_bindir}/mybashburn > /dev/null 2>&1
> > ln -s %{_datadir}/%{name}/MyBashBurn.sh %{_bindir}/bashburn > /dev/null 2>&1
> > 
> > %postun
> > rm -f %{_bindir}/bashburn
> > rm -f %{_bindir}/mybashburn
> 
> Why? This is extremely ugly. The files are not even %ghosted. They
> are not tracked in the RPM database. Why not simply create these links
> at build-time and include them in the package? That is the way it ought
> to be.

yeah, It sound kickass, better and more appropriate, I've added it in build-time.
 
> > %files
> > %defattr(-,root,root,0755)
> > %{_datadir}/%{name}/*
> 
> Directory %{_datadir}/%{name} is not included. Correct would be:
> 
> %{_datadir}/%{name}/
> 

Unknown that the contents would be recursive, now the directory trailing use is
fixed.
 
> > %doc COPYING CREDITS ChangeLog FAQ FILES HOWTO INSTALL README TODO
> 
> Is the "INSTALL" file the typical NLS documentation which is irrelevant
> to users of your RPM package? If so, don't include it. It is confusing.

Exactly. INSTALL file not is appropiate for users except for possible developers
of MyBashBurn only, it content "troubleshooting" section and installation's
instruction for tar file, neverthless, just i exclude the INSTALL file. Fixed.

> > install -d %{buildroot}/usr/lib/debug
> 
> What's this?

Really i don't know, i think that may be strictly needed for %build section, if
ommited it to get the next error:
find: /var/tmp/mybashburn-1.0-1-root-k0k/usr/lib/debug: No such file or directory

If create the directory %{buildroot}/usr/lib/debug issue fixed.
Please, remember that this package is a couple of ShellScripts written to make
cd burning in the console easier, just not is a program written in C/C++ or some
similar, for this i can't see why must be include %build section for this package?.
 
> Further, prefer "install" with option -p  (or "cp" with option -p)
> to preserve timestamps wherever it is possible.

Okay. I should adjusted the install -p for which components: files or
directories or both?

Please let me know what more i need to do, Thanks in advance for your response.

New package ready, the same URL, please check this time and report any problems.

I believe that all items was fixed.

Wilmer,
 Remember CC list is not a list that the person in CC list is surely going to
REVIEW your package. Also, there can be as many as persons be sited in CC list.
When your package is under review your package status will be changes accordingly.
Also, Being a newbie you still have to go a lot for improving a packaging.
  So i will wonder if someone will take this under review immediately. You need
to start reviewing other packages waiting for review.

Parag okeys.

(In reply to comment #15)
Sorry, I just disabled mail delivery CC for you by a time for know how the
bugzilla system worked, also i'm learning fine with others review process and
i'm not worried aobut the approved thing, i'm just learning to get it how to
work, any recommend is welcome. Sorry for my english again.

(In reply to comment #15)
Sorry, I just disabled mail delivery CC for you by a time for know how the
bugzilla system worked, also i'm learning fine with others review process and
i'm not worried aobut the approved thing, i'm just learning to get it how to
work, any recommend is welcome. Sorry for my english again.

(In reply to comment #18)
> (In reply to comment #15)
> Sorry, I just disabled mail delivery CC for you by a time for know how the
> bugzilla system worked,
aah OK.
> also i'm learning fine with others review process and
  Nice to hear from you. 
> i'm not worried aobut the approved thing, i'm just learning to get it how to
> work, any recommend is welcome. Sorry for my english again.
OK. So start posting reviews on others packages. See also some progressed BUGS
with FE-REVIEW status for how review progresses and how to post them.

You must increase release tag number each time you modifies SPEC file. I saw you
said you did some changes to SPEC in comment #12 but you kept package name as
mybashburn-1.0-1.src.rpm which SHOULD be mybashburn-1.0-2.src.rpm

if I understand it, that is something that Jorge(jtorres) me said it out, during
today Sunday i increase tag number release. thx

Now, I'm a little confused with presence  of %build section, without this
rpmlint is silent, with it is necessary to make %{buildroot}/usr/lib/debug
directory.

Also remember that i need a sponsor. ;)

All other suggestions have been implemented:
Updated to 1.0-2 -- package at:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn.spec
SRPM URL:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn-1.0-2.src.rpm

Others considerations:
I run rpmlint command and the output:

$ rpmlint mybashburn-1.0-2.noarch.rpm 
W: mybashburn conffile-without-noreplace-flag /etc/mybashburnrc
E: mybashburn script-without-shebang
/usr/share/mybashburn/lang/Swedish/iso_menu.lang
E: mybashburn script-without-shebang
/usr/share/mybashburn/lang/Czech/convert_mp3s.lang
[...]

--> I can't understand how fix it.

E: mybashburn world-writable /etc/mybashburnrc 0666
---> Note that this is good and is necessary for the package,  see comment #3

E: mybashburn standard-dir-owned-by-package /usr/bin
E: mybashburn wrong-script-end-of-line-encoding
/usr/share/mybashburn/lang/Polish/multi.lang

--> WTF?.

That's a new one to me. These are apparently false positives?, Thanks for
spending time on this!

> E: mybashburn world-writable /etc/mybashburnrc 0666
> ---> Note that this is good and is necessary for the package,
>  see comment #3

Are you kidding? Files in /etc must not be writable by ordinary
users. The software is flawed, if there is no implementation of
user-local configuration files in $HOME.

> %{buildroot}/usr/lib/debug

Then your RPM config or installation is broken. You don't need to
create that directory.

> mybashburn conffile-without-noreplace-flag /etc/mybashburnrc

This refers to

  %config(noreplace) /etc/mybashburnrc

which influences RPM's strategy for *.rpmsave/*.rpmnew config files.

> E: mybashburn script-without-shebang

This is a hint about all the executable files which should not be
executable. Take a close look at "rpm --query --list mybashburn" and
notice the questionable file permissions.

The manual page is executable, too. And so are many other files which
need not be executable.

> E: mybashburn standard-dir-owned-by-package /usr/bin

List the files included in your package:
rpm --query --list --verbose mybashburn

You include the directory /usr/bin which is wrong, since it belongs into
the core "filesystem" package already.

> E: mybashburn wrong-script-end-of-line-encoding
> /usr/share/mybashburn/lang/Polish/multi.lang
> 
> --> WTF?.

There are DOS/Windows-style 0x0d 0x0a (carriage return, linefeed) line
delimiters used in that file instead of just 0x0a (linefeed). Should be
fixed upstream. Can be fixed with dos2unix or sed.

(In reply to comment #24)
> > E: mybashburn world-writable /etc/mybashburnrc 0666
> > ---> Note that this is good and is necessary for the package,
> >  see comment #3
> 
> Are you kidding? Files in /etc must not be writable by ordinary
> users. The software is flawed, if there is no implementation of
> user-local configuration files in $HOME.
> 

Yes, i'm sure, this should be ignored.

> > %{buildroot}/usr/lib/debug
> Then your RPM config or installation is broken. You don't need to
> create that directory.

Yes, fixed.

> You include the directory /usr/bin which is wrong, since it belongs into
> the core "filesystem" package already.

Fixed.

All other rpmlint E: have been solved:
1) Fixed DOS/Windows-like (CRLF) end-of-line encoding with %%{__sed} tag.
2) Replaced %%{_bindir}/* tag of %%files section by %%{_bindir}/files.
3) Cleanup in %%install section.
4) Replaced %%config(noreplace) instead %%config.

Updated to 1.0-2 -- package at:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn.spec
SRPM URL:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn-1.0-3.src.rpm

(In reply to comment #25)
> Updated to 1.0-2 -- package at:

i meant 1.0-3.

E: mybashburn world-writable /etc/mybashburnrc 0666
(In reply to comment #25)
> (In reply to comment #24)
> > > E: mybashburn world-writable /etc/mybashburnrc 0666
> > > ---> Note that this is good and is necessary for the package,
> > >  see comment #3
> > 
> > Are you kidding? Files in /etc must not be writable by ordinary
> > users. The software is flawed, if there is no implementation of
> > user-local configuration files in $HOME.
> > 
> 
> Yes, i'm sure, this should be ignored.

Bummer, I guess, I can't avoid some _very clear_ words:
* A world-wide writeable file is NOT acceptable.
* A package relying on such a "feature" is maldesigned.

=> Your only choices are 
* Fix this defect/maldesign of the package
* Withdraw this review request.

Unless this has been fixed, there is NO WAY for this package to make into Fedora.

Really thanks for this very clear words, now with the amount of problems arisen
with this revision i lost of see the development of the project, consequently, I
maintain the request of this revision and I concentrate in the development and
adjustment of defect/maldesign of the package.

Thanks.

Ready, removed /etc/mybashburnrc, now it's configure in run time to
~/.mybashburnrc, Builds OK, rpmlint is silent, permissions fine.

New files updated:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn.spec
SRPM URL:
http://www.fedora-ve.org/mybashburn/downloads/mybashburn-1.0-3.src.rpm

greetings and happy new year,

I want announce a new release of MyBashBurn 1.0.1 with major feature and
enhancements, with some security bugfix important for this review, as a function
against race conditions on temp files, now MyBashBurn look for root/user config
in /etc/mybashburnrc, ~/.mybashburnrc in that order, fix permissions, updated
man file and the option of change the 'root directory' (/usr/share/mybashburn/)
have been deprecated for some time and will be removed.

New files location:

SPEC: http://mybashburn.sourceforge.net/mybashburn.spec
SRPMS: http://mybashburn.sourceforge.net/mybashburn-1.0.1-0.src.rpm
HOMEPAGE: http://mybashburn.sourceforge.net/

What's the status on this review?

Looks like you need to correct Changelog entry
rpmlint on rpm gave me
W: mybashburn incoherent-version-in-changelog 1.0.1 1.0.1-0
The last entry in %changelog contains a version identifier that is not
coherent with the epoch:version-release tuple of the package.

After of a short vacations here are some corrections:

SPEC: http://mybashburn.sourceforge.net/mybashburn.spec
SRPMS: http://mybashburn.sourceforge.net/mybashburn-1.0.1-2.src.rpm

Everybody remember, i need a sponsor, Thanks.

^sponser^sponsor :D

New Release of MyBashBurn for more review:

SPEC: http://mybashburn.sourceforge.net/mybashburn.spec
SRPM: http://mybashburn.sourceforge.net/mybashburn-1.0.2-1.src.rpm

- More Clean up code.
- Fixed bug of compatibility for RHEL and CentOS Enterprise Linux.
- Fixed bug on define burn data menu when navigate names with blank spaces.
- Updated Makefile.
- Updated man and INSTALL files.

This has been sitting around for far too long, and it looks as if the major
issues detailed above have been fixed.  I'll review this and emesene together
and, if those reviews go well, I'll sponsor you.  A warning, though, emesene
might need some work.

OK, this builds and installs fine in mock on x86_64 running rawhide.  rpmlint says:
  W: mybashburn spurious-executable-perm /usr/share/man/man1/mybashburn.1.gz
which is easily fixed by setting the permissions to 644 when you install it.

Unfortunately when I attempted to test this, all I get is a message flashingg by
telling me "Terminal size must be fix, the size now is 80x24 Fai MyBashBurn
1.0.2" and then the program exits.  This is on an i386 machine running rawhide.

You need to be consistent about your macro usage.  If you want to use the
macroized forms like %{__sed} then you need to use %{__rm}, %{__install},
%{__cp} and %{__ln}.

Don't start the summary with the name of the package.

You install CREDITS and HOWTO twice.  If they're required as internal help
files, they shouldn't also be installed as %doc.

Review:
* source files match upstream:
   058395728c295988c3d633f5a2a25224f25babea6117d4b35c26c7b7b93e0d6a  
   mybashburn-1.0.2.tar.bz2
* package meets naming and versioning guidelines.
* specfile is properly named
X specfile does not use macros consistently.
X summary should not start with the name of the package.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
X rpmlint has a valid complaint.
* final provides and requires are sane:
   mybashburn = 1.0.2-1.fc8
  =
   /bin/sh
   /usr/bin/env
   cdda2wav
   cdrdao
   cdrecord
   coreutils
   dialog >= 1.0
   dvd+rw-tools
   eject
   flac
   mkisofs
   vorbis-tools
* %check is not present; no test suite upstream.
X Manual testing was not at all successful.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
X CREDITS and and HOWTO are duplicated.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.

Hi Jason, Thanks for testing it.

(In reply to comment #37)
> OK, this builds and installs fine in mock on x86_64 running rawhide.  rpmlint
says:
>   W: mybashburn spurious-executable-perm /usr/share/man/man1/mybashburn.1.gz
> which is easily fixed by setting the permissions to 644 when you install it.

Permissions now are correct, Fixed with: install -p m644 mybashburn.1.gz
 
> Unfortunately when I attempted to test this, all I get is a message flashingg by
> telling me "Terminal size must be fix, the size now is 80x24 Fai MyBashBurn
> 1.0.2" and then the program exits.  This is on an i386 machine running rawhide.

This is oks, for that MyBashBurn working correctly when is running in any X term
is necessary change the window "default size" manually, it not is a bug, does it
draw the windows based on internal dialog program, also attempt that the user
obtains best experience using the program, tries yourself for example to execute
the program in a size of terminal major to 80x20, later resize terminal minor to
80x20 and you know of that I speak to you, whatever with or without resize it
simply function right although it is not seen well. :D
Finnally the user only must resize/extend a little the terminal and execute
mybashburn, made simply, nevertheless when MyBashBurn is running in any not X
terminal it working good.

> You need to be consistent about your macro usage.  If you want to use the
> macroized forms like %{__sed} then you need to use %{__rm}, %{__install},
> %{__cp} and %{__ln}.

I do not want to use that command macroized forms, s/%{_sed}/sed/
Fixed.

> Don't start the summary with the name of the package.

Fixed. 

> You install CREDITS and HOWTO twice.  If they're required as internal help
> files, they shouldn't also be installed as %doc.

oks, you are right, removed CREDITS and HOWTO of %doc.

Finnally thanks for your help on getting this worked out Jason. I've posted an
updated mybashburn spec/SRPM on its review request, update files are on
web project, please refresh:

Spec: http://mybashburn.sourceforge.net/mybashburn.spec
SRPM: http://mybashburn.sourceforge.net/mybashburn-1.0.2-2.src.rpm

(In reply to comment #36)
> I'll review this and emesene together
> and, if those reviews go well, I'll sponsor you.  A warning, though, emesene
> might need some work.

I'll working on a new emesene based on stable SVN version.

I'm just now finding some time to get back to these reviews.

This builds fine and rpmlint now finds nothing to complain about.

I'm afraid I don't understand your comments about the necessary size of the
window.  Perhaps what you're not understanding is that it fails to run
regardless of the size of the window; even on a full screen shell window with an
8pt font on a 24" monitor.  It flashes an almost unreadable message which I
thihnk tells me that the window size is 80x24 (which is most certainly isn't)
and then exits.

A minor nit: I think a summary of "Burn data and create songs with interactive
dialogs" is slightly more correct English.

Otherwise, though, the package is looking good and I'd approve it if I could run it.

Updated with you suggestions:

Spec: http://mybashburn.sourceforge.net/mybashburn.spec
SRPM: http://mybashburn.sourceforge.net/mybashburn-1.0.2-1.src.rpm

Thanks.

I'm confused; this package is older (release 1) than the package linked in
comment 38 (release 2).

I'm sorry, I was confused too, it's just fixed, i can looking some changes in
rpmlint tool and was changed license name of GPL to GPLv2.

Update files:

SPEC: http://mybashburn.sourceforge.net/mybashburn.spec
RPMS: http://mybashburn.sourceforge.net/mybashburn-1.0.2-3.src.rpm

You should use this URL in the Source-Tag:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.bz2

See:
http://fedoraproject.org/wiki/Packaging/SourceURL#head-e27982f18a3bfd26b5b6ecbee113d2d8f3f006f2

(In reply to comment #43)
> You should use this URL in the Source-Tag:
> http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.bz2

Fixed, updates both RPMS files: (release 3)

SPEC: http://mybashburn.sourceforge.net/mybashburn.spec
RPMS: http://mybashburn.sourceforge.net/mybashburn-1.0.2-3.src.rpm

* package builds in mock.
* package installs properly.
* rpmlint has valid complaints.

;)

[ERRATA] Sorry, the correct links of SRPM file is:
RPMS: http://mybashburn.sourceforge.net/mybashburn-1.0.2-3.fc8.src.rpm

Thanks for the review.

It seems to me that the tarball in the srpm is not the same as the upstream tarball.

Looking at the MyBashBurn.sh file, it's clear that the license should be GPLv2+ as they allow "any later version".

I believe those are the only issues remaining.

To refresh my memory, let me run through my checklist again:
X source files do not match upstream.
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
 description is OK.
 dist tag is present.
 build root is OK.
X license field matches the actual license (should be GPLv2+)
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper (none)
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly
* rpmlint is silent.
* final provides and requires are sane:
   mybashburn = 1.0.2-3.fc9
  =
   /bin/sh
   /usr/bin/env
   cdda2wav
   cdrdao
   cdrecord
   coreutils
   dialog >= 1.0
   dvd+rw-tools
   eject
   flac
   mkisofs
   vorbis-tools

* %check is not present; no test suite upstream.  I did some light testing
   (over the network so I didn't actually try to burn anything) and it seems
   to work OK.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.

Hi Jason, I uploaded new files and some brief comments.
"source files do not match upstream.", yeah, I was possibly packaging SVN source 
files.
"license field matches the actual license (should be GPLv2+)" Changed to GPLv2+
according.

SPEC: http://wilmer.fedorapeople.org/files/review/mybashburn/mybashburn.spec
SRPMS:
http://wilmer.fedorapeople.org/files/review/mybashburn/SRPMS/mybashburn-1.0.2-3.fc8.src.rpm
RPMS:
http://wilmer.fedorapeople.org/files/review/mybashburn/RPMS/mybashburn-1.0.2-3.fc8.noarch.rpm

OK, the license is fixed, but the tarball still does not match the upstream tarball.

If you have a Source0: url of 
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
then I simply must be able to download that tarball and get exactly, byte for
byte, what you are including in the srpm.  It is not acceptable for you to
modify that tarball in any way unless it contains content which we cannot
legally distribute.

If you are packaging something out of upstream SVN, we have rules about how you
document that.  You certainly cannot use the same version name because what you
want to distribute is not the same as what upstream ships with that version.  So
please see http://fedoraproject.org/wiki/Packaging/NamingGuidelines.  And if you
are going to package an SVN checkout then we also have rules about how you
document that so that I can make the same SVN checkout as you made:
http://fedoraproject.org/wiki/Packaging/SourceURL.

But honestly, do you have some compelling reason not to just ship what upstream
ships?  Just use their tarball in place of whatever you are trying to package.

Hi Jason, sorry for out long time, of course that there is a reason, I have a
problem with 'rpmlint' command, I get an encoding error about the file 'FILES'
of mybasburn upstream, they was writing in ISO-8859-1 and the CLI rpmlint
recommend using UTF-8, the output of rpmlint:
mybashburn.noarch: W: file-not-utf8 /usr/share/doc/mybashburn-1.0.2/FILES

So, I have to run this command for the conversion:
$ iconv -f ISO-8859-1 -t UTF8 FILES > FILES.tmp
$ mv FILES.tmp FILES

You recommend writing that in the SPEC file?

No, you should run iconv in the %prep section of the specfile to convert the
file at build time.  You don't make the changes in the tarball.

Already, please review
SPEC: http://wilmer.fedorapeople.org/files/review/mybashburn/mybashburn.spec
SRPMS:
http://wilmer.fedorapeople.org/files/review/mybashburn/SRPMS/mybashburn-1.0.2-3.fc8.src.rpm
RPMS:
http://wilmer.fedorapeople.org/files/review/mybashburn/RPMS/mybashburn-1.0.2-3.fc8.noarch.rpm

Cool, this looks good.  I believe all of the issues I had are now fixed.

APPROVED

I have already set you up in the account system, so you should be ready to make
your CVS request.

Jason, I received a email confirmation of you sponsorship.  I'm to get this
message when try to change fedora-cvs flag to '?' for the CVS admin attention:
"Flag Modification Denied
You tried to request fedora-cvs. Only an authorized user can make this change."

I have the existing memberships:
Group Name	Username	R.Domain R.Type	 R Status Sponsor
cvsextras 	wilmer 		user 	approved 	tibbs
fedorabugs 	wilmer 		user 	approved 	Unneeded

Any comment?

Well, you do have to give it time to propagate to all of the various systems and
databases.  I think this happens at least once an hour, so it should almost
certainly be working now.

New Package CVS Request
=======================
Package Name: mybashburn
Short Description: MyBashBurn - burn data and songs.
Owners: wilmer
Branches: F-8
InitialCC: wilmer
Cvsextras Commits: yes

Shouldn't the short description here be something like: 
"Burn data and create songs with interactive dialogs" ?

Hi Kevin, I guess that it sounds more correct in English.

New Package CVS Request
=======================
Package Name: mybashburn
Short Description: "Burn data and create songs with interactive dialogs."
Owners: wilmer
Branches: F-8
InitialCC: wilmer
Cvsextras Commits: yes

cvs done.

Thanks Kevin and specially to Jason for review.

mybashburn-1.0.2-3.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.