CherryTree Closes Unexpectedly on Various Debian-Based Distros

[Iggy64]

Currently running CherryTree 0.99.44 on SparkyLinux 7 (Orion-Belt), x86-64, xfce 4.16 desktop. Kernel is 5.15.0-2-amd 64.

CherryTree runs very capably on this setup. The only bug is that CherryTree occasionally (perhaps once every few hours) closes unexpectedly.

Although it is configured to save upon closing, it does not save the most-recently entered data.

Note, however, that I have purposefully configured CherryTree to autosave every 1 minute. So I never lose very much work, and can restore any slight loss easily. The situation is very livable, but I thought it worth reporting.

Note that I am also running CherryTree on an MX Linux machine, a Debian Bullseye machine, and a Mint 19.3 machine. I have had occasional unexpected closing of CherryTree on those machines, too. All these operating systems are Debian based, and all are running fairly recent versions of xfce.

I do not have unexpected closing of any other apps on any of my machines.

I cannot tell you much detail about the circumstances about when this bug occurs, as it happens sporadically. In most cases, I am running Firefox browser, CherryTree, and perhaps a utility (like gnome-disk-utility). But I have noted no particular circumstance that encourages the disappearance of CherryTree.

After today's occurrence, I ran: john@sparky8gb:~$ sudo dmesg | grep cherrytree [685890.382174] cherrytree[87601]: segfault at 0 ip 00007fe1e8c836e0 sp 00007fff67ce9070 error 4 in libgtkmm-3.0.so.1.1.0[7fe1e8b99000+12f000]

Sadly, I am not educated enough to know exactly what this means. (A memory-access problem of some sort?)

Forgive me if my report here is in poor condition. This is my first post (I believe) to GitHub, and I have little experience with this business. I thought you might have some benefit from this feedback.

As already noted, I have an easy workaround -- by autosaving my work every 1 minute.

Also, CherryTree is something I use every day in my professional and personal work. I am a researcher who is called upon to organize information and make it presentable to other decision makers. I have found no other software that suits my needs as well as CherryTree. I am very grateful to the work that has gone into making this such an invaluable tool to me and for several of my colleagues (I relay their thank-yous to you).

[datavectors]

"I am a researcher who is called upon to organize information and make it presentable to other decision makers".

I am another enthusiast user, sole developer / retired, of CherryTree in Ubuntu. If you can elaborate somewhat on the type of information (domain of research and decisions), then you might draw on ideas I have developed for using CherryTree within a framework. In a toolchain.

Regarding loss of data : Ensure that you setup auto save in File > Preferences. I keep three backups per CherryTree document. Each has a tilde character attached, *,ctd~

[giuspen]

@Iggy64 the cause of the crashes may be ironically the autosave. If you just want to get rid of it, try to disable the autosave and frequently hit Ctrl+S to save so you will see if it happens again. If you would be available to help me debug the issue, since it happens systematically for you, you could do the following: 1) build from source code: ./build.sh 2) run gdb: gdb ./build/cherrytree 3) from gdb run: (gdb) r 4) after it crashes go back to the terminal and hit bt: (gdb) bt paste here the backtrace Another option giving problem to some users was to automatically reload after external update to the cherrytree document in the preferences dialog tab miscellaneous

[Iggy64]

Hello Giuseppe,

It is very kind of you to take time to respond to my inquiry, and so quickly! 

First of all, let me once again thank you for your continuing development and support of the CherryTree software.  I am not exaggerating when I say it is the most essential and productive piece of software I have ever had the pleasure to use.  I have been doing research for over 50 years -- in physics, metallurgy, marketing, legal issues, logistics, and other fields -- and my efforts have been hugely facilitated by CherryTree.  I have built huge, highly organized databases of information and ideas for myself and for my clients.  My clients are always "blown away" by how accessible these databases are, and how easily they convey the relationships and implications.  I am very grateful to you! Concerning the unexpected closing of CherryTree: Thank you very much for your suggestions. 

• I will certainly experiment with disabling the autosave.

• I already do hit [CTRL] [S] frequently, out of habit.  With autosave turned off, I will make extra sure to do so.

• I hope I can help you with the debugging.  Although I have been a Linux user for a couple of decades, and have a fair amount of CLI experience, I confess that I have not built any app from source or helped with any debugging.  But I really enjoy learning new things, and I will study up on this and give it a go. 

Thanks, again, for your wonderful software and for you very kind support! Iggy64Ohio USA

On Saturday, January 15, 2022, 09:09:29 AM EST, Giuseppe Penone ***@***.***> wrote:  

@Iggy64 the cause of the crashes may be ironically the autosave. If you just want to get rid of it, try to disable the autosave and frequently hit Ctrl+S to save so you will see if it happens again. If you would be available to help me debug the issue, since it happens systematically for you, you could do the following:

• build from source code: ./build.sh
• run gdb: gdb ./build/cherrytree
• from gdb run: (gdb) r
• after it crashes go back to the terminal and hit bt: (gdb) bt
  paste here the backtrace
  Another option giving problem to some users was to automatically reload after external update to the cherrytree document in the preferences dialog tab miscellaneous

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[giuspen]

Thanks for your kind feedback @Iggy64 :)

[datavectors]

I searched for the error pattern .. error 4 in libgtkmm-3.0.so.1.1.0

Are you perhaps closing CT using Ctrl+Q ?

https://bugs.archlinux.org/task/68813

[Iggy64]

Hello Giuseppe! Thank you for your kind suggestions.  I have been running Cherrytree for the past couple days with the autosave feature turned OFF (something I have never done before).  So far so good: no crashes!  As always, I frequently hit [CTRL][S], especially after entering some particularly important information.  I think I can get along fine this way.  I am pretty good at remembering to manually save.  If I should run into any further crashes, though, I will let you know!

Meanwhile, I would be very happy to help with the debugging you suggested.  Sadly, I have absolutely no experience with building from source or running any debugging.  I hate to impose upon you to give a more-detailed explanation of how to set up the debugging, as you have already shared a great deal of your time with me. For example: In Step 1: build from source code: ./build.sh I assume this (./build.sh) is a bash shell script I am supposed to run.Would I simply run it in terminal, with no arguments?What would it do?In any case, I cannot find this script in root, and I cannot find it anywhere else, for that matter.If I enter "./build.sh" into terminal, it tells me the file doesn't exist.Can you tell me how to access this, and exactly what should be entered on the command line?

