[Group.of.nepali.translators] [Bug 1645324] Re: ebtables: Lock file handling has races
** Changed in: ebtables (Debian)
Status: New => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1645324
Title:
ebtables: Lock file handling has races
Status in ebtables package in Ubuntu:
Fix Released
Status in ebtables source package in Trusty:
Fix Released
Status in ebtables source package in Xenial:
Fix Released
Status in ebtables source package in Yakkety:
Fix Released
Status in ebtables source package in Zesty:
Fix Released
Status in ebtables source package in Artful:
Fix Released
Status in ebtables package in Debian:
Fix Released
Bug description:
[Impact]
* ebtables uses creation of a file with an exclusive flag
as a lock to synchronize table modification when used
with --concurrent parameter.
* If ebtables crashes it will leave a stale lock file.
This will prevent another copy of ebtables from running,
and indirectly any other service that depends on ebtables
will also be affected.
* This change adds support for real locks that get
cleaned up if a process exits or crashes.
[Test Case]
* Test Case1:
1. $ sudo touch /var/lib/ebtables/lock"
2. $ sudo ebtables --concurrent -L
3. ebtables can't acquire a lock
* Test Case 2:
1. $ while true; do /usr/sbin/ebtables --concurrent -L; done
2. hard reboot VM
3. likely that the lock file is present under /var/lib/ebtables
4. libvird hanging, try to connect to qemu:///system
[Regression Potential]
* Normal Use:
There is no regression potential during normal use and
operation of ebtables.
* Package Upgrade:
There is a very very small regression potential during the package
upgrade to the latest version. Once the package is upgraded that
potential is gone. It is a very small potential because several
things have to happen in a very small time frame and in an exact
order since ebtables is not a resident program like a daemon:
1. ebtables is launched during package upgrade AND
2. new ebtables binary has not yet been written to disk AND
3. it is launched with --concurent switch AND
4. another ebtables with new binary is launched AND
5. it is launched with --concurent switch AND
6. the first ebtables copy hasn't exited yet AND
7. both copies of ebtables are launched with a WRITE command AND
8. both copies of ebtables are manipulating the same resource.
Then one of the binaries could potentially fail, but once the old
binary exits the potential is gone so subsequent re-runs of
ebtables will succeed.
* Dragan's patch has been submitted to Debian via :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860590
* Note that the ebtables upstream project is nearly dead. Nowadays,
all the development is now happening in nft project which is intended
to be replacement.
[Original Text]
libvirtd is hanging after startup due to ebtables lock file -from an earlier
run- remains intact when the system reboots.
Same issue is happening than it is reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1290327 when the system boots.
After booting the system, It's not possible connect to the qemu-service.
- libvirt daemon tried to obtain a lock:
[pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45
[pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2,
4294967295) = 1 ([{fd=24, revents=POLLIN}])
[pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45
[pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2,
4294967295) = 1 ([{fd=24, revents=POLLIN}])
[pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45
[pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2,
4294967295^CProcess 20916 detached
- there was a file named 'lock' in /var/lib/ebtables directory with timestamp
14:54
- ebtables was configured:
* Ebtables support available, number of installed rules [ OK ]
(other nodes appeared to be in the same state from ebtables point of view,
but without the lock file)
- I removed the lock file and libvirt started to work instantly - the lock
obtain messages have disappeared from the trace and virsh commands are working
- at 14:54 the host was booting up. According to the logs, there were other
reboots after that one, but the lock file remained intact (at least the
timestamp was not updated).
Could you please suggest a solution to be sure that ebtables lock file
is removed during boot?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1645324/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to :
[Group.of.nepali.translators] [Bug 1790788] Re: Customize 'crashkernel' parameter is not properly working
** Description changed:
SRU Justification:
--
[Impact]
- * While installing makedumpfile the "crashkernel=" argument is not
+ * While installing makedumpfile the "crashkernel=" argument is not
properly set, hence dump is not triggered on reboot.
- * Means the triggering of dumpfiles is currently not possible using
+ * Means the triggering of dumpfiles is currently not possible using
makedumpfile.
- * Dumpfiles are obviously only needed in rare cases, but if they are
+ * Dumpfiles are obviously only needed in rare cases, but if they are
needed (e.g. in production environments) the situation is usually
critical.
- * Hence fixing this is needed to allow post-mortem analysis of a dumps.
+ * Hence fixing this is needed to allow post-mortem analysis of a dumps.
- * The provided shell code snippet provides a fixed sed statement that
+ * The provided shell code snippet provides a fixed sed statement that
makes sure that the kernel parameter is propoerly set.
[Test Case]
- * Create and boot a s390x (KVM virtual) machine
+ * Create and boot a s390x (KVM virtual) machine
- * Install kdump-tools and makedumpfile
-Select 'yes' on question 'Should kdump-tools be enabled by default?'
during installation
+ * Install kdump-tools and makedumpfile
+ Select 'yes' on question 'Should kdump-tools be enabled by default?'
during installation
- * [ Reboot system ]
+ * [ Reboot system ]
- * Look for crashkernel line in zipl boot-loader
-grep crashkernel /etc/zipl.conf
-crashkernel line is missing in case this bug still exists
-one or more lines like this should be given:
-parameters = root=UUID=5ed8f208-adce-4fad-b1a6-feb5e8732d89
crashkernel=196M
+ * Look for crashkernel line in zipl boot-loader
+ grep crashkernel /etc/zipl.conf
+ crashkernel line is missing in case this bug still exists
+ one or more lines like this should be given:
+ parameters = root=UUID=5ed8f208-adce-4fad-b1a6-feb5e8732d89
crashkernel=196M
- * One may further trigger a crash (for a full positiv test)
-sudo -s
-sysctl -w kernel.sysrq=1
-echo c > /proc/sysrq-trigger
-(in case this bug still exists the system will not come up again - check
console in parallel)
+ * One may further trigger a crash (for a full positiv test)
+ sudo -s
+ sysctl -w kernel.sysrq=1
+ echo c > /proc/sysrq-trigger
+ (in case this bug still exists the system will not come up again - check
console in parallel)
+Finally dump files should be visible in /var/crash
[Regression Potential]
- * The regression potential is very low, since:
+ * The regression potential is very low, since:
- * it's limited to the zipl boot loader configuration file only
-and this means again it's on the s390x platform only (IBM Z)
+ * it's limited to the zipl boot loader configuration file only
+ and this means again it's on the s390x platform only (IBM Z)
- * kdump-tools and makedumpfile are not installed by default and only used in
debug situations
-hence only system where the package(s) got manually installed get updated
+ * kdump-tools and makedumpfile are not installed by default and only used in
debug situations
+ hence only system where the package(s) got manually installed get updated
- * The function is today broken anyway, hence it can actually only get
+ * The function is today broken anyway, hence it can actually only get
better
- * I successfully verified this in disco.
+ * I successfully verified this in disco.
_
Trying to use crashdump especially in a KVM machine.
Installation looks fine and the reboot is triggered.
But it does not work because the kernel does not have a 'crashkernel='
parameter.
Nothing in /proc/cmdline:
$ cat /proc/cmdline
root=LABEL=cloudimg-rootfs
Issue seems to be in adding the crashkernel line in this snippet:
# Customize crashkernel= value according to architecture
ARCH="$(arch)"
DEF_PRESET="384M-:128M"
case "$ARCH" in
s390x)
HAS_CRASHKERNEL="$(grep crashkernel /etc/zipl.conf)" || true
if test -z "$HAS_CRASHKERNEL"; then
sed -i "/parameters/{s|\"$| crashkernel=${DEF_PRESET}\"|}"
/etc/zipl.conf
zipl
fi
CIO_IGNORE="$(cio_ignore -u -k)"
sed -i "s/\#KDUMP_CMDLINE_APPEND/KDUMP_CMDLINE_APPEND/" $INITCONFFILE
sed -i "/KDUMP_CMDLINE_APPEND/{s|\"$| ${CIO_IGNORE}\"|}"
$INITCONFFILE
;;
esac
(especially 1st sed stmt)
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Status: New => In Progress
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1790788
Title:
Customize 'crashkernel' parameter is not properly
[Group.of.nepali.translators] [Bug 1722936] Re: sssd hbac rule applicaton for AD users is inconsistent
should be fixed bionic and up ** Also affects: sssd (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: sssd (Ubuntu) Status: Triaged => Fix Released ** Changed in: sssd (Ubuntu Xenial) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-xenial -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1722936 Title: sssd hbac rule applicaton for AD users is inconsistent Status in sssd package in Ubuntu: Fix Released Status in sssd source package in Xenial: Fix Committed Bug description: [Impact] From the upstream bug at https://pagure.io/SSSD/sssd/issue/3382: """ In IPA-AD trust environment, sssd is intermittently failing to map AD user group with IPA POSIX group hence getting access denied due to HBAC rules. The issue gets resolved automatically after certain time, without restarting the sssd service. i.e: The IPA HBAC code used to read the group members from the the originalMemberOf attribute value for performance reasons. However, especially on IPA clients trusting an AD domain, the originalMemberOf attribute value is often not synchronized correctly. """ [Test Case] Coming up with a simple test case is not feasable. Even upstream wasn't able to reliably reproduce the issue in a controlled manner. My best suggestion is for affected users to try the updated package and observe if the incorrect access denied error stops happening. This involves setting up an AD server, a FreeIPA one, creating trust between them, and nested groups and HBAC rules. Upstream's description of such a scenario is at https://github.com/SSSD/sssd/pull/309#issuecomment-318037063 [Regression Potential] The patch changes how group membership in this scenario is computed. It's a complex setup, and we are relying on a) patch has been applied upstream and backported to 1.13; b) user who reported this bug confirmed it fixed the issue with a custom build he did; c) upstream test suite passed; d) dep8 tests (new with this SRU) also pass. [Other Info] The scenario where the bug happens is too complex to reproduce in a test case, but does happen out in the wild according to this report and also in upstream's bug tracker. I decided to add the DEP8 tests to this update as well to give extra confidence in this and future updates, even though it doesn't exercise this bug in particular. [Original Description] NAME="Ubuntu" VERSION="16.04.3 LTS (Xenial Xerus)" sssd Version: 1.13.4-1ubuntu1.8 I'm sometimes seeing AD users denied access to a machine due to HBAC access rules: (Tue Oct 3 04:11:09 2017) [sssd[be[nwra.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules Upstream suggest applying this commit: https://pagure.io/SSSD/sssd/c/88f6d8ad4eef4b4fa032fd451ad732cf8201b0bf That was made on the 1.13 branch but not yet released. More here: https://lists.fedorahosted.org/archives/list/sssd- us...@lists.fedorahosted.org/message/YIHC2C6JDNQLYMW7K7IXQKKIIRMO3QER/ I'm currently testing out a local package with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1722936/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1718839] Re: nvidia-340 340.104-0ubuntu1: nvidia-340 kernel module failed to build (error: initialization from incompatible pointer type [-Werror=incompatible-pointe
** No longer affects: nvidia-graphics-drivers-340 (Ubuntu Xenial) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1718839 Title: nvidia-340 340.104-0ubuntu1: nvidia-340 kernel module failed to build (error: initialization from incompatible pointer type [-Werror =incompatible-pointer-types] .fault = _fault,) Status in nvidia-graphics-drivers-340 package in Ubuntu: Invalid Bug description: After installing new drivers when I restart, it shows crash report. ProblemType: Package DistroRelease: Ubuntu 17.10 Package: nvidia-340 340.104-0ubuntu2 ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1 Uname: Linux 4.13.0-11-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 DKMSKernelVersion: 4.13.0-11-generic Date: Thu Sep 21 15:08:42 2017 DuplicateSignature: dkms:nvidia-340:340.104-0ubuntu1:/var/lib/dkms/nvidia-340/340.104/build/uvm/nvidia_uvm_lite.c:857:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] InstallationDate: Installed on 2017-04-03 (171 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageVersion: 340.104-0ubuntu1 Python3Details: /usr/bin/python3.6, Python 3.6.3rc1, python3-minimal, 3.6.2-1ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.14, python-minimal, 2.7.14-1 RelatedPackageVersions: dpkg 1.18.24ubuntu1 apt 1.5~rc4 SourcePackage: nvidia-graphics-drivers-340 Title: nvidia-340 340.104-0ubuntu1: nvidia-340 kernel module failed to build UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-340/+bug/1718839/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1819077] Re: nvidia-340 340.107-0ubuntu0.16.04.1: nvidia-340 kernel module failed to build (nvidia_uvm_lite.c:857:14: error: initialization from incompatible pointer
This is not a duplicate, since it was caused by a driver in xenial- proposed that was accepted yesterday. ** This bug is no longer a duplicate of bug 1718839 nvidia-340 340.104-0ubuntu1: nvidia-340 kernel module failed to build (error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .fault = _fault,) ** Also affects: nvidia-graphics-drivers-340 (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: nvidia-graphics-drivers-340 (Ubuntu Xenial) Status: New => In Progress ** Changed in: nvidia-graphics-drivers-340 (Ubuntu Xenial) Importance: Undecided => High ** Changed in: nvidia-graphics-drivers-340 (Ubuntu Xenial) Assignee: (unassigned) => Alberto Milone (albertomilone) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1819077 Title: nvidia-340 340.107-0ubuntu0.16.04.1: nvidia-340 kernel module failed to build (nvidia_uvm_lite.c:857:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]) Status in nvidia-graphics-drivers-340 package in Ubuntu: New Status in nvidia-graphics-drivers-340 source package in Xenial: In Progress Bug description: nvidia-340 (from xenial-proposed) does not work with kernel from linux-generic-hwe-16.04. ProblemType: Package DistroRelease: Ubuntu 16.04 Package: nvidia-340 340.107-0ubuntu0.16.04.1 ProcVersionSignature: Ubuntu 4.4.0-142.168-generic 4.4.167 Uname: Linux 4.4.0-142-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.104 Thu Sep 14 17:13:13 PDT 2017 GCC version: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 BootLog: root: clean, 221224/1281120 files, 2095043/512 blocks CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None DKMSKernelVersion: 4.15.0-46-generic Date: Fri Mar 8 01:23:53 2019 DistUpgraded: Fresh install DistroCodename: xenial DistroVariant: ubuntu DkmsStatus: bbswitch, 0.8, 4.15.0-46-generic, x86_64: installed bbswitch, 0.8, 4.4.0-142-generic, x86_64: installed nvidia-340, 340.107, 4.4.0-142-generic, x86_64: installed DuplicateSignature: dkms:nvidia-340:340.107-0ubuntu0.16.04.1:/var/lib/dkms/nvidia-340/340.107/build/uvm/nvidia_uvm_lite.c:857:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] GraphicsCard: NVIDIA Corporation G84GLM [Quadro FX 570M] [10de:040c] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company G84GLM [Quadro FX 570M] [103c:30c5] InstallationDate: Installed on 2015-11-21 (1202 days ago) InstallationMedia: Xubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021) LightdmGreeterLogOld: ** Message: Starting lightdm-gtk-greeter 2.0.1 (Aug 7 2015, 01:24:18) ** Message: [Configuration] Reading file: /etc/lightdm/lightdm-gtk-greeter.conf.d/01_ubuntu.conf ** Message: [Configuration] Reading file: /etc/lightdm/lightdm-gtk-greeter.conf.d/30_xubuntu.conf ** Message: [Configuration] Reading file: /etc/lightdm/lightdm-gtk-greeter.conf upstart: indicator-application main process (970) killed by TERM signal PackageVersion: 340.107-0ubuntu0.16.04.1 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-142-generic root=UUID=bdc3be24-dee9-4ead-bca0-c9b1e45a87e5 ro persistent quiet splash RelatedPackageVersions: dpkg 1.18.4ubuntu1.5 apt 1.2.29ubuntu0.1 SourcePackage: nvidia-graphics-drivers-340 Title: nvidia-340 340.107-0ubuntu0.16.04.1: nvidia-340 kernel module failed to build UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/01/2011 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: 68MVD Ver. F.20 dmi.board.name: 30C5 dmi.board.vendor: Hewlett-Packard dmi.board.version: KBC Version 71.36 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvr68MVDVer.F.20:bd12/01/2011:svnHewlett-Packard:pn:pvrF.20:rvnHewlett-Packard:rn30C5:rvrKBCVersion71.36:cvnHewlett-Packard:ct10:cvr: dmi.product.version: F.20 dmi.sys.vendor: Hewlett-Packard modified.conffile..etc.modprobe.d.nvidia-340_hybrid.conf: [deleted] version.compiz: compiz N/A version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.91-2~16.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.5-0ubuntu0~16.04.1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.5-0ubuntu0~16.04.1 version.nvidia-graphics-drivers:
[Group.of.nepali.translators] [Bug 1790788] Re: Customize 'crashkernel' parameter is not properly working
needs SRU template, test case etc
** Also affects: makedumpfile (Ubuntu Disco)
Importance: High
Assignee: Thadeu Lima de Souza Cascardo (cascardo)
Status: Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1790788
Title:
Customize 'crashkernel' parameter is not properly working
Status in makedumpfile package in Ubuntu:
Fix Released
Status in makedumpfile source package in Xenial:
New
Status in makedumpfile source package in Bionic:
New
Status in makedumpfile source package in Cosmic:
In Progress
Status in makedumpfile source package in Disco:
Fix Released
Bug description:
Trying to use crashdump especially in a KVM machine.
Installation looks fine and the reboot is triggered.
But it does not work because the kernel does not have a 'crashkernel='
parameter.
Nothing in /proc/cmdline:
$ cat /proc/cmdline
root=LABEL=cloudimg-rootfs
Issue seems to be in adding the crashkernel line in this snippet:
# Customize crashkernel= value according to architecture
ARCH="$(arch)"
DEF_PRESET="384M-:128M"
case "$ARCH" in
s390x)
HAS_CRASHKERNEL="$(grep crashkernel /etc/zipl.conf)" || true
if test -z "$HAS_CRASHKERNEL"; then
sed -i "/parameters/{s|\"$| crashkernel=${DEF_PRESET}\"|}"
/etc/zipl.conf
zipl
fi
CIO_IGNORE="$(cio_ignore -u -k)"
sed -i "s/\#KDUMP_CMDLINE_APPEND/KDUMP_CMDLINE_APPEND/" $INITCONFFILE
sed -i "/KDUMP_CMDLINE_APPEND/{s|\"$| ${CIO_IGNORE}\"|}"
$INITCONFFILE
;;
esac
(especially 1st sed stmt)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1790788/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1718839] Re: nvidia-340 340.104-0ubuntu1: nvidia-340 kernel module failed to build (error: initialization from incompatible pointer type [-Werror=incompatible-pointe
** Changed in: nvidia-graphics-drivers-340 (Ubuntu) Status: Confirmed => Triaged ** Also affects: nvidia-graphics-drivers-340 (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: nvidia-graphics-drivers-340 (Ubuntu Xenial) Status: New => In Progress ** Changed in: nvidia-graphics-drivers-340 (Ubuntu Xenial) Importance: Undecided => High ** Changed in: nvidia-graphics-drivers-340 (Ubuntu Xenial) Assignee: (unassigned) => Alberto Milone (albertomilone) ** Changed in: nvidia-graphics-drivers-340 (Ubuntu) Status: Triaged => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1718839 Title: nvidia-340 340.104-0ubuntu1: nvidia-340 kernel module failed to build (error: initialization from incompatible pointer type [-Werror =incompatible-pointer-types] .fault = _fault,) Status in nvidia-graphics-drivers-340 package in Ubuntu: Invalid Status in nvidia-graphics-drivers-340 source package in Xenial: In Progress Bug description: After installing new drivers when I restart, it shows crash report. ProblemType: Package DistroRelease: Ubuntu 17.10 Package: nvidia-340 340.104-0ubuntu2 ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1 Uname: Linux 4.13.0-11-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 DKMSKernelVersion: 4.13.0-11-generic Date: Thu Sep 21 15:08:42 2017 DuplicateSignature: dkms:nvidia-340:340.104-0ubuntu1:/var/lib/dkms/nvidia-340/340.104/build/uvm/nvidia_uvm_lite.c:857:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] InstallationDate: Installed on 2017-04-03 (171 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageVersion: 340.104-0ubuntu1 Python3Details: /usr/bin/python3.6, Python 3.6.3rc1, python3-minimal, 3.6.2-1ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.14, python-minimal, 2.7.14-1 RelatedPackageVersions: dpkg 1.18.24ubuntu1 apt 1.5~rc4 SourcePackage: nvidia-graphics-drivers-340 Title: nvidia-340 340.104-0ubuntu1: nvidia-340 kernel module failed to build UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-340/+bug/1718839/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1815665] Re: New upstream microreleases 9.5.16, 10.7 and 11.2
After adapting the description for the new insights I uploaded the two 10.7 branches (Bionic/Cosmic) to the unapproved queue as well (9.5 for Xenial was there already). ** Changed in: postgresql-10 (Ubuntu Cosmic) Status: Triaged => In Progress ** Changed in: postgresql-10 (Ubuntu Bionic) Status: Triaged => In Progress ** Changed in: pg-repack (Ubuntu Bionic) Status: Triaged => Invalid ** Changed in: pg-repack (Ubuntu Cosmic) Status: Triaged => Invalid ** Changed in: postgresql-plproxy (Ubuntu Bionic) Status: Triaged => Invalid ** Changed in: postgresql-plproxy (Ubuntu Cosmic) Status: Triaged => Invalid ** Changed in: postgresql-rum (Ubuntu) Status: Invalid => New ** Changed in: postgresql-rum (Ubuntu Bionic) Status: New => Invalid ** Changed in: postgresql-rum (Ubuntu Cosmic) Status: New => Invalid ** Changed in: skytools3 (Ubuntu Xenial) Status: Triaged => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1815665 Title: New upstream microreleases 9.5.16, 10.7 and 11.2 Status in pg-partman package in Ubuntu: Invalid Status in pg-repack package in Ubuntu: Invalid Status in pglogical-ticker package in Ubuntu: Confirmed Status in postgresql-10 package in Ubuntu: Invalid Status in postgresql-11 package in Ubuntu: Confirmed Status in postgresql-9.5 package in Ubuntu: Invalid Status in postgresql-plproxy package in Ubuntu: Invalid Status in postgresql-rum package in Ubuntu: Fix Released Status in skytools3 package in Ubuntu: Invalid Status in postgresql-9.5 source package in Xenial: In Progress Status in skytools3 source package in Xenial: Invalid Status in pg-repack source package in Bionic: Invalid Status in postgresql-10 source package in Bionic: In Progress Status in postgresql-plproxy source package in Bionic: Invalid Status in postgresql-rum source package in Bionic: Invalid Status in pg-partman source package in Cosmic: Invalid Status in pg-repack source package in Cosmic: Invalid Status in postgresql-10 source package in Cosmic: In Progress Status in postgresql-plproxy source package in Cosmic: Invalid Status in postgresql-rum source package in Cosmic: Invalid Status in postgresql-11 source package in Disco: Confirmed Bug description: Current versions in supported releases: postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic Special cases: - Disco will be synced from Debian soon (we are on 11.1-2) - This is again a security update, so we prep and security will eval and publish through -security Last relevant related stable updates: 9.5.16, 10.7 So the todo is to pick: MRE: Xenial 9.5.14 from https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz MRE: Bionic/Cosmic 10.7 from https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz Standing MRE - Consider last updates as template: - pad.lv/1637236 - pad.lv/1664478 - pad.lv/1690730 - pad.lv/1713979 - pad.lv/1730661 - pad.lv/1747676 - pad.lv/1752271 - pad.lv/1786938 New - this bug - pad.lv/1815665 As usual we test and prep from the PPA and then push through SRU/Security as applicable. Regression potential: - usually this works smoothly except a few test hickups that need to be clarified to be sure. But this time there are changes worth to mention for the SRU team. - change [1] is in all branches Xenil/Bionic/Cosmic and after coordinating with Debian and Upstream and some members of the SRU Team (Malta) and Debian we decided to revert this change in all releases that get SRUs (So 11.x in Disco is the only who will get it). What makes this slightly more important is that: if client_min_messages is misused, then not having that fix could cause bad data. But users of Ubuntu are either: a) not affected at all and therefore are fine as-is (majority) b) not affected by the problem but have tests/scripts/CI/... that rely on the behavior (we don't want to SRU break them) c) have a case that is affected, in that case the "code using client_min_messages" is the one to be considered broken (in favor of the majority of users) and that code should be changed instead of PostgreSQL. Furthermore with that decision we are also in sync with Debian handling the same - Change [2] renaming of symbols rb/rbt is fine doing forward (Disco), but not in Bionic/Cosmic as we'd break en external ABI of the past in an SRU. Please Note that the offending plruby this change was made for is not even in the Archive.
[Group.of.nepali.translators] [Bug 1815665] Re: New upstream microreleases 9.5.16, 10.7 and 11.2
Due to the reverts this is much less disruptive, plenty of bug tasks got invalid. As 11.2 gets the change postgresql-rum in Disco is affected, but that is already in 1.3.2-4 which is in Disco. ** Changed in: postgresql-rum (Ubuntu) Status: New => Fix Released ** Changed in: postgresql-11 (Ubuntu Disco) Importance: Undecided => Critical ** Also affects: pglogical-ticker (Ubuntu) Importance: Undecided Status: New ** Changed in: pglogical-ticker (Ubuntu) Importance: Undecided => Critical ** Changed in: pglogical-ticker (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1815665 Title: New upstream microreleases 9.5.16, 10.7 and 11.2 Status in pg-partman package in Ubuntu: Invalid Status in pg-repack package in Ubuntu: Invalid Status in pglogical-ticker package in Ubuntu: Confirmed Status in postgresql-10 package in Ubuntu: Invalid Status in postgresql-11 package in Ubuntu: Confirmed Status in postgresql-9.5 package in Ubuntu: Invalid Status in postgresql-plproxy package in Ubuntu: Invalid Status in postgresql-rum package in Ubuntu: Fix Released Status in skytools3 package in Ubuntu: Invalid Status in postgresql-9.5 source package in Xenial: In Progress Status in skytools3 source package in Xenial: Invalid Status in pg-repack source package in Bionic: Invalid Status in postgresql-10 source package in Bionic: In Progress Status in postgresql-plproxy source package in Bionic: Invalid Status in postgresql-rum source package in Bionic: Invalid Status in pg-partman source package in Cosmic: Invalid Status in pg-repack source package in Cosmic: Invalid Status in postgresql-10 source package in Cosmic: In Progress Status in postgresql-plproxy source package in Cosmic: Invalid Status in postgresql-rum source package in Cosmic: Invalid Status in postgresql-11 source package in Disco: Confirmed Bug description: Current versions in supported releases: postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic Special cases: - Disco will be synced from Debian soon (we are on 11.1-2) - This is again a security update, so we prep and security will eval and publish through -security Last relevant related stable updates: 9.5.16, 10.7 So the todo is to pick: MRE: Xenial 9.5.14 from https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz MRE: Bionic/Cosmic 10.7 from https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz Standing MRE - Consider last updates as template: - pad.lv/1637236 - pad.lv/1664478 - pad.lv/1690730 - pad.lv/1713979 - pad.lv/1730661 - pad.lv/1747676 - pad.lv/1752271 - pad.lv/1786938 New - this bug - pad.lv/1815665 As usual we test and prep from the PPA and then push through SRU/Security as applicable. Regression potential: - usually this works smoothly except a few test hickups that need to be clarified to be sure. But this time there are changes worth to mention for the SRU team. - change [1] is in all branches Xenil/Bionic/Cosmic and after coordinating with Debian and Upstream and some members of the SRU Team (Malta) and Debian we decided to revert this change in all releases that get SRUs (So 11.x in Disco is the only who will get it). What makes this slightly more important is that: if client_min_messages is misused, then not having that fix could cause bad data. But users of Ubuntu are either: a) not affected at all and therefore are fine as-is (majority) b) not affected by the problem but have tests/scripts/CI/... that rely on the behavior (we don't want to SRU break them) c) have a case that is affected, in that case the "code using client_min_messages" is the one to be considered broken (in favor of the majority of users) and that code should be changed instead of PostgreSQL. Furthermore with that decision we are also in sync with Debian handling the same - Change [2] renaming of symbols rb/rbt is fine doing forward (Disco), but not in Bionic/Cosmic as we'd break en external ABI of the past in an SRU. Please Note that the offending plruby this change was made for is not even in the Archive. => Especially in regard to "regression potential" that means that we will NOT apply the two changes that are somewhat discussion-worthy. We might in later updates reconsider them, but for now when applying the latest stable release we revert those two primarily for the reason to have the lowest possible regression potential for the SRU.
