[digiKam-users] Future of digiKam bundles...

Le 24/05/2020 à 21:57, Chris Green a écrit :

> It sounds like a FlatPak is some sort of horrible halfway house.
>

or maybe an other tentative to have a cross platform repository system,
what could be a better choice, if it succeed

jdd
--
http://dodin.org

Le 24/05/2020 à 22:10, Andrey Goreev a écrit :

finally get that ol’ BWM motorcycle
> that has been sitting in the garage for years up and running again so I

specially this one :-)))

jdd

--
http://dodin.org

[Mica Semrick]

On 5/24/20 12:57 PM, Chris Green wrote:
> It seems all wrong to me somehow.


Perhaps you should read more about flatpak if you do not understand it.

> Either (like Appimage) you download a file (downloading any old way
> you want, you usual way of doing it, ftp, wget, whatever) and it's a
> standalone program with no dependencies*OR*  you have something that
> uses the distribution's standard format for handling dependencies etc.

Flatpak uses flatpak portals to hook into your system. If your distro
provides the flatpak package, then you have the necessary means to begin
using flatpak. Flatpak is repo based, like a traditional distro package
manager, and you can also download one-off builds, similar to how you
can download a single deb/rpm to your system and install it. flatpak has
its own dependency tree/dependency management. At its heart, flatpak is
a layering system: there is the base freedesktop package, then a
kde/gnome layer on top of that, then the app layer on top of that.

> It sounds like a FlatPak is some sort of horrible halfway house.

Perhaps you should come to a full understand of the technology before
throwing your opinion into the mix.

[Chris Green]

On Sun, May 24, 2020 at 02:10:40PM -0600, Andrey Goreev wrote:
>    I think flatpaks are standalone and have no dependencies. Looks like

If that's right then I'm quite happy, it's the way appimage is/was.
However I'd expect to be able to simply download a file and run it in
that case.

--
Chris Green

[Chris Green]

On Sun, May 24, 2020 at 01:18:15PM -0700, Mica Semrick wrote:

>
>
> On 5/24/20 12:57 PM, Chris Green wrote:
> > It seems all wrong to me somehow.
>
>
> Perhaps you should read more about flatpak if you do not understand it.
>
> > Either (like Appimage) you download a file (downloading any old way
> > you want, you usual way of doing it, ftp, wget, whatever) and it's a
> > standalone program with no dependencies*OR*  you have something that
> > uses the distribution's standard format for handling dependencies etc.
>
> Flatpak uses flatpak portals to hook into your system.

Well that sounds uncomfortable for a start. :-)

>                                                  If your distro
> provides the flatpak package, then you have the necessary means to begin
> using flatpak. Flatpak is repo based, like a traditional distro package
> manager, and you can also download one-off builds, similar to how you can
> download a single deb/rpm to your system and install it. flatpak has its own
> dependency tree/dependency management. At its heart, flatpak is a layering
> system: there is the base freedesktop package, then a kde/gnome layer on top
> of that, then the app layer on top of that.
>
> > It sounds like a FlatPak is some sort of horrible halfway house.
>
> Perhaps you should come to a full understand of the technology before
> throwing your opinion into the mix.

Why?  I doubt if anyone here fully understands rpm, deb or whatever.
I'm just trying to get my mind round what flatpack might mean in terms
of keeping my installation safe and easily maintained.

It may very well be a good alternative/improvement over appimage, I'm
just trying to ensure that we're not losing the huge benefits that
well maintained repositories provide.

I already stopped using snap.  Appimage is Ok'ish and if flatpack is
as good then I'm happy, I'm just trying to convince myself that
flatpack *is* as good/safe as appimage.


--
Chris Green

[Chris Green]

[hidden email] <[hidden email]> wrote:
> Le 24/05/2020 à 21:57, Chris Green a écrit :
>
> > It sounds like a FlatPak is some sort of horrible halfway house.
> >
>
> or maybe an other tentative to have a cross platform repository system,
> what could be a better choice, if it succeed
>
It would be a rather major revolution if it replaced .rpm and .deb.  