In Steps 2 and 3, again, these commands are very unfamiliar to me.So I don't know how much of what you have written I should copy. For example, for Step 2, would I typerun gdb: gdb ./build/cherrytree orgdb:gdb  ./build/cherrytree orgdb  ./build/cherrytree? You see, I am really unfamiliar with the syntax of these commands. 

I am truly sorry that I cannot run something that must seem terribly trivial to you.  I have learned a great deal about the command line over many years, but I have never dealt with building from source, or with debugging.  Of course I did some quick research on these commands last night, but I couldn't seem to find any good examples using these terms for the purpose at hand. If you have time to explain how to access build.sh, and to show more explicitly exactly what words to enter on the command line for the other steps, I will try my very best to run the debugging scheme you outlined. If you DON'T have time for that, I completely understand!  I do not want to impose. Thank you for all the help you have already offered, and -- again -- for creating this terrific software for all of us.  And your documentation is superb! Best @.***

On Saturday, January 15, 2022, 09:09:29 AM EST, Giuseppe Penone ***@***.***> wrote:  

@Iggy64 the cause of the crashes may be ironically the autosave. If you just want to get rid of it, try to disable the autosave and frequently hit Ctrl+S to save so you will see if it happens again. If you would be available to help me debug the issue, since it happens systematically for you, you could do the following:

• build from source code: ./build.sh
• run gdb: gdb ./build/cherrytree
• from gdb run: (gdb) r
• after it crashes go back to the terminal and hit bt: (gdb) bt
  paste here the backtrace
  Another option giving problem to some users was to automatically reload after external update to the cherrytree document in the preferences dialog tab miscellaneous

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[ghost]

It will not help that much, but for info, I never had any crash with CT autosave in Debian with packages provided by Debian or from Ubuntu ppa. What is the size of the CT file ?

[Iggy64]

Concerning the question concerning the CT file size --------- In my case, the size in /usr/bin  is 5,965,032 bytes. Additional info: @.:~$ apt-cache policy cherrytree cherrytree:   Installed: 0.99.44-1   Candidate: 0.99.44-1   Version table:   0.99.44-1 1001        1001 https://repo.sparkylinux.org orion/main amd64 Packages         100 /var/lib/dpkg/status      0.99.43+dfsg-1+b1 500         500 http://deb.debian.org/debian bookworm/main amd64 Packages

So my installed version (0.99.44-1) on this machine (running Sparky Linux 7 semi-rolling) comes from the SparkyLinux "Orion" main repo, and not from Debian Bookworm (testing). I do have another laptop here running Debian Bullseye, but I no longer have one running MX Linux.  I will fire up the Bullseye computer tomorrow morning and start running CT on that one, to see if autosave causes problems there.  I know I had the occasional crash problem on either the Bullseye machine or the MX machine or both; because when it happened on this Sparky machine, I thought to myself: "Oh, this didn't go away." As I said before, this is no big deal, as I am pretty disciplined about manual saving.  Just thought I'd bring it to your attention to see if it was a known issue with a known solution.  I gather you have heard of it before, as you brought up the autosave idea right away.  I continue to test that by running without autosave.  So far, so good.Meanwhile, if you can clarify the questions I sent about the debugging procedure, I will enthusiastically try to get you some feedback with that. Thanks for all your consideration!Iggy64

On Monday, January 17, 2022, 05:54:39 PM EST, ciranus ***@***.***> wrote:  

It will not help that much, but for info, I never had any crash with CT autosave in Debian with packages provided by Debian or Ubuntu. What is the file size of the CT file ?

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[Iggy64]

Upon further review --- I dug out my notes from when I first installed Cherrytree on Debian.  Of course, my notes are stored in a Cherrytree file called "Debian :). At that time, I was running Debian 10 Buster.  Cherrytree was not available in the Buster repo, so I grabbed the flatpak.  My notes tell me I had two issues with that flatpak:

• The mysterious occasional crash

