Re: Bug#760727: qtwebkit: FTBFS on kfreebsd-*: libQtWebKit.so: undefined reference to `void WTF::freeOwnedGPtr<_GError>(_GError*)'
On 11/09/14 16:00, Andreas Cord-Landwehr wrote: > Just set up a fresh VM with KFreeBSD-amd64 and using the previously suggested > patch [1] worked for me to fix the build, see log [2]. > PS: My setup slightly more verbose: > * KFreeBSD installed from current Debian/SID to VirtualBox > * got qtwebkit sources with "apt-get source" > * applied patches with "quilt push -a" > * used "dpkg-buildpackage -b" Thank you for testing! I'm not sure what I was doing wrong; I was seeing qmake or other errors when applying my patch in a clean source tree and trying to build. But if it really works then that's great. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54138ff6.7040...@pyro.eu.org
Bug#761331: gdb-avr: Please add mig build-dep on hurd-any
Package: gdb-avr Version: 7.7-1 Severity: important Tags: patch User: debian-hurd@lists.debian.org Usertags: hurd Hello, gdb now requires mig on hurd-any, please apply the attached patch. Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Samuel Hi ! I'm a .signature virus ! Copy me into your ~/.signature, please ! --- debian/control.original 2014-09-13 00:46:39.0 +0200 +++ debian/control 2014-09-13 00:46:48.0 +0200 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Hakan Ardo Standards-Version: 3.9.5 -Build-Depends: tar (>= 1.13.18), bzip2, autoconf (>= 2.13), libtool, texinfo (>= 4.6), texlive (>= 2007-11), libncurses5-dev, libreadline-dev, bison, gettext, debhelper (>= 4.1.46), dejagnu, flex, gdb-source (>= 7.7), dpkg (>= 1.16.2), libexpat1-dev +Build-Depends: tar (>= 1.13.18), bzip2, autoconf (>= 2.13), libtool, texinfo (>= 4.6), texlive (>= 2007-11), libncurses5-dev, libreadline-dev, bison, gettext, debhelper (>= 4.1.46), dejagnu, flex, gdb-source (>= 7.7), dpkg (>= 1.16.2), libexpat1-dev, mig [hurd-any] Package: gdb-avr Section: devel
Re: SysV shutdown hanging
Hi Thomas :) Quoting Thomas Schwinge (2014-09-12 09:16:32) > In my QEMU Debian GNU/Hurd instance, I do some stuff (GDB testsuite, for > example), and then issue a »sudo shutdown -r now«. This doesn't > complete, but hangs like this: > > PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args > [...] > 283860 1 28386 28386 2 147M 1.67M 0.0 0:00.00 0:00.01 > /bin/sh /etc/init.d/rc 6 > 283910 28386 28386 28386 2 146M 1000K 0.0 0:00.01 0:00.00 > /lib/startpar/startpar -p 4 -t 20 -T 3 -M stop -P 2 -R 6 > 284130 28391 28386 28386 2 147M 1.72M 0.0 0:00.00 0:00.00 > /bin/sh /etc/init.d/sendsigs stop > 284180 28413 28386 28386 2 146M 668K 0.0 0:00.00 0:00.00 sync > [...] > > The sync is hanging; confirmed with a manually run »syncfs -s« which also > hangs. Right, I also see this. > What seems suspicious is the following: > > 8140 5 1 1 15 141M 984K 99.8 0:00.23 11:47.19 > /hurd/console > > ..., and indeed if I »kill -KILL« that one, some time later (?), the > shutdown proceeds. My /hurd/console isn't chewing CPU time, though I see the kernel complaining about it deallocating an invalid port. I'll see if I can track this down. I see however some process crashing, and the crash server failing hard: Thread 1 (Thread 4931.1): #0 0x010b1a4c in mach_msg_trap () at /usr/src/glibc-2.19/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 #1 0x010b222e in __mach_msg (msg=msg@entry=0x1604920, option=option@entry=3, send_size=send_size@entry=48, rcv_size=rcv_size@entry=32, rcv_name=65, timeout=timeout@entry=0, notify=notify@entry=0) at msg.c:110 #2 0x0127a889 in __msg_sig_post (process=11, signal=6, sigcode=sigcode@entry=0, refport=1) ---Type to continue, or q to quit--- at /usr/src/glibc-2.19/build-tree/hurd-i386-libc/hurd/RPC_msg_sig_post.c:143 #3 0x010f04a9 in kill_port (refport=, msgport=) at ../sysdeps/mach/hurd/kill.c:67 #4 kill_pid (pid=pid@entry=4931) at ../sysdeps/mach/hurd/kill.c:104 #5 0x010f0761 in __kill (pid=4931, sig=sig@entry=6) at ../sysdeps/mach/hurd/kill.c:138 #6 0x010efb94 in raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #7 0x010f2116 in abort () at abort.c:89 #8 0x0112d05c in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x1210082 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175 #9 0x011d44e0 in __fortify_fail ( msg=msg@entry=0x121006a "stack smashing detected") at fortify_fail.c:31 #10 0x011d449a in __stack_chk_fail () at stack_chk_fail.c:28 #11 0x0804be88 in dump_core (task=2, signo=1410542606, sigcode=65, sigerror=0) at ../../exec/elfcore.c:566 #12 0x0019 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Curious, does your /servers/crash point to crash-dump-core as well? Killing the crash server I managed to get my shutdown process going again, though it got stuck again. Using the kernel debugger (at this point, sysvinit succesfully killed all my shells) I could see that indeed another crash server has been spawned. Cheers, Justus signature.asc Description: signature
SysV shutdown hanging
Hi! In my QEMU Debian GNU/Hurd instance, I do some stuff (GDB testsuite, for example), and then issue a »sudo shutdown -r now«. This doesn't complete, but hangs like this: PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args [...] 283860 1 28386 28386 2 147M 1.67M 0.0 0:00.00 0:00.01 /bin/sh /etc/init.d/rc 6 283910 28386 28386 28386 2 146M 1000K 0.0 0:00.01 0:00.00 /lib/startpar/startpar -p 4 -t 20 -T 3 -M stop -P 2 -R 6 284130 28391 28386 28386 2 147M 1.72M 0.0 0:00.00 0:00.00 /bin/sh /etc/init.d/sendsigs stop 284180 28413 28386 28386 2 146M 668K 0.0 0:00.00 0:00.00 sync [...] The sync is hanging; confirmed with a manually run »syncfs -s« which also hangs. What seems suspicious is the following: 8140 5 1 1 15 141M 984K 99.8 0:00.23 11:47.19 /hurd/console ..., and indeed if I »kill -KILL« that one, some time later (?), the shutdown proceeds. Grüße, Thomas pgp1owEbIIoUn.pgp Description: PGP signature
