Processed: bug 1033301 is forwarded to https://lore.kernel.org/lkml/zbqeh6an4lfsf...@eldamar.lan/T/#u

2023-03-21 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> forwarded 1033301 
> https://lore.kernel.org/lkml/zbqeh6an4lfsf...@eldamar.lan/T/#u
Bug #1033301 [src:linux] linux: arm64 kernel size increased from 31 to 39 MB, 
causing u-boot-rpi to fail
Set Bug forwarded-to-address to 
'https://lore.kernel.org/lkml/zbqeh6an4lfsf...@eldamar.lan/T/#u'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1033301: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033301
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

2023-03-21 Thread Salvatore Bonaccorso
Hi Aurelien,

Thanks for tracking this down. I would like to loop in Masahiro and
upstream to see if something can/should be done on upstream side.

Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove
special treatment for the link order of head.o") (which got backported
as well to 6.1.14) caused the vmlinuz size to icrease significantly,
causing boot failures on Raspberry Pi 3 Model B Plus with u-boot
parameters previously working. Full quoting the Debian report below

On Tue, Mar 21, 2023 at 11:11:13PM +0100, Aurelien Jarno wrote:
> Source: linux
> Version: 6.1.15-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: vagr...@debian.org
> Control: affects -1 + u-boot-rpi
> 
> Hi,
> 
> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
> to boot with:
> 
> | 40175552 bytes read in 1695 ms (23 MiB/s)
> | 43794863 bytes read in 1817 ms (23 MiB/s)
> | Moving Image from 0x8 to 0x20, end=299
> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
> 
> I tracked the issue to a significant increase of the kernel size between
> version 6.1.12-1 and 6.15-1:
> 
> | 31492   /boot/vmlinuz-6.1.0-5-arm64
> | 39236   /boot/vmlinuz-6.1.0-6-arm64
> 
> This is more than the 36MB that is allowed by u-boot with the default
> load addresses. A workaround is to shift the load addresses at the
> u-boot level as in the attached patch.
> 
> I have tracked issue on the upstream kernel side to the following commit
> on the stable tree:
> 
> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
> | Author: Masahiro Yamada 
> | Date:   Thu Oct 13 08:35:00 2022 +0900
> | 
> | arm64: remove special treatment for the link order of head.o
> | 
> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
> | 
> | In the previous discussion (see the Link tag), Ard pointed out that
> | arm/arm64/kernel/head.o does not need any special treatment - the only
> | piece that must appear right at the start of the binary image is the
> | image header which is emitted into .head.text.
> | 
> | The linker script does the right thing to do. The build system does
> | not need to manipulate the link order of head.o.
> | 
> | Link: 
> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
> | Suggested-by: Ard Biesheuvel 
> | Signed-off-by: Masahiro Yamada 
> | Reviewed-by: Nicolas Schier 
> | Link: 
> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
> | Signed-off-by: Will Deacon 
> | Signed-off-by: Tom Saeger 
> | Signed-off-by: Greg Kroah-Hartman 
> 
> The problem is still reproducible on Linus' master.
> 
> I am reporting the bug to the linux package as I believed there is no
> real reason for such an increase in the kernel size. In case I missed
> something and this is actually wanted, the bug can be reassigned to the
> u-boot package.
> 
> Regards
> Aurelien

> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
> +++ u-boot-2023.01+dfsg/include/configs/rpi.h
> @@ -95,32 +95,32 @@
>   *   text_offset bytes (specified in the header of the Image) into a 2MB
>   *   boundary. The 'booti' command relocates the image if necessary. Linux 
> uses
>   *   a default text_offset of 0x8.  In summary, loading at 0x8
> - *   satisfies all these constraints and reserving memory up to 0x0240
> - *   permits fairly large (roughly 36M) kernels.
> + *   satisfies all these constraints and reserving memory up to 0x02a0
> + *   permits fairly large (roughly 42M) kernels.
>   *
>   * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
>   * conflict with something else. Reserving 1M for each of them at
> - * 0x0240-0x0250 and 0x0250-0x0260 should be plenty.
> + * 0x02a0-0x02b0 and 0x02c0-0x02d0 should be plenty.
>   *
>   * On ARM, both the DTB and any possible initrd must be loaded such that they
>   * fit inside the lowmem mapping in Linux. In practice, this usually means 
> not
>   * more than ~700M away from the start of the kernel image but this number 
> can
>   * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
>   * parameter given to the kernel. So reserving memory from low to high
> - * satisfies this constraint again. Reserving 1M at 0x0260-0x0270 for
> - * the DTB leaves rest of the free RAM to the initrd starting at 0x0270.
> + * satisfies this constraint again. Reserving 1M at 0x02c0-0x02d0 for
> + * the DTB leaves rest of the free RAM to the initrd starting at 0x02d0.
>   * Even with the smallest possible CPU-GPU memory split of the CPU getting
> - * only 64M, the remaining 25M starting at 0x0270 should allow quite
> + * only 64M, the remaining 19M starting at 0x02d0 should allow quite
>   * large initrds before they start colliding with U-Boot.
>   */
>  #define ENV_MEM_LA

Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

2023-03-21 Thread Aurelien Jarno
Source: linux
Version: 6.1.15-1
Severity: important
Tags: upstream
X-Debbugs-Cc: vagr...@debian.org
Control: affects -1 + u-boot-rpi

Hi,

Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
to boot with:

| 40175552 bytes read in 1695 ms (23 MiB/s)
| 43794863 bytes read in 1817 ms (23 MiB/s)
| Moving Image from 0x8 to 0x20, end=299
| ERROR: RD image overlaps OS image (OS=0x20..0x299)

I tracked the issue to a significant increase of the kernel size between
version 6.1.12-1 and 6.15-1:

| 31492   /boot/vmlinuz-6.1.0-5-arm64
| 39236   /boot/vmlinuz-6.1.0-6-arm64

This is more than the 36MB that is allowed by u-boot with the default
load addresses. A workaround is to shift the load addresses at the
u-boot level as in the attached patch.

I have tracked issue on the upstream kernel side to the following commit
on the stable tree:

| commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
| Author: Masahiro Yamada 
| Date:   Thu Oct 13 08:35:00 2022 +0900
| 
| arm64: remove special treatment for the link order of head.o
| 
| commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
| 
| In the previous discussion (see the Link tag), Ard pointed out that
| arm/arm64/kernel/head.o does not need any special treatment - the only
| piece that must appear right at the start of the binary image is the
| image header which is emitted into .head.text.
| 
| The linker script does the right thing to do. The build system does
| not need to manipulate the link order of head.o.
| 
| Link: 
https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
| Suggested-by: Ard Biesheuvel 
| Signed-off-by: Masahiro Yamada 
| Reviewed-by: Nicolas Schier 
| Link: 
https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
| Signed-off-by: Will Deacon 
| Signed-off-by: Tom Saeger 
| Signed-off-by: Greg Kroah-Hartman 

The problem is still reproducible on Linus' master.

I am reporting the bug to the linux package as I believed there is no
real reason for such an increase in the kernel size. In case I missed
something and this is actually wanted, the bug can be reassigned to the
u-boot package.

Regards
Aurelien
--- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
+++ u-boot-2023.01+dfsg/include/configs/rpi.h
@@ -95,32 +95,32 @@
  *   text_offset bytes (specified in the header of the Image) into a 2MB
  *   boundary. The 'booti' command relocates the image if necessary. Linux uses
  *   a default text_offset of 0x8.  In summary, loading at 0x8
- *   satisfies all these constraints and reserving memory up to 0x0240
- *   permits fairly large (roughly 36M) kernels.
+ *   satisfies all these constraints and reserving memory up to 0x02a0
+ *   permits fairly large (roughly 42M) kernels.
  *
  * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
  * conflict with something else. Reserving 1M for each of them at
