I'm developing an application from my PC (Ubuntu 14.04) to Raspberry pi 2. I'm trying to use GStreamer-1.0 because it has hardware acceleration support for Raspberry Pi. Shortly brief about application; getting frames from an IP camera and save them with 1 FPS to somewhere on the file system. I can save images from command line with;
gst-launcg-1.0 rtspsrc location="" ! rtph264depay ! h264parse ! omxh264dec ! videorate ! video/x-raw,framerate=1/ ! jpegenc ! multifilesink location=/somewhere/to/save/images/and/save/type
but I want to do this with C++ code and I'll use these images to do some processings. I've installed gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, gst-omx to Raspberry Pi and Installed gstreamer (and requirements, zlib, glib and libffi) to Ubuntu for cross development. I want to create a pipeline for this process but when I want to create "jpegenc" element it is giving me error which is not about gstreamer;
Wrong JPEG library version: library is 62, caller expects 80
But I didn't understand anything because my apps ldd output has no dependency about libjpeg.so.62;
libjpeg.so.8 => /usr/lib/arm-linux-gnueabihf/libjpeg.so.8 (0x74b51000)
I had have not libjpeg62 at both of my systems. But I've installed libjpeg62 (I wanted libjpeg62-dev but sudo apt-get install libjpeg62-dev wanted to remove some packages which are necessary to me then I decline it) and linked libjpeg.so with (RPi);
sudo rm /usr/lib/arm-linux-gnueabihf/libjpeg.so
sudo ln -s /usr/lib/arm-linux-gnueabihf/libjpeg.so.62 /usr/lib/arm-linux-gnueabihf/libjpeg.so
But nothing changed. I've looked this question but I'm not compiling it from R-Pi and it didn't affect anything,
uninstalled all the jpeg versions (both 62 and 80), and reinstalled jpeg8 by using
sudo apt-get install libjpeg8
Related
i'm trying to use QEMU 5.x for research.
I got QEMU 5.2 source code from qemu.org and installed following instructions.
However, when i tried to run VM by this command:
qemu-system-x86_64 \
-monitor stdio \
--enable-kvm \
-m 4096 \
-cdrom ubuntu-20.04.iso \
-drive file=img.qcow,if=virtio \
-boot c
-rtc base=localtime \
-device virtio-keyboard-pci \
-vga virtio \
then the following texts are printed:
QEMU 5.2.0 monitor - type 'help' for more information
(qemu) VNC server running on 127.0.0.1:5900
then nothing shows up, while QEMU 4.x (used before) pops up a window showing guest ubuntu's GUI.
I'm using ubuntu 20.04. Hope anyone has breakthrough for this..
The message says that this QEMU is using the VNC protocol for graphics output. You can connect a VNC client to the 127.0.0.1:5900 port that it tells you about to see the graphics output.
If what you wanted was a native X11 window (GTK), then the problem is probably that you didn't have the necessary libraries installed to build the GTK support. QEMU's configure script's default behaviour is "build all the optional features that this host has the libraries installed for, and omit the features where the libraries aren't present". So if you don't have any of the GTK/SDL etc libraries when you build QEMU, the only thing you will get in the resulting QEMU binary is the lowest-common-denominator VNC support. If you want configure to report an error for a missing feature then you need to pass it the appropriate --enable-whatever option to force the feature to be enabled (in this case, --enable-gtk).
If you're running on Ubuntu and your apt sources.list file has deb-src lines in it, the easiest way to install all the dependencies that would get you the same feature list as the real Ubuntu QEMU package is to run "apt build-dep qemu". I recommend that you do that and then re-build QEMU, passing --enable-gtk to configure so you can confirm that the necessary dependencies were installed.
I'm trying to get unison working after upgrading to Mac OS X Catalina. Unfortunately, macports installs a more recent version of ocaml (4.08.1), which means that the unison 2.51.2 release won't compile.
Well, that's no problem, I just update to git master on unison, and recompile. Unfortunately, this fails at sync time because the version of ocaml used to compile on the mac (4.08.1) is different from the one used to compile on the other machine (4.07.1). Sigh. Okay, use opam magic to install 4.07.1 on my machine. Everything should be fine, right? No!
Here's the error:
Connected [//zzzmyhost//home/clements/unison-home -> //zzzmyotherhost//Users/clements/clements]
Looking for changes
Uncaught exception Failure("input_value: ill-formed message")
Raised at file "/private/tmp/unison/src/lwt/lwt.ml", line 126, characters 16-23
Called from file "/private/tmp/unison/src/lwt/generic/lwt_unix_impl.ml", line 102, characters 8-23
Called from file "/private/tmp/unison/src/update.ml" (inlined), line 2105, characters 2-69
Called from file "/private/tmp/unison/src/uitext.ml", line 978, characters 16-56
Called from file "/private/tmp/unison/src/uitext.ml", line 1066, characters 6-90
Called from file "/private/tmp/unison/src/uitext.ml", line 1088, characters 19-66
Called from file "/private/tmp/unison/src/uitext.ml", line 1144, characters 21-43
What's going on?
Sigh... the problem here (very non-obvious) is actually with a corrupted/wrong-format syncronization file, created when doing the failed sync in the earlier test.
The solution is just to go into ~/Library/Application Support/Unison (on a UNIX machine this path would presumably live in ~/.unison and delete the archive file that's causing the problem (probably the most recent one). In a pinch, just delete all of the archive files and start over.
I've got the same problem between Windows and Ubuntu 20.04 after upgrading from Ubuntu 18.04. I tried the binary from Ubuntu 18.04 in 20.04, which still fails, so the incompatibility is likely inside one of the dependencies.
As a workaround I created a Docker image based on Ubuntu 18.04:
FROM ubuntu:18.04
RUN apt-get update && apt-get dist-upgrade -y
RUN apt-get install unison -y
RUN useradd martin --home /home/martin
WORKDIR /home/martin
USER martin
Building it with docker build -t unison:18.04 .
And then I added a wrapper to ~/bin/unison-2.48.4-docker:
#!/bin/bash
docker run --rm -i \
-v /home/martin/dirtosync:/home/martin/dirtosync \
-v /home/martin/.unison:/home/martin/.unison \
--hostname $(hostname) \
unison:18.04 unison "$#"
Setting the --hostname is important, since the hostname is part of the archive file.
Inside the profile on my Windows machine I configured:
servercmd = ~/bin/unison-2.48.4-docker
In my setup with two windows clients and one Ubuntu 18.04 server, connected by ssh, the problem startet with a second server running on Ubuntu 20.04. Neither the old server nor the windows clients could sync with the new machine.
My solution: Copying the binary from Ubuntu 18.04 to a new directory in the Ubuntu 20.04 machine. This new file is referenced in the "authorized_keys" file of ssh on the new machine.
So far, everything works great with unison 2.48.4.
I've used buildroot to build a qemu compatible Linux kernel and root filesystem. I am emulating for the MPC8544DS machine and used the qemu_ppc_mpc8544ds_defconfig to generate these components. I was able to successfully build the kernel and the root filesystem. And was able to run it under qemu.
However when I tried to run uboot instead of the Linux Kernel (and the associated rootfs) it fails. Here is the way I invoke qemu to boot u-boot:
qemu-system-ppc -nographic -M mpc8544ds -m 512 -kernel ~/CrossCompilation/u-boot.bin and it fails like so:
Wrong image type 52, expected 2
qemu: could not load kernel '~/CrossCompilation/u-boot.bin'
I do not understand what else could be wrong. I've checked various blog posts over the internet and almost all of them use uboot.bin as the kernel (as opposed to srec and other formats)
could someone shed some light on the various image type numbers and which ones fit where?
UPDATE: This is how I compiled my u-boot
cd to u-boot dir
make distclean
make mrproper
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe- MPC8544DS_defconfig
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe-
Try removing the -kernel option. Make sure everything stay as is:
qemu-system-ppc -nographic -M mpc8544ds -m 512 ~/CrossCompilation/u-boot.bin
I compiled the Linux kernel (version 2.6.32) using the Emdebian ARM toolchain. Downloaded the initrd from Aurel's personal FTP server hosted on Debian here.
The ran qemu like so:
qemu-system-arm -M versatilepb -kernel zImage -hda hda.img -initrd initrd_versatile.gz -append "root=/dev/ram" -m 1024
Yet it fails with qemu reporting:
mount: mouting none of /run failed invalid argument.
Keen to hear if someone has something to say about this. As I search for it, could someone also let me know if it is possible to use an off the shelf initrd or is it related to the kernel version being run?
I was able to run the machine by cross compiling busybox, creating a cpio archive image and then using it like so:
qemu-system-arm -M versatilepb -m 128M -kernel zImage -initrd rootfs.img -append "root=/dev/ram rdinit=/bin/sh console=tty1"
Now that Ive got it working Ill investigate what those arguments actually mean.
I'm trying to get started on libvirt with VirtualBox as a virtualization solution. I installed everything and VirtualBox itself is running when using their VBoxHeadless command.
However, libvirt fails to connect to VirtualBox:
# virsh -c vbox:///session
libvir: error : could not connect to vbox:///session
error: failed to connect to the hypervisor
I could not find any hints in the libvirt documentation that point to whether I have to make any domain specific configuration before using virsh.
Does anyone have a hint? Or even better, maybe a tutorial that works through the way of using libvirt, virsh or it's APIs (my later goal) from the ground up.
If you are doing this on Ubuntu, then the problem is their libvirt package is built without VirtualBox support.
You can rebuild the package with support very easily. Something like:
apt-get source -d libvirt
sudo apt-get build-dep libvirt
dpkg-source -x libvirt*dsc
Go into the libvirt directory and edit debian/rules so that instead of --without-vbox it says --with-vbox. You can add an entry to the top of debian/changelog so the package is compiled as a different version (e.g., append ~local1 to the version).
dpkg-buildpackage -us -uc -b -rfakeroot
You'll get new .debs built in the directory above. Use dpkg -i to install the relevant ones (libvirt0, libvirt0-bin, and whatever else you want).
Double-check whether or not you have write access to /var/run/libvirt/libvirt-sock.
The socket file should have permissions similar to:
$ sudo ls -la /var/run/libvirt/libvirt-sock
srwxrwx--- 1 root libvirtd 0 2010-08-24 14:54 /var/run/libvirt/libvirt-sock
I think it could be helpful also to increase the libvirt logging capabilities by running this in your shell:
export LIBVIRT_DEBUG=1
There is Ubuntu PPA for libvirt with VirtualBox support: https://launchpad.net/~cxl/+archive/ubuntu/libvirt