Yes, it would be lovely if we (all Linux distributions) used the same
format for distributing software but I don't believe that snap, or
appimage or flatpak are taking the right approach to doing this.  They
all seem to be looking for a way to bypass the existing way of doing
things.

--
Chris Green
·

[Mica Semrick]

On 5/24/20 1:38 PM, Chris Green wrote:
> Well that sounds uncomfortable for a start.:-)

Do you have some specific point here or are you just going to keep
making vague & uninformed comments?


>> Perhaps you should come to a full understand of the technology before
>> throwing your opinion into the mix.
> Why?  I doubt if anyone here fully understands rpm, deb or whatever.
> I'm just trying to get my mind round what flatpack might mean in terms
> of keeping my installation safe and easily maintained.

Again, using Plasma Discover, Gnome Sotftware, or the cli with "flatpak
update" is how you maintain your system. Since flatpak is repo based,
getting your flatpaks from a trusted source is how you keep it secure.
Just like you don't install software from random deb/rpm archives, you'd
do the same for flatpaks.

>
> It may very well be a good alternative/improvement over appimage, I'm
> just trying to ensure that we're not losing the huge benefits that
> well maintained repositories provide.

AppImages aren't in a repo. You download them like you would an exe,
then run them. There is no inherent sandboxing in AppImage (you'd need
to use something like firejail), but flatpak has built in sandboxing.
AppImages can't be signed, but flatpak includes GPG signing verification
out-of-the-box.

> I already stopped using snap.  Appimage is Ok'ish and if flatpack is
> as good then I'm happy, I'm just trying to convince myself that
> flatpack*is*  as good/safe as appimage.

I wouldn't consider AppImage to be "safe" by any means. There is nothing
inherent to AppImage that makes it safe to run on your system.

Le 24/05/2020 à 22:48, Chris Green a écrit :

> appimage or flatpak are taking the right approach to doing this.  They
> all seem to be looking for a way to bypass the existing way of doing
> things.
>

like did systemd today largely adopted

jdd

--
http://dodin.org

[Chris Green]

On Sun, May 24, 2020 at 02:26:43PM -0700, Mica Semrick wrote:

> On 5/24/20 1:38 PM, Chris Green wrote:
>
> > > Perhaps you should come to a full understand of the technology before
> > > throwing your opinion into the mix.
> > Why?  I doubt if anyone here fully understands rpm, deb or whatever.
> > I'm just trying to get my mind round what flatpack might mean in terms
> > of keeping my installation safe and easily maintained.
>
> Again, using Plasma Discover, Gnome Sotftware, or the cli with "flatpak
> update" is how you maintain your system. Since flatpak is repo based,
> getting your flatpaks from a trusted source is how you keep it secure. Just
> like you don't install software from random deb/rpm archives, you'd do the
> same for flatpaks.
>

OK, I tend to be a CLI person so there's a CLI with the flatpak
software, I had a bit of a problem to start with because I was
searching for 'flatpack' rather than 'flatpak'.  

It wasn't at all clear from the first announcement that the
flatpak utilities *do* come from the standard repositories, that was
my initial worry.  There seemed to be two layers of 'off repository'
software involved.   So that's not as difficult as I thought.

> >
> > It may very well be a good alternative/improvement over appimage, I'm
> > just trying to ensure that we're not losing the huge benefits that
> > well maintained repositories provide.
>
> AppImages aren't in a repo. You download them like you would an exe, then
> run them. There is no inherent sandboxing in AppImage (you'd need to use
> something like firejail), but flatpak has built in sandboxing. AppImages
> can't be signed, but flatpak includes GPG signing verification
> out-of-the-box.
>

But would the Dokuwiki images used by flatpack be inherently any
safer?  OK, there's GPG signing but that only guarantees that I'm
getting what the 'sender' wanted me to get, not that it's necessarily
safe.  Is it a big improvement that makes it worth yet another change?
There seem to be several approaches to this issue at the moment and
I'm a bit concerned that moving from one to another too often is
counter-productive.


> > I already stopped using snap.  Appimage is Ok'ish and if flatpack is
> > as good then I'm happy, I'm just trying to convince myself that
> > flatpack*is*  as good/safe as appimage.
>
> I wouldn't consider AppImage to be "safe" by any means. There is nothing
> inherent to AppImage that makes it safe to run on your system.

