Bug#998108: Rebuild w/ new toolchain

[Simon Frei]

On 08/11/2021 12:21, Jakob Haufe wrote:

On Mon, 8 Nov 2021 10:25:24 +0100
Matthias Urlichs  wrote:


Looks like the problem is a toolchain matter and requires a rebuild with
Rust 1.56.

https://bugzilla.opensuse.org/show_bug.cgi?id=1192067

According to the build log, 94.0-1 has been built with 1.56.



I read that bug as saying that 1.56 does not have any changes compared 
to 1.55 that are likely to change anything. They talk about 1.55 
requiring llvm12, not llvm13. As far as I understand their fix was to go 
back to rust 1.55 with llvm12.
When I look at the dependencies of firefox, it does depend on rust 1.56, 
which in turn was built with llvm13, so that's fine. However firefox 
also depends on libgl1-mesa-dri and mesa-va-drivers, which depend on 
llvm12. Maybe this discrepancy is the culprit?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#956712: emacs: https to plain http downgrade after unhandled GNUTLS_E_AGAIN error in TLS1.3 connection

[Simon Frei]

fixed 956712 1:26.3+1-2
thanks

I can confirm that as reported by Heenec, this is fixed in unstable 
given it's on 26.3 now.

Bug#952426: digikam: digkam experimental not correctly instalable

[Simon Frei]

On 25/02/2020 10:27, Agustin Martin wrote:
>
> There is still the problem of the undeclared digikam dependency on the
> hdf5 stuff.
>
There's no such problem, digikam does not in itself depend on hdf5
(https://www.digikam.org/api/index.html#externaldeps). As I wrote
earlier, it depends on it through opencv, on which it depends directly:

i   digikam    Depends digikam-private-libs (=
4:7.0.0~beta2+dfsg-1)
i A digikam-private-libs   Depends libopencv-imgcodecs4.2 (>=
4.2.0+dfsg)  
i A libopencv-imgcodecs4.2 Depends libgdal26 (>=
2.0.1)
i A libgdal26  Depends libhdf5-103

Bug#952426: digikam: digkam experimental not correctly instalable

[Simon Frei]

On 24/02/2020 11:38, Eric Valette wrote:
> On 24/02/2020 10:50, Simon Frei wrote:
>
>> one is 103. That suggests you aren't running the digikam binary from the
>> package, but something else (maybe you self-compiled at some point?).
>> Check the output of which digikam.
>
>
> Did you just test your packages before uploading?
>
>  ldd /usr/bin/digikam  | grep libhd
>     libhdf5_serial.so.103 =>
> /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x7fd2c60f2000)
>     libhdf5_serial_hl.so.100 => not found
>
Firstly: I don't upload digikam to debian. I am just a user interested
in having it packaged and very occasional contributor upstream. By
helping to triage and clarify bugs I hope to remove some workload from
Steve (uploader), which hopefully makes it more likely to keep getting
packages from him (thanks a lot for that!).

And my bad, apparently libhdf5-103 still ships the .100 lib:

    libhdf5-103: /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.100

