Bug#1039489: domains in i field and d field are compared as case sensitive

[Sven Bartscher]

Package: libmail-dkim-perl
Version: 0.54-1
Severity: important
Control: fixed -1 0.58-1
Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=130713

Hi,

There's a bug that has been reported upstream at 
https://rt.cpan.org/Public/Bug/Display.html?id=130713 and affects the 
package version currently in Buster. The bug has been fixed upstream in 
0.58, so no Debian releases after Buster are affected.


The bug can be reproduced by running the attached test scripts on the 
attached email file on a buster system:


$ perl ./test.pl < broken.eml
invalid (public key: does not support signing subdomains)

Note that the test email includes an i= tag with partially capitalized 
spelling and that the domain's DKIM record specifies t=s:


$ dig +short default._domainkey.weltraumschlangen.de TXT
"v=DKIM1;t=s;[...]

I would like to fix this issue in an LTS update to Buster. Is it alright 
for you, the package maintainer, if I go ahead and prepare an LTS for 
Buster? Are there any other considerations you would like me to take 
into account?


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032075: Play Queue and display of current title don't change when actually played song changes

[Sven Bartscher]

Hi,

On Mon, 27 Feb 2023 15:19:17 +0100 Sven Bartscher 
 wrote:
when listening to music in sublime music, the song metadata indicated in 
the lower left corner and the play queue reachable in the lower right 
corner do not update when they should. This includes situations such as


* the next song starts when the previous has ended
* the “Go to next song” button is used
* another song is selected for playback somewhere else in the interface
* a song is set to “play next“

Instead they just stay stuck in in the state they have when starting up, 
i.e. showing the song that was first played after starting and the play 
queue at that time. Note that while the mentioned interface elements 
don't reflect the change, the actual playback and the time slider in the 
lower middle reflect the changes made, e.g. the time resets to the start 
when a new song is started and “play next” selections are correctly 
respected when switching to the next song.


I just noticed that the behavior described above actually depends on the 
active tab being viewed. While viewing the “Playlists” tab, the behavior 
is as described above. However, as soon as yous switch to another tab 
(“Albums”, “Artists” or “Browse”) the metadata indicator in the lower 
left corner updates to the correct values.


The behavior of the play queue depends on how music was queued there. If 
music has been queued from tabs other then “Playlists” the play queue 
behaves similarly to the metadata indicator, i.e. it is frozen while on 
the “Playlists” tab, but resumes updating correctly once you switch to 
another tab. If you fill the play queue by clicking the “Play All” or 
“Shuffle All” buttons in the “Playlists” tab or double clicking a 
specific song from a playlist, it goes into a permanently frozen state 
that keeps displaying the play queue in the state before the playlist 
was queued. This frozen state can be broken by going into another tab 
and playing another song to replace the play queue.


If you don't queue a whole playlist, but only a single song from the 
playlist tab, by right-clicking and selecting “Play next” or “Add to 
queue“ the play queue updates accordingly (as soon as you switch away 
from the playlists tab) and doesn't go into the permanently frozen state.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032075: Play Queue and display of current title don't change when actually played song changes

[Sven Bartscher]

Package: sublime-music
Version: 0.11.16-4
Severity: normal


Hi,

when listening to music in sublime music, the song metadata indicated in 
the lower left corner and the play queue reachable in the lower right 
corner do not update when they should. This includes situations such as


* the next song starts when the previous has ended
* the “Go to next song” button is used
* another song is selected for playback somewhere else in the interface
* a song is set to “play next“

Instead they just stay stuck in in the state they have when starting up, 
i.e. showing the song that was first played after starting and the play 
queue at that time. Note that while the mentioned interface elements 
don't reflect the change, the actual playback and the time slider in the 
lower middle reflect the changes made, e.g. the time resets to the start 
when a new song is started and “play next” selections are correctly 
respected when switching to the next song.


When starting sublime-music it prints out various exception messages, 
which might be related to the problem, as can be seen in the attached log.


Regards
Sven

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages sublime-music depends on:
ii  gir1.2-gtk-3.03.24.36-4
ii  gir1.2-nm-1.0 1.42.0-1
ii  libjs-sphinxdoc   5.3.0-3
ii  python3   3.11.2-1
ii  python3-bleach5.0.1-2
ii  python3-dataclasses-json  0.5.7-3
ii  python3-dateutil  2.8.2-1
ii  python3-deepdiff  6.2.2-1
ii  python3-fuzzywuzzy0.18.0-4
ii  python3-gi3.42.2-3+b1
ii  python3-levenshtein   0.12.2-2+b4
ii  python3-mpv   1.0.1-3
ii  python3-peewee3.14.10+dfsg-1+b3
ii  python3-requests  2.28.1+dfsg-1
ii  python3-semver2.10.2-3
ii  sphinx-rtd-theme-common   1.2.0+dfsg-1

Versions of packages sublime-music recommends:
ii  libnotify40.8.1-1
ii  python3-bottle0.12.23-1
ii  python3-keyring   23.9.3-2
ii  python3-pychromecast  9.4.0-2

Versions of packages sublime-music suggests:
ii  network-manager  1.42.0-1

-- no debconf information

(sublime-music:76700): Gtk-CRITICAL **: 15:16:32.819: gtk_widget_set_size_request: assertion 'width >= -1' failed
Bottle v0.12.23 server starting up (using WSGIRefServer())...
Listening on http://0.0.0.0:8282/
Hit Ctrl-C to quit.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/peewee.py", line 6970, in get
return clone.execute(database)[0]
   ~~~^^^
  File "/usr/lib/python3/dist-packages/peewee.py", line 4339, in __getitem__
return self.row_cache[item]
   ~~^^
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sublime_music/app.py", line 346, in do_activate
self.dbus_manager.property_diff()
  File "/usr/lib/python3/dist-packages/sublime_music/dbus/manager.py", line 372, in property_diff
new_property_dict = self.property_dict()

  File "/usr/lib/python3/dist-packages/sublime_music/dbus/manager.py", line 239, in property_dict
