How to deal with packages cointaining rust parts?

[Julian Sikorski]

Hello,

I looked into updating libopenraw to 0.3.5 yesterday, in order to 
possibly enable packaging miniaturo [1], a drop-in replacement for the 
unmaintained raw-thumbnailer [2].
During the build process, libopenraw tries do download mp4parse and 
mp4parse_capi, which works if --enable-network is passed to mock. For a 
proper update I assume these dependencies would need to be packaged 
first. mp4_parse even used to have a fedora package at some point in the 
past [3].
The question is: what would the proper way of packaging the updated 
libopenraw? How to tell it to use the system versions of the libs? The 
guidelines appear to be focused on pure rust packages. And, even more 
importantly: would miniaturo be even allowed to be packaged? There 
appears to be no package at crates.io. Thanks for the input.

Best regards,
Julian

[1] https://github.com/dbrgn/miniaturo
[2] 
https://gitlab.freedesktop.org/libopenraw/libopenraw/-/issues/14#note_189...
[3] https://src.fedoraproject.org/rpms/rust-mp4parse

[Fabio Valentini]

On Sun, Apr 30, 2023 at 9:17 AM Julian Sikorski <belegdol(a)gmail.com&gt; wrote:
>  Hello,
>
>  I looked into updating libopenraw to 0.3.5 yesterday, in order to
>  possibly enable packaging miniaturo [1], a drop-in replacement for the
>  unmaintained raw-thumbnailer [2]. 
Hi!

From a first look, packaging miniature should be possible, but it will
require packaging a few dependencies, as you already found out.
I can help with getting miniaturo and its dependencies packaged, if you want?
It's not looking like a "simple" starting point for a first-time Rust
packager, but for example, I can submit the packages for review and
you review them, if that works for you?

>  During the build process, libopenraw tries do download mp4parse and
>  mp4parse_capi, which works if --enable-network is passed to mock. For a
>  proper update I assume these dependencies would need to be packaged
>  first. mp4_parse even used to have a fedora package at some point in the
>  past [3].
>  The question is: what would the proper way of packaging the updated
>  libopenraw? How to tell it to use the system versions of the libs? 
Yes, downloading from the internet is the "default mode of operation"
of cargo. You will need to add the "%cargo_prep" macro at the end of
the %prep scriptlet.
This macro drops a cargo configuration file into ./.cargo/config which
makes it look for Rust sources as they are packaged instead of loading
them from the internet.
Additionally, adding a %generate_buildrequires section will be needed,
where "%cargo_generate_buildrequires" needs to be run in the root
directory of the Rust subproject.
This causes the build system to pull in all necessary Rust dependencies.

The only problem I see is that the build system apparently patches
mp4-parse after download. This isn't compatible with how we package
things for Fedora (i.e. you can't just patch random third-party
library before running a build), so that will need to be dropped (but
our Fedora package for the patched crate will likely contain a similar
patch anyway).

>  The guidelines appear to be focused on pure rust packages. And, even
> more
>  importantly: would miniaturo be even allowed to be packaged? There
>  appears to be no package at crates.io. Thanks for the input. 
Packaging miniaturo is fine. It doesn't provide a Rust library
interface (i.e. an "importable crate"), so the requirement for it to
be published on crates.io does not apply. (Maybe the language for this
in the Packaging Guidelines isn't 100% obvious, sorry about that ...)

The current Rust Packaging Guidelines were written at a point in time
when almost all Rust projects that were getting packaged were "crates"
published on crates.io. This is no longer true, since many projects
started including Rust code (mesa, libblkio, firefox, thunderbird,
mozjs, rpm-ostree, gnome-tour, librsvg2, etc.) ...

I've been attempting to overhaul the Rust Packaging Guidelines to
reflect this fact (and make them more "descriptive" and less
"prescriptive", since the rust2rpm tool is basically an implementation
of the Rust Packaging Guidelines for Rust crates anyway), but I
haven't had much time work on this rewrite lately. :(

Let me know how you want to proceed. My offer to help packaging things
stands. But if you want to get started with Rust packaging yourself,
I'd recommend starting with some simple crates rather than jumping
head first into complicated multi-language projects like libopenraw :)

Fabio

[Julian Sikorski]

