Bug#1082120: Needs reuploading for PostgreSQL 17 transition

[Christoph Berg]

Source: pg-gvm
Severity: important

Hi,

postgresql-17 is already in unstable. Please re-upload pg-gvm so it
moves to providing postgresql-17-pg-gvm (including binaries, will need
to go through NEW).

Let me know when you want me to do that.

Thanks,
Christoph

Bug#1082107: Regression tests unstable on PostgreSQL 17

[Christoph Berg]

Source: php-horde-db
Version: 2.4.1-8
Severity: grave
Tags: patch

Hi,

php-horde-db's primaryKey for PostgreSQL relies on undefined ordering
when reading the columns a primary key is defined on. So far it
worked, but in PostgreSQL 17, it fails. The attached patch makes it
use a proper catalog query.

209s There was 1 failure:
209s
209s 1) Horde_Db_Adapter_Pdo_PgsqlTest::testPrimaryKey
209s Failed asserting that two strings are equal.
209s --- Expected
209s +++ Actual
209s @@ @@
209s -'foo,bar'
209s +'bar,foo'

https://ci.debian.net/packages/p/php-horde-db/testing/armel/51827881/

I intend to NMU this as it's holding up the transition of PostgreSQL 17.

Christoph
--- a/Horde_Db-2.4.1/lib/Horde/Db/Adapter/Postgresql/Schema.php
+++ b/Horde_Db-2.4.1/lib/Horde/Db/Adapter/Postgresql/Schema.php
@@ -271,15 +271,18 @@ class Horde_Db_Adapter_Postgresql_Schema
 public function primaryKey($tableName, $name = null)
 {
 $sql = '
-SELECT column_name
-FROM information_schema.constraint_column_usage
-WHERE table_name = ?
-AND constraint_name = (SELECT constraint_name
-   FROM 
information_schema.table_constraints
-   WHERE table_name = ?
-   AND constraint_type = ?)';
+SELECT a.attname
+FROM
+pg_index i,
+unnest(indkey) WITH ORDINALITY u (attnum, pos)
+JOIN pg_attribute a ON u.attnum = a.attnum
+WHERE
+i.indisprimary
+AND i.indrelid = ?::regclass
+AND a.attrelid = i.indrelid
+ORDER BY u.pos';
 $pk = $this->selectValues($sql,
-  array($tableName, $tableName, 'PRIMARY KEY'),
+  array($tableName),
   $name);
 
 return $this->makeIndex($tableName, 'PRIMARY', true, true, $pk);

Bug#1082106: Regression tests unstable on PostgreSQL 17

[Christoph Berg]

Source: php-horde-db
Version: 2.4.1-8
Severity: grave
Tags: patch

Hi,

php-horde-db's primaryKey() method for PostgreSQL relies on undefined
ordering when reading the columns of a multi-column primary key. So
far this worked, but on PG17 (already in testing, but not the default
version yet), this breaks:

209s 1) Horde_Db_Adapter_Pdo_PgsqlTest::testPrimaryKey
209s Failed asserting that two strings are equal.
209s --- Expected
209s +++ Actual
209s @@ @@
209s -'foo,bar'
209s +'bar,foo'

https://ci.debian.net/packages/p/php-horde-db/testing/armel/51827881/

The attached patch makes it use a properly ordered catalog query.

I intend to NMU this since it's holding up the transition of PG17 as
the default PG version.

