Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

August 26 2019

astyle>=3.1-2 update requires manual intervention

The astyle package prior to version 3.1-2 was missing a soname link. This has been fixed in 3.1-2, so the upgrade will need to overwrite the untracked soname link created by ldconfig. If you get an error astyle: /usr/lib/libastyle.so.3 exists in filesystem when updating, use pacman -Suy --overwrite usr/lib/libastyle.so.3 to perform the upgrade.

August 20 2019

tensorflow>=1.14.0-5 update requires manual intervention

The tensorflow packages prior to version 1.14.0-5 were missing some soname links. This has been fixed in 1.14.0-5, so the upgrade will need to overwrite the untracked soname links created by ldconfig. If you get an errors like so tensorflow: /usr/lib/libtensorflow.so.1 exists in filesystem tensorflow: /usr/lib/libtensorflow_cc.so.1 exists in filesystem tensorflow: /usr/lib/libtensorflow_framework.so.1 exists in filesystem when updating, use pacman -Suy --overwrite=usr/lib/libtensorflow.so.1,usr/lib/libtensorflow_cc.so.1,usr/lib/libtensorflow_framework.so.1 to perform the upgrade.

July 22 2019

E-ink home display

I've always wanted an e-ink status display in my living room to view the weather forecast, news and public transport information. Previously I've used a SHA2017 Badge with the following app which showed a weather forecast for the following four days. So I've decided to scale up to a nice 7.5" e-ink screen which I can hang on the wall. To control the e-ink screen I've taken an Raspberry Pi Zero W since it's easier to develop with then an ESP32. To hold the e-ink screen I've gotten an Ikea RRIBBA which perfectly fits the e-ink screen and leaves enough space to fit an e-ink SPI controller and a RaspberryPi. When I started playing around with drawing images on the e-ink screen with the official Waveshare Python driver, I noticed a blank and an image update took around 50 seconds with 100% cpu. This is too slow for a status display so I started profiling with a simple test program. The Python profiler concluded that writebytes was called for the most of the time, which is a function of the python SPIDev module. It does a write call to the SPI device for every pixel individually which was the first issue to tackle. A newer version of this driver included the 'writebytes2' function which can write a Python iterable at once, this led to a significant improvement in this commit. Waveshare also sells e-ink panels with a third color which lead to unrequited looping since my panel is black and white. The example code first clears the panel, then generates a buffer and writes it to the device simply generating the buffer up front saved a small amount of "panel updating" time. The code to generate the buffer was also optimized. After all these changes the panel updates with a Raspberry Pi Zero W in ~ 10 seconds and a tiny bit faster on a Raspberry Pi 3 in ~ 8 seconds. The driver code can be viewed here. Now all that was left is to write my own status page for my living room. The e-ink panel fetches my local weather, public transport and Dutch news the code which drives the display below can be read here. The final display can be viewed below, the frame hangs on a nail with a barrel jack connector for a 5V power supply. In the future I would like to include a graph of the predicted rain for the following hour since cycling in the rain isn't always fun :-)

July 11 2019

libbloom>=1.6-2 update requires manual intervention

The libbloom package prior to version 1.6-2 was missing a soname link. This has been fixed in 1.6-2, so the upgrade will need to overwrite the untracked soname link created by ldconfig. If you get an error libbloom: /usr/lib/libbloom.so.1 exists in filesystem when updating, use pacman -Suy --overwrite usr/lib/libbloom.so.1 to perform the upgrade.

June 27 2019

Reproducing Arch [core] repository packages

