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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 24, 2022 at 12:17:27AM +, Gary Buhrmaster wrote:
> On Wed, Feb 23, 2022 at 11:55 PM Chris Adams  wrote:
> >
> > Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > > So this is the culprit. iscsi.service has Before=remote-fs-pre.target,
> > > After=network-online.target, which means that it'll delay the boot.
> >
> > If that's the problem, there's some other issue.  On my up-to-date F35
> > system, iscsi.service also has:
> >
> > ConditionDirectoryNotEmpty=/var/lib/iscsi/nodes
> >
> > And on my systems, that directory is empty, so iscsi.service shouldn't
> > be holding up anything.

Conditions are evaluated when the service would be exectued, so a unit
which is (eventually) skipped because of Conditions still has effect on
the boot ordering and may add additional jobs to the transaction.

systemd.unit(5) says:

  The conditions and asserts are checked at the time the queued
  start job is to be executed. The ordering dependencies are
  still respected, so other units are still pulled in and ordered
  as if this unit was successfully activated, and the conditions
  and asserts are executed the precise moment the unit would
  normally start and thus can validate system state after the
  units ordered before completed initialization.

> How can one be sure that (in the general case) that one of the units
> that you are running After will not create the files/directories
> that will impact the test Condition(s)?

We aren't. In fact the conditions are checked later as described above.

> Those tests occur before the unit is actually started, but not
> before the ordering is performed.

Yes.

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: future of dual-boot on the desktop

[Gary Buhrmaster]

On Thu, Feb 24, 2022 at 12:56 AM Chris Murphy  wrote:

> And my understanding is it's required for
> Windows 11 preinstallations.

Except if your country has required that TPM not
be used, and as Microsoft did not want to prevent
billions of people from using Windows 11 those
locations are exempt from the requirements.
___
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: future of dual-boot on the desktop

[Kevin Kofler via devel]

Chris Murphy wrote:
> A work around is having GRUB set an NVRAM variable indicating the next
> boot should be Windows. That's an instruction to the firmware, so
> there's no intermediary, thus measured boot works. The next boot (from
> Windows) would boot Fedora again. GRUB can't get or set EFI variables
> yet. systemd-boot, meanwhile, will be supporting BootNext in their
> next release.

So, can we not, in GRUB, instead of chainloading the Windows bootloader, 
chainload a systemd-boot copy preconfigured to BootNext to Windows?

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

future of dual-boot on the desktop

[Chris Murphy]

Hi,

Dual boot has been a pretty important use case for Fedora Workstation
edition and the desktop spins.

There are final release criterion that apply to Windows and macOS
(notably not Fedora itself or any other Linux distros):
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual_boot
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#OS_X_dual_boot

The subtle difference is the Windows release criterion requires the
bootloader to also boot Windows, not just Fedora. So what this thread
is about, is that. The installer can still install to free space. The
problem is how to boot it afterward? For macOS, Macs have a built-in
graphical boot manager, mactel-boot installs some things that enable
the Mac firmware to see Fedora, and we boot that way, rather than via
the GRUB menu. For Windows, we use a Windows menu entry in GRUB.
That's the main problem.

Pretty much all recent Windows 10 pre-installed systems that have a
TPM 2.0 chip and Modern Standby, are coming with Bitlocker enabled.
This is Windows' software disk encryption. The gist is to use measured
boot to verify the boot chain has not been tampered with. And if it
hasn't been tampered with, the TPM will unseal the Bitlocker
encryption key and you boot.

The problem is shim and GRUB as intermediaries results in measured
boot failing. And the user sees a Windows blue screen asking for a
Bitlocker Recovery key. My Lenovo Thinkpad (gen 7, circa late 2020)
came with this preinstalled. And my understanding is it's required for
Windows 11 preinstallations.

This problem is, per release criterion as currently written, a
(conditional) blocker. It's conditional, because we don't yet know the
scope of users affected. And also it's going to be too hard to fix in
the Fedora 36 release cycle.
https://bugzilla.redhat.com/show_bug.cgi?id=2049849

A work around is having GRUB set an NVRAM variable indicating the next
boot should be Windows. That's an instruction to the firmware, so
there's no intermediary, thus measured boot works. The next boot (from
Windows) would boot Fedora again. GRUB can't get or set EFI variables
yet. systemd-boot, meanwhile, will be supporting BootNext in their
next release.

I posted an inquiry on the grub-devel list:
https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00072.html

Anyway, so far it's not clear to me that upstream GRUB has interest in
making this work.

Still another work around is merely using `sudo efibootmgr --bootnext
$windowsentry`  and rebooting. Or what about the desktop restart
dialog detecting the presence of Windows, by looking at NVRAM for an
entry, and presenting an option to do a one time boot of Windows?

How important is this?

-- 
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: Is NetworkManager-wait-online.service necessary by default?

[Gary Buhrmaster]

On Wed, Feb 23, 2022 at 11:55 PM Chris Adams  wrote:
>
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > So this is the culprit. iscsi.service has Before=remote-fs-pre.target,
> > After=network-online.target, which means that it'll delay the boot.
>
> If that's the problem, there's some other issue.  On my up-to-date F35
> system, iscsi.service also has:
>
> ConditionDirectoryNotEmpty=/var/lib/iscsi/nodes
>
> And on my systems, that directory is empty, so iscsi.service shouldn't
> be holding up anything.

How can one be sure that (in the general case) that
one of the units that you are running After will not
create the files/directories that will impact the test
Condition(s)?  Those tests occur before the unit
is actually started, but not before the ordering is
performed.
___
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 Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> So this is the culprit. iscsi.service has Before=remote-fs-pre.target,
> After=network-online.target, which means that it'll delay the boot.

If that's the problem, there's some other issue.  On my up-to-date F35
system, iscsi.service also has:

ConditionDirectoryNotEmpty=/var/lib/iscsi/nodes

And on my systems, that directory is empty, so iscsi.service shouldn't
be holding up anything.
-- 
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: GNOME only: KeepassXC quirks