Am 30.04.23 um 12:35 schrieb Fabio Valentini:
>  On Sun, Apr 30, 2023 at 9:17 AM Julian Sikorski
> <belegdol(a)gmail.com&gt; wrote:
> >
> > Hello,
> >
> > I looked into updating libopenraw to 0.3.5 yesterday, in order to
> > possibly enable packaging miniaturo [1], a drop-in replacement for the
> > unmaintained raw-thumbnailer [2].
>  
>  Hi!
>  
>   From a first look, packaging miniature should be possible, but it will
>  require packaging a few dependencies, as you already found out.
>  I can help with getting miniaturo and its dependencies packaged, if you want?
>  It's not looking like a "simple" starting point for a first-time Rust
>  packager, but for example, I can submit the packages for review and
>  you review them, if that works for you?
>  
> > During the build process, libopenraw tries do download mp4parse and
> > mp4parse_capi, which works if --enable-network is passed to mock. For a
> > proper update I assume these dependencies would need to be packaged
> > first. mp4_parse even used to have a fedora package at some point in the
> > past [3].
> > The question is: what would the proper way of packaging the updated
> > libopenraw? How to tell it to use the system versions of the libs?
>  
>  Yes, downloading from the internet is the "default mode of operation"
>  of cargo. You will need to add the "%cargo_prep" macro at the end of
>  the %prep scriptlet.
>  This macro drops a cargo configuration file into ./.cargo/config which
>  makes it look for Rust sources as they are packaged instead of loading
>  them from the internet.
>  Additionally, adding a %generate_buildrequires section will be needed,
>  where "%cargo_generate_buildrequires" needs to be run in the root
>  directory of the Rust subproject.
>  This causes the build system to pull in all necessary Rust dependencies.
>  
>  The only problem I see is that the build system apparently patches
>  mp4-parse after download. This isn't compatible with how we package
>  things for Fedora (i.e. you can't just patch random third-party
>  library before running a build), so that will need to be dropped (but
>  our Fedora package for the patched crate will likely contain a similar
>  patch anyway).
>  
> > The guidelines appear to be focused on pure rust packages. And, even more
> > importantly: would miniaturo be even allowed to be packaged? There
> > appears to be no package at crates.io. Thanks for the input.
>  
>  Packaging miniaturo is fine. It doesn't provide a Rust library
>  interface (i.e. an "importable crate"), so the requirement for it to
>  be published on crates.io does not apply. (Maybe the language for this
>  in the Packaging Guidelines isn't 100% obvious, sorry about that ...)
>  
>  The current Rust Packaging Guidelines were written at a point in time
>  when almost all Rust projects that were getting packaged were "crates"
>  published on crates.io. This is no longer true, since many projects
>  started including Rust code (mesa, libblkio, firefox, thunderbird,
>  mozjs, rpm-ostree, gnome-tour, librsvg2, etc.) ...
>  
>  I've been attempting to overhaul the Rust Packaging Guidelines to
>  reflect this fact (and make them more "descriptive" and less
>  "prescriptive", since the rust2rpm tool is basically an implementation
>  of the Rust Packaging Guidelines for Rust crates anyway), but I
>  haven't had much time work on this rewrite lately. :(
>  
>  Let me know how you want to proceed. My offer to help packaging things
>  stands. But if you want to get started with Rust packaging yourself,
>  I'd recommend starting with some simple crates rather than jumping
>  head first into complicated multi-language projects like libopenraw :)
>  
>  Fabio 
Hi,

thanks for the detailed feedback! The reason I wanted to give it a shot 
was the issue reported with raw_thumbnailer [1]. I am already 
co-maintaining libopenraw, so I thought I could at least try.
So far I managed to get packages for mp4parse, mp4parse_capi, criterion 
and bitreader building, see attached. I also managed libopenraw not to 
fail at attempting to go online, but I am not sure how to solve the 
error I am getting now:

error: Dependency tokens must begin with alpha-numeric, '_' or '/': 
~/build/BUILD/libopenraw-0  .3.5/lib/mp4 ~/build/BUILD/libopenraw-0.3.5

I am also not sure I will be able to get rid of the patching. At the 
first glance it requires understanding what the patches are doing and 
knowing how to replace the functionality.
If you would be willing to pick up where I left, I can definitely offer 
to do the package reviews. I am just worried I would not be able to help 
much beyond that, saving for keeping the packages up-to-date and liasing 
with their upstreams. But it definitely looks like you are right and I 
have bitten off more than I can chew.

Best regards,
Julian

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2165576

[Fabio Valentini]

