date:20230116

> Having the vDSO do the unwinding allows the unwinding to be entirely
transparent to userspace programs and libraries

Why *should* unwinding be transparent to userspace programs and libraries? 
Userspace can contribute to making unwinding better, especially in the managed 
case, by hooking into the unwind mechanism and extending it. The ability to 
extend unwinding so that it works with interpreters and managed runtime 
environments implies that the userspace mechanism is accessible, not 
transparent. Additionally, userspace configuration can set unwind policy more 
flexibly than the kernel can.

I'm not sure I understand the value of the "entirely transparent" argument or 
why it should outweigh the extensibility and efficiency advantages of putting 
this functionality in libc. I also haven't seen a strong rationale for putting 
this functionality in vDSO instead of libc. libc is the traditional place where 
we put all userspace bookkeeping for a Linux process. For example, libc manages 
the list of threads and ensures setreuid(2) atomicity across them. It would be 
strange and inconsistent for vDSO to take on this role at this point.

How would you support interpreter and managed runtime extension of the unwind 
mechanism in a vDSO-based model? How would you deal with the problem of how 
putting a large blob of unwinder code in the vDSO would permanently pin it into 
memory even when unwinding is not being used?

You've proposed putting the unwinder in the vDSO and thunking to it from kernel 
space in some manner distinct from signal delivery. I believe that while 
unwinding in userspace is fundamentally a good idea, both aspects of your 
proposed implementation depart unnecessarily from precedent and that we can 
achieve the same functionality with minimal changes to the current user-kernel 
interface by using a signal, not a new kind of kernel-directed jump to the 
vDSO, to start the unwind process.

> languages such as Go that do not use any libc

Go uses libc on operating systems like Windows, Solaris, and OpenBSD. Go's 
bypassing libc on Linux serves no technical purpose and should not be 
encouraged. That said, the mechanism I'm proposing is compatible with Go's 
non-libc Linux model: in this model, Go would merely have to implement the 
profiling signal protocol itself, without libc's help. There's nothing special 
or magical about libc in the model I'm proposing: the Go runtime could 
implement the same protocol with the kernel that libc uses.
___
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

fedpkg local - do not clean build directory

2023-01-16 Thread Orion Poplawski

How the #$@! do I get fedpkg local to not cleanup the local build 
directory after a successful build?  This is the most annoying change to 
come around in a long time IMHO.


Thanks.

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


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

Re: Do we have alternatives to alternatives?

2023-01-16 Thread Robin Lee

On Mon, Jan 16, 2023 at 7:34 PM Petr Menšík  wrote:
>
> Hi!
>
> I heard (read) objections to any alternatives macros usage often. But
> unless I am mistaken, we do not have any user (enough) friendly way to
> support similar functionality tools with just minor differences.
>
> I thought about it recently and I think we have similar issue solved by
> systemd-sysusers macros. Unless I am mistaken, they work fine even on
> rpm-ostree distributions. They have some similarities with alternatives
> %post scriptlets:
>
> those scriptlets more define values for some other tools than they need
> immediate reaction. Original %pre scriptlets adding users had to be
> executed during install and never outside. systemd-sysusers solves it
> fine by calling a common tool and data configuration file. It makes it
> possible to configure all users at a time or just the user from given
> config.
>
> I think similar approach could work with alternatives. Instead of
> defining the alternative name by alternatives --install command, we
> could move link name, path and priority to simple configuration snippet.
> Then process that definition either per-package (for classic rpm %post)
> or after-install (for rpm-ostree based distributions). The result should
> be the same, just time of execution may differ. It would require
> modification of alternatives to read instructions also from config file,
> not only from command line parameters.
>
> It might be naive, but wouldn't such modification allow to solve
> alternatives sufficiently also for ostree based installations? Is there
> a reason why this would not work? Of course it would add extra config
> file per package using alternatives. Unless I am mistaken, we do not
> have full featured replacement for current alternatives. Other than not
> having alternatives at all. I doubt dnf swap approach is more
> user-friendly, especially because it cannot be done by PackageKit GUI tools.
>
> Is there a reason, why my idea cannot work? Is there an unsolved problem
> it could not solve? Have something similar been considered already?
>
> Best Regards,
> Petr
>
> --
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, https://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
In the great blueprint of image-based system[1], system should boot
with an empty /etc filesystem.

But I found Fedora still has two requirements on the /etc filesystem.

The first one is /etc/alternatives. So I also hope we can change to
another mechanism that
satisfies the need for image-based system.

The other is the need for /etc/ld.so.*.

[1] https://0pointer.net/blog/fitting-everything-together.html

-robin
> ___
> 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: Yet another unwinding approach

2023-01-16 Thread Demi Marie Obenour

On 1/16/23 16:32, Daniel Colascione wrote:
>> Could the vDSO do the unwinding?
> 
> The vDSO is just userspace code that happens to be provided by the kernel, 
> so, sure, a function in vDSO *could* unwind. But why would it? What would be 
> the advantage of doing that over putting the unwinding in libc? To change the 
> vDSO, you have to change the kernel, so the vDSO is more suited for things 
> coupled to the kernel, like a fast clock_gettime implementation.

Having the vDSO do the unwinding allows the unwinding to be entirely
transparent to userspace programs and libraries, and therefore provides
complete compatibility with the in-kernel unwinder.  It also allows
supporting programs in languages such as Go that do not use any libc.-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

___
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: 20230116.n.1 changes

2023-01-16 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20230114.n.0
NEW: Fedora-Rawhide-20230116.n.1

= SUMMARY =
Added images:10
Dropped images:  4
Added packages:  2
Dropped packages:0
Upgraded packages:   276
Downgraded packages: 0

Size of added packages:  1.04 MiB
Size of dropped packages:0 B
Size of upgraded packages:   11.38 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -113.37 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20230116.n.1.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20230116.n.1.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20230116.n.1.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20230116.n.1.s390x.raw.xz
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230116.n.1.iso
Image: Server_KVM qcow2 ppc64le
Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20230116.n.1.ppc64le.qcow2
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20230116.n.1.s390x.tar.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20230116.n.1.s390x.tar.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20230116.n.1.s390x.qcow2
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20230116.n.1.iso

= DROPPED IMAGES =
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230114.n.0.iso
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230114.n.0.ppc64le.raw.xz
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230114.n.0.iso
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230114.n.0.ppc64le.qcow2

= ADDED PACKAGES =
Package: python-conda-package-streaming-0.7.0-3.fc38
Summary: Extract metadata from remote conda packages without downloading whole 
file
RPMs:python3-conda-package-streaming
Size:44.08 KiB

Package: python-nss-1.0.1^20210803hg9de14a6f77e2-6.fc38
Summary: Python bindings for Network Security Services (NSS)
RPMs:python3-nss
Size:1020.08 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  3Depict-0.0.22-15.fc38
Old package:  3Depict-0.0.22-13.fc38
Summary:  Valued 3D point cloud visualization and analysis
RPMs: 3Depict
Size: 21.57 MiB
Size change:  17.75 KiB
Changelog:
  * Mon Sep 12 2022 Scott Talbert  - 0.0.22-14
  - Rebuild with wxWidgets 3.2

  * Sat Jan 14 2023 Orion Poplawski  - 0.0.22-15
  - Rebuild with mathgl 8.0.1


Package:  64tass-1.58.2974-1.fc38
Old package:  64tass-1.57.2900-1.fc38
Summary:  6502 assembler
RPMs: 64tass
Size: 1.42 MiB
Size change:  -52.73 KiB
Changelog:
  * Sun Jan 15 2023 Dan Hor??k  - 1.58.2974-1
  - Update to 1.58.2974 (rhbz#2159962)


Package:  Carla-1:2.5.3-1.fc38
Old package:  Carla-1:2.5.2-1.fc38
Summary:  Audio plugin host
RPMs: Carla Carla-devel Carla-vst lv2-carla
Size: 54.53 MiB
Size change:  -258.03 KiB
Changelog:
  * Sun Jan 15 2023 Martin Gansser  - 1:2.5.3-1
  - Update to 2.5.3


Package:  EMBOSS-6.6.0-23.fc38
Old package:  EMBOSS-6.6.0-22.fc38
Summary:  The European Molecular Biology Open Software Suite
RPMs: EMBOSS EMBOSS-devel EMBOSS-libs libeplplot libeplplot-devel
Size: 302.72 MiB
Size change:  133.79 KiB
Changelog:
  * Sat Jan 14 2023 Orion Poplawski  - 6.6.0-23
  - Rebuild for libharu 2.4.3


Package:  InsightToolkit-4.13.3-12.fc38
Old package:  InsightToolkit-4.13.3-11.fc37
Summary:  Insight Toolkit library for medical image processing
RPMs: InsightToolkit InsightToolkit-devel InsightToolkit-doc 
InsightToolkit-examples InsightToolkit-vtk InsightToolkit-vtk-devel
Size: 71.81 MiB
Size change:  101.85 KiB
Changelog:
  * Sun Jan 15 2023 Orion Poplawski  - 4.13.3-12
  - Rebuild for vtk 9.2.5


Package:  Lmod-8.7.18-1.fc38
Old package:  Lmod-8.7.14-1.fc38
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.01 MiB
Size change:  2.84 KiB
Changelog:
  * Sun Jan 15 2023 Orion Poplawski  - 8.7.18-1
  - Update to 8.7.18


Package:  NetworkManager-1:1.41.8-1.fc38
Old package:  NetworkManager-1:1.41.7-1.fc38
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-initscripts-ifcfg-rh NetworkManager-initscripts-updown 
NetworkManager

[Bug 2157233] perl-Config-INI-Reader-Ordered-0.022 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Config-INI-Reader-Orde |perl-Config-INI-Reader-Orde
   |red-0.022-1.fc38|red-0.022-1.fc38
   |perl-Config-INI-Reader-Orde |perl-Config-INI-Reader-Orde
   |red-0.022-1.fc37|red-0.022-1.fc37
   ||perl-Config-INI-Reader-Orde
   ||red-0.022-1.fc36



--- Comment #7 from Fedora Update System  ---
FEDORA-2023-9ca015a237 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=2157233
___
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 2157213] perl-Perl-Critic-Tics-0.010 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Perl-Critic-Tics-0.010 |perl-Perl-Critic-Tics-0.010
   |-1.fc38 |-1.fc38
   |perl-Perl-Critic-Tics-0.010 |perl-Perl-Critic-Tics-0.010
   |-1.fc37 |-1.fc37
   ||perl-Perl-Critic-Tics-0.010
   ||-1.fc36



--- Comment #9 from Fedora Update System  ---
FEDORA-2023-78dd5d5d0a 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=2157213
___
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 2157222] perl-Number-Tolerant-1.710 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Number-Tolerant-1.710- |perl-Number-Tolerant-1.710-
   |1.fc38  |1.fc38
   |perl-Number-Tolerant-1.710- |perl-Number-Tolerant-1.710-
   |1.fc37  |1.fc37
   ||perl-Number-Tolerant-1.710-
   ||1.fc36



--- Comment #7 from Fedora Update System  ---
FEDORA-2023-dfce51ac98 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=2157222
___
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 2157223] perl-Pod-Elemental-PerlMunger-0.200007 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Pod-Elemental-PerlMung |perl-Pod-Elemental-PerlMung
   |er-0.27-1.fc38  |er-0.27-1.fc38
   |perl-Pod-Elemental-PerlMung |perl-Pod-Elemental-PerlMung
   |er-0.27-1.fc37  |er-0.27-1.fc37
   ||perl-Pod-Elemental-PerlMung
   ||er-0.27-1.fc36



--- Comment #7 from Fedora Update System  ---
FEDORA-2023-cda359a4bb 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=2157223
___
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

[rpms/perl-Coro] PR #3: Use _fortify_level

2023-01-16 Thread Michal Josef Špaček


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

Merged pull-request:

``
Use _fortify_level
``

https://src.fedoraproject.org/rpms/perl-Coro/pull-request/3
___
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 2157233] perl-Config-INI-Reader-Ordered-0.022 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version|perl-Config-INI-Reader-Orde |perl-Config-INI-Reader-Orde
   |red-0.022-1.fc38|red-0.022-1.fc38
   ||perl-Config-INI-Reader-Orde
   ||red-0.022-1.fc37
