I really wanted to look into the new kernel building solutions for Gentoo and maybe migrate to dracut, but last time I tried, ~1.5 years ago, the initreamfs was now working for me.
And now in 2023 I’m still running genkernel for my personal boxes as well as other servers running Gentoo.
I guess some short term solutions really become defined tools :P
Some Elisp package compilation failures are caused by not setting the loadpath correctly. It mostly happens when you compile source from a directory that is not the current working directory. For example:
1
elisp-compileelisp/*.el
In most cases you can cd or override the S variable to set it to location where ELisp source resides.
But in other cases you can append to load path the directory with source, see:
elisp-make-autoload-file allows to name the generated autoload file. For sake of easier debugging and writing Gentoo SITEFILEs, please do not rename the generated file.
The name of that file should always be ${PN}-autoloads.el.
Use new elisp-enable-tests function
elisp-enable-tests allows to set up IUSE, RESTRICT, BDEPEND and the test runner function for running tests with the specified test runner.
The 1st (test-runner) argument must be one of:
buttercup — for buttercup provided via app-emacs/buttercup,
ert-runner — for ert-runner provided via app-emacs/ert-runner,
ert — for ERT, the built-in GNU Emacs test utility.
The 2nd argument is the directory where test are located, the leftover arguments are passed to the selected test runner.
Example:
1 2 3 4 5 6 7 8 910
EAPI=8
inheritelisp
# Other package settings ...SITEFILE="50${PN}-gentoo.el"DOCS=(README.md)
elisp-enable-testsbuttercuptest
Remove empty SITEFILEs
Recently a feature was added to elisp.eclass that will cause build process to generate the required SITEFILE with boilerplate code if it does not exist.
So if your SITEFILE looked like this:
1
(add-to-list'load-path"@SITELISP@")
… then, you can just remove that file.
But remember to keep the SITEFILE variable inside your ebuild:
1
SITEFILE="50${PN}-gentoo.el"
Remove pkg.el files
The *-pkg.el files are useless to Gentoo distribution model of Emacs Lisp packages and should be removed. It is as simple as adding this line to a ebuild:
1
ELISP_REMOVE="${PN}-pkg.el"
Beware that some packages will try to find their ${PN}-pkg.el file, but in most cases this will show up in failing package tests.
Use official repository
It is tedious to repackage Elpa tarballs, so use the official upstream even if you have to snapshot a specific commit.
To snapshot GitHub repos you would generally use this code:
1 2 3 4 5 6 7 8 910
# First check if we have the correct version to prevent# autobumping package version without changing the commit.[[${PV}==*_p20220325]]&&COMMIT=65c496d3d1d1298345beb9845840067bffb2ffd8
# Use correct URL that supports snapshots.SRC_URI="https://github.com/domtronn/${PN}/archive/${COMMIT}.tar.gz -> ${P}.tar.gz"# Override the temporary build directory variable.S="${WORKDIR}"/${PN}-${COMMIT}
Git is good, git tags are good. In case if upstream does not tag their package or just forgets to, kindly ask them to create a git tag when bumping Emacs package versions.
I wanted to echo parameter values when I set them in my blog’s frog.rkt config file.
Nothing simpler in Racket!
First I create this macro for echoing a single parameter value when it is set:
1 2 3 4 5 6 7 8 9101112
(define-syntax-rule(verbose-set-parameterparameter-idparameter-value)(begin;; Set the parameter.(parameter-idparameter-value);; Then call the parameter and print it's value.;; The "'parameter-id" is special syntax;; for turning a "parameter-id" identifier to a symbol.;; We can also write it like:;; > (quote parameter-id);; to be less confusing.(printf"[DEBUG] (~a ~v)\n"'parameter-id(parameter-id))))
then, I create a wrapper for above macro that can take multiple parameter pairs:
12345
(define-syntax-rule(verbose-set-parameters(parameter-idparameter-value)...)(begin;; Unpack a chain of "(parameter-id parameter-value)" pairs;; using the "..." syntax.(verbose-set-parameterparameter-idparameter-value)...))
Notice that even the form of setting a parameter, that is (parameter-procedure "value"), remains the same, but in reality it is just similar to how the syntax macro pattern-matches on it.
Inspecting macro expansion
In racket-mode inside GNU Emacs we can inspect the macro expansion with racket-expand-region. Stepping through the expansion provided this result:
Recently I was given a task to run a outdated piece of commercial software on a very outdated (in)famous operating system. Unlucky for me on the given VDI (VirtualBox disk image) the so-called “Guests Additions” that enabled “better” time synchronization were already installed.
Fighting VBox time
So, this is what I had to do to keep the old clock:
turn off networking card in the virtual machine configuration, because we do not want the system to use NTP or other newt service to get the “new” time,
and… this magic: VBoxManage modifyvm "WinXP"
--biossystemtimeoffset "-341597644449", this thing does the very weird thing of telling the virtual machine BIOS how much to set it back in time, the offset here is total milliseconds between some old date and current date.
Getting the old date
With the Python script snippet below you will get the milliseconds to set back the VirtualBox clock to 01.01.2012 01:00.
By implementing a method for equality equal-to? and two extraction methods equal-hash-code-of and equal-secondary-hash-code-of we can define our own object comparison rules.
As a part of my work of modernizing the way .NET SDK packages are distributed in Gentoo I delved into packaging a from-source build of PowerShell for Gentoo using the dotnet-pkg eclass.
Packaging pwsh was a little tricky but I got a lot of help from reading the Alpine Linux’s APKBUILD. I had to generate special C# code bindings with ResGen and repackage the PowerShell tarball. Other than this trick, restoring and building PowerShell was pretty straight forward with the NuGet package management support from the dotnet-pkg.eclass.
Alternatively if you do not want to build PowerShell you can install the binary package, I have in plans to keep that package around even after we get the non-binary app-shells/pwsh into the official Gentoo ebuild repository.
Why install modules via Portage?
But why stop on PowerShell when we can also package multiple PS modules?
Installing modules via Portage has many benefits:
better version control,
more control over global install,
no need to enable PS Gallery,
sandboxed builds,
using system .NET runtime.
Merging the modules
PowerShell’s method of finding modules is at follows: check paths from the PSModulePath environment variable for directories containing valid .psd1 files which define the PS modules.
system modules directory in /usr/local — /usr/local/share/powershell/Modules
Modules directory inside the pwsh home — for example /usr/share/pwsh-7.3/Modules
Because we do not want to touch either /usr/local nor pwsh home, we embed a special environment variable inside the pwsh launcher script to extend the path where pwsh looks for PS modules. The new module directory is located at /usr/share/GentooPowerShell/Modules.
So every PowerShell module will install it’s files inside /usr/share/GentooPowerShell/Modules.
To follow PS module location convention we add to that path a segment for the real module name and a segment for module version. This also enables us to have proper multi-slotting because most of the time the modules will not block installing other versions.
And that is it. Some packages do not even need to be compiled, they just need files placed into specific location. But when compilation of C# code is needed we have dotnet-pkg to help.
The binary packages generated by user can have architecture-specific optimizations because they are generated after they were compiled by the host Portage installation.
In addition binpkgs are generated from ebuilds so if there is a
USE flag incompatibility on the consumer system then the binpkg will not be installed on the host and Portage will fall back to
from-source compilation.
Those binary packages can use two formats: XPAK and GPKG.
XPAK had many issues and is getting superseded by the GPKG format. Beware of upcoming GPKG transition and if you must use XPAKs then you should explicitly enable it in your system’s Portage configuration.
To host a binary package distribution server see the Binary package guide on the Gentoo wiki.
Bin packages in a repository
Binary packages in ::gentoo (the official Gentoo repository) have the
-bin suffix.
Those packages might have USE flags but generally they are very limited in case of customizations or code optimizations because they were compiled either by a Gentoo developer or by a given package
upstream maintainer (or their CI/CD system).
Those packages land in ::gentoo mostly because it is too hard (or even impossible) to compile them natively by Portage. Most of the time those packages use very complicated build systems or do not play nice with network sandbox like (e.g. Scala-based projects) or use very large frameworks/libraries like (e.g.
Electron).
They can also be added to the repository because they are very
desirable either by normal users (e.g. www-client/firefox-bin) or for (from-source) package
bootstrapping purposes (e.g. dev-java/openjdk-bin). Such packages are sometimes generated from the regular source packages inside ::gentoo and later repackaged.