[Bug 2223063] New: perl-Function-Parameters-2.002004 is available

[bugzilla]

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

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



Releases retrieved: 2.002004
Upstream release that is considered latest: 2.002004
Current version/release in rawhide: 2.2.3-2.fc39
URL: http://search.cpan.org/dist/Function-Parameters/

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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202223063%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[updates]

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

python-colander-2.0-2.el9
python-colored-2.2.3-1.el9
python-dogpile-cache-1.2.2-2.el9
python-specfile-0.20.0-1.el9
rust-assert_cmd-2.0.12-1.el9
rust-cargo-platform-0.1.3-1.el9
rust-const-oid-0.9.4-1.el9
rust-ctor-0.2.4-1.el9
rust-dashmap-5.5.0-1.el9
rust-form_urlencoded-1.2.0-1.el9
rust-gif-0.12.0-1.el9
rust-gif0.11-0.11.4-1.el9
rust-idna-0.4.0-1.el9
rust-idna0.3-0.3.0-1.el9
rust-percent-encoding-2.3.0-1.el9
rust-proc-macro2-1.0.64-1.el9
rust-serde-1.0.171-1.el9
rust-serde_derive-1.0.171-1.el9
rust-serde_test-1.0.171-1.el9
rust-syn-2.0.25-1.el9
rust-tar-0.4.39-1.el9
rust-url-2.4.0-1.el9

Details about builds:



 python-colander-2.0-2.el9 (FEDORA-EPEL-2023-4bc90f29b5)
 Simple schema-based serialization and deserialization library

Update Information:

first build in epel9

ChangeLog:

* Thu Jun 15 2023 Python Maint  - 2.0-2
- Rebuilt for Python 3.12
* Mon Jan 23 2023 Jonathan Wright  - 2.0-1
- Update to 2.0 rhbz#2157806
* Fri Jan 20 2023 Fedora Release Engineering  - 
1.8.3-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Fri Jul 22 2022 Fedora Release Engineering  - 
1.8.3-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Tue Jun 14 2022 Python Maint  - 1.8.3-6
- Rebuilt for Python 3.11
* Fri Jan 21 2022 Fedora Release Engineering  - 
1.8.3-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Fri Jul 23 2021 Fedora Release Engineering  - 
1.8.3-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

References:

  [ 1 ] Bug #2163536 - Please branch and build python-colander in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2163536




 python-colored-2.2.3-1.el9 (FEDORA-EPEL-2023-e2f121d1a3)
 Library for color and formatting in terminal

Update Information:

update to 2.2.3

ChangeLog:

* Fri Jul 14 2023 Jonathan Wright  - 2.2.3-1
- Update to 2.2.3 rhbz#443
* Tue Jun 27 2023 Python Maint  - 2.2.2-2
- Rebuilt for Python 3.12




 python-dogpile-cache-1.2.2-2.el9 (FEDORA-EPEL-2023-cd0990b59d)
 A caching front-end based on the Dogpile lock

Update Information:

update to 1.2.2

ChangeLog:

* Fri Jul 14 2023 Jonathan Wright  - 1.2.2-2
- Add missing BR
* Fri Jul 14 2023 Jonathan Wright  - 1.2.2-1
- Update to 1.2.2 rhbz#2208776
* Thu Jun 15 2023 Python Maint  - 1.2.0-3
- Rebuilt for Python 3.12




 python-specfile-0.20.0-1.el9 (FEDORA-EPEL-2023-629b736b8c)
 A library for parsing and manipulating RPM spec files

Update Information:

Automatic update for python-specfile-0.20.0-1.el9.  # **Changelog for
python-specfile**  ``` * Thu Jul 13 2023 Packit  - 0.20.0-1 -
Fixed infinite loop when removing macros with `%` in the name. (#244) - Added a
possibility to undefine system macros by setting a macro value to `None` in the
`macros` argument of the `Specfile` constructor. (#244) - Fixed a bug in
processing options of `%prep` macros. For instance, when a quoted string
appeared inside an expression expansion, it could lead to improper parsing,
rendering the spec file invalid after accessing the options. (#253)  ```

ChangeLog:

