Planet Debian

Subscribe to Planet Debian feed
Planet Debian - https://planet.debian.org/
Updated: 21 hours 22 min ago

Jonathan Dowland: Tex Shura

Mon, 2023-12-11 10:36

So yeah, I bought the Shura.

It's been about a year since I got the Tex Shinobi keyboard. I ended up taking to the office and using it there. The MX Silent Red switches are a good fit for a shared space, and I have a bit more desk space so the extra large footprint is not a problem.

Back at home, I have a reasonably large desk, but I've got a Synth jammed at the back-centre, leaving a slightly tight budget for keyboard depth. The Shura is nice and compact and fits in perfectly.

So what should I say about it? Build quality is excellent. I went with MX Reds (non-silent this time) which feel a lot better to me than the silent variant. I do worry about waking the kids up if I type after they've gone to bed, but it hasn't actually been a problem (and the switches activate quite early in travel so you can "tip-toe" type silently, and slowly).

I like these keyboards (and I've otherwise avoided the Mech keyboard money pit) because they have the integrated trackpoint, which I rely on. Just as with the Shinobi, the Trackpoint is of an excellent quality, pretty much indistinguishable from that on the official Lenovo trackpoint keyboards.

Since the Shura is a a "60%" or "65%" or "70%" or something, thus forgoing the Function keys and such, I rely on "layers": switching the function of all the regular keys whilst "Fn" is pressed. You can reprogram the Tex keyboards using a profile output by their web-based configurator which I've used to mildly customize the layout: swapped left-hand "Win" with "Fn" (FN1), mapped FN1 to the right-hand "Win". That's it so far, the defaults are otherwise sufficient for me. I've also used the DIP switches to enable mouse wheel emulation with the trackpoint (in common with the Lenovos).

In September, Justin from TeX left an intriguing comment on my last blog post:

Thanks for your promotion !! We will try to design a new keyboard ( a little ergo keyboard ) should be release end of this year !!

Categories: FLOSS Project Planets

Scarlett Gately Moore: KDE: KDE Snaps 23.08.4, PIM! KDE neon, Debian

Sun, 2023-12-10 08:33
KDE PIM Kaddressbook snap

KDE Snaps:

This weeks big accomplishment is KDE PIM snaps! I have successfully added akonadi as a service via an akonadi content snap and running it as a service. Kaddressbook is our first PIM snap with this setup and it works flawlessly! It is available in the snap store. I have a pile of MRs awaiting approvals, so keep your eye out for the rest of PIM in the next day.

KDE Applications 23.08.4 has been released and available in the snap store.

Krita 5.2.2 has been released.

I have created a new kde-qt6 snap as the qt-framework snap has not been updated and the maintainer is unreachable. It is in edge and I will be rebuilding our kf6 snap with this one.

I am debugging an issue with the latest Labplot release.

KDE neon:

This week I helped with frameworks release 5.113 and KDE applications 23.08.4.

I also worked on the ongoing Unstable turning red into green builds as the porting to qt6 continues.

Debian:

With my on going learning packaging for all the programming languages, Rust packaging: I started on Rustic https://github.com/rustic-rs/rustic unfortunately, it was a bit of wasted time as it depends on a feature of tracing-subcriber that depends on matchers which has a grave bug, so it remains disabled.

Personal:

I do have an interview tomorrow! And it looks like the ‘project’ may go through after the new year. So things are looking up, unfortunately I must still ask, if you have any spare change please consider a donation. The phone company decided to take an extra $200.00 I didn’t have to spare and while I resolved it, they refused a refund, but gave me a credit to next months bill, which doesn’t help me now. Thank you for your consideration.

https://gofund.me/b74e4c6f

Categories: FLOSS Project Planets

Freexian Collaborators: Debian Contributions: Python 3.12 preparations, debian-printing, merged-/usr tranisition updates, and more! (by Utkarsh Gupta)

Sat, 2023-12-09 19:00

Contributing to Debian is part of Freexian’s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

Preparing for Python 3.12 by Stefano Rivera

Stefano uploaded a few packages in preparation for Python 3.12, including pycxx and cython. Cython has a major new version (Cython 3), adding support for 3.12, but also bringing changes that many packages in Debian aren’t ready to build with, yet. Stefano uploaded it to Debian experimental and did an archive rebuild of affected packages, and some analysis of the result. Matthias Klose has since filed bugs for all of these issues.

debian-printing, by Thorsten Alteholz

This month Thorsten invested some of the previously obtained money to build his own printlab. At the moment it only consists of a dedicated computer with an USB printer attached. Due to its 64GB RAM and an SSD, building of debian-printing packages is much faster now. Over time other printers will be added and understanding bugs should be a lot easier now.

Also Thorsten again adopted two packages, namely mink and ink, and moved them to the debian-printing team.

Merged-/usr transition by Helmut Grohne, et al

The dumat analysis tool has been improved in quite some aspects. Beyond fixing false negative diagnostics, it now recognizes protective diversions used for mitigating 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.

Miscellaneous contributions
  • Stefano merged patches to support loong64 and hurd-amd64 in re2.
  • For the Cambridge mini-conf, Stefano added a web player to the DebConf video streaming frontend, as the Cambridge miniconf didn’t have its own website to host the player.
  • Raphaël helped the upstream developers of hamster-time-tracker to prepare a new upstream release (the first in multiple years) and packaged that new release in Debian unstable.
  • Enrico joined Hemut in brainstorming some /usr-merge solutions.
  • Thorsten took care of RM-bugs to remove no longer needed packages from the Debian archive and closed about 50 of them.
  • Helmut ported the feature of mounting a fuse connection via /dev/fd/N from fuse3 to fuse2.
  • Helmut sent a number of patches simplifying unprivileged use of piuparts.
  • Roberto worked with Helmut to prepare the Shorewall package for the ongoing /usr-move transition.
  • Utkarsh also helped with the ongoing /usr-merge work by preparing patches for gitlab, libnfc, and net-tools.
  • Utkarsh, along with Helmut, brainstormed on fixing #961138, as this affects the whole archive and all the suites and not just R packages. Utkarsh intends to follow up on the bug in December.
  • Santiago organized a MiniDebConf in Uruguay. In total, nine people attended, including most of DDs in the surrounding area. Here’s a nicely written blog by Gunnar Wolf.
  • Santiago also worked on some issues on Salsa CI, fixed with some merge requests: #462, #463, and #466.
Categories: FLOSS Project Planets

Simon Josefsson: Classic McEliece goes to IETF and OpenSSH

Sat, 2023-12-09 18:11

My earlier work on Streamlined NTRU Prime has been progressing along. The IETF document on sntrup761 in SSH has passed several process points. GnuPG’s libgcrypt has added support for sntrup761. The libssh support for sntrup761 is working, but the merge request is stuck mostly due to lack of time to debug why the regression test suite sporadically errors out in non-sntrup761 related parts with the patch.

The foundation for lattice-based post-quantum algorithms has some uncertainty around it, and I have felt that there is more to the post-quantum story than adding sntrup761 to implementations. Classic McEliece has been mentioned to me a couple of times, and I took some time to learn it and did a cut’n’paste job of the proposed ISO standard and published draft-josefsson-mceliece in the IETF to make the algorithm easily available to the IETF community. A high-quality implementation of Classic McEliece has been published as libmceliece and I’ve been supporting the work of Jan Mojžíš to package libmceliece for Debian, alas it has been stuck in the ftp-master NEW queue for manual review for over two months. The pre-dependencies librandombytes and libcpucycles are available in Debian already.

All that text writing and packaging work set the scene to write some code. When I added support for sntrup761 in libssh, I became familiar with the OpenSSH code base, so it was natural to return to OpenSSH to experiment with a new SSH KEX for Classic McEliece. DJB suggested to pick mceliece6688128 and combine it with the existing X25519+sntrup761 or with plain X25519. While a three-algorithm hybrid between X25519, sntrup761 and mceliece6688128 would be a simple drop-in for those that don’t want to lose the benefits offered by sntrup761, I decided to start the journey on a pure combination of X25519 with mceliece6688128. The key combiner in sntrup761x25519 is a simple SHA512 call and the only good I can say about that is that it is simple to describe and implement, and doesn’t raise too many questions since it is already deployed.

After procrastinating coding for months, once I sat down to work it only took a couple of hours until I had a successful Classic McEliece SSH connection. I suppose my brain had sorted everything in background before I started. To reproduce it, please try the following in a Debian testing environment (I use podman to get a clean environment).

# podman run -it --rm debian:testing-slim apt install wget python3 librandombytes-dev libcpucycles-dev gcc make git autoconf libz-dev wget -q -O- https://lib.mceliece.org/libmceliece-20230612.tar.gz | tar xfz - cd libmceliece-20230612/ ./configure make install cd .. git clone https://gitlab.com/jas/openssh-portable cd openssh-portable git checkout jas/mceliece autoreconf ./configure # verify 'libmceliece support: yes' make # CC="cc -DDEBUG_KEX=1 -DDEBUG_KEXDH=1 -DDEBUG_KEXECDH=1"

You should now have a working SSH client and server that supports Classic McEliece! Verify support by running ./ssh -Q kex and it should mention mceliece6688128x25519-sha512@openssh.com.

To have it print plenty of debug outputs, you may remove the # character on the final line, but don’t use such a build in production.

You can test it as follows:

adduser --system sshd ./ssh-keygen -A # writes to /usr/local/etc/ssh_host_... mkdir /var/empty # setup public-key based login by running the following: ssh-keygen cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys while true; do $PWD/sshd -p 2222 -f /dev/null -oKexAlgorithms=mceliece6688128x25519-sha512@openssh.com -d; done & ./ssh -v -p 2222 localhost -oKexAlgorithms=mceliece6688128x25519-sha512@openssh.com date

On the client you should see output like this:

OpenSSH_9.5p1, OpenSSL 3.0.11 19 Sep 2023 debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug1: Connecting to localhost [::1] port 2222. debug1: Connection established. debug1: identity file /root/.ssh/id_rsa type 0 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa_sk type -1 debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: identity file /root/.ssh/id_ed25519_sk type -1 debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /root/.ssh/id_xmss type -1 debug1: identity file /root/.ssh/id_xmss-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.5 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.5 debug1: compat_banner: match: OpenSSH_9.5 pat OpenSSH* compat 0x04000000 debug1: Authenticating to localhost:2222 as 'root' debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: mceliece6688128x25519-sha512@openssh.com debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: SSH2_MSG_KEX_ECDH_REPLY received debug1: Server host key: ssh-ed25519 SHA256:YognhWY7+399J+/V8eAQWmM3UFDLT0dkmoj3pIJ0zXs debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts2: No such file or directory debug1: Host '[localhost]:2222' is known and matches the ED25519 host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: Will attempt key: /root/.ssh/id_rsa RSA SHA256:+ShnZ7q1PzYOVnirxGFkrYpH7GgmpLYzoJ6F9dHIOFs debug1: Will attempt key: /root/.ssh/id_ecdsa debug1: Will attempt key: /root/.ssh/id_ecdsa_sk debug1: Will attempt key: /root/.ssh/id_ed25519 debug1: Will attempt key: /root/.ssh/id_ed25519_sk debug1: Will attempt key: /root/.ssh/id_xmss debug1: Will attempt key: /root/.ssh/id_dsa debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512> debug1: kex_ext_info_check_ver: publickey-hostbound@openssh.com=<0> debug1: kex_ext_info_check_ver: ping@openssh.com=<0> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:+ShnZ7q1PzYOVnirxGFkrYpH7GgmpLYzoJ6F9dHIOFs debug1: Server accepts key: /root/.ssh/id_rsa RSA SHA256:+ShnZ7q1PzYOVnirxGFkrYpH7GgmpLYzoJ6F9dHIOFs Authenticated to localhost ([::1]:2222) using "publickey". debug1: channel 0: new session [client-session] (inactive timeout: 0) debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: filesystem debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: client_input_hostkeys: searching /root/.ssh/known_hosts for [localhost]:2222 / (none) debug1: client_input_hostkeys: searching /root/.ssh/known_hosts2 for [localhost]:2222 / (none) debug1: client_input_hostkeys: hostkeys file /root/.ssh/known_hosts2 does not exist debug1: client_input_hostkeys: no new or deprecated keys from server debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Sending command: date debug1: pledge: fork debug1: permanently_set_uid: 0/0 Environment: USER=root LOGNAME=root HOME=/root PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin MAIL=/var/mail/root SHELL=/bin/bash SSH_CLIENT=::1 46894 2222 SSH_CONNECTION=::1 46894 ::1 2222 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 Sat Dec 9 22:22:40 UTC 2023 debug1: channel 0: free: client-session, nchannels 1 Transferred: sent 1048044, received 3500 bytes, in 0.0 seconds Bytes per second: sent 23388935.4, received 78108.6 debug1: Exit status 0

Notice the kex: algorithm: mceliece6688128x25519-sha512@openssh.com output.

How about network bandwidth usage? Below is a comparison of a complete SSH client connection such as the one above that log in and print date and logs out. Plain X25519 is around 7kb, X25519 with sntrup761 is around 9kb, and mceliece6688128 with X25519 is around 1MB. Yes, Classic McEliece has large keys, but for many environments, 1MB of data for the session establishment will barely be noticeable.

# ./ssh -v -p 2222 localhost -oKexAlgorithms=curve25519-sha256 date 2>&1 | grep ^Transferred Transferred: sent 3028, received 3612 bytes, in 0.0 seconds # ./ssh -v -p 2222 localhost -oKexAlgorithms=sntrup761x25519-sha512@openssh.com date 2>&1 | grep ^Transferred Transferred: sent 4212, received 4596 bytes, in 0.0 seconds # ./ssh -v -p 2222 localhost -oKexAlgorithms=mceliece6688128x25519-sha512@openssh.com date 2>&1 | grep ^Transferred Transferred: sent 1048044, received 3764 bytes, in 0.0 seconds

So how about session establishment time?

# date; i=0; while test $i -le 100; do ./ssh -v -p 2222 localhost -oKexAlgorithms=curve25519-sha256 date > /dev/null 2>&1; i=`expr $i + 1`; done; date Sat Dec 9 22:39:19 UTC 2023 Sat Dec 9 22:39:25 UTC 2023 # 6 seconds # date; i=0; while test $i -le 100; do ./ssh -v -p 2222 localhost -oKexAlgorithms=sntrup761x25519-sha512@openssh.com date > /dev/null 2>&1; i=`expr $i + 1`; done; date Sat Dec 9 22:39:29 UTC 2023 Sat Dec 9 22:39:38 UTC 2023 # 9 seconds # date; i=0; while test $i -le 100; do ./ssh -v -p 2222 localhost -oKexAlgorithms=mceliece6688128x25519-sha512@openssh.com date > /dev/null 2>&1; i=`expr $i + 1`; done; date Sat Dec 9 22:39:55 UTC 2023 Sat Dec 9 22:40:07 UTC 2023 # 12 seconds

I never noticed adding sntrup761, so I’m pretty sure I wouldn’t notice this increase either. This is all running on my laptop that runs Trisquel so take it with a grain of salt but at least the magnitude is clear.

Future work items include:

  • Use a better hybrid mode combiner than SHA512? See for example KEM Combiners.
  • Write IETF document describing the Classic McEliece SSH protocol
  • Submit my patch to the OpenSSH community for discussion and feedback, please review meanwhile!
  • Implement a mceliece6688128sntrup761x25519 multi-hybrid mode?
  • Write a shell script a’la sntrup761.sh to import a stripped-down mceliece6688128 implementation to avoid having OpenSSH depend on libmceliece?
  • My kexmceliece6688128x25519.c is really just kexsntrup761x25519.c with the three calls to sntrup761 replaced with mceliece6688128. This should be parametrized to avoid cut’n’paste of code, if the OpenSSH community is interested.
  • Consider if the behaviour of librandombytes related to closing of file descriptors is relevant to OpenSSH.

Happy post-quantum SSH’ing!

Categories: FLOSS Project Planets

Steinar H. Gunderson: Cubemap 1.5.0 released

Sat, 2023-12-09 11:18

I've released version 1.5.0 of Cubemap, my scalable video reflector. This was a long time coming, and I've mostly been lazy about getting the actual release out. :-) There are some fairly big features this time, reflecting further the fact that my primary way of creating video isn't VLC anymore (which was Cubemap's original proposal; a better reflector for VLC). It's on its way up into Debian unstable, but you can also get it from git and just build.

