install virtualbox modules from nixos-unstable in configuration.nix - virtualbox

It is possible to install packages from nixos-unstable in /etc/nixos/configuration.nix using the configuration from this answer.
Here is an example of installing the htop packages from nixos-unstable:
{ config, pkgs, ... }:
let
unstableTarball =
fetchTarball
https://github.com/NixOS/nixpkgs-channels/archive/nixos-unstable.tar.gz;
in
{
...
nixpkgs.config = {
packageOverrides = pkgs: {
unstable = import unstableTarball {
config = config.nixpkgs.config;
};
};
};
environment.systemPackages = with pkgs; [
...
unstable.htop
];
...
};
I would like to be able to install the Virtualbox package (and related kernel modules) from nixos-unstable as well.
Naively adding the virtualbox package to environment.systemPackages doesn't work like I expect it would. The Virtualbox modules matching the unstable version of Virtualbox do not get installed. Here is a snippet from my /etc/nixos/configuration.nix:
nixpkgs.config.virtualbox.enableExtensionPack = true;
virtualisation.virtualbox.host.enable = true;
environment.systemPackages = with pkgs; [
...
unstable.virtualbox
];
The above will correctly install the virtualbox package from nixos-unstable, but not the Virtualbox kernel modules.
How can I get the Virtualbox kernel modules to be installed from nixos-unstable as well? And why doesn't the above work?

Your configuration does not work, because the virtualbox module has its own reference to the virtualbox package. Perhaps its should expose an option to override the package like some other modules do, but for now it doesn't. It shouldn't be hard to make a pull request for it.
The alternative is to replace the offending module/modules by disabling the using disabledModules and then importing your replacements with imports.
Either way, your mileage may vary. The first option seems to be the cleanest to me, but you may want to check the differences between the nixos modules in your release and unstable versions.

The original kernel module is installed, because it is built separately, against a specific kernel. Normally, the virtualbox-host module keeps the kernel module and the user program in sync.
When you want to override the user program, you would also need to override the kernel module. This would amount to something like this:
!!untested code!!
...
boot.kernelPackages = pkgs.linuxPackages.extend (self: super: {
virtualbox = super.virtualbox.override {
inherit (self) kernel;
};
virtualboxGuestAdditions = super.virtualboxGuestAdditions.override {
inherit (self) kernel;
};
});
## also, the user program override should be introduced
## directly at packageOverrides
nixpkgs.config.packageOverrides = pkgs: rec {
unstable = import
(fetchTarball https://github.com/NixOS/nixpkgs-channels/archive/nixos-unstable.tar.gz) {
config = config.nixpkgs.config;
};
virtualbox = unstable.virtualbox;
};
...
Something like this should allow you to run the regular virtualbox-host module, with the unstable packages injected.

Related

Symlinking metro.config breaks from Expo SDK 44 to 46. How to symlink in 46?

I started a new mobile app project and since we have our own mobile components for reusability, we also use symlinking from the local component to the Expo app to make sure it's being developed properly. We have successfully linked prior Expo apps using SDK 44, but in this new project, we decided to use the most recent 46. It seems when I update the metro.config file the same as before, the bundler crashes.
default metro.config
const { getDefaultConfig } = require('expo/metro-config');
const path = require('path');
// const workspaceRoot = path.resolve(__dirname, '../myComponentLib'); // this gets uncommented when using a link
const defaultConfig = getDefaultConfig(__dirname);
defaultConfig.transformer.babelTransformerPath = require.resolve(
'react-native-svg-transformer',
);
const assetExts = defaultConfig.resolver.assetExts;
const sourceExts = defaultConfig.resolver.sourceExts;
defaultConfig.resolver = {
assetExts: assetExts.filter((ext) => ext !== 'svg'),
sourceExts: [...sourceExts, 'svg'],
};
defaultConfig.resolver.nodeModulesPaths = [
path.resolve(__dirname, 'node_modules'),
// path.resolve(workspaceRoot, 'packages/mobile/node_modules'), // this gets uncommented when using a link
];
// defaultConfig.watchFolders = [path.resolve(workspaceRoot)]; // this gets uncommented when using a link
module.exports = defaultConfig;
When I use the metro.config like above, it's fine. But if I uncomment the 3 lines notes, it fails. The error I get is:
I am curious, is there a difference in linking between the different SDKs now?
Wow, the reason for this is hidden well inside the docs: https://docs.expo.dev/guides/monorepos/#modify-the-metro-config
Scroll down to the section:
Why do we need to watch all the files with the monorepo?
Their example to watch scoped package names does the trick:
// If your monorepo tooling can give you the list of monorepo workspaces linked
// in your app workspace, you can automate this list instead of hardcoding them.
const monorepoPackages = {
'#acme/api': path.resolve(workspaceRoot, 'packages/api'),
'#acme/components': path.resolve(workspaceRoot, 'packages/components'),
};

