Mailman 3 February 2025 - Bit-dev

Release Candidate 1.5.4-rc1 targeted for Debian 13 "Trixie"
by c.buhtz＠posteo.jp Feb. 25, 2025

Feb. 25, 2025

Hello, I am happy to announce a new Release Candidate in preparation for the Back In Time release version 1.5.4 which is targeted for the upcoming Debian release version 13 (Trixie) this summer. Please report back if you use it, even if no issues are found. <https://github.com/bit-team/backintime/releases/tag/v1.5.4-rc1> This version is set to be released with Debian 13 (Trixie) this early summer and will remain available for the long lifetime of that Debian version. EncFS, used for encrypted profiles, has been marked as deprecated and is schedule for removal in 2026. The Smart & Auto remove GUI has been reorganized and renamed into "Remove & Retention", with improvements to the user manual section. Its behavior remains unchange. An offset minute can now be configured for hourly schedule options. Some config file fields have been moved to a newly introduced state file. License and copyright information is now provided in machine-readable SPDX format, following the REUSE standard. # Contributors This version received extensive support from contributors (in alphabetical order): - @bremnere - David Gibbs @fallingrock - graysky @graysky2 - Samuel More @mooresamuel - Iván Rodríguez @ivanrdgz03 - Peter Sevens @sevens - David Wales @daviewales - Dylan Wilson @dylan-wilson-usq - Also not to be forgotten are the many people who supported the project by testing it, providing feedback, reporting issues, and analyzing problems. # Known major issues open - qt_probing.py may hang with high CPU usage when running Back In Time as root via cron (https://github.com/bit-team/backintime/issues/1592) - File permissions handling and therefore possible non-differential backups (https://github.com/bit-team/backintime/issues/988 & https://github.com/bit-team/backintime/issues/994) # Changelog * Changed: More clear and intense warning about EncFS deprecation and removal (https://github.com/bit-team/backintime/issues/1904) * Changed: Updated desktop entry files * Changed: Move several values from config file into new introduce state file ($XDG_STATE_HOME/backintime.json) * Changed: Completed license information to conform the REUSE.software and SPDX standards. * Breaking Change: Auto-remove rules "Free inodes" and "Free space" disabled by default (https://github.com/bit-team/backintime/issues/1976) * Fix!: Smart-remove rule "Keep one snapshots per week or the last week" use calendar weeks * Fix: The width of the fourth column in files view is now saved * Fix: Snapshot compare copy symlink as symlink (https://github.com/bit-team/backintime/issues/1902) (Peter Sevens @sevens) * Fix: Crash when comparing a snapshot with a symlink pointing to a nonexistent target (Peter Sevens @sevens) * Fix: Crash (KeyError) opening language setup dialog with unknown locale/language * Feature: Open user manual (local if available otherwise online) via Help menu * Feature: Toolbar context menu to display the buttons in different combinations with icons and text (https://github.com/bit-team/backintime/issues/1105, https://github.com/bit-team/backintime/pull/2002) (Samuel Moore @s4moore) * Feature: Add offset minutes to hourly schedules (David Gibbs @fallingrock) * Doc: Remove & Retention (formally known as Auto-/Smart-Remove) with improved GUI and user manual section (https://github.com/bit-team/backintime/pull/2000) Regards, Christian Buhtz on behalf of the maintenance team

1 1

(no subject)
by c.buhtz＠posteo.jp Feb. 24, 2025

Feb. 24, 2025