[Germano Massullo]

This problem should have been fixed with commit
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=dda7dab8274991e4a61a97c352d4367f8f815bb9
after checking which Qt version includes such commit, I will remove 
xcb.patch [1] and release a new keepassxc release to test its behaviour


[1]: https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch
___
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: Devtoolset for epel7 for build in Copr

[Dmitry Butskoy]

Kevin Kofler via devel wrote:

I guess the easiest workaround would be to create an llvm-toolset-11.0 Copr
and to build llvm-toolset-11.0-*.src.rpm from:
http://springdale.princeton.edu/data/springdale/SCL/7/SRPMS/
in it.
Unfortunately, the rebiuld of all the llvm-toolset stuff from the 
sources is hard enough thing (a lot of cpu resources, disk space etc.).


Anyway, why the additional repo is used not for rpmbuild time only, but 
for creating the initial build system environment too? Whether the 
proper RHEL/CentOS repos plus EPEL should be enough for it?



~buc
___
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: Devtoolset for epel7 for build in Copr

[Kevin Kofler via devel]

Dmitry Butskoy wrote:
> Second, the alternate Springdale Linux repo
> http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ seems to
> have all the ones (which are provided in sources by RedHat), but cannot
> be used in Copr. Springdale provides devtoolset-3-elfutils there, and it
> in some strange way  badly correlates with the initial Copr build
> environment (even before the rpmbuild process starts). Some python2
> module cannot find libelf.so.1 ...

The problem there is that they stuff all SCLs into one single repo instead 
of one per SCL, and that Copr only allows you to input a baseurl for the 
repo and not a complete mock config group with includepkgs= or excludepkgs= 
options (which would be needed to filter what you actually want from the 
repo).

I guess the easiest workaround would be to create an llvm-toolset-11.0 Copr 
and to build llvm-toolset-11.0-*.src.rpm from:
http://springdale.princeton.edu/data/springdale/SCL/7/SRPMS/
in it. (I believe you can point Copr directly to the SRPM URLs, so you do 
not even have to download and upload them.) Then it can be referenced from 
your Copr using a copr: reference.

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-20220223.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

New failures (same test not failed in Fedora-36-20220222.n.1):

ID: 1143760 Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/1143760
ID: 1143776 Test: aarch64 universal install_kickstart_hdd@uefi
URL: https://openqa.fedoraproject.org/tests/1143776
ID: 1143804 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1143804
ID: 1143822 Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1143822

Old failures (same test failed in Fedora-36-20220222.n.1):

ID: 1143519 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1143519
ID: 1143520 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1143520
ID: 1143552 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1143552
ID: 1143616 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1143616
ID: 1143635 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1143635
ID: 1143636 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1143636
ID: 1143640 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1143640
ID: 1143642 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/1143642
ID: 1143643 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1143643
ID: 1143686 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1143686
ID: 1143687 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1143687
ID: 1143694 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1143694
ID: 1143695 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1143695
ID: 1143716 Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/1143716
ID: 1143727 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1143727
ID: 1143795 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1143795
ID: 1143823 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1143823
ID: 1143824 Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1143824
ID: 1143946 Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1143946
ID: 1143955 Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1143955
ID: 1143956 Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1143956
ID: 1143974 Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/1143974
ID: 1144006 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1144006

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

New soft failures (same test not soft failed in Fedora-36-20220222.n.1):

ID: 1143704 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1143704
ID: 1143733 Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1143733
ID: 1143779 Test: aarch64 universal upgrade_2_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1143779

Old soft failures (same test soft failed in Fedora-36-20220222.n.1):

ID: 1143513 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1143513
ID: 1143550 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1143550
ID: 1143558 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1143558
ID: 1143645 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1143645
ID: 1143656 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1143656
ID: 1143657 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1143657
ID: 1143679 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org

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

[Tom Hughes via devel]

On 23/02/2022 21:23, Zbigniew Jędrzejewski-Szmek wrote:


a) change libvirt-daemon-driver-storage 
Requires:libvirt-daemon-driver-storage-iscsi
to Suggests:libvirt-daemon-driver-storage-iscsi,


More generally why does installing libvirt neeed to force
installation of about ten storage drivers and all their
dependencies - why can't the user choose to remove some of
the more obscure ones?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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?

[Michael Catanzaro]

On Wed, Feb 23 2022 at 10:23:14 PM +0100, Zbigniew Jędrzejewski-Szmek 
 wrote:

I'd vote for a)


Me too.

I have a feeling this is going to dramatically improve our boot times. 
Shame we didn't notice this long ago. Oh well


___
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

[Samuel Sieb]

On 2/23/22 08:54, Andreas Schneider wrote:

On Tuesday, February 22, 2022 7:41:16 PM CET Artur Frenszek-Iwicki wrote:

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


How about "/proc/self/fd/0"?


Nope doesn't work ... /dev/stdin is a symlink to /proc/self/fd/0. I wonder if
this is only available with a shell ...


That has nothing to do with the shell.  It's a kernel filesystem thing. 
 You could try executing a shell script that dumps the available file 
descriptors to see what's happening.

___
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-IoT-36-20220223.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

ID: 1143988 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/1143988
ID: 1143990 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/1143990

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

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

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

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

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

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

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

ID: 1143979 Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/1143979
ID: 1144000 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/1144000

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.23 to 0.40
Previous test data: https://openqa.fedoraproject.org/tests/1142613#downloads
Current test data: https://openqa.fedoraproject.org/tests/1143992#downloads
-- 
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: Need advice on NET_ADMIN capability on a binary (iotop-c)

[przemek klosowski via devel]

On 2/22/22 12:14, Boian Bonev wrote:

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.


> 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.

It's a clever idea but I've never seen packaging used this way. I think 
you're saying that the default installation of iotop-c would have 
limited capability, and installing the second package would anoint iotop 
with the full set of privileges.


Using packaging for this is clever but unintuitive; do we really want to 
start it as a new trend? Traditionally, stuff like that was mentioned in 
release notes and done as an adiministrative commandline action. Is 
there a precedent for using packaging this way?

