Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

2022-12-13 Thread Michael Catanzaro via devel
> Anyway, the effort that
> went into that change proposal has established new expectations for any 
> change that will
> impact system performance: the new flags should be benchmarked in an 
> environment where all
> Fedora packages have been rebuilt with the new flags, so we can critique the 
> change based
> on benchmarks that are not representative of real-world usage and reject it 
> if they show a
> 2% performance hit, regardless of value to Fedora. If you don't like the idea 
> of
> rebuilding all packages with the new flags, then maybe it was a mistake to 
> require
> developers to do just that if they want to profile applications successfully.

So I was quite upset when I wrote the above mail, seeing a new change proposal 
that admits it adds register pressure a few days after the frame pointer 
proposal was rejected for adding register pressure. Probably I should not send 
mails when angry. I don't actually support requiring the proposal authors to do 
the above work. `_FORTIFY_SOURCE=3` seems certain to make Fedora users safer. 
Regardless of what happened to the frame pointer proposal, it wouldn't make 
sense to block it from benefiting Fedora users. If we were politicians, then it 
would totally make sense to block Other Team's proposal unless Our Team's 
proposal gets accepted. (I support Team Frame Pointer. ;) But Fedora change 
proposals should not operate that way. (We all support Team Fedora here, after 
all.) This should go through.

One more note regarding frame pointers. The `_FORTIFY_SOURCE=3` change proposal 
says "Per-application performance benchmarks may be useful in understanding the 
impact for those specific use cases." But this is not useful at all without an 
actionable way to figure out where performance problems are occurring, which 
requires functional profiling tools, which require frame pointers. Thank you 
_very much_ Neal, Fabio, and Zbigniew for your efforts to revisit that decision.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

2022-12-13 Thread Siddhesh Poyarekar
On Tue, Dec 6, 2022 at 10:41 AM Siddhesh Poyarekar  wrote:
>
> On Tue, Dec 6, 2022 at 10:26 AM Gary Buhrmaster
>  wrote:
> >
> > On Tue, Dec 6, 2022 at 3:16 PM Siddhesh Poyarekar  
> > wrote:
> >
> > > My full comment in that blog post is:
> > >
> > > "We need a proper study of performance and code size to understand the
> > > magnitude of the impact created by _FORTIFY_SOURCE=3 additional
> > > runtime code generation. However the performance and code size
> > > overhead may well be worth it due to the magnitude of improvement in
> > > security coverage."
> >
> > The key word is *MAY*.  That is not considered
> > to be a conclusion supported by the evidence
> > presented (at least in any scientific paper I
> > have reviewed).
>
> I have added a performance note[1] in the proposal.

SPEC2000 and SPEC2017 results with _FORTIFY_SOURCE=2 vs
_FORTIFY_SOURCE=3 show practically no difference in performance. I
have updated the wiki to note this and the fact that this should
alleviate any concerns of a general slowdown.  However I do request
package maintainers to report any slowdown they experience due to
building with _FORTIFY_SOURCE=3 so that we get a better understanding.
Always happy to help keep performance up to par even as we improve
security mitigations.

Thanks,
Sid
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


xen soname bump with 4.17.0 release

2022-12-13 Thread Michael Young

I have built an update of xen to the 4.17.0 release on rawhide in the
f38-build-side-61077 side tag. I believe that the qemu and libvirt
packages will need to be rebuilt due to the version change on some of the 
xen libraries.


Michael Young
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Summary/Minutes for today's FESCo meeting (2022-12-13)

2022-12-13 Thread David Cantrell
On Tue, Dec 13, 2022 at 12:31:59PM -0500, David Cantrell wrote:
> Action Items
> 
> * mhroncok will chair next meeting

The next FESCo meeting will be January 3, 2023.

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Summary/Minutes for today's FESCo meeting (2022-12-13)

2022-12-13 Thread David Cantrell
===
#fedora-meeting: FESCO (2022-12-13)
===


Meeting started by dcantrell at 16:59:17 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting/2022-12-13/fesco.2022-12-13-16.59.log.html


--
The agenda email for today's meeting incorrectly listed closed FESCo tickets
in the Followups section.  These should have been in the Discussed and Voted
in the Ticket section and should have included the final vote.  Here is the
corrected information:

= Discussed and Voted in the Ticket =

#2909 Change: LLVM 16
https://pagure.io/fesco/issue/2909
APPROVED (+5,0,-0)

#2908 Change: Add Fedora Auto Firstboot Services to desktop variants
https://pagure.io/fesco/issue/2908
APPROVED (+5,0,-0)

