| 2018-10-02 10:05:02 |
Julian Andres Klode |
bug |
|
|
added bug |
| 2018-10-02 10:05:09 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-10-02 10:05:09 |
Julian Andres Klode |
bug task added |
|
packagekit (Ubuntu Bionic) |
|
| 2018-10-02 10:05:09 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-10-02 10:05:09 |
Julian Andres Klode |
bug task added |
|
packagekit (Ubuntu Cosmic) |
|
| 2018-10-02 10:05:09 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-10-02 10:05:09 |
Julian Andres Klode |
bug task added |
|
packagekit (Ubuntu Xenial) |
|
| 2018-10-02 10:05:15 |
Julian Andres Klode |
packagekit (Ubuntu Cosmic): status |
New |
Fix Released |
|
| 2018-10-02 10:05:17 |
Julian Andres Klode |
packagekit (Ubuntu Bionic): status |
New |
Triaged |
|
| 2018-10-02 10:05:19 |
Julian Andres Klode |
packagekit (Ubuntu Xenial): status |
New |
Triaged |
|
| 2018-10-02 10:06:25 |
Julian Andres Klode |
description |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though. |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though. |
|
| 2018-10-02 12:33:57 |
Francis Ginther |
tags |
|
id-5bae2d4a668b6f3b803fb88b |
|
| 2018-10-03 14:32:06 |
Julian Andres Klode |
description |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though. |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though. |
|
| 2018-10-04 07:10:57 |
Julian Andres Klode |
description |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though. |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though. |
|
| 2018-10-04 07:12:48 |
Julian Andres Klode |
description |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though. |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state.
See bug 1781169 for more details on frontend locking.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though. |
|
| 2018-10-04 12:17:21 |
Julian Andres Klode |
description |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state.
See bug 1781169 for more details on frontend locking.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though. |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state.
See bug 1781169 for more details on frontend locking.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (bug 1796081)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html |
|
| 2018-10-04 12:39:31 |
Julian Andres Klode |
description |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state.
See bug 1781169 for more details on frontend locking.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (bug 1796081)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state.
See bug 1781169 for more details on frontend locking.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (bug 1796081)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades (bug 1789637)
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html |
|
| 2018-10-04 14:18:14 |
Robie Basak |
description |
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state.
See bug 1781169 for more details on frontend locking.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (bug 1796081)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades (bug 1789637)
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html |
[SRU Notes]
[rbasak] Requires apt 1.2.28 (Xenial) and 1.6.5 (Bionic), both of which are currently in proposed. Do not release to updates without releasing the newer apt first.
[Impact]
PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.
Frontend locking prevents race conditions between multiple dpkg frontends, which can cause other frontends to be interrupted while they are installing stuff - the frontend loses the dpkg lock between dpkg runs and the system ends up in a partially configured state.
See bug 1781169 for more details on frontend locking.
[Test case]
1. Install a package
2. Modify prerm to sleep
3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).
[Regression potential]
Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.
The patch also adds a call to LockInner() after the dpkg execution to make it reacquire "lock", this could fail. It should not have much impact however, as it only affects a single transaction AFAICT. It does reduce the risk of some frontend not implementing frontend locking from racing while we still hold the frontend lock, though.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (bug 1796081)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades (bug 1789637)
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html |
|
| 2018-10-04 14:30:27 |
Robie Basak |
packagekit (Ubuntu Bionic): status |
Triaged |
Fix Committed |
|
| 2018-10-04 14:30:28 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-10-04 14:30:31 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2018-10-04 14:30:34 |
Robie Basak |
tags |
id-5bae2d4a668b6f3b803fb88b |
id-5bae2d4a668b6f3b803fb88b verification-needed verification-needed-bionic |
|
| 2018-10-04 14:32:11 |
Robie Basak |
packagekit (Ubuntu Xenial): status |
Triaged |
Fix Committed |
|
| 2018-10-04 14:32:15 |
Robie Basak |
tags |
id-5bae2d4a668b6f3b803fb88b verification-needed verification-needed-bionic |
id-5bae2d4a668b6f3b803fb88b verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2018-10-18 13:46:22 |
Julian Andres Klode |
tags |
id-5bae2d4a668b6f3b803fb88b verification-needed verification-needed-bionic verification-needed-xenial |
id-5bae2d4a668b6f3b803fb88b verification-done-bionic verification-needed verification-needed-xenial |
|
| 2018-10-18 13:51:49 |
Julian Andres Klode |
tags |
id-5bae2d4a668b6f3b803fb88b verification-done-bionic verification-needed verification-needed-xenial |
id-5bae2d4a668b6f3b803fb88b verification-done verification-done-bionic verification-done-xenial |
|
| 2018-10-25 14:49:03 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-10-25 14:49:12 |
Launchpad Janitor |
packagekit (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-10-25 15:29:55 |
Launchpad Janitor |
packagekit (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
