Various packages for darktable

Software darktable
78

Sorry but it isn’t clear to me.
I tried this

wget -nv https://download.opensuse.org/repositories/graphics:darktable:master/xUbuntu_20.04/Release.key -O Release.key

but it doesn’t exist.

What do you mean by the OBS in general has 20.04 set up?
What should I do to get dt dev master branch?

79

There is a difference between build.opensuse.org in general supports a distribution and it being configured for a specifc project (graphics:darktable:master). You will have to wait until the darktable package maintainers have time for that.

80

No problem, the current dt release that I have (before upgrading ubuntu) is stable, so I’ll wait until we have new packages.

Thanks for the hard work on maintaining them!

81

@darix & other package maintainers, thanks for having made available packages for Ubuntu 20.04!

82

It was @asn. Not me. I am not touching the packages anymore.

83

I just had a quick glance at the OBS build-logs for darktable 3.0.2 on Ubuntu 18.04 and 20.04 and noticed that the builds seem to fail while trying to apply a patch to src/iop/basicadj.c.

I speculate that this is the fix for the bug in the Basic Adjustments module that snuck into the 3.0.1 release and that @darix included in the RPM and DEB packages for that version.

[  497s]  dpkg-source -b BUILD
[  498s] dpkg-source: info: using source format '3.0 (quilt)'
[  498s] dpkg-source: info: building darktable using existing ./darktable_3.0.2.orig.tar.gz
[  499s] patching file src/iop/basicadj.c
[  499s] Hunk #1 FAILED at 90.
[  499s] 1 out of 1 hunk FAILED
[  499s] dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
[  499s] dpkg-source: info: if patch '8bceae80bd8459f4ec5929df75d6ec0471c3d26c.patch' is correctly applied by quilt, use 'quilt refresh' to update it
[  499s] dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B  .pc/8bceae80bd8459f4ec5929df75d6ec0471c3d26c.patch/ --reject-file=- < BUILD.orig.jIGtAP/debian/patches/8bceae80bd8459f4ec5929df75d6ec0471c3d26c.patch subprocess returned exit status 1
[  499s] dpkg-buildpackage: error: dpkg-source -b BUILD subprocess returned exit status 2

I don’t have any experience with using OBS or packaging RPMs or DEB, so I really have no idea how to resolve this, other than trying to exclude that patch from the build process (b/c the fix should be already in the source for 3.0.2 in any case).

84

When could we have packages for ubuntu 20.10 as well?
Hopefully at least in time for 3.4?

85

I think this is still the only valid response… The darktable development team doesn’t do distributions, afaik.
As for “in time for 3.4”: packages won’t be available at the release date, that’s for sure. The repository maintainers (volunteers, in general) will need at least a few days to prepare and publish the packages…

If you want to know what’s available, just keep an eye on the repositories referred to by @revilo

86

if you have no clue what you are talking about. sometimes it is better to stay quiet.

87

You’re right, my apologies

88

Hi @asn,
thanks for the OBS packages!
I am using the package graphics:darktable:master from OBS (on Ubuntu 20.04), but I cannot use the lua scripts.
If I run the darktable --version command I see that lua is disabled.
Is it possible to activate it? or is there some technical reason?
Thank you

89

the next release will require lua 5.4 which is not supported on ubuntu 20.04. so you will have to upgrade your OS.

3 Likes
90

Thank you darix!

91

That’s interesting to know, thanks @darix! I guess time to research a replacement distro!

92

would a flatpak be feasible on 20.04 in the interim until the next LTS? I’m guessing there’s many of us using LTS these days. The next one is 22.04

2 Likes
93

I believe there is already a darktable flatpak available, however I’m not sure it supports OpenCL acceleration.

94

The flatpak supports openCL for nvidia cards.

2 Likes
95

I can confirm that. Just installed it on a Zorin OS 16 system (based on Ubuntu 20.04 with Nvidia graphics, and it works.

1 Like
96

That’s good to know. I do however prefer “native” applications where possible, rather than “bloated” flatpaks.

97

I’m not too concerned about the space demands of the few Flatpaks I run. Space is cheap, and if a flatpak solves a problem of a package that’s not working well, I’ll take it. As an example, I’m working on a video in Kdenlive, and the proxies are not being created reliably. I switched over the flatpak version and that’s working well. If I switched earlier, I would have saved a lot of time trying to solve an issue I’m ill equipped to handle.

1 Like