Last Closed||2023-01-17 01:35:56



--- Comment #6 from Fedora Update System  ---
FEDORA-2023-6c4c2d has been pushed to the Fedora 37 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=2157233
___
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 2157223] perl-Pod-Elemental-PerlMunger-0.200007 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Pod-Elemental-PerlMung |perl-Pod-Elemental-PerlMung
   |er-0.27-1.fc38  |er-0.27-1.fc38
   ||perl-Pod-Elemental-PerlMung
   ||er-0.27-1.fc37
 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2023-01-17 01:35:52



--- Comment #6 from Fedora Update System  ---
FEDORA-2023-16c89da0bf has been pushed to the Fedora 37 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=2157223
___
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 2157222] perl-Number-Tolerant-1.710 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Number-Tolerant-1.710- |perl-Number-Tolerant-1.710-
   |1.fc38  |1.fc38
   ||perl-Number-Tolerant-1.710-
   ||1.fc37
 Resolution|--- |ERRATA
Last Closed||2023-01-17 01:35:50



--- Comment #6 from Fedora Update System  ---
FEDORA-2023-e6ad5a4196 has been pushed to the Fedora 37 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=2157222
___
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 2157213] perl-Perl-Critic-Tics-0.010 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Perl-Critic-Tics-0.010 |perl-Perl-Critic-Tics-0.010
   |-1.fc38 |-1.fc38
   ||perl-Perl-Critic-Tics-0.010
   ||-1.fc37
 Resolution|--- |ERRATA
Last Closed||2023-01-17 01:35:47



--- Comment #8 from Fedora Update System  ---
FEDORA-2023-3aee38fae0 has been pushed to the Fedora 37 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=2157213
___
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

bodhi upgraded to 7.0.1

2023-01-16 Thread Kevin Fenzi

Hey folks, just a heads up that bodhi has been updated to 7.0.1 now. 

https://bodhi.fedoraproject.org

See: 
https://github.com/fedora-infra/bodhi/releases
for a full list of bugs fixed/enhancements. 

Note that this adds the concept of 'frozen' releases, which will: 
* show a warning / note for those releases to explain that it's frozen
  and updates will stay in testing unless cleared by QA as fixing a
  blocker/exception.
* allow releng to use the same automated push process, meaning that
  updates pushes will stay at the same time (00:14UTC) as always.

Along with many other bugfixes and enhancements.

Thanks to everyone who worked on it!

kevin


signature.asc
Description: PGP signature
___
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

bodhi upgraded to 7.0.1

2023-01-16 Thread Kevin Fenzi

Hey folks, just a heads up that bodhi has been updated to 7.0.1 now. 

https://bodhi.fedoraproject.org

See: 
https://github.com/fedora-infra/bodhi/releases
for a full list of bugs fixed/enhancements. 

Note that this adds the concept of 'frozen' releases, which will: 
* show a warning / note for those releases to explain that it's frozen
  and updates will stay in testing unless cleared by QA as fixing a
  blocker/exception.
* allow releng to use the same automated push process, meaning that
  updates pushes will stay at the same time (00:14UTC) as always.

Along with many other bugfixes and enhancements.

Thanks to everyone who worked on it!

kevin


signature.asc
Description: PGP signature
___
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

[Bug 2155545] Branch and build perl-Net-FTP-RetrHandle for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2023-01-17 00:38:25



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2023-2f51814cf7 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=2155545
___
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 2155539] Branch and build perl-Net-FTP-AutoReconnect for EPEL 9

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2023-01-17 00:38:22



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2023-161d4da366 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=2155539
___
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: z3 soname bump

2023-01-16 Thread Frantisek Zatloukal

On Mon, Jan 16, 2023 at 3:31 PM Lukas Zaoral  wrote:

> Hi,
> there is no need to wait for klee. Unfortunately, the package cannot be
> build
> in Rawhide at the moment since the project cannot be built with LLVM 15 and
> the llvm14 compatibility package cannot be used with clang 15 (and clang14
> is
> a library only package).
>

Yeah, I am facing the same issues with parts of the Intel stack
(intel-graphics-compiler, intel-compute-runtime). Upstream generally adds
support for newer versions of llvm, but with a bit of delay causing missing
OpenCl (and oneAPI in near future) support from newest Fedora releases.
I've always managed to push upstream/backport patches for newer llvm/clang
just a bit before another llvm stack rebase.

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
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: F39 proposal: Remove pam_console (System-Wide Change proposal)

2023-01-16 Thread Kevin Kofler via devel

> * As of today the module does nothing because one of the configuration
> files use to define the permissions (50-default.perms) is not
> installed in the distribution. Other packages may install their own
> configuration files to specify the permissions, but I haven't found
> any.

So basically, pam_console was obsoleted by systemd-logind eons ago. Not sure 
why we still ship it then. I guess it can just go away.

For the record, the one third-party RPM I maintain that used to use 
pam_console for device permissions (libticables2) switched away from 
pam_console back in 2009! (I had to rework the ACL handling several times 
between 2009 and 2012, with HAL and ConsoleKit coming and going, then it 
stabilized on udev rules, using systemd-logind internally.)

pam_console used to be a great selling point for Fedora over other 
distributions back when it was introduced, but by now, systemd-logind has 
completely subsumed its functionality.

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: z3 soname bump

2023-01-16 Thread Kevin Kofler via devel

Lukas Zaoral wrote:
> there is no need to wait for klee. Unfortunately, the package cannot be
> build in Rawhide at the moment since the project cannot be built with LLVM
> 15 and the llvm14 compatibility package cannot be used with clang 15 (and
> clang14 is a library only package).

Looks like we need better compat packages then, in this case a clang14 
package that actually ships a clang14 binary. It has been done for GCC in 
the past, at least.

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

2023-01-16 Thread Arthur Bols


On 17/03/2022 10:49, Matyáš Kroupa wrote:

Hi,
I use wine and steam (and some libraries which are required to run them) with 
total of 254 i686 packages.
Matyáš

I'm also using them for wine and steam.

--
Arthur Bols
fas/irc: principis
___
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: List of long term FTBFS packages to be retired in February

2023-01-16 Thread Petr Šabata

On Wed, Jan 11, 2023 at 1:59 PM Miro Hrončok  wrote:
>
> Dear maintainers.
>
> Based on the current fail to build from source policy, the following packages
> should be retired from Fedora 38 approximately one week before branching.
>
> tabbed   psabata

Okay, finally fixed tabbed tonight (#2047035).
P
___
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: FESCo wants to know what you use i686 packages for


On 16. 03. 22 15:15, Miro Hrončok wrote:

On 16. 03. 22 14:54, David Cantrell wrote:

Hi,

Our most recent FESCo meeting involved discussing the proposal to drop i686
builds of jdk8,11,17 from Fedora 37 onward.  The topic quickly changed to the
larger question of "what do people use i686 packages for?"

Rather than guess, we wanted to ask the community what you use i686 packages
for in Fedora.  There are no wrong answers here.  We are seeking information.

Why?  Since the removal of the i686 kernel in Fedora, we want to reduce the
number of i686 packages provided in the repo.  As time marches on, the ability
to build a lot of things for i686 becomes unrealistic or even impossible.
Remember it goes beyond providing builds...providing support, bug fixes, and
security fixes for those packages too.  Maybe some things using i686 packages
now can move to x86_64 packages.  We do not know yet, but a goal is to figure
out what packages, if anything, can drop their i686 builds.

NOTE: Nothing is changing now.  We are in an information gathering phase.
   

If you use i686 packages for something now, please respond to this thread.


  - I use i686 packages to build my i686 packages.
  - I (randomly) use i686 packages to build my noarch packages.
  - I use nosync.i686 to build my i686 packages in mock.
  - The printer driver for my Brother printer is provided as i386 RPM, but I 
don't know if I need that, as it doesn't work currently anyway :(


I made it work. I installed cups-libs.i686 so either that on or something in 
the dep chain is needed.


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

[Bug 2161420] New: perl-Class-Method-Modifiers-2.14 is available

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

Bug ID: 2161420
   Summary: perl-Class-Method-Modifiers-2.14 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Class-Method-Modifiers
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, mspa...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 2.14
Upstream release that is considered latest: 2.14
Current version/release in rawhide: 2.13-13.fc37
URL: http://search.cpan.org/dist/Class-Method-Modifiers

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161420
___
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: Yet another unwinding approach

> Could the vDSO do the unwinding?

The vDSO is just userspace code that happens to be provided by the kernel, so, 
sure, a function in vDSO *could* unwind. But why would it? What would be the 
advantage of doing that over putting the unwinding in libc? To change the vDSO, 
you have to change the kernel, so the vDSO is more suited for things coupled to 
the kernel, like a fast clock_gettime implementation. 

Also, libc can be paged out, and the vDSO can't be. It's hard to imagine a 
DWARF unwinder entirely in vDSO and resident in memory all the time being the 
optimal system design choice. Code in libc is paged into memory on demand.

Putting the unwinder in libc seems more natural, especially since libc is a 
natural coordination point for "plugging in" runtime-specific unwinders, which 
is one of the advantages of a usermode-unwinding scheme. I don't think there's 
a lot of precedent for the vDSO providing registration and plugin mechanisms.

Besides: since libc already reserves a signal for itself (SIGRTMIN), using the 
same signal for kernel-requested unwinding (distinguished by si_code, one would 
imagine) wouldn't break any new code.
___
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: Use cases for 'fedpkg scratch-build'

2023-01-16 Thread Otto Liljalaakso


Miro Hrončok kirjoitti 16.1.2023 klo 16.05:

On 16. 01. 23 14:57, Richard Shaw wrote:


Since `fedpkg scratch-build` bombs out with an error if you've made 
local changes I propose a slight modification:


If no changes are made then it does a normal scratch build for the 
"does this still build / not build" 1% use case


If there are local changes it automatically uploads an SRPM for the 
99% use case.


I love this.

$ fedpkg scratchbuild  / $ fedpkg build --scratch
Uncommitted changes found, uploading SRPM...


I like this modified proposal, too. It achieves what I wanted to do, and 
(unlike my original idea) does not break the "1% case" for 'fedpkg 
scratch-build'. I will try to create a pull request for this. More than 
a single line needs to change, but it should not be too difficult.

___
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: Use cases for 'fedpkg scratch-build'

2023-01-16 Thread Otto Liljalaakso


Michael J Gruber kirjoitti 16.1.2023 klo 14.46:


`--srpm` is named misleadingly, by the way, because it names the "transport of the 
source" when indeed it implies a potentially different source version. That's 
another reasons why removing it (the name) and making it the mode of operation for 
`scratch-build` makes sense:
- `scratch-build` is about doing things from (your) scratch. That involves an 
srpm for technical reasons.
- `build` is about building something pushed, and `--scratch` only changes 
where it is build.


Actually, --srpm is named like that because you can also do 'fedpkg 
scratch-build --srpm path/to/my/src.rpm', which does what you would 
expect. Generating the srpm from the local working directory is just the 
default when no path is given.



Now I'm wondering: Does `fedpkg build --srpm` imply `--scratch`? I would hope so, and I'm 
really wondering whether any srpm-mode should belong to that command at all. It's much 
clearer if `build` deals with sources "in the buildsystem" only, and 
{copr,scratch,local,mock}-build with the local sources. (Yes, `local` and `mockbuild` 
could have helpful aliases, too.)


I tried it. 'fedpkg build --srpm' is not a scratch build. However, Koji 
does not accept such build requests: "ActionNotAllowed: policy violation 
(build_from_srpm)".

___
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: Yet another unwinding approach

2023-01-16 Thread Demi Marie Obenour

On 1/16/23 15:54, Daniel Colascione wrote:
>> On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione > wrote:
>>
>> This sounds great, but how is it going to get made? 
> Someone has to do it.  I've been thinking about adding this mechanism for a 
> few years, but haven't had time so far. I suppose the first step would be 
> raising the subject on libc-alpha and LKML. Both places (especially the 
> former) tend to be conservative, so it'd be prudent to settle in for a long 
> debate.
> 
>> And is the kernel amenable to this in the first place?
> I don't think anyone's asked. I don't see a reason (at least a reason based 
> on the technical merits) for the kernel to be opposed, but the Linux world 
> isn't known for the tight coordination between the kernel, libc, and managed 
> runtimes that this mechanism would require.
> 
> I'm more worried about libc, to be honest. The last time [1] I proposed 
> improvements involving signal handling, libc-alpha's response was essentially 
> "No, absolutely not, we're not going to touch a thing related to signals 
> because nobody should be using signals for any purpose whatsoever". I don't 
> think this is a terribly realistic perspective on the part of libc-alpha, 
> especially given how often signals are, in fact, used productively in the 
> real world. I hope that they might be a little more moderate when it came to 
> unwinding.

Could the vDSO do the unwinding?

> [1] https://sourceware.org/legacy-ml/libc-alpha/2018-03/msg00214.html

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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: valgrind on Fedora

2023-01-16 Thread Gordon Messmer


On 2023-01-16 05:24, Kalev Lember wrote:
On Mon, Jan 16, 2023 at 2:21 PM Richard W.M. Jones  
wrote:


Also make use of suppressions:

https://gitlab.com/nbdkit/nbdkit/-/tree/master/valgrind


Also, to add to this, glib2 has a suppressions file you can use to cut 
down on the false positives: /usr/share/glib-2.0/valgrind/glib.supp



Thanks.  I've looked at the suppressions file for glib, and while I do 
get a couple of loss records from valgrind that look like they happen in 
glib, neither of them look like they match one of the existing 
suppressions.  :)


