Re: [PATCH] 4.18-rc7 on alpha: bitsperlong issue

2019-01-21 Thread Matt Turner
On Mon, Jan 21, 2019 at 1:42 PM Bob Tracy  wrote:
>
> Apologies for what is essentially a repost with a proper subject header
> in the sense of trying to get the attention of people who collect/approve
> patches for submission upstream.  See my posting from earlier today
> (followup: [FTBFS] kernel 4.18-rc7 bitsperlong.h issue on alpha) for the
> back story.  As mentioned there, this patch applies cleanly to at least
> all mainline kernel source trees >= version 4.18.
>
> Further apologies for including the patch as an attachment, but I don't
> trust my mailer not to impose unintended formatting.

Thanks Bob. I've vacuumed the patch up and will include it in a pull req soon.



[PATCH] 4.18-rc7 on alpha: bitsperlong issue

2019-01-21 Thread Bob Tracy
Apologies for what is essentially a repost with a proper subject header
in the sense of trying to get the attention of people who collect/approve
patches for submission upstream.  See my posting from earlier today
(followup: [FTBFS] kernel 4.18-rc7 bitsperlong.h issue on alpha) for the
back story.  As mentioned there, this patch applies cleanly to at least
all mainline kernel source trees >= version 4.18.

Further apologies for including the patch as an attachment, but I don't
trust my mailer not to impose unintended formatting.

--Bob

Signed-off-by: Bob Tracy 
Tested-by: Bob Tracy 
--- a/tools/include/uapi/asm/bitsperlong.h  2019-01-20 14:40:32.522422998 
-0600
+++ b/tools/include/uapi/asm/bitsperlong.h  2019-01-21 09:51:45.336938260 
-0600
@@ -13,6 +13,8 @@
 #include "../../arch/mips/include/uapi/asm/bitsperlong.h"
 #elif defined(__ia64__)
 #include "../../arch/ia64/include/uapi/asm/bitsperlong.h"
+#elif defined(__alpha__)
+#include "../../arch/alpha/include/uapi/asm/bitsperlong.h"
 #else
 #include 
 #endif


followup: [FTBFS] kernel 4.18-rc7 bitsperlong.h issue on alpha

2019-01-21 Thread Bob Tracy
July 30, 2018 I reported the following to linux-kernel, linux-alpha, etc.:

On an alpha system, got the following build error on the 4.18-rc7
mainline kernel source tree:

  HOSTCC  net/bpfilter/main.o
In file included from tools/include/uapi/asm/bitsperlong.h:17,
 from /usr/include/asm-generic/int-ll64.h:12,
 from /usr/include/alpha-linux-gnu/asm/types.h:24,
 from tools/include/linux/types.h:10,
 from ./include/uapi/linux/bpf.h:11,
 from net/bpfilter/main.c:9:
tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word 
size.  Check asm/bitsperlong.h
 #error Inconsistent word size.  Check asm/bitsperlong.h
  ^
scripts/Makefile.host:107: recipe for target 'net/bpfilter/main.o' failed
make[2]: *** [net/bpfilter/main.o] Error 1
scripts/Makefile.build:558: recipe for target 'net/bpfilter' failed
make[1]: *** [net/bpfilter] Error 2
Makefile:1029: recipe for target 'net' failed
make: *** [net] Error 2


I implemented a crap workaround at the time in
"linux/tools/include/asm-generic/bitsperlong.h", similar to what some
frustrated person did for the x86-64 case in
"linux/include/asm-generic/bitsperlong.h".  Never sent that in because I
knew it was the wrong approach.

The proper fix is attached.  If needed, consider this my official
"signed off by" and/or "tested by".  This applies cleanly to at least
all kernel mainline source trees from 4.18 to current.

Thanks.
--Bob
--- a/tools/include/uapi/asm/bitsperlong.h  2019-01-20 14:40:32.522422998 
-0600
+++ b/tools/include/uapi/asm/bitsperlong.h  2019-01-21 09:51:45.336938260 
-0600
@@ -13,6 +13,8 @@
 #include "../../arch/mips/include/uapi/asm/bitsperlong.h"
 #elif defined(__ia64__)
 #include "../../arch/ia64/include/uapi/asm/bitsperlong.h"
+#elif defined(__alpha__)
+#include "../../arch/alpha/include/uapi/asm/bitsperlong.h"
 #else
 #include 
 #endif


