Re: openmpi 5.0.0 drops 32-bit support

[Kevin Kofler via devel]

Fabio Valentini wrote:
> You don't even need to file paperwork for excluding i686 anymore since
> this happened:
> https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval

But openmpi is not a leaf package, so this fast-track process does not 
apply.

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

Re: Will dnf5 be ready by F39?

[Kevin Kofler via devel]

Michael Catanzaro wrote:
> A PackageKit backend for dnf5 would also work and I have no doubt it
> will happen regardless. Surely that'd be the best option for Fedora if
> dnfdaemon does not have the same D-Bus API that PackageKit does,
> because pushing dnf-specific code into upstream projects when
> PackageKit exists is not very friendly.

Pushing DNF-specific code is also unlikely to happen for projects such as 
KDE Plasma Discover, so if we want those to keep working, we will need the 
PackageKit D-Bus API implemented one way or the other.

> But Red Hat has a conflicting goal: we don't want to maintain PackageKit
> anymore!

I think that if Red Hat drops PackageKit, it will be completely dead. The 
whole idea of having one common API for all distros has already failed, 
because many distros have stuck or reverted to defaulting to tools directly 
using their native package manager / dependency solver. Some of those 
already emulate the PackageKit D-Bus API.

Even for Fedora, dnfdragora is already used by many users (including me), 
and now Red Hat wants to port more stuff to dnf5 directly, away from 
PackageKit. And Fedora is a distribution where PackageKit works *well*. 
(E.g., I use plasma-pk-updates for my system updates and it just works.) On 
Arch-based distributions, PackageKit is absolutely horrible (because the 
PackageKit alpm (pacman) backend is very poorly maintained). E.g., Discover 
just fails spectacularly at upgrading Manjaro. Only the native tools 
(pacman, pamac, etc.) work there.

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

Re: poppler soname bump in Rawhide

[Rajeesh K V]

> Packages which need to be rebuilt:
>   calligra
>   gambas3
>   gdal
>   gdcm
>   inkscape
>   kf5-kitinerary
>   libreoffice
>   pdf2djvu
>   scribus

Poppler update almost always results in rebuilding TeXLive (due to pdfTeX) too.

I was wondering how the ‘bootstrap’ build is done when that happens.
What magic incantations does spot (cc’ed) typically invoke for that,
is it somewhere documented?
___
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
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f41d6b3e32   
python3-pygments-2.4.2-1.el7


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

pspg-5.7.2-1.el7

Details about builds:



 pspg-5.7.2-1.el7 (FEDORA-EPEL-2023-538ecfc557)
 A unix pager optimized for psql

Update Information:

new upstream release, per release notes: -
https://github.com/okbob/pspg/releases/tag/5.7.2 -
https://github.com/okbob/pspg/releases/tag/5.7.1 -
https://github.com/okbob/pspg/releases/tag/5.7.0 -
https://github.com/okbob/pspg/releases/tag/5.6.4 -
https://github.com/okbob/pspg/releases/tag/5.6.2 -
https://github.com/okbob/pspg/releases/tag/5.6.0

ChangeLog:

* Thu Feb  2 2023 Pavel Raiskup  - 5.7.2-1
- new upstream release, per release notes:
  https://github.com/okbob/pspg/releases/tag/5.7.2
  https://github.com/okbob/pspg/releases/tag/5.7.1
  https://github.com/okbob/pspg/releases/tag/5.7.0
  https://github.com/okbob/pspg/releases/tag/5.6.4
  https://github.com/okbob/pspg/releases/tag/5.6.2
  https://github.com/okbob/pspg/releases/tag/5.6.0
* Fri Jan 20 2023 Fedora Release Engineering  - 
5.5.13-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild


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

[Bug 2164678] perl-YAML-LibYAML-0.86 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version|perl-YAML-LibYAML-0.86-1.fc |perl-YAML-LibYAML-0.86-1.fc
   |38  |38
   ||perl-YAML-LibYAML-0.86-1.fc
   ||37
Last Closed||2023-02-04 01:29:53



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


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

[Kevin Fenzi]

On Fri, Feb 03, 2023 at 05:27:06PM -0700, Orion Poplawski wrote:
> 
> Thanks, but no go:
> 
> bodhi updates trigger-tests FEDORA-2023-96ebcd6f4d
> Login successful!
> Traceback (most recent call last):

This may well be because those updates are in a updates push right now
and the updates are locked. 

Try again later tonight/tomorrow/later?

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

[Test-Announce] 2023-02-06 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2023-02-06
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.libera.chat

Greetings testers!

It's meeting time! Quite a lot of stuff is landing in Rawhide at the
moment, and the F38 branch is coming up.

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

Re: bodhi tests missing

[Orion Poplawski]

On 2/3/23 08:16, Petr Pisar wrote:

V Fri, Feb 03, 2023 at 07:40:09AM -0700, Orion Poplawski napsal(a):

I've got a couple updates with missing tests:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-96ebcd6f4d
https://bodhi.fedoraproject.org/updates/FEDORA-2023-23e26fcc32


That happens when CI is slow or broken. Or when a message bus about finising
the tests was not properly stored into test results database. Also some tests
performed in Rawhide are not performed in stable Fedoras, based on global CI
configuration.


it seems like I used to have the option to resubmit the tests but I don't
see that now.  Is my only option to waive the test results?


Try a command line: bodhi updates trigger-tests FEDORA-2023-96ebcd6f4d.


Thanks, but no go:

bodhi updates trigger-tests FEDORA-2023-96ebcd6f4d
Login successful!
Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/bodhi/client/bindings.py", 
line 382, in trigger_tests

return self.send_request(
   ^^
  File "/usr/lib/python3.11/site-packages/bodhi/client/bindings.py", 
line 235, in send_request

raise BodhiClientException(response.text)
bodhi.client.bindings.BodhiClientException: {"status": "error", 
"errors": [{"location": "body", "name": "request", "description": 
"Update is not in testing status"}]}


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/bodhi", line 8, in 
sys.exit(cli())
 ^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1130, in 
__call__

return self.main(*args, **kwargs)
   ^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1055, in 
main

rv = self.invoke(ctx)
 
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1657, in 
invoke

return _process_result(sub_ctx.command.invoke(sub_ctx))
   ^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1657, in 
invoke

return _process_result(sub_ctx.command.invoke(sub_ctx))
   ^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1404, in 
invoke

return ctx.invoke(self.callback, **ctx.params)
   ^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 760, in 
invoke

return __callback(*args, **kwargs)
   ^^^
  File "/usr/lib/python3.11/site-packages/bodhi/client/cli.py", line 
269, in wrapper

method(*args, **kwargs)
  File "/usr/lib/python3.11/site-packages/bodhi/client/cli.py", line 
986, in trigger_tests

resp = client.trigger_tests(update)
   
  File "/usr/lib/python3.11/site-packages/bodhi/client/bindings.py", 
line 128, in wrapper

result = method(*args, **kwargs)
 ^^^
  File "/usr/lib/python3.11/site-packages/bodhi/client/bindings.py", 
line 386, in trigger_tests

if exc.response.status_code == 404:
   
AttributeError: 'NoneType' object has no attribute 'status_code'


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

[Bug 2167024] New: Please branch and build perl-Shell-TermUI for EPEL 9

[bugzilla]

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

Bug ID: 2167024
   Summary: Please branch and build perl-Shell-TermUI for EPEL 9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Term-ShellUI
  Assignee: emman...@seyman.fr
  Reporter: or...@nwra.com
QA Contact: extras...@fedoraproject.org
CC: c...@fea.st, echevemas...@gmail.com,
emman...@seyman.fr, mkre...@gmail.com,
perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Description of problem:

Needed for kpcli.  Thanks.

Builds fine: https://koji.fedoraproject.org/koji/taskinfo?taskID=97068064


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

poppler soname bump in Rawhide

[Marek Kasik]

Hi,

I've prepared rebase of poppler to 23.02.0, which was released 
yesterday, in the side tag "f38-build-side-62722". I'm asking you to 
build your dependent packages in it and I will merge it to the main 
buildroot at Monday (6th of February) just before the branching.


There are several API changes and soname bump of the base library 
libpoppler.so.*.


Packages which need to be rebuilt:
 calligra
 gambas3
 gdal
 gdcm
 inkscape
 kf5-kitinerary
 libreoffice
 pdf2djvu
 scribus


If your package still uses the unstable API (headers from 
poppler-devel), could you consider to change it to use a stable API in 
the future (glib, qt5, C++)? It would mean less work for you and I would 
be able to disable the unstable API.



Regards
Marek
___
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: libgit2 1.5.x in rawhide with compat packages for 1.3.x and 1.4.x

[Fabio Valentini]

On Fri, Feb 3, 2023 at 5:05 PM Pete Walter  wrote:
>
> Today, we have 3 versions in rawhide (libgit2 was updated from 1.3.x to 1.4.x 
> and then 1.5.x over the last month and the compat packages were added today):
>
> libgit2 package with version 1.5.1 (security supported still from upstream)
> libgit2_1.4 package with version 1.4.5 (security supported still from 
> upstream)
> libgit2_1.3 package with version 1.3.2 (EOL upstream)

Thank you for working on this!

It would be great if libgit2 updates and compat packages could be
pushed to stable branches as well. It would allow me to un-vendor
libgit2 from the libgit2 Rust bindings, which suffer from the same
problems as most other libgit2 consumers (either libgit2 in Fedora is
too new, or too old), and the bindings are only ever compatible with
one 1.x branch at a time due to subtle API and / or ABI changes ...
(honestly I was kind of hoping that the 1.0.0 release of libgit2 would
mark an era with more stability, but apparently the upstream project
just released 1.0.0 and kept on breaking things with minor releases
for fun).

We would probably need to adapt consumers of libgit2 to specify which
1.x of libgit2 they want to build against before this can be pushed to
stable branches though - otherwise many will just pull in the most
recent one and start to fail to build (which wouldn't be good in
stable branches).

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

[Bug 2166962] perl-Rose-DB-0.784 is available

[bugzilla]

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

Bill Pemberton  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2023-02-03 18:59:04



--- Comment #2 from Bill Pemberton  ---
Updated rpm has been submitted to rawhide


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2166962
___
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: libgit2 1.5.x in rawhide with compat packages for 1.3.x and 1.4.x

[Josh Stone]

On 2/3/23 8:04 AM, Pete Walter wrote:
> I took over libgit2 from Igor when he gave up all his packages and have
> since tried to get it up to date. libgit2 is a bit special because it
> bumps soname every once in a while and then other packages often fail to
> rebuild against the new version both because of libgit2 API changes and
> because they are FTBFS due to unrelated issues (hi new gcc). libgit2 is
> also network facing and due to this has a high number of security issues
> so it is very important to keep it up to date.
>  
> I think I have a good plan now how to keep it up to date without too
> much disruption and it is as follows:
>  
> Update libgit2 to new version in rawhide as soon as it is released. At
> the same time, create a compat package for the old API and add it to
> rawhide. Keep the old API compat package in rawhide for 6 months or as
> long as it takes for everything to switch over to the latest version.
>  
> Today, we have 3 versions in rawhide (libgit2 was updated from 1.3.x to
> 1.4.x and then 1.5.x over the last month and the compat packages were
> added today):
>  
> libgit2 package with version 1.5.1 (security supported still from upstream)
> libgit2_1.4 package with version 1.4.5 (security supported still from
> upstream)
> libgit2_1.3 package with version 1.3.2 (EOL upstream)

Thank you for taking care of this! I've had rust (subpkg cargo) using
its own bundled copy due to the lack of updates, but I'll happily flip
that back. Since Rust bootstraps itself, it's important to always have
the old version working while I rebuild to a new version, but the compat
scheme should be fine -- we do the same for LLVM libs.

(Note regarding that 1.5.1 security issue, cargo fixed it independently
in 1.66.1, so there's no bundling worry about that one.)

> I intend to retire libgit2_1.3 as soon as git-time-metric
> (https://bugzilla.redhat.com/show_bug.cgi?id=2162852
> ) and
> golang-github-libgit2-git2go
> (https://bugzilla.redhat.com/show_bug.cgi?id=2152113
> ) are fixed.
> I intend to retire libgit2_1.4 as soon as julia
> (https://bugzilla.redhat.com/show_bug.cgi?id=2165534
> ) and
> rpm-git-tag-sort (https://bugzilla.redhat.com/show_bug.cgi?id=2165535
> ) are fixed.
>  
> The rest of the dependencies are already rebuilt to use libgit2.
>  
> I think this kind of compat package system could even allow updating
> libgit2 to latest versions in stable Fedora branches and in EPEL. I want
> to test this out in rawhide first though and see if it works well enough.
>  
> Pete
> 
> ___
> 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: shorter shutdown timers are now enabled in rawhide

[Kevin Fenzi]

On Fri, Feb 03, 2023 at 06:32:20PM +0100, Fabio Valentini wrote:
> 
> It's a 1:1 copy of the update "notes" from bodhi (except re-flowed to
> fit into however many columns plain-text emails support).
> So it's "markdown", not "awful", but sometimes it's hard to see the
> difference ;)
> Not sure if it would be possible for bodhi to convert markdown update
> notes to "plain text" (i.e. drop all markup) before including it in
> the emails it sends out ...

