date:20221206

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2022-848ebdeccf has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-848ebdeccf


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150992
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2150992] perl-generators 1.14 started to create bogus dependencies for relative imports, e.g. perl(.::t/lifecycles/utils.pl)

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-generators-1.15-1.fc38




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150992
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 7 updates-testing report

2022-12-06 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-63588ab702   
woff-0.20091126-11.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-058d69433a   
snapd-2.57.6-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-735d1baeca   
brotli-1.0.9-10.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-10049c7b14   
libbsd-0.11.7-2.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

dkms-3.0.9-2.el7
gsmartcontrol-1.1.4-3.el7
netdata-1.37.1-1.el7
purple-googlechat-0-1.20221106gitb6b824a.el7

Details about builds:



 dkms-3.0.9-2.el7 (FEDORA-EPEL-2022-18e9a882ea)
 Dynamic Kernel Module Support Framework

Update Information:

Update to 3.0.9.

ChangeLog:

* Tue Dec  6 2022 Simone Caronni  - 3.0.9-2
- Fix modprobe_on_install variable.
* Mon Dec  5 2022 Simone Caronni  - 3.0.9-1
- Update to 3.0.9.




 gsmartcontrol-1.1.4-3.el7 (FEDORA-EPEL-2022-6aaee02945)
 Graphical user interface for smartctl

Update Information:

Fixed require xterm.

ChangeLog:

* Tue Dec  6 2022 Vasiliy N. Glazov  - 1.1.4-3
- Added Requires xterm #2133082
* Thu Jul 21 2022 Fedora Release Engineering  - 
1.1.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

References:

  [ 1 ] Bug #2133082 - xterm should be listed as a gsmartcontrol package 
dependency
https://bugzilla.redhat.com/show_bug.cgi?id=2133082




 netdata-1.37.1-1.el7 (FEDORA-EPEL-2022-679aa9633d)
 Real-time performance monitoring

Update Information:

Update from upstream    Update from upstream

ChangeLog:

* Tue Dec  6 2022 Didier Fabert  1.37.1-1
- Update from upstream
* Fri Dec  2 2022 Didier Fabert  1.37.0-1
- Update from upstream

References:

  [ 1 ] Bug #2149829 - netdata-1.37.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2149829




 purple-googlechat-0-1.20221106gitb6b824a.el7 (FEDORA-EPEL-2022-aceeb13b75)
 Google Chat plugin for libpurple

Update Information:

Initial SPEC release.

ChangeLog:

* Tue Dec  6 2022 Vitaly Zaitsev  - 
0-1.20221106gitb6b824a
- Initial SPEC release.


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2144904] perl-App-cpm for EPEL 9

https://bugzilla.redhat.com/show_bug.cgi?id=2144904
Bug 2144904 depends on bug 2148436, which changed state.

Bug 2148436 Summary: Add perl-HTTP-Tinyish to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2148436

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2144904
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2148436] Add perl-HTTP-Tinyish to EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-HTTP-Tinyish-0.18-2.el
   ||9
 Status|ON_QA   |CLOSED