As Arch Linux we are working on reproducible builds for a while and have a continuous test framework rebuilding package updated in our repositories. This test does an asp checkout of a package and builds it twice in a schroot, we do not try to reproduce actual repository packages yet. In the end this is however what we want to achieve, giving users the ability to verify a repository package by rebuilding it on their own hardware. repro was created to achieve this goal, it creates a build chroot with the packages installed during build (from the .BUILDINFO file), sets SOURCE_DATE_EPOCH accordingly, fetches the correct PKGBUILD and then builds the package. This tool however does not run in a CI environment yet, so a bash script was hacked together to build all our [core] (232) packages one by one leading to 0% reproducibility with the following issues: makepkg options differed, these options are recorded in BUILDINFO but not set yet by repro. Packages where not reproducible (108 due to makepkg recording false sizes in .PKGINFO). PKGBUILD fetching logic failed (21 packages). Failed to download source files due to DNS issues (popt, libpipeline, acl, mlocate). Packages did not build due to OOM and other issues (lib32-gcc-libs, gcc-obj, gcc-libs, gcc-go, gcc-fortran, gcc, fakeroot). asp failed to get package due unknown reasons (libusb). Packages not reproducible (s-nail, amd-ucode, syslinux, texinfo, tzdata, patch, .. and more). libpcap GPG verification failed. Builds with different packages installed leading to a different BUILDINFO due to an issue in repro (unknown). Logs of the process can be found here. This shows that still a lot has still to be done for reproducible Arch Linux, in the next pacman release the size issue should be resolved. Which will lead to at least some reproducible packages! Repro has to be improved and non reproducible packages sorted out. In a few months I intend to retry reproducing [core] packages and have at least > 0% reproducibility!

mariadb 10.4.x update requires manual intervention

The update to mariadb 10.4.6-1 and later changes configuration layout as recommended by upstream. The main configuration file moved from /etc/mysql/my.cnf (and its include directory /etc/mysql/my.cnf.d/) to /etc/my.cnf (and /etc/my.cnf.d/). Make sure to move your configuration. Instantiated services (like mariadb@foo.service) are no longer configured in separate files (like /etc/mysql/myfoo.cnf). Instead move your configuration to configuration blocks with group suffix in main configuration file, one for each service. A block should look something like this: [mysqld.foo] datadir = /var/lib/mysql-foo socket = /run/mysqld/mysqld-foo.sock ... Like every mariadb feature update this requires the data directory to be updated. With the new configuration in place run: systemctl restart mariadb.service && mariadb-upgrade -u root -p

June 20 2019

Mini DebConf Hamburg 2019

The reproducible builds project was invited to join the mini DebConf Hamburg sprints and conference part. I attended with the intention to get together to work on Arch Linux reproducible test setup improvements, reproducing more packages and comparing results. The first improvement was adding JSON status output for Arch Linux and coincidently also OpenSUSE and in the future Alpine the commit can be viewed here. The result was deployed and the Arch Linux JSON results are live. The next day, I investigated why Arch Linux's kernel is not reproducible. The packaging requires a few changes for partial reproducibility: export KBUILD_BUILD_HOST="arch" export KBUILD_BUILD_TIMESTAMP=$(date -d@"$SOURCE_DATE_EPOCH" +%Y-%m-%d) One of the remaining issue is CONFIG_MODULE_SIG_ALL which signs all kernel modules to allow loading of only signed kernel modules. If there is no private key specified a key will be generated which is always non-reproducible. A solution for this problem hasn't been found, as providing a key in the repository might also be non-optimal. Apart from this issue, the vmlinuz-linux image is also non-reproducible which needs to be further investigated. Further packages where investigated which currently do not reproduce in our test framework. s-nail due to recording of MAKEFLAGS which is under investigation for fixing. keyutils was fixed for embedding the build date in it's binary with this patch nspr has been made reproducible in Arch Linux with the following change. Plans where made to extend the reproducible builds test framework for Arch Linux and start reproducing real repository packages on the test framework. Pacman was also packaged for Debian inclusion so that it's easier to bootstrap Arch containers/chroots from a Debian install. A big thanks to all the organizers of mini DebConf Hamburg for organizing the event!

May 05 2019

External encrypted disk on LibreELEC

