Processed: Re: impossible to update libbpf without updating the kernel
Processing commands for cont...@bugs.debian.org: > retitle 948041 libbpf-dev: please build from https://github.com/libbpf/libbpf Bug #948041 [src:linux] impossible to update libbpf without updating the kernel Changed Bug title to 'libbpf-dev: please build from https://github.com/libbpf/libbpf' from 'impossible to update libbpf without updating the kernel'. > reassign 948041 libbpf-dev Bug #948041 [src:linux] libbpf-dev: please build from https://github.com/libbpf/libbpf Bug reassigned from package 'src:linux' to 'libbpf-dev'. Ignoring request to alter found versions of bug #948041 to the same values previously set Ignoring request to alter fixed versions of bug #948041 to the same values previously set > merge 942903 948041 Bug #942903 [libbpf-dev] libbpf library is from kernel source Bug #948041 [libbpf-dev] libbpf-dev: please build from https://github.com/libbpf/libbpf Marked as found in versions linux/5.3.7-1. Merged 942903 948041 > quit Stopping processing here. Please contact me if you need assistance. -- 942903: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942903 948041: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948041 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#948041: impossible to update libbpf without updating the kernel
retitle 948041 libbpf-dev: please build from https://github.com/libbpf/libbpf reassign 948041 libbpf-dev merge 942903 948041 quit Hi, Julia Kartseva wrote: > On Sun, 12 Jan 2020 09:51:55 +0100 Bastian Blank wrote: >> Why should we? If the upstream developers decide to maintain it >> independently, aka don't use the kernel repo as true source, or better, >> remove the source from it, then we have something to do. I agree --- if upstream development were happening in https://github.com/libbpf/libbpf then this would be a no-brainer. It appears to instead be a mirror of the source that's in the kernel repo, though. > Why should we switch from kernel sources to GH is a frequently asked > question so the reason was explained in libbpf README [1]. If I'm reading that correctly, the intent appears to be that it would allow faster libbpf upgrades. In the context of the Debian project, that could go both ways. The Linux kernel packages are very well maintained. New versions appear in stable-backports pretty quickly, and that's *less* likely to happen with a separate libbpf source package. Binary package dependencies do not force an end user to use the same version of the kernel as userspace tools like this one. Debian even permits binary packages to have different version numbers from the source package they were built from. Depending packages would likely use Debian's shlibs or symbols mechanism (if upstream provides symbol versioning, that is very helpful) to automatically produce appropriate dependencies. More details about this are at https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#dependencies-between-the-library-and-other-packages So this appears to impose exactly the same costs and benefits as any other instance where someone splits a binary package that comes from the same upstream source package into a separate Debian source package. Sometimes that is the right thing to do, especially when the Debian maintainers for the two packages do not work very closely together. Is that the case here? Is there some underlying need that we could address more directly? I think I'm missing some piece of the motivation here. Thanks, Jonathan > [1] https://github.com/libbpf/libbpf#distributions
Bug#948041: impossible to update libbpf without updating the kernel
On Sun, 12 Jan 2020 09:51:55 +0100 Bastian Blank wrote: > But updating independently does not provide any benefit. As the kernel > repo is still upstream, all upstream chnages will flow into the Debian > archive. An extra package will always lag behind, as changes needs to > flow from kernel to external repo. > > > It might be better if we decide now what we want to do and tell them > > accordingly. > > Why should we? If the upstream developers decide to maintain it > independently, aka don't use the kernel repo as true source, or better, > remove the source from it, then we have something to do. > > Bastian Hi Bastian, Why should we switch from kernel sources to GH is a frequently asked question so the reason was explained in libbpf README [1]. There is another bug report on libbpf packaging filed earlier by me [2], feel merge it with this one. [1] https://github.com/libbpf/libbpf#distributions [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942903
Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'
Package: initramfs-tools Version: 0.135 Followup-For: Bug #948257 Just want to confirm Pierrick's observation that rolling back kmod and libkmod2 to version 26-3 fixes the logspam.
Bug#931930: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin
On Tue, 7 Jan 2020 23:38:10 +0100 "Miguel A. Vallejo" wrote: > With the arrival of kernel 5.4.0-2-amd64 now there are three missing > firmware files: > > update-initramfs: Generating /boot/initrd.img-5.4.0-2-amd64 > W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin > for module i915 > W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin > for module i915 > W: Possible missing firmware > /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915 > > All of them are in the source package (???) > > No, they are not. Only in debian source packet, not in .deb file.
Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_XXXXXXX/lib/modules/5.4.0-1-amd64/modules.builtin.bin'
Yes, this fix https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/23/diffs indeed at least silenced (maybe fixed) those wornings after update-initramfs -u Hope you will pull that in initramfs-tools-core as shown by dpkg -S ./mkinitramfs And *I hope* it will happen faster than with this obnoxious bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931930
Bug#940813: firmware-iwlwifi: iwlwifi-9000-pu-b0-jf-b0-46.ucode is broken
Package: firmware-iwlwifi Version: 20190717-2 Followup-For: Bug #940813 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! I was running in this problem (as well as some unreliability with the Bluetooth). Instead of downgrading to -41, I have updated the -46 to the version in linux-firmware.git. There has been one additional version (and more for Bluetooth): https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/iwlwifi-9000-pu-b0-jf-b0-46.ucode - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.135 - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4eLQsSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5QUYP/0CPAAZKVJPFnA2uKctgfLbiM4A5Sub7 AzLzTkeUjSajrZT8t001HZN/XYreXcfA5GhDHm9BgJ2Xh5/1qThmfe8+l0ZOEss2 gLG0DC+QMx49OUddCX09U36N8Fml3fCMbO2RU2XIWmyjZou/s7Mxv5P9C+04uO/b OEtiFF1UX/cCgW9uezND2nqNQh+hRtEELnzdCb2F8ymWWA5f7zJsmiTBf1RVgDB0 pZ4TlzIRPcrTELxelkz+jkuqAHANxbJKwWIDFsJ58EbIp6hHSQTC4s+rL1ErEipA NkPxoBe5a3QPQ3zJ1XzB9Z7X7w4mSRdDLP22BocFHDeREhFQ0hoVgL2T0SkxPzAe 9M638NMiQUvtKh4fsj55Y7iF77x31/jvqoCvh+52aj1DHdzfOZI7SkNtl9uzLmEg Np96couiDk3wHrAmWyrzti1VEu/vHTHD25T0pGdNZ7n8ec8b7v0ArYp2rGMAf7zp Uki+98Qit7w/uf0MiwaKsXIm+eHttCdjdQL2j7qmXsDDpmgGTzum0nhyGlgA60O8 uTIwfvx7fKoVae7rntyZas2Dn//oDrG8UrSUkYaS2bgIxo1FZ2IRN8XSBPjVfQjn sUopj4RcosxM+nLN7M284qD2fp+tunpYFJ1vyatvnBptmAAwVLkTn2gH9sYDtEzZ lXbPmor0thvQ =fKGB -END PGP SIGNATURE-
Bug#948921: linux-image-5.4.0-2-amd64: decrypting root partition does not work on 5.4.0 (works on 5.3.0) with decrypt_keyctl
Package: src:linux Version: 5.4.8-1 Severity: normal Dear Maintainer, * What led up to the situation? Upgrading kernel from 5.3.0 to 5.4.0 * What exactly did you do (or not do) that was effective (or ineffective)? Booting on the new kernel always fail with an error message stating I entered the wrong passphrase. Selecting kernel 5.3.0 on grub works with the same passphrase. I am sure I did not mixed passphrases, as I tried tens of times with each kernel, result was 100% failure with 5.4.0, 100% success with 5.3.0. I also checked if there was not a problem with keyboard layout, typing the passphrase as if the keyboard was configured in English QWERTY (my keyboard is a French one with AZERTY layout). It also failed 100% of time when selecting kernel 5.4.0. I regenerated several time the initramfs using update-initramfs -k all -u, this didn't change anything: kernel 5.4.0 fails to decrypt, kernel 5.3.0 succeeded. On another laptop with a comparable setting EXCEPT that the key is stored in a file, the boot completes in 5.4.0. So only the combination decrypt_keyctl and kernel 5.4.0 fails. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Dell Inc. product_name: XPS L521X product_version: A13 chassis_vendor: Dell Inc. chassis_version: A13 bios_vendor: Dell Inc. bios_version: A13 board_vendor: Dell Inc. board_name: 063M0K board_version: A00 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) Subsystem: Dell 3rd Gen Core processor DRAM Controller [1028:054e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ivb_uncore 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell 3rd Gen Core processor Graphics Controller [1028:054e] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Dell 7 Series/C210 Series Chipset Family USB xHCI Host Controller [1028:054e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04) Subsystem: Dell 7 Series/C216 Chipset Family MEI Controller [1028:054e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20 [EHCI]) Subsystem: Dell 7 Series/C216 Chipset Family USB Enhanced Host Controller [1028:054e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) Subsystem: Dell 7 Series/C216 Chipset Family High Definition Audio Controller [1028:054e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
Bug#947356: missing firmware rtl8125a-3.fw
Same problem here W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169 firmware-realtek 20190717-2 kernel ; 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64
Processed: affects 947963
Processing commands for cont...@bugs.debian.org: > affects 947963 linux-image-5.4.0-1-amd64 linux-image-5.4.0-2-amd64 Bug #947963 [src:linux] linux-image-5.4.0-1-amd64: ELAN touchpad no longer working Added indication that 947963 affects linux-image-5.4.0-1-amd64 and linux-image-5.4.0-2-amd64 > thanks Stopping processing here. Please contact me if you need assistance. -- 947963: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947963 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: retitle 947963 to linux-image-5.4.0-1-amd64: ELAN touchpad no longer working
Processing commands for cont...@bugs.debian.org: > retitle 947963 linux-image-5.4.0-1-amd64: ELAN touchpad no longer working Bug #947963 [src:linux] Mouse-pad no longer working Changed Bug title to 'linux-image-5.4.0-1-amd64: ELAN touchpad no longer working' from 'Mouse-pad no longer working'. > thanks Stopping processing here. Please contact me if you need assistance. -- 947963: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947963 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
linux-signed-arm64_5.4.8+1~bpo10+1_source.changes is NEW
binary:linux-image-5.4.0-0.bpo.2-arm64 is NEW. binary:linux-image-5.4.0-0.bpo.2-rt-arm64 is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
linux-signed-amd64_5.4.8+1~bpo10+1_source.changes is NEW
binary:linux-image-5.4.0-0.bpo.2-amd64 is NEW. binary:linux-image-5.4.0-0.bpo.2-cloud-amd64 is NEW. binary:linux-image-5.4.0-0.bpo.2-rt-amd64 is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
linux-signed-i386_5.4.8+1~bpo10+1_source.changes is NEW
binary:linux-image-5.4.0-0.bpo.2-686 is NEW. binary:linux-image-5.4.0-0.bpo.2-686-pae is NEW. binary:linux-image-5.4.0-0.bpo.2-rt-686-pae is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
Bug#948866: linux: Please enable terminus 16x32 font
Source: linux Version: 5.4.8-1 Severity: normal Hello, With hidpi displays, the default 8x16 font is unreadable. Could you enable CONFIG_FONTS=y CONFIG_FONT_TER16x32=y so that we can set fbcon=font:TER16x32 on the command line on systems with a hidpi display? Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Samuel muhahaha... ya un train qui part de Perrache à 14h57 qui passe à Part-Dieu à 15h10 si je le prends à Perrache, je suis en zone bleue si je le prends à Part-Dieu, je suis en zone blanche donc je vais le prendre à Perrache *mais* à Part-Dieu ;-) -+- #ens-mim - vive la SNCF -+-
