Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 24 Dec 2022 08:04:23 +0100
Source: linux
Architecture: source
Version: 6.1.1-1~exp2
Distribution: experimental
Urgency: medium
Maintainer: Debian Kernel Team
Changed-By:
linux_6.1.1-1~exp2_source.changes uploaded successfully to localhost
along with the files:
linux_6.1.1-1~exp2.dsc
linux_6.1.1-1~exp2.debian.tar.xz
linux_6.1.1-1~exp2_source.buildinfo
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
Your message dated Fri, 23 Dec 2022 21:33:09 +0100
with message-id
and subject line Re: Bug#1024718: Fwd: Bug#1024718: linux: Samsung PM9B1 NVMe
fails changes NID when resuming from sleep
has caused the Debian Bug report #1024718,
regarding linux: Samsung PM9B1 NVMe fails changes NID when resumin
Your message dated Fri, 23 Dec 2022 21:27:54 +0100
with message-id
and subject line Re: Bug#1026870:
has caused the Debian Bug report #1026870,
regarding linux-image-6.0.0-6-amd64 - significant performance degradation
to be marked as done.
This means that you claim that the problem has been dealt
Package: firmware-iwlwifi
Version: 20221109-4
Severity: important
File: /lib/firmware/iwlwifi-cc-a0-72.ucode
X-Debbugs-Cc: fishyw...@gmail.com
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did
Package: src:linux
Version: 6.0.12-1
Severity: normal
X-Debbugs-Cc: hel...@bluewin.ch
Dear Maintainer,
* What led up to the situation?
Regular boot shows error message. System functions normally otherwise.
[ 30.070105] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/in
-- Forwarded message -
From: Stuart
Date: Fri, Dec 23, 2022 at 1:53 PM
Subject: Re: Bug#1024718: linux: Samsung PM9B1 NVMe fails changes NID when
resuming from sleep
To: Salvatore Bonaccorso
Well it seems as of this message, it won't be accepted upstream due to
their policy on n
Hi.
Installed the new firmware-nonfree 20221214-1 unstable and Debian still
crashes after a few minutes/hours. The machine completely freezes/locks up.
The graphic card is not defective, installed windows to test, played a few
games, and had no issue in windows (I hate windows). Tried with Linux M
binary:ata-modules-6.0.0-0.deb11.6-arm64-di is NEW.
binary:btrfs-modules-6.0.0-0.deb11.6-arm64-di is NEW.
binary:cdrom-core-modules-6.0.0-0.deb11.6-arm64-di is NEW.
binary:crc-modules-6.0.0-0.deb11.6-arm64-di is NEW.
binary:crypto-dm-modules-6.0.0-0.deb11.6-arm64-di is NEW.
binary:crypto-modules-6.
linux-signed-arm64_6.0.12+1~bpo11+1_source.changes uploaded successfully to
localhost
along with the files:
linux-signed-arm64_6.0.12+1~bpo11+1.dsc
linux-signed-arm64_6.0.12+1~bpo11+1.tar.xz
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
On 12/23/22 09:49, Thorsten Glaser wrote:
Donald Buczek dixit:
To be fair, this daemon doesn't use /proc/pid/stat for that, but /proc/pid/comm
Yes, and that’s proper. The field in /proc/pid/stat is size-limited
and so not necessarily distinct.
No, it is the process name itself, which is siz
The suite "oldstable-proposed-updates" does not accept source uploads.
Mapping oldstable-security to oldstable-proposed-updates.
binary:acpi-modules-4.19.0-23-686-di is NEW.
binary:acpi-modules-4.19.0-23-686-pae-di is NEW.
binary:ata-modules-4.19.0-23-686-di is NEW.
binary:ata-modules-4.19.0-23
The suite "oldstable-proposed-updates" does not accept source uploads.
Mapping oldstable-security to oldstable-proposed-updates.
binary:ata-modules-4.19.0-23-arm64-di is NEW.
binary:btrfs-modules-4.19.0-23-arm64-di is NEW.
binary:cdrom-core-modules-4.19.0-23-arm64-di is NEW.
binary:compress-mod
The suite "oldstable-proposed-updates" does not accept source uploads.
Mapping oldstable-security to oldstable-proposed-updates.
binary:acpi-modules-4.19.0-23-amd64-di is NEW.
binary:ata-modules-4.19.0-23-amd64-di is NEW.
binary:btrfs-modules-4.19.0-23-amd64-di is NEW.
binary:cdrom-core-modules
Donald Buczek dixit:
> To be fair, this daemon doesn't use /proc/pid/stat for that, but
> /proc/pid/comm
Yes, and that’s proper. The field in /proc/pid/stat is size-limited
and so not necessarily distinct.
> As /proc/pid/stat is also used in many places, it could as well use
> that to avoid cod
On 12/22/22 21:28, Thorsten Glaser wrote:
Donald Buczek dixit:
No, Escaping would break existing programs which parse the line by
searching for the ')' from the right.
Huh? No!
The format is "(" + string + ") " after all, and only the string
part would get escaped.
The only visible change w
16 matches
Mail list logo