Yes, I quite agree, I'm not particularly happy using Appimage but
given that I want to cintinue to use Digikam (very much) I have to
really.  If we move to flatpak then I guess I'll move too.  

My questions are just my OCD/Paranoia about moving 'off repository'
and whether moving from one solution to another is necessary.

So, thank you for explaining this some more and thank you to the
Digikam development team for Digikam.  :-)

--
Chris Green

[Chris Green]

On Mon, May 25, 2020 at 08:03:20AM +0200, [hidden email] wrote:
> Le 24/05/2020 à 22:48, Chris Green a écrit :
>
> > appimage or flatpak are taking the right approach to doing this.  They
> > all seem to be looking for a way to bypass the existing way of doing
> > things.
> >
>
> like did systemd today largely adopted
>
A rather different situation though - and I'm still chasing some bugs
and problems introduced by systemd. :-)

The issue with snap/appimage/flatpak (at least as I understand what
they're trying to do) is that they couldn't be used to provide all of
a system's software.  Systemd wholly replaces the old startup/init
system (with a few hooks for legacy software), snap/appimage/flatpak
*can't* replace the whole of the existing software distribution
system.

--
Chris Green

[Stuart T Rogers]

Having read a bit about flatpak now I do have some concerns.

Firstly it seems that the actual deliverable will be considerably larger
than the normal install of Digikam say on openSUSE because it will need
to bundle in all the required other software it needs whether or not the
base OS already has the correct levels and versions installed.

Secondly while it runs in a sandbox it will likely increase the memory
requirement needed over what would normally be used because all the
additional code needed for execution will be loaded even if it already
exists and is loaded in the OS.

Thirdly this seems to me to be a sledgehammer to crack a nut since I
have not heard of any security breaches being caused by running Digikam,
yes some other applications maybe should be sandboxed because of what
they do but I do not see the need for this with Digikam.

Lastly it needs additional software installed on my system which
currently I do not use. Appimage does not need anything in addition to
be able to test a new version of Digikam.

This seems to me to be a solution looking for a purpose.

Stuart
--
Website: https://www.stella-maris.org.uk
or:      https//www.broadstairs.org

[Remco Viëtor]

On lundi 25 mai 2020 10:38:31 CEST Stuart T Rogers wrote:
> Having read a bit about flatpak now I do have some concerns.
>
> Firstly it seems that the actual deliverable will be considerably larger
> than the normal install of Digikam say on openSUSE because it will need
> to bundle in all the required other software it needs whether or not the
> base OS already has the correct levels and versions installed.

That would be the same for appimage or any other similar packaging. And it's
what is needed to make the package independent of the distribution and its
versioning.

> Secondly while it runs in a sandbox it will likely increase the memory
> requirement needed over what would normally be used because all the
> additional code needed for execution will be loaded even if it already
> exists and is loaded in the OS.
>
> Thirdly this seems to me to be a sledgehammer to crack a nut since I
> have not heard of any security breaches being caused by running Digikam,
> yes some other applications maybe should be sandboxed because of what
> they do but I do not see the need for this with Digikam.

But I have seen security updates for *libraries* dealing with the image
formats used by Digikam, like png.  So while the digikam code itself might not
need sandboxing, this doesn't hold for the needed libraries.

> Lastly it needs additional software installed on my system which
> currently I do not use. Appimage does not need anything in addition to
> be able to test a new version of Digikam.

That is the price for (semi-)automatic upgrades for the flatpaks. Appimage
does not provide a way to upgrade to newer versions.
 
> This seems to me to be a solution looking for a purpose.

Maybe. But I've had cases where the distribution-provided version was either
much older than the (then) current version or crippled as my distribution
didn't include a library or included a too old version.

So flatpak and appimage do have a use. That doesn't mean that having
distribution-maintained repositories is now superfluous, but for programs that
have a relatively small user-base, flatpak and similar have advantages.

Remco

Le 25/05/2020 à 11:34, Remco Viëtor a écrit :
> On lundi 25 mai 2020 10:38:31 CEST Stuart T Rogers wrote:

>> they do but I do not see the need for this with Digikam.
>
> But I have seen security updates for *libraries* dealing with the image
> formats used by Digikam, like png.  So while the digikam code itself might not
> need sandboxing, this doesn't hold for the needed libraries.
>

digikam deals directly with the file system (albums are folders), so yes
digikam is a sensible application

jdd


--
http://dodin.org

[Stuart T Rogers]

Yes I agree for some limited situations it may have a use. I for one
have used appimage to try out a new version but my distro (a rolling
release) is never far behind with providing stable releases of Digikam.

While the library thing may well need security fixes if I have the
library on my system normally it will get security fixes probably almost
as soon as they become available, how will I know these libraries will
need updating in the flatpak and whether or not the package has been
updated?

Stuart

On 25/05/2020 10:34, Remco Viëtor wrote:

> On lundi 25 mai 2020 10:38:31 CEST Stuart T Rogers wrote:
>> Having read a bit about flatpak now I do have some concerns.
>>
>> Firstly it seems that the actual deliverable will be considerably larger
>> than the normal install of Digikam say on openSUSE because it will need
>> to bundle in all the required other software it needs whether or not the
>> base OS already has the correct levels and versions installed.
>
> That would be the same for appimage or any other similar packaging. And it's
> what is needed to make the package independent of the distribution and its
> versioning.
>
>> Secondly while it runs in a sandbox it will likely increase the memory
>> requirement needed over what would normally be used because all the
>> additional code needed for execution will be loaded even if it already
>> exists and is loaded in the OS.
>>
>> Thirdly this seems to me to be a sledgehammer to crack a nut since I
>> have not heard of any security breaches being caused by running Digikam,
>> yes some other applications maybe should be sandboxed because of what
>> they do but I do not see the need for this with Digikam.
>
> But I have seen security updates for *libraries* dealing with the image
> formats used by Digikam, like png.  So while the digikam code itself might not
> need sandboxing, this doesn't hold for the needed libraries.
>
>> Lastly it needs additional software installed on my system which
>> currently I do not use. Appimage does not need anything in addition to
>> be able to test a new version of Digikam.
>
> That is the price for (semi-)automatic upgrades for the flatpaks. Appimage
> does not provide a way to upgrade to newer versions.
>  
>> This seems to me to be a solution looking for a purpose.
>
> Maybe. But I've had cases where the distribution-provided version was either
> much older than the (then) current version or crippled as my distribution
> didn't include a library or included a too old version.
>
> So flatpak and appimage do have a use. That doesn't mean that having
> distribution-maintained repositories is now superfluous, but for programs that
> have a relatively small user-base, flatpak and similar have advantages.
>
> Remco
>
>
>
>
>

--
Website: https://www.stella-maris.org.uk
or:      https//www.broadstairs.org

[Gilles Caulier-4]

Hi,

I just updated the Flatpak notice page on digikam source repository :

https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak

digiKam Flatpak is now compiled with ALL non-deprecated options,
including Web services using KIO. Look like the application resume is
well documented now, with plenty of screenshots.

By non deprecated, i want mean the 2 ones : Baloo and Akonady
supports. Both make a mess with digiKam (especially Baloo).

As i read, Flatpak is able to notify users when a new version is
published. I don't yet verified if it work well.

On Flatpak, it's possible to rate and review the application. So don't
hesitate to promote the application.

My best

Gilles Caulier


Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :

>
> Hi all users,
>
> I would to give some feedback about the digiKam bundles migration advance...
>
> The current files provided by the project are listed below :
>
> - Linux AppImage 64 bits
> - Linux AppImage 32 bits
> - Macos Package installer 64 bits (based on Macports)
> - Windows installer 64 bits (compiled with MXE - MinGW)
> - Windows installer 32 bits (compiled with MXE - MinGW)
>
> Current problems for these bundles are listed below :
>
> - AppImage : not signed, do not support KIO extensions, do not support
> ICU (language extension), not published on official repository.
> - MacOS package : It's not relocatable, even if MacOS support well
> this feature. I don't found the time to finalize yet the install
> relocation support in bash script. Package is not published on MacOS
> store.
> - MXE Windows installer : not signed, not published on Windows store.
> Do not support KIO extension.
>
> But we have a new one starting to work and i working on : FlatPak
>
> This one is signed, published of official repository automatically
> (you can install it on Discover application for ex). It support ICU
> and KIO too... FlatPak is compiled on KDE infrastructure nightly and
> automatically. Only a 64 bits version is supported.
>
> This want mean that AppImage end of life is near. We will still
> publish officially the AppImage until 7.0.0, but later, if FlatPak do
> the job as well, AppImage will be dropped...
>
> For Windows, all the digiKam code compile fine under Microsoft Visual
> C++ compiler. This is the goal to obtain a signed and published
> version on Microsoft store. You can imagine that Microsoft will only
> support the official Windows compiler, and not GCC to permit to sign
> and publish application on the store. Don't forget, Microsoft is well
> Closed Source (:=))))
>
> Microsoft compiler is just the hell. It slow and require a Windows
> operating system. The current cross compilation solution that we use
> work fully under Linux, and compilation time are reduced by 4/5 ! A
> full Linux Workflow is a non virus guaranty !
>
> The Visual C++ workflow is also only available on 64 bits and is
> computed on KDE infrastructure, but the installer compilation is
> broken due to a weird configuration on KDE infrastructure. I currently
> try to found a work around.
>
> Personalty, i don't want to left MXE solution for the moment.
>
> For MacOS, the KDE infrastructure based on Craft compilation framework
> will be a solution to sing and publish a relocatable package for
> Apple. digiKam do not compile yet due to  missing dependencies.
>
> Voilà, i hope to be enough clear with these technical points.
>
> My best
>
> Gilles Caulier