Last Closed||2022-12-07 03:15:27



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-e61abbb399 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2148436
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2150998] perl-RT-Client-REST-0.71 is available

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2022-8bfb602a86 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-8bfb602a86`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-8bfb602a86

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2150998] perl-RT-Client-REST-0.71 is available

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-ee41db4054 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-ee41db4054`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-ee41db4054

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2150998] perl-RT-Client-REST-0.71 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2022-10bdbca815 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-10bdbca815`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-10bdbca815

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2143735] perl-Getopt-Long-2.54 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Getopt-Long-2.54-1.fc3 |perl-Getopt-Long-2.54-1.fc3
   |8   |8
   |perl-Getopt-Long-2.54-1.fc3 |perl-Getopt-Long-2.54-1.fc3
   |7   |7
   ||perl-Getopt-Long-2.54-1.fc3
   ||6



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-0ae435577c has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2143735
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2142938] perl-Getopt-Long-2.53 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Getopt-Long-2.53-1.fc3 |perl-Getopt-Long-2.53-1.fc3
   |8   |8
   |perl-Getopt-Long-2.54-1.fc3 |perl-Getopt-Long-2.54-1.fc3
   |7   |7
   ||perl-Getopt-Long-2.54-1.fc3
   ||6



--- Comment #8 from Fedora Update System  ---
FEDORA-2022-0ae435577c has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2142938
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

OpenVPN 2.6 Beta released

2022-12-06 Thread David Sommerseth



Hi,

This is just a heads-up that the OpenVPN community has released
OpenVPN 2.6 beta 1.

While this release includes several nice new features, one important one
requires more attention - Kernel based Data Channel Offload (DCO).  The
DCO support has already been available in the OpenVPN 3 Linux project
for quite some time already, but with OpenVPN 2.6 the performance boost
can now be more noticeable as this also includes full server support.

You can read more about the release here:


There is now a Fedora Copr repository available too, which contains all
the needed pieces:



--
kind regards,

David Sommerseth


signature.asc
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, 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-06 Thread Michael Catanzaro via devel

No. He probably doesn't even know about this proposal yet, since it was just 
published yesterday. This is not the sort of thing that matters for desktop 
performance, where we care about orders of magnitude rather than a few percent 
improvement here or there. Even if extra bounds checking makes code 10% slower, 
which seems very unlikely, the benefit of the extra hardening would still be 
worth it. _FORTIFY_SOURCE=3 is going to make it harder to hack Fedora users, 
converting code execution vulnerabilities into denial of service 
vulnerabilities. That's worth a small performance cost. Reasonable educated 
users will want to make that trade even if we don't know exactly how much the 
cost is.

Ordinarily I would not have even felt any need to comment on a proposal like 
this, except it comes immediately after the rejection of frame pointers, which 
leaves us unable to measure where Fedora performance problems occur without 
rebuilding the world. People who care about performance should be *very* upset 
about that decision. 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.
___
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: Review Request: ImageMagick7

2022-12-06 Thread Sérgio Basto

On Tue, 2022-12-06 at 11:22 -0500, PGNet Dev wrote:
> 
> > As I said earlier in the thread: of the 25 reverse dependencies of
> > the
> > ImageMagick libraries, only five don't build[1].
> > 
> > Further analysis indicates that dvdauthor has a patch in
> > openSUSE[2],
> > but the fix breaks support for GraphicsMagick as an alternative. I
> > want to rework that patch so it doesn't break GraphicsMagick and
> > old
> > ImageMagick support so that it's suitable for upstreaming. I don't
> > expect this to be too difficult to do.
> 
> I understand this^^ is re: distro building/packaging
> 
> there's been at least one mention/question about run-time
> compatibility in this thread
> 
> I've not noticed mention previously, so just in case relevant here,
> fwiw
> 
> lsb_release -rd
> Description:    Fedora release 37 (Thirty Seven)
> Release:    37
> 
> rpm -qa | grep -i magick | sort
> GraphicsMagick-1.3.38-3.fc37.x86_64
> GraphicsMagick-c++-1.3.38-3.fc37.x86_64
> GraphicsMagick-c++-devel-1.3.38-3.fc37.x86_64
> GraphicsMagick-devel-1.3.38-3.fc37.x86_64
> GraphicsMagick-perl-1.3.38-3.fc37.x86_64
> ImageMagick7-7.1.0.52-1.fc37.remi.x86_64
> ImageMagick7-c++-7.1.0.52-1.fc37.remi.x86_64
> ImageMagick7-c++-devel-7.1.0.52-1.fc37.remi.x86_64
> ImageMagick7-devel-7.1.0.52-1.fc37.remi.x86_64
> ImageMagick7-libs-7.1.0.52-1.fc37.remi.x86_64
> ImageMagick7-perl-7.1.0.52-1.fc37.remi.x86_64
> ImageMagick-c++-6.9.12.67-1.fc37.remi.x86_64
> ImageMagick-libs-6.9.12.67-1.fc37.remi.x86_64
> php-pecl-imagick-im6-3.7.0-2.fc37.remi.8.2.x86_64
> 
> rpm -q --whatprovides `which convert`
> ImageMagick7-7.1.0.52-1.fc37.remi.x86_64
> 
> 
> IM7 has been in-place for quite awhile here, installed from Remi's
> repos,
> 
> 
> https://blog.remirepo.net/post/2016/12/12/ImageMagick6-and-ImageMagic
> k7
> 
> https://www.howtofixthis.com/categories/installing-linux-tools/instal
> ling-imagemagick-from-remi-repository-or-via-source-code
> https://ask.fedoraproject.org/t/how-to-install-imagemagick-7-
> on-fedora-35/20354
> 
> my machines certainly do not touch all packages with any IM deps.
> but, so far, I'm not aware of any complaint/error/etc re: that
> mix/use of *Magick pkgs on a bunch of similarly configured boxes.


TL;DR, but my proposal is almost bring a Remi copy of ImageMagick7 to
Fedora and EPEL. As Remi also based on Fedora and contribute to Fedora
/EPEL, so IMHO I can say is a "team" work . 






-- 
Sérgio M. B.
___
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)

On Tue, Dec 6, 2022 at 7:04 PM Michael Catanzaro via devel
 wrote:

> Red Hat's desktop performance engineer 

Since you bring up RH's performance engineer,
have they done performance evaluation on
_FORTIFY_SOURCE=3?  And while I understand
that until the eval is reviewed and reproduced no
final results will be available, can they share
any initial preprint results from their work?
___
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: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Josh Boyer

On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen  wrote:
>
>
>
> On Tue, 6 Dec 2022 at 13:50, Josh Boyer  wrote:
>>
>> On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa  wrote:
>> >
>> > On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer  
>> > wrote:
>> > >
>> > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
>> > > >
>> > > > On 05/12/2022 16:00, Jarek Prokop wrote:
>> > > >
>> > > >
>> > > > On 12/5/22 14:57, Peter Robinson wrote:
>> > > >
>> > > > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
>> > > >  wrote:
>>
>> > > I wouldn't expect them to build for a Fedora version.  I also wouldn't
>> > > expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
>> > > work on Fedora either.
>> > >
>> >
>> > As a practical matter, I generally *do* expect them to be compatible
>> > at some level. RHEL is a derivative of Fedora. Otherwise it gets very
>> > difficult to use commercial software on a Fedora system. I know plenty
>> > of ISVs that have a similar expectation.
>>
>> That compatibility degrades over time though.  At this point in time,
>> with RHEL 7 being almost 9 years old, I would not expect software
>> built on RHEL 7 to work on any supported Fedora version.  If it does
>> work, that's fantastic and a testament to Fedora, but people should
>> not have that expectation.  Terry is politely asking for a policy that
>> would set that expectation.  I think the intention is good, but I
>> don't believe it to be realistic.
>>
>
> I think he would be happy with the policy spelled out in any form. Something 
> like:
>
> While the Fedora Project is the upstream of CentOS Stream and Red Hat 
> Enterprise Linux, it does not give any guarantees of its releases being 
> compatible with either. Software built in either may not work due to missing 
> dependencies, changes in kernel, compile time or library options, or similar 
> issues.

Ah!  Yes, making that clear would be good.

josh

>> To perhaps illustrate the point further, Red Hat Enterprise Linux does
>> not support applications built on version X-1 running on X unless it
>> is constrained to using a very very small set of dependencies (glibc,
>> libgcc/libstdc++, and a few smaller libraries).  Again, it may work
>> fine but the expectation and support policies set for RHEL are
>> (simplified) build on X, run on X where X is within a major version.
>> Our full documentation on this is available in the Application
>> Compatibility Guides.
>>
>> 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, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> --
> 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
___
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-06 Thread Michael Catanzaro via devel

Red Hat's desktop performance engineer has repeatedly rejected use of DWARF as 
impractical and outlandish, including on this mailing list [1] and most 
recently at [2].

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UV65DSMPINEE6KWNI5MBH3MBQ26JHNNJ/

[2] 
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1437#note_1191710138
___
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)

On Tue, Dec 06, 2022 at 05:52:16PM -, Andrii Nakryiko wrote:
> > On Tue, Dec 06, 2022 at 03:12:19AM +, Gary Buhrmaster wrote:
> > 
> > Note that is not a fully equivalent scenario. The no-omit-frame-pointer
> > proposal was only offering a functional debugging benefit to a fairly
> > small number of users who are also developers, while adding a likely
> > performance hit to all users. There needs to be a high bar to justify
> > the performance hit when the benefit offered is narrow.
> 
> First, frame pointers are not just for debugging benefit. It's not even it's 
> main benefit from POV of https://pagure.io/fesco/issue/2817. Frame pointers 
> are for performance profiling and observability first and foremost, and 
> that's most useful under real-world conditions of production workloads. Not 
> some custom re-built debug versions of applications.
>
> Second, it might benefit a relatively small (but not tiny, it's at least 
> thousands of people doing performance profiling) fraction of users, but those 
> users (developers that care about performance) are the ones bringing benefits 
> to very wide user base.

Yes!  I spent a frustrating time getting perf to record stack traces
properly until I recompiled the program with frame pointers.  (I know
about --call-graph=dwarf but it doesn't seem to work most of the time.)

Rich.

> And third, with appropriate infrastructure of background perf profiling that 
> projects like GNOME and KDE can put in place (if they haven't already), user 
> doesn't have to be involved in performance profiling directly to benefit the 
> ecosystem at large, providing anonymized source of real-world profiling data 
> that could be aggregated and looked at by GNOME/KDE/whatnot developers that 
> do care about performance.
> 
> But this won't happen unless GNOME/KDE can rely on having frame pointers in 
> user systems.
> 
> > 
> > This proposal is adding a functional security benefit to all users,
> > alongside the possible performance hit. This is more easily justifiable,
> > especially given Fedora's track record of being willing to security
> > improvements even when they have a performance hit.
> > 
> > With regards,
> > Daniel
> ___
> 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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko
 wrote:
> > On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster
> >  >
> > 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."
> >
> > To elaborate, I think the performance and code size study is an
> > interesting academic concern, but the magnitude of improvement
> > justifies whatever little performance impact this may introduce and it
> > should not be a blocker for the improvement.
>
> It's interesting how now it's just an academic concern. Please hold yourself 
> to at least the standards set for https://pagure.io/fesco/issue/2817 in terms 
> of benchmarking and persuading everyone that performance degradation across 
> entire ecosystem is not a concern.
>

I don't think the two are comparable at all, neither in terms of
potential performance impact (register pressure across an entire
program vs at specific API call points in some unique cases) nor in
terms of the benefits it provides.

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

Re: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Stephen Smoogen

On Tue, 6 Dec 2022 at 13:50, Josh Boyer  wrote:

> On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa  wrote:
> >
> > On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer 
> wrote:
> > >
> > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby 
> wrote:
> > > >
> > > > On 05/12/2022 16:00, Jarek Prokop wrote:
> > > >
> > > >
> > > > On 12/5/22 14:57, Peter Robinson wrote:
> > > >
> > > > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
> > > >  wrote:
>
> > > I wouldn't expect them to build for a Fedora version.  I also wouldn't
> > > expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
> > > work on Fedora either.
> > >
> >
> > As a practical matter, I generally *do* expect them to be compatible
> > at some level. RHEL is a derivative of Fedora. Otherwise it gets very
> > difficult to use commercial software on a Fedora system. I know plenty
> > of ISVs that have a similar expectation.
>
> That compatibility degrades over time though.  At this point in time,
> with RHEL 7 being almost 9 years old, I would not expect software
> built on RHEL 7 to work on any supported Fedora version.  If it does
> work, that's fantastic and a testament to Fedora, but people should
> not have that expectation.  Terry is politely asking for a policy that
> would set that expectation.  I think the intention is good, but I
> don't believe it to be realistic.
>
>
I think he would be happy with the policy spelled out in any form.
Something like:

While the Fedora Project is the upstream of CentOS Stream and Red Hat
Enterprise Linux, it does not give any guarantees of its releases being
compatible with either. Software built in either may not work due to
missing dependencies, changes in kernel, compile time or library options,
or similar issues.



> To perhaps illustrate the point further, Red Hat Enterprise Linux does
> not support applications built on version X-1 running on X unless it
> is constrained to using a very very small set of dependencies (glibc,
> libgcc/libstdc++, and a few smaller libraries).  Again, it may work
> fine but the expectation and support policies set for RHEL are
> (simplified) build on X, run on X where X is within a major version.
> Our full documentation on this is available in the Application
> Compatibility Guides.
>
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


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

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

2022-12-06 Thread przemek klosowski via devel

Andrii,

copilot to pilot, you are responding to Jakub Jelinek's points, not
Neal's. Jakub is a compiler/toolchain engineer with considerable
experience, so when he talks about compiler technology involved in
tracing execution flow, I am inclined to believe him.

I understand that your experience lies in running (and
tracing/profiling) production applications, but please consider that
your viewpoint may be biased by your experience with existing frame
pointer-based instrumentation. This means that you just know from
experience when your results are solid and when you have to be careful
because of e.g. a particular application's large number of small
prolog/epilog-dominated functions or complex and intensive flow of
memory allocations. Jakub is saying that DWARF is a superior technology
that provide the frame pointer information more reliably, so the real
issue is that frame pointer based infrastructure is already here and
DWARF handling requires more development. I haven't heard anyone
question the solidity of the DWARF approach outlined by Jakub and other
people involved with the toolchain, so I think it is reasonable to
expect that it will get implemented.

Are you actually against using the DWARF approach for technical reasons,
or is your argument based on the practical consideration of what's
available right now?

Very Respectfully

p.k.

On 12/6/22 12:46, Andrii Nakryiko wrote:

On Tue, Dec 06, 2022 at 08:13:51AM -0500, Neal Gompa wrote:

That is nonsense. Even with -fno-omit-frame-pointers, you can't rely
on frame pointers, they are not accurate in function prologues and epilogues
and they are total garbage e.g. in a lot of functions written in assembly.

First of all,
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffesco%2Fissue%2F2817data=05%7C01%7Cprzemek.klosowski%40nist.gov%7Ca591777f6c0249b566ff08dad7b1d043%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C638059455959276624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UB%2FsGNKWZQRvJiPPB7wmPwHXvtSFkMCZ0nltpyQmAl0%3Dreserved=0
is first and foremost about enabling low-overhead **profiling** of applications (periodic
in background or on-demand requested by users explicitly), not debugging use cases. For
debugging use cases GDB might be perfectly adequate to rely only on DWARF information. But
-fno-omit-frame-pointers is to enable profiling **production workloads** as they happen,
because very often reproducibility of results is impossible without understanding the issue
in the first place, which is what frame pointers are needed for. Even more often you don't
even realize that application is doing something suboptimal unless you profile it
continuously, as it handles *real workload*.

Now, about prologues/epilogues. What percentage of useful workload is spent in
those? Tiny fraction of a percent at best? Even if we don't get accurate stack
trace in such cases it doesn't matter in the grand scheme of things.

As for hand-written assembly functions. I looked at strcmp, memcpy and similar
very frequent and hot functions in glibc. Yes, they don't save %rbp and don't
maintain frame pointers. But they also don't use %rbp register at all, which
means **they don't clobber it**. So if we take stack trace while such function
is executing, we'll still get non-broken stack trace all the way up to the root
parent function, we just won't have leaf-level function in stack traces. That's
much better and more useful than completely broken stack and allows to reason
very well about application performance. Also, almost all fpu-related routines
under sysdeps/x86_64/fpu/multiarch/svml*.S that are using %rbp, are also
properly maintaining frame pointers:

There is a very good reason why Meta enabled -fno-omit-frame-pointers across
all its internal software 5 years ago and never looked back. We rely on frame
pointers being available across millions of machines to drive performance
improvements and investigations saving millions of dollars of real
non-hypothetical savings. Google, Netflix, Apple, etc -- all enable frame
pointers due to sheer usefulness of them in practice, either for performance
profiling and/or better real-time introspection of their workloads.

So much for the "nonsense". I realize that not everyone have experience with
tracing production workloads and generally working in profiling area, but I expect people
to keep an open mind and not use double standards when thinking about implications of
system-wide changes like this one or frame pointers one.

The only reliable way to get backtraces is DWARF info or something derived
from it, that is for code emitted by the compilers (with the default
-fasynchronous-unwind-tables) accurate for all instructions and for
hand written assembly one has at least a way to describe that through
.cfi_* directives.

As has been written multiple times, for profiling there

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

2022-12-06 Thread Jakub Jelinek

On Tue, Dec 06, 2022 at 05:46:11PM -, Andrii Nakryiko wrote:
> Now, about prologues/epilogues. What percentage of useful workload is spent 
> in those? Tiny fraction of a percent at best? Even if we don't get accurate 
> stack trace in such cases it doesn't matter in the grand scheme of things.

Depends on how large functions are.  If you have lots of small functions,
it can be more than 50% of instructions you get the frame pointer wrong.

> As for hand-written assembly functions. I looked at strcmp, memcpy and 
> similar very frequent and hot functions in glibc.

You haven't looked carefully enough.

find . -name \*.S | xargs grep -l %rbp | xargs grep -L movq.*%rsp.*%rbp
./sysdeps/x86_64/fpu/multiarch/svml_s_tanhf16_core_avx512.S
./sysdeps/x86_64/fpu/multiarch/svml_s_tanhf8_core_avx2.S
./sysdeps/x86_64/fpu/multiarch/svml_s_atanhf16_core_avx512.S
./sysdeps/x86_64/fpu/multiarch/svml_s_atanhf8_core_avx2.S
./sysdeps/x86_64/fpu/svml_d_sincos2_core.S
./sysdeps/x86_64/fpu/svml_s_sincosf4_core.S
./sysdeps/x86_64/addmul_1.S
./sysdeps/x86_64/__longjmp.S
./sysdeps/x86_64/setjmp.S
./sysdeps/x86_64/_mcount.S
./sysdeps/unix/sysv/linux/x86_64/longjmp_chk.S
./sysdeps/unix/sysv/linux/x86_64/setcontext.S
./sysdeps/unix/sysv/linux/x86_64/swapcontext.S
./sysdeps/unix/sysv/linux/x86_64/getcontext.S

E.g. mpn_addmul_1 is used by printf, which certainly shows up a lot in
normal workloads.  The above cases mean the bp register contains total
garbage if one tries to use it for backtrace purposes.  And obviously
glibc isn't the only library with inline assembly out there...
As I said, you can't rely on frame pointers making sense, with unwind info
such as in DWARF you know that in this case rbp is used as a frame pointer
and in this case it is not, use some other register or this offset from
stack pointer etc.

AFAIK systemtap already uses DWARF unwinder in the kernel and as I said, for
the profiling purposes one can use only a small subset of that for the vast
majority of cases.

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

[EPEL-devel] Re: ELN Extras responsibility

2022-12-06 Thread Troy Dawson

I'm sorry, I clicked, "Send" too quickly.
If the document doesn't have that Note in it yet, please wait an hour an
check again.

On Tue, Dec 6, 2022 at 9:57 AM Troy Dawson  wrote:

> The ELN Extras page[1] was updated with one note.  I thought I'd share
> that note with the epel-devel mailing list.
>
> NOTE: **You** are responsible when your package fails to build on ELN
> Extras.  Remember to check your packages on the ELN Status Page.[2]
> ELN Extras packages get rebuilt much more frequently than in EPEL.
>
> I guess that's a little out of context.
> "You" means the person putting a package into ELN Extras.
>
> We just wanted to emphasize that when you put a package ELN Extras
> you are committing to make sure that package builds in ELN for the
> next three years, or whenever you remove it.
> ELN Extra packages get rebuilt a minimum of once every six month, usually
> more often.  It's whenever that package get's rebuilt in rawhide.
> Don't expect magic to happen.
> Check in on your packages frequently and make sure they are healthy.
>
> Troy
>
> [1] - https://docs.fedoraproject.org/en-US/eln/extras/
> [2] - http://distrobuildsync-eln-ops.apps.stream.rdu2.redhat.com/status
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] ELN Extras responsibility

2022-12-06 Thread Troy Dawson

The ELN Extras page[1] was updated with one note.  I thought I'd share that
note with the epel-devel mailing list.

NOTE: **You** are responsible when your package fails to build on ELN
Extras.  Remember to check your packages on the ELN Status Page.[2]
ELN Extras packages get rebuilt much more frequently than in EPEL.

I guess that's a little out of context.
"You" means the person putting a package into ELN Extras.

We just wanted to emphasize that when you put a package ELN Extras
you are committing to make sure that package builds in ELN for the
next three years, or whenever you remove it.
ELN Extra packages get rebuilt a minimum of once every six month, usually
more often.  It's whenever that package get's rebuilt in rawhide.
Don't expect magic to happen.
Check in on your packages frequently and make sure they are healthy.

Troy

[1] - https://docs.fedoraproject.org/en-US/eln/extras/
[2] - http://distrobuildsync-eln-ops.apps.stream.rdu2.redhat.com/status
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-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-06 Thread Andrii Nakryiko

> On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster
>  
> 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."
> 
> To elaborate, I think the performance and code size study is an
> interesting academic concern, but the magnitude of improvement
> justifies whatever little performance impact this may introduce and it
> should not be a blocker for the improvement.

It's interesting how now it's just an academic concern. Please hold yourself to 
at least the standards set for https://pagure.io/fesco/issue/2817 in terms of 
benchmarking and persuading everyone that performance degradation across entire 
ecosystem is not a concern. 

> 
> 
> Sure, I could add that as a comment in the proposal.

We need benchmarks, not a comment. Thank you.

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

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

2022-12-06 Thread Andrii Nakryiko

> On Tue, Dec 06, 2022 at 03:12:19AM +, Gary Buhrmaster wrote:
> 
> Note that is not a fully equivalent scenario. The no-omit-frame-pointer
> proposal was only offering a functional debugging benefit to a fairly
> small number of users who are also developers, while adding a likely
> performance hit to all users. There needs to be a high bar to justify
> the performance hit when the benefit offered is narrow.

First, frame pointers are not just for debugging benefit. It's not even it's 
main benefit from POV of https://pagure.io/fesco/issue/2817. Frame pointers are 
for performance profiling and observability first and foremost, and that's most 
useful under real-world conditions of production workloads. Not some custom 
re-built debug versions of applications.

Second, it might benefit a relatively small (but not tiny, it's at least 
thousands of people doing performance profiling) fraction of users, but those 
users (developers that care about performance) are the ones bringing benefits 
to very wide user base.

And third, with appropriate infrastructure of background perf profiling that 
projects like GNOME and KDE can put in place (if they haven't already), user 
doesn't have to be involved in performance profiling directly to benefit the 
ecosystem at large, providing anonymized source of real-world profiling data 
that could be aggregated and looked at by GNOME/KDE/whatnot developers that do 
care about performance.

But this won't happen unless GNOME/KDE can rely on having frame pointers in 
user systems.

> 
> This proposal is adding a functional security benefit to all users,
> alongside the possible performance hit. This is more easily justifiable,
> especially given Fedora's track record of being willing to security
> improvements even when they have a performance hit.
> 
> With regards,
> Daniel
___
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-06 Thread Andrii Nakryiko

> On Tue, Dec 06, 2022 at 08:13:51AM -0500, Neal Gompa wrote:
> 
> That is nonsense.  Even with -fno-omit-frame-pointers, you can't rely
> on frame pointers, they are not accurate in function prologues and epilogues
> and they are total garbage e.g. in a lot of functions written in assembly.

First of all, https://pagure.io/fesco/issue/2817 is first and foremost about 
enabling low-overhead **profiling** of applications (periodic in background or 
on-demand requested by users explicitly), not debugging use cases. For 
debugging use cases GDB might be perfectly adequate to rely only on DWARF 
information. But -fno-omit-frame-pointers is to enable profiling **production 
workloads** as they happen, because very often reproducibility of results is 
impossible without understanding the issue in the first place, which is what 
frame pointers are needed for. Even more often you don't even realize that 
application is doing something suboptimal unless you profile it continuously, 
as it handles *real workload*.

Now, about prologues/epilogues. What percentage of useful workload is spent in 
those? Tiny fraction of a percent at best? Even if we don't get accurate stack 
trace in such cases it doesn't matter in the grand scheme of things.

As for hand-written assembly functions. I looked at strcmp, memcpy and similar 
very frequent and hot functions in glibc. Yes, they don't save %rbp and don't 
maintain frame pointers. But they also don't use %rbp register at all, which 
means **they don't clobber it**. So if we take stack trace while such function 
is executing, we'll still get non-broken stack trace all the way up to the root 
parent function, we just won't have leaf-level function in stack traces. That's 
much better and more useful than completely broken stack and allows to reason 
very well about application performance. Also, almost all fpu-related routines 
under sysdeps/x86_64/fpu/multiarch/svml*.S that are using %rbp, are also 
properly maintaining frame pointers:

There is a very good reason why Meta enabled -fno-omit-frame-pointers across 
all its internal software 5 years ago and never looked back. We rely on frame 
pointers being available across millions of machines to drive performance 
improvements and investigations saving millions of dollars of real 
non-hypothetical savings. Google, Netflix, Apple, etc -- all enable frame 
pointers due to sheer usefulness of them in practice, either for performance 
profiling and/or better real-time introspection of their workloads.

So much for the "nonsense". I realize that not everyone have experience with 
tracing production workloads and generally working in profiling area, but I 
expect people to keep an open mind and not use double standards when thinking 
about implications of system-wide changes like this one or frame pointers one.

> The only reliable way to get backtraces is DWARF info or something derived
> from it, that is for code emitted by the compilers (with the default
> -fasynchronous-unwind-tables) accurate for all instructions and for
> hand written assembly one has at least a way to describe that through
> .cfi_* directives.
> 
> As has been written multiple times, for profiling there doesn't need to be
> full DWARF unwinder in the kernel, it is enough that there is something
> that can handle the wast majority of cases and punt (copy to userland full
> stack) in case of anything unexpected as long as it is rare.
> Say on x86-64 and various other targets, the stack pointer, CFA (how to get
> caller's stack pointer), frame pointer if any or return address is very
> rarely stored anywhere but on the stack, so it should be enough to consider
> CFA, sp, bp, ip during unwinding and ignore everything else and from the
> harder DW_CFA_* ops (those that need DWARF expression evaluation)
> perhaps only pattern recognize the most common ones (say PLT slot, signal
> frame).

You clearly have never tried to do this in practice. You'd know about the price 
of discovering and pre-computing such look up tables, both in terms of memory 
usage, CPU usage, complexity and reliability. And then you'd also realize the 
problem of tracing short-lived processes that started after profiling started 
and were discovered upfront. As for the approach with capturing stack and 
sending it for post-processing. Beyond just the overhead of capturing and 
sending so much data for post-processing, you'd also stop and wonder what is 
the right size of stack to capture to handle deep stacks/recursion or functions 
with large stack size usage.

DWARF is not a panacea. For production workloads it doesn't even come close as 
an satisfactory solution, if employed in isolation.

> 
> Frame pointers will never result in anything reliable though, it results
> purely in severe performance degradation and false feeling they can be
> relied on.

THIS is nonsense, both on degradation and reliability points. Performance 
engineers and just typical applications owners laugh at your

Re: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Vít Ondruch



Dne 06. 12. 22 v 17:09 Terry Barnaby napsal(a):

On 06/12/2022 15:56, Vít Ondruch wrote:


Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be 
depreciated,

or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.
Well, that is still *some* work and someone would have to do it. 
Are you

volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long 
as you

need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did 
was re-introduce the bits to the SPEC file that removed the building 
of the compat lib and we are fine. I haven't separated it out from 
the main ncurses SPEC through and have only done this locally as I 
have no knowledge of the hoops to create a separate package and that 
seems like the wrong way to do this in general. I have made this 
available to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the 
OS is likely to support. If the policy is to just support Fedora 
built binaries within the particular version of Fedora and to ignore 
external and commercial binaries built with say Redhat7 and provide 
no degree of compatibility so be it, but it would be useful for 
everyone to know where the land lies and be on the same page. The 
maintainer of the ncurses package wasn't sure of the policy on this.



I wonder what is this claim based upon? Could you provide a link? And 
I wonder if there was such policy, would the maintainer changed their 
mind? I am asking because I don't think that any policy can be 
enforced unless there is somebody to pickup the work. So in this 
case, it should be enough to convince the maintainer to revert the 
changes, shouldn't be?



Vít




Sorry, what claim ?



My question was specifically about the last sentence of the quote, e.g. 
do you have any link to BZ ticket, ML or anywhere else where this was 
discussed? That would help to get complete picture.





I have no issue with the maintainer in this particular instance, as 
people have said if a maintainer doesn't want to support something 
that is fine. And obviously a Policy may not be enforced, but at least 
it would be a guideline. I understand the maintainer asked a question 
on when to depreciate on this list, but had no replies.



Ah, so there was ML thread you are referring to. Is it this one?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z3U6CAM4YVI2Y62QNQIHHHLPD7QEXBBV/#Z3U6CAM4YVI2Y62QNQIHHHLPD7QEXBBV

And this could also provide more context:

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


He took it that if the compat libs were not in use by any Fedora 
packages for the release in question it should/could be depreciated 
which is one approach.



It seems that Miroslav would consider the change if there was such 
guidelines.


So do you have any specific gudelines draft?

I think this is always the same, if you really want Fedora to do 
something, then it might need to take some action. Sometimes is enough 
to open ticket or send email, other times it means to maintain package 
or draft specific proposal for guidelines. You can even join the Fedora 
governing bodies if you think it will help.


But I still think the best option for you and for the whole Fedora 
community would be if you picked up the compat-ncurses package maintenance.



Vít



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, report it:

Summary/Minutes from today's FESCo Meeting (2022-12-06)

2022-12-06 Thread Miro Hrončok


===
#fedora-meeting: FESCO (2022-12-06)
===


Meeting started by mhroncok at 17:00:22 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2022-12-06/fesco.2022-12-06-17.00.log.html
.



Meeting summary
---
* init process  (mhroncok, 17:00:33)

* #2905 Re-approval of Change proposal: RPM Macros for Build Flags for
  F38  (mhroncok, 17:03:57)
  * AGREED: APPROVED (+8,0,-1). The change is approved with a slight
modification. "The Fedora packaging policy will be updated to
require that packages that want to use additional flag use the new
macros" will be relaxed to s/require/recommend/ to allow packagers
to not use this change if they desire to use the same spec in older
Fedora/EL releases.  (mhroncok, 17:23:27)

* Next week's chair  (mhroncok, 17:24:16)
  * ACTION: dcantrell will chair next meeting  (mhroncok, 17:25:54)

* Open Floor  (mhroncok, 17:26:06)
  * LINK: https://pagure.io/fesco/issue/2883#comment-829846
(decathorpe, 17:34:27)

Meeting ended at 17:36:25 UTC.




Action Items

* dcantrell will chair next meeting




Action Items, by person
---
* dcantrell
  * dcantrell will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mhroncok (62)
* zodbot (16)
* nirik (14)
* dcantrell (14)
* decathorpe (11)
* zbyszek (10)
* music[m] (8)
* mhayden (2)
* Eighth_Doctor (2)
* bcotton (1)
* gotmax (1)
* 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
___
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: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Josh Boyer

On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa  wrote:
>
> On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer  wrote:
> >
> > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
> > >
> > > On 05/12/2022 16:00, Jarek Prokop wrote:
> > >
> > >
> > > On 12/5/22 14:57, Peter Robinson wrote:
> > >
> > > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
> > >  wrote:
> > >
> > > On 05/12/2022 12:39, Terry Barnaby wrote:
> > >
> > > I am wondering what Fedora's policy is on depreciated old shared
> > > libraries and particularly compat RPM's ?
> > >
> > > Fedora is a bleeding edge distribution. If you need old versions, you
> > > should try CentOS or RHEL.
> > >
> > > Being leading edge doesn't mean those usecases aren't relevant, one is
> > > not mutually exclusive to the other, especially when it comes to
> > > things like FPGAs etc.
> > >
> > > We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
> > > gnome-boxes, and probably others I forgot).
> > > There shouldn't be a problem spinning up a graphical environment of 
> > > CentOS 7, getting EPEL and then using the tool.
> > >
> > > Maybe the tool would work using the `toolbox` utility using last known 
> > > good Fedora version for the tool.
> > > That is just my wild guess however.
> > >
> > > This is sometimes the tax for being "too" modern.
> > > If the vendor does not want to support Fedora, we can't be held 
> > > accountable to fully support their solution.
> > > Does the software work? Yes? That is great! If not, well… we can't do 
> > > much without the source code under nice FOSS license, can we.
> > >
> > > Regards,
> > > Jarek
> > >
> > > Although yes, there are things like VM's, containers etc. which we use 
> > > for old development environments all of these are, IMO, clumsy and 
> > > awkward to use and difficult to manage especially within automated build 
> > > environments that build the complete code for an embedded system with 
> > > various CPU's, FPGA's, other tools etc.
> > >
> > > I know Fedora is fairly bleeding edge (really too bleeding edge for our 
> > > uses, but others are too far behind), but there is obviously going to be 
> > > a balance here so that Fedora is still useful to as many people as 
> > > reasonably possible, hence the question on a policy.
> > >
> > > In the particular case I am talking about, libncurses*5.so, this is a 
> > > fairly common shared library used by quite a few command line tools. A 
> > > lot of external/commercial programs are built on/for Redhat7 as it is a 
> > > de-facto base Linux platform and programs built on it will likely work on 
> > > many other Linux systems. These companies are not going to build for a 
> > > version of Fedora, it changes far to fast and would require large amounts 
> > > or development/support work because of this. Some of the tools I am using 
> > > were built/shipped in Feburary 2022, so we are not talking about old 
> > > tools here.
> >
> > I wouldn't expect them to build for a Fedora version.  I also wouldn't
> > expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
> > work on Fedora either.
> >
>
> As a practical matter, I generally *do* expect them to be compatible
> at some level. RHEL is a derivative of Fedora. Otherwise it gets very
> difficult to use commercial software on a Fedora system. I know plenty
> of ISVs that have a similar expectation.

That compatibility degrades over time though.  At this point in time,
with RHEL 7 being almost 9 years old, I would not expect software
built on RHEL 7 to work on any supported Fedora version.  If it does
work, that's fantastic and a testament to Fedora, but people should
not have that expectation.  Terry is politely asking for a policy that
would set that expectation.  I think the intention is good, but I
don't believe it to be realistic.

To perhaps illustrate the point further, Red Hat Enterprise Linux does
not support applications built on version X-1 running on X unless it
is constrained to using a very very small set of dependencies (glibc,
libgcc/libstdc++, and a few smaller libraries).  Again, it may work
fine but the expectation and support policies set for RHEL are
(simplified) build on X, run on X where X is within a major version.
Our full documentation on this is available in the Application
Compatibility Guides.

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

Re: Review Request: ImageMagick7

On Tue, Dec 6, 2022 at 11:30 AM Kevin Kofler via devel
 wrote:
>
> Neal Gompa wrote:
> > While that is true, *I* don't like doing that if I don't have to. I'd
> > rather try to get things fixed upstream in tandem. Upstreams tend to
> > appreciate that in my experience. :)
>
> Sure, but it tends to be significantly more work. Upstreams need to support
> several platforms at once, so they often cannot just move to new libraries
> and drop support for the old ones, and some are also quite picky about code
> style issues that ultimately do not matter to end users.
>
> > (This is probably why so many people think I'm everywhere, to be honest!
> > :P )
>
> :-)
>
> > Further analysis indicates that dvdauthor has a patch in openSUSE[2],
> > but the fix breaks support for GraphicsMagick as an alternative. I
> > want to rework that patch so it doesn't break GraphicsMagick and old
> > ImageMagick support so that it's suitable for upstreaming. I don't
> > expect this to be too difficult to do.
>
> Well, that is exactly why it is harder to make a patch that is acceptable to
> upstream than one that works in the distribution. A downstream patch can
> even be conditionally applied, if you want to support old and new library
> versions in the same specfile, so the dual support need not be in the patch.
> This is of course not the case for an upstream patch. So then you end up not
> only adding "#ifdef"s for every line you changed, but also need to add a
> build system ("configure") check for the library version. It can turn a
> quick search job into a patch adding dozens of new lines of code.
>

I'll just say this: anything worth doing is worth doing well.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

Terry Barnaby wrote:
> Well in this case I have created a suitable compat lib, all I did was
> re-introduce the bits to the SPEC file that removed the building of the
> compat lib and we are fine. I haven't separated it out from the main
> ncurses SPEC through and have only done this locally as I have no
> knowledge of the hoops to create a separate package and that seems like
> the wrong way to do this in general. I have made this available to
> others who will be in the same boat.

Typically, compatibility libraries should not be subpackages of the main 
library. But ncurses is a bit peculiar in that, as I understand it, the 
latest code can still be built with the old ABI. So in that case, it at 
least makes sense to build both from the same SRPM. But only if they are 
going to be maintained by the same maintainer(s), i.e., you should probably 
sign up as a comaintainer for ncurses in Fedora if you want to do it that 
way. And of course only as long as upstream continues supporting building 
for the old ABI. If they drop support, then a separate compatibility package 
with an old version that supports the old ABI will be needed.

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

Re: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Michael Cronenworth


On 12/5/22 5:39 AM, Terry Barnaby wrote:
With the latest release of Fedora37 we were hit with an issue where the 
ncurses-compat-libs RPM had been depreciated. Due to this some of the tools we use 
would no longer install from their respective RPM's or their tar based installs 
would not run as they needed the libncurses*5.so shared libraries.


If anyone has a support contact with the following hardware vendors could you tell 
them this?


- Canon
   Their 'ufr2' driver for CUPS depends on ncurses-compat-libs. They push updated 
versions as of February 2022 that still depend on it.


- Western Digital / HGST
   Their 'hugo' tool depends on libtinfo.so.5 and the tool is currently maintained 
and shipped to customers today. The latest version I have from 2021 still depends on it.

___
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: Review Request: ImageMagick7

Neal Gompa wrote:
> While that is true, *I* don't like doing that if I don't have to. I'd
> rather try to get things fixed upstream in tandem. Upstreams tend to
> appreciate that in my experience. :)

Sure, but it tends to be significantly more work. Upstreams need to support 
several platforms at once, so they often cannot just move to new libraries 
and drop support for the old ones, and some are also quite picky about code 
style issues that ultimately do not matter to end users.

> (This is probably why so many people think I'm everywhere, to be honest!
> :P )

:-)

> Further analysis indicates that dvdauthor has a patch in openSUSE[2],
> but the fix breaks support for GraphicsMagick as an alternative. I
> want to rework that patch so it doesn't break GraphicsMagick and old
> ImageMagick support so that it's suitable for upstreaming. I don't
> expect this to be too difficult to do.

Well, that is exactly why it is harder to make a patch that is acceptable to 
upstream than one that works in the distribution. A downstream patch can 
even be conditionally applied, if you want to support old and new library 
versions in the same specfile, so the dual support need not be in the patch. 
This is of course not the case for an upstream patch. So then you end up not 
only adding "#ifdef"s for every line you changed, but also need to add a 
build system ("configure") check for the library version. It can turn a 
quick search job into a patch adding dozens of new lines of code.

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

Re: Policy on supporting old and external software packages and compat RPMS

On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer  wrote:
>
> On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
> >
> > On 05/12/2022 16:00, Jarek Prokop wrote:
> >
> >
> > On 12/5/22 14:57, Peter Robinson wrote:
> >
> > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
> >  wrote:
> >
> > On 05/12/2022 12:39, Terry Barnaby wrote:
> >
> > I am wondering what Fedora's policy is on depreciated old shared
> > libraries and particularly compat RPM's ?
> >
> > Fedora is a bleeding edge distribution. If you need old versions, you
> > should try CentOS or RHEL.
> >
> > Being leading edge doesn't mean those usecases aren't relevant, one is
> > not mutually exclusive to the other, especially when it comes to
> > things like FPGAs etc.
> >
> > We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
> > gnome-boxes, and probably others I forgot).
> > There shouldn't be a problem spinning up a graphical environment of CentOS 
> > 7, getting EPEL and then using the tool.
> >
> > Maybe the tool would work using the `toolbox` utility using last known good 
> > Fedora version for the tool.
> > That is just my wild guess however.
> >
> > This is sometimes the tax for being "too" modern.
> > If the vendor does not want to support Fedora, we can't be held accountable 
> > to fully support their solution.
> > Does the software work? Yes? That is great! If not, well… we can't do much 
> > without the source code under nice FOSS license, can we.
> >
> > Regards,
> > Jarek
> >
> > Although yes, there are things like VM's, containers etc. which we use for 
> > old development environments all of these are, IMO, clumsy and awkward to 
> > use and difficult to manage especially within automated build environments 
> > that build the complete code for an embedded system with various CPU's, 
> > FPGA's, other tools etc.
> >
> > I know Fedora is fairly bleeding edge (really too bleeding edge for our 
> > uses, but others are too far behind), but there is obviously going to be a 
> > balance here so that Fedora is still useful to as many people as reasonably 
> > possible, hence the question on a policy.
> >
> > In the particular case I am talking about, libncurses*5.so, this is a 
> > fairly common shared library used by quite a few command line tools. A lot 
> > of external/commercial programs are built on/for Redhat7 as it is a 
> > de-facto base Linux platform and programs built on it will likely work on 
> > many other Linux systems. These companies are not going to build for a 
> > version of Fedora, it changes far to fast and would require large amounts 
> > or development/support work because of this. Some of the tools I am using 
> > were built/shipped in Feburary 2022, so we are not talking about old tools 
> > here.
>
> I wouldn't expect them to build for a Fedora version.  I also wouldn't
> expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
> work on Fedora either.
>

As a practical matter, I generally *do* expect them to be compatible
at some level. RHEL is a derivative of Fedora. Otherwise it gets very
difficult to use commercial software on a Fedora system. I know plenty
of ISVs that have a similar expectation.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

2022-12-06 Thread PGNet Dev




As I said earlier in the thread: of the 25 reverse dependencies of the
ImageMagick libraries, only five don't build[1].

Further analysis indicates that dvdauthor has a patch in openSUSE[2],
but the fix breaks support for GraphicsMagick as an alternative. I
want to rework that patch so it doesn't break GraphicsMagick and old
ImageMagick support so that it's suitable for upstreaming. I don't
expect this to be too difficult to do.


I understand this^^ is re: distro building/packaging

there's been at least one mention/question about run-time compatibility in this 
thread

I've not noticed mention previously, so just in case relevant here, fwiw

lsb_release -rd
Description:Fedora release 37 (Thirty Seven)
Release:37

rpm -qa | grep -i magick | sort
GraphicsMagick-1.3.38-3.fc37.x86_64
GraphicsMagick-c++-1.3.38-3.fc37.x86_64
GraphicsMagick-c++-devel-1.3.38-3.fc37.x86_64
GraphicsMagick-devel-1.3.38-3.fc37.x86_64
GraphicsMagick-perl-1.3.38-3.fc37.x86_64
ImageMagick7-7.1.0.52-1.fc37.remi.x86_64
ImageMagick7-c++-7.1.0.52-1.fc37.remi.x86_64
ImageMagick7-c++-devel-7.1.0.52-1.fc37.remi.x86_64
ImageMagick7-devel-7.1.0.52-1.fc37.remi.x86_64
ImageMagick7-libs-7.1.0.52-1.fc37.remi.x86_64
ImageMagick7-perl-7.1.0.52-1.fc37.remi.x86_64
ImageMagick-c++-6.9.12.67-1.fc37.remi.x86_64
ImageMagick-libs-6.9.12.67-1.fc37.remi.x86_64
php-pecl-imagick-im6-3.7.0-2.fc37.remi.8.2.x86_64

rpm -q --whatprovides `which convert`
ImageMagick7-7.1.0.52-1.fc37.remi.x86_64


IM7 has been in-place for quite awhile here, installed from Remi's repos,

https://blog.remirepo.net/post/2016/12/12/ImageMagick6-and-ImageMagick7

https://www.howtofixthis.com/categories/installing-linux-tools/installing-imagemagick-from-remi-repository-or-via-source-code

https://ask.fedoraproject.org/t/how-to-install-imagemagick-7-on-fedora-35/20354

my machines certainly do not touch all packages with any IM deps.
but, so far, I'm not aware of any complaint/error/etc re: that mix/use of 
*Magick pkgs on a bunch of similarly configured boxes.
___
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

[Bug 2150992] perl-generators 1.14 started to create bogus dependencies for relative imports, e.g. perl(.::t/lifecycles/utils.pl)

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

Miro Hrončok  changed:

   What|Removed |Added

Summary|perl-generators 1.14|perl-generators 1.14
   |started to create bogus |started to create bogus
   |dependencies on |dependencies for relative
   |perl(.::t/lifecycles/utils. |imports, e.g.
   |pl) |perl(.::t/lifecycles/utils.
   ||pl)




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150992
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2150992] perl-generators 1.14 started to create bogus dependencies on perl(.::t/lifecycles/utils.pl)

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



--- Comment #3 from Miro Hrončok  ---
(In reply to Petr Pisar from comment #2)
> > perl(CGI::PSGI)
> 
> This dependency is correct:
> 
> t/web/redirect.t:5:use CGI::PSGI;

Yes, I never said it is not.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150992
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Ewoud Kohl van Wijngaarden


On Tue, Dec 06, 2022 at 03:44:37PM +, Terry Barnaby wrote:

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be depreciated,
or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.

Well, that is still *some* work and someone would have to do it. Are you
volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of 
the compat lib and we are fine. I haven't separated it out from the 
main ncurses SPEC through and have only done this locally as I have no 
knowledge of the hoops to create a separate package and that seems 
like the wrong way to do this in general. I have made this available 
to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS 
is likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore 
external and commercial binaries built with say Redhat7 and provide no 
degree of compatibility so be it, but it would be useful for everyone 
to know where the land lies and be on the same page. The maintainer of 
the ncurses package wasn't sure of the policy on this. In my case, a 
lack of being able to easily run particular external/commercial 
programs built for Redhat7 will likely move me further away from 
working with Fedora (using, reporting bugs, promoting it etc.) as it 
will be a less useful system for our usage.


I'm not in charge of policy, but I always assumed it was based on 
technical possibilities (within reason) and people wanting to invest 
time in it.


Open source is for me all based on fixing your own issues and doing it 
in such a way that it others can benefit from it too. If you have a use 
case for something and are willing to spend the time to keep it alive 
while not limiting others, Fedora can support it.

___
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

[Bug 2151307] New: perl-Log-Dispatchouli-3.002 is available

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

Bug ID: 2151307
   Summary: perl-Log-Dispatchouli-3.002 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-Dispatchouli
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 3.002
Upstream release that is considered latest: 3.002
Current version/release in rawhide: 3.001-1.fc38
URL: http://search.cpan.org/dist/Log-Dispatchouli

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/7173/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Log-Dispatchouli


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2151307
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review Request: ImageMagick7

On Tue, Dec 6, 2022 at 10:49 AM Kevin Kofler via devel
 wrote:
>
> Neal Gompa wrote:
> > There are actually
> > other packages I could fix in Fedora with patches from openSUSE or
> > PLD, but they need more work to not break compatibility with building
> > with GraphicsMagick (which these packages in question support), so
> > using IM6 there for now is fine while that gets worked out.
>
> If there are patches, I do not see why we cannot just apply them downstream
> instead of building against a compat package, especially if we make
> ImageMagick 7 the default as you propose.
>
> There is no rule in Fedora that any and all patches must be upstreamed.
> Especially building against the distribution's version of a library is
> exactly what a distribution is for and hence the perfect example of when it
> makes sense to patch a package.
>

While that is true, *I* don't like doing that if I don't have to. I'd
rather try to get things fixed upstream in tandem. Upstreams tend to
appreciate that in my experience. :)

(This is probably why so many people think I'm everywhere, to be honest! :P )

> IMHO, either we go with Sergio's plan, letting ImageMagick be version 6
> forever and introducing ImageMagick7 (and in the future ImageMagick8, etc.)
> for all newer versions, then we can slowly switch packages from ImageMagick
> to ImageMagick7, or we go with your plan and move ImageMagick to version 7,
> but then we should do all we can to make really everything use the new
> version.
>

As I said earlier in the thread: of the 25 reverse dependencies of the
ImageMagick libraries, only five don't build[1].

Further analysis indicates that dvdauthor has a patch in openSUSE[2],
but the fix breaks support for GraphicsMagick as an alternative. I
want to rework that patch so it doesn't break GraphicsMagick and old
ImageMagick support so that it's suitable for upstreaming. I don't
expect this to be too difficult to do.

[1]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/24CLLA46CAIKWRSPYVLZFLDPLTPRDU7U/
[2]: 
https://code.opensuse.org/package/dvdauthor/blob/master/f/dvdauthor-0.7.2-imagemagick7.patch


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Terry Barnaby


On 06/12/2022 15:56, Vít Ondruch wrote:


Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be depreciated,
or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.
Well, that is still *some* work and someone would have to do it. Are 
you

volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as 
you

need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of 
the compat lib and we are fine. I haven't separated it out from the 
main ncurses SPEC through and have only done this locally as I have 
no knowledge of the hoops to create a separate package and that seems 
like the wrong way to do this in general. I have made this available 
to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS 
is likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore 
external and commercial binaries built with say Redhat7 and provide 
no degree of compatibility so be it, but it would be useful for 
everyone to know where the land lies and be on the same page. The 
maintainer of the ncurses package wasn't sure of the policy on this.



I wonder what is this claim based upon? Could you provide a link? And 
I wonder if there was such policy, would the maintainer changed their 
mind? I am asking because I don't think that any policy can be 
enforced unless there is somebody to pickup the work. So in this case, 
it should be enough to convince the maintainer to revert the changes, 
shouldn't be?



Vít




Sorry, what claim ?

I have no issue with the maintainer in this particular instance, as 
people have said if a maintainer doesn't want to support something that 
is fine. And obviously a Policy may not be enforced, but at least it 
would be a guideline. I understand the maintainer asked a question on 
when to depreciate on this list, but had no replies. He took it that if 
the compat libs were not in use by any Fedora packages for the release 
in question it should/could be depreciated which is one approach.


___
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

[rpms/perl-generators] PR #1: 1.15 bump; Package tests

2022-12-06 Thread Jitka Plesnikova


jplesnik merged a pull-request against the project: `perl-generators` that you 
are following.

Merged pull-request:

``
1.15 bump; Package tests
``

https://src.fedoraproject.org/rpms/perl-generators/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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-06 Thread Jarek Prokop

Hi,

first off, sorry if my write-up seemed a bit harsh, this was the last
time I am trying to respond to a change proposal late at night :).

On 12/6/22 14:14, Siddhesh Poyarekar wrote:

On Mon, Dec 5, 2022 at 7:35 PM Jaroslav Prokop wrote:

Default C and C++ compiler flags to build packages in Fedora currently
includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of
some functions in glibc, thus providing some mitigation against buffer
overflows. Since glibc 2.34 and GCC 12, there has been a new
fortification level (`_FORTIFY_SOURCE=3`) which improves the coverage
of this mitigation.

The core change to bring in this mitigation is to change the default
build flags in `redhat-rpm-config` so that packages build by default
with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`)
that do not interact well with `_FORTIFY_SOURCE` and will also need a
workaround to downgrade fortification to level 2. The change will also
include this override.

