Use case is something like this. We need to use the Bluez BT stack on linux. There is also dependency of an iOS app that controls BT testing on iOS (On mac). The execution flow triggers mounting of the file system from linux onto mac and tries to build the xcode project and use the .app file that gets generated after the build is successful
If the xcode build command is run manually on Mac directly, there is no problem
xcodebuild test-without-building -project ios_bluetooth/ios_bluetooth.xcodeproj/ -scheme
ios_bluetooth -destination id=uuid -only-
testing:ios_bluetoothUITests CONFIGURATION_BUILD_DIR=./Build/Products/Debug-iphoneos -
derivedDataPath ./ios_bluetooth/DerivedData/ arguments=TESTS_STA_BLUETOOTH_ON
From Linux, after the mount, by default it mounts to /var/root/ProjectFolder/Dependencies. Running the xcodebuild command results in issues in terms of permission. Issue can be see even if logged in as root on mac. Is there a way to circumvent this issue and get the xcode project to build? Any help in this regard is appreciated.
Related
Installation vscode
I'm running Arch Linux (Manjaro) and installed vscode with:
sudo pacman -S code
but then a simple .NET core program resulted in
--------------------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (clrdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.
--------------------------------------------------------------------------------
It seems like the official Microsoft build should be obtained via the snap store:
sudo snap install code --classic
And the program looks normal. I can install plug-ins, create a new file et cetera.
Problem
However, I cannot open any files or projects. Doing so results in vscode crashing. I read that code --disable-gpu could solve this problem, but doesn't do so for me.
Any ideas
what may cause this crash?
or how to get the pacman vscode working?
Logs
$ code --verbose
Gtk-Message: 22:59:19.805: Failed to load module "canberra-gtk-module"
Gtk-Message: 22:59:19.805: Failed to load module "canberra-gtk-module"
(code:33833): GdkPixbuf-WARNING **: 22:59:19.817: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
[33863:1104/225919.911481:ERROR:appcenter_api.cc(52)] expecting appcenter url prefix
[main 2020-11-04T21:59:19.960Z] Sending env to running instance...
[main 2020-11-04T21:59:20.041Z] Sent env to running instance. Terminating...
[main 2020-11-04T21:59:20.041Z] Lifecycle#kill()
where the recommended gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache results in bash: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache: No such file or directory
I'm running Arch Linux (Manjaro) and installed vscode with:
sudo pacman -S code
but then a simple .NET core program resulted in
--------------------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (clrdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.
--------------------------------------------------------------------------------
I had the same issue trying to get the debugger to work and I spent hours on finding the reason for this. What I found out is that the debugger only works with officially signed Microsoft binaries of VSCode. So you have to make a distinction here:
The package code contains the open source version of visual studio code, a build wich anyone can make using the provided sources by Microsoft. The program which you get here is therefore not signed by MS!
The package visual-studio-code-bin provided by the AUR contains a officially signed version by MS. If you use this package, the debugger works as expected.
I do not know wether snap - which I personally never used at all - provides this kind of package, so I can not tell anything about that, but using the said package from the user repository solved the problem for me reliably.
Try this one (which I installed just yesterday under the recent manjaro distribution and it worked fine) and see if this solves your problem with opening files and folders.
I have a node app that is going to run on a small touch screen device that has an ARM CPU. The app itself is pretty simple. I reads data from syslog and sends an ipc message to another process if it finds a log entry with some specific data.
My concern is whether or not there will be any issues with installing the npm dependencies on a build machine which is running on a different architecture and then copying it onto the ARM device. The build machine is likely to be a 64 bit Mac or Linux box.
The app seems to work fine when I run npm install on my mac and then copy the resulting node_modules folder onto the ARM device. However, I had written electron apps for this same ARM device that required us to use electron-packager with a target architecture of
--platform=linux --arch=armv7l
for it to run. Simply installing the node_modules on a mac then copying them over did not work in that case.
So what is the difference? Is it just the use of electron itself that requires the platform specific build or is it something else I might run into with this new app I'm writing?
You can find platform specific file by executing:
find node_modules -name "*.node" |xargs file
I want to customize an image I created for an ARM device (Odroid C1+). Especially I want to checkout some git repositories and install their dependencies.
But when installing go libraries, this bug is happening: https://github.com/golang/go/issues/13024
Is there a workaround? Or do you know another user emulator (or similar) to do this?
A workaround would be to use full system emulation in QEMU - just find an ARM kernel that boots in qemu-system-arm and instead of chrooting into the file system from the host, do it from within QEMU.
So I am using Ozone OS which is basically just fedora with a cool theme, and a lot less crap installed. I tried installing VMWare Horizon view client from here: https://my.vmware.com/web/vmware/details?downloadGroup=VIEWCLIENTS_LINUX_32&productId=421&rPId=7320
and then i renamed the file to vmware.bundle, when i make it runnable with:
chmod +x vmware.bundle
i ran the file using:
./vmware.bundle
this is what happens in my terminal
VMWare Horizon Client is an x86 application but you are trying to install it to an x64 Linux.
To run this installation, you may need to install 32-bit runtime libraries. Do you want to proceed? (yes/no)yes
Extracting VMware Installer...done.
but when i try going to the application menu, I can find VMware anywhere
There is really no such thing as ".bundle" files on Fedora. The only format for installable software on Fedora are RPM files.
All that this ".bundle" file appears to be, is the vendor's custom installation script, that's all. It's not any kind of a standard packaging format, of any kind.
You will be able to find a newly-installed application on your application menu only if the application correctly installed a .desktop file in the right location. If this installation script did not do so, you won't get anything in the application menu.
It is the application script's responsibility to install a .desktop file in order for the application to appear in the application menu.
try running /bin/vmware
that is the default install location
I have a need to generate my air app online on my linux webserver. I create a signature and package the app up with adt and then download it to my desktop mac and try and install it, it says the package is corrupt and to get another copy. But when I compile it on the mac (using the exact same commands to adt) it installs and runs fine.
Why is packaging using the linux SDK creating corrupt .air files ?
It seems the adt binary doesn't work 100% in Linux.