On Sun, Apr 30, 2023 at 1:31 PM Julian Sikorski <belegdol(a)gmail.com&gt; wrote:
>  thanks for the detailed feedback! The reason I wanted to give it a shot
>  was the issue reported with raw_thumbnailer [1]. I am already
>  co-maintaining libopenraw, so I thought I could at least try.
>  So far I managed to get packages for mp4parse, mp4parse_capi, criterion
>  and bitreader building, see attached. I also managed libopenraw not to
>  fail at attempting to go online, but I am not sure how to solve the
>  error I am getting now:
>
>  error: Dependency tokens must begin with alpha-numeric, '_' or '/':
>  ~/build/BUILD/libopenraw-0  .3.5/lib/mp4 ~/build/BUILD/libopenraw-0.3.5 
This is caused by using pushd / popd instead of "cd", because pushd
and popd print things to stdout that %generate_buildrequires
interprets as names of dependencies ... you can use plain "cd"
instead.

>  I am also not sure I will be able to get rid of the patching. At the
>  first glance it requires understanding what the patches are doing and
>  knowing how to replace the functionality. 
It doesn't look like a problem, the patch here looks harmless:
https://gitlab.freedesktop.org/libopenraw/libopenraw/-/blob/master/lib/mp...

>  If you would be willing to pick up where I left, I can definitely
> offer
>  to do the package reviews. I am just worried I would not be able to help
>  much beyond that, saving for keeping the packages up-to-date and liasing
>  with their upstreams. But it definitely looks like you are right and I
>  have bitten off more than I can chew. 
I took a look at the libopenraw spec file, and after fixing the
pushd/cd thing, the biggest problem I see is more of an upstream
problem ...
It bundles copies of the mp4parse and mp4parse_capi crates (no idea
whether the sources are just included or if they are forks with
downstream changes), in addition to 15 MB of vendored Rust
dependencies, which we cannot use for Fedora builds.

If the mp4parse{,_capi} sources are indeed forks with downstream
patches, it would be ok to leave them as they are, but the vendored
Rust dependencies need to be removed and can't be used. Honestly, the
entire Rust part of libopenraw [0] looks very "hackish" and ad-hoc
(it's not even a proper cargo workspace - which our Rust packaging
tools support - but disconnected crates that are held together by
path-based dependencies - which our tools *don't' support).

I'll try to make the package build ~somehow~, but I can't make any
promises right now :)

Fabio

[0]: https://gitlab.freedesktop.org/libopenraw/libopenraw/-/tree/master/lib/mp4

[Fabio Valentini]

On Sun, Apr 30, 2023 at 3:04 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  I'll try to make the package build ~somehow~, but I can't make any
>  promises right now :) 
Ok, trying to actually build all the things, it turns out things are
not *too bad*.
It looks like the bundled mp4parse and mp4parse_capi crates are indeed
forks with downstream changes.

I made some changes and added some FIXME items to the libopenraw spec
file, and I only made the minimum necessary amount of changes to make
it build successfully.
For example, I didn't check whether any BuildRequires that are present
are unnecessary with v0.3 and could be removed.
Most notably, the MPLv2.0 license file for the bundled mp4parse and
mp4parse_capi crates is missing.

Here's the spec files for the packages:
https://github.com/decathorpe/miniaturo-rpms

And here's a COPR with test builds:
https://copr.fedorainfracloud.org/coprs/decathorpe/miniaturo/monitor/

I don't know how to test whether the built binaries for miniaturo
actually work, though :)
If it indeed *does* work as expected, the next steps would probably be
something like:

- I submit (re)review request for rust-bitreader, it gets reviewed, I
import and build it
- libopenraw v0.3 FIXMEs are resolved (will likely require upstream involvement)
- libopenraw is updated to v0.3 in Fedora (not sure if any dependent
packages need to be adapted for libopenraw-0.1 → libopenraw-0.3)
- I submit review requests for rust-libopenraw-sys, rust-libopenraw,
miniaturo, and they get reviewed, imported, and built

Fabio

[Julian Sikorski]

