Next Debian freeze at 12. January 2023
Hi Folks, I just realized that the next Debian freeze is terminated at 12th January next year. Freeze means that all packages in that debian repository prepared for the next release are freezed at the current state. Until that date only security and major bug fix are gone make it into the repo. So for BIT this is a good deadline to face the next release fixing the current high priority bugs. According to the rsync-incompatibility-problem (#1247) I see no big problem to fix it until then including intensive testing. I suspect that BIT will leave the Debian repo if this bug isn't fixed. About the other known problems I'm not enough into them to judge how much time that will take. Kind Christian
Thanks for the heads-up, Christian! That's certainly sooner than I would have hoped, but it's also an encouragement :) We certainly know by now which bugs are the highest priority, so we can get to work on it. Cheers :) Michael On 05.10.2022 21:44, c.buhtz@posteo.jp wrote:
Hi Folks,
I just realized that the next Debian freeze is terminated at 12th January next year.
Freeze means that all packages in that debian repository prepared for the next release are freezed at the current state. Until that date only security and major bug fix are gone make it into the repo.
So for BIT this is a good deadline to face the next release fixing the current high priority bugs.
According to the rsync-incompatibility-problem (#1247) I see no big problem to fix it until then including intensive testing. I suspect that BIT will leave the Debian repo if this bug isn't fixed.
About the other known problems I'm not enough into them to judge how much time that will take.
Kind Christian _______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: foss@michael-bueker.de
On Wed, 2022-10-05 at 19:44 +0000, c.buhtz@posteo.jp wrote:
I just realized that the next Debian freeze is terminated at 12th January next year. ... So for BIT this is a good deadline to face the next release fixing the current high priority bugs.
Good point! On my short list are these issues until then: 1. "Save password to keyring" option is disabled https://github.com/bit-team/backintime/issues/990 2. callback / mount not called when the profile changed Profile change causes unmount only https://github.com/bit-team/backintime/issues/724 user-callback unmounts while gui is running https://github.com/bit-team/backintime/issues/977 3. [Unit tests] Popen() warning: subprocess is still running (non-deterministic) https://github.com/bit-team/backintime/issues/1292 Optional if I really have time for that (since very time consuming but HIGH): - Bit won't start. dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'net.launchpad.backintime.serviceHelper': no such name https://github.com/bit-team/backintime/issues/1052 - Tray icon issues https://github.com/bit-team/backintime/issues/1306
On 07.10.2022 23:27, J. A. wrote:
On Wed, 2022-10-05 at 19:44 +0000, c.buhtz@posteo.jp wrote:
I just realized that the next Debian freeze is terminated at 12th January next year. ... So for BIT this is a good deadline to face the next release fixing the current high priority bugs.
Good point! On my short list are these issues until then:
Thanks for the info :) To me, the single most important bug is the permissions/hardlink FUBAR introduced in 1.2.0 (best documented in #988). It still has a number of duplicates, which I will sort out, and then try to find a recipe for reliably reproducing the error. What's scary about this bug is that whatever we do, existing backups will be affected. We have people with their existing backups: a) running backintime's new >=1.2.0 default mode (rsync --perms), b) running the "--no-owner etc." workaround documented in #988, and c) possibly in even more exotic states. Currently, my feeling is that "rsync --perms" should be removed again, reverting permissions handling to the way it was before 1.2.0. "rsync --perms" may be more trouble than it's worth, but that assessment might change as I research why it was introduced in the first place (my guess: to make "full rsync mode" [which itself replaced a "cp -l"-based hack] more "full"?). As I said, it's difficult to cover all possible interactions with existing backups for any change we make. Cheers, Michael
participants (3)
-
c.buhtz＠posteo.jp -
J. A. -
Michael Büker