Bug 469585

mh, Source0 causes me some bit of discomfort
Perhaps you should use the 2 original sources of upstream and pack the translations from the debian-project as third source..
I´m not sure that you should handle it in this way

you created Source0 with original upstream version of moonbuggy and moonbuggysound and the translations from the debian-project.

New:

http://www.Thinkcoding.org/Fedora/moon-buggy.spec
http://www.Thinkcoding.org/Fedora/moon-buggy-1.0.51-2.fc10.src.rpm

Koji
http://koji.fedoraproject.org/koji/taskinfo?taskID=920044

okay, you created a desktop-file with an install and on your personal wikipage (http://www.fedoraproject.org/wiki/User:Phill) you declared, that you want to review moon-buggy for the actual EL and Fedora branches.

For EL4 & EL5 you need a vendor.

you can handle it in this way:

desktop-file-install %{SOURCE1} \
%if 0%{?rhel}
	--vendor="" \
%endif
--dir=%{buildroot}%{_datadir}/applications


I used this for my package(s), but i don´t know, if this an official way to handle it.

Perhaps we should ask in -packaging or -devel or -epel list(s) first?! I didn´t found a hint on this lists in the archives.

No, its only wrong at my wikipage.. ill fix it, thx.

mh, the translations are broken.

perhaps you should drop this part..

and the game has no pause function. perhaps you can use the debian-pause patch

Here is the New Version:


http://www.Thinkcoding.org/Fedora/moon-buggy.spec
http://www.Thinkcoding.org/Fedora/moon-buggy-1.0.51-3.fc10.src.rpm

okay! you know, this is not an official review...

This "MUST"-Checklist is from:
https://fedoraproject.org/wiki/Packaging/ReviewGuidelines
---------------------------------------------------------

MUST Items:
- MUST: rpmlint must be run on every package. The output should be posted in
the review.
+ rpmlint is silence

- MUST: The package must be named according to the Package Naming Guidelines .
+ OK

- MUST: The spec file name must match the base package %{name}, in the format
%{name}.spec unless your package has an exemption on Package Naming Guidelines
+ OK

- MUST: The package must meet the Packaging Guidelines.
+ OK

- MUST: The package must be licensed with a Fedora approved license and meet
the Licensing Guidelines.
+ OK

- MUST: The License field in the package spec file must match the actual
license.
+ OK

- 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.
+ OK

- MUST: The spec file must be written in American English.
+ OK

- MUST: The spec file for the package MUST be legible. If the reviewer is
unable to read the spec file, it will be impossible to perform a review. Fedora
is not the place for entries into the Obfuscated Code Contest
(http://www.ioccc.org/).
+ OK

- MUST: The sources used to build the package must match the upstream source,
as provided in the spec URL. Reviewers should use md5sum for this task. If no
upstream URL can be specified for this package, please see the Source URL
Guidelines for how to deal with this.
+ OK

- MUST: The package must successfully compile and build into binary rpms on at
least one supported architecture.
+ OK

- 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. Each architecture listed in ExcludeArch needs to have a bug filed
in bugzilla, describing the reason that the package does not compile/build/work
on that architecture. The bug number should then be placed in a comment, next
to the corresponding ExcludeArch line. New packages will not have bugzilla
entries during the review process, so they should put this description in the
comment until the package is approved, then file the bugzilla entry, and
replace the long explanation with the bug number. The bug should be marked as
blocking one (or more) of the following bugs to simplify tracking such issues:
FE-ExcludeArch-x86 , FE-ExcludeArch-x64 , FE-ExcludeArch-ppc ,
FE-ExcludeArch-ppc64
+ OK -> short run-test on x86 
/ N/A -> no run-test on x64
+ OK ->  short run-test on ppc  (without speakers)
/ N/A -> no run-test on ppc64
+OK build on all architectures
http://koji.fedoraproject.org/koji/taskinfo?taskID=948460

- MUST: All build dependencies must be listed in BuildRequires, except for any
that are listed in the exceptions section of the Packaging Guidelines ;
inclusion of those as BuildRequires is optional. Apply common sense.
+OK

- MUST: The spec file MUST handle locales properly. This is done by using the
%find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
/ N/A

- 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. If the package has multiple subpackages with libraries, each
subpackage should also have a %post/%postun section that calls /sbin/ldconfig.
An example of the correct syntax for this is:
/ N/A

- MUST: If the package is designed to be relocatable, the packager must state
this fact in the request for review, along with the rationalization for
relocation of that specific package. Without this, use of Prefix: /usr is
considered a blocker.
/ N/A

- 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. Refer to the Guidelines for examples.
+ OK

- MUST: A package must not contain any duplicate files in the %files listing.
+ OK

- 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.
+ OK

- MUST: Each package must have a %clean section, which contains rm -rf
%{buildroot} ( or $RPM_BUILD_ROOT ).
+ OK

- MUST: Each package must consistently use macros, as described in the macros
section of Packaging Guidelines .
+ OK

- MUST: The package must contain code, or permissable content. This is
described in detail in the code vs. content section of Packaging Guidelines .
+ OK

- MUST: Large documentation files should go in a -doc subpackage. (The
definition of large is left up to the packager's best judgement, but is not
restricted to size. Large can refer to either size or quantity)
/ N/A

- MUST: If a package includes something as %doc, it must not affect the runtime
of the application. To summarize: If it is in %doc, the program must run
properly if it is not present.
/ N/A

- MUST: Header files must be in a -devel package.
/ N/A

- MUST: Static libraries must be in a -static package.
/ N/A

- MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'
(for directory ownership and usability).
/ N/A

- 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/A

- MUST: In the vast majority of cases, devel packages must require the base
package using a fully versioned dependency: Requires: %{name} =
%{version}-%{release}
/ N/A

- MUST: Packages must NOT contain any .la libtool archives, these should be
removed in the spec.
/ N/A

- 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. This is described in detail in the desktop files section of
the Packaging Guidelines . If you feel that your packaged GUI application does
not need a .desktop file, you must put a comment in the spec file with your
explanation.
+ OK

- MUST: Packages must not own files or directories already owned by other
packages. The rule of thumb here is that the first package to be installed
should own the files or directories that other packages may rely upon. This
means, for example, that no package in Fedora should ever share ownership with
any of the files or directories owned by the filesystem or man package. If you
feel that you have a good reason to own a file or directory that another
package owns, then please present that at package review time.
+OK

- MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot}
( or $RPM_BUILD_ROOT ). See Prepping BuildRoot For %install for details.
+ OK

- MUST: All filenames in rpm packages must be valid UTF-8.
+ OK


Just a little thing: your URL should be in my opinion:
URL:             http://seehuhn.de/pages/moon-buggy
perhaps thios is completly irrelevant.

another little tipp:
to ?allure? (i don't know, if this word is suitable) a sponsor you should create one or two packages, which you have in your personal wishlist. we spoke about it, if you remember. make the package and create a review request and link the the request of package1 in your request of package2 and reverse.
so he or she can see that you are determined and that you have an understanding of process and of the packaging guidelines.

Just another tipp:
i am sure you can win points of sympathy if you help Sandro Mathys with the dependencies of TV-Browser.
https://bugzilla.redhat.com/show_bug.cgi?id=472144
speak with him and you can take care of one or two dependecies, if you want to do it. :-)

secound package review of phil is:
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=473754 nopaste

The word "across" is misspelled in the Summary tag, please fix.

Fixed. Thanks

http://www.Thinkcoding.org/Fedora/moon-buggy.spec
http://www.Thinkcoding.org/Fedora/moon-buggy-1.0.51-3.fc10.src.rpm

Some notes:

* License
  - is actually "GPL+". Only putting GPLv2 license text
    in the source tarball and not specifying any version
    on any other source codes renders the version to be
    not only version 2 but also at any version:
    http://fedoraproject.org/wiki/Licensing/FAQ

* autotool autocall
  - build.log shows:
-------------------------------------------------------------------------
   195  configure: creating ./config.status
   196  config.status: creating Makefile
   197  config.status: creating config.h
   198  config.status: executing depfiles commands
   199  + make -j8
   200  cd . && /bin/sh /builddir/build/BUILD/moon-buggy-1.0.51/missing --run autoheader
   201  rm -f stamp-h1
   202  touch config.h.in
   203  cd . && /bin/sh ./config.status config.h
   204  config.status: creating config.h
   205  make  all-am
-------------------------------------------------------------------------
     Here autotools (like autoheader) are automatically called and
     this is not desired (because this changes files unexpectedly).
     Usually this can be avioded by "touch"ing some autotool related
     files correctly.

! Timestamp
-------------------------------------------------------------------------
make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
-------------------------------------------------------------------------
  - is recommended to keep timestamps on installed files as much
    as possible.
    This method usually works for Makefiles generated by recent
    autotools.

! Note
  - Usually Game SIGs suggests that games data files must be
    packaged seperately, however for this game as sound tarball
    is not large, I don't feel the necessity to create another
    srpm for sound tarball.

ping?

I chatted with Phil a few minutes ago, he won't continue this work.
perhaps Robert Scheck, or me, or we both together, will do it.

I will speak with Robert about this (he added himself today in CC-List). We shouldn't close this "over-hasty".

I've locally built a new moon-buggy package with several fixes and
enhancements. I'll let Simon test it a bit (because I rebased it on
an older spec file by him) and afterwards I will put it into this
review.

