Re: Kernel 4.13 rebase plans

[James Hogarth]

On 2 October 2017 at 03:26, Dennis Gilmore  wrote:

> El vie, 22-09-2017 a las 15:25 -0500, Michael Catanzaro escribió:
> > On Fri, Sep 22, 2017 at 2:21 PM, Chris Adams 
> > wrote:
> > > On what grounds?  There is nothing in the Fedora guidelines that
> > > makes
> > > package maintainers beholden to third-party (by definition, not
> > > part
> > > of
> > > Fedora) repos.  There's nothing for FESCo to vote on, unless you
> > > are
> > > going to propose that change.
> >
> > OK, I'll bite. The grounds are that FESCo has granted the WG full
> > control over the Workstation product, and the kernel package is part
> > of
> > that product. Although I can't speak for the entire WG today, I
> > would
> > be fairly astounded if the WG were to choose to allow kernel updates
> > to
> > break Negativo users after having identified Negativo as a strategic
> > priority and advertised it as supported. So if a kernel update goes
> > out
> > that breaks Negativo users, I would expect a policy to delay future
> > kernel upgrades until Negativo has been tested and confirmed to be
> > working. Since that would be controversial, someone would surely
> > appeal
> > to FESCo. Probably easier for everyone to take it straight to FESCo,
> > right?
> >
> > But again, if there is already a technical solution (a fallback to
> > noveau) in place and working, as I suspect (would be really nice if
> > somebody could confirm that!) then it doesn't matter.
> >
> > Michael
>
> Just catching up on email, There is no such thing as a WG post GA, we
> ship and support a single stream of updates for all products, editions
> and spins. The only way that the WG could stop or control any update
> for a package not owned by the WG is to provide enough negative karma
> to an update in Bodhi to force it to not be ppushable. I would really
> hope that people would not do that to keep updates out, and would
> instead have a open honest discussion to try figure out a acceptable
> path forward.  Any change to how we do updates would require
> significant changes in many parts of how we manage the ditro and update
> process. It would need discussions with Release Engineering and
> Infrastructre, that came with resources to support the work.
>
>
> Dennis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>

Just to round off this thread since LWN linked to it a day or so ago ...

Installed 4.13.4-200.fc26.x86_64 from updates repo just now and
and bumblebee-nvidia-384.90-1.fc26.x86_64 compiled the driver fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Dennis Gilmore]

El vie, 22-09-2017 a las 15:25 -0500, Michael Catanzaro escribió:
> On Fri, Sep 22, 2017 at 2:21 PM, Chris Adams 
> wrote:
> > On what grounds?  There is nothing in the Fedora guidelines that
> > makes
> > package maintainers beholden to third-party (by definition, not
> > part 
> > of
> > Fedora) repos.  There's nothing for FESCo to vote on, unless you
> > are
> > going to propose that change.
> 
> OK, I'll bite. The grounds are that FESCo has granted the WG full 
> control over the Workstation product, and the kernel package is part
> of 
> that product. Although I can't speak for the entire WG today, I
> would 
> be fairly astounded if the WG were to choose to allow kernel updates
> to 
> break Negativo users after having identified Negativo as a strategic 
> priority and advertised it as supported. So if a kernel update goes
> out 
> that breaks Negativo users, I would expect a policy to delay future 
> kernel upgrades until Negativo has been tested and confirmed to be 
> working. Since that would be controversial, someone would surely
> appeal 
> to FESCo. Probably easier for everyone to take it straight to FESCo, 
> right?
> 
> But again, if there is already a technical solution (a fallback to 
> noveau) in place and working, as I suspect (would be really nice if 
> somebody could confirm that!) then it doesn't matter.
> 
> Michael

Just catching up on email, There is no such thing as a WG post GA, we
ship and support a single stream of updates for all products, editions
and spins. The only way that the WG could stop or control any update
for a package not owned by the WG is to provide enough negative karma
to an update in Bodhi to force it to not be ppushable. I would really
hope that people would not do that to keep updates out, and would
instead have a open honest discussion to try figure out a acceptable
path forward.  Any change to how we do updates would require
significant changes in many parts of how we manage the ditro and update
process. It would need discussions with Release Engineering and
Infrastructre, that came with resources to support the work.


Dennis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[jack smith]

Hello Laura,

Is it possible that these 2 bugs, that are probably due to a wrong config, be 
fixed in 4.13 ?

https://bugzilla.redhat.com/show_bug.cgi?id=1491521
https://bugzilla.redhat.com/show_bug.cgi?id=1470995

More infos : https://github.com/MattDevo/firmware/issues/74

Thanks !
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Michael Catanzaro]

On Mon, Sep 25, 2017 at 12:30 PM, Samuel Sieb  wrote:
Why would the kernel modules be shown in Gnome Software?  That goes 
against all that I've heard about it.  All the low level things like 
libraries and non-graphical programs are not shown.


I believe it has appstream metainfo. Software shows plugins and fonts 
and codecs and other stuff that is useful to non-developers. Not 
libraries or CLI programs, no.


I'm definitely not the right person to talk to about the history of 
Negativo, but my understanding is this. Christian asked people to list 
their complaints about Fedora -- why don't you use Fedora? -- and one 
of the most important results was that installing Nvidia's crap 
proprietary driver is too hard, and that it frequently breaks during 
kernel updates. So there's two parts to that problem. Part one is 
making it appear in GNOME Software, so that it's easy to install. Part 
two is making it not break. Both parts needed to be fixed.


I actually can't myself find it in GNOME Software, but I never checked 
the checkbox in gnome-initial-setup to enable proprietary software 
sources. Hopefully if someone who checked that checkbox were to search, 
it would show up. Hopefully


  And that still doesn't solve the signing issue.  Gnome Software 
can't turn off secure boot for you, so those kernel modules you've 
installed will not load. Installing third party kernel modules are a 
command line operation and if you have secure boot, will require 
other manual intervention as well.


I don't know anything about that. :( But Ubuntu has been supporting the 
Nvidia driver for many, many years without requiring any use of the 
CLI. I wouldn't be surprised if it doesn't work with secure boot. Maybe 
that will be the next challenge to fix.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Samuel Sieb]

On 09/25/2017 06:26 AM, mcatanz...@gnome.org wrote:

On Mon, Sep 25, 2017 at 1:33 AM, Florian Weimer  wrote:


How is the user experience for installing these kernel modules today, 
anyway?  Does it need specialized knowledge to turn of Secure Boot in 
the firmware?


If yes, this means that those users are pretty advanced and are likely 
able to deal with boot-related problems.



I think you just click the big blue Install button in GNOME Software.