Am 30.04.23 um 16:53 schrieb Fabio Valentini:
>  On Sun, Apr 30, 2023 at 3:04 PM Fabio Valentini
> <decathorpe(a)gmail.com&gt; wrote:
> >
> > I'll try to make the package build ~somehow~, but I can't make any
> > promises right now :)
>  
>  Ok, trying to actually build all the things, it turns out things are
>  not *too bad*.
>  It looks like the bundled mp4parse and mp4parse_capi crates are indeed
>  forks with downstream changes.
>  
>  I made some changes and added some FIXME items to the libopenraw spec
>  file, and I only made the minimum necessary amount of changes to make
>  it build successfully.
>  For example, I didn't check whether any BuildRequires that are present
>  are unnecessary with v0.3 and could be removed.
>  Most notably, the MPLv2.0 license file for the bundled mp4parse and
>  mp4parse_capi crates is missing.
>  
>  Here's the spec files for the packages:
>  https://github.com/decathorpe/miniaturo-rpms
>  
>  And here's a COPR with test builds:
>  https://copr.fedorainfracloud.org/coprs/decathorpe/miniaturo/monitor/
>  
>  I don't know how to test whether the built binaries for miniaturo
>  actually work, though :) 
Wow, nice, this was fast. Thank you! Would it be possible to build the 
copr for f38 as well? I can then test if miniaturo works by taking some 
RAW pictures and checking whether thumbnails actually get generated.

>  If it indeed *does* work as expected, the next steps would probably
> be
>  something like:
>  
>  - I submit (re)review request for rust-bitreader, it gets reviewed, I
>  import and build it
>  - libopenraw v0.3 FIXMEs are resolved (will likely require upstream involvement)
>  - libopenraw is updated to v0.3 in Fedora (not sure if any dependent
>  packages need to be adapted for libopenraw-0.1 → libopenraw-0.3)
>  - I submit review requests for rust-libopenraw-sys, rust-libopenraw,
>  miniaturo, and they get reviewed, imported, and built
>  
>  FabioI can help with reviews and checking the dependencies, I have a  
deps-rebuild
script which could help here.

Best regards,
Julian

[Fabio Valentini]

On Sun, Apr 30, 2023 at 7:45 PM Julian Sikorski <belegdol(a)gmail.com&gt; wrote:
>  Wow, nice, this was fast. Thank you! Would it be possible to build the
>  copr for f38 as well? I can then test if miniaturo works by taking some
>  RAW pictures and checking whether thumbnails actually get generated. 
Sure thing. Builds are running now, and will probably be done soon:
https://copr.fedorainfracloud.org/coprs/decathorpe/miniaturo/monitor/

>  I can help with reviews and checking the dependencies, I have a
>  deps-rebuild script which could help here. 
That would be great. I'll start by submitting the re-review request
for rust-bitreader later today, then the libopenraw v0.3 update should
be unblocked.

Fabio

[Julian Sikorski]

Am 30.04.23 um 20:36 schrieb Fabio Valentini:
>  On Sun, Apr 30, 2023 at 7:45 PM Julian Sikorski
> <belegdol(a)gmail.com&gt; wrote:
> >
> > Wow, nice, this was fast. Thank you! Would it be possible to build the
> > copr for f38 as well? I can then test if miniaturo works by taking some
> > RAW pictures and checking whether thumbnails actually get generated.
>  
>  Sure thing. Builds are running now, and will probably be done soon:
>  https://copr.fedorainfracloud.org/coprs/decathorpe/miniaturo/monitor/ 
Thanks! I have now installed miniaturo and there is good news and bad 
news. The good news is that I can manually create thumbnails from CR2 
RAW files created by my Canon camera. The bad news is that the bits 
needed for this to happen automatically appear to be missing. My 
educated guess is that this is handled in this issue:

https://github.com/dbrgn/miniaturo/issues/11

I have asked to be sure. Maybe the automation could be made to work by 
stealing the bits from raw-thumbnailer. Given that a bug was filed, it 
appears that it is still functional to some extent.

>  
> > I can help with reviews and checking the dependencies, I have a
> > deps-rebuild script which could help here.
>  
>  That would be great. I'll start by submitting the re-review request
>  for rust-bitreader later today, then the libopenraw v0.3 update should
>  be unblocked.
>  
>  Fabio 
I just checked the dependencies. It appears that nothing depends on 
libopenraw currently:

$ sudo dnf repoquery --whatrequires libopenraw
Letzte Prüfung auf abgelaufene Metadaten: vor 0:02:57 am So 30 Apr 2023 
23:33:20 CEST.
libopenraw-devel-0:0.1.3-13.fc38.i686
libopenraw-devel-0:0.1.3-13.fc38.x86_64
libopenraw-gnome-0:0.1.3-13.fc38.i686
libopenraw-gnome-0:0.1.3-13.fc38.x86_64
libopenraw-pixbuf-loader-0:0.1.3-13.fc38.i686
libopenraw-pixbuf-loader-0:0.1.3-13.fc38.x86_64

