Bug#1073988: RFS: rabbitcommon/2.2.6-1 [ITP] -- Rabbit common library using Qt

[Phil Wyett]

Control: tags -1 + moreinfo

Hi Kang,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Error / Warning / Information

E: rabbitcommon: description-synopsis-is-duplicated line 1
N: 
N:   The first line of the extended Description: should not repeat the synopsis
N:   exactly. This indicates that either the synopsis is badly formed or that
N:   the extended description has been wrongly copied and pasted.
N: 
N:   Please refer to The extended description (Section 3.4.2) in the Debian
N:   Policy Manual for details.
N: 
N:   Visibility: error
N:   Show-Always: no
N:   Check: fields/description
N: 
N:
E: rabbitcommon-dev: description-synopsis-is-duplicated line 1

E: rabbitcommon: relative-library-search-path RUNPATH ../lib [usr/lib/x86_64-
linux-gnu/libRabbitCommon.so.2.2.6]
N: 
N:   The binary or shared library sets RPATH or RUNPATH. This overrides the
N:   normal library search path, possibly interfering with local policy and
N:   causing problems for multilib, among other issues.
N:   
N:   As an aggravating factor, this search path is relative! It is probably not
N:   what you wanted.
N:   
N:   The only time a binary or shared library in a Debian package should set
N:   RPATH or RUNPATH is if it is linked to private shared libraries in the
N:   same package. In that case, place those private shared libraries in
N:   /usr/lib/*package*. Libraries used by binaries in other packages should be
N:   placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which
N:   case RPATH/RUNPATH is unnecessary.
N:   
N:   To fix this problem, look for link lines like:
N:   
N:   gcc test.o -o test -Wl,--rpath,/usr/local/lib
N:   or
N:   gcc test.o -o test -R/usr/local/lib
N:   
N:   and remove the -Wl,--rpath or -R argument.
N:   
N:   You can also use the chrpath utility to remove the RPATH.
N: 
N:   Please refer to https://wiki.debian.org/RpathIssue, Bug#732682, and
N:   Bug#732674 for details.
N: 
N:   Visibility: error
N:   Show-Always: no
N:   Check: binaries/rpath
N: 
N:
E: rabbitcommon: relative-library-search-path RUNPATH ../lib/x86_64-linux-gnu
[usr/lib/x86_64-linux-gnu/libRabbitCommon.so.2.2.6]

W: rabbitcommon: extended-description-line-too-long line 6
N: 
N:   One or more lines in the extended part of the "Description:" field have
N:   been found to contain more than 80 characters. For the benefit of users of
N:   80x25 terminals, it is recommended that the lines do not exceed 80
N:   characters.
N: 
N:   Please refer to The single line synopsis (Section 3.4.1) in the Debian
N:   Policy Manual for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: fields/description
N: 
N:
W: rabbitcommon: extended-description-line-too-long line 7
N:
W: rabbitcommon: extended-description-line-too-long line 8
N:
W: rabbitcommon-dev: extended-description-line-too-long line 6
N:
W: rabbitcommon-dev: extended-description-line-too-long line 7
N:
W: rabbitcommon-dev: extended-description-line-too-long line 8

W: rabbitcommon: initial-upload-closes-no-bugs
[usr/share/doc/rabbitcommon/changelog.Debian.gz:1]
N: 
N:   This package appears to be the first packaging of a new upstream software
N:   package (there is only one changelog entry and the Debian revision is 1),
N:   but it does not close any bugs. The initial upload of a new package should
N:   close the corresponding ITP bug for that package.
N:   
N:   This warning can be ignored if the package is not intended for Debian or
N:   if it is a split of an existing Debian package.
N: 
N:   Please refer to New packages (Section 5.1) in the Debian Developer's
N:   Reference for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: debian/changelog
N:   Renamed from: new-package-should-close-itp-bug
N: 
N:
W: rabbitcommon-dev: initial-upload-closes-no-bugs [usr/share/doc/rabbitcommon-
dev/changelog.Debian.gz:1]

W: rabbitcommon: lacks-unversioned-link-to-shared-library example:
usr/lib/x86_64-linux-gnu/libRabbitCommon.so [usr/lib/x86_64-linux-
gnu/libRabbitCommon.so.2.2.6]
N: 
N:   A -dev package is supposed to install an unversioned symbolic link that
N:   references the shared library by name.
N:   
N:   There is no requirement that the names are otherwise related.
N:   
N:   The dynamic linker uses the link to load the executable into memory.
N:   
N:   In most cases, the symbolic link should be in the same folder as the
N:   library itself. A major exception are libraries installed under /lib. In
N:   those cases, the links should go into the corresponding folders under
N:   /usr.
N:   
N:   For a library installed as /lib/i386-linux-gnu/libXYZ.so.V, a good link

Bug#1074245: pam_pkcs11 manpage has no useful information and referes to non-existing pam_pkcs11.conf

[Michael Tokarev]

Package: libpam-pkcs11
Version: 0.6.12-1
Severity: normal

the pam_pkcs11 manpage contains no information whatsoever about how to
use the module.  Also, it refers to pam_pkcs11.conf manpage which is not
shipped with the package.  The result of all this is that the module is
basically unusable.  It isn't even clear where pam_pkcs11.conf file should
be.  Okay, examples/READMEs shipped in /usr/share/doc/libpam-pkcs11/
helps a bit, also strings and strace tools, but it's not where one looks
for the info usually.

Thanks,

/mjt

Bug#1074176: packages.debian.org: allow seeing files

[Dan Jacobson]

Thanks. But: The older page needs to mention the newer page, else
people who end up on the older page will think that that is all they are 
allowed to see.
In fact the older page should use the links from the newer page, to make its 
flat list clickable.
Also both pages don't have any file dates. That is mainly why the reader came 
there,
to see how old the files are. Sure, there is a VERSION file, but no date on it 
either.
Anyway: so the entire website needs to use ls -og to show the dates.
Yes, "dates aren't reliable", but no dates are worse.

On Mon, Jun 24, 2024 at 09:47:15AM -0700, Soren Stoutner wrote:
> You are probably looking for this URL:
> https://sources.debian.org/src/gdal/3.9.1~rc2%2Bdfsg-1~exp1/

Bug#1074230: orgguide.info.gz is not visible in Emacs Info

[Nicholas D Steeves]

Hi Morten,

Nice find!  Thank you for filing this bug.

Morten Kjeldgaard  writes:

> Package: org-mode-doc
>
> Version: 9.5.2-1
>
> After installing org-mode-doc on bookworm, the Org Guide item is not 
> visible from inside Emacs after calling the Info system using C-h i. 
> Emacs simply says:
>
>      Info file 'orgguide' does not exist; consider installing it.

This will be resolved momentarily (in sid/unstable)

> The problem can be solved by copying the orgguide.info.gz file to 
> /usr/share/info:
>
>      sudo cp /usr/share/doc/org-mode-doc/orgguide.info.gz /usr/share/info

but not with this method.

This isn't a severe enough issue to make an update to stable/bookworm.

Would you please try uninstalling elpa-org-mode as well as org-mode-doc?
Then install emacs-common-non-dfsg and try to reproduce this bug,
because it's possible that it is also present in src:emacs itself (Emacs
contains a bundled copy of org-mode).  If that's the case then we'll
need to clone this bug.  Please let me know :)

> The maintainers of the package should consider creating a link to 
> orgguide.info.gz in /usr/share/info. Many other files in that directory 
> are links to /etc/alternatives, I don't know if that is necessary.

Hmm.  Please see the other org-mode and org-mode-doc bugs because your
suggestion touches on this: new org-mode-doc doesn't shadow old
Emacs-bundled copy of the info pages.


signature.asc
Description: PGP signature

Bug#1074243: sccache - please remove build-dependency on librust-counted-array-0.1+default-dev

[Peter Green]

Package: sccache
Version: 0.8.1-3
Severity: serious
x-debbugs-cc: n...@sail.ng

sccache build-depends on librust-counted-array-0.1+default-dev which was 
recently
removed from Debian. The removal request was filed by Blair Noctis who gave the
reasoning.


Please kindly remove rust-counted-array from unstable. It didn't see maintenance
upstream for a long time, and is no longer used by other packages, either
upstream or in Debian. Thank you.


Investigating deeper, it seems that sccache replaced the counted-array crate 
with
a simplified internal implementation a couple of years ago but the Debian 
package
still has a build-dependency on it.

I was able to succesfully test-build sccache with the build-dependency removed.

Bug#1074242: ITP: opentelemetry -- C++ OpenTelemetry client

[Santiago Ruano Rincón]

Package: wnpp
Severity: wishlist
Owner: Santiago Ruano Rincón 
X-Debbugs-Cc: debian-de...@lists.debian.org, team+freex...@tracker.debian.org

* Package name: opentelemetry
  Version : 1.16.0
  Upstream Contact: https://github.com/open-telemetry/opentelemetry-cpp/issues
* URL : https://opentelemetry.io/
* License : Apache-2.0
  Programming Lang: C++
  Description : OpenTelemetry client

OpenTelemetry is an Observability framework and toolkit designed to create and
manage telemetry data such as traces, metrics, and logs. Crucially,
OpenTelemetry is vendor- and tool-agnostic, meaning that it can be used with a
broad variety of Observability backends.

OpenTelemetry is focused on the generation, collection, management, and export
of telemetry. A major goal of OpenTelemetry is that you can easily instrument
your applications or systems, no matter their language, infrastructure, or
runtime environment. The storage and visualization of telemetry is
intentionally left to other tools.

This package will provide the C++ OpenTelemetry client. It will be a dependency
of tango 10.0. It will be maintained by the Freexian packaging team.


signature.asc
Description: PGP signature

Bug#1074241: opensnitch can no longer be built on ppc64el.

[Peter Green]

Package: opensnitch
Severity: serious
Justification: rc policy - packages must be buildable within the same release.

The build-dependencies for opensnitch are no longer satisfiable
on ppc64el, because bpfcc no longer supports that architecture.

  package: opensnitch
  version: 1.5.8.1-1
  architecture: any,all
  type: src
  status: broken
  reasons:
   -
missing:
 pkg:
  package: golang-github-iovisor-gobpf-dev
  version: 0.2.0-6
  architecture: all
  unsat-dependency: libbpfcc-dev:ppc64el
 depchains:
  -
   depchain:
-
 package: opensnitch
 version: 1.5.8.1-1
 architecture: any,all
 type: src
 depends: golang-github-iovisor-gobpf-dev:ppc64el

Either this needs to be dealt with somehow such that opensnitch
can be built on ppc64el again, or the ppc64el binaries for
opensnitch need to be removed.

Bug#1074240: ITP: wlmaker -- Wayland compositor inspired by Window Maker

[Gürkan Myczko]

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

* Package name: wlmaker
  Version : 0.2+git20240618+ds
  Upstream Authors: Philip Kaeser
  URL : https://github.com/phkaeser/wlmaker
* License : Apache-2.0
  Description : Wayland compositor inspired by Window Maker
 This is a Wayland compositor inspired by Window Maker.
  - Compositor for windows in stacking mode.
  - Supports multiple workspaces.
  - Appearance inspired by Window Maker, following the look and feel of
NeXTSTEP.
  - Easy to use, lightweight, low gimmicks and fast.
  - Dock and clip, to be extended for dockable apps.

This will be part of the GNUstep Team.

Bug#1074239: cura: Cura fails to start

[Peter Chubb]

Package: cura
Version: 5.0.0-3
Severity: normal

Dear Maintainer,

 I installed the latest cura, typed 'cura' in a terminal window, and got a heap 
of debug messages, but no cura window.

 Some  messages that may be relevant:
2024-06-25 09:12:27,979 - ERROR - [MainThread] UM.PluginRegistry._findPlugin 
[730]: Exception: Import error loading module TrimeshReader
2024-06-25 09:12:27,980 - ERROR - [MainThread] UM.PluginRegistry._findPlugin 
[730]: Traceback (most recent call last):
2024-06-25 09:12:27,981 - ERROR - [MainThread] UM.PluginRegistry._findPlugin 
[730]:   File "/usr/lib/python3/dist-packages/UM/PluginRegistry.py", line 728, 
in _findPlugin
2024-06-25 09:12:27,981 - ERROR - [MainThread] UM.PluginRegistry._findPlugin 
[730]: module = imp.load_module(plugin_id, file, path, desc)  # type: 
ignore #MyPy gets the wrong output type from imp.find_module for some reason.
 2024-06-25 09:12:29,758 - ERROR - [MainThread] 
UM.Qt.QtApplication.createQmlComponent [606]: 
file:///usr/lib/cura/plugins/ModelChecker/ModelChecker.qml:8:1: Type 
UM.SimpleButton unavailable


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, i386

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

Versions of packages cura depends on:
ii  cura-engine  1:5.0.0-4+b1
ii  fdm-materials5.0.0-2
ii  fonts-open-sans  1.11-2
ii  python3  3.11.8-1
ii  python3-certifi  2024.6.2-1
ii  python3-charon   5.0.0-4
ii  python3-cryptography 42.0.5-2
ii  python3-keyring  25.2.1-1
ii  python3-pynest2d 5.0.0-3+b1
ii  python3-pyqt66.7.0-1+b2
ii  python3-requests 2.32.3+dfsg-1
ii  python3-savitar  5.0.0-4.1+b1
ii  python3-sentry-sdk   1.40.4-3
ii  python3-serial   3.5-2
ii  python3-shapely  2.0.4-1
ii  python3-uranium  5.0.0-4
ii  qml6-module-qt-labs-folderlistmodel  6.6.2+dfsg-3
ii  qml6-module-qtqml-workerscript   6.6.2+dfsg-3
ii  qml6-module-qtquick-controls 6.6.2+dfsg-3
ii  qml6-module-qtquick-dialogs  6.6.2+dfsg-3
ii  qml6-module-qtquick-layouts  6.6.2+dfsg-3
ii  qml6-module-qtquick-templates6.6.2+dfsg-3
ii  qml6-module-qtquick-window   6.6.2+dfsg-3
ii  qt6-qpa-plugins  6.6.2+dfsg-8
ii  uranium-plugins  5.0.0-4

Versions of packages cura recommends:
ii  python3-zeroconf  0.132.2-2

cura suggests no packages.

-- no debconf information

Bug#1074238: local/vmxnet.hook could also detect zstd-compressed pcnet32 kernel module

[Bryce Harrington]

Source: open-vm-tools
Version: 2:11.3.5-1ubuntu4
Severity: wishlist

Ubuntu has begun compressing kernel modules[1] which results in them
having the suffix "*.ko.zst".  The vmxnet.hook for open-vm-tools detects
the module filename exactly as "pcnet32.ko" so is not able to detect the
compressed module, and thus will fail to load vmxnet as intended.

I believe this change would address the deficiency:

-if find "${DESTDIR}"/lib/modules -name pcnet32.ko >/dev/null; then
+if find "${DESTDIR}"/lib/modules -name pcnet32.ko -o -name pcnet32.ko.zst 
>/dev/null; then
manual_add_modules vmxnet
+   apply_add_modules
 fi

I considered wildcards but figure it's safer to be explicit.

I don't know whether Debian is considering support for compressed kernel
modules, but other distros[2,3] are in process of implementing it.

Thanks for considering,
Bryce

1: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/2068026
2: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12857
3: 
https://www.reddit.com/r/archlinux/comments/ecr5hz/zstdcompressed_module_patch_for_the_linux_kernel/


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-100-generic (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_BAD_PAGE, TAINT_WARN, 
TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1069744: btrfs-progs: btrfs dev usa as non-root is wrong in every way and should just give an error

[Nicholas D Steeves]

Hi Russell,

On Wed, 24 Apr 2024 08:03:59 +1000 Russell Coker  wrote:
> Package: btrfs-progs
> Version: 6.6.3-1.1+b2
> Severity: normal
> Tags: upstream
> 
> Below is an example of comparing btrfs dev usa as root and non-root.  When
> run as non-root it is wrong in every way, there is not a single correct
> value.  I've done this on my laptop (single device) and on a server with 3
> devices and the results were similarly wrong.
> 
> Instead of providing information that is wrong and misleading it should
> just give an error and say that it needs root permissions.
> 
> # btrfs dev usa /
> /dev/mapper/root, ID: 1
>Device size:   476.37GiB
>Device slack:1.50KiB
>Data,single:   170.01GiB
>Metadata,DUP:6.00GiB
>System,DUP: 64.00MiB
>Unallocated:   300.29GiB
> 
> $ btrfs dev usa /
> WARNING: cannot read detailed chunk info, per-device usage will not be shown, 
> run as root
> /dev/mapper/root, ID: 1
>Device size:   952.73MiB
>Device slack:   16.00EiB
>Unallocated:   476.37GiB

I agree 100%.  Would you please forward this upstream?

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1074237: Please update to v6.9.0

[Nicholas D Steeves]

Package: btrfs-progs
Version: 6.6.3-1.2
Severity: normal

Hi Adam,

Would you please update to 6.9.0 soon?  Btrfs-repair fixes are the main 
justification, as far as I can tell.  Also please watch out for this:

Note: raid-stripe-tree has recently got a on-disk format update
which is not backward compatible, until the patches are in kernel
(ETA release 6.11) use v6.9 or lower, both need either DEBUG or
experimental build (David Sterba, "Btrfs progs release 6.9.1")

A user on debian-backports also requested a release newer than 6.6.3
for reasons that I'm not yet familiar with.

Cheers,
Nicholas

Bug#1024257: btrfs-progs: Backup fails with "multiple capabilities" at first, then "capability no data available"

[Nicholas D Steeves]

Hi Leszek,

On Wed, 16 Nov 2022 14:50:28 +0100 Leszek Dubiel  wrote:
> Package: btrfs-progs
> Version: 5.10.1-2
> Severity: important
> 
> 
> Hello :) :)
> 
> I am doing regular backukps send/receive.
> 
> I get a lot of messages like this:
> 
> WARNING: capabilities set multiple times per file: /mnt/sda2/2022-11-11 
> 23:58:02 169205882/ZK_83308/Documents/fk-2228.jpg
> 
> WARNING: capabilities set multiple times per file: /mnt/sdc2/2022-11-11 
> 23:58:02 169205882/ZK_83308/Documents/fk-2228.jpg
> 
> WARNING: capabilities set multiple times per file: /mnt/sdc2/2022-11-12 
> 08:57:01 386278919/ZK_83308/Documents/fk-2228.jpg
> 
> 
> and after some time it completely fails with errors:
> 
> ERROR: lremovexattr ZK_83308/Documents/fk-2228.jpg security.capability 
> failed: No data available
> 
> ERROR: lremovexattr ZK_83308/Documents/fk-2228.jpg security.capability 
> failed: No data available
> 
> ERROR: lremovexattr ZK_83308/Documents/fk-2228.jpg security.capability 
> failed: No data available
> 
> 
> 
> I have found other people also have such problems:
> 
>  https://github.com/digint/btrbk/issues/416
> 
> https://www.kubuntuforums.net/forum/general/miscellaneous/btrfs/71629-strange-warning-on-incremental-backup
> 
> 
> 
> and the problem is probably back again after 2014:
> 
>  https://bugzilla.kernel.org/show_bug.cgi?id=68891
> 
> 
> 
> 
> After getting warnings I have checksummed send and receiving subvolumes 
> with rsync and files are
> identical.
> 
> But I have once found that btrfs/send receive finished without any 
> errors (!), subvolumes were both
> read-only, and file was missing on receiving side.
> 
> 
> 
> 

If you're still on bullseye (Debian 11), then Debian Backports may solve
this.  Install btrfs-progs 6.2-1~bpo11+1.  The kernel from backports may
also be required.  Note that backports support for Debian 11 (bullseye)
will probably end within the next six months, so please consider
upgrading to Debian 12 (bookworm) at your earliest convenience.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1060069: btrfs-progs: reiserfs support optional?

[Nicholas D Steeves]

Hi Daniel and Adam,

On Fri, 05 Jan 2024 16:09:32 +0100 Daniel Vacek  wrote:
> Package: btrfs-progs
> Version: 6.6.3-1
> Severity: wishlist
> X-Debbugs-Cc: neel...@gmail.com
> 
> Hello,
> 
> I was wondering if the reiserfs support could be split into a separate 
> optional
> package.
> 
> The reason is I don't really need any riserfs libraries installed on my system
> when I never used this FS and I never will.
> 
> Have a nice day :-)

I think this should be tagged "trixie" because

reiserfsprogs (1:3.6.27-7) unstable; urgency=medium

  * Remove udebs. Acked by Cyril Brulebois and Steve McIntyre on d-boot
ReiserFS has been deprecated upstream and scheduled for removal
2025.

 -- Felix Zielcke   Wed, 20 Sep 2023 18:33:40 +0200

So there's no need to make unnecessarily complicate btrfs-progs nor
increase the workload of the ftpmasters (who have to manually review
changes like this).  It looks like reiserfs will not be part of trixie
(Debian 13).

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#572712: use hardened sysctl net.* settings per default

[Ben Hutchings]

Control: reassign -1 linux-sysctl-defaults 4.10
Control: tag -1 moreinfo

Better late than never: we now have a package providing a default
sysctl configuration file, which will (soon) be added to Depends or
Recommends of systemd and procps.

You wrote:
> I think it would be a good idea to use at least the settings blow per
> default:
> net.ipv4.conf.all.rp_filter=1

This is (effectively) set to 2 by the new configuration.

> net.ipv4.conf.all.accept_redirects = 0

This is not set by the new configuration.  The kernel default for this
is the inverse of net.ipv4.conf.all.forwarding, so it will be set on
routers but not hosts.

> net.ipv6.conf.all.accept_redirects = 0

This is not set and the kernel default is still 1.

> net.ipv4.conf.all.send_redirects = 0

This is not set and the kernel default is still 1.  It's documented to
only affect routers but I'm not sure if that's true.

> net.ipv4.conf.all.accept_source_route = 0

This is (effectively) set to 0 by the new configuration.

> net.ipv6.conf.all.accept_source_route = 0

That has always been the kernel default value.

[...]
> 1) The vast majority of Debian installations are NOT used as rooter

I think this is longer true: anything hosting VMs or containers that
have networking acts a router.

> 2) It's better to ship hardened settings per default, even if this
> "breaks" some things.
> 3) As the "broken" things are usually special setups (e.g. router)
> people that need them should be aware of what they're doing, and thus be
> able to set the sysctl settings they need.
> The "normal" end-user does usually however not know of these settings,
> their security impact and whether or not he should set them.

I think it can be acceptable to break really unusual configurations if
we provide appropriate notification in NEWS and release notes.

But like I said, I don't think routers are that rare now.

Which of the above would be a problem for routers?

> btw: I'd also suggest to activate syncookies per default, but this is
> already requested in #520668.

This has been the kernel default since 2.6.33.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman



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

Bug#1074082: mmdebstrap: tests expect /var/log/faillog to exist

[Chris Hofstaedtler]

Hi!

thank you for your help with sorting out my local test setup.

On Sun, Jun 23, 2024 at 02:24:03AM +0200, Chris Hofstaedtler wrote:
> As you've already noticed, shadow 4.15.2-1 breaks mmdebstrap's
> tests.

Merge request to allow faillog, and lastlog to be absent:

https://salsa.debian.org/debian/mmdebstrap/-/merge_requests/9

Please consider merging it.

Locally I'm seeing a later failure with regard to diversions of
/.lib64.usr-is-merged et al, but that seems unrelated.

Chris

Bug#1072934: shadowsocks-libev: Consider removing the package

[Andrea Pappacoda]

On Mon, 10 Jun 2024 11:55:30 -0400 Boyuan Yang  wrote:
> Following the previous communication in March, I am considering to take action
> and remove related packages in the ss-libev ecosystem. Package 
> shadowsocks-libev
> will be removed together with simple-obfs.

Hi Boyuan, I don't know what previous communication you are referring
to, but I support your proposal! shadowsocks-libev has been deprecated
upstream for quite a while in favour of shadowsocks-rust, and while this
isn't an issue for me personally, the fact that the package builds only
with MbedTLS 2.x and fails to build with 3.6 (which I'm trying to
transition to) kinda bothers me.

Hence, if there were reasons to remove shadowsocks-libev from the
archive, now there is one more :)

Thanks again for your efforts! Bye.

Bug#1074236: node-ws: CVE-2024-37890

[Moritz Mühlenhoff]

Source: node-ws
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for node-ws.

CVE-2024-37890[0]:
| ws is an open source WebSocket client and server for Node.js. A
| request with a number of headers exceeding theserver.maxHeadersCount
| threshold could be used to crash a ws server. The vulnerability was
| fixed in ws@8.17.1 (e55e510) and backported to ws@7.5.10 (22c2876),
| ws@6.2.3 (eeb76d3), and ws@5.2.4 (4abd8f6). In vulnerable versions
| of ws, the issue can be mitigated in the following ways: 1. Reduce
| the maximum allowed length of the request headers using the --max-
| http-header-size=size and/or the maxHeaderSize options so that no
| more headers than the server.maxHeadersCount limit can be sent. 2.
| Set server.maxHeadersCount to 0 so that no limit is applied.

https://github.com/websockets/ws/security/advisories/GHSA-3h5v-q93c-6h6q
https://github.com/websockets/ws/issues/2230
https://github.com/websockets/ws/pull/2231
https://github.com/websockets/ws/commit/e55e5106f10fcbaac37cfa89759e4cc0d073a52c
 (8.17.1)
https://github.com/websockets/ws/commit/22c28763234aa75a7e1b76f5c01c181260d7917f
 (7.5.10)
https://github.com/websockets/ws/commit/eeb76d313e2a00dd5247ca3597bba7877d064a63
 (6.2.3)
https://github.com/websockets/ws/commit/4abd8f6de4b0b65ef80b3ff081989479ed93377e
 (5.2.4)


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-37890
https://www.cve.org/CVERecord?id=CVE-2024-37890

Please adjust the affected versions in the BTS as needed.

Bug#1074233: slic3r-prusa: CVE-2024-24686 CVE-2024-24685 CVE-2024-24684 CVE-2024-24584 CVE-2024-24583 CVE-2024-23951 CVE-2024-23950 CVE-2024-23949 CVE-2024-23948 CVE-2024-23947 CVE-2024-22181 CVE-2023

[Moritz Mühlenhoff]

Source: slic3r-prusa
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for libigl, which slic3r-prusa
embeds a copy of.

https://talosintelligence.com/vulnerability_reports/TALOS-2024-1929
https://talosintelligence.com/vulnerability_reports/TALOS-2024-1928
https://talosintelligence.com/vulnerability_reports/TALOS-2024-1926
https://talosintelligence.com/vulnerability_reports/TALOS-2024-1930
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1879
https://talosintelligence.com/vulnerability_reports/TALOS-2023-1784

https://github.com/libigl/libigl/issues/2387

CVE-2024-24686[0]:
| Multiple stack-based buffer overflow vulnerabilities exist in the
| readOFF functionality of libigl v2.5.0. A specially crafted .off
| file can lead to stack-based buffer overflow. An attacker can
| provide a malicious file to trigger this vulnerability.This
| vulnerability concerns the parsing of comments within the faces
| section of an `.off`  file processed via the `readOFF` function.


CVE-2024-24685[1]:
| Multiple stack-based buffer overflow vulnerabilities exist in the
| readOFF functionality of libigl v2.5.0. A specially crafted .off
| file can lead to stack-based buffer overflow. An attacker can
| provide a malicious file to trigger this vulnerability.This
| vulnerability concerns the parsing of comments within the vertex
| section of an `.off`  file processed via the `readOFF` function.


CVE-2024-24684[2]:
| Multiple stack-based buffer overflow vulnerabilities exist in the
| readOFF functionality of libigl v2.5.0. A specially crafted .off
| file can lead to stack-based buffer overflow. An attacker can
| provide a malicious file to trigger this vulnerability.This
| vulnerability concerns the header parsing occuring while processing
| an `.off`  file via the `readOFF` function.   We can see above
| that at [0] a stack-based buffer called `comment` is defined with an
| hardcoded size of `1000 bytes`.  The call to `fscanf` at [1] is
| unsafe and if the first line of the header of the `.off` files is
| longer than 1000 bytes it will overflow the `header` buffer.


CVE-2024-24584[3]:
| Multiple out-of-bounds read vulnerabilities exist in the readMSH
| functionality of libigl v2.5.0. A specially crafted .msh file can
| lead to an out-of-bounds read. An attacker can provide a malicious
| file to trigger this vulnerability.This vulnerabilitty concerns
| the`readMSH` function while processing `MshLoader::ELEMENT_TET`
| elements.


CVE-2024-24583[4]:
| Multiple out-of-bounds read vulnerabilities exist in the readMSH
| functionality of libigl v2.5.0. A specially crafted .msh file can
| lead to an out-of-bounds read. An attacker can provide a malicious
| file to trigger this vulnerability.This vulnerabilitty concerns
| the`readMSH` function while processing `MshLoader::ELEMENT_TRI`
| elements.


CVE-2024-23951[5]:
| Multiple improper array index validation vulnerabilities exist in
| the readMSH functionality of libigl v2.5.0. A specially crafted .msh
| file can lead to an out-of-bounds write. An attacker can provide a
| malicious file to trigger this vulnerability.This vulnerability
| concerns the `igl::MshLoader::parse_element_field` function while
| handling an `ascii`.msh` file.


CVE-2024-23950[6]:
| Multiple improper array index validation vulnerabilities exist in
| the readMSH functionality of libigl v2.5.0. A specially crafted .msh
| file can lead to an out-of-bounds write. An attacker can provide a
| malicious file to trigger this vulnerability.This vulnerability
| concerns the `igl::MshLoader::parse_element_field` function while
| handling an `binary`.msh` file.


CVE-2024-23949[7]:
| Multiple improper array index validation vulnerabilities exist in
| the readMSH functionality of libigl v2.5.0. A specially crafted .msh
| file can lead to an out-of-bounds write. An attacker can provide a
| malicious file to trigger this vulnerability.This vulnerability
| concerns the `igl::MshLoader::parse_node_field` function while
| handling an `ascii`.msh` file.


CVE-2024-23948[8]:
| Multiple improper array index validation vulnerabilities exist in
| the readMSH functionality of libigl v2.5.0. A specially crafted .msh
| file can lead to an out-of-bounds write. An attacker can provide a
| malicious file to trigger this vulnerability.This vulnerability
| concerns the `igl::MshLoader::parse_nodes` function while handling
| an `ascii`.msh` file.


CVE-2024-23947[9]:
| Multiple improper array index validation vulnerabilities exist in
| the readMSH functionality of libigl v2.5.0. A specially crafted .msh
| file can lead to an out-of-bounds write. An attacker can provide a
| malicious file to trigger this vulnerability.This vulnerability
| concerns the `igl::MshLoader::parse_nodes` function while handling a
| `binary` `.msh` file.


CVE-2024-22181[10]:
| An out-of-bounds write vulnerability exists in the readNODE
| functionality of libigl v2.5.0. A 

Bug#1074235: cvc5: CVE-2024-37794 CVE-2024-37795

[Moritz Mühlenhoff]

Source: cvc5
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for cvc5.

CVE-2024-37794[0]:
| Improper input validation in CVC5 Solver v1.1.3 allows attackers to
| cause a Denial of Service (DoS) via a crafted SMT2 input file.

CVE-2024-37795[1]:
| A segmentation fault in CVC5 Solver v1.1.3 allows attackers to cause
| a Denial of Service (DoS) via a crafted SMT-LIB input file
| containing the `set-logic` command with specific formatting errors.


https://github.com/cvc5/cvc5/issues/10813

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-37794
https://www.cve.org/CVERecord?id=CVE-2024-37794
[1] https://security-tracker.debian.org/tracker/CVE-2024-37795
https://www.cve.org/CVERecord?id=CVE-2024-37795

Please adjust the affected versions in the BTS as needed.

Bug#1074234: scikit-learn: CVE-2024-5206

[Moritz Mühlenhoff]

Source: scikit-learn
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for scikit-learn.

CVE-2024-5206[0]:
| A sensitive data leakage vulnerability was identified in scikit-
| learn's TfidfVectorizer, specifically in versions up to and
| including 1.4.1.post1, which was fixed in version 1.5.0. The
| vulnerability arises from the unexpected storage of all tokens
| present in the training data within the `stop_words_` attribute,
| rather than only storing the subset of tokens required for the TF-
| IDF technique to function. This behavior leads to the potential
| leakage of sensitive information, as the `stop_words_` attribute
| could contain tokens that were meant to be discarded and not stored,
| such as passwords or keys. The impact of this vulnerability varies
| based on the nature of the data being processed by the vectorizer.

https://huntr.com/bounties/14bc0917-a85b-4106-a170-d09d5191517c
https://github.com/scikit-learn/scikit-learn/commit/70ca21f106b603b611da73012c9ade7cd8e438b8
 (1.5.0rc1)


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-5206
https://www.cve.org/CVERecord?id=CVE-2024-5206

Please adjust the affected versions in the BTS as needed.

Bug#1073560: Reverting "xshared: Print protocol numbers if --numeric was given" breaks firewalld autopkgtest

[Michael Biebl]

Looping in Eric (firewalld upstream), to make him aware of this issue 
and gather his input.


Michael
Am 17.06.24 um 22:16 schrieb Jeremy Sowden:

On 2024-06-17, at 15:57:05 +0200, Michael Biebl wrote:

Source: iptables
Version: 1.8.10-4
Severity: serious


The cherry-pick of the commit 34f085b1607364f4eaded1140060dcaf965a2649
Revert "xshared: Print protocol numbers if --numeric was given" breaks
firewalld, as seen in
https://ci.debian.net/packages/f/firewalld/testing/amd64/47810213/

firewalld is very susceptible to changes of the output and command
line interface of iptables.  See an older issue
https://github.com/firewalld/firewalld/issues/1112

Filing with RC severity, so the package doesn't migrate to testing
(the debci results should prevent that, but this is just to make
doubly sure)

This change of iptables afaics has landed in a stable release
(bookworm). Do we really want to revert it again and make all users of
--numeric have to update again?


Hi.  Let me explain my understanding of the current situation.  I appre-
ciate that you probably know most of this already, but I just want to
avoid any confusion.

Upstream made a change that affected the output of protocols in listings
in the presence of the `--numeric` flag.  Previously, they were still
output by name, after the change they were output by number.  This was
released upstream in 1.8.9 and made its way into Bookworm.

This change broke stuff.  As a result of a bug-report:

 https://bugzilla.netfilter.org/show_bug.cgi?id=1729

upstream reverted the change in commit 34f085b16073 ("Revert "xshared:
Print protocol numbers if --numeric was given"").  This is where things
currently stand upstream: in the next release (1.8.11), the original
behaviour will be restored.

A report was also created in the BTS:

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

In response, I applied the upstream commit and uploaded it to unstable.
I have a draft bookworm-pu bug-report that I had intended to send
requesting that this change go into Bookworm to minimize the time before
the old behaviour is restored.  Obviously, I will hold off while we
discuss this. :)

What do you propose?  The firewalld test-suite was updated to work with
the new output; however, other tools were not, and upstream reverted the
change because there were no compelling reasons for it and it had caused
breakage in those tools.  As things stand, the old behaviour will be re-
stored.  Would you rather wait for the next upstream release?  Are you
suggesting that we ask upstream to revert 34f085b16073?  Or do you have
something else in mind?

J.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074232: transition: stk

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2024-06-24 22:35:27 +0200, IOhannes m zmoelnig wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: s...@packages.debian.org
> Control: affects -1 + src:stk
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> The latest version of STK fixes #1051564.
> Unfortuatenly STK upstream refuses to commit to semversioning their library,
> and instead attaches the release-version to the libraryname,
> following best practices as laid out in
> .
> 
> In any case, the Debian package has so far followed this scheme (which 
> requires
> a new binary package for every non-minor release), and the plan is
> to continue to do so (upstream is not very active these days).
> 
> The new library name requires a transition for the reverse dependencies.
> 
> I've done a test-build of the rdeps using 'ratt', and have not encountered any
> problems (the project's API is pretty stable)
> 
> Thanks for scheduling a transition.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1074232: transition: stk

[IOhannes m zmoelnig]

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

The latest version of STK fixes #1051564.
Unfortuatenly STK upstream refuses to commit to semversioning their library,
and instead attaches the release-version to the libraryname,
following best practices as laid out in
.

In any case, the Debian package has so far followed this scheme (which requires
a new binary package for every non-minor release), and the plan is
to continue to do so (upstream is not very active these days).

The new library name requires a transition for the reverse dependencies.

I've done a test-build of the rdeps using 'ratt', and have not encountered any
problems (the project's API is pretty stable)

Thanks for scheduling a transition.

mfardy
IOhannes


Ben file:

title = "stk";
is_affected = .depends ~ "libstk-4.6.2" | .depends ~ "libstk-5.0.0";
is_good = .depends ~ "libstk-5.0.0";
is_bad = .depends ~ "libstk-4.6.2";

Bug#1074231: nmu: Temporary dcmtk ABI breakage

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: Debian Med Packaging Team 


# autopkgtests caught that my original CVE fixes in 3.6.7-14 broke ABI,
# this is now fixed in 3.6.7-15
#
# rebuild everything that was built with the broken version
#
# further information is in #1070207
#
nmu mia_2.4.7-13 . ANY . unstable . -m "Rebuild against dcmtk 3.6.7-15"
nmu odin_2.0.5-6 . ANY . unstable . -m "Rebuild against dcmtk 3.6.7-15"
nmu openimageio_2.5.12.0+dfsg-2 . ANY . unstable . -m "Rebuild against dcmtk 
3.6.7-15"
nmu orthanc_1.12.4+dfsg-1 . ANY . unstable . -m "Rebuild against dcmtk 3.6.7-15"
nmu orthanc-dicomweb_1.17+dfsg-1 . ANY . unstable . -m "Rebuild against dcmtk 
3.6.7-15"
nmu sight_23.1.0-3 . amd64 . unstable . -m "Rebuild against dcmtk 3.6.7-15"

Bug#1073128: [Pkg-clamav-devel] Bug#1073128: clamav: unaligned access on armhf architecture

[Sebastian Andrzej Siewior]

On 2024-06-13 09:34:14 [+0200], Gianfranco Costamagna wrote:
> Hello, in Ubuntu, where the kernel is configured to forbid unaligned accesses 
> on armhf, the package FTBFS
> (this should be reproducible also on some Debian buildd machines, this is why 
> I'm reporting as serious severity)

Isn't ARMv6+ double of unaligned access? armhf requires VFP so that
should be something later. Or am I wrong here?

> example of failure:
> https://launchpadlibrarian.net/734963041/buildlog_ubuntu-oracular-armhf.clamav_1.3.1+dfsg-3ubuntu1_BUILDING.txt.gz
…
> The following patch makes sure the unaligned access is fixed:
> 
> Description: resolve armhf failure to build from source.

Instead of arguing with me, you could forward it directly to upstream
and give a pointer to apply whatever upsteams did.

> Author: Vladimir Petko 

> --- a/libclamav/special.c
> +++ b/libclamav/special.c
> @@ -48,7 +48,8 @@
> 
>  int cli_check_mydoom_log(cli_ctx *ctx)
>  {
> -const uint32_t *record;
> +const uint32_t record[16];
> +const uint32_t mask = 0x;
please get rid of mask and add your data pointer here.

>  uint32_t check, key;
>  fmap_t *map = ctx->fmap;
>  unsigned int blocks = map->len / (8 * 4);
> @@ -59,14 +60,20 @@
>  if (blocks > 5)
>  blocks = 5;
> 
> -record = fmap_need_off_once(map, 0, 8 * 4 * blocks);
> -if (!record)
> +// returns unaligned memory block
> +const char* data = fmap_need_off_once(map, 0, 8 * 4 * blocks);
> +if (!data)
>  return CL_CLEAN;
> +
>  while (blocks) { /* This wasn't probably intended but that's what the 
> current code does anyway */
> -if (record[--blocks] == 0x)
> +unsigned int offset = --blocks;
> +offset *=sizeof(uint32_t);
> +// safe (but slow) on unaligned memory
> +if (!memcmp([offset], , sizeof(uint32_t)))
>  return CL_CLEAN;