Why would the kernel modules be shown in Gnome Software?  That goes 
against all that I've heard about it.  All the low level things like 
libraries and non-graphical programs are not shown.  And that still 
doesn't solve the signing issue.  Gnome Software can't turn off secure 
boot for you, so those kernel modules you've installed will not load. 
Installing third party kernel modules are a command line operation and 
if you have secure boot, will require other manual intervention as well.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[mcatanzaro]

On Mon, Sep 25, 2017 at 1:33 AM, Florian Weimer  
wrote:


How is the user experience for installing these kernel modules today, 
anyway?  Does it need specialized knowledge to turn of Secure Boot in 
the firmware?


If yes, this means that those users are pretty advanced and are 
likely able to deal with boot-related problems.


Thanks,
Florian


I think you just click the big blue Install button in GNOME Software.

I totally agree with that philosophy, by the way. If you need to use 
the CLI to set it up, you're an advanced user and can use the CLI to 
fix it when it breaks. (No doubt these words will be used against me in 
the future. :)


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Florian Weimer]

On 09/22/2017 06:43 PM, mcatanz...@gnome.org wrote:
But if Negativo users start complaining that their computers don't boot 
anymore, then we'll definitely need to stop doing major kernel updates 
("taking the entire distro hostage" I guess) as the Negativo support is 
important for product strategy. Hopefully it doesn't come to that.


How is the user experience for installing these kernel modules today, 
anyway?  Does it need specialized knowledge to turn of Secure Boot in 
the firmware?


If yes, this means that those users are pretty advanced and are likely 
able to deal with boot-related problems.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Michael Catanzaro]

On Fri, Sep 22, 2017 at 4:43 PM, Fabio Valentini  
wrote:
For what it's worth: I just installed the 4.13.2 kernel from the 
kernel-stabilization repo, and the nvidia akmod module (from 
negativo17 repo) failed to build (as expected). But after rebooting 
with the new kernel, the system uses the fallback to nouveau 
correctly - without any manual intervention. So, from my point of 
view, it seems everything works as it is supposed to (well, except 
the compilation failure, but that's got nothing to do with fedora).


Awesome, thanks very much for testing it.

I don't think we have any problem here then.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Fabio Valentini]

For what it's worth: I just installed the 4.13.2 kernel from the
kernel-stabilization repo, and the nvidia akmod module (from negativo17
repo) failed to build (as expected). But after rebooting with the new
kernel, the system uses the fallback to nouveau correctly - without any
manual intervention. So, from my point of view, it seems everything works
as it is supposed to (well, except the compilation failure, but that's got
nothing to do with fedora).

Fabio

On Fri, Sep 22, 2017 at 10:58 PM Nicolas Chauvet  wrote:

> 2017-09-22 20:46 GMT+02:00  :
> > Oh boy. :)
> >
> > Does anyone know if the fallback is working properly? Because if so, then
> Just restoring the fact here, because despite the fallback idea is
> hans/WG the implementation is "RPM Fusion Community" original works.
> (1)
> So yet as soon as you are using "RPM Fusion", it works as expected.
>
> And furthermore, if you want to switch from nvidia to nouveau while
> the nvidia driver remains installed, you just need to unblacklist
> nouveau from cmdline (remove rd.driver.blacklist=nouveau
> modprobe.blacklist=nouveau).
> This is only implemented by the RPM Fusion "clean design".
>
> And could even be improved:
> https://bugzilla.redhat.com/show_bug.cgi?id=1489317 if anyone cares...
>
>
> (1)
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=4498
>
>
> --
> -
>
> Nicolas (kwizart)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Peter Robinson]

On Fri, Sep 22, 2017 at 7:46 PM,   wrote:
> Oh boy. :)
>
> Does anyone know if the fallback is working properly? Because if so, then
> everyone is happy and we don't need to be having this discussion. Sounds
> like there's a good chance that's the case. (I don't have an nvidia card to
> test myself.)

If fallback is not working I would say that is the responsibility of
the Workstation product to deal with and test on each kernel cycle to
ensure that it is because "Negativo support is important for product
strategy.". It's no different for any of the other groups that depend
on the kernel. I know that the architecture working groups spend a
reasonable amount of time each cycle to ensure that there's no
regressions on their architectures for the new kernels. Given that
4.13 is going to be the release kernel for F-27 and that has been
known for some time I'm kind of surprised that this is a surprise at
all as I kind of figured you'd have wanted it working on the latest
shiny GNOME by now the fact it's taken this long to be picked up
tells me that people care less than the rhetoric

> If the fallback is not working, then FESCo will probably need to decide
> indeed.
>
> Thanks,
>
> Michael
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Nicolas Chauvet]

2017-09-22 20:46 GMT+02:00  :
> Oh boy. :)
>
> Does anyone know if the fallback is working properly? Because if so, then
Just restoring the fact here, because despite the fallback idea is
hans/WG the implementation is "RPM Fusion Community" original works.
(1)
So yet as soon as you are using "RPM Fusion", it works as expected.

And furthermore, if you want to switch from nvidia to nouveau while
the nvidia driver remains installed, you just need to unblacklist
nouveau from cmdline (remove rd.driver.blacklist=nouveau
modprobe.blacklist=nouveau).
This is only implemented by the RPM Fusion "clean design".

And could even be improved:
https://bugzilla.redhat.com/show_bug.cgi?id=1489317 if anyone cares...


(1)
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4498


-- 
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Justin Forbes]

On Fri, Sep 22, 2017 at 3:25 PM, Michael Catanzaro
 wrote:
> On Fri, Sep 22, 2017 at 2:21 PM, Chris Adams  wrote:
>>
>> On what grounds?  There is nothing in the Fedora guidelines that makes
>> package maintainers beholden to third-party (by definition, not part of
>> Fedora) repos.  There's nothing for FESCo to vote on, unless you are
>> going to propose that change.
>
>
> OK, I'll bite. The grounds are that FESCo has granted the WG full control
> over the Workstation product, and the kernel package is part of that
> product. Although I can't speak for the entire WG today, I would be fairly
> astounded if the WG were to choose to allow kernel updates to break Negativo
> users after having identified Negativo as a strategic priority and
> advertised it as supported. So if a kernel update goes out that breaks
> Negativo users, I would expect a policy to delay future kernel upgrades
> until Negativo has been tested and confirmed to be working. Since that would
> be controversial, someone would surely appeal to FESCo. Probably easier for
> everyone to take it straight to FESCo, right?
>
> But again, if there is already a technical solution (a fallback to noveau)
> in place and working, as I suspect (would be really nice if somebody could
> confirm that!) then it doesn't matter.