• Objects (documents) could be embedded in the outline, but they could not be retrieved.  Neither problem  was a deal breaker, as I could retrieve the embedded objects by opening my file in Linux Mint. When Debian Bullseye was released in October, I upgraded, and was delighted to find that Cherrytree was now available in the repo.  So I installed that, and it ran much better.  I don't have any notes saying the crash problem occurred with that version. I will fire up that machine tomorrow morning and set CT running with autosave, and watch what happens.  I can report on the version number at that time.

  ----- Forwarded Message ----- From: John Slane @.>To: giuspen/cherrytree @.>Sent: Monday, January 17, 2022, 08:43:37 PM ESTSubject: Re: [giuspen/cherrytree] CherryTree Closes Unexpectedly on Various Debian-Based Distros (Issue #1930) Concerning the question concerning the CT file size --------- In my case, the size in /usr/bin  is 5,965,032 bytes. Additional info: @.:~$ apt-cache policy cherrytree cherrytree:   Installed: 0.99.44-1   Candidate: 0.99.44-1   Version table:   0.99.44-1 1001        1001 https://repo.sparkylinux.org orion/main amd64 Packages         100 /var/lib/dpkg/status      0.99.43+dfsg-1+b1 500         500 http://deb.debian.org/debian bookworm/main amd64 Packages

So my installed version (0.99.44-1) on this machine (running Sparky Linux 7 semi-rolling) comes from the SparkyLinux "Orion" main repo, and not from Debian Bookworm (testing). I do have another laptop here running Debian Bullseye, but I no longer have one running MX Linux.  I will fire up the Bullseye computer tomorrow morning and start running CT on that one, to see if autosave causes problems there.  I know I had the occasional crash problem on either the Bullseye machine or the MX machine or both; because when it happened on this Sparky machine, I thought to myself: "Oh, this didn't go away." As I said before, this is no big deal, as I am pretty disciplined about manual saving.  Just thought I'd bring it to your attention to see if it was a known issue with a known solution.  I gather you have heard of it before, as you brought up the autosave idea right away.  I continue to test that by running without autosave.  So far, so good.Meanwhile, if you can clarify the questions I sent about the debugging procedure, I will enthusiastically try to get you some feedback with that. Thanks for all your consideration!Iggy64

On Monday, January 17, 2022, 05:54:39 PM EST, ciranus ***@***.***> wrote:  

It will not help that much, but for info, I never had any crash with CT autosave in Debian with packages provided by Debian or Ubuntu. What is the file size of the CT file ?

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[ghost]

I mean the file size of your 'myfile.ctb' database file, not the binary file. If too big, instead of saving everything in one single file, you can split this file in 2 or 3 smaller files. What you don't use very often can be archived in a archive.ctb file, an open it when needed. You can use the export feature to achieve this very easily. I suspect this kind of crash only happens with very big files.

[Iggy64]

Thanks for the clarification. The file I am currently working on is my outline of SparkyLinux.  I am documenting everything from installation to modification to performance.  While using autosave, I had a crash perhaps once a day.  No big deal, as a never lost more than 60 seconds of work, which was easily remembered.  After disabling autosave, I have not had a crash, but it's only been a day since I started in that mode.  So only time will tell.

At this stage, the file size of SparkyLinux.ctb is 2.2MB. Looking at my directory of CT files, I find they range in size from around 20KB to about 41MB.  Of my current 54 outlines, I would estimate the mean size to be about 4MB.  So my current 2.2MB working file is pretty much of average size for me. 

When I was developing the 41MB database, the work spanned a few weeks, and I don't recall having any crashes.  That work was done on a previous version of Linux Mint. 

As noted recently, I DID have crashes with the flatpak version I used while running Debian Buster (since Buster repos did not provide Cherrytree).  I now have Debian Bullseye on that machine, and the Bullseye main repo did add a debian version of Cherrytree.  Later today, I will fire up that machine and run Cherrytree on it for awhile, to see if that was the other version that exhibited the problem. Again, on Sparky 7 (semi-rolling), the Cherrytree version comes from Sparky's own "Orion" repo. 

I do like the idea you proposed about subdividing large databases -- regardless of whether or not it affects the crash issue.  There are situations where I simply have too much in one giant outline, and breaking it into appropriately labeled "chunks" might make the information more approachable.

On Tuesday, January 18, 2022, 06:42:50 AM EST, ciranus ***@***.***> wrote:  

I mean the file size of your 'myfile.ctb' database file, not the binary file. If too big, instead of saving everything in one single file, you can split this file in 2 or 3 smaller files. What you don't use very often can be archived in a archive.ctb file, an open it when needed. You can use the export feature to achieve this very easily. I suspect this kind of crash only happens with very big files.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[ghost]

Your database file is so small...... it cannot explain.

So my installed version (0.99.44-1) on this machine (running Sparky Linux 7 semi-rolling) comes from the SparkyLinux "Orion" main repo, and not from Debian Bookworm (testing).

Your orion SparkyLinux CT package depends on libfmt7. Debian Bookworm CT package depends on libfmt8.

Then Sparky 'testing' is not aligned on Debian 'testing'. Just to see report this: apt policy libfmt7 libfmt8

and check you if have problems on Debian Bulleyes (you should not).

[Iggy64]

As you can probably tell, I am out of my depth here.  I mentioned earlier that - despite many years of using Linux OSes, I have studied very little about package development and management.  This is one of the reasons I have decided to venture timidly into working directly with Debian and with close derivatives like MX and Sparky.  I very much appreciate your willingness to steer me on my initial "rude awakening" with dependency conflicts.  Below are the outputs from apt policy.  It seems that libfmt7 and libfmt8 are both installed.  As you pointed out, the installed version of CT is 0.99.44-1 from Sparky Orion repo, and not 0.99.43+dfsg-1+b1 from Debian Bookworm. 

@.:~$ apt policy libfmt7 libfmt8 libfmt7:   Installed: 7.1.3+ds1-6   Candidate: 7.1.3+ds1-6   Version table:   7.1.3+ds1-6 100         100 /var/lib/dpkg/status libfmt8:   Installed: 8.0.1+ds1-4   Candidate: 8.0.1+ds1-4   Version table:   8.0.1+ds1-4 500         500 http://deb.debian.org/debian bookworm/main amd64 Packages         100 /var/lib/dpkg/status @.:~$ apt policy cherrytree cherrytree:   Installed: 0.99.44-1   Candidate: 0.99.44-1   Version table:  *** 0.99.44-1 1001        1001 https://repo.sparkylinux.org orion/main amd64 Packages         100 /var/lib/dpkg/status      0.99.43+dfsg-1+b1 500         500 http://deb.debian.org/debian bookworm/main amd64 Packages

So, how does all this affect the behavior of the installed CT? 

Does this suggest I should prioritize the Bookworm version of CT? Thank you for your patience in tutoring me. I do love learning new things.

On Tuesday, January 18, 2022, 01:01:50 PM EST, ciranus ***@***.***> wrote:  

Your database file is so small...... it cannot explain.

So my installed version (0.99.44-1) on this machine (running Sparky Linux 7 semi-rolling) comes from the SparkyLinux "Orion" main repo, and not from Debian Bookworm (testing).

Your orion SparkyLinux CT cherrytree depends on libfmt7. Debian Bookworm CT cherrytree depends on libfmt8.

Then Sparky 'testing' is not aligned on Debian 'testing'. Just to see report this: apt policy libfmt7 libfmt8

and check you if have problems on Debian Bulleyes (you should not).

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[ghost]

If you are not familiar with package management, I believe it is quite hard to manage a 'rolling-testing' distribution mixing repositories, and then adding complexity. The word 'testing' for Debian has not the same meaning for SparkyLinux. Same problem with Manjaro based on Arch: a lot of problems reported with Manjaro. Then tests should be done on something "stable" to understand if the "bug" comes from the application, or environment.

What you can also do, is installing cherrytree from Debian Bookworm in your so called "Sparky"...

sudo apt install cherrytree=0.99.43+dfsg-1+b1

You will get a message warning that you downgrade: just say yes.

For info, I currently use CT '0.99.43+dfsg-1+b1' from Debian, without any crash.

[Iggy64]

Thank you again for your kind suggestions. 

I continue to run  Debian Stable on one machine.  I  will start up Cherrytree on that machine and let it run with periodic autosave, to see whether there are any problems there. 

After two days, Cherrytree is still fine on this SparkyLinux machine, as long as autosave is turned off. Yes, I know that a (semi-) rolling release will force me to learn about package development and management.  That is why I am making the effort.  This minor issue with Cherrytree is the first glitch I've had with this OS.  I had the same issue with the Flatpak version of Cherrytree on Debian Buster (where no .deb was available).  I need to run Cherrytree for awhile on Bullseye, which has a proper Debian install of Cherrytree.

I guess I didn't realize that the minor problem with Cherrytree might be one of the package conflicts I should be expecting.  I contacted GitHub to determine if this was a known issue with a known solution.  But, as you have pointed me in the right direction, I will study harder and become more knowledgeable about apt.  Now I have incentive, right?  :) Thanks, again, for all your patient help.

On Tuesday, January 18, 2022, 03:11:53 PM EST, ciranus ***@***.***> wrote:  

If you are not familiar with package management, I believe it is quite hard to manage a 'rolling-testing' distribution mixing repositories, and then adding complexity. The word 'testing' for Debian has not the same meaning for SparkyLinux. Same problem with Manjaro based on Arch: a lot of problem reported with Manjaro. Then tests should be done on something "stable" to understand if the "bug" comes from the application, or environment.

What you can also do, is installing cherrytree from Debian Bookworm in your so called "Sparky"...

sudo apt install cherrytree= 0.99.43+dfsg-1+b1

You will get a message warning that you downgrade: just say yes.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[ghost]

Please note that you will have CT 0.99.30+dfsg-1 in Debian Bullseye. And can install without any risk 0.99.43+dfsg-1+b1 from Debian in your current Sparky. Then still a lot for investigation ... waiting for a crash.

[Iggy64]

Sparky has just upgraded CT to 0.99.45 (from 0.99.44).  I continue running without crashes.  Will give this a couple more days to confirm that disabling autosave eliminates the problem. Then I will try a downgrade to 0.99.43 from Bookworm, to see how stable it is with or without autosave. Also, I will finally get around to firing up the Debian Bullseye machine and testing CT with and without autosave. 

If you are interested in results, I will be glad to update you. Thanks again for all your friendly advice.

On Tuesday, January 18, 2022, 04:34:25 PM EST, ciranus ***@***.***> wrote:  

Please note that you will have CT 0.99.30+dfsg-1 in Debian Bullseye. And can install without any risk 0.99.43+dfsg-1+b1 from Debian in your current Sparky. Then still a lot for investigation ... waiting for a crash.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[Iggy64]

Just an update, in case in may be of any value to you: I continue to run Cherrytree with autosave disabled, on my SparkyLinux system.I simply remember to manually save every couple of minutes. However, today one my manual saves ([CTRL][S]) caused a crash.  The new material did NOT save at that event.  So it appears that the crash can occur upon any kind of save, not just an autosave.  Here is the dmesg report on this incident: @.***:~$ dmesg | grep cherrytree dmesg: read kernel buffer failed: Operation not permitted

I wonder what would happen if I run Cherrytree as root??Maybe you can interpret the message far better than I. I need to decide what to try next.  I could drop back to an earlier version of Cherrytree, as was suggested to me in this email chain. I also need to get my Debian Bullseye machine up and running and see if Cherrytree is stable in that environment (older kernel, older CT). My records do show that I had the crash problem with the Flatpak CT on Debian Buster (no .deb available in that repo).  Can't remember how things behaved on Bullseye, where CT was available in the repo.  So I must get that machine going again and check it out.

On Tuesday, January 18, 2022, 05:23:32 PM EST, John Slane ***@***.***> wrote:  

Sparky has just upgraded CT to 0.99.45 (from 0.99.44).  I continue running without crashes.  Will give this a couple more days to confirm that disabling autosave eliminates the problem. Then I will try a downgrade to 0.99.43 from Bookworm, to see how stable it is with or without autosave. Also, I will finally get around to firing up the Debian Bullseye machine and testing CT with and without autosave. 

If you are interested in results, I will be glad to update you. Thanks again for all your friendly advice.

On Tuesday, January 18, 2022, 04:34:25 PM EST, ciranus ***@***.***> wrote:  

Please note that you will have CT 0.99.30+dfsg-1 in Debian Bullseye. And can install without any risk 0.99.43+dfsg-1+b1 from Debian in your current Sparky. Then still a lot for investigation ... waiting for a crash.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[ghost]

Then test CT autosave in a real/true Debian. If it does not crash in Debian, make your own conclusion on rolling-testing Sparky. This thread is not about debugging Sparky. What is the Sparky process to test a package in a mixed Debian 'testing' + specific Sparky repository ? There is probably no process at all. You are the tester. Debian has his own robust test process: https://tracker.debian.org/pkg/cherrytree That's the major difference.

If you have some doubt of potential corruption of your CT data file, you can export it to a new file so that it is recreated.

Or again, you can also test 0.99.43+dfsg-1+b1 from Debian in Sparky (see previous messages).

[SwampRabbit]

Note that I am also running CherryTree on an MX Linux machine, a Debian Bullseye machine, and a Mint 19.3 machine. I have had occasional unexpected closing of CherryTree on those machines, too. All these operating systems are Debian based, and all are running fairly recent versions of xfce.

@Iggy64 I know you said stopped using MX Linux, but did you report this issue on the MX forums? What version are you using on MX?

I maintain Cherrytree in the MX repos and I monitor for users reporting issues with our versions, we have had no one report anything.

For MX-21 we currently have 0.99.41 in our Stable repo with 0.99.43 in our Test Repo.

I've built 0.99.45 for MX-21 (Debian Bullseye), but I haven't tested it yet.

[SwampRabbit]

@giuspen Last night I tested 0.99.45 on MX Linux 21 by creating a bunch of random documents (plain and encrypted), nodes, and child nodes.
I adjusted preferences, especially related to autosaves and the autosave location. I saved with CTRL+S a few times, no issues.
I left the documents open over night and Cherrytree checked to autosave but didn't need to as expected. In the morning I made some edits and autosaved worked as expected.

I did have one random crash while the miscellaneous tab in the preferences dialog was open, I believe (could be wrong) it was right after I changed the autosave location. The cherrytree debug log had nothing related to it in it.

I can start to do a proper backtracing if you think it is really needed, I typically only use the Debug log option in preferences.

[Iggy64]

@SwampRabbit, Thank you very much for your feedback.  I should clarify my situation:

• I used Mint for many years.  Recently decided to experiment getting closer to Debian.

• I set up machines with MX, Debian Buster (stable), and Sparky.

• When I went through my notes covering this past year, I found that CT closed unexpectedly once or twice on Mint, several times on Debian Buster (which required the Flatpak), once on MX, and now several times on Sparky7.  I have noted no problem on Debian Bullseye, but haven't used it much yet.

• I wasn't very concerned about the sparse incidents on Mint and MX, since they may have simply been due to human error.  (e.g., I am juggling spreadsheets, databases, CT, text editor, and maybe accidentally and unknowingly clicked the wrong "X" and closed the wrong window.)  Also, with autosave usually set to 1 minute, no big loss.

• I was disappointed with the FlatPak, so I just stopped using the Buster machine when I needed to do CT work.

• When the problem became more frequent in Sparky, I figured I would just check in with @giuspen, to see if this was a known issue with a simple fix.  He seemed to have some awareness this could happen under certain conditions, and thought it might be related to autosave. 

• On Sparky, I have now had CT quit even on a manual save.  So the version of CT from the Sparky repo, like the Flatpak I tried on Buster last year, is more of a concern.  Neither one apparently gets along 100% with the Debian base programs.  I may try switching to the CT from the Debian Bookworm repo, and see if that gets rid of the problem. As stated, I am trying to get closer to Debian, and figure that Debian itself, or MX, or Sparky are my best options.  I don't mind at all running into some glitches along the way, as it forces me to learn many new things I should have studied long ago.  And I just plain enjoy learning. I think MX is great, and I just may end up gravitating there.  But I need more experience with vanilla Debian and with Sparky before deciding.  I may even end up with different OSes on different machines, just to spice things up and keep learning. Thanks, again, for taking time to contribute to my education!And thanks for your work on MX.

  On Wednesday, January 19, 2022, 06:31:49 PM EST, SwampRabbit @.***> wrote:

Note that I am also running CherryTree on an MX Linux machine, a Debian Bullseye machine, and a Mint 19.3 machine. I have had occasional unexpected closing of CherryTree on those machines, too. All these operating systems are Debian based, and all are running fairly recent versions of xfce.

@Iggy64 I know you said stopped using MX Linux, but did you report this issue on the MX forums? What version are you using on MX?

I maintain Cherrytree in the MX repos and I monitor for users reporting issues with our versions, we have had no one report anything.

For MX-21 we currently have 0.99.41 in our Stable repo with 0.99.43 in our Test Repo.

I've built 0.99.45 for MX-21 (Debian Bullseye), but I haven't tested it yet.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[SwampRabbit]

@Iggy64 until giuspen or someone else can validate this is a issue for all Debian based distros, it may just be limited to Debian Testing or Sparky Linux 7 ((Semi-)Rolling)), which is based on Debian Testing branch.