[Gilles Caulier-4]

Hi,

Another important point : the Flatpak do not include yet the
application translations files. It's relevant by the missing
sunversion executable on the KDE server.

And yes, all translations team from KDE project still to use
subversion to host i18n data.

As whole KDE migrate progressively from an own git/svn servers to
gitlab, i read that i18n will also migrate to git in the near future.
So wait and see...

Best

Gilles Caulier

Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :

>
> Hi,
>
> I just updated the Flatpak notice page on digikam source repository :
>
> https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak
>
> digiKam Flatpak is now compiled with ALL non-deprecated options,
> including Web services using KIO. Look like the application resume is
> well documented now, with plenty of screenshots.
>
> By non deprecated, i want mean the 2 ones : Baloo and Akonady
> supports. Both make a mess with digiKam (especially Baloo).
>
> As i read, Flatpak is able to notify users when a new version is
> published. I don't yet verified if it work well.
>
> On Flatpak, it's possible to rate and review the application. So don't
> hesitate to promote the application.
>
> My best
>
> Gilles Caulier
>
>
> Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
> >
> > Hi all users,
> >
> > I would to give some feedback about the digiKam bundles migration advance...
> >
> > The current files provided by the project are listed below :
> >
> > - Linux AppImage 64 bits
> > - Linux AppImage 32 bits
> > - Macos Package installer 64 bits (based on Macports)
> > - Windows installer 64 bits (compiled with MXE - MinGW)
> > - Windows installer 32 bits (compiled with MXE - MinGW)
> >
> > Current problems for these bundles are listed below :
> >
> > - AppImage : not signed, do not support KIO extensions, do not support
> > ICU (language extension), not published on official repository.
> > - MacOS package : It's not relocatable, even if MacOS support well
> > this feature. I don't found the time to finalize yet the install
> > relocation support in bash script. Package is not published on MacOS
> > store.
> > - MXE Windows installer : not signed, not published on Windows store.
> > Do not support KIO extension.
> >
> > But we have a new one starting to work and i working on : FlatPak
> >
> > This one is signed, published of official repository automatically
> > (you can install it on Discover application for ex). It support ICU
> > and KIO too... FlatPak is compiled on KDE infrastructure nightly and
> > automatically. Only a 64 bits version is supported.
> >
> > This want mean that AppImage end of life is near. We will still
> > publish officially the AppImage until 7.0.0, but later, if FlatPak do
> > the job as well, AppImage will be dropped...
> >
> > For Windows, all the digiKam code compile fine under Microsoft Visual
> > C++ compiler. This is the goal to obtain a signed and published
> > version on Microsoft store. You can imagine that Microsoft will only
> > support the official Windows compiler, and not GCC to permit to sign
> > and publish application on the store. Don't forget, Microsoft is well
> > Closed Source (:=))))
> >
> > Microsoft compiler is just the hell. It slow and require a Windows
> > operating system. The current cross compilation solution that we use
> > work fully under Linux, and compilation time are reduced by 4/5 ! A
> > full Linux Workflow is a non virus guaranty !
> >
> > The Visual C++ workflow is also only available on 64 bits and is
> > computed on KDE infrastructure, but the installer compilation is
> > broken due to a weird configuration on KDE infrastructure. I currently
> > try to found a work around.
> >
> > Personalty, i don't want to left MXE solution for the moment.
> >
> > For MacOS, the KDE infrastructure based on Craft compilation framework
> > will be a solution to sing and publish a relocatable package for
> > Apple. digiKam do not compile yet due to  missing dependencies.
> >
> > Voilà, i hope to be enough clear with these technical points.
> >
> > My best
> >
> > Gilles Caulier