* Thu Jul 13 2023 Packit  - 0.20.0-1
- Fixed infinite loop when removing macros with `%` in the name. (#244)
- Added a possibility to undefine system macros by setting a macro value to 
`None` in the `macros` argument of the `Specfile` constructor. (#244)
- Fixed a bug in processing options of `%prep` macros. For instance, when a 
quoted string appeared inside an expression expansion, it could lead to 
improper parsing, rendering the spec file invalid after accessing the options. 

Re: btrfs loses 32-bit application compatibility after a while

[Scott Talbert]

> On Fri, Jul 14, 2023 at 10:45 PM Eric Sandeen  wrote:
> 
> But that still raises the question - why does it look like this
> started to happen pretty suddenly around June 30?
> The list of updates that were applied to builders in that timeframe
> doesn't raise any alarm bells (except maybe the 6.3 kernel):
> (see https://pagure.io/releng/issue/11531#comment-864471)
> I read the release notes for the 6.3 kernel but didn't see any
> mentions of BTRFS changes that could explain this. :(

When did the builders get switched to btrfs?  Could it just be a matter of 
accumulating enough inodes since then?

Scott
___
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: btrfs loses 32-bit application compatibility after a while

[Eric Sandeen]

On 7/14/23 4:47 PM, Fabio Valentini wrote:

On Fri, Jul 14, 2023 at 10:45 PM Eric Sandeen  wrote:


On 7/14/23 6:53 AM, Florian Weimer wrote:

* Neal Gompa:


On Thu, Jul 13, 2023 at 8:29 AM Fabio Valentini  wrote:


On Thu, Jul 13, 2023 at 10:33 AM Florian Weimer  wrote:


Fedora lists are hostile to upstream collaboration via cross-posting, so
I can only forward this for your information.

This causes problems with the i686 builders.


I wonder how this only started to happen recently? Has something
changed in BTRFS with the 6.3 kernel?
This only started happening a few days after builders were rebooted at
the end of June to apply updates (and kernel 6.3 was among those
updates, as far as I can tell).



This was always possible. I'm curious as to why it took so long for us
to hit it, though.

The recommended solution is to create a new subvolume for these
environments, since the inode count is reset for each subvolume.


What about impact beyond the builders?

Are end users are expected to do this?  Do we have a tool for this?


FWIW, 64 bit inodes have existed in some Linux filesystems for a very
long time. On XFS, you'll get them by default - and quickly, not after
extended use - on a filesystem of sufficient size (around 1T-2T by
default, if I remember right.)

XFS does have a hack^Wmount option to force inodes into the 32-bit
range, but just FWIW we almost never see users running into problems
with 32-bit applications (but maybe because they know about the mount
option...)


But that still raises the question - why does it look like this
started to happen pretty suddenly around June 30?
The list of updates that were applied to builders in that timeframe
doesn't raise any alarm bells (except maybe the 6.3 kernel):
(see https://pagure.io/releng/issue/11531#comment-864471)
I read the release notes for the 6.3 kernel but didn't see any
mentions of BTRFS changes that could explain this. :(


Sure - I can't speak to what might have changed in btrfs, sorry - just 
saying that binaries that choke on 64 bit inodes are going to get less 
and less usable over time, I think.


One thing you could consider if you're ever really in a pinch is an 
ld_preload that fakes up a 32-bit inode number for i.e. stat. The vast 
majority of applications don't care about the inode number at all, and 
it's really kind of unfortunate to fail the whole stat call just for that.


-Eric
___
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: btrfs loses 32-bit application compatibility after a while

[Fabio Valentini]

On Fri, Jul 14, 2023 at 10:45 PM Eric Sandeen  wrote:
>
> On 7/14/23 6:53 AM, Florian Weimer wrote:
> > * Neal Gompa:
> >
> >> On Thu, Jul 13, 2023 at 8:29 AM Fabio Valentini  
> >> wrote:
> >>>
> >>> On Thu, Jul 13, 2023 at 10:33 AM Florian Weimer  
> >>> wrote:
> 
>  Fedora lists are hostile to upstream collaboration via cross-posting, so
>  I can only forward this for your information.
> 
>  This causes problems with the i686 builders.
> >>>
> >>> I wonder how this only started to happen recently? Has something
> >>> changed in BTRFS with the 6.3 kernel?
> >>> This only started happening a few days after builders were rebooted at
> >>> the end of June to apply updates (and kernel 6.3 was among those
> >>> updates, as far as I can tell).
> >>>
> >>
> >> This was always possible. I'm curious as to why it took so long for us
> >> to hit it, though.
> >>
> >> The recommended solution is to create a new subvolume for these
> >> environments, since the inode count is reset for each subvolume.
> >
> > What about impact beyond the builders?
> >
> > Are end users are expected to do this?  Do we have a tool for this?
>
> FWIW, 64 bit inodes have existed in some Linux filesystems for a very
> long time. On XFS, you'll get them by default - and quickly, not after
> extended use - on a filesystem of sufficient size (around 1T-2T by
> default, if I remember right.)
>
> XFS does have a hack^Wmount option to force inodes into the 32-bit
> range, but just FWIW we almost never see users running into problems
> with 32-bit applications (but maybe because they know about the mount
> option...)

But that still raises the question - why does it look like this
started to happen pretty suddenly around June 30?
The list of updates that were applied to builders in that timeframe
doesn't raise any alarm bells (except maybe the 6.3 kernel):
(see https://pagure.io/releng/issue/11531#comment-864471)
I read the release notes for the 6.3 kernel but didn't see any
mentions of BTRFS changes that could explain this. :(

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

Re: btrfs loses 32-bit application compatibility after a while

[Demi Marie Obenour]

On 7/14/23 17:32, Chris Adams wrote:
> Once upon a time, Eric Sandeen  said:
>> XFS does have a hack^Wmount option to force inodes into the 32-bit
>> range, but just FWIW we almost never see users running into problems
>> with 32-bit applications (but maybe because they know about the
>> mount option...)
> 
> Aren't even most 32-bit applications compiled with LFS?  It looks like
> anything with _GNU_SOURCE will get it, and IIRC that's not uncommon.
> I'm curious how many 32-bit binaries are looking at inode numbers and
> are NOT already LFS compatible.

I recommending that the entire distro be compiled with LFS.
The non-LFS ABI is obsolete for exactly this reason.
-- 
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: btrfs loses 32-bit application compatibility after a while

[Chris Adams]

Once upon a time, Eric Sandeen  said:
> XFS does have a hack^Wmount option to force inodes into the 32-bit
> range, but just FWIW we almost never see users running into problems
> with 32-bit applications (but maybe because they know about the
> mount option...)

Aren't even most 32-bit applications compiled with LFS?  It looks like
anything with _GNU_SOURCE will get it, and IIRC that's not uncommon.
I'm curious how many 32-bit binaries are looking at inode numbers and
are NOT already LFS compatible.

-- 
Chris Adams 
___
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: blocked for tag f39-updates-candidate

[Jeremy Newton]

Ah thanks so much! This is my first time unretiring something :)
___
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 2223015] perl-SNMP-Info-3.93 is available

[bugzilla]

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



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202223015%23c2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2223015] perl-SNMP-Info-3.93 is available

[bugzilla]

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



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202223015%23c1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2223015] New: perl-SNMP-Info-3.93 is available

[bugzilla]

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

Bug ID: 2223015
   Summary: perl-SNMP-Info-3.93 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-SNMP-Info
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org,
w...@gouldfamily.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 3.93
Upstream release that is considered latest: 3.93
Current version/release in rawhide: 3.92-1.fc39
URL: http://search.cpan.org/dist/SNMP-Info/

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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202223015%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: btrfs loses 32-bit application compatibility after a while

[Eric Sandeen]

On 7/14/23 6:53 AM, Florian Weimer wrote:

* Neal Gompa:


On Thu, Jul 13, 2023 at 8:29 AM Fabio Valentini  wrote:


On Thu, Jul 13, 2023 at 10:33 AM Florian Weimer  wrote:


Fedora lists are hostile to upstream collaboration via cross-posting, so
I can only forward this for your information.

This causes problems with the i686 builders.


I wonder how this only started to happen recently? Has something
changed in BTRFS with the 6.3 kernel?
This only started happening a few days after builders were rebooted at
the end of June to apply updates (and kernel 6.3 was among those
updates, as far as I can tell).



This was always possible. I'm curious as to why it took so long for us
to hit it, though.

The recommended solution is to create a new subvolume for these
environments, since the inode count is reset for each subvolume.


What about impact beyond the builders?

Are end users are expected to do this?  Do we have a tool for this?


FWIW, 64 bit inodes have existed in some Linux filesystems for a very 
long time. On XFS, you'll get them by default - and quickly, not after 
extended use - on a filesystem of sufficient size (around 1T-2T by 
default, if I remember right.)


XFS does have a hack^Wmount option to force inodes into the 32-bit 
range, but just FWIW we almost never see users running into problems 
with 32-bit applications (but maybe because they know about the mount 
option...)


-Eric
___
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: btrfs loses 32-bit application compatibility after a while

[Kevin Fenzi]

On Fri, Jul 14, 2023 at 09:28:15AM -0700, Kevin Fenzi wrote:
...snip...
> 
> * Today / soon, I will just reinstall all the buildvm-x86 vm's.
> Thats pretty trivial to do (thanks ansible). It may cause some builds to
> restart as I move things around, but it shouldn't be too much.

ok, this is done. All the buildvm-x86* build vm's (all 32 of them)
are reinstalled. 

Please let me know if you see this i686 build failure, and what exact
machine you see it on. 

Thanks,

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: Ownership of NVML

[Emanuel Lima]

It's indirect. Qemu depends on nvml and then kata-containers depends on
qemu.

On Fri, Jul 14, 2023 at 11:26 AM Jeff Moyer  wrote:

> Hi, Emanuel,
>
> Emanuel Lima  writes:
>
> > I would like to take ownership of the nvml package, which was recently
> > orphaned, because kata-containers depends on it.
>
> Out of curiosity, what depends on nvml?  The kata-containers packages
> does not appear to.  I saw reference to nvml in the
> configure-hypervisor.sh script, but I didn't see a hard requirement.
>
> Thanks!
> Jeff
>
>

-- 

Kind Regards,

Emanuel Lima

Software Engineer, Virtualization CI
___
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: btrfs loses 32-bit application compatibility after a while

[Kevin Fenzi]

On Fri, Jul 14, 2023 at 10:28:36AM -0400, Neal Gompa wrote:
> >
> > The 32-bit binary is what suffers the consequences.
> >
> > The workload that /causes/ the problem can be anything which creates
> > lots of files.
> >
> 
> I am aware of that, but having something concretely easily
> reproducible that appears realistic makes it a lot easier for me to
> talk to them about doing something to address it. Otherwise it's all
> just hypothetical and the conversation gets difficult.

A busy mail server using postfix and creating / deleting tons of queue
files as it processes? I guess it's really hard to come up with another
case without specific usage patterns (ie, deleting a ton of files and
recreating them over and over, some websites might do this?)

Anyhow, How about this: 

* Today / soon, I will just reinstall all the buildvm-x86 vm's.
Thats pretty trivial to do (thanks ansible). It may cause some builds to
restart as I move things around, but it shouldn't be too much.

* If the problem seems to go away, then great and we can work on a
longer term solution, which could be some btrfs changes, switching
filesystems, dropping i686, etc. ;) 

* If the problems persist, I can just reinstall again with xfs and the
inode32 mount flag.

* If that doesn't fix it, we may need to delay the mass rebuild and sort
out another fix.

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: Ownership of NVML

[Jeff Moyer]

Hi, Emanuel,

Emanuel Lima  writes:

> I would like to take ownership of the nvml package, which was recently
> orphaned, because kata-containers depends on it.

Out of curiosity, what depends on nvml?  The kata-containers packages
does not appear to.  I saw reference to nvml in the
configure-hypervisor.sh script, but I didn't see a hard requirement.

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

Re: List of long term FTBFS packages to be retired in August

[Mikel Olasagasti]

Hau idatzi du Fabio Valentini (decatho...@gmail.com) erabiltzaileak
(2023 uzt. 13(a), og. (14:27)):
>
> On Wed, Jul 12, 2023 at 1:01 PM Mikel Olasagasti  
> wrote:
> >
> > Hau idatzi du Fabio Valentini (decatho...@gmail.com) erabiltzaileak
> > (2023 uzt. 12(a), az. (11:53)):
> > >
> > > On Tue, Jul 11, 2023 at 10:06 PM Mikel Olasagasti  
> > > wrote:
> > > >
> > >
> > > (snip)
> > >
> > > >
> > > > > golang-github-moby-spdystreamgo-sig, mikelo2
> > > >
> > > > Builds fine in Koschei and no BZ
> > > >
> > > > > golang-github-openapi-validate   alexsaezm, go-sig
> > > >
> > > > Builds fine in Koschei and no BZ
> > >
> > > This is usually an indication that the package fails to even produce a
> > > valid SRPM file (i.e. "fedpkg srpm" fails).
> > > In this case, mass rebuild will skip it, no FTBFS bug will be filed,
> > > and koschei will keep using the last "known good" SRPM from koji.
> >
> > Both packages work for me. I'm doing the following:
> >
> > $ fedpkg clone golang-github-moby-spdystream
> > $ cd golang-github-moby-spdystream
> > $ fedpkg srpm
> > $ mock -r fedora-rawhide-x86_64
> > /tmp/golang-github-openapi-validate/golang-github-openapi-validate-0.20.1-5.fc39.src.rpm
>
> If that is indeed the case, then the missing f38 build was likely
> caused by a hiccup during the f38 mass rebuild.
> To get the package off the "long term FTBFS retirements" list, all
> that would be needed is to run "fedpkg build".

Thanks, Fabio. I realized that packages were not built for rawhide,
f38 and f37. I built the packages for rawhide and f38, I hope it's
enough to be out of the list.

Regards,
Mikel
___
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: non-responsive maintainer check for anthr76

[Mikel Olasagasti]

Hi Mark,

Anthony announced a hiatus a couple of months ago:

https://lists.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/5NUXD4CESPDXKV6NQL2QDQAZP4BTQF2I/

As go-sig has permissions I guess you can continue updating the
package once unretired.

Regards,
Mikel

Hau idatzi du Mark E. Fuller (mark.e.ful...@gmx.de) erabiltzaileak
(2023 uzt. 14(a), or. (18:03)):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=964
>
> This email is part of the non-responsive maintainer procedure for
> anthr76, following
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/.
>
> Please respond if you are still active in Fedora and want to maintain
> golang-github-google-renameio-2.
>
> Please see the request for unretirement at
> https://bugzilla.redhat.com/show_bug.cgi?id=2219084
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Elliot

[stan via devel]

On Fri, 14 Jul 2023 14:20:28 -
"Elliot L"  wrote:

> Hi, my name is Elliot and I am a digital humanities student. In the
> open source world, I've made some small contributions to desktops
> such as Budgie and Xfce and I hope to do more work in this area. I
> also know basic RPM packaging and I would like to contribute to
> Fedora in the packaging field.
> 
> Since I am a new user, I don't have a sponsor and I am not in the
> packager broup. Looking at some of the orphaned packages, I know one
> I would like to try to maintain would be the
> rhythmbox-alternative-toolbar plugin. Should I post this in a
> separate thread?
> 
> Please let me know if there is any other information I should
> provide, thanks!

Welcome to Fedora.  I'm not a packager, but these are some links to
official information on how to become a Fedora packager.

https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/
___
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

non-responsive maintainer check for anthr76

[Mark E. Fuller]

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

This email is part of the non-responsive maintainer procedure for 
anthr76, following 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/.


Please respond if you are still active in Fedora and want to maintain 
golang-github-google-renameio-2.


Please see the request for unretirement at 
https://bugzilla.redhat.com/show_bug.cgi?id=2219084




OpenPGP_0xD599E76CFFCABF60.asc
Description: OpenPGP public key


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 2222961] New: perl-Math-BigInt-1.999839 is available

[bugzilla]

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

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



Releases retrieved: 1.999839
Upstream release that is considered latest: 1.999839
Current version/release in rawhide: 1.9998.38-3.fc39
URL: https://metacpan.org/dist/Math-BigInt/

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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20961%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Ownership of NVML

[Emanuel Lima]

I would like to take ownership of the nvml package, which was recently
orphaned, because kata-containers depends on it.

-- 

Kind Regards,

Emanuel Lima

Software Engineer, Virtualization CI
___
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

Orphaned Zim

[Robin Lee]

I've orphaned the Zim package. It fails to build with Python 3.12 in Rawhide.

Users can move to the flatpak on Flathub, which is also packaged by me.

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

Ownership of Go packages

[W. Michael Petullo]

I would like to take ownership of the following Go packages, which 
releng recently orphaned:


golang-github-bep-godartsass
golang-github-disintegration-gift
golang-github-evanw-esbuild
golang-github-evanw-esbuild-0.8.20
golang-github-getkin-kin-openapi
golang-github-rwcarlsen-goexif
golang-gocloud
golang-github-azure-amqp-common
golang-github-azure-service-bus
golang-github-devigned-tab
golang-github-shogo82148-shuffle
golang-gopkg-neurosnap-sentences-1
golang-gopkg-pipe-2
golang-nhooyr-websocket

I am interested in these packages because my Hugo package depends on 
them.


--
Mike

:wq

___
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: btrfs loses 32-bit application compatibility after a while

[Neal Gompa]

On Fri, Jul 14, 2023 at 9:58 AM Daniel P. Berrangé  wrote:
>
> On Fri, Jul 14, 2023 at 09:49:04AM -0400, Neal Gompa wrote:
> > On Fri, Jul 14, 2023 at 8:48 AM Florian Weimer  wrote:
> > >
> > > * Miroslav Suchý:
> > >
> > > > Dne 14. 07. 23 v 13:53 Florian Weimer napsal(a):
> > > >> What about impact beyond the builders?
> > > >>
> > > >> Are end users are expected to do this?  Do we have a tool for this?
> > > >
> > > > Close to zero. You have to do a really lots of builds. And keep the
> > > > buildroots of these (failed) builds.
> > >
> > > This is not restricted to mock or Koji, though.  There just needs to be
> > > one application that creates and deletes many files (or produces other
> > > events that causes object ID allocation in btrfs).
> > >
> > > For me it's going to be slow enough that the file system will likely be
> > > recreated before I encounter the 31-bit object ID limit.  But I wonder
> > > if that's true for everyone.
> > >
> >
> > I don't know of a 32-bit workload that would trigger this reliably and
> > reasonably quickly, but if there is one, then I would be interested in
> > knowing about it.
>
> The 32-bit binary is what suffers the consequences.
>
> The workload that /causes/ the problem can be anything which creates
> lots of files.
>

I am aware of that, but having something concretely easily
reproducible that appears realistic makes it a lot easier for me to
talk to them about doing something to address it. Otherwise it's all
just hypothetical and the conversation gets difficult.



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

Self Introduction: Elliot

[Elliot L]

Hi, my name is Elliot and I am a digital humanities student. In the open source 
world, I've made some small contributions to desktops such as Budgie and Xfce 
and I hope to do more work in this area. I also know basic RPM packaging and I 
would like to contribute to Fedora in the packaging field.

Since I am a new user, I don't have a sponsor and I am not in the packager 
broup. Looking at some of the orphaned packages, I know one I would like to try 
to maintain would be the rhythmbox-alternative-toolbar plugin. Should I post 
this in a separate thread?

Please let me know if there is any other information I should provide, thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Carlos Rodriguez-Fernandez]

On 7/14/23 00:02, Vitaly Zaitsev via devel wrote:

On 14/07/2023 08:16, Carlos Rodriguez-Fernandez wrote:
After much discussion, the AlmaLinux OS Foundation board today has 
decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead 
aim to be Application Binary Interface (ABI) compatible*


Imagine Red Hat shutting down CentOS Stream in a year or two just 
because they [Alma, etc.] started doing rebuilds. :-D



That would be epic, LOL.


OpenPGP_0x47EBED05C3375B1F.asc
Description: OpenPGP public key


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

Re: btrfs loses 32-bit application compatibility after a while

[Daniel P . Berrangé]

On Fri, Jul 14, 2023 at 09:49:04AM -0400, Neal Gompa wrote:
> On Fri, Jul 14, 2023 at 8:48 AM Florian Weimer  wrote:
> >
> > * Miroslav Suchý:
> >
> > > Dne 14. 07. 23 v 13:53 Florian Weimer napsal(a):
> > >> What about impact beyond the builders?
> > >>
> > >> Are end users are expected to do this?  Do we have a tool for this?
> > >
> > > Close to zero. You have to do a really lots of builds. And keep the
> > > buildroots of these (failed) builds.
> >
> > This is not restricted to mock or Koji, though.  There just needs to be
> > one application that creates and deletes many files (or produces other
> > events that causes object ID allocation in btrfs).
> >
> > For me it's going to be slow enough that the file system will likely be
> > recreated before I encounter the 31-bit object ID limit.  But I wonder
> > if that's true for everyone.
> >
> 
> I don't know of a 32-bit workload that would trigger this reliably and
> reasonably quickly, but if there is one, then I would be interested in
> knowing about it.

The 32-bit binary is what suffers the consequences.

The workload that /causes/ the problem can be anything which creates
lots of files.

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

Re: btrfs loses 32-bit application compatibility after a while

[Neal Gompa]

On Fri, Jul 14, 2023 at 8:48 AM Florian Weimer  wrote:
>
> * Miroslav Suchý:
>
> > Dne 14. 07. 23 v 13:53 Florian Weimer napsal(a):
> >> What about impact beyond the builders?
> >>
> >> Are end users are expected to do this?  Do we have a tool for this?
> >
> > Close to zero. You have to do a really lots of builds. And keep the
> > buildroots of these (failed) builds.
>
> This is not restricted to mock or Koji, though.  There just needs to be
> one application that creates and deletes many files (or produces other
> events that causes object ID allocation in btrfs).
>
> For me it's going to be slow enough that the file system will likely be
> recreated before I encounter the 31-bit object ID limit.  But I wonder
> if that's true for everyone.
>

I don't know of a 32-bit workload that would trigger this reliably and
reasonably quickly, but if there is one, then I would be interested in
knowing about it.

We used to have something in Btrfs to mitigate this called
inode_cache, but it was turned into a no-op in 5.11 and the
documentation was removed in 5.12:
https://github.com/kdave/btrfs-progs/commit/1af37385e258aabc684484aff8e5def442ada9bb

If we have a workload example that subvolumes don't work for, then I'm
happy to advocate upstream to do something to address the problem more
directly.





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

[Bug 2222007] perl-HTTP-Tiny-0.088 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|MODIFIED|CLOSED
   Fixed In Version||perl-HTTP-Tiny-0.088-1.fc39
Last Closed||2023-07-14 13:45:55



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-1e28c43c8d has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20007%23c2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2222144] perl-Test-Compile-3.3.0 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Test-Compile-3.3.0-2.f
   ||c39
 Resolution|--- |ERRATA
 Status|MODIFIED|CLOSED
