(Cross-posting this message I sent to pkg-raspi-maintainers for broader visibility.)
I started building Raspberry Pi images because I thought there should be an easy, official way to install Debian on the Raspberry Pi.
I still believe that, but I’m not actually using Debian on any of my Raspberry Pis anymore¹, so my personal motivation to do any work on the images is gone.
On top of that, I realize that my commitments exceed my spare time capacity, so I need to get rid of responsibilities.
Therefore, I’m looking for someone to take up maintainership of the Raspberry Pi images. Numerous people have reached out to me with thank you notes and questions, so I think the user interest is there. Also, I’ll be happy to answer any questions that you might have and that I can easily answer. Please reply here (or in private) if you’re interested.
If I can’t find someone within the next 7 days, I’ll put up an announcement message in the raspi3-image-spec README, wiki page, and my blog posts, stating that the image is unmaintained and looking for a new maintainer.
Thanks for your understanding,
① just in case you’re curious, I’m now running cross-compiled Go programs directly under a Linux kernel and minimal userland, see https://gokrazy.org/
I have heard a number of times that sbuild is too hard to get started with, and hence people don’t use it.
To reduce hurdles from using/contributing to Debian, I wanted to make sbuild easier to set up.
sbuild ≥ 0.74.0 provides a Debian package called sbuild-debian-developer-setup. Once installed, run the sbuild-debian-developer-setup(1) command to create a chroot suitable for building packages for Debian unstable.
On a system without any sbuild/schroot bits installed, a transcript of the full setup looks like this:
% sudo apt install -t unstable sbuild-debian-developer-setup Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libsbuild-perl sbuild schroot Suggested packages: deborphan btrfs-tools aufs-tools | unionfs-fuse qemu-user-static Recommended packages: exim4 | mail-transport-agent autopkgtest The following NEW packages will be installed: libsbuild-perl sbuild sbuild-debian-developer-setup schroot 0 upgraded, 4 newly installed, 0 to remove and 1454 not upgraded. Need to get 1.106 kB of archives. After this operation, 3.556 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://localhost:3142/deb.debian.org/debian unstable/main amd64 libsbuild-perl all 0.74.0-1 [129 kB] Get:2 http://localhost:3142/deb.debian.org/debian unstable/main amd64 sbuild all 0.74.0-1 [142 kB] Get:3 http://localhost:3142/deb.debian.org/debian testing/main amd64 schroot amd64 1.6.10-4 [772 kB] Get:4 http://localhost:3142/deb.debian.org/debian unstable/main amd64 sbuild-debian-developer-setup all 0.74.0-1 [62,6 kB] Fetched 1.106 kB in 0s (5.036 kB/s) Selecting previously unselected package libsbuild-perl. (Reading database ... 276684 files and directories currently installed.) Preparing to unpack .../libsbuild-perl_0.74.0-1_all.deb ... Unpacking libsbuild-perl (0.74.0-1) ... Selecting previously unselected package sbuild. Preparing to unpack .../sbuild_0.74.0-1_all.deb ... Unpacking sbuild (0.74.0-1) ... Selecting previously unselected package schroot. Preparing to unpack .../schroot_1.6.10-4_amd64.deb ... Unpacking schroot (1.6.10-4) ... Selecting previously unselected package sbuild-debian-developer-setup. Preparing to unpack .../sbuild-debian-developer-setup_0.74.0-1_all.deb ... Unpacking sbuild-debian-developer-setup (0.74.0-1) ... Processing triggers for systemd (236-1) ... Setting up schroot (1.6.10-4) ... Created symlink /etc/systemd/system/multi-user.target.wants/schroot.service → /lib/systemd/system/schroot.service. Setting up libsbuild-perl (0.74.0-1) ... Processing triggers for man-db (2.7.6.1-2) ... Setting up sbuild (0.74.0-1) ... Setting up sbuild-debian-developer-setup (0.74.0-1) ... Processing triggers for systemd (236-1) ... % sudo sbuild-debian-developer-setup The user `michael' is already a member of `sbuild'. I: SUITE: unstable I: TARGET: /srv/chroot/unstable-amd64-sbuild I: MIRROR: http://localhost:3142/deb.debian.org/debian I: Running debootstrap --arch=amd64 --variant=buildd --verbose --include=fakeroot,build-essential,eatmydata --components=main --resolve-deps unstable /srv/chroot/unstable-amd64-sbuild http://localhost:3142/deb.debian.org/debian I: Retrieving InRelease I: Checking Release signature I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010) I: Retrieving Packages I: Validating Packages I: Found packages in base already in required: apt I: Resolving dependencies of required packages... […] I: Successfully set up unstable chroot. I: Run "sbuild-adduser" to add new sbuild users. ln -s /usr/share/doc/sbuild/examples/sbuild-update-all /etc/cron.daily/sbuild-debian-developer-setup-update-all Now run `newgrp sbuild', or log out and log in again. % newgrp sbuild % sbuild -d unstable hello sbuild (Debian sbuild) 0.74.0 (14 Mar 2018) on x1 ============================================================================== | hello (amd64) Mon, 19 Mar 2018 07:46:14 0000 | ============================================================================== Package: hello Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary […]
I hope you’ll find this useful.
dput-ng ≥ 1.16 contains two usability changes which make uploading easier:
With these changes, after building a package, you just need to
type dput
(in the correct directory of course) to sign and upload
it.
If you want to follow along at home, clone this repository:
% GBP_CONF_FILES=:debian/gbp.conf gbp clone https://anonscm.debian.org/git/pkg-go/packages/golang-github-go-macaron-inject.git
Now, in the golang-github-go-macaron-inject
directory, I’m aware
of three ways to obtain an orig tarball (please correct me if there are more):
gbp
buildpackage
, creating an orig tarball from git
(upstream/0.0_git20160627.0.d8a0b86
)d085a04b7b35856be24f8cc4a9a6d9799cdb59b4
.
pristine-tar
checkout
d51575c0b00db5fe2bbf8eea65bc7c4f767ee954
.
origtargz
d51575c0b00db5fe2bbf8eea65bc7c4f767ee954
.
Have a look at the archive’s golang-github-go-macaron-inject_0.0~git20160627.0.d8a0b86-2.dsc, however: the file entry orig tarball reads:
f5d8631c7b77e8941498910b64542f3db6daa3c2 7688 golang-github-go-macaron-inject_0.0~git20160627.0.d8a0b86.orig.tar.xz
So, why did we get a different tarball? Let’s go through the methods:
gbp buildpackage
to create
their tarball. Perhaps they imported from a tarball created by
dh-make-golang, or created manually, and then left that tarball in place
(which is a perfectly fine, normal workflow).
pristine-tar
resulted in a different
tarball than what’s in the archive. I think the most likely theory is that
the uploader had to go back and modify the tarball, but forgot to update (or
made a mistake while updating) the pristine-tar branch.
origtargz
, when it detects pristine-tar data, uses
pristine-tar, hence the same tarball as ②.
Had we not used pristine-tar for this repository at
all, origtargz
would have pulled the correct tarball from the
archive.
The above anecdote illustrates the fragility of the pristine-tar approach. In my experience from the pkg-go team, when the pristine-tar branch doesn’t contain outright incorrect data, it is often outdated. Even when everything is working correctly, a number of packagers are disgruntled about the extra work/mental complexity.
In the pkg-go team, we have (independently of this specific anecdote) collectively decided to have the upstream branch track the upstream remote’s master (or similar) branch directly, and get rid of pristine-tar in our repositories. This should result in method ① and ③ working correctly.
In conclusion, my recommendation for any repository is: don’t bother with
pristine-tar. Instead, configure origtargz
as a git-buildpackage
postclone hook in your ~/.gbp.conf
to always work with archive
orig tarballs:
[clone] # Ensure the correct orig tarball is present. postclone=origtargz [buildpackage] # Pick up the orig tarballs created by the origtargz postclone hook. tarball-dir = ..
I previously wrote about my Debian buster preview image for the Raspberry Pi 3.
Now, I’m publishing an updated version, containing the following changes:
ip link set dev wlan0 up
, and iwlist wlan0 scan
.
As before, the image is built with vmdb2, the successor to vmdebootstrap. The input files are available at https://github.com/Debian/raspi3-image-spec.
Note that Bluetooth is still untested (see wiki:RaspberryPi3 for details).
Given that Bluetooth is the only known issue, I’d like to work towards getting this image built and provided on official Debian infrastructure. If you know how to make this happen, please send me an email. Thanks!
As a preview version (i.e. unofficial, unsupported, etc.)
until that’s done, I built and uploaded the resulting image. Find it at https://people.debian.org/~stapelberg/raspberrypi3/2018-01-08/.
To install the image, insert the SD card into your computer (I’m assuming it’s
available as /dev/sdb
) and copy the image onto it:
$ wget https://people.debian.org/~stapelberg/raspberrypi3/2018-01-08/2018-01-08-raspberry-pi-3-buster-PREVIEW.img.xz $ xzcat 2018-01-08-raspberry-pi-3-buster-PREVIEW.img.xz | dd of=/dev/sdb bs=64k oflag=dsync status=progress
If resolving client-supplied DHCP hostnames works in your network, you should be able to log into the Raspberry Pi 3 using SSH after booting it:
$ ssh root@rpi3 # Password is “raspberry”
In the pkg-go team, we are currently discussing which workflows we should standardize on.
One of the considerations is what goes into the “upstream” Git branch of our repositories: should it track the upstream Git repository, or should it contain orig tarball imports?
Now, tracking the upstream Git repository only works if upstream actually uses Git. The go tool, which is widely used within the Go community for managing Go packages, supports Git, Mercurial, Bazaar and Subversion. But which of these are actually used in practice?
Let’s find out!
/usr/lib/apt/apt-helper cat-file \ $(apt-get indextargets --format '$(FILENAME)' 'ShortDesc: Sources' 'Origin: Debian') \ | sed -n 's,Go-Import-Path: ,,gp' \ | sort -u
This is the harder option, but also the more complete one.
First, we’ll need the Go package import paths of all Go packages which are in Debian. We can get them from the ProjectB database, Debian’s main PostgreSQL database containing all of the state about the Debian archive.
Unfortunately, only Debian Developers have SSH access to a mirror of ProjectB at the moment. I contacted DSA to ask about providing public ProjectB access.
ssh mirror.ftp-master.debian.org "echo \"SELECT value FROM source_metadata \ LEFT JOIN metadata_keys ON (source_metadata.key_id = metadata_keys.key_id) \ WHERE metadata_keys.key = 'Go-Import-Path' GROUP BY value\" | \ psql -A -t service=projectb" > go_import_path.txt
I
uploaded a
copy of resulting go_import_path.txt
, if you’re curious.
Now, let’s come up with a little bit of Go to print the VCS responsible for each specified Go import path:
go get -u golang.org/x/tools/go/vcs cat >vcs4.go <<'EOT' package main import ( "fmt" "log" "os" "sync" "golang.org/x/tools/go/vcs" ) func main() { var wg sync.WaitGroup for _, arg := range os.Args[1:] { wg.Add(1) go func(arg string) { defer wg.Done() rr, err := vcs.RepoRootForImportPath(arg, false) if err != nil { log.Println(err) return } fmt.Println(rr.VCS.Name) }(arg) } wg.Wait() } EOT
Lastly, run it in combination
with uniq(1)
to discover…
go run vcs4.go $(tr '\n' ' ' < go_import_path.txt) | sort | uniq -c 760 Git 1 Mercurial
UNIX distributions used to come with the system source code
in /usr/src
. This is a concept which fascinates me: if you want
to change something in any part of your system, just make your change in the
corresponding directory, recomile, reinstall, and you can immediately see your
changes in action.
So, I decided I wanted to build a tool which can give you the impression of
that, without the downsides of additional disk space usage and slower update
times because of /usr/src
maintenance.
The result of this effort is a tool called pk4
(mnemonic: get me
the package for…) which I just uploaded to Debian.
What distinguishes this tool from an apt source
call is the
combination of a number of features:
apt policy
) will be used.
If you don’t want to wait for the package to clear the NEW queue, you can get it from here in the meantime:
wget https://people.debian.org/~stapelberg/pk4/pk4_1_amd64.deb sudo apt install ./pk4_1_amd64.deb
You can find the sources and issue tracker at https://github.com/Debian/pk4.
Here is a terminal screencast of the tool in action, availing the sources of i3, applying a patch, rebuilding the package and replacing the installed binary packages:
I previously wrote about my Debian stretch preview image for the Raspberry Pi 3.
Now, I’m publishing an updated version, containing the following changes:
A couple of issues remain, notably the lack of WiFi and bluetooth support (see wiki:RaspberryPi3 for details. Any help with fixing these issues is very welcome!
As a preview version (i.e. unofficial, unsupported, etc.)
until all the necessary bits and pieces are in place to build images in a
proper place in Debian, I built and uploaded the resulting image. Find it at https://people.debian.org/~stapelberg/raspberrypi3/2017-10-08/.
To install the image, insert the SD card into your computer (I’m assuming it’s
available as /dev/sdb
) and copy the image onto it:
$ wget https://people.debian.org/~stapelberg/raspberrypi3/2017-10-08/2017-10-08-raspberry-pi-3-buster-PREVIEW.img.bz2 $ bunzip2 2017-10-08-raspberry-pi-3-buster-PREVIEW.img.bz2 $ sudo dd if=2017-10-08-raspberry-pi-3-buster-PREVIEW.img of=/dev/sdb bs=5M
If resolving client-supplied DHCP hostnames works in your network, you should be able to log into the Raspberry Pi 3 using SSH after booting it:
$ ssh root@rpi3 # Password is “raspberry”
On 2017-01-18, I announced that https://manpages.debian.org had been modernized. Let me catch you up on a few things which happened in the meantime:
mandocd(8)
to the mandoc project, which debiman
now uses for significantly faster manpage conversion (useful for disaster
recovery/development). An entire run previously took 2 hours on my workstation.
With this change, it takes merely 22 minutes. The effects are even more
pronounced on manziarly, the VM behind manpages.debian.org.
The list above is not complete, but rather a selection of things I found worth pointing out to the larger public.
There are still a few things I plan to work on soon, so stay tuned :).
I previously wrote about my Debian stretch preview image for the Raspberry Pi 3.
Now, I’m publishing an updated version, containing the following changes:
A couple of issues remain, notably the lack of HDMI, WiFi and bluetooth support (see wiki:RaspberryPi3 for details. Any help with fixing these issues is very welcome!
As a preview version (i.e. unofficial, unsupported, etc.)
until all the necessary bits and pieces are in place to build images in a
proper place in Debian, I built and uploaded the resulting image. Find it at https://people.debian.org/~stapelberg/raspberrypi3/2017-03-22/.
To install the image, insert the SD card into your computer (I’m assuming it’s
available as /dev/sdb
) and copy the image onto it:
$ wget https://people.debian.org/~stapelberg/raspberrypi3/2017-03-22/2017-03-22-raspberry-pi-3-stretch-PREVIEW.img $ sudo dd if=2017-03-22-raspberry-pi-3-stretch-PREVIEW.img of=/dev/sdb bs=5M
If resolving client-supplied DHCP hostnames works in your network, you should be able to log into the Raspberry Pi 3 using SSH after booting it:
$ ssh root@rpi3 # Password is “raspberry”