Thanks,
Christoph
--- a/Horde_Db-2.4.1/lib/Horde/Db/Adapter/Postgresql/Schema.php
+++ b/Horde_Db-2.4.1/lib/Horde/Db/Adapter/Postgresql/Schema.php
@@ -271,15 +271,18 @@ class Horde_Db_Adapter_Postgresql_Schema
 public function primaryKey($tableName, $name = null)
 {
 $sql = '
-SELECT column_name
-FROM information_schema.constraint_column_usage
-WHERE table_name = ?
-AND constraint_name = (SELECT constraint_name
-   FROM 
information_schema.table_constraints
-   WHERE table_name = ?
-   AND constraint_type = ?)';
+SELECT a.attname
+FROM
+pg_index i,
+unnest(indkey) WITH ORDINALITY u (attnum, pos)
+JOIN pg_attribute a ON u.attnum = a.attnum
+WHERE
+i.indisprimary
+AND i.indrelid = ?::regclass
+AND a.attrelid = i.indrelid
+ORDER BY u.pos';
 $pk = $this->selectValues($sql,
-  array($tableName, $tableName, 'PRIMARY KEY'),
+  array($tableName),
   $name);
 
 return $this->makeIndex($tableName, 'PRIMARY', true, true, $pk);

Bug#1081688: pgq-node: Needs update for pg 17

[Christoph Berg]

Re: Scott Kitterman
> Still builds postgresql-16-pgq-node and depends on cruft postgresql-16-pgq3

Hi Scott,

thanks for the ftp accept!

I'm aware of the dependency chains among the PG extensions, no need
for extra bugs.

Christoph

Bug#1074781: request-tracker5/4: autopkgtests don't work directly with new MariaDB 11.4

[Christoph Berg]

Re: Paul Gevers
> This happens often enough on some architectures on ci.d.n that the Release
> Team considers this RC. Because the unstable-to-testing migration software
> now blocks on regressions in testing, flaky tests, i.e. tests that flip
> between passing and failing without changes to the list of installed
> packages, are causing people unrelated to your package to spend time on
> these tests. Just like Otto did.

Fwiw, I stumbled over this last week when it was blocking
postgresql-17, and now again for blocking postgresql-common.

If you cannot fix the tests reliably, mark them as "flaky".

Thanks,
Christoph

Bug#1080959: Does not support PostgreSQL 17

[Christoph Berg]

Source: pygresql
Version: 1:6.0.1-1
Severity: serious

Please port pygresql to PostgreSQL 17. 17.0 will be released in 3
weeks, and 17rc1 is already in unstable. pygresql is the only package
holding back the testing migration of postgresql-17.

 67s ==
 67s FAIL: test_pqlib_version 
(tests.test_classic_functions.TestHasConnect.test_pqlib_version)
 67s --
 67s Traceback (most recent call last):
 67s   File 
"/tmp/autopkgtest-lxc.yghnd19b/downtmp/autopkgtest_tmp/tests/test_classic_functions.py",
 line 128, in test_pqlib_version
 67s self.assertLess(v, 17)
 67s AssertionError: 17 not less than 17
 67s
 67s --
 67s Ran 808 tests in 26.560s

https://ci.debian.net/packages/p/pygresql/testing/s390x/51277442/

This artificial version check seems to be the only test that is
failing, which is pretty silly when the package otherwise does work as
proved by all the other tests. Perhaps just remove it?

Christoph

Bug#1079816: ITS: antennavis

[Christoph Berg]

Re: Andreas Tille
> I would like to salvage your package antennavis by following the Package
> Salvaging procedur which is described in Developers Reference[1].

Fwiw, I believe this package is a candidate for removal.

The last upstream version is from 2010. I cannot believe it is still
useful, even when replacing the obsolete "nec" dependency by "nec2c".
The xnec2c package provides visualization of the simulation results
and should be a replacement for antennavis.

http://www.include.gr/antennavis.html

Christoph

Bug#1078851: Resignation & call for votes to elect the Chair

[Christoph Berg]

Re: Sean Whitton
> It has been an honour.

Thank you!

> ===BEGIN BALLOT
> 
> A: Christoph Berg 
> B: Matthew Garrett 
> C: Helmut Grohne 
> D: Stefano Rivera 
> E: Timo Röhling 
> F: Craig Small 
> G: Matthew Vernon 
> H: Sean Whitton 
> 
> ===END BALLOT

I vote

E > G > A = B = C = D = H > F

Christoph


signature.asc
Description: PGP signature

Bug#1078269: docker.io should depend on docker-cli

[Christoph Berg]

Package: docker.io
Version: 26.1.4+dfsg1-9
Severity: normal

I just got docker.io upgraded on trixie, and /usr/bin/docker was gone.
I don't think running dockerd without having the cli available makes
sense, please upgrade docker.io's "Recommends: docker-cli" to a
"Depends: docker-cli" so people won't have this "wtf" moment.

(The package description still claims to ship the cli, btw.)

Christoph

Bug#1078209: RM: py-postgresql -- RoQA; stale, does not support current PG security standards

[Christoph Berg]

Package: ftp.debian.org
Severity: normal
Tags: security
X-Debbugs-Cc: py-postgre...@packages.debian.org, Debian Python Team 
, Debian Security Team 

Control: affects -1 + src:py-postgresql
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove py-postgresql from unstable.

The current version is an ancient git snapshot (and upstream isn't
much newer), there are few popcon users, and the package doesn't
support PG's current login method (scram-sha-256 passwords).

I bet the 40-something users reported by popcon mostly mistakenly
installed this package when looking for a PostgreSQL driver for
Python. Let's get rid of this confusion.

Christoph

Bug#1077764: Call for votes: don't issue any ruling

[Christoph Berg]

Re: Luca Boccassi
> > BEGIN BALLOT
> >
> > The Technical Committee declines to overrule the maintainer of
> > base-files, or issue any advice on issues concerning /etc/os-release.
> >
> > We do not think there is a clear proposal on the table for us to assess,
> > and we do not think it is appropriate to issue any general statements on
> > the issues concerning /etc/os-release.
> 
> Seriously? In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#368
> you say that you could rule on the general statement rather than a
> specific implementation, then I answer "I'd prefer that if it was
> possible", and this is how you respond? I've asked multiple times
> exactly what it is that you need in order to make a decision, and all
> I get in response are first cryptic and contradicting statements, and
> then this abrupt dismissal. This seriously feels like something out of
> Kafka novel.

I vote A > N.

Luca: people would be much more likely to act positively on your
requests if you wouldn't call them Kafkaesque.

Christoph


signature.asc
Description: PGP signature

Bug#841433: ITP: gmat -- Spacecraft mission analysis, desing and simulation

[Christoph Berg]

Re: Rock Storm
> * Package name: gmat
>   Version : 2015a
>   Upstream Author : National Aeronautics and Space Administration
> * URL : http://gmatcentral.org

Seems to have moved to https://software.nasa.gov/software/GSC-17177-1

> * License : Apache-2.0
>   Programming Lang: C++
>   Description : Spacecraft mission analysis, desing and simulation

It requires Matlab to build, so it will need to be in contrib, with no
sane way to autobuild.

Given the last release was 2016 and this RFP hasn't attracted
interest, I'd suggest to just close it.

Christoph

Bug#1077764: Ruling request on os-release specification implementation

[Christoph Berg]

Re: Luca Boccassi
> The TL;DR is a request to override the base-files maintainer, and
> enable moving os-release into a new, independent and separate source
> package, so that these bugs may finally be fixed, and Debian's os-
> release may finally be made compliant with the specification.

If we are fixing that, we should also fix /etc/debian_version in the
same way. I've always been wondering why we don't put better content
into these files.

(Though I'm not sure the ruling should include the "move to new source
package" part. It could also be fixed inside base-files.)

Christoph

Bug#1075404: py-postgresql: ftbfs with GCC-14

[Christoph Berg]

Re: Matthias Klose
> Package: src:py-postgresql
> Version: 1.2.1+git20180803.ef7b9a9-4

I believe instead of fixing this bug, we should remove
python3-postgresql. I've never seen it being used anywhere in the
wild, and the last version is a git snapshot from 2018. There are no
reverse dependencies, and the popcon count is only 44 (probably from
users looking for a PostgreSQL driver for Python, and mistakenly
ending up here).

I'll file a RoM in a week.

Christoph

Bug#1077330: RM: pgloader [i386] -- ROM; Architecture not supported anymore

[Christoph Berg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pgloa...@packages.debian.org
Control: affects -1 + src:pgloader
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove pgloader/i386 from unstable. The lisp maintainers do not
want to support cl-ironclad on i386 anymore, and pgloader
build-depends on it (#1077220).

Christoph

Bug#950919: [3dprinter-general] Bug#950919: Bug#950919: cura: unable to remove annoying popup message

[Christoph Berg]

Re: Gregor Riepl
> - Packaging trimesh for 64-bit archs only

That wouldn't be a problem.

Christoph

Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file

[Christoph Berg]

Re: Diederik de Haas
> When removing or 'even' purging a linux-image- package, it
> reports the following issue:
> 
> rmdir: failed to remove '/lib/modules/': Directory not empty
> 
> The reason for that is that there's still a ``modules.weakdep`` file.

I just had the same problem on linux-image-6.6.15-amd64.

> It seems to me that at least with purging that file should be removed
> and subsequently the ``/lib/modules/`` dir.

TBH, I'd even argue plain "remove" should remove the debris from the
modules directory, it's not like there's anything of value in the
modules.* files left behind.

Kernels are the only package that I'm actually purging, if "remove"
wouldn't leave /lib/modules/*/ behind, I wouldn't have to do that.

Christoph

Bug#1073790: cqrlog should depend on mariadb instead of mysql

[Christoph Berg]

Re: Dave Hibberd
> Something didn’t quite add up so I went digging further - it turns out that 
> Ubuntu is shipping mysql-* as mysql-* and Debian is shipping mariadb-* as 
> mysql-*, see:
> https://salsa.debian.org/mariadb-team/mysql/-/blob/mysql-defaults/debian/master/debian/rules
>  for the specific exception.

Ubuntu seems to have been switching back and forth between the two
mysql flavors - I've given up on tracking that in the mysql-touching
PostgreSQL packages (postgresql-mysql-fdw, ...).

If cqrlog only works with one of them, we should depend directly on
that server instead of using the default-mysql-whatever meta packages.

(If this were PostgreSQL I would tell you that depending is wrong
since you can access databases across the network, but I guess mysql
doesn't work like that in this context.)

Christoph

Bug#1073507: postgresql-16-pgnodemx: Incomplete package description

[Christoph Berg]

Re: Teemu Hukkanen
> The package description is incomplete, both the short and long
> description have "FIXME" at the beginning, without a useful description.

Oops, thanks for spotting!

Christoph

Bug#1073040: dput: Fails when processing ssh_config_options value: AttributeError: 'list' object has no attribute 'split'

[Christoph Berg]

Re: Ben Finney
> At https://salsa.debian.org/debian/dput/-/merge_requests/15> is a
> merge request proposing to fix this bug.
> 
> Can you try the resulting Dput package, and confirm whether it corrects the
> behaviour in your case?

Hi,

I don't think I have any ssh options set - it was already failing on
the default case. I'd say just upload and I'll report back if it's
still failing.

Thanks!

Christoph

Bug#1059476: postgresql-15: backend crash caused by query in llvm on arm64

[Christoph Berg]

Re: Stefan Heine
> how can I find, what version of the llvm library a given version of postgres
> is linked to?

It should be visible in the linker flags:

select * from pg_config();

LDFLAGS   │ -Wl,-z,relro -Wl,-z,now -L/usr/lib/llvm-16/lib 
-Wl,--as-needed

Christoph

Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:

[Christoph Berg]

Re: Martin-Éric Racine
> Incorrect delayed argument: ValueError: delayed days value must be a decimal 
> integer:

`dput -e 0` works around that part of the problem. I then ran into
another problem though:

Uploading to ssh-upload [DELAYED/0-day] (via scp to ssh.upload.debian.org):
Traceback (most recent call last):
  File "/usr/bin/dput", line 33, in 
sys.exit(load_entry_point('dput==1.2', 'console_scripts', 'execute-dput')())
 ^^
  File "/usr/share/dput/dput/dput.py", line 1548, in main
upload_files(
  File "/usr/share/dput/dput/dput.py", line 1267, in upload_files
upload_func(
  File "/usr/share/dput/dput/dput.py", line 1152, in upload_files_via_method_scp
line.strip() for line in ssh_config_options.split("\n"))
 
AttributeError: 'list' object has no attribute 'split'

Christoph

Bug#1053004: CVE-2019-10784 and CVE-2023-40619

[Christoph Berg]

Re: Moritz Mühlenhoff
> Agreed, if the package is actually broken with the version of PostgreSQL
> in stable and if there's no sensible backport for the open security issues,
> then let's rather remove it by the next point release.

Ack.

Christoph

Bug#1071030: postgresql-15: Drop database hang.

[Christoph Berg]

Re: Владимир Ступин
> Trouble solved with restarting PostgreSQL.

Hi,

I'm glad you solved it.

My guess would be that there was something (likely a background
worker) still connected to that database and DROP DATABASE couldn't
get the proper lock on it.

I guess there is nothing to actually fix (at least on the PG side),
can we close the bug?

Christoph

Bug#1071030: postgresql-15: Drop database hang.

[Christoph Berg]

Re: Vladimir Stupin
> Package: postgresql-15
> Version: 15.6-0+deb12u1
> 
> dropdb on any database hangs up. pg_activity shows query DROP DATABASE
> ; in state ProcSignalBarrier.
> 
> I found fix for the trouble at 
> https://www.postgresql.org/message-id/E1pKAd5-005BKs-Vr%40gemulon.postgresql.org
> 
> I use apt-source to check sources to found fix described at link above.
> Sources was not fixed. Please update package to fix the trouble.

Hi,

the fix you link to was included in 15.2 as 
267135d01d79c63dfba7fe69dd3b40c125c49a6f.
How did you determine it wasn't included?

Can you pull a backtrace of the hanging process?
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

Christoph

Bug#1070064: separate columns by 2 spaces in lists

[Christoph Berg]

Package: apt
Version: 2.9.2
Severity: wishlist

Hi,

I like the output to format lists of packages into ls-style tables
very much, thanks.

A suggestion: I would prefer if the columns were separated by 2 spaces
instead of just one, to make the spacing visually better. ls does that
as well, and my eyes are trained to reading that.

What makes it perhaps worse is that a lot of package names have - dashes
in them, which look a bit like (single) spaces on first glance. Using
double spaces would fix that problem as well.

Last instance of the problem here was this:

REMOVING:
  libhwy1 python3-editables

... which looked like libhwy1-python3-editables to me.

Thanks for considering,
Christoph

Bug#1069890: Resignation & call for votes to elect the Chair

[Christoph Berg]

Re: Sean Whitton
> ===BEGIN
> 
> A: Christoph Berg 
> B: Matthew Garrett 
> C: Helmut Grohne 
> D: Stefano Rivera 
> E: Timo Röhling 
> F: Craig Small 
> G: Matthew Vernon 
> H: Sean Whitton 
> 
> ===END

I vote

  H > ABCDEG > F

Christoph


signature.asc
Description: PGP signature

Bug#1069175: Mention "megacli" in Description

[Christoph Berg]

Package: megactl
Version: 0.4.4-1
Severity: wishlist

Hi,

when looking for megacli replacements in Debian, this package doesn't
show up. I think the description could mention it.

Description-en: LSI Megaraid Control and Monitoring Tools
 Reports diagnostics on megaraid and megaraid_sas adapters and
 attached disks. The adapters are also known as Dell PERC2, PERC3,
 PERC4 and PERC5.  Permits dumping of controller log pages for
 inspection of error, temperature, and self-test conditions, initiates
 self-test diagnostics, and documents adapter and logical drive
 configuration. Target devices may be adapters, (e.g. a0), enclosures
 (e.g. a0e0), or individual disks (e.g. a0e0s0). If no target is
 specified, reports configuration and drive state on all adapters.

Perhaps like this?

 Reports diagnostics on megaraid and megaraid_sas adapters and
 attached disks, similar to the original "megacli" tool. ...

Christoph

Bug#1067831: libaio: the t64 package slipped through and is in testing

[Christoph Berg]

Re: Raphael Hertzog
> There are (proprietary) software out there that link against it and we
> happen to ship some in Kali's non-free (oracle-instantclient-*).
> 
> https://pkg.kali.org/pkg/oracle-instantclient-basic
> https://pkg.kali.org/pkg/oracle-instantclient-devel
> 
> It would be nice if we could continue to keep compabitility with binaries
> compiled against upstream's SONAME.

Fwiw I've now stumbled over this for the same reason - the
Oracle-interfacing packages on apt.postgresql.org are now
uninstallable on Ubuntu 24.04 noble which has already picked up this
rename.

I tried to paper over the problem by making them depend on
"libaio1 | libaio1t64" but since the .so file was also renamed, this
doesn't work.

The installation instructions for Oracle on Linux have been "install
libaio1 and then run this giant installer" for the past few decades,
so this rename is going to confuse quite a few people if not reverted.

Christoph

Bug#1002458: "version in VCS newer than in repository" might be a bit overzealous

[Christoph Berg]

Control: reassign -1 qa.debian.org
Control: retitle -1 vcswatch: ignore changelog-only commits

Re: Holger Levsen
> > For starters, an early release could classify changelog-only commits as
> > "housekeeping".
> 
> *that*!
> 
> additionally you could also only classify d/changelog changing commits
> with "Gbp-Dch: ignore" in them as such, but I'd guess Marc's suggestion
> really is good enough.

I don't understand, if debian/changelog-only commits are already
ignored, what should vcswatch do additionally?

> Please reconsider, IOW, Myon: my I reassign this back to qa.debian.org
> for vcswatch?

Done.

Christoph

Bug#1068373: RM: libzia/experimental -- ROM; Merged into tucnak

[Christoph Berg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: lib...@packages.debian.org
Control: affects -1 + src:libzia
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I had somehow assumed that #1064844 would result in the removal of
libzia from both unstable and experimental, but of course it only got
removed from unstable. So, here I am again:

Please remove libzia from experimental.

The library is now part of the tucnak source since it doesn't get
released (and used) independently.

Thanks,
Christoph

Bug#1064708: pygame: FTBFS: AssertionError: "No video mode" does not match "Parameter 'surface' is invalid"

[Christoph Berg]

Control: severity -1 serious

Re: Peter Michael Green
> > severity 1064708 important
> Can you explain why you downgraded this bug? it looks rc to me
> and is blocking the time_t transition.

I think I mistakenly downgraded it along with some other "t64 nmu diff" bugs.

Christoph

Bug#1066067: cl-plus-ssl: hardcoded libssl3 dependency

[Christoph Berg]

Re: Sebastian Ramacher
> Source: cl-plus-ssl
> Version: 20220328.git8b91648-4
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> cl-plus-ssl hardcodeds a dependency on libssl3. Due to the time_t
> transition, the package name changed and the dependency needs to be
> updated.

It actually doesn't hard-code the dependency but correctly extracts it
from libssl-dev. But since we don't have arch:all binnmus, a new
upload was needed anyway. Just did that.

Once cl-plus-ssl is installed, please binnmu pgloader to have it pick
up the changed dependency.

Christoph

Bug#980150: RFA: cyrus-imspd -- Internet Message Support Protocol daemon

[Christoph Berg]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: cyrus-imspd -- RoM; FTBFS and probably full of CVEs

> I request an adopter for the cyrus-imspd package as I am not using it
> myself.
> 
> The package description is:
>  This package contains the cyrus-imspd daemon for the Internet Message Support
>  Protocol (imsp), providing central storage for addressbooks and application
>  config.

This didn't have any takers in 3 years, and the package is now
FTBFSing (#1066480) with C code so ancient it's a PITA to fix, so
let's get it removed.

Christoph

Bug#1067144: [3dprinter-general] Bug#1067144: uranium: missing depend on python3-all for autopkgtest

[Christoph Berg]

Re: Gregor Riepl
> I pushed a simple patch to add the dependency, would be nice if you could
> release it, @myon? Thanks in advance.

On its way, thanks for the update!

Christoph

Bug#1064697: flask-babelex: FTBFS: ImportError: cannot import name '_request_ctx_stack' from 'flask' (/usr/lib/python3/dist-packages/flask/__init__.py)

[Christoph Berg]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: flask-babelex -- obsolete

Re: Colin Watson
> Should we just remove this package from Debian?  I'm CCing everyone
> who's uploaded it in the past just in case, but I suspect this is an
> easy decision.

Yeah, let's just do that. Thanks for looking into the details!

Christoph

Bug#1066980: Please include "notify-send" in package description

[Christoph Berg]

Package: libnotify-bin
Version: 0.8.3-1
Severity: wishlist

This package solely ships "notify-send", but doesn't mention it in the
package description, so "apt-cache search notify send" doesn't find
it.

Please consider mentioning it, perhaps like this:

Description-en: sends desktop notifications to a notification daemon (Utilities)
 A library that sends desktop notifications to a notification daemon, as
 defined in the Desktop Notifications spec. These notifications can be
 used to inform the user about an event or display some form of
 information without getting in the user's way.
 .
 This package contains the notify-send command line utility.

Thanks,
Christoph

Bug#1066034: tech-ctte: proposed constitution fix and social contract chg to make documentation accessible to all people

[Christoph Berg]

Re: debbug.tech-c...@sideload.33mail.com
> # The DSC needs to become meaningful
> 
> Chuck Zmudzinski filed a bug report saying that the Debian Social
> Contract (DSC) is “meaningless”:

Hi,

I don't think the tech-ctte is the right body to address this.

Also, please file request using a name, we'd want to know who we
are talking to.

Christoph

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Christoph Berg]

> ===BEGIN
> The Technical Committee recommends that Craig Small  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> C: Recommend to Appoint Craig Small 
> F: Further Discussion
> ===END

I vote

  C > F

Christoph


signature.asc
Description: PGP signature

Bug#1032623: marked as done (vcswatch: should not raise error on repos > 1GiB in size)

[Christoph Berg]

> It looks like this broke for remotes that do not support filtering
> (yet?). The attached completely untested patch might make this work
> again. Affecting at least git.hadrons.org and git.dpkg.org, but there
> might be others too.

Thanks for spotting that, the patch seems to work.

Re-running the scan on the dpkg repo still takes around 3 minutes -
not sure what the client or the server are doing during that time, it
doesn't re-fetch the repo.

On acl and attr the scan is done in 2 or 3s.

Christoph

Bug#1032623: fixed in qa.debian.org

[Christoph Berg]

Re: Diederik de Haas
> The pre-filter which was 1GB and was recently further reduced to 500MB is 
> still 
> in place AFAICT. So it seems to me that this bug would be fixed when the size 
> limitation is removed, which is not (yet) the case?

The checkouts are now a 1/1000th in size.

Christoph

Bug#1053004: CVE-2019-10784 and CVE-2023-40619

[Christoph Berg]

Re: Leandro Cunha
> The
> next job would be to make it available through backports and I would
> choose to remove this package from stable. But I would only leave
> bookworm backports due to other bugs found (this CVEs too) and fixed
> in 7.14.7.
> I have to search about the status of backports to oldstable. But I'm
> also studying the possibility of working with patches for these two
> versions.

Why would you want to remove it from stable? In closed environments,
CVEs are often not a problem.

Christoph

Bug#1065425: Does not upgrade from libpam0t64

[Christoph Berg]

Package: libpam0g
Version: 1.5.3-6
Severity: serious

On my sid system, libpam0g doesn't get upgraded because apt thinks the
libpam0t64 package is good enough:

$ sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

$ apt-cache policy libpam0t64
libpam0t64:
  Installed: 1.5.3-4
  Candidate: 1.5.3-4
  Version table:
 *** 1.5.3-4 100
100 /var/lib/dpkg/status

$ apt-cache policy libpam0g
libpam0g:
  Installed: (none)
  Candidate: 1.5.3-6
  Version table:
 1.5.3-6 500
500 http://deb.debian.org/debian sid/main amd64 Packages
 1.5.2-9.1+b1 -1
100 /var/lib/dpkg/status

Christoph

Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

[Christoph Berg]

Re: Simon McVittie
> libglib2.0-0t64 could gain a preinst that deletes
> /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm. This is a clear
> Policy violation, but perhaps between closely cooperating packages
> (glib2.0 and, er, glib2.0) it would be the least-bad answer to this?

That doesn't sound too bad to me.

> Possible solution: other ideas?

Make glib2.0-t64 use a different cache filename?

> If the solution that is chosen is a Policy violation (like deleting
> the problematic postrm) then I would also like to have clarity that the
> Policy violation is tolerable as a less-bad solution, and therefore will
> not itself be treated as a RC bug in trixie.

I would tend to treat policy as a set of rules that you normally
shouldn't break, but if there's a clear argument why it makes sense in
given case, it would be quite silly to reject that solution just
because of formal reasons.

Christoph

Bug#1065000: pgpool2: the package fails to build on armhf due to gcc-13 13.2.0-16.1 changes

[Christoph Berg]

Re: Vladimir Petko
> armhf has -Werror=implicit-function-declaration enabled in default gcc flags 
> of
> gcc-13 13.2.0-16.1.

Huh, why only on armhf? That makes debugging this a bit hard.

>   Would it be possible to consider a merge request[1] that addresses this 
> issue?

I'm looking now.

Fwiw, since I have your attention, what's up with resource-agents on
noble? I see the source is present in that dist, but no binary?

Christoph

Bug#986711: z8530-utils2: diff for NMU version 3.0-1-10.1

[Christoph Berg]

Re: Chris Hofstaedtler
> I've prepared an NMU for z8530-utils2 (versioned as 3.0-1-10.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.

Thanks! I converted it to a proper maintainer upload since there were
already pending changes in git from the Janitor and canceled your
upload.

Christoph

Bug#1064838: Processed: Re: Bug#1064838: New package names break APT safety features, ability to co-install different ABIs

[Christoph Berg]

Control: reassign -1 linux

Re: Debian Bug Tracking System
> Processing control commands:
> 
> > reassign -1 tech-ctte
> Bug #1064838 [src:linux] New package names break APT safety features, ability 
> to co-install different ABIs

Please only reassign to tech-ctte after the actual discussion has
finished with an open dispute. I see you have open questions to Julian
in the bug.

Christoph

Bug#1064844: RM: libzia -- ROM; integrated into tucnak now

[Christoph Berg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: lib...@packages.debian.org, debian-h...@lists.debian.org
Control: affects -1 + src:libzia
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove libzia from unstable. The tucnak package now includes
libzia as an extra orig-libzia tarball. The split never made sense
technically as both needed to be upgraded in lockstep and there's only
tucnak as libzia rdep.

Christoph

Bug#1062742: libzia: NMU diff for 64-bit time_t transition

[Christoph Berg]

Re: Daniele Forsi
> please don't put version numbers in the package descriptions:

For libzia, it's also questionable to put the version number into the
package - that "lib" is only used by a single rdep, tucnak. We should
rather move libzia into tucnak; the split has causes several problems
in the past, while adding no value.

Christoph

Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

[Christoph Berg]

Re: Steve Langasek
> Sorry, did you manage to get sensible a-c-c output?  Otherwise, how did you
> determine that there was a single symbol affected?  The only compat_report
> output I have shows *zero* symbols affected but also shows a bunch of
> garbage output that makes me not trust it at all.

That was in a different sub-thread on this bug:

  For postgresql-16 (where libpq-dev comes from), the only symbol
  affected seems to be pqWaitTimed as indicated above.

  The good news is that the function is only used internally in libpq,
  and by no external user:

  https://codesearch.debian.net/search?q=pqWaitTimed&literal=1
  https://github.com/search?q=pqWaitTimed&type=code

  (GitHub finds a bunch of instances, but these are all either
  PostgreSQL itself, or vendored copies of libpq.)

  So I think we can safely ignore the difference and not rename libpq5.
  (It has been named like that for 20 years and I really don't want to
  break compatibility there.)

Christoph

Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

[Christoph Berg]

Re: Steve Langasek
> postgresql-server-dev-16 also shows up as impacted by LFS but the output is
> confusing, mentioning only redefinitions of constants from perl and python
> headers, why should those have disappeared based on defining LFS flags?  The
> changes are suspicious enough that I'm not prepared to conclusively declare
> it a false positive.

postgresql-16 as a whole source package contains a single affected
symbol that is not used by any external user (as per
codesearch.debian.org and github.com).

Please exclude postgresql-16 from the transition.

Where am I supposed to file these requests so they don't get
forgotten?

Christoph

Bug#1063777: Error: pg_wrapper: pgbench was not found in /usr/lib/postgresql/16/bin

[Christoph Berg]

Control: forwarded -1 https://salsa.debian.org/postgresql/postgresql/-/issues/1

Re: Jochen Sprickerhof
> The executable is in postgresql-16. So I would propose to either move
> /usr/bin/pgbench to postgresql or /usr/lib/postgresql/16/bin/pgbench to
> postgresql-client-16.

Ack.

This has already been filed as 
https://salsa.debian.org/postgresql/postgresql/-/issues/1 .

I guess I should give it another try, the alternative symlink farms
were simplified a few postgresql-common versions back.

Christoph

Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

[Christoph Berg]

Re: Adrien Nader
> Nice! Watch out though if you don't use a container: the script can
> change your system.

Hi Adrien,

thanks for the detailed answers.

I was using a chroot, that seems to have been enough isolation.

> You also need to run it on armhf to have the correct
> machine definitions.

... on i386. I'd think that should give the same answer.

> - compat_reports/libpq-dev/lfs_to_time_t/compat_report.html
> - compat_reports/libpq-dev/base_to_lfs/compat_report.html

That's where I got the "100%" from...

> On libpq-dev, I see that there is no LFS effect (abi-compliance-checker
> reports 100% compat) but there is a time_t one.
> 
> Looking at the HTML reports, the cause is:
> 
>   pqWaitTimed ( int forRead, int forWrite, PGconn* conn, long finish_time )
> 
> The ABI is therefore time_t-dependant. With an insider POV, you can
> maybe find reasons this doesn't matter; that's not something I can do
> however.

...Mmmh. I did not get that. Is that because of i386 vs armhf?

> Anyway, as I said and after many quirks, I got it to dump and diff: the
> ABI of libpg-query-dev is affected by both LFS and time_t.
> 
> NB: I think a-c-c reports symbol changes as removal + addition
> 
> You can review the change summary below. Maybe some symbols are
> internal-only, or not actually visible in normal usage, or definitions
> of symbols that are not in the package's libs (could be libc for
> instance: we can't map symbols from headers to shared objects shipped by
> the corresponding library package).

I would guess the difference is irrelevant in pracise, but since
libpg-query changes sonames fairly often, we dont't have to dig
deeper, let's just rename the library and be done.


For postgresql-16 (where libpq-dev comes from), the only symbol
affected seems to be pqWaitTimed as indicated above.

The good news is that the function is only used internally in libpq,
and by no external user:

https://codesearch.debian.net/search?q=pqWaitTimed&literal=1
https://github.com/search?q=pqWaitTimed&type=code

(GitHub finds a bunch of instances, but these are all either
PostgreSQL itself, or vendored copies of libpq.)

So I think we can safely ignore the difference and not rename libpq5.
(It has been named like that for 20 years and I really don't want to
break compatibility there.)

Christoph

Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

[Christoph Berg]

Re: Adrien Nader
> I think the most recent version of that script would be in my
> repository: https://salsa.debian.org/adrien-n/armhf-time_t/

Hi Adrien,

I actually got the script running, I think. I pushed a few
https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/132 that
have not been merged yet, though.

I guess when it says "Compatibility: 100%", everything is ok? I got
that on libpq-dev.

What I'm completely missing is an overview which *source* packages are
affected. I really want to avoid having postgresql-16 included in this
transition, and I am not yet sure if it's considered to be affected or
not.

> I'll probably give it a quick shot again today but I don't have much
> time; unless errors are few and obvious, it's unlikely that I will make
> much progress on it though.

On libpg-query-dev, the problem is that the script puts some
windows-only headers into the include path that then shadow a system
header that should actually be used:

The GCC parameters:
  gcc -fdump-lang-raw -fkeep-inline-functions -c -x c++ -fpermissive -w 
"/tmp/8yhLzFzeyA/dump1.h"  -I/usr/include/pg_query/postgres 
-I/usr/include/pg_query/postgres/utils 
-I/usr/include/pg_query/postgres/port/win32_msvc 
-I/usr/include/pg_query/postgres/port/win32

In file included from /usr/include/pg_query/postgres/port/win32/netinet/tcp.h:5,
 from /usr/include/pg_query/postgres/libpq/libpq-be.h:26,
 from /usr/include/pg_query/postgres/libpq/auth.h:17,
 from /tmp/8yhLzFzeyA/dump1.h:174:
/usr/include/pg_query/postgres/port/win32/sys/socket.h:14:10: fatal error: 
winsock2.h: No such file or directory
   14 | #include 
  |  ^~~~
compilation terminated.


This -I/usr/include/pg_query/postgres/port/win32 should not be there.

Thanks,
Christoph

Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

[Christoph Berg]

Re: Steve Langasek
> If you as maintainer want to close this bug report (indicating that no
> transition is required) or un-tag it 'pending' (indicating that a transition
> may be required but the patch is not ready to upload), and accept any
> fallout if it turns out this is incorrect, that will mark it so that we will
> not include it in NMUs to unstable.

Is there any writeup on what verification steps I have to do to do
that assessment? All I could find so far are very long lists of
packages without any explanation, and a wiki page that outlines a
plan, but doesn't have any instructions for maintainers.

Christoph

Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition

[Christoph Berg]

Control: tags -1 = moreinfo

Re: Steve Langasek
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.

Hi,

I just found out that libpg-query is included because it was thought
to be "uninstallable":

https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/logs/libpg-query-dev/apt.log

[2024-01-20T03:02:49+00:00] apt-get install libpg-query-dev libprotobuf-c-dev 
postgresql-server-dev-15 abi-compliance-checker
E: Unable to locate package postgresql-server-dev-15

I think that's bogus, the package has not been depending on PG15 for
some time.

Please exclude it from the NMUs.

Also, why did I not get a bug for that? I understand that you can't
look at 1500 packages individually, but checking the 40-something on the
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/summary/results_uninstallable.txt
list would surely have been possible?

Christoph

Bug#1063144: please mention "keyctl" in package description

[Christoph Berg]

Package: keyutils
Version: 1.6.3-2+b2
Severity: wishlist

The keyutils package description mentions it's a "set of utilities",
but doesn't mention the name "keyctl", so when apt-searching for that,
the package doesn't turn up.

Please consider mentioning that name in the package description.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 keyutils depends on:
ii  libc6 2.37-14
ii  libkeyutils1  1.6.3-2+b2

keyutils recommends no packages.

keyutils suggests no packages.

-- no debconf information

Thanks,
Christoph

Bug#1054974: behave: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Christoph Berg]

Re: Andrius Merkys
> The patch proposed in #1042610 does not fix test failure. Interestingly, the
> failure seems to be nondeterministic: after patching #1042610 some builds
> succeed. However, I did not manage to find the root cause.

The difference between a working and a failing run is this diff:

dh_auto_test -O--buildsystem=pybuild
-I: pybuild base:305: cd 
/home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; 
python3.12 -m pytest test
+I: pybuild base:305: cd 
/home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; 
python3.12 -m pytest tests

I.e. pybuild invokes either
   "python3.12 -m pytest test" (good)
or "python3.12 -m pytest tests" (bad)

I tried to drill down where this decision is made but couldn't spot
it.

As a workaround, we can move the "tests" directory aside. Then it will
reliably run the "test" target. (Not pretty, but I want to get the
package unstuck.)

Christoph

Bug#1060659: pgmodeler FTCBFS: hard codes the build architecture qmake6

[Christoph Berg]

Re: Helmut Grohne
> pgmodeler fails to cross build from source, because debian/rules hard
> codes the build architecture qmake6. We recently extended debhelper with
> a qmake6 buildsystem that will handle cross building correctly. I'm
> attaching a patch for your convenience.

Hi Helmut,

thanks for the patch!

Fwiw, I'll postpone applying it until DH 13.11.9 is in
bookworm-backports and hopefully also available in jammy-backports.

Christoph

Bug#1060115: vcswatch: look for changelog in debian/experimental branch

[Christoph Berg]

Re: Martin
> + my @branch_list = qw(HEAD debian debian/master debian/sid 
> debian/latest debian/experimental master);

Applied, thanks!

Christoph

Bug#1058937: /usr-move: Do we support upgrades without apt?

[Christoph Berg]

Re: Helmut Grohne
> Is it ok to call upgrade scenarios failures that cannot be reproduced
> using apt unsupported until we no longer deal with aliasing?
> 
> If the answer is yes here, we'll close #1058937 (Ben's libnfsidmap1 bug)
> with no action calling the scenario unsupported.

I think we should only deal with problems that can reasonably happen
in practice. If an extra hammer is required to hit the problem, we
should not spend extra effort on it.

Christoph

Bug#1057271: postgresql-15 decrufting

[Christoph Berg]

Package: ftp.debian.org
Severity: normal

postgresql-15 has been removed from unstable (thanks!), but there is
still cruft in the archive that prevents pgtap from migrating to
testing.

Please decruft everything matching "postgresql-15-*":

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on amd64,arm64,armel,armhf,i386,mips64el,ppc64el,riscv64,s390x
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq)" -s unstable -a 
amd64,arm64,armel,armhf,i386,mips64el,ppc64el,riscv64,s390x -p -R -b 
postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package repmgr version 5.3.3-4 no longer builds
  binary package(s): postgresql-15-repmgr
  on amd64,arm64,armel,armhf,i386,mips64el,ppc64el,riscv64,s390x
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by repmgr)" -s unstable -a 
amd64,arm64,armel,armhf,i386,mips64el,ppc64el,riscv64,s390x -p -R -b 
postgresql-15-repmgr
  - broken Depends:
repmgr: repmgr

* source package londiste-sql version 3.8-4 no longer builds
  binary package(s): postgresql-15-londiste-sql
  on all
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by londiste-sql - based on 
source metadata)" -s unstable -a all -p -R -b postgresql-15-londiste-sql
  - No dependency problem found

* source package mimeo version 1.5.1-17 no longer builds
  binary package(s): postgresql-15-mimeo
  on all
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by mimeo - based on source 
metadata)" -s unstable -a all -p -R -b postgresql-15-mimeo
  - No dependency problem found

* source package pg-track-settings version 2.1.2-2.1 no longer builds
  binary package(s): postgresql-15-pg-track-settings
  on all
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pg-track-settings - 
based on source metadata)" -s unstable -a all -p -R -b 
postgresql-15-pg-track-settings
  - No dependency problem found

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on i386
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq - based on source 
metadata)" -s unstable -a i386 -p -R -b postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on amd64
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq - based on source 
metadata)" -s unstable -a amd64 -p -R -b postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on armel
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq - based on source 
metadata)" -s unstable -a armel -p -R -b postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on armhf
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq - based on source 
metadata)" -s unstable -a armhf -p -R -b postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on s390x
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq - based on source 
metadata)" -s unstable -a s390x -p -R -b postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on arm64
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq - based on source 
metadata)" -s unstable -a arm64 -p -R -b postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on ppc64el
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq - based on source 
metadata)" -s unstable -a ppc64el -p -R -b postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on mips64el
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq - based on source 
metadata)" -s unstable -a mips64el -p -R -b postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package pgq version 3.5-3 no longer builds
  binary package(s): postgresql-15-pgq3
  on riscv64
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by pgq - based on source 
metadata)" -s unstable -a riscv64 -p -R -b postgresql-15-pgq3
  - broken Depends:
