Announcing new anitya integration and de-orphaning process
by Pierre-Yves Chibon
Good Morning Everyone,
Tomorrow we are planning on deploying a new version of pagure and
pagure-dist-git on production.
These changes come with two changes to the packager workflow:
* Anitya integration in dist-git
Something we lost when loosing pkgdb was the easy integration to anitya
(https://release-monitoring.org). With the coming changes we are getting them
back.
On the left hand-side column, there will be a drop-down button allowing to
change the settings for anitya for the project.
Existing status will be migrated from the fedora-scm-requests repo on pagure to
use this drop-down.
Using the fedora-scm-requests repo for the anitya integration will no longer be
supported.
* Change in the de-orphaning process
Currently if a package is orphaned, one has to open a ticket against the releng
project to adopt it. With these changes, anyone will be able to adopt orphaned
projects (not retired on master) directly from dist-git's UI.
If the project is retired or has been orphaned for too long, a ticket on the
releng project will still be required though.
Both of these changes can already be reviewed in staging at:
https://src.stg.fedoraproject.org
Looking forward for your feedback!
Pierre
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)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-announce@lists.fedora...
3 years, 5 months
Orphaning owncloud and nextcloud
by James Hogarth
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
3 years, 5 months
Release rpkg-1.58 fedpkg-1.37
by Ondrej Nosek
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=rp...
Alternative link:
https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1
rpkg is available from PyPI.
Thanks to all contributors.
Regards
3 years, 6 months
Fonts packaging policy rewrite proposal
by Nicolas Mailhot
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
3 years, 6 months
fedora-gpg-keys not updated yet again
by Zbigniew Jędrzejewski-Szmek
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
3 years, 7 months
Please, IMHO, resolve in some way the Samba MIT kerberos problem.
by Dario Lesca
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)
3 years, 7 months
Re: [ovirt-users] [feedback needed] VirtIO Windows Drivers - new installer
by Sandro Bonazzola
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-...
>
> --
>
> 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>*
3 years, 7 months
Fedora 32 System-Wide Change proposal: Firewalld Default to nftables
by Ben Cotton
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
3 years, 8 months