"Metadata": self.get_mpris_metadata(

  File "/usr/lib/python3/dist-packages/sublime_music/dbus/manager.py", line 335, in get_mpris_metadata
artist_name = song.artist.name if song.artist else ""
  ^^^
  File "/usr/lib/python3/dist-packages/peewee.py", line 4486, in __get__
return self.get_rel_instance(instance)
   ^^^
  File "/usr/lib/python3/dist-packages/peewee.py", line 4477, in get_rel_instance
obj = self.rel_model.get(self.field.rel_field == value)
  ^
  File "/usr/lib/python3/dist-packages/peewee.py", line 6522, in get
return sq.get()
   
  File "/usr/lib/python3/dist-packages/peewee.py", line 6973, in get
raise self.model.DoesNotExist('%s instance matching query does '
sublime_music.adapters.filesystem.models.ArtistDoesNotExist:  instance matching query does not exist:
SQL: SELECT "t1"."id", "t1"."name", "t1"."album_count", "t1"."starred", "t1"."biography", "t1"."music_brainz_id", "t1"."last_fm_url", "t1"."_artist_image_url_id" FROM "artist" AS "t1" WHERE 

Bug#1023451: Current Bookworm daily image breaks root file system during resize

[Sven Bartscher]

Package: cloud.debian.org
Severity: important


I was trying to use the daily image 
debian-12-genericcloud-amd64-daily-20221104-1189.qcow2. I booted it in 
QEMU as follows:


$ qemu-system-x86_64 -m 1G -device virtio-scsi-pci,id=scsi -device 
scsi-hd,drive=hd -drive file=test.qcow2,if=none,id=hd -drive 
file=user-data.iso,if=ide,media=cdrom -nographic


When cloud-init gets to the step of resizing the root file system to fit 
the disk, it fails with the following error:


[  160.037486] cloud-init[292]: 2022-11-04 12:56:50,913 - 
schema.py[WARNING]: Invalid cloud-config provided: Please run 'sudo 
cloud-init schema --system' to see the schema errors.
[  163.701342] EXT4-fs (sda1): resizing filesystem from 491515 to 
4161531 blocks

[  163.870631] EXT4-fs (sda1): resized filesystem to 4161531
[  163.914439] EXT4-fs (sda1): Invalid checksum for backup superblock 32768
[  163.914439]
[  163.914892] EXT4-fs error (device sda1) in ext4_update_backup_sb:174: 
Filesystem failed CRC

[  163.915287] Aborting journal on device sda1-8.
[  163.919235] EXT4-fs error (device sda1): ext4_journal_check_start:83: 
comm systemd-journal: Detected aborted journal

[  163.922561] EXT4-fs (sda1): Remounting filesystem read-only
[  163.922993] EXT4-fs error (device sda1) in ext4_update_backup_sb:174: 
Journal has aborted


Many of the following steps fail too, because the root file system is 
mounted read-only.


The test.qcow2 above has been created as follows:

qemu-img create -F qcow2 -b 
debian-12-genericcloud-amd64-daily-20221104-1189.qcow2 -f qcow2 
test.qcow2 16G


The user-data.iso has been created as follows:

genisoimage  -output ../user-data.iso -volid cidata -joliet -rock 
user-data meta-data


where meta-data is an empty file and user-data has the following contents:

#cloud-config
hostname: test
users:
  - name: admin
sudo: ['ALL=(ALL) ALL']
passwd: 
$6$CZ6uhDC3EwuDlkLR$tXGFBbAnunjYwT202gdT9idnjE2EAspHn6Dxn7uL7u.WmOUPYa/5D7Bz9XrSnaSpyv7uh.5Mok9bLD/JIhWq21


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019347: Fixed NMU

[Sven Bartscher]

Hi,

I just wanted to give a heads up, that earlier today I uploaded an NMU 
to DELAYED+5 containing upstream version 1.7.4 which should fix this bug.


I pushed the changes to the packaging repository on salsa, so I assume a 
debdiff of the NMU is not required here.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019347: Similar bug still present in 1.7.2

[Sven Bartscher]

Hi,

I just noticed that the current upstream release 1.7.2 still has a bug 
very similar to this bug present. 
(https://projects.torsion.org/borgmatic-collective/borgmatic/issues/590)


It's basically the same bug, only with `patterns_from` instead of 
`patterns`.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019347: Backups end up mostly empty when location.patterns is used and /root/.borgmatic exists

[Sven Bartscher]

Package: borgmatic
Version: 1.5.12-2
Severity: grave
Tags: upstream fixed-upstream
Forwarded: 
https://projects.torsion.org/borgmatic-collective/borgmatic/issues/574
Control: found -1 1.6.3-1

Hi,

Recently I reported the bug mentioned above upstream, which causes
most data to be silently excluded from backups if /root/.borgmatic
exists. Since details of the bug are already available in the upstream
bug report, I will omit them here for brevity.

Since the issue has already been fixed upstream, this bug is only
meant to track the issue in Debian.

I've set the severity to grave, because the bug causes borgmatic to
produce effectively empty backups, while the user may believe to have
secure backups, which qualifies as data loss to me. Feel free to lower
the severity to normal if you disagree.

Regards
Sven

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages borgmatic depends on:
ii  borgbackup 1.2.1-2
ii  python33.10.6-1
ii  python3-colorama   0.4.5-2
ii  python3-jsonschema 4.6.0-3
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-requests   2.27.1+dfsg-1
ii  python3-ruamel.yaml0.17.16-1

borgmatic recommends no packages.

borgmatic suggests no packages.

-- no debconf information

Bug#1011277: RM: haskell-dpkg -- ROM; incompatible with current libdpkg and no upstream fix in the foreseeable future

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

haskell-dpkg can't be built against current versions of libdpkg. The 
upstream maintainer has indicated that they will not be able to fix this 
problem for a long time. The package currently has no reverse 
dependencies. Under these circumstances it is probably best to remove 
the package from unstable for now, and reintroduce it at a later time if 
appropriate.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011224: RM: haskell-yesod-auth-oauth2 -- ROM; unmaintained and unbuildable

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

Please remove haskell-yesod-auth-oauth2 from all architectures in 
unstable. As of today, the package has been unbuildable for almost 2 
years, which shows that there doesn't seem to be sufficient interest in 
the package to maintain it.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011223: RM: haskell-werewolf -- ROM; unmaintained upstream and unbuildable

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

Please remove haskell-werewolf from all architectures in unstable. The 
package is unmaintained upstream and is not currently neither buildable 
nor installable in Debian.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011221: RM: rss2irc -- ROM; unmaintained and unbuildable

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

Please remove rss2irc from all architectures in unstable. As of today, 
the package has been unbuildable for several months, which shows that 
there doesn't seem to be sufficient interest in the package to maintain it.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011219: RM: haskell-icalendar -- ROM; unmaintained and unbuildable

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

Please remove haskell-icalendar from all architectures in unstable. As 
of today, the package has been unbuildable for almost 2 years, which 
shows that there doesn't seem to be sufficient interest in the package 
to maintain it.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011217: RM: hdevtools -- ROM; unmaintained upstream und unbuildable

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

Please remove hdevtools from all architectures in unstable. The package 
is not maintained upstream and as of today, the package has been 
unbuildable for almost 2 years, which shows that there doesn't seem to 
be sufficient interest in the package to maintain it.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011216: RM: hdbc-odbc -- ROM; unmaintained and unbuildable

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

Please remove hdbc-odbc from all architectures in unstable. As of today, 
the package has been unbuildable for more than 3 years, which shows that 
there doesn't seem to be sufficient interest in the package to maintain it.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011214: RM: haskell-chell -- ROM; unmaintained and unbuildable

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

Please remove haskell-chell from all architectures in unstable. As of 
today, the package has been unbuildable for almost 2 years, which shows 
that there doesn't seem to be sufficient interest in the package to 
maintain it. Once #1011211 has been processed, the package should have 
no remaining reverse dependencies.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011212: RM: haskell-easytest -- ROM; unbuildable and unmaintained

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

Please remove haskell-easytest from all architectures in unstable. As of 
today, the package has been unbuildable for almost 2 years, which shows 
that there doesn't seem to be sufficient interest in the package to 
maintain it.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011213: RM: haskell-gitlib -- ROM; unmaintained and unbuildable

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org


Dear FTP masters,

Please remove haskell-gitlib from all architectures in unstable. As of 
today, the package has been unbuildable for almost 2 years, which shows 
that there doesn't seem to be sufficient interest in the package to 
maintain it.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011211: RM: haskell-chell-quickcheck2 -- ROM; unmaintained and unbuildable

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

Please remove haskell-checl-quickcheck2 from all architectures in 
unstable. As of today, the package has been unbuildable for over 2 
years, which shows that there doesn't seem to be sufficient interest in 
the package to maintain it.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011208: RM: haskell-hgettext -- ROM; Unmaintained upstream and likely not helpful to users

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

haskell-hgettext hasn't received any upstream updates since 2017. The 
package is also unlikely to be of any use in the archive, since to my 
knowledge it has no reverse build dependencies and it is of little use 
for development purposes by users. For these reasons I think it is best 
to remove the package from unstable.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010556: undefined symbol extract_begin

[Sven Bartscher]

Control: tag -1 +patch

On Wed, 4 May 2022 12:57:46 -0400 
=?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?=  wrote:

Thanks for reporting this bug. I confirm I can reproduce it on my system
running unstable. Never caught it since I was running the poppler plugin.


Understandable. I discovered this while trying to see what the 
differences between poppler and mupdf would be. After this I will 
probably go back to poppler myself.



I'll have a closer look at this in the coming days.


Since the fix was relatively simple, I opened a merge request on salsa[1].

Regards
Sven

[1]: https://salsa.debian.org/pollo/qpdfview/-/merge_requests/1


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010556: undefined symbol extract_begin

[Sven Bartscher]

Control: severity -1 grave

Hi,

I'm raising the severity of this to grave, since it renders the entire 
package qpdfview-pdf-mupdf-plugin unusable for its sole purpose of 
opening PDF files.


Regards
Sven

On Wed, 4 May 2022 12:17:04 +0200 Sven Bartscher  
wrote:

Package: qpdfview-pdf-mupdf-plugin
Version: 0.4.18-6
Severity: important


Hi,

opening PDFs using qpdfview-pdf-mupdf-plugin doesn't work for me. When I 
try to do it, qpdfview displays these error messages in the GUI:


Could not load plug-in for file type 'PDF'!

Could not open 'some.pdf'.

On the console I get the following more helpful messages:

$  LC_ALL=C qpdfview some.pdf
Could not load local plug-in: "/usr/bin/libqpdfview_pdf.so"
"The shared library was not found."
Could not load global plug-in: "/usr/lib/qpdfview/libqpdfview_pdf.so"
"The shared library was not found."
Could not load local plug-in: "/usr/bin/libqpdfview_fitz.so"
"The shared library was not found."
Could not load global plug-in: "/usr/lib/qpdfview/libqpdfview_fitz.so"
"Cannot load library /usr/lib/qpdfview/libqpdfview_fitz.so: 
(/usr/lib/qpdfview/libqpdfview_fitz.so: undefined symbol: extract_begin)"


Looks to me like libqpdfview_fitz.so is missing some dynamic linking 
dependency.


Regards
Sven

-- System Information:
Debian Release: bookworm/sid
   APT prefers testing-debug
   APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages qpdfview-pdf-mupdf-plugin depends on:
ii  libc62.33-7
ii  libgcc-s112-20220428-1
ii  libjbig2dec0 0.19-3
ii  libjpeg62-turbo  1:2.1.2-1
ii  libmujs1 1.1.3-4
ii  libopenjp2-7 2.4.0-6
ii  libqt5core5a 5.15.2+dfsg-16+b1
ii  libqt5gui5   5.15.2+dfsg-16+b1
ii  libqt5widgets5   5.15.2+dfsg-16+b1


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010556: undefined symbol extract_begin

[Sven Bartscher]

Package: qpdfview-pdf-mupdf-plugin
Version: 0.4.18-6
Severity: important


Hi,

opening PDFs using qpdfview-pdf-mupdf-plugin doesn't work for me. When I 
try to do it, qpdfview displays these error messages in the GUI:


Could not load plug-in for file type 'PDF'!

Could not open 'some.pdf'.

On the console I get the following more helpful messages:

$  LC_ALL=C qpdfview some.pdf
Could not load local plug-in: "/usr/bin/libqpdfview_pdf.so"
"The shared library was not found."
Could not load global plug-in: "/usr/lib/qpdfview/libqpdfview_pdf.so"
"The shared library was not found."
Could not load local plug-in: "/usr/bin/libqpdfview_fitz.so"
"The shared library was not found."
Could not load global plug-in: "/usr/lib/qpdfview/libqpdfview_fitz.so"
"Cannot load library /usr/lib/qpdfview/libqpdfview_fitz.so: 
(/usr/lib/qpdfview/libqpdfview_fitz.so: undefined symbol: extract_begin)"


Looks to me like libqpdfview_fitz.so is missing some dynamic linking 
dependency.


Regards
Sven

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages qpdfview-pdf-mupdf-plugin depends on:
ii  libc62.33-7
ii  libgcc-s112-20220428-1
ii  libjbig2dec0 0.19-3
ii  libjpeg62-turbo  1:2.1.2-1
ii  libmujs1 1.1.3-4
ii  libopenjp2-7 2.4.0-6
ii  libqt5core5a 5.15.2+dfsg-16+b1
ii  libqt5gui5   5.15.2+dfsg-16+b1
ii  libqt5widgets5   5.15.2+dfsg-16+b1
ii  libstdc++6   12-20220428-1

qpdfview-pdf-mupdf-plugin recommends no packages.

qpdfview-pdf-mupdf-plugin suggests no packages.

-- no debconf information


OpenPGP_signature
Description: OpenPGP digital signature

Bug#993291: apt upgrade crashes with "Assertion `I->Items->Owner->Status != pkgAcquire::Item::StatIdle' failed" when not all mirrors are reachable

[Sven Bartscher]

On Sat, 4 Sep 2021 17:31:34 +0200 Marc Haber 
 wrote:

On Wed, Sep 01, 2021 at 10:44:03AM +0200, Marc Haber wrote:
> I can confirm the same issue here:

Looks like a transient issue here, today's apt update just went through.
I cannot reproduce the issue any more.



For me, the problem came back. As I mentioned earlier, some upgrades 
went through smoothly for me. But a few days ago, upgrades started 
failing again. But I have absolutely no clue, what is causing this 
difference in behavior.


My mirror in question (mirror.home.weltraumschlangen.de) is also an 
apt-cacher-ng with split DNS. If you're in the correct network segment, 
the DNS returns a reachable IP address, otherwise it just returns NXDOMAIN.


Regards
Sven



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993291: apt upgrade crashes with "Assertion `I->Items->Owner->Status != pkgAcquire::Item::StatIdle' failed" when not all mirrors are reachable

[Sven Bartscher]

Hi,

On Mon, 30 Aug 2021 11:36:49 +0200 Sven Bartscher 
 wrote:

APT seems to have trouble downloading packages, when not all configured
repositories are reachable. Attached is the result of running

sudo LC_ALL=C apt-get upgrade 2>&1 | tee apt.log

As you can see, at first apt-get (rightly) shows a lot of Ign lines for 
mirror.home.weltraumschlangen.de, as that mirror is not reachable at the 
moment. Then it crashes with a failed assertion at the end.


I completed the updates from yesterday using aptitude, which doesn't 
seem to be affected by this bug. Updates from today went through 
smoothly as expected, with the same mirror not reachable. So I'm not 
sure how to reproduce this.


Fell free to close this bug if you can't reproduce it either.

Regards
Sven



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993291: apt upgrade crashes with "Assertion `I->Items->Owner->Status != pkgAcquire::Item::StatIdle' failed" when not all mirrors are reachable

[Sven Bartscher]

Package: apt
Version: 2.3.8
Severity: normal

Hi,

APT seems to have trouble downloading packages, when not all configured
repositories are reachable. Attached is the result of running

sudo LC_ALL=C apt-get upgrade 2>&1 | tee apt.log

As you can see, at first apt-get (rightly) shows a lot of Ign lines for 
mirror.home.weltraumschlangen.de, as that mirror is not reachable at the 
moment. Then it crashes with a failed assertion at the end.


It is my understanding, that apt should deal with unreachable mirrors 
gracefully and download packages from one of the available mirrors 
instead. I also never had this problems before with this setup before 
(including unreachable mirror), so I think this is a regression in apt 
2.3.8.


When I move my device to a network location where all configured mirros 
are available, the crash doesn't occur and I can successfully complete 
the upgrade.


Using apt or apt-get doesn't seem to make a difference.

Regards
Sven

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^postgresql.*-13";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::LastInstalledKernel "5.10.0-8-amd64";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "lz4";
APT::Compressor::lz4::Cost "50";
APT::Compressor::lz4::CompressArg "";
APT::Compressor::lz4::CompressArg:: "-1";
APT::Compressor::lz4::UncompressArg "";
APT::Compressor::lz4::UncompressArg:: "-d";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";

Bug#988133: Multi component tarballs are not supported

[Sven Bartscher]

Package: dpkg-source-gitarchive
Version: 0.1.3
Severity: wishlist

As mentioned in dpkg-source.1, section “Format: 3.0 (quilt)”, source
packages with format 3.0 (quilt) support additional component tarballs
alongside the main tarball.

dpkg-source-gitarchive currently seems to ignore such tarballs when
building source packages.

3.0 (quilt) seems to include all tarballs that match
_.orig-.tar. as components. So I
think the most sensible behavior for 3.0 (gitarchive) would be to
include all such matching tarballs found in pristine-lfs.

Regards
Sven

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'testing-security'), (102, 'unstable-debug'), (102, 'unstable'), (101, 
'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg-source-gitarchive depends on:
ii  dpkg-dev  1.20.9
ii  git   1:2.30.2-1
ii  perl  5.32.1-4
ii  pristine-lfs  20210222.0-1

dpkg-source-gitarchive recommends no packages.

dpkg-source-gitarchive suggests no packages.

-- no debconf information

Bug#986216: buster-pu: package dwarf-fortress/0.44.12+dfsg1-0+deb10u1

[Sven Bartscher]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
It has been noted in #986119 that the upstream release tarballs for
dwarf-fortress include shared libraries but no corresponding source
code is available. The shared libraries in question are licensed under
GPL and thus not distributable without source code.

The affected files are not shipped in any binary packages. This
update fixes the issue by repacking the source tarballs to exclude
those files.

[ Impact ]
The package currently in buster is not distributable in its
current form, so it has to be either updated or entirely removed from
buster to cease violating the licenses of the affected files.

[ Tests ]
The now excluded files were not shipped in any binary package or used
in the build process. Their removal should not have any affect on the
binary packages. I confirmed (using diffoscope) that the built debian
packages do not differ in content except in expected ways due to
changed package metadata.

I also manually confirmed that the game can be successfully started
and basic interactions inside the game still work.

[ Risks ]
Since the removed files are not part of any binary packages, it can be
easily confirmed that their removal has no negative effect. I see
virtually no risk introduced by this update.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The source tarball has been repacked to exclude these files:

* libs/libgcc_s.so.1
* libs/libstdc++.so.6
* libs/libgcc_s.so.1
* libs/libstdc++.so.6

Additionally a note about the repacked tarball has been added to
debian/copyright and the version mangling in debian/watch has been
updated to deal with the new +dsfg1 version suffix.
Binärdateien /tmp/OJJcX56xZH/dwarf-fortress-0.44.12/amd64/libs/libgcc_s.so.1 
und /tmp/JM3ObfSHmq/dwarf-fortress-0.44.12+dfsg1/amd64/libs/libgcc_s.so.1 sind 
verschieden.
Binärdateien /tmp/OJJcX56xZH/dwarf-fortress-0.44.12/amd64/libs/libstdc++.so.6 
und /tmp/JM3ObfSHmq/dwarf-fortress-0.44.12+dfsg1/amd64/libs/libstdc++.so.6 sind 
verschieden.
diff -Nru dwarf-fortress-0.44.12/debian/changelog 
dwarf-fortress-0.44.12+dfsg1/debian/changelog
--- dwarf-fortress-0.44.12/debian/changelog 2018-07-08 15:03:52.0 
+0200
+++ dwarf-fortress-0.44.12+dfsg1/debian/changelog   2021-03-31 
19:01:19.0 +0200
@@ -1,3 +1,10 @@
+dwarf-fortress (0.44.12+dfsg1-0+deb10u1) buster; urgency=high
+
+  * Remove unnecessary code copies with license violations from source
+tarball. (Closes: #986119)
+
+ -- Sven Bartscher   Wed, 31 Mar 2021 19:01:19 +0200
+
 dwarf-fortress (0.44.12-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru dwarf-fortress-0.44.12/debian/copyright 
dwarf-fortress-0.44.12+dfsg1/debian/copyright
--- dwarf-fortress-0.44.12/debian/copyright 2018-07-08 14:13:41.0 
+0200
+++ dwarf-fortress-0.44.12+dfsg1/debian/copyright   2021-03-31 
19:01:19.0 +0200
@@ -11,6 +11,15 @@
  do not grant all freedoms required by the DFSG. No modifications of
  the included binaries are permitted, and the binaries are not
  distributed with source code.
+Comment:
+ Some files have been removed from the original source tarballs, because
+ they are licensed under the GPL, but no source is available for them.
+Files-Excluded-amd64:
+ libs/libgcc_s.so.1
+ libs/libstdc++.so.6
+Files-Excluded-i386:
+ libs/libgcc_s.so.1
+ libs/libstdc++.so.6
 
 Files: *
 Copyright: 2002-2018 Tarn Adams. All rights reserved.
diff -Nru dwarf-fortress-0.44.12/debian/watch 
dwarf-fortress-0.44.12+dfsg1/debian/watch
--- dwarf-fortress-0.44.12/debian/watch 2018-06-24 13:22:23.0 +0200
+++ dwarf-fortress-0.44.12+dfsg1/debian/watch   2021-03-31 19:01:19.0 
+0200
@@ -1,7 +1,7 @@
 version=4
-opts="uversionmangle=s/^/0./,component=amd64" \
+opts="uversionmangle=s/^/0./,dversionmangle=s/\+dfsg\d+//,component=amd64" \
   http://bay12games.com/dwarves/older_versions.html \
   df_(\d+)_(\d+)_linux@ARCHIVE_EXT@ debian
-opts="uversionmangle=s/^/0./,component=i386" \
+opts="uversionmangle=s/^/0./,dversionmangle=s/\+dfsg\d+//,component=i386" \
   http://bay12games.com/dwarves/older_versions.html \
   df_(\d+)_(\d+)_linux32@ARCHIVE_EXT@ same
Binärdateien /tmp/OJJcX56xZH/dwarf-fortress-0.44.12/i386/libs/libgcc_s.so.1 und 
/tmp/JM3ObfSHmq/dwarf-fortress-0.44.12+dfsg1/i386/libs/libgcc_s.so.1 sind 
verschieden.
Binärdateien /tmp/OJJcX56xZH/dwarf-fortress-0.44.12/i386/libs/libstdc++.so.6 
und /tmp/JM3ObfSHmq/dwarf-fortress-0.44.12+dfsg1/i386/libs/libstdc++.so.6 sind 
verschieden.

Bug#986172: unblock: dwarf-fortress/0.47.04+dfsg1-1

[Sven Bartscher]

Control: tags -1 - moreinfo

Hi,

Am 31.03.21 um 09:55 schrieb Sebastian Ramacher:
> ACK, please remove the moreinfo tag once the new version is available in
> unstable.

0.47.04+dfsg1-1 has just been accepted into unstable.

Regards
Sven

Bug#986172: unblock: dwarf-fortress/0.47.04+dfsg1-1

[Sven Bartscher]

Control: retitle -1 unblock: dwarf-fortress/0.47.04+dfsg1-1

On Tue, 30 Mar 2021 22:32:08 +0200 Sven Bartscher
 wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package dwarf-fortress
> 
> [...]
> 
> unblock dwarf-fortress/0.47_04+dfsg1-1

I typoed the package version in my initial report. The version to be
unblocked is:

unblock dwarf-fortress/0.47.04+dfsg1-1

The updated version has not been uploaded to unstable yet.

Regards
Sven

Bug#986172: unblock: dwarf-fortress/0.47_04+dfsg1-1

[Sven Bartscher]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dwarf-fortress

[ Reason ]
It has been noted in #986119 that the upstream release tarballs for
dwarf-fortress include shared libraries but no corresponding source
code is available. The shared libraries in question are licensed under
GPL and thus not distributable without source code.

The affected files are not shipped in any binary packages. This
update fixes the issue by repacking the source tarballs to exclude
those files.

[ Impact ]
The package is not distributable in its current form, so it has to be
either updated or entirely removed from testing to cease violating the
licenses of the affected files.

[ Tests ]
The now excluded files were not shipped in any binary package or used
in the build process. Their removal should not have any affect on the
binary packages. I confirmed (using diffoscope) that the built debian
packages do not differ in content except in expected ways due to
changed package metadata and changes in the generaed manpage due to a
newer pandoc version being used in the build.

I also manually confirmed that the game can be successfully started
and basic interactions inside the game still work.

[ Risks ]
Since the removed files are not part of any binary packages, it can be
easily confirmed that their removal has no negative effect. I see
virtually no risk introduced by this update.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock dwarf-fortress/0.47_04+dfsg1-1
Binärdateien /tmp/x4E2O1qvMn/dwarf-fortress-0.47.04/amd64/libs/libgcc_s.so.1 
und /tmp/ag24SxYJ0c/dwarf-fortress-0.47.04+dfsg1/amd64/libs/libgcc_s.so.1 sind 
verschieden.
Binärdateien /tmp/x4E2O1qvMn/dwarf-fortress-0.47.04/amd64/libs/libstdc++.so.6 
und /tmp/ag24SxYJ0c/dwarf-fortress-0.47.04+dfsg1/amd64/libs/libstdc++.so.6 sind 
verschieden.
diff -Nru dwarf-fortress-0.47.04/debian/changelog 
dwarf-fortress-0.47.04+dfsg1/debian/changelog
--- dwarf-fortress-0.47.04/debian/changelog 2020-03-28 18:48:06.0 
+0100
+++ dwarf-fortress-0.47.04+dfsg1/debian/changelog   2021-03-30 
19:04:37.0 +0200
@@ -1,3 +1,10 @@
+dwarf-fortress (0.47.04+dfsg1-1) unstable; urgency=high
+
+  * Remove unnecessary code copies with license violations from source
+tarball. (Closes: #986119)
+
+ -- Sven Bartscher   Tue, 30 Mar 2021 19:04:37 
+0200
+
 dwarf-fortress (0.47.04-1) unstable; urgency=low
 
   * New upstream version
diff -Nru dwarf-fortress-0.47.04/debian/copyright 
dwarf-fortress-0.47.04+dfsg1/debian/copyright
--- dwarf-fortress-0.47.04/debian/copyright 2020-03-28 18:48:06.0 
+0100
+++ dwarf-fortress-0.47.04+dfsg1/debian/copyright   2021-03-30 
19:04:37.0 +0200
@@ -11,6 +11,15 @@
  do not grant all freedoms required by the DFSG. No modifications of
  the included binaries are permitted, and the binaries are not
  distributed with source code.
+Comment:
+ Some files have been removed from the original source tarballs, because
+ they are licensed under the GPL, but no source is available for them.
+Files-Excluded-amd64:
+ libs/libgcc_s.so.1
+ libs/libstdc++.so.6
+Files-Excluded-i386:
+ libs/libgcc_s.so.1
+ libs/libstdc++.so.6
 
 Files: *
 Copyright: 2002-2020 Tarn Adams. All rights reserved.
diff -Nru dwarf-fortress-0.47.04/debian/watch 
dwarf-fortress-0.47.04+dfsg1/debian/watch
--- dwarf-fortress-0.47.04/debian/watch 2020-03-28 18:48:06.0 +0100
+++ dwarf-fortress-0.47.04+dfsg1/debian/watch   2021-03-30 19:04:37.0 
+0200
@@ -1,7 +1,7 @@
 version=4
-opts="uversionmangle=s/^/0./,component=amd64" \
+opts="uversionmangle=s/^/0./,dversionmangle=s/\+dfsg\d+//,component=amd64" \
   https://bay12games.com/dwarves/older_versions.html \
   df_(\d+)_(\d+)_linux@ARCHIVE_EXT@ debian
-opts="uversionmangle=s/^/0./,component=i386" \
+opts="uversionmangle=s/^/0./,dversionmangle=s/\+dfsg\d+//,component=i386" \
   https://bay12games.com/dwarves/older_versions.html \
   df_(\d+)_(\d+)_linux32@ARCHIVE_EXT@ same
Binärdateien /tmp/x4E2O1qvMn/dwarf-fortress-0.47.04/i386/libs/libgcc_s.so.1 und 
/tmp/ag24SxYJ0c/dwarf-fortress-0.47.04+dfsg1/i386/libs/libgcc_s.so.1 sind 
verschieden.
Binärdateien /tmp/x4E2O1qvMn/dwarf-fortress-0.47.04/i386/libs/libstdc++.so.6 
und /tmp/ag24SxYJ0c/dwarf-fortress-0.47.04+dfsg1/i386/libs/libstdc++.so.6 sind 
verschieden.

Bug#986119: Source package includes files shared libraries with GPL violations

[Sven Bartscher]

Source: dwarf-fortress
Version: 0.44.12-1
Severity: serious

The source tarballs for both amd64 and i386 contain the following
shared libraries:

$ ls {amd64,i386}/libs/lib{gcc_s.so.1,stdc++.so.6}
amd64/libs/libgcc_s.so.1
amd64/libs/libstdc++.so.6
i386/libs/libgcc_s.so.1
i386/libs/libstdc++.so.6

These files are presumably compiled from GCC runtime components and
licensed under a GPL. But upstream does not publish or point to source
code for these files or give any licensing information for them.

This is clearly a violation of the licenses of these files and we can
not distribute them.

Since these files aren't shipped in any binary packages, we can just
repack the source tarball to exclude them, to sidestep the problem.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (990, 'testing-security'), (990, 'testing-debug'), (990, 
'testing'), (102, 'unstable-debug'), (102, 'unstable'), (101, 
'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-5-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#892058: Your Debian key is expiring

[Sven Bartscher]

Hi Felix,

Am 18.03.21 um 15:18 schrieb Felix Lechner:

According to my records, you may have received an earlier reminder—on
February 16, California time. Can you find it?


I actually have received it and probably just forgot to actually act on 
it. Thank you for your assistance and sorry for the noise!


Regards
Sven



OpenPGP_signature
Description: OpenPGP digital signature

Bug#892058: Your Debian key is expiring

[Sven Bartscher]

Am 18.03.21 um 01:32 schrieb Felix Lechner:

If you like this service, please leave a favorable comment here [2].
Thank you!


I find the reminders very helpful, every time I get them. Thank you very 
much for that!


Though one thing that bothers me about them, is that the email says, 
that the keyring update will happen on the 24th of each month, which 
leaves me with about a week to update my key, before it is too late.


Under regular circumstances this is of course enough for me to extend 
the expiration under regular circumstances, but I imagine if I were on 
vacation and didn't have access to my master key, I might very well find 
myself in a situation where I get the reminder, but don't have the means 
to actually extend my key before it is too late.


Maybe the reminder should be sent earlier in advance? If the reminder 
was sent one week before the second-to-last keyring update that would 
leave people with two chances to get their key extended in time. 
However, I also see that people have been complaining in the past, that 
the reminder were sent too early in advance, so that's just my 2¢.


Regards
Sven



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979263: User systemd units redshift.service and redshift-gtk.service are both enabled by default which cases both to spawn redshift

[Sven Bartscher]

Package: redshift-gtk
Version: 1.12-4
Severity: minor

Hi

I recently noticed that redshift and redshift-gtk now ship user-level
systemd instances, which appear to have been automatically activated,
so that systemd starts them automatically on login.

This causes two actual redshift instances to be started on login, as
seen here:

% ps ax | grep redshift
  10027 ?Ssl0:00 /usr/bin/redshift
  10028 ?Ssl0:00 /usr/bin/python3 /usr/bin/redshift-gtk
  10034 ?Sl 0:00 /usr/bin/redshift -v
  10045 pts/2S+ 0:00 grep redshift

This seems to happen because each of redshift.service and
redshift-gtk.service starts their own redshift instance.

These two instances then seem to cause other trouble. For example,
when deactivating redshift throgh the redshift-gtk icon, the display
shifts to the day temperature and then reverts immediately to the
night temperature, because only one of the redshift instances has
actually been deactivated.

I can fix this locally for me, by disabling redshift.service. But I
guess this package is used by users who aren't as experienced with
systemd, so I think a default configuration that works out-of-the-box
(without starting two competing redshift instances) would be
preferable.

Regards
Sven

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages redshift-gtk depends on:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.5-2
ii  init-system-helpers  1.60
ii  python3  3.9.1-1
ii  python3-gi   3.38.0-1+b2
ii  python3-xdg  0.26-3
ii  redshift 1.12-4

Versions of packages redshift-gtk recommends:
ii  at-spi2-core  2.38.0-2

redshift-gtk suggests no packages.

-- no debconf information

Bug#973654: TLS: start_SSL fails to set SSL_verifycn_name

[Sven Bartscher]

Hi,

Control: forwarded -1 https://gitlab.com/amavis/amavis/-/issues/72

Regards
Sven

Am 05.11.20 um 21:48 schrieb Brian May:
> Hello,
> 
> I received this bug report against amavisd-new in Debian.
> 
> For full details please see http://bugs.debian.org/

thank you, for forwarding the report to us! We copied it to our issue
tracker at Gitlab[1].

[1]: https://gitlab.com/amavis/amavis/-/issues

In the future, feel free to report bugs there instead of the mailing
list. This helps us to keep track of outstanding bugs and other issues.

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Bug#965122: cloud-init: NoCloud network configuration without set-name only works after second boot

[Sven Bartscher]

Package: cloud-init
Version: 20.2-2
Severity: normal

I started a cloud-image supplying the attached user-data, meta-data (empty) and 
network-config through a 
NoCloud ISO image. After booting the image, cloud-init created the expected 
configuration in 
/etc/udev/rules/70-persistent-net.rules and 
/etc/network/interfaces.d/50-cloud-init. However, the network 
interface doesn't actually get renamed and configured. Instead a configuration 
with dhcp enabled is created in 
/run/network/interfaces.d/ and is used to configure the interface. When the 
machine is booted a second time, 
the udev rule renames the interface as appropriate and the interface is 
configured with the supplied static 
network configuration.

This seems to happen, because udev doesn't evaluate the udev rule after it is 
created, because rules for that 
interface were already processed earlier after boot. cloud-init apparently 
doesn't trigger renaming the 
interface explicitly after creating the udev rule, unless the `set-name` 
property is set for that interface.

This problem can be worked aroung, by setting the `set-name` property, which 
causes cloud-init to rename the 
interface itself. However I would expect that cloud-init handles the missing 
`set-name` either by recognizing 
that the eni renderer always requires the interface to be renamed and act as if 
`set-name` was given or that 
it at least fails with a coherent failure message, stating that `set-name` 
needs to be set when the eni 
renderer is used. The current behavior that ends up in a silent semi-failure 
state is really confusing.

I used the following official cloud image:
debian-11-genericcloud-amd64-daily-20200716-329.qcow2

The cloud-init logs are attached

Regards
Sven

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

Kernel: Linux 5.7.0-1-cloud-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cloud-init depends on:
ii  fdisk   2.35.2-6
ii  gdisk   1.0.5-1
ii  ifupdown0.8.35+b1
ii  locales 2.30-8
ii  lsb-base11.1.0
ii  lsb-release 11.1.0
ii  net-tools   1.60+git20180626.aebd88e-1
ii  procps  2:3.3.16-5
ii  python3 3.8.2-3
ii  python3-configobj   5.0.6-4
ii  python3-jinja2  2.11.2-1
ii  python3-jsonpatch   1.25-3
ii  python3-jsonschema  3.2.0-3
ii  python3-oauthlib3.1.0-2
ii  python3-requests2.23.0+dfsg-2
ii  python3-yaml5.3.1-2
ii  util-linux  2.35.2-6

Versions of packages cloud-init recommends:
ii  cloud-guest-utils  0.31-2
pn  eatmydata  
ii  sudo   1.9.1-1

Versions of packages cloud-init suggests:
pn  btrfs-progs  
ii  e2fsprogs1.45.6-1
pn  xfsprogs 

-- no debconf information
2020-07-16 13:02:42,838 - util.py[DEBUG]: Cloud-init v. 20.2 running 
'init-local' at Thu, 16 Jul 2020 13:02:42 +. Up 1.99 seconds.
2020-07-16 13:02:42,838 - main.py[DEBUG]: No kernel command line url found.
2020-07-16 13:02:42,838 - main.py[DEBUG]: Closing stdin.
2020-07-16 13:02:42,840 - util.py[DEBUG]: Writing to /var/log/cloud-init.log - 
ab: [644] 0 bytes
2020-07-16 13:02:42,841 - util.py[DEBUG]: Changing the ownership of 
/var/log/cloud-init.log to 0:4
2020-07-16 13:02:42,841 - util.py[DEBUG]: Attempting to remove 
/var/lib/cloud/instance/boot-finished
2020-07-16 13:02:42,841 - util.py[DEBUG]: Attempting to remove 
/var/lib/cloud/data/no-net
2020-07-16 13:02:42,841 - handlers.py[DEBUG]: start: init-local/check-cache: 
attempting to read from cache [check]
2020-07-16 13:02:42,841 - util.py[DEBUG]: Reading from 
/var/lib/cloud/instance/obj.pkl (quiet=False)
2020-07-16 13:02:42,841 - stages.py[DEBUG]: no cache found
2020-07-16 13:02:42,841 - handlers.py[DEBUG]: finish: init-local/check-cache: 
SUCCESS: no cache found
2020-07-16 13:02:42,841 - util.py[DEBUG]: Attempting to remove 
/var/lib/cloud/instance
2020-07-16 13:02:42,843 - stages.py[DEBUG]: Using distro class 
2020-07-16 13:02:42,843 - __init__.py[DEBUG]: Looking for data source in: 
['NoCloud', 'None'], via packages ['', 'cloudinit.sources'] that matches 
dependencies ['FILESYSTEM']
2020-07-16 13:02:42,845 - __init__.py[DEBUG]: Searching for local data source 
in: ['DataSourceNoCloud']
2020-07-16 13:02:42,846 - handlers.py[DEBUG]: start: init-local/search-NoCloud: 
searching for local data from DataSourceNoCloud
2020-07-16 13:02:42,846 - __init__.py[DEBUG]: Seeing if we can get any data 
from 
2020-07-16 13:02:42,846 - __init__.py[DEBUG]: Update datasource metadata and 
network config due to events: New instance first boot
2020-07-16 13:02:42,846 - util.py[DEBUG]: Running command 
['systemd-detect-virt', '--quiet', '--container'] with allowed return codes [0] 
(shell=False, capture=True)
2020-07-16 13:02:42,851 

Bug#964963: Icons mail-thread-ignored.png and mail-thread-watched.png not correctly displayed

[Sven Bartscher]

Package: libkf5messagelist5abi1
Version: 4:20.04.1-1
Severity: minor

kmail apparently doesn't display icons for ignored or watched threads
in message lists or the design editor for message lists. The icon
seems to be missing, because libkf5messagelist loads the icons in
messagelist/core/theme.cppL1267 as follows:

<< new 
QPixmap(QIcon::fromTheme(QStringLiteral("messagelist/pics/mail-thread-watch.png")).pixmap(mIconSize,
 mIconSize))
<< new 
QPixmap(QIcon::fromTheme(QStringLiteral("messagelist/pics/mail-thread-ignored.png")).pixmap(mIconSize,
 mIconSize))

However, I could find no theme in the Debian repository providing this
path. Instead I found these close fits:

$ apt-file search mail-thread-ignored   
breeze-icon-theme: 
/usr/share/icons/breeze-dark/actions/16/mail-thread-ignored.svg
breeze-icon-theme: 
/usr/share/icons/breeze-dark/actions/22/mail-thread-ignored.svg
breeze-icon-theme: 
/usr/share/icons/breeze-dark/actions/24/mail-thread-ignored.svg
breeze-icon-theme: /usr/share/icons/breeze/actions/16/mail-thread-ignored.svg
breeze-icon-theme: /usr/share/icons/breeze/actions/22/mail-thread-ignored.svg
breeze-icon-theme: /usr/share/icons/breeze/actions/24/mail-thread-ignored.svg
deepin-icon-theme: /usr/share/icons/bloom/actions/24/mail-thread-ignored.svg
kmail: /usr/share/doc/HTML/en/kmail2/mail-thread-ignored.png
numix-icon-theme: /usr/share/icons/Numix/16/actions/mail-thread-ignored.svg
numix-icon-theme: /usr/share/icons/Numix/22/actions/mail-thread-ignored.svg
papirus-icon-theme: 
/usr/share/icons/Papirus-Dark/16x16/actions/mail-thread-ignored.svg
papirus-icon-theme: 
/usr/share/icons/Papirus-Dark/22x22/actions/mail-thread-ignored.svg
papirus-icon-theme: 
/usr/share/icons/Papirus-Dark/24x24/actions/mail-thread-ignored.svg
papirus-icon-theme: 
/usr/share/icons/Papirus/16x16/actions/mail-thread-ignored.svg
papirus-icon-theme: 
/usr/share/icons/Papirus/22x22/actions/mail-thread-ignored.svg
papirus-icon-theme: 
/usr/share/icons/Papirus/24x24/actions/mail-thread-ignored.svg
papirus-icon-theme: 
/usr/share/icons/ePapirus/16x16/actions/mail-thread-ignored.svg
papirus-icon-theme: 
/usr/share/icons/ePapirus/22x22/actions/mail-thread-ignored.svg
papirus-icon-theme: 
/usr/share/icons/ePapirus/24x24/actions/mail-thread-ignored.svg

My guess is, that the paths for these icons need to be adjusted to
match one of these icons.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libkf5messagelist5abi1 depends on:
ii  kf5-messagelib-data  4:20.04.1-1
ii  kio  5.70.1-1
ii  libc62.30-8
ii  libgcc-s110.1.0-4
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-20.04]4:20.04.1-2+b1
ii  libkf5akonadimime5 [libkf5akonadimime5-20.04]4:20.04.1-1
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-20.04]  4:20.04.1-1
ii  libkf5completion55.70.0-1
ii  libkf5configcore55.70.0-1
ii  libkf5configgui5 5.70.0-1
ii  libkf5configwidgets5 5.70.0-1
ii  libkf5coreaddons55.70.0-1
ii  libkf5i18n5  5.70.0-1
ii  libkf5iconthemes55.70.0-1
ii  libkf5itemmodels55.70.0-1.1
ii  libkf5kiocore5   5.70.1-1
ii  libkf5messagecore5abi1 [libkf5messagecore5-20.04]4:20.04.1-1
ii  libkf5mime5abi1 [libkf5mime5-20.04]  20.04.1-1
ii  libkf5pimcommon5abi2 [libkf5pimcommon5-20.04]4:20.04.1-1
ii  libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-20.04]  4:20.04.1-1
ii  libkf5textwidgets5   5.70.0-1
ii  libkf5widgetsaddons5 5.70.0-1
ii  libkf5xmlgui55.70.0-1+b1
ii  libqt5core5a 5.14.2+dfsg-4
ii  libqt5gui5   5.14.2+dfsg-4
ii  libqt5widgets5  

Bug#964781: xhci "ERROR Transfer event TRB DMA ptr not part of current TD" on Dell WD19TB thunderbolt dock

[Sven Bartscher]

Package: src:linux
Version: 5.7.6-1
Severity: normal

I have a Dell XPS 15 9500 connected to a Dell WD19TB thunderbolt dock
and various periphery connected through the dock, namely:

* USB keyboard
* USB mouse
* HDMI display
* ethernet (according to lsusb also a USB device)
* USB headset

Sometimes all USB devices (keyboard, mouse, ethernet and headset)
connected to the dock get disconnected while the HDMI output continues
to work fine.

I haven't been able to figure out what the exact condition are, under
which this problems occurs. However, I can often reproduce the issue
by playing music from youtube through a headset connected to the
dock. Using a local sound source doesn't reproduce the issue as
reliably.

When the problem occurs, it usually happens like this:

1. I play music via youtube as described above.

2. Around [ 6796.037342] in the kernel log, the sound starts
   crackling. The crackling noise seems to correspond with the error
   messages starting to appear in the log at the same time.

3. At [ 6837.948460] all USB devices on the dock get disconnected. The
   mouse and keyboard stop responding, the ethernet interface vanishes
   from `ip a` output and pulseaudio removes the headset as a playback
   device and switches to a different output device. However, the
   devices are usually still listed by lsusb.

4. I can usually reset the devices to a working condition by issuing
   the following commands:

   $ echo ":3b:00.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind
   $ echo ":3b:00.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind 

-- Package-specific info:
** Version:
Linux version 5.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Debian 5.7.6-1 
(2020-06-24)

** Command line:
BOOT_IMAGE=/vmlinuz-5.7.0-1-amd64 
root=UUID=b2d71295-5b17-4273-b46b-da957bc247c3 ro quiet splash zswap.enabled=1

** Tainted: PWOE (12801)
 * proprietary module was loaded
 * kernel issued warning
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[ 5939.044677] usb 5-2.3.5: New USB device strings: Mfr=0, Product=1, 
SerialNumber=0
[ 5939.044679] usb 5-2.3.5: Product: Dell dock
[ 5939.051219] hid-generic 0003:413C:B06F.0021: hiddev1,hidraw6: USB HID v1.11 
Device [Dell dock] on usb-:3b:00.0-2.3.5/input0
[ 5940.382569] IPv6: ADDRCONF(NETDEV_CHANGE): enxc03ebab88cdb: link becomes 
ready
[ 5940.382795] r8152 6-2.4:1.0 enxc03ebab88cdb: carrier on
[ 5945.734624] usb 5-2.3.3: reset low-speed USB device number 7 using xhci_hcd
[ 5946.102811] usb 5-2.3.2.1: reset full-speed USB device number 9 using 
xhci_hcd
[ 6066.017094] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM
[ 6066.162874] iwlwifi :00:14.3: FW already configured (0) - re-configuring
[ 6479.015330] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM
[ 6479.163027] iwlwifi :00:14.3: FW already configured (0) - re-configuring
[ 6796.037342] xhci_hcd :3b:00.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 1 comp_code 36
[ 6796.037354] xhci_hcd :3b:00.0: Looking for event-dma ffb81a80 
trb-start ffb81a90 trb-end ffb81a90 seg-start ffb81000 
seg-end ffb81ff0
[ 6799.587398] xhci_hcd :3b:00.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 1 comp_code 36
[ 6799.587409] xhci_hcd :3b:00.0: Looking for event-dma ffb81940 
trb-start ffb81950 trb-end ffb81950 seg-start ffb81000 
seg-end ffb81ff0
[ 6802.689195] xhci_hcd :3b:00.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 1 comp_code 1
[ 6802.689208] xhci_hcd :3b:00.0: Looking for event-dma ffb81be0 
trb-start ffb81bf0 trb-end ffb81bf0 seg-start ffb81000 
seg-end ffb81ff0
[ 6802.977106] xhci_hcd :3b:00.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 1 comp_code 1
[ 6802.977117] xhci_hcd :3b:00.0: Looking for event-dma ffc0bdf0 
trb-start ffc0be00 trb-end ffc0be00 seg-start ffc0b000 
seg-end ffc0bff0
[ 6803.161146] xhci_hcd :3b:00.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 1 comp_code 1
[ 6803.161154] xhci_hcd :3b:00.0: Looking for event-dma ffb81980 
trb-start ffb81990 trb-end ffb81990 seg-start ffb81000 
seg-end ffb81ff0
[ 6803.556231] xhci_hcd :3b:00.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 1 comp_code 1
[ 6803.556244] xhci_hcd :3b:00.0: Looking for event-dma ffb81250 
trb-start ffb81260 trb-end ffb81260 seg-start ffb81000 
seg-end ffb81ff0
[ 6803.747123] xhci_hcd :3b:00.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 1 comp_code 1
[ 6803.747138] xhci_hcd :3b:00.0: Looking for event-dma 

Bug#962492: Missing copyright attributions and other problems in debian/copyright

[Sven Bartscher]

Source: vde2
Version: 2.3.2+r586-2.2+b1
Severity: serious
Justification: Policy ยง12.5

Greetings,

during the review of this package in the NEW queue I discovered
various issues that are already present in the current unstable
version of the package as outlined below.

These files are marked in the copyright file as BSD-4-clause, but
the files themselves only contain 3 clauses:
 * src/slirpvde/cksum.c
 * src/slirpvde/ip.h
 * src/slirpvde/ip_icmp.c
 * src/slirpvde/ip_icmp.h
 * src/slirpvde/ip_input.c
 * src/slirpvde/ip_output.c
 * src/slirpvde/mbuf.h
 * src/slirpvde/misc.c
 * src/slirpvde/qemu-queue.h
 * src/slirpvde/tcp.h
 * src/slirpvde/tcp_input.c
 * src/slirpvde/tcp_output.c
 * src/slirpvde/tcp_subr.c
 * src/slirpvde/tcp_timer.c
 * src/slirpvde/tcp_timer.h
 * src/slirpvde/tcp_var.h
 * src/slirpvde/tcpip.h
 * src/slirpvde/udp.c
 * src/slirpvde/udp.h

The following authors are not attributed in the copyright file for
files that list them as copyright holders. This list is not
necessarily exhaustive. Please check every file and make sure all
authors in the files are attributed in debian/copyright.

2002 Yon Uriarte, Jeff Dike:
 * README

2014 Renzo Davoli, Alessandro Ghedini VirtualSquare:
 * src/vde_vxlan/plug.h

2001,2002 Jeff Dike:
 * src/kvde_switch/consmgmt.h
 * src/kvde_switch/datasock.h
 * src/kvde_switch/kvde_switch.c
 * src/vde_switch/consmgmt.h
 * src/vde_switch/datasock.h
 * src/vde_switch/fstp.h
 * src/vde_switch/hash.c
 * src/vde_switch/hash.h
 * src/vde_switch/port.c
 * src/vde_switch/port.h
 * src/vde_switch/switch.h
 * src/vde_switch/tuntap.h
 * src/vde_switch/vde_switch.c
 * src/vde_tunctl.c
 * src/vde_tunctl.c

2004 Mattia Belletti:
 * src/kvde_switch/consmgmt.c
 * src/kvde_switch/datasock.c
 * src/kvde_switch/sockutils.c
 * src/kvde_switch/sockutils.h
 * src/vde_switch/consmgmt.c
 * src/vde_switch/datasock.c
 * src/vde_switch/sockutils.c
 * src/vde_switch/sockutils.h
 * src/vde_switch/tuntap.c
 * src/vde_switch/vde_switch.c

2007 Luca Bigliardi:
 * include/cmdparse.h
 * include/libvdemgmt.h
 * src/common/cmdparse.c
 * src/lib/libvdemgmt.c
 * src/lib/libvdesnmp.c
 * src/unixcmd.c
 * src/vde_pcapplug.c

2006-2011 Daniele Lacamera:
 * src/lib/python/VdePlug.py
 * src/lib/python/vdeplug_python.c
 * src/vde_cryptcab/crc32.c
 * src/vde_cryptcab/crc32.h
 * src/vde_cryptcab/cryptcab.c
 * src/vde_cryptcab/cryptcab.h
 * src/vde_cryptcab/vde_cryptcab_client.c
 * src/vde_cryptcab/vde_cryptcab_server.c
 * src/vde_l3/vde_buff.h
 * src/vde_l3/vde_l3.c
 * src/vde_router/vde_headers.h
 * src/vde_router/vde_router.c
 * src/vde_router/vde_router.h
 * src/vde_router/vder_arp.c
 * src/vde_router/vder_arp.h
 * src/vde_router/vder_datalink.c
 * src/vde_router/vder_datalink.h
 * src/vde_router/vder_icmp.c
 * src/vde_router/vder_icmp.h
 * src/vde_router/vder_olsr.c
 * src/vde_router/vder_packet.c
 * src/vde_router/vder_packet.h
 * src/vde_router/vder_queue.c
 * src/vde_router/vder_queue.h

2005 Ludovico Gargenghi: 
 * src/common/canonicalize.c
 * src/common/poll.c

2005 Richard Kettlewell:
 * src/common/open_memstream.c

2007 Filippo Giunchedi:
 * include/libvdesnmp.h

2004-2008 Fabrice Bellard:
 * src/slirpvde/bootp.c
 * src/slirpvde/slirp.c

2004 Magnus Damm:
 * src/slirbvde/tftp.c

2007 Daniel Lacamera, 200 Florian Heinz, Julien Oster:
 * src/vde_over_ns/dns.c
 * src/vde_over_ns/dns.h
 * src/vde_over_ns/dns_proto.h
 * src/vde_over_ns/encode.c
 * src/vde_over_ns/fun.h
 * src/vde_over_ns/pstack.c
 * src/vde_over_ns/pstack.h
 * src/vde_over_ns/queue.c
 * src/vde_over_ns/util.c
 * src/vde_over_ns/vde_io.c
 * src/vde_over_ns/vde_over_ns.c

1999 Andrea Arcangeli:
 * src/vde_router/rbtree.c
 * src/vde_router/rbtree.h

2002 David Woodhouse:
 * src/vde_router/rbtree.c

Allessandro Ghedini VirtualSquare:
 * src/vde_vxlan/log.c
 * src/vde_vxlan/log.h
 * src/vde_vxlan/plug.c
 * src/vde_vxlan/plug.h
 * src/vde_vxlan/vde_vxlan.c
 * src/vde_vxlan/vxlan.c
 * src/vde_vxlan/vxlan.h
 * src/vde_vxlan/vxlan_hash.c
 * src/vde_vxlan/vxlan_hash.h

And finally a matter of personal taste: debian/copyright contains the
following line:

> Licenses for some components in src/slirpvde in addition to GPL-2:

and then goes on to list the licenses that apply to some files in that
directory. I think this fullfills the requirement of stating the
license conditions for those files, but it doesn't really help me
if I want to know *which* files these license conditions apply
to. Stating the files each of these licenses applies to explicitly
would make the statement more helpful, especially to ftp-masters doing
future reviews of this package.

Regards
Sven

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 

Bug#960675: Default apache.conf has broken authentication

[Sven Bartscher]

Package: icinga-cgi
Version: 1.14.2+ds-1
Severity: normal

In previous versions the shipped default apache2.conf contained these
authorization related directives:

```
Order Allow,Deny
Allow From all
[...]
Require valid-user
```

This had the effect that user had to authenticate (be a `valid-user`)
to access the web interface. However, in the version this bug applies
to, the `Order` and `Allow` directives have been replaced by a single
`Require all granted` directive. Now the two `Require' directives
interact differently, than was previously intended. Instead of
requiring a `valid-user` the `all granted` now takes precedence and
users aren't required to authenticate.

I'm aware this probably won't get fixed, because the icinga package
was removed from unstable. I'm just filing this bug to document it for
anyone who might come across this problem.

Regards
Sven

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#950341: kubectx: kubernetes has been requested to be removed

[Sven Bartscher]

Hi,

On Fri, 31 Jan 2020 16:01:19 +0100 Andreas Beckmann  wrote:
> the kubernetes package has been requested to be removed (#950247), but
> kubectx still build-depends on it.
> 
> Please find a solution.

Just adding my two cents, as I'm the one who originally reported the RM
bug against kubernetes. I originally filed the RM bug, because I didn't
see how the kubernetes package adds any value for users. In the worst
case someone might use it and be surprised by the bugginess and old age
of the package or even get hit by its abundant security issues. However,
I have no particular technical problem with the package, so it would be
fine by me if kubernetes stays in unstable just to satisfy the
dependency for kubectx until a better solution is found.

I just noticed that there are also RM bugs for dependencies of
kubernetes (#902180) and apparently they actually do have a good reason
to remove the package, so there actually seems to be a need to find a
solution for this soon. Unfortunately, right now, I don't see a better
solution than removing kubectx from unstable.

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Bug#950247: RM: kubernetes -- RoQA; Unmaintained and RC buggy

[Sven Bartscher]

Am Fri, 31 Jan 2020 14:21:48 +0200
schrieb Juhani Numminen :
> Please also consider any packages that depend on kubernetes, i.e.
> kubectx. Should it be removed then as well? Is kubectx maintainer
> aware of the plan to remove kubernetes?

Hi Juhani,

Yes, I forgot to consider the reverse dependencies of kubernetes. My
apologies. I will contact the maintainer of kubectx and ask what they
think about this and how they would like to go forward.

Regards
Sven


pgpM2aZ25XpFk.pgp
Description: Digitale Signatur von OpenPGP

Bug#950247: RM: kubernetes -- RoQA; Unmaintained and RC buggy

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal

Greetings,

The kubernetes package has been orphaned for more than two years now
and has a whole range of release critical bugs. The popcon data for
the package suggests that the package doesn't have a lot of
users. Providing the package in its current form is probably more of a
disservice to users than not providing it, as both the server and the
client components have various security issues. While the client
component can work with newer server versions, lots of basic features
break, when you actually try to use them.

Regards
Sven




pgpyjWwEdjY9E.pgp
Description: Digitale Signatur von OpenPGP

Bug#949924: Manpage mentions unionfs, but it is not used anymore

[Sven Bartscher]

Package: dwarf-fortress
Version: 0.44.12-3
Severity: minor

The manpage of dwarf-fortress currently mentions that unionfs-fuse is
used, but it is actuall not used anymore. The manpage should be
updated to reflect this.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dwarf-fortress depends on:
ii  dwarf-fortress-data 0.44.12-3
ii  libc6   2.29-9
ii  libgcc1 1:9.2.1-22
ii  libglib2.0-02.62.4-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libgtk2.0-0 2.24.32-4
ii  libsdl-image1.2 1.2.12-12
ii  libsdl-ttf2.0-0 2.0.11-6
ii  libsdl1.2debian 1.2.15+dfsg2-5
ii  libstdc++6  9.2.1-22
ii  python3 3.7.5-3
ii  python3-xdg 0.26-1
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages dwarf-fortress recommends:
ii  libopenal1  1:1.19.1-1+b1

dwarf-fortress suggests no packages.

-- no debconf information

Bug#946363: reportbug can't identify the package of a bug specified with -N when the bug is files against a source package

[Sven Bartscher]

Package: reportbug
Version: 7.5.3
Severity: normal

Greetings

I recently tried to submit an additional report for the bug #939875
which is filed against src:linux, but apparently reportbug struggles
to identify src:linux as a proper package name:

$ reportbug --pgp --email 'kritzef...@debian.org' -N 939875  
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'Sven Bartscher ' as your from address.
Retrieving report #939875 from Debian bug tracking system...
What do you want to do now? [N|x|o|r|b|e|q|?]? x
Getting status for src:linux...
W: Paket src:linux kann nicht gefunden werden.
No matching source or binary packages.
A package named "src:linux" does not appear to be installed; do you want to 
search for a similar-looking filename in
an installed package [Y|n|q|?]?


reportbug still allows me to send the followup, if I press N:


A package named "src:linux" does not appear to be installed; do you want to 
search for a similar-looking filename in
an installed package [Y|n|q|?]? n
Getting available info for src:linux...
Will send report to Debian (per lsb_release).

Please provide a subject for your response.
[Re: linux-image-5.2.0-2-amd64: Suspend fails. Machine shuts down after approx 
30 seconds]> 

Enter any additional addresses this report should be sent to; press ENTER after 
each address. Press ENTER on a blank
line to continue.
> 

Spawning emacsclient...
Waiting for Emacs...


At this point the report template looks like this (delimiters inserted
by me):


START OF TEMPLATE
Subject: Re: linux-image-5.2.0-2-amd64: Suspend fails. Machine shuts down after 
approx 30 seconds
Followup-For: Bug #939875
Package: src:linux



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
END OF TEMPLATE


This looks like it only gathered the generic system information, even
though reports for src:linux usually gather a lot more information.

Regards
Sven

-- Package-specific info:
** Environment settings:
EDITOR="emacsclient -t"
PAGER="less -R"
VISUAL="emacsclient -c"
DEBEMAIL="sven.bartsc...@credativ.de"
DEBFULLNAME="Sven Bartscher"
INTERFACE="text"

** /home/sven/.reportbugrc:
reportbug_version "7.1.7"
mode expert
ui text
smtphost "mail.credativ.com"
smtpuser "sba"
smtptls

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt1.8.4
ii  python33.7.5-1
ii  python3-reportbug  7.5.3
ii  sensible-utils 0.0.12+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf-utils   1.5.73
ii  debsums 2.2.4
ii  dlocate 1.07+nmu1
ii  emacs-bin-common1:26.1+1-4
ii  file1:5.37-6
ii  gnupg   2.2.17-3
ii  postfix [mail-transport-agent]  3.4.7-2
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.8.4
ii  file   1:5.37-6
ii  python33.7.5-1
ii  python3-apt1.8.4+b1
ii  python3-debian 0.1.36
ii  python3-debianbts  2.8.2
ii  python3-requests   2.21.0-1
ii  sensible-utils 0.0.12+nmu1

python3-reportbug suggests no packages.

-- no debconf information

Bug#945575: The manpage points to a non-existent file in /usr/share/doc

[Sven Bartscher]

Package: whalebuilder
Version: 0.7
Severity: minor

The manpage for whalebuilder contains the following text:

> For more information, see /usr/share/doc/whalebuilder/README.md.

But /usr/share/doc/whalebuilder/README.md doesn't exist. Instead there
is /usr/share/doc/whalebuilder/README.md.gz. The reference in the
manpage should probably be corrected.

Regards
Sven

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages whalebuilder depends on:
ii  docker-ce5:19.03.5~3-0~debian-buster
ii  ruby 1:2.5.2
ii  ruby-debian  0.3.10
ii  ruby-gpgme   2.0.19-1

Versions of packages whalebuilder recommends:
ii  debootstrap  1.0.116
ii  fakeroot 1.24-1

Versions of packages whalebuilder suggests:
pn  xserver-xephyr | xpra  

-- no debconf information

Bug#943848: Should depend on gir1.2-soup-2.4

[Sven Bartscher]

Package: lollypop
Version: 1.2.1-1
Severity: important

After installing lollypop and trying to start it through the
application menu, nothing happened. Lollypop didn't start as
expected. Trying to start it on the terminal revealed the following
error message:

$ lollypop
Traceback (most recent call last):
  File "/usr/bin/lollypop", line 45, in 
from lollypop.application import Application
  File "/usr/lib/python3/dist-packages/lollypop/application.py", line 40, in 

from lollypop.art import Art
  File "/usr/lib/python3/dist-packages/lollypop/art.py", line 18, in 
from lollypop.art_album import AlbumArt
  File "/usr/lib/python3/dist-packages/lollypop/art_album.py", line 26, in 

from lollypop.helper_task import TaskHelper
  File "/usr/lib/python3/dist-packages/lollypop/helper_task.py", line 14, in 

gi.require_version("Soup", "2.4")
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in 
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Soup not available

Installig fir1.2-soup-2.4 fixed the issue. Apparently lollypop needs a
dependency on that package.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lollypop depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  gir1.2-gst-plugins-base-1.0  1.16.1-1
ii  gir1.2-gstreamer-1.0 1.16.1-1
ii  gir1.2-secret-1  0.19.1-1
ii  gir1.2-totemplparser-1.0 3.26.3-1
ii  gstreamer1.0-libav   1.16.1-1
ii  python3  3.7.5-1
ii  python3-bs4  4.8.0-2
ii  python3-gi   3.34.0-1
ii  python3-pil  6.2.0-1
ii  python3-pylast   3.1.0-1

lollypop recommends no packages.

lollypop suggests no packages.

-- no debconf information

Bug#943738: Syncing to an external device should not remove files from the device (at least without asking)

[Sven Bartscher]

Package: rhythmbox
Version: 3.4.3-2+b1
Severity: normal

Today I was exploring how Rythmbox can sync files between my local
music collection and my Android phone via USB. Much to my dismay, I
noticed that “sync” in Rhythmbox apparently means to sync the state of
my local music colletion onto the external device and also includes
deleting all music files from the device that aren't in my local
collection.

Now this was quite a shock for me. Usually I would expect a warning,
preferably a big fat one, before files get irrevocably deleted. But
apparently pressing a button labeled “Sync” is all it took to start
deleting files. Because of this I lost several files today, some of
which I will probably never get back.

Instead of just deleting files, I think Rhythmbox should do one of the
following:

* Suggest to import the files, which would have been deleted, into my
  local collection

* Leave the files where they are, without doing anything

* Ask me clearly if I really want these files deleted before deleting
  them. This warning should include a list of the files being deleted.

Regards
Sven

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rhythmbox depends on:
ii  dbus1.12.16-2
ii  gstreamer1.0-plugins-base   1.16.1-1
ii  gstreamer1.0-plugins-good   1.16.1-1
ii  gstreamer1.0-x  1.16.1-1
ii  libc6   2.29-2
ii  libglib2.0-02.62.2-1
ii  libgstreamer-plugins-base1.0-0  1.16.1-1
ii  libgstreamer1.0-0   1.16.1-1
ii  libgtk-3-0  3.24.12-1
ii  libpeas-1.0-0   1.22.0-4
ii  librhythmbox-core10 3.4.3-2+b1
ii  libx11-62:1.6.8-1
ii  media-player-info   24-2
ii  rhythmbox-data  3.4.3-2

Versions of packages rhythmbox recommends:
ii  avahi-daemon 0.7-4+b1
ii  gstreamer1.0-plugins-ugly1.16.1-1
ii  gstreamer1.0-pulseaudio  1.16.1-1
ii  gvfs-backends1.42.1-1
ii  notification-daemon  3.20.0-4
ii  rhythmbox-plugins3.4.3-2+b1
ii  xfce4-notifyd [notification-daemon]  0.4.4-1+b1
ii  yelp 3.34.0-1

Versions of packages rhythmbox suggests:
pn  gnome-codec-install  
pn  gnome-control-center 
ii  gstreamer1.0-plugins-bad 1.16.1-1+b1
pn  rhythmbox-plugin-cdrecorder  

-- no debconf information

Bug#919602: apache2: reload via systemd: apache2.service: Failed to set up mount namespacing: No such file or directory

[Sven Bartscher]

Hi,

On Thu, 17 Jan 2019 19:59:45 +0100 Philipp Marek 
wrote:
> Package: apache2
> Version: 2.4.37-1
> Severity: normal
> 
> During a reload for log rotation, apache was stopped instead of reloaded:
> 
> [...]

do you use tools to age out files in /var/tmp or /tmp? I recently
encountered this problem myself (on Jessie) and the cause was, that
tmpreaper deleted the private tmp directories of the apache2.service
unit. I didn't observe the apache2 service being stopped after receiving
the error though, so you problem might actually be separate from mine.

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Bug#941149: Steam breaks DPMS while running

[Sven Bartscher]

Control: forwarded -1
https://github.com/ValveSoftware/steam-for-linux/issues/5607

Hi smcv,

thanks for the pointer! I just checked and apparently the issue was
already reported with the number 5607.

Regards
Sven


Am 25.09.19 um 23:14 schrieb Simon McVittie:
> On Sat, 21 Sep 2019 at 21:53:26 +0200, Sven Bartscher wrote:
>> Apparently when steam is running prevents any DPMS timers to actually
>> power down the display.
> 
> Debian does not have access to the Steam client's source code, so we
> cannot change its behaviour. Please report issues in the proprietary Steam
> client to <https://github.com/ValveSoftware/steam-for-linux/issues/>.
> 
> Thanks,
> smcv
> 



signature.asc
Description: OpenPGP digital signature

Bug#941149: Steam breaks DPMS while running

[Sven Bartscher]

Package: steam
Version: 1.0.0.61-2
Severity: normal

Apparently when steam is running prevents any DPMS timers to actually
power down the display. I think this is might be considered a feature
in some situations where the display is supposed to stay on, but for
me steam keeps the display on when it is just minimized into the
system tray, so there is literally nothing that steam might show me
that would justify keeping the display from going into standby.

I used these steps to reproduce the problem:

* Steam is not running
* Run `xset dpms 0 0 5` to be able to quickly tell if dpms still works
  (it does at this point)
* Start steam and wait for it to minimize into the system tray (dpms
  still works)
* Open the steam library from the system tray
* DPMS doesn't trigger anymore

At this point DPMS doesn't trigger based on time anymore. Minimizing
steam doesn't make it work again. The only way I found to make DPMS
work again is to close steam completely.

Apparently this only affects time based DPMS. Using
`xset dpms force *` still works as expected.

I'm running steam in XFCE with xmonad instead of xfwm.

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages steam depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libc6  2.29-1
ii  libgl1-mesa-dri19.1.6-1
ii  libgl1-mesa-glx19.1.6-1
ii  libgpg-error0  1.36-7
ii  libstdc++6 9.2.1-8
ii  libudev1   242-7
ii  libx11-6   2:1.6.7-1
ii  libxcb-dri3-0  1.13.1-2
ii  libxinerama1   2:1.1.4-2
ii  xz-utils   5.2.4-1+b1

Versions of packages steam recommends:
ii  ca-certificates   20190110
ii  fontconfig2.13.1-2+b1
ii  fonts-liberation  1:1.07.4-10
ii  libxss1   1:1.2.3-1
ii  mesa-vulkan-drivers   19.1.6-1
ii  steam-devices 1.0.0.61-2
ii  xfce4-terminal [x-terminal-emulator]  0.8.8-1+b1
ii  xterm [x-terminal-emulator]   348-2

Versions of packages steam suggests:
ii  nvidia-driver-libs-i386  430.40-2
ii  nvidia-vulkan-icd430.40-2

Versions of packages steam is related to:
ii  libc6   2.29-1
ii  libgl1  1.1.0-1+b1
ii  libgl1-mesa-dri 19.1.6-1
ii  libglx-mesa0 [libglx-vendor]19.1.6-1
ii  libglx-nvidia0 [libglx-vendor]  430.40-2
ii  libxcb-dri3-0   1.13.1-2
ii  nvidia-driver   430.40-2
ii  nvidia-driver-libs  430.40-2
ii  nvidia-driver-libs-i386 430.40-2

-- debconf information:
* steam/question: I AGREE
* steam/license:
  steam/purge:
  steam/need-nvidia-i386:

-- debsums errors found:
debsums: package steam is not installed

Bug#931173: Configuring static networking via NoCloud with Network Config Version 2 does not work

[Sven Bartscher]

Package: cloud-init
Version: 18.3-6
Severity: normal

I was trying to start a machine with a static network setup using
cloud-init. I supplied cloud-init with the following data on a NoCloud
ISO image:

/meta-data:
instance-id: iid-foo-1
local-hostname: foo

/user-data:
#cloud-config
chpasswd: { expire: False }
password: 
ssh_authorized_keys:
  - 
ssh_pwauth: True
timezone: Europe/Berlin
users:
  - default

/network-config:
version: 2
ethernets:
  enp1s0:
match:
  macaddress: "52:54:00:95:3b:42"
addresses:
  - 192.168.123.2/255.255.255.0
gateway4: 192.168.123.1

The specified network-config doesn't seem to have any actual effect on
what actually happens when the system boots. From what I see,
cloud-init generates a configuration file from my specified
configuration in /etc/network/interfaces.d/50-cloud-init.cfg with the
following contents:

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto enp1s0
iface enp1s0 inet static
address 192.168.123.2/24
gateway 192.168.123.1

but the file apparently has not effect, as
/run/network/interfaces.d/enp1s0 seems to have precedence and
apparently always uses dhcp for the interface.

I also tried to use the set-name option of the Network Configuration
Version 2 format, to change the name of the interface, but apparently
that really confuses ifup, because it still tries to bring up the old
interface name.

-- System Information:
Debian Release: 10.0
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cloud-init depends on:
ii  cloud-guest-utils   0.29-1
ii  fdisk   2.33.1-0.1
ii  gdisk   1.0.3-1.1
ii  ifupdown0.8.35
ii  locales 2.28-10
ii  lsb-base10.2019051400
ii  lsb-release 10.2019051400
ii  net-tools   1.60+git20180626.aebd88e-1
ii  procps  2:3.3.15-2
ii  python3 3.7.3-1
pn  python3-configobj   
ii  python3-jinja2  2.10-2
pn  python3-jsonpatch   
ii  python3-jsonschema  2.6.0-4
pn  python3-oauthlib
ii  python3-requests2.21.0-1
ii  python3-six 1.12.0-1
ii  python3-yaml3.13-2
ii  util-linux  2.33.1-0.1

Versions of packages cloud-init recommends:
ii  eatmydata  105-7
ii  sudo   1.8.27-1

Versions of packages cloud-init suggests:
ii  btrfs-progs  4.20.1-2
ii  e2fsprogs1.44.5-1
ii  xfsprogs 4.20.0-1

Bug#861101: Can't enter disk encryption password

[Sven Bartscher]

Hi Laurent,

Sorry, I completely missed your email.

On Fri, 19 Jan 2018 11:50:05 +0100 Laurent Bigonville 
wrote:
> Could you please retry again with the version 0.9.3-2 that I've just 
> uploaded to unstable?
> 
> I've imported an upstream patch that might have an impact for nvidia 
> cards (fallback to text renderer if something is wrong with the DRM one)
I now have 0.9.4-1 installed and the problem is not present anymore.
Thanks for taking care of this issue!

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Bug#923536: RM: ripole -- RoQA; unmaintained; RC buggy

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear FTP masters,

ripole has been orphaned in 2012 and since then has only seen occasional
QA uploads. Recently #915535 was filed against it, which caused it to
be removed from Buster. While the bug itself could be fixed quite
easily, the fact, that the bug in question, which renders the package
in question completely unusable, has gone unnoticed since the release
of Stretch, shows that there is apparently not a large userbase who
really cares about this package in Debian.

As it stands, I guess it would be best if the package is removed
from Debian.

Regards
Sven

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEE9eLej9CS02N0etaYrrJTIyFwKMIFAlx5WnkWHGtyaXR6ZWZp
dHpAZGViaWFuLm9yZwAKCRCuslMjIXAowizLEACDkmoBQENW3qPCzp8b+kNV3tZI
XVmmC13KH3ztfendjfrr0fRlWNBovu6FV6Eoy7Yw0ucvJo0L6Jv1s1zRxSmF0DqH
jpbFxmIyQz2XIyIkdKPiN5YmFRQu0lRi8k9BafVaQmMRP83cg1w6crOyNumQTxdW
DXsQr+B7iMinYyulOEkA1m4vo4nVWayTomgLEzEumPRm/pSAmUaKl6TBC0H554jk
+koFSGwe+bJwv600DZVdAJZxKfc/By/yO5uAZvjfPTwIkUZKcUD+ayh1tnX5iuYZ
2hQ/Igej4XE67h11+Wbi9gUtAVqKZ6nur9S+fh8HulybTL1HAray3oMD8cXF9IR3
AMk4cwHPKhT9cahAoE9nJw+uoqweR/EfPC+uHW8wu7dJV/KXvHPPjjKsHPC9RBVX
vpx5LHCwxYdQ6l3XDqaO/Et22xsAAbyMiHVCaE4046g9f/QlmZDWLmNBIqr6DJ9j
V47tLPLtRAmNxEJpFKoA36P2w/jeyoK7hFNPAuWujpShU4RD3iztnL3e8Vqcll35
u7ntiHA50qNrZAdqQe31bo+sSrnIfZM84I7v0riGpNaBnkVDvwzmOv/eE+r1wtCh
H8aeukxfGfkTXIq8xe8ViKwizyLObqyBat1sqbUotSsED/2h+YpbT/LkOMy6Y6J3
e7+sCsTtY2MMZktjVQ==
=oadU
-END PGP SIGNATURE-

Bug#907214: OMEMO-encrypted file is not unencrypted before saving

[Sven Bartscher]

Hi lovetox,

On Sun, 26 Aug 2018 22:08:13 +0200 forenjunkie 
wrote:
> Hi,
> 
> I tried with pix-art and could not reproduce the problem.
> 
> Could you please try starting gajim from console with "-v" switch and 
> provide logs from the point on when you receive the message

I attached the log and hope I actually copied all the relevant parts.

P.S. When asking the submitter of a bug a question, you may want to send
your mail to nnn-submitter@bugs.d.o instead of plain nnn@bugs.d.o, that
way the submitter actually gets your message, even if they are not
subscribed to the bug.

Regards
Sven
30.08.2018 10:21:32 (I) nbxmpp.client_nb raising event from transport: :DATA RECEIVED
_
18296920180830_102132980_109c.jpgMwohBS9+Heej+IDPaT77PQi/mH3bM8Gg1ZlsiHpflPLgVyQKEAwYAiIgiskE/LP/iMI8J4mFb9z2mCEQeBkudPuCv09PEO0ELCp7y5WoOGpasg==MwohBebf9IuZu6eVZlkYNytYJ5efTZ/Hxvksu4aLpYyyJUVMEAUYBiIgpABH/5O520MmWpMuaU4A7EDSAkDIGfFQ0oZnmV1F0rwQoXcCReigdw==Wsn7RJX1Qy99lseopBlAwg==
_

30.08.2018 10:21:32 (D) gajim.c.ged stanza-received Args: (,)
30.08.2018 10:21:32 (D) gajim.c.p.bytestream IBBAllIqHandler called syn_id->CSYQH5dP10oT
30.08.2018 10:21:32 (D) gajim.c.ged raw-iq-received Args: (,)
30.08.2018 10:21:32 (I) nbxmpp.transports_nb Plugging fd 26, W:True, R:True
30.08.2018 10:21:32 (I) gajim.c.jingle_ft transport value: 
30.08.2018 10:21:32 (I) gajim.c.jingle_ft FT request: None
30.08.2018 10:21:32 (I) gajim.c.jingle_ft ourjid: s...@jabber.credativ.com/Laptop
30.08.2018 10:21:32 (D) gajim.c.ged jingle-request-received Args: (,)
30.08.2018 10:21:32 (D) gajim.c.jingle_ft Jingle FT request received
30.08.2018 10:21:32 (D) gajim.c.ged file-request-received Args: (,)
30.08.2018 10:21:33 (I) nbxmpp.transports_nb pollout called, state == CONNECTED
30.08.2018 10:21:33 (I) nbxmpp.transports_nb Plugging fd 26, W:False, R:True
30.08.2018 10:21:33 (I) nbxmpp.client_nb raising event from transport: :DATA SENT
_

_

30.08.2018 10:21:33 (D) gajim.c.ged stanza-sent Args: (,)
30.08.2018 10:21:33 (I) gajim.c.idle Idle time: 18
30.08.2018 10:21:35 (I) gajim.c.idle Idle time: 20
Gtk-Message: 10:21:36.337: GtkDialog mapped without a transient parent. This is discouraged.
30.08.2018 10:21:37 (I) gajim.c.idle Idle time: 0
30.08.2018 10:21:39 (I) gajim.c.idle Idle time: 0
30.08.2018 10:21:40 (I) gajim.c.p.bytestream send_file_approval: jingle session accept
30.08.2018 10:21:40 (I) gajim.c.jingle_transport candidate dict, {'host': '2003:5b:203b:100:6e0b:84ff:feb4:9eaf', 'candidate_id': 'b46af08b-2119-4a60-8c15-c357f13e8245', 'port': 28011, 'type': 'direct', 'jid': 's...@jabber.credativ.com/Laptop', 'priority': 8257536}
30.08.2018 10:21:40 (D) gajim.c.ged jingle-connected-received Args: (,)
30.08.2018 10:21:40 (D) gajim.c.socks5 Start listening for socks5 connection
30.08.2018 10:21:40 (I) nbxmpp.transports_nb Plugging fd 26, W:True, R:True
30.08.2018 10:21:40 (I) nbxmpp.transports_nb pollout called, state == CONNECTED
30.08.2018 10:21:40 (I) nbxmpp.transports_nb Plugging fd 26, W:False, R:True
30.08.2018 10:21:40 (I) nbxmpp.client_nb raising event from transport: :DATA SENT
_
20180830_102132980_109c.jpg182969
_

30.08.2018 10:21:40 (D) gajim.c.ged stanza-sent Args: (,)
30.08.2018 10:21:41 (I) nbxmpp.transports_nb pollin called, state == CONNECTED
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout removed for fd 26
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout set for fd 26 on 55 seconds
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout set for fd 26 on 120 seconds with function >
30.08.2018 10:21:41 (I) nbxmpp.client_nb raising event from transport: :DATA RECEIVED
_

_

30.08.2018 10:21:41 (D) gajim.c.ged stanza-received Args: (,)
30.08.2018 10:21:41 (D) gajim.c.p.bytestream IBBAllIqHandler called syn_id->4b554384-3c2d-4eb0-bf2a-b891f8876484
30.08.2018 10:21:41 (D) gajim.c.ged raw-iq-received Args: (,)
30.08.2018 10:21:41 (I) gajim.c.jingle_ft __on_iq_result
30.08.2018 10:21:41 (D) gajim.c.socks5 Trying to connect as receiver to cid arbuq563ff
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout set for fd 32 on 30 seconds
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout removed for fd 32
30.08.2018 10:21:41 (D) gajim.c.socks5 Connected to cid arbuq563ff
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout removed for fd 32
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout set for fd 32 on 30 seconds
30.08.2018 10:21:41 (I) nbxmpp.transports_nb pollin called, state == CONNECTED
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout removed for fd 26
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout set for fd 26 on 55 seconds
30.08.2018 10:21:41 (I) nbxmpp.idlequeue read timeout set for fd 26 on 120 seconds with function >
30.08.2018 10:21:41 (I) nbxmpp.client_nb raising event from transport: :DATA RECEIVED
_

_

30.08.2018 10:21:41 (D) gajim.c.ged stanza-received 

Bug#907214: OMEMO-encrypted file is not unencrypted before saving

[Sven Bartscher]

Package: gajim
Version: 1.0.3-1
Severity: normal

Greetings,

I tried to receive a file transferred to me from a Pix Art
Messenger[1] through an OMEMO encryptecd chat. The file was
transferred successfully, but I wasn't able to open it
afterwards. file(1) reported no recognized file type for the file.

[1]: https://jabber.pix-art.de/

When I tried the transfer again, after switching off OMEMO, I was able
to open the file after the transfer. This looks to me as if Gajim
saves the encrypted file as-is without decrypting it, which makes the
received file practically useless.

Please note that I didn't have this problem when sending files from
Gajim to other messengers.

Regards
Sven

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gajim depends on:
ii  gir1.2-gtk-3.03.22.30-2
ii  python3   3.6.5-3
ii  python3-gi3.28.3-1
ii  python3-gi-cairo  3.28.3-1
ii  python3-idna  2.6-1
ii  python3-nbxmpp0.6.6-1
ii  python3-openssl   18.0.0-1
ii  python3-pyasn10.4.2-3

Versions of packages gajim recommends:
ii  alsa-utils   1.1.6-1
ii  aspell-de [aspell-dictionary]20161207-5
ii  aspell-de-1901 [aspell-dictionary]   1:2-33
ii  aspell-en [aspell-dictionary]2017.08.24-0-0.1
ii  ca-certificates  20170717
ii  dbus 1.12.10-1
ii  fonts-noto-color-emoji   0~20180424-2
ii  gajim-omemo  2.6.0-1
ii  gajim-pgp1.2.7-1
ii  gir1.2-farstream-0.2 0.2.8-4
ii  gir1.2-geoclue-2.0   2.4.12-1
ii  gir1.2-gspell-1  1.6.1-1
ii  gir1.2-gst-plugins-base-1.0  1.14.2-1
ii  gir1.2-gstreamer-1.0 1.14.2-2
ii  gir1.2-gupnpigd-1.0  0.2.5-2
ii  gir1.2-secret-1  0.18.6-1
pn  gstreamer0.10-plugins-ugly   
ii  notification-daemon  3.20.0-3
ii  pulseaudio-utils 11.1-5
ii  python3-crypto   2.6.1-9+b1
ii  python3-dbus 1.2.8-2+b1
ii  python3-gnupg0.4.3-1
ii  python3-keyring  13.1.0-1
ii  python3-pil  5.2.0-2
ii  python3-precis-i18n  1.0.0-1
ii  sox  14.4.2-3
ii  xfce4-notifyd [notification-daemon]  0.4.2-1

Versions of packages gajim suggests:
ii  avahi-daemon  0.7-4
ii  libxss1   1:1.2.2-1+b2
pn  nautilus-sendto   
pn  python3-avahi 
pn  python3-gconf 
pn  python3-gnome2
pn  python3-kerberos  
ii  python3-pycurl7.43.0.1-0.2+b1

-- no debconf information

Bug#905578: Install script from emacs-goodies-el package failed

[Sven Bartscher]

Package: emacs-goodies-el
Version: 40.0
Severity: important

Today I tried to upgrade emacs-goodies-el from 39.0 to 40.0. During
the upgrade I received the following error:

emacs-goodies-el (40.0) wird eingerichtet ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
Install emacs-goodies-el for emacs25
install/emacs-goodies-el: Handling emacs25, logged in /tmp/elc_irZmKc.log
Building autoloads for emacs25 in /usr/share/emacs25/site-lisp/emacs-goodies-el
ERROR: install script from emacs-goodies-el package failed
dpkg: Fehler beim Bearbeiten des Paketes emacs-goodies-el (--configure):
 installed emacs-goodies-el package post-installation script subprocess 
returned error exit status 1
Fehler traten auf beim Bearbeiten von:
 emacs-goodies-el

The contents of /tmp/elc_irZmKc.log are as follows:

emacs25 -batch --no-site-file --multibyte --eval (setq load-path (cons "." 
load-path)) -l autoload --eval (setq generated-autoload-file (expand-file-name 
"emacs-goodies-loaddefs.el")) --eval (setq make-backup-files nil) -f 
batch-update-autoloads .
Warning (initialization): Ignoring obsolete arg --multibyte
align-string.el:0:0: error: file-error: (Opening input file Datei oder 
Verzeichnis nicht gefunden 
/usr/share/emacs25/site-lisp/emacs-goodies-el/align-string.el)

While trying to use some of the functionality provided by the package
(apache-mode, browse-kill-ring) I didn't encounter any missing
features or problems, so the only real problem this seems to cause is
that the package is marked as Failed by dpkg.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs-goodies-el depends on:
ii  bash   4.4.18-3.1
ii  dpkg   1.19.0.5+b1
ii  emacs  47.0
ii  emacs25 [emacsen]  25.2+1-6+b3
ii  emacsen-common 2.0.8
ii  install-info   6.5.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  elpa-apache-mode2.1+4.g97bf66c-2
ii  elpa-bar-cursor 2.0-1
pn  elpa-bm 
ii  elpa-boxquote   2.1-2
ii  elpa-browse-kill-ring   2.0.0-1
ii  elpa-csv-mode   1.7-1
ii  elpa-debian-el  37.5
ii  elpa-devscripts 40.1
ii  elpa-diminish   0.45-2
ii  elpa-dpkg-dev-el37.4
ii  elpa-eproject   1.5+git20180312.068218d-1
ii  elpa-graphviz-dot-mode  0.4+41+gc456a2b-1
ii  elpa-htmlize1.53-1
ii  elpa-initsplit  1.8+3+gc941d43-1
ii  elpa-markdown-mode  2.3+154-1
ii  elpa-pod-mode   1.03-1
ii  elpa-session2.4b-1
ii  elpa-tabbar 2.2-1
ii  perl-doc5.26.2-6
ii  wget1.19.5-1

emacs-goodies-el suggests no packages.

-- no debconf information

Bug#884790: haskell-store tests are no longer built with -N

[Sven Bartscher]

Version: 0.4.3.2-2

Greetings,

The -N flag was actually removed from the build settings of the package
in 0.4.3.2-2. I am thus closing this bug.

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Bug#904879: Can not select predefined time format in clock widget

[Sven Bartscher]

Package: xfce4-panel
Version: 4.12.2-1
Severity: normal

When I create a new clock widget
(/usr/share/xfce4/panel/plugins/clock.desktop apparently) it is
initially set to display the time in the format hh:mm. When I open the
settings dialog of the clock, by right clicking on it an selecting
'Properties', I can change the displayed time format and the format of
the mouse-over text. The changes done in the settings dialog are
reflected on the clock widget until I close the settings dialog. Once
I close the dialog, the widget changes to not display anything at
all. When I open the settings dialog again, the format of both the
time and the mouse-over text have been set to a user defined format
without any format string provided. As a consequence, I cannot change
the settings of a clock widget without permanently breaking the clock
or manually fiddling around with xfconf (to avoid using the broken
settings dialog).

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-panel depends on:
ii  exo-utils0.12.2-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-5
ii  libcairo21.15.10-3
ii  libdbus-1-3  1.12.8-3
ii  libdbus-glib-1-2 0.110-2
ii  libexo-1-0   0.12.2-1
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgarcon-1-00.6.1-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.1-2
ii  libgtk2.0-0  2.24.32-2
ii  libice6  2:1.0.9-2
ii  libpango-1.0-0   1.42.1-2
ii  libpangocairo-1.0-0  1.42.1-2
ii  libpangoft2-1.0-01.42.1-2
ii  libsm6   2:1.2.2-1+b3
ii  libwnck222.30.7-5.1
ii  libx11-6 2:1.6.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfce4ui-1-0   4.12.1-3
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#869167: rbldnsd: on service restart the old process does not exit on time so new process fails to bind to the IP

[Sven Bartscher]

Hi,

Am 24.04.2018 um 16:47 schrieb Marco d'Itri:
> On Apr 24, Sven Bartscher <kritzef...@debian.org> wrote:
> 
>> I currently see no fix for this besides shipping a systemd unit file
>> with RestartSec. This would require some thinking though, because the
> I want to add this anyway, but I believe that there are better solutions.
> 
>> One easy way to solve this problem about accessing the options could be
>> to tell systemd to run the init script of rbldnsd as a forking service
>> and specify RestartSec and PIDFile. This would be a slight improvement
>> over the current situation, but IMO quite ugly.
> No: this would be seriously stupid because it would mask every kind of 
> errors.

The attached patch adds the systemd units rbldnsd.service and
rbldnsd@.service. The latter controls one instance of rbldnsd with the
command line options specified in /etc/rbldnsd/.conf, while
the former controls all instances for which command line options are set.

This approach works quite well for me, but also means that the place to
configure rbldnsd depends on the used init system. I guess this makes it
unfit for inclusion in the package as-is, but it might serve as a
starting point for a proper solution.

Regards
Sven
From 70abede076f42f7b2e08079c02dcc10e95dd7a0e Mon Sep 17 00:00:00 2001
From: Sven Bartscher <sven.bartsc...@credativ.de>
Date: Wed, 25 Apr 2018 13:30:24 +0200
Subject: [PATCH] Add systemd units

The instance unit file creates an instance for each file in
/etc/rbldnsd/*.conf that sets RBLDNSD_ARGS. The non-instance unit
starts and stop all detected instances.
---
 debian/rbldnsd-generator | 27 +++
 debian/rbldnsd.conf  |  7 +++
 debian/rbldnsd.service   | 11 +++
 debian/rbldnsd@.service  | 15 +++
 debian/rules |  5 -
 5 files changed, 64 insertions(+), 1 deletion(-)
 create mode 100644 debian/rbldnsd-generator
 create mode 100644 debian/rbldnsd.conf
 create mode 100644 debian/rbldnsd.service
 create mode 100644 debian/rbldnsd@.service

diff --git a/debian/rbldnsd-generator b/debian/rbldnsd-generator
new file mode 100644
index 000..472cdb8
--- /dev/null
+++ b/debian/rbldnsd-generator
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+# This systemd generator creates dependency symlinks that make all
+# rbldnsd instances for which command line options are set be
+# started/stopped/reloaded when rbldnsd.service is
+# started/stopped/reloaded.
+
+set -eu
+
+gendir="$1"
+wantdir="$1/rbldnsd.service.wants"
+rbldnsdservice="/lib/systemd/system/rbldnsd@.service"
+
+mkdir -p "$wantdir"
+
+for conf in /etc/rbldnsd/*.conf; do
+# If nothing was found the loop still loops over the unexpanded
+# glob. Abort if that is the case.
+if ! [ -e "$conf" ]; then continue; fi
+
+if ! grep -q '^\s*RBLDNSD_ARGS=' "$conf"; then continue; fi
+
+name=$(basename -s '.conf' $conf)
+ln -s "$rbldnsdservice" "$wantdir/rbldnsd@$name.service"
+done
+
+exit 0
diff --git a/debian/rbldnsd.conf b/debian/rbldnsd.conf
new file mode 100644
index 000..0b15a19
--- /dev/null
+++ b/debian/rbldnsd.conf
@@ -0,0 +1,7 @@
+# The variable below specifies command line options that should be
+# passed to rbldnsd. To start multiple instances of rbldnsd you can
+# create additional files in the form /etc/rbldnsd/.conf. For
+# each of these files systemd will generate one rbldnsd@.service
+# unit.
+
+# RBLDNSD_ARGS="-r/var/lib/rbldns/dsbl -b127.2 list.dsbl.org:ip4set:list"
diff --git a/debian/rbldnsd.service b/debian/rbldnsd.service
new file mode 100644
index 000..590324d
--- /dev/null
+++ b/debian/rbldnsd.service
@@ -0,0 +1,11 @@
+[Unit]
+Description=rbldnsd blacklist dns server
+
+[Service]
+Type=oneshot
+ExecStart=/bin/true
+ExecReload=/bin/true
+RemainAfterExit=on
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/rbldnsd@.service b/debian/rbldnsd@.service
new file mode 100644
index 000..f3d3f50
--- /dev/null
+++ b/debian/rbldnsd@.service
@@ -0,0 +1,15 @@
+[Unit]
+Description=rbldnsd blacklist dns server instance %i
+ConditionPathExists=/etc/rbldnsd/%i.conf
+PartOf=rbldnsd.service
+ReloadPropagatedFrom=rbldnsd.service
+Before=rbldnsd.service
+
+[Service]
+ExecStart=/usr/sbin/rbldnsd -n $RBLDNSD_ARGS
+ExecReload=/bin/kill -HUP $MAINPID
+RestartSec=1
+EnvironmentFile=/etc/rbldnsd/%i.conf
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/rules b/debian/rules
index 0c7a724..dc15a90 100755
--- a/debian/rules
+++ b/debian/rules
@@ -32,9 +32,12 @@ binary-arch: build
 	dh_testroot
 	dh_prep
 
-	dh_installdirs /usr/sbin/
+	dh_installdirs /usr/sbin/ /etc/rbldnsd/ /lib/systemd/system-generators/
 	install --mode=755 rbldnsd debian/rbldnsd/usr/sbin/
+	install --mode=644 debian/rbldnsd.conf debian/rbldnsd/etc/rbldnsd/
+	install --mode=755 debian/rbldnsd-generator debian/rbldnsd/lib/systemd/system-generato

Bug#869167: rbldnsd: on service restart the old process does not exit on time so new process fails to bind to the IP

[Sven Bartscher]

Greetings,

I can reproduce this problem. It only seems to happen when restarting
with systemd. While the restart action of the init script waits for one
second between stopping and starting, systemd does not use the restart
action of the init script, but instead issues a stop and start separately.

I currently see no fix for this besides shipping a systemd unit file
with RestartSec. This would require some thinking though, because the
command line options for rbldnsd in /etc/default/rbldnsd are currently
stored in a way that makes them hard to process in systemd and I'm not
sure what would be the “proper” way to make these options available to
systemd.

One easy way to solve this problem about accessing the options could be
to tell systemd to run the init script of rbldnsd as a forking service
and specify RestartSec and PIDFile. This would be a slight improvement
over the current situation, but IMO quite ugly.

Do you have some opinion on this, Marco?

Regards
Sven

On Fri, 21 Jul 2017 10:53:36 +0200 "Lucian A."  wrote:
> Package: rbldnsd
> Version: 0.998b~pre1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> During service restart the old rbldnsd process does not exit on time.
> When the new process is started it fails to bind to the same IP address on 
> port 53.
> 
> 
> -- System Information:
> Debian Release: 9.0
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages rbldnsd depends on:
> ii  adduser   3.115
> ii  libc6 2.24-12
> ii  lsb-base  9.20161125
> ii  zlib1g1:1.2.8.dfsg-5
> 
> rbldnsd recommends no packages.
> 
> rbldnsd suggests no packages.
> 
> -- Configuration Files:
> /etc/default/rbldnsd changed [not included]
> 
> -- no debconf information
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#884371: Hangs on boot without messages

[Sven Bartscher]

Hi Salvatore,

On Thu, 14 Dec 2017 20:42:48 +0100 Salvatore Bonaccorso
<car...@debian.org> wrote:
> Hi Sven!
> 
> On Thu, Dec 14, 2017 at 06:20:14PM +0100, Sven Bartscher wrote:
> > Hi Salvatore,
> > 
> > Am 14.12.2017 um 17:33 schrieb Salvatore Bonaccorso:
> > > Just to confirm, the output is not logged to any console you are
> > > capturing?
> > 
> > That's a good question. There might actually be another console where
> > the output is going. I will definitely check this the next time it's
> > possible.
> > 
> > > Is this the same issue as #883938
> > 
> > Depends on the output I might see on the serial console.
> > 
> > > There are test-kernels available at https://bugs.debian.org/883938#170
> > > which is pending to be scheudled via a jessie-updates upload.
> > 
> > I will try if they work as soon as possible. Unfortunately, we can only
> > schedule the next downtime next month. I will post then (or sooner if an
> > unplanned opportunity arrises).
> 
> Alright, thanks. I will mark it for now as moreinfo, please let us
> know as soon you get a chance to confirm either the duplication of
> #883938 or when more infos with the 3.16.51-3 kernel are avaiable[*].

We tried 3.16.51-3+deb8u1 today and it booted without problems, so I
guess this was actually the same issue as #883938 and the output was
missing for some other reason.

Regards
Sven



signature.asc
Description: OpenPGP digital signature

Bug#884371: Hangs on boot without messages

[Sven Bartscher]

Hi Salvatore,

Am 14.12.2017 um 17:33 schrieb Salvatore Bonaccorso:
> Just to confirm, the output is not logged to any console you are
> capturing?

That's a good question. There might actually be another console where
the output is going. I will definitely check this the next time it's
possible.

> Is this the same issue as #883938

Depends on the output I might see on the serial console.

> There are test-kernels available at https://bugs.debian.org/883938#170
> which is pending to be scheudled via a jessie-updates upload.

I will try if they work as soon as possible. Unfortunately, we can only
schedule the next downtime next month. I will post then (or sooner if an
unplanned opportunity arrises).

Regards
Sven





signature.asc
Description: OpenPGP digital signature

Bug#884371: Hangs on boot without messages

[Sven Bartscher]

Package: src:linux
Version: 3.16.51-2
Severity: important

Due to the nature of this bug, this report was generated with reportbug running
on 3.16.43-2+deb8u5, so the information gathered by reportbug may only be
partially useful.

After upgrading the kernel to 3.16.51-2 it doesn't boot anymore. All I can see
is the messages emitted by GRUB “Loading Linux 3.16.0-4-amd64 ...” and “Loading
initial ramdisk ...”. Nothing seems to happen after that (I waited for about 5
minutes). The kernel does not seem to print any messages, even when booting
without the quiet parameter.

Unfortunetely the machine in question is a production server and I'm not
allowed to restart it at will. This may make debugging in the future quite hard
and is the reason why I didn't include a photo of the frozen screen.

Regards
Sven

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/[Redacted 
hostname]--vg-root ro quiet

** Not tainted

** Kernel log:
 [Redacted log (should be irrelevant anyway)]

** Model information
sys_vendor: FUJITSU
product_name: PRIMERGY RX2540 M2
product_version: GS01
chassis_vendor: FUJITSU
chassis_version: RX2540M2R6
bios_vendor: FUJITSU // American Megatrends Inc.
bios_version: V5.0.0.11 R1.7.0 for D3289-B1x
board_vendor: FUJITSU
board_name: D3289-B1
board_version: S26361-D3289-B13 WGS04 GS02

** Loaded modules:
tun
nfsd
nfsv3
nfs_acl
rpcsec_gss_krb5
auth_rpcgss
oid_registry
nfsv4
dns_resolver
nfs
lockd
sunrpc
fscache
bridge
8021q
garp
stp
mrp
llc
bonding
nls_utf8
nls_cp437
vfat
fat
x86_pkg_temp_thermal
coretemp
kvm_intel
kvm
crc32_pclmul
aesni_intel
aes_x86_64
lrw
gf128mul
glue_helper
ablk_helper
ttm
drm_kms_helper
drm
joydev
mxm_wmi
cryptd
i2c_algo_bit
iTCO_wdt
iTCO_vendor_support
evdev
efi_pstore
efivars
pcspkr
ipmi_si
ipmi_msghandler
processor
lpc_ich
thermal_sys
mfd_core
mei_me
mei
ac
shpchp
tpm_tis
tpm
acpi_power_meter
wmi
button
autofs4
ext4
crc16
mbcache
jbd2
dm_mod
hid_generic
usbhid
hid
sr_mod
cdrom
sg
sd_mod
crc_t10dif
crct10dif_generic
crct10dif_pclmul
crct10dif_common
crc32c_intel
ahci
libahci
ehci_pci
i2c_i801
libata
megaraid_sas
xhci_hcd
ehci_hcd
ixgbe
dca
ptp
be2net
usbcore
i2c_core
usb_common
pps_core
scsi_mod
vxlan
mdio

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Broadwell DMI2 [8086:6f00] (rev 
01)
Subsystem: Fujitsu Technology Solutions Device [1734:1200]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation Broadwell PCI Express Root Port 1 
[8086:6f02] (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 PCI bridge [0604]: Intel Corporation Broadwell PCI Express Root Port 2 
[8086:6f04] (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:03.0 PCI bridge [0604]: Intel Corporation Broadwell PCI Express Root Port 3 
[8086:6f08] (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:03.2 PCI bridge [0604]: Intel Corporation Broadwell PCI Express Root Port 3 
[8086:6f0a] (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:05.0 System peripheral [0880]: Intel Corporation Broadwell Adress 
Map/VTd_Misc/System Management [8086:6f28] (rev 01)
Subsystem: Fujitsu Technology Solutions Device [1734:1200]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- 

Bug#883077: Description of %P formatting token in find's manpage is wrong

[Sven Bartscher]

Package: manpages-de
Version: 2.2-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Greetings,

In the manpage of find in the description of -printf is following
paragraph describing the %P formatting directive:

„Der Name der Datei mit dem Namen des  Startpunkts,  unter dem sie
gefunden wurde, wurde entfernt.“

This doesn't correctly mirror what the original manpage says (and the
option actually does). The way it is currently written „wurde
entfernt" (“was removed”) actually applies to „Der Name der Datei“
(“The name of the file”) while it should actually apply to „Namen des
Startpunkts“ (“name of the starting point”).

Writing it like this would probably be easier to understand:

„Der Name der Datei ohne den Namen des Startpunkts unter dem sie
gefunden wurde.“
(“The name of the file without the name of the starting-point under
which it was found”)

Regards
Sven

- -- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

manpages-de depends on no packages.

manpages-de recommends no packages.

Versions of packages manpages-de suggests:
ii  man-db [man-browser]  2.7.6.1-4
ii  manpages  4.13-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEE9eLej9CS02N0etaYrrJTIyFwKMIFAloelb4WHGtyaXR6ZWZp
dHpAZGViaWFuLm9yZwAKCRCuslMjIXAowp6VD/oDgXLLgMGWqmNf4jcOnYpxr6o0
zmI0hFUR/Mf61REiq4G+nXwTbRvSynCbiaGpKq2r8uB5dtFkl39O+A4FzHaA3y9+
hmn/6erYMmIRpDDLt2rb1L7DUl8EPQqJ0hvm5VgAB3EVCQsEwS4r+Qd1P4cuUKmI
7CtNajAttl5n05tMga6bA8Y7aakR7sWHC+F2JegBUAEXfY7m7Wezpql8Cn1BDdqd
FVYZ5G7sc+YhLxTHPcnEIkxpkuFV3hsjT6Kc5P3TRXzfT4Cb+M2uOr3TjMSdRkZn
IKXUnsZ69jEwmPfUdLjrkyGG2ncSsaAai86WuyC8IZYVy52eE6/7faIjYi4p14B6
aLpT28y/PnxICPyfxKQHquc4h1dQ4zexzc2jkSIomew00ZVi/r7lcQeZtCMCz6uD
SwpHHJYxNA7AEIj9IfNux4UVL/uiMyqAbDWz5LU93Mn4cj0ujxWFPhgpwATvS8Hj
wWPDn934JcJth0OHxZu7QYBmugbUIzsTmxHDebFBVRP1JqkwefCCAFPvIGtqqxe8
DNeu+kpAUTrbw9YelEm9Lnx2tGJ5UuhsV+qgnonDUt1kpXBkoxvkBqjbynAdSI9I
tnx+SUEZWkisfwarutqMAOOGGG1m2wUpmgYmKLg/19UfiRQBuvF0VGrstlTyWwJu
HNUHug69ClkrIl52VQ==
=R+iN
-END PGP SIGNATURE-

Bug#588377: Fresh attempt on packaging dwarf-fortress

[Sven Bartscher]

Greetings,

Control: retitle -1 ITP: dwarf-fortress -- Slaves to Armok: God of Blood 
Chapter II: Dwarf Fortress

After this has been lying around for quite some time, I am planning on
making an attempt at packaging Dwarf Fortress. Status updates will
hopefully follow soon.

Regards
Sven


pgp38devtS_Q5.pgp
Description: Digitale Signatur von OpenPGP

Bug#880907: Automatically accept certificate signed by specific CA

[Sven Bartscher]

Package: claws-mail
Version: 3.15.1-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As discussed in #608344 claws-mail has an account option to
automatically accept certificates signed by CAs in
/etc/ssl/certs/ca-certificates.crt.

For some accounts I would like to configure a specific CA certificate
(or a set of certificates) by which the server certificate has to be
signed to be automatically accepted. This is useful for cases in which
the CA in question is not in the globally trusted CAs or you want to
narrow down what CAs are valid for that specific account.

Currently claws-mail does not seem to have such an option, but it
would be great if it would be added in a future version.

Regards
Sven

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

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

Versions of packages claws-mail depends on:
ii  libatk1.0-0  2.26.0-2
ii  libc62.24-17
ii  libcairo21.15.8-2
ii  libcompfaceg11:1.5.2-5+b2
ii  libcurl3-gnutls  7.56.1-1
ii  libdb5.3 5.3.28-13.1
ii  libenchant1c2a   1.6.0-11.1
ii  libetpan20   1.8.0-1
ii  libexpat12.2.3-1
ii  libfontconfig1   2.12.3-0.2
ii  libfreetype6 2.8.1-0.1
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.1-1
ii  libgnutls30  3.5.16-1
ii  libgtk2.0-0  2.24.31-2
ii  libice6  2:1.0.9-2
ii  libldap-2.4-22.4.45+dfsg-1
ii  liblockfile1 1.14-1+b1
ii  libpango-1.0-0   1.40.12-1
ii  libpangocairo-1.0-0  1.40.12-1
ii  libpangoft2-1.0-01.40.12-1
ii  libpisock9   0.12.5-dfsg-2+b3
ii  librsvg2-2   2.40.18-2
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3
ii  libsm6   2:1.2.2-1+b3
ii  xdg-utils1.1.2-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages claws-mail recommends:
ii  aspell-de [aspell-dictionary]   20161207-1
ii  aspell-de-1901 [aspell-dictionary]  1:2-31
ii  aspell-en [aspell-dictionary]   2017.08.24-0-0.1
ii  claws-mail-i18n 3.15.1-1
ii  xfonts-100dpi   1:1.0.4+nmu1
ii  xfonts-75dpi1:1.0.4+nmu1

Versions of packages claws-mail suggests:
ii  chromium [www-browser]  61.0.3163.100-2
pn  claws-mail-doc  
pn  claws-mail-tools
ii  firefox [www-browser]   56.0-2
ii  lynx [www-browser]  2.8.9dev16-1
ii  mousepad0.4.0-4

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEE9eLej9CS02N0etaYrrJTIyFwKMIFAln/I9sWHGtyaXR6ZWZp
dHpAZGViaWFuLm9yZwAKCRCuslMjIXAowv/tEACcljTgyFBCrXvYkyJQ0G6oEhEb
cwBDHj8iCPdGnetdDm4tBvlTThfPE57Vzdur88m9UygWyoZB0HuXqWdrJgaDv/a3
B/bgonLO3jJW5f7MN7lL9sAGF/FtLAswPHLG/cN/501kPRtf2wxPBNGRgFPp38K7
agAKw4AQorpk+J27jzrjiJ78uBtJFIwb1fHDvf+pQkPsBZD2l/TAZRzamch6ZBSk
md5XZU7z7Ga+Anwv6nYDvPTkVh7X50z7OnYUQIevWWY7qsDvtaE+hne5niEXKkkY
XzbhkqK+tGHHDEKmQ8OQIVFxgvNsuXMvvhpQRupYgRyOwiKVvwk1DgrKkm+JQxPr
ueufyxQZ1zWsMfvncDktCnZk+jrk9ajXvFTLimtFaPy8q4O3TNlikho/zMyC6HUp
9/i7YE2Z2T3M2kdBI1iNL1HGiHaD5g1ON8hPq2hWUwPHhOAQzs1XPHorxpMosR3e
fMAisdFiKjnnEteUR3GAzAM94GJDBbA6klDQHQ41QEvy7xwt3JSuX0e0nzYmj6tI
Hv8Li/t9z20ttEIJBwUm038t3RaGpeLX4ktNSj/rYDnbjMZvASFMupLR/PNTs2yb
qu56ZInI19VXjUkLr6p2cKX315Odi+75jHUDDxvCvnhFMYoIUhCEGmnAIVSJl+zg
Y2DUDJFFtdGuL2Ekdg==
=O9e1
-END PGP SIGNATURE-

Bug#877060: find's manpage claims that .. is a link to the directory it is in

[Sven Bartscher]

Package: manpages-de
Version: 2.0-1
Severity: minor

In find's manpage in the section of the "-noleaf" option there is a
sentence that says

"Jedes Verzeichnis [...] hat zwei harte Links: seinen Namen und seinen
»..«-Eintrag."

"»..«-Eintrag" is incorrect and should be "».«-Eintrag".

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

manpages-de depends on no packages.

manpages-de recommends no packages.

Versions of packages manpages-de suggests:
ii  man-db [man-browser]  2.7.6.1-2
ii  manpages  4.13-3

-- no debconf information

Bug#861101: Can't enter disk encryption password

[Sven Bartscher]

Hello Laurent,

On Thu, 24 Aug 2017 16:47:07 +0200
Laurent Bigonville <bi...@debian.org> wrote:

> [snip]
> 
> On Mon, 24 Apr 2017 18:49:07 +0200 Sven Bartscher 
> <sven.bartsc...@weltraumschlangen.de> wrote:
> 
> [snip]
> 
> Are you still able to reproduce this?

Yes. The situation doesn't seem to be different from when I first
reported this bug.

> Are you using closed source drivers for your graphic card?

Yes, I am using the nvidia-driver package from Debian non-free.
Removing it (and related packages, apt remove '*nvidia*') didn't help
though.

Regards
Sven


pgpq6CeFsfGWx.pgp
Description: Digitale Signatur von OpenPGP

Bug#871177: search domains declared in /etc/resolv.conf not taken over by dnssec-trigger

[Sven Bartscher]

Package: dnssec-trigger
Version: 0.13-6
Severity: normal

Greetings,

When dnssec-trigger overwrites /etc/resolv.conf it doesn't seem to
take over search domaions declared there. I would expect it to
integrate non-nameserver options declared there into its own generated
configuration file. Otherwise I don't see a way to effectively set
these options while dnssec-trigger is active.

This also affects search-domains received via DHCP.

Regards
Sven

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnssec-trigger depends on:
ii  gir1.2-networkmanager-1.0  1.8.2-1
ii  init-system-helpers1.49
ii  libc6  2.24-12
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.52.3-1
ii  libgtk2.0-02.24.31-2
ii  libldns2   1.7.0-3
ii  libssl1.1  1.1.0f-3
ii  python 2.7.13-2
ii  python-gi  3.22.0-2+b1
ii  python-lockfile1:0.12.2-2
ii  unbound1.6.4-1

dnssec-trigger recommends no packages.

dnssec-trigger suggests no packages.

-- no debconf information

Bug#869792: Can only save either none or all passwords

[Sven Bartscher]

Package: network-manager-openconnect-gnome
Version: 1.2.4-1
Severity: wishlist

When connecting to a VPN with juniper I get asked for a username and
password and get the option to "Save passwords". The particular VPN
I'm connecting to requires me to first enter a username and a password
and afterwards asks me for a one-time password.

While it makes sense for me to save the first username and password,
saving the one-time password doesn't make sense. Unfortunately the
"Save passwords" option seems to affect all entered passwords at once,
so I can either save all entered passwords or none of them.

I can work around this by just saving the one-time password. NM then
tries to connect using the saved passwords, notices that the one-time
password got rejected and asks me for it again. This works, but has
the unfortunate side effect of making an unsuccessful authentication
attempt on every connect, which causes me to get locked out of the VPN
temporarily if I connect too often in a short amount of time.

It would be really great if it were possible to choose whether to save
or not save for each password individually.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager-openconnect-gnome depends on:
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo-gobject21.14.10-1
ii  libcairo21.14.10-1
ii  libdbus-1-3  1.10.20-1
ii  libdbus-glib-1-2 0.108-2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.52.3-1
ii  libgtk-3-0   3.22.16-1
ii  libnm-glib-vpn1  1.8.2-1
ii  libnm-glib4  1.8.2-1
ii  libnm-util2  1.8.2-1
ii  libnm0   1.8.2-1
ii  libopenconnect5  7.08-1
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libsecret-1-00.18.5-3.1
ii  libxml2  2.9.4+dfsg1-3
ii  network-manager-openconnect  1.2.4-1

network-manager-openconnect-gnome recommends no packages.

network-manager-openconnect-gnome suggests no packages.

-- no debconf information

Bug#861101: Can't enter disk encryption password

[Sven Bartscher]

Package: plymouth
Version: 0.9.2-4
Severity: normal

I have a system with an encrypted root partition.
When I try to boot it with splash enabled, I get prompted for the
password in graphical mode. When I try to enter the password, it isn't
entered into the password entry. Instead it is written to the upper
left corner of the screen. Pressing enter just moves outputs a newline
instead of accepting the input.

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

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

Versions of packages plymouth depends on:
ii  init-system-helpers  1.47
ii  initramfs-tools  0.128
ii  libc62.24-9
ii  libdrm2  2.4.74-1
ii  libplymouth4 0.9.2-4
ii  lsb-base 9.20161125
ii  systemd  232-22
ii  udev 232-22

plymouth recommends no packages.

Versions of packages plymouth suggests:
ii  desktop-base 9.0.2
ii  plymouth-themes  0.9.2-4

-- Configuration Files:
/etc/plymouth/plymouthd.conf changed:
[Daemon]
Theme=spinfinity


-- no debconf information

Bug#856586: mkfs.ext4 asks whether to proceed with (y,N) as options but accepts j in german locale

[Sven Bartscher]

Package: e2fsprogs
Version: 1.43.4-2
Severity: minor
Tags: l10n

I was trying to overwrite an existing ext4 filesystem with a fresh
one using mkfs.ext4. As expected I was asked to confirm with this
localized message:

mke2fs 1.43.4 (31-Jan-2017)
/dev/sdc1 hat ein ext4-Dateisystem
Proceed anyway? (y,N)

So I pressed 'y', which caused mkfs.ext4 to abort as if I had pressed
'N'. Retrying and pressing 'j' ("yes" translates to "ja" in german)
instead works.

This is very counterintuitive and should be fixed to either show
(j, N) as options or actually accept 'y' as an option.

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

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

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.43.4-2
ii  libblkid1   2.29.1-1
ii  libc6   2.24-9
ii  libcomerr2  1.43.4-2
ii  libss2  1.43.4-2
ii  libuuid12.29.1-1
ii  util-linux  2.29.1-1

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.2-17

-- no debconf information

Bug#854785: "Fahrschule" missing in /usr/share/dict/ngerman

[Sven Bartscher]

Package: wngerman
Version: 20161207-1
Severity: minor

The word "Fahrschule"[1] is missing in the dictionary
/usr/share/dict/ngerman, whereas its plural form "Fahrschulen" does
exist.

Regards
Sven

[1]: http://www.duden.de/rechtschreibung/Fahrschule

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

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

Versions of packages wngerman depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  dictionaries-common1.27.2
pn  perl:any   

wngerman recommends no packages.

wngerman suggests no packages.

-- debconf information:
  shared/packages-wordlist:
  wngerman/languages: deutsch (New German)

Bug#850043: ghc-mod-el: Fail to install if Emacs 21/22 present.

[Sven Bartscher]

On Tue, 03 Jan 2017 16:23:30 +0200
Oleksandr Gavenko  wrote:

> Package: ghc-mod-el
> Version: 5.6.0.0-2
> Severity: normal
> 
>   $ cat /var/log/apt/term.log
>   ...
>   Install ghc-mod-el for emacs21
>   install/ghc-mod: Handling install for emacsen flavor emacs21
>   ...
>   ERROR: install script from ghc-mod-el package failed

This is probably the same problem as in #752594. Back then Joachim
suggested writing an autopkgtest, which would make sense as future
changes in ghc-mod and emacs might cause similar problems.

Unfortunately I'm not sure how to make a test that covers such
problems, as it would require having every emacs version in the archive
installed in the test system and I'm not sure how to achieve that. Any
ideas?

Regards
Sven


pgpNW2tcVvQM9.pgp
Description: Digitale Signatur von OpenPGP

Bug#846375: Wrong description of --previous in manpage

[Sven Bartscher]

Package: quodlibet
Version: 3.7.0-1
Severity: minor

The manpage says the following about the option '--previous':

   --previous
  Jump to previous song or restart if near the beginning

I think the condition is the wrong way around and should be something like:

Jump to previous song if near the beginning, otherwise restart

Regards
Sven

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

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

Versions of packages quodlibet depends on:
ii  exfalso 3.7.0-1
ii  gir1.2-gst-plugins-base-1.0 1.10.1-1
ii  gir1.2-gstreamer-1.01.10.1-1
ii  gstreamer1.0-plugins-base   1.10.1-1
ii  gstreamer1.0-plugins-good [gstreamer1.0-audiosink]  1.10.1-2
ii  gstreamer1.0-plugins-ugly   1.10.1-1
ii  gstreamer1.0-pulseaudio [gstreamer1.0-audiosink]1.10.1-2
ii  python  2.7.11-2
pn  python:any  

Versions of packages quodlibet recommends:
ii  gir1.2-gtksource-3.0 3.22.1-1
ii  gir1.2-keybinder-3.0 0.3.1-1
ii  gir1.2-soup-2.4  2.56.0-1
ii  libgpod4 0.8.3-8
ii  media-player-info22-3
ii  notification-daemon  3.20.0-1
ii  python-dbus  1.2.4-1
ii  python-feedparser5.1.3-3
ii  python-pyinotify 0.9.6-1
ii  udisks2  2.1.7-3
ii  xfce4-notifyd [notification-daemon]  0.3.4-1

Versions of packages quodlibet suggests:
pn  gstreamer1.0-plugins-bad  

-- no debconf information

Bug#839840: ghci segfaults on armel, related to doctest failure

[Sven Bartscher]

On Wed, 5 Oct 2016 17:12:45 +
Clint Adams  wrote:

> Source: ghc
> Version: 7.10.3-9
> Severity: serious
> 
> clint@abel ~/haskell-http-api-data-0.2.4
>  % ghci -isrc -XCPP -D"MIN_VERSION_base(X,Y,Z)=1"
> GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
> Prelude> :l src/Web/HttpApiData.hs  
> [1 of 2] Compiling Web.HttpApiData.Internal ( 
> src/Web/HttpApiData/Internal.hs, interpreted )
> [2 of 2] Compiling Web.HttpApiData  ( src/Web/HttpApiData.hs, interpreted )
> Ok, modules loaded: Web.HttpApiData, Web.HttpApiData.Internal.
> *Web.HttpApiData> :set -XOverloadedStrings
> *Web.HttpApiData> import Control.Applicative  
> *Web.HttpApiData Control.Applicative> import Data.Time
> *Web.HttpApiData Control.Applicative Data.Time> import Data.Int
> *Web.HttpApiData Control.Applicative Data.Time Data.Int> import Data.Text 
> (Text)
> *Web.HttpApiData Control.Applicative Data.Time Data.Int Data.Text> import 
> Data.Time (Day)
> *Web.HttpApiData Control.Applicative Data.Time Data.Int Data.Text Data.Time> 
> import Data.Version
> *Web.HttpApiData Control.Applicative Data.Time Data.Int Data.Text Data.Time 
> Data.Version> toUrlPiece True
> "true"
> *Web.HttpApiData Control.Applicative Data.Time Data.Int Data.Text Data.Time 
> Data.Version> parseUrlPiece "false" :: Either Text Bool
> zsh: segmentation fault  ghci -isrc -XCPP -D"MIN_VERSION_base(X,Y,Z)=1"
> 
> The backtrace is useless.

This bug I reported upstream[1] might be related to that.

Regards
Sven

[1]: https://ghc.haskell.org/trac/ghc/ticket/11831


pgpePliU29iyT.pgp
Description: Digitale Signatur von OpenPGP

Bug#833536: pkg-haskell-tools: dht should allow uploading by FTP

[Sven Bartscher]

On Mon, 8 Aug 2016 22:23:36 +
Sean Whitton  wrote:

> On Fri, Aug 05, 2016 at 07:19:47PM -0400, Joachim Breitner wrote:
> > With "someone" I meant me, not you: "dht upload" should just call dput,
> > and I should be able to tell dput to use ssh-upload by default.  
> 
> Oh, I see.
> 
> I'm inclined to agree with Sven that dht should default to SSH because
> DDs often use it to make huge numbers of uploads, and it would be a pain
> to sort it out if some of them failed.

I can't remember saying dht should default to SSH and rather think that
dht should honour the default set in dput.cf (see my other post for a
brief description of how to do that).

Regards
Sven


pgplN5uOuxeKo.pgp
Description: Digitale Signatur von OpenPGP

Bug#833536: pkg-haskell-tools: dht should allow uploading by FTP

[Sven Bartscher]

On Fri, 05 Aug 2016 19:19:47 -0400
Joachim Breitner  wrote:

> Hi,
> 
> Am Freitag, den 05.08.2016, 15:47 -0700 schrieb Sean Whitton:
> > Hello,
> > 
> > On Fri, Aug 05, 2016 at 03:04:06PM -0400, Joachim Breitner wrote:  
> > > 
> > > the reason is that I have had many FTP uploads fail and partial files
> > > blocking further uploaing, which is a PITA. With ssh, partial uploads
> > > do not happen (I think).
> > > 
> > > Anyways, "dht upload" should simply allow passing a parameter to dput
> > > as HOST. Any maybe anyone who wants a non-default HOST should figure
> > > out how to change dput’s defaults…  
> > 
> > It seems wrong that I should define ssh-upload to actually upload to FTP
> > in my ~/.dput.cf.  Anyway, yes, passing a parameter to override the
> > default seems like the right solution.  
> 
> With "someone" I meant me, not you: "dht upload" should just call dput,
> and I should be able to tell dput to use ssh-upload by default.

You can set the default host by settings default_host_main in the
[DEFAULT] section to ssh-upload in you dput.cf.

Regards
Sven


pgpYuPwXGASs4.pgp
Description: Digitale Signatur von OpenPGP

Bug#830477: RM: haskell-glut [armel armhf] -- ROM; Build-Dependency haskell-openglraw has been removed

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal

Since haskell-openglraw has been removed from armel and armhf as
requested by #829463, haskell-glut is uninstallable and unbuildable
on these architectures.
Please remove haskell-glut from armel and armhf.

Regards
Sven

Bug#830323: RM: haskell-opengl [armel armhf] -- ROM; Transitive Build-Dependency haskell-openglraw has been removed

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal

Since haskell-openglraw has been removed from armel and armhf as
requested by #829463, haskell-opengl is uninstallable and unbuildable
on these architectures.
Please remove haskell-opengl from armel and armhf.

Regards
Sven

Bug#830314: RM: haskell-gluraw [armel armhf] -- ROM; Build-Dependency haskell-openglraw has been removed

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal

Since haskell-openglraw has been removed from armel and armhf as
requested by #829463, haskell-gluraw is uninstallable and unbuildable
on these architectures.
Please remove haskell-gluraw from armel and armhf.

Regards
Sven

Bug#822472: various haskell -dev packages are missing Built-Using attributes

[Sven Bartscher]

Am Mon, 4 Jul 2016 18:17:37 +0200
schrieb Matthias Klose <d...@debian.org>:

> On 04.07.2016 15:01, Sven Bartscher wrote:
> > On Sun, 24 Apr 2016 22:13:47 +0200 Matthias Klose <d...@debian.org>
> > wrote:
> >> [snip]
> >>
> >> [I was doing a transition (icu 55 to 57), and investigating some
> >> build failures with link failures, some missing icu55 symbols. I
> >> didn't find the appropriate haskell package immediately, because it
> >> neither has a dependency on the icu runtime library or a
> >> Built-Using attribute ]
> >>
> >> Seen with haskell-text-icu, but it looks like there are no
> >> Built-Using attributes for any C library used for many packages.
> >> Therefore filing this isssue on a package which is maintained by
> >> the debian haskell maintainers. Feel free to clone, reassign, ...  
> > 
> > I'm afraid I don't understand what the problem is.
> > I don't see why our packages would need Build-Using fields on any C
> > libraries, because AFAIK all our packages that use C libraries are
> > dynamically linked against them and have the appropriate Depends on
> > them.  
> 
> I don't think so. For your library -dev packages you don't have any
> such dependencies.

Could you name an example? You mentioned libghc-text-icu-dev earlier,
but it has dependencies on libc6, libicu55 and libicu-dev. I don't see
anything missing here.

> > Are you at DebConf? If so, maybe we could meet and you explain the
> > problem to me.  
> 
> yes.

You don't seem to be online on IRC, so finding you isn't trivial.

Regards
Sven


pgpwPGjRzSUO6.pgp
Description: Digitale Signatur von OpenPGP

Bug#822472: various haskell -dev packages are missing Built-Using attributes

[Sven Bartscher]

On Sun, 24 Apr 2016 22:13:47 +0200 Matthias Klose 
wrote:
> Package: haskell-devscripts
> Version: 0.10.2.3
> Severity: serious
> Tags: sid stretch
> 
> [I was doing a transition (icu 55 to 57), and investigating some
> build failures with link failures, some missing icu55 symbols. I
> didn't find the appropriate haskell package immediately, because it
> neither has a dependency on the icu runtime library or a Built-Using
> attribute ]
> 
> Seen with haskell-text-icu, but it looks like there are no
> Built-Using attributes for any C library used for many packages.
> Therefore filing this isssue on a package which is maintained by the
> debian haskell maintainers. Feel free to clone, reassign, ...

I'm afraid I don't understand what the problem is.
I don't see why our packages would need Build-Using fields on any C
libraries, because AFAIK all our packages that use C libraries are
dynamically linked against them and have the appropriate Depends on
them.

Are you at DebConf? If so, maybe we could meet and you explain the
problem to me.

Regards
Sven


pgpJcD_QFNLmQ.pgp
Description: Digitale Signatur von OpenPGP

Bug#829358: gpg is used to import keys but gpg2 should be used

[Sven Bartscher]

Package: claws-mail-pgpmime
Version: 3.13.2-1
Severity: normal

When I try to fetch a key from the keyserver using claws-mail it always fails
with the following message:

 Schlüssel-ID importieren4B043FCDB9444540:

   Dieser Schlüssel konnte nicht in Ihren Schlüsselring importiert werden.
   Schlüsselserver sind manchmal sehr langsam.
   Sie können versuchen, ihn mit folgendem Befehl manuell zu importieren:

   gpg --no-tty --recv-keys 4B043FCDB9444540

I suspect that this is because I haven't configured any keyservers for gpg but
only for gpg2.
To solve this I set the option "Path to GnuPG executable" (under Plugins ->
GPG) to /usr/bin/gpg2 but the problem remains, so I think claws-mail still
tries to import the key using gpg instead of gpg2.

Copying the given command and appending a 2 to the gpg works just fine.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages claws-mail-pgpmime depends on:
ii  claws-mail   3.13.2-1
ii  libassuan0   2.4.2-3
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-13
ii  libcairo21.14.6-1+b1
ii  libdb5.3 5.3.28-11
ii  libenchant1c2a   1.6.0-11+b1
ii  libetpan17   1.6-1+b1
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgnutls30  3.4.13-1
ii  libgpg-error01.23-1
ii  libgpgme11   1.6.0-3
ii  libgtk2.0-0  2.24.30-2
ii  liblockfile1 1.09-6
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpangoft2-1.0-01.40.1-1
ii  libsasl2-2   2.1.26.dfsg1-15
ii  pinentry-gtk20.9.7-5
ii  zlib1g   1:1.2.8.dfsg-2+b1

claws-mail-pgpmime recommends no packages.

Versions of packages claws-mail-pgpmime suggests:
ii  gnupg-agent  2.1.11-7

-- no debconf information

Bug#827311: parcimonie can't find the keyserver for gpg2

[Sven Bartscher]

On Wed, 15 Jun 2016 18:15:16 -0400
Daniel Kahn Gillmor  wrote:

> what version of gnupg2 do you have installed? 

2.1.11-7

> what does:
> 
>  grep ^keyserver ~/.gnupg/dirmngr.conf
> 
> show you?

~/.gnupg/dirmngr.conf doesn't exist for my user. The keyserver is
configured in ~/.gnupg/gpg.conf. Doing the grep over that file gives
this:

$ grep ^keyserver ~/.gnupg/gpg.conf
keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options no-honor-keyserver-url
keyserver-options include-revoked
keyserver-options
ca-cert-file=/etc/gnupg/trusted-certs/sks-keyservers.netCA.pem

(I know the last option is deprecated for gnupg2, but it's there for
gpg1 compatibility)

Do I really need to configure the keyserver in the dirmngr.conf? If so,
that would be a bit inconvenient, as gpg2 itself is fine with having
the keyserver configured in gpg.conf.

Regards
Sven


pgp1B9avKTI5j.pgp
Description: Digitale Signatur von OpenPGP

Bug#827311: parcimonie can't find the keyserver for gpg2

[Sven Bartscher]

Package: parcimonie
Version: 0.10.1-1
Severity: normal

When I run parcimonie --gnupg2 it always exits with the following
message:

No keyserver is configured. at \
/usr/share/perl5/App/Parcimonie/Daemon.pm line 151.

I actually do have a keyserver configured and gpg2 utilizes it just
fine. Running parcimonie without --gnupg2 works just fine, so I don't
think this is a problem with my configuration.

I looked at the code pointed to by the error message and found that
the following command should return the keyserver:

gpg-connect-agent --dirmngr keyserver /bye

However, it always just prints "OK" and exits without giving the
address of the keyserver.

Regards
Sven

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages parcimonie depends on:
ii  libclone-perl0.38-1+b1
ii  libconfig-general-perl   2.61-1
ii  libfile-homedir-perl 1.00-1
ii  libfile-which-perl   1.21-1
ii  libgnupg-interface-perl  0.52-2
ii  libipc-system-simple-perl1.25-3
ii  liblist-moreutils-perl   0.413-1+b1
ii  libmoo-perl  2.001001-1
ii  libmoox-late-perl0.015-2
ii  libmoox-options-perl 4.022-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.094-1
ii  libtime-duration-parse-perl  0.13-1
ii  libtry-tiny-perl 0.24-1
ii  libtype-tiny-perl1.05-1
ii  libtypes-path-tiny-perl  0.005-1
ii  perl 5.22.2-1
ii  torsocks 2.1.0-2

Versions of packages parcimonie recommends:
ii  gnupg-curl  1.4.20-6
ii  libglib-perl3:1.320-2
ii  libgtk3-perl0.026-1
ii  liblocale-gettext-perl  1.07-2
ii  libnet-dbus-glib-perl   0.33.0-1+b5
ii  libnet-dbus-perl1.1.0-3+b1
ii  libpango-perl   1.227-1
ii  libtime-duration-perl   1.20-1
ii  tor 0.2.7.6-1

parcimonie suggests no packages.

-- no debconf information

Bug#813611: Passwords are stored as MD5

[Sven Bartscher]

Package: simpleid
Version: 0.8.1-14
Severity: grave
Tags: security

The identity files (in /var/lib/simpleid/identities) expect user
passwords to be given as MD5 hashes of the actual passwords, but MD5
is generally considered broken and should probably not be used to
store user passwords.

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

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

Bug#810105: Bug#809763: cabal-helper: no binary in cabal-helper package

[Sven Bartscher]

On Sun, 10 Jan 2016 20:37:13 +0100 Tomas Janousek <t...@nomi.cz> wrote:
> Hi,
> 
> On Fri, Jan 08, 2016 at 03:19:49PM +0100, Sven Bartscher wrote:
> > > It would be good if you open another report for ghc-mod, so it won't
> > > migrate before its libexecdir is set to /usr/lib.
> 
> Oh, I'm reading this only now, I forgot to scroll down the original e-mail,
> sorry. :-(

No problem. I noticed that it would be easier to clone the bug and did
that instead.

> > Searching through the code revealed, that the code for finding the
> > executable is actually in haskell-cabal-helper. *reassign*
> 
> If it's in libghc-cabal-helper-dev, then a rebuild of ghc-mod is necessary.
> And I assume that's the case since newest cabal-helper with newest ghc-mod
> gives the same error.

ghc-mod has been rebuilt and for me the problem is gone. Are you sure
you upgraded to ghc-mod 5.4.0.0-1+b1 (Note the +b1 addition)?

Regards
Sven


pgp31i5peK8i8.pgp
Description: Digitale Signatur von OpenPGP

Bug#810105: Bug#809763: cabal-helper: no binary in cabal-helper package

[Sven Bartscher]

Control: reassign -1 haskell-cabal-helper

On Mon, 4 Jan 2016 16:29:22 +0100 Sven Bartscher
<sven.bartsc...@weltraumschlangen.de> wrote:
> On Sun, 3 Jan 2016 20:52:52 +0100
> Tomas Janousek <t...@nomi.cz> wrote:
> > Also, ghc-mod seems to expect cabal-helper in /usr/libexec:
> > 
> > > $ ghc-mod list
> > > ghc-mod: Could not find $libexecdir/cabal-helper-wrapper
> > > 
> > > If you are a developer set the environment variable
> > > `cabal_helper_libexecdir' to override $libexecdir[1]. The following will
> > > work in the cabal-helper source tree:
> > > 
> > > $ export cabal_helper_libexecdir=$PWD/dist/build/cabal-helper-wrapper
> > > 
> > > [1]: /usr/libexec
> > > 
> > > If you don't know what I'm talking about something went wrong with your
> > > installation. Please report this problem here:
> > > 
> > > https://github.com/DanielG/cabal-helper/issues  
> > 
> > Shall I open another bug or can you check that as well?
> 
> It would be good if you open another report for ghc-mod, so it won't
> migrate before its libexecdir is set to /usr/lib.

Searching through the code revealed, that the code for finding the
executable is actually in haskell-cabal-helper. *reassign*

Regards
Sven


pgpqHcOeRNK8U.pgp
Description: Digitale Signatur von OpenPGP

Bug#809763: cabal-helper: no binary in cabal-helper package

[Sven Bartscher]

Control: tag -1 + pending

On Sun, 3 Jan 2016 20:52:52 +0100
Tomas Janousek  wrote:

> Package: cabal-helper
> Version: 0.6.2.0-1
> Severity: grave
> Justification: renders package unusable
> 
> There's no cabal-helper binary in the package:
> 
> > $ dpkg -L cabal-helper
> > /.
> > /usr
> > /usr/share
> > /usr/share/doc
> > /usr/share/doc/cabal-helper
> > /usr/share/doc/cabal-helper/changelog.Debian.gz
> > /usr/share/doc/cabal-helper/buildinfo_i386.gz
> > /usr/share/doc/cabal-helper/copyright  
> 
> Probably caused by the install file being called
> debian/haskell-cabal-helper-utils.install but there being no mention of
> "utils" anywhere in debian/control.

Tank you for your report!
Yes indeed, the file is missing. I think installing it to /usr/lib
would be sensible, as Debian doesn't have /usr/libexec.

> Also, ghc-mod seems to expect cabal-helper in /usr/libexec:
> 
> > $ ghc-mod list
> > ghc-mod: Could not find $libexecdir/cabal-helper-wrapper
> > 
> > If you are a developer set the environment variable
> > `cabal_helper_libexecdir' to override $libexecdir[1]. The following will
> > work in the cabal-helper source tree:
> > 
> > $ export cabal_helper_libexecdir=$PWD/dist/build/cabal-helper-wrapper
> > 
> > [1]: /usr/libexec
> > 
> > If you don't know what I'm talking about something went wrong with your
> > installation. Please report this problem here:
> > 
> > https://github.com/DanielG/cabal-helper/issues  
> 
> Shall I open another bug or can you check that as well?

It would be good if you open another report for ghc-mod, so it won't
migrate before its libexecdir is set to /usr/lib.

Regards
Sven


pgpTECo60MNMA.pgp
Description: Digitale Signatur von OpenPGP

Bug#809088: ghc-mod: Unable to install ghc-mod

[Sven Bartscher]

Control: severity -1 grave
Control: tags -1 + pending

On Sun, 27 Dec 2015 14:50:45 +0530
Vasudev Kamath  wrote:

> Source: ghc-mod
> Severity: important
> 
> Dear Maintainer,
> 
> I'm trying to install ghc-mod but I get following error.
> 
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  ghc-mod : Depends: ghc (< 7.8.4+) but 7.10.3-4.1 is to be installed
>Recommends: ghc-mod-el (= 5.2.1.2-1) but it is not going to be 
> installed
> E: Unable to correct problems, you have held broken packages.
> 
> Checking at the tracker _ It looks like this package is having this
> problem for about ~6 months. I also tried installing package from
> experimental but it also fails with following error.
> 
> The following packages have unmet dependencies:
>  ghc-mod : Depends: ghc (< 7.10.2+) but 7.10.3-4.1 is to be installed
>Recommends: ghc-mod-el (= 5.3.0.0-3) but it is not going to be 
> installed
> E: Unable to correct problems, you have held broken packages.

Thanks for your report!
We recently transitioned to GHC 7.10 in unstable and ghc-mod wasn't
updated for that. There will soon be an upload that can be built with
GHC 7.10, which should fix this problem.

> Probably the right severity for bug is *grave* as this issue renders
> package unusable but I'm not quite sure so I've kept it at
> *important*. Please consider bumping severity if that is the right
> severity.

I bumped the severity, as this indeed makes the package unusable for
almost everyone.

Regards
Sven


pgp8bOpkaWjgF.pgp
Description: Digitale Signatur von OpenPGP

Bug#809088: ghc-mod: Unable to install ghc-mod

[Sven Bartscher]

On Sun, 27 Dec 2015 15:37:43 +0100
Joachim Breitner  wrote:

> Hi,
> 
> on ghc-mod:
> 
> Am Sonntag, den 27.12.2015, 14:50 +0530 schrieb Vasudev Kamath:
> > Checking at the tracker  It looks like this package is having this
> > problem for about ~6 months.  
> 
> Does this package actually have users? Or are the users very pardoning
> and quiet?

I use it, but I'm using testing for development, so I only get bugged
by problems in ghc-mod if it affects testing. However, I didn't see
ghc-mod having any problems in unstable before the GHC 7.10 upload.

PS: In my last mail I messed up the recipients of my answer and sent a
copy to the debian-haskell list and you answered to that one, so the
bug tracker didn't get your answer.

Regards
Sven


pgpVZac8dX74P.pgp
Description: Digitale Signatur von OpenPGP

Bug#759335: psi-plus: Link against libminizip

[Sven Bartscher]

Control: tags + patch

On Tue, 26 Aug 2014 14:28:52 +0200 Florian Fieber
 wrote:
> since libminizip{1,-dev} [0] is now a Debian package, Psi+ should link against
> it instead of being compiled against its old, bundled version.

Making sure that libminizip-dev is installed during build seems to be
enough to get the the build system to link against the system version.
The attached patch adds libminizip-dev to the build dependencies and
should fix this bug.

Regards
Sven
diff --git a/debian/control b/debian/control
index 01b0faa..a02d034 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Boris Pek 
 Build-Depends: debhelper (>= 9),
libaspell-dev,
libidn11-dev,
+   libminizip-dev,
libotr5-dev | libotr2-dev,
libqca2-dev,
libqtwebkit-dev,


pgparw4sqf2gX.pgp
Description: Digitale Signatur von OpenPGP

Bug#803317: openmw-launcher: error while loading shared libraries: libboost_system.so.1.55.0

[Sven Bartscher]

Package: openmw-launcher
Version: 0.36.1-1+b2
Severity: grave
Justification: renders package unusable

omwlauncher doesn't start, but gives the following error message
instead:

omwlauncher: error while loading shared libraries:
libboost_system.so.1.55.0: cannot open shared object file: No such
file or directory

It seems like it is linked against the wrong binary.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.2.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openmw-launcher depends on:
ii  libboost-filesystem1.58.0   1.58.0+dfsg-3.1
ii  libboost-program-options1.58.0  1.58.0+dfsg-3.1
ii  libboost-system1.58.0   1.58.0+dfsg-3.1
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-22
ii  libogre-1.9.0v5 1.9.0+dfsg1-6
ii  libqtcore4  4:4.8.7+dfsg-3
ii  libqtgui4   4:4.8.7+dfsg-3
ii  libsdl2-2.0-0   2.0.2+dfsg1-7
ii  libstdc++6  5.2.1-22
ii  libunshield01.0-1
ii  libxt6  1:1.1.4-1+b1
ii  openmw  0.36.1-1+b2

openmw-launcher recommends no packages.

openmw-launcher suggests no packages.

-- no debconf information

Bug#800383: xchat: No tray icon in KDE 5

[Sven Bartscher]

Package: xchat
Version: 2.8.8-7.3
Severity: minor

No tray icon is shown for XChat since the upgrade to KDE 5. If you
accidentally minimized XChat to the tray, you can't open the running
instance anymore and also can't kill it (without a terminal).

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: i386 (i686)

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

Versions of packages xchat depends on:
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-22
ii  libcairo21.14.2-2
ii  libdbus-1-3  1.10.0-3
ii  libdbus-glib-1-2 0.102-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6-2
ii  libgdk-pixbuf2.0-0   2.32.0-1
ii  libglib2.0-0 2.44.1-1.1
ii  libgtk2.0-0  2.24.28-1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libperl5.20  5.20.2-6
ii  libsexy2 0.1.11-2.1
ii  libssl1.0.0  1.0.2d-1
ii  libx11-6 2:1.6.3-1
ii  xchat-common 2.8.8-7.3

Versions of packages xchat recommends:
ii  alsa-utils 1.0.29-1
ii  libnotify-bin  0.7.6-2
ii  libnotify4 0.7.6-2
ii  libpython2.7   2.7.10-4
ii  libtcl8.6  8.6.4+dfsg-2
ii  xdg-utils  1.1.0~rc3+git20150922-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

xchat suggests no packages.

-- no debconf information

Bug#799942: parcimonie: Tray icon not shown in KDE

[Sven Bartscher]

Package: parcimonie
Version: 0.9-3
Severity: minor

Since the KDE 5 upgrade, the parcimonie daemon tray icon isn't shown
anymore. However, the daemon seems to be started properly, so it's
only the graphical icon missing.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: i386 (i686)

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

Versions of packages parcimonie depends on:
ii  libclone-perl0.38-1
ii  libconfig-general-perl   2.58-1
ii  libfile-homedir-perl 1.00-1
ii  libfile-which-perl   1.18-1
ii  libgnupg-interface-perl  0.52-2
ii  liblist-moreutils-perl   0.413-1
ii  libmoo-perl  2.01-3
ii  libmoox-late-perl0.015-2
ii  libmoox-options-perl 4.018-1
ii  libnamespace-clean-perl  0.25-1
ii  libpath-tiny-perl0.072-1
ii  libtime-duration-parse-perl  0.12-1
ii  libtry-tiny-perl 0.22-1
ii  libtype-tiny-perl1.05-1
ii  libtypes-path-tiny-perl  0.005-1
ii  perl 5.20.2-6
ii  torsocks 2.1.0-1

Versions of packages parcimonie recommends:
ii  gnupg-curl  1.4.19-5
ii  libglib-perl3:1.307-3
ii  libgtk3-perl0.023-1
ii  liblocale-gettext-perl  1.05-9
ii  libnet-dbus-glib-perl   0.33.0-1+b4
ii  libnet-dbus-perl1.1.0-3
ii  libpango-perl   1.226-2
ii  libtime-duration-perl   1.20-1
ii  tor 0.2.6.10-1

parcimonie suggests no packages.

-- no debconf information

Bug#799941: claws-mail-multi-notifier: Tray icon not shown in KDE

[Sven Bartscher]

Package: claws-mail-multi-notifier
Version: 3.12.0-1
Severity: normal

Since the upgrade to KDE 5, the claws mail try icon isn't shown int
the tray anymore. When "minimize to tray" is set, it still continues
to run in the background, when closed, though.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: i386 (i686)

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

Versions of packages claws-mail-multi-notifier depends on:
ii  claws-mail   3.12.0-1
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-20
ii  libcairo21.14.2-2
ii  libcanberra-gtk0 0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libdb5.3 5.3.28-11
ii  libetpan17   1.6-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6-1
ii  libgdk-pixbuf2.0-0   2.31.5-1
ii  libglib2.0-0 2.44.1-1.1
ii  libgnutls-deb0-283.3.17-1
ii  libgtk2.0-0  2.24.28-1
ii  liblockfile1 1.09-6
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libsasl2-2   2.1.26.dfsg1-13
ii  libx11-6 2:1.6.3-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages claws-mail-multi-notifier recommends:
ii  notification-daemon  3.17.2-2
ii  xfce4-notifyd [notification-daemon]  0.2.4-3+b1

Versions of packages claws-mail-multi-notifier suggests:
pn  lcdproc
ii  libnotify-bin  0.7.6-2
pn  xosd-bin   

-- no debconf information

Bug#783780: ghc-mod: conffiles not removed

[Sven Bartscher]

On Thu, 30 Apr 2015 07:56:06 +0800 Paul Wise p...@debian.org wrote:
 The recent upgrade did not deal with obsolete conffiles properly.
 Please use the dpkg-maintscript-helper support provided by
 dh_installdeb to remove these obsolete conffiles on upgrade.

The conffile isn't plain obsolete, but moved to another package. The
policy doesn't declare a special case here but also fails to define
precisely when a conffile is obsolete.
So, removing the conffile should be easy, by using dh_installdeb
functionality but I don't know if it's the appropriate thing to do.

Regards
Sven

Bug#796387: Expired keys aren't handled well

[Sven Bartscher]

Package: nm.debian.org
Severity: minor

I tried to apply to become DD. My key expired recently and because I'm
currently not able to extend its lifetime I wanted to apply with the
expired key and extend the lifetime later.

Doing so gave me the warning that my key expires soon, which is
likely wrong, because I will either not extend the lifetime, so the
key won't expire at all, or I will extend it, in which case I will
likely not extend the lifetime for a short duration.

When submitting the form (because well, it's just a warning) I ran
into a 500 Internal Server error, that was likely caused by gpg, not
being able to encrypt the confirmation e-mail with an expired key.

While this doesn't affect the functionality of the process, it would
be nice if it would be handled with proper warnings/errors.

Regards
Sven

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: i386 (i686)

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