Valhalla's Things: I've been influenced
Tags: madeof:atoms






color_encoding
and color_range
for
the input colorspace conversion, that is not covered by this work.
drm_color_lut
that goes to the DPP Gamma Correction block.
The package is orphaned and its upstream is no longer developed. It depends on gtk2, has a low popcon and no reverse dependencies.So I had little hope to see this program back in Debian. The git repository shows little activity, the last being two years ago. Interestingly, I do not quite remember what it was testing, but I do remember it to find dead pixels, confirm native resolution, and various pixel-peeping. Here's a screenshot of one of the screentest screens:
--patterns
. A list of patterns relevant to your installation is
available with the gst-inspect-1.0 videotestsrc
command.
By default, screentest
goes through all patterns. Each pattern runs
indefinitely until the you close the window, then the next pattern
starts.
You can restrict to a subset of patterns, for example this would be a
good test for dead pixels:
screentest --patterns black,white,red,green,blue
This would be a good sharpness test:
screentest --patterns pinwheel,spokes,checkers-1,checkers-2,checkers-4,checkers-8
A good generic test is the classic SMPTE color bars and is the
first in the list, but you can run only that test with:
screentest --patterns smpte
(I will mention, by the way, that as a system administrator with decades of experience, it is nearly impossible to type SMPTE without first typing SMTP and re-typing it again a few times before I get it right. I fully expect this post to have numerous typos.)Here's an example of the SMPTE pattern from Wikipedia:
screentest
also supports specifying which
output to use as a native resolution, with --output
. Failing that,
it will try to look at the outputs and use the first it will
find. If it fails to find anything, you can specify a resolution with
--resolution WIDTHxHEIGHT
.
I have tried to make it go full screen by default, but stumbled a bug
in Sway that crashes gst-launch
. If your Wayland compositor
supports it, you can possibly enable full screen with --sink
waylandsink fullscreen=true
. Otherwise it will create a new window
that you will have to make fullscreen yourself.
For completeness, there's also an --audio
flag that will emit the
classic "drone", a sine wave at 440Hz at 40% volume (the audiotestsrc
gstreamer plugin. And there's a --overlay-name
option to show
the pattern name, in case you get lost and want to start with one of
them again.
gst-launch
.
There might be some additional patterns that could be useful, but I
think those are better left to gstreamer. I, for example, am somewhat
nostalgic of the Philips circle pattern that used to play for TV
stations that were off-air in my area. But that, in my opinion, would
be better added to the gstreamer plugin than into a separate thing.
The script shows which command is being ran, so it's a good
introduction to gstreamer pipelines. Advanced users (and the video
team) will possibly not need screentest
and will design their own
pipelines with their own tools.
I've previously worked with ffmpeg
pipelines (in another such
procrastinated coding spree, video-proxy-magic), and I found
gstreamer more intuitive, even though it might be slightly less
powerful.
In retrospect, I should probably have picked a new name, to avoid
crashing the namespace already used by the project, which is now on
GitHub. Who knows, it might come back to life after this blog
post; it would not be the first time.
For now, the project lives along side the rest of my scripts
collection but if there's sufficient interest, I might move it to
its own git repositories. Comments, feedback, contributions are as
usual welcome. And naturally, if you know something better for this
kind of stuff, I'm happy to learn more about your favorite tool!
So now I have finally found something to test my projector, which will
likely confirm what I've already known all along: that it's kind
of a piece of crap and I need to get a proper one.
Multi-Arch: same
file loss. It was found that the proposed
mitigation for ineffective diversions does
not work as expected. Trying to fix it up resulted in more problems, some of
which remain unsolved as of this writing.
Initial work on moving shared libraries in the essential set has been done.
Meanwhile, the wider Debian community worked on fixing all known
Multi-Arch: same
file loss scenarios. This work is now being driven by
Christian Hofstaedler and during the Mini DebConf in Cambridge, Chris Boot,
tienne Mollier, Miguel Landaeta, Samuel Henrique, and Utkarsh Gupta sent
the other half of the necessary patches.
/dev/fd/N
from fuse3
to fuse2
.piuparts
.253
. This version includes the following changes:
* Improve DOS/MBR extraction by adding support for 7z.
(Closes: reproducible-builds/diffoscope#333)
* Process objdump symbol comment filter inputs as the Python "bytes" type
(and not str). (Closes: reproducible-builds/diffoscope#358)
* Add a missing RequiredToolNotFound import.
* Update copyright years.
amd64
, arm64
, armhf
, i386
, ppc64el
, riscv64
and s390
for Debian trixie, unstable and experimental, this is only around 500GB ie. less than 1%. Although the new service not yet ready for usage, it has already provided a promising outlook in this regard. More information is available on https://rebuilder-snapshot.debian.net and we hope that this service becomes usable in the coming weeks.
.buildinfo
files, in 8,0200 variations. This little piece of paper was the beginning of rebuilder-snapshot and is a direct outcome of the summit!
The Reproducible Builds team would like to thank our event sponsors who include Mullvad VPN, openSUSE, Debian, Software Freedom Conservancy, Allotropia and Aspiration Tech.
[ ] introduce the concepts of Reproducible Builds, including best practices for developing and releasing software, the tools available to help diagnose issues, and touch on progress towards solving decades-old deeply pervasive fundamental security issues Learn how to verify and demonstrate trust, rather than simply hoping everything is OK!Germane to the contents of the talk, the slides for Vagrant s talk can be built reproducibly, resulting in a PDF with a SHA1 of
cfde2f8a0b7e6ec9b85377eeac0661d728b70f34
when built on Debian bookworm and c21fab273232c550ce822c4b0d9988e6c49aa2c3
on Debian sid at the time of writing.
[ ] today I hold in my hands the first two bit-identical LibreOffice rpm packages. And this is the success I wanted to share with you all today [and] it makes me feel as if we can solve anything.
esp32c3
microcontroller firmware reproducible with Rust, repro-env and Arch Linux:
I chose theesp32c3
[board] because it has good Rust support from theesp-rs
project, and you can get a dev board for about 6-8 . To document my build environment I usedrepro-env
together with Arch Linux because its archive is very reliable and contains all the different Rust development tools I needed.
dump
command and hopes that someone may be able to help.
amd64
, arm64
, i386
and armhf
architectures, data is collected from the Reproducible Builds testing framework is collected by this migration software even though, at the time of writing, it neither causes nor migration bonuses nor blocks migration. Indeed, the information only results are visible on Britney s excuses as well as on individual packages pages on tracker.debian.org.
.buildinfo
files
Back in 2017, Steve Langasek filed a bug against Ubuntu s Launchpad code hosting platform to report that .changes
files (artifacts of building Ubuntu and Debian packages) reference .buildinfo
files that aren t actually exposed by Launchpad itself. This was causing issues when attempting to process .changes
files with tools such as Lintian. However, it was noticed last month that, in early August of this year, Simon Quigley had resolved this issue, and .buildinfo
files are now available from the Launchpad system.
composer.lock
file, ensuring total reproducibility of the shipped binary file. Further details and the discussion that went into their particular implementation can be found on the associated GitHub pull request.
In addition, the presentation Leveraging Nix in the PHP ecosystem has been given in late October at the PHP International Conference in Munich by Pol Dellaiera. While the video replay is not yet available, the (reproducible) presentation slides and speaker notes are available.
7z
. [ ]RequiredToolNotFound
import. [ ]252
to Debian unstable. [ ]SOURCE_DATE_EPOCH
and CMake [ ], added iomart (ne Bytemark) and DigitalOcean to our sponsors page [ ] and dropped an unnecessary link on some horizontal navigation buttons [ ].
amber-cli
(date-related issue)bin86
(FTBFS-2038)buildah
(timestamp)colord
(CPU)google-noto-fonts
(file modification issue)grub2
(directory-related metadata)guile-fibers
(parallelism issue)guile-newt
(parallelism issue)gutenprint
(embedded date/hostname)hub
(random build path)ipxe
(nondeterministic behavoiour)joker
/ joker
kopete
(undefined behaviour)kraft
(embedde hostname)libcamera
(signature)libguestfs
(embeds build host file)llvm
(toolchain/Rust-related issue)nfdump
(date-related issue)ovmf
(unknown cause)quazip
(missing fonts)rdflib
(nondeterminstic behaviour)rpm
(toolchain)tigervnc
(embedded an RSA signature)whatsie
(date-related issue)xen
(time-related issue)policycoreutils
(sort-related issue)python-ansible-pygments
.bidict
.meson
.radsecproxy
.taffybar
.php-doc
.pelican
.maildir-utils
.openmrac-data
.vectorscan
.Priority: important
in a new package set. [ ][ ]pool_buildinfos
script to be re-run for a specific year. [ ]osuosl4
node [ ][ ] along with lynxis [ ].amd64
Ionos builders from 48 GiB to 64 GiB; thanks IONOS! [ ]arm64
architecture workers from 24 to 16 in order to improve stability [ ], reduce the workers for amd64
from 32 to 28 and, for i386
, reduce from 12 down to 8 [ ].cache_dir
size setting to 16 GiB. [ ]systemd-oomd
as it unfortunately kills sshd
[ ]debootstrap
from backports when commisioning nodes. [ ]live_build_debian_stretch_gnome
, debsums-tests_buster
and debsums-tests_buster
jobs to the zombie list. [ ][ ]jekyll build
with the --watch
argument when building the Reproducible Builds website. [ ]rc.local
s Bash syntax so it can actually run [ ], commenting away some file cleanup code that is (potentially) deleting too much [ ] and fixing the html_brekages
page for Debian package builds [ ]. Finally, diagnosed and submitted a patch to add a AddEncoding gzip .gz
line to the tests.reproducible-builds.org Apache configuration so that Gzip files aren t re-compressed as Gzip which some clients can t deal with (as well as being a waste of time). [ ]
#reproducible-builds
on irc.oftc.net
.
rb-general@lists.reproducible-builds.org
Plug in a USB stick - use dmesg or your favourite method to see how it is identified.
Make a couple of mount points under /mnt - /mnt/data and /mnt/cdrom
1. Grab a USB stick, Partition using MBR. Make a single VFAT
partition, type 0xEF (i.e. EFI System Partition)
For a USB stick (identified as sdX) below:
$ sudo parted --script /dev/sdX mklabel msdos $ sudo parted --script /dev/sdX mkpart primary fat32 0% 100% $ sudo mkfs.vfat /dev/sdX1
$ sudo mount /dev/sdX1 /mnt/data/
Download an arm64 netinst.iso
https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-12.2.0-arm64-netinst.iso
2. Copy the complete contents of partition *1* from a Debian arm64
installer image into the filesystem (partition 1 is the installer
stuff itself) on the USB stick, in /
$ sudo kpartx -v -a debian-12.2.0-arm64-netinst.iso # Mount the first partition on the ISO and copy its contents to the stick $ sudo mount /dev/mapper/loop0p1 /mnt/cdrom/ $ sudo rsync -av /mnt/cdrom/ /mnt/data/ $ sudo umount /mnt/cdrom
3. Copy the complete contents of partition *2* from that Debian arm64
installer image into that filesystem (partition 2 is the ESP) on
the USB stick, in /
# Same story with the second partition on the ISO
$ sudo mount /dev/mapper/loop0p2 /mnt/cdrom/
$ sudo rsync -av /mnt/cdrom/ /mnt/data/ $ sudo umount /mnt/cdrom
$ sudo kpartx -d debian-testing-amd64-netinst.iso $ sudo umount /mnt/data
4. Grab the rpi edk2 build from https://github.com/pftf/RPi4/releases
(I used 1.35) and extract it. I copied the files there into *2*
places for now on the USB stick:
/ (so the Pi will boot using it)
/rpi4 (so we can find the files again later)
5. Add the preseed.cfg file (attached) into *both* of the two initrd
files on the USB stick
- /install.a64/initrd.gz and
- /install.a64/gtk/initrd.gz
cpio is an awful tool to use :-(. In each case:
$ cp /path/to/initrd.gz .
$ gunzip initrd.gz
$ echo preseed.cfg cpio -H newc -o -A -F initrd
$ gzip -9v initrd
$ cp initrd.gz /path/to/initrd.gz
If you look at the preseed file, it will do a few things:
- Use an early_command to unmount /media (to work around Debian bug
#1051964)
- Register a late_command call for /cdrom/finish-rpi (the next
file - see below) to run at the end of the installation.
- Force grub installation also to the EFI removable media path,
needed as the rpi doesn't store EFI boot variables.
- Stop the installer asking for firmware from removable media (as
the rpi4 will ask for broadcom bluetooth fw that we can't
ship. Can be ignored safely.)
6. Copy the finish-rpi script (attached) into / on the USB stick. It
will be run at the end of the installation, triggered via the
preseed. It does a couple of things:
- Copy the edk2 firmware files into the ESP on the system that's
just been installer
- Remove shim-signed from the installed systems, as there's a bug
that causes it to fail on rpi4. I need to dig into this to see
what the issue is.
That's it! Run the installer as normal, all should Just Work (TM).
BlueTooth didn't quite work : raspberrypi-firmware didn't install until adding a symlink for boot/efi to /boot/firmware
20231127 - This may not be necessary because raspberrypi-firmware path has been fixed
snap connect kamoso:camera :camera
I have a pile of new MR s in for non release service applications and some fixes for issues found while testing. While this new workflow does take a bit longer waiting for approvals I like it much better as I am developing closer relationships with the application developers.
I have made significant progress on the Kf6 ( Qt6 based ) content snap. I am about 90% complete. While this doesn t mean much for users yet, it will when KDE applications release their qt6 ports starting the next major release cycle. I will be ready!
The last bit for snap work is I have almost completed my akonadi service snap. This will connect to all KDE PIM snaps so they share data. Akonadi is the background database that ties all the PIM applications together.
Debian:
This week I have worked on updates for several golang packages including charmbracelet/lipgloss charmbracelet/bubbles, and muesli-termenv. unfortunately I am stuck golang-github-aymanbagabas-go-osc52. The work is done in salsa but the maintainer has not uploaded. I have shot an email to the maintainer. I have also begun mentoring my first potential future DD! I reviewed his python-scienceplots and python-art which should land in Debian soon.
Thanks for stopping by! As usual, if you can please spare some change, consider a donation. All proceeds go to surviving another day to work on cool things to land on your desktop!
https://gofund.me/b8b69e54
<noscript><a href="https://liberapay.com/sgmoore/donate"><img alt="Donate using Liberapay" src="https://liberapay.com/assets/widgets/donate.svg" /></a></noscript>
Donate
Next.