Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Tuesday, February 22, 2022 10:50:06 PM CET Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> 
> > Yes. But how many domains using idn are there? I worked on idn support
> > in systemd, but when preparing the description of this change I realized
> > that I have _never_ once used an idn domain outside of testing.
> > 
> > And note that this is not about user-facing programs like firefox.
> > I assume that there might be _some_ use of idn in firefox. But for
> > command-line tools like curl this seems even less likely.
> 
> 
> I'm pretty sure use of IDN domains is a regional thing.  I live in the
> US and don't see IDN domains in my normal use.  But dropping support for
> them from a core utility would be bad for those that live in regions
> where IDN domains may be more common.
> 
> -- 
> Chris Adams 

If this appears to be a real problem, it is easy for us to re-enable IDN
in libcurl-minimal, even in an update of a stable Fedora release.  So I do
not think we need to enable it proactively.

Kamil

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Tuesday, February 22, 2022 9:45:30 PM CET Peter Robinson wrote:
> On Tue, Feb 22, 2022 at 5:00 PM Ben Cotton  wrote:
> 
> >
> >
> > https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default
> >
> >
> >
> > == Summary ==
> > `libcurl-minimal` and `curl-minimal` will be installed by default
> > instead of `libcurl` and `curl`.
> > The "minimal" variants provide only a subset of protocols (HTTP, HTTPS,
> > FTP).
> 
> Does it make sense to keep FTP with most browsers obsoleting the
> protocol due to lack of security?

Not yet, in my opinion.  But it is a controversial topic, as you can see
in the preceding discussion on this mailing list.  Of course, each application 
that does not need FTP, can disable the protocol at run-time.  But disabling 
it globally on default installations of Fedora would make this change too 
controversial.  We can reconsider it later in case the initial change is well 
accepted.

Kamil

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Tuesday, February 22, 2022 10:47:40 PM CET Chris Adams wrote:
> Once upon a time, Demi Marie Obenour  said:
> 
> > As mentioned above, the purpose of this change is to ensure that
> > vulnerabilities in obscure protocols impact a smaller fraction of
> > users.  Right now, a vulnerability in an obscure protocol impacts
> > most users.  With this change, it will only impact users that have
> > installed the full version of curl.  This is independent of whether a
> > given protocol should be disabled outright.
> 
> 
> I just feel that if there's enough security concern with some of the
> code, then Fedora shouldn't ship that code.  Either the code is secure
> enough and maintained well enough to ship, or it's not.

With your line of reasoning, one could also disable all the hardening etc.
Software security is not a black and white problem and terms like "secure 
enough" do not work in practice.  Security policies rather work with terms 
like probability and impact.  The lower those values are the better.

Kamil

> Otherwise, don't list this as a justification for the change proposal.
> 
> -- 
> Chris Adams 

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Self Introduction: Yunmei Li

[Yunmei LI]

Hi, Thanks for your help! I reworked the Milvus package for EPEL8 based on the 
comments I received, and updated the Spec URL and SRPM URL on Bugzilla: 
https://bugzilla.redhat.com/show_bug.cgi?id=20555___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Chris Murphy]

On Tue, Feb 22, 2022 at 3:19 PM Lennart Poettering  wrote:
>
> On Di, 22.02.22 14:36, Chris Murphy (li...@colorremedies.com) wrote:
>
> > On Tue, Feb 22, 2022 at 12:34 PM Gary Buhrmaster
> >  wrote:
> > >
> > > Perhaps there are additional hints in:
> > >
> > >systemctl show -p WantedBy,RequiredBy,After,Before 
> > > network-online.target
> > >
> > > I also suspect i don't understand the
> > > problem well enough to have the correct
> > > clue to help.
> >
> >
> > # systemctl show -p WantedBy,RequiredBy,After,Before 
> > network-online.target
> > RequiredBy=
> > WantedBy=packagekit.service dnf-makecache.timer
> > Before=shutdown.target iscsid.service kdump.service
> > dnf-makecache.service iscsi.service
>
> Are any of iscsid.service, iscsi.service, kdump.service actually
> running for you? or enabled?

None of those are running, all of them are enabled and have vendor
preset enabled as well.

kdump is coming from kexec-tools, which is installed due to anaconda
and abrt (looks like).

And the iscsi stuff is coming from iscsi-initiator-utils, which is
installed due to anaconda and gnome-boxes (looks like).



> Most importantly though, let's take one step back: the dnf thing will
> pull the service in, as mentioned, but not delay reaching of
> multi-user.target or graphical.target. So, what are you actually
> seeing?

Longer time to get to the login window. If 'rhgb quiet' are removed, I
see the red cylon eye at NetworkManager-wait-online.service for maybe
3-10 seconds depending on whether I'm booting Fedora 35 or 36 (36 has
a ton of debug stuff enabled on my setup, so everything is slower).

systemd-analyze states double the time to get to graphical.target when
NetworkManager-wait-online.service is enabled.


>Will these two targets only be reached after NM-w-o.s is
> reached? Or are they reached before it?

I see iscsi related stuff before and after NM-w-o.s;  and kdump things
running before NM-w-o.s

journalctl -b | grep 'iscsi\|NetworkManager-wait-online\|kdump'
https://drive.google.com/file/d/1QhSs3v3dkQRG6hzKKyI1KGlc_La3afr4/view?usp=sharing


-- 
Chris Murphy
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-36-20220222.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 16/229 (x86_64), 21/161 (aarch64)

New failures (same test not failed in Fedora-36-20220221.n.0):

ID: 1142114 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1142114
ID: 1142168 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1142168
ID: 1142176 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1142176
ID: 1142187 Test: aarch64 Server-dvd-iso 
install_repository_nfsiso_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1142187
ID: 1142256 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1142256
ID: 1142298 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1142298
ID: 1142308 Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/1142308
ID: 1142310 Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/1142310
ID: 1142327 Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1142327
ID: 1142373 Test: aarch64 universal upgrade_2_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1142373
ID: 1142593 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1142593

Old failures (same test failed in Fedora-36-20220221.n.0):

ID: 1142108 Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/1142108
ID: 1142113 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1142113
ID: 1142146 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1142146
ID: 1142147 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/1142147
ID: 1142210 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1142210
ID: 1142229 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1142229
ID: 1142230 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1142230
ID: 1142234 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1142234
ID: 1142236 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/1142236
ID: 1142237 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1142237
ID: 1142264 Test: x86_64 Workstation-upgrade desktop_background
URL: https://openqa.fedoraproject.org/tests/1142264
ID: 1142277 Test: aarch64 Workstation-upgrade desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/1142277
ID: 1142280 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1142280
ID: 1142281 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1142281
ID: 1142288 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1142288
ID: 1142289 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1142289
ID: 1142321 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1142321
ID: 1142389 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1142389
ID: 1142406 Test: aarch64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/1142406
ID: 1142417 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1142417
ID: 1142418 Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1142418
ID: 1142427 Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1142427
ID: 1142436 Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/1142436
ID: 1142437 Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1142437
ID: 1142455 Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1142455
ID: 1142595 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1142595

Soft failed openQA tests: 13/229 (x86_64), 12/161 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-36-20220221.n.0):

ID: 1142107 Test: x86_64 

Fedora-IoT-36-20220222.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/16 (x86_64), 2/15 (aarch64)

New failures (same test not failed in Fedora-IoT-36-20220220.0):

ID: 1142600 Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/1142600

Old failures (same test failed in Fedora-IoT-36-20220220.0):

ID: 1142612 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1142612
ID: 1142621 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/1142621

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-IoT-36-20220220.0):

ID: 1142596 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1142596

Passed openQA tests: 14/16 (x86_64), 13/15 (aarch64)

New passes (same test not passed in Fedora-IoT-36-20220220.0):

ID: 1142597 Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1142597
ID: 1142598 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1142598
ID: 1142599 Test: x86_64 IoT-dvd_ostree-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/1142599
ID: 1142601 Test: x86_64 IoT-dvd_ostree-iso base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/1142601
ID: 1142602 Test: x86_64 IoT-dvd_ostree-iso iot_greenboot
URL: https://openqa.fedoraproject.org/tests/1142602
ID: 1142603 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay
URL: https://openqa.fedoraproject.org/tests/1142603
ID: 1142604 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_rebase
URL: https://openqa.fedoraproject.org/tests/1142604
ID: 1142605 Test: x86_64 IoT-dvd_ostree-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/1142605
ID: 1142606 Test: x86_64 IoT-dvd_ostree-iso podman
URL: https://openqa.fedoraproject.org/tests/1142606
ID: 1142607 Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/1142607
ID: 1142608 Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/1142608
ID: 1142609 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/1142609
ID: 1142610 Test: x86_64 IoT-dvd_ostree-iso podman_client
URL: https://openqa.fedoraproject.org/tests/1142610
ID: 1142611 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/1142611
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Rpm: provide a static library in package

[Kevin Kofler via devel]

Denis Fateyev wrote:
> Unfortunately, the shared library support is explicitly removed by the
> upstream:
> https://github.com/msharov/ustl/issues/100#issuecomment-1040553883
> 
https://github.com/msharov/ustl/commit/7366ab143d9bd0f48c59931c0c58529eb5179c27

This is just lame. I do not understand the explanation at all, since I do 
not see any scenario in which the static library makes things easier for the 
consumer of the library. I have added a commit comment saying so.

And the fact that the library building code is handwritten is a WTF by 
itself. With any reasonable build system, changing a library from static to 
shared is at most a one-line change. But upstream's build system is not 
reasonable.

> As an alternative, I can orphan the "ustl" package in rawhide — I haven't
> checked yet, but suspect that it's not used by other packages nowadays.

Well, if that is the case, considering that upstream themselves consider the 
library obsolete, I guess it is fine to orphan it and let it be retired 
eventually.

Kevin Kofler
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Rpm: provide a static library in package

[Denis Fateyev]

On Wed, Feb 23, 2022 at 6:47 AM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Denis Fateyev wrote:
> > The "ustl" upstream, for which I maintain the RPM package, has recently
> > switched from providing a shared library to a static library.
>
> Generally, you do not want to follow such a change, but force the build
> system to build a shared library instead, even if it is not the upstream
> default.
>

Unfortunately, the shared library support is explicitly removed by the
upstream:
https://github.com/msharov/ustl/issues/100#issuecomment-1040553883
https://github.com/msharov/ustl/commit/7366ab143d9bd0f48c59931c0c58529eb5179c27

I believe it's not worth to work around this behavior additionally.

As an alternative, I can orphan the "ustl" package in rawhide — I haven't
checked yet, but suspect that it's not used by other packages nowadays.

-- 
wbr, Denis.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Rpm: provide a static library in package

[Kevin Kofler via devel]

Denis Fateyev wrote:
> The "ustl" upstream, for which I maintain the RPM package, has recently
> switched from providing a shared library to a static library.

Generally, you do not want to follow such a change, but force the build 
system to build a shared library instead, even if it is not the upstream 
default.

Kevin Kofler
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 36 compose report: 20220222.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-36-20220221.n.0
NEW: Fedora-36-20220222.n.1

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  4
Dropped packages:45
Upgraded packages:   193
Downgraded packages: 0

Size of added packages:  346.82 KiB
Size of dropped packages:55.46 MiB
Size of upgraded packages:   3.03 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -25.63 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-gokyle-twofactor-1.1-1.fc36
Summary: Two-factor authentication
RPMs:golang-github-gokyle-twofactor-devel
Size:16.91 KiB

Package: golang-github-jsimonetti-pwscheme-0-1.20220221git4d9895f.fc36
Summary: Golang packages defining different password schemes
RPMs:golang-github-jsimonetti-pwscheme-devel
Size:14.65 KiB

Package: ibus-engine-gui-ci-1.0.0.20220118-1.fc36
Summary: GUI CI for IBus engines
RPMs:ibus-engine-gui-ci
Size:279.85 KiB

Package: python-specfile-0.1.1-1.fc36
Summary: A library for parsing and manipulating RPM spec files
RPMs:python3-specfile
Size:35.41 KiB


= DROPPED PACKAGES =
Package: erlang-riak_control-2.1.7-10.fc35
Summary: Admin UI for Riak
RPMs:erlang-riak_control
Size:1.12 MiB

Package: javadocofflinesearch-2.2-15.fc35
Summary: Tool for offline searching in your docs via browser
RPMs:javadocofflinesearch javadocofflinesearch-javadoc
Size:407.69 KiB

Package: laby-0.6.4-28.20200413git27ecf89.fc36
Summary: Learn programming, playing with ants and spider webs
RPMs:laby
Size:7.28 MiB

Package: libyui-bindings-2.0.2-8.fc36
Summary: Language bindings for libyui
RPMs:mono-yui perl-yui python3-yui ruby-yui
Size:6.32 MiB

Package: libyui-ncurses-2.55.0-6.fc36
Summary: Character Based User Interface for libyui
RPMs:libyui-ncurses libyui-ncurses-devel libyui-ncurses-doc
Size:7.30 MiB

Package: libyui-qt-2.53.0-3.fc35
Summary: Qt User Interface for libyui
RPMs:libyui-qt libyui-qt-devel libyui-qt-doc
Size:6.36 MiB

Package: libyui-qt-graph-2.45.5-4.fc36
Summary: Qt Graph Widget for libyui
RPMs:libyui-qt-graph libyui-qt-graph-devel libyui-qt-graph-doc
Size:650.78 KiB

Package: mpir-3.0.0-29.fc36
Summary: Highly optimised library for bignum arithmetic
RPMs:mpir mpir-c++ mpir-devel mpir-doc
Size:9.01 MiB

Package: perl-MouseX-App-Cmd-0.30-20.fc34
Summary: Mashes up MouseX::Getopt and App::Cmd
RPMs:perl-MouseX-App-Cmd
Size:25.44 KiB

Package: php-pecl-solr2-2.5.1-4.fc35
Summary: Object oriented API to Apache Solr
RPMs:php-pecl-solr2
Size:849.10 KiB

Package: python-angr-9.0.9572-4.fc36
Summary: Multi-architecture binary analysis toolkit
RPMs:python3-angr
Size:8.07 MiB

Package: python-concurrentloghandler-0.9.1-20.fc35
Summary: Concurrent logging handler (drop-in replacement for 
RotatingFileHandler)
RPMs:python3-concurrentloghandler
Size:24.71 KiB

Package: python-discord-1.7.3-2.fc36
Summary: Python wrapper for the Discord API
RPMs:python3-discord
Size:811.06 KiB

Package: python-luftdaten-0.6.5-2.fc36
Summary: Python API wrapper for interacting with luftdaten.info
RPMs:python3-luftdaten
Size:16.10 KiB

Package: python-netssh2-0.1.7-12.fc35
Summary: Library for communicating with network devices using ssh2-python
RPMs:python-netssh2-doc python3-netssh2
Size:66.31 KiB

Package: python-sphinx-testing-1.0.1-13.fc36
Summary: Testing utility classes and functions for Sphinx extensions
RPMs:python3-sphinx-testing
Size:26.04 KiB

Package: python-wand-0.5.5-10.fc36
Summary: Ctypes-based simple MagickWand API binding for Python
RPMs:python3-wand
Size:182.66 KiB

Package: rust-bytes0.6-0.6.0-4.fc36
Summary: Types and traits for working with bytes
RPMs:rust-bytes0.6+default-devel rust-bytes0.6+serde-devel 
rust-bytes0.6+std-devel rust-bytes0.6-devel
Size:75.19 KiB

Package: rust-crc1-1.8.1-2.fc36
Summary: Rust implementation of CRC(16, 32, 64) with support of various 
standards
RPMs:rust-crc1+default-devel rust-crc1+std-devel rust-crc1-devel
Size:32.81 KiB

Package: rust-crypto-mac0.8-0.8.0-4.fc36
Summary: Trait for Message Authentication Code (MAC) algorithms
RPMs:rust-crypto-mac0.8+blobby-devel rust-crypto-mac0.8+default-devel 
rust-crypto-mac0.8+dev-devel rust-crypto-mac0.8+std-devel 
rust-crypto-mac0.8-devel
Size:48.51 KiB

Package: rust-javascriptcore-rs-0.15.2-2.fc36
Summary: Rust bindings for the javacriptcore library
RPMs:rust-javascriptcore-rs+default-devel rust-javascriptcore-rs+dox-devel 
rust-javascriptcore-rs+v2_28-devel rust-javascriptcore-rs-devel
Size:45.54 KiB

Package: rust-javascriptcore-rs-sys-0.3.3-3.fc36
Summary: Sys functions for the Rust bindings of the javacriptcore library
RPMs:rust-javascriptcore-rs-sys+default-devel 
rust-javascriptcore-rs-sys+dox-devel rust-javascriptcore-rs-sys+v2_28-devel 
rust-javascriptcore-rs-sys

Re: Looking for %{forgemeta} GitHub example

[PGNet Dev]

Aside from the other follow-ups about whether or not to use them...
here's an example of a SPEC I wrote for a proposed package:


not all are concerned with building according to Fedora Packaging standards, 
for proposal in inclusion

some of us use forgemeta because it provides capability that allows us to build 
what/when we require

with capabilities approaching Opensuse's OBS. in any case, more flexible than 
not.

particularly the nice git branch support; incredibly useful, imo.

here's one of mine:

  https://pagure.io/pgnd/nginx-mainline/blob/main/f/nginx/nginx.spec

used for my regular COPR builds.

it would be ... unfortunate ... if forgemeta were to vanish.

