date:20220323

Missing expected images:

Minimal raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 10/231 (x86_64), 9/161 (aarch64)

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

ID: 1192145 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1192145
ID: 1192153 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1192153
ID: 1192161 Test: x86_64 Cloud_Base-qcow2-qcow2 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1192161
ID: 1192181 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1192181
ID: 1192207 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1192207
ID: 1192218 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1192218
ID: 1192309 Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1192309
ID: 1192319 Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/1192319
ID: 1192411 Test: aarch64 universal install_scsi_updates_img@uefi
URL: https://openqa.fedoraproject.org/tests/1192411

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

ID: 1192123 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1192123
ID: 1192143 Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1192143
ID: 1192202 Test: aarch64 Server-dvd-iso mediakit_repoclosure@uefi
URL: https://openqa.fedoraproject.org/tests/1192202
ID: 1192238 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1192238
ID: 1192279 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1192279
ID: 1192293 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1192293
ID: 1192324 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1192324
ID: 1192359 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1192359
ID: 1192397 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1192397
ID: 1192418 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1192418

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

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

ID: 1192214 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1192214
ID: 1192235 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1192235
ID: 1192252 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1192252
ID: 1192262 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1192262
ID: 1192284 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1192284
ID: 1192317 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/1192317
ID: 1192322 Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/1192322
ID: 1192339 Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1192339
ID: 1192345 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1192345
ID: 1192346 Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1192346
ID: 1192403 Test: aarch64 universal upgrade_2_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1192403
ID: 1192405 Test: aarch64 universal upgrade_2_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1192405
ID: 1192408 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1192408

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

ID: 1192105 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1192105
ID: 1192109 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1192109
ID: 1192120 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1192120
ID: 1192130 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests

Re: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

On Wed, 2022-03-23 at 18:13 -0400, Elliott Sales de Andrade wrote:
> > 
> > 1) Neat trick: I'm pretty sure the buildroot override only needs to be
> > valid until all the build dependencies have been installed. For my
> > polymake rebuild, I put the override back in place, fired the polymake
> > build, waited till all the build tasks for the different arch had
> > installed build dependencies, then expired the override again. It
> > doesn't need to stay valid for the whole time the actual compilation
> > stage is happening.
> > 
> 
> Note, this override isn't strictly needed either. You can create a
> side tag, and tag in _any_ build you need to fix things. Pretty sure
> you can even tag in older versions of things if necessary. You just
> have to remember to untag the extra builds before creating the update
> in Bodhi, if you're creating it from the side tag.

Yeah, I could've made a new side tag for this, but at this point the
override existed and I had it open in a browser tab so I could
basically turn it off and on like a light switch, so I just went with
that. :D I was just noting this as a detail about how buildroot
overrides work, if you're really determined to use one.
-- 
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: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

2022-03-23 Thread Elliott Sales de Andrade

On Wed, Mar 23, 2022 at 12:16 PM Adam Williamson
 wrote:
>
> On Wed, 2022-03-23 at 08:39 +, Paul Howarth wrote:
> >
> > OK, so this is largely my fault. Whilst I didn't do the initial perl
> > 5.34.1 build and update, I did set up the buildroot override and the
> > builds of the two packages (perl-PAR-Packer and polymake) that have
> > hard dependencies on the specific perl version they were built against.
> > Unfortunately the polymake build took over 24 hours on armv7hl but
> > after that I could have and should have expired the buildroot override
> > to prevent the follow-up issues affecting other perl-related builds.
> > The issue was already known about and it was already planned to do the
> > forthcoming update for f35 to perl 5.34.1 in a side tag
> > (https://bugzilla.redhat.com/show_bug.cgi?id=2064808#c5).
>
> Oh sorry, forgot to mention a couple of other things:
>
> 1) Neat trick: I'm pretty sure the buildroot override only needs to be
> valid until all the build dependencies have been installed. For my
> polymake rebuild, I put the override back in place, fired the polymake
> build, waited till all the build tasks for the different arch had
> installed build dependencies, then expired the override again. It
> doesn't need to stay valid for the whole time the actual compilation
> stage is happening.
>

Note, this override isn't strictly needed either. You can create a
side tag, and tag in _any_ build you need to fix things. Pretty sure
you can even tag in older versions of things if necessary. You just
have to remember to untag the extra builds before creating the update
in Bodhi, if you're creating it from the side tag.

> 2) Just to note what I wound up doing here - aside from the special
> polymake case, I found (I hope) all the packages that got built against
> 5.34.1, bumped and rebuilt them against 5.34.0, and edited the
> standalone updates to have the new builds, which will work with both
> 5.34.0 and 5.34.1, so whatever order they get pushed in things should
> be OK.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>

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

Unretiring vorbisgain

2022-03-23 Thread Peter Oliver

I intend to take ownership of the vorbisgain pacakge.  It was retired last week 
having been orphaned for more than six weeks.

I am sending this email as in the procedure at 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
___
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: 20220323.n.1 changes

