Mailman 3 - Bit-dev - python.org

Next try to contact Germar
by c.buhtz＠posteo.jp June 9, 2026

June 9, 2026

Hello, just for information. Today I tried again to contact the former maintainer Germar on his regular email address. The mayor problem is that he is the only one "Owner" of the "bit-team". I am not able to manage several things, e.g. add other owners as backup, blocking AI-slop accounts to the project, manage TravisCI stuff, much more... Finally forking is technical an option, but won't solve all problems. And I also don't want to go this path. Keep you informed Christian Buhtz

1 0

New mount subsystem is ready to test
by c.buhtz＠posteo.jp June 3, 2026

June 3, 2026

Hey folks, the new mount subsystem is ready for further testing. It is not yet merged into the "dev" branch but is living in its own Pull Request on branch "feat/sshgocryptfs". Detailed installation and testing instructions can be found in this comment in the PR itself: <https://github.com/bit-team/backintime/pull/2449#issuecomment-4534635028> ☢️ CAUTION: Don't use your regular setup. Use a VM or at least a separate configuration via the "--config" switch. This PR affects 77 files, adds 3,708, and removes 5,135 lines Please also consider to repost the news on Mastodon: <https://fosstodon.org/@backintime/116635499945145372> Thanks in advance, Christian Buhtz

2 1

How do you think about UX tests?
by Marcus Rohrmoser May 8, 2026

May 8, 2026

there may be support from https://nlnet.nl/NGI0/services/#uxtesting, I could evtl. organise it. But surely only if the community wants it.. /Marcus

2 3

Status Update and Next Steps
by c.buhtz＠posteo.jp May 6, 2026

May 6, 2026

Hello everyone, The latest release of Canonical Ubuntu 26.04 LTS (Resolute Raccoon) is an opportunity to give a short overview of the current state of Back In Time and what is coming next. Current Status ============== - Latest release: 1.6.1 - Available in latest Debian GNU/Linux (stable, "Trixie", 13) - Available in latest Ubuntu 26.04 LTS (universe repository) - EncFS: - Deprecated and effectively disabled - Existing profiles still accessible - Will be removed completely in the next release Next Release ============ - Planned as 2.0.0 [7] - New mount subsystem (rewritten from scratch) to provide maintainable gocryptfs support [14] - Removal of EncFS [8] - Fixes for rsync change detection and permission handling; may slip to another version if not sufficient in time [10] - My goal is to release this as soon as possible to introduce breaking changes most far long before a new Debian release, to give Back In Time the time to evolve and stabilize. Other big ToDo's and Long-Term Ideas for later Releases ======================================================= - New configuration management code [11] - Configuration file in TOML format [12] - Internal refactoring across multiple layers, improving maintainability, testability and test coverage - Several GUI improvements - Integrate "Snapshots dialog" features into main window and remove the dialog itself - Improve "Manage profiles" dialog - etc Project and infrastructure topics ================================= - Migration to Python build system (PEP 517/621) [13] - Moving from Microsoft GitHub to Codeberg.org - Debian maintenance situation remains unresolved. Practically its status is "orphaned" (Debian meaning for "not maintained"). - Lost contact to former upstream maintainer Germar despite multiple attempts - Handling of low-quality ("AI slop") contributions remains an issue - Code reviews are missing. In most cases there is no second pair of eyes when merge my code. - There is also a lack of manual tests. Additional Notes ================ Thank you --------- I need to express my gratitude to Fabio Fantoni and Danel Echeverry stepping in for the original "Debian maintainer" Jonathan Wiltshier ("jwm") and packaging Back In Time for Debian. Also a big Thank You goes to Skia about approving an Ubuntu Freeze Exception and upload the latest BIT version to Ubuntu's universe repository [4], after we missed their Freeze deadline. Contribution quality and AI slop -------------------------------- This is one of my very personal tasks in this project. It is an ongoing topic with no easy solution. As maintainer I grow suspicious to every unknown account (first-time contributor) not saying "Hello", having to much bling bling icons on their profile page or coming from one of the countries producing millions of AI-using-college-students. I am watching myself and don't like what I see. I want to assume the best efforts in all contributors from the very first beginning, no matter their account age, skill level, or culture. But "AI" and the marketing behind it poisoned that social contract. But fact is, that not a small amount of the first time contributions are "AI slop" and/or of extreme low quality. The tool is not the problem but contributors not taking the responsibility for "their" code. That contributions would require significant review effort just to decided if it is AI or not. And this is even before starting the review itself. Because I am not willing to invest sucht efforts and to keep maintenance sustainable, I tend to close such PR's early. I also report that accounts to Microsoft's abuse team. But I am only a human being, not perfect also sometimes not in the perfect mood. So it comes that sometimes I false-close and miss the best efforts of a first-time contributor. Improving this process without discouraging legitimate contributors is an open task. Other projects I am involved with and occupied by ------------------------------------------------- I need to be careful to stay focused and not lose myself in too many things at the same time. Currently, besides Back In Time, I am working on several other projects: - I reactivated my old RSS reader project "Feedybus" [1] - My "Hyperorg" project need some attention because someone wants to package it for Debian [2]. - Because ongoing resource issues on the side of Debian Maintainers, I created a helper tool for them, named "spdx2debian", to ease their burden with managing copyright and license information [3]. Thank you for reading that far. I am always interested in your feedback. A second opinion or a second pair of eyes is also a valuable contribution. Best wishes, Christian Buhtz [1] https://codeberg.org/buhtz/Feedybus [2] https://codeberg.org/buhtz/hyperorg [3] https://codeberg.org/buhtz/spdx2debian [4] https://bugs.launchpad.net/ubuntu/+source/backintime/+bug/2142983 [5] https://tracker.debian.org/pkg/backintime [6] https://launchpad.net/ubuntu/+source/backintime [7] https://github.com/bit-team/backintime/milestone/36 [8] https://github.com/bit-team/backintime/issues/1734 [10] https://github.com/bit-team/backintime/issues/2388 [11] https://github.com/bit-team/backintime/pull/1850 [12] https://github.com/bit-team/backintime/issues/1984 [13] https://github.com/bit-team/backintime/issues/1575 [14] https://github.com/bit-team/backintime/pull/2449