something like
|  while (blocks) { /* This wasn't probably intended but that's what the 
current code does anyway */
| uint32_t local;
|
| memcpy(, [--blocks * sizeof(uint32_t)], sizeof(uint32_t));
| if (local == 0x)
|  return CL_CLEAN;

I am halfway tempted to suggest a packed-wrapper but this would be best
to consult upstream first.

>  }
> -
> +// copy into aligned array to perform bit operations
> +memcpy(record, data, sizeof(record));
>  key   = ~be32_to_host(record[0]);
>  check = (be32_to_host(record[1]) ^ key) +
>  (be32_to_host(record[2]) ^ key) +

Sebastian

Bug#1074230: orgguide.info.gz is not visible in Emacs Info

[Morten Kjeldgaard]

Package: org-mode-doc

Version: 9.5.2-1

After installing org-mode-doc on bookworm, the Org Guide item is not 
visible from inside Emacs after calling the Info system using C-h i. 
Emacs simply says:


    Info file 'orgguide' does not exist; consider installing it.

The problem can be solved by copying the orgguide.info.gz file to 
/usr/share/info:


    sudo cp /usr/share/doc/org-mode-doc/orgguide.info.gz /usr/share/info


The maintainers of the package should consider creating a link to 
orgguide.info.gz in /usr/share/info. Many other files in that directory 
are links to /etc/alternatives, I don't know if that is necessary.