[Mica Semrick]

If you want to continue to use your distro's native package, you should do that. Likewise if someone wants to volunteer to maintain the AppImage, they should do that.

That doesn't stop the project from using flatpak; they're not mutually exclusive.

On May 25, 2020 2:40:57 AM PDT, Stuart T Rogers <[hidden email]> wrote:

Yes I agree for some limited situations it may have a use. I for one 
have used appimage to try out a new version but my distro (a rolling 
release) is never far behind with providing stable releases of Digikam.

While the library thing may well need security fixes if I have the 
library on my system normally it will get security fixes probably almost 
as soon as they become available, how will I know these libraries will 
need updating in the flatpak and whether or not the package has been 
updated?

Stuart

On 25/05/2020 10:34, Remco Viëtor wrote:
On lundi 25 mai 2020 10:38:31 CEST Stuart T Rogers wrote:
 Having read a bit about flatpak now I do have some concerns.

 Firstly it seems that the actual deliverable will be considerably larger
 than the normal install of Digikam say on openSUSE because it will need
 to bundle in all the required other software it needs whether or not the
 base OS already has the correct levels and versions installed.

That would be the same for appimage or any other similar packaging. And it's
what is needed to make the package independent of the distribution and its
versioning.

 Secondly while it runs in a sandbox it will likely increase the memory
 requirement needed over what would normally be used because all the
 additional code needed for execution will be loaded even if it already
 exists and is loaded in the OS.

 Thirdly this seems to me to be a sledgehammer to crack a nut since I
 have not heard of any security breaches being caused by running Digikam,
 yes some other applications maybe should be sandboxed because of what
 they do but I do not see the need for this with Digikam.