Changelog goes as follows:

Cubemap 1.5.0, 2023-12-09 * Support input from pipes (subprocesses). With a program that can output Metacube on stdout, such as a suitably patched FFmpeg binary, this gives Cubemap transcoding/remuxing capabilities. Of course, one cannot upgrade such a binary by SIGHUP-ing it, but it will survive a Cubemap reload/restart. * Add a LD_PRELOAD-able library to force Metacube output from FFmpeg. This hooks just the right amount of functions to add Metacube output to arbitrary FFmpeg programs, but is obviously very brittle. (Native FFmpeg support would be better, but a patch did not go through when I tried a while back.) It is only lightly tested. Documentation in the README and cubemap.config.sample. * Various bugfixes.
Categories: FLOSS Project Planets

Thorsten Alteholz: My Debian Activities in November 2023

Sat, 2023-12-09 08:49
FTP master

This month I accepted 276 and rejected 25 packages. The overall number of packages that got accepted was 276. I also handled several RM bugs, so the archive did not grow that much :-).

Debian LTS

This was my hundred-thirteenth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

During my allocated time I uploaded:

  • [DLA 3670-1] minizip security update for one CVE to fix an integer overflow
  • [DLA 3673-1] gst-plugins-bad1.0 security update for one CVEs to fix an use-after-free
  • [#1056934] Bookworm PU-bug for libde265
  • [#1056935] Bullseye PU-bug for libde265
  • [#1056737] Bookworm PU-bug for minizip
  • [#1056738] Bullseye PU-bug for minizip
  • [libde265] sponsor upload to unstable
  • [zlib] all CVEs could be marked as not-affected

The update of libde265 was a bit unusual this time. The security tracker had three CVEs listed for it and the maintainer was looking for a sponsor to fix them in Unstable. So far, so good! I sponsored the upload and suddenly a fourth CVE appeared in the security tracker. As the debian/changelog mentioned a different CVE, it was automatically added. Indeed upstreams changelog contained a patch for a CVE that was reserved but not yet published (hence the security tracker could not connect it to libde265). I informed upstream and as things turned out marking the CVE as public was just forgotten. Luckily there was some time left for the upcoming point release and all four patches finally arrived in Bookworm.

Debian ELTS

This month was the sixty-fourth ELTS month. During my allocated time I uploaded:

  • [ELA-1004-1] libde265 update in Jessie and Stretch for three CVEs. The issues are related to segmentation faults and bufferf overflows in different functions, which might result in DoS.
  • [ELA-1006-1] libde265 update in Jessie and Stretch for one CVE. This issue is related to an buffer over read which might result in an information leak or denial of service when processing crafted H.265 files
  • [ELA-1010-1 ]minizip update in Stretch for one CVE. This issue was related to a heap-based buffer overflow.
  • [ELA-1015-1] gst-plugins-bad1.0 update in Jessie and Stretch for one CVEs to fix a use-after-free of some pointers within the MXF demuxer.

In order to check whether the patch for the standalone version of minizip was ok, I used a test from the embedded minizip version in chromium and it worked.

Debian Printing

This month I uploaded a new upstream version of:

Within the context of preserving old printing packages, I adopted:

If you know of any other package that is also needed and still maintained by the QA team, please tell me.

This work is generously funded by Freexian!

Debian Astro

This month I uploaded a new upstream version of:

Debian IoT

This month I uploaded a new upstream version of:

Debian Mobcom

This month I uploaded a package to fix one or the other issue:

Other stuff

This month I uploaded new upstream version of packages, did a source upload for the transition or uploaded it to fix one or the other issue:

Categories: FLOSS Project Planets

Dirk Eddelbuettel: RcppInt64 0.0.4 on CRAN: Minor Bugfix

Sat, 2023-12-09 08:22

The new-ish package RcppInt64 (announced earlier this fall in this post, with two small updates following) arrived on CRAN minutes ago as relase 0.0.4. RcppInt64 collects some of the previous conversions between 64-bit integer values in R and C++, and regroups them in a single package. It offers two interfaces: both a more standard as<>() converter from R values along with its companions wrap() to return to R, as well as more dedicated functions ‘from’ and ‘to’.

This release addresses an issues Sebastian reported a few hours and which is reported by newer, pickier compilers: We need to include <cstdint> so that int64_t is declared. CRAN was at its usual best processing this efficiently including tests of the by now two reverse dependencies. Twenty two minutes total, all automated:

The brief NEWS entry follows:

Changes in version 0.0.4 (2023-12-09)
  • The cstdint header is now included (closes #1).

Courtesy of my CRANberries, there is a diffstat report relative to previous release.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

Jonathan Dowland: The scourge of Electron, the nostalgia of Pidgin

Fri, 2023-12-08 09:18

For reasons I won't go into right now, I've spent some of this year working on a refurbished Lenovo Thinkpad Yoga 260. Despite it being relatively underpowered, I love almost everything about it.

Unfortunately the model I bought has 8G RAM which turned out to be more limiting than I thought it would be. You can do incredible things with 8G of RAM: incredible, wondrous things. And most of my work, whether that's wrangling containers, hacking on OpenJDK, or complex Haskell projects, are manageable.

Where it falls down is driving the modern scourge: Electron, and by proxy, lots of modern IM tools: Slack (urgh), Discord (where one of my main IRC social communities moved to), WhatsApp Web1 and even Signal Desktop.

For that reason, I've (temporarily) looked at alternatives, and I was pleasantly surprised to find serviceable plugins for Pidgin, the stalwart Instant Messenger multiplexer. I originally used Pidgin (then called Gaim) back in the last century, at the time to talk to ICQ, MSN Messenger and AIM (all but ICQ2 long dead). It truly is an elegant weapon from a more civilized age.

Discord from within Pidgin

The plugins are3:

Pidgin with all of these plugins loaded runs perfectly well and consumes fractions of the RAM that each of those Electron apps did prior.

A side-effect of moving these into Pidgin (in particular Discord) is a refocussing of the content. Fewer distractions around the text. The lack of auto-link embedding, and other such things, make it a cleaner, purer experience.

This made me think of the Discord community I am in (I'm really only active in one). It used to be an IRC channel of people that I met through a mutual friend. Said friend recently departed Discord, due to the signal to noise ratio being too poor, and the incessant nudge to click on links, engage, engage, engage.

I wonder if the experience — mediated by Pidgin — would be more tolerable to them?

What my hexchat looks like

I'm still active in one IRC channel (and inactive in many more). I could consider moving IRC into Pidgin as well. At the moment, my IRC client of choice is hexchat, which (like Pidgin) is still using GTK2 for the UI. There's something perversely pleasant about that.

  1. if you go to the trouble of trying to run it as an application distinct from your web browser.
  2. I'm still somewhat surprised ICQ is still going. I might try and recover my old ID.
  3. There may or may not be similar plugins for Slack, but as I (am forced to) use that for corporate stuff, I'm steering clear of them.
Categories: FLOSS Project Planets

Reproducible Builds (diffoscope): diffoscope 253 released

Thu, 2023-12-07 19:00

The diffoscope maintainers are pleased to announce the release of diffoscope version 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.

You find out more by visiting the project homepage.

Categories: FLOSS Project Planets

Dima Kogan: roslanch and =LD_PRELOAD=

Thu, 2023-12-07 15:56

This is part 2 of our series entitled "ROS people don't know how to use computers". This is about ROS1. ROS2 is presumably broken in some completely different way, but I don't know.

Unlike normal people, the ROS people don't "run" applications. They "launch" "nodes" from "packages" (these are "ROS" packages; obviously). You run

roslaunch PACKAGE THING.launch

Then it tries to find this PACKAGE (using some rules that nobody understands), and tries to find the file THING.launch within this package. The .launch file contains inscrutable xml, which includes other inscrutable xml. And if you dig, you eventually find stuff like

<node pkg="PACKAGE" name="NAME" type="TYPE" args="...." ...>

This defines the thing that runs. Unexpectedly, the executable that ends up running is called TYPE.

I know that my particular program is broken, and needs an LD_PRELOAD (exciting details described in another rant in the near future). But the above definition doesn't have a clear way to add that. Adding it to the type fails (with a very mysterious error message). Reading the docs tells you about launch-prefix, which sounds exactly like what I want. But when I add LD_PRELOAD=/tmp/whatever.so I get

RLException: Roslaunch got a 'No such file or directory' error while attempting to run: LD_PRELOAD=/tmp/whatever.so ..../TYPE .....

But this is how you're supposed to be attaching gdb and such! Presumably it looks at the first token, and makes sure it's a file, instead of simply prepending it to the string it passes to the shell. So your options are:

  • Do only approved ROS things in the docs (which are limited, since the docs were written by people who don't know how to use computers)
  • Be expert-enough to work around it

I'm expert-enough. You do this:

launch-prefix="/lib64/ld-linux-x86-64.so.2 --preload /tmp/whatever.so"
Categories: FLOSS Project Planets

Daniel Kahn Gillmor: New OpenPGP certificate for dkg, December 2023

Wed, 2023-12-06 19:15
dkg's New OpenPGP certificate in December 2023

In December of 2023, I'm moving to a new OpenPGP certificate.

You might know my old OpenPGP certificate, which had an fingerprint of C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA.

My new OpenPGP certificate has a fingerprint of: D477040C70C2156A5C298549BB7E9101495E6BF7.

Both certificates have the same set of User IDs:

  • Daniel Kahn Gillmor
  • <dkg@debian.org>
  • <dkg@fifthhorseman.net>

You can find a version of this transition statement signed by both the old and new certificates at:

https://dkg.fifthhorseman.net/2023-dkg-openpgp-transition.txt

The new OpenPGP certificate is:

-----BEGIN PGP PUBLIC KEY BLOCK----- xjMEZXEJyxYJKwYBBAHaRw8BAQdA5BpbW0bpl5qCng/RiqwhQINrplDMSS5JsO/Y O+5Zi7HCwAsEHxYKAH0FgmVxCcsDCwkHCRC7fpEBSV5r90cUAAAAAAAeACBzYWx0 QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmfUAgfN9tyTSxpxhmHA1r63GiI4v6NQ mrrWVLOBRJYuhQMVCggCmwECHgEWIQTUdwQMcMIValwphUm7fpEBSV5r9wAAmaEA /3MvYJMxQdLhIG4UDNMVd2bsovwdcTrReJhLYyFulBrwAQD/j/RS+AXQIVtkcO9b l6zZTAO9x6yfkOZbv0g3eNyrAs0QPGRrZ0BkZWJpYW4ub3JnPsLACwQTFgoAfQWC ZXEJywMLCQcJELt+kQFJXmv3RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVv aWEtcGdwLm9yZ4l+Z3i19Uwjw3CfTNFCDjRsoufMoPOM7vM8HoOEdn/vAxUKCAKb AQIeARYhBNR3BAxwwhVqXCmFSbt+kQFJXmv3AAALZQEAhJsgouepQVV98BHUH6Sv WvcKrb8dQEZOvHFbZQQPNWgA/A/DHkjYKnUkCg8Zc+FonqOS/35sHhNA8CwqSQFr tN4KzRc8ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PsLACgQTFgoAfQWCZXEJywMLCQcJ ELt+kQFJXmv3RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNlcXVvaWEtcGdwLm9y ZxLvwkgnslsAuo+IoSa9rv8+nXpbBdab2Ft7n4H9S+d/AxUKCAKbAQIeARYhBNR3 BAxwwhVqXCmFSbt+kQFJXmv3AAAtFgD4wqcUfQl7nGLQOcAEHhx8V0Bg8v9ov8Gs Y1ei1BEFwAD/cxmxmDSO0/tA+x4pd5yIvzgfGYHSTxKS0Ww3hzjuZA7NE0Rhbmll bCBLYWhuIEdpbGxtb3LCwA4EExYKAIAFgmVxCcsDCwkHCRC7fpEBSV5r90cUAAAA AAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmd7X4TgiINwnzh4jar0 Pf/b5hgxFPngCFxJSmtr/f0YiQMVCggCmQECmwECHgEWIQTUdwQMcMIValwphUm7 fpEBSV5r9wAAMuwBAPtMonKbhGOhOy+8miAb/knJ1cIPBjLupJbjM+NUE1WyAQD1 nyGW+XwwMrprMwc320mdJH9B0jdokJZBiN7++0NoBM4zBGVxCcsWCSsGAQQB2kcP AQEHQI19uRatkPSFBXh8usgciEDwZxTnnRZYrhIgiFMybBDQwsC/BBgWCgExBYJl cQnLCRC7fpEBSV5r90cUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBn cC5vcmfCopazDnq6hZUsgVyztl5wmDCmxI169YLNu+IpDzJEtQKbAr6gBBkWCgBv BYJlcQnLCRB3LRYeNc1LgUcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lh LXBncC5vcmcQglI7G7DbL9QmaDkzcEuk3QliM4NmleIRUW7VvIBHMxYhBHS8BMQ9 hghL6GcsBnctFh41zUuBAACwfwEAqDULksr8PulKRcIP6N9NI/4KoznyIcuOHi8q Gk4qxMkBAIeV20SPEnWSw9MWAb0eKEcfupzr/C+8vDvsRMynCWsDFiEE1HcEDHDC FWpcKYVJu36RAUlea/cAAFD1AP0YsE3Eeig1tkWaeyrvvMf5Kl1tt2LekTNWDnB+ FUG9SgD+Ka8vfPR8wuV8D3y5Y9Qq9xGO+QkEBCW0U1qNypg65QHOOARlcQnLEgor BgEEAZdVAQUBAQdAWTLEa0WmnhUmDBdWXX0ZlYAa4g1CK/fXg0NPOQSteA4DAQgH wsAABBgWCgByBYJlcQnLCRC7fpEBSV5r90cUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmexrMBZe0QdQ+ZJOZxFkAiwCw2I7yTSF2Ox9GVFWKmA mAKbDBYhBNR3BAxwwhVqXCmFSbt+kQFJXmv3AABcJQD/f4ltpSvLBOBEh/C2dIYa dgSuqkCqq0B4WOhFRkWJZlcA/AxqLWG4o8UrrmwrmM42FhgxKtEXwCSHE00u8wR4 Up8G =9Yc8 -----END PGP PUBLIC KEY BLOCK-----

When I have some reasonable number of certifications, i'll update the certificate associated with my e-mail addresses on https://keys.openpgp.org, in DANE, and in WKD. Until then, those lookups should continue to provide the old certificate.

Categories: FLOSS Project Planets

Tim Retout: Nostalgia for my attention span

Wed, 2023-12-06 13:38

This post was possibly inspired by my daughter’s homework assignment to interview an old person about technology change. Guess who’s old now?

Sometimes I look back at how life used to be, and remember what it was like. There are two key nostalgia points for me: before internet, and before smartphones.

Before the internet

Before the internet, there were computers. There were always computers in my life, they were just less fancy, with mainly text and fewer graphics at first. These days we adapt our user interfaces to look more like DOS and call it ‘retro’, although claiming it’s more efficient that way. Sometimes it is. The written word is a fundamental mode of human communication — it resonates.

Some of my earliest programming memories were typing lines of BASIC code into some sort of BBC Micro, usually not successfully. Most of my computer learning was largely theoretical, through Usborne books (now available online! Thanks internet for reducing the marginal cost of publishing to approximately zero) but without the benefit of a computer of my own.

I went for a walk this morning, with a slight bite to the air, and bought a newspaper, like the old person I am (I’m leaning in). Imagine that - a physical paper full of news. When I was an inquisitive sixth-former, ‘TheGuardian’ cost 50 pence — today it was £2.80. This increase far outstrips the rate of inflation, which would bring it to around 90 pence. No, this must surely reflect the drop in circulation of the physical edition, and the rise in advertisement-filled web content.

Before smartphones

As the internet became mainstream, I remember dial-up, and Freeserve, and even the tail end of USENET, and IRC.

This was still a time when email was a thing you had to be at your desk to check. Feature phones were very useful, but it was still possible to get lost. My university halls had a shared land-line phone on each floor.

And I wrote on the internet. I remember commenting on blogs, and I think my writing was better back then; more free, less inhibited.

I do find myself giving less attention to news squeezed into the small form-factor of a mobile phone. Chat messages and notification pings. I’m not convinced this is great progress for humanity.

Categories: FLOSS Project Planets

Pages