If it cannot be validated as a general Cherrytree issue, the issue needs brought up to the Sparky Linux community first, then maybe Debian after that. But the Debian maintainer wants to stop maintaining Cherrytree, so it may be awhile either way.

This sort of scenario is exactly why many applications and their dependencies are in Debian Testing branch and not the Stable branch. It may be a issue with the newer Cherrytree Debian package, it may be an issue with a dependency, or a combination of both. When you combine that with child distros packaging things, it complicates it more like @ciranus said.

Again, if it was me, I would bring it up to the Sparky Linux community (forums, Facebook, whatever) first. Others may be having the issue as well and the Sparky Linux community seems pretty responsive.

I'll be having 0.99.43 moved to the MX Stable repo and get 0.99.45 added to our Test repo in the coming days.

[Iggy64]

@SwampRabbit, Thanks for your additional thoughts and suggestions.  I have already replaced the Sparky Orion 0.99.45 with the Debian Bookworm 9.99.43, and am monitoring to see if random crashes will still occur.  Once I establish that, I will contact the Sparky team to provide the entire picture for their review (if they have time). I want to restate that I definitely have had this crash problem with Sparky Orion 0.99.44 and 0.99.45, as well as with the Cherrytree Flatpak I used last September (while running Debian Buster, which did not have its own package for Cherrytree). As I already mentioned, the one or two crashes I had with Mint and MX could possibly been due to human error (such as absent-mindedly clicking the close button on the wrong window).  Those occurrences were highly isolated, so I didn't think much was systematically wrong back then.  However, when I ran into frequently occurring issues with the Flatpak and the Sparky package, I wondered if those few earlier occurrences might have some relevance.  After further thinking and discussion, it seems far more likely those Mint and MX happenings were human error. I'll check back in with feedback on running Bookworm's package on Sparky 7, plus any commentary from the Sparky folks. Thanks, again, for your kind support.