Mamoru, will you then go for the review or shall I already look for
somebody else doing this review?

Removing fe-needsponsor blocker requirement as Philipp is no longer
a real Fedora contributor.

Robert/Simon: I suggest to close this bug and the one of you who wants to push the package forward should create a new bugzilla entry. This way we will have a correct bug owner / submitter (because AFAIK bugzilla unfortunately does not allow changing the bug owner)

Manuel, I really don't care about that. Just let's finish the review and
then we're fine. Same situation can ever happen, e.g. once the owner of a
package changes (e.g. review request with somebody else than later a bug 
report).

Spec URL: http://labs.linuxnetz.de/bugzilla/moon-buggy.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/moon-buggy-1.0.51-1.src.rpm

Mamoru, would you be so kind and do the review? I think, I shouldn't have
forgotten anything - hopefully. I'm aware about the two rpmlint errors,
but that's the same accepted practice like at e.g. typespeed and nethack:

E: non-standard-executable-perm /usr/bin/moon-buggy 02755
E: non-standard-dir-perm /var/games/moon-buggy 0775

(In reply to comment #17)
> Spec URL: http://labs.linuxnetz.de/bugzilla/moon-buggy.spec
> SRPM URL: http://labs.linuxnetz.de/bugzilla/moon-buggy-1.0.51-1.src.rpm

Well,

[tasaka1@localhost moon-buggy]$ LANG=C rpmbuild --rebuild moon-buggy-1.0.51-1.src.rpm 
Installing moon-buggy-1.0.51-1.src.rpm
error: source package expected, binary found
error: moon-buggy-1.0.51-1.src.rpm cannot be installed
[tasaka1@localhost moon-buggy]$ LANG=C rpm -ivh moon-buggy-1.0.51-1.src.rpm 
error: can't create transaction lock on /var/lib/rpm/__db.000 (Permission denied)

Something seems broken on your srpm...
For now I unpacked your srpm by rpmdev-extract and repackaged it.
Then:

- Installing moon-buggy binary rpm rebuilt from your srpm
- as tasaka1 (i.e. non-root) execute moon-buggy
Then this creates the file "mbscore" under /var/games/moon-buggy
with (owner:group) = (tasaka1:games).
Then what happens if "tasaka1" user does some malicious things on mbscore
(as tasaka1 can modify this file) and "root" executes moon-buggy?

Interesting. Which Fedora release and which RPM version? I've _no_ issues to
rebuild or install this package on plain Fedora 10 and CentOS 5. Maybe we can
get out, what's broken here (btw, rpm2cpio <src> | cpio -idm would have also
worked).

