Yes, I was thinking about something similar too (= to use the original software in docker/appimage/whatever), because - I guess - we will never know if the result (conversion to python3) was perfect (= good enough?) and works as expected.

Hya

Thanks for replies.

I guess it may be a good time to change my mind. I will use python2 version for a while. To keep data, I will code from scratch in C or ruby.

Quote form this thread.

Yes, functionality of 2/3 product can be a big issue. Unexpected (implicit) auto-conversion is extremely difficult to take care. (also urllib, urllib2 back to urllib with different parameters!) Lexically correct (implies semantically not) code is the enemy.

I greatly appreciate all suggestions and comments.

cheers

Hya,

With a lot of help from community, bibus transition to python3 may work. Libreoffice and LyX connection works for me. Pubmed download works. eTBlast is dead, so removed. MySQL, automatic file detection and MicrosoftWord connection are not checked. Not even beta version! It is nothing more than it works on my Debian testing(amd64).

Is anybody interested under GPLv2 or v3?

If I follow the sourceforge rule, I should take over the inactive project, but I do not think I am capable to be a maintainer.

cheers

Why not?

Thank you for your comment. But, I do not have any knowledge/experience except for Debian, no resource.. I even have some trouble with Debian. What I have is nothing more than "it works on my Debian"

cheers

I have to concur with ondoho. Stick with Python2. The best case for this kind of scenario is to make up/build a completely self-contained package, one which contains absolutely everything required to run it.....i.e., it does NOT need to go scampering off into the system to search for dependencies. If done properly, the ONLY system 'dependencies' would be the glibc & libstdc++.so.6, and these are usually backwards-compatible.

It can take some figuring-out, but it's immensely satisfying to see the results of your own labours burst into life at the click of your mouse.

A 'portable' format of some kind would be absolutely ideal for something like this. AppImages are perfect; they unpack themselves into, and run from /tmp for the duration. They also don't require a pre-existing framework in order to function, in the way that Snaps & Flatpaks do. I create a lot of portable packages in this manner for the Puppy Linux community, and one of our members has developed his own AppImage packaging scripts, which work beautifully.

Just a suggestion. Feel free to ignore it if not applicable.

Why would you think that other package maintainers are any better at it than you? You don't have to be a coding genius, competent in multiple disciplines.....all you need is the enthusiasm, and patience, to make sure that the package, as available for download, keeps working. An AppImage, particularly, if built correctly, will work & run anywhere....because it doesn't rely on any system dependencies.

Mike.

Thank you for your comment. My experience and knowledge about system are not as good as yours. I will check how to make a package which includes whole dependencies.

As Mike says, enthusiasm and patience/determination is enough to get started - the experience and knowledge come as you do it.

Also, maintaining a project does not mean you need to do everything the previous version did, nor that you need to do everything people might ask for - it's absolutely fine to say that you're only working on fixing the parts that interest you, and the rest is either out of scope or up to other people to work on.

As for only working on your machine, high-level languages like Python provide a lot of compatibility built-in - it's not perfect (and it's annoying when to realize you've been using something added to Python 3.8 but want to support Python 3.6), but the fewer dependencies you have (i.e. the more you use the standard library, or other zero/low-dependency modules), the less you need to worry about platform-specific issues.

Heh. I don't know as I'd agree with you there on that one. I'm the "eternal noob"; I see myself as something of a 'bodger'.....an enthusiastic 'tinkerer', at best. Some of the hacks I employ in getting stuff to do what I want it to would in all likelihood make your hair curl. They're not tidy, and certainly not elegant.....but they work.

I do, however, constantly review what I publish, and am always trying to find better ways of making things run. I'm not any kind of an 'expert', but I do at least have the enthusiasm to try and improve things. Coding does not come easily to me - I've never been good with languages, and coding languages are no different! - but when I look back at my early attempts, as compared to what I put out nowadays, even I'm quite impressed at the improvement over the last 8 years or so.

And I'm NOT easily impressed..!

Enthusiasm counts for a hell of a lot.....and this, coupled with positive feedback from your 'target' audience, along with constructive criticism (which I've never minded), will carry you a long way. You may even find you enjoy the process.


Mike.

Taking on a task that is challenging will do just that. Challenge you to learn and do better. I cannot think of a better way to learn something new (and how to do it the best way possible) than to do something you know others rely on.

My policy has always been that initially I develop/build packages for my own use. When I'm completely happy with them, only then am I content to "share". Once the package is in the public domain, as it were, I then often keep thinking up ways to improve them.....

It's an on-going process, but a satisfying one.

Mike.

Thamk you for your comments.

About a package with python2: Dependency tree itself may not be complicated. Several suggesgted packages may not. I need to figure out which one is used. One problem is that current LibreOffice does not work (connect.)

About a maintainer: Now, I know that maintainer need not to be perfect. As GPL says, program is supplied "as is ... without warranty"

cheers

Just as a refresher so I don't need to review 27+ posts and try and identify the issue.
What distro and version are you using.?
Why are you still using python 2?

LibreOffice has been kept up to date and works on all versions of Linux I have used, to it seems you might be trying to use a current version of LO on a machine that will not support the up-to-date dependencies involved.

Hya

My setup is Debian AMD64 testing.

Currently, I do not need to use python2, because 2to3 transition of bibus looks good for me. To use original bibus (or to be correct: to keep using its data) I used python2.

I tried several other reference managing programs. My conclusion is that bibus is more flexible interface, simple data structure, security and speed compared to other ones. So, I decided to 2to3 transition.

LibreOffice used to communicate with bibus, at OpenOffice.Org era. I have not investigated this, because it works with converted bibus.

To appreciate to a lot of help from community, I am thinking to share converted bibus under GPL.

Thank you for your comment.

cheers