Bug#1026199: release.debian.org: Is the toolchain list updated for bookworm
Dear Sam,
On 16-12-2022 02:40, Sam Hartman wrote:
I was looking at
https://release.debian.org/testing/essential-and-build-essential.txt
trying to figure out which packages I'm involved in are covered by the
toolchain freeze. I am wondering what's still pulling
libgssapi-krb5-2 and friends into build-essential. It used to be
pulled in via pam via libtirpc, but that should have gone away with
the pam upload of 1.4.0-13.
I'm wondering if that list hasn't been recently updated or if there's some
other dependency cycle pulling in krb5?
I just refreshed the list, it's still there. I used a script on udd,
essentially this:
essentials = {'build-essential'}
def add_sql_packages(con, essentials, query):
cur = con.cursor()
cur.execute(query)
items = cur.fetchall()
cur.close()
for item in items:
if item[0] is not None:
no_alt = re.sub(alternatives, "", item[0])
no_ver = re.sub(version, "", no_alt)
for x in no_ver.split(','):
essentials.add(re.sub(multiarch, "", x.strip()))
query = "SELECT DISTINCT package FROM packages WHERE release =
'bookworm' and essential = 'yes'"
add_sql_packages(con, essentials, query)
done = False
while not done:
ess_org = copy.copy(essentials)
query = """SELECT DISTINCT depends FROM packages WHERE release =
'bookworm' and
package in ('%s')""" % "','".join(essentials)
add_sql_packages(con, essentials, query)
if essentials == ess_org:
done = True
I haven't checked yet what pulled it in.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1026247: Acknowledgement (Spyder shows a popup message on start: "You have missing dependencies! Mandatory: qdarkstyle")
More info: Operating System: Debian 12 Bookworm GNU/Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.6 Kernel Version: 6.0.0-5-amd64 (64-bit) Graphics Platform: X11
Bug#1026247: Spyder shows a popup message on start: "You have missing dependencies! Mandatory: qdarkstyle"
Package: spyder Version: 5.3.3+dfsg-3 Every time I start Spyder the following popup shows up: You have missing dependencies! # Mandatory: qdarkstyle >=3.0.2;<3.1.0 : 3.1 (NOK) Please install them to avoid this message. Note: Spyder could work without some of these dependencies, however to have a smooth experience when using Spyder we strongly recommend you to install all the listed missing dependencies. Other than this message the Spyder IDE seems to functions without issues. Where do I get that qdarkstyle package? # aptitude search qdarkstyle i A python3-qdarkstyle Regards,
Bug#1026246: ITP: ruby-telesign -- TeleSign Ruby SDK
package: wnpp Severity: wishlist Owner: Vinay Keshava *Package Name : ruby-telesign Version : 2.2.3 Upstream Author : 2017 TeleSign Corp *URL :https://github.com/TeleSign/ruby_telesign *License : Expat Programming Lang : Ruby *Description : TeleSign Ruby SDK TeleSign Ruby SDK lets you easily integrate with our REST API . This gem is required for gitlab. - Vinay Keshava
Bug#1010740: ruby-bootsnap: FTBFS on ppc64el: test suite hangs
Hi, On Sun, 8 May 2022 20:59:08 -0300 Antonio Terceiro wrote: The ruby-bootsnap test suite hangs forever on ppc64el. This has been reported upstream at the link above, and happens on both the version in testing and the one in unstable. There have been several successful builds since this bug was reported. Should this bug be closed? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1026245: gm2-12-doc,gm2-13-doc: ships unversioned /usr/share/info/gm2.info.gz
Package: gm2-12-doc,gm2-13-doc Severity: serious Control: found -1 12.2.0-10 Control: found -1 13-20221214-1 Hi, there is a file conflict between gm2-12-doc and gm2-13-doc: Preparing to unpack .../gm2-13-doc_13-20221214-1_all.deb ... Unpacking gm2-13-doc (13-20221214-1) ... dpkg: error processing archive /var/cache/apt/archives/gm2-13-doc_13-20221214-1_all.deb (--unpack): trying to overwrite '/usr/share/info/gm2.info.gz', which is also in package gm2-12-doc 12.2.0-10 Errors were encountered while processing: /var/cache/apt/archives/gm2-13-doc_13-20221214-1_all.deb Please rename that to gm2-XX.info.gz and provide a symlink in gm2-doc (does not yet exist) like for e.g. gcc-doc. Do not forget versioned Breaks+Replaces in gm2-doc for taking over gm2.info.gz from these two packages. Andreas gm2-12-doc=12.2.0-10_gm2-13-doc=13-20221214-1.log.gz Description: application/gzip
Bug#1025176: libicu71 missing on SH4 port
On 12/16/22 20:43, Jeffrey Walton wrote: > On Fri, Dec 16, 2022 at 9:23 PM Rob Landley wrote: >> [...] >> How does one do an 'entirely from source' debootstrap, anyway? (If I wanted >> to >> reproduce your current sh4 build on my system, where would I start?) > > For SH-4 I use a Debian Chroot and follow > https://cryptopp.com/wiki/Debian_Chroot#SH-4 . > > Start with Debian Unstable/Sid. > > Then add the following packages: > > # apt install qemu qemu-user-static binfmt-support debootstrap > debian-archive-keyring debian-ports-archive-keyring > > And then setup the SH-4 guest: > > # qemu-debootstrap --arch=sh4 --keyring > /usr/share/keyrings/debian-ports-archive-keyring.gpg \ > --variant=buildd --exclude=debfoster unstable debian-sh4 > http://ftp.ports.debian.org/debian-ports $ sudo apt-get install debian-ports-archive-keyring ... $ sudo qemu-debootstrap --arch=sh4 --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd --exclude=debfoster unstable debian-sh4 http://ftp.ports.debian.org/debian-ports I: Running command: debootstrap --arch sh4 --foreign --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg --variant=buildd --exclude=debfoster unstable debian-sh4 http://ftp.ports.debian.org/debian-ports I: Retrieving InRelease I: Checking Release signature E: Release signed by unknown key (key id E852514F5DF312F6) The specified keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg may be incorrect or out of date. You can find the latest Debian release key at https://ftp-master.debian.org/keys.html Nope, doesn't work from devuan beowulf. Oh well. Thanks, off to other things... Rob
Bug#1025176: libicu71 missing on SH4 port
On Fri, Dec 16, 2022 at 9:23 PM Rob Landley wrote: > [...] > How does one do an 'entirely from source' debootstrap, anyway? (If I wanted to > reproduce your current sh4 build on my system, where would I start?) For SH-4 I use a Debian Chroot and follow https://cryptopp.com/wiki/Debian_Chroot#SH-4 . Start with Debian Unstable/Sid. Then add the following packages: # apt install qemu qemu-user-static binfmt-support debootstrap debian-archive-keyring debian-ports-archive-keyring And then setup the SH-4 guest: # qemu-debootstrap --arch=sh4 --keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg \ --variant=buildd --exclude=debfoster unstable debian-sh4 http://ftp.ports.debian.org/debian-ports Finally, enter the SH-4 guest with: # chroot debian-sh4 Jeff
Bug#1025176: libicu71 missing on SH4 port
On 12/16/22 13:02, John Paul Adrian Glaubitz wrote: > > >> On Dec 16, 2022, at 7:29 PM, John Paul Adrian Glaubitz >> wrote: >> >> >> >> >>> On Dec 16, 2022, at 7:18 PM, Jérémy Lal wrote: >>> >>> Source: icu >>> Followup-For: Bug #1025176 >>> X-Debbugs-Cc: debian-sup...@lists.debian.org >>> >>> Considering the needed porting work is only a few lines: >>> https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform >>> >>> sh4 porters might be able to help here. >> >> icu or python-greenlet? The former has been built on sh4: > > Looking at the rest of the bug report > > The reason why boost1.74 is not up to date is this bug: > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016904 I note you can run a debian root filesystem under qemu-system-sh4 with a large swap file on your media image. It's not great (the board only has 64 megs emulated ram so the swap file gets a bit hammered, although the host disk cache covers for it), but it works better than application emulation doing dodgy things with system calls? How does one do an 'entirely from source' debootstrap, anyway? (If I wanted to reproduce your current sh4 build on my system, where would I start?) Rob
Bug#1024322: transition: dpdk
Control: tags -1 -moreinfo On Wed, 23 Nov 2022 at 19:49, Sebastian Ramacher wrote: > > Control: tags -1 moreinfo > > On 2022-11-17 14:27:25 +, Luca Boccassi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org > > > > Hello Thomas and Release Team, > > > > As we did for Bullseye, we are proposing the following plan to allow > > Bookworm to ship with the latest LTS versions of DPDK and OVS. This > > will let us make use of the full LTS support windows for both projects, > > as we have done for the past few releases. > > > > Upload OVS built from git (with new sonames/package renames if > > necessary), new OVN, DPDK 22.11 in early-to-mid December to unstable, > > ideally before the 16th as we go on vacation after that, to finish the > > transition. > > > > Then, after OVS 3.1 releases in February, upload it unstable (no > > soname/transition required, as only bug fixes will go in at that > > point). The upstream release might happen before or after the > > 2023/02/12 soft freeze, and if it is after we will ask for an > > exception. > > > > Would this plan work for everyone? > > Sounds like that should work like last time. Please remove the moreinfo > tag once dpdk is ready for the upload to unstable. Hi, We are now ready. dpdk, openvswitch and ovn are ready in experimental. uhd and collectd in unstable will need a simple binary rebuild and are already compatible. Kind regards, Luca Boccassi
Bug#1026244: gnome-remote-desktop: No support for VNC
Package: gnome-remote-desktop X-Debbugs-Cc: m...@benthetechguy.net Version: 43.2-1 Severity: important Dear Maintainer, When I run grdctl, none of the VNC-related options are available. I see that the Debian packaging has chosen not to build it. Why is this? I need to use VNC for my job, and gnome-remote-desktop is the only solution I know of that supports Wayland well. At the very least, if adding VNC back to the package isn't an option, can it at least be removed from the package description? > This daemon enables GNOME to offer remote desktop sharing using VNC > with PipeWire. It's a bit misleading to say your package supports VNC when it doesn't. Thanks, - -- Ben Westover -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-asahi (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=C.UTF-8, LCCTYPE=C.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 gnome-remote-desktop depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii fuse33.12.0-1 ii init-system-helpers 1.65.2 ii libc62.36-6 ii libcairo21.16.0-7 ii libepoxy01.5.10-1 ii libfreerdp-server2-2 2.9.0+dfsg1-1 ii libfreerdp2-22.9.0+dfsg1-1 ii libfuse3-3 3.12.0-1 ii libglib2.0-0 2.74.2-1 ii libmutter-11-0 43.0-2 ii libnotify4 0.8.1-1 ii libpipewire-0.3-00.3.62-1 ii libsecret-1-00.20.5-3 ii libtss2-esys-3.0.2-0 3.2.0-4 ii libtss2-mu0 3.2.0-4 ii libtss2-rc0 3.2.0-4 ii libtss2-tctildr0 3.2.0-4 ii libwinpr2-2 2.9.0+dfsg1-1 ii libxkbcommon01.4.1-1 ii pipewire 0.3.62-1 ii wireplumber 0.4.12-1+b1 gnome-remote-desktop recommends no packages. gnome-remote-desktop suggests no packages. -- no debconf information OpenPGP_signature Description: PGP signature
Bug#1026243: fwupd: please remove old .gz cache files on upgrade (now using .xz)
Package: fwupd Version: 1.8.8-1 Severity: minor User: cruft...@packages.debian.org Usertags: cruft X-Debbugs-Cc: p...@debian.org Hi, Since a recent upgrade, fwupd has changed it's compression scheme. So please in a next upload include preinst/posting these two lines: rm -f /var/lib/fwupd/metadata/lvfs/metadata.xml.gz rm -f /var/lib/fwupd/metadata/lvfs/metadata.xml.gz.jcat to keep systems clean of old stale data. Greetings, tchet@brix ~ $ ls -l /var/lib/fwupd/metadata/lvfs/ total 1544 -rw-r--r-- 1 root root 758839 9 déc 01:59 metadata.xml.gz -rw-r--r-- 1 root root 2228 9 déc 01:59 metadata.xml.gz.jcat -rw-r--r-- 1 root root 807792 16 déc 17:14 metadata.xml.xz -rw-r--r-- 1 root root 2205 16 déc 17:14 metadata.xml.xz.jcat -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages fwupd depends on: ii adduser3.129 ii libarchive13 3.6.0-1 ii libc6 2.36-6 ii libcbor0.8 0.8.0-2+b1 ii libcurl3-gnutls7.86.0-2 ii libefiboot137-6 ii libflashrom1 1.2-5 ii libfwupd2 1.8.8-1 ii libgcab-1.0-0 1.5-1 ii libglib2.0-0 2.74.2-1 ii libgnutls303.7.8-4 ii libgudev-1.0-0 237-2 ii libgusb2 0.3.10-1 ii libjcat1 0.1.9-1 ii libjson-glib-1.0-0 1.6.6-1 ii liblzma5 5.2.9-0.0 ii libmbim-glib4 1.28.0-1 ii libmbim-proxy 1.28.0-1 ii libmm-glib01.20.0-1 ii libpolkit-gobject-1-0 122-1 ii libprotobuf-c1 1.4.1-1+b1 ii libqmi-glib5 1.32.0-1 ii libqmi-proxy 1.32.0-1 ii libsmbios-c2 2.4.3-1 ii libsqlite3-0 3.40.0-1 ii libsystemd0252.2-2 ii libtss2-esys-3.0.2-0 3.2.0-4 ii libxmlb2 0.3.8-1 ii shared-mime-info 2.2-1 Versions of packages fwupd recommends: pn bolt ii dbus 1.14.4-1 pn fwupd-signed ii jq 1.6-2.1 ii python33.10.6-1 pn secureboot-db ii udisks22.9.4-4 Versions of packages fwupd suggests: pn gir1.2-fwupd-2.0 -- Configuration Files: /etc/fwupd/redfish.conf [Errno 13] Permission non accordée: '/etc/fwupd/redfish.conf' -- no debconf information
Bug#1026242: ITP : node-seek-bzip -- Pure Javascript Node.Js module for random-access decoding bzip2 data
Package: wnppX-Debbugs-Cc:debian-de...@lists.debian.org Owner: Sandra Uwah X-Debbugs-Cc:sandrauwah...@gmail.com Severity: wishlist * Package name: node-seek-bzip Version : 2.0.0 Upstream Author : C. Scott Ananian * URL :https://github.com/cscott/seek-bzip#readme * License : Expat Programming Lang: Javascript Description : Pure-Javascript Node.Js module for random-access decoding bzip2 data
Bug#1026241: [python3-cryptography] new version breaks deluge
control: reassign -1 python3-openssl control: forcemerge 1026215 -1 On Fri, Dec 16, 2022 at 6:42 PM Lyndon Brown wrote: > > Package: python3-cryptography > Version: 38.0.4-1 > Severity: important > > Please be aware that the new version breaks deluge, see bug #1026240. the error is in pyopenssl, which im about to upgrade -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles
On Mon, Dec 12, 2022 at 05:41:46PM -0800, Noah Meyerhans wrote: > On 12/12/2022 6:44 AM, Sam Hartman wrote: > > >> From my quick read: Michael Biebl proposes dropping > > >> network-pre.target > > Ross> from cloud-init's After=, and replacing it with each of the > > Ross> config backends that cloud-init supports. This sounds pretty > > Ross> reasonable, but also like something that upstream should > > Ross> address first. > > > > Why wait for upstream? > > It's a bug affecting Debian users, our systemd maintainer has a solution > > that you (and I) think is reasonable. > > The symptom is quite serious. > > We often make changes before upstream in situations like that, > > especially when the alternative is: > > > > Ross> Should we consider adding "Conflicts: firewalld" to cloud-init > > Ross> before the freeze? That's not optimal of course, but it'd > > Ross> prevent a user from ending up in this situation for now. > > > > I'd much rather see Debian local changes than conflicts. > > We should simply move this discussion to an upstream pull request rather > than wait passively for their response. I agree that diverging from upstream > is preferable to unnecessary conflicts, but it shouldn't be done without > first consulting with upstream on our proposed solution. I played with the suggested solution and was unable to get it working: cloud-init.service doesn't have a /direct/ Before=network-pre.target to remove. The ordering is implicit in the combination of units. Probably, I think Michael knew that when he made the suggestion - but I had to play with it for a few hours first. :) At a high level the issue is: firewalld.service forces network-pre.target after sysinit.target, but cloud-init.service forces the other way around. In detail, using < to represent Before, the imposed orderings look like: - from firewalld: sysinit.target < dbus.service < firewalld.service < network-pre.target - from cloud-init: cloud-init-local.service < network-pre.target < systemd-networkd-wait-online.service < cloud-init.service < sysinit.target There's a few approaches to resolving this. As far as I can tell, the only immediately viable one (at the bottom) requires users to manually fix this and accept some trade-offs. Anyone have any better ideas? Modify firewalld to run before sysinit.target - This would let cloud-init and firewalld agree to do network-pre.target before sysinit.target. This is probably not possible since firewalld requires dbus, which starts after sysinit.target. There's a thread at [1] about why moving firewalld to be an early boot service is difficult. Modify cloud-init to run after sysinit.target - This would let cloud-init and firewalld agree to do network-pre.target after sysinit.target. This might not be advisable (see comments in [1] about running network management services in late boot), but it looks like this is how RHEL does it [2]. >From [3], I think cloud-init.service added Before=basic.target (which eventually became Before=sysinit.target) to ensure cloud-init configured block device mounts were ready early enough in boot process. The network needs to be online for this, since some block device config can come from network sources. So changing this in the Debian package seems risky to me. Locally override firewalld.service's order -- If you need to use both together, create an override unit that removes Before=network-pre.target. This eliminates the cycle by allowing cloud-init's order to win. But it the network will be up without firewalld for a period. Unfortunately, dependencies can't be removed in a drop-in - so I think you need to copy the unit to /etc/systemd/system and modify it. Ross [1] - https://lists.freedesktop.org/archives/systemd-devel/2022-March/047538.html [2] - https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L4-L6 [3] - https://github.com/canonical/cloud-init/commit/80f5ec4be0f781b26eca51d90d51abfab396b3f6
Bug#1026241: [python3-cryptography] new version breaks deluge
Package: python3-cryptography Version: 38.0.4-1 Severity: important Please be aware that the new version breaks deluge, see bug #1026240. Presumably needs the deluge maintainer to just update the packaged version rather than a bug fix being needed on this package. (Deluge is at v2.0.3; there's been 2.0.4, 2.0.5, 2.1.0 and 2.1.1 since). Filing this bug primarily to raise awareness.
Bug#1026240: Acknowledgement ([deluge] crashes on load)
Downgrading python3-cryptography from 38.0.4-1 to 3.4.8-2 is a temporary workaround.
Bug#1026240: [deluge] crashes on load
Package: deluge
Version: 2.0.3-3.2
Severity: grave
Worked yesterday, now won't start.
Loading in a terminal reveals the following output:
Traceback (most recent call last):
File "/usr/bin/deluge", line 33, in
sys.exit(load_entry_point('deluge==2.0.3', 'gui_scripts', 'deluge')())
File "/usr/lib/python3/dist-packages/deluge/ui/ui_entry.py", line 143, in
start_ui
ui.start()
File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/__init__.py", line 43, in
start
from .gtkui import GtkUI
File "/usr/lib/python3/dist-packages/deluge/ui/gtk3/gtkui.py", line 27, in
from twisted.internet import defer, gtk3reactor
File "/usr/lib/python3/dist-packages/twisted/internet/gtk3reactor.py", line
22, in
from twisted.internet import gireactor
File "/usr/lib/python3/dist-packages/twisted/internet/gireactor.py", line 27,
in
from twisted.internet import _glibbase
File "/usr/lib/python3/dist-packages/twisted/internet/_glibbase.py", line 19,
in
from twisted.internet import base, posixbase, selectreactor
File "/usr/lib/python3/dist-packages/twisted/internet/posixbase.py", line 19,
in
from twisted.internet import error, tcp, udp
File "/usr/lib/python3/dist-packages/twisted/internet/tcp.py", line 38, in
from twisted.internet._newtls import (
File "/usr/lib/python3/dist-packages/twisted/internet/_newtls.py", line 18,
in
from twisted.protocols.tls import TLSMemoryBIOFactory, TLSMemoryBIOProtocol
File "/usr/lib/python3/dist-packages/twisted/protocols/tls.py", line 50, in
Connection(Context(TLSv1_METHOD), None)
File "/usr/lib/python3/dist-packages/OpenSSL/SSL.py", line 674, in __init__
res = _lib.SSL_CTX_set_ecdh_auto(context, 1)
AttributeError: module 'lib' has no attribute 'SSL_CTX_set_ecdh_auto'
Bug#1026137: gobgp: switch B-D to golang-github-golang-protobuf-1-5-dev
Control: block 1026137 by 1026139 Updating the B-D to golang-github-golang-protobuf-1-5-dev conflicts with golang-github-golang-protobuf-1-3-dev that is pulled in by the version of golang-google-grpc-dev in experimental or one of its dependencies. Once that's resolved it should be pretty straightforward to resolve the issue with gobgp in experimental. Mathias signature.asc Description: This is a digitally signed message part
Bug#1026235: tar: ftbfs with recent glibc
On 2022-12-16 5:33 p.m., Florian Weimer wrote: * John David Anglin: On 2022-12-16 4:24 p.m., Florian Weimer wrote: * John David Anglin: I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64 This would avoid the overflow converting tv_sec from 64 to 32 bits. It's an ABI break. You probably can enable it in the tar build safely because it's not a library. But doing it by default across the distribution is difficult because it changes the meaning of time_t in header files. But it seems we already have an ABI break since tar built before the recent glibc changes. No, not an ABI break. A regression. I suspect the glibc bugfix exposed that the tar test was failing all along. If we are sure that the glibc bugfix just exposed the tar problem, then this issue can be closed. Dave -- John David Anglin dave.ang...@bell.net
Bug#1026239: transition: proftpd-dfsg
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: proftpd-d...@packages.debian.org Control: affects -1 + src:proftpd-dfsg This transition was already started by the recent proftpd upload, but is not caught caught automatically since it is a virtual package name that has changed. Ben file: title = "proftpd-dfsg"; is_affected = .depends ~ "proftpd-abi-1.3.7d" | .depends ~ "proftpd-abi-1.3.8"; is_good = .depends ~ "proftpd-abi-1.3.8"; is_bad = .depends ~ "proftpd-abi-1.3.7d"; Hilmar -- sigmentation fault signature.asc Description: PGP signature
Bug#1026235: tar: ftbfs with recent glibc
* John David Anglin: > On 2022-12-16 4:24 p.m., Florian Weimer wrote: >> * John David Anglin: >> >>> I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64 >>> This would avoid the overflow converting tv_sec from 64 to 32 bits. >> It's an ABI break. You probably can enable it in the tar build safely >> because it's not a library. But doing it by default across the >> distribution is difficult because it changes the meaning of time_t in >> header files. > But it seems we already have an ABI break since tar built before the > recent glibc changes. No, not an ABI break. A regression. I suspect the glibc bugfix exposed that the tar test was failing all along. Thanks, Florian
Bug#1025873: snac2: Crashes after a seconds with segfault since another account mentioned an account on this instance
On Sun, 11 Dec 2022 02:17:59 +0100 Axel Beckert wrote: > It might help to first try to package the most recent upstream version > (2.15 as of this writing) because 2.12 and 2.14 at least do fix some > crashes according to the release notes. So maybe these crashes I > experience are already fixed upstream. > > Feel free to ping me for testing the new version. 2.15 is now in experimental. Please check if the issue still happens. OpenPGP_signature Description: OpenPGP digital signature
Bug#990560: Error message "Value too large for defined data type"
On Tue, Dec 13, 2022 at 07:08:29PM +0100, Helge Deller wrote: > tag: hppa, lfs, patch > > This bug usually indicates that a 32-bit application uses > functions like readdir() which (by default on a 32bit platform) > can only handle 32-bit values for inode numbers. > You can overcome that issue by recompiling the code while providing > "-D_FILE_OFFSET_BITS=64" on the gcc command line. Thanks for the investigation. Subversion is using libapr to perform the directory listing, which builds with -D_LARGEFILE64_SUPPORT but not -D_FILE_OFFSET_BITS=64. Subversion itself also builds with -D_LARGEFILE64_SUPPORT and (for the Perl bindings) -D_FILE_OFFSET_BITS=64. It should probably be consistent about that, which your suggestion would enforce. > In this specific case I suggest to add the "future=+lfs" option > to debian/rules like this (copy/pasted here - may not apply cleanly but you > get the idea): I'll need to double check whether this affects the ABI of subversions library. Hopefully not, since it tends to defer to APR for OS-specific things. However, I'm not sure changing subversion's build alone will address the problem. APR may need a similar change. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#965990: Won't fix
Control: tags -1 +wontfix The `export` command was removed in nftables v0.9.1. J. signature.asc Description: PGP signature
Bug#1026234: linux-image-6.0.0-5-amd64: i915 driver fails on resume
Hi Floris, On Fri, Dec 16, 2022 at 10:34:08PM +0100, Floris Bruynooghe wrote: > Hi Salvatore, > > On Fri 16 Dec 2022 at 21:50 +0100, Salvatore Bonaccorso wrote: > > > Hi Floris, > > > > On Fri, Dec 16, 2022 at 09:28:35PM +0100, Floris Bruynooghe wrote: > >> Package: src:linux > >> Version: 6.0.10-2 > >> Severity: important > >> > >> Dear Maintainer, > >> > >> Since the 6.0.0-5 kernel the i915 graphics driver often fails on resume. > >> Downgrading to the 6.0.0-4 kernel fixes it and the driver works > >> flawlessly across resume, changing displays etc. > >> > >> On the -5 kernel the following errors are observed when the driver > >> crashes: > >> > >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-9: PM: parent card0 should > >> not be sleeping > >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-10: PM: parent card0 > >> should not be sleeping > >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-11: PM: parent card0 > >> should not be sleeping > >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: [drm] *ERROR* > >> Sending link address failed with -5 > >> Dec 13 11:26:58 fredriksen kernel: [ cut here ] > >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: > >> drm_WARN_ON(dig_port->tc_mode != TC_PORT_DISCONNECTED) > >> Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at > >> drivers/gpu/drm/i915/display/intel_tc.c:711 int> > >> Dec 13 11:26:58 fredriksen kernel: Modules linked in: usblp ctr ccm rfcomm > >> cmac algif_hash algif_skcipher af_alg> > >> Dec 13 11:26:58 fredriksen kernel: snd_sof_utils ecdh_generic > >> snd_soc_hdac_hda ecc snd_hda_ext_core snd_soc_acp> > >> Dec 13 11:26:58 fredriksen kernel: configfs efivarfs ip_tables x_tables > >> autofs4 btrfs blake2b_generic libcrc32c> > >> Dec 13 11:26:58 fredriksen kernel: CPU: 0 PID: 27095 Comm: kworker/u32:101 > >> Not tainted 6.0.0-5-amd64 #1 Debian > > >> Dec 13 11:26:58 fredriksen kernel: Hardware name: LENOVO > >> 21CBCTO1WW/21CBCTO1WW, BIOS N3AET67W (1.32 ) 09/27/2022 > >> Dec 13 11:26:58 fredriksen kernel: Workqueue: events_unbound > >> async_run_entry_fn > >> Dec 13 11:26:58 fredriksen kernel: RIP: > >> 0010:intel_tc_port_sanitize+0x2d2/0x490 [i915] > >> Dec 13 11:26:58 fredriksen kernel: Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b > >> 2f e8 a7 44 42 e3 48 c7 c1 f8 a6 d6 c0> > >> Dec 13 11:26:58 fredriksen kernel: RSP: 0018:a84dc5debc08 EFLAGS: > >> 00010286 > >> Dec 13 11:26:58 fredriksen kernel: RAX: RBX: > >> 9c812065 RCX: > >> Dec 13 11:26:58 fredriksen kernel: RDX: 0001 RSI: > >> a4b7eeea RDI: > >> Dec 13 11:26:58 fredriksen kernel: RBP: R08: > >> a5262260 R09: a5b5348a > >> Dec 13 11:26:58 fredriksen kernel: R10: R11: > >> 004a R12: 9c81101a2000 > >> Dec 13 11:26:58 fredriksen kernel: R13: 9c8101f19900 R14: > >> R15: 9c81101a2000 > >> Dec 13 11:26:58 fredriksen kernel: FS: () > >> GS:9c883f40() knlGS: > >> Dec 13 11:26:58 fredriksen kernel: CS: 0010 DS: ES: CR0: > >> 80050033 > >> Dec 13 11:26:58 fredriksen kernel: CR2: 55710e140b16 CR3: > >> 0002db810003 CR4: 00770ef0 > >> Dec 13 11:26:58 fredriksen kernel: PKRU: 5554 > >> Dec 13 11:26:58 fredriksen kernel: Call Trace: > >> Dec 13 11:26:58 fredriksen kernel: > >> Dec 13 11:26:58 fredriksen kernel: intel_ddi_sync_state+0x3f/0x90 [i915] > >> Dec 13 11:26:58 fredriksen kernel: > >> intel_modeset_setup_hw_state+0x3b1/0x1410 [i915] > >> Dec 13 11:26:58 fredriksen kernel: ? _raw_spin_lock_irq+0x19/0x40 > >> Dec 13 11:26:58 fredriksen kernel: ? wait_for_completion+0x91/0x160 > >> Dec 13 11:26:58 fredriksen kernel: ? drm_modeset_lock+0x63/0xd0 [drm] > >> Dec 13 11:26:58 fredriksen kernel: ? ww_mutex_lock+0x14/0x80 > >> Dec 13 11:26:58 fredriksen kernel: ? __intel_display_resume+0x1a/0xe0 > >> [i915] > >> Dec 13 11:26:58 fredriksen kernel: __intel_display_resume+0x1a/0xe0 [i915] > >> Dec 13 11:26:58 fredriksen kernel: intel_display_resume+0xfc/0x140 [i915] > >> Dec 13 11:26:58 fredriksen kernel: i915_drm_resume+0xba/0x130 [i915] > >> Dec 13 11:26:58 fredriksen kernel: ? pci_pm_poweroff_noirq+0x100/0x100 > >> Dec 13 11:26:58 fredriksen kernel: dpm_run_callback+0x47/0x150 > >> Dec 13 11:26:58 fredriksen kernel: device_resume+0x88/0x190 > >> Dec 13 11:26:58 fredriksen kernel: async_resume+0x19/0x30 > >> Dec 13 11:26:58 fredriksen kernel: async_run_entry_fn+0x2d/0x130 > >> Dec 13 11:26:58 fredriksen kernel: process_one_work+0x1c4/0x380 > >> Dec 13 11:26:58 fredriksen kernel: worker_thread+0x4d/0x380 > >> Dec 13 11:26:58 fredriksen kernel: ? rescuer_thread+0x3a0/0x3a0 > >> Dec 13 11:26:58 fredriksen kernel: kthread+0xe6/0x110 > >> Dec 13 11:26:58 fredriksen kernel: ? kthread_complete_and_exit+0x20/0x20 > >> Dec 13 11:26:58 fredriksen kernel:
Bug#1025953: Reassigning to libhmsbeagle
Control: reassign -1 libhmsbeagle 3.1.2+dfsg-12 Control: affects -1 beast-mcmc beast2-mcmc Control: tags -1 pending Hi, Thanks to Remco Bouckaert, the author of beast2, I could find the issue is in libhmsbeagle. Passing --without-opencl to the configure step of libhmsbeagle allows one to avoid errors such as the one you reported. This change does not seem to affect the other reverse dependency of libhmsbeagle, so I am endorsing it. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1026238: tea: "The tea.desktop file has an error", desktop-file-validate said
Package: tea Version: 61.2.0-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! The application "desktop-file-validate" told me this about tea's desktop file: desktop-file-validate /usr/share/applications/tea.desktop /usr/share/applications/tea.desktop: error: (will be fatal in the future): value "text/plain;application/epub+zip;application/fb2;application/vnd.openxmlformats-officedocument.wordprocessingml.document;application/vnd.oasis.opendocument.text;application/rtf;application/x-tex; " for key "MimeType" in group "Desktop Entry" contains value " " which is an invalid MIME type: " " does not contain a subtype root@Archimedes:~/work# mcedit /usr/share/applications/tea.desktop There is a space character at the end of the "MimeType" line. After I removed this space, desktop-file-validate didn't said anything again. This bug should be fixed in next version. - -- Yours sincerely Joerg Schiermeier - -- System Information: Debian Release: bookworm/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), LANGUAGE=de:en_GB Shell: /bin/sh linked to /usr/bin/dash Init: OpenRC (via /run/openrc), PID 1: init Versions of packages tea depends on: ii libaspell150.60.8-4+b1 ii libc6 2.36-6 ii libdjvulibre21 3.5.28-2 ii libgcc-s1 12.2.0-10 ii libhunspell-1.7-0 1.7.1-1 ii libpoppler-qt5-1 22.08.0-2.1 ii libqt5core5a 5.15.6+dfsg-5 ii libqt5gui5 5.15.6+dfsg-5 ii libqt5widgets5 5.15.6+dfsg-5 ii libstdc++6 12.2.0-10 ii tea-data 61.2.0-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages tea recommends: ii antiword 0.37-16 ii aspell0.60.8-4+b1 ii bzip2 1.0.8-5+b1 ii hunspell 1.7.1-1 tea suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Comment: This was created by GnuPG for Linux. iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAmOc51AACgkQodFQ9YsO 8GML3g//a/ScfLjzXrnM0YkFVG7HhCowMrUz8eRJeeNZpW1136McqVDHvMYxRhzE HTw6qzv+JB+1f2hr0m+GxQbhCeukFstJ07MQT/aVzATV5u0azArWpyBniN5qhML2 T08BlvBDKipn/Gzep81TnEaucmPNGoyt+UgYwDsxyH0XWiTNTmjEcRdcWEKA2akf KjzZF2vuW9q+yW7P/4v7YfXykJdmb9ZOsuOo6nEbLZGPSduj474QnvVivgq+oOIJ h4ZcxaEN1NHaBwgf0K45Rz6gwhV7ecWe7z67u/ckA+3KdMyC9MlX2GSURM4pTjT2 iELMIMqJbtQyeYC637RW4owMa3VzXFquBbYefRsUr8DcQ8Xu23NvMhWFY/NriMo8 QeY5kTqWCzP+hS8h/6O/hqtNjJmIgcgOB3SMx9wN41vu4kXaF0OtTqyGUGe3yA5q 0nBaf8hKQDa47Vaqitq9HdbFX6oQiS+ryFaWmbBVE08micepX53H/SK+6Z2Bj5H/ kPvpbeMJuF0OrKXVQsl8Amq00nXjhEqzOkhMEFN2IOO2qIr41wtItX7MAifSl+Jh VreyDE30GSP9zBajhtDf3hNIj7oVFU/suJhXxMEqbExcDrWwrHcFn6UghQuPpf4O VGIAUGg98kt03U62/CpPALHF9heASKgqIrajzfddmqKWizG38ks= =APhd -END PGP SIGNATURE-
Bug#1026235: tar: ftbfs with recent glibc
On 2022-12-16 4:24 p.m., Florian Weimer wrote: * John David Anglin: I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64 This would avoid the overflow converting tv_sec from 64 to 32 bits. It's an ABI break. You probably can enable it in the tar build safely because it's not a library. But doing it by default across the distribution is difficult because it changes the meaning of time_t in header files. But it seems we already have an ABI break since tar built before the recent glibc changes. Regards, Dave -- John David Anglin dave.ang...@bell.net
Bug#1026237: tcl-fitstcl: FTBFS with cfitsio 4.2.0 / new upstream version 2.5
Source: tcl-fitstcl
Version: 2.4-4
Severity: important
Tags: ftbfs patch upstream
Hi Ole,
A new version of cfitsio has been released recently, and it fixes a few
security issues, but it also includes a soname change, meaning we have
to do a transition. I would like to try to get it into bookworm. So far
the version 4.2.0 is already in experimental.
I have tried to rebuild all the reverse dependencies and it appears that
unfortunately tcl-fitstcl fails to build against it. It is not fully
surprising, given it accesses internal cfitsio structures. However NASA
just released version 2.5 [1] which adds support for cfitsio 4.2.0 (but
removes support for older versions). The debian package also need some
changes to make it working, I have attached the debdiff I ended up with.
Would it be possible to upload this new version to experimental asap,
and if we can still get a transition slot, synchronize the upload to
unstable with cfitsio?
Thanks,
Aurelien
[1]
https://heasarc.gsfc.nasa.gov/docs/software/lheasoft/ftools/fv/fitsTcl_home.html
diff -Nru tcl-fitstcl-2.4/debian/control tcl-fitstcl-2.5/debian/control
--- tcl-fitstcl-2.4/debian/control 2019-02-28 21:06:35.0 +
+++ tcl-fitstcl-2.5/debian/control 2022-12-16 21:17:19.0 +
@@ -5,7 +5,7 @@
Uploaders: Ole Streicher
Build-Depends: debhelper (>= 12),
dh-autoreconf,
- libcfitsio-dev | libcfitsio3-dev,
+ libcfitsio-dev (>= 4.2.0),
tcl-dev,
wcslib-dev
Standards-Version: 4.3.0
diff -Nru
tcl-fitstcl-2.4/debian/patches/Propagate-CPPFLAGS-and-LDFLAGS-for-hardening.patch
tcl-fitstcl-2.5/debian/patches/Propagate-CPPFLAGS-and-LDFLAGS-for-hardening.patch
---
tcl-fitstcl-2.4/debian/patches/Propagate-CPPFLAGS-and-LDFLAGS-for-hardening.patch
2019-02-28 21:03:49.0 +
+++
tcl-fitstcl-2.5/debian/patches/Propagate-CPPFLAGS-and-LDFLAGS-for-hardening.patch
2022-12-16 21:17:19.0 +
@@ -19,7 +19,7 @@
+ ${CC} -c -o ${
+#include
+#include
@@ -134,15 +134,19 @@
+#endif
+#include "fitsio2.h"
+
-+#ifndef FFBISON
-+#include "eval_tab.h"
-+#endif
-+
+#define MAXDIMS 5
+#define MAXSUBS 10
+#define MAXVARNAME 80
+#define CONST_OP -1000
+#define pERROR -1
++#define MAX_STRLEN 256
++#define MAX_STRLEN_S "255"
++
++typedef struct ParseData_struct ParseData;
++typedef void* yyscan_t;
++#ifndef FFBISON
++#include "eval_tab.h"
++#endif
+
+
+typedef struct {
@@ -164,7 +168,7 @@
+ double dbl;
+ long lng;
+ char log;
-+ char str[256];
++ char str[MAX_STRLEN];
+ double *dblptr;
+ long *lngptr;
+ char *logptr;
@@ -175,17 +179,17 @@
+
+typedef struct Node {
+ intoperation;
-+ void (*DoOp)(struct Node *this);
++void (*DoOp)(ParseData *, struct Node *this);
+ intnSubNodes;
+ intSubNodes[MAXSUBS];
+ inttype;
+ lval value;
+} Node;
+
-+typedef struct {
++struct ParseData_struct {
+ fitsfile*def_fptr;
-+ int (*getData)( char *dataName, void *dataValue );
-+ int (*loadData)( int varNum, long fRow, long nRows,
++int (*getData)( ParseData *, char *dataName, void
*dataValue );
++int (*loadData)( ParseData *, int varNum, long fRow,
long nRows,
+ void *data, char *undef );
+
+ int compressed;
@@ -201,11 +205,14 @@
+ int nNodes;
+ int nNodesAlloc;
+ int resultNode;
-+
++
+ longfirstRow;
+ longnRows;
+
+ int nCols;
++ long nElements;
++ int nAxis;
++ longnAxes[MAXDIMS];
+ iteratorCol *colData;
+ DataInfo*varData;
+ PixelFilter *pixFilter;
@@ -213,12 +220,13 @@
+ longfirstDataRow;
+ longnDataRows;
+ longtotalRows;
++ longnPrevDataRows;
+
+ int datatype;
+ int hdutype;
+
+ int status;
-+} ParseData;
++};
+
+typedef enum {
+ rnd_fct = 1001,
@@ -263,68 +271,196 @@
+nonnull_fct,
+angsep_fct,
+gasrnd_fct,
-+poirnd_fct
++poirnd_fct,
++
Bug#1025213: DRM platform with kms_swrast
If the i915 dri driver is present gnome-shell is using the DRM platform (not the Wayland platform?) with this driver. If i915 is not present gnome-shell uses the DRM platform with the kms_swrast-driver! I did not see this with the lsof-command, because the name of the "zink"-driver was shown which is hard-linked to the other dri-drivers and was opened and checked unsuccessfully before the "kms_swrast" driver. I tried an old version 22.0.5-1 of kms_swrast driver, but that did not help. I will open an issue upstream.
Bug#1026234: linux-image-6.0.0-5-amd64: i915 driver fails on resume
Hi Salvatore, On Fri 16 Dec 2022 at 21:50 +0100, Salvatore Bonaccorso wrote: > Hi Floris, > > On Fri, Dec 16, 2022 at 09:28:35PM +0100, Floris Bruynooghe wrote: >> Package: src:linux >> Version: 6.0.10-2 >> Severity: important >> >> Dear Maintainer, >> >> Since the 6.0.0-5 kernel the i915 graphics driver often fails on resume. >> Downgrading to the 6.0.0-4 kernel fixes it and the driver works >> flawlessly across resume, changing displays etc. >> >> On the -5 kernel the following errors are observed when the driver >> crashes: >> >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-9: PM: parent card0 should >> not be sleeping >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-10: PM: parent card0 should >> not be sleeping >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-11: PM: parent card0 should >> not be sleeping >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: [drm] *ERROR* Sending >> link address failed with -5 >> Dec 13 11:26:58 fredriksen kernel: [ cut here ] >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: >> drm_WARN_ON(dig_port->tc_mode != TC_PORT_DISCONNECTED) >> Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at >> drivers/gpu/drm/i915/display/intel_tc.c:711 int> >> Dec 13 11:26:58 fredriksen kernel: Modules linked in: usblp ctr ccm rfcomm >> cmac algif_hash algif_skcipher af_alg> >> Dec 13 11:26:58 fredriksen kernel: snd_sof_utils ecdh_generic >> snd_soc_hdac_hda ecc snd_hda_ext_core snd_soc_acp> >> Dec 13 11:26:58 fredriksen kernel: configfs efivarfs ip_tables x_tables >> autofs4 btrfs blake2b_generic libcrc32c> >> Dec 13 11:26:58 fredriksen kernel: CPU: 0 PID: 27095 Comm: kworker/u32:101 >> Not tainted 6.0.0-5-amd64 #1 Debian > >> Dec 13 11:26:58 fredriksen kernel: Hardware name: LENOVO >> 21CBCTO1WW/21CBCTO1WW, BIOS N3AET67W (1.32 ) 09/27/2022 >> Dec 13 11:26:58 fredriksen kernel: Workqueue: events_unbound >> async_run_entry_fn >> Dec 13 11:26:58 fredriksen kernel: RIP: >> 0010:intel_tc_port_sanitize+0x2d2/0x490 [i915] >> Dec 13 11:26:58 fredriksen kernel: Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f >> e8 a7 44 42 e3 48 c7 c1 f8 a6 d6 c0> >> Dec 13 11:26:58 fredriksen kernel: RSP: 0018:a84dc5debc08 EFLAGS: >> 00010286 >> Dec 13 11:26:58 fredriksen kernel: RAX: RBX: >> 9c812065 RCX: >> Dec 13 11:26:58 fredriksen kernel: RDX: 0001 RSI: >> a4b7eeea RDI: >> Dec 13 11:26:58 fredriksen kernel: RBP: R08: >> a5262260 R09: a5b5348a >> Dec 13 11:26:58 fredriksen kernel: R10: R11: >> 004a R12: 9c81101a2000 >> Dec 13 11:26:58 fredriksen kernel: R13: 9c8101f19900 R14: >> R15: 9c81101a2000 >> Dec 13 11:26:58 fredriksen kernel: FS: () >> GS:9c883f40() knlGS: >> Dec 13 11:26:58 fredriksen kernel: CS: 0010 DS: ES: CR0: >> 80050033 >> Dec 13 11:26:58 fredriksen kernel: CR2: 55710e140b16 CR3: >> 0002db810003 CR4: 00770ef0 >> Dec 13 11:26:58 fredriksen kernel: PKRU: 5554 >> Dec 13 11:26:58 fredriksen kernel: Call Trace: >> Dec 13 11:26:58 fredriksen kernel: >> Dec 13 11:26:58 fredriksen kernel: intel_ddi_sync_state+0x3f/0x90 [i915] >> Dec 13 11:26:58 fredriksen kernel: >> intel_modeset_setup_hw_state+0x3b1/0x1410 [i915] >> Dec 13 11:26:58 fredriksen kernel: ? _raw_spin_lock_irq+0x19/0x40 >> Dec 13 11:26:58 fredriksen kernel: ? wait_for_completion+0x91/0x160 >> Dec 13 11:26:58 fredriksen kernel: ? drm_modeset_lock+0x63/0xd0 [drm] >> Dec 13 11:26:58 fredriksen kernel: ? ww_mutex_lock+0x14/0x80 >> Dec 13 11:26:58 fredriksen kernel: ? __intel_display_resume+0x1a/0xe0 [i915] >> Dec 13 11:26:58 fredriksen kernel: __intel_display_resume+0x1a/0xe0 [i915] >> Dec 13 11:26:58 fredriksen kernel: intel_display_resume+0xfc/0x140 [i915] >> Dec 13 11:26:58 fredriksen kernel: i915_drm_resume+0xba/0x130 [i915] >> Dec 13 11:26:58 fredriksen kernel: ? pci_pm_poweroff_noirq+0x100/0x100 >> Dec 13 11:26:58 fredriksen kernel: dpm_run_callback+0x47/0x150 >> Dec 13 11:26:58 fredriksen kernel: device_resume+0x88/0x190 >> Dec 13 11:26:58 fredriksen kernel: async_resume+0x19/0x30 >> Dec 13 11:26:58 fredriksen kernel: async_run_entry_fn+0x2d/0x130 >> Dec 13 11:26:58 fredriksen kernel: process_one_work+0x1c4/0x380 >> Dec 13 11:26:58 fredriksen kernel: worker_thread+0x4d/0x380 >> Dec 13 11:26:58 fredriksen kernel: ? rescuer_thread+0x3a0/0x3a0 >> Dec 13 11:26:58 fredriksen kernel: kthread+0xe6/0x110 >> Dec 13 11:26:58 fredriksen kernel: ? kthread_complete_and_exit+0x20/0x20 >> Dec 13 11:26:58 fredriksen kernel: ret_from_fork+0x1f/0x30 >> Dec 13 11:26:58 fredriksen kernel: >> Dec 13 11:26:58 fredriksen kernel: ---[ end trace ]--- >> Dec 13 11:26:58 fredriksen kernel: [ cut here ] >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0:
Bug#1026235: tar: ftbfs with recent glibc
* John David Anglin: > I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64 > This would avoid the overflow converting tv_sec from 64 to 32 bits. It's an ABI break. You probably can enable it in the tar build safely because it's not a library. But doing it by default across the distribution is difficult because it changes the meaning of time_t in header files. Thanks, Florian
Bug#1026236: tracker: Please increase test timeouts for "riscv64" arch
Source: tracker Version: 3.4.2-1 Severity: wishlist Tags: ftbfs patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org, m...@debian.org Hi, I built this package with the attached changes in the .debdiff. Basically it's setting the timeout multiplier to 3, as one of the tests (23/37: tracker:core / service) takes around 67 seconds. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru tracker-3.4.2/debian/changelog tracker-3.4.2/debian/changelog --- tracker-3.4.2/debian/changelog 2022-12-06 21:51:16.0 + +++ tracker-3.4.2/debian/changelog 2022-12-16 15:11:36.0 + @@ -1,3 +1,10 @@ +tracker (3.4.2-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: test timeouts, use multiplier x3 + + -- Manuel A. Fernandez Montecelo Fri, 16 Dec 2022 15:11:36 + + tracker (3.4.2-1) unstable; urgency=medium * New upstream release diff -Nru tracker-3.4.2/debian/rules tracker-3.4.2/debian/rules --- tracker-3.4.2/debian/rules 2022-12-06 21:51:16.0 + +++ tracker-3.4.2/debian/rules 2022-12-16 15:11:36.0 + @@ -26,4 +26,4 @@ dh_makeshlibs -V -X/usr/lib/$(DEB_HOST_MULTIARCH)/tracker-3.0/ -- -c4 override_dh_auto_test: - dbus-run-session -- dh_auto_test --no-parallel + dbus-run-session -- dh_auto_test --no-parallel -- --timeout-multiplier 3
Bug#1026234: linux-image-6.0.0-5-amd64: i915 driver fails on resume
Hi Floris, On Fri, Dec 16, 2022 at 09:28:35PM +0100, Floris Bruynooghe wrote: > Package: src:linux > Version: 6.0.10-2 > Severity: important > > Dear Maintainer, > > Since the 6.0.0-5 kernel the i915 graphics driver often fails on resume. > Downgrading to the 6.0.0-4 kernel fixes it and the driver works > flawlessly across resume, changing displays etc. > > On the -5 kernel the following errors are observed when the driver > crashes: > > Dec 13 11:26:58 fredriksen kernel: drm card0-DP-9: PM: parent card0 should > not be sleeping > Dec 13 11:26:58 fredriksen kernel: drm card0-DP-10: PM: parent card0 should > not be sleeping > Dec 13 11:26:58 fredriksen kernel: drm card0-DP-11: PM: parent card0 should > not be sleeping > Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: [drm] *ERROR* Sending > link address failed with -5 > Dec 13 11:26:58 fredriksen kernel: [ cut here ] > Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: > drm_WARN_ON(dig_port->tc_mode != TC_PORT_DISCONNECTED) > Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at > drivers/gpu/drm/i915/display/intel_tc.c:711 int> > Dec 13 11:26:58 fredriksen kernel: Modules linked in: usblp ctr ccm rfcomm > cmac algif_hash algif_skcipher af_alg> > Dec 13 11:26:58 fredriksen kernel: snd_sof_utils ecdh_generic > snd_soc_hdac_hda ecc snd_hda_ext_core snd_soc_acp> > Dec 13 11:26:58 fredriksen kernel: configfs efivarfs ip_tables x_tables > autofs4 btrfs blake2b_generic libcrc32c> > Dec 13 11:26:58 fredriksen kernel: CPU: 0 PID: 27095 Comm: kworker/u32:101 > Not tainted 6.0.0-5-amd64 #1 Debian > > Dec 13 11:26:58 fredriksen kernel: Hardware name: LENOVO > 21CBCTO1WW/21CBCTO1WW, BIOS N3AET67W (1.32 ) 09/27/2022 > Dec 13 11:26:58 fredriksen kernel: Workqueue: events_unbound > async_run_entry_fn > Dec 13 11:26:58 fredriksen kernel: RIP: > 0010:intel_tc_port_sanitize+0x2d2/0x490 [i915] > Dec 13 11:26:58 fredriksen kernel: Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f > e8 a7 44 42 e3 48 c7 c1 f8 a6 d6 c0> > Dec 13 11:26:58 fredriksen kernel: RSP: 0018:a84dc5debc08 EFLAGS: 00010286 > Dec 13 11:26:58 fredriksen kernel: RAX: RBX: > 9c812065 RCX: > Dec 13 11:26:58 fredriksen kernel: RDX: 0001 RSI: > a4b7eeea RDI: > Dec 13 11:26:58 fredriksen kernel: RBP: R08: > a5262260 R09: a5b5348a > Dec 13 11:26:58 fredriksen kernel: R10: R11: > 004a R12: 9c81101a2000 > Dec 13 11:26:58 fredriksen kernel: R13: 9c8101f19900 R14: > R15: 9c81101a2000 > Dec 13 11:26:58 fredriksen kernel: FS: () > GS:9c883f40() knlGS: > Dec 13 11:26:58 fredriksen kernel: CS: 0010 DS: ES: CR0: > 80050033 > Dec 13 11:26:58 fredriksen kernel: CR2: 55710e140b16 CR3: > 0002db810003 CR4: 00770ef0 > Dec 13 11:26:58 fredriksen kernel: PKRU: 5554 > Dec 13 11:26:58 fredriksen kernel: Call Trace: > Dec 13 11:26:58 fredriksen kernel: > Dec 13 11:26:58 fredriksen kernel: intel_ddi_sync_state+0x3f/0x90 [i915] > Dec 13 11:26:58 fredriksen kernel: intel_modeset_setup_hw_state+0x3b1/0x1410 > [i915] > Dec 13 11:26:58 fredriksen kernel: ? _raw_spin_lock_irq+0x19/0x40 > Dec 13 11:26:58 fredriksen kernel: ? wait_for_completion+0x91/0x160 > Dec 13 11:26:58 fredriksen kernel: ? drm_modeset_lock+0x63/0xd0 [drm] > Dec 13 11:26:58 fredriksen kernel: ? ww_mutex_lock+0x14/0x80 > Dec 13 11:26:58 fredriksen kernel: ? __intel_display_resume+0x1a/0xe0 [i915] > Dec 13 11:26:58 fredriksen kernel: __intel_display_resume+0x1a/0xe0 [i915] > Dec 13 11:26:58 fredriksen kernel: intel_display_resume+0xfc/0x140 [i915] > Dec 13 11:26:58 fredriksen kernel: i915_drm_resume+0xba/0x130 [i915] > Dec 13 11:26:58 fredriksen kernel: ? pci_pm_poweroff_noirq+0x100/0x100 > Dec 13 11:26:58 fredriksen kernel: dpm_run_callback+0x47/0x150 > Dec 13 11:26:58 fredriksen kernel: device_resume+0x88/0x190 > Dec 13 11:26:58 fredriksen kernel: async_resume+0x19/0x30 > Dec 13 11:26:58 fredriksen kernel: async_run_entry_fn+0x2d/0x130 > Dec 13 11:26:58 fredriksen kernel: process_one_work+0x1c4/0x380 > Dec 13 11:26:58 fredriksen kernel: worker_thread+0x4d/0x380 > Dec 13 11:26:58 fredriksen kernel: ? rescuer_thread+0x3a0/0x3a0 > Dec 13 11:26:58 fredriksen kernel: kthread+0xe6/0x110 > Dec 13 11:26:58 fredriksen kernel: ? kthread_complete_and_exit+0x20/0x20 > Dec 13 11:26:58 fredriksen kernel: ret_from_fork+0x1f/0x30 > Dec 13 11:26:58 fredriksen kernel: > Dec 13 11:26:58 fredriksen kernel: ---[ end trace ]--- > Dec 13 11:26:58 fredriksen kernel: [ cut here ] > Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: > drm_WARN_ON(dig_port->tc_lock_wakeref) > Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at > drivers/gpu/drm/i915/display/intel_tc.c:712 int> > Dec 13
Bug#1026235: tar: ftbfs with recent glibc
Source: libc6
Version: 2.36-6
Severity: normal
Dear Maintainer,
See the following BZ for tar:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026204
__USE_TIME_BITS64 now needs to be defined on most 32-bit
architectures to build tar even when _FILE_OFFSET_BITS=64
is selected. The folowing error occurs from glibc:
+tar: dir/f2038-01-19T03\:14\:08.9: Cannot stat: Value too large for defined
data type
The following two commits changed the handling of file times:
commit dd4131c8322891a0ad7cfb661efa41aecc02b581
Author: Aurelien Jarno
Date: Tue Nov 1 20:43:55 2022 +0100
linux: Fix fstatat on MIPSn64 (BZ #29730)
Commit 6e8a0aac2f883 ("time: Fix overflow itimer tests on 32-bit
systems") changed in_time_t_range to assume a 32-bit time_t. This broke
fstatat on MIPSn64 that was using it with a 64-bit time_t due to
difference between stat and stat64. This commit fix that by adding a
MIPSn64 specific version, which bypasses the EOVERFLOW tests.
Resolves: BZ #29730
Reviewed-by: Adhemerval Zanella
(cherry picked from commit 7457b7eef8dfe8cc48e55b9f9837df6dd397b80d)
commit 7b7dfbb0cbdffebf0233c650627a4861212fbb60
Author: Adhemerval Zanella
Date: Wed Oct 19 19:14:04 2022 -0300
linux: Fix generic struct_stat for 64 bit time (BZ# 29657)
The generic Linux struct_stat misses the conditionals to use
bits/struct_stat_time64_helper.h in the __USE_TIME_BITS64 for
architecture that uses __TIMESIZE == 32 (currently csky and nios2).
Since newer ports should not support 32 bit time_t, the generic
implementation should be used as default.
For arm, hppa, and sh a copy of default struct_stat is added,
while for csky and nios a new one based on generic is used, along
with conditionals to use bits/struct_stat_time64_helper.h.
The default struct_stat is also replaced with the generic one.
Checked on aarch64-linux-gnu and arm-linux-gnueabihf.
(cherry picked from commit 7a6ca82f8007ddbd43e2b8fce806ba7101ee47f5)
I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64
This would avoid the overflow converting tv_sec from 64 to 32 bits.
Regards,
Dave
-- System Information:
Debian Release: bookworm/sid
APT prefers buildd-unstable
APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)
Kernel: Linux 6.0.12 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
-- debconf information excluded
Bug#1026234: linux-image-6.0.0-5-amd64: i915 driver fails on resume
Package: src:linux Version: 6.0.10-2 Severity: important Dear Maintainer, Since the 6.0.0-5 kernel the i915 graphics driver often fails on resume. Downgrading to the 6.0.0-4 kernel fixes it and the driver works flawlessly across resume, changing displays etc. On the -5 kernel the following errors are observed when the driver crashes: Dec 13 11:26:58 fredriksen kernel: drm card0-DP-9: PM: parent card0 should not be sleeping Dec 13 11:26:58 fredriksen kernel: drm card0-DP-10: PM: parent card0 should not be sleeping Dec 13 11:26:58 fredriksen kernel: drm card0-DP-11: PM: parent card0 should not be sleeping Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: [drm] *ERROR* Sending link address failed with -5 Dec 13 11:26:58 fredriksen kernel: [ cut here ] Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: drm_WARN_ON(dig_port->tc_mode != TC_PORT_DISCONNECTED) Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at drivers/gpu/drm/i915/display/intel_tc.c:711 int> Dec 13 11:26:58 fredriksen kernel: Modules linked in: usblp ctr ccm rfcomm cmac algif_hash algif_skcipher af_alg> Dec 13 11:26:58 fredriksen kernel: snd_sof_utils ecdh_generic snd_soc_hdac_hda ecc snd_hda_ext_core snd_soc_acp> Dec 13 11:26:58 fredriksen kernel: configfs efivarfs ip_tables x_tables autofs4 btrfs blake2b_generic libcrc32c> Dec 13 11:26:58 fredriksen kernel: CPU: 0 PID: 27095 Comm: kworker/u32:101 Not tainted 6.0.0-5-amd64 #1 Debian > Dec 13 11:26:58 fredriksen kernel: Hardware name: LENOVO 21CBCTO1WW/21CBCTO1WW, BIOS N3AET67W (1.32 ) 09/27/2022 Dec 13 11:26:58 fredriksen kernel: Workqueue: events_unbound async_run_entry_fn Dec 13 11:26:58 fredriksen kernel: RIP: 0010:intel_tc_port_sanitize+0x2d2/0x490 [i915] Dec 13 11:26:58 fredriksen kernel: Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 a7 44 42 e3 48 c7 c1 f8 a6 d6 c0> Dec 13 11:26:58 fredriksen kernel: RSP: 0018:a84dc5debc08 EFLAGS: 00010286 Dec 13 11:26:58 fredriksen kernel: RAX: RBX: 9c812065 RCX: Dec 13 11:26:58 fredriksen kernel: RDX: 0001 RSI: a4b7eeea RDI: Dec 13 11:26:58 fredriksen kernel: RBP: R08: a5262260 R09: a5b5348a Dec 13 11:26:58 fredriksen kernel: R10: R11: 004a R12: 9c81101a2000 Dec 13 11:26:58 fredriksen kernel: R13: 9c8101f19900 R14: R15: 9c81101a2000 Dec 13 11:26:58 fredriksen kernel: FS: () GS:9c883f40() knlGS: Dec 13 11:26:58 fredriksen kernel: CS: 0010 DS: ES: CR0: 80050033 Dec 13 11:26:58 fredriksen kernel: CR2: 55710e140b16 CR3: 0002db810003 CR4: 00770ef0 Dec 13 11:26:58 fredriksen kernel: PKRU: 5554 Dec 13 11:26:58 fredriksen kernel: Call Trace: Dec 13 11:26:58 fredriksen kernel: Dec 13 11:26:58 fredriksen kernel: intel_ddi_sync_state+0x3f/0x90 [i915] Dec 13 11:26:58 fredriksen kernel: intel_modeset_setup_hw_state+0x3b1/0x1410 [i915] Dec 13 11:26:58 fredriksen kernel: ? _raw_spin_lock_irq+0x19/0x40 Dec 13 11:26:58 fredriksen kernel: ? wait_for_completion+0x91/0x160 Dec 13 11:26:58 fredriksen kernel: ? drm_modeset_lock+0x63/0xd0 [drm] Dec 13 11:26:58 fredriksen kernel: ? ww_mutex_lock+0x14/0x80 Dec 13 11:26:58 fredriksen kernel: ? __intel_display_resume+0x1a/0xe0 [i915] Dec 13 11:26:58 fredriksen kernel: __intel_display_resume+0x1a/0xe0 [i915] Dec 13 11:26:58 fredriksen kernel: intel_display_resume+0xfc/0x140 [i915] Dec 13 11:26:58 fredriksen kernel: i915_drm_resume+0xba/0x130 [i915] Dec 13 11:26:58 fredriksen kernel: ? pci_pm_poweroff_noirq+0x100/0x100 Dec 13 11:26:58 fredriksen kernel: dpm_run_callback+0x47/0x150 Dec 13 11:26:58 fredriksen kernel: device_resume+0x88/0x190 Dec 13 11:26:58 fredriksen kernel: async_resume+0x19/0x30 Dec 13 11:26:58 fredriksen kernel: async_run_entry_fn+0x2d/0x130 Dec 13 11:26:58 fredriksen kernel: process_one_work+0x1c4/0x380 Dec 13 11:26:58 fredriksen kernel: worker_thread+0x4d/0x380 Dec 13 11:26:58 fredriksen kernel: ? rescuer_thread+0x3a0/0x3a0 Dec 13 11:26:58 fredriksen kernel: kthread+0xe6/0x110 Dec 13 11:26:58 fredriksen kernel: ? kthread_complete_and_exit+0x20/0x20 Dec 13 11:26:58 fredriksen kernel: ret_from_fork+0x1f/0x30 Dec 13 11:26:58 fredriksen kernel: Dec 13 11:26:58 fredriksen kernel: ---[ end trace ]--- Dec 13 11:26:58 fredriksen kernel: [ cut here ] Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: drm_WARN_ON(dig_port->tc_lock_wakeref) Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at drivers/gpu/drm/i915/display/intel_tc.c:712 int> Dec 13 11:26:58 fredriksen kernel: Modules linked in: usblp ctr ccm rfcomm cmac algif_hash algif_skcipher af_alg> Dec 13 11:26:58 fredriksen kernel: snd_sof_utils ecdh_generic snd_soc_hdac_hda ecc snd_hda_ext_core snd_soc_acp> Dec 13 11:26:58 fredriksen kernel: configfs
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Fri, Dec 16, 2022 at 07:21:37PM +0100, Adam Borowski wrote: > Package: debian-policy > Version: 4.6.1.1 > Severity: wishlist > > Hi! > As of Bookworm, legacy locales are no longer officially supported. In order > to not break testsuites, they're mostly working if you install locales-all, > and you may manually request their generation by editing /etc/locale.gen -- > but functionality is expected to bit rot and/or be removed in the future. Hi Adam, How do you define a legacy locale ? What do you mean by "officially supported" ? By whom ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#1021341: autopkgtest-build-qemu: add dependency on zerofree
Control: reassign -1 vmdb2/0.25-1 Control: retitle -1 vmdb2: Add dependency on zerofree On 2022-10-06 11:19, Emanuele Rocca wrote: > autopkgtest-build-qemu assumes that zerofree is installed, but it does > not depend on the relevant package. It's actually missing in vmdb2, the utility that autopkgtest uses to build the actual images. > [...] > 2022-09-23 20:26:11 INFO Calling > > 2022-09-23 20:26:11 DEBUG Unmounting /tmp/tmp4a9yk5hg and everything on top > of it > 2022-09-23 20:26:12 DEBUG Finished unmounting /tmp/tmp4a9yk5hg > 2022-09-23 20:26:12 INFO Exec: ['zerofree', '-v', '/dev/mapper/loop0p1'] > 2022-09-23 20:26:12 ERROR [Errno 2] No such file or directory: 'zerofree'
Bug#1017780: Version bump: 1.4.230
Hi Diederik, Quoting Diederik de Haas (2022-12-16 15:57:37) > On Tuesday, 13 December 2022 10:55:18 CET Jonas Smedegaard wrote: > > perhaps I can point you to other examples as well > > I'd love to have several examples to look at :-) > Especially if you know of one (or more) who write extensive commit messages > explaining the reasons/rational of their changes. This should help me get an > understanding of how, what and why to do (packaging) things. Sorry, what I have intimate knowledge on (and therefore can offer to select amongst) are packages that I maintain myself - and while I try hard to make the packaging tight and include comments for unusual details, I almost never write multi-line commit messages. Feel free to ask, and I shall elaborate on details... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#864795: brave-less Debian
On Fri, 16 Dec 2022 08:53:49 + =?UTF-8?B?RGFuaWFsIEJlaHphZGkg2K/Yp9mG24zYp9mEINio2YfYstin2K/bjA==?= wrote: Brave always looked malware to me. Maybe that's why it's always in RFP and there's no ITP. I personally prefer a brave-less Debian. I've come to think the same thing. I suppose more than half of the 'secure' apps/programs/VPNs are really honeypots by the three letter guys. If you use secure setups you probably end up on a list. -- Karl Schmidt EMail k...@lrak.net 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 Few things are more dangerous to humanity than a failed and humiliated ruling class that still clings to power. -kps
Bug#1021728: tracker.debian.org: Please include the new "non-free-firmware" section
Hello Gunnar, On Thu, 13 Oct 2022, Gunnar Wolf wrote: > Last week I uploaded raspi-firmware to non-free-firmware (and was > promptly processed through NEW, whee!). > > Two days ago, it successfully migrated to Texting. > > I am now building the Raspberry Pi images for Bookworm , and > raspi-firmware is correctly downloaded from non-free-firmware. > > However, tracker.debian.org misleadingly shows the package as if it > was removed from Debian («package is gone. This package is not in any > development repository. (...)», and no longer lists it for testing and > unstable. Please update me on the official plans... will this section be entirely disjoint from non-free? Or will packages from non-free-firmware also appear in non-free? Will we move all firmwares from non-free in that new section before the release of bookworm? In any case, I have tweaked the configuration of tracker.debian.org so that it knows (and monitors) that new section in bookworm/sid/experimental at this point. Hopefully that should be sufficient to fix this initial issue. We will have to monitor this for other possible side-effects. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#844741: [ristretto] Segafault when run as root
Using the current version in Debian testing (0.12.3), I can no longer reproduce the bug. Philipp
Bug#1026233: bookkeeper: CVE-2022-32531
Source: bookkeeper X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for bookkeeper. CVE-2022-32531[0]: | The Apache Bookkeeper Java Client (before 4.14.6 and also 4.15.0) does | not close the connection to the bookkeeper server when TLS hostname | verification fails. This leaves the bookkeeper client vulnerable to a | man in the middle attack. The problem affects BookKeeper client prior | to versions 4.14.6 and 4.15.1. https://lists.apache.org/thread/xyk2lfc7lzof8mksmwyympbqxts1b5s9 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-32531 https://www.cve.org/CVERecord?id=CVE-2022-32531 Please adjust the affected versions in the BTS as needed.
Bug#1025176: libicu71 missing on SH4 port
> On Dec 16, 2022, at 7:29 PM, John Paul Adrian Glaubitz > wrote: > > > > >>> On Dec 16, 2022, at 7:18 PM, Jérémy Lal wrote: >>> >> Source: icu >> Followup-For: Bug #1025176 >> X-Debbugs-Cc: debian-sup...@lists.debian.org >> >> Considering the needed porting work is only a few lines: >> https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform >> >> sh4 porters might be able to help here. > > icu or python-greenlet? The former has been built on sh4: Looking at the rest of the bug report The reason why boost1.74 is not up to date is this bug: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016904 The reason why gdb is missing is this bug report: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576242 See also: > https://github.com/glaubitz/binutils-gdb/tree/linux-sh There is no known issue with icu on sh4. Adrian
Bug#1026232: RFP: label-studio -- multi-type data labeling and annotation tool with standardized output format
Package: wnpp Severity: wishlist * Package name: label-studio Version : 1.7.0 Upstream Author : Heartexlabs * URL : https://github.com/heartexlabs/label-studio * License : Apache 2.0 Programming Lang: Python Description : multi-type data labeling and annotation tool with standardized output format Label Studio is an open source data labeling tool. It lets you label data types like audio, text, images, videos, and time series with a simple and straightforward UI and export to various model formats. It can be used to prepare raw data or improve existing training data to get more accurate ML models. In my case I am considering to try it for a project to automate data entry QC (see https://github.com/con/noisseur/issues/1) -- if you know anything like that already, please let me know. Notes: - that git repository is a bit "suboptimal" -- >1GB of .git/objects (likely mistakes made in prior history, checkout tree is only about 200MB with all the docs/ images per each release etc). watchout while cloning, might want a shallow clone
Bug#1025176: libicu71 missing on SH4 port
> On Dec 16, 2022, at 7:18 PM, Jérémy Lal wrote: > > Source: icu > Followup-For: Bug #1025176 > X-Debbugs-Cc: debian-sup...@lists.debian.org > > Considering the needed porting work is only a few lines: > https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform > > sh4 porters might be able to help here. icu or python-greenlet? The former has been built on sh4: > https://buildd.debian.org/status/package.php?p=icu=sid Adrian
Bug#1026213: [Pkg-shadow-devel] Bug#1026213: login: $HOME created as 0755 by default
This would violate POLA and break, among other things already noted, things like fingerd, which wants to run with least-privilege but still access .plan and .project files. Security is a process and requires conscious thought by an administrator, and default permissions on home directories are no different and easily tailored away from the expected defaults. -- Mason Loring Bliss (( If I have not seen as far as others, it is because ma...@blisses.org )) giants were standing on my shoulders. - Hal Abelson
Bug#1026231: debian-policy: document droppage of support for legacy locales
Package: debian-policy Version: 4.6.1.1 Severity: wishlist Hi! As of Bookworm, legacy locales are no longer officially supported. In order to not break testsuites, they're mostly working if you install locales-all, and you may manually request their generation by editing /etc/locale.gen -- but functionality is expected to bit rot and/or be removed in the future. Thus, what about spelling this in the Policy?: * Software may assume they always run in an UTF-8 locale, and emit or require UTF-8 input/output without checking. * The execution environment (usually init system or a container) must default to UTF-8 encoding unless explicitly configured otherwise. * Legacy locales are no longer officially supported, and packages may drop support for them and/or exclude them from their testsuites. * Packages may retain support for legacy locales, but related bug reports (unless security related) are considered to be of wishlist severity. * Filesystems may be configured to reject file names that are not valid printable UTF-8 encoded Unicode. * So-called BOM (U+FEFF) must not be added to plain-text output, and if present, editors/viewers customarily used for editing code should not hide its presence. * Human-readable files outside of packages' private data must be encoded in UTF-8. This applies especially to files in /usr/share/doc and /etc but applies to eg. executable scripts in /bin or /sbin as well. Rationale: it takes non-trivial amount of code to support diverse encodings; Unicode is a strict superset of all legacy charsets thus there's no loss of functionality by switching to it exclusively. In todays Unicode world, text files of other encodings present a barrier to being read by the user. While data received from outside the network may legitimately use legacy locales, requiring all of stdin/stdout/stderr and filesystem data to use UTF-8 would simplify code. It's not like we pay more than lip service to other encodings anymore... While diversity in software is welcome, diversity in standards is not: UTF-8 will not damage your pinky finger nor require Alt-F2 kill -9 to exit; will not make your computer fail to boot or require a trip to the data center; nor infect your K desktop with gnomeitis. [Of course, there's no plausible reason to use Postfix, ever!]. In other words, having multiple phone vendors is essential but having multiple charging connectors is bad. As for BOM, it is explicitly discouraged by the Unicode Consortium, and can cause security vulnerabilities where scripts that pass human review act different than it appears. #!/bin/perl gets executed by bash, and this is just one of examples. As for inits/containers declaring LC_CTYPE=C.UTF-8, systemd has been doing this for a while, in sysvinit land we debated whether that's still needed when glibc started to consider unset locale to mean C.UTF-8 rather than C -- but then, some language compilers do not use glibc. debootstrap doesn't configure a default locale, while not all higher-level tools do so, rendering a system installed in non-standard but reasonable way to lack the setting, to the surprise of the admin. Meow!
Bug#1025176: libicu71 missing on SH4 port
Source: icu Followup-For: Bug #1025176 X-Debbugs-Cc: debian-sup...@lists.debian.org Considering the needed porting work is only a few lines: https://github.com/python-greenlet/greenlet/tree/master/src/greenlet/platform sh4 porters might be able to help here. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1026230: debhelper: Unable to successfully build in read-only source directory.
Package: debhelper
Version: 13.6ubuntu1
Severity: wishlist
Dear Maintainer,
I'm working on a use-case which can be generalized as wanting to be able to
perform a build with debhelper in a read-only source directory. Not simply
that the files themselves are read-only, but that the full directory
tree is read-only. Think of building source from a directory on a CD-ROM,
a NFS mount with read-only permissions, or in my case a Docker container with
the source code on a read-only bind mount.
Many of the required capabilities are already supported. For example, the
--builddirectory flag allows the building step to be placed in a different
directory. The autotools like automake and autoconf support building
out-of-tree. However, I'm left with debhelper and related scripts themselves.
The debhelper scripts are causing a few issues. The immediate issue which has
led me to file this ticket is that debhelper really wants to write log files
into the source directory. This results in an error such as:
dh_autoreconf_clean: error: failed to write to debian/.debhelper.log:
Read-only file system
I tried to work around this by hacking up the debhelper scripts in the Docker
image by doing:
RUN sed -i -e
's!"debian/${ext}debhelper.log"!"/working/debian/${ext}debhelper.log"!g'
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm
RUN sed -i -e 's!debian/\*.debhelper.log!/working/debian/\*.debhelper.log!g'
/usr/share/perl5/Debian/Debhelper/SequencerUtil.pm
RUN sed -i -e 's!debian/\*.debhelper.log!/working/debian/\*.debhelper.log!g'
/usr/bin/dh_clean
This failed because the script was unable to find the log file to delete, with
error message:
dh_autoreconf_clean: error: failed to write to
/working/debian/.debhelper.log: No such file or directory
The changes required are clearly more extensive than a little string
substitution. And if the work involved is going to be extensive, it should
probably be handled by someone with knowledge of (and the wisdom to) alter the
architecture as well.
One other possibly-related item of note (I can file a separate bug if you like)
and which may have an existing solution:
Passing in --buildinfo-option=-u/out still results in a -O option which
refers to the wrong directory. That is, I get the following:
dpkg-genbuildinfo -u/out --build=binary
-O../_2.0.6-1_amd64.buildinfo
dpkg-genbuildinfo: error: cannot write
../_2.0.6-1_amd64.buildinfo.new: Permission denied
This resulted from an experiment where I was copying the source code to a
temporary directory with read/write permissions, but where the parent
directory was not writable.
Thank you for your time,
- Garrett
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Bug#1026229: efibootguard: missing Breaks+Replaces: libebgenv-dev (<< 0.12-2)
Package: efibootguard Version: 0.12-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../efibootguard_0.12-2_amd64.deb ... Unpacking efibootguard (0.12-2) ... dpkg: error processing archive /var/cache/apt/archives/efibootguard_0.12-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/efibootguard/efibootguardx64.efi', which is also in package libebgenv-dev 0.12-1+b1 Errors were encountered while processing: /var/cache/apt/archives/efibootguard_0.12-2_amd64.deb cheers, Andreas libebgenv-dev=0.12-1+b1_efibootguard=0.12-2.log.gz Description: application/gzip
Bug#1026228: emacs-common 1:28.2+1-8 and emacs-bin-common 1:27.1+1-3.1+b1 both contain /usr/lib/systemd/user/emacs.service
Package: emacs-common Version: 1:28.2+1-8 Upgrading emacs from 27.1 to 28.2 today on my debian testing system, i ran into this problem with the upgrade: Unpacking emacs-common (1:28.2+1-8) over (1:27.1+1-3.1) ... dpkg: error processing archive /tmp/apt-dpkg-install-nVWWVc/05-emacs-common_1%3a28.2+1-8_all.deb (--unpack): trying to overwrite '/usr/lib/systemd/user/emacs.service', which is also in package emacs-bin-common 1:27.1+1-3.1+b1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) this eventually caused "apt upgrade" to fail, but a subsequent "apt -f install" succeeded without issue, presumably because emacs-bin-common had also already been upgraded to 1:28.2+1-8 in the meantime. Moving a file from one package to another should be done more cautiously, along these lines: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces Thanks for maintaining emacs in debian! --dkg signature.asc Description: PGP signature
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
Followup-For: Bug #1012890 Control: found -1 13~beta3-1~exp1 Hi, I now see this failure while building android-platform-frameworks-base/experimental: clang++ -c -o libs/androidfw/LoadedArsc.o libs/androidfw/LoadedArsc.cpp -g -O2 -ffile-prefix-map=/build/android-platform-frameworks-base-13~beta3=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -std=gnu++17 -Wno-missing-field-initializers -Wunreachable-code -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -UDEBUG -I/usr/include/android -Wno-c99-designator -Wno-gnu-designator -Wno-gnu-folding-constant -fmessage-length=0 -fno-exceptions -fno-strict-aliasing -no-canonical-prefixes -DSTATIC_ANDROIDFW_FOR_TOOLS -Ilibs/androidfw/include In file included from libs/androidfw/LoadedArsc.cpp:19: In file included from libs/androidfw/include/androidfw/LoadedArsc.h:20: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/map:60: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_tree.h:63: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_algobase.h:66: /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_iterator_base_funcs.h:192:2: error: cannot decrement value of type 'android::incfs::map_ptr::const_iterator' --__i; ^ ~~~ /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_iterator_base_funcs.h:222:12: note: in instantiation of function template specialization 'std::__advance::const_iterator, long>' requested here std::__advance(__i, __d, std::__iterator_category(__i)); ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_algobase.h:1462:9: note: in instantiation of function template specialization 'std::advance::const_iterator, long>' requested here std::advance(__middle, __half); ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_algo.h:2004:19: note: in instantiation of function template specialization 'std::__lower_bound::const_iterator, unsigned short, __gnu_cxx::__ops::_Iter_comp_val<(lambda at libs/androidfw/LoadedArsc.cpp:255:36)>>' requested here return std::__lower_bound(__first, __last, __val, ^ libs/androidfw/LoadedArsc.cpp:254:24: note: in instantiation of function template specialization 'std::lower_bound::const_iterator, unsigned short, (lambda at libs/androidfw/LoadedArsc.cpp:255:36)>' requested here auto result = std::lower_bound(sparse_indices, sparse_indices_end, entry_index, ^ 1 error generated. make[2]: *** [debian/libandroidfw.mk:57: libs/androidfw/LoadedArsc.o] Error 1 Andreas
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
* Sébastien Villemot [2022-12-16 16:26]: In the current system, in which the BLAS and LAPACK implementation are decided through the alternatives system, it’s not possible to solve the problem through versioned provides. Because even if the dependency on the versioned provides is satisfied, this does not prevent another flavour of LAPACK (not satisfying the dependency) to be installed and selected through the alternatives system. I think those alternatives names would need to be per ABI version (of the virtual package) anyhow. So indeed the only clean way of solving this issue seems to forbid coinstallability of several BLAS or LAPACK flavours. But the latter is considered as a feature, not as a bug. I agree that using the alternatives system for a shared library is a bit ugly and does not play well with our tooling, but that’s a choice that was made long ago and it also brings some flexibility for the user (it’s easy to switch from one implementation to the other). Is ease of switching the only reason for using the alternatives system here? Maybe we should rethink this decision as it really does not play well with our tooling and you could just as well use apt to switch the implementation. Cheers Jochen signature.asc Description: PGP signature
Bug#999724: ruby-omniauth-salesforce: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencie
Followup-For: Bug #999724 Control: found -1 1.0.5-3 The version in sid now fails with Could not find 'omniauth' (~> 1.0) - did find: [omniauth-2.1.0] and the version in experimental fails with Could not find 'omniauth-oauth2' (~> 1.7.1) - did find: [omniauth-oauth2-1.8.0] Andreas
Bug#1026227: vagrant: Uninstallable in sid with VirtualBox 7.0.x
Package: vagrant Version: 2.2.19+dfsg-2 Severity: serious Hi! Since virtualbox 7.0.4 got uploaded, vagrant is no longer installable in Debian sid. I assume this will require packaging a new upstream release to support the new virtualbox version 7.0.x series. Thanks, Guillem
Bug#975326: dash: inconsistency between ulimit -r and ulimit -a
Control: tags -1 + upstream patch Control: forwarded -1 https://lore.kernel.org/dash/20221216172019.upb425kmpx75e...@tarta.nabijaczleweli.xyz/t/ Your analysis is right, this is oddly missing from the original addition of ulimit -r in 2012. Forwarded the diff to dash@, archived at forwarded-to. наб signature.asc Description: PGP signature
Bug#1026226: emacs: Emacs ignores extended file attributes (xattr)
Package: emacs Version: 1:28.2+1-8 Severity: normal Dear Maintainer, If a file has extended attributes and is edited with Emacs, the extended attributes are lost. The easiest and most common way to do this is to assign keywords, comments or ratings to a file with the file manager Dolphin* and then open this file with Emacs and change it so that it can be "written" under the same name. (* Or alternatively: setfattr -n user.xdg.tags -v "keyword") On the homepage of Emacs I think I read that Emacs can handle extended attributes. This is obviously still not the case here. However, should this behavior be desired in the form, consider this letter as irrelevant. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs depends on: ii emacs-gtk 1:28.2+1-8 emacs recommends no packages. emacs suggests no packages. -- debconf-show failed
Bug#1026225: /bin/cp: "cp update" ignores "extended attributes".
Package: coreutils Version: 9.1-1 Severity: normal File: /bin/cp Dear Maintainer, "cp update" ignores "extended attributes". The underlying "cp" command reads: #+begin_src sh \cp --preserve=all --reflink=always -au #+end_src If an attribute is subsequently changed or newly set in the source file, e.g. the "user.baloo.rating" with KDE's Dophin, this change is not recognized by "cp". -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages coreutils depends on: ii libacl1 2.3.1-2 ii libattr1 1:2.5.1-3 ii libc62.36-6 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libselinux1 3.4-1+b3 coreutils recommends no packages. coreutils suggests no packages. -- debconf-show failed
Bug#1026205: Unpaper errors for every scanned page
Thanks for the report. On 16/12/2022 11:05, martin f krafft wrote: for every page processed by unpaper, I get two errors: 1. [image2 @ 0x558772ceee40] The specified filename '/home/ssd/madduck/.tmp/gscan2pdf-SMFz/OHSkXwKy5v.pnm' does not contain an image sequence pattern or a pattern is invalid. 2. [image2 @ 0x558772ceee40] Use a pattern such as %03d for an image sequence or use the -update option (with -frames:v 1 if needed) to write a single image. I think that this is this bug in unpaper: https://github.com/unpaper/unpaper/issues/113 OpenPGP_signature Description: OpenPGP digital signature
Bug#1026224: live-build: Option "-b netboot" fails on arm64 architecture
Package: live-build Version: 1:20220505 Severity: normal X-Debbugs-Cc: deb...@jugra.de Dear Maintainer, lb config -d bookworm --chroot-filesystem squashfs --apt-indices false --cache-packages false --config https://gitlab.x2go.org/x2go/live-build-x2go.git::feature/bookworm-fvwm --archive-areas "main contrib non-free" --apt-recommends false --firmware-binary false --updates true --backports false --win32-loader false --loadlin false --security false --initsystem systemd -b netboot --bootappend-live toram live-config lb build run through on amd64 architecture, but fails with following error on arm64: [2022-12-15 02:11:12] lb binary_netboot P: Begin building binary netboot image... mv: cannot stat 'tftpboot': No such file or directory E: An unexpected failure occurred, exiting... P: Begin unmounting filesystems... P: Saving caches... Best Regards, Juri Grabowski
Bug#1026223: golang-github-google-cel-spec: switch B-D to golang-github-golang-protobuf-1-5-dev
Source: golang-github-google-cel-spec Version: 0.5.1-1 Severity: serious golang-github-google-cel-spec/experimental has a B-D: golang-goprotobuf-dev (>= 1.4.3~) which is no longer available but has been superseded by golang-github-golang-protobuf-1-5-dev. Andreas
Bug#1026131: Merging and marking as closed
Control: forcemerge 1025838 -1 Hello, This is the same as #1025838, which version 1.11.9+dfsg-3 properly closes. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1026222: golang-google-genproto: switch B-D to golang-github-golang-protobuf-1-5-dev
Source: golang-google-genproto Version: 0.0~git20210726.e7812ac-1~exp0 Severity: serious golang-google-genproto/experimental has a B-D: golang-goprotobuf-dev (>= 1.4.1~) which is no longer available but has been superseded by golang-github-golang-protobuf-1-5-dev. Andreas
Bug#1026221: rust-sequoia-octopus-librnp: B-D on no longer available librust-libgit2-sys-0.12+default-dev
Source: rust-sequoia-octopus-librnp Version: 1.4.1-1 Severity: serious Tags: ftbfs Justification: fails to build from source Hi, rust-sequoia-octopus-librnp/experimental has a no longer satisfiable Build-Depends: librust-libgit2-sys-0.12+default-dev librust-libgit2-sys-dev now provides (among others) librust-libgit2-sys+default-dev (= 0.13.2-2) librust-libgit2-sys-0+default-dev (= 0.13.2-2) librust-libgit2-sys-0.13+default-dev (= 0.13.2-2) librust-libgit2-sys-0.13.2+default-dev (= 0.13.2-2) Andreas
Bug#811087: qemu-user-static: qemu-arm-static segfaults in armhf chroot on 'aptitude -u'
Control: tag -1 + confirmed upstream patch Control: forwarded -1 https://lore.kernel.org/qemu-devel/20221216152006.2838195-1-...@msgid.tls.msk.ru/T Just sent a patch fixing this issue to the qemu list. /mjt
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Le vendredi 16 décembre 2022 à 13:47 +0100, Jochen Sprickerhof a
écrit :
> Hi Sébastien,
>
> * Sébastien Villemot [2022-12-16 10:30]:
> > Le jeudi 15 décembre 2022 à 21:16 +0100, Paul Gevers a écrit :
> > > On 13-12-2022 21:59, Sébastien Villemot wrote:
> > > > The problem is that atlas needs to be recompiled against lapack 3.11.0.
> > > > Which has been done in atlas 3.10.3-13. But atlas itself cannot migrate
> > > > to testing because of #1025699.
> > >
> > > While I understand recompiling "solves" the issue, normally this error
> > > "undefined reference" hints at removal of symbols. Normally that should
> > > be handled by a SONAME bump which would trigger auto trackers to be
> > > generated for the transition. Such trackers notify the release team of
> > > transitions and they can trigger rebuilds (you know that drill,
> > > including the transition bug filing for coordination). Why do you think
> > > that a SONAME bump wasn't the right solution in this case?
> >
> > Actually the error is not due to a symbol removed, but to a symbol
> > *added*. So no SONAME bump is warranted.
> >
> > Let me explain:
> >
> > In lapack 3.11.0, several new symbols ({z,c,d,s}trsyl3_) were added to
> > liblapack.so.3 (a linear algebra library with a Fortran interface).
> > As a consequence, new wrapper functions around these symbols were also
> > added to liblapacke.so.3 (note the “e”), which is a C wrapper around
> > liblapack.so.3, and which is also shipped by src:lapack. Hence the
> > latest liblapacke.so.3 depends on the new symbols in liblapack.so.3.
> >
> > Now, libatlas3-base (compiled from src:atlas) also provides its own
> > version of liblapack.so.3 (through the alternatives system¹). But,
> > until it is recompiled against lapack 3.11.0, that version of
> > liblapack.so.3 does not contain the new symbols. Hence, when
> > liblapack.so.3 is provided by libatlas3-base, loading liblapacke.so.3
> > produces the error that is seen in the failing test.
> >
> > Essentially, what is missing is a restriction which would forbid the
> > co-installation of liblapacke ⩾ 3.11 and libatlas3-base compiled
> > against lapack < 3.11. I don’t know how to express that using our
> > tooling, but maybe I’m unimaginative.
>
> I think you can get that with a virtual abi package, something like:
>
> Provides: libblas-abi (= 3.11)
>
> And have downstream packages shlibs depend on that virtual package:
>
> override_dh_makeshlibs:
> dh_makeshlibs -plibfoo -V 'libblas-abi (= 3.11)'
> dh_makeshlibs --remaining-packages
>
> Maybe also add a:
>
> Conflicts: libblas-abi (= 3.11)
>
> So only one lib can be installed at the same time and drop the
> alternatives system.
In the current system, in which the BLAS and LAPACK implementation are
decided through the alternatives system, it’s not possible to solve the
problem through versioned provides. Because even if the dependency on
the versioned provides is satisfied, this does not prevent another
flavour of LAPACK (not satisfying the dependency) to be installed and
selected through the alternatives system.
So indeed the only clean way of solving this issue seems to forbid
coinstallability of several BLAS or LAPACK flavours. But the latter is
considered as a feature, not as a bug. I agree that using the
alternatives system for a shared library is a bit ugly and does not
play well with our tooling, but that’s a choice that was made long ago
and it also brings some flexibility for the user (it’s easy to switch
from one implementation to the other).
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1026216: pkg-conf: breaking build with latest m4 fixes
Hi, On Fri, 16 Dec 2022, at 15:12, Gianfranco Costamagna wrote: > Source: pkgconf > Version: 1.8.0-11 > Severity: serious > Forwarded: https://github.com/pkgconf/pkgconf/issues/260 > > Hello, after the change in > https://github.com/pkgconf/pkgconf/commit/8d9d3de6eb8f0ffdbb859fce79cff89038e513c4 > The pkg-config automake module is broken if the pkg-config is called > with multiple parameters. > See the upstream ticket for more information. > > thanks for considering disabling patch > debian/patches/pkg.m4/0002-pkg.m4-PKG_CHECK_MODULES-provides-modversion.patch > for now Thanks for reporting. Disabling it now. -- Cheers, Andrej
Bug#1026220: graphicsmagick: Missing JPEG XL support
Package: graphicsmagick Version: 1.4+really1.3.38+hg16870-1 Severity: normal Dear Maintainer, according to: http://www.graphicsmagick.org/formats.html GraphicsMagick'd support JPEG XL format, but it's missing in Debian packaged version. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:it Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages graphicsmagick depends on: ii libc62.36-6 ii libgraphicsmagick-q16-3 1.4+really1.3.38+hg16870-1 graphicsmagick recommends no packages. Versions of packages graphicsmagick suggests: pn graphicsmagick-dbg -- no debconf information
Bug#1017780: Version bump: 1.4.230
Hi Jonas, On Tuesday, 13 December 2022 10:55:18 CET Jonas Smedegaard wrote: > perhaps I can point you to other examples as well I'd love to have several examples to look at :-) Especially if you know of one (or more) who write extensive commit messages explaining the reasons/rational of their changes. This should help me get an understanding of how, what and why to do (packaging) things. TIA, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1026219: FTBFS: ruby-nokogiri fails to build
Package: ruby-nokogiri Version: 1.13.8+dfsg-1 The package fails to build due to the `test_large_cdata_is_handled` test failure. The test fails because https://tracker.debian.org/pkg/libxml2 had a security patch upload that hides handling huge data behind a flag (also see upstream https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.10.3). The flag (XML_PARSE_HUGE) is listed in https://gnome.pages.gitlab.gnome.org/libxml2/devhelp/libxml2-parser.html#xmlParserOption and can be set in the context using the corresponding function https://gitlab.gnome.org/GNOME/libxml2/-/blob/master/parser.c#L14949. -- Regards, Andrey
Bug#1026218: ITP: python3-scrape-schema-recipe -- extracts cooking recipe from HTML structured data
Package: wnpp Severity: wishlist Owner: Christian Marillat X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python3-scrape-schema-recipe Version : 0.2.0 Upstream Contact: Micah Cochra * URL : https://github.com/micahcochran/scrape-schema-recipe * License : Apache-2.0 Programming Lang: Python Description : extracts cooking recipe from HTML structured data Scrapes recipes from HTML https://schema.org/Recipe (Microdata/JSON-LD) into Python dictionaries. This python module is needed by gourmand to import recipes from internet.
Bug#1026213: [Pkg-shadow-devel] Bug#1026213: login: $HOME created as 0755 by default
On Fri, Dec 16, 2022 at 04:14:56PM +0300, Michael Tokarev wrote: > On Fri, 16 Dec 2022 11:50:18 + debian user wrote: > > Package: login > > Version: 1:4.13+dfsg1-1 > > Severity: grave > > Tags: security > > Justification: user security hole > > X-Debbugs-Cc: r...@localhost.lan, Debian Security Team > > > > > > Dear Maintainer, > > > > please uncomment the line in /etc/login.defs that currently says: > > > > #HOME_MODE 0700 > > > > to say: > > > > HOME_MODE 0700 > > > > The current settings makes user $HOME directories be created with > > permissions where other users can read the contents by default. > > I tend to disagree, the default is just fine, all the sensitive > data (eg, .bash_history, .ssh/ etc) is already protected, there's > absolutely nothing wrong if the files in home dirs are accessible > by default, - for example my users complain if they can't show content > of their own files to other users by default. On the other hand, > it is trivial to uncomment the HOME_MODE setting locally if the local > policy is that users should be paranoid against each other. It is > just as easy to set perms of your own home dir at any time, too. > > /mjt Agreed with mjt. As an example, unprivileged containers cannot be started if your subuids cannot at least 'x' $HOME. And in all the systems I set up to share with family/friends I want to encourage not limit sharing. -serge
Bug#1026217: libunwind 1.6.2-2.1 assumes 4k page sizes and crashes on systems with bigger page sizes
Package: libunwind8 Version: 1.6.2-2.1 Severity: important Tags: patch X-Debbugs-Cc: as...@lists.linux.dev Hello, the recent libunwind8 update 1.6.2-2.1 breaks for architectures which have a pagesize bigger than 4096 on arm64. The issue is fixed upstream. But no release has been made with the patch included. libunwind8 1.6.2-2.1 crashes Xorg on startup for systems with a pagesize bigger than 4096 on arm64. Linux on apple silicon (m1/m2) uses a 16 KB page size. https://github.com/libunwind/libunwind/commit/2d004eafc77f3c6a4bd9a44b1c35735273fd4e97 Please apply the above patch. Cheers, Thomas -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-asahi (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libunwind8 depends on: ii libc6 2.36-6 ii liblzma5 5.2.9-0.0 libunwind8 recommends no packages. libunwind8 suggests no packages. -- no debconf information
Bug#1026216: pkg-conf: breaking build with latest m4 fixes
Source: pkgconf Version: 1.8.0-11 Severity: serious Forwarded: https://github.com/pkgconf/pkgconf/issues/260 Hello, after the change in https://github.com/pkgconf/pkgconf/commit/8d9d3de6eb8f0ffdbb859fce79cff89038e513c4 The pkg-config automake module is broken if the pkg-config is called with multiple parameters. See the upstream ticket for more information. thanks for considering disabling patch debian/patches/pkg.m4/0002-pkg.m4-PKG_CHECK_MODULES-provides-modversion.patch for now G. OpenPGP_signature Description: OpenPGP digital signature
Bug#811087: qemu-user-static: qemu-arm-static segfaults in armhf chroot on 'aptitude -u'
On Sun, 14 Feb 2021 21:29:20 +0100 Andreas Beckmann wrote:
Version: 1:5.2+dfsg-3~bpo10+1
On 2/14/21 4:46 PM, Michael Tokarev wrote:
> Before I was able to hit this issue with almost any invocation of aptitude.
> But in 5.0 or current 5.2 I can't reproduce this issue anymore, now matter
> how I try.
a simple 'aptitude -u' does the job for me :-(
The core file I get inside the chroot is actually from the qemu binary on the
host,
perhaps this backtrace helps:
Reading symbols from /usr/bin/qemu-aarch64-static...Reading symbols from
/usr/lib/debug/.build-id/30/efd3930fb9519b21470b113679376f2ffbb41a.debug...done.
done.
warning: core file may not match specified executable file.
[New LWP 23784]
[New LWP 23772]
[New LWP 23774]
[New LWP 23777]
[New LWP 23776]
[New LWP 23775]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/qemu-aarch64-static /usr/bin/aptitude -u'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0059a1eb in getgroups (__list=0x7f867be79cc0, __size=65536) at
/usr/include/x86_64-linux-gnu/bits/unistd.h:275
This comes from the following code, linux-user/syscall.c:11757 in qemu version
7.2:
case TARGET_NR_getgroups32:
{
int gidsetsize = arg1;
uint32_t *target_grouplist;
gid_t *grouplist;
int i;
grouplist = alloca(gidsetsize * sizeof(gid_t));
11757 ret = get_errno(getgroups(gidsetsize, grouplist));
gidsetsize as coming from aptitude is 65536. Grouplist is allocated on the
stack...
/mjt
Bug#1022068: Still found
found 1022068 6.1~rc8-1~exp1 upstream 1022068 https://gitlab.freedesktop.org/drm/nouveau/-/issues/188 thanks Still in latest experimental kernel. :-( I've found an upstream bug (every distro affected). Cheers -- Mathieu
Bug#1026213: login: $HOME created as 0755 by default
On Fri, 16 Dec 2022 11:50:18 + debian user wrote: Package: login Version: 1:4.13+dfsg1-1 Severity: grave Tags: security Justification: user security hole X-Debbugs-Cc: r...@localhost.lan, Debian Security Team Dear Maintainer, please uncomment the line in /etc/login.defs that currently says: #HOME_MODE 0700 to say: HOME_MODE 0700 The current settings makes user $HOME directories be created with permissions where other users can read the contents by default. I tend to disagree, the default is just fine, all the sensitive data (eg, .bash_history, .ssh/ etc) is already protected, there's absolutely nothing wrong if the files in home dirs are accessible by default, - for example my users complain if they can't show content of their own files to other users by default. On the other hand, it is trivial to uncomment the HOME_MODE setting locally if the local policy is that users should be paranoid against each other. It is just as easy to set perms of your own home dir at any time, too. /mjt
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Hi Sébastien,
* Sébastien Villemot [2022-12-16 10:30]:
Le jeudi 15 décembre 2022 à 21:16 +0100, Paul Gevers a écrit :
On 13-12-2022 21:59, Sébastien Villemot wrote:
> The problem is that atlas needs to be recompiled against lapack 3.11.0.
> Which has been done in atlas 3.10.3-13. But atlas itself cannot migrate
> to testing because of #1025699.
While I understand recompiling "solves" the issue, normally this error
"undefined reference" hints at removal of symbols. Normally that should
be handled by a SONAME bump which would trigger auto trackers to be
generated for the transition. Such trackers notify the release team of
transitions and they can trigger rebuilds (you know that drill,
including the transition bug filing for coordination). Why do you think
that a SONAME bump wasn't the right solution in this case?
Actually the error is not due to a symbol removed, but to a symbol
*added*. So no SONAME bump is warranted.
Let me explain:
In lapack 3.11.0, several new symbols ({z,c,d,s}trsyl3_) were added to
liblapack.so.3 (a linear algebra library with a Fortran interface).
As a consequence, new wrapper functions around these symbols were also
added to liblapacke.so.3 (note the “e”), which is a C wrapper around
liblapack.so.3, and which is also shipped by src:lapack. Hence the
latest liblapacke.so.3 depends on the new symbols in liblapack.so.3.
Now, libatlas3-base (compiled from src:atlas) also provides its own
version of liblapack.so.3 (through the alternatives system¹). But,
until it is recompiled against lapack 3.11.0, that version of
liblapack.so.3 does not contain the new symbols. Hence, when
liblapack.so.3 is provided by libatlas3-base, loading liblapacke.so.3
produces the error that is seen in the failing test.
Essentially, what is missing is a restriction which would forbid the
co-installation of liblapacke ⩾ 3.11 and libatlas3-base compiled
against lapack < 3.11. I don’t know how to express that using our
tooling, but maybe I’m unimaginative.
I think you can get that with a virtual abi package, something like:
Provides: libblas-abi (= 3.11)
And have downstream packages shlibs depend on that virtual package:
override_dh_makeshlibs:
dh_makeshlibs -plibfoo -V 'libblas-abi (= 3.11)'
dh_makeshlibs --remaining-packages
Maybe also add a:
Conflicts: libblas-abi (= 3.11)
So only one lib can be installed at the same time and drop the
alternatives system.
Cheers Jochen
signature.asc
Description: PGP signature
Bug#1026215: python3-openssl: Fails using deprecated SSL_CTX_set_ecdh_auto which ultimately has been removed w/ p-cryptography 38
Package: python3-openssl Version: 21.0.0-1 Severity: important Dear Maintainer, since p-cryptography 38 hit unstable, this fails somewhere here File "/usr/lib/python3/dist-packages/OpenSSL/SSL.py", line 674, in __init__ using SSL_CTX_set_ecdh_auto, which is deprecated w/ at least openssl3 afaiu, and python3-cryptography 38 seem to to have that binding now removed for good. Newest release versions of pyopenssl have this depcrecated call just removed, so maybe updating upstream is the way to go here. Hth, and thanks! Stephan -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages python3-openssl depends on: ii python3 3.10.6-3 ii python3-cryptography 38.0.4-1 ii python3-six 1.16.0-4 python3-openssl recommends no packages. Versions of packages python3-openssl suggests: pn python-openssl-doc pn python3-openssl-dbg -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/python3/dist-packages/OpenSSL/SSL.py (from python3-openssl package)
Bug#1006179: [Pkg-clamav-devel] Bug#1006179: Bug#1006179: Bug#1006179: Bug#1006179: ClamAV 1.0.0 release candidate now available
On Tue, 13 Dec 2022, Sebastian Andrzej Siewior wrote: On 2022-12-12 22:45:57 [-0500], Scott Kitterman wrote: That doesn't sound too bad. I'll see if I can find some time to work on the split, but probably not until Wednesday or Friday. So I managed to tell cmake to use the tfm library instead of the bundled code and the testsuite fails now but I think this is due to the limit in "our" libtfm. I noticed libclammspack/libclammspack.so which appears to be the libmspack and I hope that this is a typo somewhere and we can exclude the bundled library. INSTALL.md lists a CMake option ENABLE_EXTERNAL_MSPACK so there should be no problem there. Then I had to throw up a little. It might me be nothing and I'm just stupid and don't know things but there is a lot of rust code in libclamav_rust/.cargo/vendor/ and it appears to me that they bundled a bunch of rust libraries. It *might* be enough to just install librust-jpeg-decoder-dev as dependency and then libclamav_rust/.cargo/vendor/jpeg-decoder will be ignored but I just wanted point that out. I don't have any rust skills at this time. ClamAV are moving towards Rust being a major part of the project. https://docs.clamav.net/faq/faq-rust.html Sadly, from our point of view, they use cpack (part of cmake) to build their .deb (and .rpm) packages rather than a "debian" tree. They also use an in-house tool - Mussels https://blog.clamav.net/2019/12/introducing-mussels-application.html to manage library dependencies. Not sure whther this will be an issue. CMakeLists.txt has set(LLVM_MAX_VER "13") set(LLVM_MIN_VER "8") I don't know about Debian, but Ubuntu Kinetic/22.10 has LLVM v15 by default. We can hope that 13 is not a hard limit, just that it is the latest tested version ... -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk
Bug#1026165: cmd2: diff for NMU version 2.4.2+ds-3
Control: tags 1026165 + patch
Control: tags 1026165 + pending
Dear maintainer,
I've prepared an NMU for cmd2 (versioned as 2.4.2+ds-3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru cmd2-2.4.2+ds/debian/changelog cmd2-2.4.2+ds/debian/changelog
--- cmd2-2.4.2+ds/debian/changelog 2022-09-12 10:16:17.0 +0200
+++ cmd2-2.4.2+ds/debian/changelog 2022-12-16 12:59:38.0 +0100
@@ -1,3 +1,16 @@
+cmd2 (2.4.2+ds-3) unstable; urgency=medium
+
+ * Team upload.
+
+ [ Debian Janitor ]
+ * Remove constraints unnecessary since buster
+ * Trim trailing whitespace.
+
+ [ Jochen Sprickerhof ]
+ * Drop unused build dependency (Closes: #1026165)
+
+ -- Jochen Sprickerhof Fri, 16 Dec 2022 12:59:38 +0100
+
cmd2 (2.4.2+ds-2) unstable; urgency=medium
* Team upload.
@@ -37,7 +50,7 @@
- Removed line without effect: rm -f tests/scripts/binary.bin
- Remove doctrees files to documentation sphinx
- Remove all file '.js' sphinx documentation
- - Iclude test Ignore: test_utils.py
+ - Iclude test Ignore: test_utils.py
* debian/source:
- Remove lintian-overrides
* debian/watch:
diff -Nru cmd2-2.4.2+ds/debian/control cmd2-2.4.2+ds/debian/control
--- cmd2-2.4.2+ds/debian/control 2022-09-11 16:54:15.0 +0200
+++ cmd2-2.4.2+ds/debian/control 2022-12-15 16:36:32.0 +0100
@@ -6,7 +6,6 @@
Build-Depends-Indep: dh-python,
python3-all,
python3-attr,
- python3-contextlib2,
python3-pyperclip,
python3-pytest,
python3-pytest-cov,
@@ -24,13 +23,11 @@
Package: python3-cmd2
Architecture: all
-Pre-Depends: dpkg (>= 1.15.6~)
Depends: python3-wcwidth,
${misc:Depends},
${python3:Depends},
Recommends: ${python3:Recommends}
Provides: ${python3:Provides}
-Breaks: python3-pyperclip (<< 1.6.0-1)
Suggests: python-cmd2-doc
Description: Enhanced Python cmd module - Python 3.x
Drop-in replacement adds several features for command-prompt tools, like
signature.asc
Description: PGP signature
Bug#968495: ITP: c-evo-dh -- C-evo: Distant Horizon, Empire building game
New Upstream version * Package name : c-evo-dh Version : 1.6.0-1 Upstream contact : Peter * URL : https://sourceforge.net/projects/c-evo-eh/ * License : CC-BY-3.0, CC-BY-SA-3.0-US, CC0-1.0, GPL-2+ * Vcs : https://salsa.debian.org/PeterB/c-evo-dh Section : games Changes since 1.1 c-evo-dh (1.6) Restore CityType drag cursor (lost with Lazarus 2.2.0) Remove binary cursor files Change package & folder names from c-evo to c-evo-dh Update Docs -- Wed, 14 Dec 2022 c-evo-dh (1.5) More fixes to internationalisations (es, de, it, pt, ru) Update Appstream metadata Remove example maps that have missing special resources -- Mon, 12 Dec 2022 c-evo-dh (1.4) Fixes to internationalisation of in game help -- Sun, 11 Dec 2022 c-evo-dh (1.3) Fixes to Windows build Include Spanish and Portuguese translations -- Sun, 04 Dec 2022 c-evo-dh (1.2) Reduce Spaceship costs to 50% of original Support random resource placement by external map generators Include Windows build Remove example game (incompatible due to Spaceship costs) -- Tue, 27 Sep 2022
Bug#1026214: libpcre3: Lower Priority
Package: libpcre3 Severity: important Version: 2:8.39-14 libpcre3 and libpcre3-udeb have Priority: important. They are considered obsolete, so please lower their priority to optional so they are not necessarily installed on a standard installation.
Bug#1026213: login: $HOME created as 0755 by default
Package: login Version: 1:4.13+dfsg1-1 Severity: grave Tags: security Justification: user security hole X-Debbugs-Cc: r...@localhost.lan, Debian Security Team Dear Maintainer, please uncomment the line in /etc/login.defs that currently says: #HOME_MODE 0700 to say: HOME_MODE 0700 The current settings makes user $HOME directories be created with permissions where other users can read the contents by default. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages login depends on: ii libaudit1 1:3.0.7-1.1+b2 ii libc6 2.36-6 ii libcrypt1 1:4.4.33-1 ii libpam-modules 1.5.2-5 ii libpam-runtime 1.5.2-5 ii libpam0g1.5.2-5 login recommends no packages. login suggests no packages. -- no debconf information
Bug#828903: auditd embeds a copy of libev
Am 16.12.22 um 12:20 schrieb Laurent Bigonville: Do you think you could bring that upstream? Usually, projects have their reasons to vendor libraries (mostly, convenience or CI-related). The patch is not complete in the sense that it still reads the .m4 file from the vendored library. So I do not think this has a high chance to be considered for upstream inclusion. However, I can try to hand in one that gets rid of the vendoring completely (not happening in a timeframe before bookworm freeze). If you do not want to include the patch for now then please at least make sure the embedded libev is registered with the Security Team.
Bug#1026212: FTBFS: haskell-wide-word fails to build on i386
Package: haskell-wide-word Version: 0.1.1.2-3 Package fails to build on i386 due to using platform-specific type aliases. There is a new version available on https://hackage.haskell.org/package/wide-word which starts to use explicit types in https://hackage.haskell.org/package/wide-word-0.1.3.0/src/src/Data/WideWord/Compat.hs (e.g. see plusWord# implementation). Reproducibility logs: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/i386/haskell-wide-word.html -- Regards, Andrey
Bug#828903: auditd embeds a copy of libev
Hello, Le 15/12/22 à 17:08, Bastian Germann a écrit : On Tue, 28 Jun 2016 22:28:07 +0200 Nicolas Braud-Santoni wrote: The audit source package ships a (custom, patched) copy of libev. Moreover, it is not listed in the security team's list of code copies: https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=markup I discovered the issue while preparing a DEP5 copyright file for the audit source package, and more generally fixing all Lintian warnings while preparing a patch for #759604. I think this is an important issue and have included a patch. Would you please consider to apply this before the bookworm freeze? Do you think you could bring that upstream? Not sure we want to carry this patch forever
Bug#1026211: RM: astap [mipsel] -- ROM; FTBFS on mipsel
Package: ftp.debian.org Severity: normal The pascal compiler seems to have a problem on mipsel, so please remove this package from that architecture for now. Thorsten
Bug#1026210: scipy: autopkgtest regression due to invalid test function returns
Source: scipy Version: 1.8.1-14 Severity: serious Control: affects -1 src:pytest -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainers, the autopkgtest of your package started failing because some of the tests return values. This has always been incorrect (tests are expected to assert, not return anything), but recently, pytest 7.2 started issuing warnings [1], which are turned into hard errors by your pytest.ini filterwarnings directive. Cheers Timo [1] https://docs.pytest.org/en/7.2.x/deprecations.html#returning-non-none-value-in-test-functions -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmOcTDIACgkQ+C8H+466 LVl98AwAk1Wnpwkl+NU8uNXM8gtiP4YLQ7ncEZFaCOrbrjQEHY/JMgHy6s3mEFvg EndEr2mXNk5BsID1kLmXX+nz9hqhAoA1R7admtzFJNd8wNZC2yZNSegQffT6yRM5 WoCxaoK89quDomxhVRAHzIHUxmXJXHHhkjymNKOL9iULkexWMTOyrXSIiTrdqskL 7skF/Ak+GtdT4oswn675fEvWeAAgxexcjRyxO9UQ6Jt7vq7D+GP0PIC+tKsXv5Iw FK0RUuNLpOPTAqlECkFlE6/ekupD5MNWFIYrqhn0iCl656Dclgxa8UeXfO0kt0ot o/m7+aMkDvMCq+N702jKCIHKjBNxcZA/YMMUtQ1hGr7sO+O7G3rKvozdhoq1HjnI 88uqk5fJf5TYsRS7to5Atv+nMLWNMN5AE/QlOLGzVNJoBKaSds0yQ+P4H41gR8hZ QfqaPExVr0V1o/3kOqwrFLDUuU8kVzDvY41d9vWoMr6W1m29fYf4J+aO/SpaOlbV yWH373Hn =A9xu -END PGP SIGNATURE-
Bug#811087: closed by Michael Tokarev (Re: Bug#811087: qemu-user-static: qemu-arm-static segfaults in armhf chroot on 'aptitude -u')
Control: tag -1 - moreinfo Control: found -1 1:7.2+dfsg-1 On Sun, 14 Feb 2021 21:29:20 +0100 Andreas Beckmann wrote: Version: 1:5.2+dfsg-3~bpo10+1 On 2/14/21 4:46 PM, Michael Tokarev wrote: > Before I was able to hit this issue with almost any invocation of aptitude. > But in 5.0 or current 5.2 I can't reproduce this issue anymore, now matter > how I try. a simple 'aptitude -u' does the job for me :-( This is still happening with current sid and qemu 7.2. That's fantastic!.. :) The core file I get inside the chroot is actually from the qemu binary on the host, perhaps this backtrace helps: How does one gets the core inside a ch /mjt
Bug#1026209: python3-pytest-asyncio: deprecated use of markers for hook implementations
Package: python3-pytest-asyncio Version: 0.19.0-1 Severity: important Tags: fixed-upstream Control: affects -1 src:opendrop -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, recently, pytest 7.2 started issuing a warning about deprecated marker use [1], which in turn causes stderr output in packages using the asyncio plugin, thereby failing autopkgtests [2] This problem has been addressed in upstream release 0.20.2, with yet another deprecation-related fix in the very latest 0.20.3. As this currently prevents pytest from migrating to testing, it would be awesome if you could update the package ASAP. I would also do an NMU, but the VCS is not up-to-date. :/ By the way, have you considered moving this package to the Python Team? Cheers Timo [1] https://docs.pytest.org/en/7.2.x/deprecations.html#configuring-hook-specs-impls-using-markers [2] https://ci.debian.net/data/autopkgtest/testing/amd64/o/opendrop/29435557/log.gz -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmOcScAACgkQ+C8H+466 LVmn9AwAkhRqI9LEttVX/Qlw9VbYaBEtW6FeGqx2UX+ut/QIE2gSROIbEVd2Mnj5 SaxkSujl9MwRth5kFvQQabhK74B2zTD4I60hZYvKXE7lbsFbwqhqgY18Ug2eNzOu O6HExUcn8/KKu2v4hYc/w2VeuMBLxz1/FAXV33H4RbLpYOyEwbghjaFsONPTDg8s Bp6o2nHUQfgz9HzKuS3BphleRn411ZkZxu2DEwt6Qu4w+lX/VaYNupsDsqHXJ20D U051jkLYGuHix0xW0tsDnhbjIBUkTSK3BqaaRhq30PIixhKS/V/MRWGha7NzUgMX r7vafK9APCHJmCXoCt+Vm7BDzmaCI2XIzfSkT4RO2Q4c+7ZBm7EjR/8WRl+l7NeQ Mc22APP1jkib66lKBOUq4+hiJbQWgCS+TFOiZTnkJr7aeWSkd/XZdN/KK+4PnFzH ZV95Q2AueJwNt75N/r7GbSUvVwzDIei9wtnB+sBUoJ8ZpK/BRjqCTiFx1X/VSP1e TmtPOyHm =TCge -END PGP SIGNATURE-
Bug#972099: CVE-2019-12067
Control: severity -1 normal Since this issue is questioned upstream and in a few years there was no activity (neither upstream nor in debian), let's downgrade severity at least to normal. /mjt
Bug#971390: qemu: CVE-2020-25742
Control: severity -1 normal Since this issue is questioned upstream and in a few years there was no activity (neither upstream nor in debian), let's downgrade severity at least to normal. /mjt
Bug#970939: qemu: CVE-2020-25741
Control: severity -1 normal Since this issue is questioned upstream and in a few years there was no activity (neither upstream nor in debian), let's downgrade severity at least to normal. /mjt
Bug#970940: qemu: CVE-2020-25743
Control: severity -1 normal Since this issue is questioned upstream and in a few years there was no activity (neither upstream nor in debian), let's downgrade severity at least to normal. /mjt
Bug#1025140: diffutils: define SIGSEGV_FAULT_STACKPOINTER for loongarch
El 16/12/22 a las 5:17, 张丹丹 escribió: Hi，maintainers, Hello. I believe you need a similar change for m4. Please submit a bug for m4 as well. I have added a change for m4. Please consider it. I meant "please submit a bug to the Debian bug system". I don't see your bug report here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=m4 Thanks.
Bug#1026208: RM: recipe-scrapers -- ROM; Upstream switched to scrape-schema-recipe
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, I did an ITP for recipe-scrapers module #1001313 (package already in NEWS) but upstream (gourmand package) changed to the scrape-schema-recip python module. So I no longer need this package. Christian
Bug#1026207: python-ase: autopkgtest regression because test functions return values
Source: python-ase Version: 3.22.1-2 Severity: serious Control: affects -1 src:pytest -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainers, the autopkgtest of your package started failing because some of the tests return values. This has always been incorrect (tests are expected to assert, not return anything), but recently, pytest 7.2 started issuing warnings to stderr [1]. As a simple workaround, you could set "Restrictions: allow-stderr" until upstream has fixed their tests properly. Cheers Timo [1] https://docs.pytest.org/en/7.2.x/deprecations.html#returning-non-none-value-in-test-functions -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmOcQ5cACgkQ+C8H+466 LVmxrAwA3nN7Lbpp5XoVNWAR8NKy3fENAty3CFTnc17myzhoYc4TVoj8e9Vzg+Ci NuHgY3gl7AKTYK4mPtgicw5VXOdt+hojwJDgsMjRIYli/zssLFhfsN+I3/YoETsN tw5V+HJMJpahcMuHKgqcMfR3mVTy52u1eNrsf7jsyFyUacs2PO2/5tNaKCzAfinF Y5HB7oii4+drxSdHGTJqADDrBmAQvkXqzLsJLyG7kJpGBw7qLBN7IQdPMvoQMgcw iP4r9Y5lA7n3ae2Q/Nukt4/lF1snEn6KUcN1gkVeDbY2twRvlORNwnu5o8r7tJmU W5vHvB5eP0aakylfQQqhbUdq9jsvoWLbZHCY9dlrrLFwa1TA88olKXNoEcdup/rc Obj3rrkhrVHEs1Ax626PCuFOg5Y1+sVv9m/LJo4dEyh0/35S1gw6BZA697hrWnO9 pcElGT4lL4CXkb7LcS//y4YjOf8gLx9xi/6LwC62JsYkweCocqzqZXbyIErATBXx 4rjUs7u0 =Ysj+ -END PGP SIGNATURE-
