Re: Updating wcslib in rawhide to 8.2.2 (with sidetag)

[Mattia Verga via devel]

Il 09/01/24 17:20, Sergio Pascual ha scritto:
> Hello, I have created the side tag f40-build-side-81054 to build
> packages depending on wcslib
>
> Build your package with:
> fedpkg build --target=f40-build-side-81054
>
> Affected:
> astrometry
> cpl
> kstars
> python3-astrometry
> python3-astropy
> siril
> sourcextractor++
> stellarsolver
>
> I have already built cpl and I'm building python-astropy now
>
I've rebuilt siril in the side-tag.

Astrometry rebuild failed because it requires python-astropy which is 
currently FTB with wcslib 8.

Mattia

--
___
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 2255608] perl-SQL-Translator-1.64 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-SQL-Translator-1.64-1. |perl-SQL-Translator-1.64-1.
   |fc40|fc40
   ||perl-SQL-Translator-1.64-1.
   ||fc39



--- Comment #5 from Fedora Update System  ---
FEDORA-2024-1af96a979b 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=2255608

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

Re: Heads up: libgweather4 to libgweather rename in rawhide

[Kalev Lember]

Thanks for helping think about this, both of you! Let me try to reply to
both of your emails in the same reply.

On Wed, Jan 10, 2024 at 8:04 PM Stephen Gallagher 
wrote:

> On Wed, Jan 10, 2024 at 1:38 PM Yaakov Selkowitz 
> wrote:
> >
> > On Wed, 2024-01-10 at 19:13 +0100, Kalev Lember wrote:
> > > On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz
> > > 
> > > wrote:
> > >
> > > > Since the previous libgweather versions were 40.y and the new
> > > > versions
> > > > are 4.4.z, shouldn't there be an Epoch?
> > > >
> > >
> > > I was thinking about this hard as well and I managed to convince
> > > myself
> > > that it should be fine without an epoch, for two reasons:
> > >
> > > 1) The libgweather package was last part of the F38 package set, and
> > > has
> > > been retired ever since (in F39+). Because of that, new F39 installs
> > > don't
> > > have the package, and people who have updated from F38 to either F39
> > > or
> > > current rawhide (F40) don't have the package either (it was obsoleted
> > > in
> > > fedora-obsolete-packages).
> > >
> > > 2) This only leaves people who would do F38->F40 distro upgrade in
> > > the
> > > future, but I think this case should be fine as well because AFAIK
> > > both dnf
> > > and PackageKit use distro-sync for distro upgrades, so they handle
> > > downgrades just fine.
> > >
> > > Normally this should have definitely warranted an epoch, but because
> > > it was
> > > retired for a long time, I believe it should be fine without. We can
> > > also
> > > always add an epoch in the future if it turns out we missed some
> > > case.
> > >
> > > What do you think?
> > > >
> >
> > Still concerned.  You've mentioned those who have already upgraded 38-
> > >rawhide, but what about those who *will* upgrade (e.g. post-branching)
> > 38->40?  Since that is a supported upgrade path, and 38 had 40.0, this
> > will be a downgrade.  If this wasn't landing until F41 the answer could
> > be different, but it really hasn't been out long enough.  After all,
> > the fedora-obsolete-packages entry was set to be removed for F41 for a
> > reason.
>

Replying to Yaakov here:
I actually mentioned this as case (2) above, where my idea was that because
dnf and PackageKit distro upgrades both use the "distro-sync" method by
default, they can handle package downgrades just fine when updating from
F38->F40.

However, Stephan then found a hole in the idea:


> I agree with Yaakov here.
>
> While you're correct that the standard upgrade mechanism now defaults
> to using `dnf distro-sync`, it's not the ONLY upgrade path that people
> take. There are a huge number of users who still insist on doing a
> basic DNF upgrade, no matter how much documentation we write. This
> WILL cause issues for them and will translate into bug reports that
> need to be at least triaged. So please, just support a clean upgrade
> path with the epoch bump.
>

Ah, and that's a fair point. I agree that there are probably a ton of
people just doing dnf update across distro versions.

However, I'm still a bit reluctant to add an epoch to libgweather, and not
because of the one extra Epoch line in libgweather's spec file, but because
of all other packages that would then need to remember to use the epoch
when they want to express a versioned dependency on libgweather. E.g.
'Requires: libgweather >= 4.5' would match _any_ libgweather version if the
epoch is set to 1, and packages would need to use 'Requires: libgweather >=
1:4.5' instead.

So, thinking of alternatives to epoch (and yes, I realize that my timing
was bad here and I should have just waited for F40 branching before doing
the rename), I suddenly realized that nothing in F38 actually uses the old
libgweather at all - we got everything ported over to libgweather4, but
failed to retire libgweather in time.

And that opens up a new possibility: we could add libgweather to
fedora-obsoletes-packages in F38, and by the time F40 is released in
several months time, everybody's F40 systems will have gotten rid of the
old libgweather package and we get a nice clean upgrade path from F38->F40,
without having to worry about adding epoch.

How does that sound? Also keep in mind that the above is only to cater for
people who try to use an unsupported upgrade method - dnf and
PackageKit/gnome-software distro upgrades should already work fine without
it.


> Also, what about RHEL upgrades?  c9s has libgweather-40.0, this will
> > cause c10s to have 4.4.0.
> >
>
> RHEL major upgrades have special tooling, so I wouldn't worry about that.
>

That's good to hear - that makes everything a whole lot easier. If RHEL
major upgrades relied on regular Obsoletes and Provides, we'd have to be
much more conservative on Fedora side (in all packages, not talking about
libgweather here) and keep the upgrade path not just for 2 Fedora releases,
but a whole lot longer, so that they'd cover the time between major RHEL
versions.

-- 
Kalev
--
___
devel 

