Bug#959692: ITP: otpclient -- Simple GTK+ software to generate OTPs (TOTP and HOTP)

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 

* Package name: otpclient
  Version : 2.2.1
  Upstream Author : Paolo Stivanin 
* URL : https://github.com/paolostivanin/OTPClient
* License : GPL-3+
  Programming Lang: C
  Description : Simple GTK+ software to generate OTPs (TOTP and HOTP)

  Highly secure and easy to use GTK+ software for two-factor
  authentication that supports both Time-based One-time Passwords
  (TOTP) and HMAC-Based One-Time Passwords (HOTP).
  .
  Features:
   - support both TOTP and HOTP
   - support setting custom digits (between 4 and 10 inclusive)
   - support setting a custom period (between 10 and 120 seconds inclusive)
   - support SHA1, SHA256 and SHA512 algorithms
   - support for Steam codes
   - import encrypted Authenticator Plus backup
   - import and export encrypted and/or plain andOTP backup
   - import and export plain FreeOTPPlus backup (key URI format only)
   - local database is encrypted using AES256-GCM
   * key is derived using PBKDF2 with SHA512 and 100k iterations
   * decrypted file is never saved (and hopefully never swapped) to disk.
 While the app is running, the decrypted content resides
 in a "secure memory" buffer allocated by Gcrypt

Re: [Summary]: RFC: Standardizing source package artifacts build paths

[Raphael Hertzog]

On Sat, 02 May 2020, Scott Kitterman wrote:
> Personally, I don't see any real benefit of standardizing on (making up an 
> example here) debian/.build over debian/build.

Same here. The arguments against debian/build are very weak. If we care
about a source package building a binary package named "build" or
whatever, it's really a unique case and surely it can be built with
some overrides and passing a different path where needed.

There's also the precedence of debian/source that has taken over a part of
the namespace below the debian directory.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#959703: ITP: jsofa -- Java translation of IAU SOFA library

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-j...@lists.debian.org, debian-devel@lists.debian.org, 
debian-as...@lists.debian.org

* Package name: jsofa
  Version : 20190722
  Upstream Author : 
* URL : http://javastro.github.io/jsofa/
* License : jsofa and SOFA
  Programming Lang: Java
  Description : pure Java translation of the IAU's C SOFA software library

jsofa provides algorithms and software for use in astronomical computing,
including routines for Astrometry, Calendars, Times, Coordinates etc.

It is a new dependency of the "aladin" package. The packages will be maintained
under Debian Astro team maintainance, with the repository at

https://salsa.debian.org/debian-astro-team/jsofa

Best regards

Ole

default email client from gsettings

[Jeff]

Apologies for a question that is only tangentially to do with Debian.

The Fedora maintainer for a package for which I am upstream has pointed
out that it still uses gconftool or gconftool-2, which is way out of
date and should use gsettings[1].

Unfortunately, my search engine foo is failing me and I can't find the
right incantation to get gsettings to tell me the default email client.

Would someone mind putting me on the right track?

Thanks and regards

Jeff

[1]https://sourceforge.net/p/gscan2pdf/feature-requests/112/



signature.asc
Description: OpenPGP digital signature

Re: [Summary]: RFC: Standardizing source package artifacts build paths

[Michael Biebl]

Am 04.05.20 um 09:55 schrieb Raphael Hertzog:
> On Sat, 02 May 2020, Scott Kitterman wrote:
>> Personally, I don't see any real benefit of standardizing on (making up an 
>> example here) debian/.build over debian/build.
> 
> Same here. The arguments against debian/build are very weak. If we care
> about a source package building a binary package named "build" or
> whatever, it's really a unique case and surely it can be built with
> some overrides and passing a different path where needed.

If you want to avoid name collisions, you could also use
debian/_build

I kinda like the idea of prefixing *all* temporary directory with a '_'





signature.asc
Description: OpenPGP digital signature

Re: default email client from gsettings

[Paul Wise]

On Mon, May 4, 2020 at 9:23 AM Jeff wrote:

> Unfortunately, my search engine foo is failing me and I can't find the
> right incantation to get gsettings to tell me the default email client.

I diffed `dconf dump /` and `gsettings list-recursively` before and
after changing my default email client and came up with no
differences, so I don't think it is stored in gsettings.

Then I did an strace of gnome-control-centre and noticed it modified
this file, changing the mailto handler in the [Default Applications]
section:

~/.config/mimeapps.list

Personally I would suggest you drop the custom code that you have and
just use xdg-email, it appears to know how to do things on various
desktops and to query the mimeapps file on gnome3 and to use gconftool
on gnome2.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: default email client from gsettings

[Vincent Bernat]

 ❦  4 mai 2020 11:23 +02, Jeff:

> The Fedora maintainer for a package for which I am upstream has pointed
> out that it still uses gconftool or gconftool-2, which is way out of
> date and should use gsettings[1].
>
> Unfortunately, my search engine foo is failing me and I can't find the
> right incantation to get gsettings to tell me the default email client.
>
> Would someone mind putting me on the right track?

Maybe:

 xdg-mime query default "x-scheme-handler/mailto"

But unsure if it uses something from gsettings.
-- 
As to the Adjective: when in doubt, strike it out.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Re: default email client from gsettings

[Simon McVittie]

On Mon, 04 May 2020 at 11:23:24 +0200, Jeff wrote:
> The Fedora maintainer for a package for which I am upstream has pointed
> out that it still uses gconftool or gconftool-2, which is way out of
> date and should use gsettings[1].