That leaves one loss record that's printed over a hundred times, which I 
find very confusing 
(https://sourceforge.net/p/valgrind/mailman/message/37763877/), and two 
more that might be leaks in sqlite3 that I still need to look into.
___
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: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python


On 16. 01. 23 21:37, Fabio Valentini wrote:

Isn't the problem here that building Python extensions needs to work
correctly in two - possibly conflicting - scenarios:

- in RPM packages, where using system compiler flags is a MUST


Yes and packages get *all* the Fedora RPM flags that way via:

 - https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck
 - %py3_build, %pyproject_wheel, etc.


- when user installs Python packages manually, for example with pip in
a venv, where using system compiler flags isn't necessary (or
necessarily a good idea)


This is the case this thread is about.


Just dropping everything but `-fexceptions` would certainly violate
Packaging Guidelines (i.e. packages not getting built with default
compiler and hardening flags) in the first scenario, wouldn't it?


Dropping it from %{extension_*flags} would not change any Fedora package except 
such packages that %undefine _auto_set_build_flags and don't use macros to 
build stuff but invoke the build manually somehow -- such packages should 
already be recognizable by not having annobin and package ELF notes.


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

Re: Use cases for 'fedpkg scratch-build'

2023-01-16 Thread Otto Liljalaakso


Vít Ondruch kirjoitti 16.1.2023 klo 16.50:

I don't oppose to change of the defaults.

However, I am also using `fedpkg scratch-build --srpm some.rpm`. So how 
would the proposed change influence this command?


I do not intend to change that behavior in any way.
___
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: Yet another unwinding approach

> On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione  wrote:
> 
> This sounds great, but how is it going to get made? 

Someone has to do it. :-) I've been thinking about adding this mechanism for a 
few years, but haven't had time so far. I suppose the first step would be 
raising the subject on libc-alpha and LKML. Both places (especially the former) 
tend to be conservative, so it'd be prudent to settle in for a long debate.

> And is the kernel amenable to this in the first place?

I don't think anyone's asked. I don't see a reason (at least a reason based on 
the technical merits) for the kernel to be opposed, but the Linux world isn't 
known for the tight coordination between the kernel, libc, and managed runtimes 
that this mechanism would require.

I'm more worried about libc, to be honest. The last time [1] I proposed 
improvements involving signal handling, libc-alpha's response was essentially 
"No, absolutely not, we're not going to touch a thing related to signals 
because nobody should be using signals for any purpose whatsoever". I don't 
think this is a terribly realistic perspective on the part of libc-alpha, 
especially given how often signals are, in fact, used productively in the real 
world. I hope that they might be a little more moderate when it came to 
unwinding.

[1] https://sourceware.org/legacy-ml/libc-alpha/2018-03/msg00214.html
___
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: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python

2023-01-16 Thread Fabio Valentini

On Mon, Jan 16, 2023 at 9:01 PM Jakub Jelinek  wrote:
>
> On Mon, Jan 16, 2023 at 08:42:32PM +0100, Miro Hrončok wrote:
> > On 16. 01. 23 20:30, Siddhesh Poyarekar wrote:
> > > If it is for distribution packages then I reckon the flags should be
> > > as close as possible for the mere reason of consistency within the
> > > distribution.
> >
> > Nope, the individual packages with extension modules all¹ use the
> > %{build_cflags} flags by default.
> >
> > ¹: Technically they are required to and it is really hard not to do that 
> > noways.
> >
> > > If they're used for custom built modules (e.g. through
> > > a tool that python auto-generates to build modules), then a very small
> > > subset of the above flags would be necessary to retain binary
> > > compatibility; you should be able to remove most of it.
> >
> > That is what I thought. Thank you.
>
> Options like -m64/-m32 are ABI changing (but in %{optflags} these days
> mostly uselessly because we don't usually cross-compile and gcc defaults to
> those), -fsigned-char/-funsigned-char (I see it in redhat-rpm-config but
> for armv3l/armv4b/armv4l which we don't build - in the past it was used on
> more platforms) would be ABI changing, again on arm the various
> -march=, -mfpu=, -mfloat-abi=, -mabi= options (but note that e.g. on most
> other arches the -march= options aren't ABI changing, one just needs hw with
> all the ISAs required by the built code), -fexceptions could be considered
> partly ABI changing (at least say pthread_cancel through some objects
> built with -fexceptions and others without that or with -fno-exceptions
> will not destruct everything that should be after reaching frames without
> it or similarly throwing C++ exceptions won't work well), so I'd suggest
> to keep that one in.  -mlong-double-{64,128} would be ABI changing, but
> we just use compiler's default.  -mabi={ibm,ieee}longdouble are ABI changing
> on ppc64le too, but again we use the compiler defaults.
> If you look at gcc documentation, many options are marked as ABI changing,
> but I don't see them used in our %{optflags}...
>
> So, when talking about options actually in use currently in f36/f37/f38 on
> Fedora supported arches, I think -fexceptions is the only one I'd list.

Isn't the problem here that building Python extensions needs to work
correctly in two - possibly conflicting - scenarios:

- in RPM packages, where using system compiler flags is a MUST
- when user installs Python packages manually, for example with pip in
a venv, where using system compiler flags isn't necessary (or
necessarily a good idea)

Just dropping everything but `-fexceptions` would certainly violate
Packaging Guidelines (i.e. packages not getting built with default
compiler and hardening flags) in the first scenario, wouldn't it?

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

Re: Yet another unwinding approach

2023-01-16 Thread Neal Gompa

On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione  wrote:
>
> Frame pointers also have the disadvantage of working only with AOT-compiled 
> languages for which a trace analysis tool can associate an instruction 
> pointer with a semantically-relevant bit of code. If you try to use frame 
> pointers to profile a Python program, all you're going to get is a profile of 
> the interpreter. It seems like the debate is between those who want 
> observability (via frame pointers) and those who want the performance 
> benefits of -fomit-frame-pointer.
>
> There's a third way.
>
> See, both pro-FP and anti-FP camps think that it's the kernel that has to do 
> the unwinding unless we copy whole stacks into traces. Why should that be? As 
> mentioned in [1], instead of finding a way to have the kernel unwind user 
> programs, we can create a protocol through which the kernel can ask usermode 
> to unwind itself. It could work like this:
>
> 1) backtrace requested in the kernel (e.g. to a perf counter overflow)
>
> 2) kernel unwinds itself to the userspace boundary the usual way
>
> 3) kernel forms a nonce (e.g. by incrementing a 64-bit counter)
>
> 4) kernel logs a stack trace the usual way (e.g. to the ftrace ring buffer), 
> but with the final frame referring to the nonce created in the previous step
>
> 5) kernel queues a signal (one userspace has explicitly opted into via a new 
> prctl()); the siginfo_t structure encodes (e.g. via si_status and si_value) 
> the nonce
>
> 6) kernel eventually returns to userspace; queued signal handler gains control
>
> 7) signal handler unwinds the calling thread however it wants (and can sleep 
> and take page faults if needed)
>
> 8) signal handler logs the result of its unwind, along with the nonce, to the 
> system log (e.g. via a new system call, a sysfs write, an io_uring 
> submission, etc.)
>
> Post-processing tools can associate kernel stacks with user stacks tagged 
> with the corresponding nonces and reconstitute the full stacks in effect at 
> the time of each logged event.
>
> We can avoid duplicating unwindgs too: at step #3, if the kernel finds that 
> the current thread already has an unwind pending, it can uses the 
> already-pending nonce instead of making a new one and queuing a signal: many 
> kernel stacks can end with the same user stack "tail".
>
> One nice property of this scheme is that the userspace unwinding isn't 
> limited to native code. Libc could arbitrate unwinding across an arbitrary 
> number of managed runtime environments in the context of a single process: 
> the system could be smart enough to know that instead of unwinding through, 
> e.g. Python interpreter frames, the unwinder (which is normal userspace code, 
> pluggable via DSO!) could traverse and log *Python* stack frames instead, 
> with meaningful function names. And if you happened to have, say, a 
> JavaScript runtime in the same process, both JavaScript and Python could 
> participate in the semantic unwinding process.
>
> A pluggable userspace unwind mechanism would have zero cost in the case that 
> we're not recording stack frames. On top of that, a pluggable userspace 
> unwinder *could* be written to traverse frame pointers just as the kernel 
> unwinder does today, if userspace thinks that's the best option. Without 
> breaking kernel ABI, that userspace unwinder could use DWARF, or ORC, or any 
> other userspace unwinding approach. It's future-proof.
>
> In other words, choice between frame pointers and no frame pointers is a 
> false dichotomy. There's a better approach. The Linux ecosystem as a whole 
> would be better off building something like the pluggable userspace 
> asynchronous unwinding infrastructure described above.
>
> [1] 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/646XXHGEGOKO465LQKWCPPPAZBSW5NWO/

This sounds great, but how is it going to get made? And is the kernel
amenable to this in the first place?



-- 
真実はいつも一つ！/ 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: -fno-omit-frame-pointer does not work as advertised

2023-01-16 Thread Demi Marie Obenour

On 1/16/23 08:40, Florian Weimer wrote:
> * Daniel Alley:
> 
>> What has happened is that because -O2 optimized away all of the stack
>> access for the function, so it uses no space on the stack, so there is
>> no stack frame separate from the caller's.
>>
>> It is unlikely that the critical bottleneck of any applications will
>> be on such a function.
> 
> Is it?  Plenty of math functions and cryptographic primitives are like
> that.  Anything that makes an inline system call, too.  Maybe you can
> infer from the caller's caller where the time is spent in these cases.
> People certainly seem to be concerned about this gap because they
> included -mno-omit-leaf-frame-pointer in the build flags.
> 
> This is something that an upstream/ABI discussion could cover, with some
> sort of protocol that ensures the toolchain produces something the
> intended tools can consume.  For example, there could be a rule that
> only frames up to a certain size may lack a frame pointer, so that a
> fixed-size copy from the top of the stack can recover the caller address
> by looking at the DWARF unwinding data (out of context, for that frame
> alone).  Or it could be spelt out that LBR has to be used to recover the
> calling frame.  This isn't really something that Fedora can implement in
> a downstream change, though.
What about the new SFrame unwind info?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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

Yet another unwinding approach

Frame pointers also have the disadvantage of working only with AOT-compiled
languages for which a trace analysis tool can associate an instruction pointer
with a semantically-relevant bit of code. If you try to use frame pointers to
profile a Python program, all you're going to get is a profile of the
interpreter. It seems like the debate is between those who want observability
(via frame pointers) and those who want the performance benefits of
-fomit-frame-pointer.

There's a third way.