[rpms/perl-NetAddr-IP] PR #3: Remove dependency to Socket6, which we are going to remove

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-NetAddr-IP` that 
you are following:
``
Remove dependency to Socket6, which we are going to remove
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-NetAddr-IP/pull-request/3
--
___
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] Re: Orphaning python-mistune on EPEL

[Michel Lind]

Hi Miro,

On Wed, Jan 10, 2024 at 02:51:33PM +0100, Miro Hrončok wrote:
> Hello,
> 
> I recently took python-mistune in Fedora.
> I am not interested in maintaining it in EPEL.
> 
> It is branched for epel7, epel8 and epel9.
> 
> @epel-packagers-sig is a collaborator so I assume somebody built this in
> epel9 without taking responsibility.
> 
> There is a low impact CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2112231
> 
> If somebody want to maintain it, let me know and I'll make you the epel
> point of contact.
>
Please mark me as the EPEL POC.

Thanks,

-- 
Michel Lind (né Salim)
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

[EPEL-devel] EPEL Steering Committee Meeting Time Reschedule

[Diego Herrera]

As we discussed during last meeting, here is a poll to check if there is a 
timeslot that can fit more of the people that are currently interested to 
participate in the EPEL Steering Committee Meeting.

https://whenisgood.net/EPEL_Steering_Committee_2024

What day and time would you like? Paint over all the time slots that are good 
for you. 

I will run this for a couple of weeks and collect the results after that.
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads up: libgweather4 to libgweather rename in rawhide

[Stephen Gallagher]

On Wed, Jan 10, 2024 at 1:38 PM Yaakov Selkowitz  wrote:
>
> On Wed, 2024-01-10 at 19:13 +0100, Kalev Lember wrote:
> > On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz
> > 
> > wrote:
> >
> > > Since the previous libgweather versions were 40.y and the new
> > > versions
> > > are 4.4.z, shouldn't there be an Epoch?
> > >
> >
> > I was thinking about this hard as well and I managed to convince
> > myself
> > that it should be fine without an epoch, for two reasons:
> >
> > 1) The libgweather package was last part of the F38 package set, and
> > has
> > been retired ever since (in F39+). Because of that, new F39 installs
> > don't
> > have the package, and people who have updated from F38 to either F39
> > or
> > current rawhide (F40) don't have the package either (it was obsoleted
> > in
> > fedora-obsolete-packages).
> >
> > 2) This only leaves people who would do F38->F40 distro upgrade in
> > the
> > future, but I think this case should be fine as well because AFAIK
> > both dnf
> > and PackageKit use distro-sync for distro upgrades, so they handle
> > downgrades just fine.
> >
> > Normally this should have definitely warranted an epoch, but because
> > it was
> > retired for a long time, I believe it should be fine without. We can
> > also
> > always add an epoch in the future if it turns out we missed some
> > case.
> >
> > What do you think?
> > >
>
> Still concerned.  You've mentioned those who have already upgraded 38-
> >rawhide, but what about those who *will* upgrade (e.g. post-branching)
> 38->40?  Since that is a supported upgrade path, and 38 had 40.0, this
> will be a downgrade.  If this wasn't landing until F41 the answer could
> be different, but it really hasn't been out long enough.  After all,
> the fedora-obsolete-packages entry was set to be removed for F41 for a
> reason.

I agree with Yaakov here.

While you're correct that the standard upgrade mechanism now defaults
to using `dnf distro-sync`, it's not the ONLY upgrade path that people
take. There are a huge number of users who still insist on doing a
basic DNF upgrade, no matter how much documentation we write. This
WILL cause issues for them and will translate into bug reports that
need to be at least triaged. So please, just support a clean upgrade
path with the epoch bump.

> Also, what about RHEL upgrades?  c9s has libgweather-40.0, this will
> cause c10s to have 4.4.0.
>

RHEL major upgrades have special tooling, so I wouldn't worry about that.

> Fedora Code of Conduct: 
> https://docs.fedoraproject.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: Heads up: libgweather4 to libgweather rename in rawhide

[Yaakov Selkowitz]

On Wed, 2024-01-10 at 19:13 +0100, Kalev Lember wrote:
> On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz
> 
> wrote:
> 
> > Since the previous libgweather versions were 40.y and the new
> > versions
> > are 4.4.z, shouldn't there be an Epoch?
> > 
> 
> I was thinking about this hard as well and I managed to convince
> myself
> that it should be fine without an epoch, for two reasons:
> 
> 1) The libgweather package was last part of the F38 package set, and
> has
> been retired ever since (in F39+). Because of that, new F39 installs
> don't
> have the package, and people who have updated from F38 to either F39
> or
> current rawhide (F40) don't have the package either (it was obsoleted
> in
> fedora-obsolete-packages).
> 
> 2) This only leaves people who would do F38->F40 distro upgrade in
> the
> future, but I think this case should be fine as well because AFAIK
> both dnf
> and PackageKit use distro-sync for distro upgrades, so they handle
> downgrades just fine.
> 
> Normally this should have definitely warranted an epoch, but because
> it was
> retired for a long time, I believe it should be fine without. We can
> also
> always add an epoch in the future if it turns out we missed some
> case.
> 
> What do you think?
> > 

Still concerned.  You've mentioned those who have already upgraded 38-
>rawhide, but what about those who *will* upgrade (e.g. post-branching)
38->40?  Since that is a supported upgrade path, and 38 had 40.0, this
will be a downgrade.  If this wasn't landing until F41 the answer could
be different, but it really hasn't been out long enough.  After all,
the fedora-obsolete-packages entry was set to be removed for F41 for a
reason.

Also, what about RHEL upgrades?  c9s has libgweather-40.0, this will
cause c10s to have 4.4.0.

Welcome to further input on this, but epoch seems the safest bet here.

> > > I expect this only affects places where the package name is
> > > hardcoded
> > > -
> > > CentOS 10 package sync comes to mind. I've added obsoletes and
> > > provides for
> > > all its subpackages so it should be transparent otherwise.
> > 
> > Please file a PR for content-resolver-input.
> > 
> 
> Thanks, done:
> 
> https://github.com/minimization/content-resolver-input/pull/1055

Thanks, merged.

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

[EPEL-devel] Re: Orphaning python-mistune on EPEL

[Miro Hrončok]

On 10. 01. 24 15:21, Neil Hanlon wrote:

I'll take this one for epel.


Thank You, Neil. Done.

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

Re: Heads up: libgweather4 to libgweather rename in rawhide

[Kalev Lember]

Hi Yaakov,

On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz 
wrote:

> Since the previous libgweather versions were 40.y and the new versions
> are 4.4.z, shouldn't there be an Epoch?
>

I was thinking about this hard as well and I managed to convince myself
that it should be fine without an epoch, for two reasons:

1) The libgweather package was last part of the F38 package set, and has
been retired ever since (in F39+). Because of that, new F39 installs don't
have the package, and people who have updated from F38 to either F39 or
current rawhide (F40) don't have the package either (it was obsoleted in
fedora-obsolete-packages).

2) This only leaves people who would do F38->F40 distro upgrade in the
future, but I think this case should be fine as well because AFAIK both dnf
and PackageKit use distro-sync for distro upgrades, so they handle
downgrades just fine.

Normally this should have definitely warranted an epoch, but because it was
retired for a long time, I believe it should be fine without. We can also
always add an epoch in the future if it turns out we missed some case.

What do you think?



> > I expect this only affects places where the package name is hardcoded
> > -
> > CentOS 10 package sync comes to mind. I've added obsoletes and
> > provides for
> > all its subpackages so it should be transparent otherwise.
>
> Please file a PR for content-resolver-input.
>

Thanks, done:

https://github.com/minimization/content-resolver-input/pull/1055

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

Fedora CoreOS Community Meeting Minutes 2024-01-10

[Steven Presti]

Minutes:
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-01-10/fedora-coreos-meeting.2024-01-10-16.35.html
Minutes (text):
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-01-10/fedora-coreos-meeting.2024-01-10-16.35.txt
Log:
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-01-10/fedora-coreos-meeting.2024-01-10-16.35.log.txt

=
# #meeting-1:fedoraproject.org: fedora_coreos_meeting
=

Meeting started by @spresti:fedora.im at 2024-01-10 16:35:03



Meeting summary
---
* TOPIC: roll call (@spresti:fedora.im, 16:35:16)
* TOPIC: Action items from last meeting (@spresti:fedora.im, 16:38:59)
* TOPIC: there are no action items from the last meeting.
(@spresti:fedora.im, 16:40:16)
* TOPIC: New Package Request: mtr (@spresti:fedora.im, 16:41:06)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1644
(@spresti:fedora.im, 16:41:17)
* AGREED: the basic functionality of mtr already exists in FCOS
through tracepath. Additionally mtr can be installed and ran in a
toolbox container. So we currently do not see the need to add this
package to the base for everyone. (@spresti:fedora.im, 16:53:51)
* TOPIC: aarch64 failing to upgrade with /boot filesystem full
(@spresti:fedora.im, 16:54:22)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1637
(@spresti:fedora.im, 16:54:34)
* AGREED: continue with the proposed mitigation/fix for this is in
https://github.com/coreos/fedora-coreos-tracker/issues/1637#issuecomment-1878186381
which we are actively executing. (@spresti:fedora.im, 17:00:27)
* TOPIC: tracker: Fedora 40 changes considerations
(@spresti:fedora.im, 17:00:55)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1626
(@spresti:fedora.im, 17:01:11)
* TOPIC: Open Floor (@spresti:fedora.im, 17:06:53)

Meeting ended at 2024-01-10 17:19:10

Action items


People Present (lines said)
---
* @spresti:fedora.im (42)
* @siosm:matrix.org (21)
* @dustymabe:matrix.org (18)
* @zodbot:fedora.im (7)
* @fifofonix:matrix.org (4)
* @jlebon:fedora.im (4)
* @meetbot:fedora.im (2)
* @marmijo:fedora.im (1)
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads up: libgweather4 to libgweather rename in rawhide

[Yaakov Selkowitz]

On Wed, 2024-01-10 at 17:59 +0100, Kalev Lember wrote:
> Just a quick heads up that I'm in the process of renaming
> libgweather4
> package
> back to libgweather - we only ship a single libgweather version in
> rawhide
> (and
> in F39), so there is no need any more to have the API version encoded
> in the
> package name in order to make it parallel installable.

Since the previous libgweather versions were 40.y and the new versions
are 4.4.z, shouldn't there be an Epoch?

> I expect this only affects places where the package name is hardcoded
> -
> CentOS 10 package sync comes to mind. I've added obsoletes and
> provides for
> all its subpackages so it should be transparent otherwise.

Please file a PR for content-resolver-input.

-- 
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.
--
___
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 2257445] nagios-plugins-disk_smb cannot be installed

[bugzilla]

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



--- Comment #4 from Christoph Karl  ---
Thank you very much, its working now.
I was not aware that CodeReady Builder repository is required.


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

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

Heads up: libgweather4 to libgweather rename in rawhide

[Kalev Lember]

Hi all,

Just a quick heads up that I'm in the process of renaming libgweather4
package
back to libgweather - we only ship a single libgweather version in rawhide
(and
in F39), so there is no need any more to have the API version encoded in the
package name in order to make it parallel installable.

I expect this only affects places where the package name is hardcoded -
CentOS 10 package sync comes to mind. I've added obsoletes and provides for
all its subpackages so it should be transparent otherwise.

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

[EPEL-devel] Retirement of package `godot` in EPEL7

[Rémi Verschelde]

Hi,

I'm the maintainer of the `godot` [0] package in Fedora and EPEL7 (as well as 
the
upstream maintainer).
I'm following the documented procedure [1] to retire this package.

I announced my intent to retire this package from EPEL7 back in October 2023 
[2].
Nobody volunteered to take it over (which I also wouldn't recommend 
personally), so I'm now proceeding with removing this package.

EPEL7 users who want to continue using Godot 3.1.2 (version packaged currently) 
can download Linux binaries [3] which should work on EPEL7. I advise 
downloading the latest version of Godot for any serious game development effort 
(currently 4.2.1 [4]).

Best,
Rémi

[0] https://src.fedoraproject.org/rpms/godot
[1] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/
[2] 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/MO7JO2MGSVRP2R2A6KOAX7O7J67RR4CH/?sort=date
[3] https://github.com/godotengine/godot/releases/tag/3.1.2-stable
[4] https://github.com/godotengine/godot/releases/tag/4.2.1-stable
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review of Matrix Go packages

[Kai A. Hiller]

I’m still looking for reviews of these packages. Initial responder sadly 
didn’t come back to me. Can I interest you in a review swap?


On 2023-11-18 09:48, Kai A. Hiller wrote:


Hello,

I’m currently adding Go-based parts of the Matrix ecosystem to Fedora. 
For that I need reviews of quite a few, but mostly small and 
auto-generated packages. Help is appreciated, please tell me what you 
need from me in return.


List of package dependencies and bugzilla links:

golang-maunium-mautrix (#2250408 
)
├ golang-mau-zeroconfig (#2249896 
)
├ golang-mau-util (#2249878 
)
├ golang-maunium-mauflag (#2249890 
)
├ golang-maunium-maulogger-2 (#2249894 
)
│ ├ golang-github-tidwall-sjson (#2249874 
<#https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2249874>)
│ │ ├ golang-github-tidwall-gjson (#2249873 
<#https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2249873>)
│ │ │ ├ golang-github-tidwall-match (#2249868 
<#https://bugzilla.redhat.com/show_bug.cgi?id=2249868>)
├ golang-github-matrix-org-gomatrixserverlib (#2250315 
)
│ ├ golang-gopkg-macaroon-2 (#2250314 
)
│ ├ golang-github-matrix-org-util (#2250311 
)
│ ├ golang-github-matrix-org-gomatrix (#2250312 
)

│ ├ golang-github-tidwall-sjson

Best wishes
Kai


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

[EPEL-devel] Re: Orphaning python-mistune on EPEL

[Neil Hanlon]

On Wed, Jan 10, 2024, 08:51 Miro Hrončok  wrote:

> Hello,
>
> I recently took python-mistune in Fedora.
> I am not interested in maintaining it in EPEL.
>
> It is branched for epel7, epel8 and epel9.
>
> @epel-packagers-sig is a collaborator so I assume somebody built this in
> epel9
> without taking responsibility.
>
> There is a low impact CVE:
> https://bugzilla.redhat.com/show_bug.cgi?id=2112231
>
> If somebody want to maintain it, let me know and I'll make you the epel
> point
> of contact.
>

I'll take this one for epel.

Thanks!

Neil

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

[Bug 2257491] perl-Date-Manip-6.94 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Date-Manip-6.94-1.fc40
 Resolution|--- |ERRATA
Last Closed||2024-01-10 14:18:25



--- Comment #2 from Fedora Update System  ---
FEDORA-2024-9cd2ca525b has been pushed to the Fedora 40 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=2257491

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202257491%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 2257491] perl-Date-Manip-6.94 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2024-9cd2ca525b has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-9cd2ca525b


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202257491%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-Date-Manip] PR #5: 6.94 bump; Package tests

[Jitka Plesnikova]

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

Merged pull-request:

``
6.94 bump; Package tests
``

https://src.fedoraproject.org/rpms/perl-Date-Manip/pull-request/5
--
___
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] Orphaning python-mistune on EPEL

[Miro Hrončok]

Hello,

I recently took python-mistune in Fedora.
I am not interested in maintaining it in EPEL.

It is branched for epel7, epel8 and epel9.

@epel-packagers-sig is a collaborator so I assume somebody built this in epel9 
without taking responsibility.


There is a low impact CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2112231

If somebody want to maintain it, let me know and I'll make you the epel point 
of contact.


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

[rpms/perl-Date-Manip] PR #5: 6.94 bump; Package tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Date-Manip` that 
you are following:
``
6.94 bump; Package tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Date-Manip/pull-request/5
--
___
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

