Re: Modern C failures in Haskell stack

[Jens-Ulrik Petersen]

Thanks Richard for the PR and Florian for the patch

On Thu, Feb 15, 2024 at 11:28 PM Richard W.M. Jones 
wrote:

> On Thu, Feb 15, 2024 at 12:57:21PM +0100, Florian Weimer wrote:
> > For the first issue, please try this GHC patch
>


> I submitted it to GHC here:
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12079


The patch was approved upstream.

It should now be in the Rawhide buildroot as ghc-9.4.5-140.fc41
(Richard: hopefully also serves as a rebuild bump for riscv64)

Cheers, Jens
--
___
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: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

[Jens-Ulrik Petersen]

Thanks for the support.

I will start to post more review requests, maybe post them on discourse
too...

Currently there is https://bugzilla.redhat.com/show_bug.cgi?id=2163472
(base64) which I opened 1 year ago.

Jens

On Fri, Feb 16, 2024 at 3:54 AM Christopher Klooz  wrote:

> On 14/02/2024 17.35, Michel Lind wrote:
>
> As a pandoc user, I'm happy to help with any reviews. Is there a list
> where this tends to get posted, apart from devel?
>
> Thanks,
>
> Michel
>
> Once the package needs a review, the request should be found here:
> http://fedoraproject.org/PackageReviewStatus/
>
> Details of the roles of "contributor" and "reviewer" in the "package
> review process" can be found here:
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/
> (based upon its history, I expect this page is kept updated but I don't
> know for sure)
>
> According to the elaboration, you need to be in the FAS packager group,
> even for reviews.
>
> On Fri, Feb 09, 2024 at 11:26:33PM +0800, Jens-Ulrik Petersen wrote:
>
> I should also have added there's an increasing amount of technical debt
> with the pandoc packaging - I guess I need to beg people to help with
> package reviews: also reminded of our packaging (review) streamlining
> discussion from Flock last year.
>
> Jens
>
> On Fri, 9 Feb 2024, 23:23 Jens-Ulrik Petersen,  
>  wrote:
>
>
> Hello I am here - thanks for contacting me.
>
> I was hoping to cover this as part of my F40 Change, but unfortunately I
> haven't gotten to it, so the Change is now at risk of being deferred to F41.
>
> Nevertheless I will see what I can do about this for F40: maybe a backport
> can also be done for F39.
>
> Next time you could also comment on the relevant 
> bug:https://bugzilla.redhat.com/show_bug.cgi?id=1996301 - that would be
> appreciated.
>
> Thanks, Jens
>
> PS Special thanks to Neal Gompa for pinging me in Matrix. 
>
>
> On Fri, 9 Feb 2024, 20:05 Christopher Klooz,  
>  wrote:
>
>
> I cannot reach the maintainer petersen (see mail below): The package
> "pandoc" remains at 3.1.3 in Fedora, but pandoc is already at 3.1.11.1.
> Among the updates since 3.1.3, there have been two security-critical
> (including the medium CVE-2023-35936. Security fixes are in 3.1.4 & 3.1.6).
>
> The actual risk is limited, but these should be updated nevertheless.
>
> Does anyone know how to reach him by other means?
>
> Regards,
> Chris
>
>
>  Forwarded Message 
> Subject: Fedora package "pandoc" outdated and contains security
> vulnerability
> Date: Thu, 1 Feb 2024 15:55:09 +0100
> From: py0...@posteo.net
> To: peter...@fedoraproject.org
>
> Hi petersen,
>
> I am reaching out because of the package "pandoc", which you maintain.
>
> I have seen that the package is still at version 3.1.3 [1] when I tried
> to install it with dnf, whereas the current version is 3.1.11.1 [2]: is
> this intended or an accident?
>
> It has to be noted that the updates that have been added in the meantime
> contain fixes for security vulnerabilities (at least CVE-2023-35936; I have
> just roughly skimmed the changelogs). So at the moment, it seems the Fedora
> build can be exploited by attackers in some circumstances [3] [4] because
> it is still at 3.1.3.
>
> Regards & thanks for maintaining,
>
> Chris
>
> [1] https://koji.fedoraproject.org/koji/packageinfo?packageID=11560
>
> [2] https://hackage.haskell.org/package/pandoc &https://github.com/jgm/pandoc
>
> [3] https://github.com/jgm/pandoc/releases?page=1
>
> [4] https://github.com/jgm/pandoc/releases?page=2
>
> --
> ___
> 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
>
>
> --
> ___
> 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: 
> 

Re: Need help with incompatible pointer types on i686

[Elliott Sales de Andrade]

On Thu, Feb 15, 2024 at 11:39 PM Orion Poplawski  wrote:
>
> We're hitting this with h5py on i686:
>
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
> ‘__pyx_f_4h5py_4defs_H5Dread_chunk’:
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error:
> passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type
> [-Wincompatible-pointer-types]
> 14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id,
> __pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf);
>|
>  ^~~
>|
>  |
>|
>  __pyx_t_5numpy_uint32_t * {aka long unsigned int *}
> In file included from /usr/include/hdf5.h:25,
>   from
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27,
>   from
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246:
> /usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka
> ‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’
> {aka ‘long unsigned int *’}
>   1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const
> hsize_t *offset, uint32_t *filters,
>|
>   ~~^~~
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
> ‘__pyx_f_4h5py_4defs_H5Pget_driver_info’:
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning:
> assignment discards ‘const’ qualifier from pointer target type
> [-Wdiscarded-qualifiers]
> 31935 |   __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id);
>| ^
>
>
> It seems that numpy is defining a uint32_t type as long unsigned int on
> i686, while glibc(?) is defining it as unsigned int.

Yes, looking at NumPy's header [1], it appears to check `long` first,
then `long long`, then `int`, then `short`, and assigns the first one
that matches to the matching bit-length. So it should pick unsigned
long for npy_uint32 before unsigned int if they are both 4 bytes wide.

>  Now what puzzles
> me a little is that on i686 aren't these both 4-byte integers and no not
> incompatible at all?

Yes, I think they are the same size, as demonstrated on a 32-bit mock:
```
#include 
#include 
int main(void) {
printf("npy_uint32: %u\nunsigned int: %u\nunsigned long:
%u\nunsigned long long: %u\n",
   sizeof(npy_uint32), sizeof(unsigned int), sizeof(unsigned
long), sizeof(unsigned long long));

return 0;
}
```
prints out:
```
npy_uint32: 4
unsigned int: 4
unsigned long: 4
unsigned long long: 8
```

> What should be done here?
>

I guess that depends on how glibc sets things up, but perhaps it would
work better if NumPy checked from smallest to largest as defined in C
(short -> int -> long -> long long)?

[1] 
https://github.com/numpy/numpy/blob/308273e94bcf49980be9d5ded2b0ff5b4dd3a897/numpy/_core/include/numpy/npy_common.h#L488
--
___
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

Need help with incompatible pointer types on i686

[Orion Poplawski]

We're hitting this with h5py on i686:

/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function 
‘__pyx_f_4h5py_4defs_H5Dread_chunk’:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error: 
passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type 
[-Wincompatible-pointer-types]
14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id, 
__pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf);
  | 
^~~
  | 
|
  | 
__pyx_t_5numpy_uint32_t * {aka long unsigned int *}

In file included from /usr/include/hdf5.h:25,
 from 
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27,
 from 
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246:
/usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka 
‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’ 
{aka ‘long unsigned int *’}
 1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const 
hsize_t *offset, uint32_t *filters,
  | 
 ~~^~~
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function 
‘__pyx_f_4h5py_4defs_H5Pget_driver_info’:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning: 
assignment discards ‘const’ qualifier from pointer target type 
[-Wdiscarded-qualifiers]

31935 |   __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id);
  | ^


It seems that numpy is defining a uint32_t type as long unsigned int on 
i686, while glibc(?) is defining it as unsigned int.  Now what puzzles 
me a little is that on i686 aren't these both 4-byte integers and no not 
incompatible at all?