Yeah. Please file RFE at https://github.com/fedora-infra/bodhi ?

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Fabio Valentini]

On Fri, Feb 3, 2023 at 6:27 PM Vít Ondruch  wrote:
>
> I have just realized, that the rpmautospec is not documented in the
> guidelines (unless my search-fu is failing me). Therefore I consider it
> strange that we should go from "no documentation at all" to "use it by
> default". I don't think this is right.
>
> IOW why is it not documented yet as an optional feature?

Well ... because nobody has submitted any proposal of documenting this
to the Packaging Guidelines?

I put it on my TODO list to write up rpmautospec documentation for the
Packaging Guidelines a while ago ... but TODO list keeps growing and
less important things keep getting pushed to the bottom of the list.
:)

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Fabio Valentini]

On Tue, Jan 10, 2023 at 1:53 PM Richard Shaw  wrote:
>
> On Tue, Jan 10, 2023 at 1:16 AM Zbigniew Jędrzejewski-Szmek 
>  wrote:
>>
>> On Mon, Jan 09, 2023 at 09:37:44PM -0600, Richard Shaw wrote:
>> > Now I'm getting bit by the rpmautospec and COPR issue.
>>
>> Please be more precise. How are you building the rpms?
>
>
> The SRPMS? I'm using "rpkg build "
>
>
>>
>> If rpmautospec is used in COPR, and the build is started in a
>> compatible way, the release field should be the same as in koji.
>>
>> > I'm trying to test rebuilds of all dependent packages for a new OpenColorIO
>> > release, but usd uses rpmautospec and in Fedora it's usd--16 but
>> > COPR is calculating it as usd--9 so the Fedora version has a
>> > higher NEVR.
>>
>> First of all, if you e.g. want to test the rebuilt packages on your system,
>> you can always install a lower version than the one currently released.
>> Dnf allows both downgrades and installations of a specific package and
>> a specific package version.
>
>
> I don't want to test the packages per say, I just need COPR to pull in the 
> rebuilt package instead of the one in Fedora, otherwise I get dnf conflicts:
>
>  Problem: package usd-libs-22.05b-16.fc38.x86_64 requires 
> libOpenColorIO.so.2.1()(64bit), but none of the providers can be installed
>   - cannot install both OpenColorIO-2.1.2-5.fc38.1.x86_64 and 
> OpenColorIO-2.2.0-1.fc38.x86_64
>   - package usd-devel-22.05b-16.fc38.x86_64 requires usd-libs(x86-64) = 
> 22.05b-16.fc38, but none of the providers can be installed
>   - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires 
> libOpenColorIO.so.2.2()(64bit), but none of the providers can be installed
>   - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires 
> OpenColorIO(x86-64) = 2.2.0-1.fc38, but none of the providers can be installed
>
> - cannot install the best candidate for the job
>
>
>>
>> Second, how exactly are you building the package?
>> Looking at [1], you used "Source Type: SRPM or .spec file upload".
>> How was it generated?
>>
>> [1] https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/
>>
>> Both 'fedpkg srpm' and uploading that to copr, and letting copr build from
>> dist-git should result in the expected release. (Though without other steps
>> it'll still be the same as the version in Fedora release, so you'll need
>> to tell dnf to install that specific build.)
>
>
> Looks like the problem is using `rpkg` but that's the easiest method and has 
> worked great until now...

