Trying to send email. Email is hard. Configuration is hard. I don't remember how I send email properly. Trying to use git send-email since ages, and I think I am getting email bounces from random lists. SPF failure. Oh now.
In this post, I demonstrate the optimal workflow for creating new Debian packages in 2025, preserving the upstream git history. The motivation for this is to lower the barrier for sharing improvements to and from upstream, and to improve software provenance and supply-chain security by making it easy to inspect every change at any level using standard git tooling.
Key elements of this workflow include:
git-buildpackage commands, with all package-specific options in gbp.conf.Files-Excluded in the debian/copyright file to filter out unwanted files in Debian.dh_make to create the initial Debian packaging.mkdir debian-entr
cd debian-entr
git clone --origin upstreamvcs --branch master \
--single-branch https://github.com/eradman/entr.gitgit clone lay the foundation for the Debian packaging git repository structure where the upstream git remote name is upstreamvcs. Only the upstream main branch is tracked to avoid cluttering git history with upstream development branches that are irrelevant for packaging in Debian.
Next, enter the git repository directory and list the git tags. Pick the latest upstream release tag as the commit to start the branch upstream/latest. This latest refers to the upstream release, not the upstream development branch. Immediately after, branch off the debian/latest branch, which will have the actual Debian packaging files in the debian/ subdirectory.
cd entr
git tag # shows the latest upstream release tag was '5.6'
git checkout -b upstream/latest 5.6
git checkout -b debian/latest%% init: 'gitGraph': 'mainBranchName': 'master' %% gitGraph: checkout master commit id: "Upstream 5.6 release" tag: "5.6" branch upstream/latest checkout upstream/latest commit id: "New upstream version 5.6" tag: "upstream/5.6" branch debian/latest checkout debian/latest commit id: "Initial Debian packaging" commit id: "Additional change 1" commit id: "Additional change 2" commit id: "Additional change 3"At this point, the repository is structured according to DEP-14 conventions, ensuring a clear separation between upstream and Debian packaging changes, but there are no Debian changes yet. Next, add the Salsa repository as a new remote which called
origin, the same as the default remote name in git.
git remote add origin git@salsa.debian.org:otto/entr-demo.git
git push --set-upstream origin debian/latestdebian/latest branch, which does not yet have any debian/ directory.
cd ..
podman run --interactive --tty --rm --shm-size=1G --cap-add SYS_PTRACE \
--env='DEB*' --volume=$PWD:/tmp/test --workdir=/tmp/test debian:sid bash--volume parameter will loop-mount the current directory inside the container. Thus all files created and modified are on the host system, and will persist after the container shuts down.
Once inside the container, install the basic dependencies:
apt update -q && apt install -q --yes git-buildpackage dpkg-dev dh-makedebian/ files with dh-make
To create the files needed for the actual Debian packaging, use dh_make:
# dh_make --packagename entr_5.6 --single --createorig
Maintainer Name : Otto Kek l inen
Email-Address : otto@debian.org
Date : Sat, 15 Feb 2025 01:17:51 +0000
Package Name : entr
Version : 5.6
License : blank
Package Type : single
Are the details correct? [Y/n/q]
Done. Please edit the files in the debian/ subdirectory now.dh_make works, the package name and version need to be written as a single underscore separated string. In this case, you should choose --single to specify that the package type is a single binary package. Other options would be --library for library packages (see libgda5 sources as an example) or --indep (see dns-root-data sources as an example). The --createorig will create a mock upstream release tarball (entr_5.6.orig.tar.xz) from the current release directory, which is necessary due to historical reasons and how dh_make worked before git repositories became common and Debian source packages were based off upstream release tarballs (e.g. *.tar.gz).
At this stage, a debian/ directory has been created with template files, and you can start modifying the files and iterating towards actual working packaging.
git add debian/
git commit -a -m "Initial Debian packaging"dh_make would be:
-- entr
-- LICENSE
-- Makefile.bsd
-- Makefile.linux
-- Makefile.linux-compat
-- Makefile.macos
-- NEWS
-- README.md
-- configure
-- data.h
-- debian
-- README.Debian
-- README.source
-- changelog
-- control
-- copyright
-- gbp.conf
-- entr-docs.docs
-- entr.cron.d.ex
-- entr.doc-base.ex
-- manpage.1.ex
-- manpage.md.ex
-- manpage.sgml.ex
-- manpage.xml.ex
-- postinst.ex
-- postrm.ex
-- preinst.ex
-- prerm.ex
-- rules
-- salsa-ci.yml.ex
-- source
-- format
-- upstream
-- metadata.ex
-- watch.ex
-- entr.1
-- entr.c
-- missing
-- compat.h
-- kqueue_inotify.c
-- strlcpy.c
-- sys
-- event.h
-- status.c
-- status.h
-- system_test.sh
-- entr_5.6.orig.tar.xzdebian/ directory are:
changelog,control,copyright,rules..ex are example files that won t have any effect until their content is adjusted and the suffix removed.
For detailed explanations of the purpose of each file in the debian/ subdirectory, see the following resources:
wrap-and-sort -vast or debputy reformat --style=black.
pcre2posix.h cannot be found or that libcre2-posix.so is missing, you can use these commands:
$ apt install -q --yes apt-file && apt-file update
$ apt-file search pcre2posix.h
libpcre2-dev: /usr/include/pcre2posix.h
$ apt-file search libpcre2-posix.so
libpcre2-dev: /usr/lib/x86_64-linux-gnu/libpcre2-posix.so
libpcre2-posix3: /usr/lib/x86_64-linux-gnu/libpcre2-posix.so.3
libpcre2-posix3: /usr/lib/x86_64-linux-gnu/libpcre2-posix.so.3.0.6debian/control should be extended to define a Build-Depends: libpcre2-dev relationship.
There is also dpkg-depcheck that uses strace to trace the files the build process tries to access, and lists what Debian packages those files belong to. Example usage:
dpkg-depcheck -b debian/rules builddebian/, test the build by running dpkg-buildpackage inside the container:
dpkg-buildpackage -uc -us -b-uc -us will skip signing the resulting Debian source package and other build artifacts. The -b option will skip creating a source package and only build the (binary) *.deb packages.
The output is very verbose and gives a large amount of context about what is happening during the build to make debugging build failures easier. In the build log of entr you will see for example the line dh binary --buildsystem=makefile. This and other dh commands can also be run manually if there is a need to quickly repeat only a part of the build while debugging build failures.
To see what files were generated or modified by the build simply run git status --ignored:
$ git status --ignored
On branch debian/latest
Untracked files:
(use "git add <file>..." to include in what will be committed)
debian/debhelper-build-stamp
debian/entr.debhelper.log
debian/entr.substvars
debian/files
Ignored files:
(use "git add -f <file>..." to include in what will be committed)
Makefile
compat.c
compat.o
debian/.debhelper/
debian/entr/
entr
entr.o
status.odpkg-buildpackage will include running the command dh clean, which assuming it is configured correctly in the debian/rules file will reset the source directory to the original pristine state. The same can of course also be done with regular git commands git reset --hard; git clean -fdx. To avoid accidentally committing unnecessary build artifacts in git, a debian/.gitignore can be useful and it would typically include all four files listed as untracked above.
After a successful build you would have the following files:
-- entr
-- LICENSE
-- Makefile -> Makefile.linux
-- Makefile.bsd
-- Makefile.linux
-- Makefile.linux-compat
-- Makefile.macos
-- NEWS
-- README.md
-- compat.c
-- compat.o
-- configure
-- data.h
-- debian
-- README.source.md
-- changelog
-- control
-- copyright
-- debhelper-build-stamp
-- docs
-- entr
-- DEBIAN
-- control
-- md5sums
-- usr
-- bin
-- entr
-- share
-- doc
-- entr
-- NEWS.gz
-- README.md
-- changelog.Debian.gz
-- copyright
-- man
-- man1
-- entr.1.gz
-- entr.debhelper.log
-- entr.substvars
-- files
-- gbp.conf
-- patches
-- PR149-expand-aliases-in-system-test-script.patch
-- series
-- system-test-skip-no-tty.patch
-- system-test-with-system-binary.patch
-- rules
-- salsa-ci.yml
-- source
-- format
-- tests
-- control
-- upstream
-- metadata
-- signing-key.asc
-- watch
-- entr
-- entr.1
-- entr.c
-- entr.o
-- missing
-- compat.h
-- kqueue_inotify.c
-- strlcpy.c
-- sys
-- event.h
-- status.c
-- status.h
-- status.o
-- system_test.sh
-- entr-dbgsym_5.6-1_amd64.deb
-- entr_5.6-1.debian.tar.xz
-- entr_5.6-1.dsc
-- entr_5.6-1_amd64.buildinfo
-- entr_5.6-1_amd64.changes
-- entr_5.6-1_amd64.deb
-- entr_5.6.orig.tar.xzdebian/entr are essentially what goes into the resulting entr_5.6-1_amd64.deb package. Familiarizing yourself with the majority of the files in the original upstream source as well as all the resulting build artifacts is time consuming, but it is a necessary investment to get high-quality Debian packages.
There are also tools such as Debcraft that automate generating the build artifacts in separate output directories for each build, thus making it easy to compare the changes to correlate what change in the Debian packaging led to what change in the resulting build artifacts.
debian/watch, debian/upstream/signing-key.asc, and debian/gbp.conf need to be present with the correct options. In the gbp.conf file, ensure you have the correct options based on:
pristine-tar = True.upstream-signatures = on.upstream-vcs-tag = %(version%~%.)s.gbp import-orig with the current version explicitly defined:
$ gbp import-orig --uscan --upstream-version 5.6
gbp:info: Launching uscan...
gpgv: Signature made 7. Aug 2024 07.43.27 PDT
gpgv: using RSA key 519151D83E83D40A232B4D615C418B8631BC7C26
gpgv: Good signature from "Eric Radman <ericshane@eradman.com>"
gbp:info: Using uscan downloaded tarball ../entr_5.6.orig.tar.gz
gbp:info: Importing '../entr_5.6.orig.tar.gz' to branch 'upstream/latest'...
gbp:info: Source package is entr
gbp:info: Upstream version is 5.6
gbp:info: Replacing upstream source on 'debian/latest'
gbp:info: Running Postimport hook
gbp:info: Successfully imported version 5.6 of ../entr_5.6.orig.tar.gzpristine-tar branch, and store the tarball delta on it. This command will also attempt to create the tag upstream/5.6 on the upstream/latest branch.
git fetch upstreamvcs; gbp import-orig --uscan, which fetches the upstream git tags, checks for new upstream tarballs, and automatically downloads, verifies, and imports the new version. See the galera-4-demo example in the Debian source packages in git explained post as a demo you can try running yourself and examine in detail.
You can also try running gbp import-orig --uscan without specifying a version. It would fetch it, as it will notice there is now Entr version 5.7 available, and import it.
gbp buildpackage, which will do a more comprehensive build.
gbp buildpackage -uc -usgit-buildpackage build also includes running Lintian to find potential Debian policy violations in the sources or in the resulting .deb binary packages. Many Debian Developers run lintian -EviIL +pedantic after every build to check that there are no new nags, and to validate that changes intended to previous Lintian nags were correct.
debian/latest branch to another name, for example next/debian/latest, and open a Merge Request that targets the debian/latest branch on your Salsa fork, which still has only the unmodified upstream files.
If you have followed the workflow in this post so far, you can simply run:
git checkout -b next/debian/latestgit push --set-upstream origin next/debian/latestnext/debian/latest, rebase, force push, and request re-review as many times as you want.
While at it, make sure the Settings > CI/CD page has under CI/CD configuration file the value debian/salsa-ci.yml so that the CI can run and give you immediate automated feedback.
For an example of an initial packaging Merge Request, see https://salsa.debian.org/otto/entr-demo/-/merge_requests/1.
debian/patches), and can also easily be submitted upstream as any regular git commit (and rebased and resubmitted many times over).
First, decide if you want to work out of the upstream development branch and later cherry-pick to the Debian packaging branch, or work out of the Debian packaging branch and cherry-pick to an upstream branch.
The example below starts from the upstream development branch and then cherry-picks the commit into the git-buildpackage patch queue:
git checkout -b bugfix-branch master
nano entr.c
make
./entr # verify change works as expected
git commit -a -m "Commit title" -m "Commit body"
git push # submit upstream
gbp pq import --force --time-machine=10
git cherry-pick <commit id>
git commit --amend # extend commit message with DEP-3 metadata
gbp buildpackage -uc -us -b
./entr # verify change works as expected
gbp pq export --drop --commit
git commit --amend # Write commit message along lines "Add patch to .."gbp pq import --force --time-machine=10
nano entr.c
git commit -a -m "Commit title" -m "Commit body"
gbp buildpackage -uc -us -b
./entr # verify change works as expected
gbp pq export --drop --commit
git commit --amend # Write commit message along lines "Add patch to .."
git checkout -b bugfix-branch master
git cherry-pick <commit id>
git commit --amend # prepare commit message for upstream submission
git push # submit upstreamgbp pq import --force --time-machine=10
gbp pq export --drop --commit%% init: 'gitGraph': 'mainBranchName': 'debian/latest' %% gitGraph checkout debian/latest commit id: "Initial packaging" branch patch-queue/debian/latest checkout patch-queue/debian/latest commit id: "Delete debian/patches/..." commit id: "Patch 1 title" commit id: "Patch 2 title" commit id: "Patch 3 title"These can be run at any time, regardless if any
debian/patches existed prior, or if existing patches applied cleanly or not, or if there were old patch queue branches around. Note that the extra -b in gbp buildpackage -uc -us -b instructs to build only binary packages, avoiding any nags from dpkg-source that there are modifications in the upstream sources while building in the patches-applied mode.
dh_make --python option for Python support directly in dh_make itself. The list is not complete and many more tools exist. For some languages, there are even competing options, such as for Go there is in addition to dh-make-golang also Gophian.
When learning Debian packaging, there is no need to learn these tools upfront. Being aware that they exist is enough, and one can learn them only if and when one starts to package a project in a new programming language.
gbp buildpackage on the Entr packaging repository above will result in several files:
entr_5.6-1_amd64.changes
entr_5.6-1_amd64.deb
entr_5.6-1.debian.tar.xz
entr_5.6-1.dsc
entr_5.6.orig.tar.gz
entr_5.6.orig.tar.gz.ascentr_5.6-1_amd64.deb is the binary package, which can be installed on a Debian/Ubuntu system. The rest of the files constitute the source package. To do a source-only build, run gbp buildpackage -S and note the files produced:
entr_5.6-1_source.changes
entr_5.6-1.debian.tar.xz
entr_5.6-1.dsc
entr_5.6.orig.tar.gz
entr_5.6.orig.tar.gz.asc.deb for amd64, or any architecture that the package supports. It is important to grasp that the Debian source package is the preferred form to be able to build the binary packages on various Debian build systems, and the Debian source package is not the same thing as the Debian packaging git repository contents.
flowchart LR git[Git repository<br>branch debian/latest] --> gbp buildpackage -S src[Source Package<br>.dsc + .tar.xz] src --> dpkg-buildpackage bin[Binary Packages<br>.deb]If the package is large and complex, the build could result in multiple binary packages. One set of package definition files in
debian/ will however only ever result in a single source package.
Files-Excluded lists in the debian/copyright file
Some upstream projects may include binary files in their release, or other undesirable content that needs to be omitted from the source package in Debian. The easiest way to filter them out is by adding to the debian/copyright file a Files-Excluded field listing the undesired files. The debian/copyright file is read by uscan, which will repackage the upstream sources on-the-fly when importing new upstream releases.
For a real-life example, see the debian/copyright files in the Godot package that lists:
Files-Excluded: platform/android/java/gradle/wrapper/gradle-wrapper.jar+ds to signify that it is not the true original upstream source but has been modified by Debian:
godot_4.3+ds.orig.tar.xz
godot_4.3+ds-1_amd64.debdebian/latest branch on a clone of the upstream git repository as the starting point for the Debian packaging, but one must revert the traditional way of starting from an upstream release tarball with gbp import-orig package-1.0.tar.gz.
.deb packaging format and the tooling to work with it have evolved several generations. In the past 10 years, more and more Debian Developers have converged on certain core practices evidenced by https://trends.debian.net/, but there is still a lot of variance in workflows even for identical tasks. Hopefully, you find this post useful in giving practical guidance on how exactly to do the most common things when packaging software for Debian.
Happy packaging!
+/- on the keyboard, mouse wheel,
gesture) works.
End-to-end, the major development for this release was done over
around two weeks, which is pretty short: I extensively used Claude
Sonnet and Grok to unblock myself. Not to write code per se - although
there is code written 1:1 by LLMs, but most of the code is weirdly
wrong, and I have to either correct it or just use it as a starter and
rewrite most of it. But to discuss and unblock, and learn about new
things, the current LLMs are very good at.
And yet, sometimes even what they re good at, fails hard. I asked for
ideas to simplify a piece of code, and it went nowhere, even if there
were significant rewrite possibilities. I spent the brain cycles on
it, reverse engineered my own code, then simplified. I ll have to
write a separate blog post on this
In any case, this (zooming) was the last major feature I was
missing. There are image viewer libraries, but most of them slow,
compared to the bare-bones (well, now not so much anymore) viewer that
I use as main viewer. From now on, it will me minor incremental
features, mostly around Exif management/handling, etc. Or, well,
internal cleanups: extend test coverage, remove use of JQuery in the
frontend, etc., there are tons of things to do.
Fun fact: I managed to discover a Safari iOS bug. Or at least I think
it s a bug, so reported
it and curious
what ll come out of it.
Finally, I still couldn t fix the GitHub actions bug where the git
describe doesn t see the just pushed tag, sigh, so the demo site still
lists Corydalis v2024.12.0-133-g00edf63 as the version .
In this post, I demonstrate the optimal workflow for creating new Debian packages in 2025, preserving the upstream git history. The motivation for this is to lower the barrier for sharing improvements to and from upstream, and to improve software provenance and supply-chain security by making it easy to inspect every change at any level using standard git tooling.
Key elements of this workflow include:
git-buildpackage commands, with all package-specific options in gbp.conf.Files-Excluded in the debian/copyright file to filter out unwanted files in Debian.dh_make to create the initial Debian packaging.mkdir debian-entr
cd debian-entr
git clone --origin upstreamvcs --branch master \
--single-branch https://github.com/eradman/entr.gitgit clone lay the foundation for the Debian packaging git repository structure where the upstream git remote name is upstreamvcs. Only the upstream main branch is tracked to avoid cluttering git history with upstream development branches that are irrelevant for packaging in Debian.
Next, enter the git repository directory and list the git tags. Pick the latest upstream release tag as the commit to start the branch upstream/latest. This latest refers to the upstream release, not the upstream development branch. Immediately after, branch off the debian/latest branch, which will have the actual Debian packaging files in the debian/ subdirectory.
cd entr
git tag # shows the latest upstream release tag was '5.6'
git checkout -b upstream/latest 5.6
git checkout -b debian/latest%% init: 'gitGraph': 'mainBranchName': 'master' %% gitGraph: checkout master commit id: "Upstream 5.6 release" tag: "5.6" branch upstream/latest checkout upstream/latest commit id: "New upstream version 5.6" tag: "upstream/5.6" branch debian/latest checkout debian/latest commit id: "Initial Debian packaging" commit id: "Additional change 1" commit id: "Additional change 2" commit id: "Additional change 3"At this point, the repository is structured according to DEP-14 conventions, ensuring a clear separation between upstream and Debian packaging changes, but there are no Debian changes yet. Next, add the Salsa repository as a new remote which called
origin, the same as the default remote name in git.
git remote add origin git@salsa.debian.org:otto/entr-demo.git
git push --set-upstream origin debian/latestdebian/latest branch, which does not yet have any debian/ directory.
cd ..
podman run --interactive --tty --rm --shm-size=1G --cap-add SYS_PTRACE \
--env='DEB*' --volume=$PWD:/tmp/test --workdir=/tmp/test debian:sid bash--volume parameter will loop-mount the current directory inside the container. Thus all files created and modified are on the host system, and will persist after the container shuts down.
Once inside the container, install the basic dependencies:
apt update -q && apt install -q --yes git-buildpackage dpkg-dev dh-makedebian/ files with dh-make
To create the files needed for the actual Debian packaging, use dh_make:
# dh_make --packagename entr_5.6 --single --createorig
Maintainer Name : Otto Kek l inen
Email-Address : otto@debian.org
Date : Sat, 15 Feb 2025 01:17:51 +0000
Package Name : entr
Version : 5.6
License : blank
Package Type : single
Are the details correct? [Y/n/q]
Done. Please edit the files in the debian/ subdirectory now.dh_make works, the package name and version need to be written as a single underscore separated string. In this case, you should choose --single to specify that the package type is a single binary package. Other options would be --library for library packages (see libgda5 sources as an example) or --indep (see dns-root-data sources as an example). The --createorig will create a mock upstream release tarball (entr_5.6.orig.tar.xz) from the current release directory, which is necessary due to historical reasons and how dh_make worked before git repositories became common and Debian source packages were based off upstream release tarballs (e.g. *.tar.gz).
At this stage, a debian/ directory has been created with template files, and you can start modifying the files and iterating towards actual working packaging.
git add debian/
git commit -a -m "Initial Debian packaging"dh_make would be:
-- entr
-- LICENSE
-- Makefile.bsd
-- Makefile.linux
-- Makefile.linux-compat
-- Makefile.macos
-- NEWS
-- README.md
-- configure
-- data.h
-- debian
-- README.Debian
-- README.source
-- changelog
-- control
-- copyright
-- gbp.conf
-- entr-docs.docs
-- entr.cron.d.ex
-- entr.doc-base.ex
-- manpage.1.ex
-- manpage.md.ex
-- manpage.sgml.ex
-- manpage.xml.ex
-- postinst.ex
-- postrm.ex
-- preinst.ex
-- prerm.ex
-- rules
-- salsa-ci.yml.ex
-- source
-- format
-- upstream
-- metadata.ex
-- watch.ex
-- entr.1
-- entr.c
-- missing
-- compat.h
-- kqueue_inotify.c
-- strlcpy.c
-- sys
-- event.h
-- status.c
-- status.h
-- system_test.sh
-- entr_5.6.orig.tar.xzdebian/ directory are:
changelog,control,copyright,rules..ex are example files that won t have any effect until their content is adjusted and the suffix removed.
For detailed explanations of the purpose of each file in the debian/ subdirectory, see the following resources:
wrap-and-sort -vast or debputy reformat --style=black.
pcre2posix.h cannot be found or that libcre2-posix.so is missing, you can use these commands:
$ apt install -q --yes apt-file && apt-file update
$ apt-file search pcre2posix.h
libpcre2-dev: /usr/include/pcre2posix.h
$ apt-file search libpcre2-posix.so
libpcre2-dev: /usr/lib/x86_64-linux-gnu/libpcre2-posix.so
libpcre2-posix3: /usr/lib/x86_64-linux-gnu/libpcre2-posix.so.3
libpcre2-posix3: /usr/lib/x86_64-linux-gnu/libpcre2-posix.so.3.0.6debian/control should be extended to define a Build-Depends: libpcre2-dev relationship.
There is also dpkg-depcheck that uses strace to trace the files the build process tries to access, and lists what Debian packages those files belong to. Example usage:
dpkg-depcheck -b debian/rules builddebian/, test the build by running dpkg-buildpackage inside the container:
dpkg-buildpackage -uc -us -b-uc -us will skip signing the resulting Debian source package and other build artifacts. The -b option will skip creating a source package and only build the (binary) *.deb packages.
The output is very verbose and gives a large amount of context about what is happening during the build to make debugging build failures easier. In the build log of entr you will see for example the line dh binary --buildsystem=makefile. This and other dh commands can also be run manually if there is a need to quickly repeat only a part of the build while debugging build failures.
To see what files were generated or modified by the build simply run git status --ignored:
$ git status --ignored
On branch debian/latest
Untracked files:
(use "git add <file>..." to include in what will be committed)
debian/debhelper-build-stamp
debian/entr.debhelper.log
debian/entr.substvars
debian/files
Ignored files:
(use "git add -f <file>..." to include in what will be committed)
Makefile
compat.c
compat.o
debian/.debhelper/
debian/entr/
entr
entr.o
status.odpkg-buildpackage will include running the command dh clean, which assuming it is configured correctly in the debian/rules file will reset the source directory to the original pristine state. The same can of course also be done with regular git commands git reset --hard; git clean -fdx. To avoid accidentally committing unnecessary build artifacts in git, a debian/.gitignore can be useful and it would typically include all four files listed as untracked above.
After a successful build you would have the following files:
-- entr
-- LICENSE
-- Makefile -> Makefile.linux
-- Makefile.bsd
-- Makefile.linux
-- Makefile.linux-compat
-- Makefile.macos
-- NEWS
-- README.md
-- compat.c
-- compat.o
-- configure
-- data.h
-- debian
-- README.source.md
-- changelog
-- control
-- copyright
-- debhelper-build-stamp
-- docs
-- entr
-- DEBIAN
-- control
-- md5sums
-- usr
-- bin
-- entr
-- share
-- doc
-- entr
-- NEWS.gz
-- README.md
-- changelog.Debian.gz
-- copyright
-- man
-- man1
-- entr.1.gz
-- entr.debhelper.log
-- entr.substvars
-- files
-- gbp.conf
-- patches
-- PR149-expand-aliases-in-system-test-script.patch
-- series
-- system-test-skip-no-tty.patch
-- system-test-with-system-binary.patch
-- rules
-- salsa-ci.yml
-- source
-- format
-- tests
-- control
-- upstream
-- metadata
-- signing-key.asc
-- watch
-- entr
-- entr.1
-- entr.c
-- entr.o
-- missing
-- compat.h
-- kqueue_inotify.c
-- strlcpy.c
-- sys
-- event.h
-- status.c
-- status.h
-- status.o
-- system_test.sh
-- entr-dbgsym_5.6-1_amd64.deb
-- entr_5.6-1.debian.tar.xz
-- entr_5.6-1.dsc
-- entr_5.6-1_amd64.buildinfo
-- entr_5.6-1_amd64.changes
-- entr_5.6-1_amd64.deb
-- entr_5.6.orig.tar.xzdebian/entr are essentially what goes into the resulting entr_5.6-1_amd64.deb package. Familiarizing yourself with the majority of the files in the original upstream source as well as all the resulting build artifacts is time consuming, but it is a necessary investment to get high-quality Debian packages.
There are also tools such as Debcraft that automate generating the build artifacts in separate output directories for each build, thus making it easy to compare the changes to correlate what change in the Debian packaging led to what change in the resulting build artifacts.
debian/watch, debian/upstream/signing-key.asc, and debian/gbp.conf need to be present with the correct options. In the gbp.conf file, ensure you have the correct options based on:
pristine-tar = True.upstream-signatures = on.upstream-vcs-tag = %(version%~%.)s.gbp import-orig with the current version explicitly defined:
$ gbp import-orig --uscan --upstream-version 5.6
gbp:info: Launching uscan...
gpgv: Signature made 7. Aug 2024 07.43.27 PDT
gpgv: using RSA key 519151D83E83D40A232B4D615C418B8631BC7C26
gpgv: Good signature from "Eric Radman <ericshane@eradman.com>"
gbp:info: Using uscan downloaded tarball ../entr_5.6.orig.tar.gz
gbp:info: Importing '../entr_5.6.orig.tar.gz' to branch 'upstream/latest'...
gbp:info: Source package is entr
gbp:info: Upstream version is 5.6
gbp:info: Replacing upstream source on 'debian/latest'
gbp:info: Running Postimport hook
gbp:info: Successfully imported version 5.6 of ../entr_5.6.orig.tar.gzpristine-tar branch, and store the tarball delta on it. This command will also attempt to create the tag upstream/5.6 on the upstream/latest branch.
git fetch upstreamvcs; gbp import-orig --uscan, which fetches the upstream git tags, checks for new upstream tarballs, and automatically downloads, verifies, and imports the new version. See the galera-4-demo example in the Debian source packages in git explained post as a demo you can try running yourself and examine in detail.
You can also try running gbp import-orig --uscan without specifying a version. It would fetch it, as it will notice there is now Entr version 5.7 available, and import it.
gbp buildpackage, which will do a more comprehensive build.
gbp buildpackage -uc -usgit-buildpackage build also includes running Lintian to find potential Debian policy violations in the sources or in the resulting .deb binary packages. Many Debian Developers run lintian -EviIL +pedantic after every build to check that there are no new nags, and to validate that changes intended to previous Lintian nags were correct.
debian/latest branch to another name, for example next/debian/latest, and open a Merge Request that targets the debian/latest branch on your Salsa fork, which still has only the unmodified upstream files.
If you have followed the workflow in this post so far, you can simply run:
git checkout -b next/debian/latestgit push --set-upstream origin next/debian/latestnext/debian/latest, rebase, force push, and request re-review as many times as you want.
While at it, make sure the Settings > CI/CD page has under CI/CD configuration file the value debian/salsa-ci.yml so that the CI can run and give you immediate automated feedback.
For an example of an initial packaging Merge Request, see https://salsa.debian.org/otto/entr-demo/-/merge_requests/1.
debian/patches), and can also easily be submitted upstream as any regular git commit (and rebased and resubmitted many times over).
First, decide if you want to work out of the upstream development branch and later cherry-pick to the Debian packaging branch, or work out of the Debian packaging branch and cherry-pick to an upstream branch.
The example below starts from the upstream development branch and then cherry-picks the commit into the git-buildpackage patch queue:
git checkout -b bugfix-branch master
nano entr.c
make
./entr # verify change works as expected
git commit -a -m "Commit title" -m "Commit body"
git push # submit upstream
gbp pq import --force --time-machine=10
git cherry-pick <commit id>
git commit --amend # extend commit message with DEP-3 metadata
gbp buildpackage -uc -us -b
./entr # verify change works as expected
gbp pq export --drop --commit
git commit --amend # Write commit message along lines "Add patch to .."gbp pq import --force --time-machine=10
nano entr.c
git commit -a -m "Commit title" -m "Commit body"
gbp buildpackage -uc -us -b
./entr # verify change works as expected
gbp pq export --drop --commit
git commit --amend # Write commit message along lines "Add patch to .."
git checkout -b bugfix-branch master
git cherry-pick <commit id>
git commit --amend # prepare commit message for upstream submission
git push # submit upstreamgbp pq import --force --time-machine=10
gbp pq export --drop --commit%% init: 'gitGraph': 'mainBranchName': 'debian/latest' %% gitGraph checkout debian/latest commit id: "Initial packaging" branch patch-queue/debian/latest checkout patch-queue/debian/latest commit id: "Delete debian/patches/..." commit id: "Patch 1 title" commit id: "Patch 2 title" commit id: "Patch 3 title"These can be run at any time, regardless if any
debian/patches existed prior, or if existing patches applied cleanly or not, or if there were old patch queue branches around. Note that the extra -b in gbp buildpackage -uc -us -b instructs to build only binary packages, avoiding any nags from dpkg-source that there are modifications in the upstream sources while building in the patches-applied mode.
dh_make --python option for Python support directly in dh_make itself. The list is not complete and many more tools exist. For some languages, there are even competing options, such as for Go there is in addition to dh-make-golang also Gophian.
When learning Debian packaging, there is no need to learn these tools upfront. Being aware that they exist is enough, and one can learn them only if and when one starts to package a project in a new programming language.
gbp buildpackage on the Entr packaging repository above will result in several files:
entr_5.6-1_amd64.changes
entr_5.6-1_amd64.deb
entr_5.6-1.debian.tar.xz
entr_5.6-1.dsc
entr_5.6.orig.tar.gz
entr_5.6.orig.tar.gz.ascentr_5.6-1_amd64.deb is the binary package, which can be installed on a Debian/Ubuntu system. The rest of the files constitute the source package. To do a source-only build, run gbp buildpackage -S and note the files produced:
entr_5.6-1_source.changes
entr_5.6-1.debian.tar.xz
entr_5.6-1.dsc
entr_5.6.orig.tar.gz
entr_5.6.orig.tar.gz.asc.deb for amd64, or any architecture that the package supports. It is important to grasp that the Debian source package is the preferred form to be able to build the binary packages on various Debian build systems, and the Debian source package is not the same thing as the Debian packaging git repository contents.
flowchart LR git[Git repository<br>branch debian/latest] --> gbp buildpackage -S src[Source Package<br>.dsc + .tar.xz] src --> dpkg-buildpackage bin[Binary Packages<br>.deb]If the package is large and complex, the build could result in multiple binary packages. One set of package definition files in
debian/ will however only ever result in a single source package.
Files-Excluded lists in the debian/copyright file
Some upstream projects may include binary files in their release, or other undesirable content that needs to be omitted from the source package in Debian. The easiest way to filter them out is by adding to the debian/copyright file a Files-Excluded field listing the undesired files. The debian/copyright file is read by uscan, which will repackage the upstream sources on-the-fly when importing new upstream releases.
For a real-life example, see the debian/copyright files in the Godot package that lists:
Files-Excluded: platform/android/java/gradle/wrapper/gradle-wrapper.jar+ds to signify that it is not the true original upstream source but has been modified by Debian:
godot_4.3+ds.orig.tar.xz
godot_4.3+ds-1_amd64.debdebian/latest branch on a clone of the upstream git repository as the starting point for the Debian packaging, but one must revert the traditional way of starting from an upstream release tarball with gbp import-orig package-1.0.tar.gz.
.deb packaging format and the tooling to work with it have evolved several generations. In the past 10 years, more and more Debian Developers have converged on certain core practices evidenced by https://trends.debian.net/, but there is still a lot of variance in workflows even for identical tasks. Hopefully, you find this post useful in giving practical guidance on how exactly to do the most common things when packaging software for Debian.
Happy packaging!
After cartridge pleating, the next fabric manipulation technique I
wanted to try was smocking, of the honeycombing variety, on a shirt.
My current go-to pattern for shirts is the 1880 menswear one
I have on my website: I love the fact that most of the fabric is still
cut as big rectangles, but the shaped yoke and armscyes make it
significantly more comfortable than the earlier style where most of the
shaping at the neck was done with gathers into a straight collar.
In my stash I had a cut of purple-blue hopefully cotton [#cotton] I had
bought for a cheap price and used for my first attempt at an
historically accurate pirate / vampire shirt that has now become by
official summer vaccine jab / blood test shirt (because it has the long
sleeves I need, but they are pretty easy to roll up to give access to my
arm.
That shirt tends to get out of the washing machine pretty wearable even
without ironing, which made me think it could be a good fabric for
something that may be somewhat hard to iron (but also made me
suspicious about the actual composition of the fabric, even if it feels
nice enough even when worn in the summer).
Of course I wanted some honeycombing on the front, but I was afraid that
the slit in the middle of it would interfere with the honeycombing and
gape, so I decided to have the shirt open in an horizontal line at the
yoke.
I added instructions to the pattern page
for how I changed the opening in the front, basically it involved
finishing the front edge of the yoke, and sewing the honeycombed yoke to
a piece of tape with snaps.
Another change from the pattern is that I used plain rectangles for the
sleeves, and a square gusset, rather than the new style tapered sleeve ,
because I wanted to have more fabric to gather at the wrist. I did the
side and sleeve seams with a hem + whipstitch method rather than a
felled seam, which may have helped, but the sleeves went into the
fitted armscyes with no issue.
I think that if (yeah, right. when) I ll make another sleeve in this
style I ll sew it into the side seam starting 2-3 cm lower than the
place I ve marked on the pattern for the original sleeve.
I also used a row of honeycombing on the back and two on the upper part
of the sleeves, instead of the gathering, and of course some rows to
gather the cuffs.
The honeycombing on the back was a bit too far away from the edge, so
it s a bit of an odd combination of honeycombing and pleating that I
don t hate, but don t love either. It s on the back, so I don t mind. On
the sleeves I ve done the honeycombing closer to the edge and I ve
decided to sew the sleeve as if it was a cartridge pleated sleeve, and
that worked better.
Because circumstances are still making access to my sewing machine
more of a hassle than I d want it to be, this was completely sewn by
hand, and at a bit more than a month I have to admit that near the end
it felt like it had been taken forever. I m not sure whether it was the
actual sewing being slow, some interruptions that happened when I had
little time to work on it, or the fact that I ve just gone through a
time when my brain kept throwing new projects at me, and I kept thinking
of how to make those. Thanks brain.
Even when on a hurry to finish it, however, it was still enjoyable
sewing, and I think I ll want to do more honeycombing in the future.
Anyway, it s done! And it s going straight into my daily garment
rotation, because the weather is getting hot, and that means it s
definitely shirt time.
The following contributors got their Debian Developer accounts in the last two
months:
A # install request for A
B # manually installed, keep it
A depends on: conflicts-B C
A on a system with B installed installed C, as it was not allowed to
install the conflicts-B package since B is installed.
However, I also introduced a mode to allow removing manually installed packages, and that s
where it broke down, now instead of B being a fact, our clauses looked like:
A # install request for A
A depends on: conflicts-B C
Optional: B # try to keep B installed
conflicts-B and removed B; the steps the solver takes are:
A is a fact, mark itA depends on: conflicts-B C is the strongest clause, try to install conflicts-Bconflicts-B conflicts with B, so we mark not BOptional: B is reached, but not satisfiable, ignore it because it s optional.for fact in facts:
enqueue(fact)
if not propagate():
return False
for optionalLiteral in optionalLiterals:
registerClause(SoftClause([optionalLiteral]))
if assume(optionalLiteral) and not propagate():
undo()
while True:
if not propagate():
if not backtrack():
return False
elif <all clauses are satisfied>:
return True
elif it := find("best unassigned literal satisfying a hard clause"):
assume(it)
elif it := find("best literal satisfying a soft clause"):
assume(it)
A,B,C and B is not possible, we will have also undone C. But since
C is also enqueued as a soft clause, we will then later find it again:
A: State=[Assume(A)], Clauses=[SoftClause([A])]B: State=[Assume(A),Assume(B)], Clauses=[SoftClause([A]),SoftClause([B])]C: State=[Assume(A),Assume(B),Assume(C)], Clauses=[SoftClause([A]),SoftClause([B]),SoftClause([C])]not C: State=[Assume(A),Assume(B),not(C)]not B: State=[Assume(A),not(B)] C is no longer assumed eitherC as it satisfies SoftClause([C]) as next best literal: State=[Assume(A),not(B),Assume(C)]A, not B, and C.Optional: A
Optional: B
Optional: C
B Conflicts with A
C Conflicts with A
A If we assume A first, we are unable to satisfy B or C. B,C If we assume either B or C first, A is unsat.2**n times for n soft clauses, whereas our heuristic only needs n runs.
For dependency solving, it seems we do not seem have a strong need for a global maximum:
There are various other preferences between our literals, say priorities;
and empirically, from evaluating hundreds of regressions without the initial assumptions,
I can say that the assumptions do fix those cases and the result is correct.
Further improvements exist, though, and we can look into them if they are needed, such as:
For a while, the strongSwan Debian package had an autopktest.
The initial version was proposed by Christian Ehrhardt in 2016
(presumably especially for downstream use in Ubuntu) and updated in
2019, but since then not much at least in Debian.
With the metapackage dependencies update in 6.0.0-1 I had to
tune a bit the tests dependencies so they wouldn't totally fail,
and I noticed the amd64 tests were failing since basically the
beginning (the other architectures would pass, but because the
tests wouldn't actually run at all since they rely on the
isolation-machine restriction which is
not available there.
So I tried to fix them, and it actually took me quite a while
because I wasn't able to run the tests locally easily and the salsa
CI doesn't have the isolation-machine
restriction either. And some tests would pass and not
other.
With some nice help from #debci, and using my newly received X13G5 I set
up an autopkgtest VM and started experimenting. The 6.0.0-4
autopkgtests were failing 19 times over 20 steps, but passing one
time. So it looked like a race condition, which we narrowed to the
fact that starting the daemons (using invoke-rc.d which calls systemctl) is asynchronous. So depending on the load
and maybe the machine, the tests would usually fail but sometime
pass.
There's no easy way to make the call synchronous, so as a
stopgap I added a small sleep 1 command and it fixed it for now.
Tada! strongSwan has now passing
autopkgtests in unstable (and testing) amd64. It's not entirely
satisfying but still.
Next steps would be to add tests for the new daemon using the
swanctl inteface, but that'll be for Forky (Trixie+1).
pflogsumm from /usr/sbin to /usr/bin!
There was not really a good reason to ever have it in sbin. It's neither a system binary,
nor statically linked (like in the very old days), or something that really only makes sense
to be used as root. Some out there likely have custom scripts which do not rely on an
adjusted PATH variable, those scripts require an update.
I have been a very happy user of my two SK-8845 keyboards (one at my
office, one at home) since I bought them, in 2018 and 2021
respectively. What are they, mind you?
)
The beautiful keyboard every Thinkpad owner knows and loves. And although I
no longer use my X230 laptop that was my workhorse for several years, my
fingers are spoiled.
So, both shift keys of my home keyboard have been getting flaky, and I
am basically sure it s a failure in the controller, as it does not feel to
be physical. It s time to revisit that seven year old
post
where I found the SK-8845.
This time, I decided to try my luck with something different. As a Emacs
user, everybody knows we ought to be happy with more and more keys. In
fact, I suppose many international people are now familiar with El
Eternauta, true? we Emacs users would be the natural ambassadors to deal
with the hand species:
So it kind-of sort-of made sense, when I saw a Toshiba-IBM keyboard
being sold for quite cheap (MX$400, just over US$20) to try my luck with
it:
This is quite an odd piece of hardware, built in 2013 according to its
label. At first I was unsure whether to buy it because of the weird
interface it had, but the vendor replied they would ship a (very long!) USB
cable with it, so
As expected, connecting it to Linux led to a swift, errorless recognition:
Within minutes of receiving the hardware, I had it hooked up and started
looking at the events it generated However the romance soon started to
wane. Some of the reasons:
middle
emulation enabled, but the buttons are separated it requires clicking
with both thumbs, which is unelegant, to say the least.
I remapped some of the spare keys to be mouse buttons 1 5, and it worked
for middle click, but not for scroll events. Maybe I could tweak it a bit
more but I didn t in the end.
When you learn to write, one of the major pieces is writing an introduction. You could say quite a bit about the formal process and the way formal writing is typically structured.That being said, I m not your typical writer. I didn t exactly plan to be in this spot, and honestly, it s just a hobby of mine. If you enjoy reading my posts, great. I appreciate it.My entire point, from the very beginning of this week, has been to bootstrap my own platform, on my own two feet. As you all know, rumors were going around, and I felt as if I wasn t in that great of a position to go out and say everything that I ve said, in one long post. I ve needed to break it apart, and work through some of my own notes again. Prove myself, rather than asking for it to be handed to me. Keep people guessing on some elements, to let the people who have been doing wrong firmly prove themselves. At least twelve people at this point have sent me undeniable proof. I don t want to do anything with it. I want to move on, and I want to write about technology, and other things I actually enjoy writing about.I really don t enjoy conflict, or writing about it, at all. I just know how to defend myself if I need to. If you think I actively want to make everyone mad for no good reason, you re honestly fooling yourself.I already know that I m not going to agree with everything I write in a few years, or maybe even weeks. But I ll hold myself to the same standard I hold everyone else. If you say something and a few years pass, I m not going to assume you still have the same opinion. I ll give you the opportunity to correct it. I d ask you lend me the same courtesy.I do this because I enjoy it, not out of anger, sadness, or anything like that. A number of people have approached me now simply asking why I m doing what I m doing. I planned to write this blog post at the very end all along. I just haven t revealed the plans before publishing. [I wrote the outline for this more than a day ago.]My entire point here is to give the common person a voice. I know exactly what it s like to start from nothing, and work your way up to a comfortable spot. I didn t only do it once, I did it twice. This is my third time. I genuinely don t appreciate it when people silence other people s voices just because they don t like them. I wasn t raised that way, and that s not how I run my own projects. In fact, I d say that if you silence opinions or values that don t exactly match yours, you re missing out on the variety of life.You can lead a horse to water, but you can t make them drink. If you still think there are issues on my end, you re being misinformed. Plain and simple. I m not going to spend any more time on it, I actually want to start what I ve always wanted to do for years, just never had the opportunity to.This is my last post for the week. I feel like I ve bootstrapped enough where next week I can focus on another topic, as originally planned.Thanks for reading. I appreciate your support. Talk to you on Monday. If you have topic suggestions, feel free to leave them in the comments. Feel free to leave your hate mail too, so I know where I m at.If you read Piaget, you know that silence is concerning with respect to socialization. I just took a look at the view count for the first time, and I m already up to more than 2k views. In the first week. Without actually digging into the content I want to write about, yet.I don t mean to say that to brag, I m just telling you for a fact that I m not ranting into thin air. I m not even ranting at all. In fact, every single one of my posts has been written either calmly or with happiness, including this one.My entire point is this: debate me on the merits of the subject, not on me as a person. If you don t like me, that s okay. Go play elsewhere.But, I m still going to keep writing. Next week, different metaphors.We re bootstrapped now.
Armadillo is a powerful
and expressive C++ template library for linear algebra and scientific
computing. It aims towards a good balance between speed and ease of use,
has a syntax deliberately close to Matlab, and is useful for algorithm
development directly in C++, or quick conversion of research code into
production environments. RcppArmadillo
integrates this library with the R environment and language and is
widely used by (currently) 1251 other packages on CRAN, downloaded 39.8 million
times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint
/ vignette) by Conrad and myself has been cited 628 times according
to Google Scholar.
Conrad released a minor
bugfix version yesterday which addresses corner cases with non-finite
values in sparse matrices. And despite conference traveling, I managed
to wrap this up and ship it to CRAN where it appeared yesterday.
The changes since the last CRAN
release are summarised below.
Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.Changes in RcppArmadillo version 14.4.3-1 (2025-05-21)
- Upgraded to Armadillo release 14.4.3 (Filtered Espresso)
- Fix for several corner cases involving handling of non-finite elements by sparse matrices
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.
I haven t had time to blog, but today is my birthday and taking some time to myself!This release came with a major bugfix. As it turns out our applications were very crashy on non-KDE platforms including Ubuntu proper. Unfortunately, for years, and I didn t know. Developers were closing the bug reports as invalid because users couldn t provide a stacktrace. I have now convinced most developers to assign snap bugs to the Snap platform so I at least get a chance to try and fix them. So with that said, if you tried our snaps in the past and gave up in frustration, please do try them again! I also spent some time cleaning up our snaps to only have current releases in the store, as rumor has it snapcrafters will be responsible for any security issues. With 200+ snaps I maintain, that is a lot of responsibility. We ll see if I can pull it off. First off, my members-only post is much happier. Members-only posts continue until open source Medium becomes available. Don t worry, if you write to me privately, I can give you a copy on request.Here are a few donuts for everyone:https://medium.com/media/48d02097292c207c14cfa0203f840bc2/hrefhttps://medium.com/media/092204ce4dd42849ab42c7dae9172c8a/hrefhttps://medium.com/media/28bd9e3206e39011fab17e7d7159c374/hrefGood.
Hey folks! Ope, you might need the Midwest Voice Translator on this one. Read this one in a heavy Midwest accent, and tell your folks I
Don t knock the fence down before you know why it s up. I repeat this phrase over and over again, yet the (metaphorical) Homeowner s Association still decides my fence is the wrong color.Well, now you get to know why the fence is up. If anyone s actually willing to challenge me on this level, I d welcome it.The four ideas I d like to discuss are this: quantum physics, Lutheranism, mental resilience, and psychology. I ve been studying these topics intensely for the past decade as a passion project. I m just going to let my thoughts flow, but I d like to hear other opinions on this.Can the mysteries of the mind, the subatomic world, and faith converge to reveal deeper truths?When it comes to self-taught knowledge on analysis, I m mostly learned on Freud, with some hints of Jung and Peterson. I ve read much of the original source material, and watched countless presentations on it. This all being said, I m both learned on Rothbard and Marx, so if there is a major flaw in the way of Freud is frowned upon, I d genuinely like to know so I can update my research and juxtapose the two schools of thought.Alongside this, although probably not directly relevant, I m learned on John Locke and transcendentalism. What I d like to focus on here is this the Id.The Id is the pleasure-seeking, instinctual part of the psyche. Jung further extends this into the idea of the shadow self, and Peterson maps the meanings of these texts into a combined work (at least in my rudimentary understanding).In my research, the Id represents the part of your psyche that deals with religious values. As an example, if you re an impulsive person, turning to a spiritual or religious outlet can be highly beneficial. I ve been using references from the foundational text of the Judaeo-Christian value system this entire time, feel free to re-read my other blog posts (instead of claiming they don t exist).Let s tie this into quantum physics. This is the part where I ll struggle most. I ve watched several movies about this, read several books, and even learned about it academically, but quantum physics is likely to be my weak spot here.I did some research, and here are the elements I m looking for: uncertainty principle, wave-particle duality, quantum entanglement, and the observer effect.I already know about the cat in the box. And the Cat in the Hat, for that matter. I know about wave-particle duality from an incredibly intelligent high school physics teacher of mine. I know about the uncertainty principle purely in a colloquial sense. The remaining element I need to wrap my head around is quantum entanglement, but it feels like I m almost there.These concepts do actually challenge the idea of pure free will. It s almost like we re coming full circle. Some theologians (including myself, if you can call me a self-taught one) do believe the idea of quantum indeterminacy can be a space where divine action may take place. You could also liken the unpredictable nature of the Id to quantum indeterminacy as well. These are ones to think about, because in all reality, they re subjective opinions. I do believe they re interconnected.In terms of Lutheranism, I ll be short on this one. Please do go read the full history behind Martin Luther and his turbulent relationship with Catholicism. I m not a Bible thumper, and I actually think this is the first time I ve mentioned religion publicly at all. This being said, now I m actually ready to defend the points on an academic level.The Id represents hidden psychological forces, quantum physics reveals subatomic mysteries, and Lutheranism emphasizes faith in the unseen God. Okay, so we have the baseline. Now, time for some mental resilience. When I think of mental resilience, the first people I think of are David Goggins and Jocko Willink. I ve also enjoyed Dr. Andrew Huberman s podcast.The idea there is simple if you understand exactly how to learn, you know your fundamentals well enough to draw them and explain them vividly on a whiteboard, and you can make it a habit, at that point you re ready to work on your mental resilience. Little by little, gradually, how far can you push the bar towards the ceiling?There s obviously limits. People sometimes get scared when I mention mental resilience, but obviously that s a bit of a catch 22. There are plenty of satirical videos out there, and of course, I don t believe in Goggins or Jocko wholeheartedly. They re just tools in the toolbox when times get tough.I wish you all well, and I hope this gets you thinking about those people who just insist there is no God or higher being, and think you re stupid for believing there is one. Those people obviously haven t read analysis, in my own opinion.Have a great night!
Edit: for the people calling this unhinged, you don t have the full context. I know it s not a good look. Just stop and think for a second, though.I d like to start this post by saying that I am indeed well. I ve thought so from the very beginning, and it s been confirmed by professionals as such. That being said, there is still this perception that people are still believing the other person that needs help.See, when you re deeply involved in this space for ten years and start a blog to share all the cool things you ve learned, you don t expect people to spread the rumor that you re crazy. And you especially don t expect them to resort to a legal bluff and then brag about it in a private IRC channel (yes, I have the proof.)I d like my apology letter, please. And I d like you all to stop using Orwellian tactics to silence me by spreading those rumors, please. I know the source of the rumor-mill, and it s being dealt with. There has been progress, but one thing hasn t happened yet I haven t received my apology letter. I ll even volunteer, out of my own good spirit, to remove this post and all BwE parts of my first post if you send me a full apology letter in the next 24 hours. I d do that, just to get you to open your eyes and smile.Silencing people, or asking them to remove parts of a post you don t like, is never okay. You could choose whether to publish it on your platform, sure, but you certainly don t get to pick and choose what I put in my personal blog posts.I am a United States citizen with a 1st amendment right that shall be respected. I ve also studied and enjoyed writing for years. I m sick and tired of the back and forth on this. I ve wanted to move on and you are actively not letting me.I have the full IRC logs. Several other people have attested they also have them. What would you like to do next?I m not sure about you, but I m sitting here eating a donut. This isn t harrassment, this is self defense. At some point, you have to get sick and tired of issues happening, and you have to stand up for yourself, on your own footing.It isn t easy. I probably won t look back favorably on this post and thought process in a few years. That being said, it s necessary to defend myself on someone who has mistreated me personally on so many grave levels. You ll note I still haven t made the name public.They want to make you out to look like a loose cannon. They want to push your buttons and make you write a rant blog post telling you how much they hate them. I m not going to dignify that, because I know a specific electrician who wouldn t be happy if I had to write him a dissent.I m done. Don t defame me anymore.With donuts, A popular topic of public conversation in 2025 is balance. How do we balance budgets, how do we balance entities, and how do we balance perspectives? How do we balance the right of free expression with our ability to effectively convey a message?Here s another popular topic of conversation AI. What is it? What does it do?I m going to give you some resources, as someone who first learned the inner workings of AI about ten years ago.I ll start with the presentation I gave in middle school. Our objective was to give a presentation on a topic of our choice, and we would be graded on our ability to give a presentation. Instead of talking about specific things or events, I talked about the broader idea of fully establishing an artificial form of intelligence.This is the video I used as a basis for that presentation:https://medium.com/media/21d2427a502b7c7cb669220e2e3478c8/hrefNot only did I explain exactly how this specific video game worked, it helped me understand machine learning and genetic algorithms. If I m recalling correctly, the actual title of my presentation had to do with genetic algorithms specifically.In the presentation, I specifically tied in Darwin s readings on evolution (of course, I had to keep it secular ), directly relating the information I learned about evolution in science class into a presentation about what would become AI. But Simon, the title of that video says Machine Learning. Do you have your glasses on?!? Yes, yes I do. It took me a few years to watch this space evolve, as I focused on other portions of the open source world. This changed when I attended SCaLE 21x. At that conference, the product manager for AI at Canonical (apologies if I m misquoting your exact title) gave a presentation on how she sees this space evolving. It s a must watch, in my opinion:https://medium.com/media/a13b2e46fc8acaa3bebf01a7f7bdeebb/hrefThis comprehensive presentation really covers the entire space, and does an excellent job at giving the whole picture.The short of it is this calling everything AI is inaccurate. Using AI for everything under the sun also isn t accurate. Speaking of the sun, it will get us if we don t find a sustainable way to get all that energy we ll need.I also read a paper on this issue, which I believe ties it together nicely. Published in June 2024, it s titled Situational Awareness The Decade Ahead and does an excellent job in predicting how this space will evolve. So far, it s been very accurate.The reason I m explaining this is fairly simple. In 2025, I still don t think many people have taken the time to dig into the content. From many conversations I ve heard, including one I took notes on in an entirely personal capacity, I m finding that not many people have a decent idea for where this space is going.It s been researched! :)If someone can provide a dissent for this view of the artificial intelligence space in the comments, I d be more than happy to hear it. Here s where I think this connects to the average person Many of the open source companies right now, without naming names, are focusing too much on the corporate benefits of AI. Yes, AI will be an incredibly useful tool for large organizations, and it will have a great benefit for how we conduct business over the course of the next decade. But do we have enough balance?Before you go all-in on AI, just do your research, please. Take a look at your options, and choose one that is correctly calibrated with the space as you see it.Lastly, when I talk about AI, I always bring up Orwell. I m a very firm, strong believer in free speech. AI must not be used to censor content, and the people who design your AI stack are very important. Look at which one of the options, as a company, enforces a diversity policy that is consistent with your values. The values of that company will carry over into its product. If you think I m wrong about this point, seriously, go read 1984 by George Orwell a few times over. You ll get the picture on what we re looking to avoid.In short, there s no need to over-complicate AI to those who don t understand it. Use the video game example. It s simple, and it works. Try using that same sentiment in your messaging, too. Appealing to both companies and individual users, together, should be important for open source companies, especially those with a large user base.I wish you all well. If you re getting to the end of this post and you re mad at me, sorry about that. Go re-read 1984 just one more time, please. ;)
Next.