On Thursday, January 20, 2022, 02:38:24 PM EST, SwampRabbit ***@***.***> wrote:  

@Iggy64 until giuspen or someone else can validate this is a issue for all Debian based distros, it may just be limited to Debian Testing or Sparky Linux 7 ((Semi-)Rolling)), which is based on Debian Testing branch.

If it cannot be validated as a general Cherrytree issue, the issue needs brought up to the Sparky Linux community first, then maybe Debian after that. But the Debian maintainer wants to stop maintaining Cherrytree, so it may be awhile either way.

This sort of scenario is exactly why many applications and their dependencies are in Debian Testing branch and not the Stable branch. It may be a issue with the newer Cherrytree Debian package, it may be an issue with a dependency, or a combination of both. When you combine that with child distros packaging things, it complicates it more like @ciranus said.

Again, if it was me, I would bring it up to the Sparky Linux community (forums, Facebook, whatever) first. Others may be having the issue as well and the Sparky Linux community seems pretty responsive.

I'll be having 0.99.43 moved to the MX Stable repo and get 0.99.45 added to our Test repo in the coming days.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[giuspen]

@SwampRabbit I will try to enable autosave and then change the autosave location and see if I can reproduce the crash. @Iggy64 building from source code is documented on https://github.com/giuspen/cherrytree#building-cherrytree-on-ubuntu and the build.sh I mentioned will make sense if you read there. If you build successfully from the source code you can then try to run under debug as I indicated before, I can get back on that after and if you successfully build from sources

[Iggy64]

@giuspen Thank you for the additional information. I should restate a couple of points that might be of interest to you: -  While running 0.99.45 from the Sparky Orion repo, I had occasional crashes not only on autosave, but also once on a manual save, while autosave was turned off.  The system feedback on that manual-save crash was @.***:~$ dmesg | grep cherrytree dmesg: read kernel buffer failed: Operation not permitted