my $0.02
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Fedora 36 Branched 20220222.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 36 Branched 20220222.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20220218.n.0: anaconda-36.16.1-1.fc36.src, 20220222.n.1: 
anaconda-36.16.2-1.fc36.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/36

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220222.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220222.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220222.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220222.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220222.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220222.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220222.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing account takeovers through expired domains

[Gary Buhrmaster]

On Mon, Feb 21, 2022 at 7:17 PM Vitaly Zaitsev via devel
 wrote:

> OTP is absolutely free. FIDO2 requires the purchase of a special
> hardware token.

Not necessarily.  Not only can some mobile devices
present the needed credentials (as if they were an
external hardware token), but as I recall U2F specifies
a TPM(2?) chip as a possible secure processor.
While I don't remember where, I think I did once see
a reference to where someone had created a TPM
based FIDO implementation.

But I agree there are some known problems in
obtaining a $10(US) FIDO2 token.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing account takeovers through expired domains

[Gary Buhrmaster]

On Tue, Feb 22, 2022 at 9:54 PM Kevin Fenzi  wrote:

> I don't think there's any way in IPA to require otp as a requirement for
> group membership currently. (Please let me know if there is).
> Which would leave us checking after the fact and removing people without
> one set, which is a big pile of hassle. :(

Well, should such a policy be enacted, there is the
one time check for existing packagers, and then
just one more step to check box to check for those
that are requesting to be added to the packager
group.

Not ideal, but I would expect doable (unless there
is a lot more churn in the packager group than I
am aware of).

> Enforcing otp per group also would require dev work from what I
> understand. :(

Probably.  Although the requirement to enforce
the most restrictive requirement(s) on a user
that any group requires that the user is a member
of is something that is certainly desirable of better
implementations (and if a group later is changed
to have higher requirements, users that do not
conform would need to be addressed (removal
from group entirely, not getting the group
authorizations, something).
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Lennart Poettering]

On Di, 22.02.22 14:36, Chris Murphy (li...@colorremedies.com) wrote:

> On Tue, Feb 22, 2022 at 12:34 PM Gary Buhrmaster
>  wrote:
> >
> > Perhaps there are additional hints in:
> >
> >systemctl show -p WantedBy,RequiredBy,After,Before network-online.target
> >
> > I also suspect i don't understand the
> > problem well enough to have the correct
> > clue to help.
>
>
> # systemctl show -p WantedBy,RequiredBy,After,Before network-online.target
> RequiredBy=
> WantedBy=packagekit.service dnf-makecache.timer
> Before=shutdown.target iscsid.service kdump.service
> dnf-makecache.service iscsi.service

Are any of iscsid.service, iscsi.service, kdump.service actually
running for you? or enabled?

Most importantly though, let's take one step back: the dnf thing will
pull the service in, as mentioned, but not delay reaching of
multi-user.target or graphical.target. So, what are you actually
seeing? Will these two targets only be reached after NM-w-o.s is
reached? Or are they reached before it?

If the latter is the case, there actually is no problem, because yes,
NM-w-o.s will still run for a while after the relevant parts of the
boot completed, but it will not cause delays for anything that
matters, it just helps making dnf cache sync output a bit less noisy,
that's all. Or in other words: we consider the boot complete once
multi-user.target/graphical.target have been reached. Stuff that runs
after that is stuff we don't consider boot-up stuff anymore, but just
background stuff that runs after the actual boot phase is complete.

Lennart

--
Lennart Poettering, Berlin
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Lennart Poettering]

On Di, 22.02.22 10:32, Chris Murphy (li...@colorremedies.com) wrote:

> > Normally, unlikely client software, server software should really
> > watch rtnl or so and follow local network configuration to make its
> > services available, and thus it doesn't have to wait for the online
> > sync point...
>
> OK so PackageKit, dnf, and nfs-utils.
>
> In a default clean install, nfs-convert.service is enabled, but vendor
> preset is disabled. I do not know why. When I use "systemctl
> preset-all" it's not enabled. And I'm not finding any candidates in
> /etc for a local change.

We probably should have some form of release criterium that mandates
that on a default install (i.e. one where /etc/fstab has not been
added to include SMB/NFS mounts of so) it is not acceptable that
NM-w-o.s/network-online.target is pulled into the initial transaction
while being transitively ordered before multi-user.target or
graphical.target.

Because that's the issue as Zbigniew mentioned: not so much that
network-online.target is pulled in, but that it is pulled in *and*
something that actually delays the boot — i.e. that delays
multiuser.target or graphical.target being reached — is ordered after
it. Because that means multi-user.target/graphical.target cannot be
reached without the network-online.target also being reached.

By that standard dnf's use of network-online.target is not an issue,
as while dnf-makecache.service is ordered after it transitively, that
service is not ordered before multi-user.target/graphical.target, and
hence does *not* transitively delay m-u.t/g.t to be reached.

(And while we are at it, anything that pulls in and puts
systemd-udev-settle.service should similarly be prohibited).

Lennart

--
Lennart Poettering, Berlin
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Lennart Poettering]

On Di, 22.02.22 18:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> Clarification: it *is* a bug *if* the unit that is ordered after it is
> ordered before the default boot target. So e.g. something that is started
> at boot but does not delay the default boot target is not a problem.

Indeed.

> > > The DNF thing looks like an obvious bug to me. DNF's cache logic
> > > really shouldn't add an expensive sync point to the boot like
> > > this. Someone should file a bug to ask them to remove that.
>
> No, no. dnf-makecache.timer is "asynchronous" — it is not part of
> multi-user.target. It is reasonable to order it after network is up
> because this way it can just do its thing without spurious noise about
> failed connections.

OK, I think this is indeed OK, then.

Lennart

--
Lennart Poettering, Berlin
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Demi Marie Obenour]

On 2/22/22 16:47, Chris Adams wrote:
> Once upon a time, Demi Marie Obenour  said:
>> As mentioned above, the purpose of this change is to ensure that
>> vulnerabilities in obscure protocols impact a smaller fraction of
>> users.  Right now, a vulnerability in an obscure protocol impacts
>> most users.  With this change, it will only impact users that have
>> installed the full version of curl.  This is independent of whether a
>> given protocol should be disabled outright.
> 
> I just feel that if there's enough security concern with some of the
> code, then Fedora shouldn't ship that code.  Either the code is secure
> enough and maintained well enough to ship, or it's not.
> 
> Otherwise, don't list this as a justification for the change proposal.

Secure enough to ship ≠ secure enough to enable by default.  Every
piece of attack surface that can be removed from the default install
is helpful.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing account takeovers through expired domains

[Kevin Fenzi]

On Tue, Feb 22, 2022 at 11:33:55AM +, Daniel P. Berrangé wrote:
> On Sun, Feb 20, 2022 at 04:08:43PM -0800, Adam Williamson wrote:
> > On Sun, 2022-02-20 at 16:42 +, Gary Buhrmaster wrote:
> > > Unfortunately, last I checked, the FAS account
> > > system did not support adding something
> > > like a FIDO2 security key to an account(**).
> > > Even if it did, I suspect not all the other parts
> > > of the system would support FIDO keys.
> > 
> > It used to support these, but the support was lost with the recent
> > rewrite. However, it supports Google Authenticator-style OTPs. Folks
> > with infra privileges on their accounts (like me) are already required
> > to use these. It works fine. I preferred being able to use a yubikey so
> > I don't always have to open an app on my phone and retype a six digit
> > code when I need to log in to something, but that's just a minor
> > annoyance.
> 
> Given that the accounts system already supports these OTPs, what
> is the reason for not mandating this OTP based 2FA for *all*
> contributors today, as oppposed to merely infra people ?

All contributors? ie, require an otp to make an account?
Or did you mean all packagers? or something else?

I don't think there's any way in IPA to require otp as a requirement for
group membership currently. (Please let me know if there is). 
Which would leave us checking after the fact and removing people without
one set, which is a big pile of hassle. :( 
 
> We know that Fedora contributors have had their passwords compromised
> in the past [1], so not using 2FA of any kind is a risk to Fedora.
> 
> I understand these simple OTPs are not as secure as FIDO2, but
> they have the clear advantage of actually being supported in
> Fedora's auth system today. These OTPs are good enough that 1000's
> of companies globally use them, rather than relying on plain passwords
> only.
> 
> By all means have FIDO2 supported as the desired long term goal, but
> it feels dubious to stick with only plain passwords in the meantime.
> FIDO2 support requires significant dev work on a service that is not
> under Fedora's control and make take many many years to arrive in a
> form that is usable.

Enforcing otp per group also would require dev work from what I
understand. :(

kevin


signature.asc
Description: PGP signature
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Looking for %{forgemeta} GitHub example

[Chris Adams]

Once upon a time, Ian Pilcher  said:
> Can anyone suggest a good (simple) example SPEC file that I can
> reference as an example of how to use the forgemeta macro?

Aside from the other follow-ups about whether or not to use them...
here's an example of a SPEC I wrote for a proposed package:

https://cmadams.fedorapeople.org/ks-install/ks-install.spec

-- 
Chris Adams 
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> Yes. But how many domains using idn are there? I worked on idn support
> in systemd, but when preparing the description of this change I realized
> that I have _never_ once used an idn domain outside of testing.
> 
> And note that this is not about user-facing programs like firefox.
> I assume that there might be _some_ use of idn in firefox. But for
> command-line tools like curl this seems even less likely.

I'm pretty sure use of IDN domains is a regional thing.  I live in the
US and don't see IDN domains in my normal use.  But dropping support for
them from a core utility would be bad for those that live in regions
where IDN domains may be more common.

-- 
Chris Adams 
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Demi Marie Obenour  said:
> As mentioned above, the purpose of this change is to ensure that
> vulnerabilities in obscure protocols impact a smaller fraction of
> users.  Right now, a vulnerability in an obscure protocol impacts
> most users.  With this change, it will only impact users that have
> installed the full version of curl.  This is independent of whether a
> given protocol should be disabled outright.

I just feel that if there's enough security concern with some of the
code, then Fedora shouldn't ship that code.  Either the code is secure
enough and maintained well enough to ship, or it's not.

Otherwise, don't list this as a justification for the change proposal.

-- 
Chris Adams 
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Chris Murphy]

On Tue, Feb 22, 2022 at 12:34 PM Gary Buhrmaster
 wrote:
>
> Perhaps there are additional hints in:
>
>systemctl show -p WantedBy,RequiredBy,After,Before network-online.target
>
> I also suspect i don't understand the
> problem well enough to have the correct
> clue to help.


# systemctl show -p WantedBy,RequiredBy,After,Before network-online.target
RequiredBy=
WantedBy=packagekit.service dnf-makecache.timer
Before=shutdown.target iscsid.service kdump.service
dnf-makecache.service iscsi.service
After=network.target NetworkManager-wait-online.service


-- 
Chris Murphy
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 36 Bodhi updates-testing Activation and Beta Freeze

[Adam Williamson]

On Tue, 2022-02-22 at 14:34 +0100, Tomas Hrcka wrote:
> Hi all,
> 
> Today's an important day on the Fedora 36 schedule[1], with several
> significant cut-offs. First of all, today is the Bodhi updates-testing
> activation point [2]. That means that from now all Fedora 36 packages must
> be submitted to updates-testing and pass the relevant
> requirements[3] before they will be marked as 'stable' and moved to
> the fedora repository.

Note this also means critical path updates are tested in openQA. Gating
is not yet enabled, though. There are some known failures at this time:
the desktop_background tests , the install_default_update_live tests
for KDE, and desktop_printing and desktop_update_graphical for KDE are
failing. If you see these failures for your update, don't worry, they
aren't caused by your update. I'll work on cleaning these up, and
enabling gating for known-good tests soon.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Peter Robinson]

On Tue, Feb 22, 2022 at 5:00 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default
>
> == Summary ==
> `libcurl-minimal` and `curl-minimal` will be installed by default
> instead of `libcurl` and `curl`.
> The "minimal" variants provide only a subset of protocols (HTTP, HTTPS, FTP).

Does it make sense to keep FTP with most browsers obsoleting the
protocol due to lack of security?

> The full versions can be explicitly requested as `libcurl-full` and 
> `curl-full`.
>
> == Owner ==
> * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
> * Email: zbyszek at in.waw.pl
> * Name: [[User:Kdudka| Kamil Dudka]]
> * Email: kdudka at redhat.com
>
>
> == Detailed Description ==
>
> The `curl` package provides two sets of subpackages: `curl`+`libcurl`
> and `curl-minimal`+`libcurl+minimal`.
> `curl-minimal`+`libcurl-minimal` are compiled with various
> semi-obsolete protocols and infrequently-used features disabled:
> DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP,
> SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names.
>
> (Both variants support HTTP, HTTPS, and FTP.)
>
> `curl-minimal` has `Provides:curl` and `libcurl-minimal` has 
> `Provides:libcurl`.
> This means that both sets can be used to satisfy a dependency on
> `curl` or `libcurl`.
> `curl` has the virtual `Provides:curl-full` and `libcurl` has the
> virtual `Provides:libcurl-full`.
> The user or another package can explicitly pull in the full variants,
> e.g. with `dnf install curl-full`
> or `Requires: libcurl-full`.
> With this change, `Suggests: libcurl-minimal` or `Suggests:
> curl-minimal` will be added to a few packages
> that already have a dependency on `libcurl` or `curl`.
> Currently, doing this for `systemd` and `rpm` is planned.
> Effectively, `dnf` will install the minimal variants, unless another
> package has a stronger dependency on the full variants.
>
>
> == Benefit to Fedora ==
> There are two separate motivations for this.
>
> Those infrequently used protocols are less tested than the common ones
> and are a source of security bugs.
> Most users are not using those protocols anyway, so disabling them
> reduces the bug and attack surface.
> (In fact, many applications already call `curl_easy_setopt(c,
> CURLOPT_PROTOCOLS, …)` to internally
> limit what protocols are supported. So even if `libcurl` is swapped
> for `libcurl-minimal` for many
> uses this will not be a difference.)
>
> The packages for the minimal variants are smaller:
> a trivial installation with `curl-minimal`+`libcurl+minimal` is 18 MB
> download, 57 MB installed size, 50 packages;
> the same with `curl-full` and  `libcurl-full` is 21 MB download, 65
> installed size, 62 packages.
> Thus we save 8 MB, reducing the initial size by 12%.
>
> == Scope ==
> * Proposal owners:
> Create pull requests to add `Suggests: curl-minimal` or `Suggests:
> libcurl-minimal` as appropriate
> to packages which already require `curl` or `libcurl`: `rpm` and `systemd`.
> This means that any installation (which should be most of them) will
> get the minimal variants.
>
> * Other developers:
> For packages that use the full variants: add `Recommends: curl-full`
> or `Recommends: libcurl-full` or
> `Requires: curl-full` or `Requires: libcurl-full` as appropriate.
>
> * Release engineering:
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
> == Upgrade/compatibility impact ==
> Users who use curl or another application which uses libcurl with the
> removed protocols will lose support for those protocols. They will
> need to explicitly install the full variants.
>
> == How To Test ==
> `dnf swap curl curl-minimal` or `dnf swap libcurl libcurl-minimal` and
> check that `curl` and other applications using `libcurl` still work.
>
> == User Experience ==
> This should be not be noticed by users, except as noted above in
> Upgrade/compatibility impact.
>
> == Dependencies ==
>
> == Contingency Plan ==
>
> Remove the additions of Suggests, or even add explicit Recommends or Requires.
> * Contingency deadline: any time, possibly even after the final release
> * Blocks release? No
>
> == Documentation ==
> This page should be enough.
>
> == Release Notes ==
> `curl-minimal` and `libcurl-minimal` are installed by default. The
> support for various obsolete protocols is unavailable by default
> through curl (DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP,
> SMB, SMTP, SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names).
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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: 

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 22, 2022 at 07:25:41PM +0100, Björn Persson wrote:
> > `curl-minimal`+`libcurl-minimal` are compiled with various
> > semi-obsolete protocols and infrequently-used features disabled:
> > DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP,
> > SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names.
> 
> Disabling IDNA makes libcurl-minimal suited only for programs that only
> communicate with a predefined set of servers in ASCII-only domains. Any
> program that accepts user-provided URLs will need curl-full to be able
> to handle arbitrary domain names, even if the program speaks only HTTPS,
> HTTP and FTP.

Yes. But how many domains using idn are there? I worked on idn support
in systemd, but when preparing the description of this change I realized
that I have _never_ once used an idn domain outside of testing.

And note that this is not about user-facing programs like firefox.
I assume that there might be _some_ use of idn in firefox. But for
command-line tools like curl this seems even less likely.

Zbyszek
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Looking for %{forgemeta} GitHub example

[Jason L Tibbitts III]

> Brandon Nielsen  writes:

> I would like to see the forge macros removed from the guidelines if
> development truly has ceased.

I would like to get into them and at least see what needs to change
but... the internal implementation is somewhat baroque and my time is
severely limited.  I think there is good stuff there but I don't know
how much work would be required to salvage it.

One problem is that at least I thought that significant portions of the
Go tooling relied on it, and there's no alternative that has any kind of
automation.

 - J<
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Looking for %{forgemeta} GitHub example

[Brandon Nielsen]

On 2/22/22 1:19 AM, Mattia Verga via devel wrote:

Il 21/02/22 22:09, Fabio Valentini ha scritto:

Hi!
I would recommend that you use the standard source handling as
documented on the SourceURL page.
The forge macros are no longer actively maintained or developed, the
last fix / update they received was almost two years ago.
The original author is no longer contributing to Fedora, and nobody
else seems to understand how the lua scripts behind those macros work.


