I vaguely remember that pipenv retirement was briefly discussed here on
the ML, yet I was surprised that F40 doesn't have pipenv anymore.
IMO, this would have been announced more prominently as a self contained
change, as I expect more python developers to find out this too late.
Also, the offi
On Mon, Apr 29, 2024 at 12:20:37PM GMT, Brian C. Lane wrote:
> I screwed up the isomd5sum checksums in the 1.2.4 release while trying
> to fix support for small isos. I've reverted the change and 1.2.4-2 is
> building for rawhide and Fedora 40. Thanks to Jonathan Billings for the
> bug report (http
=
# #meeting:fedoraproject.org: fesco
=
Meeting started by @mhayden:fedora.im at 2024-04-29 19:00:56
Meeting summary
---
* TOPIC: Init Process (@mhayden:fedora.im, 19:01:17)
* TOPIC: #3198 Request to update Kube
In one week (2024-05-06), or slightly later, I plan to update the
rapidyaml package to 0.6.0[1] and the c4core package to 0.2.0[2] in
F41/Rawhide. This includes an SONAME version bump in both cases, with
specific breaking changes documented in the upstream release
notes[3][4]. An impact check i
I screwed up the isomd5sum checksums in the 1.2.4 release while trying
to fix support for small isos. I've reverted the change and 1.2.4-2 is
building for rawhide and Fedora 40. Thanks to Jonathan Billings for the
bug report (https://bugzilla.redhat.com/show_bug.cgi?id=2277398).
The bad version ma
On Mon, Apr 29, 2024 at 4:38 PM Vitaly Zaitsev via devel
wrote:
> Both of my LLVM dependent packages: iwyu and pocl. On every LLVM major
> release they break and I have to wait for the upstream to release a new
> version.
I would hope that there are more examples than O(1),
as processes should n
Neal Gompa writes:
> You also have to do new package
> reviews for each new version instead of using the compatibility
> package exception to branch older releases into compatibility
> packages.
I don't think this will be needed because it is one of the exceptions [1]:
The package is being
On 29/04/2024 16:41, Gary Buhrmaster wrote:
Do we have any idea how many code bases are
actually sensitive to the specific llvm version?
Both of my LLVM dependent packages: iwyu and pocl. On every LLVM major
release they break and I have to wait for the upstream to release a new
version.
--
On Mon, Apr 29, 2024 at 2:25 PM Tulio Magno Quites Machado Filho
wrote:
> Considering that LLVM releases usually happen very late in Fedora's
> development cycle, if the default LLVM version is changed, packages may
> start to FTBFS very late in the development cycle if they buildrequire
> the de
Nico Kadel-Garcia writes:
> On Sat, Apr 27, 2024 at 12:35 AM Tom Stellard wrote:
>> * Invert the order of compat/main packages. Instead of having the compat
>> package be
>> the old version, and the main package be the new version, we would have the
>> compat package
>> be newer and the main
* Stephen Smoogen:
> I guess we need to see what RPM owns that symlink and get it into the
> build root
Sorry, I meant $RPM_BUILDROOT or %buildroot (the staging area used by
rpmbuild). That's not controlled by the system package manager,
obviously.
Thanks,
Florian
> On Mon, Apr 29, 2024 at 08:
Hi Adam,
> Just to follow up on this: the Kiwi container build test failure
> pointed to some changes that will be required to the Fedora kiwi config
> when this change lands. I have filed a PR for that -
> https://pagure.io/fedora-kiwi-descriptions/pull-request/46 - which
> should only be merged
OLD: Fedora-Rawhide-20240428.n.0
NEW: Fedora-Rawhide-20240429.n.0
= SUMMARY =
Added images:2
Dropped images: 2
Added packages: 0
Dropped packages:0
Upgraded packages: 24
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size
Following is the list of topics that will be discussed in the
FESCo meeting Monday at 19:00 UTC in #meeting:fedoraproject.org
on Matrix.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2024-04-29 19:00 UTC'
Links to all issues to be d
On Mon, Apr 29, 2024 at 3:31 PM Stephen Smoogen wrote:
>
> I guess we need to see what RPM owns that symlink and get it into the build
> root
>
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle. --
> Ian MacClaren
>
>
> On Mon, Apr 2
I guess we need to see what RPM owns that symlink and get it into the build
root
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
On Mon, Apr 29, 2024 at 08:22 Florian Weimer wrote:
> * Richard W. M. Jones:
>
> >> I
* Richard W. M. Jones:
>> I don't want us to have RPM spec file hacks just to get RISC-V to
>> install in the correct locations. The symbolic link evidently does not
>> cover all cases.
>
> What cases aren't covered by the symlink? We have a full, working
> Fedora/RISC-V distro using it at the m
On Mon, Apr 29, 2024 at 11:44 AM Fabio Valentini wrote:
> No, this will make a Release like 2.1.fc40 - which is not what's
> needed (which would be 1.fc40.1).
> So it doesn't work because -e adds a component *before* the dist-tag,
> *and* because the main number is still incremented.
Since [.min
On Mon, Apr 29, 2024 at 11:35 AM Richard W.M. Jones wrote:
>
> On Sun, Apr 28, 2024 at 10:27:26AM +0200, Julian Sikorski wrote:
>
> > I know this is just a cosmetic issue, but choices made by the
> > primary maintainers should be respected IMO.
>
> I agree in general, but sometimes if you're makin
On Mon, Apr 29, 2024 at 1:28 PM Richard W.M. Jones wrote:
>
> On Sat, Apr 27, 2024 at 10:41:59PM +0200, Julian Sikorski wrote:
> > Hello,
> >
> > I need to rebuild mame on F40 only for qt-6.7. On rawhide,
> > mame-0.265-1.fc41 is already built against it so I only need to
> > build mame-0.265-1.fc
On Sun, Apr 28, 2024 at 10:27:26AM +0200, Julian Sikorski wrote:
> Hello,
>
> is there a general recommendation regarding keeping git release
> branches separate vs merged? I have been keeping mine separate.
> Originally to avoid release and changelog conflicts when
> cherry-picking, but I got use
On Sat, Apr 27, 2024 at 10:41:59PM +0200, Julian Sikorski wrote:
> Hello,
>
> I need to rebuild mame on F40 only for qt-6.7. On rawhide,
> mame-0.265-1.fc41 is already built against it so I only need to
> build mame-0.265-1.fc40.1. Can it be done using %autorelease?
I don't think anyone answered
Fabio Valentini wrote:
> No, that's just wrong.
> The "upgrade path" (wrt/ NVRs) is no longer enforced across release
> boundaries. AFAIK, all supported release-upgrade methods now use
> distro-sync or something equivalent, so NVR-based "upgrade path" is just
> not important any more.
That just do
> On 04/24/2024 4:21 PM CEST Remi Collet wrote:
>
> I can probably help for PHP reviews
Thank you, appreciated!
> Notice:
>
> - php-ralouphie-getallheaders: this is a compat layer providing a
> missing function in PHP < 7.3 for php-fpm users
>
> Please check you really still need it ;)
Goo
On Mon, Apr 29, 2024 at 11:17 AM Kevin Kofler via devel
wrote:
>
> Michael J Gruber wrote:
> > A minor bump (as in %{?dist}[.]) only comes into play
> > if a "lower" branch needs to move forward without creating a version
> > ahead of a "higher" branch. And (independent of autorelease) you cannot
Michael J Gruber wrote:
> A minor bump (as in %{?dist}[.]) only comes into play
> if a "lower" branch needs to move forward without creating a version
> ahead of a "higher" branch. And (independent of autorelease) you cannot
> do that unless you use divergent git branches and cherry-picks in
> dist
Kevin Kofler via devel venit, vidit, dixit 2024-04-28 23:55:37:
> Julian Sikorski wrote:
> > I need to rebuild mame on F40 only for qt-6.7. On rawhide,
> > mame-0.265-1.fc41 is already built against it so I only need to build
> > mame-0.265-1.fc40.1. Can it be done using %autorelease?
>
> No, whic
27 matches
Mail list logo
