Control: forcemerge -1 946347 Hello Jens,
this issue was first submitted by #946347 https://bugs.debian.org/946347 Am 11.12.19 um 12:33 schrieb Jens Holzkämper: > The current package of thunderbird in stretch (68.2.2-1~deb9u1) reports a > bigger version number than the current package in buster (68.2.2-1~deb10u1) > due > to the inclusion of the build timestamp. The version reported by stretch is > 68.2.2_20191116203149/20191116203149 and buster > 68.2.2_20191116193034/20191116193034. > > This information is then used by thunderbird to fill the compatibility.ini in > the profile and after an upgrade from stretch to buster leads to thunderbird > prompting to either quit or create a new profile because it detects that an > older version of thunderbird is trying to open a profile last used by a newer > version. I believe > using the same profile should be safe, as the underlying upstream version is > the same at the moment and should probably never be newer in oldstable than > stable. > > As a workaround it's possible to start thunderbird with the parameter > "--allow- > downgrade" or manually delete the line starting with "LastVersion=" in the > compatibility.ini in the profile but less savy users may use access to the > data > in their old profiles (the data is still there but a regular user will > probably > not be able to access it without further instructions). currently I don't test such upgrade scenarios and until now we don't had any need to do such testing. If we would know which variable is used within the build we could use the same date for all builds of the thunderbird packages and prevent such situations. For now I can only build technically the stretch version before the buster version to get the older date hard included within the thunderbird binary. @Emilio Updating from jessie to stretch will of course affected by this issue. I've no idea how we could solve as in the end the jessie version would be needed built first of all. Do you have contact to Mike or Sylvestre which might know if there is such an variable we could use while building the packages? -- Regards Carsten Schoenert