pgq-node: postgresql-15-pgq-node

* source package pgq-node version 3.5-5 no longer builds
  binary

Bug#1056717: RM: postgresql-15 -- ROM; Superseded by postgresql-16

[Christoph Berg]

Re: To Debian Bug Tracking System
> Please remove postgresql-15 from unstable. All reverse dependencies
> have transitioned to postgresql-16.
> 
> The remaining problems quoted below are arch:all packages not yet
> decrufted (postgresql-15-*), or one binnmu away from being fixed
> (glom, not sure why that was missed on riscv64, will get that done).

Fwiw, glom has been binnmued, so the PG15 removal can proceed now.

Christoph

Bug#1056961: transition: limesuite

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: limesu...@packages.debian.org
Control: affects -1 + src:limesuite

Hi,

I'm sorry that I rushed that with neglecting to ask for coordination -
perhaps the Cambridge Minidebconf was too exciting and I just
uploaded. Anyway:

There is a new limesuite version in unstable, and the 3 reverse-deps
need binnmus "Rebuild against limesuite 23.11.":

gr-limesdr
indi-limesdr
osmo-trx

https://release.debian.org/transitions/html/auto-limesuite.html

Thanks,
Christoph

Bug#959891: pgbench in wrong package?

[Christoph Berg]

Re: Peter Eisentraut
> pgbench is in the postgresql-client-common package [0], but the actual
> per-version binaries are in the server package, e.g., postgresql-16 [1].  If
> you try to call pgbench without installing the server package, it tells you
> 
> Error: You must install at least one postgresql-client- package
> 
> but that is wrong advice in this situation.
> 
> Is there are reason for this arrangement?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959891