___
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?

[Kevin P. Fleming]

On Wed, Feb 23, 2022 at 4:25 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> So this is the culprit. iscsi.service has Before=remote-fs-pre.target,
> After=network-online.target, which means that it'll delay the boot.
> remote-fs-pre.target is Before remote-fs.target which is Before
> multi-user.target.
> (Also see the chart in bootup(7).)
>
> There's a chain of deps that goes all the way to gnome-boxes and tmt:
> iscsi-initiator-utils ← libvirt-daemon-driver-storage-iscsi ←
> libvirt-daemon-driver-storage ← libvirt-daemon-kvm ← gnome-boxes,
>
> iscsi-initiator-utils ← libvirt-daemon-driver-storage-iscsi ←
> libvirt-daemon-driver-storage ← libvirt ← python3-testcloud ←
> tmt-provision-virtual
> ← tmt-all.
>
> At least the dependency in gnome-boxes means it'll be installed
> e.g. on Workstation.
>
> I see three+ solutions:
> a) change libvirt-daemon-driver-storage
> Requires:libvirt-daemon-driver-storage-iscsi
>to Suggests:libvirt-daemon-driver-storage-iscsi,
> b) change the preset for iscsi.service to disabled,
> c) drop the ordering in iscsi.service,
> d) some combination of the above
>
>
Can confirm; 'systemctl disable iscsi.service' and a reboot of my F35
laptop resulted in a GDM login prompt before the network connection had
even been completed.
___
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 08:26:22PM -0700, Chris Murphy wrote:
> 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).

So yeah, if you see the cylon eye, something is definitely wrong.

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

systemd[1]: iscsi.service: starting held back, waiting for: 
network-online.target

So this is the culprit. iscsi.service has Before=remote-fs-pre.target,
After=network-online.target, which means that it'll delay the boot.
remote-fs-pre.target is Before remote-fs.target which is Before 
multi-user.target.
(Also see the chart in bootup(7).)

There's a chain of deps that goes all the way to gnome-boxes and tmt:
iscsi-initiator-utils ← libvirt-daemon-driver-storage-iscsi ←
libvirt-daemon-driver-storage ← libvirt-daemon-kvm ← gnome-boxes,

iscsi-initiator-utils ← libvirt-daemon-driver-storage-iscsi ←
libvirt-daemon-driver-storage ← libvirt ← python3-testcloud ← 
tmt-provision-virtual
← tmt-all.

At least the dependency in gnome-boxes means it'll be installed
e.g. on Workstation.

I see three+ solutions:
a) change libvirt-daemon-driver-storage 
Requires:libvirt-daemon-driver-storage-iscsi
   to Suggests:libvirt-daemon-driver-storage-iscsi,
b) change the preset for iscsi.service to disabled,
c) drop the ordering in iscsi.service,
d) some combination of the above

I don't think we should have a service that delays boot in this way
installed and enabled by default. I'd vote for a), because iscsi is rather
specialized thing, and if you need it, you know you need it, and you can
install a package to get support. And b) requires an explicit command to
enable, so we might as well not install the package by default.

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

License change: python-userpath 1.8.0 is “MIT” instead of “MIT OR ASL 2.0”

[Ben Beasley]

With version 1.8.0, upstream for python-userpath has dropped the Apache 
license option. The License field has therefore changed from “MIT OR ASL 
2.0” to simply “MIT”. This version will appear in F37/Rawhide and (after 
the beta freeze) F36/branched.


– Ben
___
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: 20220223.n.0 changes

[Fedora Rawhide Report]

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

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
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 Wed, Feb 23, 2022 at 7:00 PM Björn Persson  wrote:
>
> Zbigniew Jędrzejewski-Szmek wrote:
> > Apart from Dmitry, I don't think there were any opinions from folks
> > who would be directly impacted.
>
> I don't know which programs use Curl so I can't tell whether I'd be
> impacted. I understand that Yum uses it. Lack of IDNA in Yum would
> impact me if I had a private mirror, but I don't. For downloading
> files from a command line, my habit is to use Wget, so I guess I'm
> dodging that bullet.

The "dnf repoquery --whatrequires "libcurl.so.4"" reports around 116
dependencies (no de-duped).
___
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]

Zbigniew Jędrzejewski-Szmek wrote:
> Apart from Dmitry, I don't think there were any opinions from folks
> who would be directly impacted.

I don't know which programs use Curl so I can't tell whether I'd be
impacted. I understand that Yum uses it. Lack of IDNA in Yum would
impact me if I had a private mirror, but I don't. For downloading
files from a command line, my habit is to use Wget, so I guess I'm
dodging that bullet.

Björn Persson


pgpBhrzmDJc5Y.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: Devtoolset for epel7 for build in Copr

[Dmitry Butskoy]

Ben Beasley wrote:

Yes, the devtoolsets work nicely if you supply the appropriate incantations. I 
haven’t tried in COPR specifically
I've just tried and it seems that devtoolset are not available for epel7 
builds in Copr. (For epel7, I successfully build seamonkey with 
devtoolset already for years :) )


There is a possibility to use an additional external repo for Copr. But 
there are issues with this.


First, the appropriate CentOS repo 
http://mirror.centos.org/centos/7/sclo/x86_64/rh/ does not have the 
latest llvm packages (for clang) -- say, llvm-toolset-11-* . (BTW, why??)


Second, the alternate Springdale Linux repo 
http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ seems to 
have all the ones (which are provided in sources by RedHat), but cannot 
be used in Copr. Springdale provides devtoolset-3-elfutils there, and it 
in some strange way  badly correlates with the initial Copr build 
environment (even before the rpmbuild process starts). Some python2 
module cannot find libelf.so.1 ...