Updated installation images 2019-01-21

2019-01-21 Thread John Paul Adrian Glaubitz
Hello!

I have created updated installation images for Debian Ports,
please find the updated images below and test them [1].

Feedback welcome.

Adrian

> [1] https://cdimage.debian.org/cdimage/ports/2019-01-21/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Updated installation images 2019-01-20

2019-01-21 Thread Michael Cree
On Mon, Jan 21, 2019 at 10:09:29AM +0100, Frank Scheiner wrote:
> Dear Adrian,
> 
> On 1/21/19 00:42, John Paul Adrian Glaubitz wrote:
> > Hi!
> > 
> > On 1/20/19 9:40 PM, Bob Tracy wrote:
> > > Thank you!  I'll give the Alpha version a try in the next few days.
> > > Waiting on a 4.18 kernel build: should be done in the next 24 hours
> > > or so.
> > 
> > The klibc package included in the current images is affected by a
> > serious bug which breaks the boot on nearly all architecture [1].
> > 
> > I will therefore have to build new images once the new klibc package
> > has been synced on the FTP mirrors.
> 
> I did not yet check the ISO for Alpha, but what kernel version and type
> (non-MP/MP) does it include actually?
> 
> Because we had that problem with non-MP kernels not working on many - if
> not all - Alpha machines earlier. And although it was actually fixed by
> Michael, the fix is only included since Linux v5.0-rc1 according to the
> tagging as I understand it, see [1] for details.
> 
> [1]:
> https://github.com/torvalds/linux/commit/6ab7d47bcbf0144a8cb81536c2cead4cde18acfe
> 
> So maybe it'd be better to delay the rebuild until after Linux 5.0
> reaches unstable?

We should get that backported to the stable series.

I've added a comment to:
https://salsa.debian.org/kernel-team/linux/merge_requests/79

Cheers
Michael.



Re: Updated installation images 2019-01-20

2019-01-21 Thread John Paul Adrian Glaubitz
Hi!

On 1/21/19 10:09 AM, Frank Scheiner wrote:
> I did not yet check the ISO for Alpha, but what kernel version and type
> (non-MP/MP) does it include actually?

It always contains the kernel version that was in unstable during the
time when the debian-installer was built, in this case 4.19.16-1:

> https://packages.qa.debian.org/l/linux/news/20190117T230016Z.html

> Because we had that problem with non-MP kernels not working on many - if
> not all - Alpha machines earlier. And although it was actually fixed by
> Michael, the fix is only included since Linux v5.0-rc1 according to the
> tagging as I understand it, see [1] for details.
> 
> [1]:
> https://github.com/torvalds/linux/commit/6ab7d47bcbf0144a8cb81536c2cead4cde18acfe

I see. I don't know, however, when 5.0 will be part of unstable. Mind that
we're going into freeze soonish and we are going to end up with whatever
is the next LTS kernel.

So, it might be possible to backport this fix and open a PR in Salsa.

> So maybe it'd be better to delay the rebuild until after Linux 5.0
> reaches unstable?
Well, I can just continue building new images and put them into a separate
subfolder for testing. We don't need to block the other arches because
of this particular bug.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Updated installation images 2019-01-20

2019-01-21 Thread Frank Scheiner

Dear Adrian,

On 1/21/19 00:42, John Paul Adrian Glaubitz wrote:

Hi!

On 1/20/19 9:40 PM, Bob Tracy wrote:

Thank you!  I'll give the Alpha version a try in the next few days.
Waiting on a 4.18 kernel build: should be done in the next 24 hours
or so.


The klibc package included in the current images is affected by a
serious bug which breaks the boot on nearly all architecture [1].

I will therefore have to build new images once the new klibc package
has been synced on the FTP mirrors.


I did not yet check the ISO for Alpha, but what kernel version and type
(non-MP/MP) does it include actually?

Because we had that problem with non-MP kernels not working on many - if
not all - Alpha machines earlier. And although it was actually fixed by
Michael, the fix is only included since Linux v5.0-rc1 according to the
tagging as I understand it, see [1] for details.

[1]:
https://github.com/torvalds/linux/commit/6ab7d47bcbf0144a8cb81536c2cead4cde18acfe

So maybe it'd be better to delay the rebuild until after Linux 5.0
reaches unstable?

Cheers,
Frank