The agreement when the whole Negativo strategy started was that a
technical fallback would be in place. If it is not ready, you can't
blame the kernel. But sure, let's take it to FESCo, that will be a fun
meeting. I am chairing next week, and would be happy to put it on the
agenda.

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Chris Adams]

Once upon a time, Michael Catanzaro  said:
> OK, I'll bite. The grounds are that FESCo has granted the WG full
> control over the Workstation product

Where is it documented that "full control" includes non-Fedora content?
I would have assumed (unless otherwise stated) that anything that's part
of the Fedora project is made up of Fedora content and still follows all
Fedora guidelines.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Michael Catanzaro]

On Fri, Sep 22, 2017 at 2:21 PM, Chris Adams  wrote:

On what grounds?  There is nothing in the Fedora guidelines that makes
package maintainers beholden to third-party (by definition, not part 
of

Fedora) repos.  There's nothing for FESCo to vote on, unless you are
going to propose that change.


OK, I'll bite. The grounds are that FESCo has granted the WG full 
control over the Workstation product, and the kernel package is part of 
that product. Although I can't speak for the entire WG today, I would 
be fairly astounded if the WG were to choose to allow kernel updates to 
break Negativo users after having identified Negativo as a strategic 
priority and advertised it as supported. So if a kernel update goes out 
that breaks Negativo users, I would expect a policy to delay future 
kernel upgrades until Negativo has been tested and confirmed to be 
working. Since that would be controversial, someone would surely appeal 
to FESCo. Probably easier for everyone to take it straight to FESCo, 
right?


But again, if there is already a technical solution (a fallback to 
noveau) in place and working, as I suspect (would be really nice if 
somebody could confirm that!) then it doesn't matter.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Chris Adams]

Once upon a time, mcatanz...@gnome.org  said:
> If the fallback is not working, then FESCo will probably need to
> decide indeed.

On what grounds?  There is nothing in the Fedora guidelines that makes
package maintainers beholden to third-party (by definition, not part of
Fedora) repos.  There's nothing for FESCo to vote on, unless you are
going to propose that change.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[mcatanzaro]

Oh boy. :)

Does anyone know if the fallback is working properly? Because if so, 
then everyone is happy and we don't need to be having this discussion. 
Sounds like there's a good chance that's the case. (I don't have an 
nvidia card to test myself.)


If the fallback is not working, then FESCo will probably need to decide 
indeed.


Thanks,

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Neal Gompa]

On Fri, Sep 22, 2017 at 2:20 PM, Laura Abbott  wrote:
> 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 instructions that totally blacklisted
>>> it leaving no GPU at all).
>>
>>
>> If that fallback is working, then I guess that's fine. (Though I'm not
>> speaking for the whole Working Group here... perhaps others expect it to
>> always work, I'm not sure.)
>>
>> But if Negativo users start complaining that their computers don't boot
>> anymore, then we'll definitely need to stop doing major kernel updates
>> ("taking the entire distro hostage" I guess) as the Negativo support is
>> important for product strategy. Hopefully it doesn't come to that.
>>
>> Michael
>>
>
> I appreciate that not having the nVidia driver work is not a good
> experience but we choose to do major kernel updates multiple times
> per release for many reasons. One of the biggest is that kernel
> versions eventually go EOL and no longer get official updates
> from the community (see https://www.kernel.org/ that 4.12 is now
> EOL). We have no hope of trying to sync to a LTS release and it's
> not feasible right now to have the two kernel maintainers try and
> manage our own stable release. Moving to a new major kernel version
> is the best way to provide bug fixes and security updates to
> Fedora users. It's not a perfect process by any means but any
> ideas about process improvement need to take that into account as
> well.

I would be extremely upset if we did move to longterm kernels. I use
Fedora precisely because I get current, up to date, relatively close
to vanilla builds of the kernel. If the Workstation WG is having
trouble with their current arrangement, then they should be exerting
pressure to fix the situation from NVIDIA's side, not Fedora's.

For that matter, if they *really* want that, then why not talk to NVIDIA
to have them set up an official repository that builds everything
properly (like negativo and RPM Fusion) and tracks our kernels and
builds kmod packages, just like they do for openSUSE Leap and
Tumbleweed.

It's not even difficult to do, since they clearly have an OBS that
supports tracking kernels and building kmod packages correctly. Just
have them build it for our distribution like they do for openSUSE and
publish. Then the WG can use that and stop trying to "hold the
distribution hostage".


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Laura Abbott]

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 instructions that 
totally blacklisted it leaving no GPU at all).


If that fallback is working, then I guess that's fine. (Though I'm not 
speaking for the whole Working Group here... perhaps others expect it to 
always work, I'm not sure.)


But if Negativo users start complaining that their computers don't boot 
anymore, then we'll definitely need to stop doing major kernel updates 
("taking the entire distro hostage" I guess) as the Negativo support is 
important for product strategy. Hopefully it doesn't come to that.


Michael



I appreciate that not having the nVidia driver work is not a good
experience but we choose to do major kernel updates multiple times
per release for many reasons. One of the biggest is that kernel
versions eventually go EOL and no longer get official updates
from the community (see https://www.kernel.org/ that 4.12 is now
EOL). We have no hope of trying to sync to a LTS release and it's
not feasible right now to have the two kernel maintainers try and
manage our own stable release. Moving to a new major kernel version
is the best way to provide bug fixes and security updates to
Fedora users. It's not a perfect process by any means but any
ideas about process improvement need to take that into account as
well.

Thanks,
Laura
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Luya Tshimbalanga]

On 12/09/17 02:47 PM, Laura Abbott wrote:
> 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, typically
>> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
>> does not give release dates for stable release but given past
>> timings, this will probably happen towards the end of September.
>> As always, if you have any questions please let me know.
>>
>> Thanks,
>> Laura
>>
>
> 4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
> this morning but given it was released in conjunction with a new
> publicized CVE, it was slightly smaller and I'm inclined to wait
> for 4.13.3 before attempting to push anything to bodhi for F26.
>
> Thanks,
> Laura
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

On the topic, it will be nice to enable amdgpu for both AMD SI and CIK
cards (the earlier GCN) as well to help our fellow AMD team[0]. I am
currently using mystro256 COPR amd-staging-kernel[1] and sometime
amd-mainline-kernel[2] repositories for testing purpose.

The goal is simple: supporting all GCN cards with amdgpu drive and leave
radeon for pre-GCN while playing a fallback should amdgpu fail somehow.
The process may be too late for F27 but could be useful for F28.


References

[0] https://cgit.freedesktop.org/~agd5f/linux/?h=amd-mainline-hybrid-4.11
[1] https://copr.fedorainfracloud.org/coprs/mystro256/amd-staging-kernel/
[2] https://copr.fedorainfracloud.org/coprs/mystro256/amd-mainline-kernel/

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Chris Adams]

