Bug#933274: closed by Carsten Schoenert (Re: Bug#933274: thunderbird: TB recreates .icedove profile dir if missing, will not start at next launch)
Il 31/07/19 16:07, Carsten Schoenert ha scritto: It was *not* made for directly modifications on the file system in parallel made by the users them self! I did not do any modifications until I had this issue, I know this since I log these kind of changes. And the root for your reported issue wasn't the TB profile folder migration. I don't think we have enough information to rule either way. If you are missing some further hints, did you have followed the logging output of the starting wrapper and / or have taken a look at the README file within /usr/share/doc/thunderbird? Yes, but until I saw the contents of pref.js the hints in the README made no sense. Adding text in the README was outside my jurisdiction, so to speak, but I felt adding a note in the wiki was ok. Do you believe it's really likely that about 2.5 years after the de-branding of Thunderbird and the profile migration issue are happen often? Please don't make unnecessary assumptions on why some errors might resurface after a long time: I actively use TB on this laptop about once a year, perhaps less often, so it's hardly surprising that an unused program gives no errors. But now I also don't see any deeper need to spend more time on this. The de-branding is almost history and people still have a working TB profile. Even if they have enabled AppArmor. For sure, changing the script now without a clear case to solve is just asking for trouble. Extending the documentation, however, would have been a safe bet, however unlikely it is that we address each and every corner case. Over and out.
Bug#933274: closed by Carsten Schoenert (Re: Bug#933274: thunderbird: TB recreates .icedove profile dir if missing, will not start at next launch)
Hello Andrea,
Am 31.07.19 um 15:40 schrieb Andrea Borgia:
> Hello, Carsten.
>
>
>> unfortunately I needed to revert your modifications after I've read
>> it several times. The added additional section was more than less
>> completely redundant to the exciting section just before!The section
>
> While that section might seem "exciting" to you, it left me scratching
> my head: it provided no meaningful pointers towards a solution, unlike
> my edit. I am also a bit disappointed that what I've learnt while fixing
> this migration error cannot be passed on to the community.
the wrapper script was made to create a working new environment for the
users TB profiles after the rollout of the packages and de-branding them
back to Thunderbird.
It was *not* made for directly modifications on the file system in
parallel made by the users them self!
And the root for your reported issue wasn't the TB profile folder migration.
If you are missing some further hints, did you have followed the logging
output of the starting wrapper and / or have taken a look at the README
file within /usr/share/doc/thunderbird?
> 219 output_debug "There are already the folders or symlinks
> '${TB_PROFILE_FOLDER}' and '${ID_PROFILE_FOLDER}'"
> 220 output_debug "which not pointing to each other, will do nothing as
> don't know which folder to use."
> 221 output_debug "Please investigate by yourself! Maybe you will find
> additional information in '/usr/share/doc/thunderbird/README.Debian.gz'."
Do you believe it's really likely that about 2.5 years after the
de-branding of Thunderbird and the profile migration issue are happen
often? I haven't seen a bug report on this or some private email to me
about issues regarding to a wrong or not working TB profile folder for
about 2.25 years now. So I must getting hardly convinced that the script
isn't working.
We can write much more documentation and guidance for sure, users will
always find something that is not covered.
BTW: Until now nobody come up with a meaningful help and some
preparations about this topic, and I haven't expected any help. :)
But now I also don't see any deeper need to spend more time on this. The
de-branding is almost history and people still have a working TB
profile. Even if they have enabled AppArmor.
--
Regards
Carsten Schoenert
Bug#933274: closed by Carsten Schoenert (Re: Bug#933274: thunderbird: TB recreates .icedove profile dir if missing, will not start at next launch)
Hello, Carsten. unfortunately I needed to revert your modifications after I've read it several times. The added additional section was more than less completely redundant to the exciting section just before!The section While that section might seem "exciting" to you, it left me scratching my head: it provided no meaningful pointers towards a solution, unlike my edit. I am also a bit disappointed that what I've learnt while fixing this migration error cannot be passed on to the community. I see no need to add this again and point to an bug report which does not have more and detailed information than already known, that is confusing users more than needed. Fair enough: I added the link to expand on how that scenario might come about, because I saw that bugs are frequently referenced in the wiki. In comparison to the resolution steps I wrote in the wiki, this is not so important, for sure. Regards, Andrea.
Bug#933274: thunderbird: TB recreates .icedove profile dir if missing, will not start at next launch
Hello, Carsten. this is with recent versions of Thunderbird not possible anymore as this is hard coded within the sources. I never had experienced something like you have described. It only happened on my laptop, the desktop was fine. In fact, I used it as a control of sorts. For sure, as this one of the conditions the wrapper is checking. But why do you delete any folder if Thunderbird working correctly? It wasn't my initial goal: I just wanted to find out why TB refused to start! During my tests, I ended up discovering the newly created .icedove first and later the odd behaviour with the symlink, none of which was happening on the other system. Any Apparmore profile for TB activated? My system diary shows I disabled it on my desktop when dealing with #918035; checking the laptop, I can find no AppArmor errors on the day I opened this report and apparmor_status has no entry for thunderbird. This is on the user side as one packaging rule strictly says we don't change anything within the users folder while package installation or upgrade. And adding a symlink that probably will never break things within the users home folder is quite the maximum we can do. Understood. I was thinking about some external helping script that could do this migration but due lack of interests and urgency I haven't work further here. And it's mainly just the moving of '.icedove' to '.thunderbird' in the prefs.js file. But other extensions can have there own setting withing the TB profile! I see, then I'll probably add a short paragraph to the wikipage explaining this corner case and you may close this report. Thanks, Andrea.
Bug#933274: thunderbird: TB recreates .icedove profile dir if missing, will not start at next launch
Hello Andrea, Am 28.07.19 um 19:50 schrieb Andrea Borgia: > This system has gone through the thunderbird->icedove->thunderbird > conversions; launching thunderbird with a real .thunderbird profile > directory and no .icedove, thunderbird will recreate .icedove as a > directory, this is with recent versions of Thunderbird not possible anymore as this is hard coded within the sources. I never had experienced something like you have described. And further more the logic in the starting wrapper script checks exactly this as first use case and will leave the loop for checking things as having ~/.thunderbird folder the default again. > so that following attempts to run it will fail with a conversion > error. If I remove the .icedove directory and replace it with a symlink to > .thunderbird, the program will start happily. For sure, as this one of the conditions the wrapper is checking. But why do you delete any folder if Thunderbird working correctly? Please don't try to be smarter than the binary is working. Any Apparmore profile for TB activated? > Thinking it might have been an incomplete conversion, I quit the program, > removed the .icedove symlink, renamed .thunderbird to .icedove and restarted > the program. Once the conversion was done, I closed the program and > verified I had my ".icedove" (formerly .thunderbird) directory and a new > .thunderbird symlink. I deleted this symlink and renamed .icedove to > .thunderbird: no luck, again .icedove as real dir at the first run and an > error at the next. > > First I though this was #857029 again but it turned out that, for some > reason, this profile still had a "prefs.js" which referenced ".icedove": > manually editing this file fixed the issue for good. Shouldn't this file be > migrated too? This is on the user side as one packaging rule strictly says we don't change anything within the users folder while package installation or upgrade. And adding a symlink that probably will never break things within the users home folder is quite the maximum we can do. I was thinking about some external helping script that could do this migration but due lack of interests and urgency I haven't work further here. And it's mainly just the moving of '.icedove' to '.thunderbird' in the prefs.js file. But other extensions can have there own setting withing the TB profile! -- Regards Carsten Schoenert
Bug#933274: thunderbird: TB recreates .icedove profile dir if missing, will not start at next launch
Package: thunderbird Version: 1:60.8.0-1 Severity: normal Dear Maintainer, This system has gone through the thunderbird->icedove->thunderbird conversions; launching thunderbird with a real .thunderbird profile directory and no .icedove, thunderbird will recreate .icedove as a directory, so that following attempts to run it will fail with a conversion error. If I remove the .icedove directory and replace it with a symlink to .thunderbird, the program will start happily. Thinking it might have been an incomplete conversion, I quit the program, removed the .icedove symlink, renamed .thunderbird to .icedove and restarted the program. Once the conversion was done, I closed the program and verified I had my ".icedove" (formerly .thunderbird) directory and a new .thunderbird symlink. I deleted this symlink and renamed .icedove to .thunderbird: no luck, again .icedove as real dir at the first run and an error at the next. First I though this was #857029 again but it turned out that, for some reason, this profile still had a "prefs.js" which referenced ".icedove": manually editing this file fixed the issue for good. Shouldn't this file be migrated too? -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.2-19.03.18.amdgpu (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunderbird depends on: ii debianutils 4.8.6.3 ii fontconfig2.13.1-2 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-1 ii libdbus-glib-1-2 0.110-4 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-9 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:9.1.0-10 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-3 ii libgtk-3-03.24.5-1 ii libgtk2.0-0 2.24.32-3 ii libhunspell-1.7-0 1.7.0-2+b1 ii libicu63 63.2-2 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.21-1 ii libnss3 2:3.45-1 ii libpango-1.0-01.42.4-6 ii libsqlite3-0 3.29.0-1 ii libstartup-notification0 0.12-6 ii libstdc++69.1.0-10 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-shm0 1.13.1-2 ii libxcb1 1.13.1-2 ii libxext6 2:1.3.3-1+b2 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1+b3 ii psmisc23.2-1 ii x11-utils 7.7+4 ii zlib1g1:1.2.11.dfsg-1 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1 ii hunspell-it [hunspell-dictionary] 1:6.3.0~rc1-1 ii lightning 1:60.8.0-1 Versions of packages thunderbird suggests: ii apparmor 2.13.3-3 pn fonts-lyx ii libgssapi-krb5-2 1.17-5 -- no debconf information
