Spec URL: http://people.redhat.com/dcantrel/core/partimage.spec SRPM URL: http://people.redhat.com/dcantrel/core/partimage-0.6.4-1.src.rpm Description: Partition Image is a Linux/UNIX partition imaging utility: it saves all used blocks in a partition to an image file. This image file can be compressed using gzip or bzip2 compression to save space, and even split into multiple files to be copied to movable media such as Zip disks or CD-R. The following partition types are supported: - Ext2FS (the Linux standard) - ReiserFS (a new, powerful journalling file system) - NTFS (Windows NT File System) - FAT16/32 (DOS & Windows file systems) - HPFS (OS/2 File System) This allows you to back up a full Linux/Windows system with a single operation. When problems such as viruses, crashes, or other errors occur, you just have to restore, and after several minutes your system can be restored (boot record and all your files) and fully working. This is also very useful when installing the same software on many machines: just install one of them, create an image, and just restore the image on all other machines. Then, after the first one, each machine installation can take just minutes.
I'll take this, but first do you have good justification for why this should be in Core vs Extras?
It was requested that we add this to our rescue CD, which makes sense to me. Partimage is pretty useful for recovery, backup, etc.
FWIW, I have a local (not really maintained anymore) package of 0.6.5beta2, maybe you'll find something useful worth adopting at http://cachalot.mine.nu/5/SRPMS/partimage-0.6.5-0.1.beta2.src.rpm
Yeah, you included partimaged. I was torn on whether or not to include it. I'm not convinced it's a good idea, but maybe I'll rework mine and turn partimaged back on. Thanks.
Jesse, I've updated the partimage package now. Enabled partimaged in a subpackage, etc, stuff, whatever. Have a look and then let me know when I can move it to devel-cvs.
Bad: - Buildroot should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - Server requires should probably be %{name} = %{version}-%{release} - Doesn't build on x86_64: fs_xfs.h:115: error: conflicting declaration 'typedef long long int __int64_t' /usr/include/bits/types.h:47: error: '__int64_t' has a previous declaration as 'typedef long int __int64_t' fs_xfs.h:116: error: conflicting declaration 'typedef long long unsigned int __uint64_t' /usr/include/bits/types.h:48: error: '__uint64_t' has a previous declaration as 'typedef long unsigned int __uint64_t' make[4]: *** [fs_xfs.o] Error 1 rpmlint isn't very happy w/ the 32bit package either. W: partimage conffile-without-noreplace-flag /etc/pam.d/partimage W: partimage conffile-without-noreplace-flag /etc/security/console.apps/partimage E: partimage use-old-pam-stack /etc/pam.d/partimage E: partimage use-old-pam-stack /etc/pam.d/partimage W: partimage-server conffile-without-noreplace-flag /etc/logrotate.d/partimaged W: partimage-server conffile-without-noreplace-flag /etc/pam.d/partimaged W: partimage-server conffile-without-noreplace-flag /etc/rc.d/init.d/partimaged E: partimage-server non-readable /etc/partimaged/partimagedusers 0600 E: partimage-server executable-marked-as-config-file /etc/rc.d/init.d/partimaged E: partimage-server incoherent-logrotate-file /etc/logrotate.d/partimaged W: partimage-server file-not-in-%lang /usr/share/man/en/man5/partimagedusers.5.gz W: partimage-server file-not-in-%lang /usr/share/man/en/man8/partimaged.8.gz W: partimage-server incoherent-subsys /etc/rc.d/init.d/partimaged $prog W: partimage-server incoherent-init-script-name partimaged E: partimage-server use-old-pam-stack /etc/pam.d/partimaged E: partimage-server use-old-pam-stack /etc/pam.d/partimaged E: partimage-server use-old-pam-stack /etc/pam.d/partimaged Indifferent: - %description is a bit long winded... - chmod of pam.d/partimaged followed by install -m seems redundant. NEEDSWORK
(In reply to comment #6) > Bad: > - Buildroot should be %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Corrected. > - Server requires should probably be %{name} = %{version}-%{release} Had that originally. Changed back. > - Doesn't build on x86_64: Does now. > rpmlint isn't very happy w/ the 32bit package either. Well, it should quit being so pedantic. > W: partimage conffile-without-noreplace-flag /etc/pam.d/partimage > W: partimage conffile-without-noreplace-flag /etc/security/console.apps/partimage Added noreplace. > E: partimage use-old-pam-stack /etc/pam.d/partimage > E: partimage use-old-pam-stack /etc/pam.d/partimage Corrected. > W: partimage-server conffile-without-noreplace-flag /etc/logrotate.d/partimaged > W: partimage-server conffile-without-noreplace-flag /etc/pam.d/partimaged > W: partimage-server conffile-without-noreplace-flag /etc/rc.d/init.d/partimaged Added noreplace. > E: partimage-server non-readable /etc/partimaged/partimagedusers 0600 Corrected. > E: partimage-server executable-marked-as-config-file /etc/rc.d/init.d/partimaged Not marking it as a config file. > E: partimage-server incoherent-logrotate-file /etc/logrotate.d/partimaged Corrected. > W: partimage-server file-not-in-%lang /usr/share/man/en/man5/partimagedusers.5.gz > W: partimage-server file-not-in-%lang /usr/share/man/en/man8/partimaged.8.gz Corrected. > W: partimage-server incoherent-subsys /etc/rc.d/init.d/partimaged $prog > W: partimage-server incoherent-init-script-name partimaged Corrected. > E: partimage-server use-old-pam-stack /etc/pam.d/partimaged > E: partimage-server use-old-pam-stack /etc/pam.d/partimaged > E: partimage-server use-old-pam-stack /etc/pam.d/partimaged Corrected. > Indifferent: > - %description is a bit long winded... Removed last two paragraphs. People don't read anyway. > - chmod of pam.d/partimaged followed by install -m seems redundant. Look more closely. There are two pam.d files: partimage and partimaged. One I have to change the SYSCONFDIR in during installation, so I use sed and chmod. The other I can install directly, so I use install. > NEEDSWORK Grade me again, TA. Package and spec file can be found at http://people.redhat.com/dcantrel/core/
Well, it manages to build on x86_64, but failed on i386. *shrug* trying one more time. Other changes looked good, and rpmlint is happy again.
Ha! I'm an idiot. Fixed. Try again, por favor.
Builds and lint is clean. APPROVED Proceed with the next steps on PackageListProcess.
initscripts really shouldn't be noreplace (arguably, they shouldn't be %config). Perhaps we need to fix rpmlint in this regard.
rpmlint, I trusted you... Actually I was a bit confused about that as well, but I said, "eh, whatever, I'll change it." I will remove the %config for the initscripts. Course, if Jeremy is crushing and destroying all my hopes of having this package included in core...well, it's all wasted effort.
(In reply to comment #12) > rpmlint, I trusted you... > > Actually I was a bit confused about that as well, but I said, "eh, whatever, > I'll change it." > > I will remove the %config for the initscripts. Course, if Jeremy is crushing > and destroying all my hopes of having this package included in core...well, it's > all wasted effort. FWIW, I agree with rpmlint; initscripts shouldn't be %config - any configurability can be handled using settings in /etc/sysconfig/packagename, which can be %config(noreplace)
The way rpmlint should work with issues related to init scripts is that it should be whining about: - any executable which is marked as %config* - any non-executable file in /etc which is not marked as %config* - any file which is marked as %config but not (noreplace) ...so the only whineless solution for init scripts at the moment is to not mark them as %config*, and obviously install them executable. If this is not what happens, or if you have improvement suggestions, please file a bug against rpmlint.
Where are we with this, I heard we may not be including due to NTFS?
Dump it. I don't want to gut the NTFS code from partimage and then include that because it would (a) be annoying to maintain, (b) be less featureful than what people have asked for, and (c) result in an endless stream of emails from people asking to enable NTFS support.
OK, now that ntfs support has been added to extras, is it time to reconsider partimage? The addition of ntfs (ntfs-3g) to extras seems to have taken place in the October 2006 timeframe (late in the FC6 development cycle). There appears to have been some Red Hat internal discussion of NTFS to allow its addition to extras but I have been unable to find anything. What is the different between the ntfs-3g and ntfsprogs in extras and the ntfs support in partimage? If I understand correctly, the same rules apply to both Fedora Extras and Fedora Core ... e.g., no MP3 stuff. If ntfs any different? Is the ntfs support in partimage any different that that in ntfs-3g? Granted, ntfs-3g needs a lot more functionality since partimage only needs to handle ntfs partitions enough to backup and restore used blocks. I would be happy to see it added to extras but I really believe it needs to be added to Core so that it can be on the rescuecd ... I have built my own versions of the rescuecd which adds partimage and have found this to be very useful for backup and restore. If (somehow) the ntfs support in partimage is different from that in ntfs-3g, what changes in partimage would it take to make it as acceptable as ntfs-3g?
The guidelines have changed, ntfs isn't a forbidden item anymore. What have changed is that the patents are now in the hands of some organization which bought it to have free software not being sued and not to sue (to my understanding).
Partimage NTFS code is unsafe, experimental, abandoned for years and 100% different from both ntfsprogs and ntfs-3g. Ntfsprogs has a safe NTFS imaging tool, called ntfsclone, which works stable for over three years. Some backup tools (e.g. Debian Mondo) replaced Partimage NTFS support with ntfsclone which approach was also agreed upon to be done between the two independent teams, however it got never realized. OIN protects NTFS, even if no NTFS patent was found or pointed out by anybody ever in any country with which any of the Linux NTFS work would potentially conflict or violate.
David, are you interested in submitting this again? If not I'm going to close the ticket.
Closing as dead review.
Now that partimage uses ntfs-3g, is it worth revisiting this package?