$ sudo dnf repoquery --arch=src  --whatrequires libopenraw-devel
Letzte Prüfung auf abgelaufene Metadaten: vor 0:04:33 am So 30 Apr 2023 
23:33:20 CEST.

Best regards,
Julian

[Fabio Valentini]

On Sun, Apr 30, 2023 at 11:41 PM Julian Sikorski <belegdol(a)gmail.com&gt; wrote:
>  Am 30.04.23 um 20:36 schrieb Fabio Valentini:
>  > On Sun, Apr 30, 2023 at 7:45 PM Julian Sikorski <belegdol(a)gmail.com&gt; wrote:
>  >>
>  >> Wow, nice, this was fast. Thank you! Would it be possible to build the
>  >> copr for f38 as well? I can then test if miniaturo works by taking some
>  >> RAW pictures and checking whether thumbnails actually get generated.
>  >
>  > Sure thing. Builds are running now, and will probably be done soon:
>  > https://copr.fedorainfracloud.org/coprs/decathorpe/miniaturo/monitor/
>
>  Thanks! I have now installed miniaturo and there is good news and bad
>  news. The good news is that I can manually create thumbnails from CR2
>  RAW files created by my Canon camera. The bad news is that the bits
>  needed for this to happen automatically appear to be missing. My
>  educated guess is that this is handled in this issue:
>
>  https://github.com/dbrgn/miniaturo/issues/11
>
>  I have asked to be sure. Maybe the automation could be made to work by
>  stealing the bits from raw-thumbnailer. Given that a bug was filed, it
>  appears that it is still functional to some extent. 
Yeah, I assumed that there would need to be some associated
configuration files to actually make this a functional thumbnailer for
certain file types, but yeah, those things are currently missing from
the miniaturo project as far as I can see.

>  >
>  >> I can help with reviews and checking the dependencies, I have a
>  >> deps-rebuild script which could help here.
>  >
>  > That would be great. I'll start by submitting the re-review request
>  > for rust-bitreader later today, then the libopenraw v0.3 update should
>  > be unblocked.
>  >
>  > Fabio
>  I just checked the dependencies. It appears that nothing depends on
>  libopenraw currently:
>
>  $ sudo dnf repoquery --whatrequires libopenraw
>  Letzte Prüfung auf abgelaufene Metadaten: vor 0:02:57 am So 30 Apr 2023
>  23:33:20 CEST.
>  libopenraw-devel-0:0.1.3-13.fc38.i686
>  libopenraw-devel-0:0.1.3-13.fc38.x86_64
>  libopenraw-gnome-0:0.1.3-13.fc38.i686
>  libopenraw-gnome-0:0.1.3-13.fc38.x86_64
>  libopenraw-pixbuf-loader-0:0.1.3-13.fc38.i686
>  libopenraw-pixbuf-loader-0:0.1.3-13.fc38.x86_64
>
>  $ sudo dnf repoquery --arch=src  --whatrequires libopenraw-devel
>  Letzte Prüfung auf abgelaufene Metadaten: vor 0:04:33 am So 30 Apr 2023
>  23:33:20 CEST. 
True, but you forgot to check the libopenraw-gnome and
libopenraw-pixbuf-loader subpackages:
It appears that tumbler-extras depends on libopenraw-gnome.
It might need adjustments to changed APIs and the changed library /
pkgconfig name.

Fabio

[Julian Sikorski]

Am 01.05.23 um 00:22 schrieb Fabio Valentini:
>  On Sun, Apr 30, 2023 at 11:41 PM Julian Sikorski
> <belegdol(a)gmail.com&gt; wrote:
> >
> > Am 30.04.23 um 20:36 schrieb Fabio Valentini:
> >> On Sun, Apr 30, 2023 at 7:45 PM Julian Sikorski <belegdol(a)gmail.com&gt;
> wrote:
> >>>
> >>> Wow, nice, this was fast. Thank you! Would it be possible to build the
> >>> copr for f38 as well? I can then test if miniaturo works by taking some
> >>> RAW pictures and checking whether thumbnails actually get generated.
> >>
> >> Sure thing. Builds are running now, and will probably be done soon:
> >> https://copr.fedorainfracloud.org/coprs/decathorpe/miniaturo/monitor/
> >
> > Thanks! I have now installed miniaturo and there is good news and bad
> > news. The good news is that I can manually create thumbnails from CR2
> > RAW files created by my Canon camera. The bad news is that the bits
> > needed for this to happen automatically appear to be missing. My
> > educated guess is that this is handled in this issue:
> >
> > https://github.com/dbrgn/miniaturo/issues/11
> >
> > I have asked to be sure. Maybe the automation could be made to work by
> > stealing the bits from raw-thumbnailer. Given that a bug was filed, it
> > appears that it is still functional to some extent.
>  
>  Yeah, I assumed that there would need to be some associated
>  configuration files to actually make this a functional thumbnailer for
>  certain file types, but yeah, those things are currently missing from
>  the miniaturo project as far as I can see. 
I will experiment with hacking the raw-thumbnailer files to work with 
miniaturo.

