Bug#1063900: gstreamer1.0-plugins-good: missing Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)

[Richard B]

Hello.

Upgrading gstreamer1.0-plugins-ugly to 1.24.3-1 on Trixie didn't produce 
the error that was originally reported.  Here's my output:


   Retrieving bug reports... Done
   Parsing Found/Fixed information... Done
   serious bugs of gstreamer1.0-plugins-good (1.22.10-1 → 1.24.3-1)
   
 b1 - #1063900 - gstreamer1.0-plugins-good: missing
   Breaks+Replaces: gstreamer1.0-plugins-ugly (<< 1.23)
   Merged with: 1063921
   Summary:
 gstreamer1.0-plugins-good(1 bug)
   Are you sure you want to install/upgrade the above packages?
   [Y/n/?/...] y
   Reading changelogs... Done
   ...
   Preparing to unpack .../gstreamer1.0-plugins-good_1.24.3-1_amd64.deb ...
   Unpacking gstreamer1.0-plugins-good:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   Preparing to unpack .../gstreamer1.0-plugins-bad_1.24.3-1_amd64.deb ...
   Unpacking gstreamer1.0-plugins-bad:amd64 (1.24.3-1) over (1.22.10-1) ...
   ...
   Preparing to unpack
   .../04-libgstreamer-plugins-bad1.0-0_1.24.3-1_amd64.deb ...
   Unpacking libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   Preparing to unpack
   .../05-gir1.2-gst-plugins-bad-1.0_1.24.3-1_amd64.deb ...
   Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) over
   (1.22.10-1) ...
   ...
   Setting up libgstreamer-plugins-bad1.0-0:amd64 (1.24.3-1) ...
   Setting up gir1.2-gst-plugins-bad-1.0:amd64 (1.24.3-1) ...
   Setting up gstreamer1.0-plugins-good:amd64 (1.24.3-1) ...
   Setting up gstreamer1.0-plugins-bad:amd64 (1.24.3-1) ...
   Processing triggers for libc-bin (2.38-7) ...

I see that the conflicting files mentioned are on my system, but that 
didn't seem to impact my upgrade:


   -rw-r--r-- 1 root root 27K Apr 30 04:18
   /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrnb.so
   -rw-r--r-- 1 root root 19K Apr 30 04:18
   /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstamrwbdec.so
   -rw-r--r-- 1 root root 208 Apr 29 18:15
   /usr/share/gstreamer-1.0/presets/GstAmrnbEnc.prs

gstreamer1.0-plugins-ugly was upgraded to a matching version before 
this.  Here's what dpkg reports:


   ii  gstreamer1.0-plugins-ugly:amd64
   1.24.3-1 amd64    GStreamer plugins
   from the "ugly" set

Best.

Richard

Bug#1061731: fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish”

[Richard B]

Hello.

I can confirm that upgrading fwupd and libfwupd2 on Trixie to 1.9.14-1 
and installing the package maintainer's version of /etc/fwupd/fwupd.conf 
allowed the fwupd status to start:


   sudo apt upgrade
   Reading package lists... Done
   Building dependency tree... Done
   Reading state information... Done
   Calculating upgrade... Done
   The following packages will be upgraded:
  fwupd libfwupd2
   2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
   Need to get 0 B/3,833 kB of archives.
   After this operation, 54.3 kB of additional disk space will be used.
   Do you want to continue? [Y/n] y
   Retrieving bug reports... Done
   Parsing Found/Fixed information... Done
   serious bugs of fwupd (1.9.11-1 → 1.9.14-1) 
 b1 - #1061731 - fwupd: Failed to load daemon: failed to load
   engine: Failed to load config: Key file does not have group “redfish”
   Summary:
 fwupd(1 bug)
   Are you sure you want to install/upgrade the above packages?
   [Y/n/?/...] y
   Reading changelogs... Done
   ...
   Configuration file '/etc/fwupd/fwupd.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
   *** fwupd.conf (Y/I/N/O/D/Z) [default=N] ? y
   Installing new version of config file /etc/fwupd/fwupd.conf ...
   fwupd-offline-update.service is a disabled or a static unit not
   running, not starting it.
   fwupd-refresh.service is a disabled or a static unit not running,
   not starting it.
   fwupd.service is a disabled or a static unit not running, not
   starting it.
   Processing triggers for libc-bin (2.37-15) ...
   Processing triggers for man-db (2.12.0-3) ...
   Processing triggers for dbus (1.14.10-4) ...
   Processing triggers for hicolor-icon-theme (0.17-2) ...

   systemctl status fwupd
   ○ fwupd.service - Firmware update daemon
 Loaded: loaded (/usr/lib/systemd/system/fwupd.service; static)
 Active: inactive (dead)
   Docs: https://fwupd.org/

   sudo systemctl start fwupd

   systemctl status fwupd
   ● fwupd.service - Firmware update daemon
 Loaded: loaded (/usr/lib/systemd/system/fwupd.service; static)
 Active: active (running) since Thu 2024-03-07 16:37:27 CST; 3s ago
   Docs: https://fwupd.org/
   Main PID: 22184 (fwupd)
  Tasks: 7 (limit: 18110)
 Memory: 23.7M (peak: 108.7M)
    CPU: 988ms
 CGroup: /system.slice/fwupd.service
 └─22184 /usr/libexec/fwupd/fwupd

I kept fwupd at 1.9.11-1 since this bug was reported, but the new 
version seems to be in the clear.


Best.

Richard

Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

[Richard B. Kreckel]

On 2/5/24 00:08, Jeremy Bícha wrote:

I do not believe your issue is the same since you are still able to
log in to your NextCloud, but the original bug poster is not.


Okay.


Yes, I believe it is expected that updating GNOME Online Accounts to
3.49 will require reauthenticating. Authentication is now handled in
the user's regular web browser instead of a webkitgtk dialog which
makes login more reliable and should be more resilient to
authentication changes from upstream providers.


I was looking for information like this pointing out the 
incompatibility. (The changelog does mention that authentication for 
Google & Microsoft now uses the web browser, but nothing about nextCloud 
etc.)



It is not expected that everything will work if you try to share
configuration between different operating system versions. Sorry.


