> Am 08.03.2022 um 01:41 schrieb Kevin Kofler via devel
> :
>
> I do not see why we would want to force removing working, maintained
> packages from the distribution. That is a major disservice to users and
> basically a "screw you" to the maintainer. Whom does that help?
>
> GLib 1 and GTK+
Michael Catanzaro wrote:
> Broken dependencies will be automatically retired if they are not fixed
> within a certain time, so it's really OK to do this. The broken
> packages won't stick around forever: they will eventually get cleaned
> up.
In other words, leaf applications that end users care a
Michael Catanzaro wrote:
> The maintainer is unwilling to retire them.
>
> I think we should ask FESCo to force them to be retired. It's confusing
> to have ancient versions of the packages in the distro, and they will
> stick around forever if not.
I do not see why we would want to force removin
Felix Schwarz wrote:
> Btw: How do you handle/fix build issues when you can only build inside
> mock?
>
> So for example your mock build fails because some paths or binaries are
> wrong and it is not obvious from the error what needs to be changed. In
> these situations I'd like to have some kind
Hi,
On Fri, 2022-03-04 at 18:07 +0100, Kamil Dudka wrote:
> On Friday, March 4, 2022 4:17:01 PM CET Sérgio Basto wrote:
> > I think you missed the
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
>
> When the change landed, I had to fix all my packages to build althoug
On 3/7/22 2:03 PM, Neal Gompa wrote:
A simpler solution would be to just default-off i686 and check-in some
marker file that indicates the package needs to be built for multilib.
This is how openSUSE does it today with the baselibs.conf file:
https://code.opensuse.org/package/fdk-aac-free/blob/ma
As you all know by now, I'm trying to retire as steward of the
sagemath and Macaulay2 stacks. Nevertheless, after some impassioned
pleas from a couple of sagemath users, I have prepared an update for
sagemath 9.5. This will require an update to Singular 4.2.1p3, which
comes with an soname bump.
Neal Gompa writes:
> On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood wrote:
>>
>> Fabio Valentini writes:
>>
>> > For example, as far as I know, you need the 32-bit host libraries for
>> > running 32-bit Windows applications in Wine. Dropping that would make
>> > our Wine packages almost useless
On Mon, Mar 7, 2022 at 3:46 PM Adam Williamson
wrote:
>
> On Mon, 2022-03-07 at 11:25 -0800, Kevin Fenzi wrote:
> > So, I'll go ahead and be a bad guy here:
> >
> > Perhaps it's time to just retire i686 completely?
> >
> > Steam is available as a flatpak
>
> Do we know how the flatpak is built and
On Mon, 2022-03-07 at 11:25 -0800, Kevin Fenzi wrote:
> So, I'll go ahead and be a bad guy here:
>
> Perhaps it's time to just retire i686 completely?
>
> Steam is available as a flatpak
Do we know how the flatpak is built and updated? Would Fedora ending
i686 support affect *that* work?
--
Ada
On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood wrote:
>
> Fabio Valentini writes:
>
> > For example, as far as I know, you need the 32-bit host libraries for
> > running 32-bit Windows applications in Wine. Dropping that would make
> > our Wine packages almost useless, since a large fraction of W
Fabio Valentini writes:
> For example, as far as I know, you need the 32-bit host libraries for
> running 32-bit Windows applications in Wine. Dropping that would make
> our Wine packages almost useless, since a large fraction of Windows
> software still isn't 64-bit.
Would it be possible to ha
On Mon, Mar 7, 2022 at 2:15 PM Miro Hrončok wrote:
>
> On 07. 03. 22 19:30, Fabio Valentini wrote:
> > On Mon, Mar 7, 2022 at 7:22 PM Chris Adams wrote:
> >>
> >> Once upon a time, Ben Cotton said:
> >>> == Summary ==
> >>>
> >>> Package maintainers are encouraged to actively stop building their
On Mon, 2022-03-07 at 20:32 +0100, Fabio Valentini wrote:
> On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi wrote:
> >
> > So, I'll go ahead and be a bad guy here:
> >
> > Perhaps it's time to just retire i686 completely?
> >
> > Steam is available as a flatpak, and old software thats 32bit only and
On Wed, Mar 2, 2022 at 7:15 PM Steve Grubb wrote:
> As someone involved in that change, the situation was much worse back in
> 2011. Almost everything was running as root. The inspection tools back then
> were non-existent, which is what I wrote pscap and netcap.
>
> Now, a lot of things use capa
On Mon, Mar 7, 2022 at 8:15 PM Miro Hrončok wrote:
>
Thanks for your feedback, I'll respond inline.
>
> This begs several questions that would probably need to be clarified e.g. in
> the packaging guidelines. For example:
>
> --
>
> I am adding a brand new package to multiple Fedora releases
On 07. 03. 22 20:25, Kevin Fenzi wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak, and old software thats 32bit only and
can't be rebuilt could just be run from a f36 container?
This would save us:
* all the buil
Hi Steve,
On Wed, Mar 02, 2022 at 07:11:42PM -0500, Steve Grubb wrote:
> Hello,
>
> On Tuesday, March 1, 2022 6:43:57 PM EST Michel Alexandre Salim wrote:
> > The subject of setuid came up in a private conversation recently, and to my
> > surprise we don't seem to have it documented in the packag
On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi wrote:
>
> So, I'll go ahead and be a bad guy here:
>
> Perhaps it's time to just retire i686 completely?
>
> Steam is available as a flatpak, and old software thats 32bit only and
> can't be rebuilt could just be run from a f36 container?
>
> This would
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak, and old software thats 32bit only and
can't be rebuilt could just be run from a f36 container?
This would save us:
* all the builder resources
* all the multilib calculat
On Mon, Mar 7 2022 at 04:48:27 PM +, Paul Howarth
wrote:
I'm not unwilling to retire them, I just want their users to be
retired
first so I don't leave a bunch of broken dependencies behind.
Hi, sorry, maybe I misunderstood your previous statements.
Broken dependencies will be automatica
On 07. 03. 22 19:30, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams wrote:
Once upon a time, Ben Cotton said:
== Summary ==
Package maintainers are encouraged to actively stop building their
packages for i686, especially if supporting this architecture requires
significan
Once upon a time, Fabio Valentini said:
> As far as I can tell, any approach more sophisticated than that (like
> automatically determining the i686 packages we *need*) would require
> significantly more work, and probably be more error-prone, introduce
> more friction, and make it harder to rever
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams wrote:
>
> Once upon a time, Ben Cotton said:
> > == Summary ==
> >
> > Package maintainers are encouraged to actively stop building their
> > packages for i686, especially if supporting this architecture requires
> > significant investment of time or re
Once upon a time, Ben Cotton said:
> == Summary ==
>
> Package maintainers are encouraged to actively stop building their
> packages for i686, especially if supporting this architecture requires
> significant investment of time or resources, for no benefit. This will
> not apply to packages which
On Sat, Mar 05, 2022 at 10:58:53AM +, Dan Čermák wrote:
>
>
> On March 5, 2022 9:03:54 AM UTC, Gary Buhrmaster
> wrote:
> >On Mon, Feb 28, 2022 at 5:25 PM Kevin Fenzi wrote:
> >
> >> No, there's things we can do and are trying to do. ;)
> >
> >I seem to remember that one of the issues
> >i
Hi Fedora, CentOS, and EPEL Communities!
As part of our continued 3 year major Red Hat Enterprise Linux release
cadence, RHEL 9 development is starting to wrap up with the spring
2022 release coming soon. That means planning for the next release
will start in earnest in the very near future. As
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
== Summary ==
Package maintainers are encouraged to actively stop building their
packages for i686, especially if supporting this architecture requires
significant investment of time or resources, for no benefit. This will
not apply
On Sat, 2022-03-05 at 16:08 -0500, Elliott Sales de Andrade wrote:
> On Fri, Mar 4, 2022 at 3:26 PM Ken Gaillot
> wrote:
> > Hi all,
> >
> > I have a question about the guidelines for "Handling Locale Files":
> >
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_handling_locale_fil
On Mon, 07 Mar 2022 10:29:02 -0600
Michael Catanzaro wrote:
> On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto
> wrote:
> > Hi,
> > In resume glib still required for 20 packages [1],
> > apart of the sweet memories that some package bring to us , any of
> > these packages is needed ? or h
Hi
On Mon, Mar 7, 2022 at 11:29 AM Michael Catanzaro wrote:
> On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto
> > Hi,
> > In resume glib still required for 20 packages [1],
> > apart of the sweet memories that some package bring to us , any of
> > these packages is needed ? or haven't
On Mon, 2022-03-07 at 16:17 +, Sérgio Basto wrote:
> Hi,
> In resume glib still required for 20 packages [1],
> apart of the sweet memories that some package bring to us , any of
> these packages is needed ? or haven't replacement ?
>
> Thanks
>
> alsa-tools (maintained by: perex, timj)
>
On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto
wrote:
Hi,
In resume glib still required for 20 packages [1],
apart of the sweet memories that some package bring to us , any of
these packages is needed ? or haven't replacement ?
The maintainer is unwilling to retire them.
I think we sh
Hi,
In resume glib still required for 20 packages [1],
apart of the sweet memories that some package bring to us , any of
these packages is needed ? or haven't replacement ?
Thanks
[1]
Depending packages (rawhide) (20): NsCDE alsa-firmware alsa-tools
bubblemon crossfire crossfire-client cros
No missing expected images.
Failed openQA tests: 12/229 (x86_64), 11/161 (aarch64)
New failures (same test not failed in Fedora-36-20220306.n.0):
ID: 1162863 Test: x86_64 Workstation-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1162863
ID: 1162889 Test: x86_64 KDE-l
https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
== Summary ==
java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and
java-latest-openjdk packages will no longer build i686 subpackages
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email:
* Product: java and java stack
* Responsible W
Hey all,
I'm going to do an ABI-breaking update of FFmpeg in F36+ to drop a
non-upstream patch that was intended to make it work with Chromium.
However, the patch never made it upstream and other FFmpeg builds
don't have it anymore, so now we have an ABI incompatibility that
needs to be fixed.
I
Am 07.03.22 um 13:25 schrieb Miro Hrončok:
Building pypy is nontrivial. I don't know if you can "just" build it on x86_64
for i686 without using mock, but you should be able to do it in mock:
Btw: How do you handle/fix build issues when you can only build inside mock?
So for example your mock
Hey Folks,
As most of you already know, we have the i18n test week happening now.
If you are someone who loves to experience Fedora Linux in your native
language and test out the new i18n changes this is your moment.
The wiki [0] starts off by telling you what the test day is all about,
the test
Missing expected images:
Minimal raw-xz armhfp
Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 17/231 (x86_64), 23/161 (aarch64)
New failures (same test not failed
On 07. 03. 22 10:51, Victor Stinner wrote:
How can someone reproduce the issue? I was asked by a developer
running Ubuntu. Is there an easy way to:
(*) Get Fedora 36
(*) Build PyPy 2.7 for 32-bit: can it be done on x86-64? What is the
command line for that?
Building pypy is nontrivial. I don't
OLD: Fedora-36-20220306.n.0
NEW: Fedora-36-20220307.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of upgraded
OLD: Fedora-Rawhide-20220305.n.0
NEW: Fedora-Rawhide-20220307.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 1
Dropped packages:1
Upgraded packages: 117
Downgraded packages: 0
Size of added packages: 148.21 KiB
Size of dropped packages
How can someone reproduce the issue? I was asked by a developer
running Ubuntu. Is there an easy way to:
(*) Get Fedora 36
(*) Build PyPy 2.7 for 32-bit: can it be done on x86-64? What is the
command line for that?
Victor
___
devel mailing list -- devel
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-34-20220306.0):
ID: 1161992 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
On 07. 03. 22 10:42, Miro Hrončok wrote:
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_
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
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-35-20220306.0):
ID: 1161918 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
48 matches
Mail list logo