Bug#1074229: Consider building with parallel interface enabled

[taokann.one]

Package: avrdude
Version:7.1+dfsg-3+b2 Dear maintainer, In the 'avrdude' package provided in 
Debian, parallel programmers support is disabled. Indeed, this is off by 
default. It has to be enabled as a build option to work. Enabling 
parallel programmers support is not harmful in any way to a computer 
without a parallel port. The said programmers just show up in the list 
(avrdude -c ?) but are unusable. However, this option off prevents using 
those programmers even if a parallel port is available. You can't bring 
them back using the config file, avrdude has to be rebuilt with the 
option on. I suggest the Debian package enables parallel programmers 
support in avrdude. When using build.sh provided by upstream, line 67 
has to be uncommented. When building with Cmake, it can be done passing 
"-D HAVE_PARPORT=1".

Bug#1067858: reset SuperSpeed USB device number 2 using xhci_hcd

[Diederik de Haas]

On Saturday, 22 June 2024 13:02:24 CEST Pierre Tomon wrote:
> Control: tags -1 + fixed-upstream
> 
> This bug is now fixed upstream.
> 
> Commit: 7926d51f73e0 - scsi: sd: Use READ(16) when reading block zero on
> large capacity disks Releases: v6.1.95, v6.6.35 and v6.9.6

That's awesome. Great work!

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

Bug#1074228: odoo: CVE-2024-4367 – Arbitrary JavaScript execution in PDF.js

[Martina Ferrari]

Package: odoo
Version: 14.0.0+dfsg.2-7+deb11u1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: t...@debian.org, Debian Security Team 

