Bug#1070077: [Pkg-privacy-maintainers] Bug#1070077: ships files directly in /usr/onionprobe

[Georg Faerber]

Hi,

Thanks for the report.

On 24-04-29 16:19:21, Antoine Beaupre wrote:
> Package: onionprobe
> Version: 1.0.0+ds-2.1+deb12u1
> Severity: serious
> 
> The Debian package shipped in bookworm right now changed the path to
> the examples/ directory. It used to be:
> 
> /usr/lib/python3/dist-packages/onionprobe/examples/tpo.py
> 
>  and now seems to be:
> 
> /usr/onionprobe/examples/tpo.py
> 
> Apart from the gratuitous change, this seems to be a violation of the
> FHS policy, packages shouldn't ship their own stuff directly under
> /usr like this...

Indeed -- I wasn't aware, or probably forgot, that bookworm is affected.
Given the severity, this might warrant a bookworm-pu, I guess?

> I haven't checked in unstable to see if this is fixed.

This was reported via #1025508 and fixed in unstable via 1.1.2+ds-1.

Cheers,
Georg

Bug#1068411: bookworm-pu: package schleuder/4.0.3-7+deb12u1

[Georg Faerber]

On 24-04-06 22:31:03, Jonathan Wiltshire wrote:
> Please go ahead.

Uploaded, thank you.

Bug#1068411: bookworm-pu: package schleuder/4.0.3-7+deb12u1

[Georg Faerber]

