-existing-packages/#_public_domain_or_ultrapermissive
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_licenseref_kde_accepted
https://docs.fedoraproject.org/en-US/legal/license-review-process/ (note about
funny licenses being treated seriously)
- kernel was documented as
Hello,
I am writing this message to get feedback from the community on new
findings by static analyzers in Critical Path Packages that have
changed in Fedora 43.
TLDR: This report[1] contains a total of 54975 findings and 1732 new
findings identified since Fedora 42. Please review the report and
On 2025-01-23 10:30, Miro Hrončok wrote:
marker atim
I wish I would have noticed this; started un-retirement process, review
request: https://bugzilla.redhat.com/show_bug.cgi?id=2362370
-Tomi
--
___
devel mailing list -
devel-announce
wrote:
> Report started at 2025-04-20 22:00:03 UTC
>
> 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 pr
Report started at 2025-04-20 22:00:03 UTC
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
On Sunday, March 23, 2025 10:12:09 AM Central Daylight Time maxwell--- via
devel-announce wrote:
> IMPORTANT NOTE: I forgot to process the orphaned packages and send the
> report that was due the second week of March, so some packages have been
> orphaned for more than six weeks but
On 2025-04-18 18:59, Sérgio Basto via devel wrote:
Hi,
I need to reduce my workload
so some packages with impact but I have nothing to do with it:
- bc
- gflags
- gperf
I've picked these up, thanks!
Cheers
Davide
--
___
devel mailing list --
On Fri, Apr 18, 2025 at 10:01 PM Sérgio Basto via devel
wrote:
>
> Hi,
> I need to reduce my workload
>
[...]
>
[...]
> - libcomps
> - atf
> - libphonenumber
>
[...]
>
> - tofrodos
> - smb4k
>
Thanks for maintaining them, I grabbed these as I need/use them in
various contexts.
--
真実はいつも一つ！/ Al
Hi,
I need to reduce my workload
so some packages with impact but I have nothing to do with it:
- bc
- gflags
- gperf
- libcomps
- atf
- libphonenumber
Package that I don't use anymore or obsoleted :
- tofrodos
- rawstudio
- smb4k
Package that give to much work ;
- ogre
Best re
l path from F41 to maintain
compatibility. I did that in systemd:
https://src.fedoraproject.org/rpms/systemd/c/6f0d03443d2f5695e05146e3bd17f6dab84ab459.
> I presume it's too late todo anything about this now, so this mail
> is mostly a heads up in case other maintainers have packages aff
t I've just discovered an unanticipated consequence
of this difference between upgraded & fresh Fedora installs, that is
worth pointing out, as it would affect other packages.
When building in Koji, /sbin & /usr/sbin are symlinks to /usr/bin.
In meson.build libvirt searchs for a bunch o
Hi,
On 15-Apr-25 13:20, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
>
> When a system is _upgraded_ to F42, we try to "merge", by making
> /usr/sbin a symlink to /usr/bin. This is blocked when a package lists
> files under /usr/sbin. It'd be great to rebuild/update
On Tue, Apr 15, 2025 at 11:20:29AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
>
> When a system is _upgraded_ to F42, we try to "merge", by making
> /usr/sbin a symlink to /usr/bin. This is blocked when a package lists
> files under /usr/sbin. It'd be great to
7;d be great to rebuild/update those packages,
> so that the upgraded systems reach the intended state and look the
> same as new installations. (For new installations, /usr/sbin is always
> a symlink.)
>
> On f42, repoquery gives the following list of packages:
> soundmodem-0:0
Hi,
When a system is _upgraded_ to F42, we try to "merge", by making
/usr/sbin a symlink to /usr/bin. This is blocked when a package lists
files under /usr/sbin. It'd be great to rebuild/update those packages,
so that the upgraded systems reach the intended state and look
Report started at 2025-04-10 01:00:46 UTC
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
Miroslav Suchý writes:
...
> Packages that are neither in SPDX nor in Callaway format (highest
> priority for now) - 32 packages:
>
> https://pagure.io/copr/license-validate/blob/main/f/neither-nor-remaining-packagers.txt
>
> Most of such packages has open issue in fedora-lice
Hi everyone,
I would like to unretire and take ownership of following packages:
* datanommer-commands -
https://src.fedoraproject.org/rpms/datanommer-commands
* python-datanommer-models -
https://src.fedoraproject.org/rpms/python-datanommer-models
I already have bugzilla review tickets open
Dne 02. 04. 25 v 12:30 odp. Daniel P. Berrangé napsal(a):
Even after that is merged, I would have though 'license-validate' is still
going to report an invalid expression, because BSD-3-Clause-Clear is not a
permitted license, and license-validate doesn't know the package name & thus
can't proces
On Mon, Mar 31, 2025 at 03:30:50PM +0200, Miroslav Suchý wrote:
> Dne 31. 03. 25 v 2:14 odp. Vitaly Kuznetsov napsal(a):
> > Miroslav Suchý writes:
> >
> > ...
> >
> > > Packages that are neither in SPDX nor in Callaway format (highest
> > > priori
Dne 31. 03. 25 v 2:14 odp. Vitaly Kuznetsov napsal(a):
Miroslav Suchý writes:
...
Packages that are neither in SPDX nor in Callaway format (highest
priority for now) - 32 packages:
https://pagure.io/copr/license-validate/blob/main/f/neither-nor-remaining-packagers.txt
Most of such packages
- Richard and I are meeting every week and we started
working together on old and painfull issues.
Five weeks ago we had:
* 24379 spec files in Fedora
* 31024license tags in all spec files
* 123 tags are not SPDX compliant (number from line bellow minus packages with
LicenseRef-Callaway
Hello,
according to step 10 of
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs
I am supposed to orphan+retire the following packages from Fedora 42+ today:
golang-github-aclements-gg
php-guzzlehttp
IMPORTANT NOTE: I forgot to process the orphaned packages and send the report
that was due the second week of March, so some packages have been orphaned for
more than six weeks but were not announced as usual. I will wait until
Wednesday to retire the remaining packages orphaned for 6+ weeks
According to Fedora packaging guidelines, building Java documentation
(-javadoc) packages is now optional. It was previously mandatory,
then recommended, and is now left entirely to the maintainer's
discretion.
As the primary maintainer of many Java packages, I have decided to
obsolet
On Wed, Feb 26, 2025 at 08:10:20AM -0800, Davide Cavalca wrote:
> On 2025-02-24 17:33, maxw...@gtmx.me wrote:
> > simh orphan 0
> > weeks ago
>
> I picked this up and somewhat coaxed it into building again, but I'd be
> happy to have some co-m
On 2025-02-24 17:33, maxw...@gtmx.me wrote:
simh orphan 0
weeks ago
I picked this up and somewhat coaxed it into building again, but I'd be
happy to have some co-maintainers if anybody's interested.
Cheers
Davide
--
_
On Tuesday, 25 February 2025 at 02:33, maxw...@gtmx.me wrote:
> Report started at 2025-02-25 01:00:06 UTC
>
> 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 sh
Hey there,
After doing my best to maintain Google Cloud's packages in Fedora, I'd
like to give up these packages to someone who could spend more time
maintaining them. I don't use Google Cloud in my daily work and these
packages move quickly. Some of the agents now depend on
Hot news:
- the review of licenses in queue has been stalled for several weeks
Two weeks ago we had:
* 24347spec files in Fedora
* 30986license tags in all spec files
* 127 tags are not SPDX compliant (number from line bellow minus packages with
LicenseRef-Callaway-*)
* 2246tags have not
On Mon, 2025-02-10 at 10:36 +0100, Milan Crha wrote:
> I believe it's time to retire the MAPI protocol in Fedora. I'll wait
> with the orphan for one week.
Hi,
as announced the last week, I just orphaned evolution-mapi and
openchange packages in the Fedora (I clicked the
Mikel Olasagasti wrote:
> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current guidelines [2].
I am opposed to this. Bundli
On Mon, 2025-02-10 at 11:58 +0100, Alexander Bokovoy wrote:
> Could you please rebuild them in f43-build-side-105065 and f42-build-
> side-105181?
Hi,
sure, I can do it.
Bye,
Milan
--
___
devel mailing list -- devel@lists.fedora
On Mon, 2025-02-10 at 11:10 +0100, Peter Robinson wrote:
> It might be better off to directly retire them rather than orphan
> them if no one expresses a requirement for them.
Hi,
sure, I'm not against it, though when I looked into
https://src.fedoraproject.org/rpms/openchange
it offered m
On Пан, 10 лют 2025, Milan Crha wrote:
Hello,
I'd like to orphan the evolution-mapi and openchange packages for the
Fedora 43. Both are for the Microsoft's MAPI protocol. The OpenChange
lost its upstream many years ago.
The Microsoft released the first version of an Ex
On Mon, 10 Feb 2025 at 09:41, Milan Crha wrote:
> Hello,
> I'd like to orphan the evolution-mapi and openchange packages for the
> Fedora 43. Both are for the Microsoft's MAPI protocol. The OpenChange
> lost its upstream many years ago.
>
> The Microsoft rele
Hello,
I'd like to orphan the evolution-mapi and openchange packages for the
Fedora 43. Both are for the Microsoft's MAPI protocol. The OpenChange
lost its upstream many years ago.
The Microsoft released the first version of an Exchange Web Services
(EWS) protocol in 2007, with
On Sat, Feb 8, 2025 at 10:00 PM Orion Poplawski wrote:
>
> Many hdf5 dependencies have the following:
>
> Requires: hdf5%{?_isa} = %{_hdf5_version}
>
> resulting in rpm -q --requires listing:
>
> hdf5(x86-64) = 1.14.5
>
> I would like to know what packages have th
Many hdf5 dependencies have the following:
Requires: hdf5%{?_isa} = %{_hdf5_version}
resulting in rpm -q --requires listing:
hdf5(x86-64) = 1.14.5
I would like to know what packages have this requires, but this does not
appear to work:
dnf5 repoquery --whatrequires 'hdf5(x86_64) = 1
endency on python3-snappy in the
committed-but-not-built update to python-pymongo 4.9.1, since it’s not
possible to query dependencies for packages that have never been built.
Still, it seems to be no great hardship to just re-enable i686 support
in this case, rather than saying “too bad, I dr
allowed me learn about the new dependency on python3-snappy
in the committed-but-not-built update to python-pymongo 4.9.1, since
it’s not possible to query dependencies for packages that have never
been built.
Still, it seems to be no great hardship to just re-enable i686 support
in this case
Yes, it looks like I probably made an error in dropping i686 support in
python-cramjam starting in Fedora 41.
The case of a package considering dropping i686 (python-cramjam) having
an indirect dependency from another arched package (python-pymongo) via
one or more noarch packages (python
Hi Sergio,
I have opened the relevant issue for you at
https://issues.redhat.com/browse/RHEL-78335.
Feel free to add any comments.
Kind regards,
Dimitris
On Thu, Feb 6, 2025 at 11:56 PM Mikolaj Izdebski
wrote:
> On Thu, Feb 6, 2025 at 7:51 PM Sérgio Basto via devel
> wrote:
> > BTW I'd like t
Hot news:
- the review of licenses in queue has been stalled for several weeks
Two weeks ago we had:
* 24401spec files in Fedora
* 31038license tags in all spec files
* 142 tags are not SPDX compliant (number from line bellow minus packages with
LicenseRef-Callaway-*)
* 2289 tags have
(leaf package on that architecture)
While many packages depend on this one, we believe we have correctly
verified that all directly or indirectly dependent packages either are
noarch or already exclude i686.
However, we are now seeing a build failure on i686 for python-pymongo
age on that architecture)
>
> While many packages depend on this one, we believe we have correctly
> verified that all directly or indirectly dependent packages either are
> noarch or already exclude i686.
>
> However, we are now seeing a build failure on i686 for pytho
python-cramjam dropped i686 with this:
commit 3ebdbdac596b6f01c97b89d3b67635519b10b944
Author: Benjamin A. Beasley
Date: Mon Sep 30 19:24:11 2024 -0400
F41+: Drop i686 support (leaf package on that architecture)
While many packages depend on this one, we believe we have correctly
On Thu, Feb 6, 2025 at 7:51 PM Sérgio Basto via devel
wrote:
> BTW I'd like to fix tomcat 9 in RHEL9
> https://bugzilla.redhat.com/show_bug.cgi?id=2331858
>
> how we contact RH maintainer ?
You can open a Jira issue at https://issues.redhat.com/
--
Mikolaj
>
>
> Thank you
> --
> Sérgio M. B.
>
On Thu, 2025-02-06 at 18:01 +, Aoife Moloney via devel-announce
wrote:
>
> == Feedback ==
> No feedback is received.
As a tomcat user , this remove of tomcat-servlet-api, tomcat-el-api,
and tomcat-jsp-api doesn't affect me
BTW I'd like to fix tomcat 9 in RHEL9
https://bugzilla.redhat.com/s
Wiki -
https://fedoraproject.org/wiki/Changes/Remove_el,_jsp_and_servlet_packages_from_tomcat
Discussion Thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-remove-el-jsp-and-servlet-packages-from-tomcat-self-contained/144199
This is a proposed Change for Fedora Linux.
This
On 2/5/25 8:50 AM, Ken Dreyer wrote:
Hi folks, I've changed jobs recently and I need to drop
co-maintainership on some packages.
I have (co-)maintainership on 27 packages here:
https://src.fedoraproject.org/user/ktdreyer/projects
If I have admin permissions on a package, I can remove m
On Wed, Feb 05, 2025 at 02:50:18PM +, Ken Dreyer wrote:
> Hi folks, I've changed jobs recently and I need to drop
> co-maintainership on some packages.
>
> I have (co-)maintainership on 27 packages here:
> https://src.fedoraproject.org/user/ktdreyer/projects
>
> I
V Wed, Feb 05, 2025 at 02:50:18PM -, Ken Dreyer napsal(a):
> Hi folks, I've changed jobs recently and I need to drop
> co-maintainership on some packages.
>
> I have (co-)maintainership on 27 packages here:
> https://src.fedoraproject.org/user/ktdreyer/projects
Hi folks, I've changed jobs recently and I need to drop
co-maintainership on some packages.
I have (co-)maintainership on 27 packages here:
https://src.fedoraproject.org/user/ktdreyer/projects
If I have admin permissions on a package, I can remove myself, but for many of
these I only ha
On Tue, Feb 04, 2025 at 02:54:30PM +, Sérgio Basto via devel wrote:
> Hi,
> In this case: "packages which install to hardcoded $DESTDIR/usr/sbin,
> but then use %{_sbindir} in %files, will need to be adjusted."
>
> I did this [1] after the make install, is that c
On Tue, Feb 04, 2025 at 02:54:30PM +, Sérgio Basto via devel wrote:
> Hi,
> In this case: "packages which install to hardcoded $DESTDIR/usr/sbin,
> but then use %{_sbindir} in %files, will need to be adjusted."
>
> I did this [1] after the make install, is that c
Hi,
In this case: "packages which install to hardcoded $DESTDIR/usr/sbin,
but then use %{_sbindir} in %files, will need to be adjusted."
I did this [1] after the make install, is that correct ?
[1]
%if "%{_sbindir}" == "%{_bindir}"
mkdir -p %{buildroot}%{_bi
On Wed, 2025-01-29 at 08:47 -0700, Nathanael Noblet wrote:
> On Thu, 2025-01-23 at 09:30 +0100, Miro Hrončok wrote:
> > clamsmtp gnat
>
> I've just gotten in contact with the upstream source maintainer that
> is
> assisting in trying to get this to build. We're currently
On Fri, Jan 31, 2025 at 11:58 AM Matthew Miller
wrote:
>
> On Fri, Jan 31, 2025 at 12:04:33AM +0100, Neal Gompa wrote:
> > Right, we need a way for the build system to count the number of times
> > a commit was built and export that as an rpm macro that we can use to
> > make the NVR unique.
>
> h
On Fri, Jan 31, 2025 at 12:04:33AM +0100, Neal Gompa wrote:
> Right, we need a way for the build system to count the number of times
> a commit was built and export that as an rpm macro that we can use to
> make the NVR unique.
https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms-nvr-nvrb/
On Thu, Jan 30, 2025 at 11:51 PM Kevin Fenzi wrote:
>
> On Thu, Jan 30, 2025 at 11:13:24PM +0100, Neal Gompa wrote:
> > On Thu, Jan 30, 2025 at 11:05 PM Kevin Fenzi wrote:
> > >
> > > On Wed, Jan 29, 2025 at 07:18:23AM -0500, Matthew Miller wrote:
> > > > On Tue, Jan 21, 2025 at 08:21:26AM -0500,
On Thu, Jan 30, 2025 at 11:13:24PM +0100, Neal Gompa wrote:
> On Thu, Jan 30, 2025 at 11:05 PM Kevin Fenzi wrote:
> >
> > On Wed, Jan 29, 2025 at 07:18:23AM -0500, Matthew Miller wrote:
> > > On Tue, Jan 21, 2025 at 08:21:26AM -0500, Neal Gompa wrote:
> > > > If Koschei could trigger non-scratch r
On Thu, Jan 30, 2025 at 11:05 PM Kevin Fenzi wrote:
>
> On Wed, Jan 29, 2025 at 07:18:23AM -0500, Matthew Miller wrote:
> > On Tue, Jan 21, 2025 at 08:21:26AM -0500, Neal Gompa wrote:
> > > If Koschei could trigger non-scratch rebuilds, that would go a long
> > > way toward this.
>
> Note that kos
On Wed, Jan 29, 2025 at 07:18:23AM -0500, Matthew Miller wrote:
> On Tue, Jan 21, 2025 at 08:21:26AM -0500, Neal Gompa wrote:
> > If Koschei could trigger non-scratch rebuilds, that would go a long
> > way toward this.
Note that koschei just rebuilds existing src.rpms in scratch builds.
Getting it
us to check the boxes of our own rules? Is it worthwhile to try to package
> > Home Assistant? And, not, like, quixotically worthwhile — what impact does
> > it have?
> >
>
> A recent survey of Android packages where bundling is default indicates that
> dependencies
the _internal_ ability, do we have a meaningful chance to effect
> outside change — if we build it, will they come?
Adopting Python in Fedora improved the entire Python ecosystem, so yes it is
possible.
Arch linux and FreeBSD have a clear set of core packages, and policies to make
a package
On Thu, 2025-01-23 at 09:30 +0100, Miro Hrončok wrote:
> clamsmtp gnat
I've just gotten in contact with the upstream source maintainer that is
assisting in trying to get this to build. We're currently testing some
patches.
Sincerely,
--
Nathanael
--
_
On Wed, Jan 22, 2025 at 09:51:28AM +, Daniel P. Berrangé wrote:
> While the ring idea as presented there didn't come to exist inside
> Fedora as a community, I think we can see that concept has indeed
> grown up outside Fedora.
Yes, 100%. This was already happening when I made the Rings propos
On Tue, Jan 21, 2025 at 02:13:02PM +, Zbigniew Jędrzejewski-Szmek wrote:
> At the fundamental level, such automation would effectively do two
> steps:
> 1. create a no-change commit like we do now,
> 2. push the commit and fire off a build.
>
> (I think we want to keep 1. unchanged. We need to
On Tue, Jan 21, 2025 at 08:21:26AM -0500, Neal Gompa wrote:
> If Koschei could trigger non-scratch rebuilds, that would go a long
> way toward this.
This is what draft builds are for, isn't it?
https://docs.pagure.org/koji/release_notes/release_notes_1.34/#draft-builds
--
Matthew Miller
Fedo
I have orphaned the following:
- apache-commons-configuration
- apache-commons-jexl
- apache-commons-vfs
They were used by maven-doxia, but with the
maven-doxia*/maven-reporting* updates I just submitted to Rawhide,
they no longer are. If my repoquery usage is correct, then the first
two have no
us quo that could benefit other languages where the usual way of
> > > dealing with dependencies is incompatible with distributions.
> > > You are aware that 1) this request is explicitly targeting Golang
> > packages only, and 2) building with vendored dependencies is *alrea
pendencies is incompatible with distributions.
> > You are aware that 1) this request is explicitly targeting Golang
> packages only, and 2) building with vendored dependencies is *already*
> allowed (regardless of language ecosystem) when not doing so would
> place an undue mainten
ware that 1) this request is explicitly targeting Golang
packages only, and 2) building with vendored dependencies is *already*
allowed (regardless of language ecosystem) when not doing so would
place an undue maintenance burden on the packager? In particular, with
zig stuff, I doubt that it'
On 1/24/25 04:56, Miro Hrončok wrote:
On 24. 01. 25 6:13, Yaakov Selkowitz wrote:
On 1/23/25 03:30, Miro Hrončok wrote:
qm-dsp tartina
qm-vamp-plugins valtri
https://src.fedoraproject.org/rpms/qm-dsp/pull-request/3
https://src.fedoraproject.org/rpms/qm-vamp-plugin
On Fri, 2025-01-24 at 10:56 +0100, Miro Hrončok wrote:
> On 24. 01. 25 6:13, Yaakov Selkowitz wrote:
> > On 1/23/25 03:30, Miro Hrončok wrote:
> > > qm-dsp tartina
> > > qm-vamp-plugins valtri
> >
> > https://src.fedoraproject.org/rpms/qm-dsp/pull-request/3
> > https:/
On 24. 01. 25 6:13, Yaakov Selkowitz wrote:
On 1/23/25 03:30, Miro Hrončok wrote:
qm-dsp tartina
qm-vamp-plugins valtri
https://src.fedoraproject.org/rpms/qm-dsp/pull-request/3
https://src.fedoraproject.org/rpms/qm-vamp-plugins/pull-request/2
(Those two should be
Hot news:
- no news today
Two weeks ago we had:
* 24379spec files in Fedora
* 30988license tags in all spec files
* 161 tags are not SPDX compliant (number from line bellow minus packages with
LicenseRef-Callaway-*)
* 2325 tags have not been converted to SPDX yet
* 21 tags can be
On 1/23/25 03:30, Miro Hrončok wrote:
qm-dsp tartina
qm-vamp-plugins valtri
https://src.fedoraproject.org/rpms/qm-dsp/pull-request/3
https://src.fedoraproject.org/rpms/qm-vamp-plugins/pull-request/2
(Those two should be done in order due to dependencies.)
rats
On 23/1/25 19:30, Miro Hrončok via devel-announce wrote:
rats athoscr, cicku, fale
Would be a shame to lose rats.
--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
--
___
devel mailing list -- devel@lists.fedorapro
Dear maintainers.
Based on the current fail to build from source policy, the following packages
should be retired from Fedora 42 approximately one week before branching,
i.e. 2025-01-28.
5 weekly reminders are required, this is the last one.
Policy:
https://docs.fedoraproject.org/en-US/fesco
On Thu, Jan 23, 2025 at 12:32 AM Richard W.M. Jones wrote:
>
> I don't think supply chain security was really mentioned in the thread
> yet (apologies if it was - I only scanned it).
>
> There's a real danger that if we forgo responsibility for reviewing
> packa
I don't think supply chain security was really mentioned in the thread
yet (apologies if it was - I only scanned it).
There's a real danger that if we forgo responsibility for reviewing
packages to another project, then someone can add a bad package to
that other project and it becomes
ker
> > > container images. Fedora meanwhile continues trying to package and
> > > deliver everything the same way as we did for decades, as if this
> > > shift were not happening.
> >
> > This kind of misses the point that Fedora packages do provide (in my
eanwhile continues trying to package and
> > > deliver everything the same way as we did for decades, as if this
> > > shift were not happening.
> > > This kind of misses the point that Fedora packages do provide (in my
> > opinion) quite a lot of value on top of m
t; shift were not happening.
> > This kind of misses the point that Fedora packages do provide (in my
> opinion) quite a lot of value on top of most language-specific package
> package managers.
> pip is a little bit more advanced than other tools here, but `go
> install` and `c
e did for decades, as if this
> > shift were not happening.
>
> This kind of misses the point that Fedora packages do provide (in my
> opinion) quite a lot of value on top of most language-specific package
> package managers.
>
> pip is a little bit more advanced than other
le ring 3 is the space filled by Flatpaks and further docker
> container images. Fedora meanwhile continues trying to package and
> deliver everything the same way as we did for decades, as if this
> shift were not happening.
This kind of misses the point that Fedora packages do provide (in m
doesn't need to follow those steps.
> What's disappointing is that as end users are adopting use of things
> from Ring's 2 & 3, they are loosing the potential benefits Fedora's
> more direct involvement would have enabled.
The easy-of-use, quality, and flexib
On Wed, Jan 22, 2025 at 8:45 AM Ondrej Mosnáček wrote:
>
> On Tue, 21 Jan 2025 at 21:42, maxwell--- via devel-announce
> wrote:
> >
> > Report started at 2025-01-21 20:00:10 UTC
> >
> > The following packages are orphaned and will be retired when they
>
gt; > > platform (not just as an "app" platform). If we expect developers to
> > > install dependencies of their project via the ecosystem tools (pip, ...)
> > > locally (envs, containers) and "app packages" do the same during build
> > > then i
On Tue, 21 Jan 2025 at 21:42, maxwell--- via devel-announce
wrote:
>
> Report started at 2025-01-21 20:00:10 UTC
>
> 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
On Tue, Jan 21, 2025 at 9:07 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> Consider https://kojipkgs.fedoraproject.org/mass-rebuild/f42-failures.html:
> there are 7 failed rust packages there. Part of the reason is that
> by not bundling we don't have a long tail of old versions s
at
> > many different versions.
> >The only cases are for widely used libraries that *also* frequently
> > change API (like hashbrown, nix, or quick-xml).
> >Otherwise we would already have ported everything to newer versions
> > of those libraries.
>
> a
and doing
other things like it made them feel better. If we have the choice, we
should pick higher-quality dependencies which are stable and don't
require constant pointless churn. But if we are unlucky and depend on
something that does require rebuilds, I want to have a name and
an explana
On Tue, Jan 21, 2025 at 03:42:22PM +0100, Miroslav Suchý wrote:
> Dne 21. 01. 25 v 3:13 odp. Zbigniew Jędrzejewski-Szmek napsal(a):
> > At the fundamental level, such automation would effectively do two
> > steps:
> > 1. create a no-change commit like we do now,
> > 2. push the commit and fire off
herwise we would already have ported everything to newer versions
> of those libraries.
a quick search showed me roughly 25 packages which had multiple versions
packaged in fedora
if you have a big hand in all the packages within the ecosystem then its a bit
more trivial to make changes
he only cases are for widely used libraries that *also* frequently
change API (like hashbrown, nix, or quick-xml).
Otherwise we would already have ported everything to newer versions
of those libraries.
2. I am actively working on reducing the number of "compat" packages we provide,
On 1/21/25 8:00 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 20, 2025 at 11:20:50AM +, Daniel P. Berrangé wrote:
I understand that these are challenges, and they are increasing because
there are so many upcoming ecosystems which build their own distribution
channels and tools, be it Go
ely up to this point and its only caused
a ton of extra work which fewer people want to do.
Lots of Fedora package maintainers are already spread across a dozen packages
for which they often don't have the time to properly maintain and most of the
time no one cares because there are only a hand
1 - 100 of 8451 matches
Mail list logo