So, shall we remove the reference to %forgemeta macros from the
Packaging Guidelines?

I'd like to have only one recommended way to make things listed in PG.
Having more is confusing for new packagers (and experienced also).

The same applies for %autorelease and %autochangelog. Either recommend
the use of them or not, instead of saying "pick what you like". It seems
to me that these two were adopted in a hurry, but now the development
has almost stopped...

Mattia



I would like to see the forge macros removed from the guidelines if 
development truly has ceased. I just switched a bunch of stuff I build 
on copr over, and am now moderately annoyed. Out of date documentation 
is often worse than no documentation.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Demi Marie Obenour]

On 2/22/22 13:57, Chris Adams wrote:
> Once upon a time, Ben Cotton  said:
>> Those infrequently used protocols are less tested than the common ones
>> and are a source of security bugs.
>> Most users are not using those protocols anyway, so disabling them
>> reduces the bug and attack surface.
> 
> This is a poor argument IMHO.  If the protocols are still going to be
> shipped, they need to be maintained to the same level.  There will be
> things that want to use some other protocol and guides on the Internet
> that say "for Fedora, install the full curl", so from a security
> standpoint, the maintenance requirement is still the same.

Reducing maintenance requirements is not the purpose of this change.
The purpose is to reduce the likelihood that a user is compromised by a
0day or other vulnerability.  The fewer people are impacted by a given
vulnerability, the better.

> Looking at the curl RPM changelog on F35, most CVE entries seem to be
> TLS and/or HTTP(S) related, with a couple of TELNET and one MQTT.
> Looking back to 2020, there were more TLS and a couple of FTP (which is
> staying in the minimal build).
> 
> If TELNET/etc. is a problem and not being maintained upstream, then just
> drop TELNET.  Don't shuffle it off to the side and ignore security
> issues in a package still in the repos.

As mentioned above, the purpose of this change is to ensure that
vulnerabilities in obscure protocols impact a smaller fraction of
users.  Right now, a vulnerability in an obscure protocol impacts
most users.  With this change, it will only impact users that have
installed the full version of curl.  This is independent of whether a
given protocol should be disabled outright.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Gary Buhrmaster]

On Tue, Feb 22, 2022 at 5:42 PM Chris Murphy  wrote:

> $ cat /usr/lib/systemd/system/packagekit.service
> [Unit]
> Description=PackageKit Daemon
> # PK doesn't know how to do anything on ostree-managed systems;
> # currently the design is to have dedicated daemons like
> # eos-updater and rpm-ostree, and gnome-software talks to those.
> ConditionPathExists=!/run/ostree-booted
> Wants=network-online.target
>
> [Service]
> Type=dbus
> BusName=org.freedesktop.PackageKit
> User=root
> ExecStart=/usr/libexec/packagekitd
>

Older versions of the service file did
not include the Wants= in the package.
PackageKit 1.2.5 included the Wants=
But in any event, there is no After=.

Perhaps there are additional hints in:

   systemctl show -p WantedBy,RequiredBy,After,Before network-online.target

I also suspect i don't understand the
problem well enough to have the correct
clue to help.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Ben Cotton  said:
> Those infrequently used protocols are less tested than the common ones
> and are a source of security bugs.
> Most users are not using those protocols anyway, so disabling them
> reduces the bug and attack surface.

This is a poor argument IMHO.  If the protocols are still going to be
shipped, they need to be maintained to the same level.  There will be
things that want to use some other protocol and guides on the Internet
that say "for Fedora, install the full curl", so from a security
standpoint, the maintenance requirement is still the same.

Looking at the curl RPM changelog on F35, most CVE entries seem to be
TLS and/or HTTP(S) related, with a couple of TELNET and one MQTT.
Looking back to 2020, there were more TLS and a couple of FTP (which is
staying in the minimal build).

If TELNET/etc. is a problem and not being maintained upstream, then just
drop TELNET.  Don't shuffle it off to the side and ignore security
issues in a package still in the repos.

-- 
Chris Adams 
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Rpm: provide a static library in package

[Denis Fateyev]

Hello all,

The "ustl" upstream, for which I maintain the RPM package, has recently
switched from providing a shared library to a static library.

So I'm going to make changes in the package, and provide everything in
"-devel" subpackage.
I have looked through
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries
requirements — but there are some questions left.

1) Should I preserve debug information for the static library during build,
so the library can be stripped and debug packages can be created? Or, can I
just skip  debug package creation with  "%global debug_package %{nil}" ?
I know it's acceptable for header-only, but not sure for packages with
binary static libraries.

2) Can I use the stripping LDFLAGS option ("-s") right during the static
package build, not to strip anything after build? Or, let the built library
be stripped in terms of RPM package flow?

Thanks!

-- 
wbr, Denis.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Chris Murphy]

On Tue, Feb 22, 2022 at 10:50 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Feb 22, 2022 at 10:41:50AM -0700, Chris Murphy wrote:
> > $ cat /usr/lib/systemd/system/dnf-makecache.timer
> > [Unit]
> > Description=dnf makecache --timer
> > ConditionKernelCommandLine=!rd.live.image
> > # See comment in dnf-makecache.service
> > ConditionPathExists=!/run/ostree-booted
> > Wants=network-online.target
> >
> > [Timer]
> > OnBootSec=10min
> > OnUnitInactiveSec=1h
> > RandomizedDelaySec=60m
> > Unit=dnf-makecache.service
> >
> > [Install]
> > WantedBy=timers.target
> > [chris@fovo ~]$
> >
> >
> > So what should the Wants be here, instead of network-online.target?
> > multiuser.target? I suppose they need to be someone tolerant of no
> > network being available during startup, it does seem to take a while
> > for wireless connections to succeed, but at least in my case it's up
> > by the time I've logged in.
> >
> > Also the same thing for packagekit.service.
> >
> > $ cat /usr/lib/systemd/system/packagekit.service
> > [Unit]
> > Description=PackageKit Daemon
> > # PK doesn't know how to do anything on ostree-managed systems;
> > # currently the design is to have dedicated daemons like
> > # eos-updater and rpm-ostree, and gnome-software talks to those.
> > ConditionPathExists=!/run/ostree-booted
> > Wants=network-online.target
> >
> > [Service]
> > Type=dbus
> > BusName=org.freedesktop.PackageKit
> > User=root
> > ExecStart=/usr/libexec/packagekitd
>
> See my other mail: those two are not a problem.

I'm lost on what is causing the problem, because I have a reproducible
doubling of boot times with NetworkManager-wait-online.service
enabled, versus not enabled. And
$ systemctl show -p WantedBy,RequiredBy network-online.target
RequiredBy=
WantedBy=packagekit.service dnf-makecache.timer

So it seems one or both of those is the cause of the problem; or I
don't understand the problem well enough to be involved in the
discussion (almost certainly true anyway).


-- 
Chris Murphy
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM spec feedback directly in your editor

[Artur Frenszek-Iwicki]

> error: Unable to open /dev/stdin: No such device or address
How about "/proc/self/fd/0"?

A.FI.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Gary Buhrmaster]

On Tue, Feb 22, 2022 at 5:43 PM Zbigniew Jędrzejewski-Szmek
 wrote:

> No, no. dnf-makecache.timer is "asynchronous" — it is not part of
> multi-user.target. It is reasonable to order it after network is up
> because this way it can just do its thing without spurious noise about
> failed connections.

It would seem to me that the service file should
have the Wants, not the timer (after all, it is
possible to start the service without using
a timer, and your argument about spurious
noise would apply there too).
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Björn Persson]

> `curl-minimal`+`libcurl-minimal` are compiled with various
> semi-obsolete protocols and infrequently-used features disabled:
> DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP,
> SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names.

Disabling IDNA makes libcurl-minimal suited only for programs that only
communicate with a predefined set of servers in ASCII-only domains. Any
program that accepts user-provided URLs will need curl-full to be able
to handle arbitrary domain names, even if the program speaks only HTTPS,
HTTP and FTP.

Björn Persson


pgp4a7tFpzQPo.pgp
Description: OpenPGP digital signatur
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing account takeovers through expired domains

[Demi Marie Obenour]

On 2/22/22 06:33, Daniel P. Berrangé wrote:
> On Sun, Feb 20, 2022 at 04:08:43PM -0800, Adam Williamson wrote:
>> On Sun, 2022-02-20 at 16:42 +, Gary Buhrmaster wrote:
>>> Unfortunately, last I checked, the FAS account
>>> system did not support adding something
>>> like a FIDO2 security key to an account(**).
>>> Even if it did, I suspect not all the other parts
>>> of the system would support FIDO keys.
>>
>> It used to support these, but the support was lost with the recent
>> rewrite. However, it supports Google Authenticator-style OTPs. Folks
>> with infra privileges on their accounts (like me) are already required
>> to use these. It works fine. I preferred being able to use a yubikey so
>> I don't always have to open an app on my phone and retype a six digit
>> code when I need to log in to something, but that's just a minor
>> annoyance.
> 
> Given that the accounts system already supports these OTPs, what
> is the reason for not mandating this OTP based 2FA for *all*
> contributors today, as oppposed to merely infra people ?

I very much would support this change.

> We know that Fedora contributors have had their passwords compromised
> in the past [1], so not using 2FA of any kind is a risk to Fedora.
> 
> I understand these simple OTPs are not as secure as FIDO2, but
> they have the clear advantage of actually being supported in
> Fedora's auth system today. These OTPs are good enough that 1000's
> of companies globally use them, rather than relying on plain passwords
> only.
> 
> By all means have FIDO2 supported as the desired long term goal, but
> it feels dubious to stick with only plain passwords in the meantime.
> FIDO2 support requires significant dev work on a service that is not
> under Fedora's control and make take many many years to arrive in a
> form that is usable.

I wholeheartedly agree with this statement.

> With regards,
> Daniel
> 
> [1] 
> https://lists.fedoraproject.org/pipermail/announce/2011-January/002911.html
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20220222.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
4 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 25/216 (x86_64), 28/161 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220221.n.0):

ID: 1141249 Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/1141249
ID: 1141277 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1141277
ID: 1141303 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/1141303
ID: 1141317 Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1141317
ID: 1141326 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1141326
ID: 1141329 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1141329
ID: 1141337 Test: aarch64 Server-dvd-iso 
install_repository_nfsiso_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1141337
ID: 1141385 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/1141385
ID: 1141457 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1141457
ID: 1141467 Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/1141467
ID: 1141531 Test: aarch64 universal upgrade_2_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1141531

Old failures (same test failed in Fedora-Rawhide-20220221.n.0):

ID: 1141235 Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/1141235
ID: 1141257 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1141257
ID: 1141263 Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1141263
ID: 1141267 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1141267
ID: 1141270 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1141270
ID: 1141273 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1141273
ID: 1141276 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1141276
ID: 1141340 Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/1141340
ID: 1141361 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1141361
ID: 1141379 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1141379
ID: 1141380 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1141380
ID: 1141384 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1141384
ID: 1141387 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1141387
ID: 1141389 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1141389
ID: 1141406 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1141406
ID: 1141407 Test: x86_64 Workstation-upgrade desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1141407
ID: 1141408 Test: x86_64 Workstation-upgrade 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1141408
ID: 1141415 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1141415
ID: 1141418 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1141418
ID: 1141434 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1141434
ID: 1141439 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1141439
ID: 1141440 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1141440
ID: 1141447 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1141447
ID: 1141448 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1141448
ID: 1141451 Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/1141451
ID: 1141461 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1141461
ID: 1141480 Test: 

Re: Failed OpenQA tests for zchunk update - how to troubleshoot?

[Adam Williamson]

On Mon, 2022-02-21 at 22:36 +, Jonathan Dieter wrote:
> On Sun, 2022-02-20 at 15:37 -0800, Adam Williamson wrote:
> > On Sun, 2022-02-20 at 20:26 +, Jonathan Dieter wrote:
> > > I've just pushed zchunk-1.2.0 to all active Fedora branches, and
> > > it's
> > > passed the (admittedly non-comprehensive) zchunk test suite, but
> > > I'm
> > > seeing 2 OpenQA failed tests in Bodhi:
> > > 
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2022-e4bcaeea7a
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2022-a3da9e6213
> > > 
> > > Looking through
> > > https://openqa.fedoraproject.org/tests/1138503#step/_do_install_and_reboot/5
> > > it's not clear where the problem is in the screenshots that show as
> > > failed, especially since zchunk has nothing to do with the UI.
> > > 
> > > Is this some unrelated OpenQA error, or am I missing something?
> > 
> > You're missing that I'm an idiot and JSON is awful. Sorry!
> > 
> > https://pagure.io/fedora-qa/os-autoinst-distri-fedora/c/9bc039b26de4779f74d5da146889779b2a55b111?branch=master
> > 
> > Should be all good in an hour or so, after I hit a bunch of restart
> > buttons.
> 
> Thanks so much for looking into this!  That fixed the F34 build, but
> I'm still seeing a failed test in F35:
> https://openqa.fedoraproject.org/tests/1138994
> 
> Is there some way I can restart it, or does that require special
> permission?

Oh, that was bad luck :| That was the re-run I triggered after fixing
the JSON problem, but it happened to hit a mysterious failure that
occasionally happens and I don't know why:
https://bugzilla.redhat.com/show_bug.cgi?id=2051753
I'm trying to find time to debug it but I haven't managed to yet. It
only happens occasionally and usually isn't an issue because we
automatically retry all failed tests once (so when this rarely happens,
it almost always works on the retry), but since this was already a
retry of a failed test, it didn't get re-re-tried :\

Yes, you can restart the tests; just hit the "Re-Trigger Tests" button
in Bodhi. It should be visible any time gating is "failed". It looks
like maybe you or someone figured this out, because the test was
restarted this morning and did actually pass this time.

Sorry again for the trouble!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: strange ppc64le failures

[Peter Lemenkov]

Thanks, now I can see what's wrong here!
So I am going to update gnulib to something more recent starting from F-36

вт, 22 февр. 2022 г. в 19:01, Jakub Jelinek :
>
> On Thu, Feb 17, 2022 at 07:49:45PM +0100, Peter Lemenkov wrote:
> > Hello,
> > I've got a very suspiciously looking compilation issues while building
> > PSPP package. All other arches are good except for ppc64le. Just grep
> > for "error:" in the log attached.
> >
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=82939449
> > * https://kojipkgs.fedoraproject.org//work/tasks/9583/82939583/build.log
> > (ppc64le build log)
> >
> > Is it a known issue or something new?
>
> That typically means using old gnulib headers which contained a copy of
> what glibc did, but weren't updated to what glibc does now.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=2044656 for more details.
>
> Jakub
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
With best regards, Peter Lemenkov.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2057089] perl-B-Keywords-1.24 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2057089



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-B-Keywords-1.24-1.fc34.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=83181279


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2057089
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: strange ppc64le failures

[Jakub Jelinek]

On Thu, Feb 17, 2022 at 07:49:45PM +0100, Peter Lemenkov wrote:
> Hello,
> I've got a very suspiciously looking compilation issues while building
> PSPP package. All other arches are good except for ppc64le. Just grep
> for "error:" in the log attached.
> 
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=82939449
> * https://kojipkgs.fedoraproject.org//work/tasks/9583/82939583/build.log
> (ppc64le build log)
> 
> Is it a known issue or something new?

That typically means using old gnulib headers which contained a copy of
what glibc did, but weren't updated to what glibc does now.

See https://bugzilla.redhat.com/show_bug.cgi?id=2044656 for more details.

Jakub
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 22, 2022 at 05:09:37PM +, Daniel P. Berrangé wrote:
> On Tue, Feb 22, 2022 at 12:00:06PM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default
> > 
> > == Summary ==
> > `libcurl-minimal` and `curl-minimal` will be installed by default
> > instead of `libcurl` and `curl`.
> > The "minimal" variants provide only a subset of protocols (HTTP, HTTPS, 
> > FTP).
> > The full versions can be explicitly requested as `libcurl-full` and 
> > `curl-full`.
> > 
> > == Owner ==
> > * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
> > * Email: zbyszek at in.waw.pl
> > * Name: [[User:Kdudka| Kamil Dudka]]
> > * Email: kdudka at redhat.com
> > 
> > 
> > == Detailed Description ==
> > 
> > The `curl` package provides two sets of subpackages: `curl`+`libcurl`
> > and `curl-minimal`+`libcurl+minimal`.
> > `curl-minimal`+`libcurl-minimal` are compiled with various
> > semi-obsolete protocols and infrequently-used features disabled:
> > DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP,
> > SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names.
> > 
> > (Both variants support HTTP, HTTPS, and FTP.)
> > 
> > `curl-minimal` has `Provides:curl` and `libcurl-minimal` has 
> > `Provides:libcurl`.
> > This means that both sets can be used to satisfy a dependency on
> > `curl` or `libcurl`.
> > `curl` has the virtual `Provides:curl-full` and `libcurl` has the
> > virtual `Provides:libcurl-full`.
> > The user or another package can explicitly pull in the full variants,
> > e.g. with `dnf install curl-full`
> > or `Requires: libcurl-full`.
> > With this change, `Suggests: libcurl-minimal` or `Suggests:
> > curl-minimal` will be added to a few packages
> > that already have a dependency on `libcurl` or `curl`.
> > Currently, doing this for `systemd` and `rpm` is planned.
> > Effectively, `dnf` will install the minimal variants, unless another
> > package has a stronger dependency on the full variants.
> > 
> > 
> > == Benefit to Fedora ==
> > There are two separate motivations for this.
> > 
> > Those infrequently used protocols are less tested than the common ones
> > and are a source of security bugs.
> > Most users are not using those protocols anyway, so disabling them
> > reduces the bug and attack surface.
> > (In fact, many applications already call `curl_easy_setopt(c,
> > CURLOPT_PROTOCOLS, …)` to internally
> > limit what protocols are supported. So even if `libcurl` is swapped
> > for `libcurl-minimal` for many
> > uses this will not be a difference.)
> > 
> > The packages for the minimal variants are smaller:
> > a trivial installation with `curl-minimal`+`libcurl+minimal` is 18 MB
> > download, 57 MB installed size, 50 packages;
> > the same with `curl-full` and  `libcurl-full` is 21 MB download, 65
> > installed size, 62 packages.
> > Thus we save 8 MB, reducing the initial size by 12%.
> > 
> > == Scope ==
> > * Proposal owners:
> > Create pull requests to add `Suggests: curl-minimal` or `Suggests:
> > libcurl-minimal` as appropriate
> > to packages which already require `curl` or `libcurl`: `rpm` and `systemd`.
> > This means that any installation (which should be most of them) will
> > get the minimal variants.
> > 
> > * Other developers:
> > For packages that use the full variants: add `Recommends: curl-full`
> > or `Recommends: libcurl-full` or
> > `Requires: curl-full` or `Requires: libcurl-full` as appropriate.
> 
> The libcurl-devel RPM has a Requires: libcurl, which will
> be satisfied by either full or minimal versions.
> 
> IOW, if an application has a test suite that relies on a
> particular protocols not present in the minimal build, then
> their BuildRequires will also need to explicitly ask for a
> libcurl-full.

