This is my first package; sponsor, please. Spec URL: http://www.charlescurley.com/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO.spec SRPM URL: http://www.charlescurley.com/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO-2.3-1.fc7.src.rpm Description: A set of scripts to back up and restore a minimal system for bare metal restoration. They are useful on i386 systems. Patches for others are welcome. Install this package on clients, and the documentation package where you want it. This bug replaces bug 250315, which somehow got marked "closed".
*** Bug 250315 has been marked as a duplicate of this bug. ***
New SRPM: http://www.charlescurley.com/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO-2.3-2.fc7.src.rpm The spec, revised, is at the same place: http://www.charlescurley.com/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO.spec
I'm not sponsored, so this isn't official: ? - Package meets naming and packaging guidelines --> Seems more a set of scripts than documentation... although I could be looking at what it does all wrong :P Consider renaming after script-suite? OK - Spec file matches base package name. OK? - Spec has consistant macro usage. --> $RPM_BUILD_ROOT could be macro-ified as %{buildroot} OK - License field in spec matches OK - License is GPL OK - License file is included in package OK - Spec in American English OK - Spec is legible. NOT OK - Sources SHOULD match upstream md5sum --> Source: e44ce87defb0b7f3688dbbded79bedc4 Package: e44ce87defb0b7f3688dbbded79bedc4 OK - Package has correct buildroot. OK - Package has %defattr and permissions on files is good. ? - Changelog section is correct. --> Not sure if one should put such direct references to the specfile in %changelog... but it's probably bad form to change the %changelog after the fact...
Thank you, Mr. Boyle. > ? - Package meets naming and packaging guidelines > --> Seems more a set of scripts than documentation... although I could be > looking at what it does all wrong :P Consider renaming after script-suite? Hmmm. The current name is the name of the document at the Linux Documentation Project, and I figured that consistency would be a good idea. The main package is some of the scripts (more are to come), and the -doc subpackage is the original HOWTO in various formats. I could make the docs the main package and put the scripts into a -scripts subpackage, I suppose, but the current naming and subpackaging are consistent with current Fedora usage. I'm open to suggestions here. > OK? - Spec has consistant macro usage. > --> $RPM_BUILD_ROOT could be macro-ified as %{buildroot} OK, done. It should show up in the next version. > NOT OK - Sources SHOULD match upstream md5sum > --> Source: e44ce87defb0b7f3688dbbded79bedc4 Package: > e44ce87defb0b7f3688dbbded79bedc4 I'm not sure where that came from. In any case, it should go away as soon as I put new packages up on my server. > ? - Changelog section is correct. > --> Not sure if one should put such direct references to the specfile in > %changelog... but it's probably bad form to change the %changelog after the fact... That was the reason for the new package version, and the sole change. As with this one. Again, new SRPM: http://www.charlescurley.com/Linux-Complete-Backup-and-Recovery-HOWTO/srpms/Linux-Complete-Backup-and-Recovery-HOWTO-2.3-3.fc7.src.rpm And the revised spec is at the usual: http://www.charlescurley.com/Linux-Complete-Backup-and-Recovery-HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO.spec BTW, since my web page is pretty much automated, and comments for this bugzilla entry are not, the web page (http://www.charlescurley.com/Linux-Complete-Backup-and-Recovery-HOWTO.html) is authoritative for the most recent version, not bugzilla.
Are you still interested in this or is it dead? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It's dead.