devel November 2019

devel@lists.fedoraproject.org

226 participants
291 discussions

Schedule for Thursday's FPC Meeting (2019-08-15 16:00 UTC)
by James Antill 09 Apr '20

09 Apr '20

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-08-15 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2019-08-15 09:00 PDT US/Pacific 2019-08-15 12:00 EDT --> US/Eastern <-- 2019-08-15 16:00 UTC UTC 2019-08-15 17:00 BST Europe/London 2019-08-15 18:00 CEST Europe/Berlin 2019-08-15 18:00 CEST Europe/Paris 2019-08-15 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2019-08-16 00:00 HKT Asia/Hong_Kong 2019-08-16 00:00 +08 Asia/Singapore 2019-08-16 01:00 JST Asia/Tokyo 2019-08-16 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #902 Cleanup & enhance spec files .fpc 902 https://pagure.io/packaging-committee/issue/902 #topic #904 Caret versioning .fpc 904 https://pagure.io/packaging-committee/issue/904 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #914 Automatic R runtime dependencies .fpc 914 https://pagure.io/packaging-committee/issue/914 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

2 1

Orphaning owncloud and nextcloud
by James Hogarth 03 Apr '20

03 Apr '20

Hi all, It's become clear that I haven't had the time I thought I'd have this past year due to $life ... These are in a bit of a broken state and right now I'd advise people that need them to use upstream packages/containers. I don't foresee sufficient time coming in the near future with family needs in advance of hobbies like Fedora of course. I'll give it a week or so for anyone to contact me who wants to pick them up, otherwise I'll update pagure to assign them to "orphan" James

6 17

Release rpkg-1.58 fedpkg-1.37
by Ondrej Nosek 17 Mar '20

17 Mar '20

Hi all, a new version rpkg-1.58 and fedpkg-1.37 is released. Currently, Fedora 30 packages are in the stable repository, feel free to try other waiting distributions in Bodhi. Numerous features and improvements (as well as bugfixes) includes: (For "rpkg") - Improvements for scratch module builds - Allow passing arguments to “mbs-manager build_module_locally” - Remove the ability to parse a module’s branch - Permit setting arbitrary rpm macros during build - Ignore specific files in a cloned repository - Pass specific arguments to “mock” - Added “depth” argument to "git clone" - Watch multiple module builds - Show module build links in output from command module-build - Add the ability to configure multiple regex expressions - Add “retire” command supporting both packages and modules - Import srpm without uploading sources - Ignore any specified profile when finding the Flatpak build target - Added update-docs script - And other fixes and small improvements (For "fedpkg") - Ignore files in a cloned repository - Enable shell completion for module scratch builds - Show hint when Pagure token expires - Include possible distprefix in “–define dist” for Forge-based packages - Other small fixes More specific changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.58.html https://docs.pagure.org/fedpkg/releases/1.37.html Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.58-1.el6&builds=rpkg… Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 rpkg is available from PyPI. Thanks to all contributors. Regards

2 2

Fonts packaging policy rewrite proposal
by Nicolas Mailhot 14 Mar '20

14 Mar '20

Hi, A fonts packaging policy rewrite proposal has been pushed to FPC today: https://pagure.io/packaging-committee/pull-request/934 It should be clearer, more opinionated, and take into account: – updates of The OpenType standard – variable fonts – web fonts – upstream depreciation of non OpenType formats: final stages of the Harfbuzz consolidation decided at the 2006 Text Layout summit https://www.freedesktop.org/wiki/TextLayout/ – appstream & fonts – weak dependencies – and probably more I forget here It is based on the new fonts-rpm-macros project for automation: This project builds on tooling enhancements in redhat-rpm-config and rpm itself, done during the past two years for the Forge and Go sets of packaging macros. It started 2 years ago as a fork of fontpackages, which is the core of our current fonts packaging guidelines. It will require putting the fonts-srpm-macros package in the default build root, like is done for other domain-specific packaging macro sets. Major additions: – better documentation (clearer and more complete) – better automation (less packager hassle for better and more complete results) Major removals: – tools and scripts – fixing metadata with ttname Mostly because no one seems willing to maintain those scripts, or port ttname to python 3. https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/ showcases the new policy on 62 real-world source packages, generating 139 installation packages. Some of those are badly delayed updates to Fedora packages, others are brand-new packages ready for Fedora inclusion. They include major font packages such as Stix, DejaVu, Droid, IBM Plex. Existing Fedora packages will continue to build, the old fontpackages macros are grandfathered in fonts-rpm-macros for now. They will be removed in a few years to give packagers time to apply the new guidelines. Regards, -- Nicolas Mailhot

