Processed: reassign 785494 to src:linux
Processing commands for cont...@bugs.debian.org: > reassign 785494 src:linux 4.0.2-1 Bug #785494 [linux-image-4.0.0-1-amd64] [linux-image-4.0.0-1-amd64] USB3 device errors (on empty ports) Bug reassigned from package 'linux-image-4.0.0-1-amd64' to 'src:linux'. No longer marked as found in versions linux/4.0.2-1. Ignoring request to alter fixed versions of bug #785494 to the same values previously set Bug #785494 [src:linux] [linux-image-4.0.0-1-amd64] USB3 device errors (on empty ports) Marked as found in versions linux/4.0.2-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 785494: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785494 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.143183020229111.transcr...@bugs.debian.org
Bug#785494: [linux-image-4.0.0-1-amd64] USB3 device errors (on empty ports)
Package: linux-image-4.0.0-1-amd64 Version: 4.0.2-1 For the past few days I have noticed that my keyboard is non-functional for about 60 seconds during boot of a Sid install. I was initially writing up a report specifically about that, but I have found some info in dmesg about the underlying cause - the keyboard and mouse are connected to a pair of USB3 ports, and prior to their detection, the following occurs: > [2.502871] Switched to clocksource tsc > [ 16.347077] usb 3-3: device descriptor read/all, error -110 > [ 16.459202] usb 3-3: new high-speed USB device number 3 using xhci_hcd > [ 26.602170] usb 3-3: device descriptor read/all, error -110 > [ 26.714160] usb 3-3: new high-speed USB device number 4 using xhci_hcd > [ 31.737562] usb 3-3: device descriptor read/8, error -110 > [ 36.865049] usb 3-3: device descriptor read/8, error -110 > [ 37.081325] usb 3-3: new high-speed USB device number 5 using xhci_hcd > [ 42.104855] usb 3-3: device descriptor read/8, error -110 > [ 47.23] usb 3-3: device descriptor read/8, error -110 > [ 47.336341] usb usb3-port3: unable to enumerate USB device (The mouse and keyboard are successfully detected at usb 3-9 and 3-10 immediately following this). The mouse and keyboard are the only USB devices connected. I typically update this Sid install at least once daily, and I believe the problem must have been introduced by an update from the 12th or 13th of this month. Here's a copy of my apt update history from these two days: > Start-Date: 2015-05-12 13:26:01 > Install: firmware-linux-free:amd64 (3.3, automatic), linux-kbuild-4.0:amd64 > (4.0.2-1, automatic), linux-image-4.0.0-1-amd64:amd64 (4.0.2-1, automatic), > linux-headers-4.0.0-1-common:amd64 (4.0.2-1, automatic), > linux-headers-4.0.0-1-amd64:amd64 (4.0.2-1, automatic), > linux-compiler-gcc-4.9-x86:amd64 (4.0.2-1, automatic), irqbalance:amd64 > (1.0.6-3, automatic) > Upgrade: firmware-linux-nonfree:amd64 (0.43, 0.44), linux-image-amd64:amd64 > (3.16+63, 4.0+64), libx11-protocol-perl:amd64 (0.56-6, 0.56-7), > linux-headers-amd64:amd64 (3.16+63, 4.0+64), apache2-bin:amd64 (2.4.12-1, > 2.4.12-2), linux-libc-dev:amd64 (3.16.7-ckt9-3, 4.0.2-1), rsyslog:amd64 > (8.4.2-1+b1, 8.9.0-3) > End-Date: 2015-05-12 13:26:49 > > Start-Date: 2015-05-12 19:07:31 > Upgrade: libegl1-mesa:amd64 (10.4.2-2, 10.5.5-1), libgl1-mesa-dri:amd64 > (10.4.2-2, 10.5.5-1), libopenal1:amd64 (1.16.0-2, 1.16.0-3), > libglapi-mesa:amd64 (10.4.2-2, 10.5.5-1), mesa-vdpau-drivers:amd64 (10.4.2-2, > 10.5.5-1), libgles2-mesa:amd64 (10.4.2-2, 10.5.5-1), libopenal-data:amd64 > (1.16.0-2, 1.16.0-3), libgl1-mesa-glx:amd64 (10.4.2-2, 10.5.5-1), > libxatracker2:amd64 (10.4.2-2, 10.5.5-1), libgles1-mesa:amd64 (10.4.2-2, > 10.5.5-1), libwayland-egl1-mesa:amd64 (10.4.2-2, 10.5.5-1), libgbm1:amd64 > (10.4.2-2, 10.5.5-1) > End-Date: 2015-05-12 19:07:34 > > Start-Date: 2015-05-13 01:07:57 > Upgrade: geoip-database:amd64 (20150413-1, 20150512-1), dbus:amd64 (1.8.16-1, > 1.8.16-2), libglib2.0-0:amd64 (2.44.0-2, 2.44.0-3), python-cryptography:amd64 > (0.8.2-2, 0.8.2-3), libdbus-1-3:amd64 (1.8.16-1, 1.8.16-2), > libglib2.0-data:amd64 (2.44.0-2, 2.44.0-3), dbus-x11:amd64 (1.8.16-1, > 1.8.16-2), libglib2.0-bin:amd64 (2.44.0-2, 2.44.0-3) > End-Date: 2015-05-13 01:08:00 > > Start-Date: 2015-05-13 13:39:53 > Upgrade: libnet-ssleay-perl:amd64 (1.65-1+b1, 1.68-1), libwebpmux1:amd64 > (0.4.3-1.2, 0.4.3-1.3), libwebpdemux1:amd64 (0.4.3-1.2, 0.4.3-1.3), > libwebp5:amd64 (0.4.3-1.2, 0.4.3-1.3), console-setup:amd64 (1.125, 1.126), > console-setup-linux:amd64 (1.125, 1.126), libsqlite3-0:amd64 (3.8.10-1, > 3.8.10.1-1), libnss3:amd64 (3.17.2-1.1, 3.19-1), keyboard-configuration:amd64 > (1.125, 1.126), libdebconfclient0:amd64 (0.192, 0.193) > End-Date: 2015-05-13 13:39:58 > > Start-Date: 2015-05-13 20:02:14 > Upgrade: gir1.2-wnck-3.0:amd64 (3.4.9-3, 3.14.0-2), > gir1.2-gst-plugins-base-1.0:amd64 (1.4.4-2, 1.4.5-2), > libgstreamer-plugins-base1.0-0:amd64 (1.4.4-2, 1.4.5-2), > gstreamer1.0-plugins-base:amd64 (1.4.4-2, 1.4.5-2), gstreamer1.0-x:amd64 > (1.4.4-2, 1.4.5-2), libwnck-3-0:amd64 (3.4.9-3, 3.14.0-2), > libwildmidi-config:amd64 (0.3.7-1, 0.3.8-2), libwildmidi1:amd64 (0.3.7-1, > 0.3.8-2), libwnck-3-common:amd64 (3.4.9-3, 3.14.0-2), iceweasel:amd64 > (31.6.0esr-1, 38.0-1), iceweasel-l10n-en-gb:amd64 (31.6.0esr-1, 38.0-1), > liborc-0.4-0:amd64 (0.4.22-1, 0.4.23-2), gstreamer1.0-plugins-ugly:amd64 > (1.4.4-2+b1, 1.4.5-2), gstreamer1.0-plugins-bad:amd64 (1.4.4-2.1+b1, > 1.4.5-2), gstreamer1.0-pulseaudio:amd64 (1.4.4-2, 1.4.5-2), > libgstreamer1.0-0:amd64 (1.4.4-2, 1.4.5-2), gstreamer1.0-plugins-good:amd64 > (1.4.4-2, 1.4.5-2), gir1.2-gstreamer-1.0:amd64 (1.4.4-2, 1.4.5-2), > libgstreamer-plugins-bad1.0-0:amd64 (1.4.4-2.1+b1, 1.4.5-2) > End-Date: 2015-05-13 20:02:20 > > Start-Date: 2015-05-13 23:58:31 > Upgrade: libgssapi-krb5-2:amd64 (1.12.1+dfsg-19, 1.12.1+dfsg-20), > libkrb5-3:amd64 (1.12.1+dfsg-19,
Re: linux: give back on ppc64el
On Sat, May 16, 2015 at 19:18:35 +0100, Ben Hutchings wrote: > linux failed to build from source on ppc64el due to a regression in > gcc-4.9 (#785066). This is fixed in gcc-4.9/4.9.2-17. > > Please ensure that buildds are upgraded, then: > > gb linux_4.0.2-1 . ppc64el > jcristau@wuiet:~$ wb gb linux . ppc64el . --extra-depends 'gcc-4.9 (>= 4.9.2-17)' Cheers, Julien signature.asc Description: Digital signature
Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot
On May 16, 2015, at 12:58 PM, Rick Thomas wrote:
>
> On May 16, 2015, at 6:02 AM, Ben Hutchings wrote:
>
>> This is not implemented directly by the init system. util-linux
>> installs the script/lib/udev/hwclock-set and a udev rule that runs it
>> for each RTC device. However, the hwclock-set script does nothing if
>> systemd is running.
>
> curiouser and curiouser…
>
> Looking at the code in /lib/udev/hwclock-set, I can’t see that it would would
> ever do anything useful (except by chance) in the case like mine where there
> are two rtc devices, only one of which should actually be used to set system
> time at boot.
>
> In particular, it goes to some effort to source /etc/default/rcS and
> /etc/default/hwclock, but it pays no attention to the HCTOSYS_DEVICE
> parameter.
>
> It appears to set the system time from each RTC device in turn as it
> discovers them. So system time ends up set by the last RTC to be discovered.
> If the right one happens to be last, that’s good. But that’s not guaranteed.
Looking further, I find that what I said is not quite true. hwclock-set only
gets called for /dev/rtc0, i.e. the *first* one to be discovered. This happens
in /lib/udev/rules.d/85-hwclock.rules. There is provision in
/lib/udev/rules.d/50-udev-default.rules to swing the /dev/rtc symlink to the
device that has ATTR{hctosys}==“1”, but that doesn’t fix the problem at hand,
because the symlink is not used anywhere in hwclock-set.
Fascinating!
Rick
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/c4618e4b-58a9-4f5d-8cbd-7967f1a9c...@pobox.com
Bug#714471: marked as done (linux-image-3.9-1-amd64: No sound from internal speakers with hda intel)
Your message dated Sat, 16 May 2015 17:04:48 -0300 with message-id and subject line Re: linux-image-3.9-1-amd64: No sound from internal speakers with hda intel has caused the Debian Bug report #714471, regarding linux-image-3.9-1-amd64: No sound from internal speakers with hda intel 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.) -- 714471: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714471 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:linux Version: 3.9.6-1 Severity: normal Dear linux maintainers, the 3.9 kernel has introduced a regression compared with the 3.8 kernel (and earlier), now my internal speakers produce no sound (playing with the several pulseaudio and alsa mixers produces no results). I have attached the reportbug-generated reports for both 3.9-1 and 3.8-1, and also the alsa-info.sh output for both kernels. If any other information is required, I will happily provide it. -- Saludos, Felipe Sateler report.tgz Description: GNU Zip compressed data --- End Message --- --- Begin Message --- On Sat, 29 Jun 2013 13:56:02 -0400 Felipe Sateler wrote: > Package: src:linux > Version: 3.9.6-1 > Severity: normal > > Dear linux maintainers, the 3.9 kernel has introduced a regression > compared with the 3.8 kernel (and earlier), now my internal speakers > produce no sound (playing with the several pulseaudio and alsa mixers > produces no results). > > I have attached the reportbug-generated reports for both 3.9-1 and > 3.8-1, and also the alsa-info.sh output for both kernels. > > If any other information is required, I will happily provide it. I have sound from my cards since a long time now, so this bug is no longer an issue. Saludos--- End Message ---
Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot
On May 16, 2015, at 6:02 AM, Ben Hutchings wrote: > This is not implemented directly by the init system. util-linux > installs the script/lib/udev/hwclock-set and a udev rule that runs it > for each RTC device. However, the hwclock-set script does nothing if > systemd is running. curiouser and curiouser… Looking at the code in /lib/udev/hwclock-set, I can’t see that it would would ever do anything useful (except by chance) in the case like mine where there are two rtc devices, only one of which should actually be used to set system time at boot. In particular, it goes to some effort to source /etc/default/rcS and /etc/default/hwclock, but it pays no attention to the HCTOSYS_DEVICE parameter. It appears to set the system time from each RTC device in turn as it discovers them. So system time ends up set by the last RTC to be discovered. If the right one happens to be last, that’s good. But that’s not guaranteed. Enjoy! Rick -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c5140f9d-0a22-415a-8a0e-9b77b2da2...@pobox.com
Bug#775812: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
On Tue, 2015-05-12 at 14:03 -0400, Deepee Khosla wrote: > Now I've discovered your bug report, but I'm still not sure what > action I should take to get my laptop to power down. Do you have any > advice for me? As the reporter of this bug, Miguel Ortiz Lombardía, on Mon, 30 Mar 2015 23:28:53 +0200 wrote: > [...] > I must say that eventually after much reading I solved my problem by > tweaking the BIOS and making sure that "Wake on WLAN" was inactive... > I still don't understand why this manipulation had not been necessary > previously, but anyway, that's not important to me : I don't need/want > to wake up my computer when a known wifi becomes available... I can confirm that disabling “Wake on WLAN” in the notebook's BIOS settings solved the problem for me as well. If you really rely on this option, then I can only help you by advising you to look into the notebook's wireless or wired drivers. I have the suspicion that the bug is caused by one of these. Hope this helps. Best, Tim -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431805350.4173.12.ca...@tim-notebook.timvandekamp.nl
Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot
On May 16, 2015, at 6:02 AM, Ben Hutchings wrote: >> If that’s correct, I’m not sure if even sysvinit >> with /etc/default/hwclock could have done the right thing in my case. > > This is not implemented directly by the init system. util-linux > installs the script /lib/udev/hwclock-set and a udev rule that runs it > for each RTC device. However, the hwclock-set script does nothing if > systemd is running. Thank you Ben. As usual, your clear explanation has helped me to better understand my problem and pointed me in new directions. Why does it do that? Is there some systemd feature that should make setting the system time unnecessary? If so, it’s not working. Thanks! Rick -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6a59d631-3182-4419-aab8-41ea2e2a3...@pobox.com
linux: give back on ppc64el
linux failed to build from source on ppc64el due to a regression in gcc-4.9 (#785066). This is fixed in gcc-4.9/4.9.2-17. Please ensure that buildds are upgraded, then: gb linux_4.0.2-1 . ppc64el -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Bug#785422: amd64: Please enable CONFIG_SND_SOC_INTEL_BROADWELL_MACH
On Sat, 16 May 2015 05:41:40 +0200 Sebastian Reichel wrote: > Source: linux > Version: 4.0.2-1 > Severity: wishlist > > Hi, > > Please enable CONFIG_SND_SOC_INTEL_BROADWELL_MACH. Broadwell processors > are built into e.g. the Lenovo Thinkpad X250, which is available since > February. I'm not speaking for the kernel team (which I'm not part of) but I own a X250 and wrote a page [1] about Linux support. I'm unsure what CONFIG_SND_SOC_INTEL_BROADWELL_MACH is supposed to be used for, but it's not needed for sound support on X250. At first sight this option looks related to Intel Smart Sound Technology (Intel SST) which looks to be a specific DSP for usages a bit like Siri on the iOS platforms. I don't think the CPU in the X250 has this technology, althought it might be useful for Core M Broadwell ultrabooks. In any case, loading the modules on my X250 doesn't do anything and don't show anything in dmesg either. So I don't say enabling it is bad, but I don't think it'll improve the experience on your ThinkPad. [1] http://www.corsac.net/X250/ Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#711108: linux-image-* should suggest linux-tools-*
On Sat, 2015-05-16 at 09:50 +0200, Piotr Engelking wrote: > tags 711108 + patch > thanks > > Untested patch attached. > > It may also be interesting to notice that apt already attempts to > prevent automatic removal of linux-tools matching an installed kernel, > but fails, since it assumes a version format which is no longer in use: > > /etc/kernel/postinst.d/apt-auto-removal > /etc/apt/apt.conf.d/01autoremove [...] That's an Ubuntu-ism. They use the wrong version format for their linux-tools package. Anyway, there's no reason to prevent auto-removal of this package as it's obviously not required to boot. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot
On Sat, 2015-05-16 at 05:01 -0700, Rick Thomas wrote: > On May 16, 2015, at 3:13 AM, Ian Campbell wrote: > > > On Fri, 2015-05-15 at 17:55 -0700, Rick Thomas wrote: > > [...] > >> There does not seem to be any way to over-ride this. There's code in > >> /etc/default/hwclock > >> that would do part of the work in a sysvinit setup, but it seems to be > >> ignored under systemd. > > [...] > >> Presumably, there is systemd magic that could do the same thing as was > >> available under > >> sysvinit. Is there anybody out there with enough systemd foo to tell me > >> how to do that? > > > > I think that if systemd is not supporting /etc/default/hwclock and the > > replacement mechanism is not apparent after some searching of the docs > > etc then this should be considered a systemd bug (either in the docs if > > not an actual code bug or missing feature). > > > > Perhaps someone on the pkg-systemd-maintainers@alioth list will be > > better able to advise on if/how systemd solves this problem? > > > > Ian. > > Thanks, Ian, for the prompt response. I’ve submitted a separate bug > to systemd asking for a fix. However, it may not be possible to do > this with systemd… Looking at the dmesg output, it looks like the > decision to use /dev/rtc0 is being made at the kernel level, before > systemd even gets started. That's right, the kernel optionally reads an RTC into the system time at boot (CONFIG_RTC_HCTOSYS) and the name of the RTC to use is also part of the kernel configuration (CONFIG_RTC_HCTOSYS_DEVICE). > If that’s correct, I’m not sure if even sysvinit > with /etc/default/hwclock could have done the right thing in my case. This is not implemented directly by the init system. util-linux installs the script /lib/udev/hwclock-set and a udev rule that runs it for each RTC device. However, the hwclock-set script does nothing if systemd is running. > Do you happen to know why the patch I came across never made it into > the kernel? Don't know. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot
On May 16, 2015, at 3:13 AM, Ian Campbell wrote: > On Fri, 2015-05-15 at 17:55 -0700, Rick Thomas wrote: > [...] >> There does not seem to be any way to over-ride this. There's code in >> /etc/default/hwclock >> that would do part of the work in a sysvinit setup, but it seems to be >> ignored under systemd. > [...] >> Presumably, there is systemd magic that could do the same thing as was >> available under >> sysvinit. Is there anybody out there with enough systemd foo to tell me how >> to do that? > > I think that if systemd is not supporting /etc/default/hwclock and the > replacement mechanism is not apparent after some searching of the docs > etc then this should be considered a systemd bug (either in the docs if > not an actual code bug or missing feature). > > Perhaps someone on the pkg-systemd-maintainers@alioth list will be > better able to advise on if/how systemd solves this problem? > > Ian. Thanks, Ian, for the prompt response. I’ve submitted a separate bug to systemd asking for a fix. However, it may not be possible to do this with systemd… Looking at the dmesg output, it looks like the decision to use /dev/rtc0 is being made at the kernel level, before systemd even gets started. If that’s correct, I’m not sure if even sysvinit with /etc/default/hwclock could have done the right thing in my case. Do you happen to know why the patch I came across never made it into the kernel? Thanks, again! Rick -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/80f682f1-e5b8-4195-b6bb-be1e1c2af...@pobox.com
Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot
On Fri, 2015-05-15 at 17:55 -0700, Rick Thomas wrote: [...] > There does not seem to be any way to over-ride this. There's code in > /etc/default/hwclock > that would do part of the work in a sysvinit setup, but it seems to be > ignored under systemd. [...] > Presumably, there is systemd magic that could do the same thing as was > available under > sysvinit. Is there anybody out there with enough systemd foo to tell me how > to do that? I think that if systemd is not supporting /etc/default/hwclock and the replacement mechanism is not apparent after some searching of the docs etc then this should be considered a systemd bug (either in the docs if not an actual code bug or missing feature). Perhaps someone on the pkg-systemd-maintainers@alioth list will be better able to advise on if/how systemd solves this problem? Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431771195.5748.44.ca...@debian.org
radeon firmware does not work with LG Philips LVDS (firmware-linux-nonfree)
Since my latest upgrade to Debian 8 my X server does no more start without proprietary firmware any more (see: https://bugs.freedesktop.org/show_bug.cgi?id=90474, https://bugs.freedesktop.org/show_bug.cgi?id=90475 ). However the proprietary firmware does not perform as well as it would be needed. While I can still use my notebook with various external monitors over the HDMI and VGA interfaces the integrated LVDS stays black all the time (whether I boot with external monitors or not). So no way to use my notebook as notebook any more! The integrated display seems to switch from black to black doing something whenever the X server starts or whenever I try out a new graphics mode but actually nothing gets displayed. xrandr reports the LVDS display to be functional though it stays black in deed. integrated monitor: LG Philips LVDS graphics card: ATI Mobility Radeon HD 2700 package: firmware-linux-nonfree_0.43_all.deb What can I do? To whom can I turn in order to get the firmware fixed? Elmar -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55570f7e.3080...@gmail.com
Bug#785435: init: touch not found
Package: initramfs-tools Version: 0.120 Severity: wishlist I swear I saw something about init: touch not found fly past on my screen, but I have no log file to prove it. I wish there was a log file. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87382wvquo@jidanni.org
Bug#711108: linux-image-* should suggest linux-tools-*
tags 711108 + patch
thanks
Untested patch attached.
It may also be interesting to notice that apt already attempts to
prevent automatic removal of linux-tools matching an installed kernel,
but fails, since it assumes a version format which is no longer in use:
/etc/kernel/postinst.d/apt-auto-removal
/etc/apt/apt.conf.d/01autoremove
On 4 June 2013 at 21:03, Ben Hutchings wrote:
> On Tue, Jun 04, 2013 at 08:46:50PM +0200, Piotr Engelking wrote:
>> Source: linux
>> Severity: wishlist
>>
>> Please consider having the linux-image-${version}-* packages suggesting
>> the matching linux-tools-${version} package. This would help users to keep
>> them in sync.
>
> It might be a useful hint. However the linux-tools meta-package is
> a more effective way to keep linux-tools-* up to date (unless you
> install the kernel from experimental).
>
> Ben.
>
> --
> Ben Hutchings
> We get into the habit of living before acquiring the habit of thinking.
> - Albert Camus
diff --git a/debian/templates/control.image.type-plain.in b/debian/templates/control.image.type-plain.in
index 29306e3..0c29b32 100644
--- a/debian/templates/control.image.type-plain.in
+++ b/debian/templates/control.image.type-plain.in
@@ -3,7 +3,7 @@ Provides: linux-modules-@abiname@@localversion@
Pre-Depends: debconf | debconf-2.0
Depends: kmod | module-init-tools, linux-base (>= 3~), ${misc:Depends}
Recommends: firmware-linux-free (>= 3~), ${kernel:Recommends}
-Suggests: linux-doc-@version@, debian-kernel-handbook
+Suggests: linux-tools-@version@, linux-doc-@version@, debian-kernel-handbook
Breaks: at (<< 3.1.12-1+squeeze1)
Description: Linux @upstreamversion@ for @class@
The Linux kernel @upstreamversion@ and modules for use on @longclass@.
Processed: Re: Bug#711108: linux-image-* should suggest linux-tools-*
Processing commands for cont...@bugs.debian.org: > tags 711108 + patch Bug #711108 [src:linux] linux-image-* should suggest linux-tools-* Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 711108: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711108 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.143176264424556.transcr...@bugs.debian.org
