Bug#1072106: azure-cli: az ad sp create-for-rbac results in python error
Package: azure-cli Version: 2.45.0-1 Severity: normal Running this results in a traceback for me on Debian 12: $ az ad sp create-for-rbac --name foo --role Contributor --scopes /subscriptions/ Creating 'Contributor' role assignment under scope '/subscriptions/' Role assignment creation failed. The command failed with an unexpected error. Here is the traceback: 'RoleAssignmentsOperations' object has no attribute 'config' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/knack/cli.py", line 233, in invoke cmd_result = self.invocation.execute(args) ^ File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 663, in execute raise ex File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 726, in _run_jobs_serially results.append(self._run_job(expanded_arg, cmd_copy)) ^ File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 718, in _run_job return cmd_copy.exception_handler(ex) ^^ File "/usr/lib/python3/dist-packages/azure/cli/command_modules/role/commands.py", line 51, in graph_err_handler raise ex File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 697, in _run_job result = cmd_copy(params) File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", line 333, in __call__ return self.handler(*args, **kwargs) ^ File "/usr/lib/python3/dist-packages/azure/cli/core/commands/command_operation.py", line 121, in handler return op(**command_args) ^^ File "/usr/lib/python3/dist-packages/azure/cli/command_modules/role/custom.py", line 1246, in create_service_principal_for_rbac _create_role_assignment(cmd.cli_ctx, role, sp_oid, None, scope, resolve_assignee=False, File "/usr/lib/python3/dist-packages/azure/cli/command_modules/role/custom.py", line 198, in _create_role_assignment assignments_client.config.subscription_id) ^ AttributeError: 'RoleAssignmentsOperations' object has no attribute 'config' Versions of azure packages I have installed: ii azure-cli 2.45.0-1 ii python3-azure 20230112+git-1 ii python3-azure-cli 2.45.0-1 ii python3-azure-cli-core 2.45.0-1 ii python3-azure-cli-telemetry 2.45.0-1 ii python3-azure-cosmos 3.1.1-5 ii python3-azure-datalake-store 0.0.52-2 ii python3-azure-multiapi-storage 1.0.0-1 ii python3-azure-storage 20230112+git-1 ii python3-msrestazure 0.6.4-2 Michael
Bug#1071260: prometheus-postgres-exporter: pg_replication_slots metrics query fails on standbys with replication slots
Package: prometheus-postgres-exporter
Version: 0.11.1-3+b5
Severity: normal
Tags: patch
Hi,
if prometheus-postgres-exporter runs on a standby, and that standby has
physical replication slots, then the pg_replication_slots metrics queries
throws an error (see also upstream issues #547 [0] and #962 [1]):
|Mai 17 12:20:21 pg2 prometheus-postgres-exporter[8458]:
|ts=2024-05-17T10:20:21.162Z caller=namespace.go:236 level=info err="Error
|running query on database \"/var/run/postgresql/:5432\": pg_replication_slots
|pq: recovery is in progress"
This can be manually reproduced like this:
|postgres=# SELECT pg_create_physical_replication_slot('test');
| pg_create_physical_replication_slot
|-
| (test,)
|(1 row)
|
|postgres=# SELECT pg_is_in_recovery();
| pg_is_in_recovery
|---
| t
|(1 row)
|
|postgres=# SELECT slot_name, database, active,
pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
|FROM pg_replication_slots;
|ERROR: recovery is in progress
|HINT: WAL control functions cannot be executed during recovery.
Usually those functions like pg_current_wal_lsn() are guarded by CASE
pg_is_in_recovery(), but not here (maybe because it is not very common
to have replication slots on standbys). The attached patch should fix
it.
Michael
[0] https://github.com/prometheus-community/postgres_exporter/issues/547
[1] https://github.com/prometheus-community/postgres_exporter/issues/962
Index: prometheus-postgres-exporter-0.11.1/cmd/postgres_exporter/queries.go
===
--- prometheus-postgres-exporter-0.11.1.orig/cmd/postgres_exporter/queries.go
+++ prometheus-postgres-exporter-0.11.1/cmd/postgres_exporter/queries.go
@@ -105,14 +105,14 @@ var queryOverrides = map[string][]Overri
{
semver.MustParseRange(">=9.4.0 <10.0.0"),
`
- SELECT slot_name, database, active,
pg_xlog_location_diff(pg_current_xlog_location(), restart_lsn)
+ SELECT slot_name, database, active, (case
pg_is_in_recovery() when 't' then null else
pg_xlog_location_diff(pg_current_xlog_location(), restart_lsn) end)
FROM pg_replication_slots
`,
},
{
semver.MustParseRange(">=10.0.0"),
`
- SELECT slot_name, database, active,
pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
+ SELECT slot_name, database, active, (case
pg_is_in_recovery() when 't' then null else
pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) end)
FROM pg_replication_slots
`,
},
Bug#1063752: [Debichem-devel] Bug#1063752: custodian: Inappriate maintainer address
Hi, On Tue, Feb 13, 2024 at 11:24:15AM +0100, Drew Parsons wrote: > Source: custodian > Followup-For: Bug #1063752 > X-Debbugs-Cc: Debichem Team > Control: reassign 1063752 lists.debian.org > Control: affects 1063752 src:custodian > > Scott Kitterman reported that lists.alioth.debian.org is bouncing > emails from debian official addresses (ftpmas...@ftp-master.debian.org > in this case, processing packages for the Debichem team with Maintainer > address debichem-de...@lists.alioth.debian.org) > > Scott filed the bug against src:custodian, but the bug must be in the > mailing list daemon, so I'm reassigning the bug to lists.debian.org I don't think the Debian listmasters are responsible for lists.alioth.debian.org - also, I don't think there is a pseudo package for it :-/ I got another complaint from ftp-master for a NEW processing mail some time ago, so maybe it is related to that. After checking the admin interface, it looks like lists.alioth.debian.org was updated last month and the configuration reset - suspected spam mails were auto-rejected again while they were sent to me previously. I reverted that now and maybe that fixes it already. Michael
Bug#1059476: please reopen - still happens with 15.6
Hi, On Sat, Feb 17, 2024 at 09:54:22AM +0100, Clemens Eisserer wrote: > | can you try to upgrade and check whether your > | problamatic case is fixed as well? If not, I will reopen this bug > | report. > | are usually very bad memory leaks > | due to the way PostgreSQL uses LLVM. > > I've just tested the query with 15.6 - and the crash still occurs, > despite the closed bug report ;) Ok, I have reopened it. > As can be seen in my email to the postgresql mailing list this is a > segfault crash, not some failed allocation or the linux oom killer > kicking in. > > Also the issue was analyzed by the postgresql devs and they came to > the conclusion it is a bug within llvm-14. > As mentioned, I've tested the same query on the same dataset with the > same version of postgresql (15.5) on the same hardware on ubuntu, with > the sole difference that ubuntu links to llvm-15 and there the query > succeeds and postgresql doesn't crash. If you want to stay on Debian, you can try the Postgres community repositories from apt.postgresql.org - the postgresql-15 packages for Debian 12 are linked against llvm16 it seems: https://wiki.postgresql.org/wiki/Apt https://apt.postgresql.org/pub/repos/apt/pool/main/p/postgresql-15/postgresql-15_15.6-1.pgdg120%2B2_arm64.deb > Just to be curious, what was the rational behind linking against the > oldest available llvm version available in the debian repos (I saw 14, > 15 and 16 are provided). I don't know, but Debian will not switch LLVM versions in a stable release I believe, sorry. Michael
Bug#1019503: postgresql-13: memory leak with JIT compilation
tags 1019503 +pending thanks Hi, On Sat, Sep 10, 2022 at 01:29:22PM -0400, Antoine Beaupre wrote: > We have found severe regressions when upgrading from bookworm to > bullseye on two of our PostgreSQL servers. Note that a work-around for this is (AFAIK) to set jit_inline_above_cost to 0, to avoid JIT inlining. In any case, a fix for this (supposedly) landed in master a few months back and got backpatched to all active branches some time ago, so it will be in the next round of Postgres stable releases, scheduled for mid-February. Michael
Bug#1025936: Possible fix
merge 1025936 1025937 tags 1025936 +patch tags 1025936 +pending thanks On Wed, Dec 06, 2023 at 04:06:26PM +, René Højbjerg Larsen wrote: > We use the TLS server as well, and are bothered by the same problem. > After installing pgbackrest package updates across out servers (we use > the PGDG repo), we experience lots of [ProtocolError] errors on log > archiving and backups due to the services still using the old > pgBackRest version (having not been restarted). > > In my limited testing, simply changing the dh_installsystemd > invocation in debian/rules from: > > dh_installsystemd --no-enable --no-start > > to > > dh_installsystemd --no-enable --no-start --restart-after-upgrade > > fixes the issue. I have reproduced the problem now and can confirm that the above fixes it, so committed it to the git repository. Thanks, Michael
Bug#1056303: pg_createcluster destroys data directory under certain conditions
severity 1056303 important
tags 1056303 +patch
thanks
Hi,
On Mon, Nov 20, 2023 at 09:49:34AM +0100, Max Kellermann wrote:
> When I tried to use "pg_createcluster" to configure my pre-existing
> PostgreSQL data directory with a new Debian install, it deleted the
> whole cluster with all databases instead. (This serious data loss
> justifies "severity critical" according to
> https://www.debian.org/Bugs/Developer#severities)
> Steps to reproduce:
>
> pg_createcluster 15 test
> cp /etc/postgresql/15/test/postgresql.conf /var/lib/postgresql/15/test/
You missed to copy the other configuration files, as cautioned in the
manpage:
| If the data directory already exists, it is integrated into the
| postgresql-common structure by moving the configuration file and
| setting the data_directory option. Please note that this only works
| for data directories which were created directly with initdb, i.e.
| all the configuration files (postgresql.conf etc.) must be present in
| the data directory.
> rm -r /etc/postgresql/15/test
> pg_createcluster 15 test
>
> This creates a new cluster just for the demo, then deletes the
> configuration directory, after copying the postgresql.conf to the data
> directory.
>
> I expect the second "pg_createcluster" call to find the existing data
> directory and configure it; and it tries to do so indeed:
>
> Configuring already existing cluster (configuration:
> /etc/postgresql/15/test, data: /var/lib/postgresql/15/test, owner:
> 103:111)
>
> After it finds and moves a "postgresql.conf", it however fails to find
> "pg_hba.conf"
Right, see above.
> Error: move_conffile: required configuration file
> /var/lib/postgresql/15/test/pg_hba.conf does not exist
> This fails the whole operation, and apparently, "pg_createcluster"
> tries to roll back by invoking "pg_dropcluster 15 test 2>/dev/null",
> destroying all pre-existing data.
>
> If "postgresql.conf" does not exist (or is empty), "pg_dropcluster" is
> not invoked.
This is because pg_creatcluster copies postgresql.conf first, and gets
version and cluster from it - if those are set, the data directory is
removed in the cleanup phase on error.
I think it would be sensible to only remove the data directory if it
actually got created by pg_createcluster, so I propose the attached
patch; I have also opened a merge request on Salsa for this:
https://salsa.debian.org/postgresql/postgresql-common/-/merge_requests/19
Michael
>From c1e61705ab9384a005a009ed6327bb40d9027afb Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Tue, 2 Jan 2024 15:54:04 +0100
Subject: [PATCH] pg_createcluster: Do not remove existing data directory on
failure. (Closes: #105630)
---
pg_createcluster | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pg_createcluster b/pg_createcluster
index 66f0b82..0c36561 100755
--- a/pg_createcluster
+++ b/pg_createcluster
@@ -361,6 +361,8 @@ if (-f "$datadir/PG_VERSION") {
($owneruid, $ownergid) = (stat "$datadir/PG_VERSION")[4,5];
if ($existingver == $version) {
print "Configuring already existing cluster (configuration: $confdir, data: $datadir, owner: $owneruid:$ownergid)\n";
+# Do not remove already existing data directory on errors
+$cleanup_cruft = 0;
} else {
error "$datadir contains a version $existingver cluster, but $version was requested";
}
--
2.39.2
Bug#1059277: [Debichem-devel] Bug#1059277: openbabel: CVE-2022-37331 CVE-2022-41793 CVE-2022-42885 CVE-2022-43467 CVE-2022-43607 CVE-2022-44451 CVE-2022-46280 CVE-2022-46289 CVE-2022-46290 CVE-2022-46
forwarded 1059277 https://github.com/openbabel/openbabel/issues/2650 thanks Hi, On Fri, Dec 22, 2023 at 01:06:17PM +0100, Moritz Mühlenhoff wrote: > Source: openbabel > X-Debbugs-CC: t...@security.debian.org > Severity: important > Tags: security > > Hi, > > The following vulnerabilities were published for openbabel. > > It's unclear if these were ever properly reported upstream/fixed, > could you please sync up with the upstream developers? Thanks, I checked, and it looks like Cisco disclosed it to the Openbabel maintainers with some lead time, and they will fix them for the next version. Michael
Bug#1057556: [Debichem-devel] Bug#1057556: elpa: FTBFS: not enough slots available
Hi, On Mon, Dec 11, 2023 at 02:50:40PM +0100, Santiago Vila wrote: > El 11/12/23 a las 14:08, Michael Banck escribió: > > So you are building elpa on a machine/vm with one cpu/vcore apparently? > > No. In this case the build was made on an AWS machine of type m6a.large, > which has 2 vcores. I'm usually including the machine type in the hostname, > so that it may be found in the very first line of the full build log: > > sbuild (Debian sbuild) 0.85.0 (04 January 2023) on m6a-large-1701732603 > > The specs for m6a.large machines are available here: > > https://aws.amazon.com/ec2/instance-types/m6a/ Hrm, ok. > > I guess it is useful information that elpa requires at least two cores > > to executes its MPI-based testsuite > > I think the end user should never have to deal with such "useful > information". Note that the end user is not seeing this problem, they are installing the binary packages and are not, in general, running the test suite. > If it is possible to detect beforehand that the test suite will fail > on a given system, then the package should probably enclose > dh_auto_test inside a suitable Makefile if/endif block. > > Alternatively, if the number "2" at the end of the debian/rules > line saying "export TEST_FLAGS=200 12 2" is the number of vcores > requested for the tests, then the package should probably honor > DEB_BUILD_OPTIONS=parallel=n so that no more vcores than available > are requested. Good point, I will investigate this. Thanks, Michael
Bug#1057556: [Debichem-devel] Bug#1057556: elpa: FTBFS: not enough slots available
severity 1057556 normal retitle 1057556 elpa: FTBFS unless machine has more than one vcore thanks Hi Santiago, On Tue, Dec 05, 2023 at 11:05:01PM +0100, Santiago Vila wrote: > Package: src:elpa > Version: 2022.11.001-2 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > During a rebuild of all packages in unstable, your package failed to build: > > > [...] > debian/rules build > dh build --max-parallel=1 --builddir=build >dh_update_autotools_config -O--max-parallel=1 -O--builddir=build >dh_autoreconf -O--max-parallel=1 -O--builddir=build > libtoolize: putting auxiliary files in '.'. > libtoolize: copying file './ltmain.sh' > libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. > libtoolize: copying file 'm4/libtool.m4' > libtoolize: copying file 'm4/ltoptions.m4' > libtoolize: copying file 'm4/ltsugar.m4' > libtoolize: copying file 'm4/ltversion.m4' > libtoolize: copying file 'm4/lt~obsolete.m4' > configure.ac:298: warning: The macro `AC_PROG_CC_C99' is obsolete. > configure.ac:298: You should run autoupdate. > > [... snipped ...] > > -- > FAIL validate_complex_double_invert_triangular_default.sh (exit status: 1) > > FAIL: validate_real_double_explicit_invert_triangular_default.sh > > > -- > There are not enough slots available in the system to satisfy the 2 > slots that were requested by the application: > > ./validate_real_double_explicit_invert_triangular [...] > About the archive rebuild: The build was made using virtual machines > from AWS, with enough memory, enough disk, and either one or two > CPUs, using a reduced chroot with only build-essential packages. So you are building elpa on a machine/vm with one cpu/vcore apparently? I guess it is useful information that elpa requires at least two cores to executes its MPI-based testsuite, but I don't think that this should be a general requirement for an RC bug, so downgrading to normal for now. If you indeed have more than 1 cpu core/vcore available, then I agree that this is RC. Michael
Bug#1053548: check-patroni: does not work well with current Patroni
Hi David, On Mon, Oct 23, 2023 at 07:17:11PM +0200, David Prévot wrote: > First of all thanks a lot for your bug report! Sorry that it took me so long to reply now :-/ > Le Fri, Oct 06, 2023 at 09:11:32AM +0200, Michael Banck a écrit : > > Package: check-patroni > > Version: 1.0.0-1 > > Severity: normal > > Tags: patch > > > > Hi, > > > > since version 3.0.4, Patroni displays "streaming" as state if a node is > > actually replicating from its leader. This is taken into account by > > check-patroni 1.0.0 (see https://github.com/dalibo/check_patroni/pull/30). > […] > > I was hoping to answer to your message sooner, and dig deeper into your > advises, but couldn’t find the time yet, and I’m afraid I won’t have > much time until at least a few weeks. So please consider this message as > an apology and an acknowledgement of the various issues and fixes you > pointed. > > > Actually, I did not realize you had uploaded check-patroni and > > independently packaged it for the pkg-postgres team here: > > https://salsa.debian.org/postgresql/check-patroni > > Ha, I quickly prepared this package during DebConf and didn’t try to > reach out to the Python or PostgreSQL teams, so thanks for the heads up. > FWIW, I’d be happy to move the packaging under the PostgreSQL team > umbrella if it makes sense. So, what are your plans? I can offer to take over the packaging of check-patroni as part of the Postgres team; I'd move the git to salsa.debian.org/postgresql and merge in a few of the things I did differently. If you want to go ahead and keep maintaining this, that'd be fine as well of course. Cheers, Michael
Bug#967333: exult: depends on deprecated GTK 2
Hi, On Sat, Oct 21, 2023 at 02:35:02AM +0200, Bastian Germann wrote: > Control: block -1 by 967394 > > The GIMP plugin is the only thing that needs GTK 2. I've dropped the libgtk2.0-dev Build-Dependency from exult now, but yeah, libgtk2.0 is still picked up via GIMP for the binary package. Michael
Bug#1054177: [Debichem-devel] Bug#1054177: src:cp2k: fails to migrate to testing for too long: no longer buildable on armel
Hi, On Wed, Oct 18, 2023 at 07:28:14PM +0200, Paul Gevers wrote: > If you believe your package is unable to migrate to testing due to issues > beyond your control, don't hesitate to contact the Release Team. I am not sure it is out of my control or not, but the issue seems to be that armel is not able to run the dbcsr testsuite without timing out, so a cp2k Build-Depends is missing. Michael
Bug#1053548: check-patroni: does not work well with current Patroni
Package: check-patroni Version: 1.0.0-1 Severity: normal Tags: patch Hi, since version 3.0.4, Patroni displays "streaming" as state if a node is actually replicating from its leader. This is taken into account by check-patroni 1.0.0 (see https://github.com/dalibo/check_patroni/pull/30). However, the way 1.0.0 handles this is suboptimal: It accepts both "running" and "streaming" as valid states; however, a state of "running" for Patroni 3.0.4 and up means broken replication and check-patroni should not consider this as OK. This is being worked on upstream as https://github.com/dalibo/check_patroni/pull/54. I found another issue however: The streaming state for Standby leaders was not included in PR#30, so the cluster_has_leader check returns CRITICAL for standby clusters. This has been filed as https://github.com/dalibo/check_patroni/issues/58. I'm attaching two patches for your consideration - the first one is the draft PR#54 and the second a fix for issue #58, which however will likely not work well with older Patroni versions, so not sure whether this is something you want to include at this point. Actually, I did not realize you had uploaded check-patroni and independently packaged it for the pkg-postgres team here: https://salsa.debian.org/postgresql/check-patroni I'll drop that once check-patroni in unstable works fine with current Patroni. Cheers, Michael -- System Information: Debian Release: 10.13 APT prefers oldoldstable-updates APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-22-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled >From 341ac64702569cf68ebe29053c0d076e409fc72f Mon Sep 17 00:00:00 2001 From: benoit Date: Wed, 27 Sep 2023 16:37:40 +0200 Subject: [PATCH 1/5] cluster_has_replica: fix the way a healthy replica is detected For patroni >= version 3.0.4: * the role is replica or sync_standby * the state is streaming * the lag is lower or equal to max_lag For prio versions: * the role is replica or sync_standby * the state is running and with the same timeline has the leader * the lag is lower or equal to max_lag --- CHANGELOG.md | 2 ++ README.md| 3 ++- check_patroni/cli.py | 3 ++- check_patroni/cluster.py | 51 ++-- 4 files changed, 50 insertions(+), 9 deletions(-) Index: check-patroni/CHANGELOG.md === --- check-patroni.orig/CHANGELOG.md +++ check-patroni/CHANGELOG.md @@ -6,6 +6,8 @@ ### Fixed +* Fix what `cluster_has_replica` deems a healthy replica. (#50, reported by @mbanck) + ### Misc ## check_patroni 1.0.0 - 2023-08-28 Index: check-patroni/README.md === --- check-patroni.orig/README.md +++ check-patroni/README.md @@ -170,8 +170,9 @@ Usage: check_patroni cluster_has_replica Check if the cluster has healthy replicas and/or if some are sync standbies A healthy replica: - * is in running or streaming state (V3.0.4) * has a replica or sync_standby role + * is in running state with the same timeline has the leader (patroni < V3.0.4) + * is in streaming state (patroni >= V3.0.4) * has a lag lower or equal to max_lag Check: @@ -182,8 +183,9 @@ Usage: check_patroni cluster_has_replica Perfdata: * healthy_replica & unhealthy_replica count * the number of sync_replica, they are included in the previous count - * the lag of each replica labelled with "member name"_lag - * a boolean to tell if the node is a sync stanbdy labelled with "member name"_sync + * the lag of each replica labelled with "member name"_lag + * the timeline of each replica labelled with "member name"_timeline + * a boolean to tell if the node is a sync stanbdy labelled with "member name"_sync Options: -w, --warning TEXTWarning threshold for the number of healthy replica Index: check-patroni/check_patroni/cli.py === --- check-patroni.orig/check_patroni/cli.py +++ check-patroni/check_patroni/cli.py @@ -343,8 +343,9 @@ def cluster_has_replica( \b A healthy replica: -* is in running or streaming state (V3.0.4) * has a replica or sync_standby role +* is in running state with the same timeline has the leader (patroni < V3.0.4) +* is in streaming state (patroni >= V3.0.4) * has a lag lower or equal to max_lag \b @@ -357,8 +358,9 @@ def cluster_has_replica( Perfdata: * healthy_replica & unhealthy_replica count * the number of sync_replica, they are included in the previous count -* the lag of each replica labelled with "member
Bug#1052028: please update to pydantic 2.x
Hi Timo, On Sat, Sep 16, 2023 at 12:26:32PM +0200, Timo Röhling wrote: > I would like to have pydantic updated to the latest 2.x major release, > because rstcheck depends on it. > > The 2.x API has some breaking changes, but according to the pydantic > README, version 1.10.4 is shipped as pydantic.v1 legacy module. > Therefore, any reverse dependency which is incompatible with the 2.x API > can be fixed trivially at import level. > > As pydantic is only weakly team managed, I am submitting this wishlist > bug, but I am willing to do the grunt work for this and provide the > necessary team uploads. Please go ahead, I don't think I will have time before the end of Debconf to do this, and then probably even less for a while afterwards Michael
Bug#1051986: scalapack: cmake files miss multiarch, referencing missing file
Source: scalapack
Version: 2.2.1-2
Severity: serious
Hi,
I'm building a package that can use scalapack; it uses cmake as build
system and fails configuring as such:
|dh_auto_configure -- \
| -DCMAKE_BUILD_TYPE= \
| -DBUILD_SHARED_LIBS=NO \
| -DBUILD_TESTING=YES \
| -DENABLE_SCALAPACK_MPI=YES
| cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake
|-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None
|-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var
|-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
|-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF
|-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
|-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run
|"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON
|-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_BUILD_TYPE=
|-DBUILD_SHARED_LIBS=NO -DBUILD_TESTING=YES -DENABLE_SCALAPACK_MPI=YES ..
|-- Setting build type to Release as none was set
|-- Will use the mpi_f08 Fortran module
|CMake Error at
|/usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets.cmake:93
|(message):
| The imported target "scalapack" references the file
|
| "/usr/lib/libscalapack-openmpi.so.2.2.1"
|
| but this file does not exist. Possible reasons include:
|
| * The file was deleted, renamed, or moved to another location.
|
| * An install or uninstall procedure did not complete successfully.
|
| * The installation package was faulty and contained
|
| "/usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets.cmake"
|
| but not all the files it references.
|
|Call Stack (most recent call first):
| /usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-config.cmake:2
|(include)
| CMakeLists.txt:61 (find_package)
Looking at
/usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets-none.cmake it
does not take multiarch into account:
|# grep PREFIX.*openmpi
/usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets-none.cmake
| IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/lib/libscalapack-openmpi.so.2.2.1"
|list(APPEND _cmake_import_check_files_for_scalapack
"${_IMPORT_PREFIX}/lib/libscalapack-openmpi.so.2.2.1" )
If I add (see attached patch), the build goes fine. I have not looked so
far at what it would take to change in the scalapack build system to fix
this.
Michael
-- System Information:
Debian Release: 10.13
APT prefers oldoldstable-updates
APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-22-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- /usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets-none.cmake 2023-09-15 11:27:13.423032655 +
+++ /usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets-none.cmake.new 2023-09-15 11:26:56.347447809 +
@@ -8,12 +8,12 @@
# Import target "scalapack" for configuration "None"
set_property(TARGET scalapack APPEND PROPERTY IMPORTED_CONFIGURATIONS NONE)
set_target_properties(scalapack PROPERTIES
- IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/lib/libscalapack-openmpi.so.2.2.1"
+ IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/lib/${CMAKE_LIBRARY_ARCHITECTURE}/libscalapack-openmpi.so.2.2.1"
IMPORTED_SONAME_NONE "libscalapack-openmpi.so.2.2"
)
list(APPEND _cmake_import_check_targets scalapack )
-list(APPEND _cmake_import_check_files_for_scalapack "${_IMPORT_PREFIX}/lib/libscalapack-openmpi.so.2.2.1" )
+list(APPEND _cmake_import_check_files_for_scalapack "${_IMPORT_PREFIX}/lib/${CMAKE_LIBRARY_ARCHITECTURE}/libscalapack-openmpi.so.2.2.1" )
# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)
Bug#1027025: [Debichem-devel] Bug#1027025: psi4: FTBFS with Python 3.11 as default version
Hi James, On Thu, Jan 05, 2023 at 04:14:24PM +, James Addison wrote: > Source: psi4 > Version: 1:1.3.2+dfsg-3 > Followup-For: Bug #1027025 > > I've opened a merge request[1] to address what I thought was a > cmake-related build failure cause on Python 3.11, described in my > previous message.. however it looks like the package has built > successfully since then - so I might have been on the wrong track > there (apologies). Thanks, I've merged it. I think it always built fine, but psi4 was broken at runtime so all the tests failed, but that did not lead to a build failure. With your patch, most of the tests pass and I'll have to investigate the remaining numerical issues. Michael
Bug#1026294: vip-manager: FTBFS: cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument to arp.NewPacket
Hi, On Sat, Dec 17, 2022 at 10:08:45PM +, Mathias Gibbens wrote: > Source: vip-manager > Version: 1.0.2-3 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > > vip-manager is failing to build in a clean sid schroot: > > > github.com/cybertec-postgresql/vip-manager/ipmanager > > # github.com/cybertec-postgresql/vip-manager/ipmanager > > src/github.com/cybertec-postgresql/vip-manager/ipmanager/basicConfigurer_linux.go:101:3: > > cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument > > to arp.NewPacket > > src/github.com/cybertec-postgresql/vip-manager/ipmanager/basicConfigurer_linux.go:103:3: > > cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument > > to arp.NewPacket > > src/github.com/cybertec-postgresql/vip-manager/ipmanager/basicConfigurer_linux.go:125:3: > > cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument > > to arp.NewPacket > > src/github.com/cybertec-postgresql/vip-manager/ipmanager/basicConfigurer_linux.go:127:3: > > cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument > > to arp.NewPacket This is due to an update in golang-github-mdlayher-arp-dev that pulled in this: https://github.com/mdlayher/arp/commit/6706a2966875c189c24afd003ffe801ff69542a1 Michael
Bug#1022469: python-pint: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13
tags 1022469 +patch
thanks
Hi,
On Wed, Nov 23, 2022 at 07:48:47PM +1100, Stuart Prescott wrote:
> pint is incompatible with babel > 2.8; unfortunately, Debian now has babel
> 2.10.
>
> So far, upstream has only noted the compatibility with version pinning.
>
> https://github.com/hgrecco/pint/issues/1219
>
> Upstream tests for newer releases of pint also now fail due to this same
> reason.
Looks like they got a work-around here in (since closed) PR #1401:
https://github.com/hgrecco/pint/commit/eb4e13428a3ede09148b76c71bc5b8cddb169176.patch
If I stick this (also attached) patch in, the testsuite passes fine.
> (and we should enable autopkgtest tests for pint and then this would have
> been caught as soon as babel > 2.8 was uploaded)
Yeah.
Michael
>From eb4e13428a3ede09148b76c71bc5b8cddb169176 Mon Sep 17 00:00:00 2001
From: Hernan
Date: Wed, 27 Oct 2021 20:36:40 -0300
Subject: [PATCH] Support for babel > 2.8
Close #1400, #1219 and #1296.
---
pint/formatting.py| 11 ---
pint/testsuite/test_issues.py | 8
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/pint/formatting.py b/pint/formatting.py
index a04205dd9..528f4e03e 100644
--- a/pint/formatting.py
+++ b/pint/formatting.py
@@ -333,9 +333,14 @@ def formatter(
# Don't remove this positional! This is the format used in Babel
key = pat.replace("{0}", "").strip()
break
-division_fmt = compound_unit_patterns.get("per", {}).get(
-babel_length, division_fmt
-)
+
+tmp = compound_unit_patterns.get("per", {}).get(babel_length, division_fmt)
+
+try:
+division_fmt = tmp.get("compound", division_fmt)
+except AttributeError:
+division_fmt = tmp
+
power_fmt = "{}{}"
exp_call = _pretty_fmt_exponent
if value == 1:
diff --git a/pint/testsuite/test_issues.py b/pint/testsuite/test_issues.py
index ed781b72f..9d4167c02 100644
--- a/pint/testsuite/test_issues.py
+++ b/pint/testsuite/test_issues.py
@@ -824,6 +824,14 @@ def test_issue_1300(self):
m = ureg.Measurement(1, 0.1, "meter")
assert m.default_format == "~P"
+def test_issue_1400(self, sess_registry):
+q1 = 3 * sess_registry.W
+q2 = 3 * sess_registry.W / sess_registry.cm
+assert q1.format_babel("~", locale="es_Ar") == "3 W"
+assert q1.format_babel("", locale="es_Ar") == "3 vatios"
+assert q2.format_babel("~", locale="es_Ar") == "3.0 W / cm"
+assert q2.format_babel("", locale="es_Ar") == "3.0 vatios por centímetros"
+
if np is not None:
Bug#1006788: [Debichem-devel] Bug#1006788: bagel: autopkgtest failure with new mpich.
Hi, On Wed, Aug 17, 2022 at 10:25:38PM +0200, Paul Gevers wrote: > Control: severity -1 serious > Control: retitle -1 autopkgtest fails on hosts with lots of RAM/cores > > Hi, > > On Sun, 3 Apr 2022 19:42:42 +0200 Michael Banck wrote: > > Hrm, it seems that test case passed now on the latest upload: > > https://ci.debian.net/data/autopkgtest/unstable/amd64/b/bagel/20573831/log.gz > > > > |Get:14 http://deb.debian.org/debian unstable/main amd64 libmpich12 amd64 > > 4.0.1-1 [4,924 kB] > > [...] > > |running test case 'he3_svp_asd-dmrg'... PASSED. > > > > So I'm a bit at a loss about what's going on here, perhaps that test > > case really is just flakey. > > Yes, this test looks flaky (I came here because it was blocking glibc). The > good news is however, it seems related to the host that runs the test. I.e. > the test fails on our beefy amd64 host (ci-worker13) with 64 cores and 256GB > RAM, but seems to pass on the others. > > The error on s390x is the same by the way (that has 10 cores and 32GB RAM). I can reproduce this again on my developer (amd64) notebook. If I downgrade mpich from 4.0.2 to 3.x, it passes fine: |(unstable-amd64-sbuild)mba@curie:/tmp/autopkgtest.p02Sns/build.Osj/src$ dpkg -l | grep mpich |ii libmpich12:amd64 3.4.1-5 amd64 Shared libraries for MPICH |(unstable-amd64-sbuild)mba@curie:/tmp/autopkgtest.p02Sns/build.Osj/src$ ./debian/tests/testsuite.sh |running test case 'he3_svp_asd-dmrg'... PASSED. |All tests passed |(unstable-amd64-sbuild)mba@curie:/tmp/autopkgtest.p02Sns/build.Osj/src$ dpkg -l | grep mpich |ii libmpich12:amd64 4.0.2-2 amd64 Shared libraries for MPICH |(unstable-amd64-sbuild)mba@curie:/tmp/autopkgtest.p02Sns/build.Osj/src$ ./debian/tests/testsuite.sh |running test case 'he3_svp_asd-dmrg'... FAILED. | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * broadcast 0.00 | * dmrg block 0.00 | >> ** .. 0.17 | |
Bug#1021057: [Debichem-devel] Bug#1021057: cp2k autopkgtest times outs on armel
Hi Paul, On Sat, Oct 01, 2022 at 11:53:27AM +0200, Paul Gevers wrote: > Source: cp2k > Version: 6.1-2 I guess that was supposed to be 9.1-2, as that is (was) current and the log you referenced also has that. I agree with Adrian and downgraded this bug to important for now. Michael
Bug#1005202: [Debichem-devel] Bug#1005202: openmolcas: Is the -fno-expensive-optimizations flag still needed?
Hi João, On Tue, Feb 08, 2022 at 11:31:20PM +, João wrote: > Source: openmolcas > Version: 21.10-1 > Severity: normal > > Dear Maintainer, > > Is the compiler flag -fno-expensive-optimizations in debian/rules still > needed? > This flag was introduced to fix a problem with the arm64 build as reported in > the bug > https://bugs.debian.org/961704 > and associated upstream issue > https://gitlab.com/Molcas/OpenMolcas/-/issues/218 > > However the following merge request applied upstream > https://gitlab.com/Molcas/OpenMolcas/-/merge_requests/420 > suggests that the issue might have been fixed with the flag -ffp-contract=off I've replaced -fno-expensive-optimizations with -ffp-contract=off now, but from reading the MR description it sounds like that new flag is only needed for one test that we don't run during autopkgtest currently. Still, I guess it won't hurt. Let's see whether arm64 still works... Michael
Bug#1008355: python-ldap: _slaptest.py fails with "slapd exited before opening port", breaking other package builds
Hi, On Sun, Apr 24, 2022 at 02:49:41PM +0200, Michael Banck wrote: > If I apply the mentioned (and attached patch), slapd starts up fine: > > |>>> import slapdtest > |>>> server = slapdtest.SlapdObject() > |>>> server.start() > |starting slapd: %r /usr/sbin/slapd -f > /build/django-auth-ldap-3.0.0/python-ldap-test-49837/slapd.conf -F > /build/django-auth-ldap-3.0.0/python-ldap-test-49837/slapd.d -h > ldap://127.0.0.1:49837/ > ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-49837%2Fldapi -d > 0 > |>>> > > and django-auth-ldap's tests pass: > > |I: pybuild base:239: PYTHONPATH=. python3.9 /usr/bin/django-admin test > --settings tests.settings > |Creating test database for alias 'default'... > |System check identified no issues (0 silenced). > |starting slapd: %r /usr/sbin/slapd -f > /build/django-auth-ldap-3.0.0/python-ldap-test-33057/slapd.conf -F > /build/django-auth-ldap-3.0.0/python-ldap-test-33057/slapd.d -h > ldap://127.0.0.1:33057/ > ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-33057%2Fldapi -d > 0 > | > |-- > |Ran 88 tests in 3.494s > | > |OK However, python-ldap still doesn't get through its test suite (which really should be run during package build or as autopkgtest) with that patch, but with the attached updated patch it passes fine: |Ran 235 tests in 42.709s | |OK (skipped=38, expected failures=5) Michael --- ./Lib/slapdtest/_slapdtest.py.orig 2022-04-24 12:55:37.979187400 + +++ ./Lib/slapdtest/_slapdtest.py 2022-04-24 12:55:59.327002871 + @@ -402,7 +402,6 @@ slapd_args = [ self.PATH_SLAPD, '-f', self._slapd_conf, -'-F', self.testrundir, '-h', ' '.join(urls), ] if self._log.isEnabledFor(logging.DEBUG):
Bug#1008355: django-auth-ldap: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom "--test-args=PYTHONPATH=. {interpreter} /usr/bin/django-admin test --settings
forwarded 1008355 https://github.com/python-ldap/python-ldap/issues/422
tags +patch
thanks
Hi,
On Sun, Apr 24, 2022 at 01:21:33PM +0200, Michael Banck wrote:
> This error comes from python3-ldap's slaptest:
>
> |$ python3
> |Python 3.10.4 (main, Apr 2 2022, 09:04:19) [GCC 11.2.0] on linux
> |Type "help", "copyright", "credits" or "license" for more information.
> |>>> import slapdtest
> |>>> server = slapdtest.SlapdObject()
> |>>> server.start()
> |Traceback (most recent call last):
> | File "", line 1, in
> | File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 445,
> in start
> |self._start_slapd()
> | File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 420,
> in _start_slapd
> |raise RuntimeError("slapd exited before opening port")
> |RuntimeError: slapd exited before opening port
> |>>>
>
> Not sure what the actual problem is,
When I add debugging (using "slapd_args.extend(['-d', '-1'])"
unconditionally around line 409), I get
|>>> import slapdtest
|>>> server = slapdtest.SlapdObject()
|>>> server.start()
|starting slapd: %r /usr/sbin/slapd -f
/build/django-auth-ldap-3.0.0/python-ldap-test-45785/slapd.conf -F
/build/django-auth-ldap-3.0.0/python-ldap-test-45785 -h ldap://127.0.0.1:45785/
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi -d -1
|62654543.29b9109c 0x7f121ed57980 @(#) $OpenLDAP: slapd 2.5.11+dfsg-1 (Mar 12
2022 03:38:02) $
| Debian OpenLDAP Maintainers
|62654544.008b742b 0x7f121ed57980 daemon_init: ldap://127.0.0.1:45785/
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi
|62654544.008cb95c 0x7f121ed57980 daemon_init: listen on ldap://127.0.0.1:45785/
|62654544.008ccf75 0x7f121ed57980 daemon_init: listen on
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi
|62654544.008ce019 0x7f121ed57980 daemon_init: 2 listeners to open...
|62654544.008cf2ec 0x7f121ed57980 ldap_url_parse_ext(ldap://127.0.0.1:45785/)
|62654544.008d759a 0x7f121ed57980 daemon: listener initialized
ldap://127.0.0.1:45785/
|62654544.008d8a56 0x7f121ed57980
ldap_url_parse_ext(ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi)
|62654544.008e74f4 0x7f121ed57980 daemon: listener initialized
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi
|62654544.008e85df 0x7f121ed57980 daemon_init: 2 listeners opened
|62654544.0099667a 0x7f121ed57980 slapd init: initiated server.
|62654544.009b64a3 0x7f121ed57980 slap_sasl_init: initialized!
|62654544.00b255c4 0x7f121ed57980 backend_startup_one: starting "cn=config"
|62654544.00b36ec4 0x7f121ed57980 config_setup_ldif: expected directory
/build/django-auth-ldap-3.0.0/python-ldap-test-45785 to be empty!
|62654544.00b440d5 0x7f121ed57980 slapd destroy: freeing system resources.
|62654544.00b6056e 0x7f121ed57980 slapd stopped.
|62654544.00b6821b 0x7f121ed57980 connections_destroy: nothing to destroy.
|Traceback (most recent call last):
| File "", line 1, in
| File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 447, in
start
|self._start_slapd()
| File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 422, in
_start_slapd
|raise RuntimeError("slapd exited before opening port")
|RuntimeError: slapd exited before opening port
The error seems to be
|config_setup_ldif: expected directory
/build/django-auth-ldap-3.0.0/python-ldap-test-45785 to be empty!
which is open upstream item at
https://github.com/python-ldap/python-ldap/issues/422
If I apply the mentioned (and attached patch), slapd starts up fine:
|>>> import slapdtest
|>>> server = slapdtest.SlapdObject()
|>>> server.start()
|starting slapd: %r /usr/sbin/slapd -f
/build/django-auth-ldap-3.0.0/python-ldap-test-49837/slapd.conf -F
/build/django-auth-ldap-3.0.0/python-ldap-test-49837/slapd.d -h
ldap://127.0.0.1:49837/
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-49837%2Fldapi -d 0
|>>>
and django-auth-ldap's tests pass:
|I: pybuild base:239: PYTHONPATH=. python3.9 /usr/bin/django-admin test
--settings tests.settings
|Creating test database for alias 'default'...
|System check identified no issues (0 silenced).
|starting slapd: %r /usr/sbin/slapd -f
/build/django-auth-ldap-3.0.0/python-ldap-test-33057/slapd.conf -F
/build/django-auth-ldap-3.0.0/python-ldap-test-33057/slapd.d -h
ldap://127.0.0.1:33057/
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-33057%2Fldapi -d 0
|
|--
|Ran 88 tests in 3.494s
|
|OK
Michael
diff
Bug#1008355: django-auth-ldap: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom "--test-args=PYTHONPATH=. {interpreter} /usr/bin/django-admin test --settings
reassign 1008355 python-ldap
retitle 1008355 python-ldap: _slaptest.py fails with "slapd exited before
opening port", breaking other package builds
notfound 3.0.0-1
found 1008355 3.2.0-4
thanks
Hi,
On Sat, Mar 26, 2022 at 09:35:43PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_test -- --system=custom --test-args="PYTHONPATH=. {interpreter}
> > /usr/bin/django-admin test --settings tests.settings"
> > I: pybuild pybuild:298: cp -r /<>/tests
> > /<>/.pybuild/cpython3_3.10_django-auth-ldap/build
> > I: pybuild base:237: PYTHONPATH=. python3.10 /usr/bin/django-admin test
> > --settings tests.settings
> > Creating test database for alias 'default'...
> > System check identified no issues (0 silenced).
> > E
> > ==
> > ERROR: setUpClass (tests.tests.LDAPTest)
> > --
> > Traceback (most recent call last):
> > File "/<>/tests/tests.py", line 140, in setUpClass
> > cls.server.start()
> > File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 445,
> > in start
> > self._start_slapd()
> > File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 420,
> > in _start_slapd
> > raise RuntimeError("slapd exited before opening port")
> > RuntimeError: slapd exited before opening port
> >
> > --
> > Ran 0 tests in 1.517s
This error comes from python3-ldap's slaptest:
|$ python3
|Python 3.10.4 (main, Apr 2 2022, 09:04:19) [GCC 11.2.0] on linux
|Type "help", "copyright", "credits" or "license" for more information.
|>>> import slapdtest
|>>> server = slapdtest.SlapdObject()
|>>> server.start()
|Traceback (most recent call last):
| File "", line 1, in
| File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 445, in
start
|self._start_slapd()
| File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 420, in
_start_slapd
|raise RuntimeError("slapd exited before opening port")
|RuntimeError: slapd exited before opening port
|>>>
Not sure what the actual problem is, but one problem is that
python3-ldap is not exercising the upstream test suite; if I install
slapd and ldap-utils and run "pybuild --test" in python-ldap-3.2.0's
source directory, I also end up with erorrs like:
|==
|ERROR: setUpClass (Tests.t_ldap_sasl.TestSasl)
|--
|Traceback (most recent call last):
| File "/build/python-ldap-3.2.0/Tests/t_ldap_sasl.py", line 50, in setUpClass
|super(TestSasl, cls).setUpClass()
| File "/build/python-ldap-3.2.0/Lib/slapdtest/_slapdtest.py", line 594, in
setUpClass
|cls.server.start()
| File "/build/python-ldap-3.2.0/Lib/slapdtest/_slapdtest.py", line 445, in
start
|self._start_slapd()
| File "/build/python-ldap-3.2.0/Lib/slapdtest/_slapdtest.py", line 420, in
_start_slapd
|raise RuntimeError("slapd exited before opening port")
|RuntimeError: slapd exited before opening port
|
|--
|Ran 104 tests in 22.132s
|
|FAILED (errors=11, skipped=6, expected failures=3)
|Test failed:
|error: Test failed:
|E: pybuild pybuild:369: test: plugin distutils failed with: exit code=1:
python3.10 setup.py test
Michael
Bug#1009281: [Debichem-devel] Bug#1009281: Bug#1009281: Should cinfony be removed?
Hi, On Mon, Apr 11, 2022 at 08:38:21AM +0300, Andrius Merkys wrote: > Hi, > > On 2022-04-11 01:35, Moritz Muehlenhoff wrote: > > Source: cinfony > > Version: 1.2-4 > > Severity: serious > > > > Your package came up as a candidate for removal from Debian: > > > > - Still depends on Python 2 and thus removed from testing since 2019 > > - Dead upstream > > - No reverse dependencies > > Incidentally, I was the last to upload this package. Since 2019 there > were no uploads, due to aforementioned reasons. I have contemplated > filing for RM ever since, but did not get to it. I think it is fine to > remove. If Python 3 port ever happens, we can reintroduce the package then. I contacted the author and asked him about it - it seems the master branch on Github has python3 support, but I didn't look very closely. Michael
Bug#1006788: Bug#1006788: bagel: autopkgtest failure with new mpich.
severity 1006788 important thanks On Sun, Apr 03, 2022 at 07:42:42PM +0200, Michael Banck wrote: > On Sun, Apr 03, 2022 at 02:30:14PM +0200, Michael Banck wrote: > > On Fri, Mar 04, 2022 at 11:36:24PM +, peter green wrote: > > > Package: bagel > > > Version: 1.2.2-3 > > > Severity: serious > > > x-debbugs-cc: mp...@packages.debian.org > > > > > > bagel's autopkgtest is failing on amd64 with mpich 4.0.1-1 and hence > > > blocking it's migration to testing and hence blocking the finalisation > > > of the slurm-wlm transition. > > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/b/bagel/19726694/log.gz > > > > > > > running test case 'he3_svp_asd-dmrg'... FAILED. > > > > For the record, the error in the .out file is: > > > > | ERROR: EXCEPTION RAISED: dsyev/pdsyevd failed in Matrix > > Hrm, it seems that test case passed now on the latest upload: > https://ci.debian.net/data/autopkgtest/unstable/amd64/b/bagel/20573831/log.gz > > |Get:14 http://deb.debian.org/debian unstable/main amd64 libmpich12 amd64 > 4.0.1-1 [4,924 kB] > [...] > |running test case 'he3_svp_asd-dmrg'... PASSED. > > So I'm a bit at a loss about what's going on here, perhaps that test > case really is just flakey. Downgrading this as ci.debian.net seems to be happy about it now. Michael
Bug#1006788: [Debichem-devel] Bug#1006788: Bug#1006788: bagel: autopkgtest failure with new mpich.
Hi, On Sun, Apr 03, 2022 at 02:30:14PM +0200, Michael Banck wrote: > On Fri, Mar 04, 2022 at 11:36:24PM +, peter green wrote: > > Package: bagel > > Version: 1.2.2-3 > > Severity: serious > > x-debbugs-cc: mp...@packages.debian.org > > > > bagel's autopkgtest is failing on amd64 with mpich 4.0.1-1 and hence > > blocking it's migration to testing and hence blocking the finalisation > > of the slurm-wlm transition. > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/b/bagel/19726694/log.gz > > > > > running test case 'he3_svp_asd-dmrg'... FAILED. > > For the record, the error in the .out file is: > > | ERROR: EXCEPTION RAISED: dsyev/pdsyevd failed in Matrix Hrm, it seems that test case passed now on the latest upload: https://ci.debian.net/data/autopkgtest/unstable/amd64/b/bagel/20573831/log.gz |Get:14 http://deb.debian.org/debian unstable/main amd64 libmpich12 amd64 4.0.1-1 [4,924 kB] [...] |running test case 'he3_svp_asd-dmrg'... PASSED. So I'm a bit at a loss about what's going on here, perhaps that test case really is just flakey. Michael
Bug#1006788: [Debichem-devel] Bug#1006788: bagel: autopkgtest failure with new mpich.
On Fri, Mar 04, 2022 at 11:36:24PM +, peter green wrote: > Package: bagel > Version: 1.2.2-3 > Severity: serious > x-debbugs-cc: mp...@packages.debian.org > > bagel's autopkgtest is failing on amd64 with mpich 4.0.1-1 and hence > blocking it's migration to testing and hence blocking the finalisation > of the slurm-wlm transition. > > https://ci.debian.net/data/autopkgtest/testing/amd64/b/bagel/19726694/log.gz > > > running test case 'he3_svp_asd-dmrg'... FAILED. For the record, the error in the .out file is: | ERROR: EXCEPTION RAISED: dsyev/pdsyevd failed in Matrix Michael
Bug#1006184: [Debichem-devel] Bug#1006184:
Hi, On Sat, Feb 26, 2022 at 11:20:38AM +0100, Aritz Erkiaga wrote: > I believe this is incorrect. Those two commits only close #1005006, while > #1006184 is closed by the single commit linked in this bug report. All > *three* commits have been merged into upstream, fixing both bugs. For > clarification, I'll link the *missing* patch (which does close this bug) > here. > > Fix for #1006184: > https://github.com/OpenChemistry/avogadrolibs/commit/c47d00c821ba77ea2b13aaa933cfc922f1980469 Ok, I've added this commit to the patch and uploaded another revision, thanks for the notice; as it was a bit older I didn't see it immediately in the avogadrolibs git commit history. Michael
Bug#1005006: [Debichem-devel] Bug#1005006: avogadro: manipulation tools do not work
Hi, On Thu, Feb 24, 2022 at 03:06:29AM +0100, Aritz Erkiaga wrote: > On 2/23/22 09:12, Michael Banck wrote: > > I think the first step would be to get the PR merged upstream, then we > > can merge it as a patch in Debian. > > > > I don't have the bandwidth right now (am on vacation this week) to > > reproduce this but and test whether the changes in the pull request > > fixes it. > > Good news, the PR is now merged! Also, a new bugfix release, 1.95.2, is on > the way, according to the main upstream dev. Thanks, I have uploaded avogadrolibs with the two commits now. Michael
Bug#1005006: [Debichem-devel] Bug#1005006: avogadro: manipulation tools do not work
Hi, On Wed, Feb 23, 2022 at 03:58:55AM +0100, Aritz Erkiaga wrote: > I've sent a pull request upstream to fix this bug: > https://github.com/OpenChemistry/avogadrolibs/pull/825 > > While I'm very sure the fix can't cause further breakage, I'm still unsure > how the problem actually arises. I think the first step would be to get the PR merged upstream, then we can merge it as a patch in Debian. I don't have the bandwidth right now (am on vacation this week) to reproduce this but and test whether the changes in the pull request fixes it. Michael
Bug#889714: Bug #889714: chmod: cannot access '/var/lib/etcd/': No such file or directory
severity 889714 serious thanks On Tue, Feb 06, 2018 at 10:36:41AM +0100, Christoph Berg wrote: > Package: etcd-server > Version: 3.2.9+dfsg-3 > Severity: important > > If etcd is already present in /etc/passwd, but /var/lib/etcd is > missing, installing etcd-server fails: > > Setting up etcd-server (3.2.9+dfsg-3) ... > chmod: cannot access '/var/lib/etcd/': No such file or directory > dpkg: error processing package etcd-server (--configure): > installed etcd-server package post-installation script subprocess returned > error exit status 1 > > The situation arises here because I'm installing it in a chroot with > /etc/passwd copied from the host system. It will also be seen on > systems with LDAP and other distributed user management systems. This breaks autopkgtests for me now; I don't know quite what I did with autopgktest/schroot setup to arrive here, but I recently installed etcd in my main root in order to debug something and I don't think it's reasonable to mandate one isn't allowed to do this in order for etcd to work. Michael
Bug#995123: cyrus-sasl2 FTBFS: sphinx: AttributeError: 'CyrusManualPageBuilder' object has no attribute 'settings'
tags 995123 +pending thanks Am Montag, dem 25.10.2021 um 14:58 +0200 schrieb Michael Banck: > On Sun, Sep 26, 2021 at 06:39:54PM -0700, Vagrant Cascadian wrote: > > I tested the attached patch which seems to fix this. > > This FTBFS has been open for about a month - are you going to NMU it > Vagrant? Otherwise, I will upload an NMU to DELAYED/$SOME-DAYS > soonish to move this forward. I've uploaded your patch to DELAYED/3-days now. Michael -- Michael Banck Teamleiter PostgreSQL-Team Projektleiter Tel.: +49 2166 9901-171 E-Mail: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Geoff Richardson, Peter Lilley Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Bug#995123: cyrus-sasl2 FTBFS: sphinx: AttributeError: 'CyrusManualPageBuilder' object has no attribute 'settings'
Hi Vagrant, On Sun, Sep 26, 2021 at 06:39:54PM -0700, Vagrant Cascadian wrote: > I tested the attached patch which seems to fix this. This FTBFS has been open for about a month - are you going to NMU it Vagrant? Otherwise, I will upload an NMU to DELAYED/$SOME-DAYS soonish to move this forward. Michael -- Michael Banck Team Lead PostgreSQL Project Manager Tel.: +49 2166 9901-171 Mail: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Management: Dr. Michael Meskes, Geoff Richardson, Peter Lilley Our handling of personal data is subject to: https://www.credativ.de/en/contact/privacy/
Bug#995157: libfido2: FTBFS with openssl3: error: ‘SHA256_Init’ is deprecated: Since OpenSSL 3.0)
tags 995157 +patch thanks Hi, the attach patch/debdiff fixes the build for me. Cheers, Michael -- Michael Banck Team Lead PostgreSQL Project Manager Tel.: +49 2166 9901-171 Mail: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Management: Dr. Michael Meskes, Sascha Heuer, Geoff Richardson, Peter Lilley Our handling of personal data is subject to: https://www.credativ.de/en/contact/privacy/ diff -Nru libfido2-1.6.0/debian/changelog libfido2-1.6.0/debian/changelog --- libfido2-1.6.0/debian/changelog 2021-01-16 23:46:13.0 +0100 +++ libfido2-1.6.0/debian/changelog 2021-10-12 17:33:01.0 +0200 @@ -1,3 +1,12 @@ +libfido2 (1.6.0-2+gl1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * debian/rules: Add -Wno-error=deprecated-declarations +-Wno-error=discarded-qualifiers to compile flags +Closes: #995157 + + -- Michael Banck Tue, 12 Oct 2021 17:33:01 +0200 + libfido2 (1.6.0-2) unstable; urgency=medium * No-op change from 1.6.0-1 to fix dgit history. diff -Nru libfido2-1.6.0/debian/rules libfido2-1.6.0/debian/rules --- libfido2-1.6.0/debian/rules 2021-01-16 23:46:13.0 +0100 +++ libfido2-1.6.0/debian/rules 2021-10-12 17:33:01.0 +0200 @@ -1,6 +1,8 @@ #!/usr/bin/make -f export DEB_BUILD_MAINT_OPTIONS = hardening=+all +export CFLAGS+=-Wno-error=deprecated-declarations +export CFLAGS+=-Wno-error=discarded-qualifiers %: dh $@
Bug#950232: software-properties-common: Wrong URL for Bullseye security updates
Hi, What I see is this: If in software-properties-gtk I swith from "Main server" to "German Server" (paraphrased), this diff gets written to sources.list: -deb http://security.debian.org/debian-security bullseye-security main contrib non-free +deb http://ftp.de.debian.org/debian/ bullseye-security main contrib non-free and the new line does not work: Fehl:6 http://ftp.de.debian.org/debian bullseye-security Release 404 Not Found [IP: 141.76.2.4 80] Using the revert button fixes it to work again. Michael
Bug#995152: FTBFS with openssl3: assignment discards const qualifier from pointer target type (-Werror=discarded-qualifiers)
retitle 995152 krb5: FTBFS with openssl3: assignment discards const qualifier from pointer target type (-Werror=discarded-qualifiers) user pkg-openssl-de...@lists.alioth.debian.org usertags 995152 ftbfs-3.0 thanks
Bug#995157: FTBFS with openssl3: error: ‘SHA256_Init’ is deprecated: Since OpenSSL 3.0
user pkg-openssl-de...@lists.alioth.debian.org usertags 995157 ftbfs-3.0 thanks
Bug#992891: Please package 1.8.2
Hi Sandro, On Mon, Oct 04, 2021 at 11:48:39PM -0400, Sandro Tosi wrote: > On Tue, 24 Aug 2021 22:44:48 +0500 Andrey Rahmatullin wrote: > > New python3-itemadapter supports pydantic, but only 1.8+ (as it uses > > allow_mutation) so I would be glad if it's updated to the latest version. > > Thank you. > > I echo the same requests: it appears fastapi/0.68.1 requires a newer > version of pydantic > > Michael, if you're busy i volunteer to take care of the upgrade Thanks, please go ahead. Michael
Bug#871622: [Bug #871622]: hello: please include a trivial autopkgtest for this trivial package
Hi, I noticed Matthias' patch doesn't apply anymore and that hello grew a "skip" test with exit status 77 that trips over the trivial shell loop, so I've skipped it there. New patch attached. Michael diff -Nru hello-2.10/debian/changelog hello-2.10/debian/changelog --- hello-2.10/debian/changelog 2019-05-13 20:06:50.0 +0200 +++ hello-2.10/debian/changelog 2018-09-24 14:35:00.0 +0200 @@ -1,3 +1,10 @@ +hello (2.10-2ubuntu1) cosmic; urgency=medium + + * Run the upstream tests as an autopkg test as well. + * Bump the standards version. + + -- Matthias Klose Mon, 24 Sep 2018 14:35:00 +0200 + hello (2.10-2) unstable; urgency=medium * Fix version skew. Closes: #928887. diff -Nru hello-2.10/debian/control hello-2.10/debian/control --- hello-2.10/debian/control 2019-05-13 19:00:00.0 +0200 +++ hello-2.10/debian/control 2018-09-24 14:35:00.0 +0200 @@ -6,6 +6,7 @@ Build-Depends: debhelper-compat (= 9) Homepage: http://www.gnu.org/software/hello/ Rules-Requires-Root: no +XS-Testsuite: autopkgtest Package: hello Architecture: any diff -Nru hello-2.10/debian/tests/control hello-2.10/debian/tests/control --- hello-2.10/debian/tests/control 1970-01-01 01:00:00.0 +0100 +++ hello-2.10/debian/tests/control 2018-09-24 14:35:00.0 +0200 @@ -0,0 +1,2 @@ +Test-Command: for i in tests/*; do if [ "$i" = "tests/greeting-2" ]; then continue; fi; echo "Testing $(basename $i) ..."; $i; done +Depends: hello
Bug#995157: FTBFS with openssl3: error: ‘SHA256_Init’ is deprecated: Since OpenSSL 3.0
Source: libfido2
Version: 1.8.0-1
Severity: important
Dear Maintainer,
libfido2 fails to build with openssl3 from experimental:
|[ 0%] Building C object src/CMakeFiles/fido2.dir/aes256.c.o
|cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/cc -DHAVE_CBOR_H
-DHAVE_CLOCK_GETTIME -DHAVE_DEV_URANDOM -DHAVE_ENDIAN_H -DHAVE_ERR_H
-DHAVE_EXPLICIT_BZERO -DHAVE_GETLINE -DHAVE_GETOPT -DHAVE_GETPAGESIZE
-DHAVE_GETRANDOM -DHAVE_OPENSSLV_H -DHAVE_SIGACTION -DHAVE_SIGNAL_H
-DHAVE_SYSCONF -DHAVE_SYS_RANDOM_H -DHAVE_UNISTD_H -DSIGNAL_EXAMPLE
-DTLS=__thread -D_FIDO_INTERNAL -D_FIDO_MAJOR=1 -D_FIDO_MINOR=8 -D_FIDO_PATCH=0
-I/<>/src -D_POSIX_C_SOURCE=200809L -D_BSD_SOURCE -D_GNU_SOURCE
-D_DEFAULT_SOURCE -std=c99 -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -Wall -Wextra -Werror -Wshadow -Wcast-qual
-Wwrite-strings -Wmissing-prototypes -Wbad-function-cast -pedantic
-pedantic-errors -fstack-protector-all -Wno-unused-result -Wconversion
-Wsign-conversion -MD -MT src/CMakeFiles/fido2.dir/aes256.c.o -MF
CMakeFiles/fido2.dir/aes256.c.o.d -o CMakeFiles/fido2.dir/aes256.c.o -c
/<>/src/aes256.c
|[ 0%] Generating eddsa_pk_new.3
|cd /<>/obj-x86_64-linux-gnu/man && cp -f
/<>/man/eddsa_pk_new.3 .
|[ 0%] Generating es256_pk_new.3
|cd /<>/obj-x86_64-linux-gnu/man && cp -f
/<>/man/es256_pk_new.3 .
|[ 0%] Generating fido2-assert.1
|cd /<>/obj-x86_64-linux-gnu/man && cp -f
/<>/man/fido2-assert.1 .
|[ 0%] Generating fido2-cred.1
|cd /<>/obj-x86_64-linux-gnu/man && cp -f
/<>/man/fido2-cred.1 .
|[ 0%] Generating fido2-token.1
|cd /<>/obj-x86_64-linux-gnu/man && cp -f
/<>/man/fido2-token.1 .
|/<>/src/assert.c: In function ‘fido_get_signed_hash’:
|/<>/src/assert.c:389:3: error: ‘SHA256_Init’ is deprecated: Since
OpenSSL 3.0 [-Werror=deprecated-declarations]
| 389 | if (dgst->len < SHA256_DIGEST_LENGTH || SHA256_Init() == 0 ||
| | ^~
|[...]
|In file included from /<>/src/assert.c:8:
|/usr/include/openssl/sha.h:76:27: note: declared here
| 76 | OSSL_DEPRECATEDIN_3_0 int SHA256_Final(unsigned char *md, SHA256_CTX
*c);
| | ^~~~
|/<>/src/assert.c: In function ‘fido_verify_sig_es256’:
|/<>/src/assert.c:433:6: error: ‘EVP_PKEY_get0_EC_KEY’ is
deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
| 433 | (ec = EVP_PKEY_get0_EC_KEY(pkey)) == NULL) {
| | ^
|In file included from /<>/src/fido.h:11,
| from /<>/src/assert.c:10:
|/usr/include/openssl/evp.h:1372:25: note: declared here
| 1372 | const struct ec_key_st *EVP_PKEY_get0_EC_KEY(const EVP_PKEY *pkey);
| | ^~~~
|/<>/src/assert.c:433:10: error: assignment discards ‘const’
qualifier from pointer target type [-Wdiscarded-qualifiers]
| 433 | (ec = EVP_PKEY_get0_EC_KEY(pkey)) == NULL) {
| | ^
|/<>/src/assert.c:438:2: error: ‘ECDSA_verify’ is deprecated:
Since OpenSSL 3.0 [-Werror=deprecated-declarations]
[...]
|cc1: all warnings being treated as errors
|make[3]: *** [src/CMakeFiles/fido2.dir/build.make:93:
src/CMakeFiles/fido2.dir/assert.c.o] Error 1
|make[3]: *** Waiting for unfinished jobs
Filing this as important for now, as long as openssl3 is not in unstable.
Michael
Bug#995152: FTBFS with openssl3: assignment discards const qualifier from pointer target type (-Werror=discarded-qualifiers)
Source: krb5
Version: 1.18.3-7
Severity: important
Tags: patch
Dear maintainer,
krb5 fails to build with openssl3 from experimental:
|make[4]: Entering directory '/<>/build/tests/softpkcs11'
|gcc -fPIC -DSHARED -DHAVE_CONFIG_H -I../../include -I../../../src/include
-I../../../src/plugins/preauth/pkinit -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wcast-align
-Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow
-Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes -Wreturn-type
-Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wunused-label
-Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare
-Werror=uninitialized -Wno-maybe-uninitialized -Werror=pointer-arith
-Werror=int-conversion -Werror=incompatible-pointer-types
-Werror=discarded-qualifiers -Werror=implicit-int
-Werror=declaration-after-statement -Werror-implicit-function-declaration
-pthread -c ../../../src/tests/softpkcs11/main.c -o main.so.o && mv -f
main.so.o main.so
|o > binutils.versions "HIDDEN { local: __*; _rest*; _save*; *; };"
|echo >> binutils.versions "softpkcs11_0_MIT {"
|sed >> binutils.versions < ../../../src/tests/softpkcs11/softpkcs11.exports
"s/$/;/"
|echo >> binutils.versions "};"
|../../../src/tests/softpkcs11/main.c: In function ‘application_error’:
|../../../src/tests/softpkcs11/main.c:161:5: warning: function
‘application_error’ might be a candidate for ‘gnu_printf’ format attribute
[-Wsuggest-attribute=format]
| 161 | vprintf(fmt, ap);
| | ^~~
|../../../src/tests/softpkcs11/main.c: In function ‘st_logf’:
|../../../src/tests/softpkcs11/main.c:174:5: warning: function ‘st_logf’ might
be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
| 174 | vfprintf(soft_token.logfile, fmt, ap);
| | ^~~~
|../../../src/tests/softpkcs11/main.c: In function ‘snprintf_fill’:
|../../../src/tests/softpkcs11/main.c:185:5: warning: function ‘snprintf_fill’
might be a candidate for ‘gnu_printf’ format attribute
[-Wsuggest-attribute=format]
| 185 | len = vsnprintf(str, size, fmt, ap);
| | ^~~
|../../../src/tests/softpkcs11/main.c: In function ‘add_pubkey_info’:
|../../../src/tests/softpkcs11/main.c:430:9: warning: ‘EVP_PKEY_get0_RSA’ is
deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
| 430 | rsa = EVP_PKEY_get0_RSA(key);
| | ^~~
|In file included from ../../../src/tests/softpkcs11/main.c:38:
|/usr/include/openssl/evp.h:1346:22: note: declared here
| 1346 | const struct rsa_st *EVP_PKEY_get0_RSA(const EVP_PKEY *pkey);
| | ^
|../../../src/tests/softpkcs11/main.c:430:13: error: assignment discards
‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
| 430 | rsa = EVP_PKEY_get0_RSA(key);
| | ^
|[...]
|cc1: some warnings being treated as errors
|make[4]: *** [Makefile:804: main.so] Error 1
|make[4]: Leaving directory '/<>/build/tests/softpkcs11'
|make[3]: *** [Makefile:1223: all-recurse] Error 1
|make[3]: Leaving directory '/<>/build/tests'
|make[2]: *** [Makefile:1546: all-recurse] Error 1
There is a patch in the OpenMandriva repository that fixes this and
which I have attached:
https://raw.githubusercontent.com/OpenMandrivaAssociation/krb5/master/krb5-openssl3.patch
(I am getting a "LaTeX Error: File `tgtermes.sty' not found." error then
which I have not further diagnosed).
Michael
diff -up krb5-1.19.1/src/tests/softpkcs11/main.c.omv~
krb5-1.19.1/src/tests/softpkcs11/main.c
--- krb5-1.19.1/src/tests/softpkcs11/main.c.omv~2021-03-29
17:46:17.495294577 +0200
+++ krb5-1.19.1/src/tests/softpkcs11/main.c 2021-03-29 17:50:06.618117704
+0200
@@ -427,7 +427,7 @@ add_pubkey_info(struct st_object *o, CK_
RSA *rsa;
const BIGNUM *n, *e;
-rsa = EVP_PKEY_get0_RSA(key);
+rsa = EVP_PKEY_get1_RSA(key);
RSA_get0_key(rsa, , , NULL);
modulus_bits = BN_num_bits(n);
@@ -680,7 +680,7 @@ add_certificate(char *label,
/* XXX verify keytype */
if (key_type == CKK_RSA)
-RSA_set_method(EVP_PKEY_get0_RSA(o->u.private_key.key),
+RSA_set_method(EVP_PKEY_get1_RSA(o->u.private_key.key),
RSA_PKCS1_OpenSSL());
if (X509_check_private_key(cert, o->u.private_key.key) != 1) {
@@ -1224,7 +1224,7 @@ C_Login(CK_SESSION_HANDLE hSession,
}
/* XXX check keytype */
-RSA_set_method(EVP_PKEY_get0_RSA(o->u.private_key.key),
+RSA_set_method(EVP_PKEY_get1_RSA(o->u.private_key.key),
RSA_PKCS1_OpenSSL());
if (X509_check_private_key(o->u.private_key.cert,
o->u.private_key.key) != 1) {
@@ -1512,7 +1512,7 @@ C_Encrypt(CK_SESSION_HANDLE hSession,
return CKR_ARGUMENTS_BAD;
Bug#994288: [Debichem-devel] Bug#994288: Bug#994288: libinchi1: feature request, add InChI trust, reference executable
Hi Norwid, On Sat, Sep 18, 2021 at 09:03:45PM +, Norwid Behrnd wrote: > On Sat, 18 Sep 2021 20:28:30 +0200 > Michael Banck wrote: > > On Thu, Sep 16, 2021 at 10:40:02AM +0300, Andrius Merkys wrote: > > > Control: owner -1 ! > > > Control: tags -1 + pending > > > > > > Hi Norwid, > > > > > > On 2021-09-16 09:26, Norwid Behrnd wrote: > > > >> Am I right to assume you are requesting here for the 'inchi_main' > > > >> executable being included in Debian packages for inchi? > > > > > > > > Yes, this is .true. and you are right. If technical possible and > > > > InChI trust's license permitting, I would like to install their .sdf > > > > to InChI conversion packaged for Debian such that this may be run > > > > from the CLI. > > > > > > Thanks for clarification. I have just packaged the executable in a new > > > binary package, libinchi-bin, it how has to pass the NEW queue. > > > > A bit late, but maybe "inchi-bin" or even juust "inchi" would be also > > appropriate? > > > > > > Michael > > I'm not sure if your question is about how to name the eventual > package, or about how to launch the executable the package provides. It was about the package. [...] > On the other hand, I interpret the package tracker's entry > > "NEW/unstable: 1.03+dfsg-4" > > on > > https://tracker.debian.org/pkg/inchi > > as if the inchi executable is going to be included within the already > existing entry `synaptic` lists as `libinchi1` No, there will (or is, it got manually processed already I think) be a new package "libinchi-bin" which ships the executable. Michael
Bug#994288: [Debichem-devel] Bug#994288: Bug#994288: libinchi1: feature request, add InChI trust, reference executable
Hi, On Thu, Sep 16, 2021 at 10:40:02AM +0300, Andrius Merkys wrote: > Control: owner -1 ! > Control: tags -1 + pending > > Hi Norwid, > > On 2021-09-16 09:26, Norwid Behrnd wrote: > >> Am I right to assume you are requesting here for the 'inchi_main' > >> executable being included in Debian packages for inchi? > > > > Yes, this is .true. and you are right. If technical possible and > > InChI trust's license permitting, I would like to install their .sdf > > to InChI conversion packaged for Debian such that this may be run > > from the CLI. > > Thanks for clarification. I have just packaged the executable in a new > binary package, libinchi-bin, it how has to pass the NEW queue. A bit late, but maybe "inchi-bin" or even juust "inchi" would be also appropriate? Michael
Bug#991920: please demote pkg-config to Recommends
On Thu, Aug 05, 2021 at 10:21:30PM +0200, Michael Banck wrote: > I've run "dracut --no-kernel" in a minimal lxc container, once with > pkg-config and once without and then diffoscope'd the two generated > initrds. Most of what diffoscope complains about are timestamp > differences in directories and symlinks which I don't know how to get > rid of, but there's some changes in etc/conf.d/systemd.conf that I have > attached. Not sure whether those are problematic? To clarify, the above was done on bullseye, on a usrmerge system. I see the same path changes in /etc/conf.d/systemd.conf if I try that on a real bullseye system. On a non-usrmerge buster system, diffoscope sees no such path differences between a dracut run with or without pkg-config. > │ ├── etc/conf.d/systemd.conf > │ │ @@ -1,3 +1,3 @@ > │ │ -systemdutildir="/lib/systemd" > │ │ -systemdsystemunitdir="/lib/systemd/system" > │ │ +systemdutildir="/usr/lib/systemd" > │ │ +systemdsystemunitdir="/usr/lib/systemd/system" > │ │ systemdsystemconfdir="/etc/systemd/system" > │ ├── usr/lib/systemd/system/ctrl-alt-del.target > │ │┄ symlink > │ │ @@ -1 +1 @@ > │ │ -destination: ../../../../lib/systemd/system/reboot.target > │ │ +destination: reboot.target Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Sascha Heuer, Geoff Richardson, Peter Lilley Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Bug#991920: Acknowledgement (please demote pkg-config to Recommends)
I've run "dracut --no-kernel" in a minimal lxc container, once with pkg-config and once without and then diffoscope'd the two generated initrds. Most of what diffoscope complains about are timestamp differences in directories and symlinks which I don't know how to get rid of, but there's some changes in etc/conf.d/systemd.conf that I have attached. Not sure whether those are problematic? Michael │ ├── etc/conf.d/systemd.conf │ │ @@ -1,3 +1,3 @@ │ │ -systemdutildir="/lib/systemd" │ │ -systemdsystemunitdir="/lib/systemd/system" │ │ +systemdutildir="/usr/lib/systemd" │ │ +systemdsystemunitdir="/usr/lib/systemd/system" │ │ systemdsystemconfdir="/etc/systemd/system" │ ├── usr/lib/systemd/system/ctrl-alt-del.target │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../lib/systemd/system/reboot.target │ │ +destination: reboot.target │ ├── usr/lib/systemd/system/sockets.target.wants/systemd-journald-audit.socket │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sockets.target.wants/../systemd-journald-audit.socket │ │ +destination: ../systemd-journald-audit.socket │ ├── usr/lib/systemd/system/sockets.target.wants/systemd-journald-dev-log.socket │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sockets.target.wants/../systemd-journald-dev-log.socket │ │ +destination: ../systemd-journald-dev-log.socket │ ├── usr/lib/systemd/system/sockets.target.wants/systemd-journald.socket │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sockets.target.wants/../systemd-journald.socket │ │ +destination: ../systemd-journald.socket │ ├── usr/lib/systemd/system/sockets.target.wants/systemd-udevd-control.socket │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sockets.target.wants/../systemd-udevd-control.socket │ │ +destination: ../systemd-udevd-control.socket │ ├── usr/lib/systemd/system/sockets.target.wants/systemd-udevd-kernel.socket │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sockets.target.wants/../systemd-udevd-kernel.socket │ │ +destination: ../systemd-udevd-kernel.socket │ ├── usr/lib/systemd/system/sysinit.target.wants/kmod-static-nodes.service │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sysinit.target.wants/../kmod-static-nodes.service │ │ +destination: ../kmod-static-nodes.service │ ├── usr/lib/systemd/system/sysinit.target.wants/systemd-ask-password-console.path │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sysinit.target.wants/../systemd-ask-password-console.path │ │ +destination: ../systemd-ask-password-console.path │ ├── usr/lib/systemd/system/sysinit.target.wants/systemd-journald.service │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sysinit.target.wants/../systemd-journald.service │ │ +destination: ../systemd-journald.service │ ├── usr/lib/systemd/system/sysinit.target.wants/systemd-modules-load.service │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sysinit.target.wants/../systemd-modules-load.service │ │ +destination: ../systemd-modules-load.service │ ├── usr/lib/systemd/system/sysinit.target.wants/systemd-sysctl.service │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sysinit.target.wants/../systemd-sysctl.service │ │ +destination: ../systemd-sysctl.service │ ├── usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup-dev.service │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sysinit.target.wants/../systemd-tmpfiles-setup-dev.service │ │ +destination: ../systemd-tmpfiles-setup-dev.service │ ├── usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sysinit.target.wants/../systemd-tmpfiles-setup.service │ │ +destination: ../systemd-tmpfiles-setup.service │ ├── usr/lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sysinit.target.wants/../systemd-udev-trigger.service │ │ +destination: ../systemd-udev-trigger.service │ ├── usr/lib/systemd/system/sysinit.target.wants/systemd-udevd.service │ │┄ symlink │ │ @@ -1 +1 @@ │ │ -destination: ../../../../../lib/systemd/system/sysinit.target.wants/../systemd-udevd.service │ │ +destination: ../systemd-udevd.service
Bug#991920: please demote pkg-config to Recommends
Package: dracut-core Version: 051-1 Severity: wishlist Dear Maintainer, dracut may be used in minimal systems. If that is the case, dracut-core drags in perl via pkg-config. However, it seems pkg-config is an optional part of dracut (and is indeed not shipped as a dependency for the RPM package if I read the upstream spec file correctly) and there is fall-back support if pkg-config is not installed. So it would be nice to demote pkg-config to Recommends in order to support minimal systems that don't ship perl by default. Michael -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dracut-core depends on: ii cpio2.12+dfsg-9 ii e2fsprogs 1.44.5-1+deb10u3 ii kmod26-1 ii kpartx 0.7.9-3+deb10u1 ii libc6 2.28-10 ii libkmod226-1 ii pkg-config 0.29-6 ii udev241-7~deb10u8 ii util-linux 2.33.1-0.1 Versions of packages dracut-core recommends: ii binutils 2.31.1-16 ii console-setup 1.193~deb10u1 ii cryptsetup 2:2.1.0-5+deb10u2 pn dmraid ii dmsetup2:1.02.155-3 ii lvm2 2.03.02-3 pn mdadm ii systemd241-7~deb10u8 dracut-core suggests no packages.
Bug#990119: vip-manager: systemd service file uses incorrect parameter syntax
Hi, Am Montag, den 21.06.2021, 11:12 +0200 schrieb Chris Hofstaedtler: > Package: vip-manager > Version: 1.0.1-3+b2 > Severity: serious > > Dear Maintainer, > > thanks for maintaining the vip-manager package. > > I've noticed that the service file > /lib/systemd/system/vip-manager.service uses options with one dash > (ex: `-ip=a.b.c.d`), but the vip-manager binary expects two dashes > (`--ip=a.b.c.d`). > > I believe old vip-manager versions used one dash, but apparently > this has changed, and the Debian patch "service_file.patch" needs to > be updated. You're right. I only tested the Debian-integrated version of vip-manager where one uses the templated service unit that's corresponding to the Patroni service/Debian PostgreSQL cluster (e.g. vip-manager@13-main) and not the general one. > Setting severity serious, because the default service file appears > broken. I've pushed a fix now according to your other mail. I first thought of harmonizing the two service units some more (and just use environment variables), but then decided to go for the minimal fix for bullseye. I'll try to overhaul this for bookworm. I also uploaded a new package candidate to https://people.debian.org/~mbanck/.tmp/vip-manager_1.0.1-4_amd64.deb if you want to test it. Or just build it yourself from the salsa repo. Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 E-Mail: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Sascha Heuer, Geoff Richardson, Peter Lilley Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Bug#987963: [Debichem-devel] Bug#987963: pymol: flaky autopkgtest on arm64: hits autopkgtest timeout
Hi, On Sun, May 02, 2021 at 09:17:26PM +0200, Paul Gevers wrote: > Run 'pymol -c > /tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/scenes2movie.pml'... > :1: DeprecationWarning: the imp module is deprecated in favour > of importlib; see the module's documentation for alternative uses > autopkgtest [04:22:04]: ERROR: timed out on command "su -s /bin/bash Ok, so on closer look (and after inspecting the other ci.d.b failures), it seems it always hangs on the above scenes2movie.pml script. I'm not sure why, and I can't reproduce it on amdahl (at least not during half a dozen runs), but as we skip about a dozen scripts so far already, I suggest to just add this one to it. Michael
Bug#987963: [Debichem-devel] Bug#987963: pymol: flaky autopkgtest on arm64: hits autopkgtest timeout
Hi Paul, On Sun, May 02, 2021 at 09:17:26PM +0200, Paul Gevers wrote: > Source: pymol > Version: 2.4.0+dfsg-1 > Severity: serious > Tags: sid bullseye > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > Your package has an autopkgtest, great. However, because of the failure > "caused" by glbic, Can you elaborate what you mean by that, is that related to pymol? Or are you saying that due to glbic (glibc?) failures, you had to look at all flaky tests and pymol was one of them? > I looked into the history of your autopkgtest [1] and I noticed it > fails regularly on arm64 because it hits the autopkgtest timeout after > 2:47 hours. > > 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. Well I'm going to try to take a look, but this apparently being arm64-specific won't make it easier. Michael
Bug#983864: RM: abinit [mips64el mipsel] -- RoQA; no longer builds on mips*
Hi ftp-master, as abinit's maintainer/upload, ping on this, I think this blocks abinit from migrating to bullseye. Thanks, Michael
Bug#985269: [Debichem-devel] Bug#985269: libint1: ships broken library symlinks: /usr/lib/lib*-stable.so.1 -> lib*.so.1
Hi,
On Mon, Mar 15, 2021 at 10:40:09AM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
Thanks for the report.
> From the attached log (scroll to the bottom...):
>
> libint1: MISSING OBJECT /usr/lib/libderiv-stable.so.1
> libint1: MISSING OBJECT /usr/lib/libint-stable.so.1
> libint1: MISSING OBJECT /usr/lib/libr12-stable.so.1
Those are legacy symlinks. I am not sure they are still needed, but
probably now isn't the time to remove them either.
> The dangling symlinks get "cleaned up" by ldconfig.
>
> The package ships the following libraries and symlinks:
>
> -rw-r--r-- root/root 20421064 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libderiv.so.1.0.0
> -rw-r--r-- root/root 9215552 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libint.so.1.0.0
> -rw-r--r-- root/root 9816208 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libr12.so.1.0.0
> lrwxrwxrwx root/root 0 2021-03-04 15:25
> ./usr/lib/libderiv-stable.so.1 -> libderiv.so.1
> lrwxrwxrwx root/root 0 2021-03-04 15:25 ./usr/lib/libint-stable.so.1
> -> libint.so.1
> lrwxrwxrwx root/root 0 2021-03-04 15:25 ./usr/lib/libr12-stable.so.1
> -> libr12.so.1
> lrwxrwxrwx root/root 0 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libderiv.so.1 -> libderiv.so.1.0.0
> lrwxrwxrwx root/root 0 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libint.so.1 -> libint.so.1.0.0
> lrwxrwxrwx root/root 0 2021-03-04 15:25
> ./usr/lib/x86_64-linux-gnu/libr12.so.1 -> libr12.so.1.0.0
>
> Do you need to move the lib*-stable.so.1 symlinks to
> /usr/lib/${DEB_HOST_MULTIARCH} ?
I guess dh_link can't cope with multiarch, so we will have to to the
symlinking in an install override, will look into it.
Michael
Bug#985067: unblock: libint/1.2.1-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libint
This appears to be required because libint does not have autopkgtests, and will
make libint and psi4 transition.
unblock libint/1.2.1-5
-- System Information:
Debian Release: 10.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 32539f9..494cc22 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,37 @@
+libint (1.2.1-5) unstable; urgency=medium
+
+ * Team upload
+ * Add Breaks on psi4 (<< 1:1.3.2+dfsg-1)
+
+ -- Graham Inggs Thu, 04 Mar 2021 14:25:43 +
+
+libint (1.2.1-4) unstable; urgency=medium
+
+ * debian/rules (override_dh_auto_configure): Increase angular momentum
+configure options by one.
+
+ -- Michael Banck Sun, 17 Jan 2021 18:50:04 +0100
+
+libint (1.2.1-3) unstable; urgency=medium
+
+ * debian/rules (override_dh_auto_configure): Set cmake's MAX_AM_ERI variable
+to 5 to be more in-line with the autotools build.
+ * debian/rules (override_dh_auto_configure): Add ENABLE_XHOST=OFF to cmake
+variables.
+ * debian/rules (override_dh_auto_install): Skip installing the cmake build.
+ * debian/libint-dev.install: Install the cmake files directly out of the
+build directory.
+ * debian/rules (override_dh_auto_configure): Add --with-pic to configure
+arguments.
+ * debian/control (Standards-Version): Bumped to 4.5.1.
+ * debian/compat: Bump to 11.
+ * debian/rules (override_dh_auto_install,override_dh_install): Targets
+removed.
+ * debian/libint1.install,debian/libint-dev.install: Update for multiarch
+libdir.
+
+ -- Michael Banck Sat, 16 Jan 2021 19:50:14 +0100
+
libint (1.2.1-2) unstable; urgency=medium
* debian/libint1.links: Reintroduce lib*-stable.so.1 as symlinks (Closes:
diff --git a/debian/compat b/debian/compat
index 45a4fb7..b4de394 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-8
+11
diff --git a/debian/control b/debian/control
index 5a6bc33..ad2769a 100644
--- a/debian/control
+++ b/debian/control
@@ -11,15 +11,16 @@ Build-Depends: autotools-dev (>> 20100122.1~),
texlive-base-bin,
texlive-font-utils,
texlive-latex-base
-Standards-Version: 3.9.4
+Standards-Version: 4.5.1
Homepage: http://sourceforge.net/p/libint/home/
-Vcs-Browser: http://anonscm.debian.org/viewvc/debichem/unstable/libint/
-Vcs-Svn: svn://anonscm.debian.org/debichem/unstable/libint/
+Vcs-Browser: https://salsa.debian.org/debichem-team/libint
+Vcs-Git: https://salsa.debian.org/debichem-team/libint.git
Package: libint1
Section: libs
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: psi4 (<< 1:1.3.2+dfsg-1)
Description: Evaluate the integrals in modern atomic and molecular theory
The LIBINT library is used to evaluate the traditional (electron repulsion)
and certain novel two-body matrix elements (integrals) over Cartesian
diff --git a/debian/libint-dev.install b/debian/libint-dev.install
index 103f8eb..42c016b 100644
--- a/debian/libint-dev.install
+++ b/debian/libint-dev.install
@@ -1,4 +1,5 @@
usr/include/*
-usr/lib/lib*.a
-usr/lib/lib*.so
-usr/share/cmake
+usr/lib/*/lib*.a
+usr/lib/*/lib*.so
+obj-*/stage/usr/share/cmake/Libint /usr/share/cmake
+obj-*/LibintConfig*cmake /usr/share/cmake/Libint
diff --git a/debian/libint1.install b/debian/libint1.install
index d0dbfd1..3ddde58 100644
--- a/debian/libint1.install
+++ b/debian/libint1.install
@@ -1 +1 @@
-usr/lib/lib*.so.*
+usr/lib/*/lib*.so.*
diff --git a/debian/rules b/debian/rules
index 0c58153..71bd4ef 100755
--- a/debian/rules
+++ b/debian/rules
@@ -30,29 +30,24 @@ override_dh_auto_configure:
--enable-deriv \
--enable-r12 \
--enable-debug=opt \
- --with-libint-max-am=5 \
- --with-libderiv-max-am1=4 \
- --with-libderiv-max-am2=3 \
+ --with-libint-max-am=6 \
+ --with-libderiv-max-am1=5 \
+ --with-libderiv-max-am2=4 \
--prefix=/usr \
--with-cc-optflags="$(CFLAGS) $(CPPFLAGS)" \
--with-cxx-optflags="$(CXXFLAGS) $(CPPFLAGS)" \
- --with-libdirs="$(LDFLAGS)"
+ --with-libdirs="$(LDFLAGS)" \
+ --with-pic
dh_auto_configure --buildsystem=cmake --\
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_INSTALL_LIBDIR=lib \
-
Bug#983246: RM: quantum-espresso [armel] -- ROM; out-of-date package; current package not able to pass QA
Package: ftp.debian.org Severity: normal Hi, please remove the outdated armel binary for quantum-espresso; this version only built because the testsuite failed to run properly; the current version aborts during the testsuite. Thanks, Michael
Bug#983040: [Debichem-devel] Bug#983040: rdkit: doesn't ship with inchi support enabled
tags 983040 +wontfix merge 983040 964773 thanks On Thu, Feb 18, 2021 at 03:35:21PM +0200, Andrius Merkys wrote: > On 2021-02-18 15:27, Michael Banck wrote: > > On Thu, Feb 18, 2021 at 02:48:49PM +0900, Francois Berenger wrote: > >> --- > >> python3 > >> import rdkit > >> from rdkit import Chem > >> rdkit.Chem.INCHI_AVAILABLE > >> # False > >> --- > >> > >> It would be nice if INCHI support is enabled > >> when building rdkit for Debian. > >> > >> If you point me to the bugtracker where I should report > >> this (not found after 10min of searching...), I might report it there. > > This has already been reported as [#964773]. In short, rdkit cannot be > built with INCHI support in Debian due to DFSG reasons (please see the > original bug report for explanation). > > [#964773] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964773 Thanks Andrius for the pointer. By the way, I've looked at the INCHI licenes again, and clause 3 allows to use the INCHI code under the GPL, was it considered to just go that route in Debian or is there some other loophole I don't see? Maybe RDKit could be changed in some way to build against both INCHI versions, but if that is possible at all, it sounds like a major project. Francois, what might help here is opening an issue with RDKit's GitHub issue tracker and asking them about supporting both versions. Michael
Bug#983040: rdkit: doesn't ship with inchi support enabled
Package: rdkit Severity: wishlist Hi Francois, On Thu, Feb 18, 2021 at 02:48:49PM +0900, Francois Berenger wrote: > --- > python3 > import rdkit > from rdkit import Chem > rdkit.Chem.INCHI_AVAILABLE > # False > --- > > It would be nice if INCHI support is enabled > when building rdkit for Debian. > > If you point me to the bugtracker where I should report > this (not found after 10min of searching...), I might report it there. What you can do is email sub...@bugs.debian.org (in BCC on this mail) and use the above pseudo-headers, or use the reportbug tool available in Debian. > inchi is a pretty standard and common format for people dealing with > chemical data. Thanks, I'll look into it. However, the next Debian release is feature-frozen already so not clear whether it will/can make it in. Michael
Bug#980854: [Debichem-devel] Bug#980854: gabedit: Wrong homepage
Hi, On Sat, Jan 23, 2021 at 09:36:23AM +0100, Davide Prina wrote: > Package: gabedit > Version: 2.5.1~20200828-1 > Severity: normal > > I have see that the project homepage do not respond anymore: > https://gabedit.sourceforge.net/ Thanks for the report! > I think that the homepage is now: > http://gabedit.sourceforge.net/ > > note the working page is HTTP and not HTTPS That's weird. Anyway, seeing how the download links go to google sites anyway, I suggest er rather use https://sites.google.com/site/allouchear/Home/gabedit as homepage. Michael
Bug#979983: [Debichem-devel] Bug#979983: qcelemental downloads from the internet during the build
Hi,
On Tue, Jan 12, 2021 at 05:31:51PM +0200, Adrian Bunk wrote:
> matchobj =
>
> def process_pubchem(matchobj):
> pubsearch = matchobj.group("pubsearch")
>
> # search pubchem for the provided string
> try:
> results = pubchem.get_pubchem_results(pubsearch)
> except Exception as e:
> > raise ValidationError(e.message)
> E qcelemental.exceptions.ValidationError: Input Error:
> PubchemError
> E
> E received when trying to open
> E
> https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/cid/223/property/IUPACName,MolecularFormula,Charge/JSON
> E Check your internet connection, and the above URL, and try
> again.
>
> qcelemental/molparse/from_string.py:309: ValidationError
I noticed, and I mentioned it in
https://github.com/MolSSI/QCElemental/issues/83#issuecomment-757475240
but no reply from upstream so far.
Michael
Bug#979339: APBS tools in the packages
fixed 979339 1.5+dfsg1-1 thanks On Fri, Jan 08, 2021 at 12:09:06PM +, Athanasios Anastasiou wrote: > Having compiled the tools, they are binaries and therefore probably better > to be included in apbs. I had a look a this now, and it turns out that we are already shipping them in the apbs package, starting from version 1.5 on. Michael
Bug#979708: devscripts: origtargz should print some status message before running pristine-tar
Package: devscripts Version: 2.19.5+deb10u1 Severity: wishlist Running pristine-tar can take a while, especially if xz part. During this, origtargz just sits there with no output and the user might wonder what's going on. So adding something like 'print "Trying pristine-tar\n";' before running pristine-tar checkout would be nice, as other methods do yield output as well. -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- DEBFULLNAME="Michael Banck" DEBEMAIL="mba...@debian.org" DEBSIGN_KEYID=B43481B0 -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages devscripts depends on: ii dpkg-dev 1.19.7 ii fakeroot 1.23-1 ii file 1:5.35-4+deb10u1 ii gnupg 2.2.12-1+deb10u1 ii gnupg22.2.12-1+deb10u1 ii gpgv 2.2.12-1+deb10u1 ii libc6 2.28-10 ii libfile-homedir-perl 1.004-1 ii libfile-which-perl1.23-1 ii libipc-run-perl 20180523.0-1 ii libmoo-perl 2.003004-2 ii libwww-perl 6.36-2 ii patchutils0.3.4-2 ii perl 5.28.1-6+deb10u1 ii python3 3.7.3-1 ii sensible-utils0.0.12 ii wdiff 1.2.2-2+b1 Versions of packages devscripts recommends: ii apt 1.8.2.2 ii at 3.1.23-1 ii curl7.64.0-4+deb10u1 ii dctrl-tools 2.24-3 pn debian-keyring ii dput1.0.3 pn equivs ii libdistro-info-perl 0.21 ii libdpkg-perl1.19.7 ii libencode-locale-perl 1.05-1 pn libgit-wrapper-perl pn libgitlab-api-v4-perl pn liblist-compare-perl ii liblwp-protocol-https-perl 6.07-2 pn libsoap-lite-perl pn libstring-shellquote-perl ii libtry-tiny-perl0.30-1 ii liburi-perl 1.76-1 pn licensecheck ii lintian 2.15.0 ii man-db 2.8.5-2 ii patch 2.7.6-3+deb10u1 ii python3-apt 1.8.4.3 ii python3-debian 0.1.35 pn python3-magic ii python3-requests2.21.0-1 pn python3-unidiff ii python3-xdg 0.25-5 ii strace 4.26-0.2 ii unzip 6.0-23+deb10u1 ii wget1.20.1-1.1 ii xz-utils5.2.4-1 Versions of packages devscripts suggests: pn adequate ii autopkgtest 5.10 pn bls-standalone ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 ii build-essential 12.6 pn check-all-the-things pn cvs-buildpackage ii debhelper 12.1.1 pn devscripts-el pn diffoscope pn disorderfs pn dose-extra pn duck pn faketime ii gnuplot 5.2.6+dfsg1-1+deb10u1 ii gnuplot-x11 [gnuplot] 5.2.6+dfsg1-1+deb10u1 pn how-can-i-help ii libauthen-sasl-perl 2.1600-1 pn libdbd-pg-perl ii libfile-desktopentry-perl 0.22-1 pn libnet-smtps-perl pn libterm-size-perl ii libtimedate-perl 2.3000-2+deb10u1 pn libyaml-syck-perl ii mailutils [mailx] 1:3.5-4 pn mozilla-devscripts ii mutt 1.10.1-2.1+deb10u4 ii openssh-client [ssh-client] 1:7.9p1-10+deb10u2 pn piuparts ii postgresql-client-11 [postgresql-client] 11.9-0+deb10u1 ii quilt 0.65-3 pn ratt pn reprotest pn svn-buildpackage ii w3m 0.5.3-37 -- no debconf information
Bug#979339: APBS tools in the packages
On Tue, Jan 05, 2021 at 03:02:02PM +, Athanasios Anastasiou wrote: > Thank you very much for the quick response, I think it would be useful to > include them with apbs more generally. Perhaps even as apbs-tools (?). We'll see; one problem is that the freeze for the next Debian release is pretty soon and we won't have time to get another binary package approved, so maybe it makes more sense to ship them in the apbs or apbs-data (depending on whether those are binary executables or scripts) packages, but maybe in a non-default path. I think /usr/share/apbs/tools/ is used by apbs-data already and we could use /usr/lib/apbs/tools accordingly. Michael
Bug#979339: APBS tools in the packages
Package: apbs Version: 1.4.2.1-1 Severity: wishlist Hi Athanasios, On Tue, Jan 05, 2021 at 02:50:15PM +, Athanasios Anastasiou wrote: > I am looking at APBS' documentation at: > https://apbs.readthedocs.io/en/latest/using/tools.html?highlight=similarity > > And I can see a number of tools, with similarity being the one I am trying > to track down. > > Do you know if there is any auxiliary package that would include these > tools? > > I am trying apt-cache search but it does not return any useful results for > the alternatives. It seems we just haven't included them in the package yet. I've CC'd sub...@bugs.debian.org which should open a bug report about this so we don't forget. Cheers, Michael
Bug#979041: closed by Debian FTP Masters (reply to Alastair McKinstry ) (Bug#979041: fixed in openmpi 4.1.0-4)
reopen 979041 thanks Hi, On Mon, Jan 04, 2021 at 09:36:06AM +, Debian Bug Tracking System wrote: >* Fix for missing plugin mca_op_avx.so. Closes: #979041, #978496 This change fixes the mca_op_avx.so issues, but at least my testing shows this abort is still there when trying to run the gpaw autopkgtests with 4.1.0-4: > |A process has executed an operation involving a call > |to the fork() system call to create a child process. > | > |As a result, the libfabric EFA provider is operating in > |a condition that could result in memory corruption or > |other system errors. > | > |For the libfabric EFA provider to work safely when fork() > |is called, you will need to set the following environment > |variable: > | RDMAV_FORK_SAFE > | > |However, setting this environment variable can result in > |signficant performance impact to your application due to > |increased cost of memory registration. > | > |You may want to check with your application vendor to see > |if an application-level alternative (of not using fork) > |exists. > | > |Your job will now abort. Michael
Bug#979071: ITP: neci -- Full Configuration Interaction Quantum Monte Carlo Code
Package: wnpp Severity: wishlist Owner: Michael Banck * Package name: neci Version : git snapshot Upstream Author : George H. Booth and Ali Alavi * URL : https://github.com/ghb24/NECI_STABLE * License : GPLv3 Programming Lang: Fortran90 Description : Full Configuration Interaction Quantum Monte Carlo Code The N-Electron Configuration Interaction (NECI) code base implements FCIQMC (Full Configuration Interaction Quantum Monte Carlo), a method based on a stochastic application of the Hamiltonian matrix on a sparse sampling of the wave function. It can be interfaced to both OpenMolcas and pySCF in order to implement stochastic CASSCF (complete active space SCF).
Bug#979041: libopempi3: aborts python code due to libfabric fork() issues
Package: libopenmpi3 Version: 4.1.0-3 Severity: serious The revert of pmix has fixed some issues, but python packages still show autopkgtest regressions in dolfin[1], gpaw[2], gyoto[3] and mshr[4] . The error is always like this: |A process has executed an operation involving a call |to the fork() system call to create a child process. | |As a result, the libfabric EFA provider is operating in |a condition that could result in memory corruption or |other system errors. | |For the libfabric EFA provider to work safely when fork() |is called, you will need to set the following environment |variable: | RDMAV_FORK_SAFE | |However, setting this environment variable can result in |signficant performance impact to your application due to |increased cost of memory registration. | |You may want to check with your application vendor to see |if an application-level alternative (of not using fork) |exists. | |Your job will now abort. If I export RDMAV_FORK_SAFE=1, the tests run fine, but (i) it seems something in OpenMPI has changed so that those programs no longer run and (ii) the warnings about performance issues are to be considered. Also note that it seems those errors only happen on amd64/i386, the ARM ports run fine, maybe because of missing libfabric-related features/packages? Michael [1] https://ci.debian.net/data/autopkgtest/testing/amd64/d/dolfin/9184050/log.gz [2] https://ci.debian.net/data/autopkgtest/testing/amd64/g/gpaw/9302177/log.gz [3] https://ci.debian.net/data/autopkgtest/testing/amd64/g/gyoto/9303088/log.gz [4] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mshr/9300183/log.gz
Bug#977230: bagel FTBFS with Boost 1.74
reassign 977230 libboost-serialization1.74-dev thanks On Fri, Jan 01, 2021 at 06:58:24PM +0200, Adrian Bunk wrote: > On Fri, Jan 01, 2021 at 01:07:25PM +0100, Michael Banck wrote: > > I tried to look at it, but it's unclear to me where BAGEL is being at > > fault, it seems to just include boost headers and then there's error in > > one of them? Should it do something different? > > This might be a bug in boost? > https://github.com/boostorg/property_tree/pull/62 Oh thanks - I didn't find much when searching. I'm reassigning it to boost then for now. Michael
Bug#977230: bagel FTBFS with Boost 1.74
Hi, On Sat, Dec 12, 2020 at 09:45:10PM +0200, Adrian Bunk wrote: > Source: bagel > Version: 1.2.2-1 > Severity: serious > Tags: ftbfs bullseye sid > > https://buildd.debian.org/status/fetch.php?pkg=bagel=amd64=1.2.2-1%2Bb2=1607773477=0 > > ... > /usr/include/boost/property_tree/ptree_serialization.hpp: In function ‘void > boost::property_tree::detail::load_children(Archive&, > boost::property_tree::basic_ptree&)’: > /usr/include/boost/property_tree/ptree_serialization.hpp:66:24: error: > ‘library_version_type’ in namespace ‘bsa’ does not name a type >66 | const bsa::library_version_type library_version( > |^~~~ > ... I tried to look at it, but it's unclear to me where BAGEL is being at fault, it seems to just include boost headers and then there's error in one of them? Should it do something different? |In file included from ../../../src/util/serialization.h:46, | from ../../../src/util/input/input.h:31, | from input.cc:27: |/usr/include/boost/property_tree/ptree_serialization.hpp: In function |‘void boost::property_tree::detail::load_children(Archive&, |boost::property_tree::basic_ptree&)’: |/usr/include/boost/property_tree/ptree_serialization.hpp:66:24: error: |‘library_version_type’ in namespace ‘bsa’ does not name a type | 66 | Michael
Bug#978022: libopenmpi3 Runtime failure opal_pmix_base_select failed
Package: libopenmpi3 Version: 3.1.3-11 Severity: serious Even with the fixed libpmix2_4.0.0~rc1-2, I am getting runtime failures trying to run MPI programs, e.g. the nwchem autopkgtests all fail like this: | Running tests/water/water_md | | cleaning scratch | copying input and verified output files | running nwchem (/usr/bin/nwchem) with 1 processors | | NWChem execution failed |[kohn:13218] [[5127,0],0] ORTE_ERROR_LOG: Not found in file ../../../../../../orte/mca/ess/hnp/ess_hnp_module.c at line 320 |-- |It looks like orte_init failed for some reason; your parallel process is |likely to abort. There are many reasons that a parallel process can |fail during orte_init; some of which are due to configuration or |environment problems. This failure appears to be an internal failure; |here's some additional information (which may only be relevant to an |Open MPI developer): | | opal_pmix_base_select failed | --> Returned value Not found (-13) instead of ORTE_SUCCESS |-- Not sure whether this is libopenmpi3, openmpi-bin, libpmix2 or something else, so please reassign as needed. But at least the openmpi excuses is full of ci.debian.net regressions: https://qa.debian.org/excuses.php?package=openmpi Or is there something needed on the application side, like a new environment variable or library to be linked in? Michael
Bug#977873: libpmix2: broken library symlink
Package: libpmix2
Version: 4.0.0~rc1-1
Severity: serious
It seems the 4.0.0 upload did not update the convenience
/usr/lib//libpmix.so.* symlink, it is pointing nowehere
in the data.tar.gz (and dpkg seems to refuse to unpack/create it, cause
I don't have it in my unstable chroot):
(unstable-amd64-sbuild)root@kohn:/tmp# ar x libpmix2_4.0.0~rc1-1_amd64.deb
(unstable-amd64-sbuild)root@kohn:/tmp# ls -l
usr/lib/x86_64-linux-gnu/{,pmix2/lib}/
usr/lib/x86_64-linux-gnu//:
total 4
lrwxrwxrwx 1 root root 39 Dec 21 08:01 libmca_common_dstore.so.1 ->
pmix2/lib/libmca_common_dstore.so.1.0.2
lrwxrwxrwx 1 root root 39 Dec 21 08:01 libmca_common_dstore.so.1.0.2 ->
pmix2/lib/libmca_common_dstore.so.1.0.2
lrwxrwxrwx 1 root root 27 Dec 21 08:01 libpmix.so.2 ->
pmix2/lib/libpmix.so.2.2.32
lrwxrwxrwx 1 root root 27 Dec 21 08:01 libpmix.so.2.2.2.32 ->
pmix2/lib/libpmix.so.2.2.32
drwxr-xr-x 4 root root 4096 Dec 21 08:01 pmix2
usr/lib/x86_64-linux-gnu/pmix2/lib/:
total 1368
lrwxrwxrwx 1 root root 29 Dec 21 08:01 libmca_common_dstore.so ->
libmca_common_dstore.so.1.0.3
lrwxrwxrwx 1 root root 29 Dec 21 08:01 libmca_common_dstore.so.1 ->
libmca_common_dstore.so.1.0.3
-rw-r--r-- 1 root root 60024 Dec 21 08:01 libmca_common_dstore.so.1.0.3
lrwxrwxrwx 1 root root 16 Dec 21 08:01 libpmix.so -> libpmix.so.2.3.0
lrwxrwxrwx 1 root root 16 Dec 21 08:01 libpmix.so.2 -> libpmix.so.2.3.0
-rw-r--r-- 1 root root 1334704 Dec 21 08:01 libpmix.so.2.3.0
drwxr-xr-x 2 root root4096 Dec 21 08:01 pmix
(unstable-amd64-sbuild)root@kohn:/tmp# ls -l
usr/lib/x86_64-linux-gnu/pmix2/lib/libpmix.so.2.2.32
ls: cannot access 'usr/lib/x86_64-linux-gnu/pmix2/lib/libpmix.so.2.2.32': No
such file or directory
(unstable-amd64-sbuild)root@kohn:/tmp# dpkg -l libpmix2 | tail -1
ii libpmix2:amd64 4.0.0~rc1-1 amd64Process Management Interface
(Exascale) library
(unstable-amd64-sbuild)root@kohn:/tmp# dpkg -L libpmix2 | grep
gnu.libpmix.so.2$
/usr/lib/x86_64-linux-gnu/libpmix.so.2
(unstable-amd64-sbuild)root@kohn:/tmp# ls -l
/usr/lib/x86_64-linux-gnu/libpmix.so.2
ls: cannot access '/usr/lib/x86_64-linux-gnu/libpmix.so.2': No such file or
directory
Michael
Bug#975219: [Debichem-devel] Bug#975219: elkcode: FTBFS: internal compiler error: in lookup_field_for_decl, at tree-nested.c:288
Hi Lucas, That looks like an ICE, shouldn't that be filed with gfortran? On Thu, Nov 19, 2020 at 10:52:05AM +0100, Lucas Nussbaum wrote: > > mpif90 `dpkg-buildflags --get FFLAGS` `dpkg-buildflags --get CPPFLAGS` > > -Wall -ffast-math -funroll-loops -fopenmp -fallow-argument-mismatch > > `dpkg-buildflags --get LDFLAGS` -c exxengy.f90 > > exxengy.f90:6:18: > > > > 6 | subroutine exxengy > > | ^ > > internal compiler error: in lookup_field_for_decl, at tree-nested.c:288 > > 0x71106d lookup_field_for_decl > > ../../src/gcc/tree-nested.c:288 > > 0x111523e convert_local_reference_stmt > > ../../src/gcc/tree-nested.c:2408 [...] > > Please submit a full bug report, > > with preprocessed source if appropriate. > > Please include the complete backtrace with any bug report. > > See for instructions. > > make[3]: *** [Makefile:194: exxengy.o] Error 1 Michael
Bug#973027: [Debichem-devel] Bug#973027: rdkit: FTBFS in unstable with postgresql 13
Hi, On Fri, Oct 30, 2020 at 08:39:00AM +0200, Andrius Merkys wrote: > Hi Michael, > > On 2020-10-29 22:10, Michael Banck wrote: > > Andrius, are you going to upload rdkit again? BTW, the changelog in > > salsa still has UNRELEASED as distribution, are you going to update this > > once the upload went through? Further, the bug isn't being closed in the > > changelog. > > I tried uploading again, but got rejected with the following message: > > librdkit-dev_202003.4-3_amd64.deb: trying to install to new, but could > not find source (rdkit 202003.4-3) > > binary:postgresql-13-rdkit is NEW. Sounds like this time you only uploaded .debs and not the .dsc/.debian.tar.xz, it wants both. The mergechanges tool (from devscripts I think) might be of help here. > I do not know how to deal with it, could you please help? I have now > pushed the commit releasing 202003.4-3 and closing this bug, so you may > alternatively do the upload. OK, I'll take a look. Michael
Bug#973027: [Debichem-devel] Bug#973027: rdkit: FTBFS in unstable with postgresql 13
Hi Steve, On Thu, Oct 29, 2020 at 12:56:26PM -0700, Steve Langasek wrote: > Package: rdkit > Version: 202003.4-2 > Followup-For: Bug #973027 > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu hirsute ubuntu-patch > > This bug has been tagged patch, and there is a PR linked from the upstream > bug report, but no patch is attached to the bug. The attached patch is what > I have uploaded to Ubuntu to resolve this build failure. Andrius has committed a similar patch to salsa two days ago: https://salsa.debian.org/debichem-team/rdkit/-/commit/5994e329e094cf12c5b6be0a44b079e52f984843 However, his source-only upload was rejected due to the new pg13 binary package. Andrius, are you going to upload rdkit again? BTW, the changelog in salsa still has UNRELEASED as distribution, are you going to update this once the upload went through? Further, the bug isn't being closed in the changelog. Alternatively, we could revert those commits and sync from Ubuntu, I'm leaving this to Andrius. Michael
Bug#968283: Removal of packges which depend on GTK2
Hi Sean, On Sat, Oct 10, 2020 at 09:11:23AM -0700, Sean Whitton wrote: > Hello GNOME team, I think #968283 is the wrong bug, cause I don't think jack has anything to do with gtk2, does it? Michael
Bug#971918: pydantic ftbfs with python3-defaults (python3.9) from experimental
Hi, On Sat, Oct 10, 2020 at 02:12:38PM +0200, Matthias Klose wrote: > On 10/10/20 12:23 PM, Michael Banck wrote: > > Hi, > > > > On Fri, Oct 09, 2020 at 08:18:23PM +0200, Matthias Klose wrote: > >> Package: src:pydantic > >> Version: 1.2-1 > >> Severity: important > >> Tags: sid bullseye > >> User: debian-pyt...@lists.debian.org > >> Usertags: python3.9 > >> > >> [...] > > > > Can you share an sbuild command-line in order to reproduce this? > > sorry, I don't know what you mean I meant a way to reproduce this build failure in an unstable schroot with sbuild (or pbuilder, though I don't use that). That'd make it easier for the package maintainers to reproduce the failure and/or test a fix. Seems this works (as in, I'm seeing the failure now): sbuild -d unstable -A --extra-repository="deb http://deb.debian.org/debian experimental main" --build-dep-resolver=aspcud --add-depends='python3-all-dev (>= 3.8.5-1)' About the bug, there's a PR that fixes it[1], but unfortuntely, it really only applies to 1.6/1.6.1, and I'm seeing other regression test failures there[2]. Might take another look at back-patching the PR in case the other failures can't be figured out soon. Michael [1] https://github.com/samuelcolvin/pydantic/pull/1844 [2] https://github.com/samuelcolvin/pydantic/issues/1580
Bug#971918: pydantic ftbfs with python3-defaults (python3.9) from experimental
Hi, On Fri, Oct 09, 2020 at 08:18:23PM +0200, Matthias Klose wrote: > Package: src:pydantic > Version: 1.2-1 > Severity: important > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: python3.9 > > [...] Can you share an sbuild command-line in order to reproduce this? Michael
Bug#969311: UDD: please install pg_stat_statements extension
owner 969311 mba...@debian.org thanks On Mon, Aug 31, 2020 at 10:02:52AM +0200, Michael Banck wrote: > In order to best assess where and how to improve the situation, please > install the pg_stat_statements extension in the udd database, like > > CREATE EXTENSION pg_stat_statements; Gah, I forgot that pg_stat_statements requires a preloaded library. So before the above can work, postgresql.conf needs to be changed: -#shared_preload_libraries = '' # (change requires restart) +shared_preload_libraries = 'pg_stat_statements' # (change requires restart) As indicated, this will only take effect after the next server restart, then the extension can be created. pg_stat_statements is part of the core set of Postgres extensions and does not need to be installed via packages. Michael
Bug#969311: UDD: please install pg_stat_statements extension
Package: qa.debian.org Severity: wishlist User: qa.debian@packages.debian.org Usertags: udd Dear Maintainer, it seems some parts of the UDD schema are sub-optimal, e.g. some non-trivial tables are missing primary keys or indexes alltogether, resulting in many full table scans. In order to best assess where and how to improve the situation, please install the pg_stat_statements extension in the udd database, like CREATE EXTENSION pg_stat_statements; Also it would be beneficial if the 'track_io_timings' parameter in postgresql.conf could be set to 'on' followed by a reload (a restart is not necessary). After a few days or weeks running with pg_stat_statements, I'd like to take a look at the most problematic queries and how to possibly improve them. Thanks, Michael -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#951674: [Debichem-devel] Building Kalzium with OpenBabel: bad CMake module
Hi,
On Fri, Jul 24, 2020 at 08:31:12AM +0300, mer...@debian.org wrote:
> On 2020-07-19 00:31, John Scott wrote:
> > See the bug hunting at [1]: it seems that even in OpenBabel 3.1.1,
> > the CMake module probably wrongfully hardcodes a path and makes it not work
> > on
> > Debian.
>
> Indeed, there seems to be a problem with paths in OpenBabel CMake
> modules. OpenBabel3Config.cmake seems suspicious: ${OpenBabel3_DIR} does
> not seem to be set anywhere, and the following paths too get incorrect
> values:
>
> * OpenBabel3_INCLUDE_DIRS: should be /usr/include/openbabel3
> * OpenBabel3_EXPORTS_FILE: should be
> /usr/lib//cmake/openbabel3/OpenBabel3_EXPORTS.cmake
> * OpenBabel3_LIBRARIES (maybe?)
>
> Not sure if this issue is relevant outside Debian, hence the upstream
> confusion. I would suggest patching OpenBabel CMake modules in Debian. I
> volunteer to do that if no one comes up with a better solution.
Without having looked at the problem in detail, it sounds like it's
worth filing an issue in OpenBabel upstream as well, or is there one
already?
Michael
Bug#962828: libpgjava: CVE-2020-13692
tags 962828 +patch thanks Hi, Am Sonntag, den 14.06.2020, 22:28 +0200 schrieb Christoph Berg: > Re: Salvatore Bonaccorso > > CVE-2020-13692[0]: > > > PostgreSQL JDBC Driver (aka PgJDBC) before 42.2.13 allows XXE. > > > > which older versions are affected by this, and what is the impact? > > > > > > > I would probably only worry about 42.2.x versions > > impact summary > > https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html > > > > > > > In Debian, we currently ship: > > > > > > libpgjava | 9.2-1002-1| oldoldstable | source (ignore, it's EOL > > > really soon) > > > libpgjava | 9.4.1212-1| oldstable| source > > > libpgjava | 42.2.5-2 | stable | source > > > libpgjava | 42.2.12-1 | testing | source > > > libpgjava | 42.2.12-1 | unstable | source > > > > > > Can you share the actual CVE diff, so we can fix it in the older > > > versions? > > > > Here is the diff > > https://github.com/pgjdbc/pgjdbc/commit/14b62aca4764d496813f55a43d050b017e01eb65 > > (I haven't checked yet if that diff applies to the buster package.) I've backpatched that commit to the stable version (several edits were required but the general code structure is similar) and verified that it builds and that autopkgtest runs fine. I haven't tested it otherwise yet, nor tried to reproduce the CVE, I guess no exploits are available? Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz diff -Nru libpgjava-42.2.5/debian/changelog libpgjava-42.2.5/debian/changelog --- libpgjava-42.2.5/debian/changelog 2019-02-07 10:54:50.0 +0100 +++ libpgjava-42.2.5/debian/changelog 2020-06-19 11:56:51.0 +0200 @@ -1,3 +1,12 @@ +libpgjava (42.2.5-3) stable-security; urgency=medium + + * Team upload. + * debian/patches/cve-2020-13692.patch: New patch, fixes XML External Entitiy +(XXE) injection (CVE-2020-13692). +https://github.com/pgjdbc/pgjdbc/commit/14b62aca4764d496813f55a43d050b017e01eb65 + + -- Michael Banck Fri, 19 Jun 2020 12:02:27 +0200 + libpgjava (42.2.5-2) unstable; urgency=medium * Update PostgreSQL Maintainers address. diff -Nru libpgjava-42.2.5/debian/patches/cve-2020-13692.patch libpgjava-42.2.5/debian/patches/cve-2020-13692.patch --- libpgjava-42.2.5/debian/patches/cve-2020-13692.patch 1970-01-01 01:00:00.0 +0100 +++ libpgjava-42.2.5/debian/patches/cve-2020-13692.patch 2020-06-19 11:25:04.0 +0200 @@ -0,0 +1,585 @@ +From 14b62aca4764d496813f55a43d050b017e01eb65 Mon Sep 17 00:00:00 2001 +From: Sehrope Sarkuni +Date: Mon, 1 Jun 2020 08:54:32 -0400 +Subject: [PATCH] Merge pull request from GHSA-37xm-4h3m-5w3v + +* refactor: Clean up whitespace in existing PgSQLXMLTest + +* fix: Fix XXE vulnerability in PgSQLXML by disabling external access and doctypes + +Fixes XXE vulnerability by defaulting to disabling external access and doc types. The +legacy insecure behavior can be restored via the new connection property xmlFactoryFactory +with a value of LEGACY_INSECURE. Alternatively, a custom class name can be specified that +implements org.postgresql.xml.PGXmlFactoryFactory and takes a no argument constructor. + +* fix: Add missing getter and setter for XML_FACTORY_FACTORY to BasicDataSource +--- + .../main/java/org/postgresql/PGProperty.java | 11 ++ + .../org/postgresql/core/BaseConnection.java | 9 ++ + .../postgresql/ds/common/BaseDataSource.java | 8 + + .../org/postgresql/jdbc/PgConnection.java | 40 + + .../java/org/postgresql/jdbc/PgSQLXML.java| 43 +++--- + .../xml/DefaultPGXmlFactoryFactory.java | 140 ++ + .../xml/EmptyStringEntityResolver.java| 23 +++ + .../LegacyInsecurePGXmlFactoryFactory.java| 57 +++ + .../org/postgresql/xml/NullErrorHandler.java | 25 + .../postgresql/xml/PGXmlFactoryFactory.java | 30 + .../org/postgresql/jdbc/PgSQLXMLTest.java | 96 +++- + 11 files changed, 453 insertions(+), 29 deletions(-) + create mode 100644 pgjdbc/src/main/java/org/postgresql/xml/DefaultPGXmlFactoryFactory.java + create mode 100644 pgjdbc/src/main/java/org/postgresql/xml/EmptyStringEntityResolver.java + create mode 100644 pgjdbc/src/main/java/org/postgresql/xml/LegacyInsecurePGXmlFactoryFactory.java + create mode 100644 pgjdbc/src/main/java/org/postgresql/xml/NullErrorHandler.java + create mode 100644 pgjdbc/src/main/java/org/postgresql/xml/PGXmlFactoryFactory.ja
Bug#962949: ITS: libxsmm
Hi, On Tue, Jun 16, 2020 at 09:48:56AM -0400, Boyuan Yang wrote: > Source: libxsmm > Version: 1.9-1 > Tags: sid > X-Debbugs-CC: mba...@debian.org > Severity: important > > Dear Debian libxsmm package maintainer, Uhm, I'm just the uploader, not the maintainer. The maintainer is the science-team, which you are part of, so why don't you just go ahead and upload your proposed fixes, adding yourself as an additional uploader? Michael
Bug#961980: autopkgtest: add an option to check test dependencies without running tests
Package: autopkgtest Version: 5.13.1 Severity: wishlist Dear Maintainer, in order to run autopkgtest on porter machines, I have written a small proof-of-concept script[1]. This script starts a schroot session, installs autopkgtest and the package's binary packages into it and then tries to figure out the required test dependencies in order to install them as well, followed by running autopkgtest. It currently tries to figure out the dependencies by capturing the error output from autopkgtest first, then installing the dependencies, then running autopkgtest again. I am worried there will be cases without dependencies or where dependencies are already satisfied by installing the binary packages (and their dependencies), so autopkgtest will run twice. It would helpful if autopkgtest had a mode which basically just checks whether the test dependencies are satisfied, and if not, print them out, then exiting before actually running the tests. Michael [1] https://salsa.debian.org/mbanck/dd-autopkgtest
Bug#961755: dh-golang: dh_golang_autopkgtest no longer detects debian/rules targets with make-4.3
On Thu, May 28, 2020 at 09:57:04PM +0200, Michael Banck wrote:
> with make_4.2.3-1:
I meant 4.2.1-1.3.
> |# make -pRrq -f debian/rules : | awk -v RS= -F: '/^# File/,/^# Finished Make
> data base/ { if ($1 !~ "^[#.]") {print $1} }'
> |
> |autopkgtest
> |build
> |override_dh_auto_test
> |override_dh_installsystemd
> |debian/rules
> |override_dh_installinit
> |#
>
> with make_4.3-1:
>
> |# make -pRrq -f debian/rules : | awk -v RS= -F: '/^# File/,/^# Finished
> Make data base/ { if ($1 !~ "^[#.]") {print $1} }'
> |#
>
> i.e. no output.
The difference is in the make output; make-4.2.1-1.3 puts a new line
before '# Files', like:
|# 1 implicit rules, 0 (0.0%) terminal.
|
|# Files
But make-4.3 no longer does that:
|# 1 implicit rules, 0 (0.0%) terminal.
|# Files
That (in combination with setting RS to empty and IFS to :) makes awk's
pattern-match no longer find /^# File/.
Not sure what the best fix would be.
Michael
Bug#961755: dh-golang: dh_golang_autopkgtest no longer detects debian/rules targets with make-4.3
Package: dh-golang
Version: 1.48
Severity: important
Dear Maintainer,
dh_golang_autopkgtest's prepar() function tries to determine the targets
in debian/rules. In current unstable, TARGETS= is empty and it exits out
silently with return code 1 (due to set -e at the top I think).
with make_4.2.3-1:
|# make -pRrq -f debian/rules : | awk -v RS= -F: '/^# File/,/^# Finished Make
data base/ { if ($1 !~ "^[#.]") {print $1} }'
|
|autopkgtest
|build
|override_dh_auto_test
|override_dh_installsystemd
|debian/rules
|override_dh_installinit
|#
with make_4.3-1:
|# make -pRrq -f debian/rules : | awk -v RS= -F: '/^# File/,/^# Finished Make
data base/ { if ($1 !~ "^[#.]") {print $1} }'
|#
i.e. no output.
Michael
-- System Information:
Debian Release: 10.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dh-golang depends on:
ii debhelper 12.1.1
ii dpkg 1.19.7
ii libdpkg-perl 1.19.7
ii perl 5.28.1-6
dh-golang recommends no packages.
dh-golang suggests no packages.
Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.
Hi, On Wed, Mar 25, 2020 at 09:00:13AM +0100, Roberto Mier Escandon wrote: > The word 'guys' is enough inclusive. https://twitter.com/AdamantxYves/status/126170393028609 Now can we get back to discussing packaging yq? cheers, Michael
Bug#956260: [Debichem-devel] Bug#956260: Bug#956260: bkchem: should this package be removed?
Hi, On Sun, May 10, 2020 at 11:22:32AM +0200, Moritz Mühlenhoff wrote: > Let's go ahead with removal now? This is blocking progress on lower level > dependencies. What exactly is it blocking? Michael
Bug#953197: let pg_createconfig_patroni correctly parse multiple dcs endpoints
Hi, Am Donnerstag, den 05.03.2020, 17:58 +0100 schrieb Tomas Pospisek: > this patch [1] lets pg_createconfig_patroni parse multiple DCS endpoints > defined in > `/etc/patroni/dcs.yml` correctly. This could use some additional documentation, maybe in README.Debian. Though I admit the current documentation there is lacking already :-/ Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Bug#956424: etcd: autopkgtest does not seem to run any tests
Source: etcd Version: 3.2.26+dfsg-6 Severity: important Dear Maintainer, E.g. https://ci.debian.net/data/autopkgtest/testing/amd64/e/etcd/4881296/log.gz has at the end: |autopkgtest [15:59:05]: test dh-golang-autopkgtest: |/usr/bin/dh_golang_autopkgtest |autopkgtest [15:59:05]: test dh-golang-autopkgtest: |[--- |[info] Testing github.com/coreos/etcd... |[info] Source code installed by binary package, overriding |dh_auto_configure... |make: 'build' is up to date. |autopkgtest [15:59:06]: test dh-golang-autopkgtest: |---] |autopkgtest [15:59:06]: test dh-golang-autopkgtest: - - - - - - - - - - |results - - - - - - - - - - |dh-golang-autopkgtest PASS |autopkgtest [15:59:06]: summary |dh-golang-autopkgtest PASS Compared to the rather verbose output by the override_dh_auto_test target, there does not seem to be any tests run, also note the time stamps (same second). Michael -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#954366: autopkgtest: logs are missing timestamps
Package: autopkgtest Version: 5.11 Severity: wishlist Dear Maintainer, I believe logs like https://ci.debian.net/data/packages/testing/arm64/p/patroni/4139544.log are from autopkgtest, but there is no timestamp whatsoever in that log. The corresponding full log at https://ci.debian.net/data/autopkgtest//testing/arm64/p/patroni/4139544/log.gz has no timestamps on its own either, though one can guess the test time due to the pdiff filenames from apt update, though that is less than ideal, in my view. Michael -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 1.8.2 ii libdpkg-perl1.19.7 ii procps 2:3.3.15-2 ii python3 3.7.3-1 ii python3-debian 0.1.35 Versions of packages autopkgtest recommends: pn autodep8 Versions of packages autopkgtest suggests: pn lxc pn lxd pn ovmf pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils1:3.1+dfsg-8+deb10u3 ii schroot 1.6.10-6+b1 pn vmdb2
Bug#952535: patroni: test failures on arm64 and others
Hi, Am Dienstag, den 25.02.2020, 13:53 +0100 schrieb Gianfranco Costamagna: > Source: patroni > Version: 1.6.3-2 > Severity: serious > > Hello, looks like your package depends on etcd, but that package is > not working everywhere (even if built, I'll open an RC > later today) > > Can you please have a look, such as marking the test as flaky, > restricting on amd64 and ppc64el, Did something change here? It seems patroni tested fine on arm64 a while ago: https://ci.debian.net/data/packages/testing/arm64/p/patroni/4139544.log > or maybe export ETCD_UNSUPPORTED_ARCH on the unsupported > architectures? I find it a bit hard to believe that arm64 is really an unsupported arch for etcd these days? But anyhow, how do you do that for autopkgtest depends? Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Bug#953942: Removed package(s) from unstable
On Wed, Mar 18, 2020 at 02:48:51AM +, Debian FTP Masters wrote: > We believe that the bug you reported is now fixed; the following > package(s) have been removed from unstable: > > jack | 3.1.1+cvs20050801-31 | source, amd64, arm64, armel, armhf, i386, > mips64el, mipsel, ppc64el, s390x Great Job! Michael
Bug#953623: patroni: Missing quotes in pg_clonecluster_patroni script cause clone to fail
Hi, Am Mittwoch, den 11.03.2020, 10:05 + schrieb Willer, Alexander: > when patroni tries to clone a new secondary server, it fails. Sorry, I didn't see your report immediately when you sent it, but I just encountered the same problem; I think this is a regression with patroni- 1.6.4. > The error happens in the script > /usr/share/patroni/pg_clonecluster_patroni. It seems to happen > because there are some quotes missing for the '--dbname=' argument > which is passed to pg_basebackup. Due to the missing quotes, the > connstring looks like multiple arguments instead of one. My guess ist they changed things around for v12 and the removal of recovery.conf. Or I was just lucky all the time. > After adding quotes to the script (line 44) so that the last argument > looks as follows, the clone process works flawlessly: > > --dbname="$CONNSTR" Right, I had it fixed that way locally as well. Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Bug#953942: jack: should this package be removed?
Hi, On Sun, Mar 15, 2020 at 11:56:00AM -0400, Sandro Tosi wrote: > On Sun, Mar 15, 2020 at 3:01 AM Michael Banck wrote: > > On Sat, Mar 14, 2020 at 03:33:34PM -0400, Sandro Tosi wrote: > > > I believe this package should be removed: > > > > > > * python2-only > > > * no upstream release since 2004 (!) or svn update since 2005 (!) > > > * it's keeping several python2 modules in debian that could be dropped if > > > jack > > > is removed too > > > * several alternatives exist that are much more populare than jack > > > > > > if i dont hear back within a week with a good reason to keep this > > > package, i'll > > > file for its removal. > > > > I find a week way too short for these kind of things, especially in the > > current conditions. > > I set a week of time for an *answer*, not to do the actual work. > > i think i did not see what you think about the removal of jack: is it > worth to keep a 15 years old application in debian (which transitively > keeps in the archive several python2 packages, that could be dropped > as soon as jack is removed)? are you planning on porting it to python3 > (i googled if a port was already available but i couldnt find any)? if > so, did you start already? where can we track progress? Dude, I'm trying to keep my family alive right now. If you think removing jack will save the world, by all means, go for it. Michael
Bug#953942: jack: should this package be removed?
Hi, On Sat, Mar 14, 2020 at 03:33:34PM -0400, Sandro Tosi wrote: > I believe this package should be removed: > > * python2-only > * no upstream release since 2004 (!) or svn update since 2005 (!) > * it's keeping several python2 modules in debian that could be dropped if jack > is removed too > * several alternatives exist that are much more populare than jack > > if i dont hear back within a week with a good reason to keep this package, > i'll > file for its removal. I find a week way too short for these kind of things, especially in the current conditions. Michael
Bug#952463: [Debichem-devel] Bug#952463: bagel: flaky arm64 autopkgtest: terminate called without an active exception
Hi Paul,
On Mon, Feb 24, 2020 at 08:57:40PM +0100, Paul Gevers wrote:
> https://ci.debian.net/data/autopkgtest/testing/arm64/b/bagel/4258642/log.gz
>
> running test case 'hf_sto3g_relfci_gaunt'... terminate called without an
> active exception
> /tmp/autopkgtest-lxc.q3t4znog/downtmp/build.F1y/src/debian/tests/testsuite.sh:
> line 85: 15487 Aborted BAGEL test/${testname}.json >
> ${testname}.out
> /tmp/autopkgtest-lxc.q3t4znog/downtmp/build.F1y/src/debian/tests/testsuite.sh:
> fork: retry: Resource temporarily unavailable
> FAILED.
This looks like the arm64 authobuilder has not enough memory or
something?
Michael
Bug#943991: Bug #943991: behave: failing tests with python3.8
Hi, Am Freitag, den 01.11.2019, 22:05 -0700 schrieb Steve Langasek: > For the moment I have worked around the failure in Ubuntu by changing the > packaging to test only against the current version of python3 and not > against all supported versions, but this is a very short-term fix given that > python3.8 will become the default in the next 6 months. I tried to adapt the upstream changes to 1.2.5, but there's just too much change since 2015 to make this feasible. So I've updated behave to 1.2.6 and added the patch there, see attached (debian/-only) debdiff (which includes the unreleased changes), or the MR here: https://salsa.debian.org/python-team/modules/behave/merge_requests/1 Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz diff -Nru behave-1.2.5/debian/changelog behave-1.2.6/debian/changelog --- behave-1.2.5/debian/changelog 2019-09-13 15:19:10.0 +0200 +++ behave-1.2.6/debian/changelog 2019-10-18 16:03:41.0 +0200 @@ -1,3 +1,21 @@ +behave (1.2.6-1) UNRELEASED; urgency=medium + + * New upstream relesae. + + [ Ondřej Nový ] + * Bump Standards-Version to 4.4.1. + + [ Michael Banck ] + * debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch: +Removed, no longer needed. + * debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch: +Removed, no longer needed. + * debian/patches/0003-Backport-for-py38-fixes.patch: New patch, provides +compatibility with Python 3.8. Closes: #943991. + * debian/control: Added python3-sphinx-bootstrap-theme to Build-Depends. + + -- Ondřej Nový Fri, 18 Oct 2019 16:03:41 +0200 + behave (1.2.5-3) unstable; urgency=medium * Team upload. diff -Nru behave-1.2.5/debian/control behave-1.2.6/debian/control --- behave-1.2.5/debian/control 2019-09-13 14:45:20.0 +0200 +++ behave-1.2.6/debian/control 2019-10-18 16:03:41.0 +0200 @@ -13,8 +13,9 @@ python3-parse-type, python3-setuptools, python3-six, - python3-sphinx -Standards-Version: 4.4.0 + python3-sphinx, + python3-sphinx-bootstrap-theme +Standards-Version: 4.4.1 Homepage: https://github.com/behave/behave Vcs-Git: https://salsa.debian.org/python-team/modules/behave.git Vcs-Browser: https://salsa.debian.org/python-team/modules/behave diff -Nru behave-1.2.5/debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch behave-1.2.6/debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch --- behave-1.2.5/debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch 2019-09-13 14:27:54.0 +0200 +++ behave-1.2.6/debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch 1970-01-01 01:00:00.0 +0100 @@ -1,23 +0,0 @@ -From ed6df9cf0e8522ada8e3eda1d69dfbebc972f271 Mon Sep 17 00:00:00 2001 -From: Vincent Bernat -Date: Tue, 13 Jun 2017 07:38:03 +0200 -Subject: docs: disable use of sphincontrib.cheeseshop - -Not available in Debian - docs/conf.py | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/docs/conf.py b/docs/conf.py -index e108e30138f4..781eff883837 100644 a/docs/conf.py -+++ b/docs/conf.py -@@ -30,7 +30,7 @@ extensions = [ - "sphinx.ext.autodoc", - "sphinx.ext.extlinks", - # -- PYTHON2 SUPPORT ONLY: --"sphinxcontrib.cheeseshop", -+# "sphinxcontrib.cheeseshop", - ] - # if six.PY2: - # # -- PYTHON2 ONLY: Not ported to python3, yet. diff -Nru behave-1.2.5/debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch behave-1.2.6/debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch --- behave-1.2.5/debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch 2019-09-13 14:27:54.0 +0200 +++ behave-1.2.6/debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch 1970-01-01 01:00:00.0 +0100 @@ -1,25 +0,0 @@ -From 6c303a1255e86e7c6d8a9f9b958ea83a7db5db70 Mon Sep 17 00:00:00 2001 -From: Vincent Bernat -Date: Sat, 5 Aug 2017 12:44:17 +0200 -Subject: Python 3.6 compatibility patch (re.LOCALE removed) - - behave/configuration.py | 4 +++- - 1 file changed, 3 insertions(+), 1 deletion(-) - -diff --git a/behave/configuration.py b/behave/configuration.py -index a2563dfbf081..134004c1c950 100644 a/behave/configuration.py -+++ b/behave/configuration.py -@@ -661,8 +661,10 @@ class Configuration(object): - :param names: List of name parts or regular expressions (as text). - :return: Compiled regular expression to use. - "&
Bug#941127: Sphinx docs are downloading resources from the internet
tags 941127 +pending thanks Hi, Am Mittwoch, den 25.09.2019, 11:05 +0200 schrieb Christoph Berg: > Package: patroni > Version: 1.6.0-2 > Severity: normal > > The patroni builds on apt.pg.o are frequently hanging like this: > > 10:47:50 (cd docs; /usr/bin/make html) > 10:47:50 make[2]: Entering directory '/<>/docs' > 10:47:50 Running Sphinx v1.8.5 > 10:47:50 making output directory... > 10:47:50 loading intersphinx inventory from > https://docs.python.org/objects.inv... > > There's some build-dependency missing for a sphinx plugin, I'd say. It seems this is normal behaviour of the intersphinx plugin/module. I've patched it out now, but that is another annoying thing about sphinx builds in Debian. Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Bug#947504: jack: crashes on tagging
Hi, On Fri, Dec 27, 2019 at 01:41:38PM -0500, Norman Ramsey wrote: > I'm ripping and tagging a new CD. At the tagging step, jack crashes > with an error message and stack trace (demonstration below). > The outcome I expected was that the files would be tagged. Thanks for your report. Is this crash specific to this CD, or does it happen for every CD? Michael
Bug#935994: [Debichem-devel] Bug#935994: nwchem: NWChem compiled with long int lapack/blas interface?
Hi, On Thu, Oct 31, 2019 at 01:35:00AM +, Mo Zhou wrote: > Hi NWChem maintainers, > > blas/lapack lib maintainer here. > > > I don't follow it closely, are you saying that both the refblas/lapack > > packages now provide a 64bit int interface, and MKL? Or just MKL? > > both. We additionally compiled a 64bit-indexing version of src:lapack, > namely libblas64-dev and liblapack64-dev. > > Once built against the standard implementaiton, users could switch > the underlying blas64/lapack64 with the update-alternatives mechanism. > https://wiki.debian.org/DebianScience/LinearAlgebraLibraries > > e.g libopenblas64-0 (still in exp), libblis64-2, > libmkl-rt (need to export MKL_INTERFACE_LAYER=ILP64 when actually using) > > However I don't recommend compiling debian packages with the > -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -lmkl_blacs_openmpi_ilp64 ... > way as it would drive the package into contrib. Cool, thanks for the explanation. If somebody (Giacomo?) wants to come up with patches to switch NWChem over to 64bit Blas, that'd be great. I'm pretty busy right now and won't have time for a while to look into it myself. Michael
Bug#935994: [Debichem-devel] Bug#935994: nwchem: NWChem compiled with long int lapack/blas interface?
Hi Giacomo, sorry, I apparently missed your mail initially. On Wed, Aug 28, 2019 at 08:42:21PM +0200, Giacomo Mulas wrote: > I am a long time NWChem (ab)user. I always have to compile NWChem myself, > instead of using the binary version provided by debian, because for large > enough molecules matrices become too big for the 32 bit int interface, and > only run if NWChem was compiled with a 64 bit int lapack/blas. > I understand the need to provide a version of NWChem in debian that works > with free libs available in debian as well, hence the need (so far) to > compile it using the 64 to 32 bit conversion of ints on 64 bit machines. > However, lapack and blas libs with 64 bit integer interfaces just appeared > on debian experimental, and have been available for some time in the > non-free (but packaged in non-free) Intel MKL libs. I don't follow it closely, are you saying that both the refblas/lapack packages now provide a 64bit int interface, and MKL? Or just MKL? > Apparently, this would require limited changes in the debian/rules file. > Would you consider building (also) such a version of nwchem, compiled with > long int blas/lapack libs? Unless there are considerable downsides (are there?) I would not mind switching the nwchem packaging to a 64bit int build using blas/lapack libraries from main. Regarding mkl, my current, initial opinion is that we would welcome patches to make it possible to rebuild nwchem for MKL without source changes (via some DEB_BUILD_OPTIONS or other external flags), but building nwchem twice and once for MKL would (I believe) mean the source package would have to move into contrib as it build-depended on a non-free package. Does anybody else want to chime in here and offer their opinion? Michael
