Add misc patches from Fedora, including one to fix #46847 by Vlastimil Holer. Do not generate device nodes since there is no point and it makes selinux angry #73928 by Bryan Stine. Clean up the ebuild in general and change the -fPIC filter to a proper PIC patch.

(Portage version: 2.0.51-r15)

1 files changed, 59 insertions, 0 deletions

diff --git a/sys-fs/raidtools/files/raidtools-1.00.3-gcc33.patch b/sys-fs/raidtools/files/raidtools-1.00.3-gcc33.patch
new file mode 100644
index 000000000000..d8a78901dfda
--- /dev/null
+++ b/sys-fs/raidtools/files/raidtools-1.00.3-gcc33.patch
@@ -0,0 +1,59 @@
+--- raidtools-1.00.3/mkraid.c.gcc33	2003-05-22 15:59:57.000000000 -0400
++++ raidtools-1.00.3/mkraid.c	2003-05-22 16:00:38.000000000 -0400
+@@ -171,31 +171,31 @@
+     if (old_force_flag && (func == mkraid)) {
+ 	fprintf(stderr, 
+ 
+-"
+- WARNING!
+-
+- NOTE: if you are recovering a double-disk error or some other failure mode
+- that made your array unrunnable but data is still intact then it's strongly
+- recommended to use the lsraid utility and to read the lsraid HOWTO.
+-
+- If your RAID array holds useful and not yet backed up data then --force
+- and the hot-add/hot-remove functionality should be used with extreme care!
+- If your /etc/raidtab file is not in sync with the real array configuration,
+- then --force might DESTROY ALL YOUR DATA. It's especially dangerous to use
+- -f if the array is in degraded mode.
+-
+- If your /etc/raidtab file matches the real layout of on-disk data then
+- recreating the array will not hurt your data, but be aware of the risks
+- of doing this anyway: freshly created RAID1 and RAID5 arrays do a full
+- resync of their mirror/parity blocks, which, if the raidtab is incorrect,
+- the resync will wipe out data irrecoverably. Also, if your array is in
+- degraded mode then the raidtab must match the degraded config exactly,
+- otherwise you'll get the same kind of data destruction during resync.
+- (see the failed-disk raidtab option.) You have been warned!
+-
+- [ If your array holds no data, or you have it all backed up, or if you
+- know precisely what you are doing and you still want to proceed then use
+- the --really-force (or -R) flag. ]
++"\n\
++ WARNING!\n\
++\n\
++ NOTE: if you are recovering a double-disk error or some other failure mode\n\
++ that made your array unrunnable but data is still intact then it's strongly\n\
++ recommended to use the lsraid utility and to read the lsraid HOWTO.\n\
++\n\
++ If your RAID array holds useful and not yet backed up data then --force\n\
++ and the hot-add/hot-remove functionality should be used with extreme care!\n\
++ If your /etc/raidtab file is not in sync with the real array configuration,\n\
++ then --force might DESTROY ALL YOUR DATA. It's especially dangerous to use\n\
++ -f if the array is in degraded mode.\n\
++\n\
++ If your /etc/raidtab file matches the real layout of on-disk data then\n\
++ recreating the array will not hurt your data, but be aware of the risks\n\
++ of doing this anyway: freshly created RAID1 and RAID5 arrays do a full\n\
++ resync of their mirror/parity blocks, which, if the raidtab is incorrect,\n\
++ the resync will wipe out data irrecoverably. Also, if your array is in\n\
++ degraded mode then the raidtab must match the degraded config exactly,\n\
++ otherwise you'll get the same kind of data destruction during resync.\n\
++ (see the failed-disk raidtab option.) You have been warned!\n\
++\n\
++ [ If your array holds no data, or you have it all backed up, or if you\n\
++ know precisely what you are doing and you still want to proceed then use\n\
++ the --really-force (or -R) flag. ]\n\
+ ");
+ 	return EXIT_FAILURE;
+     }