Once upon a time, mcatanz...@gnome.org  said:
> But if Negativo users start complaining that their computers don't
> boot anymore, then we'll definitely need to stop doing major kernel
> updates ("taking the entire distro hostage" I guess) as the Negativo
> support is important for product strategy. Hopefully it doesn't come
> to that.

Just... no.

I don't use nVidia hardware (in part because of the driver shenanigans)
and I had not heard of Negativo before today.  That's not Fedora, and
certainly should not dictate how Fedora is run.

If any third-party repo wants to dictate kernel update requirements,
they can maintain their own kernels.  There is zero reason for all
Fedora users to suffer because of non-Fedora repos.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Ben Rosser]

On Fri, Sep 22, 2017 at 1:06 PM, Stephen John Smoogen  wrote:
> On 22 September 2017 at 12:43,   wrote:
>> But if Negativo users start complaining that their computers don't boot
>> anymore, then we'll definitely need to stop doing major kernel updates
>> ("taking the entire distro hostage" I guess) as the Negativo support is
>> important for product strategy. Hopefully it doesn't come to that.
>>
>
> Please don't try that. No one wins from fights like that.
>
> Anything further I could write on this is hard because I am so tired
> of this yearly self-inflicted headache.

I, too, am tired of this sort of thing, but I feel that someone needs
to say something here so...

Something seems wrong about basing "product strategy" for Fedora on
compatibility with a single third party repository. This is *not* how
the third party repository policy was sold; the goal was supposedly to
curate useful repositories for given Fedora editions, not to make them
the center of our "strategy". In fact I was concerned at the time that
more central oversight of third party repositories was needed rather
than leaving it up to the individual working groups, but I was
reassured that it wasn't because they were just sort of optional
extras.

If we block changes to the entire distro because we are concerned
about breaking a specific third party repository, then effectively,
it's *not* a third party repository. It's as much a part of Fedora as
any other component, except for a thin pretense that we are not
distributing this nonfree software directly.

In which case, I would be prepared to argue again that it should be
FESCo that curates the list of such repositories, not the working
groups.

I use nvidia drivers on my system and I'm all for acknowledging that
in the "real world" people use nonfree software, but I find myself
somewhat concerned at the apparent change of culture and direction
here. All the more so because of the apparent attempt to brush this
potential concern under the rug with the "taking the distro hostage"
comment, which I think is an overly excitable way to phrase a
legitimate concern.

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Tomasz Torcz]

On Fri, Sep 22, 2017 at 11:43:21AM -0500, 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 instructions that totally
> > blacklisted it leaving no GPU at all).
> 
> If that fallback is working, then I guess that's fine. (Though I'm not
> speaking for the whole Working Group here... perhaps others expect it to
> always work, I'm not sure.)
> 
> But if Negativo users start complaining that their computers don't boot
> anymore, then we'll definitely need to stop doing major kernel updates
> ("taking the entire distro hostage" I guess) as the Negativo support is
> important for product strategy. Hopefully it doesn't come to that.

  I cannot believe what I read. I don't think there would ever be
agreement to forfeit one of the greatest Fedora strength - current
kernel – for the sake of users of proprietary driver from 3rd repo!

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Stephen John Smoogen]

On 22 September 2017 at 12:43,   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 instructions that totally blacklisted
>> it leaving no GPU at all).
>
>
> If that fallback is working, then I guess that's fine. (Though I'm not
> speaking for the whole Working Group here... perhaps others expect it to
> always work, I'm not sure.)
>
> But if Negativo users start complaining that their computers don't boot
> anymore, then we'll definitely need to stop doing major kernel updates
> ("taking the entire distro hostage" I guess) as the Negativo support is
> important for product strategy. Hopefully it doesn't come to that.
>

Please don't try that. No one wins from fights like that.

Anything further I could write on this is hard because I am so tired
of this yearly self-inflicted headache.


> Michael
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[mcatanzaro]

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 instructions 
that totally blacklisted it leaving no GPU at all).


If that fallback is working, then I guess that's fine. (Though I'm not 
speaking for the whole Working Group here... perhaps others expect it 
to always work, I'm not sure.)


But if Negativo users start complaining that their computers don't boot 
anymore, then we'll definitely need to stop doing major kernel updates 
("taking the entire distro hostage" I guess) as the Negativo support is 
important for product strategy. Hopefully it doesn't come to that.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 22 September 2017 at 15:02, James Hogarth 
wrote:

>
>
> On 22 September 2017 at 14:50, Gary Gatling  wrote:
>
>>
>>
>> On Fri, Sep 22, 2017 at 9: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 instructions that totally blacklisted
>>> it leaving no GPU at all).
>>>
>>> Of course this is only helpful when the GPU is supported by nouveau ;)
>>>
>>> Note I haven't tested the negativo driver yet on the stabalization copr
>>> as I prefer the bumblebee experience since that keeps the discrete GPU
>>> powered down saving battery and temperatures when not in use ... and the
>>> negativo driver flips everything over to running on the discrete GPU and
>>> ignores the Intel integrated one.
>>>
>>> Given that it's fundamentally the same driver though I expect the
>>> experience to be the same - willing to test and report back :)
>>>
>>>
>> Hello,
>>
>> I am looking at the patch referenced earlier in the thread. There was a
>> problem with a missing file in nvidia's archive (nv_compiler.h) I am unsure
>> if it was really needed.
>>
>> I will try to test it with bumblebee-nvidia when I have time this weekend
>> on 4.12 and 4.13 beta.
>>
>> Thank you.
>>
>>
>> _
>>
>>
> Do keep in mind that the patching which is done to get it working (note
> that patch still failed compiling for me on 4.13.2 ... no patch was needed
> on 4.13.1) also has to change the license type so that it works, as a
> non-GPL symbol in use was marked GPL apparently ... which of course means
> it cannot be distributed by Negativo as a "fix" ...
>
> Checking the comments on the Negativo nvidia-driver site[0] it appears
> that there's already reports of it not working on F27 with that kernel:
>
> > ANARCHISTCAT
> > September 20, 2017 at 12:52 am
> > With Fedora 27 nvidia driver 384.69-1.fc27 and kernel
> 4.13.2-300.fc27.x86_64 i got with akmod an error and its unable to compile
> the driver 2017/09/20 00:40:28 akmodsbuild: MODPOST 4 modules
> > 2017/09/20 00:40:28 akmodsbuild: FATAL: modpost: GPL-incompatible module
> nvidia.ko uses GPL-only symbol ‘lockdep_init_map’
> > 2017/09/20 00:40:28 akmodsbuild: make[2]: ***
> [scripts/Makefile.modpost:91: __modpost] Error 1
> > 2017/09/20 00:40:28 akmodsbuild: make[1]: *** [Makefile:1520: modules]
> Error 2
> > 2017/09/20 00:40:28 akmodsbuild: make[1]: Leaving directory
> ‘/usr/src/kernels/4.13.2-300.fc27.x86_64’
>
>
>
> [0] https://negativo17.org/nvidia-driver/
>
>
And just to confirm my own experiences 

