LMDE 6 upgrade still fails on sticky.py error

[TRH-TRH]

My upgrade to LMDE 6 "Faye" failed because of a syntax error in the file "sticky.py". Previous solutions to this inexcusable problem don't work for me. I need a sticky.py file that will execute.

One previous solution was to remove the sticky package before running the upgrade tool. Too late!

Another solution was to upgrade the Python package before running the upgrade tool. Too late!

Another solution was to edit the sticky.py file to comment out the syntax error and replace it with new code. I can't do that because the file is missing!

Can someone please post a sticky.py file that I can install on my system so I can finish this upgrade?

And can someone PLEASE inform the LMDE 6 team to fix this problem once and for all? Unbelievable that it's been aborting upgrades since last year. I already lived through computing in the 1970s once. I needn't do it again.

[Jeremy7701]

Simply install the sticky package from the repositories - you can do it with synaptic for a GUI solution. In the 1970's you wouldn't have been able to download anything at all.

[TRH-TRH]

Thanks for your advice, but installing the sticky package doesn't work. Error message: "No such file or directory: '/usr/lib/sticky/sticky.py'"

Yet the directory DOES exist, with several files. Just not the file "sticky.py". Apparently that's the only file I need. Mintupgrade can't run without it.

After further research, I've learned that "sticky" is a Post-It Note program. Seriously? A Post-It Note program crashes a major OS upgrade? And crashes the OS on a syntax error that in olden days would never have survived compilation?

I've lost count of the number of programming languages I've used, but Python isn't one of them. I am shocked that a language update would change the basic syntax so radically that it breaks existing software. Programs I wrote decades ago are still running fine on modern systems. If the Python maintainers insist on mucking around with the syntax, they should rebrand the language. I suggest "Anaconda." Naming this unstable language after deadly snakes is slyly appropriate.

Perhaps the youngster who wrote sticky.py in Python should have used a more stable language, such as ... COBOL.

And FYI, we were uploading and downloading data in the 1970s, albeit at 300 baud acoustic.

I still can't fix this silly sticky problem, and now my computer is crippled. Can someone please post the sticky.py program so I can try to install it manually -- in the sticky directory that does indeed exist? And please post the patched code so the Post-It Notes won't crash me again.

[TRH-TRH]

Whew! I finally restored my Python-crippled computer to normal operation, upgraded to LMDE 6 Faye. But it wasn't easy.

I found the missing program I needed -- sticky.py -- on another of my Linux computers. That machine is running Ubuntu-based Linux Mint, not Debian Linux Mint, but I figured the sticky-note program would be the same.

Copying that file to my crippled computer was difficult because the GUI was mostly nonfunctional and terminal windows were reluctant to open.

After successfully copying the file to the /usr/lib/sticky directory, I restarted mintupgrade. It stalled on the same syntax error in sticky.py as before.

This time I opened sticky.py in nano to implement the workaround suggested in another thread (#79): comment out an entire Python method from lines 764 to 774. Note that this was my first exposure to Python source code. Nano doesn't display line numbers, but I found the dbus_method_callback method. Having already learned that Python's creators enjoy inventing new syntax to do the same old things, I assumed that the comment symbol wouldn't be // or /* or <!-- or even REM. Yep, it's #, and each line of code requires its own symbol. Good thing only 11 lines need to be nuked.

That done, I saved the lobotomized program with nano and restarted mintupgrade. This time it paused warily on sticky.py but eventually passed it.

Mintupgrade took a long while to install LMDE 6, as expected, but it finished successfully and I rebooted from the command line. The restart took about two minutes, same as before. I haven't used the upgraded system for very long but it seems to be okay.

I'm tempted to remove the "sticky" package -- I've never used the sticky-note widget -- but I'm afraid it might blow up the universe or something.

Now will someone PLEASE fix this problem for other people who won't or can't tolerate this much trouble? At minimum, mintupgrade should check to see which version of sticky.py or Python is installed before starting the process.

[Jeremy7701]

Most (nearly all?) Linux scripting languages and configuration files use # to signify a comment. Suggest you run a test upgrade in future against a relevant VM version - I always do. I'm sure the sticky thing will have been fixed long before LMDE7 appears, although its a bit surprising that the bug in the upgrade program hasn't already been fixed.

[TRH-TRH]

Jeremy, thanks for your suggestion to test future upgrades on a VM first. It's good advice, but I would have to install a VM on my Windows PC, because my Macintosh and both of my Linux machines are too old and slow to tolerably run a VM. My LMDE laptop is 10 years old and is now exclusively my travel computer, because it's more or less expendable. It's too slow for Windows, hence LMDE.

My other Linux machine is a 17-year-old Macbook! It's running Ubuntu-based Linux Mint. As I said in my previous post, it was my savior yesterday when I found an uncorrupted sticky.py file on it.

I didn't guess that Python uses the hashmark (#) for comments because I mistakenly thought Python was a general-purpose programming language, not another Linux scripting language. Don't we already have Bash?

Although I appreciate the hard work that went into mintupgrade, I'm still astonished that a major OS update has a critical dependency on 11 lines of deprecated code in a sticky-note widget. And even more astonished that this problem has persisted since last year. Oh, well. At least my LMDE6 machine is up and running now. Thanks again.