Re: Bug#660400: hal: FTBFS on kfreebsd-*
tag 660400 patch pending
thanks
Steven Chamberlain (19/02/2012):
> This is due to 'unsafe' format strings being supplied to printf in
> FreeBSD-specific code, revealed by the -Wformat-security build hardening
> option. I've attached a patch to fix this.
Thanks, uploaded right away since we have many blockers for the
freebsd-libs transition, I hope Michael will be fine with my
being in a hurry. The patch for my NMU is attached.
Also: Thanks to IRILL for sponsoring this BSP in Paris.
Mraw,
KiBi.
diff -Nru hal-0.5.14/debian/changelog hal-0.5.14/debian/changelog
--- hal-0.5.14/debian/changelog 2011-08-12 14:41:15.0 +
+++ hal-0.5.14/debian/changelog 2012-02-19 04:44:41.0 +
@@ -1,3 +1,14 @@
+hal (0.5.14-7.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Apply patch from Steven Chamberlain (thanks!) to fix FTBFS on
+kfreebsd-* during the rebuild for the unannounced freebsd-libs
+transition, due to hardening options (-Werror=format-security):
+55-kfreebsd-format-security.patch (Closes: #660400)
+ * Set urgency to “high” for the RC bug fix.
+
+ -- Cyril Brulebois Sun, 19 Feb 2012 04:22:09 +
+
hal (0.5.14-7) unstable; urgency=low
* debian/control
diff -Nru hal-0.5.14/debian/patches/55-kfreebsd-format-security.patch hal-0.5.14/debian/patches/55-kfreebsd-format-security.patch
--- hal-0.5.14/debian/patches/55-kfreebsd-format-security.patch 1970-01-01 00:00:00.0 +
+++ hal-0.5.14/debian/patches/55-kfreebsd-format-security.patch 2012-02-19 04:24:52.0 +
@@ -0,0 +1,39 @@
+Description: fixes for -Wformat-security in FreeBSD-specific code
+Author: Steven Chamberlain
+Bug-Debian: http://bugs.debian.org/660400
+
+Index: hal-0.5.14/hald/freebsd/hf-acpi.c
+===
+--- hal-0.5.14.orig/hald/freebsd/hf-acpi.c 2012-02-19 03:28:06.0 +
hal-0.5.14/hald/freebsd/hf-acpi.c 2012-02-19 03:29:18.0 +
+@@ -520,7 +520,7 @@
+
+ g_return_val_if_fail(HAL_IS_DEVICE(parent), NULL);
+
+- if (get_sysctl == NULL || ! hf_has_sysctl(get_sysctl))
++ if (get_sysctl == NULL || ! hf_has_sysctl("%s", get_sysctl))
+ return NULL;
+ device = hf_device_new(parent);
+
+@@ -536,7 +536,7 @@
+ {
+ int bmax;
+
+- if (hf_get_int_sysctl(&bmax, NULL, max_sysctl))
++ if (hf_get_int_sysctl(&bmax, NULL, "%s", max_sysctl))
+ hal_device_property_set_int(device, "laptop_panel.num_levels", bmax);
+ else
+ hal_device_property_set_int(device, "laptop_panel.num_levels", max_levels);
+Index: hal-0.5.14/hald/freebsd/hf-devtree.c
+===
+--- hal-0.5.14.orig/hald/freebsd/hf-devtree.c 2012-02-19 03:33:18.0 +
hal-0.5.14/hald/freebsd/hf-devtree.c 2012-02-19 03:33:49.0 +
+@@ -556,7 +556,7 @@
+
+ devfile = g_strdup_printf("/dev/%s%i", driver, unit);
+ if (g_file_test(devfile, G_FILE_TEST_EXISTS))
+-hf_device_property_set_string_printf(device, "freebsd.device_file", devfile);
++hf_device_property_set_string_printf(device, "freebsd.device_file", "%s", devfile);
+ g_free(devfile);
+ }
+
diff -Nru hal-0.5.14/debian/patches/series hal-0.5.14/debian/patches/series
--- hal-0.5.14/debian/patches/series 2011-08-12 13:47:11.0 +
+++ hal-0.5.14/debian/patches/series 2012-02-19 04:25:11.0 +
@@ -13,4 +13,5 @@
52-kfreebsd-libufs.patch
53-kfreebsd-blkid.patch
54-kfreebsd-libusb2.patch
+55-kfreebsd-format-security.patch
60-create-run-hald-directory.patch
signature.asc
Description: Digital signature
Re: hal: FTBFS on kfreebsd-*
Hi,
This is due to 'unsafe' format strings being supplied to printf in
FreeBSD-specific code, revealed by the -Wformat-security build hardening
option. I've attached a patch to fix this.
Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Description: fixes for -Wformat-security in FreeBSD-specific code
Author: Steven Chamberlain
Bug-Debian: http://bugs.debian.org/660400
Index: hal-0.5.14/hald/freebsd/hf-acpi.c
===
--- hal-0.5.14.orig/hald/freebsd/hf-acpi.c 2012-02-19 03:28:06.0 +
+++ hal-0.5.14/hald/freebsd/hf-acpi.c 2012-02-19 03:29:18.0 +
@@ -520,7 +520,7 @@
g_return_val_if_fail(HAL_IS_DEVICE(parent), NULL);
- if (get_sysctl == NULL || ! hf_has_sysctl(get_sysctl))
+ if (get_sysctl == NULL || ! hf_has_sysctl("%s", get_sysctl))
return NULL;
device = hf_device_new(parent);
@@ -536,7 +536,7 @@
{
int bmax;
- if (hf_get_int_sysctl(&bmax, NULL, max_sysctl))
+ if (hf_get_int_sysctl(&bmax, NULL, "%s", max_sysctl))
hal_device_property_set_int(device, "laptop_panel.num_levels", bmax);
else
hal_device_property_set_int(device, "laptop_panel.num_levels", max_levels);
Index: hal-0.5.14/hald/freebsd/hf-devtree.c
===
--- hal-0.5.14.orig/hald/freebsd/hf-devtree.c 2012-02-19 03:33:18.0 +
+++ hal-0.5.14/hald/freebsd/hf-devtree.c 2012-02-19 03:33:49.0 +
@@ -556,7 +556,7 @@
devfile = g_strdup_printf("/dev/%s%i", driver, unit);
if (g_file_test(devfile, G_FILE_TEST_EXISTS))
-hf_device_property_set_string_printf(device, "freebsd.device_file", devfile);
+hf_device_property_set_string_printf(device, "freebsd.device_file", "%s", devfile);
g_free(devfile);
}
Re: Bug#561076: hal: FTBFS on kfreebsd-* with 8.x kernel headers
I would very much appreciate if you ore Aurelien could review the kfreebsd patches (debian/patches/5?-kfreebsd-*.patch). Their patch headers should contain a meaningful description. Please replace 54-kfreebsd-libusb2.patch by attached one. The expectation for logic is that either both __FreeBSD_version and __FreeBSD_kernel_version are defined to the same value or only one of them is defined and the remaining is undefined (evaluated as zero). So these test should be #if (__FreeBSD_version < 800092) && (__FreeBSD_kernel_version < 800092) #if (__FreeBSD_version >= 800064) || (__FreeBSD_kernel_version >= 800064) E.g. in debian/patches/54-kfreebsd-libusb2.patch I only changed the minimum of "#if __FreeBSD_version" to make it compile, but the code contains a lot more #ifdefs which have no distinction for kfreebsd (grep __FreeBSD_version hald -R) and I don't know if they should be updated too. We cannot easily replace the addon-mouse.c/probe-mouse.c as we do not have kinfo_getfile(). Petr 54-kfreebsd-libusb2.patch.gz Description: Binary data
Re: Bug#561076: hal: FTBFS on kfreebsd-* with 8.x kernel headers
Petr Salinger wrote: >> Regarding 0.5.14 (which I plan to upload soon): Do you want me to enable the >> new >> usb2 backend (given we get it to compile) or the old usb backend? > > I personally prefer the new one, CC-ing -bsd to get broader opinion. Very well then. I put up preliminary packages of 0.5.14 up at [1]. The should compile successfully on linux and kfreebsd. I would very much appreciate if you ore Aurelien could review the kfreebsd patches (debian/patches/5?-kfreebsd-*.patch). Their patch headers should contain a meaningful description. E.g. in debian/patches/54-kfreebsd-libusb2.patch I only changed the minimum of "#if __FreeBSD_version" to make it compile, but the code contains a lot more #ifdefs which have no distinction for kfreebsd (grep __FreeBSD_version hald -R) and I don't know if they should be updated too. I'm awaiting your response so I can go on with the upload of 0.5.14-1. Thanks, Michael [1] http://debs.michaelbiebl.de/hal/ -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#561076: hal: FTBFS on kfreebsd-* with 8.x kernel headers
Petr Salinger (14/12/2009): > I expect Aurelien/Cyril has installed it on buildd already or he > will install it very soon. Already installed as soon as they were installable (at least as far as I can tell). In case of FTBFS, I'm usually aware of ongoing glibc and kfreebsd headers packages needing an update, so I trigger give backs once the chroots are up to date. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#561076: hal: FTBFS on kfreebsd-* with 8.x kernel headers
make[6]: Entering directory `/tmp/hal-0.5.13/hald/freebsd/probing' probe-hiddev.c:32:32: error: legacy/dev/usb/usb.h: No such file or directory Do I need to adjust the build dependencies, too? You are so quick ;-) Aurelien uploaded the needed fix into unstable this morning. kfreebsd-kernel-headers (0.46) unstable; urgency=low [ Petr Salinger ] * Add * Add #include into -- Aurelien Jarno Mon, 14 Dec 2009 07:36:36 +0100 I expect Aurelien/Cyril has installed it on buildd already or he will install it very soon. Regarding 0.5.14 (which I plan to upload soon): Do you want me to enable the new usb2 backend (given we get it to compile) or the old usb backend? I personally prefer the new one, CC-ing -bsd to get broader opinion. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