2022-03-23 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20220323.n.0
NEW: Fedora-Rawhide-20220323.n.1

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

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

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

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

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  389-ds-base-2.1.1-1.fc37
Old package:  389-ds-base-2.1.0-1.fc36
Summary:  389 Directory Server (base)
RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-libs 389-ds-base-snmp 
cockpit-389-ds python3-lib389
Size: 21.97 MiB
Size change:  2.38 MiB
Changelog:
  * Wed Mar 23 2022 Mark Reynolds  - 2.1.1-1
  - Bump version to 2.1.1
  - Issue 5230 - Race condition in RHDS disk monitoring functions
  - Issue 4299 - UI - Add CoS funtionality (#5196)
  - Issue 5225 - UI - impossible to manually set entry cache
  - Issue 5186 - UI - Fix SASL Mapping regex test feature
  - Issue 5221 - User with expired password can still login with full privledges
  - Issue 5218 - double-free of the virtual attribute context in persistent 
search (#5219)
  - Issue 5193 - Incomplete ruv occasionally returned from ruv search (#5194)
  - Issue 5200 - dscontainer should use environment variables with DS_ prefix
  - Issue 5189 - memberOf plugin exclude subtree not cleaning up groups on 
modrdn
  - Issue 5051 - RFE - ADSync flatten tree (#5192)
  - Issue 5188 - UI - LDAP editor - add entry and group types
  - Issue 5184 - memberOf does not work correctly with multiple include scopes
  - Issue 5162 - BUG - error on importing chain files (#5164)
  - Issue 5186 - UI - Fix SASL Mapping regex validation and other minor 
improvements
  - Issue 5048 - Support for nsslapd-tcp-fin-timeout and 
nsslapd-tcp-keepalive-time (#5179)
  - Issue 5122 - dsconf instance backend suffix set doesn't accept backend name 
(#5178)
  - Issue 5032 - Fix configure option in specfile (#5174)
  - Issue 5176 - CI rewriter fails when libslapd.so.0 does not exist (#5177)
  - Issue 5160 - BUG - x- prefix in descr-oid can confuse oid parser (#5161)
  - Issue 5137 - RFE - improve sssd conf output (#5138)
  - Issue 5102 - BUG - container may fail with bare uid/gid (#5140)
  - Issue 5145 - Fix covscan errors
  - Issue 4721 - UI - attribute uniqueness crashes UI when there are no configs
  - Issue 5155 - RFE - Provide an option to abort an Auto Member rebuild task
  - Issue 4299 - UI - Add Role funtionality (#5163)
  - Issue 5050 - bdb bulk op fails if fs page size > 8K (#5150)
  - Issue 5149 - Build failure on EL8 - undefined reference to `twalk_r'
  - Issue 5142 - CLI - dsctl dbgen is broken
  - Issue 4678 - Added test cases


Package:  Lmod-8.6.16-1.fc37
Old package:  Lmod-8.6.12-1.fc37
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 918.58 KiB
Size change:  2.74 KiB
Changelog:
  * Sun Feb 27 2022 Orion Poplawski  - 8.6.14-1
  - Update to 8.6.14

  * Wed Mar 23 2022 Orion Poplawski  - 8.6.16-1
  - Update to 8.6.16


Package:  NetworkManager-1:1.36.4-1.fc37
Old package:  NetworkManager-1:1.36.2-1.fc37
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-initscripts-ifcfg-rh NetworkManager-initscripts-updown 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 23.59 MiB
Size change:  1.84 KiB
Changelog:
  * Tue Mar 22 2022 Beniamino Galvani  - 1:1.36.4-1
  - Update to 1.36.4 release


Package:  adwaita-icon-theme-42.0-1.fc37
Old package:  adwaita-icon-theme-42~beta-1.fc37
Summary:  Adwaita icon theme
RPMs: adwaita-cursor-theme adwaita-icon-theme adwaita-icon-theme-devel
Size: 4.80 MiB
Size change:  200.14 KiB
Changelog:
  * Mon Mar 21 2022 David King  - 42.0-1
  - Update to 42.0


Package:  at-spi2-core-2.44.0-1.fc37
Old package:  at-spi2-core-2.42.0-2.fc36
Summary:  Protocol definitions and daemon for D-Bus at-spi
RPMs: at-spi2-core at-spi2-core-devel
Size: 1.54 MiB
Size change:  3.88 KiB
Changelog:
  * Fri Mar 18 2022 David King  - 2.44.0-1
  - Update to 2.44.0


Package:  baobab-42.0-1.fc37
Old package:  baobab-42~rc-1.fc37
Summary:  A graphical directory tree analyzer
RPMs: baobab
Size: 1.53 MiB
Size change:  1.36 KiB
Changelog:
  * Mon Mar 21 20

Re: error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Werror,-Wunused-command-line-argument]

2022-03-23 Thread Gary Buhrmaster

On Wed, Mar 23, 2022 at 7:54 PM Richard Shaw  wrote:

> Clang doesn't understand some options that gcc does, and a lot of it depends 
> on the version of clang IIRC. For a while Fedora maintainers would modify 
> clang to at least silently ignore these options but now it's much easier to 
> specify the toolchain you're using:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_macros

Except, unfortunately, the el8 rpm macros don't
seem to understand the toolchain specification.

These are the days when I wish the documentation
had something like a "available/introduced as of ..."
annotation, so that one does not have to guess
if the capability exists in a certain release.  Yes,
I understand these are fedora docs, and epel is
not the primary target, but for those trying to
support packages that build in both fedora and
epel it would save some time (while there is an
epel packaging section, it does not reliably
include all the differences such as this one).
___
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 CoreOS Meeting Minutes 2022-03-23

2022-03-23 Thread Dusty Mabe

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-03-23/fedora_coreos_meeting.2022-03-23-16.28.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-03-23/fedora_coreos_meeting.2022-03-23-16.28.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-03-23/fedora_coreos_meeting.2022-03-23-16.28.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:28:21 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-03-23/fedora_coreos_meeting.2022-03-23-16.28.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:28:26)

* Action items from last meeting   (dustymabe, 16:33:21)
  * ACTION: davdunc to put a package review in for ec2-net-utils and
brainstorm on how we can use that for #601  (dustymabe, 16:34:59)

* F36: Fedora CoreOS Test Week  (dustymabe, 16:35:07)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1123
(dustymabe, 16:35:13)
  * ACTION: ravanelli and mnguyen and miabbott to work with dustymabe to
organize the test day for f36. miabbott will attempt to document the
process for future iterations  (dustymabe, 16:48:08)

* Drop libvarlink-utils from package set  (dustymabe, 16:49:18)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1130
(dustymabe, 16:49:24)
  * AGREED: We don't know of any other common uses of libvarlink-utils
on FCOS right now. We'll try removing it from `next` and send an
email about it to the list to see if that gives us any new
information. After a period of time with no issues we'll promote
that to `testing` and `stable`.  (dustymabe, 16:58:30)

* Update the VMware metadata to new, modern defaults  (dustymabe,
  16:59:13)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1119
(dustymabe, 16:59:19)
  * because of some great work by bgilbert we now have the flexibility
to use different values in the OVA for FCOS and RHCOS so each
derivative can use values most appropriate. FCOS will remain at hw
version 13 until after the vSphere 6.5/6.7 EOL date.  (dustymabe,
17:05:31)
  * the defaults were changed for FCOS to use EFI firmware and Secure
Boot by default  (dustymabe, 17:06:07)
  * LINK:

https://github.com/coreos/coreos-assembler/pull/2762/files#diff-14140576af10bcdc1ecc6b8cc85c596338ec2b0894adb8d383f7a67ba606e5bdR83
>SB is not enabled here  (travier, 17:11:11)
  * ACTION: miabbott to send an email to the list about planned updates
to the OVA  (dustymabe, 17:12:21)

* Unable to disable zincati.service using Ignition   (dustymabe,
  17:13:25)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/392
(dustymabe, 17:13:32)
  * there was no response to last week's request for feedback on
https://github.com/systemd/systemd/pull/15205 so we'll pursue a
workaround solution.   (dustymabe, 17:16:29)
  * ACTION: jlebon bgilbert travier to discuss potential solutions for
#392 and update the ticket and present the outcome at a future
meeting.  (dustymabe, 17:25:48)

* open floor  (dustymabe, 17:26:34)

Meeting ended at 17:29:26 UTC.




Action Items

* davdunc to put a package review in for ec2-net-utils and brainstorm on
  how we can use that for #601
* ravanelli and mnguyen and miabbott to work with dustymabe to organize
  the test day for f36. miabbott will attempt to document the process
  for future iterations
* miabbott to send an email to the list about planned updates to the OVA
* jlebon bgilbert travier to discuss potential solutions for #392 and
  update the ticket and present the outcome at a future meeting.




Action Items, by person
---
* bgilbert
  * jlebon bgilbert travier to discuss potential solutions for #392 and
update the ticket and present the outcome at a future meeting.
* davdunc
  * davdunc to put a package review in for ec2-net-utils and brainstorm
on how we can use that for #601
* dustymabe
  * ravanelli and mnguyen and miabbott to work with dustymabe to
organize the test day for f36. miabbott will attempt to document the
process for future iterations
* jlebon
  * jlebon bgilbert travier to discuss potential solutions for #392 and
update the ticket and present the outcome at a future meeting.
* miabbott
  * ravanelli and mnguyen and miabbott to work with dustymabe to
organize the test day for f36. miabbott will attempt to document the
process for future iterations
  * miabbott to send an email to the list about planned updates to the
OVA
* mnguyen
  * ravanelli and mnguyen and miabbott to work with dustymabe to
organize the test day for f36. miabbott will attempt to document the
process for future iterations
* ravanelli
  * ravanelli and mnguyen and miabbott to work with dustymabe to
organize the test day for f36. miabbott will att

Re: error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Werror,-Wunused-command-line-argument]

2022-03-23 Thread Gary Buhrmaster

On Wed, Mar 23, 2022 at 6:55 PM Ron Olson  wrote:
>
> Hey all-
>
> I’m trying to build a new version of a package and got the aforementioned 
> error, but only under EPEL 8, all other builds (Rawhide, F35, F34, EPEL 9) 
> built fine. The failed build is at 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=84560380.
>
> I’m curious what I can do, but also to understand what causes this; I have 
> this same behavior on a different package where under Rawhide I see the 
> warning (but it doesn’t fail because the -Werror switch isn’t used), but 
> under F35 there is no warning at all.
>
> Thanks for any info,

The "-specs" hardening option is used for gcc, and "--config"
is used for clang.

I believe (suspect) that the el8 redhat macros do not
specify the toolchain dependent hardening flags (which
would use --config for clang).

I have no clue if RH will update the macros in el8,
but I suspect you are going to have ro do your own
equivalent.
___
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: error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Werror,-Wunused-command-line-argument]

2022-03-23 Thread Richard Shaw

On Wed, Mar 23, 2022 at 1:55 PM Ron Olson  wrote:

> Hey all-
>
> I’m trying to build a new version of a package and got the aforementioned
> error, but only under EPEL 8, all other builds (Rawhide, F35, F34, EPEL 9)
> built fine. The failed build is at
> https://koji.fedoraproject.org/koji/taskinfo?taskID=84560380.
>
> I’m curious what I can do, but also to understand what causes this; I have
> this same behavior on a different package where under Rawhide I see the
> warning (but it doesn’t fail because the -Werror switch isn’t used), but
> under F35 there is no warning at all.
>
> Thanks for any info,
>

Clang doesn't understand some options that gcc does, and a lot of it
depends on the version of clang IIRC. For a while Fedora maintainers would
modify clang to at least silently ignore these options but now it's much
easier to specify the toolchain you're using:

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

Thanks,
Richard
___
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: Problem compiling tellico in F37 (linker stage)

2022-03-23 Thread Ben Beasley

I encountered the same problem in luminance-hdr. It does not seem to 
affect all packages that link qt5-qtwebengine. I would like to know the 
root cause, but never figured it out. Instead, I was able to work around 
it by disabling LTO in my own package. More details in the bugs below.



luminance-hdr: FTBFS in Fedora Rawhide

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


Problems linking libQt5WebEngineCore.so.5.15.8

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


On 3/23/22 15:10, José Abílio Matos wrote:


Hi,

in order to rebuild tellico, to fix a FTBFS bug, I get in the link 
stage the following error:


/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so.5.15.8: undefined 
reference to `std::__cxx11::basic_string, 
std::allocator >::_M_replace_aux(unsigned long, unsigned long, 
unsigned long, char)@GLIBCXX_3.4.21'


/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so.5.15.8: undefined 
reference to `std::__cxx11::basic_string, 
std::allocator >::_M_append(char const*, unsigned 
long)@GLIBCXX_3.4.21'


/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so.5.15.8: undefined 
reference to `std::__cxx11::basic_string, 
std::allocator >::_M_construct(unsigned long, char)@GLIBCXX_3.4.21'


/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so.5.15.8: undefined 
reference to `std::__cxx11::basic_string, 
std::allocator >::_M_create(unsigned long&, unsigned 
long)@GLIBCXX_3.4.21'



This fails in x86* and arm64 and succeeds in ppc64le and x390x:

https://koji.fedoraproject.org/koji/taskinfo?taskID=84590646


Is this related to LTO? Or is it something else?


Regards,

--

José Abílio


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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

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

No missing expected images.

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

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

ID: 1191594 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1191594
ID: 1191655 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1191655
ID: 1191689 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/1191689
ID: 1191697 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1191697
ID: 1191705 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1191705
ID: 1191707 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/1191707
ID: 1191708 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/1191708
ID: 1191818 Test: x86_64 universal install_with_swap
URL: https://openqa.fedoraproject.org/tests/1191818

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

ID: 1191622 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1191622
ID: 1191721 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1191721
ID: 1191754 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1191754
ID: 1191776 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1191776
ID: 1191807 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1191807
ID: 1191842 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1191842
ID: 1191880 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1191880
ID: 1191901 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1191901

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

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

ID: 1191590 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1191590
ID: 1191605 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1191605
ID: 1191615 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1191615
ID: 1191632 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1191632
ID: 1191637 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1191637
ID: 1191639 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1191639
ID: 1191640 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1191640
ID: 1191646 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1191646
ID: 1191735 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1191735
ID: 1191736 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1191736
ID: 1191740 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1191740
ID: 1191748 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1191748
ID: 1191770 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1191770
ID: 1191783 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1191783

Passed openQA tests: 214/229 (x86_64), 146/161 (aarch64)

New passes (same test not passed in Fedora-36-20220322.n.0):

ID: 1191560 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1191560
ID: 1191625 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1191625
ID: 1191666 Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1191666
ID: 1191669 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1191669
ID: 1191670 Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1191670
ID: 1191671 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/1191671
ID: 1191672 Test: aarch64 Server-dvd-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/1191672

Problem compiling tellico in F37 (linker stage)

2022-03-23 Thread José Abílio Matos

Hi,
  in order to rebuild tellico, to fix a FTBFS bug, I get in the link stage the 
following error:
/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so.5.15.8: undefined reference to 
`std::__cxx11::basic_string, std::allocator 
>::_M_replace_aux(unsigned long, unsigned long, unsigned long, 
char)@GLIBCXX_3.4.21'
/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so.5.15.8: undefined reference to 
`std::__cxx11::basic_string, std::allocator 
>::_M_append(char const*, unsigned long)@GLIBCXX_3.4.21'
/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so.5.15.8: undefined reference to 
`std::__cxx11::basic_string, std::allocator 
>::_M_construct(unsigned long, char)@GLIBCXX_3.4.21'
/usr/bin/ld: /usr/lib64/libQt5WebEngineCore.so.5.15.8: undefined reference to 
`std::__cxx11::basic_string, std::allocator 
>::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21'

This fails in x86* and arm64 and succeeds in ppc64le and x390x:
https://koji.fedoraproject.org/koji/taskinfo?taskID=84590646

Is this related to LTO? Or is it something else?

Regards,
-- 
José Abílio___
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

error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Werror,-Wunused-command-line-argument]

2022-03-23 Thread Ron Olson

Hey all-

I’m trying to build a new version of a package and got the aforementioned 
error, but only under EPEL 8, all other builds (Rawhide, F35, F34, EPEL 9) 
built fine. The failed build is at 
https://koji.fedoraproject.org/koji/taskinfo?taskID=84560380.

I’m curious what I can do, but also to understand what causes this; I have this 
same behavior on a different package where under Rawhide I see the warning (but 
it doesn’t fail because the -Werror switch isn’t used), but under F35 there is 
no warning at all.

Thanks for any info,

Ron
___
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: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

2022-03-23 Thread Paul Howarth

On Wed, 23 Mar 2022 10:41:52 -0700
Kevin Fenzi  wrote:

> I wonder... should we stop allowing buildroot overrides?
> 
> Or at the very least add a admon to adding a new one in bodhi,
> explaining that you should probibly use a side tag, etc?

They're still very useful when bringing up new EPEL releases. When you
have things like the perl stack with lots of interdependencies I think
side tags would be quite unwieldy. They got lots of use (not just by
me!) when bringing up EPEL-8 and EPEL-9 in particular.

Paul.
___
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: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides


On 23. 03. 22 18:40, Mattia Verga via devel wrote:

So, now that we have side-tags to perform this kind of builds, does the
buildroot override existence still make sense? Is there any use case
that still requires BR overrides and cannot be done with side-tags?


As I've said elsewhere in the thread: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4BCV5BOA5JWEQBNIEWHPCGLBQB4QMHRW/


Happy to elaborate and seek for alternate solutions.

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

Re: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides


On 23. 03. 22 18:41, Kevin Fenzi wrote:

I wonder... should we stop allowing buildroot overrides?


I wondered this for a long time. Unfortunately I still find usecases for 
buildroot overrides. E.g. when we ship new versions of some macro packages etc. 
and we want them available even before the update reaches stable (e.g. to see 
them not breaking other packages in Kochei).


They should certainly be discouraged as a mean to update interdependent 
packages.


Or at the very least add a admon to adding a new one in bodhi,
explaining that you should probibly use a side tag, etc?


+1

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

Re: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

2022-03-23 Thread Kevin Fenzi

I wonder... should we stop allowing buildroot overrides?

Or at the very least add a admon to adding a new one in bodhi,
explaining that you should probibly use a side tag, etc?

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: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

2022-03-23 Thread Mattia Verga via devel

So, now that we have side-tags to perform this kind of builds, does the
buildroot override existence still make sense? Is there any use case
that still requires BR overrides and cannot be done with side-tags?

Mattia

___
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: fedpkg request-branch doesn't work as expected

2022-03-23 Thread Petr Pisar

V Wed, Mar 23, 2022 at 10:24:35AM -0600, Orion Poplawski napsal(a):
> When I do:
> 
> [orion@vmrawhide-rufous zabbix (rawhide *+)]$ fedpkg request-branch
> --no-auto-module --sl rawhide:2027-06-01 -- 6.0
> 
> It generates a request for a branch named "rawhide".  I'm following:
> 
> https://docs.fedoraproject.org/en-US/modularity/building-modules/fedora/adding-new-modules/
> 
> fedpkg-1.42-1.fc36.noarch
> 
> Is this a bug in fedpkg or an issue with the docs?
> 
"fedpkg request-branch --help" recommends a different syntax:

Request a branch with service level tied to the branch. In this case branch
argument has to be before --sl argument, because --sl allows multiple 
values.

fedpkg request-branch branch_name --sl bug_fixes:2020-06-01 
rawhide:2019-12-01

Especially note the "branch argument has to be before --sl argument" remark.
Maybe the "--" separator triggers a different parsing of the arguments.
I don't know the implementation details of fedpkg.

I would definitely recommend changing the Modularity documentation to follow
fedpkg help usage. Although I don't like the fedpkg syntax, we should not rely
on undocumented behaviour.

Try:

fedpkg request-branch 6.0 --no-auto-module --sl rawhide:2027-06-01

I would also like to hear an explanation of the various --sl types. I always
only used bug_fixes.

-- 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: No daemon-reload or restart with %systemd_postun_with_restart

2022-03-23 Thread Ewoud Kohl van Wijngaarden


On Mon, Mar 21, 2022 at 07:12:23PM -0400, Sam Varshavchik wrote:

Ewoud Kohl van Wijngaarden writes:


On Mon, Mar 21, 2022 at 08:27:35AM -0400, Sam Varshavchik wrote:

Ewoud Kohl van Wijngaarden writes:


On Fri, Mar 18, 2022 at 06:22:08PM -0400, Sam Varshavchik wrote:

The only thing that https://docs.fedoraproject.org/en-US/packaging-
guidelines/Scriptlets/ tells me to do is to put 
%systemd_postun_with_restart in my %post. However:


1) systemd complains that it wants a daemon-reload, in order 
to pick up an updated .service file


2) I still must manually run systemctl reload-or-restart 
--marked, in order to actually restart an updated service


It seems to be there's a missing step, in here. By comparison 
I prepared comparable .deb packages for Ubuntu, using 
dh_installsystemd in the install script. The end result:


A) The initial .deb install enabled and started the service.

B) Bumping the release, rebuilding, and installing the newer 
package results in an automatic daemon-reload and restart, 
restarting the service.


Overall .deb's systemd integration seems to go smoother 
(compared to the rest of the .deb packaging process) than 
rpm's.


Is there a specific reason why %systemd_postun_with_restart 
stops before finishing the job? Am I missing something that I 
can install, to have this happen auto-magically?


I think daemon-reload changed to file triggers in systemd 228:

https://github.com/systemd/systemd/commit/873e413323dfff4023604849c70944674ae5cd29

However, the scriptlets documentation[1] states to use 
%systemd_post with %post and %systemd_postun_with_restart with 
%postun. %Perhaps that you're using %systemd_postun_with_restart 
in %post is the source of your problems?


No, my invocation is in %postun. Furthermore, it wouldn't matter, 
since at %post time the new package and the new service unit 
should already be installed and restartable.


And, as I wrote:

1) systemd complains that it wants a daemon-reload, in order 
to pick up an updated .service file


If ot was "changed to file triggers", well, it's not working since 
nothing is getting triggered. Furthermore, 
%systemd_postun_with_restart runs:


/usr/lib/systemd/systemd-update-helper mark-restart-system-units

which does:

systemctl set-property "$unit" Markers=+needs-restart &

That's all it does. Then, as I wrote:

2) I still must manually run systemctl reload-or-restart 
--marked, in order to actually restart an updated service


So, the shipped systemd scriptlets are still, very much, under an 
impression that explicit action needs to be taken to restart 
and/or reload updated .services. But, nothing gets reloaded. The 
.service files gets marked for a restart, but, from what I can 
tell, nothing ever gets restarted.


Do you happen to have the spec file and/or the RPMs? How can we 
replicate the findings?


Take the following spec file, below, and just feed it to rpmbuild -ba.

Then, rpm -ivh the binary rpm. Then:

systemctl enable testsystemd
systemctl start testsystemd
systemctl status testsystemd

You'll get something like this:

[mrsam@jack tmp]$ systemctl status testsystemd
● testsystemd.service - testsystemd
   Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; 
enabled; vend>

   Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 10s ago
  Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 88834 (code=exited, status=0/SUCCESS)
  CPU: 2ms

Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.

Up to now, everything looks good.

Now, take this spec file, bump the release, feed it to rpmbuild again.

According to my best understanding of systemd's published 
documentation: installing an updated package should automatically 
restart the active service, shouldn't it?


But after I fed the new version to rpm -UvhF, what I got was:

[mrsam@jack tmp]$ systemctl status testsystemd | cat
Warning: The unit file, source configuration file or drop-ins of 
testsystemd.service changed on disk. Run 'systemctl daemon-reload' to 
reload units.

● testsystemd.service - testsystemd
   Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; 
enabled; vendor preset: disabled)

   Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 4min 35s ago
  Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 88834 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 76902)
   Memory: 0B
  CPU: 0
   CGroup: /system.slice/testsystemd.service

Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.

A loud complaint at the beginning that systemd wasn't reload. Same, 
unchanged, syslog timestamp from the initial start.


This is on up to date F35.

Then, at this point:

sudo systemctl daemon-reload
sudo systemctl reload-or-restart --marked

[mrsam@jack tmp]$ systemctl status testsystemd
● testsystemd.service - testsystemd
   Loaded: loaded (/usr/lib/

Fedora 36 compose report: 20220323.n.0 changes

2022-03-23 Thread Fedora Rawhide Report

OLD: Fedora-36-20220322.n.0
NEW: Fedora-36-20220323.n.0

= SUMMARY =
Added images:2
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 =
Image: Python_Classroom raw-xz aarch64
Path: Labs/aarch64/images/Fedora-Python-Classroom-36-20220323.n.0.aarch64.raw.xz
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-36-20220323.n.0.ppc64le.tar.xz

= 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

fedpkg request-branch doesn't work as expected

2022-03-23 Thread Orion Poplawski


When I do:

[orion@vmrawhide-rufous zabbix (rawhide *+)]$ fedpkg request-branch 
--no-auto-module --sl rawhide:2027-06-01 -- 6.0


It generates a request for a branch named "rawhide".  I'm following:

https://docs.fedoraproject.org/en-US/modularity/building-modules/fedora/adding-new-modules/

fedpkg-1.42-1.fc36.noarch

Is this a bug in fedpkg or an issue with the docs?


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic 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: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

On Wed, 2022-03-23 at 08:39 +, Paul Howarth wrote:
> 
> OK, so this is largely my fault. Whilst I didn't do the initial perl
> 5.34.1 build and update, I did set up the buildroot override and the
> builds of the two packages (perl-PAR-Packer and polymake) that have
> hard dependencies on the specific perl version they were built against.
> Unfortunately the polymake build took over 24 hours on armv7hl but
> after that I could have and should have expired the buildroot override
> to prevent the follow-up issues affecting other perl-related builds.
> The issue was already known about and it was already planned to do the
> forthcoming update for f35 to perl 5.34.1 in a side tag
> (https://bugzilla.redhat.com/show_bug.cgi?id=2064808#c5).

Oh sorry, forgot to mention a couple of other things:

1) Neat trick: I'm pretty sure the buildroot override only needs to be
valid until all the build dependencies have been installed. For my
polymake rebuild, I put the override back in place, fired the polymake
build, waited till all the build tasks for the different arch had
installed build dependencies, then expired the override again. It
doesn't need to stay valid for the whole time the actual compilation
stage is happening.

2) Just to note what I wound up doing here - aside from the special
polymake case, I found (I hope) all the packages that got built against
5.34.1, bumped and rebuilt them against 5.34.0, and edited the
standalone updates to have the new builds, which will work with both
5.34.0 and 5.34.1, so whatever order they get pushed in things should
be OK.
-- 
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: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

On Wed, 2022-03-23 at 08:39 +, Paul Howarth wrote:
> 
> In mitigation, my thinking was that since the f36 beta freeze is still
> ongoing, the perl update and its hard dependencies would almost
> certainly have been pushed to stable at the same time anyway. In
> addition, since those updates were created prior to the ones for
> the other modules that were incidentally built against 5.34.1, perl
> itself would have been stable before the later updates arrived. So in
> practice there probably wouldn't have been any mysterious dependency
> issues in this particular case. And whilst I could have added the
> delayed polymake build to the perl+perl-PAR-Packer update, I chose not
> to so as not to reset the timer on the perl+perl-PAR-Packer update,
> which would have set it back by 2 days and potentially resulted in
> other modules being pushed to stable before the underlying perl update.
> 
Thanks Paul! So yeah, it's true about the freeze and the ordering, but
it's still possible for undesirable things to happen, thanks to
autopush. All the updates seem to have default autopush settings - +3
karma, 14 days time. So if one of the dependent updates happened to get
+3 karma before the perl update, and the perl update wasn't submitted
manually, they could still have been submitted first.

The freeze could potentially be lifted quite soon, since go/no-go is
tomorrow, so it wouldn't necessarily save us.

And finally, since polymake depends on *exactly* the version of perl
(it's not a >= situation), I believe polymake and perl really have to
be submitted *exactly together* in order not to break anything. AIUI,
if perl gets pushed before polymake, the polymake in stable will no
longer be installable with the perl in stable. This is why I think it'd
still be best to edit polymake into the perl update, even though the
build does take forever (my rebuild is still running :|)

What might be safest overall is to edit my polymake rebuild into the
perl update when it's done, then make sure the perl update gets +1 or
+2 karma (whichever it needs) and is submitted for stable manually
ASAP.

Thanks again!
-- 
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

Rawhide users with Secure Boot enabled: DO NOT UPDATE TO GRUB2 2.06-27!

Heads up for anyone using Rawhide with Secure Boot enabled: *do not*
update to grub2 version 2.0.6-27! Due to a chain of unfortunate events,
it is in today's Rawhide compose, but is not signed with the official
Fedora SB keys and will not be trusted. If you update to it, your
system will not boot with SB enabled.

If you updated to it already, **DO NOT REBOOT**. Downgrade to 2.0.6-26
or upgrade to 2.0.6-28 (from Koji) before rebooting.

If you already updated to it and rebooted and you're stuck, I think the
easiest way to fix it is to temporarily disable secure boot, downgrade
or upgrade grub2, and enable secure boot again. This of course means
you have to trust me that it's a silly mistake and not an evil build
designed to compromise you. What can I say, that's what it is. :D If
you're concerned about that, in order to keep SB enabled you would need
to boot to some kind of alternative environment - another OS, a rescue
image - and downgrade or upgrade grub2 from there.

I'm very sorry for any trouble this causes anyone.
-- 
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

[Test-Announce] Re: Fedora 36 Candidate Beta-1.4 Available Now!

On Tue, 2022-03-22 at 08:15 +, rawh...@fedoraproject.org wrote:
> According to the schedule [1], Fedora 36 Candidate Beta-1.4 is now
> available for testing. Please help us complete all the validation
> testing! For more information on release validation testing, see:
> https://fedoraproject.org/wiki/QA:Release_validation_test_plan

So, this candidate looks good: it actually has everything it was
intended to have! Firefox and gnome-shell are the correct versions, and
all known blockers are addressed. So this compose can be considered an
RC, and we should try to do complete testing of it. Later today I'll go
through the 1.2 and 1.3 matrices and transfer any results that should
still be applicable.

Thanks folks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: [Fedora-legal-list] How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?

2022-03-23 Thread Robbie Harwood

Miro Hrončok  writes:

> If that's the case, can we please stop enforcing the signed-off-by
> thing in Fedora projects (such as various Fedora projects on Pagure or
> Bodhi on GitHub)?

My understanding is that's about provenance, not licensing per se (not a
lawyer etc.).  In any case it's up to the project maintainers.

Be well,
--Robbie


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: FESCo wants to know what you use i686 packages for

2022-03-23 Thread Steve Cossette

I know for a fact you need at least a few i686 packages to run games on 
Lutris as well (Blizzard Agent/Overwatch being one)


On 3/23/22 08:03, Germano Massullo wrote:

All these are somehow related to Steam and x86 32 bit games


# rpm -qa | grep 686 | sort
alsa-lib-1.2.6.1-3.fc35.i686
atk-2.36.0-4.fc35.i686
at-spi2-atk-2.38.0-3.fc35.i686
at-spi2-atk-debuginfo-2.38.0-3.fc35.i686
at-spi2-atk-debugsource-2.38.0-3.fc35.i686
at-spi2-core-2.42.0-1.fc35.i686
avahi-libs-0.8-14.fc35.i686
bluez-libs-5.63-1.fc35.i686
bzip2-libs-1.0.8-9.fc35.i686
cairo-1.17.4-4.fc35.i686
cairo-gobject-1.17.4-4.fc35.i686
colord-libs-1.4.5-3.fc35.i686
cups-libs-2.3.3op2-16.fc35.i686
cyrus-sasl-lib-2.1.27-14.fc35.i686
dbus-libs-1.12.22-1.fc35.i686
dconf-0.40.0-5.fc35.i686
elfutils-debuginfod-client-0.186-1.fc35.i686
elfutils-libelf-0.186-1.fc35.i686
elfutils-libs-0.186-1.fc35.i686
expat-2.4.4-1.fc35.i686
fdk-aac-free-2.0.0-7.fc35.i686
flac-libs-1.3.4-1.fc35.i686
fontconfig-2.13.94-5.fc35.i686
freetype-2.11.0-3.fc35.i686
fribidi-1.0.10-5.fc35.i686
gamemode-1.6-3.fc35.i686
gdbm-libs-1.22-1.fc35.i686
gdk-pixbuf2-2.42.6-2.fc35.i686
gdk-pixbuf2-modules-2.42.6-2.fc35.i686
glib2-2.70.5-1.fc35.i686
glibc-2.34-29.fc35.i686
glibc-gconv-extra-2.34-29.fc35.i686
glib-networking-2.70.1-1.fc35.i686
gmp-6.2.0-7.fc35.i686
gnutls-3.7.2-3.fc35.i686
graphite2-1.3.14-8.fc35.i686
gsm-1.0.19-6.fc35.i686
gstreamer1-1.20.0-1.fc35.i686
gtk2-2.24.33-5.fc35.i686
gtk3-3.24.31-2.fc35.i686
harfbuzz-2.9.1-1.fc35.i686
inih-49-4.fc35.i686
jasper-libs-2.0.33-1.fc35.i686
jbigkit-libs-2.1-22.fc35.i686
json-glib-1.6.6-1.fc35.i686
keyutils-libs-1.6.1-3.fc35.i686
krb5-libs-1.19.2-2.fc35.i686
lcms2-2.12-2.fc35.i686
libasyncns-0.8-21.fc35.i686
libatomic-11.2.1-9.fc35.i686
libblkid-2.37.4-1.fc35.i686
libbrotli-1.0.9-6.fc35.i686
libcanberra-0.30-27.fc35.i686
libcanberra-gtk2-0.30-27.fc35.i686
libcanberra-gtk3-0.30-27.fc35.i686
libcap-2.48-3.fc35.i686
libcloudproviders-0.3.1-4.fc35.i686
libcom_err-1.46.3-1.fc35.i686
libcurl-7.79.1-1.fc35.i686
libdatrie-0.2.13-2.fc35.i686
libdb-5.3.28-50.fc35.i686
libdbusmenu-16.04.0-18.fc35.i686
libdbusmenu-gtk3-16.04.0-18.fc35.i686
libdrm-2.4.110-1.fc35.i686
libedit-3.1-40.20210910cvs.fc35.i686
libepoxy-1.5.9-1.fc35.i686
libevent-2.1.12-4.fc35.i686
libffi-3.1-29.fc35.i686
libgcc-11.2.1-9.fc35.i686
libgcrypt-1.9.4-1.fc35.i686
libglvnd-1.3.4-2.fc35.i686
libglvnd-glx-1.3.4-2.fc35.i686
libgpg-error-1.43-1.fc35.i686
libgusb-0.3.9-1.fc35.i686
libICE-1.0.10-7.fc35.i686
libicu-69.1-2.fc35.i686
libidn2-2.3.2-3.fc35.i686
libjpeg-turbo-2.1.0-3.fc35.i686
libldac-2.0.2.3-9.fc35.i686
libmodman-2.0.1-25.fc35.i686
libmount-2.37.4-1.fc35.i686
libnghttp2-1.45.1-1.fc35.i686
libnsl-2.34-29.fc35.i686
libogg-1.3.5-2.fc35.i686
libpciaccess-0.16-5.fc35.i686
libpng12-1.2.57-14.fc35.i686
libpng-1.6.37-11.fc35.i686
libproxy-0.4.17-3.fc35.i686
libpsl-0.21.1-4.fc35.i686
libsbc-1.5-2.fc35.i686
libselinux-3.3-1.fc35.i686
libsepol-3.3-2.fc35.i686
libSM-1.2.3-9.fc35.i686
libsndfile-1.0.31-6.fc35.i686
libsoup-2.74.2-1.fc35.i686
libssh-0.9.6-1.fc35.i686
libstdc++-11.2.1-9.fc35.i686
libstemmer-0-17.585svn.fc35.i686
libtasn1-4.16.0-6.fc35.i686
libtdb-1.4.4-3.fc35.i686
libthai-0.1.28-7.fc35.i686
libtiff-4.3.0-4.fc35.i686
libtool-ltdl-2.4.6-50.fc35.i686
libtracker-sparql-3.2.1-1.fc35.i686
libunistring-0.9.10-14.fc35.i686
libunwind-1.5.0-1.fc35.i686
libusb1-1.0.24-4.fc35.i686
libuuid-2.37.4-1.fc35.i686
libva-2.13.0-3.fc35.i686
libvdpau-1.5-1.fc35.i686
libverto-0.3.2-2.fc35.i686
libvorbis-1.3.7-4.fc35.i686
libwayland-client-1.20.0-1.fc35.i686
libwayland-cursor-1.20.0-1.fc35.i686
libwayland-egl-1.20.0-1.fc35.i686
libwebp-1.2.2-1.fc35.i686
libX11-1.7.3.1-1.fc35.i686
libX11-xcb-1.7.3.1-1.fc35.i686
libXau-1.0.9-7.fc35.i686
libxcb-1.13.1-8.fc35.i686
libXcomposite-0.4.5-6.fc35.i686
libxcrypt-4.4.28-1.fc35.i686
libxcrypt-compat-4.4.28-1.fc35.i686
libXcursor-1.2.0-6.fc35.i686
libXdamage-1.1.5-6.fc35.i686
libXext-1.3.4-7.fc35.i686
libXfixes-6.0.0-2.fc35.i686
libXft-2.3.3-7.fc35.i686
libXi-1.7.10-7.fc35.i686
libXinerama-1.1.4-9.fc35.i686
libxkbcommon-1.3.1-1.fc35.i686
libxml2-2.9.13-1.fc35.i686
libXrandr-1.5.2-7.fc35.i686
libXrender-0.9.10-15.fc35.i686
libXScrnSaver-1.2.3-9.fc35.i686
libxshmfence-1.3-9.fc35.i686
libXtst-1.2.3-15.fc35.i686
libXxf86vm-1.1.4-17.fc35.i686
libzstd-1.5.2-1.fc35.i686
lilv-0.24.10-4.fc35.i686
llvm-libs-13.0.0-4.fc35.i686
lz4-libs-1.9.3-3.fc35.i686
mesa-dri-drivers-21.3.7-1.fc35.i686
mesa-filesystem-21.3.7-1.fc35.i686
mesa-libGL-21.3.7-1.fc35.i686
mesa-libglapi-21.3.7-1.fc35.i686
mesa-vulkan-drivers-21.3.7-1.fc35.i686
ncurses-libs-6.2-8.20210508.fc35.i686
nettle-3.7.3-2.fc35.i686
nspr-4.32.0-5.fc35.i686
nss-3.75.0-1.fc35.i686
nss-softokn-3.75.0-1.fc35.i686
nss-softokn-freebl-3.75.0-1.fc35.i686
nss-util-3.75.0-1.fc35.i686
openldap-2.4.59-3.fc35.i686
openssl-libs-1.1.1l-2.fc35.i686
openssl-pkcs11-0.4.11-4.fc35.i686
opus-1.3.1-9.fc35.i686
p11-kit-0.23.22-4.fc35.i686
pango-1.50.4-1.fc35.i686
pcre2-10.39-1.fc35.i686
pcre-8.45-1.fc35.i686
pipewire-0.3.48-1.fc35.i686
pipewire-

[IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed

2022-03-23 Thread Zdenek Dohnal


Hi all,

driverless+printer applications world of printing and scanning is coming 
in the future:


- printer driver, raw queues and other removals are planned with CUPS 
3.0, roughly in the next year,
- printer applications RPMs are waiting for cups-filters 2.0, but the 
apps are in SNAP already for people to try them,
- driverless scanning is already possible with sane-airscan, which 
supports WSD and eSCL protocols.


and since ipp-usb is in Fedora for a while (since Fedora 32), CUPS and 
sane-airscan packages started to recommend ipp-usb package, which 
unfortunately leads to expected breakage (see known issues[1] - either 
under HPLIP or golang-github-openprinting-ipp-usb) due a conflict on USB 
port.


_This breakage happens if both conditions below are met:_

- the device supports IPP-over-USB - how to find out here[2]
- the device is currently installed with a classic driver, (f.e. HPLIP - 
has its device uri starting with 'hp:/usb/'),


_The __behavior__of breakage_ is:

- for printing - the old queue is available, but when a job is sent it 
prints nothing, with errors in the logs as:


hp[3559]: io/hpmud/musb.c 515: invalid claim_interface 7/1/4: Device or 
resource busy

- for scanning - the scanner is not recognized by the classic driver, 
but sane-airscan should kick in and provide functional device, so a new 
device should appear in scanning dialog



_The breakage is __expected__for IPP-over-USB devices_, because ipp-usb 
is running on the USB port, prepared for incoming IPP requests. This 
behavior blocks the port for other binaries, which can try to access it, 
such as printing and scanning backends (pixma, hp, hpaio...).


Unfortunately there is no clean upgrade path to solve the migration 
automatically because of unrealistic requirements such as:


- the USB device would have needed to be plugged in and turned on during 
the update
- %post scriptlets don't work the same way on immutable Fedoras as on 
Fedora Linux, and other upgrade possibilities such as Leapp don't 
support Fedora upgrades AFAIK,


the fix has to be done manually.


_How to fix the breakage:_

- printing - remove the old print queue and start using CUPS temporary 
queue[3], which is supported by modern print dialogs, or install the new 
queue permanently by:


$ lpadmin -p  -v ipp://localhost:6/ipp/print -m 
everywhere -E


ipp-usb advertises the printer only to localhost at port 6 by 
default, any other USB printer capable of IPP-over-USB will be available 
at port 60001 etc...


- scanning - sane-airscan should automatically pick the device up, if 
the device supports eSCL or WSD protocols - here [4] is the growing list 
of devices, which were identified by users as they are working with 
sane-airscan.


In case you have only one device supported by the driver package and the 
driver is a list package, you can safely remove the driver package



_If the driverless setup with ipp-usb doesn't work for you:_

It would be great if you filed a bug at https://bugzilla.redhat.com for 
golang-github-openprinting-ipp-usb component after you've gone through 
the useful tricks for printing[8], 'How to fix the breakage' from this 
email and known issues of CUPS[9].


If the device is unusable for ipp-usb due a serious firmware bug, we can 
add a quirk upstream rejecting this device in ipp-usb, so the daemon 
will ignore the device and the quirk will be shared with all users - so 
the device can be again used with classic driver or with, in the future, 
with a printer application.


If user wants to go with classic drivers again, 
golang-github-openprinting-ipp-usb-0.9.20 (currently in rawhide and for 
other releases in testing repo - F36[5], F35[6], F34[7]) supports device 
quirks in /etc/ipp-usb/quirks directory. See 'man ipp-usb' for more info.

__


_Affected OS versions:_

Fedora 36+ and users who installed cups-2.3.3op2-15.fc35/fc34 updates - 
the change was reverted in cups-2.3.3op2-16.fc35/fc34, but ipp-usb is 
not removed with the new CUPS update, so it has to be removed manually 
or the setup has to be migrated ('How to fix the breakage') to ipp-usb.



_SUMMARY:_

I'm deeply sorry for the inconvenience during the breakage and for not 
announcing the change in advance via proper channels - hopefully 
driverless setup with ipp-usb can help you with using the device without 
additional drivers, proprietary binary blobs and its 'installation' (in 
case of CUPS temporary queues you don't need to install the printer at 
all, that's why installation with quotes) will be more smoother.



Thank you for your time and effort!


Zdenek


[1] 
https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_golang_github_openprinting_ipp_usb


[2] 
https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_find_out_if_my_usb_device_supports_ipp_over_usb


[3] 
https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/#_temporary_print_queues


[4] https://github.com/alexpevzner/sane-airscan#comp

Re: Qualcomm CPU / Fedora: AI-maker board project >> need support (paid)!

2022-03-23 Thread Demi Marie Obenour

On 3/22/22 11:19, Petr Pisar wrote:
> V Tue, Mar 22, 2022 at 07:30:13AM -0400, Demi Marie Obenour napsal(a):
>> All kernel-mode drivers, to be specific.  User-mode drivers are an
>> underutilized alternative for systems that have an IOMMU/SMMU.  Obviously,
>> the drivers still need to be free software for Fedora to package them, but
>> user-mode drivers have the advantage of not running with kernel privilege.
> 
> That smells like a microkernel :)

That’s because almost all drivers on a microkernel work that way 🙂.
Interrupt controller, IOMMU, and timer drivers are the main exceptions
I know of.

> I did not know it's possible. I can image
> one can program IOMMU to direct all reads and writes by a device into a memory
> mapped into a user-space process. But how can a user space process receive
> interrupts? Is there an in-kernel translation layer which presents interrupts
> to the user process somehow?

There is; see ‘Documentation/driver-api/vfio.rst’ in the kernel
source tree.  To be clear: this is not an excuse for the driver being
proprietary or of low quality, but rather a way to allow the driver to
run as a deprivileged userspace process.

> Or does it only work with the modern MSI-like
> interrupts which are a ring buffer of messages in a shared memory?
> 
> -- Petr

On x86 I believe it only supports MSI interrupts, but for a different
reason: old-style interrupts cannot be remapped, and so devices that
can create them cannot safely be assigned to an untrusted principal
(which a userspace driver is, from the kernel’s perspective).
Specifically, I believe neither Xen nor Hyper-V support device
passthrough for devices with old-style interrupts, and this is
equivalent (from a security perspective) to VFIO.  I do not know how
this works on ARM.

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

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

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

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

Missing expected images:

Minimal raw-xz armhfp

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

Failed openQA tests: 16/216 (x86_64), 13/161 (aarch64)

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

ID: 1190706 Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/1190706
ID: 1190707 Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1190707
ID: 1190764 Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1190764
ID: 1190765 Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/1190765
ID: 1190782 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1190782
ID: 1190813 Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1190813
ID: 1190833 Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1190833
ID: 1190869 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1190869
ID: 1190893 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1190893
ID: 1190907 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1190907
ID: 1190976 Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/1190976
ID: 1190980 Test: x86_64 universal install_kickstart_firewall_configured 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1190980
ID: 1191017 Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/1191017
ID: 1191022 Test: x86_64 universal install_kickstart_user_creation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1191022
ID: 1191024 Test: x86_64 universal install_kickstart_firewall_disabled 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1191024
ID: 1191025 Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/1191025
ID: 1191041 Test: aarch64 universal install_kickstart_user_creation@uefi
URL: https://openqa.fedoraproject.org/tests/1191041
ID: 1191043 Test: aarch64 universal 
install_kickstart_firewall_configured@uefi
URL: https://openqa.fedoraproject.org/tests/1191043
ID: 1191048 Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1191048

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

ID: 1190793 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1190793
ID: 1190857 Test: aarch64 Server-dvd-iso mediakit_repoclosure@uefi
URL: https://openqa.fedoraproject.org/tests/1190857
ID: 1190934 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1190934
ID: 1190948 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1190948
ID: 1190979 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1190979
ID: 1191014 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1191014
ID: 1191052 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1191052
ID: 1191062 Test: aarch64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/1191062
ID: 1191073 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1191073
ID: 1191077 Test: aarch64 universal install_kickstart_firewall_disabled@uefi
URL: https://openqa.fedoraproject.org/tests/1191077

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

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

ID: 1190775 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1190775
ID: 1190779 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1190779
ID: 1190790 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1190790
ID: 1190800 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1190800
ID: 1190807 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1190807
ID: 1190817 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1190817
ID: 1190908 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: http

Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

2022-03-23 Thread Josh Boyer

On Wed, Mar 23, 2022 at 7:05 AM Alexander Sosedkin  wrote:
>
> On Wed, Mar 23, 2022 at 12:51 AM Josh Boyer  wrote:
> >
> > On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin  
> > wrote:
> > >
> > > Hello, community, I need your wisdom for planning a disruptive change.
> > >
> > > Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> > > Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > > I believe we should start planning
> > > for the next cryptographic defaults tightening.
> > > And next time it's gonna be even more disruptive because of SHA-1 (again).
> > >
> > > SHA-1 is a hash function from 1995,
> > > which collision resistance is no longer to be relied upon for security 
> > > [1].
> > > At the same time, it's not like software has successfully migrated off it,
> > > not even close.
> > > It's not a question of "if" the world should migrate from it,
> > > sooner or later we must part ways with it.
> > > (Technically, some acute energy crisis or a collapse of civilization
> > >  forever raising the costs of computations thousandfold would also do,
> > >  but let's agree that migrating to a more modern hash is the way =)
> > >
> > > We've been disabling it in TLS, but its usage is much wider than TLS.
> > > The next agonizing step is to restrict its usage for signatures
> > > on the cryptographic libraries level, with openssl being the scariest one.
> > >
> > > Good news is, RHEL-9 is gonna lead the way
> > > and thus will take a lot of the hits first.
> > > Fedora doesn't have to pioneer it.
> > > Bad news is, Fedora has to follow suit someday anyway,
> > > and this brings me to how does one land such a change.
> >
> > Given that RHEL 9 already switched the crypto-policy defaults, and we
> > presume that future RHEL releases will not deviate from that, is this
> > change already made in ELN?  I honestly can't tell because it looks
> > like it is, but I don't see any conditionalization in the spec file
> > that would lead me to believe the same default isn't already flipped
> > in Rawhide.  That leaves me wondering what needs to be changed and
> > where at this point.
> >
> > josh
>
> No, it's neither in ELN nor in Rawhide yet.

Could you please make this change in ELN?  It might actually prove
fruitful for the broader Fedora activity because it gives you an
isolated base to see what happens.

If we already know there are other similar changes for future RHEL
releases, making those in ELN now would go a long way towards sorting
those out as well.  That can be a follow-on after SHA-1 though, which
is certainly more pressing.

josh
___
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: FESCo wants to know what you use i686 packages for

2022-03-23 Thread Germano Massullo


All these are somehow related to Steam and x86 32 bit games


# rpm -qa | grep 686 | sort
alsa-lib-1.2.6.1-3.fc35.i686
atk-2.36.0-4.fc35.i686
at-spi2-atk-2.38.0-3.fc35.i686
at-spi2-atk-debuginfo-2.38.0-3.fc35.i686
at-spi2-atk-debugsource-2.38.0-3.fc35.i686
at-spi2-core-2.42.0-1.fc35.i686
avahi-libs-0.8-14.fc35.i686
bluez-libs-5.63-1.fc35.i686
bzip2-libs-1.0.8-9.fc35.i686
cairo-1.17.4-4.fc35.i686
cairo-gobject-1.17.4-4.fc35.i686
colord-libs-1.4.5-3.fc35.i686
cups-libs-2.3.3op2-16.fc35.i686
cyrus-sasl-lib-2.1.27-14.fc35.i686
dbus-libs-1.12.22-1.fc35.i686
dconf-0.40.0-5.fc35.i686
elfutils-debuginfod-client-0.186-1.fc35.i686
elfutils-libelf-0.186-1.fc35.i686
elfutils-libs-0.186-1.fc35.i686
expat-2.4.4-1.fc35.i686
fdk-aac-free-2.0.0-7.fc35.i686
flac-libs-1.3.4-1.fc35.i686
fontconfig-2.13.94-5.fc35.i686
freetype-2.11.0-3.fc35.i686
fribidi-1.0.10-5.fc35.i686
gamemode-1.6-3.fc35.i686
gdbm-libs-1.22-1.fc35.i686
gdk-pixbuf2-2.42.6-2.fc35.i686
gdk-pixbuf2-modules-2.42.6-2.fc35.i686
glib2-2.70.5-1.fc35.i686
glibc-2.34-29.fc35.i686
glibc-gconv-extra-2.34-29.fc35.i686
glib-networking-2.70.1-1.fc35.i686
gmp-6.2.0-7.fc35.i686
gnutls-3.7.2-3.fc35.i686
graphite2-1.3.14-8.fc35.i686
gsm-1.0.19-6.fc35.i686
gstreamer1-1.20.0-1.fc35.i686
gtk2-2.24.33-5.fc35.i686
gtk3-3.24.31-2.fc35.i686
harfbuzz-2.9.1-1.fc35.i686
inih-49-4.fc35.i686
jasper-libs-2.0.33-1.fc35.i686
jbigkit-libs-2.1-22.fc35.i686
json-glib-1.6.6-1.fc35.i686
keyutils-libs-1.6.1-3.fc35.i686
krb5-libs-1.19.2-2.fc35.i686
lcms2-2.12-2.fc35.i686
libasyncns-0.8-21.fc35.i686
libatomic-11.2.1-9.fc35.i686
libblkid-2.37.4-1.fc35.i686
libbrotli-1.0.9-6.fc35.i686
libcanberra-0.30-27.fc35.i686
libcanberra-gtk2-0.30-27.fc35.i686
libcanberra-gtk3-0.30-27.fc35.i686
libcap-2.48-3.fc35.i686
libcloudproviders-0.3.1-4.fc35.i686
libcom_err-1.46.3-1.fc35.i686
libcurl-7.79.1-1.fc35.i686
libdatrie-0.2.13-2.fc35.i686
libdb-5.3.28-50.fc35.i686
libdbusmenu-16.04.0-18.fc35.i686
libdbusmenu-gtk3-16.04.0-18.fc35.i686
libdrm-2.4.110-1.fc35.i686
libedit-3.1-40.20210910cvs.fc35.i686
libepoxy-1.5.9-1.fc35.i686
libevent-2.1.12-4.fc35.i686
libffi-3.1-29.fc35.i686
libgcc-11.2.1-9.fc35.i686
libgcrypt-1.9.4-1.fc35.i686
libglvnd-1.3.4-2.fc35.i686
libglvnd-glx-1.3.4-2.fc35.i686
libgpg-error-1.43-1.fc35.i686
libgusb-0.3.9-1.fc35.i686
libICE-1.0.10-7.fc35.i686
libicu-69.1-2.fc35.i686
libidn2-2.3.2-3.fc35.i686
libjpeg-turbo-2.1.0-3.fc35.i686
libldac-2.0.2.3-9.fc35.i686
libmodman-2.0.1-25.fc35.i686
libmount-2.37.4-1.fc35.i686
libnghttp2-1.45.1-1.fc35.i686
libnsl-2.34-29.fc35.i686
libogg-1.3.5-2.fc35.i686
libpciaccess-0.16-5.fc35.i686
libpng12-1.2.57-14.fc35.i686
libpng-1.6.37-11.fc35.i686
libproxy-0.4.17-3.fc35.i686
libpsl-0.21.1-4.fc35.i686
libsbc-1.5-2.fc35.i686
libselinux-3.3-1.fc35.i686
libsepol-3.3-2.fc35.i686
libSM-1.2.3-9.fc35.i686
libsndfile-1.0.31-6.fc35.i686
libsoup-2.74.2-1.fc35.i686
libssh-0.9.6-1.fc35.i686
libstdc++-11.2.1-9.fc35.i686
libstemmer-0-17.585svn.fc35.i686
libtasn1-4.16.0-6.fc35.i686
libtdb-1.4.4-3.fc35.i686
libthai-0.1.28-7.fc35.i686
libtiff-4.3.0-4.fc35.i686
libtool-ltdl-2.4.6-50.fc35.i686
libtracker-sparql-3.2.1-1.fc35.i686
libunistring-0.9.10-14.fc35.i686
libunwind-1.5.0-1.fc35.i686
libusb1-1.0.24-4.fc35.i686
libuuid-2.37.4-1.fc35.i686
libva-2.13.0-3.fc35.i686
libvdpau-1.5-1.fc35.i686
libverto-0.3.2-2.fc35.i686
libvorbis-1.3.7-4.fc35.i686
libwayland-client-1.20.0-1.fc35.i686
libwayland-cursor-1.20.0-1.fc35.i686
libwayland-egl-1.20.0-1.fc35.i686
libwebp-1.2.2-1.fc35.i686
libX11-1.7.3.1-1.fc35.i686
libX11-xcb-1.7.3.1-1.fc35.i686
libXau-1.0.9-7.fc35.i686
libxcb-1.13.1-8.fc35.i686
libXcomposite-0.4.5-6.fc35.i686
libxcrypt-4.4.28-1.fc35.i686
libxcrypt-compat-4.4.28-1.fc35.i686
libXcursor-1.2.0-6.fc35.i686
libXdamage-1.1.5-6.fc35.i686
libXext-1.3.4-7.fc35.i686
libXfixes-6.0.0-2.fc35.i686
libXft-2.3.3-7.fc35.i686
libXi-1.7.10-7.fc35.i686
libXinerama-1.1.4-9.fc35.i686
libxkbcommon-1.3.1-1.fc35.i686
libxml2-2.9.13-1.fc35.i686
libXrandr-1.5.2-7.fc35.i686
libXrender-0.9.10-15.fc35.i686
libXScrnSaver-1.2.3-9.fc35.i686
libxshmfence-1.3-9.fc35.i686
libXtst-1.2.3-15.fc35.i686
libXxf86vm-1.1.4-17.fc35.i686
libzstd-1.5.2-1.fc35.i686
lilv-0.24.10-4.fc35.i686
llvm-libs-13.0.0-4.fc35.i686
lz4-libs-1.9.3-3.fc35.i686
mesa-dri-drivers-21.3.7-1.fc35.i686
mesa-filesystem-21.3.7-1.fc35.i686
mesa-libGL-21.3.7-1.fc35.i686
mesa-libglapi-21.3.7-1.fc35.i686
mesa-vulkan-drivers-21.3.7-1.fc35.i686
ncurses-libs-6.2-8.20210508.fc35.i686
nettle-3.7.3-2.fc35.i686
nspr-4.32.0-5.fc35.i686
nss-3.75.0-1.fc35.i686
nss-softokn-3.75.0-1.fc35.i686
nss-softokn-freebl-3.75.0-1.fc35.i686
nss-util-3.75.0-1.fc35.i686
openldap-2.4.59-3.fc35.i686
openssl-libs-1.1.1l-2.fc35.i686
openssl-pkcs11-0.4.11-4.fc35.i686
opus-1.3.1-9.fc35.i686
p11-kit-0.23.22-4.fc35.i686
pango-1.50.4-1.fc35.i686
pcre2-10.39-1.fc35.i686
pcre-8.45-1.fc35.i686
pipewire-0.3.48-1.fc35.i686
pipewire-alsa-0.3.48-1.fc35.i686
pipewire-debuginfo-0.3.48-1.fc35.i686
pipewire-debugsource-0.3.48-1.fc35.i686
pipewire-libs-0.3.48-1.fc35.i686
pixman-0.40.0-4.fc35.i686
pulseaud

Re: [Fedora-legal-list] How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?

2022-03-23 Thread Michal Schorm

On Wed, Mar 23, 2022 at 9:36 AM Vít Ondruch  wrote:
> Dne 22. 03. 22 v 19:18 Michal Schorm napsal(a):
> > On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana  wrote:
> >> I would assert that the "unlicensed
> >> contribution" scenario contemplated by the FPCA is actually going to
> >> be fairly rare apart from the special case of spec files, which the
> >> FPCA was particularly aimed at. In the typical case, a Fedora-related
> >> project makes clear what the applicable license of a repository (or of
> >> files within a repository) is/are, and under the "inbound=outbound"
> >> convention, that will be understood to be the license of the
> >> contribution.
> > I've never heard about "inbound=outbound convention".
>
> I think you can get more information about this concept in Richard's
> article:
>
> https://opensource.com/article/19/2/cla-problems

What a great article !

That answers it to me.
We don't need the contributors to sign the FPCA or any CLA.
Thanks.

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, Mar 23, 2022 at 9:36 AM Vít Ondruch  wrote:
>
>
> Dne 22. 03. 22 v 19:18 Michal Schorm napsal(a):
> > On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana  wrote:
> >> I would assert that the "unlicensed
> >> contribution" scenario contemplated by the FPCA is actually going to
> >> be fairly rare apart from the special case of spec files, which the
> >> FPCA was particularly aimed at. In the typical case, a Fedora-related
> >> project makes clear what the applicable license of a repository (or of
> >> files within a repository) is/are, and under the "inbound=outbound"
> >> convention, that will be understood to be the license of the
> >> contribution.
> > I've never heard about "inbound=outbound convention".
>
>
> I think you can get more information about this concept in Richard's
> article:
>
> https://opensource.com/article/19/2/cla-problems
>
>
> >
> > I understand your answer as that:
> > it is irrelevant whether the contributor specified the license (e.g.
> > text "I submit this under GPL-2.0 license" in the pull request
> > comment)
>
>
> If somebody states license of the contribution, then it has to be
> respected. Otherwise it is assumed that the contribution has similar
> licensing conditions as the target project.
>
>
> Vít
>
>
>
> >   or whether none was specified, or whether the FPCA was
> > accepted by the contributor; since every contributor to a code (let's
> > say a single package repository) is always legally assumed to be under
> > the license othe code of that package has, unless specified
> > differently by the contributor.
> >
> > Is my understanding correct ?
> >
> > Michal
> >
> > --
> >
> > Michal Schorm
> > Software Engineer
> > Core Services - Databases Team
> > Red Hat
> >
> > --
> >
> > On Tue, Mar 22, 2022 at 7:06 PM Richard Fontana  wrote:
> >> On Tue, Mar 22, 2022 at 12:25 PM Michal Schorm  wrote:
> >>> Hello,
> >>>
> >>> I'm trying to answer this question:
> >>> "Under which license are the contributions done to Fedora Project,
> >>> unless license is specified - and how make this clear to the
> >>> contributors (or whether we make this clear enough)".
> >>> The answer is _probably_ FPCA [1].
> >> The FPCA basically says that there's a particular default license that
> >> applies in cases where the contribution is not "covered by explicit
> >> licensing terms that are conspicuous and readily discernible to
> >> recipients." This does not spell out what "explicit", "conspicuous"
> >> and "readily discernible" actually mean, much as you haven't explained
> >> what you mean by "specified". I would assert that the "unlicensed
> >> contribution" scenario contemplated by the FPCA is actually going to
> >> be fairly rare apart from the special case of spec files, which the
> >> FPCA was particularly aimed at. In the typical case, a Fedora-related
> >> project makes clear what the applicable license of a repository (or of
> >> files within a repository) is/are, and under the "inbound=outbound"
> >> convention, that will be understood to be the license of the
> >> contribution.
> >>
> >> I'm not aware of any reason to make anything clearer that it currently
> >> is. I think at this point the FPCA is sort of a historical curiosity
> >> that lives on because of inertia (other than as an indirect statement
> >> of licensing policy around certain special things like spec files but
> >> those could be addressed in a different way).
> >>
> >>> And this HTTPS workflow leads back to my original question - since FAS
> >>> users outside of 'packager' group AFAIK don't need to sign FPCA [1],
> >>> but can contribute a code - under which license or agreement it is
> >>> contributed ? If it is FPCA - are such contributors aware ?
> >> If contributors haven't signed the FPCA, the FPCA doesn't apply to
> >> their contributions. But this is most likely unproblematic, for much
> >> the same reason that Fedora could abandon use of the FPCA altogether
> >> wit

Heads-up: python-probeinterface 0.2.8 will contain an API change

2022-03-23 Thread Ben Beasley

I will build python-probeinterface 0.2.8[1] for Rawhide in one week 
(2022-03-30), or slightly later.


This breaks the API by renaming:

- `probeinterface.probe.select_dimensions` to 
`probeinterface.probe.select_axes`

- the `plane` keyword argument of `probeinterface.probe.to_3d` to `axes`
- the `dimensions` keyword argument of `probeinterface.probe.to_3d` to 
`axes`


I will not issue updates for F36 or for stable releases. The only 
dependent package, `python-neo`, does not use the affected parts of the 
API, so it will not require any changes.


[1] https://src.fedoraproject.org/rpms/python-probeinterface/pull-request/1
___
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: Heads up: cgnslib 4.3 coming to rawhide with soname bump

2022-03-23 Thread Sandro Mani



On 22.03.22 08:47, Sandro Mani wrote:


Hi

I'll be updating to cgnslib-4.3 in rawhide in f37-build-side-52152, 
rebuilding the following dependencies:



gmsh
paraview
pcl
petsc
vtk


This is now done and the side-tag merged.

Sandro
___
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-20220323.0 compose check report

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-20220322.0):

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

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: Landing a larger-than-release change (distrusting SHA-1 signatures)

2022-03-23 Thread Alexander Sosedkin

On Wed, Mar 23, 2022 at 12:51 AM Josh Boyer  wrote:
>
> On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin  
> wrote:
> >
> > Hello, community, I need your wisdom for planning a disruptive change.
> >
> > Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> > Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > I believe we should start planning
> > for the next cryptographic defaults tightening.
> > And next time it's gonna be even more disruptive because of SHA-1 (again).
> >
> > SHA-1 is a hash function from 1995,
> > which collision resistance is no longer to be relied upon for security [1].
> > At the same time, it's not like software has successfully migrated off it,
> > not even close.
> > It's not a question of "if" the world should migrate from it,
> > sooner or later we must part ways with it.
> > (Technically, some acute energy crisis or a collapse of civilization
> >  forever raising the costs of computations thousandfold would also do,
> >  but let's agree that migrating to a more modern hash is the way =)
> >
> > We've been disabling it in TLS, but its usage is much wider than TLS.
> > The next agonizing step is to restrict its usage for signatures
> > on the cryptographic libraries level, with openssl being the scariest one.
> >
> > Good news is, RHEL-9 is gonna lead the way
> > and thus will take a lot of the hits first.
> > Fedora doesn't have to pioneer it.
> > Bad news is, Fedora has to follow suit someday anyway,
> > and this brings me to how does one land such a change.
>
> Given that RHEL 9 already switched the crypto-policy defaults, and we
> presume that future RHEL releases will not deviate from that, is this
> change already made in ELN?  I honestly can't tell because it looks
> like it is, but I don't see any conditionalization in the spec file
> that would lead me to believe the same default isn't already flipped
> in Rawhide.  That leaves me wondering what needs to be changed and
> where at this point.
>
> josh

No, it's neither in ELN nor in Rawhide yet.

> > Fedora is a large distribution with short release cycles, and
> > the only realistic way to weed out its reliance on SHA-1 signatures
> > from all of its numerous dark corners is to break them.
> > Make creation and verification fail in default configuration.
> > But it's unreasonable to just wait for, say, Fedora 37 branch-off
> > and break it in Rawhide for Fedora 38.
> > The fallout will just be too big.
> >
> > Maintainers need time to get bugs, look into them, think,
> > analyze, react and test --- and that's just if it fails correctly!
> > Unfortunately, it's not just that the error paths are as dusty as they get
> > because the program counter has never set foot on them before.
> > Some maintainers might even find that
> > picking a different hash function renders their code non-interoperable,
> > or even that protocols they implement have SHA-1 hardcoded in the spec.
> > Or that everything is ready, but real world deployments need another decade.
> > Or that on-disk formats are just hard to change and migrate.
> > Took git years to migrate from SHA-1, and some others haven't even started.
> > There are gonna be investigations, planning, exceptions, upstream changes,
> > opt-out mechanisms, arguing, compromises, waiting out, all kinds of things.
> > It's gonna be big. Too big for a single release cycle.
> >
> > ---
> >
> > But how does one land something and give the distribution
> > the extra cycles needed to react? That's not really clear to me.
> >
> > An obvious thing is to announce it in one cycle and land in another one.
> > The downsides are well-documented
> > in "The Hitchhiker's Guide to the Galaxy":
> > announcements are one weak measure, and then it's too late.
> >
> > A second scheme I can come up with is a "jump scare".
> > Break the functionality in Fedora 37 Rawhide,
> > make most of the affected people realize the depth of the problem,
> > then unbreak it. Break again for Fedora 38 and never fix.
> >
> > This could also be extended into "let one stable release slide'.
> > Break in 37 Rawhide, unbreak on branched off 37,
> > but never in Rawhide.
> >
> > But these are all rather... crude?
> > Sure there should be better ways,
> > preferably something explored before.
> > I'm all for pulling this tooth out smoothly,
> > but I need hints on how to do it.
> > I hope that together we can devise a better plan than these.
> >
> > So, how does one land a change that's bigger than a release cycle?
> >
> > [1] https://eprint.iacr.org/2020/014
> > ___
> > 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

Re: [Fedora-legal-list] How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?


On 23. 03. 22 9:35, Vít Ondruch wrote:


I understand your answer as that:
it is irrelevant whether the contributor specified the license (e.g.
text "I submit this under GPL-2.0 license" in the pull request
comment)



If somebody states license of the contribution, then it has to be respected. 
Otherwise it is assumed that the contribution has similar licensing conditions 
as the target project.


If that's the case, can we please stop enforcing the signed-off-by thing in 
Fedora projects (such as various Fedora projects on Pagure or Bodhi on GitHub)?


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

Fedora rawhide compose report: 20220323.n.0 changes

2022-03-23 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20220322.n.0
NEW: Fedora-Rawhide-20220323.n.0

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

Size of added packages:  475.68 KiB
Size of dropped packages:1.04 MiB
Size of upgraded packages:   3.52 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20220323.n.0.s390x.tar.xz
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20220323.n.0.iso
Image: Python_Classroom raw-xz aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20220323.n.0.aarch64.raw.xz

= DROPPED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20220322.n.0.iso

= ADDED PACKAGES =
Package: python-simple-salesforce-1.11.5-1.fc37
Summary: Simple Salesforce is a basic Salesforce.com REST API client built for 
Python
RPMs:python3-simple-salesforce
Size:60.63 KiB

Package: rubygem-importmap-rails-1.0.3-1.fc37
Summary: Manage modern JavaScript in Rails without transpiling or bundling
RPMs:rubygem-importmap-rails rubygem-importmap-rails-doc
Size:337.19 KiB

Package: tty-copy-0.2.2-1.fc37
Summary: Copy content to system clipboard via TTY and terminal using ANSI OSC52 
sequence
RPMs:tty-copy
Size:77.86 KiB


= DROPPED PACKAGES =
Package: javahelp2-2.0.05-32.fc36
Summary: JavaHelp is a full-featured, platform-independent, extensible help 
system
RPMs:javahelp2 javahelp2-javadoc
Size:1.04 MiB


= UPGRADED PACKAGES =
Package:  ansible-collection-community-general-4.6.1-1.fc37
Old package:  ansible-collection-community-general-4.5.0-1.fc37
Summary:  Modules and plugins supported by Ansible community
RPMs: ansible-collection-community-general
Size: 1.40 MiB
Size change:  5.20 KiB
Changelog:
  * Tue Mar 22 2022 Maxwell G  - 4.6.1-1
  - Update to 4.6.1. Fixes rhbz#2064712.


Package:  awscli-1.22.79-1.fc37
Old package:  awscli-1.22.78-1.fc37
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.17 MiB
Size change:  90 B
Changelog:
  * Tue Mar 22 2022 Gwyn Ciesla  - 1.22.79-1
  - 1.22.79


Package:  blackbox-0.77-1.fc37
Old package:  blackbox-0.76-7.fc36
Summary:  Very small and fast Window Manager
RPMs: blackbox blackbox-devel
Size: 2.18 MiB
Size change:  -2.98 KiB
Changelog:
  * Wed Mar 23 2022 Filipe Rosset  - 0.77-1
  - Update to 0.77 fixes rhbz#1959905


Package:  calibre-5.39.1-1.fc37
Old package:  calibre-5.37.0-2.fc37
Summary:  E-book converter and library manager
RPMs: calibre
Size: 48.14 MiB
Size change:  -68.52 KiB
Changelog:
  * Tue Mar 22 2022 Kevin Fenzi  5.39.1-1
  - Update to 5.39.1. Fixes rhbz#2060703


Package:  ceph-2:17.1.0-0.5.56.g60fdd357.fc37
Old package:  ceph-2:17.1.0-0.4.31.g1ccf6db7.fc37
Summary:  User space components of the Ceph file system
RPMs: ceph ceph-base ceph-common ceph-fuse ceph-grafana-dashboards 
ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm 
ceph-mgr-dashboard ceph-mgr-diskprediction-local ceph-mgr-k8sevents 
ceph-mgr-modules-core ceph-mgr-rook ceph-mon ceph-osd ceph-prometheus-alerts 
ceph-radosgw ceph-resource-agents ceph-selinux ceph-test ceph-volume cephadm 
cephfs-java cephfs-mirror cephfs-shell cephfs-top libcephfs-devel libcephfs2 
libcephfs_jni-devel libcephfs_jni1 libcephsqlite libcephsqlite-devel 
librados-devel librados2 libradospp-devel libradosstriper-devel 
libradosstriper1 librbd-devel librbd1 librgw-devel librgw2 
python3-ceph-argparse python3-ceph-common python3-cephfs python3-rados 
python3-rbd python3-rgw rados-objclass-devel rbd-fuse rbd-mirror rbd-nbd
Size: 335.40 MiB
Size change:  -18.18 KiB
Changelog:
  * Mon Mar 21 2022 Kaleb S. KEITHLEY  - 
2:17.1.0-0.5.56-g60fdd357
  - 17.1.0 snapshot 56


Package:  cfn-lint-0.58.4-1.fc37
Old package:  cfn-lint-0.58.3-1.fc37
Summary:  CloudFormation Linter
RPMs: cfn-lint
Size: 2.04 MiB
Size change:  33.41 KiB
Changelog:
  * Tue Mar 22 2022 Benjamin A. Beasley  0.58.4-1
  - Update to 0.58.4 (close RHBZ#2066498)


Package:  cp2k-9.1-2.fc37
Old package:  cp2k-9.1-1.fc37
Summary:  Ab Initio Molecular Dynamics
RPMs: cp2k cp2k-common cp2k-mpich cp2k-openmpi
Size: 217.98 MiB
Size change:  -6.43 KiB
Changelog:
  * Tue Mar 22 2022 Dominik Mierzejewski  - 9.1-2
  - fix three failing tests due to wrong LD_LIBRARY_PATH setting


Package:  cross-binutils-2.38-2.fc37
Old package:  cross-binutils-2.38-1.fc37
Summary:  A GNU collection of cross-compilation binary utilities
RPMs: binutils-aarch64-linux-gnu binutils-alpha-linux-gnu

Re: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

On 22. 03. 22 19:48, Adam Williamson wrote:

I found quite a big mess today, caused by an attempt to bump perl to
5.34.1 in Fedora 36:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-cea638ebd4

Because some packages depend on the exact perl interpreter version, the
maintainer made a buildroot override for perl:

https://bodhi.fedoraproject.org/overrides/perl-5.34.1-486.fc36

and rebuilt them. Okay.

The problem with this is, we have lots of perl modules. People build
them all the time. And buildroot overrides apply to *everything*.

So, while the buildroot override has been valid, multiple *other* perl
modules have been unwittingly built against it:

perl-Scalar-List-Utils:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1936732
perl-Parallel-Pipes:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1937527
perl-PPIx-Regexp:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1937522
perl-Crypt-SSLeay:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1937521
perl-Crypt-OpenSSL-PKCS10:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1937471

...and those are just the ones I found so far. Because they were built
against 5.34.1, all of those builds require
"perl(:MODULE_COMPAT_5.34.1)" , which means they require perl-5.34.1
from updates-testing. They cannot be installed with perl-5.34.0 from
stable. But the maintainers likely had no idea about this - buildroot
overrides are not at all discoverable, there is zero indication your
package is building against one when you build it - and have created
separate updates for those packages:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb1170abf2
https://bodhi.fedoraproject.org/updates/FEDORA-2022-d83d0ba901
https://bodhi.fedoraproject.org/updates/FEDORA-2022-fac98e635f
https://bodhi.fedoraproject.org/updates/FEDORA-2022-c2203f1964
https://bodhi.fedoraproject.org/updates/FEDORA-2022-0990e3309e

Users testing those updates will likely not notice the problem, because
they'll have *all* of updates-testing enabled when they update, and
perl-5.34.1 will be pulled in. But if any of those updates is pushed
stable before the perl update is pushed stable, it will fail to install
for anyone who does not have updates-testing enabled.

This is quite a mess. I'm going to try and clean it up, but it'll be a
bit ugly (there are a couple of ways I can do it, but both will involve
doing bumps-and-rebuilds of the affected packages with no changes).

I've been worried about this sort of thing happening for a while due to
the undesirable properties of buildroot overrides. This is the biggest
real-world case I've seen, but it could certainly happen again. It
might even have happened without anyone noticing exactly what was going
on (just mysterious dependency issues that magically went away after a
bit).

So: now we have convenient self-service side tags, *please use them*.
Especially for something as major as a bump of perl that changes
dependencies of packages built against it like this. Side tags avoid
this mess entirely. Using the mechanism to produce an update from a
side tag also makes it easier to make sure all the right packages are
in the update and they don't get incorrectly submitted as separate
updates.

Thanks folks!

Thanks for this, Adam.

I will add one more reason:

When the automatic "fails to install" reports run, they use the Koji buidlroot.
Every now and then, a bugzilla is reported like this one:

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

It is not a false positive, the dependency problem exists, but it only exists
because there is an override:

https://bodhi.fedoraproject.org/overrides/R-4.1.3-1.fc36

Please, use side tags, not overrides, when updating inter-dependent packages,
it avoid (even temporary) breakage:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

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

Fedora-Cloud-35-20220323.0 compose check report