Last year I replaced, on the Raspberry Pi, the ArchLinux ARM with just Kodi installed with LibreELEC. Today I plugged an external disk encrypted with dm-crypt, but to my full surprise this isn’t supported. Luckily the project is open source and sky42 already provides a LibreELEC version with dm-crypt built-in support. Once I flashed sky42’s version, I setup automated mount at startup via the autostart.sh script and the corresponding umount via shutdown.sh this way: // copy your keyfile into /storage via SSH $ cat /storage/.config/autostart.sh cryptsetup luksOpen /dev/sda1 disk1 --key-file /storage/keyfile mount /dev/mapper/disk1 /media $ cat /storage/.config/shutdown.sh umount /media cryptsetup luksClose disk1 Reboot it and voilà! Automount If you want to automatically mount the disk whenever you plug it, then create the following udev rule: // Find out ID_VENDOR_ID and ID_MODEL_ID for your drive by using `udevadm info` $ cat /storage/.config/udev.rules.d/99-automount.rules ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEM=="block", ENV{ID_VENDOR_ID}=="0000", ENV{ID_MODEL_ID}=="9999", RUN+="cryptsetup luksOpen $env{DEVNAME} disk1 --key-file /storage/keyfile", RUN+="mount /dev/mapper/disk1 /media"

May 04 2019

Automated phone backup with Syncthing

How do you backup your phones? Do you? I use to perform a copy of all the photos and videos from my and my wife’s phone to my PC monthly and then I copy them to an external HDD attached to a Raspberry Pi. However, it’s a tedious job mainly because: - I cannot really use the phones during this process; - MTP works one in 3 times - often I have to fallback to ADB; - I have to unmount the SD cards to speed up the copy; - after I copy the files, I have to rsync everything to the external HDD. The Syncthing way Syncthing describes itself as: Syncthing replaces proprietary sync and cloud services with something open, trustworthy and decentralized. I installed it to our Android phones and on the Raspberry Pi. On the Raspberry Pi I also enabled remote access. I started the Syncthing application on the Android phones and I’ve chosen the folders (you can also select the whole Internal memory) to backup. Then, I shared them with the Raspberry Pi only and I set the folder type to “Send Only” because I don’t want the Android phone to retrieve any file from the Raspberry Pi. On the Raspberry Pi, I accepted the sharing request from the Android phones, but I also changed the folder type to “Receive Only” because I don’t want the Raspberry Pi to send any file to the Android phones. All done? Not yet. Syncthing main purpose is to sync, not to backup. This means that, by default, if I delete a photo from my phone, that photo is gone from the Raspberry Pi too and this isn’t what I do need nor what I do want. However, Syncthing supports File Versioning and best yet it does support a “trash can”-like file versioning which moves your deleted files into a .stversions subfolder, but if this isn’t enough yet you can also write your own file versioning script. All done? Yes! Whenever I do connect to my own WiFi my photos are backed up!

April 02 2019

Arch signoff

Arch sign off tool Since some time Arch has been letting users become testers which can sign off packages in [testing] repository's. The idea behind allowing users and not only the Arch team sign off packages as known good is that packages can be moved earlier or bugs and issues found earlier. To sign off a package you need to login into Arch Linux's website and go to the sign off page to sign off a package. Haavard created a tool to be able to sign off packages from the command line which makes it easier to sign off by doing it interatively. This tool has now been adopted by Arch as the official sign off tool and has been packaged in the extra repository. Issues can be reported here. If you want to become an Arch Linux tester, feel free to apply here. A special thanks goes out to the current testing team and haavard for creating this awesome tool!

March 06 2019

My new hobby

A few years ago, sitting in an emergency room, I realized I'm not getting any younger and if I want to enjoy some highly physical outdoor activities for grownups these are the very best years I have left to go and do them. Instead of aggravating my RSI with further repetitive motions on the weekends (i.e. trying to learn how to suck less at programming) I mostly wrench on an old BMW coupe and drive it to the mountains (documenting that journey, and the discovery of German engineering failures, was best left to social media and enthusiast forums). Around the same time I switched jobs, and the most interesting stuff I encounter that I could write about I can't really write about, because it would disclose too much about our infrastructure. If you are interested in HAProxy for the enterprise you can follow development on the official blog.

January 01 2019

Bug Day 2019