How can I configure Jenkins using .groovy config file to set up 'Build strategies -> Tags' in my multi-branch pipeline?

I want something similar for 'Basic Branch Build Strategies' plugin https://plugins.jenkins.io/basic-branch-build-strategies
I figure out to make it something like this but it's not working:
def traits = it / sources / data / 'jenkins.branch.BranchSource' / source / traits
traits << 'com.cloudbees.jenkins.plugins.bitbucket.TagDiscoveryTrait' {
strategyId(3)
}
traits << 'jenkins.branch.buildstrategies.basic.TagBuildStrategyImpl' {
strategyId(1)
}
Here you can find full config file: https://gist.github.com/sobi3ch/170bfb0abc4b7d91a1f757a9db07decf
The first trait is working fine 'TagDiscoveryTrait' but second (my change) doesn't apply on Jenkins restart, 'TagBuildStrategyImpl'.
How can I configure 'Build strategies -> Tags' in .groovy config for my multibranch pipeline using 'Basic Branch Build Strategies' plugin?
UPDATE: Maybe I don't need to use traits at all. Maybe there is a simpler solution. I'm not expert in Jenkins groovy configuration.
UPDATE 2: This is scan log for my code https://gist.github.com/sobi3ch/74051b3e33967d2dd9dc7853bfb0799d
I am using the following Groovy init script to setup a Jenkins job with a "tag" build strategy.
def job = instance.createProject(WorkflowMultiBranchProject.class, "<job-name>")
PersistedList sources = job.getSourcesList()
// I am using Bitbucket, you need to replace this with your source
def pullRequestSource = new BitbucketSCMSource("<repo-owner>", "<repo-name>")
def source = new BranchSource(pullRequestSource)
source.setBuildStrategies([new TagBuildStrategyImpl(null, null)])
sources.add(source)
If I am recognizing the syntax correctly, the question is about Job DSL plugin.
The problem with the attempted solution is that the TagBuildStrategyImpl is not a Trait (known as Behavior in UI) but a Build Strategy. The error confirms this:
java.lang.ClassCastException: jenkins.branch.buildstrategies.basic.TagBuildStrategyImpl cannot be cast to jenkins.scm.api.trait.SCMSourceTrait
Class cannot be cast because TagBuildStrategyImpl does not extend SCMSourceTrait, it extends BranchBuildStrategy.
The best way to discover the JobDSL syntax applicable for a specific installation of Jenkins is to use the built-in Job DSL API Viewer. It is available under <jenkins-location>/plugin/job-dsl/api-viewer/index.html, e.g. https://ci.jenkins.io/plugin/job-dsl/api-viewer/index.html
On the version I am running what you are try to achieve would look approximately like this:
multibranchPipelineJob('foo') {
branchSources {
branchSource {
source {
bitbucket {
...
traits {
bitbucketTagDiscovery()
}
}
}
buildStrategies {
buildTags { ... }
}
}
}
}

