Re: Update of catch to Catch2 v3

2023-02-23 Thread Vitaly Zaitsev via devel

On 22/02/2023 12:37, Tom Hughes via devel wrote:

I have now added catch2 (for Catch2 v2.x) and upgraded the catch
package to Catch2 v3.x in rawhide and f38.


All my catch-dependent packages are now failing due to the missing 
catch.hpp header:


tests.cpp:32:10: fatal error: catch.hpp: No such file or directory
   32 | #include "catch.hpp"
  |  ^~~
compilation terminated.

Catch v3 is no longer a single-header library?

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


Bodhi_enabled ? Re: F38 Change complete (100% complete) deadline today

2023-02-23 Thread Sérgio Basto
On Tue, 2023-02-21 at 16:40 -0500, Ben Cotton wrote:
> As of today, F38 Changes should be 100% complete. Change owners can
> indicate this by setting the Bugzilla tracker to the ON_QA state. F38
> enters beta freeze today. Any updates that need to land in the beta
> release will require an approved freeze exception or beta blocker.
> 
> The current beta target is the early target date of 14 March.
> 
> More schedule details are available at
> https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html


ok, we also have "Bodhi updates-testing activation point" 

I just notice many fc38 packages in bodhi -> "create new update" that
weren't sent to updates-testing. 

> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to
> devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

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


Re: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Daniel Alley
Are you saying that DNF does an exact version match instead of making the 
assumption that packages with version >= X contain a fix for a security bug 
which the updateinfo declares to be fixed in X?  Or that the updateinfo itself 
gets purged of advisories that don't apply to the latest versions available.
___
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

2023-02-23 Thread updates
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-66548f784b   
openssl11-1.1.1k-5.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-acd256a168   
gssntlmssp-1.2.0-1.el7


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

ipmctl-compat-02.00.00.3885-02.00.00.3885-2.el7

Details about builds:



 ipmctl-compat-02.00.00.3885-02.00.00.3885-2.el7 (FEDORA-EPEL-2023-aa3ef32878)
 Utility for managing Intel Optane DC persistent memory modules

Update Information:

Initial release of compat for other projects that are depend on the Release 2.x
of ipmctl. New projects and new releases of existing projects should use the
ipmctl release.

ChangeLog:

* Thu Feb 23 2023 Steven Pontsler  - 02.00.00.3885-2
- Change to python from python3 and make from cmake
* Thu Feb 23 2023 Steven Pontsler  - 02.00.00.3885-1
- Compat based on Release 02.00.00.3885


___
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

2023-02-23 Thread updates
The following builds have been pushed to Fedora EPEL 8 updates-testing

ansible-lint-3.5.1-2.el8
onedrive-2.4.23-2.el8
python-pylero-0.0.7-1.el8

Details about builds:



 ansible-lint-3.5.1-2.el8 (FEDORA-EPEL-2023-7238d2a613)
 Best practices checker for Ansible

Update Information:

Rebuild for new ansible build

ChangeLog:

* Thu Feb 23 2023 Parag Nemade  - 3.5.1-2
- Rebuild for new ansible build
- Adapt ansible packaging change that is build against python39 package
- Disable tests as required test deps are not available

References:

  [ 1 ] Bug #2171313 - FTI python3-ansible-lint
https://bugzilla.redhat.com/show_bug.cgi?id=2171313




 onedrive-2.4.23-2.el8 (FEDORA-EPEL-2023-e2078d51cd)
 OneDrive Free Client written in D

Update Information:

Add OneDrive for EPEL8

ChangeLog:

* Thu Feb 23 2023 Zamir SUN  - 2.4.23-2
- Support EPEL8
* Mon Feb  6 2023 Zamir SUN  - 2.4.23-1
- Update to 2.4.23
* Thu Jan 19 2023 Fedora Release Engineering  - 
2.4.21-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Sat Aug 13 2022 Zamir SUN  - 2.4.21-1
- Update to 2.4.21
* Sat Aug 13 2022 Zamir SUN  - 2.4.20-1
- Update to 2.4.20
* Wed Jul 27 2022 Kalev Lember  - 2.4.19-3
- Rebuilt for ldc 1.30
* Fri Jul 22 2022 Fedora Release Engineering  - 
2.4.19-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Tue Jun 28 2022 Zamir SUN  - 2.4.19-1
- Update to 2.4.19
* Fri Jun  3 2022 Fedora Release Monitoring 
 - 2.4.18-1