• Back in September, I used the Cherrytree flatpak on Debian Buster, since Buster did not offer its own package.  I had frequent crashes with the flatpak.  I also had a problem with inserted objects in that flatpak.
• In current Sparky machine, I have removed the Sparky Orion 0.99.45 and installed 0.99.43 from Debian Bookworm, to see if that eliminates the problem.

@.:~$ apt policy cherrytree cherrytree:   Installed: 0.99.43+dfsg-1+b1   Candidate: 0.99.45-1   Version table:      0.99.45-1 1001        1001 https://repo.sparkylinux.org orion/main amd64 Packages   0.99.43+dfsg-1+b1 500         500 http://deb.debian.org/debian bookworm/main amd64 Packages         100 /var/lib/dpkg/status

I note that the Bookworm package has been repackaged by Debian to conform with DFSG.  Perhaps that is something lacking in the Flatpak and Sparky versions?  It will be interesting to see if this version is completely stable.  I recall that Cherrytree from the Bullseye repo seemed very stable.

I will definitely read the instructions on how to due the build from source and see if I can get you any good debugging feedback.

Many thanks for your support!

On Friday, January 21, 2022, 05:30:23 PM EST, Giuseppe Penone ***@***.***> wrote:  

@SwampRabbit I will try to enable autosave and then change the autosave location and see if I can reproduce the crash. @Iggy64 building from source code is documented on https://github.com/giuspen/cherrytree#building-cherrytree-on-ubuntu and the build.sh I mentioned will make sense if you read there. If you build successfully from the source code you can then try to run under debug as I indicated before, I can get back on that after and if you successfully build from sources

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[giuspen]

If you can build from sources then note that you can also create your own Debian package with "./build.sh deb" - this also documented just after instructions how to build from sources. I shall add also instructions on how to provide a backtrace of a crash via gdb

[SwampRabbit]

@giuspen while testing the 0.99.45 package I build for MX-21 (Debian 11) it continues to crash somewhat randomly but related to autosaving. I was typing in a node and it just closed.

The Debug log option in preferences doesn't seem to log the crash or anything related to it.

The only thing thing I can think of is that our package is based on the actual upstream Debian packaging rather than what you have.

I'm going to do a build directly off of Master and see if it shows the same symptoms. If it doesn't then the issue may be limited to builds based on the actual upstream Debian packaging. If it does, then I'll do a proper backtrace for you.

[Iggy64]

@giuspen

Thank you for all the additional instructions and advice.  I enjoy learning new things, and I will do my best to provide additional feedback to you on running Cherrytree on Sparky Linux 7 (based on Debian Testing). As described earlier, I had the crashing problem with Cherrytree 0.99.44 and then with 0.99.45 (after a routine upgrade) from Sparky's own repository.  Since that time, I have removed Sparky's package and  installed 0.99.43 from Debian Bookworm (Testing).  That has been running without problem for three days. So, for me, the crashing problem occurred with Sparky's packages, and with the Flatpak I tried back in September (while running Debian Buster).  I had no problem with the Cherrytree package in Debian Bullseye (Stable), and am running successfully with 0.99.43 from Debian Bookworm (Testing). Thanks, again, for your generosity in helping my find my way.

On Monday, January 24, 2022, 02:17:07 PM EST, SwampRabbit ***@***.***> wrote:  

@giuspen while testing the 0.99.45 package I build for MX-21 (Debian 11) it continues to crash somewhat randomly but related to autosaving. I was typing in a node and it just closed.

The Debug log option in preferences doesn't seem to log the crash or anything related to it.

The only thing thing I can think of is that our package is based on the actual upstream Debian packaging rather than what you have.

I'm going to do a build directly off of Master and see if it shows the same symptoms. If it doesn't then the issue may be limited to builds based on the actual upstream Debian packaging. If it does, then I'll do a proper backtrace for you.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[ghost]

@Iggy64

While running 0.99.45 from the Sparky Orion repo

For clarification, the CT package found in Sparky repo [ cherrytree_0.99.45-1_amd64.deb ] is a copy of cherrytree_0.99.45-1 file made by giupsen @ppa

$ sha256sum cherrytree_0.99.45-1_amd64.deb
b3fc3713e86b7d1bf18c936447752bcc2815d13a6e9b73c1ff09fc208ab2d920 

dmesg: read kernel buffer failed: Operation not permitted

SECURITY_DMESG_RESTRICT, prevents non-root users reading the kernel log by default You can execute this to see next potential kernel messages: sudo sysctl kernel.dmesg_restrict=0

Could a wrong 5.15 kernel testing configuration and recent update explain some crash ? To be investigated with Sparky as soon as you read kernel messages. Testing is testing.

I wonder what would happen if I run Cherrytree as root ?

Don't do this; never do this (out of scope here to detail why).

I note that the Bookworm package has been repackaged by Debian to conform with DFSG

Debian does not unpack/repack anything. Debian builds a Debian package from source, according to Debian rules.

And finally, could you please stop quoting every reply messages which make this thread difficult to follow (even better, clean quotes of your previous messages....).

@giuspen Debian CT testing package now depends on libfmt8, and Ubuntu has then updated their Jammy CT package accordingly on Dec 24th.

cherrytree (0.99.43+dfsg-1build1) jammy; urgency=medium
  * No-change rebuild against libfmt8
 -- Graham Inggs <ginggs@ubuntu.com>  Fri, 24 Dec 2021 14:18:19 +0000

changelogs.ubuntu.com/changelogs/pool/universe/c/cherrytree/cherrytree_0.99.43+dfsg-1build1/changelog

In order to limit CT packages diversity, and limit discrepancy with packages built by Debian and Ubuntu, I think 0.99.45-4 from ppa should depend on libfmt8 and not libfmt7 anymore. Is an 0.99.45-4 update possible ? I wonder if a potential regression is not related to these freshly added libfmtx dependencies

@SwampRabbit As you know, Debian backport is poor and this is a problem for Debian stable users. This is why one of your MX collegue [stevepusser] is supporting an 'unofficial' Debian backport repo. This is accepted by Debian. Who needs PPAs? I have my own multimedia+ repo! - stevepusser - Debian User Forums

Would you share the idea that instead of having 20 more or less identified CT packages in 20 different repos, it would be an improvement to share Debian compatible CT packages in one repo only ? Each Debian derivatives could just 'copy' these packages in their repos, instead of approximately correctly building according to Debian rules. This is just an open investigation. -->> openSUSE:Build Service Debian builds - openSUSE Wiki