How come systemd gets an exception? If it is a security option, it should be
enabled everywhere.

It's an unfortunate (although hopefully temporary) exclusion, see this
issue for more context:

https://github.com/systemd/systemd/issues/22801

In summary, systemd uses malloc_usable_size in a way that it's
discouraged, which results in behaviour that's undefined by the
standard, which is now caught out by the compiler. We're hoping to
convince the systemd community to fix this so that we can actually
build it with fortification.

I do not see benefit in a security change that ignores PID 1 process,

Do you mean that factually or rhetorically? I've shared statistics of
improvement in the proposal, surely improvements to packages like
bash, sudo and coreutils would count for something :)

If the feature, on the GCC side, is not 100% done.
How do I tell a difference of a bug with the _FORTIFY_SOURCE which I will
ignore and a bug with my package?

_FORTIFY_SOURCE=3 has been enabled on OpenSUSE for nearly a year. If
it causes a crash in your package, it's extremely likely that your
package has a bug.
This is interesting to know. I was not aware of this as I do not follow
other distributions closely.

I would have appreciated seeing this noted on the proposal.
I then know I can compare spec files / build results with the relevant
counterparts if it works for them but not for us.

I do not have the knowledge or the time to be able to say that GCC generated
the wrong machine code and therefore it is not a bug with my package.
If my program was not complaining before the change and is now complaining with
the change, I am opting out of the change, and filing a bug against GCC on
Fedora.

