Good day-
I finally got the documentation for my package squared away, along with
support for _both_ gitlab and github interoperability (with github
having a much more idiosyncratic REST API...)
* My package's documentation is here: https://repliversion.org
* My package's repo is here: https://git.repliversion.org
* The .deb for my package is here: https://deb.repliversion.org
The deb for my package works, but since it is the first one I have ever
assembled, there is a good chance it has deficiencies.
What are the next steps to getting this into unstable?
I think this package will be appreciated because EASY versioning is
something that's missing from desktop Linux, while competing desktop
OS's already have it (I believe the fact they do points to ts importance...)
[Note that the versioning works even in shell/non-desktop.]
On 10/3/24 09:49 PM, Antonio Russo wrote:
On 10/3/24 14:02, stev...@osfda.org wrote:
I have a package that manages file versioning that has been alpha
tested with:
* bookworm
* KDE plasma
I apologize if I'm overlooking it, but could you please link to the
source code
of this project, as well as your packaging of the deb?
Think like: Windows File versioning/Mac Revert. It is based on
inotify. [Before you think that couldn't be reliable, hear me out for
a discussion of safeguards I take to make it so -at some future point
I could eventually do the heavy lift to implement it as a shim to the
EXT4 driver., but for now: it works..]
This sounds interesting!
While there are paid backup products that do this, there's no free
solution, ready to install from the stable repos (you can suggest any
that I might have missed, and I will confirm or show how they fall
short...) Presently Windows and Mac users at this point expect
integrated versioning to just be part of a desktop OS. With the rise
in Linux desktop adoption, having access to such a product that they
have come to rely on will help reduce the friction for some users
migrating to it.
I disagree here; there are tools that do this. Git and ZFS and sanoid
come to
mind, but these are not terribly new-user friendly.
There's also Nextcloud [1], (granted, the server is not packaged in
stable).
I would like to get a sponsor for this package. I have a press
article for it, and it will have a dedicated vanity domain
(purchased, org+com...) I do not expect to have it included with
KDE/plasma to start, but it would greatly stimulate interest in it if
it could be readily accessible as a separate package, and it will
also facilitate getting people to field-test it out even further (for
later adoption as an "extra" in the KDE install?)
This package could eventually be adapted to gnome and other desktops,
but to start I have focused on KDE/plasma (it has integration with
the "Dolphin" file manager, though command-line operation is
eminently usable...)
The code base is written in python, and a service uses code generated
by cython at the time its package install is done (you can also opt
to have the service run using the python codebase, should more
extended traceback analysis ever be needed...)
I have assembled a prototype deb package file, and ran it through
linitian. I will have a few brief questions about standards for
whoever my sponsor ends up being.
If this plane takes off, I will put up a wiki for its manual on its
vanity domain, and its README and [pyqt5] GUI will have a link to it.
I could also opt to use Sphinx <https://www.sphinx-doc.org/en/master>
for its documentation, which I have used before and I readily admit
has a sharp look; but mediawiki
<https://www.mediawiki.org/wiki/MediaWiki> can be helpful in
garnering the assistance of others with documentation at some later
point ("many hands make light work...")
I presently have a nice article with screenshots (as of yet
unpublished, pending its hopefully eventual appearance in bookworm's
stable repo...) *I would appreciate if someone from the KDE/plasma
team sponsor this package for inclusion to the stable repos at the
first practical opportunity; again, NOT for immediate inclusion into
KDE/plasma.* After months of field testing, perhaps it can
*/eventually/* be considered worthy enough for KDE extras...
I recommend reading [2] if you plan on maintaining this package
yourself in
Debian.
Respectfully,
Steve Boriotti
Senior Developer, full stack
------------------------------------------------------------------------
About me: I am a developer with over 30 years commercial experience
(mostly in fintech...) Back in the 2000s I did code auditing of the
open source Cyrus mail server <https://www.cyrusimap.org> (using
"RATS
<https://code.google.com/archive/p/rough-auditing-tool-for-security>"...)
I also happen to be a postgres advocate, and have published a python
tool for generating self-signed certificates for pgadmin (a rather
hairy multistep process when done manually...)
[https://gitlab.com/osfda/pg_ssl_init] I even furnished patches on
StackOverflow to remedy bugs in the new asynchronous psycopg3
<https://www.psycopg.org/psycopg3> driver.
Best,
Antonio
[1]
https://docs.nextcloud.com/server/20/admin_manual/configuration_files/file_versioning.html
[2] https://www.debian.org/doc/manuals/maint-guide/