- Update to 2.4.18 (#2093172)
* Sat Apr 30 2022 Fedora Release Monitoring 
 - 2.4.17-1
- Update to 2.4.17 (#2080550)
* Thu Mar 10 2022 Fedora Release Monitoring 
 - 2.4.16-1
- Update to 2.4.16 (#2036387)
* Thu Jan 20 2022 Fedora Release Engineering  - 
2.4.14-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Wed Nov 24 2021 Fedora Release Monitoring 
 - 2.4.14-1
- Update to 2.4.14 (#2026496)
* Tue Aug 17 2021 Kalev Lember  - 2.4.13-4
- Rebuilt for ldc 1.27
* Thu Jul 22 2021 Fedora Release Engineering  - 
2.4.13-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Fri Jul 16 2021 Zamir SUN  - 2.4.13-2
- Fix rpath issue
* Wed Jul 14 2021 Marcel <34819524+marcelcod...@users.noreply.github.com> - 
2.4.13-1
- Update to 2.4.13
* Fri Jul  2 2021 Marcel <34819524+marcelcod...@users.noreply.github.com> - 
2.4.12-1
- Update to 2.4.12
* Mon Feb 22 2021 Kalev Lember  - 2.4.8-3
- Rebuilt for ldc 1.25
* Tue Jan 26 2021 Fedora Release Engineering  - 
2.4.8-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
* Sun Dec 13 2020 Zamir SUN  - 2.4.8-1
- Update to 2.4.8 to apply more fixes
* Sat Nov 28 2020 Zamir SUN  - 2.4.7-1
- Update to 2.4.7
* Fri Aug 21 2020 Kalev Lember  - 2.4.5-2
- Rebuilt for ldc 1.23
* Sat Aug 15 2020 Zamir SUN  - 2.4.5-1
- Update to 2.4.5
* Tue Jul 28 2020 Fedora Release Engineering  - 
2.4.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Wed May 27 2020 Thomas Drake-Brockman  - 2.4.2-1
- Update to 2.4.2 (#1840773)
* Mon May 18 2020 Zamir SUN  - 2.4.1-1
- Update to 2.4.1
* Sun Apr 19 2020 Alan Pevec  2.4.0-1
- Update to 2.4.0
* Mon Feb 10 2020 Kalev Lember  - 2.3.12-3
- Rebuilt for ldc 1.20
* Wed Jan 29 2020 Fedora Release Engineering  - 
2.3.12-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Tue Dec 17 2019 Thomas Drake-Brockman  - 2.3.12-1
- Update to 2.3.12
* Wed Oct  2 2019 Zamir SUN  - 2.3.10-1
- Update to 2.3.10
* Mon Aug 19 2019 David Va  - 2.3.8-1
- Update to 2.3.8 for bug fixes
* Thu Jul 25 2019 Fedora Release Engineering  - 
2.3.7-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Sat Jul  6 2019 Thomas Drake-Brockman  - 2.3.7-1
- Update to 2.3.7 for bug fixes
* Thu Jun 20 2019 Zamir SUN  - 2.3.5-1
- Update to 2.3.5 to apply some more fixes
* Sat Jun 15 2019 Zamir SUN  - 2.3.4-1
- Update to 2.3.4 for bug fixes
* Tue Apr  9 2019 Kalev Lember  - 2.3.2-2
- Rebuilt for ldc 1.15
* Wed Apr  3 2019 Zamir SUN  - 2.3.2-1
- Update to 2.3.2 to bring in bugfixes.
- Resolves: 1695392
* Thu Mar  7 2019 Tim Landscheidt  - 2.2.1-5
- Remove obsolete requirement for %post scriptlet
* Mon Feb 18 2019 Kalev Lember  - 2.2.1-4
- Rebuilt for ldc 1.14
* Fri Feb  1 2019 Fedora Release Engineering  - 
2.2.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Tue Dec  4 2018 Zamir SUN  - 

Re: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Kevin Kofler via devel
Kevin Fenzi wrote:
> I'm not sure what a solution could be. Keep every update in updateinfo
> so dnf could tell you that there's 2 updates and 1 is security and the
> other bugfix? but then we would need to also keep those updates around
> to update to.

Add a repodata field "last security update EVR" that would be filled in by 
Bodhi for any non-security update. Then DNF would just need to check whether 
the installed EVR is less than the value of that field and treat the update 
as a security update in that case.

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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Kevin Kofler via devel
Michael Catanzaro wrote:
> On Fri, Feb 24 2023 at 12:00:40 AM +0100, Björn Persson
>  wrote:
>> There are also other dangers with installing only security fixes. If a
>> bugfix is released and packaged, and later it's discovered that the
>> bug
>> had security implications, then no security update will be made
>> because
>> the fix is already packaged. It might be possible to set a security
>> flag on the update after the fact, but nobody will bother with that.
>> 
>> I would therefore advise against using --security. If one can't
>> install
>> all the updates continuously, then one should use a more stable
>> distribution than Fedora.
> 
> tbh I'd go so far as to propose that this functionality should not be
> reimplemented in dnf5 at all.

I would personally not miss --security, but what is really useful is the 
--advisory=… flag that used to be implemented by the same plugin. (They are 
now both built in in DNF.) That is invaluable to test individual updates 
from updates-testing. I would consider the absence of --advisory=… a 
dealbreaker.

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: Changes to Bugzilla API key requirements

2023-02-23 Thread Kevin Kofler via devel
Matthew Miller wrote:
> The "good news" is that Red Hat has announced a move away from Bugzilla
> for future products. (They're going to Jira.)

Ah right, I had forgotten about that issue. I do not think I will ever 
understand the fascination some projects have for JIRA. It is proprietary, 
and IMHO the web UI for users to report bugs in JIRA is very confusing at 
times. (The Bugzilla one can be confusing at times as well, but at least it 
is familiarly confusing. ;-) )

So Fedora will have to move on anyway. Hopefully not to a proprietary 
solution as RHEL is doing.

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


[Bug 2172670] perl-HTTP-Daemon-6.15 is available

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172670

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-d04facf6ce has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-d04facf6ce

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


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

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2173127

Bug ID: 2173127
   Summary: perl-HTTP-Daemon-6.16 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-HTTP-Daemon
  Keywords: FutureFeature, Triaged
  Assignee: mspa...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 6.16
Upstream release that is considered latest: 6.16
Current version/release in rawhide: 6.15-1.fc39
URL: http://search.cpan.org/dist/HTTP-Daemon/

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2173127
___
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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Globe Trotter via devel
Looks good here too:

Downgrading:
 Lmod x86_64 8.7.18-1.fc38 fedora 258 k
 festival-data    noarch 2.5.0-16.fc38 fedora 1.2 M
 fwupd    x86_64 1.8.10-1.fc38 fedora 1.8 M
 fwupd-plugin-flashrom    x86_64 1.8.10-1.fc38 fedora  26 k
 fwupd-plugin-modem-manager   x86_64 1.8.10-1.fc38 fedora  60 k
 fwupd-plugin-uefi-capsule-data   x86_64 1.8.10-1.fc38 fedora 1.8 M
 gh   x86_64 2.22.1-1.fc38 fedora 8.3 M
 mock-core-configs    noarch 38.1-1.fc38   fedora 141 k
 python3-xlsxwriter   noarch 3.0.7-1.fc38  fedora 327 k
 scrot    x86_64 1.7-4.fc38    fedora  79 k









___
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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Adam Williamson
On Fri, 2023-02-24 at 10:17 +1100, Ian Laurie wrote:
> On 2/22/23 20:30, Miroslav Suchý wrote:
> > Do you want to make Fedora 38 better? Please spend 1 minute of your time 
> > and try to run:
> 
> Looked good here, just some downgrades as follows:
> 
> Downgrading:
>   fwupdx86_64 1.8.10-1.fc38
>   fwupd-plugin-flashromx86_64 1.8.10-1.fc38
>   fwupd-plugin-modem-manager   x86_64 1.8.10-1.fc38
>   fwupd-plugin-uefi-capsule-data x86_64   1.8.10-1.fc38
>   inxi noarch 3.3.24-2.fc38
>   mock-core-configsnoarch 38.1-1.fc38

the fwupd 1.8.11 build for F38 was overlooked, I think. I've pinged
Richard about it on a related bug report.
-- 
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


Re: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Reon Beon via devel
Should it be replaced with rsync?
___
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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Solomon Peachy via devel
On Wed, Feb 22, 2023 at 10:30:40AM +0100, Miroslav Suchý wrote:
> dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo 
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync

F36 snowflake server:

Error: 
 Problem: package python3-PyDrive-1.3.1-19.fc36.noarch requires python(abi) = 
3.10, but none of the providers can be installed
  - python3-3.10.9-1.fc36.x86_64 does not belong to a distupgrade repository
  - problem with installed package python3-PyDrive-1.3.1-19.fc36.noarch

 (as an aside, this is the cleanest upgrade I can remember this server 
seeing...)

F37 workstation:

Error: 
 Problem 1: package opencolorio1-1.1.1-3.fc37.x86_64 requires 
libyaml-cpp.so.0.6()(64bit), but none of the providers can be installed
  - yaml-cpp-0.6.3-7.fc37.x86_64 does not belong to a distupgrade repository
  - problem with installed package opencolorio1-1.1.1-3.fc37.x86_64
 Problem 2: package blender-1:3.4.1-11.fc38.x86_64 requires 
libembree3.so.3()(64bit), but none of the providers can be installed
  - problem with installed package blender-1:3.4.1-2.fc37.x86_64
  - embree-3.13.5-3.fc37.x86_64 does not belong to a distupgrade repository
  - blender-1:3.4.1-2.fc37.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)

F37 laptop:

 Success, but with these downgrades:

 fwupd   x86_64 1.8.10-1.fc38fedora 1.8 M
 fwupd-plugin-flashrom   x86_64 1.8.10-1.fc38fedora  26 k
 fwupd-plugin-modem-manager  x86_64 1.8.10-1.fc38fedora  60 k
 fwupd-plugin-uefi-capsule-data
 x86_64 1.8.10-1.fc38fedora 1.8 M
 inxinoarch 3.3.24-2.fc38fedora 493 k
 libmsi1 x86_64 0.101.32-3.fc36  fedora 110 k
 msitoolsx86_64 0.101.32-3.fc36  fedora 551 k
 python3-xlsxwriter  noarch 3.0.7-1.fc38 fedora 327 k

F37 server #1 & #2

  Success!  (same fwupd downgrade as above)

I have a few other systems but they're buried/offline in preparation for
a home office move.  Only one that's remotely unusual is an RPi3.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
Dowling Park, FL  speachy (libra.chat)


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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Orion Poplawski
Thanks for the heads up.  Looks like the update got stuck.  I've kicked 
it.  Now need to wait for the freeze to end.


https://bodhi.fedoraproject.org/updates/FEDORA-2023-fa1d678565

On 2/22/23 06:12, Steve Cossette wrote:

I just tried on a second PC, and I see this too on this one:

Lmod  x86_64 8.7.18-1.fc38 fedora    258 k

Seems Lmod is of a lower version on Fedora 38 as well, compared to 
Fedora 37.


Le mer. 22 févr. 2023, à 04 h 30, Miroslav Suchý > a écrit :


Do you want to make Fedora 38 better? Please spend 1 minute of your
time and try to run:

# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled
again
sudo dnf module reset '*'

dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo
--enablerepo=updates-testing-modular) \
--assumeno distro-sync


This command does not replace `dnf system-upgrade`, but it will
reveals potential problems.

You may also run `dnf upgrade` before running this command.


The `--assumeno` will just test the transaction, but does not make
the actual upgrade.


In case you hit dependency issues, please report it against the
appropriate package.

Or against fedora-obsolete-packages if that package should be
removed in Fedora 38. Please check existing reports against

fedora-obsolete-packages first:

https://red.ht/2kuBDPu 

and also there is already bunch of "Fails to install"
(F38FailsToInstall) reports:

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


Thank you

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



___
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


--
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 2173116] New: perl-SQL-Translator-1.63 is available

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2173116

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



Releases retrieved: 1.63
Upstream release that is considered latest: 1.63
Current version/release in rawhide: 1.62-9.fc38
URL: http://search.cpan.org/dist/SQL-Translator/

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2173116
___
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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Ian Laurie

On 2/24/23 10:17, Ian Laurie wrote:

On 2/22/23 20:30, Miroslav Suchý wrote:
Do you want to make Fedora 38 better? Please spend 1 minute of your 
time and try to run:


Looked good here, just some downgrades as follows:

Downgrading:
  fwupd    x86_64 1.8.10-1.fc38
  fwupd-plugin-flashrom    x86_64 1.8.10-1.fc38
  fwupd-plugin-modem-manager   x86_64 1.8.10-1.fc38
  fwupd-plugin-uefi-capsule-data x86_64   1.8.10-1.fc38
  inxi noarch 3.3.24-2.fc38
  mock-core-configs    noarch 38.1-1.fc38


Took it a step further, did an actual upgrade on a bare metal system, 
Fedora 37 Xfce to Fedora 38, worked fine.


Dell Precision T5610 2 x Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz
(8 cores total)
NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1)

Ian
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
___
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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Dennis Gilmore via devel
On Tue, Feb 21, 2023 at 2:48 PM Matthew Miller 
wrote:

> I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
> priority. Last time we talked about this we didn't really get anywhere...
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E
>
> ... and that ticket hasn't moved, because fixing it isn't trivial.
>
>
> What we're doing now — as has been the case for several years, already
> noted
> in the previous discussion — has very little end-user value. Also as noted
> in that thread (as in the ticket)... that's unfortunate, because it did
> bring some real benefits (and could possibly do even more.)
>
> But, I think it's time to move on. We have ostree and various
> container-delta approaches. We should focus on those — and give DeltaRPMs a
> sad, fond farewell.
>

The last updates just now on three different machines gave me
Delta RPMs reduced 284.9 MB of updates to 281.0 MB (1.4% saved)
Delta RPMs reduced 14.3 MB of updates to 3.3 MB (76.9% saved)
 and the third had no Delta RPMs

Outside of specific instances, the first or last results are typical.  I
think it is time to say goodbye. Times are very different from what they
were when we added support.

Dennis
___
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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Demi Marie Obenour
On 2/23/23 18:00, Björn Persson wrote:
> Gordon Messmer wrote:
>> Contrary-wise: Because Fedora updates only contains the latest built, 
>> once a build marked as a security fix is obsoleted by another build, 
>> there is no longer any indication that a security issue existed in any 
>> version, at which point "dnf update --security" no longer works.
> 
> There are also other dangers with installing only security fixes. If a
> bugfix is released and packaged, and later it's discovered that the bug
> had security implications, then no security update will be made because
> the fix is already packaged. It might be possible to set a security
> flag on the update after the fact, but nobody will bother with that.
> 
> I would therefore advise against using --security. If one can't install
> all the updates continuously, then one should use a more stable
> distribution than Fedora.
> 
> Björn Persson

I actually use --security for the *opposite* purpose: to get security
updates from updates-testing.  Only problem I can remember having is broken
syntax highlighting from a somewhat recent vim update.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Demi Marie Obenour
On 2/23/23 12:52, Matthew Miller wrote:
> On Wed, Feb 22, 2023 at 10:33:27AM -0800, Kevin Fenzi wrote:
>> Just FYI, we do not produce drpms for rawhide/branched at all (since
>> 2017 ish).
> [...]
>> Its one line in bodhi pungi config:
>> createrepo_deltas = False
>>> If shut off, can it be turned back on again (in case of Regrets)?
>> Just change the one line back to True (well, it's more complex because
>> we only actually do drpms for the 'Everything' repo, not others, but
>> it's one line).
> 
> 
> So, it sounds like "remove the step in the release SOP to turn them _on_ for
> the branch at release time" would be the easiest way to go. And the default
> config could be changed in DNF at any time for F38+.

I would like to see the DNF config changed in F38, for attack surface
reduction reasons.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Michael Catanzaro
On Fri, Feb 24 2023 at 12:00:40 AM +0100, Björn Persson 
 wrote:

There are also other dangers with installing only security fixes. If a
bugfix is released and packaged, and later it's discovered that the 
bug
had security implications, then no security update will be made 
because

the fix is already packaged. It might be possible to set a security
flag on the update after the fact, but nobody will bother with that.

I would therefore advise against using --security. If one can't 
install

all the updates continuously, then one should use a more stable
distribution than Fedora.


tbh I'd go so far as to propose that this functionality should not be 
reimplemented in dnf5 at all.


___
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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Ian Laurie

On 2/22/23 20:30, Miroslav Suchý wrote:
Do you want to make Fedora 38 better? Please spend 1 minute of your time 
and try to run:


Looked good here, just some downgrades as follows:

Downgrading:
 fwupdx86_64 1.8.10-1.fc38
 fwupd-plugin-flashromx86_64 1.8.10-1.fc38
 fwupd-plugin-modem-manager   x86_64 1.8.10-1.fc38
 fwupd-plugin-uefi-capsule-data x86_64   1.8.10-1.fc38
 inxi noarch 3.3.24-2.fc38
 mock-core-configsnoarch 38.1-1.fc38


Ian
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
___
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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Björn Persson
Gordon Messmer wrote:
> Contrary-wise: Because Fedora updates only contains the latest built, 
> once a build marked as a security fix is obsoleted by another build, 
> there is no longer any indication that a security issue existed in any 
> version, at which point "dnf update --security" no longer works.

There are also other dangers with installing only security fixes. If a
bugfix is released and packaged, and later it's discovered that the bug
had security implications, then no security update will be made because
the fix is already packaged. It might be possible to set a security
flag on the update after the fact, but nobody will bother with that.

I would therefore advise against using --security. If one can't install
all the updates continuously, then one should use a more stable
distribution than Fedora.

Björn Persson


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


[rpms/perl-HTTP-Daemon] PR #20: 6.15 bump

2023-02-23 Thread Michal Josef Špaček

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

Merged pull-request:

``
6.15 bump
``

https://src.fedoraproject.org/rpms/perl-HTTP-Daemon/pull-request/20
___
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 2172742] perl-Geo-ShapeFile-3.03 is available

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172742

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Geo-ShapeFile-3.02 is  |perl-Geo-ShapeFile-3.03 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Releases retrieved: 3.03
Upstream release that is considered latest: 3.03
Current version/release in rawhide: 3.01-7.fc38
URL: https://metacpan.org/dist/Geo-ShapeFile/

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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2172742
___
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: Help with systemd/cgroup task limits in koji

2023-02-23 Thread Than Ngo


Am 23.02.23 um 20:05 schrieb Kevin Fenzi:

On Thu, Feb 23, 2023 at 11:11:49AM +0100, Florian Weimer wrote:

* Giuseppe Scrivano:


Florian Weimer  writes:

It could be an old kernel bug:

   Task exit is signaled before task resource deallocation, leading to
   bogus EAGAIN errors
   

There have been recent namespace optimizations which introduce a similar
pattern there.  While they improve throughput in many cases, continuous
allocation and deallocation can now fail, even though the program logic
ensures that resources are never exceeded.

Guiseppe, any suggestions how to debug this?

the only optimization I am aware of that could cause a similar issue is
the delayed IPC namespace cleanup.  That would cause the IPC namespace
creation to fail though, not posix_spawn.

If you believe the failure can be related to reaching the pids limit for
the cgroup, could you please check the actual limit inside the
container?  You could check the value of /sys/fs/cgroup/pids.max inside
the container (assuming cgroupv2 and a cgroup namespace for the container).

Please let me know if that helps.

(replying for the benefit of the list)

Than: could you try some chromium builds with a cat of that value at
various points? (ie, prep, build, etc?)


Hi Kevin

i tried chromium build with a cat of that value. The value of 
/sys/fs/cgroup/pids.max is *max* at %prep, %setup and %build

The chromium build failed again with errors:

Error: spawn /usr/bin/node-19 EAGAIN
    at Process.ChildProcess._handle.onexit 
(node:internal/child_process:285:19)

    at onErrorNT (node:internal/child_process:483:16)
    at processTicksAndRejections (node:internal/process/task_queues:82:21)

[!] Error: unfinished hook action(s) on exit

https://kojipkgs.fedoraproject.org//work/tasks/2362/97912362/build.log

Than
___
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: webkitgtk6.0 soname bump season

2023-02-23 Thread Michael Catanzaro
On Thu, Jan 19 2023 at 06:02:53 PM -0600, Michael Catanzaro 
 wrote:
The webkitgtk6.0 package (for GTK 4, not GTK 3) will be doing several 
soname bumps over the next two months in preparation for stabilizing 
the GTK 4 API. I won't announce individual bumps since they will be 
frequent. I will handle rebuilds of the impacted packages: 
gnome-initial-setup, gnome-builder, evolution-data-server, and 
epiphany. (If I've missed anything, please yell.)


Hi all,

Quick update here. We are approaching the end of soname bump season! 
\o/ There will be one or (less likely) two additional soname bumps 
within the next three weeks, and then when WebKitGTK 2.40.0 is released 
alongside GNOME 44 the soname bumps will stop and the GTK 4 API will be 
stable.


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


[rpms/perl-HTTP-Daemon] PR #20: 6.15 bump

2023-02-23 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-HTTP-Daemon` that 
you are following:
``
6.15 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTTP-Daemon/pull-request/20
___
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 2172670] perl-HTTP-Daemon-6.15 is available

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172670

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2172670
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-HTTP-Daemon] PR #19: 6.15 bump

2023-02-23 Thread Michal Josef Špaček

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

Merged pull-request:

``
6.15 bump
``

https://src.fedoraproject.org/rpms/perl-HTTP-Daemon/pull-request/19
___
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: Update of catch to Catch2 v3

2023-02-23 Thread Stephen Gallagher
On Wed, Feb 22, 2023 at 6:38 AM Tom Hughes via devel
 wrote:
>
> As discussed a few weeks ago the Catch testing framework has
> a slightly weird naming scheme, namely:
>
> * Catch (v1.x, actually a branch in Catch2 repository)
> * Catch2 v2.x
> * Catch2 v3.x
>
> Since Catch2 was released we have had catch1 and catch packages
> to support both v1.x and v2.x users.
>
> I have now added catch2 (for Catch2 v2.x) and upgraded the catch
> package to Catch2 v3.x in rawhide and f38.
>
> What this means is that if your package uses catch-devel to build
> that you probably need to update your BuildRequire to catch2-devel
> when you next build it - unless your upstream supports v3.x of
> course.

So should we expect the next major version to be Catch22 v4.x?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-HTTP-Daemon] PR #19: 6.15 bump

2023-02-23 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-HTTP-Daemon` that 
you are following:
``
6.15 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTTP-Daemon/pull-request/19
___
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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Leigh Scott
google-chrome rpm caused issues due to it's SHA1 signature.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-HTTP-Daemon] PR #18: 6.15 bump

2023-02-23 Thread Michal Josef Špaček

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

Merged pull-request:

``
6.15 bump
``

https://src.fedoraproject.org/rpms/perl-HTTP-Daemon/pull-request/18
___
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: Self Introduction: Dalton Hubble

2023-02-23 Thread Dusty Mabe


On 2/23/23 00:19, Dalton Hubble wrote:
> Hey folks,
> 
> I'm an engineer working in the Go, cloud, and infrastructure space. I've been 
> a Linux user for a while, a Fedora user for the last ~8 years, and used to 
> work for CoreOS. I maintain a few open source Go libraries, maintain a 
> Kubernetes distro, and operate the AS207563 network. When I can, I enjoy 
> hiking and tinkering on my infra.
> 
> I'm glad to get aquainted and help with containerd packaging.

Welcome Dalton!

And thank you for your work and participation in the Fedora CoreOS community!

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


[rpms/perl-HTTP-Daemon] PR #18: 6.15 bump

2023-02-23 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-HTTP-Daemon` that 
you are following:
``
6.15 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTTP-Daemon/pull-request/18
___
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 2172670] perl-HTTP-Daemon-6.15 is available

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172670

Michal Josef Spacek  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED



--- Comment #1 from Michal Josef Spacek  ---
Changes:

6.15  2023-02-22 22:02:46Z
  - Fix CVE-2022-31081: Inconsistent Interpretation of HTTP Requests
Correctly handle multiple Content-Length headers and its variants
(Theo van Hoesel)
Closes "Discrepancies in the Parsing of Content Length header ..." (GH#56)
(blessingcharles)
  - kill test server with KILL rather than QUIT (GH#63) (Graham Knop)
  - Create TestServer test lib for running daemon process (GH#62) (Graham Knop)
  - Clean up tests (GH#61) (Graham Knop)

For Fedora 36,37,38 and rawhide


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

2023-02-23 Thread Ben Cotton
The current target release date is the early target date (2023-03-14).

Action summary


Accepted blockers
-

1. distribution — Workstation boot x86_64 image exceeds maximum size — ASSIGNED
ACTION: Workstation WG to reduce image size or increase the limit

2. kwin — kwin_wayland often crashed when used as the sddm Wayland
compositor and logging out of Plasma resulting in a black screen —
ON_QA
ACTION: QA to verify FEDORA-2023-81ff51758d


Proposed blockers
-

1. gdb — Can't open file anon_inode:i915.gem which was expanded to
anon_inode:i915.gem during file-backed mapping note processing — NEW
ACTION: Maintainer to diagnose issue

2. pkgconf — Don't depend on system-rpm-config — ON_QA
ACTION: QA to verify FEDORA-2023-766817d642


Bug-by-bug detail
=

Accepted blockers
-

1. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2149246 — ASSIGNED
Workstation boot x86_64 image exceeds maximum size

Changes to linux-firmware briefly brought the Worktation image below
the limit. However, the Fedora-38-20230216.n.0 went above the limit
again.

2. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2168034 — ON_QA
kwin_wayland often crashed when used as the sddm Wayland compositor
and logging out of Plasma resulting in a black screen

Logging out of Plasma sometimes triggers a kwin crash.
FEDORA-2023-81ff51758d contains a candidate fix.


Proposed blockers
-

1. gdb — https://bugzilla.redhat.com/show_bug.cgi?id=2172342 — NEW
Can't open file anon_inode:i915.gem which was expanded to
anon_inode:i915.gem during file-backed mapping note processing

Reporting a bug with gnome-abrt fails because no fram and no thread
found in the backtrace that gdb produces.

2. pkgconf — https://bugzilla.redhat.com/show_bug.cgi?id=2172406 — ON_QA
Don't depend on system-rpm-config

pkgconf pulls in ~22 new packages as a runtime dependency, which don't
appear to be strictly necessary. FEDORA-2023-766817d642 contains a
candidate fix.



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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: Changes to Bugzilla API key requirements

2023-02-23 Thread Gary Buhrmaster
On Thu, Feb 23, 2023 at 6:48 PM Ben Cotton  wrote:

> I have a survey prepared that will be opened once the F37
> retrospective survey is done. This will give us a basis for evaluating
> our requirements as we look for possible replacements.

Thanks for planning on the followup.
___
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: Help with systemd/cgroup task limits in koji

2023-02-23 Thread Kevin Fenzi
On Thu, Feb 23, 2023 at 11:11:49AM +0100, Florian Weimer wrote:
> * Giuseppe Scrivano:
> 
> > Florian Weimer  writes:
> >> It could be an old kernel bug:
> >>
> >>   Task exit is signaled before task resource deallocation, leading to
> >>   bogus EAGAIN errors
> >>   
> >>
> >> There have been recent namespace optimizations which introduce a similar
> >> pattern there.  While they improve throughput in many cases, continuous
> >> allocation and deallocation can now fail, even though the program logic
> >> ensures that resources are never exceeded.
> >>
> >> Guiseppe, any suggestions how to debug this?
> >
> > the only optimization I am aware of that could cause a similar issue is
> > the delayed IPC namespace cleanup.  That would cause the IPC namespace
> > creation to fail though, not posix_spawn.
> >
> > If you believe the failure can be related to reaching the pids limit for
> > the cgroup, could you please check the actual limit inside the
> > container?  You could check the value of /sys/fs/cgroup/pids.max inside
> > the container (assuming cgroupv2 and a cgroup namespace for the container).
> >
> > Please let me know if that helps.
> 
> (replying for the benefit of the list)

Than: could you try some chromium builds with a cat of that value at
various points? (ie, prep, build, etc?)

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


Re: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Kevin Fenzi
On Thu, Feb 23, 2023 at 10:15:42AM -0800, Gordon Messmer wrote:
> On 2023-02-23 10:05, Gordon Messmer wrote:
> > Contrary-wise: Because Fedora updates only contains the latest built,
> > once a build marked as a security fix is obsoleted by another build,
> > there is no longer any indication that a security issue existed in any
> > version, at which point "dnf update --security" no longer works.
> 
> 
> For example, https://bodhi.fedoraproject.org/updates/FEDORA-2022-839fd408a5
> is no longer an indication of a problem in a default package:
> 
> $ podman run --rm -it fedora:37
> [root@d1c2aa7da870 /]# rpm -qa vim\*
> vim-data-9.0.475-1.fc37.noarch
> vim-minimal-9.0.475-1.fc37.x86_64
> [root@d1c2aa7da870 /]# dnf update --security vim\*
> No security updates needed for "vim*", but 2 updates available
> Dependencies resolved.
> Nothing to do.
> Complete!
> 
> > That might be a problem only for systems that are updated less
> > frequently than the window between a security update and a later build,
> > I still think it's a flaw that should be fixed.
> 
> (And I probably shouldn't have phrased this as if it's very limited. 
> Anything installed from the installation media or "fedora" repo without full
> updates would definitely have security issues that weren't reflected in the
> package set selected by "dnf update --security")

For this reason, bodhi used to mark such packages for the rest of the
release. Ie, if you mark foo-1.0-1.fc37 a security update, forever after
that foo package gets 'security' in the updateinfo. I think this was
dropped because it confused too many people and it also didn't really
express the actual problem here. 

I'm not sure what a solution could be. Keep every update in updateinfo
so dnf could tell you that there's 2 updates and 1 is security and the
other bugfix? but then we would need to also keep those updates around
to update to. 

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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Kevin Fenzi
On Thu, Feb 23, 2023 at 10:46:03AM +0100, Vít Ondruch wrote:
> 
> Dne 22. 02. 23 v 5:38 Kevin Kofler via devel napsal(a):
> > Kevin Fenzi wrote:
> > > I fear the only way to fix it is to get pungi to merge entire repos, and
> > > I don't think thats anything that pungi wants to be on the hook for
> > > doing.
> > But there are more things than just DeltaRPMs it could be useful for. E.g.,
> > I remember that in ancient times (pre Core-Extras Merge), some Fedora
> > repository (IIRC, the old Fedora Extras) used to ship not only the latest
> > build for each package, but the TWO latest builds, so that if the latest
> > build was broken, you could easily downgrade to the previous one. That
> > should really be done in all the rolling repositories (updates, updates-
> > testing, Rawhide).
> 
> 
> Once there was this DNF RFE:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1397174

yeah. We actually do have a repo with all updates for stable releases,
which we had to setup for a corner fedora coreos corner case. I suppose
we could enable that more globally if the desire is for easy downgrades
in stable releases. I think they would be much more common in
rawhide/branched 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: Fwd: fedmsg notification

2023-02-23 Thread Kevin Fenzi
On Thu, Feb 23, 2023 at 11:10:20AM +, Jonathan Wakely wrote:
> What does this notification mean, and how do I turn it off?
> 
> The filter UI for notifications is impossible to understand.

yes, it is. ;( 

It's currently being re-written. 

The current janky version sends emails like: 
> 
> -- Forwarded message -
> From: 
> Date: Thu, 23 Feb 2023 at 10:25
> Subject: fedmsg notification
> 
> 
> 
> Notification time stamped 2023-02-23 10:25:03 UTC
> 
> 
> https://bodhi.fedoraproject.org
> 
> --
> You received this message due to your preference settings at
> https://apps.fedoraproject.org/notifications/jwakely.id.fedoraproject.org/email/29140

Because the notifications service is still using our old fedmsg bus, and
it has no idea what these messages are, just that they are from bodhi.
;( 

This one was caused by: 

https://apps.fedoraproject.org/datagrepper/v2/id?id=b4981565-9359-4c26-8354-6f79a0fb78f6_raw=true=extra-large

so, a 'testing complete' message from ci for 
https://bodhi.fedoraproject.org/updates/FEDORA-2023-4e72394dd9

:( 

So, the big hammer here would be to add a 'not all bodhi' to your rules. 
Or add that and a new ruleset with just those bodhi messages you do want
if you want any. 

This should be about 1000x better soon with the new version. 
It's using fedora-messaging, as part of the work we are making sure
applications publish schemas and so it should be able to show things as
they really are.

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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Feb 22, 2023 at 09:34:14AM -0700, Nathanael D. Noblet wrote:
> On Wed, 2023-02-22 at 10:30 +0100, Miroslav Suchý wrote:
> > dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
> >  --enablerepo=updates-testing \
> >  $(rpm -q fedora-repos-modular >/dev/null && echo --
> > enablerepo=updates-testing-modular) \
> >  --assumeno distro-sync
> 
> I got 
> 
> Error: 
>  Problem: package msv-xsdlib-1:2013.6.1-19.fc33.noarch requires
> mvn(relaxngDatatype:relaxngDatatype), but none of the providers can be
> installed
>   - jaxb-relaxng-datatype-2.3.5-7.fc37.noarch does not belong to a
> distupgrade repository

Once msv-xsdlib is removed, jaxb-relaxng-datatype should update.

>   - problem with installed package msv-xsdlib-1:2013.6.1-19.fc33.noarch
> (try to add '--skip-broken' to skip uninstallable packages)

I'll add this one to fedora-obsolete-packages.

> I don't know why those are installed (I don't recognize the packages
> and they aren't dependencies of anything I know I need) and just
> removed them and everything was good after that.

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: Changes to Bugzilla API key requirements

2023-02-23 Thread Ben Cotton
On Thu, Feb 23, 2023 at 1:42 PM Gary Buhrmaster
 wrote:
>
> I seem to recall that some of the Fedora people were
> talking about creating a document that would show
> what "we" use bugzilla for so that a future issue/bug
> tracker solution (whatever that might be) could be
> evaluated and any prep work needed to potentially
> unhook Fedora's procedures/processes from bugzilla
> could be started early (should the eventual chosen
> solution not be able to provide those features).
> Did that happen, and if so, where is it located?

I have a survey prepared that will be opened once the F37
retrospective survey is done. This will give us a basis for evaluating
our requirements as we look for possible replacements.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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: Changes to Bugzilla API key requirements

2023-02-23 Thread Gary Buhrmaster
On Thu, Feb 23, 2023 at 5:54 PM Matthew Miller  wrote:

> The "good news" is that Red Hat has announced a move away from Bugzilla for
> future products. (They're going to Jira.) RH Bugzilla isn't officially shut
> down, but its days are numbered. We need to come up with something else.

"Good" is in the eyes of the beholder.

I can't say I am enamoured of bugzilla (any variant),
but it has been basically an adequate solution.

Having a "one pane of glass" view of both RH EL and
Fedora bugs/issues (which are sometimes related)
is something I am concerned will be lost when RH
moves issues to jira (and I really don't look forward
to having to look two different places for possible
bug reports or resolutions).

I seem to recall that some of the Fedora people were
talking about creating a document that would show
what "we" use bugzilla for so that a future issue/bug
tracker solution (whatever that might be) could be
evaluated and any prep work needed to potentially
unhook Fedora's procedures/processes from bugzilla
could be started early (should the eventual chosen
solution not be able to provide those features).
Did that happen, and if so, where is it located?
And does the document capture other wants/desires
for new/dropped functionality?
___
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: Update of catch to Catch2 v3

2023-02-23 Thread Benson Muite
On 2/22/23 14:37, Tom Hughes via devel wrote:
> As discussed a few weeks ago the Catch testing framework has
> a slightly weird naming scheme, namely:
> 
> * Catch (v1.x, actually a branch in Catch2 repository)
> * Catch2 v2.x
> * Catch2 v3.x
> 
> Since Catch2 was released we have had catch1 and catch packages
> to support both v1.x and v2.x users.
> 
> I have now added catch2 (for Catch2 v2.x) and upgraded the catch
> package to Catch2 v3.x in rawhide and f38.
> 
Thanks.
> What this means is that if your package uses catch-devel to build
> that you probably need to update your BuildRequire to catch2-devel
> when you next build it - unless your upstream supports v3.x of
> course.
> 
> Tom
> 
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Thomas Rodgers
systemtap is FTBFS because dyninst is FTBFS, see PR2173030
 for dyninst.


On Thu, Feb 23, 2023 at 2:49 AM Richard W.M. Jones 
wrote:

> boost 1.81.0 (side tag f39-boost) was merged into Fedora earlier this week:
>
>   https://koji.fedoraproject.org/koji/packageinfo?packageID=1074
>
> These are the builds in the side tag:
>
>
> https://koji.fedoraproject.org/koji/builds?inherited=0=63053=-build_id=1
>
> However I think some packages didn't get rebuilt.  Definitely
> systemtap, which causes this problem with qemu:
>
>   https://koschei.fedoraproject.org/package/qemu?collection=f39
>
>   - nothing provides libboost_system.so.1.78.0()(64bit) needed by
> systemtap-devel-4.8-2.fc38.x86_64
>
> Possibly ceph, causing:
>
>   https://koschei.fedoraproject.org/package/virt-v2v?collection=f39
>   https://koschei.fedoraproject.org/package/libguestfs?collection=f39
>
>   - nothing provides libboost_thread.so.1.78.0()(64bit) needed by
> librados2-2:17.2.5-11.fc39.x86_64
>   - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by
> librados2-2:17.2.5-11.fc39.x86_64
>
> There's a comment in the current ceph package saying that it's
> incompatible with boost 1.81 so they've switched back to the bundled
> copy.  However we still don't have an installable package.
>
> I think systemtap needs to be added to the list of packages that
> depend on boost for next time.  The systemtap spec file is a maze of
> twisty RPM macros all alike, so perhaps whatever script is used to
> check for things requiring boost got confused:
>
>
> https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Vít Ondruch


Dne 23. 02. 23 v 12:41 Zbigniew Jędrzejewski-Szmek napsal(a):

On Thu, Feb 23, 2023 at 12:28:48PM +0100, Kalev Lember wrote:

On Thu, Feb 23, 2023 at 12:17 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
I think you got something wrong with your repoquery. Perhaps it picked up
older packages from a published rawhide compose that were still linked with
older boost?

It seems so. I thought the compose would have already happened.



Compose is broken due to Boost:

https://pagure.io/releng/failed-composes/issue/4654


Vít




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


[Bug 2172819] perl-SQL-Statement-1.414-10.fc39 tests produce a lot of warnings: Use of uninitialized value $unkpos in subtraction (-) at /usr/share/perl5/vendor_perl/Text/Balanced.pm line 1008

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172819

Michal Josef Spacek  changed:

   What|Removed |Added

Link ID||CPAN 146697



--- Comment #3 from Michal Josef Spacek  ---
I reported bug to RT (https://rt.cpan.org/Ticket/Display.html?id=146697) and
prepared possible fix (https://github.com/steve-m-hay/Text-Balanced/pull/8)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2172819
___
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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Gordon Messmer

On 2023-02-23 10:05, Gordon Messmer wrote:
Contrary-wise: Because Fedora updates only contains the latest built, 
once a build marked as a security fix is obsoleted by another build, 
there is no longer any indication that a security issue existed in any 
version, at which point "dnf update --security" no longer works. 



For example, 
https://bodhi.fedoraproject.org/updates/FEDORA-2022-839fd408a5 is no 
longer an indication of a problem in a default package:


$ podman run --rm -it fedora:37
[root@d1c2aa7da870 /]# rpm -qa vim\*
vim-data-9.0.475-1.fc37.noarch
vim-minimal-9.0.475-1.fc37.x86_64
[root@d1c2aa7da870 /]# dnf update --security vim\*
No security updates needed for "vim*", but 2 updates available
Dependencies resolved.
Nothing to do.
Complete!

That might be a problem only for systems that are updated less 
frequently than the window between a security update and a later 
build, I still think it's a flaw that should be fixed. 


(And I probably shouldn't have phrased this as if it's very limited.  
Anything installed from the installation media or "fedora" repo without 
full updates would definitely have security issues that weren't 
reflected in the package set selected by "dnf update --security")

___
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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Gordon Messmer

On 2023-02-22 10:48, Kevin Fenzi wrote:

On Wed, Feb 22, 2023 at 05:38:23AM +0100, Kevin Kofler via devel wrote:


I remember that in ancient times (pre Core-Extras Merge), some Fedora
repository (IIRC, the old Fedora Extras) used to ship not only the latest
build for each package, but the TWO latest builds,

Cons:
* It will allow for more easily tricking people into downgrading to a
version that has serious security problems so they could be exploited.



Contrary-wise: Because Fedora updates only contains the latest built, 
once a build marked as a security fix is obsoleted by another build, 
there is no longer any indication that a security issue existed in any 
version, at which point "dnf update --security" no longer works.


That might be a problem only for systems that are updated less 
frequently than the window between a security update and a later build, 
I still think it's a flaw that should be fixed.

___
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: Changes to Bugzilla API key requirements

2023-02-23 Thread Matthew Miller
On Thu, Feb 23, 2023 at 05:35:36AM +0100, Kevin Kofler via devel wrote:
> IMHO, Fedora really needs its own bug tracker that is not driven by this 
> kind of enterprise-grade security requirements.

The "good news" is that Red Hat has announced a move away from Bugzilla for
future products. (They're going to Jira.) RH Bugzilla isn't officially shut
down, but its days are numbered. We need to come up with something else.

-- 
Matthew Miller

Fedora Project Leader
___
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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Matthew Miller
On Wed, Feb 22, 2023 at 10:33:27AM -0800, Kevin Fenzi wrote:
> Just FYI, we do not produce drpms for rawhide/branched at all (since
> 2017 ish).
[...]
> Its one line in bodhi pungi config:
> createrepo_deltas = False
> > If shut off, can it be turned back on again (in case of Regrets)?
> Just change the one line back to True (well, it's more complex because
> we only actually do drpms for the 'Everything' repo, not others, but
> it's one line).


So, it sounds like "remove the step in the release SOP to turn them _on_ for
the branch at release time" would be the easiest way to go. And the default
config could be changed in DNF at any time for F38+.

It doesn't sound like it's really worthwhile to bother changing F36 or F37.



-- 
Matthew Miller

Fedora Project Leader
___
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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Matthew Miller
On Wed, Feb 22, 2023 at 10:56:53AM -0500, Demi Marie Obenour wrote:
> > Could we do this as a two-step approach? First change the default to
> > not use deltas but still allow people to opt-in to it. Then (assuming
> > we can track this, which maybe we can't) see how much they're used
> > before we decide to pull the plug on producing them.
> That would be absolutely awesome.

I don't think we can actually tell easily. Additionally, we can't actually
tell the important thing, which was "how useful were they really?" — if we
have a million people using them but getting an average 0.01% size
benefit... that probably doesn't outweigh the costs.

But, we _can_ tell (again, see previous discussion) that what we're
currently providing is really unlikely to be very useful. So, I'm not
actually sure this approach buys us anything.

-- 
Matthew Miller

Fedora Project Leader
___
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: Announced pkgconf soname change

2023-02-23 Thread Neal Gompa
On Thu, Feb 23, 2023 at 8:02 AM Neal Gompa  wrote:
>
> On Thu, Feb 23, 2023 at 7:55 AM Petr Pisar  wrote:
> >
> > pkgconf-1.9.4-1.fc39, comparing to 1.8.0-6.fc39, changed a soname without
> > a notice on this list. Affected packages:
> >
> > # dnf -q --repoid f39-build repoquery --whatrequires 
> > 'libpkgconf.so.3()(64bit)' --source | sort -u
> > build2-0.15.0-1.fc37~bootstrap.src.rpm
> > perl-PkgConfig-LibPkgConf-0.11-11.fc38.src.rpm
> >
> > It also broke API:
> >
> > LibPkgConf.xs:246:23: error: too few arguments to function 
> > 'pkgconf_pkg_new_from_file'
> >   246 |   RETVAL = PTR2IV(pkgconf_pkg_new_from_file(>client, 
> > filename, fp));
> >   |   ^
> >
> > From an upstream changelog:
> >
> > * pkgconf 1.9.0 is the first testing release in the pkgconf 2.0 development
> >   series.  While it is believed to be suitable for production, there may be
> >   bugs due to the overall redesign of the solver and other initiatives.
> >   Additionally, a future release of pkgconf plans will have additional ABI
> >   breaks for the libpkgconf library before the pkgconf 2.0 release is cut.
> >
>
> My bad, I missed that this package doesn't have the soversion tracked.
> I'll update the packaging for that going forward.
>

I've updated the packaging to track this going forward:
https://src.fedoraproject.org/rpms/pkgconf/c/930106a9359d866a6591b27e797fd396b2013b08?branch=rawhide


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


Re: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Matthew Miller
On Wed, Feb 22, 2023 at 01:41:43PM +0100, Luna Jernberg wrote:
> Dislike -1

This kind of "vote" isn't really very helpful. Of course not everyone is
going to like everything. As I said initially, it's unfortunate that we
aren't in a better place here. But we're in the place we're in. If you have
a constructive, alternate proposal, let's hear that, please.

-- 
Matthew Miller

Fedora Project Leader
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Thomas Rodgers
PR2173019  has been
created. The file in question was updated within the last three days, but
not to fix this issue.

On Thu, Feb 23, 2023 at 7:47 AM Thomas Rodgers  wrote:

> ceph is FTBFS due to a change in Boost Asio. I'll file a PR this morning.
>
> usr/include/boost/asio/async_result.hpp:651:9: error: no type named 
> 'completion_handler_type' in 'class 
> boost::asio::async_result,
>  void(boost::system::error_code, ceph::buffer::v15_2_0::list)>'
>   651 | completion_handler_type;
>   | ^~~
>
>
> On Thu, Feb 23, 2023 at 6:04 AM Kaleb Keithley 
> wrote:
>
>>
>>
>> On Thu, Feb 23, 2023 at 8:19 AM Jakub Jelinek  wrote:
>>
>>> On Thu, Feb 23, 2023 at 01:11:13PM +, Jonathan Wakely wrote:
>>> > On Thu, 23 Feb 2023 at 13:03, Richard W.M. Jones wrote:
>>> > > Do you know anything about what's happening with Ceph?
>>> >
>>> > No idea, sorry.
>>>
>>> Ceph is likely #2169364 aka https://gcc.gnu.org/PR108773 , still
>>> unresolved
>>> GCC bug.
>>>
>>
>> Doubtful. That's from building early snapshots of what will become
>> ceph-18.  Thus far ceph-17 hasn't hit the ICE.
>>
>> right now the issue is with the bundled boost building with Python-3.11.
>> There are a lot of moving parts.
>>
>> --
>>
>> Kaleb
>>
>
___
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


Heads up - squashfs-tools prelease in rawhide

2023-02-23 Thread Bruno Wolff III
Phillip is really close to releasing 4.6 and I want to get some testing 
in rawhide before that happens. If we do find a problem, it will be easier 
on him if we find it before the release. I ran a test script that tests 
the features we mostly use, so I'm not expecting any problems.

___
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: Self Introduction: Dalton Hubble

2023-02-23 Thread Joe Doss

On 2/22/23 11:19 PM, Dalton Hubble wrote:

I'm an engineer working in the Go, cloud, and infrastructure space.
I've been a Linux user for a while, a Fedora user for the last ~8
years, and used to work for CoreOS. I maintain a few open source Go
libraries, maintain a Kubernetes distro, and operate the AS207563
network. When I can, I enjoy hiking and tinkering on my infra.


Glad to have you with us Dalton! I am a very big fan of Typhoon and 
Matchbox! :D


Joe



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


Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

2023-02-23 Thread Gordon Messmer
I wanted to sum up my understanding of the thread so far, and changes I 
intend to work on:


The current implementation generates a version if the library's full 
name ends with ".so." followed by numbers separated by dots. After 
discussion, it seems like a more logical approach is to ensure that the 
soname is a symlink, ensure that the basename of the destination does 
not match the soname, and to use the suffix of that file if there is a 
numeric ending after ".so." (whether or not there are dots.)  If the 
soname isn't a symlink, then an update wouldn't have any way to provide 
a version that advances. This change will improve handling of sonames 
that have a dotted-numeric suffix.  I'll update the PR shortly; this 
should be a fairly small change.


Due to Fedora's FTBFS policy, it may take more than one release to 
globally enable the _elf_require_fallback_versions macro.  In the 
release after the _elf_provide_fallback_versions macro is globally 
enabled, we could review the number of packages that provide libraries 
which failed to build, and decide whether it was worth globally enabling 
the require macro and opting out a number of dependent packages or, more 
likely, putting off enabling the require macro for another release.  
I'll update the proposal to reflect the possibility of a longer 
deployment timeline.  (I'm not clear on the subject of whether or not I 
should add the proposal to the wiki, given that the change has not yet 
merged upstream.)


Shared objects might not be built by libtool, and may provide versions, 
so references to libtool in the PR will be renamed to improve accuracy.


I want to follow up on Fedora's rpminspect tests to ensure that 
sub-packages are being checked, since I can't find abidiff reports for 
the package that I used as an example.  I'll also explore the 
possibility of detecting backward-compatible ABI changes that don't have 
a change in their full name, which would support this proposal.



There were also some points made that probably bear further discussion, 
which I think might not have consensus right now:


While some developers are concerned that retaining the full version 
taken from the fullname will make it difficult to downgrade packages, 
which might make debugging more difficult, others believe that interface 
changes might occur with any version change.  This might bear further 
discussion.  One possible approach would be to add a flag to truncate 
groups of digits from the Requires generated, and let the distribution 
set that or not.


There's been a suggestion that versions should be added to dependencies 
with versioned symbols, which are currently exempt from this change.


There were several suggestions to use the rpm version instead of a 
version taken from the full name of the library.  The original change 
suggested to RPM did that; the developers didn't like it. There's 
concern that the proposal as-is will make it more difficult to provide 
alternate implementations of a shared library; I think that using rpm 
versions would make that even more difficult (though using the version 
of the providing rpm package definitely has some advantages as well).


There was also a suggestion to add a literal string, "soname", to either 
the version or the requirement in order to better indicate the source of 
the versioned dependency.

___
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: Unannounced .so version bump (F38/F39): openexr2

2023-02-23 Thread Gwyn Ciesla via devel
My apologies, I was fixing the FTBFS and apparently mistyped my repoquery. :/

-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, February 22nd, 2023 at 9:42 PM, Ben Beasley 
 wrote:


> The openexr2 compat package was just updated from 2.5.7 to 2.5.8 in 
> F39/Rawhide. This included a bump of the “imfsover,” the .so version for the 
> libIlmImf-2_5 and libIlmImfUtil-2_5 libraries.
> The following packages will need to be rebuilt in F39/Rawhide.
> 

> - CTL
> - aqsis
> - bcd
> - kde-runtime
> - kdebase3
> - kdelibs
> - luminance-hdr (I will take care of this one)
> - synfig
> 

> There are other packages that link libraries from openexr2, but these should 
> be the only ones that link the libraries affected by the .so version bump.
> 

> The package was also updated in F38/Branched, but the build is still only 
> tagged into f38-updates-candidate, and no Bodhi update has been created. If 
> the maintainer proceeds with the update for F38, all of the above dependent 
> packages will need to be rebuilt there, too, once the update reaches stable. 
> Alternatively, maybe the F38 build could be tagged into a side tag.

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


Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

2023-02-23 Thread Thomas Rodgers
On Thu, Feb 23, 2023 at 5:14 AM Jonathan Wakely  wrote:

> On Wed, 22 Feb 2023 at 20:52, Thomas Rodgers wrote:
> >
> > The f39-boost side tag builds have finished.
> >
> > The following packages are new FTBFS likely due to the Boost update -
> [...]
> > - usd [[
> https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log
> ]]
>
> The correct log for usd is
> https://kojipkgs.fedoraproject.org//work/tasks/2081/97882081/build.log
> and it shows errors related to hash_value. Probably related to this
> item in the Boost 1.81.0 release notes:
>
> Container Hash:
>
> Major update.
> The specializations of boost::hash have been removed; it now always
> calls hash_value.
>
> https://www.boost.org/users/history/version_1_81_0.html
>
>
And I noted in the associated PR that there is significant churn in the
upstream related to fixing that.
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Thomas Rodgers
ceph is FTBFS due to a change in Boost Asio. I'll file a PR this morning.

usr/include/boost/asio/async_result.hpp:651:9: error: no type named
'completion_handler_type' in 'class
boost::asio::async_result,
void(boost::system::error_code, ceph::buffer::v15_2_0::list)>'
  651 | completion_handler_type;
  | ^~~


On Thu, Feb 23, 2023 at 6:04 AM Kaleb Keithley  wrote:

>
>
> On Thu, Feb 23, 2023 at 8:19 AM Jakub Jelinek  wrote:
>
>> On Thu, Feb 23, 2023 at 01:11:13PM +, Jonathan Wakely wrote:
>> > On Thu, 23 Feb 2023 at 13:03, Richard W.M. Jones wrote:
>> > > Do you know anything about what's happening with Ceph?
>> >
>> > No idea, sorry.
>>
>> Ceph is likely #2169364 aka https://gcc.gnu.org/PR108773 , still
>> unresolved
>> GCC bug.
>>
>
> Doubtful. That's from building early snapshots of what will become
> ceph-18.  Thus far ceph-17 hasn't hit the ICE.
>
> right now the issue is with the bundled boost building with Python-3.11.
> There are a lot of moving parts.
>
> --
>
> Kaleb
>
___
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: Self Introduction: Dalton Hubble

2023-02-23 Thread Dalton Hubble
Yes, but only distantly :)

Dalton
___
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 2172742] perl-Geo-ShapeFile-3.02 is available

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172742

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com |
   Doc Type|--- |If docs needed, set a value
Link ID||Github
   ||shawnlaffan/Geo-ShapeFile/i
   ||ssues/30



--- Comment #2 from Jitka Plesnikova  ---
The build is failing.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2172742
___
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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Chuck Anderson
Another system success:

Installing weak dependencies:
 ipp-usb   x86_64 
0.9.23-2.fc38   fedora  
   2.1 M
 oneVPL-intel-gpu  x86_64 
22.5.3-1.fc38   fedora  
   2.1 M
 passt x86_64 
0^20230216.g4663ccc-1.fc38  fedora  
   174 k
Removing:
 kernelx86_64 
6.1.7-200.fc37  @updates-testing
 0  
 kernel-core   x86_64 
6.1.7-200.fc37  @updates-testing
91 M
 kernel-modulesx86_64 
6.1.7-200.fc37  @updates-testing
57 M
 kernel-modules-extra  x86_64 
6.1.7-200.fc37  @updates-testing
   3.2 M
Downgrading:
 Lmod  x86_64 
8.7.18-1.fc38   fedora  
   258 k
 enchant2  x86_64 
2.3.3-6.fc38fedora  
65 k
 freerdp-libs  x86_64 
2:2.9.0-3.fc38  fedora  
   1.0 M
 fwupd x86_64 
1.8.10-1.fc38   fedora  
   1.8 M
 fwupd-plugin-flashrom x86_64 
1.8.10-1.fc38   fedora  
26 k
 fwupd-plugin-modem-managerx86_64 
1.8.10-1.fc38   fedora  
60 k
 fwupd-plugin-uefi-capsule-datax86_64 
1.8.10-1.fc38   fedora  
   1.8 M
 hdparmx86_64 
9.63-2.fc38 fedora  
96 k
 libwinpr  x86_64 
2:2.9.0-3.fc38  fedora  
   355 k
 mock-core-configs noarch 
38.1-1.fc38 fedora  
   141 k

Transaction Summary
===
Install  37 Packages
Upgrade2669 Packages
Remove4 Packages
Downgrade10 Packages

Total download size: 3.5 G
Operation aborted.
___
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: Test upgrades from F37 to F38 - it will take you just a minute

2023-02-23 Thread Chuck Anderson
Success:

Installing weak dependencies:
 ipp-usb   x86_64 
0.9.23-2.fc38   fedora  
   2.1 M
 oneVPL-intel-gpu  x86_64 
22.5.3-1.fc38   fedora  
   2.1 M
 passt x86_64 
0^20230216.g4663ccc-1.fc38  fedora  
   174 k
Removing:
 kernelx86_64 
6.0.15-300.fc37 @updates
 0
 kernel-core   x86_64 
6.0.15-300.fc37 @updates
92 M
 kernel-modulesx86_64 
6.0.15-300.fc37 @updates
56 M
 kernel-modules-extra  x86_64 
6.0.15-300.fc37 @updates
   3.2 M
Downgrading:
 fwupd x86_64 
1.8.10-1.fc38   fedora  
   1.8 M
 fwupd-plugin-flashrom x86_64 
1.8.10-1.fc38   fedora  
26 k
 fwupd-plugin-modem-managerx86_64 
1.8.10-1.fc38   fedora  
60 k
 fwupd-plugin-uefi-capsule-datax86_64 
1.8.10-1.fc38   fedora  
   1.8 M
 mock-core-configs noarch 
38.1-1.fc38 fedora  
   141 k

Transaction Summary
===
Install  36 Packages
Upgrade2636 Packages
Remove4 Packages
Downgrade 6 Packages

Total download size: 2.9 G
Operation aborted.
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Kaleb Keithley
On Thu, Feb 23, 2023 at 8:19 AM Jakub Jelinek  wrote:

> On Thu, Feb 23, 2023 at 01:11:13PM +, Jonathan Wakely wrote:
> > On Thu, 23 Feb 2023 at 13:03, Richard W.M. Jones wrote:
> > > Do you know anything about what's happening with Ceph?
> >
> > No idea, sorry.
>
> Ceph is likely #2169364 aka https://gcc.gnu.org/PR108773 , still
> unresolved
> GCC bug.
>

Doubtful. That's from building early snapshots of what will become
ceph-18.  Thus far ceph-17 hasn't hit the ICE.

right now the issue is with the bundled boost building with Python-3.11.
There are a lot of moving parts.

-- 

Kaleb
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Jakub Jelinek
On Thu, Feb 23, 2023 at 01:11:13PM +, Jonathan Wakely wrote:
> On Thu, 23 Feb 2023 at 13:03, Richard W.M. Jones wrote:
> > Do you know anything about what's happening with Ceph?
> 
> No idea, sorry.

Ceph is likely #2169364 aka https://gcc.gnu.org/PR108773 , still unresolved
GCC bug.

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


Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

2023-02-23 Thread Jonathan Wakely
On Wed, 22 Feb 2023 at 20:52, Thomas Rodgers wrote:
>
> The f39-boost side tag builds have finished.
>
> The following packages are new FTBFS likely due to the Boost update -
[...]
> - usd 
> [[https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log]]

The correct log for usd is
https://kojipkgs.fedoraproject.org//work/tasks/2081/97882081/build.log
and it shows errors related to hash_value. Probably related to this
item in the Boost 1.81.0 release notes:

Container Hash:

Major update.
The specializations of boost::hash have been removed; it now always
calls hash_value.

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


Re: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Jonathan Wakely
On Thu, 23 Feb 2023 at 13:03, Richard W.M. Jones wrote:
> Do you know anything about what's happening with Ceph?

No idea, sorry.
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Richard W.M. Jones
On Thu, Feb 23, 2023 at 11:35:15AM +, Jonathan Wakely wrote:
> On Thu, 23 Feb 2023 at 11:33, Jonathan Wakely  wrote:
> >
> > On Thu, 23 Feb 2023 at 10:49, Richard W.M. Jones  wrote:
> > >
> > > boost 1.81.0 (side tag f39-boost) was merged into Fedora earlier this 
> > > week:
> > >
> > >   https://koji.fedoraproject.org/koji/packageinfo?packageID=1074
> > >
> > > These are the builds in the side tag:
> > >
> > >   
> > > https://koji.fedoraproject.org/koji/builds?inherited=0=63053=-build_id=1
> > >
> > > However I think some packages didn't get rebuilt.  Definitely
> > > systemtap, which causes this problem with qemu:
> > >
> > >   https://koschei.fedoraproject.org/package/qemu?collection=f39
> > >
> > >   - nothing provides libboost_system.so.1.78.0()(64bit) needed by 
> > > systemtap-devel-4.8-2.fc38.x86_64
> > >
> > > Possibly ceph, causing:
> > >
> > >   https://koschei.fedoraproject.org/package/virt-v2v?collection=f39
> > >   https://koschei.fedoraproject.org/package/libguestfs?collection=f39
> > >
> > >   - nothing provides libboost_thread.so.1.78.0()(64bit) needed by 
> > > librados2-2:17.2.5-11.fc39.x86_64
> > >   - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by 
> > > librados2-2:17.2.5-11.fc39.x86_64
> > >
> > > There's a comment in the current ceph package saying that it's
> > > incompatible with boost 1.81 so they've switched back to the bundled
> > > copy.  However we still don't have an installable package.
> > >
> > > I think systemtap needs to be added to the list of packages that
> > > depend on boost for next time.  The systemtap spec file is a maze of
> > > twisty RPM macros all alike, so perhaps whatever script is used to
> > > check for things requiring boost got confused:
> > >
> > >   
> > > https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec
> >
> > systemtap is already in the list (and I bumped the spec file for it
> > before Tom started the rebuilds).
> >
> > It didn't get rebuilt because it depends on dyninst, which is FTBFS
> > with GCC 13 due to header changes (I think fche has a fix pending).
> >
> > Once dyninst has been rebuilt, then systemtap can be rebuilt.
> 
> FWIW the list of packages to rebuild for Boost is obtained using this
> command, which I ran on Monday just before the rebuilds started:
> 
> dnf repoquery -s --releasever=rawhide --whatrequires libboost\*
> --repo=fedora | sed -n 's/-[[:digit:]].*//p' | grep -v '^boost$' |
> sort -u
> 
> If there's something wrong with that, we can change it.

Thanks & I think that's correct.

Do you know anything about what's happening with Ceph?

I don't think we need to rebuild any of the virt packages -- hopefully
once systemtap and ceph are fixed it should just work -- but I can do
that if necessary.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Announced pkgconf soname change

2023-02-23 Thread Neal Gompa
On Thu, Feb 23, 2023 at 7:55 AM Petr Pisar  wrote:
>
> pkgconf-1.9.4-1.fc39, comparing to 1.8.0-6.fc39, changed a soname without
> a notice on this list. Affected packages:
>
> # dnf -q --repoid f39-build repoquery --whatrequires 
> 'libpkgconf.so.3()(64bit)' --source | sort -u
> build2-0.15.0-1.fc37~bootstrap.src.rpm
> perl-PkgConfig-LibPkgConf-0.11-11.fc38.src.rpm
>
> It also broke API:
>
> LibPkgConf.xs:246:23: error: too few arguments to function 
> 'pkgconf_pkg_new_from_file'
>   246 |   RETVAL = PTR2IV(pkgconf_pkg_new_from_file(>client, 
> filename, fp));
>   |   ^
>
> From an upstream changelog:
>
> * pkgconf 1.9.0 is the first testing release in the pkgconf 2.0 development
>   series.  While it is believed to be suitable for production, there may be
>   bugs due to the overall redesign of the solver and other initiatives.
>   Additionally, a future release of pkgconf plans will have additional ABI
>   breaks for the libpkgconf library before the pkgconf 2.0 release is cut.
>

My bad, I missed that this package doesn't have the soversion tracked.
I'll update the packaging for that going forward.


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


Announced pkgconf soname change

2023-02-23 Thread Petr Pisar
pkgconf-1.9.4-1.fc39, comparing to 1.8.0-6.fc39, changed a soname without
a notice on this list. Affected packages:

# dnf -q --repoid f39-build repoquery --whatrequires 'libpkgconf.so.3()(64bit)' 
--source | sort -u
build2-0.15.0-1.fc37~bootstrap.src.rpm
perl-PkgConfig-LibPkgConf-0.11-11.fc38.src.rpm

It also broke API:

LibPkgConf.xs:246:23: error: too few arguments to function 
'pkgconf_pkg_new_from_file'
  246 |   RETVAL = PTR2IV(pkgconf_pkg_new_from_file(>client, 
filename, fp));
  |   ^

From an upstream changelog:

* pkgconf 1.9.0 is the first testing release in the pkgconf 2.0 development
  series.  While it is believed to be suitable for production, there may be
  bugs due to the overall redesign of the solver and other initiatives.
  Additionally, a future release of pkgconf plans will have additional ABI
  breaks for the libpkgconf library before the pkgconf 2.0 release is cut.

-- 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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

2023-02-23 Thread Panu Matilainen

On 2/21/23 14:01, Fabio Valentini wrote:

On Tue, Feb 21, 2023 at 9:40 AM Richard W.M. Jones  wrote:


On Mon, Feb 20, 2023 at 10:56:30AM -0800, Gordon Messmer wrote:

On 2023-02-20 10:01, Richard W.M. Jones wrote:

Does it have to be something which looks so much like it might be a
version number?  For example it could be helpful for debugging if the
generated requires was something like:

   Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1



You mean the literal string "soname", right?


Yes.


I don't know a reason
that wouldn't work off the top of my head, but I also can't think of
a reason that it would add information that wasn't inferred in the
current iteration.  One reason we might want to stick with something
that looks like a version is that we might need to extend the system
to allow an epoch in the future (though I really hope that isn't
necessary.)


I mean if I'm looking at an error message, it might help to know that
I should look at the SONAME instead of trying to work out where the
weird version number had come from.


This reminds me, there *is* precedent for stuffing "arbitrary"
versions into RPM Requires / Provides.
Many language ecosystems use virtual Provides / Requires like
"py3dist(foo) = 1.2.3", "crate(foo) = 0.0.11", or even
"golang(github.com/foo/bar/v2) = 2.0.1", where the version is the
*upstream* version (normalized to only contain characters that are
valid in RPM versions), but that doesn't necessarily match version of
the RPM.
The virtual provides that are generated for shared libraries have
always been a bit odd in this regard - maybe we could do something
like "Provides: soname(libnghttp2.so.14()(64bit)) = 14.24.1"?


And that is not "a bit odd"? :D

The ()(64bit) fubar is of course terrible in any form.

- Panu -
___
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 2172714] F39FailsToInstall: perl-PkgConfig-LibPkgConf

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172714

Petr Pisar  changed:

   What|Removed |Added

Link ID||Github
   ||PerlAlien/PkgConfig-LibPkgC
   ||onf/issues/15
 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




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

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172713

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2172713
___
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 38 compose report: 20230223.n.0 changes

2023-02-23 Thread Fedora Rawhide Report
OLD: Fedora-38-20230222.n.0
NEW: Fedora-38-20230223.n.0

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

Size of added packages:  10.92 MiB
Size of dropped packages:173.92 KiB
Size of upgraded packages:   1.10 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-38-20230223.n.0.aarch64.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-need-being-tree-0.1.0-1.fc38
Summary: Pretty print trees in Go
RPMs:golang-github-need-being-tree-devel
Size:11.31 KiB

Package: golang-oras-0.15.1-1.20221105git690716b.fc38
Summary: Work with OCI registries, but for secure supply chain
RPMs:compat-golang-github-deislabs-oras-devel golang-oras golang-oras-devel
Size:10.69 MiB

Package: golang-oras-1-1.2.1-1.fc38
Summary: ORAS Go library
RPMs:golang-oras-1-1-devel
Size:94.14 KiB

Package: golang-oras-2-2.0.0~rc.4-1.fc38
Summary: ORAS Go library
RPMs:golang-oras-2-devel
Size:135.98 KiB


= DROPPED PACKAGES =
Package: gnome-shell-extension-sound-output-device-chooser-43-5.fc38
Summary: GNOME Shell extension for selecting sound devices
RPMs:gnome-shell-extension-sound-output-device-chooser
Size:57.78 KiB

Package: rust-concolor-control-0.0.7-2.fc38
Summary: Control console coloring across all dependencies
RPMs:rust-concolor-control+api_unstable-devel 
rust-concolor-control+atty-devel rust-concolor-control+auto-devel 
rust-concolor-control+bitflags-devel rust-concolor-control+clicolor-devel 
rust-concolor-control+concolor-query-devel rust-concolor-control+core-devel 
rust-concolor-control+default-devel rust-concolor-control+interactive-devel 
rust-concolor-control+no_color-devel rust-concolor-control+std-devel 
rust-concolor-control+term-devel rust-concolor-control+windows-devel 
rust-concolor-control-devel
Size:116.14 KiB


= UPGRADED PACKAGES =
Package:  gcc-13.0.1-0.5.fc38
Old package:  gcc-13.0.1-0.4.fc38
Summary:  Various compilers (C, C++, Objective-C, ...)
RPMs: cpp gcc gcc-c++ gcc-gdb-plugin gcc-gdc gcc-gfortran gcc-gm2 
gcc-gnat gcc-go gcc-objc gcc-objc++ gcc-offload-nvptx gcc-plugin-annobin 
gcc-plugin-devel libasan libasan-static libatomic libatomic-static libgcc 
libgccjit libgccjit-devel libgfortran libgfortran-static libgm2 libgm2-static 
libgnat libgnat-devel libgnat-static libgo libgo-devel libgo-static libgomp 
libgomp-offload-nvptx libgphobos libgphobos-static libhwasan libhwasan-static 
libitm libitm-devel libitm-static liblsan liblsan-static libobjc libquadmath 
libquadmath-devel libquadmath-static libstdc++ libstdc++-devel libstdc++-docs 
libstdc++-static libtsan libtsan-static libubsan libubsan-static
Size: 916.88 MiB
Size change:  -962.40 KiB
Changelog:
  * Tue Feb 21 2023 Jakub Jelinek  13.0.1-0.5
  - update from trunk
- PRs analyzer/108664, analyzer/108666, analyzer/108725, analyzer/108806,
c++/52809, c++/53638, c++/87389, c++/89741, c++/92099, c++/97553,
c++/101073, c++/104041, c++/104691, c++/107773, c++/108243,
c++/108829, c/105660, c/108375, fortran/103608, fortran/104554,
libstdc++/108030, target/90458, target/108805, target/108831,
target/108832, target/108862, testsuite/108835,
tree-optimization/108657, tree-optimization/108783,
tree-optimization/108791, tree-optimization/108816,
tree-optimization/108819, tree-optimization/108821,
tree-optimization/108825, tree-optimization/108855,
tree-optimization/108868


Package:  golang-helm-3-3.11.1-1.fc38
Old package:  golang-helm-3-3.5.4-2.fc35
Summary:  The Kubernetes Package Manager
RPMs: golang-helm-3-devel helm
Size: 55.82 MiB
Size change:  27.72 MiB
Changelog:
  * Thu Jan 20 2022 Fedora Release Engineering  - 
3.5.4-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Sat Jul 09 2022 Maxwell G  - 3.5.4-4
  - Rebuild for CVE-2022-{24675,28327,29526 in golang}

  * Tue Jul 19 2022 Maxwell G  - 3.5.4-5
  - Rebuild for CVE-2022-{1705,32148,30631,30633,28131,30635,30632,30630,1962} 
in
golang

  * Thu Jul 21 2022 Fedora Release Engineering  - 
3.5.4-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

  * Wed Aug 10 2022 Maxwell G  - 3.5.4-7
  - Rebuild to fix FTBFS

  * Thu Jan 19 2023 Fedora Release Engineering  - 
3.5.4-8
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

  * Tue Feb 21 2023 Davide Cavalca  - 3.11.1-1
  - Update to 3.11.1; Fixes: RHBZ#1977738, RHBZ#2045644, RHBZ#2138841,
RHBZ#2142198, RHBZ#2142210, RHBZ#2097975, RHBZ#2155938, RHBZ#2155939,
RHBZ#2163231, RHBZ#1971091, RHBZ#1971029


Package:  perl-DBD-Pg-3.16.0-3.module_f38+16255+02d9c530
Old package

Re: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Jonathan Wakely
On Thu, 23 Feb 2023 at 11:41, Zbigniew Jędrzejewski-Szmek wrote:
>
> On Thu, Feb 23, 2023 at 12:28:48PM +0100, Kalev Lember wrote:
> > On Thu, Feb 23, 2023 at 12:17 PM Zbigniew Jędrzejewski-Szmek <
> > zbys...@in.waw.pl> wrote:
> > I think you got something wrong with your repoquery. Perhaps it picked up
> > older packages from a published rawhide compose that were still linked with
> > older boost?
>
> It seems so. I thought the compose would have already happened.
> Sorry for the confusion.
>
> This is shorter, but still quite long.
>
> > My list of things needing rebuild is much shorter:
> >
> > $ dnf repoquery --whatrequires 'libboost*.so.1.78.0()(64bit)'
> > --disablerepo='*' --enablerepo=rawhide-koji -s
> > 0ad-0.0.26-7.fc38.src.rpm
> > blender-3.4.1-11.fc39.src.rpm
> > ceph-17.2.5-11.fc39.src.rpm
> > condor-8.8.15-7.fc37.src.rpm
> > credentials-fetcher-1.1.0-3.fc39.src.rpm
> > cryfs-0.11.2-6.fc38.src.rpm
> > dolfin-2019.1.0.post0-37.fc38.src.rpm
> That's my package. I see 'Rebuilt for Boost 1.81' in dist-git, but
> no attempt in koji (?). I'll start a build now.

I see why it got missed, I'll send a fix to Tom for the makefile.
___
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: FTBFS bug filed, build already deleted

2023-02-23 Thread Jonathan Wakely
On Wed, 22 Feb 2023 at 14:21, Scott Talbert wrote:
>
> On Wed, 22 Feb 2023, Kevin Kofler via devel wrote:
>
> > Julian Sikorski wrote:
> >> FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> >> build [2] has already been deleted. This is not ideal from maintainer
> >> perspective as it effectively is a bug with no info provided whatsoever.
> >> Not to mention being quite wasteful from the resources perspective as
> >> mame builds take quite a while.
> >> While not much can be done now, can we make sure that the mass rebuild
> >> builds do not get garbage collected, or at least the build logs are
> >> saved somewhere? Thanks.
> >
> > This is a constantly recurring problem. I have run into this very
> > frequently. The retention period for failed build logs is way too short. It
> > needs to be at least 13 months (the approximate time we get to fix an FTBFS
> > bug before the package is retired).
>
> I have to agree here.  There is nothing more frustrating as a contributor
> than going to investigate a FTBFS for a package and finding the logs are
> gone.

When it's a hard-to-reproduce issue on s390x, then I agree, it's a
problem when the only info about the failure is gone.

But the current situation is different. The mass rebuild failures are
usually failures on every arch, due to changes in the buildroot
(typically GCC 13, but sometimes other things that changed since the
last successful build of the package). And the failures can be easily
reproduced with a new scratch build, and then you have fresh logs.
It's an inconvenience, sure, but I regularly encounter far more
frustrating things to deal with as a contributor :-)
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Feb 23, 2023 at 12:28:48PM +0100, Kalev Lember wrote:
> On Thu, Feb 23, 2023 at 12:17 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> I think you got something wrong with your repoquery. Perhaps it picked up
> older packages from a published rawhide compose that were still linked with
> older boost?

It seems so. I thought the compose would have already happened.
Sorry for the confusion.

This is shorter, but still quite long.

> My list of things needing rebuild is much shorter:
> 
> $ dnf repoquery --whatrequires 'libboost*.so.1.78.0()(64bit)'
> --disablerepo='*' --enablerepo=rawhide-koji -s
> 0ad-0.0.26-7.fc38.src.rpm
> blender-3.4.1-11.fc39.src.rpm
> ceph-17.2.5-11.fc39.src.rpm
> condor-8.8.15-7.fc37.src.rpm
> credentials-fetcher-1.1.0-3.fc39.src.rpm
> cryfs-0.11.2-6.fc38.src.rpm
> dolfin-2019.1.0.post0-37.fc38.src.rpm
That's my package. I see 'Rebuilt for Boost 1.81' in dist-git, but
no attempt in koji (?). I'll start a build now.

> dyninst-12.2.0-2.fc38.src.rpm
> fastnetmon-1.2.1-5.20220528git420e7b8.fc38.src.rpm
> fbthrift-2022.07.11.00-2.fc37.src.rpm
> folly-2022.07.11.00-4.fc38.src.rpm
> galera-26.4.13-2.fc38.src.rpm
> gazebo-10.1.0-34.fc38.src.rpm
> gnucash-4.13-5.fc38.src.rpm
> heaptrack-1.2.0-11.fc38.src.rpm
> inkscape-1.2.2-5.fc38.src.rpm
> libreoffice-7.5.0.3-2.fc38.src.rpm
> libzypp-17.31.1-2.fc38.src.rpm
> luxcorerender-2.6-19.fc38.src.rpm
> mapnik-3.1.0-24.fc38.src.rpm
> mcrouter-0.41.0.20220711-2.fc38.src.rpm
> nextpnr-1-16.20230104gita46afc6.fc38.src.rpm
> pcb2gcode-1.3.2-25.fc38.src.rpm
> prusa-slicer-2.4.2-7.fc38.src.rpm
> pulseeffects-5.0.4-7.fc38.src.rpm
> python-mapnik-3.0.23-22.20200224git7da019c.fc38.src.rpm
> rstudio-2022.12.0+353-1.fc38.src.rpm
> snapper-0.10.1-2.fc37.src.rpm
> sourcextractor++-0.19-5.fc38.src.rpm
> systemtap-4.8-2.fc38.src.rpm
> usd-22.05b-23.fc39.src.rpm
> vsomeip3-3.1.20.3-10.fc38.src.rpm
> wesnoth-1.17.13-1.fc39.src.rpm

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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

2023-02-23 Thread Jonathan Wakely
On Thu, 23 Feb 2023 at 11:10, Miro Hrončok wrote:
>
> On 23. 02. 23 11:50, Jonathan Wakely wrote:
> > On Thu, 23 Feb 2023 at 09:34, Miro Hrončok wrote:
> >>
> >> On 23. 02. 23 2:37, Thomas Rodgers wrote:
> >>> imath is listed as a prerequisite for OpenImageIO, but not openvdb. Fixed 
> >>> now.
> >>
> >> Listed where? It's not necessary to construct a dependency tree, it was
> >> entirely possible to keep restarting the failures until nothing else built 
> >> the
> >> last time I run a Boost rebuild.
> >
> >
> > Yes, it's possible to just keep building, but it's faster and uses
> > fewer resources to build in dependency order. And the process can be
> > left unattended.
> >
> > One or two missing dependencies can easily be dealt with afterwards,
> > rather than dozens of rebuilds being started in a loop until they
> > work.
> >
> > If you want to use brute force for your rebuilds, go ahead, but that's
> > not the only way :-)
>
> Sure, I just wanted to point out that if the dependency tree calculation is
> flawed, using brute force could have prevented this.
>
> I'd take wasting machine resources over wasting people resources any day.

Agreed. The missing dependency info could/should have been spotted and
corrected, and then new builds run, before merging the side tag back
to rawhide.
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Jonathan Wakely
On Thu, 23 Feb 2023 at 11:29, Kalev Lember  wrote:
> I think you got something wrong with your repoquery. Perhaps it picked up 
> older packages from a published rawhide compose that were still linked with 
> older boost?
>
> My list of things needing rebuild is much shorter:

This list is what I'd expect to see, and I think all of those either
have an open FTBFS in bugzilla (some failed in the mass rebuild
already, a few are new failures with Boost 1.81) or have been fixed
already (e.g. rstudio).
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Jonathan Wakely
On Thu, 23 Feb 2023 at 11:33, Jonathan Wakely  wrote:
>
> On Thu, 23 Feb 2023 at 10:49, Richard W.M. Jones  wrote:
> >
> > boost 1.81.0 (side tag f39-boost) was merged into Fedora earlier this week:
> >
> >   https://koji.fedoraproject.org/koji/packageinfo?packageID=1074
> >
> > These are the builds in the side tag:
> >
> >   
> > https://koji.fedoraproject.org/koji/builds?inherited=0=63053=-build_id=1
> >
> > However I think some packages didn't get rebuilt.  Definitely
> > systemtap, which causes this problem with qemu:
> >
> >   https://koschei.fedoraproject.org/package/qemu?collection=f39
> >
> >   - nothing provides libboost_system.so.1.78.0()(64bit) needed by 
> > systemtap-devel-4.8-2.fc38.x86_64
> >
> > Possibly ceph, causing:
> >
> >   https://koschei.fedoraproject.org/package/virt-v2v?collection=f39
> >   https://koschei.fedoraproject.org/package/libguestfs?collection=f39
> >
> >   - nothing provides libboost_thread.so.1.78.0()(64bit) needed by 
> > librados2-2:17.2.5-11.fc39.x86_64
> >   - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by 
> > librados2-2:17.2.5-11.fc39.x86_64
> >
> > There's a comment in the current ceph package saying that it's
> > incompatible with boost 1.81 so they've switched back to the bundled
> > copy.  However we still don't have an installable package.
> >
> > I think systemtap needs to be added to the list of packages that
> > depend on boost for next time.  The systemtap spec file is a maze of
> > twisty RPM macros all alike, so perhaps whatever script is used to
> > check for things requiring boost got confused:
> >
> >   https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec
>
> systemtap is already in the list (and I bumped the spec file for it
> before Tom started the rebuilds).
>
> It didn't get rebuilt because it depends on dyninst, which is FTBFS
> with GCC 13 due to header changes (I think fche has a fix pending).
>
> Once dyninst has been rebuilt, then systemtap can be rebuilt.

FWIW the list of packages to rebuild for Boost is obtained using this
command, which I ran on Monday just before the rebuilds started:

dnf repoquery -s --releasever=rawhide --whatrequires libboost\*
--repo=fedora | sed -n 's/-[[:digit:]].*//p' | grep -v '^boost$' |
sort -u

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


Re: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Jonathan Wakely
On Thu, 23 Feb 2023 at 10:49, Richard W.M. Jones  wrote:
>
> boost 1.81.0 (side tag f39-boost) was merged into Fedora earlier this week:
>
>   https://koji.fedoraproject.org/koji/packageinfo?packageID=1074
>
> These are the builds in the side tag:
>
>   
> https://koji.fedoraproject.org/koji/builds?inherited=0=63053=-build_id=1
>
> However I think some packages didn't get rebuilt.  Definitely
> systemtap, which causes this problem with qemu:
>
>   https://koschei.fedoraproject.org/package/qemu?collection=f39
>
>   - nothing provides libboost_system.so.1.78.0()(64bit) needed by 
> systemtap-devel-4.8-2.fc38.x86_64
>
> Possibly ceph, causing:
>
>   https://koschei.fedoraproject.org/package/virt-v2v?collection=f39
>   https://koschei.fedoraproject.org/package/libguestfs?collection=f39
>
>   - nothing provides libboost_thread.so.1.78.0()(64bit) needed by 
> librados2-2:17.2.5-11.fc39.x86_64
>   - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by 
> librados2-2:17.2.5-11.fc39.x86_64
>
> There's a comment in the current ceph package saying that it's
> incompatible with boost 1.81 so they've switched back to the bundled
> copy.  However we still don't have an installable package.
>
> I think systemtap needs to be added to the list of packages that
> depend on boost for next time.  The systemtap spec file is a maze of
> twisty RPM macros all alike, so perhaps whatever script is used to
> check for things requiring boost got confused:
>
>   https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec

systemtap is already in the list (and I bumped the spec file for it
before Tom started the rebuilds).

It didn't get rebuilt because it depends on dyninst, which is FTBFS
with GCC 13 due to header changes (I think fche has a fix pending).

Once dyninst has been rebuilt, then systemtap can be rebuilt.
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Kalev Lember
On Thu, Feb 23, 2023 at 12:17 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> The problem is more widespread :(
>
> $ (dnf5 repoquery --whatrequires 'libboost_thread.so.1.78.0()(64bit)';
> dnf5 repoquery --whatrequires 'libboost_iostreams.so.1.78.0()(64bit)'; dnf5
> repoquery --whatrequires 'libboost_system.so.1.78.0()(64bit)') 2>/dev/null
> | sort -u
>
> Field3D-0:1.7.3-20.fc38.x86_64
> FlightCrew-cli-0:0.9.1-30.fc38.x86_64
> FlightCrew-sigil-plugin-0:0.9.1-30.fc38.x86_64
> OpenImageIO-0:2.4.8.1-1.fc39.x86_64
> anyterm-0:1.2.3-14.fc38.x86_64
> aqsis-0:1.8.2-50.fc38.x86_64
> aqsis-core-0:1.8.2-50.fc38.x86_64
> aqsis-libs-0:1.8.2-50.fc38.x86_64
> bear-engine-0:0.7.0-0.40.20200220git2a78522.fc38.x86_64
> boost-http-server-0:0-5.20220116gitcd5245f.fc38.x86_64
> boost-locale-0:1.78.0-11.fc38.x86_64
> boost-log-0:1.78.0-11.fc38.x86_64
> boost-type_erasure-0:1.78.0-11.fc38.x86_64
> boost-wave-0:1.78.0-11.fc38.x86_64
> btbuilder-0:0.5.19-4.fc38.x86_64
> ceph-common-2:17.2.5-11.fc39.x86_64
> ceph-exporter-2:17.2.5-11.fc39.x86_64
> ceph-osd-2:17.2.5-11.fc39.x86_64
> ceph-radosgw-2:17.2.5-11.fc39.x86_64
> ceph-test-2:17.2.5-11.fc39.x86_64
> codeblocks-contrib-0:20.03-16.20230124svn13161.fc38.x86_64
> cpp-hocon-0:0.3.0-26.fc38.x86_64
> cryfs-0:0.11.2-6.fc38.x86_64
> dmlite-dome-0:1.15.2-13.fc38.x86_64
> dmlite-dpm-xrootd-0:1.15.2-13.fc38.x86_64
> dmlite-libs-0:1.15.2-13.fc38.x86_64
> dmlite-plugins-domeadapter-0:1.15.2-13.fc38.x86_64
> dmlite-plugins-mysql-0:1.15.2-13.fc38.x86_64
> dolfin-0:2019.1.0.post0-37.fc38.x86_64
> domoticz-0:2022.1-6.fc38.x86_64
> dssp-0:3.0.0-16.fc37.x86_64
> dyninst-0:12.2.0-2.fc38.x86_64
> eclib-0:20221012-4.fc38.x86_64
> fastnetmon-0:1.2.1-5.20220528git420e7b8.fc38.x86_64
> fcitx5-chinese-addons-0:5.0.16-2.fc38.x86_64
> flamerobin-0:0.9.3.1-24.fc38.x86_64
> freecad-1:0.20.2-3.fc38.x86_64
> freeopcua-0:0-37.20220717.bd13aee.fc38.x86_64
> gazebo-0:10.1.0-34.fc38.x86_64
> gazebo-libs-0:10.1.0-34.fc38.x86_64
> gazebo-ode-0:10.1.0-34.fc38.x86_64
> glob2-0:0.9.4.4-61.fc38.x86_64
> gnuradio-0:3.10.4.0-6.fc38.x86_64
> gr-osmosdr-0:0.2.4-3.fc38.x86_64
> guitarix-0:0.44.1-4.fc38.x86_64
> heaptrack-0:1.2.0-11.fc38.x86_64
> innoextract-0:1.9-9.fc38.x86_64
> kea-hooks-0:2.2.0-3.fc38.x86_64
> kea-libs-0:2.2.0-3.fc38.x86_64
> ledger-0:3.2.1-11.fc38.x86_64
> lgogdownloader-0:3.9-3.fc38.x86_64
> libime-0:1.0.15-2.fc38.x86_64
> libkolabxml-0:1.2.0-15.fc38.x86_64
> liblas-0:1.8.2-0.4.gitded4637.fc38.x86_64
> liborcus-0:0.17.2-8.fc38.x86_64
> liborcus-model-0:0.17.2-8.fc38.x86_64
> libphonenumber-0:8.12.57-6.fc38.x86_64
> librados2-2:17.2.5-11.fc39.x86_64
> librgw2-2:17.2.5-11.fc39.x86_64
> libzypp-0:17.31.1-2.fc38.x86_64
> lucene++-0:3.0.7-36.fc38.x86_64
> lunchbox-devel-0:1.17.0-7.fc38.x86_64
> luxcorerender-core-0:2.6-19.fc38.x86_64
> lv2-c++-tools-devel-0:1.0.5-16.fc38.x86_64
> maeparser-0:1.3.1-1.fc38.x86_64
> mapnik-0:3.1.0-24.fc38.x86_64
> mapnik-utils-0:3.1.0-24.fc38.x86_64
> mir-server-libs-0:2.12.0-1.fc38.x86_64
> mmseq-0:1.0.11-14.fc38.x86_64
> ncmpcpp-0:0.9.2-11.fc38.x86_64
> nextpnr-0:1-16.20230104gita46afc6.fc38.x86_64
> ogre-1:1.9.0-43.fc38.x86_64
> ogre-terrain-1:1.9.0-43.fc38.x86_64
> ogre-volume-1:1.9.0-43.fc38.x86_64
> openshadinglanguage-libs-0:1.12.9.0-1.fc38.x86_64
> opentrep-0:0.07.11-5.fc38.x86_64
> openvdb-libs-0:10.0.1-1.fc38.x86_64
> pcl-0:1.12.0-25.fc38.x86_64
> poedit-0:3.2.2-3.fc38.x86_64
> pokerth-0:1.1.2-24.fc38.x86_64
> povray-0:3.7.0.10-9.fc38.x86_64
> prusa-slicer-0:2.4.2-7.fc38.x86_64
> python-tdlib-0:0.9.2-6.20210929.e8ec911.fc38.x86_64
> python3-gattlib-0:0.20210616-3.fc38.x86_64
> python3-graph-tool-0:2.45-6.fc38.x86_64
> python3-luxcorerender-0:2.6-19.fc38.x86_64
> python3-mapnik-0:3.0.23-22.20200224git7da019c.fc38.x86_64
> radiotray-ng-0:0.2.8-8.fc38.x86_64
> rstudio-0:2022.12.0+353-1.fc38.x86_64
> rstudio-desktop-0:2022.12.0+353-1.fc38.x86_64
> rstudio-server-0:2022.12.0+353-1.fc38.x86_64
> simspark-0:0.3.3-6.fc38.x86_64
> slic3r-0:1.3.0-28.fc38.x86_64
> smesh-0:9.8.0.2-5.fc38.x86_64
> snapper-0:0.10.1-2.fc37.x86_64
> snapper-libs-0:0.10.1-2.fc37.x86_64
> sourcextractor++-0:0.19-5.fc38.x86_64
> supercollider-0:3.12.2-8.fc38.x86_64
> systemtap-client-0:4.8-2.fc38.x86_64
> systemtap-devel-0:4.8-2.fc38.x86_64
> systemtap-runtime-0:4.8-2.fc38.x86_64
> trellis-0:1.2.1-14.20230215git0c522ce.fc39.x86_64
> trellis-devel-0:1.2.1-14.20230215git0c522ce.fc39.x86_64
> uhd-0:4.4.0.0-1.fc38.x86_64
> vsomeip3-0:3.1.20.3-10.fc38.x86_64
> vsomeip3-compat-0:3.1.20.3-10.fc38.x86_64
> wesnoth-0:1.17.13-1.fc39.x86_64
> wesnoth-server-0:1.17.13-1.fc39.x86_64
> wsjtx-0:2.6.1-1.fc38.x86_64
>

I think you got something wrong with your repoquery. Perhaps it picked up
older packages from a published rawhide compose that were still linked with
older boost?

My list of things needing rebuild is much shorter:

$ dnf repoquery --whatrequires 'libboost*.so.1.78.0()(64bit)'
--disablerepo='*' --enablerepo=rawhide-koji -s
0ad-0.0.26-7.fc38.src.rpm
blender-3.4.1-11.fc39.src.rpm

Re: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Miro Hrončok

On 23. 02. 23 12:16, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Feb 23, 2023 at 10:49:30AM +, Richard W.M. Jones wrote:

boost 1.81.0 (side tag f39-boost) was merged into Fedora earlier this week:

   https://koji.fedoraproject.org/koji/packageinfo?packageID=1074

These are the builds in the side tag:

   
https://koji.fedoraproject.org/koji/builds?inherited=0=63053=-build_id=1

However I think some packages didn't get rebuilt.  Definitely
systemtap, which causes this problem with qemu:

   https://koschei.fedoraproject.org/package/qemu?collection=f39

   - nothing provides libboost_system.so.1.78.0()(64bit) needed by 
systemtap-devel-4.8-2.fc38.x86_64

Possibly ceph, causing:

   https://koschei.fedoraproject.org/package/virt-v2v?collection=f39
   https://koschei.fedoraproject.org/package/libguestfs?collection=f39

   - nothing provides libboost_thread.so.1.78.0()(64bit) needed by 
librados2-2:17.2.5-11.fc39.x86_64
   - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by 
librados2-2:17.2.5-11.fc39.x86_64


The problem is more widespread :(

$ (dnf5 repoquery --whatrequires 'libboost_thread.so.1.78.0()(64bit)'; dnf5 
repoquery --whatrequires 'libboost_iostreams.so.1.78.0()(64bit)'; dnf5 repoquery 
--whatrequires 'libboost_system.so.1.78.0()(64bit)') 2>/dev/null | sort -u


It seems like you are querying composed/mirrored rawhide instead of the Koji 
buildroot.


E.g. you listed slic3r-0:1.3.0-28.fc38.x86_64 but release 29.fc39 links to new 
boost:


https://koji.fedoraproject.org/koji/buildinfo?buildID=2156386

$ repoquery --repo=koji --whatrequires 'libboost_thread.so.1.78.0()(64bit)' 
--whatrequires 'libboost_iostreams.so.1.78.0()(64bit)' --whatrequires 
'libboost_system.so.1.78.0()(64bit)'


ceph-common-2:17.2.5-11.fc39.x86_64
ceph-exporter-2:17.2.5-11.fc39.x86_64
ceph-osd-2:17.2.5-11.fc39.x86_64
ceph-radosgw-2:17.2.5-11.fc39.x86_64
ceph-test-2:17.2.5-11.fc39.x86_64
cryfs-0:0.11.2-6.fc38.x86_64
dolfin-0:2019.1.0.post0-37.fc38.x86_64
dyninst-0:12.2.0-2.fc38.x86_64
fastnetmon-0:1.2.1-5.20220528git420e7b8.fc38.x86_64
gazebo-0:10.1.0-34.fc38.x86_64
gazebo-libs-0:10.1.0-34.fc38.x86_64
gazebo-ode-0:10.1.0-34.fc38.x86_64
heaptrack-0:1.2.0-11.fc38.x86_64
librados2-2:17.2.5-11.fc39.x86_64
librgw2-2:17.2.5-11.fc39.x86_64
libzypp-0:17.31.1-2.fc38.x86_64
luxcorerender-core-0:2.6-19.fc38.x86_64
mapnik-0:3.1.0-24.fc38.x86_64
mapnik-utils-0:3.1.0-24.fc38.x86_64
nextpnr-0:1-16.20230104gita46afc6.fc38.x86_64
prusa-slicer-0:2.4.2-7.fc38.x86_64
python3-luxcorerender-0:2.6-19.fc38.x86_64
python3-mapnik-0:3.0.23-22.20200224git7da019c.fc38.x86_64
snapper-0:0.10.1-2.fc37.x86_64
snapper-libs-0:0.10.1-2.fc37.x86_64
sourcextractor++-0:0.19-5.fc38.x86_64
systemtap-client-0:4.8-2.fc38.x86_64
systemtap-devel-0:4.8-2.fc38.x86_64
systemtap-runtime-0:4.8-2.fc38.x86_64
vsomeip3-0:3.1.20.3-10.fc38.x86_64
vsomeip3-compat-0:3.1.20.3-10.fc38.x86_64
wesnoth-0:1.17.13-1.fc39.x86_64
wesnoth-server-0:1.17.13-1.fc39.x86_64


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


Fwd: fedmsg notification

2023-02-23 Thread Jonathan Wakely
What does this notification mean, and how do I turn it off?

The filter UI for notifications is impossible to understand.

-- Forwarded message -
From: 
Date: Thu, 23 Feb 2023 at 10:25
Subject: fedmsg notification



Notification time stamped 2023-02-23 10:25:03 UTC


https://bodhi.fedoraproject.org

--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/jwakely.id.fedoraproject.org/email/29140
___
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: Some boost breakage in Fedora Rawhide

2023-02-23 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Feb 23, 2023 at 10:49:30AM +, Richard W.M. Jones wrote:
> boost 1.81.0 (side tag f39-boost) was merged into Fedora earlier this week:
> 
>   https://koji.fedoraproject.org/koji/packageinfo?packageID=1074
> 
> These are the builds in the side tag:
> 
>   
> https://koji.fedoraproject.org/koji/builds?inherited=0=63053=-build_id=1
> 
> However I think some packages didn't get rebuilt.  Definitely
> systemtap, which causes this problem with qemu:
> 
>   https://koschei.fedoraproject.org/package/qemu?collection=f39
> 
>   - nothing provides libboost_system.so.1.78.0()(64bit) needed by 
> systemtap-devel-4.8-2.fc38.x86_64
> 
> Possibly ceph, causing:
> 
>   https://koschei.fedoraproject.org/package/virt-v2v?collection=f39
>   https://koschei.fedoraproject.org/package/libguestfs?collection=f39
> 
>   - nothing provides libboost_thread.so.1.78.0()(64bit) needed by 
> librados2-2:17.2.5-11.fc39.x86_64
>   - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by 
> librados2-2:17.2.5-11.fc39.x86_64

The problem is more widespread :(

$ (dnf5 repoquery --whatrequires 'libboost_thread.so.1.78.0()(64bit)'; dnf5 
repoquery --whatrequires 'libboost_iostreams.so.1.78.0()(64bit)'; dnf5 
repoquery --whatrequires 'libboost_system.so.1.78.0()(64bit)') 2>/dev/null | 
sort -u

Field3D-0:1.7.3-20.fc38.x86_64
FlightCrew-cli-0:0.9.1-30.fc38.x86_64
FlightCrew-sigil-plugin-0:0.9.1-30.fc38.x86_64
OpenImageIO-0:2.4.8.1-1.fc39.x86_64
anyterm-0:1.2.3-14.fc38.x86_64
aqsis-0:1.8.2-50.fc38.x86_64
aqsis-core-0:1.8.2-50.fc38.x86_64
aqsis-libs-0:1.8.2-50.fc38.x86_64
bear-engine-0:0.7.0-0.40.20200220git2a78522.fc38.x86_64
boost-http-server-0:0-5.20220116gitcd5245f.fc38.x86_64
boost-locale-0:1.78.0-11.fc38.x86_64
boost-log-0:1.78.0-11.fc38.x86_64
boost-type_erasure-0:1.78.0-11.fc38.x86_64
boost-wave-0:1.78.0-11.fc38.x86_64
btbuilder-0:0.5.19-4.fc38.x86_64
ceph-common-2:17.2.5-11.fc39.x86_64
ceph-exporter-2:17.2.5-11.fc39.x86_64
ceph-osd-2:17.2.5-11.fc39.x86_64
ceph-radosgw-2:17.2.5-11.fc39.x86_64
ceph-test-2:17.2.5-11.fc39.x86_64
codeblocks-contrib-0:20.03-16.20230124svn13161.fc38.x86_64
cpp-hocon-0:0.3.0-26.fc38.x86_64
cryfs-0:0.11.2-6.fc38.x86_64
dmlite-dome-0:1.15.2-13.fc38.x86_64
dmlite-dpm-xrootd-0:1.15.2-13.fc38.x86_64
dmlite-libs-0:1.15.2-13.fc38.x86_64
dmlite-plugins-domeadapter-0:1.15.2-13.fc38.x86_64
dmlite-plugins-mysql-0:1.15.2-13.fc38.x86_64
dolfin-0:2019.1.0.post0-37.fc38.x86_64
domoticz-0:2022.1-6.fc38.x86_64
dssp-0:3.0.0-16.fc37.x86_64
dyninst-0:12.2.0-2.fc38.x86_64
eclib-0:20221012-4.fc38.x86_64
fastnetmon-0:1.2.1-5.20220528git420e7b8.fc38.x86_64
fcitx5-chinese-addons-0:5.0.16-2.fc38.x86_64
flamerobin-0:0.9.3.1-24.fc38.x86_64
freecad-1:0.20.2-3.fc38.x86_64
freeopcua-0:0-37.20220717.bd13aee.fc38.x86_64
gazebo-0:10.1.0-34.fc38.x86_64
gazebo-libs-0:10.1.0-34.fc38.x86_64
gazebo-ode-0:10.1.0-34.fc38.x86_64
glob2-0:0.9.4.4-61.fc38.x86_64
gnuradio-0:3.10.4.0-6.fc38.x86_64
gr-osmosdr-0:0.2.4-3.fc38.x86_64
guitarix-0:0.44.1-4.fc38.x86_64
heaptrack-0:1.2.0-11.fc38.x86_64
innoextract-0:1.9-9.fc38.x86_64
kea-hooks-0:2.2.0-3.fc38.x86_64
kea-libs-0:2.2.0-3.fc38.x86_64
ledger-0:3.2.1-11.fc38.x86_64
lgogdownloader-0:3.9-3.fc38.x86_64
libime-0:1.0.15-2.fc38.x86_64
libkolabxml-0:1.2.0-15.fc38.x86_64
liblas-0:1.8.2-0.4.gitded4637.fc38.x86_64
liborcus-0:0.17.2-8.fc38.x86_64
liborcus-model-0:0.17.2-8.fc38.x86_64
libphonenumber-0:8.12.57-6.fc38.x86_64
librados2-2:17.2.5-11.fc39.x86_64
librgw2-2:17.2.5-11.fc39.x86_64
libzypp-0:17.31.1-2.fc38.x86_64
lucene++-0:3.0.7-36.fc38.x86_64
lunchbox-devel-0:1.17.0-7.fc38.x86_64
luxcorerender-core-0:2.6-19.fc38.x86_64
lv2-c++-tools-devel-0:1.0.5-16.fc38.x86_64
maeparser-0:1.3.1-1.fc38.x86_64
mapnik-0:3.1.0-24.fc38.x86_64
mapnik-utils-0:3.1.0-24.fc38.x86_64
mir-server-libs-0:2.12.0-1.fc38.x86_64
mmseq-0:1.0.11-14.fc38.x86_64
ncmpcpp-0:0.9.2-11.fc38.x86_64
nextpnr-0:1-16.20230104gita46afc6.fc38.x86_64
ogre-1:1.9.0-43.fc38.x86_64
ogre-terrain-1:1.9.0-43.fc38.x86_64
ogre-volume-1:1.9.0-43.fc38.x86_64
openshadinglanguage-libs-0:1.12.9.0-1.fc38.x86_64
opentrep-0:0.07.11-5.fc38.x86_64
openvdb-libs-0:10.0.1-1.fc38.x86_64
pcl-0:1.12.0-25.fc38.x86_64
poedit-0:3.2.2-3.fc38.x86_64
pokerth-0:1.1.2-24.fc38.x86_64
povray-0:3.7.0.10-9.fc38.x86_64
prusa-slicer-0:2.4.2-7.fc38.x86_64
python-tdlib-0:0.9.2-6.20210929.e8ec911.fc38.x86_64
python3-gattlib-0:0.20210616-3.fc38.x86_64
python3-graph-tool-0:2.45-6.fc38.x86_64
python3-luxcorerender-0:2.6-19.fc38.x86_64
python3-mapnik-0:3.0.23-22.20200224git7da019c.fc38.x86_64
radiotray-ng-0:0.2.8-8.fc38.x86_64
rstudio-0:2022.12.0+353-1.fc38.x86_64
rstudio-desktop-0:2022.12.0+353-1.fc38.x86_64
rstudio-server-0:2022.12.0+353-1.fc38.x86_64
simspark-0:0.3.3-6.fc38.x86_64
slic3r-0:1.3.0-28.fc38.x86_64
smesh-0:9.8.0.2-5.fc38.x86_64
snapper-0:0.10.1-2.fc37.x86_64
snapper-libs-0:0.10.1-2.fc37.x86_64
sourcextractor++-0:0.19-5.fc38.x86_64
supercollider-0:3.12.2-8.fc38.x86_64
systemtap-client-0:4.8-2.fc38.x86_64
systemtap-devel-0:4.8-2.fc38.x86_64

Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

2023-02-23 Thread Miro Hrončok

On 23. 02. 23 11:50, Jonathan Wakely wrote:

On Thu, 23 Feb 2023 at 09:34, Miro Hrončok wrote:


On 23. 02. 23 2:37, Thomas Rodgers wrote:

imath is listed as a prerequisite for OpenImageIO, but not openvdb. Fixed now.


Listed where? It's not necessary to construct a dependency tree, it was
entirely possible to keep restarting the failures until nothing else built the
last time I run a Boost rebuild.



Yes, it's possible to just keep building, but it's faster and uses
fewer resources to build in dependency order. And the process can be
left unattended.

One or two missing dependencies can easily be dealt with afterwards,
rather than dozens of rebuilds being started in a loop until they
work.

If you want to use brute force for your rebuilds, go ahead, but that's
not the only way :-)


Sure, I just wanted to point out that if the dependency tree calculation is 
flawed, using brute force could have prevented this.


I'd take wasting machine resources over wasting people resources any day.

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


Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

2023-02-23 Thread Jonathan Wakely
On Thu, 23 Feb 2023 at 09:34, Miro Hrončok wrote:
>
> On 23. 02. 23 2:37, Thomas Rodgers wrote:
> > imath is listed as a prerequisite for OpenImageIO, but not openvdb. Fixed 
> > now.
>
> Listed where? It's not necessary to construct a dependency tree, it was
> entirely possible to keep restarting the failures until nothing else built the
> last time I run a Boost rebuild.


Yes, it's possible to just keep building, but it's faster and uses
fewer resources to build in dependency order. And the process can be
left unattended.

One or two missing dependencies can easily be dealt with afterwards,
rather than dozens of rebuilds being started in a loop until they
work.

If you want to use brute force for your rebuilds, go ahead, but that's
not the only way :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Some boost breakage in Fedora Rawhide

2023-02-23 Thread Richard W.M. Jones
boost 1.81.0 (side tag f39-boost) was merged into Fedora earlier this week:

  https://koji.fedoraproject.org/koji/packageinfo?packageID=1074

These are the builds in the side tag:

  
https://koji.fedoraproject.org/koji/builds?inherited=0=63053=-build_id=1

However I think some packages didn't get rebuilt.  Definitely
systemtap, which causes this problem with qemu:

  https://koschei.fedoraproject.org/package/qemu?collection=f39

  - nothing provides libboost_system.so.1.78.0()(64bit) needed by 
systemtap-devel-4.8-2.fc38.x86_64

Possibly ceph, causing:

  https://koschei.fedoraproject.org/package/virt-v2v?collection=f39
  https://koschei.fedoraproject.org/package/libguestfs?collection=f39

  - nothing provides libboost_thread.so.1.78.0()(64bit) needed by 
librados2-2:17.2.5-11.fc39.x86_64
  - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by 
librados2-2:17.2.5-11.fc39.x86_64

There's a comment in the current ceph package saying that it's
incompatible with boost 1.81 so they've switched back to the bundled
copy.  However we still don't have an installable package.

I think systemtap needs to be added to the list of packages that
depend on boost for next time.  The systemtap spec file is a maze of
twisty RPM macros all alike, so perhaps whatever script is used to
check for things requiring boost got confused:

  https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec

Rich.

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


[Bug 2172819] perl-SQL-Statement-1.414-10.fc39 tests produce a lot of warnings: Use of uninitialized value $unkpos in subtraction (-) at /usr/share/perl5/vendor_perl/Text/Balanced.pm line 1008

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172819



--- Comment #2 from Michal Josef Spacek  ---
Triggered by commit:
https://github.com/steve-m-hay/Text-Balanced/commit/744f78ff9566e3720860f830dc0b21facae9e648


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2172819
___
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: Help with systemd/cgroup task limits in koji

2023-02-23 Thread Florian Weimer
* Giuseppe Scrivano:

> Florian Weimer  writes:
>> It could be an old kernel bug:
>>
>>   Task exit is signaled before task resource deallocation, leading to
>>   bogus EAGAIN errors
>>   
>>
>> There have been recent namespace optimizations which introduce a similar
>> pattern there.  While they improve throughput in many cases, continuous
>> allocation and deallocation can now fail, even though the program logic
>> ensures that resources are never exceeded.
>>
>> Guiseppe, any suggestions how to debug this?
>
> the only optimization I am aware of that could cause a similar issue is
> the delayed IPC namespace cleanup.  That would cause the IPC namespace
> creation to fail though, not posix_spawn.
>
> If you believe the failure can be related to reaching the pids limit for
> the cgroup, could you please check the actual limit inside the
> container?  You could check the value of /sys/fs/cgroup/pids.max inside
> the container (assuming cgroupv2 and a cgroup namespace for the container).
>
> Please let me know if that helps.

(replying for the benefit of the list)
___
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: Unannounced .so version bump (F38/F39): openexr2

2023-02-23 Thread Marc Deop i Argemí
On Thursday, 23 February 2023 09:48:36 CET Marc Deop i Argemí wrote:
> > - kde-runtime
> > - kdebase3
> > - kdelibs

I created a side-tag: f39-build-side-63924 and rebuilt kdelibs and kde-
runtime.

However, it turns out I don't have commit access to kdebase3. I submitted a PR 
here: https://src.fedoraproject.org/rpms/kdebase3/pull-request/2

Could any kdebase3  maintainer please check it out and build on the 
aforementioned f39-build-side-63924 site-tag?

Best,

-- 
Marc Deop i Argemí
System Engineer

___
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 2172819] perl-SQL-Statement-1.414-10.fc39 tests produce a lot of warnings: Use of uninitialized value $unkpos in subtraction (-) at /usr/share/perl5/vendor_perl/Text/Balanced.pm line 1008

2023-02-23 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2172819



--- Comment #1 from Michal Josef Spacek  ---
Triggered by perl-Text-Balanced 2.05.
The issue exists in 2.06 still.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2172819
___
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: Proposal: drop delta rpms (for real this time)

2023-02-23 Thread Vít Ondruch


Dne 22. 02. 23 v 5:38 Kevin Kofler via devel napsal(a):

Kevin Fenzi wrote:

I fear the only way to fix it is to get pungi to merge entire repos, and
I don't think thats anything that pungi wants to be on the hook for
doing.

But there are more things than just DeltaRPMs it could be useful for. E.g.,
I remember that in ancient times (pre Core-Extras Merge), some Fedora
repository (IIRC, the old Fedora Extras) used to ship not only the latest
build for each package, but the TWO latest builds, so that if the latest
build was broken, you could easily downgrade to the previous one. That
should really be done in all the rolling repositories (updates, updates-
testing, Rawhide).



Once there was this DNF RFE:

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


Vít




 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


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


[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives

2023-02-23 Thread Miro Hrončok

On 30. 01. 23 21:39, Miro Hrončok wrote:

On 30. 01. 23 20:13, Miro Hrončok wrote:

On 11. 12. 22 15:48, Miro Hrončok wrote:

On 21. 11. 22 12:56, Miro Hrončok wrote:

On 09. 11. 22 20:07, Miro Hrončok wrote:

On 08. 11. 22 22:36, Troy Dawson wrote:

Hi Miro,
You have explained the problem very well, and a possible solution.
But I'm a bit confused as to what you want to happen.

Is this a heads up, that you are going to change something?
Do you want us to discuss what is the best thing to do?


Yes, that was my intention.

Are you letting us know about the problem, and want someone else to 
implement a solution?


I was prepared to implement it myself, but Maxwell is already looking into 
it.


https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54


As a followup, when we merge this, we might neeed to rebuild some affected 
packages.


A naïve query that returns everything that uses /usr/bin/python3 shebang 
but probably wants /usr/bin/python3.6:


$ comm -12 <(repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | 
sort) <(repoquery -q --repo=epel8 --whatrequires 'python3.6dist(*)' 
--whatrequires 'python(abi) = 3.6' | sort)

apprise-0:1.0.0-1.el8.noarch
argparse-manpage-0:4-1.el8.noarch
cekit-0:4.4.0-1.el8.noarch
copr-cli-0:1.103-1.el8.noarch
csmock-common-0:3.3.4-1.el8.noarch
csmock-plugin-gitleaks-0:3.3.4-1.el8.noarch
csmock-plugin-infer-0:3.3.4-1.el8.noarch
csmock-plugin-unicontrol-0:3.3.4-1.el8.noarch
distgen-0:1.14-1.el8.noarch
dmlite-shell-0:1.15.2-11.el8.x86_64
drgn-0:0.0.21-1.el8.x86_64
fedpkg-0:1.43-2.el8.noarch
fts-rest-client-0:3.12.0-1.el8.noarch
glances-0:3.3.0.1-1.el8.noarch
kf5-kapidox-0:5.96.0-1.el8.noarch
lightdm-gtk-greeter-settings-0:1.2.2-18.el8.noarch
meld-0:3.20.4-1.el8.noarch
mozo-0:1.26.2-1.el8.noarch
nordugrid-arc-arcctl-0:6.16.1-1.el8.x86_64
nordugrid-arc-arex-0:6.16.1-1.el8.x86_64
nordugrid-arc-0:6.16.1-1.el8.x86_64
podman-compose-0:1.0.3-3.el8.noarch
pypolicyd-spf-0:2.9.3-1.el8.noarch
PyQt-builder-0:1.13.0-2.el8.noarch
python3-bloom-0:0.11.2-1.el8.noarch
python3-breathe-0:4.11.1-1.el8.noarch
python3-django3-0:3.2.15-3.el8.noarch
python3-dotenv-0:0.19.2-4.el8.noarch
python3-impacket-0:0.10.0-1.el8.noarch
python3-ipython-0:7.16.3-1.el8.noarch
python3-junitxml-0:0.7-28.el8.noarch
python3-kaptan-0:0.5.12-15.el8.noarch
python3-kiwi-0:9.24.48-2.el8.noarch
python3-subunit-test-0:1.4.0-13.el8.noarch
python3-subunit-0:1.4.0-13.el8.noarch
python3-tabulate-0:0.8.10-1.el8.noarch
python3-testrepository-0:0.0.20-29.el8.noarch
python3-vcstool-0:0.3.0-1.el8.noarch
python3-virt-firmware-0:1.5-1.el8.noarch
python3-websockify-0:0.10.0-3.el8.noarch
rednotebook-0:2.26-1.el8.noarch
resalloc-openstack-0:9.3-1.el8.noarch
resalloc-server-0:4.8-1.el8.noarch
resalloc-webui-0:4.8-1.el8.noarch
retrace-server-0:1.24.2-1.el8.noarch
suricata-0:5.0.10-1.el8.x86_64
s3cmd-0:2.3.0-1.el8.noarch
tito-0:0.6.21-1.el8.noarch
yamllint-0:1.28.0-1.el8.noarch


But obviously, anything in this list *might* be affected:

$ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | wc -l
92
$ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 --source | sort 
| uniq | wc -l

73


I am building all the packages in 
https://copr.fedorainfracloud.org/coprs/churchyard/epel8-python3.6-shebang-rebuild/ to see if the shebang changes.


Something else came up, than the holidays and suddenly that repo is expired 
because I have created it as temporary :D


Will start over.



When it does change I plan to rebuild the package in EPEL 8.


The following packages FTBFS:

kwin

The following packages still build after an hour and I need to remember to 
check them later:


qt-creator
root

The rest needs a rebuild:

ansible-collection-community-general
ansible-packaging
argparse-manpage
asterisk
cepces
clifm
cockpit-file-sharing
distgen
fedpkg
fmf
fts-rest-client
git-tools
ipython
kcachegrind
kde-dev-scripts
kf5-kapidox
konversation
lightdm-gtk-greeter-settings
meld
mozo
netplan
packit
plasma-desktop
pluma
podman-compose
pypolicyd-spf
PyQt-builder
python-bloom
python-breathe
python-colcon-core
python-django3
python-dotenv
python-impacket
python-junitxml
python-kaptan
python-tabulate
python-testrepository
python-vcstool
python-websockify
resalloc
retrace-server
rlwrap
rpmconf
sasutils
subunit
s3cmd
tacacs
tito
vcs-diff-lint
zchunk

I don't want to disrupt any "the rawhide and epel8 branch must be in sync" 
workflows, so I'll probably send PRs.


I merged the PRs without response, built the packages and submitted the Bodhi 
updates. They gone stable by now. This has been "done" from my part.


Leftovers are on track:

$ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 --source | pkgname

ansible-collection-community-general
https://src.fedoraproject.org/rpms/ansible-collection-community-general/pull-request/12#comment-129648

mozo
my PR was merged but not built, submitted the update myself
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-5dd853f8d9

pluma
my PR was merged but not built, 

Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

2023-02-23 Thread Miro Hrončok

On 23. 02. 23 2:37, Thomas Rodgers wrote:

imath is listed as a prerequisite for OpenImageIO, but not openvdb. Fixed now.


Listed where? It's not necessary to construct a dependency tree, it was 
entirely possible to keep restarting the failures until nothing else built the 
last time I run a Boost rebuild.


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


  1   2   >