I assume that by the package providing the exception, packagers get to choose
themselves and we do not need to go through FESCO
to disable a security feature?

I think they should have to, but that's something for FESCO to decide.
_FORTIFY_SOURCE is not a new feature, the new level is just better at
catching bugs. Significantly better.

To this point, including and opt-out mechanism is IMO reasonable.
Even including a "reference" to the opt out mechanism of the current
_FORTIFY_SOURCE level,

should it be the same, is valuable.

== Benefit to Fedora ==

[https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing
Analysis of packages] in Fedora rawhide indicate that the improvement
of mitigation coverage is on average over 2.4x, in some cases
protecting more than half of the fortified glibc calls in the target
application.

This change will thus harden Fedora to a significant extent, thus
making it a more secure distribution out of the box.

1) Is there some complete source for all these findings? If google sheets cannot handle
all the "raw data" as noted in the comment,
maybe it is the wrong medium.

I've literally posted the raw data in the sheets, please take a look.
Ah, I was starting to get mixed up the sheet pages. The "Raw data - All
x86_64" include the sentence "Note: Summary data since Google sheets
didn't like the raw data".

Other raw data variants seem to be correctly "raw".

2) What does *anything* on that google sheet mean. I have managed to figure
out, from the article, that bos and bdos correspond to level 2 and 3 of
_FORTIFY_SOURCE.
However, total of /.*/? Violated accesses? Segfaults? Then followed by "Sum of total".
For rubygem-ffi, this reaches into hundreds while "bdos" is 2. That is the only sum I can
make, with the data provided.
I am no wiser from looking at it, what do the data mean?