So the general questions are:
- Whether it is possible to enable "rhel7-server-rhscl-7" and friends 
for epel7 builds in Copr? (See 
https://koji.fedoraproject.org/koji/taginfo?tagID=259 for more info);
- Why the user specified additional repos affect the initial set of 
packages used for the build environment?



~buc

P.S. Does anybody know a repo (besides Springdale) with the latest 
llvm-toolset-* provided?

___
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 Wed, Feb 23, 2022 at 10:33:16AM +0100, Vitaly Zaitsev via devel wrote:
> On 22/02/2022 12:33, Daniel P. Berrangé wrote:
> > 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 like it, but many Fedora contributors won't be happy. Google said that
> only 10% of their users use OTP.
> 
> We need to fix Fedora's OTP implementation first. Sending password+CODE is
> the worst idea, I ever seen. You can't even use a password manager to
> auto-enter it.
> 
> My suggestions:
> 1. Change password entry dialog on id.fedoraproject.org with
> accounts.fedoraproject.org version (with a separate OTP field).

We have this change already done, but are waiting for a upstream ipsilon
release. 

> 2. Kinit should ask for password and OTP code in different prompts (check
> how it works with SSH + OTP plugin).

This is being worked on by IPA folks.

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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Björn Persson]

Zbigniew Jędrzejewski-Szmek wrote:
> According to ICANN [1], there were 8.3 mln IDN domains worldwide.

And that's presumably only second-level domains. Nobody knows how many
non-ASCII subdomains exist under ASCII second-level domains, since
domain holders define subdomains at will without telling anybody.

There are currently 153 non-ASCII top-level domains out of 1486 total,
which is 10.3%:
https://data.iana.org/TLD/tlds-alpha-by-domain.txt

> Apparently .рф is fairly popular, with 1/5th of .ru registrations [3].

And that was eight years ago, only four years after рф was opened for
registrations.

> But from what I have seen, all those internationalized domains serve
> as a redirect or backup to sites also available as ascii.

In 2013 11% of рф domains redirected to ASCII domains, 50% were in use
and not redirecting, and 39% were only registered but unused. Already
in 2011, the year after the floodgates were opened, 34% were in use and
not redirecting. This is according to page 116 of this report:
https://web.archive.org/web/20141210151244/http://www.eurid.eu/files/publ/IDNWorldReport2014_Interactive.pdf

But yes, it's still often necessary to resort to ASCII, either the ACE
form (xn--gobbledygook) or a separate ASCII-only fallback domain. Email
in particular remains a major drag. Only in 2012 was there enough
consensus to publish a proposed standard for SMTPUTF8. Extensions to
IMAP and POP followed in 2013. Support in various email-handling
programs is still lacking. As long as people feel that they must have
an ASCII domain for email, some will naturally choose to use that same
domain for their website rather than using two separate domains.

> And for command-line
> tools or scripting, using those ascii versions seems quite likely…

That's another area where support for IDNA is spotty, yes. OpenSSH
still lacks support for example. So does Nmap. The Bind utils have
incomplete and inconsistent support. "dig", "host" and "nslookup" can
look up non-ASCII domain names, but if a server to query is specified,
then they expect the server to have an ASCII-only name. "delv" lacks
support entirely.

This is the problem that you're about to make worse. People will find
that support for IDNA is unreliable in various programs that use Curl
under the hood. To work around the problem they'll resort to the ACE
form, or to an ASCII-only domain they have for precisely that purpose.
Thus you end up hampering the adoption of international domains even
more.

> So I'd definitely vote to enable libidn2 in curl-minimal,
> _if_ there are people who'd actually use this for real.

People can't use it until it's consistently supported, and you won't
support it until people use it. Do you mean to wait for all the other
command line programs to support IDNA first, and then, when the whole
world is waiting for you, then you'll turn it on in Curl and people
will start using it? Guess what – everybody else is also waiting for
everybody else.

This is the same deadlock that hampers IPv6, encrypted email and many
other things. Everybody's waiting for everybody else to move first.

Björn Persson


pgp90R61gv1GJ.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: RPM spec feedback directly in your editor

[Andreas Schneider]

On Tuesday, February 22, 2022 7:41:16 PM CET Artur Frenszek-Iwicki wrote:
> > error: Unable to open /dev/stdin: No such device or address
> 
> How about "/proc/self/fd/0"?

Nope doesn't work ... /dev/stdin is a symlink to /proc/self/fd/0. I wonder if 
this is only available with a shell ...

___
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: Boost 1.78 upgrade (System-Wide Change proposal)

[Ben Cotton]

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


== Summary ==
This change brings Boost 1.78 to Fedora. This will mean Fedora ships
with a recent upstream Boost release.

== Owner ==

* Name: [[User:trodgers| Thomas Rodgers]]
* Email: trodg...@redhat.com


== Detailed Description ==

The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is absent from Boost, this entails rebuilding of
all dependent packages. This also entails the change owner assisting
maintainers of client packages in decoding cryptic boost-ese seen in
output from g++.

The equivalent changes for previous releases were
[[Changes/F35Boost176]], [[Changes/F34Boost175]],
[[Changes/F33Boost173]], [[Changes/F30Boost169|Fedora 30 Change]],
[[Changes/F29Boost167|Fedora 29 Change]], [[Changes/F28Boost166|Fedora
28 Change]], [[Changes/F27Boost164|Fedora 27 Change]],
[[Changes/F26Boost163|Fedora 26 Change]], [[Changes/F25Boost161|Fedora
25 Change]], [[Changes/F24Boost160|Fedora 24 Change]],
[[Changes/F23Boost159|Fedora 23 Change]] and
[[Changes/F22Boost158|Fedora 22 Change]].

== Benefit to Fedora ==

Fedora 37 includes Boost 1.78.

Fedora will stay relevant, as far as Boost clients are concerned.

Boost 1.78 does not bring any new components, but includes two new
header-only libraries from Boost 1.77 -
* Describe: A C++14 reflection library. Provides macros for describing
enumerators and struct/class members, and primitives for querying this
information.
* Lambda2: A C++14, dependency-free, single header lambda library.
Allows simple function objects to be constructed via expressions such
as _1 + 5, _1 % 2 == 0, _1 > _2, or _1 == ' ' || _1 == '\t'.