With the negativo driver the build fails:

  CC [M]  /var/lib/dkms/nvidia/384.69/build/nvidia-drm/nv-pci-table.o
ld -r -o /var/lib/dkms/nvidia/384.69/build/nvidia/nv-interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-frontend.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-instance.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-acpi.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-chrdev.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-cray.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-dma.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-gvi.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-i2c.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-mempool.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-mmap.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-p2p.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-pat.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-procfs.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-usermap.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-vm.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-vtophys.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-mlock.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-pci.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-registry.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-usermap.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-modeset-interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-pci-table.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-kthread-q.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-kthread-q-selftest.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-memdbg.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv_uvm_interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nvlink_linux.o
ld -r -o
/var/lib/dkms/nvidia/384.69/build/nvidia-modeset/nv-modeset-interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia-modeset/nvidia-modeset-linux.o
  LD [M]  /var/lib/dkms/nvidia/384.69/build/nvidia.o
  LD [M]  /var/lib/dkms/nvidia/384.69/build/nvidia-uvm.o
  LD [M]  /var/lib/dkms/nvidia/384.69/build/nvidia-modeset.o
  LD [M]  /var/lib/dkms/nvidia/384.69/build/nvidia-drm.o
  Building modules, stage 2.
  MODPOST 4 modules
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'lockdep_init_map'
make[2]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
make[1]: *** [Makefile:1520: modules] Er

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 22 September 2017 at 14:50, Gary Gatling  wrote:

>
>
> On Fri, Sep 22, 2017 at 9: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 instructions that totally blacklisted
>> it leaving no GPU at all).
>>
>> Of course this is only helpful when the GPU is supported by nouveau ;)
>>
>> Note I haven't tested the negativo driver yet on the stabalization copr
>> as I prefer the bumblebee experience since that keeps the discrete GPU
>> powered down saving battery and temperatures when not in use ... and the
>> negativo driver flips everything over to running on the discrete GPU and
>> ignores the Intel integrated one.
>>
>> Given that it's fundamentally the same driver though I expect the
>> experience to be the same - willing to test and report back :)
>>
>>
> Hello,
>
> I am looking at the patch referenced earlier in the thread. There was a
> problem with a missing file in nvidia's archive (nv_compiler.h) I am unsure
> if it was really needed.
>
> I will try to test it with bumblebee-nvidia when I have time this weekend
> on 4.12 and 4.13 beta.
>
> Thank you.
>
>
> _
>
>
Do keep in mind that the patching which is done to get it working (note
that patch still failed compiling for me on 4.13.2 ... no patch was needed
on 4.13.1) also has to change the license type so that it works, as a
non-GPL symbol in use was marked GPL apparently ... which of course means
it cannot be distributed by Negativo as a "fix" ...

Checking the comments on the Negativo nvidia-driver site[0] it appears that
there's already reports of it not working on F27 with that kernel:

> ANARCHISTCAT
> September 20, 2017 at 12:52 am
> With Fedora 27 nvidia driver 384.69-1.fc27 and kernel
4.13.2-300.fc27.x86_64 i got with akmod an error and its unable to compile
the driver 2017/09/20 00:40:28 akmodsbuild: MODPOST 4 modules
> 2017/09/20 00:40:28 akmodsbuild: FATAL: modpost: GPL-incompatible module
nvidia.ko uses GPL-only symbol ‘lockdep_init_map’
> 2017/09/20 00:40:28 akmodsbuild: make[2]: ***
[scripts/Makefile.modpost:91: __modpost] Error 1
> 2017/09/20 00:40:28 akmodsbuild: make[1]: *** [Makefile:1520: modules]
Error 2
> 2017/09/20 00:40:28 akmodsbuild: make[1]: Leaving directory
‘/usr/src/kernels/4.13.2-300.fc27.x86_64’



[0] https://negativo17.org/nvidia-driver/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Gary Gatling]

On Fri, Sep 22, 2017 at 9: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 instructions that totally blacklisted
> it leaving no GPU at all).
>
> Of course this is only helpful when the GPU is supported by nouveau ;)
>
> Note I haven't tested the negativo driver yet on the stabalization copr as
> I prefer the bumblebee experience since that keeps the discrete GPU powered
> down saving battery and temperatures when not in use ... and the negativo
> driver flips everything over to running on the discrete GPU and ignores the
> Intel integrated one.
>
> Given that it's fundamentally the same driver though I expect the
> experience to be the same - willing to test and report back :)
>
>
Hello,

I am looking at the patch referenced earlier in the thread. There was a
problem with a missing file in nvidia's archive (nv_compiler.h) I am unsure
if it was really needed.

I will try to test it with bumblebee-nvidia when I have time this weekend
on 4.12 and 4.13 beta.

Thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 22 September 2017 at 14:34, Matthew Miller 
wrote:

> On Fri, Sep 22, 2017 at 09:22:08AM -0400, Josh Boyer wrote:
> > > repo is supported and it needs to not break. We've been super super
> lenient
> >
> > That's a completely untenable position.  There is only one kernel for
> > all the Editions.  There will be times where the kernel needs to be
> > updated to fix a CVE and it breaks the nVidia driver.  There is no way
> > you can hold the entire distro hostage to an out-of-tree *proprietary*
> > driver.
>
> I thought the desktop team was working on a plan where if there is a
> kernel update with no working Nvidia driver, the new kernel would be
> installed but the default boot would stay the old one until the driver
> update is available (overridable by the user at any time or on the
> distro side if we flag a kernel update as important or critical for
> security). I've got some misgivings about even that, but it sounds far
> better than holding back the kernel overall.
>
>
>
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 instructions that totally blacklisted it
leaving no GPU at all).

Of course this is only helpful when the GPU is supported by nouveau ;)

Note I haven't tested the negativo driver yet on the stabalization copr as
I prefer the bumblebee experience since that keeps the discrete GPU powered
down saving battery and temperatures when not in use ... and the negativo
driver flips everything over to running on the discrete GPU and ignores the
Intel integrated one.

Given that it's fundamentally the same driver though I expect the
experience to be the same - willing to test and report back :)




[0] https://hansdegoede.livejournal.com/17356.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Matthew Miller]

