Skip to contentSkip to conversation

xorg-server: point localstatedir to /var

PATCH New Gustavo Zacarias 3 participants 8 messages Mar 10, 2011

lore
Share & tools
lore
#0 lore raw

PATCH 1/3 xorg-server: point localstatedir to /var

We don't want logs to end up in /usr/var/log

---
 .../xserver_xorg-server/xserver_xorg-server.mk     |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
package/x11r7/xserver_xorg-server/xserver_xorg-server.mk +1 -1
index 6dc1705..0311483 100644
@@ -60,7 +60,7 @@ XSERVER_XORG_SERVER_CONF_OPT = --disable-config-hal \
 		--disable-xnest --disable-xephyr --disable-xvfb \
 		--with-builder-addr=buildroot at uclibc.org \
 		CFLAGS="$(TARGET_CFLAGS) -I$(STAGING_DIR)/usr/include/pixman-1" \
-		--with-fontdir=/usr/share/fonts/X11/
+		--with-fontdir=/usr/share/fonts/X11/ --localstatedir=/var
 
 ifeq ($(BR2_PACKAGE_XSERVER_xorg),y)
 XSERVER_XORG_SERVER_CONF_OPT += --enable-xorg
Signature · 1 line
1.7.3.4
#1 lore raw

PATCH 2/3 xz: bump to version 5.0.1

---
 package/xz/xz.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
package/xz/xz.mk +1 -1
index dfc0638..1d8c7ee 100644
@@ -3,7 +3,7 @@
 # xz-utils
 #
 #############################################################
-XZ_VERSION = 5.0.0
+XZ_VERSION = 5.0.1
 XZ_SOURCE = xz-$(XZ_VERSION).tar.bz2
 XZ_SITE = http://tukaani.org/xz/
 XZ_INSTALL_STAGING = YES
Signature · 1 line
1.7.3.4
#2 lore raw

PATCH 2/3 xz: bump to version 5.0.1

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Gustavo" == Gustavo Zacarias <[email protected]> writes:

Gustavo> Signed-off-by: Gustavo Zacarias <[email protected]>

Committed, thanks.

Signature · 1 line
Bye, Peter Korsgaard
#3 lore raw

PATCH 3/3 busybox 1.18.3: add patches for klogd and menuconfig

In reply to Gustavo Zacarias
---
 .../busybox-1.18.3/busybox-1.18.3-klogd.patch      |   45 ++++++++++++++++++++
 .../busybox-1.18.3/busybox-1.18.3-menuconfig.patch |   11 +++++
 2 files changed, 56 insertions(+), 0 deletions(-)
 create mode 100644 package/busybox/busybox-1.18.3/busybox-1.18.3-klogd.patch
 create mode 100644 package/busybox/busybox-1.18.3/busybox-1.18.3-menuconfig.patch
