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
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
On Sun, Nov 5, 2023 at 3:54 PM Samuel Sieb wrote:
>
> On 11/2/23 06:36, Christopher wrote:
> > On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi wrote:
> >>
> >> On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
> >>> It's also not clear when this option would take effect. Would it take
>
On 11/2/23 06:36, Christopher wrote:
On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi wrote:
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
It's also not clear when this option would take effect. Would it take
effect if I did `dnf install /path/to/local/file` or just when I did
no,
gt; > > > On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi wrote:
> > > > >
> > > > > FWIW, from what I can recall, yum used to check all packages, but this
> > > > > resulted in tons of people complaining because they did not want
On Thu, Nov 2, 2023 at 1:33 PM Brian C. Lane wrote:
>
> I think we should:
>
> * Switch the default local gpg check to true
> - this removes surprise when you learn you've been installing
> unchecked software for ... years? If they want it, it can be set
> back to false by the user.
>
On Tue, Oct 31, 2023 at 04:23:41PM +0100, Petr Pisar wrote:
> The nonchecking behavior probably exists to make installing local packages
> easy. If DNF5 would insist on checking the signatures, Fedora users would have
> to pass --no-gpgchecks option to their "dnf5" commands
gt;
> > > > FWIW, from what I can recall, yum used to check all packages, but this
> > > > resulted in tons of people complaining because they did not want it to
> > > > check their local packages. So, a localpkg_gpgcheck option was added and
> > > > se
On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi wrote:
>
> On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
> > On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi wrote:
> > >
> > > FWIW, from what I can recall, yum used to check all packages, but this
&g
to install a local file is for consistency of using the same
command as for repo packages, not manually altering the RPM database
outside of YUM/DNF (that results in a warning), and the expectation of
FWIW, dnf doesn't issue any silly warnings about rpm changing its own
database, that was a yum thing
V Tue, Oct 31, 2023 at 04:49:30PM -0700, Kevin Fenzi napsal(a):
> FWIW, from what I can recall, yum used to check all packages, but this
> resulted in tons of people complaining because they did not want it to
> check their local packages. So, a localpkg_gpgcheck option was added
On Wed, Nov 01, 2023 at 10:49:36AM -0700, Kevin Fenzi wrote:
> On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
> > On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi wrote:
> > >
> > > FWIW, from what I can recall, yum used to check all packages, but this
>
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
> On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi wrote:
> >
> > FWIW, from what I can recall, yum used to check all packages, but this
> > resulted in tons of people complaining because they did not want it to
>>>>> Christopher writes:
>> $ wget mypackage.rpm
>> $rpm --checksig mypackage.rpm
> the whole point of
> using DNF to install a local file is for consistency of using the same
> command as for repo packages, not manually altering the RPM databas
ackage.rpm
Yeah, that's why DNF is more convenient for this... the whole point of
using DNF to install a local file is for consistency of using the same
command as for repo packages, not manually altering the RPM database
outside of YUM/DNF (that results in a warning), and the expectation of
it performing the
On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi wrote:
>
> FWIW, from what I can recall, yum used to check all packages, but this
> resulted in tons of people complaining because they did not want it to
> check their local packages. So, a localpkg_gpgcheck option was added and
> set
e goes to different directory. See:
>
> $ rpm -qf /usr/share/licenses/llvm/LICENSE.TXT
> llvm-17.0.2-1.fc39.x86_64
> $ rpm -qf /usr/share/licenses/llvm-libs/LICENSE.TXT
> llvm-libs-17.0.2-1.fc39.x86_64
>
> llvm-libs-17.0.2-1.fc39.i686
>
> so license from llvm and llvm-lib
On Tue, 31 Oct 2023 12:48:31 -0400
Christopher wrote:
> I'm actually a bit concerned about this thread, because I assumed DNF4
> and DNF5 would check signatures by default today, and that it would
> only skip if `--nogpgcheck` was passed as an option. If it sometimes
> skips the GPG check without
-libs-17.0.2-1.fc39.i686
so license from llvm and llvm-libs should not never conflicts because the file
goes to different directory.
What can conflict is multilib packages in different version with different
content of the file.
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno
FWIW, from what I can recall, yum used to check all packages, but this
resulted in tons of people complaining because they did not want it to
check their local packages. So, a localpkg_gpgcheck option was added and
set to false. dnf4 still has this option.
It's also worth noting that if you pass
> > > <https://github.com/rpm-software-management/dnf5/issues/991> that
> "dnf update
> > > https://...; skips verifying package signatures:
> > >
> > > $ sudo dnf update
> https://kojipkgs.fedoraproject.org//packages/gnome
On Tue, 31 Oct 2023 16:23:41 +0100
Petr Pisar wrote:
> I would would like to hear your opinion: Should DNF5 start verifying
> all packages? Should DNF5 keep ignoring signatures for
> out-of-repository packages? Or should rather narrow the verification
> skip to packages from a local
gt; > https://...; skips verifying package signatures:
> >
> > $ sudo dnf update
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> >
> > https://kojipkgs.fedoraproject.or
Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a):
Hello,
DNF5 got a complaint
<https://github.com/rpm-software-management/dnf5/issues/991> that "dnf update
https://...; skips verifying package signatures:
$ sudo dnf update
https://kojipkgs.fedoraproject.org//packages/gnome-con
On Tue, Oct 31, 2023 at 5:47 PM Miroslav Suchý wrote:
> How it conflicts?
>
> %files
>
> %license LICENSE
>
> %files doc
>
> %license LICENSE
>
> should not create any conflicts. And this is recomended way to do it.
>
I guess the conflicts happen when the LICENSE file changes between builds
and
t;https://github.com/rpm-software-management/dnf5/issues/991> that "dnf
> > > update
> > > https://...; skips verifying package signatures:
> > >
> > > $ sudo dnf update
> > > https://kojipkgs.fedoraproject.org//packages/gnome-contr
Dne 31. 10. 23 v 16:10 Tom Stellard napsal(a):
Hi,
I've run into a problem with the cmake package, and I'm trying to figure out how
to solve it. This issue is that the cmake license files are included in both
the cmake and cmake-doc packages. This creates a conflict when up trying to
update
t; update
> > https://...; skips verifying package signatures:
> >
> > $ sudo dnf update
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> >
> > https://koji
On Tue, Oct 31, 2023 at 4:24 PM Petr Pisar wrote:
>
> Hello,
>
> DNF5 got a complaint
> <https://github.com/rpm-software-management/dnf5/issues/991> that "dnf update
> https://...; skips verifying package signatures:
>
> $ sudo dnf update
> https://koji
Hello,
DNF5 got a complaint
<https://github.com/rpm-software-management/dnf5/issues/991> that "dnf update
https://...; skips verifying package signatures:
$ sudo dnf update
https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x
On Tue, Oct 31, 2023 at 11:10 AM Tom Stellard wrote:
>
> Hi,
>
> I've run into a problem with the cmake package, and I'm trying to figure out
> how
> to solve it. This issue is that the cmake license files are included in both
> the cmake and cmake-doc packages. This creat
Hi,
I've run into a problem with the cmake package, and I'm trying to figure out how
to solve it. This issue is that the cmake license files are included in both
the cmake and cmake-doc packages. This creates a conflict when up trying to
update cmake while an older version of cmake-doc
On Thu, 2023-10-19 at 18:43 +0200, Frantisek Zatloukal wrote:
> On Thu, Oct 19, 2023 at 6:24 PM Adam Williamson
> wrote:
>
> > I'm not sure I have time to take this, but glancing over it, I have a
> > suggestion on how to further automate the release stuff.
> >
> > You can use Bodhi release
On Thu, Oct 19, 2023 at 6:24 PM Adam Williamson
wrote:
> I'm not sure I have time to take this, but glancing over it, I have a
> suggestion on how to further automate the release stuff.
>
> You can use Bodhi release date to determine the extant EPEL releases
> and the current Branched release.
> Every branching, the script needs (trivial) changes.
>
> When I see packages orphaned for 6+ weeks, I retire them.
>
>
> I took this task a coupe years back because I was not satisfied with the
> status
> quo at that time (packages orphaned for year+ lingering in the d
Every branching, the script needs (trivial) changes.
>
> When I see packages orphaned for 6+ weeks, I retire them.
>
>
> I took this task a coupe years back because I was not satisfied with the
> status
> quo at that time (packages orphaned for year+ lingering in the distro).
>
t;
> Every branching, the script needs (trivial) changes.
>
> When I see packages orphaned for 6+ weeks, I retire them.
>
>
> I took this task a coupe years back because I was not satisfied with
> the status
> quo at that time (packages orphaned for year+ lingering in the
the output and whenever it is stuck, I restart it.
Every 2 weeks I try to save a copy of the generated file and send it to
the devel list, devel announce list and the affected maintainers.
Every branching, the script needs (trivial) changes.
When I see packages orphaned for 6+ weeks, I retire
On 19-10-2023 11:06, Miro Hrončok wrote:
I can provide all the details about the operation if you want to become
the reaper's apprentice.
A reaper by the name of Churchyard! ⚰️
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
it is stuck, I restart it.
Every 2 weeks I try to save a copy of the generated file and send it to the
devel list, devel announce list and the affected maintainers.
Every branching, the script needs (trivial) changes.
When I see packages orphaned for 6+ weeks, I retire them.
I took this task
Could someone (perhaps someone interested in Hyprland) please review:
hyprland-protocols - https://bugzilla.redhat.com/show_bug.cgi?id=2244285
hyprland - https://bugzilla.redhat.com/show_bug.cgi?id=2244377
xdg-desktop-portal-hyprland -
https://bugzilla.redhat.com/show_bug.cgi?id=2244378
I'd
On 10/16/23 00:20, Peter Boy wrote:
Sorry for top posting. But my question doesn’t fit to a specific post. And I
don’t like to contribute to getting off-topic. But ...
I followed the thread and various similar discussions closely. My question is:
Who is really suffering from the famous „June
Sorry for top posting. But my question doesn’t fit to a specific post. And I
don’t like to contribute to getting off-topic. But ...
I followed the thread and various similar discussions closely. My question is:
Who is really suffering from the famous „June decision“ of Red Hat? I don’t get
it.
done - thanks for stepping up Mikel
On 07/10/2023 15:16, Mikel Olasagasti wrote:
Hi Mark,
Hau idatzi du Mark E. Fuller (ful...@fedoraproject.org) erabiltzaileak
(2023 urr. 7(a), lr. (12:22)):
>
> Hi all,
>
> I picked up a number of prometheus packages (see below) a few months
&
Hi Mark,
Hau idatzi du Mark E. Fuller (ful...@fedoraproject.org) erabiltzaileak
(2023 urr. 7(a), lr. (12:22)):
>
> Hi all,
>
> I picked up a number of prometheus packages (see below) a few months
> back during the golang scramble after an unresponsive maintainer.
> I d
Hi all,
I picked up a number of prometheus packages (see below) a few months
back during the golang scramble after an unresponsive maintainer.
I don't have the time or the interest (or the technical chops) to
maintain them.
Obviously these are important packages, so at this time I am
and why the
> > people
> > are so afraid of use Centos Stream version instead .
>
>
> I can only answer for me, but the main reason to avoid Stream on real
> Hardware (I use it on virtual Maschines) is the missing support for
> elrepo.org kmod packages [1].
>
real
Hardware (I use it on virtual Maschines) is the missing support for
elrepo.org kmod packages [1].
After RedHat dropped support for so many hardware, especially in EL9
[2], it is hard to run on older / unsupported hardware without the help
of elrepo.
CU
Jens
[1] https://elrepo.org/tiki/About#What
the missing support for
elrepo.org kmod packages [1].
After RedHat dropped support for so many hardware, especially in EL9
[2], it is hard to run on older / unsupported hardware without the help
of elrepo.
CU
Jens
[1] https://elrepo.org/tiki/About#What_is_ELRepo_
"ELRepo packages are not compatib
Notification time stamped 2023-10-05 01:23:49 UTC
From 4e577520b04b10e9f5c557655d2bff9d6bf86805 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: Jun 03 2022 10:23:39 +
Subject: Perl 5.36 re-rebuild of bootstrapped packages
---
diff --git a/perl-Mail-Message.spec b/perl-Mail
Ouch. I swear, I wanted to check if you're still interested in
maintaining RBTools. Just slipped my mind when I saw that the packages
are in process of being dropped from f39 :(
I can add you as an admin when the unretirement is processed.
On Wed, Oct 4, 2023 at 4:48 PM Jonathan Wright via devel
gt; python-pydiffxorphan 2
> weeks ago
>
> Somehow I missed the retirement of these two packages (can we have
> nice 'will be retired in a week' emails for the FTI process as well,
> please?).
> I need to keep these alive, and it took two small patches to
On Mon, Sep 25, 2023 at 5:00 AM Miro Hrončok wrote:
> RBTools orphan 2 weeks ago
> python-pydiffxorphan 2 weeks ago
Somehow I missed the retirement of these two packages (can we hav
It is sad to see you go, but I see your point why you are doing this.
Thank you for all your work on git package, it was great collaborating with
you.
All the best,
On Tue, Oct 3, 2023 at 4:25 PM Todd Zullinger wrote:
> Hi,
>
> I'm orphaning all my packages (which I effectively did
On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote:
> Am 03.10.23 um 20:46 schrieb Sérgio Basto:
> > On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
> > > On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
> > >
> > > wrote:
> > > > Additionally *all* of the code is
Because when they ask “where is the code?”, they are asking a different
question than yours :)
Regards,
Carlos
On Tue, Oct 3, 2023 at 2:30 PM Simo Sorce wrote:
> On Tue, 2023-10-03 at 23:13 +0200, Leon Fauster via devel wrote:
> > Am 03.10.23 um 21:29 schrieb Simo Sorce:
> > > On Tue,
Leon,
I don't think this has ever been about whether a piece of code is
present in version 8 (using your example), but about the free (gratis)
availability of the combination of version 7 with selected backports
from version 8 that has been thoroughly tested by RedHat teams and their
On Tue, 2023-10-03 at 23:13 +0200, Leon Fauster via devel wrote:
> Am 03.10.23 um 21:29 schrieb Simo Sorce:
> > On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote:
> > > Am 03.10.23 um 20:46 schrieb Sérgio Basto:
> > > > On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
> >
Am 03.10.23 um 21:29 schrieb Simo Sorce:
On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote:
Am 03.10.23 um 20:46 schrieb Sérgio Basto:
On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
wrote:
Additionally *all* of
On Tue, Oct 03, 2023 at 04:36:20PM +0200, Michael J Gruber wrote:
> Thank you for all the effort you have put into maintaining these
> packages so far, for the benefit of all of Fedora, and consequently
> its downstream!
Indeed -- thank you Todd.
--
Matthew Miller
Fedora Proje
On Tue, Oct 3 2023 at 03:32:36 PM -0400, Solomon Peachy via devel
wrote:
However, this has _always_ been the situation for RHEL. Only the
sources for the _latest_ point release (eg RHEL 7.4) were ever made
available to the general public; updates/fixes backported to prior
versions (eg RHEL
On Tue, Oct 3 2023 at 02:23:34 PM -0400, Stephen Gallagher
wrote:
The *exact* set of source code that the package was built for is
included in the Source RPM and all of the individual changes that
comprised it are part of the c9s branch in CentOS Stream (or the
maintainer has been regressing
On Tue, Oct 3 2023 at 07:46:58 PM +0100, Sérgio Basto
wrote:
it is here :
https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9
Well OK yes, but that only worked because my example was from before we
stopped publishing sources to git.centos.org.
On Tue, Oct 03, 2023 at 08:50:53PM +0200, Leon Fauster via devel wrote:
> If a bumped version of a package fixes an issue (stream variant of
> CentOS) e.g 2.2, and a released package (rhel variant) has a
> backported fix for e.g. 2.1, that doesn't mean that the code is also
> in the stream git
On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote:
> Am 03.10.23 um 20:46 schrieb Sérgio Basto:
> > On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
> > > On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
> > > wrote:
> > > > Additionally *all* of the code is fully
Am 03.10.23 um 20:46 schrieb Sérgio Basto:
On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
wrote:
Additionally *all* of the code is fully available in git form on
gitlab
as part of CentOS Stream.
We all know or should know that
Am 03.10.23 um 20:23 schrieb Stephen Gallagher:
On Tue, Oct 3, 2023 at 2:14 PM Michael Catanzaro wrote:
On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
wrote:
Additionally *all* of the code is fully available in git form on
gitlab
as part of CentOS Stream.
We all know or should know
On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
> On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
> wrote:
> > Additionally *all* of the code is fully available in git form on
> > gitlab
> > as part of CentOS Stream.
>
> We all know or should know that this is false. It's easy
On Tue, Oct 3, 2023 at 2:14 PM Michael Catanzaro wrote:
>
> On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
> wrote:
> > Additionally *all* of the code is fully available in git form on
> > gitlab
> > as part of CentOS Stream.
>
> We all know or should know that this is false. It's easy
On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
wrote:
Additionally *all* of the code is fully available in git form on
gitlab
as part of CentOS Stream.
We all know or should know that this is false. It's easy enough to
disprove with a counterexample:
On Tue, 2023-10-03 at 11:33 -0400, Todd Zullinger wrote:
> Sérgio Basto wrote:
> > On Tue, 2023-10-03 at 10:25 -0400, Todd Zullinger wrote:
> > > a project
> > > where the primary sponsor and downstream no longer provides
> > > source code freely and openly
> >
> > what you are talking about ?
Am 03.10.23 um 17:33 schrieb Todd Zullinger:
Sérgio Basto wrote:
On Tue, 2023-10-03 at 10:25 -0400, Todd Zullinger wrote:
a project
where the primary sponsor and downstream no longer provides
source code freely and openly
what you are talking about ? all RHEL Source are freely available on
Sérgio Basto wrote:
> On Tue, 2023-10-03 at 10:25 -0400, Todd Zullinger wrote:
>> a project
>> where the primary sponsor and downstream no longer provides
>> source code freely and openly
>
> what you are talking about ? all RHEL Source are freely available on
> Centos Stream , and RHEL never was
On Tuesday, October 3, 2023 9:32:17 AM CDT Jonathan Wright via devel wrote:
> I've picked up git and paperkey.
>
> On Tue, Oct 3, 2023 at 9:25 AM Todd Zullinger wrote:
> > Hi,
> >
> > I'm orphaning all my packages (which I effectively did
> > months ago). It's
On Tue, 2023-10-03 at 10:25 -0400, Todd Zullinger wrote:
> a project
> where the primary sponsor and downstream no longer provides
> source code freely and openly
what you are talking about ? all RHEL Source are freely available on
Centos Stream , and RHEL never was free .
--
Sérgio M. B.
t 10:25:40 a.m. EDT, Todd Zullinger
wrote:
Hi,
I'm orphaning all my packages (which I effectively did
months ago). It's been fun being a maintainer since 2006.
However, I am not interested in contributing to a project
where the primary sponsor and downstream no longer provides
source c
Hi,
Michael J Gruber wrote:
> Thank you for all the effort you have put into maintaining these
> packages so far, for the benefit of all of Fedora, and consequently
> its downstream!
Thanks!
> Your reasons resonate with me, though I'm not taking the same
> conclusions. Ha
Am Di., 3. Okt. 2023 um 16:25 Uhr schrieb Todd Zullinger :
>
> Hi,
>
> I'm orphaning all my packages (which I effectively did
> months ago). It's been fun being a maintainer since 2006.
>
> However, I am not interested in contributing to a project
> where the primar
I've picked up git and paperkey.
On Tue, Oct 3, 2023 at 9:25 AM Todd Zullinger wrote:
> Hi,
>
> I'm orphaning all my packages (which I effectively did
> months ago). It's been fun being a maintainer since 2006.
>
> However, I am not interested in contributing to a project
&
Hi,
I'm orphaning all my packages (which I effectively did
months ago). It's been fun being a maintainer since 2006.
However, I am not interested in contributing to a project
where the primary sponsor and downstream no longer provides
source code freely and openly. It's simply not consistent
Hi,
I'm orphaning the following llvm, clang, and lld compat packages:
llvm12, llvm13
clang11, clang13
lld13
-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code
On 02. 10. 23 15:03, Sandro wrote:
On 27-09-2023 11:56, Miro Hrončok wrote:
here is the list of packages that still need a Python 3.12 rebuild for Fedora
39+.
Not mentioned on the list, but still pending, is the update for spyder.
It's not mentioned because it does not need a Python 3.12
On 02. 10. 23 15:03, Sandro wrote:
On 27-09-2023 11:56, Miro Hrončok wrote:
here is the list of packages that still need a Python 3.12 rebuild for Fedora
39+.
Not mentioned on the list, but still pending, is the update for spyder.
It's not mentioned because it does not need a Python 3.12
On 27-09-2023 11:56, Miro Hrončok wrote:
here is the list of packages that still need a Python 3.12 rebuild for
Fedora 39+.
Not mentioned on the list, but still pending, is the update for spyder.
That's finally ready now the last of the dependencies has been updated.
However, it's a bit
On 27-09-2023 11:56, Miro Hrončok wrote:
here is the list of packages that still need a Python 3.12 rebuild for
Fedora 39+.
Not mentioned on the list, but still pending, is the update for spyder.
That's finally ready now the last of the dependencies has been updated.
However, it's a bit
On 30-09-2023 02:16, Jonathan Steffan wrote:
supervisor in fedora 39 is 4.2.2 but the version that supports python
3.12 is 4.2.5. I filed Bug 2239529 about this and have received no
response.
I've updatedhttps://bugzilla.redhat.com/show_bug.cgi?id=2239529 with links
to an updated Rawhide
On Wed, Sep 27, 2023 at 2:28 PM Dulaney wrote:
> On Sep 27, 2023 aig 11:56:01AM +0200, sgrìobh Miro Hrončok:
> > Hello packagers,
> > here is the list of packages that still need a Python 3.12 rebuild for
> Fedora 39+.
> >
>
> supervisor in fedora 39 is 4.2.2 but th
On Wed, 2023-09-27 at 11:56 +0200, Miro Hrončok wrote:
> Hello packagers,
> here is the list of packages that still need a Python 3.12 rebuild
> for Fedora 39+.
>
> Packages on this list have broken dependencies and hence the users of
> Fedora
> Linux 39+ cannot install th
Hey
On 2023-09-27 11:56, Miro Hrončok wrote:
Hello packagers,
here is the list of packages that still need a Python 3.12 rebuild for
Fedora 39+.
Thanks for the reminder
sdyroffpython-ansi
I retired this package for rawhide and f39. As this was my first
retirement :) please let me
On Sep 27, 2023 aig 11:56:01AM +0200, sgrìobh Miro Hrončok:
> Hello packagers,
> here is the list of packages that still need a Python 3.12 rebuild for Fedora
> 39+.
>
supervisor in fedora 39 is 4.2.2 but the version that supports python
3.12 is 4.2.5. I filed Bug 2239529 about t
On Wed, 2023-09-27 at 09:48 -0500, Ian Pilcher wrote:
> On 9/27/23 04:56, Miro Hrončok wrote:
> > fail2ban
> >
> > https://bugzilla.redhat.com/2219991
> > https://github.com/fail2ban/fail2ban/issues/3487
> > Bugzilla ASSIGNED 2 months ago, no update since.
> > Maintainers NEEDINFOed last
On Wed, Sep 27, 2023 at 09:48:04AM -0500, Ian Pilcher wrote:
> On 9/27/23 04:56, Miro Hrončok wrote:
> > fail2ban
> >
> > https://bugzilla.redhat.com/2219991
> > https://github.com/fail2ban/fail2ban/issues/3487
>
> With my system/network administrator hat on, this one is really
>
On 9/27/23 04:56, Miro Hrončok wrote:
fail2ban
https://bugzilla.redhat.com/2219991
https://github.com/fail2ban/fail2ban/issues/3487
Bugzilla ASSIGNED 2 months ago, no update since.
Maintainers NEEDINFOed last week.
With my system/network administrator hat on, this one is really
On 27. 09. 23 15:58, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Sep 27, 2023 at 11:56:01AM +0200, Miro Hrončok wrote:
Hello packagers,
here is the list of packages that still need a Python 3.12 rebuild for Fedora
39+.
zbyszekpython-igor
I retired it now in f39 and rawhide. The first
On 27. 09. 23 15:58, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Sep 27, 2023 at 11:56:01AM +0200, Miro Hrončok wrote:
Hello packagers,
here is the list of packages that still need a Python 3.12 rebuild for Fedora
39+.
zbyszekpython-igor
I retired it now in f39 and rawhide. The first
On Wed, Sep 27, 2023 at 11:56:01AM +0200, Miro Hrončok wrote:
> Hello packagers,
> here is the list of packages that still need a Python 3.12 rebuild for Fedora
> 39+.
> zbyszekpython-igor
I retired it now in f39 and rawhide. The first attempt failed halfway
because I didn't
On Wed, Sep 27, 2023 at 11:56:01AM +0200, Miro Hrončok wrote:
> Hello packagers,
> here is the list of packages that still need a Python 3.12 rebuild for Fedora
> 39+.
> zbyszekpython-igor
I retired it now in f39 and rawhide. The first attempt failed halfway
because I didn't
Hello packagers,
here is the list of packages that still need a Python 3.12 rebuild for Fedora
39+.
Packages on this list have broken dependencies and hence the users of Fedora
Linux 39+ cannot install them at all.
Moreover, users of Fedora Linux 37 or 38 with the listed packages installed
On 27. 09. 23 12:49, Fabio Valentini wrote:
On Wed, Sep 27, 2023 at 11:56 AM Miro Hrončok wrote:
python-rust-update-set
==
https://bugzilla.redhat.com/2220488
Bugzilla ASSIGNED 2 months ago, no update since.
Maintainer NEEDINFOed last week.
That NEEDINFO won't help, the
On Wed, Sep 27, 2023 at 11:56 AM Miro Hrončok wrote:
>
> python-rust-update-set
> ==
> https://bugzilla.redhat.com/2220488
> Bugzilla ASSIGNED 2 months ago, no update since.
> Maintainer NEEDINFOed last week.
That NEEDINFO won't help, the maintainer apparently sends bugzilla
301 - 400 of 13319 matches
Mail list logo