On Fri, Sep 22, 2017 at 09:22:08AM -0400, Josh Boyer wrote:
> > repo is supported and it needs to not break. We've been super super lenient
> 
> That's a completely untenable position.  There is only one kernel for
> all the Editions.  There will be times where the kernel needs to be
> updated to fix a CVE and it breaks the nVidia driver.  There is no way
> you can hold the entire distro hostage to an out-of-tree *proprietary*
> driver.

I thought the desktop team was working on a plan where if there is a
kernel update with no working Nvidia driver, the new kernel would be
installed but the default boot would stay the old one until the driver
update is available (overridable by the user at any time or on the
distro side if we flag a kernel update as important or critical for
security). I've got some misgivings about even that, but it sounds far
better than holding back the kernel overall.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Josh Boyer]

On Fri, Sep 22, 2017 at 9:05 AM, Michael Catanzaro
 wrote:
> On Fri, Sep 22, 2017 at 6:54 AM, Josh Boyer 
> wrote:
>>
>> Absolutely not.
>>
>> josh
>
>
> If it breaks the Negativo repo, then yes it is. The Nvidia driver from that

No, it's really not.

> repo is supported and it needs to not break. We've been super super lenient

That's a completely untenable position.  There is only one kernel for
all the Editions.  There will be times where the kernel needs to be
updated to fix a CVE and it breaks the nVidia driver.  There is no way
you can hold the entire distro hostage to an out-of-tree *proprietary*
driver.

> with allowing kernel updates in the Workstation product, since it seems to
> be working well for everyone involved, but that would need to be
> reconsidered if a kernel update intentionally breaks an important subset of
> our users. (Note: we only support Nvidia if installed from the Negativo
> repo, not from anywhere else.)

No, you misunderstand.  Nobody intentionally broke nvidia.  It happens
during the normal course of development because nvidia is out-of-tree
and the upstream project does not preserve ABI.  This is the price a
driver pays for being out of tree.  The only viable solution is to get
the driver upstream, which is not likely to happen.

> It sounds like patches are already available, so it shouldn't be a huge
> problem to get the Nvidia package updated.

Great.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Michael Catanzaro]

On Fri, Sep 22, 2017 at 6:54 AM, Josh Boyer  
wrote:

Absolutely not.

josh


If it breaks the Negativo repo, then yes it is. The Nvidia driver from 
that repo is supported and it needs to not break. We've been super 
super lenient with allowing kernel updates in the Workstation product, 
since it seems to be working well for everyone involved, but that would 
need to be reconsidered if a kernel update intentionally breaks an 
important subset of our users. (Note: we only support Nvidia if 
installed from the Negativo repo, not from anywhere else.)


It sounds like patches are already available, so it shouldn't be a huge 
problem to get the Nvidia package updated.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Josh Boyer]

On Fri, Sep 22, 2017 at 4:42 AM, James Hogarth  wrote:
>
>
> On 15 September 2017 at 11:00, James Hogarth 
> wrote:
>>
>>
>>
>> On 13 September 2017 at 01:39, James Hogarth 
>> wrote:
>>>
>>>
>>>
>>> On 12 Sep 2017 10:49 pm, "Laura Abbott"  wrote:
>>>
>>> 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, typically
 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
 does not give release dates for stable release but given past
 timings, this will probably happen towards the end of September.
 As always, if you have any questions please let me know.

 Thanks,
 Laura