package/busybox/busybox-1.18.3/busybox-1.18.3-klogd.patch new file +45 -0
new file mode 100644
index 0000000..2272cd0
@@ -0,0 +1,45 @@
+--- busybox-1.18.3/sysklogd/klogd.c
++++ busybox-1.18.3-klogd/sysklogd/klogd.c
+@@ -150,12 +150,41 @@ int klogd_main(int argc UNUSED_PARAM, ch
+ 	 */
+ 	klogd_open();
+ 	openlog("kernel", 0, LOG_KERN);
++	/*
++	 * glibc problem: for some reason, glibc changes LOG_KERN to LOG_USER
++	 * above. The logic behind this is that standard
++	 * http://pubs.opengroup.org/onlinepubs/9699919799/functions/syslog.html
++	 * says the following about openlog and syslog:
++	 * "LOG_USER
++	 *  Messages generated by arbitrary processes.
++	 *  This is the default facility identifier if none is specified."
++	 *
++	 * I believe glibc misinterpreted this text as "if openlog's
++	 * third parameter is 0 (=LOG_KERN), treat it as LOG_USER".
++	 * Whereas it was meant to say "if *syslog* is called with facility
++	 * 0 in its 1st parameter without prior call to openlog, then perform
++	 * implicit openlog(LOG_USER)".
++	 *
++	 * As a result of this, eh, feature, standard klogd was forced
++	 * to open-code its own openlog and syslog implementation (!).
++	 *
++	 * Note that prohibiting openlog(LOG_KERN) on libc level does not
++	 * add any security: any process can open a socket to "/dev/log"
++	 * and write a string "<0>Voila, a LOG_KERN + LOG_EMERG message"
++	 *
++	 * Google code search tells me there is no widespread use of
++	 * openlog("foo", 0, 0), thus fixing glibc won't break userspace.
++	 *
++	 * The bug against glibc was filed:
++	 * bugzilla.redhat.com/show_bug.cgi?id=547000
++	 */
+ 
+ 	if (i)
+ 		klogd_setloglevel(i);
+ 
+-	bb_signals(BB_FATAL_SIGS, record_signo);
+ 	signal(SIGHUP, SIG_IGN);
++	/* We want klogd_read to not be restarted, thus _norestart: */
++	bb_signals_recursive_norestart(BB_FATAL_SIGS, record_signo);
+ 
+ 	syslog(LOG_NOTICE, "klogd started: %s", bb_banner);
+ 
package/busybox/busybox-1.18.3/busybox-1.18.3-menuconfig.patch new file +11 -0
new file mode 100644
index 0000000..3fc3eda
@@ -0,0 +1,11 @@
+--- busybox-1.18.3/scripts/kconfig/mconf.c
++++ busybox-1.18.3-menuconfig/scripts/kconfig/mconf.c
+@@ -256,7 +256,7 @@ search_help[] = N_(
+ 	"          USB$ => find all CONFIG_ symbols ending with USB\n"
+ 	"\n");
+ 
+-static char buf[4096], *bufptr = buf;
++static char buf[4096*10], *bufptr = buf;
+ static char input_buf[4096];
+ static const char filename[] = ".config";
+ static char *args[1024], **argptr = args;
Signature · 1 line
1.7.3.4
#4 lore raw

PATCH 3/3 busybox 1.18.3: add patches for klogd and menuconfig

Hello,

Quoted 7 lines · On Thu, 10 Mar 2011 09:25:04 -0300 Gustavo Zacarias <[email protected]>…
---
 .../busybox-1.18.3/busybox-1.18.3-klogd.patch      |   45 ++++++++++++++++++++
 .../busybox-1.18.3/busybox-1.18.3-menuconfig.patch |   11 +++++
 2 files changed, 56 insertions(+), 0 deletions(-)
 create mode 100644 package/busybox/busybox-1.18.3/busybox-1.18.3-klogd.patch
 create mode 100644 package/busybox/busybox-1.18.3/busybox-1.18.3-menuconfig.patch

Is it really necessary to add Busybox patches all the time, since they got deprecated pretty quickly by newer releases ? I mean, at the time of the Buildroot release, it of course make sense to have the latest Busybox release with the latest fixes, but during the development phase, is it really useful ?

Of course, if you already do it for other purposes, that's just fine. I'm just wondering.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#5 lore raw

PATCH 3/3 busybox 1.18.3: add patches for klogd and menuconfig

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi,

Thomas> Is it really necessary to add Busybox patches all the time, since they Thomas> got deprecated pretty quickly by newer releases ? I mean, at the time Thomas> of the Buildroot release, it of course make sense to have the latest Thomas> Busybox release with the latest fixes, but during the development Thomas> phase, is it really useful ?

I personally don't mind the (pretty minimal) churn. I find it a good thing that git works as good as possible (E.G. fixed for known issues are included), as it helps testing at all times, not only just before a release.

Signature · 1 line
Bye, Peter Korsgaard