Last Closed||2023-07-14 12:51:55



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20144%23c2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: btrfs loses 32-bit application compatibility after a while

[Florian Weimer]

* Miroslav Suchý:

> Dne 14. 07. 23 v 13:53 Florian Weimer napsal(a):
>> What about impact beyond the builders?
>>
>> Are end users are expected to do this?  Do we have a tool for this?
>
> Close to zero. You have to do a really lots of builds. And keep the
> buildroots of these (failed) builds.

This is not restricted to mock or Koji, though.  There just needs to be
one application that creates and deletes many files (or produces other
events that causes object ID allocation in btrfs).

For me it's going to be slow enough that the file system will likely be
recreated before I encounter the 31-bit object ID limit.  But I wonder
if that's true for everyone.

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

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Richard W.M. Jones]

I've been actually using dnf5 daily and while it's a little rough
around the edges it seems usable enough.

Here are some notes ...

(1) The allow_vendor_change option makes things strange.  I think this
feature should be turned off (ie True) until it is fixed properly.

https://github.com/rpm-software-management/dnf5/issues/722

Also dnf downgrade seems broken, probably related to this.

(2) Current bugs that stop fedora-review or mock from working:

https://bugzilla.redhat.com/show_bug.cgi?id=2217496
https://bugzilla.redhat.com/show_bug.cgi?id=2217496#c5

