I'm trying to open a plugin for SNAP (to process Sentinel-3 imagery) on my Mac - the plugin downloads as an .exe file which means I need to open it using WineBottler. Every time I try and open the file however, I get this error message:
###BOTTLING### default.sh
/var/folders/rz/rr6ytzhx5gl60f1v1tbc67xm0000gn/T/AppTranslocation/6CDA1855-FA78-4A2A-A976-2C1A539F36ED/d/WineBottler.app/Contents/Frameworks/WBottler.framework/Resources/bottler.sh: line 39: /Applications/Wine.app/Contents/Resources/bin/wine: Bad CPU type in executable
###BOTTLING### Gathering debug Info...
Versions
OS...........................: darwin21
Wine.........................:
WineBottler..................: 1.8.6
Wineticks....................: 20220411-next - sha256sum: b6370f13c4dc410023f2a4e4e9a4385d2a0420031666c2f30befccc9b39c8f65
Environment
PWD..........................: '/Applications/Wine.app/Contents/Resources/bin'
PATH.........................: /Applications/Wine.app/Contents/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin
USER.........................: hannah
HOME.........................: /Users/hannah
COMPUTERNAME.................: hannahâs MacBook Air
BUNDLERESOURCEPATH...........: /var/folders/rz/rr6ytzhx5gl60f1v1tbc67xm0000gn/T/AppTranslocation/6CDA1855-FA78-4A2A-A976-2C1A539F36ED/d/WineBottler.app/Contents/Frameworks/WBottler.framework/Resources
WINEPREFIX...................: /Applications/Wine.app/Contents/Resources
WINEPATH.....................: /Applications/Wine.app/Contents/Resources/bin
LD_LIBRARY_PATH..............: /Applications/Wine.app/Contents/Resources/lib:/opt/X11/lib:/usr/X11/lib
DYLD_FALLBACK_LIBRARY_PATH...: /Applications/Wine.app/Contents/Resources/lib:/usr/lib:/opt/X11/lib:/usr/X11/lib
SILENT.......................:
http_proxy...................:
https_proxy..................:
ftp_proxy....................:
socks5_proxy.................:
Bottle
TEMPLATE.....................:
BOTTLE.......................: /Users/hannah/Desktop/Untitled.app
INSTALLER_URL................: /Users/hannah/Desktop/iCOR_Setup_3.0.0.exe
INSTALLER_IS_ZIPPED..........: 0
INSTALLER_NAME...............: iCOR_Setup_3.0.0.exe
INSTALLER_ARGUMENTS..........:
REMOVE_MONO..................:
REMOVE_GECKO.................:
REMOVE_USERS.................:
REMOVE_INSTALLERS............:
WINETRICKS_ITEMS.............: winxp
DLL_OVERRIDES................:
EXECUTABLE_PATH..............: winefile
EXECUTABLE_ARGUMENTS.........:
EXECUTABLE_VERSION...........: 1.0.0
BUNDLE_COPYRIGHT.............: © Your Company
BUNDLE_IDENTIFIER............: com.yourcompany.yourapp
BUNDLE_CATEGORYTYPE..........: public.app-category.business
SILENT.......................:
Hardware:
Hardware Overview:
Model Name: MacBook Air
Model Identifier: MacBookAir7,2
Processor Name: Dual-Core Intel Core i5
Processor Speed: 1.6 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 3 MB
Hyper-Threading Technology: Enabled
Memory: 4 GB
System Firmware Version: 476.0.0.0.0
OS Loader Version: 540.120.3~22
SMC Version (system): 2.27f2
Serial Number (system): C02QM1XWG941
Hardware UUID: EE27242F-C2B2-59E6-AAED-D598D1D61044
Provisioning UDID: EE27242F-C2B2-59E6-AAED-D598D1D61044
###BOTTLING### Create .app...
###BOTTLING### Enabling CoreAudio, Colors, Antialiasing and flat menus...
/var/folders/rz/rr6ytzhx5gl60f1v1tbc67xm0000gn/T/AppTranslocation/6CDA1855-FA78-4A2A-A976-2C1A539F36ED/d/WineBottler.app/Contents/Frameworks/WBottler.framework/Resources/bottler.sh: line 134: /Applications/Wine.app/Contents/Resources/bin/wine: Bad CPU type in executable
### LOG ### Command '/Applications/Wine.app/Contents/Resources/bin/wine regedit /tmp/reg.reg' returned status 126.
###ERROR### Command '/Applications/Wine.app/Contents/Resources/bin/wine regedit /tmp/reg.reg' returned status 126.
Task returned with status 1.
I've tried downloading the 'stable' version of WineBottler, download and redownload it to no avail - it always returns this message. I can't seem to find any way of getting around this or recently posted question (a lot are from 2010-15 and are outdated in their solutions)
Does anyone know what I can do to get around this and open it? It's driving me insane!!!
Thanks!
I am trying to run a Next.js server on a DigitalOcean virtual machine. The server works, but when I run npm run start, the logs say Killed after ~1 minute.
Here is an example log of what happens:
joey#mydroplet:~/Server$ sudo node server
info - SWC minify release candidate enabled. https://nextjs.link/swcmin
event - compiled client and server successfully in 3.3s (196 modules)
wait - compiling...
event - compiled client and server successfully in 410 ms (196 modules)
> Ready on https://localhost:443
> Ready on http://localhost:8080
wait - compiling / (client and server)...
event - compiled client and server successfully in 1173 ms (261 modules)
Killed
joey#mydroplet:~/Server$
After some research, I came across a couple of threads which detail a server lacking enough memory/resources to continue the operation. I upgraded the memory from 512 mb to 1 gb, but this still happens.
Do I need to further upgrade the memory?
This is the plan that I am on:
It was the memory. Upgrading the memory of the server from 1 gb to 2 gb solved this problem.
This is the plan that worked for me:
In my device I enabled software watchdog to monitor a file which is updated every 5 second by a application. I have configured software watchdog as below
file = /data/file_name_to_watch
change = 10
Watchdog is getting started at bootup using below command during bootup:
/usr/sbin/watchdog.sh -f -v -c watchdog.conf
Application which is responsible to update the file(file_name_to_watch) is started after watchdog deamon during bootup. File being monitored by watchdog is updated every 5 seconds by the application.
Problem is that watchdog is rebooting the system if it is started at bootup and this same problem doesn't exist when watchdog is not started at bootup but started manually after application is launched.
dmesg shows "Watchdog did not stop"
Also, changing the watchdog configuration file to below didn't help.
file = /data/file_name_to_watch
change = 20
I have checked that the file is getting updated before 10 seconds elapsed after watchdog is launched during bootup.
Any pointers to debug this problem will be appreciated.
Code which I am using for watchdog: https://layers.openembedded.org/layerindex/recipe/122/
Debugged and found the problem to be time(NULL) returning a huge number in src/file_stat.c
This was happening due to date being not set very early during bootup.
I installed the current lirc package (0.9.0~pre1-1.2) on a Raspian jessie (no pixel) (everything updated and upgraded) and connected to the (lirc default) GPIO ports:
to gpio port 17 - an IR LED via transistor etc
to gpio port 18 - an IR receiver nodule
The receiver part works perfectly:
mode2 command receiving raw data from transmitter
the IR code recognition of previously recorded keys works
However, the IR LED only works only while lirc is not involved:
a shell script can switch the IR LED on and off with no problem
The only thing that doesn't work:
irsend does not make the IR transmitter emit anything, however no error message is shown
So the hardware, especially the IR LED is definitely working, while lirc cannot make the LED emit any configured IR code.
Please note that this seems to be a duplicate of
stackoverflow: irsend is not giving errors, but does not send signal on Raspbian
Unfortunately it is not. The "solution" provided there was placing the data for /etc/modules into the file /etc/modules-load.d/lirc_rpi.conf. I tried that as well, but it makes no difference.
Any help is greatly appreciated!
Configuration data follows - if any other data is required, I'd be happy to add it! TIA!
System and lirc Configuration
Extract fom: /boot/config.txt
dtoverlay=lirc-rpi,gpio_in_pin=18,gpio_out_pin=17,debug=on
Extract of: /etc/modules
lirc_dev
lirc_rpi gpio_in_pin=18 gpio_out_pin=17
(not sure if that is necessary at all, does not make a difference if this is not configured!? Any hint apppreciated)
All active entries in: /etc/lirc/hardware.conf
LIRCD_ARGS="--uinput"
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
LIRCD_CONF=""
LIRCMD_CONF=""
Some system output
1) The driver is loaded, output of following command right after boot, output of: dmesg | grep lirc
lirc_dev: IR Remote Control driver registered, major 245
lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
lirc_rpi: to_irq 178
lirc_rpi: auto-detected active low receiver on GPIO pin 18
lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
lirc_rpi: driver registered!
input: lircd as /devices/virtual/input/input0
lirc_rpi: Interrupt 178 obtained
2) the service is started and running, output of: systemctl status lirc
? lirc.service - LSB: Starts LIRC daemon.
Loaded: loaded (/etc/init.d/lirc)
Active: active (running) since Mo 2017-06-12 20:04:03 CEST; 2h 58min ago
Process: 377 ExecStart=/etc/init.d/lirc start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/lirc.service
+-437 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput
3) the modules are loaded, output of: lsmod | grep Module;lsmod | grep lirc
Module Size Used by
lirc_rpi 8453 3
lirc_dev 10211 1 lirc_rpi
rc_core 23776 1 lirc_dev
I followed the troubleshooting steps in the (outdated) manual at http://aron.ws/projects/lirc_rpi/
to get some more information.
Output of: cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-53, parent: platform/20200000.gpio, pinctrl-bcm2835:
gpio-35 ( |? ) in hi
gpio-47 ( |? ) out lo
I have seen that output also in this case:
raspberrypi.stcakexchange: LIRC won't transmit (irsend: hardware does not support sending)
This user is as irritated by that output as I am - can somebody please tell why gpio-35 and gpio-47 are listed here? shouldn't it be gpio-17 and gpio-18?
Output of: cat /proc/interrupts | grep lirc
178: 875 pinctrl-bcm2835 18 Edge lirc_rpi
This matches the dmesg output on having obtained interrupt 178
Any other dmesg output of lircd, no matter what action, is repeatedly (most likely due to the debug option set) only
lirc_rpi: SET_SEND_CARRIER
lirc_rpi: in init_timing_params, freq=38000 pulse=13157, space=13158
lirc_rpi: SET_SEND_DUTY_CYCLE
lirc_rpi: in init_timing_params, freq=38000 pulse=13157, space=13158
Having restarted testing again after some time for to build up a test copy of the circuit, the problem occurred again. And now, after some more month of much testing, having asked lots of people for help (no one could help), even having purchased and built up a cheap mini USB oscilloscope kit for to examine the hardware further, I finally found the solution.
Long story short: everything in the configuration was correct, and all of the attached hardware was fine. The problem was the testing script - see my remark on
"a shell script can switch the IR LED on and off with no problem"
and as I did not put it in the above description, nobody could have found the solution myself....
The script uses the pseudo files in /sys/class/gpio, see an example here:
raspberry-projects.com: IO pin control from the command line
At the end of the script a command writes to /sys/class/gpio/unexport for cleanup purposes, and this step seems to reset a GPIO port to always end up in the state of being configured for input. As a result LIRC is not longer able to control this GPIO port, since it seems to configure the GPIO port for output only during system boot, and after that always expecting the port to be in that state.
I tracked the problem down to this point by using the gpio utility from the wirinpi package (install with sudo apt-get wiringpi), executing gpio readall and checking for differences.
The time when everything suddenly worked again, I simply may have fogotten about to run my testscript before testing LIRC, which I otherwise always did...
Luckily the problem with the port configuration can easily be fixed without having to reboot the system. Again I use the gpio utility to reset reset the used port for output, where in the below example
the default output port 17 for LIRC is used and
the parameter -g lets the utility use the ordinary GPIO port numbering and not that very different one of the wiringpi package and library
Here is the command, after having executed this last in my test script, LIRC can properly send IR codes again:
gpio -g mode 17 out
I can't get overtone to work with supercollider server, I'm following the getting started guide at https://github.com/overtone/overtone/wiki/Getting-Started, I've got Jack audio server running through qjackctl, then I ran SuperCollider with scsynth -u 8888 which produced the following output:
Found 12 LADSPA plugins
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024
SuperCollider 3 server ready.
Zeroconf: registered service 'SuperCollider'
then in the clojure repl I connect to SC server:
(connect-external-server 8888)
then when I run (definst foo [] (saw 220))
I get the following error:
CompilerException java.util.concurrent.TimeoutException: deref! timeout
error. Dereference took longer than 5000 ms whilst blocking until the
following node has completed loading: #<synth-group[loading]: Inst foo
Container 41>, compiling:(form-init1483192646581877285.clj:131:7)
and scsynth outputs FAILURE IN SERVER /g_new Group 31 not found
also if I try (demo (sin-osc)) I get the error FAILURE IN SERVER /s_new Group 7 not found
although if I run using sclang:
s.boot;
{ SinOsc.ar(440, 0, 0.2) }.play;
it does produce a sound.
I'm running Manjaro Linux using the Linux 4.9.27 real time Manjaro kernel
and an HDA Intel PCH sound card.