Hi,

See details of vulnerability at:

https://codeanlabs.com/blog/research/cve-2024-4367-arbitrary-js-execution-in-pdf-js/

Note that I am not currently using the Debian version of the Odoo package, but
I noticed this issue when investigating the possibility of switching from the
Odoo-provided package.

All versions currently in Debian seem to be affected by this, as they embed
version 2.2.228 of PDFjs:

https://sources.debian.org/src/odoo/14.0.0%2Bdfsg.2-7%2Bdeb11u1/addons/web/static/lib/pdfjs/build/pdf.js/#L126
https://sources.debian.org/src/odoo/16.0.0%2Bdfsg.2-2/addons/web/static/lib/pdfjs/build/pdf.js/#L126

This vulnerability has been corrected in 4.2.67,
alternatively there seems to be a simple workaround described in:

https://github.com/mozilla/pdf.js/discussions/18168

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#1073981: tmux: entering copy mode is very slow with large history

[Romain Francoise]

My patch was accepted upstream; please test again with 3.4-7 when that
reaches your machine.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1074227: goldencheetah: Unsatisfiable build-dependencies

[Patrick Franz]

Package: goldencheetah
Version: 1:3.5-5
Severity: serious
X-Debbugs-Cc: delta...@debian.org

Dear Maintainer,

your package has unsatisfiable build-dependencies, specifically
libqt5widgets5 and libqt5concurrent5.
These packages have been superseded by libqt5widgets5t64 and
libqt5concurrent5t64 respectively.

Build-depending on them is neither necessary nor recommended as the
corresponding packages are pulled automatically by qtbase5-dev.


--
Regards

Patrick Franz

Bug#1074226: sonic-visualiser: FTBFS on armel/armhf

[Patrick Franz]

Package: sonic-visualiser
Version: 4.5.2-2
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: delta...@debian.org

Dear Maintainer,

your package FTBFS on armel/armhf is therefore stuck on unsatisfiable
dependencies. See
https://buildd.debian.org/status/fetch.php?pkg=sonic-visualiser=armel=4.5.2-2%2Bb3=1713251413=0
and
https://buildd.debian.org/status/fetch.php?pkg=sonic-visualiser=armhf=4.5.2-2%2Bb3=1713249425=0


--
Regards

Patrick Franz

Bug#1074014: encode mandatory merged-/usr into policy

[Luca Boccassi]

On Sat, 22 Jun 2024 13:34:23 +0200 Chris Hofstaedtler 
wrote:
> On Sat, Jun 22, 2024 at 09:42:27AM +0200, Helmut Grohne wrote:
> > [..] he came up with a crazy solution where mksh's data.tar
contains
> > ./bin/mksh but not ./bin on the grounds that ./bin is provided by
an
> > essential package in all Debian releases.
> 
> > I think this approach practically solves a significant chunk of the
> > problems listed by DEP17, but it still confuses QA tools and e.g.
> > dpkg -S (maybe more). [..]
> 
> A fully working, unconfused, dpkg is part of what we want. In my
> understanding, we are trying to ship a distribution, IOW a set of
> packages that work *together*.
> 
> If a confused dpkg was okay, then a lot of the work could have been
> skipped.

+1

-- 
Kind regards,
Luca Boccassi


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

Bug#1074225: RM: watchcatd -- RoQA; dead upstream, obsolete

[Moritz Muehlenhoff]

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

Please remove watchcatd. It's dead upstream and generally obsolete,
such process supervision is built into systemd natively.

Bug#1074224: crossfire FTBFS with Python 3.12 as default

[Adrian Bunk]

Source: crossfire
Version: 1.75.0-6
Severity: serious
Tags: ftbfs
Forwarded: 
https://sourceforge.net/p/crossfire/crossfire-server/ci/472dd26ac74419baa0e6373cb04e095437e994c6/

https://buildd.debian.org/status/fetch.php?pkg=crossfire=arm64=1.75.0-6%2Bb3=1719233376=0

...
cfpython_archetype.c:136:5: note: (near initialization for 
‘Crossfire_ArchetypeType.tp_vectorcall_offset’)
cjson.c: In function ‘encode_unicode’:
cjson.c:700:9: error: implicit declaration of function ‘PyUnicode_AS_UNICODE’; 
did you mean ‘PyUnicode_AsUCS4’? [-Werror=implicit-function-declaration]
  700 | s = PyUnicode_AS_UNICODE(unicode);
  | ^~~~
  | PyUnicode_AsUCS4
cjson.c:700:7: warning: assignment to ‘Py_UNICODE *’ {aka ‘unsigned int *’} 
from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
  700 | s = PyUnicode_AS_UNICODE(unicode);
  |   ^
cjson.c:701:12: error: implicit declaration of function ‘PyUnicode_GET_SIZE’; 
did you mean ‘PyDict_GET_SIZE’? [-Werror=implicit-function-declaration]
  701 | size = PyUnicode_GET_SIZE(unicode);
  |^~
  |PyDict_GET_SIZE
...

Bug#1074127: gnupg2: write_status_text_and_buffer fails to escape some non-printable characters

[Baptiste Beauplat]

On Mon, 2024-06-24 at 18:43 +0200, Andreas Metzler wrote:
> Thank you, I have forwarded this to the upstream tracker.

Thanks a lot.

To give out a bit more context, we got an python Exception on
mentors.debian.net triggered by an upload, signed by sq (Sequoia).

The tool apparently adds a random binary salt to the signature as
notation data, which is then present in the status output.

We read the status output as utf-8 encoded data (perhaps wrongfully)
and python failed to decode the output because the salt was neither
escaped properly nor valid utf-8 output.

I do expect we will not be the only one affected by this issue.

I'd like to point out that other function in gpg seem to escape char
over 127 (such as in `print_hashline` from `g10/gpg.c`).

Best,
-- 
Baptiste Beauplat



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

Bug#1074223: trixie: please document samba package changes

[Michael Tokarev]

Package: release-notes
Severity: normal
Tags: patch
X-Debbugs-Cc: pkg-samba-de...@lists.alioth.debian.org

There are a few changes in samba packaging for trixie which are worth
mentioning in the release notes.  The changes are mentioned in the NEWS
files in the package.

samba (2:4.20.1+dfsg-2) unstable; urgency=medium

  Active Directory Domain Controller (AD-DC) functionality has been split out
  of main samba (the file server) package into its own separate package named
  samba-ad-dc.  This includes the samba binary, the startup files and a few
  support executables.  Please additionally install samba-ad-dc  package if
  you need AD-DC functionality on your system.

 -- Michael Tokarev   Sun, 26 May 2024 13:44:07 +0300

samba-vfs-modules (2:4.20.2+dfsg-3) unstable; urgency=medium

  samba-vfs-modules package has been dropped in this release.
  Instead, all common vfs modules are now part of regular samba
  package, so are always installed (so there is not need to install
  samba-vfs-modules for, say, wide links = yes to work, ad-dc always
  works too and so on).

  At the same time, glusterfs and ceph vfs modules are now shipped in
  their own separate packages, samba-vfs-glusterfs and samba-vfs-ceph
  (samba-vfs-glusterfs in universe in ubuntu).  If you need ceph or
  glusterfs functionality, please install samba-vfs-ceph and/or
  samba-vfs-glusterfs package(s) separately.

 -- Michael Tokarev   Mon, 24 Jun 2024 12:48:23 +0300


While samba-vfs-modules removal is not actually very important to have
in the release notes, but samba-ad-dc becoming required for the AD-DC
functionality is definitely worth mentioning.  Plus the split of the
two vfs modules packages.

It would be nice if this is mentioned for trixie.

Thanks,

/mjt

Bug#1074222: pycorrfit FTBFS with Python 3.12 as default

[Adrian Bunk]

Source: pycorrfit
Version: 1.1.7+dfsg-2
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/logs.php?pkg=pycorrfit=1.1.7%2Bdfsg-2%2Bb2

...
running egg_info
/usr/lib/python3/dist-packages/setuptools/command/egg_info.py:131: 
SetuptoolsDeprecationWarning: Invalid version: 'unknown'.
!!



Version 'unknown' is not valid according to PEP 440.

Please make sure to specify a valid version for your package.
Also note that future releases of setuptools may halt the build process
if an invalid version is given.

This deprecation is overdue, please update your project and remove 
deprecated
calls to avoid build errors in the future.

See https://peps.python.org/pep-0440/ for details.



!!
  return _normalization.best_effort_version(tagged)
Traceback (most recent call last):
  File "/<>/setup.py", line 54, in 
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 107, in 
setup
return distutils.core.setup(**attrs)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 
185, in setup
return run_commands(dist)
   ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 
201, in run_commands
dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
969, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, in 
run_command
super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
988, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/command/build.py", 
line 131, in run
self.run_command(cmd_name)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 318, 
in run_command
self.distribution.run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, in 
run_command
super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
988, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", line 
65, in run
self.build_package_data()
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", line 
161, in build_package_data
for target, srcfile in self._get_package_data_output_mapping():
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", line 
153, in _get_package_data_output_mapping
for package, src_dir, build_dir, filenames in self.data_files:
  ^^^
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", line 
74, in __getattr__
self.data_files = self._get_data_files()
  ^^
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", line 
86, in _get_data_files
self.analyze_manifest()
  File "/usr/lib/python3/dist-packages/setuptools/command/build_py.py", line 
183, in analyze_manifest
self.run_command('egg_info')
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 318, 
in run_command
self.distribution.run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, in 
run_command
super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
987, in run_command
cmd_obj.ensure_finalized()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 111, 
in ensure_finalized
self.finalize_options()
  File "/usr/lib/python3/dist-packages/setuptools/command/egg_info.py", line 
225, in finalize_options
parsed_version = packaging.version.Version(self.egg_version)
 ^^^
  File 
"/usr/lib/python3/dist-packages/setuptools/_vendor/packaging/version.py", line 
198, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
setuptools.extern.packaging.version.InvalidVersion: Invalid version: 'unknown'
E: pybuild pybuild:389: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py build 
dh_auto_build: error: pybuild --build -i python{version} -p 3.12 returned exit 
code 13
make[1]: *** [debian/rules:49: override_dh_auto_build] Error 25

Bug#1026957: (no subject)

[Patrick Franz]

Hi,

I'm raising the severity to serious as the explicit dependency to
libqt6core6 causes the package to have unsatisfiable dependencies.

The package libqt6core6 has been superseded by libqt6core6t64. And as 
already mentioned, these explicit dependencies to the Qt libraries 
should not be needed.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1074135: lintian: error due to login no longer being Essential:yes

[Chris Hofstaedtler]

On Sun, Jun 23, 2024 at 06:10:49PM +0200, Guillem Jover wrote:
> Since shadow 1:4.15.1-1, the login package is no longer Essential:yes,
> instead it is now Protected:yes.

Because rouca asked on IRC: shadow in unstable is indeed not
Essential:yes anymore. It will take a few more days to be sure that
this is okay, but I intend to have it that way for trixie.

Chris

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

[Ernesto Alfonso]

Thank you Gregor, it would definitely work. It would also be nice to be
able to remove the bundled plugin after clicking "remove plugin", and this
may be a separate issue.

Ernesto

On Mon, Jun 24, 2024 at 4:42 AM Gregor Riepl  wrote:

> Hi Ernesto,
>
> > Any time I open cura, I see two annoying popup messages:
> ...
> > - clicking the "Remove plugin" button in the popup
> > - attempting the "pip install trimesh" workaround
> > - clicking "Marketplace -> Installed", unchecking the two problematic
> plugins
> ...
> > None of these solutions appears to have any effect.
>
> Yes, that's a well-known issue. Sorry about that...
>
> > I saw a reference somewhere to the package python3-trimesh, but
> "apt-cache search trimesh" returned no results, and the package doesn't
> seem to exist.
>
> The problem with trimesh is that it relies on partially undefined behavior
> in numpy, which causes it to behave incorrectly on 32-bit architectures.
>
> See the ITP bug here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950920
> My patch for the issue doesn't use the correct types, and I'd prefer not
> having to maintain it myself in the end. The issue should be fixed in
> numpy, IMHO.
>
> There is one possible solution that would make most users happy, however:
>
> - Factoring out the two Cura plugins into a separate package
> - Adding a Recommends: dependency on this package to Cura
> - Making the package runtime-depend on python3-trimesh
> - Packaging trimesh for 64-bit archs only
>
> I haven't checked if this would actually work, but I think it's the
> correct solution until the numpy developers have figured out a solution for
> the typing issue.
>
> Would that work for you?
>
> Regards,
> Gregor
>

Bug#1073069: magic-wormhole: Fails to build with Python 3.12

[Jeremy Bícha]

Control: severity -1 serious

On Wed, Jun 12, 2024 at 2:01 PM Jeremy Bícha  wrote:
> Source: magic-wormhole
> Version: 0.13.0-1
> Severity: important
> Tags: ftbfs
>
> magic-wormhole 0.13.0-1 fails to build when the default Python 3 is
> switched to 3.12 (as was done with Ubuntu 24.04 LTS and will happen in
> Debian "soon").
>
> This issue is fixed in magic-wormhole 0.14.0 so I recommend upgrading
> to that version.
>
> You can also close LP: #2068774 with your upload.
> https://launchpad.net/bugs/2068774

The Python 3.12 transition has begun so I'm raising the severity.

Thank you,
Jeremy Bícha

Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package

[Matthijs Kooijman]

Hi James,

> The relevant CMake file addition was sourced[1] from the LLVM codebase, which
> is licensed under a variant of the Apache 2.0 license with some exception
> clauses added for the LLVM project.  This is not yet documented in the source
> package.

Thanks for pointing this out.

It turns out I've failed to update the copyright file for some other
included code as well. I'm preparing an upload to fix this now.

> To explain my reasoning: On balance I'd prefer opening a serious-severity bug
> to prevent migration (that could later be reduced in severity) than to allow
> the package transition while being aware of a potential problem.
Yes, makes sense!

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#1074221: morph-browser: FTBFS on mips64el

[Patrick Franz]

Package: morph-browser
Version: 1.1.0+dfsg-2
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: delta...@debian.org

Dear Maintainer,

your package fails to build on mips64el and can therefore not migrate
to testing. See
https://buildd.debian.org/status/fetch.php?pkg=morph-browser=mips64el=1.1.0%2Bdfsg-2=1716667926=0


--
Regards

Patrick Franz

Bug#1074220: scribus: Fails to build with Python 3.12

[Jeremy Bícha]