I've mentioned this in the article, but it's a compile-time statistic
of the number of success of __builtin_object_size vs
__builtin_dynamic_object_size, using the fortify-metrics plugin:

https://github.com/siddhesh/fortify-metrics

The numbers you should be looking at are the "coverage" columns, which
tells you what percentage of the calls were successful. For
rubygem-ffi, the fortification is

Re: Review Request: ImageMagick7

On Tue, Dec 6, 2022 at 10:17 AM Michael Cronenworth  wrote:
>
> On 12/6/22 8:31 AM, Neal Gompa wrote:
> > There's a very important difference between September 2017 and now: we
> > know someone else already did it!
>
> Great. Good luck.
>
> > As an aside: I don't appreciate the "high horse" comment, considering
> > during most of this discussion, I was doing the work and evaluating
> > things.
>
> It's unfortunate you feel this way. Maybe we cannot work together.
>

I don't think that's the case. The point I'm making is that I'm not
speaking from a point of arrogance, but trying to speak from the
ideals of what we're supposed to do, while simultaneously trying to
actually execute on that to demonstrate that I'm willing to help to
make it happen. Most of the complaints from Sergio and you seem to be
centered on doing it alone and taking on the entire workload
yourselves, but that is not a requirement at all. I spent a chunk of
my Sunday adapting the ImageMagick packaging, building an ImageMagick6
package, and rebuilding packages from Dist-Git in COPR against
ImageMagick 7 to figure out what the scope of things are.

I truly think that transitioning to ImageMagick 7 for the majority of
packages is a lot less difficult than it was back when it was tried in
2017. And dragging our feet on this isn't going to help anything.

The ImageMagick 6 website itself states the recommendation to move to
ImageMagick 7 now:

> As ImageMagick version 6 is no longer being evolved, we recommend you switch 
> to ImageMagick version 7. In the mean-time we continue to support and add 
> security patches, but not evolve, ImageMagick version 6, until at least 
> August 1, 2030.

Yes, the EOL period is further out, but I'd rather make it so that the
next RHEL will have ImageMagick 7 right from the beginning. And in
EPEL 9, there's one package that needs a patch to build against
ImageMagick 7 if we wanted to make that bump and ship the ImageMagick6
compat package there like I propose we do for Fedora.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2022-12-06 Thread tdawson

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2022-12-07 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




Source: https://calendar.fedoraproject.org//meeting/9854/

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Vít Ondruch



Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be depreciated,
or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.

Well, that is still *some* work and someone would have to do it. Are you
volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of 
the compat lib and we are fine. I haven't separated it out from the 
main ncurses SPEC through and have only done this locally as I have no 
knowledge of the hoops to create a separate package and that seems 
like the wrong way to do this in general. I have made this available 
to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS 
is likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore 
external and commercial binaries built with say Redhat7 and provide no 
degree of compatibility so be it, but it would be useful for everyone 
to know where the land lies and be on the same page. The maintainer of 
the ncurses package wasn't sure of the policy on this.



I wonder what is this claim based upon? Could you provide a link? And I 
wonder if there was such policy, would the maintainer changed their 
mind? I am asking because I don't think that any policy can be enforced 
unless there is somebody to pickup the work. So in this case, it should 
be enough to convince the maintainer to revert the changes, shouldn't be?



Vít


In my case, a lack of being able to easily run particular 
external/commercial programs built for Redhat7 will likely move me 
further away from working with Fedora (using, reporting bugs, 
promoting it etc.) as it will be a less useful system for our usage.

___
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


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

[rpms/perl-generators] PR #1: 1.15 bump; Package tests

2022-12-06 Thread Jitka Plesnikova


jplesnik opened a new pull-request against the project: `perl-generators` that 
you are following:
``
1.15 bump; Package tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-generators/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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)

On Tue, Dec 6, 2022 at 3:42 PM Siddhesh Poyarekar  wrote:

> I have added a performance note[1] in the proposal.

Thank you.
___
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: Review Request: ImageMagick7

Neal Gompa wrote:
> There are actually
> other packages I could fix in Fedora with patches from openSUSE or
> PLD, but they need more work to not break compatibility with building
> with GraphicsMagick (which these packages in question support), so
> using IM6 there for now is fine while that gets worked out.

If there are patches, I do not see why we cannot just apply them downstream 
instead of building against a compat package, especially if we make 
ImageMagick 7 the default as you propose.

There is no rule in Fedora that any and all patches must be upstreamed. 
Especially building against the distribution's version of a library is 
exactly what a distribution is for and hence the perfect example of when it 
makes sense to patch a package.

IMHO, either we go with Sergio's plan, letting ImageMagick be version 6 
forever and introducing ImageMagick7 (and in the future ImageMagick8, etc.) 
for all newer versions, then we can slowly switch packages from ImageMagick 
to ImageMagick7, or we go with your plan and move ImageMagick to version 7, 
but then we should do all we can to make really everything use the new 
version.

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

Re: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Terry Barnaby


On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be depreciated,
or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.

Well, that is still *some* work and someone would have to do it. Are you
volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of the 
compat lib and we are fine. I haven't separated it out from the main 
ncurses SPEC through and have only done this locally as I have no 
knowledge of the hoops to create a separate package and that seems like 
the wrong way to do this in general. I have made this available to 
others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS is 
likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore external 
and commercial binaries built with say Redhat7 and provide no degree of 
compatibility so be it, but it would be useful for everyone to know 
where the land lies and be on the same page. The maintainer of the 
ncurses package wasn't sure of the policy on this. In my case, a lack of 
being able to easily run particular external/commercial programs built 
for Redhat7 will likely move me further away from working with Fedora 
(using, reporting bugs, promoting it etc.) as it will be a less useful 
system for our usage.

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

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.

Thanks,
Sid

[1] 
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags#Performance_note
___
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)

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).
___
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: Review Request: ImageMagick7

2022-12-06 Thread Michael Cronenworth


On 12/6/22 8:31 AM, Neal Gompa wrote:

There's a very important difference between September 2017 and now: we
know someone else already did it!


Great. Good luck.


As an aside: I don't appreciate the "high horse" comment, considering
during most of this discussion, I was doing the work and evaluating
things.


It's unfortunate you feel this way. Maybe we cannot work together.

Take care.
___
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)

On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster
 wrote:
>
> On Tue, Dec 6, 2022 at 12:47 PM Siddhesh Poyarekar  
> wrote:
>
> > Overall even if there is a miniscule performance overhead, I
> > reckon the reward is much higher.
>
> I am curious how you can claim there is only a
> minuscule performance overhead without doing
> any benchmarks?
>
> I am not claiming the overheads are high, I
> don't know, but I know enough to trust that
> when you (yourself) said in the article:
>
>"We need a proper study of performance
>and code size to understand the magnitude
>of the impact"
>
> that you are making a very clear statement
> that you believe that such a study is needed.
>
> If you do not believe that that statement
> is correct, will you be issuing a correction
> to the posted article saying that such a study
> is no longer needed?

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

To elaborate, I think the performance and code size study is an
interesting academic concern, but the magnitude of improvement
justifies whatever little performance impact this may introduce and it
should not be a blocker for the improvement.

> And without any benchmarks, the proposal
> should acknowledge explicitly that some
> unknown performance penalty may be seen,
> and needs to be accepted as a trade-off for
> security reasons (some may be fine with that,
> others less so, but that is a different debate
> to have).

Sure, I could add that as a comment in the proposal.

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

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

On Tue, Dec 6, 2022 at 12:47 PM Siddhesh Poyarekar  wrote:

> Overall even if there is a miniscule performance overhead, I
> reckon the reward is much higher.

I am curious how you can claim there is only a
minuscule performance overhead without doing
any benchmarks?

I am not claiming the overheads are high, I
don't know, but I know enough to trust that
when you (yourself) said in the article:

   "We need a proper study of performance
   and code size to understand the magnitude
   of the impact"

that you are making a very clear statement
that you believe that such a study is needed.

If you do not believe that that statement
is correct, will you be issuing a correction
to the posted article saying that such a study
is no longer needed?

And without any benchmarks, the proposal
should acknowledge explicitly that some
unknown performance penalty may be seen,
and needs to be accepted as a trade-off for
security reasons (some may be fine with that,
others less so, but that is a different debate
to have).
___
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)

On Tue, Dec 6, 2022 at 9:55 AM Siddhesh Poyarekar  wrote:
>
> On Tue, Dec 6, 2022 at 8:14 AM Siddhesh Poyarekar  wrote:
> > > Please provide a proper "how to test" section, I cannot fix what I cannot 
> > > test or compare results when I have no idea what I am seeing.
> > >
> > > Actually, last time I heard about number of packages, it was around 50k 
> > > (not source, build result), and as I stated,
> > > Ruby is missing, and so are quite a few dependent packages that should 
> > > have GCC involved somewhere:
> > > ~~~
> > > $ dnf repoquery --whatrequires "*libruby.so*" --disablerepo="*" 
> > > --enablerepo="fedora" 2>/dev/null | grep -v "i686" | uniq | wc -l
> > > 115
> > > ~~~
> > >
> > > If we also filter rubygem-* packages that depend on the *libruby.so* (and 
> > > most probably contain a binary extension written in C/C++ that links to 
> > > Ruby), I get 68 packages.
> > > When I search "All x86_64" for "ruby" I get 28 packages. That is... not 
> > > adding up.
> >
> > Yeah, I have missed packages; I had looked at revdeps glibc-devel,
> > which turned out around 9k packages, of which 6k had any
> > _FORTIFY_SOURCE use at all.  I can redo with *all* packages and
> > generate a report.
>
> I checked again and it looks like ruby had failed in that mass
> rebuild[1] but I can't see the logs anymore; they've probably been
> garbage collected.  I reckon it was one of those with a transient
> failure that I reran by hand later.  I'm going to run a full rebuild
> anyway (should take about 8 days, about 23k source packages AFAICT)
> and will share the results here.

To be clear, ruby *builds* successfully[1] with _FORTIFY_SOURCE=3, it
just didn't build successfully when running the metrics.

Sid

[1] https://copr.fedorainfracloud.org/coprs/siddhesh/mpb.41/builds/
___
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)

On Tue, Dec 6, 2022 at 8:14 AM Siddhesh Poyarekar  wrote:
> > Please provide a proper "how to test" section, I cannot fix what I cannot 
> > test or compare results when I have no idea what I am seeing.
> >
> > Actually, last time I heard about number of packages, it was around 50k 
> > (not source, build result), and as I stated,
> > Ruby is missing, and so are quite a few dependent packages that should have 
> > GCC involved somewhere:
> > ~~~
> > $ dnf repoquery --whatrequires "*libruby.so*" --disablerepo="*" 
> > --enablerepo="fedora" 2>/dev/null | grep -v "i686" | uniq | wc -l
> > 115
> > ~~~
> >
> > If we also filter rubygem-* packages that depend on the *libruby.so* (and 
> > most probably contain a binary extension written in C/C++ that links to 
> > Ruby), I get 68 packages.
> > When I search "All x86_64" for "ruby" I get 28 packages. That is... not 
> > adding up.
>
> Yeah, I have missed packages; I had looked at revdeps glibc-devel,
> which turned out around 9k packages, of which 6k had any
> _FORTIFY_SOURCE use at all.  I can redo with *all* packages and
> generate a report.

I checked again and it looks like ruby had failed in that mass
rebuild[1] but I can't see the logs anymore; they've probably been
garbage collected.  I reckon it was one of those with a transient
failure that I reran by hand later.  I'm going to run a full rebuild
anyway (should take about 8 days, about 23k source packages AFAICT)
and will share the results here.

Thanks,
Sid

[1] https://copr.fedorainfracloud.org/coprs/siddhesh/mpb.41/builds/
___
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: Review Request: ImageMagick7

On Tue, Dec 6, 2022 at 8:26 AM Michael Cronenworth  wrote:
>
> On 12/5/22 5:41 PM, Neal Gompa wrote:
> > But in general, it looks like an upgrade to ImageMagick 7 will be
> > rather easy to do.
>
> Hi Neal,
>
> I appreciate your eagerness here, but it is a little misled.
>
> Version 7 is radically different than version 6. Most (I don't have an exact 
> figure)
> packages in Fedora are *only* compatible with version 6.
>
> Why do I know this? Check out the ImageMagick git history around September 
> 2017. :)
>