- * 0x0240-0x0250 and 0x0250-0x0260 should be plenty.
+ * 0x02a0-0x02b0 and 0x02c0-0x02d0 should be plenty.
  *
  * On ARM, both the DTB and any possible initrd must be loaded such that they
  * fit inside the lowmem mapping in Linux. In practice, this usually means not
  * more than ~700M away from the start of the kernel image but this number can
  * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
  * parameter given to the kernel. So reserving memory from low to high
- * satisfies this constraint again. Reserving 1M at 0x0260-0x0270 for
- * the DTB leaves rest of the free RAM to the initrd starting at 0x0270.
+ * satisfies this constraint again. Reserving 1M at 0x02c0-0x02d0 for
+ * the DTB leaves rest of the free RAM to the initrd starting at 0x02d0.
  * Even with the smallest possible CPU-GPU memory split of the CPU getting
- * only 64M, the remaining 25M starting at 0x0270 should allow quite
+ * only 64M, the remaining 19M starting at 0x02d0 should allow quite
  * large initrds before they start colliding with U-Boot.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
"fdt_high=" FDT_HIGH "\0" \
"initrd_high=" INITRD_HIGH "\0" \
"kernel_addr_r=0x0008\0" \
-   "scriptaddr=0x0240\0" \
-   "pxefile_addr_r=0x0250\0" \
-   "fdt_addr_r=0x0260\0" \
-   "ramdisk_addr_r=0x0270\0"
+   "scriptaddr=0x02a0\0" \
+   "pxefile_addr_r=0x02b0\0" \
+   "fdt_addr_r=0x02c0\0" \
+   "ramdisk_addr_r=0x02d0\0"
 
 #if CONFIG_IS_ENABLED(CMD_MMC)
#define BOOT_TARGET_MMC(func) \


Processed: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

2023-03-21 Thread Debian Bug Tracking System
Processing control commands:

> affects -1 + u-boot-rpi
Bug #1033301 [src:linux] linux: arm64 kernel size increased from 31 to 39 MB, 
causing u-boot-rpi to fail
Added indication that 1033301 affects u-boot-rpi

-- 
1033301: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033301
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: your mail

2023-03-21 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> noowner 1030691
Bug #1030691 {Done: Albert Nash } [evince] Evince crashes on 
an unreadable nonempty postscript file owned by root
Ignoring request to unset the owner of bug #1030691 which was not set
> noowner 1032974
Bug #1032974 {Done: Albert Nash } [foot] 
initial-window-size-chars=80x25 in foot.ini doesn't take the data from the 
current monitor but from the primary one if the monitors have different 
resolution
Ignoring request to unset the owner of bug #1032974 which was not set
> noowner 1025333
Bug #1025333 {Done: Albert Nash } [gnome] Notification with 
connection failure pops up despite Internet
Ignoring request to unset the owner of bug #1025333 which was not set
> noowner 1026965
Bug #1026965 {Done: Albert Nash } [src:linux] ACPI Error: 
Needed [Integer/String/Buffer], found [Package]
Ignoring request to unset the owner of bug #1026965 which was not set
> archive 1030691
Bug #1030691 {Done: Albert Nash } [evince] Evince crashes on 
an unreadable nonempty postscript file owned by root
archived 1030691 to archive/91 (from 1030691)
> archive 1032974
Bug #1032974 {Done: Albert Nash } [foot] 
initial-window-size-chars=80x25 in foot.ini doesn't take the data from the 
current monitor but from the primary one if the monitors have different 
resolution
archived 1032974 to archive/74 (from 1032974)
> archive 1025333
Bug #1025333 {Done: Albert Nash } [gnome] Notification with 
connection failure pops up despite Internet
archived 1025333 to archive/33 (from 1025333)
> archive 1026965
Bug #1026965 {Done: Albert Nash } [src:linux] ACPI Error: 
Needed [Integer/String/Buffer], found [Package]
archived 1026965 to archive/65 (from 1026965)
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1025333: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025333
1026965: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026965
1030691: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030691
1032974: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032974
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: your mail

