I need to use python3.7m instead of default python3.8 in my buildroot project. Is there a solution for that or only way is get older buildroot version?
You do not have to downgrade Buildroot. You can always add a custom python3 package based on an older version, e.g.: https://git.busybox.net/buildroot/tree/package/python3?id=b3424c8fc9d1199f5836483f15af48b56373609e
Here the documentation on how to add a package:
https://buildroot.org/downloads/manual/manual.html#adding-packages
One possibility is to add a custom package with a different python version, as #Ezra Bühler explained. However, that custom package must have a different name than python3, which means that you also need to make custom versions of all packages that use python3.
Therefore, a simpler possibility is to modify the Buildroot code itself. There's normally no need to go back to an older Buildroot version - instead, you can take just copy and overwrite python3 from an older version that still has python 3.7. Of course, this is a completely untested configuration so you might encounter some breakage, but it's usually doable. If you take that route, you'll want to also update python to the latest (currently python 3.7.11).
Related
I keep getting the following error, I'm using meteor 2.1 currently
Error: A new entrypoint in the #emotion/styled package, #emotion/styled/base, has replaced the #emotion/styled-base package. Please remove this package and use #emotion/styled/base instead.
i cannot find ANY way to install this #emotion/styled/base package. #emotion/styled-base is installed and i cannot create a build suddenly.
any suggestions???
I'm using react.js
#emotion/styled/base isn't a package you need to install, but rather its a submodule of the #emotion/styled package.
I have a hunch that you are not using #emotion/styled-base directly, so most likely what you have is a version mismatch where you have a newer version of #emotion/styled installed, but that package is written for an older version. You'll probably just need to locate this offending package and update it.
If this isn't the case, then you'll just need to replace your imports for #emotion/styled-base with ones for #emotion/styled/base
For example I have Intellij Idea installed on my Arch Linux system. Intellij Idea has built in updater and assume that I's already updated Intellij Idea with that built in Intellij Idea updater. But when I perform "yaourt -Syu" corresponding Intellij Idea's package is still shown in list of packages that are waiting for updates. So how can I say yaourt or pacman (or any other pacman wrapper that may have such feature) that package is already updated?
If you just want that Feature I would recommend yay to you, it has that Feature to skip an installation of a Packet! As discussed here you shouldn't use yaourt anymore.
If you don't want that update Problem at all install jetbrains-toolbox which will manage your installed IDEs, if you are using more than one, so you only have to update the toolbox once in a while.
The problem is that you haven't updated it. You've overwritten the copy pacman knows about, with an untracked copy from elsewhere.
So, of course, pacman's metadata will not be updated. In order to circumvent this you'd need to create a custom dummy package which provides intellij, while managing it entirely yourself.
But what is wrong with using the official repository package https://www.archlinux.org/packages/?name=intellij-idea-community-edition and just letting pacman update it for you?
What is the best way to ensure that all developers and the build server are using the latest version of FAKE?
If a build.cmd like the one from FSharp.Data is used, the developer will not be on the latest until they delete FAKE from the packages folder or just delete the whole packages folder.
If you add FAKE as a dependency in .nuget\packages.config, your build.fsx script must include the version information and be updated each time you change versions. You will not automatically get the latest version.
With NuGet 2.8.1 you can remove the "if not exists" parts - NuGet will check (very slowly) if the latest FAKE is installed.
I would like to install a complete new version of Trac alongside of our current version (0.11.7) and I am looking for ways to do this. After some research, it says to use python's virtualenv, but I am trying to find specific steps on how to accomplish this without interfering with our 0.11.7 version at all.
I am using Ubuntu as the OS. Any input including any possible pitfalls is appreciated.
Try virtualenvwrapper that makes using python-virtualenv a breeze.
The steps to create and use such a Python virtual environment are explained in the user documentation. These environments form the core setup of my own Trac plugin development. It allows to even use custom python versions, if you ever need that. I found the need to give each environment a self-explaining name and use it with different Trac environment directories matching the db version required by different Trac versions, i.e. virtualenv "trac-0.11_py2.4" with Trac env "sandbox_0.11", "trac-0.12_py2.6" with Trac env "sandbox_0.12", etc.
I've created repository where I store my own packages.
System uses my and some other public repositories.
So now I've a package in my repo which I want to be as an update for some other package from another repository.
The repositories are rpm package based.
Is it generally possible to mark my own package to update another package ?
(I would have made this a comment on the previous answer, but its too long.)
There's a problem with using the same package name and just bumping the version number.
Eventually the original package may increase its version number past what you're using, in which case someone may do a yum update and end up upgrading back to the original package.
To avoid this problem, you can change the package name slightly, and add some Obsoletes and Conflicts dependencies to your spec file. The Obsoletes dependency allows the original package to be upgraded to your package, while the Conflicts keeps the original package from being installed at the same time as your package.
This should keep an upstream version bump from clobbering your changes.
See http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-dependencies.html
Going to answer to my own question, yes yum treats all repositories equally. So all I need to do was setting package name the same and increased version number.
To test it you just need to create a yum repo and setup yum to use your repository for more info look here