While investigating whether libopenraw's dependency on GTK 2 can be
removed (which it can, see #967585), I noticed that the version of
libopenraw in Debian is from 2018 and there have been 12 new upstream
releases since then.

With this being file parsing code, I'm concerned that this might mean
unfixed security issues (although I don't see any obvious security fixes
in the upstream NEWS).

tumbler-plugins-extra seems to be the only package in Debian that makes
use of libopenraw (gegl also has a Build-Depends on it, but it seems to
be unused there) so the maintainers of tumbler might be interested in
salvaging libopenraw to have a high-quality version to depend on if its
current Debian maintainer is no longer active?

    smcv

Hi Simon, thanks for the heads-up.

Tumbler is a thumbnailing application used in Xfce so it uses libopenraw
just for generating thumbnails for RAW files, not for manipulating them
or something. I'm surprised tumbler is the only user, and I'm definitely
not keen on adding another package to maintain to our large base.

I share your concern about an outdated library parsing complex files.
If libopenraw Debian package isn't maintained in practice, maybe it
makes sense to drop it completely. For tumbler we can just remove the
dependency (and lose the hability to generate thumbnails for them) or
maybe investigate a way to uses a different library.

Regards,

For what it's worth, gegl switched from libopenraw to libraw (libraw-dev)
a while ago. libraw seems to be somewhat widely used: it's also what
gthumb, shotwell, geeqie, kimageformat-plugins, etc. use.

    smcv

Thanks for the pointer, I'll transfer that to upstream!

Regards,

On Mon, 24 Jul 2023 00:02:15 +0100 Simon McVittie <smcv@debian.org> wrote:
 > Source: libopenraw
 > Version: 0.1.2-0.2
 > Severity: wishlist
 > X-Debbugs-Cc: tumbler@packages.debian.org
 > Control: affects -1 + tumbler-plugins-extra
 >
 > While investigating whether libopenraw's dependency on GTK 2 can be
 > removed (which it can, see #967585), I noticed that the version of
 > libopenraw in Debian is from 2018 and there have been 12 new upstream
 > releases since then.
 >
 > With this being file parsing code, I'm concerned that this might mean
 > unfixed security issues (although I don't see any obvious security fixes
 > in the upstream NEWS).
 >
 > tumbler-plugins-extra seems to be the only package in Debian that makes
 > use of libopenraw (gegl also has a Build-Depends on it, but it seems to
 > be unused there) so the maintainers of tumbler might be interested in
 > salvaging libopenraw to have a high-quality version to depend on if its
 > current Debian maintainer is no longer active?
 >

Hi,

the newest glycin added one additonal image loader for opening RAW image
files.

The underlying rust crate needs libopenraw-dev 0.3. While RAW files are
not that common enabling the RAW loader

should be done sooner or later. Since loupe is the default image viewer
having RAW support would be great.

After my exams I can take a stab at getting libopenraw updated to 0.3 as
QA upload. The only rdep is tumbler-plugins-extra, so I hope this won't
be too much effort.

Getting loupe 48 in has priority though.

I won't adopt the package as I already maintain a lot.


best,


werdahias

Everything in Debian except for tumbler uses libraw instead of
libopenraw. Could you ask the Glycin developers if they have
considered libraw?

Thank you,
Jeremy Bícha

Hi all,

wanted to chime to give an update/perspective from my end. The library
is now mostly rewritten in Rust. I would like to see it updated to its
latest version, and its librust- part provided as new package. This is
because glycin, which is the new default image loader for GNOME, now has
a RAW loader too, which would require a recent (rust) libopenraw. While
that loader is still optional, I would like to enable it at some point.
Upstream stated that they will keep using libopenraw as their loader
since it's rust (and not C).
.
Updating libopenraw would require the following new crates to be
packaged:
fallible_collections, multiversion, multiversion-macros,
target-features.
I won't be packaging those, because I already maintain quite a few.
I'd be willing to review/sponsor/help with any work leading up to get
libopenraw current again though.

best,

werdahias
--bzz_bzz__bzz__1mwagujqskslet07t1f3bfuogxo00g0p
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8; charset=utf-8

Hi all,

wanted to chime to give an update/perspective from my end. The library
is now mostly rewritten in Rust. I would like to see it updated to its
latest version, and its librust- part provided as new package. glycin,
which is the new default image loader for GNOME, now has a RAW loader
too, which would require a recent (rust) libopenraw. While that loade
loaderloaderr is still optional I would like to enable it at some point.
Upstream stated that they will keep using libopenraw as their loader
since it's rust (and not C).
.
Updating libopenraw would require the following new crates to be
packaged:
fallible_collections, multiversion, multiversion-macros,
target-features.
I won't be packaging those, because I already maintain quite a few.
I'd be willing to review/sponsor/help with any work leading up to get
libopenraw current again though.

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.