| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| backport/Revert-network-un-set-the-firewalld-zone-while-shutting-d.patch | Revert "network: *un*set the firewalld zone while shutting down a network" This reverts commit 200f60b2e12e68d618f6d59f0173bb507b678838. The same functionality will be re-added in a different way in an upcoming patch. (cherry picked from commit 816876f51740da8b73c2176de3a64646772218f3) |
Laine Stump <laine@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/816876f51740da8b73c2176de3a64646772218f3 | 2024-10-04 | |
| backport/Revert-network-support-setting-firewalld-zone-for-bridge-.patch | Revert "network: support setting firewalld zone for bridge device of open networks" This reverts commit 1a72b83d566df952033529001b0f88a66d7f4393. That patch had made the incorrect assumption that the firewalld zone of a bridge would not be changed/removed when firewalld reloaded its rules (e.g. with "killall -HUP firewalld"). It turns out my memory was faulty, and this *does* remove the bridge interface's zone, which results in guest networking failure after a firewalld reload, until the virtual network is restarted. The functionality reverted as a result of this patch reversion will be added back in an upcoming patch that keeps the zone setting in networkAddFirewallRules() (rather than moving it into a separate function) so that it is called every time the network's firewall rules are reloaded (including the reload that happens in response to a reload notification from firewalld). (cherry picked from commit ef760a413361a8992a3e56884a1ec09290954c71) |
Laine Stump <laine@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/ef760a413361a8992a3e56884a1ec09290954c71 | 2024-10-04 | |
| backport/network-call-network-Add-Remove-FirewallRules-for-forward.patch | network: call network(Add|Remove)FirewallRules() for forward mode='open' Previously networkAddFirewallRules() and networkRemoveFirewallRules() were only called if the forward mode was none, 'route', or 'nat', so those functions didn't check the forward mode. Although their current contents shouldn't be executed for forward mode='open', soon they will have extra functionality that should be executed for all the current forward modes and also mode='open'. This patch modifies all places either of the functions are called to make sure they are called for mode='open' in addition to current modes (by either adding 'case ..._OPEN:' to the case of a switch statement, or just removing an 'if (mode != ...OPEN)' around the calls; to balance out for that, it puts the entirety of the contents of both functions inside if (mode != ...OPEN) to retain current behavior. (an upcoming patch will add code outside that if clause). debug log messages were also added to make it easier to test that the right thing is being done in all cases. (cherry picked from commit d552d810b97d478675eac830164349d8a1a35e63) |
Laine Stump <laine@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/d552d810b97d478675eac830164349d8a1a35e63 | 2024-10-04 | |
| backport/network-a-different-way-of-supporting-firewalld-zone-for-.patch | network: a different way of supporting firewalld zone for mode='open' networks Now that networkAddFirewallRules and networkRemoveFirewallRules() are being called for mode='open' networks, we just need to move the code that sets the zone outside of the if (mode != ...OPEN) clause, so that it's done for all forward modes, with the exception of setting the implied 'libvirt*' zones, which are set when no zone is specified for all forward modes *except* 'open'. This was previously done in commit v10.7.0-76-g1a72b83d56, but in a manner that caused the zone to be unset whenever firewalld reloaded its rules. That patch was reverted, and this new better patch takes its place. (cherry picked from commit cb4e38d4b1e947d0718232a59f964f35ad156c74) |
Laine Stump <laine@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/cb4e38d4b1e947d0718232a59f964f35ad156c74 | 2024-10-04 | |
| backport/network-a-different-implementation-of-un-setting-firewall.patch | network: a different implementation of *un*setting firewalld zone when network is destroyed (this is a remake of commit v10.7.0-78-g200f60b2e1, which was reverted due to a regression in another patch it was dependent on. The new implementation just adds the call to virFirewallDInterfaceUnsetZone() into the existing networkRemoveFirewallRules() (but only if we had set a zone when the network was first started). (cherry picked from commit c0ba3ed69d14a4b9a03475d1ba1d734b27a141f8) |
Laine Stump <laine@redhat.com> | not-needed | https://gitlab.com/libvirt/libvirt/-/commit/c0ba3ed69d14a4b9a03475d1ba1d734b27a141f8 | 2024-10-04 | |
| forward/Reduce-udevadm-settle-timeout-to-10-seconds.patch | Reduce udevadm settle timeout to 10 seconds This isn't a proper fix but it will make virt-manager at least start. |
=?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org> | no | 2012-06-04 | ||
| debian/Debianize-libvirt-guests.patch | Debianize libvirt-guests | =?utf-8?q?Laurent_L=C3=A9onard?= <laurent@open-minds.org> | not-needed | 2010-12-09 | ||
| debian/apparmor_profiles_local_include.patch | apparmor_profiles_local_include Include local apparmor profile |
Felix Geyer <fgeyer@debian.org> | not-needed | 2015-08-11 | ||
| debian/Use-sensible-editor-by-default.patch | Use sensible-editor by default It is the reasonable default for Debian. |
Andrea Bolognani <eof@kiyuko.org> | not-needed | 2020-08-18 |