2 1

Scheduling broken in 1.6.1 ?
by c.buhtz＠posteo.jp March 23, 2026

March 23, 2026

Hello, if you are using Back In time 1.6.1 please check if your scheduled profiles are running as expected. Maybe 1.6.0 users, too. Let me know if this is not the case. Best would be to open an issue for the report. Regards, Christian

1 0

Much earlier removal of EncFS support than planned
by c.buhtz＠posteo.jp March 20, 2026

March 20, 2026

Hello, EncFS support in Back In Time will be removed much earlier than previously planned [1]. Monitor the progress in this PR #2449 [2]. Recent development work on the implementation of gocryptfs support revealed that maintaining EncFS in parallel introduce significant complexity and maintenance overhead. Continuing to keep EncFS in the code base would block progress on gocryptfs and jeopardize the entire plan. I have decided to remove the complete mounting logic and re-implement it from scratch. Refactoring the existing EncFS logic would consume disproportionate time and effort for a component that is scheduled for removal. As a consequence, EncFS must be removed before gocryptfs can be fully implemented. The original plan was to add full gocryptfs support and release that verison of Back In Time with the upcoming Debian 14 (~end of 2027), removing EncFS afterwards. This is no longer feasable. The version of Back In Time version for Debian 14 will include full gocryptfs support will not longer support EncFS. Users currently relying on EncFS should start planning a migration to gocryptfs. Migration documentation and guidance will be provided. Additionally, there is the plan to ensure that the latest EncFS-supporting version of Back In Time remain usable on Debian 14, when installed from upstream. Please let me add that the security issues with EncFS are known since the year 2014 [3]. Removing it from Back In Time was decided in 2023, and first deprecation warning within Back In Time was released in July 2024 with version 1.5.0 [4]. Best regards, Christian Buhtz Current maintainer & lead developer [1] https://github.com/bit-team/backintime/issues/1734 [2] https://github.com/bit-team/backintime/pull/2449 [3] https://sourceforge.net/p/encfs/mailman/message/31849549/ [4] https://github.com/bit-team/backintime/releases/tag/v1.5.0