(3) [superficial] I don't like the update summary that it prints as
much as the old dnf one.  The dnf5 one lacks "==" to delineate the
headers from the list.

Also the actual transaction lines are clipped so you cannot see the
full versions, eg:

[ 3/20] Upgrading nbdkit-server-0:1.35. 100% |   6.8 MiB/s | 228.4 KiB |  00m00s
[ 4/20] Upgrading nbdkit-basic-filters- 100% |  31.2 MiB/s | 831.8 KiB |  00m00s
[ 5/20] Upgrading nbdkit-basic-plugins- 100% |  32.5 MiB/s | 532.1 KiB |  00m00s
...
[12/20] Erasing nbdkit-0:1.34.1-1.fc38. 100% |  16.3 KiB/s | 100.0   B |  00m00s
[13/20] Erasing nbdkit-basic-filters-0: 100% |  14.2 KiB/s | 145.0   B |  00m00s
[14/20] Erasing nbdkit-basic-plugins-0: 100% |   8.9 KiB/s |  64.0   B |  00m00s

(4) It's a lot faster, great!

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

Possible to combine ExclusiveArch?

[Richard W.M. Jones]

For some virt packages we need to combine 2 or 3 of:

  ExclusiveArch: %{kernel_arches}
  ExclusiveArch: %{qemu_sysemu_host_arches}   # [1]
  ExclusiveArch: %{ocaml_native_compiler}

