I've started struggling to see my mouse pointer on my desktop. I probably need
to take an eye test and possibly buy some new glasses. In the meantime, I've
changed my mouse pointer to something larger and more colourful: The Amiga
Workbench 1.3 mouse pointer that I grew up with, but scaled up to 128x128
pixels (from 16x16, I think)
See if you can spot it
sbuild, autopkgtest-build-qemu and vmdb2 to
provide a trivial interface for creating and using QEMU-based environments for
package building:
qemu-sbuild-create creates VM imagesqemu-sbuild-update is to VM images what sbuild-update is to chrootsqemu-sbuild wraps sbuild, adding all necessary (and some useful)
options for autopkgtest mode.$ sudo qemu-sbuild-create -o simple.img unstable http://deb.debian.org/debian $ qemu-sbuild --image simple.img -d unstable [sbuild-options] FOO.dscThat's it. Both
qemu-sbuild-create and qemu-sbuild automate certain things, but
also accept a number of options. For example, qemu-sbuild-create can
install additional packages either from one of the APT sources, or .deb
packages from the local filesystem.
qemu-sbuild will pass on every option it does not consume itself to
sbuild, so it should mostly work as a drop-in replacement for it (see the
Limitations section below for where it doesn't).
The created images can also be used for running autopkgtest itself, of
course.
qemu-sbuild-utils is not quite there yet.
amd64 architecture, for
building packages in amd64 and i386 VMs. There are plans to support
arm64 in the near future.
qemu-sbuild-create needs root, for the debootstrap stage. I'm looking into
ways around this (by extending vmdb2). In any case, image updating and
package building do not need privileges.
autopkgtest mode does not yet support interactivity, so one cannot drop
into a shell with --build-failed-commands, for example. The easy workaround
is to connect to the VM with SSH. For this, the image must contain the
openssh-server package.
qemubuilder, but had troubles getting it to work. In any case,
the autopkgtest chroot mode of sbuild seemed far more powerful and
useful to me.
vectis looks incredibly promising,
but I had already written qemu-sbuild-utils by the time I stumbled over it,
and as my current setup works well for me for now and is simple enough to
maintain, I decided to polish and publish it.
I'm also looking into Docker- and other namespace-based isolation solutions (of
which there are
many), which
I think are the way forward for the majority of packages (those that aren't
too close to the kernel and/or hardware).
Rather than relying on the kernel for isolation, KVM-based solutions like
Amazon's Firecracker
and QEMU's
microvm machine
type provide minimal VMs with almost no boot overhead. Firecracker, for
example, claims less than 125ms from launch to /sbin/init. Investigating
these is a medium-term project for me.
sbuild, autopkgtest, and vmdb2.
About a month worth of updates on KDE/Plasma in Debian has accumulated, so here we go. The highlights are: Plasma 5.19.5 based on Qt 5.15 is in Debian/experimental and hopefully soon in Debian/unstable, and my own builds at OBS have been updated to Plasma 5.20.2, Frameworks 5.75, Apps 20.08.2.
Thanks to the dedicated work of the Qt maintainers, Qt 5.15 has finally entered Debian/unstable and we can finally target Plasma 5.20.
OBS packages
The OBS packages as usual follow the latest release, and currently ship KDE Frameworks 5.75, KDE Apps 20.08.2, and new, Plasma 5.20.2. The package sources are as usual (note the different path for the Plasma packages and the App packages, containing the release version!), for Debian/unstable:
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/frameworks/Debian_Unstable/ ./ deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma520/Debian_Unstable/ ./ deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2008/Debian_Unstable/ ./ deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other/Debian_Unstable/ ./
Testing instead of Unstable for Debian/testing.
The update to Plasma 5.20 took a bit of time, not only because of the wait for Qt 5.15, but also because I couldn t get it running on my desktop, only in the VM. It turned out that the Plasmoid Event Calendar needed an update, and the old version crashed Plasma ( v68 and below crash in Arch after the Qt 5.15.1 update. ). After I realized that, it was only a question of updating to get Plasma 5.20 running.
There are two points I have to mention (and I will fix sooner or later):
A couple of year ago, I moved into a new flat that comes with RJ45 sockets wired for 10 Gigabit (but currently offering 1 Gigabit) Ethernet.This also meant changing the settings on my router box for my new ISP.I took this opportunity to review my router's other settings too. I'll be blogging about these over the next few posts.
Adding IPv6 support to my home LAN
I have been following the evolution of IPv6 ever since the KAME project produced the first IPv6 implementation. I have also been keeping track of the IPv4 address depletion.
Around the time the IPv6 Day was organized in 2011, I started investigating the situation of IPv6 support at local ISPs.
Well, never mind all those rumors about Finland being some high-tech mecca. Back then, no ISP went beyond testing their routers for IPv6 compatibility and producing white papers on what their limited test deployments accomplished.
Not that it matters much, in practice. Most IPv6 documentation out there, including Debian's own, still focuses on configuring transitional mechanisms, especially how to connect to a public IPv6 tunnel broker.
Relocating to a new flat and rethinking my home network to match gave me an opportunity to revisit the topic. Much to my delight, my current ISP offers native IPv6.
This prompted me to go back and read up on IPv6 one more time. One important detail:
IPv6 hosts are globally reachable.
The implications of this don't immediately spring to mind for someone used to IPv4 network address translation (NAT):
Any network service running on an IPv6 host can be reached by anyone anywhere.
Contrary to IPv4, there is no division between private and public IP addresses. Whereas a device behind an IPv4 NAT essentially is shielded from the outside world, IPv6 breaks this assumption in more than one way. Not only is the host reachable from anywhere, its default IPv6 address is a mathematical conversion (EUI-64) of the network interface's MAC address, which makes every connection forensically traceable to a unique device.
Basically, if you hadn't given much thought to firewalls until now, IPv6 should give you enough goose bumps to get around it. Tightening the configuration of every network service is also an absolute must. For instance, I configured sshd to only listen to private IPv4 addresses.
What /etc/network/interfaces might look like on an dual-stack (IPv4 + IPv6) host:
allow-hotplug enp9s0 iface enp9s0 inet dhcp iface enp9s0 inet6 auto privext 2 dhcp 1The
auto method means that IPv6 will be auto-configured using SLAAC; privext 2 enables IPv6 privacy options and specifies that we prefer connecting via the randomly-generated IPv6 address, rather than the EUI-64 calculated MAC specific address; dhcp 1 enables passive DHCPv6 to fetch additional routing information.
The above works for most desktop and laptop configurations.
Where things got more complicated is on the router. I decided early on to keep NAT to provide an IPv4 route to the outside world. Now how exactly is IPv6 routing done? Every node along the line must have its own IPv6 address... including the router's LAN interface. This is accomplished using the sample script found in Debian's IPv6 prefix delegation wiki page. I modified mine as follows (the rest of the script is omitted for clarity):
#Both LAN interfaces on my private network are bridged via br0 IA_PD_IFACE="br0" IA_PD_SERVICES="dnsmasq" IA_PD_IPV6CALC="/usr/bin/ipv6calc"Just put the script at the suggested location. We'll need to request a prefix on the router's outside interface to utilize it. This gives us the following
interfaces file:
allow-hotplug enp2s4 enp2s8 enp2s9 auto br0 iface enp2s4 inet dhcp iface enp2s4 inet6 auto request_prefix 1 privext 2 dhcp 1 iface enp2s8 inet manual iface enp2s8 inet6 manual iface enp2s9 inet manual iface enp2s9 inet6 manual iface br0 inet static bridge_ports enp2s8 enp2s9 address 10.10.10.254 iface br0 inet6 manual bridge_ports enp2s8 enp2s9 # IPv6 from /etc/dhcp/dhclient-exit-hooks.d/prefix_delegationThe IPv4 NAT and IPv6 Bridge script on my router looks as follows:
#!/bin/sh PATH="/usr/sbin:/sbin:/usr/bin:/bin" wan=enp2s4 lan=br0 ######################################################################## # IPv4 NAT iptables -F; iptables -t nat -F; iptables -t mangle -F iptables -X; iptables -t nat -X; iptables -t mangle -X iptables -Z; iptables -t nat -Z; iptables -t mangle -Z iptables -t nat -A POSTROUTING -o $wan -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward ######################################################################## # IPv6 bridge ip6tables -F; ip6tables -X; ip6tables -Z # Default policy DROP ip6tables -P FORWARD DROP # Allow ICMPv6 forwarding ip6tables -A FORWARD -p ipv6-icmp -j ACCEPT # Allow established connections ip6tables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT # Accept packets FROM LAN to everywhere ip6tables -I FORWARD -i $lan -j ACCEPT echo 1 > /proc/sys/net/ipv6/conf/all/forwarding echo 1 > /proc/sys/net/ipv6/conf/default/forwarding # IPv6 propagation via /etc/dhcp/dhclient-exit-hooks.d/prefix_delegationThe above already provided enough IPv6 connectivity to pass the IPv6 test on my desktop inside the LAN. To make things more fun, I enabled DHCPv6 support for my LAN on the router's dnsmasq by adding the last 3 lines to the configuration:
dhcp-hostsfile=/etc/dnsmasq-ethersfile bind-interfaces interface=br0 except-interface=enp2s4 no-dhcp-interface=enp2s4 dhcp-range=tag:br0,10.10.10.0,static,infinite dhcp-range=tag:br0,::1,constructor:br0,ra-names,ra-stateless,infinite enable-ra dhcp-option=option6:dns-server,[::],[2606:4700:4700::1111],[2001:4860:4860::8888]The 5 first lines (included here for emphasis) are extremely important: they ensure that dnsmasq won't provide any IPv4 or IPv6 service to the outside interface (enp2s4) and that DHCP will only be provided for LAN hosts whose MAC address is known. Line 6 shows how dnsmasq's DHCP service syntax differs between IPv4 and IPv6. The rest of my configuration was omitted on purpose. Enabling native IPv6 on my LAN has been an interesting experiment. I'm sure that someone could come up with even better ip6tables rules for the router or for my desktop hosts. Feel free to mention them in the blog's comment.
A couple of years ago, I moved into a new flat that comes with RJ45 sockets wired for 10 Gigabit (but currently offering 1 Gigabit) Ethernet.This also meant changing the settings on my router box for my new ISP.I took this opportunity to review my router's other settings too. I'll be blogging about these over the next few posts.
GRUB fine-tuning
One thing that had been annoying me ever since Debian migrated to systemd as /sbin/init is that boot message verbosity hasn't been the same. Previously, the cmdline option quiet merely suppressed the kernel's output to the bootscreen, but left the daemon startup messages alone. Not anymore. Nowadays, quiet produces a blank screen.
After some googling, I found the solution to that:
GRUB_CMDLINE_LINUX_DEFAULT="noquiet loglevel=5"
The former restores daemon startup messages, while the later makes the kernel output only significant notices or more serious messages. On most of my hosts, it mostly reports inconsistencies in the ACPI configuration of the BIOS.
Another setting I find useful is a reboot delay in case a kernel panic happens:
GRUB_CMDLINE_LINUX="panic=15"
This gives me enough time to snap a picture of the screen output to attach to the bug report that will follow.
I released version 2.5 of ledger2beancount, a ledger to beancount converter.
Here are the changes in 2.5:
0 correctly0 amounts to notesprice==cost but when they use different number formatsprice==cost but per-unit and total notation mixedD directive to set default commodity for hledgerConfig::Onion module
So here's an interesting thing. Certain commit hashes
are rapidly heading toward being
illegal on Github.
So, if you clone a git repo from somewhere else, you had better be wary of
pushing it to Github. Because if it happened to contain one of those
hashes, that could get you banned from Github. Which, as we know, is your
resume.
Now here's another interesting thing. It's entirely possible for me to add
one of those commit hashes to any of my repos, which of course, I
self host. I can do it without adding any of
the content which Github/Microsoft, as a RIAA member, wishes
to suppress.
When you clone the my repo, here's how it looks:
# git log
commit 1fff890c0980a72d669aaffe9b13a7a077c33ecf (HEAD -> master, origin/master, origin/HEAD)
Author: Joey Hess <joeyh@joeyh.name>
Date: Mon Nov 2 18:29:17 2020 -0400
remove submodule
commit 8864d5c1182dccdd1cfc9ee6e5d694ae3c70e7af
Author: Joey Hess <joeyh@joeyh.name>
Date: Mon Nov 2 18:29:00 2020 -0400
add
# git ls-tree HEAD^
160000 commit b5[redacted cuz DMCA+Nov 3 = too much] back up your cat videos with this
100644 blob 45b983be36b73c0788dc9cbcb76cbb80fc7bb057 hello
#!/bin/sh
printf "Enter the url of the illegal repo, Citizen: "
read wha
git submodule add "$wha" wha
git rm .gitmodules
git commit -m wha
git rm wha
git commit -m wha
A new RcppSimdJson release arrived on CRAN late yesterday bringing along the one recently updated simdjson release 0.6.0.
RcppSimdJson wraps the fantastic and genuinely impressive simdjson library by Daniel Lemire and collaborators. Via very clever algorithmic engineering to obtain largely branch-free code, coupled with modern C++ and newer compiler instructions, it results in parsing gigabytes of JSON parsed per second which is quite mindboggling. The best-case performance is faster than CPU speed as use of parallel SIMD instructions and careful branch avoidance can lead to less than one cpu cycle per byte parsed; see the video of the talk by Daniel Lemire at QCon (also voted best talk).
Other than the upstream update, Brendan added some new utilities to check for valid utf-8 or json format, and to minify json plus a small workaround for a clang-9 bug we encountered. We can confirm Daniel s statement on ridiculously fast utf-8 validattion. It is so cool to work with amazing tools.
The NEWS entry follows.
Courtesy of my CRANberries, there is also a diffstat report for this release. For questions, suggestions, or issues please use the issue tracker at the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.Changes in version 0.1.3 (2020-11-01)
- Added URLs to DESCRIPTION (Dirk closing #50).
- Upgraded to simdjson 0.6.0 (Dirk in #52).
- New policy option to always convert integers to
int64_t(Brendan in #55 closing #54).- Added workaround for odd clang-9 bug (Brendan in #57).
- New utility functions
is_valid_utf8(),is_valid_json()andfminify()(Brendan in #58).
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
The KDE Bugzilla handles a lot of projects and they often match with the repo name, but not always.
For instance we have ancient products and components at Bugzilla, as projects have a lifecycle from playground into Release Service, or Frameworks, sometimes with a change of name.
So you may end up searching Bugzilla quite awhile for the correct product and component to be able to confirm or create bug reports against an application.
Let's have a look at KPeople, and see why the situation is complicated.
You find two products in KDE Bugzilla: kpeople (the repository's name) and on the other hand Frameworks have the scheme of a "frameworks-" prefix: frameworks-kpeople.
From the data displayed even I as a developer am unable to tell which is the correct product to add new bug reports. Both have bug reports this year that got fixed and the number of bug reports is too low to get a clear picture of which to choose.
This is not only a problem of KDE; it is a general problem in different communities that it is hard for newcomers to find the correct place to search and add new bug reports.
That's why Debian added the bug report information for every package.
This should help users to search the upstream bug reports or create new ones (Bug-Submit and Bug-Database): https://wiki.debian.org/UpstreamMetadata#Fields
While I was collecting this information for Frameworks and KDE PIM, I wondered why KDE does not have links between each project and Bugzilla.
After some searching and discussions it became obvious, that KDE does not have this information that can be processed.
Okay let's fix this.
The obvious place to reach this information is the Project API available under https://projects.kde.org/api/.
To reach this goal I began adding Bugzilla information to the data source of the Project API named Git Repo Metadata.
Then a merge request later the Project API is able to generate the links to Bugzilla invent:sysadmin/projects-api!2.
Where you should search for bugs in kontact? Go to https://projects.kde.org/api/v1/identifier/kontact:
issoPackage = with pkgs.python3Packages; buildPythonPackage rec pname = "isso"; version = "custom"; src = pkgs.fetchFromGitHub # Use my fork owner = "vincentbernat"; repo = pname; rev = "vbe/master"; sha256 = "0vkkvjcvcjcdzdj73qig32hqgjly8n3ln2djzmhshc04i6g9z07j"; ; propagatedBuildInputs = [ itsdangerous jinja2 misaka html5lib werkzeug bleach flask-caching ]; buildInputs = [ cffi ]; checkInputs = [ nose ]; checkPhase = '' $ python.interpreter setup.py nosetests ''; ;
"$ issoEnv /bin/gunicorn", like with a virtual
environment.
issoEnv = pkgs.python3.buildEnv.override extraLibs = [ issoPackage pkgs.python3Packages.gunicorn pkgs.python3Packages.gevent ]; ;
issoConfig = pkgs.writeText "isso.conf" '' [general] dbpath = /db/comments.db host = https://vincent.bernat.ch http://localhost:8080 notify = smtp [ ] '';
Dockerfile:
issoDockerImage = pkgs.dockerTools.buildImage name = "isso"; tag = "latest"; extraCommands = '' mkdir -p db ''; config = Cmd = [ "$ issoEnv /bin/gunicorn" "--name" "isso" "--bind" "0.0.0.0:$ port " "--worker-class" "gevent" "--workers" "2" "--worker-tmp-dir" "/dev/shm" "--preload" "isso.run" ]; Env = [ "ISSO_SETTINGS=$ issoConfig " "SSL_CERT_FILE=$ pkgs.cacert /etc/ssl/certs/ca-bundle.crt" ]; ; ;
issoEnv derivation in config.Cmd, the
whole derivation, including Isso and Gunicorn, is copied inside the
Docker image. The same applies for issoConfig, the configuration
file we created earlier, and pkgs.cacert, the derivation containing
trusted root certificates. The resulting image is 171 MB once
installed, which is comparable to the Debian Buster image generated by
the official Dockerfile.
NixOS features an abstraction to run Docker containers. It is not
currently documented in NixOS manual but you can look at the source
code of the module for the available options. I choose to use
Podman instead of Docker as the backend because it does not
require running an additional daemon.
virtualisation.oci-containers = backend = "podman"; containers = isso = image = "isso"; imageFile = issoDockerImage; ports = ["127.0.0.1:$ port :$ port "]; volumes = [ "/var/db/isso:/db" ]; ; ; ;
$ systemctl status podman-isso.service podman-isso.service Loaded: loaded (/nix/store/a66gzqqwcdzbh99sz8zz5l5xl8r8ag7w-unit-> Active: active (running) since Sun 2020-11-01 16:04:16 UTC; 4min 44s ago Process: 14564 ExecStartPre=/nix/store/95zfn4vg4867gzxz1gw7nxayqcl> Main PID: 14697 (podman) IP: 0B in, 0B out Tasks: 10 (limit: 2313) Memory: 221.3M CPU: 10.058s CGroup: /system.slice/podman-isso.service 14697 /nix/store/pn52xgn1wb2vr2kirq3xj8ij0rys35mf-podma> 14802 /nix/store/7vsba54k6ag4cfsfp95rvjzqf6rab865-conmo> nov. 01 16:04:17 web03 podman[14697]: container init (image=localhost/isso:latest) nov. 01 16:04:17 web03 podman[14697]: container start (image=localhost/isso:latest) nov. 01 16:04:17 web03 podman[14697]: container attach (image=localhost/isso:latest) nov. 01 16:04:19 web03 conmon[14802]: INFO: connected to SMTP server nov. 01 16:04:19 web03 conmon[14802]: INFO: connected to https://vincent.bernat.ch nov. 01 16:04:19 web03 conmon[14802]: [INFO] Starting gunicorn 20.0.4 nov. 01 16:04:19 web03 conmon[14802]: [INFO] Listening at: http://0.0.0.0:8080 (1) nov. 01 16:04:19 web03 conmon[14802]: [INFO] Using worker: gevent nov. 01 16:04:19 web03 conmon[14802]: [INFO] Booting worker with pid: 8 nov. 01 16:04:19 web03 conmon[14802]: [INFO] Booting worker with pid: 9
comments.luffy.cx to the container. NixOS provides a simple
integration to grab a Let s Encrypt certificate.
services.nginx.virtualHosts."comments.luffy.cx" = root = "/data/webserver/comments.luffy.cx"; enableACME = true; forceSSL = true; extraConfig = '' access_log /var/log/nginx/comments.luffy.cx.log anonymous; ''; locations."/" = proxyPass = "http://127.0.0.1:$ port "; extraConfig = '' proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_hide_header Set-Cookie; proxy_hide_header X-Set-Cookie; proxy_ignore_headers Set-Cookie; ''; ; ; security.acme.certs."comments.luffy.cx" = email = lib.concatStringsSep "@" [ "letsencrypt" "vincent.bernat.ch" ]; ;
Back in 2017 I announced that the https://Debian-Administration.org website was being made read-only, and archived.
At the time I wrote a quick update to save each requested page as a flat-file, hashed beneath /tmp, with the expectation that after a few months I'd have a complete HTML-only archive of the site which I could serve as a static-website, instead of keeping the database and pile of CGI scripts running.
Unfortunately I never got round to archiving the pages in a git-repository, or some other store, and I usually only remembered this local tree of content was available a few minutes after I'd rebooted the server and lost the stuff - as the reboot would reap the contents of /tmp!
Thinking about it today I figured I probably didn't even need to do that, instead I just need to redirect to the wayback machine. Working on the assumption that the site has been around for "a while" it should have all the pages mirrored by now I've made a "final update" to Apache:
RewriteEngine on
RewriteRule ^/(.*) "http://web.archive.org/web/https://debian-administration.org/$1" [R,L]
phpmyadmin, php-bacon-baconqrcode, twig, php-dasprid-enum, sql-parser, and mariadb-mysql-kbs for William.
:wq for today.
Here is my monthly update covering what I have been doing in the free software world during October 2020 (previous month):
ora2pg is a tool used to migrate an Oracle database to PostgreSQL. This month, I submitted a patch to make it build reproducibly. [...]
declares-possibly-conflicting-debhelper-compat-versions tag as we may specify the Debhelper compatibility level in debian/rules or debian/control (#972464) and dropped a reference to missing manual page [...].
perl: Please make the build mostly reproducible. (#972559)
fckit: Please make the build (mostly) reproducible. (#972378)
libgrokj2k: Please make the documentation reproducible. (#972494)
netcdf-parallel: Please make the settings file reproducible. (#972930)
dh-fortran-mod: Please make the output reproducible
version graph. (#965255)
emacs package to make the generated .el files reproducible, a regression that is causing many packages to become unreproducible. (#972861)
dpkg-buildflags to enable reproducible=+fixfilepath by default.
dettrace [...], and added yet another supply-chain security attack publication [...].relative_url to fix missing translation icon on various pages. [...]161 to Debian:
test_ocaml to the assert_diff helper. [...]20.8b1. (#972518)--help-only test as being a 'superficial' test. (#971506)try.diffoscope.org service. [...]debhelper compatibility level to 13 [...] and bump Standards-Version to 4.5.0 [...].jackson-databind, a Java library for processing JSON, to address an external entity expansion vulnerability.
tomcat8, the Java application server. This was to fix an issue where an excessive number of concurrent streams could have resulted in users seeing responses for unexpected resources.
3.1.2-1) New upstream bugfix release.
6.0.8-2 Apply a patch from Yossi Gottlieb to fix a crash when reporting RDB/AOF file errors. (#972683)6.0.9-1 New upstream release.1.6.8+dfsg-1) New upstream release)
4.0.25-1) New upstream release, where parsing configuration file now works correctly with Turkish locale. (#972387)
2.0-1) New upstream release.
20.8b1-2) Non-maintainer upload to correct version handling to avoid a ModuleNotFoundError error which was affecting a number of related packages. (#970901)
Another month, another bunch of uploads. The freeze for Debian 11 (bullseye) is edging closer, so I ve been trying to get my package list in better shape ahead of that. Thanks to those who worked on fixing lintian.debian.org and the lintian reports on the QA pages, those are immensely useful and it s great to have that back!
2020-10-04: Upload package gnome-shell-extension-draw-on-your-screen (8-1) to Debian unstable.
2020-10-05: Sponsor package flask-restful (0.3.8-4) for Debian unstable (Python Team request).
2020-10-05: Sponsor package python-potr (1.0.2-3) for Debian unstable (Python Team request).
2020-10-06: Sponsor package python-pyld (2.0.3-1) for Debian unstable (Python Team request).
2020-10-06: Sponsor package flask-openid (1.2.5+dfsg-4) for Debian unstable (Python Team request).
2020-10-06: Sponsor package qosmic (1.6.0-4) for Debian unstable (E-mail request).
2020-10-07: File removal for gnome-shell-extension-workspace-to-dock (RC Buggy, no longer maintained: #971803).
2020-10-07: Upload package gnome-shell-extension-pixelsaver (1.20-2) to Debian unstable (Closes: #971689).
2020-10-07: Upload package calamares (3.2.31-1) to Debian unstable.
2020-10-07: Upload package gnome-shell-extension-dashtodock (69-1) to Debian unstable (Closes: #971654).
2020-10-08: Sponsor package python3-libcloud (3.020-1) for Debian unstable.
2020-10-09: Upload package gnome-shell-extension-dashtopanel (40-1) to Debian unstable (Closes: #971087).
2020-10-09: Upload package gnome-shell-extension-draw-on-your-screen (8.1-1) to Debian unstable.
2020-10-12: Upload package gnome-shell-extension-pixelsaver (1.24-1) to Debian unstable.
2020-10-14: Sponsor package python3-onewire (0.2-1) for Debian unstable (Python Team request).
2020-10-15: Sponsor package cheetah (3.2.5-1) for Debian unstable (Python Team request).
2020-10-15: Sponsor package xmodem (0.4.6+dfsg-1) for Debian unstable (Python Team request).
2020-10-15: Sponsor package ansi (0.1.5-1) for Debian unstable (Python Team request).
2020-10-15: Sponsor package cbor2 (5.2.0-1) for Debian unstable (Python Team request).
2020-10-16: Upload package calamares (3.2.32-1) to Debian unstable.
2020-10-17: Upload package calamares (3.2.32.1-1) to Debian unstable.
2020-10-18: Upload package kpmcore (4.2.0-1) to Debian unstable.
2020-10-18: Upload package gnome-shell-extension-draw-on-your-screen (9-1) to Debian unstable.
2020-10-18: Upload package bundlewrap (4.2.1-1) to Debian unstable.
2020-10-18: Upload package bcachefs-tools (0.1+git20201017.8a4408-1~exp1) to Debian experimental.
2020-10-18: Upload package calamares (3.2.32.1-2) to Debian unstable.
2020-10-18: Upload package partitionmanager (4.1.0-2) to Debian unstable.
2020-10-19: Upload package kpmcore (4.2.0-2) to Debian unstable.
2020-10-21: Upload package calamares (3.2.32.1-3) to Debian unstable.
2020-10-21: Upload package calamares-settings-debian (11.0.3-1) to Debian unstable (Closes: #969930, #941301).
2020-10-21: Upload package partitionmanager (4.2.0-1) to Debian unstable.
2020-10-21: Upload package gnome-shell-extension-hard-disk-led (22-1) to Debian unstable (Closes: #971041).
2020-10-21: Merge MR!1 for catimg (Janitor improvements).
2020-10-21: Sponsor package r4d (1.7-1) for Debian unstable (Python Team request).
2020-10-22: Upload package aalib (1.4rc5-47) to Debian unstable.
2020-10-22: Upload package fabulous (0.3.0+dfsg1-8) to Debian unstable.
2020-10-22: Merge MR!1 for gdisk (Janitor improvements).
2020-10-22: Merge MR!1 for gnome-shell-extension-arc-menu (New upstream URLs, thanks Edward Betts).
2020-10-22: Upload package gnome-shell-extension-arc-menu (49-1) to Debian unstable.
2020-10-22: Upload package gnome-shell-extension-draw-on-your-screen (10-1) to Debian unstable.
2020-10-22: Merge MR!1 for vim-airline (Janitor improvements).
2020-10-22: Merge MR!1 for vim-airline-themes (Janitor improvements).
2020-10-22: Merge MR!1 for preload (Janitor improvements).
2020-10-22: Upload package aalib (1.4rc5-48) to Debian unstable.
2020-10-22: Upload package gnome-shell-extension-trash (0.2.0-git20200326.3425fcf1-1).
2020-10-26: Upload package bcachefs-tools (0.1+git20201025.742dbbdb-1) to Debian unstable.
2020-10-26: Sponsor package dunst (1.5.0-1) for Debian unstable (mentors.debian.net request).
I frequently see a pattern in image build/refresh scripts where a set of packages is installed, and then all packages are updated:
apt update apt install -y pkg1 pkg2 pkg2 apt dist-upgrade -yWhile it s not much, this results in redundant work. For example reading/writing package database, potentially running triggers (man-page refresh, ldconfig, etc). The internal package dependency resolution stuff isn t actually different: install will also do upgrades of needed packages, etc. Combining them should be entirely possible, but I haven t found a clean way to do this yet. The best I ve got so far is:
apt update apt-cache dumpavail dpkg --merge-avail - (for i in pkg1 pkg2 pkg3; do echo "$i install") dpkg --set-selections apt-get dselect-upgradeThis gets me the effect of running install and upgrade at the same time, but not dist-upgrade (which has slightly different resolution logic that d I d prefer to use). Also, it includes the overhead of what should be an unnecessary update of dpkg s database. Anyone know a better way to do this? Update: Julian Andres Klode pointed out that
dist-upgrade actually takes package arguments too just like install. *face palm* I didn t even try it I believed the man-page and the -h output. It works perfectly!
2020, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
We all know these situations when we receive an email asking Can you
check the design of X, I need a reply by tonight. Or an instant
message: My website went down, can you check? Another email: I
canceled a plan at the hosting company, can you restore my website as
fast as possible? A phone call: The TLS certificate didn t get
updated, and now we can t access service Y. Yet another email: Our
super important medical advice website is suddenly being censored in
country Z, can you help?
Everyone knows those messages that have URGENT in capital letters in
the email subject. It might be that some of them really are urgent.
Others are the written signs of someone having a hard time properly
planning their own work and passing their delays on to someone who comes
later in the creation or production chain. And others again come from
people who are overworked and try to delegate some of their tasks to a
friendly soul who is likely to help.
when an Asker meets a Guesser, unpleasantness results. An Asker won t think it s rude to request two weeks in your spare room, but a Guess culture person will hear it as presumptuous and resent the agony involved in saying no. Your boss, asking for a project to be finished early, may be an overdemanding boor or just an Asker, who s assuming you might decline. If you re a Guesser, you ll hear it as an expectation.Askers should also be aware that there might be Guessers in their team. It can help to define clear guidelines about making requests (when do I expect an answer, under which budget/contract/responsibility does the request fall, what other task can be put aside to handle the urgent task?) Last, but not least, Making work visible has a lot of other proposals on how to visibilize and then deal with unplanned work.
Next.