>>>
>>> 4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
>>> this morning but given it was released in conjunction with a new
>>> publicized CVE, it was slightly smaller and I'm inclined to wait
>>> for 4.13.3 before attempting to push anything to bodhi for F26.
>>>
>>>
>>>
>>> Thanks for the update Laura
>>>
>>> I'll pop that on my system tomorrow for some early testing and when
>>> you're ready with the bodhi update will add the feedback.
>>>
>>
>> Hi,
>>
>> Installed and running well here:
>>
>> Intel® Core™ i5-6300HQ CPU @ 2.30GHz × 4 Intel® HD Graphics 530 (Skylake
>> GT2) / Nvidia-bumblebee 384.69 on NV117
>>
>> WiFI working, bluetooth working, GPU works still.
>>
>> Ran through both the default and performance kernel regression tests[0] -
>> both passed.
>>
>> https://apps.fedoraproject.org/kerneltest/kernel/4.13.1-200.fc26.x86_64
>>
>> Incidentally I enabled the bfq scheduler for my spinning rust large data
>> drive and kyber for my SSD (since they have had some time to initially "bed
>> in" in 4.12)  and the system feels noticeably more responsive than on cfq
>> before ... though I wonder how much is a placebo effect ... might be fun to
>> switch it up and do some bonnie and iozone testing at some point.
>>
>> Cheers,
>>
>> James
>>
>>
>> [0] https://fedoraproject.org/wiki/KernelTestingInitiative
>
>
>
> Something happened in the 4.13.2 release which broke the nvidia driver.
>
> A few symbols changed and there was something that flipped to a GPL labelled
> symbol.
>
> I know we don't directly provide that for various reasons, but there is the
> initiative with Negativo etc that the Workstation Working Group has
> highlighted several times.
>
> See these posts:
>
> http://mom.hlmjr.com/2017/09/09/driver-wars-nvidia-drivers-384-69-vs-kernel-4-13/
>
> https://devtalk.nvidia.com/default/topic/1023822/linux/-patch-384-69-kernel-4-13-4-14-staging-/
>
> It refers to 4.14-rc1 but I saw the identical issues on 4.13.2-200 with
> this.
>
> Is this something worth holding back on the kernel release on F26 for the
> time being?

Absolutely not.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 15 September 2017 at 11:00, James Hogarth 
wrote:

>
>
> On 13 September 2017 at 01:39, James Hogarth 
> wrote:
>
>>
>>
>> On 12 Sep 2017 10:49 pm, "Laura Abbott"  wrote:
>>
>> 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, typically
>>> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
>>> does not give release dates for stable release but given past
>>> timings, this will probably happen towards the end of September.
>>> As always, if you have any questions please let me know.
>>>
>>> Thanks,
>>> Laura
>>>
>>>
>> 4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
>> this morning but given it was released in conjunction with a new
>> publicized CVE, it was slightly smaller and I'm inclined to wait
>> for 4.13.3 before attempting to push anything to bodhi for F26.
>>
>>
>>
>> Thanks for the update Laura
>>
>> I'll pop that on my system tomorrow for some early testing and when
>> you're ready with the bodhi update will add the feedback.
>>
>>
> Hi,
>
> Installed and running well here:
>
> Intel® Core™ i5-6300HQ CPU @ 2.30GHz × 4 Intel® HD Graphics 530 (Skylake
> GT2) / Nvidia-bumblebee 384.69 on NV117
>
> WiFI working, bluetooth working, GPU works still.
>
> Ran through both the default and performance kernel regression tests[0] -
> both passed.
>
> https://apps.fedoraproject.org/kerneltest/kernel/4.13.1-200.fc26.x86_64
>
> Incidentally I enabled the bfq scheduler for my spinning rust large data
> drive and kyber for my SSD (since they have had some time to initially "bed
> in" in 4.12)  and the system feels noticeably more responsive than on cfq
> before ... though I wonder how much is a placebo effect ... might be fun to
> switch it up and do some bonnie and iozone testing at some point.
>
> Cheers,
>
> James
>
>
> [0] https://fedoraproject.org/wiki/KernelTestingInitiative
>


Something happened in the 4.13.2 release which broke the nvidia driver.

A few symbols changed and there was something that flipped to a GPL
labelled symbol.

I know we don't directly provide that for various reasons, but there is the
initiative with Negativo etc that the Workstation Working Group has
highlighted several times.

See these posts:

http://mom.hlmjr.com/2017/09/09/driver-wars-nvidia-drivers-384-69-vs-kernel-4-13/

https://devtalk.nvidia.com/default/topic/1023822/linux/-patch-384-69-kernel-4-13-4-14-staging-/

It refers to 4.14-rc1 but I saw the identical issues on 4.13.2-200 with
this.

Is this something worth holding back on the kernel release on F26 for the
time being?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 13 September 2017 at 01:39, James Hogarth 
wrote:

>
>
> On 12 Sep 2017 10:49 pm, "Laura Abbott"  wrote:
>
> 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, typically
>> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
>> does not give release dates for stable release but given past
>> timings, this will probably happen towards the end of September.
>> As always, if you have any questions please let me know.
>>
>> Thanks,
>> Laura
>>
>>
> 4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
> this morning but given it was released in conjunction with a new
> publicized CVE, it was slightly smaller and I'm inclined to wait
> for 4.13.3 before attempting to push anything to bodhi for F26.
>
>
>
> Thanks for the update Laura
>
> I'll pop that on my system tomorrow for some early testing and when you're
> ready with the bodhi update will add the feedback.
>
>
Hi,

Installed and running well here:

Intel® Core™ i5-6300HQ CPU @ 2.30GHz × 4 Intel® HD Graphics 530 (Skylake
GT2) / Nvidia-bumblebee 384.69 on NV117

WiFI working, bluetooth working, GPU works still.

Ran through both the default and performance kernel regression tests[0] -
both passed.

https://apps.fedoraproject.org/kerneltest/kernel/4.13.1-200.fc26.x86_64

Incidentally I enabled the bfq scheduler for my spinning rust large data
drive and kyber for my SSD (since they have had some time to initially "bed
in" in 4.12)  and the system feels noticeably more responsive than on cfq
before ... though I wonder how much is a placebo effect ... might be fun to
switch it up and do some bonnie and iozone testing at some point.

Cheers,

James


[0] https://fedoraproject.org/wiki/KernelTestingInitiative
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 12 Sep 2017 10:49 pm, "Laura Abbott"  wrote:

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, typically
> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
> does not give release dates for stable release but given past
> timings, this will probably happen towards the end of September.
> As always, if you have any questions please let me know.
>
> Thanks,
> Laura
>
>
4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
this morning but given it was released in conjunction with a new
publicized CVE, it was slightly smaller and I'm inclined to wait
for 4.13.3 before attempting to push anything to bodhi for F26.



Thanks for the update Laura

I'll pop that on my system tomorrow for some early testing and when you're
ready with the bodhi update will add the feedback.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Laura Abbott]

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, typically
4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
does not give release dates for stable release but given past
timings, this will probably happen towards the end of September.
As always, if you have any questions please let me know.

Thanks,
Laura



4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
this morning but given it was released in conjunction with a new
publicized CVE, it was slightly smaller and I'm inclined to wait
for 4.13.3 before attempting to push anything to bodhi for F26.

Thanks,
Laura
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Petr Šabata]

On Tue, Sep 05, 2017 at 06:39:29PM -0400, Josh Boyer wrote:
> On Tue, Sep 5, 2017 at 6:25 PM, James Hogarth  wrote:
> >
> >
> > On 5 September 2017 at 22:40, Chris Murphy  wrote:
> >>
> >> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy 
> >> wrote:
> >>
> >> > FWIW, you can just download the F27 kernel, kernel-core,
> >> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
> >> > that same download directory and it will install it without complaint.
> >> > I routinely run Fedora built n+1 (typically rawhide) kernels on
> >> > current release OS.
> >>
> >> Small gotcha is that you can't upgrade perf, dnf will complain. But
> >> usually rudimentary use of current perf will work with a newer kernel.
> >>
> >>
> >>
> >
> > Right ... with kernel-tools and perf I'd rather have something built against
> > the F26 userspace ... but I have run the rawhidenodebug kernels in the past
> > for testing ... it's just nicer and more representative for testing what
> > will end up in the F26 repos to have the kernel built against F26 in the
> > stabilization COPR
> 
> I've suggested in the past that we ship the userspace tools in a
> completely separate package, leaving ONLY kernel bits in the kernel
> SRPM and subpackages.  Partly for this reason, and also because there
> is no NEED to build e.g. perf daily.  I'm willing to put my money
> where my mouth is and do the maintenance on the userspace side if
> people want to pursue this.

+1

P


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Josh Boyer]

On Tue, Sep 5, 2017 at 6:25 PM, James Hogarth  wrote:
>
>
> On 5 September 2017 at 22:40, Chris Murphy  wrote:
>>
>> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy 
>> wrote:
>>
>> > FWIW, you can just download the F27 kernel, kernel-core,
>> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
>> > that same download directory and it will install it without complaint.
>> > I routinely run Fedora built n+1 (typically rawhide) kernels on
>> > current release OS.
>>
>> Small gotcha is that you can't upgrade perf, dnf will complain. But
>> usually rudimentary use of current perf will work with a newer kernel.
>>
>>
>>
>
> Right ... with kernel-tools and perf I'd rather have something built against
> the F26 userspace ... but I have run the rawhidenodebug kernels in the past
> for testing ... it's just nicer and more representative for testing what
> will end up in the F26 repos to have the kernel built against F26 in the
> stabilization COPR

I've suggested in the past that we ship the userspace tools in a
completely separate package, leaving ONLY kernel bits in the kernel
SRPM and subpackages.  Partly for this reason, and also because there
is no NEED to build e.g. perf daily.  I'm willing to put my money
where my mouth is and do the maintenance on the userspace side if
people want to pursue this.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Josh Boyer]