to mean only compile on the intersection of these arches.  If you have
multiple ExclusiveArch lines then RPM seems to do the union of arches
which is the opposite of what anyone would want.

Dan Berrange came up with a clever way to do it though ...

  %ifnarch %{kernel_arches}
  ExcludeArch: %{_arch}
  %endif
  %ifnarch %{qemu_sysemu_host_arches}
  ExcludeArch: %{_arch}
  %endif

But this makes my head hurt.  Is there a better way or could RPM
provide explicit union and intersection operators?

Rich.

[1] https://src.fedoraproject.org/rpms/qemu/pull-request/43

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Miroslav Suchý]

Dne 14. 07. 23 v 2:11 Kevin Fenzi napsal(a):

On Fri, Jul 14, 2023 at 12:26:27AM +0200, Miroslav Suchý wrote:

Dne 13. 07. 23 v 23:59 Fabio Valentini napsal(a):

- rawhide mock / koji builds still default to dnf-3 (DNF 4)

Support for DNF5 landed in Mock

https://rpm-software-management.github.io/mock/Release-Notes-4.0

In the meantime 4.1 was released.

I hope that in week or two we release 4.2 and we can set

config_opts['package_manager'] = 'dnf5'

for fedora-rawhide config. I have just created
https://github.com/rpm-software-management/mock/issues/1147

Of course, Koji admins can do that independently in their configs.

Sure, but... our builders are Fedora 38.
Is the dnf5 in f38 expected to be ready to do bootstrap chroots?
Or only the rawhide one?


Hmm,

F39 has dnf5-5.0.15-4.fc39 


F38 has dnf5-5.0.13-2.fc38 


and there are some important changes (like module enable or forcearch) but not sure if Koji will need this. Mock uses it 
in some scenarions.


Miroslav

--

Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
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 2222144] perl-Test-Compile-3.3.0 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20144%23c1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: btrfs loses 32-bit application compatibility after a while

[Miroslav Suchý]

Dne 14. 07. 23 v 13:53 Florian Weimer napsal(a):

What about impact beyond the builders?

Are end users are expected to do this?  Do we have a tool for this?


Close to zero. You have to do a really lots of builds. And keep the buildroots 
of these (failed) builds.

For normal users the buildroots are reused. No chance to have so many inodes.

Copr terminate builders and spin up new one. And when build finish Copr retrieve only interresting artifacts. So it is 
no issue there.


So it is only Koji.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
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 2222007] perl-HTTP-Tiny-0.088 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20007%23c1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: btrfs loses 32-bit application compatibility after a while

[Florian Weimer]

* Neal Gompa:

> On Thu, Jul 13, 2023 at 8:29 AM Fabio Valentini  wrote:
>>
>> On Thu, Jul 13, 2023 at 10:33 AM Florian Weimer  wrote:
>> >
>> > Fedora lists are hostile to upstream collaboration via cross-posting, so
>> > I can only forward this for your information.
>> >
>> > This causes problems with the i686 builders.
>>
>> I wonder how this only started to happen recently? Has something
>> changed in BTRFS with the 6.3 kernel?
>> This only started happening a few days after builders were rebooted at
>> the end of June to apply updates (and kernel 6.3 was among those
>> updates, as far as I can tell).
>>
>
> This was always possible. I'm curious as to why it took so long for us
> to hit it, though.
>
> The recommended solution is to create a new subvolume for these
> environments, since the inode count is reset for each subvolume.

What about impact beyond the builders?

Are end users are expected to do this?  Do we have a tool for this?

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

[Bug 2219879] perl-Module-ScanDeps-1.32 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-Module-ScanDeps-1.32-1
   ||.fc39
Last Closed||2023-07-14 11:51:55



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202219879%23c2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Eike Rathke]

Hi Frantisek,

On Friday, 2023-07-14 09:22:06 +0200, Frantisek Zatloukal wrote:

> The side tag has been merged:
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c

Thank you very much for taking care of this!

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A


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

Orphaned python-blockdiag et al

[Dridi Boukelmoune]

Greetings,

Since Pillow 10 landed in f39 the following packages are FTBFS:

https://src.fedoraproject.org/rpms/python-blockdiag
https://src.fedoraproject.org/rpms/python-actdiag
https://src.fedoraproject.org/rpms/python-nwdiag
https://src.fedoraproject.org/rpms/python-seqdiag

Ever since the 3.0.0 release there has been zero activity on the
project and I don't have time nor interest to keep it on life support.

The following packages depend on them:

python-zuul-client.src
python3-sphinxcontrib-actdiag.
noarch
python3-sphinxcontrib-blockdiag.noarch
python3-sphinxcontrib-seqdiag.noarch

The only reason why I am also the maintainer of python-webcolors and
python-funcparserlib was blockdiag et al but since they require low
activity I will keep maintaining them for now.

Dridi
___
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 2219879] perl-Module-ScanDeps-1.32 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202219879%23c1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2219870] perl-Test-Output-1.034 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-Test-Output-1.03.4-1.f
   ||c39
 Status|MODIFIED|CLOSED
Last Closed||2023-07-14 09:42:55



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202219870%23c2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20230714.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230713.n.1
NEW: Fedora-Rawhide-20230714.n.0

= SUMMARY =
Added images:12
Dropped images:  3
Added packages:  7
Dropped packages:0
Upgraded packages:   165
Downgraded packages: 1

Size of added packages:  2.93 MiB
Size of dropped packages:0 B
Size of upgraded packages:   12.78 GiB
Size of downgraded packages: 2.25 MiB

Size change of upgraded packages:   27.50 MiB
Size change of downgraded packages: -13.59 KiB