Swift 3: How to implement Cocoapods into project?

I'm a beginner to swift 3 and cocoapods and i want to implement this https://github.com/luowenxing/MTImagePicker image picker for my project.
I've installed the pod into my project and am using the .xcworkspace file.
However, I'm facing problems as i've errors like:
No such module 'MTImagePicker'
Use of unresolved identifier 'MTImagePickerController'
Use of undeclared type 'MTImagePickerAssetsModel'
I've moved the MTImagePicker folder into my project as instructed.
But I'm still having this problem.
Any help is much appreciated.
Thank you so much!
Edited:
Podfile
# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'
target 'BPMatters' do
# Comment the next line if you're not using Swift and don't want to use dynamic frameworks
use_frameworks!
# Pods for BPMatters
source 'https://github.com/CocoaPods/Specs.git'
pod 'MTImagePicker', '~> 1.0.1'
target 'BPMattersTests' do
inherit! :search_paths
# Pods for testing
end
target 'BPMattersUITests' do
inherit! :search_paths
# Pods for testing
end
end
#objc protocol MTImagePickerControllerDelegate:NSObjectProtocol {
// Implement it when setting source to MTImagePickerSource.ALAsset
optional func imagePickerController(picker:MTImagePickerController, didFinishPickingWithAssetsModels models:[MTImagePickerAssetsModel])
// Implement it when setting source to MTImagePickerSource.Photos
#available(iOS 8.0, *)
optional func imagePickerController(picker:MTImagePickerController, didFinishPickingWithPhotosModels models:[MTImagePickerPhotosModel])
optional func imagePickerControllerDidCancel(picker: MTImagePickerController)
}
///third party image picker////
func thirdPartyImagePicker(){
let imagePicker = MTImagePickerController.instance
imagePicker.mediaTypes = [MTImagePickerMediaType.Photo,MTImagePickerMediaType.Video]
imagePicker.imagePickerDelegate = self
imagePicker.maxCount = 10 // max select count
imagePicker.defaultShowCameraRoll = true // when set to true would show Camera Roll Album like WeChat by default.
//default is MTImagePickerSource.ALAsset
imagePicker.source = MTImagePickerSource.ALAsset
//imagePicker.source = MTImagePickerSource.Photos (Work on iOS8+)
self.presentViewController(imagePicker, animated: true, completion: nil)
}
///third party image picker end///
Screenshot of Terminal after pod install
Solution: I got my stuffs working by doing this: https://stackoverflow.com/a/39435421/7498313
I marked Faris Sbahi's answer as the correct answer as I believe his answers can help beginners like me to set up the cocoapods and implementation of the project.
Thank you so much! :)
import MTImagePicker at the top of your class.
Update your Podfile to
Podfile
# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'
use_frameworks!
target 'BPMatters' do
# Pods for BPMatters
pod 'MTImagePicker', '~> 1.0.1'
end
target 'BPMattersTests' do
inherit! :search_paths
# Pods for testing
end
target 'BPMattersUITests' do
inherit! :search_paths
# Pods for testing
end
After updating your Podfile to this, run pod install and ensure no errors are returned. After doing so, open the xcworkspace file and when you attempt to build ensure that the target is BPMatters.
Be sure that in the side pane you see something like this:
With a folder for MTImagePicker

Enumerate Upgrade Codes of installed products?

I'd like to get list of all Upgrade codes of all installed products on Windows box. The question is: is there a dedicated MSI function to address this request?
There is MsiEnumProducts() that enumerates all installed products and MsiEnumRelatedProducts() to enumerate all products for the given Upgrade code. But I can't find a function to get all Upgrade codes in the system.
The workaround I can imagine is use MsiEnumProducts() to get list of all installed products, open each with MsiOpenProduct() function and read "UpgradeCode" property with MsiGetProductProperty(). But this should be very slow due to multiple MsiOpenProduct() calls.
I believe MsiEnumProducts loop with MsiOpenProduct and then MsiGetProductProperty is the correct official sequence. If you really need faster and are willing to bypass the API's you could read the registry directly at HKCR\Installer\UpgradeCodes. You'll have to reverse the Darwin Descriptors though. This isn't technically supported but the reality is these keys have been there for 16 years and MSFT has been doing ZERO development on The Windows Installer. Ok, maybe they updated the version number and removed ARM support in Windows 10 LOL.
FWIW, I like to use C# not C++ but the concept is the same. The following snippet ran on my developer machine in about 2 seconds.
using System;
using Microsoft.Deployment.WindowsInstaller;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
foreach (var productInstallation in ProductInstallation.AllProducts)
{
using(var database = new Database(productInstallation.LocalPackage, DatabaseOpenMode.ReadOnly))
{
Console.WriteLine(database.ExecutePropertyQuery("UpgradeCode"));
}
}
}
}
}
According to the DTF documentation, ProductInstallation.AllProducts uses MsiEnumProducts. The Database class constructor is using MsiOpenDatabase and ExecutePropertyQuery is a higher level call that basically abstracts doing a SELECT Value from Property WHERE Property = '%s'. So it'll be calling APIs to create, execute and fetch results from views. All these classes implement IDisposable to call the correct APIs to free resources also.
Ya... that's why I love managed code. :)

Dojo build to single file

I want to build my Dojo JavaScript code that I have carefully structured into packages into a single JavaScript file. I'm a little confused as to how to do it.
For now I have this:
var profile = {
...
layers: {
'app': {
include: [
'dojo/module1',
'dojo/module2',
...,
'dojo/moduleN',
'package2/module1',
'package2/module2',
...,
'package2/moduleN'
]
}
}
...
};
Do I really have to manually add all the modules to the app layer? Can't I just say "all", or better yet, "all referenced"? I don't want to include the dojo/something modul if I don't use it. Also, in my release folder, that's all I would like to have - one file.
So - can this even be achieved? Clean Dojo automatic build of only referenced modules into a single (minified and obfuscated of course) JavaScript file?
Take a look at the examples in the Layers section of this build tutorial:
It’s also possible to create a custom build of dojo.js; this is particularly relevant when using AMD, since by default (for backwards compatibility), the dojo/main module is added automatically by the build system to dojo.js, which wastes space by loading modules that your code may not actually use. In order to create a custom build of dojo.js, you simply define it as a separate layer, setting both customBase and boot to true:
var profile = {
layers: {
"dojo/dojo": {
include: [ "dojo/dojo", "app/main" ],
customBase: true,
boot: true
}
}
};
You can include an entire "app" in a single layer by including the root of that app (or module). Note that if a module in that app is not explicitly required by that app, it would have to be included manually. See the second example in the Layers section in the above tutorial for an illustration of that.
You can also define packages to include in your layers, if you want to change or customize the layout of your project:
packages: [
{name:'dojo', location:'other/dojotoolkit/location/dojo'},
/* ... */
],
layers: {
'dojo/dojo': { include: ['dojo/dojo'] },
/* ... */
}
You don't have to specify all the modules, if the module you add already has dependencies on others. For example, if you include 'app/MainApplication' to a layer, the builder would include all the modules that app/MainApplication depens on. If your MainApplication.js touches everything in your project, everything would be included.
During the build of a layer, dojo parses require() and define() calls in every module. Then it builds the dependency tree. Nls resources are also included.
In your code, you should name your layer as a file in existing package. In my build, it caused errors when I name a layer with a single word. You should code
var profile =
layers: {
'existingPackage/fileName': {
...
}
}
If you want to have exacltly one file, you have to include 'dojo/dojo' in your layer and specify customBase and boot flags.
Dojo always build every package before building layers. You will always have dojo and dijit folders in your release directory containing minified versions of dojo filies in them.
Just copy the layer file you need and delete everything other.