>  
> >>
> >>> I can help with reviews and checking the dependencies, I have a
> >>> deps-rebuild script which could help here.
> >>
> >> That would be great. I'll start by submitting the re-review request
> >> for rust-bitreader later today, then the libopenraw v0.3 update should
> >> be unblocked.
> >>
> >> Fabio
> > I just checked the dependencies. It appears that nothing depends on
> > libopenraw currently:
> >
> > $ sudo dnf repoquery --whatrequires libopenraw
> > Letzte Prüfung auf abgelaufene Metadaten: vor 0:02:57 am So 30 Apr 2023
> > 23:33:20 CEST.
> > libopenraw-devel-0:0.1.3-13.fc38.i686
> > libopenraw-devel-0:0.1.3-13.fc38.x86_64
> > libopenraw-gnome-0:0.1.3-13.fc38.i686
> > libopenraw-gnome-0:0.1.3-13.fc38.x86_64
> > libopenraw-pixbuf-loader-0:0.1.3-13.fc38.i686
> > libopenraw-pixbuf-loader-0:0.1.3-13.fc38.x86_64
> >
> > $ sudo dnf repoquery --arch=src  --whatrequires libopenraw-devel
> > Letzte Prüfung auf abgelaufene Metadaten: vor 0:04:33 am So 30 Apr 2023
> > 23:33:20 CEST.
>  
>  True, but you forgot to check the libopenraw-gnome and
>  libopenraw-pixbuf-loader subpackages:
>  It appears that tumbler-extras depends on libopenraw-gnome.
>  It might need adjustments to changed APIs and the changed library /
>  pkgconfig name.
>   
Good catch! The good news is that tumbler at least builds with 
libopenraw-0.3.

Best regards,
Julian

[Fabio Valentini]

On Mon, May 1, 2023 at 10:14 AM Julian Sikorski <belegdol(a)gmail.com&gt; wrote:
>  Am 01.05.23 um 00:22 schrieb Fabio Valentini:
>  > On Sun, Apr 30, 2023 at 11:41 PM Julian Sikorski <belegdol(a)gmail.com&gt; wrote:
>  >>
>  >> Am 30.04.23 um 20:36 schrieb Fabio Valentini:
>  >>> On Sun, Apr 30, 2023 at 7:45 PM Julian Sikorski <belegdol(a)gmail.com&gt;
> wrote:
>  >>>>
>  >>>> Wow, nice, this was fast. Thank you! Would it be possible to build the
>  >>>> copr for f38 as well? I can then test if miniaturo works by taking some
>  >>>> RAW pictures and checking whether thumbnails actually get generated.
>  >>>
>  >>> Sure thing. Builds are running now, and will probably be done soon:
>  >>> https://copr.fedorainfracloud.org/coprs/decathorpe/miniaturo/monitor/
>  >>
>  >> Thanks! I have now installed miniaturo and there is good news and bad
>  >> news. The good news is that I can manually create thumbnails from CR2
>  >> RAW files created by my Canon camera. The bad news is that the bits
>  >> needed for this to happen automatically appear to be missing. My
>  >> educated guess is that this is handled in this issue:
>  >>
>  >> https://github.com/dbrgn/miniaturo/issues/11
>  >>
>  >> I have asked to be sure. Maybe the automation could be made to work by
>  >> stealing the bits from raw-thumbnailer. Given that a bug was filed, it
>  >> appears that it is still functional to some extent.
>  >
>  > Yeah, I assumed that there would need to be some associated
>  > configuration files to actually make this a functional thumbnailer for
>  > certain file types, but yeah, those things are currently missing from
>  > the miniaturo project as far as I can see.
>
>  I will experiment with hacking the raw-thumbnailer files to work with
>  miniaturo. 
Thanks for your PR, I've pushed a new build of miniaturo to COPR.

Fabio