Bug#890472: Status for Vulkan development tools?
Hi! Any news on this submission? Is anything blocking it or is it lack of maintainers? Thanks! On Mon, 13 Jul 2020 09:57:25 -0600 John Zupin wrote: > Hello, > > Brett is no longer with LunarG and I'll be making updates to his ITP bug > submissions about the status of these packages. > > The current status for the shaderc package is that it has been out for > 1+ years now and is hosted by LunarG. > > I am LunarG's curator for these packages, please check > https://vulkan.lunarg.com/sdk/home under the "ubuntu packages" tab for > more information about our repository.
Bug#682688: syncevolution: doesn't stop syncing
On Tue, 24 Jul 2012 19:12:41 +0200 Michael Below wrote: > I am syncing Evolution manually with a Nokia E71 via Bluetooth. > This works well, but syncevolution keeps working for quite some > time (5 minutes or more) after the mobile side shows that it is > finished. According to the progress bar, the PC is still sending > tasks. If I shut down Bluetooth on the mobile during that time, > syncevolution shows an error 22001. This bug has likely been fixed in the last decade, please check syncevolution version 2.0.0-3 from Debian testing/bookworm or later. If you still have the same issue, please report it upstream and let us know the URL of the new upstream issue. https://syncevolution.org/support -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#617320: syncevolution: Fails to sync with evolution "Cannot get cal from factory: Invalid source"
On Mon, 07 Mar 2011 19:54:14 -0600 Ken Bloom wrote: > SyncEvolution fails to sync with my Evolution calendar This bug has likely been fixed in the last decade, please check syncevolution version 2.0.0-3 from Debian testing/bookworm or later. If you still have the same issue, please report it upstream and let us know the URL of the new upstream issue. https://syncevolution.org/support -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#645102: syncevolution: time of recurring events changes
On Wed, 12 Oct 2011 16:06:20 +0200 Michael Below wrote: > But there is a slight problem: when I create a recurring event in > Evolution, and it is parallel to another event already known to > the E71, the time of the new event is changed. This bug has likely been fixed in the last decade, please check syncevolution version 2.0.0-3 from Debian testing/bookworm or later. If you still have the same issue, please report it upstream and let us know the URL of the new upstream issue. https://syncevolution.org/support -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#599247: syncevolution: Syncing with horde3 - always only slow-sync possible
On Wed, 06 Oct 2010 08:28:47 +0200 Thomas Maass wrote: > If i want to sync with horde3, always only a slow-sync is possible. > This causes double entries. This bug has likely been fixed in the last decade, please check syncevolution version 2.0.0-3 from Debian testing/bookworm or later. If you still have the same issue, please report it upstream and let us know the URL of the new upstream issue. https://syncevolution.org/support -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1000772: macaulay2: autopkgtest regression on i386: out of memory
Control: forwarded -1 https://github.com/Macaulay2/M2/issues/2319 Control: tags -1 pending On Sun 28 Nov 2021 02:57:24 PM EST, Paul Gevers wrote: Source: macaulay2 Version: 1.19+ds-3 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of macaulay2 the autopkgtest of macaulay2 fails in testing when that autopkgtest is run with the binary packages of macaulay2 from unstable. It passes when run with only packages from testing. In tabular form: passfail macaulay2 from testing1.19+ds-3 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from macaulay2/1.19+ds-3. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=macaulay2 https://ci.debian.net/data/autopkgtest/testing/i386/m/macaulay2/17068663/log.gz K3Surfaces ** -- capturing check(0, "K3Surfaces")-- 15.155 seconds elapsed -- capturing check(1, "K3Surfaces")-- 3.51379 seconds elapsed -- capturing check(2, "K3Surfaces")-- 14.3303 seconds elapsed -- capturing check(3, "K3Surfaces")-- 27.3209 seconds elapsed -- capturing check(4, "K3Surfaces")-- 1.92744 seconds elapsed -- capturing check(5, "K3Surfaces")-- 9.5648 seconds elapsed -- skipping check(6, "K3Surfaces")-- 0.00011649 seconds elapsed -- skipping check(7, "K3Surfaces")-- 0.7854 seconds elapsed -- capturing check(8, "K3Surfaces") *** out of memory trying to allocate 131108 bytes, exiting *** cd /tmp/M2-2812-0/171-rundir/; GC_MAXIMUM_HEAP_SIZE=400M "/usr/bin/M2-binary" -q --int --no-randomize --no-readline --silent --stop --print-width 77 <"/tmp/M2-2812-0/170.m2" >>"/tmp/M2-2812-0/170.tmp" /tmp/M2-2812-0/170.tmp:0:1: (output file) error: Macaulay2 exited with status code 1 /tmp/M2-2812-0/170.m2:0:1: (input file) M2: *** Error 1 Thanks for the report! I've reported this upstream and have pushed a band-aid fix to git skipping this test. It should be fixed on the next upload. Doug signature.asc Description: PGP signature
Bug#1000187: [Pkg-auth-maintainers] Bug#1000187: Bug#1000187: yubikey-manager: Exception when trying to add an oath account
Hi Tobias, On Sun, Nov 28, 2021 at 12:56:36PM +, Tobias Bengfort wrote: > On 28/11/2021 07.56, Florian Schlichting wrote: > > Can you try again with yubikey-manager 4.0.7-1 (currently in unstable > > and testing)? > > I can verify that this issue does not existing in testing. Is it possible to > packport a fix to stable? thanks for confirming. I can probably upload version 4.0.7 to bullseye-backports, would that be useful for you? Updating the version in stable requires a targeted fix, and from a quick glance I fail to see where things go wrong in 4.0.0~a1-4 and what exactly has been fixed. (Are you sure this isn't just a fixed error message, or are you using something else as the value for SECRET?) Florian
Bug#1000803: autopkgtest: avoid duplication with autopkgtests and how unittests are run at build-time
Package: autopkgtest Version: 5.16 Severity: normal X-Debbugs-Cc: mo...@debian.org Hello, There are at least 2 main places where source packages declare tests: 1. in debian/rules, to be executed at build-time 2. in debina/tests/*, to be executed post-build via autopkgtests Usually 1) are written first, because you need to get them to pass during build-time; this activity also require to add additional dependencies to debian/control, which are only required by tests (and not by the package building commands). And then there's 2), where often you're required to duplicate the steps from 1) and that could lead to misalignment, forgotten dependencies (and so failures), etc. In general, it's preferred to reduce duplication to the minimum, just to avoid the problems listed above, but autopkgtest kinda requires you to have exactly this duplication. F.e., i make sure to mark all the b-d only needed for tests, but there's no selector in debian/tests/control to only pull in those packages, and sometimes the quickest way is to get all @builddeps@, even if that has the risk to include extra packages in the mix. There's also the problem of duplicating how we run tests; while autopkgtest is less restrictive than the buildd environment (f.e. via allow-network), there could be substantial duplication on how test runners are setup in d/rules and in autopkgtest. I dont know if you ever thought about the duplication problem, i feel it would be really helpful if that could be substantially reduced. Thanks, Sandro -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 2.3.12 ii libdpkg-perl1.20.9 ii procps 2:3.3.17-5 ii python3 3.9.8-1 ii python3-debian 0.1.39 Versions of packages autopkgtest recommends: ii autodep8 0.24 Versions of packages autopkgtest suggests: ii lxc 1:4.0.10-1 pn lxd pn ovmf pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils1:6.1+dfsg-8+b1 ii schroot 1.6.10-12 pn vmdb2 -- no debconf information
Bug#680565: ITP: taudem -- Terrain Analysis Using Digital Elevation Models
On 11/29/21 01:00, Alain Delplanque wrote: Is this correct, what should I do now? Have you consulted the team policy yet? https://lists.debian.org/debian-gis/2021/11/msg00019.html Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1000802: autopkgtest: quicker way to iterate over autopkgtests while writing them
Package: autopkgtest Version: 5.16 Severity: normal X-Debbugs-Cc: mo...@debian.org Hello, while adding autopkgtests to a package, it seems the only way to iterate over them (adding new tests, fix broken ones) is to fix them in the source package and rebuild it. There are packages that takes hours to build, and that's essentially to write a handful of files in the source package. Is there a better way to incrementally work on autopkgtests that doesnt require to waste hours (sometimes days) just waiting for the source package to build? I think that would greatly improve the developers experience. Thanks, Sandro -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 2.3.12 ii libdpkg-perl1.20.9 ii procps 2:3.3.17-5 ii python3 3.9.8-1 ii python3-debian 0.1.39 Versions of packages autopkgtest recommends: ii autodep8 0.24 Versions of packages autopkgtest suggests: ii lxc 1:4.0.10-1 pn lxd pn ovmf pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils1:6.1+dfsg-8+b1 ii schroot 1.6.10-12 pn vmdb2 -- no debconf information
Bug#1000801: ayatana-indicator-messages: lower version number than Ubuntu's package
Source: ayatana-indicator-messages Version: 0.9.0-1 Debian's ayatana-indicator-messages builds the same binary packages as the indicator-messages source package. indicator-messages is still in Ubuntu but has a higher version number. If you intend to replace Ubuntu's packages, you'll need to use a higher version number. Please then follow up by filing a bug requesting indicator-messages' removal from Ubuntu and then subscribe ubuntu-archive to your new bug. https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+filebug Here's Ubuntu's indicator-messages: https://launchpad.net/ubuntu/+source/indicator-messages Thanks, Jeremy Bicha
Bug#1000800: RM: django-rules [source] -- RoQA; duplicate source package
Package: ftp.debian.org X-Debbugs-Cc: django-ru...@packages.debian.org Affects: src:django-rules Please remove the source package django-rules. It is a duplicate of python-django-rules. Both packages build the same binary package python3-django-rules. Fortunately, the older source package builds a slightly higher version number so the older binary package was not replaced. Please use the -S option for dak to remove the source package only. Thanks, Jeremy Bicha
Bug#1000799: django-rules: Duplicate package of python-django-rules
Source: django-rules Severity: serious django-rules is already in Debian. The source package is python-django-rules. I will file a removal bug for the new django-rules source package since it is a violation of Debian Policy to have 2 different source packages provide the same binary package name. Thanks, Jeremy Bicha
Bug#1000798: vde2: Provides the same binary package as another source package
Source: vde2 Severity: serious The binary package libvdeplug2 is built by both source packages vde2 and vdeplug4. This violates Debian Policy. Thanks, Jeremy Bicha
Bug#1000797: vdeplug4: Provides the same binary package as another source package
Source: vdeplug4 Severity: serious The binary package libvdeplug2 is built by both source packages vde2 and vdeplug4. This violates Debian Policy. Thanks, Jeremy Bicha
Bug#1000796: update-passwd only remove item one time
Package: base-passwd Version: 3.5.51 Severity: critical update-passwd only removes once and exits even more than one items need to be removed. Root cause is walk is set to walk->next after remove_node(), in which the walk has been cleaned, so the while(walk) is terminated. $update-passwd --verbose Adding group "postgres" (120) Adding group "nova" (162) Adding group "barbican" (978) Adding group "keystone" (42424) Adding group "neutron" (164) Adding group "ceilometer" (166) Adding group "sysinv" (168) Adding group "snmpd" (169) Adding group "fm" (195) Adding group "libvirt" (991) Adding group "ironic" (1874) Adding group "www" (1877) Removing group "daemon" (1) Adding user "postgres" (120) Adding user "neutron" (164) Adding user "sysinv" (168) Adding user "snmpd" (169) Adding user "fm" (195) Adding user "barbican" (982) Adding user "ceilometer" (991) Adding user "keystone" (42424) Adding user "nova" (994) Adding user "ironic" (1874) Adding user "www" (1877) Removing user "daemon" (1) 25 changes have been made, rewriting files Writing passwd-file to /etc/passwd Writing shadow-file to /etc/shadow Writing group-file to /etc/group Adding user works well, but removing user just run one time. I attached a fix, with which, it works as $sudo update-passwd --verbose Adding group "postgres" (120) Adding group "nova" (162) Adding group "barbican" (978) Adding group "keystone" (42424) Adding group "neutron" (164) Adding group "ceilometer" (166) Adding group "sysinv" (168) Adding group "snmpd" (169) Adding group "fm" (195) Adding group "libvirt" (991) Adding group "ironic" (1874) Adding group "www" (1877) Removing group "daemon" (1) Removing group "bin" (2) Removing group "lp" (7) Removing group "man" (12) Removing group "audio" (29) Removing group "video" (44) Removing group "games" (60) Adding user "postgres" (120) Adding user "neutron" (164) Adding user "sysinv" (168) Adding user "snmpd" (169) Adding user "fm" (195) Adding user "barbican" (982) Adding user "ceilometer" (991) Adding user "keystone" (42424) Adding user "nova" (994) Adding user "ironic" (1874) Adding user "www" (1877) Removing user "daemon" (1) Removing user "bin" (2) Removing user "games" (5) Removing user "lp" (7) Removing user "mail" (8) 35 changes have been made, rewriting files Writing passwd-file to /etc/passwd Writing shadow-file to /etc/shadow Writing group-file to /etc/group Thanks, ytao >From a2a96fa28fe132e34185ab1646b1f1ea4baf4942 Mon Sep 17 00:00:00 2001 From: Yue Tao Date: Thu, 25 Nov 2021 10:14:45 +0800 Subject: [PATCH] update-passwd.c: set walk to walk->next before removing update-passwd only removes once and exits even more than one items need to be removed. Root cause is walk is set to walk->next after remove_node(), in which the walk has been cleaned, so the while(walk) is terminated. Without the fix, the output of update-passwd $update-passwd --verbose Adding group "postgres" (120) Adding group "nova" (162) Adding group "barbican" (978) Adding group "keystone" (42424) Adding group "neutron" (164) Adding group "ceilometer" (166) Adding group "sysinv" (168) Adding group "snmpd" (169) Adding group "fm" (195) Adding group "libvirt" (991) Adding group "ironic" (1874) Adding group "www" (1877) Removing group "daemon" (1) Adding user "postgres" (120) Adding user "neutron" (164) Adding user "sysinv" (168) Adding user "snmpd" (169) Adding user "fm" (195) Adding user "barbican" (982) Adding user "ceilometer" (991) Adding user "keystone" (42424) Adding user "nova" (994) Adding user "ironic" (1874) Adding user "www" (1877) Removing user "daemon" (1) 25 changes have been made, rewriting files Writing passwd-file to /etc/passwd Writing shadow-file to /etc/shadow Writing group-file to /etc/group With the fix: $sudo update-passwd --verbose Adding group "postgres" (120) Adding group "nova" (162) Adding group "barbican" (978) Adding group "keystone" (42424) Adding group "neutron" (164) Adding group "ceilometer" (166) Adding group "sysinv" (168) Adding group "snmpd" (169) Adding group "fm" (195) Adding group "libvirt" (991) Adding group "ironic" (1874) Adding group "www" (1877) Removing group "daemon" (1) Removing group "bin" (2) Removing group "lp" (7) Removing group "man" (12) Removing group "audio" (29) Removing group "video" (44) Removing group "games" (60) Adding user "postgres" (120) Adding user "neutron" (164) Adding user "sysinv" (168) Adding user "snmpd" (169) Adding user "fm" (195) Adding user "barbican" (982) Adding user "ceilometer" (991) Adding user "keystone" (42424) Adding user "nova" (994) Adding user "ironic" (1874) Adding user "www" (1877) Removing user "daemon" (1) Removing user "bin" (2) Removing user "games" (5) Removing user "lp" (7) Removing user "mail" (8) 35 changes have been made, rewriting files Writing passwd-file to /etc/passwd Writing shadow-file to /etc/shadow Writing group-file to /etc/group Signed-off-by: Yue Tao --- update-passwd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git
Bug#1000795: debsums: [INTL:pt] Update on Portuguese translation of MANPAGE
Package: debsums Version: 3.0.2 Tags: l10n, patch- Severity: wishlist Updated Portuguese translation for debsums's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro debsums_3.0.2_pt.po.gz Description: application/gzip
Bug#1000794: fakeroot: [INTL:pt] Update on Portuguese translation of MANPAGE
Package: fakeroot Version: 1.26-1 Tags: l10n, patch- Severity: wishlist Updated Portuguese translation for fakeroot's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro fakeroot_1.26-1_pt.po.gz Description: application/gzip
Bug#987884: Sponsoring git-autofixup
Hi Andrej, On Sat, May 01, 2021 at 07:39:22PM +0200, Andrej Shadura wrote: > > - I plan to maintain this package myself, though I am looking for a > > sponsor. > > I can probably sponsor it. Just a ping on sponsoring git-autofixup. I never heard back from you on this. I've just re-uploaded git-autofixup to mentors: https://mentors.debian.net/package/git-autofixup/ and it's also on salsa if you prefer the gbp workflow: https://salsa.debian.org/dxld-guest/git-autofixup Thanks, --Daniel
Bug#1000793: bind9-dnsutils: dig command fails with "`fd > STDERR_FILENO' failed" when run from a XFCE4 desktop applet
Package: bind9-dnsutils Version: 1:9.16.22-1~deb11u1 Severity: normal X-Debbugs-Cc: cqu...@arcor.de I am experiencing a weird bug in which the dig command fails when run as part of a shell script executed inside the XFCE4 "Generic monitor" plugin. The error message is: dig: ./src/unix/core.c:570: uv__close: Assertion `fd > STDERR_FILENO' failed. Aborted It looks like something doesn't like that the stdout or stderr is not managed by the terminal. The command I am running is: dig @resolver4.opendns.com myip.opendns.com +short -4 As a way to reproduce it: add the "Generic monitor" plugin to a xfce4 panel and in the properties set the command to the one above. Is I run the command in the terminal then everything is fine. -- System Information: Debian Release: 11.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable- security'), (400, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es_ES:es Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bind9-dnsutils depends on: ii bind9-host [host] 1:9.16.22-1~deb11u1 ii bind9-libs 1:9.16.22-1~deb11u1 ii libc6 2.31-13+deb11u2 ii libedit2 3.1-20191231-2+b1 ii libidn2-0 2.3.0-5 ii libkrb5-3 1.18.3-6+deb11u1 ii libprotobuf-c1 1.3.3-1+b2 bind9-dnsutils recommends no packages. bind9-dnsutils suggests no packages.
Bug#1000792: gnuradio: unsatisfiable Build-Depends(-Arch) on s390x: libunwind-dev
Source: gnuradio Version: 3.9.4.0-2 Severity: serious Tags: ftbfs sid bookworm Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org libunwind-dev does not exist on s390x. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#1000790: uhd: FTBFS on ppc64el: c++: error: unrecognized command-line option ‘-march=native’; did you mean ‘-mcpu=native’?
Source: uhd Version: 4.1.0.4-2 Severity: serious Tags: ftbfs sid bookworm Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org uhd fails to build on ppc64el: | FAILED: lib/CMakeFiles/uhd.dir/transport/uhd-dpdk/dpdk_common.cpp.o | /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_ASIO_DISABLE_STD_EXPERIMENTAL_STRING_VIEW -DBOOST_ASIO_DISABLE_STD_STRING_VIEW -DBOOST_ATOMIC_DYN_LINK -DBOOST_CHRONO_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_SERIALIZATION_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -DHAVE_CONFIG_H -DHAVE_DPDK -DUHD_DLL_EXPORTS -DUHD_LOG_CONSOLE_COLOR -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_MIN_LEVEL=1 -I/<>/obj-powerpc64le-linux-gnu/include -I/<>/host/include -I/<>/host/lib/include -I/<>/obj-powerpc64le-linux-gnu/lib/include -I/<>/host/lib/deps/flatbuffers/include -I/<>/obj-powerpc64le-linux-gnu/lib/ic_reg_maps -I/<>/host/lib/convert -I/<>/obj-powerpc64le-linux-gnu/lib/convert -I/<>/host/lib/usrp -I/<>/host/lib/usrp/common/ad9361_driver -I/<>/host/lib/usrp/common -I/usr/include/dpdk -I/usr/include/libnl3 -I/usr/include/dpdk/../powerpc64le-linux-gnu/dpdk -I/usr/include/powerpc64le-linux-gnu/dpdk -I/<>/obj-powerpc64le-linux-gnu/lib/transport/nirio/lvbitx -I/usr/include/libusb-1.0 -I/<>/host/lib/transport/uhd-dpdk -I/<>/host/lib/deps/rpclib/include -I/usr/include/python3.9 -I/<>/host/lib/deps/pybind11/include -I/<>/obj-powerpc64le-linux-gnu/_cmrc/include -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden -fvisibility-inlines-hidden -O2 -g -DNDEBUG -fPIC -Wall -Wextra -Wsign-compare -std=gnu++14 -march=native -D_GNU_SOURCE -MD -MT lib/CMakeFiles/uhd.dir/transport/uhd-dpdk/dpdk_common.cpp.o -MF lib/CMakeFiles/uhd.dir/transport/uhd-dpdk/dpdk_common.cpp.o.d -o lib/CMakeFiles/uhd.dir/transport/uhd-dpdk/dpdk_common.cpp.o -c /<>/host/lib/transport/uhd-dpdk/dpdk_common.cpp | c++: error: unrecognized command-line option ‘-march=native’; did you mean ‘-mcpu=native’? See https://buildd.debian.org/status/fetch.php?pkg=uhd=ppc64el=4.1.0.4-2=1638057565=0 If you start an uncoordinated transition, please at least ensure that the package builds everywhere. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#1000791: uhd: FTBFS on mipsel:
Source: uhd Version: 4.1.0.4-2 Severity: serious Tags: ftbfs sid bookworm Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org uhd fails to build on mipsel: | FAILED: python/CMakeFiles/pyuhd.dir/pyuhd.cpp.o | /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_ASIO_DISABLE_STD_EXPERIMENTAL_STRING_VIEW -DBOOST_ASIO_DISABLE_STD_STRING_VIEW -DBOOST_ATOMIC_DYN_LINK -DBOOST_CHRONO_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_SERIALIZATION_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -DHAVE_CONFIG_H -DUHD_LOG_CONSOLE_COLOR -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_MIN_LEVEL=1 -Dpyuhd_EXPORTS -I/<>/obj-mipsel-linux-gnu/include -I/<>/host/include -I/usr/include/python3.9 -I/<>/host/lib/deps/pybind11/include -I/usr/lib/python3/dist-packages/numpy/core/include -I/<>/host/lib -I/<>/obj-mipsel-linux-gnu/_cmrc/include -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden -fvisibility-inlines-hidden -O2 -g -DNDEBUG -fPIC -Wall -Wextra -Wsign-compare -std=gnu++14 -MD -MT python/CMakeFiles/pyuhd.dir/pyuhd.cpp.o -MF python/CMakeFiles/pyuhd.dir/pyuhd.cpp.o.d -o python/CMakeFiles/pyuhd.dir/pyuhd.cpp.o -c /<>/host/python/pyuhd.cpp | | cc1plus: out of memory allocating 2217812 bytes after a total of 59752448 bytes | ninja: build stopped: subcommand failed. See https://buildd.debian.org/status/fetch.php?pkg=uhd=mipsel=4.1.0.4-2=1638083831=0 If you start an uncoordinated transition, please ensure at least that the package builds everywhere. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#1000789: kiosk locked xfce4-panel causes ~/.xsession-errors to rapidly fill with error logspam
Package: xfce4-panel Version: 4.16.2-1 Severity: minor https://sources.debian.org/src/xfce4-panel/4.16.3-1/plugins/launcher/launcher.c/?hl=593#L592-L667 This function copy-paste-edits /usr/share/applications/foo.desktop to ~/.config/xfce4/panel/launcher-NUMBER/TIMESTAMP.desktop Then it updates xfconf property xfce4-panel/plugins/plugin-NUMBER/items[] to refer to the new location. When the panel is locked (by ), the update fails. In XFCE 4.10 (Debian 9), this happened once per login. In XFCE 4.16 (Debian 11), this happens about once per second. This is causing ~/.xsession-errors to fill up, eventually filling $HOME and triggering EDQUOT/ENOSPC errors for all applications. The rate of consumption is approximately 655 bytes per launcher item per second. For a quicklaunch bar with 3 items, this is 161 MB/day. A minimum file to reproduce is attached; put it in world-readable /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. Please provide kiosk operators a way to opt-out of launcher_plugin_item_duplicate. I would be happy with any of these: 1. xfce4-panel sees the xfconf channel is locked, and implicitly skips launcher_plugin_item_duplicate. 2. xfce4-panel checks for an explicit opt-out like xfce4-panel/plugins/plugin-1/duplicate-launcher=false. 3. launcher_plugin_item_duplicate is only tried once-per-login (not once-per-second), so .xsession-errors doesn't fill up. 4. xfconf/garcon warnings/assertions are suppressed, so .xsession-errors doesn't fill up. The errors look like this on Debian 11: (xfce4-panel:658): xfconf-WARNING **: 10:23:49.199: Failed to set property "xfce4-panel::/plugins/plugin-1/items": GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while modifying property "/plugins/plugin-1/items" on channel "xfce4-panel" (xfce4-panel:658): garcon-CRITICAL **: 10:23:49.227: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:49.228: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:49.228: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): xfconf-WARNING **: 10:23:50.199: Failed to set property "xfce4-panel::/plugins/plugin-1/items": GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while modifying property "/plugins/plugin-1/items" on channel "xfce4-panel" (xfce4-panel:658): garcon-CRITICAL **: 10:23:50.215: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:50.215: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:50.215: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): xfconf-WARNING **: 10:23:51.198: Failed to set property "xfce4-panel::/plugins/plugin-1/items": GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while modifying property "/plugins/plugin-1/items" on channel "xfce4-panel" (xfce4-panel:658): garcon-CRITICAL **: 10:23:51.215: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:51.215: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:51.215: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): xfconf-WARNING **: 10:23:52.198: Failed to set property "xfce4-panel::/plugins/plugin-1/items": GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while modifying property "/plugins/plugin-1/items" on channel "xfce4-panel" (xfce4-panel:658): garcon-CRITICAL **: 10:23:52.212: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:52.213: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:52.213: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): xfconf-WARNING **: 10:23:53.198: Failed to set property "xfce4-panel::/plugins/plugin-1/items": GDBus.Error:org.xfce.Xfconf.Error.PermissionDenied: Permission denied while modifying property "/plugins/plugin-1/items" on channel "xfce4-panel" (xfce4-panel:658): garcon-CRITICAL **: 10:23:53.214: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:53.214: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): garcon-CRITICAL **: 10:23:53.215: garcon_gtk_menu_get_desktop_actions_menu: assertion 'actions != NULL' failed (xfce4-panel:658): xfconf-WARNING **:
Bug#1000743: installation-reports: bootx64.efi didn't seem to get installed and no UEFI boot entry was created for Debian
Le 28/11/2021 à 23:07, Adam Baxter a écrit : Maybe it'd be worth having an option to allow a user to tether a mobile phone via USB to grab the firmware online. This is automatic if the phone emulates a USB-ethernet adapter. Perhaps the prompt should say "We can download the firmware automatically if you are able to use an alternative connection, such as mobile tethering", although I wonder how this would work for non-free firmware. Sorry, there was a misunderstanding. I meant that a tethered phone can be used as a network interface to download packages during the installation, but not to download firmware for the installer itself. Also, a cdrom: entry was added to sources.list even though I installed from USB. Because both contain the same ISO image so have the same data structure. But Debian was looking for these files at /media/cdrom - would the installation USB be re-mounted at this location? Not automatically (unless you create an appropriate udev rule or fstab entry), but you can do it manually.
Bug#999433: [Pkg-javascript-devel] Bug#999433: nodejs: please enable riscv64
Le mer. 24 nov. 2021 à 11:27, Jonas Smedegaard a écrit : > Quoting Jérémy Lal (2021-11-24 11:07:55) > > I've just enabled the arch in latest release. However a binary build > > still needs to be done, and it will pose bootstrap issues. > > > > nodejs needs to be built with nodoc profile first, then rebuilt > > without. However nodejs build-depends on some external modules, which > > build-depend on nodejs: acorn, acorn-walk (at the moment). > > > > Since nodejs has a --node-builtin-modules-path flag, i'll add a > > "nobuiltin" flag to allow building without including acorn, and > > install builtin modules and symlink to acorn. > > > > That should allow acorn to be built and stage 2 built to be done. > > Please document the bootstrapping build stages and flags needed for each > in debian/README.source > I've pushed some work on master-16.x branch: the stage 1 build should produce a debian package without depending on nodejs, but it needs further testing. See comments in debian/README.source.
Bug#1000743: installation-reports: bootx64.efi didn't seem to get installed and no UEFI boot entry was created for Debian
On Mon, Nov 29, 2021 at 08:57:37AM +1100, deb...@voltagex.org wrote: >Hi >>>At least GRUB itself was installed in the EFI partition. >>> Shouldn't there normally be EFI/boot/bootx64.efi? >>> >>>Not by default. It happens only if you choose to install a copy of the boot >>>loader in the removable device path. The option is available only in expert >>>install or after changing priority for questions to low. >> >> Agreed. We deliberately do *not* install there by default as this can >> cause other OSes not to boot. We try to be more accommodating than >> Windows etc. :-/ >> >Unless I did something wrong in the partitioning setup, there were no other >operating systems. The only other EFI entry I had created in the firmware >setup manually was one for the USB drive. > >What do you mean by removable device in this case? /boot/EFI is on >the same NVMe drive as the Debian install itself. The *normal* way for UEFI boot is via vendor paths and boot variables. The alternate path is primarily designed for removable media, where you won't have boot variables set to point to the right files. Hopefully the docs I've written in https://wiki.debian.org/UEFI#Booting_a_UEFI_machine_normally and https://wiki.debian.org/UEFI#Booting_from_removable_media might help explain some more. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Bug#1000743: installation-reports: bootx64.efi didn't seem to get installed and no UEFI boot entry was created for Debian
> The installation manual provides all this information. OK, this is fair, I wasn't thinking about the manual as I've installed Debian quite a few times and know how the installation goes. Perhaps the text could include a reminder to check the manual for more info on firmware loading, or even a QR code to take me to the correct place? >> I ended up grabbing >> https://saimei.ftp.acc.umu.se/cdimage/unofficial/non-free/firmware/testing/20211122/firmware.zip >> and extracting the firmware files from firmware-iwlwifi_20210818-1_all.deb >> Would the installer have coped if I'd just dropped that single deb file? > > Yes, as stated in the installation manual. > >> Maybe it'd be worth having an option to allow a user to tether a mobile >> phone via USB to grab the firmware online. > > This is automatic if the phone emulates a USB-ethernet adapter. > Perhaps the prompt should say "We can download the firmware automatically if you are able to use an alternative connection, such as mobile tethering", although I wonder how this would work for non-free firmware. >> Also, a cdrom: entry was added to sources.list even though I installed from >> USB. > > Because both contain the same ISO image so have the same data structure. But Debian was looking for these files at /media/cdrom - would the installation USB be re-mounted at this location? --Adam
Bug#999415: transition: pandas 1.1 -> 1.3 - to unstable now or not?
On Sun, 28 Nov 2021, Rebecca N. Palmer wrote: After build-testing about half of the reverse dependencies, failures that look new-pandas-related are cfgrib #1000726, joypy #1000727, python-skbio #1000752, and maybe hyperspy (not filed yet). python-skbio and hyperspy already FTBFS for unrelated reasons (but fail more tests with new pandas), and joypy looks trivially fixable. Given this and expecting to find a similar number in the other half, against pandas 1.3 working on python3.10 while 1.1 doesn't (#1000422), would you prefer to have pandas 1.3 in unstable now, or not? My vote would be: go for it, but then again, I don't maintain any of pandas BDs. Thanks, Scott
Bug#1000781: ghostscript breaks asymptote autopkgtest: build fails: GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
Control: reassign -1 ghostscript Control: severity 1000710 serious Control: merge 1000710 -1 Am 28.11.2021 um 21:29 teilte Paul Gevers mit: Hi Paul, Dear maintainer(s), With a recent upload of ghostscript the autopkgtest of asymptote fails in testing when that autopkgtest is run with the binary packages of ghostscript from unstable. It passes when run with only packages from testing. In tabular form: We are already on it and I forwarded the issue to upstream: https://bugs.ghostscript.com/show_bug.cgi?id=704737 Last statement we got from there was: "This appear to be fixed already, I will narrow down the relevant commit tomorrow." So chances are good to have a fix soon. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1000743: installation-reports: bootx64.efi didn't seem to get installed and no UEFI boot entry was created for Debian
Hi >>At least GRUB itself was installed in the EFI partition. >> >>> Shouldn't there normally be EFI/boot/bootx64.efi? >> >>Not by default. It happens only if you choose to install a copy of the boot >>loader in the removable device path. The option is available only in expert >>install or after changing priority for questions to low. > > Agreed. We deliberately do *not* install there by default as this can > cause other OSes not to boot. We try to be more accommodating than > Windows etc. :-/ > Unless I did something wrong in the partitioning setup, there were no other operating systems. The only other EFI entry I had created in the firmware setup manually was one for the USB drive. What do you mean by removable device in this case? /boot/EFI is on the same NVMe drive as the Debian install itself. Thanks, Adam
Bug#995679: exim4: FTBFS on sparc64 due to bad alignment (Bus Error)
Control: tags -1 +patch
Hello!
Upstream has now merged a patch by me - with slight modifications by upstream -
which fixes the problem [1], also on alpha and not just sparc64.
Attaching a backported version of the patch which applies against exim-4.95.
Could you include this patch in the next upload?
Thanks,
Adrian
> [1]
> https://github.com/Exim/exim/commit/d73b9f478a2a5b299634acee4e05ff8ea25375a2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Fix basic memory use for SPARC. Bug 2838
Bug 2838: Fix for i32lp64 hard-align platforms. Found for SPARC Linux,
though only once PCRE2 was introduced: the memory accounting used under
debug offset allocations by an int, giving a hard trap in early startup.
Change to using a size_t. Debug and fix by John Paul Adrian Glaubitz.
Author: John Paul Adrian Glaubitz, Jeremy Harris
Origin: Backported from git master
Forwarded: https://bugs.exim.org/show_bug.cgi?id=2838
Last-Update: 2021-11-28
--- exim4-4.95.orig/src/store.c
+++ exim4-4.95/src/store.c
@@ -192,7 +192,7 @@ static const uschar * poolclass[NPOOLS]
#endif
-static void * internal_store_malloc(int, const char *, int);
+static void * internal_store_malloc(size_t, const char *, int);
static void internal_store_free(void *, const char *, int linenumber);
/**/
@@ -861,26 +861,29 @@ Returns: pointer to gotten store (p
*/
static void *
-internal_store_malloc(int size, const char *func, int line)
+internal_store_malloc(size_t size, const char *func, int line)
{
void * yield;
-if (size < 0 || size >= INT_MAX/2)
+/* Check specifically for a possibly result of conversion from
+a negative int, to the (unsigned, wider) size_t */
+
+if (size >= INT_MAX/2)
log_write(0, LOG_MAIN|LOG_PANIC_DIE,
-"bad memory allocation requested (%d bytes) at %s %d",
-size, func, line);
+"bad memory allocation requested (%lld bytes) at %s %d",
+(unsigned long long)size, func, line);
-size += sizeof(int); /* space to store the size, used under debug */
+size += sizeof(size_t); /* space to store the size, used under debug */
if (size < 16) size = 16;
-if (!(yield = malloc((size_t)size)))
+if (!(yield = malloc(size)))
log_write(0, LOG_MAIN|LOG_PANIC_DIE, "failed to malloc %d bytes of memory: "
"called from line %d in %s", size, line, func);
#ifndef COMPILE_UTILITY
-DEBUG(D_any) *(int *)yield = size;
+DEBUG(D_any) *(size_t *)yield = size;
#endif
-yield = US yield + sizeof(int);
+yield = US yield + sizeof(size_t);
if ((nonpool_malloc += size) > max_nonpool_malloc)
max_nonpool_malloc = nonpool_malloc;
@@ -893,8 +896,8 @@ giving warnings. */
is not filled with zeros so as to catch problems. */
if (f.running_in_test_harness)
- memset(yield, 0xF0, (size_t)size - sizeof(int));
-DEBUG(D_memory) debug_printf("--Malloc %6p %5d bytes\t%-20s %4d\tpool %5d nonpool %5d\n",
+ memset(yield, 0xF0, size - sizeof(size_t));
+DEBUG(D_memory) debug_printf("--Malloc %6p %5lld bytes\t%-20s %4d\tpool %5d nonpool %5d\n",
yield, size, func, line, pool_malloc, nonpool_malloc);
#endif /* COMPILE_UTILITY */
@@ -902,7 +905,7 @@ return yield;
}
void *
-store_malloc_3(int size, const char *func, int linenumber)
+store_malloc_3(size_t size, const char *func, int linenumber)
{
if (n_nonpool_blocks++ > max_nonpool_blocks)
max_nonpool_blocks = n_nonpool_blocks;
@@ -927,10 +930,11 @@ Returns: nothing
static void
internal_store_free(void * block, const char * func, int linenumber)
{
-uschar * p = US block - sizeof(int);
+uschar * p = US block - sizeof(size_t);
#ifndef COMPILE_UTILITY
-DEBUG(D_any) nonpool_malloc -= *(int *)p;
-DEBUG(D_memory) debug_printf("Free %6p %5d bytes\t%-20s %4d\n", block, *(int *)p, func, linenumber);
+DEBUG(D_any) nonpool_malloc -= *(size_t *)p;
+DEBUG(D_memory) debug_printf("Free %6p %5lld bytes\t%-20s %4d\n",
+ block, (unsigned long long) *(size_t *)p, func, linenumber);
#endif
free(p);
}
--- exim4-4.95.orig/src/store.h
+++ exim4-4.95/src/store.h
@@ -65,7 +65,7 @@ typedef void ** rmark;
extern BOOLstore_extend_3(void *, BOOL, int, int, const char *, int);
extern voidstore_free_3(void *, const char *, int);
/* store_get_3 & store_get_perm_3 are in local_scan.h */
-extern void *store_malloc_3(int, const char *, int) ALLOC ALLOC_SIZE(1) WARN_UNUSED_RESULT;
+extern void *store_malloc_3(size_t, const char *, int) ALLOC ALLOC_SIZE(1) WARN_UNUSED_RESULT;
extern rmark store_mark_3(const char *, int);
extern void *store_newblock_3(void *, BOOL, int, int, const char *, int);
extern voidstore_release_above_3(void *, const char *, int);
Bug#997948: winff FTBFS: Fatal: (10022) Can't find unit Interfaces used by winff
Hi Abou, On 28-11-2021 20:51, Abou Al Montacir wrote: But in Debian I'd expect package relations to embed the knowledge to prevent this from happening. This is generally the case except when FPC get upgraded to a new version, which is generally a transitory situation for a very short time. I forgot how we do that then, but how do we guarantee that the period is short? Does it show up on the Release Team transition trackers [1] somehow? Or do we have to always remember to ask for a rebuild of lazarus ourselves (if we don't have a reason to upload a new version of lazarus)? Paul [1] https://release.debian.org/transitions/ OpenPGP_signature Description: OpenPGP digital signature
Bug#999448: [External] Re: Bug#999448: atop: Two fixes for debian/rules: activate atopacctd before activating atop, load atop.default into pkg
On Thu, Nov 25, 2021 at 08:08:53PM +0800, 李菲 wrote: > In short, build => install => check (no restart) should work. I apologize, but I don't see the problem here: [15/4605]mh@testsid85:~ $ sudo apt install atop Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: atop 0 upgraded, 1 newly installed, 0 to remove and 5 not upgraded. Need to get 201 kB of archives. After this operation, 511 kB of additional disk space will be used. Get:1 http://debian.debian.zugschlus.de/debian sid/main amd64 atop amd64 2.6.0-2 [201 kB] Fetched 201 kB in 0s (1.836 kB/s) Selecting previously unselected package atop. (Reading database ... 32406 files and directories currently installed.) Preparing to unpack .../atop_2.6.0-2_amd64.deb ... Unpacking atop (2.6.0-2) ... Setting up atop (2.6.0-2) ... Created symlink /etc/systemd/system/timers.target.wants/atop-rotate.timer → /lib/systemd/system/atop-rotate.timer. Created symlink /etc/systemd/system/multi-user.target.wants/atop.service → /lib/systemd/system/atop.service. Created symlink /etc/systemd/system/multi-user.target.wants/atopacct.service → /lib/systemd/system/atopacct.service. atop-rotate.service is a disabled or a static unit, not starting it. Processing triggers for man-db (2.9.4-2) ... [16/4606]mh@testsid85:~ $ sudo ls -la /proc/$(pgrep '^atop$')/fd /proc/$(pgrep '^atopacctd$')/fd /proc/43189/fd: total 0 dr-x-- 2 root root 0 Nov 28 21:40 . dr-xr-xr-x 9 root root 0 Nov 28 21:40 .. lr-x-- 1 root root 64 Nov 28 21:40 0 -> /run/pacct_source l-wx-- 1 root root 64 Nov 28 21:40 1 -> /run/pacct_shadow.d/00.paf lrwx-- 1 root root 64 Nov 28 21:40 2 -> 'socket:[219557]' l-wx-- 1 root root 64 Nov 28 21:40 3 -> /run/pacct_shadow.d/current lrwx-- 1 root root 64 Nov 28 21:40 4 -> 'socket:[219561]' lrwx-- 1 root root 64 Nov 28 21:40 5 -> 'socket:[219562]' /proc/43192/fd: total 0 dr-x-- 2 root root 0 Nov 28 21:40 . dr-xr-xr-x 9 root root 0 Nov 28 21:40 .. lr-x-- 1 root root 64 Nov 28 21:40 0 -> /dev/null lrwx-- 1 root root 64 Nov 28 21:40 1 -> 'socket:[219563]' lrwx-- 1 root root 64 Nov 28 21:40 2 -> 'socket:[219563]' lr-x-- 1 root root 64 Nov 28 21:40 3 -> /run/pacct_shadow.d/00.paf lrwx-- 1 root root 64 Nov 28 21:40 4 -> 'socket:[218991]' l-wx-- 1 root root 64 Nov 28 21:40 5 -> /var/log/atop/atop_20211128 [17/4607]mh@testsid85:~ $ I see that on my system fds 1 and 2 are a socket while yours are files, and that fd3 is correctly the /run/pacct_shadow.d file. Am I still doing things wrong here? Greetings Marc
Bug#1000786: davs2 FTCBFS: configures for the build architecture
Source: davs2
Version: 1.6-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags ftcbfs
davs2 fails to cross build from source, because it configures for the
build architecture. The upstream configure script is very much unlike
autoconf and ignores --host as passed by dh_auto_configure. Instead one
is supposed to pass --cross-prefix. Please consider applying the
attached patch.
Helmut
diff --minimal -Nru davs2-1.6/debian/changelog davs2-1.6/debian/changelog
--- davs2-1.6/debian/changelog 2021-04-11 16:02:46.0 +0200
+++ davs2-1.6/debian/changelog 2021-11-28 14:04:33.0 +0100
@@ -1,3 +1,10 @@
+davs2 (1.6-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: Pass --cross-prefix to configure. (Closes: #-1)
+
+ -- Helmut Grohne Sun, 28 Nov 2021 14:04:33 +0100
+
davs2 (1.6-1) unstable; urgency=medium
[ Ondřej Nový ]
diff --minimal -Nru davs2-1.6/debian/rules davs2-1.6/debian/rules
--- davs2-1.6/debian/rules 2021-04-11 15:55:39.0 +0200
+++ davs2-1.6/debian/rules 2021-11-28 14:04:32.0 +0100
@@ -1,5 +1,6 @@
#!/usr/bin/make -f
+include /usr/share/dpkg/architecture.mk
include /usr/share/dpkg/pkg-info.mk
manpage = debian/davs2.1
@@ -10,6 +11,7 @@
override_dh_auto_configure:
VER_SHA="$(DEB_DISTRIBUTION)" dh_auto_configure -- \
+ --cross-prefix=$(DEB_HOST_GNU_TYPE)- \
--enable-shared \
--enable-pic \
--extra-cflags="${CPPFLAGS} -fvisibility=hidden -DDAVS2_EXPORTS"
Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: Alessandro Ghedini , Samuel Henrique , Sergio Durigan Junior libcurl4-gnutls-dev is not multiarch-coinstallable in bullseye despite being marked Multi-Arch: same. When attempting to coinstall it, dpkg issues an unpack error. That's a very bad thing to do. The issue has been reported as #990128 and has been fixed in unstable. Reproducible builds added compiler flags that include the build directory (which varies per build) and those build flags made it into curl-config. As such, reproducible builds made curl unreproducible. This issue has been well understood and for a different compiler flag, a workaround was already in place in debian/rules. The solution was to extend the workaround in the obvious way (stripping that other flag). I think that the risk/benefit ratio is good. The only affected piece is curl-config, the change is fairly obvious and it makes unpack errors from dpkg go away. It also has been in testing for a while now. buster is unaffected by this issue. Note that I am not a curl maintainer, but I provided the solution for unstable. I intend to NMU this change. I've put the curl maintainers into X-Debbugs-Cc in case they wish to pick this up. The full (small) .debdiff is attached. Helmut diff --minimal -Nru curl-7.74.0/debian/changelog curl-7.74.0/debian/changelog --- curl-7.74.0/debian/changelog2021-06-25 20:59:54.0 +0200 +++ curl-7.74.0/debian/changelog2021-11-28 06:38:09.0 +0100 @@ -1,3 +1,10 @@ +curl (7.74.0-1.3+deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Also remove -ffile-prefix-map from curl-config. (Closes: #990128) + + -- Helmut Grohne Sun, 28 Nov 2021 06:38:09 +0100 + curl (7.74.0-1.3) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru curl-7.74.0/debian/rules curl-7.74.0/debian/rules --- curl-7.74.0/debian/rules2021-06-25 20:59:54.0 +0200 +++ curl-7.74.0/debian/rules2021-11-28 06:37:57.0 +0100 @@ -101,11 +101,13 @@ # 3. Likewise, replace the architecture name used for --build (and #build_alias) with a literal backquoted call to dpkg-architecture. # 4. In --configure output, remove -#-fdebug-prefix-map=/buildd/specific/random/path=. +#-fdebug-prefix-map=/buildd/specific/random/path=. and +#-ffile-prefix-map=/buildd/specific/random/path=. sed -e "/-lcurl /s|`krb5-config --libs gssapi`|\`krb5-config --libs gssapi\`|" \ -e "/--prefix/s|/$(DEB_HOST_MULTIARCH)'|/'\`dpkg-architecture -qDEB_HOST_MULTIARCH\`|g" \ -e "/--prefix/s|=$(DEB_BUILD_GNU_TYPE)'|='\`dpkg-architecture -qDEB_BUILD_GNU_TYPE\`|g" \ -e "/-fdebug-prefix-map=/s|\(-fdebug-prefix-map=\)/[^ ]*=.||" \ + -e "/-ffile-prefix-map=/s|\(-ffile-prefix-map=\)/[^ ]*=.||" \ -i `find . -name curl-config` override_dh_installchangelogs:
Bug#1000784: php8.1: does not trap errors from dtrace
Source: php8.1 Version: 8.1.0-1 Severity: serious Tags: patch Justification: policy 4.6 When dtrace fails, the build system continues anyway. Such behaviour is in violation with policy section 4.6 and thus justifies a release-critical bug report. The actual issue resides in build/php.m4 line 2391 and following: | $ac_bdir[$]ac_hdrobj: $abs_srcdir/$ac_provsrc | CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak && \$(SED) -e 's,PHP_,DTRACE_,g' \$[]@.bak > \$[]@ The dtrace call is separated from the sed invocation using &&. While the combination of "false && true" results in a non-zero exit, this does not terminate the shell even with -e set. See the following example: $ sh -c "set -e; false && true; echo huh" huh $ As such, a dtrace failures is swallowed and this causes the policy violation. To fix this, one can invoke the two commands separately: | $ac_bdir[$]ac_hdrobj: $abs_srcdir/$ac_provsrc | CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak | \$(SED) -e 's,PHP_,DTRACE_,g' \$[]@.bak > \$[]@ I'm attaching a patch for your convenience. Helmut --- php8.1-8.1.0.orig/build/php.m4 +++ php8.1-8.1.0/build/php.m4 @@ -2389,7 +2389,8 @@ $abs_srcdir/$ac_provsrc:; $ac_bdir[$]ac_hdrobj: $abs_srcdir/$ac_provsrc - CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak && \$(SED) -e 's,PHP_,DTRACE_,g' \$[]@.bak > \$[]@ + CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak + \$(SED) -e 's,PHP_,DTRACE_,g' \$[]@.bak > \$[]@ \$(PHP_DTRACE_OBJS): $ac_bdir[$]ac_hdrobj
Bug#1000783: finalcut: binary-any FTBFS
Source: finalcut Version: 0.8.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=finalcut=0.8.0-1 ... debian/rules override_dh_auto_clean make[1]: Entering directory '/<>' test -f final/font/xfonts-finalcut-newfont.alias && rm final/font/xfonts-finalcut-newfont.alias make[1]: *** [debian/rules:25: override_dh_auto_clean] Error 1
Bug#999695: systemd: emergency/rescue targets fail to stop journald
On 28.11.21 12:37, westlake wrote: FIX IT NOW!! Please dial down your rhetoric a couple of notches. All it has achieved so far is that I'm no longer motivated to look at this issue. OpenPGP_signature Description: OpenPGP digital signature
Bug#1000782: plink2: autopkgtest regression: Segmentation fault
Source: plink2
Version: 2.00~a3-211011+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of plink2 the autopkgtest of plink2 fails in
testing when that autopkgtest is run with the binary packages of plink2
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
plink2 from testing2.00~a3-211011+dfsg-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=plink2
https://ci.debian.net/data/autopkgtest/testing/amd64/p/plink2/17088127/log.gz
PLINK v2.00a3 SSE4.2 (11 Oct 2021)
www.cog-genomics.org/plink/2.0/
(C) 2005-2021 Shaun Purcell, Christopher Chang GNU General Public
License v3
Logging to tmp_data.log.
Options in effect:
--dummy 33 65537 0.1 dosage-freq=0.1
--out tmp_data
Start time: Sun Nov 28 11:11:17 2021
257840 MiB RAM detected; reserving 128920 MiB for main workspace.
Using up to 48 threads (change this with --threads).
--dummy: 65k variants written.
Dummy data (33 samples, 65537 SNPs) written to tmp_data.pgen +
tmp_data.pvar +
tmp_data.psam .
End time: Sun Nov 28 11:11:17 2021
/usr/bin/plink2: line 8: 1566 Segmentation fault "${cmd}" "$@"
autopkgtest [11:11:17]: test run-sample-analysis
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1000781: ghostscript breaks asymptote autopkgtest: build fails: GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
Source: ghostscript, asymptote Control: found -1 ghostscript/9.55.0~dfsg-1 Control: found -1 asymptote/2.70+ds-2 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of ghostscript the autopkgtest of asymptote fails in testing when that autopkgtest is run with the binary packages of ghostscript from unstable. It passes when run with only packages from testing. In tabular form: passfail ghostscriptfrom testing9.55.0~dfsg-1 asymptote from testing2.70+ds-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of ghostscript to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=ghostscript https://ci.debian.net/data/autopkgtest/testing/amd64/a/asymptote/17088116/log.gz cd png && make all make[4]: Entering directory '/tmp/autopkgtest-lxc.9yct2tpe/downtmp/build.gii/src/doc/png' cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ axis3.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ bezier2.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ bezier.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ beziercurve.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ bigdiagonal.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ binarytreetest.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ Bode.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ brokenaxis.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ CAD1.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ CDlabel.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ colons.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ colors.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ cube.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ cylinderskeleton.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ datagraph.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ diagonal.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ diatom.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ dots.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ eetomumu.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ elliptic.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ errorbars.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ exp.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ filegraph.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ flow.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ flowchartdemo.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ GaussianSurface.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ generalaxis3.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ generalaxis.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ graphmarkers.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ grid3xyz.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ hatch.asy Error: /rangecheck in --stroke-- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1990 1 3 %oparray_pop 1989 1 3 %oparray_pop 1988 1 3 %oparray_pop --nostringval-- 1977 1 3 %oparray_pop 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- fill (NULL) (gs_pattern1_instance_t) (pattern accumulator) 0 %pattern_paint_finish --nostringval-- Dictionary stack: --dict:767/1123(ro)(G)-- --dict:0/20(G)-- --dict:83/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 2701 GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1 _shipout(prefix,f,currentpatterns,format,wait,view,t); ^ ../base/plain_shipout.asy: 104.11: runtime: shipout failed make[4]: *** [Makefile:14: hatch.png] Error 1 make[4]: Leaving
Bug#1000554: RFS: libfm-qt/0.16.0-3.1 [NMU] [RC] -- Language package for libfm-qt
I have decided to package the newest version of LXQt (including libfm-qt), as such, this bug report no longer has relevance.
Bug#1000780: eigen3 breaks pybind11 autopkgtest on ppc64el: inlining failed in call to ‘always_inline’
Source: eigen3, pybind11
Control: found -1 eigen3/3.4.0-1
Control: found -1 pybind11/2.7.1-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of eigen3 the autopkgtest of pybind11 fails in
testing when that autopkgtest is run with the binary packages of eigen3
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
eigen3 from testing3.4.0-1
pybind11 from testing2.7.1-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of eigen3 to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=eigen3
https://ci.debian.net/data/autopkgtest/testing/ppc64el/p/pybind11/17068686/log.gz
-- The CXX compiler identification is GNU 11.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Python: /usr/bin/python3.9 (found suitable exact version
"3.9.9") found components: Interpreter Development Development.Module
Development.Embed -- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Found pybind11: /usr/include (found version "2.7.1" )
-- Setting tests build type to MinSizeRel as none was specified
-- Building tests with Eigen v3.4.0
-- Found Boost:
/usr/lib/powerpc64le-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake
(found suitable version "1.74.0", minimum required is "1.56") -- Found
pytest 6.2.5
-- Configuring done
-- Generating done
-- Build files have been written to:
/tmp/autopkgtest-lxc.xeav8k1t/downtmp/autopkgtest_tmp/tests-python3.9
[ 2%] Building CXX object
CMakeFiles/pybind11_tests.dir/pybind11_tests.cpp.o
[ 4%] Building CXX object CMakeFiles/pybind11_tests.dir/test_async.cpp.o
[ 6%] Building CXX object CMakeFiles/pybind11_tests.dir/test_buffers.cpp.o
[ 9%] Building CXX object
CMakeFiles/pybind11_tests.dir/test_builtin_casters.cpp.o
[ 11%] Building CXX object
CMakeFiles/pybind11_tests.dir/test_call_policies.cpp.o
[ 13%] Building CXX object
CMakeFiles/pybind11_tests.dir/test_callbacks.cpp.o
[ 16%] Building CXX object CMakeFiles/pybind11_tests.dir/test_chrono.cpp.o
[ 18%] Building CXX object CMakeFiles/pybind11_tests.dir/test_class.cpp.o
[ 20%] Building CXX object
CMakeFiles/pybind11_tests.dir/test_constants_and_functions.cpp.o
[ 23%] Building CXX object
CMakeFiles/pybind11_tests.dir/test_copy_move.cpp.o
[ 25%] Building CXX object
CMakeFiles/pybind11_tests.dir/test_custom_type_casters.cpp.o
[ 27%] Building CXX object
CMakeFiles/pybind11_tests.dir/test_docstring_options.cpp.o
[ 30%] Building CXX object CMakeFiles/pybind11_tests.dir/test_eigen.cpp.o
In file included from /usr/include/eigen3/Eigen/Core:286,
from /usr/include/pybind11/eigen.h:36,
from
/tmp/autopkgtest-lxc.xeav8k1t/downtmp/autopkgtest_tmp/tests-python3.9/test_eigen.cpp:12:
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductMMA.h: In
function
‘Eigen::internal::storeAccumulatorlong, 0, 0, 1>, long, double __vector(2), 2l>(long, long,
Eigen::internal::blas_data_mapper const&, double
__vector(2) const&, __vector_quad*)void’:
/usr/include/eigen3/Eigen/src/Core/util/BlasUtil.h:227:46: error:
inlining failed in call to ‘always_inline’
‘Eigen::internal::blas_data_mapper1>::storePacketBlock(long, long,
Eigen::internal::PacketBlock const&) constvoid’:
target specific option mismatch
227 | EIGEN_DEVICE_FUNC EIGEN_ALWAYS_INLINE void
storePacketBlock(Index i, Index j, const PacketBlock
) const {
| ^~~~
In file included from
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProduct.h:38,
from /usr/include/eigen3/Eigen/Core:350,
from /usr/include/pybind11/eigen.h:36,
from
/tmp/autopkgtest-lxc.xeav8k1t/downtmp/autopkgtest_tmp/tests-python3.9/test_eigen.cpp:12:
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductMMA.h:43:44: note:
called from here
43 | data.template storePacketBlock(i, j, tRes);
| ~^~~~
In file included from /usr/include/eigen3/Eigen/Core:350,
from /usr/include/pybind11/eigen.h:36,
from
/tmp/autopkgtest-lxc.xeav8k1t/downtmp/autopkgtest_tmp/tests-python3.9/test_eigen.cpp:12:
Bug#1000779: eigen3: autopkgtest regression on armhf: output to stderr
Source: eigen3 Version: 3.4.0-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of eigen3 the autopkgtest of eigen3 fails in testing when that autopkgtest is run with the binary packages of eigen3 from unstable on armhf. It passes when run with only packages from testing. In tabular form: passfail eigen3 from testing3.4.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. The test itself passes, the autopkgtest fails on output to stderr. One can make an autopkgtest not fail on stderr by adding the "allow-stderr" restriction if that's appropriate. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=eigen3 https://ci.debian.net/data/autopkgtest/testing/armhf/e/eigen3/17091576/log.gz In file included from /usr/include/eigen3/Eigen/Core:330, from /usr/include/eigen3/Eigen/Dense:1, from demo.cpp:8: /usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h: In member function ‘void Eigen::internal::lhs_process_one_packetLhsProgress, RhsProgress, LhsScalar, RhsScalar, ResScalar, AccPacket, LhsPacket, RhsPacket, ResPacket, GEBPTraits, LinearMapper, DataMapper>::operator()(const DataMapper&, const LhsScalar*, const RhsScalar*, ResScalar, Eigen::Index, Eigen::Index, Eigen::Index, Eigen::Index, Eigen::Index, Eigen::Index, int, Eigen::Index, Eigen::Index, Eigen::Index, Eigen::Index, Eigen::Index) [with int nr = 4; int LhsProgress = 1; int RhsProgress = 1; LhsScalar = double; RhsScalar = double; ResScalar = double; AccPacket = double; LhsPacket = double; RhsPacket = double; ResPacket = double; GEBPTraits = Eigen::internal::gebp_traits; LinearMapper = Eigen::internal::BlasLinearMapper; DataMapper = Eigen::internal::blas_data_mapper]’: /usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1269:28: note: parameter passing for argument of type ‘Eigen::internal::gebp_traits’ changed in GCC 7.1 1269 | peeled_kc_onestep(0, blA, blB, traits, , _panel, , , , , ); | ~^~~ /usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1270:28: note: parameter passing for argument of type ‘Eigen::internal::gebp_traits’ changed in GCC 7.1 1270 | peeled_kc_onestep(1, blA, blB, traits, , _panel, , , , , ); | ~^~~ /usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1271:28: note: parameter passing for argument of type ‘Eigen::internal::gebp_traits’ changed in GCC 7.1 1271 | peeled_kc_onestep(2, blA, blB, traits, , _panel, , , , , ); | ~^~~ /usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1272:28: note: parameter passing for argument of type ‘Eigen::internal::gebp_traits’ changed in GCC 7.1 1272 | peeled_kc_onestep(3, blA, blB, traits, , _panel, , , , , ); | ~^~~ /usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1274:28: note: parameter passing for argument of type ‘Eigen::internal::gebp_traits’ changed in GCC 7.1 1274 | peeled_kc_onestep(4, blA, blB, traits, , _panel, , , , , ); | ~^~~ /usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1275:28: note: parameter passing for argument of type ‘Eigen::internal::gebp_traits’ changed in GCC 7.1 1275 | peeled_kc_onestep(5, blA, blB, traits, , _panel, , , , , ); | ~^~~ /usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1276:28: note: parameter passing for argument of type ‘Eigen::internal::gebp_traits’ changed in GCC 7.1 1276 | peeled_kc_onestep(6, blA, blB, traits, , _panel, , , , , ); | ~^~~ /usr/include/eigen3/Eigen/src/Core/products/GeneralBlockPanelKernel.h:1277:28: note: parameter passing for argument of type ‘Eigen::internal::gebp_traits’ changed in GCC 7.1 1277 | peeled_kc_onestep(7, blA, blB, traits, , _panel, , , , , ); | ~^~~
Bug#1000778: entrypoints: please use pybuild's flit plugin
Package: src:entrypoints Version: 0.3-8 Severity: wishlist Dear maintainer, Pybuild now supports flit natively. It would be great if you could migrate to it instead of using a custom build system. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#1000777: numpy breaks python-xarray autopkgtest on i386: numerical deltas
Source: numpy, python-xarray
Control: found -1 numpy/1:1.21.4-2
Control: found -1 python-xarray/0.19.0-6
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of numpy the autopkgtest of python-xarray fails in
testing when that autopkgtest is run with the binary packages of numpy
from unstable on i386. It passes when run with only packages from
testing. In tabular form:
passfail
numpy from testing1:1.21.4-2
python-xarray from testing0.19.0-6
versioned deps [0] from testingfrom unstable
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of numpy to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
numpy/1:1.21.4-2. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=numpy
https://ci.debian.net/data/autopkgtest/testing/i386/p/python-xarray/17095751/log.gz
=== FAILURES
===
___ test_interpolate_chunk_advanced[linear]
method = 'linear'
@requires_scipy
@requires_dask
@pytest.mark.parametrize("method", ["linear", "nearest"])
@pytest.mark.filterwarnings("ignore:Increasing number of chunks")
def test_interpolate_chunk_advanced(method):
"""Interpolate nd array with an nd indexer sharing coordinates."""
# Create original array
x = np.linspace(-1, 1, 5)
y = np.linspace(-1, 1, 7)
z = np.linspace(-1, 1, 11)
t = np.linspace(0, 1, 13)
q = np.linspace(0, 1, 17)
da = xr.DataArray(
data=np.sin(x[:, np.newaxis, np.newaxis, np.newaxis,
np.newaxis])
* np.cos(y[:, np.newaxis, np.newaxis, np.newaxis])
* np.exp(z[:, np.newaxis, np.newaxis])
* t[:, np.newaxis]
+ q,
dims=("x", "y", "z", "t", "q"),
coords={"x": x, "y": y, "z": z, "t": t, "q": q, "label":
"dummy_attr"},
)
# Create indexer into `da` with shared coordinate
("full-twist" Möbius strip)
theta = np.linspace(0, 2 * np.pi, 5)
w = np.linspace(-0.25, 0.25, 7)
r = xr.DataArray(
data=1 + w[:, np.newaxis] * np.cos(theta),
coords=[("w", w), ("theta", theta)],
)
x = r * np.cos(theta)
y = r * np.sin(theta)
z = xr.DataArray(
data=w[:, np.newaxis] * np.sin(theta),
coords=[("w", w), ("theta", theta)],
)
kwargs = {"fill_value": None}
expected = da.interp(t=0.5, x=x, y=y, z=z, kwargs=kwargs,
method=method)
da = da.chunk(2)
x = x.chunk(1)
z = z.chunk(3)
actual = da.interp(t=0.5, x=x, y=y, z=z, kwargs=kwargs,
method=method)
assert_identical(actual, expected)
E AssertionError: Left and right DataArray objects are not identical
E E Differing values:
E L
E array([[[ 3.302241e-01, 3.927241e-01, ..., 1.267724e+00,
1.330224e+00],
E [ 1.239764e-17, 6.25e-02, ..., 9.375000e-01,
1.00e+00],
E ...,
E [-5.560517e-17, 6.25e-02, ..., 9.375000e-01,
1.00e+00],
E [ 3.302241e-01, 3.927241e-01, ..., 1.267724e+00,
1.330224e+00]],
E E [[ 3.603946e-01, 4.228946e-01, ...,
1.297895e+00, 1.360395e+00],
E [ 1.346533e-17, 6.25e-02, ..., 9.375000e-01,
1.00e+00],
E ...,
E [-5.109700e-17, 6.25e-02, ..., 9.375000e-01,
1.00e+00],
E [ 3.603946e-01, 4.228946e-01, ..., 1.297895e+00,
1.360395e+00]],
E E ...,
E E [[ 4.810764e-01, 5.435764e-01, ...,
1.418576e+00, 1.481076e+00],
E [ 1.878775e-17, 6.25e-02, ..., 9.375000e-01,
1.00e+00],
E ...,
E [-3.662163e-17, 6.25e-02, ..., 9.375000e-01,
1.00e+00],
E [ 4.810764e-01, 5.435764e-01, ..., 1.418576e+00,
1.481076e+00]],
E E [[ 5.112469e-01, 5.737469e-01, ...,
1.448747e+00, 1.511247e+00],
E [
Bug#1000776: golang-github-go-openapi-errors breaks golang-github-go-openapi-runtime autopkgtest: not enough arguments in call to "github.com/go-openapi/errors"
Source: golang-github-go-openapi-errors, golang-github-go-openapi-runtime Control: found -1 golang-github-go-openapi-errors/0.20.1-1 Control: found -1 golang-github-go-openapi-runtime/0.15.0-1 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of golang-github-go-openapi-errors the autopkgtest of golang-github-go-openapi-runtime fails in testing when that autopkgtest is run with the binary packages of golang-github-go-openapi-errors from unstable. It passes when run with only packages from testing. In tabular form: passfail golang-github-go-openapi-errors from testing0.20.1-1 golang-github-go-openapi-runtime from testing0.15.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of golang-github-go-openapi-errors to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=golang-github-go-openapi-errors https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-go-openapi-runtime/17090239/log.gz [info] Testing github.com/go-openapi/runtime... [info] Source code installed by binary package, overriding dh_auto_configure... dh build --buildsystem=golang --with=golang dh_update_autotools_config -O--buildsystem=golang dh_autoreconf -O--buildsystem=golang debian/rules override_dh_auto_configure make[1]: Entering directory '/tmp/autopkgtest-lxc.te2evu81/downtmp/autopkgtest_tmp' mkdir -p "obj-x86_64-linux-gnu" cp -a /usr/share/gocode/src "obj-x86_64-linux-gnu" make[1]: Leaving directory '/tmp/autopkgtest-lxc.te2evu81/downtmp/autopkgtest_tmp' dh_auto_build -O--buildsystem=golang cd obj-x86_64-linux-gnu && go install -trimpath -v -p 48 github.com/go-openapi/runtime github.com/go-openapi/runtime/client github.com/go-openapi/runtime/flagext github.com/go-openapi/runtime/internal/testing github.com/go-openapi/runtime/internal/testing/petstore github.com/go-openapi/runtime/internal/testing/simplepetstore github.com/go-openapi/runtime/logger github.com/go-openapi/runtime/middleware github.com/go-openapi/runtime/middleware/denco github.com/go-openapi/runtime/middleware/header github.com/go-openapi/runtime/middleware/untyped github.com/go-openapi/runtime/security github.com/go-openapi/runtime/yamlpc internal/goexperiment internal/race unicode/utf16 unicode internal/unsafeheader encoding unicode/utf8 runtime/internal/sys vendor/golang.org/x/crypto/cryptobyte/asn1 internal/itoa crypto/internal/subtle vendor/golang.org/x/crypto/internal/subtle crypto/subtle internal/cpu runtime/internal/atomic math/bits internal/nettrace container/list internal/abi sync/atomic runtime/internal/math internal/bytealg math runtime internal/reflectlite sync internal/testlog internal/singleflight internal/sysinfo github.com/josharian/intern math/rand runtime/cgo errors sort internal/oserror path vendor/golang.org/x/net/dns/dnsmessage io crypto/elliptic/internal/fiat strconv syscall crypto/internal/randutil hash bytes strings crypto/hmac hash/crc32 vendor/golang.org/x/crypto/hkdf crypto/rc4 crypto reflect vendor/golang.org/x/text/transform golang.org/x/text/transform net/http/internal/ascii net/http/internal/testcert bufio html regexp/syntax golang.org/x/text/width internal/syscall/execenv internal/syscall/unix time regexp context io/fs internal/poll golang.org/x/net/context os internal/fmtsort encoding/binary encoding/base64 crypto/md5 crypto/ed25519/internal/edwards25519/field crypto/sha512 crypto/cipher crypto/sha1 crypto/sha256 vendor/golang.org/x/crypto/poly1305 io/ioutil path/filepath fmt runtime/debug net encoding/pem vendor/golang.org/x/sys/cpu crypto/ed25519/internal/edwards25519 crypto/des vendor/golang.org/x/crypto/chacha20 crypto/aes vendor/golang.org/x/crypto/chacha20poly1305 encoding/hex log net/url encoding/xml net/http/internal mime/quotedprintable vendor/golang.org/x/crypto/curve25519 github.com/go-openapi/runtime/logger mime github.com/docker/go-units encoding/json vendor/golang.org/x/net/http2/hpack github.com/pmezard/go-difflib/difflib text/template/parse database/sql/driver compress/flate runtime/trace flag gopkg.in/mgo.v2/internal/json encoding/gob golang.org/x/text/unicode/norm vendor/golang.org/x/text/unicode/norm gopkg.in/yaml.v2 math/big gopkg.in/yaml.v3 github.com/go-openapi/runtime/flagext github.com/davecgh/go-spew/spew github.com/go-openapi/analysis/internal/debug golang.org/x/text/unicode/bidi vendor/golang.org/x/text/unicode/bidi
Bug#1000775: golang-github-go-openapi-errors breaks prometheus-alertmanager autopkgtest: not enough arguments in call to "github.com/go-openapi/errors"
Source: golang-github-go-openapi-errors, prometheus-alertmanager Control: found -1 golang-github-go-openapi-errors/0.20.1-1 Control: found -1 prometheus-alertmanager/0.21.0+ds-4 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of golang-github-go-openapi-errors the autopkgtest of prometheus-alertmanager fails in testing when that autopkgtest is run with the binary packages of golang-github-go-openapi-errors from unstable. It passes when run with only packages from testing. In tabular form: passfail golang-github-go-openapi-errors from testing0.20.1-1 prometheus-alertmanager from testing0.21.0+ds-4 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of golang-github-go-openapi-errors to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=golang-github-go-openapi-errors https://ci.debian.net/data/autopkgtest/testing/amd64/p/prometheus-alertmanager/17090240/log.gz [info] Testing github.com/prometheus/alertmanager... [info] Source code installed by binary package, overriding dh_auto_configure... dh build --buildsystem=golang --with=golang \ --builddirectory=/tmp/autopkgtest-lxc.g1act3hi/downtmp/autopkgtest_tmp/build dh_update_autotools_config -O--buildsystem=golang -O--builddirectory=/tmp/autopkgtest-lxc.g1act3hi/downtmp/autopkgtest_tmp/build dh_autoreconf -O--buildsystem=golang -O--builddirectory=/tmp/autopkgtest-lxc.g1act3hi/downtmp/autopkgtest_tmp/build debian/rules override_dh_auto_configure make[1]: Entering directory '/tmp/autopkgtest-lxc.g1act3hi/downtmp/autopkgtest_tmp' mkdir -p "build" cp -a /usr/share/gocode/src "build" make[1]: Leaving directory '/tmp/autopkgtest-lxc.g1act3hi/downtmp/autopkgtest_tmp' debian/rules override_dh_auto_build make[1]: Entering directory '/tmp/autopkgtest-lxc.g1act3hi/downtmp/autopkgtest_tmp' dh_auto_build -- -ldflags " -X github.com/prometheus/common/version.Version=0.21.0+ds -X github.com/prometheus/common/version.Revision=0.21.0+ds-4 -X github.com/prometheus/common/version.Branch=debian/sid -X github.com/prometheus/common/version.BuildUser=team+pkg...@tracker.debian.org -X github.com/prometheus/common/version.BuildDate=20210129-00:48:05 -X github.com/prometheus/common/version.GoVersion=go1.17.3" cd build && go install -trimpath -v -p 2 -ldflags " -X github.com/prometheus/common/version.Version=0.21.0+ds -X github.com/prometheus/common/version.Revision=0.21.0+ds-4 -X github.com/prometheus/common/version.Branch=debian/sid -X github.com/prometheus/common/version.BuildUser=team+pkg...@tracker.debian.org -X github.com/prometheus/common/version.BuildDate=20210129-00:48:05 -X github.com/prometheus/common/version.GoVersion=go1.17.3" github.com/prometheus/alertmanager/api github.com/prometheus/alertmanager/api/metrics github.com/prometheus/alertmanager/api/v1 github.com/prometheus/alertmanager/api/v2 github.com/prometheus/alertmanager/api/v2/client github.com/prometheus/alertmanager/api/v2/client/alert github.com/prometheus/alertmanager/api/v2/client/alertgroup github.com/prometheus/alertmanager/api/v2/client/general github.com/prometheus/alertmanager/api/v2/client/receiver github.com/prometheus/alertmanager/api/v2/client/silence github.com/prometheus/alertmanager/api/v2/models github.com/prometheus/alertmanager/api/v2/restapi github.com/prometheus/alertmanager/api/v2/restapi/operations github.com/prometheus/alertmanager/api/v2/restapi/operations/alert github.com/prometheus/alertmanager/api/v2/restapi/operations/alertgroup github.com/prometheus/alertmanager/api/v2/restapi/operations/general github.com/prometheus/alertmanager/api/v2/restapi/operations/receiver github.com/prometheus/alertmanager/api/v2/restapi/operations/silence github.com/prometheus/alertmanager/cli github.com/prometheus/alertmanager/cli/config github.com/prometheus/alertmanager/cli/format github.com/prometheus/alertmanager/client github.com/prometheus/alertmanager/cluster github.com/prometheus/alertmanager/cluster/clusterpb github.com/prometheus/alertmanager/cmd/alertmanager github.com/prometheus/alertmanager/cmd/amtool github.com/prometheus/alertmanager/config github.com/prometheus/alertmanager/dispatch github.com/prometheus/alertmanager/inhibit github.com/prometheus/alertmanager/nflog github.com/prometheus/alertmanager/nflog/nflogpb github.com/prometheus/alertmanager/notify
Bug#685506: Reach out to www.debian.org
Hi, For your information: In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000771 is help requested from people of pseudo-package www.debian.org Groeten Geert Stappers -- Silence is hard to parse
Bug#1000774: python3-matplotlib: Segfault on mips64el in draw
Package: python3-matplotlib Version: 3.5.0-2 Severity: serious Justification: FTBFS Affects: deap deap FTBFS on mips64el, in matplotlib, I'd assume this is a matploptlib regression on mips64el: Current thread 0x00fff7382010 (most recent call first): File "/usr/lib/python3/dist-packages/matplotlib/collections.py", line 422 in draw File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper File "/usr/lib/python3/dist-packages/matplotlib/collections.py", line 989 in draw File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper File "/usr/lib/python3/dist-packages/mpl_toolkits/mplot3d/art3d.py", line 532 in draw File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in _draw_list_compositin g_images File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082 in draw File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper File "/usr/lib/python3/dist-packages/mpl_toolkits/mplot3d/axes3d.py", line 469 in draw File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in _draw_list_compositin g_images File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2803 in draw File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in draw_wrapper File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73 in draw_wrapper File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", line 436 in draw File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", line 540 in print_ png File "/usr/lib/python3/dist-packages/matplotlib/_api/deprecation.py", line 412 in wrapper File "/usr/lib/python3/dist-packages/matplotlib/backend_bases.py", line 1643 in wrapper File "/usr/lib/python3/dist-packages/matplotlib/backend_bases.py", line 2314 in print_figure File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 3012 in savefig File "/usr/lib/python3/dist-packages/matplotlib/sphinxext/plot_directive.py", line 647 in re nder_figures File "/usr/lib/python3/dist-packages/matplotlib/sphinxext/plot_directive.py", line 789 in ru n File "/usr/lib/python3/dist-packages/matplotlib/sphinxext/plot_directive.py", line 259 in ru n File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 2147 in run_directive File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 2097 in directive File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 2355 in explicit_construct File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 2343 in explicit_markup File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 451 in check_line File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 239 in run File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 197 in run File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 282 in nested_parse File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 394 in new_subsection File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 328 in section File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 2770 in underline File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 451 in check_line File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 239 in run File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 197 in run File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 282 in nested_parse File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 394 in new_subsection File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 328 in section File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 3009 in text File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 451 in check_line File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 239 in run File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", line 171 in run File "/usr/lib/python3/dist-packages/sphinx/parsers.py", line 101 in parse File "/usr/lib/python3/dist-packages/docutils/readers/__init__.py", line 78 in parse File "/usr/lib/python3/dist-packages/sphinx/io.py", line 109 in read File "/usr/lib/python3/dist-packages/docutils/core.py", line 217 in publish File "/usr/lib/python3/dist-packages/sphinx/io.py", line 189 in read_doc File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 476 in read_doc File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 436 in _read_serial File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 415 in read File
Bug#997948: winff FTBFS: Fatal: (10022) Can't find unit Interfaces used by winff
Hi Paul > A retry worked. It seems to me that the failure was due to lazarus not > having been rebuild against the latest fpc in the archive. More exactly, because the installed lcl-units-* were not build using the installed FPC. > But in Debian > I'd expect package relations to embed the knowledge to prevent this from > happening. This is generally the case except when FPC get upgraded to a new version, which is generally a transitory situation for a very short time. > > Similar to the discussion in bug 997940 about src:castle-game-engine. It is not exactly the same. Lazarus is an IDE + framework (LCL). The IDE itself can work with whatever FPC version and with many LCL versions. So in principle, one can install the IDE and have a custom FPC + LCL. One problem here is that the LCL is packaged with the IDE, and this is a issue from upstream not separating the IDE development from the framework development. I don't like the idea to enforce the dependency because in principle, the same instance of Lazarus IDE can work with FPC-2.2.0 and FPC-2.2.2 which allows a developer to have time to migrate his application broken by a FPC or LCL upgrade wile using the last IDE. I personally use this feature for a SW that is tightly linked to LCL and thus using a new Lazarus with an old LCL until upgrade is done. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1000773: ruby-gitlab-sidekiq-fetcher: autopkgtest needs update for new version of ruby-sidekiq: Could not find 'sidekiq' (>= 5, < 6.1)
Source: ruby-gitlab-sidekiq-fetcher Version: 0.6.1-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:ruby-sidekiq [X-Debbugs-CC: debian...@lists.debian.org, ruby-side...@packages.debian.org] Dear maintainer(s), With a recent upload of ruby-sidekiq the autopkgtest of ruby-gitlab-sidekiq-fetcher fails in testing when that autopkgtest is run with the binary packages of ruby-sidekiq from unstable. It passes when run with only packages from testing. In tabular form: passfail ruby-sidekiqfrom testing6.3.1+dfsg-1 ruby-gitlab-sidekiq-fetcher from testing0.6.1-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of ruby-sidekiq to testing [1]. Of course, ruby-sidekiq shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in ruby-sidekiq was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from ruby-sidekiq should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=ruby-sidekiq https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-gitlab-sidekiq-fetcher/17076745/log.gz ┌──┐ │ Checking Rubygems dependency resolution on ruby2.7 │ └──┘ GEM_PATH= ruby2.7 -e gem\ \"gitlab-sidekiq-fetcher\" /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies': Could not find 'sidekiq' (>= 5, < 6.1) among 61 total gem(s) (Gem::MissingSpecError) Checked in 'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0' at: /usr/share/rubygems-integration/all/specifications/gitlab-sidekiq-fetcher-0.6.1.gemspec, execute `gem env` for more information from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block in activate_dependencies' from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each' from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `activate_dependencies' from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in `activate' from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block in gem' from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `synchronize' from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem' from -e:1:in `' /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not find 'sidekiq' (>= 5, < 6.1) - did find: [sidekiq-6.3.1] (Gem::MissingSpecVersionError) Checked in 'GEM_PATH=/home/debci/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0' , execute `gem env` for more information from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block in activate_dependencies' from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each' from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `activate_dependencies' from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in `activate' from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block in gem' from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `synchronize' from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem' from -e:1:in `' benchmark (default: 0.1.0) bigdecimal (default: 2.0.0) bundler (default: 2.1.4) cgi (default: 0.1.0) connection_pool (2.2.5) csv (default: 3.1.2) date (default: 3.0.0) dbm (default: 1.1.0) delegate (default: 0.1.0) did_you_mean (default: 1.4.0) etc (default: 1.1.0) fcntl (default: 1.0.0) fiddle (default: 1.0.0) fileutils (default: 1.4.1) forwardable (default: 1.3.1) gdbm (default: 2.1.0) getoptlong (default: 0.1.0) gitlab-sidekiq-fetcher (0.6.1) io-console
Bug#1000680: python3-aiohttp: fails to import, "TypeError: function() argument 'code' must be code, not str"
[Boyuan Yang, 2021-11-28] > Thanks for the info and sorry for the breakage; obviously I should have > uploaded it into Experimental first. I am looking into fixing the issue > (ideally through upgrade of all related packages) but this may take some time. > If you already have a solution, it would be even better. I already fixed it by upgrading aiohttp. It needs 2 NEW packages that I packaged and uploaded, one of them is already accepted, second it waiting for review. Unfortunately I uploaded my previous build (tagged 1~exp1 in the git repo, but uploaded -1 so version in unstable needs aiosignal ASAP - I asked one of the ftp-masters if it's possible to check it sooner and hopefully unstable will be fixed soon)
Bug#1000772: macaulay2: autopkgtest regression on i386: out of memory
Source: macaulay2 Version: 1.19+ds-3 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of macaulay2 the autopkgtest of macaulay2 fails in testing when that autopkgtest is run with the binary packages of macaulay2 from unstable. It passes when run with only packages from testing. In tabular form: passfail macaulay2 from testing1.19+ds-3 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from macaulay2/1.19+ds-3. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=macaulay2 https://ci.debian.net/data/autopkgtest/testing/i386/m/macaulay2/17068663/log.gz K3Surfaces ** -- capturing check(0, "K3Surfaces") -- 15.155 seconds elapsed -- capturing check(1, "K3Surfaces") -- 3.51379 seconds elapsed -- capturing check(2, "K3Surfaces") -- 14.3303 seconds elapsed -- capturing check(3, "K3Surfaces") -- 27.3209 seconds elapsed -- capturing check(4, "K3Surfaces") -- 1.92744 seconds elapsed -- capturing check(5, "K3Surfaces") -- 9.5648 seconds elapsed -- skipping check(6, "K3Surfaces") -- 0.00011649 seconds elapsed -- skipping check(7, "K3Surfaces") -- 0.7854 seconds elapsed -- capturing check(8, "K3Surfaces") *** out of memory trying to allocate 131108 bytes, exiting *** cd /tmp/M2-2812-0/171-rundir/; GC_MAXIMUM_HEAP_SIZE=400M "/usr/bin/M2-binary" -q --int --no-randomize --no-readline --silent --stop --print-width 77 <"/tmp/M2-2812-0/170.m2" >>"/tmp/M2-2812-0/170.tmp" /tmp/M2-2812-0/170.tmp:0:1: (output file) error: Macaulay2 exited with status code 1 /tmp/M2-2812-0/170.m2:0:1: (input file) M2: *** Error 1 OpenPGP_signature Description: OpenPGP digital signature
Bug#981549: [Pkg-pascal-devel] Bug#981549: Bug#981549: lazarus-ide: At startup, a message will appear if it is different from the ver described in version.inc.
Control: fixed -1 2.0.12+dfsg1-1 This issue was fixed on 2.0.12 and nobody was objecting the closure published in last message. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1000680: python3-aiohttp: fails to import, "TypeError: function() argument 'code' must be code, not str"
Hi, 在 2021-11-27星期六的 23:23 -0500，Sandro Tosi写道： > > root@zion:/# python3.9 -c "import aiohttp" > > Traceback (most recent call last): > > File "", line 1, in > > File "/usr/lib/python3/dist-packages/aiohttp/__init__.py", line 6, in > > > > from .client import ( > > File "/usr/lib/python3/dist-packages/aiohttp/client.py", line 35, in > > > > from . import hdrs, http, payload > > File "/usr/lib/python3/dist-packages/aiohttp/http.py", line 7, in > > > > from .http_parser import ( > > File "/usr/lib/python3/dist-packages/aiohttp/http_parser.py", line 15, > > in > > from .helpers import NO_EXTENSIONS, BaseTimerContext > > File "/usr/lib/python3/dist-packages/aiohttp/helpers.py", line 667, in > > > > class CeilTimeout(async_timeout.timeout): > > TypeError: function() argument 'code' must be code, not str > > > > > > root@zion:/# python3.10 -c "import aiohttp" > > Traceback (most recent call last): > > File "", line 1, in > > File "/usr/lib/python3/dist-packages/aiohttp/__init__.py", line 6, in > > > > from .client import ( > > File "/usr/lib/python3/dist-packages/aiohttp/client.py", line 35, in > > > > from . import hdrs, http, payload > > File "/usr/lib/python3/dist-packages/aiohttp/http.py", line 7, in > > > > from .http_parser import ( > > File "/usr/lib/python3/dist-packages/aiohttp/http_parser.py", line 15, > > in > > from .helpers import NO_EXTENSIONS, BaseTimerContext > > File "/usr/lib/python3/dist-packages/aiohttp/helpers.py", line 667, in > > > > class CeilTimeout(async_timeout.timeout): > > TypeError: function() argument 'code' must be code, not str > > Boyuan, > you caused this by uploading python-async-timeout 4.x > > https://tracker.debian.org/news/1280914/accepted-python-async-timeout-401-1-source-into-unstable/ > > while aiohttp is incompatible with it. > > Apparently the latest version of aiohttp supports async-timeout > 4.0 > > https://github.com/aio-libs/aiohttp/blob/v3.8.1/setup.cfg#L54 > > are you going to handle this upgrade? Thanks for the info and sorry for the breakage; obviously I should have uploaded it into Experimental first. I am looking into fixing the issue (ideally through upgrade of all related packages) but this may take some time. If you already have a solution, it would be even better. Thanks, Boyuan Yang
Bug#999918: zsh: depends on obsolete pcre3 library -- tracked in Ubuntu as well
Hi, JFTR: This is tracked in Ubuntu as well. The according bug report is at https://bugs.launchpad.net/ubuntu/+source/zsh/+bug/1792544, affects many packages and exists for quite a while now. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1000396: systemd-detect-virt falsely detects "Microsoft" virtualisation
Hi Michael, I can see from the upstream issue that the problem has been fixed with a fairly small code change. Would it be possible to carry the fix as a patch in the debian package until the fix makes it into a stable release? https://github.com/systemd/systemd/commit/76eec0649936d9ae2f9087769f463feaf0cf5cb4.patch On Mon, 22 Nov 2021 17:40:05 +0100 Michael Biebl wrote: > Control: forwarded -1 https://github.com/systemd/systemd/issues/21468 > > Am 22.11.21 um 16:37 schrieb Michael Biebl: > > On 22.11.21 14:06, Liban Hannan wrote: > > > >> systemd-detect-virt checks /sys/class/dmi/id/sys_vendor as part of its > >> attempt to detect if the system is virtualised. I am using a Surface > >> Laptop so sys_vendor returns "Microsoft Corporation" which (as far as I > >> can tell) the program assumes indicates the presence of hyper-v rather > >> than Microsoft produced hardware. One of the consequences is that > >> systemd units that won't run in a VM fail, such as thermald. > > > > Would you mind forwarding this issue to upstream by filing an issue at > > https://github.com/systemd/systemd/issues > > I've filed it as https://github.com/systemd/systemd/issues/21468 > > Please consider subscribing to this upstream bug report in case upstream > has further questions. > > >
Bug#1000771: missing Files-Excluded in packaging-manuals/copyright-format
Package: www.debian.org Hello www.debian.org care takers, While searching for information about field 'Files-Excluded: ' in debian/copyright did I came across https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ That document is not yet aware of the field. Since https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685506#197 is there a patch for it. Please advice how to add information to https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Groeten Geert Stappers -- Silence is hard to parse
Bug#1000743: installation-reports: bootx64.efi didn't seem to get installed and no UEFI boot entry was created for Debian
Le 28/11/2021 à 15:06, Steve McIntyre a écrit : On Sun, Nov 28, 2021 at 02:24:06PM +0100, Pascal Hambourg wrote: Shouldn't there normally be EFI/boot/bootx64.efi? Not by default. It happens only if you choose to install a copy of the boot loader in the removable device path. The option is available only in expert install or after changing priority for questions to low. Agreed. We deliberately do *not* install there by default as this can cause other OSes not to boot. We try to be more accommodating than Windows etc. :-/ This is too detrimental to Debian IMO, there are too many broken UEFI firmwares out there. As I suggested in a previous post, what about setting grub2/force_efi_extra_removable true by default when the file does not exist ?
Bug#1000769: node-marked: please make the build reproducible
Source: node-marked
Version: 4.0.5+ds-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0] we noticed that
node-marked could not be built reproducibly.
This is because the existing reproducible.patch is not complete and
misses a copyright notice that has a nondeterministic date. A patch
to the current packaging is attached, but as this is a "diff of a
diff", I have also attached an updated reproducible.patch.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible.patch 2021-11-28 11:34:20.634085499 -0800
--- b/debian/patches/reproducible.patch 2021-11-28 11:37:35.838392663 -0800
@@ -3,9 +3,18 @@
Forwarded: not-needed
Last-Update: 2020-12-01
a/rollup.config.js
-+++ b/rollup.config.js
-@@ -19,7 +19,7 @@
+--- node-marked-4.0.5+ds.orig/rollup.config.js
node-marked-4.0.5+ds/rollup.config.js
+@@ -19,7 +19,7 @@ The code in this file is generated from
+ license({
+ banner: `
+ marked - a markdown parser
+-Copyright (c) 2011-${new Date().getFullYear()}, Christopher Jeffrey. (MIT
Licensed)
++Copyright (c) 2011-${(new Date(process.env.SOURCE_DATE_EPOCH ?
(process.env.SOURCE_DATE_EPOCH * 1000) : new Date().getTime())).getFullYear()},
Christopher Jeffrey. (MIT Licensed)
+ https://github.com/markedjs/marked
+ `
+ }),
+@@ -46,7 +46,7 @@ The code in this file is generated from
license({
banner: `
marked - a markdown parser
--- a/rollup.config.js 2021-11-28 11:34:20.634085499 -0800
--- b/rollup.config.js 2021-11-28 11:37:32.802388038 -0800
@@ -46,7 +46,7 @@
license({
banner: `
marked - a markdown parser
-Copyright (c) 2011-${new Date().getFullYear()}, Christopher Jeffrey. (MIT
Licensed)
+Copyright (c) 2011-${(new Date(process.env.SOURCE_DATE_EPOCH ?
(process.env.SOURCE_DATE_EPOCH * 1000) : new Date().getTime())).getFullYear()},
Christopher Jeffrey. (MIT Licensed)
https://github.com/markedjs/marked
`
}),
Description: make build reproducible
Author: Xavier Guimard
Forwarded: not-needed
Last-Update: 2020-12-01
--- node-marked-4.0.5+ds.orig/rollup.config.js
+++ node-marked-4.0.5+ds/rollup.config.js
@@ -19,7 +19,7 @@ The code in this file is generated from
license({
banner: `
marked - a markdown parser
-Copyright (c) 2011-${new Date().getFullYear()}, Christopher Jeffrey. (MIT Licensed)
+Copyright (c) 2011-${(new Date(process.env.SOURCE_DATE_EPOCH ? (process.env.SOURCE_DATE_EPOCH * 1000) : new Date().getTime())).getFullYear()}, Christopher Jeffrey. (MIT Licensed)
https://github.com/markedjs/marked
`
}),
@@ -46,7 +46,7 @@ The code in this file is generated from
license({
banner: `
marked - a markdown parser
-Copyright (c) 2011-${new Date().getFullYear()}, Christopher Jeffrey. (MIT Licensed)
+Copyright (c) 2011-${(new Date(process.env.SOURCE_DATE_EPOCH ? (process.env.SOURCE_DATE_EPOCH * 1000) : new Date().getTime())).getFullYear()}, Christopher Jeffrey. (MIT Licensed)
https://github.com/markedjs/marked
`
}),
Bug#1000770: perfect-scrollbar: please make the build reproducible
Source: perfect-scrollbar
Version: 1.5.2+ds-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0] we noticed that
perfect-scrollbar could not be built reproducibly.
This is because a copyright notice embeds the current build year.
Patch attached.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1969-12-31 16:00:00.0
-0800
--- b/debian/patches/reproducible-build.patch 2021-11-28 11:35:57.366240536
-0800
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2021-11-28
+
+--- perfect-scrollbar-1.5.2+ds.orig/rollup.config.js
perfect-scrollbar-1.5.2+ds/rollup.config.js
+@@ -7,7 +7,7 @@ const version = require('./package.json'
+ const banner =
+ `/*!
+ * perfect-scrollbar v${version}
+- * Copyright ${new Date().getFullYear()} Hyunje Jun, MDBootstrap and
Contributors
++ * Copyright ${(new Date(process.env.SOURCE_DATE_EPOCH ?
(process.env.SOURCE_DATE_EPOCH * 1000) : new Date().getTime())).getFullYear()}
Hyunje Jun, MDBootstrap and Contributors
+ * Licensed under MIT
+ */
+ `;
--- a/debian/patches/series 2021-11-28 11:34:09.082066502 -0800
--- b/debian/patches/series 2021-11-28 11:35:56.362238958 -0800
@@ -1 +1,2 @@
do-not-use-rollup-minify.patch
+reproducible-build.patch
Bug#1000768: krb5: FTBFS due to missing dependency on tex-gyre
Source: krb5
Severity: serious
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Between September and October, something changed in krb5's build
dependencies that triggers a build failure:
https://tests.reproducible-builds.org/debian/history/amd64/krb5.html
You can pick from a few failing build logs at:
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/krb5.html
Except from a failing build:
(/usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def))
(/usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf))
! LaTeX Error: File `tgtermes.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
l.37 \usepackage
{tgheros}^^M
! ==> Fatal error occurred, no output PDF file produced!
I'm not sure the exact cause of the changes, but adding tex-gyre to
Build-Depends-Indep appears to fix this issue.
Thanks for maintaining krb5!
live well,
vagrant
From ba098c18c519c9275eafeac18983e5974a8714af Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Sun, 28 Nov 2021 18:56:56 +
Subject: [PATCH] debian/control: Add Build-Depends-Indep on tex-gyre.
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index bd78bbe11..973f11b64 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Build-Depends: debhelper-compat (= 13), byacc | bison,
libkeyutils-dev [linux-any], libldap2-dev , libsasl2-dev ,
libssl-dev, ss-dev,
libverto-dev (>= 0.2.4), pkg-config
-Build-Depends-Indep: python3, python3-cheetah, python3-lxml, python3-sphinx, doxygen, doxygen-latex
+Build-Depends-Indep: python3, python3-cheetah, python3-lxml, python3-sphinx, doxygen, doxygen-latex, tex-gyre
Standards-Version: 4.5.0
Maintainer: Sam Hartman
Uploaders: Russ Allbery , Benjamin Kaduk
--
2.30.2
signature.asc
Description: PGP signature
Bug#1000715: dpkg -S fails to identify package for coreutils files: says 'no path found matching pattern' instead
On Sun, 28 Nov 2021 09:48:22 +0100 Niels Thykier wrote: > This is a consequence of the currently incomplete "/usr-merge" > transition, where /bin has been merged into /usr/bin without dpkg's back. > > As such, dpkg knows those paths only by their "officially declared" > paths in /bin. It is obviously confusing to you as a user because you > then have to "know" whether to search for /usr/bin/P or /bin/P. > > As a work around you can use a wild card search, such as: > > dpkg -S '*/bin/ls' > I suppose this means I don't actually understand how dpkg works at all. The files are there in /usr/bin, and SOMETHING, presumably an installer run by dpkg the most recent time coreutils was updated, installed them. But dpkg does not know which installer was running at the time? Does it rely on some information separate from keeping track of the actual files written while an installer is running, to know which installer was responsible for writing the files? That's very unexpected at least to me. It seems like manually maintaining the lists would be a lot more work than coding the automatic tracking I had assumed was happening. I'd be interested in understanding the design constraints that make it preferable. Not that it makes much difference on the ground right now. The news relevant to this is, it's on your radar already as an issue with this migration/merge situation, and I'm not bringing up anything that wouldn't eventually get fixed otherwise. So I suppose all there is to say is "known issue" and "workaround available" and close this when you get to it in the due course of the migration work. I hope various aspects of this don't cause you too many more headaches. Honestly I don't have much opinion on the /bin and /usr/bin merger; the pros and cons seem balanced on a knife edge to me. It seems like an objectively good impulse to reduce complexity, but it also seems like a hell of a lot of work, pain, and confusion to go through right now for what will be, in any particular future year, only a very minor benefit. On the third hand there won't come a time in the future when it's easier or less painful than right now, so the choice is existential; rather than "when", we face "whether at all" because the pro and con arguments are unlikely to change. Bear
Bug#1000622: ser2net: Fails to start on boot since the serial port is not ready
On Sat, Nov 27, 2021 at 05:29:23PM -0600, Corey Minyard wrote: > On Sat, Nov 27, 2021 at 09:29:24AM +0100, Marc Haber wrote: > > ser2net[625]: Invalid port name/number: Invalid data to parameter on > > line 30 column 0 > > > > since it might refer to a serial port as well as to a TCP port. I guess > > this misled me to ser2net complaining about the /dev/ttyAMA0 not > > appearing in time. > > Yes, that is an issue; I have made the error message precise. Thank you! > > > > Additionally, the ser2net.yml quoted by the original bug reporter in the > > original bug report does not seem to have 30 lines. This is all very > > strange for me. > > Also an issue. This error means that gensio was unable to parse an > accepter line. On line 30. I woud guess there is something incorrect > on line 30 in an accepter: . So that ie neither a line in a configuration file, nor a code line in the sources, but a line like a serial line? That would never have occurred to me, this needs less ambigious wording. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#995202: horst: diff for NMU version 5.1-2.1
Dear maintainer,
I've prepared an NMU for horst (versioned as 5.1-2.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.
cu
Adrian
diff -Nru horst-5.1/debian/changelog horst-5.1/debian/changelog
--- horst-5.1/debian/changelog 2019-02-01 17:29:06.0 +0200
+++ horst-5.1/debian/changelog 2021-11-28 20:51:58.0 +0200
@@ -1,3 +1,11 @@
+horst (5.1-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch from Sven Joachim to fix FTBFS with new ncurses.
+(Closes: #995202)
+
+ -- Adrian Bunk Sun, 28 Nov 2021 20:51:58 +0200
+
horst (5.1-2) unstable; urgency=medium
* Bug fix: "horst FTCBFS: upstream Makefile hard codes build
diff -Nru horst-5.1/debian/patches/0001-Fix-string-format-errors-with-recent-ncurses.patch horst-5.1/debian/patches/0001-Fix-string-format-errors-with-recent-ncurses.patch
--- horst-5.1/debian/patches/0001-Fix-string-format-errors-with-recent-ncurses.patch 1970-01-01 02:00:00.0 +0200
+++ horst-5.1/debian/patches/0001-Fix-string-format-errors-with-recent-ncurses.patch 2021-11-28 20:51:36.0 +0200
@@ -0,0 +1,39 @@
+From 8110d832bd6502b7caed75b6504bd6d24d30d36b Mon Sep 17 00:00:00 2001
+From: Sven Joachim
+Date: Thu, 14 Oct 2021 20:06:26 +0200
+Subject: [PATCH] Fix string format errors with recent ncurses
+
+---
+ display-main.c | 2 +-
+ display.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/display-main.c b/display-main.c
+index b613291..6519895 100644
+--- a/display-main.c
b/display-main.c
+@@ -53,7 +53,7 @@ static struct ewma bpsn_avg;
+ void print_dump_win(const char *str, int refresh)
+ {
+ wattron(dump_win, RED);
+- wprintw(dump_win, str);
++ wprintw(dump_win, "%s", str);
+ wattroff(dump_win, RED);
+ if (refresh)
+ wrefresh(dump_win);
+diff --git a/display.c b/display.c
+index 777c7a2..e0755f4 100644
+--- a/display.c
b/display.c
+@@ -86,7 +86,7 @@ print_centered(WINDOW* win, int line, int cols, const char *fmt, ...)
+ vsnprintf(buf, cols, fmt, ap);
+ va_end(ap);
+
+- mvwprintw(win, line, cols / 2 - strlen(buf) / 2, buf);
++ mvwprintw(win, line, cols / 2 - strlen(buf) / 2, "%s", buf);
+ free(buf);
+ }
+
+--
+2.33.0
+
diff -Nru horst-5.1/debian/patches/series horst-5.1/debian/patches/series
--- horst-5.1/debian/patches/series 2019-02-01 17:29:06.0 +0200
+++ horst-5.1/debian/patches/series 2021-11-28 20:51:57.0 +0200
@@ -1,3 +1,4 @@
cross.patch
0001-add-support-for-PREFIX.patch
0001-install-manpages-in-share-properly-Closes-91.patch
+0001-Fix-string-format-errors-with-recent-ncurses.patch
Bug#995769: dbab: v1.5.7 package fail to upgrade from bullseye (1.5.01-1)
Hi, Getting package autoremoved from testing is not end-of-the-world -- once the bug is fixed, it can get back to Debian Testing at any time. Meanwhile, the previous bug is real and will need to be fixed sooner or later. I may get back to look into the bug later, bug I don't have enough time recently. Feel free to find help from others, or I may get involved when I have enough time. Thanks, Boyuan Yang 在 2021-11-28星期日的 11:35 -0500，Tong Sun写道： > Hi Boyuan, please please help. > > -- Forwarded message - > From: Tong Sun > Date: Sun, Nov 28, 2021 at 11:33 AM > Subject: Re: Bug#995769: dbab: v1.5.7 package fail to upgrade from > bullseye (1.5.01-1) > To: Boyuan Yang , <995...@bugs.debian.org> > > > To Boyuan, or any mentors reading this issue. > > I've been trying to fix it myself, but all my previous attempts > failed, because I don't understand what breaks and why, from the > output of the package upgrade log. > > I've sent a help request to debian-mentors a few days ago, but nobody > answers yet. > > My package is now marked for autoremoval from testing, with a wrong > reason, and I don't know how to stop my package being autoremed from > testing, and I got no answers/help on that either. > > Since I don't know how to fix it myself, and all my previous attempts > failed, if nobody helps me by next weekend, I'll do the only thing > that I know -- to change the severity of this bug to minor, because > there is a simple solution to it as explained below. This will solve > everything and win me the time it takes for me to do further > investigation/testing. > > Really hope it won't be the case. > Somebody help please. > Thanks > > On Thu, Oct 7, 2021 at 9:31 PM Tong Sun wrote: > > > > On Tue, Oct 5, 2021 at 7:27 AM Boyuan Yang wrote: > > > > > Package dbab/1.5.7-1 has broken maintscript and cannot be properly > > > upgraded > > > from dbab/1.5.01-1 to dbab/1.5.7-1: > > > > Thanks for reporting. I'll try to fix it ASAP. > > > > In the meantime, for anyone who doesn't want to wait for the fix to be > > published -- > > do not do an upgrade -- remove the package completely, then do a fresh > > install. > > > > thx
Bug#1000767: vim: files inside a zip archive appear empty
Package: vim Version: 2:8.2.3565-1+b1 Severity: normal X-Debbugs-Cc: jkran...@gmail.com When trying to edit a file inside any zip archive (doing 'vim some-archive.zip' and choosing a file), vim 8.2.3565-1+b1 only gives an empty buffer, even if file is not actually empty. Vim version 8.2.2434-3 from the stable repository does not have this problem. -- Package-specific info: --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.gtk3 /usr/bin/vim is /usr/bin/vim.gtk3 /usr/bin/gvim is /usr/bin/vim.gtk3 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vim depends on: ii libacl1 2.3.1-1 ii libc62.32-4 ii libgpm2 1.20.7-9 ii libselinux1 3.3-1+b1 ii libsodium23 1.0.18-1 ii libtinfo66.3-1 ii vim-common 2:8.2.3565-1 ii vim-runtime 2:8.2.3565-1 vim recommends no packages. Versions of packages vim suggests: pn ctags pn vim-doc pn vim-scripts -- no debconf information
Bug#1000766: bugs.debian.org: After upgrade to linux kernel 15.15.0-1-amd64 bluetooth controller doen't start
Package: bugs.debian.org Severity: normal X-Debbugs-Cc: safi...@gmx.de Dear Maintainer, * What led up to the situation? * After upgrading to linux kernel 15.15.0-1-amd64 from 15.14.0-4-amd64 bluetooth doesn't work. bluetoothctl says "no controller available". I have a bit older HP laptop with Intel Dual Band Wireless-AC 7265. On startup I get following errors regarding bluetooth: Bluetooth: hci0: Reading Intel version command failed (-110) Bluetooth: hci0: command 0xfc05 tx timeout * What exactly did you do (or not do) that was effective (or ineffective)? * If I start debian with previos kernel (15.14.0-4-amd54) blueooth is working againg
Bug#1000421: Bug#1000146: cppcheck: incorrect dependencies: libc6 should be >= 2.32
Guillem Jover: > Bug #1000421 in package dpkg reported by you has been fixed in > the dpkg/dpkg.git Git repository Thanks for the investigation. What a nuisance. Joachim Reichel (cppcheck maintainer): > I'll upload a new version cppcheck with a workaround shortly Would you mind both prioritising this fix ? FTAOD it's not just cppcheck that is scheduled for autoremoval. Any package which transitively [build-]depends on any package whose .debs are affected will be scheduled for autoremoval (assuming some bug has been filed). I noticed this problem because my own package `dgit` is scheduled for autoremoval due to this bug and I don't even know what the dependency chain is that links dgit to cppcheck. When this happens to me it usually involves git-buildpackage, so perhaps gbp is scheduled for autoremoval too. I also think that when the fixed dpkg-shlibdeps is in unstable: 1. We should consider backporting the dpkg-shlibdeps fix in a stable point release, since it seems people might have new binutils (via a Debian backports suite or from upsteam) 2. We should consider trying to detect this situation in existing .debs and requesting .deb rebuilds or something. Do we have a plausible way of doing that ? Possibly we could look for the combination of new binutils and old dpkg-dev, in buildinfo files. Thanks, Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#1000765: prometheus-nextcloud-exporter: [INTL:pt] Updated Portuguese translation - debconf messages
Package: prometheus-nextcloud-exporter Version: 0.4.0-2 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for prometheus-nextcloud-exporter's debconf messages Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro - prometheus-nextcloud-exporter_0.4.0-2_pt.po.gz Description: application/gzip
Bug#1000764: Chhange Recommends to sudo | doas
Package: inxi Version: 3.3.07-1-1 Severity: wishlist Doas is a massively simpler (and hopefully therefore safer) tool coming from the OpenBSD folks that does what most people use sudo for: Running commands as root. It's already supported by inxi, and is used over sudo if both are installed. As such, would you consider adding it as an alternative to sudo in inxi's Recoomends? Thanks! -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-1-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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) LSM: AppArmor: enabled Versions of packages inxi depends on: ii pciutils 1:3.7.0-6 ii perl 5.32.1-6 ii procps2:3.3.17-5 Versions of packages inxi recommends: ii bind9-dnsutils [dnsutils] 1:9.17.20-3 ii dmidecode 3.3-3 ii file 1:5.41-2 ii hddtemp0.3-beta15-54 ii iproute2 5.15.0-1 ii kmod 29-1 ii lm-sensors 1:3.6.0-7 ii mesa-utils 8.4.0-1+b2 ii net-tools 1.60+git20181103.0eebece-1 ii sudo 1.9.5p2-3 ii tree 1.8.0-1+b1 ii usbutils 1:014-1 ii x11-utils 7.7+5 ii x11-xserver-utils 7.7+9 Versions of packages inxi suggests: ii curl 7.79.1-2 ii libcpanel-json-xs-perl4.27-1 ii libjson-xs-perl 4.030-1+b1 pn libxml-dumper-perl ii perl [libhttp-tiny-perl] 5.32.1-6 ii wget 1.21.2-2+b1 -- no debconf information
Bug#1000763: wims-lti: [INTL:pt] Updated Portuguese translation - debconf messages
Package: wims-lti Version: 0.4.4.1-10 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for wims-lti's debconf messages Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro - wims-lti_0.4.4.1-10_pt.po.gz Description: application/gzip
Bug#1000762: atftp: [INTL:pt] Updated Portuguese translation - debconf messages
Package: atftp Version: 0.7.git20210915-2 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for atftp's debconf messages Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro - atftp_0.7.git20210915-2_pt.po.gz Description: application/gzip
Bug#1000700: Debian 11 - Cinnamon 4.8.6-2 dont work correctly
Il 28/11/2021 17:22, pham...@bluewin.ch ha scritto: Hello and thank you for your message, - The desktop display bug is the most annoying, if you could fix it that would be great... I'm using a stable Debian, I'm afraid that if I upgrade Cinnamon with SID it created an unstable system for me. Sorry for my bad english, are you refer about desktop icons? (managed by nemo) is not optimal in some things but I don't see a bug from a fast look, can you check desktop disposition options if works differently as they setted and specify? - Having a small tool that allows you to choose between old style and new style would be so much more practical, in addition this tool exists in Linux Mint ... I also used Mint on recent tests for muffin rebase but I don't saw it if I remember good, anyway don't seems good to me (and other maintainers in past) add all packages and customization mint specific to debian New users of Cinnamon under Debian or other OS (non Mint) do not even know that there is the option to choose between old and new style ;-( I know that in Debian very few people use Cinnamon yet, but this problem is also present in other Linux distributions that offer Cinnamon. This missing option therefore certainly affects more people than would appear in the first degree of analysis ... Don't seems very few people use it looking popcon, but I don't know a method to propose a survey to debian cinnamon users about some things (such as customizations) while on others such as language selection via gui in a simple/fast way I know it's missing but I don't have the time to do it - The choice of the GPU for laptop between integrated or discrete, at the launch of the programs, such as Gnome or Mate proposes it is absent from Debian 11 + Cinnamon 4.8.6-2. I understand you, it is difficult to be in the oven and in the mill when you are working alone... From reading you, you seem to me to be an independent maintainer, not a developer of Cinnamon ?? I not a DM with upload right now, I started procedure only after Norbert left cinnamon for kde (however, he was kind to upload for months until now), I contributed to cinnamon packages for 7 years through git and some testing, I'm not alone there is also a new one, joshua who has started contributing in the last year but at least a DD for upload and someone else to help would be useful. Maybe you could ask the LMDE team at Cinnamon & Linux Mint to give you some help ? When I wrote to the Cinnamon development team about the 2nd issue (old style / new style), as a Debian user they tell us to contact you ;-( I already give a small upstream contribution but even for that I don't have enough time, we collaborate or forward bugs upstream only when confirmed and not specific to the distribution (but of the software itself) We ended up wondering if it is not better to use Mate, XFCE or another desktop so as not to have any more problems on Debian... Thank you for everything and have a good end of the weekend. OpenPGP_signature Description: OpenPGP digital signature
Bug#1000761: msmtp: [INTL:pt] Updated Portuguese translation - debconf messages
Package: msmtp Version: 1.8.16-1 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for msmtp's debconf messages Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro - msmtp_1.8.16-1_pt.po.gz Description: application/gzip
Bug#1000760: ITP: liblinux-systemd-perl -- Perl module with bindings for systemd APIs
Package: wnpp Owner: Damyan Ivanov Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: liblinux-systemd-perl Version : 1.201600 Upstream Author : Ioan Rogers * URL : https://metacpan.org/release/Linux-Systemd * License : LGPL-2.1 Programming Lang: Perl Description : Perl module with bindings for systemd APIs Linux::Systemd makes several systemd APIs available to Perl code: * sd_notify(3) for startup and status notifications * write to and read from the journal The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1000759: ITP: sedparse -- GNU sed's parser translated from C to Python
Package: wnpp Severity: wishlist Owner: Marcos Talau X-Debbugs-Cc: debian-de...@lists.debian.org, mar...@talau.info * Package name: sedparse Version : 0.1.2 Upstream Author : Aurelio Jargas * URL : https://github.com/aureliojargas/sedparse * License : GPL-3+ Programming Lang: Python Description : GNU sed's parser translated from C to Python A translation from C to Python of GNU sed's parser for sed scripts. . After running sedparse in your sed script, the complete list of all the found sed commands and their arguments will be available in different formats: - List of objects (translated C structs). - List of dictionaries. - JSON. . This package provides an executable program and a Python3 library. signature.asc Description: PGP signature
Bug#997851: The doas package should be called opendoas
On 2021-11-28 10:08 a.m., Scupake wrote: > I like the idea of giving slicer69/doas a diffrent name, I still haven't > decided on a name yet so I'll work on renaming this package to "opendoas". > > Thanks a lot and sorry for the late reply. > Thanks for the update and for changing this package's name. Please let me know when you settle on a name for the slicer69/doas version of doas? - Jesse
Bug#995769: dbab: v1.5.7 package fail to upgrade from bullseye (1.5.01-1)
To Boyuan, or any mentors reading this issue. I've been trying to fix it myself, but all my previous attempts failed, because I don't understand what breaks and why, from the output of the package upgrade log. I've sent a help request to debian-mentors a few days ago, but nobody answers yet. My package is now marked for autoremoval from testing, with a wrong reason, and I don't know how to stop my package being autoremed from testing, and I got no answers/help on that either. Since I don't know how to fix it myself, and all my previous attempts failed, if nobody helps me by next weekend, I'll do the only thing that I know -- to change the severity of this bug to minor, because there is a simple solution to it as explained below. This will solve everything and win me the time it takes for me to do further investigation/testing. Really hope it won't be the case. Somebody help please. Thanks On Thu, Oct 7, 2021 at 9:31 PM Tong Sun wrote: > > On Tue, Oct 5, 2021 at 7:27 AM Boyuan Yang wrote: > > > Package dbab/1.5.7-1 has broken maintscript and cannot be properly upgraded > > from dbab/1.5.01-1 to dbab/1.5.7-1: > > Thanks for reporting. I'll try to fix it ASAP. > > In the meantime, for anyone who doesn't want to wait for the fix to be > published -- > do not do an upgrade -- remove the package completely, then do a fresh > install. > > thx
Bug#1000722: [Pkg-javascript-devel] Bug#1000722: Bug#1000722: Bug#1000722: Please ship TypeScript definitions
Quoting Julien Puydt (2021-11-28 17:01:56) > Le dimanche 28 novembre 2021 à 15:38 +0100, Yadd a écrit : > > > > please try with node-lodash-packages 4.17.21+dfsg+~cs8.31.198.20210220- > > 2 > > from experimental. > > I don't see it yet: > apt-cache show node-lodash-packages |grep Version > Version: 4.17.21+dfsg+~cs8.31.196.20210220-2 Not sure, but seems the above command is unreliable, and this one works: apt-cache search node-types-lodash.escape - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1000700: Debian 11 - Cinnamon 4.8.6-2 dont work correctly
Hello and thank you for your message, - The desktop display bug is the most annoying, if you could fix it that would be great... I'm using a stable Debian, I'm afraid that if I upgrade Cinnamon with SID it created an unstable system for me. - Having a small tool that allows you to choose between old style and new style would be so much more practical, in addition this tool exists in Linux Mint ... New users of Cinnamon under Debian or other OS (non Mint) do not even know that there is the option to choose between old and new style ;-( I know that in Debian very few people use Cinnamon yet, but this problem is also present in other Linux distributions that offer Cinnamon. This missing option therefore certainly affects more people than would appear in the first degree of analysis ... - The choice of the GPU for laptop between integrated or discrete, at the launch of the programs, such as Gnome or Mate proposes it is absent from Debian 11 + Cinnamon 4.8.6-2. I understand you, it is difficult to be in the oven and in the mill when you are working alone... From reading you, you seem to me to be an independent maintainer, not a developer of Cinnamon ?? Maybe you could ask the LMDE team at Cinnamon & Linux Mint to give you some help ? When I wrote to the Cinnamon development team about the 2nd issue (old style / new style), as a Debian user they tell us to contact you ;-( We ended up wondering if it is not better to use Mate, XFCE or another desktop so as not to have any more problems on Debian... Thank you for everything and have a good end of the weekend.
Bug#1000722: [Pkg-javascript-devel] Bug#1000722: Bug#1000722: Please ship TypeScript definitions
Le dimanche 28 novembre 2021 à 15:38 +0100, Yadd a écrit : > > please try with node-lodash-packages 4.17.21+dfsg+~cs8.31.198.20210220- > 2 > from experimental. I don't see it yet: apt-cache show node-lodash-packages |grep Version Version: 4.17.21+dfsg+~cs8.31.196.20210220-2 but I'll give it a try when I see it. For the sake of completeness: that will be useful for the rendermime package of jupyterlab (but even then I'll have to clear the apputils and codemirror packages). Thanks, J.Puydt
Bug#996640: powertop FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]
Control: tags -1 + fixed-upstream Am 16.10.2021 um 17:44 schrieb Helmut Grohne: > Source: powertop > Version: 2.13-2 > Severity: serious > Tags: ftbfs > > powertop fails to build from source in unstable, because ncurses added > format string annotations. A non-parallel build now ends as follows: > > | g++ -std=c++11 -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/share/locale\" > -I/usr/include/libnl3 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 > -I/usr/include/x86_64-linux-gnu -pthread -Wdate-time -D_FORTIFY_SOURCE=2 > -Wall -Wformat -Wshadow -fno-omit-frame-pointer -fstack-protector > -I/usr/include/libnl3 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 > -I/usr/include/x86_64-linux-gnu -pthread -g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -c -o powertop-display.o `test -f 'display.cpp' || > echo './'`display.cpp > | display.cpp: In function ‘void show_tab(unsigned int)’: > | display.cpp:128:26: error: format not a string literal and no format > arguments [-Werror=format-security] > | 128 | mvwprintw(bottom_line, 0,0, c); > | | ~^ > | cc1plus: some warnings being treated as errors > | make[4]: *** [Makefile:1107: powertop-display.o] Error 1 > | make[4]: Leaving directory '/<>/src' > | make[3]: *** [Makefile:657: all] Error 2 > | make[3]: Leaving directory '/<>/src' > | make[2]: *** [Makefile:461: all-recursive] Error 1 > | make[2]: Leaving directory '/<>' > | make[1]: *** [Makefile:391: all] Error 2 > | make[1]: Leaving directory '/<>' > | dh_auto_build: error: make -j1 returned exit code 2 > | make: *** [debian/rules:9: binary] Error 25 > | dpkg-buildpackage: error: debian/rules binary subprocess returned exit > status 2 The upstream git repository contains a fix for that problem: https://github.com/fenrus75/powertop/commit/9ef1559a1582f23d599c149601c3a8e06809296c It looks correct to me, but I have not tested it. Cheers, Sven
Bug#1000511: bullseye-pu: package debian-edu-config/2.11.56+deb11u2
On Wed, Nov 24, 2021 at 01:29:50PM +0100, Wolfgang Schweer wrote: > The package will be uploaded soonish by Holger Levsen. I've done this now. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The greatest danger in times of turbulence is not the turbulence; it is to act with yesterdays logic. (Peter Drucker) signature.asc Description: PGP signature
Bug#1000757: sssd-ldap: Backport Fix from Bug 991274 to Bullseye
Package: sssd-ldap Version: 2.4.1-2 Severity: important Dear Maintainer, I have came accross the same issue as described in Debian Bug #991274 (1). I have found a patch there and also a request to backport the patch into bullseye because currently sssd isn't working in bullseye. The original report was closed but for me I have not found a working package in bullseye. I was able to fix it for myself by applying the patch found in (2). Would it be possible to either apply this patch for the next bullseye update or maybe provide a backport of a newer version for bullseye? thanks Philipp (1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991274 (2) https://github.com/SSSD/sssd/pull/5743 -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads) 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) LSM: AppArmor: enabled Versions of packages sssd-ldap depends on: ii libc6 2.31-13+deb11u2 ii libsss-idmap0 2.4.1-2 ii libtalloc2 2.3.1-2+b1 ii libtevent0 0.10.2-1 ii sssd-common 2.4.1-2 ii sssd-krb5-common 2.4.1-2 Versions of packages sssd-ldap recommends: ii ldap-utils 2.4.57+dfsg-3 Versions of packages sssd-ldap suggests: pn libsasl2-modules-ldap -- no debconf information
Bug#1000756: freedv: FTBFS: varicode.h: No such file or directory
Source: freedv Version: 1.4.3~1gdc71a1c-1 Severity: serious Tags: ftbfs sid bookworm Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org | cd "/<>/Build/src" && /usr/bin/c++ -DDEB_VERSION="\"1.4.3~1gdc71a1c-1+b2\"" -DHAVE_LINUX_HIDRAW_H -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -I"/<>/src" -I"/<>/Build/src" -I"/<>/Build" -isystem /usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 -isystem /usr/include/wx-3.0 -isystem /usr/include/codec2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -pthread -g -MD -MT src/CMakeFiles/freedv.dir/dlg_ptt.cpp.o -MF CMakeFiles/freedv.dir/dlg_ptt.cpp.o.d -o CMakeFiles/freedv.dir/dlg_ptt.cpp.o -c "/<>/src/dlg_ptt.cpp" | In file included from /<>/src/dlg_ptt.h:25, | from /<>/src/dlg_ptt.cpp:22: | /<>/src/fdmdv2_main.h:101:10: fatal error: varicode.h: No such file or directory | 101 | #include "varicode.h" | | ^~~~ | compilation terminated. | make[3]: *** [src/CMakeFiles/freedv.dir/build.make:121: src/CMakeFiles/freedv.dir/dlg_ptt.cpp.o] Error 1 | make[3]: *** Waiting for unfinished jobs | In file included from /<>/src/dlg_filter.h:25, | from /<>/src/dlg_filter.cpp:21: | /<>/src/fdmdv2_main.h:101:10: fatal error: varicode.h: No such file or directory | 101 | #include "varicode.h" | | ^~~~ | In file included from /<>/src/dlg_options.h:25, | from /<>/src/dlg_options.cpp:22: | /<>/src/fdmdv2_main.h:101:10: fatal error: varicode.h: No such file or directory | 101 | #include "varicode.h" | | ^~~~ | compilation terminated. | compilation terminated. | make[3]: *** [src/CMakeFiles/freedv.dir/build.make:93: src/CMakeFiles/freedv.dir/dlg_filter.cpp.o] Error 1 | make[3]: *** [src/CMakeFiles/freedv.dir/build.make:107: src/CMakeFiles/freedv.dir/dlg_options.cpp.o] Error 1 | In file included from /<>/src/dlg_audiooptions.cpp:22: | /<>/src/fdmdv2_main.h:101:10: fatal error: varicode.h: No such file or directory | 101 | #include "varicode.h" | | ^~~~ | compilation terminated. See https://buildd.debian.org/status/fetch.php?pkg=freedv=amd64=1.4.3%7E1gdc71a1c-1%2Bb2=1638113993=0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#998853: obs-frontend-api.h: fatal error: {obs,util/darray}.h: No such file or directory
Em sáb., 27 de nov. de 2021 às 19:28, Sebastian Ramacher escreveu: > > Control: reassign -1 obs-move-transition 2.5.1-2 > > On 2021-11-27 23:12:58 +0100, Sebastian Ramacher wrote: > > On 2021-11-27 17:17:56 -0300, Eriberto wrote: > > > Em seg., 22 de nov. de 2021 às 20:02, Sebastian Ramacher > > > escreveu: > > > > > > > > Control: tags -1 moreinfo > > > > > > > > On 2021-11-08 17:23:01 -0300, Joao Eriberto Mota Filho wrote: > > > > > Package: libobs-dev > > > > > Version: 26.1.2+dfsg1-2 > > > > > Severity: important > > > > > Tags: patch > > > > > Control: affects -1 obs-move-transition > > > > > > > > > > Dear maintainer, > > > > > > > > > > In last weekend obs-move-transition[1] arrived to Debian. > > > > > obs-move-transition > > > > > is the most rated plugin for obs-studio. > > > > > > > > > > [1] https://tracker.debian.org/pkg/obs-move-transition > > > > > > > > > > obs-move-transition depends of the libobs-dev. When packaging this > > > > > plugin, I > > > > > got the following errors: > > > > > > > > > > In file included from > > > > > /PKGS/obs-move-transition-2.5.1/move-source-filter.c:2: > > > > > /usr/include/obs/obs-frontend-api.h:3:10: fatal error: obs.h: No > > > > > such file or directory > > > > > 3 | #include > > > > >| ^~~ > > > > > > > > > > In file included from > > > > > /PKGS/obs-move-transition-2.5.1/move-transition.c:3: > > > > > /usr/include/obs/obs-frontend-api.h:4:10: fatal error: > > > > > util/darray.h: No such file or directory > > > > > 4 | #include > > > > >| ^~~ > > > > > > > > > > To allow the plugin to build correctly, I created a 'fixed copy' of > > > > > the > > > > > /usr/include/obs/obs-frontend-api.h inside of > > > > > obs-move-transition-2.5.1. > > > > > > > > > > On Debian, the libobs-dev put the headers in /usr/include/obs/ but > > > > > the current > > > > > /usr/include/obs/obs-frontend-api.h expects to find for these files in > > > > > /usr/include/. However, when building obs-studio, the source code > > > > > searches for > > > > > the headers also in /usr/include/. Consequently, making a patch for > > > > > obs-frontend-api.h to search for headers in /usr/include/obs/ will > > > > > generate a > > > > > FTBFS. IMO, the right way is changing the obs-frontend-api.h after the > > > > > obs-studio build process. The attached patch will fix this issue. I > > > > > also sent > > > > > an MR to Salsa [2] to make to make easier the fix. > > > > > > > > In the cmake config installed by libobs-dev, the include dir is > > > > specified as /usr/include/obs. Why is obs-move-transition ignoring this > > > > bit? > > > > > > Hi Sebastian, > > > > > > The /usr/include/obs/obs-frontend-api.h is part of the obs-studio, not > > > obs-move-transition. Thus, the obs-studio package has an internal file > > > (obs-frontend-api.h) pointing to a wrong path. The problem is not in > > > obs-move-transition. > > > > > > In other words, obs-move-transition is not ignoring the cmake config > > > installed by libobs-dev. Let me know how to help you. I think my MR #5 > > > will solve this issue. > > > > Let me reprhase that: the cmake config of obs-studio tells users to set > > -I/usr/include/obs which makes #include and #include > > work. Why is obs-move-transition not picking this up? > > I just checked obs-move-transition's CMakeLists.txt. It's missing the > equivalent of a find_package(libobs REQUIRED) and then setting up the > include directories. This is a bug in obs-move-transition. > Fixed. Thanks for your help. I also noticed that upstream removed the call for easings.h for the current version. Consequently, I will close this bug and the bug #998855. Thanks again. Cheers, Eriberto
Bug#997194: mtr: FTBFS: ../ui/curses.c:435:17: error: format not a string literal and no format arguments [-Werror=format-security]
Control: tags -1 + fixed-upstream On 2021-10-24 05:56 -0700, Robert Woodcock wrote: > On 10/24/21 4:36 AM, Rogier Wolff wrote: >> >> I think this is perfectly legal C code and your compiler doesn't like >> it. It doesn't just warn, but gives an error. >> >> Roger. > Rogier, that is a 100% true statement, but Debian (and most other > distributions) have started using the -Werror=format-security build flag for > everything everywhere because leaving all of these calls as-is means, in > certain cases, leaving vulnerabilities in. Sure, you can prove that mtr's > code introduces no such vulnerabilities because none of the format specs are > user-supplied, but it's probably not reasonable to expect that that would be > a one-time effort, whereas changing the code would be. In the meantime upstream has accepted a pull request (not tested by me): https://github.com/traviscross/mtr/commit/aeb493e08eabcb4e6178bda0bb84e9cd01c9f213 Cheers, Sven
Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages
Rustam wrote on 12 Oct 2021: Hi Guillem, Any news on the proposed patch? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664#49 Can it be merged already? ;) Ubuntu packages are already using zstd compression. So tools like Mainline don't work on Debian any more, see e.g. https://github.com/bkw777/mainline/issues/121 More than that: AFAIU Ubuntu has in fact switched its default compressor to zstd [1], so Debian's tools haven't been able to understand Ubuntu's freshly generated packages from 2021-06-14 on. I have applied [2] Bálint's commit to *current* dpkg from git: * there was a trivial merge conflict in man/deb.pod, which is easily fixed [3] * in my dpkg git repo and zstd branch I have changed the patch author (including the merge conflict fix) back from me to Bálint [3], which might not be the right/clean way to do things, but that's a minor thing I can fix if Guillem would want that * dpkg-buildpackage built the patched package fine * I only did a smoketest with the resulting dpkg : `dpkg -x sbsigntool_0.9.4-2ubuntu1_amd64.deb foodir` [4] which successfully unpacked Ubuntu's zstd compressed sbsigntool package into the foodir directory So I am reporting that Bálint's patch [4] applies cleanly (with a trivially to solve merge conflict (see above)) and works (again see above for the minimal testing I did), has been in production in Ubuntu since 2021-04-14 and zstd is beeng used as default compressor in Ubtuntu since 2021-06-14. Of course I would welcome it very much if Debian's tools would be compatible and allow to work with Ubtuntu's packages. Concrete point in case: it would have made my life easier figuring out Ubuntu's mechanism to sign user-generated modules [5]. Thanks a lot to all involved! For Guillem's work on dpkg, Bálint for the patch and all others for their contributions here and in Ubuntu!!! Greets, *t [1] http://changelogs.ubuntu.com/changelogs/pool/main/d/dpkg/dpkg_1.20.9ubuntu2/changelog [2] https://salsa.debian.org/tpo/dpkg/-/tree/zstd [3] https://salsa.debian.org/tpo/dpkg/-/commit/e7cb231bc289d356f563c1e2c761d94c85aa7055 [4] https://packages.ubuntu.com/impish/amd64/sbsigntool/download [5] https://salsa.debian.org/rbalint/dpkg/-/commit/eb38de93eeb9524a54e80525c480df249828e84f [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939392
Bug#1000700: Debian 11 - Cinnamon 4.8.6-2 dont work correctly
pham...@bluewin.ch ha scritto: Bug Description: After clean install the desktop is displayed normally (look the print screen "After install" in attachement), but after a logout/login or reboot the desktop dont displayed normally the folders on the desk (look the print screen "After reboot" in attachement). The backrests are no longer in their original place and the height at which they should be is not respected either. At the bottom right in the taskbar, we also see 2 x the blueman applet. Sometimes it is present 4 times ?!? Sadly, this version 4.8.6-2 of Cinnamon was not sufficiently debugged before going into production ;-( The first problem is the most annoying, please bring a fix. The old style of desktop arrangement as you see in the screenshots is not provided by default. You have to bother to configure it manually ;-( You would be very kind if you could provide us with a little tool to choose the style of office you want to use (old or new) so that you don't have to break your head to make this adjustment... Thank you by advance & regards. Thanks for you report, bug description "dont work correctly" don't seems good for minor bugs and request change of default settings (more a whishlist) The old style desktop and other graphic options are don't forced to a specific choice but near all default, I don't know if is good force many default option in debian, too few users report something about it, I think most users set up as they want in few minutes just after install. About desktop icon is related to nemo and you can select also here some option about size, order ecc... and from a fast test on my Sid (with cinnamon and nemo 5.0 they works) About duplicate tray icons I don't see it on my testing environment, I'll try to check on 5.2 testing in clean install. About the testing it was not so much but unfortunately I have too little time, the basic packaging, the control with the upstream, some basic tests of build, install, upgrade, use of everything require many hours and often I can only do those in the span of a some weekends and make more relevant fixes; while for customizations in addition I don't know if I would do well to force the defaults without displeasing more users, I also don't have enough time to test everything in detail each new version. There is a new maintainer and I hope it will help me to do more testing as well as the packaging, often testing and debugging takes much longer than the packaging itself, however larger projects like this DE would require a larger team for better results (or at least maintainer/s with more time) It would be nice for users that you integrate the choice of graphics card to use on a laptop (multi-GPU / Optimus, integrated or discrete card) when launching applications as proposed by Gnome. Was added in cinnamon 4.6 on the menu (desktop icon is managed by nemo instead), I see it in my Sid testing install (with 5.0), I don't have a bullseye desktop for a fast check now on it. OpenPGP_signature Description: OpenPGP digital signature
Bug#1000403: linux-image-5.15.0-1-amd64: Bluetooth no longer works with linux 5.15 on an Intel AX201 laptop
Dear Maintainer, On my Debian sid laptop, which has an AX201 chipset, I also confirmed the same bug as reported in this thread. However, today Linux-image-5.15.0-2-amd64 came to sid. Then I installed this package right away, and I confirmed to resolve this bug. The AX201 Bluetooth on my laptop appeared to work entirely. Thank you for releasing the latest stable version of the kernel. -- Takahide Nojima
Bug#1000755: stellarium: Dialog boxes cause segfault crash under Wayland
Package: stellarium Version: 0.20.4-3 Severity: important X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, When using Stellarium under Wayland, certain file picker dialogs cause Stellarium to segfault. The bug is perhaps in Qt, but since I am unable to reproduce it with any other Qt program (I tried several), I am filing a bug for Stellarium since that is where I can observe it. Steps to reproduce: 1: Launch Stellarium under Wayland (QT_QPA_PLATFORM=wayland). 2: Observe that much of the program works just fine. 3: Open a file picker dialog, such as under View -> Landscape -> Add/Remove -> Install a new landscape from a zip archive. 4: Observe segfault. The same steps work fine under X11. A backtrace follows. -- Backtrace -- #0 QDialogButtonBoxPrivate::layoutButtons (this=0x64867cb0) at widgets/qdialogbuttonbox.cpp:270 #1 0x77b1bfd4 in QDialogButtonBoxPrivate::resetLayout (this=) at widgets/qdialogbuttonbox.cpp:218 #2 0x77ba0bb2 in Ui_QFileDialog::setupUi (this=0x63fb4290, QFileDialog=0x7fffcd10) at .uic/ui_qfiledialog.h:238 #3 0x77b9afaf in QFileDialogPrivate::createWidgets (this=0x64047b40) at dialogs/qfiledialog.cpp:3110 #4 0x77b9c770 in QFileDialogPrivate::init (this=0x64047b40, args=...) at dialogs/qfiledialog.cpp:3040 #5 0x77b9d41d in QFileDialog::QFileDialog (this=0x7fffcd10, args=...) at dialogs/qfiledialog.cpp:390 #6 0x77b9d4e2 in QFileDialog::getOpenFileUrl (parent=parent@entry=0x0, caption=..., dir=..., filter=..., selectedFilter=selectedFilter@entry=0x0, options=..., supportedSchemes=...) at dialogs/qfiledialog.cpp:2259 #7 0x77b9d7b2 in QFileDialog::getOpenFileName (parent=parent@entry=0x0, caption=..., dir=..., filter=..., selectedFilter=selectedFilter@entry=0x0, options=...) at dialogs/qfiledialog.cpp:2210 #8 0x55893c4e in AddRemoveLandscapesDialog::browseForArchiveClicked (this=0x6406c810) at ./src/gui/AddRemoveLandscapesDialog.cpp:118 #9 0x76907df8 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x77a7 in QAbstractButton::clicked (this=this@entry=0x6385e270, _t1=) at .moc/moc_qabstractbutton.cpp:308 #11 0x77a7249a in QAbstractButtonPrivate::emitClicked (this=0x62bd6260) at widgets/qabstractbutton.cpp:415 #12 0x77a74060 in QAbstractButtonPrivate::click (this=0x62bd6260) at widgets/qabstractbutton.cpp:408 #13 0x77a74283 in QAbstractButton::mouseReleaseEvent (this=0x6385e270, e=0x7fffd520) at widgets/qabstractbutton.cpp:1044 #14 0x779c131e in QWidget::event (this=0x6385e270, event=0x7fffd520) at kernel/qwidget.cpp:9019 #15 0x7797f6af in QApplicationPrivate::notify_helper (this=this@entry=0x566df060, receiver=receiver@entry=0x6385e270, e=e@entry=0x7fffd520) at kernel/qapplication.cpp:3632 #16 0x779871b4 in QApplication::notify (this=, receiver=0x6385e270, e=0x7fffd520) at kernel/qapplication.cpp:3076 #17 0x768d175a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x77985cc3 in QApplicationPrivate::sendMouseEvent (receiver=0x6385e270, event=event@entry=0x7fffd520, alienWidget=alienWidget@entry=0x6385e270, nativeWidget=0x63456d60, buttonDown=buttonDown@entry=0x7fffd4b8, lastMouseReceiver=..., spontaneous=true, onlyDispatchEnterLeave=false) at kernel/qapplication.cpp:2614 #19 0x77ca6256 in QGraphicsProxyWidgetPrivate::sendWidgetMouseEvent (this=0x63faaa10, event=0x7fffd8a0) at graphicsview/qgraphicsproxywidget.cpp:309 #20 0x77c90188 in QGraphicsItem::sceneEvent (this=0x647fc3e0, event=0x7fffd8a0) at graphicsview/qgraphicsitem.cpp:6928 #21 0x77cb2d71 in QGraphicsScenePrivate::sendMouseEvent (this=this@entry=0x56ac5290, mouseEvent=mouseEvent@entry=0x7fffd8a0) at graphicsview/qgraphicsscene.cpp:1335 #22 0x77cb88fc in QGraphicsScene::mouseReleaseEvent (this=, mouseEvent=0x7fffd8a0) at graphicsview/qgraphicsscene.cpp:4123 #23 0x77cc54f1 in QGraphicsScene::event (this=0x56892c60, event=0x7fffd8a0) at graphicsview/qgraphicsscene.cpp:3436 #24 0x7797f6af in QApplicationPrivate::notify_helper (this=, receiver=0x56892c60, e=0x7fffd8a0) at kernel/qapplication.cpp:3632 #25 0x768d175a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #26 0x77ce2cc0 in QGraphicsView::mouseReleaseEvent (this=0x7fffe5d0, event=0x7fffde50) at graphicsview/qgraphicsview.cpp:3430 #27 0x779c131e in QWidget::event (this=0x7fffe5d0, event=0x7fffde50) at kernel/qwidget.cpp:9019 #28 0x77a6d74e in QFrame::event (this=0x7fffe5d0, e=0x7fffde50) at widgets/qframe.cpp:550 #29 0x768d14c2 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from
Bug#1000722: [Pkg-javascript-devel] Bug#1000722: Bug#1000722: Please ship TypeScript definitions
Le 28/11/2021 à 14:44, Yadd a écrit : > Le 27/11/2021 à 22:50, Julien Puydt a écrit : >> Package: node-lodash >> Version: 4.17.21+dfsg+~cs8.31.196.20210220-2 >> Severity: minor >> >> Please ship TypeScript definitions, in particular for lodash.escape, as >> I'm finding I need them on the way to jupyterlab. > > Was really a hard work Hi Julien, please try with node-lodash-packages 4.17.21+dfsg+~cs8.31.198.20210220-2 from experimental. Cheers, Yadd
Bug#997504: terminator: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
Control: reassign -1 terminator 2.1.0-2
Hi Timo,
* Timo Röhling [2021-11-05 14:51]:
On Sat, 23 Oct 2021 22:41:30 +0200 Lucas Nussbaum wrote:
collecting ... Trace/breakpoint trap
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=133: cd
/<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest
--doctest-modules
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9
returned exit code 13
I investigated this failure a bit and found that there seems to be a
segfault on instantiating terminal.Terminal(), which looks like it
is caused by the bindings in python3-gi.
I assume so because I found that the error also occurs with older
terminator versions in unstable, but not with the latest terminator
version in a bullseye chroot.
For reference, the error in unstable can be reproduced in an interactive
Python session (I ran "gdb /usr/bin/python3" to get a stacktrace):
>>> from terminatorlib import terminal
/build/terminator-2.1.0/terminatorlib/terminal.py:9: PyGIWarning: Pango was
imported without specifying a version first. Use gi.require_version('Pango',
'1.0') before import to ensure that the right version gets loaded.
from gi.repository import GLib, GObject, Pango, Gtk, Gdk, GdkPixbuf
/build/terminator-2.1.0/terminatorlib/terminal.py:9: PyGIWarning: Gtk was
imported without specifying a version first. Use gi.require_version('Gtk',
'3.0') before import to ensure that the right version gets loaded.
from gi.repository import GLib, GObject, Pango, Gtk, Gdk, GdkPixbuf
>>> t = terminal.Terminal()
(.:106187): Gtk-CRITICAL **: 13:00:40.235:
_gtk_style_provider_private_get_settings: assertion
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
(.:106187): Gtk-CRITICAL **: 13:00:40.235:
_gtk_style_provider_private_get_settings: assertion
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
(.:106187): Gtk-CRITICAL **: 13:00:40.235:
_gtk_style_provider_private_get_settings: assertion
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
Program received signal SIGSEGV, Segmentation fault.
0x75a98a80 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
(gdb) bt
#0 0x75a98a80 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
[..]
You can get a meaningful backtrace by enabling debug symbols, either by
installing the dbgsym packages or by:
export DEBUGINFOD_URLS="https://debuginfod.debian.net;
With this I get:
#0 _gtk_settings_get_screen (settings=0x0) at
../../../../gtk/gtksettings.c:3360
#1 0x75a2de84 in gtk_css_value_icon_theme_compute (icon_theme=,
property_id=, provider=, style=,
parent_style=)
at ../../../../gtk/gtkcssiconthemevalue.c:84
#2 0x75a4f658 in gtk_css_static_style_compute_value (style=0xbc4090, provider=0x0,
parent_style=, id=3, specified=0x760d1e20 ,
section=0x0) at ../../../../gtk/gtkcssstaticstyle.c:237
#3 0x75a39dca in _gtk_css_lookup_resolve
(lookup=lookup@entry=0xbc3100, provider=provider@entry=0x0,
style=style@entry=0xbc4090, parent_style=parent_style@entry=0x0) at
../../../../gtk/gtkcsslookup.c:122
#4 0x75a4f528 in gtk_css_static_style_new_compute (parent=0x0,
matcher=0x0, provider=0x0) at ../../../../gtk/gtkcssstaticstyle.c:195
#5 gtk_css_static_style_get_default () at
../../../../gtk/gtkcssstaticstyle.c:164
#6 0x75a3a712 in gtk_css_node_init (cssnode=0xbc0510) at
../../../../gtk/gtkcssnode.c:667
#7 0x7778aae3 in g_type_create_instance (type=) at
../../../gobject/gtype.c:1923
#8 0x77770cbd in g_object_new_internal (class=class@entry=0xbc3000,
params=params@entry=0x0, n_params=n_params@entry=0) at
../../../gobject/gobject.c:1939
#9 0x777721fd in g_object_new_with_properties (object_type=11724208,
n_properties=0, names=names@entry=0x0, values=values@entry=0x0) at
../../../gobject/gobject.c:2108
#10 0x77772bb1 in g_object_new (object_type=,
first_property_name=first_property_name@entry=0x0) at ../../../gobject/gobject.c:1779
#11 0x75a5800b in gtk_css_widget_node_new
(widget=widget@entry=0xbc1140) at ../../../../gtk/gtkcsswidgetnode.c:302
#12 0x75c41dd9 in gtk_widget_init (instance=0xbc1140, g_class=0xbc0800)
at ../../../../gtk/gtkwidget.c:4468
#13 0x7778aae3 in g_type_create_instance (type=) at
../../../gobject/gtype.c:1923
#14 0x77770cbd in g_object_new_internal (class=class@entry=0xbc0800,
params=params@entry=0x0, n_params=n_params@entry=0) at
../../../gobject/gobject.c:1939
#15 0x777721fd in g_object_new_with_properties (object_type=10410752,
n_properties=n_properties@entry=0, names=names@entry=0x0,
values=values@entry=0x0) at ../../../gobject/gobject.c:2108
#16 0x77900e17 in pygobject_object_new_with_properties (values=0x0,
names=0x0, n_properties=0, object_type=) at gi/gimodule.c:1019
#17 pygobject_constructv (self=self@entry=0x753eafc0,
n_properties=n_properties@entry=0, names=names@entry=0x0,
values=values@entry=0x0) at
Bug#1000754: RFS: lebiniou/3.63.4-1 -- user-friendly, powerful music visualization / VJing tool
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lebiniou": * Package name: lebiniou Version : 3.63.4-1 Upstream Author : Olivier Girondel * URL : https://biniou.net * License : GPL-2+ Section : graphics It builds this binary package: lebiniou - user-friendly, powerful music visualization / VJing tool The package appears to be lintian-clean. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lebiniou Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.63.4-1.dsc Changes since the last upload: * New upstream release 3.63.4. Regards, -- Olivier Girondel
Bug#997851: The doas package should be called opendoas
I like the idea of giving slicer69/doas a diffrent name, I still haven't decided on a name yet so I'll work on renaming this package to "opendoas". Thanks a lot and sorry for the late reply. -- Scupake :D 4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16 signature.asc Description: PGP signature
Bug#1000743: installation-reports: bootx64.efi didn't seem to get installed and no UEFI boot entry was created for Debian
On Sun, Nov 28, 2021 at 02:24:06PM +0100, Pascal Hambourg wrote: >Hello, > >Le 28/11/2021 à 12:28, Adam Baxter a écrit : >> >> Comments/Problems: >> Once the installer had finished and prompted me to reboot, the system came >> back up in Dell's hardware check mode and >> some investigation revealed there was no UEFI boot entry for Debian. > >Some UEFI firmwares are broken and do not handle EFI boot entries properly. I'm guessing this is similar to the firware bug we've seen before in https://bugs.debian.org/905319 , in fact. >> /boot/efi >> └── EFI >> ├── debian >> │ ├── BOOTX64.CSV >> │ ├── fbx64.efi >> │ ├── grub.cfg >> │ ├── grubx64.efi >> │ ├── mmx64.efi >> │ └── shimx64.efi > >At least GRUB itself was installed in the EFI partition. > >> Shouldn't there normally be EFI/boot/bootx64.efi? > >Not by default. It happens only if you choose to install a copy of the boot >loader in the removable device path. The option is available only in expert >install or after changing priority for questions to low. Agreed. We deliberately do *not* install there by default as this can cause other OSes not to boot. We try to be more accommodating than Windows etc. :-/ Adam: if you boot the installer again in rescue mode, there is an automated way to install to the removable media path, and that's probably the easiest way to do this. The system will remember that you need to do this in future and also install there on any further grub package updates. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Bug#1000700: Debian 11 - Cinnamon 4.8.6-2 dont work correctly
PS It would be nice for users that you integrate the choice of graphics card to use on a laptop (multi-GPU / Optimus, integrated or discrete card) when launching applications as proposed by Gnome. Regards.
Bug#998679: firefox-esr freezes shortly after start
I'm using firefox-esr from the Debian repo and Firefox nightly from Mozilla's website. I experience this issue only in Firefox ESR and stable from the Debian repos. All browsers are used under Wayland. I think that it might be an issue with the Debian build. On Mon, 22 Nov 2021 09:31:55 -0700 Daniel Blaschke wrote: > Package: firefox-esr > Followup-For: Bug #998679 > X-Debbugs-Cc: blasc...@hep.itp.tuwien.ac.at > > Dear Maintainer, > > for the past two days I've been testing firefox-esr 91.3.0 downloaded directly > from mozilla.org on debian 11 (bullseye) without any problems: no crashes > whatsoever. > gfx.x11-egl.force-disabled is set to its default "false" and mesa version on my > system is 20.3.5. > > I'm running on an intel broadwell gpu (HD Graphics 5500) using the older > xserver-xorg-video-intel driver and gnome-shell on xorg (not wayland). > In fact, wayland crashes randomly after standby on my system (unrelated to > firefox). > > Perhaps, the firefox crashes experienced by others is a bug in either newer > mesa 21.2 or the wayland display server of debian testing and firefox is merely > triggering that bug? > Do people affected by this bug experience it on both xorg and wayland or just > wayland? > > On Debian stable we're now 3 weeks overdue for a security update of firefox, > which too me seems rather important to address; I cannot reproduce the bug > reported here on bullseye. > > Cheers, > Daniel > > > -- Package-specific info: > > > -- Addons package information > > -- System Information: > Debian Release: 11.1 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads) > 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) > LSM: AppArmor: enabled > > Versions of packages firefox-esr depends on: > ii debianutils 4.11.2 > ii fontconfig 2.13.1-4.2 > ii libatk1.0-0 2.36.0-2 > ii libc6 2.31-13+deb11u2 > ii libcairo-gobject2 1.16.0-5 > ii libcairo2 1.16.0-5 > ii libdbus-1-3 1.12.20-2 > ii libdbus-glib-1-2 0.110-6 > ii libevent-2.1-7 2.1.12-stable-1 > ii libffi7 3.3-6