Hello together, While the new year was coming I thought about summarizing what happened the last year in this project. But because I found way to much stuff, now please allow me to summarize the project progress since 2022 when the new team took over. # Releases, Features & Bugs The first release with the new team involved was 1.3.3 in January 2023. Since then we did seven additional releases, with 1.5.3 in November 2024 as the last.[9] Scrolling through the changelog, most of the entries are related to refactoring code and housekeeping work around the projects infrastructure and documentation. But we also fixed a lot of bugs and improved several other details. - Diagnostic and debug output was improved to support us analyzing bugs. - Continuous improvement of the test suite and usage of linters to force code quality. - Some aspects of the GUI are modified, for example the "Settings" dialog, now renamed to "Manage profiles" dialog. - BIT was adapted to rsyncs new behavior regarding argument protection. - Error handling and logging was improved. - Some bugs around X and Wayland are dealt with. - Migration of Qt from version 5 to 6. - Begin with deprecation of EncFS because of security issues. - The user manual migrated to MkDocs and might be easier to edit for non technical users. - And a lot more ... # Managing Issues, Pull Requests and the overall workflow In the first year (all) ~400 issues where triaged and until now cut into half.[1] All modifications, even those by maintainers, are handled with pull requests (PR).[2] PRs are used to force quality and find errors. In the best days a PR will get reviewed and approved by a second person. But we are seriously lacking reviewers and testers. But we also had several active contributors in different areas, providing bug fixes and new features. To manage on organize issues and PRs, labels and milestones are used. The later is nice to prioritize things. Therefore others can get a good overview of what is coming next. # Facing problems Some PRs are just AI crap. It is not much yet. But it cost some time to identify and deal with it. Every "contributor" throwing unreviewed and untested AI code to our project, is reported to our code hoster. # Translation This is going very well. Moved from Canonical Launchpad to Weblate hosted at Codeberg.org.[3] Weblate is a web frontend, easy to use by non technical users. I did a lot of acquisition in the community, translation forums, and other channels to recruit translators. There where round about 350 translatable strings in the beginning. Because of additional text but also optimization, e.g. break down multi-line text, these are now round about 430 strings. Nearly [10] all strings have screenshots attached to them to give translators more context. # Pulic relation I tried to do public relations for the project in several areas to attract contributors. We got some news articles.[4][5] Wherever it is appropriated I do announce that the project is back alive, and asking for translators and testers. Our traffic statistic at our Microsoft GitHub repo shows constantly round about 100 unique visitors each day. I also tried to attract new contributors and offering mentoring to newbies. I use "Help wanted" and "Good first issue" labels. I updated our documentation for newbies.[6][7] Beside the mailing list, the project now has a Mastodon account[8]. I always tried to establish and keep contact to distro and package maintainers. Regards, Christian [1] -- <https://codeberg.org/buhtz/spielwiese/src/branch/main/bit.md> [2] -- <https://github.com/bit-team/backintime/blob/dev/CONTRIBUTING.md#what-happen…> [3] -- <https://translate.codeberg.org/engage/backintime/> [4] -- <https://linuxnews.de/back-in-time-is-back/> [5] -- <https://lwn.net/Articles/996720/> [6] -- <https://github.com/bit-team/backintime/blob/dev/CONTRIBUTING.md> [7] -- <https://github.com/bit-team/backintime/blob/dev/FAQ.md#how-to-review-a-pull…> [8] -- <https://fosstodon.org/@backintime> [9] -- <https://github.com/bit-team/backintime/releases> [10] -- <https://github.com/bit-team/backintime/issues/2028>

1 0

du command slow over multiple snapshots
by William Seligman Feb. 5, 2025

Feb. 5, 2025

I'll start by acknowledging that is not a bug in backintime. If this is the wrong place to ask this question, please consider leaving a suggestion to where I should ask. I've set up a Linux server to serve as a repository for remote backintime backups for several systems. I'm trying to create a report, for each system's backup, of the amount of disk space used for the latest snapshot (easy, I'll show the command below), and total disk space used for all the snapshots for that system. To the disk space used for the latest snapshot (or any particular snapshot), there's no difficulty. For example: /usr/bin/du -sx /pool/backup/backintime/mysystem.example.com/user/1/last_snapshot/backup/* The problem comes when I want to see the total disk use for `mysystem.example.com`. This command gives the correct answer, as far as I can tell: /usr/bin/du -sx /pool/backup/backintime/mysystem.example.com/ The problem is that while the answer appears to be correct, as the number of snapshots increases, the du command takes longer and longer to execute. For some of the backups with a large number of files, it takes hours for that one du command to execute. My guess is that this has something to do with how du is handling the hard links in order to get that correct answer. Based on my fiddling around, it appears that du is visiting every snapshot directory and going through all of files it finds, even if there are only a few files that differ between snapshots. The result appears to be that if that first `du` command takes ten minutes due to the number of files in the snapshot, the second `du` command takes ten minutes * the number of snapshots. Is my guess correct? Or is this due to something else? Is there any work-around? The purpose of this report I'm creating is to understand how much actual disk space is being used over time for backintime backups. If I found that new snapshots were taking up a lot of space, it would mean the system's user was refreshing a lot of large files in-between snapshots. I'd want to re-evaluate the frequency of their backups or how long backintime retained the snapshots. AlmaLinux 9.5 backintime 1.3.2 I obtained backtime via the EPEL repository: dnf install backintime-qt Disk has: # df -h /pool Filesystem Size Used Avail Use% Mounted on /dev/mapper/POOL-pool 17T 5.1T 11T 33% /pool # df -hi /pool Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/POOL-pool 262M 58M 205M 22% /pool -- -- Bill

3 3

Remove & Retention: Improved GUI and added user manual section
by c.buhtz＠posteo.jp Feb. 1, 2025

Feb. 1, 2025

Hi, As discussed earlier I improved the GUI about the Auto-/Smart-Remove feature, now known as Remove & Retention. I also added a section to the user manual. The goal was only to investigate, document and clarify how that feature currently work. To minimize the risk of bugs, the behavior should be kept as it is in this initial step. Despite this step sounds minimal it was much more work than I though in the beginning. The modifications are not merged yet but available via my PR. Feedback is welcome. <https://github.com/bit-team/backintime/pull/2000> The relevant docu section can be found here in its markdown format: <https://github.com/buhtz/backintime/blob/fix/1976retention/doc/manual/src/r…> Looking forward to your feedback. Regards, Christian

1 0