Danger is everywhere. You could exploit vi(1) with nice stuff, insert and
execute your own malicious code written in the file, vi is going to read and
edit - AFAIK this even was recently possible and is now fixed there. For me
this example is the same situation as what you try to describe above, but for
software like vi this seems much more dangerous to me rather to moon-buggy.

There is always some risk once more than a single user is able to touch a
file. Yesterday evening when enabling that feature I already had some kind
of IRC discussion on #fedora-devel. But removing the highscore feature isn't
acceptable for me at all.

My C knowledge isn't the best, but when reading read_version2_data() or the
read_version3_data() from highscore.c, the C code seems to be good. On the
other hand, there AFAIK was no CVE report for that possible issue ever, even 
many various Linux distributions deliver(ed) moon-buggy to their users. So
why should I feel not good for Fedora here?

[20:32:08] < rsc> Packagers around? I've got a game which would like to write a multiuser highscore file. Where? /var/games/%{name}/*? And which permissions? Program offers setgid with games user.
[20:32:22] < ixs> why not?
[20:32:39] < ixs> but I'd give it a special user...
[20:32:42] < ixs> for security reasons
[20:32:56] < ixs> or simple remove the highscore feature
[20:33:08] < rsc> ixs: wäh!
[20:33:18] < ixs> :>
[20:34:30] < lkundrak> ixs: yes, rsc is right
[20:34:53] < ixs> ahh come on
[20:34:57] < ixs> nobody needs highscores
[20:34:58] < ixs> amirite?
[20:35:54] < lkundrak> ixs: i suggest looking at some already existing game. probably nethack or something like that
[20:37:11] < ivazquez> Using games should be fine. What are they going to do, overwrite other games' high scores? :P
[20:37:35] < rsc> lkundrak: existing games are doing what the program offers (setgit + /var/games/)
[20:37:51] < rsc> lkundrak: at least one, I was pointed to.
[20:38:43] < ivazquez> nethack and Maelstrom both use the games group.
[20:40:14] < rsc> ivazquez: /var/games/%{name}.highscore or /var/games/%{name}/highscore or what would you suggest?
[20:44:53] < ivazquez> I would put it in its own directory.
[20:45:19] < ivazquez> I would consider /var/games to be a games-specific /var/lib.
[20:47:43] < rsc> ivazquez: thanks

