Hi all,
Changes since 20190403:
The sound-asoc tree lost its build failure.
The mfd tree lost its build failure.
The selinux tree lost its build failure.
The ipmi tree lost its build failure.
The staging tree gained conflicts against the spi and v4l-dvb trees.
Non-merge commits (relative to
On Fri 2018-04-20 15:30:03, Daniel Micay wrote:
> Well, that's not related, it's just this:
>
> #ifdef __GNUC__
> #if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
> #error Your compiler is too buggy; it is known to miscompile kernels.
> #errorKnown good compilers: 3.3, 4.x
> #endif
> #if GCC_VERSION
On Fri 2018-04-20 15:30:03, Daniel Micay wrote:
> Well, that's not related, it's just this:
>
> #ifdef __GNUC__
> #if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
> #error Your compiler is too buggy; it is known to miscompile kernels.
> #errorKnown good compilers: 3.3, 4.x
> #endif
> #if GCC_VERSION
Well, that's not related, it's just this:
#ifdef __GNUC__
#if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
#error Your compiler is too buggy; it is known to miscompile kernels.
#errorKnown good compilers: 3.3, 4.x
#endif
#if GCC_VERSION >= 40800 && GCC_VERSION < 40803
#error Your compiler is too
Well, that's not related, it's just this:
#ifdef __GNUC__
#if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
#error Your compiler is too buggy; it is known to miscompile kernels.
#errorKnown good compilers: 3.3, 4.x
#endif
#if GCC_VERSION >= 40800 && GCC_VERSION < 40803
#error Your compiler is too
On Fri 2018-04-20 15:18:32, Daniel Micay wrote:
> On 20 April 2018 at 15:15, Pavel Machek wrote:
> > Hi!
> >
> >> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> >> >> a particular subset of arm architectures? (My local builds of arm all
> >> >> succeed,
On Fri 2018-04-20 15:18:32, Daniel Micay wrote:
> On 20 April 2018 at 15:15, Pavel Machek wrote:
> > Hi!
> >
> >> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> >> >> a particular subset of arm architectures? (My local builds of arm all
> >> >> succeed, for example.
On 20 April 2018 at 15:15, Pavel Machek wrote:
> Hi!
>
>> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
>> >> a particular subset of arm architectures? (My local builds of arm all
>> >> succeed, for example. Can you send your failing config?) I'll take a
On 20 April 2018 at 15:15, Pavel Machek wrote:
> Hi!
>
>> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
>> >> a particular subset of arm architectures? (My local builds of arm all
>> >> succeed, for example. Can you send your failing config?) I'll take a
>> >> closer
Hi!
> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> >> a particular subset of arm architectures? (My local builds of arm all
> >> succeed, for example. Can you send your failing config?) I'll take a
> >> closer look on Monday if Daniel doesn't beat me to it.
> >
> >
Hi!
> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to
> >> a particular subset of arm architectures? (My local builds of arm all
> >> succeed, for example. Can you send your failing config?) I'll take a
> >> closer look on Monday if Daniel doesn't beat me to it.
> >
> >
On Fri, Apr 20, 2018 at 08:05:17AM -0700, Kees Cook wrote:
> On Fri, Apr 20, 2018 at 12:34 AM, Pavel Machek wrote:
> > On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> >> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
> >> > Hi!
> >> >
> >> >> Thanks.
> >> >>
>
On Fri, Apr 20, 2018 at 08:05:17AM -0700, Kees Cook wrote:
> On Fri, Apr 20, 2018 at 12:34 AM, Pavel Machek wrote:
> > On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> >> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
> >> > Hi!
> >> >
> >> >> Thanks.
> >> >>
> >> >> Ok, let me try to
On Fri, Apr 20, 2018 at 12:34 AM, Pavel Machek wrote:
> On Sun 2018-04-15 11:00:06, Kees Cook wrote:
>> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
>> > Hi!
>> >
>> >> Thanks.
>> >>
>> >> Ok, let me try to bisect it. Compile-problem should be easy...
>> >>
On Fri, Apr 20, 2018 at 12:34 AM, Pavel Machek wrote:
> On Sun 2018-04-15 11:00:06, Kees Cook wrote:
>> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
>> > Hi!
>> >
>> >> Thanks.
>> >>
>> >> Ok, let me try to bisect it. Compile-problem should be easy...
>> >>
>> >> Hmm. And as it is
On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
> > Hi!
> >
> >> Thanks.
> >>
> >> Ok, let me try to bisect it. Compile-problem should be easy...
> >>
> >> Hmm. And as it is compile-problem in single file, it should even be
> >>
On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
> > Hi!
> >
> >> Thanks.
> >>
> >> Ok, let me try to bisect it. Compile-problem should be easy...
> >>
> >> Hmm. And as it is compile-problem in single file, it should even be
> >> reasonably
On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
> > Hi!
> >
> >> Thanks.
> >>
> >> Ok, let me try to bisect it. Compile-problem should be easy...
> >>
> >> Hmm. And as it is compile-problem in single file, it should even be
> >>
On Sun 2018-04-15 11:00:06, Kees Cook wrote:
> On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
> > Hi!
> >
> >> Thanks.
> >>
> >> Ok, let me try to bisect it. Compile-problem should be easy...
> >>
> >> Hmm. And as it is compile-problem in single file, it should even be
> >> reasonably
On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
> Hi!
>
>> Thanks.
>>
>> Ok, let me try to bisect it. Compile-problem should be easy...
>>
>> Hmm. And as it is compile-problem in single file, it should even be
>> reasonably fast. I did not realize how easy it would be:
>>
>>
On Sun, Apr 15, 2018 at 10:39 AM, Pavel Machek wrote:
> Hi!
>
>> Thanks.
>>
>> Ok, let me try to bisect it. Compile-problem should be easy...
>>
>> Hmm. And as it is compile-problem in single file, it should even be
>> reasonably fast. I did not realize how easy it would be:
>>
>> #!/bin/bash
>>
Hi!
> Thanks.
>
> Ok, let me try to bisect it. Compile-problem should be easy...
>
> Hmm. And as it is compile-problem in single file, it should even be
> reasonably fast. I did not realize how easy it would be:
>
> #!/bin/bash
> set -e
> cp config.ok .config
> yes '' | ARCH=arm make
Hi!
> Thanks.
>
> Ok, let me try to bisect it. Compile-problem should be easy...
>
> Hmm. And as it is compile-problem in single file, it should even be
> reasonably fast. I did not realize how easy it would be:
>
> #!/bin/bash
> set -e
> cp config.ok .config
> yes '' | ARCH=arm make
On Wed 2018-04-04 09:50:47, Pavel Machek wrote:
> Hi!
>
> > Please do not add any v4.18 destined stuff to your linux-next included
> > trees until after v4.17-rc1 has been released.
>
> On thinkpad x60, suspend does not suspend at all with this -next
> version. Previous versions
On Wed 2018-04-04 09:50:47, Pavel Machek wrote:
> Hi!
>
> > Please do not add any v4.18 destined stuff to your linux-next included
> > trees until after v4.17-rc1 has been released.
>
> On thinkpad x60, suspend does not suspend at all with this -next
> version. Previous versions
On Thursday, April 5, 2018 10:30:45 PM CEST Pavel Machek wrote:
> Hi!
>
> > > Well, v4.16-rc4 is parent of v4.16-rc6, but next-20180304 is not
> > > parent of next-20180307.
> > >
> > > But you are right that if I do bisect between -linus and -next, it
> > > should work.
> > >
> > > Anyway,
On Thursday, April 5, 2018 10:30:45 PM CEST Pavel Machek wrote:
> Hi!
>
> > > Well, v4.16-rc4 is parent of v4.16-rc6, but next-20180304 is not
> > > parent of next-20180307.
> > >
> > > But you are right that if I do bisect between -linus and -next, it
> > > should work.
> > >
> > > Anyway,
Hi!
> > Well, v4.16-rc4 is parent of v4.16-rc6, but next-20180304 is not
> > parent of next-20180307.
> >
> > But you are right that if I do bisect between -linus and -next, it
> > should work.
> >
> > Anyway, does s2ram work for you in -next? Are you testing 32bit?
>
> Hmm. I tested on T40p.
Hi!
> > Well, v4.16-rc4 is parent of v4.16-rc6, but next-20180304 is not
> > parent of next-20180307.
> >
> > But you are right that if I do bisect between -linus and -next, it
> > should work.
> >
> > Anyway, does s2ram work for you in -next? Are you testing 32bit?
>
> Hmm. I tested on T40p.
On Wed 2018-04-04 10:49:05, Pavel Machek wrote:
> On Wed 2018-04-04 09:58:17, Rafael J. Wysocki wrote:
> > On Wed, Apr 4, 2018 at 9:50 AM, Pavel Machek wrote:
> > > Hi!
> > >
> > >> Please do not add any v4.18 destined stuff to your linux-next included
> > >> trees until after
On Wed 2018-04-04 10:49:05, Pavel Machek wrote:
> On Wed 2018-04-04 09:58:17, Rafael J. Wysocki wrote:
> > On Wed, Apr 4, 2018 at 9:50 AM, Pavel Machek wrote:
> > > Hi!
> > >
> > >> Please do not add any v4.18 destined stuff to your linux-next included
> > >> trees until after v4.17-rc1 has been
On Wed 2018-04-04 12:59:51, Tony Lindgren wrote:
> * Pavel Machek [180404 18:47]:
> > Hi!
> >
> > > > When trying to build kernel for N900, I get:
> > > >
> > > > CC lib/timerqueue.o
> > > > CC lib/vsprintf.o
> > > > lib/string.c: In function 'strstr':
> > > >
On Wed 2018-04-04 12:59:51, Tony Lindgren wrote:
> * Pavel Machek [180404 18:47]:
> > Hi!
> >
> > > > When trying to build kernel for N900, I get:
> > > >
> > > > CC lib/timerqueue.o
> > > > CC lib/vsprintf.o
> > > > lib/string.c: In function 'strstr':
> > > >
* Pavel Machek [180404 18:47]:
> Hi!
>
> > > When trying to build kernel for N900, I get:
> > >
> > > CC lib/timerqueue.o
> > > CC lib/vsprintf.o
> > > lib/string.c: In function 'strstr':
> > > lib/string.c:478:8: error: inlining failed in call to
> > >
* Pavel Machek [180404 18:47]:
> Hi!
>
> > > When trying to build kernel for N900, I get:
> > >
> > > CC lib/timerqueue.o
> > > CC lib/vsprintf.o
> > > lib/string.c: In function 'strstr':
> > > lib/string.c:478:8: error: inlining failed in call to
> > > always_inline
Hi!
> > When trying to build kernel for N900, I get:
> >
> > CC lib/timerqueue.o
> > CC lib/vsprintf.o
> > lib/string.c: In function 'strstr':
> > lib/string.c:478:8: error: inlining failed in call to
> > always_inline 'strlen': function not inlinable
> >
Hi!
> > When trying to build kernel for N900, I get:
> >
> > CC lib/timerqueue.o
> > CC lib/vsprintf.o
> > lib/string.c: In function 'strstr':
> > lib/string.c:478:8: error: inlining failed in call to
> > always_inline 'strlen': function not inlinable
> >
Hi!
> > > Please do not add any v4.18 destined stuff to your linux-next included
> > > trees until after v4.17-rc1 has been released.
> > >
> > > Changes since 20180403:
> > >
> > > The vfs tree still had its build failure for which I reverted a commit.
> > >
> > > Non-merge commits (relative
Hi!
> > > Please do not add any v4.18 destined stuff to your linux-next included
> > > trees until after v4.17-rc1 has been released.
> > >
> > > Changes since 20180403:
> > >
> > > The vfs tree still had its build failure for which I reverted a commit.
> > >
> > > Non-merge commits (relative
* Pavel Machek [180404 07:50]:
> Hi!
>
> > Please do not add any v4.18 destined stuff to your linux-next included
> > trees until after v4.17-rc1 has been released.
> >
> > Changes since 20180403:
> >
> > The vfs tree still had its build failure for which I reverted a commit.
> >
* Pavel Machek [180404 07:50]:
> Hi!
>
> > Please do not add any v4.18 destined stuff to your linux-next included
> > trees until after v4.17-rc1 has been released.
> >
> > Changes since 20180403:
> >
> > The vfs tree still had its build failure for which I reverted a commit.
> >
> >
On Wed 2018-04-04 09:58:17, Rafael J. Wysocki wrote:
> On Wed, Apr 4, 2018 at 9:50 AM, Pavel Machek wrote:
> > Hi!
> >
> >> Please do not add any v4.18 destined stuff to your linux-next included
> >> trees until after v4.17-rc1 has been released.
> >
> > On thinkpad x60, suspend
On Wed 2018-04-04 09:58:17, Rafael J. Wysocki wrote:
> On Wed, Apr 4, 2018 at 9:50 AM, Pavel Machek wrote:
> > Hi!
> >
> >> Please do not add any v4.18 destined stuff to your linux-next included
> >> trees until after v4.17-rc1 has been released.
> >
> > On thinkpad x60, suspend does not suspend
On Wed, Apr 4, 2018 at 9:50 AM, Pavel Machek wrote:
> Hi!
>
>> Please do not add any v4.18 destined stuff to your linux-next included
>> trees until after v4.17-rc1 has been released.
>
> On thinkpad x60, suspend does not suspend at all with this -next
> version. Previous versions
On Wed, Apr 4, 2018 at 9:50 AM, Pavel Machek wrote:
> Hi!
>
>> Please do not add any v4.18 destined stuff to your linux-next included
>> trees until after v4.17-rc1 has been released.
>
> On thinkpad x60, suspend does not suspend at all with this -next
> version. Previous versions
Hi!
> Please do not add any v4.18 destined stuff to your linux-next included
> trees until after v4.17-rc1 has been released.
On thinkpad x60, suspend does not suspend at all with this -next
version. Previous versions suspended/resumed fine but broke networking.
Any ideas? I guess bisecting on
Hi!
> Please do not add any v4.18 destined stuff to your linux-next included
> trees until after v4.17-rc1 has been released.
On thinkpad x60, suspend does not suspend at all with this -next
version. Previous versions suspended/resumed fine but broke networking.
Any ideas? I guess bisecting on
Hi!
> Please do not add any v4.18 destined stuff to your linux-next included
> trees until after v4.17-rc1 has been released.
>
> Changes since 20180403:
>
> The vfs tree still had its build failure for which I reverted a commit.
>
> Non-merge commits (relative to Linus' tree): 8505
> 8493
Hi!
> Please do not add any v4.18 destined stuff to your linux-next included
> trees until after v4.17-rc1 has been released.
>
> Changes since 20180403:
>
> The vfs tree still had its build failure for which I reverted a commit.
>
> Non-merge commits (relative to Linus' tree): 8505
> 8493
Hi all,
Please do not add any v4.18 destined stuff to your linux-next included
trees until after v4.17-rc1 has been released.
Changes since 20180403:
The vfs tree still had its build failure for which I reverted a commit.
Non-merge commits (relative to Linus' tree): 8505
8493 files changed,
Hi all,
Please do not add any v4.18 destined stuff to your linux-next included
trees until after v4.17-rc1 has been released.
Changes since 20180403:
The vfs tree still had its build failure for which I reverted a commit.
Non-merge commits (relative to Linus' tree): 8505
8493 files changed,
Hi all,
Changes since 20170403:
New tree: sunxi-drm
The net-next tree gained a conflict against the net tree.
The keys tree gained a build failure so I used the version from
next-20170403.
The vhost tree still had its build failure, so I used the version from
next-20170329.
The mfd tree
Hi all,
Changes since 20170403:
New tree: sunxi-drm
The net-next tree gained a conflict against the net tree.
The keys tree gained a build failure so I used the version from
next-20170403.
The vhost tree still had its build failure, so I used the version from
next-20170329.
The mfd tree
On Tue, Apr 12, 2016 at 06:34:08PM +0200, Martin Schwidefsky wrote:
> On Mon, 4 Apr 2016 16:26:35 +0200
> Heiko Carstens wrote:
>
> > On Mon, Apr 04, 2016 at 05:51:09PM +0530, Sudip Mukherjee wrote:
> > > On Monday 04 April 2016 09:39 AM, Stephen Rothwell wrote:
> > >
On Tue, Apr 12, 2016 at 06:34:08PM +0200, Martin Schwidefsky wrote:
> On Mon, 4 Apr 2016 16:26:35 +0200
> Heiko Carstens wrote:
>
> > On Mon, Apr 04, 2016 at 05:51:09PM +0530, Sudip Mukherjee wrote:
> > > On Monday 04 April 2016 09:39 AM, Stephen Rothwell wrote:
> > > >Hi all,
> > > >
> > >
On Mon, 4 Apr 2016 16:26:35 +0200
Heiko Carstens wrote:
> On Mon, Apr 04, 2016 at 05:51:09PM +0530, Sudip Mukherjee wrote:
> > On Monday 04 April 2016 09:39 AM, Stephen Rothwell wrote:
> > >Hi all,
> > >
> > >Changes since 20160401:
> >
> > s390 allmodconfig build
On Mon, 4 Apr 2016 16:26:35 +0200
Heiko Carstens wrote:
> On Mon, Apr 04, 2016 at 05:51:09PM +0530, Sudip Mukherjee wrote:
> > On Monday 04 April 2016 09:39 AM, Stephen Rothwell wrote:
> > >Hi all,
> > >
> > >Changes since 20160401:
> >
> > s390 allmodconfig build fails with the error:
> >
> >
On Mon, Apr 04, 2016 at 05:51:09PM +0530, Sudip Mukherjee wrote:
> On Monday 04 April 2016 09:39 AM, Stephen Rothwell wrote:
> >Hi all,
> >
> >Changes since 20160401:
>
> s390 allmodconfig build fails with the error:
>
> arch/s390/crypto/ghash_s390.c:14:24: fatal error: crypt_s390.h: No
> such
On Mon, Apr 04, 2016 at 05:51:09PM +0530, Sudip Mukherjee wrote:
> On Monday 04 April 2016 09:39 AM, Stephen Rothwell wrote:
> >Hi all,
> >
> >Changes since 20160401:
>
> s390 allmodconfig build fails with the error:
>
> arch/s390/crypto/ghash_s390.c:14:24: fatal error: crypt_s390.h: No
> such
On Monday 04 April 2016 09:39 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20160401:
s390 allmodconfig build fails with the error:
arch/s390/crypto/ghash_s390.c:14:24: fatal error: crypt_s390.h: No such
file or directory
#include "crypt_s390.h"
^
build log is
On Monday 04 April 2016 09:39 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20160401:
s390 allmodconfig build fails with the error:
arch/s390/crypto/ghash_s390.c:14:24: fatal error: crypt_s390.h: No such
file or directory
#include "crypt_s390.h"
^
build log is
Hi all,
Changes since 20160401:
My fixes tree is empty again.
The qcom tree lost its build failure.
The pm tree lost its build failure.
The akpm tree lost a patch that turned up elsewhere.
Non-merge commits (relative to Linus' tree): 1950
1797 files changed, 75443 insertions(+), 50320
Hi all,
Changes since 20160401:
My fixes tree is empty again.
The qcom tree lost its build failure.
The pm tree lost its build failure.
The akpm tree lost a patch that turned up elsewhere.
Non-merge commits (relative to Linus' tree): 1950
1797 files changed, 75443 insertions(+), 50320
On 04/04/13 00:22, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130403:
>
on x86_64, when CONFIG_BUG is not enabled:
CC [M] drivers/usb/gadget/configfs.o
drivers/usb/gadget/configfs.c: In function 'config_usb_cfg_unlink':
drivers/usb/gadget/configfs.c:442:2: error: implicit
Hi all,
Changes since 20130403:
The ext4 tree gained a build failure so I used the version from
next-20130403.
The nfsd tree lost its build failure.
The vfs tree lost its build failure.
The net-next tree gained a conflict against the wireless tree.
The wireless-next tree lost its build
Hi all,
Changes since 20130403:
The ext4 tree gained a build failure so I used the version from
next-20130403.
The nfsd tree lost its build failure.
The vfs tree lost its build failure.
The net-next tree gained a conflict against the wireless tree.
The wireless-next tree lost its build
On 04/04/13 00:22, Stephen Rothwell wrote:
Hi all,
Changes since 20130403:
on x86_64, when CONFIG_BUG is not enabled:
CC [M] drivers/usb/gadget/configfs.o
drivers/usb/gadget/configfs.c: In function 'config_usb_cfg_unlink':
drivers/usb/gadget/configfs.c:442:2: error: implicit
67 matches
Mail list logo