= ADDED IMAGES =
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20230714.n.0.iso
Image: Container_Toolbox docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Toolbox-Rawhide-20230714.n.0.aarch64.tar.xz
Image: Container_Toolbox docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Toolbox-Rawhide-20230714.n.0.x86_64.tar.xz
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20230714.n.0.aarch64.raw.xz
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20230714.n.0.iso
Image: Container_Toolbox docker s390x
Path: 
Container/s390x/images/Fedora-Container-Toolbox-Rawhide-20230714.n.0.s390x.tar.xz
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20230714.n.0.aarch64.raw.xz
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20230714.n.0.iso
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20230714.n.0.iso
Image: Container_Toolbox docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Toolbox-Rawhide-20230714.n.0.ppc64le.tar.xz
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20230714.n.0.iso
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20230714.n.0.iso

= DROPPED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230713.n.1.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20230713.n.1.iso
Image: Container_Minimal_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20230713.n.1.x86_64.tar.xz

= ADDED PACKAGES =
Package: apache-commons-vfs-2.9.0-1.fc39
Summary: Commons Virtual File System
RPMs:apache-commons-vfs apache-commons-vfs-ant apache-commons-vfs-examples 
apache-commons-vfs-javadoc apache-commons-vfs-project
Size:1.15 MiB

Package: hipcub-5.6.0-2.fc39
Summary: ROCm port of CUDA CUB library
RPMs:hipcub-devel
Size:110.93 KiB

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

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

Package: rust-libssh2-sys0.2-0.2.23-1.fc39
Summary: Native bindings to the libssh2 library
RPMs:rust-libssh2-sys0.2+default-devel rust-libssh2-sys0.2-devel
Size:27.33 KiB

Package: rust-miniz_oxide0.6-0.6.2-1.fc39
Summary: DEFLATE compression and decompression library rewritten in Rust based 
on miniz
RPMs:rust-miniz_oxide0.6+default-devel rust-miniz_oxide0.6+std-devel 
rust-miniz_oxide0.6+with-alloc-devel rust-miniz_oxide0.6-devel
Size:77.84 KiB

Package: smf-spf-2.5.1^20220423g061e937-1.fc39
Summary: Mail filter for Sender Policy Framework verification
RPMs:smf-spf
Size:152.29 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  389-ds-base-2.4.2-3.fc39
Old package:  389-ds-base-2.4.2-2.fc39
Summary:  389 Directory Server (base)
RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-libs 389-ds-base-snmp 
cockpit-389-ds python3-lib389
Size: 21.37 MiB
Size change:  328 B
Changelog:
  * Tue Jul 11 2023 Franti??ek Zatloukal  - 2.4.2-3
  - Rebuilt for ICU 73.2


Package:  R-4.3.1-2.fc39
Old package:  R-4.3.1-1.fc39
Summary:  A language for data analysis and graphics
RPMs: R R-core R-core-devel R-devel R-java R-java-devel libRmath 
libRmath-devel libRmath-static
Size: 320.21 MiB
Size change:  -62.06 KiB
Changelog:
  * Tue Jul 11 2023 Franti??ek Zatloukal  - 4.3.1-2
  - Rebuilt for ICU 73.2


Package:  R-Cairo-1.6.0-5.fc39
Old package:  R-Cairo-1.6.0-4.fc39
Summary:  Use Cairo for high-quality bitmap, vector, and display output
RPMs

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Vít Ondruch]

Since DNF5 was forced upon me as a Rawhide user, I'd prefer to keep it 
this way and actually rename DNF5 back to DNF to have e.g. man pages 
correctly available.



Vít


Dne 13. 07. 23 v 23:59 Fabio Valentini napsal(a):

Hi all,

I'm opening this thread to trigger discussion of the roadmap for DNF5
in Fedora 39 - whether the switch still looks doable for this release,
or whether it should be reverted for F39 and postponed to F40.

This is also being tracked in a FESCo ticket:
https://pagure.io/fesco/issue/3039

The DNF5 Change was approved with the condition that bits that are
important to the distribution *MUST* work, but this does not seem to
be the case yet, six months after this was initially approved -
there's at least a few things that are still using dnf-3 or have been
broken since the switch to dnf5:

- rawhide mock / koji builds still default to dnf-3 (DNF 4)
- Fedora CI has been partially broken since the switch to DNF5 (c.f.
[fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
making CI results for bodhi updates at least partially useless
- fedora-review has been broken since the switch to DNF5 (c.f.
[FedoraReview#482](FedoraReview/issue/482)), which is really hurting
the rate at which new packages are getting reviewed and added to
Fedora
- (not an exhaustive list, feel free to mention other things, I will
update the list to include them)

We are now mere days before the Fedora 39 mass rebuild is scheduled to
start, so I think it's time to start talking about the roadmap for
getting missing pieces into place for Fedora 39, or if that is not
possible within this timeframe, whether the contingency mechanism
should be enacted.

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


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 2219870] perl-Test-Output-1.034 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202219870%23c1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Test-Output] PR #1: 1.034 bump; Package tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Test-Output` that you 
are following.

Merged pull-request:

``
1.034 bump; Package tests
``

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

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Pavel Březina]

On 7/13/23 23:59, Fabio Valentini wrote:

Hi all,

I'm opening this thread to trigger discussion of the roadmap for DNF5
in Fedora 39 - whether the switch still looks doable for this release,
or whether it should be reverted for F39 and postponed to F40.


+1 for postponing. We have hit issues preparing CI environment via 
ansible and applying workarounds to make dnf5 work is imho not the way 
to go with such core tool. It should be there as opt-in so it can get 
tested but not default.



This is also being tracked in a FESCo ticket:
https://pagure.io/fesco/issue/3039

The DNF5 Change was approved with the condition that bits that are
important to the distribution *MUST* work, but this does not seem to
be the case yet, six months after this was initially approved -
there's at least a few things that are still using dnf-3 or have been
broken since the switch to dnf5:

- rawhide mock / koji builds still default to dnf-3 (DNF 4)
- Fedora CI has been partially broken since the switch to DNF5 (c.f.
[fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
making CI results for bodhi updates at least partially useless
- fedora-review has been broken since the switch to DNF5 (c.f.
[FedoraReview#482](FedoraReview/issue/482)), which is really hurting
the rate at which new packages are getting reviewed and added to
Fedora
- (not an exhaustive list, feel free to mention other things, I will
update the list to include them)

We are now mere days before the Fedora 39 mass rebuild is scheduled to
start, so I think it's time to start talking about the roadmap for
getting missing pieces into place for Fedora 39, or if that is not
possible within this timeframe, whether the contingency mechanism
should be enacted.

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

___
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: Several questionable packages installed on fresh system

[Vít Ondruch]

(adding the list back on CC, since it seems this went private just by 
mistake)


You know, my initial email listed 4 packages and removal of them might 
result in saving of tens of MBs. They are small on itself but they pull 
in much bigger dependency chains. And that typically happens just by 
evolution.


Maybe exiv2 really isn't the biggest package ATM, but who knows what 
dependency it will grow in a year. Or maybe it won't. I don't know.


I cannot ignore this on principle.


Vít


Dne 13. 07. 23 v 20:59 Rex Dieter napsal(a):
I'm surprised you'd consider this for such a small space savings (< 
200k).  I figured it a better use of everyone's time to focus on 
bigger things.


Technically, the translations are packaged in the wrong place. I 
hadn't considered that to be much of a problem since the soft 
dependency defaulted to getting them installed.
If you're planning on breaking that presumption, so that translations 
wouldn't get installed, then I'll probably have to do something about it.


On Thu, Jul 13, 2023 at 12:00 PM Vít Ondruch  wrote:

Yes, we would have the same conversation.

And generally, what you said about the translations does not make
sense to me. Are they in the right package or not?

IOW the only way we would not have this conversation is if there
was not the split between the -libs and executable. It does not
seems to me that you are favor in this split yet we have it but
don't benefit from it.


Vít


Dne 13. 07. 23 v 17:51 Rex Dieter napsal(a):

Seems like you may have not considered the translations angle, so
let me spin it another way...

If I adjusted where translations are packaged (put with -libs),
so that the base 'exiv2' package was < 1mb (~200k uncompressed),
would we still be having this conversation?

On Thu, Jul 13, 2023 at 10:10 AM Vít Ondruch
 wrote:

1) I am sure I never had any need to use the exiv2 executable
and I would be surprised if majority of Fedora users had
different experience

2) I don't understand what else then space saving and e.g.
optimization of install media should be the reason for the split.

But given that the split as well as the recommends are
correct, then I'll probably ask to remove the `exiv2` from
the install media via kickstart or whatever is the right way
to customize the install media content.


Vít


Dne 13. 07. 23 v 15:45 Rex Dieter napsal(a):

I don't see any good reason to change here.  Mostly because
the status quo is already a compromise to leave the base
package as an optional Recommends (ie, removable).

This is considering that most of the space in question here
are translations, that strictly-speaking, probably ought to
be included in the -libs package anyway.  if those files
were moved, the space saving for the base package would be
negligible.

On Thu, Jul 13, 2023 at 7:42 AM Vít Ondruch
 wrote:

(now hopefully with correct maintainer email)


Dne 13. 07. 23 v 14:38 Vít Ondruch napsal(a):
>
> Dne 10. 07. 23 v 10:38 Vít Ondruch napsal(a):
>>
>> exiv2
>>
>>
>
> So this is pulled in by exiv2-libs:
>
>

https://src.fedoraproject.org/rpms/exiv2/blob/rawhide/f/exiv2.spec#_53-58
>
> I am not sure I agree with the comment `# not strictly
required, but
> convenient and expected`. But I think dependencies
like this should be
> reevaluated at least in the install media context.
This would save 4+
> MB of space.
>
> Or is the exiv2 maintainer (in CC) going to revisit
this dependency?
>
>
> 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

[rpms/perl-Test-Output] PR #1: 1.034 bump; Package tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Test-Output` that 
you are following:
``
1.034 bump; Package tests
``

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

[Bug 2222866] New: perl-Business-ISBN-Data-20230714.001 is available

[bugzilla]

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

Bug ID: 866
   Summary: perl-Business-ISBN-Data-20230714.001 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Business-ISBN-Data
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 20230714.001
Upstream release that is considered latest: 20230714.001
Current version/release in rawhide: 20230707.001-1.fc39
URL: https://metacpan.org/dist/Business-ISBN-Data/

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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20866%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rawhide] ICU upgrade to 73.2

[Frantisek Zatloukal]

The side tag has been merged:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c


-- 

Best regards / S pozdravem,

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

[Bug 2222854] New: perl-Test-Valgrind-1.19-22.fc39 FTBFS with perl 5.38.0: t/20-bad.t fails

[bugzilla]

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

Bug ID: 854
   Summary: perl-Test-Valgrind-1.19-22.fc39 FTBFS with perl
5.38.0: t/20-bad.t fails
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-Test-Va
lgrind
Status: NEW
 Component: perl-Test-Valgrind
  Assignee: p...@city-fan.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org
Blocks: 2168842 (F39FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-Test-Valgrind-1.19-22.fc39 fails to build because a test fails with perl
5.38.0:

t/00-load.t ... ok
# Using valgrind 3.21.0 located at /usr/bin/valgrind
# Generating suppressions...
# Suppressions for this perl stored in
/builddir/.perl/Test-Valgrind/suppressions/1.19/memcheck-3.21.0-89544340d2cf0ab61f972f6ffa315e7d.supp
# Using suppressions from
/builddir/.perl/Test-Valgrind/suppressions/1.19/memcheck-3.21.0-89544340d2cf0ab61f972f6ffa315e7d.supp
# 1..1
# not ok 1 - dummy test in the child, should not interfere with the actual TAP
stream
# 
# #   Failed test 'dummy test in the child, should not interfere with the
actual TAP stream'
# #   at t/10-good.t line 30.
# # Looks like you failed 1 test of 1.
t/10-good.t ... ok
# Using valgrind 3.21.0 located at /usr/bin/valgrind
# Using suppressions from
/builddir/.perl/Test-Valgrind/suppressions/1.19/memcheck-3.21.0-89544340d2cf0ab61f972f6ffa315e7d.supp
# dummy run-time exception, should not cause the test to fail at
t/12-good-run-exception.t line 20.
t/12-good-run-exception.t . ok
# Using valgrind 3.21.0 located at /usr/bin/valgrind
# Using suppressions from
/builddir/.perl/Test-Valgrind/suppressions/1.19/memcheck-3.21.0-89544340d2cf0ab61f972f6ffa315e7d.supp
# # leaking some bytes!
#   10,000 bytes in 1 blocks are still reachable in loss record 18 of 18
# malloc (/usr/libexec/valgrind/vgpreload_memcheck-x86-linux.so)
[vg_replace_malloc.c:431]
# tv_leak
(/builddir/build/BUILD/Test-Valgrind-1.19/blib/arch/auto/Test/Valgrind/Valgrind.so)
[Valgrind.xs:34]
# XS_Test__Valgrind_leak
(/builddir/build/BUILD/Test-Valgrind-1.19/blib/arch/auto/Test/Valgrind/Valgrind.so)
[Valgrind.xs:54]
# ? (/usr/lib/libperl.so.5.38.0) [?:?]
# Perl_runops_standard (/usr/lib/libperl.so.5.38.0) [?:?]
# perl_run (/usr/lib/libperl.so.5.38.0) [?:?]
# ? (/usr/bin/perl) [?:?]
# (below main) (/usr/lib/libc.so.6) [?:?]
#   Failed test 'Leak_StillReachable'
#   at
/builddir/build/BUILD/Test-Valgrind-1.19/blib/lib/Test/Valgrind/Session.pm line
598.
#  got: 1
# expected: 0
#   Failed test 'caught one extra leak'
#   at /builddir/build/BUILD/Test-Valgrind-1.19/blib/lib/Test/Valgrind.pm line
307.
#  got: '0'
# expected: '1'
#   Failed test 'no extra leak caught, hence no bytes leaked'
#   at /builddir/build/BUILD/Test-Valgrind-1.19/blib/lib/Test/Valgrind.pm line
307.
#   Failed test 'no extra leak caught, hence no block leaked'
#   at /builddir/build/BUILD/Test-Valgrind-1.19/blib/lib/Test/Valgrind.pm line
307.
# Looks like your test exited with 1 just after 18.
t/20-bad.t  
Dubious, test returned 1 (wstat 256, 0x100)
Failed 4/18 subtests 
# Using IO::Handle 1.52
# Using IO::Select 1.52
# Using IPC::Open3 1.22
t/30-skip.t ... ok
t/60-version.t  ok
t/70-session.t  ok
t/71-session-command.t  ok
# The default suppression file contains 12 suppressions, of which 12 are not
empty and 12 apply to perl
t/80-suppressions.t ... ok
t/81-suppressions-demangle.t .. ok
Test Summary Report
---
t/20-bad.t  (Wstat: 256 (exited 1) Tests: 18 Failed: 4)
  Failed tests:  15-18
  Non-zero exit status: 1
Files=10, Tests=200, 39 wallclock secs ( 0.09 usr  0.02 sys + 37.38 cusr  1.17
csys = 38.66 CPU)
Result: FAIL
Failed 1/10 test programs. 4/200 subtests failed.



Referenced Bugs:

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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%20854%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 

[Bug 2222638] F39FailsToInstall: perl-Tk

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||2168842
   ||(F39FTBFS,RAWHIDEFTBFS)
 CC||ppi...@redhat.com



--- Comment #2 from Petr Pisar  ---
From s390x perl-Tk-804.036-11.fc39 build.log:

# 
# Tk platform:unix
# server info:X11R0 The X.Org Foundation 12014000
# window manager: 
#version: 
# XFT:yes
t/00wmcheck.t  ok
t/adjuster.t . ok
t/after.t  ok
t/async.t  ok
t/autoload.t . ok
#   Failed test 'Creating Balloon widget'
#   at t/balloon.t line 31.
#  got: 'couldn't recognize image data at
/builddir/build/BUILD/Tk-804.036/blib/lib/Tk/Image.pm line 21.
#  at /builddir/build/BUILD/Tk-804.036/blib/lib/Tk/Balloon.pm line 62.
# '
# expected: ''
#   Failed test 'Existance of ballon'
#   at t/balloon.t line 32.
#   Failed test 'Attaching message to Label widget'
#   at t/balloon.t line 36.
#  got: 'Can't call method "attach" on an undefined value at
t/balloon.t line 35.
# '
# expected: ''
#   Failed test 'Attaching statusmsg/baloonmsg to Label widget'
#   at t/balloon.t line 38.
#  got: 'Can't call method "attach" on an undefined value at
t/balloon.t line 37.
# '
# expected: ''
#   Failed test 'Attaching message to Canvas item'
#   at t/balloon.t line 44.
#  got: 'Can't call method "attach" on an undefined value at
t/balloon.t line 43.
# '
# expected: ''
#   Failed test 'Attaching message to scrolled Canvas item'
#   at t/balloon.t line 51.
#  got: 'Can't call method "attach" on an undefined value at
t/balloon.t line 50.
# '
# expected: ''
#   Failed test 'Attaching message to Menu'
#   at t/balloon.t line 64.
#  got: 'Can't call method "attach" on an undefined value at
t/balloon.t line 62.
# '
# expected: ''
#   Failed test 'Set motioncommand option'
#   at t/balloon.t line 67.
#  got: 'Can't call method "configure" on an undefined value at
t/balloon.t line 66.
# '
# expected: ''
#   Failed test 'Reset motioncommand option'
#   at t/balloon.t line 69.
#  got: 'Can't call method "configure" on an undefined value at
t/balloon.t line 68.
# '
# expected: ''
#   Failed test 'Attaching message to Listbox items'
#   at t/balloon.t line 75.
#  got: 'Can't call method "attach" on an undefined value at
t/balloon.t line 74.
# '
# expected: ''
#   Failed test 'Attaching message to scrolled Listbox items'
#   at t/balloon.t line 83.
#  got: 'Can't call method "attach" on an undefined value at
t/balloon.t line 81.
# '
# expected: ''
Can't call method "attach" on an undefined value at t/balloon.t line 93.
# Looks like your test exited with 2 just after 12.
t/balloon.t .. 
Dubious, test returned 2 (wstat 512, 0x200)
Failed 13/14 subtests 
t/bind.t . ok
t/browseentry-grabtest.t . ok
t/browseentry-subclassing.t .. ok
t/browseentry.t .. ok
t/browseentry2.t . ok
t/button-tcl.t ... ok
t/button.t ... ok
t/canvas-grid.t .. ok
t/canvas.t ... ok
couldn't recognize image data at
/builddir/build/BUILD/Tk-804.036/blib/lib/Tk/Image.pm line 21.
 at /builddir/build/BUILD/Tk-804.036/blib/lib/Tk/Balloon.pm line 62.
# Looks like your test exited with 255 before it could output anything.
t/canvas2.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 87/87 subtests 
t/coloreditor.t .. ok
t/create.t ... ok
t/cursor.t ... ok
t/dash.t . ok
t/dialogbox.t  ok
t/dirtree.t .. ok
t/entry.t  ok
XS_Tk__Callback_Call error:Intentional error.
XS_Tk__Callback_Call error:Intentional error.
t/errordialog.t .. ok
t/eventGenerate.t  ok
t/exefiles.t . ok
t/fbox.t . ok
t/fileevent.t  ok
t/fileevent2.t ... ok
t/fileselect.t ... ok
Font Courier -12 still in cache.
t/font.t . ok
t/fork.t . ok
t/geomgr.t ... ok
t/iso8859-1.t  ok
t/itemstyle.t  ok
t/JP.t ... ok
t/KR.t ... ok
t/leak.t . skipped: need Devel::Leak
t/list.t . ok
t/listbox.t .. ok
t/listvar.t .. ok
t/magic.t  ok
t/mega.t . ok
t/msgbox.t ... ok
t/mwm.t .. ok
t/notebook.t . ok
t/objglue.t .. ok
t/optmenu.t .. ok

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Vitaly Zaitsev via devel]

On 14/07/2023 08:16, Carlos Rodriguez-Fernandez wrote:
After much discussion, the AlmaLinux OS Foundation board today has 
decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead 
aim to be Application Binary Interface (ABI) compatible*


Imagine Red Hat shutting down CentOS Stream in a year or two just 
because they [Alma, etc.] started doing rebuilds. :-D


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

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Carlos Rodriguez-Fernandez]

This is actually good news, especially for the CentOS Stream project.

https://almalinux.org/blog/future-of-almalinux/

Quotes:

After much discussion, the AlmaLinux OS Foundation board today has 
decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead 
aim to be Application Binary Interface (ABI) compatible*


We will also start asking anyone who reports bugs in AlmaLinux OS to 
attempt to test and replicate the problem in CentOS Stream as well, so 
we can focus our energy on correcting it in the right place.


While all of these changes open up a lot of opportunities, we want to be 
clear about the fact that we are still dedicated to being good open 
source citizens. We’ll continue to contribute upstream in Fedora and 
CentOS Stream and to the greater Enterprise Linux ecosystem, just as we 
have been doing since our inception, and we invite our community to do 
the same!





On 7/12/23 15:28, Leslie Satenstein via devel wrote:
SUSE has also jumped in to say they will provide an alternative, but 
compatible Linux to RH.




Leslie Satenstein



On Tuesday, July 11, 2023 at 06:49:38 a.m. GMT-4, Kevin Kofler via devel 
 wrote:



Oracle has (finally – the community projects Rocky and Alma were much
quicker to react) made an announcement about the situation:
https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/ 


         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 



___
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_0x47EBED05C3375B1F.asc
Description: OpenPGP public key


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