ich rely on the same key. As a fallback, the first
  subscription found is used. Before, people might have received a reply
  to a different email address. (Closes: #1068335)

Thanks for your work!

Cheers,
Georg
diff -Nru schleuder-4.0.3/debian/changelog schleuder-4.0.3/debian/changelog
--- schleuder-4.0.3/debian/changelog2022-12-26 18:49:28.0 +
+++ schleuder-4.0.3/debian/changelog2024-04-04 18:15:10.0 +
@@ -1,3 +1,36 @@
+schleuder (4.0.3-7+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
+- x-subscribe: fix parsing of arguments. Optional flags provided at the
+  end are only taken into account if there is a valid fingerprint, and
+  they are checked to be "true", or "false". Before, due to insufficient
+  validation, an email address might have been erroneously subscribed with
+  'admin' permissions. (Closes: #1068330)
+- x-add-key: fix importing keys from attachments as Thunderbird sends
+  them. Before, such attachments were ignored. This regression was
+  introduced in 4.0.0. (Closes: #1068331)
+- x-add-key: fix handling of emails without further content or
+  attachments. A proper error message is returned. Before, a traceback was
+  thrown. (Closes: #1068332)
+- Stop looking for keywords if email starts with other content. This
+  allows to send usage instructions including keywords within an email to
+  a Schleuder list. Before, these keywords would have been stripped, which
+  limited the value of such an email. This change matches documentation,
+  which tells that keywords require that they are written in the beginning
+  of an email body. (Closes: #1068333)
+- receive_from_subscribed_emailaddresses_only(): check downcased email
+  address. This follows and mirrors changes made in both schleuder-cli and
+  schleuder-web, which nowadays enforce lowercase if adding subscriptions.
+  Before, incoming emails might have been erroneously rejected, if an
+  uppercase email address was used in the From: header. (Closes: #1068334)
+- Consider From: when finding reply address. Look for a subscription that
+  matches the sending email address, in case of multiple subscriptions
+  which rely on the same key. As a fallback, the first subscription found
+  is used. Before, people might have received a reply to a different email
+  address. (Closes: #1068335)
+
+ -- Georg Faerber   Thu, 04 Apr 2024 18:15:10 +
+
 schleuder (4.0.3-7) unstable; urgency=medium
 
   * Team upload
diff -Nru 
schleuder-4.0.3/debian/patches/0032-Improve-parsing-arguments-of-x-subscribe.patch
 
schleuder-4.0.3/debian/patches/0032-Improve-parsing-arguments-of-x-subscribe.patch
--- 
schleuder-4.0.3/debian/patches/0032-Improve-parsing-arguments-of-x-subscribe.patch
  1970-01-01 00:00:00.0 +
+++ 
schleuder-4.0.3/debian/patches/0032-Improve-parsing-arguments-of-x-subscribe.patch
  2024-04-04 18:15:10.0 +
@@ -0,0 +1,135 @@
+From: paz 
+Date: Mon, 29 Jan 2024 18:09:12 +0100
+Subject: Improve parsing arguments of x-subscribe
+
+The flags at the end now are only taken into account if there's a valid
+fingerprint, and they are checked to be "true", or "false".
+---
+ lib/schleuder/gpgme/key.rb |  2 +-
+ .../keyword_handlers/subscription_management.rb| 22 +++--
+ locales/de.yml |  2 +-
+ locales/en.yml |  2 +-
+ spec/schleuder/integration/keywords_spec.rb| 38 ++
+ 5 files changed, 60 insertions(+), 6 deletions(-)
+
+diff --git a/lib/schleuder/gpgme/key.rb b/lib/schleuder/gpgme/key.rb
+index 0039e1c..f5d1a7b 100644
+--- a/lib/schleuder/gpgme/key.rb
 b/lib/schleuder/gpgme/key.rb
+@@ -82,7 +82,7 @@ module GPGME
+ end
+ 
+ def self.valid_fingerprint?(fp)
+-  fp =~ Schleuder::Conf::FINGERPRINT_REGEXP
++  fp.present? && fp.match?(Schleuder::Conf::FINGERPRINT_REGEXP)
+ end
+   end
+ end
+diff --git a/lib/schleuder/keyword_handlers/subscription_management.rb 
b/lib/schleuder/keyword_handlers/subscription_management.rb
+index 1fc7f1b..68ca6ec 100644
+--- a/lib/schleuder/keyword_handlers/subscription_management.rb
 b/lib/schleuder/keyword_handlers/subscription_management.rb
+@@ -22,9 +22,25 @@ module Schleuder
+   while @arguments.first.present? && 
@arguments.first.match(/^(0x)?[a-f0-9]+$/i)
+ fingerprint << @arguments.shift.downcase
+   end
+-  # Use possibly remaining args as flags.
+-  adminflag = @arguments.shift.to_s.downcase.presence
+-  deliveryflag = @arguments.shift.to_s.downcase.presence
++  # If the collected values aren't a valid fingerprint, then the input
++  # didn't conform with what this code expects, and then the other
++  # valu

Bug#1068333: schleuder: keywords in the middle of messages get stripped

[Georg Faerber]

Package: schleuder
Version: 4.0.3-7
Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/535
Tags: bookworm fixed-upstream upstream

Sometimes, a user of a schleuder list might send instructions about how
to control a schleuder list in a message that went to the list itself.

If the instructions include keywords, those keywords are stripped before
re-sending, even if those keywords are not at the top of the message.

Bug#1068332: schleuder: throws a traceback if told to import a key, but a key can't be found

[Georg Faerber]

Package: schleuder
Version: 4.0.3-7
Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/526
Tags: bookworm fixed-upstream upstream

Super admins receive the following error via mail if a user tries to
import a key via a request mail with x-add-key, but no key:

undefined method `compact' for "Your message did not contain any attachments 
nor text content. Therefore no key could be imported.":String

import_stati = results.compact.collect(&:imports).flatten
  
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers/key_management.rb:21:in 
`add_key'
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers_runner.rb:67:in 
`run_handler'
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers_runner.rb:34:in `block in 
run'
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers_runner.rb:32:in `map'
/usr/lib/ruby/vendor_ruby/schleuder/keyword_handlers_runner.rb:32:in `run'
/usr/lib/ruby/vendor_ruby/schleuder/filters/post_decryption/10_request.rb:16:in 
`request'
/usr/lib/ruby/vendor_ruby/schleuder/filters_runner.rb:14:in `block in run'
/usr/lib/ruby/vendor_ruby/schleuder/filters_runner.rb:12:in `map'
/usr/lib/ruby/vendor_ruby/schleuder/filters_runner.rb:12:in `run'
/usr/lib/ruby/vendor_ruby/schleuder/runner.rb:127:in `run_filters'
/usr/lib/ruby/vendor_ruby/schleuder/runner.rb:56:in `run'
/usr/lib/ruby/vendor_ruby/schleuder/cli.rb:38:in `work'
/usr/share/rubygems-integration/all/gems/thor-1.2.1/lib/thor/command.rb:27:in 
`run'
/usr/share/rubygems-integration/all/gems/thor-1.2.1/lib/thor/invocation.rb:127:in
 `invoke_command'
/usr/share/rubygems-integration/all/gems/thor-1.2.1/lib/thor.rb:392:in 
`dispatch'
/usr/share/rubygems-integration/all/gems/thor-1.2.1/lib/thor/base.rb:485:in 
`start'
/usr/bin/schleuder:13:in `'

Bug#1068331: schleuder: x-add-key fails to import keys from attachments as Thunderbird sends them

[Georg Faerber]

Package: schleuder
Version: 4.0.3-7
Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/525
Tags: bookworm fixed-upstream upstream
 
Schleuder fails to import keys from attachments as Thunderbird sends
them. This regression was introduced in 4.0.0.

Bug#1037346: cyrus-imapd: all emails disappeared after upgrading from bullseye to bookworm (similar to #1007965)

[Jens Georg]

Package: cyrus-common
Version: 3.2.6-2+deb11u2
Followup-For: Bug #1037346


Some additional information:
 - You can roll-back to package 3.2 after the upgrade to 3.6, the
   mailboxes will re-appear again
 - You might encounter some junk mailboxes from the failed conversion
   attempt, the remedy is to convert mailboxes.db to text, remove the
   offending lines, and convert it back to its original format.
 - The proper may to migrate to 3.6 without hassle is:
   - Stop cyrus-imapd service
   - Download and compile 3.4, run ./imap/ctl_cyrusdb -r once (make a
 copy of /var/lib/cyrus/mailboxes.db beforehand, of course)
 - Then proceed with the update

It seems that the debian package, despite claiming that it has the
necessary patches to make the upgrade possible, doesn't.

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-16-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, 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 cyrus-common depends on:
ii  adduser 3.134
ii  db-upgrade-util 5.3.1+nmu1
ii  db-util 5.3.2
ii  debconf [debconf-2.0]   1.5.82
ii  e2fsprogs   1.47.0-2
ii  gawk1:5.2.1-2
ii  init-system-helpers 1.65.2
ii  libc6   2.36-9+deb12u4
ii  libclamav9  0.103.10+dfsg-0+deb11u1
ii  libcom-err2 1.47.0-2
ii  libgcc-s1   12.2.0-14
ii  libical33.0.16-1+b1
ii  libicu6767.1-7
ii  libjansson4 2.14-2
ii  libkrb5-3   1.20.1-2+deb12u1
ii  libldap-2.4-2   2.4.57+dfsg-3+deb11u1
ii  libpcre32:8.39-15
ii  libpq5  15.5-0+deb12u1
ii  libsasl2-2  2.1.28+dfsg-10
ii  libsasl2-modules2.1.28+dfsg-10
ii  libsnmp40   5.9.3+dfsg-2
ii  libsqlite3-03.40.1-2
ii  libssl1.1   1.1.1w-0+deb11u1
ii  libstdc++6  12.2.0-14
ii  libwrap07.6.q-32
ii  libxapian30 1.4.22-1
ii  libxml2 2.9.14+dfsg-1.3~deb12u1
ii  libzephyr4  3.1.2-1.1+b1
ii  lsb-base11.6
ii  netbase 6.4
ii  perl5.36.0-7+deb12u1
ii  postfix [mail-transport-agent]  3.7.6-0+deb12u2
ii  sysvinit-utils [lsb-base]   3.06-4
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages cyrus-common recommends:
hi  cyrus-admin  3.2.6-2+deb11u2
hi  cyrus-imapd  3.2.6-2+deb11u2
hi  cyrus-pop3d  3.2.6-2+deb11u2

Versions of packages cyrus-common suggests:
pn  apt-listchanges
hi  cyrus-admin3.2.6-2+deb11u2
pn  cyrus-caldav   
pn  cyrus-clients  
hi  cyrus-doc  3.2.6-2+deb11u2
hi  cyrus-imapd3.2.6-2+deb11u2
pn  cyrus-murder   
pn  cyrus-nntpd
hi  cyrus-pop3d3.2.6-2+deb11u2
pn  cyrus-replication  
ii  sasl2-bin  2.1.28+dfsg-10

-- Configuration Files:
/etc/cyrus.conf changed [not included]
/etc/imapd.conf changed [not included]
/etc/pam.d/sieve changed [not included]

-- debconf information excluded

Bug#1060084: puppet-agent: Resource type 'Cron' was not found, even after puppet-module-puppetlabs-cron-core installed

[Georg Faerber]

On 24-01-05 21:15:52, Georg Faerber wrote:
> On bullseye, I had to install the 'cron' package on the machine
> running the agent. I'm not sure if it works with other cron
> implementations as well.

The above comment was not about bullseye, but bookworm.

Bug#1060084: puppet-agent: Resource type 'Cron' was not found, even after puppet-module-puppetlabs-cron-core installed

[Georg Faerber]

Hi Will,

On 24-01-05 19:02:38, Will Partain wrote:
> Invoked puppet-agent against a "legacy" server:
> 
>/usr/bin/puppet agent --server parple-pup1.parple.org --test 
> --certname=parple-pup2.parple.org --environment=prodnew --diff_args=-U1 
> --noop --debug
> 
> It received "work" from the server, and started doing things, until it
> needed 'Cron'... (the debugging log just before that...):
> 
>   Debug: /Package[apticron]: Provider apt does not support features 
> install_only; not managing attribute install_only
>   Debug: /Package[logrotate]: Provider apt does not support features 
> targetable; not managing attribute command
>   Debug: /Package[logrotate]: Provider apt does not support features 
> install_only; not managing attribute install_only
>   Error: Failed to apply catalog: Resource type 'Cron' was not found

On bullseye, I had to install the 'cron' package on the machine running
the agent. I'm not sure if it works with other cron implementations as
well.

Maybe this helps,
all the best,
Georg

Bug#1056594: [Pkg-privacy-maintainers] Bug#1056594: mat2: test failure

[Georg Faerber]

Hi Paul,

On 24-01-01 10:24:46, Paul Gevers wrote:
> On 01-01-2024 09:50, Paul Gevers wrote:
> > I'm going to NMU with this patch shortly. @gregor, any reason why
> > you didn't the upload to DELAYED after you built it already?
> 
> I have uploaded the attached changes.

Thanks for the upload, although I would have appreciated communication
about this upfront.

Could you please push the relevant changes to git?

Thanks & all the best,
Georg

Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1

[Georg Faerber]

Hi Jonathan,

On 23-12-24 19:48:20, Jonathan Wiltshire wrote:
> Yes. Just make sure you have the rejection email before you upload
> again with the same version.

Thanks -- the changelog listing the latest upload 1.0.0+ds-2.1, as
present currently in bookworm, is now part of the git history. I rebuild
accordingly, see the attached diff, which now correctly lists the
version as per above in the changelog.

I've uploaded again, and hope it goes without troubles for you this time.

I'll pay better attention next time.

Cheers,
Georg
diff -Nru onionprobe-1.0.0+ds/debian/changelog onionprobe-1.0.0+ds/debian/changelog
--- onionprobe-1.0.0+ds/debian/changelog	2022-10-15 10:32:07.0 +
+++ onionprobe-1.0.0+ds/debian/changelog	2023-12-18 14:30:56.0 +
@@ -1,3 +1,11 @@
+onionprobe (1.0.0+ds-2.1+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
+- Pull in upstream fix to silence Tor if generating hashed passwords.
+  (Closes: #1053204)
+
+ -- Georg Faerber   Mon, 18 Dec 2023 14:30:56 +
+
 onionprobe (1.0.0+ds-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru onionprobe-1.0.0+ds/debian/patches/0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch onionprobe-1.0.0+ds/debian/patches/0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch
--- onionprobe-1.0.0+ds/debian/patches/0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch	1970-01-01 00:00:00.0 +
+++ onionprobe-1.0.0+ds/debian/patches/0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch	2023-12-18 14:30:56.0 +
@@ -0,0 +1,21 @@
+Description: Fix: make the tor process quiet when generating hashed passwords
+Author: Silvio Rhatto 
+Origin: upstream
+Applied-Upstream: 6bb2a64fa73e2f678279709f82823f90fd3dc672
+Reviewed-by: Georg Faerber 
+Last-Update: 2023-12-18
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: onionprobe/packages/onionprobe/tor.py
+===
+--- onionprobe.orig/packages/onionprobe/tor.py	2023-12-18 14:20:02.960327906 +
 onionprobe/packages/onionprobe/tor.py	2023-12-18 14:21:17.442024820 +
+@@ -166,7 +166,7 @@
+ import subprocess
+ 
+ tor= shutil.which('tor')
+-result = subprocess.check_output([tor, '--hash-password', password], text=True)
++result = subprocess.check_output([tor, '--quiet', '--hash-password', password], text=True)
+ 
+ return result
+ 
diff -Nru onionprobe-1.0.0+ds/debian/patches/series onionprobe-1.0.0+ds/debian/patches/series
--- onionprobe-1.0.0+ds/debian/patches/series	1970-01-01 00:00:00.0 +
+++ onionprobe-1.0.0+ds/debian/patches/series	2023-12-18 14:30:56.0 +
@@ -0,0 +1 @@
+0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch

Bug#1059496: podman: network ls: might fail to handle removed container

[Georg Faerber]

Package: podman
Version: 4.3.1+ds1-8+b1
Control: fixed -1 4.7.2+ds1-2
Severity: normal
Forwarded: https://github.com/containers/podman/issues/17341
Tags: bookworm fixed-upstream upstream 

podman 4.3.1+ds1-8+b1, as currently present in bookworm, might fail to
list a network while a container was just removed.

GitLab CI recently added the possibility to use podman as an executor,
instead of docker, and requires a feature flag 'FF_NETWORK_PER_BUILD' to
be set, see [1] for the upstream docs.

However, due to the above described problem, container preparation
initiated by podman might fail [2].

This was fixed in podman upstream [3] and released in 4.5.0.

Any chance this fix could be backported to bookworm via a
proposed-update? If helpful, I'm able to test a proposed, fixed package.

Thanks a lot for maintaining podman in Debian!

Cheers,
Georg


[1] 
https://docs.gitlab.com/runner/executors/docker.html#use-podman-to-run-docker-commands
[2] https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28971
[3] https://github.com/containers/podman/pull/17376

Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1

[Georg Faerber]

Hi,

Sorry for the additional work:

On 23-12-24 16:31:37, Jonathan Wiltshire wrote:
> Something has gone wrong with your upload (a rebase maybe?):

The missing part of the changelog, as per the diff you sent, is
currently not part of the git history, which is problematic, I guess.

So if my above assumption is correct, I'll ensure that's recorded in git
accordingly, rebuild and upload again.

Jonathan, does the above make sense?

Thanks,
Georg

Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1

[Georg Faerber]

On 23-12-21 21:52:08, Jonathan Wiltshire wrote:
> Please go ahead.

Thanks, uploaded.

Bug#1053204: [Pkg-privacy-maintainers] Bug#1053204: onionprobe: Tor warns when generating hashed passwords

[Georg Faerber]

The bookworm proposed-updated is tracked via #1058938.

Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1

[Georg Faerber]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 + src:onionprobe

Dear release team,

[ Reason ]
On bullseye, this works without a warning:
$ tor --hash-password some-string
16:A871A161E60E3C3960934C88AA783AC6B693DF63CF7897CA5E87219E26

Whereas on bookworm, this throws a warning:
$ tor --hash-password some-string
Sep 28 20:48:10.111 [warn] Tor was compiled with zstd 1.5.2, but is running 
with zstd 1.5.4. For safety, we'll avoid using advanced zstd functionality.
16:E4DFE5BA0F5C257060D3D092B5666351C8A04DEF6C77E27DAE7B6015A8

Due to this, onionprobe fails to initialize Tor.

This was fixed, both upstream and in Debian unstable via 1.1.2+ds-1.

[ Impact ]
Severe, as onionprobe fails to work as expected. There are no
workarounds.

[ Tests ]
Tests were done both manually and on production systems for several
weeks.

[ Risks ]
There should be none.

[ 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 stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Pull in upstream fix to silence Tor if generating hashed passwords.

Thanks for your work!

Cheers,
Georg
diff -Nru onionprobe-1.0.0+ds/debian/changelog onionprobe-1.0.0+ds/debian/changelog
--- onionprobe-1.0.0+ds/debian/changelog	2022-07-20 19:16:36.0 +
+++ onionprobe-1.0.0+ds/debian/changelog	2023-12-18 14:30:56.0 +
@@ -1,3 +1,11 @@
+onionprobe (1.0.0+ds-2.1+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
+- Pull in upstream fix to silence Tor if generating hashed passwords.
+  (Closes: 1053204)
+
+ -- Georg Faerber   Mon, 18 Dec 2023 14:30:56 +
+
 onionprobe (1.0.0+ds-2) unstable; urgency=medium
 
   * Source-only upload to allow migration. 
diff -Nru onionprobe-1.0.0+ds/debian/patches/0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch onionprobe-1.0.0+ds/debian/patches/0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch
--- onionprobe-1.0.0+ds/debian/patches/0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch	1970-01-01 00:00:00.0 +
+++ onionprobe-1.0.0+ds/debian/patches/0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch	2023-12-18 14:30:56.0 +
@@ -0,0 +1,21 @@
+Description: Fix: make the tor process quiet when generating hashed passwords
+Author: Silvio Rhatto 
+Origin: upstream
+Applied-Upstream: 6bb2a64fa73e2f678279709f82823f90fd3dc672
+Reviewed-by: Georg Faerber 
+Last-Update: 2023-12-18
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: onionprobe/packages/onionprobe/tor.py
+===
+--- onionprobe.orig/packages/onionprobe/tor.py	2023-12-18 14:20:02.960327906 +
 onionprobe/packages/onionprobe/tor.py	2023-12-18 14:21:17.442024820 +
+@@ -166,7 +166,7 @@
+ import subprocess
+ 
+ tor= shutil.which('tor')
+-result = subprocess.check_output([tor, '--hash-password', password], text=True)
++result = subprocess.check_output([tor, '--quiet', '--hash-password', password], text=True)
+ 
+ return result
+ 
diff -Nru onionprobe-1.0.0+ds/debian/patches/series onionprobe-1.0.0+ds/debian/patches/series
--- onionprobe-1.0.0+ds/debian/patches/series	1970-01-01 00:00:00.0 +
+++ onionprobe-1.0.0+ds/debian/patches/series	2023-12-18 14:30:56.0 +
@@ -0,0 +1 @@
+0001-Fix-make-the-tor-process-quiet-when-generating-hashed-passwords.patch

Bug#1058818: Acknowledgement (grub-common: fwsetup --is-supported not supported, boots into setup instead)

[Georg Lukas]

Okay, this is a weirdness caused by how I installed this laptop. I did a
standard Debian install in 2021, then copied the rootfs from my previous
(non-EFI) machine over it.

Therefore I ended up with the modules in /usr/lib/grub/x86_64-efi in
place, but not part of any installed Debian package. Instead, grub-pc
kept the files in /usr/lib/grub/i386-pc up-to-date.

However, grub-install correctly identified the machine as EFI and just
silently used the stale files from /usr/lib/grub/x86_64-efi:

# /usr/sbin/grub-install
Installing for x86_64-efi platform.
Installation finished. No error reported.
#

This caused the 2021 files to be installed to /boot/grub/x86_64-efi/ and
to the EFI partition.

Installing grub-efi-amd64-bin and updating grub got me the
efifwsetup.mod with the --is-supported flag and now everything is good.

Still, maybe it's a good idea to have grub-install check for the
presence of the right / up-to-date package?

Thank you very much.

Bug#1058818: Acknowledgement (grub-common: fwsetup --is-supported not supported, boots into setup instead)

[Georg Lukas]

This is probably related to
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=26031d3b101648352e4e427f04bf69d320088e77
- if the config change from that commit is combined with an older grub2
binary, the binary will interpret `fwsetup --is-supported` as `fwsetup`
and immediately reboot into the BIOS setup.

This will happen when loading a new config from an old grub2, like the
one bundled with the Debian installer ISO/USB.

This also happens with the grub2 binary that's part of the 2.12~rc1-12
package - maybe it wasn't cleanly compiled? Or I have some older files
installed somewhere?!

Bug#1058818: grub-common: fwsetup --is-supported not supported, boots into setup instead

[Georg Lukas]

Package: grub-common
Version: 2.12~rc1-12
Severity: important

The `fwsetup --is-supported` call from grub.d/30_uefi-firmware doesn't
query for support, but instead reboots right into the BIOS setup. This
makes the system unusable, as the command is executed when reading the
config file.

Removing /etc/grub.d/30_uefi-firmware and re-running update-grub
works around the issue.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/ssd--vg-ssd--root / ext4 
rw,noatime,nodiratime,discard,errors=remount-ro 0 0
/dev/nvme0n1p2 /boot ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

terminal_input console
terminal_output console
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-afc8989e-fe3d-41e3-98fa-45a5959c6982' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 
d880c702-5a61-4007-85e8-7d93eb1339f9
echo'Loading Linux 6.5.0-5-amd64 ...'
linux   /vmlinuz-6.5.0-5-amd64 root=/dev/mapper/ssd--vg-ssd--root ro 
resume=/dev/mapper/ssd--vg-ssd--swap quiet rd.luks.options=discard 
acpi_backlight=native
echo'Loading initial ramdisk ...'
initrd  /initrd.img-6.5.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-afc8989e-fe3d-41e3-98fa-45a5959c6982' {
menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-6.5.0-5-amd64-advanced-afc8989e-fe3d-41e3-98fa-45a5959c6982' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 
d880c702-5a61-4007-85e8-7d93eb1339f9
echo'Loading Linux 6.5.0-5-amd64 ...'
linux   /vmlinuz-6.5.0-5-amd64 
root=/dev/mapper/ssd--vg-ssd--root ro resume=/dev/mapper/ssd--vg-ssd--swap 
quiet rd.luks.options=discard acpi_backlight=native
echo'Loading initial ramdisk ...'
initrd  /initrd.img-6.5.0-5-amd64
}
menuentry 'Debian GNU/Linux, with Linux 6.5.0-5-amd64 (recovery mode)' 
--class debian --class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-6.5.0-5-amd64-recovery-afc8989e-fe3d-41e3-98fa-45a5959c6982' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 
d880c702-5a61-4007-85e8-7d93eb1339f9
echo'Loading Linux 6.5.0-5-amd64 ...'
linux   /vmlinuz-6.5.0-5-amd64 
root=/dev/mapper/ssd--vg-ssd--root ro single single dis_ucode_ldr 
resume=/dev/mapper/ssd--vg-ssd--swap
echo'Loading initial ramdisk ...'
initrd  /initrd.img-6.5.0-5-amd64
}
menuentry 'Debian GNU/Linux, with Linux 6.5.0-4-amd64' 

Bug#1053204: [Pkg-privacy-maintainers] Bug#1053204: onionprobe: Tor warns when generating hashed passwords

[Georg Faerber]

Hi,

On 23-10-19 10:49:26, Antoine Beaupré wrote:
> What's the status of this bug? are you planning a release update for
> this?

Yes, I do, swamped with work currently. Expect the unstable update
within the upcoming four days. Once done, I'll take care of the stable
update, although that will take a while to be officially released,
still. 

Cheers,
Georg

Bug#1054128: coreutils: cp -p --parent not working

[Georg Borgström]

Package: coreutils
Version: 9.1-1
Severity: normal

Dear Maintainer,

This doesn't work in bookworm but works in bullseye:

$ mkdir /tmp/newdir
$ cp -p --parent /etc/passwd /tmp/newdir
cp: ‘etc’: No such file or directory

/tmp/newdir/etc gets created but with wrong permission and also the error 
message above.

$ ls -ald /tmp/newdir/etc
drwx-- 2 gb gb 60 Oct 17 14:54 /tmp/newdir/etc

Should be:
drwxr-xr-x 2 gb gb 60 Oct 17 11:09 /tmp/newdir/etc

Could be the same as:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2017414

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9+deb12u3
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b6

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1053204: onionprobe: Tor warns when generating hashed passwords

[Georg Faerber]

Package: onionprobe
Version: 1.0.0+ds-2.1
Severity: important
Forwarded: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41339
Tags: bookworm fixed-upstream upstream 

On bullseye, this works without warning:
$ tor --hash-password some-string
16:A871A161E60E3C3960934C88AA783AC6B693DF63CF7897CA5E87219E26

Whereas on bookworm, this throws a warning:
$ tor --hash-password some-string
Sep 28 20:48:10.111 [warn] Tor was compiled with zstd 1.5.2, but is running 
with zstd 1.5.4. For safety, we'll avoid using advanced zstd functionality.
16:E4DFE5BA0F5C257060D3D092B5666351C8A04DEF6C77E27DAE7B6015A8

The later might lead to a failing service, that is onionprobe might not
work as expected.

Bug#1050340: [Pkg-puppet-devel] Bug#1050340: puppetserver: incompatibility with system hiera-eyaml

[Georg Faerber]

Hi all,

I ran into this issue as well and debugged a bit:

On 23-08-23 12:16:10, Antoine Beaupré wrote:
> Same here, I was just curious if you thought the manual gem update
> fixed this because it's a new upstream or just because "some gem
> thing".

I believe the issue is not about the new upstream, as according to the
changelog there were no relevant changes in between 3.3.0 and 3.4.0, but rather
it's about the directories, which are searched and code is loaded from.

Due to this, initially, I took the "easy route" and did this:

+++ a/etc/puppet/puppetserver/conf.d/puppetserver.conf
+++ b/etc/puppet/puppetserver/conf.d/puppetserver.conf
@@ -11,7 +11,7 @@ jruby-puppet: {
 # This setting defines the complete "GEM_PATH" for jruby.  If set, it 
should include
 # the gem-home directory as well as any other directories that gems can be 
loaded
 # from (including the vendored gems directory for gems that ship with 
puppetserver)
-gem-path: [${jruby-puppet.gem-home}, 
"/usr/lib/puppetserver/vendored-jruby-gems"]
+gem-path: [${jruby-puppet.gem-home}, 
"/usr/lib/puppetserver/vendored-jruby-gems", 
"/usr/share/rubygems-integration/all"]
 
 # PLEASE NOTE: Use caution when modifying the below settings. Modifying
 # these settings will change the value of the corresponding Puppet settings

However, this leads to the following:

Exception in thread "main" java.lang.IllegalStateException: Unable to borrow 
JRubyInstance from pool
[...]
Caused by: org.jruby.embed.EvalFailedException: (LoadError) Java extensions are 
required for JRuby.
no such file to load -- concurrent/concurrent_ruby.jar

concurrent_ruby.jar is part of the puppetserver package and installed to
/usr/lib/puppetserver/vendored-jruby-gems/gems/concurrent-ruby-1.1.5/lib/concurrent/concurrent_ruby.jar.

The ordering of the directory paths in puppetserver.conf doesn't make a
difference, the error stays the same.

So, symlinks to the rescue:

ln -s /usr/share/rubygems-integration/all/gems/hiera-eyaml-3.3.0/ 
/usr/lib/puppetserver/vendored-jruby-gems/gems/hiera-eyaml-3.3.0
ln -s /usr/share/rubygems-integration/all/gems/optimist-3.0.0/ 
/usr/lib/puppetserver/vendored-jruby-gems/gems/optimist-3.0.0
ln -s /usr/lib/ruby/vendor_ruby/highline 
/usr/lib/puppetserver/vendored-jruby-gems/gems/highline
ln -s 
/usr/share/rubygems-integration/all/specifications/hiera-eyaml-3.3.0.gemspec 
/usr/lib/puppetserver/vendored-jruby-gems/specifications/hiera-eyaml-3.3.0.gemspec
ln -s /usr/share/rubygems-integration/all/specifications/optimist-3.0.0.gemspec 
/usr/lib/puppetserver/vendored-jruby-gems/specifications/optimist-3.0.0.gemspec
ln -s /usr/share/rubygems-integration/all/specifications/highline-2.0.3.gemspec 
/usr/lib/puppetserver/vendored-jruby-gems/specifications/highline-2.0.3.gemspec

This made the error go away.

Maybe that's helpful,
all the best,
Georg

Bug#1038935: [DRE-maint] Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='

[Georg Faerber]

Hi,

On 23-06-27 09:05:43, Georg Faerber wrote:
> Regarding the test: I'll seek comments of the Ruby team before filling
> the -pu; I believe the risk of regressions should be fairly low, as
> arel, as described, has been part of activerecord since quite some
> time.  I'll test this especially in combination with schleuder, which
> exposed this issue; to ease future maintenance and increase the
> chances of spotting these issues earlier, ideally before release, I
> added a "piuparts multi distro upgrade" test job to the Salsa CI [1].

I was on the road the last weeks, therefore I was only able to mail the
team by now.

Cheers,
Georg

Bug#1039020: bullseye-pu: package schleuder/3.6.0-3+deb11u2

[Georg Faerber]

Hi,

On 23-07-23 14:08:17, Jonathan Wiltshire wrote:
> Please go ahead.

Thanks -- uploaded accordingly.

Cheers,
Georg

Bug#1040791: bookworm-pu: package schleuder-cli/0.1.0-4+deb12u1

[Georg Faerber]

Hi Adam,

On 23-07-11 21:46:01, Adam D. Barratt wrote:
> Please go ahead.

Thanks, uploaded.

Cheers,
Georg

Bug#1040257: schleuder-cli does not work with Ruby >= 3.0.0

[Georg Faerber]

Hi,

Thanks for your report.

On 23-07-03 23:50:03, s3lph wrote:
> [...]
>
> Upstream has fixed the issue on the main branch, but has not yet
> created a new release containing the fix.  The fix is quite small,
> only two lines diff:
> 
> https://0xacab.org/schleuder/schleuder-cli/-/commit/68754cf94cc2d9b2a400ff19d2e48a7ffa2ec1f2
> 
> With this patch applied manually, schleuder-cli works as expected:
>
> [...]

Indeed, I forgot to pull this into Debian, apologies for that. That's
fixed now via 0.1.0-5.

bookworm-pu is tracked via #1040791.

Cheers,
Georg

Bug#1040791: bookworm-pu: package schleuder-cli/0.1.0-4+deb12u1

[Georg Faerber]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debianb...@s3lph.me
Control: affects -1 + src:schleuder-cli

Dear release team,

[ Reason ]
Ruby 3.1, as shipped in bookworm, changes the way values are escaped, in
contrast to Ruby <= 3.0. This was fixed upstream in schleuder-cli quite
some time ago, but so far not released.

The patch was pulled into Debian unstable via 0.1.0-5.

[ Impact ]
Severe, as schleuder-cli ceases to work, and throws a traceback due to
an "undefined method".

[ Tests ]
Tests were done both manually and via the upstream CI. The correctness
of the patch was confirmed via #1040257.

[ Risks ]
There should be none.

[ 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 stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
An upstream patch was pulled in to correctly handle escaping values in
Ruby 3.1.

For details, see the attached debdiff of 0.1.0-4, as currently present
in bookworm, and 0.1.0-4+deb12u1.

Thanks for your work!

Cheers,
Georg
diff -Nru schleuder-cli-0.1.0/debian/changelog schleuder-cli-0.1.0/debian/changelog
--- schleuder-cli-0.1.0/debian/changelog	2021-02-01 22:47:06.0 +
+++ schleuder-cli-0.1.0/debian/changelog	2023-07-10 16:06:00.0 +
@@ -1,3 +1,11 @@
+schleuder-cli (0.1.0-4+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
+- Pull in upstream patch to fix escaping values in Ruby 3.
+  (Closes: #1040257)
+
+ -- Georg Faerber   Mon, 10 Jul 2023 16:06:00 +
+
 schleuder-cli (0.1.0-4) unstable; urgency=medium
 
   [ Utkarsh Gupta ]
diff -Nru schleuder-cli-0.1.0/debian/patches/0004-Ruby-3-fix-escaping-values.patch schleuder-cli-0.1.0/debian/patches/0004-Ruby-3-fix-escaping-values.patch
--- schleuder-cli-0.1.0/debian/patches/0004-Ruby-3-fix-escaping-values.patch	1970-01-01 00:00:00.0 +
+++ schleuder-cli-0.1.0/debian/patches/0004-Ruby-3-fix-escaping-values.patch	2023-07-10 16:06:00.0 +
@@ -0,0 +1,31 @@
+Description: Ruby 3: fix escaping values
+Origin: https://0xacab.org/schleuder/schleuder-cli/-/commit/68754cf94cc2d9b2a400ff19d2e48a7ffa2ec1f2
+Reviewed-by: Georg Faerber 
+Last-Update: 2023-07-10
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: schleuder-cli/lib/schleuder-cli.rb
+===
+--- schleuder-cli.orig/lib/schleuder-cli.rb	2023-07-10 15:42:53.037304520 +
 schleuder-cli/lib/schleuder-cli.rb	2023-07-10 15:42:53.029303960 +
+@@ -3,6 +3,7 @@
+ require 'pathname'
+ require 'net/https'
+ require 'uri'
++require 'cgi'
+ require 'singleton'
+ require 'yaml'
+ require 'base64'
+Index: schleuder-cli/lib/schleuder-cli/helper.rb
+===
+--- schleuder-cli.orig/lib/schleuder-cli/helper.rb	2023-07-10 15:42:53.037304520 +
 schleuder-cli/lib/schleuder-cli/helper.rb	2023-07-10 15:42:53.029303960 +
+@@ -19,7 +19,7 @@
+   u = "/#{args.join('/')}.json"
+   if params
+ paramstring  = params.map do |k,v|
+-  "#{URI.escape(k.to_s)}=#{URI.escape(v.to_s)}"
++  "#{CGI.escape(k.to_s)}=#{CGI.escape(v.to_s)}"
+ end.join('&')
+ u << "?#{paramstring}"
+   end
diff -Nru schleuder-cli-0.1.0/debian/patches/series schleuder-cli-0.1.0/debian/patches/series
--- schleuder-cli-0.1.0/debian/patches/series	2021-02-01 22:47:06.0 +
+++ schleuder-cli-0.1.0/debian/patches/series	2023-07-10 16:06:00.0 +
@@ -1,3 +1,4 @@
+0004-Ruby-3-fix-escaping-values.patch
 0003-gemspec-relax-thor-version.patch
 0002-spec-remove-bundler.patch
 0001-lib-use-require-instead-of-require-relative.patch

Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='

[Georg Faerber]

Hi,

On 23-06-26 10:27:37, Antoine Beaupré wrote:
> Just to make sure, someone still is working on this to make sure it's
> fixed in bookworm?

I'll take care of it.

> I guess the first step is to wait for the package to transition to
> trixie and then do the -pu? I suspect it will be hard to test this in
> trixie since you'd need to upgrade from buster to trixie, right?

Right, it needs some more days. CI reported regressions, which I believe
are unrelated to the issue and hand the fix. As of now it should migrate
within five days.

Regarding the test: I'll seek comments of the Ruby team before filling
the -pu; I believe the risk of regressions should be fairly low, as
arel, as described, has been part of activerecord since quite some time.
I'll test this especially in combination with schleuder, which exposed
this issue; to ease future maintenance and increase the chances of
spotting these issues earlier, ideally before release, I added a
"piuparts multi distro upgrade" test job to the Salsa CI [1].

I'll keep this bug updated.

Cheers,
Georg


[1] 
https://salsa.debian.org/ruby-team/schleuder/-/commit/08fd9a91a938346f5cad3cf216f8225b6f6cdd0e

Bug#1036950: schleuder: fails to upgrade from 'buster': insufficient dependency on ruby-activerecord (>= 2:6)

[Georg Faerber]

Hi,

On 23-06-23 20:14:59, Georg Faerber wrote:
> Unfortunately, up until now, there wasn't a proposed update targeting
> bullseye.
> 
> Andreas, how do you want to proceed? Do you have any spare cycles to
> handle this? This would be great -- but please don't hesitate to tell me
> if that's not the case, if so, I'll take over.

The pu targeting bullseye is now tracked via #1039020.

Cheers,
Georg

Bug#1039020: bullseye-pu: package schleuder/3.6.0-3+deb11u2

[Georg Faerber]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: gitcom...@henk.geekmail.org
Control: affects -1 + src:schleuder

Dear release team,

[ Reason ]
Missing versioning of the ruby-activerecord dependency might lead to
failing upgrades from buster to bullseye if done in two stages, in
contrast to only one stage. This issue was reported by Hendrik Jäger and
Andreas Beckmann, both privately and in Debian via #1036950.

It was fixed in unstable via 4.0.3-8.

[ Impact ]
Severe, as upgrades might fail, depending on how these are done.

[ Tests ]
Tests were done both manually and via Salsa CI. Additionally, to ease
future maintenance and ensure upgrades work as expected, a new "piuparts
multi distro upgrade" CI test job was introduced. [2]

[ Risks ]
There should be none, I believe.

[ 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 stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Add missing versioning on ruby-activerecord dependency, to ensure
correct ordering during upgrades.

For details, see the attached debdiff of 3.6.0-3+deb11u1, as currently
present in bullseye, and 3.6.0-3+deb11u2.

Thanks for your work!

Cheers,
Georg


[1] 
https://salsa.debian.org/ruby-team/schleuder/-/commit/08fd9a91a938346f5cad3cf216f8225b6f6cdd0e
diff -Nru schleuder-3.6.0/debian/changelog schleuder-3.6.0/debian/changelog
--- schleuder-3.6.0/debian/changelog	2021-12-26 16:28:29.0 +
+++ schleuder-3.6.0/debian/changelog	2023-06-24 15:02:25.0 +
@@ -1,3 +1,14 @@
+schleuder (3.6.0-3+deb11u2) bullseye; urgency=medium
+
+  * debian/control:
+- Add missing versioning on ruby-activerecord dependency. Before, upgrades
+  from buster to bullseye might have failed if done in two stages, in
+  contrast to only one stage, which worked as expected. Thanks to
+  Hendrik Jäger and Andreas Beckmann for reporting this issue.
+  (Closes: #1036950)
+
+ -- Georg Faerber   Sat, 24 Jun 2023 15:02:25 +
+
 schleuder (3.6.0-3+deb11u1) bullseye; urgency=medium
 
   * debian/patches:
diff -Nru schleuder-3.6.0/debian/control schleuder-3.6.0/debian/control
--- schleuder-3.6.0/debian/control	2021-12-26 16:28:29.0 +
+++ schleuder-3.6.0/debian/control	2023-06-24 15:02:25.0 +
@@ -39,7 +39,7 @@
  lsb-base,
  rake,
  ruby | ruby-interpreter,
- ruby-activerecord,
+ ruby-activerecord (>= 2:6~),
  ruby-charlock-holmes,
  ruby-gpgme,
  ruby-mail,

Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='

[Georg Faerber]

Hi,

On 23-06-24 14:58:21, Andreas Beckmann wrote:
> Shouldn't these conflicts rather be in ruby-activerecord?

Yes, I agree, that's the correct place.

> As I understand the history, arel has been merged into activerecord (5 years
> ago, probably version 6.0.x) and the "old" arel 9 is no longer compatible
> with current activerecord 6.1.x. This is probably unrelated to schleuder
> (which only exposes the bug).

That's my understanding as well.

> Interestingly this didn't happen on buster->bullseye upgrades, but perhaps
> arel 9 was still compatible with activerecord 6.0.x.

Yeah, I wondered about this also, but I'm unsure why is that, so far.

> Should ruby-arel be RM:ed?
> Note: one reverse build dependency
> # Broken Build-Depends:
> ruby-premailer-rails: ruby-arel

Yes -- I sent a mail about this to the Ruby team, see [1] for details.

> I'll give it a try... yes, the conflict against ruby-arel fixes the
> upgrade path.

Great, thanks.

So, given the above, I believe this bug should be reassigned to
ruby-activerecord, and schleuder should be marked as affected? Also, I
guess, as this issue is not specific to schleuder, probably more
packages which rely on ruby-activerecord are affected.

I'll prepare a ruby-activerecord proposed-update targeting bookworm.

Cheers,
Georg


[1] https://lists.debian.org/debian-ruby/2023/06/msg4.html

Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='

[Georg Faerber]

Control: tag -1 + patch

Hi,

Thanks for the report!

On 23-06-23 11:20:28, Andreas Beckmann wrote:
> Package: schleuder
> 
> during a test with piuparts I noticed your package fails to upgrade
> from 'buster' to 'bullseye' to 'bookworm'.
> It installed fine in 'buster', and upgraded to 'bullseye'
> successfully, but then the upgrade to 'bookworm' failed.

I believe that's caused by ruby-arel, the attached patches fix the issue
in my tests.

Andreas, are you able to test these in your environment?

All the best,
Georg
>From 45bc5cfff9adbacef1174d6bb9cd49ba8a90d860 Mon Sep 17 00:00:00 2001
From: Georg Faerber 
Date: Sat, 24 Jun 2023 00:14:47 +
Subject: [PATCH 1/2] debian/control: add Conflicts: ruby-arel

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 0f08e89..80a6f0c 100644
--- a/debian/control
+++ b/debian/control
@@ -32,6 +32,7 @@ Rules-Requires-Root: no
 
 Package: schleuder
 Architecture: all
+Conflicts: ruby-arel,
 Depends: adduser,
  cron | cron-daemon,
  default-mta | postfix | mail-transport-agent,
-- 
2.30.2

>From 009d8af740408deccafd477bbbeaf8eaa6d54ec1 Mon Sep 17 00:00:00 2001
From: Georg Faerber 
Date: Sat, 24 Jun 2023 00:15:10 +
Subject: [PATCH 2/2] debian/changelog: Debian release 4.0.3-8

---
 debian/changelog | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index edb2aa8..9bda664 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+schleuder (4.0.3-8) unstable; urgency=medium
+
+  * debian/control:
+- Declare that schleuder conflicts with ruby-arel. Before, database
+  migration failed during an upgrade, if ruby-arel was installed.
+  (Closes: #1038935)
+
+ -- Georg Faerber   Sat, 24 Jun 2023 00:05:14 +
+
 schleuder (4.0.3-7) unstable; urgency=medium
 
   * Team upload
-- 
2.30.2

Bug#1036950: schleuder: fails to upgrade from 'buster': insufficient dependency on ruby-activerecord (>= 2:6)

[Georg Faerber]

Control: tag -1 + confirmed bullseye
Control: X-Debbugs-CC: gitcom...@henk.geekmail.org

Hi,

Thanks for reporting this, and sorry for my delay in answering:

On 23-06-23 09:34:13, Andreas Beckmann wrote:
> Followup-For: Bug #1036950
> Control: tag -1 patch
> Control: retitle -1 schleuder: fails to upgrade from 'buster': insufficient 
> dependency on ruby-activerecord (>= 2:6)
> 
> I'm currently testing the attached patch ...

This makes sense -- thanks a lot. Actually, Hendrik Jäger (Cc:ed)
reported this issue and provided a patch [1], which was uploaded to
unstable on 2022/12/26 via 4.0.3-7. After a review of the patch, I also
noticed this only targeted Build-Depends, but not Depends.

Unfortunately, up until now, there wasn't a proposed update targeting
bullseye.

Andreas, how do you want to proceed? Do you have any spare cycles to
handle this? This would be great -- but please don't hesitate to tell me
if that's not the case, if so, I'll take over.

Also, another, related question, looking at #1038935, which will require
an update targeting bookworm: I assume, as Debian, qua definition, only
supports upgrades from one release to the next, fixing the
ruby-activerecord issue in bullseye is sufficient?

All the best,
Georg


[1] 
https://salsa.debian.org/ruby-team/schleuder/-/commit/307f8f5e4125dec9d3a9b2bce5a721394c9657fa

Bug#1037086: dropbear-initramfs: /etc/dropbear/initramfs/dropbear_dss_host_key file not generated

[Georg Gast]

Package: dropbear-initramfs
Version: 2022.83-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
One of my systems did not start and landed in rescue shell. I wanted to install
dropbear-initramfs and enable ssh access for rescue target. I installed it and
configured it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Updated initramfs and created symlinks
/etc/dropbear/dropbear_ecdsa_host_key ->
/etc/dropbear/initramfs/dropbear_ecdsa_host_key
/etc/dropbear/dropbear_ed25519_host_key ->
/etc/dropbear/initramfs/dropbear_ed25519_host_key
/etc/dropbear/dropbear_rsa_host_key ->
/etc/dropbear/initramfs/dropbear_rsa_host_key

DROPBEAR_OPTIONS="-FEsjk"

But dropbear did not start as it was complaining about the missing dss host
key. I generated a new dss key and added the symlink

dropbearkeygen -t dss -f /etc/dropbear/initramfs/dropbear_dss_host_key
/etc/dropbear/dropbear_dss_host_key ->
/etc/dropbear/initramfs/dropbear_dss_host_key

Updated initramfs, reboot into rescue

   * What was the outcome of this action?
dropbear did NOT start.

If i delete /etc/dropbear/initramfs/dropbear_dss_host_key and generate a new
one
dropbearkeygen -t dss -f /etc/dropbear/initramfs/dropbear_dss_host_key
in the resuce shell dropbear starts.


Info:
-

georg@nas-dsm:~$ uname -a
Linux nas-dsm 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)
x86_64 GNU/Linux
georg@nas-dsm:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;
georg@nas-dsm:~$ apt-cache policy dropbear-initramfs
dropbear-initramfs:
  Installiert:   2022.83-1
  Installationskandidat: 2022.83-1
  Versionstabelle:
 *** 2022.83-1 500
500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status
georg@nas-dsm:~$ tree /etc/dropbear/
/etc/dropbear/
├── dropbear_dss_host_key -> initramfs/dropbear_dss_host_key
├── dropbear_ecdsa_host_key -> initramfs/dropbear_ecdsa_host_key
├── dropbear_ed25519_host_key -> initramfs/dropbear_ed25519_host_key
├── dropbear_rsa_host_key -> initramfs/dropbear_rsa_host_key
└── initramfs
├── authorized_keys
├── dropbear.conf
├── dropbear_dss_host_key
├── dropbear_ecdsa_host_key
├── dropbear_ed25519_host_key
└── dropbear_rsa_host_key

2 directories, 10 files





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

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
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 dropbear-initramfs depends on:
ii  busybox-static [busybox]  1:1.35.0-4+b3
pn  dropbear-bin  
ii  initramfs-tools   0.142
ii  udev  252.6-1

Versions of packages dropbear-initramfs recommends:
ii  cryptsetup-initramfs  2:2.6.1-4~deb12u1

dropbear-initramfs suggests no packages.

Bug#1035020: Info received (Bug#1035020: Acknowledgement (okular scans my homefolder without any need))

[Georg Gast]

Found out that these file paths are stored in
~/.config/okularrc

Bug#1035020: Acknowledgement (okular scans my homefolder without any need)

[Georg Gast]

I found out that these documents are stored in recentdocuments:/ url
in dolphin. I disabled the "Zuletzt geöffnete Dokumente" (last opened
files) in the settings but it still tries to open these files. I also
disabled in the plasma search category "Zuletzt geöffnete Dokumente"
but no change.

Bug#986881: iw: Incorporate useful bits of crda?

[Georg Müller]

On Mon, 1 Nov 2021 15:13:50 +0100 Paride Legovini  wrote:

Control: reassign -1 wireless-regdb

Thanks for this detailed and informative bug report. I think the udev
rule belongs to wireless-regdb, as the rule isn't really useful without
the regulatory db, and I don't think we want to make iw Recommend
wireless-regdb. If wireless-regdb adopts the rule then it should at
least Recommend iw, which I think makes sense.

I'm reassigning this bug to wireless-regdb, but I'm open for further
discussion.

Cheers,

Paride


Is there any progress on this? Now that debian begins stabilizing bookworm
release, there is no setregdomain mechanism included.

Fedora has a nice udev script which - if no country is set explicitly - sets
the regulatory domain from the configured time zone:

https://src.fedoraproject.org/rpms/wireless-regdb/blob/rawhide/f/setregdomain

If there should not be a hard dependency on iw, this might need a separate check
or a warning...

Best regards,
Georg

Bug#1029516: Small patch

[Georg Gast]

Needed i just a small patch that makes it at least usable.

https://github.com/Steveorevo/phppgadmin/commit/6ae0b7b99b34adb85d253a0c545a220c54180f8e

Bug#1029516: phppgadmin: postgresql-15 not supported

[Georg]

Package: phppgadmin
Version: 7.13.0+dfsg-2
Severity: important
Tags: upstream
X-Debbugs-Cc: ge...@schorsch-tech.de

Dear Maintainer,

   * What led up to the situation?
Debian/bookwork includes postgresql-15.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
phppgadmin 7.13.0 does not support postgresql-15. So i downloaded a fork from
https://github.com/ReimuHakurei/phpPgAdmin and activated in on my database
server.

   * What was the outcome of this action?
Problem solved. Can now connect to the postgresql-15 server.

   * What outcome did you expect instead?
Problem solved. Can now connect to the postgresql-15 server.



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: amd64

Kernel: Linux 6.1.0-1-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
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 phppgadmin depends on:
ii  libapache2-mod-php  2:8.2+93
ii  libapache2-mod-php8.2 [libapache2-mod-php]  8.2.1-1
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
pn  libphp-adodb
ii  php-common  2:93
ii  php-mbstring2:8.2+93
ii  php-pgsql   2:8.2+93
ii  php8.2-mbstring [php-mbstring]  8.2.1-1
ii  php8.2-pgsql [php-pgsql]8.2.1-1

Versions of packages phppgadmin recommends:
ii  apache2 [httpd]  2.4.55-1

Versions of packages phppgadmin suggests:
pn  postgresql  
pn  postgresql-doc  
pn  slony1-bin  

Bug#995940: Shim contains a bug that prevents me from installing Debian

[Georg Faerber]

Hi all,

I'm running into this problem as well with a Fujitsu Lifebook E549, with
both the Debian 11 and Debian 12 network install iso.

Is anyone working on this, or has found a workaround?

Thanks & all the best,
Georg

Bug#1023557: rygel: consider After=network.target in rygel.service for lingering

[Jens Georg]

On Mi, Dez 21 2022 at 13:34:15 +, Barak A. Pearlmutter 
 wrote:

Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to
FF0E::C: Error sending message: Network is unreachable
Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to
FF0E::C: Error sending message: Network is unreachable
Dec 21 09:00:20 sweat rygel[853]: Error creating GUPnP context: Failed
to bind socketError binding to address
[fe80::4f84:2ae9:bb96:f67f%3]:1900: Cannot assign requested address


This is upstream ticket 
 - I believe I have 
fixed that with the release of GUPnP 1.6.3.


Sorry for resending, debian bugtracker does not love my primary mail 
address

Bug#1025508: [Pkg-privacy-maintainers] Bug#1025508: onionprobe: config and examples installed to unusual locations

[Georg Faerber]

Control: forwarded -1 
https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/65
Control: tags -1 + upstream

Hi Stefano,

On 22-12-05 21:13:43, Stefano Rivera wrote:
> The next upload of dh-python will change the layout of onionprobe's
> installed data:
> 
> [...]

Thanks for your report.

Cheers,
Georg

Bug#1024594: RFP: nginx-unit -- polyglot app server, a reverse proxy, and a static file server

[Georg Faerber]

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org

Package name: nginx-unit
Version : 1.28.0
Upstream Author : Nginx team members and contributors
URL : https://github.com/nginx/unit
License : Apache Software License (ASL) 2.0
Programming Lang: C
Description : polyglot app server, reverse proxy, and static file server

nginx-unit is a lightweight and versatile open-source server that has three
core capabilities:

* it is an HTTP reverse proxy,
* a web server for static media assets,
* and an application server that runs code in seven languages.

Key Features

Flexibility

* The entire configuration is managed dynamically over HTTP via a RESTful JSON 
API
* Updates to the configuration are performed granularly at runtime with zero 
interruption
* Requests are routed between static content, upstream servers, and local apps
* Request filtering and dispatching uses elaborate matching rules that allow 
regular expressions
* Apps in multiple languages and language versions run side by side
* Common language-specific APIs for all supported languages run seamlessly
* Upstream server groups provide dynamic load balancing using a weighted 
round-robin method
* Originating IP identification supports X-Forwarded-For and similar header 
fields

Performance

* Requests are asynchronously processed in threads with efficient event loops 
(epoll, kqueue)
* Syscalls and data copy operations are kept to a necessary minimum
* 10,000 inactive HTTP keep-alive connections take up only a few MBs of memory
* Router and app processes rely on low-latency IPC built with lock-free queues 
over shared memory
* Built-in statistics provide insights into Unit’s performance
* The number of per-app processes is defined statically or scales preemptively 
within given limits
* App and instance usage statistics are collected and exposed via the API
* Multithreaded request processing is supported for Java, Perl, Python, and 
Ruby apps

Security & Robustness

* Client connections are handled by a separate non-privileged router process
* Low-resource conditions (out of memory or descriptors) and app crashes are 
handled gracefully
* SSL/TLS with SNI, session cache and tickets is integrated (OpenSSL 1.0.1 and 
later)
* Different apps are isolated in separate processes
* Apps can be additionally containerized with namespace and file system 
isolation
* Static file serving benefits from chrooting, symlink and mount point 
traversal restrictions

Supported App Languages

* Binary-compiled languages in general: using the embedded libunit library
* Go: by overriding the http module
* JavaScript (Node.js): by automatically overloading the http and websocket 
modules
* Java: using the Servlet Specification 3.1 and WebSocket APIs
* Perl: using PSGI
* PHP: using a custom SAPI module
* Python: using WSGI or ASGI with WebSocket support
* Ruby: using the Rack API

Upstream docs available via https://unit.nginx.org/.

Bug#1023557: rygel: consider After=network.target in rygel.service for lingering

[Jens Georg]

Hi Barak,

Rygel should be able to cope with this situation. If it does not not,
then this is a bug that needs looking into.

Please provide the output of journalctl -u rygel.service and also feel
free to take this upstream at
https://gitlab.gnome.org/GNOME/rygel/issues

Bug#1021732: [Pkg-privacy-maintainers] Bug#1021732: Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...

[Georg Faerber]

Hi nodens,

On 22-10-25 09:16:29, Clément Hermann wrote:
> Do you mind if I cherry-pick the upstream fix and upload today ?
> This is blocking the perl 5.36 transition.

I do not, please do, and thanks in advance. Please push your changes,
including the tag.

Cheers,
Georg

Bug#1019682: [DRE-maint] Bug#1019682: Bug#1019682: schleuder: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error: expect(error).to be_empty

[Georg Faerber]

Hi,

After further debugging, I've now got the following backtrace:

a bounce message is received


:85:in 
`require': cannot load such file -- charlock_holmes (LoadError)
from 
:85:in 
`require'
from /<>/lib/schleuder/cli.rb:4:in `'
from 
:85:in 
`require'
from 
:85:in 
`require'
from bin/schleuder:12:in `'
from bounce example

However, the following works as expected

# ruby -v -e "require 'charlock_holmes'; puts CharlockHolmes::VERSION"
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux-gnu]
0.7.7

so I'm still at loss.

Cheers,
Georg

Bug#1019682: [DRE-maint] Bug#1019682: schleuder: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error: expect(error).to be_empty

[Georg Faerber]

Control: tags -1 + help

Hi Antonio, all,

Thanks for your report. I had a look, and I'm able to reproduce locally if
building the package, although so far I haven't been able to find out what is
causing this. I would be happy if someone is able to support me in debugging
this.

Looking at [1], which fails in the same way, I noticed:

Ignoring bcrypt-3.1.17 because its extensions are not built. Try: gem pristine 
bcrypt --version 3.1.17
Ignoring charlock_holmes-0.7.7 because its extensions are not built. Try: gem 
pristine charlock_holmes --version 0.7.7
Ignoring debug-1.4.0 because its extensions are not built. Try: gem pristine 
debug --version 1.4.0
Ignoring rbs-2.1.0 because its extensions are not built. Try: gem pristine rbs 
--version 2.1.0
Ignoring sdbm-1.0.0 because its extensions are not built. Try: gem pristine 
sdbm --version 1.0.0
Ignoring thin-1.8.0 because its extensions are not built. Try: gem pristine 
thin --version 1.8.0
Ignoring bcrypt-3.1.17 because its extensions are not built. Try: gem pristine 
bcrypt --version 3.1.17
Ignoring charlock_holmes-0.7.7 because its extensions are not built. Try: gem 
pristine charlock_holmes --version 0.7.7
Ignoring debug-1.4.0 because its extensions are not built. Try: gem pristine 
debug --version 1.4.0
Ignoring rbs-2.1.0 because its extensions are not built. Try: gem pristine rbs 
--version 2.1.0
Ignoring sdbm-1.0.0 because its extensions are not built. Try: gem pristine 
sdbm --version 1.0.0
Ignoring thin-1.8.0 because its extensions are not built. Try: gem pristine 
thin --version 1.8.0

Some of these are direct dependencies of Schleuder.

I'm mentioning this, because some days ago, [2] reported different errors:

Failure/Error: require 'thin'
LoadError:
  cannot load such file -- thin

To make all of this even more interesting: [3] reports no errors.

I'm wondering if different build environments are of relevance here.

Any clue, anyone?

Thanks in advance,
all the best,
Georg


[1] 
https://buildd.debian.org/status/fetch.php?pkg=schleuder=all=4.0.3-4.1=1666457954=0
[2] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/schleuder.html
[3] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/schleuder/27432900/log.gz

Bug#1021732: [Pkg-privacy-maintainers] Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...

[Georg Faerber]

Control: forwarded -1 https://0xacab.org/jvoisin/mat2/-/issues/178
Control: tags -1 + fixed-upstream upstream

Hi Paul,

On 22-10-13 19:52:35, Paul Gevers wrote:
> With a recent upload of libimage-exiftool-perl the autopkgtest of mat2
> fails in testing when that autopkgtest is run with the binary packages
> of libimage-exiftool-perl from unstable.

Thanks for your report.

Cheers,
Georg

Bug#1014814: [Pkg-privacy-maintainers] Bug#1014814: ITP: onionprobe -- test/monitor tool for Tor Onion Services sites

[Georg Faerber]

Control: tags -1 + pending

Packaging lives at [1], initial upload done, now in NEW.

Cheers,
Georg


[1] https://salsa.debian.org/pkg-privacy-team/onionprobe

Bug#1014814: ITP: onionprobe -- test/monitor tool for Tor Onion Services sites

[Georg Faerber]

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-privacy-maintain...@lists.alioth.debian.org

Package name: onionprobe
Version : 1.0.0
Upstream Author : Silvio Rhatto 
URL : https://gitlab.torproject.org/tpo/onion-services/onionprobe
License : GNU General Public License v3
Programming Lang: Python
Description : test/monitor tool for Tor Onion Services sites

Onionprobe is a tool for testing and monitoring the status of Tor Onion
Services sites.

It can run a single time or continuously to probe a set of onion
services endpoints and paths, optionally exporting to Prometheus.

This package will be maintained within the Debian Privacy Tools
Maintainers team.

Bug#1014812: RFP: tusd -- implementation of the tus resumable upload protocol

[Georg Faerber]

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist

Package name: tusd
Version : 1.9.0
Upstream Author : Transloadit Ltd and Contributors
URL : https://github.com/tus/tusd
License : MIT
Programming Lang: Go
Description : implementation of the tus resumable upload protocol 

tusd is the official reference implementation of the tus resumable
upload protocol. The protocol specifies a flexible method to upload
files to remote servers using HTTP. The special feature is the ability
to pause and resume uploads at any moment allowing to continue
seamlessly after e.g. network interruptions.

It is capable of accepting uploads with arbitrary sizes and storing them
locally on disk, on Google Cloud Storage or on AWS S3 (or any other
S3-compatible storage system). Due to its modularization and
extensibility, support for nearly any other cloud provider could easily
be added to tusd.

Bug#1009775: ITP: ruby-net-smtp -- library to send Internet mail via SMTP, the Simple Mail Transfer Protocol

[Georg Faerber]

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist
X-Debbugs-CC: debian-r...@lists.debian.org
Control: affects -1 schleuder
Control: block -1 by 1009774

Package name: ruby-net-smtp
Version : 0.3.1
Upstream Author : Yukihiro Matsumoto, Minero Aoki
URL : https://github.com/ruby/net-smtp
License : BSD-2-clause
Programming Lang: Ruby
Description : library to send Internet mail via SMTP, the Simple Mail 
Transfer Protocol

This package will provide functionality to send Internet mail via SMTP,
the Simple Mail Transfer Protocol. It used to be part of the Ruby
standard library before Ruby 3.1, and was extracted to a standalone
package.

It depends on ruby-net-protocol.

This package will be maintained within the Debian Ruby team.

Bug#1009774: ITP: ruby-net-protocol -- Internal class for the other net-* libraries

[Georg Faerber]

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist
X-Debbugs-CC: debian-r...@lists.debian.org
Control: affects -1 schleuder

Package name: ruby-net-protocol
Version : 0.1.3
Upstream Author : Yukihiro Matsumoto, Minero Aoki
URL : https://github.com/ruby/net-protocol
License : BSD-2-clause
Programming Lang: Ruby
Description : internal class for the other net-* libraries

This package will provide an internal class for the other net-*
libraries, for example ruby-net-smtp. It used to be part of the Ruby
standard library before Ruby 3.1, and was extracted to a standalone
package.

It will become a dependency of ruby-net-smtp.

This package will be maintained within the Debian Ruby team.

Bug#1002652: bullseye-pu: package schleuder/3.6.0-3+deb10u1

[Georg Faerber]

On 22-02-19 17:54:40, Adam D. Barratt wrote:
> Please go ahead; sorry for the delay.

Uploaded, thanks.

Cheers,
Georg

Bug#993350: xsane: Scanimage detects scanner but Xsane won't start it

[Hans Georg Colle]

Hi,
after updating libsane1 yesterday xsane works as expected.
Georg

Bug#1002418: [Pkg-privacy-maintainers] Bug#1002418: marked as done (mat2: FTBFS: AssertionError: 'TransparentColor' not found in {})

[Georg Faerber]

Hi Utkarsh,
 
Thanks for your upload.
 
Could you please push the changes you did to the git repo?
 
Thanks,
cheers,
Georg

Bug#1002418: [Pkg-privacy-maintainers] Bug#1002418: marked as done (mat2: FTBFS: AssertionError: 'TransparentColor' not found in {})

[Georg Faerber]

Hi Utkarsh,

Thanks for your upload.

Could you please push the changes you did to the git repo?

Thanks,
cheers,
Georg

Bug#1003156: dnsmasq: SIGSEV when running as PROXYDHCP and target is not listed inn config file

[Georg Gast]

I may have wrote misleading:

It need these options to tag the architecture
dhcp-vendorclass=ARM32,PXEClient:Arch:00010
dhcp-vendorclass=ARM64,PXEClient:Arch:00011
and these options to send them the PROXYDHCP
dhcp-boot=tag:ARM32,default,192.168.160.19
dhcp-boot=tag:ARM64,default,192.168.160.19

Bug#1003156: dnsmasq: SIGSEV when running as PROXYDHCP and target is not listed inn config file

[Georg Gast]

Package: dnsmasq
Version: 2.85-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I try to boot various SBC computer to boot from NFS. I have a FRITZBox as dhcp
server and i compiled u boot to accept the serverip from the PROXYDHCP. dnsmasq
needs the
dhcp-boot=tag:ARM32,default,192.168.160.19
dhcp-boot=tag:ARM64,default,192.168.160.19
to tag the connections. When these option for the specified architecture is not
present, dnsmasq gets a SIGSEV when such a architecture boots.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to get a meaningful backtrace and followed
https://wiki.debian.org/HowToGetABacktrace but i just got

0x7f819e8b73c3 in __GI___poll (fds=0x5642e7458400, nfds=7, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
Download failed: Das Argument ist ungültig.  Continuing without source file
./io/../sysdeps/unix/sysv/linux/poll.c.
29  ../sysdeps/unix/sysv/linux/poll.c: Datei oder Verzeichnis nicht
gefunden.
(gdb)
(gdb) bt
#0  0x7f819e8b73c3 in __GI___poll (fds=0x5642e7458400, nfds=7, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x5642e7002473 in ?? ()
#2  0x7f819e7ead0a in __libc_start_main (main=0x5642e7000d60, argc=11,
argv=0x7ffc0cef7608, init=, fini=,
rtld_fini=, stack_end=0x7ffc0cef75f8)
at ../csu/libc-start.c:308
#3  0x5642e700337a in ?? ()
(gdb) info threadsa
Undefined info command: "threadsa".  Try "help info".
(gdb) info threads
  Id   Target IdFrame
* 1Thread 0x7f819e0dfcc0 (LWP 241194) "dnsmasq" 0x7f819e8b73c3 in
__GI___poll (fds=0x5642e7458400, nfds=7, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
(gdb) bt
#0  0x7f819e8b73c3 in __GI___poll (fds=0x5642e7458400, nfds=7, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x5642e7002473 in ?? ()
#2  0x7f819e7ead0a in __libc_start_main (main=0x5642e7000d60, argc=11,
argv=0x7ffc0cef7608, init=, fini=,
rtld_fini=, stack_end=0x7ffc0cef75f8)
at ../csu/libc-start.c:308
#3  0x5642e700337a in ?? ()


*** End of the template - remove these template lines ***

This could be a problem for users thar relay on dnsmasq to work properly even
if there comes a packet from an architekture they dont handle. dnsmasq would
stop working.

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-
debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads)
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 dnsmasq depends on:
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  runit-helper 2.10.3

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
ii  openresolv [resolvconf]  3.12.0-1

-- Configuration Files:
/etc/dnsmasq.conf changed:
port=0
log-dhcp
log-debug
log-queries
enable-tftp
tftp-root=/srv/netboot/
dhcp-vendorclass=BIOS,PXEClient:Arch:0
dhcp-vendorclass=UEFI32,PXEClient:Arch:6
dhcp-vendorclass=UEFI,PXEClient:Arch:7
dhcp-vendorclass=UEFI64,PXEClient:Arch:9
dhcp-vendorclass=ARM32,PXEClient:Arch:00010
dhcp-vendorclass=ARM64,PXEClient:Arch:00011
dhcp-boot=UEFI32,i386-efi/ipxe.efi,,192.168.160.19
dhcp-boot=UEFI,ipxe.efi,,192.168.160.19
dhcp-boot=UEFI64,ipxe.efi,,192.168.160.19
dhcp-boot=tag:ARM32,default,192.168.160.19
dhcp-boot=tag:ARM64,default,192.168.160.19
pxe-service=1, "Boot CSA 1", efi64/syslinux.efi
dhcp-range=192.168.160.1,proxy

Bug#1002652: bullseye-pu: package schleuder/3.6.0-3+deb11u1

[Georg Faerber]

Control: retitle -1 bullseye-pu: package schleuder/3.6.0-3+deb11u1
--

Hi,

The proposed package used an incorrect versioning scheme targeting
buster, not bullseye.

The attached debdiff is fixed in this regard.

Sorry for this noise.

Cheers,
Georg
diffstat for schleuder-3.6.0 schleuder-3.6.0

 changelog   |   12 ++
 patches/0031-db-change-boolean-values-to-integers.patch |   77 
 patches/series  |1 
 3 files changed, 90 insertions(+)

diff -Nru schleuder-3.6.0/debian/changelog schleuder-3.6.0/debian/changelog
--- schleuder-3.6.0/debian/changelog2021-07-29 20:36:52.0 +
+++ schleuder-3.6.0/debian/changelog2021-12-26 16:28:29.0 +
@@ -1,3 +1,15 @@
+schleuder (3.6.0-3+deb11u1) bullseye; urgency=medium
+
+  * debian/patches:
+- Pull in upstream patch to migrate boolean values to integers, if the
+  ActiveRecord SQLite3 connection adapter is in use. Since ActiveRecord >=
+  6.0, the relevant code relies on boolean serialization to use 1 and 0,
+  but does not natively recognize 't' and 'f' as booleans were previously
+  serialized. This change made existing mailing lists fail, if people were
+  upgrading buster to bullseye. (Closes: #100262)
+
+ -- Georg Faerber   Sun, 26 Dec 2021 16:28:29 +
+
 schleuder (3.6.0-3) unstable; urgency=medium
 
   * debian/patches:
diff -Nru 
schleuder-3.6.0/debian/patches/0031-db-change-boolean-values-to-integers.patch 
schleuder-3.6.0/debian/patches/0031-db-change-boolean-values-to-integers.patch
--- 
schleuder-3.6.0/debian/patches/0031-db-change-boolean-values-to-integers.patch  
1970-01-01 00:00:00.0 +
+++ 
schleuder-3.6.0/debian/patches/0031-db-change-boolean-values-to-integers.patch  
2021-12-26 16:28:29.0 +
@@ -0,0 +1,77 @@
+Description: DB: change boolean values to integers
+  Since ActiveRecord >= 6.0, the SQLite3 connection adapter relies on boolean
+  serialization to use 1 and 0, but does not natively recognize 't' and 'f' as
+  booleans were previously serialized. Accordingly, this patch handles
+  conversion via a database migration of both column defaults and stored data
+  provided by a user.
+Author: Georg Faerber 
+Origin: upstream
+Bug: https://0xacab.org/schleuder/schleuder/-/issues/505
+Applied-Upstream: 9ee12c4a1d6604c860c44073b99d8258bb4bc0ae
+Last-Update: 2021-12-25
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: schleuder/db/migrate/20211106112020_change_boolean_values_to_integers.rb
+===
+--- /dev/null  1970-01-01 00:00:00.0 +
 schleuder/db/migrate/20211106112020_change_boolean_values_to_integers.rb   
2021-12-26 17:28:42.468530957 +
+@@ -0,0 +1,46 @@
++# Since ActiveRecord >= 6.0, the SQLite3 connection adapter relies on boolean
++# serialization to use 1 and 0, but does not natively recognize 't' and 'f' as
++# booleans were previously serialized.
++#
++# Accordingly, this migration handles conversion of both column defaults and
++# stored data provided by a user.
++#
++# In contrast to other migrations, only a 'forward' method is provided, a
++# mechanism to 'reverse' is not. Given the nature of this migration, the later
++# is not really required.
++#
++# Unfortunately, we missed this breaking change when bumping ActiveRecord to 
>=
++# 6.0 in Schleuder version 4.0. This caused quite some work upstream, but also
++# in downstream environments and, last but not least, at the side of users.
++#
++# We should extend our CI to explicitly test, and ensure things work as
++# expected, if running a Schleuder setup in real world. As of now, we don't
++# ensure data provided by a user in Schleuder version x still works after
++# upgrading to version y.
++
++class ChangeBooleanValuesToIntegers < ActiveRecord::Migration[6.0]
++  class Lists < ActiveRecord::Base
++  end
++
++  class Subscriptions < ActiveRecord::Base
++  end
++
++  def up
++[Lists, Subscriptions].each do |table|
++  unless 
table.connection.is_a?(ActiveRecord::ConnectionAdapters::SQLite3Adapter)
++return
++  end
++
++  bool_columns_defaults = table.columns.select { |column| column.type == 
:boolean }.map{ |column| [column.name, column.default] }
++
++  bool_columns_defaults.each do |column_name, column_default|
++column_bool = 
ActiveRecord::Type::Boolean.new.deserialize(column_default)
++
++change_column_default :"#{table.table_name}", :"#{column_name}", 
column_bool
++
++table.where("#{column_name} = 'f'").update_all("#{column_name}": 0)
++table.where("#{column_name} = 't'").update_all("#{column_name}": 1)
++  end
++end
++  end
++end
+Index: schleuder/db/schema.rb
+===
+--- schl

Bug#1000335: mmanon plugin: IPv6 anonymization partially broken

[Georg Faerber]

Hi again,

On 21-12-26 23:52:58, Georg Faerber wrote:
> I've built a package now to ease this, and uploaded it to [1]. This
> file is not signed, but this email is. The sha256sum of said file
> should be 1edd0e09abf870146da441e7737fe78f634351c9cbbd0abdb46962911fe38e03.

This package used an incorrect versioning scheme targeting buster, not
bullseye.

A fixed package is available via [1], sha256sum should be
e6ccd338ebabcfea2014972e7b72e83ceb1e71f6a4ef9e3f32e0c718ece10311.

Cheers,
Georg

[1] 
https://people.debian.org/~georg/rsyslog/rsyslog_8.2102.0-2+deb11u1_amd64.deb


signature.asc
Description: PGP signature

Bug#1000335: mmanon plugin: IPv6 anonymization partially broken

[Georg Faerber]

Hi all,

On 21-12-26 23:08:01, Georg Faerber wrote:
> Besides, functional testing of this new package still needs to happen.

I've built a package now to ease this, and uploaded it to [1]. This file
is not signed, but this email is. The sha256sum of said file should be
1edd0e09abf870146da441e7737fe78f634351c9cbbd0abdb46962911fe38e03.

I guess it would make sense if interested parties would test this
package, before reaching out to the SRMs.

Cheers,
Georg


[1] 
https://people.debian.org/~georg/rsyslog/rsyslog_8.2102.0-2+deb10u1_amd64.deb


signature.asc
Description: PGP signature

Bug#1000335: mmanon plugin: IPv6 anonymization partially broken

[Georg Faerber]

Hi Michael, all,

On 21-11-30 18:35:36, Michael Biebl wrote:
> I'm very busy atm, but I can try.

I've pushed the proposed upload to the debian/bullseye branch in the
rsyslog repo.

I've cherry-picked your commit
(dfe482df2733940774c8d4f6d7756e5de3ade252) which initially introduced
the fix and the corresponding testbench, but removed the later again, as
the new test script is created with mode 100644, which fails, as the
test setup expects these scripts to be executable.

I'm unsure how to track file permissions via quilt, and a quick research
didn't yield much. Any input how to solve this?

Besides, functional testing of this new package still needs to happen.

Cheers,
Georg

Bug#1002652: bullseye-pu: package schleuder/3.6.0-3+deb10u1

[Georg Faerber]

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

Dear release team,

[ Reason ]
Since ActiveRecord >= 6.0, the SQLite3 connection adapter relies on boolean
serialization to use 1 and 0, but does not natively recognize 't' and 'f' as
booleans were previously serialized. This change makes existing mailing lists
fail, after an upgrade of buster to bullseye, due to the involved ActiveRecord
version bump, as Schleuder isn't able anymore to fetch correct values from the
database.

Unfortunately, we missed this breaking change when bumping ActiveRecord to >=
6.0 recently. This caused quite some work upstream, but also in downstream
environments and, last but not least, at the side of users.

This was reported in Debian via #1002622, and fixed in unstable via 3.6.0-4.

[ Impact ]
Severe, as existing and formerly working setups are left broken, after an
upgrade of buster to bullseye. Manual workarounds do exist, and are documented
upstream [1].

[ Tests ]
Extensive testing happened via upstream CI and multiple, manual tests on
various machines which exhibit this problem. The fix is targeted and worked, in
these tests, as expected.

[ Risks ]
The fix was reviewed upstream to ensure it works as expected, and doesn't cause
any harm. It's guarded to only be effective in setups which makes use of
SQLite3, although that's the default, and probably true for the big majority of
Debian-based setups.

[ 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 stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The fix provided upstream was imported, which adds a database migration to
ensure correct serialization of boolean values, both defaults and
user-provided, if the SQLite3 connection adapter is in use.

Thanks for your work!

Cheers,
Georg


[1] https://0xacab.org/schleuder/schleuder/-/issues/505
diffstat for schleuder-3.6.0 schleuder-3.6.0

 changelog   |   12 ++
 patches/0031-db-change-boolean-values-to-integers.patch |   77 
 patches/series  |1 
 3 files changed, 90 insertions(+)

diff -Nru schleuder-3.6.0/debian/changelog schleuder-3.6.0/debian/changelog
--- schleuder-3.6.0/debian/changelog2021-07-29 20:36:52.0 +
+++ schleuder-3.6.0/debian/changelog2021-12-26 16:28:29.0 +
@@ -1,3 +1,15 @@
+schleuder (3.6.0-3+deb10u1) bullseye; urgency=medium
+
+  * debian/patches:
+- Pull in upstream patch to migrate boolean values to integers, if the
+  ActiveRecord SQLite3 connection adapter is in use. Since ActiveRecord >=
+  6.0, the relevant code relies on boolean serialization to use 1 and 0,
+  but does not natively recognize 't' and 'f' as booleans were previously
+  serialized. This change made existing mailing lists fail, if people were
+  upgrading buster to bullseye. (Closes: #100262)
+
+ -- Georg Faerber   Sun, 26 Dec 2021 16:28:29 +
+
 schleuder (3.6.0-3) unstable; urgency=medium
 
   * debian/patches:
diff -Nru 
schleuder-3.6.0/debian/patches/0031-db-change-boolean-values-to-integers.patch 
schleuder-3.6.0/debian/patches/0031-db-change-boolean-values-to-integers.patch
--- 
schleuder-3.6.0/debian/patches/0031-db-change-boolean-values-to-integers.patch  
1970-01-01 00:00:00.0 +
+++ 
schleuder-3.6.0/debian/patches/0031-db-change-boolean-values-to-integers.patch  
2021-12-26 16:28:29.0 +
@@ -0,0 +1,77 @@
+Description: DB: change boolean values to integers
+  Since ActiveRecord >= 6.0, the SQLite3 connection adapter relies on boolean
+  serialization to use 1 and 0, but does not natively recognize 't' and 'f' as
+  booleans were previously serialized. Accordingly, this patch handles
+  conversion via a database migration of both column defaults and stored data
+  provided by a user.
+Author: Georg Faerber 
+Origin: upstream
+Bug: https://0xacab.org/schleuder/schleuder/-/issues/505
+Applied-Upstream: 9ee12c4a1d6604c860c44073b99d8258bb4bc0ae
+Last-Update: 2021-12-25
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: schleuder/db/migrate/20211106112020_change_boolean_values_to_integers.rb
+===
+--- /dev/null  1970-01-01 00:00:00.0 +
 schleuder/db/migrate/20211106112020_change_boolean_values_to_integers.rb   
2021-12-26 17:28:42.468530957 +
+@@ -0,0 +1,46 @@
++# Since ActiveRecord >= 6.0, the SQLite3 connection adapter relies on boolean
++# serialization to use 1 and 0, but does not natively recognize 't' and 'f' as
++# booleans were previously serialized.
++#
++# Accordingly, this migration handles conversion of both column defaults and
++# stored data provided by a user.
++#
++# In contrast to other migrations, only a '

Bug#1002622: schleuder: ActiveRecord >= 6.0 changes boolean serialization, makes existing mailing lists fail

[Georg Faerber]

Package: schleuder
Version: 3.6.0-3
Severity: grave
Justification: renders package unusable
Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/505
Tags: fixed-upstream

Since ActiveRecord >= 6.0, the SQLite3 connection adapter relies on
boolean serialization to use 1 and 0, but does not natively recognize
't' and 'f' as booleans were previously serialized. This change made
existing mailing lists fail, after people upgraded buster to bullseye,
due to the involved ActiveRecord version bump, as Schleuder isn't able
anymore to fetch correct values from the database.

Unfortunately, we missed this breaking change when bumping ActiveRecord
to >= 6.0 recently. This caused quite some work upstream, but also in
downstream environments and, last but not least, at the side of users.

We should extend our CI to explicitly test, and ensure things work as
expected, if running a Schleuder setup in real world. As of now, we
don't ensure data provided by a user in Schleuder version x still works
after upgrading to version y.

Bug#1002418: [Pkg-privacy-maintainers] Bug#1002418: mat2: FTBFS: AssertionError: 'TransparentColor' not found in {}

[Georg Faerber]

Control: affects -1 libimage-exiftool-perl
Control: forwarded -1 https://0xacab.org/jvoisin/mat2/-/issues/162
--

Hi Lucas,

On 21-12-22 09:13:25, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks for reporting, the error is caused by libimage-exiftool-perl >=
12.37+dfsg-1.

I've forwarded this upstream.

Cheers,
Georg

Bug#1000335: mmanon plugin: IPv6 anonymization partially broken

[Georg Faerber]

Hi all,

Thanks for maintaining rsyslog, and for the recent upload to fix this in
unstable and testing.

I've never dealt, up until now, the packaging of rsyslog, but I deem 
an update in bullseye important, due to the privacy-implications of this
issue.

Accordingly, I'll look into handling this, although it seems a bit late
to still get this into 11.2, ETA 12/18.

Michael, would you be up for a review before reaching out to the SRMs?

Cheers,
Georg

Bug#998232: cargo segv when updating crates.io index

[Georg Brandl]

On Mon, 01 Nov 2021 12:38:41 + "Daniel P. Berrange"
 wrote:

Since about Oct 12th, we have been seeing cargo on Debian 10
crash with a segv when attempting to update crates.io index
in CI jobs.

This was initially seen inside docker container running CI
pipelines in GitLab, but has been reproduced in regular
VM installs too and by multiple people


This seems to be caused by cargo's libgit2.  A workaround is to
add "git" as a build dep and set CARGO_NET_GIT_FETCH_WITH_CLI=true
in cargo's environment or set the corresponding option in
.cargo/config.toml.

Bug#998355: Acknowledgement (samba: Access Time of File is set to the far future: 30828-09-14 04:48:05.477580700 +0200)

[Georg Gast]

I tried to build old samba version from https://git.samba.org/samba.

Version samba-4.11.17. No problem about the time. All like it was on 
buster. The build of version prior 4.11 failed because of some python 
issues.


-

samba-4.12.10

root@TestClient1:/srv/samba# stat Georg_2016.mgz
 Datei: Georg_2016.mgz
 Größe: 20643840Blöcke: 40272  EA Block: 4096   reguläre Datei
 Gerät: fe01h/65025dInode: 537336  Verknüpfungen: 1
Zugriff: (0660/-rw-rw)  Uid: ( 1000/   georg)   Gid: ( 1000/   georg)
Zugriff: 2446-05-11 00:38:55.0 +0200
Modifiziert: 2021-11-03 18:16:37.748463643 +0100
Geändert: 2021-11-03 18:16:37.748463643 +0100
Geburt: 2021-11-03 18:01:03.115693155 +0100

-

samba-4.13.5

root@TestClient1:/srv/samba# stat Georg_2016.mgz
 Datei: Georg_2016.mgz
 Größe: 20643840Blöcke: 40312  EA Block: 4096   reguläre Datei
 Gerät: fe01h/65025dInode: 537336  Verknüpfungen: 1
Zugriff: (0660/-rw-rw)  Uid: ( 1000/   georg)   Gid: ( 1000/   georg)
Zugriff: 2446-05-11 00:38:55.0 +0200
Modifiziert: 2021-11-03 18:26:44.551167646 +0100
Geändert: 2021-11-03 18:26:44.548920728 +0100
Geburt: 2021-11-03 18:01:03.115693155 +0100

-

As i first tried this on a fast build machine (vm) i got the date 
2446-05-11 00:38:55.0 +0200 repeatedly. As i compiled it on the 
real machine i am using, i got the 30828-09-14 04:48:05.477580700 +0200 
again.


My guess is, that is about some initialization issue but i am not sure. 
I try to do a git bisect, but i am not yet done as the build on the 
target is so slow.

Bug#998355: samba: Access Time of File is set to the far future: 30828-09-14 04:48:05.477580700 +0200

[Georg Gast]

Package: samba
Version: 2:4.13.5+dfsg-2
Severity: normal
X-Debbugs-Cc: ge...@schorsch-tech.de

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I upgraded from buster to bullseye. With buster i used a .NET program on 
windows called "Mein Geld 365". The database is on the NAS running samba. With 
buster, the accesstime was normal adjusted but with bullseye, the accesstime is 
set far to the future.

This shows the outout of stat when the error is there:
stat Georg_2016.mgz
 Datei: Georg_2016.mgz
 Größe: 20905984Blöcke: 40808  EA Block: 4096   reguläre Datei
 Gerät: 2bh/43d Inode: 452839  Verknüpfungen: 1
Zugriff: (0660/-rw-rw)  Uid: ( 1000/   georg)   Gid: ( 1000/   georg)
Zugriff: 30828-09-14 04:48:05.477580700 +0200
Modifiziert: 2021-11-02 17:18:23.581530067 +0100
Geändert: 2021-11-02 17:18:23.577239537 +0100
Geburt: 2021-11-02 17:16:31.709703003 +0100

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I reverted my machine to buster (snapshot on btrfs) and the application worked 
correctly. With the wrong accesstime the application complains about
"Invalid Win32-FileTime". After the rollback to bullseye the application 
complained again about the wront "Win32-FileTime".
Even a touch on the nas to the file corrects the accesstime. 

   * What outcome did you expect instead?
The accesstime of the file should be correct.

*** End of the template - remove these template lines ***

I wanted to pin the old samba version to see, if its samba or the kernel, but 
the pin did not work as it conflicts on libldb2/libldb1.

-- Package-specific info:
* /etc/samba/smb.conf present, and attached
* /var/lib/samba/dhcp.conf present, and attached

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
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 samba depends on:
ii  adduser  3.118
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13+deb11u2
ii  libgnutls30  3.7.1-5
ii  libldb2  2:2.2.0-3.1
ii  libpam-modules   1.4.0-9+deb11u1
ii  libpam-runtime   1.4.0-9+deb11u1
ii  libpopt0 1.18-2
ii  libpython3.9 3.9.2-1
ii  libtalloc2   2.3.1-2+b1
ii  libtasn1-6   4.16.0-2
ii  libtdb1  1.4.3-1+b1
ii  libtevent0   0.10.2-1
ii  libwbclient0 2:4.13.5+dfsg-2
ii  lsb-base 11.1.0
ii  procps   2:3.3.17-5
ii  python3  3.9.2-3
ii  python3-dnspython2.0.0-1
ii  python3-samba2:4.13.5+dfsg-2
ii  samba-common 2:4.13.5+dfsg-2
ii  samba-common-bin 2:4.13.5+dfsg-2
ii  samba-libs   2:4.13.5+dfsg-2
ii  tdb-tools1.4.3-1+b1

Versions of packages samba recommends:
ii  attr1:2.4.48-6
ii  logrotate   3.18.0-2
ii  python3-markdown3.3.4-1
ii  samba-dsdb-modules  2:4.13.5+dfsg-2
ii  samba-vfs-modules   2:4.13.5+dfsg-2

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
pn  ntp | chrony   
pn  smbldap-tools  
pn  ufw
pn  winbind

-- no debconf information
[global]
#workgroup = dahoam2
#min protocol = NT1
#max protocol = smb2
netbios name = NAS-DSM
ntlm auth = yes

#vfs objects = full_audit
#full_audit:prefix = %u|%I|%m|%S
#full_audit:success = mkdir rename unlink rmdir pwrite
#full_audit:failure = none
#full_audit:facility = local7
#full_audit:priority = NOTICE

# this is important to join the workgroup
domain master = no

# allow to execute from the share
acl allow execute always = True

server role = standalone server
realm = nas-dsm

#name resolve order = wins lmhosts bcast
name resolve order = wins bcast

# %v prints the version of Samba being used.
server string = Samba Server %v
load printers = no

## # This line enables the log file and limits its size to less than 50kb.
log file = /var/log/samba/log.%m
log level = 3
max log size = 50

## # We are going to set some options for our interfaces...
socket options = TCP_NODELAY

## # This is a good idea, what we are doing is binding the
# samba server to our local network.
# For example, if eth0 is the local network interface:
interfaces = eth0
# bind interfaces only = yes

## # Specifies which IP address range is allowed to access Samba
hosts allow = 127.0.0.1 192.168.160.0/24 192.168.177.0/24
hosts deny = 0.0.0.0/0

## # Other options for this are USER, DOMAIN, ADS, and SERVER
# The default is user
security = us

Bug#804857: linux: New feature: enable CONFIG_NO_HZ_FULL and CONFIG_RCU_NOCB_CPU/CONFIG_RCU_NOCB_CPU_NONE

[Georg Müller]

But for other configurations it is worse:

config NO_HZ_FULL
bool "Full dynticks system (tickless)"
...
 This is implemented at the expense of some overhead in user <-> kernel
 transitions: syscalls, exceptions and interrupts. Even when it's
 dynamically off.

 Say N.




Upstream commit 176b8906 changed the description regarding NO_HZ_FULL:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=176b8906c399a170886ea4bad5b24763c6713d61


> By default, without passing the nohz_full parameter, this behaves just
> like NO_HZ_IDLE.
>
> If you're a distro say Y.

Bug#994017: python3-pynetbox: please provide a bullseye-backport

[Georg Faerber]

Package: python3-pynetbox
Severity: wishlist

Dear maintainer,

Would it be possible to provide a backport targeting bullseye?

Thanks a lot for maintaining python3-pynetbox in Debian!

Cheers,
Georg

Bug#993920: Patch works on bullseye

[Georg Faerber]

Hi,

On 21-09-09 13:36:44, Santiago Garcia Mantinan wrote:
> I'm attaching the patch as github's web seems to put it difficult (or even
> imposible, at least I didn't find it) to download the raw patch.

FWIW, you get the raw patch via appending .patch to the URL of the PR in
question. In this case, that's therefore:
https://github.com/ganeti/ganeti/pull/1603.patch

Cheers,
Georg

Bug#993438: python3-pygments: Markdown and Output lexers cannot be found

[Georg Brandl]

On 01/09/2021 13:34, Francesco Potortì wrote:
> Package: python3-pygments
> Version: 2.7.1+dfsg-2.1
> Severity: normal
> X-Debbugs-Cc: none, Francesco Potortì 
>
>   get_lexer_by_name("markdown")
> does not work: it does not find the lexer.
> However,
>   get_lexer_by_name("md")
> works, so this is a bug with a workaround.
>
>   get_lexer_by_name("output")
> does not work: it does not find the lexer.
> This time, it seems that OutputLexer is not really there, as
>   from pygments.lexers import OutputLexer
> does not work either.

If the version (2.7.1) is correct, this is expected: the "markdown"
alias is new in 2.8.0, while the Output lexer is new in 2.10.0.

Bug#993350: xsane: Scanimage detects scanner but Xsane won't start it

[Hans Georg Colle]

Scanimage fails starting the scan, too. The result of "scanimage -d
epson2:libusb:002:005 --format png -o /home/georg/unsinn.png" is
"scanimage: sane_start: Operation not supported".
Georg

Bug#993350: xsane: Scanimage detects scanner but Xsane won't start it

[Georg]

Package: xsane
Version: 0.999-12
Severity: normal
X-Debbugs-Cc: georg.co...@gmail.com




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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
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 xsane depends on:
ii  libc62.31-17
ii  libgimp2.0   2.10.22-4
ii  libglib2.0-0 2.68.4-1
ii  libgtk2.0-0  2.24.33-2
ii  libjpeg62-turbo  1:2.0.6-4
ii  liblcms2-2   2.12~rc1-2
ii  libpng16-16  1.6.37-3
ii  libsane1 1.0.32-4
ii  libtiff5 4.2.0-1
ii  sensible-utils   0.0.16
ii  xsane-common 0.999-12
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages xsane recommends:
ii  cups-client2.3.3op2-6
ii  firefox-esr [www-browser]  78.13.0esr-1

Versions of packages xsane suggests:
ii  gimp 2.10.22-4
pn  gv   
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr4.1.1-2.1

-- no debconf information

After turning on my usb flatbed scanner Epson Perfection 1650 I start Xsane and 
it shows on the screen.
When clicking on the preview button or the scan button an error box pops up 
saying 'Konnte Scanner nicht
starten Operation nicht unterstützt' (Could not start scanner operation not 
supported).
I get this issue since xsane was updated to version 0.999-12 a few days ago.
The output of scanimage -L is "device `epson2:libusb:002:004' is a Epson 
GT-8200 flatbed scanner".
In journalctl I found a message concerning xsane and gnome-shell
'gnome-shell[1219]: Couldn't find child [0x5640f14df430 
Gjs_ui_windowPreview_WindowPreview:first-child
last-child ("xsane 0.999")] in window slots'.

Regards, Georg

Bug#982660: knot-resolver: fails to start

[Georg Faerber]

Control: tags -1 + bullseye

Hi,

On 21-02-12 20:47:42, Daniel Kahn Gillmor wrote:
> When i "apt install knot-resolver" on an otherwise clean system
> running systemd, the default configuration should start a listener on
> port 53 on 127.0.0.1.
> 
> However, that listener often fails to start.

I ran into this as well while upgrading machines from buster to
bullseye. I did a couple of reboots, and in my case, every time the
listener failed to start.

I looked into this a bit, but was unable to figure out what causes this.

Upstream tells [1]:

kresd@*.service is not enabled by default, thus Knot Resolver won’t
start automatically after reboot. To start and enable service in one
command use systemctl enable --now kresd@1.service

I'm not sure if these docs apply to the Debian packaging as well, and if
that's the intended way to go, but it helped in my case.

Thanks for maintaining knot-resolver in Debian!

Cheers,
Georg


[1] https://knot-resolver.readthedocs.io/en/stable/quickstart-startup.html

Bug#991831: unblock: mat2/0.12.1-3

[Georg Faerber]

Hi Paul,

On 21-08-06 14:07:00, Paul Gevers wrote:
> That's part of the equation, yes.

Thanks for clarifying.

> I won't speak for SRM, but I would expect so.

Thanks!

> Tip: reportbug from bullseye has a better template for unblock and p-u
> bugs than buster. Please be verbose on impact, tests and risks if/when
> you file a p-u bug so that SRM can properly assess the gain vs risks.

ACK, will do so in the future.

Have a good release time!

Thanks for your work,
cheers,
Georg

Bug#991831: unblock: mat2/0.12.1-3

[Georg Faerber]

Hi Paul,

Thanks for your reply.

On 21-08-06 08:32:20, Paul Gevers wrote:
> It's too late for changes like this one.

Is this due to mat2 being a key package?

Besides, would this potentially accepted in 11.1?

Cheers,
Georg

Bug#948346: ////////////Guten Morgen

[Georg KÖRBL]

Vielen Dank für die Informationen, die ich über Ihr Facebook-Profil
über Sie erhalten habe. Ich benötige jedoch Ihre Mithilfe, um
humanitäre Hilfe zu verteilen, um das Projekt entsprechend finanziell
zu arrangieren.
Grüße.

Bug#991832: unblock: schleuder/3.6.0-3

[Georg Faerber]

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

Dear release team,

Please unblock schleuder 3.6.0-3.

It ships an upstream patch to fix verifying encapsulated messages: monkeypatch
ruby-mail-gpg to restore the use of the unaltered raw source of the relevant
email part.

This code was removed in a recent release of ruby-mail-gpg for yet unknown
reasons, and uploaded to Debian via 0.4.4-1.

The change is guarded by a test, which contributes a lot to the size of the
diff; autopkgtests look good, no regressions reported.

Histogramm of the diff:

~ debdiff schleuder_3.6.0-2.dsc schleuder_3.6.0-3.dsc | diffstat

 changelog  |   11 
 patches/0030-fix-verifying-encapsulated-messages.patch |  308 +
 patches/series |1 
 3 files changed, 320 insertions(+)

Please find the full debdiff attached.

unblock schleuder/3.6.0-3

Thanks for your work,
cheers,
Georg
diff -Nru schleuder-3.6.0/debian/changelog schleuder-3.6.0/debian/changelog
--- schleuder-3.6.0/debian/changelog	2021-05-23 17:32:19.0 +
+++ schleuder-3.6.0/debian/changelog	2021-07-29 20:36:52.0 +
@@ -1,3 +1,14 @@
+schleuder (3.6.0-3) unstable; urgency=medium
+
+  * debian/patches:
+- Pull in upstream patch to fix verifying encapsulated messages:
+  monkeypatch ruby-mail-gpg to restore the use of the unaltered raw source
+  of the relevant email part.
+  This code was removed in a recent release of ruby-mail-gpg for yet
+  unknown reasons, and uploaded to Debian via 0.4.4-1.
+
+ -- Georg Faerber   Thu, 29 Jul 2021 20:36:52 +
+
 schleuder (3.6.0-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru schleuder-3.6.0/debian/patches/0030-fix-verifying-encapsulated-messages.patch schleuder-3.6.0/debian/patches/0030-fix-verifying-encapsulated-messages.patch
--- schleuder-3.6.0/debian/patches/0030-fix-verifying-encapsulated-messages.patch	1970-01-01 00:00:00.0 +
+++ schleuder-3.6.0/debian/patches/0030-fix-verifying-encapsulated-messages.patch	2021-07-29 20:36:52.0 +
@@ -0,0 +1,308 @@
+Description: Fix verifying encapsulated messages
+ This monkeypatches mail-gpg to restore the use of the unaltered raw 
+ source of the relevant email part.
+ This code was removed in 
+ <https://github.com/jkraemer/mail-gpg/commit/5fded41ccee4a58f848a2f8e7bd53d11236f8984>
+ for yet unknown reasons.
+ The issue is tracked at <https://github.com/jkraemer/mail-gpg/issues/67>.
+Origin: upstream
+Bug: https://0xacab.org/schleuder/schleuder/-/issues/502
+Applied-Upstream: cf9a046436e6a1cfe06565bf9b4a41d6b6eebb0d, 7c049123971bde41b5b9203b45009a40ff667b03
+Reviewed-by: Georg Faerber 
+Last-Update: 2021-07-29
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: schleuder/lib/schleuder.rb
+===
+--- schleuder.orig/lib/schleuder.rb	2021-07-29 20:07:47.289606627 +
 schleuder/lib/schleuder.rb	2021-07-29 20:07:47.281606517 +
+@@ -31,6 +31,7 @@
+ require 'schleuder/mail/message.rb'
+ require 'schleuder/mail/gpg.rb'
+ require 'schleuder/mail/encrypted_part.rb'
++require 'schleuder/mail/gpg/sign_part.rb'
+ require 'schleuder/gpgme/import_status.rb'
+ require 'schleuder/gpgme/key.rb'
+ require 'schleuder/gpgme/sub_key.rb'
+Index: schleuder/lib/schleuder/mail/gpg/sign_part.rb
+===
+--- /dev/null	1970-01-01 00:00:00.0 +
 schleuder/lib/schleuder/mail/gpg/sign_part.rb	2021-07-29 20:07:47.281606517 +
+@@ -0,0 +1,33 @@
++module Mail
++  module Gpg
++class SignPart < Mail::Part
++  # Copied verbatim from mail-gpg v.0.4.2. This code was changed in
++  # <https://github.com/jkraemer/mail-gpg/commit/5fded41ccee4a58f848a2f8e7bd53d11236f8984>,
++  # which breaks verifying some encapsulated (signed-then-encrypted)
++  # messages. See
++  # <https://github.com/jkraemer/mail-gpg/pull/40#issue-95776382> for
++  # details.
++  def self.verify_signature(plain_part, signature_part, options = {})
++if !(signature_part.has_content_type? &&
++('application/pgp-signature' == signature_part.mime_type))
++  return false
++end
++
++# Work around the problem that plain_part.raw_source prefixes an
++# erroneous CRLF, <https://github.com/mikel/mail/issues/702>.
++if ! plain_part.raw_source.empty?
++  plaintext = [ plain_part.header.raw_source,
++"\r\n\r\n",
++plain_part.body.raw_source
++  ].join
++else
++  plaintext = plain_part.encoded
++end
++
++signature = signature_part.body.encoded
++GpgmeHelper.sign_verify(plaintext, signature, options)
++  end
++end
++ 

Bug#991831: unblock: mat2/0.12.1-3

[Georg Faerber]

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

Dear release team,

Please unblock mat2 0.12.1-3.

It ships improved support of XLSX files and a fix adressing problems if
printing cleaned PDF files.

It's a key package, as doxygen build-depends on it, but so far regressions
haven't been reported, and autopkgtest looks good as well.

Histogramm of the diff:

~ debdiff mat2_0.12.1-2.dsc mat2_0.12.1-3.dsc | diffstat

 changelog|   12 
 patches/0001-improve-support-for-xlsx-files.patch|   28 +--
 patches/0002-fix-printing-of-cleaned-pdf-files.patch |   48 +++
 patches/series   |1 
 4 files changed, 84 insertions(+), 5 deletions(-)

Please find the full debdiff attached.

unblock mat2/0.12.1-3

Thanks for your work,
cheers,
Georg
diff -Nru mat2-0.12.1/debian/changelog mat2-0.12.1/debian/changelog
--- mat2-0.12.1/debian/changelog	2021-05-24 15:01:29.0 +
+++ mat2-0.12.1/debian/changelog	2021-07-29 16:21:06.0 +
@@ -1,3 +1,15 @@
+mat2 (0.12.1-3) unstable; urgency=medium
+
+  * debian/patches:
+- Pull in upstream patch to improve support of OpenXML (xlsx) files.
+  This patch extends the one introduced in the previous upload, 0.12.1-2.
+  This approach is chosen to limit the diff, as both patches target the
+  same area of the source code.
+- Pull in upstream patch to fix issues if printing cleaned Portable
+  Document Format (pdf) files.
+
+ -- Georg Faerber   Thu, 29 Jul 2021 16:21:06 +
+
 mat2 (0.12.1-2) unstable; urgency=medium
 
   * debian/patches:
diff -Nru mat2-0.12.1/debian/patches/0001-improve-support-for-xlsx-files.patch mat2-0.12.1/debian/patches/0001-improve-support-for-xlsx-files.patch
--- mat2-0.12.1/debian/patches/0001-improve-support-for-xlsx-files.patch	2021-05-24 15:01:29.0 +
+++ mat2-0.12.1/debian/patches/0001-improve-support-for-xlsx-files.patch	2021-07-29 16:21:06.0 +
@@ -1,19 +1,37 @@
 Description: Improve support of Open XML (xlsx) files
 Origin: upstream
-Applied-Upstream: bf0c777cb9159e220f636b0c019fe4957e4fea75
+Applied-Upstream: bf0c777cb9159e220f636b0c019fe4957e4fea75, 0b094b594bd1db017ed3d063a10714f6b2a7b9f3
 Reviewed-by: Georg Faerber 
-Last-Update: 2021-05-24
+Last-Update: 2021-07-29
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 Index: mat2/libmat2/office.py
 ===
 mat2.orig/libmat2/office.py	2021-05-19 11:26:06.093187321 +
-+++ mat2/libmat2/office.py	2021-05-24 14:44:33.698488246 +
-@@ -107,6 +107,7 @@
+--- mat2.orig/libmat2/office.py	2021-07-29 15:56:40.307190532 +
 mat2/libmat2/office.py	2021-07-29 15:58:33.200905419 +
+@@ -88,6 +88,7 @@
+ r'^\[Content_Types\]\.xml$',
+ r'^_rels/\.rels$',
+ r'^xl/sharedStrings\.xml$',  # https://docs.microsoft.com/en-us/office/open-xml/working-with-the-shared-string-table
++r'^xl/calcChain\.xml$',
+ r'^(?:word|ppt|xl)/_rels/document\.xml\.rels$',
+ r'^(?:word|ppt|xl)/_rels/footer[0-9]*\.xml\.rels$',
+ r'^(?:word|ppt|xl)/_rels/header[0-9]*\.xml\.rels$',
+@@ -107,6 +108,9 @@
  # TODO: check if p:bgRef can be randomized
  r'^ppt/slideMasters/slideMaster[0-9]+\.xml',
  r'^ppt/slideMasters/_rels/slideMaster[0-9]+\.xml\.rels',
 +r'^xl/worksheets/_rels/sheet[0-9]+\.xml\.rels',
++r'^xl/drawings/vmlDrawing[0-9]+\.vml',
++r'^xl/drawings/drawing[0-9]+\.xml',
  }))
  self.files_to_omit = set(map(re.compile, {  # type: ignore
  r'^\[trash\]/',
+@@ -123,6 +127,7 @@
+ # Additional presentation-wide properties like printing properties,
+ # presentation show properties etc.
+ r'^(?:word|ppt|xl)/presProps\.xml$',
++r'^(?:word|ppt|xl)/comments[0-9]+\.xml$',
+ 
+ # we have an allowlist in self.files_to_keep,
+ # so we can trash everything else
diff -Nru mat2-0.12.1/debian/patches/0002-fix-printing-of-cleaned-pdf-files.patch mat2-0.12.1/debian/patches/0002-fix-printing-of-cleaned-pdf-files.patch
--- mat2-0.12.1/debian/patches/0002-fix-printing-of-cleaned-pdf-files.patch	1970-01-01 00:00:00.0 +
+++ mat2-0.12.1/debian/patches/0002-fix-printing-of-cleaned-pdf-files.patch	2021-07-29 16:21:06.0 +
@@ -0,0 +1,48 @@
+Description: Fix issues if printing cleaned pdf file
+ pyCairo by default renders the PDF surfaces with a resolution of 72
+ dpi which is so low that the bitmap gets blurred compared to original.
+ Since pyCairo 1.12.0, a new method set_device_scale(x_scale, y_scale)
+ is added, which allows changing the canvas resolution.
+Origin: upstream
+Applied-Upstream: 3b094ae449afbb2c375454c1ee76b76aa98648d4
+Reviewed-by: Georg Faerber

Bug#991662: schleuder: x-add-key fails for attached, binary key-material

[Georg Faerber]

Package: schleuder
Version: 3.6.0-2
Severity: important
Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/495

x-add-key fails for attached, binary key material, and Schleuder tells
'no keys could be found'.

This was fixed upstream via [1], but pulling this patch into the current
version, 3.6.0-2, leads to a spec error which tests attached
quoted-printable key-material (as produced by Thunderbird).

It's currently unclear what causes this.

Bug#990920: unblock: mat2/0.12.1-2

[Georg Faerber]

Hi Adrian, all,

On 21-07-11 06:45:07, Adrian Bunk wrote:
> Please unblock package mat2
> 
>   * debian/patches:
> - Pull in upstream patch to improve support of Open XML (xlsx) files.
> (change by Georg Faerber)
> 
> Oneline change, autopkgtest pass.
> 
> Maintainer is in Cc, ack/nak would be appreciated.

ACK -- thanks for handling this, it was on my TODO as well.

Cheers,
Georg

Bug#988771: unblock: mat2/0.12.1-1

[Georg Faerber]

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

Dear release team,

Please unblock mat2 0.12.1-1.

It ships improved support of EPUB and Microsoft Office files. It's a key
package, as doxygen build-depends on it, but so far regressions haven't been
reported, and autopkgtest looks good as well. The diff is quite small:

~ debdiff mat2_0.12.0-1.dsc mat2_0.12.1-1.dsc | diffstat

 CHANGELOG.md  |5 +
 debian/changelog  |7 +++
 doc/mat2.1|2 +-
 libmat2/epub.py   |   49 +++--
 libmat2/office.py |2 ++
 mat2  |2 +-
 setup.py  |2 +-
 7 files changed, 60 insertions(+), 9 deletions(-)

Please find the full debdiff attached.

unblock mat2/0.12.1-1

Thanks for your work,
cheers,
Georg
diff -Nru mat2-0.12.0/CHANGELOG.md mat2-0.12.1/CHANGELOG.md
--- mat2-0.12.0/CHANGELOG.md	2020-12-18 16:55:41.0 +
+++ mat2-0.12.1/CHANGELOG.md	2021-03-19 16:54:21.0 +
@@ -1,3 +1,8 @@
+# 0.12.1 - 2021-03-19
+
+- Improve epub support
+- Improve MS Office support
+
 # 0.12.0 - 2020-12-18
 
 - Improve significantly MS Office formats support
diff -Nru mat2-0.12.0/debian/changelog mat2-0.12.1/debian/changelog
--- mat2-0.12.0/debian/changelog	2020-12-26 19:52:55.0 +
+++ mat2-0.12.1/debian/changelog	2021-03-20 19:11:38.0 +
@@ -1,3 +1,10 @@
+mat2 (0.12.1-1) unstable; urgency=medium
+
+  * New upstream version 0.12.1:
+- Ships improved support of EPUB and Microsoft Office files.
+
+ -- Georg Faerber   Sat, 20 Mar 2021 19:11:38 +
+
 mat2 (0.12.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru mat2-0.12.0/doc/mat2.1 mat2-0.12.1/doc/mat2.1
--- mat2-0.12.0/doc/mat2.1	2020-12-18 16:55:41.0 +
+++ mat2-0.12.1/doc/mat2.1	2021-03-19 16:54:21.0 +
@@ -1,4 +1,4 @@
-.TH mat2 "1" "December 2020" "mat2 0.12.0" "User Commands"
+.TH mat2 "1" "March 2021" "mat2 0.12.1" "User Commands"
 
 .SH NAME
 mat2 \- the metadata anonymisation toolkit 2
diff -Nru mat2-0.12.0/libmat2/epub.py mat2-0.12.1/libmat2/epub.py
--- mat2-0.12.0/libmat2/epub.py	2020-12-18 16:55:41.0 +
+++ mat2-0.12.1/libmat2/epub.py	2021-03-19 16:54:21.0 +
@@ -1,7 +1,9 @@
 import logging
 import re
 import uuid
+import zipfile
 import xml.etree.ElementTree as ET  # type: ignore
+from typing import Dict, Any
 
 from . import archive, office
 
@@ -15,11 +17,28 @@
 'META-INF/container.xml',
 'mimetype',
 'OEBPS/content.opf',
+'content.opf',
+'hmh.opf',
+'OPS/.+.xml'
 }))
+self.files_to_omit = set(map(re.compile, {  # type: ignore
+'iTunesMetadata.plist',
+'META-INF/calibre_bookmarks.txt',
+'OEBPS/package.opf',
+ }))
 self.uniqid = uuid.uuid4()
 
-def _specific_get_meta(self, full_path, file_path):
-if file_path != 'OEBPS/content.opf':
+
+def is_archive_valid(self):
+super().is_archive_valid()
+with zipfile.ZipFile(self.filename) as zin:
+for item in self._get_all_members(zin):
+member_name = self._get_member_name(item)
+if member_name.endswith('META-INF/encryption.xml'):
+raise ValueError('the file contains encrypted fonts')
+
+def _specific_get_meta(self, full_path, file_path) -> Dict[str, Any]:
+if not file_path.endswith('.opf'):
 return {}
 
 with open(full_path, encoding='utf-8') as f:
@@ -30,14 +49,32 @@
 except (TypeError, UnicodeDecodeError):
 return {file_path: 'harmful content', }
 
-def _specific_cleanup(self, full_path: str):
-if full_path.endswith('OEBPS/content.opf'):
+def _specific_cleanup(self, full_path: str) -> bool:
+if full_path.endswith('hmh.opf') or full_path.endswith('content.opf'):
 return self.__handle_contentopf(full_path)
 elif full_path.endswith('OEBPS/toc.ncx'):
 return self.__handle_tocncx(full_path)
+elif re.search('/OPS/[^/]+.xml$', full_path):
+return self.__handle_ops_xml(full_path)
 return True
 
-def __handle_tocncx(self, full_path: str):
+def __handle_ops_xml(self, full_path: str) -> bool:
+try:
+tree, namespace = office._parse_xml(full_path)
+except ET.ParseError:  # pragma: nocover
+logging.error("Unable to parse %s in %s.", full_path, self.filename)
+return False
+
+for item in tree.iterfind('.//', namespace):  # pragma: nocover
+if item.tag.strip().lower().endswith('head'):
+item.clear()
+break
+tree.write(full_path, xml_declaration=True, encoding='utf-8',
+   short_empty_elements=F

Bug#984564: Still exists in 5.10.0-4-amd64 #1 SMP Debian 5.10.19-1

[Georg Borgström]

Dear Maintainer,

The same behaviour exists in 5.10.0-4-amd64 #1 SMP Debian 5.10.19-1.

I can reproduce the error by switching off the monitor. When I power it on,
the error always comes. The only time the error appears is when the monitor
has been powered off and is powered on again. At least as far as I can tell.

It's always six lines of "gdk_monitor_get_scale_factor: assertion
'GDK_IS_MONITOR (monitor)' failed" followed by one single line with
"[drm] *ERROR* CPU pipe A FIFO underrun"

Best regards
Georg

Bug#973248: [Pkg-puppet-devel] Bug#973248: Deprecation warning in Ruby 2.7: $SAFE will become a normal global variable in Ruby 3.0

[Georg Faerber]

Hi,

On 21-03-08 20:46:54, Thomas Goirand wrote:
> The patch is super small and looks clean. I also am very annoyed by
> this problem and would like it to be fixed. I'm not sure I can be the
> voice of all of the team, but I would say: please go ahead with NMU +
> dealing with the release team. Can someone else approve? Apollon
> maybe?

ACK from my side as well, please go ahead.

Thanks for caring and dealing this.

Cheers,
Georg

Bug#980194: [Pkg-privacy-maintainers] Bug#980194: Bug#980194: mat2: autopkgtest regression in testing: AssertionError: ValueError not raised

[Georg Faerber]

Hi Paul,

On 21-01-15 22:57:54, Georg Faerber wrote:
> I'm wondering if this is related to the recent upload of media-types
> [1].
> 
> This test [2], which installed media-types 1.0.1, was successful,
> whereas the test [3], which installed media-types 1.1.0, wasn't.

I've requested a test [1] in testing with media-types from unstable,
which was successful. The problem seems a regression in media-types,
which is fixed in media-types >= 3.0.0. Given this, is there anything
else required from my side?

Cheers,
Georg


[1] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/9735398/log.gz

Bug#980194: [Pkg-privacy-maintainers] Bug#980194: mat2: autopkgtest regression in testing: AssertionError: ValueError not raised

[Georg Faerber]

Hi Paul,

Thanks for telling!

On 21-01-15 22:09:18, Paul Gevers wrote:
> With a very recent change in testing the autopkgtest of your package
> started to fail. I copied some of the output at the bottom of this
> report. Can you please investigate the situation and fix it?

I'm wondering if this is related to the recent upload of media-types
[1].

This test [2], which installed media-types 1.0.1, was successful,
whereas the test [3], which installed media-types 1.1.0, wasn't.

Cheers,
Georg


[1] 
https://tracker.debian.org/news/1208854/accepted-media-types-110-source-into-unstable/
[2] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/9452897/log.gz
[3] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/9663226/log.gz

Bug#953132: kodi-pvr-vdr-vnsi: 8.1.0 Status: Ok (from source)

[Georg Gast]

Hi Vasyl,

i tested some of the plugins listed on salsa in the kodi repo:

Ok:
- kodi-pvr-iptvsimple
- kodi-pvr-vdr-vnsi

- kodi-screensaver-asteroids
- kodi-screensaver-biogenesis
- kodi-screensaver-greynetic
- kodi-screensaver-pingpong
- kodi-screensaver-pyro
- kodi-screensaver-shadertoy

- kodi-visualization-fishbmc
- kodi-visualization-spectrum
- kodi-visualization-waveform

Build and install ok, but could not test functionality
- kodi-pvr-dvbviewer
- kodi-pvr-hts

Build and install ok, but could not add files on a SSH server over it. 
The data source in kodi does not show sftp even if this addon is activated.

- kodi-vfs-sftp

About the other addons i have no backend to test them (practicly all 
other pvr addons). The codec addons, i dont know how to use them yet.


I wish you also a happy new year!

BTW:
If you need more help by testing kodi stuff, just mail me :)

Bye
Georg


Am 03.01.21 um 08:23 schrieb Vasyl Gello:

Hi Georg,


Just wanted to let you know, because the freeze of bullseye is on the
doorstep. Maybe this addon can slip into bullseye.


Yes, we are working together with Mattia to review & upload all packages listed 
under

https://salsa.debian.org/multimedia-team/kodi-media-center

to bullseye before the freeze. Please test as many addons as you can - this 
greatly helps us!

Happy New Year!
--
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

3 січня 2021 р. 07:08:13 UTC, Georg Gast  написав(-ла):

Dear Maintainers,

The old plugin from stretch worked up until buster. The system was
originally installed with stretch, but he kodi-pvr-vdr-vnsi addon was
not upgraded nor purged at the dist upgrades. I hit this issue as i
tried to upgrade to bullseye on my VDR. because at buster->bullseye it
got purged.

I just built kodi 19 Beta2 [1] and kodi-pvr-vdr-vnsi:8.1.0 [2] from
source and tested it on my VDR system.
It works on bullseye/amd64 from source. I tried to get the package from
sid and kodi from bullseye. I could not install the plugin as it depends
on kodi-pvr-api=5.10.3. Also because the package in sid is still the old
version.

https://tracker.debian.org/pkg/kodi-pvr-vdr-vnsi

Then i tried to check the source on salsa. It has already the merge of
8.1.0 upstream in it. I built the package from the salsa source and
installed the resulting package on my VDR. It works as expected.

Just wanted to let you know, because the freeze of bullseye is on the
doorstep. Maybe this addon can slip into bullseye.

Bye

Georg

[1] https://github.com/xbmc/xbmc (branch master)
[2] https://github.com/kodi-pvr/pvr.vdr.vnsi (branch Matrix)

Bug#953132: kodi-pvr-vdr-vnsi: 8.1.0 Status: Ok (from source)

[Georg Gast]

Dear Maintainers,

The old plugin from stretch worked up until buster. The system was 
originally installed with stretch, but he kodi-pvr-vdr-vnsi addon was 
not upgraded nor purged at the dist upgrades. I hit this issue as i 
tried to upgrade to bullseye on my VDR. because at buster->bullseye it 
got purged.


I just built kodi 19 Beta2 [1] and kodi-pvr-vdr-vnsi:8.1.0 [2] from 
source and tested it on my VDR system.
It works on bullseye/amd64 from source. I tried to get the package from 
sid and kodi from bullseye. I could not install the plugin as it depends 
on kodi-pvr-api=5.10.3. Also because the package in sid is still the old 
version.


https://tracker.debian.org/pkg/kodi-pvr-vdr-vnsi

Then i tried to check the source on salsa. It has already the merge of 
8.1.0 upstream in it. I built the package from the salsa source and 
installed the resulting package on my VDR. It works as expected.


Just wanted to let you know, because the freeze of bullseye is on the 
doorstep. Maybe this addon can slip into bullseye.


Bye

Georg

[1] https://github.com/xbmc/xbmc (branch master)
[2] https://github.com/kodi-pvr/pvr.vdr.vnsi (branch Matrix)

Bug#976270: [Pkg-puppet-devel] Bug#976270: Bug#976270: ruby-puppet-forge: autopkgtest/ftbfs with ruby-faraday-middleware 1.x

[Georg Faerber]

Hi,

On 20-12-03 14:19:00, Pirate Praveen wrote:
> Added Breaks, but we may need to request removal from testing to allow
> ruby-faraday to migrate.

I would like to keep it in testing, as it's a dependency of r10k.

Cheers,
Georg

Bug#933063: [debian-mysql] Bug#933063: Bug#933063: Bug#933063: character_set_client: latin1?

[Georg Richter]

Hi Otto,

this is the commit

/Georg

git show 29720950eeae75f1ea7ef1376a6149cabeb79d13
commit 29720950eeae75f1ea7ef1376a6149cabeb79d13
Author: Georg Richter 
Date:   Wed Sep 30 06:29:29 2020 +0200

   Allow to specify the default character set in server builds with
-DCONC_DEFAULT_CHARSET

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c85baf2..4045491 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,7 +25,7 @@ get_directory_property(IS_SUBPROJECT PARENT_DIRECTORY)
SET_PROPERTY(DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
FOREACH(V WITH_MYSQLCOMPAT WITH_MSI WITH_SIGNCODE WITH_RTC WITH_UNIT_TESTS
WITH_DYNCOL WITH_EXTERNAL_ZLIB WITH_CURL WITH_SQLITE WITH_SSL
WITH_ICONV
-INSTALL_LAYOUT WITH_TEST_SRCPKG)
+DEFAULT_CHARSET INSTALL_LAYOUT WITH_TEST_SRCPKG)
  SET(${V} ${${OPT}${V}})
ENDFOREACH()


On Tue, Oct 6, 2020 at 11:49 AM Otto Kekäläinen  wrote:

> Hello Georg!
>
> Will you do this same `-DCONC_DEFAULT_CHARSET=utf8mb4` change upstream
> as I did in
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/ca5e93c754209f9c1a729bb057332ab3b0b76363
> ?
>
> Let me know if there is an upstream commit so I can document it in
>
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/patches/933063-client-utf8mb4-by-default.patch
> and easily drop it once that upstream commit is eventually imported
> into Debian.
>
> su 4. lokak. 2020 klo 12.39 Otto Kekäläinen (o...@debian.org) kirjoitti:
> >
> > Thanks!
> >
> > I confirm the patch from Georg fixes this and the result looks like:
> >
> > g++ b933063.cpp -l mariadbclient && ./a.out
> > character_set_client: utf8mb4
> > character_set_connection: utf8mb4
> > character_set_database: utf8mb4
> > character_set_filesystem: binary
> > character_set_results: utf8mb4
> > character_set_server: utf8mb4
> > character_set_system: utf8
> > character_sets_dir: /usr/share/mysql/charsets/
> > spider_remote_access_charset:
> > spider_use_table_charset: -1
> >
> >
> > I also extended Salsa-CI to automatically test for this so that this
> > simple client library linking build does not regress unnoticed:
> >
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/bugfix/933063-default-client-charset-utf8mb4
> >
> > Open
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/3c62617cf955ece894504e88a72b3ce207635d05
> > to view the changes.
> >
> >
> > Georg: Will you do this same `-DCONC_DEFAULT_CHARSET=utf8mb4` change
> upstream?
> >
>


-- 
Georg Richter, Senior Software Engineer
MariaDB Corporation Ab

Bug#933063: [debian-mysql] Bug#933063: character_set_client: latin1?

[Georg Richter]

Hi Otto,

according to the build log you didn't build server with option
-DCONC_DEFAULT_CHARSET=utf8mb4 or do I miss something?

/Georg

On Thu, Oct 1, 2020 at 8:20 AM Otto Kekäläinen  wrote:

> When libmariadb-dev and libmariadbd-dev are installed one gets:
>
> # grep -rF DEFAULT_CHARSET /usr/include/
> /usr/include/mariadb/mariadb_ctype.h:#define MADB_DEFAULT_CHARSET_NAME
> "latin1"
> /usr/include/mariadb/server/my_config.h:#define
> MYSQL_DEFAULT_CHARSET_NAME "latin1"
>
> Georg: at the very end of the build log at
>
> http://buildbot.askmonty.org/buildbot/builders/kvm-deb-buster-amd64/builds/3187/steps/compile/logs/stdio
> you can see that files are included in the libmariadb-dev and other
> packages.
>
> Are we missing something?
> The config.h and ma_config.h files are now only in the mariadb sources
> themselves.
>
> Olaf: what commands did you run to compile your example program? Any
> pkg-config or mariadb_config involved?
>


-- 
Georg Richter, Senior Software Engineer
MariaDB Corporation Ab

Bug#933063: [debian-mysql] Bug#933063: character_set_client: latin1?

[Georg Richter]

Hi Otto,

looks like you use the command line client to check this - command line
client is different, it is using charset="auto" by default.
To check the mariadb_default_charset you can check the generated include
files:

georg@beethoven:~/work/mariadb/server/bld$ grep DEFAULT_CHARSET
libmariadb/include/*.h
libmariadb/include/config.h:#define MARIADB_DEFAULT_CHARSET "utf8mb4"
libmariadb/include/ma_config.h:#define MARIADB_DEFAULT_CHARSET "utf8mb4"

/Georg

On Wed, Sep 30, 2020 at 8:23 PM Otto Kekäläinen  wrote:

> Tested this patch, unfortunately it didn't work:
>
>
> MariaDB [(none)]> status;
> --
> mariadb  Ver 15.1 Distrib 10.5.5-MariaDB, for debian-linux-gnu
> (x86_64) using readline 5.2
>
> Connection id: 45
> Current database:
> Current user: root@localhost
> SSL: Not in use
> Current pager: stdout
> Using outfile: ''
> Using delimiter: ;
> Server: MariaDB
> Server version: 10.5.5-MariaDB-2-debug Debian unstable
> Protocol version: 10
> Connection: Localhost via UNIX socket
> Server characterset: utf8mb4
> Db characterset: utf8mb4
> Client characterset: latin1
> Conn.  characterset: latin1
>
>
> commit 2e1239cd426dd6bb910363082f57d66c06f71254
> Author: Otto Kekäläinen 
> Date:   Tue Sep 29 21:27:02 2020 +0300
>
> Use build flag to enforce default charset as utf8mb4 (Closes: #933063)
>
> diff --git a/debian/patches/933063-client-utf8mb4-by-default.patch
> b/debian/patches/933063-client-utf8mb4-by-default.patch
> new file mode 100644
> index 0..573dcf2f7
> --- /dev/null
> +++ b/debian/patches/933063-client-utf8mb4-by-default.patch
> @@ -0,0 +1,14 @@
> +Author: Georg Richter 
> +  Looks like it was forgotten to add this option when building C/C as
> a sunproject inside server. I fixed that now:
> +
> +--- a/libmariadb/CMakeLists.txt
>  b/libmariadb/CMakeLists.txt
> +@@ -25,7 +25,7 @@ get_directory_property(IS_SUBPROJECT PAR
> + SET_PROPERTY(DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
> + FOREACH(V WITH_MYSQLCOMPAT WITH_MSI WITH_SIGNCODE WITH_RTC
> WITH_UNIT_TESTS
> + WITH_DYNCOL WITH_EXTERNAL_ZLIB WITH_CURL WITH_SQLITE WITH_SSL
> +-INSTALL_LAYOUT WITH_TEST_SRCPKG)
> ++DEFAULT_CHARSET INSTALL_LAYOUT WITH_TEST_SRCPKG)
> +   SET(${V} ${${OPT}${V}})
> + ENDFOREACH()
> +
> diff --git a/debian/patches/series b/debian/patches/series
> index 043ed42cf..81eef0cdc 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -14,3 +14,4 @@
> prevent-executable-stack-due-to-objects-compiled-fro.patch
>  env-perl-usr-bin-perl.patch
>  fix-spelling.patch
>  ftbfs-x32.patch
> +933063-client-utf8mb4-by-default.patch
> diff --git a/debian/rules b/debian/rules
> index 819ac6ea0..3809e8f54 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -101,6 +101,7 @@ endif
> -DSYSTEM_TYPE="debian-$(DEB_HOST_GNU_SYSTEM)" \
>     -DBUILD_CONFIG=mysql_release \
> -DWITH_SSL=bundled \
> +   -DCONC_DEFAULT_CHARSET=utf8mb4 \
> -DPLUGIN_TOKUDB=NO \
> -DPLUGIN_CASSANDRA=NO \
> -DPLUGIN_AWS_KEY_MANAGEMENT=NO \
>


-- 
Georg Richter, Senior Software Engineer
MariaDB Corporation Ab

Bug#933063: [debian-mysql] Bug#933063: character_set_client: latin1?

[Georg Richter]

Hi Otto,

you're right - looks like it was forgotten to add this option when building
C/C as a sunproject inside server. I fixed that now:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c85baf2..4045491 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,7 +25,7 @@ get_directory_property(IS_SUBPROJECT PARENT_DIRECTORY)
 SET_PROPERTY(DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
 FOREACH(V WITH_MYSQLCOMPAT WITH_MSI WITH_SIGNCODE WITH_RTC WITH_UNIT_TESTS
 WITH_DYNCOL WITH_EXTERNAL_ZLIB WITH_CURL WITH_SQLITE WITH_SSL
WITH_ICONV
-INSTALL_LAYOUT WITH_TEST_SRCPKG)
+DEFAULT_CHARSET INSTALL_LAYOUT WITH_TEST_SRCPKG)
   SET(${V} ${${OPT}${V}})
 ENDFOREACH()

With this patch you should be able to specify the character set in server
build with
cmake -DCONC_DEFAULT_CHARSET=utf8mb4

/Georg

On Tue, Sep 29, 2020 at 10:41 PM Otto Kekäläinen  wrote:

> I tested this but it did not at least directly work:
>
> commit b8e537d55b467eb285a82842e73bb22732ef9ad6 (HEAD -> master-next)
> Author: Otto Kekäläinen 
> Date:   Tue Sep 29 21:27:02 2020 +0300
>
> Use build flag to enforce default charset as utf8mb4 (Closes: ##933063)
>
> diff --git a/debian/rules b/debian/rules
> index 819ac6ea0..12b162002 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -101,6 +101,7 @@ endif
> -DSYSTEM_TYPE="debian-$(DEB_HOST_GNU_SYSTEM)" \
> -DBUILD_CONFIG=mysql_release \
> -DWITH_SSL=bundled \
> +  -DDEFAULT_CHARSET=utf8mb4 \
> -DPLUGIN_TOKUDB=NO \
> -DPLUGIN_CASSANDRA=NO \
> -DPLUGIN_AWS_KEY_MANAGEMENT=NO \
>
>
> --->
>
>
> MariaDB [(none)]> status
> --
> mariadb  Ver 15.1 Distrib 10.5.5-MariaDB, for debian-linux-gnu
> (x86_64) using readline 5.2
>
> Connection id: 76
> Current database:
> Current user: root@localhost
> SSL: Not in use
> Current pager: stdout
> Using outfile: ''
> Using delimiter: ;
> Server: MariaDB
> Server version: 10.5.5-MariaDB-2-debug Debian 10
> Protocol version: 10
> Connection: Localhost via UNIX socket
> Server characterset: utf8mb4
> Db characterset: utf8mb4
> Client characterset: latin1
> Conn.  characterset: latin1
> UNIX socket: /run/mysqld/mysqld.sock
> Uptime: 27 sec
>
> Threads: 22  Questions: 674  Slow queries: 0  Opens: 199  Open tables:
> 37  Queries per second avg: 24.962
> --
>


-- 
Georg Richter, Senior Software Engineer
MariaDB Corporation Ab

Bug#933063: [debian-mysql] Bug#933063: character_set_client: latin1?

[Georg Richter]

Hi Otto,

in server build you have to pass special options for C/C  - I need to check
it and will get back to you.

/Georg

On Tue, Sep 29, 2020 at 3:42 PM Otto Kekäläinen  wrote:

> Hi!
>
> ti 29. syysk. 2020 klo 7.39 Georg Richter (ge...@mariadb.com) kirjoitti:
> >
> > Hi,
> >
> > if server has default charset utf8mb4 on Debian, why don't you build C/C
> with -DDEFAULT_CHARSET=utf8mb4 ?
>
> Yes, that might be a good solution. I wasn't aware of such an option.
>
> The upstream MariaDB 10.5 has this identical case, should that build
> flag also be applied there and if so, on what branch do you suggest
> (10.6 for future or older)?
>


-- 
Georg Richter, Senior Software Engineer
MariaDB Corporation Ab

Bug#964143: schleuder: ftbfs with Rails 6 in experimental - Could not find 'activerecord' (~> 5.2) - did find: [activerecord-6.0.3.1]

[Georg Faerber]

Package: schleuder
Version: 3.5.3-1
Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/454
Severity: important
Tags: ftbfs
User: pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: rails6-transition


The package fails to build (autopkgtest also failed) with Rails 6
currently in experimental. Rails 6 will be uploaded to unstable around
the first week of August, so please make sure this package is ready for
rails 6. The severity of this bug will be raised to serious after Rails
6 is uploaded to unstable.

https://people.debian.org/~praveen/rails6-meta-build/autopkgtest/schleuder.log

Bug#960066: schleuder: decide about the future of Recommends: haveged

[Georg Faerber]

Hi Chris,

Thanks for your input.

On 20-05-28 15:09:22, Chris Hofstaedtler wrote:
> Also, modern Linux kernels also contain a change to always have enough
> entropy available, even during boot time. Such a kernel will ship with
> bullseye.

ACK, that's one of the reasons I'm thinking about all of this.

> I would recommend dropping the Recommends: haveged.

ACK, that's what I'm leaning towards, too.

Do you have practical experience in regards to the new interface? I'm
wondering especially if it works as expected in virtual machines as
well, regardless of the setup (for example passing a host rng device
into the vm) or the virtualization technology in use? And what about
containers?

Thanks again,
cheers,
Georg