Well, it was only a matter of time until rpkg stopped working.
It was abandoned a while ago and was officially marked as "no longer
maintained" last year:
https://pagure.io/rpkg-util

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

Re: shorter shutdown timers are now enabled in rawhide

[Fabio Valentini]

On Fri, Feb 3, 2023 at 11:53 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Feb 02, 2023 at 08:11:41PM +, upda...@fedoraproject.org wrote:
> > The following comment has been added to the systemd-253~rc2-2.fc38 update:
>
> >Bugs: 2156900 - None
> >   Notes: Automatic update for systemd-253~rc2-2.fc38.  # 
> > **Changelog**
> >: ``` * Thu Feb  2 2023 Michael Catanzaro
> >:  - 253~rc2-2 - Shorten shutdown
> >: timeout to 45 s * Thu Feb  2 2023 Zbigniew
> >: Jędrzejewski-Szmek  - 253~rc2-1 -
> >: Version 253~rc2 - Sysusers fixup (rhbz#2156900) +
> >: other small changes * Thu Feb  2 2023 Yaakov Selkowitz
> >:  - 253~rc1-5 - Build with xen
> >: only on Fedora  ```
> >   Submitter: zbyszek
> >   Submitted: 2023-02-02 20:11:41.724093
> >Comments: bodhi - 2023-02-02 20:11:41.727324 (karma 0)
> >  This update was automatically created
> >
> >   https://bodhi.fedoraproject.org/updates/FEDORA-2023-2ac77d299f
>
> The automatic changelog entry says it all.
>
> --
>
> BTW. Could we make the text less awful? It was originally plain text…
> Why is all reformatted and surrounded with backticks?

It's a 1:1 copy of the update "notes" from bodhi (except re-flowed to
fit into however many columns plain-text emails support).
So it's "markdown", not "awful", but sometimes it's hard to see the
difference ;)
Not sure if it would be possible for bodhi to convert markdown update
notes to "plain text" (i.e. drop all markup) before including it in
the emails it sends out ...

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Vít Ondruch]

I have just realized, that the rpmautospec is not documented in the 
guidelines (unless my search-fu is failing me). Therefore I consider it 
strange that we should go from "no documentation at all" to "use it by 
default". I don't think this is right.


IOW why is it not documented yet as an optional feature?