What should be done here?

--
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: The semiannual "Transaction failed: Signature verification failed." exercise

[Kevin Fenzi]

On Thu, Feb 15, 2024 at 07:57:37PM +, Zbigniew Jędrzejewski-Szmek wrote:
> It's this time of the year again:
...
> 
> Could we please do something so that this doesn't happen?
> Dunno, generate and distribute the keys earlier so that mock
> and https://fedoraproject.org/fedora.gpg get updated _before_
> we need it?

That won't do it. We need mock to update it's config at exactly the same
moment a successfull rawhide compose completes and mirrors to whatever
mirror you are hitting. ;( 

We make keys a year ahead now. The f42 key is in fedora-release already.

> I know this subject comes up approx. twice a year (or once once for F21 ;) ),
> e.g. [2]. I know this can be "fixed" with some manual steps, but I posit
> that this should never occur in the first place.

I guess one possible solution would be for rpm to support multiple
signatures and koji to support writing out those rpms and then we could
sign new rawhide with both keys at least for a while. 

I guess I had that idea 7 years ago:
https://github.com/rpm-software-management/rpm/issues/189

Or I suppose we could move to just one key for everything, but then it
would have a larger effect if we ever had to revoke/reissue. 

At the very least, perhaps mock could try and identify this problem and
note to upgrade mock-core-configs?

Dunno. I agree it's not good, but it's not easy to solve either. 

kevin


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

Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Kevin Kofler via devel]

Michael J Gruber wrote:
> chmod +x'ing should be fine on Fedoras, as well.

It used to be mandatory, even, exactly because of the dependency generator 
requiring it back then. Nowadays, you will get away with both +x or -x.

The idea that shared libraries should not be executable comes from Debian, 
which made that a requirement after someone tried to execute a shared 
library and it would just crash with a segfault or something, then blaming 
Debian for the "broken executable". So the Debian packagers would file bugs 
against build system maintainers and the build systems would try to 
implement this then, breaking things for Fedora in the process. (E.g., we 
had that issue with CMake.) So then Fedora packagers would file bugs 
requesting that this be reverted, and upstreams would either just give up 
and arbitrarily decide for one or the other approach, or do what CMake did 
and make this configurable (and CMake even tries to auto-detect the distro 
and set the default for the option accordingly).

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: Bisecting an older kernel

[Justin Forbes]

On Mon, Feb 12, 2024 at 7:49 AM Julian Sikorski  wrote:
>
> Am 12.02.24 um 10:03 schrieb Michael J Gruber:
> > Am So., 11. Feb. 2024 um 23:14 Uhr schrieb Julian Sikorski 
> > :
> >>
> >> Hello,
> >>
> >> I am trying to bisect an issue which appears to have regressed between
> >> 5.18 final and 5.19-rc2. This is somewhat challenging as most of the
> >> kernels are since gone from koji, and the ark os-build branch seems to
> >> have been rebased after kernel 6.7 release, meaning that the required
> >> commits to the redhat folder are not in sync with the commits to the
> >> kernel itself.
> >
> > I'm not sure I'm following this completely - are you saying that (part
> > of) the old kernel sources are not there (in git) any more because a
> > branch got rebased?
>
> Well the commits are there in the os-build branch, but they got rebased
> on top of 6.7. This means that they are no longer in sync with upstream
> kernel commits from the 5.19-rc0 timeframe.
> In the meantime I was able to learn that the correct order is still
> present in the tags:
>
> $ git bisect good kernel-5.19.0-0.rc0.fdaf9a5840ac.1
> $ git bisect bad kernel-5.19.0-0.rc0.babf0bb978e3.3
>
> I was able to recreate an "os-build-5.19" branch and am finally building
> a kernel now.
>
> >
> >> I tried cherry-picking them on top, but it does not apply
> >> cleanly either:
> >>
> >> $ git clone -b os-build g...@gitlab.com:cki-project/kernel-ark.git
> >> $ git bisect start
> >> $ git bisect bad v5.19-rc2
> >> $ git bisect good v5.18
> >> $ git checkout 2518f226c60d8e04d18ba4295500a5b0b8ac7659
> >> $ git cherry-pick
> >> 0dd3ee31125508cd67f7e7172247f05b7fd1753a..6d8a7e484dc667c1094fc90452dee6af30d509f6
> >>
> >> Is there a way simpler than trying to fix the cherry-pick conflicts
> >> every single time?
> >
> > `rerere` can be really helpful for something like this.
> >
> I will have a look if I get stuck again, thanks!
>
> > I guess you've checked already whether the problem you're trying to
> > solve depends on the extra redhat commits.
>
> I don't think so, there are redhat kernels which both do and do not work.
>

We do rebase the os-build branch, but I would strongly recommend doing
a bisect on Linus' tree (master in kernel-ark) just using the 5.19
config.  Doing bisects as rpms are massively time consuming and not
worth the effort.  If it were a redhat specific patch, you would know
that quickly because 5.19-rc2 from Linus' tree would be good instead
of bad.  In this case, we rarely carry to many patches in any area,
you could literally eyeball it and see which patch that we carry is
causing the issue.

Justin
--
___
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 need CONFIG_UPROBES=y in our kernels?

[Kevin Kofler via devel]

Roberto Ragusa wrote:
> Auditors are constantly proposing disabling features and making things
> inconvenient, undebuggable, inefficient and substantially annoying to
> operate.
>  
> They should instead learn some basic concepts of security.
> For example: if you are running a process, even in a VM or container, you
> have to trust the administrator of the host system. And that's it.

+1. Disabling important debugging tools in the name of "security" is a no 
go. Also goes for ptrace etc.

The worst invasive security nightmares actually come from the security folks 
themselves, e.g., auditd, which keeps a meticulous log of just about 
everything you do that the NSA (or other countries' equivalent) can 
conveniently read if they ever manage to compromise your computer. That 
contraption is one of the first things I disable on my computers!

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

Fedora 40 compose report: 20240215.n.1 changes

[Fedora Branched Report]

OLD: Fedora-40-20240213.n.1
NEW: Fedora-40-20240215.n.1

= SUMMARY =
Added images:3
Dropped images:  11
Added packages:  1
Dropped packages:5
Upgraded packages:   170
Downgraded packages: 0

Size of added packages:  4.73 MiB
Size of dropped packages:4.04 MiB
Size of upgraded packages:   2.20 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-40-20240215.n.1.iso
Image: KDE raw-xz aarch64
Path: Spins/aarch64/images/Fedora-KDE-40-20240215.n.1.aarch64.raw.xz
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-40-20240215.n.1.iso

= DROPPED IMAGES =
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-40.20240213.n.1.ociarchive
Image: Sericea ociarchive x86_64
Path: Sericea/x86_64/images/Fedora-Sericea-40.20240213.n.1.ociarchive
Image: Silverblue ociarchive ppc64le
Path: Silverblue/ppc64le/images/Fedora-Silverblue-40.20240213.n.1.ociarchive
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-40-20240213.n.1.iso
Image: Sericea ociarchive aarch64
Path: Sericea/aarch64/images/Fedora-Sericea-40.20240213.n.1.ociarchive
Image: Silverblue dvd-ostree x86_64
Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-40-20240213.n.1.iso
Image: Kinoite ociarchive x86_64
Path: Kinoite/x86_64/images/Fedora-Kinoite-40.20240213.n.1.ociarchive
Image: Silverblue ociarchive x86_64
Path: Silverblue/x86_64/images/Fedora-Silverblue-40.20240213.n.1.ociarchive
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-40-20240213.n.1.iso
Image: Kinoite ociarchive aarch64
Path: Kinoite/aarch64/images/Fedora-Kinoite-40.20240213.n.1.ociarchive
Image: Silverblue ociarchive aarch64
Path: Silverblue/aarch64/images/Fedora-Silverblue-40.20240213.n.1.ociarchive

= ADDED PACKAGES =
Package: python-cramjam-2.8.1-1.fc40
Summary: Thin Python bindings to de/compression algorithms in Rust
RPMs:python3-cramjam
Size:4.73 MiB


= DROPPED PACKAGES =
Package: ksysguard-5.22.0-10.fc39
Summary: KDE Process Management application
RPMs:ksysguard ksysguardd
Size:3.09 MiB

Package: rust-git2_0.13-0.13.25-6.fc40
Summary: Bindings to libgit2 for interoperating with git repositories
RPMs:rust-git2_0.13+default-devel rust-git2_0.13+https-devel 
rust-git2_0.13+openssl-probe-devel rust-git2_0.13+openssl-sys-devel 
rust-git2_0.13+ssh-devel rust-git2_0.13+ssh_key_from_memory-devel 
rust-git2_0.13+unstable-devel rust-git2_0.13-devel
Size:234.04 KiB

Package: rust-git2_0.14-0.14.4-3.fc40
Summary: Bindings to libgit2 for interoperating with git repositories
RPMs:rust-git2_0.14+default-devel rust-git2_0.14+https-devel 
rust-git2_0.14+openssl-probe-devel rust-git2_0.14+openssl-sys-devel 
rust-git2_0.14+ssh-devel rust-git2_0.14+ssh_key_from_memory-devel 
rust-git2_0.14+unstable-devel rust-git2_0.14+vendored-libgit2-devel 
rust-git2_0.14-devel
Size:241.65 KiB

Package: rust-git2_0.16-0.16.1-3.fc40
Summary: Bindings to libgit2 for interoperating with git repositories
RPMs:rust-git2_0.16+default-devel rust-git2_0.16+https-devel 
rust-git2_0.16+openssl-probe-devel rust-git2_0.16+openssl-sys-devel 
rust-git2_0.16+ssh-devel rust-git2_0.16+ssh_key_from_memory-devel 
rust-git2_0.16+unstable-devel rust-git2_0.16+vendored-libgit2-devel 
rust-git2_0.16-devel
Size:244.05 KiB

Package: rust-git2_0.17-0.17.2-2.fc40
Summary: Bindings to libgit2 for interoperating with git repositories
RPMs:rust-git2_0.17+default-devel rust-git2_0.17+https-devel 
rust-git2_0.17+openssl-probe-devel rust-git2_0.17+openssl-sys-devel 
rust-git2_0.17+ssh-devel rust-git2_0.17+ssh_key_from_memory-devel 
rust-git2_0.17+unstable-devel rust-git2_0.17+vendored-libgit2-devel 
rust-git2_0.17-devel
Size:248.74 KiB


= UPGRADED PACKAGES =
Package:  OpenMolcas-24.02-1.fc40
Old package:  OpenMolcas-23.10-3.fc40
Summary:  A multiconfigurational quantum chemistry software package
RPMs: OpenMolcas
Size: 65.46 MiB
Size change:  -732.98 KiB
Changelog:
  * Thu Feb 15 2024 Susi Lehtola  - 24.02-1
  - Update to 24.02.


Package:  RBTools-4.1-4.fc40
Old package:  RBTools-4.1-3.fc40
Summary:  Tools for use with ReviewBoard
RPMs: RBTools
Size: 893.88 KiB
Size change:  -45 B
Changelog:
  * Wed Feb 07 2024 Miro Hron??ok  - 4.1-4
  - Make tests pass even when pkg_resources emits DeprecationWarnings


Package:  annobin-12.40-1.fc40
Old package:  annobin-12.38-1.fc40
Summary:  Annotate and examine compiled binary files
RPMs: annobin-annocheck annobin-docs annobin-libannocheck 
annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm
Size: 5.35 MiB
Size change:  -7.35 KiB
Changelog:
  * Fri Feb 09 2024 Nick Clifron   - 12.39-1
  - Annocheck: Also skip

The semiannual "Transaction failed: Signature verification failed." exercise

[Zbigniew Jędrzejewski-Szmek]

It's this time of the year again:

Running transaction
Importing PGP key 0xA15B79CC:
 Userid : "Fedora (40) "
 Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC
 From   : 
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary
The key was successfully imported.
Importing PGP key 0xA15B79CC:
 Userid : "Fedora (40) "
 Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC
 From   : 
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary
The key was successfully imported.
Importing PGP key 0x18B8E74C:
 Userid : "Fedora (39) "
 Fingerprint: E8F23996F23218640CB44CBE75CF5AC418B8E74C
 From   : 
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary
The key was successfully imported.

Transaction failed: Signature verification failed.
PGP check for package "curl-8.6.0-6.fc40.x86_64" 
(/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/curl-8.6.0-6.fc40.x86_64.rpm)
 from repo "fedora" has failed: Import of the key didn't help, wrong key?

This message is from mock. It's one issue if mock fails, when you call
it from the command line, but this failure also causes CI fails.
And as everybody knows, flaky CI gets ignroed.

I very much want people to use Fedora for their CI, and in particular
rawhide, because it's great for testing with upstream software. But
it looks silly if we get such a major "security failure" twice a year [1].

Could we please do something so that this doesn't happen?
Dunno, generate and distribute the keys earlier so that mock
and https://fedoraproject.org/fedora.gpg get updated _before_
we need it?

I know this subject comes up approx. twice a year (or once once for F21 ;) ),
e.g. [2]. I know this can be "fixed" with some manual steps, but I posit
that this should never occur in the first place.

Zbyszek


[1] From 
https://github.com/systemd/systemd/actions/runs/7919159325/job/21619276641?pr=31338:

Running transaction
Importing PGP key 0xA15B79CC:
 Userid : "Fedora (40) "
 Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC
 From   : 
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
The key was successfully imported.

Transaction failed: Signature verification failed.
PGP check for package "filesystem-3.18-8.fc40.x86_64" 
(/var/cache/libdnf5/fedora-306b6523e9c8dc02/packages/filesystem-3.18-8.fc40.x86_64.rpm)
 from repo "fedora" has failed: Import of the key didn't help, wrong key?

Note that this is a test VM that was created specifically for this
test run, so there's no question of stale data or anything like that.


[2] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MFX2JDVANNEW7LWWIBBLYCN6DEPWHSXF/.
--
___
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: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

[Christopher Klooz]

On 14/02/2024 17.35, Michel Lind wrote:

As a pandoc user, I'm happy to help with any reviews. Is there a list
where this tends to get posted, apart from devel?

Thanks,

Michel


Once the package needs a review, the request should be found here: 
http://fedoraproject.org/PackageReviewStatus/


Details of the roles of "contributor" and "reviewer" in the "package 
review process" can be found here: 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/ 
(based upon its history, I expect this page is kept updated but I don't 
know for sure)


According to the elaboration, you need to be in the FAS packager group, 
even for reviews.



On Fri, Feb 09, 2024 at 11:26:33PM +0800, Jens-Ulrik Petersen wrote:

I should also have added there's an increasing amount of technical debt
with the pandoc packaging - I guess I need to beg people to help with
package reviews: also reminded of our packaging (review) streamlining
discussion from Flock last year.

Jens

On Fri, 9 Feb 2024, 23:23 Jens-Ulrik Petersen,  wrote:


Hello I am here - thanks for contacting me.

I was hoping to cover this as part of my F40 Change, but unfortunately I
haven't gotten to it, so the Change is now at risk of being deferred to F41.

Nevertheless I will see what I can do about this for F40: maybe a backport
can also be done for F39.

Next time you could also comment on the relevant bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1996301  - that would be
appreciated.

Thanks, Jens

PS Special thanks to Neal Gompa for pinging me in Matrix. 


On Fri, 9 Feb 2024, 20:05 Christopher Klooz,  wrote:


I cannot reach the maintainer petersen (see mail below): The package
"pandoc" remains at 3.1.3 in Fedora, but pandoc is already at 3.1.11.1.
Among the updates since 3.1.3, there have been two security-critical
(including the medium CVE-2023-35936. Security fixes are in 3.1.4 & 3.1.6).

The actual risk is limited, but these should be updated nevertheless.

Does anyone know how to reach him by other means?

Regards,
Chris


 Forwarded Message 
Subject: Fedora package "pandoc" outdated and contains security
vulnerability
Date: Thu, 1 Feb 2024 15:55:09 +0100
From:py0...@posteo.net
To:peter...@fedoraproject.org

Hi petersen,

I am reaching out because of the package "pandoc", which you maintain.

I have seen that the package is still at version 3.1.3 [1] when I tried
to install it with dnf, whereas the current version is 3.1.11.1 [2]: is
this intended or an accident?

It has to be noted that the updates that have been added in the meantime
contain fixes for security vulnerabilities (at least CVE-2023-35936; I have
just roughly skimmed the changelogs). So at the moment, it seems the Fedora
build can be exploited by attackers in some circumstances [3] [4] because
it is still at 3.1.3.

Regards & thanks for maintaining,

Chris

[1]https://koji.fedoraproject.org/koji/packageinfo?packageID=11560

[2]https://hackage.haskell.org/package/pandoc  &
https://github.com/jgm/pandoc

[3]https://github.com/jgm/pandoc/releases?page=1

[4]https://github.com/jgm/pandoc/releases?page=2

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


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



--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, 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: 

Re: do we need CONFIG_UPROBES=y in our kernels?

[Josh Stone]

On 2/13/24 7:36 AM, Jerry James wrote:
> On Mon, Feb 12, 2024 at 11:16 AM Marius Schwarz  
> wrote:
>> In a german developer blog article was the topic raised, that with
>> uprobes enabled, userland apps can i.e. circumvent tls security(and
>> other protections),
>> by telling the kernel to probe the function calls with the uprobes api.
>> As this enables i.e. the hosting system of a vm or container, to track
>> activity inside the container, trust is lost i.e. from customer to
>> hoster. To be fair, you need to be root on the host to do this, but as
>> it "wasn't possible before", and it is "now" ( out in a greater public
>> ), it tends to create trust issues, just for being there*.
>>
>> As this only works with uprobes enabled and has no use case besides a
>> developer debugging apps, the question is:
>>
>> Do we need this for all others out there enabled by default?
> 
> Both systemtap and bpftrace can use uprobes.  Those capabilities have
> been important from time to time in my job.  That does not mean that
> my ability to do my job should outweigh security concerns, of course,
> but I think some effort should be made to find out if use of uprobes
> via systemtap and bpftrace is common amongst Fedora users.

"perf probe" can also define events based on uprobes, which makes them
available to "perf record", "perf trace", etc.
--
___
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 2261448] perl-Curses: FTBFS in Fedora rawhide/f40

[bugzilla]

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



--- Comment #5 from Steve Traylen  ---
Hmm i686 build fails only:

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2261448

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202261448%23c5
--
___
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 2261448] perl-Curses: FTBFS in Fedora rawhide/f40

[bugzilla]

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

Steve Traylen  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value



--- Comment #4 from Steve Traylen  ---
Don't understand...

mock -r fedora-rawhide-x86_64 --install bash

...

Running transaction
Importing PGP key 0xA15B79CC:
 Userid : "Fedora (40) "
 Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC
 From   :
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary
The key was successfully imported.
Importing PGP key 0xA15B79CC:
 Userid : "Fedora (40) "
 Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC
 From   :
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary
The key was successfully imported.
Importing PGP key 0x18B8E74C:
 Userid : "Fedora (39) "
 Fingerprint: E8F23996F23218640CB44CBE75CF5AC418B8E74C
 From   :
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-39-primary
The key was successfully imported.

Transaction failed: Signature verification failed.
PGP check for package "tar-2:1.35-3.fc40.x86_64"
(/var/lib/mock/dnf5-test/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/tar-1.35-3.fc40.x86_64.rpm)
from repo "fedora" has failed: Import of the key didn't help, wrong key?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2261448

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202261448%23c4
--
___
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 2264388] F41FailsToInstall: perl-Code-TidyAll

[bugzilla]

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

Fedora Fails To Install  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WORKSFORME
Last Closed||2024-02-15 18:10:16



--- Comment #1 from Fedora Fails To Install  ---
Hello,

Please note that this comment was generated automatically by
https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at
https://pagure.io/releng/

All subpackages of a package against which this bug was filled are now
installable or removed from Fedora 41.

Thanks for taking care of it!


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264388

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264388%23c1
--
___
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 2264388] F41FailsToInstall: perl-Code-TidyAll

[bugzilla]

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

Bug 2264398 Summary: /usr/bin/node is gone
https://bugzilla.redhat.com/show_bug.cgi?id=2264398

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA




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

[Jens-Ulrik Petersen]

Thank you for looking into this, much appreciated,
since I hadn't found proper time yet.

It might be helpful to have a downstream ghc bug to track this too.

Jens
--
___
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: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Michael J Gruber]

Am Do., 15. Feb. 2024 um 17:43 Uhr schrieb Kalev Lember :
>
> On Thu, Feb 15, 2024 at 5:30 PM Michael J Gruber  
> wrote:
>>
>> Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against
>> the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch
>> builds for fc39 and el9 yields
>>
>> libmupdf.so.23.10()(64bit)
>>
>> in both cases. I could try and stuff %__elf_provides into the spec for
>> a koji scratch debug run ...
>
>
> Is libmupdf.so.23.10 executable? It used to be the case that the elf depgen 
> only ran on executable files, IIRC. Maybe that has changed in recent Fedoras, 
> but still is the case in el9?

Gotcha! You rock! Thanks a bunch.

chmod +x'ing should be fine on Fedoras, as well. And from looking at
/usr/lib64 it's common anyways.

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

Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Kalev Lember]

On Thu, Feb 15, 2024 at 5:30 PM Michael J Gruber 
wrote:

> Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against
> the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch
> builds for fc39 and el9 yields
>
> libmupdf.so.23.10()(64bit)
>
> in both cases. I could try and stuff %__elf_provides into the spec for
> a koji scratch debug run ...
>

Is libmupdf.so.23.10 executable? It used to be the case that the elf depgen
only ran on executable files, IIRC. Maybe that has changed in recent
Fedoras, but still is the case in el9?

-- 
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: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Michael J Gruber]

Am Do., 15. Feb. 2024 um 17:22 Uhr schrieb Petr Pisar :
>
> V Thu, Feb 15, 2024 at 05:10:34PM +0100, Michael J Gruber napsal(a):
> > Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar :
> > >
> > > V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> > > > Hi there
> > > >
> > > > I recently switched mupdf to shared libraries. During test builds on
> > > > COPR for EPEL I noticed a strange difference to fedora builds which I
> > > > can reproduce with koji scratch builds as well (epel9 vs fc39). The
> > > > difference is in the automatic provides for the -libs sub package:
> > > >
> > > > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> > > >
> > > > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> > > > mupdf-libs(x86-64) = 1.23.10-2.fc39
> > > >
> > > > And, of course, packages built against mupdf-devel automatically
> > > > require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> > > >
> > > > I even tested with `%ldconfig_scriptlets libs`, which makes no 
> > > > difference.
> > > >
> > > > Both packages have the same file contents including the lib, the
> > > > SONAME is `libmupdf.so.23.10`.
> > > >
> > > Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion 
> > > about
> > > rpmbuild not to generate provides and requires for a SONAME if the libary 
> > > is
> > > not installed into a standard library path.
> >
> > It's in /usr/lib64/ in both cases (x86_64, checked with
> > rpmdev-extract). spec part is:
> >
> Does running a dependency generator for ELF files on that file report the
> expected provides? Look at /usr/lib/rpm/fileattrs/elf.attr content. There
> should be a ".../elfdeps --provides" command for generating provides. Take
> that command and pass the library file as a possitional argument. An example:
>
> /usr/lib/rpm/elfdeps --provides /usr/lib64/libacl.so.1.1.2301
> libacl.so.1(ACL_1.0)(64bit)
> libacl.so.1(ACL_1.1)(64bit)
> libacl.so.1(ACL_1.1)(64bit)
> libacl.so.1(ACL_1.2)(64bit)
> libacl.so.1(ACL_1.2)(64bit)
> libacl.so.1()(64bit)

Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against
the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch
builds for fc39 and el9 yields

libmupdf.so.23.10()(64bit)

in both cases. I could try and stuff %__elf_provides into the spec for
a koji scratch debug run ...

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

Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Petr Pisar]

V Thu, Feb 15, 2024 at 05:10:34PM +0100, Michael J Gruber napsal(a):
> Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar :
> >
> > V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> > > Hi there
> > >
> > > I recently switched mupdf to shared libraries. During test builds on
> > > COPR for EPEL I noticed a strange difference to fedora builds which I
> > > can reproduce with koji scratch builds as well (epel9 vs fc39). The
> > > difference is in the automatic provides for the -libs sub package:
> > >
> > > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> > >
> > > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> > > mupdf-libs(x86-64) = 1.23.10-2.fc39
> > >
> > > And, of course, packages built against mupdf-devel automatically
> > > require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> > >
> > > I even tested with `%ldconfig_scriptlets libs`, which makes no difference.
> > >
> > > Both packages have the same file contents including the lib, the
> > > SONAME is `libmupdf.so.23.10`.
> > >
> > Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion 
> > about
> > rpmbuild not to generate provides and requires for a SONAME if the libary is
> > not installed into a standard library path.
> 
> It's in /usr/lib64/ in both cases (x86_64, checked with
> rpmdev-extract). spec part is:
>
Does running a dependency generator for ELF files on that file report the
expected provides? Look at /usr/lib/rpm/fileattrs/elf.attr content. There
should be a ".../elfdeps --provides" command for generating provides. Take
that command and pass the library file as a possitional argument. An example:

/usr/lib/rpm/elfdeps --provides /usr/lib64/libacl.so.1.1.2301
libacl.so.1(ACL_1.0)(64bit)
libacl.so.1(ACL_1.1)(64bit)
libacl.so.1(ACL_1.1)(64bit)
libacl.so.1(ACL_1.2)(64bit)
libacl.so.1(ACL_1.2)(64bit)
libacl.so.1()(64bit)

-- Petr


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

Re: Does splint work for anyone?

[Stephen Smoogen]

On Thu, 15 Feb 2024 at 10:15, David Cantrell  wrote:

> On 2/14/24 13:32, Stephen Smoogen wrote:
> >
> >
> > On Fri, 9 Feb 2024 at 17:17, Ian Laurie  > > wrote:
> >
> > On 2/10/24 05:06, Stephen Smoogen wrote:
> > >
> > > I was trying out the splint program on some code and found that it
> > > doesn't seem to work on any recent release due to changes in
> various
> > > header files
> > I tried using splint many years ago in connection with embedded
> > programming, and even though the GCC based embedded compiler I was
> using
> > was several major version numbers behind what was natively in
> Fedora, I
> > found splint to be hopelessly behind the times and utterly
> unusable.  I
> > don't know why it is even packaged in Fedora.
> >
> > I wish I had the skills necessary to bring it up to date but I don't.
> >
> >
> > Me too. I saw it is FTBFS in F40 and added my data
> > to https://bugzilla.redhat.com/show_bug.cgi?id=2261709
> > 
>
> I got it building and posted a PR:
> https://src.fedoraproject.org/rpms/splint/pull-request/1
>
> The upstream project went dormant in 2010, but there are some other
> semi-active forks.  I don't think that really matters.  The program
> itself could be useful for research and just as another tool in the
> toolbox for development.
>
>
Does it "work?" however.
```
[ssmoogen@toolbox phytool (fix_asprintf)]$ splint +posixlib phytool.c
Splint 3.1.2 --- 22 Jul 2023

/usr/include/asm-generic/int-ll64.h:20:24: Parse Error:
Suspect missing struct or union keyword: __signed__ :
int. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
```

Trying different flags, just got it to find even more 'parseerrors' on more
and more layers of header files. I could not find any combination of flags
which didn't result in the program not working with how our headers are
done in post Fedora 38 (my oldest system).



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


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Michael J Gruber]

Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar :
>
> V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> > Hi there
> >
> > I recently switched mupdf to shared libraries. During test builds on
> > COPR for EPEL I noticed a strange difference to fedora builds which I
> > can reproduce with koji scratch builds as well (epel9 vs fc39). The
> > difference is in the automatic provides for the -libs sub package:
> >
> > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> >
> > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> > mupdf-libs(x86-64) = 1.23.10-2.fc39
> >
> > And, of course, packages built against mupdf-devel automatically
> > require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> >
> > I even tested with `%ldconfig_scriptlets libs`, which makes no difference.
> >
> > Both packages have the same file contents including the lib, the
> > SONAME is `libmupdf.so.23.10`.
> >
> Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion about
> rpmbuild not to generate provides and requires for a SONAME if the libary is
> not installed into a standard library path.

It's in /usr/lib64/ in both cases (x86_64, checked with
rpmdev-extract). spec part is:

```
%files libs
%license COPYING
%{_libdir}/%{libname}.so.%{soname}
```

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

Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Petr Pisar]

V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> Hi there
> 
> I recently switched mupdf to shared libraries. During test builds on
> COPR for EPEL I noticed a strange difference to fedora builds which I
> can reproduce with koji scratch builds as well (epel9 vs fc39). The
> difference is in the automatic provides for the -libs sub package:
> 
> Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> 
> Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> mupdf-libs(x86-64) = 1.23.10-2.fc39
> 
> And, of course, packages built against mupdf-devel automatically
> require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> 
> I even tested with `%ldconfig_scriptlets libs`, which makes no difference.
> 
> Both packages have the same file contents including the lib, the
> SONAME is `libmupdf.so.23.10`.
> 
Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion about
rpmbuild not to generate provides and requires for a SONAME if the libary is
not installed into a standard library path.

-- Petr


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

Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Michael J Gruber]

Hi there

I recently switched mupdf to shared libraries. During test builds on
COPR for EPEL I noticed a strange difference to fedora builds which I
can reproduce with koji scratch builds as well (epel9 vs fc39). The
difference is in the automatic provides for the -libs sub package:

Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9

Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
mupdf-libs(x86-64) = 1.23.10-2.fc39

And, of course, packages built against mupdf-devel automatically
require ibmupdf.so.23.10()(64bit) and fail to install on *EL.

I even tested with `%ldconfig_scriptlets libs`, which makes no difference.

Both packages have the same file contents including the lib, the
SONAME is `libmupdf.so.23.10`.

Is there any special magic on *EL which I need to do for the provides?

Differences I noticed in build.log:

epel9 uses `cc` and has
lto-wrapper: warning: using serial compilation of 47 LTRANS jobs

fc39 uses `gcc` and has extra flags
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
-specs=/usr/lib/rpm/redhat/redhat-package-notes

Cheers
Michael

https://koji.fedoraproject.org/koji/taskinfo?taskID=113544172
https://koji.fedoraproject.org/koji/taskinfo?taskID=113544612
--
___
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: Modern C failures in Haskell stack

[Richard W.M. Jones]

On Thu, Feb 15, 2024 at 12:57:21PM +0100, Florian Weimer wrote:
> For the first issue, please try this GHC patch (only compile-tested with
> the stage 0 compiler build this point):
> 
> diff --git a/compiler/GHC/HsToCore/Foreign/C.hs 
> b/compiler/GHC/HsToCore/Foreign/C.hs
> index 2164ded112..8beaa8986e 100644
> --- a/compiler/GHC/HsToCore/Foreign/C.hs
> +++ b/compiler/GHC/HsToCore/Foreign/C.hs
> @@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty 
> is_IO_res_ty cc
>   ,   ppUnless res_hty_is_unit $
>   if libffi
>then char '*' <> parens (ffi_cResType <> char '*') <>
> -   text "resp = cret;"
> +   text "resp = " <> parens ffi_cResType <> text "cret;"
>else text "return cret;"
>   , rbrace
>   ]

Thanks, I tested this and it works.

I submitted it to GHC here:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12079

(Unfortunately to modify this you'll have to sign up to their gitlab
instance, which is very timeconsuming.)

Rich.

-- 
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: Does splint work for anyone?

[David Cantrell]

On 2/14/24 13:32, Stephen Smoogen wrote:
> 
> 
> On Fri, 9 Feb 2024 at 17:17, Ian Laurie  > wrote:
> 
> On 2/10/24 05:06, Stephen Smoogen wrote:
> >
> > I was trying out the splint program on some code and found that it
> > doesn't seem to work on any recent release due to changes in various
> > header files
> I tried using splint many years ago in connection with embedded
> programming, and even though the GCC based embedded compiler I was using
> was several major version numbers behind what was natively in Fedora, I
> found splint to be hopelessly behind the times and utterly unusable.  I
> don't know why it is even packaged in Fedora.
> 
> I wish I had the skills necessary to bring it up to date but I don't.
> 
> 
> Me too. I saw it is FTBFS in F40 and added my data
> to https://bugzilla.redhat.com/show_bug.cgi?id=2261709
> 

I got it building and posted a PR:
https://src.fedoraproject.org/rpms/splint/pull-request/1

The upstream project went dormant in 2010, but there are some other
semi-active forks.  I don't think that really matters.  The program
itself could be useful for research and just as another tool in the
toolbox for development.

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

[Bug 2264428] perl-Net-DNS-1.44 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Net-DNS-1.44-1.fc38.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=113543556


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264428

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264428%23c2
--
___
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 2264428] perl-Net-DNS-1.44 is available

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264428

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264428%23c1
--
___
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 2264428] New: perl-Net-DNS-1.44 is available

[bugzilla]

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

Bug ID: 2264428
   Summary: perl-Net-DNS-1.44 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-DNS
  Keywords: FutureFeature, Triaged
  Assignee: paul.wout...@aiven.io
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: ka...@ucw.cz, mspa...@redhat.com,
paul.wout...@aiven.io,
perl-devel@lists.fedoraproject.org, rstr...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.44
Upstream release that is considered latest: 1.44
Current version/release in rawhide: 1.43-1.fc40
URL: https://metacpan.org/dist/Net-DNS/

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264428

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264428%23c0
--
___
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: Why branched config pointed to rolling config?

[Sérgio Basto]

On Wed, 2024-02-14 at 15:38 +, Sérgio Basto wrote:
> On Wed, 2024-02-14 at 13:38 +, Mikhail Gavrilov wrote:
> > Why branched config pointed to rolling config?
> > # ls -ln | grep fedora-40
> > lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-aarch64.cfg ->
> > fedora-rawhide-aarch64.cfg
> > lrwxrwxrwx. 1 0 135   23 Jan 11 20:46 fedora-40-i386.cfg -> fedora-
> > rawhide-i386.cfg
> > lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-ppc64le.cfg ->
> > fedora-rawhide-ppc64le.cfg
> > lrwxrwxrwx. 1 0 135   24 Jan 11 20:46 fedora-40-s390x.cfg ->
> > fedora-
> > rawhide-s390x.cfg
> > lrwxrwxrwx. 1 0 135   25 Jan 11 20:46 fedora-40-x86_64.cfg ->
> > fedora-
> > rawhide-x86_64.cfg
> > 
> > I build every day mesa snapshot, but today `mock -r fedora-rawhide-
> > i386 ...` beginning create packages of 41 branch. And I can't fix
> > it
> > by `mock -r fedora-40-i386 ...` because 40 means rawhide now :(
> 
> we need update mock-core-configs, but is not yet available , I'm
> going
> check it with Fedora Build System group 

After update mock-core-configs with [1] the problem should be fixed 

[1]
dnf update --enablerepo=updates-testing --refresh mock-core-configs

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

Re: Modern C failures in Haskell stack

[Richard W.M. Jones]

I did a more thorough review of all the failed ghc-* packages by
submitting scratch builds for every one of them (starting from this
list: https://kojipkgs.fedoraproject.org/mass-rebuild/f40-failures.html).

It turns out that there is only one "class" of modern C failure,
of this form:

  /tmp/ghc167_0/ghc_8.c: In function 
‘zdreadlinezm1zi0zi3zi0zm5rmDmTTeacP6ZZL2WI5OaFEzdSystemziConsoleziReadlinezdreadlinezzm1zzi0zzi3zzi0zzm5rmDmTTeacP6L2WI5OaFEzuSystemzziConsolezziReadlinezuexportDequoter’:
  /tmp/ghc167_0/ghc_8.c:68:17: error:
   error: assignment to ‘ffi_arg’ {aka ‘long unsigned int’} from ‘HsPtr’ 
{aka ‘void *’} makes integer from pointer without a cast [-Wint-conversion]
 68 | *(ffi_arg*)resp = cret;
| ^
 |
  68 | *(ffi_arg*)resp = cret;
 | ^

I'll try Florian's suggested patch for ghc in a few minutes.

The other errors were not really related (except maybe OpenSSL ones).
They were:

* ghc-libxml-sax has non-generated code with missing headers

* ghc-th-orphans crashes ("Killed") during the build

* ghc-gi-gtk, ghc-gi-ostree seems to have a haskell code bug

* ghc-HsOpenSSL errors are significantly complex and need
  further investigation:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=113537596

Several packages actually built fine so I have submitted proper builds
for those.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Modern C failures in Haskell stack

[Jakub Jelinek]

On Thu, Feb 15, 2024 at 12:57:21PM +0100, Florian Weimer wrote:
> For the first issue, please try this GHC patch (only compile-tested with
> the stage 0 compiler build this point):
> 
> diff --git a/compiler/GHC/HsToCore/Foreign/C.hs 
> b/compiler/GHC/HsToCore/Foreign/C.hs
> index 2164ded112..8beaa8986e 100644
> --- a/compiler/GHC/HsToCore/Foreign/C.hs
> +++ b/compiler/GHC/HsToCore/Foreign/C.hs
> @@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty 
> is_IO_res_ty cc
>   ,   ppUnless res_hty_is_unit $
>   if libffi
>then char '*' <> parens (ffi_cResType <> char '*') <>
> -   text "resp = cret;"
> +   text "resp = " <> parens ffi_cResType <> text "cret;"
>else text "return cret;"
>   , rbrace
>   ]
> 
> I'm not even sure if there is a better fix for this.  Perhaps emitting a
> memcpy call to avoid the aliasing violation?

I thought it isn't an aliasing violation (though I only looked at the
diagnostics, nothing else), I thought the problem is that cret has some
pointer type and ffi_arg has integer type.  The above will work
if cret has non-pointer type (changes implicit conversion to explicit) but
with pointers still will emit a warning if say ffi_arg is 64-bit and pointers
are 32-bit or ffi_arg is 32-bit and pointers are 64-bit.
For that (ffi_arg) (uintptr_t) cret;
casts would be desirable, but one would need to find out if cret is a
pointer or not.

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: Modern C failures in Haskell stack

[Florian Weimer]

* Richard W. M. Jones:

> We noticed that some ghc-* packages FTBFS with Modern C failures eg
> these two picked at random:
>
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
>
> I think what's happening here is that ghc is generating C FFI code
> which is fed to GCC 14.  The code being generated is buggy.
>
> So probably the fix for this is just in ghc itself.  I looked at
> upstream ghc and wasn't able to identify any commits which fix this
> (except maybe
> https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
> But I didn't look especially hard and the code is very complicated.
>
> An alternative to fixing this in the compiler is to throw up our hands
> and add:
>
>   %global build_type_safety_c 0
>
> to every affected ghc-* package.

Please don't do this, it's unnecessary busy-work.

> eg This fixes ghc-readline:
>
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
>
> Any thoughts on this?

If GHC cannot be fixed properly, it should be trivial to teach it to
emit #pragma directives near the start of the generated files.  This is
what we currently do for Vala:



(The upstream submission has a Clang variant as well.)

Hopefully, GHC has a better understanding of the types and the control
flow of the code it generates than the Vala compiler, so this shouldn't
be necessary.

For the first issue, please try this GHC patch (only compile-tested with
the stage 0 compiler build this point):

diff --git a/compiler/GHC/HsToCore/Foreign/C.hs 
b/compiler/GHC/HsToCore/Foreign/C.hs
index 2164ded112..8beaa8986e 100644
--- a/compiler/GHC/HsToCore/Foreign/C.hs
+++ b/compiler/GHC/HsToCore/Foreign/C.hs
@@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty 
is_IO_res_ty cc
  ,   ppUnless res_hty_is_unit $
  if libffi
   then char '*' <> parens (ffi_cResType <> char '*') <>
-   text "resp = cret;"
+   text "resp = " <> parens ffi_cResType <> text "cret;"
   else text "return cret;"
  , rbrace
  ]

I'm not even sure if there is a better fix for this.  Perhaps emitting a
memcpy call to avoid the aliasing violation?

For the second build failure, GCC reports *genuine* bugs in the C code
in that package, leading to run-time crashes:

cbits/hslibxml-shim.c:44:21: error:
 warning: incompatible implicit declaration of built-in function ‘calloc’ 
[-Wbuiltin-declaration-mismatch]
   44 | user_data = calloc(1, sizeof(UserData));
  | ^~

That hasn't been valid C since 1986 or thereabouts.

As Jakub said, you really need to include the appropriate header files
to make this work.

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: Modern C failures in Haskell stack

[Richard W.M. Jones]

On Thu, Feb 15, 2024 at 12:24:22PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 15, 2024 at 11:13:08AM +, Richard W.M. Jones wrote:
> > We noticed that some ghc-* packages FTBFS with Modern C failures eg
> > these two picked at random:
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
> > 
> > I think what's happening here is that ghc is generating C FFI code
> > which is fed to GCC 14.  The code being generated is buggy.
> > 
> > So probably the fix for this is just in ghc itself.  I looked at
> > upstream ghc and wasn't able to identify any commits which fix this
> > (except maybe
> > https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
> > But I didn't look especially hard and the code is very complicated.
> > 
> > An alternative to fixing this in the compiler is to throw up our hands
> > and add:
> > 
> >   %global build_type_safety_c 0
> 
> Please don't if at all possible.
> 
> > to every affected ghc-* package.  eg This fixes ghc-readline:
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
> > 
> > Any thoughts on this?
> 
> The diagnostics is quite clear what needs to be done, in some cases
> #include , in others (uintptr_t) cast added when you want to
> assign a pointer to ffi_arg which is integral type.  Perhaps stdint.h
> include for that.

The problem isn't that we don't know how to change the code,
the problem is we need to work out where in the depths of GHC
to make the change.  Take a look for yourself:

https://github.com/ghc/ghc/blob/master/compiler/GHC/HsToCore/Foreign/C.hs

Rich.



>   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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Modern C failures in Haskell stack

[Jakub Jelinek]

On Thu, Feb 15, 2024 at 11:13:08AM +, Richard W.M. Jones wrote:
> We noticed that some ghc-* packages FTBFS with Modern C failures eg
> these two picked at random:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
> 
> I think what's happening here is that ghc is generating C FFI code
> which is fed to GCC 14.  The code being generated is buggy.
> 
> So probably the fix for this is just in ghc itself.  I looked at
> upstream ghc and wasn't able to identify any commits which fix this
> (except maybe
> https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
> But I didn't look especially hard and the code is very complicated.
> 
> An alternative to fixing this in the compiler is to throw up our hands
> and add:
> 
>   %global build_type_safety_c 0

Please don't if at all possible.

> to every affected ghc-* package.  eg This fixes ghc-readline:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
> 
> Any thoughts on this?

The diagnostics is quite clear what needs to be done, in some cases
#include , in others (uintptr_t) cast added when you want to
assign a pointer to ffi_arg which is integral type.  Perhaps stdint.h
include for that.

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

Modern C failures in Haskell stack

[Richard W.M. Jones]

We noticed that some ghc-* packages FTBFS with Modern C failures eg
these two picked at random:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
  https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602

I think what's happening here is that ghc is generating C FFI code
which is fed to GCC 14.  The code being generated is buggy.

So probably the fix for this is just in ghc itself.  I looked at
upstream ghc and wasn't able to identify any commits which fix this
(except maybe
https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
But I didn't look especially hard and the code is very complicated.

An alternative to fixing this in the compiler is to throw up our hands
and add:

  %global build_type_safety_c 0

to every affected ghc-* package.  eg This fixes ghc-readline:

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

Any thoughts on this?

Rich.

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

[Bug 2264268] F40FailsToInstall: perl-Alien-pkgconf

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |NEXTRELEASE
Last Closed||2024-02-15 10:15:33




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

Fedora rawhide compose report: 20240215.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240214.n.1
NEW: Fedora-Rawhide-20240215.n.0

= SUMMARY =
Added images:4
Dropped images:  12
Added packages:  3
Dropped packages:5
Upgraded packages:   122
Downgraded packages: 0

Size of added packages:  4.80 MiB
Size of dropped packages:4.04 MiB
Size of upgraded packages:   2.69 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20240215.n.0.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20240215.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20240215.n.0.iso
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240215.n.0.iso

= DROPPED IMAGES =
Image: Silverblue ociarchive x86_64
Path: Silverblue/x86_64/images/Fedora-Silverblue-Rawhide.20240214.n.1.ociarchive
Image: Kinoite ociarchive x86_64
Path: Kinoite/x86_64/images/Fedora-Kinoite-Rawhide.20240214.n.1.ociarchive
Image: Sericea ociarchive x86_64
Path: Sericea/x86_64/images/Fedora-Sericea-Rawhide.20240214.n.1.ociarchive
Image: Silverblue ociarchive aarch64
Path: 
Silverblue/aarch64/images/Fedora-Silverblue-Rawhide.20240214.n.1.ociarchive
Image: Kinoite ociarchive aarch64
Path: Kinoite/aarch64/images/Fedora-Kinoite-Rawhide.20240214.n.1.ociarchive
Image: Sericea ociarchive aarch64
Path: Sericea/aarch64/images/Fedora-Sericea-Rawhide.20240214.n.1.ociarchive
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20240214.n.1.ppc64le.tar.xz
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20240214.n.1.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20240214.n.1.iso
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20240214.n.1.iso
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-Rawhide.20240214.n.1.ociarchive
Image: Silverblue ociarchive ppc64le
Path: 
Silverblue/ppc64le/images/Fedora-Silverblue-Rawhide.20240214.n.1.ociarchive

= ADDED PACKAGES =
Package: golang-github-foxcpp-mockdns-1.1.0-1.fc41
Summary: Boilerplate for testing of code involving DNS lookups
RPMs:golang-github-foxcpp-mockdns-devel
Size:17.07 KiB

Package: golang-github-tidwall-gjson-1.17.0-1.fc41
Summary: Get JSON values quickly - JSON parser for Go
RPMs:golang-github-tidwall-gjson-devel
Size:45.67 KiB

Package: python-cramjam-2.8.1-1.fc41
Summary: Thin Python bindings to de/compression algorithms in Rust
RPMs:python3-cramjam
Size:4.73 MiB


= DROPPED PACKAGES =
Package: ksysguard-5.22.0-10.fc39
Summary: KDE Process Management application
RPMs:ksysguard ksysguardd
Size:3.09 MiB

Package: rust-git2_0.13-0.13.25-6.fc40
Summary: Bindings to libgit2 for interoperating with git repositories
RPMs:rust-git2_0.13+default-devel rust-git2_0.13+https-devel 
rust-git2_0.13+openssl-probe-devel rust-git2_0.13+openssl-sys-devel 
rust-git2_0.13+ssh-devel rust-git2_0.13+ssh_key_from_memory-devel 
rust-git2_0.13+unstable-devel rust-git2_0.13-devel
Size:234.04 KiB

Package: rust-git2_0.14-0.14.4-3.fc40
Summary: Bindings to libgit2 for interoperating with git repositories
RPMs:rust-git2_0.14+default-devel rust-git2_0.14+https-devel 
rust-git2_0.14+openssl-probe-devel rust-git2_0.14+openssl-sys-devel 
rust-git2_0.14+ssh-devel rust-git2_0.14+ssh_key_from_memory-devel 
rust-git2_0.14+unstable-devel rust-git2_0.14+vendored-libgit2-devel 
rust-git2_0.14-devel
Size:241.64 KiB

Package: rust-git2_0.16-0.16.1-3.fc40
Summary: Bindings to libgit2 for interoperating with git repositories
RPMs:rust-git2_0.16+default-devel rust-git2_0.16+https-devel 
rust-git2_0.16+openssl-probe-devel rust-git2_0.16+openssl-sys-devel 
rust-git2_0.16+ssh-devel rust-git2_0.16+ssh_key_from_memory-devel 
rust-git2_0.16+unstable-devel rust-git2_0.16+vendored-libgit2-devel 
rust-git2_0.16-devel
Size:244.05 KiB

Package: rust-git2_0.17-0.17.2-2.fc40
Summary: Bindings to libgit2 for interoperating with git repositories
RPMs:rust-git2_0.17+default-devel rust-git2_0.17+https-devel 
rust-git2_0.17+openssl-probe-devel rust-git2_0.17+openssl-sys-devel 
rust-git2_0.17+ssh-devel rust-git2_0.17+ssh_key_from_memory-devel 
rust-git2_0.17+unstable-devel rust-git2_0.17+vendored-libgit2-devel 
rust-git2_0.17-devel
Size:248.70 KiB


= UPGRADED PACKAGES =
Package:  arm-trusted-firmware-2.10.0-5.fc41
Old package:  arm-trusted-firmware-2.10.0-4.fc40
Summary:  ARM Trusted Firmware
RPMs: arm-trusted-firmware-armv8
Size: 176.36 KiB
Size change:  23.75 KiB
Changelog:
  * Tue Feb 13 2024 Peter Robinson  - 2.10.0-5
  - Add initial rk3588

Re: JACK rtprio=60, PipeWire rtprio=88: Why?

[Wim Taymans]

I think the main reason is that I was not aware of this policy and so we
chose some random numbers. The parameters are configurable at build time
and I can add these limits.

Wim

On Wed, Feb 14, 2024 at 7:30 PM Runiq via devel <
devel@lists.fedoraproject.org> wrote:

> Hey,
>
> I intend to pull the rtirq package [1] back into this decade and
> realized there's a discrepancy between the priorities of JACK and
> PipeWire realtime threads.
>
> JACK's is at 60, per the decision made in Fedora 17 [2]:
>
> ```
> $ ps -p 109009 -Lo tid,class,pri,rtprio,command
>
>  TID CLS PRI RTPRIO COMMAND
>   109009 TS   19  - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
>   109023 TS   19  - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
>   109024 TS   19  - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
>   109025 FF   60 20 jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
>   109026 TS   19  - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
> ```
>
> Accordingly, the jackuser group rtprio limit is set to 70:
>
> ```
> # /etc/security/limits.d/95-jack.conf
> @jackuser - rtprio 70
> @jackuser - memlock 4194304
>
> @pulse-rt - rtprio 20
> @pulse-rt - nice -20
> ```
>
> On the other hand, PipeWire's realtime thread runs with prio 88:
>
> ```
> $ ps -p 4453 -Lo tid,class,pri,rtprio,command
>  TID CLS PRI RTPRIO COMMAND
> 4453 TS   30  - /usr/bin/pipewire
> 4460 FF  128 88 /usr/bin/pipewire
> ```
>
> And the group gets an rtprio limit of 95:
>
> ```
> # /etc/security/limits.d/25-pw-rlimits.conf
> @pipewire   - rtprio  95
> @pipewire   - nice-19
> @pipewire   - memlock 4194304
> ```
>
> Is there a reason for this discrepancy? Apart from the already mentioned
> email acknowledging the policy change in Fedora 17 [2], I couldn't find
> anything else about that. Since both Pipewire and JACK fill similar
> roles, I would have expected them to both have similar rtprio values.
>
> I've also posted this to Ask Fedora [3].
>
> Best regards,
> Patrice
>
> [1] https://src.fedoraproject.org/rpms/rtirq
> [2]
> https://cm-mail.stanford.edu/pipermail/planetccrma/2012-May/018018.html
> [3] https://discussion.fedoraproject.org/t/105188
> --
> ___
> 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 2264388] F41FailsToInstall: perl-Code-TidyAll

[bugzilla]

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

Miro Hrončok  changed:

   What|Removed |Added

 Depends On||2264398





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2264398
[Bug 2264398] /usr/bin/node is gone
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264388
--
___
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 2264268] F40FailsToInstall: perl-Alien-pkgconf

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-Alien-pkgconf-0.19-8.f
   ||c40
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264268
--
___
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 2264388] New: F41FailsToInstall: perl-Code-TidyAll

[bugzilla]

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

Bug ID: 2264388
   Summary: F41FailsToInstall: perl-Code-TidyAll
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Code-TidyAll
  Assignee: jples...@redhat.com
  Reporter: fti-b...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 2260877 (F41FailsToInstall,RAWHIDEFailsToInstall)
  Target Milestone: ---
Classification: Fedora



Hello,

Please note that this comment was generated automatically by
https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at
https://pagure.io/releng/

Your package (perl-Code-TidyAll) Fails To Install in Fedora 41:

can't install perl-Code-TidyAll:
  - nothing provides nodejs needed by perl-Code-TidyAll-0.84-3.fc40.noarch

If you know about this problem and are planning on fixing it, please
acknowledge so by setting the bug status to ASSIGNED. If you don't have time to
maintain this package, consider orphaning it, so maintainers of dependent
packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs
(https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/),
your package may be orphaned in 8+ weeks.


P.S. The data was generated solely from koji buildroot, so it might be newer
than the latest compose or the content on mirrors. To reproduce, use the
koji/local repo only, e.g. in mock:

$ mock -r fedora-41-x86_64 --config-opts mirrored=False install
perl-Code-TidyAll


P.P.S. If this bug has been reported in the middle of upgrading multiple
dependent packages, please consider using side tags:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2260877
[Bug 2260877] Fedora 41 Fails To install Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264388

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264388%23c0
--
___
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 2264260] F41FailsToInstall: perl-Alien-pkgconf

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |CLOSED
 Resolution|--- |DUPLICATE
Last Closed||2024-02-15 08:50:10



--- Comment #1 from Petr Pisar  ---


*** This bug has been marked as a duplicate of bug 2264268 ***


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264260

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264260%23c1
--
___
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 2264268] F40FailsToInstall: perl-Alien-pkgconf

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||2260877
   ||(F41FailsToInstall,RAWHIDEF
   ||ailsToInstall)



--- Comment #1 from Petr Pisar  ---
*** Bug 2264260 has been marked as a duplicate of this bug. ***



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2260877
[Bug 2260877] Fedora 41 Fails To install Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264268

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264268%23c1
--
___
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