Boost 1.78 also includes many fixes and enhancements to existing components.

== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f37-boost"
[https://docs.pagure.org/releng/sop_adding_side_build_targets.html
build system tag]
([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
discussion]):

** Build boost into that tag (take a look at the
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build
#606493] for inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).

* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.


* Release engineering: TODO  (a check of an impact with Release Engineering is needed)

* Policies and guidelines:
** Apart from scope, this is business as usual, so no new policies, no
new guidelines.

* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
* No manual configuration or data migration needed.
* Some impact on other packages needing code changes to rebuild.
Historically this hasn't been too much of a problem and could always
be resolved before deadline.

== How To Test ==
* No special hardware is needed.
* Integration testing simply consists of installing Boost packages
(`dnf install boost`) on Fedora and checking that it does not break
other packages (see below for a way to obtain a list of boost
clients).


== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to
rebuild against the new Boost packages, and may need to adjust their
code if the new Boost release is not source-compatible.

== Dependencies ==
Packages that must be rebuilt:
$ dnf repoquery -s --releasever=rawhide --whatrequires
libboost\* --disablerepo=* --enablerepo=fedora | sort -u

All clients:
$ dnf repoquery --releasever=rawhide --archlist=src
--whatrequires boost-devel --disablerepo='*'
--enablerepo=fedora-source

== Contingency Plan ==

* Contingency mechanism: Worst case scenario is to abandon the update
and simply ship F37 with Boost 1.76, which is already in rawhide.
* Blocks release? No
* Blocks product? None

== Documentation ==
* https://www.boost.org/users/history/version_1_78_0.html (released on
8th December 2021)
* https://www.boost.org/users/history/version_1_77_0.html (released on
11 August 2021)
* https://www.boost.org/development/index.html

== Release Notes ==


-- 
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/dev

Re: Devtoolset for epel7 for build in Copr

[Ben Beasley]

Yes, the devtoolsets work nicely if you supply the appropriate incantations. I 
haven’t tried in COPR specifically, but I assume the situation is the same as 
in EPEL proper. Please see the very clean example in the epel7 branch for 
sleef[1], which was kindly contributed by Dave Love.

– Ben

[1] https://src.fedoraproject.org/rpms/sleef/blob/epel7/f/sleef.spec

On Wed, Feb 23, 2022, at 11:25 AM, Dmitry Butskoy wrote:
> Is it possible to use RHEL7 devtoolsets (aka devtoolset-8, 
> llvm-toolset-11 and so on) for the correspond builds in Copr, as well as 
> it is possible for builds for Fedora EPEL7 ?
>
> ~buc
> ___
> 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
___
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

Devtoolset for epel7 for build in Copr

[Dmitry Butskoy]

Is it possible to use RHEL7 devtoolsets (aka devtoolset-8, 
llvm-toolset-11 and so on) for the correspond builds in Copr, as well as 
it is possible for builds for Fedora EPEL7 ?


~buc
___
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: rpmlint 2.x totally bogus output on debuginfo sub-pkgs

[Hans de Goede]

Hi,

On 2/23/22 15:23, Petr Pisar wrote:
> V Wed, Feb 23, 2022 at 01:45:02PM +0100, Hans de Goede napsal(a):
>> I'm wondering if I'm the only one who is seeing quite a few bogus
>> warnings / errors getting thrown by rpmlint when run on C/C++
>> debuginfo sub-pkgs ?
>>
>> And assuming I'm not the only one I'm wondering if there are some
>> plans to address / fix this ?
>>
>> I tend to always run rpmlint as part of my workflow to avoid
>> unnecessary mistakes getting pushed out, but all the new
>> false-positive  errors/warnings make this a lot more painful
>> then it used to be.
>>
> You are not the only one
> . Upstream claims that
> rpmlint is not expected to run on debuginfo subpackages. Hence it's up to
> "fedpkg lint" to exclude the debuginfo subpackages from linting.

Ah, thank you.

I did check: http://bugz.fedoraproject.org/rpkg but not fedpkg.

Note I believe that rpkg would be a more appropriate component since
that is where the actual logic is implemented AFAIK.

Regards,

Hans
___
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 Wed, Feb 23, 2022 at 02:22:32PM +, Daniel P. Berrangé wrote:
> On Wed, Feb 23, 2022 at 02:52:02PM +0100, Kamil Dudka wrote:
> > On Wednesday, February 23, 2022 10:22:00 AM CET Dmitry Belyavskiy wrote:
> > > Dear Kamil,
> > > 
> > > On Wed, Feb 23, 2022 at 8:51 AM Kamil Dudka  wrote:
> > > > 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.
> > > > 
> > > > Being from Russia and having several years of interacting with Universal
> > > 
> > > Acceptance, I'd say IDN is a must nowadays.
> > 
> > To be clear, I am not completely against including IDN in libcurl-minimal.
> > On the other hand, we removed IDN from libcurl in ubi9 images in September
> > and nobody has complained about it so far:
>
> Is that really a good metric to evaluate against though ? All the
> minimal containers have generally thrown out anything related to
> i18n/l10n, leaving only support for the most basic C locale, in the
> name of saving image size. IOW loss of anything related to helping
> non-English/Western users is (unfortunately) accepted collatoral
> damage with containers, and IDN was just one cut of many in that
> area.
> 
> I don't think it follows that it is OK to sacrifice IDN by default
> for all Fedora deliverables, because many others do still care
> about providing good i18n support to users.

"sacrifice" and "all Fedora deliverables" are not good terms here.
This change has no impact on e.g. browsers. And even without changing
how curl is built, e.g. we can always add "Enhances: langpacks-uk,
langpacks-ru, langpacks-be" to libcurl if we determine that Ukrainian,
Russian, and Bellarussian users are particularly likely to use idn.

Apart from Dmitry, I don't think there were any opinions from folks
who would be directly impacted.

Zbyszek

