opencv 4.1.2 soname bump
The "Rebuild (tesseract)" , pushed opencv-4.1.2-3.fc32 to rawhide which is one soname bump , the build should failed on i686 but don't . I have to review the latest commits ... -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Firewalld Default to nftables
On Sat, Dec 28, 2019 at 8:00 AM Neal Gompa wrote: > > On Mon, Sep 9, 2019 at 3:32 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables > > > > == Summary == > > This change will toggle the default firewalld backend from iptables to > > nftables. All of firewalld's primitives will use nftables while direct > > rules continue to use iptables/ebtables. > > > > == Owner == > > * Name: [[User:erig0| Eric Garver]] > > * Email: egar...@redhat.com > > > > > > == Detailed Description == > > Firewalld upstream has used nftables as the default backend for the > > past two minor releases. It is also the default in other distributions > > (e.g. RHEL-8). This change will bring Fedora in line with upstream. > > > > Using nftables bring many advantages. See firewalld's upstream > > [https://firewalld.org/2018/07/nftables-backend blog post]. It also > > highlights a few behavioral changes. > > > > == Benefit to Fedora == > > * Fewer firewall rules (rule consolidation) > > All of firewalld's primitives will use the same underlying firewall > > (nftables) instead of duplicating rules both in iptables and > > ip6tables. In nftables rules can match both IPv4 and IPv6 packets. > > This reduces the number of firewall rules by half. > > * firewalld's rules are namespaced > > With nftables firewalld's rules are isolated to a "firewalld" table. A > > separate firewall (or user) can create its own independent ruleset and > > firewalld will never touch it. > > * Netfilter upstream is focusing on nftables, not iptables > > > > == Scope == > > * Proposal owners: firewalld (erig0, Eric Garver) > > Currently the firewalld package has a Fedora downstream patch to hide > > the nftables backend. The only firewalld change required is to remove > > that patch from the package and rebuild. > > > > * Other developers: libvirt, podman, docker > > ** libvirt > > *** libvirt already cooperates with the firewalld nftables backend. > > The only thing needed is to test/verify. > > ** podman > > *** libvirt already cooperates with the firewalld nftables backend. > > The only thing needed is to test/verify. > > ** docker > > *** Docker currently does not cooperate with the nftables backend. It > > currently side-steps firewalld by injecting its own rules in iptables > > ahead of firewalld's rules. However, with the nftables backend > > firewalld's rule will still be evaluated. Netfilter in the kernel will > > call iptables, then nftables for the same packet. This means > > firewalld/nftables is likely to drop the packet even if docker has > > iptables rules to ACCEPT. > > *** Proposed fix 1: Docker package should provide a firewalld zone > > definition that includes the docker interfaces (e.g. docker0). The > > zone should use the "ACCEPT" policy (firewalld --set-target). This > > will allow docker's traffic to pass through firewalld/nftables. > > Issue 1: If a user has configured a different docker bridge name, > > then they'll have to manually add the bridge to the docker zone (or > > firewalld's trusted zone). > > *** Proposed fix 2: Just like "Proposed fix 1", but instead of adding > > the zone definition to docker we created a "docker-firewalld" (or > > firewalld-docker?) package that has the zone definition. This could be > > installed by default when docker is installed. > > * Policies and guidelines: No updated needed. > > * Trademark approval: N/A (not needed for this Change) > > > > > > == Upgrade/compatibility impact == > > When users are upgraded to firewalld with nftables enabled (f32) all > > their firewall rules will exist in nftables instead of iptables. All > > of firewalld's primitives (zones, services, ports, rich rules, etc.) > > are 100% compatible between backends. > > > > Users of direct rules may need to consider the > > [https://firewalld.org/2018/07/nftables-backend behavioral changes] > > that were announced upstream. Some are also highlighted here: > > > > * direct rules execute before _all_ firewalld rules > > ** This has been requested by users > > * packets dropped in iptables (or direct rules) will never be seen by > > firewalld > > * packets accepted in iptables (or direct rules) are still subject to > > firewalld's rules > > > > == How To Test == > > Testing should mostly be integration based. Firewalld upstream has a > > fairly comprehensive testsuite that covers functional testing. > > > > The following are packages known to integrate with firewalld. They > > should be tested with the nftables backend. > > > > * libvirt > > ** verify VMs with different network types (bridged, routed) have > > working network access > > ** newer version of libvirt should create and use a "libvirt" > > firewalld zone. Interfaces should be dynamically added to the zone. > > * podman > > ** verify podman adds container bridge interface to the "trusted" zone > > ** verify container still has network access > > * docker > > ** known to not work with the firewalld nftables backend out of
Review swaps
Hello, Can somebody help me with some reviews, the first two being more urgent than others. I can swap with anything in exchange. Happy holidays, Robert-André 1786858[1] _Review Request: golang-rsc-binaryregexp - Go regexp for binary/latin-1 data _ 1786857[2] _Review Request: golang-github-andygrunwald-gerrit - Go(lang) client/library for Gerrit Code Review _ 1786204[3] _Review Request: golang-github-youmark-pkcs8 - Parse and convert private keys in PKCS#8 format _ 1785849[4] _Review Request: rust-rust_hawktracer - Rust bindings for hawktracer profiling library _ 1785851[5] _Review Request: rust-rust_hawktracer_normal_macro - Helper crate for hawktracer profiling library _ 1785852[6] _Review Request: rust-rust_hawktracer_proc_macro - Helper crate for hawktracer profiling library _ 1785853[7] _Review Request: rust-rust_hawktracer_sys - Sys crate for the rust_hawktracer library _ 1785899[8] _Review Request: rust-rav1e - Fastest and safest AV1 encoder _ 1783828[9] _Review Request: rust-zstd-sys - Low-level bindings for the zstd compression library _ 1783848[10] _Review Request: rust-zstd-safe - Safe low-level bindings for the zstd compression library _ 1784162[11] _Review Request: rust-zstd - Binding for the zstd compression library _ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1786858 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1786857 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1786204 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1785849 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1785851 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1785852 [7] https://bugzilla.redhat.com/show_bug.cgi?id=1785853 [8] https://bugzilla.redhat.com/show_bug.cgi?id=1785899 [9] https://bugzilla.redhat.com/show_bug.cgi?id=1783828 [10] https://bugzilla.redhat.com/show_bug.cgi?id=1783848 [11] https://bugzilla.redhat.com/show_bug.cgi?id=1784162 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Firewalld Default to nftables
On Mon, Sep 9, 2019 at 3:32 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables > > == Summary == > This change will toggle the default firewalld backend from iptables to > nftables. All of firewalld's primitives will use nftables while direct > rules continue to use iptables/ebtables. > > == Owner == > * Name: [[User:erig0| Eric Garver]] > * Email: egar...@redhat.com > > > == Detailed Description == > Firewalld upstream has used nftables as the default backend for the > past two minor releases. It is also the default in other distributions > (e.g. RHEL-8). This change will bring Fedora in line with upstream. > > Using nftables bring many advantages. See firewalld's upstream > [https://firewalld.org/2018/07/nftables-backend blog post]. It also > highlights a few behavioral changes. > > == Benefit to Fedora == > * Fewer firewall rules (rule consolidation) > All of firewalld's primitives will use the same underlying firewall > (nftables) instead of duplicating rules both in iptables and > ip6tables. In nftables rules can match both IPv4 and IPv6 packets. > This reduces the number of firewall rules by half. > * firewalld's rules are namespaced > With nftables firewalld's rules are isolated to a "firewalld" table. A > separate firewall (or user) can create its own independent ruleset and > firewalld will never touch it. > * Netfilter upstream is focusing on nftables, not iptables > > == Scope == > * Proposal owners: firewalld (erig0, Eric Garver) > Currently the firewalld package has a Fedora downstream patch to hide > the nftables backend. The only firewalld change required is to remove > that patch from the package and rebuild. > > * Other developers: libvirt, podman, docker > ** libvirt > *** libvirt already cooperates with the firewalld nftables backend. > The only thing needed is to test/verify. > ** podman > *** libvirt already cooperates with the firewalld nftables backend. > The only thing needed is to test/verify. > ** docker > *** Docker currently does not cooperate with the nftables backend. It > currently side-steps firewalld by injecting its own rules in iptables > ahead of firewalld's rules. However, with the nftables backend > firewalld's rule will still be evaluated. Netfilter in the kernel will > call iptables, then nftables for the same packet. This means > firewalld/nftables is likely to drop the packet even if docker has > iptables rules to ACCEPT. > *** Proposed fix 1: Docker package should provide a firewalld zone > definition that includes the docker interfaces (e.g. docker0). The > zone should use the "ACCEPT" policy (firewalld --set-target). This > will allow docker's traffic to pass through firewalld/nftables. > Issue 1: If a user has configured a different docker bridge name, > then they'll have to manually add the bridge to the docker zone (or > firewalld's trusted zone). > *** Proposed fix 2: Just like "Proposed fix 1", but instead of adding > the zone definition to docker we created a "docker-firewalld" (or > firewalld-docker?) package that has the zone definition. This could be > installed by default when docker is installed. > * Policies and guidelines: No updated needed. > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > When users are upgraded to firewalld with nftables enabled (f32) all > their firewall rules will exist in nftables instead of iptables. All > of firewalld's primitives (zones, services, ports, rich rules, etc.) > are 100% compatible between backends. > > Users of direct rules may need to consider the > [https://firewalld.org/2018/07/nftables-backend behavioral changes] > that were announced upstream. Some are also highlighted here: > > * direct rules execute before _all_ firewalld rules > ** This has been requested by users > * packets dropped in iptables (or direct rules) will never be seen by > firewalld > * packets accepted in iptables (or direct rules) are still subject to > firewalld's rules > > == How To Test == > Testing should mostly be integration based. Firewalld upstream has a > fairly comprehensive testsuite that covers functional testing. > > The following are packages known to integrate with firewalld. They > should be tested with the nftables backend. > > * libvirt > ** verify VMs with different network types (bridged, routed) have > working network access > ** newer version of libvirt should create and use a "libvirt" > firewalld zone. Interfaces should be dynamically added to the zone. > * podman > ** verify podman adds container bridge interface to the "trusted" zone > ** verify container still has network access > * docker > ** known to not work with the firewalld nftables backend out of the box > ** verify new package docker-firewalld installs firewalld docker zone > and has "docker0" interface added > ** verify container still has network access > * fail2ban-firewalld > ** verify the direct rules added to firewalld by fail2ban still block traff
Re: help with repackaging pdf-stapler for python3
Sorry, no problem.I was referring to the following: "The egg metadata state that the current version is a 1.0.0 release candidate, so the 0.x versioning is correct." But I guess that it is perhaps fine now. Thanks! On Saturday, December 28, 2019, 9:31:47 AM EST, Alexander Ploumistos wrote: You are welcome. Sorry for the HTML, I am away from home. On Sat, Dec 28, 2019, 15:12 Globe Trotter via devel wrote: Thanks! There was an issue with koji and me. Now the update has been built and submitted for testing. Should I fix the egg issue? How.Thanks! I am not sure there is an "egg issue", but that's something you should check with our python gurus. I remember that there is a section on packaging egg stuff in our Packaging guidelines, you can search for that page and see if you're adhering to it. Best regards,Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: help with repackaging pdf-stapler for python3
You are welcome. Sorry for the HTML, I am away from home. On Sat, Dec 28, 2019, 15:12 Globe Trotter via devel < devel@lists.fedoraproject.org> wrote: > Thanks! There was an issue with koji and me. Now the update has been built > and submitted for testing. Should I fix the egg issue? How. > Thanks! > I am not sure there is an "egg issue", but that's something you should check with our python gurus. I remember that there is a section on packaging egg stuff in our Packaging guidelines, you can search for that page and see if you're adhering to it. Best regards, Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: help with repackaging pdf-stapler for python3
Thanks! There was an issue with koji and me. Now the update has been built and submitted for testing. Should I fix the egg issue? How.Thanks! On Saturday, December 28, 2019, 3:34:30 AM EST, Alexander Ploumistos wrote: On Sat, Dec 28, 2019 at 7:35 AM Globe Trotter via devel wrote: > Any further suggestion/help? Here is the updated spec file: > > $ fpaste pdf-stapler.spec > Uploading (5.0KiB)... > https://paste.centos.org/view/3a4fe4d6 > Oh, there's also a problem with your changelog entries, the last three have 1.0.0-1 as the version. Since there hasn't been a successful koji build yet, change them to 1.0.0-0.2.20191215git8753251 1.0.0-0.1.20191215git8753251 etc. The egg metadata state that the current version is a 1.0.0 release candidate, so the 0.x versioning is correct. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Issue with sysusage build and bodhi
On Sat, Dec 28, 2019 at 4:27 AM Frank Crawford wrote: > > Folks, > > I did a new build to add sysusage to EPEL8 the other day, and pushed it to > bodhi, and today received the following message: > > bodhi - 2019-12-27 20:13:12.706366 (karma: 0) > FEDORA-EPEL-2019-e249fc2a74 ejected from the push because "Cannot find > relevant tag for sysusage-5.7-6.el8. None of ['epel8-testing', > 'epel8-testing-pending'] are in ['dist-6E-epel-testing-candidate', > 'epel7-testing-candidate', 'dist-5E-epel-testing-candidate', > 'f27-modular-updates-candidate', 'f30-modular-updates-candidate', > 'f30-container-updates-candidate', 'f30-flatpak-updates-candidate', > 'f28-modular-updates-candidate', 'f28-container-updates-candidate', > 'epel8-testing-candidate', 'f31-modular-updates-candidate', > 'f32-container-updates-candidate', 'f31-container-updates-candidate', > 'f31-flatpak-updates-candidate', 'f29-modular-updates-candidate', > 'f29-container-updates-candidate', 'f29-flatpak-updates-candidate', > 'f22-updates-candidate', 'f21-updates-candidate', 'f25-updates-candidate', > 'f24-updates-candidate', 'f23-updates-candidate', 'f26-updates-candidate', > 'f27-updates-candidate', 'f30-updates-candidate', 'f28-updates-candidate', > 'f31-updates-candidate', 'f32-updates-candidate', 'f29-updates-candidate', > 'el8-modular-updates-candidate']." > > What do I have to do to fix it, or where can I file a ticket to get it looked > at? This issue is already tracked: https://pagure.io/fedora-infrastructure/issue/8477 The fedora infra heroes have been looking into it since christmas, but AFAIK, the root cause of the problem has not been identified yet. Fabio > Thanks > Frank > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: help with repackaging pdf-stapler for python3
On Sat, Dec 28, 2019 at 7:35 AM Globe Trotter via devel wrote: > Any further suggestion/help? Here is the updated spec file: > > $ fpaste pdf-stapler.spec > Uploading (5.0KiB)... > https://paste.centos.org/view/3a4fe4d6 > Oh, there's also a problem with your changelog entries, the last three have 1.0.0-1 as the version. Since there hasn't been a successful koji build yet, change them to 1.0.0-0.2.20191215git8753251 1.0.0-0.1.20191215git8753251 etc. The egg metadata state that the current version is a 1.0.0 release candidate, so the 0.x versioning is correct. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: help with repackaging pdf-stapler for python3
On Sat, Dec 28, 2019 at 7:35 AM Globe Trotter via devel wrote: > > Thanks! This seems to compile again, but I can't tell what happened with koji: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=39956986 Besides koji misbehaving in general in the last few days, you have uploaded an older source rpm (or you gave the link to the wrong koji task). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
