Spec Name or Url: in the src.rpm SRPM Name or Url: ftp://ftp.mondorescue.org/fedora/5/mindi-1.0.7-454.fc5.src.rpm Description: Mindi takes your kernel, modules, tools and libraries, and puts them on N bootable disks (or 1 bootable CD image). You may then boot from the disks/CD and do system maintenance - e.g. format partitions, backup/restore data, verify packages, etc.
Needs work : * No need to define all tags at the top of the spec file. Just use the rpm tags, that will define the proper variables. * BuildRoot should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) (wiki: PackagingGuidelines#BuildRoot) * Non standard group Archiving/Archiving (you can use Applications/Archiving) * Some paths are not replaced with RPM macros (wiki: QAChecklist item 7) (in the scriptlet) * No downloadable source. Please give the full URL in the Source tag. * The BuildRoot must be cleaned at the beginning of %install, not in %prep (it breaks rpmbuild --short-circuit) * The build should be done in %build, and only the install in %install (as a result, you can't use the install.sh script) * The scriptlets should never output anything. It can break some graphical installers, and installation can be unattended. * The /etc/mindi directory is not owned * File list: some files were listed multiple times (wiki: Packaging/ReviewGuidelines) : %{_libdir}/mindi is recursive, you'd better set the correct mode in %install and get rid of the last 3 lines of the %files section. * You need to add a changelog entry
First I generate multiple RPMs for various distro from a single spec template + m4 macros. then I used rpmlint to check for potential issues before submiting and solved nearly all of them. * The tags at the begining not needed, but result from that generation process, and I don't think it's a big issue in itself. * %__id_u is not available for all distro, so I replaced it with id -u -n * Group modified * The path used in the scriptlet is just a check to avoid simultaneous installation of the tool from the tar ball and the rpm which leaded to issuse in the past. So it has to echo something, if not iy's useless. I can't adapt the path, as this path is precisely unrelated to the ones used in the package. * I modified thr Source: tag to include full path * I removed the cleanup in %prep * There is no build phase in itself, as mindi is based on script, and configuration files, as well as a small chroot content. So I don't see your point because I don't build in the install phase. I really just install wit the install.sh script. * I added /etc/mindi as a %config in %files * The problem of the duplicate files is due to te fact that the defattr is 644, but I need that some files be 755. Doing it in install (I went there) does not solve that issue, as rpm behind rechange the modes, if you don't put them with attr later on. Any solution to that issue ? * Changelog added (forgot it) New version available at ftp://ftp.mondorescue.org/fedora/5/mindi-1.0.7-495.fc5.src.rpm
rpmlint errors W: mindi unreasonable-epoch 495 W: mindi incoherent-version-in-changelog 1.0.7 495:1.0.7-495.fc5 E: mindi statically-linked-binary /usr/lib/mindi/rootfs/bin/busybox.net E: mindi statically-linked-binary /usr/lib/mindi/rootfs/bin/busybox W: mindi dangling-relative-symlink /usr/lib/mindi/rootfs/sbin/parted2fdisk fdisk W: mindi dangling-symlink /usr/sbin/parted2fdisk /sbin/fdisk W: mindi hidden-file-or-dir /usr/lib/mindi/rootfs/root/.profile W: mindi hidden-file-or-dir /usr/lib/mindi/rootfs/proc/.keep as well as alot of duplicate file warnings
1/ Epoch is currently the SVN revision Personaly I don't see why Epoch should be limited in any way. But I can study how to change the way it works currently to add a new release revision tag incremented of 1 each time the same version is released. 2/ Yes error on my side 3/ and 4/ I can't do without it !! These binaries have to be statically linked and under that path. What is the real issue here ? I can also ask the new developpers of rpmlint to amend that. 5/ - 8/ Again I need it. the rootfs directory is used to create a boot environment with mindi, so it needs all thes files and links in order to work correclty. Except if you have a better suggestion of localisation ? Concerning the duplicate messages, it's due to the fact that I use %defattr(644,root,root,755) in the spec file. It modifies the modes of the files, as set by the install.sh script. So I have to later on put them again with the right mode: %attr(755,root,root) %{_libdir}/mindi/aux-tools/sbin/* %attr(755,root,root) %{_libdir}/mindi/rootfs/bin/* %attr(755,root,root) %{_libdir}/mindi/rootfs/sbin/* Any suggestion of another way to do it ?
epoch is designed to be used sparingly. for instance if you need to revert to an older version. or upstream change there versioning in a way that means the new versioning will not update the old version. what you would be best using is the release. Statically linked binaries are frowned upon. not forbidden but it is recommended that you dynamically link. the dangling symlinks mean that the files they link to don't exist in the case of files needing different permissions then you need to list them more carefully in the %files section. making sure you own all directories and files you create.
So here is the latest version I prepared. I hope it includes all the points mentioned above. Spec Name or Url: in the src.rpm SRPM Name or Url: ftp://ftp.mondorescue.org/fedora/5/mindi-1.0.7-1.fc5.src.rpm Description: Mindi takes your kernel, modules, tools and libraries, and puts them on N bootable disks (or 1 bootable CD image). You may then boot from the disks/CD and do system maintenance - e.g. format partitions, backup/restore data, verify packages, etc.
Oops, URL is : ftp://ftp.mondorescue.org/fedora/5/mindi-1.0.9-1.fc5.src.rpm
remove the %post section. You cant have that kind of output you have binary statically linked files that you don't build this is very bad as one you shouldn't have anything statically linked, it should not be prebuilt, extras packages support multiple arches those files will not run on ppc or sparc for instance. they will run on x86_64 but 64 bit binaries are preferred.
Thanks for looking at the package. the %post section is to avoid what happens frequently is a dual installation of tar.gz mindi and .rpm mindi with different versions. Depending on PATH it creates issues. That message is just here to prevent people doing that unintentionaly. In what way is it a problem ? (it doesn't break unattended installation as I've seen earlier). Concerning statically built binaries, it is provided upstream like that. It's a busybox version recompiled for mindi. Of course the .config file is provided so information on how to rebuild is there. mindi doesn't support other arch than x86, x86_64 and ia64, for which there is another busybox binary. That binary is just used during restore to create a mini-Unix environement. It would imply an upstream change to modify that, which is not planned yet.
Our supported arches are x86, x86_64, and ppc. from http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?action=show&redirect=PackageReviewGuidelines - 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. (Extras Only) The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc prebuilt binaries are not allowed. you must build them in your package or use the system busybox in this case. http://fedoraproject.org/wiki/Packaging/Guidelines#head-adf31c383612aac313719f7b4f8167b7dcf245d2 Upstream really should not provide them.
I have added an ExcludeArch entry in the spec file for ppc. mindi creates a boot environement which is architecture dependant and for now only i386, x86_64 and ia64 are supported. Upstream provides busybox .config file to allow people to rebuild busybox if needed. What is fedora habits here ? Shoud I provide a mindi-busybox package in addition ?
you can not provide a pre built binary. Why can you not use the Fedora provided busybox? and add support for ppc?
I need to check the pre-built fedore busybox contain all the options needed by mindi. I'll look at it and report. Concerning ppc, have you really looked at what mindi does ? It you want to port it, then propose patches upstream, but I do not have any time nor hardware to do that myself sorry. Do you ask for elilo to be available on ppc too ? mindi deals with boatloading and then has a lot of dependancies with lilo/syslinux/isolinux/elilo which means that you really need to adapt it for ppc if you want it to work on power. I also wanted to add that you do NOT provide a disaster recovey solution for fedora currently whereas I have add much less problem to integrate mindi and mondo in Mandriva, OpenSuSE or Debian. I try to follow the requirements you give for the spec file, but can't follow when you deal with porting, internals of the tool ... which are upstream concerns not packaging concerns. Now if the goal is to avoid adding packages to fedora, I would prefer a clear opinion on that.
if the fedora busybox is missing something you need then please file bugs against busybox. as far as ppc goes i will look at what is needed in regards to porting to ppc. we have a policy to have all arches except when something is arch specific. we use yaboot for ppc loading. We have a clear set of guidelines for packaging and reviewing. http://fedoraproject.org/wiki/Packaging/ReviewGuidelines#head-2f03bba0a9f05b2ac0128eb1d70b1e3ce9f9dc40 states - 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. (Extras Only) The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc
Hi Bruno, Dennis! I've been watching this review request and the one for mondo (bug 187318) for a while and I'm really eager to see mondorescue become part of the Fedora project (Fedora Extras, in this case). The problem is, Fedora currently doesn't provide sufficient backup facilities in Core or Extras. Sure, we have rdiff-backup, duplicity, dump, tar, etc., but nothing can compare with mondorescue's simplicity and ability to do a disaster recovery bare-metal restore. I've been researching various linux lvm-capable bare-metal restore solutions and mondorescue is my best bet so far. Taking into account the aforementioned issues, we should try to be more flexible and respect the specific nature of bare-metal restore process and try to work together, especially if the current upstream maintainer and lead developer of mondorescue is taking time to package mindi and mondo according to Fedora Extras Guidelines. Best regards, Tadej
Thanks Tadej for the feedback. I've since March made a lot of modifications to both the spec files and also the code itself, so that mindi and mondo can integrate Fedora. And It has improved the project packaging and work. In 2.2.0, I'll add a mindi-busybox package, which will indeed remove the binary files from mindi. I hope it's a move well taken. What I can't do now is the ppc adaptation, as I said due to lack of hardware, knowledge, and incitation to so it, but I generally welcome patches. I hope to fix the latest bugs and publish 2.2.0 for the 8th of October. I'll then provide you a new build so that you can look at and comment. Bruno.
we have guidelines that need to be followed. the busybox binary has to be removed from the tarball. and you need to use the one provided by Fedora. how is 2.2.0 coming along?
mindi 1.2.0 (version available at ftp://ftp.mondorescue.org/fedora/5/mindi-1.2.0-2.fc5.src.rpm) is now delivered without a binary busybox in it. Instead an additional package has been made (Cf: ftp://ftp.mondorescue.org/fedora/5/mindi-busybox-1.2.1-2.fc5.src.rpm) I've not checked that all your remarks have been taken in account, even if I tried to. As 1.2.1 is planned to be delivered as soon as my current test are finished, I did not work on that in parallel. Now if you think the current status would allow for easier inclusion, let me know.
As promised the latest version is now there: ftp://ftp.mondorescue.org/fedora/5/mindi-1.2.1-1.fc5.src.rpm Could I have a feedback on this one please ? I also have the mindi-busybox package to consider: ftp://ftp.mondorescue.org/fedora/5/mindi-busybox-1.2.2-1.fc5.src.rpm I tried to fix the problems reported in this report. Let me know what the staus could be.
A few comments : * The spec file incoding should be UTF-8 * In %%prep : "-n %name-%version" is not needed, it's the default (it's not a blocker, do as you wish). You also may want to add -q to suppress the file listing on untarring. * If the package contains no binary, it should be "noarch" (BuildArch: noarch) Thanks for your patience and dedication.
I've added -q and removed -n in the SPEC The packge still contained one binary file that I have now removed, so I'll now make the package noarch.rpm indeed. I'm still looking at why UTF-8 is incorrect. As soon as I have a new package ready for your analysis, I'll let you know. Thanks for your feedback.
> I'm still looking at why UTF-8 is incorrect. Open the spec file in "less", you'll see accented caracters stand out in changelog entries for 1.0.7-1.fc5 and 1.06-1.fc5 (Rémy and Sébastien). By the way, the spec file changelog should only contain packaging changes, not the application's changelog. That should only be in the ChangeLog file, installed in %doc.
ping ?
Due to problems on 1.2.2/2.2.2 I skiped those packages. Could you check the status of the mindi package available at ftp://ftp.mondorescue.org/fedora-extras/mindi-1.2.3-1.fc6.src.rpm (notice that mindi now needs also mindi-busybox available at the same place: ftp://ftp.mondorescue.org/fedora-extras/mindi-busybox-1.2.2-2.fc6.src.rpm)
i still stand by my earlier comment. you should use the busybox in fedora. not some other version. If there is extra functionality you need you should get it upstream to busybox rather than forking busybox.
I still stand on my earlier comments: you've not understood what is mindi's goal, not why I need to control the way busybox is built. I don't use whatever busybox, I make a special binary based on busybox hold under rootfs/sbin that will be use at restore time. You asked to not have a binary in the tree, and I agreed on that, even if it wasn't a priority for the project. Now let me use what I need, no what you would like us to do !! We're not here to discuss on upstream functions but to package an existing app ! Now, I think I won't pass any more time on this. After all people wanting to use it on fedore have packages since a long time, and use them. My goal was to make it easy for fedore users. You disagree. That's fine. I'll rather work on creating repodata info and config files.
I'm sorry you feel that way. To give you some perspective of where i'm coming from. say i start some project and fork busybox for my needs and so does someone else. with your version we would now have 4 slightly different versions of busybox. that means 4 seperate people need to maintain it. The reason i suggest and its not a must just a suggestion that you use the fedora busybox. is so that we don't end up with a ton of pretty much the same but just a litte different versions of the same package. You need to submit your mindi-busybox package for review. Please continue to work with us. I did a quick check of the package last night. you are still not using disttags as per the guidelines. you are not allowed to hardcode the disttag value. /etc/mindi/ needs to be owned by mindi
I need my version of busybox (fixed, well known without the bugs introduced by newer one ...). It's only a small package, I'm able to maintain that myself. I can change the name if that's an issue ;-) But I need full control on it. I continue to work with you, even if I find that a bit picky sometimes. the dist tag, contrary to what you say is not mandatory (Cf: http://fedoraproject.org/wiki/Packaging/DistTag?action=show&redirect=DistTag). But there was an error in my .spec I corrected now, so I should normaly use it correctly now. mindi should also now own /etc/mindi. Latest versions at: ftp://ftp.mondorescue.org/fedora-extras/
This seems to be stalled, blocked on the reviewer. Setting NEEDINFO. In addition, the submitter needs sponsorship according to bug 187318. Aurelien, were you aware of that?
New packages at ftp://ftp.mondorescue.org/fedora/7/mindi-1.2.4-1.fc7.src.rpm ftp://ftp.mondorescue.org/fedora/7/mindi-busybox-1.2.2-3.fc7.src.rpm and ftp://ftp.mondorescue.org/fedora/6/mindi-1.2.4-1.fc6.src.rpm ftp://ftp.mondorescue.org/fedora/6/mindi-busybox-1.2.2-3.fc6.src.rpm Working yum repo at ftp://ftp.mondorescue.org/fedora/7/fedora-mondo.repo ftp://ftp.mondorescue.org/fedora/6/fedora-mondo.repo Is there still someone looking for this? I'd love to see this in the standard repository. Bruno, could you give some more information what makes it difficult to use the busybox package that's already in the repository? What specific additions or fixes did you add that can't go in the main branch? I'm just curious here and trying to build a bridge... Where are the source packages for afio and buffer? Wouldn't these be needed as well in Fedora and thus should also go through review? Could neither find .src.rpm nor review request.
The version of busybox used by mindi is statically linked. So I have a patch to handle that as it's not supported in busybox 1.2.x. I have the need for precise functions built-in and some other *NOT* built in (such as modules support). I keep using an older version of busybox as that binary is cfritical for our tool, and I don't want to pass my time testing newer versions all the time. I need a very stable busybox for the recovery env, for which e.g. NFS is no problem ... 3 good reasons IMO for the project to keep a separated package for that. For afio and buffer I can also provide packages for fedora if there is a need indeed to provide them (I thought they were already part of the distro and didn't check that indeed).
> For afio and buffer I can also provide packages for fedora if there is a need > indeed to provide them (I thought they were already part of the distro and > didn't check that indeed). Please do this. Also I did some changes in Bug 187317 blocks: FE-NEEDSPONSOR was missing, FE-REVIEW is not needed anymore.
Ok, I put a first version of afio and buffer packages at ftp://ftp.mondorescue.org/fedora-extras/afio-2.5-1.src.rpm and ftp://ftp.mondorescue.org/fedora-extras/buffer-1.19-1.src.rpm I guess there will be some remarks (I tried to do my best with rpmlint remarks)
I'm trying to look over some of these really old tickets. This one seems to be a real mess. First, one review per ticket, please. If you want afio and buffer to be reviewed, please open new tickets for them. Second, what's happened to the reviewer? Aurelien, do you still have any interest at all in reviewing this? Since this is a NEEDSPONSOR ticket, were you intending to sponsor Bruno?
Here is the ticket for afio: https://bugzilla.redhat.com/show_bug.cgi?id=449037 And for buffer: https://bugzilla.redhat.com/show_bug.cgi?id=462982
I fixed some remaining mode issues recently. Latest version is at ftp://ftp.mondorescue.org/test/fedora/9/mindi-2.0.4-1.fc9.src.rpm and SPEC at ftp://ftp.mondorescue.org/test/fedora/9/mindi.spec Still looking for evolution on that if you still want it to be included.
We have an issue here. Fedora packages MUST be able to be built using ONLY the content of the Fedora repository. Hence the Require: mindi-busybox will prevent building mindi, as long as mindi-busybox is not a valid Fedora package. And I do not see even a review request for such a beast. Note that I believe that a fork of an existing package would not be accepted without an approval from the packaging committee. I am sure that a proper solution could be found, once the correct arguments are presented.
(In reply to comment #37) > We have an issue here. Fedora packages MUST be able to be built using ONLY the > content of the Fedora repository. Hence the Require: mindi-busybox will prevent > building mindi, as long as mindi-busybox is not a valid Fedora package. And I > do not see even a review request for such a beast. Yes. As the global project mondo was needing also buffer and afio, I chose to began with those bricks which are external. I can easily make a request for mindi-busybox once those have been accepted. > Note that I believe that a fork of an existing package would not be accepted > without an approval from the packaging committee. I am sure that a proper > solution could be found, once the correct arguments are presented. As already entioned many times, we nee a very well known version of busybox during restore time (having some functions activated and other not) which we rely deeply on. Upstream is maintaining such a project based on an older but more stable (at least known) version of busybox in order to avoid unexpected issues. THat may evolve in the future but is now required. Hope this helps.
I have made available a mindi-busybox package (Cf: https://bugzilla.redhat.com/show_bug.cgi?id=476234)
The latest versions for this package are available here: ftp://ftp.mondorescue.org/test/fedora/16/x86_64/mindi-2.1.0-0.20111114000556.fc16.src.rpm and ftp://ftp.mondorescue.org/test/fedora/16/x86_64/mindi.spec TIA for anyone willing to hep me having them in Fedora.
Aurelien Bompard does not react for some time. Moving back to NEW so somebody else can do the review.
Cannot find Bruno Cornec in FAS. Please maintain the FE-NEEDSPONSOR flag properly. Hidden review tickets, wrong ticket status, unclear sponsorship status -> that several of the reasons for no progress.
The "Spec URL" and "SRPM URL" lines in review tickets make it possible to run "fedora-review -b 187317" for this ticket. Spec URL: ftp://ftp.mondorescue.org/test/fedora/19/x86_64/mindi.spec SRPM URL: ftp://ftp.mondorescue.org/test/fedora/19/x86_64/mindi-2.1.620130730020540-0.fc19.src.rpm
The rpmlint findings (run rpmlint with option -i for more helpful explanations): > mindi.x86_64: W: only-non-binary-in-usr-lib > mindi.x86_64: E: no-binary False positive, and the spec file comments on that too. It's true that the executables in PATH are only scripts, but the package cannnot be made "noarch" because of the arch-specific %_libdir/mindi/ tree it creates. However, this means the automatically generated -debuginfo package should/could be disabled with this definition: %global debug_package %{nil} Currently, it's empty anyway. > mindi.x86_64: W: dangling-relative-symlink /usr/sbin/parted2fdisk ../../sbin/fdisk > mindi.x86_64: W: dangling-relative-symlink /usr/lib64/mindi/rootfs/sbin/parted2fdisk fdisk Two minor issues here: * It's /usr/sbin/fdisk since Fedora 17: http://fedoraproject.org/wiki/Features/UsrMove * Is the missing dependency on either package "util-linux" or /usr/sbin/fdisk intentional, or has it been optimised away? > mindi.src:42: W: macro-in-comment %{_docdir} In %changelog, please escape macros using double '%%', so they never get expanded. You want to see the macro name in the changelog, not its value, which may change over time. Some macros even can have side-effects when expanding at "wrong" locations of the spec file. > mindi.src:1266: W: mixed-use-of-spaces-and-tabs (spaces: line 1266, tab: line 4) Somewhere deep in the %changelog, so not really an issue. > mindi.src: W: invalid-url Source0: ftp://ftp.mondorescue.org/test/src/mindi-2.1.620130730020540.tar.gz <urlopen error ftp error: [Errno ftp error] 550 Failed to change directory.> Indeed. That tarball is not available in the src download dir. > Release: 0%{dist} Just mentioning, first build for Fedora starts at 1 usually. > %config(noreplace) %{_sysconfdir}/%{name} A bit "sloppy", because this line includes the complete /etc/mindi directory, even README.* files and flags everything as config file. What else? Similar to review of mindi-busybox, being explicit in the spec file with a comment on whether the spec file shall stay compatible with EL5 would be good. Else the old buildroot related cruft may be removed. %defattr usage can be dropped in either case.
Bruno has been sponsored (fas name bcornec) therefore removing FE-NEEDSPONSOR.
Setting NEEDINFO flag to start the countdown of 30 days before review-stats closes this, just in case someone wants to resurrect this 14yo ticket...
Sorry, seems that due ato a change in my e-mail address some of the dialog has been lost. And yes it has been a lenghty opened BR, but I'm still willing to include MondoRescue and here mindi inside Fedora, if you wish it as well. Anyway, since it has been long since the last feedback, I think it's better to start from the latest versions from both sides: SRPM: ftp://ftp.mondorescue.org/test/fedora/32/x86_64/mindi-3.3.0-0.20201118003941.s3776M.fc32.src.rpm SPEC: ftp://ftp.mondorescue.org/test/fedora/32/x86_64/mindi.spec Hopefully most of the problems are either acceptable or solved since that.
Well, the first step if you want this review to proceed is to get mindi-busybox packaged - the old review request was closed as stalled, so you'll have to open a new one. After that, you should have a look to the packaging guidelines, I've barely looked your last .spec file, but I've already some problems (ExclusiveArch set for architectures that are no more supported by Fedora, buildroot removal...)
- This need to be justified or fixed: # Avoids to generate debug packages %global debug_package %{nil} - Again why the non standard release info: Release: 0.20201118013837.s3776M%{dist} It should be 1. - Not used in Fedora Group: - Not needed BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -u -n) - Not available for me: Source: ftp://ftp.mondorescue.org/test/src/%{srcname}-%{version}.0.20201118013837.tar.gz - I don't think we support ia64 anymore. - Please justify this ExclusiveArch: x86_64 i586 i386 i686 ia64 Why can't it be compiled on other arches? - Not needed: rm -rf $RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT %defattr(-,root,root) - The license file must be installed with %license in %files: %license COPYING - Is there a reason this is not noarchc it seems to be all perl and bash. You should probably add: BuildRequires: perl-generators BuildRequires: perl-interpreter
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time. We're sorry it is taking so long. If you're still interested in packaging this software into Fedora repositories, please respond to this comment clearing the NEEDINFO flag. You may want to update the specfile and the src.rpm to the latest version available and to propose a review swap on Fedora devel mailing list to increase chances to have your package reviewed. If this is your first package and you need a sponsor, you may want to post some informal reviews. Read more at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group. Without any reply, this request will shortly be considered abandoned and will be closed. Thank you for your patience.
This is an automatic action taken by review-stats script. The ticket submitter failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we consider this ticket as DEADREVIEW and proceed to close it.