This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 187317 - (mindi) Review Request: mindi - Creation of emergency boot disks/CDs using your kernel, tools and modules
Review Request: mindi - Creation of emergency boot disks/CDs using your kerne...
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: 476234
Blocks: mondo
  Show dependency treegraph
 
Reported: 2006-03-29 18:28 EST by Bruno Cornec
Modified: 2016-09-19 14:18 EDT (History)
11 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)

  None (edit)
Description Bruno Cornec 2006-03-29 18:28:19 EST
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.
Comment 1 Aurelien Bompard 2006-04-17 12:28:51 EDT
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
Comment 2 Bruno Cornec 2006-04-20 04:49:03 EDT
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




Comment 3 Dennis Gilmore 2006-05-08 00:07:35 EDT
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
Comment 4 Bruno Cornec 2006-05-08 09:34:28 EDT
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 ?
Comment 5 Dennis Gilmore 2006-05-08 09:48:15 EDT
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.

Comment 6 Bruno Cornec 2006-08-07 19:44:55 EDT
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.
Comment 7 Bruno Cornec 2006-08-07 19:49:17 EDT
Oops, URL is : ftp://ftp.mondorescue.org/fedora/5/mindi-1.0.9-1.fc5.src.rpm
Comment 8 Dennis Gilmore 2006-08-13 23:52:38 EDT
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.
Comment 9 Bruno Cornec 2006-09-16 19:22:27 EDT
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.
Comment 10 Dennis Gilmore 2006-09-17 00:37:47 EDT
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.
Comment 11 Bruno Cornec 2006-09-23 05:14:00 EDT
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 ? 
Comment 12 Dennis Gilmore 2006-09-23 08:24:39 EDT
you can not provide a pre built binary.  Why can you not use the Fedora 
provided busybox? and add support for ppc?
Comment 13 Bruno Cornec 2006-09-23 13:52:10 EDT
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.
Comment 14 Dennis Gilmore 2006-09-23 23:38:12 EDT
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 

Comment 15 Tadej Janež 2006-09-27 03:13:24 EDT
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
Comment 16 Bruno Cornec 2006-09-27 05:42:11 EDT
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.
Comment 17 Dennis Gilmore 2006-12-04 07:52:28 EST
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?
Comment 18 Bruno Cornec 2006-12-04 08:03:24 EST
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.

Comment 19 Bruno Cornec 2007-01-03 20:47:11 EST
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. 
Comment 20 Aurelien Bompard 2007-02-02 10:43:50 EST
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.
Comment 21 Bruno Cornec 2007-02-09 09:39:05 EST
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.
Comment 22 Aurelien Bompard 2007-02-09 10:39:30 EST
> 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.
Comment 23 Aurelien Bompard 2007-03-23 03:19:48 EDT
ping ?
Comment 24 Bruno Cornec 2007-04-29 06:08:17 EDT
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)
Comment 25 Dennis Gilmore 2007-04-29 06:39:39 EDT
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.
Comment 26 Bruno Cornec 2007-04-29 11:18:13 EDT
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.
Comment 27 Dennis Gilmore 2007-04-29 17:41:39 EDT
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
Comment 28 Bruno Cornec 2007-05-05 20:22:08 EDT
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/

Comment 29 Jason Tibbitts 2007-06-30 17:03:03 EDT
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?
Comment 30 Tim Niemueller 2007-09-02 06:46:31 EDT
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.
Comment 31 Bruno Cornec 2007-09-07 04:54:08 EDT
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).
Comment 32 Till Maas 2007-09-08 02:48:52 EDT
> 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.
Comment 33 Bruno Cornec 2007-09-14 18:15:17 EDT
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)
Comment 34 Jason Tibbitts 2008-01-18 01:16:36 EST
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?
Comment 35 Bruno Cornec 2008-09-19 19:56:41 EDT
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
Comment 36 Bruno Cornec 2008-09-23 03:35:20 EDT
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.
Comment 37 manuel wolfshant 2008-10-02 14:50:34 EDT
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.
Comment 38 Bruno Cornec 2008-10-06 10:20:40 EDT
(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.
Comment 39 Bruno Cornec 2008-12-14 14:23:01 EST
I have made available a mindi-busybox package (Cf: https://bugzilla.redhat.com/show_bug.cgi?id=476234)
Comment 40 Bruno Cornec 2011-11-18 19:14:36 EST
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.
Comment 41 Miroslav Suchý 2013-05-13 11:03:22 EDT
Aurelien Bompard does not react for some time. Moving back to NEW so somebody else can do the review.
Comment 42 Michael Schwendt 2013-10-24 04:30:14 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 43 Michael Schwendt 2013-10-29 15:50:23 EDT
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
Comment 44 Michael Schwendt 2013-10-30 05:24:19 EDT
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.
Comment 45 Miroslav Suchý 2015-10-08 02:27:24 EDT
Bruno has been sponsored (fas name bcornec) therefore removing FE-NEEDSPONSOR.

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