Koji down?
by Ron Olson
I submitted some builds yesterday and didn’t get any emails, and at least as of 6:18 CDT every link I click on the main webpage replies with “server is offline”.
2 years, 2 months
Dropping wine from ARM
by Michael Cronenworth
Hi,
Fedora currently ships Wine 7.3 released February 25th, 2022.
Wine 7.4, released March 11th, started to require a 'llvm-mingw' compiler for ARM64
builds. Fedora ships the 'mingw-w64' gcc-based MinGW environment and does not ship
the 'llvm' MinGW environment. Unlike the WineMono package, which bundles a
'llvm-mingw' compiler (that is removed and mingw-w64 is used), the Wine package does
not bundle one and does not allow for an alternative compiler.
I will need to drop ARM from Wine in order to continue shipping new updates. I do
not have the bandwidth to package the llvm-mingw compiler toolchain, nor do I have
the time right now to discuss this with upstream.
Thanks,
Michael
2 years, 2 months
Looking for provenpackager to update rapid-photo-downloader package
by Damon Lynch
Greetings Fedora community, I am the developer of Rapid Photo Downloader. The package for it in Fedora is about two years old, and crashes during start-up under Python 3.10.
As the subject says, I'm looking for a provenpackager to update the package. I'm posting this message here at the suggestion of a fellow PyQt developer who unlike myself is a Fedora expert.
I filed a bug report last year but the maintainer has been unable to work on it: https://bugzilla.redhat.com/show_bug.cgi?id=2031866
Meanwhile, two months ago Neal Gompa made this pull request to update it: https://src.fedoraproject.org/rpms/rapid-photo-downloader/pull-request/3
The current release is 0.9.33. Compared to the Fedora version, it requires a new package in Fedora: https://github.com/damonlynch/showinfilemanager
Unfortunately I'm unable to volunteer my time because I managed to injure my hands while working on the code earlier this year. Serious typing injuries are not fun. :-(
(I'm dictating this using a voice recognition program under Windows.)
Fun fact: Fedora was the first distro to package Rapid Photo Downloader.
2 years, 2 months
F36 - Errors/Warnings with `dnf update`
by Nathanael D. Noblet
Hello,
Just wondering if this is a bug and what to report against. I
upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update`
and saw some odd output. Not sure if its a bug with dnf or selinux or
the packages being installed. Let me know if its a known issue or if I
need to file a bug and where.
Running transaction
Preparing :
1/1
Upgrading : crun-1.4.4-1.fc36.x86_64
1/16
error: lsetfilecon: (/usr/bin/crun;62451078,
system_u:object_r:container_runtime_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed
Error unpacking rpm package crun-1.4.4-1.fc36.x86_64
Upgrading : containers-common-4:1-53.fc36.noarch
2/16
error: unpacking of archive failed on file /usr/bin/crun;62451078:
cpio: (error 0x2)
error: crun-1.4.4-1.fc36.x86_64: install failed
error: lsetfilecon: (/var/lib/containers/sigstore,
system_u:object_r:container_var_lib_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed
Error unpacking rpm package containers-common-4:1-53.fc36.noarch
Upgrading : conmon-2:2.1.0-2.fc36.x86_64
3/16
error: unpacking of archive failed on file
/var/lib/containers/sigstore: cpio: (error 0x2)
error: containers-common-4:1-53.fc36.noarch: install failed
error: lsetfilecon: (/usr/bin/conmon;62451078,
system_u:object_r:conmon_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed
Error unpacking rpm package conmon-2:2.1.0-2.fc36.x86_64
Upgrading : podman-3:4.0.2-1.fc36.x86_64
4/16
error: unpacking of archive failed on file /usr/bin/conmon;62451078:
cpio: (error 0x2)
error: conmon-2:2.1.0-2.fc36.x86_64: install failed
error: lsetfilecon: (/usr/bin/podman;62451078,
system_u:object_r:container_runtime_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed
Error unpacking rpm package podman-3:4.0.2-1.fc36.x86_64
Upgrading : runc-2:1.1.1-1.fc36.x86_64
5/16
error: unpacking of archive failed on file /usr/bin/podman;62451078:
cpio: (error 0x2)
error: podman-3:4.0.2-1.fc36.x86_64: install failed
error: lsetfilecon: (/usr/bin/runc;62451078,
system_u:object_r:container_runtime_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed
Error unpacking rpm package runc-2:1.1.1-1.fc36.x86_64
Upgrading : swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64
6/16
error: unpacking of archive failed on file /usr/bin/runc;62451078:
cpio: (error 0x2)
error: runc-2:1.1.1-1.fc36.x86_64: install failed
error: lsetfilecon: (/usr/bin/swtpm;62451078,
system_u:object_r:swtpm_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed
Error unpacking rpm package swtpm-0.7.2-
1.20220307git21c90c1.fc36.x86_64
Upgrading : snapd-2.54.4-1.fc36.x86_64
7/16
error: unpacking of archive failed on file /usr/bin/swtpm;62451078:
cpio: (error 0x2)
error: swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64: install failed
error: lsetfilecon: (/etc/sysconfig/snapd;62451078,
system_u:object_r:snappy_config_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed
Error unpacking rpm package snapd-2.54.4-1.fc36.x86_64
Running scriptlet: flatpak-1.12.7-1.fc36.x86_64
8/16
error: unpacking of archive failed on file
/etc/sysconfig/snapd;62451078: cpio: (error 0x2)
error: snapd-2.54.4-1.fc36.x86_64: install failed
Upgrading : flatpak-1.12.7-1.fc36.x86_64
8/16
error: lsetfilecon: (/usr/libexec/flatpak-system-helper;62451078,
system_u:object_r:flatpak_helper_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed
Error unpacking rpm package flatpak-1.12.7-1.fc36.x86_64
2 years, 2 months
F37 Change: Support FIDO Device Onboarding (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FIDODeviceOnboarding
== Summary ==
Package and enable the
[https://fidoalliance.org/fido-alliance-creates-new-onboarding-standard-to...
FIDO Device Onboarding] software stack for Zero Touch Onboarding on
Fedora IoT.
== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: [mailto:pbrobinson@fedoraproject.org| pbrobinson(a)fedoraproject.org]
* Name: [[User:runcom| Antonio Murdaca]]
* Email: [mailto:amurdaca@redhat.com| amurdaca(a)redhat.com]
== Detailed Description ==
The ability for an IoT or Edge device to be plugged in and
automatically onboard itself with zero user interaction is critical to
be able to scale IoT/Edge to millions of devices. To do this in a
secure way with open standards across the industry is even more
critical. The FIDO IoT working group has worked with leaders in the
silicon industry such as Intel and Arm to produce the FIDO Device
onboarding spec which allows a device credential, a root and chain of
trust to ensure the secure onboarding of a device without the need of
stored credentials.
== Benefit to Fedora ==
The benefit to Fedora is to allow the IoT Edition to demonstrate the
use of leading edge open industry protocols for onboarding IoT and
Edge devices.
== Scope ==
* Proposal owners:
** Package the rust implementation of the FIDO device onboarding stack
including client, rendezvous service, owner onboarding service and
prototype manufacturing service.
** Enable the client service by default for IoT Edition
** Add the client service to the IoT Edition deliverables
* Other developers:
** No impact
* Release engineering: [https://pagure.io/releng/issue/10720 #10720]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There is no upgrade impact. FIDO FDO is a single use onboarding
protocol and will not impact existing IoT user systems.
== How To Test ==
* Test with FDO all-in-one services. Documentation will be available
for testing.
== User Experience ==
No impact to non IoT Edition users.
The user experience for the IoT Edition is still evolving and this
will be updated as things fall into place later in Spring and early
Summer 2022.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Not shipping FDO as a package in Fedora or
including it in the IoT Edition
* Contingency deadline: GA
* Blocks release? No.
* Blocks product? No.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora IoT Edition supports the FIDO Device Onboarding 1.1
specification for zero touch onboarding of IoT and Edge devices.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
[IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a
driver are installed
by 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 <queue_name> -v ipp://localhost:60000/ipp/print -m
everywhere -E
ipp-usb advertises the printer only to localhost at port 60000 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/#_golan...
[2]
https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_...
[3]
https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/#_tempor...
[4] https://github.com/alexpevzner/sane-airscan#compatibility
[5] https://bodhi.fedoraproject.org/updates/FEDORA-2022-037458e247
[6] https://bodhi.fedoraproject.org/updates/FEDORA-2022-140993eb13
[7] https://bodhi.fedoraproject.org/updates/FEDORA-2022-f151accd9b
[8] https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks
[9] https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_cups
--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
2 years, 2 months
Retiring python-typer-cli due to lack of upstream support
by Ben Beasley
This is just a heads-up that I am retiring python-typer-cli in
F37/Rawhide due to an ongoing lack of upstream support. It is a leaf
package.
Important functionality has been patched out downstream[1] for about six
months due to incompatibility with click version 8.x and typer version
0.4.0 (the latter by the same author as typer-cli). The required fix is
nontrivial, and there is no sign of progress[2]. This has been the case
through the entire F35 lifecycle, and I wouldn’t expect the package to
be adequately maintained even if upstream does comes through with a
patch at some point.
Still, I will maintain the packages in F34–F36 until those releases’
end-of-life dates, and I’ll also keep maintaining the related
python-typer package, which has seen a much more adequate amount of
upstream attention in the past year.
– Ben
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1999921
[2] https://github.com/tiangolo/typer-cli/issues/50
2 years, 2 months
Poco FTBFS fix and soname bump
by Robin Lee
Poco upstream finally committed OpenSSL 3 in the next release branch.
And Carl George helped to finish rawhide/f36 builds with a snapshot
source.
There is also a soname bump. Poco bumps soname at every release.
After all, nothing else in Fedora depends on Poco.
-robin
2 years, 2 months