:(   Ouch! This is so frustrating.

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

[Richard B. Kreckel]

Confirmed: Same problem here for nextCloud and for google accounts.

Gnome files says "Unable to access usern...@googlemail.com Invalid 
credentials for usern...@googlemail.com".
Same for nextCloud accounts. goa-daemon says 
"/org/gnome/OnlineAccounts/Accounts/account_1706819076_1: Setting 
AttentionNeeded to TRUE
 because EnsureCredentials() failed with: Invalid password with 
username “username” (goa-error-quark, 4): Authentication failed (goa-e

rror-quark, 4)

I can remove the accounts and re-add them. But then they don't work with 
gnome-online-accounts 3.46.0-1 (Debian stable machine where same home 
dir is mounted). There, I can remove them and re-add them. But changing 
to 3.49.0-1 from testing all starts over again.


Seems like compatibility broke badly.

Bug#1033847: closed by Debian FTP Masters (reply to gabr...@debian.org (Gabriel F. T. Gomes)) (Bug#1033847: fixed in bash-completion 1:2.11-7)

[Richard B. Kreckel]

Gabriel,

On 7/17/23 08:39, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the bash-completion package:

#1033847: Please update to upstream sources

It has been closed by Debian FTP Masters  
(reply to gabr...@debian.org (Gabriel F. T. Gomes)).


You seem to have fixed the NIS issue by removing the specific Debian 
patch. That's great. Thank you!


Would it be possible to update the package to the current upstream 
version? The Debian package is lagging three years behind, after all.


  -richy.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033847: Please update to upstream sources

[Richard B. Kreckel]

On 4/10/23 19:55, Sergio Durigan Junior wrote:

 fix_quote_readline_by_ref.patch, thanks to JuanJo Ciarlante (Closes: 
#739835)
 
 + avoid escaping 1st '~' (LP: #1288314)

 + avoid quoting if empty, else expansion without args only shows
   dirs (LP: #1288031)
 + replace double escaping to single (eg for completing file/paths
   with spaces)


Bingo! What I observe is reported in #825317.

I can confirm that adding a backslash before ~* in 
_quote_readline_by_ref() stops bash doing the very expensive NSS lookup.


Using the upstream version of the function has the same effect, of course.

In my humble opinion, this is a prime example that Debian (and Ubuntu) 
maintainers should be careful with their patches, especially in 
well-maintained packages.


Best wishes,
  -richard.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1033847: Please update to upstream sources

[Richard B. Kreckel]

Gabriel,

Times are changing. Many upstream maintainers don't do releases any more 
and instead rely on CI to maintain a good quality level. Unfortunately, 
this change often goes without announcement and unnoticed by package 
maintainers, leading to the situation you describe.


In cases like this, it might be best to check with upstream and ask them 
about their intentions. It may be that you'll never see a release tag 
again. Then, it would be best to just take the most up-to-date git version.


Regarding my hangs: It is because something's broken in my NIS 
(yellow-pages) setup (haven't fully analyzed yet). It turns out that, 
when doing tab completion, your patch 00-fix_quote_readline_by_ref.patch 
tries to match against ~*, which incurs a NIS look-up and that blocks.
The upstream version doesn't do that and it seems like the patch has 
never been applied.

Are you sure it is necessary?
If no: can it be removed?
If yes: has it been reported upstream and what was the response?

Best wishes,
   -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1033847: Please update to upstream sources

[Richard B. Kreckel]

The reproducible hang on my system turns out to be caused by Debian's 
00-fix_quote_readline_by_ref.patch. Without it, tab completion returns 
immediately. This patch is not there upstreams. Is it really needed?


It hangs at the line comparing $1 to ~*. Not sure what it does.

Bug#1033847: Please update to upstream sources

[Richard B. Kreckel]

Package: bash-completion
Version: 1:2.11-6
Severity: important

The current package version was taken from upstream somewhen in 2020. 
Since then, a lot has happened upstream.


Please update this package to the current upstream version. That version 
is reasonably maintained.


I got here (and classify this as 'important') because there seem to be 
really annoyhing bugs in the old version. I have a problem where file 
completion of ls reproducibly hangs for many seconds in the _filedir 
function. This does not happen when I swap 
/usr/share/bash-completion/bash_completion for the upstream version. I 
am not sure it's worth debugging this further, given the outdated state 
of this package in Debian.


  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1033624: obs-studio: Pipewire capture source not listed

[Richard B. Kreckel]

On 3/28/23 22:12, Kevin Otte wrote:

When I attempt to add a source to the current scene, I do not see the "Screen 
Capture (Pipewire)" option listed as demonstrated in the screenshot at 
https://www.linuxuprising.com/2021/06/obs-studio-27-released-with-wayland-and.html

As such, I am unable to capture the screen under Wayland (specifically, sway).


Do you have xdg-desktop-portal-gnome installed? (See bug #1031645.)

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031645: gnome-shell should depend on xdg-desktop-portal-gnome

[Richard B. Kreckel]

On 2/19/23 20:31, Simon McVittie wrote:

[...]
* gnome-core, a GNOME system with essential utilities like a login prompt,
   preferences, a file manager and a text editor, which Depends on
   gnome-session, and also on xdg-desktop-portal-gnome specifically;


Okay, you managed to convince me that gnome-core should pull it in, not 
gnome-shell.


(For some weird reason gnome-core was not installed on my machines 
although I've been using them with GNOME for ages.)


I'm gonna close this bug then.

  -richy.

Bug#1031645: gnome-shell should depend on xdg-desktop-portal-gnome

[Richard B. Kreckel]

Package: gnome-shell
Version: 43.2-2

The package should pull in xdg-desktop-portal-gnome.

After all, "GNOME Shell is the defining technology of the GNOME 3 user 
experience." A system without xdg-desktop-portal-gnome installed will 
not provide some of this experience, like the ability to do screen 
captures (PipeWire) in OBS studio, etc.


Related: https://bugzilla.redhat.com/show_bug.cgi?id=2074189

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On Wed, 11 Jan 2023 09:43:31 +0100 Sylvestre Ledru 
 wrote:
go: could not create module cache: mkdir /sbuild-nonexistent: permission 
denied

To make this go away, the package must Build-Depend on dh-golang.

However, that does not seem to be enough. The way subpackages are 
fetched or not during build is not very clear to me. How did you put 
together the 2.9.0 source package?


  -richard.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/9/23 23:26, Sylvestre Ledru wrote:

Le 08/01/2023 à 00:46, Richard B. Kreckel a écrit :


2) Based on mozillavpn_2.9.0-1.debian.tar.xz, apply some changes to 
debian/ directory:
   a) -DBUILD_TESTING=OFF to dh_auto_configure argument in 
debian/rules (without it it FTBFS trying to run some tests and that is 
also in upstream's rules file)
   d) change rm -rf debian/mozillavpn/etc/opt/chrome to rm -rf 
debian/mozillavpn/etc/opt in debian/rules so purge won't remove 
/etc/opt/ since there's nothing in there anyway
   c) Add packages python3-click and python3-jinja2 to Build-Depnds in 
debian/control (without these, it FTBFS)
   d) remove libqt6* and qt6-qpa-plugins dependencies in 
debian/control (see #1026957).



I tried with these changes but I am getting:


/<>/src/connectionbenchmark/benchmarktaskdownload.cpp:50:4: 
error: #error Check if QT added support for QDnsLookup::lookup() on Android
    50 | #  error Check if QT added support for QDnsLookup::lookup() on 
Android

   |    ^
[ 56%] Building CXX object 
src/CMakeFiles/mozillavpn.dir/connectionbenchmark/benchmarktaskping.cpp.o


rings a bell?


Sure.

Mozillavpn 2.9.0 #errors out there if QT_VERSION >= 0x060400.

The current qt6-base-dev in the archive is 6.4.2+dfsg~rc1-3 and that 
#defines QT_VERSION 060402. Hence, #error...


You must have been compiling Mozillavpn version 2.9.0, and not 2.12.0, 
as I recommended! (It was Andrea Marchesini who changed this upstream 
2022-10-06.)


All my best,
  -richard.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/9/23 10:38, Sylvestre Ledru wrote:

Or just push a fork on github. I can take it for there :)


For work-related reasons this isn't going to happen the next few weeks.

Can you, please, update to 1.12.0 and include the minor described fixes 
to debian/*? It should work, afaict.


  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

On 1/8/23 12:36, Richard B. Kreckel wrote:

I am unfamiliar with GitLab. Sorry.


Well, then I thought that could give it a try...

Is there a simple walk-through what to do to create salsa MRs in a case 
like this package?


(I've spent the whole Sunday now and I'm giving up frustrated by the 
existing documentation now.)


  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

Szlvestre,

On 1/8/23 00:54, Sylvestre Ledru wrote:
Could you please submit a MR here ? 
https://salsa.debian.org/sylvestre/mozillavpn


I will be happy to upload it then


Is that really necessary?
I am unfamiliar with GitLab. Sorry.

  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Richard B. Kreckel]

Could we just upgrade to version 1.12.0 for sid/bookworm, please?

Right now, the mozillavpn package is slated for removal from bookworm. I 
would be very happy if we could avoid this.


After some tinkering, I got v1.12.0 to work on sid/bookworm. Here's what 
it takes:


1) Create mozillavpn_2.12.0.orig.tar.gz
   a) download 
https://github.com/mozilla-mobile/mozilla-vpn-client/archive/refs/tags/v2.12.0.tar.gz
   b) unpack it (and discover that directories under 3rdparty/ subdir 
are empty)
   c) drop the contents of 
https://github.com/mozilla/glean/archive/refs/tags/v52.0.0.tar.gz into 
3rdparty/glean/
   d) drop the contents of 
https://github.com/WireGuard/wireguard-tools/archive/refs/heads/master.zip 
into 3rdparty/wireguard-tools/


2) Based on mozillavpn_2.9.0-1.debian.tar.xz, apply some changes to 
debian/ directory:
   a) -DBUILD_TESTING=OFF to dh_auto_configure argument in debian/rules 
(without it it FTBFS trying to run some tests and that is also in 
upstream's rules file)
   d) change rm -rf debian/mozillavpn/etc/opt/chrome to rm -rf 
debian/mozillavpn/etc/opt in debian/rules so purge won't remove 
/etc/opt/ since there's nothing in there anyway
   c) Add packages python3-click and python3-jinja2 to Build-Depnds in 
debian/control (without these, it FTBFS)
   d) remove libqt6* and qt6-qpa-plugins dependencies in debian/control 
(see #1026957).


This builds for me on amd64.

An alternative to step 1) above is of course to clone from 
https://github.com/mozilla-mobile/mozilla-vpn-client.git and then git 
submodule update --init. That only adds some stuff not needed for Debian 
into the orig.tar.gz.


For the record, I've placed copies of the files at 
https://in.terlu.de/~kreckel/mozillavpn/.


Also, debian-release should be contacted because of the build failure on 
mipsel and mpis64el. It makes little sense to insist on these 
architectures if upstream doesn't care.


Please decide how to proceed and let me know if I can help in any way.

  -richard.
--
   .''`.  Richard B. Kreckel
  : :' :  
  `. `'   
`-<http://in.terlu.de/~kreckel/>

Bug#1026072: Fix for the bug

[Richard B. Kreckel]

I am having it too and downgrading to 107.0.1-1 fixes the problem.

It seems like someone was seeing something similar before and reported 
it here <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024351> but 
the bug got closed?


  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1020695: [Pkg-openssl-devel] Bug#1020695: failure to compute digest: md4 and rmd160

[Richard B. Kreckel]

IMO, this bug can be closed. There's been the decision by the OpenSSL 
Managment Board to reinstate RIPEMD160 (and only that) to the default 
providers in release 3.0.7.


The other algorithm, MD4 is unsafe and remains in the legacy provider.

References:
OMC decision: 


ChangeLog: 

  -richy.

Bug#1020695: [Pkg-openssl-devel] Bug#1020695: failure to compute digest: md4 and rmd160

[Richard B. Kreckel]

On 9/27/22 08:15, Sebastian Andrzej Siewior wrote:

It is not part of any standard.


It could hardly be less standardized. See ISO/IEC 10118-3:2018.

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1020695: failure to compute digest: md4 and rmd160

[Richard B. Kreckel]

W.r.t. RIPEMD160, this seems to be a mistake:
https://github.com/openssl/openssl/issues/16994
Also, Fedora seems to have worked around this.

Bug#1020695: failure to compute digest: md4 and rmd160

[Richard B. Kreckel]

On 9/25/22 21:14, Sebastian Andrzej Siewior wrote:

See the man page for OSSL_PROVIDER-legacy.


Having to add a the extra option -provider legacy breaks otherwise 
flawless existing software.


There are no good reasons to break openssl dgst -rmd160, since RIPEMD160 
is a hash algorithm with still good security properties. It is used by a 
lot of crypto software (e.g. BitCoin...) Here is how this breaks 
Python's HashLib:

$ python
Python 3.10.7 (main, Sep  8 2022, 14:34:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> h = hashlib.new('ripemd160')
Traceback (most recent call last):
  File "/usr/lib/python3.10/hashlib.py", line 160, in __hash_new
return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines] unsupported

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.10/hashlib.py", line 166, in __hash_new
return __get_builtin_constructor(name)(data)
  File "/usr/lib/python3.10/hashlib.py", line 123, in 
__get_builtin_constructor

raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type ripemd160

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020695: failure to compute digest: md4 and rmd160

[Richard B. Kreckel]

Package: openssl
Version: 3.0.5-4

rbk@bitzer:~$ echo foo |openssl dgst -md4
Error setting digest
4087791C597F:error:0308010C:digital envelope 
routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:373:Global 
default library context, Algorithm (MD4 : 88), Properties ()
4087791C597F:error:0386:digital envelope 
routines:evp_md_init_internal:initialization 
error:../crypto/evp/digest.c:252:

rbk@bitzer:~$ echo foo |openssl dgst -rmd160
Error setting digest
40A761FE947F:error:0308010C:digital envelope 
routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:373:Global 
default library context, Algorithm (RIPEMD160 : 99), Properties ()
40A761FE947F:error:0386:digital envelope 
routines:evp_md_init_internal:initialization 
error:../crypto/evp/digest.c:252:


All other digests seem to work fine.

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1016283: onetbb: FTBFS: _segment_table.h:63:63: error: member ‘tbb::detail::d1::segment_table, 128>, tbb::detail::d1::cache_aligned_alloc

[Richard B. Kreckel]

I am unable to reproduce the above compile-time error.

Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

[Richard B. Kreckel]

On Wed, 3 Aug 2022 11:33:13 -0700 Max Bell  wrote:
> Why isn't the bug being fixed? That is obviously the correct solution.
So far, they argue that it's correct and only exposed bugs in all those
other packages. Which may even be correct. But without a clear
perspective of getting those fixed anytime soon, it's best to work
around in Debian.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

[Richard B. Kreckel]

This is issue 157 upstream:
https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157
Apparently, they do not want to revert it.

So, should Debian build with --disable-thread-safety-constructor, at
least for a while?

(Remember that this bug will soon block other packages from migrating,
e.g. thunderbird 102.)

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot

[Richard B. Kreckel]

Hi Salvatore,

On 19.02.22 20:31, Salvatore Bonaccorso wrote:
> Alright thank you for confirming that. Would it be possible that you
> as well build the kernel with
> https://git.kernel.org/linus/bea2662e7818e15d7607d17d57912ac984275d94
> applied on top to see if this resolved the issue?

Yes that patch fixes it.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot

[Richard B. Kreckel]

Hi,

I'm running a AMD Ryzen 3 4300U with Radeon Graphics system and found
myself suddenly unable to boot linux-image-5.16.0-1-amd64 until a point
where I could log in. (linux-image-5.15.0-3-amd64 and previous versions
all had worked fine.)

After reading your link
https://lore.kernel.org/stable/05b11936073c8d6b7a28c07cc...@stwm.de/, I
just removed the iwlwifi.ko module and it boots just fine now.

  -richy.
-- 

Richard B. Kreckel

<https://in.terlu.de/~kreckel/>

Bug#1001156: qemu-arm needs some help with finding libs

[Richard B. Kreckel]

On 05.12.21 23:16, Aurelien Jarno wrote:
>> I am asking because without it I am getting
>> a.out: error while loading shared libraries: libstdc++.so.6: cannot open
>> shared object file: No such file or directory
>>
>> when running qemu-arm a.out. (libstdc++6-armhf-cross is installed.)
> 
> You need to install libstdc++6:armhf instead.

Aurelien, you are right. That fixes it.

This bug can indeed be closed.

All this about libfoo:arch vs. libfoo-arch-cross doesn't seem to be
documented in https://wiki.debian.org/CrossToolchains or the Debian
Multiarch HOWTO or elsewhere, does it?

  -richy.

Bug#1001156: qemu-arm needs some help with finding libs

[Richard B. Kreckel]

On 05.12.21 20:22, Aurelien Jarno wrote:
> libc6:armhf does provide the /lib/ld-linux-armhf.so.3. Do you have it 
> installed?

I see. Maybe I messed up that symlink while trying to find an error.

Say, do users have to export LD_LIBRARY_PATH=/usr/arm-linux-gnueabihf/lib?

I am asking because without it I am getting
a.out: error while loading shared libraries: libstdc++.so.6: cannot open
shared object file: No such file or directory

when running qemu-arm a.out. (libstdc++6-armhf-cross is installed.)

  -rbk.

Bug#1001156: qemu-arm needs some help with finding libs

[Richard B. Kreckel]

On 05.12.21 17:33, Michael Tokarev wrote:
> 05.12.2021 19:21, Richard B. Kreckel wrote:
>> On 05.12.21 14:34, Michael Tokarev wrote:
>>> If you want your foreign binary to run, enable this foreign architecture
>>> in dpkg (--add-architecture), run apt update, and install the
>>> corresponding
>>> libc - this one will install things into the right place.
>>
>> All this has already been done. (Otherwise, there wouldn't have been
> 
> No.

Oh, yes!

The armhf architecture *is* added (according to dpkg
--print-foreign-architectures) and the package libc6:armhf *is*
installed (according to dpkg -s libc6:armhf).

  -rbk.

Bug#1001156: qemu-arm needs some help with finding libs

[Richard B. Kreckel]

On 05.12.21 14:34, Michael Tokarev wrote:
> If you want your foreign binary to run, enable this foreign architecture
> in dpkg (--add-architecture), run apt update, and install the corresponding
> libc - this one will install things into the right place.

All this has already been done. (Otherwise, there wouldn't have been
/usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3, which is provided by
package libc6-armhf-cross_2.32-1cross4.)

> I don't know details and reasons about the /usr/arb-linux/gnueabihf/ stuff
> and why it is not in /lib. But it is definitely not qemu's way to change
> the way regular linux system works.

Well, this is the way files are set up by Debian multiarch.

As things are, qemu-arm cannot be used by non-root users because they
need to do something only root can do. => It is broken. Why it is
broken, is the question now.

We should reopen this bug. If qemu-user is the wrong package, it should
be reassigned to another more appropriate package. (Maybe
libc6-armhf-cross?)

  -rbk.

Bug#1001156: qemu-arm needs some help with finding libs

[Richard B. Kreckel]

Package: qemu-user

Version: 1:6.1+dfsg-8+b1



It seems like one has to help qemu-arm a little in order to run ARM
executables. (This procedure does not seem to be necessary for other
targets - at least not for qemu-ppc64le where I tried.)




$ cat hello.c

#include 

int main()

{

printf("hello world!\n");

}

$ arm-linux-gnueabihf-gcc-11 hello.c

$ qemu-arm a.out

qemu-arm: Could not open '/lib/ld-linux-armhf.so.3': No such file or
directory

$ ln -s /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3 /lib/

$ qemu-arm a.out

a.out: error while loading shared libraries: libc.so.6: cannot open
shared object file: No such file or directory

$ export LD_LIBRARY_PATH=/usr/arm-linux-gnueabihf/lib

$ qemu-arm a.out

hello world!



Both seem to be necessary to run a binary: setting LD_LIBRARY_PATH and
providing ld-linux-armhf.so.3 in /lib/
. It should work without these steps.

  -rbk.
-- 

  .''`.  Richard B. Kreckel

 : :' :  

 `. `'   

   `-<http://in.terlu.de/~kreckel/>

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 06.11.21 10:49, Helmut Grohne wrote:
> I confirm. Mystery finally solved. The next upstream release shall close
> this bug.

So, that powerpc problem with computing long double epsilon was a false
alarm, then?

If you could confirm that, I'ld close this, spin a release, and be
happy.  ;-)

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#998698: qtwayland5 should always be installed along with Qt

[Richard B. Kreckel]

Package: qtwayland5
Severity: normal
Version: 5.15.2-4

This plugin is way too important. Without it, Qt applications cannot be
executed when running a Wayland session. People will run in circles
trying to find out what's wrong. It doesn't hurt installing it.

Please feel free to reassign this bug.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 05.11.21 23:28, Helmut Grohne wrote:
> I created a fresh unstable chroot containing only essential and then ran
> the following commands inside:
> 
> # dpkg --add-architecture ppc64el
> # apt-get update
> # apt-get install g++-powerpc64le-linux-gnu make file libgmp-dev:ppc64el
> $ apt-get source cln
> $ cd cln-*
> $ ./configure --host=powerpc64le-linux-gnu --disable-shared
> 
> It hangs. The last line of output is:
> 
> creating include/cln/intparam.h
> 
> I deliberately used precisely your configure invocation here. As you can
> see, I cannot reproduce your success. Can you reproduce my failure this
> way?
Yes, I can. There seems to be a misunderstanding.

This hang creating intparam.h is the known issue you reported and that
should be fixed upstream.

Sorry, the Debian package version 1.3.6-4 is not fixed yet.

Could you, please, try checking out cln from
https://www.ginac.de/CLN/cln.git/ and run
$ ./autogen.sh
$ ./configure --host=powerpc64le-linux-gnu --disable-shared

The question I am trying to get an answer for is if this really still
hangs in CL_FLOATPARAM_CROSS.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 05.11.21 15:41, Helmut Grohne wrote:
> On Fri, Nov 05, 2021 at 10:32:59AM +0100, Richard B. Kreckel wrote:
> I vaguely suspect that you do have qemu-user-binfmt installed and that
> it enables running foreign binaries and changes the way configure
> behaves. Does that match reality?

Indeed, qemu-user-binfmt was installed.

So I uninstalled it. It still compiles and I can still run the tests.

> The last attempt for ppc64el is a bit dated already:
> http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20210324230722.log
> I scheduled a new attempt now.
> 
> For all other architectures, we see a new issue:
> 
> ../include/cln/intparam.h:26:2: error: #error "Type char * does not fit into 
> an intptr_t!!"
>26 | #error "Type char * does not fit into an intptr_t!!"
>   |  ^
> 
> That even happens for combinations of 64bit architectures. I see that
> stdint.h is now included, so I don't understand why it fails like that.

I don't understand either. That check should really work.

Obviously, I cannot reproduce that either.

Since when do we get this?

> Does that help you with reproducing the failures I see?

Unfortunately, no.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

On 05.11.21 10:32, Richard B. Kreckel wrote:
> On my bullseye setup, this works:
> $ ./configure --host=powerpc64le-linux-gnu --disable-shared
> $ make
> $ qemu-ppc64le -L /usr/powerpc64le-linux-gnu ./tests/exam
> Tests passed.

It was on a bookworm/unstable setup, actually.
(I don't see how that would matter.)

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 28.08.21 13:53, Helmut Grohne wrote:
> The issue is with the detection of the long double epsilon on powerpc
> architectures. m4/floatparam.m4' macro CL_FLOATPARAM_CROSS attempts to
> deduce the minimal value that can be added to 1 using compile time
> bisection. That works, because gcc does constant folding of floating
> point numbers, except when it does not not powerpc architectures. There
> is a long standing gcc bug
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779.
> 
> Would there be any chance to use gcc constants such as LDBL_EPSILON for
> this case (even opportunistically)?
> 
> In any case, the current implementation is very bad, because the while
> loop never finishes as every compilation attempt fails on the supposedly
> non-constant expression. At minimum, there should be a bound on the
> number of iterations.

How can I reproduce this?

On my bullseye setup, this works:
$ ./configure --host=powerpc64le-linux-gnu --disable-shared
$ make
$ qemu-ppc64le -L /usr/powerpc64le-linux-gnu ./tests/exam
Tests passed.

It surely produces the expected floatparam.h file, with
long_double_mant_bits set to 106.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#793675: hplip-gui: No system tray detected

[Richard B. Kreckel]

Hi,

On 15.05.21 10:32, Fabrice Bauzac-Stehly wrote:
> "Richard B. Kreckel"  writes:
> 
>> Running version 3.21.2+dfsg1-2 of package hplip-gui, the annoying
>> message still pops up after each login.
> 
> Version 3.21.2+dfsg1-2 does not contain the change to
> /etc/xdg/autostart/hplip-systray.desktop, so I expect that you get the
> annoying message.
> 
> The fixed version is 3.21.2+dfsg1-2+exp0.
> 
>> I have checked that /etc/xdg/autostart/hplip-systray.desktop indeed
>> contains the line saying NoShowIn=GNOME;
> 
> Have you modified it manually?

Indeed.

I had tried that fix from Ubuntu long ago and it didn't work...

...but now that you confirmed that it works, I tried again. And d'oh, I
had a typo in it! (NoShowIn=...)

Let's close this bug now...

   -richard.

Bug#793675: hplip-gui: No system tray detected

[Richard B. Kreckel]

reopen 793675

Running version 3.21.2+dfsg1-2 of package hplip-gui, the annoying
message still pops up after each login.

I have checked that /etc/xdg/autostart/hplip-systray.desktop indeed
contains the line saying NoShowIn=GNOME; It does not seem to suppress
the popup. There is no other "hplip-systray.desktop"

I wonder if anybody has tried if this works? If so, please speak up.

  -rbk.
-- 

  .''`.  Richard B. Kreckel

 : :' :  

 `. `'   

   `-<http://in.terlu.de/~kreckel/>

Bug#847271: mutter: Resizing window moves the whole window

[Richard B. Kreckel]

This seems to be fixed in mutter 3.38.2-1.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#847271: mutter: Resizing window moves the whole window

[Richard B. Kreckel]

On Tue, 06 Dec 2016 21:50:34 +0100 =?utf-8?q?Jakobus_Sch=C3=BCrz?= 
 wrote:

Resizing a window with the mouse makes window moving around. See in
demonstration-video:

https://www.youtube.com/watch?v=EI_--20D6tE


This bug was gone for a long time, but seems to have reappeared 
recently. Also see these upstream PRs:

https://gitlab.gnome.org/GNOME/mutter/-/issues/1447
https://gitlab.gnome.org/GNOME/mutter/-/issues/1461

I notice that the Debian changelog claims to have fixed this: Mutter 
3.38.1-2 lists "Fix resizing issues (LP: #1878293)" and 3.38.1-3 lists 
"When resizing terminals interactively, don't offset the position" in 
the update to 3.38.1-33-g067af969c.


However, the problem is still there both in 3.38.1-2 and in 3.38.1-3.

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#969029: pitivi fresh install gives missing dependecies message: GSound plugin, libav

[Richard B. Kreckel]

Hi!

After installing gir1.2-gsound-1.0, this message goes away.
Pitivi already suggests installing gir1.2-gsound-1.0.
This is perfectly correct, according to the Debian policy, section 7.2.
On the other hand, it wouldn't hurt making this dependency stronger, 
would it?


  -richy.
--

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

On 12.10.20 20:49, Helmut Grohne wrote:

I strongly suggest that you do not proxy builds through me. The latency
is much higher than doing it yourself. The primary goal of cross builds
is that you can build for anything on your box instead of having to own
the target box. All you need to do is pass --host to sbuild or
--host-arch to pbuilder.

Nevertheless, I attempted applying your box and built for arm64 and
ppc64el. With the patch, it passes the build for arm64, but ppc64el
still hangs in configure.


Okay, all that has just been fixed upstream now.

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

On 11.10.20 19:28, Helmut Grohne wrote:

If you are interested in figuring out why this happens, all the better,
I guess you should pass --anything-failed-commands=%SBUILD_SHELL to
sbuild and examine config.log.


Before I dig into this, could you, please, try applying the attached 
patch and check if it works?


(It's a little bit a stab in the dark, just reverting the last changes 
made there. After all, it should've worked before.)


  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>
diff --git a/m4/intparam.m4 b/m4/intparam.m4
index 3c990d7..7d81424 100644
--- a/m4/intparam.m4
+++ b/m4/intparam.m4
@@ -113,7 +113,7 @@ AC_DEFUN([CL_INTPARAM_CROSS],
 echo "#error \"Integer types long long and unsigned long long have different sizes!!\""
   fi
 fi
-AC_TRY_COMPILE([#include ], [static_assert(sizeof(char*) <= sizeof(intptr_t), "");],
+AC_TRY_COMPILE([#include ], [typedef int verify[2*(sizeof(char*)<=sizeof (intptr_t))-1];],
   [], [echo "#error \"Type char * does not fit into an intptr_t!!\""])
 _AC_COMPUTE_INT([sizeof (char *)], [pointer_size])
 pointer_bitsize=`expr $pointer_size '*' $char_bitsize`
@@ -290,7 +290,7 @@ AC_DEFUN([CL_INTPARAM_ALIGNOF],
 #else
 # define alignof(type)  offsetof (struct { char slot1; type slot2; }, slot2)
 #endif
-], [static_assert(alignof($1) == $n, "");],
+], [typedef int verify[2*(alignof($1) == $n) - 1];],
   [$2=$n; break;]
   [if test $n = 0; then $2=; break; fi])
 n=`expr $n '*' 2`

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

On 10.10.20 07:04, Helmut Grohne wrote:

Source: cln
Version: 1.3.6-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cln fails to cross build from source, because it checks for the size of
intptr_t without including . It thus fails detecting a size
and errors out. Please add the required include. I'm attaching a patch
for that.


Thank you! Your patch has been upstreamed.


I fear this is not the only issue. For instance on ppc64el, the build
times out during configure. I haven't figured out why yet. Can you just
fix the missing include and close this bug when doing so?


I would love to know at which point configure gets stuck.

  -richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#971769: rakudo 2020.09 uninstallable

[Richard B. Kreckel]

Package: rakudo
Version: 2020.09+dfsg-1
Severity: normal

# apt install rakudo
Setting up rakudo (2020.09+dfsg-1) ...
  rakudo-helper.pl: Reinstalling all perl6 modules ...
(1/3) reinstall: perl6-readline
Unhandled exception: Missing or wrong version of dependency 
'gen/moar/stage2/MASTNodes.nqp' (from 'gen/moar/Pod.nqp')
   at :1 
(/usr/lib/perl6/lib/Perl6/Pod.moarvm:)
 from src/vm/moar/ModuleLoader.nqp:47 
(/usr/share/nqp/lib/ModuleLoader.moarvm:)
 from src/vm/moar/ModuleLoader.nqp:40 
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_module)
 from :1 
(/usr/lib/perl6/lib/Perl6/Actions.moarvm:)
 from src/vm/moar/ModuleLoader.nqp:47 
(/usr/share/nqp/lib/ModuleLoader.moarvm:)
 from src/vm/moar/ModuleLoader.nqp:40 
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_module)
 from :1 
(/usr/lib/perl6/lib/Perl6/Grammar.moarvm:)
 from src/vm/moar/ModuleLoader.nqp:47 
(/usr/share/nqp/lib/ModuleLoader.moarvm:)
 from src/vm/moar/ModuleLoader.nqp:40 
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_module)
 from :1 
(/usr/lib/perl6/runtime/perl6.moarvm:)
"perl6 /usr/share/perl6/tools/install-dist.p6 
--from=/usr/share/perl6/debian-sources/perl6-readline 
--to=/tmp/ngbtOAF5Oc/build --for=vendor" unexpectedly returned exit 
value 1 at /usr/share/perl5/IPC/System/Simple.pm line 578.
	IPC::System::Simple::_check_exit("perl6 
/usr/share/perl6/tools/install-dist.p6 --from=/usr/shar"..., 1, 
ARRAY(0x55a91c24e310)) called at /usr/share/perl5/IPC/System/Simple.pm 
line 550
	IPC::System::Simple::_process_child_error(256, "perl6 
/usr/share/perl6/tools/install-dist.p6 --from=/usr/shar"..., 
ARRAY(0x55a91c24e310)) called at /usr/share/perl5/IPC/System/Simple.pm 
line 190
	IPC::System::Simple::run("perl6 /usr/share/perl6/tools/install-dist.p6 
--from=/usr/shar"...) called at (eval 31) line 12

eval {...} called at (eval 31) line 11
	Fatal::__ANON__("perl6 /usr/share/perl6/tools/install-dist.p6 
--from=/usr/shar"...) called at /usr/share/perl6/rakudo-helper.pl line 47
	main::install("perl6-readline") called at 
/usr/share/perl6/rakudo-helper.pl line 109
	main::reinstall_all() called at /usr/share/perl6/rakudo-helper.pl line 
151 at /usr/share/perl6/rakudo-helper.pl line 47

dpkg: error processing package rakudo (--configure):
 installed rakudo package post-installation script subprocess returned 
error exit status 1



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

Kernel: Linux 5.8.0-2-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rakudo depends on:
ii  libc6  2.31-3
ii  libgraph-perl  1:0.9704-1
ii  libipc-system-simple-perl  1.30-1
ii  libpath-tiny-perl  0.114-1
ii  moarvm 2020.09+dfsg-1
ii  nqp2020.09+dfsg-2

rakudo recommends no packages.

Versions of packages rakudo suggests:
ii  valgrind  1:3.16.1-1

-- no debconf information

Bug#971741: pitivi should depend on libgstreamer-plugins-bad1.0-dev

[Richard B. Kreckel]

Package: pitivi
Version: 2020.09-1
Severity: important

Dear Maintainer,

Pitivi reports "Could not import 'GstTranscoder'. Make sure you have it 
available." and exits immediately unless package 
gir1.2-gst-plugins-bad-1.0 is isntalled.


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pitivi depends on:
ii  gir1.2-gdkpixbuf-2.02.40.0+dfsg-5
ii  gir1.2-ges-1.0  1.18.0-2
ii  gir1.2-glib-2.0 1.66.0-1
ii  gir1.2-gst-plugins-base-1.0 1.18.0-dmo1
ii  gir1.2-gstreamer-1.01.18.0-3
ii  gir1.2-gtk-3.0  3.24.23-1
ii  gir1.2-pango-1.01.46.2-1
ii  gstreamer1.0-gl [gstreamer1.0-videosink]1.18.0-dmo1
ii  gstreamer1.0-gtk3 [gstreamer1.0-videosink]  1.18.0-dmo1
ii  gstreamer1.0-plugins-bad [gstreamer1.0-videosink]   1:1.18.0-dmo4
ii  gstreamer1.0-plugins-base   1.18.0-dmo1
ii  gstreamer1.0-plugins-good [gstreamer1.0-videosink]  1.18.0-dmo1
ii  gstreamer1.0-pulseaudio [gstreamer1.0-audiosink]1.18.0-dmo1
ii  gstreamer1.0-x [gstreamer1.0-videosink] 1.18.0-dmo1
ii  libc6   2.31-3
ii  libcairo2   1.16.0-4
ii  libglib2.0-02.66.0-2
ii  libgstreamer1.0-0   1.18.0-3
ii  libpython3.83.8.6-1
ii  python3 3.8.2-3
ii  python3-cairo   1.16.2-4
ii  python3-dbus1.2.16-3
ii  python3-gi  3.38.0-1
ii  python3-gi-cairo3.38.0-1
ii  python3-gst-1.0 1.18.0-1
ii  python3-matplotlib  3.3.2-1
ii  python3-numpy   1:1.19.2-2
ii  python3-xdg 0.26-3
ii  python3.8   3.8.6-1

pitivi recommends no packages.

Versions of packages pitivi suggests:
pn  frei0r-plugins 
ii  gir1.2-gnomedesktop-3.03.38.0-2
pn  gir1.2-gsound-1.0  
ii  gir1.2-notify-0.7  0.7.9-1
ii  gstreamer1.0-libav 1:1.18.0-dmo2
ii  gstreamer1.0-plugins-ugly  1:1.18.0-dmo1

-- no debconf information

Bug#947247: libcln-dev: move cln.pc to a multiarch location

[Richard B. Kreckel]

Hi Helmut,

On 02.01.20 20:14, Helmut Grohne wrote:
> Yes. I often opt for moving all components to the multiarch libdir.
> However in the case of cln, the comment in debian/rules line 70 made me
> not go that route:
> 
> # This installs into libdir, but we must not set libdir because it affects 
> the .la file:
> 
> Maybe I didn't properly understand the comment, but it seemed as if we
> shouldn't pass --libdir. If that actually works, it should be preferred.
> It might even allow marking some packages Multi-Arch: same.

I, too, was wondering about this comment. Well, since .la files aren't
shipped let's ignore this.

I think it's safe to Multi-Arch: same libcln6, now. The -dev package, I
don't think so: Some headers are configure-generated and arch-dependent.
I'ld have to learn how to handle this, first.

> This bug is only concerned with the location of the .pc file though. It
> can be solved by only moving it or by moving all files. Whatever suits
> you best. I chose the minimally invasive route, because I feared
> introducing a regression, but as you figured it adds complexity on its
> own.

Thanks. I'm going to dupload a thoroughly modernized CLN package now. If
you could have a look at it, this would be appreciated.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#947247: libcln-dev: move cln.pc to a multiarch location

[Richard B. Kreckel]

On 23.12.19 15:18, Helmut Grohne wrote:
> ginac fails to cross build from source, because it cannot find cln.pc
> using pkg-config. During cross compilation, pkg-config does not search
> /usr/lib/pkgconfig. It only searches /usr/share/pkgconfig and
> /usr/lib//pkgconfig. To be usable for cross compilation, cln.pc
> must be moved to a multiarch location. Please consider applying the
> attached patch.

Thank you for reporting this!

Hmmm, I have a question: Wouldn't it be more consistent to set $(libdir)
to /usr/lib//, so the library files are installed there, too,
not in /usr/lib/?

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#899154: Acknowledgement (console switching broken on Polaris11 hardware with amdgpu.dc=1)

[Richard B. Kreckel]

On Fri, 1 Jun 2018 01:10:10 +0200 "Richard B. Kreckel"
 wrote:
> On 05/24/2018 11:54 PM, Richard B. Kreckel wrote:
> > Aha! The problem goes away when upgrading to Xorg 1.20.
> 
> Oh, the problem has re-surfaced after a recent burst of debian/testing
> upgrades.  :(

This problem has not shown up again on the same and similar hardware
since the release of Buster. Bug can be closed, IMO.

Bug#942003: libcln-dev: remove unneeded dependencies

[Richard B. Kreckel]

On 08.10.19 23:35, Pino Toscano wrote:
> libcln-dev depends on some packages which are not strictly needed as
> such:
> - g++: even though cln is a C++ library, usually -dev packages with
>   includes do not require a certain compiler, which is chosen by the
>   user

In theory, it should depend on c++-compiler, which is also provided by
clang, for instance. But since that is not the practice in other C++
libs either, I'm not going to discuss this.  => agreed.

> - libc6-dev | libc-dev: as above, usually -dev packages do not require
>   the standard C library headers, as they are provided by the libc

Sure, agreed.

> - install-info: for few years install-info has been shipping a dpkg
>   trigger to automatically run update-info-dir

Sure, agreed.

Thanks for the patch. I'll apply it and upload these days.

   -richy.

Bug#865999: [exiv2] Please package exiv2 0.26

[Richard B. Kreckel]

On Sun, 10 Mar 2019 00:26:43 +0100 "Richard B. Kreckel"
 wrote:
> Raphaël, what makes you sure that these CVEs are not present in earlier
> versions (e.g. in 0.25 currently in testing)?

Never mind. I see now that they're allo triaged by security.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#865999: [exiv2] Please package exiv2 0.26

[Richard B. Kreckel]

On Tue, 26 Sep 2017 17:56:57 +0200 Raphael Hertzog 
wrote:
> Except that version 0.26 is vulnerable to multiple security issues which
> are currently not present in earlier versions [...]
Raphaël, what makes you sure that these CVEs are not present in earlier
versions (e.g. in 0.25 currently in testing)?

They were reported against 0.26 because that version was fuzzed, that's
all, AFICT.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#914006: exiv2: Please package version 0.27

[Richard B. Kreckel]

It looks like I forgot one grave bug:
#62 (CVE-2018-5772) <https://github.com/Exiv2/exiv2/issues/216>

But that's also fixed in 0.27.0.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#914006: exiv2: Please package version 0.27

[Richard B. Kreckel]

On Sun, 18 Nov 2018 06:47:43 -0500 Jeremy Bicha  wrote:
> There is a new exiv2 0.27 RC2 tarball release. Could you look into
> whether it fixes the security issues from 0.26 and would be acceptable
> for unstable?

I just went through all Debian bug reports associated with CVEs.
As far as I can see, upstream has fixed them all in exiv2 0.27.0.

Grave bugs:
#876242 (CVE-2017-12957) 
#880027 (CVE-2017-14861) 
#880015 (CVE-2017-14866) 
#63 (CVE-2017-1000127) 
#64 (CVE-2017-1000126) 
#65 (CVE-2017-14865) 
#66 (CVE-2017-14863) 
#67 (CVE-2017-14860) 
#69 (CVE-2017-14857) 
#72 (CVE-2017-12956) 
#73 (CVE-2017-12955) 
#74 (CVE-2017-11553) 
#894179 (CVE-2018-8977) 
#903763 (CVE-2018-14046) 
#912828 (CVE-2018-18915) 
#915134 (CVE-2018-19607) 
#923472 (CVE-2019-9143) 
#923473 (CVE-2019-9144) 

Important bugs:
#886006 (CVE-2017-17669) 
#886962 (CVE-2018-4868) 
#891044 (CVE-2017-17722) 
#891783 (CVE-2017-17724) 
#895568 (CVE-2017-11592) 
#897260 (CVE-2017-1000128) 
#903813 (CVE-2018-8976) 
#910060 (CVE-2018-17581) 
#910909 (CVE-2018-9145) 
#913272 (CVE-2018-19108) 
#913273 (CVE-2018-19107) 
#915135 (CVE-2018-19535) 
#916081 (CVE-2018-16336) 

This looks good to me!

  -richy.

Bug#218557: dies with "Cannot find node `Top'"

[Richard B. Kreckel]

On 25.01.19 23:27, Hilmar Preuße wrote:
> As of 5.2.0.dfsg.1-4 install-info is the one from upstream.

And apparently, it is robust enough not to choke on those dir files that
Victor-Philipp Busch sent in 2008 (if that was the original problem).

> Is anybody of you still able to reproduce the problem or should we close
> the issue instead?

I've never ran across this again. Let's close it.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#906777: ginac: FTBFS in buster/sid (-I: command not found)

[Richard B. Kreckel]

This is because makeinfo is missing in your build environment.
Will add a build-depend on texinfo to fix this.

  -richy.

Bug#900511: libcurl4 Conflicts: libcurl3

[Richard B. Kreckel]

On Sat, 2 Jun 2018 23:14:40 +0300 Adrian Bunk  wrote:
> libcurl3 is not part of buster, and using libraries from previous 
> releases that are no longer present in a new stable Debian release is 
> not strictly supported - it works most of the time, but when problems
> are reported a Breaks/Conflicts against that library is usually the
> solution.

Yeah, I have read this:
https://salsa.debian.org/debian/curl/merge_requests/2.

Still, the question remains: Why can different libssl packages coexist
fine (even if they are from a previous Debian version) but libcurl
packages cannot?

There are external software packages shipped as .deb which require
libcurl3. (I've seen that the LightWorks video editor and several games
are affected.) To support those, there should be a way to provide libcurl3.

Bug#899154: Acknowledgement (console switching broken on Polaris11 hardware with amdgpu.dc=1)

[Richard B. Kreckel]

On 05/24/2018 11:54 PM, Richard B. Kreckel wrote:
> Aha! The problem goes away when upgrading to Xorg 1.20.

Oh, the problem has re-surfaced after a recent burst of debian/testing
upgrades.  :(

Bug#899154: Acknowledgement (console switching broken on Polaris11 hardware with amdgpu.dc=1)

[Richard B. Kreckel]

Aha! The problem goes away when upgrading to Xorg 1.20.

Bug#899154: console switching broken on Polaris11 hardware with amdgpu.dc=1

[Richard B. Kreckel]

Package: linux-image-4.16.0-1-amd64
Severity: normal
Version: 4.16.5-1

With current Debian/testing, I cannot switch consoles once I'm in
graphics mode: Pressing Ctrl-Alt-F1 produces some artifacts on a black
screen, mouse pointer still there and movable but that's it. It is
impossible to switch back or to another console; the box must be reset.

This does not happend when booting without amdgpu.dc=1.

This is a regression with respect to linux-image-4.15.0-3-amd64.

Bug#897598: cln: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Richard B. Kreckel]

On 05/03/2018 02:39 PM, Manuel A. Fernandez Montecelo wrote:
> I am attaching a patch that adds support for the arquitecture.  I don't know 
> if
> you will send upstream yourself or if you prefer that we send it.

Pushed patch upstream:
https://www.ginac.de/CLN/cln.git/?p=cln.git;a=commit;h=26aaf349a1fb3879274090d9e1c8f86da4a0a585

Bug#894310: Please build the thunderbolt-net module

[Richard B. Kreckel]

Package: linux
Severity: wishlist
File: /boot/config-4.15.0-2-amd64
X-Debbugs-CC: sin...@nefkom.net

I'ld like to play-test the thunderbolt-net module.

Please consider enabling CONFIG_THUNDERBOLT_NET.

Thanks
   -richy.

Bug#890861: man(1) fails to display anything

[Richard B. Kreckel]

To my surprise that system had the 'execve() wrapper and logger' package
snoopy version 2.4.6-3 installed. Purging snoopy fixes the problem and
installing it makes it come back - reproducibly.

Maybe this bug should be reassigned to package snoopy.
(I still would like to test this on another machine.)

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Bug#890861: man(1) fails to display anything

[Richard B. Kreckel]

Package: man-db
Version: 2.8.1-1
Severity: important

$ man ls
man: command exited with status 159: /usr/lib/man-db/zsoelim |
/usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv
-e UTF-8 | tbl | nroff -mandoc -rLL=175n -rLT=175n -Tutf8

It turns out that
$ MAN_DISABLE_SECCOMP=1 man ls
works just fine.

Bug#865209: gnome-terminal: Resizing terminal window to one side (left or right) also makes the window expand up and down

[Richard B. Kreckel]

This looks like a duplicate of bug#850024.
And it appears to have been fixed.

Bug#850024: gnome-terminal moves, while it's being resized

[Richard B. Kreckel]

This bug has disappeared by an upgrade about a week ago.
Apparently, the problem was not caused by gnome-terminal: downgrading 
from version 3.26.2-2 to 3.22.2-1 does not re-introduce it.

In any case, feel free to close this bug.

Bug#850024: gnome-terminal moves, while it's being resized

[Richard B. Kreckel]

Not sure if this is related, but while a gnome terminal window is being
resized, messages about "Allocating size to GtkScrollbar 0x555efdf44410
without calling gtk_widget_get_preferred_width/height(). How does the
code know the size to allocate?" keep appearing in /var/log/messages.

Bug#850149: shotwell: Freezes when trying to open an image in fullscreen mode

[Richard B. Kreckel]

Looking back at the original description, it might be this upstream bug:
.

Bug#854912: unblock: shotwell/0.25.4-0.1

[Richard B. Kreckel]

On 02/20/2017 12:15 PM, Jonathan Wiltshire wrote:
> I specifically asked you not to use a "really" version. I don't mind so
> much for sid, but it's really nasty for targeting a release.

I'm sorry.

Jonathan, if I violated some policy, please point it out to me and I'll
respond *immediately*.

I am aware you asked me to pull an epoch. But it's been pointed out
elsewhere that epochs stick forever and I was asked to do a "really"
version instead.

Having a choice between 1) doing a "really" version and 2) pulling an
epoch, with one justification offered for 1) but none for 2) I opted for
option 1). Did I miss anything?

I'm kindly asking that we work together to get this package of the
stable version in before the release, for the reasons pointed out in
#849688 and #850149.

All my best,
   -richard.
-- 
Richard B. Kreckel
<http://in.terlu.de/~kreckel/>

Bug#850149: shotwell: Freezes when trying to open an image in fullscreen mode

[Richard B. Kreckel]

On Wed, 15 Feb 2017 13:04:43 +0200 Alberto Garcia <be...@igalia.com> wrote:
> On Tue, Feb 14, 2017 at 06:36:05PM +, Debian Bug Tracking System wrote:
> >  shotwell (0.25.4+really0.24.5-0.1) unstable; urgency=medium
> >  .
> >* Revert to last stable release 0.24.5 (Closes: #850149).
> 
> Thanks for this! Shotwell is finally usable again.
> 
> However the original problem (as described in the first comment) is
> still present, do you want me to file a separate bug for that, or what
> do you prefer?

Is there a reference to an upstream bug?

  -richy.
-- 
Richard B. Kreckel
<http://in.terlu.de/~kreckel/>

Bug#854912: unblock: shotwell/0.25.4-0.1

[Richard B. Kreckel]

I've NMUed shotwell 0.25.4+really0.24.5-0.1, containing 0.24.5, the
latest stable release. It's now three days old.

How to proceed?

  -richy.
-- 
Richard B. Kreckel
<http://in.terlu.de/~kreckel/>

Bug#854912: unblock: shotwell/0.25.4-0.1

[Richard B. Kreckel]

Subject: unblock: shotwell/0.25.4-0.1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package shotwell.

Upstream version 0.25.1 of shotwell was packaged for testing, but that
version is unsuitable for release in stretch as it contained tons of
temporary regressions due to a major change in the menu handling
code, cf. Bug#849688. These bugs have been ironed out upstream in
versin 0.25.4, which is the NMU I'm kindly requesting to be unblocked.

Oh, and BTW: I'm personally using shotwell almost daily and I can
confirm that 0.25.4 runs smoothly while 0.25.1 is so broken it's next to
useless.

$ debdiff shotwell_0.25.1-1_amd64.deb shotwell_0.25.4-0.1_amd64.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo-gobject2 (>=
1.10.0), libcairo2 (>= 1.2.4), libexif12 (>= 0.6.21-1~), libgck-1-0 (>=
2.91.1), libgcr-base-3-1 (>= 3.8.0), libgcr-ui-3-1 (>= 3.8.0),
libgdk-pixbuf2.0-0 (>= 2.25.2), libgee-0.8-2 (>= 0.10.1), libgexiv2-2
(>= 0.6.1), libglib2.0-0 (>= 2.41.1), libgomp1 (>= 4.2.1), libgphoto2-6
(>= 2.5.10), libgphoto2-port12 (>= 2.5.10),
libgstreamer-plugins-base1.0-0 (>= 1.0.0), libgstreamer1.0-0 (>= 1.0.0),
libgtk-3-0 (>= 3.16.2), libgudev-1.0-0 (>= 146),
libjavascriptcoregtk-4.0-18, libjson-glib-1.0-0 (>= 0.12.0), liblcms2-2
(>= 2.2+git20110628), libp11-kit0 (>= 0.2), libpango-1.0-0 (>= 1.18.0),
libpangocairo-1.0-0 (>= 1.14.0), libraw15 (>= 0.16.0), libsoup2.4-1 (>=
2.41.90), libsqlite3-0 (>= 3.5.9), libstdc++6 (>= 4.1.1),
libwebkit2gtk-4.0-37 (>= 2.5.3), libxml2 (>= 2.7.4), shotwell-common (=
[-0.25.1-1),-] {+0.25.4-0.1),+} dconf-cli, default-dbus-session-bus |
dbus-session-bus, librsvg2-common
Installed-Size: [-5833-] {+5837+}
Version: [-0.25.1-1-] {+0.25.4-0.1+}

unblock shotwell/0.25.4-0.1

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#849688: package in debian/testing is development version, severely broken

[Richard B. Kreckel]

severity 849688 important

(This is "a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone", so setting to
important.)

Please respond today with a proposal how to get this broken package in
Debian fixed. I may help with an NMU unless there is a better proposal.

Bug#849688: package in debian/testing is development version, severely broken

[Richard B. Kreckel]

On Mon, 02 Jan 2017 11:19:47 +0100 Jörg Frings-Fürst wrote:
> I set the severity to normal because
>  * there are only 2 open bugs[5] for release 0.25.x at shotwell
>bugtracker
>  * the next release date is near enough to get it into
>unstable/testing.

Jörg, having the freeze in mind, may I ask what your plans are to get a
useable release into Debian/stretch?

  -richy.

Bug#851061: Collections don't work at all, do they?

[Richard B. Kreckel]

Package: gnome-documents
Version: 3.22.0-1

I've reproduced this on three accounts on two computers running
Debian/testing:

I successfully followed the help to create a collection of some related
documents.

Now, if I click on the Collections button on the top, I see the
collection, with its name and an icon built from thumbnails of four of
the documents I placed into the collection. But then, what?
- Nothing happens when I click on the collection item.
- I can select the collection with the ✓ button, but nothing more: at
the bottom, buttons for Open, share, print, delete, Collections, and
Properties appear, but they are all disabled.
- The collection does not appear in the Documents view.
- The collection does not seem to appear elsewhere.
To summarize: It seems to be as useless as teats on a boar.  :-/

While there's a help page explaining how to create collections it is
silent about what to do with it.

If there is some use, then it should be documented, so people can find out.
-- 
Richard B. Kreckel
<http://in.terlu.de/~kreckel/>

Bug#850548: gegl: please update to 0.3.10

[Richard B. Kreckel]

Package: gegl
Version: 0.3.8
Severity: normal

A lot has happened upstream in gegl during the last half year.
Please update gegl to version 0.3.10.

Bug#849883: inconsistency while processing conflicts

[Richard B. Kreckel]

On 01/02/2017 12:22 AM, Richard B. Kreckel wrote:
> [Status: Package emacs25 is marked for removal, emacs25-lucid and
> emacs25-nox are both marked for *complete* removal.]

That was incorrect: the two packages emacs25-lucid and emacs25-nox are
not marked for complete removal. They are both marked as broken (filled
red box). Sorry.

   -richard.

Bug#850024: gnome-terminal moves, while it's being resized

[Richard B. Kreckel]

Package: gnome-terminal
Version: 3.22.1-1

When grabbing one of the four corners of a window in order to resize it,
one invariant is that the opposite corner should stay in its position.

Gnome-terminal somehow manages to violate this invariant. Grab the top
left or top right corner, whirl it around, and watch the entire window
move away!

This happens both in Gnome sessions on X11 and on Wayland. On X11, the
window's lower corner tends to move downwards. On Wayland it tends to
move upwards.

I'm not observing this with any other program, which is why I'm
reporting this against gnome-terminal. (In particular, it doesn't happen
with xterm.)

Bug#849688: package in debian/testing is development version, severely broken

[Richard B. Kreckel]

On 01/02/2017 11:19 AM, Jörg Frings-Fürst wrote:
>  * the next release date is near enough to get it into unstable/testing.

That is great news!

In the meanwhile, I suggest to upload a prerelease version with decent
quality off from git into unstable/testing so it can receive fair testing.

No bugs were opened against the Debian package because these bugs were
opened directly upstream. Few bugs are open upstream because the others
have been fixed in the last weeks.

Bug#849883: inconsistency while processing conflicts

[Richard B. Kreckel]

Package: synaptic
Version: 0.83+nmu1
Severity: normal

There is a reproducible inconsistency while processing conflicts in
synaptic. It appears to involve three packages, each of which conflicts
with and replaces the other two.

Using packages emacs25, emacs25-nox, and emacs25-lucid, here are steps
to reproduce:
0) Assuming package emacs25 and its dependencies are installed, start
synaptic.
1) Right-click emacs25-lucid -> mark for installation. Confirm removal
of emacs25 by clicking the 'Mark' button.
[Status: Package emacs25 is marked for removal, emacs25-lucid is marked
for installation.]
2) Right-click emacs25-nox -> mark for installation.
[Status: Package emacs25 is marked for removal, emacs25-lucid is marked
for installation.[
3) Right-click emacs25-lucid -> mark for installation. The box informs
about "additional required changes" to be installed: emacs25-nox. This
is, of course, where the nonsense begins. Confirm by clicking the 'Mark'
button.
[Status: Package emacs25 is marked for removal, emacs25-lucid and
emacs25-nox are both marked for *complete* removal.]

  -richy.
-- 
Richard B. Kreckel
<http://in.terlu.de/~kreckel/>

Bug#849688: Acknowledgement (package in debian/testing is development version, severely broken)

[Richard B. Kreckel]

On 12/29/2016 08:59 PM, Richard B. Kreckel asked:
> Can a user downgrade to 0.24 once he has started using 0.25.1?

On 12/29/2016 09:22 PM, Jens Georg replied:
> Yes, that's perfectly fine as long as you go for shotwell-0.24.3,
> otherwise you re-introduce an db index issue.

Bug#849688: package in debian/testing is development version, severely broken

[Richard B. Kreckel]

Package: shotwell
Version: 0.25.1
Severity: grave

The version 0.25.1 of shotwell that is packaged for Debian/testing is
unsuitable for release in stretch. As Jens Georg points out on his Blog
at http://jensge.org/, the odd-numbered versions are unstable
development versions that should not be packaged by distributions.

According to Jens Georg, there has recently been a major change in the
menu handling code, temporarily causing severe usability regressions.
(I've added several bugs to Gnome's bugzilla database about that:
776527, 776298, 776590, 776592, 776593...)

The version in Debian/testing is plagued by all of these problems and
the overall user experience of this package has the potential to turn
people off. That would be a shame.

Having an eye on the Debian/stretch release and impeding freeze, there
are two options:
1) either downgrade to the latest stable version (0.24.2) or
2) move along with the version from git and hope for the best.

I don't know which option is more feasible. This is a question for Jens
Georg: Can a user downgrade to 0.24 once he has started using 0.25.1?

  -richy.
-- 
Richard B. Kreckel
<http://in.terlu.de/~kreckel/>

Bug#849208: Nvidia driver does not use DPMS

[Richard B. Kreckel]

After upgrading to version 375.26-1, DPMS works even without setting it
in xorg.conf, indeed even without an xorg.conf file.
I was unable to find this issue in Nvidia's release notes for this
driver version, though.
Anyway, this bug can be closed.

  -rbk.
-- 

Bug#776800: X server crashes when switching to another user

[Richard B. Kreckel]

As of stretch, with the nvidia-driver 375.20 and Xorg 1.19 this problem
has disappeared.

Bug#849208: Acknowledgement (Nvidia driver does not use DPMS)

[Richard B. Kreckel]

It turns out that installing nvidia-xconfig and creating an xorg.conf
file with Option "DPMS" "true" in the "Monitor" section makes the screen
turn off as desired.

The nvidia-xconfig package description says that "This tool is
deprecated. The NVIDIA drivers now automatically integrate with the Xorg
Xserver configuration. Creating an xorg.conf is no longer needed for
normal setups." This leaves the questions: What exactly is that "Xorg
Xserver configuration"?

In any case: DPMS should be part of any "normal setup".

Bug#849208: Nvidia driver does not use DPMS

[Richard B. Kreckel]

Package: nvidia-driver
Version: 375.20-4

The screen blanks, but the backlight is never turned off.

It seems like DPMS is not enabled?
$ xset -q
[...]
DPMS (Energy Star):
  Standby: 0Suspend: 0Off: 0
  DPMS is Disabled

This is the card:
$ nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208
[GeForce GT 730] [10de:1287] (rev a1)

DPMS used to work on the same hardware when it was still running jessie.

Bug#838602: glibc should provide LSB-style symlinks /lib*/ld-lsb*.so.*

[Richard B. Kreckel]

Package: libc6
Version: 2.23-5

Quite some 3rd party packages expect symbolic links ld-lsb*.so.* to the
dynamic linker/loader. (E.g., on amd64, google-earth won't start on
stretch unless /lib64/ld-lsb-x86-64.so.3 is a symlink to
/ld-linux-x86-64.so.2). These symlinks used to be installed by package
lsb-base, which has been removed from stretch. Please provide the
symlinks that came with lsb-base with libc6, to keep these 3rd party
packages running.

Bug#830532: package should be re-built with gcc-6

[Richard B. Kreckel]

Package: ginac
Version: 1.7.0-1
Severity: serious

The uploaded amd64 package was built with gcc-6. But on other
architectures, it was built with gcc-5 -std=c++11. To avoid any ABI
breakage or yet anther soname bump, this package should not migrate to
testing.

A new package should be uploaded as soon as gcc-6 has become the default
compiler.

Bug#810851: Please upload version in testing to backports

[Richard B. Kreckel]

Package: gnome-shell-extension-weather
Version: 0~20140924.git7e28508-1

As has been reported several times [1] and [2], the version in stable
has stopped working due to API changes at openweathermap.org.

The version currently in testing can be installed and works fine in a
Jessie system.

May I propose to uplad a ersion to Debian backports [3]?

   -richy.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804505
[2] https://extensions.gnome.org/extension/750/openweather/
[3] http://backports.debian.org/Contribute/

--
  .''`.  Richard B. Kreckel
 : :' :  <krec...@debian.org>
 `. `'   <krec...@in.terlu.de>
   `-<http://in.terlu.de/~kreckel/>

Bug#791048: ginac: library transition may be needed when GCC 5 is the default

[Richard B. Kreckel]

On 09/21/2015 08:54 AM, Niels Thykier wrote:
> Is anything blocking the upload (beyond someone doing it)?

I'm not aware of anythin blocking. I've been away for a couple of weeks
and will care for this later today.

Bug#791048: ginac: library transition may be needed when GCC 5 is the default

[Richard B. Kreckel]

On 09/21/2015 09:29 AM, Simon McVittie wrote:
> I have uploaded this revised diff.

Well, that diff should resolve this issue.
Thanks, Simon.

Bug#791048: ginac: library transition may be needed when GCC 5 is the default

[Richard B. Kreckel]

On 08/21/2015 10:12 AM, Simon McVittie wrote:
 The broken situation would be that you have programs (or libraries) foo
 and bar installed, both linked to libginac.so.5, with foo expecting the
 g++-4.x ABI and bar expecting the g++-5 ABI. Depending which version of
 libginac.so.5 you had installed, either foo or bar would crash. What we
 are doing by renaming the package is to force this situation not to
 exist: foo would depend on libginac5, bar would depend on libginac5v5,
 and dpkg will not let you have them both installed at the same time.

But wouldn't that mean that a program that's not in the archives (a
commercial program, for instance) which depends on a C++ library
libjoedoe.so.23 in Jessie will not work any more because there's going
to be libjoedoe.so.23 compiled with the g++-5 ABI in Stretch. And we're
not going to do that, right? (Sorry for being a nuisance.)

   -richard.

Bug#791048: ginac: library transition may be needed when GCC 5 is the default

[Richard B. Kreckel]

On 08/19/2015 10:56 AM, Simon McVittie wrote:
 On Mon, 03 Aug 2015 at 10:01:51 +0200, Richard B. Kreckel wrote:
 But there is going to be libginac5 in Debian 9
 anyway and this will be compiled with the new ABI. So, there is no need
 for a libginac2v5 package.
 
 libginac2v5 is unecessary, but libginac5 is already in the archive
 with the g++-4.x ABI, and other packages have been compiled against it;
 so a transition to libginac5v5 is (very likely to be) needed for the g++-5
 ABI.

Okay, this makes sense. It wasn't clear to me if the soname bump
mentioned in the bug report was relative to jessie or to what's in the
archive.

 Ubuntu have a patch for this, which I have attached. The lintian
 overrides are unnecessary in Debian (lintian has been changed to
 accept the v5 suffix as valid).

This patch replaces libginac5. This is in line with what the bug report
says: Rename the library package, append v5 to the name of the
package (e.g. libfoo2 - libfoo2v5).

I can do that and will do so ASAP if it's the right thing to do. But
don't the two packages have to coexist? (After all, one of the concerns
is to not break packages which are not in the archive!)

(Sorry, I also found the wiki explanation vague on this point. Maybe,
somebody can improve it.)

   -richard.

Bug#577965: [Debian-ha-maintainers] Bug#577965: corosync fails to install when user ais already exists

[Richard B Winters]

Hello,

 My current work-around is to go into
  /var/lib/dpkg/info/corosync.postinst 
 
 
 and replacing all instances of ais with ais_corosync   -  then I
 re-run the apt-get install;  it works and gives me a working system,
 but this seems like the wrong way to do it, and I'm pretty sure I'm
 gonna experience significant pain next time the corosync package is
 updated. 
 

I'm not sure what Ubuntu has going on at this time regarding the
packages, but you can report a bug for their packages here (find the
Report a bug link off to the right of your screen):

https://launchpad.net/ubuntu/+source/corosync/+bugs


We are currently updating the packages on Debian, and they are being
built without heartbeat or ais; please refer to our wiki for more
information:

http://wiki.debian.org/Debian-HA/


Best,



-- 
Rik


signature.asc
Description: This is a digitally signed message part

Bug#577965: [Debian-ha-maintainers] Bug#577965: corosync fails to install when user ais already exists

[Richard B Winters]

Hello,

On Wed, 2015-06-17 at 17:00 -0700, Luke Crawford wrote:
 I'm trying to install corosync on a system that already has a user
 'ais'  -  a user that I can't overwrite or otherwise get rid of.  
  ...
 My current work-around is to go into
  /var/lib/dpkg/info/corosync.postinst 
 
 
 and replacing all instances of ais with ais_corosync   -  then I
 re-run the apt-get install;  it works and gives me a working system,
 but this seems like the wrong way to do it, and I'm pretty sure I'm
 gonna experience significant pain next time the corosync package is
 updated.


Sorry, I didn't quite realize you might just be asking if your
work-around is kosher.

I think it looks good, just make sure any configuration parameters which
set the user reference to ais are updated to ais_corosync.

There really isn't any other way to make a work-around other than to
build from source after modifying post-inst, unless the normal install
finishes correctly; then just update the correct configuration variables
after manually creating the user you wish to use. 

HTH


-- 
Rik


signature.asc
Description: This is a digitally signed message part

Bug#769960: gdm3: upgrade from 3.14.0 to 3.14.1 results in blank screen

[Richard B. Kreckel]

Some more fiddling has revealed:
It does not seem to be the nvidia driver's fault: with the nouveau
driver the screen remains blank, too.
It does not seem to be systemd's fault either: it also happens when
starting gdm3 manually.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org