On Tue, Sep 5, 2017 at 6:25 PM, James Hogarth  wrote:
>
>
> On 5 September 2017 at 22:40, Chris Murphy  wrote:
>>
>> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy 
>> wrote:
>>
>> > FWIW, you can just download the F27 kernel, kernel-core,
>> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
>> > that same download directory and it will install it without complaint.
>> > I routinely run Fedora built n+1 (typically rawhide) kernels on
>> > current release OS.
>>
>> Small gotcha is that you can't upgrade perf, dnf will complain. But
>> usually rudimentary use of current perf will work with a newer kernel.
>>
>>
>>
>
> Right ... with kernel-tools and perf I'd rather have something built against
> the F26 userspace ... but I have run the rawhidenodebug kernels in the past
> for testing ... it's just nicer and more representative for testing what
> will end up in the F26 repos to have the kernel built against F26 in the
> stabilization COPR

I've suggested in the past that we ship the userspace tools in a
completely separate package, leaving ONLY kernel bits in the kernel
SRPM and subpackages.  Partly for this reason, and also because there
is no NEED to build e.g. perf daily.  I'm willing to put my money
where my mouth is and do the maintenance on the userspace side if
people want to pursue this.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 5 September 2017 at 22:40, Chris Murphy  wrote:

> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy 
> wrote:
>
> > FWIW, you can just download the F27 kernel, kernel-core,
> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
> > that same download directory and it will install it without complaint.
> > I routinely run Fedora built n+1 (typically rawhide) kernels on
> > current release OS.
>
> Small gotcha is that you can't upgrade perf, dnf will complain. But
> usually rudimentary use of current perf will work with a newer kernel.
>
>
>
>
Right ... with kernel-tools and perf I'd rather have something built
against the F26 userspace ... but I have run the rawhidenodebug kernels in
the past for testing ... it's just nicer and more representative for
testing what will end up in the F26 repos to have the kernel built against
F26 in the stabilization COPR
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Chris Murphy]

On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy  wrote:

> FWIW, you can just download the F27 kernel, kernel-core,
> kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
> that same download directory and it will install it without complaint.
> I routinely run Fedora built n+1 (typically rawhide) kernels on
> current release OS.

Small gotcha is that you can't upgrade perf, dnf will complain. But
usually rudimentary use of current perf will work with a newer kernel.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Chris Murphy]

On Tue, Sep 5, 2017 at 3:13 PM, James Hogarth  wrote:
>
>
> On 5 September 2017 at 18:26, Laura Abbott  wrote:
>>
>> On 09/05/2017 09:59 AM, James Hogarth wrote:
>> >
>> >
>> > On 5 Sep 2017 5:42 pm, "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, typically
>> > 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
>> > does not give release dates for stable release but given past
>> > timings, this will probably happen towards the end of September.
>> > As always, if you have any questions please let me know.
>> >
>> >
>> > Thanks for the heads up Laura
>> >
>> > Will there be a stabilization COPR for us to test the builds against/on
>> > F26?
>> >
>>
>> Yes, I can throw that in the stabilization copr once I start working on
>> the rebase. I might have a very early 4.13.0 to test by the end of
>> the week but no promises.
>>
>>
>>
>
> That's great thanks ... I'd be happy to test the builds and provide early
> feedback on my laptop ... but as I can't risk it going boom I'm not able to
> update it to F27 until further through the release schedule.
>
> Having an F26 build of the upcoming kernel makes early testing simple though
> :)

FWIW, you can just download the F27 kernel, kernel-core,
kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
that same download directory and it will install it without complaint.
I routinely run Fedora built n+1 (typically rawhide) kernels on
current release OS.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 5 September 2017 at 18:26, Laura Abbott  wrote:

> On 09/05/2017 09:59 AM, James Hogarth wrote:
> >
> >
> > On 5 Sep 2017 5:42 pm, "Laura Abbott"  labb...@redhat.com>> 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, typically
> > 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
> > does not give release dates for stable release but given past
> > timings, this will probably happen towards the end of September.
> > As always, if you have any questions please let me know.
> >
> >
> > Thanks for the heads up Laura
> >
> > Will there be a stabilization COPR for us to test the builds against/on
> F26?
> >
>
> Yes, I can throw that in the stabilization copr once I start working on
> the rebase. I might have a very early 4.13.0 to test by the end of
> the week but no promises.
>
>
>
>
That's great thanks ... I'd be happy to test the builds and provide early
feedback on my laptop ... but as I can't risk it going boom I'm not able to
update it to F27 until further through the release schedule.

Having an F26 build of the upcoming kernel makes early testing simple
though :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Thorsten Leemhuis]

On 05.09.2017 18:59, James Hogarth wrote:
> On 5 Sep 2017 5:42 pm, "Laura Abbott"  > wrote:
>
> 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 stable the kernel is. Upstream
> does not give release dates for stable release but given past
> timings, this will probably happen towards the end of September.
> As always, if you have any questions please let me know.
> Thanks for the heads up Laura
> Will there be a stabilization COPR for us to test the builds against/on F26?

Shameless plug: If you want to get Linux 4.13 now you can also run this:

curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo |
sudo tee /etc/yum.repos.d/kernel-vanilla.repo
sudo dnf --enablerepo=kernel-vanilla-stable update

This will install a vanilla kernel from the kernel vanilla stable repo,
where is landed yesterday. For more details and other kernel vanilla
repos (mainline, mainline-wo-mergew & fedora) please see
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories &
https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories-FAQ

HTH, CU, knurd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Laura Abbott]

On 09/05/2017 09:59 AM, James Hogarth wrote:
> 
> 
> On 5 Sep 2017 5:42 pm, "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, typically
> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
> does not give release dates for stable release but given past
> timings, this will probably happen towards the end of September.
> As always, if you have any questions please let me know.
> 
> 
> Thanks for the heads up Laura
> 
> Will there be a stabilization COPR for us to test the builds against/on F26?
> 

Yes, I can throw that in the stabilization copr once I start working on
the rebase. I might have a very early 4.13.0 to test by the end of
the week but no promises.

Thanks,
Laura
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 5 Sep 2017 5:42 pm, "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, typically
4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
does not give release dates for stable release but given past
timings, this will probably happen towards the end of September.
As always, if you have any questions please let me know.


Thanks for the heads up Laura

Will there be a stabilization COPR for us to test the builds against/on F26?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Kernel 4.13 rebase plans

[Laura Abbott]

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 stable the kernel is. Upstream
does not give release dates for stable release but given past
timings, this will probably happen towards the end of September.
As always, if you have any questions please let me know.

Thanks,
Laura
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org