Taking a step back from "tell me the default email client", what are
you actually trying to do, at a high level? I suspect that rather
than manipulating the default email client (which is a job for desktop
configuration applications like gnome-control-center), you probably want
to compose an email?

It's often best to start from your application's high-level goal, ask
what you want to achieve, and look for (or ask about) APIs to do exactly
that, rather than immediately homing in on a particular lower-level
implementation detail.

If your goal is to pre-fill the To/Subject/body of an email in the user's
preferred email composition application, you would probably be better
off building a mailto: URI and asking your preferred library (in your
case that seems to be GLib/GTK?) to launch the preferred handler for that
URI. In GLib/GTK, try using APIs like g_app_info_launch_default_for_uri().

Or you could use xdg-email(1) from the xdg-utils package. It's a large
shell script that tries to do various legacy desktop-specific and/or
client-specific things in addition to the freedesktop.org URI-handler code
path, so might work better in legacy environments, at the cost that if
a desktop has moved from legacy desktop-specific APIs to freedesktop.org
APIs and xdg-utils hasn't been updated, it will continue to do the legacy
thing (even if that's now wrong).

> Unfortunately, my search engine foo is failing me and I can't find the
> right incantation to get gsettings to tell me the default email client.

That's probably because it isn't stored in gsettings.

GNOME 2 had GNOME-specific configuration for the preferred email client,
stored in gconf. The most direct equivalent of gconf in GNOME 3 is
indeed gsettings. However, there is not a 1:1 equivalence between
configuration items in gconf and configuration items in gsettings.

Instead of gconf or gsettings, GNOME 3 uses the freedesktop.org content
type (MIME type) handlers as a way to store/choose application defaults,
which is hopefully cross-desktop. Specifically, email is tracked as
the handler of the pseudo-MIME-type "x-scheme-handler/mailto". It
looks as though recent versions of at least KDE, MATE and Cinnamon
do the same. XFCE might still have its own desktop-specific mechanism
(or maybe it uses the freedesktop.org handlers now and xdg-utils just
hasn't caught up).

If you really need to manipulate the preferred handler for a URI
scheme like mailto (which you probably don't, because again,
this is a job for desktop configuration applications like
gnome-control-center), the way to do it in GNOME/KDE/etc. is
with C APIs like g_app_info_get_default_for_uri_scheme() and
g_app_info_set_as_default_for_type() (or their bindings into various non-C
languages), or with 'gio mime x-scheme-handler/mailto' from libglib2.0-bin
(which is just a CLI binding for those APIs), or with Qt/KDE equivalents
if you're closer to the Qt/KDE ecosystem than the GLib/GNOME ecosystem.

Or you could use xdg-settings(1) and/or xdg-mime(1) from the xdg-utils
package. Again, these are large shell scripts that try to do various
legacy desktop-specific and/or client-specific things, so they might work
better in legacy environments, but they might also do the wrong thing if
they have got out of sync with how their supported desktop environments
actually work.

smcv

Re: default email client from gsettings

[Jeff]

On 04/05/2020 14:50, Simon McVittie wrote:
> Taking a step back from "tell me the default email client", what are
> you actually trying to do, at a high level? I suspect that rather
> than manipulating the default email client (which is a job for desktop
> configuration applications like gnome-control-center), you probably want
> to compose an email?

Yup.

> If your goal is to pre-fill the To/Subject/body of an email in the user's
> preferred email composition application, you would probably be better
> off building a mailto: URI and asking your preferred library (in your
> case that seems to be GLib/GTK?) to launch the preferred handler for that
> URI. In GLib/GTK, try using APIs like g_app_info_launch_default_for_uri().

Thanks for that. I'll take a look. Not sure how to call that from Perl,
yet, but I'll work it you.

> Or you could use xdg-email(1) from the xdg-utils package. It's a large
> shell script that tries to do various legacy desktop-specific and/or
> client-specific things in addition to the freedesktop.org URI-handler code
> path, so might work better in legacy environments, at the cost that if
> a desktop has moved from legacy desktop-specific APIs to freedesktop.org
> APIs and xdg-utils hasn't been updated, it will continue to do the legacy
> thing (even if that's now wrong).

That was my fallback, as when I first added the functionality, it didn't
always do the right thing. It looks as though it is much better, now.

Thanks again for the detailed explanation - and also to the others that
answered.

Regards

jeff



signature.asc
Description: OpenPGP digital signature

Re: default email client from gsettings

[Simon McVittie]

On Mon, 04 May 2020 at 22:50:16 +0200, Jeff wrote:
> On 04/05/2020 14:50, Simon McVittie wrote:
> > Or you could use xdg-email(1)
> 
> That was my fallback, as when I first added the functionality, it didn't
> always do the right thing.

Please open bugs if it doesn't - quite a lot of third-party software
relies on xdg-email, so it's worth making sure we ship a version that
works with Debian's various desktops.

smcv

Bug#959739: ITP: editorconfig-checker -- tool to verify that your files are in harmony with your .editorconfig

[Stephan Lachnit]

Package: wnpp
Severity: wishlist
Owner: Stephan Lachnit 

  Package name: editorconfig-checker
  Version : 2.0.3
  Upstream Author : editorconfig-checker team 
  URL : https://github.com/editorconfig-checker/editorconfig-
checker
  License : MIT
  Programming Lang: Go
  Description : tool to verify that your files are in harmony with your
.editorconfig

This is a tool to check if your files consider your .editorconfig-rules. Most
tools - like linters for example - only test one filetype and need an extra
configuration. This tool only needs your .editorconfig to check all files.

Cheers,
Stephan