[Iggy64]

I'm sorry that I have caused problems with my replies in this thread.  I am completely new to GitHub, and don't know how this is supposed to be done.  I am responding as I would normally do to an everyday email, as that is all I know. I guess I have gotten in over my head, and I will cease posting anything here until I learn the correct way of doing so.  I am not a programmer, and probably should never have posted here to begin with.  I only did so because I wanted to ask giuspen if my crash issue had a known solution.  His web page directed me to GitHub,  and  I probably shouldn't have gone there, as I am just an everyday user, not an expert at all.

Meanwhile, please accept my gratitude for all the help and suggestions.

On Monday, January 24, 2022, 03:57:54 PM EST, ciranus ***@***.***> wrote:  

@Iggy64

While running 0.99.45 from the Sparky Orion repo

For clarification, the CT package found in Sparky repo [ cherrytree_0.99.45-1_amd64.deb ] is a copy of cherrytree_0.99.45-1 file made by giupsen @ppa $ sha256sum cherrytree_0.99.45-1_amd64.deb b3fc3713e86b7d1bf18c936447752bcc2815d13a6e9b73c1ff09fc208ab2d920

dmesg: read kernel buffer failed: Operation not permitted

SECURITY_DMESG_RESTRICT, prevents non-root users reading the kernel log by default You can execute this to see next potential kernel messages: sudo sysctl kernel.dmesg_restrict=0

Could a wrong 5.15 kernel testing configuration and recent update explain some crash ? To be investigated with Sparky as soon as you read kernel messages. Testing is testing.

I wonder what would happen if I run Cherrytree as root ?

Don't do this; never do this (out of scope here to detail why).

I note that the Bookworm package has been repackaged by Debian to conform with DFSG

Debian does not unpack/repack anything. Debian builds a Debian package from source, according to Debian rules.

And finally, could you please stop quoting every reply messages which make this thread difficult to follow (even better, clean quotes of your previous messages....).

@giuspen Debian CT testing package now depends on libfmt8, and Ubuntu has then updated their Jammy CT package accordingly on Dec 24th. cherrytree (0.99.43+dfsg-1build1) jammy; urgency=medium

• No-change rebuild against libfmt8 -- Graham Inggs @.***> Fri, 24 Dec 2021 14:18:19 +0000

changelogs.ubuntu.com/changelogs/pool/universe/c/cherrytree/cherrytree_0.99.43+dfsg-1build1/changelog

In order to limit CT packages diversity, and limit discrepancy with packages built by Debian and Ubuntu, I think 0.99.45-4 from ppa should depend on libfmt8 and not libfmt7 anymore. Is an 0.99.45-4 update possible ? I wonder if a potential regression is not related to these freshly added libfmtx dependencies

@SwampRabbit As you know, Debian backport is poor and this is a problem for Debian stable users. This is why one of your MX collegue [stevepusser] is supporting an 'unofficial' Debian backport repo. This is accepted by Debian. Who needs PPAs? I have my own multimedia+ repo! - stevepusser - Debian User Forums

Would you share the idea that instead of having 20 more or less identified CT packages in 20 different repos, it would be an improvement to share Debian compatible CT packages in one repo only ? Each Debian derivatives could just 'copy' these packages in their repos, instead of approximately correctly building according to Debian rules. This is just an open investigation. -->> openSUSE:Build Service Debian builds - openSUSE Wiki

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[SwampRabbit]

@SwampRabbit As you know, Debian backport is poor and this is a problem for Debian stable users. This is why one of your MX collegue [stevepusser] is supporting an 'unofficial' Debian backport repo. This is accepted by Debian. Who needs PPAs? I have my own multimedia+ repo! - stevepusser - Debian User Forums

Would you share the idea that instead of having 20 more or less identified CT packages in 20 different repos, it would be an improvement to share Debian compatible CT packages in one repo only ? Each Debian derivatives could just 'copy' these packages in their repos, instead of approximately correctly building according to Debian rules.

@ciranus I don't see how any of this has anything to do with what we (MX) builds for our own repos.

The Debian maintainer doesn't want to maintain it anymore. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003512 We HAVE to build our own packages for now.

What Steve builds in that OBS repo has nothing to do with what he or I put in the official MX repos.

It is not correct to "just copy" binaries into an official repo, it needs to be built from source and the source files need included. We don't "approximately" build packages. We build our packages no different than Debian.

If the newer version of libfmt8 needs to be used then that is going to be a problem except for bleeding edge or unstable distros. For anything based on Bullseye its a problem because libc6 (2.33) is a listed depend for it, and libc6 (2.33) isn't in Debian Bullseye and won't be. Debian Testing and Ubuntu both also build Cherrytree with libc6 (2.33). Maybe libfmt8 can be built and run with libc6 (2.31) from Bullseye, but that will have to be tested first and it complicates things more.

I have the latest master built for a Debian Bullseye base, I just need to test it. If there are still issues, we take it from there. More than likely a proper bacetrace needs done.

Edit for typo

[ghost]

@SwampRabbit I did not make any confusion between Sparky and MX. MX is based on Debian stable. You make your own CT 0.99-45 package under investigation in you testrepo No problem at all with this. I trust your investigations on CT 0.99.45 in a 'stable' environment.

Would you trust any conclusion coming from CT Ubuntu ppa package built for Ubuntu focal tested in a mixed Debian stable+testing ? I don't. It looks like Sparky orion situation (I've checked CT Sparky package in detail), and I don't understand what is tested.

Iggy64 is just learning Debian package management in already a Testing environment !! I consider it is far too premature to ask him to 'make a build, a package' in this fuzzy environment, and that Iggy64 will have some difficulty to choose between libfmt7 and libfmt8 dependency. Learning Debian/Linux takes some time (hours/weeks/months/years....).

At this moment, there are no 0.99.45 CT packages available even for test or investigation for Debian testing, and package 0.99.45.4 from ppa cannot be installed in Debian (I mean for test/investigation only...), because latest Ubuntu dpkg is now using zst compression as default instead of xv compression. Is asking each user to make his own build the right solution ? I must say I am not convinced in a Debian environment. A clearly referenced test package should be available somewhere.