Source: scribus
Version: 1.5.8+dfsg-5
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

scribus fails to build with Python 3.12. In Ubuntu, this was fixed by
updating scribus to 1.6.1 (and now 1.6.2).

Build log excerpt
--
/<>/scribus/plugins/scriptplugin/cmdgetsetprop.cpp: In
function ‘PyObject* scribus_setproperty(PyObject*, PyObject*,
PyObject*)’:
/<>/scribus/plugins/scriptplugin/cmdgetsetprop.cpp:413:84:
error: ‘PyUnicode_AS_UNICODE’ was not declared in this scope; did you
mean ‘PyUnicode_AsUCS4’?
  413 | const unsigned short * ucs2Data =
(const unsigned short *) PyUnicode_AS_UNICODE(objValue);
  |
^~~~
  |
PyUnicode_AsUCS4
/<>/scribus/plugins/scriptplugin/cmdgetsetprop.cpp:433:84:
error: ‘PyUnicode_AS_UNICODE’ was not declared in this scope; did you
mean ‘PyUnicode_AsUCS4’?
  433 | const unsigned short * utf16Data =
(const unsigned short *)PyUnicode_AS_UNICODE(objValue);
  |
^~~~
  |
PyUnicode_AsUCS4
make[3]: *** 
[scribus/plugins/scriptplugin/CMakeFiles/scriptplugin.dir/build.make:173:
scribus/plugins/scriptplugin/CMakeFiles/scriptplugin.dir/cmdgetsetprop.cpp.o]
Error 1

Full build logs

https://buildd.debian.org/status/package.php?p=scribus

Thank you,
Jeremy Bícha

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

[Christoph Berg]

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

That wouldn't be a problem.

Christoph

Bug#1074219: eln: Build-Depends on unsatisfiable dependencies on armel/mips64el/ppc64el/s390x

[Patrick Franz]

Package: eln
Version: 1.5.4-1
Severity: serious
X-Debbugs-Cc: delta...@debian.org

Dear Maintainer,

your package build-depends on qt6-pdf-dev, 
qml6-module-qtwebengine-controlsdelegates
and qml6-module-qtwebengine on armel/mips64el/ppc64el/s390x.
However, these packages only exist on amd64/arm64/armhf/i386.

This prevents the packages from being built on these architectures and thus from
migrating to testing.


--
Regards

Patrick Franz

Bug#1074218: dogecoin: FTBFS because of symbol errors

[Patrick Franz]

Package: dogecoin
Version: 1.14.7-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: delta...@debian.org

Dear Maintainer,

the package FTBFS on amd64 due to symbol errors. See
https://buildd.debian.org/status/fetch.php?pkg=dogecoin=amd64=1.14.7-1=1716846348=0

--
Regards

Patrick Franz

Bug#1073509: sbuild-qemu-update works, but increases image allocated size each time

[Christian Kastner]

On 2024-06-22 12:49, Francesco Poli wrote:
> On Fri, 21 Jun 2024 00:42:21 +0200 Christian Kastner wrote:
>> In this particular case, one factor would be that the update caused new
>> APT lists to be downloaded, which have tens of MB.
> 
> How so?
> 
> As I said in the [original] bug report, I tried to run
> sbuild-qemu-update on the image that I had just regenerated from
> scratch. It seems that it found nothing to update, not even the APT
> repository lists (which were already up-to-date, as expected). Please
> take a look at the output of sbuild-qemu-update in the [original] bug
> report...

Indeed. Sorry, I replied with gut instinct here.

> Come on, I am sure you are clever enough to figure out a good strategy
> to automatically prevent the image allocated size from growing
> indefinitely!

Apparently, there is a trick after all.

(1) sbuild-qemu-{boot,update} need to add discard=unmap to the block
device options of the image
(2) In the guest,
  (2a) the root partition needs to be remounted with discard
  (2b) fstrim /
(3) On the host, qemu-img convert -O qcow2 foo.img bar.img

At least on my end, this reduced the image size.

fstrim was the only solution I could find that could trigger TRIMs on a
mounted filesystem.

I've pushed a fix implementing this. It seems safe enough, though I
wonder if I shouldn't have guarded this with a --shrink option.

Best,
Christian

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

Package: dpkg-dev
Followup-For: Bug #872381

Hello again.
My last message was confusing.

I am suggesting to improve commit f1175056 with
0001-build-spare-an-unneeded-subst-handling-in-pkg-info.m.patch.

I have only quoted 0001-scripts-mk-stop-hard-coding-dpkg_datadir.patch
for context. Please ignore it.

Bug#1072965: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.256.02-1~deb11u1

[Adam D. Barratt]

On Mon, 2024-06-24 at 11:28 +0200, Andreas Beckmann wrote:
> On 22/06/2024 10.46, Adam D. Barratt wrote:
> > On Sat, 2024-06-22 at 01:10 +0200, Andreas Beckmann wrote:
> > > On 21/06/2024 19.05, Adam D. Barratt wrote:
> > > > On Tue, 2024-06-11 at 02:02 +0200, Andreas Beckmann wrote:
> > > > > A new upstream release of the nvidia drivers in non-free is
> > > > > needed
> > > > > for fixing a few new CVEs.
> > > > 
> > > > The ppc64el build failed:
> > > > 
> > > > FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only
> > > > symbol 'rcu_read_unlock_strict'
> > > > make[5]: *** [/usr/src/linux-headers-5.10.0-30-
> > > > common/scripts/Makefile.modpost:123: /<>/kernel-
> > > > source-tree/Module.symvers] Error 1
> > > 
> > > OK, I can reproduce that with linux-headers-5.10.0-30-powerpc64le
> > > but
> > > not with linux-headers-5.10.0-28-powerpc64le (nor with
> > > linux-headers-6.8.12-powerpc64le)
> > 
> > "Yay".
> 
> This happened:
> 
> There are two commits in 6.8 that modify (the arch independent) 
> pfn_valid() in include/linux/mmzone.h to fix race conditions:
> 
> 5ec8e8ea8b7783fab150cf86404fc38cb4db8800 (v6.8-rc1)
> introduces usage of rcu_read_lock()/rcu_read_unlock()
> (which are (transitively) GPL-only symbols)
> 
> f6564fce256a3944aa1bc76cb3c40e792d97c1eb (v6.8-rc3)
> switches that to rcu_read_lock_sched()/rcu_read_unlock_sched()
> (which are not)
> 
> Both commits got backported to Linux 6.1 (in bookworm) in 
> v6.1.76/v6.1.77 but so far only the first got backported to Linux
> 5.10 (in bullseye) in v5.10.210.
> I just filed #1074170 for the potentially missing backport in the 
> bullseye-pu kernel.
> 
> While the nvidia driver stopped using pfn_valid() in 470.239.06, it 
> still uses the (arch specific) virt_addr_valid() macro.
> 
> On ppc64el (arch/powerpc/include/asm/page.h) this macro calls the
> arch independent pfn_valid() (which is transitively GPL-only).
> 
> On amd64 (arch/x86/include/asm/page.h) this macro uses 
> EXPORT_SYMBOL(__virt_addr_valid) from arch/x86/mm/physaddr.c
> 
> On arm64 (arch/arm64/include/asm/memory.h) this macro calls the arch 
> specific pfn_valid() (due to CONFIG_HAVE_ARCH_PFN_VALID=y).
> 
> I'm adding a patch that (on ppc64el only) for Linux >= 5.10.210 &&
> Linux < 5.11 introduces nv_pfn_valid() which is the pfn_valid() from 
> 5.10.210 + the changes from f6564fce256a3944aa1bc76cb3c40e792d97c1eb
> as well as nv_virt_addr_valid() which uses it.
> 
> It has only slightly been tested:
> - building a module for linux-headers-5.10.0-30-powerpc64le now
> succeeds
> - building a module for linux-headers-5.10.0-28-powerpc64le
> (5.10.209) 
> still succeeds
> - building a module for linux-headers-5.10.0-30-amd64 still succeeds 
> (patch is theoretically a no-op on amd64)
> - untested on arm64, but patch is theoretically a no-op on arm64
> 
> I'm not routing this patch through sid and bookworm for now,
> therefore the versions of the bullseye uploads (just done) are
> - nvidia-graphics-drivers 470.256.02-2
> - nvidia-graphics-drivers-tesla-470 470.256.02-1~deb11u2
> Do you need separate opu requests for these?

Nope, as they're regression fixes to the versions currently in (o-)p-u,
that's not required.

It looks like the -2 update has fixed the issues on ppc64el at least;
thanks.

Regards,

Adam

Bug#1071098: onboard: failing build tests

[Jeremy Bícha]

Control: retitle -1 onboard: failing build tests
Control: severity -1 serious
Control: tags -1 -patch

This affects all the architectures and is blocking the completion of
the Python 3.12 transition. I'm dropping the patch tag since the
provided patch won't help much.

I pushed another build test fix to Salsa but I'm not sure yet on how
to deal with this build failure.

Thank you,
Jeremy Bícha

Bug#1074115: gudhi: FTBFS with CGAL 6.0

[Joachim Reichel]

Thanks for the heads up. The upcoming 3.10 release of GUDHI will support
CGAL 6.0, and should be out soon [1]. I'll get it packaged as soon as
it's out (the RC cycle for GUDHI is usually merely a matter of days).


Ok, very good.


PS: I see this bug was filed against GUDHI versions starting with the
one in Bookworm. Does that make sense? Is there an expectation to be
able to compile the Bookworm version of GUDHI with a not-yet-in-Trixie
version of CGAL?


No, please ignore that version, unstable is sufficient. I was using reportbug 
from a stable system and forgot to enter the version numbers from unstable. I'll 
try later to fix the version numbers (happened also to other bugs for that 
transition).


  Joachim

Bug#1074127: gnupg2: write_status_text_and_buffer fails to escape some non-printable characters

[Andreas Metzler]

Control:

forwarded -1 https://dev.gnupg.org/T7176

On 2024-06-23 Baptiste Beauplat  wrote:
> Source: gnupg2
> Severity: important
> Tags: patch upstream
> X-Debbugs-Cc: lykn...@debian.org

> Dear maintainer,

> The check for escaping characters in `write_status_text_and_buffer` is
> written in  `g10/cpr.c` as:

> ```c
> 333   if (*s == '%' || *(const byte*)s <= lower_limit
> 334   || *(const byte*)s == 127 )
> ```

> Except `byte` is defined as an unsigned char, with non-printable values
> exceeding 127.

> Therefor the check should be `>= 127` and not `== 127`.
[...]

Thank you, I have forwarded this to the upstream tracker.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1029032: Package (almost) ready

[Adrien Nader]

HI László,

Apologies, I was busy on other topics and I had gotten some initial
comments on the packaging too (d/copyright needing tweaks).

I can't upload and would appreciate sponsoring.

I've updated the packaging in the git repository:

https://salsa.debian.org/adrien-n/python-google-api-core/-/tree/sid?ref_type=heads

I've updated d/copyright and the packaging is lintian-clean. Julian has
also tested the package and confirmed it working with new
python-googleapi versions.

Thanks,

-- 
Adrien

Bug#1055780: apt-listchanges: Probably needs special handling for linux/linux-signed

[Andreas Metzler]

On 2023-11-11 Andreas Metzler  wrote:
> Package: apt-listchanges
> Version: 4.4
> Severity: normal

> Hello,

> linux seems to do strange things with its changelogs:
[...]

Having gone back to 3.x a couple of weeks ago made me realize again how
severe this bug is, any kernel update caused absurdely huge (about 2 MB) old 
changelogs to be shown. I think this justifies to be considered RC.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1074217: ppc64el default page size too large for typical use cases

[Timothy Pearson]

Package: linux-image-powerpc64le
Severity: normal

Debian has traditionally built the ppc64el kernel with a 64k page size, however 
this decision comes with a number of drawbacks.  Much like arm64, the 
underlying ppc64el hardware supports either 4k or 64k page sizes, and the 
selection of which page size to use is largely application-specific.  Notably, 
Ubuntu has acknowledged this in recent months by offering both 64k and 4k 
kernel builds for their arm64 SBSA servers, with the "largemem" 64k variant 
targetted specifically at database, machine learning, etc.

Since ppc64el is the only higher-tier architecture in the archive that is built 
exclusively for 64k pages, it is unneccesarily exposed to various bugs that are 
not present on a 4k build, in addition to experiencing decreased performance in 
many common workloads (JIT-heavy applications such as node.js, Web browsing, 
etc.)

I would propose that Debian at minimum offer a separate 4k kernel image for 
ppc64el that could be installed instead of the default 64k page kernel.  Most 
appications will automatically detect the page size change and use the 4k pages 
available, and the few that do not will continue to function at essentially the 
same or slightly worse performance level as they did on the 64k page kernel.  
This change would be relatively trivial to implement, and if there is agreement 
on this direction I can put the required patches together.

Bug#1074216: kitty FTBFS with Python 3.12 as default

[Adrian Bunk]

Source: kitty
Version: 0.35.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=kitty=0.35.1-1%2Bb1

...
==
FAIL: test_ssh_leading_data (kitty_tests.ssh.SSHKitten.test_ssh_leading_data) 
(sh='python3')
--
Traceback (most recent call last):
  File "/<>/kitty/launcher/../../kitty_tests/ssh.py", line 167, in 
test_ssh_leading_data
self.ae(pty.screen_contents(), 'UNTAR_DONE\nld:before_tarfile')
pty = 
script = 'print("ld:" + leading_data.decode("ascii")); raise SystemExit(0);'
self = 
sh = 'python3'
tdir = '/tmp/tmpj2ma30as'
AssertionError: 'bootstrap.py:214: DeprecationWarning: Pyt[180 chars]file' != 
'UNTAR_DONE\nld:before_tarfile'
- bootstrap.py:214: DeprecationWarning: Python 3.14 will, by default, filter 
extra
- cted tar archives and reject files or modify their metadata. Use the filter 
argu
- ment to control this behavior.
  UNTAR_DONE
  ld:before_tarfile


--
Ran 144 tests in 68.976s

FAILED (failures=1, skipped=2)
Error: Some tests failed!
make[1]: *** [debian/rules:60: override_dh_auto_test] Error 1

Bug#1071456: 1071456: duplicate of 1072004

[Chris Hofstaedtler]

affects 1072004 autopkgtest
thanks

#1071456 is caused by #1072004 in the kernel. Keeping it here so
other people can find #1072004.

Chris

Bug#1074176: packages.debian.org: allow seeing files

[Soren Stoutner]

You are probably looking for this URL:

