[Kernel-packages] [Bug 1625805] Re: arm64 kernel panic for l2 mmu with unity8 session snap (& deb as well)
Paolo, you marked this invalid. Is there a workaround or does the kernel no longer panic in this case? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1625805 Title: arm64 kernel panic for l2 mmu with unity8 session snap (& deb as well) Status in Snappy: New Status in linux package in Ubuntu: Invalid Bug description: we are running the unity8 session snap on amd64 without any problems. to setup and reproduce the problem follow the "on Dragonboard" section of https://docs.google.com/document/d/1o-jKITqUxRsujmN3OwRj3wRnn6dgblKuvrhKjeN8-Wc You can also find the panic signature at line 3276 of the attached syslog. To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1625805/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1548009] Re: ZFS pools should be automatically scrubbed
I get not wanting unnecessary PATHs... But is /usr/local really considered a security issue? It's in /usr... It's part of the standard PATH for the root user. And if an admin has installed tools in /usr/local, wouldn't they expect them to be used? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1548009 Title: ZFS pools should be automatically scrubbed Status in zfs-linux package in Ubuntu: Fix Released Status in zfs-linux source package in Xenial: Incomplete Bug description: [Impact] Xenial shipped with a cron job to automatically scrub ZFS pools, as desired by many users and as implemented by mdadm for traditional Linux software RAID. Unfortunately, this cron job does not work, because it needs a PATH line for /sbin, where the zpool utility lives. Given the existence of the cron job and various discussions on IRC, etc., users expect that scrubs are happening, when they are not. This means ZFS is not pre-emptively checking for (and correcting) corruption. The odds of disk corruption are admittedly very low, but violating users' expectations of data safety, especially when they've gone out of their way to use a filesystem which touts data safety, is bad. [Test Case] $ truncate -s 1G test.img $ sudo zpool create test `pwd`/test.img $ sudo zpool status test $ sudo vi /etc/cron.d/zfsutils-linux Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes (modifying the date range if it's not currently the 8th through the 14th and the "-eq 0" check if it's not currently a Sunday). $ grep zfs /var/log/cron.log Verify in /var/log/cron.log that the job ran. $ sudo zpool status test Expected results: scan: scrub repaired 0 in ... on Actual results: scan: none requested Then, add the PATH line, update the time rules in the cron job, and repeat the test. Now it will work. - OR - The best test case is to leave the cron job file untouched, install the patched package, wait for the second Sunday of the month, and verify with zpool status that a scrub ran. I did this, on Xenial, with the package I built. The debdiff is in comment #11 and was accepted to Yakkety. If someone can get this in -proposed before the 14th, I'll gladly install the actual package from -proposed and make sure it runs correctly on the 14th. [Regression Potential] The patch only touches the cron.d file, which has only one cron job in it. This cron job is completely broken (inoperative) at the moment, so the regression potential is very low. ORIGINAL, PRE-SRU, DESCRIPTION: mdadm automatically checks MD arrays. ZFS should automatically scrub pools too. Scrubbing a pool allows ZFS to detect on-disk corruption and (when the pool has redundancy) correct it. Note that ZFS does not blindly assume the other copy is correct; it will only overwrite bad data with data that is known to be good (i.e. it passes the checksum). I've attached a debdiff which accomplishes this. It builds and installs cleanly. The meat of it is the scrub script I've been using on production systems, both servers and laptops, and recommending in my Ubuntu root- on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot of disk load which could theoretically lead to another failure. We should save that disk load for resilvering. 2) Performance is already less on a degraded pool and scrubbing can make that worse, even though scrubs are throttled. Arguably, I might be being too conservative here, but the marginal benefit of scrubbing a *degraded* pool is pretty minimal as pools should not be left degraded for very long. The cron.d in this patch scrubs on the second Sunday of the month. mdadm scrubs on the first Sunday of the month. This way, if a system has both MD and ZFS pools, the load doesn't all happen at the same time. If the system doesn't have both types, it shouldn't really matter which week. If you'd rather make it the same week as MD, I see no problem with that. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1548009] Re: ZFS pools should be automatically scrubbed
I've uploaded the patch to xenial-proposed too. Thanks! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1548009 Title: ZFS pools should be automatically scrubbed Status in zfs-linux package in Ubuntu: Fix Released Status in zfs-linux source package in Xenial: New Bug description: [Impact] Xenial shipped with a cron job to automatically scrub ZFS pools, as desired by many users and as implemented by mdadm for traditional Linux software RAID. Unfortunately, this cron job does not work, because it needs a PATH line for /sbin, where the zpool utility lives. Given the existence of the cron job and various discussions on IRC, etc., users expect that scrubs are happening, when they are not. This means ZFS is not pre-emptively checking for (and correcting) corruption. The odds of disk corruption are admittedly very low, but violating users' expectations of data safety, especially when they've gone out of their way to use a filesystem which touts data safety, is bad. [Test Case] $ truncate -s 1G test.img $ sudo zpool create test `pwd`/test.img $ sudo zpool status test $ sudo vi /etc/cron.d/zfsutils-linux Modify /etc/cron.d/zfsutils-linux to run the cron job in a few minutes (modifying the date range if it's not currently the 8th through the 14th and the "-eq 0" check if it's not currently a Sunday). $ grep zfs /var/log/cron.log Verify in /var/log/cron.log that the job ran. $ sudo zpool status test Expected results: scan: scrub repaired 0 in ... on Actual results: scan: none requested Then, add the PATH line, update the time rules in the cron job, and repeat the test. Now it will work. - OR - The best test case is to leave the cron job file untouched, install the patched package, wait for the second Sunday of the month, and verify with zpool status that a scrub ran. I did this, on Xenial, with the package I built. The debdiff is in comment #11 and was accepted to Yakkety. If someone can get this in -proposed before the 14th, I'll gladly install the actual package from -proposed and make sure it runs correctly on the 14th. [Regression Potential] The patch only touches the cron.d file, which has only one cron job in it. This cron job is completely broken (inoperative) at the moment, so the regression potential is very low. ORIGINAL, PRE-SRU, DESCRIPTION: mdadm automatically checks MD arrays. ZFS should automatically scrub pools too. Scrubbing a pool allows ZFS to detect on-disk corruption and (when the pool has redundancy) correct it. Note that ZFS does not blindly assume the other copy is correct; it will only overwrite bad data with data that is known to be good (i.e. it passes the checksum). I've attached a debdiff which accomplishes this. It builds and installs cleanly. The meat of it is the scrub script I've been using on production systems, both servers and laptops, and recommending in my Ubuntu root- on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot of disk load which could theoretically lead to another failure. We should save that disk load for resilvering. 2) Performance is already less on a degraded pool and scrubbing can make that worse, even though scrubs are throttled. Arguably, I might be being too conservative here, but the marginal benefit of scrubbing a *degraded* pool is pretty minimal as pools should not be left degraded for very long. The cron.d in this patch scrubs on the second Sunday of the month. mdadm scrubs on the first Sunday of the month. This way, if a system has both MD and ZFS pools, the load doesn't all happen at the same time. If the system doesn't have both types, it shouldn't really matter which week. If you'd rather make it the same week as MD, I see no problem with that. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1548009] Re: ZFS pools should be automatically scrubbed
Thanks for the patch! I've uploaded to yakkety, this bug should autoclose. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1548009 Title: ZFS pools should be automatically scrubbed Status in zfs-linux package in Ubuntu: In Progress Bug description: mdadm automatically checks MD arrays. ZFS should automatically scrub pools too. Scrubbing a pool allows ZFS to detect on-disk corruption and (when the pool has redundancy) correct it. Note that ZFS does not blindly assume the other copy is correct; it will only overwrite bad data with data that is known to be good (i.e. it passes the checksum). I've attached a debdiff which accomplishes this. It builds and installs cleanly. The meat of it is the scrub script I've been using on production systems, both servers and laptops, and recommending in my Ubuntu root- on-ZFS HOWTO, for years, which scrubs all *healthy* pools. If a pool is not healthy, scrubbing it is bad for two reasons: 1) It adds a lot of disk load which could theoretically lead to another failure. We should save that disk load for resilvering. 2) Performance is already less on a degraded pool and scrubbing can make that worse, even though scrubs are throttled. Arguably, I might be being too conservative here, but the marginal benefit of scrubbing a *degraded* pool is pretty minimal as pools should not be left degraded for very long. The cron.d in this patch scrubs on the second Sunday of the month. mdadm scrubs on the first Sunday of the month. This way, if a system has both MD and ZFS pools, the load doesn't all happen at the same time. If the system doesn't have both types, it shouldn't really matter which week. If you'd rather make it the same week as MD, I see no problem with that. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1548009/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1532198] Re: [MIR] zfs-linux
That looks good! With that on its way to yakkety, I'll mark this approved. Thank you! ** Changed in: zfs-linux (Ubuntu) Status: Incomplete => Fix Committed ** Changed in: zfs-linux (Ubuntu) Assignee: Colin Ian King (colin-king) => (unassigned) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1532198 Title: [MIR] zfs-linux Status in zfs-linux package in Ubuntu: Fix Committed Bug description: Following the process documented at https://wiki.ubuntu.com/MainInclusionProcess , the following template needs to be filled in to start the MIR for zfs-linux in 16.04 Below are my answers to the various main inclusion requirements, marked by a * prefix: [Availability]: "The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on." * http://packages.ubuntu.com/xenial/admin/zfsutils-linux * Yes - built for 64 bit arches only, because ZFS is designed to run well only on 64 bit architectures. [Rationale]: "There must be a certain level of demand for the package, for example: The package is useful for a large part of our user base." * Yes - there is a lot of interest in ZFS in the server space and for users wanting to use a file system that supports huge collections of disks with excellent reliable features such as checksummed raid, mirroring striping with easy configuration and also simple data sanity checking and fixing. * Being requested by Kiko "The package is a new build dependency or dependency of a package that we already support (additionally, the official image builder requires all used packages be in main)." * Yes, already in Wily as a technology demo. "The package helps meet a specific Blueprint goal." * No blueprint goal. "The package replaces another package we currently support and promises higher quality and/or better features, so that we can drop the old package from the supported set." * Not applicable [Security]: "The security history and the current state of security issues in the package must allow us to support the package for at least 18 months without exposing its users to an inappropriate level of security risks. This requires checking of several things that are explained in detail in the subsection Security checks." "Check how many vulnerabilities the package had in the past and how they were handled by upstream and the Debian/Ubuntu package:" "http://cve.mitre.org/cve/cve.html: Search in the National Vulnerability Database using the package as a keyword" NO ZFS Linux CVEs found, here is the complete list from Mitre: CVE-2015-1415 The bsdinstall installer in FreeBSD 10.x before 10.1 p9, when configuring full disk encrypted ZFS, uses world-readable permissions for the GELI keyfile (/boot/encryption.key), which allows local users to obtain sensitive key information by reading the file. CVE-2015-0448 Unspecified vulnerability in Oracle Sun Solaris 11.2 allows local users to affect confidentiality, integrity, and availability via vectors related to ZFS File system. CVE-2013-3266 The nfsrvd_readdir function in sys/fs/nfsserver/nfs_nfsdport.c in the new NFS server in FreeBSD 8.0 through 9.1-RELEASE-p3 does not verify that a READDIR request is for a directory node, which allows remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code by specifying a plain file instead of a directory. CVE-2011-2313 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect availability, related to ZFS. CVE-2011-2312 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect confidentiality, related to ZFS. CVE-2011-2311 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect availability, related to ZFS. CVE-2011-2286 Unspecified vulnerability in Oracle Solaris 10 and 11 Express allows remote authenticated users to affect availability, related to ZFS. CVE-2010-4458 Unspecified vulnerability in Oracle Solaris 11 Express allows local users to affect availability, related to ZFS. CVE-2010-3540 Unspecified vulnerability in Oracle Solaris 10 and OpenSolaris allows local users to affect availability, related to ZFS. CVE-2010-2392 Unspecified vulnerability in Oracle Solaris 10 and OpenSolaris allows local users to affect integrity and availability, related to ZFS. CVE-2010-0318 The replay functionality for ZFS Intent Log (ZIL) in FreeBSD 7.1, 7.2, and 8.0, when creating files during replay of a setattr transaction, uses permissions instead of the original permissions, which might allow local users to read or modify
[Kernel-packages] [Bug 1532198] Re: [MIR] zfs-linux
That debdiff doesn't look like it stops the double-installation of the zed man page from comment #24 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1532198 Title: [MIR] zfs-linux Status in zfs-linux package in Ubuntu: Incomplete Bug description: Following the process documented at https://wiki.ubuntu.com/MainInclusionProcess , the following template needs to be filled in to start the MIR for zfs-linux in 16.04 Below are my answers to the various main inclusion requirements, marked by a * prefix: [Availability]: "The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on." * http://packages.ubuntu.com/xenial/admin/zfsutils-linux * Yes - built for 64 bit arches only, because ZFS is designed to run well only on 64 bit architectures. [Rationale]: "There must be a certain level of demand for the package, for example: The package is useful for a large part of our user base." * Yes - there is a lot of interest in ZFS in the server space and for users wanting to use a file system that supports huge collections of disks with excellent reliable features such as checksummed raid, mirroring striping with easy configuration and also simple data sanity checking and fixing. * Being requested by Kiko "The package is a new build dependency or dependency of a package that we already support (additionally, the official image builder requires all used packages be in main)." * Yes, already in Wily as a technology demo. "The package helps meet a specific Blueprint goal." * No blueprint goal. "The package replaces another package we currently support and promises higher quality and/or better features, so that we can drop the old package from the supported set." * Not applicable [Security]: "The security history and the current state of security issues in the package must allow us to support the package for at least 18 months without exposing its users to an inappropriate level of security risks. This requires checking of several things that are explained in detail in the subsection Security checks." "Check how many vulnerabilities the package had in the past and how they were handled by upstream and the Debian/Ubuntu package:" "http://cve.mitre.org/cve/cve.html: Search in the National Vulnerability Database using the package as a keyword" NO ZFS Linux CVEs found, here is the complete list from Mitre: CVE-2015-1415 The bsdinstall installer in FreeBSD 10.x before 10.1 p9, when configuring full disk encrypted ZFS, uses world-readable permissions for the GELI keyfile (/boot/encryption.key), which allows local users to obtain sensitive key information by reading the file. CVE-2015-0448 Unspecified vulnerability in Oracle Sun Solaris 11.2 allows local users to affect confidentiality, integrity, and availability via vectors related to ZFS File system. CVE-2013-3266 The nfsrvd_readdir function in sys/fs/nfsserver/nfs_nfsdport.c in the new NFS server in FreeBSD 8.0 through 9.1-RELEASE-p3 does not verify that a READDIR request is for a directory node, which allows remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code by specifying a plain file instead of a directory. CVE-2011-2313 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect availability, related to ZFS. CVE-2011-2312 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect confidentiality, related to ZFS. CVE-2011-2311 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect availability, related to ZFS. CVE-2011-2286 Unspecified vulnerability in Oracle Solaris 10 and 11 Express allows remote authenticated users to affect availability, related to ZFS. CVE-2010-4458 Unspecified vulnerability in Oracle Solaris 11 Express allows local users to affect availability, related to ZFS. CVE-2010-3540 Unspecified vulnerability in Oracle Solaris 10 and OpenSolaris allows local users to affect availability, related to ZFS. CVE-2010-2392 Unspecified vulnerability in Oracle Solaris 10 and OpenSolaris allows local users to affect integrity and availability, related to ZFS. CVE-2010-0318 The replay functionality for ZFS Intent Log (ZIL) in FreeBSD 7.1, 7.2, and 8.0, when creating files during replay of a setattr transaction, uses permissions instead of the original permissions, which might allow local users to read or modify unauthorized files in opportunistic circumstances after a system crash or power failure. CVE-2009-3706 Unspecified vulnerability in the ZFS filesystem
[Kernel-packages] [Bug 1532198] Re: [MIR] zfs-linux
Yeah... Looks like it could be dropped. Even if it did refer to a file that moved at one point, we're past the LTS now, so file migration during upgrades aren't even a concern. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1532198 Title: [MIR] zfs-linux Status in zfs-linux package in Ubuntu: Incomplete Bug description: Following the process documented at https://wiki.ubuntu.com/MainInclusionProcess , the following template needs to be filled in to start the MIR for zfs-linux in 16.04 Below are my answers to the various main inclusion requirements, marked by a * prefix: [Availability]: "The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on." * http://packages.ubuntu.com/xenial/admin/zfsutils-linux * Yes - built for 64 bit arches only, because ZFS is designed to run well only on 64 bit architectures. [Rationale]: "There must be a certain level of demand for the package, for example: The package is useful for a large part of our user base." * Yes - there is a lot of interest in ZFS in the server space and for users wanting to use a file system that supports huge collections of disks with excellent reliable features such as checksummed raid, mirroring striping with easy configuration and also simple data sanity checking and fixing. * Being requested by Kiko "The package is a new build dependency or dependency of a package that we already support (additionally, the official image builder requires all used packages be in main)." * Yes, already in Wily as a technology demo. "The package helps meet a specific Blueprint goal." * No blueprint goal. "The package replaces another package we currently support and promises higher quality and/or better features, so that we can drop the old package from the supported set." * Not applicable [Security]: "The security history and the current state of security issues in the package must allow us to support the package for at least 18 months without exposing its users to an inappropriate level of security risks. This requires checking of several things that are explained in detail in the subsection Security checks." "Check how many vulnerabilities the package had in the past and how they were handled by upstream and the Debian/Ubuntu package:" "http://cve.mitre.org/cve/cve.html: Search in the National Vulnerability Database using the package as a keyword" NO ZFS Linux CVEs found, here is the complete list from Mitre: CVE-2015-1415 The bsdinstall installer in FreeBSD 10.x before 10.1 p9, when configuring full disk encrypted ZFS, uses world-readable permissions for the GELI keyfile (/boot/encryption.key), which allows local users to obtain sensitive key information by reading the file. CVE-2015-0448 Unspecified vulnerability in Oracle Sun Solaris 11.2 allows local users to affect confidentiality, integrity, and availability via vectors related to ZFS File system. CVE-2013-3266 The nfsrvd_readdir function in sys/fs/nfsserver/nfs_nfsdport.c in the new NFS server in FreeBSD 8.0 through 9.1-RELEASE-p3 does not verify that a READDIR request is for a directory node, which allows remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code by specifying a plain file instead of a directory. CVE-2011-2313 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect availability, related to ZFS. CVE-2011-2312 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect confidentiality, related to ZFS. CVE-2011-2311 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect availability, related to ZFS. CVE-2011-2286 Unspecified vulnerability in Oracle Solaris 10 and 11 Express allows remote authenticated users to affect availability, related to ZFS. CVE-2010-4458 Unspecified vulnerability in Oracle Solaris 11 Express allows local users to affect availability, related to ZFS. CVE-2010-3540 Unspecified vulnerability in Oracle Solaris 10 and OpenSolaris allows local users to affect availability, related to ZFS. CVE-2010-2392 Unspecified vulnerability in Oracle Solaris 10 and OpenSolaris allows local users to affect integrity and availability, related to ZFS. CVE-2010-0318 The replay functionality for ZFS Intent Log (ZIL) in FreeBSD 7.1, 7.2, and 8.0, when creating files during replay of a setattr transaction, uses permissions instead of the original permissions, which might allow local users to read or modify unauthorized files in opportunistic circumstances after a system crash or power
[Kernel-packages] [Bug 1532198] Re: [MIR] zfs-linux
I see that there's a team bug subscriber now. So the only issue on my original list is fixing the zfs-zed Replaces line for zfsutils-linux. It's such a tiny thing to hold up a MIR, but I guess since xenial deadline is passed and it's so trivial to fix, let's just fix it. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1532198 Title: [MIR] zfs-linux Status in zfs-linux package in Ubuntu: Incomplete Bug description: Following the process documented at https://wiki.ubuntu.com/MainInclusionProcess , the following template needs to be filled in to start the MIR for zfs-linux in 16.04 Below are my answers to the various main inclusion requirements, marked by a * prefix: [Availability]: "The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on." * http://packages.ubuntu.com/xenial/admin/zfsutils-linux * Yes - built for 64 bit arches only, because ZFS is designed to run well only on 64 bit architectures. [Rationale]: "There must be a certain level of demand for the package, for example: The package is useful for a large part of our user base." * Yes - there is a lot of interest in ZFS in the server space and for users wanting to use a file system that supports huge collections of disks with excellent reliable features such as checksummed raid, mirroring striping with easy configuration and also simple data sanity checking and fixing. * Being requested by Kiko "The package is a new build dependency or dependency of a package that we already support (additionally, the official image builder requires all used packages be in main)." * Yes, already in Wily as a technology demo. "The package helps meet a specific Blueprint goal." * No blueprint goal. "The package replaces another package we currently support and promises higher quality and/or better features, so that we can drop the old package from the supported set." * Not applicable [Security]: "The security history and the current state of security issues in the package must allow us to support the package for at least 18 months without exposing its users to an inappropriate level of security risks. This requires checking of several things that are explained in detail in the subsection Security checks." "Check how many vulnerabilities the package had in the past and how they were handled by upstream and the Debian/Ubuntu package:" "http://cve.mitre.org/cve/cve.html: Search in the National Vulnerability Database using the package as a keyword" NO ZFS Linux CVEs found, here is the complete list from Mitre: CVE-2015-1415 The bsdinstall installer in FreeBSD 10.x before 10.1 p9, when configuring full disk encrypted ZFS, uses world-readable permissions for the GELI keyfile (/boot/encryption.key), which allows local users to obtain sensitive key information by reading the file. CVE-2015-0448 Unspecified vulnerability in Oracle Sun Solaris 11.2 allows local users to affect confidentiality, integrity, and availability via vectors related to ZFS File system. CVE-2013-3266 The nfsrvd_readdir function in sys/fs/nfsserver/nfs_nfsdport.c in the new NFS server in FreeBSD 8.0 through 9.1-RELEASE-p3 does not verify that a READDIR request is for a directory node, which allows remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code by specifying a plain file instead of a directory. CVE-2011-2313 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect availability, related to ZFS. CVE-2011-2312 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect confidentiality, related to ZFS. CVE-2011-2311 Unspecified vulnerability in Oracle Solaris 10 allows local users to affect availability, related to ZFS. CVE-2011-2286 Unspecified vulnerability in Oracle Solaris 10 and 11 Express allows remote authenticated users to affect availability, related to ZFS. CVE-2010-4458 Unspecified vulnerability in Oracle Solaris 11 Express allows local users to affect availability, related to ZFS. CVE-2010-3540 Unspecified vulnerability in Oracle Solaris 10 and OpenSolaris allows local users to affect availability, related to ZFS. CVE-2010-2392 Unspecified vulnerability in Oracle Solaris 10 and OpenSolaris allows local users to affect integrity and availability, related to ZFS. CVE-2010-0318 The replay functionality for ZFS Intent Log (ZIL) in FreeBSD 7.1, 7.2, and 8.0, when creating files during replay of a setattr transaction, uses permissions instead of the original permissions, which might allow local users to read
[Kernel-packages] [Bug 1572650] Re: [MIR] ubuntu-fan
** Changed in: ubuntu-fan (Ubuntu) Status: Incomplete => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to ubuntu-fan in Ubuntu. https://bugs.launchpad.net/bugs/1572650 Title: [MIR] ubuntu-fan Status in ubuntu-fan package in Ubuntu: Fix Committed Bug description: [Availability] https://launchpad.net/ubuntu/+source/ubuntu-fan The Ubuntu Fan package is currently available in Universe for Trusty, Vivid, Wily, and Xenial. [Rationale] https://insights.ubuntu.com/2015/06/24/introducing-the-fan-simpler-container-networking/ Additionally, with 16.04 Snappy Ubuntu Core is supposed to be fully supported ... we had a request to always include ubuntu-fan in the snappy images for container networking, so ubuntu-fan needs be moved to main [Quality assurance] The kernel team has ubuntu-fan smoke tests integrated into their routine kernel test suite which gets run for every kernel upload. The kernel team will own any issues with this package. [Dependencies] $ apt-cache depends ubuntu-fan ubuntu-fan Depends: bridge-utils bridge-utils:i386 Depends: iproute2 iproute2:i386 Depends: dnsmasq-base Depends: init-system-helpers Depends: lsb-base Recommends: netcat Netcat-traditional netcat-openbsd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-fan/+bug/1572650/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1492441] Re: Cannot connect to 1byone bluetooth keyboard (after successfully pairing)
Does the keyboard need to be in pairing mode to connect (vs actually pair?). It seemed to help me today, but I had thought that when I first reported this bug I had also tried putting it in pairing mode. Without the keyboard in pairing mode: bluetoothd[4848]: src/device.c:connect_profiles() /org/bluez/hci0/dev_08_73_00_13_CC_45 (all), client :1.147 bluetoothd[4848]: profiles/input/device.c:input_device_connect() bluetoothd[4848]: Can't get HIDP connection info bluetoothd[4848]: src/service.c:change_state() 0x556055ffed90: device 08:73:00:13:CC:45 profile input-hid state changed: disconnected -> connecting (0) bluetoothd[4848]: src/adapter.c:connect_failed_callback() hci0 08:73:00:13:CC:45 status 4 bluetoothd[4848]: plugins/policy.c:conn_fail_cb() status 4 bluetoothd[4848]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 08:73:00:13:CC:45 type 0 status 0x4 bluetoothd[4848]: src/device.c:device_bonding_complete() bonding (nil) status 0x04 bluetoothd[4848]: src/device.c:device_bonding_failed() status 4 bluetoothd[4848]: src/adapter.c:resume_discovery() bluetoothd[4848]: connect error: Host is down (112) bluetoothd[4848]: src/service.c:change_state() 0x556055ffed90: device 08:73:00:13:CC:45 profile input-hid state changed: connecting -> disconnected (-5) bluetoothd[4848]: src/device.c:device_profile_connected() input-hid Input/output error (5) bluetoothd[4848]: src/device.c:device_profile_connected() returning response to :1.147 With the device in pairing mode (it connected! Yay! But now it appears paired and connected, but won't actually type any letters in... so something is still wrong): bluetoothd[4848]: src/device.c:connect_profiles() /org/bluez/hci0/dev_08_73_00_13_CC_45 (all), client :1.147 bluetoothd[4848]: profiles/input/device.c:input_device_connect() bluetoothd[4848]: Can't get HIDP connection info bluetoothd[4848]: src/service.c:change_state() 0x556055ffed90: device 08:73:00:13:CC:45 profile input-hid state changed: disconnected -> connecting (0) bluetoothd[4848]: src/adapter.c:connected_callback() hci0 device 08:73:00:13:CC:45 connected eir_len 17 bluetoothd[4848]: src/service.c:change_state() 0x556055ffed90: device 08:73:00:13:CC:45 profile input-hid state changed: connecting -> connected (0) bluetoothd[4848]: src/device.c:device_profile_connected() input-hid Success (0) bluetoothd[4848]: src/device.c:device_profile_connected() returning response to :1.147 bluetoothd[4848]: src/service.c:btd_service_ref() 0x556055ffed90: ref=3 bluetoothd[4848]: plugins/policy.c:service_cb() Added input-hid reconnect 0 bluetoothd[4848]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 08:73:00:13:CC:45 type 0 status 0x5 bluetoothd[4848]: src/device.c:device_bonding_complete() bonding (nil) status 0x05 bluetoothd[4848]: src/device.c:device_bonding_failed() status 5 bluetoothd[4848]: src/adapter.c:resume_discovery() bluetoothd[4848]: src/device.c:search_cb() 08:73:00:13:CC:45: No service update bluetoothd[4848]: src/device.c:device_svc_resolved() /org/bluez/hci0/dev_08_73_00_13_CC_45 err 0 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1492441 Title: Cannot connect to 1byone bluetooth keyboard (after successfully pairing) Status in bluez package in Ubuntu: New Bug description: I own a 1byone bluetooth keyboard/touchpad combo device. I'm using wily. I have managed to successfully pair it (the UI did not work for this -- bug 1492443). But doing it via the console did pair it: $ bluetoothctl [NEW] Device 08:73:00:13:CC:45 1byone Keyboard [bluetooth]# agent on Agent registered [bluetooth]# default-agent Default agent request successful [bluetooth]# pair 08:73:00:13:CC:45 Attempting to pair with 08:73:00:13:CC:45 [CHG] Device 08:73:00:13:CC:45 Connected: yes [agent] PIN code: 420005 [CHG] Device 08:73:00:13:CC:45 Modalias: usb:v04E8p7021d011B [CHG] Device 08:73:00:13:CC:45 UUIDs: 1000--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 UUIDs: 1124--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 UUIDs: 1200--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 Paired: yes Pairing successful [CHG] Device 08:73:00:13:CC:45 Connected: no [CHG] Device 60:03:08:C9:C0:87 RSSI: -59 [CHG] Device 60:03:08:C9:C0:87 RSSI: -48 [CHG] Device 60:03:08:C9:C0:87 RSSI: -60 [CHG] Device 60:03:08:C9:C0:87 RSSI: -48 etc, etc (kept outputting RSSI bits every now and then) OK. So it paired. (which means it's not bug 1490347) But now I can't connect. You can see above that it says "Connected: no". If I go to the Bluetooth panel in System Settings, its "Connection" switch is set to Off and disabled. But it otherwise seems to be successfully paired. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 4.1.0-3.3-generic
[Kernel-packages] [Bug 1492441] Re: Cannot connect to 1byone bluetooth keyboard (after successfully pairing)
** Description changed: I own a 1byone bluetooth keyboard/touchpad combo device. I'm using wily. I have managed to successfully pair it (the UI did not work for this -- - it never prompted me to type a PIN code in, it just silently failed). - But doing it via the console did pair it: + bug 1492443). But doing it via the console did pair it: $ bluetoothctl [NEW] Device 08:73:00:13:CC:45 1byone Keyboard [bluetooth]# agent on Agent registered [bluetooth]# default-agent Default agent request successful [bluetooth]# pair 08:73:00:13:CC:45 Attempting to pair with 08:73:00:13:CC:45 [CHG] Device 08:73:00:13:CC:45 Connected: yes [agent] PIN code: 420005 [CHG] Device 08:73:00:13:CC:45 Modalias: usb:v04E8p7021d011B [CHG] Device 08:73:00:13:CC:45 UUIDs: 1000--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 UUIDs: 1124--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 UUIDs: 1200--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 Paired: yes Pairing successful [CHG] Device 08:73:00:13:CC:45 Connected: no [CHG] Device 60:03:08:C9:C0:87 RSSI: -59 [CHG] Device 60:03:08:C9:C0:87 RSSI: -48 [CHG] Device 60:03:08:C9:C0:87 RSSI: -60 [CHG] Device 60:03:08:C9:C0:87 RSSI: -48 etc, etc (kept outputting RSSI bits every now and then) OK. So it paired. (which means it's not bug 1490347) But now I can't connect. You can see above that it says "Connected: no". If I go to the Bluetooth panel in System Settings, its "Connection" switch is set to Off and disabled. But it otherwise seems to be successfully paired. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 4.1.0-3.3-generic 4.1.3 Uname: Linux 4.1.0-3-generic x86_64 ApportVersion: 2.18-0ubuntu9 Architecture: amd64 CurrentDesktop: Unity Date: Fri Sep 4 15:16:58 2015 DistributionChannelDescriptor: - # This is a distribution channel descriptor - # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor - canonical-oem-somerville-precise-amd64-20120703-2 + # This is a distribution channel descriptor + # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor + canonical-oem-somerville-precise-amd64-20120703-2 EcryptfsInUse: Yes InstallationDate: Installed on 2013-01-09 (967 days ago) InstallationMedia: Ubuntu 12.04 "Precise" - Build amd64 LIVE Binary 20120703-15:08 InterestingModules: rfcomm bnep btusb bluetooth MachineType: Dell Inc. Dell System XPS L322X ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.1.0-3-generic root=UUID=0719ea95-7c02-4d0a-a969-1ba285c420f2 ro quiet splash vt.handoff=7 SourcePackage: bluez SystemImageInfo: - current build number: 0 - device name: - channel: daily - last update: Unknown + current build number: 0 + device name: + channel: daily + last update: Unknown UpgradeStatus: Upgraded to wily on 2013-01-31 (945 days ago) dmi.bios.date: 12/03/2012 dmi.bios.vendor: Dell Inc. dmi.bios.version: A06 dmi.board.name: 0CK86J dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 0.1 dmi.modalias: dmi:bvnDellInc.:bvrA06:bd12/03/2012:svnDellInc.:pnDellSystemXPSL322X:pvr:rvnDellInc.:rn0CK86J:rvrA00:cvnDellInc.:ct8:cvr0.1: dmi.product.name: Dell System XPS L322X dmi.sys.vendor: Dell Inc. hciconfig: - hci0:Type: BR/EDR Bus: USB - BD Address: C4:85:08:FB:58:0A ACL MTU: 310:10 SCO MTU: 64:8 - UP RUNNING PSCAN - RX bytes:19494 acl:0 sco:0 events:721 errors:0 - TX bytes:3449 acl:0 sco:0 commands:234 errors:1 + hci0:Type: BR/EDR Bus: USB + BD Address: C4:85:08:FB:58:0A ACL MTU: 310:10 SCO MTU: 64:8 + UP RUNNING PSCAN + RX bytes:19494 acl:0 sco:0 events:721 errors:0 + TX bytes:3449 acl:0 sco:0 commands:234 errors:1 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1492441 Title: Cannot connect to 1byone bluetooth keyboard (after successfully pairing) Status in bluez package in Ubuntu: New Bug description: I own a 1byone bluetooth keyboard/touchpad combo device. I'm using wily. I have managed to successfully pair it (the UI did not work for this -- bug 1492443). But doing it via the console did pair it: $ bluetoothctl [NEW] Device 08:73:00:13:CC:45 1byone Keyboard [bluetooth]# agent on Agent registered [bluetooth]# default-agent Default agent request successful [bluetooth]# pair 08:73:00:13:CC:45 Attempting to pair with 08:73:00:13:CC:45 [CHG] Device 08:73:00:13:CC:45 Connected: yes [agent] PIN code: 420005 [CHG] Device 08:73:00:13:CC:45 Modalias: usb:v04E8p7021d011B [CHG] Device 08:73:00:13:CC:45 UUIDs: 1000--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 UUIDs:
[Kernel-packages] [Bug 1492441] [NEW] Cannot connect to 1byone bluetooth keyboard (after successfully pairing)
Public bug reported: I own a 1byone bluetooth keyboard/touchpad combo device. I'm using wily. I have managed to successfully pair it (the UI did not work for this -- it never prompted me to type a PIN code in, it just silently failed). But doing it via the console did pair it: $ bluetoothctl [NEW] Device 08:73:00:13:CC:45 1byone Keyboard [bluetooth]# agent on Agent registered [bluetooth]# default-agent Default agent request successful [bluetooth]# pair 08:73:00:13:CC:45 Attempting to pair with 08:73:00:13:CC:45 [CHG] Device 08:73:00:13:CC:45 Connected: yes [agent] PIN code: 420005 [CHG] Device 08:73:00:13:CC:45 Modalias: usb:v04E8p7021d011B [CHG] Device 08:73:00:13:CC:45 UUIDs: 1000--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 UUIDs: 1124--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 UUIDs: 1200--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 Paired: yes Pairing successful [CHG] Device 08:73:00:13:CC:45 Connected: no [CHG] Device 60:03:08:C9:C0:87 RSSI: -59 [CHG] Device 60:03:08:C9:C0:87 RSSI: -48 [CHG] Device 60:03:08:C9:C0:87 RSSI: -60 [CHG] Device 60:03:08:C9:C0:87 RSSI: -48 etc, etc (kept outputting RSSI bits every now and then) OK. So it paired. (which means it's not bug 1490347) But now I can't connect. You can see above that it says "Connected: no". If I go to the Bluetooth panel in System Settings, its "Connection" switch is set to Off and disabled. But it otherwise seems to be successfully paired. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 4.1.0-3.3-generic 4.1.3 Uname: Linux 4.1.0-3-generic x86_64 ApportVersion: 2.18-0ubuntu9 Architecture: amd64 CurrentDesktop: Unity Date: Fri Sep 4 15:16:58 2015 DistributionChannelDescriptor: # This is a distribution channel descriptor # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-precise-amd64-20120703-2 EcryptfsInUse: Yes InstallationDate: Installed on 2013-01-09 (967 days ago) InstallationMedia: Ubuntu 12.04 "Precise" - Build amd64 LIVE Binary 20120703-15:08 InterestingModules: rfcomm bnep btusb bluetooth MachineType: Dell Inc. Dell System XPS L322X ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.1.0-3-generic root=UUID=0719ea95-7c02-4d0a-a969-1ba285c420f2 ro quiet splash vt.handoff=7 SourcePackage: bluez SystemImageInfo: current build number: 0 device name: channel: daily last update: Unknown UpgradeStatus: Upgraded to wily on 2013-01-31 (945 days ago) dmi.bios.date: 12/03/2012 dmi.bios.vendor: Dell Inc. dmi.bios.version: A06 dmi.board.name: 0CK86J dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 0.1 dmi.modalias: dmi:bvnDellInc.:bvrA06:bd12/03/2012:svnDellInc.:pnDellSystemXPSL322X:pvr:rvnDellInc.:rn0CK86J:rvrA00:cvnDellInc.:ct8:cvr0.1: dmi.product.name: Dell System XPS L322X dmi.sys.vendor: Dell Inc. hciconfig: hci0: Type: BR/EDR Bus: USB BD Address: C4:85:08:FB:58:0A ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:19494 acl:0 sco:0 events:721 errors:0 TX bytes:3449 acl:0 sco:0 commands:234 errors:1 ** Affects: bluez (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug wily -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1492441 Title: Cannot connect to 1byone bluetooth keyboard (after successfully pairing) Status in bluez package in Ubuntu: New Bug description: I own a 1byone bluetooth keyboard/touchpad combo device. I'm using wily. I have managed to successfully pair it (the UI did not work for this -- it never prompted me to type a PIN code in, it just silently failed). But doing it via the console did pair it: $ bluetoothctl [NEW] Device 08:73:00:13:CC:45 1byone Keyboard [bluetooth]# agent on Agent registered [bluetooth]# default-agent Default agent request successful [bluetooth]# pair 08:73:00:13:CC:45 Attempting to pair with 08:73:00:13:CC:45 [CHG] Device 08:73:00:13:CC:45 Connected: yes [agent] PIN code: 420005 [CHG] Device 08:73:00:13:CC:45 Modalias: usb:v04E8p7021d011B [CHG] Device 08:73:00:13:CC:45 UUIDs: 1000--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 UUIDs: 1124--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 UUIDs: 1200--1000-8000-00805f9b34fb [CHG] Device 08:73:00:13:CC:45 Paired: yes Pairing successful [CHG] Device 08:73:00:13:CC:45 Connected: no [CHG] Device 60:03:08:C9:C0:87 RSSI: -59 [CHG] Device 60:03:08:C9:C0:87 RSSI: -48 [CHG] Device 60:03:08:C9:C0:87 RSSI: -60 [CHG] Device 60:03:08:C9:C0:87 RSSI: -48 etc, etc (kept outputting RSSI bits every now and then) OK. So it paired. (which means it's not bug 1490347) But now I can't connect. You can see above that it says
[Kernel-packages] [Bug 1408444] Re: bluetooth-wizard cannot pair keyboard with given pin
A search for bluepin on packages.ubuntu.com shows no package providing it. Where did you get it? (doing "dpkg -S bluepin" may help) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1408444 Title: bluetooth-wizard cannot pair keyboard with given pin Status in bluez package in Ubuntu: New Bug description: To pair e.g. an Iconia W700 type cover using bluetooth-wizard a further line in /etc/bluetooth/main.conf is necessary: pin_helper = /usr/bin/bluepin Without it pairing fails without any comment. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: bluez 4.101-0ubuntu20 ProcVersionSignature: Ubuntu 3.16.0-23.31-generic 3.16.4 Uname: Linux 3.16.0-23-generic x86_64 ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Wed Jan 7 21:48:39 2015 InstallationDate: Installed on 2014-10-22 (77 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) InterestingModules: btusb bnep rfcomm bluetooth MachineType: Acer TP-W700-53334G12 ProcEnviron: LANGUAGE=de_DE PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-23-generic.efi.signed root=UUID=f732ccc6-b7f0--8bcf-da659f0321d0 ro quiet splash SourcePackage: bluez UpgradeStatus: Upgraded to utopic on 2014-10-23 (75 days ago) dmi.bios.date: 05/24/2013 dmi.bios.vendor: Insyde Corp. dmi.bios.version: V2.14 dmi.board.asset.tag: No Asset Tag dmi.board.name: SAGE dmi.board.vendor: Acer dmi.board.version: V2.14 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Insyde Corp. dmi.chassis.version: V2.14 dmi.modalias: dmi:bvnInsydeCorp.:bvrV2.14:bd05/24/2013:svnAcer:pnTP-W700-53334G12:pvrV2.14:rvnAcer:rnSAGE:rvrV2.14:cvnInsydeCorp.:ct10:cvrV2.14: dmi.product.name: TP-W700-53334G12 dmi.product.version: V2.14 dmi.sys.vendor: Acer hciconfig: hci0:Type: BR/EDR Bus: USB BD Address: 24:FD:52:1E:C7:CF ACL MTU: 1022:8 SCO MTU: 183:5 UP RUNNING PSCAN ISCAN RX bytes:612 acl:0 sco:0 events:37 errors:0 TX bytes:942 acl:0 sco:0 commands:37 errors:0 mtime.conffile..etc.bluetooth.main.conf: 2015-01-07T13:38:43.304721 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1408444/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1277065] Re: Sync makedumpfile 1.5.5-2 (main) from Debian unstable (main)
Thanks Louis! I uploaded to trusty with one minor changelog change. You don't need to mention not building arm64 because that was a change made previously that is no longer part of our delta. But besides that, great! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1277065 Title: Sync makedumpfile 1.5.5-2 (main) from Debian unstable (main) Status in “makedumpfile” package in Ubuntu: Confirmed Bug description: Need merging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1277065/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
