On Wed, 2025-02-26 at 13:40 +0100, Miguel Ojeda wrote:
> On Wed, Feb 26, 2025 at 1:13 PM NoisyCoil wrote:
> >
> > As for the actual contents of the package, the Rust bits, they are
> > binary files (and include an actual shared library), so my reasoning was
> > that they should belong to a differ
On Wed, Feb 26, 2025 at 7:24 PM NoisyCoil wrote:
>
> It does indeed depend on the configuration, because at least some
> abstractions are enabled via the configuration and different metadata
> will be produced depending on whether they are or not (Miguel should
> confirm this, but I'm pretty sure
On 26/02/25 19:47, Miguel Ojeda wrote:
On Wed, Feb 26, 2025 at 7:24 PM NoisyCoil wrote:
It does indeed depend on the configuration, because at least some
abstractions are enabled via the configuration and different metadata
will be produced depending on whether they are or not (Miguel should
con
Hi Greg, hi Sasha
A while back the following regression after 4bce37a68ff8 ("mips/mm:
Convert to using lock_mm_and_find_vma()") was reported:
https://lore.kernel.org/all/75e9fd7b08562ad9b456a5bdaacb7cc220311cc9.ca...@xry111.site/
affecting mips64el. This was later on fixed by 8fa507083388
("mm/mem
Processing commands for cont...@bugs.debian.org:
> found 1086028 6.1.37-1
Bug #1086028 [src:linux] loupe: FTBFS on mips64el: failed to acquire jobserver
token: Bad address (os error 14)
Bug #1087809 [src:linux] cargo: [mipsel64] failed to acquire jobserver
token/Bad address (os error 14)
Bug #10
On Wed, Feb 26, 2025 at 01:02:33PM +0100, Diederik de Haas wrote:
> On Sat Feb 22, 2025 at 11:59 AM CET, Aurelien Jarno wrote:
> > Starting with version 6.13.3-1~exp1, the riscv64 kernel is shipped as a
> > EFI binary with the payload compressed with zstd (using the EFI_ZBOOT
> > config option). In
Hi Sergei,
On Wed, Feb 26, 2025 at 04:23:29PM +0300, Sergei Golovan wrote:
> Hi Salvatore,
>
> On Tue, Feb 25, 2025 at 7:36???PM Salvatore Bonaccorso
> wrote:
> >
> > Hi Sergei,
> >
> > Can you test the two patched attached instead please?
>
> I confirm that these two patches indeed fix the bu
On Wed, Feb 26, 2025 at 01:13:45PM +0100, NoisyCoil wrote:
> Unless you are fine with
> linux-headers-@abiname@@localversion@ also installing binary files, in which
> case one can just add the Rust bits there.
The headers package includes many generated files that can
Hi Salvatore,
On Tue, Feb 25, 2025 at 7:36 PM Salvatore Bonaccorso wrote:
>
> Hi Sergei,
>
> Can you test the two patched attached instead please?
I confirm that these two patches indeed fix the bug. I've applied them
to the 6.1.128-1 kernel and used erlc (Erlang compiler) to reproduce
the bug i
On 26/02/25 13:40, Miguel Ojeda wrote:
Ah, and by the way, there will likely be way more `.rmeta`s and `.so`s
generated (and where they get placed will change) in the future, since
the system will change, so please keep that in mind (e.g. perhaps try
to avoid hardcoding details and/or overfitting
On 26/02/25 14:22, Bastian Blank wrote:
case one can just add the Rust bits there. But I still think the Rust bits
should be installed in /usr/lib [1] instead of /usr/src.
There is no need to get picky, sorry.
No need to be sorry, this is the kind of feedback I am looking for. If
you confirm
On Sun Feb 23, 2025 at 4:59 AM CET, Matthias Babisch wrote:
> Am 21.02.25 um 08:11 schrieb Salvatore Bonaccorso:
>> On Wed, Feb 19, 2025 at 01:40:35PM +0100, Matthias Babisch wrote:
>>> Package: src:linux
>>> Version: 6.1.124-1
>>>
>>> System is unaffected if running older kernel. I have two system
linux-signed-amd64_6.12.12+1~bpo12+1_source.changes uploaded successfully to
localhost
along with the files:
linux-signed-amd64_6.12.12+1~bpo12+1.dsc
linux-signed-amd64_6.12.12+1~bpo12+1.tar.xz
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
Mapping bookworm-backports to stable-backports.
binary:ata-modules-6.12.12+bpo-amd64-di is NEW.
binary:btrfs-modules-6.12.12+bpo-amd64-di is NEW.
binary:cdrom-core-modules-6.12.12+bpo-amd64-di is NEW.
binary:crypto-dm-modules-6.12.12+bpo-amd64-di is NEW.
binary:crypto-modules-6.12.12+bpo-amd64-di i
Hi Ben,
On 26/02/25 19:11, Ben Hutchings wrote:
This shouldn't go in a linux-headers package, because we aim to support
cross-builds of modules. If it doesn't depend on the kernel
configuration (aside from CONFIG_RUST being enabled) then it belongs in
linux-kbuild.
Ben.
It does indeed depend
This week's meeting will happen today (2025-02-26) at 20:00 UTC, this time
on IRC.
The agenda is here:
https://salsa.debian.org/kernel-team/meetings/-/wikis/20250226
Please reply to this message if you want to add items.
Ben.
--
Ben Hutchings
All the simple programs have been written
On Wed, Feb 26, 2025 at 3:15 PM NoisyCoil wrote:
>
> Yeah I'd imagined this could happen. Currently d/rules just copies
> rust/{*.rmeta,*.so} into the destination directory. My guess was that in
> the future they could be placed in subdirectories of rust/, but on a
> second thought I think as subs
On Wed, Feb 26, 2025 at 7:11 PM Ben Hutchings wrote:
>
> This shouldn't go in a linux-headers package, because we aim to support
> cross-builds of modules. If it doesn't depend on the kernel
> configuration (aside from CONFIG_RUST being enabled) then it belongs in
> linux-kbuild.
Hmm... Right no
On 26/02/25 19:10, Miguel Ojeda wrote:
On Wed, Feb 26, 2025 at 3:15 PM NoisyCoil wrote:
Yeah I'd imagined this could happen. Currently d/rules just copies
rust/{*.rmeta,*.so} into the destination directory. My guess was that in
the future they could be placed in subdirectories of rust/, but on a
Processing commands for cont...@bugs.debian.org:
> reassign 1088826 src:linux 6.1.115-1
Bug #1088826 [linux-image-686-pae] /usr/share/bug/linux-image-686-pae/presubj:
Fails to boot after 6.1.0-22
Bug reassigned from package 'linux-image-686-pae' to 'src:linux'.
No longer marked as found in versio
Control: clone -1 -2
Control: reassign -2 src:grub
Control: retitle -2 grub - fails to start zboot linux on risvc64: Unhandled
exception: Store/AMO access fault
Control: severity -2 important
On Mon, Feb 24, 2025 at 10:50:58PM +0100, Aurelien Jarno wrote:
> It works fine when the kernel is direct
Processing control commands:
> clone -1 -2
Bug #1098661 [src:linux] linux: fails to boot on VisionFive 2: Unhandled
exception: Store/AMO access fault
Bug 1098661 cloned as bug 1098973
> reassign -2 src:grub
Bug #1098973 [src:linux] linux: fails to boot on VisionFive 2: Unhandled
exception: Store
Processing control commands:
> tag -1 wontfix
Bug #1050578 [src:linux] linux-image-6.1.0-11-amd64: kernel disk device cache
coherency issue: stale reads on /dev/sda1
Added tag(s) wontfix.
> severity -1 normal
Bug #1050578 [src:linux] linux-image-6.1.0-11-amd64: kernel disk device cache
coherency
Control: tag -1 wontfix
Control: severity -1 normal
As this usage of block devices is not supported by upstream and that
isn't likely to change, I'm marking this wontfix and reducing severity.
Ben.
--
Ben Hutchings
All the simple programs have been written, and all the good names taken
sign
On Wed, Feb 26, 2025 at 01:27:00AM +0100, NoisyCoil wrote:
> Needless to say, Rust must be enabled in the kernel for these files to be
> generated, meaning the Debian kernel cannot currently support this. However,
> there is at least one fork of the Debian kernel being built with Rust
> enabled at
On 26/02/25 12:29, Bastian Blank wrote:
I completely miss the reason why this can't be part of linux-headers and
just be used the same way.
Yeah, I should have explained my reasoning in my previous email.
The metapackage is added so users can choose whether to install the Rust
bits or not. If
On Sat Feb 22, 2025 at 11:59 AM CET, Aurelien Jarno wrote:
> Starting with version 6.13.3-1~exp1, the riscv64 kernel is shipped as a
> EFI binary with the payload compressed with zstd (using the EFI_ZBOOT
> config option). In addition to breaking non-EFI systems, this change
Breaks non-EFI systems
On Wed, Feb 26, 2025 at 1:13 PM NoisyCoil wrote:
>
> As for the actual contents of the package, the Rust bits, they are
> binary files (and include an actual shared library), so my reasoning was
> that they should belong to a different package than
> linux-headers-@abiname@@localversion@, and be i
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 23 Feb 2025 19:00:49 +0100
Source: linux
Architecture: source
Version: 6.12.12-1~bpo12+1
Distribution: bookworm-backports
Urgency: medium
Maintainer: Debian Kernel Team
Mapping oldstable-security to oldstable-proposed-updates.
binary:acpi-modules-5.10.0-34-amd64-di is NEW.
binary:ata-modules-5.10.0-34-amd64-di is NEW.
binary:btrfs-modules-5.10.0-34-amd64-di is NEW.
binary:cdrom-core-modules-5.10.0-34-amd64-di is NEW.
binary:crc-modules-5.10.0-34-amd64-di is NEW.
b
Mapping oldstable-security to oldstable-proposed-updates.
binary:ata-modules-5.10.0-34-arm64-di is NEW.
binary:btrfs-modules-5.10.0-34-arm64-di is NEW.
binary:cdrom-core-modules-5.10.0-34-arm64-di is NEW.
binary:crc-modules-5.10.0-34-arm64-di is NEW.
binary:crypto-dm-modules-5.10.0-34-arm64-di is N
Mapping oldstable-security to oldstable-proposed-updates.
binary:acpi-modules-5.10.0-34-686-di is NEW.
binary:acpi-modules-5.10.0-34-686-pae-di is NEW.
binary:ata-modules-5.10.0-34-686-di is NEW.
binary:ata-modules-5.10.0-34-686-pae-di is NEW.
binary:btrfs-modules-5.10.0-34-686-di is NEW.
binary:bt
Package: src:linux
Version: 6.12.16-1
Followup-For: Bug #1098782
X-Debbugs-Cc: bruno...@gmail.com
Dear Maintainer,
While upgarding to the latest kernel 6.12.16 on Sid today, I ran into a
dkms error that prevented the Nvidia module to configure, and
consequently left the entire kernel unconfigure
33 matches
Mail list logo