https://sources.debian.org/src/gdal/3.9.1~rc2%2Bdfsg-1~exp1/[1]

On Monday, June 24, 2024 4:22:49 AM MST Dan Jacobson wrote:
> Package: general
> 
> Here we are looking at a list of files,
> https://packages.debian.org/experimental/amd64/gdal-bin/filelist
> but cannot click them to see their contents.


-- 
Soren Stoutner
so...@debian.org


[1] https://sources.debian.org/src/gdal/3.9.1~rc2%2Bdfsg-1~exp1/


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

Bug#1074215: ITP: yubihsm-shell -- Command-line and interactive tool for the YubiHSM 2

[Colin Watson]

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

* Package name: yubihsm-shell
  Version : 2.5.0
  Upstream Contact: Yubico Open Source Maintainers 
* URL : https://developers.yubico.com/yubihsm-shell/
* License : Apache-2.0
  Programming Lang: C
  Description : Command-line and interactive tool for the YubiHSM 2

The YubiHSM 2 is a Hardware Security Module that is within reach of all
organizations.  It provides advanced cryptography, including hashing,
asymmetric and symmetric key cryptography, to protect the cryptographic keys
that secure critical applications, identities, and sensitive data in an
enterprise for certificate authorities, databases, code signing and more.

This package contains a command-line and interactive tool for working
with a YubiHSM 2.


We're in the process of starting to use a YubiHSM in Freexian.  Upstream
does provide their own Debian packages, but given that there's no
licensing obstacle I'd prefer to have this in Debian.  I have the
hardware and I intend to maintain this as part of
https://salsa.debian.org/pkg-security-team (compare
https://bugs.debian.org/1074007).

The upstream yubihsm-shell source package builds a number of binary
packages (libyubihsm*, libykhsmauth*, yubihsm-pkcs11, yubihsm-shell,
yubihsm-wrap, and yubihsm-auth).  Their layout looks reasonable to me
and I'll try not to be gratuitously incompatible with it.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1074109: RM: rsh-redone -- RoQA; obsolete; unmaintained; will break soon

[Patrik Schindler]

Hello,

> please remove rsh-redone, a reimplementation of rsh. Unfortunately it's been 
> orphaned in Debian in 2020, and upstream also stopped working on it 6 years 
> ago.

While I understand that the lack of a maintainer is a good reason to remove a 
package, "upstream stopped working on it" may be not.

> login will soon drop support for "-h" (= remote logins), then rsh will also 
> be broken.

Any reference on this?

> I hope that all systems have transitioned to ssh in the meantime.

Nope.

I still have use cases in tightly controlled LAN environments where raw 
transfer speed vs. useless CPU cycle burning for encryption is sought after.

Also, there is sometimes compatibility needed to older IBM operating systems in 
the Midrange/Mainframe environment but with a current Linux base.

Pity that those niches are not enough to keep r* commands alive.

Just my $.02.

:wq! PoC

Bug#1074214: fastfetch: please make the build reproducible

[Chris Lamb]

Source: fastfetch
Version: 2.15.0+dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
fastfetch could not be built reproducibly.

This is because it embeds a timezone-varying date in its manual page.
A patch is attached that specifies "UTC" in the CMake file. This
timestamp will be correctly sourced from SOURCE_DATE_EPOCH if present.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

--- a/debian/patches/reproducible-build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-build.patch   2024-06-24 08:11:03.048294988 
-0700
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-06-24
+
+--- fastfetch-2.15.0+dfsg.orig/CMakeLists.txt
 fastfetch-2.15.0+dfsg/CMakeLists.txt
+@@ -254,7 +254,7 @@ if(APPLE)
+ configure_file(src/util/apple/Info.plist.in Info.plist @ONLY)
+ endif()
+ 
+-string(TIMESTAMP FASTFETCH_BUILD_DATE "%d %B %Y")
++string(TIMESTAMP FASTFETCH_BUILD_DATE "%d %B %Y" UTC)
+ configure_file(doc/fastfetch.1.in fastfetch.1 @ONLY)
+ 
+ 
--- a/debian/patches/series 1969-12-31 16:00:00.0 -0800
--- b/debian/patches/series 2024-06-24 08:11:02.120305326 -0700
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)

[Samo Pogačnik]

Hi Daniel,

i prepared another candidate for the 0.4.6-1 release (

https://salsa.debian.org/spog/git-subrepo/-/commit/f96eeedd0e96b6f2bbcc8c013909de5d5325cafe
), hoping it ticks all the boxes and more:)