The Git history is not useful. It has no details of why. I've already
looked at it before.

> I think you need to back off the high horse here wanting version 7 as a 
> primary
> package and version 6 as a compat package, but I've relinquished my 
> ImageMagick
> duties as it takes too much time and energy, and Sergio is doing a great job 
> taking
> over.
>

There's a very important difference between September 2017 and now: we
know someone else already did it!

Two distributions have already transitioned from ImageMagick 6 to
ImageMagick 7 by default: PLD (December 2016) and openSUSE (March
2017). As a result of that, a number of packages have already been
made compatible with IM7 over the past five years. Incidentally, this
means ImageMagick 7 is part of SUSE Linux Enterprise 15.

When I went through and rebuilt things, most things *just worked*. I
had to do a very simple tweak to the ImageMagick package to make it
easier to make stuff that's compatible with both find the IM7 headers,
and all but 5 packages built. Only two packages needed patches to
introduce IM6/IM7 compatibility, and one of those isn't dead upstream.
I'll send the patch upstream for that package. There are actually
other packages I could fix in Fedora with patches from openSUSE or
PLD, but they need more work to not break compatibility with building
with GraphicsMagick (which these packages in question support), so
using IM6 there for now is fine while that gets worked out.

I only said we should do it because I know it works. Not doing it
propagates this problem of continuing to default to the legacy
version.

As an aside: I don't appreciate the "high horse" comment, considering
during most of this discussion, I was doing the work and evaluating
things.

--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Upcoming Fedora Linux 38 deadlines

2022-12-06 Thread Ben Cotton

Hi everyone,

As you prepare for the end of the year, it's time to be thinking about
your F38 plans. Here are the upcoming F38 Change proposal deadlines:

* 2022-12-21: Deadline for Changes requiring infrastructure changes
* 2022-12-27: Deadline for System-Wide Changes and Changes requiring a
mass rebuild
* 2023-01-17: Deadline for Self-Contained Changes

The full schedule is at
https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Upcoming Fedora Linux 38 deadlines

2022-12-06 Thread Ben Cotton

Hi everyone,

As you prepare for the end of the year, it's time to be thinking about
your F38 plans. Here are the upcoming F38 Change proposal deadlines:

* 2022-12-21: Deadline for Changes requiring infrastructure changes
* 2022-12-27: Deadline for System-Wide Changes and Changes requiring a
mass rebuild
* 2023-01-17: Deadline for Self-Contained Changes

The full schedule is at
https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Replace versioned MODULE_COMPAT_ requires by generators

2022-12-06 Thread Jitka Plesnikova




Parametric macro dependency generators are not supported in EPEL 7 and
8's RPM versions. You can still implement this using a "regular"
dependency generator. This is also described in the RPM
documentation[1]. Instead of specifying %__perlcompat_requires() and
writing an RPM macro that accepts a path name as %1, you specify
`%__percompat_requires /path/to/executable`. That script receives a
newline separated list of paths as stdin and prints the generated
dependencies to stdout separated by newlines.

So perlcompat.attr could look something like

```
%__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version}

# %%__perlcompat_path can stay the same.
```

These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is
passed to the script as an argument, because the script of course
doesn't have access to the RPM context. This can be any executable
written in any language, but it should be straightforward to do this in
shell.


Thank you for your advice.

The dependency generator would be added to perl-srpm-macros which is in 
buildroot of Fedora.
So, I prepared package perl-srpm-macros-epel which should work for EPEL 
7/8/9.

If you want to check it please look at
https://jplesnik.fedorapeople.org/perl-srpm-macros-epel/

I checked it in Copr
https://copr.fedorainfracloud.org/coprs/jplesnik/perl-epel/.

If the change is approved by FESCo, I'll prepared the review for the 
package.

Then I'll ask you for adding it to epel-srpm-macros.

Regards,
Jitka

--
Jitka Plesnikova
Senior Software Engineer
Red Hat
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-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)

On Tue, Dec 6, 2022 at 5:45 AM Jakub Jelinek  wrote:
>
> On Tue, Dec 06, 2022 at 11:13:38AM +0100, Vitaly Zaitsev via devel wrote:
> > On 05/12/2022 20:58, Ben Cotton wrote:
> > > Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
> > > improve mitigation of security issues arising from buffer overflows in
> > > packages in Fedora.
> >
> > AFAIK, _FORTIFY_SOURCE=3 enables runtime checks for every mem*() function
> > call. This should result in significant performance degradation.
>
> That is misunderstanding.
> The way _FORTIFY_SOURCE works is that say for memcpy if the destination
> has known upper bound on size (__builtin_object_size (dst, 0) returns
> something other than ~(size_t)0), then __memcpy_chk is used instead of
> memcpy, unless the compiler can prove that the length will always fit into
> that destination (in that case it is folded back to (builtin) memcpy).
> So, "every" is definitely not the case.  In many cases nothing is known
> about the size of the destination, and in a lot of cases it is provable that
> no overflow will happen.

To add to this, I twiddled the macros to make sure that even if the
sizes are not known, we can infer safety from ranges of values that
they could have.  For example if the destination object size in memcpy
is known to be at least 1024 bytes and the write size is known to be
at most 64 bytes, the copy is deemed safe at compile time.

> > To proposal owner: add information about potential performance degradation,
> > including benchmark results.
>
> Deferring that to Siddhesh, I haven't done that benchmarking myself.

I haven't run any benchmarks because (1) the magnitude of coverage is
immense, making a small performance impact (IMO) worthwhile and (2)
other distributions have enabled _FORTIFY_SOURCE=3 by default for
nearly a year without any reports of performance degradation from
their users and (3) the code size tests show negligible impact.
However if it is considered a blocker by FESCO, I'll be happy to run a
benchmark they suggest to post numbers.

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

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

2022-12-06 Thread Jakub Jelinek

On Tue, Dec 06, 2022 at 08:13:51AM -0500, Neal Gompa wrote:
> "may improve" is proven to be "does improve significantly". We had

That is nonsense.  Even with -fno-omit-frame-pointers, you can't rely
on frame pointers, they are not accurate in function prologues and epilogues
and they are total garbage e.g. in a lot of functions written in assembly.
The only reliable way to get backtraces is DWARF info or something derived
from it, that is for code emitted by the compilers (with the default
-fasynchronous-unwind-tables) accurate for all instructions and for
hand written assembly one has at least a way to describe that through
.cfi_* directives.

As has been written multiple times, for profiling there doesn't need to be
full DWARF unwinder in the kernel, it is enough that there is something
that can handle the wast majority of cases and punt (copy to userland full
stack) in case of anything unexpected as long as it is rare.
Say on x86-64 and various other targets, the stack pointer, CFA (how to get
caller's stack pointer), frame pointer if any or return address is very
rarely stored anywhere but on the stack, so it should be enough to consider
CFA, sp, bp, ip during unwinding and ignore everything else and from the
harder DW_CFA_* ops (those that need DWARF expression evaluation)
perhaps only pattern recognize the most common ones (say PLT slot, signal
frame).

Frame pointers will never result in anything reliable though, it results
purely in severe performance degradation and false feeling they can be
relied on.

Jakub
___
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: Review Request: ImageMagick7

2022-12-06 Thread Michael Cronenworth


On 12/5/22 5:41 PM, Neal Gompa wrote:

But in general, it looks like an upgrade to ImageMagick 7 will be
rather easy to do.


Hi Neal,

I appreciate your eagerness here, but it is a little misled.

Version 7 is radically different than version 6. Most (I don't have an exact figure) 
packages in Fedora are *only* compatible with version 6.


Why do I know this? Check out the ImageMagick git history around September 
2017. :)

I think you need to back off the high horse here wanting version 7 as a primary 
package and version 6 as a compat package, but I've relinquished my ImageMagick 
duties as it takes too much time and energy, and Sergio is doing a great job taking 
over.


Thanks,
Michael
___
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)

On Tue, Dec 6, 2022 at 4:05 AM Richard W.M. Jones  wrote:
>
> On Tue, Dec 06, 2022 at 01:35:04AM +0100, Jaroslav Prokop wrote:
> > On 12/5/22 20:58, Ben Cotton wrote:
> >
> > The core change to bring in this mitigation is to change the default
> > build flags in `redhat-rpm-config` so that packages build by default
> > with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`)
> > that do not interact well with `_FORTIFY_SOURCE` and will also need a
> > workaround to downgrade fortification to level 2. The change will also
> > include this override.
> >
> > How come systemd gets an exception? If it is a security option, it should be
> > enabled everywhere.
>
> I don't believe the proposal is that everyone *has* to use this (or at
> least, I hope not).  Even existing _FORTIFY_SOURCE=2 is optional.  I'd
> like to know what the problems are that affect systemd however.

Yes, I intend it to be the same as _FORTIFY_SOURCE=2.  In fact, I'm
thinking of a %fortify_level macro override that allows packages to
override this without fiddling directly with cflags.

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

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

On Mon, Dec 5, 2022 at 10:20 PM Gary Buhrmaster
 wrote:
>
> On Mon, Dec 5, 2022 at 10:53 PM Neal Gompa  wrote:
>
> > It has a similar impact that turning back on frame pointers would.
> >
> > Cf. 
> > https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#the_gains_of_improved_security_coverage_outweigh_the_cost
> >
>
> That article explicitly states:
>   "We need a proper study of performance and code size to understand
> the magnitude of the impact"
>
> I look forward to seeing the results of that proper study before
> this is even considered for approval (since, after all, one of the
> strong push-backs for -fno-omit-frame-pointer was performance).

Besides the point that the two are not comparable, code size results
are in the sheet I linked to in the proposal; there's no negative
impact.  The feature has been enabled by default in OpenSUSE for
nearly a year and there have been no noticeable performance issues
reported there either.  IMO the magnitude of improvement is such that
a benchmark shouldn't be a blocker for this feature, but if that's
what FESCO insists, I'll be happy to run whatever benchmark they
suggest.

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

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

On Mon, Dec 5, 2022 at 7:35 PM Jaroslav Prokop  wrote:
> Default C and C++ compiler flags to build packages in Fedora currently
> includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of
> some functions in glibc, thus providing some mitigation against buffer
> overflows.  Since glibc 2.34 and GCC 12, there has been a new
> fortification level (`_FORTIFY_SOURCE=3`) which improves the coverage
> of this mitigation.
>
> The core change to bring in this mitigation is to change the default
> build flags in `redhat-rpm-config` so that packages build by default
> with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`)
> that do not interact well with `_FORTIFY_SOURCE` and will also need a
> workaround to downgrade fortification to level 2. The change will also
> include this override.
>
> How come systemd gets an exception? If it is a security option, it should be 
> enabled everywhere.

It's an unfortunate (although hopefully temporary) exclusion, see this
issue for more context:

https://github.com/systemd/systemd/issues/22801

In summary, systemd uses malloc_usable_size in a way that it's
discouraged, which results in behaviour that's undefined by the
standard, which is now caught out by the compiler.  We're hoping to
convince the systemd community to fix this so that we can actually
build it with fortification.

> I do not see benefit in a security change that ignores PID 1 process,

Do you mean that factually or rhetorically?  I've shared statistics of
improvement in the proposal, surely improvements to packages like
bash, sudo and coreutils would count for something :)

> If the feature, on the GCC side, is not 100% done.
> How do I tell a difference of a bug with the _FORTIFY_SOURCE which I will 
> ignore and a bug with my package?

_FORTIFY_SOURCE=3 has been enabled on OpenSUSE for nearly a year.  If
it causes a crash in your package, it's extremely likely that your
package has a bug.

> I do not have the knowledge or the time to be able to say that GCC generated 
> the wrong machine code and therefore it is not a bug with my package.
> If my program was not complaining before the change and is now complaining 
> with the change, I am opting out of the change, and filing a bug against GCC 
> on Fedora.
>
> I assume that by the package providing the exception, packagers get to choose 
> themselves and we do not need to go through FESCO
> to disable a security feature?

I think they should have to, but that's something for FESCO to decide.
_FORTIFY_SOURCE is not a new feature, the new level is just better at
catching bugs.  Significantly better.

> == Benefit to Fedora ==
>
> [https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing
> Analysis of packages] in Fedora rawhide indicate that the improvement
> of mitigation coverage is on average over 2.4x, in some cases
> protecting more than half of the fortified glibc calls in the target
> application.
>
> This change will thus harden Fedora to a significant extent, thus
> making it a more secure distribution out of the box.
>
>
> 1) Is there some complete source for all these findings? If google sheets 
> cannot handle all the "raw data" as noted in the comment,
> maybe it is the wrong medium.

I've literally posted the raw data in the sheets, please take a look.

> 2) What does *anything* on that google sheet mean. I have managed to figure 
> out, from the article, that bos and bdos correspond to level 2 and 3 of 
> _FORTIFY_SOURCE.
> However, total of /.*/? Violated accesses? Segfaults? Then followed by "Sum 
> of total". For rubygem-ffi, this reaches into hundreds while "bdos" is 2. 
> That is the only sum I can make, with the data provided.
> I am no wiser from looking at it, what do the data mean?

I've mentioned this in the article, but it's a compile-time statistic
of the number of success of __builtin_object_size vs
__builtin_dynamic_object_size, using the fortify-metrics plugin:

https://github.com/siddhesh/fortify-metrics

The numbers you should be looking at are the "coverage" columns, which
tells you what percentage of the calls were successful.  For
rubygem-ffi, the fortification is negligible regardless of whether it
is built at _FORTIFY_SOURCE=2 or _FORTIFY_SOURCE=3.  This means that
it is unaffected by this change.

> 3) I cannot speak to much else than Ruby, I do not see ruby in neither the 
> failures or "All x86_64". Should we attempt to test it ourselves?

That's odd, thanks for pointing out.

> Please provide a proper "how to test" section, I cannot fix what I cannot 
> test or compare results when I have no idea what I am seeing.
>
> Actually, last time I heard about number of packages, it was around 50k (not 
> source, build result), and as I stated,
> Ruby is missing, and so are quite a few dependent packages that should have 
> GCC involved somewhere:
> ~~~
> $ dnf repoquery --whatrequires "*libruby.so*" --disablerepo="*" 
> --enablerepo="fedora" 2>/dev/null | grep

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

