Bug 187318 - (mondo) Review Request: mondo - A program which a Linux user can utilize to create a rescue/restore CD/tape
Review Request: mondo - A program which a Linux user can utilize to create a ...
Status: NEW
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
:
Depends On: mindi afio 759818
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-29 18:31 EST by Bruno Cornec
Modified: 2016-09-19 14:19 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
corrected spec (67.05 KB, text/plain)
2006-08-13 23:36 EDT, Dennis Gilmore
no flags Details

  None (edit)
Description Bruno Cornec 2006-03-29 18:31:14 EST
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
Comment 1 Brian Pepple 2006-05-07 16:16:03 EDT
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
Comment 2 Dennis Gilmore 2006-05-07 23:46:10 EDT
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} ?

Comment 3 Bruno Cornec 2006-05-08 10:05:23 EDT
(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.
Comment 4 Dennis Gilmore 2006-05-08 10:10:13 EDT
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
Comment 5 Bruno Cornec 2006-05-08 10:25:22 EDT
(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.
Comment 6 Bruno Cornec 2006-05-08 10:26:52 EDT
(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.

Comment 7 Aurelien Bompard 2006-05-08 10:38:27 EDT
> 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)
Comment 8 Dennis Gilmore 2006-05-08 10:43:04 EDT
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
Comment 9 Brian Pepple 2006-05-08 10:50:01 EDT
(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.
Comment 10 Dennis Gilmore 2006-07-31 22:27:33 EDT
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.
Comment 11 Bruno Cornec 2006-08-01 20:07:56 EDT
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.
Comment 12 Bruno Cornec 2006-08-07 19:43:38 EDT
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
Comment 13 Dennis Gilmore 2006-08-13 23:34:58 EDT
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
Comment 14 Dennis Gilmore 2006-08-13 23:36:36 EDT
Created attachment 134115 [details]
corrected spec
Comment 15 Herve Lemaitre 2006-12-04 05:28:35 EST
hello

No activity logged since August 2006. What's is the status of inclusion of Mondo
rescue into Fedora Extras ? 
Comment 16 Bruno Cornec 2006-12-04 07:58:51 EST
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.
Comment 17 Bruno Cornec 2007-01-03 20:54:18 EST
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
Comment 19 Bruno Cornec 2007-04-29 06:22:35 EDT
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.
Comment 20 Tim Niemueller 2007-09-02 06:48:11 EDT
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?
Comment 21 Jan ONDREJ 2007-09-06 03:44:45 EDT
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@mondorescue.org> 2.2.4-1.fc7              
to:
  * Fri Jul 06 2007 Bruno Cornec <bruno@mondorescue.org> - 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.
Comment 22 Till Maas 2007-09-08 02:40:25 EDT
FE-NEW does not need to be blocked anymore.
Comment 23 Bruno Cornec 2007-09-14 18:22:33 EDT
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.
Comment 24 Jan ONDREJ 2007-09-15 02:21:08 EDT
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. :-)
Comment 25 Debarshi Ray 2007-12-25 11:49:29 EST
Ping?
Comment 26 Jason Tibbitts 2008-01-25 12:08:57 EST
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.
Comment 27 Bruno Cornec 2008-01-27 14:57:55 EST
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
Comment 28 Jason Tibbitts 2008-03-01 14:18:38 EST
It looks like Bruno neglected to check the "I am providing the requested
information" box, and so this is improperly set as NEEDINFO.
Comment 29 Jason Tibbitts 2008-04-29 18:15:04 EDT
Unfortunately the URL in comment 27 is invalid.
Comment 30 Bruno Cornec 2008-04-30 07:45:32 EDT
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)
Comment 31 Jason Tibbitts 2008-05-10 18:24:17 EDT
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?
Comment 32 Bruno Cornec 2008-05-29 19:21:56 EDT
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.
Comment 33 Bruno Cornec 2008-09-19 19:57:18 EDT
Buffer is now submitted at https://bugzilla.redhat.com/show_bug.cgi?id=462982
Comment 34 Jan ONDREJ 2008-09-23 01:35:12 EDT
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.
Comment 35 Bruno Cornec 2008-09-23 03:39:39 EDT
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
Comment 36 manuel wolfshant 2008-12-12 10:09:09 EST
restoring NEW as status, according to its history no one has ever formally decided to review the bug.
Comment 37 Bruno Cornec 2008-12-12 10:18:09 EST
mondo may work without afio, using star already in fedora, so removing the link.
Will regenerate packages accordingly asap.
Comment 38 manuel wolfshant 2008-12-12 10:46:57 EST
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.
Comment 39 MartinG 2009-01-15 08:00:29 EST
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?
Comment 40 Bruno Cornec 2009-01-15 19:02:18 EST
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.
Comment 41 MartinG 2009-01-16 15:48:32 EST
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
Comment 42 MartinG 2009-01-16 17:02:49 EST
...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...?
Comment 43 Bruno Cornec 2009-01-16 18:16:25 EST
(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.
Comment 44 MartinG 2009-01-16 19:02:16 EST
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.
Comment 45 manuel wolfshant 2009-01-17 05:27:02 EST
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.
Comment 46 Gratien D'haese 2009-01-19 09:36:45 EST
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.
Comment 47 Jan ONDREJ 2009-01-19 11:38:52 EST
(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.
Comment 48 Gratien D'haese 2009-01-21 10:28:53 EST
(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
Comment 49 Caius Chance 2010-04-30 01:52:07 EDT
Ping. This request may be closed if no response from the reporter.
Comment 50 Bruno Cornec 2010-04-30 13:13:53 EDT
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 ?
Comment 51 Gratien D'haese 2011-08-29 08:54:34 EDT
Is the mindi-busybox dependency now gone for fc15 or fc16?
Comment 52 Bruno Cornec 2011-08-30 05:52:19 EDT
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.
Comment 53 Bruno Cornec 2011-11-18 19:16:04 EST
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.
Comment 54 Tadej Janež 2011-11-20 15:27:50 EST
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?
Comment 55 Bruno Cornec 2011-11-20 20:26:53 EST
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.
Comment 56 Orion Poplawski 2011-11-21 16:11:37 EST
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.
Comment 57 Bruno Cornec 2011-11-22 03:53:09 EST
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 ?
Comment 58 Orion Poplawski 2011-11-22 11:33:10 EST
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.
Comment 59 Bruno Cornec 2011-12-03 20:01:49 EST
Buffer is now submitted at https://bugzilla.redhat.com/show_bug.cgi?id=759818
Comment 60 Michael Schwendt 2013-10-24 04:29:43 EDT
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.
Comment 62 Michael Schwendt 2013-11-01 07:17:05 EDT
"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
Comment 63 Bruno Cornec 2013-12-03 00:43:27 EST
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 ?)
Comment 64 Orion Poplawski 2013-12-03 18:28:17 EST
OR clause?  Not sure what that would be, but I would just drop afio if it is forbidden.
Comment 65 Miroslav Suchý 2015-10-08 02:27:41 EDT
Bruno has been sponsored (fas name bcornec) therefore removing FE-NEEDSPONSOR.
Comment 66 Upstream Release Monitoring 2015-12-06 13:25:28 EST
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
Comment 67 Bruno Cornec 2016-02-07 20:20:07 EST
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.

Note You need to log in before you can comment on or make changes to this bug.