On 6/24/20 4:29 PM, Przemek Klosowski via devel wrote:
I noticed that kmod-wireguard is being updated on F31, even after
WireGuard became a part of Linux kernel since 5.6.0. Shouldn't
kernel>5.6.0 obsolete kmod-wireguard? Is it kept and updated because it
was originally installed via @command
On 7/15/20 1:11 PM, Chris Murphy wrote:
Hi,
While bad RAM is uncommon, it comes up with some regularity to cause
folks a lot of grief. I'm wondering if there's a way to make it easier
to get bad news :-\ In particular there are cases where RAM defects
just don't show up with a few hours of memte
On 06/08/2016 05:29 AM, Josh Boyer wrote:
Hi All,
The upstream stable maintainers released kernels 4.5.7 and 4.6.2
yesterday. I thought I would send a brief word about how the rebase
of F24 to 4.6.y will happen.
We'll ship 4.5.7 as the final 4.5.y update and have that available as
the 0-day up
On 08/03/2016 09:57 PM, Bruno Wolff III wrote:
On Thu, Aug 04, 2016 at 05:02:56 +0100,
Sérgio Basto wrote:
Hi,
From list of koji builds [1] rawhide and F25 uses pre 4.8. My question
is kernel-4.7.0-2 doesn't land on F24 and F23 ? , since kernel 4.6
already have a short live and 4.7 fix my cpu-
Hi,
I just submitted the 4.6.6 kernel update to stable for F23/F24. Both
4.7.1 and 4.6.7 are expected to be released upstream on Tuesday. 4.6.7
will be the last 4.6.y based kernel for F23/F24. 4.7.1 or 4.7.2 will
be available for testing sometime early next week.
If you have any questions please
On 08/17/2016 04:06 AM, Josh Boyer wrote:
On Tue, Aug 16, 2016 at 9:31 PM, Zbigniew Jędrzejewski-Szmek
wrote:
Unfortunately, due to the disagreements in the kernel development
community, CPU controller cgroup v2 support has not been merged and
enabling it requires applying two small out-of-tree
On 08/15/2016 08:31 AM, Laura Abbott wrote:
Hi,
I just submitted the 4.6.6 kernel update to stable for F23/F24. Both
4.7.1 and 4.6.7 are expected to be released upstream on Tuesday. 4.6.7
will be the last 4.6.y based kernel for F23/F24. 4.7.1 or 4.7.2 will
be available for testing sometime
On 08/23/2016 02:38 PM, Laura Abbott wrote:
On 08/15/2016 08:31 AM, Laura Abbott wrote:
Hi,
I just submitted the 4.6.6 kernel update to stable for F23/F24. Both
4.7.1 and 4.6.7 are expected to be released upstream on Tuesday. 4.6.7
will be the last 4.6.y based kernel for F23/F24. 4.7.1 or
On 09/22/2016 09:18 AM, Matthew Miller wrote:
On Wed, Sep 21, 2016 at 12:32:40PM -0600, Kevin Fenzi wrote:
* IMHO the initial upstream default didn't make sense for Fedora
On this specific change, I'm not sure the *updated* default makes sense
either. It still is quite constrained.
* Perhaps
(cross post from kernel)
We're starting to see a fall off in F23 karma. The kernel gets new
releases fairly frequently so this may start to slow down how fast F23
gets new kernels. If you still have an F23 system, please remember to
test and give karma for new kernels. A big thanks to those wh
Hi,
The 4.11 kernel was officially released last night. This kernel should
be showing up in a rawhide release in the next few days. F26 will also
get the final 4.11 update and then get the incremental stable updates
as they are released. F24/F25 will be rebased on the same schedule we
have in the
On 05/01/2017 08:35 AM, Laura Abbott wrote:
> Hi,
>
> The 4.11 kernel was officially released last night. This kernel should
> be showing up in a rawhide release in the next few days. F26 will also
> get the final 4.11 update and then get the incremental stable updates
> as they
On 07/11/2017 01:57 PM, Josh Boyer wrote:
> The fact that i686 kernels continue to work in general is basically luck.
I'm going to clarify this point and say that it's less luck and more
inertia and if nobody cares enough sometimes it just stops. Some
examples from recent history:
i686 builds wer
On 07/12/2017 09:23 AM, Hans de Goede wrote:
> Hi,
>
> On 12-07-17 16:33, Josh Boyer wrote:
>> On Wed, Jul 12, 2017 at 10:14 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>>
>>> On 12-07-17 15:18, Josh Boyer wrote:
On Wed, Jul 12, 2017 at 9:09 AM, Hans de Goede
wrote:
>
> Hi,
Hi,
4.4.2 is currently building and should be in updates-testing soon. As usual,
please test and give karma appropriately (negative karma for new issues,
not existing issues).
Thanks,
Laura
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists
On 02/18/2016 05:51 PM, Laura Abbott wrote:
Hi,
4.4.2 is currently building and should be in updates-testing soon. As usual,
please test and give karma appropriately (negative karma for new issues,
not existing issues).
Thanks,
Laura
A use after free bug was found in the 4.4.2 release. Since
On 02/24/2016 11:17 AM, Josh Boyer wrote:
On Wed, Feb 24, 2016 at 2:09 PM, Xose Vazquez Perez
wrote:
Jóhann_B._Guðmundsson wrote:
Arguably the regression in 4.4 with drm/i915 that causes screen
flickering in dual monitor setups needs to be looked at before this gets
released since it will g
Hi,
Kernel 4.9 was officially released yesterday, December 11. This kernel is
being built for rawhide today. The plan for bringing this kernel into
F24/F25 is going to follow roughly the same schedule as in the past.
This means pushing the new rebase when we think it's stable enough.
In the past,
On 12/19/2016 02:59 PM, Igor Gnatenko wrote:
> Hi,
>
> I found only one cross-compiler in repos -- arm-none-eabi-gcc-cs
>
> But it doesn't work:
> This package is compiled in bootstrap mode and used only to solve circular
> build dependency. You don't want to use this package. It's not expected t
On 12/12/2016 09:14 AM, Laura Abbott wrote:
> Hi,
>
> Kernel 4.9 was officially released yesterday, December 11. This kernel is
> being built for rawhide today. The plan for bringing this kernel into
> F24/F25 is going to follow roughly the same schedule as in the past.
> This
On 01/10/2017 08:16 AM, Laura Abbott wrote:
> On 12/12/2016 09:14 AM, Laura Abbott wrote:
>> Hi,
>>
>> Kernel 4.9 was officially released yesterday, December 11. This kernel is
>> being built for rawhide today. The plan for bringing this kernel into
>> F24/F25 is
On 11/7/19 1:31 PM, James Cassell wrote:
On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote:
I am on kernel 5.3.8 but I still have
kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated.
Is there a reason a new kernel-headers package hasn't been generated for
the newer versions? Has
On 8/10/19 2:56 AM, Adam Williamson wrote:
Hey folks! I'm starting a new thread for this to trim the recipient
list a bit and include devel@ and coreos@.
The Story So Far: there is a Fedora release criterion which requires
Fedora to boot on Xen:
"The release must boot successfully as Xen DomU w
On 1/17/19 3:06 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 17, 2019 at 11:13:47AM +0100, Miro Hrončok wrote:
It happened to me almost dozen times now, so here's my rage :D
I want to send a pull request to a Fedora project*, I clone it, fork it,
push to the fork, open a PR and there it g
gcc9 exposed an underlying issue with some inline asm on s390x. I've emailed
upstream about the issue but it's still not fixed. In the interest of
continuing to test kernels, I've disabled this arch in rawhide kernels
for now. I'll be keeping an eye on this and plan to turn this arch back
on as so
I've been experimenting with enabling CONFIG_GCC_PLUGINS in the kernel
since I've heard some people express interest in stackleak (I'm interested
as well). a gcc plugin gets built as an .so file for use during
compilation. This means we need to package this .so file as part
of kernel-devel for bui
On 2/15/19 3:47 AM, Florian Weimer wrote:
* Laura Abbott:
I've been experimenting with enabling CONFIG_GCC_PLUGINS in the kernel
since I've heard some people express interest in stackleak (I'm interested
as well). a gcc plugin gets built as an .so file for use during
compilation
On 3/7/19 2:23 PM, Robert-André Mauchin wrote:
Hello,
I'm trying to build the new python-twisted 18.9.0, but it fails on 32 bits
architecture:
BUILDSTDERR: In file included from /usr/include/asm/socket.h:1,
BUILDSTDERR: from /usr/include/bits/socket.h:393,
BUILDSTDERR:
On 08/17/2018 08:55 AM, Dusty Mabe wrote:
I'd love to make logging during early boot not require everyone
to happen to get the `console=` entries ordered correctly on the
kernel command line. Inevitably we always get it wrong or the ordering
of the `console=` lines on a pre-baked works great for
On 10/05/2018 11:03 AM, Lennart Poettering wrote:
On Fr, 05.10.18 19:31, Kamil Paral (kpa...@redhat.com) wrote:
(cross-posting to devel and desktop lists, ideally reply to both)
Coincidentally, at All Systems Go! in Berlin last week I had some
discussions with kernel people about RLIMIT_NOFIL
On 11/7/18 1:29 PM, Dusty Mabe wrote:
On 11/7/18 1:35 PM, Michael Cronenworth wrote:
On 11/7/18 10:44 AM, Mohan Boddu wrote:
For a long time now updates are pushed manually everyday. It was troublesome and
someone has to own it for a week and look after it.
Now, the pushes are automated and
On 11/14/18 2:35 AM, Daniel P. Berrangé wrote:
If Fedora had longer life cycles, and more streams maintained in
parallel, then I think the result would be that I end up doing
rebases for everything I maintain rather than trying to backport
anything. Admittedly this would somewhat negate the suppo
On 11/14/18 5:29 AM, Matthew Miller wrote:
On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote:
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime versio
On 01/11/2018 06:17 PM, Peter Robinson wrote:
I just noticed, there is a difference in the default value of
`/proc/sys/net/core/optmem_max` on armv7l:
On all arches it is 20480, but on armv7l it is 10240.
Is there any specific reason for limiting the maximum ancillary buffer
size allowed per so
On 8/17/20 7:36 PM, Germano Massullo wrote:
Hi there, I would need help in understanding why this kernel build failed.
https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1613735/
The SRPM is the same of Fedora repository except for a small patch file
that I ha
Hi,
Kernel 4.13 was released this past weekend. This kernel has been
built for rawhide and is building for F27 as well. We will be
following the same upgrade procedure as in the past. F25 and F26
will get rebased to 4.13 after a few stable releases, typically
4.13.2 or 4.11.3 depending on how stab
On 09/05/2017 09:59 AM, James Hogarth wrote:
>
>
> On 5 Sep 2017 5:42 pm, "Laura Abbott" <mailto:labb...@redhat.com>> wrote:
>
> Hi,
>
> Kernel 4.13 was released this past weekend. This kernel has been
> built for rawhide and is building
On 09/05/2017 09:41 AM, Laura Abbott wrote:
Hi,
Kernel 4.13 was released this past weekend. This kernel has been
built for rawhide and is building for F27 as well. We will be
following the same upgrade procedure as in the past. F25 and F26
will get rebased to 4.13 after a few stable releases
On 09/22/2017 09:43 AM, mcatanz...@gnome.org wrote:
On Fri, Sep 22, 2017 at 8:41 AM, James Hogarth
wrote:
Pretty sure the last testing I did with the details form Hans's
blog[0] the behaviour was that if the nvidia driver failed then the
nouveau driver was a fallback (rather than the older ins
The kernel has seen an uptick in testing from fuzzers lately. This
has been great for the kernel as its exposed a number of bugs. See
https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html
as an example. Part of this has also shown what areas of the kernel
are under
While experimenting with some refactoring, I noticed that /usr/include/cpuidle.h
was being picked up by the glob for kernel-headers. This is kind of unusual
because /usr/include/cpufreq.h exists in kernel-tools-libs-devel yet both
come out of install from cpupower tools. This header really belongs
On 11/21/2017 03:25 PM, Laura Abbott wrote:
While experimenting with some refactoring, I noticed that /usr/include/cpuidle.h
was being picked up by the glob for kernel-headers. This is kind of unusual
because /usr/include/cpufreq.h exists in kernel-tools-libs-devel yet both
come out of install
On 06/21/2018 01:50 AM, Daniel P. Berrangé wrote:
The kernel change that introduced the i686 build problem was just a
rebase between 2 arbitrary pre-release git snapshots. I don't really
a compelling justification to rebase to a known broken snapshot,
without allowing time for x86 SIG to resolve
On 06/22/2018 08:37 AM, Jerry James wrote:
On Thu, Jun 21, 2018 at 2:50 AM Daniel P. Berrangé wrote:
Fedora rawhide has not had any kernel build available for i686 for a
week now. It was disabled in a rebase due to part of the build process
segfaulting.
The bug causing the segfault is not spe
On 06/23/2018 02:05 PM, Alexander Ploumistos wrote:
I've submitted the patch upstream, I hope it fares better than my last attempt.
Thanks for that, it looks like the maintainer accepted the package.
I took the patch into today's rawhide build and it seems to
have completed.
I have filed at t
On 06/28/2018 06:42 AM, Miro Hrončok wrote:
Stuff that doesn't build and sounds important:
- ceph (also FTBFS in regular rawhide)
- libreoffice (also FTBFS in regular rawhide)
- orca (blocked by pyatspi, looking at it ATM)
- kernel-tools
For kernel-tools, it depends on your definition
46 matches
Mail list logo