#2906 Change: Remove Guile Support from GDB
https://pagure.io/fesco/issue/2906
APPROVED (+8, 0, 0)

#2901 Change: Build Fedora Silverblue & Kinoite using rpm-ostree unified core 
mode
https://pagure.io/fesco/issue/2901
APPROVED (+3,0,-0)

#2883 Change: Ostree Native Container (Phase 2, stable)
https://pagure.io/fesco/issue/2883
APPROVED (+4,0,-0)

--



Meeting summary
---
* init process  (dcantrell, 16:59:35)

* #2911 Review removal of ncurses-compat-libs  (dcantrell, 17:01:53)
  * Marked as stalled until we can get feedback from the ncurses
package maintainer.

* Next week's chair  (dcantrell, 17:06:29)
  * ACTION: mhroncok will chair next meeting  (dcantrell, 17:08:16)

* Open Floor  (dcantrell, 17:08:31)

Meeting ended at 17:19:24 UTC.




Action Items

* mhroncok will chair next meeting




Action Items, by person
---
* mhroncok
  * mhroncok will chair next meeting




People Present (lines said)
---
* dcantrell (49)
* mhroncok (24)
* zodbot (16)
* Eighth_Doctor (8)
* decathorpe (7)
* zbyszek (7)
* mhayden (6)
* music[m] (4)
* nirik (0)
* sgallagh (0)
* music (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* Son_Goku (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions


-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


F38 proposal: Use mdadm for BIOS RAID Support in Anaconda (Self-Contained Change proposal)

2022-12-13 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/UseMdadmForBIOSRAIDInAnaconda

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Use mdadm instead of dmraid to support BIOS RAID (Firmware RAID or
Fake RAID) during the Fedora installation process.

== Owner ==
* Name: [[User:vtrefny| Vojtech Trefny]] (Blivet)
* Email: vtrefny AT redhat.com
* Name: [[User:vponcova|Vendula Poncova]] (Anaconda)
* Email: vponcova AT redhat.com


== Detailed Description ==
[[Anaconda]] (or to be more precise [[Blivet]], the storage library
Anaconda uses) is currently using dmraid to support the BIOS RAID
devices (sometimes also called Firmware or BIOS RAID) during
installation. We plan to replace dmraid by mdadm, which we are
currently using for software RAID management. The main reason is that
dmraid is no longer actively maintained. mdadm supports the two major
BIOS RAID technologies: Common RAID Disk Data Format (DDF)
[https://www.snia.org/tech_activities/standards/curr_standards/ddf
standard by SNIA] and
[https://www.intel.com/content/www/us/en/support/products/122484/memory-and-storage/datacenter-storage-solutions/intel-virtual-raid-on-cpu-intel-vroc.html
Intel Matrix Storage Manager] format. mdadm is missing support for
some older BIOS RAID formats that existed before DDF and are still
supported by dmraid so by implementing this change, we will remove
support for some BIOS RAID formats from the installer.

== Feedback ==

We tried to 
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/A6G5HTBXXIDQUMYBCILU264ZLEWF75ND/
get feedback from the community] to find out how many users use BIOS
RAID and would be affected by this change (especially by removing
support for the older formats). The only response was from the Fedora
QA which has an Intel Matrix machine for testing which should be
supported by mdadm.

== Benefit to Fedora ==

Replacing a tool/library that is no longer being actively developed
and maintained. Because we are replacing it with a tool that is
currently used for software RAID management in the installer, this
also means removing one dependency from the installer environment and
remove the dmraid startup service from the installed system.

== Scope ==
* Proposal owners: Changes to Blivet (replacing dmraid with mdadm for
the specified BIOS RAID formats) and Anaconda (removing the
`inst.nodmraid` flag)

* Other developers:

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


== Upgrade/compatibility impact ==

This change will affect only new installations (the change only
changes behaviour of the installer).


== How To Test ==
A hardware with BIOS RAID support (DDF or IMSM) is required. (Creating
a "fake" BIOS RAID with mdadm might be possible for testing, we'll add
steps for testing without the hardware later (if possible).)

Follow the test case for installing on BIOS/Firmware RAID:
[[QA:Testcase_install_to_firmware_RAID]].


== User Experience ==
Users with supported BIOS RAIDs shouldn't notice a change, the
installation should work the same for them. Users with older
unsupported BIOS RAID formats won't be able to install Fedora on these
arrays. For these users we'll recommend switching to software RAID.

== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: Revert the changes and keep using dmraid for
all BIOS RAID formats.
* Contingency deadline: Beta  
* Blocks release? No


== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Fedora/CentOS planned outage 2022-12-08 19:00 UTC

2022-12-13 Thread Stephen Smoogen
On Wed, 7 Dec 2022 at 11:37, Stephen Smoogen  wrote:

>
> Due to some issues, this "lanned" outage has to be delayed to 2022-12-13
> at the same time.
>
>
Due to additional timing issues, the planned outage has been moved to
2023-01-10 at the same time. Updates and more information will be added to
https://pagure.io/fedora-infrastructure/issue/11031


>
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Updating python-ezdxf to 1.0.0 in Rawhide with minor breaking changes

2022-12-13 Thread Ben Beasley
In one week (2022-12-20), or slightly later, I will update python-ezdxf 
to 1.0.0 in Rawhide.[1]


This release contains some minor breaking changes[2][3]; the only 
dependent package is python-trimesh[4], and I have verified it is 
already compatible with the new release.


[1] https://src.fedoraproject.org/rpms/python-ezdxf/pull-request/2

[2] 
https://github.com/mozman/ezdxf/blob/v1.0.0/NEWS.md#version-100---2022-12-09


[3] https://ezdxf.mozman.at/release-v1-0.html

[4] https://src.fedoraproject.org/rpms/python-trimesh
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Fedora 35 is End of Life

2022-12-13 Thread Tomas Hrcka
Hello all,

As of the 13th of December 2022, Fedora 35
has reached its end of life for updates and support.
No further updates, including security updates, will be
available for Fedora 35 after the said date. All the updates of Fedora
35 being pushed to stable will be stopped as well.

Fedora 36 will continue to receive updates until approximately one
month after the release of Fedora 38. The maintenance schedule of
Fedora releases is documented on the Fedora Project wiki [0]. The
Fedora Project wiki also contains instructions [1] on how to upgrade
from a previous release of Fedora to a version receiving updates.

Regards,
Tomas Hrcka
Fedora Release Engineering

[0]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Strange maven build problem in jackson packages

2022-12-13 Thread Chris Kelley
Hello all!

I recently took over maintaining the Jackson serialisation packages in Fedora 
and I am rebasing them to the latest upstream version in a side-tag: 
https://koji.fedoraproject.org/koji/builds?userID=ckelley&tagID=60533. I am 
experiencing curious difficulties I am hoping someone may be able to shed light 
on!

Before attempting this update in Rawhide, I performed the update in copr: 
https://copr.fedorainfracloud.org/coprs/ckelley/pki/packages/
This, after a bit of trial-and-error, was successful - and these packages are 
now being used successfully in the upstream CI for various packages. All good.

Then, I attempted the same in Rawhide. The first 3 packages in the side-tag 
(FYI first time side-tagging) build fine, but jackson-annotations does not: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=95305556
The failure is strange as the dep that provides the code to understand bundle 
packaging is present (and it works in copr).

After a bit of frustration I stopped to focus on performing the same update in 
CentOS 9 Stream, from the same sources. This update too was successful 
(eventually, first side-tag there too). The spec files are essentially 
identical between c9s and Rawhide, so I don't see an explanation there.

Curiously, I submitted a later update to jackson-annotations in c9s and it now 
fails with the exact same packaging problem as occurs in Rawhide. That update 
contained only a RH internal test file, the sources and spec were untouched.

My theory is that there is a dependency that was updated in Rawhide, which is 
problematic for my build, and that dep was recently updated in c9s and is now 
causing the same problem for me there. Has anyone seen anything like this 
before? How did you begin to investigate it? Or am I just being a side-tag noob?

Any help at all appreciated, thanks!

Chris
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Fedora rawhide compose report: 20221213.n.0 changes

2022-12-13 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20221212.n.0
NEW: Fedora-Rawhide-20221213.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  12
Dropped packages:1
Upgraded packages:   115
Downgraded packages: 0

Size of added packages:  3.02 MiB
Size of dropped packages:251.00 KiB
Size of upgraded packages:   1.92 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20221213.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20221212.n.0.iso

= ADDED PACKAGES =
Package: oneapi-level-zero-1.8.8-1.fc38
Summary: OneAPI Level Zero Specification Headers and Loader
RPMs:oneapi-level-zero oneapi-level-zero-devel
Size:249.62 KiB

Package: python-langdetect-1.0.9-2.fc38
Summary: Language detection library ported from Google's language-detection
RPMs:python3-langdetect
Size:898.06 KiB

Package: python-oslo-service-3.0.0-6.fc38
Summary: Oslo service library
RPMs:python-oslo-service-doc python3-oslo-service python3-oslo-service-tests
Size:1.16 MiB

Package: python-phply-1.2.5-3.fc38
Summary: PHP parser written in Python using PLY
RPMs:python3-phply
Size:142.02 KiB

Package: python-pypresence-4.2.1-1.fc38
Summary: A Discord Rich Presence Client in Python
RPMs:python3-pypresence
Size:40.78 KiB

Package: rust-dlv-list0.2-0.2.3-1.fc38
Summary: Semi-doubly linked list implemented using a vector
RPMs:rust-dlv-list0.2+default-devel rust-dlv-list0.2-devel
Size:26.15 KiB

Package: rust-idna0.2-0.2.3-1.fc38
Summary: IDNA (Internationalizing Domain Names in Applications) and Punycode
RPMs:rust-idna0.2+default-devel rust-idna0.2-devel
Size:230.59 KiB

Package: rust-libudev0.2-0.2.0-1.fc38
Summary: Rust wrapper for libudev
RPMs:rust-libudev0.2+default-devel rust-libudev0.2-devel
Size:24.40 KiB

Package: rust-memoffset0.6-0.6.5-1.fc38
Summary: Offset_of functionality for Rust structs
RPMs:rust-memoffset0.6+default-devel rust-memoffset0.6+unstable_const-devel 
rust-memoffset0.6-devel
Size:29.49 KiB

Package: rust-ordered-multimap0.3-0.3.1-1.fc38
Summary: Insertion ordered multimap
RPMs:rust-ordered-multimap0.3+default-devel 
rust-ordered-multimap0.3+serde-devel rust-ordered-multimap0.3-devel
Size:40.23 KiB

Package: rust-rust-ini0.17-0.17.0-1.fc38
Summary: Ini configuration file parsing library in Rust
RPMs:rust-rust-ini0.17+case-insensitive-devel 
rust-rust-ini0.17+default-devel rust-rust-ini0.17+inline-comment-devel 
rust-rust-ini0.17+unicase-devel rust-rust-ini0.17-devel
Size:49.85 KiB

Package: safeint-3.0.27-2.fc38
Summary: Class library for C++ that manages integer overflows
RPMs:safeint-devel
Size:176.93 KiB


= DROPPED PACKAGES =
Package: qextserialport-1.2-0.24.beta2.fc37
Summary: Qt interface class for old fashioned serial ports
RPMs:qextserialport qextserialport-devel
Size:251.00 KiB


= UPGRADED PACKAGES =
Package:  Ri-li-2.0.1-35.fc38
Old package:  Ri-li-2.0.1-34.fc37
Summary:  Arcade game where you drive a toy wood engine
RPMs: Ri-li
Size: 57.40 MiB
Size change:  -2.24 KiB
Changelog:
  * Mon Dec 12 2022 Florian Weimer  - 2.0.1-35
  - Port configure script to C99


Package:  awscli-1.27.28-1.fc38
Old package:  awscli-1.27.27-1.fc38
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 3.25 MiB
Size change:  8.79 KiB
Changelog:
  * Mon Dec 12 2022 Gwyn Ciesla  - 1.27.28-1
  - 1.27.28


Package:  axmail-2.9-7.fc38
Old package:  axmail-2.9-6.fc37
Summary:  UROnode addon - an SMTP mailbox
RPMs: axmail
Size: 247.51 KiB
Size change:  -382 B
Changelog:
  * Mon Dec 12 2022 Florian Weimer  - 2.9-7
  - Port to C99


Package:  barcode-0.98-44.fc38
Old package:  barcode-0.98-43.fc37
Summary:  Generates barcodes from text strings
RPMs: barcode barcode-devel
Size: 584.43 KiB
Size change:  2.35 KiB
Changelog:
  * Mon Dec 12 2022 Florian Weimer  - 0.98-44
  - Port to C99


Package:  bitcoin-core-24.0.1-1.fc38
Old package:  bitcoin-core-24.0-1.fc38
Summary:  Peer to Peer Cryptographic Currency
RPMs: bitcoin-core-desktop bitcoin-core-devel bitcoin-core-libs 
bitcoin-core-server bitcoin-core-utils
Size: 62.94 MiB
Size change:  2.59 KiB
Changelog:
  * Mon Dec 12 2022 Simone Caronni  - 24.0.1-1
  - Update to 24.0.1


Package:  callaudiod-0.1.6-1.fc38
Old package:  callaudiod-0.1.5-1.fc38
Summary:  Daemon for dealing with audio routing during phone calls
RPMs: callaudiod callaudiod-devel
Size: 355.14 KiB
Size change:  2.21 KiB
Changelog:
  * Mon Dec 12 2022 Torrey Sorensen  - 0.1.6-1
  - Update to 0.1.6


Package:  clearsilver-0.10.5-70.fc38
Old package:  clears