I added a note in "Upgrade/compatibility impact".

If this turns out to be common problem, we could add Requires:libcurl-full
to libcurl-devel. Nevertheless, I don't expect that that it will be common
at all.

Zbyszek
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2057089] New: perl-B-Keywords-1.24 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2057089

Bug ID: 2057089
   Summary: perl-B-Keywords-1.24 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-B-Keywords
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
mspa...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
rob.my...@gtri.gatech.edu
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.24
Current version/release in rawhide: 1.23-2.fc36
URL: http://search.cpan.org/dist/B-Keywords/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2662/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2057089
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2057089] perl-B-Keywords-1.24 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2057089



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1862694
  --> https://bugzilla.redhat.com/attachment.cgi?id=1862694=edit
Update to 1.24 (#2057089)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2057089
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

RPM spec feedback directly in your editor

[Andreas Schneider]

Hi,

I'm a big fan of neovim (emacs users jump to 'emacs:' ;-). neovim has support 
for the Language Server Protocol and there is a nice plugin called 'null-ls' 
[1] which allows you to hook linters and formatters into neovim.

I've added support for rpmspec in 'null-ls' so you can get feedback directly 
while editing a spec file. See the attached screenshot.

How to configure it:

```
local ok, null_ls = pcall(require, 'null-ls')
if not ok then
return
end
local sources = {}

if vim.fn.executable('rpmspec') == 1 then
table.insert(sources, null_ls.builtins.diagnostics.rpmspec)
end

null_ls.setup({
debug = false,
sources = sources,
})
```

What is currently missing in rpmspec is support to parse the input form stdin 
instead of a file [2]. But there is already a PR to support it [3].

Best regards


Andreas


[1] https://github.com/jose-elias-alvarez/null-ls.nvim/
[2] https://github.com/rpm-software-management/rpm/issues/1926
[3] https://github.com/rpm-software-management/rpm/pull/1928

emacs:
There is a general purpose LSP called diagnostic-language-server [4]
you can use to achieve the same with emacs-lsp.

`dnf install nodejs-diagnostic-languageserver`

[4] https://github.com/iamcco/diagnostic-languageserver___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 22, 2022 at 10:41:50AM -0700, Chris Murphy wrote:
> $ cat /usr/lib/systemd/system/dnf-makecache.timer
> [Unit]
> Description=dnf makecache --timer
> ConditionKernelCommandLine=!rd.live.image
> # See comment in dnf-makecache.service
> ConditionPathExists=!/run/ostree-booted
> Wants=network-online.target
> 
> [Timer]
> OnBootSec=10min
> OnUnitInactiveSec=1h
> RandomizedDelaySec=60m
> Unit=dnf-makecache.service
> 
> [Install]
> WantedBy=timers.target
> [chris@fovo ~]$
> 
> 
> So what should the Wants be here, instead of network-online.target?
> multiuser.target? I suppose they need to be someone tolerant of no
> network being available during startup, it does seem to take a while
> for wireless connections to succeed, but at least in my case it's up
> by the time I've logged in.
> 
> Also the same thing for packagekit.service.
> 
> $ cat /usr/lib/systemd/system/packagekit.service
> [Unit]
> Description=PackageKit Daemon
> # PK doesn't know how to do anything on ostree-managed systems;
> # currently the design is to have dedicated daemons like
> # eos-updater and rpm-ostree, and gnome-software talks to those.
> ConditionPathExists=!/run/ostree-booted
> Wants=network-online.target
> 
> [Service]
> Type=dbus
> BusName=org.freedesktop.PackageKit
> User=root
> ExecStart=/usr/libexec/packagekitd

See my other mail: those two are not a problem.

In particular dnf-makecache.timer is started early (as part of
timers.target in early boot), but that's OK. At some point is fires
and dnf-makecache.service will be started, but that is usually a long
time after multi-user.target has been reached and the machine has
"finished booting"(*).

(*) Quotes are used because this shows that with multiple overlapping
targets the definition of "finished" is not clear.

> ==
> 
> $ grep -r "network-online" /usr/lib/systemd/system/
> /usr/lib/systemd/system/NetworkManager-wait-online.service:Before=network-online.target
> /usr/lib/systemd/system/NetworkManager-wait-online.service:WantedBy=network-online.target
> /usr/lib/systemd/system/NetworkManager.service:#
> WantedBy=network-online.target, so enabling it only has an effect if
> /usr/lib/systemd/system/NetworkManager.service:# network-online.target
> itself is enabled or pulled in by some other unit.
> /usr/lib/systemd/system/auditd.service:## uncomment the second so that
> network-online.target is part of After.
> /usr/lib/systemd/system/auditd.service:##After=network-online.target
> local-fs.target systemd-tmpfiles-setup.service
> /usr/lib/systemd/system/cups-browsed.service:After=cups.service
> avahi-daemon.service network-online.target
> /usr/lib/systemd/system/cups-browsed.service:Wants=avahi-daemon.service
> network-online.target
> /usr/lib/systemd/system/dnf-makecache.service:After=network-online.target
> /usr/lib/systemd/system/dnf-makecache.timer:Wants=network-online.target
> /usr/lib/systemd/system/dnsmasq.service:;After=network-online.target
> /usr/lib/systemd/system/iscsi.service:After=network.target
> network-online.target iscsid.service iscsiuio.service
> systemd-remount-fs.service
> /usr/lib/systemd/system/iscsid.service:After=network-online.target
> iscsiuio.service iscsi-init.service
> /usr/lib/systemd/system/kdump.service:After=network.target
> network-online.target remote-fs.target basic.target
> /usr/lib/systemd/system/nfs-mountd.service:Wants=network-online.target
> /usr/lib/systemd/system/nfs-mountd.service:After=network-online.target
> local-fs.target
> /usr/lib/systemd/system/nfs-server.service:Wants=rpcbind.socket
> network-online.target
> /usr/lib/systemd/system/nfs-server.service:After=network-online.target
> local-fs.target
> /usr/lib/systemd/system/openvpn-client@.service:After=syslog.target
> network-online.target
> /usr/lib/systemd/system/openvpn-client@.service:Wants=network-online.target
> /usr/lib/systemd/system/openvpn-server@.service:After=syslog.target
> network-online.target
> /usr/lib/systemd/system/openvpn-server@.service:Wants=network-online.target
> /usr/lib/systemd/system/packagekit.service:Wants=network-online.target
> /usr/lib/systemd/system/podman-auto-update.service:Wants=network-online.target
> /usr/lib/systemd/system/podman-auto-update.service:After=network-online.target
> /usr/lib/systemd/system/rpc-statd-notify.service:Wants=network-online.target
> /usr/lib/systemd/system/rpc-statd-notify.service:After=local-fs.target
> network-online.target nss-lookup.target
> /usr/lib/systemd/system/rpc-statd.service:Wants=network-online.target
> /usr/lib/systemd/system/rpc-statd.service:After=network-online.target
> nss-lookup.target rpcbind.socket
> /usr/lib/systemd/system/systemd-networkd-wait-online.service:Before=network-online.target
> shutdown.target
> /usr/lib/systemd/system/systemd-networkd-wait-online.service:WantedBy=network-online.target
> /usr/lib/systemd/system/systemd-networkd.service:#
> WantedBy=network-online.target, so enabling it only has an effect if
> /usr/lib/systemd/system/systemd-networkd.service:#
> 

Re: Is NetworkManager-wait-online.service necessary by default?

[Michael Catanzaro]

On Tue, Feb 22 2022 at 06:14:19 PM +0100, Lennart Poettering 
 wrote:

dnf-makecache.timer nfs-server.service rpc-statd-notify.service
rpc-statd.service nfs-mountd.service


Another one: docker.service

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 22, 2022 at 10:32:52AM -0700, Chris Murphy wrote:
> On Tue, Feb 22, 2022 at 10:14 AM Lennart Poettering
>  wrote:
> >
> > On Di, 22.02.22 18:08, Lennart Poettering (mzerq...@0pointer.de) wrote:
> >
> > >  And: NM-w-o.s actually being pulled in *is* a bug, unless you
> > >  have something like configured NFS/SMB mounts in /etc/fstab,
> > >  that really cannot work without the network actually being
> > >  up. There might be other valid candidates for this,
> > >  i.e. other network client stuff that is really important for
> > >  the boot to be up.

Clarification: it *is* a bug *if* the unit that is ordered after it is
ordered before the default boot target. So e.g. something that is started
at boot but does not delay the default boot target is not a problem.

> > On one of my machines here I see that the following services pull it in:
> >
> > dnf-makecache.timer nfs-server.service rpc-statd-notify.service
> > rpc-statd.service nfs-mountd.service
> >
> > The DNF thing looks like an obvious bug to me. DNF's cache logic
> > really shouldn't add an expensive sync point to the boot like
> > this. Someone should file a bug to ask them to remove that.

No, no. dnf-makecache.timer is "asynchronous" — it is not part of
multi-user.target. It is reasonable to order it after network is up
because this way it can just do its thing without spurious noise about
failed connections.

> > The NFS stuff look all wrong to me too, i.e. NFS server stuff
> > afaics. That should not require the network to be fully up during
> > boot. But then again, NFS is weird, so what do I know?
> >
> > Normally, unlikely client software, server software should really
> > watch rtnl or so and follow local network configuration to make its
> > services available, and thus it doesn't have to wait for the online
> > sync point...

nfs works best when the network is up ;)
We probably could rewrite it to be more event-driven, but I guess
it's unlikely at this point.

> OK so PackageKit, dnf, and nfs-utils.
> 
> In a default clean install, nfs-convert.service is enabled, but vendor
> preset is disabled. I do not know why. When I use "systemctl
> preset-all" it's not enabled. And I'm not finding any candidates in
> /etc for a local change.

Zbyszek
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Chris Murphy]

$ cat /usr/lib/systemd/system/dnf-makecache.timer
[Unit]
Description=dnf makecache --timer
ConditionKernelCommandLine=!rd.live.image
# See comment in dnf-makecache.service
ConditionPathExists=!/run/ostree-booted
Wants=network-online.target

[Timer]
OnBootSec=10min
OnUnitInactiveSec=1h
RandomizedDelaySec=60m
Unit=dnf-makecache.service

[Install]
WantedBy=timers.target
[chris@fovo ~]$


So what should the Wants be here, instead of network-online.target?
multiuser.target? I suppose they need to be someone tolerant of no
network being available during startup, it does seem to take a while
for wireless connections to succeed, but at least in my case it's up
by the time I've logged in.

Also the same thing for packagekit.service.

$ cat /usr/lib/systemd/system/packagekit.service
[Unit]
Description=PackageKit Daemon
# PK doesn't know how to do anything on ostree-managed systems;
# currently the design is to have dedicated daemons like
# eos-updater and rpm-ostree, and gnome-software talks to those.
ConditionPathExists=!/run/ostree-booted
Wants=network-online.target

[Service]
Type=dbus
BusName=org.freedesktop.PackageKit
User=root
ExecStart=/usr/libexec/packagekitd

==

$ grep -r "network-online" /usr/lib/systemd/system/
/usr/lib/systemd/system/NetworkManager-wait-online.service:Before=network-online.target
/usr/lib/systemd/system/NetworkManager-wait-online.service:WantedBy=network-online.target
/usr/lib/systemd/system/NetworkManager.service:#
WantedBy=network-online.target, so enabling it only has an effect if
/usr/lib/systemd/system/NetworkManager.service:# network-online.target
itself is enabled or pulled in by some other unit.
/usr/lib/systemd/system/auditd.service:## uncomment the second so that
network-online.target is part of After.
/usr/lib/systemd/system/auditd.service:##After=network-online.target
local-fs.target systemd-tmpfiles-setup.service
/usr/lib/systemd/system/cups-browsed.service:After=cups.service
avahi-daemon.service network-online.target
/usr/lib/systemd/system/cups-browsed.service:Wants=avahi-daemon.service
network-online.target
/usr/lib/systemd/system/dnf-makecache.service:After=network-online.target
/usr/lib/systemd/system/dnf-makecache.timer:Wants=network-online.target
/usr/lib/systemd/system/dnsmasq.service:;After=network-online.target
/usr/lib/systemd/system/iscsi.service:After=network.target
network-online.target iscsid.service iscsiuio.service
systemd-remount-fs.service
/usr/lib/systemd/system/iscsid.service:After=network-online.target
iscsiuio.service iscsi-init.service
/usr/lib/systemd/system/kdump.service:After=network.target
network-online.target remote-fs.target basic.target
/usr/lib/systemd/system/nfs-mountd.service:Wants=network-online.target
/usr/lib/systemd/system/nfs-mountd.service:After=network-online.target
local-fs.target
/usr/lib/systemd/system/nfs-server.service:Wants=rpcbind.socket
network-online.target
/usr/lib/systemd/system/nfs-server.service:After=network-online.target
local-fs.target
/usr/lib/systemd/system/openvpn-client@.service:After=syslog.target
network-online.target
/usr/lib/systemd/system/openvpn-client@.service:Wants=network-online.target
/usr/lib/systemd/system/openvpn-server@.service:After=syslog.target
network-online.target
/usr/lib/systemd/system/openvpn-server@.service:Wants=network-online.target
/usr/lib/systemd/system/packagekit.service:Wants=network-online.target
/usr/lib/systemd/system/podman-auto-update.service:Wants=network-online.target
/usr/lib/systemd/system/podman-auto-update.service:After=network-online.target
/usr/lib/systemd/system/rpc-statd-notify.service:Wants=network-online.target
/usr/lib/systemd/system/rpc-statd-notify.service:After=local-fs.target
network-online.target nss-lookup.target
/usr/lib/systemd/system/rpc-statd.service:Wants=network-online.target
/usr/lib/systemd/system/rpc-statd.service:After=network-online.target
nss-lookup.target rpcbind.socket
/usr/lib/systemd/system/systemd-networkd-wait-online.service:Before=network-online.target
shutdown.target
/usr/lib/systemd/system/systemd-networkd-wait-online.service:WantedBy=network-online.target
/usr/lib/systemd/system/systemd-networkd.service:#
WantedBy=network-online.target, so enabling it only has an effect if
/usr/lib/systemd/system/systemd-networkd.service:#
network-online.target itself is enabled or pulled in by some other
unit.


Is Wants=network-online.target the problem? Or also After=network-online.target?

It looks like there's potential for more service units causing this
problem than just the two I'm seeing.


--
Chris Murphy
___
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
Do not reply to spam on 

Re: Is NetworkManager-wait-online.service necessary by default?

[Chris Murphy]

On Tue, Feb 22, 2022 at 10:14 AM Lennart Poettering
 wrote:
>
> On Di, 22.02.22 18:08, Lennart Poettering (mzerq...@0pointer.de) wrote:
>
> >  And: NM-w-o.s actually being pulled in *is* a bug, unless you
> >  have something like configured NFS/SMB mounts in /etc/fstab,
> >  that really cannot work without the network actually being
> >  up. There might be other valid candidates for this,
> >  i.e. other network client stuff that is really important for
> >  the boot to be up.
>
> On one of my machines here I see that the following services pull it in:
>
> dnf-makecache.timer nfs-server.service rpc-statd-notify.service
> rpc-statd.service nfs-mountd.service
>
> The DNF thing looks like an obvious bug to me. DNF's cache logic
> really shouldn't add an expensive sync point to the boot like
> this. Someone should file a bug to ask them to remove that.
>
> The NFS stuff look all wrong to me too, i.e. NFS server stuff
> afaics. That should not require the network to be fully up during
> boot. But then again, NFS is weird, so what do I know?
>
> Normally, unlikely client software, server software should really
> watch rtnl or so and follow local network configuration to make its
> services available, and thus it doesn't have to wait for the online
> sync point...


OK so PackageKit, dnf, and nfs-utils.

