Re: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

[Michel Lind]

On Thu, Feb 15, 2024 at 07:53:38PM +, 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.
> 
Thanks. I'm a long term packager so I know about these already ;)

Was just wondering if there's another place where Haskell packaging is
coordinated.

-- 
Michel Lind
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: Proposing a Fedora SIG for the upcoming COSMIC desktop environment

[Michel Lind]

Hello and welcome!

On Fri, Feb 16, 2024 at 08:59:49PM -, Ryan Brue wrote:
> Hello all! This is my first time using a mailing list, but I want to do this 
> more often in the future :)
> 
> 
> If you happen to like rust, or are simply excited to see another desktop 
> environment join the space, share your interest!
> If there is enough interest, I would suggest we then create a matrix group, 
> similar to what the Fedora KDE SIG has. I believe the KDE SIG uses an IRC 
> bridge as well, for those interested in using IRC.

Happy to join the Matrix room when it's created! Can't commit to being
that involved, but it seems like there's going to be a lot of overlap on
the packaging side with the Rust SIG I'm already in (Rust crates in
Fedora are all co-maintained by the SIG) so feel free to drop in and ask
questions at #rust:fedoraproject.org

Best regards,

-- 
Michel Lind
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: Proposing a Fedora SIG for the upcoming COSMIC desktop environment

[Ryan Brue]

> We do not use IRC for Fedora KDE at all.

My bad! I must be thinking about the generic KDE matrix instance. There is a 
"KDE Libera chat IRC Bridge".
--
___
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

2024-02-19 @ 17:00 UTC - Fedora 40 Blocker Review Meeting

[Adam Williamson]

# F40 Blocker Review meeting
# Date: 2024-02-19
# Time: 17:00 UTC
# Location:
https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org

Hi folks! It's time for another blocker review meeting. We have 6
proposed blockers and 1 proposed freeze exception for Beta, and 4
proposed blockers for Final.

The meeting will be on Matrix, as we're trying to move to more modern
systems and the meeting bot is working on Matrix now. Click the link
above to join in a web client - you can authenticate with your FAS
account - or use a dedicated client of your choosing.

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F40 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria

-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

[Test-Announce] 2024-02-19 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2024-02-19
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location:
https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org

Greetings testers! It's meeting time again, and once again we'll
be on Matrix.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 40 status, including anaconda web UI test planning
3. Test Day / community event status
4. Open floor
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

[Test-Announce] 2024-02-19 @ 17:00 UTC - Fedora 40 Blocker Review Meeting

[Adam Williamson]

# F40 Blocker Review meeting
# Date: 2024-02-19
# Time: 17:00 UTC
# Location:
https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org

Hi folks! It's time for another blocker review meeting. We have 6
proposed blockers and 1 proposed freeze exception for Beta, and 4
proposed blockers for Final.

The meeting will be on Matrix, as we're trying to move to more modern
systems and the meeting bot is working on Matrix now. Click the link
above to join in a web client - you can authenticate with your FAS
account - or use a dedicated client of your choosing.

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F40 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4a6bba707d   
libmodsecurity-3.0.12-1.el7


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

ascii-3.20-1.el7

Details about builds:



 ascii-3.20-1.el7 (FEDORA-EPEL-2024-148b3d3023)
 Interactive ascii name and synonym chart

Update Information:

Update from upstream

ChangeLog:

* Fri Feb 16 2024 Didier Fabert  - 3.20-1
- Update to 3.20 version

References:

  [ 1 ] Bug #2264550 - ascii-3.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2264550


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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-34c7addedb   
chromium-121.0.6167.160-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4d3eb328e3   
libmodsecurity-3.0.12-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-10430622fd   
syncthing-1.27.3-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0b7ba715af   
pdns-recursor-4.8.6-1.el8


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

ascii-3.20-1.el8
lexertl14-0.1.0-21.20240216git7a365a2.el8
libmongocrypt-1.9.0-1.el8
mock-5.5-1.el8
mock-core-configs-40.2-1.el8
python-treq-20.4.1-1.el8
python-virt-firmware-24.2-1.el8

Details about builds:



 ascii-3.20-1.el8 (FEDORA-EPEL-2024-734f899efe)
 Interactive ascii name and synonym chart

Update Information:

Update from upstream

ChangeLog:

* Fri Feb 16 2024 Didier Fabert  - 3.20-1
- Update to 3.20 version

References:

  [ 1 ] Bug #2264550 - ascii-3.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2264550




 lexertl14-0.1.0-21.20240216git7a365a2.el8 (FEDORA-EPEL-2024-08b49cccda)
 The Modular Lexical Analyser Generator

Update Information:

Update to 0.1.0^20240216git7a365a2

ChangeLog:

* Fri Feb 16 2024 Benjamin A. Beasley  - 0.1.0-21
- Update to 0.1.0^20240216git7a365a2
* Fri Feb 16 2024 Benjamin A. Beasley  - 0.1.0-20
- Keep timestamps when converting text file line endings
* Fri Feb 16 2024 Benjamin A. Beasley  - 0.1.0-19
- Update to c045058 (multilib fixed upstream)




 libmongocrypt-1.9.0-1.el8 (FEDORA-EPEL-2024-c96deabbe8)
 The companion C library for client side encryption in drivers

Update Information:

Version 1.9.0
New features
Support named KMS providers.

ChangeLog:

* Fri Feb 16 2024 Remi Collet  - 1.9.0-1
- update to 1.9.0




 mock-5.5-1.el8 (FEDORA-EPEL-2024-e9e1b2dad6)
 Builds packages inside chroots

Update Information:

https://rpm-software-management.github.io/mock/Release-Notes-5.5
https://rpm-software-management.github.io/mock/Release-Notes-Configs-40.2

ChangeLog:

* Wed Feb 14 2024 Pavel Raiskup 
- allow chroot_scan to create archive instead of directory (tkope...@redhat.com)
- handle greedy options in Bash completion
- fix root_cache invalidation (not) triggered by config changes
- new '{{ repo_arch }}' Jinja2 template support
- package_manager: disable %-interpolation in dnf.conf parser
- only `chown` the in-chroot home files with the --rebuild mode
- all non-privileged actions performed wiht EGID=135 (mock group)
- mock newly requires a precise version of mock-filesystem
- allow shadow-utils to run in buildroot by exception if necessary 
(martj...@redhat.com)
- hw_info now reports file system type (vondr...@redhat.com)




 mock-core-configs-40.2-1.el8 (FEDORA-EPEL-2024-e9e1b2dad6)
 Mock core config files basic chroots

Update Information:

https://rpm-software-management.github.io/mock/Release-Notes-5.5
https://rpm-software-management.github.io/mock/Release-Notes-Configs-40.2

ChangeLog:

* Fri Feb 16 2024 Pavel Raiskup  40.2-1
- Use dnf5 on Fedora 40+ (m...@hroncok.cz)
* Wed Feb 14 2024 Pavel Raiskup  40.1-1
- new '{{ repo_arch }}' template variable used for Mageia
- Mageia 7 is EOL (wa...@mageia.org)
- OpenMandriva i686 is EOL (fros...@email.cz)
- Fedora 40 branched

[Bug 2222638] F39FailsToInstall: perl-Tk

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |ERRATA
   Fixed In Version||perl-Tk-804.036-13.fc39



--- Comment #9 from Fedora Update System  ---
FEDORA-2024-b6f0e855b0 (perl-Tk-804.036-13.fc39) has been pushed to the Fedora
39 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20638%23c9
--
___
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: Need help with incompatible pointer types on i686

[Orion Poplawski]

On 2/16/24 01:29, Michael J Gruber wrote:

Am Fr., 16. Feb. 2024 um 07:15 Uhr schrieb 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:


They are the same (bit size, signedness, general type) but not equal
(long int vs int), and with gcc14 this became an error. I"m sure it
always warned about that before.


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


numpy definitely needs to fix this. You cannot just go by bitsize and
signedness. You never could and now you can't ;)
I'm surprised this didn't come up during our "gcc 14 ride".

Michael


Could you or someone else knowledgeable here file a bug with numpy?  I'm 
sick at the moment and not sure I can articulate what needs to get done.


Thank you!

--
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: temp symlink while building spec file?

[Richard W.M. Jones]

On Fri, Feb 16, 2024 at 12:22:45PM -0600, Ron Olson wrote:
> Hi all-
> 
> Since Apple released Swift 5.9 it requires a previous version of Swift to 
> build; it seems it can’t be built from scratch anymore just using the source. 
> To make it more complicated, during compiling it’s expected that certain 
> libraries are available specifically at /usr/lib/swift. In a container, I can 
> symlink the necessary directory with “ln -s 
> /usr/libexec/swift/5.8.1/lib/swift /usr/lib/swift” and Swift builds fine.
> 
> This doesn’t work with Mock and I’m trying to think of a way to build Swift 
> without introducing more patches; I’ve been able to create a patch that 
> changes the directory it’s looking for, but at the cost of compile errors 
> later on.
> 
> Might anyone have a suggestion about what can be done within mock to minimize 
> the changes needed to the source? I’m really hoping to avoid adding any more 
> patches as I feel there’s already too many (8!) just to make it build 
> successfully.

An LD_PRELOAD hack perhaps?  Ugly but it would avoid source changes.

I think the best plan is to just fix the source however ...  Can't you
persuade them to at least make $libdir configurable during the build?

Rich.

> I was wondering if I could submit a newer version of 5.8.1 with the symlink 
> as part of the rpm so that it would be available going forward. This seems 
> like the “safest” option, but before doing that I was wondering if there was 
> a specific thing that allows this in Mock that I’m just not aware of.
> 
> Thanks for any info!
> 
> Ron
> --
> ___
> 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-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
___
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: SoPlex and SCIP review swaps

[Jerry James]

On Mon, Feb 12, 2024 at 11:11 AM Jerry James  wrote:
> On Wed, Dec 6, 2023 at 3:10 PM Jerry James  wrote:
> > I need reviews for the following new packages.  I am willing to swap 
> > reviews.
> > - asl: https://bugzilla.redhat.com/show_bug.cgi?id=2253354
> > - ccluster: https://bugzilla.redhat.com/show_bug.cgi?id=2253355
> > - lusol: https://bugzilla.redhat.com/show_bug.cgi?id=2253356
> > - pdqsort: https://bugzilla.redhat.com/show_bug.cgi?id=2253357
> > - zimpl: https://bugzilla.redhat.com/show_bug.cgi?id=2253358
> > - zstr: https://bugzilla.redhat.com/show_bug.cgi?id=2253359
> > - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360
> > - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361
> > - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362
> > - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363
> > - spasm: https://bugzilla.redhat.com/show_bug.cgi?id=2253364
>
> Just a few package reviews to go!  This is what remains to be done:
>
> - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360
> - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361
> - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362
> - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363
>
> These will need to be reviewed with respect to the [COPR mentioned
> above](https://copr.fedorainfracloud.org/coprs/jjames/SCIP/), since I
> can't build asl in Rawhide without breaking the existing mp package,
> so the rest all has to be done at once in a side tag.
>
> Let me know what I can review for you in exchange for the above reviews.

Thanks to Benson Muite, papilo has been reviewed and soplex is under
review.  I still need reviewers for scip and coin-or-HiGHS.  If you
don't have a package that needs review right now, I can give you a
rain check, or I can do some other task for you.
-- 
Jerry James
http://www.jamezone.org/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposing a Fedora SIG for the upcoming COSMIC desktop environment

[Neal Gompa]

On Fri, Feb 16, 2024 at 4:00 PM Ryan Brue  wrote:
>
> Hello all! This is my first time using a mailing list, but I want to do this 
> more often in the future :)
>
> System76, makers of Linux computers and creators of Pop!_OS are currently 
> working on a desktop environment entirely built in rust, called COSMIC. 
> (https://github.com/pop-os/cosmic-epoch). They use and contribute to a lot of 
> base Linux development components written in rust, including:
> Smithay: A wayland compositor library https://github.com/Smithay/smithay
> Iced: A GUI library https://github.com/iced-rs/iced
> WGPU: A graphics library https://github.com/gfx-rs/wgpu
> ZBus: A rust D-Bus crate https://github.com/dbus2/zbus
>
> I have been closely following its development and I am even dipping my toes 
> in rust for the first time to help contribute to its development.
>
> I happen to enjoy Fedora quite a bit, and I use Silverblue on my main machine 
> myself, but in order to try COSMIC in its current state (and to create a test 
> environment for my code changes) I started creating Fedora atomic images with 
> the COSMIC desktop environment installed (see: 
> https://github.com/ryanabx/fedora-cosmic-atomic). The image is very 
> primitive, and simply compiles COSMIC components and puts the files where 
> they need to be in their various directories, no RPM packaging involved at 
> this phase.
>
> I would like to gauge interest in creating a COSMIC SIG for Fedora. The 
> initial major goals of such a group would be:
>
> * Creating RPM packaging for COSMIC's components
> * Laying out a plan for and promoting a Fedora COSMIC Spin
> * Contributing to COSMIC development (for those interested, of course nothing 
> is required)
> * Creating an accompanying Fedora COSMIC Atomic variant
>
> If you happen to like rust, or are simply excited to see another desktop 
> environment join the space, share your interest!

This sounds great!

> If there is enough interest, I would suggest we then create a matrix group, 
> similar to what the Fedora KDE SIG has. I believe the KDE SIG uses an IRC 
> bridge as well, for those interested in using IRC.

We do not use IRC for Fedora KDE at all.



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

Proposing a Fedora SIG for the upcoming COSMIC desktop environment

[Ryan Brue]

Hello all! This is my first time using a mailing list, but I want to do this 
more often in the future :)

System76, makers of Linux computers and creators of Pop!_OS are currently 
working on a desktop environment entirely built in rust, called COSMIC. 
(https://github.com/pop-os/cosmic-epoch). They use and contribute to a lot of 
base Linux development components written in rust, including:
Smithay: A wayland compositor library https://github.com/Smithay/smithay
Iced: A GUI library https://github.com/iced-rs/iced
WGPU: A graphics library https://github.com/gfx-rs/wgpu
ZBus: A rust D-Bus crate https://github.com/dbus2/zbus

I have been closely following its development and I am even dipping my toes in 
rust for the first time to help contribute to its development.

I happen to enjoy Fedora quite a bit, and I use Silverblue on my main machine 
myself, but in order to try COSMIC in its current state (and to create a test 
environment for my code changes) I started creating Fedora atomic images with 
the COSMIC desktop environment installed (see: 
https://github.com/ryanabx/fedora-cosmic-atomic). The image is very primitive, 
and simply compiles COSMIC components and puts the files where they need to be 
in their various directories, no RPM packaging involved at this phase.

I would like to gauge interest in creating a COSMIC SIG for Fedora. The initial 
major goals of such a group would be:

* Creating RPM packaging for COSMIC's components
* Laying out a plan for and promoting a Fedora COSMIC Spin
* Contributing to COSMIC development (for those interested, of course nothing 
is required)
* Creating an accompanying Fedora COSMIC Atomic variant

If you happen to like rust, or are simply excited to see another desktop 
environment join the space, share your interest!
If there is enough interest, I would suggest we then create a matrix group, 
similar to what the Fedora KDE SIG has. I believe the KDE SIG uses an IRC 
bridge as well, for those interested in using IRC.
--
___
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: Restore dmz-cursor-themes

[Jerry James]

Hi Fabrice,

On Fri, Feb 16, 2024 at 4:43 AM Fabrice  wrote:
> Hi!
>
> I would like to become the maintainer of dmz-cursor-themes.
> https://src.fedoraproject.org/rpms/dmz-cursor-themes
>
> I would like to push an update from Debian, v0.4.5.1.

Thank you for your interest in this package.  Since it has been
retired for more than 8 weeks, it will need to be reviewed as
described here:

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

Are you currently a Fedora packager?  If not, you will need to follow
the procedure described here:

https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/

Feel free to ask questions or ask for help on this mailing list or on
https://discussion.fedoraproject.org/.

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

[EPEL-devel] Re: RFC: updating python-poetry-core in EPEL 9 to 1.6.1

[Michel Lind]

On Fri, Feb 16, 2024 at 01:27:18PM -0600, Michel Lind wrote:
> except for python-asyncmy: 
> https://copr.fedorainfracloud.org/coprs/salimma/poetry-core-epel9-wip/build/7026743/
> 
Looks like this is a known issue fixed in 0.2.7:
https://github.com/long2ice/asyncmy/blob/dev/CHANGELOG.md

and there are no breaking changes up to 0.2.9 that is in our F39 branch,
which rebuilds fine as is.

So the current plan is to build python-poetry-core 1.6.1-1 and
python-asyncmy 0.2.9-1 in a sidetag on Monday and then put up an update.

cc-ing python-asyncmy maintainer here

I'll post here when the update goes out, and if there's any concern
between now and Monday, let me know and I can delay that until that is
addressed.

Best regards,

-- 
Michel Lind
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

[EPEL-devel] RFC: updating python-poetry-core in EPEL 9 to 1.6.1

[Michel Lind]

Dear all,

Per https://bugzilla.redhat.com/show_bug.cgi?id=2262237 I'm planning to
update python-poetry-core to 1.6.1; based on the changelog there should
be no breaking change. The request is to update to at least 1.2 which is
needed by python-dns-lexicon which is blocking certbot from being
updated.

https://github.com/python-poetry/poetry-core/blob/main/CHANGELOG.md

I have a COPR that rebuilds every dependent packages - found using

`fedrq whatrequires python3-poetry-core -b epel9 -F source --src | tee
dependents.txt`

So far everything (taken from epel9 branch) builds fine:
https://copr.fedorainfracloud.org/coprs/salimma/poetry-core-epel9-wip/builds/

except for python-asyncmy: 
https://copr.fedorainfracloud.org/coprs/salimma/poetry-core-epel9-wip/build/7026743/

I'll try to repro rebuilding against the current poetry-core and the
proposed update, to see if it's related to this or not.

If the asyncmy failure is related, I'll try and fix it (or try a lower
version of poetry-core that let it be compiled) before doing official
builds.

Will probably let this sit until Monday to give people chance to
comment.

Best regards,

-- 
Michel Lind
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

temp symlink while building spec file?

[Ron Olson]

Hi all-

Since Apple released Swift 5.9 it requires a previous version of Swift to 
build; it seems it can’t be built from scratch anymore just using the source. 
To make it more complicated, during compiling it’s expected that certain 
libraries are available specifically at /usr/lib/swift. In a container, I can 
symlink the necessary directory with “ln -s /usr/libexec/swift/5.8.1/lib/swift 
/usr/lib/swift” and Swift builds fine.

This doesn’t work with Mock and I’m trying to think of a way to build Swift 
without introducing more patches; I’ve been able to create a patch that changes 
the directory it’s looking for, but at the cost of compile errors later on.

Might anyone have a suggestion about what can be done within mock to minimize 
the changes needed to the source? I’m really hoping to avoid adding any more 
patches as I feel there’s already too many (8!) just to make it build 
successfully.

I was wondering if I could submit a newer version of 5.8.1 with the symlink as 
part of the rpm so that it would be available going forward. This seems like 
the “safest” option, but before doing that I was wondering if there was a 
specific thing that allows this in Mock that I’m just not aware of.

Thanks for any info!

Ron
--
___
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 Fri, Feb 16, 2024 at 09:37:25AM -0800, Kevin Fenzi wrote:
...snip...
> 
> It should have been. I am not sure where the process failed. 
> 
> I did generate the fedora-42 key. 

FYI, I was lacking coffee or something. 
it's there in the rawhide fedora-repos:

https://src.fedoraproject.org/rpms/fedora-repos/c/d10a092adbcf0e0b2d7e4f05311255c805c878b5?branch=rawhide

Needs updating in other places though.

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

[Kevin Fenzi]

On Fri, Feb 16, 2024 at 11:12:07AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 15, 2024 at 06:03:59PM -0800, Kevin Fenzi wrote:
> > 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.
> 
> Oh, I didn't know that. I see that I have
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary
> on both my F39 and ~rawhide systems.

yes. The 42 one should have been added too... not sure why it didn't
land. ;( 

> This means that both keys are on the system, it's just a matter of
> pointing dnf/other tools at them.

Yes. Looking more I think we just need mock to list both the current
one and the next one.

fedora-repos already does this and I think dnf/dfn5 honor it.

> But let's not talk about mock, let's talk about mkosi.

ok

> In my earlier message I quoted this case:
> 
> > [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?
> 
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
> points to RPM-GPG-KEY-fedora-40-primary.
> So everythould be fine, no? filesystem-3.18-8.fc40.x86_64 is clearly an F40
> package, so it should be signed with the RPM-GPG-KEY-fedora-40-primary key.

Not really no. 

When we branch, the branched release gets all the already signed by
fedora-40 key packages. Rawhide is completely re-signed with the new
fedora-41 key. The dist tag of packages has nothing to do with it. 

So, day X, rawhide is all signed by fedora-40 key. 
Day X+1 we branch and get a new rawhide compose and all rawhide is
signed by the fedora-41 key.

> But it has
> "Signature   : RSA/SHA256, Fri 09 Feb 2024 01:30:23 PM CET, Key ID 
> d0622462e99d6ad1"
> which is RPM-GPG-KEY-fedora-41-primary.
> 
> This actually raises a bunch of questions:
> 1. Why is the .f40 package signed with the F41 key?

Because it's composed in rawhide. That same package composed in branched
composes _is_ signed by the fedora-40 key.

> 2. How does this even work later on? Wouldn't F40 installations refuse
>packages signed with the F41 key?

refuse where? dnf/dnf5 use the line in fedora-rawhide.repo that lists
Both keys.

> 3. If F42 key has already been generated, why isn't it distributed in
>distribution-gpg-keys already, to make it well known and make the
>transition easier in the future?

It should have been. I am not sure where the process failed. 

I did generate the fedora-42 key. 

> and also:
> 
> 4. https://fedoraproject.org/fedora.gpg contains keys for F35, F36, F37, F38, 
> F38, F40.
>Why not F41 and F42?

Yes, it should be added. 

> For mkosi specifically, I guess could try to import also the "next" key
> when configuring rawhide installs, but I'd like to first understand why
> the packages are signed with the F41 key.

See above, happy to expand or try better to explain.

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

[Kevin Fenzi]

On Fri, Feb 16, 2024 at 09:46:05AM +0100, Vít Ondruch wrote:
> 
> 
> Other solution could be if Rawhide lived in rawhide repos instead of f41.

I'm not sure I follow... rawhide is in a rawhide repo?

pub/fedora/linux/development/rawhide/

Or did you mean to sign rawhide with a 'rawhide' key always that never
changes? Thats an option, but then there's no regular key rotation...

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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 16, 2024 at 11:12:07AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 15, 2024 at 06:03:59PM -0800, Kevin Fenzi wrote:
> > 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.
> 
> Oh, I didn't know that. I see that I have
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary
> on both my F39 and ~rawhide systems.
> 
> This means that both keys are on the system, it's just a matter of
> pointing dnf/other tools at them.
> 
> But let's not talk about mock, let's talk about mkosi.
> 
> In my earlier message I quoted this case:
> 
> > [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?
> 
> /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
> points to RPM-GPG-KEY-fedora-40-primary.
> So everythould be fine, no? filesystem-3.18-8.fc40.x86_64 is clearly an F40
> package, so it should be signed with the RPM-GPG-KEY-fedora-40-primary key.
> 
> But it has
> "Signature   : RSA/SHA256, Fri 09 Feb 2024 01:30:23 PM CET, Key ID 
> d0622462e99d6ad1"
> which is RPM-GPG-KEY-fedora-41-primary.
> 
> This actually raises a bunch of questions:
> 1. Why is the .f40 package signed with the F41 key?
> 2. How does this even work later on? Wouldn't F40 installations refuse
>packages signed with the F41 key?
> 3. If F42 key has already been generated, why isn't it distributed in
>distribution-gpg-keys already, to make it well known and make the
>transition easier in the future?
> 
> and also:
> 
> 4. https://fedoraproject.org/fedora.gpg contains keys for F35, F36, F37, F38, 
> F38, F40.
>Why not F41 and F42?
> 
> For mkosi specifically, I guess could try to import also the "next" key
> when configuring rawhide installs, but I'd like to first understand why
> the packages are signed with the F41 key.

For now, I prepared the following PR: 
https://github.com/systemd/mkosi/pull/2398.
It makes the build work by importing both RPM-GPG-KEY-fedora-40-primary
and RPM-GPG-KEY-fedora-41-primary when the version string is "rawhide".
As I wrote above, I don't understand some things here, so comments are
very much welcome.

Zbyszek
--
___
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 Fri, 16 Feb 2024 at 10:51, David Cantrell  wrote:

> On 2/15/24 11:19, Stephen Smoogen wrote:
> >
> >
> > 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).
>
> It depends on what you mean by "work".  It's definitely clear there is a
> lot of syntax it does not understand.
>
>
It was mainly that I couldn't get it to 'parse' various simple C code
without bombing out over standard headers it couldn't parse. I was mainly
asking in case you had a standard flag set which made it work and I had
missed the obvious.


> There is at least one fork I found on github that has continued work on
> splint, but its most recent commit is from 3 years ago and it has open
> issues like "support C99 syntax".
>
>
Yeah I could not get the one I found to compile (but it was even older) so
not sure where things stood in forks either.


> splint's days may be over.
>
>
I will pour one compile out for it.


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

[David Cantrell]

On 2/15/24 11:19, Stephen Smoogen wrote:



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 mailto:nixu...@mail.com>
 > >> 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).


It depends on what you mean by "work".  It's definitely clear there is a 
lot of syntax it does not understand.


There is at least one fork I found on github that has continued work on 
splint, but its most recent commit is from 3 years ago and it has open 
issues like "support C99 syntax".


splint's days may be over.

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

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

[Marius Schwarz]

Am 15.02.24 um 23:09 schrieb Kevin Kofler via devel:

They should instead learn some basic concepts of security.
It's about trust in integrity of system encapsulated in something else 
which is disrupted.


From host to guest:  you need to trust the guest not to ... spam, scan, 
hack aso.
From guest to host:  you need to trust the host not to spy on you, your 
data, connection targets aso.


"not per se bad faith" kernel mechanics that can do that, do not help 
with trust. That's what the original author wanted to express, and here 
i agree.


My work would also suffer, if i could not just trace a process when i 
need to. On the other hand, I can imagine that hardening the system
against "espionage" can only help to gain that trust into computing and 
turn the lifes of some bad actors worse.


Having talked about it, is a good start.

conveniently read if they ever manage to compromise your computer. That
contraption is one of the first things I disable on my computers!


Agreed, for a more profane reason: it trashes the logfiles for 99.9+% of 
the time ;)


best regards,
Marius Schwarz--
___
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

SPDX Statistics - Please Please Me edition

[Miroslav Suchý]

Hot news:

    SPDX did a new release of license list with 43 new licenses. Most of them 
were added thank to Fedora maintainers
https://github.com/spdx/license-list-XML/releases

Two weeks ago we had:


* 23711spec files in Fedora

* 30306license tags in all spec files

* 11542 tags have not been converted to SPDX yet

* 5193 tags can be trivially converted using `license-fedora2spdx`

* Progress: 61,92% ░░ 100%

ELN subset:

217 out of 2766 packages are not converted yet (progress 92.15%)



Today we have:

* 23737spec files in Fedora

* 30335license tags in all spec files

* 11314 tags have not been converted to SPDX yet

* 5105 tags can be trivially converted using `license-fedora2spdx`

* Progress: 62,70% ░░ 100%

ELN subset:

128 out of 2412 packages are not converted yet (progress 94.69%)

Graph of these data with the burndown chart:

https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing

The list of packages needed to be converted is here:

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt

List by package maintainers is here

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt

List of packages from ELN subset that needs to be converted:

https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt

New version of fedora-license-data has been released. With:
    14 new licenses (plus some public domain declarations).
    20 licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data) 
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked


Legal docs and especially

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

was updated too.

License analysis of remaining packages: 
http://miroslav.suchy.cz/fedora/spdx-reports/


New projection when we will be finished is 2025-01-17 (+12 days from last 
report).  Pure linear approximation.

If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license 
tag matches SPDX formula, you can put your package on ignore list


https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt

Either pull-request or direct email to me is fine.


Why Please Please Me edition? On this day, in 1963 Beatles got the first place in UK music chart for the first time. It 
was their first album. They decided to record it after a success of their single. So they recorded 10 additional songs 
(in one day) and album Please Please Me was born. It stayed in the chart for almost a year until Beatles recorded next 
album. This was surprising as before this album the charts were occupied by movie songs and easy listening song for 
adults and not for teenagers. Follow the rabbit hole:


https://en.wikipedia.org/wiki/Please_Please_Me

Miroslav


--
___
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 2223392] perl-Test-Vars: FTBFS with Perl 5.38

[bugzilla]

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



--- Comment #9 from Paul Howarth  ---
Seems to be retired OK in rawhide but not f40 yet:

https://pagure.io/releng/issue/11959


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

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

perl-Image-PNG-Libpng-tests license corrected

[Petr Pisar]

I corrected a perl-Image-PNG-Libpng-tests license tag from

(GPL-1.0-or-later OR Artistic-1.0-Perl)

to

(GPL-1.0-or-later OR Artistic-1.0-Perl) AND 
LicenseRef-Fedora-UltraPermissive

-- 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: Need help with incompatible pointer types on i686

[Sérgio Basto]

On Fri, 2024-02-16 at 14:01 +0100, Florian Weimer wrote:
> * Orion Poplawski:
> 
> > 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?
> 
> The types int and long are distinct according to C rules.
> 
> The problem seems to be in h5py/api_types_ext.pxd:
> 
> from numpy cimport int8_t, uint8_t, int16_t, uint16_t, int32_t,
> uint32_t, int64_t, uint64_t
> 
> I think it should use the types from  instead, at least in
> the
> global scope.  For certain Numpy functions, it may be required to
> reference them as numpy.uint32_t etc.


this is over complicated to me , we can disable this check with: 

%global build_type_safety_c 0

> 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

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

Fedora 40 compose report: 20240216.n.0 changes

[Fedora Branched Report]

OLD: Fedora-40-20240215.n.1
NEW: Fedora-40-20240216.n.0

= SUMMARY =
Added images:3
Dropped images:  1
Added packages:  4
Dropped packages:4
Upgraded packages:   60
Downgraded packages: 0

Size of added packages:  7.55 MiB
Size of dropped packages:4.68 MiB
Size of upgraded packages:   1015.06 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-40-20240216.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-40-20240216.n.0.iso
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-40-20240216.n.0.iso

= DROPPED IMAGES =
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-40-20240215.n.1.iso

= ADDED PACKAGES =
Package: papilo-2.1.4-1.fc40
Summary: Parallel presolve for integer and linear optimization
RPMs:libpapilo libpapilo-devel papilo
Size:6.45 MiB

Package: python-wsgidav-4.3.0-1.fc40
Summary: Generic and extendable WebDAV server based on WSGI
RPMs:python3-wsgidav python3-wsgidav+pam
Size:342.07 KiB

Package: rust-nu-command-0.88.1-1.fc40
Summary: Nushell's built-in commands
RPMs:rust-nu-command+default-devel rust-nu-command+num-devel 
rust-nu-command+plugin-devel rust-nu-command+rusqlite-devel 
rust-nu-command+sqlite-devel rust-nu-command+trash-devel 
rust-nu-command+trash-support-devel rust-nu-command+which-devel 
rust-nu-command+which-support-devel rust-nu-command-devel
Size:590.38 KiB

Package: rust-ureq-2.9.1-1.fc40
Summary: Simple, safe HTTP client
RPMs:rust-ureq+brotli-devel rust-ureq+charset-devel rust-ureq+cookies-devel 
rust-ureq+default-devel rust-ureq+gzip-devel rust-ureq+http-crate-devel 
rust-ureq+http-interop-devel rust-ureq+json-devel rust-ureq+native-certs-devel 
rust-ureq+native-tls-devel rust-ureq+proxy-from-env-devel 
rust-ureq+socks-proxy-devel rust-ureq+tls-devel rust-ureq-devel
Size:197.68 KiB


= DROPPED PACKAGES =
Package: rust-libgit2-sys0.12-0.12.26-7.fc40
Summary: Native bindings to the libgit2 library
RPMs:rust-libgit2-sys0.12+default-devel rust-libgit2-sys0.12+https-devel 
rust-libgit2-sys0.12+libssh2-sys-devel rust-libgit2-sys0.12+openssl-sys-devel 
rust-libgit2-sys0.12+ssh-devel rust-libgit2-sys0.12+ssh_key_from_memory-devel 
rust-libgit2-sys0.12+vendored-devel rust-libgit2-sys0.12-devel
Size:1.15 MiB

Package: rust-libgit2-sys0.13-0.13.5-3.fc40
Summary: Native bindings to the libgit2 library
RPMs:rust-libgit2-sys0.13+default-devel rust-libgit2-sys0.13+https-devel 
rust-libgit2-sys0.13+libssh2-sys-devel rust-libgit2-sys0.13+openssl-sys-devel 
rust-libgit2-sys0.13+ssh-devel rust-libgit2-sys0.13+ssh_key_from_memory-devel 
rust-libgit2-sys0.13+vendored-devel rust-libgit2-sys0.13-devel
Size:1.16 MiB

Package: rust-libgit2-sys0.14-0.14.2-3.fc40
Summary: Native bindings to the libgit2 library
RPMs:rust-libgit2-sys0.14+default-devel rust-libgit2-sys0.14+https-devel 
rust-libgit2-sys0.14+libssh2-sys-devel rust-libgit2-sys0.14+openssl-sys-devel 
rust-libgit2-sys0.14+ssh-devel rust-libgit2-sys0.14+ssh_key_from_memory-devel 
rust-libgit2-sys0.14+vendored-devel rust-libgit2-sys0.14-devel
Size:1.19 MiB

Package: rust-libgit2-sys0.15-0.15.2-2.fc40
Summary: Native bindings to the libgit2 library
RPMs:rust-libgit2-sys0.15+default-devel rust-libgit2-sys0.15+https-devel 
rust-libgit2-sys0.15+libssh2-sys-devel rust-libgit2-sys0.15+openssl-sys-devel 
rust-libgit2-sys0.15+ssh-devel rust-libgit2-sys0.15+ssh_key_from_memory-devel 
rust-libgit2-sys0.15+vendored-devel rust-libgit2-sys0.15-devel
Size:1.20 MiB


= UPGRADED PACKAGES =
Package:  apptainer-1.3.0~rc.2-1.fc40
Old package:  apptainer-1.3.0~rc.1-1.fc40
Summary:  Application and environment virtualization formerly known as 
Singularity
RPMs: apptainer apptainer-suid
Size: 128.53 MiB
Size change:  3.35 MiB
Changelog:
  * Fri Jan 19 2024 Fedora Release Engineering  - 
1.3.0~rc.1-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Mon Jan 22 2024 Fedora Release Engineering  - 
1.3.0~rc.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Sun Feb 11 2024 Maxwell G  - 1.3.0~rc.1-4
  - Rebuild for golang 1.22.0

  * Thu Feb 15 2024 Dave Dykstra  - 1.3.0~rc.2
  - Update to upstream 1.3.0-rc.2


Package:  arm-trusted-firmware-2.10.0-6.fc40
Old package:  arm-trusted-firmware-2.10.0-4.fc40
Summary:  ARM Trusted Firmware
RPMs: arm-trusted-firmware-armv8
Size: 192.26 KiB
Size change:  39.64 KiB
Changelog:
  * Tue Feb 13 2024 Peter Robinson  - 2.10.0-5
  - Add initial rk3588 support

  * Thu Feb 15 2024 Michael Brown  - 2.10.0-6
  - Add qemu_sbsa platform


Package:  bsfilter-1.0.19-5.fc40
Old package:  bsfilter-1.0.19-4.fc40.16

Re: Need help with incompatible pointer types on i686

[Florian Weimer]

* Orion Poplawski:

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

The types int and long are distinct according to C rules.

The problem seems to be in h5py/api_types_ext.pxd:

from numpy cimport int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, 
int64_t, uint64_t

I think it should use the types from  instead, at least in the
global scope.  For certain Numpy functions, it may be required to
reference them as numpy.uint32_t etc.

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

[Test-Announce] Fedora 40 Branched 20240216.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 40 Branched 20240216.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
lorax - 20240213.n.1: lorax-40.5-1.fc40.src, 20240216.n.0: lorax-40.5-2.fc40.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/40

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240216.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240216.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240216.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240216.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240216.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240216.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240216.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Doubts on /etc/mock/fedora-40-*.cfg

[Petr Pisar]

V Fri, Feb 16, 2024 at 01:11:38PM +0100, Petr Pisar napsal(a):
> If locally run mock is expected to mimich Koji as much as possible, it should
> change fedora-40*.cfg to use dnf5.
> 
https://bugzilla.redhat.com/show_bug.cgi?id=2264535

-- 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: Doubts on /etc/mock/fedora-40-*.cfg

[Petr Pisar]

V Fri, Feb 16, 2024 at 12:09:27PM +0100, Ralf Corsépius napsal(a):
> Am 16.02.24 um 12:00 schrieb Ralf Corsépius:
> > Hi,
> > 
> > today, mock-core-configs-40.1-1.fc39.noarch landed, bringing along
> > 
> > /etc/mock/fedora-40-x86_64.cfg
> > and
> > /etc/mock/fedora-40-i386.cfg
> > 
> > Now, I'm wondering about config_opts['package_manager']
> > 
> > fedora-40-*.cfg includes templates/fedora-branched.tpl
> > which sets
> > config_opts['package_manager']=dnf
> > 
> > This is unlike fedora-rawhide-*.cfg which sets
> > config_opts['package_manager']=dnf5
> > 
> > I.e. all fc40 packages having been built before fedora-40*.cfgs were
> > introduced, were using "dnf", while packages being built from now on
> > will be using "dnf"
> 
> Typo: This was meant to be
> "... were using "dnf5", ... will be using "dnf".
> 
> > Shouldn't fedora-40*.cfgs set config_opts['package_manager']=dnf5 ?
> > 
Good catch. F40 packages are suppossed to be built with dnf5
.

I believe Koji uses mock configs from Koji build tag configuration instead
those provided by mock-core-configs.

If locally run mock is expected to mimich Koji as much as possible, it should
change fedora-40*.cfg to use dnf5.

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

Restore dmz-cursor-themes

[Fabrice]

Hi!

I would like to become the maintainer of dmz-cursor-themes.
https://src.fedoraproject.org/rpms/dmz-cursor-themes

I would like to push an update from Debian, v0.4.5.1.

Thanks
--
___
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: [Pierre-Yves Chibon] Unresponsive packagers: nknazeko

[Pierre-Yves Chibon]

On Tue, Feb 13, 2024 at 11:20:59AM +0100, Pierre-Yves Chibon wrote:
> 
> On Sun, Feb 11, 2024 at 10:44:18PM +0100, Vit Mojzis wrote:
> > Nikola left Red Hat and hence changed the email address in FAS. I'm
> > guessing that only her Red Hat email was tied to a BZ account.
> > I'll try and let her know. Do I understand correctly that she just needs
> > to create a new BZ account using the email address in FAS?
> 
> That's correct, she either need to create a bugzilla account associated with 
> the
> email she uses in FAS, or fill in the "bugzilla email" field of her FAS 
> account
> with the email of her bugzilla account.

Hey Vit,

Just out of curiosity, have you heard back from her?
From our side the issue still seems to be present.

Thanks,
Pierre
--
___
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: Fw: [Bug 2066129] mingw-libgsf-1_14_52 is available

[Daniel P . Berrangé]

On Fri, Feb 09, 2024 at 11:12:42PM -0600, Greg Hellings wrote:
> Looks like I'm not allowed to retire on the f39 branch. It was already
> retired in Rawhide before I could get there.
> 
> $ fedpkg retire "MinGW support merged to native package in Fedora 39
> release"
> Fedora release (f39) is in state 'current' - retire operation is not
> allowed.

Oh well, it should be harmless as long as no one ever updates that
branch with new versions, nor does any new builds from that branch.
The NEVR from the native package should be newer and thus the mingw
sub-RPMs from the native build are what should get into the yum repos.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 15, 2024 at 06:03:59PM -0800, Kevin Fenzi wrote:
> 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.

Oh, I didn't know that. I see that I have
/usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-40-primary
/usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-41-primary
on both my F39 and ~rawhide systems.

This means that both keys are on the system, it's just a matter of
pointing dnf/other tools at them.

But let's not talk about mock, let's talk about mkosi.

In my earlier message I quoted this case:

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

/usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary
points to RPM-GPG-KEY-fedora-40-primary.
So everythould be fine, no? filesystem-3.18-8.fc40.x86_64 is clearly an F40
package, so it should be signed with the RPM-GPG-KEY-fedora-40-primary key.

But it has
"Signature   : RSA/SHA256, Fri 09 Feb 2024 01:30:23 PM CET, Key ID 
d0622462e99d6ad1"
which is RPM-GPG-KEY-fedora-41-primary.

This actually raises a bunch of questions:
1. Why is the .f40 package signed with the F41 key?
2. How does this even work later on? Wouldn't F40 installations refuse
   packages signed with the F41 key?
3. If F42 key has already been generated, why isn't it distributed in
   distribution-gpg-keys already, to make it well known and make the
   transition easier in the future?

and also:

4. https://fedoraproject.org/fedora.gpg contains keys for F35, F36, F37, F38, 
F38, F40.
   Why not F41 and F42?

For mkosi specifically, I guess could try to import also the "next" key
when configuring rawhide installs, but I'd like to first understand why
the packages are signed with the F41 key.

Zbyszek
--
___
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: Doubts on /etc/mock/fedora-40-*.cfg

[Ralf Corsépius]

Am 16.02.24 um 12:00 schrieb Ralf Corsépius:

Hi,

today, mock-core-configs-40.1-1.fc39.noarch landed, bringing along

/etc/mock/fedora-40-x86_64.cfg
and
/etc/mock/fedora-40-i386.cfg

Now, I'm wondering about config_opts['package_manager']

fedora-40-*.cfg includes templates/fedora-branched.tpl
which sets
config_opts['package_manager']=dnf

This is unlike fedora-rawhide-*.cfg which sets
config_opts['package_manager']=dnf5

I.e. all fc40 packages having been built before fedora-40*.cfgs were 
introduced, were using "dnf", while packages being built from now on 
will be using "dnf"


Typo: This was meant to be
"... were using "dnf5", ... will be using "dnf".


Shouldn't fedora-40*.cfgs set config_opts['package_manager']=dnf5 ?

Ralf

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

Doubts on /etc/mock/fedora-40-*.cfg

[Ralf Corsépius]

Hi,

today, mock-core-configs-40.1-1.fc39.noarch landed, bringing along

/etc/mock/fedora-40-x86_64.cfg
and
/etc/mock/fedora-40-i386.cfg

Now, I'm wondering about config_opts['package_manager']

fedora-40-*.cfg includes templates/fedora-branched.tpl
which sets
config_opts['package_manager']=dnf

This is unlike fedora-rawhide-*.cfg which sets
config_opts['package_manager']=dnf5

I.e. all fc40 packages having been built before fedora-40*.cfgs were 
introduced, were using "dnf", while packages being built from now on 
will be using "dnf"


Shouldn't fedora-40*.cfgs set config_opts['package_manager']=dnf5 ?

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com



--- Comment #6 from Petr Pisar  ---
(In reply to Steve Traylen from comment #4)
> Don't understand...
> 
> mock -r fedora-rawhide-x86_64 --install bash
[...] 
> 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?

See
.


-- 
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%23c6
--
___
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: 20240216.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240215.n.0
NEW: Fedora-Rawhide-20240216.n.0

= SUMMARY =
Added images:4
Dropped images:  1
Added packages:  4
Dropped packages:4
Upgraded packages:   104
Downgraded packages: 0

Size of added packages:  7.55 MiB
Size of dropped packages:4.68 MiB
Size of upgraded packages:   2.42 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20240216.n.0.iso
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20240216.n.0.iso
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20240216.n.0.ppc64le.tar.xz
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20240216.n.0.iso

= DROPPED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240215.n.0.iso

= ADDED PACKAGES =
Package: papilo-2.1.4-1.fc41
Summary: Parallel presolve for integer and linear optimization
RPMs:libpapilo libpapilo-devel papilo
Size:6.45 MiB

Package: python-wsgidav-4.3.0-1.fc41
Summary: Generic and extendable WebDAV server based on WSGI
RPMs:python3-wsgidav python3-wsgidav+pam
Size:341.91 KiB

Package: rust-nu-command-0.88.1-1.fc41
Summary: Nushell's built-in commands
RPMs:rust-nu-command+default-devel rust-nu-command+num-devel 
rust-nu-command+plugin-devel rust-nu-command+rusqlite-devel 
rust-nu-command+sqlite-devel rust-nu-command+trash-devel 
rust-nu-command+trash-support-devel rust-nu-command+which-devel 
rust-nu-command+which-support-devel rust-nu-command-devel
Size:590.45 KiB

Package: rust-ureq-2.9.1-1.fc41
Summary: Simple, safe HTTP client
RPMs:rust-ureq+brotli-devel rust-ureq+charset-devel rust-ureq+cookies-devel 
rust-ureq+default-devel rust-ureq+gzip-devel rust-ureq+http-crate-devel 
rust-ureq+http-interop-devel rust-ureq+json-devel rust-ureq+native-certs-devel 
rust-ureq+native-tls-devel rust-ureq+proxy-from-env-devel 
rust-ureq+socks-proxy-devel rust-ureq+tls-devel rust-ureq-devel
Size:197.67 KiB


= DROPPED PACKAGES =
Package: rust-libgit2-sys0.12-0.12.26-7.fc40
Summary: Native bindings to the libgit2 library
RPMs:rust-libgit2-sys0.12+default-devel rust-libgit2-sys0.12+https-devel 
rust-libgit2-sys0.12+libssh2-sys-devel rust-libgit2-sys0.12+openssl-sys-devel 
rust-libgit2-sys0.12+ssh-devel rust-libgit2-sys0.12+ssh_key_from_memory-devel 
rust-libgit2-sys0.12+vendored-devel rust-libgit2-sys0.12-devel
Size:1.15 MiB

Package: rust-libgit2-sys0.13-0.13.5-3.fc40
Summary: Native bindings to the libgit2 library
RPMs:rust-libgit2-sys0.13+default-devel rust-libgit2-sys0.13+https-devel 
rust-libgit2-sys0.13+libssh2-sys-devel rust-libgit2-sys0.13+openssl-sys-devel 
rust-libgit2-sys0.13+ssh-devel rust-libgit2-sys0.13+ssh_key_from_memory-devel 
rust-libgit2-sys0.13+vendored-devel rust-libgit2-sys0.13-devel
Size:1.16 MiB

Package: rust-libgit2-sys0.14-0.14.2-3.fc40
Summary: Native bindings to the libgit2 library
RPMs:rust-libgit2-sys0.14+default-devel rust-libgit2-sys0.14+https-devel 
rust-libgit2-sys0.14+libssh2-sys-devel rust-libgit2-sys0.14+openssl-sys-devel 
rust-libgit2-sys0.14+ssh-devel rust-libgit2-sys0.14+ssh_key_from_memory-devel 
rust-libgit2-sys0.14+vendored-devel rust-libgit2-sys0.14-devel
Size:1.19 MiB

Package: rust-libgit2-sys0.15-0.15.2-2.fc40
Summary: Native bindings to the libgit2 library
RPMs:rust-libgit2-sys0.15+default-devel rust-libgit2-sys0.15+https-devel 
rust-libgit2-sys0.15+libssh2-sys-devel rust-libgit2-sys0.15+openssl-sys-devel 
rust-libgit2-sys0.15+ssh-devel rust-libgit2-sys0.15+ssh_key_from_memory-devel 
rust-libgit2-sys0.15+vendored-devel rust-libgit2-sys0.15-devel
Size:1.20 MiB


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


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


Package:  appstream-data-40-6.fc41
Old package:  appstream-data-40-5.fc40
Summary:  Fedora AppStream metadata
RPMs: appstream-data
Size: 14.36 MiB
Size change:  269.27 KiB
Changelog:
  * Thu Feb 15 2024 Richard Hughes  - 40-6
  - New metadata version


Package:  apptainer-1.3.0~rc.2-1.fc41
Old package:  apptainer-1.3.0~rc.1-1.fc40
Summary:  Application and environment

Re: Modern C failures in Haskell stack

[David Abdurachmanov]

On Fri, Feb 16, 2024 at 9:38 AM Jens-Ulrik Petersen  wrote:
>
> 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)

I started building this NVR a couple of hours ago in Fedora/RISCV Koji.

http://fedora.riscv.rocks/koji/taskinfo?taskID=1602528

Should take ~24 hours.

Cheers,
david

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

[Vít Ondruch]

Dne 16. 02. 24 v 3:03 Kevin Fenzi napsal(a):

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.



Other solution could be if Rawhide lived in rawhide repos instead of f41.


Vít




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

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


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

[Bug 2264507] perl-Crypt-SMIME-0.28-11.fc41 FTBFS: Failed test 'Load the default public key store' at t/04-taint.t line 257: died: Crypt::SMIME#setPublicKeyStore: failed to store the public cert at t/

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
This could be triggered by upgrading openssl from 3.1.4-4.fc40 to 3.2.1-2.fc40.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264507%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 2264507] New: perl-Crypt-SMIME-0.28-11.fc41 FTBFS: Failed test 'Load the default public key store' at t/04-taint.t line 257: died: Crypt::SMIME#setPublicKeyStore: failed to store the public cert

[bugzilla]

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

Bug ID: 2264507
   Summary: perl-Crypt-SMIME-0.28-11.fc41 FTBFS: Failed test 'Load
the default public key store' at t/04-taint.t line
257: died: Crypt::SMIME#setPublicKeyStore: failed to
store the public cert at t/04-taint.t line 257.
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Crypt-SMIME
  Assignee: steve.tray...@cern.ch
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
steve.tray...@cern.ch, xav...@bachelot.org
Blocks: 2260875 (F41FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-Crypt-SMIME-0.28-11.fc41 fails to build in Fedora 41 for me because a test
fails:

+ make test
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- SMIME.bs
blib/arch/auto/Crypt/SMIME/SMIME.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')"
t/*.t
# Testing Crypt::SMIME 0.28, Perl 5.038002, /usr/bin/perl
t/00-load.t ... ok
# Using `/usr/bin/openssl' to generate a keypair
t/01-smime.t .. ok
# Using `/usr/bin/openssl' to generate a keypair
t/02-smime.more.t . ok
# Using `/usr/bin/openssl' to generate a keypair
t/03-chained-certs.t .. ok
# Using `/usr/bin/openssl' to generate a keypair

#   Failed test 'Load the default public key store'
#   at t/04-taint.t line 257.
# died: Crypt::SMIME#setPublicKeyStore: failed to store the public cert at
t/04-taint.t line 257.
t/04-taint.t ..
Failed 2/7 subtests
t/boilerplate.t ... ok
t/manifest.t .. ok
t/pod-coverage.t .. ok
t/pod.t ... ok

Test Summary Report
---
t/04-taint.t(Wstat: 139 (Signal: SEGV, dumped core) Tests: 5 Failed: 0)
  Non-zero wait status: 139
  Parse errors: Bad plan.  You planned 7 tests but ran 5.
Files=9, Tests=72,  1 wallclock secs ( 0.04 usr  0.01 sys +  1.05 cusr  0.17
csys =  1.27 CPU)
Result: FAIL
Failed 1/9 test programs. 0/72 subtests failed.
make: *** [Makefile:1072: test_dynamic] Error 255



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2260875
[Bug 2260875] Fedora 41 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264507

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264507%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: Need help with incompatible pointer types on i686

[Michael J Gruber]

Am Fr., 16. Feb. 2024 um 07:15 Uhr schrieb 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:

They are the same (bit size, signedness, general type) but not equal
(long int vs int), and with gcc14 this became an error. I"m sure it
always warned about that before.

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

numpy definitely needs to fix this. You cannot just go by bitsize and
signedness. You never could and now you can't ;)
I'm surprised this didn't come up during our "gcc 14 ride".

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