darkshram/seahorse-caja

An extension for caja which allows encryption and decryption of OpenPGP files using GnuPG. Ported to Caja from seahorse-nautilus.

seahorse-caja's Issues

incorrect-fsf-address

During fedora review
https://bugzilla.redhat.com/show_bug.cgi?id=1502181
reviewer point me too this rpmlint issue.
seahorse-caja.x86_64: E: incorrect-fsf-address /usr/share/licenses/seahorse-caja/COPYING
This is easy to fix, the correct address you will find here https://www.gnu.org/licenses/old-licenses/old-licenses.html#GPL
Or an example at Mate repo.
http://git.mate-desktop.org/caja/commit/?id=0251b0f018c0860bafdd621f7be5eb395b510f5c

Replace build dependency on libgnome-keyring by libsecret

The GNOME people in Debian are asking for replacement of libgnome-keyring in caja-seahorse and use libsecret instead.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886476

They even started raising severity which threatens mate-power-manager to be auto-removed from Debian testing. Any porting work on this in sight?

If you have any questions or are in need of help, please contact the Debian+Ubuntu MATE Packaging Team on OFTC IRC (irc.debian.org, channel #debian-mate) or upstream MATE devs on Freenode IRC (channel: #mate-dev). Thanks!

Support GNUPG 2.1

Hey, I'm packaging this one too. 😉

It seems that this only supports GNUPG 2.0, but doesn't support 2.1+, which is the only version Ubuntu ships in recent releases.

Can this be fixed?

(in addition, fixing #3 would be good too)

autotools-pkg-config-macro-not-cross-compilation-safe configure.ac (line 29)

W: caja-seahorse source: autotools-pkg-config-macro-not-cross-compilation-safe configure.ac (line 29)
N:
N: The package appears to use AC_PATH_PROG to discover the location of
N: pkg-config(1). This macro fails to select the correct version to support
N: cross-compilation.
N:
N: A better way would be to use the PKG_PROG_PKG_CONFIG macro from pkg.m4
N: and then using the $PKG_CONFIG shell variable.
N:
N: Refer to https://bugs.debian.org/884798 for details.
N:
N: Severity: normal, Certainty: possible
N:
N: Check: cruft, Type: source

please drop build-dependency on dbus-glib (deprecated upstream)

dbus-glib is a deprecated D-Bus library with some significant design
flaws, and is essentially unmaintained. I would like to minimize its
use, and eventually remove it from Debian. There will not be a
version that fixes its design flaws, because that would be a major
compatibility break, and any user of dbus-glib who is willing to port
their application to a newer, incompatible version should instead be
porting their application to a better D-Bus implementation such as
GDBus.

For most purposes, the recommended replacement for dbus-glib is the
GDBus family of APIs in GLib, found in <gio/gio.h>. This does not add
an additional dependency, because dbus-glib already depends on a
sufficiently new version of GLib. A porting guide is available in the
GLib documentation:
https://developer.gnome.org/gio/stable/ch35.html. Practical
examples of porting from dbus-glib to GDBus can be found in the git
history of most older GNOME applications.

Alternatives to GDBus, with different design emphasis and trade-offs,
include sd-bus (systemd's D-Bus implementation), QtDBus (Qt's D-Bus
API), and libdbus (the low-level reference D-Bus implementation).
Please contact the D-Bus mailing list
if you are unsure which D-Bus implementation is most suitable for a
particular package.

Some libraries expose dbus-glib as part of their API/ABI, in which
case removing the deprecated dependency requires breaking API/ABI
(telepathy-glib is a good example). For these libraries, maintainers
should talk to the dependent library's upstream developers about
whether the dependent library should break API/ABI and switch to
GDBus, or whether the dependent library should itself be deprecated.

In a few cases, the package uses the reference D-Bus library libdbus
for all D-Bus-related APIs, and only uses dbus-glib as a way to
connect libdbus to the GLib main loop: if the only functions
referenced from dbus-glib are dbus_connection_setup_with_g_main() and
dbus_server_setup_with_g_main(), then you are in this situation. The
recommended replacement in this case is to bundle the dbus-gmain
branch from the dbus-glib git repository, for example as a git subtree or git submodule. For example, dbus-python's GLib
integration now works like this. See
<https://gitlab.freedesktop.org/dbus/dbus-glib/blob/dbus-gmain/README
.md> for more details.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955881

You might want to coordinate with the seahorse-nautilus maintainers who also need to migrated away from dbus-glib.

Thanks for maintaining seahorse-caja (from the Debian maintainer of MATE Desktop).

configure options

I want to include your package in official fedora, so i have a question about configure options.
You're using --disable-gpg-check in your spec file, what's the reason for it.
Or is this from seahorse-nautilus spec? 😄

PS: not really a issue.....

desktop-mime-but-no-exec-code

Hey there :)

Here's some Lintian errors that you should be aware of relating to the desktop files:

W: caja-seahorse: desktop-mime-but-no-exec-code usr/share/applications/mate-seahorse-pgp-encrypted.desktop
N:                                                                                                                                                                                                                                            
N:    The desktop entry lists support for at least one mime type, but does not
N:    provide codes like %f, %F, %u or %U for the Exec key.
N:    
N:    If the application can indeed handle files of the listed mime types, it
N:    should specify a way to pass the filenames as parameters.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: menu-format, Type: binary
N: 
W: caja-seahorse: desktop-mime-but-no-exec-code usr/share/applications/mate-seahorse-pgp-keys.desktop
W: caja-seahorse: desktop-mime-but-no-exec-code usr/share/applications/mate-seahorse-pgp-signature.desktop