Russ Allbery: Review: Golden Gates
| Publisher: | Penguin |
| Copyright: | 2020 |
| ISBN: | 0-525-56022-X |
| Format: | Kindle |
| Pages: | 249 |
| Publisher: | Penguin |
| Copyright: | 2020 |
| ISBN: | 0-525-56022-X |
| Format: | Kindle |
| Pages: | 249 |
sip:657837644.522827@192.168.169.170Now if only jami would reduce its memory usage, I could even recommend this setup to others. :) As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
Welcome to the April 2020 report from the Reproducible Builds project. In our regular reports we outline the most important things that we and the rest of the community have been up to over the past month.
What are reproducible builds? One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. But whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into seemingly secure software during the various compilation and distribution processes.
It was discovered that more than 725 malicious packages were downloaded thousands of times from RubyGems, the official channel for distributing code for the Ruby programming language. Attackers used a variation of typosquatting and replaced hyphens and underscores (for example, uploading a malevolent atlas-client in place of atlas_client) that executed a script that intercepted Bitcoin payments. (Ars Technica report)
Bernhard M. Wiedemann launched ismypackagereproducibleyet.org, a service that takes a package name as input and displays whether the package is reproducible in a number of distributions. For example, it can quickly show the status of Perl as being reproducible on openSUSE but not in Debian. Bernhard also improved the documentation of his unreproducible package to add some example patches for hash issues. [ ].
There was a post on Chaos Computer Club s website listing Ten requirements for the evaluation of Contact Tracing apps in relation to the SARS-CoV-2 epidemic. In particular:
4. Transparency and verifiability: The complete source code for the app and infrastructure must be freely available without access restrictions to allow audits by all interested parties. Reproducible build techniques must be used to ensure that users can verify that the app they download has been built from the audited source code.Elsewhere, Nicolas Boulenguez wrote a patch for the Ada programming language component of the GCC compiler to skip
-f.*-prefix-map options when writing Ada Library Information files. Amongst other properties, these .ali files embed the compiler flags used at the time of the build which results in the absolute build path being recorded via -ffile-prefix-map, -fdebug-prefix-map, etc.
In the Arch Linux project, kpcyrd reported that they held their first rebuilder workshop . The session was held on IRC and participants were provided a document with instructions on how to install and use Arch s repro tool. The meeting resulted in multiple people with no prior experience of Reproducible Builds validate their first package. Later in the month he also announced that it was now possible to run independent rebuilders under Arch in a hands-off, everything just works solution to distributed package verification.
Mathias Lang submitted a pull request against dmd, the canonical compiler for the D programming languageto add support for our SOURCE_DATE_EPOCH environment variable as well the other C preprocessor tokens such __DATE__, __TIME__ and __TIMESTAMP__ which was subsequently merged. SOURCE_DATE_EPOCH defines a distribution-agnostic standard for build toolchains to consume and emit timestamps in situations where they are deemed to be necessary. [ ]
The Telegram instant-messaging platform announced that they had updated to version 5.1.1 continuing their claim that they are reproducible according to their full instructions and therefore verifying that its original source code is exactly the same code that is used to build the versions available on the Apple App Store and Google Play distribution platforms respectfully.
Lastly, Herv Boutemy reported that 97% of the current development versions of various Maven packages appear to have a reproducible build. [ ]
In Debian this month, 89 reviews of Debian packages were added, 21 were updated and 33 were removed this month adding to our knowledge about identified issues. Many issue types were noticed, categorised and updated by Chris Lamb, including:
captures_build_path_in_hd5_database_filescargo_installs_crates2_jsonnondeterministic_devhelp_documentation_generated_by_gtk_docros_dynamic_reconfigure_captures_build_pathdebrebuild, a tool for rebuilding a Debian package given a .buildinfo file, proposing to add --standalone or --one-shot-mode functionality.
In openSUSE, Bernhard M. Wiedemann made the following changes:
blender (sort C readdir call, rejected upstream)guile/guix (parallelism race condition)mingw32-filesystem/mingw32-binutils (sort readdir, filesystem, toolchain)mingw64-filesystem/mingw64-binutils (sort readdir, filesystem, toolchain)musescore (non-deterministic .zip files)OBS (FTBFS in rebuild)perl-Image-Sane (report hung build on a single core VM)ruby2.7 (date, already upstream)vtk (drop unreproducible .pyc file)
In Arch Linux, a rebuilder instance has been setup at reproducible.archlinux.org that is rebuilding Arch s [core] repository directly. The first rebuild has led to approximately 90% packages reproducible contrasting with 94% on the Reproducible Build s project own ArchLinux status page on tests.reproducible-builds.org that continiously builds packages and does not verify Arch Linux packages. More information may be found on the corresponding wiki page and the underlying decisions were explained on our mailing list.
Chris Lamb made the following changes to diffoscope, the Reproducible Builds project s in-depth and content-aware diff utility that can locate and diagnose reproducibility issues (including preparing and uploading versions 139, 140, 141, 142 and 143 to Debian which were subsequently uploaded to the backports repository):
.dex files can also serve as APK containers so restrict the narrower identification of .dex files to files ending with this extension and widen the identification of APK files to when file(1) discovers a Dalvik file. (#28).p7c and .p7b certificates. (#94)zipinfo(1) warnings. (#97)pdftotext as a requirement to run the PDF test_metadata text. (#99)python3-h5py in debian/tests/control.in to ensure that we have this module installed during a test run to generate the fixtures in these tests. [ ]./setup.py test --pytest-args arguments. [ ]zipinfo directly instead of piping input via /dev/stdin in order to ensure portability to the BSD operating system [ ]. In addition, Ben Hutchings documented how --exclude arguments are matched against filenames [ ] and Jelle van der Waa updated the LLVM test fixture difference for LLVM version 10 [ ] as well as adding a reference to the name of the h5dump tool in Arch Linux [ ].
Lastly, Mattia Rizzolo also fixed in incorrect build dependency [ ] and Vagrant Cascadian enabled diffoscope to locate the openssl and h5dump packages on GNU Guix [ ][ ], and updated diffoscope in GNU Guix to version 141 [ ] and 143 [ ].
*.sym files as Java archives. (#15).zip filename filtering and exclude two patterns of files generated by Maven projects in fork mode. (#13)0.5.9-1 to Debian unstable. Vagrant Cascadian subsequently refreshed disorderfs in GNU Guix to version 0.5.9 [ ].
elixir (parallelism)gnutls (build failure)moonjit/bcc (compile-time CPU-detection)openstack (backport of patch to drop unreproducible sphinx .pickle files)x3270 (merged, update date patch)dh-cargo.gmap.gpick.herbstluftwm.libcamera.libctl.minetest-mod-xdecor.netgen-lvs.nickle.nmrpflash.node-mqtt.sprai.yaz.xxhash.acoular (report unknown non-determinism)cri-o (report a date issue)gnutls (report certtool being unable to extend certificates beyond 2049)gnutls (report copyright year variation)libxslt (report a bug about non-deterministic output from data corruption)python-astropy (report a future build failure in 2021)
This month, Chris Lamb made a large number of changes to our website and documentation in the following categories:
rb-general mailing list is probably a first step for contributors to take. [ ]jekyll-redirect-from over manual redirect pages [ ][ ] and add a redirect from /docs/buildinfo/ to /docs/recording/. (#23)/news/ namespace [ ] and improve formatting of archived news links [ ].
We operate a large and many-featured Jenkins-based testing framework that powers tests.reproducible-builds.org that, amongst many other tasks, tracks the status of our reproducibility efforts as well as identifies any regressions that have been introduced.
disorderfs-debug prefix in log output when we change non-disorderfs things in the file and, as it happens, do not run disorderfs at all. [ ]<a> HTML elements under <li> ones, which was causing a comma/bullet spacing issue. [ ]jekyll-redirect-from as it now needed by the reproducible-builds.org website. [ ]arm64 architecture, etc.. [ ][ ]debrebuild to version from the latest version of devscripts. [ ][ ]sbuild. [ ][ ][ ][ ][ ].buildinfo file and attempt to build and compare the result. [ ][ ][ ][ ]disorderfs package did not pass its GPG verification which was also fixed by Chris Lamb.
Hans-Christoph Steiner of the Guardian Project asked whether there would be interest in making our website translatable which resulted in a WIP merge request being filed against the website and a discussion on how to track translation updates.
#reproducible-builds on irc.oftc.net.
rb-general@lists.reproducible-builds.org
This month s report was written by Bernhard M. Wiedemann, Chris Lamb, Daniel Shahaf, Holger Levsen, Jelle van der Waa, kpcyrd, Mattia Rizzolo and Vagrant Cascadian. It was subsequently reviewed by a bunch of Reproducible Builds folks on IRC and the mailing list.
This is the ninth part in a series of blog posts. The previous post was Amiga floppy recovery project scope. The whole series is available here: Amiga.It's been a while since I've reported on my Amiga floppy recovery project. With my bulky Philips CRT attached I slowly ground through the process of importing all my floppy disks, which is now done. The majority of disks were imported without errors. Commercial disks were the most likely to fail to import. Possibly I'd have more success with them if I used a different copying technique than X-COPY's default, but my focus was not on the commercial disks. I have not yet restored the use of my LCD TV with the Amiga. I was waiting to hear back from Amiga Kit about an agreed return, but despite their web store claiming they're still open for business, I haven't been able to get any response to my emails to them since mid-February. I've given up, written off that order and bought an RGB/SCART adaptor elsewhere instead. Meanwhile my bulky CRT has returned to the loft. The next step is pretty boring: time to check over my spreadsheet of disks, the imported copies of them, make sure everything is accounted for and decide whether to make further attempts for any that failed or write them off. For commercial disks it's almost certainly less effort to track down someone else's rip than to try mine again. After that I can return to moving the Gotek floppy adaptor inside the Amiga case, as described in the last entry, and start playing.
The apt.postgresql.org repository has been extended
to cover the arm64 architecture.
We had occasionally received user request to add "arm" in the past, but it was
never really clear which kind of "arm" made sense to target for PostgreSQL. In
terms of Debian architectures, there's (at least) armel, armhf, and arm64.
Furthermore, Raspberry Pis are very popular (and indeed what most users seemed
to were asking about), but the raspbian "armhf" port is incompatible with the
Debian "armhf" port.
Now that most hardware has moved to 64-bit, it was becoming clear that "arm64"
was the way to go. Amit Khandekar made it happen that
HUAWEI Cloud Services
donated a arm64 build host with enough resources to build the arm64 packages
at the same speed as the existing amd64, i386, and ppc64el architectures.
A few days later, all the build jobs were done, including passing all
test-suites. Very few arm-specific issues were encountered which makes me
confident that arm64 is a solid architecture to run PostgreSQL on.
We are targeting Debian buster (stable), bullseye (testing), and sid
(unstable), and Ubuntu bionic (18.04) and focal (20.04). To use the arm64
archive, just add the normal sources.list entry:
deb https://apt.postgresql.org/pub/repos/apt buster-pgdg mainUbuntu focal At the same time, I've added the next Ubuntu LTS release to apt.postgresql.org: focal (20.04). It ships amd64, arm64, and ppc64el binaries.
deb https://apt.postgresql.org/pub/repos/apt focal-pgdg mainOld PostgreSQL versions Many PostgreSQL extensions are still supporting older server versions that are EOL. For testing these extension, server packages need to be available. I've built packages for PostgreSQL 9.2+ on all Debian distributions, and all Ubuntu LTS distributions. 9.1 will follow shortly. This means people can move to newer base distributions in their .travis.yml, .gitlab-ci.yml, and other CI files.
| Series: | Seraphina #1 |
| Publisher: | Ember |
| Copyright: | 2012 |
| ISBN: | 0-375-89658-9 |
| Format: | Kindle |
| Pages: | 360 |
The way developers somehow think DevOps is (or should be) an abbreviation of "Developers doing/replacing Operations" is terrifying to me.I'm also in the same boat as the author, in that I recommend and target Debian Stable + Backports (and some vendor/community repos when required).
However hard you work on documentation, it won't work for your software - unless you do it the right way.
I'm going to preach the wonders of Python dataclasses, but for reasons of interested to those who have already gone down the delightful rabbit-hole of typed Python. So let me start with a quick plug for mypy if you haven't heard about it.
Subscribe in a reader Subscribe by Email
Database of 15500 abandonware games free. One of the most complete video games museum. Take a trip down Memory Lane now! Warning: whole weekends can be lost.
For way too long now something I had meant to start was a little series about tips, tricks, tools, and toys. I had mentioned the idea a few times to a friend or two, and generally received a thumbs up or a go for it . But it takes a little to get over the humb and get going. And it turns out that last week s r^4 talk on upgrading to R 4.0.0 hit some latent demand as we are now at 1400 views on YouTube. Wowser.
So hence without further ado, let s kick off T^4. Similar in spirit to R^4, but broader in scope and going beyond R. The opening slides explaining what we plan to do are here, and the video link follows below:
With some luck we should have the first actual talk next week. See you then! 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.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
ssh -R127.0.0.1:2222:127.0.0.1:22 server.example.com will forward localhost:2222 on server.example.com to port 22 of the machine the SSH connection originated from. But what happens if the connection dies? Adding a while true; do ; done around it might help, but I would really like not to reinvent the wheel here!
Thankfully, somebody already invented that particular wheel and OpenWRT comes with a sshtunnel package that takes care of setting up and keeping up such tunnels and documentation how to do so. Just install the sshtunnel package, edit /etc/config/sshtunnel to contain a server stanza with hostname, port and username and a tunnelR stanza referring said server plus the local and remote sides of the tunnel and you're good to go.
config server home
option user user
option hostname server.example.com
option port 22
config tunnelR local_ssh
option server home
option remoteaddress 127.0.0.1
option remoteport 2222
option localaddress 127.0.0.1
option localport 22
The only caveat is that sshtunnel needs the OpenSSH client binary (and the package correctly depends on it) and OpenWRT does not ship the ssh-keygen tool from OpenSSH but only the equivalent for Dropbear. As OpenSSH can't read Dropbear keys (and vice versa) you'll have to generate the key somewhere else and deploy it to the OpenWRT box and the target system.
Oh, and OpenWRT defaults to enabling password login via SSH, so please disable that if you expose the box to the Internet in any way!
Using the tunnel
After configuring and starting the service, you'll see the OpenWRT system logging in to the configured remote and opening the tunnel. For some reason that connection would not show up in the output of w -- probably because there was no shell started or something, but logs show it clearly.
Now it's just a matter of connecting to the newly open port and you're in. As the port is bound to 127.0.0.1, the connection is only possible from server.example.com or using it as a jump host via OpenSSH's ProxyJump option: ssh -J server.example.com -p 2222 root@localhost.
Additionally, you can forward a local port over the tunneled connection to create a tunnel for the OpenWRT webinterface: ssh -J server.example.com -p 2222 -L8080:localhost:80 root@localhost. Yes, that's a tunnel inside a tunnel, and all the network engineers will go brrr, but it works and you can access LuCi on http://localhost:8080 just fine.
If you don't want to type that every time, create an entry in your .ssh/config:
Host openwrt
ProxyJump server.example.com
HostName localhost
Port 2222
User root
LocalForward 8080 localhost:80
And we're done. Enjoy easy access to the newly deployed box and carry on./etc/hostname: foobar/etc/mailname: foobar.example.com/etc/hosts: 127.0.0.1 foobar.example.com vogar localhostavahi-daemon package to be able to reach this box
using foobar.local.
I noticed the presence of a world-writable
directory and so I
tightened the security of some of the default mount points by putting the following
in /etc/rc.local:
mount -o remount,nodev,nosuid /etc/network
mount -o remount,nodev,nosuid /lib/modules
chmod 755 /etc/network
exit 0
/dev/sda) is a small SSD so that the GnuBee can run silently when the
spinning disks aren't needed. To hold the backup data on the other hand, I
got three 4-TB drives drives which I setup in a
RAID-5 array.
If the data were valuable, I'd use
RAID-6 instead
since it can survive two drives failing at the same time, but in this case
since it's only holding backups, I'd have to lose the original machine at
the same time as two of the 3 drives, a very unlikely scenario.
I created new gpt partition tables on /dev/sdb, /dev/sdbc, /dev/sdd
and used fdisk to create a single partition of type 29 (Linux RAID) on
each of them.
Then I created the RAID array:
mdadm /dev/md127 --create -n 3 --level=raid5 -a /dev/sdb1 /dev/sdc1 /dev/sdd1
and waited more than 24 hours for that operation to finish. Next, I
formatted the array:
mkfs.ext4 -m 0 /dev/md127
and added the following to /etc/fstab:
/dev/md127 /mnt/data/ ext4 noatime,nodiratime 0 2
To reduce unnecessary noise and reduce power consumption, I also installed
hdparm:
apt install hdparm
and configured all spinning drives to spin down after being idle for 10
minutes by putting the following in /etc/hdparm.conf:
/dev/sdb
spindown_time = 120
/dev/sdc
spindown_time = 120
/dev/sdd
spindown_time = 120
and then reloaded the configuration:
/usr/lib/pm-utils/power.d/95hdparm-apm resume
Finally I setup smartmontools by putting
the following in /etc/smartd.conf:
/dev/sda -a -o on -S on -s (S/../.././02 L/../../6/03)
/dev/sdb -a -o on -S on -s (S/../.././02 L/../../6/03)
/dev/sdc -a -o on -S on -s (S/../.././02 L/../../6/03)
/dev/sdd -a -o on -S on -s (S/../.././02 L/../../6/03)
and restarting the daemon:
systemctl restart smartd.service
adduser machine1
adduser machine1 sshuser
adduser machine1 sftponly
chsh machine1 -s /bin/false
and then matching directories under /mnt/data/home/:
mkdir /mnt/data/home/machine1
chown machine1:machine1 /mnt/data/home/machine1
chmod 700 /mnt/data/home/machine1
Then I created a custom ssh key for each machine:
ssh-keygen -f /root/.ssh/foobar_backups -t ed25519
and placed it in /home/machine1/.ssh/authorized_keys on the GnuBee.
On each machine, I added the following to /root/.ssh/config:
Host foobar.local
User machine1
Compression no
Ciphers aes128-ctr
IdentityFile /root/backup/foobar_backups
IdentitiesOnly yes
ServerAliveInterval 60
ServerAliveCountMax 240
The reason for setting the ssh cipher and disabling compression is to speed
up the ssh connection as much
as possible given that the GnuBee has avery small RAM
bandwidth.
Another performance-related change I made on the GnuBee was switching to the internal sftp
server
by putting the following in /etc/ssh/sshd_config:
Subsystem sftp internal-sftp
# Configure for each host
PASSWORD="XXXX" # use pwgen -s 64 to generate a good random password
BACKUP_HOME="/root/backup"
REMOTE_URL="sftp:foobar.local:"
RETENTION_POLICY="--keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 2"
# Internal variables
SSH_IDENTITY="IdentityFile=$BACKUP_HOME/foobar_backups"
EXCLUDE_FILE="$BACKUP_HOME/exclude"
PKG_FILE="$BACKUP_HOME/dpkg-selections"
PARTITION_FILE="$BACKUP_HOME/partitions"
# If the list of files has been requested, only do that
if [ "$1" = "--list-current-files" ]; then
RESTIC_PASSWORD=$PASSWORD restic --quiet -r $REMOTE_URL ls latest
exit 0
# Show list of available snapshots
elif [ "$1" = "--list-snapshots" ]; then
RESTIC_PASSWORD=$GPG_PASSWORD restic --quiet -r $REMOTE_URL snapshots
exit 0
# Restore the given file
elif [ "$1" = "--file-to-restore" ]; then
if [ "$2" = "" ]; then
echo "You must specify a file to restore"
exit 2
fi
RESTORE_DIR="$(mktemp -d ./restored_XXXXXXXX)"
RESTIC_PASSWORD=$PASSWORD restic --quiet -r $REMOTE_URL restore latest --target "$RESTORE_DIR" --include "$2" exit 1
echo "$2 was restored to $RESTORE_DIR"
exit 0
# Delete old backups
elif [ "$1" = "--prune" ]; then
# Expire old backups
RESTIC_PASSWORD=$PASSWORD restic --quiet -r $REMOTE_URL forget $RETENTION_POLICY
# Delete files which are no longer necessary (slow)
RESTIC_PASSWORD=$PASSWORD restic --quiet -r $REMOTE_URL prune
exit 0
# Catch invalid arguments
elif [ "$1" != "" ]; then
echo "Invalid argument: $1"
exit 1
fi
# Check the integrity of existing backups
RESTIC_PASSWORD=$PASSWORD restic --quiet -r $REMOTE_URL check exit 1
# Dump list of Debian packages
dpkg --get-selections > $PKG_FILE
# Dump partition tables from harddrives
/sbin/fdisk -l /dev/sda > $PARTITION_FILE
/sbin/fdisk -l /dev/sdb > $PARTITION_FILE
# Do the actual backup
RESTIC_PASSWORD=$PASSWORD restic --quiet --cleanup-cache -r $REMOTE_URL backup / --exclude-file $EXCLUDE_FILE
I run it with the following cronjob in /etc/cron.d/backups:
30 8 * * * root ionice nice nocache /root/backup/backup-machine1-to-foobar
30 2 * * Sun root ionice nice nocache /root/backup/backup-machine1-to-foobar --prune
in a way that doesn't impact the rest of the system too much.
Finally, I printed a copy of each of my backup script, using
enscript, to stash in a safe place:
enscript --highlight=bash --style=emacs --output=- backup-machine1-to-foobar ps2pdf - > foobar.pdf
This is actually a pretty important step since without the password, you
won't be able to decrypt and restore what's on the GnuBee.
Debian project leader This month contained the first week and a half or so of my term as Debian Project Leader. So far my focus has been getting up to speed and keeping the gears turning with day to day DPL tasks. The updates listed here will also be available on the DPL blog, where I aim to make more frequent updates. During May, Debian Brazil will host Debian talks throughout the month which they will stream to their YouTube channel. You can find the schedule in this git repository, most of the talks will be in Portuguese, but on the 4th of May at 21:00 UTC, I ll be covering some Debian project topics for an hour or so and take some questions if there s time left. 2020-04-19: Handover session with Sam, our outgoing DPL. We covered a lot of questions I had and main areas that the DPL works in. Thanks to Sam for having taken the time to do this. 2020-04-21: First day of term! Thank you to everybody who showed support and have offered to help! 2020-04-21: Request feedback from the trademark team on an ongoing trademark dispute. 2020-04-21: Join the GNOME Advisory Board as a representative from Debian. 2020-04-21: Reply on an ongoing community conflict issue. 2020-04-21: Update Debian project summary for SPI annual report. 2020-04-21: Received a great e-mail introduction from Debian France and followed up on that. 2020-04-21: Posted Bits from the new DPL to debian-devel-announce. 2020-04-22: Became Debian s OSI Affilliate representative. 2020-04-22: Reply to a bunch of media inquiries for interviews, will do them later when initial priorities are on track. 2020-04-23: Resign as Debian FTP team trainee and mailing list moderator. In both these areas there are enough people taking care of it and I intend to maximise available time for DPL and technical areas in the project. 2020-04-25: Review outgoing mail for trademark team. 2020-04-25: Answer some questions in preparation for DAM/Front Desk delegation updates. 2020-04-26: Initiated wiki documentation for delegation updates process. 2020-04-27: Update delegation for the Debian Front Desk team. 2020-04-29: Schedule video call with Debian treasurer team. 2020-04-29: OSI affiliate call. Learned about some Open Source projects including OpenDev, OpenSourceMatters, FOSS Responders and Democracy Labs.
Debian Social Work on the Debian Social project is progressing, we plan to start a separate blog syndicated to Planet Debian that contains progress and status updates. I ve been terrible at tracking the work we ve been doing on this, so for now, here are some micro updates:
MiniDebConf Online In the DebConf video team, we ve been wondering whether we have all the tools required to successfully host a DebConf (or even a mini DebConf) entirely online. There s really just one way to know for sure, so we re going to host MiniDebConf Online from 28 May to 31 May. The first two days will be an online MiniDebCamp, where we can try to hold online spints, meetings and general chit-chat. The last two days will be for talks and lightnight talks, with BoFs likely to take place throughout the 4 days (this will probably be decided once we have a content team). Announcements should go out within the next week, in the meantime, save the dates.
Debian package uploads 2020-04-07: Upload package flask-autoindex (0.6.6-1) to Debian unstable. 2020-04-07: Upload package gamemode (1.5.1-1) to Debian unstable. 2020-04-08: Accept MR#2 for live-tasks (add usbutils to live-task-standard). 2020-04-08: Upload package live-tasks (11.0.2) to Debian unstable (Closes: #955526, #944578, #942837, #942834). 2020-04-08: Close live-config bug #655198 (Only affects squeeze which is no longer supported). 2020-04-08: Upload package live-config (11.0.1) to Debian unstable. 2020-04-08: Upload package calamares (3.2.22-1) to Debian unstable. 2020-04-15: Upload package xabacus (8.2.6-1) to Debian unstable. 2020-04-16: Merge MR#1 for gnome-shell-extension-dashtodock (new upstream release). 2020-04-16: Upload package gnome-shell-extension-dashtodock (67+git20200225-1) to Debian unstable. 2020-04-16: Merge MR#1 for gnome-shell-extension-hard-disk-led (fix some lintian issues). 2020-04-16: Merge MR#1 for gnome-shell-extension-system-monitor (fix some lintian issues). 2020-04-17: Upload package calamares (3.2.23-1) to Debian unstable. 2020-04-17: Upload package catimg (2.6.0-1) to Debian unstable (Closes: #956150). 2020-04-17: Upload package fabulous (0.3.0+dfsg1-7) to Debian unstable (Closes: #952242). 2020-04-17: Upload package gnome-shell-extension-system-monitor (38+git20200414-32cc79e-1) to Debian unstable (Closes: #956656, #956171). 2020-04-17: Upload package gnome-shell-extension-arc-menu (45-1) to Debian unstable (Closes: #956168). 2020-04-18: Upload package toot (0.26.0-1) to Debian unstable. 2020-04-23: Update packaging for gnome-shell-extension-tilix-shortcut, upstream section needs some additional work before release is possible. 2020-04-23: Upload package xabacus (8.2.7-1) to Debian unstable. 2020-04-27: Upload package gnome-shell-extension-dash-to-panel (37-1) to Debian unstable (Closes: #956162, #954978). 2020-04-27: Upload package gnome-shell-extension-dash-to-panel (37-2) to Debian unstable. 2020-04-27: Upload package gnome-shell-extension-dashtodock (68-1) to Debian unstable. 2020-04-30: Merge MR#8 for gamemode (add symbol files) (Closes: #952425). 2020-04-30: Merge MR#9 for gamemode (reduce number of -dev packages generated). 2020-04-30: Merge MR#10 for gamemode (deal better with upgrades on a buggy version). 2020-04-30: Manually merge changes from MR#11 for gamemode (packaging fixes). 2020-04-30: Upload package gamemode (1.5.1-2) to Debian unstable.
$home.
--gem-install layout and fixing autopkgtest.Conflicts field.ARM $arch.Breaks+Replaces for ruby-sass-rails (#952682 and #954544).cut -d'-' -f1 to just show upstream version.
encryptor for Ruby2.7 test failures.image_science for removing relative paths.ffi-yajl for Ruby2.7 test failures.aggregate for simply using require.aggregate for modernizing CI and adding Ruby 2.5 and 2.7 support.espeak-ruby for Ruby2.7 test failures.tty-which for test failures in general.packable for Ruby2.7 test failures. PR #12 has been proposed.growl for test failures and proposed an initial patch.
hugo-coder, asking to enable RSS feed for blogs.hugo-coder for fixing the above issue myself.arbre for requesting a release.combustion, asking to relax dependency on rubocop. Fixed in this commit.ffi-compiler for requesting to fix homepage and license.gographviz for requesting a release.crb-blast, suggesting compatability with bio 2.0.x.uniform_notifier for asking to drop the use of ruby-growl.polybar, adding installation instructions on Debian systems.:wq for today.
Here is my monthly update covering what I have been doing in the free software world during April 2020 (previous month's report). Looking it over prior to publishing, I am surprised how much I got done this month I felt that I was not only failing to do all the extra things I had planned, but I was doing far less than normal. But let us go easy on ourselves; nobody is nailing this.
send-later command's message limit. [...]
debian/rules files that specify -Wl,--as-needed as this is now the default from bullseye onwards. (#956146).debug. (#958945)--with=systemd with a Debhelper compatibility level of 10 or higher. (#949844)$* as using the Debhelper sequencer. (#930679)override dh_install (ie. with a space) in debian/rules; in 99% of cases this will be an omission of the underscore. [...]python3-all-dev and python3-all-dbg to satisfy the check for packages that use py3versions with the -s argument. (#955799, #956134)Build-Depends-Arch and Build-Depends-Indep do not imply each other, so don't warn about "duplicate" dependencies in this case. (#956368)py3versions -s without the corresponding Build-Depends. (#958794)pre-depends-directly-on-multiarch-support tag; any package pre-depending on the multiarch-support will not be installable in the bullseye distribution. (#798762)mailing-list-obsolete-in-debian-infrastructure as being experimental. (#958182, #958666)dh_dwz-generated "multi-files". (#955752)package-relation-with-self if we have specified a required architecture. (#956227)package-uses-old-debhelper-compat-version when run against itself. [...].travis.yml file as we are using Salsa now. [...]
One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes.
The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised.
The initiative is proud to be a member project of the Software Freedom Conservancy, a not-for-profit 501(c)(3) charity focused on ethical technology and user freedom.
Conservancy acts as a corporate umbrella allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter.
otf-active mailing list this final report described in detail the status of each objective, our overall lessons and our future plans.
disorderfs-debug prefix in log output when we change non-disorderfs things in the file and, as it happens, do not run disorderfs at all. [...]a HTML elements under li ones, which was causing a comma/bullet spacing issue. [...]*.sym files as Java archives. (#15).zip filename filtering and exclude two patterns of files generated by Maven projects in "fork" mode. (#13)
Elsewhere in our tooling, I made the following changes to diffoscope, our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues, including preparing and uploading versions 139, 140, 141 and 142 to Debian:
.dex files can also serve as APK containers so restrict the narrower identification of .dex files to files ending with this extension and widen the identification of APK files to when file(1) discovers a Dalvik file. (#28).p7c and .p7b certificates. (#94)zipinfo(1) warnings. (#97)pdftotext as a requirement to run the PDF test_metadata text. (#99)python3-h5py in debian/tests/control.in to ensure that we have this module installed during a test run to generate the fixtures in these tests. [...]./setup.py test --pytest-args arguments. [...]rb-general mailing list is probably a first step for contributors to take. [...]/docs/buildinfo/ to /docs/recording/. (#23)/news/ namespace [...] and improve formatting of archived news links [...].ntp Network Time Protocol server to prevent a denial of service vulnerability (CVE-2020-11868).
ntp in ELA-224-2 to add further protection that was not present in the previous update.
Content-Type HTTP header is missing when downloading .deb files (#956471) and to report build failures in the macs & ruby-enumerable-statistics packages:
6.0~rc3-1 New upstream beta release.6.0~rc4-1 New upstream beta release and use the newly-packaged liblzf-dev package over the local version. (#958321)5.0.7-3 Fix build failures with GCC 10. (#957751)5.0.7-4 Use the newly-packaged liblzf-dev package over the bundled version. (#958321)5.0.7-5 Ensure that the daemon is running prior to running the autopkgtests.5.0.7-6 Perform a "no change" sourceful upload to permit migration to the testing distribution.5.0.7-7 Add a sleep to ensure that the server has started before running the tests.2.2.12-1 New upstream release.3.0.5-1 New upstream release.1.6.3-1 New upstream release.1.6.5-1 New upstream release.1.6.5-2 Fix a failing autopkgtest that assumes a particular string is in the first kilobyte of the response which was no longer the case due to the addition of new configuration options.1.2.2-1 New upstream release.1.2.2-2 Ensure that the server is started before running autopkgtests.1.2.2-3 Sleep to ensure the server has really started before running the autopkgtests.2.2-2) Replace python-nautilus in the build-dependencies with python3-nautilus. (#943137)
15) Correct the (confusing) internal logic of --force from being visible to users. (#895686)
20.0.0-1) New upstream release and refresh packaging.
1.0.1-1) New upstream release and refresh packaging.
0.6-3) Mark a non-deterministic autopkgtest as "flaky" for now to ease migration (#930448) and use DEB_VERSION_UPSTREAM_REVISION over manually parsing dpkg-parsechangelog in debian/rules.
A SYNCNI article passed by on my Twitter feed this morning, talking about balancing work life balance while working from home in these times of COVID-19 inspired lock down. The associated Twitter thread expressed an interest in some words of advice from men to other men (because of course the original article has the woman having to do all the balancing).
This post does not contain the words of advice searched for, but it hopefully at least offers some reassurance that if you re finding all of this difficult you re not alone. From talking to others I don t think there s anything particularly special we re doing in this house; a colleague is taking roughly the same approach, and some of the other folk I ve spoken to in the local tech scene seem to be doing likewise.
First, the situation. Like many households both my wife and I work full time. We have a small child (not even a year and a half old yet). I work for a software startup, my wife is an HR business partner for a large multinational, dealing with employees all over the UK and Ireland. We re both luckily able to work from home easily - our day to day work machines are laptops, our employers were already setup with the appropriate VPN / video conferencing etc facilities. Neither of us has seen any decrease in workload since lock down; there are always more features and/or bugs to work on when it comes to a software product, and, as I m sure you can imagine, there has been a lot more activity in the HR sphere over the past 6 weeks as companies try to work out what to do.
On top of this our childcare arrangements, like everyone else s, are completely gone. Nursery understandably shut down around the same time as the schools (slightly later, but not by much) and contact with grandparents is obviously out (which they re finding hard). So we re left with trying to fit 2 full time jobs in with full time childcare, of a child who up until recently tried to go down stairs by continuing to crawl forward.
Make no mistake, this is hard. I know we are exceptionally lucky in our situation, but that doesn t mean we re finding it easy. We ve adopted an approach of splitting the day up. I take the morning slot (previously I would have got up with our son anyway), getting him up and fed while my wife showers. She takes over for a bit while I shower and dress, then I take over again in time for her to take her daily 8am conference call.
My morning is mostly taken up with childcare until nap time; I try to check in first thing to make sure there s nothing urgent, and get a handle on what I might have to work on later in the day. My local team mates know they re more likely to get me late morning and it s better to arrange meetings in the afternoon. Equally I work with a lot of folk on the US West coast, so shifting my hours to be a bit later is not a problem there.
After nap time (which, if we re lucky, takes us to lunch) my wife takes over. As she deals with UK/Ireland folk she often ends up having to take calls even while looking after our son; generally important meetings can be moved to the morning and meetings with folk who understand there might be a lot of pot banging going on in the background can happen in the afternoon.
Having started late I generally work late - past the point where I d normally get home; if I m lucky I pop my head in for bath time, but sometimes it s only for a couple of minutes. We alternate cooking; usually based on work load + meetings. For example tonight I m cooking while my wife catches up on some work after having put our son to bed. Last night I had a few meetings so my wife cooked.
So what s worked for us? Splitting the day means we can plan with our co-workers. We always make sure we eat together in the evening, and that generally is the cut-off point for either of us doing any work. I m less likely to be online in the evening because my study has become the place I work. That means I m not really doing any of my personal projects - this definitely isn t a case of being at home during lock down and having lots of time to achieve new things. It s much more of case of trying to find a sustainable way to get through the current situation, however long it might last.
Next.