Various packaging related things
debconf stuff
http://www.debian.org/doc/packaging-manuals/debconf_specification.html
http://hezmatt.org/~mpalmer/talks/2002/debconf-use-and-abuse/view.pdf
https://www.debian.org/doc/manuals/dbconfig-common/common-using.html
Platform Specifics
Defines
As I always search for that while debugging KFreeBSD or Hurd build issues ...
gcc -dM -E -x c++ /dev/null # for C++ gcc -dM -E -x c /dev/null # for C
C/C++ tip: How to detect the operating system type using compiler predefined macros
C/C++ tip: How to detect the processor type using compiler predefined macros
Platform Endianness, Debian architectures and compiler host names
I can't remember mostly of the time what relationship between the Debian architecture names, Compiler specific host names and endianness exists ...
TODO: move this to ArchitectureSpecificsMemo
Debian architecture |
Compiler host name |
Endianness |
|
RC platform |
|||
i386 |
i686-pc-linux-gnu |
LE |
|
amd64 |
x86_64-pc-linux-gnu |
LE |
|
armel |
arm-unknown-linux-gnueabi |
LE |
|
armhf |
arm-unknown-linux-gnueabihf |
LE |
|
arm64 |
aarch64-unknown-linux-gnu |
LE |
|
mips |
mips-unknown-linux-gnu |
BE |
|
mips64el |
mips64el-unknown-linux-gnuabi64 |
LE |
|
mipsel |
mipsel-unknown-linux-gnu |
LE |
|
ppc64el |
powerpc64le-unknown-linux-gnu |
LE |
|
s390x |
s390x-ibm-linux-gnu |
BE |
|
non RC platform |
|||
alpha |
alpha-unknown-linux-gnu |
LE |
|
hppa |
hppa-unknown-linux-gnu |
BE |
|
hurd-386 |
i686-pc-gnu |
LE |
|
kfreebsd-i386 |
i686-pc-kfreebsd-gnu |
LE |
|
kfreebsd-amd64 |
x86_64-pc-kfreebsd-gnu |
LE |
|
m68k |
m68k-unknown-linux-gnu |
BE |
|
powerpc |
powerpc-unknown-linux-gnu |
BE |
|
powerpcspe |
powerpc-unknown-linux-gnuspe |
BE |
|
ppc64 |
powerpc64-unknown-linux-gnu |
BE |
|
sh4 |
sh4-unknown-linux-gnu |
LE |
|
sparc64 |
sparc64-unknown-linux-gnu |
BE |
|
x32 |
x86_64-pc-linux-gnux32 |
LE |
git-buildpackage
Setting up Hooks with git-buildpackage
Every time I new set up my PC I also can't remember that.
Setting up some global Hooks.
sudo mkdir /etc/pbuilder/hooks cd !$ sudo ln -s /usr/share/doc/pbuilder/examples/C11screen sudo ln -s /usr/share/doc/pbuilder/examples/D80no-man-db-rebuild
And enable them in the pbuilderrc.
sudo echo "HOOKDIR=/etc/pbuilder/hooks" >> /etc/pbuilderrc
Misc
Syncing source package and Debian files somethere
Instead of using scp with a complex call simply use dcmd (from devscripts package):
$ dcmd scp mypackage_99.2-1~exp1.dsc somehost.org:/foo/bar/mypackage-99.2
Searching for $package in Build-Depends,Build-Depends-Arch,Build-Depends-Indep
For preparation of a mass bug filing or simply research about the whole archive (depending on the used entries in sources.list), needs a installed package dctrl-tools and devscripts
$ grep-dctrl -FBuild-Depends,Build-Depends-Arch,Build-Depends-Indep $package /var/lib/apt/lists/*.debian.org_debian_dists_*Sources | dd-list --dctrl
make git-archive more useful
Sometimes I need to make a orig.tar.xz tarball from a upstream repo.
$ git config tar.tar.xz.command "xz -c" git archive --format=tar.xz --output=../mypackage_99.2.orig.tar.xz mypackage-0.99.2 # use a tag or ID
Turn Lenovo BIOS firmware ISO image into something bootable from USB
Lenovo is participating in the Linux Vendor Firmware Service and most of the Lenovo laptops are supported to getting firmware update through fwupd. But some types of laptops aren't getting updates this way or newer updates doesn't appear here. But you can update your device manually.
Unfortunately the ISO images you can get from the support website for your peace of hardware are not prepared to produce a bootable USB memory device. So you need to burn them on a CD. Or you rework the ISO image before writing to a USB stick. The former possibility is quite boring and produces a CD that you will only use once, so why not modify the ISO image to make it usable on a USB stick? For this you will need to have installed the package genisoimage.
Download the BIOS ISO image from the support website. (Take care you select the correct model!)
- Convert the ISO image using geteltorito.
$ geteltorito -o bios_update_x280.img ~/Downloads/n20ur21w.iso
- Burn the created *.img file on some random USB stick.
- Boot from this new created USB device and follow the instructions. Note you need to have the power plug connected!
Granting DM permissions
As I mostly forget to find this Wiki page DebianMaintainer#Granting_Permissions ...
$ dcut ftp-master dm --uid "username" --allow src:pkg1 src:pkg2
ARM based boards
TODO: move this to InstallingDebianOn The following stuff should finally go into the Installing Debian On X sites in the end. If someone wants to do so feel free, otherwise it's best to sort out some more things first.
Libre Computer Board AML-S905X-CC - Le Potato
The Le Potato is a ARM64 based Raspberry Pi-Like Single-Board Computer. It's created by Libre Computer and based on the Amlogic S905 processor, a 64-bit Quad Core ARM Cortex A53 SoC, with 2GB RAM and an eMMC interface.
Due the nature of the SoC (ARMv8) it needs a ATF and also a U-Boot that is knowing about internals of the ATF to start the board.
The Le Potato board is available since 1st October 2017 and development on upstream support of Linux kernel and U-Boot has just started a few months ago. The first notable Linux kernel with main line support for the Amlogic GXL family is 4.14. The current state of implementation is visible in the wiki of linux-meson. So it's obvious no full support and usability available right now.
Current state in Debian
While writing there is no support build in inside the Debian ecosystem, especially in the installer and probably never will be. The main issue right now is a no free available U-Boot and knowledge how to build and use the ATF binary. If you can give further details please ad them here!
Main work to build in support into main line kernel and U-boot is done by BayLibre and this mostly in person of Neil Armstrong.
There seems to be a way added in 2022 by Libre Computer to install a native Debian on the Le Potato without the need to use any pre-build images. https://docs.google.com/presentation/d/1wzYGJUg2xncSdfZ9075b5yYwOUgADz6iMO7ZmoZIkaM
Links
Manufacturer (also with links to resources of SD-card images) https://libre.computer/products/boards/aml-s905x-cc/
Kickstarter project https://www.kickstarter.com/projects/librecomputer/libre-computer-board-next-gen-4k-sbc-dev-board-for
Ordering https://www.loverpi.com/products/libre-computer-board-aml-s905x-cc
Ordering (Germany) https://www.bsgh.shop/hersteller/libre-computer/le-potato/
Support Forum http://forum.loverpi.com/categories/libre-computer-board-aml-s905x-cc
Product wiki http://wiki.loverpi.com/sbc-brand:libre-computer
Debian based images https://www.armbian.com/lepotato/
U-Boot contributions of Neil Armstrong https://patchwork.ozlabs.org/project/uboot/list/?series=&submitter=67289&state=*&q=&archive=both&delegate=
U-Boot git tree of BayLibre https://github.com/BayLibre/u-boot
ATF Arm Trusted Firmware reference implementation https://github.com/ARM-software/arm-trusted-firmware
Introduction into ATF (slightly outdated) https://de.slideshare.net/linaroorg/arm-trusted-firmareforarmv8alcu13
Blogpost about ATF on the HiKey boards https://prosauce.org/blog/2016/11/25/hands-on-introduction-to-arm-firmware-using-the-hikey
Presentation of the state of MainLine Linux on ?AmLogic S905 from the LinuxConfAU 2018 https://youtu.be/pScgOz1IbsY
Building an Upstream U-Boot binary
It's possible to build an u-boot from the upstream sources as BayLibre has forwarded their work into upstream U-Boot. The following instructions may not be fully correct and need additional steps (like creating the ATF) to get a fully working u-boot for the Libre Computer Board AML-S905X-CC. I collect them here to not need to collect them again.
We will need some additional needed packages.
$ sudo apt install bison flex crossbuild-essential-arm64
We need the upstream sources of U-Boot.
git clone https://github.com/u-boot/u-boot.git
No we can build the dedicated files for the AML-S905X-CC based board.
$ cd u-boot $ make libretech-cc_defconfig $ make -j CROSS_COMPILE=aarch64-linux-gnu-
The steps to create the needed ATF and the steps on the sd-card have still to be added.
Cubieboard2
Using OnBoard LED's on the Cubieboard2
As the Allwinner OnBoard LED's are specific to the DTS implementation there is no Debian package or way to configure them. To use the LED's for anything useful you have to write the wished usage of them into a trigger file. The location of these files are predefined by the Device Tree definition, for the CB2 the location for the blue LED is in /sys/class/leds/cubieboard2:blue:usr/trigger and the green LED is triggered via /sys/class/leds/cubieboard2:green:usr/trigger.
There are various things on a CB2 that can be shown by a LED activity (other Allwinner devices may contain more options!).
rc-feedback -> activity by a IR remote control
nand-disk -> R/W activity on the NAND flash
cpu0 -> CPU activity on core 1
cpu1 -> CPU activity on core 2
mmc0 -> R/W activity on the MMC 1 (SD-Card 1)
none -> show nothing
To let the kernel show any specific action on than just write the keyword into the trigger file as root. For example if you want to see on the blue LED the activity of CPU0 and on the green LED R/W actions on the MMC1 put the following lines into /etc/rc.local before the exit 0 line.
.... echo cpu0 > /sys/class/leds/cubieboard2\:blue\:usr/trigger echo mmc0 > /sys/class/leds/cubieboard2\:green\:usr/trigger ....
To enable/disable the LED activity without loosing the predefined action you can switch on/of the LED by writing into the brightness trigger as root.
echo 0 > /sys/class/leds/cubieboard2\:blue\:usr/brightness # switch off LED echo 0 > /sys/class/leds/cubieboard2\:green\:usr/brightness # switch off LED
echo 1 > /sys/class/leds/cubieboard2\:blue\:usr/brightness # switch on LED, default state after boot echo 1 > /sys/class/leds/cubieboard2\:green\:usr/brightness # switch on LED, default state after boot
Reading SoC Temperature on Cubieboard2
The path to the temperature on the SOC is depending on the DTB, so it differs between Bullseye and Buster. For Bullseye the current value of the temperature on the board is stored in the following file.
$ cat /sys/devices/platform/soc/1c25000.rtp/hwmon/hwmon0/temp1_input 26200
While Buster uses a different path.
$ cat /sys/devices/platform/soc@1c00000/1c25000.rtp/hwmon/hwmon0/temp1_input 30600
NetBox
NetBox is a Django based application that is developed as infrastructure resource modeling (IRM) tool. The goal of NetBox is to act as a database with the intended state of IT infrastructure and to provide an API to doing further things on top of NetBox like provisioning. The following part is dedicated to get NetBox packaged into Debian.
Source
Source code: https://github.com/netbox-community/netbox
Documentation: https://docs.netbox.dev/
Demo site: https://demo.netbox.dev/
ITP: #1017079
WIP Packaging: https://salsa.debian.org/tijuca/netbox
Package dependencies
Due the underlying Django framework quite most of the package dependencies are related to Python packages which are mostly but not completely available within Debian. Note that upstream is picking quite recent depending upstream versions for depending packages, but only a few packages are later really need to be of this version! So versions in the field Version are mostly picked from the beginning of the packaging and only increased if there is a real need to bump the version.
Package |
Version |
testing |
unstable/sid |
experimental |
Notes |
python3-bleach |
>= 5.0.0 |
|
|
|
|
python3-django |
>= 4.1 |
|
|
|
|
python3-django-cacheops |
>= 6.0 |
|
|
|
|
python3-django-cors-headers |
>= 3.7.0 |
|
|
|
|
python3-django-debug-toolbar |
>= 3.2.1 |
|
|
|
|
python3-django-filters |
>= 2.4.0 |
|
|
|
|
python3-django-graphiql-debug-toolbar |
>= 0.1.4 |
|
|
|
|
python3-django-mptt |
>= 0.13.2 |
|
|
|
|
python3-django-pglocks |
>= 1.0.4 |
|
|
|
|
python3-django-prometheus |
>= 2.1.0 |
|
|
|
|
python3-django-redis |
>= 5.2.0 |
|
|
|
|
python3-django-rq |
>= 2.4.1 |
|
|
|
|
python3-django-tables2 |
>= 2.3.4 |
|
|
|
|
python3-django-taggit |
>= 2.0.0 |
|
|
|
|
python3-django-timezone-field |
>= 4.1.2 |
|
|
|
|
python3-djangorestframework |
>= 3.12.4 |
|
|
|
|
python3-djangorestframework-spectacular |
>= 0.26.2 |
|
|
|
|
python3-drf-spectacular-sidecar-nonfree |
>= 2023.5.1 |
|
|
|
|
python3-dulwich |
>= 0.21.5 |
|
|
|
|
python3-feedparser |
>= 6.0.10 |
|
|
|
|
python3-gunicorn |
>= 20.1.0 |
|
|
|
|
python3-jinja2 |
>= 2.11.3 |
|
|
|
|
python3-markdown |
>= 3.3.4 |
|
|
|
|
python3-netaddr |
>= 0.8.0 |
|
|
|
|
python3-nh3 |
|
|
|
|
not packaged yet |
python3-pil |
>= 8.2.0 |
|
|
|
|
python3-psycopg2 |
>= 2.8.6 |
|
|
|
|
python3-social-auth-core |
>= 4.1.0 |
|
|
|
|
python3-social-django |
>= 5.0.0 |
|
|
|
|
python3-yaml |
>= 5.4.1 |
|
|
|
|
python3-svgwrite |
>= 1.4.1 |
|
|
|
|
python3-tablib |
>= 3.0.0 |
|
|
|
|
strawberry-graphiql |
|
|
|
|
not packaged yet |
strawberry-graphiql-django |
|
|
|
|
not packaged yet |
Build dependencies (direct and indirect)
Package |
Version |
testing |
unstable/sid |
experimental |
Notes |
mkdocs |
>= 1.2.3 |
|
|
|
|
mkdocs-autorefs |
>= 0.4.1 |
|
|
|
|
mkdocs-material |
>= 9.4.0 |
|
|
|
|
mkdocs-material-extensions |
>= 1.0.3 |
|
|
|
|
mkdocstrings |
>= 0.20.0 |
|
|
|
|
mkdocstrings-python-legacy |
>= 0.2.3 |
|
|
|
|
python3-nh3 |
|
|
|
|
not packaged yet |
python3-bleach |
>= 5.0.0 |
|
|
|
|
python3-funcy |
>= 1.16 |
|
|
|
|
python3-markdown-include |
>= 0.6.0 |
|
|
|
|
python3-markuppy |
>= 1.14 |
|
|
|
|
python3-graphql-core |
>= 3.2.1 |
|
|
|
|
python3-graphql-relay |
>= 3.2.0 |
|
|
|
|
python3-promise |
>= 2.3.0 |
|
|
|
|
python3-pymdownx |
>= 9.5 |
|
|
|
|
python3-pytkdocs |
>= 0.16.1 |
|
|
|
|
python3-text-unidecode |
>= 1.3 |
|
|
|
|
strawberry-graphiql |
|
|
|
|
not packaged yet |
strawberry-graphiql-django |
|
|
|
|
not packaged yet |
A snapshot of the current (new) package dependency graph.
ToDo
The current state in the WIP packaging produces working packages so far, except the GraphQL interface isn't working due a needed update of the some internal NetBox code. But the user experience should get improved by providing further helping tooling.
- Packaging Improvements
A helper script e.g. nb-adm would be nice that will do all the required stuff while the postinst script is called like doing migrations of the database, copy the static files and so on.
Preferable the script should be written in Python so modifying the configuration in /etc/netbox/netbox-config.py is more easy.
- This script could also do a first time installation of the PostgreSQL database, no matter if the database is running locally or on a remote server.
- Importing and exporting the database would also be nice.
- A debconf helper for first time installations and also later configuration which uses the above helper needs to be written.
Packaging of other stuff around NetBox like Pynetbox, configuration management modules (e.g. Ansible, Salt) or also some popular plugins.
Right now we are impossible to rebuild the shipped minimized JS/CSS files, besides the source is also shipped, that are used within the NetBox Django application (and the package will need to go into contrib). Upstream is using the script verify-bundles.sh to check the integrity of the bundles by the usage of yarn. We would need to create a similar workflow without depending on yarn and the outer world to pull in external packages. Any help on this is appreciated!
Upstream did moved away from graphene-django to strawberry (as underlying GraphQL library) and strawberry-django (as integration into Django). This brings again new and different build and package dependencies which are not packaged yet. There is RFP #1037085 opened that hopefully get some attention from someone who feels obligated to work on this.
Testing
A mostly current WIP status of a packaged NetBox application and the depending additional needed packages can be found on people.d.o. If you want to rebuild the depending packages look at the Git linked resource within the table.
You will need to use at least the unstable release as base for testing. For a first time setup please have a look into the README.Debian file.
Patchwork
Note: This section isn't up2date! In the between times Patchwork has reached a version 2 with some different requirements than listed below. I've currently no time nor interests to dig into packaging patchwork.
Source
git clone git://github.com/getpatchwork/patchwork
Mailinglist/Maintainer/URL
Jeremy Kerr jk@ozlabs.org
Dependencies
Software |
Version |
|
|
Phyton2 Interpreter |
>= 2.7 |
|
|
>= 1.5 |
|
|
|
phyton-psycopg2 Bindings |
>= 2.0 |
|
|
Apache2 Webserver |
>= 2.2 |
|
|
or |
|
|
|
lighttpd Webserver |
>= 1.4 |
|
|
mta-transport-agent |
- |
- |
- |
modpython libapache2-mod-python |
>= 3.3 |
|
|
>= 1.3 |
|
|
|
>= 5.5 |
|
|
|
or |
|
|
|
>= 9.0 |
|
|
|
Bash (some scripts) |
>= 3.0 |
|
|
ITP Request
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703226
Old Staging Area
https://github.com/tijuca/patchwork