I made the PR upstream (https://github.com/ingydotnet/git-subrepo/pull/623) and
added 'Forwarded' fields with PR to all five patches. I hope that making a
separate commit for adding 'Forwarded' field to patches is ok.

The 'git-subrepo.d' subdir has been removed upon 'make install' and additional
Makefile adjustment done according to your suggestions.

Regarding internal test suite, things weren't that trivial, as the
implementation requires that the project is a git worktree. However debian
builds from a non-git tarball. I fixed that by git-initializing the project on
the fly, when needed as well as providing local git configuration for all repos
involved in tests. Another thing regarding tests was that they rely upon english
output, so tests failed in reprotest, when executed in a French environment for
example. By setting fixed locale during each test being run, it all went well.

I also went a step further regarding tests. Three test repos being used by
several tests were committed upstream as binary bare git repos, which i really
do not like. So i prepared a few scripts, which generate the same repos with the
same history upon each test suite startup.

best regards, Samo

Bug#1072674: Please upload fmtlib 10 to unstable

[Jordi Mallach]

Hi!

El dj. 06 de 06 de 2024 a les 16:09 +0800, en/na Shengjing Zhu va
escriure:
> Thanks for the reminder. I was about to ask for the transition before
> but then there are archive wide time64 transitions ongoing. Now
> things
> have settled down. I will start to prepare and ask for transition.

Were you able to work on a transition for this? Thanks!

Jordi

-- 
Jordi Mallach 
Debian Project

Bug#1074213: mirror submission for debian.mobinhost.com

[Mobinhost]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.mobinhost.com
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Mobinhost 
Country: IR Iran, Islamic Republic of
Location: Tehran
Sponsor: Mobinhost https://mobinhost.com
Comment: Hello,
 Please added ftp.ir.debian.org assign in ip 87.107.153.51 or CNAME record to 
debian.mobinhost.com
 It should be noted that our mirror is updated every three hours.
 Kind regards




Trace Url: http://debian.mobinhost.com/debian/project/trace/
Trace Url: 
http://debian.mobinhost.com/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.mobinhost.com/debian/project/trace/debian.mobinhost.com

Bug#1074212: matplotlib: build-time test failure is ignored

[Drew Parsons]

Source: matplotlib
Version: 3.8.3-1
Severity: normal

The matplotlib build is failing tests during the transition from 3.7
to 3.8 (for debian, that's from 3.6 to 3.8), when docs are being built
.

The reason is twofold
- upstream changed the import handling of mpl_toolkits (they removed 
__init__.py)
- the doc build has a circular dependency in python3-sphinx-gallery,
which Depends on python3-matplotlib.

If python3-matplotlib 3.6 is installed (as forced by
python3-sphinx-gallery), then when matplot v3.8 tests are run, python
selects the 3.6 version of mpl_toolkits instead of the newly built 3.8
version. Consequently the test run fails (the Axes3D API changed
between 3.6 and 3.8).

The problem is discussed upstream at
https://github.com/matplotlib/matplotlib/issues/26827
It's effectively unavoidable (short of not building docs in order to
avoid python3-sphinx-gallery), we just have to hold our breath and
push through to v3.8.

But in any case this test failure is ignored, and the debian build
goes on to build the packages anyway.

This is actually a "good" thing for the 3.6 → 3.8 transition. We can
build the new packages in spite of the build time test failure.

But in general (after 3.8 or 3.9 is settled in testing), we should
probably check the tests and not ignore failure
e.g. use `set -e` at the beginning of the test block

Bug#1074211: ITP: python-expandvars -- bash-style environment variable expansion in Python

[Colin Watson]

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

* Package name: python-expandvars
  Version : 0.12.0
  Upstream Contact: Arijit Basu 
* URL : https://github.com/sayanarijit/expandvars
* License : MIT
  Programming Lang: Python
  Description : bash-style environment variable expansion in Python

This module is inspired by GNU bash's variable expansion features. It
can be used as an alternative to Python's os.path.expandvars function.

A good use case is reading config files with the flexibility of reading
values from environment variables using advanced features like returning
a default value if some variable is not defined.


This is a new build-dependency of frozenlist 1.4.1.  I intend to
maintain it as part of the Python team.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1058104: astropy-helpers: FTBFS: ModuleNotFoundError: No module named 'imp'

[Ole Streicher]

Hi Boyuan Yang,

On 14.06.24 19:50, Boyuan Yang wrote:

-> % build-rdeps python3-astropy-helpers
Reverse Build-depends in unstable/main:

astroquery
hipspy

Found a total of 2 reverse build-depend(s) for python3-astropy-helpers.

Two reverse-dependencies exist, and both of them are not having active
upstream development. You are also listed as the uploader for them.

If you believe that this issue will not be fixed upstream, please review
the current status of these packages and determine how to proceed. Thanks!


Hipspy is currently unmaintained upstream RC buggy in Debian. Since it 
seems not really abandoned upstream, I still keep it in unstable, having 
some hope that maintenance will resume at some future point. If they 
re-start, the will need to migrate from astropy-helpers in any case, so 
I'd keep the state here as it is. Removing astropy-helpers is therefore 
not a problem here.


For astroquery, I am not an uploader; however I will have a look how to 
update it (it is team maintained anyway). They didn't have the resources 
to migrate away from astropy-helpers yet, and they come with an updated 
local copy of it (because it is abandoned upstream). Using this copy 
would be the way to go here; it is in any case only temporary, and it 
will be the only package that somehow uses astropy-helpers for some 
time. Updating Debian's astropy-helpers instead would not worth the 
effort, and would also send wrong signals to the users to use a clearly 
abandoned package.


Astroquery is still actively maintained on Github; the last commit was 4 
days ago. The development is very close to astropy, so I am confident 
about the future removal of astropy-helpers from astroquery.


I hope that helps to answer your questions?

After I team-updated astroquery, I will write an removal request for 
astropy-helpers.


Best

Ole

Bug#1069641: nmu: uwsgi-plugin-php_0.0.15 uwsgi-plugin-luajit_0.0.8 uwsgi-plugin-mongo_0.0.9

[Alexandre Rossi]

Hi,

Gentle reminder to ask for this to be scheduled, or any blockers to be raised
so that I can fix those.

Thanks,

Alex

--
uwsgi.h changed again, and uwsgi ABI id is derived from that file, so
a rebuild is required for plugins to depend on the correct uwsgi-abi binary
package.

nmu uwsgi-plugin-php_0.0.15  . ANY . unstable . -m "rebuild against new uwsgi.h"
nmu uwsgi-plugin-luajit_0.0.8  . ANY . unstable . -m "rebuild against new 
uwsgi.h"
nmu uwsgi-plugin-mongo_0.0.9  . ANY . unstable . -m "rebuild against new 
uwsgi.h"

Bug#987749:

[Grace Helen]

Did you receive my last message?

Bug#1069317: FTBFS: tests failed

[IOhannes m zmoelnig]

On closer inspection, this seems to be a bug in vamp, rather than 
sonic-visualiser.


E.g. consider the following example program:


```C++
#include "vamp-hostsdk/RealTime.h"
#include 
#include 

int main() {
  Vamp::RealTime t1 = Vamp::RealTime(0, 5);
  struct timeval tv;
  tv.tv_sec = 0; tv.tv_usec = 50;
  Vamp::RealTime t2 = Vamp::RealTime::fromTimeval(tv);
  std::cout << "RealTime(0, ONE_BILLION/2) = " << t1 << std::endl;
  std::cout << "RealTime::fromTimeval(0, ONE_MILLION/2) = " << t2 << 
std::endl;


  if (t1 != t2)
  return 1;

  return 0;
}
```

And run with:
```sh
g++ test.cpp   -o test $(pkg-config --cflags --libs vamp-hostsdk)
./test || echo oops
```

On amd64, this will output
```
RealTime(0, ONE_BILLION/2) =  0.5R
RealTime::fromTimeval(0, ONE_MILLION/2) =  0.5R
```

whereas on armhf, you get
```
RealTime(0, ONE_BILLION/2) =  0.5R
RealTime::fromTimeval(0, ONE_MILLION/2) =  0.0R
oops
```

so obviously RealTime::fromTimeval() is broken on armhf.

gdmasr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071656: autopkgtest failure on archs other than amd64 and i386

[Bernhard Übelacker]

On Thu, 23 May 2024 10:28:52 +0200 Jeroen Ploemen  wrote:

Package: gpscorrelate
Severity: normal
Control: found -1 2.1-1

hi Shriram,

it seems the recent upload of gpscorrelate has issues preventing
migration to testing [1]: the autopkgtest fails for all architectures
except amd64 and i386.



I tried to collect some more informations about this issue.
I could reproduce it inside a Unstable qemu arm64 VM
(running on amd64 hardware).


First it looks like the package build never uses valgrind (-m) [1],
therefore this issue appears just in the autopkgtest, as this always
uses the (-m) [2]. Cannot say if this intentional.

There was a patch pushed to git [3] which explicitly lists valgrind archs.
I stepped over a package valgrind-if-available [4].
Maybe depending on this might be of some help here?


And the issue itself manifests at arm64 in following instruction
with the same input producing a result in register $w5 of
- without valgrind 323,
- with valgrind  322

:   fcvtas  w5, d8

Unfortunately I don't know why this happens, maybe some
floating point initialisation is done in valgrind?

See attached file for complete gdb sessions without and with valgrind.
At the bottom is also a minimal reproducer which showed the difference
with and without valgrind to me.


Kind regards,
Bernhard


[1]
./Makefile:13:CHECK_OPTIONS=
./Makefile-60-check: gpscorrelate$(EXEEXT)
./Makefile:61:  (cd tests && ./testsuite $(CHECK_OPTIONS))

[2]
./debian/tests/upstream-suite:14:./testsuite -m

[3]
https://salsa.debian.org/debian/gpscorrelate/-/commit/818f924c401fcaac4873ff3acb99b614065afc10

[4]
https://packages.debian.org/sid/valgrind-if-available
# Trixie/unstable arm64 qemu VM 2024-06-23

apt build-dep gpscorrelate
apt install mc valgrind gpscorrelate gpscorrelate-dbgsym



mkdir /home/benutzer/source/gpscorrelate/orig -p
cd/home/benutzer/source/gpscorrelate/orig
apt source gpscorrelate

mkdir /home/benutzer/source/glibc/orig -p
cd/home/benutzer/source/glibc/orig
apt source glibc

mkdir /home/benutzer/source/valgrind/orig -p
cd/home/benutzer/source/valgrind/orig
apt source valgrind

mkdir /home/benutzer/source/exiv2/orig -p
cd/home/benutzer/source/exiv2/orig
apt source exiv2

mkdir /home/benutzer/source/libxml2/orig -p
cd/home/benutzer/source/libxml2/orig
apt source libxml2




# tests/data/test167.param

cd /home/benutzer/source/gpscorrelate/try1/gpscorrelate-2.1
cat tests/staging/point1-2.jpg > /tmp/test.jpg
/usr/bin/gpscorrelate --heading --max-heading 90 -O -45 -z 0 -g 
tests/staging/track13.gpx /tmp/test.jpg > /tmp/outfile
exiv2 -pv pr /tmp/test.jpg >> /tmp/outfile

cd /home/benutzer/source/gpscorrelate/try1/gpscorrelate-2.1
cat tests/staging/point1-2.jpg > /tmp/test-valgrind.jpg
valgrind --error-exitcode=126 --tool=memcheck --leak-check=yes --num-callers=30 
--log-file=/tmp/test167-valgrind.log /usr/bin/gpscorrelate --heading 
--max-heading 90 -O -45 -z 0 -g tests/staging/track13.gpx 
/tmp/test-valgrind.jpg > /tmp/outfile-valgrind
exiv2 -pv pr /tmp/test-valgrind.jpg >> /tmp/outfile-valgrind

$ diff -Nurp /tmp/outfile /tmp/outfile-valgrind
--- /tmp/outfile2024-06-23 13:25:35.87200 +
+++ /tmp/outfile-valgrind   2024-06-23 13:26:13.64000 +
@@ -32,6 +32,6 @@ Failed:  0 (0 Not matched, 0 Write f
 0x0006 GPSInfo  GPSAltitude Rational1  4234/10
 0x0007 GPSInfo  GPSTimeStampRational3  12/1 34/1 35/1
 0x000e GPSInfo  GPSTrackRef Ascii   2  T
-0x000f GPSInfo  GPSTrackRational1  323/1
+0x000f GPSInfo  GPSTrackRational1  322/1
 0x0012 GPSInfo  GPSMapDatum Ascii   7  WGS-84
 0x001d GPSInfo  GPSDateStampAscii  11  2012:11:22
$ 













































# Just debugging with GDB


cd /home/benutzer/source/gpscorrelate/orig/gpscorrelate-2.1
cat tests/staging/point1-2.jpg > /tmp/test.jpg
gdb -q --args /usr/bin/gpscorrelate --heading --max-heading 90 -O -45 -z 0 -g 
tests/staging/track13.gpx /tmp/test.jpg
set width 0
set pagination off
b WriteGPSData
run
b 625
cont
b *(ConvertToRational+104)
display/i $pc
cont
print $d8
stepi
print $w5
bt
up
print Point->MoveHeading


benutzer@debian:~/source/gpscorrelate/try1/gpscorrelate-2.1$ cd 
/home/benutzer/source/gpscorrelate/orig/gpscorrelate-2.1
benutzer@debian:~/source/gpscorrelate/orig/gpscorrelate-2.1$ cat 
tests/staging/point1-2.jpg > /tmp/test.jpg
benutzer@debian:~/source/gpscorrelate/orig/gpscorrelate-2.1$ gdb -q --args 
/usr/bin/gpscorrelate --heading --max-heading 90 -O -45 -z 0 -g 
tests/staging/track13.gpx /tmp/test.jpg
Reading symbols from /usr/bin/gpscorrelate...
Reading symbols from 
/usr/lib/debug/.build-id/05/6a4b627d6a584d22788080e79d2e7defc8c4fd.debug...
(gdb) set width 0
(gdb) set pagination off
(gdb) b WriteGPSData
Breakpoint 1 at 0x6324: file ./exif-gps.cpp, line 467.
(gdb) run
Starting program: /usr/bin/gpscorrelate 

Bug#601631: bash-doc: please install NEWS file

[Gioele Barabucci]

Version: 5.0-6

On Wed, 27 Oct 2010 18:36:10 -0500 Jonathan Nieder  
wrote:

I was looking for /usr/share/doc/bash-doc/NEWS.gz to track down a
regression, but it does not seem to exist.  Any reason not to add it?


NEWS.gz is now distributed as part of the bash package:

$ dpkg -S bash/NEWS
bash: /usr/share/doc/bash/NEWS.gz

Regards,

--
Gioele Barabucci

Bug#1074209: php-voku-portable-ascii: FTBFS with pkg-php-tools_1.45+nmu1: Warning: require_once(/usr/share/php/voku/helper/autoload.php): Failed to open stream: No such file or directory in /<

[Athos Ribeiro]

Source: php-voku-portable-ascii
Version: 2.0.1-2
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-voku-portable-ascii was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit --include-path src
> PHP Warning:  require_once(/usr/share/php/voku/helper/autoload.php): Failed 
> to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> 
> Warning: require_once(/usr/share/php/voku/helper/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/voku/helper/autoload.php' 
> (include_path='src:.:/usr/share/php')
> #0 /<>/tests/bootstrap.php(6): require_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once('...')
> #2 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #6 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #7 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #8 {main}
> make[1]: *** [debian/rules:21: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-voku-portable-ascii/php-voku-portable-ascii_2.0.1-2+rebuild1719091210_amd64-2024-06-22T21:20:11Z.build

Bug#1074210: php-zeta-base: FTBFS with pkg-php-tools_1.45+nmu1: make[1]: *** [debian/rules:12: override_dh_auto_test] Error 1

[Athos Ribeiro]

Source: php-zeta-base
Version: 1.9.4-2
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-zeta-base was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> .SF.. 45 / 45 
> (100%)
> 
> Time: 00:00.016, Memory: 6.00 MB
> 
> There was 1 failure:
> 
> 1) base_file_copy_recursive_test::testRecursiveCopyFailureNotReadable
> Failed asserting that true is false.
> 
> /<>/tests/file_copy_recursive_test.php:224
> 
> FAILURES!
> Tests: 45, Assertions: 34, Failures: 1, Skipped: 17.
> make[1]: *** [debian/rules:12: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-zeta-base/php-zeta-base_1.9.4-2+rebuild1719091321_amd64-2024-06-22T21:22:02Z.build

Bug#1074203: php-pda-pheanstalk: FTBFS with pkg-php-tools_1.45+nmu1: Error in bootstrap script

[Athos Ribeiro]

Source: php-pda-pheanstalk
Version: 4.0.5-3
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-pda-pheanstalk was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Pheanstalk/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /<>/tests/bootstrap.php(3): require()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once('...')
> #2 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #6 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #7 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #8 {main}
> make[1]: *** [debian/rules:19: override_dh_auto_test] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:3: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2
> E: Build killed with signal TERM after 150 minutes of inactivity


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-pda-pheanstalk/php-pda-pheanstalk_4.0.5-3+rebuild1719080606_amd64-2024-06-22T18:23:27Z.build

Bug#1074207: php-twig: FTBFS with pkg-php-tools_1.45+nmu1: make[1]: *** [debian/rules:73: override_dh_auto_test] Error 1

[Athos Ribeiro]

Source: php-twig
Version: 3.8.0-3
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-twig was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> SYMFONY_DEPRECATIONS_HELPER=weak phpunit
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Testing 
> ...FF   61 / 1670 (  
> 3%)
> .  122 / 1670 (  
> 7%)
> .  183 / 1670 ( 
> 10%)
> .  244 / 1670 ( 
> 14%)
> R  305 / 1670 ( 
> 18%)
> .  366 / 1670 ( 
> 21%)
> .  427 / 1670 ( 
> 25%)
> .  488 / 1670 ( 
> 29%)
> .S...  549 / 1670 ( 
> 32%)
> ..S..  610 / 1670 ( 
> 36%)
> .  671 / 1670 ( 
> 40%)
> .  732 / 1670 ( 
> 43%)
> .S...  793 / 1670 ( 
> 47%)
> .  854 / 1670 ( 
> 51%)
> .  915 / 1670 ( 
> 54%)
> .  976 / 1670 ( 
> 58%)
> . 1037 / 1670 ( 
> 62%)
> . 1098 / 1670 ( 
> 65%)
> . 1159 / 1670 ( 
> 69%)
> . 1220 / 1670 ( 
> 73%)
> . 1281 / 1670 ( 
> 76%)
> . 1342 / 1670 ( 
> 80%)
> . 1403 / 1670 ( 
> 84%)
> . 1464 / 1670 ( 
> 87%)
> . 1525 / 1670 ( 
> 91%)
> . 1586 / 1670 ( 
> 94%)
> . 1647 / 1670 ( 
> 98%)
> ...   1670 / 1670 
> (100%)
> 
> Time: 00:00.782, Memory: 36.00 MB
> 
> There were 2 failures:
> 
> 1) Twig\Tests\Cache\FilesystemTest::testWriteFailMkdir
> Failed asserting that exception of type "RuntimeException" is thrown.
> 
> 2) Twig\Tests\Cache\FilesystemTest::testWriteFailDirWritable
> Failed asserting that exception of type "RuntimeException" is thrown.
> 
> --
> 
> There was 1 risky test:
> 
> 1) 
> Twig\Tests\Extension\SandboxTest::testMultipleClassMatchesViaInheritanceInAllowedMethods
> This test did not perform any assertions
> 
> /<>/tests/Extension/SandboxTest.php:416
> 
> FAILURES!
> Tests: 1670, Assertions: 4412, Failures: 2, Skipped: 3, Risky: 1.
> 
> Legacy deprecation notices (3)
> 
> Other deprecation notices (9)
> make[1]: *** [debian/rules:73: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-twig/php-twig_3.8.0-3+rebuild1719090652_amd64-2024-06-22T21:10:53Z.build

Bug#1074208: php-vlucas-phpdotenv: FTBFS with pkg-php-tools_1.45+nmu1: TypeError: Dotenv\Repository\AdapterRepository::set(): Argument #1 ($name) must be of type string, int given, called in /<

[Athos Ribeiro]

Source: php-vlucas-phpdotenv
Version: 5.4.1-2
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-vlucas-phpdotenv was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit -v --bootstrap src/autoload.php
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Runtime:   PHP 8.2.18
> Configuration: /<>/phpunit.xml.dist
> Warning:   Your XML configuration validates against a deprecated schema.
> Suggestion:Migrate your XML configuration using "--migrate-configuration"!
> 
> ...  63 / 248 ( 
> 25%)
> E.. 126 / 248 ( 
> 50%)
> ... 189 / 248 ( 
> 76%)
> ... 248 / 248 
> (100%)
> 
> Time: 00:00.056, Memory: 8.00 MB
> 
> There was 1 error:
> 
> 1) 
> Dotenv\Tests\Repository\RepositoryTest::testImmutableLoaderCannotClearExistingEnvironmentVars
> TypeError: Dotenv\Repository\AdapterRepository::set(): Argument #1 ($name) 
> must be of type string, int given, called in 
> /<>/tests/Dotenv/Repository/RepositoryTest.php on line 114
> 
> /<>/src/Repository/AdapterRepository.php:72
> /<>/tests/Dotenv/Repository/RepositoryTest.php:114
> 
> ERRORS!
> Tests: 248, Assertions: 490, Errors: 1.
> make[1]: *** [debian/rules:10: override_dh_auto_test] Error 2


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-vlucas-phpdotenv/php-vlucas-phpdotenv_5.4.1-2+rebuild1719091184_amd64-2024-06-22T21:19:45Z.build

Bug#1074206: php-seld-signal-handler: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Seld/Signal/autoload.php): Failed to open stream: No such file or directory in /<

[Athos Ribeiro]

Source: php-seld-signal-handler
Version: 2.0.2-2
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-seld-signal-handler was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit --exclude-group nophpunit11
> PHP Warning:  require_once(/usr/share/php/Seld/Signal/autoload.php): Failed 
> to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 5
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Seld/Signal/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:19: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-seld-signal-handler/php-seld-signal-handler_2.0.2-2+rebuild1719090293_amd64-2024-06-22T21:04:54Z.build

Bug#1074205: php-react-promise: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/React/Promise/autoload.php): Failed to open stream: No such file or directory in /<

[Athos Ribeiro]

Source: php-react-promise
Version: 3.2.0-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-react-promise was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  require_once(/usr/share/php/React/Promise/autoload.php): Failed 
> to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/React/Promise/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:25: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-react-promise/php-react-promise_3.2.0-1+rebuild1719090207_amd64-2024-06-22T21:03:28Z.build

Bug#1074201: php-monolog: FTBFS with pkg-php-tools_1.45+nmu1: make[1]: *** [debian/rules:15: override_dh_auto_test] Error 1

[Athos Ribeiro]

Source: php-monolog
Version: 2.9.3-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-monolog was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit --include-path src --exclude-group Elasticsearch
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Warning:   Your XML configuration validates against a deprecated schema.
> Suggestion:Migrate your XML configuration using "--migrate-configuration"!
> 
> ...SS...S..W.   61 / 1127 (  
> 5%)
> S.WW.S..S  122 / 1127 ( 
> 10%)
> .S...  183 / 1127 ( 
> 16%)
> .WWWWSS..  244 / 1127 ( 
> 21%)
> ..S..  305 / 1127 ( 
> 27%)
> ...W..W.S  366 / 1127 ( 
> 32%)
> .  427 / 1127 ( 
> 37%)
> W...FFSS.  488 / 1127 ( 
> 43%)
> .W.W.W..SSWW.  549 / 1127 ( 
> 48%)
> .  610 / 1127 ( 
> 54%)
> .  671 / 1127 ( 
> 59%)
> .  732 / 1127 ( 
> 64%)
> .  793 / 1127 ( 
> 70%)
> .  854 / 1127 ( 
> 75%)
> .  915 / 1127 ( 
> 81%)
> .  976 / 1127 ( 
> 86%)
> S..W.W.S. 1037 / 1127 ( 
> 92%)
> . 1098 / 1127 ( 
> 97%)
> . 1127 / 1127 
> (100%)
> 
> Time: 00:05.197, Memory: 333.20 MB
> 
> There were 41 warnings:
> 
> 1) 
> Monolog\Formatter\LineFormatterTest::testDefFormatWithExceptionAndStacktrace
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 2) Monolog\Formatter\LineFormatterTest::testFormatShouldStripInlineLineBreaks
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 3) 
> Monolog\Formatter\LineFormatterTest::testFormatShouldNotStripInlineLineBreaksWhenFlagIsSet
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 4) Monolog\Handler\FlowdockHandlerTest::testWriteHeader
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 5) Monolog\Handler\FlowdockHandlerTest::testWriteContent
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 6) Monolog\Handler\InsightOpsHandlerTest::testWriteContent
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 7) Monolog\Handler\InsightOpsHandlerTest::testWriteBatchContent
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 8) Monolog\Handler\LogEntriesHandlerTest::testWriteContent
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 9) Monolog\Handler\LogEntriesHandlerTest::testWriteBatchContent
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 10) Monolog\Handler\LogmaticHandlerTest::testWriteContent
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 11) Monolog\Handler\LogmaticHandlerTest::testWriteBatchContent
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 12) Monolog\Handler\PushoverHandlerTest::testWriteHeader
> assertRegExp() is deprecated and will be removed in PHPUnit 10. Refactor your 
> code to use assertMatchesRegularExpression() instead.
> 
> 13) 