Vít


Dne 30. 12. 22 v 20:01 Ben Cotton napsal(a):

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

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

== Summary ==
Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
the default approach.
Packaging Guidelines and other documentation are adjusted to describe
this approach first.
Various tools that provide spec file templates are adjusted.

== Owner ==
* Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
* Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl


== Detailed Description ==

{{admon/note|Brief reminder about rpmautospec|
The spec file contains:

Version: 1.2.3
Release: %autorelease
...
%changelog
%autochangelog

Rpmautospec uses git history. Whenever the package is built
(`.src.rpm` is generated), rpmautospec tooling will replace the
`%autorelease` macro with the number of commits since the last commit
that changed the `Version` field, and the `%autochangelog` macro with
a text generated from `git log`.
For details see the
[https://docs.pagure.org/fedora-infra.rpmautospec/principle.html
docs].
}}

Rpmautospec has been deployed in Fedora since F35
([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%).
But it is still a "second-class citizen": most documentation doesn't
mention it, and many packagers know that it exists but don't use it in
their packages. We think that it's reasonable to switch to
`%autorelease`+`%autochangelog` for almost all packages and that
Packaging Guidelines and various packaging howtos should recommend
that approach to packagers. The "traditional" approach of
manually-managed `Release` and `%changelog` will remain valid and will
be documented as a fallback.

This change is targeted at Fedora 38, but it will actually apply to
all releases. The goal is to update the Packaging Guidelines and other
prominent documentation and tools now, and other docs and tools
possibly at a later time. Changing packages is out of scope.

It is worth mentioning that `rust2rpm` uses
`%autorelease`+`%autochangelog` since a few releases, so most rust
packages have switched. (Generally, rust spec files are recreated
using the generator for each new version, so the switch would happen
whenever a new version is packaged unless the packager opts out.)

== Feedback ==

* Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/T6J2WGIMRCTW77QTH4D7HPNS6KUGDQOQ/
rpmautospec by default]
** open issues: a bunch have been fixed.
** maintenance: Nils will add some co-maintainers.
** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see
Scope section.

== Benefit to Fedora ==
Various packaging workflows become smoother for packagers and contributors:

* packagers don't need to touch the `Release` field on updates
* packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
* patches to the spec file can be cherry-picked between branches
without trivial conflicts
* pull requests on src.fedoraproject.org can be merged without trivial conflicts
* in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over

== Scope ==
* Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to
make `%autorelease`+`%autochangelog` the default
** implement fixes for issues reported by packagers
** make semi-regular releases of rpmautospec
([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/K5EA5OGRX2BCZ353C7S4MQVZTSH2BH63/
0.3.1 was released on November 17th, and should be deployed to
production in about two weeks])

* Other developers:
** provide pull requests to other docs as appropriate
** accept the changes to documentation
** update other spec file generators (pip2rpm, others?)

* Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641
** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the
command will fail. A replacement workflow that instead restores
`%autorelease`+`%autochangelog` in the file committed to dist-git
needs to be implemented.

* Related work
** https://pagure.io/rpkg/c/3087dd7
** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4


* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

* Policies and guidelines: a list of places to be updated
** 

[Bug 2166962] perl-Rose-DB-0.784 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Scratch build failed. Details below:

GenericError: Invalid method: krb_login
Traceback:
  File
"/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
195, in build
session = self._session_maker()
  File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
