[stretch] ABI bump for 4.9 with retpoline support?
Hi kernel team I am currently working on 4.9.81 (and will work on 4.9.82 when it's out) for stretch-pu. Fixes for Spectre started appearing in recent versions (especially retpoline) and Moritz has worked a lot on gcc with retpoline support, so it looks that we'll be able to ship a kernel with retpoline enabled and functional in stretch-pu before the next point release. It doesn't seem that building with a retpoline-aware gcc will bump the ABI by itself, but do we still want to do it? There's a bunch of ABI breaks in 4.9.81 again, and we ignored/reverted a lot of them since 4.9.65+kaiser, so maybe it'll be a good idea at one point, but I don't have a strong opinion on this right now. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#890393: linux-image-4.9.0-5-amd64: backport of the megaraid_sas driver for Debian stable
Package: src:linux Version: 4.9+80+deb9u3 Severity: important Hi, I copy /usr/src/linux-4.14.19/drivers/scsi/megaraid/ to /usr/src/linux-4.9.81/drivers/scsi/megaraid/. I compile the kernel and is OK! Please backport to Debian 9.4, for instalation. Regards, Doru Iorgulescu dmesg Description: Binary data
Processed: forcibly merging 890034 890393
Processing commands for cont...@bugs.debian.org:
> forcemerge 890034 890393
Bug #890034 {Done: Salvatore Bonaccorso } [src:linux]
linux-image-4.9.0-5-amd64: No driver support for Perc H740P RAID Controller
Bug #890034 {Done: Salvatore Bonaccorso } [src:linux]
linux-image-4.9.0-5-amd64: No driver support for Perc H740P RAID Controller
Marked as fixed in versions linux/4.14.13-1 and linux/4.14.13-1~bpo9+1.
The source linux and version 4.9+80+deb9u3 do not appear to match any binary
packages
The source linux and version 4.9.30-2+deb9u5 do not appear to match any binary
packages
Marked as found in versions linux/4.9+80+deb9u3 and linux/4.9.30-2+deb9u5.
Bug #890393 [src:linux] linux-image-4.9.0-3-amd64: backport of the megaraid_sas
driver for Debian stable
Marked Bug as done
Marked as fixed in versions linux/4.11-1~exp1.
The source linux and version 4.9+80+deb9u3 do not appear to match any binary
packages
The source linux and version 4.9.30-2+deb9u5 do not appear to match any binary
packages
Marked as found in versions linux/4.9.30-2 and linux/4.9.65-3+deb9u2.
Merged 890034 890393
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
890034: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890034
890393: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890393
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#890034: comment on 890034
Hi Phil, On Thu, Feb 15, 2018 at 07:18:14PM +, Phil Lavin wrote: > Thanks for updating the issue, Salvatore. The motivation behind > raising the bug was to ask that the driver be backported to 4.9. > Dell's Gen 14 hardware with Perc H740P has only been around a few > months and, given that Debian 10 is a fair way away from being > released, I suspect that there will be a raft of users wishing to > install Debian on this hardware in the not so distant future who > will be unable to do so without manually compiling and loading the > driver from Dell into both the installer and the installed OS. > > If a bug isn't the right way to request a backport, can you advise > how it should be done? Filling a bug is absolutely fine, actually. My updating on the bug was to mark it as fixed where the support for the respective support for H740P was added. I have not looked at which patches would be needed and how much involving they are (the bug you referenced at least seem to indicate that trying to do so for an older 4.4 would require large backport seris involving refactoring of the code) Hope this clarifies my updates to the bug! Regards, Salvatore
Bug#884871: rpc.svcgssd starts while disabled in /etc/default/nfs-kernel-server
rpc.svcgssd is also needed on clients in order to support NFSv4.0 callbacks. It was moved from nfs-kernel-server to nfs-common for this reason. See Debian bug #651558. Apparently the task of starting rpc.svcgssd under SysV init is still entrusted to the nfs-kernel-server package. Maybe something needs to be done about that. If you are using systemd, you may find the file systemd/README in the source package to be of interest. The relevant portion reads: "rpc.gssd and rpc.svcgssd are assumed to be needed if /etc/krb5.keytab is present. If a site needs this file present but does not want the gss daemons running, it should create /etc/systemd/system/rpc-gssd.service.d/01-disable.conf and /etc/systemd/system/rpc-svcgssd.service.d/01-disable.conf containing [Unit] ConditionNull=false " I think this (or equivalent information; I'd have suggested "systemctl disable" instead of the above approach) should be included somewhere under /usr/share/doc/nfs-common/. As for the side question on how to disable version 4.0 but not 4.1: try passing --no-nfs-version=4.0 to nfsd. (I haven't tested this myself yet, only read utils/nfsd/nfsd.c. The man page is too terse about this.)
Bug#886858: linux-image-3.16.0-5-686-pae: Kernle fails to boot/Kernle-Panic
3.16.54 upstream kernel doesn't work too.
Bug#890601: Source Package Doesn't Contain Source
Package: firmware-linux-free Version: 3.4 It appears that the source package for firmware-linux-free contains the firmware binaries downloaded from linux-firmware.git. Shouldn't a source package contain, you know, the source code? Especially as some of the firmwares are GPL-licensed, and Debian is shipping only the binaries. In looking into other distros it seems that that most don't compile the firmware from source either. As a result people don't notice when the tools to do so break. For example: The as31 assembler needed to build the usbdux firmware currently segfaults. Reference bug #887320.
Re: [stretch] ABI bump for 4.9 with retpoline support?
On Fri, 2018-02-16 at 11:54 +0100, Yves-Alexis Perez wrote: > > There's a bunch of ABI breaks in 4.9.81 again, and we ignored/reverted a lot > of them since 4.9.65+kaiser, so maybe it'll be a good idea at one point, but I > don't have a strong opinion on this right now. I've pushed my work to the stretch branch. It builds fine on x86 and powerpc after some fixes. When built with gcc-6 just uploaded to security-master, retpoline is enabled: /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline Depending on the opinion, we can either revert the various ABI fixes and bump the ABI, or try an upload as-is. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#890601: firmware-free: Source Package Doesn't Contain Source
Hi Jason, Jason Self wrote: > It appears that the source package for firmware-linux-free contains the > firmware binaries downloaded from linux-firmware.git. Shouldn't a source > package contain, you know, the source code? Especially as some of the > firmwares are GPL-licensed, and Debian is shipping only the binaries. Can you be more specific? Which file have you found in the source package that does not have corresponding source included? > In looking into other distros it seems that that most don't compile the > firmware from source either. As a result people don't notice when the tools > to do so break. For example: The as31 assembler needed to build the usbdux > firmware currently segfaults. Reference bug #887320. That sounds like a different bug report: "package doesn't build from source". Thanks and hope that helps, Jonathan
Bug#890601: firmware-free: Source Package Doesn't Contain Source
Jonathan Nieder wrote .. > Can you be more specific? Which file have you found in the source > package that does not have corresponding source included? OK; perhaps this bug needs re-titling. There seems to be "a" source present, but the programs don't appear to be built from it. What started this is that I tried to build the usbdux firmware from source and found that the assembler needed to build the firmware segfaulted when trying to do so. Curious as to how Debian got the firmware to build I checked out the firmware-free package. The answer seems to be: They didn't; they just use the binaries from linux- firmware.git. (The sha512 hashes appear to be identical.) If they were built from source then the build dependencies for firmware- free would be bigger (such as, among others, depending on as31 in order to build the usbdux firmware) and the breakage of tools needed to build the firmware would have been noticed. Surely including auto-generated files and/or just re-cycling upstream's binaries in a source package either is or should be some sort of policy violation? Building from source would help to ensure that the provided source is complete, corresponding, and buildable. It would also be consistent with the proposed stuff for JavaScript to exclude auto- generated files from source.
Processed: Re: firmware-free: Source Package Doesn't Contain Source
Processing commands for cont...@bugs.debian.org: > retitle 890601 firmware-linux-free uses prebuilt blobs instead of building > from source Bug #890601 [firmware-linux-free] Source Package Doesn't Contain Source Changed Bug title to 'firmware-linux-free uses prebuilt blobs instead of building from source' from 'Source Package Doesn't Contain Source'. > severity 890601 wishlist Bug #890601 [firmware-linux-free] firmware-linux-free uses prebuilt blobs instead of building from source Severity set to 'wishlist' from 'normal' > quit Stopping processing here. Please contact me if you need assistance. -- 890601: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890601 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#890601: firmware-free: Source Package Doesn't Contain Source
retitle 890601 firmware-linux-free uses prebuilt blobs instead of building from source severity 890601 wishlist quit Jason Self wrote: > Jonathan Nieder wrote .. >> Can you be more specific? Which file have you found in the source >> package that does not have corresponding source included? > > OK; perhaps this bug needs re-titling. There seems to be "a" source > present, but the programs don't appear to be built from it. Thanks for clarifying. I agree that fixing that is a worthwhile project, though it's hard to do (e.g. because of the current state of cross-compilers in the archive). Retitling and setting severity based on my understanding of kernel team's current plans. Thanks, Jonathan