Hey all. We will be holding a bug day on the weekend of January 5th and 6th, to start off the year with a cleaned up bugtracker.The community is encouraged to canvass the bugtracker and find old bugs, figure out which ones are still valid, track down fixes and suchlike. Feel free to join #archlinux-bugs at that time in order to reach a bug wrangler and get more input on a bug. Or just post to the bug tracker.Links:https://lists.archlinux.org/pipermail/a … 29410.htmlOpen bugs, sorted by last edit date: core/extra and community

December 13 2018

Arch Linux @ Reproducible Build Summit Paris

Write up of the reproducible summit Three members of the Arch Linux team attended the Reproducible Build Summit 2018 in Paris this week to work together with the reproducible ecosystem to work on reproducible build issues. The other participants where from a lot of different projects and companies such as Debian, NixOS, Guix, Alpine, openSUSE, OpenWrt, Google, Microsoft and many more. The summit was organized by letting attendees work with a small subset of the attendees on issues which they are interested in and trying to find solutions and discuss ideas. At the end of the day there time for hacking together on solutions. The event was very open and there was a lot of collaboration between projects which have different goals! The Arch Team has worked on the following topics: Packaging & updating more reproducible build tools in our repos, disorderfs was updated to the latest version and disorderfs was updated after a pytest fix from Chris Lamb for diffoscope. Reprotest, the tool to test if something is reproducible has been added to [community]. A note has been made that we should investigate if the Arch ISO is reproducible. At least one possible issue is that squashfs images are not reproducible and Arch should consider switching to squashfskit which creates reproducible squashfs images. Discussed adding a JSON endpoint for fetching the reproducible build status of Arch Linux packages on tests.reproducible-builds.org. Sharing reproducible build issues cross distros. Discussed how to rebuild Arch Linux packages and test if they are reproducible. Discussed how to verify before installing a package if a package is reproducible. Debian's Kernel is reproducible, but Arch's isn't. We started investigating why ours isn't reproducible, as one goal is to get [core] reproducible as first repo. Investigate PGO (profile guided optimisation) reproducibility issues for Firefox and Python. And much more! It has left us with a lot of "homework" to continue making Arch Linux more reproducible! A huge thanks to the organizers and sponsors of the Reproducible build summit!

December 09 2018

Arch Linux ARM on the Allwinner NanoPi A64

Arch Linux ARM on a NanoPi A64 I've obtained two NanoPi A64's a long while ago and recently thought of setting them up as a HA cluster as an exercise. Since setting it up with real hardware is a lot more fun then with VM's or containers. And I wanted to try out aarch64 and see how well that fares on mainline Linux. The first part of setting it up created the partitions and rootfs on the sd card. For this I've just followed the "Generic AArch64 Installation". The more challenging part was setting up U-boot, clone it and follow the 64 bit board instructions. All that is required now is to install a boot.scr file in /boot on the sdcard, download the boot.cmd file and create a boot.scr with mkimage from uboot-tools with mkimage -C none -A arm64 -T script -d boot.cmd boot.scr. That should get the NanoPi A64 booting, note that 4.20 is required for the ethernet controller to work, luckily Arch Linux ARM offers an linux-rc package since as of writing this article 4.20 is still not released yet.

October 18 2018

archlinux-keyring update required before December 1 2018

archlinux-keyring 20181018-1 re-enables my PGP key for packaging. As any package updates on my behalf requires this version (or greater) to proceed without errors, users should update archlinux-keyring before December 1 2018. Prior to this date, there will be no new packages signed by my key. The list of affected packages:https://www.archlinux.org/packages/?sor … ainer=AladAlad

August 22 2018

lib32-ncurses 6.1-2 x86_64

System V Release 4.0 curses emulation library (32-bit)

August 21 2018

kdepim-runtime 18.08.0-2 x86_64

Extends the functionality of kdepim

firefox-developer-edition-i18n-es-mx 62.0b19-1 any

Spanish (Mexico) language pack for Firefox Developer Edition

firefox-developer-edition-i18n-en-za 62.0b19-1 any

English (South African) language pack for Firefox Developer Edition

firefox-developer-edition-i18n-bs 62.0b19-1 any

Bosnian language pack for Firefox Developer Edition
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl