Spec Name or Url: in the src.rpm SRPM Name or Url: ftp://ftp.mondorescue.org/fedora/5/mondo-2.0.7-454.fc5.src.rpm Description: A program which a Linux user can utilize to create a rescue/restore CD/tape
Note that this is not a formal review. Here's a couple of quick items: 1. Don't use all the macros at the top of your spec, it just makes it harder to do any qa on. 2. Drop the additional languages from the spec. 3. Missing ChangeLog. 4. You using a non-standard Group. 5. Duplicate BuildRequires: slang-devel (provided by newt-devel) I would suggest fully reading the packing guidelines on the wiki, since most of these issues are addressed there. http://fedoraproject.org/wiki/Extras
in addition to above you need to fill in the changelog. the source needs the full http:// or ftp:// url generally package builds start at 1 not 454. it is recommeneded to use disttags. you have alot of duplicate requires rpm is smart enough to pick up shared objects that are linked. looks like it requires mindi but it is not available it seems to be submitted bug #187317 you should block this bug also. you need to own all the files/directories you create why is there executable files in %{_datadir} ?
(In reply to comment #1) > 1. Don't use all the macros at the top of your spec, it just makes it harder to > do any qa on. Well, as I explained already in the mindi package, I have a build system to create .spec already in place. I'll see if I can do better, but for now these macros are useful for multirpm distro support (aka mandriva + suse + rhel + sles) > 2. Drop the additional languages from the spec. Why that ? Is fedora becoming an english only distro ? there are billions of people not speaking english, and for them having the possibility to read something else that english is useful no ? To be honest those rpms exist nearly since the begining of the project, and nobody never complained on that before, so I'm really surprised. > 3. Missing ChangeLog. My fault, will redeliver and add it. Corrected in SVN. > 4. You using a non-standard Group. Corrected in SVN. > 5. Duplicate BuildRequires: slang-devel (provided by newt-devel) I don't see the point here: # rpm -q slang-devel --provides slang-devel = 2.0.5-5.2.1 # rpm -q newt-devel --provides newt-devel = 0.52.2-5.2 What do you mean by duplicate ? Thanks for your answer, Bruno.
by duplicate he means [dennis@rpclnx001 SPECS]$ rpm -q --whatrequires slang-devel newt-devel-0.52.2-6 so by BuildRequire newt-devel you also get slang-devel
(In reply to comment #2) (will do shorter as my comments were thrown away due to simultabeous modifs grumph) > in addition to above you need to fill in the changelog. the source needs the > full http:// or ftp:// url generally package builds start at 1 not 454. it > is recommeneded to use disttags. Corrected in SVN. We used SVN revision up to now so the 454. What is the rule for SVN devs ? What are disttags ? (no ref in your above http link) > you have alot of duplicate requires rpm is smart enough to pick up shared > objects that are linked. Do you mean newt ? And what if I require at least a certain version of newt ? > looks like it requires mindi but it is not available it seems to be submitted > bug #187317 you should block this bug also. The answers to the rest are in the mindi bug report (don't want to mix and match bug reports). Bruno.
(In reply to comment #4) > by duplicate he means > > [dennis@rpclnx001 SPECS]$ rpm -q --whatrequires slang-devel > newt-devel-0.52.2-6 > > so by BuildRequire newt-devel you also get slang-devel Ok, understood. But what about th fact we need slang > 1.4.1 ? This constraint is different from the previous one no ? Bruno.
> 2. Drop the additional languages from the spec. Actually, it is recommanded to have the translations in the spec file. See the bottom of http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?highlight=translations (2nd SHOULD item)
disttag explenation http://fedoraproject.org/wiki/DistTag it will have zero effect on other Distros \ we only provide one version of slang so if its not high enough build will fail. rpmbuild partial output. Requires: /bin/sh afio binutils bzip2 >= 0.9 libc.so.6()(64bit) libc.so.6 (GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libnewt.so.0.52()(64bit) libnewt.so.0.52 (NEWT_0.52)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5) (64bit) mindi >= 1.0.7 mkisofs newt >= 0.50 slang >= 1.4.1 syslinux >= 1.52 so you link to libnewt's shared objects rpm knows that and has a requires on it. you dont link toslang though so it is a superfluous Requires as it is brought in via newt. i am assuming that you are using bzip2 binutils mkisofs syslinux via scripts? as you havent linked to them. you also have alot of duplicate files listed did you read the packaging guidelines? they answer most of these issues
(In reply to comment #3) > (In reply to comment #1) > > 1. Don't use all the macros at the top of your spec, it just makes it harder to > > do any qa on. > > Well, as I explained already in the mindi package, I have a build system to > create .spec already in place. I'll see if I can do better, but for now these > macros are useful for multirpm distro support (aka mandriva + suse + rhel + sles) Well, since this will be imported in Fedora Extras CVS, the other distro support should be dropped, and the unnecessary macros dropped.
Are you stillintrested in getting this package in Fedora Extras? If so please review the packaging guidelines. and ensure that your package meets them. Please note that you can not use your existing build system with the extras package. It must meet the fedora guidelines and live in fedora extras cvs. you can keep a copy in your local svn tree but your package must meet fedora guidelines always.
I'm still interested, and have read most of what was advised. I want to propose a new version with the upstream 2.0.9 version which should arrive RSN. I'll amend this bug report as soon as it's available.
So here is the latest version I prepared. I hope it includes all the points mentined above. Spec Name or Url: in the src.rpm SRPM Name or Url: ftp://ftp.mondorescue.org/fedora/5/mondo-2.0.9-1.fc5.src.rpm Description: A program which a Linux user can utilize to create a rescue/restore CD/tape
ok quick thing drop the define addreq and just put your requires in a Requires line you do realise you dont have to have them all on one line? do not hard code .fc5 in release use %{?dist} is there any reason you are not using %{?_smp_mflags} with make you really should just call make not %{__make} drop --program-prefix=%{?_program_prefix} from %configure your not using it at all you really should not add all the Requires unless they are only needed at run time. if they please state so. http://fedoraproject.org/wiki/Packaging/Guidelines#Requires you dont need to require gcc http://fedoraproject.org/wiki/Extras/FullExceptionList dont use %makeinstall http://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d0dbcfbdd2fcb7791dd002 I would write the spec file more like attached spec
Created attachment 134115 [details] corrected spec
hello No activity logged since August 2006. What's is the status of inclusion of Mondo rescue into Fedora Extras ?
the latest status on my side is available at ftp://ftp.mondorescue.org/fedora/5/mondo-2.2.0-2.fc5.src.rpm Not all the previous remarks made on this bug report have been integrated :-( That's why I haven't given feedback till now. Version 2.2.1 should arrive soon (tests running now), and I hope to be able to fix most remaining problems with it. A snapshot is available at ftp://ftp.mondorescue.org/fedora/5/mondo-stable-1.fc5.src.rpm I hope that at that point inclusion will be easier. BTW as noted, first point is to fix mindi for inclusion.
So a new version of mondo is available and I hope it will meet Fedora Extra requirements. ftp://ftp.mondorescue.org/fedora/5/mondo-2.2.1-1.fc5.src.rpm TIA for your feedback
An updated version is now available at ftp://ftp.mondorescue.org/fedora-extras/mondo-2.2.3-1.fc6.src.rpm which hopefully solves the issues encountered in the past. Of course, mindi needs to be accepted first, so this has to wait till that point. TIA for your feedback.
New packages at ftp://ftp.mondorescue.org/fedora/6/mondo-2.2.4-1.fc6.src.rpm and ftp://ftp.mondorescue.org/fedora/7/mondo-2.2.4-1.fc7.src.rpm I have rebuild the packages and they work just fine. Someone here to do the formal packaging checks?
rpmlint says: W: mondo invalid-license GPL E: mondo non-utf8-spec-file mondo.spec W: mondo macro-in-%changelog attr W: mondo macro-in-%changelog done W: mondo macro-in-%changelog d Please change license to GPLv2 or GPLv2+ . Convert your spec file to UTF-8. Remove macros (%attr, %done, %d) from changelog entries, you can remove the "%" sign and leave only the "attr macro" string. Your localized summary lines are too loing. They can be only 80 characters long. The ".fc7" tag is hardcoded into spec file. Please change it to "%{?dist}". Update changelog entries to more Fedora notation. Change this: * Fri Jul 06 2007 Bruno Cornec <bruno> 2.2.4-1.fc7 to: * Fri Jul 06 2007 Bruno Cornec <bruno> - 2.2.4-1.fc7 ("-" sign has been added) I think your changelog is too long and may be reduced. I think svn.log is not needed in package documentation, ChangeLog is enough.
FE-NEW does not need to be blocked anymore.
I've removed the % in my svn version. I made summary shorter also in SVN. spec file should now be UTF-8. I'll try to shorten the log and remove the svn.log as well. For the License, how to you handle compatibility with previous versions of fedora ? If I put GPLv2, and tr to build on an older version rpmlint will say it doesn't exists.
PLease add an URL for new src.rpm for next review. You can update rpmlint on FC6 and F7 to display proper information. I think it is not important, what shows old rpmlint on non-supported fedoras. The package will be compatible with any versions of Fedora older than FC6 with any License tag, because there was no LicensingGuidelines for these fedoras. Another way can be rebuild of rpmlint for your older fedora, if you want, but it is highly recommended to upgrade all non-supported Fedoras asap. Because they have no updates, I think it is not required to make new backups of these systems. :-)
Ping?
So it's been another month and there hasn't been any actividy on either this or bug 187317 (besides these pings) in ages. Setting NEEDINFO; I will close them in one week if there is no response.
the latest package version built is at ftp://ftp.mondorescue.org/fedora/8/test/mondo-2.2.5-1.fc8.src.rpm Hope they will show progress
It looks like Bruno neglected to check the "I am providing the requested information" box, and so this is improperly set as NEEDINFO.
Unfortunately the URL in comment 27 is invalid.
Sorry, 2.2.5 has since been published officially. So the new correct URLs at the tuime of the writing are: ftp://ftp.mondorescue.org/fedora/8/test/mondo-2.2.6-1.fc8.src.rpm (latest beta) ftp://ftp.mondorescue.org/fedora/8/mondo-2.2.5-1.fc8.src.rpm (latest official)
This builds but fails to install for me: /usr/bin/yum --installroot /mock/fedora-development-x86_64/root/ install /mock/fedora-development-x86_64/result/mondo-2.2.6-1.fc8.x86_64.rpm /mock/fedora-development-x86_64/result/mondo-debuginfo-2.2.6-1.fc8.x86_64.rpm Error: Missing Dependency: mindi >= 1.2.1 is needed by package mondo Error: Missing Dependency: afio is needed by package mondo Error: Missing Dependency: buffer is needed by package mondo I guess the mindi review is stalled out. I don't see any review tickets for afio or buffer, though; what are they?
Here is the ticket for afio: https://bugzilla.redhat.com/show_bug.cgi?id=449037 I'll work on buffer and provide it here as well.
Buffer is now submitted at https://bugzilla.redhat.com/show_bug.cgi?id=462982
Any sponsor watching this package? I think all dependencies have been solved. I am ready to approve buffer package, just I am not a sponsor and it's better, if packager's first package is approved by a sponsor. I am in packager group and I am interested in packaging mondorescue project. It's a good project and I have to use it in fedora.
The latest version to look at is under: ftp://ftp.mondorescue.org/test/fedora/9/mondo-2.2.7-1.fc9.src.rpm SPEC: ftp://ftp.mondorescue.org/test/fedora/9/mondo.spec
restoring NEW as status, according to its history no one has ever formally decided to review the bug.
mondo may work without afio, using star already in fedora, so removing the link. Will regenerate packages accordingly asap.
Could you please can try to trim the changelog? I doubt anyone still cares about the entries from 2000 and in the current form it has almost 1300 lines out of the total of 1382. Not to mention that a large part of the content seems to better fit into a program changelog, not in the package's changelog And also please fix the ending ".fc9" automatically appended to all entries. I am kind of sure .fc9 was not around when the first ones were created.
I just tried the repo file from ftp://ftp.mondorescue.org/fedora/9/mondorescue.repo but get Error: Missing Dependency: afio is needed by package mondo-2.2.7-1.fc9.x86_64 (mondorescue) Error: Missing Dependency: buffer is needed by package mondo-2.2.7-1.fc9.x86_64 (mondorescue) when I try "yum install mondo mindi". Any workaround? Anything I can do to help testing?
I'm making my integration tests for fedora at the moment for my first package buffer. In the mean time, my tests packages available with that repo file: ftp://ftp.mondorescue.org/test/fedora/9/mondorescue.repo Sorry for the confusion. As soon as I've finished validating them, I'll put them in the main directory.
Thanks - the test repo seems to work just fine. I'm able to install: Installing: mindi x86_64 2.0.5-1.fc9 mondorescue 218 k mondo x86_64 2.2.8-1.fc9 mondorescue 900 k Installing for dependencies: afio x86_64 2.5-1.fc9 mondorescue 75 k buffer x86_64 1.19-4.fc9 mondorescue 22 k mindi-busybox i386 1.7.3-1.fc9 mondorescue 244 k mtools x86_64 3.9.11-4.fc9 fedora 212 k syslinux x86_64 3.61-2.fc9 fedora 770 k
...and then I tried it, and it failed: "---FATALERROR--- Failed to generate boot+data disks" Seems to be because of this: "Unable to find mindi-busybox, please install it" Hm, read bug #187317 and understand there are some problems regarding (mindi-)buybox. This is what I've got on my system: mindi-busybox-1.7.3-1.fc9.i386 Hope this will be sorted out, good luck Bruno! In the meantime, is there a workaround anyone can suggest...?
(In reply to comment #42) > ...and then I tried it, and it failed: > "---FATALERROR--- Failed to generate boot+data disks" > > Seems to be because of this: > "Unable to find mindi-busybox, please install it" > > Hm, read bug #187317 and understand there are some problems regarding > (mindi-)buybox. This is what I've got on my system: > mindi-busybox-1.7.3-1.fc9.i386 Which is not compatible with mondo x86_64 and mindi x86_64 You should exclude the i386 arch when using yum to get the right one I think. Maybe there is a better way to indicate that in the repo file.
Ok, I'm not sure how to exclude i386 (not even sure that is the right thing to do - some stuff relies on i386 even on 64bit), but this is what I did: 'yum remove mindi-busybox' (also removed mondo and mindi), then 'yum install mondo' (wants to install mondo.x86_64, mindi.x86_64 and mindi-busybox.i386, all from mondorescue repo). So it seems the x86_64 version is not available: "yum list mindi-busybox" shows only mindi-busybox.i386 1.7.3-1.fc9. Any hints appreciated.
I do not want to sound rude, but Martin, none of your comments is related to package submission / review. Please be as kind as to solve your problem[s] via more appropriate channels.
Official review of 47a66f982319e2c8d0b73a6400f4342f mondo-2.2.8-1.fc9.src.rpm - MUST: rpmlint must be run on every package. The output should be posted in the review. Clean. - MUST: The package must be named according to the Package Naming Guidelines . Good. - 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 Good. - MUST: The package must meet the Packaging Guidelines . ==> in spec file the line: Source: ftp://ftp.mondorescue.org/src/%{name}-%{version}.tar.gz can better be called Source0: ftp://ftp.mondorescue.org/src/%{name}-%{version}.tar.gz - MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . Good. - MUST: The License field in the package spec file must match the actual license. Good. - 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. Good. - MUST: The spec file must be written in American English. Good. - 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/). Good. Might want to trim the changelog (getting too large to be useful in spec file) - 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. Good. - MUST: The package must successfully compile and build into binary rpms on at least one supported architecture. Good. - 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 Spec file mentions: ExcludeArch: ppc ==> Please read above recommendation carefully and do what is required. - 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. Requires: rtld(GNU_HASH) seems to be missing. - MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. Good. - 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: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig NA. - 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. NA. - 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. Good. - MUST: A package must not contain any duplicate files in the %files listing. Good. - 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. ==> In spec file there is : %defattr(-,root,root) Please replace it with : %defattr(-,root,root,-) - MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} ( or $RPM_BUILD_ROOT ). Good. - MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines . Good. - MUST: The package must contain code, or permissable content. This is described in detail in the code vs. content section of Packaging Guidelines . Good. - 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) NA. - 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. Good. - MUST: Header files must be in a -devel package. NA. - MUST: Static libraries must be in a -static package. NA. - MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). NA. - 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. NA. - MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} NA. - MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. Good. - 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. NA. - 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. NA. - MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} ( or $RPM_BUILD_ROOT ). See Prepping BuildRoot For %install for details. Good. - MUST: All filenames in rpm packages must be valid UTF-8. /usr/share/doc/mondo-2.2.8/AUTHORS: ASCII text /usr/share/doc/mondo-2.2.8/ChangeLog: ASCII text /usr/share/doc/mondo-2.2.8/COPYING: ASCII English text /usr/share/doc/mondo-2.2.8/INSTALL: ASCII English text /usr/share/doc/mondo-2.2.8/mondorescue-howto.html: HTML document text /usr/share/doc/mondo-2.2.8/mondorescue-howto.pdf: PDF document, version 1.4 /usr/share/doc/mondo-2.2.8/NEWS: UTF-8 Unicode English text, with very long lines /usr/share/doc/mondo-2.2.8/NEWS.old: UTF-8 Unicode English text /usr/share/doc/mondo-2.2.8/README: ASCII English text /usr/share/doc/mondo-2.2.8/TODO: ASCII English text ==> please convert to UTF-8 Keeping the original date/time of documentation file is probably a good idea (no guidelines about this) A simple solution : # Convert to utf-8 for file in COPYING INSTALL NEWS README TODO AUTHORS Changelog; do mv $file timestamp iconv -f ISO-8859-1 -t UTF-8 -o $file timestamp touch -r timestamp $file done I guess the NEWS.old is not relevant? - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. Good. - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. Good. - SHOULD: The the package builds in mock. Good on i386. - SHOULD: The package should compile and build into binary rpms on all supported architectures. $ koji build --arch=x86_64 --scratch dist-f10 SRPMS/mondo-2.2.8-1.fc9.src.rpm Uploading srpm: SRPMS/mondo-2.2.8-1.fc9.src.rpm [====================================] 100% 00:00:55 1.91 MiB 35.31 KiB/sec Created task: 1066356 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1066356 Watching tasks (this may be safely interrupted)... 1066356 build (dist-f10, mondo-2.2.8-1.fc9.src.rpm): open (x86-2.fedora.phx.redhat.com) 1066357 buildArch (mondo-2.2.8-1.fc9.src.rpm, x86_64): open (x86-4.fedora.phx.redhat.com) 1066357 buildArch (mondo-2.2.8-1.fc9.src.rpm, x86_64): open (x86-4.fedora.phx.redhat.com) -> closed 0 free 1 open 1 done 0 failed 1066356 build (dist-f10, mondo-2.2.8-1.fc9.src.rpm): open (x86-2.fedora.phx.redhat.com) -> closed 0 free 0 open 2 done 0 failed 1066356 build (dist-f10, mondo-2.2.8-1.fc9.src.rpm) completed successfully Good. - SHOULD: The package functions as described. Good. - SHOULD: If scriptlets are used, those scriptlets must be sane. NA. - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. NA. - SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. NA. - SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. Good.
(In reply to comment #46) > - MUST: All filenames in rpm packages must be valid UTF-8. > > /usr/share/doc/mondo-2.2.8/AUTHORS: ASCII text > /usr/share/doc/mondo-2.2.8/ChangeLog: ASCII text > /usr/share/doc/mondo-2.2.8/COPYING: ASCII English text > /usr/share/doc/mondo-2.2.8/INSTALL: ASCII English text > /usr/share/doc/mondo-2.2.8/mondorescue-howto.html: HTML document text > /usr/share/doc/mondo-2.2.8/mondorescue-howto.pdf: PDF document, version 1.4 > /usr/share/doc/mondo-2.2.8/NEWS: UTF-8 Unicode English text, > with very long lines > /usr/share/doc/mondo-2.2.8/NEWS.old: UTF-8 Unicode English text > /usr/share/doc/mondo-2.2.8/README: ASCII English text > /usr/share/doc/mondo-2.2.8/TODO: ASCII English text > > ==> please convert to UTF-8 What do you need to convert? I think Bruno can't convert these to UTF-8. 7bit ASCII will remain ASCII also after conversion and HTML and PDF does not say aboout encoding here.
(In reply to comment #47) As mention in comment #46: for file in COPYING INSTALL NEWS README TODO AUTHORS Changelog; do => only above files should be converted if needed during the build
Ping. This request may be closed if no response from the reporter.
The latest version I made is for fedora 12 available as usual at ftp://ftp.mondorescue.org/fedora/12/mondo-2.2.9.3-1.fc12.src.rpm and spec file at ftp://ftp.mondorescue.org/fedora/12/mondo.spec For the record, I'm trying to phase out the mindi-busybox dependency for the next major release, but it won't be for this one. Could someone make a simple a clear assesment of what remains to be solved ?
Is the mindi-busybox dependency now gone for fc15 or fc16?
the mindi-busybox dep will only go away as part of version 2.2.10 of mondo. With the current 2.2.9.x tree we keep it. And we still rely heavily on afio, even if star is another possibility.
The latest versions for this package are available here: ftp://ftp.mondorescue.org/test/fedora/16/x86_64/mondo-3.0.0-0.20111114000556.fc16.src.rpm and ftp://ftp.mondorescue.org/test/fedora/16/x86_64/mondo.spec TIA for anyone helping with an update on this.
Hi! I don't want to sound very pessimistic, but I see at least two roadblocks here: - afio package (required by mondo) has been rejected from Fedora due to its licensing issues (see https://bugzilla.redhat.com/show_bug.cgi?id=449037#c26) - buffer package (also required by mindi) has been retired from Fedora on 2011-07-25 due to it being unable to build for multiple releases (see http://pkgs.fedoraproject.org/gitweb/?p=buffer.git;a=blob;f=dead.package;h=6c90bdc8768fc421bae28dabe5c08e13cbcd8a84;hb=4a2e8f905b7e3ee5d6c199b6d7e370f80cc9f18f) Does this still apply to the Mondo 3.0?
mondo 3.0.0 is requirinrg either afio or star. Hopefully with that last one, it will be possible to make progress. Concerning buffer, it's mandatory for tape usage. Now I don't understand the concept of "unable to build for multiple releases" and the link doesn't give much more info. I'm building buffer for multiple Fedora release myself without issue, so I guess it's related to something else.
buffer will need to be resubmitted for review to get it back in Fedora. If it builds fine, hopefully that won't be hard to do then.
I'm willing to resubmit it, but to avoid worthless work, I'd like to understand why iy has been droped ? (as I don't want that to happen again !) Should I use https://bugzilla.redhat.com/show_bug.cgi?id=462982 again or create a new one ?
The dead.package should have told us why it was dropped, though it doesn't make much sense in this case. But again, if it builds fine for you, I wouldn't worry about it too much. You need to open a new review.
Buffer is now submitted at https://bugzilla.redhat.com/show_bug.cgi?id=759818
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.
Spec URL: ftp://ftp.mondorescue.org/test/fedora/19/x86_64/mondo.spec SRPM URL: ftp://ftp.mondorescue.org/test/fedora/19/x86_64/mondo-3.0.420130730020540-0.fc19.src.rpm
"fedora-review -b 187318" finds a few things, in particular that "Requires: afio" is needed, but it's CLOSED/CANTFIX for legal reasons: bug 449037
I recently confirmed with a customer that afio is not needed, as star can also be used without issue anymore with mondoarchive. So for Fedora we could remove the afio dependency in favour of star (or should I use a OR clause ?)
OR clause? Not sure what that would be, but I would just drop afio if it is forbidden.
Bruno has been sponsored (fas name bcornec) therefore removing FE-NEEDSPONSOR.
pbrobinson's scratch build of linux-user-chroot?#b7afe5173cbd31b029b027b6f8a14baa5e6ce87a for epel7-archbootstrap and git://pkgs.fedoraproject.org/linux-user-chroot?#b7afe5173cbd31b029b027b6f8a14baa5e6ce87a failed http://koji.fedoraproject.org/koji/taskinfo?taskID=12089939
Now that buffer has been pushed to Fedora (Cf: https://bugzilla.redhat.com/show_bug.cgi?id=759818) I'll work on adding mindi-busybox and mindi before adding mondo itself.
To follow up with mindi's update: SRPM: ftp://ftp.mondorescue.org/test/fedora/32/x86_64/mondo-3.3.0-0.20201118013837.s3776M.fc32.src.rpm SPEC: ftp://ftp.mondorescue.org/test/fedora/32/x86_64/mondo.spec
- Use %global not %define %global srcname mondo - Group: is not used by Fedora - Not needed: BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -u -n) - Please justify this, why wouldn't it be available on all Fedora supported arches: ExclusiveArch: x86_64 i586 i386 i686 ia64 (also use %{ix86} instead of i586 i386 i686 - make %{?_smp_mflags} → %make_build - Not needed : rm -rf $RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT - make DESTDIR=$RPM_BUILD_ROOT install → %make_install - Not needed it is the default: %defattr(-,root,root) - The license file COPYING must be installed with %license not %doc %license COPYING - I can't find: ftp://ftp.mondorescue.org/test/src/mondo-3.3.0.0.20201118013837.tar.gz I'd rather use http://www.mondorescue.org/ftp/src/ - The release is weird: Release: 0.20201118013837.s3776M%{dist} It should start at 1 for a release. Why are 20201118013837 and s3776M needed? Is it extra versioning info?
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.