See, both pro-FP and anti-FP camps think that it's the kernel that has to do
the unwinding unless we copy whole stacks into traces. Why should that be? As
mentioned in [1], instead of finding a way to have the kernel unwind user
programs, we can create a protocol through which the kernel can ask usermode to
unwind itself. It could work like this:

1) backtrace requested in the kernel (e.g. to a perf counter overflow)

2) kernel unwinds itself to the userspace boundary the usual way

3) kernel forms a nonce (e.g. by incrementing a 64-bit counter)

4) kernel logs a stack trace the usual way (e.g. to the ftrace ring buffer),
but with the final frame referring to the nonce created in the previous step

5) kernel queues a signal (one userspace has explicitly opted into via a new
prctl()); the siginfo_t structure encodes (e.g. via si_status and si_value) the
nonce

6) kernel eventually returns to userspace; queued signal handler gains control

7) signal handler unwinds the calling thread however it wants (and can sleep
and take page faults if needed)

8) signal handler logs the result of its unwind, along with the nonce, to the
system log (e.g. via a new system call, a sysfs write, an io_uring submission,
etc.)

Post-processing tools can associate kernel stacks with user stacks tagged with
the corresponding nonces and reconstitute the full stacks in effect at the time
of each logged event.

We can avoid duplicating unwindgs too: at step #3, if the kernel finds that the
current thread already has an unwind pending, it can uses the already-pending
nonce instead of making a new one and queuing a signal: many kernel stacks can
end with the same user stack "tail".

One nice property of this scheme is that the userspace unwinding isn't limited
to native code. Libc could arbitrate unwinding across an arbitrary number of
managed runtime environments in the context of a single process: the system
could be smart enough to know that instead of unwinding through, e.g. Python
interpreter frames, the unwinder (which is normal userspace code, pluggable via
DSO!) could traverse and log *Python* stack frames instead, with meaningful
function names. And if you happened to have, say, a JavaScript runtime in the
same process, both JavaScript and Python could participate in the semantic
unwinding process.

A pluggable userspace unwind mechanism would have zero cost in the case that
we're not recording stack frames. On top of that, a pluggable userspace
unwinder *could* be written to traverse frame pointers just as the kernel
unwinder does today, if userspace thinks that's the best option. Without
breaking kernel ABI, that userspace unwinder could use DWARF, or ORC, or any
other userspace unwinding approach. It's future-proof.

In other words, choice between frame pointers and no frame pointers is a false
dichotomy. There's a better approach. The Linux ecosystem as a whole would be
better off building something like the pluggable userspace asynchronous
unwinding infrastructure described above.

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

___
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: Do we have alternatives to alternatives?

2023-01-16 Thread Neal Gompa

On Mon, Jan 16, 2023 at 11:56 AM Vít Ondruch  wrote:
>
>
> Dne 16. 01. 23 v 12:34 Petr Menšík napsal(a):
> > Hi!
> >
> > I heard (read) objections to any alternatives macros usage often. But
> > unless I am mistaken, we do not have any user (enough) friendly way to
> > support similar functionality tools with just minor differences.
>
>
> I have not tried this:
>
> https://github.com/openSUSE/libalternatives
>
> But I like the idea.
>

I packaged it a while ago: https://copr.fedorainfracloud.org/coprs/ngompa/alts/

I didn't bring it into Fedora yet, though.



-- 
真実はいつも一つ！/ 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

F39 proposal: Remove pam_console (System-Wide Change proposal)

2023-01-16 Thread Ben Cotton

https://fedoraproject.org/wiki/Changes/RemovePamConsole

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

== Summary ==
Remove pam_console as it is not enabled by default, can be replaced by
systemd and has security issues.

== Owner ==
* Name: [[User:ipedrosa| Iker Pedrosa]]
* Email: ipedr...@redhat.com


== Detailed Description ==
pam_console give users at the physical console additional capabilities
when authenticating, and removes those capabilities when the user logs
out. The module changes the permissions and ownership of files and
devices.

pam_console has some limitations and flaws:
* Only one user can have those additional capabilities at the same
time (no multi-seat)
* Potential security problems of device file ownership if the PAM
conversation ending isn't executed
* Remove ACL and call revoke() on device nodes for
fast-user-switching. This is to prevent the user of the inactive
session B spying on the user of the active session A using webcam,
sound cards, etc.
* As of today the module does nothing because one of the configuration
files use to define the permissions (50-default.perms) is not
installed in the distribution. Other packages may install their own
configuration files to specify the permissions, but I haven't found
any.

These additional capabilities that pam_console provides are useful to
simplify the work for console users. Usually, the permissions are set
for devices like the CD/DVD reader, or the disk drives. This
functionality is still useful today, and it should be managed with
systemd-logind, rather than with a PAM module. This systemd service
takes care of user sessions, multi-seat management, device access
management... This would increase the security level of the system,
and enable multi-seat for the file and device permissions. For more
information on systemd-logind implementation refer to the
documentation on how to
[https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/
Write Display Managers] and
[https://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments/
Write Desktop Environments].

In 2007 there was a [[Releases/FeatureRemovePAMConsole|System-Wide
Change]] proposal to remove pam_console, but it wasn't finished. My
plan is to continue that work and remove the pam_console module.


== Feedback ==


== Benefit to Fedora ==
By removing pam_console and moving to systemd-logind the distribution
would benefit from the multi-seat functionality and higher security
levels.

== Scope ==
* Proposal owners:
# Provide PRs to remove pam_console from the PAM stack of the
identified software packages (see Dependencies).
# Remove pam_console from [https://pagure.io/pam-redhat pam-redhat]
project and rebuild the PAM package without it.

* Other developers:
# Identified software package maintainers should review and merge the
pam_console removal PRs.