(In reply to comment #19)
> Interesting. Which Fedora release and which RPM version? I've _no_ issues to
> rebuild or install this package on plain Fedora 10 and CentOS 5. Maybe we can
> get out, what's broken here (btw, rpm2cpio <src> | cpio -idm would have also
> worked).

Both on my rawhide i386 system and koji scratch build
fails (ref:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1031143 )

> Danger is everywhere. You could exploit vi(1) with nice stuff, insert and
> execute your own malicious code written in the file, vi is going to read and
> edit - 

I guess vi case does not apply for the case in this package.
What I am saying is that the malicious code inserted by _one_ person
is read by _another_ person unintentionally (i.e. like
the case in which some malicious png file created by unknown
person on the internet is accessed by local users). 
For /bin/vi case, the impact of the risk should be limited 
to the person who intentionally tried to read the file.

> AFAIK this even was recently possible and is now fixed there. For me
> this example is the same situation as what you try to describe above, but for
> software like vi this seems much more dangerous to me rather to moon-buggy.

So I don't think vi and moon-buggy are the same situation.

> There is always some risk once more than a single user is able to touch a
> file. Yesterday evening when enabling that feature I already had some kind
> of IRC discussion on #fedora-devel. But removing the highscore feature isn't
> acceptable for me at all.

Then please do this in the safe way. By the way the basic problem
I think is that the file "mbscore" is created by arbitrary person.

> My C knowledge isn't the best, but when reading read_version2_data() or the
> read_version3_data() from highscore.c, the C code seems to be good. On the
> other hand, there AFAIK was no CVE report for that possible issue ever, even 
> many various Linux distributions deliver(ed) moon-buggy to their users. So
> why should I feel not good for Fedora here?

