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 availab
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 wr
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 down
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 b
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]
Prod
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 b
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]
Pr
https://bugzilla.redhat.com/show_bug.cgi?id=2257628
TEJ RATHI changed:
What|Removed |Added
Blocks||2257625 (CVE-2024-22368)
Referenced Bug
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 thei
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@list
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
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.fe
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
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
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:
htt
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
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 Jupy
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
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.
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
>
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.fedora
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
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
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
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:
> >
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
26 matches
Mail list logo