* Release engineering: [https://pagure.io/releng/issue/11223 #11223]

* Policies and guidelines: N/A

* Trademark approval: N/A

* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
No impact is expected.


== How To Test ==
No special hardware or configuration is required to test this change.
Once the change is in place, check that the pam_console isn't
installed in your system (default location:
/lib64/security/pam_console.so) and do a user authentication (i.e.
graphical interface, su, ssh, and whatever else comes to your mind).


== User Experience ==
Users won't experience any change.

== Dependencies ==
This change depends on other packages removing pam_console from their
PAM stack. I have identified five packages and I have opened a
bugzilla for all of them:
* xorg-x11-server - https://bugzilla.redhat.com/show_bug.cgi?id=1822209
* lxdm - https://bugzilla.redhat.com/show_bug.cgi?id=187
* xorg-x11-xdm - https://bugzilla.redhat.com/show_bug.cgi?id=185
* slim - https://bugzilla.redhat.com/show_bug.cgi?id=189
* gdm - https://bugzilla.redhat.com/show_bug.cgi?id=188

From the above list only the first item is a blocker as it requires
pam_console to succeed in the authentication. In all other cases it is
optional, so not removing the module from their PAM stack will only
cause a message printed in the security file.


== Contingency Plan ==

* Contingency mechanism: Postpone to the next release.
* Contingency deadline: Beta freeze.
* Blocks release? No.


== Documentation ==
No documentation.


== Release Notes ==
No need to update the release notes for this change.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:

F38 proposal: cups-filters 2.0b (Self-Contained Change proposal)

2023-01-16 Thread Ben Cotton

https://fedoraproject.org/wiki/Changes/Cups-filters2.0b

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

== Summary ==
The `cups-filters` project has been split into five projects in the
new major version 2.0b - `cups-filters`, `libcupsfilters`, `libppd`,
`braille-printer-app` and `cups-browsed` - the new projects will be
packaged and `cups-filters` package will be rebased to version 2.0b
once the other projects are available in rawhide. All projects are now
united on Apache Software License 2.0.

== Owner ==
* Name: [[User:Zdohnal| Zdenek Dohnal]]
* Email: zdoh...@redhat.com


== Detailed Description ==
cups-filters 1.x series contain several different sets of binaries:

* filters, which are used during printing, such as `pdftopdf`,
`imagetopdf`, `bannertopdf`,
* `cups-browsed` daemon, which automatically installs remote printers
(remote print queues shared by mDNS or by CUPS broadcast, remote print
queue from print server outside of local network via `BrowsePoll` or
local devices) locally and provides clusters for load balancing
functionality,
* `driverless` and `driverless-fax` utilities, which generate a PPD
file based on IPP response from the device,
* printing backends as `beh` and `implicitclass`,
* printer drivers such as generic PDF driver or virual braille driver,
* shared library `libcupsfilters` defining functions used by cups-filters tools.

Major version 2.0 follows CUPS 3.0's example - the project is divided
into several modules based on its functionality. The new projects are:

* [https://github.com/OpenPrinting/libcupsfilters libcupsfilters]-
shared library, which now implements filter functions for filtering,
* [https://github.com/OpenPrinting/libppd libppd] - shared library
copied from CUPS 2.x for retrospective PPD driver support in printer
applications - !do not use it for new projects!,
* [https://github.com/OpenPrinting/cups-browsed cups-browsed] -
cups-browsed daemon,
* [https://github.com/OpenPrinting/cups-filters cups-filters] - filter
and backend binaries useful for CUPS 2.x,
* [https://github.com/OpenPrinting/braille-printer-app
braille-printer-app] - printer driver for Braille embosser.

All of them have to be packaged to ensure the same set of
functionality as in the past. The `libcupsfilters 2.x` library
implements functions required for retro-fitting printer applications,
which are projects substituting classic printer driver in cases where
driverless protocols can't be applied (older devices which are not
capable of using driverless protocols) or where driverless protocols
and their options don't suffice (devices with specific printing
options). The printer applications are currently available only as
Snaps. Once `libcupsfilters` and `libppd` are shipped in Fedora,
printer applications developed by OpenPrinting can be packaged into
Fedora as RPMs.

`libcupsfilters` requires `ghostscript` 10.00.0, which currently is
not shipped in Fedora, so a prerequisite for new `cups-filters` is
rebase of `ghostscript`.

The project's split has an additional side effect - `cups-browsed`
won't be brought together with `cups` by default. I propose to add it
into `printing` group in comps to make sure the package is installed
in specific environments, but doesn't depend on `cups`.

== Feedback ==


== Benefit to Fedora ==
The newest cups-filters version will be shipped in Fedora, providing
shared libraries `libcupsfilters` and `libppd` needed by printer
applications. Printer applications are required for supporting older
or specific devices, which can't use drivereless standards, in a
system where CUPS does not support classic printer drivers (planned
for CUPS 3.x).

== Scope ==
* Proposal owners:
The owner will package the new projects, rebase the current
`cups-filters` package and create a pull request for adding
`cups-browsed` into `printing` comps group. He will add the proper
`Conflicts:`, `Requires:` and `Obsoletes:` tags to ensure a clean
upgrade path.

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


== Upgrade/compatibility impact ==
RPM tags will be used in .SPEC file to ensure the clean upgrade path.

== How To Test ==
Once all projects are packaged and waiting on review, there will be
available in the
[https://copr.fedorainfracloud.org/coprs/zdohnal/cups-filters-2.0-repo/
COPR] repo.

Regarding testing, a printer and a print server (another machine
sharing the printer, ideally one in local network, second in different
network) is required.

=== Filters testing ===
* print different file formats to your existing printer - text file
(.txt), PDF, PostScript, PCL, image (.png/.jpeg)
* check printout if it is okay

=== cups-browsed testing ===

Re: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python

2023-01-16 Thread Jakub Jelinek

On Mon, Jan 16, 2023 at 08:42:32PM +0100, Miro Hrončok wrote:
> On 16. 01. 23 20:30, Siddhesh Poyarekar wrote:
> > If it is for distribution packages then I reckon the flags should be
> > as close as possible for the mere reason of consistency within the
> > distribution.
> 
> Nope, the individual packages with extension modules all¹ use the
> %{build_cflags} flags by default.
> 
> ¹: Technically they are required to and it is really hard not to do that 
> noways.
> 
> > If they're used for custom built modules (e.g. through
> > a tool that python auto-generates to build modules), then a very small
> > subset of the above flags would be necessary to retain binary
> > compatibility; you should be able to remove most of it.
> 
> That is what I thought. Thank you.

Options like -m64/-m32 are ABI changing (but in %{optflags} these days
mostly uselessly because we don't usually cross-compile and gcc defaults to
those), -fsigned-char/-funsigned-char (I see it in redhat-rpm-config but
for armv3l/armv4b/armv4l which we don't build - in the past it was used on
more platforms) would be ABI changing, again on arm the various
-march=, -mfpu=, -mfloat-abi=, -mabi= options (but note that e.g. on most
other arches the -march= options aren't ABI changing, one just needs hw with
all the ISAs required by the built code), -fexceptions could be considered
partly ABI changing (at least say pthread_cancel through some objects
built with -fexceptions and others without that or with -fno-exceptions 
will not destruct everything that should be after reaching frames without
it or similarly throwing C++ exceptions won't work well), so I'd suggest
to keep that one in.  -mlong-double-{64,128} would be ABI changing, but
we just use compiler's default.  -mabi={ibm,ieee}longdouble are ABI changing
on ppc64le too, but again we use the compiler defaults.
If you look at gcc documentation, many options are marked as ABI changing,
but I don't see them used in our %{optflags}...

So, when talking about options actually in use currently in f36/f37/f38 on
Fedora supported arches, I think -fexceptions is the only one I'd list.

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: Orphaned packages looking for new maintainers


On 16. 01. 23 20:53, Simo Sorce wrote:

On Fri, 2023-01-13 at 12:28 +0100, Miro Hrončok wrote:

On 13. 01. 23 0:35, Chuck Anderson wrote:

For receiving/filtering emails, you can filter on the List-Id: header
rather than the To: or Cc: headers.  In that way you can differentiate
between normal list distribution and Bcc:.  If there is no List-Id:
header, the mail can be directed to your Inbox rather than the mailing
list folder (if that is how you filter your messages) or otherwise
flag it as important, etc.


I am afraid this does not work properly with gmail.
Gmail will receive two emails with identical content but different headers (one
with List-Id and one without) and it will "consolidate" the two email into one
by randomly dropping one of them entirely.


Even if gmail drops the headers, they know at time of receive what is
what (bad magic) so if you use google's own filtering you can tell it
to file messages sent to "this list" under a specific tag, you can also
tell it to keep in inbox if you are explicitly in CC or TO (potentially
requires two separate filters to do that selectively).


But can you tell it to keep it in the Inbox if you are Bcc'ed? Because I have 
not figured out how to do that and apparently many packagers who are Bcc'ed on 
my emails to the list don't know they were Bcc'ed.



It sucks, but it can be worked with to some degree...

If you do your own filtering after fetching emails  maybe you
should consider a better hosting for your emails...


I use gmail filtering and I cannot change how Red Hat hosts my email.

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

Re: Orphaned packages looking for new maintainers

2023-01-16 Thread Simo Sorce

On Fri, 2023-01-13 at 12:28 +0100, Miro Hrončok wrote:
> On 13. 01. 23 0:35, Chuck Anderson wrote:
> > For receiving/filtering emails, you can filter on the List-Id: header
> > rather than the To: or Cc: headers.  In that way you can differentiate
> > between normal list distribution and Bcc:.  If there is no List-Id:
> > header, the mail can be directed to your Inbox rather than the mailing
> > list folder (if that is how you filter your messages) or otherwise
> > flag it as important, etc.
> 
> I am afraid this does not work properly with gmail.
> Gmail will receive two emails with identical content but different headers 
> (one 
> with List-Id and one without) and it will "consolidate" the two email into 
> one 
> by randomly dropping one of them entirely.

Even if gmail drops the headers, they know at time of receive what is
what (bad magic) so if you use google's own filtering you can tell it
to file messages sent to "this list" under a specific tag, you can also
tell it to keep in inbox if you are explicitly in CC or TO (potentially
requires two separate filters to do that selectively).

It sucks, but it can be worked with to some degree...

If you do your own filtering after fetching emails  maybe you
should consider a better hosting for your emails...


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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
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: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python


On 16. 01. 23 20:30, Siddhesh Poyarekar wrote:

If it is for distribution packages then I reckon the flags should be
as close as possible for the mere reason of consistency within the
distribution.


Nope, the individual packages with extension modules all¹ use the 
%{build_cflags} flags by default.


¹: Technically they are required to and it is really hard not to do that noways.


If they're used for custom built modules (e.g. through
a tool that python auto-generates to build modules), then a very small
subset of the above flags would be necessary to retain binary
compatibility; you should be able to remove most of it.


That is what I thought. Thank you.

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

Re: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python

On Mon, Jan 16, 2023 at 1:40 PM Miro Hrončok  wrote:
>
> Hello folks,
> this recent Fedora change:
>
> https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
>
> Made me think:
>
> Which compiler flags we need to store in Python and which can we omit?
>
> In order to make Python extension modules binary compatible with Python, 
> Python
> saves the compiler flags at compile-time and reuses them when building
> extension modules.
>
> Historically, we had troubles with this approach because some of the flags are
> unusable without redhat-rpm-config, annobin etc.
>
> As a result, there are now 2 compiler flags macros available for RPM:
> %{build_cflags} and %{extension_cflags} (same for ldflags etc.).
> While Python itself is built with %{build_cflags}, it saves 
> %{extension_cflags}
> in sysconfig.
>
> The flags differ like this:
>
> $ diff -u <(rpm --eval '%build_cflags' | tr ' ' '\n') <(rpm --eval
> '%extension_cflags' | tr ' ' '\n') | grep ^-
> --flto=auto
> --ffat-lto-objects
> --specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> --specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>
> $ diff -u <(rpm --eval '%build_ldflags' | tr ' ' '\n') <(rpm --eval
> '%extension_ldflags' | tr ' ' '\n') | grep ^-
> --specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> --specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>
> (There are also some other differences wrt
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects but
> those are apparently harder to get from outside of a real build.)
>
> The current set of flags from Python can be obtained by:
>
>  >>> sysconfig.get_config_var('CFLAGS')
> '-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG  -O2  -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security -U_FORTIFY_SOURCE
> -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -fstack-protector-strong   -m64  -mtune=generic -fasynchronous-unwind-tables
> -fstack-clash-protection -fcf-protection   -D_GNU_SOURCE -fPIC -fwrapv -O2
> -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3
> -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong   -m64  -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -D_GNU_SOURCE -fPIC -fwrapv  -O2  -fexceptions -g -grecord-gcc-switches -pipe
> -Wall -Werror=format-security -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE
> -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong
> -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection   -D_GNU_SOURCE -fPIC -fwrapv'
>  >>> sysconfig.get_config_var('LDFLAGS')
> '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now-Wl,--build-id=sha1  -g
> -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now-Wl,--build-id=sha1  -g'
>
>
> I wonder if other flags should be removed as well.
>
> Isn't Python built e.g. with -Werror=format-security or -Wsign-compare binary
> compatible with extension modules built without it?

None of the warning flags should impact ABI or for that matter, even codegen.

> What about FORTIFY_SOURCE and others?

It won't impact ABI, i.e. python could be built with _FORTIFY_SOURCE
and modules without, or vice versa.

> Is there a compiler flags expert here who could help me determine what flags
> could (or even should) be removed from %{extension_*flags}?
>

If it is for distribution packages then I reckon the flags should be
as close as possible for the mere reason of consistency within the
distribution.  If they're used for custom built modules (e.g. through
a tool that python auto-generates to build modules), then a very small
subset of the above flags would be necessary to retain binary
compatibility; you should be able to remove most of it.

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

Changes in the Fedora Packaging Guidelines


Hello packagers,

the Fedora Packaging Committee has been asked to send summaries of changes in 
the Fedora Packaging Guidelines. Here is my attempt to do that. Since this 
hasn't been done in years, this first announcement sets the boundary of what to 
announce somewhat arbitrarily. I will try to followup on this announcement in 
the future once there is something new to announce.



Here are the noteworthy "recent" changes, newest to oldest (more or less):

---

Perl packages are no longer required to have:
 Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))

https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_versioned_module_compat_requires_or_perl_libs
https://pagure.io/packaging-committee/pull-request/1242

---

New section: Ansible Collection Packaging Guidelines

https://docs.fedoraproject.org/en-US/packaging-guidelines/Ansible_collections/
https://pagure.io/packaging-committee/pull-request/1201

---

Rust packages are no longer required to have:
 ExclusiveArch: %{rust_arches}

https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/
https://pagure.io/packaging-committee/pull-request/1222

---

GAP packaging guidelines have been updated, packages MUST use:
 ExclusiveArch: %{gap_arches} (noarch)

https://docs.fedoraproject.org/en-US/packaging-guidelines/GAP/
https://pagure.io/packaging-committee/pull-request/1211

---

Packages are told not to conditionalize Sources definitions
(e.g. on %fedora or %rhel).

https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_do_not_conditionalize_sources
https://pagure.io/packaging-committee/pull-request/1163

---

Packagers SHOULD NOT simply glob everything under a shared directory.
E.g. this SHOULD NOT be used in %files:

%{_bindir}/*
%{_datadir}/*
%{_includedir}/*
%{_mandir}/*
%{_docdir}/*

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_explicit_lists
https://pagure.io/packaging-committee/pull-request/1160

---

Packages MUST use the SPDX license identifiers in the License tag.

https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_valid_license_short_names
https://pagure.io/packaging-committee/pull-request/1142

---

Python packages SHOULD undefine macros if they need to remove some default 
flags from Python shebangs.


https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_shebangs
https://pagure.io/packaging-committee/pull-request/1191

---

Java packages MUST use:
 ExclusiveArch: %{java_arches}

https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_architecture_support
https://pagure.io/packaging-committee/pull-request/1187

---


I've decided to end here. If you think I've omitted something important, let me 
know.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Changes in the Fedora Packaging Guidelines


Hello packagers,

the Fedora Packaging Committee has been asked to send summaries of changes in 
the Fedora Packaging Guidelines. Here is my attempt to do that. Since this 
hasn't been done in years, this first announcement sets the boundary of what to 
announce somewhat arbitrarily. I will try to followup on this announcement in 
the future once there is something new to announce.



Here are the noteworthy "recent" changes, newest to oldest (more or less):

---

Perl packages are no longer required to have:
 Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))

https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_versioned_module_compat_requires_or_perl_libs
https://pagure.io/packaging-committee/pull-request/1242

---

New section: Ansible Collection Packaging Guidelines

https://docs.fedoraproject.org/en-US/packaging-guidelines/Ansible_collections/
https://pagure.io/packaging-committee/pull-request/1201

---

Rust packages are no longer required to have:
 ExclusiveArch: %{rust_arches}

https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/
https://pagure.io/packaging-committee/pull-request/1222

---

GAP packaging guidelines have been updated, packages MUST use:
 ExclusiveArch: %{gap_arches} (noarch)

https://docs.fedoraproject.org/en-US/packaging-guidelines/GAP/
https://pagure.io/packaging-committee/pull-request/1211

---

Packages are told not to conditionalize Sources definitions
(e.g. on %fedora or %rhel).

https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_do_not_conditionalize_sources
https://pagure.io/packaging-committee/pull-request/1163

---

Packagers SHOULD NOT simply glob everything under a shared directory.
E.g. this SHOULD NOT be used in %files:

%{_bindir}/*
%{_datadir}/*
%{_includedir}/*
%{_mandir}/*
%{_docdir}/*

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_explicit_lists
https://pagure.io/packaging-committee/pull-request/1160

---

Packages MUST use the SPDX license identifiers in the License tag.

https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_valid_license_short_names
https://pagure.io/packaging-committee/pull-request/1142

---

Python packages SHOULD undefine macros if they need to remove some default 
flags from Python shebangs.


https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_shebangs
https://pagure.io/packaging-committee/pull-request/1191

---

Java packages MUST use:
 ExclusiveArch: %{java_arches}

https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_architecture_support
https://pagure.io/packaging-committee/pull-request/1187

---


I've decided to end here. If you think I've omitted something important, let me 
know.


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

[rpms/perl-Coro] PR #3: Use _fortify_level


siddhesh commented on the pull-request: `Use _fortify_level` that you are 
following:
``
Actually since this is only for arm, I wonder if we could simply drop that 
whole block.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Coro/pull-request/3
___
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: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python

2023-01-16 Thread Kevin P. Fleming


On 1/16/23 13:39, Miro Hrončok wrote:
Isn't Python built e.g. with -Werror=format-security or -Wsign-compare 
binary compatible with extension modules built without it? 


That's a good question, it's almost as if "extension_flags" should be 
named "abi_compatibility_flags" or something similar.


--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
___
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

-Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python


Hello folks,
this recent Fedora change:

https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags

Made me think:

Which compiler flags we need to store in Python and which can we omit?

In order to make Python extension modules binary compatible with Python, Python 
saves the compiler flags at compile-time and reuses them when building 
extension modules.


Historically, we had troubles with this approach because some of the flags are 
unusable without redhat-rpm-config, annobin etc.


As a result, there are now 2 compiler flags macros available for RPM: 
%{build_cflags} and %{extension_cflags} (same for ldflags etc.).
While Python itself is built with %{build_cflags}, it saves %{extension_cflags} 
in sysconfig.


The flags differ like this:

$ diff -u <(rpm --eval '%build_cflags' | tr ' ' '\n') <(rpm --eval 
'%extension_cflags' | tr ' ' '\n') | grep ^-

--flto=auto
--ffat-lto-objects
--specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
--specs=/usr/lib/rpm/redhat/redhat-annobin-cc1

$ diff -u <(rpm --eval '%build_ldflags' | tr ' ' '\n') <(rpm --eval 
'%extension_ldflags' | tr ' ' '\n') | grep ^-

--specs=/usr/lib/rpm/redhat/redhat-hardened-ld
--specs=/usr/lib/rpm/redhat/redhat-annobin-cc1

(There are also some other differences wrt 
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects but 
those are apparently harder to get from outside of a real build.)


The current set of flags from Python can be obtained by:

>>> sysconfig.get_config_var('CFLAGS')
'-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG  -O2  -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security -U_FORTIFY_SOURCE 
-Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS 
-fstack-protector-strong   -m64  -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -fcf-protection   -D_GNU_SOURCE -fPIC -fwrapv -O2 
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security 
-U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong   -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-D_GNU_SOURCE -fPIC -fwrapv  -O2  -fexceptions -g -grecord-gcc-switches -pipe 
-Wall -Werror=format-security -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE 
-Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong 
-m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
-fcf-protection   -D_GNU_SOURCE -fPIC -fwrapv'

>>> sysconfig.get_config_var('LDFLAGS')
'-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now-Wl,--build-id=sha1  -g 
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now-Wl,--build-id=sha1  -g'



I wonder if other flags should be removed as well.

Isn't Python built e.g. with -Werror=format-security or -Wsign-compare binary 
compatible with extension modules built without it?


What about FORTIFY_SOURCE and others?

Is there a compiler flags expert here who could help me determine what flags 
could (or even should) be removed from %{extension_*flags}?


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

-Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python


Hello folks,
this recent Fedora change:

https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags

Made me think:

Which compiler flags we need to store in Python and which can we omit?

In order to make Python extension modules binary compatible with Python, Python 
saves the compiler flags at compile-time and reuses them when building 
extension modules.


Historically, we had troubles with this approach because some of the flags are 
unusable without redhat-rpm-config, annobin etc.


As a result, there are now 2 compiler flags macros available for RPM: 
%{build_cflags} and %{extension_cflags} (same for ldflags etc.).
While Python itself is built with %{build_cflags}, it saves %{extension_cflags} 
in sysconfig.


The flags differ like this:

$ diff -u <(rpm --eval '%build_cflags' | tr ' ' '\n') <(rpm --eval 
'%extension_cflags' | tr ' ' '\n') | grep ^-

--flto=auto
--ffat-lto-objects
--specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
--specs=/usr/lib/rpm/redhat/redhat-annobin-cc1

$ diff -u <(rpm --eval '%build_ldflags' | tr ' ' '\n') <(rpm --eval 
'%extension_ldflags' | tr ' ' '\n') | grep ^-

--specs=/usr/lib/rpm/redhat/redhat-hardened-ld
--specs=/usr/lib/rpm/redhat/redhat-annobin-cc1

(There are also some other differences wrt 
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects but 
those are apparently harder to get from outside of a real build.)


The current set of flags from Python can be obtained by:

>>> sysconfig.get_config_var('CFLAGS')
'-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG  -O2  -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security -U_FORTIFY_SOURCE 
-Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS 
-fstack-protector-strong   -m64  -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -fcf-protection   -D_GNU_SOURCE -fPIC -fwrapv -O2 
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security 
-U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong   -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-D_GNU_SOURCE -fPIC -fwrapv  -O2  -fexceptions -g -grecord-gcc-switches -pipe 
-Wall -Werror=format-security -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE 
-Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong 
-m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
-fcf-protection   -D_GNU_SOURCE -fPIC -fwrapv'

>>> sysconfig.get_config_var('LDFLAGS')
'-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now-Wl,--build-id=sha1  -g 
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now-Wl,--build-id=sha1  -g'



I wonder if other flags should be removed as well.

Isn't Python built e.g. with -Werror=format-security or -Wsign-compare binary 
compatible with extension modules built without it?


What about FORTIFY_SOURCE and others?

Is there a compiler flags expert here who could help me determine what flags 
could (or even should) be removed from %{extension_*flags}?


Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2161311] perl-Coro: Use %_fortify_level instead of twiddling with RPM_OPT_FLAGS

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

Summary|Use %_fortify_level instead |perl-Coro: Use
   |of twiddling with   |%_fortify_level instead of
   |RPM_OPT_FLAGS   |twiddling with
   ||RPM_OPT_FLAGS




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161311
___
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: valgrind on Fedora

2023-01-16 Thread Gordon Messmer


On 2023-01-16 01:38, Tom Hughes wrote:

I suspect this is a result of libraries being opened and closed
dynamically...
Try using --keep-debuginfo=yes to make valgrind cache debuginfo
for libraries that have been closed. 



Yes, that was it.  I did not know this about valgrind.  Thank you!

I'll resume work to shrink packagekitd.
___
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: -D_FORTIFY_SOURCE defined but value is too low [-Werror]

On Mon, Jan 16, 2023 at 1:05 PM Daniel P. Berrangé  wrote:
>
> I'm getting the strange error in $SUBJECT in an upstream CI job that
> is targetting Fedora rawhide. I'm guessing it is something related to
> the recent changes to set the  _FOTIFY_SOURCE value to 3 instead of
> 2, but not sure what.
>
> What I'm finding especially bizarre is that I can't reproduce it on
> rawhide myself, despite using the exact same package versions and
> base container.
>
> I can't even figure out which particular component is emitting this
> error message string. My only thought is that perhaps it could be
> ccache related, since upstream CI has ccache enabled and the cache
> is preserved across CI pipelines. That could explain why I can't
> reproduce myself.
>
> My app has a config.h file used by all sources that does
>
>   #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__
>   # define _FORTIFY_SOURCE 2
>   #endif
>
> but the -D_FORTIFY_SOURCE=3 set by RPM in CFLAGS on the gcc command
> line ought to override this fine.
>
> $ gcc -Ilibvirt-glib/libvirt-glib-1.0.so.0.4000.0.p -Ilibvirt-glib 
> -I../libvirt-glib -I. -I.. -I/usr/include/glib-2.0 
> -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
> -std=gnu99 ...snip many -Wxxx flags... -fexceptions 
> -fasynchronous-unwind-tables -fipa-pure-const  -fstack-protector-strong -O2 
> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe  
> -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
> -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC 
> -pthread '-DLOCALEDIR="/usr/share/locale"' '-DDATADIR="/usr/share"' 
> -DLIBVIRT_GLIB_BUILD -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_48 
> -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_48 -MD -MQ 
> libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -MF 
> libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o.d -o 
> libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -c 
> ../libvirt-glib/libvirt-glib-error.c
> ../libvirt-glib/libvirt-glib-error.c: error: -D_FORTIFY_SOURCE defined but 
> value is too low [-Werror]
> cc1: all warnings being treated as errors
>
> So does anyone know what this error message would be coming from, and more
> importantly how to make it go away :-)

I've seen this happen with ccache is in use[1], which flips the
defines around, causing _FORTIFY_SOURCE to be undefined.  I've posted
a fix to redhat-rpm-config[2] to remedy this in the default flags to
work around the reordering; the additional -U was redundant anyway.

Sid

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2160275
[2] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/237
___
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: -D_FORTIFY_SOURCE defined but value is too low [-Werror]

2023-01-16 Thread Daniel P . Berrangé

On Mon, Jan 16, 2023 at 12:06:59PM -0600, Jonathan Wright wrote:
> Are you by chance running this inside of a rawhide docker container within
> GH actions?  If so, I'm in the same boat and haven't figured out how to
> force it back to "2", or why it's failing in the first place.

No, I'm using GitLab CI, rather than GitHub.  Still docker, but I
fully control the container content, which usually means I can
100% reliably reproduce problems locally but not this time :-(


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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 2161364] perl-Module-ExtractUse-0.345 is available

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Module-ExtractUse-0.345-1.fc36.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=96214046


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161364
___
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: -D_FORTIFY_SOURCE defined but value is too low [-Werror]

2023-01-16 Thread Jonathan Wright via devel

Are you by chance running this inside of a rawhide docker container within
GH actions?  If so, I'm in the same boat and haven't figured out how to
force it back to "2", or why it's failing in the first place.

On Mon, Jan 16, 2023 at 12:05 PM Daniel P. Berrangé 
wrote:

> I'm getting the strange error in $SUBJECT in an upstream CI job that
> is targetting Fedora rawhide. I'm guessing it is something related to
> the recent changes to set the  _FOTIFY_SOURCE value to 3 instead of
> 2, but not sure what.
>
> What I'm finding especially bizarre is that I can't reproduce it on
> rawhide myself, despite using the exact same package versions and
> base container.
>
> I can't even figure out which particular component is emitting this
> error message string. My only thought is that perhaps it could be
> ccache related, since upstream CI has ccache enabled and the cache
> is preserved across CI pipelines. That could explain why I can't
> reproduce myself.
>
> My app has a config.h file used by all sources that does
>
>   #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__
>   # define _FORTIFY_SOURCE 2
>   #endif
>
> but the -D_FORTIFY_SOURCE=3 set by RPM in CFLAGS on the gcc command
> line ought to override this fine.
>
> $ gcc -Ilibvirt-glib/libvirt-glib-1.0.so.0.4000.0.p -Ilibvirt-glib
> -I../libvirt-glib -I. -I.. -I/usr/include/glib-2.0
> -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> -std=gnu99 ...snip many -Wxxx flags... -fexceptions
> -fasynchronous-unwind-tables -fipa-pure-const  -fstack-protector-strong -O2
> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
> -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC
> -pthread '-DLOCALEDIR="/usr/share/locale"' '-DDATADIR="/usr/share"'
> -DLIBVIRT_GLIB_BUILD -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_48
> -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_48 -MD -MQ
> libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -MF
> libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o.d -o
> libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -c
> ../libvirt-glib/libvirt-glib-error.c
> ../libvirt-glib/libvirt-glib-error.c: error: -D_FORTIFY_SOURCE defined but
> value is too low [-Werror]
> cc1: all warnings being treated as errors
>
> So does anyone know what this error message would be coming from, and more
> importantly how to make it go away :-)
>
> With regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
> ___
> 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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
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 2161364] perl-Module-ExtractUse-0.345 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1938423
  --> https://bugzilla.redhat.com/attachment.cgi?id=1938423=edit
Update to 0.345 (#2161364)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161364
___
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 2161364] New: perl-Module-ExtractUse-0.345 is available

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

Bug ID: 2161364
   Summary: perl-Module-ExtractUse-0.345 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Module-ExtractUse
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.345
Upstream release that is considered latest: 0.345
Current version/release in rawhide: 0.344-4.fc37
URL: http://search.cpan.org/dist/Module-ExtractUse/

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161364
___
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

-D_FORTIFY_SOURCE defined but value is too low [-Werror]

2023-01-16 Thread Daniel P . Berrangé

I'm getting the strange error in $SUBJECT in an upstream CI job that
is targetting Fedora rawhide. I'm guessing it is something related to
the recent changes to set the  _FOTIFY_SOURCE value to 3 instead of
2, but not sure what. 

What I'm finding especially bizarre is that I can't reproduce it on
rawhide myself, despite using the exact same package versions and
base container.

I can't even figure out which particular component is emitting this
error message string. My only thought is that perhaps it could be
ccache related, since upstream CI has ccache enabled and the cache
is preserved across CI pipelines. That could explain why I can't
reproduce myself.

My app has a config.h file used by all sources that does

  #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__
  # define _FORTIFY_SOURCE 2
  #endif

but the -D_FORTIFY_SOURCE=3 set by RPM in CFLAGS on the gcc command
line ought to override this fine.

$ gcc -Ilibvirt-glib/libvirt-glib-1.0.so.0.4000.0.p -Ilibvirt-glib 
-I../libvirt-glib -I. -I.. -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
-std=gnu99 ...snip many -Wxxx flags... -fexceptions 
-fasynchronous-unwind-tables -fipa-pure-const  -fstack-protector-strong -O2 
-flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe  
-U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC 
-pthread '-DLOCALEDIR="/usr/share/locale"' '-DDATADIR="/usr/share"' 
-DLIBVIRT_GLIB_BUILD -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_48 
-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_48 -MD -MQ 
libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -MF 
libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o.d -o 
libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -c 
../libvirt-glib/libvirt-glib-error.c
../libvirt-glib/libvirt-glib-error.c: error: -D_FORTIFY_SOURCE defined but 
value is too low [-Werror]
cc1: all warnings being treated as errors

So does anyone know what this error message would be coming from, and more
importantly how to make it go away :-)

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Do we have alternatives to alternatives?

2023-01-16 Thread Vít Ondruch



Dne 16. 01. 23 v 12:34 Petr Menšík napsal(a):

Hi!

I heard (read) objections to any alternatives macros usage often. But 
unless I am mistaken, we do not have any user (enough) friendly way to 
support similar functionality tools with just minor differences.



I have not tried this:

https://github.com/openSUSE/libalternatives

But I like the idea.


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

Update to clamav 1.0.0 coming next week to rawhide

2023-01-16 Thread Orion Poplawski

I will be updating clamav to 1.0.0 next week in rawhide.  This includes 
a switch to rust, a soname update and a slight API change.  Dependent 
packages have been rebuilt here:

 https://copr.fedorainfracloud.org/coprs/orion/clamav-1.0/builds/

Fix for klamav has been filed here:
 https://src.fedoraproject.org/rpms/klamav/pull-request/1

This has been in the works for quite a while due to the switch to rust. 
Many thanks to Fabio Valentini for reviewing all of the rust dependencies.


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


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

Rpmautospec updated to version 0.3.1 in Koji

2023-01-16 Thread Nils Philippsen

Hey there,

Kevin Fenzi recently updated the Koji builders in production and with
this, the rpmautospec plugin got updated to version 0.3.1.

These are the changes in this version which affect building packages on
Koji in Fedora Infrastructure:

- You can mark a commit log with `[skip changelog]` (on a line of its
own, without the quotes) and to avoid adding it to the RPM changelog.

- The (epoch-)version-release at the end of every generated changelog
header is separated from the rest of the line with a dash.

Cheers,
Nils
-- 
Nils Philippsen / Senior Software Engineer / Red Hat
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D

___
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

Rpmautospec updated to version 0.3.1 in Koji

2023-01-16 Thread Nils Philippsen

Hey there,

Kevin Fenzi recently updated the Koji builders in production and with
this, the rpmautospec plugin got updated to version 0.3.1.

These are the changes in this version which affect building packages on
Koji in Fedora Infrastructure:

- You can mark a commit log with `[skip changelog]` (on a line of its
own, without the quotes) and to avoid adding it to the RPM changelog.

- The (epoch-)version-release at the end of every generated changelog
header is separated from the rest of the line with a dash.

Cheers,
Nils
-- 
Nils Philippsen / Senior Software Engineer / Red Hat
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D

___
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-Coro] PR #3: Use _fortify_level


siddhesh opened a new pull-request against the project: `perl-Coro` that you 
are following:
``
Use _fortify_level
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Coro/pull-request/3
___
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 2161311] Use %_fortify_level instead of twiddling with RPM_OPT_FLAGS

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

 Blocks||2158232





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2158232
[Bug 2158232] Add _FORTIFY_SOURCE=3 to distribution build flags
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161311
___
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 2161311] New: Use %_fortify_level instead of twiddling with RPM_OPT_FLAGS

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

Bug ID: 2161311
   Summary: Use %_fortify_level instead of twiddling with
RPM_OPT_FLAGS
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Coro
  Assignee: mspa...@redhat.com
  Reporter: sipoy...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
There is now a canonical way to disable fortification, see "Fortification
level" in the build flags guide:

https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md#source-fortification

This way, one doesn't need to mess with RPM_OPT_FLAGS to do this. The usage in
perl-Coro seems pointless for Fedora since there's no supported arm32 anymore,
but I'll send a PR anyway.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161311
___
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: Use cases for 'fedpkg scratch-build'

2023-01-16 Thread Vít Ondruch


I don't oppose to change of the defaults.

However, I am also using `fedpkg scratch-build --srpm some.rpm`. So how 
would the proposed change influence this command?



Vít


Dne 16. 01. 23 v 8:56 Otto Liljalaakso napsal(a):

Hello everybody,

I would like to gather different use cases for the 'fedpkg 
scratch-build' command.


Currently, this is exactly the same as 'fedpkg build --scratch', 
meaning that is performs a scratch build of the pushed head of the 
current branch. At least in my workflow, I only do scratch builds 
before pushing, to ensure that what I am about to push builds 
correctly in Koji. Because if this, I never use the default form. 
Instead, I always specify 'fedpkg scratch-build --srpm', so that the 
srpm to build from is locally generated from the local working directory.


What I would like to do is to submit a pull request to either fedpkg 
or rpkg, making that the default. It is a single line code change, not 
counting changes to documentation and code comments.


Doing a scratch build from the pushed contents would still be possible 
by either a) using 'fedpkg build --scratch' or b) checking out the 
remote head and then issuing 'fedpkg scratch-build'.


Above change seems like a clear improvement to me, making the most 
used option the default. But I have noticed that workflows differ 
wildly between packagers, so before submitting any code for review, I 
would like to hear if somebody regularly uses the default form 'fedpkg 
scratch-build' and thinks it currently does the right thing.


This issue came up when we were updating Package Maintainer Docs about 
Koji [1].


[1]: 
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101#comment-181487

___
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

Intend to retire klee

2023-01-16 Thread Lukas Zaoral

Hello,

Unfortunately, klee cannot be built in Rawhide at the moment since it
is incompatible with LLVM 15 and it requires the corresponding Clang
version during the build. Therefore, the llvm14 and clang14
compatibility packages cannot be used as clang14 only contains
libraries.

I've ported this package to newer LLVM versions for its last four
releases, but proper support for LLVM 15's opaque pointers and new
optimization pass manager would require a bigger rewrite of klee's
internals. I've been quite occupied for the last few months and I lack
the necessary deeper knowledge of LLVM for that to happen and the
upstream is also not as active as they used to be.

I plan to retire this package in rawhide in a week. If you are
interested, let me know.

Regards,
Lukas
___
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: z3 soname bump

2023-01-16 Thread Lukas Zaoral

Hi,
there is no need to wait for klee. Unfortunately, the package cannot be build
in Rawhide at the moment since the project cannot be built with LLVM 15 and
the llvm14 compatibility package cannot be used with clang 15 (and clang14 is
a library only package).

Unfortunately, I do not have the necessary time or that deep knowledge of LLVM
to do the necessary porting work myself (quite a lot of breaking
changes in LLVM 15)
and upstream has not yet merged the work I did for LLVM 14 last March.
I plan to retire this package in a week unless someone steps up. I'll
announce this
in a separate email as well.

Regards,
Lukas

On Sun, Jan 15, 2023 at 7:07 PM Jerry James  wrote:
>
> Version 4.12.0 of z3 has been released, and bumps the library soname.
> In a week, I will build the new version for z3 and will rebuild its
> sole consumer, klee, unless the klee maintainers (BCCed) prefer to do
> so themselves.
> --
> Jerry James
> http://www.jamezone.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
___
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 2160077] perl-Prima-1.67-1.fc38 FTBFS: t/Image/Transform.t aborts

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

 Blocks||2158232





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2158232
[Bug 2158232] Add _FORTIFY_SOURCE=3 to distribution build flags
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2160077
___
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: Use cases for 'fedpkg scratch-build'

2023-01-16 Thread Richard Shaw

On Mon, Jan 16, 2023 at 8:06 AM Miro Hrončok  wrote:

> On 16. 01. 23 14:57, Richard Shaw wrote:
> >
> > Since `fedpkg scratch-build` bombs out with an error if you've made
> local
> > changes I propose a slight modification:
> >
> > If no changes are made then it does a normal scratch build for the "does
> this
> > still build / not build" 1% use case
> >
> > If there are local changes it automatically uploads an SRPM for the 99%
> use case.
>
> I love this.
>
> $ fedpkg scratchbuild  / $ fedpkg build --scratch
> Uncommitted changes found, uploading SRPM...
>
> > If you end up in a weird state, i.e. made changes but for some reason
> want to
> > do a "normal" scratch build you have a few different ways to accomplish
> that.
>
> That was already impossible:
>
> $ fedpkg --release rawhide scratch-build
> Could not execute scratch_build: .../python3.9 has uncommitted changes.
> Use
> git status to see details
> Try option --srpm to make scratch build from local changes.
>

Someone mentioned it's possible to specify a specific commit to build from?
I don't know I haven't tried. The other option which is what I would use
would to use `git stash` / scratch build / `git stash apply`.

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

Re: Use cases for 'fedpkg scratch-build'


On 16. 01. 23 14:57, Richard Shaw wrote:


Since `fedpkg scratch-build` bombs out with an error if you've made local 
changes I propose a slight modification:


If no changes are made then it does a normal scratch build for the "does this 
still build / not build" 1% use case


If there are local changes it automatically uploads an SRPM for the 99% use 
case.


I love this.

$ fedpkg scratchbuild  / $ fedpkg build --scratch
Uncommitted changes found, uploading SRPM...

If you end up in a weird state, i.e. made changes but for some reason want to 
do a "normal" scratch build you have a few different ways to accomplish that.


That was already impossible:

$ fedpkg --release rawhide scratch-build
Could not execute scratch_build: .../python3.9 has uncommitted changes.  Use 
git status to see details

Try option --srpm to make scratch build from local changes.

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

Re: Use cases for 'fedpkg scratch-build'

2023-01-16 Thread Richard Shaw

On Mon, Jan 16, 2023 at 3:38 AM Sandro  wrote:

> On 16-01-2023 08:56, Otto Liljalaakso wrote:
> > Above change seems like a clear improvement to me, making the most used
> > option the default. But I have noticed that workflows differ wildly
> > between packagers, so before submitting any code for review, I would
> > like to hear if somebody regularly uses the default form 'fedpkg
> > scratch-build' and thinks it currently does the right thing.
>
> +1 for the PR.
>
> So far I haven't used the scratch-build command. I always use build,
> since I need to supply extra options anyway to start a scratch build
> from local HEAD. This change would make me use the scratch-build command
> instead.
>

Since `fedpkg scratch-build` bombs out with an error if you've made local
changes I propose a slight modification:

If no changes are made then it does a normal scratch build for the "does
this still build / not build" 1% use case

If there are local changes it automatically uploads an SRPM for the 99% use
case.

If you end up in a weird state, i.e. made changes but for some reason want
to do a "normal" scratch build you have a few different ways to accomplish
that.

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

Re: -fno-omit-frame-pointer does not work as advertised

2023-01-16 Thread Florian Weimer

* Daniel Alley:

> What has happened is that because -O2 optimized away all of the stack
> access for the function, so it uses no space on the stack, so there is
> no stack frame separate from the caller's.
>
> It is unlikely that the critical bottleneck of any applications will
> be on such a function.

Is it?  Plenty of math functions and cryptographic primitives are like
that.  Anything that makes an inline system call, too.  Maybe you can
infer from the caller's caller where the time is spent in these cases.
People certainly seem to be concerned about this gap because they
included -mno-omit-leaf-frame-pointer in the build flags.

This is something that an upstream/ABI discussion could cover, with some
sort of protocol that ensures the toolchain produces something the
intended tools can consume.  For example, there could be a rule that
only frames up to a certain size may lack a frame pointer, so that a
fixed-size copy from the top of the stack can recover the caller address
by looking at the DWARF unwinding data (out of context, for that frame
alone).  Or it could be spelt out that LBR has to be used to recover the
calling frame.  This isn't really something that Fedora can implement in
a downstream change, though.

Thanks,
Florian
___
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: Use cases for 'fedpkg scratch-build'

2023-01-16 Thread Richard W.M. Jones

On Mon, Jan 16, 2023 at 09:56:31AM +0200, Otto Liljalaakso wrote:
> Hello everybody,
> 
> I would like to gather different use cases for the 'fedpkg
> scratch-build' command.
> 
> Currently, this is exactly the same as 'fedpkg build --scratch',
> meaning that is performs a scratch build of the pushed head of the
> current branch. At least in my workflow, I only do scratch builds
> before pushing, to ensure that what I am about to push builds
> correctly in Koji. Because if this, I never use the default form.
> Instead, I always specify 'fedpkg scratch-build --srpm', so that the
> srpm to build from is locally generated from the local working
> directory.
> 
> What I would like to do is to submit a pull request to either fedpkg
> or rpkg, making that the default. It is a single line code change,
> not counting changes to documentation and code comments.
> 
> Doing a scratch build from the pushed contents would still be
> possible by either a) using 'fedpkg build --scratch' or b) checking
> out the remote head and then issuing 'fedpkg scratch-build'.
> 
> Above change seems like a clear improvement to me, making the most
> used option the default. But I have noticed that workflows differ
> wildly between packagers, so before submitting any code for review,
> I would like to hear if somebody regularly uses the default form
> 'fedpkg scratch-build' and thinks it currently does the right thing.
> 
> This issue came up when we were updating Package Maintainer Docs
> about Koji [1].
> 
> [1]: 
> https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101#comment-181487

I always use the --srpm option.  I wasn't really aware that there was
another possibility, and it doesn't seem very useful.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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: valgrind on Fedora

2023-01-16 Thread Kalev Lember

On Mon, Jan 16, 2023 at 2:21 PM Richard W.M. Jones 
wrote:

> Also want to mention that your valgrind command line is ... a little
> naive.  Many other options are useful.  Here's what we use in nbdkit:
>
>
> https://gitlab.com/nbdkit/nbdkit/-/blob/a5f804180240aea7031470cb8ed294f904268f0a/wrapper.c#L206-216
>
> (Best to check each of these options in the manual before using)
>
> Also make use of suppressions:
>
>   https://gitlab.com/nbdkit/nbdkit/-/tree/master/valgrind


Also, to add to this, glib2 has a suppressions file you can use to cut down
on the false positives: /usr/share/glib-2.0/valgrind/glib.supp

-- 
Kalev
___
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: valgrind on Fedora

2023-01-16 Thread Richard W.M. Jones

On Mon, Jan 16, 2023 at 12:52:38AM -0800, Gordon Messmer wrote:
> ==29692== 30 bytes in 2 blocks are definitely lost in loss record
> 917 of 2,602
> ==29692==    at 0x484386F: malloc (vg_replace_malloc.c:393)
> ==29692==    by 0x14806539: ???
> ==29692==    by 0x14BA7D87: ???
> ==29692==    by 0x14BA7DFC: ???
> ==29692==    by 0x14B86D88: ???
> ==29692==    by 0x146ED193: ???
> ==29692==    by 0x1475E205: ???
> ==29692==    by 0x1475E71A: ???
> ==29692==    by 0x1475ED49: ???
> ==29692==    by 0x146EF09F: ???

This has the hallmark of missing glibc debuginfo.  What's the output
of this command?

$ rpm -qa | grep glibc | sort

Rich.

> ==29692==    by 0x4A5D0E7: g_type_create_instance (gtype.c:1931)
> ==29692==    by 0x4A42C1F: g_object_new_internal (gobject.c:2228)
> ==29692==    by 0x4A44247: g_object_new_with_properties (gobject.c:2391)
> ==29692==    by 0x4A44FF0: g_object_new (gobject.c:2037)
> ==29692==    by 0x146F5395: ???
> ==29692==    by 0x145D820C: ???
> ==29692==    by 0x145E06E3: ???
> ==29692==    by 0x1276D0: pk_backend_load (pk-backend.c:569)
> ==29692==    by 0x135D1A: pk_engine_load_backend (pk-engine.c:967)
> ==29692==    by 0x119468: main (pk-main.c:219)
> 
> ==29692== 158,863 (8,192 direct, 150,671 indirect) bytes in 1 blocks
> are definitely lost in loss record 2,602 of 2,602
> ==29692==    at 0x48486AF: realloc (vg_replace_malloc.c:1451)
> ==29692==    by 0x14805D7B: ???
> ==29692==    by 0x148062D6: ???
> ==29692==    by 0x1480DA3F: ???
> ==29692==    by 0x1480FCAB: ???
> ==29692==    by 0x14B86DF5: ???
> ==29692==    by 0x146ED193: ???
> ==29692==    by 0x1475E205: ???
> ==29692==    by 0x1475E71A: ???
> ==29692==    by 0x1475ED49: ???
> ==29692==    by 0x146EF09F: ???
> ==29692==    by 0x4A5D0E7: g_type_create_instance (gtype.c:1931)
> ==29692==    by 0x4A42C1F: g_object_new_internal (gobject.c:2228)
> ==29692==    by 0x4A44247: g_object_new_with_properties (gobject.c:2391)
> ==29692==    by 0x4A44FF0: g_object_new (gobject.c:2037)
> ==29692==    by 0x146F5395: ???
> ==29692==    by 0x145D820C: ???
> ==29692==    by 0x145E06E3: ???
> ==29692==    by 0x1276D0: pk_backend_load (pk-backend.c:569)
> ==29692==    by 0x135D1A: pk_engine_load_backend (pk-engine.c:967)
> ==29692==    by 0x119468: main (pk-main.c:219)
> ___
> 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: valgrind on Fedora

2023-01-16 Thread Richard W.M. Jones

On Sun, Jan 15, 2023 at 10:10:24PM -0800, Gordon Messmer wrote:
> I'm working on reducing memory use in packagekitd, and so far
> progress has been very good.  I've opened 4 memory-related PRs
> against PackageKit and libdnf this week, and locally I've reduced
> memory use at idle by almost 90% (I can reliably cause stock
> packagekitd to use ~ 700MB of RAM in a couple of minutes, but a
> patched version will free most of its memory and shrink to around
> 75MB.)
> 
> However, I've hit a possibly minor road block.  I haven't fixed all
> of the leaks originally reported; valgrind still reports some leaks
> in my patched builds, but most of the call stack is unresolved, so I
> can't locate the problems in order to address any remaining issues.
> 
> I'm running 'valgrind --leak-check=full --num-callers=25
> /usr/libexec/packagekitd', running for a while, and then exiting
> with Ctrl-C.  When I exit, I get a list of leaks, most of which
> contain unresolved symbols.  I see the same thing when I run
> Fedora's builds (in which case, debug info appears to be provided by
> debuginfod-client), or when I run my own builds (in which case I'm
> installing the debuginfo and debugsource packages produced by the
> local build.)
> 
> Does anyone have any hints for improving the information I get from
> valgrind?

Just wanted to report that valgrind works very well for me in Fedora
if you have correct debuginfo installed (or debuginfod).  I use it
very regularly.

Also want to mention that your valgrind command line is ... a little
naive.  Many other options are useful.  Here's what we use in nbdkit:

  
https://gitlab.com/nbdkit/nbdkit/-/blob/a5f804180240aea7031470cb8ed294f904268f0a/wrapper.c#L206-216

(Best to check each of these options in the manual before using)

Also make use of suppressions:

  https://gitlab.com/nbdkit/nbdkit/-/tree/master/valgrind

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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 2160077] perl-Prima-1.67-1.fc38 FTBFS: t/Image/Transform.t aborts

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

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2023-01-16 13:10:52



--- Comment #4 from Petr Pisar  ---
Thanks. I applied the fix in Fedora.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2160077
___
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

[rpms/perl-Dist-Zilla-Plugin-GithubMeta] PR #1: Package tests and update license to SPDX license

2023-01-16 Thread Michal Josef Špaček


mspacek merged a pull-request against the project: 
`perl-Dist-Zilla-Plugin-GithubMeta` that you are following.

Merged pull-request:

``
Package tests and update license to SPDX license
``

https://src.fedoraproject.org/rpms/perl-Dist-Zilla-Plugin-GithubMeta/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: Use cases for 'fedpkg scratch-build'

2023-01-16 Thread Michael J Gruber

Yes, testing local changes with `srpm` is the main use case. I would even say 
that using `scratch-build` without `--srpm` is a typical mistake for new 
packagers - thinking they test before they push, when in effect they don't.

Testing (scratch-building) the pushed head makes sense when there are/were 
koschei warnings, or updates to related packages and you want to know whwther 
your package still builds (would build) as is, say before a mass rebuild.

And as you point out, checking out the pushed head gives you almost that at the 
expense of an srpm rebuild, which is not exactly the same as scratch-building 
the "original srpm".

`--srpm` is named misleadingly, by the way, because it names the "transport of 
the source" when indeed it implies a potentially different source version. 
That's another reasons why removing it (the name) and making it the mode of 
operation for `scratch-build` makes sense:
- `scratch-build` is about doing things from (your) scratch. That involves an 
srpm for technical reasons.
- `build` is about building something pushed, and `--scratch` only changes 
where it is build.

Now I'm wondering: Does `fedpkg build --srpm` imply `--scratch`? I would hope 
so, and I'm really wondering whether any srpm-mode should belong to that 
command at all. It's much clearer if `build` deals with sources "in the 
buildsystem" only, and {copr,scratch,local,mock}-build with the local sources. 
(Yes, `local` and `mockbuild` could have helpful aliases, too.)
___
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 2160077] perl-Prima-1.67-1.fc38 FTBFS: t/Image/Transform.t aborts

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Prima-1.67-2.fc38




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2160077
___
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: Shorter Shutdown Timer (System-Wide Change proposal)

2023-01-16 Thread Lennart Poettering

On Mi, 11.01.23 16:35, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> We have thousands of systemd services in Fedora. To "just add timeouts
> to things that take too long" would mean updating them individually.
> (Or maybe only some, but we don't really know which ones.)
> This is never going to happen, it's just too much work, and there is
> no clear clear understanding if it is "safe" for any specific service.
>
> Instead, the idea is to attack the problem from the other end: reduce
> the timeout for everyone. Once this happens, we should start getting
> feedback about what services where this doesn't work. Some services
> legitimately need a long timeout (databases, etc), and for those the
> maintainers would usually have a good idea and can extend the timeout
> easily. Some services are just buggy, and with the additional visibility
> and tracebacks, it should be much easier to diagnose why they are slow.
>
> Approaching the problem from this side is much more feasible. We'll
> probably have to touch a dozen files instead of thousands.

Just to say this cleary btw: when we introduced the time-out initially
we were coming from sysvinit where no such time-out existed at
all. Hence we picked a conservative (i.e. overly long) value to not
upset things too badly. And yes, some people were very much upset we
now defaulted to a time-out.

If we'd start from scratch without sysvinit heritage, I think we
would have started with something much much lower right-away. It
appears to me fedora is considering switch to that now, and I
certainly think that would make a lot of sense.

Anyway, if fedora now wants to lower the default setup, then I
certainly sympathize. I think a policy of "aggressive time-out by
default, individual opt-outs per-service" is a better policy for a
stable OS than the current "conservative time-out by default,
individual opt-in per-service for something more aggressive".

So yes, lowering the time-outs by default would make sense to me, but
of course, people will be upset...

Lennart

--
Lennart Poettering, Berlin
___
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: Do we have alternatives to alternatives?