My concern was just about how to facilitate a clearly identified repo with 2 CT Debian packages: 1] compatible stable 2] compatible testing/unstable

This is even more justified if you say "The Debian maintainer doesn't want to maintain it anymore". Does it mean current maintainer will be simply replaced, or Debian will drop CT from their repo ? not clear to me. Hopes it clarifies.

[SwampRabbit]

This is even more justified if you say "The Debian maintainer doesn't want to maintain it anymore". Does it mean current maintainer will be simply replaced, or Debian will drop CT from their repo ? not clear to me.

No they will not just be "replaced", someone must volunteer to take up maintaining it in their free time. Debian will not drop Cherrytree, but there may not be new packages in Debian Testing or Sid for awhile until someone volunteers.

Cherrytree is a good and important application, I'm sure it won't be unmaintained long at the Debian level.

[ghost]

Then, in the meantime, could we consider that CT for Debian stable, packages found @ /mx/repo/pool/main/c/cherrytree for stable @ /mx/testrepo/pool/test/c/cherrytree for test only are the best option for "all" Debian stable users ? I would say intuitively.... : yes.

The most difficult is for Debian testing/unstable (avoiding distributions mixing stable+testing packages). Last official Debian release, which works fine: 0.99.43. Without real user feedback for next releases, contribution to next releases maturity will be lowered. I still think a clear identified CT Debian testing package should be identified somewhere (but not in ppa to avoid confusion with ubuntu).

[SwampRabbit]

Then, in the meantime, could we consider that CT for Debian stable, packages found @ /mx/repo/pool/main/c/cherrytree for stable @ /mx/testrepo/pool/test/c/cherrytree for test only are the best option for "all" Debian stable users ? I would say intuitively.... : yes.

No, Debian users should stick to what is in the actual Debian repos

Last official Debian release, which works fine: 0.99.43.

0.99.43 was the last official Debian Testing release, I build and tested this version on MX-21 (Debian Bullseye), it has a issue crashing randomly still.

It may be related to needing libfmt8 like you hypothesised, but it needs tested. I will be working on checking Cherrytree later today when I get some free time.

[ghost]

No, Debian users should stick to what is in the actual Debian repos

Of course, but I mean for Debian stable users looking for reliable CT releases above 0.99.30 (last Debian stable one).

[SwampRabbit]

@giuspen attached is a backtrace for you, this is from Cherrytree 0.99.45 + git master from 20220123, built and running on MX-21 (basically Debian 11.

Earlier today it would crash and close right away from what appeared to be when it autosaves, but I wasn't debugging yet.

When ran with gdb this time it froze, but didn't close like it was before.

cherrytree_0.99.45+git20220123_master_build_backtrace.txt

I have the instance of Cherrytree still running and won't shut it down until I hear back from you, please let me know if you want me to do any further debugging

[burundian20]

I am using Ubuntu and I have NEVER had CherryTree close unexpectedly nor crash either ....

[ghost]

0.99.46 UPDATE

Test made with cherrytree_0.99.46-2_amd64.deb from ppa in Debian bookworm[=testing] (no dependency or installation issue). 0.99.46-2 depends on libfmt8.

cd /tmp
wget https://launchpad.net/~giuspen/+archive/ubuntu/ppa/+files/cherrytree_0.99.46-2_amd64.deb
sudo dpkg -i ./cherrytree_0.99.46-2_amd64.deb
sudo apt install -f

No crash.

@SwampRabbit This thread title is totally misleading. You should start fresh 0.99.46 MX investigations in a new thread, if still necessary.

I would warmly recommend to close this thread.

[SwampRabbit]

@ciranus the title isn't misleading, the OP had issues with several Debian based distros, MX being one of them

I don't know why you're @ing me, I'm not the creator of the thread in the first place

please don't @ me @ the actual OP, @Iggy64 .... I get enough notifications for all the packages I maintain

the Launchpad PAA is built against Ubuntu, Ubuntu PPAs can't be 100% guaranteed to work on Debian based distros, totally different OS bases, and adding Ubuntu PPAs to Debian can lead to issues short term and long term no one that wants something available cross-distro using Launchpad... and that's half the reason package maintainers have to change or fix builds to work on their distros

when I get time to build and test the new Cherrytree, I'll create an issue if there are issues, but again this isn't my issue

[ghost]

Until now, no CT crash has been reported in any Debian or Ubuntu derivatives using Debian or Ubuntu or ppa .deb builds.

»»» List of Debian-based Linux distributions

The Launchpad PAA is built against Ubuntu, Ubuntu PPAs can't be 100% guaranteed to work on Debian based distros

Of course, who said the opposite ? It does not prevent to use ppa CT builds for test, to track crashes, investigate, compare, assuming you know what you do, with a basic dependency check before installation. Example: I've checked specific compatibility of cherrytree_0.99.46-2_amd64.deb from ppa with booksworm[testing], and did not make any generality, and have previously highlighted problems with 0.99.45 from ppa for Debian (I've never used 0.99.4/5).

I've never seen a CT ppa package able to break Debian system. If the CT ppa build does not work, the easy fallback is just to reinstall a CT Debian build. Never seen a Debian user not able to deal with this. If CT ppa builds are sometimes used in Debian, the reason is probably that the expected Debian build version is not available....

It's not so easy to track issues with X different builds made by X people, because no guaranty these builds are identical and correct (waste of time): »»» ReproducibleBuilds/Howto - Debian Wiki

As already stated, the ideal case would be to get available somewhere CT Debian test builds, used as reference to track issues (a kind of Debian ppa): 1] compatible stable 2] compatible testing/unstable

Derivatives:

• Sparky/Orion: wrong package in repository/ solved one month ago

Iggy64 > I then installed v. 0.99.43 from the Debian Bookworm repo. This runs perfectly fine. Sparky dev > Cherrytree removed from Sparky repos.

• MX: CT Debian stable package should be compatible with MX based on Debian stable. MX specific build potential issue cannot be mixed with anything else. Why MX needs a specific CT build is not clear to me, but don't want to debate this. If the answer is that Debian is a bit slow to propose updates, or CT updates are not proposed in Debian stable backports, why not organizing a dev pool to create Debian builds for all Debian derivatives (outside Debian repositories if too complicated with Debian).

In order to be consistent with my recommendation to close this thread (i.e. Iggy64 or Giuspen ), this is my last contribution to this issue.