In a default clean install, nfs-convert.service is enabled, but vendor
preset is disabled. I do not know why. When I use "systemctl
preset-all" it's not enabled. And I'm not finding any candidates in
/etc for a local change.


-- 
Chris Murphy
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Tuesday's FESCo Meeting (2022-02-22) is CANCELLED

[Neal Gompa]

Hey all,

We have no new business to discuss, so this meeting is CANCELLED.

I'll chair next week if we have a meeting.

= DIscussed and Voted in the Ticket =

Change proposal: GNU Toolchain Update (gcc 12, glibc 2.35)
https://pagure.io/fesco/issue/2750
APPROVED (+6, 0, -0)

Change proposal: MinGW UCRT target
https://pagure.io/fesco/issue/2754
APPROVED (+4, 0, -0)

Proven packager request for thrnciar
https://pagure.io/fesco/issue/2755
APPROVED (+14, 0, -0)

Change proposal: MinGW OpenSSL 3.x update
https://pagure.io/fesco/issue/2756
APPROVED (+5, 0, -0)

Consider bug #2032085 (systemd-resolved not being used as expected) as
a FESCo blocker
https://pagure.io/fesco/issue/2760
APPROVED (+6, 0, -0)

Modularity guidelines change: All packages in default stream should be
part of module API
https://pagure.io/fesco/issue/2761
APPROVED (+4, 0, -0)


-- 
Neal Gompa (FAS: ngompa)
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Chris Murphy]

On Tue, Feb 22, 2022 at 10:09 AM Lennart Poettering
 wrote:
>
> On Di, 22.02.22 09:38, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Do any of Fedora desktop spins and Workstation edition need
> > NetworkManager-wait-online.service enabled by default?
> >
> > Fedora 35 Workstation (updated, default "preset-all" service units)
> > $ systemd-analyze
> > Startup finished in 1.330s (kernel) + 1.284s (initrd) + 12.256s
> > (userspace) = 14.871s
> > graphical.target reached after 12.232s in userspace
> >
> > Fedora 35 Workstation, same as above except
> > NetworkManager-wait-online.service is disabled
> > $ systemd-analyze
> > Startup finished in 1.294s (kernel) + 1.243s (initrd) + 5.704s
> > (userspace) = 8.242s
> > graphical.target reached after 5.670s in userspace
> >
> > 6.6s longer to wait for what? Is this service enabled just in case
> > someone adds an NFS or Samba mount to fstab? I'm not sure why this
> > service unit is enabled by default; and if we can either go without it
> > on the desktop, or if there's some other way to make it better,
> > because nearly doubling the boot time doesn't seem reasonable.
>
> The idea is that it is only pulled into the bootup transaction if
> something needs it. Typically that's stuff like NFS/SMB mounts listed
> in /etc/fstab or so.

Nothing like that is in fstab. Just some extra btrfs subvolumes
compared to default fstab.



> LTDR: figure our which service pulls in network-online.target for
> you. A command like this should work:
>
> systemctl show -p WantedBy,RequiredBy network-online.target

$ systemctl show -p WantedBy,RequiredBy network-online.target
RequiredBy=
WantedBy=packagekit.service dnf-makecache.timer
$




-- 
Chris Murphy
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Release rpkg-1.64 and fedpkg-1.42

[Miro Hrončok]

On 22. 02. 22 17:35, Ondrej Nosek wrote:

Hi all,

a new version rpkg-1.64 together with fedpkg-1.42 are released containing both 
features and bugfixes.

Currently, all supported packages are present in stable repositories.

Changelog (web documentation):
https://docs.pagure.org/rpkg/releases/1.64.html 

https://docs.pagure.org/fedpkg/releases/1.42.html 



I must say that most of the changes look awesome! Thanks for this release.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Need advice on NET_ADMIN capability on a binary (iotop-c)

[Boian Bonev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Dan,

Thanks for the suggestion - I like that way because it gives full control to
the admin together with the responsibility and does not implicitly do
unexpected things. It is also a clean approach both from user experience and
packaging point of view, so I will go for that way.

With best regards,
b.

On Sun, 2022-02-20 at 07:51 +, Dan Čermák wrote:
> Hi Boian,
> 
> On February 20, 2022 12:49:53 AM UTC, Boian Bonev  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Hello,
> > 
> > I have got a pull request [1] that implements installing iotop-c with the
> > NET_ADMIN capability by default and I am trying to evaluate if that is OK
> > or
> > not.
> > 
> > Currently iotop-c will only allow to be run as root. In case it is run as
> > some
> > other user, it will advise to use sudo, or alternatively add the NET_ADMIN
> > capability to the binary:
> > 
> > sudo setcap 'cap_net_admin+eip' /iotop
> > 
> > Obviously that will have to be redone after each update, adding some
> > inconvenience for admins who decide to allow that for non-root users. 
> 
> This is not really an answer to the security question, but if that remains
> unresolved, you could also introduce a sub package to iotop-c, that would
> contain a transaction file trigger on the binary and add the capability. Thus
> user would be able to opt into having iotop-c with the added capability even
> after upgrades, as long as the sub package is installed.
> 
> 

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmIVGf0ACgkQE2VyCRPS
8i2DqBAAmmcZD3AxQg6h0U1Me0FjtNzNb2d4Rkb3WcOT5CRO4OKH3TIgtrppPm5E
dAX3KoyO7gU4etQ0drYYOp8t1RfOlw/HkjKQh2efxMNx8SSsNi5YK7SM9jPFftiK
26bU97niLb1Pozh3T5hLcAl7GDRR30/OVR8ZjxF3aEOcgxRn0f2kDS7/jboGO3we
r/bxg34f6Bg0vVN5tMvLbNbZzG60wfOWN9RHG9DEBms+dIy2f5i1BVsvWdUZ6bsM
3+yX/cuDZeUg4DwEIDtG955gjx9OfjvvvHt+uM5vCv1DSQjuLEzQ1HTHjIcJQzux
NsgpMeHZ54DokGxvFXeqDXv+I+hA0t/jjPSaHlDTmzXVRrqEhi+k0FMMGPMCE8bK
Br70cn0C07qKp2hCCAdDXbowVhGBF/5ZtirxJV/EWO5IauOjZCe09OAAUfXllgif
1CkEnSsT3aVHW5IIheHthRZev77SsDsmHzi3kFcmtn6PG1GYSfMGW2dRfftglHCy
uyU73JpRKB+DJ9ngB44+RhnIarbRDV9V7T+5omJWfZ5V0smTN6l1fHntPW+kjykr
PFk6YAlWKCIWEctwfF5JMdDERAl4908x19MeiGvtN8/aImizO6ssmebjQpqNvPFs
NuUEVvTdZD2EBua+JJcNr0CVPIjnsPcuMuoc1YNtEIYmdht3DrM=
=vTJr
-END PGP SIGNATURE-
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Lennart Poettering]

On Di, 22.02.22 18:08, Lennart Poettering (mzerq...@0pointer.de) wrote:

>  And: NM-w-o.s actually being pulled in *is* a bug, unless you
>  have something like configured NFS/SMB mounts in /etc/fstab,
>  that really cannot work without the network actually being
>  up. There might be other valid candidates for this,
>  i.e. other network client stuff that is really important for
>  the boot to be up.

On one of my machines here I see that the following services pull it in:

dnf-makecache.timer nfs-server.service rpc-statd-notify.service
rpc-statd.service nfs-mountd.service

The DNF thing looks like an obvious bug to me. DNF's cache logic
really shouldn't add an expensive sync point to the boot like
this. Someone should file a bug to ask them to remove that.

The NFS stuff look all wrong to me too, i.e. NFS server stuff
afaics. That should not require the network to be fully up during
boot. But then again, NFS is weird, so what do I know?

Normally, unlikely client software, server software should really
watch rtnl or so and follow local network configuration to make its
services available, and thus it doesn't have to wait for the online
sync point...

Lennart

--
Lennart Poettering, Berlin
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Daniel P . Berrangé]

On Tue, Feb 22, 2022 at 12:00:06PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default
> 
> == Summary ==
> `libcurl-minimal` and `curl-minimal` will be installed by default
> instead of `libcurl` and `curl`.
> The "minimal" variants provide only a subset of protocols (HTTP, HTTPS, FTP).
> The full versions can be explicitly requested as `libcurl-full` and 
> `curl-full`.
> 
> == Owner ==
> * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
> * Email: zbyszek at in.waw.pl
> * Name: [[User:Kdudka| Kamil Dudka]]
> * Email: kdudka at redhat.com
> 
> 
> == Detailed Description ==
> 
> The `curl` package provides two sets of subpackages: `curl`+`libcurl`
> and `curl-minimal`+`libcurl+minimal`.
> `curl-minimal`+`libcurl-minimal` are compiled with various
> semi-obsolete protocols and infrequently-used features disabled:
> DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP,
> SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names.
> 
> (Both variants support HTTP, HTTPS, and FTP.)
> 
> `curl-minimal` has `Provides:curl` and `libcurl-minimal` has 
> `Provides:libcurl`.
> This means that both sets can be used to satisfy a dependency on
> `curl` or `libcurl`.
> `curl` has the virtual `Provides:curl-full` and `libcurl` has the
> virtual `Provides:libcurl-full`.
> The user or another package can explicitly pull in the full variants,
> e.g. with `dnf install curl-full`
> or `Requires: libcurl-full`.
> With this change, `Suggests: libcurl-minimal` or `Suggests:
> curl-minimal` will be added to a few packages
> that already have a dependency on `libcurl` or `curl`.
> Currently, doing this for `systemd` and `rpm` is planned.
> Effectively, `dnf` will install the minimal variants, unless another
> package has a stronger dependency on the full variants.
> 
> 
> == Benefit to Fedora ==
> There are two separate motivations for this.
> 
> Those infrequently used protocols are less tested than the common ones
> and are a source of security bugs.
> Most users are not using those protocols anyway, so disabling them
> reduces the bug and attack surface.
> (In fact, many applications already call `curl_easy_setopt(c,
> CURLOPT_PROTOCOLS, …)` to internally
> limit what protocols are supported. So even if `libcurl` is swapped
> for `libcurl-minimal` for many
> uses this will not be a difference.)
> 
> The packages for the minimal variants are smaller:
> a trivial installation with `curl-minimal`+`libcurl+minimal` is 18 MB
> download, 57 MB installed size, 50 packages;
> the same with `curl-full` and  `libcurl-full` is 21 MB download, 65
> installed size, 62 packages.
> Thus we save 8 MB, reducing the initial size by 12%.
> 
> == Scope ==
> * Proposal owners:
> Create pull requests to add `Suggests: curl-minimal` or `Suggests:
> libcurl-minimal` as appropriate
> to packages which already require `curl` or `libcurl`: `rpm` and `systemd`.
> This means that any installation (which should be most of them) will
> get the minimal variants.
> 
> * Other developers:
> For packages that use the full variants: add `Recommends: curl-full`
> or `Recommends: libcurl-full` or
> `Requires: curl-full` or `Requires: libcurl-full` as appropriate.

The libcurl-devel RPM has a Requires: libcurl, which will
be satisfied by either full or minimal versions.

IOW, if an application has a test suite that relies on a
particular protocols not present in the minimal build, then
their BuildRequires will also need to explicitly ask for a
libcurl-full.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is NetworkManager-wait-online.service necessary by default?

[Lennart Poettering]

On Di, 22.02.22 09:38, Chris Murphy (li...@colorremedies.com) wrote:

> Do any of Fedora desktop spins and Workstation edition need
> NetworkManager-wait-online.service enabled by default?
>
> Fedora 35 Workstation (updated, default "preset-all" service units)
> $ systemd-analyze
> Startup finished in 1.330s (kernel) + 1.284s (initrd) + 12.256s
> (userspace) = 14.871s
> graphical.target reached after 12.232s in userspace
>
> Fedora 35 Workstation, same as above except
> NetworkManager-wait-online.service is disabled
> $ systemd-analyze
> Startup finished in 1.294s (kernel) + 1.243s (initrd) + 5.704s
> (userspace) = 8.242s
> graphical.target reached after 5.670s in userspace
>
> 6.6s longer to wait for what? Is this service enabled just in case
> someone adds an NFS or Samba mount to fstab? I'm not sure why this
> service unit is enabled by default; and if we can either go without it
> on the desktop, or if there's some other way to make it better,
> because nearly doubling the boot time doesn't seem reasonable.

The idea is that it is only pulled into the bootup transaction if
something needs it. Typically that's stuff like NFS/SMB mounts listed
in /etc/fstab or so.

Note that the fact that the unit is enabled, doesn't mean it's
automatically in the boot transaction! That's because it (correctly)
hooks itself into network-online.target (rather than multi-user.target
or so) — and that target is only pulled in when something actually
needs it.

LTDR: figure our which service pulls in network-online.target for
you. A command like this should work:

systemctl show -p WantedBy,RequiredBy network-online.target

Summary: NM-w-o.s being enabled is not a bug, if you use NM for
 network management.

 And: NM-w-o.s actually being pulled in *is* a bug, unless you
 have something like configured NFS/SMB mounts in /etc/fstab,
 that really cannot work without the network actually being
 up. There might be other valid candidates for this,
 i.e. other network client stuff that is really important for
 the boot to be up.

Lennart

--
Lennart Poettering, Berlin
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default

== Summary ==
`libcurl-minimal` and `curl-minimal` will be installed by default
instead of `libcurl` and `curl`.
The "minimal" variants provide only a subset of protocols (HTTP, HTTPS, FTP).
The full versions can be explicitly requested as `libcurl-full` and `curl-full`.

== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl
* Name: [[User:Kdudka| Kamil Dudka]]
* Email: kdudka at redhat.com


== Detailed Description ==

The `curl` package provides two sets of subpackages: `curl`+`libcurl`
and `curl-minimal`+`libcurl+minimal`.
`curl-minimal`+`libcurl-minimal` are compiled with various
semi-obsolete protocols and infrequently-used features disabled:
DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP,
SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names.

(Both variants support HTTP, HTTPS, and FTP.)

`curl-minimal` has `Provides:curl` and `libcurl-minimal` has `Provides:libcurl`.
This means that both sets can be used to satisfy a dependency on
`curl` or `libcurl`.
`curl` has the virtual `Provides:curl-full` and `libcurl` has the
virtual `Provides:libcurl-full`.
The user or another package can explicitly pull in the full variants,
e.g. with `dnf install curl-full`
or `Requires: libcurl-full`.
With this change, `Suggests: libcurl-minimal` or `Suggests:
curl-minimal` will be added to a few packages
that already have a dependency on `libcurl` or `curl`.
Currently, doing this for `systemd` and `rpm` is planned.
Effectively, `dnf` will install the minimal variants, unless another
package has a stronger dependency on the full variants.


== Benefit to Fedora ==
There are two separate motivations for this.

Those infrequently used protocols are less tested than the common ones
and are a source of security bugs.
Most users are not using those protocols anyway, so disabling them
reduces the bug and attack surface.
(In fact, many applications already call `curl_easy_setopt(c,
CURLOPT_PROTOCOLS, …)` to internally
limit what protocols are supported. So even if `libcurl` is swapped
for `libcurl-minimal` for many
uses this will not be a difference.)

The packages for the minimal variants are smaller:
a trivial installation with `curl-minimal`+`libcurl+minimal` is 18 MB
download, 57 MB installed size, 50 packages;
the same with `curl-full` and  `libcurl-full` is 21 MB download, 65
installed size, 62 packages.
Thus we save 8 MB, reducing the initial size by 12%.

== Scope ==
* Proposal owners:
Create pull requests to add `Suggests: curl-minimal` or `Suggests:
libcurl-minimal` as appropriate
to packages which already require `curl` or `libcurl`: `rpm` and `systemd`.
This means that any installation (which should be most of them) will
get the minimal variants.

* Other developers:
For packages that use the full variants: add `Recommends: curl-full`
or `Recommends: libcurl-full` or
`Requires: curl-full` or `Requires: libcurl-full` as appropriate.

* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
Users who use curl or another application which uses libcurl with the
removed protocols will lose support for those protocols. They will
need to explicitly install the full variants.

== How To Test ==
`dnf swap curl curl-minimal` or `dnf swap libcurl libcurl-minimal` and
check that `curl` and other applications using `libcurl` still work.

== User Experience ==
This should be not be noticed by users, except as noted above in
Upgrade/compatibility impact.

== Dependencies ==

== Contingency Plan ==

Remove the additions of Suggests, or even add explicit Recommends or Requires.
* Contingency deadline: any time, possibly even after the final release
* Blocks release? No

== Documentation ==
This page should be enough.

== Release Notes ==
`curl-minimal` and `libcurl-minimal` are installed by default. The
support for various obsolete protocols is unavailable by default
through curl (DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP,
SMB, SMTP, SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names).


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default

== Summary ==
`libcurl-minimal` and `curl-minimal` will be installed by default
instead of `libcurl` and `curl`.
The "minimal" variants provide only a subset of protocols (HTTP, HTTPS, FTP).
The full versions can be explicitly requested as `libcurl-full` and `curl-full`.

== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl
* Name: [[User:Kdudka| Kamil Dudka]]
* Email: kdudka at redhat.com


== Detailed Description ==

The `curl` package provides two sets of subpackages: `curl`+`libcurl`
and `curl-minimal`+`libcurl+minimal`.
`curl-minimal`+`libcurl-minimal` are compiled with various
semi-obsolete protocols and infrequently-used features disabled:
DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP,
SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names.

(Both variants support HTTP, HTTPS, and FTP.)