P.S. I checked statistics for .pl, and the number of IDN domains under .pl
has fallen from a high of 65k in 2012 to 29k in 2021, out of 2500k total
in 2021 [1].

[1] https://www.nask.pl/download/30/4166/NASK-Q1-2021-RAPORT.pdf
___
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: rpmlint 2.x totally bogus output on debuginfo sub-pkgs

[Petr Pisar]

V Wed, Feb 23, 2022 at 01:45:02PM +0100, Hans de Goede napsal(a):
> I'm wondering if I'm the only one who is seeing quite a few bogus
> warnings / errors getting thrown by rpmlint when run on C/C++
> debuginfo sub-pkgs ?
> 
> And assuming I'm not the only one I'm wondering if there are some
> plans to address / fix this ?
> 
> I tend to always run rpmlint as part of my workflow to avoid
> unnecessary mistakes getting pushed out, but all the new
> false-positive  errors/warnings make this a lot more painful
> then it used to be.
> 
You are not the only one
. Upstream claims that
rpmlint is not expected to run on debuginfo subpackages. Hence it's up to
"fedpkg lint" to exclude the debuginfo subpackages from linting.

-- Petr


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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Daniel P . Berrangé]

On Wed, Feb 23, 2022 at 02:52:02PM +0100, Kamil Dudka wrote:
> On Wednesday, February 23, 2022 10:22:00 AM CET Dmitry Belyavskiy wrote:
> > Dear Kamil,
> > 
> > On Wed, Feb 23, 2022 at 8:51 AM Kamil Dudka  wrote:
> > > 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.
> > > 
> > > Being from Russia and having several years of interacting with Universal
> > 
> > Acceptance, I'd say IDN is a must nowadays.
> 
> To be clear, I am not completely against including IDN in libcurl-minimal.
> On the other hand, we removed IDN from libcurl in ubi9 images in September
> and nobody has complained about it so far:

Is that really a good metric to evaluate against though ? All the
minimal containers have generally thrown out anything related to
i18n/l10n, leaving only support for the most basic C locale, in the
name of saving image size. IOW loss of anything related to helping
non-English/Western users is (unfortunately) accepted collatoral
damage with containers, and IDN was just one cut of many in that
area.

I don't think it follows that it is OK to sacrifice IDN by default
for all Fedora deliverables, because many others do still care
about providing good i18n support to users.

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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Ewoud Kohl van Wijngaarden]

On Wed, Feb 23, 2022 at 02:52:02PM +0100, Kamil Dudka wrote:

On Wednesday, February 23, 2022 10:22:00 AM CET Dmitry Belyavskiy wrote:

Dear Kamil,

On Wed, Feb 23, 2022 at 8:51 AM Kamil Dudka  wrote:
> 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.
>
> 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.
>
> Being from Russia and having several years of interacting with Universal

Acceptance, I'd say IDN is a must nowadays.


To be clear, I am not completely against including IDN in libcurl-minimal.
On the other hand, we removed IDN from libcurl in ubi9 images in September
and nobody has complained about it so far:

   https://bugzilla.redhat.com/1994521


Isn't this also a bit of chicken and egg problem? You can't really use 
IDN since tooling doesn't support it and tooling doesn't support it 
because nobody uses it.


I'll note that personally I have no need for IDN.
___
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 Wednesday, February 23, 2022 10:22:00 AM CET Dmitry Belyavskiy wrote:
> Dear Kamil,
> 
> On Wed, Feb 23, 2022 at 8:51 AM Kamil Dudka  wrote:
> > 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.
> > 
> > Being from Russia and having several years of interacting with Universal
> 
> Acceptance, I'd say IDN is a must nowadays.

To be clear, I am not completely against including IDN in libcurl-minimal.
On the other hand, we removed IDN from libcurl in ubi9 images in September
and nobody has complained about it so far:

https://bugzilla.redhat.com/1994521

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

rpmlint 2.x totally bogus output on debuginfo sub-pkgs

[Hans de Goede]

Hi All,

I'm wondering if I'm the only one who is seeing quite a few bogus
warnings / errors getting thrown by rpmlint when run on C/C++
debuginfo sub-pkgs ?

And assuming I'm not the only one I'm wondering if there are some
plans to address / fix this ?

I tend to always run rpmlint as part of my workflow to avoid
unnecessary mistakes getting pushed out, but all the new
false-positive  errors/warnings make this a lot more painful
then it used to be.

Regards,

Hans
___
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)

[Dominique Martinet]

Zbigniew Jędrzejewski-Szmek wrote on Wed, Feb 23, 2022 at 10:44:12AM +0100:
> According to ICANN [1], there were 8.3 mln IDN domains worldwide. I admit
> that is more than I expected. According to verisgn [2], out of 364.6 mln 
> total,
> i.e. around 2%.
> Apparently .рф is fairly popular, with 1/5th of .ru registrations [3].

Dmitry mentionned Russia in a sibling mail, Japan also definitley has
quite a few of these as well which I see often enough here, I defintely
wouldn't say IDN domains are rare in such regions...

> But from what I have seen, all those internationalized domains serve
> as a redirect or backup to sites also available as ascii. And for command-line
> tools or scripting, using those ascii versions seems quite likely…

... but I can also agree with this, I haven't seen any ostensibly used
in scripts, although I don't particularly look at Japanese
documentations/examples so I wouldn't say I'm sure about that.

Searching github for "curl https://xn--"; (xn-- is the punycode prefix)
did turn out some results though in issues, e.g. acme.sh:
https://github.com/acmesh-official/acme.sh/issues/3078
which does make sense, cert renewal happens with these domains usually
used in web browsers, so is quite likely to contain such domains if only
for testing purposes.
With that in mind monitoring is also very likely, stuff like nagios
plugins or prometheus web-related probes will definitely want idn
support.

> I certainly wouldn't want to break things for people using non-latin
> scripts. So I'd definitely vote to enable libidn2 in curl-minimal,
> _if_ there are people who'd actually use this for real.

