Bug#892057: Fwd: Re: TS-x09 fails to boot when obtaining MAC

The fix is in Linus' tree since v.16-rc5: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13a55372b64e00e564a08d785ca87bd9d454ba30 I don't see it in 4.9 stable or the stable queue. Will Greg pick it up automatically because of the Fixes: info or do we have to let

Re: [PATCH v4] scripts/package/builddeb: split generating packaging and build

On Wed, 2018-03-28 at 11:58 +0300, Riku Voipio wrote: [...] > One option: > > +++ b/scripts/package/mkdebian > cat < debian/rules > -#!/usr/bin/make -f > #!$(which $MAKE) -f [..] Shebang lines are interpreted by the kernel, not by a shell. So you can't do anything clever like that. Ben. --

Bug#894310: Please build the thunderbolt-net module

Package: linux Severity: wishlist File: /boot/config-4.15.0-2-amd64 X-Debbugs-CC: sin...@nefkom.net I'ld like to play-test the thunderbolt-net module. Please consider enabling CONFIG_THUNDERBOLT_NET. Thanks -richy.

Bug#886049: The problem with the splice() depends on the used SMB-Version

Since this Bug only appears if the file is copied from a CIFS-Share it now was seen that the error depends on the used SMB-Version. If the share is mounted with the option vers=2.0, small files can be copied without blocking. If a higher SMB-Version than 2.0 is used to mount the share, e.g.

Bug#894089: linux-image-4.9.0-6-amd64: Please fix max supported i915 screen (not display) resolution

Thank you for the contact, Ben. I will follow up with them. FWIW, this patch does not even seem to work properly. While it does change the max supported size reported by xrandr, trying to use the space just results in an error.

Re: armel/marvell kernel size

Hello guys, I believe the problem we are facing on Kirkwood with stretch is the same I had with iop32 and other folks with ixp4xx. As the support for iop32 on Wheezy is under EOL, do we have any hopes to solve the kernel size issue common for all this architectures or it's time to replace our nas?

Bug#894294: Comment in the source of unmkinitramfs is ambiguous

Source: initramfs-tools Version: 0.130 Severity: wishlist The line 56-59 of unmkinitramfs goes: # There may be a prepended uncompressed archive. cpio # won't tell us the true size of this so we have to # parse the headers and padding ourselves. This is # very roughly based on

Re: D-Link DNS-323 support dropped in Debian stretch

On Wed, Mar 28, 2018 at 5:40 PM, Ian Campbell wrote: > On Tue, 2018-03-27 at 21:25 +0300, Aaro Koskinen wrote: >> Hi, >> >> On Mon, Mar 26, 2018 at 07:36:26PM +0900, Roger Shimizu wrote: >> > There's one possibility that can bring back qnap, or even D-Link >> > DNS device: >> > -

Re: armel/marvell kernel size

On Mar 27, 2018, at 2:08 PM, Rogério Brito wrote: > On 2018-03-27 17:29, Rick Thomas wrote: >> On Mar 27, 2018, at 1:04 PM, Rogério Brito wrote: >>> As a related subject, I could compile a more stripped down version of >>> the armel kernel, put it for

Re: [PATCH v4] scripts/package/builddeb: split generating packaging and build

On 27 March 2018 at 18:23, Masahiro Yamada wrote: > Riku, > > 2018-03-27 22:28 GMT+09:00 Riku Voipio : > >>> If I use GNU Make 4.2 >>> >>> $ cat deb_pkg_log.txt >>> MAKEFLAGS for deb-pkg: rR -I/home/masahiro/ref/linux -j8 >>>

Re: D-Link DNS-323 support dropped in Debian stretch

On Tue, 2018-03-27 at 21:25 +0300, Aaro Koskinen wrote: > Hi, > > On Mon, Mar 26, 2018 at 07:36:26PM +0900, Roger Shimizu wrote: > > There's one possibility that can bring back qnap, or even D-Link > > DNS device: > > - create a new flavour for armel, such as armel-none-mini > > - the new flavour