[Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7
We’re looking whether this can be fixed on the glibc side currently. ** Changed in: qemu Status: Expired => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: Incomplete Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x pr=0xf63b9c74 fpscr=0x0008 spc=0x ssr=0x gbr=0xf61102a8 vbr=0x sgr=0x dbr=0x delayed_pc=0xf64dd2a0 fpul=0x0003 r0=0xf6fc1320 r1=0x r2=0x5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x03ff r7=0x r8=0x0004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x0804 r15=0xf6fc1220 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson Date: Tue Jul 18 10:02:50 2017 -1000 target/sh4: Add missing FPSCR.PR == 0 checks Both frchg and fschg require PR == 0, otherwise undefined_operation. Reviewed-by: Aurelien Jarno Signed-off-by: Richard Henderson Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno :04 04 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions
[Bug 1891748] Re: qemu-arm-static 5.1 can't run gcc
It works with sudo, but that can’t be the fix… -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1891748 Title: qemu-arm-static 5.1 can't run gcc Status in QEMU: Fix Released Status in Juju Charms Collection: New Bug description: Issue discovered while trying to build pikvm (1) Long story short: when using qemu-arm-static 5.1, gcc exits whith message: Allocating guest commpage: Operation not permitted when using qemu-arm-static v5.0, gcc "works" Steps to reproduce will follow (1) https://github.com/pikvm/pikvm/blob/master/pages/building_os.md To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1891748/+subscriptions
[Bug 1891748] Re: qemu-arm-static 5.1 can't run gcc
Heh, even if I omit -static … -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1891748 Title: qemu-arm-static 5.1 can't run gcc Status in QEMU: Fix Released Status in Juju Charms Collection: New Bug description: Issue discovered while trying to build pikvm (1) Long story short: when using qemu-arm-static 5.1, gcc exits whith message: Allocating guest commpage: Operation not permitted when using qemu-arm-static v5.0, gcc "works" Steps to reproduce will follow (1) https://github.com/pikvm/pikvm/blob/master/pages/building_os.md To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1891748/+subscriptions
[Bug 1891748] Re: qemu-arm-static 5.1 can't run gcc
$ qemu-arm --version qemu-arm version 5.2.0 (Debian 1:5.2+dfsg-6) Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers I’m seeing this error on a totally different file: I’ve made a short test program (hello world-ish) and compiled it with the OpenWrt toolchain but added -static so I can run it on the host using qemu-user-arm: $ STAGING_DIR=$PWD/staging_dir PATH=staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.5.0_musl_eabi/bin:$PATH arm-openwrt-linux-muslgnueabi-gcc -Os -pipe -g3 -fno-caller-saves -fno-plt -fhonour-copts -mfloat-abi=hard -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -static x.c $ ./a.out Allocating guest commpage: Operation not permitted -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1891748 Title: qemu-arm-static 5.1 can't run gcc Status in QEMU: Fix Released Status in Juju Charms Collection: New Bug description: Issue discovered while trying to build pikvm (1) Long story short: when using qemu-arm-static 5.1, gcc exits whith message: Allocating guest commpage: Operation not permitted when using qemu-arm-static v5.0, gcc "works" Steps to reproduce will follow (1) https://github.com/pikvm/pikvm/blob/master/pages/building_os.md To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1891748/+subscriptions
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
On Tue, 3 Mar 2020, Daniel P. Berrangé wrote: > AFAICT, this is not the case. On both my Fedora & Debian installs, > x11vnc is just a binary that attaches to an existing X11 server Huh, weird. Perhaps this changed over the years and distro releases. > $ ls -al /usr/bin/vncserver $ realpath $(which vncserver) /usr/bin/tightvncserver This does surprise me, because I also have x11vnc installed and vaguely remember using it in standalone server mode for a while. But, yes, tightvncserver 1:1.3.9-9.1 is also installed, so I’m apparently using that. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
On Mon, 2 Mar 2020, Daniel P. Berrangé wrote: > There's two translations happening > > * The scancode emitted by the kernel and/or hardware device, >and then translated/mangled by X11 and reported as the >hardware keycode > > * The keysym which is the mapping from the hardware keycode >done by XKB and/or Xmodmap Yes, sure. > We're dealing with the first point in QEMU, taking the hardware > keycode and trying to undo the X11 mangling that was performed. That’s where VNC often fails, generally, anyway… (asd often get translated back as adf). > > But if I can do anything to help debugging this, sure. > > Can you launch 'xev' inside your VNC session and press the 'Page Up' > button and let me know what it reports the keycode and keysym. Sure. > Specifically I'm interested in this line of text: > > state 0x0, keycode 112 (keysym 0xff55, Prior), same_screen YES, > > On evdev it reports 112 as hardware code which is 0x70 hex, while with > 'kbd' it reports 99 which is 0x63 hex. These are the only two scenarios > QEMU knows how to cope with. Then we’re somewhat out of luck: KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624181177, (244,533), root:(250,560), state 0x0, keycode 71 (keysym 0xff55, Prior), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False I’ve also done a,s,d: KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624183753, (244,533), root:(250,560), state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XmbLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624184249, (244,533), root:(250,560), state 0x0, keycode 56 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (73) "s" XmbLookupString gives 1 bytes: (73) "s" XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624184641, (244,533), root:(250,560), state 0x0, keycode 41 (keysym 0x64, d), same_screen YES, XLookupString gives 1 bytes: (64) "d" XmbLookupString gives 1 bytes: (64) "d" XFilterEvent returns: False I’ve tried looking at the sources for x11vnc-0.9.16 and tightvnc-1.3.9 but could not, within a quarter hour at least (got to go…), find out where those codes are mapped anyway other than a reference to XKeysymToKeycode (from libX11 probably). > For that matter, if you have time to help, it would be interesting to > see what it reports for a random selection of other keys too. For > example: > > @ KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624747092, (82,98), root:(88,125), state 0x0, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624747284, (82,98), root:(88,125), state 0x1, keycode 19 (keysym 0x40, at), same_screen YES, XLookupString gives 1 bytes: (40) "@" XmbLookupString gives 1 bytes: (40) "@" XFilterEvent returns: False > # KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624748276, (82,98), root:(88,125), state 0x0, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624748772, (82,98), root:(88,125), state 0x1, keycode 20 (keysym 0x23, numbersign), same_screen YES, XLookupString gives 1 bytes: (23) "#" XmbLookupString gives 1 bytes: (23) "#" XFilterEvent returns: False > $ KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624749620, (82,98), root:(88,125), state 0x0, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624750028, (82,98), root:(88,125), state 0x1, keycode 21 (keysym 0x24, dollar), same_screen YES, XLookupString gives 1 bytes: (24) "$" XmbLookupString gives 1 bytes: (24) "$" XFilterEvent returns: False > ` This one is tricky because on my host keyboard layout ` is on the Escape key while the key left to 1 has Esc (except when shifted, so ~ is Shift plus the key left from 1). This is the physical Escape key, giving `: KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624751028, (82,98), root:(88,125), state 0x0, keycode 33 (keysym 0x60, grave),
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
On Mon, 2 Mar 2020, Daniel P. Berrangé wrote: > "x11vnc" suggests you had a regular X11 desktop session, and are > exporting it via VNC ? No, x11vnc is a standalone VNC server. > Can you tell me a bit more detail about how you launch this all. Sure: $ vncserver -geometry 1000x768 -name nowm :2 $ (export DISPLAY=:2; exec >.xsession-errors; exec 2>&1; icewm-session &) (I could run icewm-session from ~/.vnc/xstartup but this way it inherits some more desirable environment variables.) My ~/.vnc/xstartup looks like: #!/bin/sh xrdb $HOME/.Xresources xsetroot -solid grey uxterm & > ...this suggests your running a VNC server, with embedded X11 server Yes, indeed. > > - xprop -root > > ...there's no _XKB_RULES_NAMES(STRING) property listed, which is the key > thing we'd expect to see for a modern X server. eg > > _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "" > > is what most X servers on Linux will report. This is not a good assumption to make. For example, I’m also using xmodmap instead of xkb for my keyboard layout under the main X.org desktop. (It does carry the xkb information because Debian starts it that way, but I replace it with xmodmap right in .xsessioinrc.) > Can you also say what QEMU version ? qemu-system-x86 1:4.2-3 > So either your QEMU is fairly old, or you are using a keycode mapping > that QEMU has no understanding of (we support evdev, or the classic > xfree86 'kbd' mapping). The latter is the Xmodmap one? If so, then okay. > It would be highly unusual not to use one of > those two, but none the less, that appears to be the case here ? I must admit not knowing all that much about the VNC servers. I used to use tightvnc, but that had issues with… somewhat I don’t remember, so I now use tightvnc’s client but X11vnc as standalone server. There’s also tigervnc, but that works even worse for me. I also tested this in an RDP session with xrdp and xorgxrdp, but things work thereunder just fine. (No surprise, xorgxrdp just provides keyboard, mouse and video modules to an other‐ wise distro-standard X.org server, so the whole xkb first, xmodmap later, dance also applies there, although it doesn’t use evdev keycodes but the earlier PC standard ones from XFree86® and pre-evdev X.org.) But if I can do anything to help debugging this, sure. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
I got this while running qemu under VNC, and was told to report it. including the following information: - Operating system Debian GNU/Linux sid/x32 - X11 Server x11vnc 0.9.16-3 - xprop -root _NET_ACTIVE_WINDOW(WINDOW): window id # 0x1400010 _NET_CLIENT_LIST(WINDOW): window id # 0x400010, 0x10b, 0x1400010 _NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x10b, 0x1400010, 0x400010 _WIN_CLIENT_LIST(CARDINAL) = 16777227, 20971536, 4194320 ICEWM_GUI_EVENT(ICEWM_GUI_EVENT) = 0xf _WIN_DESKTOP_BUTTON_PROXY(CARDINAL) = 12583282 _WIN_WORKAREA(CARDINAL) = 0, 0, 1000, 743 _NET_WORKAREA(CARDINAL) = 0, 0, 1000, 743, 0, 0, 1000, 743, 0, 0, 1000, 743, 0, 0, 1000, 743 _NET_CURRENT_DESKTOP(CARDINAL) = 0 _WIN_WORKSPACE(CARDINAL) = 0 _NET_SHOWING_DESKTOP(CARDINAL) = 0 _NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0 _NET_DESKTOP_GEOMETRY(CARDINAL) = 1000, 768 _NET_NUMBER_OF_DESKTOPS(CARDINAL) = 4 _WIN_WORKSPACE_COUNT(CARDINAL) = 4 _NET_DESKTOP_NAMES(UTF8_STRING) = " 1 ", " 2 ", " 3 ", " 4 " _WIN_WORKSPACE_NAMES(STRING) = " 1 ", " 2 ", " 3 ", " 4 " WM_ICON_SIZE(WM_ICON_SIZE): minimum icon size: 32 by 32 maximum icon size: 32 by 32 incremental size change: 1 by 1 _NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0xc00014 _NET_SUPPORTED(ATOM) = _NET_ACTIVE_WINDOW, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_CLOSE_WINDOW, _NET_CURRENT_DESKTOP, _NET_DESKTOP_GEOMETRY, _NET_DESKTOP_LAYOUT, _NET_DESKTOP_NAMES, _NET_DESKTOP_VIEWPORT, _NET_FRAME_EXTENTS, _NET_MOVERESIZE_WINDOW, _NET_NUMBER_OF_DESKTOPS, _NET_REQUEST_FRAME_EXTENTS, _NET_RESTACK_WINDOW, _NET_SHOWING_DESKTOP, _NET_STARTUP_ID, _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_SYSTEM_TRAY_MESSAGE_DATA, _NET_SYSTEM_TRAY_OPCODE, _NET_SYSTEM_TRAY_ORIENTATION, _NET_SYSTEM_TRAY_VISUAL, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ALLOWED_ACTIONS, _NET_WM_DESKTOP, _NET_WM_FULLSCREEN_MONITORS, _NET_WM_HANDLED_ICONS, _NET_WM_ICON_NAME, _NET_WM_ICON, _NET_WM_MOVERESIZE, _NET_WM_NAME, _NET_WM_PID, _NET_WM_PING, _NET_WM_STATE, _NET_WM_STATE_ABOVE, _NET_WM_STATE_BELOW, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_FOCUSED, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_HIDDEN, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MODAL, _NET_WM_STATE_SHADED, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY, _NET_WM_STRUT, _NET_WM_STRUT_PARTIAL, _NET_WM_USER_TIME, _NET_WM_USER_TIME_WINDOW, _NET_WM_VISIBLE_ICON_NAME, _NET_WM_VISIBLE_NAME, _NET_WM_WINDOW_OPACITY, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_COMBO, _NET_WM_WINDOW_TYPE_DESKTOP, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DND, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_NOTIFICATION, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WORKAREA _WIN_AREA(CARDINAL) = 0, 0 _WIN_AREA_COUNT(CARDINAL) = 1, 1 _WIN_SUPPORTING_WM_CHECK(CARDINAL) = 12582932 _WIN_PROTOCOLS(ATOM) = _WIN_AREA, _WIN_AREA_COUNT, _WIN_CLIENT_LIST, _WIN_DESKTOP_BUTTON_PROXY, _WIN_HINTS, _WIN_ICONS, _WIN_LAYER, _WIN_PROTOCOLS, _WIN_STATE, _WIN_SUPPORTING_WM_CHECK, _ICEWM_TRAY, _WIN_WORKAREA, _WIN_WORKSPACE, _WIN_WORKSPACE_COUNT, _WIN_WORKSPACE_NAMES _XROOTCOLOR_PIXEL(CARDINAL) = 8256 _XROOTPMAP_ID(PIXMAP): pixmap id # 0x0 _ICEWMBG_PID_S0(CARDINAL) = 4749 RESOURCE_MANAGER(STRING) = "*VT100*translations:\t#override \\n Shift~CtrlInsert:insert-selection(PRIMARY) \\n Shift CtrlInsert:insert-selection(CLIPBOARD) \\n ~Shift~Ctrl:insert-selection(PRIMARY) \\n Shift~Ctrl:insert-selection(CLIPBOARD) \\n ~Shift:select-end(PRIMARY) \\n Shift:select-end(CLIPBOARD)
Re: [Qemu-devel] [PATCH v15 23/26] sched: early boot clock (was Re: Bug#918036: linux: uptime after reboot wrong (kvm-clock related?))
Hi Salvatore, >p.s.: my earlier reply to you seem to have been rejected and never > reached you, hope this one does now. if you sent from Googlemail, it may reach me in the next weeks or never *shrug* they don’t play nice with greylisting. The -submitter or @d.o works, though. I’m following up from my $dayjob address as the issue occurred there (which is also Googlemail, unfortunately). >There was now a followup on this, and if you can I think it's best if >you can followup there. > >https://lore.kernel.org/lkml/ca+ck2bc70pnl0wimb0xt99j4nnfi8w3zuuhgak-jspuop9j...@mail.gmail.com/ OK, doing now: Pavel Tatashin wrote: >Could you please send the config file and qemu arguments that were >used to reproduce this problem. This is from a libvirt-managed system. The arguments as shown by “ps axwww” are: qemu-system-x86_64 -enable-kvm -name ci-busyapps -S -machine pc-1.1,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 09536d92-dd73-8993-78fb-e0c885acf763 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ci-busyapps.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/vms/ci-busyapps,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:6e:fd,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on I’ve attached the kernel configuration; this is a stock Debian unstable/amd64 system, just upgraded. After upgrading the guest, I merely issued a “reboot” in the guest and did not stop/start qemu. The host is Debian jessie/amd64 (Linux 3.16.0-7-amd64 / 3.16.59-1) in case that matters. Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
[Qemu-devel] [Bug 1525682] Re: configure: fix POSIX compatibility issue
Note that mksh is virtually a superset of OpenBSD ksh and accepts this
construct, for a quick fix.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1525682
Title:
configure: fix POSIX compatibility issue
Status in QEMU:
New
Bug description:
When running configure script from 2.5.0-rc4 on OpenBSD-current
(amd64), I get the following error:
./configure[4756]: ${nettle:+($nettle_version)}": bad substitution
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2747
'/usr/ports/pobj/qemu-2.5.0rc4/.configure_done')
*** Error 1 in /usr/ports/openbsd-wip/emulators/qemu
(/usr/ports/infrastructure/mk/bsd.port.mk:2491 'configure')
Indeed, construct "${nettle:+($nettle_version)}" does not conform to
POSIX Shell Command Language. The attached patch fixes the issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1525682/+subscriptions
[Qemu-devel] mksh on Slackware (was Re: CVS: herc.mirbsd.org: src)
Hi all! Thanks for this: Commit ID: 100548597A713CD6746 CVSROOT: /cvs Module name: src Changes by:t...@herc.mirbsd.org2014/12/08 12:20:42 UTC Modified files: bin/mksh : Build.sh Log message: port this to GNU bash 1.12.1 from http://www.qemu-advent-calendar.org/#day-1 The image has JOE 0.1.5, some sort of jupp¹-ish editor, which made me happy. But I’ve got another problem: I can’t run mksh’s testsuite, whose driver is written in Perl, which I don’t speak. root@slack:/root/mksh # perl -v This is perl, version 4.0 $RCSfile: perl.c,v $$Revision: 4.0.1.7 $$Date: 92/06/08 14:50:39 $ Patch level: 35 Copyright (c) 1989, 1990, 1991, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 4.0 source kit. Any help in porting mksh/check.pl² to t̲h̲a̲t̲? ☺ Thanks in advance, //mirabilos ① https://www.mirbsd.org/jupp.htm ② https://www.mirbsd.org/cvs.cgi/src/bin/mksh/check.pl?rev=HEAD -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Re: [Qemu-devel] mksh on Slackware (was Re: CVS: herc.mirbsd.org: src)
enh dixit: [ mksh testsuite ] have you considered using sh instead? :-) Not pure sh, that’s nowhere near enough. Maybe mksh. But if the one just built has issues, that may mask it. If another, you’ve got hen/egg problems. Maybe C. But then, (cross-)building a C program to test another one just built *may* (or may not) be more susceptible to errors than using a completely separate tool. No, I’m not happy with the current testsuite driver, but it’s there, it’s reasonably portable, and does its job, after some prodding (and I still don’t speak Perl). (there's no perl on Android, which makes running the mksh tests impractical. one can *build* perl for Android, i'm led to believe, but I’ve successfully (modulo the things that just didn’t exist, or didn’t work with toolbox) run the testsuite on Android (on the emulator) once, with a native Bionic perl. Nowadays, I’d probably just get a Linux/ARM box (Debian poterbox would be superb, except I retired from Debian recently), build a native Perl against dietlibc or musl, statically, then copy that over to Android, as it only relies on the kernel, and this is enough for the testsuite. Another idea we will have to try out: check if the testsuite can be run on the build system (instead of the target), using ssh (or adb shell) to invoke the to-be-tested utility on the target. Con: we’d probably need to NFS-mount or rsync the directory tree. But maybe something the *WRT people are also interested in. (Or we could move file generation to the target as well. Needs more hacking work in the testsuite driver.) Anyway, this is still enough short-term. bye, //mirabilos -- “The final straw, to be honest, was probably my amazement at the volume of petty, peevish whingeing certain of your peers are prone to dish out on -devel, telling each other how to talk more like a pretty princess, as though they were performing some kind of public service.” (someone to me, privately)