Orphaning python-jupyter-collaboration and other related packages

[Lumír Balhar]

Hello.

I plan to orphan the following independent set of packages:

python-jupyter-collaboration
python-jupyter-server-fileid
python-jupyter-ydoc
python-ypy-websocket
python-y-py
rust-yrs
rust-lib0

I've packaged python-jupyter-collaboration to bring the real-time 
collaboration feature into Jupyter lab (like Google docs have). But now, 
they decided to switch to a different backend and the update of 
jupyter-ydoc and related components requires to package at least two new 
packages pycrdt and pycrdt-websocket and I don't have enought time for that.


Users of Jupyter Lab won't lose the real-time feature. If you want to 
use it, make sure you have the latest version of jupyterlab installed. 
The latest version makes it possible to install and use extensions from 
Python Package Index. Just run Jupyter lab, switch to extensions pane 
and install jupyter-collaboration and then, after a restart of jupyter 
lab, you have the same functionality as python3-jupyter-collaboration 
provides. Extensions are installed into $HOME/.local/lib/python… (same 
as pip install --user).


Rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=2343378
F39: https://bodhi.fedoraproject.org/updates/FEDORA-2024-4805f7aa89

Have a nice day.

Lumír
--
___
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: Referencing an upstream subdir in the sources

[Iñaki Ucar]