At least it does in testing. I now upgraded libhdf5-103 to experimental
and I do get the same error you do. Maybe at the time the experimental
build was done the old version of hdf5 was still in experimental. Anyway
the fix for you is to downgrade libhdf5-103 to unstable and for the
package probably as simple as a rebuild (which in my opinion isn't
really necessary unless there's another change, e.g. beta3).

Bug#952426: digikam: digkam experimental not correctly instalable

[Simon Frei]

On Mon, 24 Feb 2020 10:14:54 +0100 Eric Valette 
wrote:
> digikam
> digikam: error while loading shared libraries:
libhdf5_serial_hl.so.100: cannot open shared object file: No such file
or directory
>
> Has already been reported.

Did you just copy the error message from there, or did this error come
up with the package from experimental installed?

> But in addition,
>
> LANG="C" apt-get -t experimental install libhdf5-hl-100

That package isn't in experimental, so the error you get is entirely
expected.
Digikam in experimental (4:7.0.0~beta2+dfsg-1) does depend on hdf, but a
different version:

i   digikam                Depends digikam-private-libs (=
4:7.0.0~beta2+dfsg-1)
i A digikam-private-libs    Depends libopencv-imgcodecs4.2 (>=
4.2.0+dfsg)  
i A libopencv-imgcodecs4.2 Depends libgdal26 (>=
2.0.1)
i A libgdal26             Depends libhdf5-103

The error message you quote refers to so-version 100, while the required
one is 103. That suggests you aren't running the digikam binary from the
package, but something else (maybe you self-compiled at some point?).
Check the output of which digikam.

Bug#893515: digikam: FTBFS with kdepim 17.12.2

[Simon Frei]

I totally understand that, I am just trying to get infos to you as
debian maintainer from my (at the moment admittedly almost non-existing)
involvement upstream. Exiv2 0.26 will likely not get into testing.
Upstream does backport a lot of security fixes to 0.26, but negated
creating a dot release on request, and is focussing on 0.27. It was
planned to release an rc in early 2018, but from what I read in the
issue tracker, that's not going to happen asap.



signature.asc
Description: OpenPGP digital signature

Bug#893515: digikam: FTBFS with kdepim 17.12.2

[Simon Frei]

Digikam still works with exiv2 0.25. It's just that a lot of fixes have
gone into 0.26 that prevent crashs in digikam, that's why its cmake file
has a >=0.26 dependency.



signature.asc
Description: OpenPGP digital signature

Bug#876242: exiv2: CVE-2017-12957

[Simon Frei]

This has been fixed and and also backported to 0.26 upstream:
https://github.com/Exiv2/exiv2/issues/60

forwarded 876242 https://github.com/Exiv2/exiv2/issues/60
tags fixed-upstream
thanks

Bug#849476: libopencv-dev: fails to install on experimental due to inconsistent version suffix '+b1'

[Simon Frei]

Package: libopencv-dev
Version: 3.1.0+dfsg-1~exp2
Severity: serious

Hi,

Trying to install libopencv-dev from experimental fails:

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
libopencv-dev : Depends: libopencv3.1-java (= 3.1.0+dfsg-1~exp2+b1)
but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

The problem is that all binary packages in experimental are version
3.1.0+dfsg-1~exp2+b1 except libopencv3.1-java which is
3.1.0+dfsg-1~exp2. As libopencv depends on the latter, it fails as its
version number is older.

Cheers,
Simon

Bug#798850: update resolved bug

[Simon Frei]

A recent upgrade resolved this bug, it can be closed.

Bug#798850: enfuse: Immediate segmentation fault on launch

[Simon Frei]

Package: enfuse
Version: 4.1.3+dfsg-2
Severity: grave
Justification: renders package unusable



-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages enfuse depends on:
ii  libboost-filesystem1.55.0  1.55.0+dfsg-4
ii  libboost-system1.55.0  1.55.0+dfsg-4
ii  libc6  2.19-19
ii  libgcc11:5.2.1-16
ii  libgomp1   5.2.1-16
ii  libgsl0ldbl1.16+dfsg-4
ii  liblcms2-2 2.6-3+b3
ii  libstdc++6 5.2.1-16
ii  libtiff5   4.0.5-1
ii  libvigraimpex4 1.9.0+dfsg-10+b3

Versions of packages enfuse recommends:
ii  hugin  2015.0.0~rc3+dfsg-1+b1

enfuse suggests no packages.

-- no debconf information

When I invoke enfuse it aborts immediately with a segmentation fault. This is 
independent of the specified input files.
Gdb backtrace:

Starting program: /usr/bin/enfuse *expo*
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x7695562b in std::basic_string::basic_string(std::string const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#0  0x7695562b in std::basic_string::basic_string(std::string const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00450eaa in ?? ()
#2  0x004088c5 in ?? ()
#3  0x75dccb45 in __libc_start_main (main=0x4085a0, argc=4, 
argv=0x7fffe278, init=, fini=, 
rtld_fini=, stack_end=0x7fffe268) at libc-start.c:287
#4  0x0040c33e in ?? ()