Because Fedora is more careful? (actually security responsible
team on RedHat is very concerned about setuid/setgid binaries:
e.g.
https://www.redhat.com/archives/fedora-security-list/2007-April/msg00004.html )


> [20:32:08] < rsc> Packagers around? I've got a game which would like to write a
> multiuser highscore file. Where? /var/games/%{name}/*? And which permissions?
> Program offers setgid with games user.
> [20:32:22] < ixs> why not?
> [20:32:39] < ixs> but I'd give it a special user...
> [20:32:42] < ixs> for security reasons
> [20:32:56] < ixs> or simple remove the highscore feature
> [20:33:08] < rsc> ixs: wäh!
> [20:33:18] < ixs> :>
> [20:34:30] < lkundrak> ixs: yes, rsc is right
> [20:34:53] < ixs> ahh come on
> [20:34:57] < ixs> nobody needs highscores
> [20:34:58] < ixs> amirite?
> [20:35:54] < lkundrak> ixs: i suggest looking at some already existing game.
> probably nethack or something like that
> [20:37:11] < ivazquez> Using games should be fine. What are they going to do,
> overwrite other games' high scores? :P
> [20:37:35] < rsc> lkundrak: existing games are doing what the program offers
> (setgit + /var/games/)
> [20:37:51] < rsc> lkundrak: at least one, I was pointed to.
> [20:38:43] < ivazquez> nethack and Maelstrom both use the games group.
> [20:40:14] < rsc> ivazquez: /var/games/%{name}.highscore or
> /var/games/%{name}/highscore or what would you suggest?
> [20:44:53] < ivazquez> I would put it in its own directory.
> [20:45:19] < ivazquez> I would consider /var/games to be a games-specific
> /var/lib.
> [20:47:43] < rsc> ivazquez: thanks

(In reply to comment #20)
> Both on my rawhide i386 system and koji scratch build
> fails (ref: http://koji.fedoraproject.org/koji/taskinfo?taskID=1031143)

Looks like my Rawhide system is then somehow broken, possible. But shouldn't
prevent us here from continuing, the packages for Fedora are anyway built by
the build system hopefully not broken ;-)

> For /bin/vi case, the impact of the risk should be limited 
> to the person who intentionally tried to read the file.

And if the person doing intentionally this is root? Thus it is simply the
same case as vi. You unluckily didn't get my point.

> Then please do this in the safe way. By the way the basic problem
> I think is that the file "mbscore" is created by arbitrary person.

Patches by you are cheerfully accepted. As other packages having exactly (!)
the same got successfully reviewed, I'm definately not going to change this
as downstream. This would be upstream's job, I'm not forking foreign software
as other packagers do, because we're just Fedora and because of we're just
cool or we want to be better and more concerned about something than others.

Again, can you show me how to exploit or manipulate read_version2_data() or 
read_version3_data() somehow? As mentioned - my C knowledge isn't the best,
but the C code seems straight-forward to me.

> Because Fedora is more careful? (actually security responsible
> team on RedHat is very concerned about setuid/setgid binaries:
> e.g.

> https://www.redhat.com/archives/fedora-security-list/2007-April/msg00004.html

That thread talks about SELinux, PAM and that setuid is here not needed at all;
wrong topic.

According to the Fedora Packaging Guidelines of the Games SIG (http://
fedoraproject.org/wiki/SIGs/Games/Packaging), the current behaviour is
okay and accepted ("[...] If necessary, a game can be made setgid 'games'
in order to allow a shared scoreboard file. [...]"). So why are you here
unneccessarily making the review more hard? If you would like to change
something in general, please go to FESCO or ask the Games SIG to change
this. But don't question the Packaging Guidelines in a Review, that's the
wrong point in the process.

(In reply to comment #21)
> > For /bin/vi case, the impact of the risk should be limited 
> > to the person who intentionally tried to read the file.
> 
> And if the person doing intentionally this is root? Thus it is simply the
> same case as vi. You unluckily didn't get my point.

Again what I am saying that a malious file created by one person
can be read by other person, not only by root.

> 
> > Then please do this in the safe way. By the way the basic problem
> > I think is that the file "mbscore" is created by arbitrary person.
> 
> Patches by you are cheerfully accepted. As other packages having exactly (!)
> the same got successfully reviewed, 

This package is not the other packages, of course.

> I'm definately not going to change this
> as downstream. This would be upstream's job, 

No, maintaining the software in the safe way is definitely
distribution maintainer's job (well, I really don't like the
word "it is upstream's job" which is spoken carelessly.
It must not be a maintainer's attitude).

> I'm not forking foreign software
> as other packagers do, because we're just Fedora and because of we're just
> cool or we want to be better and more concerned about something than others.

I think this must not be a maintainer's attitude.

> 
> Again, can you show me how to exploit or manipulate read_version2_data() or 
> read_version3_data() somehow? As mentioned - my C knowledge isn't the best,
> but the C code seems straight-forward to me.

Potential crafted files may cause buffer overflow or numerical
overflow, in such case we cannot tell what happens, for example?

> 
> > Because Fedora is more careful? (actually security responsible
> > team on RedHat is very concerned about setuid/setgid binaries:
> > e.g.
> 
> > https://www.redhat.com/archives/fedora-security-list/2007-April/msg00004.html
> 
> That thread talks about SELinux, PAM and that setuid is here not needed at all;
> wrong topic.

I just showed an example that RH security responsible team
is very concerned about setuid/gid binaries.

(In reply to comment #22)
> According to the Fedora Packaging Guidelines of the Games SIG (http://
> fedoraproject.org/wiki/SIGs/Games/Packaging), the current behaviour is
> okay and accepted ("[...] If necessary, a game can be made setgid 'games'
> in order to allow a shared scoreboard file. [...]"). 

And of course this must be done safely. Unfortunately
all setgid binaries under %_bindir related to game programs
on my system are in gnome-games or gnuchess, and they handle
high score files in a safe way.

> So why are you here
> unneccessarily making the review more hard? 

It is definitely needed. Review request is _NOT_ just checking
"packaging" issue.

> If you would like to change
> something in general, 

I am not changing anything.

Args, you're expecting me to create and own the /var/games/moon-buggy/mbscore 
file inside of the RPM package with 664 and root:games - right? As the mbscore
file should be created after installing or with the first run of the game (if
you looked to it, there are dates and expires mentioned), I would like to do 
that with %ghost and something in %post - also acceptable?

Well, the more acceptable method is
- do 
  touch %buildroot%_localstatedir/games/%name/mbscore
  at %install
- In %files
  %verify(not md5 size mtime) %config(noreplace) %attr(664, root, games)
  (or %attr(644, games, games)) %_localstatedir/games/%names/mbscore

With this no %post is required, and $ rpm -V won't complain
because of %verify(not). Also I checked that with this
(i.e. creating zero-size mbscore with (root,games)), mbscore
is initialized, however (user, group) is still (root,games).
Also normal user cannot write this file anymore.

(In reply to comment #26)
>   (or %attr(644, games, games)) %_localstatedir/games/%names/mbscore

Of course %attr(664, games,games)...

Okay, if zero-sized mbscore works for moon-buggy, I'll do it that way with the
next build of the package. Something else, you would like to see changed?

Well, we recommend %defattr(-,root,root,-), however
I think that's all.

Spec URL: http://labs.linuxnetz.de/bugzilla/moon-buggy.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/moon-buggy-1.0.51-2.src.rpm

Okay.

-----------------------------------------------------------
       This package (moon-buggy) is APPROVED by mtasaka
-----------------------------------------------------------

New Package CVS Request
=======================
Package Name: moon-buggy
Short Description: Drive and jump with some kind of car across the moon
Owners: robert, cassmodiah
Branches: EL-4 EL-5 F-9 F-10
InitialCC: 
Cvsextras Commits: no

cvs done.

moon-buggy-1.0.51-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/moon-buggy-1.0.51-2.fc9

moon-buggy-1.0.51-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/moon-buggy-1.0.51-2.fc10

1152 (moon-buggy): Build on target fedora-4-epel succeeded.
1151 (moon-buggy): Build on target fedora-5-epel succeeded.

Package: moon-buggy-1.0.51-2.fc9 Tag: dist-f9-updates-candidate Status: complete Built by: robert
Package: moon-buggy-1.0.51-2.fc10 Tag: dist-f10-updates-candidate Status: complete Built by: robert
Package: moon-buggy-1.0.51-2.fc11 Tag: dist-f11 Status: complete Built by: robert

moon-buggy-1.0.51-2.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

moon-buggy-1.0.51-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.