Fedora-Cloud-35-20220219.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-20220218.0):

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

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

Fedora rawhide compose report: 20220219.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220218.n.0
NEW: Fedora-Rawhide-20220219.n.0

= SUMMARY =
Added images:3
Dropped images:  0
Added packages:  1
Dropped packages:0
Upgraded packages:   86
Downgraded packages: 1

Size of added packages:  962.78 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.27 GiB
Size of downgraded packages: 1.51 MiB

Size change of upgraded packages:   10.94 MiB
Size change of downgraded packages: 3.32 KiB

= ADDED IMAGES =
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20220219.n.0.aarch64.raw.xz
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20220219.n.0.iso
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20220219.n.0.aarch64.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: community-mysql-8.0.28-1.module_f37+13827+ed4bfb11
Summary: MySQL client programs and shared libraries
RPMs:community-mysql community-mysql-common community-mysql-devel 
community-mysql-errmsg community-mysql-libs community-mysql-server 
community-mysql-test
Size:962.78 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  abseil-cpp-20210324.2-4.fc37
Old package:  abseil-cpp-20210324.2-2.fc35
Summary:  C++ Common Libraries
RPMs: abseil-cpp abseil-cpp-devel
Size: 5.43 MiB
Size change:  70.79 KiB
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
20210324.2-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Mon Jan 31 2022 Benjamin A. Beasley  - 20210324.2-4
  - Fix test failure (fix RHBZ#2045186)


Package:  criu-3.16.1-8.fc37
Old package:  criu-3.16.1-7.fc36
Summary:  Tool for Checkpoint/Restore in User-space
RPMs: crit criu criu-devel criu-libs criu-ns python3-criu
Size: 2.84 MiB
Size change:  2.26 KiB
Changelog:
  * Fri Feb 18 2022 Radostin Stoyanov  - 3.16.1-8
  - rebuilt


Package:  deepin-calendar-5.8.27-1.fc37
Old package:  deepin-calendar-5.8.26-2.fc36
Summary:  Calendar for Deepin Desktop Environment
RPMs: deepin-calendar
Size: 6.12 MiB
Size change:  6.86 KiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.8.27-1
  - New release 5.8.27


Package:  deepin-desktop-schemas-5.10.2-1.fc37
Old package:  deepin-desktop-schemas-5.9.41-2.fc36
Summary:  GSettings deepin desktop-wide schemas
RPMs: deepin-desktop-schemas
Size: 70.65 KiB
Size change:  231 B
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.10.2-1
  - New release 5.10.2


Package:  deepin-dock-5.5.9-1.fc37
Old package:  deepin-dock-5.4.69.1-2.fc36
Summary:  Deepin desktop-environment - Dock module
RPMs: deepin-dock deepin-dock-devel deepin-dock-onboard-plugin
Size: 7.50 MiB
Size change:  -36.11 KiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.5.9-1
  - New release 5.5.9


Package:  deepin-file-manager-5.5.1-4.fc37
Old package:  deepin-file-manager-5.5.1-2.fc36
Summary:  Deepin File Manager
RPMs: deepin-desktop deepin-file-manager deepin-file-manager-devel
Size: 146.91 MiB
Size change:  109.15 KiB
Changelog:
  * Thu Jan 20 2022 Fedora Release Engineering  
5.5.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Fri Feb 18 2022 Robin Lee  5.5.1-4
  - Fix build on GCC 12 (RHBZ#2045305)


Package:  deepin-icon-theme-2021.11.24-1.fc37
Old package:  deepin-icon-theme-2021.08.19-3.fc36
Summary:  Icons for the Deepin Desktop Environment
RPMs: deepin-icon-theme
Size: 32.07 MiB
Size change:  7.92 MiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  2021.11.24-1
  - New release 2021.11.24


Package:  deepin-launcher-5.5.6-1.fc37
Old package:  deepin-launcher-5.4.60-2.fc36
Summary:  Deepin desktop-environment - Launcher module
RPMs: deepin-launcher deepin-launcher-devel
Size: 2.96 MiB
Size change:  90.26 KiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.5.6-1
  - New release 5.5.6


Package:  deepin-pw-check-5.1.6-1.fc37
Old package:  deepin-pw-check-5.1.2-1.fc36
Summary:  Tool used to check password and manager the configuration for 
password
RPMs: deepin-pw-check deepin-pw-check-devel
Size: 8.82 MiB
Size change:  25.60 KiB
Changelog:
  * Thu Jan 20 2022 Fedora Release Engineering  
5.1.2-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Fri Feb 18 2022 Robin Lee  5.1.6-1
  - New release 5.1.6 (RHBZ#2045308)


Package:  deepin-qt-dbus-factory-5.5.5-1.fc37
Old package:  deepin-qt-dbus-factory-5.4.20-2.fc36
Summary:  A repository stores auto-generated Qt5 dbus code
RPMs: deepin-qt-dbus-factory deepin-qt-dbus-factory-devel
Size: 3.75 MiB
Size change:  66.01 KiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.5.5-1
  - New release 5.5.5


Package:  deepin-qt5platform-plugins-5.0.46-1.fc37
Old package:  deepin-qt5platform-plugins-5.0.42-2.fc36
Summary

Fedora-Cloud-34-20220219.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (aarch64)

New failures (same test not failed in Fedora-Cloud-34-20220218.0):

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

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

Old soft failures (same test soft failed in Fedora-Cloud-34-20220218.0):

ID: 1137053 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1137053

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

Fedora 36 compose report: 20220219.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-36-20220218.n.0
NEW: Fedora-36-20220219.n.0

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

Size of added packages:  21.22 KiB
Size of dropped packages:0 B
Size of upgraded packages:   1.89 GiB
Size of downgraded packages: 1.76 MiB

Size change of upgraded packages:   13.13 MiB
Size change of downgraded packages: 3.71 KiB

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: uniol-fonts-1.0.1-6.fc36
Summary: Unicode compliant Open source Ol Chiki font
RPMs:uniol-fonts
Size:21.22 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  abseil-cpp-20210324.2-4.fc36
Old package:  abseil-cpp-20210324.2-2.fc35
Summary:  C++ Common Libraries
RPMs: abseil-cpp abseil-cpp-devel
Size: 6.48 MiB
Size change:  80.06 KiB
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
20210324.2-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Mon Jan 31 2022 Benjamin A. Beasley  - 20210324.2-4
  - Fix test failure (fix RHBZ#2045186)


Package:  community-mysql-8.0.28-1.module_f36+13829+5c014eb2
Old package:  community-mysql-8.0.27-1.module_f36+13266+add8567c
Summary:  MySQL client programs and shared libraries
RPMs: community-mysql community-mysql-common community-mysql-devel 
community-mysql-errmsg community-mysql-libs community-mysql-server 
community-mysql-test
Size: 1.17 GiB
Size change:  4.84 MiB
Changelog:
  * Sun Nov 07 2021 Mamoru TASAKA  - 8.0.27-2
  - rebuild for new protobuf

  * Wed Jan 19 2022 Fedora Release Engineering  - 
8.0.27-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Wed Jan 19 2022 Lars Tangvald  - 8.0.28-1
  - Update to MySQL 8.0.28


Package:  deepin-calendar-5.8.27-1.fc36
Old package:  deepin-calendar-5.8.26-2.fc36
Summary:  Calendar for Deepin Desktop Environment
RPMs: deepin-calendar
Size: 7.57 MiB
Size change:  6.41 KiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.8.27-1
  - New release 5.8.27


Package:  deepin-desktop-schemas-5.10.2-1.fc36
Old package:  deepin-desktop-schemas-5.9.41-2.fc36
Summary:  GSettings deepin desktop-wide schemas
RPMs: deepin-desktop-schemas
Size: 70.64 KiB
Size change:  219 B
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.10.2-1
  - New release 5.10.2


Package:  deepin-dock-5.5.9-1.fc36
Old package:  deepin-dock-5.4.69.1-2.fc36
Summary:  Deepin desktop-environment - Dock module
RPMs: deepin-dock deepin-dock-devel deepin-dock-onboard-plugin
Size: 8.88 MiB
Size change:  -21.70 KiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.5.9-1
  - New release 5.5.9


Package:  deepin-file-manager-5.5.1-4.fc36
Old package:  deepin-file-manager-5.5.1-2.fc36
Summary:  Deepin File Manager
RPMs: deepin-desktop deepin-file-manager deepin-file-manager-devel
Size: 175.94 MiB
Size change:  112.15 KiB
Changelog:
  * Thu Jan 20 2022 Fedora Release Engineering  
5.5.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Fri Feb 18 2022 Robin Lee  5.5.1-4
  - Fix build on GCC 12 (RHBZ#2045305)


Package:  deepin-icon-theme-2021.11.24-1.fc36
Old package:  deepin-icon-theme-2021.08.19-3.fc36
Summary:  Icons for the Deepin Desktop Environment
RPMs: deepin-icon-theme
Size: 32.09 MiB
Size change:  7.94 MiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  2021.11.24-1
  - New release 2021.11.24


Package:  deepin-launcher-5.5.6-1.fc36
Old package:  deepin-launcher-5.4.60-2.fc36
Summary:  Deepin desktop-environment - Launcher module
RPMs: deepin-launcher deepin-launcher-devel
Size: 3.50 MiB
Size change:  116.96 KiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.5.6-1
  - New release 5.5.6


Package:  deepin-pw-check-5.1.6-1.fc36
Old package:  deepin-pw-check-5.1.2-1.fc36
Summary:  Tool used to check password and manager the configuration for 
password
RPMs: deepin-pw-check deepin-pw-check-devel
Size: 10.56 MiB
Size change:  27.79 KiB
Changelog:
  * Thu Jan 20 2022 Fedora Release Engineering  
5.1.2-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Fri Feb 18 2022 Robin Lee  5.1.6-1
  - New release 5.1.6 (RHBZ#2045308)


Package:  deepin-qt-dbus-factory-5.5.5-1.fc36
Old package:  deepin-qt-dbus-factory-5.4.20-2.fc36
Summary:  A repository stores auto-generated Qt5 dbus code
RPMs: deepin-qt-dbus-factory deepin-qt-dbus-factory-devel
Size: 4.44 MiB
Size change:  78.14 KiB
Changelog:
  * Fri Feb 18 2022 Robin Lee  5.5.5-1
  - New release 5.5.5


Package:  deepin-qt5platform-plugins-5.0.46-1.fc36
Old package:  deepin-qt5platform-plugins-5.0.42-2.fc36
Summary:  Qt platform integration plugins for Deepin Desktop Environment
RPMs: deepin-qt5platform-plugins
Size

Question about Fedora Package Naming

[Hirotaka Wakabayashi via devel]

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-guzzlehttps://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.

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

Re: Question about Fedora Package Naming

[Neal Gompa]

On Sat, Feb 19, 2022 at 7:59 AM Hirotaka Wakabayashi via devel
 wrote:
>
> 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.
>

The preference is to update the main package to the latest version,
and in the event the older one is needed, branch that as a
compatibility package using the compatibility package guidelines.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Preventing account takeovers through expired domains (was: Do we have any policy for disabling inactive users)

[Björn Persson]

Vitaly Zaitsev via devel wrote:
> We're talking about potentially hacked accounts, right?

In this subthread I'm talking about *preventing* account takeovers so
that they don't happen in the first place. One specific method of
takeover that the Fedora Project would be able to prevent.

I thought the quote I posted was perfectly clear. Evidently it wasn't.
Allow me to explain the scenario step by step:


Step 1: J. Doe joins the Fedora Project using a working email address,
j@example.net. J. Doe gets sponsored and makes some packages. All
is well so far.

Step 2: Much later, the holder of example.net stops paying the renewal
fee. The registry removes the domain from DNS. j@example.net ceases
to exist. J. Doe forgets to update the address in their Fedora account.
This has happened to 2818 NPM accounts according to the article I
quoted. It can happen to Fedora accounts too.

Possible step 3: A program on a Fedora Project server notes that
example.net has been deactivated. The program removes the address
j@example.net from J. Doe's account, or disables sending to the
nonexistent address.

Question: Does step 3 happen? I suspect that this program doesn't exist.
I haven't seen any mentions of it.

Step 4: The quarantine period ends. The registry releases example.net
for registration.

Step 5: Malicious Mallory registers example.net, sets up a mail server
and configures the alias "j.doe". Suddenly j@example.net exists
again, but now this address quite legitimately belongs to Mallory.

Step 6: Mallory enters J. Doe's username into 
https://accounts.fedoraproject.org/forgot-password/ask and clicks on
"Send".

Branch 6A: If step 3 was not done, then a passphrase reset email is sent
to j@example.net and is received by Mallory. Mallory takes over J.
Doe's account and replaces any SSH and OpenPGP keys with his own.
Malicious Mallory is now a Fedora packager in the name of J. Doe, and
is empowered to insert malware into J. Doe's packages.

Branch 6B: If step 3 was done, then no passphrase reset email is sent.
Mallory's attack fails.

Step 7: J. Doe tries to log in.

Branch 7A: If step 3 was not done, then none of J. Doe's credentials
work anymore. Mallory has control of the account and J. Doe is locked
out.

Branch 7B: If step 3 was done, then the account still belongs to J. Doe.
The account system tells J. Doe to enter a new email address. The
system sends a verification code to this new address. This is not a
passphrase reset. It's an email address verification code, which J. Doe
must paste into the web interface while logged in, to prove that the
address belongs to the right person. After the new address is verified,
J. Doe's account works normally again.


Note that Mallory must do step 5 before step 6 for the attack to work,
and the registry won't allow step 5 to happen before step 4. Therefore
doing step 3 before step 4 ensures that step 6 cannot happen before
step 3. That way the Fedora Project could reliably prevent this kind of
attack.

I hope this explanation is clear enough to be understood. In case of
TL;DR, the short version is four posts upthread from here.

So, does step 3 exist?

Björn Persson


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

Fedora-IoT-37-20220219.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

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

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

ID: 1137540 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1137540
ID: 1137541 Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1137541
ID: 1137542 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1137542
ID: 1137556 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1137556
ID: 1137557 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1137557

Skipped non-gating openQA tests: 26 of 31
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing account takeovers through expired domains (was: Do we have any policy for disabling inactive users)

[Zbigniew Jędrzejewski-Szmek]

On Sat, Feb 19, 2022 at 02:18:38PM +0100, Björn Persson wrote:
> Possible step 3: A program on a Fedora Project server notes that
> example.net has been deactivated. The program removes the address
> j@example.net from J. Doe's account, or disables sending to the
> nonexistent address.
...
> Step 4: The quarantine period ends. The registry releases example.net
> for registration.

This means we would create the domain entering quarantine period
almost like it being deactivated. That's very harsh… Based on a quick
search, it seems that the quarantine varies, but is 14-40 days.

I think it'd be better to check the status weekly and only require
account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋
times in a row (where N=quarantine length in days).

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

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

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 93/229 (x86_64), 60/161 (aarch64)

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

ID: 1137105 Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/1137105
ID: 1137106 Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1137106
ID: 1137107 Test: x86_64 Server-dvd-iso 
install_blivet_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/1137107
ID: 1137108 Test: x86_64 Server-dvd-iso 
install_blivet_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1137108
ID: 1137109 Test: x86_64 Server-dvd-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1137109
ID: 1137110 Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1137110
ID: 1137112 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1137112
ID: 1137113 Test: x86_64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1137113
ID: 1137116 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1137116
ID: 1137117 Test: x86_64 Server-dvd-iso install_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/1137117
ID: 1137118 Test: x86_64 Server-dvd-iso install_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1137118
ID: 1137121 Test: x86_64 Server-dvd-iso install_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/1137121
ID: 1137122 Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1137122
ID: 1137125 Test: x86_64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1137125
ID: 1137126 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/1137126
ID: 1137129 Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/1137129
ID: 1137134 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/1137134
ID: 1137138 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1137138
ID: 1137139 Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1137139
ID: 1137142 Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/1137142
ID: 1137143 Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/1137143
ID: 1137144 Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/1137144
ID: 1137152 Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/1137152
ID: 1137154 Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/1137154
ID: 1137155 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/1137155
ID: 1137156 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/1137156
ID: 1137159 Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/1137159
ID: 1137161 Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1137161
ID: 1137162 Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/1137162
ID: 1137163 Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/1137163
ID: 1137164 Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/1137164
ID: 1137185 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1137185
ID: 1137215 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1137215
ID: 1137245 Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1137245
ID: 1137246 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1137246
ID: 1137247 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1137247
ID: 1137248 Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1137248
ID: 1137249 Test: aarch64 Server-dvd-iso 
install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1137249
ID: 1137251 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1137251
ID: 1137252 Test: aarch64 Server-dv

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

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

Failed openQA tests: 35/231 (x86_64), 30/161 (aarch64)

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

ID: 1136662 Test: x86_64 Server-dvd-iso 
install_blivet_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1136662
ID: 1136716 Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/1136716
ID: 1136824 Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/1136824
ID: 1136844 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1136844
ID: 1136845 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1136845
ID: 1136863 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1136863
ID: 1136864 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1136864
ID: 1136866 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1136866
ID: 1136868 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1136868
ID: 1136871 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1136871
ID: 1136873 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1136873
ID: 1136890 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1136890
ID: 1136891 Test: x86_64 Workstation-upgrade desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1136891
ID: 1136892 Test: x86_64 Workstation-upgrade 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1136892
ID: 1136895 Test: x86_64 Workstation-upgrade desktop_printing
URL: https://openqa.fedoraproject.org/tests/1136895
ID: 1136899 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1136899
ID: 1136902 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1136902
ID: 1136903 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1136903
ID: 1136904 Test: x86_64 Workstation-upgrade desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1136904
ID: 1136905 Test: x86_64 Workstation-upgrade evince
URL: https://openqa.fedoraproject.org/tests/1136905
ID: 1136910 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1136910
ID: 1136914 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1136914
ID: 1136915 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1136915
ID: 1136922 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1136922
ID: 1136923 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1136923
ID: 1136925 Test: aarch64 Workstation-upgrade evince@uefi
URL: https://openqa.fedoraproject.org/tests/1136925
ID: 1136965 Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/1136965
ID: 1137067 Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1137067
ID: 1137076 Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1137076

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

ID: 1136704 Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/1136704
ID: 1136720 Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1136720
ID: 1136722 Test: x86_64 Workstation-live-iso evince
URL: https://openqa.fedoraproject.org/tests/1136722
ID: 1136726 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1136726
ID: 1136732 Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1136732
ID: 1136734 Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1136734
ID: 1136735 Test: x86_64 Workstation-live-iso desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1136735
ID: 1136736 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org

Fedora-IoT-36-20220219.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

ID: 1137580 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1137580
ID: 1137581 Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1137581
ID: 1137582 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1137582
ID: 1137597 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1137597

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

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

Skipped non-gating openQA tests: 26 of 31
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64

[Sérgio Basto]

On Mon, 2022-02-14 at 11:28 +, Sérgio Basto wrote:
> On Mon, 2022-02-14 at 10:34 +0100, Michal Schorm wrote:
> > The time had to come, when two packages would generate the same
> > hash.
> > 
> > I was hit by:
> > ---
> > Error: Transaction test error:
> >   file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> > conflicts between attempted installs of discord-0.0.16-
> > 1.fc35.x86_64
> > and skypeforlinux-8.79.0.95-1.x86_64
> > ---
> > some time ago but since neither is a package maintained by Fedora
> > Project maintainers, no one gave a damn about the core of the
> > issue.
> > That time, I got one of the apps as a Flatpak instead, but not all
> > packages have such workarounds at hand.
> 
> yeah , thank you for reminder these cases (with electron apps)
> 
> we fixed with `%global debug_package %{nil}`

is fixed with %global _build_id_links none


> > --
> > 
> > Michal Schorm
> > Software Engineer
> > Core Services - Databases Team
> > Red Hat
> > 
> > --
> > 
> > On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok 
> > wrote:
> > > 
> > > Hey,
> > > apparently some ELF files are identical between Fedora's pypy3.7-
> > > libs and
> > > pypy3.8-libs packages.
> > > 
> > > On Fedora 34, this leads to installation conflict:
> > > 
> > > Error: Transaction test error:
> > >    file /usr/lib/.build-
> > > id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/c9/e94d839699198b0e87c334f8e03160fec054de from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > >    file /usr/lib/.build-
> > > id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
> > > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > > from package
> > > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > > 
> > > As reported in https://bugzilla.redhat.com/2053880
> > > 
> > > I've read all the previous discussion about this on Fedora devel
> > > list, but I
> > > still have no idea what should I do to prevent this conflict.
> > > 
> > > Moving the files to a common component seems like a bad idea
> > > given
> > > it's not
> > > "two packages bundle the same thing" but rather "two packages
> > > built
> > > in a
> > > different way".
> > > 
> > > I see this:
> > > 
> > > https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.in#L177
> > > 
> > > %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
> > > 
> > > I suppose I could pass in %{NAME} as well, right?
> > > 
> > > What are the side effects for changing the seed like this?:
> > > 
> > > %global __debug_install_post \
> > > 
> > > %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-
> > > id%-seed%s+"',
> > > rpm.expand('--build-id-seed "%{NAME}-')))}
> > > 
> > > 
> > > Actually, should RPM pass %{NAME} by default? Or at least have a
> > > macro I could
> > > redefine in a less cryptic and fragile way?
> > > 
> > > --
> > > Miro Hrončok
> > > --
> > > Phone: +420777974800
> > > IRC: mhroncok
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to
> > > devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it:
> > > htt

Nate158

[WATCHARIN Torwong]

%global pypi_name HyperKitty
%global prerel 1

Name:   hyperkitty
Version:1.1.5
Release:%{?prerel:0.}1%{?dist}
Summary:A web interface to access GNU Mailman v3 archives

License:GPLv3
URL:https://gitlab.com/mailman/hyperkitty
Source0:
http://pypi.python.org/packages/source/H/%{pypi_name}/%{pypi_name}-%{version}%{?prerel:.dev0}.tar.gz

# Patch settings to use the FHS
Patch0: hyperkitty-fhs.patch

BuildArch:  noarch

BuildRequires:  python-devel
BuildRequires:  python-sphinx
BuildRequires:  systemd
# Unit tests in %%check
BuildRequires:  python-django-gravatar2
BuildRequires:  python-django-q
BuildRequires:  python-django-rest-framework >= 2.2.0
BuildRequires:  python-django-compressor
BuildRequires:  python-rjsmin
BuildRequires:  sassc
BuildRequires:  python-mailman-client >= 3.1.1
BuildRequires:  python-robot-detection
BuildRequires:  pytz
BuildRequires:  python-django-paintstore
BuildRequires:  python-django >= 1.8
BuildRequires:  python-dateutil
BuildRequires:  python-networkx
BuildRequires:  python-enum34
BuildRequires:  python-django-haystack >= 2.5.0
BuildRequires:  python-django-extensions
BuildRequires:  python-django-mailman3
BuildRequires:  python-lockfile
# Unit tests only
BuildRequires:  python-beautifulsoup4
BuildRequires:  python-lxml
BuildRequires:  python-mock
BuildRequires:  python-whoosh

# SELinux
BuildRequires:  checkpolicy, selinux-policy-devel, 
/usr/share/selinux/devel/policyhelp
BuildRequires:  hardlink

%{?systemd_requires}
Requires:   python-django-gravatar2
Requires:   python-django-rest-framework >= 2.2.0
Requires:   python-django-q
Requires:   python-django-compressor
Requires:   python-rjsmin
Requires:   sassc
Requires:   python-mailman-client >= 3.1.1
Requires:   python-robot-detection
Requires:   pytz
Requires:   python-django-paintstore
Requires:   python-django >= 1.8
Requires:   python-dateutil
Requires:   python-networkx
Requires:   python-enum34
Requires:   python-django-haystack >= 2.5.0
Requires:   python-django-extensions
Requires:   python-django-mailman3
Requires:   python-lockfile


%description
HyperKitty is an open source Django application under development. It aims at
providing a web interface to access GNU Mailman archives.
The code is available from: https://gitlab.com/mailman/hyperkitty .
The documentation can be browsed online at https://hyperkitty.readthedocs.org .


%package selinux
%global selinux_variants mls targeted
Summary:SELinux policy module for %{name}
Requires:   %{name} = %{version}-%{release}
%{!?_selinux_policy_version: %global _selinux_policy_version %(sed -e 
's,.*selinux-policy-\\([^/]*\\)/.*,\\1,' /usr/share/selinux/devel/policyhelp 
2>/dev/null)}
%if "%{_selinux_policy_version}" != ""
Requires:  selinux-policy >= %{_selinux_policy_version}
%endif

Requires(post):   /usr/sbin/semodule, /sbin/restorecon, /sbin/fixfiles, %{name}
Requires(postun): /usr/sbin/semodule, /sbin/restorecon, /sbin/fixfiles, %{name}

%description selinux
This is the SELinux module for %{name}, install it if you are using SELinux.



%prep
%setup -q -n %{pypi_name}-%{version}%{?prerel:.dev0}
%patch0 -p0

# Remove bundled egg-info
rm -rf %{pypi_name}.egg-info
# remove shebang on manage.py
sed -i -e '1d' example_project/manage.py
# remove executable permissions on wsgi.py
chmod -x example_project/wsgi.py
# remove __init__.py in example_project to prevent it from being
# installed (find_package won't find it). It's empty anyway.
rm -f example_project/__init__.py

# SELinux
mkdir SELinux
echo '%{_localstatedir}/lib/%{name}/sites(/.*)? 
gen_context(system_u:object_r:httpd_sys_content_t,s0)' \
> SELinux/%{name}.fc
# remember to bump the following version if the policy is updated
echo "policy_module(%{name}, 1.0)" > SELinux/%{name}.te


%build
%{__python} setup.py build

# generate html docs
sphinx-build doc html
# remove the sphinx-build leftovers
rm -rf html/.{doctrees,buildinfo}

# SELinux
cd SELinux
for selinuxvariant in %{selinux_variants}; do
  make NAME=${selinuxvariant} -f /usr/share/selinux/devel/Makefile
  mv %{name}.pp %{name}.pp.${selinuxvariant}
  make NAME=${selinuxvariant} -f /usr/share/selinux/devel/Makefile clean
done
cd -


%install
rm -rf %{buildroot}
%{__python} setup.py install --skip-build --root %{buildroot}

# Install the Django files
mkdir -p %{buildroot}%{_sysconfdir}/%{name}/sites/default
cp -p example_project/{manage,settings,urls,wsgi}.py \
%{buildroot}%{_sysconfdir}/%{name}/sites/default/
touch --reference example_project/manage.py \
%{buildroot}%{_sysconfdir}/%{name}/sites/default/__init__.py
# Apache HTTPd config file
install -p -m 644 -D example_project/apache.conf \
 %{buildroot}/%{_sysconfdir}/httpd/conf.d/hyperkitty.conf
touch --reference example_project/apache.conf \
%{buildroot}/%{_sysconfdir}/httpd/conf.d/hyperkitty.conf
# SQLite databases directory, static f

Re: Preventing account takeovers through expired domains

[Björn Persson]

Zbigniew Jędrzejewski-Szmek wrote:
> I think it'd be better to check the status weekly and only require
> account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋
> times in a row (where N=quarantine length in days).

It will be fine as long as it's done before the domain is released for
registration. Let's just not make it so tight that a little unscheduled
downtime can open an attack window.

Björn Persson


pgpqiv4u1U4Nr.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: F36 Change: DIGLIM (System-Wide Change proposal)

[David Sastre]

(Secure Boot is concerned only with verifying the trustworthiness of the
bootloader.
>From https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html:

The Kernel Lockdown feature is designed to prevent both direct
and indirect access to a running kernel image, attempting to
protect against unauthorized modification of the kernel image and
to prevent access to security and cryptographic data located in
kernel memory, whilst still permitting driver modules to be
loaded.

eBPF does not require loading additional kernel modules, perhaps you were
thinking of systemtap?,
nor does it need to modify the kernel image.)

To verify this works on current stable, you can try:

# hostnamectl | rg -i cpe
 CPE OS Name: cpe:/o:fedoraproject:fedora:35

# bootctl | rg -i secure.*boot
systemd-boot not installed in ESP.
  Secure Boot: enabled

# cat /sys/kernel/security/lockdown
none [integrity] confidentiality

# rpm -q bcc-tools
bcc-tools-0.21.0-1.fc35.x86_64

# rpm -ql bcc-tools | rg bitesize
/usr/share/bcc/tools/bitesize
/usr/share/bcc/tools/doc/bitesize_example.txt
/usr/share/man/man8/bcc-bitesize.8.gz

# /usr/share/bcc/tools/bitesize
Tracing block I/O... Hit Ctrl-C to end.
^C
Process Name = dmcrypt_write/2
 Kbytes  : count distribution
 0 -> 1  : 0|
 |
 2 -> 3  : 0|
 |
 4 -> 7  : 195  |**
 |
 8 -> 15 : 42   |**
 |
16 -> 31 : 756
 ||
32 -> 63 : 166  |
 |
64 -> 127: 24   |*
  |
   128 -> 255: 5|
 |
   256 -> 511: 99   |*
  |
...

The bcc-tools package is a collection of eBPF programs (
https://github.com/iovisor/bcc).

Alternatively, the much simpler
https://gist.github.com/lizrice/47ad44a15cce912502f8667a403f5649#file-hello_world-py
(requires python3-bcc):

# cat << 'EOF' > hi.py
#!/usr/bin/python
from bcc import BPF

prog = """
int hello(void *ctx) {
bpf_trace_printk("Hello world\\n");
return 0;
}
"""

b = BPF(text=prog)
clone = b.get_syscall_fnname("clone")
b.attach_kprobe(event=clone, fn_name="hello")
b.trace_print()
> EOF

# strace -e bpf ./hi.py

Hope that helps.



On Fri, Feb 18, 2022 at 6:50 PM Fabio Valentini 
wrote:

> On Fri, Feb 18, 2022 at 4:27 PM Roberto Sassu via devel
>  wrote:
> >
> > Hi everyone
> >
> > I have very exciting news to share.
> >
> > Given the difficulty to have the DIGLIM kernel patches
> > accepted, I checked if I could achieve the same goals
> > with an eBPF program.
> >
> > I focused only on the functionality side, it is probably
> > required some support from the kernel to have the
> > same security guarantees of an LSM integrated in the
> > kernel.
> >
> > But, at least for the functionality part, I would say that
> > thanks to the very extensive support from eBPF, I managed
> > to almost match what I provided with the kernel patches
> > (at least for appraisal, not for measurement).
> >
> > This is the repo with the code:
> >
> > https://github.com/robertosassu/diglim-ebpf
> >
> > and the Copr project with binary packages:
> >
> > https://copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM-eBPF/
> >
> > Unfortunately, due to a feature introduced only recently
> > (allow sleepable programs to use the inode map), it will
> > work only with Fedora 36. Probably, commit 0fe4b381a59e
> > ("bpf: Allow bpf_local_storage to be used by sleepable programs)
> > applied to the kernel 5.16 would be sufficient to use
> > DIGLIM eBPF also in Fedora 35.
> >
> > Unlike the previous version of DIGLIM, this one does not
> > have any dependency (I just had to add rpmplugin.h in
> > the rpm-devel package).
> >
> > It can be configured with two simple commands (please
> > do it in a testing VM):
> >
> > # dnf copr enable robertosassu/DIGLIM-eBPF
> > # diglim_setup.sh install --default
> >
> > After reboot, the kernel will refuse to execute anything
> > that is not in a package. Updating a package or installing
> > new ones is supported, DIGLIM eBPF takes care of loading
> > the new reference values.
> >
> > Adding custom software is also possible, as shown with the
> > following commands:
> >
> > # ./script.sh
> > -bash: ./script.sh: /bin/bash: bad interpreter: Operation not permitted
> > # compact_gen -d /etc/digest_lists -i script.sh
> > # diglim_user_client -o add -p
> /etc/digest_lists/0-file_list-compact-script.sh
> > Digest list command successful
> > # ./script.sh
> > Hello world!
> >
> > I know it is too late for Fedora 36, but I hope you could
> > consider this version for Fedora 37. In the meantime, I will
> > work on the security guarantees (signature verification of
> > the digest lists, avoid unplugging of the LSM).
> >
> > Any comment or suggestion is very appreciated!
> >
> > Thanks
> >
> > Roberto
>
> I seem to remember discussions about eBPF programs having certain
> limitations (related to kernel Lockdown patches and Se

Re: GNOME (and Cinnamon) issues in Rawhide: status report, including gnome-bluetooth soname issues

[Kevin Kofler via devel]

Kevin Fenzi wrote:
> About a year ago I asked fesco to add
> 
> "In exceptional cases, releng may untag packages."
> 
> https://pagure.io/fesco/fesco-docs/pull-request/40

Well, this is very vague, because nothing defines what an "exceptional case" 
is.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GNOME (and Cinnamon) issues in Rawhide: status report, including gnome-bluetooth soname issues

[Miro Hrončok]

On 16. 02. 22 9:03, Adam Williamson wrote:

Full version: gnome-shell and mutter 42~beta builds were run yesterday.
For Fedora 36 they were done in a sidetag, but for Rawhide, no sidetag
yet existed, so unfortunately they went straight to the main Rawhide
tag and were included in yesterday's compose.


Hello Adam.

You make it sound like the builds were submitted to a side tag but since it did 
not yet exist, they accidentally slipped trough into rawhide. As far as I 
understand how things work, that does not sound realistic. What actually 
happened here? There was no rawhide side tag yet, so the maintainers have made 
a choice to build the updated packages in rawhide directly?


I am not asking to point fingers, but I'd like to ensure that whoever have made 
this decision will know better the next time, so we can avoid this kind of a 
problem in the future.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Boian Bonev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I have got a pull request [1] that implements installing iotop-c with the
NET_ADMIN capability by default and I am trying to evaluate if that is OK or
not.

Currently iotop-c will only allow to be run as root. In case it is run as some
other user, it will advise to use sudo, or alternatively add the NET_ADMIN
capability to the binary:

sudo setcap 'cap_net_admin+eip' /iotop

Obviously that will have to be redone after each update, adding some
inconvenience for admins who decide to allow that for non-root users. I have
never considered installing it suid - that would be an overkill and may
introduce security problems. I always use it as root and have never given that
too much thought, also never before did deep analyses of the consequences of
the above setcap.

Here is a brief list of the consequences of allowing non-root users to run it
by the setcap:

- - Process IO usage will be exposed [maybe OK]
- - Process list and command lines will be exposed (same as other tops) [safe]
- - Re-nicing own processes to rt/* will not work [safe]
- - Re-nicing non-own processes will not work [safe]
- - task_delayacct sysctl toggle (Ctrl-T) will not work [safe]
- - There are no other networking operations besides TASKSTATS from
NETLINK_GENERIC that would allow the unprivileged user do privileged tasks via
the higher capped binary [safe]

As a summary it seems that accepting the PR is 99% OK, but I'd prefer to get
more opinions before doing so.

With best regards,
b.

[1] https://src.fedoraproject.org/rpms/iotop-c/pull-request/1
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmIRkDEACgkQE2VyCRPS
8i32ww//dRzxVtff8+8qQ2ujLwf49ZigGdawkgdnJRuE+0oBDV30yycENblSLNWB
8FlidJcA+ZkoWf9WyoRvXydPcnuEhsr7y9UxyS/XA6l4iHHpUn7SJ/i79KAmVb8J
uuyWDBa23fZ4P22fy8/EklCzACWDeiYwS/jv+fwr8oLjEZ6nG+kjmMDIx5I2oA8J
vAfhCRLSTBXTQnWRs9MMxMIjQ9dcTvzOdv8ZPq+lVJuG6xrinLrH00XWLmDC7Dgh
/Ie2hvuHFCmId8BBAN5I47bh57ly4aZH0QKVpQL7x5bOYJDF1R27NHW660MxFZay
4xCZwYkLBcUtcm9R9SG8cZCd0nDptMRwmpvxu26QgFFl5hJgngdq4xmp3xsS/W2Y
JmQ7eTB+ypCVzd0QiQNHIfP1I+6NQbbakA+YIfiT9Uk1Z610IsO3cGW3tr2mSiBW
5/2fb2kU/vK4f2QPFwXJU8PYdJO/c9/zTFoRHomWG/MQx0zhNM8h0sK1tdxLp4V2
wuU/8wihpJx+rAofbmf2FrLowRYshiKqKeGYEWiWHLUAqWWKlBXkBiV5PY8l/YNx
Ta8Kd9aK00aezFmYa3TOHQyJYBuChdp/zqYfhRfRveXKj3TJMRW9MlgDtvuXXfUu
ukpSZWgR8twIhh+1QlS5rWZILIyVcdd0lNOSUYb2/i41bSREXkA=
=EJ2s
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: PSA: GTK-RS 0.15 update coming to F36+

[Fabio Valentini]

On Mon, Feb 14, 2022 at 9:45 PM Fabio Valentini  wrote:
>
> I will leave the side tags open until Sunday, two days before the beta
> freeze goes into effect.

This is now done. The side tags have been merged into rawhide and f36.
Please submit further builds directly for rawhide and f36.

I have also retired all packages that have been dropped by upstream
and/or that are no longer useful and/or that have not been ported to
the latest version (i.e. the list posted in my last email, minus
msgbox, which has since been ported and updated). Let's hope that
releng can figure out how to properly retire packages again ;)

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

[Hirotaka Wakabayashi via devel]

 Hello Neal. Thank you for reply! I will firstly ask to update the main package.

I think it's ideal if Fedora users can always use the latest packages and they
don't use inactive(EOL?) packages naturally.

 I don't completely understand the Fedora infra, but I am wondering if a mass
rebuild can skip rebuilding packages that contain version number in their
package name or can file them as FTBFS bugs. If so, the package maintainers
will request rebuild if they really want the packages. I believe this change is 
unrealistic but I think this may stop Fedora users using EOL-version package 
like php-guzzlehttp-guzlle.

Regrads,
Hirotaka

On Saturday, February 19, 2022, 10:13:20 PM GMT+9, Neal Gompa 
 wrote:  
 
 On Sat, Feb 19, 2022 at 7:59 AM Hirotaka Wakabayashi via devel
 wrote:
>
> 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.
>

The preference is to update the main package to the latest version,
and in the event the older one is needed, branch that as a
compatibility package using the compatibility package guidelines.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

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

[Demi Marie Obenour]

On 2/19/22 19:49, Boian Bonev wrote:
> Hello,
> 
> I have got a pull request [1] that implements installing iotop-c with the
> NET_ADMIN capability by default and I am trying to evaluate if that is OK or
> not.
> 
> Currently iotop-c will only allow to be run as root. In case it is run as some
> other user, it will advise to use sudo, or alternatively add the NET_ADMIN
> capability to the binary:
> 
> sudo setcap 'cap_net_admin+eip' /iotop
> 
> Obviously that will have to be redone after each update, adding some
> inconvenience for admins who decide to allow that for non-root users. I have
> never considered installing it suid - that would be an overkill and may
> introduce security problems. I always use it as root and have never given that
> too much thought, also never before did deep analyses of the consequences of
> the above setcap.
> 
> Here is a brief list of the consequences of allowing non-root users to run it
> by the setcap:
> 
> - Process IO usage will be exposed [maybe OK]
> - Process list and command lines will be exposed (same as other tops) [safe]
> - Re-nicing own processes to rt/* will not work [safe]
> - Re-nicing non-own processes will not work [safe]
> - task_delayacct sysctl toggle (Ctrl-T) will not work [safe]
> - There are no other networking operations besides TASKSTATS from
> NETLINK_GENERIC that would allow the unprivileged user do privileged tasks via
> the higher capped binary [safe]
> 
> As a summary it seems that accepting the PR is 99% OK, but I'd prefer to get
> more opinions before doing so.
> 
> With best regards,
> b.
> 
> [1] https://src.fedoraproject.org/rpms/iotop-c/pull-request/1

My main worry would be memory corruption vulnerabilities in C.  This
could be avoided if iotop was written in a memory safe language, or
if it uses privilege separation so that only a small part of the code
actually runs with elevated privileges.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Adam Williamson]

On Fri, 2022-02-18 at 13:54 +0100, Lennart Poettering wrote:
> 
> sudo is what users/admins use. pkexec is what (desktop) programs often use.

In which case we can have the programs that use it depend on it, so at
least we have those requirements mapped distinctly. To me it makes more
sense to say "let's install pkexec when we are also installing
something that uses it" than "let's install pkexec any time we install
polkit".

> Then don't. But whether you use it or whether it's "legacy"/should go
> away are two distinct questions.

I agree, but your argument read to me like "we must keep it installed
even when no program that uses it is installed, for interactive use",
which I disagree with.

I think focusing on the word "legacy" misses the point. The real meat
of the idea for me is "let's only install it when it's needed", which I
think would be good.

Still, if it's as tied in to Workstation as it seems to be, the effort
may not be worthwhile. We'd only ultimately be able to drop it, maybe,
from minimal and Server installs. If it still has to be in KDE and
Workstation installs, the value of doing all the work to separate it
and find all the packages that use it may not be worthwhile.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GNOME (and Cinnamon) issues in Rawhide: status report, including gnome-bluetooth soname issues

[Adam Williamson]

On Sun, 2022-02-20 at 00:39 +0100, Miro Hrončok wrote:
> On 16. 02. 22 9:03, Adam Williamson wrote:
> > Full version: gnome-shell and mutter 42~beta builds were run yesterday.
> > For Fedora 36 they were done in a sidetag, but for Rawhide, no sidetag
> > yet existed, so unfortunately they went straight to the main Rawhide
> > tag and were included in yesterday's compose.
> 
> Hello Adam.
> 
> You make it sound like the builds were submitted to a side tag but since it 
> did 
> not yet exist, they accidentally slipped trough into rawhide. As far as I 
> understand how things work, that does not sound realistic. What actually 
> happened here? There was no rawhide side tag yet, so the maintainers have 
> made 
> a choice to build the updated packages in rawhide directly?
> 
> I am not asking to point fingers, but I'd like to ensure that whoever have 
> made 
> this decision will know better the next time, so we can avoid this kind of a 
> problem in the future.

Yes, that's basically what happened. We've already talked about it on
IRC so I didn't see the point in throwing anybody under any buses.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Dan Čermák]

Hi Boian,

On February 20, 2022 12:49:53 AM UTC, Boian Bonev  wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Hello,
>
>I have got a pull request [1] that implements installing iotop-c with the
>NET_ADMIN capability by default and I am trying to evaluate if that is OK or
>not.
>
>Currently iotop-c will only allow to be run as root. In case it is run as some
>other user, it will advise to use sudo, or alternatively add the NET_ADMIN
>capability to the binary:
>
>sudo setcap 'cap_net_admin+eip' /iotop
>
>Obviously that will have to be redone after each update, adding some
>inconvenience for admins who decide to allow that for non-root users. 

This is not really an answer to the security question, but if that remains 
unresolved, you could also introduce a sub package to iotop-c, that would 
contain a transaction file trigger on the binary and add the capability. Thus 
user would be able to opt into having iotop-c with the added capability even 
after upgrades, as long as the sub package is installed.

> I have
>never considered installing it suid - that would be an overkill and may
>introduce security problems. I always use it as root and have never given that
>too much thought, also never before did deep analyses of the consequences of
>the above setcap.
>
>Here is a brief list of the consequences of allowing non-root users to run it
>by the setcap:
>
>- - Process IO usage will be exposed [maybe OK]
>- - Process list and command lines will be exposed (same as other tops) [safe]
>- - Re-nicing own processes to rt/* will not work [safe]
>- - Re-nicing non-own processes will not work [safe]
>- - task_delayacct sysctl toggle (Ctrl-T) will not work [safe]
>- - There are no other networking operations besides TASKSTATS from
>NETLINK_GENERIC that would allow the unprivileged user do privileged tasks via
>the higher capped binary [safe]
>
>As a summary it seems that accepting the PR is 99% OK, but I'd prefer to get
>more opinions before doing so.
>
>With best regards,
>b.
>
>[1] https://src.fedoraproject.org/rpms/iotop-c/pull-request/1
>-BEGIN PGP SIGNATURE-
>
>iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmIRkDEACgkQE2VyCRPS
>8i32ww//dRzxVtff8+8qQ2ujLwf49ZigGdawkgdnJRuE+0oBDV30yycENblSLNWB
>8FlidJcA+ZkoWf9WyoRvXydPcnuEhsr7y9UxyS/XA6l4iHHpUn7SJ/i79KAmVb8J
>uuyWDBa23fZ4P22fy8/EklCzACWDeiYwS/jv+fwr8oLjEZ6nG+kjmMDIx5I2oA8J
>vAfhCRLSTBXTQnWRs9MMxMIjQ9dcTvzOdv8ZPq+lVJuG6xrinLrH00XWLmDC7Dgh
>/Ie2hvuHFCmId8BBAN5I47bh57ly4aZH0QKVpQL7x5bOYJDF1R27NHW660MxFZay
>4xCZwYkLBcUtcm9R9SG8cZCd0nDptMRwmpvxu26QgFFl5hJgngdq4xmp3xsS/W2Y
>JmQ7eTB+ypCVzd0QiQNHIfP1I+6NQbbakA+YIfiT9Uk1Z610IsO3cGW3tr2mSiBW
>5/2fb2kU/vK4f2QPFwXJU8PYdJO/c9/zTFoRHomWG/MQx0zhNM8h0sK1tdxLp4V2
>wuU/8wihpJx+rAofbmf2FrLowRYshiKqKeGYEWiWHLUAqWWKlBXkBiV5PY8l/YNx
>Ta8Kd9aK00aezFmYa3TOHQyJYBuChdp/zqYfhRfRveXKj3TJMRW9MlgDtvuXXfUu
>ukpSZWgR8twIhh+1QlS5rWZILIyVcdd0lNOSUYb2/i41bSREXkA=
>=EJ2s
>-END PGP SIGNATURE-
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: 
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives: 
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>Do not reply to spam on the list, report it: 
>https://pagure.io/fedora-infrastructure
___
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

[Remi Collet]

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