But I have seen security updates for *libraries* dealing with the image
formats used by Digikam, like png.  So while the digikam code itself might not
need sandboxing, this doesn't hold for the needed libraries.

Lastly it needs additional software installed on my system which
currently I do not use. Appimage does not need anything in addition to
be able to test a new version of Digikam.

That is the price for (semi-)automatic upgrades for the flatpaks. Appimage
does not provide a way to upgrade to newer versions.
  
This seems to me to be a solution looking for a purpose.

Maybe. But I've had cases where the distribution-provided version was either
much older than the (then) current version or crippled as my distribution
didn't include a library or included a too old version.

So flatpak and appimage do have a use. That doesn't mean that having
distribution-maintained repositories is now superfluous, but for programs that
have a relatively small user-base, flatpak and similar have advantages.

Remco

[Gilles Caulier-4]

Look like digiKam will be also added to official FlatHub repository soon :

https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061

Gilles Caulier

Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :

>
> Hi,
>
> Another important point : the Flatpak do not include yet the
> application translations files. It's relevant by the missing
> sunversion executable on the KDE server.
>
> And yes, all translations team from KDE project still to use
> subversion to host i18n data.
>
> As whole KDE migrate progressively from an own git/svn servers to
> gitlab, i read that i18n will also migrate to git in the near future.
> So wait and see...
>
> Best
>
> Gilles Caulier
>
> Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
> >
> > Hi,
> >
> > I just updated the Flatpak notice page on digikam source repository :
> >
> > https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak
> >
> > digiKam Flatpak is now compiled with ALL non-deprecated options,
> > including Web services using KIO. Look like the application resume is
> > well documented now, with plenty of screenshots.
> >
> > By non deprecated, i want mean the 2 ones : Baloo and Akonady
> > supports. Both make a mess with digiKam (especially Baloo).
> >
> > As i read, Flatpak is able to notify users when a new version is
> > published. I don't yet verified if it work well.
> >
> > On Flatpak, it's possible to rate and review the application. So don't
> > hesitate to promote the application.
> >
> > My best
> >
> > Gilles Caulier
> >
> >
> > Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
> > >
> > > Hi all users,
> > >
> > > I would to give some feedback about the digiKam bundles migration advance...
> > >
> > > The current files provided by the project are listed below :
> > >
> > > - Linux AppImage 64 bits
> > > - Linux AppImage 32 bits
> > > - Macos Package installer 64 bits (based on Macports)
> > > - Windows installer 64 bits (compiled with MXE - MinGW)
> > > - Windows installer 32 bits (compiled with MXE - MinGW)
> > >
> > > Current problems for these bundles are listed below :
> > >
> > > - AppImage : not signed, do not support KIO extensions, do not support
> > > ICU (language extension), not published on official repository.
> > > - MacOS package : It's not relocatable, even if MacOS support well
> > > this feature. I don't found the time to finalize yet the install
> > > relocation support in bash script. Package is not published on MacOS
> > > store.
> > > - MXE Windows installer : not signed, not published on Windows store.
> > > Do not support KIO extension.
> > >
> > > But we have a new one starting to work and i working on : FlatPak
> > >
> > > This one is signed, published of official repository automatically
> > > (you can install it on Discover application for ex). It support ICU
> > > and KIO too... FlatPak is compiled on KDE infrastructure nightly and
> > > automatically. Only a 64 bits version is supported.
> > >
> > > This want mean that AppImage end of life is near. We will still
> > > publish officially the AppImage until 7.0.0, but later, if FlatPak do
> > > the job as well, AppImage will be dropped...
> > >
> > > For Windows, all the digiKam code compile fine under Microsoft Visual
> > > C++ compiler. This is the goal to obtain a signed and published
> > > version on Microsoft store. You can imagine that Microsoft will only
> > > support the official Windows compiler, and not GCC to permit to sign
> > > and publish application on the store. Don't forget, Microsoft is well
> > > Closed Source (:=))))
> > >
> > > Microsoft compiler is just the hell. It slow and require a Windows
> > > operating system. The current cross compilation solution that we use
> > > work fully under Linux, and compilation time are reduced by 4/5 ! A
> > > full Linux Workflow is a non virus guaranty !
> > >
> > > The Visual C++ workflow is also only available on 64 bits and is
> > > computed on KDE infrastructure, but the installer compilation is
> > > broken due to a weird configuration on KDE infrastructure. I currently
> > > try to found a work around.
> > >
> > > Personalty, i don't want to left MXE solution for the moment.
> > >
> > > For MacOS, the KDE infrastructure based on Craft compilation framework
> > > will be a solution to sing and publish a relocatable package for
> > > Apple. digiKam do not compile yet due to  missing dependencies.
> > >
> > > Voilà, i hope to be enough clear with these technical points.
> > >
> > > My best
> > >
> > > Gilles Caulier

