Bug 469585
Summary: | Review Request: moon-buggy - Drive and jump with some kind of car across the moon | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Philipp Baum <phil> |
Component: | Package Review | Assignee: | Mamoru TASAKA <mtasaka> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | cassmodiah, christoph.wickert, fedora-package-review, mtasaka, notting, redhat-bugzilla |
Target Milestone: | --- | Flags: | mtasaka:
fedora-review+
kevin: fedora-cvs+ |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 1.0.51-2 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-01-07 13:39:44 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Philipp Baum
2008-11-02 22:04:02 UTC
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. |