This is a multi-part message in MIME format.
Yes, well aware of git's potential to be used. But this is supersimple,
run by means of context menus in the dolphin file manager. It also uses
a server process to assign immutability to the archived files, to make
sure you don't */accidentally/* delete them (let's say you delete the
folder. being versioned...) The files are kept in a ".archive" subfolder
of the folder being versioned (so it's a simple local backup, just like
Windows File Versioning and Mac Revert...)
ZFS could work, but many will want to stay with the filesystem herd
(EXT4...)
I could eventually add a cloud storage capability, but that opens a can
of worms. Maybe */eventually/* just interface it to a git repo of one's choosing? In the meantime, we have the equivalent functionality to File Versioner/Revert.
I will need to add a "rules" and a few of these other files to it:
https://www.debian.org/doc/manuals/maint-guide/dother.en.html
A functional package and repo should be ready by Monday. I think one
should read the article first though before investing time in pouring
over code, to check that my approach is sound and does not violate any
security model.
Shoot me a non-list Email if you are interested, and I'll send the
article to you; it's about 10 pages and NOT technically dense (it's
geared more as a press kit for potential end-users...) Until it's
submitted, I'd rather not have another project grabbing my ideas and
later claiming that they came up with them first. [If you can't see my
Email on this list, I can convey it back by a trivial obfuscation,
unless you know another way; I could also DM you on Stack Overflow if
you have a profile there...] ------------------------------------------------------------------------
Sounds like you know what you're doing. So I have a couple of QUICK
questions on deb policy, if you wouldn't mind answering them. [I
searched for an answer, but the advice was a bit contested...]
* There's /usr/local/share, /usr/local/share/doc, and /opt for storing
package files. But a more sensible convention I have seen [for
non-standard packages, and this would certainly be that...] is to
store a package's associated components in a folder under /usr/local
(NOT /usr/local/*/share/*, because I don't want to suggest that all
of them be shared, since some are for a dedicated Linux service...)
Then for any commands, you set up symbolic links in /usr/local/bin
to scripts/binaries in that /usr/local subfolder (presently I have a
postinst that does that linking, long with a prerm to remove
them...) Does that sound OK to you? Because lintian was griefing
that I was putting a folder with files in /usr/local -hey, it IS
local, so in theory we should be able to adapt it as we see fit
(perhaps this is a case of lintian being a chatty linter...)
* KDE has a *requirement* that .desktop files be executable; lintian
saw that and certain group/other permissions as being weird. Can I
ignore those too? If not, I could always do the permissions the way
it wants, and adjust them after they are copied in, in the postinst
script...
Thanks again...
On 10/3/24 09:49 PM, Antonio Russo wrote:
On 10/3/24 14:02, steve.b@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/
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Yes, well aware of git's potential to be used. But this is
supersimple, run by means of context menus in the dolphin file
manager. It also uses a server process to assign immutability to
the archived files, to make sure you don't <b><i>accidentally</i></b>
delete them (let's say you delete the folder. being versioned...)
The files are kept in a ".archive" subfolder of the folder being
versioned (so it's a simple local backup, just like Windows File
Versioning and Mac Revert...)</p>
<p>ZFS could work, but many will want to stay with the filesystem
herd (EXT4...)</p>
<p>I could eventually add a cloud storage capability, but that opens
a can of worms. Maybe <b><i>eventually</i></b> just interface it
to a git repo of one's choosing? In the meantime, we have the
equivalent functionality to File Versioner/Revert.<br>
</p>
<p>I will need to add a "rules" and a few of these other files to
it: <a href="
https://www.debian.org/doc/manuals/maint-guide/dother.en.html"
class="moz-txt-link-freetext">
https://www.debian.org/doc/manuals/maint-guide/dother.en.html</a><br>
</p>
<div class="moz-cite-prefix">A functional package and repo should be
ready by Monday. I think one should read the article first though
before investing time in pouring over code, to check that my
approach is sound and does not violate any security model.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Shoot me a non-list Email if you are
interested, and I'll send the article to you; it's about 10 pages
and NOT technically dense (it's geared more as a press kit for
potential end-users...) Until it's submitted, I'd rather not have
another project grabbing my ideas and later claiming that they
came up with them first. [If you can't see my Email on this list,
I can convey it back by a trivial obfuscation, unless you know
another way; I could also DM you on Stack Overflow if you have a
profile there...]</div>
<div class="moz-cite-prefix">
<hr width="100%" size="2">Sounds like you know what you're doing.
So I have a couple of QUICK questions on deb policy, if you
wouldn't mind answering them. [I searched for an answer, but the
advice was a bit contested...]<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">
<ul>
<li>There's /usr/local/share, /usr/local/share/doc, and /opt for
storing package files. But a more sensible convention I have
seen [for non-standard packages, and this would certainly be
that...] is to store a package's associated components in a
folder under /usr/local (NOT /usr/local/<b><i>share</i></b>,
because I don't want to suggest that all of them be shared,
since some are for a dedicated Linux service...) Then for any
commands, you set up symbolic links in /usr/local/bin to
scripts/binaries in that /usr/local subfolder (presently I
have a postinst that does that linking, long with a prerm to
remove them...) Does that sound OK to you? Because lintian was
griefing that I was putting a folder with files in /usr/local
-hey, it IS local, so in theory we should be able to adapt it
as we see fit (perhaps this is a case of lintian being a
chatty linter...)</li>
</ul>
</div>
<div class="moz-cite-prefix">
<ul>
<li>KDE has a <b>requirement</b> that .desktop files be
executable; lintian saw that and certain group/other
permissions as being weird. Can I ignore those too? If not, I
could always do the permissions the way it wants, and adjust
them after they are copied in, in the postinst script...</li>
</ul>
</div>
<div class="moz-cite-prefix">Thanks again...</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 10/3/24 09:49 PM, Antonio Russo
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:
d38553f8-d052-4e07-9e17-985e32614e52@aerusso.net">On
10/3/24 14:02, <a class="moz-txt-link-abbreviated" href="mailto:
steve.b@osfda.org">
steve.b@osfda.org</a> wrote:
<br>
<blockquote type="cite">I have a package that manages file
versioning that has been alpha tested with:
<br>
<br>
* bookworm
<br>
<br>
* KDE plasma
<br>
</blockquote>
<br>
I apologize if I'm overlooking it, but could you please link to
the source code
<br>
of this project, as well as your packaging of the deb?
<br>
<br>
<blockquote type="cite">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..]
<br>
</blockquote>
<br>
This sounds interesting!
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
I disagree here; there are tools that do this. Git and ZFS and
sanoid come to
<br>
mind, but these are not terribly new-user friendly.
<br>
<br>
There's also Nextcloud [1], (granted, the server is not packaged
in stable).
<br>
<br>
<blockquote type="cite">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?)
<br>
<br>
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...)
<br>
<br>
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...)
<br>
<br>
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.
<br>
<br>
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
<a class="moz-txt-link-rfc2396E" href="
https://www.sphinx-doc.org/en/master"><https://www.sphinx-doc.org/en/master></a> for its
documentation, which I have used before and I readily admit has
a sharp look; but mediawiki
<a class="moz-txt-link-rfc2396E" href="
https://www.mediawiki.org/wiki/MediaWiki"><https://www.mediawiki.org/wiki/MediaWiki></a> can be helpful
in garnering the assistance of others with documentation at some
later point ("many hands make light work...")
<br>
<br>
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...
<br>
</blockquote>
<br>
I recommend reading [2] if you plan on maintaining this package
yourself in
<br>
Debian.
<br>
<br>
<blockquote type="cite">Respectfully,
<br>
Steve Boriotti
<br>
Senior Developer, full stack
<br>
<br> ------------------------------------------------------------------------
<br>
<br>
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
<a class="moz-txt-link-rfc2396E" href="
https://www.cyrusimap.org"><https://www.cyrusimap.org></a> (using "RATS
<a class="moz-txt-link-rfc2396E" href="
https://code.google.com/archive/p/rough-auditing-tool-for-security"><https://code.google.com/archive/p/rough-auditing-tool-for-security></a>"...)
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...)
[<a class="moz-txt-link-freetext" href="
https://gitlab.com/osfda/pg_ssl_init">https://gitlab.com/osfda/pg_ssl_init</a>] I even furnished patches
on StackOverflow to remedy bugs in the new asynchronous psycopg3
<a class="moz-txt-link-rfc2396E" href="
https://www.psycopg.org/psycopg3"><https://www.psycopg.org/psycopg3></a> driver.
<br>
</blockquote>
<br>
Best,
<br>
Antonio
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="
https://docs.nextcloud.com/server/20/admin_manual/configuration_files/file_versioning.html">https://docs.nextcloud.com/server/20/admin_manual/configuration_files/file_versioning.html</a><br>
[2] <a class="moz-txt-link-freetext" href="
https://www.debian.org/doc/manuals/maint-guide/">https://www.debian.org/doc/manuals/maint-guide/</a>
<br>
<br>
</blockquote>
</body>
</html>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)