[JayRutherford]

Good news! I upgraded Linux Mint to 18.3, which has flatpak built in and now have some applications running under flatpak.

Jay Rutherford

On Mon, May 25, 2020, at 17:49, Gilles Caulier wrote:

> Look like digiKam will be also added to official FlatHub repository soon :
>
> https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061
>
> Gilles Caulier
>
> Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :
> >
> > Hi,
> >
> > Another important point : the Flatpak do not include yet the
> > application translations files. It's relevant by the missing
> > sunversion executable on the KDE server.
> >
> > And yes, all translations team from KDE project still to use
> > subversion to host i18n data.
> >
> > As whole KDE migrate progressively from an own git/svn servers to
> > gitlab, i read that i18n will also migrate to git in the near future.
> > So wait and see...
> >
> > Best
> >
> > Gilles Caulier
> >
> > Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
> > >
> > > Hi,
> > >
> > > I just updated the Flatpak notice page on digikam source repository :
> > >
> > > https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak
> > >
> > > digiKam Flatpak is now compiled with ALL non-deprecated options,
> > > including Web services using KIO. Look like the application resume is
> > > well documented now, with plenty of screenshots.
> > >
> > > By non deprecated, i want mean the 2 ones : Baloo and Akonady
> > > supports. Both make a mess with digiKam (especially Baloo).
> > >
> > > As i read, Flatpak is able to notify users when a new version is
> > > published. I don't yet verified if it work well.
> > >
> > > On Flatpak, it's possible to rate and review the application. So don't
> > > hesitate to promote the application.
> > >
> > > My best
> > >
> > > Gilles Caulier
> > >
> > >
> > > Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
> > > >
> > > > Hi all users,
> > > >
> > > > I would to give some feedback about the digiKam bundles migration advance...
> > > >
> > > > The current files provided by the project are listed below :
> > > >
> > > > - Linux AppImage 64 bits
> > > > - Linux AppImage 32 bits
> > > > - Macos Package installer 64 bits (based on Macports)
> > > > - Windows installer 64 bits (compiled with MXE - MinGW)
> > > > - Windows installer 32 bits (compiled with MXE - MinGW)
> > > >
> > > > Current problems for these bundles are listed below :
> > > >
> > > > - AppImage : not signed, do not support KIO extensions, do not support
> > > > ICU (language extension), not published on official repository.
> > > > - MacOS package : It's not relocatable, even if MacOS support well
> > > > this feature. I don't found the time to finalize yet the install
> > > > relocation support in bash script. Package is not published on MacOS
> > > > store.
> > > > - MXE Windows installer : not signed, not published on Windows store.
> > > > Do not support KIO extension.
> > > >
> > > > But we have a new one starting to work and i working on : FlatPak
> > > >
> > > > This one is signed, published of official repository automatically
> > > > (you can install it on Discover application for ex). It support ICU
> > > > and KIO too... FlatPak is compiled on KDE infrastructure nightly and
> > > > automatically. Only a 64 bits version is supported.
> > > >
> > > > This want mean that AppImage end of life is near. We will still
> > > > publish officially the AppImage until 7.0.0, but later, if FlatPak do
> > > > the job as well, AppImage will be dropped...
> > > >
> > > > For Windows, all the digiKam code compile fine under Microsoft Visual
> > > > C++ compiler. This is the goal to obtain a signed and published
> > > > version on Microsoft store. You can imagine that Microsoft will only
> > > > support the official Windows compiler, and not GCC to permit to sign
> > > > and publish application on the store. Don't forget, Microsoft is well
> > > > Closed Source (:=))))
> > > >
> > > > Microsoft compiler is just the hell. It slow and require a Windows
> > > > operating system. The current cross compilation solution that we use
> > > > work fully under Linux, and compilation time are reduced by 4/5 ! A
> > > > full Linux Workflow is a non virus guaranty !
> > > >
> > > > The Visual C++ workflow is also only available on 64 bits and is
> > > > computed on KDE infrastructure, but the installer compilation is
> > > > broken due to a weird configuration on KDE infrastructure. I currently
> > > > try to found a work around.
> > > >
> > > > Personalty, i don't want to left MXE solution for the moment.
> > > >
> > > > For MacOS, the KDE infrastructure based on Craft compilation framework
> > > > will be a solution to sing and publish a relocatable package for
> > > > Apple. digiKam do not compile yet due to  missing dependencies.
> > > >
> > > > Voilà, i hope to be enough clear with these technical points.
> > > >
> > > > My best
> > > >
> > > > Gilles Caulier
>

[Brian Morrison]

On Mon, 2020-05-25 at 23:49 +0200, Gilles Caulier wrote:
> Look like digiKam will be also added to official FlatHub repository
> soon :
>
> https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061
>

https://www.xkcd.com/927/

--

Brian