Mostly a historical mistake that has been difficult to fix because of
the update-alternatives trees for the manpages, where moving "slave"
links from one tree to another is quite hard. I think it's possible to
revisit that now that the client and server manpage trees have been
merged.

> (The same confusion applies to vacuumlo.)

Ack.

Christoph

Bug#1056717: RM: postgresql-15 -- ROM; Superseded by postgresql-16

[Christoph Berg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: postgresql...@packages.debian.org
Control: affects -1 + src:postgresql-15

Please remove postgresql-15 from unstable. All reverse dependencies
have transitioned to postgresql-16.

The remaining problems quoted below are arch:all packages not yet
decrufted (postgresql-15-*), or one binnmu away from being fixed
(glom, not sure why that was missed on riscv64, will get that done).

Please remove postgresql-15 well before the upcoming bookworm point
release, the SRMs would prefer to update postgresql-15 in bookworm
without having an older package in unstable around.

$ dak rm -nR postgresql-15
Will remove the following packages from unstable:

postgresql-15 | 15.4-3 | source, amd64, arm64, armel, armhf, i386, 
mips64el, ppc64el, riscv64, s390x
postgresql-client-15 | 15.4-3 | amd64, arm64, armel, armhf, i386, mips64el, 
ppc64el, riscv64, s390x
postgresql-doc-15 | 15.4-3 | all
postgresql-plperl-15 | 15.4-3 | amd64, arm64, armel, armhf, i386, mips64el, 
ppc64el, riscv64, s390x
postgresql-plpython3-15 | 15.4-3 | amd64, arm64, armel, armhf, i386, 
mips64el, ppc64el, riscv64, s390x
postgresql-pltcl-15 | 15.4-3 | amd64, arm64, armel, armhf, i386, mips64el, 
ppc64el, riscv64, s390x
postgresql-server-dev-15 | 15.4-3 | amd64, arm64, armel, armhf, i386, 
mips64el, ppc64el, riscv64, s390x

Maintainer: Debian PostgreSQL Maintainers 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
glom: glom [riscv64]
  glom-utils [riscv64]
londiste-sql: postgresql-15-londiste-sql
mimeo: postgresql-15-mimeo
pg-track-settings: postgresql-15-pg-track-settings
pgq: postgresql-15-pgq3
pgq-node: postgresql-15-pgq-node
pgtap: postgresql-15-pgtap
repmgr: postgresql-15-repmgr

Dependency problem found.


Thanks,
Christoph

Bug#1055468: [3dprinter-general] Bug#1055468: python3-charon: Warning during boot about "Unknown username "ultimaker" in message bus configuration file"

[Christoph Berg]

Re: Gregor Riepl
> > During boot, I get a warning about a missing username "ultimaker".

> @myon, could we release a backported fix to bookworm, or should we leave it
> as it is? I don't have much experience with stable packaging policies.

Since it's just a warning, I wouldn't touch it. Stable updates are
possible, but need poking the stable release managers who have more
interesting problems to fix.

Christoph

Bug#1054697: [3dprinter-general] Bug#1054697: slic3r-prusa: FTBFS: test_arrange.cpp:1:10: fatal error: catch2/catch.hpp: No such file or directory

[Christoph Berg]

Re: Gregor Riepl
> > fatal error: catch2/catch.hpp: No such file or directory
> 
> This is caused by significant changes in catch2 3.4.0.
> Some other packages are affected by the same problem, which currently blocks
> migration: https://qa.debian.org/excuses.php?package=catch2
> 
> I think this bug should be:
> 
> reassign -1 catch2
> affects -1 slic3r-prusa
> 
> Are there any objections if I do this?

If that's an intentional upstream change, reassigning to catch2 won't
help as it's not a bug in that package.

Christoph

Bug#1054505: su/sudo broken on i386

[Christoph Berg]

Control: retitle -1 su/sudo broken

Re: To Debian Bug Tracking System
> Package: libpam-modules-bin
> Version: 1.5.2-8
> Severity: grave
> 
> amd64 is unaffected.

Correction: amd64 is affected as well (-8 just had not hit the mirrors
yet when I first tried).

Christoph

Bug#1054505: su/sudo broken on i386

[Christoph Berg]

Package: libpam-modules-bin
Version: 1.5.2-8
Severity: grave

With pam 1.5.2-8 installed, my i386 chroots can't run su or sudo
anymore:

(sid-i386)root@turing:/home/myon# su -
su: Permission denied

(sid-i386)root@turing:/home/myon# sudo -i
sudo: PAM account management error: Permission denied
sudo: a password is required

amd64 is unaffected.

(sid-i386)root@turing:/home/myon# strace su -
execve("/usr/bin/su", ["su", "-"], 0xffc17124 /* 17 vars */) = 0
brk(NULL)   = 0x57956000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf7eef000
...
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = -1 ENOENT (No such 
file or directory)
close(4)= 0
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = -1 ENOENT (No such 
file or directory)
close(4)= 0
read(3, "", 4096)   = 0
close(3)= 0
getuid32()  = 0
socket(AF_NETLINK, SOCK_RAW, NETLINK_AUDIT) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
readlink("/proc/self/exe", "/usr/bin/su", 4096) = 11
sendto(3, [{nlmsg_len=140, nlmsg_type=0x44c /* NLMSG_??? */, 
nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=1, nlmsg_pid=0}, 
"\x6f\x70\x3d\x50\x41\x4d\x3a\x61\x75\x74\x68\x65\x6e\x74\x69\x63\x61\x74\x69\x6f\x6e\x20\x67\x72\x61\x6e\x74\x6f\x72\x73\x3d\x70"...],
 140, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 140
poll([{fd=3, events=POLLIN}], 1, 500)   = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, [{nlmsg_len=36, nlmsg_type=NLMSG_ERROR, nlmsg_flags=NLM_F_CAPPED, 
nlmsg_seq=1, nlmsg_pid=627976}, {error=0, msg={nlmsg_len=140, 
nlmsg_type=AUDIT_FIRST_USER_MSG, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, 
nlmsg_seq=1, nlmsg_pid=0}}], 8988, MSG_PEEK|MSG_DONTWAIT, 
{sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, [12]) = 36
recvfrom(3, [{nlmsg_len=36, nlmsg_type=NLMSG_ERROR, nlmsg_flags=NLM_F_CAPPED, 
nlmsg_seq=1, nlmsg_pid=627976}, {error=0, msg={nlmsg_len=140, 
nlmsg_type=AUDIT_FIRST_USER_MSG, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, 
nlmsg_seq=1, nlmsg_pid=0}}], 8988, MSG_DONTWAIT, {sa_family=AF_NETLINK, 
nl_pid=0, nl_groups=}, [12]) = 36
close(3)= 0
socket(AF_NETLINK, SOCK_RAW, NETLINK_AUDIT) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
sendto(3, [{nlmsg_len=124, nlmsg_type=0x44d /* NLMSG_??? */, 
nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, nlmsg_pid=0}, 
"\x6f\x70\x3d\x50\x41\x4d\x3a\x61\x63\x63\x6f\x75\x6e\x74\x69\x6e\x67\x20\x67\x72\x61\x6e\x74\x6f\x72\x73\x3d\x3f\x20\x61\x63\x63"...],
 124, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 124
poll([{fd=3, events=POLLIN}], 1, 500)   = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, [{nlmsg_len=36, nlmsg_type=NLMSG_ERROR, nlmsg_flags=NLM_F_CAPPED, 
nlmsg_seq=2, nlmsg_pid=627976}, {error=0, msg={nlmsg_len=124, nlmsg_type=0x44d 
/* AUDIT_??? */, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, 
nlmsg_pid=0}}], 8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, 
nl_groups=}, [12]) = 36
recvfrom(3, [{nlmsg_len=36, nlmsg_type=NLMSG_ERROR, nlmsg_flags=NLM_F_CAPPED, 
nlmsg_seq=2, nlmsg_pid=627976}, {error=0, msg={nlmsg_len=124, nlmsg_type=0x44d 
/* AUDIT_??? */, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, 
nlmsg_pid=0}}], 8988, MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, 
nl_groups=}, [12]) = 36
close(3)= 0
getpid()= 627976
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = -1 ENOENT (No such 
file or directory)
close(3)= 0
getpid()= 627976
openat(AT_FDCWD, "/var/log/btmp", O_WRONLY|O_LARGEFILE) = 3
alarm(0)= 0
rt_sigaction(SIGALRM, {sa_handler=0xf7e13d90, sa_mask=[], sa_flags=0}, 
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
alarm(10)   = 0
fcntl64(3, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
alarm(0)= 10
rt_sigaction(SIGALRM, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, NULL, 8) = 0
_llseek(3, 0, [384], SEEK_END)  = 0
write(3, "\6\0\0\0\10\225\t\0pts/3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
384) = 384
fcntl64(3, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
close(3)= 0
munmap(0xf7c6a000, 16392)   = 0
munmap(0xf7c37000, 208144)  = 0
munmap(0xf7b97000, 651928)  = 0
munmap(0xf7b92000, 16416)   = 0
munmap(0xf7b8c000, 20488)   = 0
munmap(0xf7b87000, 16392)   = 0
munmap(0xf7b7f000, 28680)   = 0
openat(AT_FDCWD, "/etc/login.defs", O_RDONLY|O_LARGEFILE) = 3
statx(3, ""

Bug#1050327: gcc-arm-none-eabi update breaks other arm-none-eabi packages

[Christoph Berg]

Re: Matthias Klose
> Package: src:gcc-arm-none-eabi
> Version: 15:12.3.rel1-1
> Severity: serious
> Tags: sid trixie
> 
> a typical upload-and-run-away package upload ...

I think to fix, a simple rebuild of libstdc++-arm-none-eabi is
required (not binnmu-able since it's arch:all).

The original reason I was looking into this is hackrf (#1052857), but
that got updated yesterday not to build the arm firmware image
anymore. Furthermore, when trying to build the hackrf package that
still needs the arm toolchain, I'm now getting this:

-- Check for working C compiler: /usr/bin/arm-none-eabi-gcc - broken
CMake Error at /usr/share/cmake-3.27/Modules/CMakeTestCCompiler.cmake:67 
(message):
  The C compiler

"/usr/bin/arm-none-eabi-gcc"

  is not able to compile a simple test program.

  It fails with the following output:

Change Dir: 
'/home/myon/debian/nmu/gcc-arm-none-eabi/hackrf/firmware/build_hackrf/CMakeFiles/CMakeScratch/TryCompile-eCZznn'

Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/gmake -f 
Makefile cmTC_64ef2/fast
gmake[2]: Entering directory 
'/home/myon/debian/nmu/gcc-arm-none-eabi/hackrf/firmware/build_hackrf/CMakeFiles/CMakeScratch/TryCompile-eCZznn'
/usr/bin/gmake  -f CMakeFiles/cmTC_64ef2.dir/build.make 
CMakeFiles/cmTC_64ef2.dir/build
gmake[3]: Entering directory 
'/home/myon/debian/nmu/gcc-arm-none-eabi/hackrf/firmware/build_hackrf/CMakeFiles/CMakeScratch/TryCompile-eCZznn'
Building C object CMakeFiles/cmTC_64ef2.dir/testCCompiler.c.obj
/usr/bin/arm-none-eabi-gcc   -g -O2 
-ffile-prefix-map=/home/myon/debian/nmu/gcc-arm-none-eabi/hackrf=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection  -o 
CMakeFiles/cmTC_64ef2.dir/testCCompiler.c.obj -c 
/home/myon/debian/nmu/gcc-arm-none-eabi/hackrf/firmware/build_hackrf/CMakeFiles/CMakeScratch/TryCompile-eCZznn/testCCompiler.c
cc1: error: '-fcf-protection=full' is not supported for this target

So, I'm not going to fix this bug, but perhaps these notes help
others.

Christoph

Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium

[Christoph Berg]

Re: Sean Whitton
> Package: tech-ctte
> 
> I call for votes on the following resolution.
> Voting lasts for one week or until the outcome is no longer in doubt.
> 
> === BEGIN
> 
> OPTION A:
> 
> The Technical Committee formally repeals its moratorium recommending
> that maintainers of individual packages should not proactively move
> files from the root filesystem to corresponding locations under /usr in
> the data.tar.* of packages (see #1035831).
> 
> Under Constitution 6.1.5, the Technical Committee now recommends that
> maintainers consult with those driving the merged-/usr transition before
> moving files from the root filesystem to corresponding locations under
> /usr in the data.tar.* of packages.
> 
> The transition driver, which at the time of writing is Helmut Grohne, is
> using a phased approach, in which the moratorium is rolled back for only
> certain classes of packages, and changes, at a time.  In addition,
> restructuring uploads should be targeted at experimental, and left for
> three days.  This is in order that automated testing by dumat can occur.
> 
> We recommend following , as edited by
> the transition driver(s).  If there is any doubt as to whether a change
> you wish to make is appropriate, please seek explicit approval from the
> transition driver(s).
> 
> OPTION N:
> 
> None of the above.
> 
> === END

I vote A > N.

Christoph


signature.asc
Description: PGP signature

Bug#1023047: wsjtx: No transmit audio

[Christoph Berg]

Re: erebion
> According to Pavucontrol there is no audio, as wsjtx does not show up. That
> is while transmitting, haven't tried to receive last time as I did not have
> the required cable with me.
> 
> I think input was broken as well, but to be sure I'd need to have another
> look.

You don't need the radio connected, you can also let wsjtx record
audio from the local mic and check if the ambient noise shows up on
the waterfall. (Same for TX and local speaker of course.)

If wsjtx doesn't show up, I don't really know where to look further.
(Frustratingly, I have the same issue atm with wfview. I currently
blame pipewire, but I think it did work before.)

Christoph

Bug#1023047: wsjtx: No transmit audio

[Christoph Berg]

Re: erebion
> Is there anything specific I could check?

Can you fire up pavucontrol to check if there's 1) any audio 2) on the
correct sound card while transmitting?

Is the TX gain slider at something between -20dB and 0dB and not at
the very bottom?

Christoph DF7CB

Bug#1053346: bullseye-pu: package postgresql-common/225+deb11u1

[Christoph Berg]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: postgresql-com...@packages.debian.org
Control: affects -1 + src:postgresql-common

Hi,

I've uploaded a new postgresql-common package to bullseye that fixes
the autopktest tests on salsa-ci and ci.debian.net. (Test-only
changes.)

* Fix t/085 to correctly prepare the test environment
* Tell ./testsuite to continue testing even when one test fails
* Change debian/gitlab-ci.yml to use the standard pipeline

The result is mostly green:

https://salsa.debian.org/postgresql/postgresql-common/-/pipelines/585893

(The lintian error is an dependency on lsb-base that I don't want to
touch in oldstable.)

Please unblock postgresql-common/225+deb11u1

Thanks,
Christoph

Control files: lines which differ (wdiff format)

Vcs-Git: https://salsa.debian.org/postgresql/postgresql-common.git {+-b bullseye+}

diff -Nru postgresql-common-225/debian/changelog postgresql-common-225+deb11u1/debian/changelog
--- postgresql-common-225/debian/changelog	2021-02-02 15:40:25.0 +0100
+++ postgresql-common-225+deb11u1/debian/changelog	2023-10-02 10:20:47.0 +0200
@@ -1,3 +1,11 @@
+postgresql-common (225+deb11u1) bullseye; urgency=medium
+
+  * t/085_pg_ctl.conf.t: sudo and salsa-ci set the core file size hard limit
+to 0 by default, undo that. (Salsa: postgresql/postgresql#2)
+  * testsuite: Run all tests even when one is failing.
+
+ -- Christoph Berg   Mon, 02 Oct 2023 10:20:47 +0200
+
 postgresql-common (225) unstable; urgency=medium
 
   * pg_lsclusters, cluster_info: Show cluster managed by pacemaker or patroni.
diff -Nru postgresql-common-225/debian/control postgresql-common-225+deb11u1/debian/control
--- postgresql-common-225/debian/control	2020-10-22 14:15:09.0 +0200
+++ postgresql-common-225+deb11u1/debian/control	2023-10-02 10:20:47.0 +0200
@@ -8,7 +8,7 @@
  Peter Eisentraut ,
 Standards-Version: 4.4.0
 Rules-Requires-Root: no
-Vcs-Git: https://salsa.debian.org/postgresql/postgresql-common.git
+Vcs-Git: https://salsa.debian.org/postgresql/postgresql-common.git -b bullseye
 Vcs-Browser: https://salsa.debian.org/postgresql/postgresql-common
 Build-Depends:
  debhelper (>= 9),
diff -Nru postgresql-common-225/debian/gitlab-ci.yml postgresql-common-225+deb11u1/debian/gitlab-ci.yml
--- postgresql-common-225/debian/gitlab-ci.yml	2020-09-30 09:27:36.0 +0200
+++ postgresql-common-225+deb11u1/debian/gitlab-ci.yml	2023-10-02 10:20:47.0 +0200
@@ -1,44 +1,5 @@
-.debian_script: &debian_script
-  - $SUDO apt-get update
-  - $SUDO apt-get -o DPkg::Options::=--force-confnew dist-upgrade -y
-  - $SUDO apt-get install -y build-essential fakeroot debhelper libreadline-dev dh-systemd
-  - rm -f ../*.deb ../*.dsc ../*.buildinfo ../*.changes ../*.tar.*
-  - dpkg-buildpackage -uc -us -rfakeroot
-  - ( set -x; for deb in ../*.deb; do dpkg-deb --info $deb; dpkg-deb --contents $deb; done )
-  - ( set -x; $SUDO dpkg --force-confmiss --force-confnew -i ../*.deb || { $SUDO apt-get install -fy; $SUDO dpkg --force-confmiss --force-confnew -i ../*.deb; } )
-  - dpkg -l postgresql\* | cat
-  - $SUDO ./cleanpg
-  - cd /usr/share/postgresql-common && $SUDO ./testsuite -v "$(./supported-versions)" -i
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
 
-sid:
-  image: debian:unstable
-  script: *debian_script
-  variables:
-SKIP_IPV6: 1
-
-buster:
-  tags:
-- buster
-  script: *debian_script
-  variables:
-SUDO: sudo
-
-stretch:
-  tags:
-- stretch
-  script: *debian_script
-  variables:
-SUDO: sudo
-
-centos7:
-  tags:
-- centos7
-  script:
-- sudo yum install -y rpm-build centos-release-scl epel-release # for llvm
-- make rpmremove
-- make rpmbuild
-- rpm -ql pgdg-redhat-repo > /dev/null || sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
-- sudo yum -y update
-- make rpminstall
-- sudo ./cleanpg
-- cd /usr/share/postgresql-common && sudo ./testsuite -v "$(./supported-versions)" -i
+variables:
+  RELEASE: 'bullseye'
diff -Nru postgresql-common-225/t/085_pg_ctl.conf.t postgresql-common-225+deb11u1/t/085_pg_ctl.conf.t
--- postgresql-common-225/t/085_pg_ctl.conf.t	2019-11-15 19:58:53.0 +0100
+++ postgresql-common-225+deb11u1/t/085_pg_ctl.conf.t	2023-10-02 10:20:47.0 +0200
@@ -6,7 +6,7 @@
 use TestLib;
 use PgCommon;
 
-use Test::More tests => $MAJORS[-1] >= '8.3' ? 29 : 1;
+use Test::More tests => $MAJORS[-1] >= '8.3' ? 33 : 1;
 
 # Do test with newest version
 my $v = $MAJORS[-1];
@@ -15,38 +15,37 @@
 exit 0;
 }
 
-is ((system "pg_createcluster $v main >/dev/null"), 0, "pg_createcluster $v main");
+# enable core dumps
+# su

Bug#1053268: RM: pgaudit-1.7 -- ROM; superseded by pgaudit-16

[Christoph Berg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pgaudit-...@packages.debian.org
Control: affects -1 + src:pgaudit-1.7

Please remove pgaudit-1.7 from unstable, it supports PG15 only.
(pgaudit-16 in unstable supports PG16.)

Thanks,
Christoph

Bug#1053174: Block Ben Tris

[Christoph Berg]

Package: bugs.debian.org

Hi,

we keep seeing non-actionable bug reports from Ben Tris that look like
this:

> Subject: Re: Bug#1052524: postgresql-16: Ow that hurts! On the short 
> description.
>
> Package: postgresql-16
> Severity: minor
> X-Debbugs-Cc: benatt...@gezapig.nl
> 
> Dear Maintainer,
> 
> Is it really not The World's Most Advanced Relational Database?
> Please, do not tell me it is true, it hurts me so badly.
> 
> Please change the short description to a friendlier one. (while you're doing,
> please also remove free and open-source (sounds pretty dumb while you're in
> main) from the long description?  Else I have to make a separate bug report 
> for
> that)

People (including me) have been trying to tell him to stop this,
without any reaction.

Please block Ben Tris from filing any new bugs, it's just a waste of
time for maintainers.

Christoph

Bug#1052445: Transition: libpqxx 6.4->7.8

[Christoph Berg]

Re: Maarten van Geijn
> Hi Christoph,
> 
> Thanks for pointing this out.
> Yes, this is intended as pre-approval request for the transition into sid. I
> got this https://wiki.debian.org/Teams/ReleaseTeam/Transitions site, from
> which I understood that a bug-report on this was necessary for the sid
> upload, but perhaps I misunderstood.

Yes, a bug report on the "release.debian.org" pseudo package.

(You can reassign this bug, or open a new one.)

Christoph

Bug#1052445: Transition: libpqxx 6.4->7.8

[Christoph Berg]

Re: Maarten van Geijn
> Dear Release Team,

Hi Maarten,

you filed this on the libpqxx package, the release team won't see it
there.

Is this the pre-approval request for the transition?

> Package libpqxx has a new update from upstream in experimental.
> 
> Checked sqlsmith and osm2pgrouting source packages, which seem to be 
> unaffected.
> 
> Ben information:
> Affected: .depends ~ /\b(libpqxx\-7\.8|libpqxx\-6\.4)\b/
> Good: .depends ~ /\b(libpqxx\-7\.8)\b/
> Bad: .depends ~ /\b(libpqxx\-6\.4)\b/

The automatic tracker got that right already:

https://release.debian.org/transitions/html/auto-libpqxx.html

> Request scheduled binNMU for libpqxx into sid.

You need to actually upload libpqxx to sid, it won't transition like
sid->testing works.

BinNMUs can then take care of the two rdeps.

Christoph

Bug#1052324: nmu: glom_1.30.4-7+b3

[Christoph Berg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:glom

Please binnmu glom:

nmu glom_1.30.4-7+b3 . ANY . unstable . -m "Rebuild against postgresql-16."

Thanks,
Christoph

Bug#1052177: Provides a PostgreSQL extension without depending on the correct server version

[Christoph Berg]

Source: pg-gvm
Version: 22.4.0-2
Severity: serious
Tags: patch

Hi,

pg-gvm currently ships a single binary package "pg-gvm" that installs
files to /usr/lib/postgresql/15/, but doesn't declare that anywhere;
the packaging doesn't conform to the established PostgreSQL extension
packaging scheme.

PostgreSQL 16 is just entering unstable, the package needs to be
updated.

A branch to fix that is at 
https://salsa.debian.org/pkg-security-team/pg-gvm/-/merge_requests/1

I plan to NMU this in 10 days to get the PostgreSQL 16 transition
forward if I don't hear back otherwise.

Thanks,
Christoph

Bug#1051385: postgresql-15: Please disable LLVM support on loong64 for now

[Christoph Berg]

Re: John Paul Adrian Glaubitz
> I forgot to mention: We need to check with DSA first whether the dpkg version
> on the DAK server already supports loong64. Otherwise, it could happen that 
> the
> package gets rejected when you add loong64 to debian/control.

Good point! I see several packages in sid that have loong64 in the
sources file, including gcc-11. So that should be fine.

Christoph

Bug#1051385: postgresql-15: Please disable LLVM support on loong64 for now

[Christoph Berg]

Re: John Paul Adrian Glaubitz
> While LLVM has already been ported to LoongArch (loong64), PostgreSQL does 
> not support
> LLVM on this architecture yet. Since this currently results in an FTBFS [1], 
> I would
> like to ask to disable LLVM on loong64 for the time being.

Hi,

PG does not support LLVM 16 yet, which seems to be pulled in by
llvm-dev on loong64, while in unstable it's still LLVM 14 (15 should
work as well). But these LLVM versions don't support loong64 yet.

I'll do a new postgresql-15 upload.

Christoph

Bug#1050768: xastir: Drop unused libproj-dev build dependency

[Christoph Berg]

Control: tags -1 moreinfo

Re: Bas Couwenberg
> Your package build depends on libproj-dev but doesn't link to libproj nor 
> include proj.h.

Xastir uses libgeotiff-dev, which depends on libproj-dev, so dropping
the B-D wouldn't make it not use it.

Since configure.ac contains an explicit check for libproj before it
tries to check for libgeotiff, I think keeping the B-D does have some
value.

Christoph

Bug#1050375: Invalid command name "pg_connect"

[Christoph Berg]

Package: pfm
Version: 2.0.8-3
Severity: grave

pfm doesn't do anything useful here, it just produces a message popup
saying

Connection to database foo has failed:

invalid command name "pg_connect"

I guess Tcl/Tk has changed since this package was last updated 10 years ago.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de:en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pfm depends on:
ii  itcl3  3.4.4-2
ii  libpgtcl   1:3.0.0-1
ii  postgresql-client  15+253.pgdg+1
ii  postgresql-client-10 [postgresql-  10.23-2.pgdg+1
client]
ii  postgresql-client-11 [postgresql-  11.21-1.pgdg+1
client]
ii  postgresql-client-12 [postgresql-  12.16-1.pgdg+1
client]
ii  postgresql-client-13 [postgresql-  13.12-1.pgdg+1
client]
ii  postgresql-client-14 [postgresql-  14.9-1.pgdg+1
client]
ii  postgresql-client-15 [postgresql-  15.4-1.pgdg+1
client]
ii  postgresql-client-16 [postgresql-  16~beta2-2.pgdg+~20230807.1056.ge8386b2
client]
ii  postgresql-client-17 [postgresql-  17~~devel-1.pgdg+~20230820.0934.g1951d21
client]
ii  postgresql-client-8.2 [postgresql  8.2.23-11.pgdg+1
-client]
ii  postgresql-client-8.4 [postgresql  8.4.22-9.pgdg+1
-client]
ii  postgresql-client-9.3 [postgresql  9.3.25-9.pgdg+1
-client]
ii  postgresql-client-9.4 [postgresql  9.4.26-8.pgdg+1
-client]
ii  postgresql-client-9.5 [postgresql  9.5.25-6.pgdg+1
-client]
ii  postgresql-client-9.6 [postgresql  9.6.24-5.pgdg+1
-client]
ii  sensible-utils 0.0.20
ii  tcl8.6.13
ii  tk 8.6.13

pfm recommends no packages.

Versions of packages pfm suggests:
ii  postgresql  15+253.pgdg+1

-- no debconf information

Christoph

Bug#982430: grig: Communication of /dev/ttyS* timed out

[Christoph Berg]

Re: Michael Vorleiter
> Package: grig
> Version: 0.8.1-2
> Severity: important
> 
> Dear Maintainer,
> 
> I am describing in seven points the situation; from the error message to the 
> hardware.
> 
> 1. Error message: 
> 2020/04/22 08:45:06;;GRIG;;2;;rig_daemon_start: Öffnen des Anlagen-Ports 
> fehlgeschlagen /dev/ttyS1: Communication timed out (Berechtigungen?)

Hi Michael,

this is a message from hamlib, so likely not a problem in grig.
If you still experience the problem, try using rigctl instead.

I'm closing the bug now, if there is a problem with grig, we can
reopen.

73,
Christoph DF7CB

Bug#1050001: Unwinding the directory aliasing mistake

[Christoph Berg]

Re: Ian Jackson
> Protecting my mental health
> 
> I will try to avoid regularly reading this thread.  I hope that now
> that I have made the suggestion, others will be able to carry the
> conversation.  I will be configuring my mail client to disregard my
> personal copies of messages sent to this bug; when I want to read
> the thread I will look at the mailing list.
> 
> Also, if you disagree with my decision to raise this now, please don't
> email me.  If you feel I have overstepped a boundary, please contact
> the Community Team or DAM.

I think this is just gross. Submitting a proposal and then telling
CT/DAM to deal with the fallout is rude.

Christoph

Bug#1042025: thrift: FTBFS: dh_auto_test: error: make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

[Christoph Berg]

Re: Lucas Nussbaum
> Version: 0.17.0-2

> > (./testapplicationexception:892843): GLib-CRITICAL **: 07:16:59.134: Did 
> > not see expected message GLib-GObject-WARNING **: value*out of range*type*
> > not ok /testapplicationexception/Properties/test - 
> > GLib-GObject-FATAL-CRITICAL: value "-1" of type 'gint' is invalid or out of 
> > range for property 'type' of type 'gint'
> > Bail out!
> > /bin/bash: line 6: 892843 Trace/breakpoint trap   ${dir}$tst
> > FAIL: testapplicationexception
> > TAP version 13
> > # random seed: R02Sdadbad636988fc61fb41629b59ecfdd6

Fwiw, there is a new 0.18.1 upstream version. Perhaps that works
better.

Christoph

Bug#1043250: tzdata: bring back top-level UTC

[Christoph Berg]

Control: severity -1 serious

Re: Thorsten Glaser
> >Why isn't Etc/UTC an alternative to UTC?
> 
> It’s not as portable, it binds to the Olson database whereas
> an otherwise unqualified UTC is pretty standard. Worse, if
> Etc/UTC is not available, the fallback makes it assume Etc,
> not UTC, as timezone name.

We can't know how many people out there have "TZ=UTC" in their shell
scripts, and we shouldn't break that. Perhaps Etc/UTC is more correct,
but I don't see why insisting on correctness needs to annoy users,
when the cost is just maintaining one symlink that we have shipped for
decades.

For a concrete data point: This change is now causing PostgreSQL to
FTBFS since UTC is used in the regression tests:

 SET TimeZone to 'UTC';
+ERROR:  invalid value for parameter "TimeZone": "UTC"

I'm hence raising to serious.

Christoph

Bug#1042825: postgresql-common: pg_upgrade dumps diagnostics into new cluster and then drops it

[Christoph Berg]

Control: forwarded -1 
https://salsa.debian.org/postgresql/postgresql-common/-/issues/29

Hi Markus,

thanks for the report.

Re: Markus Demleitner
> The trouble with that is: loadable_libraries.txt is itself below
> /var/lib/postgresql/15 and is hence dropped with the (broken) new cluster,
> and hence the file is gone by the time mere humans read the message.
> 
> Is there a special reason why loadable_libraries.txt is not dumpted into
> the ordinary log directory?

Only because pg_upgradecluster hasn't yet learned that the output
files are now in a different location - they used to be written to the
current directory.

This had already been filed as
https://salsa.debian.org/postgresql/postgresql-common/-/issues/29, but
wasn't addressed yet.

Another relevant bug is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703850

I'll get to these one day...

Christoph

Bug#1042157: [3dprinter-general] Bug#1042157: uranium: FTBFS: dh_install: error: missing files, aborting

[Christoph Berg]

Re: Timo Röhling
> https://lists.debian.org/debian-devel/2023/07/msg00307.html

Thanks for the explanation, I'm preparing an upload.

Cheers,
Christoph

Bug#1042157: [3dprinter-general] Bug#1042157: uranium: FTBFS: dh_install: error: missing files, aborting

[Christoph Berg]

Hi Timo,

did cmake intentionally change Python_SITELIB to point to /usr/local?

Re: Gregor Riepl
> > purelib: directory for site-specific, non-platform-specific files
> > (https://docs.python.org/3/library/sysconfig.html)
> > 
> > "site-specific" doesn't sound like packages should install anything
> > there.
> 
> "site-specific" may be meant from the perspective of the Python interpreter,
> not the whole system, so it does sound correct to me - especially if you
> consider that Python modules are separated into the standard library and
> dist-packages.
> 
> > Perhaps the bug is that Python_SITELIB is used and it should be
> > something else?
> 
> I've tried Python_STDLIB (=sysconfig.get_path('stdlib')), but that's
> definitely wrong: It points to /usr/lib/python3.11
> 
> Python packages are normally installed into /usr/lib/python3/dist-packages/
> (or /usr/lib/python3.11/dist-packages/ if they're interpreter-specific).
> Uranium used to be installed into /usr/lib/python3/dist-packages/, because
> it's a pure Python library and doesn't depend on the interpreter version.
> 
> Python_STDARCH and Python_SITEARCH have the same values as Python_STDLIB and
> Python_SITELIB, and I don't see any other useful FindPython[1] variables.
> IMHO, Python_SITELIB is still the best choice, unless there's some other way
> to install Python modules in cmake that doesn't involve these variables.
> 
> I'm going to ask the debian-python list for help, perhaps they know more
> about the correct paths to use.
> In the meantime, I do think this issue should block cmake 3.27 migration
> until we've sorted it out, so the bug should be reassigned to cmake.
> 
> 
> [1] https://cmake.org/cmake/help/latest/module/FindPython.html
> 

Christoph

Bug#1042157: [3dprinter-general] Bug#1042157: uranium: FTBFS: dh_install: error: missing files, aborting

[Christoph Berg]

Re: Gregor Riepl
> This is caused by a change in cmake 3.27.
> 
> In 3.26.4-4, Python_SITELIB is /usr/lib/python3/dist-packages.
> In 3.27.1-1, it's /usr/local/lib/python3.11/dist-packages
> 
> The documentation for 3.26 states:
> > Information returned by 
> > distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False) 
> > or else sysconfig.get_path('purelib').
> 
> And for 3.27:
> > Information returned by sysconfig.get_path('purelib').
> 
> I'm not sure if Debian overrides this in any way, but it's certainly a 
> regression.

purelib: directory for site-specific, non-platform-specific files
(https://docs.python.org/3/library/sysconfig.html)

"site-specific" doesn't sound like packages should install anything
there.

Perhaps the bug is that Python_SITELIB is used and it should be
something else?

Christoph

Bug#1042157: [3dprinter-general] Bug#1042157: uranium: FTBFS: dh_install: error: missing files, aborting

[Christoph Berg]

Re: Gregor Riepl
> 
> > > -- Installing: 
> > > /<>/debian/tmp/usr/local/lib/python3.11/dist-packages/UM
> > > -- Installing: 
> > > /<>/debian/tmp/usr/local/lib/python3.11/dist-packages/UM/ColorImage.py
> 
> > > dh_install: warning: Cannot find (any matches for) 
> > > "usr/lib/python3/dist-packages/UM" (tried in ., debian/tmp)
> > > 
> > > dh_install: warning: python3-uranium missing files: 
> > > usr/lib/python3/dist-packages/UM
> > > dh_install: error: missing files, aborting
> > > make: *** [debian/rules:7: binary] Error 25
> 
> Those are very strange results.
> No files should end up in /usr/local!
> 
> And I haven't been able to reproduce this locally yet.
> Investigation ongoing...

I can reproduce it here, but haven't investigated yet.

Christoph

Bug#1041870: [3dprinter-general] Bug#1041870: slic3r-prusa FTBFS on i386

[Christoph Berg]

Re: Adrian Bunk
> 2. the following change:
> 
> --- debian/rules.old  2023-07-24 15:36:20.941771419 +
> +++ debian/rules  2023-07-24 15:36:43.133759741 +
> @@ -5,7 +5,7 @@
>  # less debug info to avoid running out of address space
>  ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
>   export DEB_CXXFLAGS_MAINT_APPEND += --param ggc-min-expand=5 -g0
> -else ifneq (,$(filter $(DEB_HOST_ARCH), armhf))

The old command was wrong anyway, the pattern list comes first:

ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))

Doesn't matter when it's a single item without % wildcards, but will
explode when adding more architectures.

Christoph

Bug#1037614: [3dprinter-general] Bug#1037614: cura-engine: ftbfs with GCC-13

[Christoph Berg]

Re: Gregor Riepl
> > The package fails to build in a test rebuild on at least amd64 with
> > gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
> > severity of this report will be raised before the trixie release.
> 
> This issue was due to a missing #include , and it was already fixed
> upstream in an unrelated commit.

Hi Gregor,

thanks for collecting all the patches and putting them together.

There's still an issue on i386 left, and at least from looking at the
CI tests, it might have been caused by this fix:

https://salsa.debian.org/3dprinting-team/cura-engine/-/pipelines

Any ideas?

I have only an old and super slow notebook here on vacation, so can't
really do any C++ debugging now.

Christoph

Bug#1040191: [3dprinter-general] Bug#1040191: marked as pending in libnest2d

[Christoph Berg]

Re: Adrian Bunk
> They seem to have renamed the python modules, e.g. in python3-arcus:

Sigh, and thanks for spotting that.

I had hoped that uploading to experimental would have found such
issues over the last year, but was not true. :(

Christoph

Bug#1040191: marked as pending in libnest2d

[Christoph Berg]

Re: Gregor Riepl
> 
> Thanks for the quick fix, but I'm not super happy about this solution.
> 
> This package *really* installs only platform-independent header files, and I
> think the error is wrong.
> 
> But I can see where it's coming from; one of the cmake scripts contains
> boilerplate that depends on the installation architecture:

Right, I wasn't really happy about making it Arch:any either, but I
didn't want to disentangle the cmake files, not knowing if other
packages hook into that check somehow.

The cost of the change isn't high (small .deb files on the mirrors),
and it's still easy to revert if we find a better fix.

The whole set of cura packages still has much bigger problems, there's
a few failing autopkgtests... :(

Christoph

Bug#1040228: Resignation & call for votes to elect the Chair

[Christoph Berg]

> ===BEGIN
> 
> A: Christoph Berg 
> B: Matthew Garrett 
> C: Helmut Grohne 
> D: Simon McVittie 
> E: Stefano Rivera 
> F: Timo Röhling 
> G: Matthew Vernon 
> H: Sean Whitton 
> 
> ===END

I vote H > A = B = C = D = G > E = F

Christoph


signature.asc
Description: PGP signature

Bug#1033316: Autopkgtest is flaky

[Christoph Berg]

Control: severity -1 serios

Re: To Debian Bug Tracking System
> ruby-moneta is currently showing up on
> https://qa.debian.org/excuses.php?package=postgresql-common as a
> regression in postgresql-common, but that's not true, the code hasn't
> changed.
> 
> https://ci.debian.net/packages/r/ruby-moneta/testing/amd64/
> 
> This has already happened last week. Clicking the retry buttons
> resolved the issue back then, on some architectures by making the test
> pass, and on other architectures by making even the "reference" test
> fail.
> 
> Please fix the tests to be stable.

Hi,

this has been hitting again and again intermittently during the
bookworm release. Please fix the package so it doesn't get in the way
of other package's testing migration.

Thanks,
Christoph