Bug#782561: marked as done (Buffer overruns in Linux kernel RFC4106 implementation using AESNI (CVE-2015-3331))
Your message dated Thu, 23 Apr 2015 18:07:06 + with message-id e1yllwk-0002ea...@franck.debian.org and subject line Bug#782561: fixed in linux 3.16.7-ckt9-3 has caused the Debian Bug report #782561, regarding Buffer overruns in Linux kernel RFC4106 implementation using AESNI (CVE-2015-3331) 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.) -- 782561: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782561 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: src:linux Version: 3.16.7-ckt7-1 Severity: wishlist Using the rfc4106 IPsec implementation provided by the aesni_intel module results in occasional crashes on an busy gateway. This was fixed upstream by commit ccfe8c3f7e52: | commit ccfe8c3f7e52ae83155cb038753f4c75b774ca8a | Author: Stephan Mueller smuel...@chronox.de | Date: Thu Mar 12 09:17:51 2015 +0100 | | crypto: aesni - fix memory usage in GCM decryption | | The kernel crypto API logic requires the caller to provide the | length of (ciphertext || authentication tag) as cryptlen for the | AEAD decryption operation. Thus, the cipher implementation must | calculate the size of the plaintext output itself and cannot simply use | cryptlen. | | The RFC4106 GCM decryption operation tries to overwrite cryptlen memory | in req-dst. As the destination buffer for decryption only needs to hold | the plaintext memory but cryptlen references the input buffer holding | (ciphertext || authentication tag), the assumption of the destination | buffer length in RFC4106 GCM operation leads to a too large size. This | patch simply uses the already calculated plaintext size. | | In addition, this patch fixes the offset calculation of the AAD buffer | pointer: as mentioned before, cryptlen already includes the size of the | tag. Thus, the tag does not need to be added. With the addition, the AAD | will be written beyond the already allocated buffer. | | Note, this fixes a kernel crash that can be triggered from user space | via AF_ALG(aead) -- simply use the libkcapi test application | from [1] and update it to use rfc4106-gcm-aes. | | Using [1], the changes were tested using CAVS vectors to demonstrate | that the crypto operation still delivers the right results. | | [1] http://www.chronox.de/libkcapi.html | | CC: Tadeusz Struk tadeusz.st...@intel.com | Cc: sta...@vger.kernel.org | Signed-off-by: Stephan Mueller smuel...@chronox.de | Signed-off-by: Herbert Xu herb...@gondor.apana.org.au This fix is already queued for 3.16.7-ckt10, but it'd be great if you could include it in jessie ASAP. Thanks, -- Romain Francoise rfranco...@debian.org http://people.debian.org/~rfrancoise/ ---End Message--- ---BeginMessage--- Source: linux Source-Version: 3.16.7-ckt9-3 We believe that the bug you reported is fixed in the latest version of linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 782...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings b...@decadent.org.uk (supplier of updated linux package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 23 Apr 2015 16:41:27 +0100 Source: linux Binary: linux-source-3.16 linux-doc-3.16 linux-manual-3.16 linux-support-3.16.0-4 linux-libc-dev linux-headers-3.16.0-4-all linux-headers-3.16.0-4-all-alpha kernel-image-3.16.0-4-alpha-generic-di nic-modules-3.16.0-4-alpha-generic-di nic-wireless-modules-3.16.0-4-alpha-generic-di nic-shared-modules-3.16.0-4-alpha-generic-di serial-modules-3.16.0-4-alpha-generic-di usb-serial-modules-3.16.0-4-alpha-generic-di ppp-modules-3.16.0-4-alpha-generic-di pata-modules-3.16.0-4-alpha-generic-di cdrom-core-modules-3.16.0-4-alpha-generic-di scsi-core-modules-3.16.0-4-alpha-generic-di scsi-modules-3.16.0-4-alpha-generic-di scsi-common-modules-3.16.0-4-alpha-generic-di scsi-extra-modules-3.16.0-4-alpha-generic-di loop-modules-3.16.0-4-alpha-generic-di btrfs-modules-3.16.0-4-alpha-generic-di ext4-modules-3.16.0-4-alpha-generic-di isofs-modules-3.16.0-4-alpha-generic-di jfs-modules-3.16.0-4-alpha-generic-di
linux_3.16.7-ckt9-3_multi.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 23 Apr 2015 16:41:27 +0100 Source: linux Binary: linux-source-3.16 linux-doc-3.16 linux-manual-3.16 linux-support-3.16.0-4 linux-libc-dev linux-headers-3.16.0-4-all linux-headers-3.16.0-4-all-alpha kernel-image-3.16.0-4-alpha-generic-di nic-modules-3.16.0-4-alpha-generic-di nic-wireless-modules-3.16.0-4-alpha-generic-di nic-shared-modules-3.16.0-4-alpha-generic-di serial-modules-3.16.0-4-alpha-generic-di usb-serial-modules-3.16.0-4-alpha-generic-di ppp-modules-3.16.0-4-alpha-generic-di pata-modules-3.16.0-4-alpha-generic-di cdrom-core-modules-3.16.0-4-alpha-generic-di scsi-core-modules-3.16.0-4-alpha-generic-di scsi-modules-3.16.0-4-alpha-generic-di scsi-common-modules-3.16.0-4-alpha-generic-di scsi-extra-modules-3.16.0-4-alpha-generic-di loop-modules-3.16.0-4-alpha-generic-di btrfs-modules-3.16.0-4-alpha-generic-di ext4-modules-3.16.0-4-alpha-generic-di isofs-modules-3.16.0-4-alpha-generic-di jfs-modules-3.16.0-4-alpha-generic-di xfs-modules-3.16.0-4-alpha-generic-di fat-modules-3.16.0-4-alpha-generic-di md-modules-3.16.0-4-alpha-generic-di multipath-modules-3.16.0-4-alpha-generic-di usb-modules-3.16.0-4-alpha-generic-di usb-storage-modules-3.16.0-4-alpha-generic-di fb-modules-3.16.0-4-alpha-generic-di input-modules-3.16.0-4-alpha-generic-di event-modules-3.16.0-4-alpha-generic-di mouse-modules-3.16.0-4-alpha-generic-di nic-pcmcia-modules-3.16.0-4-alpha-generic-di pcmcia-modules-3.16.0-4-alpha-generic-di nic-usb-modules-3.16.0-4-alpha-generic-di sata-modules-3.16.0-4-alpha-generic-di core-modules-3.16.0-4-alpha-generic-di crc-modules-3.16.0-4-alpha-generic-di crypto-modules-3.16.0-4-alpha-generic-di crypto-dm-modules-3.16.0-4-alpha-generic-di ata-modules-3.16.0-4-alpha-generic-di nbd-modules-3.16.0-4-alpha-generic-di squashfs-modules-3.16.0-4-alpha-generic-di virtio-modules-3.16.0-4-alpha-generic-di zlib-modules-3.16.0-4-alpha-generic-di fuse-modules-3.16.0-4-alpha-generic-di srm-modules-3.16.0-4-alpha-generic-di linux-headers-3.16.0-4-common linux-image-3.16.0-4-alpha-generic linux-headers-3.16.0-4-alpha-generic linux-image-3.16.0-4-alpha-smp linux-headers-3.16.0-4-alpha-smp linux-headers-3.16.0-4-all-amd64 kernel-image-3.16.0-4-amd64-di nic-modules-3.16.0-4-amd64-di nic-wireless-modules-3.16.0-4-amd64-di nic-shared-modules-3.16.0-4-amd64-di serial-modules-3.16.0-4-amd64-di usb-serial-modules-3.16.0-4-amd64-di ppp-modules-3.16.0-4-amd64-di pata-modules-3.16.0-4-amd64-di cdrom-core-modules-3.16.0-4-amd64-di firewire-core-modules-3.16.0-4-amd64-di scsi-core-modules-3.16.0-4-amd64-di scsi-modules-3.16.0-4-amd64-di scsi-common-modules-3.16.0-4-amd64-di scsi-extra-modules-3.16.0-4-amd64-di loop-modules-3.16.0-4-amd64-di btrfs-modules-3.16.0-4-amd64-di ext4-modules-3.16.0-4-amd64-di isofs-modules-3.16.0-4-amd64-di jfs-modules-3.16.0-4-amd64-di ntfs-modules-3.16.0-4-amd64-di xfs-modules-3.16.0-4-amd64-di fat-modules-3.16.0-4-amd64-di md-modules-3.16.0-4-amd64-di multipath-modules-3.16.0-4-amd64-di usb-modules-3.16.0-4-amd64-di usb-storage-modules-3.16.0-4-amd64-di pcmcia-storage-modules-3.16.0-4-amd64-di fb-modules-3.16.0-4-amd64-di input-modules-3.16.0-4-amd64-di event-modules-3.16.0-4-amd64-di mouse-modules-3.16.0-4-amd64-di nic-pcmcia-modules-3.16.0-4-amd64-di pcmcia-modules-3.16.0-4-amd64-di nic-usb-modules-3.16.0-4-amd64-di sata-modules-3.16.0-4-amd64-di core-modules-3.16.0-4-amd64-di acpi-modules-3.16.0-4-amd64-di i2c-modules-3.16.0-4-amd64-di crc-modules-3.16.0-4-amd64-di crypto-modules-3.16.0-4-amd64-di crypto-dm-modules-3.16.0-4-amd64-di efi-modules-3.16.0-4-amd64-di ata-modules-3.16.0-4-amd64-di mmc-core-modules-3.16.0-4-amd64-di mmc-modules-3.16.0-4-amd64-di nbd-modules-3.16.0-4-amd64-di squashfs-modules-3.16.0-4-amd64-di speakup-modules-3.16.0-4-amd64-di virtio-modules-3.16.0-4-amd64-di uinput-modules-3.16.0-4-amd64-di sound-modules-3.16.0-4-amd64-di hyperv-modules-3.16.0-4-amd64-di udf-modules-3.16.0-4-amd64-di fuse-modules-3.16.0-4-amd64-di linux-image-3.16.0-4-amd64 linux-headers-3.16.0-4-amd64 linux-image-3.16.0-4-amd64-dbg xen-linux-system-3.16.0-4-amd64 linux-headers-3.16.0-4-all-arm64 kernel-image-3.16.0-4-arm64-di nic-modules-3.16.0-4-arm64-di nic-wireless-modules-3.16.0-4-arm64-di nic-shared-modules-3.16.0-4-arm64-di ppp-modules-3.16.0-4-arm64-di cdrom-core-modules-3.16.0-4-arm64-di scsi-core-modules-3.16.0-4-arm64-di scsi-modules-3.16.0-4-arm64-di loop-modules-3.16.0-4-arm64-di btrfs-modules-3.16.0-4-arm64-di ext4-modules-3.16.0-4-arm64-di isofs-modules-3.16.0-4-arm64-di jfs-modules-3.16.0-4-arm64-di xfs-modules-3.16.0-4-arm64-di fat-modules-3.16.0-4-arm64-di md-modules-3.16.0-4-arm64-di multipath-modules-3.16.0-4-arm64-di usb-modules-3.16.0-4-arm64-di usb-storage-modules-3.16.0-4-arm64-di input-modules-3.16.0-4-arm64-di event-modules-3.16.0-4-arm64-di nic-usb-modules-3.16.0-4-arm64-di sata-modules-3.16.0-4-arm64-di
Bug#783208: linux-image-3.16.0-4-amd64: USB mouse randomly stops working
Package: src:linux Version: 3.16.7-ckt9-2 Severity: normal Dear Maintainer, My USB mouse intermittently stops working (pointer not responding to it, but responding normally to the internal trackpad); this has been happening for at least 1-2 months (possibly since install), but has been unusually frequent for the last few days. When not working, the mouse continues to appear in lsusb and /dev/bus/usb, but sudo cat /dev/input/mouse0 gives nothing; nothing appears in kern.log. It can be made to work again by a suspend/resume or hibernate/resume cycle, or by physically disconnecting and reconnecting it. Unlike #780923, it only ever affects the mouse, not the (also USB) keyboard. Boot messages for this device: Apr 20 20:01:10 rnpalmer-laptop kernel: [3.212600] usb 3-2: new low-speed USB device number 3 using xhci_hcd Apr 20 20:01:10 rnpalmer-laptop kernel: [3.380727] usb 3-2: device descriptor read/64, error -71 Apr 20 20:01:10 rnpalmer-laptop kernel: [3.616509] usb 3-2: New USB device found, idVendor=13ee, idProduct=0001 Apr 20 20:01:10 rnpalmer-laptop kernel: [3.616515] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Apr 20 20:01:10 rnpalmer-laptop kernel: [3.616518] usb 3-2: Product: AND Apr 20 20:01:10 rnpalmer-laptop kernel: [3.616521] usb 3-2: Manufacturer: MOON Apr 20 20:01:10 rnpalmer-laptop kernel: [3.616524] usb 3-2: SerialNumber: @ɌAB Apr 20 20:01:10 rnpalmer-laptop kernel: [3.616790] usb 3-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes Apr 20 20:01:10 rnpalmer-laptop kernel: [3.619421] input: MOON AND as /devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0/0003:13EE:0001.0003/input/input7 Apr 20 20:01:10 rnpalmer-laptop kernel: [3.619602] hid-generic 0003:13EE:0001.0003: input,hidraw2: USB HID v1.00 Mouse [MOON AND ] on usb-:00:14.0-2/input0 $ sudo lsusb -d 13ee:0001 -v Bus 003 Device 003: ID 13ee:0001 MosArt Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x13ee MosArt idProduct 0x0001 bcdDevice0.10 iManufacturer 1 MOON iProduct2 AND iSerial 3 @ɌAB bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.00 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 52 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Device Status: 0x (Bus Powered) rnpalmer@rnpalmer-laptop:~$ -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) ** Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=UUID=1ebca590-0a18-44f5-8d75-f96f5ca7c36e ro quiet ** Not tainted ** Kernel log: [ 629.323176] ehci-pci :00:1a.0: using default PCI settings [ 629.323189] snd_hda_intel :00:1b.0: no hotplug settings from platform [ 629.323196] pcieport :00:1c.0: no hotplug settings from platform [ 629.323202] pcieport :00:1c.1: no hotplug settings from platform [ 629.323266] ath9k :02:00.0: no hotplug settings from platform [ 629.323273] pcieport :00:1c.2: no hotplug settings from platform [ 629.323291] alx :03:00.0: no hotplug settings from platform [ 629.323297] ehci-pci :00:1d.0: no hotplug settings from platform [ 629.323300] ehci-pci :00:1d.0: using default PCI settings [ 629.323315] lpc_ich :00:1f.0: no hotplug settings from platform [ 629.323318] lpc_ich :00:1f.0: using default
Processed: nfs-kernel-server: exportfs fails to set rw, ro, [no_]root_squash or [no_]squash_all flags in some cases
Processing control commands: merge -1 709403 Bug #783212 [nfs-kernel-server] nfs-kernel-server: exportfs fails to set rw, ro, [no_]root_squash or [no_]squash_all flags in some cases Bug #783212 [nfs-kernel-server] nfs-kernel-server: exportfs fails to set rw, ro, [no_]root_squash or [no_]squash_all flags in some cases Marked as found in versions nfs-utils/1:1.2.8-2. Bug #709403 [nfs-kernel-server] nfs-kernel-server: all exports are read only Marked as found in versions nfs-utils/1:1.2.8-9. Added tag(s) fixed-upstream. Merged 709403 783212 -- 709403: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709403 783212: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783212 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.b.142982705414408.transcr...@bugs.debian.org
Bug#783212: nfs-kernel-server: exportfs fails to set rw, ro, [no_]root_squash or [no_]squash_all flags in some cases
Package: nfs-kernel-server Version: 1:1.2.8-9 Severity: important Tags: fixed-upstream Control: merge -1 709403 Dear Maintainer, after upgrading from version 1:1.2.6-4 several exports on my server lost their no_root_squash flag, causing Permission denied errors on the corresponding clients when using root. After some testing and debugging I came to the following conclusion: Commit 11ba3b1e01b67b7d19f26fba94fabdb60878e809 (Add a default flavor to an export's e_secinfo list) breaks export option parsing by exportfs in some cases. Upstream commit 7004991526be90ec2647d28c503936dc91bc9100 (exportfs: Fix the default authentication flavour setting) fixes the bug as a side effect of dealing with another problem sharing the same root cause. The easiest workaround is to add a sec=xyz option at the beginning of all export option strings. My test configuration is as follows: -- /etc/exports -- /srv/nfs4 -fsid=0,async,no_subtree_check,insecure,all_squash 10.0.0.2 10.0.0.3(secure,rw,no_root_squash,no_all_squash) exportfs -v output from version 1:1.2.8-9: /srv/nfs4 10.0.0.2(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=0,sec=sys,ro,root_squash,all_squash) /srv/nfs4 10.0.0.3(ro,async,wdelay,root_squash,all_squash,no_subtree_check,fsid=0,sec=sys,ro,root_squash,all_squash) but /var/lib/nfs/etab shows /srv/nfs4 10.0.0.2(ro,async,wdelay,hide,nocrossmnt,insecure,root_squash,all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534,sec=sys,ro,root_squash,all_squash) /srv/nfs4 10.0.0.3(rw,async,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534,sec=sys,ro,root_squash,all_squash) ^ ^ ^ ^ ^ ^ meaning exportfs -a|-r produces an inconsistent etab line. Consequently rw, no_root_squash and no_all_squash get dropped by exportfs -v and mountd (last save wins). This happens under following conditions: (1) A default option specification is present on the export line. (2) The export line contains an export with rw, ro, [no_]root_squash or [no_]squash_all options different from the implied or declared default options (3) The option string for this export doesn't contain a sec=xyz option preceding the options named in (2). The underlying bug is in function parseopts at ./support/nfs/exports.c:646: A default security flavor containing duplicates of the specified default values for the READONLY, ROOTSQUASH and ALLSQUASH flags is added to the default options. This default flavor is erroneously reused for all exports on the same line in spite of containing flags that can be altered by export specifications. This results in possibly incorrect options at the end of the export specifications in the etab file. The bug fix is to generate a default security flavor seperately for each export that doesn't already have one. This is in effect what upstream commit 7004991526be90ec2647d28c503936dc91bc9100 does by deferring the generation of default security flavors as long as possible. I have patched version 1:1.2.8-9 with upstream commit 7004991526be90ec2647d28c503936dc91bc9100 and it works as expected: exportfs -v output from version 1:1.2.8-9.1: /srv/nfs4 10.0.0.2(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=0,sec=sys,ro,root_squash,all_squash) /srv/nfs4 10.0.0.3(rw,async,wdelay,no_root_squash,no_subtree_check,fsid=0,sec=sys,rw,no_root_squash,no_all_squash) /var/lib/nfs/etab after exportfs -r (version 1:1.2.8-9.1): /srv/nfs4 10.0.0.2(ro,async,wdelay,hide,nocrossmnt,insecure,root_squash,all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534,sec=sys,ro,root_squash,all_squash) /srv/nfs4 10.0.0.3(rw,async,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534,sec=sys,rw,no_root_squash,no_all_squash) I have set the severity to important in order to be able to merge bug #709403, which looks like an instance of the same bug to me. If this doesn't seem appropriate please adjust as you see fit. Regards, Martin B -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (900, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages nfs-kernel-server depends on: ii libblkid1 2.25.2-6 ii libc6 2.19-18 ii libcap2 1:2.24-8 ii libsqlite3-0 3.8.7.4-1 ii libtirpc1 0.2.5-1 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian13+nmu1 ii nfs-common1:1.2.8-9 ii ucf
Bug#783214: linux-image-686: Enable HID_BATTERY_STRENGTH config option
Package: linux-image-686 Severity: wishlist Dear Maintainer, since 3.19 the HID_BATTERY_STRENGTH doesn't requires patching to Kconfig to be enabled without requiring HID to be built-in. HID_BATTERY_STRENGTH is an option that allows for HID devices that support reporting their battery state (eg Apple Wireless Keyboard/mouse...), do so by using the power_supply infrastructure, I've asked Ubuntu and Fedora to enable this in the past, and has been working well since 3.4 iirc with 3.19 it's easier so I'd like to have it enabled on the Debian kernel so we at Tanglu don't need local patches. Thanks -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.13.0-48-generic (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20150423222044.17779.85789.report...@tanglu.tanglu.org
Processing of linux_3.16.7-ckt9-3_multi.changes
linux_3.16.7-ckt9-3_multi.changes uploaded successfully to localhost along with the files: linux_3.16.7-ckt9-3.dsc linux_3.16.7-ckt9-3.debian.tar.xz linux-support-3.16.0-4_3.16.7-ckt9-3_all.deb linux-doc-3.16_3.16.7-ckt9-3_all.deb linux-manual-3.16_3.16.7-ckt9-3_all.deb linux-source-3.16_3.16.7-ckt9-3_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1ylll0-00013s...@franck.debian.org
Re: 3.19.0 dependency problem
Hello, On Thu, Apr 23, 2015 at 07:35:52AM +1200, Fred Cooke wrote: Thanks for the quick replies! I love that I run Sid (on 4 machines), only notice something worth reporting every 2 years or so, and get immediate responses! 3 Debian. I've not built a Kernel (or any related part) in a VERY long time, I think maybe 2.6.something? I've simply not needed to. I still don't need to :-) I'm aware of the need being only for kernel headers, however I've been burned on Sid before by not grabbing them at the time of the image, and not being able to grab them later as they are not persisted in parallel in the repo. Then you're forced to get a new kernel and headers, and back then, that meant possible bugs/changed behaviours that I didn't want. So I always You don't know about http://snapshot.debian.org/ ? install headers up front. And I should use meta packages to do that, but haven't been in the past. Meta-packages that glue this stuff all together seem to be missing from experimental too. If you don't care, it's fine by me. Just letting you know in case it was an oversight. Yeah, that's known, too. Usually there is just noone to volunteer updating them for experimental, same as for kbuild. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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/20150423064909.gj23...@pengutronix.de
Re: 3.19.0 dependency problem
Wow, no, I did not know about that! But I do now. Thanks! :-) I would have thought the updating of meta packages would be automated as the set of things that make up a kernel meta package should probably have synced version numbers. Perhaps I'm just optimistic. If kbuild requires some work to update, then that's understandable, meta packages, though, should be near zero effort to keep up to date. Even if they have the same missing kbuild problem. Anyway, enough noise/spam out of me. Thanks again, Fred. On Thu, Apr 23, 2015 at 6:49 PM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: Hello, On Thu, Apr 23, 2015 at 07:35:52AM +1200, Fred Cooke wrote: Thanks for the quick replies! I love that I run Sid (on 4 machines), only notice something worth reporting every 2 years or so, and get immediate responses! 3 Debian. I've not built a Kernel (or any related part) in a VERY long time, I think maybe 2.6.something? I've simply not needed to. I still don't need to :-) I'm aware of the need being only for kernel headers, however I've been burned on Sid before by not grabbing them at the time of the image, and not being able to grab them later as they are not persisted in parallel in the repo. Then you're forced to get a new kernel and headers, and back then, that meant possible bugs/changed behaviours that I didn't want. So I always You don't know about http://snapshot.debian.org/ ? install headers up front. And I should use meta packages to do that, but haven't been in the past. Meta-packages that glue this stuff all together seem to be missing from experimental too. If you don't care, it's fine by me. Just letting you know in case it was an oversight. Yeah, that's known, too. Usually there is just noone to volunteer updating them for experimental, same as for kbuild. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH 2/2] deb-pkg: add source package
On 22 April 2015 at 18:50, maximilian attems m...@stro.at wrote: On Fri, Apr 10, 2015 at 04:15:14PM +0300, riku.voi...@linaro.org wrote: From: Riku Voipio riku.voi...@linaro.org By passing BUILD_SOURCE=y variable, make deb-pkg builds a debian source package. It will generate a minimal debian/rules file that calls back to make deb-pkg. Generated source package will build the same kernel .config than what was available for make deb-pkg. The source package is useful for gpl compliance, or for feeding to a automated debian package builder. Patch depends on the deb-pkg: move setting debarch for a separate function for correct changelog filenames. Signed-off-by: Riku Voipio riku.voi...@linaro.org --- great this is a much requested feature for wider adoption of make deb-pkg. In general acked-by me, just minor comment below. I do not like the BUILD_SOURCE=y variable, I think it should just be like the other scripts and do it by default. What we do need is a target that *only* compiles the linux image. So a bin-debpkg target in scripts/package/Makefile ? scripts/package/builddeb | 42 ++ 1 file changed, 42 insertions(+) diff --git a/scripts/package/builddeb b/scripts/package/builddeb index e397815..3d77fd3 100755 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -272,12 +272,23 @@ On Debian GNU/Linux systems, the complete text of the GNU General Public License version 2 can be found in \`/usr/share/common-licenses/GPL-2'. EOF + +build_depends=bc, +if [ -n $BUILD_TOOLS ] why this dual stage? That variable was introduced in RFC: builddeb: add linux-tools package with perf [1]. Building perf as part of deb-pkg was kind of the major motivation for these series. +then + build_depends=$build_depends python-dev, libperl-dev, bison, flex, \ +libaudit-dev, libdw-dev, libelf-dev, libiberty-dev, libnewt-dev, autoconf, \ +automake, libtool, libglib2.0-dev, libudev-dev, libwrap0-dev, libiberty-dev, \ +libunwind8-dev [amd64 arm64 i386], libnuma-dev [amd64 arm64 i386 powerpc ppc64 ppc64el] how did you generate this list, this seems bogus to me?! python-dev should probably be python why would you need automake? These are build-depends of linux-tools (perf etc). plus I do seem to miss cpio, kmod. I'll add kmod and cpio to the non-tools case. [1] [1] https://lists.debian.org/debian-kernel/2015/04/msg00013.html -- 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/caaqcghnrinmmg++0d02-anyrdhxod5k3g5qcwxba7tkoqe+...@mail.gmail.com
Re: [PATCH 2/2] deb-pkg: add source package
On Thu, Apr 23, 2015 at 12:01:10PM +0300, Riku Voipio wrote: On 22 April 2015 at 18:50, maximilian attems m...@stro.at wrote: great this is a much requested feature for wider adoption of make deb-pkg. In general acked-by me, just minor comment below. I do not like the BUILD_SOURCE=y variable, I think it should just be like the other scripts and do it by default. What we do need is a target that *only* compiles the linux image. So a bin-debpkg target in scripts/package/Makefile ? yes, please. scripts/package/builddeb | 42 ++ 1 file changed, 42 insertions(+) diff --git a/scripts/package/builddeb b/scripts/package/builddeb index e397815..3d77fd3 100755 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -272,12 +272,23 @@ On Debian GNU/Linux systems, the complete text of the GNU General Public License version 2 can be found in \`/usr/share/common-licenses/GPL-2'. EOF + +build_depends=bc, +if [ -n $BUILD_TOOLS ] why this dual stage? That variable was introduced in RFC: builddeb: add linux-tools package with perf [1]. Building perf as part of deb-pkg was kind of the major motivation for these series. With adding the very specific image target, I don't think this variable is needed. +then + build_depends=$build_depends python-dev, libperl-dev, bison, flex, \ +libaudit-dev, libdw-dev, libelf-dev, libiberty-dev, libnewt-dev, autoconf, \ +automake, libtool, libglib2.0-dev, libudev-dev, libwrap0-dev, libiberty-dev, \ +libunwind8-dev [amd64 arm64 i386], libnuma-dev [amd64 arm64 i386 powerpc ppc64 ppc64el] how did you generate this list, this seems bogus to me?! python-dev should probably be python why would you need automake? These are build-depends of linux-tools (perf etc). Hmm, ok. plus I do seem to miss cpio, kmod. I'll add kmod and cpio to the non-tools case. good. -- 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/20150423104358.gr27...@stro.at