I'd say if desktop environments and things that might deal with such
domains are updated to pull curl-full it'll probably be ok, but at this
point I also think anything non-trivial in an international setup would
want to pull it in so it might as well get included in curl-minimal.

That being said, the point about FTP in another part of the thread is
also probably correct, so curl minimal is starting not to feel that
minimal... I'm not sure forking a third version of the package for
default setup makes sense though.
-- 
Dominique
___
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

Orphaned magic-wormhole + its python deps

[Fabio Valentini]

Hi everyone,

I have just orphaned magic-wormhole (the original one written in
Python) and its dependencies. I no longer use it, I have no time to
fix the packages for new Python versions, and upstream is pretty much
dead since they started porting the project to Rust.

- python-magic-wormhole
- python-magic-wormhole-mailbox-server
- python-magic-wormhole-transit-relay
- python-txtorcon
- python-spake2
- python-hkdf

There is an alternative Go implementation of the "Wormhole Protocol"
(wormhole-william), for which eclipseo already submitted a review
request. It seems to be better maintained than the Python original, if
we want to have a Wormhole client in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1922806

The official port of magic-wormhole to Rust also seems to be
progressing, we might want to package that one instead once it's
released:
https://github.com/magic-wormhole/magic-wormhole.rs

Fabio
___
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

[Daniel P . Berrangé]

On Wed, Feb 23, 2022 at 10:33:16AM +0100, Vitaly Zaitsev via devel wrote:
> On 22/02/2022 12:33, Daniel P. Berrangé wrote:
> > 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 like it, but many Fedora contributors won't be happy. Google said that
> only 10% of their users use OTP.

I presume you're referring to Google services like GMail, etc. I can
totally understand that kind of metric for the global population in
general, but I don't think the comparison is relevant or valid.

Contributing to the Fedora project comes with responsibilities,
and being asked to keep your account secured with 2fa is not an
unreasonable request from a project such as Fedora, whose output
is consumed by a huge number of users. 2fa is a standard best
practice expected from any organization that takes user account
security seriously.

There are significant implications for reputational damage to
Fedora if a contributor's account is compromised and that is
then successfully used to compromise software and get it shipped
to millions of users.

We got lucky in the past with scope of damage after an account
compromise, but we should not assume that will be the case next
time...

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

Fedora-Cloud-34-20220223.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-34-20220221.0):

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

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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 23, 2022 at 08:51:10AM +0100, Kamil Dudka wrote:
> 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.

According to ICANN [1], there were 8.3 mln IDN domains worldwide. I admit
that is more than I expected. According to verisgn [2], out of 364.6 mln total,
i.e. around 2%.
Apparently .рф is fairly popular, with 1/5th of .ru registrations [3].

But from what I have seen, all those internationalized domains serve
as a redirect or backup to sites also available as ascii. And for command-line
tools or scripting, using those ascii versions seems quite likely…

I certainly wouldn't want to break things for people using non-latin
scripts. So I'd definitely vote to enable libidn2 in curl-minimal,
_if_ there are people who'd actually use this for real.

[1] 
https://www.icann.org/en/blogs/details/supporting-a-multilingual-internet-through-idns-icann-idn-progress-report-14-1-2022-en
[2] https://www.verisign.com/en_US/domain-names/dnib/index.xhtml
[3] https://en.wikipedia.org/wiki/.%D1%80%D1%84

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: Preventing account takeovers through expired domains

[Vitaly Zaitsev via devel]

On 22/02/2022 12:33, Daniel P. Berrangé wrote:

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 like it, but many Fedora contributors won't be happy. Google said that 
only 10% of their users use OTP.


We need to fix Fedora's OTP implementation first. Sending password+CODE 
is the worst idea, I ever seen. You can't even use a password manager to 
auto-enter it.


My suggestions:
1. Change password entry dialog on id.fedoraproject.org with 
accounts.fedoraproject.org version (with a separate OTP field).
2. Kinit should ask for password and OTP code in different prompts 
(check how it works with SSH + OTP plugin).


--
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 23/02/2022 00:03, Gary Buhrmaster wrote:

a TPM(2?) chip as a possible secure processor.


In some countries, TPM can't be pre-installed on all new PCs/Laptops due 
to regulation issues.


--
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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Dmitry Belyavskiy]

Dear Kamil,



On Wed, Feb 23, 2022 at 8:51 AM Kamil Dudka  wrote:

> 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.
>
> Being from Russia and having several years of interacting with Universal
Acceptance, I'd say IDN is a must nowadays.


-- 
Dmitry Belyavskiy
___
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)

[Vitaly Zaitsev via devel]

On 23/02/2022 08:46, Kamil Dudka wrote:

  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.


dnf still needs FTP support.

--
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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 22/02/2022 21:45, Peter Robinson wrote:

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


Many Fedora mirrors still use FTP. You can check metalink file.

--
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: Rpm: provide a static library in package

[Vitaly Zaitsev via devel]

On 23/02/2022 02:05, Denis Fateyev wrote:
Unfortunately, the shared library support is explicitly removed by the 
upstream:


You can revert this commit with a downstream patch.


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


From README:

> This library is obsolete. Please use the official gcc C++ standard 
library.


--
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: Rpm: provide a static library in package

[Vitaly Zaitsev via devel]

On 22/02/2022 19:57, Denis Fateyev wrote:
So I'm going to make changes in the package, and provide everything in 
"-devel" subpackage.


No. You must patch the build manifest and force building as a shared 
library, regardless of the upstream choice.


https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries

--
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

Fedora-Cloud-35-20220223.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-20220222.0):

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

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: Self Introduction: Yunmei Li

[Benson Muite]

On 2/23/22 6:42 AM, Yunmei LI wrote:

Hi,
Thanks for your help! I reworked the Milvus package for EPEL8 based on 
the comments I received, and updated theSpec URL and SRPMURL on 
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2055596 

I am really lookingforward to someone reviewingMilvus package at the 
earliest convenience.