On Tue, Dec 6, 2022 at 7:50 AM Siddhesh Poyarekar  wrote:
>
> On Mon, Dec 5, 2022 at 5:53 PM Neal Gompa  wrote:
> >
> > On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
> >  wrote:
> > >
> > > On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton  wrote:
> > > >
> > > > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
> > > >
> > >
> > > It is my vague recollection (I could easily be wrong, so
> > > correct me as appropriate) that _FORTIFY_SOURCE=3
> > > adds some runtime overhead that did not apply in
> > > previous levels.
> > >
> > > If that is correct, has the potential performance impact
> > > been evaluated and documented somewhere?  And, if
> > > correct, the change proposal should probably be modified
> > > to mention the potential performance impacts.
> >
> > It has a similar impact that turning back on frame pointers would.
> >
> > Cf. 
> > https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#the_gains_of_improved_security_coverage_outweigh_the_cost
> >
> > I'm extremely displeased now, as the toolchain team basically told us
> > they wouldn't accept register pressure on x86_64 and then turned
> > around and made a proposal that does the same thing. Apparently
> > quality of life improvements for developers and real-time tracing
> > (e.g. making bpftrace useful) isn't worth it, but this is.
> >
> > I want a really good justification for not doing both at the same time
> > if we're going to accept this.
>
> They're only similar to the extent of potentially having a performance
> impact.  One may improve debugging experience while the other improves
> security mitigation coverage by a factor of 2.4x in the average case
> and 5-10x in some key cases.
>

"may improve" is proven to be "does improve significantly". We had
GNOME and other desktop software developers and hyperscale developers
telling us it would be helpful to have. Entire classes of tracing and
debugging tools *don't work* without frame pointers.

I say that the impact is about equal, just in different areas, with
the same kind of performance hit.

(But who cares about developers, I guess?)

> They're apples and butter chicken.
>

Well, okay then, that's one I hadn't heard before. :P




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Josh Boyer

On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
>
> On 05/12/2022 16:00, Jarek Prokop wrote:
>
>
> On 12/5/22 14:57, Peter Robinson wrote:
>
> On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
>  wrote:
>
> On 05/12/2022 12:39, Terry Barnaby wrote:
>
> I am wondering what Fedora's policy is on depreciated old shared
> libraries and particularly compat RPM's ?
>
> Fedora is a bleeding edge distribution. If you need old versions, you
> should try CentOS or RHEL.
>
> Being leading edge doesn't mean those usecases aren't relevant, one is
> not mutually exclusive to the other, especially when it comes to
> things like FPGAs etc.
>
> We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
> gnome-boxes, and probably others I forgot).
> There shouldn't be a problem spinning up a graphical environment of CentOS 7, 
> getting EPEL and then using the tool.
>
> Maybe the tool would work using the `toolbox` utility using last known good 
> Fedora version for the tool.
> That is just my wild guess however.
>
> This is sometimes the tax for being "too" modern.
> If the vendor does not want to support Fedora, we can't be held accountable 
> to fully support their solution.
> Does the software work? Yes? That is great! If not, well… we can't do much 
> without the source code under nice FOSS license, can we.
>
> Regards,
> Jarek
>
> Although yes, there are things like VM's, containers etc. which we use for 
> old development environments all of these are, IMO, clumsy and awkward to use 
> and difficult to manage especially within automated build environments that 
> build the complete code for an embedded system with various CPU's, FPGA's, 
> other tools etc.
>
> I know Fedora is fairly bleeding edge (really too bleeding edge for our uses, 
> but others are too far behind), but there is obviously going to be a balance 
> here so that Fedora is still useful to as many people as reasonably possible, 
> hence the question on a policy.
>
> In the particular case I am talking about, libncurses*5.so, this is a fairly 
> common shared library used by quite a few command line tools. A lot of 
> external/commercial programs are built on/for Redhat7 as it is a de-facto 
> base Linux platform and programs built on it will likely work on many other 
> Linux systems. These companies are not going to build for a version of 
> Fedora, it changes far to fast and would require large amounts or 
> development/support work because of this. Some of the tools I am using were 
> built/shipped in Feburary 2022, so we are not talking about old tools here.

I wouldn't expect them to build for a Fedora version.  I also wouldn't
expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
work on Fedora either.

> My view is that compat versions of the commonly used shared libraries for 
> programs that are used on Redhat7 should be kept available until most people 
> are not producing programs for that system at least +nyears and then I guess 
> Redhat8 once that really becomes a core base platform that external people 
> use. A core list of these (there are only a few) could be kept somewhere and 
> when one is to be depreciated, or users see problems when Fedora is updated,  
> a decision on this can be then made with that info. This would keep the 
> Fedora system relevant for more users needs without too much work. In the 
> case of ncurses, it is really just putting back into the SPEC file that which 
> was removed for F37 plus the extra storage on mirrors for the compat RPM's.

As a data point, Red Hat Enterprise Linux 9 does not provide
ncurses-compat-libs.  If you can, it would be good to ask your ISVs to
provide a timeline when they will migrate off of a very old version of
ncurses.

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

Re: Review Request: ImageMagick7

2022-12-06 Thread Nico Kadel-Garcia

On Sat, Dec 3, 2022 at 5:57 AM Vitaly Zaitsev via devel
 wrote:
>
> On 03/12/2022 00:30, Sérgio Basto wrote:
> > The proposal now is to keep ImageMagick 6 and make a new package with
> > ImageMagick 7 , when we have all applications use only ImageMagick 7,
> > we move the sources from ImageMagick7 to ImageMagick
>
> I think it would be better to update the ImageMagick package to version
> 7 and create a compatibility package ImageMagick6.
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)

We've had just these issues with Java and python, and years ago with
perl and gcc upgrades. Do the "add a suffix" first, to make the new
version available for testing and debugging, because it's going to
break a *lot* of working code that uses tools like "convert". After
that's had a chance to sink in, then switch the default to be the new
ImageMagick 7 tools, and leave a previous version around as
ImageMagick 6.

The "compat-*" packages, such as the compat-gnutls I've worked with in
RHEL, have been useful for compilation of tools demanding current
versions of libraries, but are not helpful with such a large suite of
executable tools as ImageMagick.
___
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)

On Mon, Dec 5, 2022 at 5:53 PM Neal Gompa  wrote:
>
> On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
>  wrote:
> >
> > On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
> > >
> >
> > It is my vague recollection (I could easily be wrong, so
> > correct me as appropriate) that _FORTIFY_SOURCE=3
> > adds some runtime overhead that did not apply in
> > previous levels.
> >
> > If that is correct, has the potential performance impact
> > been evaluated and documented somewhere?  And, if
> > correct, the change proposal should probably be modified
> > to mention the potential performance impacts.
>
> It has a similar impact that turning back on frame pointers would.
>
> Cf. 
> https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#the_gains_of_improved_security_coverage_outweigh_the_cost
>
> I'm extremely displeased now, as the toolchain team basically told us
> they wouldn't accept register pressure on x86_64 and then turned
> around and made a proposal that does the same thing. Apparently
> quality of life improvements for developers and real-time tracing
> (e.g. making bpftrace useful) isn't worth it, but this is.
>
> I want a really good justification for not doing both at the same time
> if we're going to accept this.

They're only similar to the extent of potentially having a performance
impact.  One may improve debugging experience while the other improves
security mitigation coverage by a factor of 2.4x in the average case
and 5-10x in some key cases.

They're apples and butter chicken.

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

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

On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
 wrote:
>
> On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
> >
>
> It is my vague recollection (I could easily be wrong, so
> correct me as appropriate) that _FORTIFY_SOURCE=3
> adds some runtime overhead that did not apply in
> previous levels.
>
> If that is correct, has the potential performance impact
> been evaluated and documented somewhere?  And, if
> correct, the change proposal should probably be modified
> to mention the potential performance impacts.

There is indeed a theoretical concern over performance due to size
expressions vs constants, but none have been reported in practice.
OpenSUSE and Gentoo (at least) have had _FORTIFY_SOURCE=3 enabled by
default for nearly a year and there haven't seen any reports of
performance degradation.  Besides, the magnitude of mitigation
coverage is *immense*.  For example with bash, where only 3% of the
calls were fortified, now nearly half of the calls are fortified.
Likewise, sudo has gone from about 1% to nearly half.

Note that it doesn't mean that all those new calls have an additional
overhead; the compiler and glibc can also detect which of these
accesses are always safe and it simplifies the calls to the regular
ones.  Overall even if there is a miniscule performance overhead, I
reckon the reward is much higher.  Just ask the folks over at
OpenSUSE, they've uncovered a bunch of bugs over the last year thanks
to this feature.

I did a code size analysis though (since it's a much clearler problem
to analyze) and funnily, _FORTIFY_SOURCE=3 ended up *reducing* code
size by a tiny bit on average.  Very few packages saw code size
increases beyond 1%, most were in the nearly negligible range.  The
numbers are in the Google spreadsheet I linked to in the proposal,
under the "size summary" tab.

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

Re: Review Request: ImageMagick7

2022-12-06 Thread Sérgio Basto

On Sun, 2022-12-04 at 21:06 -0600, Richard Shaw wrote:
> On Sun, Dec 4, 2022 at 6:32 PM Sérgio Basto 
> wrote:
> > Final statement, instead of wasting my time and energy on
> > arguments,
> > Imagemagick7 could already be built on rawhide if someone had done
> > the
> > package review for me
> > 
> 
> 
> I understand the sentiment as another person who has donated 1000s of
> hours to packaging on Fedora, but the "default" package SHOULD be the
> current latest package. It' just part of "Fedora First". 

You are wrong , the default packaging for gtk was gtk+, gtk2 , gtk3,
gtk4 . For wxGTK was wxGTK, wxGTK3 . For Python was python , python3 ,
and you have much more examples that I can remember now 

The ImageMagick 6 series is officially supported until December of
2027.