Great guide and references. Thanks, Michael and Michal.

Iñaki

El mié., 10 ene. 2024 13:41, Michal Schorm  escribió:

> On Wed, Jan 10, 2024 at 12:14 PM Michael J Gruber 
> wrote:
> > Alternatively, we (used to?) have several packages which need to clean
> > upstream sources before even committing them to the lookaside cache.
>
> I do it for MariaDB for example, deleting part of the sources under
> unapproved licenses:
>
> https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/generate-modified-sources.sh
>
> Michal
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>
> On Wed, Jan 10, 2024 at 12:14 PM Michael J Gruber 
> wrote:
> >
> > Am Mi., 10. Jan. 2024 um 11:39 Uhr schrieb Iñaki Ucar <
> iu...@fedoraproject.org>:
> > >
> > > Hi,
> > >
> > > A package has its source code embedded as a subdirectory of a larger
> > > piece of software. Sometimes they publish this subdirectory as a
> > > separate tar as a release artifact, but sometimes they forget.
> > >
> > > To avoid depending on their memory (and opening an issue each time), I
> > > would like to simply download the full repo and produce the tar
> > > myself. How should I deal with this in the spec? (Note: building this
> > > subdir as a subpackage in the main one is not a good idea in this
> > > case, it's not an option).
> >
> > Hi,
> >
> > I assume you don't want to distribute the full tar and simply cd into
> > it the proper subdir during the build? That would be the easiest
> > solution.
> >
> > Alternatively, we (used to?) have several packages which need to clean
> > upstream sources before even committing them to the lookaside cache.
> > scribus comes to my mind, some crypto things were like that in the
> > past. What you typically do is:
> > - Write a simple script which mangles the upstream package.tar and
> > repackages it as package-free.tar or such.
> > - Add the script to dist-git.
> > - comment out the original source line in spec (and the signature if
> present)
> > - specify "source: package-free.tar" instead and comment on the use of
> > the script
> > - commit only package-free.tar to dist-git
> >
> > That way, everyone can reproduce the used source code from the
> > upstream source code if needed while we only have the actual used
> > source in dist-git (lookaside).
> >
> > Michael
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> 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: Referencing an upstream subdir in the sources

[Michal Schorm]

On Wed, Jan 10, 2024 at 12:14 PM Michael J Gruber  
wrote:
> Alternatively, we (used to?) have several packages which need to clean
> upstream sources before even committing them to the lookaside cache.

I do it for MariaDB for example, deleting part of the sources under
unapproved licenses:
  
https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/generate-modified-sources.sh

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, Jan 10, 2024 at 12:14 PM Michael J Gruber  
wrote:
>
> Am Mi., 10. Jan. 2024 um 11:39 Uhr schrieb Iñaki Ucar 
> :
> >
> > Hi,
> >
> > A package has its source code embedded as a subdirectory of a larger
> > piece of software. Sometimes they publish this subdirectory as a
> > separate tar as a release artifact, but sometimes they forget.
> >
> > To avoid depending on their memory (and opening an issue each time), I
> > would like to simply download the full repo and produce the tar
> > myself. How should I deal with this in the spec? (Note: building this
> > subdir as a subpackage in the main one is not a good idea in this
> > case, it's not an option).
>
> Hi,
>
> I assume you don't want to distribute the full tar and simply cd into
> it the proper subdir during the build? That would be the easiest
> solution.
>
> Alternatively, we (used to?) have several packages which need to clean
> upstream sources before even committing them to the lookaside cache.
> scribus comes to my mind, some crypto things were like that in the
> past. What you typically do is:
> - Write a simple script which mangles the upstream package.tar and
> repackages it as package-free.tar or such.
> - Add the script to dist-git.
> - comment out the original source line in spec (and the signature if present)
> - specify "source: package-free.tar" instead and comment on the use of
> the script
> - commit only package-free.tar to dist-git
>
> That way, everyone can reproduce the used source code from the
> upstream source code if needed while we only have the actual used
> source in dist-git (lookaside).
>
> Michael
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
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

F40 Change Proposal: Java 21 (System-Wide)

[Aoife Moloney]

Wiki ->https://fedoraproject.org/wiki/Changes/Java21

**This is a *proposed* Change for Fedora Linux.**
This document represents a *proposed* Change. As part of the [Changes
process](https://docs.fedoraproject.org/en-US/program_management/changes_policy/),
proposals are publicly announced in order to receive community
feedback. This proposal will only be implemented if approved by the
Fedora Engineering Steering Committee.


== Summary ==
Update the system JDK in Fedora from java-17-openjdk to java-21-openjdk.

== Owner ==
* Name: [[User:pmikova| Petra Alice Mikova]]
* Email: 
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)(which no longer exists)
* rcm ticket: https://pagure.io/releng/issue/11859
* named side tag ticket: TBD



=== Expected schedule ===
* During January 2024, we will create a new package, java-21-openjdk,
which will be a clone of java-latest-openjdk, which contains STS
versions of OpenJDK (currently 21) and will move to JDK 22 in
February/March.
* December 2023 I will do mass rebuild in copr
** all maintainers will be informed about the results
* January 2023 I will do second mass rebuild in copr
** all maintainers will be informed about the results
*  February 2023 mass rebuild in rawhide - side tag
** FTBFS bugs will be filed
*  February 2023 the sidetag will be merged
* Change Checkpoint: 100% Code Complete Deadline TBD
** hard deadline for feature completed

== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* java-17-openjdk (LTS), system JDK
* java-latest-openjdk (currently JDK21)
* java-21-openjdk will be cloned from java-latest-openjdk

Therefore, every package honoring the packaging rules and requiring
java via java-headless or java-devel is built in koji using
java-17-openjdk-devel and pulling java-17-openjdk during runtime (see
[https://fedoraproject.org/wiki/Java java] ). Also,
javapackaging-tools are using java-11-openjdk as hardcoded runtime
(see 
[https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting
changes]).

We were intentionally delaying jdk11 on-boarding for stability
reasons. But there is reason for this approach with 21 (for recall,
see https://fedoraproject.org/wiki/Changes/Java11)

Major incompatibility is again (as we were bumping 8->11)
encapsulation. What was hidden is now even more hidden and few more
parts were hidden. Luckily, most of the projects, when shifted to 11,
did it properly. Still few projects may hit usage of some  newly
restricted APIs.

== Feedback ==


== Benefit to Fedora ==

JDK21 was released a while ago, but compatibility with JDK 17 is good
enough and it is a stable release. Although we can expect some group
of packages to use jdk8 forever, and some other (much smaller) group
of packages stay on jdk11 for a while, the java stack should be able
to use the JDK 21. Both JDK 8 and JDK 11 will remain part of Fedora as
long as they are supported upstream, and there is a target audience in
our OS.


== Scope ==
=== To keep the java-17-openjdk (and lower versions of JDK), but to
remove its java/javac versionless provides, make java-21-openjdk the
provider of java, javac and other versionless provides, and keep
java-latest-openjdk as rolling package for STS JDKs) ===
* will guarantee fedora to be pure JDK21 distro.
* will allow maintainers of JDK21 (or higher) incompatible packages to
keep using JDK 17, JDK 11 and JDK 8
** if any package depends on a package built by JDK 21, JDK 17, JDK 11
and JDK 8 may not be able to pick up that dependency.
** this may lead to quite a lot of bundling or compat packages, but
that may be acceptable
** people developing JDK8 and JDK11 applications will very likely stay
with fedora
** we are bumping the system JDK every time a new JDK LTS comes up and
it proved itself as a good practice

While quite a lot of users will rejoice, there may be cases where
application is very hard to migrate to JDK11, so the contingency plan
should be taken very serious.
 Bytecode version 
* It appeared, that several applications have to be built by jdk8,
while they work fine with jdk11
* It lead to manual work on aligned libraries on 1.8 byte code
version.  see https://pagure.io/java-maint-sig/issue/7
* Other approaches how to avoid this in next update (jdk17, aprox f36,
minimal bytecode 7) were mentioned here:
https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#comment-50266
 Workflow 
* announce as by
https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_essential_communication
* tune java-latest-openjdk package (for all live Fedoras)
* clone java-21-openjdk package (for all live Fedoras)
* several rounds of mass rebuilds ( see
https://fedoraproject.org/w/index.php?title=Changes/Java21#Expected_schedule)
** from copr
** over side tag
** to koji
 Change owners 
* Feature will be implemented in
[https://fedoraproject.org/wiki/Changes/Java21#side_tag side 

F40 Change Proposal: Java 21 (System-Wide)

[Aoife Moloney]

Wiki ->https://fedoraproject.org/wiki/Changes/Java21

**This is a *proposed* Change for Fedora Linux.**
This document represents a *proposed* Change. As part of the [Changes
process](https://docs.fedoraproject.org/en-US/program_management/changes_policy/),
proposals are publicly announced in order to receive community
feedback. This proposal will only be implemented if approved by the
Fedora Engineering Steering Committee.


== Summary ==
Update the system JDK in Fedora from java-17-openjdk to java-21-openjdk.

== Owner ==
* Name: [[User:pmikova| Petra Alice Mikova]]
* Email: 
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)(which no longer exists)
* rcm ticket: https://pagure.io/releng/issue/11859
* named side tag ticket: TBD



=== Expected schedule ===
* During January 2024, we will create a new package, java-21-openjdk,
which will be a clone of java-latest-openjdk, which contains STS
versions of OpenJDK (currently 21) and will move to JDK 22 in
February/March.
* December 2023 I will do mass rebuild in copr
** all maintainers will be informed about the results
* January 2023 I will do second mass rebuild in copr
** all maintainers will be informed about the results
*  February 2023 mass rebuild in rawhide - side tag
** FTBFS bugs will be filed
*  February 2023 the sidetag will be merged
* Change Checkpoint: 100% Code Complete Deadline TBD
** hard deadline for feature completed

== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* java-17-openjdk (LTS), system JDK
* java-latest-openjdk (currently JDK21)
* java-21-openjdk will be cloned from java-latest-openjdk

Therefore, every package honoring the packaging rules and requiring
java via java-headless or java-devel is built in koji using
java-17-openjdk-devel and pulling java-17-openjdk during runtime (see
[https://fedoraproject.org/wiki/Java java] ). Also,
javapackaging-tools are using java-11-openjdk as hardcoded runtime
(see 
[https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting
changes]).

We were intentionally delaying jdk11 on-boarding for stability
reasons. But there is reason for this approach with 21 (for recall,
see https://fedoraproject.org/wiki/Changes/Java11)

Major incompatibility is again (as we were bumping 8->11)
encapsulation. What was hidden is now even more hidden and few more
parts were hidden. Luckily, most of the projects, when shifted to 11,
did it properly. Still few projects may hit usage of some  newly
restricted APIs.

== Feedback ==


== Benefit to Fedora ==

JDK21 was released a while ago, but compatibility with JDK 17 is good
enough and it is a stable release. Although we can expect some group
of packages to use jdk8 forever, and some other (much smaller) group
of packages stay on jdk11 for a while, the java stack should be able
to use the JDK 21. Both JDK 8 and JDK 11 will remain part of Fedora as
long as they are supported upstream, and there is a target audience in
our OS.


== Scope ==
=== To keep the java-17-openjdk (and lower versions of JDK), but to
remove its java/javac versionless provides, make java-21-openjdk the
provider of java, javac and other versionless provides, and keep
java-latest-openjdk as rolling package for STS JDKs) ===
* will guarantee fedora to be pure JDK21 distro.
* will allow maintainers of JDK21 (or higher) incompatible packages to
keep using JDK 17, JDK 11 and JDK 8
** if any package depends on a package built by JDK 21, JDK 17, JDK 11
and JDK 8 may not be able to pick up that dependency.
** this may lead to quite a lot of bundling or compat packages, but
that may be acceptable
** people developing JDK8 and JDK11 applications will very likely stay
with fedora
** we are bumping the system JDK every time a new JDK LTS comes up and
it proved itself as a good practice

While quite a lot of users will rejoice, there may be cases where
application is very hard to migrate to JDK11, so the contingency plan
should be taken very serious.
 Bytecode version 
* It appeared, that several applications have to be built by jdk8,
while they work fine with jdk11
* It lead to manual work on aligned libraries on 1.8 byte code
version.  see https://pagure.io/java-maint-sig/issue/7
* Other approaches how to avoid this in next update (jdk17, aprox f36,
minimal bytecode 7) were mentioned here:
https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#comment-50266
 Workflow 
* announce as by
https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_essential_communication
* tune java-latest-openjdk package (for all live Fedoras)
* clone java-21-openjdk package (for all live Fedoras)
* several rounds of mass rebuilds ( see
https://fedoraproject.org/w/index.php?title=Changes/Java21#Expected_schedule)
** from copr
** over side tag
** to koji
 Change owners 
* Feature will be implemented in
[https://fedoraproject.org/wiki/Changes/Java21#side_tag side 

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2024-01-03.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

cdsclient astro-sig, orphan0 weeks ago
clash go-sig, orphan   5 weeks ago
csmithorphan   0 weeks ago
drumstick orphan, yanqiyu  0 weeks ago
drumstick0orphan, yanqiyu  0 weeks ago
kmetronomeorphan   0 weeks ago
libASLorion, orphan, slaanesh  2 weeks ago
mrpt  jkastner, kwizart, orphan,   5 weeks ago
  robotics-sig
mygnuhealth   orphan   0 weeks ago
obs-service-cargo_vendor  orphan   2 weeks ago
python-compressed-rtf orphan   0 weeks ago
python-google-cloud-access-   fkolwa, miyunari, orphan,2 weeks ago
approval  python-packagers-sig
python-google-cloud-access-   fkolwa, miyunari, orphan,2 weeks ago
context-manager   python-packagers-sig
python-google-cloud-api-gateway   fkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-apigee-   fkolwa, miyunari, orphan,2 weeks ago
connect   python-packagers-sig
python-google-cloud-appengine-fkolwa, miyunari, orphan,2 weeks ago
admin python-packagers-sig
python-google-cloud-asset fkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-automlfkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-bigquery  fkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-bigquery- fkolwa, miyunari, orphan,2 weeks ago
connectionpython-packagers-sig
python-google-cloud-bigquery- fkolwa, miyunari, orphan,2 weeks ago
datatransfer  python-packagers-sig
python-google-cloud-bigquery- fkolwa, miyunari, orphan,2 weeks ago
reservation   python-packagers-sig
python-google-cloud-bigquery- fkolwa, miyunari, orphan,2 weeks ago
storage   python-packagers-sig
python-google-cloud-bigtable  fkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-billing   fkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-billing-  fkolwa, miyunari, orphan,2 weeks ago
budgets   python-packagers-sig
python-google-cloud-build fkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-commonfkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-container fkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-  fkolwa, miyunari, orphan,2 weeks ago
containeranalysis python-packagers-sig
python-google-cloud-data-fusion   fkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-datacatalog   fkolwa, miyunari, orphan,2 weeks ago
  python-packagers-sig
python-google-cloud-dataproc  fkolwa, miyunari, orphan,2 

Re: Where to add new ssh key to my FAS account?

[Osama Albahrani via devel]

Hi Barry,

I think what you’re looking for can be done in
https://accounts.fedoraproject.org

Best,
Osama

On Wed, 10 Jan 2024 at 6:55 AM Barry Scott  wrote:

> I have been changing from SSH RSA key to using ed25519 based keys.
> I cannot recall, or track down docs on where to upload my new ssh key to
> for my FAS account.
>
> Can you point me in the right direction please?
>
> Barry
> --
> ___
> 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: Where to add new ssh key to my FAS account?

[Peter Robinson]

On Wed, 10 Jan 2024 at 11:55, Barry Scott  wrote:
>
> I have been changing from SSH RSA key to using ed25519 based keys.
> I cannot recall, or track down docs on where to upload my new ssh key to
> for my FAS account.
>
> Can you point me in the right direction please?

Login to https://accounts.fedoraproject.org/ and it should be on the
right side of your profile page under the avatar roughly.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20240110.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240109.n.0
NEW: Fedora-Rawhide-20240110.n.0

= SUMMARY =
Added images:0
Dropped images:  11
Added packages:  9
Dropped packages:4
Upgraded packages:   48
Downgraded packages: 0

Size of added packages:  9.63 MiB
Size of dropped packages:13.42 MiB
Size of upgraded packages:   9.60 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20240109.n.0.iso
Image: Container_Minimal_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20240109.n.0.x86_64.tar.xz
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20240109.n.0.iso
Image: SoaS raw-xz aarch64
Path: Spins/aarch64/images/Fedora-SoaS-Rawhide-20240109.n.0.aarch64.raw.xz
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20240109.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20240109.n.0.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20240109.n.0.iso
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20240109.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20240109.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20240109.n.0.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20240109.n.0.iso

= ADDED PACKAGES =
Package: rust-gcd-2.3.0-1.fc40
Summary: Calculate the greatest common divisor
RPMs:rust-gcd+default-devel rust-gcd-devel
Size:23.44 KiB

Package: rust-uu_base32-0.0.23-1.fc40
Summary: Base32 ~ (uutils) decode/encode input (base32-encoding)
RPMs:rust-uu_base32+default-devel rust-uu_base32-devel uu_base32
Size:1.67 MiB

Package: rust-uu_comm-0.0.23-1.fc40
Summary: comm ~ (uutils) compare sorted inputs
RPMs:rust-uu_comm+default-devel rust-uu_comm-devel uu_comm
Size:1.51 MiB

Package: rust-uu_df-0.0.23-1.fc40
Summary: df ~ (uutils) display file system information
RPMs:rust-uu_df+default-devel rust-uu_df-devel uu_df
Size:1.74 MiB

Package: rust-uu_mkdir-0.0.23-1.fc40
Summary: mkdir ~ (uutils) create DIRECTORY
RPMs:rust-uu_mkdir+default-devel rust-uu_mkdir-devel uu_mkdir
Size:1.54 MiB

Package: rust-uu_mktemp-0.0.23-1.fc40
Summary: mktemp ~ (uutils) create and display a temporary file or directory 
from TEMPLATE
RPMs:rust-uu_mktemp+default-devel rust-uu_mktemp-devel uu_mktemp
Size:1.62 MiB

Package: rust-uu_whoami-0.0.23-1.fc40
Summary: whoami ~ (uutils) display user name of current effective user ID
RPMs:rust-uu_whoami+default-devel rust-uu_whoami-devel uu_whoami
Size:1.49 MiB

Package: rust-uutils_term_grid-0.3.0-1.fc40
Summary: Library for formatting strings into a grid layout. Fork of term_grid
RPMs:rust-uutils_term_grid+default-devel rust-uutils_term_grid-devel
Size:25.61 KiB

Package: zstr-1.0.7-1.fc40
Summary: A C++ header-only ZLib wrapper
RPMs:zstr-devel
Size:15.68 KiB


= DROPPED PACKAGES =
Package: clash-1.8.0-8.fc39
Summary: A rule-based tunnel in Go
RPMs:clash golang-github-dreamacro-clash-devel
Size:12.66 MiB

Package: libwpe-1.15.1-2.fc39
Summary: General-purpose library for the WPE-flavored port of WebKit
RPMs:libwpe libwpe-devel
Size:381.86 KiB

Package: python-esphomeflasher-1.4.0-8.fc39
Summary: Simple GUI tool to flash ESPs over USB
RPMs:esphomeflasher
Size:59.48 KiB

Package: wpebackend-fdo-1.14.2-2.fc39
Summary: A WPE backend designed for Linux desktop systems
RPMs:wpebackend-fdo wpebackend-fdo-devel
Size:338.50 KiB


= UPGRADED PACKAGES =
Package:  LibRaw-0.21.2-2.fc40
Old package:  LibRaw-0.21.2-1.fc40
Summary:  Library for reading RAW files obtained from digital photo cameras
RPMs: LibRaw LibRaw-devel LibRaw-samples LibRaw-static
Size: 4.97 MiB
Size change:  -17.79 KiB
Changelog:
  * Thu Dec 21 2023 Gwyn Ciesla  - 0.21.2-1
  - 0.21.2, enable zlib support.

  * Tue Jan 09 2024 Gwyn Ciesla  - 0.21.2-2
  - CR3-Qstep table: avoid wrong 64-bit code generation patch


Package:  ModemManager-1.22.0-1.fc40
Old package:  ModemManager-1.20.6-3.fc39
Summary:  Mobile broadband modem management service
RPMs: ModemManager ModemManager-devel ModemManager-glib 
ModemManager-glib-devel ModemManager-vala
Size: 11.93 MiB
Size change:  135.13 KiB
Changelog:
  * Tue Jan 09 2024 Dennis Gilmore  - 1.22.0-1
  - update to 1.22.0


Package:  almanah-0.12.3-9.fc40
Old package:  almanah-0.12.3-8.fc39
Summary:  Application for keeping an encrypted diary
RPMs: almanah
Size

Where to add new ssh key to my FAS account?

[Barry Scott]

I have been changing from SSH RSA key to using ed25519 based keys.
I cannot recall, or track down docs on where to upload my new ssh key to
for my FAS account.

Can you point me in the right direction please?

Barry
--
___
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: Referencing an upstream subdir in the sources

[Michael J Gruber]

Am Mi., 10. Jan. 2024 um 11:39 Uhr schrieb Iñaki Ucar :
>
> Hi,
>
> A package has its source code embedded as a subdirectory of a larger
> piece of software. Sometimes they publish this subdirectory as a
> separate tar as a release artifact, but sometimes they forget.
>
> To avoid depending on their memory (and opening an issue each time), I
> would like to simply download the full repo and produce the tar
> myself. How should I deal with this in the spec? (Note: building this
> subdir as a subpackage in the main one is not a good idea in this
> case, it's not an option).

Hi,

I assume you don't want to distribute the full tar and simply cd into
it the proper subdir during the build? That would be the easiest
solution.

Alternatively, we (used to?) have several packages which need to clean
upstream sources before even committing them to the lookaside cache.
scribus comes to my mind, some crypto things were like that in the
past. What you typically do is:
- Write a simple script which mangles the upstream package.tar and
repackages it as package-free.tar or such.
- Add the script to dist-git.
- comment out the original source line in spec (and the signature if present)
- specify "source: package-free.tar" instead and comment on the use of
the script
- commit only package-free.tar to dist-git

That way, everyone can reproduce the used source code from the
upstream source code if needed while we only have the actual used
source in dist-git (lookaside).

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

[Bug 2257627] CVE-2024-22368 perl-Spreadsheet-XLSX: perl-Spreadsheet-ParseXLSX: out-of-memory condition during parsing of a crafted XLSX document [epel-all]

[bugzilla]

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

TEJ RATHI  changed:

   What|Removed |Added

 Blocks||2257625 (CVE-2024-22368)





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2257625
[Bug 2257625] CVE-2024-22368 perl-Spreadsheet-ParseXLSX: out-of-memory
condition during parsing of a crafted XLSX document
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2257627
--
___
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 2257628] CVE-2024-22368 perl-Spreadsheet-XLSX: perl-Spreadsheet-ParseXLSX: out-of-memory condition during parsing of a crafted XLSX document [fedora-all]

[bugzilla]

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



--- Comment #1 from TEJ RATHI  ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=

# bugfix, security, enhancement, newpackage (required)
type=security

# low, medium, high, urgent (required)
severity=medium

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=2257625,2257628

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

==

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202257628%23c1
--
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2257628] New: CVE-2024-22368 perl-Spreadsheet-XLSX: perl-Spreadsheet-ParseXLSX: out-of-memory condition during parsing of a crafted XLSX document [fedora-all]

[bugzilla]

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

Bug ID: 2257628
   Summary: CVE-2024-22368 perl-Spreadsheet-XLSX:
perl-Spreadsheet-ParseXLSX: out-of-memory condition
during parsing of a crafted XLSX document [fedora-all]
   Product: Fedora
   Version: 39
Status: NEW
 Component: perl-Spreadsheet-XLSX
  Keywords: Security, SecurityTracking
  Severity: medium
  Priority: medium
  Assignee: redhat-bugzi...@linuxnetz.de
  Reporter: tra...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org,
redhat-bugzi...@linuxnetz.de
  Target Milestone: ---
Classification: Fedora




More information about this security flaw is available in the following bug:

http://bugzilla.redhat.com/show_bug.cgi?id=2257625

Disclaimer: Community trackers are created by Red Hat Product Security team on
a best effort basis. Package maintainers are required to ascertain if the flaw
indeed affects their package, before starting the update process.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202257628%23c0
--
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2257628] CVE-2024-22368 perl-Spreadsheet-XLSX: perl-Spreadsheet-ParseXLSX: out-of-memory condition during parsing of a crafted XLSX document [fedora-all]

[bugzilla]

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

TEJ RATHI  changed:

   What|Removed |Added

 Blocks||2257625 (CVE-2024-22368)





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2257625
[Bug 2257625] CVE-2024-22368 perl-Spreadsheet-ParseXLSX: out-of-memory
condition during parsing of a crafted XLSX document
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2257628
--
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2257627] CVE-2024-22368 perl-Spreadsheet-XLSX: perl-Spreadsheet-ParseXLSX: out-of-memory condition during parsing of a crafted XLSX document [epel-all]

[bugzilla]

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



--- Comment #1 from TEJ RATHI  ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=

# bugfix, security, enhancement, newpackage (required)
type=security

# low, medium, high, urgent (required)
severity=medium

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=2257625,2257627

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

==

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202257627%23c1
--
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2257627] New: CVE-2024-22368 perl-Spreadsheet-XLSX: perl-Spreadsheet-ParseXLSX: out-of-memory condition during parsing of a crafted XLSX document [epel-all]

[bugzilla]

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

Bug ID: 2257627
   Summary: CVE-2024-22368 perl-Spreadsheet-XLSX:
perl-Spreadsheet-ParseXLSX: out-of-memory condition
during parsing of a crafted XLSX document [epel-all]
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Spreadsheet-XLSX
  Keywords: Security, SecurityTracking
  Severity: medium
  Priority: medium
  Assignee: redhat-bugzi...@linuxnetz.de
  Reporter: tra...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org,
redhat-bugzi...@linuxnetz.de
  Target Milestone: ---
Classification: Fedora




More information about this security flaw is available in the following bug:

http://bugzilla.redhat.com/show_bug.cgi?id=2257625

Disclaimer: Community trackers are created by Red Hat Product Security team on
a best effort basis. Package maintainers are required to ascertain if the flaw
indeed affects their package, before starting the update process.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202257627%23c0
--
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Referencing an upstream subdir in the sources

[Iñaki Ucar]

Hi,

A package has its source code embedded as a subdirectory of a larger
piece of software. Sometimes they publish this subdirectory as a
separate tar as a release artifact, but sometimes they forget.

To avoid depending on their memory (and opening an issue each time), I
would like to simply download the full repo and produce the tar
myself. How should I deal with this in the spec? (Note: building this
subdir as a subpackage in the main one is not a good idea in this
case, it's not an option).

Thanks,
-- 
Iñaki Úcar
--
___
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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Sjoerd Mullender]

On 09/01/2024 18.53, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Jan 09, 2024 at 03:51:26PM +0100, Sjoerd Mullender wrote:

On 08/01/2024 14.41, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Jan 08, 2024 at 10:02:55AM +0200, Panu Matilainen wrote:

On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney  wrote:


Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin



I agree unifying the *programs* to a single directory makes sense. But I
fail to see anything good come out of bringing all those system daemon
executables into every users path.


To clarify: they already *are* in every user's path, see
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin#Detailed_Description,
third para.


Not quite true: If you're using lightdm as display manager, the PATH is
initialized to /usr/local/bin:/usr/bin:/bin, at least on Fedora 39.


Please open a bug against lightdm ;)


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

--
Sjoerd Mullender
--
___
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 2257292] perl-CGI-4.61 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-CGI-4.61-1.fc40
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2024-01-10 10:00:25



--- Comment #2 from Fedora Update System  ---
FEDORA-2024-d2314b03db has been pushed to the Fedora 40 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=2257292

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202257292%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 2257292] perl-CGI-4.61 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202257292%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: Re: [heads-up] evolution-data-server libecal-2.0 soname version bump in rawhide

[Milan Crha]

On Tue, 2024-01-09 at 19:01 +0100, Kalev Lember wrote:
> The gnome-shell update just landed in rawhide, so it needs a few
> minutes before the build roots are regenerated. If you can do 'koji
> wait-repo f40-build-side-80962 --build mutter-46~alpha-2.fc40' first
> to make sure new mutter is available in the build roots, then it
> should be fine to rebuild.

Hi,
Frantisek sorted it out, I verified the gnome-shell had been built
against the mutter version you mentioned above. The update also landed
in rawhide shortly afterwards.
Bye,
Milan
--
___
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