User-mode
By default you would probably have something like this, the user-mode network:
|
<interface type="user">
<mac address="00:00:00:00:00:00"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
|
Bridge
Bridges can be easily created using the NetworkManager’s TUI tool called nmtui
.
Bridge XML configuration for Libvirt
|
<interface type="bridge">
<mac address="00:00:00:00:00:00"/>
<source bridge="br1"/>
<target dev="vnet2"/>
<model type="virtio"/>
<alias name="net0"/>
<address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/>
</interface>
|
Sysctl options
Be sure the following options are enabled (1
):
net.ipv4.ip_forward
net.ipv4.conf.all.send_redirects
and the following options are disabled (0
):
net.bridge.bridge-nf-call-iptables
Building PowerShell
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.
By default pwsh
tries to find modules in paths:
- user’s modules directory —
~/.local/share/powershell/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
.
|
dotnet-pkg-utils_append_launchervar \
'PSModulePath="${PSModulePath}:/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.
Take a look at this example from the app-pwsh/posh-dotnet–1.2.3 ebuild:
|
src_install() {
insinto /usr/share/GentooPowerShell/Modules/${PN}/${PV}
doins ${PN}.psd1 ${PN}.psm1
einstalldocs
}
|
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.
Binpkgs generated by user
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.
Patching
The file lit.site.cfg
has to be inspected for any incorrect calls to executables. For example see src_prepare
function form dev-lang/boogie.
Eclasses
Because we will need to specify how many threads should lit
run we need to inherit multiprocessing
to detect how many parallel jobs the portage config sets.
Dependencies
Ensure that dev-python/lit
is in BDEPEND
, but also additional packages may be needed, for example dev-python/OutputCheck
.
|
BDEPEND="
${RDEPEND}
test? (
dev-python/lit
dev-python/OutputCheck
)
"
|
Bad tests
To deal with bad test you can simply remove the files causing the failures.
|
local -a bad_tests=(
civl/inductive-sequentialization/BroadcastConsensus.bpl
civl/inductive-sequentialization/PingPong.bpl
livevars/bla1.bpl
)
local bad_test
for bad_test in ${bad_tests[@]} ; do
rm "${S}"/Test/${bad_test} || die
done
|
Test phase
--threads $(makeopts_jobs)
specifies how many parallel tests to run.
--verbose
option will show output of failed tests.
Last lit
argument specifies where lit
should look for lit.site.cfg
and tests.
|
src_test() {
lit --threads $(makeopts_jobs) --verbose "${S}"/Test || die
}
|
Portage
Configure the following for Portage.
Emerge
Emerge the following packages:
app-emacs/company-ebuild
dev-util/pkgcheck
Company-Ebuild should pull in app-emacs/ebuild-mode
, if that does not happen, then report a bug ;-D
Standard
Add the following to your user's Emacs initialization file. The initialization file is either ~/.emacs.d/init.el
or ~/.config/emacs/init.el
for newer versions of GNU Emacs.
|
(require 'ebuild-mode)
(require 'company-ebuild)
(require 'flycheck)
(require 'flycheck-pkgcheck)
(add-hook 'ebuild-mode-hook 'company-ebuild-setup)
(add-hook 'ebuild-mode-hook 'flycheck-mode)
(add-hook 'ebuild-mode-hook 'flycheck-pkgcheck-setup)
|
Use-Package
We can also configure our environment using a use-package
macro that simplifies the setup a little bit.
To use the below configuration the app-emacs/use-package
package will have to be installed.
|
(require 'use-package)
(use-package ebuild-mode
:defer t
:mode "\\.\\(ebuild\\|eclass\\)\\'"
:hook
((ebuild-mode . company-ebuild-setup)
(ebuild-mode . flycheck-mode)
(ebuild-mode . flycheck-pkgcheck-setup)))
|
The :defer t
and :mode "..."
enable deferred loading which theoretically speeds up GNU Emacs initialization time at the cost of running the whole use-package
block of ebuild-mode
configuration when the :mode
condition is met.
Prototype
Recently while browsing the Alpine git repo I noticed they have a function called snapshot
, see: https://git.alpinelinux.org/aports/tree/testing/dart/APKBUILD#n45 I am not 100% sure about how that works but a wild guess is that the developers can run that function to fetch the sources and maybe later upload them to the Alpine repo or some sort of (cloud?) storage.
In Portage there exists a pkg_config
function used to run miscellaneous configuration for packages. The only major difference between src_snapshot
and that would of course be that users would never run snapshot
.
Sandbox
Probably only the network sandbox
would have to be lifted out… to fetch the sources of course.
But also a few (at least one?) special directories and variables would be useful.
Fosstodon
If you prefer to follow my posts on Fosstodon via RSS, then here is the link: fosstodon.org/users/xgqt.rss.