Bug#1082648: Please ship upstream-provided "recover_qi.pl" utility.
On Thursday, 26 September 2024 9:22:41 AM AEST Michael Biebl wrote: > I disagree. What's not tested is broken. > Anyway, since you have no interest in providing an autopkgtest for this, > let's close this as wontfix. For the record, I'm disappointed by your unhelpful attitude. Having this useful and necessary (although rarely needed) utility would be advantageous to users. It is upstream's responsibility to test and maintain it properly, not ours. Please reconsider your decision and make a trivial change to provide this utility. (Providing autopkgtest for this utility is a far from trivial effort.) -- Kind regards, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- Power concedes nothing without a demand. It never did and it never will. Find out just what any people will quietly submit to and you have found out the exact measure of injustice and wrong which will be imposed upon them, and these will continue till they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass signature.asc Description: This is a digitally signed message part.
Bug#1082648: Please ship upstream-provided "recover_qi.pl" utility.
On Tuesday, 24 September 2024 7:57:01 PM AEST Michael Biebl wrote: > This tool was committed as an external contribution more than 10 years > ago. Do we now that it still works? Yes it works, and I had to use it recently to flush over hundred gigs of on-disk logs to log server. It was crucial and necessary. (It is like fsck utility.) > I'm happy to ship it in Debian if it's accompanied with an autopkgtest. > I won't be writing this autopkgtest though, so will rely on your help. I'm not doing autopkgtrest for it. It would be overkill and I have no capacity. Such things should be tested upstream anyway. Shipping small rarely used script does not require autopkgtest. Just please ship this useful maintenance utility without which rsyslog may not be repaired when it stops forwarding accumulated logs. There is no risk. (Why do I even have to convince after demonstrating the exact situation when it is required?) -- Best wishes, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- Trying to achieve freedom through the political process is like a slave letting his owner decide what means of escape are allowed. -- Larken Rose signature.asc Description: This is a digitally signed message part.
Bug#1082648: Please ship upstream-provided "recover_qi.pl" utility.
Source: rsyslog Version: 8.2408.0-2 Severity: wishlist Please ship "recover_qi.pl" anywhere in the package. "recover_qi.pl" is a maintenance utility to repair on-disk queue index: https://github.com/rsyslog/rsyslog/blob/master/tools/recover_qi.pl Its use might be necessary to flush disk queue after unclean shutdown. It would be very convenient if this utility will be shipped with the package to spare users from trip to upstream repository. Thanks. See also: * https://serverfault.com/a/1157850/85724 * https://www.rsyslog.com/doc/concepts/queues.html#disk-queues -- Regards, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- Trying to achieve freedom through the political process is like a slave letting his owner decide what means of escape are allowed. -- Larken Rose signature.asc Description: This is a digitally signed message part.
Bug#1082557: transition: qtbase-abi-5-15-15
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release team, I have skipped Qt 5.15.14 release and would like to upgrade to 5.15.15 which was published in the end of August. The transition is prepared in experimental. There are no known blockers in testing, although I will happily wait for the Qt 6.7.2 transition (#1081239) to complete first, as there are some dual Qt 5 and Qt 6 packages which make them entangled. I have submitted a merge request with the ben file: https://salsa.debian.org/release-team/transition-data/-/merge_requests/55 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1078158: RFS: gcc-doc uploads
Soren, On Mon, 16 Sept 2024 at 22:51, Soren Stoutner wrote: > On Monday, September 16, 2024 1:47:14 PM MST Dmitry Baryshkov wrote: > > gcc-14-doc has been uploaded by Bastian German (BTW, Bastian, thank > > you) and is currently waiting for the NEW processing. > > I don't know what are his plans for gcc-doc-defaults. > > OK. > > If you will push changes to Salsa for the small issues identified below (and > add an entry for yourself to debian/copyright under debian/*) I will sponsor > the package. Ack. I'm currently at the OSS EU & LPC, I will update the repo on salsa closer to the weekend and ping you afterwards. Just in case: I was thinking about adding the changes into the new revision of the package (and then making the upload include changes from both releases). Is that suitable from your POV? > > Thank you for your good packaging work. > > > > On Monday, September 16, 2024 1:31:16 PM MST Dmitry Baryshkov wrote: > > > > Soren, > > > > > > > > On Mon, 16 Sept 2024 at 22:27, Soren Stoutner wrote: > > > > > Dmitry, > > > > > > > > > > debian/source/format lists this package as 3.0 (native). Is Debian > the > > > > > upstream for this package? > > > > > > > > Yes, see how gcc-defaults handle the same case. > > > > > > > > > You should delete the debian/compat file as it is deprecated. > > > > > > > > > > In debian/control you should build-depend on "debhelper (= 13)". > > > > > > > > Ack. > > > > > > > > > You should add "Rules-Requires-Root: no” to debian/control (I assume > you > > > > > don’t need root to build this package). > > > > > > > > Ack. > > > > > > > > > As an example, see: > > > > > > > > > > https://salsa.debian.org/soren/privacybrowser/-/blob/master/debian/ > > > > > > control? > > > > > > > > ref_type=heads > > > > > > > > > > debian/copyright says: > > > > > > > > > > Source: <ftp://ftp.gnu.org/gnu/gcc/gcc-4.9.1/gcc-4.9.1.tar.bz2>, > notice > > > > > > > > > > that this package only contains several license files. > > > > > > > > > > Is that current? > > > > > > > > Yes, we haven't been updating it since that time, it wasn't required. > > > > > > > > > Comment: > > > > > This package was put together by Nikita V. Youshchenko > > > > > > > > > > on Mon, 18 Sep 2006 00:34:35 +0400. > > > > > . > > > > > Copyright (C) 2006, Nikita V. Youshchenko > > > > > > > > > > This looks obsolete (replaced by the debian/* entry). > > > > > > > > Ack. > > > > > > > > > Can you give me a little bit of background on why parts of this > package > > > > > > are > > > > > > > > non-free? I am having a hard time imagining that the Free Software > > > > > Foundation released a bunch of documentation that isn’t DFSG-free. > > > > > > > > The documentation is released under GFDL with invariant sections. It's > > > > considered non-DFSG-free. > > > > > > -- > > > Soren Stoutner > > > so...@debian.org > > > -- > Soren Stoutner > so...@debian.org -- With best wishes Dmitry
Bug#1078158: RFS: gcc-doc uploads
Soren, On Mon, 16 Sept 2024 at 22:38, Soren Stoutner wrote: > > Dmitry, > > Thanks for your quick answers below. > > Piuparts fails because of the following: > > The following packages have unmet dependencies: >cpp-doc : Depends: cpp-14-doc (>= 14.2.0-1~) but it is not installable >gcc-doc : Depends: gcc-14-doc (>= 14.2.0-1~) but it is not installable >gccgo-doc : Depends: gccgo-14-doc (>= 14.2.0-1~) but it is not installable >gfortran-doc : Depends: gfortran-14-doc (>= 14.2.0-1~) but it is not > installable > > It looks like Debian currently has cpp-13-doc (I assume the rest are the > same). Do these packages need to be updated at the same time? gcc-14-doc has been uploaded by Bastian German (BTW, Bastian, thank you) and is currently waiting for the NEW processing. I don't know what are his plans for gcc-doc-defaults. > > On Monday, September 16, 2024 1:31:16 PM MST Dmitry Baryshkov wrote: > > Soren, > > > > On Mon, 16 Sept 2024 at 22:27, Soren Stoutner wrote: > > > Dmitry, > > > > > > debian/source/format lists this package as 3.0 (native). Is Debian the > > > upstream for this package? > > > > Yes, see how gcc-defaults handle the same case. > > > > > You should delete the debian/compat file as it is deprecated. > > > > > > In debian/control you should build-depend on "debhelper (= 13)". > > > > Ack. > > > > > You should add "Rules-Requires-Root: no” to debian/control (I assume you > > > don’t need root to build this package). > > > > Ack. > > > > > As an example, see: > > > > > > https://salsa.debian.org/soren/privacybrowser/-/blob/master/debian/ > control? > > > ref_type=heads > > > > > > debian/copyright says: > > > > > > Source: <ftp://ftp.gnu.org/gnu/gcc/gcc-4.9.1/gcc-4.9.1.tar.bz2>, notice > > > > > > that this package only contains several license files. > > > > > > Is that current? > > > > Yes, we haven't been updating it since that time, it wasn't required. > > > > > Comment: > > > This package was put together by Nikita V. Youshchenko > > > on Mon, 18 Sep 2006 00:34:35 +0400. > > > . > > > Copyright (C) 2006, Nikita V. Youshchenko > > > > > > This looks obsolete (replaced by the debian/* entry). > > > > Ack. > > > > > Can you give me a little bit of background on why parts of this package > are > > > non-free? I am having a hard time imagining that the Free Software > > > Foundation released a bunch of documentation that isn’t DFSG-free. > > > > The documentation is released under GFDL with invariant sections. It's > > considered non-DFSG-free. > > > -- > Soren Stoutner > so...@debian.org -- With best wishes Dmitry
Bug#1078158: RFS: gcc-doc uploads
Soren, On Mon, 16 Sept 2024 at 22:27, Soren Stoutner wrote: > > Dmitry, > > debian/source/format lists this package as 3.0 (native). Is Debian the > upstream for this package? Yes, see how gcc-defaults handle the same case. > You should delete the debian/compat file as it is deprecated. > > In debian/control you should build-depend on "debhelper (= 13)". Ack. > You should add "Rules-Requires-Root: no” to debian/control (I assume you don’t > need root to build this package). Ack. > > As an example, see: > > https://salsa.debian.org/soren/privacybrowser/-/blob/master/debian/control? > ref_type=heads > > debian/copyright says: > > Source: <ftp://ftp.gnu.org/gnu/gcc/gcc-4.9.1/gcc-4.9.1.tar.bz2>, notice > that this package only contains several license files. > > Is that current? Yes, we haven't been updating it since that time, it wasn't required. > > Comment: > This package was put together by Nikita V. Youshchenko > on Mon, 18 Sep 2006 00:34:35 +0400. > . > Copyright (C) 2006, Nikita V. Youshchenko > > This looks obsolete (replaced by the debian/* entry). Ack. > > Can you give me a little bit of background on why parts of this package are > non-free? I am having a hard time imagining that the Free Software Foundation > released a bunch of documentation that isn’t DFSG-free. The documentation is released under GFDL with invariant sections. It's considered non-DFSG-free. -- With best wishes Dmitry
Bug#1078158: RFS: gcc-doc uploads
Soren, On Mon, 16 Sept 2024 at 21:50, Soren Stoutner wrote: > > Dmitry, > > It looks like the Salsa repository does not contain your most recent changes. > When sponsoring packages I like to build from Git. Can you please push them > there? Oops. Pushed gcc-doc-defaults changes. > > On Monday, September 16, 2024 12:44:51 PM MST Soren Stoutner wrote: > > Control: owner -1 ! > > > > Dmitry, > > > > I will take a look at sponsoring this. > > > > On Thursday, September 12, 2024 3:45:27 AM MST Dmitry Baryshkov wrote: > > > Hello, > > > > > > I'm looking for sponsors for the gcc-doc-defaults ([1]), gcc-13-doc > > > ([2]), gcc-14-doc ([3]) packages. > > > > > > Traditionally these uploads were handled for me by Adam, but for the > > > gcc-13-doc he wrote that he couldn't help at that time and for this > > > upload he didn't respond at all. Last time Bastian uploaded the > > > packages for me. Can anybody help me this time? It would be sad to get > > > gcc-docs removed from testing (scheduled for September 20th). > > > > > > [1] https://lists.debian.org/debian-mentors/2024/09/msg00059.html > > > [2] https://lists.debian.org/debian-mentors/2024/09/msg00058.html > > > [3] https://lists.debian.org/debian-mentors/2024/09/msg00060.html > > > -- > Soren Stoutner > so...@debian.org -- With best wishes Dmitry
Bug#1074980: gcin: ftbfs with GCC-14
Hi,
On Wed, Jul 03, 2024 at 12:27:13PM +, Matthias Klose wrote:
> Package: src:gcin
> Version: 2.9.0+dfsg1-3
> Severity: important
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-14
>
> [This bug is targeted to the upcoming trixie release]
>
> Please keep this issue open in the bug tracker for the package it
> was filed for. If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
> severity of this report will be raised before the trixie release.
>
> The full build log can be found at:
> http://qa-logs.debian.net/2024/07/01/gcin_2.9.0+dfsg1-3_unstable_gccexp.log
> The last lines of the build log are at the end of this report.
>
> [...]
> win-gtab.cpp:643:22: error: passing argument 1 of ‘gtk_label_set_text’ from
> incompatible pointer type [-Wincompatible-pointer-types]
> 643 | gtk_label_set_text(label_key_codes, str_key_codes);
> | ^~~
> | |
> | GtkWidget * {aka struct _GtkWidget *}
I have uploaded an NMU to fix this to DELAYED/0.
The diff is available here:
https://salsa.debian.org/debian/gcin/-/merge_requests/3
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1081238: "dh_mkdocs --theme-package mkdocs-material" hangs
Control: tags -1 + pending Hi Julian! On Mon, Sep 09, 2024 at 09:29:48PM +0100, Julian Gilbey wrote: > Package: mkdocs > Version: 1.5.3+dfsg-1 > Severity: normal > > I tried using dh_mkdocs with python-jellyfish, but dpkg-buildpackage > (using sbuild with unshare) just hung: > [...] It looks like Nick has already fixed this in git [1], however the fix has not been uploaded yet. Also it looks like there is an active work on the new upstream release [2], so hopefully there will be a new upload soon. [1]: https://salsa.debian.org/python-team/packages/python-mkdocs/-/commit/9ca53c4a51f34462ad311e621faa866c8ef5403b [2]: https://salsa.debian.org/python-team/packages/python-mkdocs/-/merge_requests/5 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1077635: debian-installer: RFC: provide UEFI shell under Advanced/Export options
Source: debian-installer Version: 20230607+deb12u6 Followup-For: Bug #1077635 X-Debbugs-Cc: Pascal Hambourg On 31/07/2024 Pascal Hambourg wrote: > On 31/07/2024 at 03:04, Dmitry Baryshkov wrote: >> >> This is an RFC whether it would be possible to include UEFI shell into >> the debian installer media. I understand that it won't work with >> SecureBoot > > The menu entry can be hidden when secure boot is enabled. Yes >> For example, on some of old Qualcomm-based laptops EFI vars are not >> accessible or are read-only. Thus it is not possible to setup boot >> configuration from the running Linux configuration. > > Isn't it possible to work around this with grub-installer options > "install in the removable media path" and "do not update EFI boot > variables" ? Not really. E.g. on Lenovo Miix 630 winldr gets selected even if grub is installed in the removable media path. Moreover until DTB loading issues get sorted out we have to manually modify EFI boot entries after installing the DtbLoader.efi. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.10.6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) -- With best wishes Dmitry
Bug#1080452: RFS: gcc-doc-defaults/5:28 [RC] -- several GNU manual pages
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "gcc-doc-defaults": * Package name : gcc-doc-defaults Version : 5:28 Upstream contact : [fill in name and email of upstream] * URL : http://gcc.gnu.org/ * License : GNU-meta-license, GNU-meta-license-01, GPL-2 * Vcs : https://salsa.debian.org/lumag/gcc-doc-defaults Section : contrib/doc The source builds the following binary packages: gcc-doc - documentation for the GNU compilers (gcc, gobjc, g++) cpp-doc - documentation for the GNU C preprocessor (cpp) gfortran-doc - documentation for the GNU Fortran Compiler (gfortran) gnat-doc - documentation for the GNU Ada Compiler (gnat) gccgo-doc - documentation for the GNU Go compiler (gccgo) gcc-doc-base - several GNU manual pages To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gcc-doc-defaults/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/contrib/g/gcc-doc-defaults/gcc-doc-defaults_28.dsc Changes since the last upload: gcc-doc-defaults (5:28) unstable; urgency=medium . * d/rules: build using GCC 14 (Closes: #1078158) * d/control: regen using GCC 14 as defaults * d/control.in: Bump Standards-Version to 4.7.0 (no changes needed) -- With best wishes Dmitry
Bug#1080451: RFS: gcc-14-doc/14.2.0-1 [RC] -- documentation for the GNU compilers (gcc, gobjc, g++)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "gcc-14-doc": * Package name : gcc-14-doc Version : 14.2.0-1 Upstream contact : http://gcc.gnu.org/bugzilla/ * URL : http://gcc.gnu.org/ * License : GFDL-1.3+-gnat-ugn, GPL-3+, GFDL-1.3+-gcc-1, GFDL-NIV-1.2+, GNU-meta-license, XXX, GFDL-1.2+-libquadmath, GNU-meta-license-variant, GFDL-NIV-1.3+, GFDL-NIV-1.3+-libiberty, Expat, GFDL-1.3+-gnat-rm, GPL-2+ * Vcs : https://salsa.debian.org/lumag/gcc-doc Section : non-free/doc The source builds the following binary packages: gcc-14-doc - documentation for the GNU compilers (gcc, gobjc, g++) cpp-14-doc - documentation for the GNU C preprocessor (cpp) gfortran-14-doc - documentation for the GNU Fortran Compiler (gfortran) gnat-14-doc - documentation for the GNU Ada Compiler (gnat) gccgo-14-doc - documentation for the GNU Go compiler (gccgo) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gcc-14-doc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/non-free/g/gcc-14-doc/gcc-14-doc_14.2.0-1.dsc Changes for the initial release (Debian packaging inherited from): gcc-14-doc (14.2.0-1) unstable; urgency=medium . * d/control: fix git branch name * d/salsa-ci.yml: add CI pipeline file * d/*: switch to gcc 14 * New upstream version 14.2.0 (Closes: #1079010) * d/patches: refresh patches * d/control: bump Standards-Version to 4.7.0, no changes needed -- With best wishes Dmitry
Bug#1080450: RFS: gcc-13-doc/13.3.0-1 -- documentation for the GNU compilers (gcc, gobjc, g++)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "gcc-13-doc": * Package name : gcc-13-doc Version : 13.3.0-1 Upstream contact : http://gcc.gnu.org/bugzilla/ * URL : http://gcc.gnu.org/ * License : GFDL-1.3+-gnat-ugn, GPL-3+, GFDL-1.3+-gcc-1, GFDL-NIV-1.2+, GNU-meta-license, XXX, GFDL-1.2+-libquadmath, GNU-meta-license-variant, GFDL-NIV-1.3+, GFDL-NIV-1.3+-libiberty, Expat, GFDL-1.3+-gnat-rm, GPL-2+ * Vcs : https://salsa.debian.org/lumag/gcc-doc Section : non-free/doc The source builds the following binary packages: gcc-13-doc - documentation for the GNU compilers (gcc, gobjc, g++) cpp-13-doc - documentation for the GNU C preprocessor (cpp) gfortran-13-doc - documentation for the GNU Fortran Compiler (gfortran) gnat-13-doc - documentation for the GNU Ada Compiler (gnat) gccgo-13-doc - documentation for the GNU Go compiler (gccgo) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gcc-13-doc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/non-free/g/gcc-13-doc/gcc-13-doc_13.3.0-1.dsc Changes since the last upload: gcc-13-doc (13.3.0-1) unstable; urgency=medium . * d/control: fix git branch name * d/salsa-ci.yml: add CI pipeline file * New upstream version 13.3.0 * d/patches: refresh patches from gcc-13 * d/control: bump Standards-Version to 4.7.0, no changes needed -- With best wishes Dmitry
Bug#1076725: please add udeb package for d-i
Hi Arnaud, On Thu, 29 Aug 2024 at 22:00, Arnaud Ferraris wrote: > > Hi Dmitry, > > Le 22/07/2024 à 18:37, Dmitry Baryshkov a écrit : > > > > Please provide .udeb package for tqftpserv to make it possible > > to use WiFi during Debian installation on Qualcomm devices. > > As you may have noticed I've uploaded the new upstream version of > tqftpserv earlier this week. However, I haven't yet added udeb to this: > I never dealt with those special packages yet, and need to take the time > to research a bit more the matter. > > I do plan to ship those in a future package release, though (likely next > month, so we can be reasonably sure those will be included in Trixie). Thanks! It would be really nice to be able to use WiFi from the D-I in corresponding Qualcomm devices. -- With best wishes Dmitry
Bug#1078990: python3-griffe: New upstream release is available
Package: python3-griffe Version: 0.48.0-1 Severity: wishlist Dear Maintainers, griffe 1.0.0 was released a few days ago, and then after two more days there was 1.1.0 [1]. It looks like there were some breaking changes in 1.0.0 [2]. The only reverse build- and runtime dependency is mkdocstrings-python-handlers, so please check if it works fine with the new griffe (maybe it also needs an upgrade to new upstream release). This version may also break python-markdown [3], but I will take care of it. [1]: https://github.com/mkdocstrings/griffe/releases [2]: https://github.com/mkdocstrings/griffe/releases/tag/1.0.0 [3]: https://github.com/Python-Markdown/markdown/commit/bd836a1448963081 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing
On Sunday, 11 August 2024 8:51:06 PM AEST Daniel Gröber wrote: > What remains to discuss is how you want to handle the git repo. Personally > I still haven't found a git packaging workflow I'm really happy with I use something like the following that does not depend on git, GBP, etc.: https://salsa.debian.org/onlyjob/notes/-/wikis/bp It works well for NMUs, even without access to package repository at all, and IMHO it is a relief when one does not need to bother with "gbp import-orig" or other methods of committing upstream sources. (By the way GBP workflow is a huge impediment for large packages, MUT packages, as well as packages with many vendored/bundled libraries which is typical for Golang software.) > so I > have a hard time recommending something. gbp is the most popular but I find > it lacking in a number of technical aspects. dgit is nice but complex, > still a bit niche and also not technically perfect in my eyes. IMHO GBP approach is counter-productive, with needlessly complicated workflow, redundant upstream branch(es) and incredibly inconvenient merge of debian packaging and upstream files in "master". Here is some criticism: https://salsa.debian.org/onlyjob/notes/-/wikis/no-gbp > Perhaps it would be best to just stick with the current debian/-only repo > layout since blktrace doesn't seem to get many releases anyway? Yes, absolutely. > If we document the magic incantation to unpack a new upstream release > in d/README.source it's not so bad really. There is not much to document, as "origtargz" is all that one needs. And arguably that should be a common knowledge among Debian maintainers. (Alternatively just extract tarball, copy/add "debian" folder and build.) -- All the best, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- If you make a mistake and do not correct it, this is called a mistake. -- Anonymous, "Analects" signature.asc Description: This is a digitally signed message part.
Bug#1075892: ruby-github-markup: Autopkgtest fails with docutils 0.21: MarkupTest#test_toc.rst and MarkupTest#test_rst failed
Control: tags -1 + pending Hi all, On Fri, Jul 19, 2024 at 11:33:37PM +0300, Dmitry Shachnev wrote: > The two files in question (README.toc.rst.html and README.rst.html) were > updated in this upstream commit: > > https://github.com/github/markup/commit/5488510af8644f45 > > which is included in version 5.0.0. > > Is it possible to update ruby-github-markup to the new version, or cherry-pick > that commit (or at least the relevant part of that commit)? I have backported the relevant part and uploaded NMU to DELAYED/2. And created a merge request on salsa with the diff: https://salsa.debian.org/ruby-team/ruby-github-markup/-/merge_requests/1 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1036948: edk2: please configure a grub menu entry for efi-shell-ARCH
Source: edk2 Version: 2024.05-1 Followup-For: Bug #1036948 Let me second this request. In some cases the UEFI shell is the main and the only tool to inspect the UEFI variables, DMI tables, etc. I think it would be helpful to be able to boot it from the grub menu if it is installed on the UEFI system. -- With best wishes Dmitry -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.10.0-test-dp+ (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1077635: debian-installer: RFC: provide UEFI shell under Advanced/Export options
Source: debian-installer Version: 20230607+deb12u6 Severity: wishlist This is an RFC whether it would be possible to include UEFI shell into the debian installer media. I understand that it won't work with SecureBoot, however under some obscure cases UEFI shell is the only (or the easiest) way to perform some actions. For example, on some of old Qualcomm-based laptops EFI vars are not accessible or are read-only. Thus it is not possible to setup boot configuration from the running Linux configuration. Being able to boot to the shell allows us to fix such issues. With the UEFI shell being available as the Debian package it should be pretty simple to include it into the generated D-I media. Having it under the Advanced / Export options would mean that it should not be used by default, still providing a way to rescue some of the issues. WDYT? -- With best wishes Dmitry -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.10.0-test-dp+ (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1077625: default.preseed breaks D-I's Manual disk partitioning
On Tue, 30 Jul 2024 at 23:07, Vagrant Cascadian wrote: > > Control: tags 1077625 wontfix > > On 2024-07-30, Dmitry Baryshkov wrote: > > It looks like the defaults present in the simple-cdd packages make > > generated images fail manual disk partitioning (if I select Manual, > > partman returns immediately). After commenting the `d-i > > partman/choose_partition` preseed value I can select correct option > > during installation. > > The intention of Simple-CDD has always been to automate the defaults as > much as possible, and use simple-cdd profiles to override the defaults > with desired customizations. Yes and it's great for this task. > Either do as you suggest, commenting out the line in default.preseed, or > possibly a better idea provide another simple-cdd profile that sets a > different value for this particular question. Please correct me if I'm wrong, I was under the impression that the default preset ends up being used even if I create another profile. This probably means that if I want to be able to partition the storage manually, I have to override default profile -- With best wishes Dmitry
Bug#1077625: default.preseed breaks D-I's Manual disk partitioning
Package: simple-cdd Version: 0.6.9 Severity: normal It looks like the defaults present in the simple-cdd packages make generated images fail manual disk partitioning (if I select Manual, partman returns immediately). After commenting the `d-i partman/choose_partition` preseed value I can select correct option during installation. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.10.0-test-dp+ (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages simple-cdd depends on: ii dctrl-tools 2.24-3 ii debian-cd 3.2.2 ii lsb-release 12.1-1 ii python3 3.12.3-1 ii python3-simple-cdd 0.6.9 ii reprepro5.3.1-5+b2 ii rsync 3.3.0-1 ii wget1.24.5-1 Versions of packages simple-cdd recommends: ii dose-distcheck 7.0.0-5+b2 Versions of packages simple-cdd suggests: pn qemu-system | qemu-kvm -- no debconf information
Bug#1076969: mako: FTBFS: dh_sphinxdoc: error: debian/python-mako-doc/usr/share/doc/python-mako-doc/html/search.html does not load searchindex.js
Control: reassign -1 sphinx-common 7.3.7-3 Control: affects -1 + src:mako Control: tags -1 + pending On Wed, Jul 24, 2024 at 09:44:43PM +0200, Santiago Vila wrote: > Package: src:mako > Version: 1.3.2-1 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > During a rebuild of all packages in unstable, your package failed to build: > > [...] > dh_sphinxdoc > dh_sphinxdoc: error: > debian/python-mako-doc/usr/share/doc/python-mako-doc/html/search.html does > not load searchindex.js > make[1]: *** [debian/rules:17: override_dh_sphinxdoc] Error 25 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:12: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 This is a bug in dh_sphinxdoc, I will fix it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1077371: simple-cdd: allow setting custom_installer via command line options
Package: simple-cdd Version: 0.6.9 Severity: normal Having custom_installer in the profiles/foo.conf file complicates tracking config files under the VCS (because the path can change between build machines). Please provide a way to pass custom_installer path via the command line option. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.10.0-test-dp+ (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages simple-cdd depends on: ii dctrl-tools 2.24-3 ii debian-cd 3.2.2 ii lsb-release 12.1-1 ii python3 3.12.3-1 ii python3-simple-cdd 0.6.9 ii reprepro5.3.1-5+b2 ii rsync 3.3.0-1 ii wget1.24.5-1 Versions of packages simple-cdd recommends: ii dose-distcheck 7.0.0-5+b2 Versions of packages simple-cdd suggests: pn qemu-system | qemu-kvm -- no debconf information
Bug#991141: debian-cd: arm64 device trees not included in ESP
Package: debian-cd Followup-For: Bug #991141 I'd like to second this request. We are looking at using Debian Installer images to support Qualcomm hardware (both Robotics boards and laptops). Having DTB files inside ESP would simplify booting / installation process. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.10.0-test-dp+ (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages debian-cd depends on: ii apt2.9.6 ii bc 1.07.1-4 ii bzip2 1.0.8-5.1 ii cpp4:13.2.0-7 ii curl 8.8.0-4 ii dctrl-tools [grep-dctrl] 2.24-3 ii dpkg-dev 1.22.9 ii genisoimage9:1.1.11-3.5 pn libcompress-zlib-perl pn libdigest-md5-perl ii libdpkg-perl 1.22.9 ii libfile-slurp-perl .32-2 ii libyaml-libyaml-perl 0.89+ds-1+b1 ii lynx 2.9.2-1 ii make 4.3-4.1 ii perl [libdigest-sha-perl] 5.38.2-5 ii pigz 2.8-1 ii tofrodos 1.7.13+ds-6 ii uuid-runtime 2.40.2-1 ii wget 1.24.5-1 ii xorriso1.5.6-1.2 Versions of packages debian-cd recommends: ii dosfstools 4.2-1.1 ii hfsutils 3.2.6-16 ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii mtools 4.0.43-1 ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 debian-cd suggests no packages. -- no debconf information
Bug#1076986: error: SSE register return with SSE2 disabled
Control: forwarded -1 https://codereview.qt-project.org/c/qt/qtbase/+/579205
Hi,
On Thu, Jul 25, 2024 at 04:58:40AM +0200, Andrew Lee wrote:
> Dear Maintainers,
>
> I recently updating LXQt to new upstream release which uses Qt6. And I
> got salsa-ci detected FTBFS with following message on i386:
> ```
> /usr/include/i386-linux-gnu/qt6/QtCore/qfloat16.h: In member function
> ‘constexpr qfloat16::operator NativeType() const’:
> /usr/include/i386-linux-gnu/qt6/QtCore/qfloat16.h:64:52: error: SSE register
> return with SSE2 disabled
>64 | constexpr operator NativeType() const noexcept { return nf; }
> |^
> /usr/include/i386-linux-gnu/qt6/QtCore/qfloat16.h: In function ‘qfloat16
> operator+(qfloat16, qfloat16)’:
> /usr/include/i386-linux-gnu/qt6/QtCore/qfloat16.h:124:147: error: operation
> not permitted on type ‘_Float16’ without option ‘-msse2’
> 124 | friend inline qfloat16 operator+(qfloat16 a, qfloat16 b) noexcept
> { return qfloat16(static_cast(a) +
> static_cast(b)); }
> ```
>
> Full log:
> https://salsa.debian.org/lxqt-team/libqtxdg/-/jobs/6021057#L2281
>
> Not sure if this a false detection or something wrong in Qt6 package.
> The LXQt package used to builds fine with Qt5.
I submitted a patch for this to upstream, but I would like to get it
reviewed by upstream (especially by Thiago Macieira) before uploading to
Debian.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1075430: qtlocation-opensource-src: ftbfs with GCC-14
Control: reassign -1 qtbase5-dev 5.15.13+dfsg-3 Control: affects -1 src:qtlocation-opensource-src On Wed, Jul 03, 2024 at 12:41:37PM +, Matthias Klose wrote: > Package: src:qtlocation-opensource-src > Version: 5.15.13+dfsg-2 > Severity: important > Tags: sid trixie > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-14 > > [This bug is targeted to the upcoming trixie release] > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The > severity of this report will be raised before the trixie release. > [...] > > /usr/include/x86_64-linux-gnu/qt5/QtCore/qfutureinterface.h:284:37: warning: > template-id not allowed for constructor in C++20 [-Wtemplate-id-cdtor] > 284 | explicit QFutureInterface(State initialState = NoState) > | ^ > /usr/include/x86_64-linux-gnu/qt5/QtCore/qfutureinterface.h:284:37: note: > remove the ‘< >’ The error comes from a qtbase header, so needs to be fixed there. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1076802: Please update to v1.1
Source: tqftpserv Version: 1.0-5 Severity: normal Please update tqftpserv to the freshly released v1.1. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.8-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#995986: simple-cdd: Firmware not being included in installer image
Package: simple-cdd Version: 0.6.9 Followup-For: Bug #995986 I found that following lines allow me to include non-free firmware packages into the generated images: mirror_components="main non-free-firmware" export NONFREE=1 export NONFREE_COMPONENTS="non-free-firmware" export DEP11=0 # woraround a bug with simple-cdd not fetching dep11 files The last line might require not-yet-uploaded debian-cd (built from git, works perfectly). -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.10.0-test-dp+ (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages simple-cdd depends on: ii dctrl-tools 2.24-3 ii debian-cd 3.2.2 ii lsb-release 12.1-1 ii python3 3.12.3-1 ii python3-simple-cdd 0.6.9 ii reprepro5.3.1-5+b2 ii rsync 3.3.0-1 ii wget1.24.5-1 Versions of packages simple-cdd recommends: ii dose-distcheck 7.0.0-5+b2 Versions of packages simple-cdd suggests: pn qemu-system | qemu-kvm -- no debconf information
Bug#1076726: please add udeb package for d-i
Package: rmtfs Version: 1.0-3 Severity: wishlist Please provide .udeb package for rmtfs to make it possible to use WiFi during Debian installation on Qualcomm devices. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.10.0-test-dp+ (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages rmtfs depends on: ii libc6 2.38-14 ii libqrtr1 1.1-1 ii libudev1 256.2-1 rmtfs recommends no packages. rmtfs suggests no packages. -- no debconf information
Bug#1076725: please add udeb package for d-i
Package: tqftpserv Version: 1.0-5 Severity: normal Please provide .udeb package for tqftpserv to make it possible to use WiFi during Debian installation on Qualcomm devices. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.10.0-test-dp+ (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages tqftpserv depends on: ii libc6 2.38-14 ii libqrtr1 1.1-1 tqftpserv recommends no packages. tqftpserv suggests no packages. -- no debconf information
Bug#1076724: fails to boot on some Arm64 laptops
Package: shim-unsigned Version: 15.8-1 Severity: important The shim binaries are being built with relaxed file alignment requirements. This makes some of UEFI implementations reject shim binaries. For example Lenovo Miix 630 boots grubaa64.efi, but rejects shimaa64.efi. Most likely this is because of the header differences. Compare: objdump -p shimaa64.efi: ... BaseOfCode 0001e000 ImageBase SectionAlignment1000 FileAlignment 0200 ... objdump -p grubaa64.efi: ... AddressOfEntryPoint 1000 BaseOfCode 1000 ImageBase SectionAlignment1000 FileAlignment 1000 ... Reference for the alignment story: - https://git.savannah.gnu.org/cgit/grub.git/commit/include/grub/efi/pe32.h?id=a51f953f4ee87cbfbf25a7df564304c5e9fea6a0 - https://web.archive.org/web/20200619041814/https://www.linaro.org/blog/porting-linux-to-aarch64-laptops/ -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.10.0-test-dp+ (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#1075892: ruby-github-markup: Autopkgtest fails with docutils 0.21: MarkupTest#test_toc.rst and MarkupTest#test_rst failed
Hi Praveen and all! On Sun, Jul 07, 2024 at 12:14:21PM +0300, Dmitry Shachnev wrote: > Source: ruby-github-markup > Version: 1.7.0+dfsg-6 > Severity: important > > Dear Maintainer, > > The autopkgtest for your package failed when it was run against > python-docutils 0.21.2+dfsg-1 from experimental. > > The log can be found here: > https://ci.debian.net/packages/r/ruby-github-markup/unstable/amd64/48395015/ The two files in question (README.toc.rst.html and README.rst.html) were updated in this upstream commit: https://github.com/github/markup/commit/5488510af8644f45 which is included in version 5.0.0. Is it possible to update ruby-github-markup to the new version, or cherry-pick that commit (or at least the relevant part of that commit)? If the tests do not pass with older docutils anymore, maybe we can synchronize our uploads: first I upload python-docutils to unstable with adding Breaks for old ruby-github-markup, and then you make your upload. Will that work? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1076229: libqt5webview5: Cannot be installed due to missing dependency
Hi Robert! On Fri, Jul 12, 2024 at 09:18:16PM +0200, Robert Griebl wrote: > Package: libqt5webview5 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: rob...@griebl.org > > Dear Maintainer, > > This package is used in KDE's "discover" Package Installer, which is > not installable anymore now. > > $ agi libqt5webview5 > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > Unsatisfied dependencies: > libqt5webview5 : Depends: qtwebengine-abi-5-15-16 but it is not installable > Error: Unable to correct problems, you have held broken packages We are in a transition (see #1075964), so it's expected that packages are temporarily uninstallable. This will be resolved in a day or two, hopefully. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1055311: libqt6gui6: recommend libqt6svg6
Hi Patrick! On Wed, Jul 10, 2024 at 10:22:08PM +0200, Patrick Franz wrote: > I don't quite like the recommendation because I think it's going in the > wrong way. > > I see that audacious build-depends on qt6-svg-dev, but somehow does not > pick up the dependency to the libqt6svg6 ? It is not about a library dependency. It is about the fact that libqt6svg6 ships two plugins, without which Qt does not support SVG icons and images: /usr/lib/x86_64-linux-gnu/qt6/plugins/iconengines/libqsvgicon.so /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqsvg.so This is the reason why I made libqt5gui5 recommend libqt5svg5. If you do not like depending on a library, maybe you can move plugins to a separate binary package and recommend that? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1076031: pyside breaks reverse dependencies by renaming library file
Hi Tobias and all, On Wed, Jul 10, 2024 at 06:10:52PM +0200, Tobias Frost wrote: > X-Debbugs-Cc: debian-rele...@lists.debian.org > Control: reassign -1 pyside2 > Control: affects -1 freecad > > This has been introduced by the upload of pyside3, which changed the > libary name without managing that reverse dependencies so that they rebuilt. > > Dear pyside2 maintainers, please be more thoughtful and manage your > transistions more carefully. This happend already in the past, see #1013881. First, what you called an upload, was actually a binNMU rebuild against Python 3.12 as default version. Then, it is upstream pyside2 buildsystem that enforces that Python version number is part of the library file name: https://sources.debian.org/src/pyside2/5.15.14-1/sources/pyside2/libpyside/CMakeLists.txt/#L102 libpyside2 is an internal interface for pyside2, which is not documented (and thus not intended for wide use), and freecad is the only package build-depending on libpyside2-dev. However, freecad seems to support this convention with config suffixes: https://sources.debian.org/src/freecad/0.21.2+dfsg1-4/cMake/FreeCAD_Helpers/SetupShibokenAndPyside.cmake/#L33 So, probably it just needs to be binNMUed together with pyside2, and that will solve the problem. If there is anything else I can do, please let me know. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1075964: transition: qtwebengine-abi-5-15-17
Hi Emilio! On Tue, Jul 09, 2024 at 10:48:46AM +0200, Emilio Pozuelo Monfort wrote: > I suppose those two build fine against the new version. Yes, they do. > If so, please go ahead. Thank you. Uploaded. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1075964: transition: qtwebengine-abi-5-15-17
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release team, I would like to move Qt WebEngine 5.15.17 from experimental to unstable. It is a patch release in 5.15 LTS branch that backports multiple CVE fixes from upstream Chromium, adds native Python 3 support (so we can drop our large patch), and additionally it includes a fix for building with libxml2 2.12 (so it fixes #1074671). Only two reverse dependencies will need to be binNMUed: angelfish and qtwebview-opensource-src. Ben file: title = "qtwebengine-abi-5-15-17"; is_affected = .depends ~ "qtwebengine-abi-5-15-16" | .depends ~ "qtwebengine-abi-5-15-17"; is_good = .depends ~ "qtwebengine-abi-5-15-17"; is_bad = .depends ~ "qtwebengine-abi-5-15-16"; -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1075892: ruby-github-markup: Autopkgtest fails with docutils 0.21: MarkupTest#test_toc.rst and MarkupTest#test_rst failed
Source: ruby-github-markup Version: 1.7.0+dfsg-6 Severity: important Dear Maintainer, The autopkgtest for your package failed when it was run against python-docutils 0.21.2+dfsg-1 from experimental. The log can be found here: https://ci.debian.net/packages/r/ruby-github-markup/unstable/amd64/48395015/ Relevant part: > 29s 1) Failure: > 29s MarkupTest#test_toc.rst > [/tmp/autopkgtest-lxc.yh8vy9c8/downtmp/build.Pwd/src/test/markup_test.rb:71]: > 29s README.toc.rst.html's contents are not html equal to output: > 29s --- - 2024-07-01 10:34:26.130218085 + > 29s +++ test/markups/README.toc.rst.html 2018-12-04 16:56:49.0 > + > 29s @@ -1,5 +1,5 @@ > 29s > 29s -Contents > 29s +Contents > 29s > 29s > 29s 1 Introduction > 29s @@ -29,4 +29,4 @@ > 29s > 29s pycparser is unique in the sense that it's written > in pure Python - a very > 29s high level language that's easy to experiment with and tweak. To people > familiar > 29s -with Lex and Yacc, pycparser's code will be simple to > understand. > 29s \ No newline at end of file > 29s +with Lex and Yacc, pycparser's code will be simple to > understand. > 29s > 29s > 29s > 29s 2) Failure: > 29s MarkupTest#test_rst > [/tmp/autopkgtest-lxc.yh8vy9c8/downtmp/build.Pwd/src/test/markup_test.rb:71]: > 29s README.rst.html's contents are not html equal to output: > 29s --- - 2024-07-01 10:34:26.722235734 + > 29s +++ test/markups/README.rst.html 2024-07-01 10:34:14.0 + > 29s @@ -2,7 +2,7 @@ > 29s Subtitle > 29s Example text. > 29s > 29s -Table of Contents > 29s +Table of Contents > 29s > 29s Header 2 > 29s Field list > 29s @@ -99,8 +99,7 @@ > 29s > 29s > 29s > 29s -https://scan.coverity.com/projects/621";> > 29s - src="https://scan.coverity.com/projects/621/badge.svg";> > 29s +https://scan.coverity.com/projects/621";>https://scan.coverity.com/projects/621/badge.svg";> > 29s > 29s src="https://scan.coverity.com/projects/621/badge.svg";> > 29s > 29s > 29s > 29s > 29s 19 runs, 47 assertions, 2 failures, 0 errors, 0 skips -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1075891: pydoctor: Autopkgtest fails with docutils 0.21: 6 tests failed
on.org"; > target="_top">ThePythonhomepage > 76s href="mailto:edlo...@gradient.cis.upenn.edu"; target="_top">Edward > Loper''' > 76s > 76s > assert epytext2html(doc) == squash(expected) > 76s E assert 'http://www.python.org"; > target="_top">www.python.orghttp://www.python.org"; > target="_top">http://www.python.orghttp://epydoc.sourceforge.net"; target="_top">The epydoc > homepage href="http://www.python.org"; > target="_top">ThePythonhomepage class="rst-reference rst-external" > href="mailto:edlo...@gradient.cis.upenn.edu"; target="_top">Edward > Loper' == 'http://www.python.org"; > target="_top">www.python.org href="http://www.python.org"; > target="_top">http://www.python.orghttp://epydoc.sourceforge.net"; target="_top">The epydoc > homepage href="http://www.python.org"; > target="_top">ThePythonhomepage class="rst-reference external" href="mailto:edlo...@gradient.cis.upenn.edu"; > target="_top">Edward Loper' > 76s E > 76s E - href="http://www.python.org"; target="_top">www.python.org class="rst-reference external" href="http://www.python.org"; > target="_top">http://www.python.orghttp://epydoc.sourceforge.net"; target="_top">The epydoc > homepage href="http://www.python.org"; > target="_top">ThePythonhomepage class="rst-reference external" href="mailto:edlo...@gradient.cis.upenn.edu"; > target="_top">Edward Loper > 76s E + http://www.python.org"; > target="_top">www.python.orghttp://www.python.org"; > target="_top">http://www.python.orghttp://epydoc.sourceforge.net"; target="_top">The epydoc > homepage href="http://www.python.org"; > target="_top">ThePythonhomepage class="rst-reference rst-external" > href="mailto:edlo...@gradient.cis.upenn.edu"; target="_top">Edward > Loper > 76s E ? > > > > > > > > 76s > 76s pydoctor/test/epydoc/test_epytext2html.py:255: AssertionError > [...] > 76s = 6 failed, 1314 passed, 1 skipped, 5 deselected, 2 xfailed in 17.43s > == -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1074773: qt5-qmake: unable to rebuild package xdrawchem, due to an error of qmake
Hi Georges! On Tue, Jul 02, 2024 at 07:17:41PM +0200, Georges Khaznadar wrote: > Package: qt5-qmake > Version: 5.15.13+dfsg-2 > Severity: important > > Dear Maintainer, > > I cannot currently rebuild the package xdrawchem, which uses qmake and > also the library libopenbabel-dev > > A build log can be found at > https://salsa.debian.org/georgesk/xdrawchem/-/pipelines/691085 > > I could reproduce this bug with this minimal example: > > --8<--- > $ sudo cowbuilder login > ... > root@georges:/# cd tmp > root@georges:/tmp# cat > foo.pro < > TEMPLATE = app > > TARGET = foo > > CONFIG += link_pkgconfig > > PKGCONFIG += openbabel-3 > > EOF > root@georges:/tmp# apt install libopenbabel-dev qt5-qmake libqt5core5t64 > ... > root@georges:/tmp# qmake -makefile > Info: creating stash file /tmp/.qmake.stash > Project ERROR: openbabel-3 development package not found > --8<--- > > The error message states that openbabel-3 is not there; however > the file /usr/lib/x86_64-linux-gnu/pkgconfig/openbabel-3.pc is around. Thank you for the minimal example. qmake calls pkg-config as a subprocess, so you need to build-depend on pkgconf explicitly if you need it. It is an optional feature so I don't think it should be a hard dependency. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1074671: qtwebengine-opensource-src: FTBFS: ../../3rdparty/chromium/third_party/blink/renderer/core/xml/xsl_style_sheet_libxslt.cc:132:70: error: invalid conversion from ‘void (*)(void*, xmlError*
Hi all, On Tue, Jul 02, 2024 at 12:06:44PM -0700, Soren Stoutner wrote: > I can confirm this build failure on my local system. > > Dmitry, do you have any idea off the top of your head as to the root cause? > Do > you think it is related to the recent upgrade from gcc-13 13.2.0 to 13.3.0? More likely to the libxml2 update from the end of May. It was fixed in 5.15.17 release in this commit: https://github.com/qt/qtwebengine-chromium/commit/c98d28f2f0f23721 And I am currently preparing 5.15.17, will upload it to experimental soon and then request a mini-transition for uploading it to unstable. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1073500: nbsphinx: Autopkgtest fails with Sphinx 7.3: LaTeX Error: File `{data:image/png;base64,...}' not found
Control: reassign -1 python3-sphinx 7.3.7-1 Control: forwarded -1 https://github.com/sphinx-doc/sphinx/issues/12331 On Sun, Jun 16, 2024 at 06:16:25PM +0300, Dmitry Shachnev wrote: > Source: nbsphinx > Version: 0.8.11+ds-1 > Severity: important > User: python-modules-t...@lists.alioth.debian.org > Usertags: sphinx7.3 > > Dear Maintainer, > > The autopkgtest for your package failed when it was run against Sphinx 7.3.7-2 > from experimental. > > The log can be found here: > https://ci.debian.net/packages/n/nbsphinx/unstable/amd64/47694298/ This is actually a bug in Sphinx, not nbsphinx, and an upstream pull request exists to fix it (which was not merged yet). And nbsphinx is no longer affected, because the command to build doc-latex was commented out: https://salsa.debian.org/python-team/packages/nbsphinx/-/commit/5ce52603f2f1814f -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1073828: libuim-data update fails due to undefined symbol
Control: tags -1 + pending On Fri, Jun 28, 2024 at 06:52:35PM +0200, Andreas Metzler wrote: > Hello, > > The latest iteration of > https://salsa.debian.org/debian/uim/-/merge_requests/15#note_501667 > is intended to fix this. And I have just uploaded it to DELAYED/2. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1073502: sphinx-autoapi: Autopkgtest fails with Sphinx 7.3: cannot cache unpickable configuration value: 'autoapi_prepare_jinja_env'
Source: sphinx-autoapi Version: 3.0.0-0.1 Severity: important User: python-modules-t...@lists.alioth.debian.org Usertags: sphinx7.3 Dear Maintainer, The autopkgtest for your package failed when it was run against Sphinx 7.3.7-2 from experimental. The log can be found here: https://ci.debian.net/packages/s/sphinx-autoapi/unstable/amd64/47694914/ Relevant part (hopefully): > 57s self = > 57s record = /usr/lib/python3/dist-packages/sphinx/util/logging.py, 131, "cannot cache > unpickable configuration value: %r (because it contains a function, class, or > module object)"> > 57s > 57s def filter(self, record: logging.LogRecord) -> bool: > 57s if getattr(record, 'skip_warningsiserror', False): > 57s # disabled by DisableWarningIsErrorFilter > 57s return True > 57s elif self.app.warningiserror: > 57s location = getattr(record, 'location', '') > 57s try: > 57s message = record.msg % record.args > 57s except (TypeError, ValueError): > 57s message = record.msg # use record.msg itself > 57s > 57s if location: > 57s exc = SphinxWarning(location + ":" + str(message)) > 57s else: > 57s exc = SphinxWarning(message) > 57s if record.exc_info is not None: > 57s raise exc from record.exc_info[1] > 57s else: > 57s > raise exc > 57s E sphinx.errors.SphinxWarning: cannot cache unpickable > configuration value: 'autoapi_prepare_jinja_env' (because it contains a > function, class, or module object) > 57s > 57s /usr/lib/python3/dist-packages/sphinx/util/logging.py:478: SphinxWarning -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1073501: python-sphinx-codeautolink: Autopkgtest fails with Sphinx 7.3: cannot cache unpickable configuration value: 'codeautolink_custom_blocks'
Source: python-sphinx-codeautolink Version: 0.15.0-4 Severity: important User: python-modules-t...@lists.alioth.debian.org Usertags: sphinx7.3 Dear Maintainer, The autopkgtest for your package failed when it was run against Sphinx 7.3.7-2 from experimental. The log can be found here: https://ci.debian.net/packages/p/python-sphinx-codeautolink/unstable/amd64/47694800/ Relevant part (hopefully): > 80s tests/extension/__init__.py:301: RuntimeError > 80s - Captured stdout call > - > 80s Running Sphinx v7.3.7 > 80s making output directory... done > 80s building [mo]: targets for 0 po files that are out of date > 80s writing output... > 80s building [html]: targets for 1 source files that are out of date > 80s updating environment: [new config] 1 added, 0 changed, 0 removed > 80s reading sources... [100%] index > 80s > 80s looking for now-outdated files... none found > 80s pickling environment... failed > 80s - Captured stderr call > - > 80s > 80s Warning, treated as error: > 80s cannot cache unpickable configuration value: 'codeautolink_custom_blocks' > (because it contains a function, class, or module object) > 80s === short test summary info > > 80s FAILED tests/extension/__init__.py::test_references[file6] - > RuntimeError: Sp... > 80s FAILED tests/extension/__init__.py::test_references[file7] - > RuntimeError: Sp... > 80s FAILED tests/extension/__init__.py::test_references[file30] - > RuntimeError: S... > 80s == 3 failed, 224 passed, 13 xfailed in 26.25s > == -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1073500: nbsphinx: Autopkgtest fails with Sphinx 7.3: LaTeX Error: File `{data:image/png;base64,...}' not found
Source: nbsphinx
Version: 0.8.11+ds-1
Severity: important
User: python-modules-t...@lists.alioth.debian.org
Usertags: sphinx7.3
Dear Maintainer,
The autopkgtest for your package failed when it was run against Sphinx 7.3.7-2
from experimental.
The log can be found here:
https://ci.debian.net/packages/n/nbsphinx/unstable/amd64/47694298/
Relevant part (hopefully):
> 285s pdfTeX warning: pdflatex (file ./python_logo.pdf): PDF inclusion: found
> PDF ver
> 285s sion <1.7>, but at most version <1.5> allowed
> 285s
> 285s
> 285s pdfTeX warning: pdflatex (file ./main-logo.pdf): PDF inclusion: found
> PDF versi
> 285s on <1.7>, but at most version <1.5> allowed
> 285s [21 <./python_logo.pdf>]
> 285s
> 285s ! LaTeX Error: File
> `{data:image/png;base64,iVBORw0KGgoNSUhEUgAAAEBACAY
> 285s
> AAACqaXHeCXBIWXMAAAsTAAALEwEAmpwYAAAHv0lEQVR42u2ae2xbZxnGf+f4OLbjOHGcNq2bpq
> 285s
> F12tJmZGtJttK1m7Z1XMomVQyp4zYESEMwMNLEKEgIbQJNFKkIVUNogJj2B9u6cYkETBUtl5UNWDt10
> 285s
> NGMbiU0G+klpE6aq9PYMX+c5xRjEl8SJ3WcvdKR7ePvXN7ney/P+34fvCWLW4x5eIYHCAGV+v2Pcgcg
> 285s
> BFTpewB4J/AxYDmQAKLAaeBcOQLQKgW3AymgETgL1AJHgAlgI9ADPAQcB8bLxZ1WAZ3AYaALuBdo0fl
> 285s
> rgTogLID6gDc0xlMOynuAm4DXgU9plj1Zxt4B/BM4JYAWvPL3AX8VCPnO6A5gRFayoKUFiAOvFTibzc
> 285s
> DfgTuvphuYRbjHkPz518BAAVbTCkwCr17NQGgW6T5J+fV1BQCwRFnhcjnEgE/KnDs1s6vEB6aSauDzw
> 285s
> N+ALeWSAquV0rqApwXG9wXGBoERBtqkfB8wCqwtJyLkEevbI8Vf1Kcf+JNA2CzljwPfBl4qRyocltIj
> 285s
> wBdEfA4ClwA38Czwu1KhwnMpzcAJ4CsCpU5HSTE/aw4D463KMs8shtnOVP5dmv0DQH0pv6yriEonFQR
> 285s
> vBR5QKhwS5+8W6Sm7hkgIWA2skDs9CgwCPs38oAqku4EzpQiANYOZ9qu+r1VO3ykKvAL4I/BlBbuvqy
> 285s
> FyXkCUhW9/GHhMjG8UeAL4lUx/raK9B7gfeEXjy6Lic7o9J4CngJeB29KaHOnSJo7/jK7pFBCeAtwqX
> 285s
> GrKR4BHRG+bs1BYj/i9o3QYeBz4XpbaIPM5PwJ+Pl8gWHnOyEOq+b+J3dCcTvl3Aw+rOHpZ8WJCDDCX
> 285s
> bAc+I6sx8rxmXsrhNcBu7LZ2LMu4cY1ZA1xMq/ETOZSJAB8EfgbcJTf7kHoMJSHbsXt3ufw43fdDGYH
> 285s
> zpFwns2Z4P3Yr7d/AT4CtiislIxv0go/n4ZOblBnap6gJOoEPCJCIssZBoFfl871XK/BZOdLeJqBBFd
> 285s
> 25HP2Aj4jxXcj477JYYEQz/B2gQue+IYuJUaLrA+/Ns3HRKjN+aopoH1JNMKEAekIz3kyJrwlEFMmfz
> 285s
> iOFNWN3haeLE3XAjdgd4I2lpHiuNFghJpdP6XsZODqNKV8EXtDYkjL1bGlwQn56KAcIK4HPYjc5Yzme
> 285s
> V3J+ns0C3lCaupDjxR3SEl+I/D6XC+RLRlzYCyMjCw2A2S6MpK/wHGUBLnUXY2XInZbvWYwAFKOztOA
> 285s
> B8CplLjoAnC0wg7rXChbYjo+Zmm4IuBnYh935jYoP7AZ+KtITw+4b9k9zj9hsXrznc22pzHMNj7xkzA
> 285s
> cAEeBBKXsEey3QqfbukVVMihhtVDWZmR3iwNdmAsJUis8GCGMGM/8tfX9SijtVok//+4DrsbfAtE0Bg
> 285s
> EOHv1QoAPkoXygIRgGKh+Tj+1TRPZBFAQ/2XsFQxpha7LY5hQJQiPKFgJBvT3CfCp4B+Xsu3j+u42LG
> 285s
> +RR2i8w3VzOfeV0uEPIBIKCmSBJ7IeTILGLXiK7/qixkShCjHe0GwP5dx1IUWaId7Vcy3/5dxyaNaEe
> 285s
> 7S65gKHilgJQeHgZukblGZ6m8Iy3AMezNk6+nvZhbE2Ly3zXLxJ7DqVnXF3t3GC4xVrfc0wHhsgWs0x
> 285s
> +OeY4Dw+tvClWc+kPsYVKMKLqf0MyYafFjMg2sfMWhzDUC36vYUIe9cSqgc5PqRhVD/Lr3crm017FIC
> 285s
> /iEzNGUifYD55dG/K7Xno/dabqNQ81bamPvuT9Sqxt500AYB8aiHe2jUiyRByAXgV+YLuOev/zywuh1
> 285s
> dywLaRLWiUvU6DkUEYA12DvY1qp75ZMOMQt75dZBJAmMAb3V9RXjHr+LyJbQ4NaPNtyoC5ZiN0AtKXs
> 285s
> Juxf4L/UNBoB4tKM9ofs5LpUEJvfvOpaq8LuqJ0aTrcvW+X/89pvrtgLX9nWP3mC6jKWhlb7KDICLFQ
> 285s
> N2qiW3WpbglgXHLQU4x6RTAD0nhxr//MRZ831fbO4Pb6jaZlWY16SlN2/a2GExwR5R4h7R4iFZxLA+B
> 285s
> 4GRaEf72IsHehqPd5z3N7ZWbxofTS7p7RpZ+/xjby4DjJ17mlPBsHcuCqvdQJMsy9SRAgJWRj1gxN4c
> 285s
> 47kfdJuJ8ST+kDtkVZhBDZ6cgjs4ceNK7JAbjelzQGD0K+InVrcFm04e6gsaBtuPHugJ9p4etUKNXsP
> 285s
> tc+HxW8YUAYw9h1OzCYAXxEitjPc3/i8NJiYmOfvqMKFGHy63QWXQbaRF5NQ05Mmdli6XZJh9QhYQd9
> 285s
> igp8qqtDymv/O3fVUrrwkYbXeFWfmOAKZl4queky1L9dkInxHtaL8Cb8/JIZ7de5qmzTVcv3sFwbB3N
> 285s
> g9OZXx3DnPgXNzoOzNqhNdX4QlYWO7cRelMrGDvjtzedOXJ8aEEXUf7adpcQ8vtS/HVzHpx1kg7nNxu
> 285s
> AWYw7DXe1hbEH6rIS/l8lZnJeNcNdzc8CGB5TOojfupW+fj9o92MXZrAG7BwWQaWxyy6XZquwmPdC2s
> 285s
> MtnUVF6z/cQFHzp0a5jffPQOpFMvXV7Ht4414A3O1pXBmMpVLFGol09YC4fVV3PLpJp77YTfJiRTx4U
> 285s
> TJATATZQtqiTW0BLjtvtVUVLp45WAv8aEE5ShZp3VZs5/qervFV2oWMC8AAHOVm0tGTBa5vAXAYgfgP
> 285s 6N1EOJNty18AElFTkSuQmCC}' not found.
> 285s
> 285s See the LaTeX manual or LaTeX Companion for explanation.
> 285s Type H for immediate help.
> 285s ...
> 285s
> 285s l.2292 ...a5vAXAYgfgP6N1EOJNty18AElFTkSuQmCC}}
> 285s
> 285s ?
> 285s ! Emergency stop.
> 285s ...
> 285s
> 285s l.2292 ...a5vAXAYgfgP6N1EOJNty18AElFTkSuQmCC}}
> 285s
> 285s ! ==> Fatal error occurred, no output PDF file produced!
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1073182: qtdeclarative-opensource-src: Qt QML engine is broken on loong64
Hi! On Fri, Jun 14, 2024 at 02:59:56PM +0800, 宋鼎 wrote: > Source: qtdeclarative-opensource-src > Version: 5.15.13+dfsg-2 > Severity: normal > Tags: patch > User: debian-loonga...@lists.debian.org > Usertags: loong64 > > Dear maintainers, > > Compiling the qtdeclarative-opensource-src failed for loong64 in the > Debian Package Auto-Building environment. > > The build log can be found at > https://buildd.debian.org/status/logs.php?pkg=qtdeclarative-opensource-src&ver=5.15.13%2Bdfsg-2&arch=loong64. > Refer for other architectures, please add loong64 to "Qt QML engine is > broken" lists in debian/rules. > Please consider the patch I attached. > Your opinions are welcome. What is the point of shipping a package if it won't be usable anyway? I see a lot of tests are failing with segmentation fault, so any application relying on Qt Declarative will likely fail to run in a similar way. Have you tried to get a stacktrace of those segfaults? Maybe they will give us a hint on how to fix this. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1072673: qttools-opensource-src: uses LLVM 15 which is being removed
Hi Emilio! On Thu, Jun 06, 2024 at 09:58:19AM +0200, Emilio Pozuelo Monfort wrote: > Source: qttools-opensource-src > Version: 5.15.8-2 > Severity: important > > Hi, > > qttools-opensource-src is building with LLVM 15, which is going to be > removed soon. Please switch to a newer version (such as 17), or ideally > use the default version, which may be more suitable/stable these days. Unfortunately, qttools fails to build with newer LLVM, some qdoc-related tests fail [1]. In particular, it misinterprets typedefs as structs, as can be seen in the build log [2]. Upstream Qt 6 had a series of patches to fix build with LLVM 16/17, see the linked Gerrit Reviews in this bug [3]. However, most of these patches fail to apply cleanly to 5.15 branch, and based on patch descriptions I could not identify the patch which would fix these particular test failures. So I either need a help from LLVM expert who would explain this test failure, or we can ignore these tests, or we can drop qdoc in 5.15. The last option would mean dropping documentation for all of Qt 5, and also fixing at least kuserfeedback and quickflux. It is hard to identify the complete set of affected packages, because some packages can depend on qdoc-qt5 indirectly via qttools5-dev-tools. Maybe the set of affected packages will become smaller once Qt6-based KDE stack lands in unstable. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051883 [2]: https://buildd.debian.org/status/fetch.php?pkg=qttools-opensource-src&arch=amd64&ver=5.15.10-3%2Bb1&stamp=1694632815&raw=0 [3]: https://bugreports.qt.io/browse/QTBUG-111580 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1070835: OBS does not correctly implement the bootstrap protocol
Package: ed Followup-For: Bug #1070835 To slightly improve the suggestion, instead of skipping ed I ended up forcebly installing usrmerge: %if %_repository == "Debian_Unstable" || %_repository == "Debian_Testing" Preinstall: usrmerge Runscripts: usrmerge %endif -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages ed depends on: ii libc6 2.38-11 ed recommends no packages. ed suggests no packages. -- no debconf information
Bug#1069759: alabaster: Please update to the latest upstream version
Control: tags -1 + pending On Fri, May 10, 2024 at 09:47:29PM +0300, Dmitry Shachnev wrote: > I have prepared a pull request now [1]. > > [1]: https://github.com/jbouse-debian/alabaster/pull/9 And now also uploaded this as NMU to DELAYED/10. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061179: transition: qtbase-abi-5-15-13
Hi Sebastian! On Mon, May 20, 2024 at 08:04:02PM +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Please go ahead I see that now all packages except gammaray built successfully. I think you can rebuild gammaray too. Its FTBFS bug is only about a flaky test, it should still build fine, maybe after retries on some architectures. I have some work in progress to update gammaray to the new upstream version, but that needs to wait for Qt 6.6 and KDE Frameworks 6 in unstable first. P.S. Also, upstream published Qt 5.15.14 and Qt WebEngine 5.15.17 this week. I will probably skip this Qt release, but maybe I will ask you for a Qt WebEngine mini-transition which will need rebuilds of two packages. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061179: Bug#1060019: transition: poppler 24.02
On Mon, May 20, 2024 at 05:46:31PM +0200, Sebastiaan Couwenberg wrote: > dak reports no rdeps on mirror.ftp-master.d.o: > > $ dak rm -Rn -a i386 lmms > W: -a/--architecture implies -p/--partial. > Will remove the following packages from unstable: > >lmms | 1.2.2+dfsg1-6 | source >lmms | 1.2.2+dfsg1-6+b1 | i386 > lmms-vst-server | 1.2.2+dfsg1-6+b1 | i386 > > Maintainer: Debian Multimedia Maintainers > > > --- Reason --- > > -- > > Checking reverse dependencies... > No dependency problem found. > > So I've filed: #1071530. Thank you! -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061179: Bug#1060019: transition: poppler 24.02
Hi, On Thu, May 16, 2024 at 01:25:56PM +0200, Jeremy Bícha wrote: > libpoppler134 has migrated to Testing and I don't see libpoppler126 > there any more so I'm closing the poppler transition bug. FWIW, I am waiting for a formal "tags -1 confirmed" from Sebastian. Also, one of the affected packages (lmms) currently FTBFS on i386: https://bugs.debian.org/1068155. Would it be possible to remove it from testing on i386 (or completely) so it doesn't block Qt migration? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1071193: libqt6core6t64/experimental breaks ABI
Hi all, On Fri, May 17, 2024 at 01:07:31AM +0300, Adrian Bunk wrote: > Apparently the symbols were moved to PRIVATE_API: > _ZN5QUtf816convertToUnicodeE14QByteArrayViewPN20QStringConverterBase5StateE@@Qt_6_PRIVATE_API > _ZN5QUtf816convertToUnicodeEPDs14QByteArrayView@@Qt_6_PRIVATE_API > _ZN6QUtf1616convertToUnicodeE14QByteArrayViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API > _ZN6QUtf3216convertToUnicodeE14QByteArrayViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API > _ZN5QUtf818convertFromUnicodeE11QStringView@@Qt_6_PRIVATE_API > _ZN5QUtf818convertFromUnicodeE11QStringViewPN20QStringConverterBase5StateE@@Qt_6_PRIVATE_API > _ZN6QUtf1618convertFromUnicodeE11QStringViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API > _ZN6QUtf3218convertFromUnicodeE11QStringViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API I suspect this may be related to a change in Qt 6.5 where they replaced Perl code to look for private classes (findclasslist.pl) with C++ code in syncqt [1][2]. These QUtf8 / QUtf16 / QUtf32 structs were always defined in a private header (qstringconverter_p.h), so marking them as private is correct. Maybe findclasslist.pl only looked at classes marked as Q_*_EXPORT, while these structs are not marked as such (individual members are marked instead). [1]: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=5a5ad8c0029ef9f9 [2]: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=7f4aa1a3fa461064 > This is an upstream(?) ABI break, but since libqt6core5compat6 seems > to be the only affected package something like > Breaks: libqt6core5compat6 (<< 6.6) > might be the best available option to avoid issues when upgrading > from bookworm. I agree. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1070389: uim: FTBFS: error: some symbols or patterns disappeared in the symbols file
Control: tags -1 + pending On Sat, May 04, 2024 at 08:52:16PM +0300, Dmitry Shachnev wrote: > I have prepared a merge request on salsa [2] fixing this build failure. > > [1]: > https://tracker.debian.org/news/1526298/accepted-glibc-238-7-source-into-unstable/ > [2]: https://salsa.debian.org/debian/uim/-/merge_requests/15 And as the Qt transition is starting soon and this is one of the blockers, I have uploaded NMU to DELAYED/2 based on that merge request. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1070564: libqt5quick5-gles: attempt to upgrade to version 5.15.10+dfsg-3 tries to remove other packages
Hi Cristian! On Mon, May 06, 2024 at 04:18:32PM +0200, Cristian Ionescu-Idbohrn wrote: > Package: libqt5quick5-gles > Version: 5.15.10+dfsg-2+b3 > Severity: important > > Hi, > > I see this message: > > The following packages have been kept back: > libqt5quick5-gles I see you have installed libqt5quick5-gles and the non-GLES variant of libqt5gui5t64. But your hardware does not really use OpenGL ES, right? There was a period during the 64-bit time_t transition when apt could replace libqt5quick5 with libqt5quick5-gles. On March 30th I tigthened dependencies of libqt5quick5-gles to prevent that [1], but probably you upgraded your system before then. If my guess is right and you do not really need the GLES variant, the right thing to do will be to install libqt5quick5, which will remove libqt5quick5-gles and let the other packages be upgraded. Please try that and let me know if it helps. [1]: https://tracker.debian.org/news/1515848/accepted-qtdeclarative-opensource-src-gles-51510dfsg-3-source-into-unstable/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1069759: alabaster: Please update to the latest upstream version
Control: tags -1 + patch Dear Maintainer, On Wed, Apr 24, 2024 at 02:01:42PM +0300, Dmitry Shachnev wrote: > Source: alabaster > Version: 0.7.12-1 > Severity: wishlist > > Dear Maintainer, > > Sphinx now requires alabaster 0.7.14 or newer [1]. It would be nice if you > packaged the latest version, which is 0.7.16 at the moment [2]. > > I can prepare a pull request if needed. I have prepared a pull request now [1]. [1]: https://github.com/jbouse-debian/alabaster/pull/9 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
On Tue, May 07, 2024 at 05:58:55PM +, Thorsten Glaser wrote:
> Dmitry Shachnev dixit:
>
> >Will you be able to forward your patch upstream when you finalize it?
>
> Sort of. I can do the CLA, Gerrit, etc. dance, but I probably cannot
> respond well if they want me to test things with vanilla upstream
> (instead of the packaging), or if they have requests I as a C (but
> not C++) developer don’t understand.
I also usually test with our packaging, not with vanilla upstream.
But with Qt 6.6 from experimental there should not be much difference:
we don't have any patches for this part of code, and we are lagging only
a few versions behind upstream.
And your test example compiles without changes with Qt 6, you just need
to call qmake6 instead of qmake.
> >> +static inline int roundForBbox(qreal v)
> >> +{
> >> +return (v < 0) ? floor(v) : ceil(v);
> >> +}
> >
> >I see you are passing negated values to this function, e.g. roundForBbox(-x).
>
> Not only them. And roundForBbox is basically just the canonical
> “round away from zero / towards ±infinity for integer results”.
>
> The negation in the callers is to convert *some* Qt coordinates
> to PS/PDF coordinates, but only for the Y axis, as the X axis is
> the same for them.
Okay, makes sense.
> >I see why you moved properties to the top, but is moving postscriptName
> >needed? Maybe leave it where it was to minimize the diff?
>
> It’s not. I moved the whole block to make it easier to read,
> but good point.
Thank you.
> >You are passing scalep pointer here only to multiply it by this value?
>
> Yes.
>
> >It looks like fontEngine is a public member of QFontSubset, so you can
> >do it in the calling code.
>
> Yes, except it’s the callee that determines the scaling factor,
> not the caller. By passing it back like this, nothing would have
> to change in the caller should the callee ever decide to not scale.
Valid point. Let's see if Qt developers like this approach with passing a
pointer. If they don't, maybe the same thing can be achieved differently,
e.g. by returning QPair.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
On Sun, May 05, 2024 at 08:45:25PM +, Thorsten Glaser wrote:
> Dixi quod…
>
> >correct… but it only changes the metrics in the head table, not
> >in the OS/2 or hhea tables (as can be seen when loading the font
> >from the PDF in FontForge). Furthermore, the /FontBBox in the PDF
> >is constructed from the values from the original font.
>
> And Atril uses the values from the hhea table (found by hexediting).
>
> #define TO_TTF(x) qRound(x * 2048. / ppem)
>
> This is used in things like…
>
> font.hhea.maxAdvanceWidth = TO_TTF(fontEngine->maxCharWidth());
>
> … but not in…
>
> font.hhea.ascender = qRound(properties.ascent);
> font.hhea.descender = -qRound(properties.descent);
> font.hhea.lineGap = qRound(properties.leading);
>
> … and of course not when the OS/2 table is copied:
>
> if (!noEmbed) {
> QTtfTable os2;
> os2.tag = MAKE_TAG('O', 'S', '/', '2');
> os2.data = fontEngine->getSfntTable(os2.tag);
> if (!os2.data.isEmpty())
> tables.append(os2);
> }
>
> (all examples from stretch’s Qt, as the oldest I had at hand)
Actually, this code dates back to “Initial import from the monolithic Qt”
commit from 2011. The only thing that changed is that MAKE_TAG macro was
replaced with QFont::Tag class.
I checked Qt 4 history [1] and there this code dates back to “Long live Qt!”
commit from 2009. So it’s unlikely that we can find the original developer
and ask why it is like that and whether we actually need the OS/2 table.
Now that you dug so deeply, maybe you can try to replace qRound in those
three lines that you mentioned with TO_TTF, and check if it fixes the bug
(and does not break anything else)?
[1]: https://github.com/qt/qt/blame/4.8/src/gui/text/qfontsubset.cpp
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1067047: Buildng the package removes debian/.gitlab-ci.yml
On Friday, 26 April 2024 10:33:55 PM AEST Andrey Rakhmatullin wrote: > If the file is normally not shipped in the package then I'm fine, Let me assure you that is exactly the case. None of my uploads have that file. By the way, I've just uploaded new Gnucash release! ;) > I only > wanted to make sure that it's easy to do NMUs for the package. I see... Thank you for your attention and care. -- Regards, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- While it is relatively easy to see that government is a bully, a thief, and a killer, the most baneful effect of government has always been psychological. Government convinced man that it was an absolute necessity for human survival. ‘No matter how bad a government may be, it is better than no government.’ No other church had a more convincing argument. -- Robert LeFevre, "A Way to Be Free: The Autobiography of Robert LeFevre, Volume I" (1999) signature.asc Description: This is a digitally signed message part.
Bug#1067047: Buildng the package removes debian/.gitlab-ci.yml
On Friday, 26 April 2024 12:16:39 AM AEST Andrey Rakhmatullin wrote: > > Obviously '.gitlab-ci.yml' is a repository-specific file with > > configuration of Gitlab CI on Salsa. There is no reason to ship it with > > source package > > Yet you are shipping it, maybe you should reconsider that? > > $ tar tvf gnucash_5.5-1.2.debian.tar.xz debian/.gitlab-ci.yml > -rw-rw-r-- 0/0 759 2024-02-23 22:55 debian/.gitlab-ci.yml I'm not shipping it. NMU uploader must have built the package differently to preserve the file. Oh, wait, that was you who last uploaded Ghucash. (Thank you for your help with NMU. Much appreciated.) I don't mind shipping the file (it is harmless) but I've made an explicit change to "debian/clean" to remove it. Leave this matter alone please. Frankly it does not worth your time and I'd rather not play that bug reopen ping-pong. What change you expect me to make?? Everything already works as intended. -- Best wishes, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- If you have a government of good laws and bad men, you will have a bad government. For bad men will not be bound by good laws. -- Robert LeFevre signature.asc Description: This is a digitally signed message part.
Bug#1069759: alabaster: Please update to the latest upstream version
Source: alabaster Version: 0.7.12-1 Severity: wishlist Dear Maintainer, Sphinx now requires alabaster 0.7.14 or newer [1]. It would be nice if you packaged the latest version, which is 0.7.16 at the moment [2]. I can prepare a pull request if needed. [1]: https://github.com/sphinx-doc/sphinx/pull/11858 [2]: https://pypi.org/project/alabaster/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1069574: age-old and insecure webkit package
Hi again Hadmut, On Sun, Apr 21, 2024 at 08:25:23PM +0300, Hadmut Danisch wrote: > Hi Dmitry, > > > even their own website > > https://wkhtmltopdf.org/status.html > > says: > >*Do not use wkhtmltopdf with any untrusted HTML* – be sure to >sanitize any user-supplied HTML/JS, otherwise it can lead to >complete takeover of the server it is running on! Please consider >using a Mandatory Access Control system like AppArmor or SELinux, >see recommended AppArmor policy <https://wkhtmltopdf.org/apparmor.html>. > > Wouldn't it be more than enough or a reason to throw this out of > debian/ubuntu, until they fixed this? First, I am the wrong person to ask about this. I am CCing the wkhtmltopdf maintainer. Second, wkhtmltopdf is not a leaf package, there are other packages depending on it: Reverse-Recommends == * civicrm-common * python3-a38 Reverse-Depends === * odoo-16 * python3-django-wkhtmltopdf * python3-pdfkit -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1069574: age-old and insecure webkit package
Hi Hadmut! On Sat, Apr 20, 2024 at 09:23:37PM +0300, Hadmut Danisch wrote: > Package: libqt5webkit5 > > Version: 5.212.0~alpha4-30 > > > Hi, > > this was originally a bug report against Ubuntu 24.04 as 2061191, but since > the package is community maintained and not by Ubuntu, they asked me to > report it "upstreams". > > > Ubuntu 24.04 beta / Debian bookworm still use libqt5webkit5. > > It is not obvious, where it comes from, but the version is still an alpha4, > and the link in the README seems to suggest, that it still comes from > https://github.com/annulen/webkit, which redirects to > https://github.com/qtwebkit/qtwebkit, where the alpha4 tag is over 4 years > old. > > There, the latest README tells: > > Code in this repository is obsolete. If you are looking for up-to-date > QtWebKit use this fork: https://github.com/movableink/webkit > > https://github.com/movableink/webkit seems to be still maintained – more or > less. And calls itself "inofficial mirror" Unfortunately, movableink/webkit seems to be even less stable or ready than qtwebkit/qtwebkit. For example, it is known that PyQt5 cannot be built against it [1], and there are packages in Debian which need it: $ reverse-depends python3-pyqt5.qtwebkit Reverse-Recommends == * linuxcnc-uspace [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * python3-ginga Reverse-Depends === * frescobaldi [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * manuskript * openshot-qt * python3-pyface * python3-qgis [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * python3-qtpy * qutebrowser-qtwebkit * yade [amd64 arm64] > Have a look at > > https://blogs.gnome.org/mcatanzaro/2022/11/04/stop-using-qtwebkit/ > > which calls qtwebkit insecure, poorly maintained, and cites CVEs about > remote code execution (some of them would have to be fixed in the fork, but > probably not in the version here in ubuntu). > > The problem is, that tools like wkhtmltopdf do use this library and are > typically used to pull contents from a given URL, i.e. from foreign > websites. > > Processing foreign HTML and Javascript code in conjunction with > vulnerabilities to remote code execution, this is highly dangerous. I absolutely agree. Projects like wkhtmltopdf should stop using Qt WebKit and should be ported to Qt WebEngine or other alternatives [2]. Once they do that, we will be able to remove Qt WebKit from Debian. Any help with filing bugs, both upstream and here in Debian, is welcome. It is also worth noting that our Release Notes explicitly mention [3] that Qt WebKit is not covered by security support, thus anyone who uses it with untrusted input data does so on their own risk. [1]: https://github.com/movableink/webkit/issues/16 [2]: ideally, they should be also ported from Qt 5 to Qt 6 [3]: https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1066320: astlib: FTBFS: PyWCSTools/wcssubs-3.9.5/wcscon_wrap.c:3533:3: error: implicit declaration of function ‘wcscon’; did you mean ‘wcstoq’? [-Werror=implicit-function-declaration]
Control: tags -1 + patch Hi, On Wed, Mar 13, 2024 at 12:47:51PM +0100, Lucas Nussbaum wrote: > Source: astlib > Version: 0.11.10-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > This is most likely caused by a change in dpkg 1.22.6, that enabled > -Werror=implicit-function-declaration. For more information, see > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration I have created a MR on salsa which fixes this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066320 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1068904: w: crashes because of the systemd support
Package: procps
Version: 2:4.0.4-4
Severity: normal
I noticed that w is segfaulting sometimes. Backtracing it showed the
issue. Running `w -hs` crashes. The main function passes NULL utmp entry
together with the systemd session, while later print_from expects to be
able to access the utmp data.
(gdb) r
Starting program: /tmp/procps-4.0.4/src/.libs/w -hs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
print_host (host=host@entry=0x4c ,
len=16, len@entry=256, fromlen=fromlen@entry=16) at src/w.c:112
112 if (*host == '\0') break;
(gdb) bt
#0 print_host (host=host@entry=0x4c , len=16, len@entry=256, fromlen=fromlen@entry=16) at src/w.c:112
#1 0x7371 in print_from (session=session@entry=0x0, u=u@entry=0x0,
ip_addresses=ip_addresses@entry=0, fromlen=fromlen@entry=16) at src/w.c:264
#2 0x7e6e in showinfo (session=0x555654d0 "1794",
name=name@entry=0xd800 "lumag", u=u@entry=0x0,
formtype=formtype@entry=0, maxcmd=maxcmd@entry=156, from=from@entry=1,
userlen=8, fromlen=16, ip_addresses=0, pids=0) at src/w.c:622
#3 0x671f in main (argc=, argv=) at
src/w.c:831
(gdb) list src/w.c:831
826 if (!strcmp(name, user))
827
showinfo(sessions_list[i], name, NULL, longform,
828 maxcmd, from,
userlen, fromlen,
829 ip_addresses,
pids);
830 } else {
831 showinfo(sessions_list[i],
name, NULL, longform, maxcmd,
832 from, userlen,
fromlen, ip_addresses, pids);
833 }
834 free(name);
835 free(sessions_list[i]);
(gdb) l src/w.c:264
259 if (len) { /* IP address is non-empty, print it (and
concatenate with display, if present) */
260 fputs(buf, stdout);
261 /* show the display part of the host or IPv6
link addr. interface, if present */
262 print_display_or_interface(u->ut_host,
UT_HOSTSIZE, fromlen - len);
263 } else { /* IP address is empty, print the host instead
*/
264 print_host(u->ut_host, UT_HOSTSIZE, fromlen);
265 }
266 } else { /* -i switch NOT used */
267 print_host(u->ut_host, UT_HOSTSIZE, fromlen);
268 }
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages procps depends on:
ii init-system-helpers 1.66
ii libc62.37-15
ii libncursesw6 6.4+20240113-1
ii libproc2-0 2:4.0.4-4
ii libsystemd0 255.4-1
ii libtinfo66.4+20240113-1
Versions of packages procps recommends:
ii psmisc 23.7-1
procps suggests no packages.
-- no debconf information
Bug#1068038: FTBFS: error: ‘struct input_event’ has no member named ‘time’
Control: tags -1 + pending Hi, On Sat, Mar 30, 2024 at 02:10:56AM +0500, Andrey Rakhmatullin wrote: > Source: flightgear > Version: 1:2020.3.18+dfsg-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=flightgear&arch=armhf&ver=1%3A2020.3.18%2Bdfsg-1%2Bb2&stamp=1711729288&raw=0 > > /<>/src/Input/FGLinuxEventInput.cxx: In member function ‘virtual > void FGLinuxInputDevice::Send(const char*, double)’: > /<>/src/Input/FGLinuxEventInput.cxx:418:7: error: ‘struct > input_event’ has no member named ‘time’ > 418 | evt.time.tv_sec = 0; > | ^~~~ > /<>/src/Input/FGLinuxEventInput.cxx:419:7: error: ‘struct > input_event’ has no member named ‘time’ > 419 | evt.time.tv_usec = 0; > | ^~~~ I have uploaded NMU which fixes this to DELAYED/2. The diff can be seen here: https://salsa.debian.org/debian/flightgear/-/merge_requests/3 It depends on my another NMU for simgear: unless simgear is rebuilt with the new time_t ABI, flightgear will fail to build with link failures. And simgear is a static library so we cannot just bump SONAME for it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060926: simgear: FTBFS: Compositor.hxx:137:34: error: field ‘_uniforms’ has incomplete type ‘simgear::compositor::Compositor::BuiltinUniforms’ {aka ‘std::array, 14>’}
Control: tags -1 + pending
Hi,
On Tue, Jan 16, 2024 at 08:36:13PM +0100, Lucas Nussbaum wrote:
> Source: simgear
> Version: 1:2020.3.18+dfsg-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240115 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > cd /<>/build/simgear && /usr/bin/c++ -DHAVE_CONFIG_H
> > -DHAVE_INTTYPES_H -I/<> -I/<>/build/simgear
> > -I/<>/build -I/usr/include/AL
> > -I/<>/simgear/canvas/ShivaVG/include
> > -I/<>/3rdparty/utf8/source -g -O2
> > -ffile-prefix-map=/<>=. -fstack-protector-strong
> > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> > -Wdate-time -D_FORTIFY_SOURCE=2 -msse2 -mfpmath=sse -ftree-vectorize
> > -ftree-slp-vectorize -Wall -fPIC -Wno-unused-local-typedefs
> > -DBOOST_BIMAP_DISABLE_SERIALIZATION -DBOOST_NO_STDLIB_CONFIG -O3 -g
> > -DNDEBUG -msse2 -mfpmath=sse -ftree-vectorize -ftree-slp-vectorize
> > -std=gnu++11 -MD -MT
> > simgear/CMakeFiles/SimGearScene.dir/sound/xmlsound.cxx.o -MF
> > CMakeFiles/SimGearScene.dir/sound/xmlsound.cxx.o.d -o
> > CMakeFiles/SimGearScene.dir/sound/xmlsound.cxx.o -c
> > /<>/simgear/sound/xmlsound.cxx
> > In file included from
> > /<>/simgear/scene/viewer/Compositor.cxx:17:
> > /<>/simgear/scene/viewer/Compositor.hxx:137:34: error: field
> > ‘_uniforms’ has incomplete type
> > ‘simgear::compositor::Compositor::BuiltinUniforms’ {aka
> > ‘std::array, 14>’}
> > 137 | BuiltinUniforms _uniforms;
> > | ^
> > In file included from /usr/include/c++/13/bits/hashtable_policy.h:34,
> > from /usr/include/c++/13/bits/hashtable.h:35,
> > from /usr/include/c++/13/bits/unordered_map.h:33,
> > from /usr/include/c++/13/unordered_map:41,
> > from
> > /<>/simgear/scene/viewer/Compositor.hxx:20:
> > /usr/include/c++/13/tuple:2005:45: note: declaration of
> > ‘simgear::compositor::Compositor::BuiltinUniforms’ {aka ‘struct
> > std::array, 14>’}
> > 2005 | template struct array;
> > | ^
I have uploaded NMU which fixes this and another build failure to DELAYED/2.
The diff can be seen here:
https://salsa.debian.org/debian/simgear/-/merge_requests/1
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1068155: lmms: FTBFS on i386: dh_install: warning: Cannot find (any matches for) "usr/lib/*/lmms/libvestige.so" (tried in ., debian/tmp)
Control: reassign -1 libwine-dev 9.0~repack-4 Control: affects -1 + src:lmms Hi all, On Tue, Apr 02, 2024 at 12:16:09PM +0200, Andreas Beckmann wrote: > Comparing bookworm and sid buildlogs shows the following relevant > differences during cmake: > > -Setting up libwine-dev:i386 (8.0~repack-4) ...^M > +Setting up libwine-dev:i386 (9.0~repack-4+b1) ...^M > > --- Found Wine: /usr/lib/i386-linux-gnu/wine/libwine.so > +CMake Warning (dev) at cmake/modules/FindWine.cmake:20 (EXEC_PROGRAM): > + Policy CMP0153 is not set: The exec_program command should not be called. > + Run "cmake --help-policy CMP0153" for policy details. Use the cmake_policy > + command to set the policy and suppress this warning. > + > + Use execute_process() instead. > +Call Stack (most recent call first): > + CMakeLists.txt:462 (FIND_PACKAGE) > +This warning is for project developers. Use -Wno-dev to suppress it. > + > +-- Could NOT find Wine (missing: WINE_LIBRARIES) > > -* VST-instrument hoster : OK, with workaround linking > /usr/lib/i386-linux-gnu/wine/i386-unix/libwinecrt0.a/ > -* VST-effect hoster : OK, with workaround linking > /usr/lib/i386-linux-gnu/wine/i386-unix/libwinecrt0.a/ > +* VST-instrument hoster : not found, please install (lib)wine-dev (or > similar) - 64 bit systems additionally need gcc-multilib and g++-multilib > +* VST-effect hoster : not found, please install (lib)wine-dev (or > similar) - 64 bit systems additionally need gcc-multilib and g++-multilib This is actually a bug in libwine-dev: libwine.so is a broken symlink: # ls -l /usr/lib/i386-linux-gnu/wine/libwine.so lrwxrwxrwx 1 root root 22 Mar 12 18:22 /usr/lib/i386-linux-gnu/wine/libwine.so -> i386-unix/libwine.so.1 # ls -l $(realpath /usr/lib/i386-linux-gnu/wine/libwine.so) ls: cannot access '/usr/lib/i386-linux-gnu/wine/i386-unix/libwine.so.1': No such file or directory The problem is not specific to i386, the same thing is on amd64: # ls -l $(realpath /usr/lib/x86_64-linux-gnu/wine/libwine.so) ls: cannot access '/usr/lib/x86_64-linux-gnu/wine/x86_64-unix/libwine.so.1': No such file or directory It's just lmms uses wine only on i386. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1067326: mkdocstrings: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hi Carsten! On Wed, Mar 20, 2024 at 10:00:48PM +0100, Lucas Nussbaum wrote: > Source: mkdocstrings > Version: 0.24.1-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240319 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > [...] > > The full build log is available from: > http://qa-logs.debian.net/2024/03/19/mkdocstrings_0.24.1-1_unstable.log Upstream released 0.24.2 today, which should fix this failure [1]. [1]: https://github.com/mkdocstrings/mkdocstrings/commit/c0d009000678a2cc -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1068078: FTBFS on armel: shiboken2:smart::smart_pointer Newly detected Real test failure!
Hi, (CCing debian-arm@l.d.o. Please CC me back as I’m not subscribed.) On Sat, Mar 30, 2024 at 02:11:32PM +0500, Andrey Rakhmatullin wrote: > Source: pyside2 > Version: 5.15.12-6.1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=pyside2&arch=armel&ver=5.15.12-6.1&stamp=1711789575&raw=0 > > RUN 2: Test project /<>/pyside3_build/py3.11-qt5.15.10-32bit- > relwithdebinfo/shiboken2 > RUN 2: Start 181: smart_smart_pointer > RUN 2: 1/1 Test #181: smart_smart_pointer ..***Failed0.23 sec > RUN 2: Running garbage collector for reference test > RUN 2: FFF > RUN 2: == > RUN 2: FAIL: testObjSmartPointer > (__main__.SmartPointerTests.testObjSmartPointer) > RUN 2: -- > RUN 2: Traceback (most recent call last): > RUN 2: File > "/<>/sources/shiboken2/tests/smartbinding/smart_pointer_test.py", > line 94, in testObjSmartPointer > RUN 2: self.assertEqual(integerCount(), 1) > RUN 2: AssertionError: 2 != 1 > [...] I tried to build pyside2 on two porterboxes, amdahl.d.o and abel.d.o, and on both it built successfully (in sid_armel-dchroot). I also ran the test manually several times after build, and it was successful too: (sid_armel-dchroot)mitya57@abel:~/pyside2-5.15.12/pyside3_build/py3.11-qt5.15.10-32bit-relwithdebinfo/shiboken2$ ctest --tests-regex '^(smart_smart_pointer)$' Test project /home/mitya57/pyside2-5.15.12/pyside3_build/py3.11-qt5.15.10-32bit-relwithdebinfo/shiboken2 Start 181: smart_smart_pointer 1/1 Test #181: smart_smart_pointer .. Passed0.48 sec 100% tests passed, 0 tests failed out of 1 Total Test time (real) = 0.53 sec Does anyone have ideas why there may be such difference between the buildds (arm-conova-01, arm-arm-03) and the porter boxes? It’s worth noting that the armhf build ran on the same arm-conova-01, and it was successful. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060724: meteo-qt: Please remove python3-sip Depends
Control: tags -1 + pending Dear Maintainer, On Sat, Jan 13, 2024 at 03:13:33PM +0300, Dmitry Shachnev wrote: > Package: meteo-qt > Version: 3.3-2 > Severity: important > Usertags: sip6 > > Dear Maintainer, > > Your package depends on python3-sip, which belongs to the deprecated sip4 > source package. > > The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages > in Debian are built with that modern version. > > python3-pyqt5 already depends on its SIP run-time module, python3-pyqt5.sip, > so there is no need to depend on it explicitly. I have uploaded a trivial fix for this to DELAYED/5. The NMU diff is available here: https://salsa.debian.org/lxqt-team/meteo-qt/-/merge_requests/3 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hi,
On Fri, Mar 22, 2024 at 03:30:55PM +0100, Holger Wansing wrote:
> Ok, I see.
> So, we will need to get sphinx-rtd-theme-common installed on all debian.org
> website mirrors, and it will just work (?) ...
From your earlier message it seemed to me like you are using the build
tree in your deploy process, not the built package.
That is why I suggested not running dh_sphinxdoc, however my suggestion
applied only to your deploy procedure. The package which is being uploaded
to Debian archive should still use dh_sphinxdoc.
If you are using the built package and installing it on the remote server,
then yes, install sphinx-rtd-theme-common and you should be good.
Actually, I would move ${sphinxdoc:Depends} from Recommends to Depends,
because the documentation is mostly unusable without the static files.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
On Fri, Mar 22, 2024 at 01:46:48PM +0100, Holger Wansing wrote: > [...] > Anyway, the symlink points to some path inside the package build path, here: > /srv/debian-policy/debian-policy-4.6.2.1/debian/debian-policy/usr/share/sphinx_rtd_theme_static/css/theme.css > > and that path does not exist. > Same in the debian-policy binary package. This is expected. The path in the build tree is relative in a way that when a package is built and installed, it becomes working. The symlink is generated relative per Policy 10.5. And I think that even if dh_sphinxdoc generated it as absolute, dh_link would later change it to relative. If you are trying to rely on something that is in the build directory, you have to turn relative symlinks into absolute ones on your own. Or just don't call dh_sphinxdoc, then you will get normal files. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Control: tags 1066967 +unreproducible
Hi Holger!
On Sat, Mar 16, 2024 at 09:52:54AM +0100, Holger Wansing wrote:
> Package: sphinx-common
> Severity: serious
>
> Hi,
>
> dh_sphinxdoc does not work well with read-the-doc theme, apparently.
> Debian policy document has switched to sphinx_rtd_theme recently (see
> https://salsa.debian.org/dbnpolicy/policy/-/commit/686622814018b5a121252b189d99c1968f332b78
> )
>
> However, the built document has a completely broken html layout, because
> many files under _static/ are empty (0B size), most noteably
> _static/css/theme.css.
>
> If I replace
> dh $@ --with sphinxdoc
> by
> dh $@
> (so do not use dh_sphinxdoc), I get a valid html file with the theme
> in use.
I cannot reproduce this. I downloaded debian-policy source package and built
it in an up-to-date sid chroot. And the built package has this:
$ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css
lrwxrwxrwx root/root 0 2024-02-24 15:39
./usr/share/doc/debian-policy/policy.html/_static/css/theme.css ->
../../../../../sphinx_rtd_theme/static/css/theme.css
So, it is a symlink, not an empty file. When resolving the relative path,
I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file
exists in sphinx-rtd-theme-common and is non-empty.
The only issue I see is that sphinx-rtd-theme-common is in Recommends of
debian-policy, not in Depends. But that is because ${sphinxdoc:Depends}
was put there.
Am I doing something wrong?
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1067442: contains files for different architecture
Package: syslinux-efi Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3 Severity: grave X-Debbugs-Cc: dbarysh...@gmail.com The ARM64 syslinux-efi package binaries for x86 instead instead of ARM binaries: $ uname -m aarch64 $ file /usr/lib/SYSLINUX.EFI/efi*/syslinux.efi /usr/lib/SYSLINUX.EFI/efi32/syslinux.efi: PE32 executable (EFI application) Intel 80386 (stripped to external PDB), for MS Windows /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows As such these binaries are unusable on ARM64 hosts. -- System Information: Debian Release: 12.5 APT prefers stable APT policy: (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.6.9-qcomlt-arm64-00188-g31f49428dc7d (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) syslinux-efi depends on no packages. Versions of packages syslinux-efi recommends: ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 Versions of packages syslinux-efi suggests: ii dosfstools 4.2-1 -- no debconf information
Bug#1067009: lomiri-ui-toolkit: FTBFS: 63 failures which MUST be fixed
Source: lomiri-ui-toolkit Version: 1.3.5012+dfsg-5 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Control: block 1061179 by -1 Dear Maintainer, As can be seen in [1], the package failed to build on buildds in unstable. The relevant part is: /<>/tests/checkresults.sh /<>/tests/*.xml || exit 1; 63 failures which MUST be fixed: tst_scrollbar.13.qml tst_scrollbar_header.13.qml tst_scrollview.13.qml The reasons why the tests failed can be found by searching for FAIL!. E.g., the first test failed with this error: FAIL! : components::Scrollbar::test_defaultStylingValues(vertical scrollbar) Uncaught exception: Cannot read property 'interactive' of null Loc: [/<>/tests/unit/visual/tst_scrollbar.13.qml(1187)] [1]: https://buildd.debian.org/status/package.php?p=lomiri-ui-toolkit -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1059264: qbs: ftbfs on riscv64: test timeout
Hi! On Sun, Mar 03, 2024 at 03:14:58PM +0800, Bo YU wrote: > Due to 2.1.2-2.1 was t64 transition related, so I have to generate > debdiff based on 2.1.2-2. So please let me know if any issue. > > I should wait the 64 trsansition to finish but not sure how long it will > to achive this. Right. I committed the patch so it will be part of the next upload, but I am not uploading it until the current version migrates to testing. Also, our debian/rules includes /usr/share/dpkg/default.mk which in turn includes architecture.mk, so $(DEB_BUILD_ARCH_CPU) is defined and there is no need to call dpkg-architecture explicitly. I have updated the patch based on that. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1064994: O: ima-evm-utils -- Linux IMA Extended Verification Module signing tools
Package: wnpp Severity: normal X-Debbugs-Cc: ima-evm-ut...@packages.debian.org Control: affects -1 + src:ima-evm-utils I intend to orphan the ima-evm-utils package. The package description is: Linux kernel integrity subsystem is comprised of a number of different components including the Integrity Measurement Architecture (IMA), Extended Verification Module (EVM), IMA-appraisal extension, digital signature verification extension and audit measurement log support. . The package provides the Linux Integrity Measurement Architecture (IMA) Extended Verification Module (EVM) tools. . With EVM, the security sensitive extended attributes are verified against offline tampering. Unfortunately I'm no longer using this package and I don't have time to properly maintain it. Thus I'm orphaning the package in the hope that somebody can pick it up. Ping me if you'd like me to transfer the ownership of the repo on salsa. -- With best wishes Dmitry
Bug#1062946: 64-bit time_t transition in progress
Control: tags 1062723 -pending Control: tags 1062747 -pending Control: tags 1062749 -pending Control: tags 1062750 -pending Control: tags 1062751 -pending Control: tags 1062758 -pending Control: tags 1062759 -pending Control: tags 1062760 -pending Control: tags 1062762 -pending Control: tags 1062763 -pending Control: tags 1062764 -pending Control: tags 1062766 -pending Control: tags 1062940 -pending Hi all, On Thu, Feb 08, 2024 at 01:06:40PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! > > On Fri, 2 Feb 2024 at 13:22, Steve Langasek wrote: > > > > Dear developers, > > > > A number of you will have noticed already that the 64-bit time_t transition > > is now in progress in Debian experimental. > [snip] > > >qt6-virtualkeyboard > >qt-qml-models > > For all Qt packages, be it Qt 5 or 6, you only need to modify > libqtXcoreX. The rest of the packages will just follow suite, > **nothing** in Qt does not depends upon libQtCoreX. In fact I would > say that by doing that you get even the whole KDE stack in. Lisandro is right, it is enough to NMU only qtbase. All other Qt submodules depend on libqtXcoreX, so they just need to be binNMUed to rebuild against the new version, changing SONAMEs is not needed. So removing pending tags from Qt modules other than qtbase, to exclude them from upload list. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1059264: qbs: ftbfs on riscv64: test timeout
Hi! On Fri, Dec 22, 2023 at 05:25:52PM +0800, Bo YU wrote: > Package: qbs > Version: 1.24.1+dfsg-2 > Severity: important > Tags: ftbfs patch > User: debian-ri...@lists.debian.org > Usertags: riscv64 > X-Debbugs-Cc: debian-ri...@lists.debian.org > > Dear Maintainer, > > qbs has ftbfs on riscv64 since 2.1.1-2(2023/08) on sid. The problem is > due to timeout on buildd machines for riscv64 now: > > [...] > > So we can see the timeout on tst_blackbox-qt suite mainly. But the > question is that failed test function cases are randomized. So I have > captured a few cases to temporarily skip over riscv64 buildd(holpe this > works). And I would like to suggest that we keep opening the reportbug > until we have more powerful buildd machines to close it as expected > it. I can build it on vf2 without any patch but it has not been tested > many times. > > So could you apply it on next upload or any ideas? I would prefer increasing the timeout to disabling the test. The blackbox tests start qbs in a subprocess and wait for it to finish in a reasonable time [1]. The value of testTimeoutInMsecs() can be configured by QBS_AUTOTEST_TIMEOUT environment variable, which specifies time in seconds and is 600 by default, which is 10 minutes. However, Qt test library has its own timeout: any test function call is interrupted in 5 minutes [2]. This can be configured by QTEST_FUNCTION_TIMEOUT variable, which is in milliseconds. It looks like this is the timeout that occurs in the log fragments you provided. Do you have any way to check if increasing QTEST_FUNCTION_TIMEOUT helps to get it built on slow riscv64 machines. And if yes, to what value it should be increased? [1]: https://sources.debian.org/src/qbs/2.1.2-2/tests/auto/blackbox/tst_blackboxbase.cpp/#L100 [2]: https://doc.qt.io/qt-6/qtest-overview.html#increasing-test-function-timeout -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#884119: libdbi1: dbi_result_next_row() error handler change breaks existing code
Hi, I encountered this bug while trying to use gammu-smsd (1.42.0-8) with libdbi1 (0.9.0-6) + libdbd-sqlite3 (0.9.0-11) on debian buster. The gammu-smsd does not exit for me, but it spams the log with the "An invalid or out-of-range index was passed to libdbi" error message periodically. I am not sure if it is fully functional with this error message or not. Rebuilding libdbi1 without re-enable_call_to_error_handler.patch made the error message go away. It's been a while since this bug was opened, is there something blocking us from applying this fix or did it just slip through the cracks? I guess that theoretically there's a possibility that there's now some other software that depends on this new behavior :( Having said that, I peeked at the most recent libdbi package source in another distribution, and this call to error handler is still commented out there. On Fri, 9 Nov 2018 07:25:15 +0100 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > On Mon, Jan 22, 2018 at 11:21 PM gotodimas wrote: > > > > This bug breakes gammu-smsd. Daemon exit with error: > > > > gammu-smsd[2018]: DBI error -6: -6: An invalid or out-of-range index was passed to libdbi > This is bad. :( > > > Reverting libdbi1 to 0.9.0-4 (not 0.9.0-4+deb9u1) fixes this problem. > Going to ask for a package update with the attached patch. > > Regards, > Laszlo/GCS
Bug#1060761: lomiri-ui-toolkit: FTBFS with Qt ≥ 5.15.11: error: invalid use of non-static member function ‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’
Hi James! On Thu, Feb 15, 2024 at 05:17:00PM +, James Addison wrote: > Source: lomiri-ui-toolkit > Followup-For: Bug #1060761 > X-Debbugs-Cc: sunwea...@debian.org, mity...@debian.org > > Hi Mike, Dmitry, > > Is the second patch here (to disable the failing unit test) likely to be > uploaded to unstable in the nearish future? > > I'm eager to see the results of some build reproducibility improvements in > qttools from 5.15.12 (#1059592, #1059631) and this is tagged as a blocker for > the relevant qtbase ABI migration. I don’t think the start of Qt transition is blocked by this bug. I rather think that there are many transition requests and mine waits in the queue. Because it is going to take longer than I expected, I have now uploaded the qttools patches to unstable. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1056419: Spinx help needed
Hi Andreas! On Thu, Feb 15, 2024 at 08:37:38AM +0100, Andreas Tille wrote: > Control: tags -1 pending > > Hi, > > I pushed fixes for #1056419 and #1058311 to Git and I think should be > fixed as well. The only remaining build problem is new and caused by > sphinx[1]: > > dh_sphinxdoc -i -O--buildsystem=pybuild > dh_sphinxdoc: error: > debian/python-lmfit-doc/usr/share/doc/python3-lmfit/html/search.html > top-level node does not have data-content_root attribute > > Unfortunately I have no idea how to fix this. Any ideas? lmfit-py ships a vendored copy of sphinx13 theme [1], which was copied from Sphinx source code with a minor modification in 2020 [2] and rebased in January 2022 [3]. However, there were more Sphinx releases since that month, and the theme needs to be updated for compatibility with them. In particular, the basic_layout.html file misses the change which was made in Sphinx commit [4], without which the search will not work. There is a comment under that commit which illustrates how exactly it will not work: contentRoot will be undefined, and the browser will attempt to make requests to a URL that has "undefined" in it. dh_sphinxdoc catches such issues and produces an error about them. So, to fix this issue, you should copy sphinx/themes/basic/layout.html from the latest stable version of Sphinx to lmfit-py's basic_layout.html, applying the one-line change which is described in [2] and [3]. [1]: doc/sphinx/theme/sphinx13/* [2]: https://github.com/lmfit/lmfit-py/commit/29e4712036606913149e16b246340a7fbedd8829 [3]: https://github.com/lmfit/lmfit-py/commit/e2418377c9870e02c820d0fe40d2232187864a81 [4]: https://github.com/sphinx-doc/sphinx/commit/8e730ae303ae686705ea12f44ef11da926a87cf5 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1050693: sphinx: unreproducible output if the same function has two entries in the table of contents
Hi Rebecca, and sorry for the late response! On Mon, Aug 28, 2023 at 11:39:05AM +0100, Rebecca N. Palmer wrote: > Package: python3-sphinx > Version: 5.3.0-7 > Severity: wishlist > User: reproducible-bui...@lists.alioth.debian.org > Usertags: fileordering > > When the same function has two entries in the table of contents, that > function's documentation page may be generated with the table of contents > open to either of those two entries. (Probably based on filesystem order, > i.e. which entry gets processed first, but I don't actually know that.) > > For example, pandas DataFrame.to_* are listed in both reference/io.rst and > reference/frame.rst: > https://salsa.debian.org/science-team/pandas/-/jobs/4617327 In the log referenced by you there is indeed diff for /usr/share/doc/python-pandas-doc/html/reference/api/pandas.DataFrame.to_*.html files. However, I don't see any diff in the recent pandas reprotest logs, e.g. in these ones: - https://salsa.debian.org/science-team/pandas/-/jobs/5232189 - https://salsa.debian.org/science-team/pandas/-/jobs/5268239 - https://salsa.debian.org/science-team/pandas/-/jobs/5273611 There is no diff for /usr/share/doc/python-pandas-doc/html/reference/* at all. Maybe this bug no longer happens in Sphinx 7.2 (which was uploaded to unstable on 2023-11-05)? Or it just happens rarely and the CI can't always catch it? If we manage to reproduce it, the next step would be identifying whether this is a problem in autosummary extension, or can be reproduced without it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1063326: TypeError: first argument must be callable
Hi Frédéric! On Tue, Feb 06, 2024 at 09:32:45AM +0100, Picca Frédéric-Emmanuel wrote: > Package: python3-sphinx > Version: 5.3.0-4 > Severity: important > > Dear Maintainer, > > Hello, while preparing the new silx package, I got this error message from > sphinx when calling this command line > > [...] > > File "/usr/lib/python3/dist-packages/sphinx/registry.py", line 353, in > create_translator > setattr(translator, 'visit_' + name, MethodType(visit, translator)) > ^ > TypeError: first argument must be callable This is because sphinx-panels defines the handler for "fontawesome" role for manpage builder as (None, None): https://sources.debian.org/src/sphinx-panels/0.6.0-3/sphinx_panels/icons.py/#L144 While Sphinx expects at least the visit function (the first pair element) to be not None. However, sphinx-panels is dead, and upstream recommends to use sphinx-design instead. And in sphinx-design this bug is fixed: https://sources.debian.org/src/sphinx-design/0.5.0-2/sphinx_design/icons.py/#L42 https://github.com/executablebooks/sphinx-design/pull/88 If you want a fix in sphinx-panels, please reassign the bug. Otherwise, if you have found another solution, please close it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061206: Please upgrade to llvm-toolchain-17
Hi Sylvestre! On Sat, Jan 20, 2024 at 09:57:51PM +0100, Sylvestre Ledru wrote: > Source: pyside2 > Severity: important > > Dear Maintainer, > > As part of the effort to limit the number of llvm packages in the > archive, it would be great if you could upgrade to -17. > > This package depends on 15. It was not easy, but I backported 9 patches from upstream 6.x branch and added one my patch on top of them, and now pyside2 can build with LLVM 16 and LLVM 17. I did as you suggested and forced build with 17, and uploaded to unstable. However now it dep-waits on mips64el, because llvm-toolchain-17 failed to build there. Should I roll back to the default version (16) for now? Or this will be resolved somehow? I will need rebuilding pyside2 for Qt 5.15.12 transition soon, and if it does not build on mips64el, that will prevent Qt from migrating. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060761: fixed in lomiri-ui-toolkit 1.3.5012+dfsg-1
Control: reopen -1
Control: forwarded -1
https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/issues/34
Hi Mike!
On Fri, Feb 02, 2024 at 12:34:40AM +, Debian FTP Masters wrote:
> Source: lomiri-ui-toolkit
> Source-Version: 1.3.5012+dfsg-1
> Done: Mike Gabriel
>
> We believe that the bug you reported is fixed in the latest version of
> lomiri-ui-toolkit, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
In the original bug report, I mentioned that there are two issues.
The new upstream release fixes the first one, but not the second one.
As a temporary measure until upstream fixes this properly, I can suggest
the attached patch that I applied in Ubuntu.
--
Dmitry Shachnev
Description: disable the test that fails with Qt 5.15.11
Author: Dmitry Shachnev
Forwarded: not-needed
Bug: https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/issues/34
Last-Update: 2024-01-13
--- a/tests/unit/units/dpr1/tst_units.cpp
+++ b/tests/unit/units/dpr1/tst_units.cpp
@@ -41,6 +41,7 @@ private Q_SLOTS:
QCOMPARE(units.gridUnit(), 42.0f);
}
+#if QT_VERSION < QT_VERSION_CHECK(5, 15, 11)
void gridUnitEnvironmentVariable() {
QByteArray gridUnit = QString::number(11).toLocal8Bit();
qputenv("GRID_UNIT_PX", gridUnit);
@@ -48,6 +49,7 @@ private Q_SLOTS:
QCOMPARE(units.gridUnit(), 11.0);
qunsetenv("GRID_UNIT_PX");
}
+#endif
void dpGridUnitDefault() {
UCUnits units;
signature.asc
Description: PGP signature
Bug#1060802: stellarium: FTBFS on armel, ppc64el, s390x: unsatisfiable Build-Depends: qtwebengine5-dev (>= 5.15)
Hi James! On Wed, Jan 31, 2024 at 11:57:52PM +, James Addison wrote: > Source: stellarium > Followup-For: Bug #1060802 > X-Debbugs-Cc: tom...@debian.org, mity...@debian.org > > > stellarium 23.4-1 added a new build-dependency on qtwebengine5-dev, which > > prevents it from building on some release architectures (and all non-release > > ones). > > Would 'qtwebengine5-dev | libqt5webkit5-dev' provide an acceptable alternative > build dependency spec? > > Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913043;msg=10 Qt WebEngine and (deprecated) Qt WebKit are not compatible with each other, they provide different sets of classes. And it looks like upstream stellarium only supports Qt WebEngine, not WebKit. Good news is that Qt WebEngine support is optional and you can just build without it on architectures where it's not available. This can be achieved by limiting the build-dependency: qtwebengine5-dev (>= 5.15) [amd64 arm64 armhf i386 mips64el], I did that in Ubuntu [1] and the package built on all Ubuntu's architectures. [1]: https://launchpad.net/ubuntu/+source/stellarium/23.4-1ubuntu1 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060725: qutebrowser: Please remove python3-sip Depends
Hi Fritz! On Tue, Jan 30, 2024 at 11:12:28PM +0100, Fritz Reichwald wrote: > Hi Dimitry, > > thank you for the report. > I just uploaded a 2.5.4-2 without the dependency as it is no longer > needed as you already stated. Thank you for fixing this! -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061679: libqt5datavisualization5: Crashes in Q3DBars destructor on mips64el
Package: libqt5datavisualization5
Version: 5.15.10-2
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org
The following C++ program crashes on exit on mips64el:
#include
#include
#include
int main(int argc, char **argv) {
QApplication app(argc, argv);
QtDataVisualization::Q3DBars bars;
bars.show();
QTimer::singleShot(5000, app.quit);
return app.exec();
}
The stack trace is:
Thread 1 "test" received signal SIGABRT, Aborted.
0x00fff64599c4 in __pthread_kill_implementation (threadid=,
signo=, no_tid=) at pthread_kill.c:43
43 pthread_kill.c: No such file or directory.
(gdb) bt
#0 0x00fff64599c4 in __pthread_kill_implementation (threadid=, signo=, no_tid=) at pthread_kill.c:43
#1 0x00fff6403f48 in __GI_raise (sig=) at
../sysdeps/posix/raise.c:26
#2 0x00fff63ea8b4 in __GI_abort () at abort.c:79
#3 0x00fff6448b98 in __libc_message (fmt=) at
../sysdeps/posix/libc_fatal.c:150
#4 0x00fff6467804 in malloc_printerr (str=) at malloc.c:5658
#5 0x00fff646a11c in _int_free (av=0xfff65a0ad0 ,
p=0xaab7e352d0, have_lock=) at malloc.c:4584
#6 0x00fff646d014 in __GI___libc_free (mem=0xaab7e352e0) at malloc.c:3367
#7 0x00fff1c99d34 in _XShmDestroyImage (ximage=) at
../../src/XShm.c:265
#8 0x00fff1ddf014 in XCreateDrawable (pdp=0xaab6e5a5e0, shmid=-1,
dpy=0xaed340) at ../src/glx/drisw_glx.c:67
#9 0x00fff1ddfcec in swrastXPutImage (srcx=0, x=0, y=0, w=160,
h=, stride=640, shmid=, data=0xfff0804000
"\377\377\377", loaderPrivate=0xaab6e5a5e0,
op=, draw=, srcy=0) at
../src/glx/drisw_glx.c:197
#10 0x00fff09f5f68 in put_image2 (stride=, height=, width=, y=, x=,
data=,
drawable=) at ../src/gallium/frontends/dri/drisw.c:74
#11 drisw_put_image2 (drawable=, data=,
x=, y=, width=, height=, stride=)
at ../src/gallium/frontends/dri/drisw.c:174
#12 0x00fff112bd98 in dri_sw_displaytarget_unmap (ws=,
dt=0xadee30) at ../src/gallium/winsys/sw/dri/dri_sw_winsys.c:208
#13 0x00fff112df1c in softpipe_transfer_unmap (pipe=,
transfer=0xaab7e34d80) at ../src/gallium/drivers/softpipe/sp_texture.c:468
#14 0x00fff114d4b8 in sp_tile_cache_set_surface (tc=0xc8bab0, ps=0x0)
at ../src/gallium/drivers/softpipe/sp_tile_cache.c:179
#15 0x00fff1141150 in softpipe_set_framebuffer_state (pipe=0xb92da0,
fb=0xff2bf0) at ../src/gallium/drivers/softpipe/sp_state_surface.c:68
#16 0x00fff106a4e8 in cso_unbind_context (ctx=0xc24e30) at
../src/gallium/auxiliary/cso_cache/cso_context.c:456
#17 0x00fff106a6c0 in cso_destroy_context (ctx=0xc24e30) at
../src/gallium/auxiliary/cso_cache/cso_context.c:490
#18 0x00fff0ae67c8 in st_destroy_context_priv (st=0xc233d0,
destroy_pipe=true) at ../src/mesa/state_tracker/st_context.c:369
#19 0x00fff0ae856c in st_destroy_context (st=0xc233d0) at
../src/mesa/state_tracker/st_context.c:1018
#20 0x00fff09fc078 in dri_destroy_context (ctx=0xc8f0a0) at
../src/gallium/frontends/dri/dri_context.c:277
#21 0x00fff0a00cd4 in driDestroyContext (pcp=) at
../src/gallium/frontends/dri/dri_util.c:668
#22 0x00fff1ddecbc in drisw_destroy_context (context=0xc8ef20) at
../src/glx/drisw_glx.c:431
#23 0x00fff1de1ef0 in glXDestroyContext (ctx=0xc8ef20,
dpy=0xaed340) at ../src/glx/glxcmds.c:469
#24 glXDestroyContext (dpy=0xaed340, ctx=0xc8ef20) at
../src/glx/glxcmds.c:450
#25 0x00fff1e98c78 in QGLXContext::~QGLXContext (this=0xffec003120,
__in_chrg=) at qglxintegration.cpp:541
#26 QGLXContext::~QGLXContext (this=0xffec003120, __in_chrg=) at
qglxintegration.cpp:542
#27 0x00fff7162204 in QOpenGLContext::destroy (this=0xb65650) at
kernel/qopenglcontext.cpp:653
#28 0x00fff71626ac in QOpenGLContext::~QOpenGLContext (this=0xb65650,
__in_chrg=) at kernel/qopenglcontext.cpp:691
#29 0x00fff71626f8 in QOpenGLContext::~QOpenGLContext (this=0xb65650,
__in_chrg=) at kernel/qopenglcontext.cpp:696
#30 0x00fff6cc9c58 in QObjectPrivate::deleteChildren (this=0xb238d0) at
kernel/qobject.cpp:2137
#31 0x00fff6cdabe0 in QObject::~QObject (this=,
__in_chrg=) at kernel/qobject.cpp:1115
#32 0x00fff7107ad0 in QWindow::~QWindow (this=0xff3060,
__in_chrg=) at kernel/qwindow.cpp:227
#33 0x00fff7e87300 in
QtDataVisualization::QAbstract3DGraph::~QAbstract3DGraph (this=0xff3060,
__in_chrg=)
at /usr/include/mips64el-linux-gnuabi64/qt5/QtGui/qopenglfunctions.h:242
#34 0x00fff7e8b0d4 in QtDataVisualization::Q3DBars::~Q3DBars
(this=, __in_chrg=) at engine/q3dbars.cpp:120
#35 0x00aa992c in main (argc=1, argv=0xff3248) at
datavisualization_test.cpp:12
I was not able to analyze this problem with valgrind, as valgrind itself
crashes with SIGILL.
The problem does not happen on amd64, even if I force software rendering with
LIBGL_ALWAYS_SOFTWARE=1.
Any help with this is welcome.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1060741: ball: Please port from sip4 to sip6
Hi Andreas! On Sat, Jan 27, 2024 at 07:56:46AM +0100, Andreas Tille wrote: > I gave it a try by changing the Build-Depends first[1] and see what > happens[2]. I think the problem is caused by this Python file[3] where > I tried to replace > > import sipconfig > > by > > import sipbuild > > Since I'm lacking the knowledge about the new interface (and was not > able to find the solution after a *quick* search in sip6-doc) I gave up > here and ask for help. I could forward the issue upstream but I would > like to have a first idea about a patch. It is much more complicated than just changing the module name. SIP v4 (and v5, in compatibility mode) had a command-line tool that accepted all relevant details about project configuration as command-line arguments. In SIP v6, the project should have a pyproject.toml and, in most cases, project.py files for that purpose. See [1] and [2] for examples of such files. Sometimes, when the content of pyproject.toml can not be static, and it needs to be generated at build time. For example, krita [3] and QGIS [4] do that. If you want to see how a patch for porting to the new build system could look like, take a look at [5] or [6]. There is an alternative approach that involves using sipbuild API directly, without pyproject.toml file, however that API is poorly documented and can change between releases. But as porting is a major work (and sorry, I am more busy than I was in 2021 and I don't have time for that), I would recommend contacting upstream and providing this information to them first. If a project is active, they will have to do that anyway (SIP v4 does not support Python 3.11+). If the project is dead, maybe it's not worth it, and ball should be removed from Debian? [1]: https://github.com/frescobaldi/python-poppler-qt5/blob/master/pyproject.toml [2]: https://github.com/frescobaldi/python-poppler-qt5/blob/master/project.py [3]: https://invent.kde.org/graphics/krita/-/blob/master/cmake/modules/SIPMacros.cmake [4]: https://github.com/kadas-albireo/QGIS/blob/master/python/CMakeLists.txt [5]: https://github.com/GauiStori/PyQt-Qwt/pull/14 [6]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964127#51 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061454: python3-dput: Does not work with Python 3.12: 'ConfigParser' object has no attribute 'readfp'
Package: python3-dput Version: 1.37 Severity: important User: debian-pyt...@lists.debian.org Usertags: python3.12 Dear Maintainer, This module seems to be incompatible with Python 3.12: $ dput ftp-master sip6_6.8.2+dfsg-1_source.changes Traceback (most recent call last): File "/usr/bin/dput", line 129, in upload_package(changes, args) File "/usr/lib/python3/dist-packages/dput/uploader.py", line 274, in invoke_dput profile = dput.profile.load_profile(args.host) File "/usr/lib/python3/dist-packages/dput/profile.py", line 191, in load_profile _multi_config = MultiConfig() ^ File "/usr/lib/python3/dist-packages/dput/profile.py", line 85, in __init__ self.preload(configs) File "/usr/lib/python3/dist-packages/dput/profile.py", line 101, in preload classes[obj['type']]( File "/usr/lib/python3/dist-packages/dput/config.py", line 42, in __init__ self.preload(configs) File "/usr/lib/python3/dist-packages/dput/configs/dputcf.py", line 60, in preload parser.readfp(open(config, 'r')) ^ AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you mean: 'read'? Quoting Python 3.12 changes page: > Several names deprecated in the configparser way back in 3.2 have been > removed per gh-89336: > > [...] > - configparser.ConfigParser no longer has a readfp method. Use read_file() > instead. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061179: transition: qtbase-abi-5-15-12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 1060761 1060802 Dear Release team, I have skipped Qt 5.15.11 release and would like to upgrade to 5.15.12 which was published in December. Qt WebEngine will be upgraded from 5.15.15 to 5.15.16. The transition is prepared in experimental. There are two blockers, lomiri-ui-toolkit and stellarium, but I can NMU them. I have submitted a merge request with the ben file: https://salsa.debian.org/release-team/transition-data/-/merge_requests/47 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060802: stellarium: FTBFS on armel, ppc64el, s390x: unsatisfiable Build-Depends: qtwebengine5-dev (>= 5.15)
Source: stellarium Version: 23.4-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: ftbfs Dear Maintainer, stellarium 23.4-1 added a new build-dependency on qtwebengine5-dev, which prevents it from building on some release architectures (and all non-release ones). Upstream mentions [1] that Qt WebEngine build-dependency is optional and can be either detected automatically by the build system, or configured explicitly using -DENABLE_QTWEBENGINE=ON/OFF [2]. Qt WebEngine is available only amd64, arm64, armhf, i386 and mips64el, and it's unlikely that this set of architectures will be changed for Qt 5. So you can limit the build-dependency to these architectures. [1]: https://github.com/Stellarium/stellarium/blob/master/BUILDING.md#linux-without-qtwebengine [2]: https://github.com/Stellarium/stellarium/blob/master/BUILDING.md#supported-cmake-parameters -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1058371: python-cloup: FTBFS: make[1]: *** [Makefile:20: html] Error 2
Control: reassign -1 python3-astroid 2.15.6-1 Control: retitle -1 python3-astroid: incompatible with Python 3.12 (exception: 'TreeRebuilder' object has no attribute 'visit_typealias') Control: affects -1 + src:python-cloup src:sphinx-autoapi Control: block 1056529 1058408 by -1 Control: tags -1 + fixed-upstream Hi all, On Tue, Dec 12, 2023 at 09:27:12AM +0100, Lucas Nussbaum wrote: > Source: python-cloup > Version: 3.0.3-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20231212 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > make[1]: Entering directory '/<>/docs' > > Running Sphinx v7.2.6 > > making output directory... done > > /usr/lib/python3/dist-packages/autoapi/extension.py:137: > > RemovedInSphinx80Warning: Sphinx 8 will drop support for representing paths > > as strings. Use "pathlib.Path" or "os.fspath" instead. > > elif app.srcdir != os.getcwd(): > > /usr/lib/python3/dist-packages/autoapi/mappers/python/mapper.py:300: > > RemovedInSphinx80Warning: The alias 'sphinx.util.status_iterator' is > > deprecated, use 'sphinx.util.display.status_iterator' instead. Check > > CHANGES for Sphinx API modifications. > > for dir_root, path in sphinx.util.status_iterator( > > [2K[AutoAPI] Reading files... [ 4%] /<>/cloup/__init__.py > > [2K[AutoAPI] Reading files... [ 9%] /<>/cloup/_util.py > > [2K[AutoAPI] Reading files... [ 13%] /<>/cloup/_sections.py > > [2K[AutoAPI] Reading files... [ 17%] /<>/cloup/_commands.py > > > > Extension error (autoapi.extension): > > Handler for event 'builder-inited' > > threw an exception (exception: 'TreeRebuilder' object has no attribute > > 'visit_typealias') > > make[1]: *** [Makefile:20: html] Error 2 This is actually caused by astroid 2.15 being incompatible with Python 3.12. In upstream it was fixed in commit [1], which is part of a larger PR [2] that adds support for Python 3.12. These changes were included in astroid 3.0, so updating to that release should fix the problem. [1]: https://github.com/pylint-dev/astroid/commit/6d4f364a08289bf3 [2]: https://github.com/pylint-dev/astroid/pull/2219 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060734: Acknowledgement (Add more dev dependencies)
libsail 0.9.1 is out, so it's a good time to update the version as well. -- Dmitry сб, 13 янв. 2024 г. в 18:06, Debian Bug Tracking System < ow...@bugs.debian.org>: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1060734: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060734. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Sudip Mukherjee > > If you wish to submit further information on this problem, please > send it to 1060...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1060734: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060734 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#1060761: lomiri-ui-toolkit: FTBFS with Qt ≥ 5.15.11: error: invalid use of non-static member function ‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’
Source: lomiri-ui-toolkit
Version: 1.3.5010+dfsg-3
Severity: important
Tags: ftbfs upstream
Dear Maintainer,
lomiri-ui-toolkit fails to build with Qt ≥ 5.15.11. Currently there is version
5.15.12 available in experimental, but I would like to upload it to unstable
soon.
The first error is:
ucstylehints.cpp: In member function ‘void
UCStyleHintsParser::verifyProperty(const
QQmlRefPointer&, const
QV4::CompiledData::Binding*)’:
ucstylehints.cpp:54:23: error: invalid use of non-static member function
‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’
54 | if (binding->type == QV4::CompiledData::Binding::Type_Object) {
| ~~^~
In file included from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qv4executablecompilationunit_p.h:54,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlcontext_p.h:69,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlproperty_p.h:60,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlbinding_p.h:59,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlcustomparser_p.h:55,
from ucstylehints_p.h:25,
from ucstylehints.cpp:19:
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qv4compileddata_p.h:544:10:
note: declared here
544 | Type type() const { return Type(flagsAndType.get()); }
| ^~~~
This error is fixed by upstream pull request [1], however there is another
issue with tst_UCUnits::gridUnitEnvironmentVariable() test which is not yet
fixed upstream. Perhaps it can be disabled until upstream figures out what to
do with it.
[1]:
https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/merge_requests/63
[2]: https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/issues/34
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1059648: sip4: autopkgtest failure with Python 3.12
On Sun, Jan 07, 2024 at 06:34:24PM +0300, Dmitry Shachnev wrote: > krita and pyqwt3d have open bugs to move to sip6, but I will need to file > bugs for the other packages too. All the missing bugs are filed now: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=mity...@debian.org;tag=sip6 -- Dmitry Shachnev signature.asc Description: PGP signature