ImageMagick was not maintained well since about 2018 , Redhat drop it
on el8 and was moved epel because in short and in my humble
interpretation,  gives much work to maintain and have many so bumps
 ( https://access.redhat.com/solutions/4437561  ) 


> So my vote (as much as it matters) is that all packages should be
> built with the latest version in COPR to verify compatibility, and
> the ones that don't, build with an ImageMagik 6 compat package. 
> 
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Sérgio M. B.
___
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: SPDX Statistics

2022-12-06 Thread Michael J Gruber

> false negative - especially 
> the *-fonts because they declare the license using macro, which I am unable 
> to process
> (yet).|

Can I put the new tags in the same macro, e.g.:
```
 %global foundry   ADF
-%global fontlicense   GPLv2+ with exceptions
+%global fontlicense   GPL-2.0-or-later WITH Font-exception-2.0
 %global fontlicenses  OTF/COPYING
 %global fontdocs  NOTICE.txt
```
___
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: 20221206.n.0 changes

2022-12-06 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20221205.n.0
NEW: Fedora-Rawhide-20221206.n.0

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

Size of added packages:  3.51 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.66 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: 8088_bios-0.9.8-1.fc38
Summary: BIOS for Intel 8088 based computers
RPMs:8088_bios
Size:30.80 KiB

Package: lua-cliargs-3.0.2-1.fc38
Summary: A command-line argument parser
RPMs:lua-cliargs
Size:23.79 KiB

Package: lua-epnf-0.3-1.fc38
Summary: Extended PEG Notation Format (easy grammars for LPeg)
RPMs:lua-epnf
Size:12.51 KiB

Package: lua-luarepl-0.10-1.fc38
Summary: REPL.lua - a reusable Lua REPL written in Lua
RPMs:lua-luarepl
Size:26.94 KiB

Package: lua-vstruct-2.1.1-1.fc38
Summary: Lua library to manipulate binary data
RPMs:lua-vstruct
Size:41.89 KiB

Package: pcem-17-2.fc38
Summary: IBM PC emulator
RPMs:pcem
Size:2.90 MiB

Package: pgaudit-1.7.0-3.module_f38+15740+7a459c5e
Summary: PostgreSQL Audit Extension
RPMs:pgaudit
Size:223.05 KiB

Package: python-argon2-cffi-bindings-21.2.0-1.fc38
Summary: Low-level CFFI bindings for Argon2
RPMs:python3-argon2-cffi-bindings
Size:107.77 KiB

Package: python-flit-scm-1.7.0-2.fc38
Summary: PEP 518 build backend that uses setuptools_scm and flit
RPMs:python3-flit-scm
Size:12.50 KiB

Package: python-jupyter-server-terminals-0.4.2-1.fc38
Summary: A Jupyter Server Extension Providing Terminals
RPMs:python3-jupyter-server-terminals
Size:34.54 KiB

Package: xtideuniversalbios-2.0.0^20221002svn624-1.fc38
Summary: XTIDE Universal BIOS
RPMs:xtideuniversalbios
Size:118.76 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  R-errors-0.4.0-1.fc38
Old package:  R-errors-0.3.6-7.fc38
Summary:  Uncertainty Propagation for R Vectors
RPMs: R-errors
Size: 312.69 KiB
Size change:  4.65 KiB
Changelog:
  * Wed Aug 03 2022 Tom spot Callaway  0.3.6-9
  - R 4.2.1

  * Mon Dec 05 2022 I??aki ??car  0.4.0-1
  - Update to 0.4.0


Package:  R-quantities-0.2.0-1.fc38
Old package:  R-quantities-0.1.6-6.fc38
Summary:  Quantity Calculus for R Vectors
RPMs: R-quantities
Size: 2.17 MiB
Size change:  1.53 MiB
Changelog:
  * Sat Sep 03 2022 Tom spot Callaway  0.1.6-7
  - rebuild for R 4.2.1

  * Mon Dec 05 2022 I??aki ??car  0.2.0-1
  - Update to 0.2.0


Package:  alliance-5.1.1-27.20160506gitd8c05cd.fc38
Old package:  alliance-5.1.1-26.20160506gitd8c05cd.fc37
Summary:  VLSI EDA System
RPMs: alliance alliance-devel alliance-doc alliance-libs
Size: 19.71 MiB
Size change:  -10.42 KiB
Changelog:
  * Mon Dec 05 2022 Ralf Cors??pius  - 
5.1.1-27.20160506gitd8c05cd
  - Convert license to SPDX.


Package:  ansible-collection-containers-podman-1.10.1-1.fc38
Old package:  ansible-collection-containers-podman-1.9.4-2.fc37
Summary:  Podman Ansible collection for Podman containers
RPMs: ansible-collection-containers-podman
Size: 96.77 KiB
Size change:  -161.68 KiB
Changelog:
  * Tue Nov 29 2022 Maxwell G  - 1.10.1-1
  - Update to 1.10.1. Fixes rhbz#2143801.
  - Remove useless docs directory from collection artifact.


Package:  awscli-1.27.23-1.fc38
Old package:  awscli-1.27.22-1.fc38
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 3.24 MiB
Size change:  1.14 KiB
Changelog:
  * Mon Dec 05 2022 Gwyn Ciesla  - 1.27.23-1
  - 1.27.23


Package:  buildbot-3.7.0-1.fc38
Old package:  buildbot-3.6.1-1.fc38
Summary:  Build/test automation system
RPMs: buildbot buildbot-master buildbot-master-container 
buildbot-master-ec2 buildbot-master-libvirt buildbot-master-openstack 
buildbot-worker buildbot-www
Size: 4.75 MiB
Size change:  5.04 KiB
Changelog:
  * Mon Dec 05 2022 Gwyn Ciesla  - 3.7.0-1
  - 3.7.0


Package:  claws-mail-4.1.1-2.fc38
Old package:  claws-mail-4.1.1-1.fc38
Summary:  Email client and news reader based on GTK+
RPMs: claws-mail claws-mail-devel claws-mail-plugins 
claws-mail-plugins-acpi-notifier claws-mail-plugins-address-keeper 
claws-mail-plugins-archive claws-mail-plugins-att-remover 
claws-mail-plugins-attachwarner claws-mail-plugins-bogofilter 
claws-mail-plugins-bsfilter claws-mail-plugins-clamd claws-mail-plugins-fancy 
claws-mail-plugins-fetchinfo claws-mail-plugins-gdata 
claws-mail-plugins-keyword_warner claws-mail-plugins-libravatar 
claws-mail-plugins-litehtml-viewer claws-mail-plugins-mailmbox 
claws-mail-plugins-managesieve claws-mail-plugins-newmail 
claws-mail-plugins-notification claws-mail-plugins-pdf-viewer 
claws-mail-plugins-perl claws-mail-plugins-pgp

Re: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

Adam Williamson wrote:

> On Mon, 2022-12-05 at 22:44 +0100, Kevin Kofler via devel wrote:
>> Mattia Verga via devel wrote:
>> > Or let's just get rid of Bodhi and trust all packagers to "know exactly
>> > what they are doing with their package".
>> 
>> Yes please!
> 
> Exhibits 1 through 2636 for why this is a bad idea:
> https://bodhi.fedoraproject.org/updates/?search==unpushed=1

In my ideal world, it would still be possible for a maintainer and for rel-
eng to unpush bad updates. IMHO, even from stable updates, since there is 
not really a technical reason to not allow that. It could be as simple as 
"koji untag-pkg fnn-updates foo".

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

Assess impact of package changes with the mass prebuilder

2022-12-06 Thread Frederic Berat

Hello Fedora community,

The Christmas period is coming, and soon after the Fedora mass rebuild will
come and may lead to the creation of a bunch of FTBFS bugzillas.

I'd like to share with you the availability of a tool that we started  to
develop this year, which aims to help developers to assess the  impact a
change in their component will have on other components that  depend on
them.

I recently used it in order to prepare for the upcoming Autoconf 2.72
release, and with it uncovered about 84 build failures (out of 1197
packages depending on Autoconf) that would have been missed if I were
following the "classical" workflow. This resulted in few bugs opened in
corresponding components, and even upstream changes toward the Autoconf
community, prior to the official 2.72 release.

In the past weeks, it has also been used to assess the impact of porting
Fedora to Modern C (by Florian Weimer) which tested about 10k packages and
for the make 4.4 update (from DJ Delorie), which tested about 9k
dependencies against this new version to look for breakage.

Yet, the more users there will be, the more this tool will improve and be
useful for the packagers.

This tool is called the mass prebuilder. I've written a blog post for Red
Hat a while ago, which already contains a lot of details about it:
https://developers.redhat.com/articles/2022/09/26/find-errors-packages-through-mass-builds

There is a COPR package available to ease installation:
https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/

And a detailed Howto available in the source README:
https://gitlab.com/fedora/packager-tools/mass-prebuild/-/blob/main/README.md

As of today, the tool provides most of the planned features, although it
only uses COPR as a builder backend, whereas Koji is also planned on the
long run (and likely others).
Since the tool is fairly new, it lacks manpages, may miss features you
would expect and is likely to have bugs (even if we tried to limit them as
much as possible).
Therefore, don't hesitate to open issues in the Gitlab repository if need
be: https://gitlab.com/fedora/packager-tools/mass-prebuild/-/issues.

Frédéric Bérat

Senior Software Engineer, Platform Tools

Red Hat 

fbe...@redhat.com

___
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: Policy on supporting old and external software packages and compat RPMS

2022-12-06 Thread Dominik 'Rathann' Mierzejewski

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]
> My view is that compat versions of the commonly used shared libraries
> for programs that are used on Redhat7 should be kept available until
> most people are not producing programs for that system at least
> +nyears and then I guess Redhat8 once that really becomes a core base
> platform that external people use. A core list of these (there are
> only a few) could be kept somewhere and when one is to be depreciated,
> or users see problems when Fedora is updated,  a decision on this can
> be then made with that info. This would keep the Fedora system
> relevant for more users needs without too much work.

Well, that is still *some* work and someone would have to do it. Are you
volunteering?

> In the case of ncurses, it is really just putting back into the SPEC
> file that which was removed for F37 plus the extra storage on mirrors
> for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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-06 Thread Jakub Jelinek

On Tue, Dec 06, 2022 at 11:13:38AM +0100, Vitaly Zaitsev via devel wrote:
> On 05/12/2022 20:58, Ben Cotton wrote:
> > Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
> > improve mitigation of security issues arising from buffer overflows in
> > packages in Fedora.
> 
> AFAIK, _FORTIFY_SOURCE=3 enables runtime checks for every mem*() function
> call. This should result in significant performance degradation.

That is misunderstanding.
The way _FORTIFY_SOURCE works is that say for memcpy if the destination
has known upper bound on size (__builtin_object_size (dst, 0) returns
something other than ~(size_t)0), then __memcpy_chk is used instead of
memcpy, unless the compiler can prove that the length will always fit into
that destination (in that case it is folded back to (builtin) memcpy).
So, "every" is definitely not the case.  In many cases nothing is known
about the size of the destination, and in a lot of cases it is provable that
no overflow will happen.
#define _FORTIFY_SOURCE 2 // or 3
#include 
void qux (void *);
void foo (void *dst, void *src, size_t len) { memcpy (dst, src, len); }
// Nothing is known about the length of dst above, so it will be normal memcpy
void bar (void *src) { char dst[64]; memcpy (dst, src, 32); qux (dst); }
// __builtin_object_size (dst, 0) is 64, but 32 <= 64, so again it will be
// normal memcpy.
void baz (void *src, size_t len) { char dst[64]; memcpy (dst, src, len); qux 
(dst); }
// __builtin_object_size (dst, 0) is 64, we don't know if len <= 64, so
// with _FORTIFY_SOURCE 1 and higher there will be __memcpy_chk (dst, src, len, 
64);
// call.
The only change that happens between _FORTIFY_SOURCE 2 and 3 is that in the
former case only constant upper bounds are computed, while
__builtin_dynamic_object_size can compute either constant (including
~(size_t) 0 for don't know, no upper bound) or something computed at
runtime.
void quux (void *src, size_t len) { char dst = malloc (64); memcpy (dst, src, 
len); qux (dst); }
// The above will still have even with _FORTIFY_SOURCE 2 __bos0 (dst) 64, so
// again __memcpy_chk (dst, src, len, 64);
void corge (void *src, size_t sz, size_t len) { char dst = malloc (sz); memcpy 
(dst, src, len); qux (dst); }
// But the above case changes with -D_FORTIFY_SOURCE=3, with 2 __bos0 (dst)
// is -1, with 3 __bdos0 (dst) is sz.  In this case it is still quite cheap
// to compute, just means extending the lifetime of sz until the
// __memcpy_chk (dst, src, len, sz); call.  True, in some other cases it
// might be more expensive to compute, but the goal is still that the
// compiler can punt at any time to -1 if the computation of the length
// would be too expensive.

> To proposal owner: add information about potential performance degradation,
> including benchmark results.

Deferring that to Siddhesh, I haven't done that benchmarking myself.

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

[Bug 2150998] perl-RT-Client-REST-0.71 is available

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2022-ee41db4054 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-ee41db4054


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2150998] perl-RT-Client-REST-0.71 is available

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-10bdbca815 has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-10bdbca815


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2150998] perl-RT-Client-REST-0.71 is available

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-8bfb602a86 has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-8bfb602a86


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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-06 Thread Vitaly Zaitsev via devel


On 05/12/2022 20:58, Ben Cotton wrote:

Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
improve mitigation of security issues arising from buffer overflows in
packages in Fedora.


AFAIK, _FORTIFY_SOURCE=3 enables runtime checks for every mem*() 
function call. This should result in significant performance degradation.


To proposal owner: add information about potential performance 
degradation, including benchmark results.


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

[Bug 2150998] perl-RT-Client-REST-0.71 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-RT-Client-REST-0.71-1.
   ||fc38



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2151095] perl-Perl-Critic-1.144 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Perl-Critic-1.144-1.fc
   ||38
 Resolution|--- |ERRATA
 Status|MODIFIED|CLOSED
Last Closed||2022-12-06 10:07:33



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-d7ae05143b has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2151095
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2151095] perl-Perl-Critic-1.144 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-d7ae05143b has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-d7ae05143b


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2151095
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2150998] perl-RT-Client-REST-0.71 is available

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

Petr Pisar  changed:

   What|Removed |Added

 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2150992] perl-generators 1.14 started to create bogus dependencies on perl(.::t/lifecycles/utils.pl)

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



--- Comment #2 from Petr Pisar  ---
> $ rpm -qRp rt-tests-5.0.3-2.fc38.noarch.rpm
[...]
> perl(.::t/lifecycles/utils.pl)

I think this is a bug in the generators. Relative imports (./) should be
ignored.

t/web/lifecycle_rights.t:4:BEGIN {require './t/lifecycles/utils.pl'};

> perl(CGI::PSGI)

This dependency is correct:

t/web/redirect.t:5:use CGI::PSGI;


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150992
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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-06 Thread Jarek Prokop



On 12/6/22 10:08, Richard W.M. Jones wrote:

On Tue, Dec 06, 2022 at 08:59:03AM +, Richard W.M. Jones wrote:

I don't believe the proposal is that everyone *has* to use this (or at
least, I hope not).  Even existing _FORTIFY_SOURCE=2 is optional.  I'd
like to know what the problems are that affect systemd however.

It's mentioned in this document:

https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#2__better_fortification_coverage

   _FORTIFY_SOURCE=3 revealed another pattern. Applications such as
   systemd used malloc_usable_size to determine available space in
   objects and then used the residual space. The glibc manual
   discourages this type of usage, dictating that malloc_usable_size is
   for diagnostic purposes only. But applications use the function as a
   hack to avoid reallocating buffers when there is space in the
   underlying malloc chunk. The implementation of malloc_usable_size
   needs to be fixed to return the allocated object size instead of the
   chunk size in non-diagnostic use. Alternatively, another solution is
   to deprecate the function. But that is a topic for discussion by the
   glibc community.

Rich.


Thanks for sharing. I missed that one.

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

On Tue, Dec 06, 2022 at 08:59:03AM +, Richard W.M. Jones wrote:
> I don't believe the proposal is that everyone *has* to use this (or at
> least, I hope not).  Even existing _FORTIFY_SOURCE=2 is optional.  I'd
> like to know what the problems are that affect systemd however.

It's mentioned in this document:

https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#2__better_fortification_coverage

  _FORTIFY_SOURCE=3 revealed another pattern. Applications such as
  systemd used malloc_usable_size to determine available space in
  objects and then used the residual space. The glibc manual
  discourages this type of usage, dictating that malloc_usable_size is
  for diagnostic purposes only. But applications use the function as a
  hack to avoid reallocating buffers when there is space in the
  underlying malloc chunk. The implementation of malloc_usable_size
  needs to be fixed to return the allocated object size instead of the
  chunk size in non-diagnostic use. Alternatively, another solution is
  to deprecate the function. But that is a topic for discussion by the
  glibc community.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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)

On Tue, Dec 06, 2022 at 01:35:04AM +0100, Jaroslav Prokop wrote:
> On 12/5/22 20:58, Ben Cotton wrote:
> 
> The core change to bring in this mitigation is to change the default
> build flags in `redhat-rpm-config` so that packages build by default
> with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`)
> that do not interact well with `_FORTIFY_SOURCE` and will also need a
> workaround to downgrade fortification to level 2. The change will also
> include this override.
> 
> How come systemd gets an exception? If it is a security option, it should be
> enabled everywhere.

I don't believe the proposal is that everyone *has* to use this (or at
least, I hope not).  Even existing _FORTIFY_SOURCE=2 is optional.  I'd
like to know what the problems are that affect systemd however.

> I do not see benefit in a security change that ignores PID 1 process,

I agree we should try to cover it.

> If the feature, on the GCC side, is not 100% done.
> How do I tell a difference of a bug with the _FORTIFY_SOURCE which I will
> ignore and a bug with my package?

By looking at the message printed out when the program crashes, I
guess?  And if that's not enough information, then asking here.

> I do not have the knowledge or the time to be able to say that GCC
> generated the wrong machine code and therefore it is not a bug with
> my package.  If my program was not complaining before the change and
> is now complaining with the change, I am opting out of the change,
> and filing a bug against GCC on Fedora.

GCC & Fedora developers have been very responsive on these kinds of
issues in the past.  No one wants a compiler with code gen problems.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
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)