The repository 'https://packagecloud.io/realm/realm/linuxmint serena Release' does not have a Release file.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
We don't support Linux Mint at this time.
Edit regarding the comment:
We support Linux. It's the only platform we support in production.
We support Ubuntu 16.04, CentOS 6 & 7 (as indicated on the website). You can trivially create a docker container or VM using one of these base images on Linux Mint. We have a number of issues requesting Debian support, Fedora support, native Docker image, but none formally requesting Linux Mint support.
We obviously want to make the experience as painless as possible for everyone, but we also have to be very strategic when deciding to add a new platform as officially supported. Our CI has to build and test every single change on this new platform. We have to be able to support our users, etc. For example, we already have some bugs that only appear on CentOS 6, but not on 7 nor Ubuntu, so we want to make sure we stabilise things before moving ahead.
Feel free to submit a feature request to support Linux Mint. That way you will have a place where you can ask us directly about progress.
Related
I'm currently working on an application that I would like to publish to many distributions. So far, I've done all my testing on one distribution at a time (compile and run on the same distro). But when I take the outputted AppImage from compilation on my main computer (Arch Linux), and try to run it in a vm (Ubuntu 20.04), it gives me the error below:
gabriel#gabriel-VirtualBox:~/Downloads$ ./Neptune.Installer-x86_64.AppImage ./Neptune.Installer-x86_64.AppImage: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./Neptune.Installer-x86_64.AppImage)
What possible solutions are there to this? I've considered statically linking the library, but I'm unsure if that might cause licensing issues, as my program is not open source. Apart from that, I might consider simply compiling my program on a very old distribution such as Ubuntu 12 or something, but I won't know how well that carries over to other distros (for example, will my program still work on an old version of Fedora?)
This might be a complicated question but I just want to know what the best way to solve this issue is. Change libraries? Statically link? Compile on old distributions? Let me know what you think.
I've considered statically linking the library, but I'm unsure if that might cause licensing issues,
Yes.
very old distribution such as Ubuntu 12 or something, but I won't know how well that carries over to other distros
It doesn't (alpine linux). If you compile software, you have to run it with the set of libraries you compiled it against. Even if you compile on "very old distributions" there may be changes.
publish to many distributions
Choose the list of distributions and versions of these distributions you want to support. Tell users that you will support these distribution versions. (https://partner.steamgames.com/doc/store/application/platforms -> Steam only officially supports Ubuntu running Ubuntu 12.04 LTS or newer..).
Compile against every combination of distribution+version separately, and distribute your software separately for every such distribution version. For users convenience, create and share package repositories for specific distribution package manager with your software. On https://www.zabbix.com/download there are only so many combinations to choose from. Interest yourself in CI/CD in docker virtualized environments. I like gitlab.
Or alternatively distribute your application with all dependent shared libraries. Bundle it all together with the operating system and distribute in a form of a docker image or a qemu/virtualbox virtual image. Or distribute with just shared libraries files with a wrapper around LD_PRELOAD. Just like steam does. Install steam on your system, and see what happens in ~/.steam/steam/ubuntu12_64.
And hire a layer to solve the licensing issues.
Since Mac OS 11 Big Sur release Apple allows installation of kext drivers in the Recovery mode only.
It also prohibits installation of kext drivers from Apple store. Which I guess is the end of macFuse, at least for virtual/cloud file systems.
What would be the migration path and how to build virtual file systems for Mac OS 11+, in particular for document management and cloud storage, similar to OneDrive, DropBox, etc.
I can also guess that a similar issue may appear on Windows too. I can imagine that Microsoft will follow Apple's path and will prohibit file system drivers and filters on Windows for these purposes in future releases.
Any hint for future migration if such a situation happens would be appreciated.
Since macOS 11, Apple has updated documentation of the File Provider API which can be used to sync files between client and server and may serve as a replacement for file system drivers. Until this day Apple has not officially announced that functionality on macOS.
The API is similar to the File Provider API that Apple has provided for iOS 11 some time ago but still it has some differences in mostly how main FileProvider class extension works and which abilities it has. There is no examples at this moment that I’ve seen but it looks like this functionality works at least on basic level. Based on what people say on the forums.
On Windows, Microsoft has introduced the Cloud Storage Provider (Cloud Sync Engine) API for Windows 10 in the year 2018 (Windows Creators update). It is used in One Drive for Windows. Here are some examples on GitHub in C++ and in C#.
The error message I get is:
This release is not compliant with the Google Play 64-bit requirement
The following APK or App Bundles are available to 64-bit devices, but they only have 32-bit native code: 180.
Include 64-bit and 32-bit native code in your app. Use the Android App Bundle publishing format to automatically ensure that each device architecture receives only the native code it needs. This avoids increasing the overall size of your app. Learn More. The Start to roll out button is then disabled.
I am guessing I used a cn1lib which is not 64bit compliant or some native code which is not
I have the following libraries installed
QR Maker.cn1lib
QR Scanner.cn1lib
Zip Support.cn1lib
cn1-codescan.cn1lib
The following is the native code I have on:
Codename One, the native code you used and 3 of these libraries are in Java which means they support all Android platforms.
The only exception is QRScanner.cn1lib which was updated to support 64 bit and fix quite a few issues ages ago so I doubt it has a problem. It's possible you have something from an older version of that library still in your system. Try uninstalling it and see if this resolves the issue. Assuming it does try re-installing it with a fresh copy.
I want to create native C extensions to PostgreSQL 9.5 64bit on Windows.
I would love to build them with MinGW-w64 if that's possible, to get my build chain as clean as possible. But I am using the EnterpriseDB build of PostgreSQL, and MinGW build crashes it.
It would also be okay if there is another free compiler that I can use in this commercial project.
I know how to get this to work with Visual Studio 2003 Express but that doesn't seem to be a solution because of License issues.
Addition to the Main Answer
In the article linked below, you can read that it is possible to write C modules using Mingw or Cygwin, and some guidelines regarding the same. However I highly discourage doing so, mostly because of the reasons listed below, and also because that page mentions that those Windows configurations have special needs and receive lighter testing than most; expect a greater incidence of build problems
Here is the full excerpt on Unix-like Platform:
Unix-like Platforms
PGXS originated on Unix-like systems, and it is easy to use there. Unpack the extension module archive and run these commands in the resulting directory:
make PG_CONFIG=path_to_postgresql_installation/bin/pg_config
make PG_CONFIG=path_to_postgresql_installation/bin/pg_config install
You may omit the PG_CONFIG overrides if running type pg_config in your shell locates the correct PostgreSQL installation. Subject to the ownership of the existing PostgreSQL installation directories, the second command will often require root privileges. These instructions also apply when building for Windows using the MinGW or Cygwin compilers. However, those Windows configurations have special needs and receive lighter testing than most; expect a greater incidence of build problems.
A common mistake is to specify the PG_CONFIG=... on the command line before the 'make', which does not work as the value is then overridden by the inner workings of makefiles.
It's important to know that different compilers are not compatible with each other. Each of them have different runtime libraries. So it is very risky to compile extensions with a different compiler other than the one used to build the software you are using.
Postgresql's Windows build uses Visual Studio, same with EnterpriseDB (as far as I know). You will need to use the same compiler to build your extensions.
(For more information please refer: Building and Installing PostgreSQL Extension Modules and Postgres Enterprise Manager Installation Guide - EnterpriseDB (PDF))
This should explain why your extensions compiled with Mingw-w64 crash.
Luckily, there are two solutions you could choose:
Use Microsoft Visual Studio Community. It is completely free for individual developers, however there are restrictions for businesses. It should compile proper modules for your Postgresql build.
Rebuild the compleat Postgresql binary with Mingw-w64 or any other compiler of your choice (LLVM/Clang maybe), and then compile extensions with the same.
Doing either of these should help you. And this applies to all platforms, languages, and other softwares too. If you want to build extensions for a software, you need the same compiler, on the same platform used to build the software being used.
So, if you want to build extensions for Postgresql on Linux, you need the same compiler (probably GCC) to build extensions.
Happy coding =)
#Swith give you link to docs how to build PostgreSQL Extension Modules with Visual Studio and as you can read:
These instructions also apply when building for Windows using the MinGW or Cygwin compilers. However, those Windows configurations have special needs and receive lighter testing than most; expect a greater incidence of build problems.
A common mistake is to specify the PG_CONFIG=... on the command line before the 'make', which does not work as the value is then overridden by the inner workings of makefiles.
Did you check this ?
Also you can read other docs Building PostgreSQL With MinGW - maybe this help you more.
It would also be okay if there is another free compiler that I can use in this commercial project.
Did you check C compliers list on wiki - in particular, you can check Cygwin compiler - it's mentioned in docs above and it's free.
I know how to get this to work with Visual Studio 2003 Express but that doesn't seem to be a solution because of License issues.
What kind of issues do you see ?
Maybe check Visual Studio 2015 Community Edition (not Express) like #Simon Mourier suggest.
There is quite different licencing between Express and Community editions - I'm not sure about details, but as far I know Community Edition is more flexible for using in commercial projects:
For organizations:
An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects.
For all other usage scenarios:
In non-enterprise organizations, up to five users can use Visual Studio Community. In enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above.
For more information, see the Visual Studio Community license terms.
I'm looking for some advice on how to properly handle versioning when managing a distro using Yocto.
I have several embedded systems in production and have to rely on a third party to apply updates. Updates include one or more .ipk packages that get installed via opkg. I have no control over when the third parties apply the update(s) I send them. This introduces the issue I am trying to find a solution to. The systems are likely to be in various different states as some updates are applied and others are not. Is there a common solution to tell what state a system is in?
One problem I'm not clear on is how ensure the embedded system has certain updates applied before applying further updates. How do distros such as Ubuntu or Redhat handle this? Or do they?
Ubuntu and RedHat have a remote repositories. The systems have a internal list of installed packages. When you update the repository you get a new list of packages. You can then compare this list of installed packages against the new package list and install them. This is basically done with apt-get update && apt-get upgrade and the yum equivalent.
Yocto actually supports rpm and deb package format and their remote repositories. I am not familiar with opkg and if they have the option of a remote repository.
When I implemented a system I narrowed it down to the following options:
have a repository (deb and rpm definitely work here)
have a version package
using images
Version packages have the big disadvantages since you have to get your own logic on which packages to install. But you can require that version-1.deb needs software-v2.deb and tool-v1_5.deb. That works well with you own software but is a big manual overhead for the entire Yocto package stack.
Repository would be the usual way such as: apt-get update && apt-get -y upgrade. Works well and easy, but lacks also a risk free path to newer Yocto version.
The image way is more complicated and depends on your used hardware, size of image and transfer of the image. If you have a huge image and a slow network you might not want to do this. Basically you push your new image (or automatically pull it based on a version) d push it then to the device. The device dd's it to a secondary partition and then you flip the bootload to use the other partition. Depending on bootloader and/or hardware you can automatically flip back in case the partition you booted in is broken. Helpful for remote systems. Advantage is: you can also easily upgrade the entire OS without manually picking versions. And you can have (automatic) fail-over.