Not a review, but does it build on Copr[1] or Koji[2] ?
It may be helpful to check the Go SIG recommendations[3],[4].
You may also find OpenBuildService helpful[5].

[1] https://copr.fedorainfracloud.org/
[2] https://koji.fedoraproject.org/koji/
[3] https://fedoraproject.org/wiki/SIGs/Go
[4] https://fedoraproject.org/wiki/PackagingDrafts/Go
[5] https://openbuildservice.org/


Thanks,
Yunmei Li
From: "Ben Beasley">

Date: Mon, Feb 21, 2022, 22:11
Subject: Re: Self Introduction: Yunmei Li
To: mailto:devel@lists.fedoraproject.org>>

All current versions of *Fedora* have CMake 3.20 or later, so you 
shouldn’t have any problems there.


When packaging for EPEL, you rely on the package versions that were 
released with the corresponding version of Red Hat Enterprise Linux. 
RHEL aims to provide long-term stability, so these mostly get bugfix 
releases and security backports rather than significant updates over the 
life of the distribution. This is largely the same update philosophy as 
individual Fedora releases, but with a lifecycle on the order of a 
decade rather than a year. Since RHEL 7.0 was released in 2014, most of 
the packages you can use when building for EPEL7 are based on pretty old 
upstream versions.


In most cases, if the dependency versions in a particular release of 
RHEL don’t meet your needs, it means that it is not practical to build 
your package for the corresponding version of EPEL. There are a few 
exceptions—for example, you can get a newer compiler toolchain by using 
one of the devtoolset releases, e.g. [1].


If you can package for EPEL7 successfully, but only by doing things that 
don’t meet Fedora/EPEL guidelines (bundling dependencies without 
satisfying the conditions in [2], packaging your own 
newer-but-not-parallel-installable version of cmake to build with), then 
you might still be able to offer a package for EL7 distributions via 
COPR[3].


You might find that EPEL8 or EPEL9 are still viable targets. You also 
might find that the epel-devel mailing list is a helpful place to ask 
questions.


– Ben

[1] https://src.fedoraproject.org/rpms/sleef/blob/epel7/f/sleef.spec

[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling

[3] https://docs.pagure.org/copr.copr/user_documentation.html#faq


___
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: Question about Fedora Package Naming

[Hirotaka Wakabayashi via devel]

 Hello Remi, Thank you very much for your reply! I am a PHP user for years. 
I like PHP very much except for breaking compatibility :P
How do you think about adding something similar to the following sentences
to naming scheme of PHP packaging guidelines[1]. I understand the preference 
is to update the main package to the latest version, but PHP has its specific 
guideline, so I think we should update PHP guidelines. I can submit PR if no 
problem.

```
Composer enabled packages (referenced in packagist.org or another registry)
should be named php-vendor-library-%{version}-%{release}.noarch.rpm

However, php-vendor-library%{version}-%{version}-%{release}.noarch.rpm should
be acceptable if php-vendor-library package already exists Fedora’s git
repository and there is no compatibility with it.
 ```
Currently I am reviewing this ticket. The package name is 
php-guzzlehttp-guzzle7.and php-guzzlehttp-guzzle already exists in Fedora’s git 
repository.
https://bugzilla.redhat.com/show_bug.cgi?id=1982627

---
1: https://docs.fedoraproject.org/en-US/packaging-guidelines/PHP/#naming-scheme

Regards,
Hirotaka

On Sunday, February 20, 2022, 04:54:51 PM GMT+9, Remi Collet 
 wrote:  
 
 Le 19/02/2022 à 13:58, Hirotaka Wakabayashi via devel a écrit :
> Hello, I have a question about Fedora Package Naming.
> 
> php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version 
> by upstream. The latest version is 7.4.1.
> https://src.fedoraproject.org/rpms/php-guzzlehttp-guzzle 
> 
> https://github.com/guzzle/guzzle#version-guidance 
> 
> 
> In this situation, if I want to package the 7.4.1. version, should the 
> package name be php-guzzlehttp-guzzle7? Or should I submit a patch to 
> change the php-guzzlehttp-guzzle version? I think php-guzzlehttp-guzzle 
> should be upgraded because EOL products potentially contain security 
> issues, but most users probably doesn't know the package is EOL or not 
> when they install it.

Notice: PHP libraries usually follow semver, so major version means
breaking changes. i.e. v5, v6 and v7 are not compatible.

For guzzle, we have

php-guzzlehttp-guzzle6 version 6.5.5
php-guzzlehttp-guzzle  version 5.3.4
php-guzzle-Guzzle      version 3.9.3 (retired)

IMHO, we should always use version in name
even if the package name doesn't really matter as we should
always use virtual provides, php-composer(guzzlehttp/guzzle) and range 
dependencies.

OK, I know Fedora policy prefers to create "compat" packages
for old versions, but this is a nightmare to maintain as each
update will break everything

if "php-foo" provides a library v1 in /usr/share/php/Foo
a major update will break other packages

creating a compat "php-foo1" in /usr/share/php/Foo1
won't help (other package will have to be fixed)

keeping the compat "php-foo1" in /usr/share/php/Foo
and update the "php-foo" to use /usr/share/php/Foo2
may work, but is really confusing.

BTW I start thinking using system libraries in PHP app
was a interesting adventure, but it also means fightning with
php and composer usage, where everything is bundled in each project.

In the near future a lot of PHP system libraries are going to
be removed from Fedora repository because of fail to build or
fail to install. And there is not enough maintainers to fix them.
(I'm working on building a list I will post on "php-devel" ML)

To be clear nobody uses PHP system libraries directly.

Users needs app (composer, phpMyAdmin, nextcloud, wordpress...)

Developers only use composer to install project dependencies
in the project directory.

As I already said elsewhere, I'm sad, but I'm tired to fight
with PHP projects which don't care of system wide installation
and don't support them, and don't want them, and to fight with
Fedora which don't care of the PHP stack.


Remi



> 
> Regards,
> Hirotaka
> 
> 
> ___
> 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
___
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