`curl-minimal` has `Provides:curl` and `libcurl-minimal` has `Provides:libcurl`.
This means that both sets can be used to satisfy a dependency on
`curl` or `libcurl`.
`curl` has the virtual `Provides:curl-full` and `libcurl` has the
virtual `Provides:libcurl-full`.
The user or another package can explicitly pull in the full variants,
e.g. with `dnf install curl-full`
or `Requires: libcurl-full`.
With this change, `Suggests: libcurl-minimal` or `Suggests:
curl-minimal` will be added to a few packages
that already have a dependency on `libcurl` or `curl`.
Currently, doing this for `systemd` and `rpm` is planned.
Effectively, `dnf` will install the minimal variants, unless another
package has a stronger dependency on the full variants.


== Benefit to Fedora ==
There are two separate motivations for this.

Those infrequently used protocols are less tested than the common ones
and are a source of security bugs.
Most users are not using those protocols anyway, so disabling them
reduces the bug and attack surface.
(In fact, many applications already call `curl_easy_setopt(c,
CURLOPT_PROTOCOLS, …)` to internally
limit what protocols are supported. So even if `libcurl` is swapped
for `libcurl-minimal` for many
uses this will not be a difference.)

The packages for the minimal variants are smaller:
a trivial installation with `curl-minimal`+`libcurl+minimal` is 18 MB
download, 57 MB installed size, 50 packages;
the same with `curl-full` and  `libcurl-full` is 21 MB download, 65
installed size, 62 packages.
Thus we save 8 MB, reducing the initial size by 12%.

== Scope ==
* Proposal owners:
Create pull requests to add `Suggests: curl-minimal` or `Suggests:
libcurl-minimal` as appropriate
to packages which already require `curl` or `libcurl`: `rpm` and `systemd`.
This means that any installation (which should be most of them) will
get the minimal variants.

* Other developers:
For packages that use the full variants: add `Recommends: curl-full`
or `Recommends: libcurl-full` or
`Requires: curl-full` or `Requires: libcurl-full` as appropriate.

* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
Users who use curl or another application which uses libcurl with the
removed protocols will lose support for those protocols. They will
need to explicitly install the full variants.

== How To Test ==
`dnf swap curl curl-minimal` or `dnf swap libcurl libcurl-minimal` and
check that `curl` and other applications using `libcurl` still work.

== User Experience ==
This should be not be noticed by users, except as noted above in
Upgrade/compatibility impact.

== Dependencies ==

== Contingency Plan ==

Remove the additions of Suggests, or even add explicit Recommends or Requires.
* Contingency deadline: any time, possibly even after the final release
* Blocks release? No

== Documentation ==
This page should be enough.

== Release Notes ==
`curl-minimal` and `libcurl-minimal` are installed by default. The
support for various obsolete protocols is unavailable by default
through curl (DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP,
SMB, SMTP, SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names).


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Is NetworkManager-wait-online.service necessary by default?

[Chris Murphy]

Do any of Fedora desktop spins and Workstation edition need
NetworkManager-wait-online.service enabled by default?

Fedora 35 Workstation (updated, default "preset-all" service units)
$ systemd-analyze
Startup finished in 1.330s (kernel) + 1.284s (initrd) + 12.256s
(userspace) = 14.871s
graphical.target reached after 12.232s in userspace

Fedora 35 Workstation, same as above except
NetworkManager-wait-online.service is disabled
$ systemd-analyze
Startup finished in 1.294s (kernel) + 1.243s (initrd) + 5.704s
(userspace) = 8.242s
graphical.target reached after 5.670s in userspace

6.6s longer to wait for what? Is this service enabled just in case
someone adds an NFS or Samba mount to fstab? I'm not sure why this
service unit is enabled by default; and if we can either go without it
on the desktop, or if there's some other way to make it better,
because nearly doubling the boot time doesn't seem reasonable.


-- 
Chris Murphy
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Release rpkg-1.64 and fedpkg-1.42

[Ondrej Nosek]

Hi all,

a new version rpkg-1.64 together with fedpkg-1.42 are released containing
both features and bugfixes.
Currently, all supported packages are present in stable repositories.

Changelog (web documentation):
https://docs.pagure.org/rpkg/releases/1.64.html
https://docs.pagure.org/fedpkg/releases/1.42.html

Updates:
https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.64-2.el7=rpkg-1.64-2.el8=rpkg-1.64-2.el9=rpkg-1.64-2.fc34=rpkg-1.64-2.fc35=rpkg-1.64-2.fc36=fedpkg-1.42-1.el7=fedpkg-1.42-1.el8=fedpkg-1.42-1.fc34=fedpkg-1.42-1.fc35=fedpkg-1.42-1.fc36

Alternative link:
https://bodhi.fedoraproject.org/updates/?packages=rpkg=1
https://bodhi.fedoraproject.org/updates/?packages=fedpkg=1

rpkg is also available from PyPI.

Thanks to all contributors.
Special thank to carlwgeorge who prepared el9 release.

Regards
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Net-DNS] PR #1: Update to 1.30 (#1944610)

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: 
`perl-Net-DNS` that you
are following.

Closed pull-request:

``
Update to 1.30 (#1944610)
``

https://src.fedoraproject.org/rpms/perl-Net-DNS/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Net-DNS] PR #2: Remove obsolete dependency to Net::DNS::SEC and package tests

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Net-DNS` that you 
are following:
``
Remove obsolete dependency to Net::DNS::SEC and package tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Net-DNS/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20220222.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220221.n.0
NEW: Fedora-Rawhide-20220222.n.1

= SUMMARY =
Added images:1
Dropped images:  2
Added packages:  4
Dropped packages:46
Upgraded packages:   130
Downgraded packages: 0

Size of added packages:  295.19 KiB
Size of dropped packages:47.08 MiB
Size of upgraded packages:   1.89 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   71.80 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20220222.n.1.iso

= DROPPED IMAGES =
Image: Workstation live ppc64le
Path: 
Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20220221.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20220221.n.0.iso

= ADDED PACKAGES =
Package: golang-github-gokyle-twofactor-1.1-1.fc37
Summary: Two-factor authentication
RPMs:golang-github-gokyle-twofactor-devel
Size:16.99 KiB

Package: golang-github-jsimonetti-pwscheme-0-1.20220221git4d9895f.fc37
Summary: Golang packages defining different password schemes
RPMs:golang-github-jsimonetti-pwscheme-devel
Size:14.74 KiB

Package: ibus-engine-gui-ci-1.0.0.20220118-1.fc37
Summary: GUI CI for IBus engines
RPMs:ibus-engine-gui-ci
Size:228.05 KiB

Package: python-specfile-0.1.1-1.fc37
Summary: A library for parsing and manipulating RPM spec files
RPMs:python3-specfile
Size:35.40 KiB


= DROPPED PACKAGES =
Package: erlang-riak_control-2.1.7-10.fc35
Summary: Admin UI for Riak
RPMs:erlang-riak_control
Size:1.12 MiB

Package: javadocofflinesearch-2.2-15.fc35
Summary: Tool for offline searching in your docs via browser
RPMs:javadocofflinesearch javadocofflinesearch-javadoc
Size:407.69 KiB

Package: laby-0.6.4-28.20200413git27ecf89.fc36
Summary: Learn programming, playing with ants and spider webs
RPMs:laby
Size:5.96 MiB

Package: libyui-bindings-2.0.2-8.fc36
Summary: Language bindings for libyui
RPMs:mono-yui perl-yui python3-yui ruby-yui
Size:5.08 MiB

Package: libyui-ncurses-2.55.0-6.fc36
Summary: Character Based User Interface for libyui
RPMs:libyui-ncurses libyui-ncurses-devel libyui-ncurses-doc
Size:6.88 MiB

Package: libyui-qt-2.53.0-3.fc35
Summary: Qt User Interface for libyui
RPMs:libyui-qt libyui-qt-devel libyui-qt-doc
Size:6.00 MiB

Package: libyui-qt-graph-2.45.5-4.fc36
Summary: Qt Graph Widget for libyui
RPMs:libyui-qt-graph libyui-qt-graph-devel libyui-qt-graph-doc
Size:583.47 KiB

Package: mpir-3.0.0-29.fc36
Summary: Highly optimised library for bignum arithmetic
RPMs:mpir mpir-c++ mpir-devel mpir-doc
Size:7.42 MiB

Package: perl-MouseX-App-Cmd-0.30-20.fc34
Summary: Mashes up MouseX::Getopt and App::Cmd
RPMs:perl-MouseX-App-Cmd
Size:25.44 KiB

Package: perl-VOMS-Lite-0.20-25.fc36
Summary: Perl extension for VOMS Attribute certificate creation
RPMs:perl-VOMS-Lite perl-VOMS-Lite-tests perl-voms-server
Size:195.20 KiB

Package: php-pecl-solr2-2.5.1-4.fc35
Summary: Object oriented API to Apache Solr
RPMs:php-pecl-solr2
Size:687.18 KiB

Package: python-angr-9.0.9572-4.fc36
Summary: Multi-architecture binary analysis toolkit
RPMs:python3-angr
Size:5.38 MiB

Package: python-concurrentloghandler-0.9.1-20.fc35
Summary: Concurrent logging handler (drop-in replacement for 
RotatingFileHandler)
RPMs:python3-concurrentloghandler
Size:24.71 KiB

Package: python-discord-1.7.3-2.fc36
Summary: Python wrapper for the Discord API
RPMs:python3-discord
Size:811.06 KiB

Package: python-luftdaten-0.6.5-2.fc36
Summary: Python API wrapper for interacting with luftdaten.info
RPMs:python3-luftdaten
Size:16.10 KiB

Package: python-netssh2-0.1.7-12.fc35
Summary: Library for communicating with network devices using ssh2-python
RPMs:python-netssh2-doc python3-netssh2
Size:66.31 KiB

Package: python-sphinx-testing-1.0.1-13.fc36
Summary: Testing utility classes and functions for Sphinx extensions
RPMs:python3-sphinx-testing
Size:26.04 KiB

Package: python-wand-0.5.5-10.fc36
Summary: Ctypes-based simple MagickWand API binding for Python
RPMs:python3-wand
Size:182.66 KiB

Package: rust-bytes0.6-0.6.0-4.fc36
Summary: Types and traits for working with bytes
RPMs:rust-bytes0.6+default-devel rust-bytes0.6+serde-devel 
rust-bytes0.6+std-devel rust-bytes0.6-devel
Size:75.19 KiB

Package: rust-crc1-1.8.1-2.fc36
Summary: Rust implementation of CRC(16, 32, 64) with support of various 
standards
RPMs:rust-crc1+default-devel rust-crc1+std-devel rust-crc1-devel
Size:32.81 KiB

Package: rust-crypto-mac0.8-0.8.0-4.fc36
Summary: Trait for Message Authentication Code (MAC) algorithms
RPMs:rust-crypto-mac0.8+blobby-devel rust-crypto-mac0.8+default-devel 
rust-crypto-mac0.8+dev-devel rust-crypto-mac0.8+std-devel 
rust-crypto-mac0.8-devel
Size

Fedora-IoT-37-20220222.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 3/16 (x86_64), 2/15 (aarch64)

Old failures (same test failed in Fedora-IoT-37-20220220.0):

ID: 1141623 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1141623
ID: 1141624 Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1141624
ID: 1141625 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1141625
ID: 1141639 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1141639
ID: 1141640 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1141640

Skipped non-gating openQA tests: 26 of 31
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Unannounced soname bump: libwebsockets.so.18 -> libwebsockets.so.19

[Mamoru TASAKA]

Hello, all:

On f37 / f36 two days ago libwebsockets was updated from 4.2.2 to 4.3.1
which causes unannounced soname bump from libwebsockets.so.18 to 
libwebsockets.so.19

What is strange here is that the committer seems aware of this change:
https://src.fedoraproject.org/rpms/libwebsockets/c/ad122ba347b290d1221fe6fee1c4194ac74c2719?branch=rawhide

Affected packages:

$ dnf repoquery --quiet --repo=koji-36 --qf '%{sourcerpm}' --whatrequires 
"libwebsockets.so.18()(64bit)"  | cat -n
 1  kismet-0.0.2022.01.R3-1.fc36.src.rpm
 2  qpid-dispatch-1.18.0-2.fc36.src.rpm

Note that kismet broken deps now causes Fedora-Security-Live live spin breakage:
https://koji.fedoraproject.org/koji/packageinfo?packageID=22098
https://koji.fedoraproject.org/koji/taskinfo?taskID=83148899

(Yes, Fedora-Security-Live began to be broken on f36 from 36-20220221.n.0)
And now we are under F36 beta freeze.

Regards,
Mamoru
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 36 Bodhi updates-testing Activation and Beta Freeze

[Tomas Hrcka]

Hi all,

Today's an important day on the Fedora 36 schedule[1], with several
significant cut-offs. First of all, today is the Bodhi updates-testing
activation point [2]. That means that from now all Fedora 36 packages must
be submitted to updates-testing and pass the relevant
requirements[3] before they will be marked as 'stable' and moved to
the fedora repository.

Today is also the Beta freeze[4]. This means that only packages which
fix accepted blocker or freeze exception bugs[5][6] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Today is also the Software String freeze[7], which means that strings
marked for translation in Fedora-translated projects should not now be
changed for Fedora 36.

Finally, today is the 'completion deadline' Change Checkpoint[8],
meaning that Fedora 36 Changes must now be 'feature complete or close
enough to completion that a majority of its functionality can be
tested'. All tracking bugs should be on ON_QA state or later to
reflect this.

Regards
Tomáš Hrčka

[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
[8] https://fedoraproject.org/wiki/Changes/Policy
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 36 Bodhi updates-testing Activation and Beta Freeze

[Tomas Hrcka]

Hi all,

Today's an important day on the Fedora 36 schedule[1], with several
significant cut-offs. First of all, today is the Bodhi updates-testing
activation point [2]. That means that from now all Fedora 36 packages must
be submitted to updates-testing and pass the relevant
requirements[3] before they will be marked as 'stable' and moved to
the fedora repository.

Today is also the Beta freeze[4]. This means that only packages which
fix accepted blocker or freeze exception bugs[5][6] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Today is also the Software String freeze[7], which means that strings
marked for translation in Fedora-translated projects should not now be
changed for Fedora 36.

Finally, today is the 'completion deadline' Change Checkpoint[8],
meaning that Fedora 36 Changes must now be 'feature complete or close
enough to completion that a majority of its functionality can be
tested'. All tracking bugs should be on ON_QA state or later to
reflect this.

Regards
Tomáš Hrčka

[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
[8] https://fedoraproject.org/wiki/Changes/Policy
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

List of long term FTBFS packages to be retired in March

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 36 approximately one week before branching.

However, 5 weekly reminders are required and I forgot to start this sooner,
hence the retirement will happen in 1 week, i.e. March 1st 2022.
Since this is after the Beta Freeze,
I will skip retiring components with depending packages.
Such components (if any) will be retired during the next release cycle,
and are included in this report for completeness.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 33.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.


Package  (co)maintainers
===
adf-tribun-fonts  frixxon, nim
catharsis-cormorant-fonts nim
ecolier-court-fonts   frixxon, nim
gfs-ambrosia-fontsfrixxon, nim
gfs-artemisia-fonts   nim
gfs-baskerville-fonts nim
gfs-bodoni-classic-fonts  nim
gfs-bodoni-fonts  nim
gfs-complutum-fonts   nim
gfs-decker-fonts  nim
gfs-didot-classic-fonts   nim
gfs-didot-display-fonts   nim
gfs-didot-fonts   nim
gfs-eustace-fonts nim
gfs-fleischman-fonts  nim
gfs-galatea-fonts nim
gfs-garaldus-fontsnim
gfs-gazis-fonts   nim
gfs-goschen-fonts nim
gfs-ignacio-fonts nim
gfs-jackson-fonts nim
gfs-neohellenic-fonts nim
gfs-neohellenic-math-fontsnim
gfs-nicefore-fontsnim
gfs-olga-fontsnim
gfs-orpheus-classic-fonts nim
gfs-orpheus-fonts nim
gfs-orpheus-sans-fontsnim
gfs-philostratos-fontsnim
gfs-porson-fonts  nim
gfs-pyrsos-fonts  nim
gfs-solomos-fonts nim
gfs-theokritos-fonts  nim
ht-alegreya-sans-fontsnim
impallari-dancing-script-fontsnim
intel-clear-sans-fontsnim
kemie-bellota-fonts   nim
libicu65  pwalter
ndiscover-exo-2-fonts nim
rubygem-cucumber-railsorphan
rubygem-sup dcallagh, jaruga, ruby-packagers-sig, shreyankg
sil-alkalami-fontsnim
sil-andika-compact-fonts  nim
sil-andika-fonts  nim
sil-andika-new-basic-fontsnim
sil-annapurna-fonts   nim
sil-apparatus-fonts   nim
sil-awami-nastaliq-fonts  nim
sil-charis-compact-fonts  nim
sil-dai-banna-fonts   nim
sil-ezra-fontsnim
sil-gentium-plus-compact-fontsnim
sil-harmattan-fonts   nim
sil-mondulkiri-extra-fontsnim
sil-mondulkiri-fonts  nim
sil-namdhinggo-fonts  nim
sil-shimenkan-fonts   nim
sil-sophia-nubian-fonts   nim
sil-tagmukay-fontsnim
sil-tai-heritage-pro-fontsnim
symbian-m-yuppy-gb-fonts  nim
tmux-top  ttomecek
typesetit-great-vibes-fonts   nim
uswds-public-sans-fonts   nim
vernnobile-muli-fonts nim
vernnobile-nunito-fonts   nim
vernnobile-oswald-fonts   nim
wagesreiter-patrick-hand-fontsnim
weiweihuanghuang-work-sans-fonts  nim
yanone-kaffeesatz-fonts   nim

All listed packages are leaf packages, nothing depends on them.

Affected (co)maintainers
dcallagh: rubygem-sup
frixxon: adf-tribun-fonts, ecolier-court-fonts, gfs-ambrosia-fonts
jaruga: rubygem-sup
nim: sil-namdhinggo-fonts, yanone-kaffeesatz-fonts, gfs-decker-fonts, 
gfs-didot-fonts, gfs-bodoni-fonts, impallari-dancing-script-fonts, 
gfs-didot-display-fonts, typesetit-great-vibes-fonts, sil-charis-compact-fonts, 
sil-tagmukay-fonts, uswds-public-sans-fonts, weiweihuanghuang-work-sans-fonts, 
ecolier-court-fonts, gfs-solomos-fonts, gfs-jackson-fonts, 
catharsis-cormorant-fonts, gfs-neohellenic-fonts, sil-annapurna-fonts, 
gfs-neohellenic-math-fonts, sil-andika-new-basic-fonts, gfs-eustace-fonts, 
adf-tribun-fonts, gfs-fleischman-fonts, sil-awami-nastaliq-fonts, 
sil-dai-banna-fonts, sil-mondulkiri-fonts, vernnobile-nunito-fonts, 
gfs-theokritos-fonts, ndiscover-exo-2-fonts, symbian-m-yuppy-gb-fonts, 
sil-andika-fonts, gfs-goschen-fonts, ht-alegreya-sans-fonts, gfs-olga-fonts, 

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2022-02-21.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package   (co)maintainers  Status Change

3proxy orphan  4 weeks ago
DivFix++   orphan  4 weeks ago
colorize   orphan  4 weeks ago
elmon  orphan  4 weeks ago
erlang-riak_controlbowlofeggs, erlang-maint-sig, orphan0 weeks ago
hans   orphan  4 weeks ago
httpd-itk  orphan  4 weeks ago
javahelp2  orphan  2 weeks ago
laby   orphan  6 weeks ago
mysqlreportorphan, wolfy   4 weeks ago
nautilus-image-converter   orphan, timj2 weeks ago
pacmanager ngompa, orphan  4 weeks ago
percol orphan  4 weeks ago
perl-File-Finder   orphan  4 weeks ago
perl-File-Inplace  orphan  4 weeks ago
perl-HTML-Tidy gnat, jplesnik, mmaslano, mspacek,  2 weeks ago
   orphan, ppisar
perl-Lingua-EN-Fathom  jfearn, orphan  4 weeks ago
perl-Lingua-EN-Syllableorphan  4 weeks ago
perl-MouseX-App-Cmdorphan  2 weeks ago
perl-ParseLex  orphan  4 weeks ago
pgcenter   orphan  4 weeks ago
pgdbf  orphan  4 weeks ago
php-pecl-datadog_trace orphan  3 weeks ago
php-pecl-solr2 orphan  6 weeks ago
pstreams-devel jwakely, orphan 4 weeks ago
publican   jfearn, orphan  4 weeks ago
python-ECPyorphan  4 weeks ago
python-angrfab, orphan 1 weeks ago
python-btchip  jonny, orphan   4 weeks ago
python-cmigemo orphan  4 weeks ago
python-discord orphan  0 weeks ago
python-luftdaten   orphan  3 weeks ago
python-netssh2 orphan  6 weeks ago
python-wandorphan  6 weeks ago
rpg-cliorphan, rust-sig1 weeks ago
rubygem-cucumber-rails orphan  0 weeks ago
rubygem-database_cleaner   orphan  0 weeks ago
rubygem-ruby-ntlm  orphan  3 weeks ago
slim   aarem, orphan   4 weeks ago
sqlite3-dbforphan  4 weeks ago
ssh-contactorphan  2 weeks ago
telepathy-farstreamorphan  2 weeks ago
telepathy-idle orphan  2 weeks ago
telepathy-logger   orphan, rishi   2 weeks ago
teseq  orphan  4 weeks ago
trickleorphan, villadalmine, wolfy 4 weeks ago
uml_utilities  chkr, orphan7 weeks ago
vanessa_adtorphan   

Modularity: Default component references

[Petr Pisar]

I have a simple question and I don't know the answer:

What should a default value of a version-control-system reference for a module
component ("ref" value in modulemd YAML document) look like?


If a module document looks like this:

document: modulemd-packager
version: 3
data:
  name: A
  stream: B
  components:
rpms:
  foo:
rationale: API.
ref: C
  bar:
rationale: API.

there are people concerned with the missing "ref:" line for package "bar".
(Compare to "ref: C" for package "foo".) They want a sane default value so
they do not have to repeat it over and over again.

What's actually the default? Current specification

reads:

If no ref is given, the build system is permitted to make reasonable
assumptions about the correct default value. Otherwise, the fall-back is
the default branch for the git repository (commonly 'master').

So the specification is clear that it's implementation-defined. (I.e. how MBS
is configured.) But there are two concerns:

(1) "master" is not a good default for Fedora because Fedora renamed "master"
branch to "rawhide"/"main". MBS developers know about it and want to move to
"main" . The "main" would become
the "reasonable default value" configured in Fedora's MBS instance.

(2) There are people questioning even this git-ish "reasonable default value" 
,
. They would like to see the
component ref to default to a branch name of the module YAML file:

Whatever the name of the branch is in module repository, the same branch
must be used for the referred components. If there is not branch like this
for the specified component, then master is used.

What do say current packaging guidelines
?

using upstream major versions as branches is recommended

Well, that's a value no machine can figure out. That won't help us in
selecting a proper default for MBS. (Actually I saw a request to change the
recommended branch from an "upstream major version" to "stream-MODULE-STREAM"
with an explanation that the latter prevents from conflicts if multiple
modules want to include a different version of the package.)

What do packagers use in Fedora 36?

# zcat 
/var/cache/dnf/fedora-modular-f440a08391e7b71d/repodata/32db3716d3542119dfbb23f3880a7fcbf17e5720669de9570db941aedcf475a8-modules.yaml.gz
 | grep ref: |sort | uniq -c | sort -n -r
115 ref: f33
 56 ref: f34
 14 ref: rawhide
  5 ref: stream-postgresql-11
  3 ref: 1.22
  3 ref: stream-postgresql-12
  2 ref: 1.21
  2 ref: 1.20
  2 ref: 1
  2 ref: stream-6.0
  2 ref: latest
  1 ref: 9.2
  1 ref: 82lts
  1 ref: 8.10
  1 ref: 6.2
  1 ref: 6.1
  1 ref: 6.0
  1 ref: 5f5f293e
  1 ref: 4.0
  1 ref: 16
  1 ref: 14
  1 ref: 1.23
  1 ref: 1.14
  1 ref: 10.7
  1 ref: 10.6
  1 ref: 10.5
  1 ref: stream-1.20
  1 ref: stream-postgresql-14
  1 ref: stream-postgresql-10
  1 ref: stream-mainline
  1 ref: nextcloud-22
  1 ref: nextcloud-21
  1 ref: nextcloud-19
  1 ref: nextcloud-18
  1 ref: nextcloud-stable
  1 ref: mariadb-10.7
  1 ref: mariadb-10.6
  1 ref: mariadb-10.5

Plenty of them refer to a Fedora release branch (f34), a large amount of them
point to Rawhide, the rest uses a stream value or module-stream value.


As we can see, different people have different opinions. Based on that I was
thinking about adding a new top-level "ref" into modulemd-packager-v3 format.
A packager could define it's own default value. Moreover, it could
support some kind of templating like this:

data:
  name: NAME
  stream: STREAM
  configurations:
- context: CONTEXT
  platform: PLATFORM
  buildopts:
ref: stream-%n-%s-%c-%p
  components:
rpms:
  foo:
ref: A_GIT_TREE_ISH
  bar:

would expand to:

  components:
rpms:
  foo:
ref: A_GIT_TREE_ISH
  bar:
ref: stream-NAME-STREAM-CONTEXT-PLATFORM

That would address this request  where
a packager wants use different braches for different Fedora (platform)
versions. There could be a formatting string "%b" expanding to a branch name
the module document. However, this new 

Re: libxml2 or expat regression in Rawhide?

[Miro Hrončok]

On 22. 02. 22 14:13, Miro Hrončok wrote:

On 22. 02. 22 14:05, Miro Hrončok wrote:

On 22. 02. 22 13:06, Miro Hrončok wrote:

On 22. 02. 22 12:29, Miro Hrončok wrote:

On 22. 02. 22 12:26, Tomas Korbar wrote:

Hi Miro,
Very interesting. This is the latest upstream version of expat and
nothing was suggesting that there could be such issues.
I will start to look for the cause of this immediately.


Thanks.

I see that there is a build of expect for Fedora 35. I've tagged the build 
to a side tag (f35-build-side-51003) and will try to rebuild Pythons there. 
That should give us some information whether the failures are caused by 
expact or libxml2.


Looks like it is caused by expat.


In f35-build-side-51003 i.e. in Fedora 35 with expat-2.4.6-1.fc35, Python FTBFS

In f37-build-side-51005 i.e. in Fedora 37 with expact downgraded to 
2.4.4-1.fc36, Python builds successfully.


And finally in f37-build-side-51007 i.e. in Fedora 37 with libxml2 downgraded 
to 2.9.12-7.fc36 but with expat-2.4.6-1.fc37, Python FTBFS again.



So, apparently, this is a problem in the Python test suite and not expat itself.

https://bugs.python.org/issue46811 has fixes for Python >= 3.7.


And https://bugzilla.redhat.com/show_bug.cgi?id=2056970 is the downstream 
bugzilla.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libxml2 or expat regression in Rawhide?

[Miro Hrončok]

On 22. 02. 22 14:05, Miro Hrončok wrote:

On 22. 02. 22 13:06, Miro Hrončok wrote:

On 22. 02. 22 12:29, Miro Hrončok wrote:

On 22. 02. 22 12:26, Tomas Korbar wrote:

Hi Miro,
Very interesting. This is the latest upstream version of expat and
nothing was suggesting that there could be such issues.
I will start to look for the cause of this immediately.


Thanks.

I see that there is a build of expect for Fedora 35. I've tagged the build 
to a side tag (f35-build-side-51003) and will try to rebuild Pythons there. 
That should give us some information whether the failures are caused by 
expact or libxml2.


Looks like it is caused by expat.


In f35-build-side-51003 i.e. in Fedora 35 with expat-2.4.6-1.fc35, Python FTBFS

In f37-build-side-51005 i.e. in Fedora 37 with expact downgraded to 
2.4.4-1.fc36, Python builds successfully.


And finally in f37-build-side-51007 i.e. in Fedora 37 with libxml2 downgraded 
to 2.9.12-7.fc36 but with expat-2.4.6-1.fc37, Python FTBFS again.



So, apparently, this is a problem in the Python test suite and not expat itself.

https://bugs.python.org/issue46811 has fixes for Python >= 3.7.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libxml2 or expat regression in Rawhide?

[Miro Hrončok]

On 22. 02. 22 13:06, Miro Hrončok wrote:

On 22. 02. 22 12:29, Miro Hrončok wrote:

On 22. 02. 22 12:26, Tomas Korbar wrote:

Hi Miro,
Very interesting. This is the latest upstream version of expat and
nothing was suggesting that there could be such issues.
I will start to look for the cause of this immediately.


Thanks.

I see that there is a build of expect for Fedora 35. I've tagged the build to 
a side tag (f35-build-side-51003) and will try to rebuild Pythons there. That 
should give us some information whether the failures are caused by expact or 
libxml2.


Looks like it is caused by expat.


In f35-build-side-51003 i.e. in Fedora 35 with expat-2.4.6-1.fc35, Python FTBFS

In f37-build-side-51005 i.e. in Fedora 37 with expact downgraded to 
2.4.4-1.fc36, Python builds successfully.


And finally in f37-build-side-51007 i.e. in Fedora 37 with libxml2 downgraded 
to 2.9.12-7.fc36 but with expat-2.4.6-1.fc37, Python FTBFS again.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libxml2 or expat regression in Rawhide?

[Miro Hrončok]

On 22. 02. 22 12:29, Miro Hrončok wrote:

On 22. 02. 22 12:26, Tomas Korbar wrote:

Hi Miro,
Very interesting. This is the latest upstream version of expat and
nothing was suggesting that there could be such issues.
I will start to look for the cause of this immediately.


Thanks.

I see that there is a build of expect for Fedora 35. I've tagged the build to a 
side tag (f35-build-side-51003) and will try to rebuild Pythons there. That 
should give us some information whether the failures are caused by expact or 
libxml2.


Looks like it is caused by expat.


Thanks for bringing this to my attention.

On Tue, Feb 22, 2022 at 12:25 PM Miro Hrončok  wrote:


On 22. 02. 22 12:20, Miro Hrončok wrote:

Hello Dave and Tomas,

I see in Koschei that since libxml2 has been upgraded from 2.9.12-7.fc36 to
2.9.13-1.fc37 [1] and expat has been upgraded from 2.4.4-1.fc36 to 
2.4.6-1.fc37

[2], Python fails to build (as well as many other packages).

The Python test failures are:

==
ERROR: testEncodings (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
    File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line
1150, in testEncodings
  self.assertRaises(UnicodeDecodeError, parseString,
    File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 816,
in assertRaises
  return context.handle('assertRaises', args, kwargs)
    File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 202,
in handle
  callable_obj(*args, **kwargs)
    File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line
1969, in parseString
  return expatbuilder.parseString(string)
    File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", 
line

925, in parseString
  return builder.parseString(string)
    File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", 
line

223, in parseString
  parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, 
column 5


==
ERROR: testExceptionOnSpacesInXMLNSValue (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
    File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line
1597, in testExceptionOnSpacesInXMLNSValue
  parseString('')
    File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line
1969, in parseString
  return expatbuilder.parseString(string)
    File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", 
line

925, in parseString
  return builder.parseString(string)
    File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", 
line

223, in parseString
  parser.Parse(string, True)
xml.parsers.expat.ExpatError: syntax error: line 1, column 0
--

==
ERROR: test_issue3151 (test.test_xml_etree.BugsTest)
--
Traceback (most recent call last):
    File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_xml_etree.py", 
line

1972, in test_issue3151
  e = ET.XML('')
    File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/etree/ElementTree.py",
line 1320, in XML
  parser.feed(text)
xml.etree.ElementTree.ParseError: syntax error: line 1, column 0
--

Is it possible that libxml2 or expat (or both) have a regression that causes a
previously valid XML document to fail to parse?

[1]
https://koschei.fedoraproject.org/affected-by/libxml2-devel?epoch1=0=2.9.12=7.fc36=0=2.9.13=1.fc37=f37 



[2]
https://koschei.fedoraproject.org/affected-by/expat-devel?epoch1=0=2.4.4=1.fc36=0=2.4.6=1.fc37=f37 



This also happens on Fedora 36:

https://koschei.fedoraproject.org/affected-by/libxml2?epoch1=0=2.9.12=7.fc36=0=2.9.13=1.fc36=f36 

https://koschei.fedoraproject.org/affected-by/expat-devel?epoch1=0=2.4.4=1.fc36=0=2.4.6=1.fc36=f36 



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok







--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2034031] Please branch and build perl-Image-Size for epel9

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2034031

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-6c6a27be5e has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6c6a27be5e


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2034031
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing account takeovers through expired domains

[Daniel P . Berrangé]

On Sun, Feb 20, 2022 at 04:08:43PM -0800, Adam Williamson wrote:
> On Sun, 2022-02-20 at 16:42 +, Gary Buhrmaster wrote:
> > Unfortunately, last I checked, the FAS account
> > system did not support adding something
> > like a FIDO2 security key to an account(**).
> > Even if it did, I suspect not all the other parts
> > of the system would support FIDO keys.
> 
> It used to support these, but the support was lost with the recent
> rewrite. However, it supports Google Authenticator-style OTPs. Folks
> with infra privileges on their accounts (like me) are already required
> to use these. It works fine. I preferred being able to use a yubikey so
> I don't always have to open an app on my phone and retype a six digit
> code when I need to log in to something, but that's just a minor
> annoyance.

Given that the accounts system already supports these OTPs, what
is the reason for not mandating this OTP based 2FA for *all*
contributors today, as oppposed to merely infra people ?

We know that Fedora contributors have had their passwords compromised
in the past [1], so not using 2FA of any kind is a risk to Fedora.

I understand these simple OTPs are not as secure as FIDO2, but
they have the clear advantage of actually being supported in
Fedora's auth system today. These OTPs are good enough that 1000's
of companies globally use them, rather than relying on plain passwords
only.

By all means have FIDO2 supported as the desired long term goal, but
it feels dubious to stick with only plain passwords in the meantime.
FIDO2 support requires significant dev work on a service that is not
under Fedora's control and make take many many years to arrive in a
form that is usable.

With regards,
Daniel

[1] https://lists.fedoraproject.org/pipermail/announce/2011-January/002911.html
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libxml2 or expat regression in Rawhide?

[Miro Hrončok]

On 22. 02. 22 12:26, Tomas Korbar wrote:

Hi Miro,
Very interesting. This is the latest upstream version of expat and
nothing was suggesting that there could be such issues.
I will start to look for the cause of this immediately.


Thanks.

I see that there is a build of expect for Fedora 35. I've tagged the build to a 
side tag (f35-build-side-51003) and will try to rebuild Pythons there. That 
should give us some information whether the failures are caused by expact or 
libxml2.



Thanks for bringing this to my attention.

On Tue, Feb 22, 2022 at 12:25 PM Miro Hrončok  wrote:


On 22. 02. 22 12:20, Miro Hrončok wrote:

Hello Dave and Tomas,

I see in Koschei that since libxml2 has been upgraded from 2.9.12-7.fc36 to
2.9.13-1.fc37 [1] and expat has been upgraded from 2.4.4-1.fc36 to 2.4.6-1.fc37
[2], Python fails to build (as well as many other packages).

The Python test failures are:

==
ERROR: testEncodings (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line
1150, in testEncodings
  self.assertRaises(UnicodeDecodeError, parseString,
File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 816,
in assertRaises
  return context.handle('assertRaises', args, kwargs)
File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 202,
in handle
  callable_obj(*args, **kwargs)
File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line
1969, in parseString
  return expatbuilder.parseString(string)
File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line
925, in parseString
  return builder.parseString(string)
File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line
223, in parseString
  parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 5

==
ERROR: testExceptionOnSpacesInXMLNSValue (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line
1597, in testExceptionOnSpacesInXMLNSValue
  parseString('')
File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line
1969, in parseString
  return expatbuilder.parseString(string)
File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line
925, in parseString
  return builder.parseString(string)
File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line
223, in parseString
  parser.Parse(string, True)
xml.parsers.expat.ExpatError: syntax error: line 1, column 0
--

==
ERROR: test_issue3151 (test.test_xml_etree.BugsTest)
--
Traceback (most recent call last):
File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_xml_etree.py", line
1972, in test_issue3151
  e = ET.XML('')
File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/etree/ElementTree.py",
line 1320, in XML
  parser.feed(text)
xml.etree.ElementTree.ParseError: syntax error: line 1, column 0
--

Is it possible that libxml2 or expat (or both) have a regression that causes a
previously valid XML document to fail to parse?

[1]
https://koschei.fedoraproject.org/affected-by/libxml2-devel?epoch1=0=2.9.12=7.fc36=0=2.9.13=1.fc37=f37

[2]
https://koschei.fedoraproject.org/affected-by/expat-devel?epoch1=0=2.4.4=1.fc36=0=2.4.6=1.fc37=f37


This also happens on Fedora 36:

https://koschei.fedoraproject.org/affected-by/libxml2?epoch1=0=2.9.12=7.fc36=0=2.9.13=1.fc36=f36
https://koschei.fedoraproject.org/affected-by/expat-devel?epoch1=0=2.4.4=1.fc36=0=2.4.6=1.fc36=f36

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok





--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libxml2 or expat regression in Rawhide?

[Tomas Korbar]

Hi Miro,
Very interesting. This is the latest upstream version of expat and
nothing was suggesting that there could be such issues.
I will start to look for the cause of this immediately.

Thanks for bringing this to my attention.

On Tue, Feb 22, 2022 at 12:25 PM Miro Hrončok  wrote:
>
> On 22. 02. 22 12:20, Miro Hrončok wrote:
> > Hello Dave and Tomas,
> >
> > I see in Koschei that since libxml2 has been upgraded from 2.9.12-7.fc36 to
> > 2.9.13-1.fc37 [1] and expat has been upgraded from 2.4.4-1.fc36 to 
> > 2.4.6-1.fc37
> > [2], Python fails to build (as well as many other packages).
> >
> > The Python test failures are:
> >
> > ==
> > ERROR: testEncodings (test.test_minidom.MinidomTest)
> > --
> > Traceback (most recent call last):
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line
> > 1150, in testEncodings
> >  self.assertRaises(UnicodeDecodeError, parseString,
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 
> > 816,
> > in assertRaises
> >  return context.handle('assertRaises', args, kwargs)
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 
> > 202,
> > in handle
> >  callable_obj(*args, **kwargs)
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line
> > 1969, in parseString
> >  return expatbuilder.parseString(string)
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", 
> > line
> > 925, in parseString
> >  return builder.parseString(string)
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", 
> > line
> > 223, in parseString
> >  parser.Parse(string, True)
> > xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, 
> > column 5
> >
> > ==
> > ERROR: testExceptionOnSpacesInXMLNSValue (test.test_minidom.MinidomTest)
> > --
> > Traceback (most recent call last):
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line
> > 1597, in testExceptionOnSpacesInXMLNSValue
> >  parseString(' > />')
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line
> > 1969, in parseString
> >  return expatbuilder.parseString(string)
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", 
> > line
> > 925, in parseString
> >  return builder.parseString(string)
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", 
> > line
> > 223, in parseString
> >  parser.Parse(string, True)
> > xml.parsers.expat.ExpatError: syntax error: line 1, column 0
> > --
> >
> > ==
> > ERROR: test_issue3151 (test.test_xml_etree.BugsTest)
> > --
> > Traceback (most recent call last):
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_xml_etree.py", 
> > line
> > 1972, in test_issue3151
> >  e = ET.XML('')
> >File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/etree/ElementTree.py",
> > line 1320, in XML
> >  parser.feed(text)
> > xml.etree.ElementTree.ParseError: syntax error: line 1, column 0
> > --
> >
> > Is it possible that libxml2 or expat (or both) have a regression that 
> > causes a
> > previously valid XML document to fail to parse?
> >
> > [1]
> > https://koschei.fedoraproject.org/affected-by/libxml2-devel?epoch1=0=2.9.12=7.fc36=0=2.9.13=1.fc37=f37
> >
> > [2]
> > https://koschei.fedoraproject.org/affected-by/expat-devel?epoch1=0=2.4.4=1.fc36=0=2.4.6=1.fc37=f37
>
> This also happens on Fedora 36:
>
> https://koschei.fedoraproject.org/affected-by/libxml2?epoch1=0=2.9.12=7.fc36=0=2.9.13=1.fc36=f36
> https://koschei.fedoraproject.org/affected-by/expat-devel?epoch1=0=2.4.4=1.fc36=0=2.4.6=1.fc36=f36
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libxml2 or expat regression in Rawhide?

[Miro Hrončok]

On 22. 02. 22 12:20, Miro Hrončok wrote:

Hello Dave and Tomas,

I see in Koschei that since libxml2 has been upgraded from 2.9.12-7.fc36 to 
2.9.13-1.fc37 [1] and expat has been upgraded from 2.4.4-1.fc36 to 2.4.6-1.fc37 
[2], Python fails to build (as well as many other packages).


The Python test failures are:

==
ERROR: testEncodings (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
   File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line 
1150, in testEncodings

     self.assertRaises(UnicodeDecodeError, parseString,
   File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 816, 
in assertRaises

     return context.handle('assertRaises', args, kwargs)
   File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 202, 
in handle

     callable_obj(*args, **kwargs)
   File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line 
1969, in parseString

     return expatbuilder.parseString(string)
   File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line 
925, in parseString

     return builder.parseString(string)
   File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line 
223, in parseString

     parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 5

==
ERROR: testExceptionOnSpacesInXMLNSValue (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
   File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line 
1597, in testExceptionOnSpacesInXMLNSValue
     parseString('/>')
   File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line 
1969, in parseString

     return expatbuilder.parseString(string)
   File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line 
925, in parseString

     return builder.parseString(string)
   File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line 
223, in parseString

     parser.Parse(string, True)
xml.parsers.expat.ExpatError: syntax error: line 1, column 0
--

==
ERROR: test_issue3151 (test.test_xml_etree.BugsTest)
--
Traceback (most recent call last):
   File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_xml_etree.py", line 
1972, in test_issue3151

     e = ET.XML('')
   File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/etree/ElementTree.py", 
line 1320, in XML

     parser.feed(text)
xml.etree.ElementTree.ParseError: syntax error: line 1, column 0
--

Is it possible that libxml2 or expat (or both) have a regression that causes a 
previously valid XML document to fail to parse?


[1] 
https://koschei.fedoraproject.org/affected-by/libxml2-devel?epoch1=0=2.9.12=7.fc36=0=2.9.13=1.fc37=f37 

[2] 
https://koschei.fedoraproject.org/affected-by/expat-devel?epoch1=0=2.4.4=1.fc36=0=2.4.6=1.fc37=f37 


This also happens on Fedora 36:

https://koschei.fedoraproject.org/affected-by/libxml2?epoch1=0=2.9.12=7.fc36=0=2.9.13=1.fc36=f36
https://koschei.fedoraproject.org/affected-by/expat-devel?epoch1=0=2.4.4=1.fc36=0=2.4.6=1.fc36=f36

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

libxml2 or expat regression in Rawhide?

[Miro Hrončok]

Hello Dave and Tomas,

I see in Koschei that since libxml2 has been upgraded from 2.9.12-7.fc36 to 
2.9.13-1.fc37 [1] and expat has been upgraded from 2.4.4-1.fc36 to 2.4.6-1.fc37 
[2], Python fails to build (as well as many other packages).


The Python test failures are:

==
ERROR: testEncodings (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line 
1150, in testEncodings

self.assertRaises(UnicodeDecodeError, parseString,
  File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 816, 
in assertRaises

return context.handle('assertRaises', args, kwargs)
  File "/builddir/build/BUILD/Python-3.8.12/Lib/unittest/case.py", line 202, 
in handle

callable_obj(*args, **kwargs)
  File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line 
1969, in parseString

return expatbuilder.parseString(string)
  File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line 
925, in parseString

return builder.parseString(string)
  File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line 
223, in parseString

parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 5

==
ERROR: testExceptionOnSpacesInXMLNSValue (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_minidom.py", line 
1597, in testExceptionOnSpacesInXMLNSValue
parseString('/>')
  File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/minidom.py", line 
1969, in parseString

return expatbuilder.parseString(string)
  File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line 
925, in parseString

return builder.parseString(string)
  File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/dom/expatbuilder.py", line 
223, in parseString

parser.Parse(string, True)
xml.parsers.expat.ExpatError: syntax error: line 1, column 0
--

==
ERROR: test_issue3151 (test.test_xml_etree.BugsTest)
--
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.8.12/Lib/test/test_xml_etree.py", line 
1972, in test_issue3151

e = ET.XML('')
  File "/builddir/build/BUILD/Python-3.8.12/Lib/xml/etree/ElementTree.py", 
line 1320, in XML

parser.feed(text)
xml.etree.ElementTree.ParseError: syntax error: line 1, column 0
--

Is it possible that libxml2 or expat (or both) have a regression that causes a 
previously valid XML document to fail to parse?


[1] 
https://koschei.fedoraproject.org/affected-by/libxml2-devel?epoch1=0=2.9.12=7.fc36=0=2.9.13=1.fc37=f37
[2] 
https://koschei.fedoraproject.org/affected-by/expat-devel?epoch1=0=2.4.4=1.fc36=0=2.4.6=1.fc37=f37


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM spec feedback directly in your editor

[Andreas Schneider]

On Tuesday, February 22, 2022 9:29:49 AM CET Ondrej Mosnacek wrote:
> > What is currently missing in rpmspec is support to parse the input form
> > stdin
 instead of a file [2]. But there is already a PR to support it
> > [3].
> 
> `rpmspec -P /dev/stdin` seems to work already now. I use this "trick"
> all the time with programs that don't support stdin/stdout natively.
> (Sometimes even that doesn't work, e.g. if the program tries to seek
> or mmap it, but often it does.)

I think it only works if a shell is involved. If I try it rpmspec reports:

error: Unable to open /dev/stdin: No such device or address

as lua does execv() on rpmspec.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-36-20220221.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 13/229 (x86_64), 17/161 (aarch64)

New failures (same test not failed in Fedora-36-20220220.n.0):

ID: 1140429 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1140429
ID: 1140437 Test: x86_64 Silverblue-dvd_ostree-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/1140437
ID: 1140502 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1140502

Old failures (same test failed in Fedora-36-20220220.n.0):

ID: 1140400 Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/1140400
ID: 1140405 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1140405
ID: 1140438 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1140438
ID: 1140439 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/1140439
ID: 1140521 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1140521
ID: 1140522 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1140522
ID: 1140526 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1140526
ID: 1140528 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/1140528
ID: 1140529 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1140529
ID: 1140556 Test: x86_64 Workstation-upgrade desktop_background
URL: https://openqa.fedoraproject.org/tests/1140556
ID: 1140569 Test: aarch64 Workstation-upgrade desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/1140569
ID: 1140572 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1140572
ID: 1140573 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1140573
ID: 1140580 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1140580
ID: 1140581 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1140581
ID: 1140603 Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1140603
ID: 1140613 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1140613
ID: 1140681 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1140681
ID: 1140693 Test: aarch64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/1140693
ID: 1140698 Test: aarch64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/1140698
ID: 1140709 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1140709
ID: 1140710 Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1140710
ID: 1140711 Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1140711
ID: 1140729 Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/1140729
ID: 1140730 Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1140730
ID: 1140739 Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1140739
ID: 1140758 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1140758

Soft failed openQA tests: 15/229 (x86_64), 13/161 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-36-20220220.n.0):

ID: 1140399 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1140399
ID: 1140436 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1140436
ID: 1140444 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1140444
ID: 1140531 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1140531
ID: 1140542 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1140542
ID: 1140543 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1140543
ID: 1140565 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1140565
ID: 1140568 Test: aarch64 

Fedora-Rawhide-20220221.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
5 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 25/231 (x86_64), 24/161 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220220.n.0):

ID: 1139901 Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/1139901
ID: 1139913 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1139913
ID: 1140011 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1140011
ID: 1140128 Test: x86_64 Workstation-upgrade evince
URL: https://openqa.fedoraproject.org/tests/1140128
ID: 1140184 Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1140184
ID: 1140243 Test: aarch64 universal upgrade_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1140243
ID: 1140268 Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1140268
ID: 1140317 Test: aarch64 Server-dvd-iso install_updates_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/1140317

Old failures (same test failed in Fedora-Rawhide-20220220.n.0):

ID: 1139927 Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/1139927
ID: 1139949 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1139949
ID: 1139955 Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1139955
ID: 1139959 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1139959
ID: 1139962 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1139962
ID: 1139965 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1139965
ID: 1139968 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1139968
ID: 1140001 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1140001
ID: 1140047 Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/1140047
ID: 1140067 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1140067
ID: 1140068 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1140068
ID: 1140086 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1140086
ID: 1140087 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1140087
ID: 1140091 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1140091
ID: 1140094 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1140094
ID: 1140096 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1140096
ID: 1140113 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1140113
ID: 1140114 Test: x86_64 Workstation-upgrade desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1140114
ID: 1140115 Test: x86_64 Workstation-upgrade 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1140115
ID: 1140122 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1140122
ID: 1140125 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1140125
ID: 1140133 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1140133
ID: 1140137 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1140137
ID: 1140138 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1140138
ID: 1140145 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1140145
ID: 1140146 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1140146
ID: 1140149 Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/1140149
ID: 1140159 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1140159
ID: 1140178 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1140178
ID: 1140208 Test: x86_64 

Fedora-Cloud-35-20220222.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-35-20220221.0):

ID: 1140763 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1140763
ID: 1140776 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1140776

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM spec feedback directly in your editor

[Ondrej Mosnacek]

On Tue, Feb 22, 2022 at 8:50 AM Andreas Schneider  wrote:
> Hi,
>
> I'm a big fan of neovim (emacs users jump to 'emacs:' ;-). neovim has support
> for the Language Server Protocol and there is a nice plugin called 'null-ls'
> [1] which allows you to hook linters and formatters into neovim.
>
> I've added support for rpmspec in 'null-ls' so you can get feedback directly
> while editing a spec file. See the attached screenshot.
>
> How to configure it:
>
> ```
> local ok, null_ls = pcall(require, 'null-ls')
> if not ok then
> return
> end
> local sources = {}
>
> if vim.fn.executable('rpmspec') == 1 then
> table.insert(sources, null_ls.builtins.diagnostics.rpmspec)
> end
>
> null_ls.setup({
> debug = false,
> sources = sources,
> })
> ```
>
> What is currently missing in rpmspec is support to parse the input form stdin
> instead of a file [2]. But there is already a PR to support it [3].

`rpmspec -P /dev/stdin` seems to work already now. I use this "trick"
all the time with programs that don't support stdin/stdout natively.
(Sometimes even that doesn't work, e.g. if the program tries to seek
or mmap it, but often it does.)

>
> Best regards
>
>
> Andreas
>
>
> [1] https://github.com/jose-elias-alvarez/null-ls.nvim/
> [2] https://github.com/rpm-software-management/rpm/issues/1926
> [3] https://github.com/rpm-software-management/rpm/pull/1928


-- 
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing account takeovers through expired domains

[Vitaly Zaitsev via devel]

On 22/02/2022 04:17, Ian McInerney via devel wrote:
The only viable option I see for requiring the use of hardware keys 
would be if RedHat (or another sponsor) provided them to packagers when 
needed.


There is another problem - the US export/sanctions policies. You can't 
ship such cryptographic devices to contributors in sanctioned regions.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing account takeovers through expired domains

[Vitaly Zaitsev via devel]

On 22/02/2022 03:14, Demi Marie Obenour wrote:

Developing a roadmap to encourage, and eventually require, the use of
hardware authenticators to submit packages is a reasonable precaution
in this threat environment.  A hardware authenticator could be a FIDO2
token, smart card, etc.


Who will pay for this equipment?

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure