You are not logged in.

#1 2013-06-15 15:50:27

Registered: 2012-11-17
Posts: 62

Notes on mindi and mondo

The final two packages (fourth and fifth) that I was going to look at -- per the original post -- were aur/mindi (2.1.2-1) and aur/mondo (3.0.2-1). Both of these are part of the MondoRescue project (backup/disaster recovery software), and both currently install binaries under /usr/sbin.

I did indeed plan to look at these, but have decided otherwise for now. There are a few reasons for that decision; I'm not currently using these packages -- having moved to rsync for that part of my backup strategy -- and, as far as I know, I can't properly test mindi (my system uses GPT which, if mindi is capable of working with that now to make the backup bootable, it certainly didn't used to be, and thus I've always had it disabled as part of my mondo invocation command... which kinda defeats the purpose wink). I had kept them installed, however, since MondoRescue is a nice package, and I kept the final backups I did with it for a time.

I have flagged both of these (well, one; the other was already flagged) and did have a crack at fixing up mindi, but it also seems resolving the issues here will be far from straightforward:

(1) mindi depends upon aur/mindi-busybox, which currently hits errors when you 'makepkg'. I was able to work around this fairly simply (please find the details in a follow-up) and that package does not install any binaries (so is not affected by the /usr/bin consolidation), however this will complicate life for others involved in this until it is fixed in AUR.

(2) mindi itself appears to have a raft of hard-coded references through its codebase to locations other than /usr/bin; you can't just bulk replace all of these, as some of them are not references to locations on the installed system, but to locations on what becomes the bootable backup (which, of course, has no need to follow the /usr/bin consolidation policy). There is also no configure step, as there's nothing to 'make'; the programs are all 'sh' or 'perl' scripts.

My attempt -- just modifying the "" and relying on the symlinks from core/filesystem to do the rest, using latest mindi, and mindi-busybox fixed per above -- ended up with mindi seeming to work, but either erroring out or getting 'stuck' in a loop of some kind (the documentation indicates mindi should take up to five minutes, but I have left it for multiples of that and it just sits there, spawning/exiting processes of itself) depending upon my answer to its initial question. Whether that's due to my changes, or my using GPT, or something else, I don't know at present.

(mondo also appears to have some hard-coded references, but substantially less in proportion to those of mindi; more importantly, it also has a configure step...)

(3) These packages also need to be updated from upstream; mindi is up to 2.1.5, mondo is up to 3.0.3, and while mindi-busybox has the same version, it's clear the upstream package has been changed. The PKGBUILDs for these need some work to come up to current standards, and the resulting package(s) -- at least for mindi and mondo -- also throw a stack of warnings in namcap, some of which are contradictory (e.g. unneeded deps which are quite definitely needed). Finally, when I actually went to flag the first two packages, I discovered mondo had been flagged since mid-April; the last AUR activity by the maintainer concerned -- who maintains all three of these packages -- was almost a year ago, in July 2012.

What's probably needed here is an active maintainer involved with both the ArchLinux community and the upstream developers (or, alternatively, to lure somone upstream to ArchLinux big_smile), and it does seem that's what these packages have had in the past; upstream has been willing to accept patches specific to ArchLinux such that the tools work correctly, and indeed, I had no actual issues with them (apart from GPT support) until the /usr/bin consolidation. I could continue working at it, but given that I don't currently use these packages, can't guarantee active participation and probably don't have enough experience yet to really do patching work at this level, I'm probably not the right choice to take this on. Also, the established maintainer hasn't yet been contacted about their involvement, to my knowledge (I'm willing to try and get in touch with them if they don't respond to the flags, but beyond that...).

So, I'm putting this out here for now, partly as information (since I did promise to look at these) and partly to capture the attention of anyone who is a MondoRescue user or developer that may come across this post. I'll post a follow-up should I get the opportunity to do more than what I have done (or tried to do thusfar), but for the moment, this will need to rest in hands other than mine.

Last edited by aexoxea (2013-06-16 03:17:08)


#2 2013-06-15 15:51:23

Registered: 2012-11-17
Posts: 62

Re: Notes on mindi and mondo

Further to the above, I include below changes to the aur/mindi-busybox package that enabled it to build successfully for me (and which I will note on the AUR package page).

First, I removed the shell_common.patch file; it fails to apply, because upstream has fixed the issue.

Second, I modified the PKGBUILD per the following diff, per the above, namcap report on the package, and current packaging standards:

--- PKGBUILD	2012-07-08 19:39:52.000000000 +1000
+++ PKGBUILD	2013-06-16 01:45:49.928438387 +1000
@@ -6,22 +6,25 @@
 arch=('i686' 'x86_64')
 #There are two official mirrors. If one is not working try the other. The seems faster.
-	shell_common.patch)
-	'ec7280e7573eb12cbb9cc6707468ef01')
 build() {
   cd "$srcdir/$pkgname-$pkgver"
-  patch -p1 < ../shell_common.patch
-  make oldconfig || return 1
-  make busybox || return 1
-  make CONFIG_PREFIX=$pkgdir/usr/lib/mindi/rootfs install
+  make oldconfig
+  make busybox
-# vim:set ts=2 sw=2 et:
+package() {
+  cd "$srcdir/$pkgname-$pkgver"
+  make "CONFIG_PREFIX=$pkgdir/usr/lib/mindi/rootfs" install

As with the similar work I have done on other AUR packages lately, I tried to modify the original package as little as possible, and any (constructive) feedback is welcome.

Last edited by aexoxea (2013-06-16 03:23:14)


Board footer

Powered by FluxBB