422, in _session_maker
result = koji_session.krb_login(
  File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 2362, in
__call__
return self.__func(self.__name, args, opts)
  File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 2874, in
_callMethod
raise err

If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues


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

[bugzilla]

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

Bug ID: 2166962
   Summary: perl-Rose-DB-0.784 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Rose-DB
  Keywords: FutureFeature, Triaged
  Assignee: wf...@worldbroken.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
wf...@worldbroken.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.784
Upstream release that is considered latest: 0.784
Current version/release in rawhide: 0.783-11.fc38
URL: http://search.cpan.org/dist/Rose-DB/

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


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


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


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2166962
___
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: List of long term FTBFS packages to be retired next week

[Gary Buhrmaster]

On Tue, Jan 31, 2023 at 12:45 PM Miro Hrončok  wrote:

> If you see a package that can be rebuilt, please do so.

> tpm2-tss-engine mzavalavz


No longer FTBFS. It can be removed from the
to be retired list.

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

libgit2 1.5.x in rawhide with compat packages for 1.3.x and 1.4.x

[Pete Walter]

I took over libgit2 from Igor when he gave up all his packages and have since tried to get it up to date. libgit2 is a bit special because it bumps soname every once in a while and then other packages often fail to rebuild against the new version both because of libgit2 API changes and because they are FTBFS due to unrelated issues (hi new gcc). libgit2 is also network facing and due to this has a high number of security issues so it is very important to keep it up to date. I think I have a good plan now how to keep it up to date without too much disruption and it is as follows: Update libgit2 to new version in rawhide as soon as it is released. At the same time, create a compat package for the old API and add it to rawhide. Keep the old API compat package in rawhide for 6 months or as long as it takes for everything to switch over to the latest version. Today, we have 3 versions in rawhide (libgit2 was updated from 1.3.x to 1.4.x and then 1.5.x over the last month and the compat packages were added today): libgit2 package with version 1.5.1 (security supported still from upstream)libgit2_1.4 package with version 1.4.5 (security supported still from upstream)libgit2_1.3 package with version 1.3.2 (EOL upstream) I intend to retire libgit2_1.3 as soon as git-time-metric (https://bugzilla.redhat.com/show_bug.cgi?id=2162852) and golang-github-libgit2-git2go (https://bugzilla.redhat.com/show_bug.cgi?id=2152113) are fixed.I intend to retire libgit2_1.4 as soon as julia (https://bugzilla.redhat.com/show_bug.cgi?id=2165534) and rpm-git-tag-sort (https://bugzilla.redhat.com/show_bug.cgi?id=2165535) are fixed. The rest of the dependencies are already rebuilt to use libgit2. I think this kind of compat package system could even allow updating libgit2 to latest versions in stable Fedora branches and in EPEL. I want to test this out in rawhide first though and see if it works well enough. Pete___
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: bodhi tests missing

[Petr Pisar]

V Fri, Feb 03, 2023 at 07:40:09AM -0700, Orion Poplawski napsal(a):
> I've got a couple updates with missing tests:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-96ebcd6f4d
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-23e26fcc32
> 
That happens when CI is slow or broken. Or when a message bus about finising
the tests was not properly stored into test results database. Also some tests
performed in Rawhide are not performed in stable Fedoras, based on global CI
configuration.

> it seems like I used to have the option to resubmit the tests but I don't
> see that now.  Is my only option to waive the test results?
> 
Try a command line: bodhi updates trigger-tests FEDORA-2023-96ebcd6f4d.

-- 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: Rawhide and debug kernel changes

[Dan Horák]

On Fri, 3 Feb 2023 08:03:10 -0600
Justin Forbes  wrote:

> On Fri, Feb 3, 2023 at 6:52 AM Dan Horák  wrote:
> >
> > On Thu, 2 Feb 2023 14:17:36 -0600
> > Justin Forbes  wrote:
> >
> > > As the MR is now merged, it is a good time to make sure that everyone
> > > is aware. As of 6.2-rc5, Rawhide is no longer forcing a debug build
> > > with any kernels. All rawhide kernels are now built just like stable
> > > Fedora kernels, with both non-debug and debug variations.   This
> > > change was necessary because performance has degraded with debug
> > > kernels to the point that there were very few people using them,
> > > meaning fewer people testing daily upstream development builds.
> > > Changing the config to make the performance acceptable to more would
> > > take away much of the usefulness of the debug builds to begin with.
> > > We do still appreciate those who have the patience and ability to run
> > > rawhide debug kernels when possible just because they do still find
> > > the occasional lockdep issue, or other problems that would be hidden
> > > by a non-debug kernel.
> > >
> > > In addition to this change, I have added debug builds for aarch64
> > > kernels.  Previously, debug kernels were only available on x86.
> >
> > do you plan to still populate the RawhideKernelNodebug repo with the
> > current kernel rcs for use on the stable releases?
> 
> I had planned to discontinue this, but I suppose I can continue if
> there is value in it.

yes, please. I find the weekly frequency of the rcs combined with stable
Fedoras as the right compromise to be able to provide some useful
feedback. Hopefully I am not alone :-)


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

bodhi tests missing

[Orion Poplawski]

I've got a couple updates with missing tests:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-96ebcd6f4d
https://bodhi.fedoraproject.org/updates/FEDORA-2023-23e26fcc32

it seems like I used to have the option to resubmit the tests but I 
don't see that now.  Is my only option to waive the test results?


--
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: Rawhide and debug kernel changes

[Justin Forbes]

On Fri, Feb 3, 2023 at 6:52 AM Dan Horák  wrote:
>
> On Thu, 2 Feb 2023 14:17:36 -0600
> Justin Forbes  wrote:
>
> > As the MR is now merged, it is a good time to make sure that everyone
> > is aware. As of 6.2-rc5, Rawhide is no longer forcing a debug build
> > with any kernels. All rawhide kernels are now built just like stable
> > Fedora kernels, with both non-debug and debug variations.   This
> > change was necessary because performance has degraded with debug
> > kernels to the point that there were very few people using them,
> > meaning fewer people testing daily upstream development builds.
> > Changing the config to make the performance acceptable to more would
> > take away much of the usefulness of the debug builds to begin with.
> > We do still appreciate those who have the patience and ability to run
> > rawhide debug kernels when possible just because they do still find
> > the occasional lockdep issue, or other problems that would be hidden
> > by a non-debug kernel.
> >
> > In addition to this change, I have added debug builds for aarch64
> > kernels.  Previously, debug kernels were only available on x86.
>
> do you plan to still populate the RawhideKernelNodebug repo with the
> current kernel rcs for use on the stable releases?

I had planned to discontinue this, but I suppose I can continue if
there is value in it.

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

Issue with hardened build

[Paul Howarth]

Hi all,

I recently received a bug report
(https://bugzilla.redhat.com/show_bug.cgi?id=2166454) about
proftpd not being able to load a dynamic module (mod_rewrite) that
provides some optional functionality. This module is not used by
default and has to be enabled manually. The ticket was raised for
EPEL-9 but I can reproduce the issue on my Fedora 37 machine.

I raised the issue upstream
(https://github.com/proftpd/proftpd/issues/1590) and after some
experimentation, it appears that turning off hardened build (by
undefining _hardened_build) results in a build that can load the module.
I can also add -fstack-protector-strong back into optflags without it
breaking. Various other of proftpd's optional modules work OK
regardless of the hardened build state.

The hardened build has been enabled in proftpd for a long time so I
don't know if it's recently stopped working or nobody ever used
mod_rewrite with the packaged builds.

Any ideas why this should be happening? I'd really rather not disable
the hardened build for a complex internet-facing server like proftpd.

Regards, Paul.
___
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: Rawhide and debug kernel changes

[Dan Horák]

On Thu, 2 Feb 2023 14:17:36 -0600
Justin Forbes  wrote:

> As the MR is now merged, it is a good time to make sure that everyone
> is aware. As of 6.2-rc5, Rawhide is no longer forcing a debug build
> with any kernels. All rawhide kernels are now built just like stable
> Fedora kernels, with both non-debug and debug variations.   This
> change was necessary because performance has degraded with debug
> kernels to the point that there were very few people using them,
> meaning fewer people testing daily upstream development builds.
> Changing the config to make the performance acceptable to more would
> take away much of the usefulness of the debug builds to begin with.
> We do still appreciate those who have the patience and ability to run
> rawhide debug kernels when possible just because they do still find
> the occasional lockdep issue, or other problems that would be hidden
> by a non-debug kernel.
> 
> In addition to this change, I have added debug builds for aarch64
> kernels.  Previously, debug kernels were only available on x86.

do you plan to still populate the RawhideKernelNodebug repo with the
current kernel rcs for use on the stable releases?


Dan
___
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: openmpi 5.0.0 drops 32-bit support

[Fabio Valentini]

On Fri, Feb 3, 2023 at 5:20 AM Orion Poplawski  wrote:
>
> As a heads up - openmpi 5.0.0 drops support for 32-bit builds [1].  I'm
> not sure how far away it is from release - we're on rc10 at the moment.
>
> Affected packages seem to be:
>
> amg4psblas-1.1.0-4.fc38.src.rpm
> arbor-0.7-4.fc38.src.rpm
> auryn-0.8.2-15.fc38.src.rpm
> boost-1.78.0-11.fc38.src.rpm
> bout++-4.4.2-5.fc37.src.rpm
> cgnslib-4.3.0-6.fc38.src.rpm
> cgnslib-4.3.0-7.fc38.src.rpm
> coin-or-Ipopt-3.14.9-2.fc38.src.rpm
> combblas-1.6.2-0.15.beta2.fc37.src.rpm
> cp2k-2023.1-2.fc38.src.rpm
> dolfin-2019.1.0.post0-36.fc38.src.rpm
> elpa-2022.05.001-2.fc38.src.rpm
> fftw-3.3.10-3.fc37.src.rpm
> freefem++-4.12-2.fc38.src.rpm
> ga-5.7.2-13.fc38.src.rpm
> gmsh-4.11.1-3.fc38.src.rpm
> gpaw-22.8.0-5.fc38.src.rpm
> gretl-2022c-2.fc38.src.rpm
> h5py-3.7.0-4.fc38.src.rpm
> hdf5-1.12.1-11.fc38.src.rpm
> hpx-1.8.1-1.fc37.src.rpm
> hypre-2.24.0-3.fc37.src.rpm
> intel-mpi-benchmarks-2021.3-3.fc38.src.rpm
> lammps-20220623-3.fc38.src.rpm
> libcircle-0.3-12.fc38.src.rpm
> libneurosim-1.2.0-6.20210110.gitafc003f.fc38.src.rpm
> mathgl-8.0.1-2.fc38.src.rpm
> mpi4py-3.1.4-2.fc38.src.rpm
> MUMPS-5.5.1-1.fc38.src.rpm
> MUSIC-1.1.16-10.20201002git8c6b77a.fc38.src.rpm
> nest-3.3-1.fc38.src.rpm
> netcdf-4.9.0-5.fc38.src.rpm
> netcdf-cxx4-4.3.1-8.fc38.src.rpm
> netcdf-fortran-4.5.4-3.fc38.src.rpm
> netgen-mesher-6.2.2202-5.fc38.src.rpm
> neuron-8.0.2-6.fc38.src.rpm
> nwchem-7.0.2-12.fc38.src.rpm
> openmpi-4.1.4-8.fc38.src.rpm
> paraview-5.11.0-3.fc38.src.rpm
> petsc-3.17.4-7.fc38.src.rpm
> psblas3-3.8.0-3.fc37.src.rpm
> python-dijitso-2019.1.0-12.fc38.src.rpm
> python-ffc-2019.1.0.post0-11.fc38.src.rpm
> python-lfpy-2.2.6-6.fc38.src.rpm
> python-steps-3.6.0-27.fc38.src.rpm
> quantum-espresso-7.0-5.fc38.src.rpm
> scalapack-2.2.0-3.fc38.src.rpm
> scotch-6.1.2-3.fc37.src.rpm
> sundials2-2.7.0-12.fc38.src.rpm
> sundials-5.8.0-11.fc38.src.rpm
> superlu_dist-8.1.1-1.fc38.src.rpm
> vtk-9.2.5-2.fc38.src.rpm
>
> Personally I've been planning on dropping 32-bit support in a buch of
> packages I maintain in this stack like vtk, paraview, etc.  This seems
> like as good a driver for it as any.
>
> That said, packages that build serial and parallel versions don't need
> to drop 32-bit support completely, just for the openmpi builds.

I assume this update will only be pushed to rawhide when it's ready?
Then you should be fine dropping i686 support when that happens
(assuming that dependent packages get the same ExcludeArch treatment,
of course).
The only thing that's not OK as far as I know is dropping support for
architectures during the lifetime of a stable release.

You don't even need to file paperwork for excluding i686 anymore since
this happened:
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval

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

shorter shutdown timers are now enabled in rawhide

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 02, 2023 at 08:11:41PM +, upda...@fedoraproject.org wrote:
> The following comment has been added to the systemd-253~rc2-2.fc38 update:

>Bugs: 2156900 - None
>   Notes: Automatic update for systemd-253~rc2-2.fc38.  # **Changelog**
>: ``` * Thu Feb  2 2023 Michael Catanzaro
>:  - 253~rc2-2 - Shorten shutdown
>: timeout to 45 s * Thu Feb  2 2023 Zbigniew
>: Jędrzejewski-Szmek  - 253~rc2-1 -
>: Version 253~rc2 - Sysusers fixup (rhbz#2156900) +
>: other small changes * Thu Feb  2 2023 Yaakov Selkowitz
>:  - 253~rc1-5 - Build with xen
>: only on Fedora  ```
>   Submitter: zbyszek
>   Submitted: 2023-02-02 20:11:41.724093
>Comments: bodhi - 2023-02-02 20:11:41.727324 (karma 0)
>  This update was automatically created
> 
>   https://bodhi.fedoraproject.org/updates/FEDORA-2023-2ac77d299f

The automatic changelog entry says it all.

--

BTW. Could we make the text less awful? It was originally plain text…
Why is all reformatted and surrounded with backticks?

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: [Scitech] openmpi 5.0.0 drops 32-bit support

[Dominik 'Rathann' Mierzejewski]

On Friday, 03 February 2023 at 05:20, Orion Poplawski wrote:
> As a heads up - openmpi 5.0.0 drops support for 32-bit builds [1].  I'm not
> sure how far away it is from release - we're on rc10 at the moment.
[...]
> Personally I've been planning on dropping 32-bit support in a buch of
> packages I maintain in this stack like vtk, paraview, etc.  This seems like
> as good a driver for it as any.
> 
> That said, packages that build serial and parallel versions don't need to
> drop 32-bit support completely, just for the openmpi builds.
> 
> 1 - https://github.com/open-mpi/ompi/pull/11282

Thanks for the heads-up, Orion. We are affected by this bug[2], anyway,
and I guess it's not going to be fixed upstream. At least two of the
affected packages have ExcludeArch: %{ix86} already. I'll proceed to
exclude openmpi subpackages on i686, too.

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2142304

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2166858] New: perl-Data-Dump-Color-0.249 is available

[bugzilla]

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

Bug ID: 2166858
   Summary: perl-Data-Dump-Color-0.249 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Data-Dump-Color
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.249
Upstream release that is considered latest: 0.249
Current version/release in rawhide: 0.248-6.fc38
URL: http://search.cpan.org/dist/Data-Dump-Color/

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


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


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


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


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


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