Processed: Re: Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
Processing control commands: > reassign -1 src:linux 4.19.37-5 Bug #931507 [kernel-wedge] kernel-wedge: HDA sound board detection takes 60s in d-i Bug reassigned from package 'kernel-wedge' to 'src:linux'. No longer marked as found in versions kernel-wedge/2.99. Ignoring request to alter fixed versions of bug #931507 to the same values previously set Bug #931507 [src:linux] kernel-wedge: HDA sound board detection takes 60s in d-i Marked as found in versions linux/4.19.37-5. -- 931507: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931507 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: [...] > No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only uploads if > you want them to reach bullseye. I support this move in principle, but: > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). > > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. [...] This is not going to fly for src:linux. We can't stage ABI bumps in experimental as we typically have a different upstream versions in unstable and experimental. We even need to do ABI bumps in stable from time to time. I think that the requirement to upload binary packages for binary-NEW (but not source-NEW) needs to go. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Processed: severity of 928736 is important
Processing commands for cont...@bugs.debian.org: > severity 928736 important Bug #928736 [initramfs-tools] initramfs-tools: With plymouth print misleading resuming from hibernation Severity set to 'important' from 'minor' > thanks Stopping processing here. Please contact me if you need assistance. -- 928736: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928736 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bits from the Release Team: ride like the wind, Bullseye!
> "Ben" == Ben Hutchings writes: Ben> On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: Ben> [...] >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is >> about to begin. From now on, we will no longer allow binaries >> uploaded by maintainers to migrate to testing. This means that >> you will need to do source-only uploads if you want them to reach >> bullseye. Ben> I support this move in principle, but: Ben> This is not going to fly for src:linux. We can't stage ABI Ben> bumps in experimental as we typically have a different upstream Ben> versions in unstable and experimental. We even need to do ABI Ben> bumps in stable from time to time. Ben> I think that the requirement to upload binary packages for Ben> binary-NEW (but not source-NEW) needs to go. I agree with Ben. There are a lot of good reasons to stage (possibly even most) binary new packages through experimental. Ben has talked about cases where experimental can't work. I'd like to talk about cases where it is the wrong answer. However, we've gotten a lot of feedback from our maintainers over the years that anything that adds an extra round trip to their workflow is significantly demotivating. If I need to wait for something to go through new, and then after it goes through new do an extra thing to accomplish my goal, that increases the cost of what I'm doing significantly. If it's a simple soname bump because of a new symbol, that doesn't always require experimental. Thinking back to my own experience with krb5, I have a good handle on when ABI bumps need to go through experimental and when things are going to be fine through unstable. I haven't made a lot of mistakes in that front--uploading things to unstable that ended up being broken enough we wished they had gone through experimental. I know I'm not alone. I think that for this to fly, binaries for binary new need to go. I understand that balancing the trade offs here requires a bit of a mind meld between the ftp team and the release team, and I understand that cross team decision making is more complex here. I'd be happy to facilitate any discussion around the trade offs if that would be useful. --Sam
Processed: Re: initramfs hook scripts which use log_* functions die
Processing control commands: > tag -1 moreinfo Bug #931499 [initramfs-tools-core] initramfs hook scripts which use log_* functions die Added tag(s) moreinfo. -- 931499: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931499 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931499: initramfs hook scripts which use log_* functions die
Control: tag -1 moreinfo On Sat, 6 Jul 2019 20:31:37 +0200 Guenther Brunthaler wrote: > Package: initramfs-tools-core > Version: 0.133 > > initramfs hook scripts which source > > . /usr/share/initramfs-tools/scripts/functions > > and then later use one of the log_*() functions such as > > log_begin_msg "Installing terminfo entries: $tinfos" > > will make the hook script fail with the message "quiet: parameter not > set", which will make the invoking "update-initramfs" also fail as a > consequence. [...] These functions are meant to be used by boot scripts, not by hook scripts. The documentation is consistent with that. Which hook scripts are using them? Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
Ben Hutchings, le dim. 07 juil. 2019 13:35:20 +0100, a ecrit: > i915 belongs in fb-modules. I'm not sure that sound-modules should > depend on it, as it's not a hard dependency. It is not a hard-hard dependency for the HDA driver, but without it there is a 60s delay for the detection of HDA-based devices... Samuel
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
On Sun, 2019-07-07 at 17:16 +0200, Samuel Thibault wrote: > Ben Hutchings, le dim. 07 juil. 2019 13:35:20 +0100, a ecrit: > > i915 belongs in fb-modules. I'm not sure that sound-modules should > > depend on it, as it's not a hard dependency. > > It is not a hard-hard dependency for the HDA driver, but without it > there is a 60s delay for the detection of HDA-based devices... I think that could (and should) be avoided by only waiting if request_module() succeeds. And I think all installer configurations that include sound-modules also include fb-modules already. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
Ben Hutchings, le dim. 07 juil. 2019 17:36:03 +0100, a ecrit: > On Sun, 2019-07-07 at 17:16 +0200, Samuel Thibault wrote: > > Ben Hutchings, le dim. 07 juil. 2019 13:35:20 +0100, a ecrit: > > > i915 belongs in fb-modules. I'm not sure that sound-modules should > > > depend on it, as it's not a hard dependency. > > > > It is not a hard-hard dependency for the HDA driver, but without it > > there is a 60s delay for the detection of HDA-based devices... > > I think that could (and should) be avoided by only waiting if > request_module() succeeds. Ah, request_modules() is synchronous, I then wonder what this is waiting for, actually. > And I think all installer configurations that include sound-modules > also include fb-modules already. Probably indeed, but I don't find i915.ko in fb-modules. Samuel
Bug#931561: Failed to load mediatek/mt7610u
Package: firmware-misc-nonfree
Version: 20190114-1
USB Wi-Wi adapter "Archer T2U" does not work.
lsusb output:
Bus 004 Device 002: ID 8087:8001 Intel Corp.
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:8009 Intel Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 148f:761a Ralink Technology, Corp. MT7610U ("Archer T2U"
2.4G+5G WLAN Adapter
lsmod | grep mt76
mt76x0118784 0
mt76 40960 1 mt76x0
mac80211 815104 5 mt76,mt76x0,rt2x00lib,rt2x00usb,rt2800lib
cfg80211 761856 4 mt76x0,rt2x00lib,mac80211,r8188eu
usbcore 290816 9
xhci_hcd,rt2800usb,mt76x0,ehci_pci,usbhid,ehci_hcd,xhci_pci,rt2x00usb,r8188eu
dmesg output:
[ 2028.014840] usb 1-14: new high-speed USB device number 6 using xhci_hcd
[ 2028.178216] usb 1-14: New USB device found, idVendor=148f, idProduct=761a,
bcdDevice= 1.00
[ 2028.178221] usb 1-14: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 2028.178224] usb 1-14: Product: WiFi
[ 2028.178227] usb 1-14: Manufacturer: MediaTek
[ 2028.178229] usb 1-14: SerialNumber: 1.0
[ 2028.307040] usb 1-14: reset high-speed USB device number 6 using xhci_hcd
[ 2028.461948] mt76x0 1-14:1.0: ASIC revision: 7612 MAC revision: 76502000
[ 2028.462534] mt76x0 1-14:1.0: firmware: failed to load mediatek/mt7610u.bin
(-2)
[ 2028.462542] mt76x0 1-14:1.0: Direct firmware load for mediatek/mt7610u.bin
failed with error -2
[ 2028.462825] mt76x0: probe of 1-14:1.0 failed with error -2
--
С уважением,
Евгений.
Bug#931507: kernel-wedge: HDA sound board detection takes 60s in d-i
On Sun, 2019-07-07 at 18:44 +0200, Samuel Thibault wrote: > Ben Hutchings, le dim. 07 juil. 2019 17:36:03 +0100, a ecrit: > > On Sun, 2019-07-07 at 17:16 +0200, Samuel Thibault wrote: > > > Ben Hutchings, le dim. 07 juil. 2019 13:35:20 +0100, a ecrit: > > > > i915 belongs in fb-modules. I'm not sure that sound-modules should > > > > depend on it, as it's not a hard dependency. > > > > > > It is not a hard-hard dependency for the HDA driver, but without it > > > there is a 60s delay for the detection of HDA-based devices... > > > > I think that could (and should) be avoided by only waiting if > > request_module() succeeds. > > Ah, request_modules() is synchronous, I then wonder what this is waiting > for, actually. Device probing might still be partially asynchronous (though for PCI it's synchronous by default). > > And I think all installer configurations that include sound-modules > > also include fb-modules already. > > Probably indeed, but I don't find i915.ko in fb-modules. Yes that's still to be done. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#931564: Kernel Won't Load Firmware?
Package: linux Version: 4.19.37-5 The version: Debian 10 Buster The hardware: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV610/M74 [Mobility Radeon HD 2400 XT] On boot I see this message. In past Debian versions I can either install firmware-amd-graphics to silence the message or ignore it; either way the display would work fine. Jul 7 08:11:45 localhost kernel: [2.232573] [drm] radeon kernel modesetting enabled. Jul 7 08:11:45 localhost kernel: [2.232719] [drm:radeon_pci_probe [radeon]] *ERROR* radeon kernel modesetting for R600 or later requires firmware installed Jul 7 08:11:45 localhost kernel: [2.232786] See https://wiki.debia n.org/Firmware for information about missing firmware With Buster things seem to fall over and die: Jul 7 08:11:46 localhost systemd[1]: Starting GNOME Display Manager... Jul 7 08:11:47 localhost systemd[1]: Started GNOME Display Manager. Jul 7 08:11:50 localhost systemd[1]: Started Session c1 of user Debian-gdm. Jul 7 08:11:54 localhost gnome-shell[571]: Failed to create backend: Could not find a primary drm kms device Jul 7 08:11:54 localhost gnome-session[562]: gnome-session- binary[562]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 Jul 7 08:11:54 localhost gnome-session-binary[562]: Unrecoverable failure in required component org.gnome.Shell.desktop Jul 7 08:11:54 localhost gnome-session-binary[562]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 I decide to try to see if the firmware makes a difference. I enable nonfree, install firmware-amd-graphics, and reboot but nothing has changed. The exact same messages as above still appears; below. It's almost like the kernel still couldn't find it, even after it had been installed. I compiled a kernel from upstream which was able to load the firmware and get a graphical interface. Since replacing the kernel solved it I'm reporting this against the kernel. Jul 7 08:30:10 localhost kernel: [2.198524] [drm] radeon kernel modesetting enabled. Jul 7 08:30:10 localhost kernel: [2.198675] [drm:radeon_pci_probe [radeon]] *ERROR* radeon kernel modesetting for R600 or later requires firmware installed Jul 7 08:30:10 localhost kernel: [2.198745] See https://wiki.debia n.org/Firmware for information about missing firmware Jul 7 08:30:12 localhost systemd[1]: Starting GNOME Display Manager... Jul 7 08:30:13 localhost systemd[1]: Started GNOME Display Manager. Jul 7 08:30:16 localhost systemd[1]: Started Session c1 of user Debian-gdm. Jul 7 08:30:19 localhost gnome-shell[581]: Failed to create backend: Could not find a primary drm kms device Jul 7 08:30:20 localhost gnome-session[573]: gnome-session- binary[573]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1 Jul 7 08:30:20 localhost gnome-session-binary[573]: Unrecoverable failure in required component org.gnome.Shell.desktop Jul 7 08:30:20 localhost gnome-session-binary[573]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
Bug#931590: linux-image-cloud-amd64: new build for 4.19.37-5 ?
Package: linux-image-cloud-amd64 Version: 4.19+105~bpo9+1 Severity: normal Dear Maintainer, In reference to this CVE https://security-tracker.debian.org/tracker/CVE-2019-11478 Will there be a build for the linux image (cloud) for 4.19.37-5? which is marked as fixing this issue ? Thanks -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-0.bpo.4-cloud-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages linux-image-cloud-amd64 depends on: ii linux-image-4.19.0-0.bpo.5-cloud-amd64 4.19.37-4~bpo9+1 linux-image-cloud-amd64 recommends no packages. linux-image-cloud-amd64 suggests no packages. -- no debconf information
Bug#891038: Please?
This would be very handy. Please please?
Bug#931590: marked as done (linux-image-cloud-amd64: new build for 4.19.37-5 ?)
Your message dated Mon, 08 Jul 2019 03:09:29 +0100 with message-id and subject line Re: Bug#931590: linux-image-cloud-amd64: new build for 4.19.37-5 ? has caused the Debian Bug report #931590, regarding linux-image-cloud-amd64: new build for 4.19.37-5 ? 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.) -- 931590: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931590 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-image-cloud-amd64 Version: 4.19+105~bpo9+1 Severity: normal Dear Maintainer, In reference to this CVE https://security-tracker.debian.org/tracker/CVE-2019-11478 Will there be a build for the linux image (cloud) for 4.19.37-5? which is marked as fixing this issue ? Thanks -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-0.bpo.4-cloud-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages linux-image-cloud-amd64 depends on: ii linux-image-4.19.0-0.bpo.5-cloud-amd64 4.19.37-4~bpo9+1 linux-image-cloud-amd64 recommends no packages. linux-image-cloud-amd64 suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- On Mon, 2019-07-08 at 11:23 +1000, Dean Hamstead wrote: > Package: linux-image-cloud-amd64 > Version: 4.19+105~bpo9+1 > Severity: normal > > Dear Maintainer, > > In reference to this CVE > https://security-tracker.debian.org/tracker/CVE-2019-11478 > > Will there be a build for the linux image (cloud) for 4.19.37-5? which > is marked as fixing this issue ? Please don't open a bug to ask a question. The answer is at the bottom of that page, anyway. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part --- End Message ---