1 0

Backing up another machine form this machine and storing the backup on this machine
by Jeff Silverman March 11, 2026

March 11, 2026

Hello, I have been using backintime for more years than I can remember and I love it. It just works. I was wandering through the documentation and I realized that I could use backintime to backup my local web server. Currently, the web server has no backups, if something happens to it, I just rebuild it and copy the content to the server. But it occurred to me that I can use backintime to backup the server. My problem is that when I backup my server, it stays on the server. There are five solutions that present themselves: 1) Use an NFS mount from my enormous disk drive that I currently use as the backup destination 2) Use a CIFS (samba) mount from my enormous disk drive that I currently use as the backup destination 3) Use a cron job or similar to run rsync over SSH to pull the files from the server to the enormous disk drive. This seems like the safest solution from a computing security point of view because if the server gets compromised, the putative bad guy does not get write access to the enormous disk drive. 4) Use a cron job or similar to run rsync on the server to push the files from the to the enormous disk drive. 5) Ask if there is a better solution. The problems with solutions 1, 2, and 4 is that if a bad guy gets into my server, then he or she has write access to my enormous disk drive. Yes, I am aware that if a bad guy compromises my server, then he or she can write malware and the backup system will copy it to the enormous disk drive. But unless I do something stupid, that's as far as the malware can get. I see that version 1.6 is in the release process - my question might be answered by upgrading. Is that the case? Thank you Jeff Silverman https://jeffsilverman.ddns.net jeffsilverm(a)gmail.com -- Jeff Silverman jeffsilverm(a)gmail.com http://jeffsilverm.ddns.net <https://jeffsilverm.ddns.net>.

1 0

Update on BackInTime 1.6 Release for Ubuntu LTS
by c.buhtz＠posteo.jp March 2, 2026

March 2, 2026

Hello everyone, Version 1.6 is an important release as it introduces several deprecations and functional changes, and it informs and prepares users about that. In my view, it is important and urgunt that Ubuntu LTS users receive this update so they aren’t caught off guard in later LTS release if BIT stops working within their setup. From my experience, Ubuntu LTS users tend to stay on their LTS version for the full five-year-support period. Version 1.6.0 was unfortunately released rather close (11 days) to Ubuntu's "Debian Import Freeze" (February 19). Two days later, version 1.6.1 followed with fixes, leaving only 9 days before the Import Freeze Deadline. Packaging in Debian was also delayed, which meant we missed the Ubuntu deadline. Fortunately, Fabio Fantoni stepped in again to handle the Debian packaging. Our last chance now is a so-called “freeze exception”: <https://bugs.launchpad.net/ubuntu/+source/backintime/+bug/2142983> I’m not fully familiar with the decision process at Canonical, but the Ubuntu maintainer responsible is the same as for Debian. I’m unsure whether that is an advantage or disadvantage. Just wanted to keep you all updated. Fingers crossed! Best regards, Christian

1 0

Announcement: "plugin system" will be removed
by c.buhtz＠posteo.jp Feb. 17, 2026

Feb. 17, 2026

Hello, I just won't to inform that I'll plan to remove the "plugin system". <https://github.com/bit-team/backintime/issues/2424> There is no concrete time schedule for it. But I like to announce this as early as possible. Let me know if anyone of you created and is using a user-defined plugin beside the ones offered by Back In Time itself. The regular user callback scripts will work and are not related to that issue. The issue at Mastodon: <https://fosstodon.org/@backintime/116087256061038756> Regards, Christian Buhtz

1 0

Announcement: Release 1.6.1
by c.buhtz＠posteo.jp Feb. 10, 2026

Feb. 10, 2026

Hello, two days later I have to announce the 1.6.1 release fixing some minor issues. Full release notes: <https://github.com/bit-team/backintime/releases/tag/v1.6.1> Changelog: <https://github.com/bit-team/backintime/blob/dev/CHANGES> Regards, Christian Buhtz

1 0