2 6

fedora-gpg-keys not updated yet again
by Zbigniew Jędrzejewski-Szmek 19 Feb '20

19 Feb '20

This seems to repeat every 6 months: rawhide mock is broken on stable Fedora, people are scrambling to install the right gpg keys, dnf reports unsigned packages. Looking at https://bodhi.fedoraproject.org/updates/?packages=fedora-repos, there is still no F30 package with the right keys. Can we *please* send out the FN+1 and FN+2 keys a month before branching, to *all* releases of Fedora, so we can avoid this pointless scramble? Zbyszek

14 27

Please, IMHO, resolve in some way the Samba MIT kerberos problem.
by Dario Lesca 12 Feb '20

12 Feb '20

Too many people (like also me) try to use samba-dc on fedora for deploy a production AD DC controller, without know that MIT kerberos is experimental and some useful things cannot work (es. win to win access). An recent last example: https://lists.samba.org/archive/samba/2019-November/226845.html > On 01/11/2019 22:23, Vex Mage wrote: > > The script is expecting dpkg however this is a Red Hat > > derived distro (Fedora Server.) > > Where did you get the Samba packages from ? > > If they are the default OS packages, then you should stop using > them, they use MIT kerberos and are experimental. There is many approach for resolve this issue: a) Stop use MIT kerberos and rebuild samba with Heimdal Kerberos. b) Produce a samba alternative package version (like, for example, firefox-x11) build it with Heimdal Kerberos (es samba-hk-*) c) Stop enable DC on Fedora, like RH/Centos do. d) Notify users at the end of the installation that Fedora Samba DC is experimental. e) Solve the problems that make MIT kerberos experimental and put us in a position to ask for help on the samba team. f) ... some other proposal ? What is the best approach chosen by Fedora ? Many thanks -- Dario Lesca (inviato dal mio Linux Fedora 31 Workstation)

10 22

Re: [ovirt-users] [feedback needed] VirtIO Windows Drivers - new installer
by Sandro Bonazzola 04 Feb '20

04 Feb '20

Il giorno gio 24 ott 2019 alle ore 19:28 Strahil <hunter86_bg(a)yahoo.com> ha scritto: > Hi Sandro,All, > > Can I upgrade the tools on existing VM , or it requires a fresh one? Best > Regards > If you have oVirt windows guest tools already installed suggestion is to uninstall it before installing this new installer. > Best Regards, > Strahil Nikolov > On Oct 24, 2019 14:35, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote: > > Hi, > as part of the work on oVirt 4.4, the team rewrote the VirtiIO Windows > Drivers installer using the open source framework WiX. > Thanks to the virtio-win maintainer, the new installer is not shipped > anymore within oVirt Guest Tools ISO: it's shipped now directly into VirtIO > Windows ISO[1] > > Please give it a run on your testing environment / testing VMs and let us > know about your experience at devel(a)ovirt.org. > Thanks, > > > [1] > https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-vi… > > -- > > Sandro Bonazzola > > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > > Red Hat EMEA <https://www.redhat.com/> > > sbonazzo(a)redhat.com > <https://www.redhat.com/>*Red Hat respects your work life balance. > Therefore there is no need to answer this email out of your office hours.* > > -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. <https://mojo.redhat.com/docs/DOC-1199578>*

2 1

This update's test gating status has been changed to, 'greenwave_failed'.
by Miro Hrončok 13 Jan '20

13 Jan '20

Couple of my updates have e-mailed me $subj. Is it something to worry about? Example: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f2ffe568a1 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

6 7

Fedora 32 System-Wide Change proposal: Firewalld Default to nftables
by Ben Cotton 06 Jan '20

06 Jan '20

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: egarver(a)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 traffic == User Experience == In general users shouldn't notice the change. Occasional a user will look at the iptables rule that firewalld generates. They'll now have to look at nftables instead. == Dependencies == * libvirt >= 5.1.0 * CNI >= 0.8.0 (used by podman) * docker-firewalld (new package) == Contingency Plan == * Contingency mechanism: firewalld maintainer (erig0) will reinstate the current patch to default to the iptables backend. * Contingency deadline: beta freeze == Documentation == * [https://firewalld.org/2018/07/nftables-backend Firewalld blog post] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

5 5

Orphaning pykka
by Jonathan Dieter 05 Jan '20

05 Jan '20

I've just orphaned pykka (https://admin.fedoraproject.org/pkgdb/package /rpms/pykka/) as I'm no longer using it. Jonathan

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2019