Bug#1074204: php-proxy-manager: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/ProxyManager/autoload.php): Failed to open stream: No such file or directory in /<

[Athos Ribeiro]

Source: php-proxy-manager
Version: 2.11.1+1.0.18-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-proxy-manager was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  require_once(/usr/share/php/ProxyManager/autoload.php): Failed 
> to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 5
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/ProxyManager/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:28: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-proxy-manager/php-proxy-manager_2.11.1+1.0.18-1+rebuild1719089916_amd64-2024-06-22T20:58:37Z.build

Bug#1074202: php-oscarotero-html-parser: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/HtmlParser/autoload.php): Failed to open stream: No such file or directory in /<

[Athos Ribeiro]

Source: php-oscarotero-html-parser
Version: 0.1.8-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-oscarotero-html-parser was found to fail to build 
with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  require_once(/usr/share/php/HtmlParser/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/HtmlParser/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-oscarotero-html-parser/php-oscarotero-html-parser_0.1.8-1+rebuild1719080526_amd64-2024-06-22T18:22:07Z.build

Bug#1074200: php-masterminds-html5: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Masterminds/HTML5/autoload.php): Failed to open stream: No such file or directory in /

[Athos Ribeiro]

Source: php-masterminds-html5
Version: 2.9.0+dfsg-2
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-masterminds-html5 was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  require_once(/usr/share/php/Masterminds/HTML5/autoload.php): 
> Failed to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Masterminds/HTML5/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:24: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-masterminds-html5/php-masterminds-html5_2.9.0+dfsg-2+rebuild1719080211_amd64-2024-06-22T18:16:52Z.build

Bug#1074198: php-hamcrest: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Hamcrest/autoload.php): Failed to open stream: No such file or directory in /<>/ven

[Athos Ribeiro]

Source: php-hamcrest
Version: 2.0.1-4
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-hamcrest was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit --include-path hamcrest --configuration tests/phpunit.xml.dist
> PHP Warning:  require_once(/usr/share/php/Hamcrest/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Hamcrest/autoload.php' 
> (include_path='hamcrest:.:/usr/share/php')
> #0 /<>/tests/bootstrap.php(5): require()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once('...')
> #2 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #6 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #7 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #8 {main}
> make[1]: *** [debian/rules:17: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-hamcrest/php-hamcrest_2.0.1-4+rebuild1719079668_amd64-2024-06-22T18:07:49Z.build

Bug#1074199: php-league-csv: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/League/Csv/autoload.php): Failed to open stream: No such file or directory in /<>

[Athos Ribeiro]

Source: php-league-csv
Version: 9.9.0-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-league-csv was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit --exclude-group network
> PHP Warning:  require_once(/usr/share/php/League/Csv/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 5
> PHP Stack trace:
> PHP   1. {main}() /usr/bin/phpunit:0
> PHP   2. PHPUnit\TextUI\Command::main($exit = *uninitialized*) 
> /usr/bin/phpunit:107
> PHP   3. PHPUnit\TextUI\Command->run($argv = [0 => '/usr/bin/phpunit', 1 => 
> '--exclude-group', 2 => 'network'], $exit = TRUE) 
> /usr/share/php/PHPUnit/TextUI/Command.php:99
> PHP   4. PHPUnit\TextUI\Command->handleArguments($argv = [0 => 
> '/usr/bin/phpunit', 1 => '--exclude-group', 2 => 'network']) 
> /usr/share/php/PHPUnit/TextUI/Command.php:114
> PHP   5. PHPUnit\TextUI\Command->handleBootstrap($filename = 
> '/<>/vendor/autoload.php') 
> /usr/share/php/PHPUnit/TextUI/Command.php:347
> PHP   6. PHPUnit\Util\FileLoader::checkAndLoad($filename = 
> '/<>/vendor/autoload.php') 
> /usr/share/php/PHPUnit/TextUI/Command.php:567
> PHP   7. PHPUnit\Util\FileLoader::load($filename = 
> '/<>/vendor/autoload.php') 
> /usr/share/php/PHPUnit/Util/FileLoader.php:49
> PHP   8. include_once() /usr/share/php/PHPUnit/Util/FileLoader.php:66
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/League/Csv/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:42: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-league-csv/php-league-csv_9.9.0-1+rebuild1719080066_amd64-2024-06-22T18:14:27Z.build

Bug#1074197: php-guzzlehttp-promises: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/GuzzleHttp/Promise/autoload.php): Failed to open stream: No such file or directory i

[Athos Ribeiro]

Source: php-guzzlehttp-promises
Version: 1.5.3-3
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-guzzlehttp-promises was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  require_once(/usr/share/php/GuzzleHttp/Promise/autoload.php): 
> Failed to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/GuzzleHttp/Promise/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [Makefile:4: test] Error 1
> make[1]: Leaving directory '/<>'
> dh_auto_test: error: make -j1 test returned exit code 2


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-guzzlehttp-promises/php-guzzlehttp-promises_1.5.3-3+rebuild1719079619_amd64-2024-06-22T18:07:00Z.build

Bug#1074196: php-doctrine-inflector: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Doctrine/Inflector/autoload.php): Failed to open stream: No such file or directory in

[Athos Ribeiro]

Source: php-doctrine-inflector
Version: 2.0.10-2
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-doctrine-inflector was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit --include-path lib --bootstrap vendor/autoload.php
> PHP Warning:  require_once(/usr/share/php/Doctrine/Inflector/autoload.php): 
> Failed to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Doctrine/Inflector/autoload.php' 
> (include_path='lib:.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(345): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:19: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-doctrine-inflector/php-doctrine-inflector_2.0.10-2+rebuild1719079124_amd64-2024-06-22T17:58:45Z.build

Bug#1074195: php-doctrine-event-manager: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Doctrine/Common/EventManager/autoload.php): Failed to open stream: No such file or

[Athos Ribeiro]

Source: php-doctrine-event-manager
Version: 2.0.1-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-doctrine-event-manager was found to fail to build 
with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  
> require_once(/usr/share/php/Doctrine/Common/EventManager/autoload.php): 
> Failed to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required 
> '/usr/share/php/Doctrine/Common/EventManager/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-doctrine-event-manager/php-doctrine-event-manager_2.0.1-1+rebuild1719079101_amd64-2024-06-22T17:58:22Z.build

Bug#1074194: php-doctrine-deprecations: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Doctrine/Deprecations/autoload.php): Failed to open stream: No such file or direct

[Athos Ribeiro]

Source: php-doctrine-deprecations
Version: 1.1.3-2
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-doctrine-deprecations was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit --include-path lib
> PHP Warning:  
> require_once(/usr/share/php/Doctrine/Deprecations/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Doctrine/Deprecations/autoload.php' 
> (include_path='lib:.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-doctrine-deprecations/php-doctrine-deprecations_1.1.3-2+rebuild1719079079_amd64-2024-06-22T17:57:59Z.build

Bug#1074193: php-doctrine-cache: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Doctrine/Common/Cache/autoload.php): Failed to open stream: No such file or directory in /

[Athos Ribeiro]

Source: php-doctrine-cache
Version: 2.2.0-3
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-doctrine-cache was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> memcached -d -u memcache
> redis-server --daemonize yes
> phpunit --include-path lib --bootstrap vendor/autoload.php
> PHP Warning:  
> require_once(/usr/share/php/Doctrine/Common/Cache/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 5
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Doctrine/Common/Cache/autoload.php' 
> (include_path='lib:.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(345): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:25: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-doctrine-cache/php-doctrine-cache_2.2.0-3+rebuild1719078918_amd64-2024-06-22T17:55:19Z.build

Bug#1074192: php-doctrine-annotations: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Doctrine/Common/Annotations/autoload.php): Failed to open stream: No such file or di

[Athos Ribeiro]

Source: php-doctrine-annotations
Version: 2.0.1-3
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-doctrine-annotations was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit --include-path lib --exclude-group nophpunit11
> PHP Warning:  
> require_once(/usr/share/php/Doctrine/Common/Annotations/autoload.php): Failed 
> to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required 
> '/usr/share/php/Doctrine/Common/Annotations/autoload.php' 
> (include_path='lib:.:/usr/share/php')
> #0 /<>/tests/Doctrine/Tests/TestInit.php(22): require_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once('...')
> #2 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #6 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #7 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #8 {main}
> make[1]: *** [debian/rules:30: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-doctrine-annotations/php-doctrine-annotations_2.0.1-3+rebuild1719078891_amd64-2024-06-22T17:54:52Z.build

Bug#1074191: php-dflydev-dot-access-data: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Dflydev/DotAccessData/autoload.php): Failed to open stream: No such file or dire

[Athos Ribeiro]

Source: php-dflydev-dot-access-data
Version: 3.0.2-2
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-dflydev-dot-access-data was found to fail to build 
with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  
> require_once(/usr/share/php/Dflydev/DotAccessData/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Dflydev/DotAccessData/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:18: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-dflydev-dot-access-data/php-dflydev-dot-access-data_3.0.2-2+rebuild1719078819_amd64-2024-06-22T17:53:40Z.build

Bug#1074190: php-constant-time: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/ParagonIE/ConstantTime/autoload.php): Failed to open stream: No such file or directory in /

[Athos Ribeiro]

Source: php-constant-time
Version: 2.7.0-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-constant-time was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  
> require_once(/usr/share/php/ParagonIE/ConstantTime/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/ParagonIE/ConstantTime/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:18: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-constant-time/php-constant-time_2.7.0-1+rebuild1719078707_amd64-2024-06-22T17:51:48Z.build

Bug#1074189: php-composer-xdebug-handler: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Composer/XdebugHandler/autoload.php): Failed to open stream: No such file or dir

[Athos Ribeiro]

Source: php-composer-xdebug-handler
Version: 3.0.5-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-composer-xdebug-handler was found to fail to build 
with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  
> require_once(/usr/share/php/Composer/XdebugHandler/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Composer/XdebugHandler/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-composer-xdebug-handler/php-composer-xdebug-handler_3.0.5-1+rebuild1719078660_amd64-2024-06-22T17:51:01Z.build

Bug#1074188: php-composer-pcre: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Composer/Pcre/autoload.php): Failed to open stream: No such file or directory in /<

[Athos Ribeiro]

Source: php-composer-pcre
Version: 3.1.4-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-composer-pcre was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit --exclude-group nophpunit10
> PHP Warning:  require_once(/usr/share/php/Composer/Pcre/autoload.php): Failed 
> to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Composer/Pcre/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-composer-pcre/php-composer-pcre_3.1.4-1+rebuild1719078584_amd64-2024-06-22T17:49:45Z.build

Bug#1074187: php-composer-class-map-generator: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Composer/ClassMapGenerator/autoload.php): Failed to open stream: No such fil

[Athos Ribeiro]

Source: php-composer-class-map-generator
Version: 1.3.4-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-composer-class-map-generator was found to fail to 
build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> phpunit
> PHP Warning:  
> require_once(/usr/share/php/Composer/ClassMapGenerator/autoload.php): Failed 
> to open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required 
> '/usr/share/php/Composer/ClassMapGenerator/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #2 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #6 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #7 {main}
> make[1]: *** [debian/rules:25: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-composer-class-map-generator/php-composer-class-map-generator_1.3.4-1+rebuild1719078561_amd64-2024-06-22T17:49:22Z.build

Bug#1074186: php-brick-math: FTBFS with pkg-php-tools_1.45+nmu1: PHP Warning: require_once(/usr/share/php/Brick/Math/autoload.php): Failed to open stream: No such file or directory in /<>

[Athos Ribeiro]

Source: php-brick-math
Version: 0.11.0-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: pkg-php-tools-1.45

Hi,

During a test rebuild, php-brick-math was found to fail to build with
pkg-php-tools 1.45 available in experimental.

To reproduce this locally, you need to install pkg-php-tools from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> CALCULATOR=GMP phpunit
> PHP Warning:  require_once(/usr/share/php/Brick/Math/autoload.php): Failed to 
> open stream: No such file or directory in 
> /<>/vendor/autoload.php on line 4
> PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
> 
> Error in bootstrap script: Error:
> Failed opening required '/usr/share/php/Brick/Math/autoload.php' 
> (include_path='.:/usr/share/php')
> #0 /<>/phpunit.php(7): require()
> #1 /usr/share/php/PHPUnit/Util/FileLoader.php(66): include_once('...')
> #2 /usr/share/php/PHPUnit/Util/FileLoader.php(49): 
> PHPUnit\Util\FileLoader::load()
> #3 /usr/share/php/PHPUnit/TextUI/Command.php(567): 
> PHPUnit\Util\FileLoader::checkAndLoad()
> #4 /usr/share/php/PHPUnit/TextUI/Command.php(347): 
> PHPUnit\TextUI\Command->handleBootstrap()
> #5 /usr/share/php/PHPUnit/TextUI/Command.php(114): 
> PHPUnit\TextUI\Command->handleArguments()
> #6 /usr/share/php/PHPUnit/TextUI/Command.php(99): 
> PHPUnit\TextUI\Command->run()
> #7 /usr/bin/phpunit(107): PHPUnit\TextUI\Command::main()
> #8 {main}
> make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1


The full build log is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/pkg-php-tools_virt-provides/0/php-brick-math/php-brick-math_0.11.0-1+rebuild1719078364_amd64-2024-06-22T17:46:05Z.build