2023-03-21 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> close 1030691
Bug #1030691 [evince] Evince crashes on an unreadable nonempty postscript file 
owned by root
Marked Bug as done
> close 1032974
Bug #1032974 {Done: Albert Nash } [foot] 
initial-window-size-chars=80x25 in foot.ini doesn't take the data from the 
current monitor but from the primary one if the monitors have different 
resolution
Bug 1032974 is already marked as done; not doing anything.
> close 1025333
Bug #1025333 [gnome] Notification with connection failure pops up despite 
Internet
Marked Bug as done
> close 1026965
Bug #1026965 [src:linux] ACPI Error: Needed [Integer/String/Buffer], found 
[Package]
Marked Bug as done
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1025333: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025333
1026965: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026965
1030691: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030691
1032974: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032974
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Re: Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

2023-03-21 Thread Cyril Brulebois
Frédéric Bonnard  (2023-03-17):
> > It would be helpful to confirm which exact kernel version is getting
> > used in both cases (last 6.1.0-4 working, and first 6.1.0-5 not
> > working), then look at the changes between both versions, in src:linux
> > (and resulting udebs).
> 
> From linux changelog (
> https://tracker.debian.org/media/packages/l/linux/changelog-6.1.15-1 )
> and http://snapshot.debian.org/package/linux/,
> I see :
> 6.1.11-1 -> Bump ABI to 4 
> http://snapshot.debian.org/archive/debian/20230211T151657Z/
> 6.1.12-1 -> Bump ABI to 5 
> http://snapshot.debian.org/archive/debian/20230217T033139Z/
> 
> and tested from those (rebuilding the same d-i source with the 2 kernels
> from snapshot.d.o . 6.1.12-1 clearly doesn't work.
> I had already have a look at the kernel changelog but missed that one :
> ---
> linux (6.1.12-1) unstable; urgency=medium
> ...
> - of: Make OF framebuffer device names unique
> ...
> ---
> 
> I recompiled the kernel deb source without that one (
> https://github.com/torvalds/linux/commit/241d2fb56a18473af5f2ff0d512992a996eb64dd.patch
> ) and the mini.iso actually made it to the menu... and given the
> behaviour, a framebuffer actually makes sense.
> 
> Now, that patch does not harm when the kernel is installed on disk.
> But it does in the installer...

Adding the kernel team to the loop: d-i regression on ppc64el.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1033176: marked as done (linux: Future Android/Waydroid support)

2023-03-21 Thread Debian Bug Tracking System
Your message dated Tue, 21 Mar 2023 14:16:29 +0100
with message-id <739.xpBMn53rMx@prancing-pony>
and subject line Re: Bug#1033176: linux: Future Android/Waydroid support
has caused the Debian Bug report #1033176,
regarding linux: Future Android/Waydroid support
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1033176: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033176
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: linux
Version: Future Android/Waydroid support
Severity: wishlist
Forwarded: https://github.com/waydroid/waydroid/issues/811

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In https://salsa.debian.org/kernel-team/linux/-/merge_requests/651 I had
initially removed the 2 Android related patches for the following
reason:

Drop patches:
- debian/android-enable-building-ashmem-and-binder-as-modules.patch
- debian/export-symbols-needed-by-android-drivers.patch
After https://bugs.debian.org/901492 the preceding 2 patches were
created for anbox support. However in kernel 5.18 `ashmem` was removed
from the upstream kernel and since then, anbox has not been working as
reported in https://bugs.debian.org/1014329.
Then in https://bugs.debian.org/1032304, titled "RM: anbox -- ROM;
Upstream discontinued", the anbox package has been removed from the
Debian archive. And on Anbox's GH page one can see the following:
"It's development has however stalled in the past years and it's only
fair to say that now in 2023 it's no longer actively developed."
So it's of no use to continue carrying these patches.

Even though anbox is removed from the Debian archive and upstream more
or less 'dead', it turns out that Waydroid (= ~ anbox's successor) could
probably benefit from support in the Debian kernel too.

So I undid/reverted the dropping of those patches.
Removal of Android support should be done separately and ideally based on
a bug report in the BTS, hence this bug report.

In https://github.com/waydroid/waydroid/issues/811 I asked 'upstream'
for recommendations on which/how/what kernel modules to enable.

- -- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZBZPHwAKCRDXblvOeH7b
bpbCAPsFqbmYhJzizpispzGdw+ksgNnm59ZQDtmSMSYcNk5S5gD9FcHWbGx6XtJ2
5YefJ1PVNv1BbtdAkofzw2Nz5gLLDgE=
=pyYQ
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
On Sunday, 19 March 2023 00:54:15 CET Diederik de Haas wrote:
> In https://github.com/waydroid/waydroid/issues/811 I asked 'upstream'
> for recommendations on which/how/what kernel modules to enable.

In https://git.kernel.org/linus/9e18d0c82f0c07f2a41898d4adbb698a953403ee the 
default value of BINDER_DEVICES was changed to "binder,hwbinder,vndbinder" 
whereas the Debian kernel only has "binder". Also in other places they use the 
3 values, but I haven't been able to find out *why*.
As I wouldn't be able to make the argument to change it to something else and 
the most important thing is to enable ANDROID_BINDER_IPC, which is already the 
case, there's no need to keep this bug open.

If someone *can* substantiate why and how things should be changed, they 
should file a bug report (themselves) making the case.

signature.asc
Description: This is a digitally signed message part.
--- End Message ---


Processed: reassign 1032238 to src:linux, reassign 1033209 to apt, reassign 1033208 to apt, tagging 1032551 ...

2023-03-21 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reassign 1032238 src:linux
Bug #1032238 {Done: Salvatore Bonaccorso } 
[linux-image-6.1.0-5-amd64] linux-image-6.1.0-5-amd64: cryptsetup 2:2.6.1-1 
password not recognized
Warning: Unknown package 'linux-image-6.1.0-5-amd64'
Bug reassigned from package 'linux-image-6.1.0-5-amd64' to 'src:linux'.
Ignoring request to alter found versions of bug #1032238 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1032238 to the same values 
previously set
> reassign 1033209 apt 2.2.4
Bug #1033209 [apt-get] This info seems to have inadvertently been omitted from 
the Debian Bug report logs
Warning: Unknown package 'apt-get'
Bug reassigned from package 'apt-get' to 'apt'.
No longer marked as found in versions 2.2.4.
Ignoring request to alter fixed versions of bug #1033209 to the same values 
previously set
Bug #1033209 [apt] This info seems to have inadvertently been omitted from the 
Debian Bug report logs
Marked as found in versions apt/2.2.4.
> reassign 1033208 apt 2.2.4
Bug #1033208 [apt-get] /etc/apt/sources.list
Warning: Unknown package 'apt-get'
Bug reassigned from package 'apt-get' to 'apt'.
Ignoring request to alter found versions of bug #1033208 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1033208 to the same values 
previously set
Bug #1033208 [apt] /etc/apt/sources.list
Marked as found in versions apt/2.2.4.
> reassign 1033200 apt 2.2.4
Bug #1033200 [apt-get] apt, apt-get, aptitude and others have been failing for 
an extended period.
Warning: Unknown package 'apt-get'
Bug reassigned from package 'apt-get' to 'apt'.
Ignoring request to alter found versions of bug #1033200 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1033200 to the same values 
previously set
Bug #1033200 [apt] apt, apt-get, aptitude and others have been failing for an 
extended period.
Marked as found in versions apt/2.2.4.
> reassign 1033124 src:linux
Bug #1033124 [kernel] kernel: Fails to rebuild initrd.img after firmware is 
purged.
Warning: Unknown package 'kernel'
Bug reassigned from package 'kernel' to 'src:linux'.
No longer marked as found in versions 5.10.0-21-686-pae.
Ignoring request to alter fixed versions of bug #1033124 to the same values 
previously set
> tags 1032551 - bookworm sid
Bug #1032551 {Done: Pirate Praveen } [src:ruby-kubeclient] 
ruby-kubeclient: FTBFS in testing: ERROR: Test "ruby3.1" failed.
Removed tag(s) sid and bookworm.
> tags 983719 + experimental
Bug #983719 {Done: Faidon Liambotis } [esptool] Package is 
severely outdated
Added tag(s) experimental.
> tags 1032557 - bookworm sid
Bug #1032557 {Done: Andreas Tille } [src:freebayes] libvcflib 
breaks freebayes autopkgtest: Error: signal 11
Removed tag(s) bookworm and sid.
> tags 1005886 + sid bookworm
Bug #1005886 [debian-cd] debian-cd: bookworm net-install CD hangs on "Detecting 
Network Hardware"
Added tag(s) bookworm and sid.
> reassign 966653 ruby-spamcheck
Bug #966653 {Done: Pirate Praveen } [ruby-grpc] gitlab: 
[BUG] Segmentation fault at 0x
Bug reassigned from package 'ruby-grpc' to 'ruby-spamcheck'.
No longer marked as found in versions grpc/1.30.2-2.
No longer marked as fixed in versions 
ruby-spamcheck/1.0.0+git20220819.662e6bf-2.
> fixed 966653 1.0.0+git20220819.662e6bf-2
Bug #966653 {Done: Pirate Praveen } [ruby-spamcheck] 
gitlab: [BUG] Segmentation fault at 0x
Marked as fixed in versions ruby-spamcheck/1.0.0+git20220819.662e6bf-2.
> affects 966653 + src:gitlab
Bug #966653 {Done: Pirate Praveen } [ruby-spamcheck] 
gitlab: [BUG] Segmentation fault at 0x
Added indication that 966653 affects src:gitlab
> notfixed 1005023 1:102.7.0-1
Bug #1005023 {Done: Carsten Schoenert } [thunderbird] 
thunderbird subprocess (glxtest) dumps core on startup (with apparmor)
There is no source info for the package 'thunderbird' at version '1:102.7.0-1' 
with architecture ''
Unable to make a source version for version '1:102.7.0-1'
No longer marked as fixed in versions 1:102.7.0-1.
> fixed 1005023 1:102.6.0-1
Bug #1005023 {Done: Carsten Schoenert } [thunderbird] 
thunderbird subprocess (glxtest) dumps core on startup (with apparmor)
Marked as fixed in versions thunderbird/1:102.6.0-1.
> notfixed 685148 2.3
Bug #685148 {Done: Joachim Reichel } [cppcheck] 
false positive: casting between pointer with incompatible binary data 
representation
There is no source info for the package 'cppcheck' at version '2.3' with 
architecture ''
Unable to make a source version for version '2.3'
No longer marked as fixed in versions 2.3.
> fixed 685148 2.3-1
Bug #685148 {Done: Joachim Reichel } [cppcheck] 
false positive: casting between pointer with incompatible binary data 
representation
Marked as fixed in versions cppcheck/2.3-1.
> reassign 1007981 src:cvc5
Bug #1007981 {Done: Scott Talbert } [src:cvc4] cvc4: Consider 
upgrading to cvc5
Bug reassigned from package 'src:cvc4' to '

Bug#925424: linux-image-amd64: Build the Silead touchscreen controller kernel driver

2023-03-21 Thread Gregor Riepl

Hi Debian kernel team,

It's been 4 years, and the Debian kernel is still lacking out-of-the-box 
support for Silead touchscreen controllers and corresponding DMI quirks.


Can you please enable these options?


CONFIG_TOUCHSCREEN_SILEAD=m
CONFIG_TOUCHSCREEN_DMI=y


Thank you very much.