Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it

[Riku Voipio]

Hi,

On Wed, Dec 02, 2020 at 09:41:01AM +0100, Vincent Bernat wrote:
>  ❦  1 décembre 2020 22:28 +01, Moritz Mühlenhoff:

> > Michael has been heroically keeping up with this beast of a codebase for 
> > years,
> > but we clearly need a broader base to sustain it going forward.

> In the past, it was team-maintained. I don't remember exactly, but I
> think there was a disagreement between Michael and Riku over
> some items, including collaborating on the git repository. Maybe Riku
> can reconsider helping with Chromium?

Chromium is a team effort.. ..in that Michael takes (took?) care of most
things and I focus on keeping chromium working on armhf/arm64. I really
appreceate all the work Michael has done on chromium despite that often
rather harrasive mails from endusers. I don't think I'm stoic enough to
become the main maintainer for chromium.

Regards,
Riku

Bug#971442: qemu: No arm64 package in buster-backports

[Riku Voipio]

tags 971442 + patch
thanks

Hi Michael,

The attached patch should do. If you don't mind, I can do the upload
buster-backports.

Riku
diff --git debian/changelog debian/changelog
index 25ade45560..c9b39f8883 100644
--- debian/changelog
+++ debian/changelog
@@ -1,3 +1,10 @@
+qemu (1:5.0-14~bpo10+2) buster-backports; urgency=medium
+
+  * Rebuild for buster-backports.
+  * Disable libpmem on arm64. Closes: #971442
+
+ -- Riku Voipio   Tue, 17 Nov 2020 14:55:13 +0200
+
 qemu (1:5.0-14~bpo10+1) buster-backports; urgency=medium
 
   * Rebuild for buster-backports.
diff --git debian/control-in debian/control-in
index 44b2af0396..8bd7735574 100644
--- debian/control-in
+++ debian/control-in
@@ -102,8 +102,8 @@ Build-Depends: debhelper-compat (= 12),
  libjpeg-dev,
 # --enable-vnc-png
  libpng-dev,
-# --enable-libpmem	linux-amd64|linux-arm64
- libpmem-dev [linux-amd64 linux-arm64],
+# --enable-libpmem	linux-amd64
+ libpmem-dev [linux-amd64],
 # --enable-kvm		linux-*
 # --enable-vhost-net	linux-*	# is it really linux-specific?
 ##--enable-lzo todo, for (memory) dumps

Bug#970640: ITS: mtd-utils

[Riku Voipio]

Hi,

On Mon, 21 Sep 2020 at 12:29, Bastian Germann
 wrote:
> Hi Riku,
>
> Thanks, please upload the NMU. As I am not a DD, I do not have commit
> access on the salsa repository. Would you please grant me permission
> (Gitlab user bage)?

Both should be done now,

Riku

Bug#970640: ITS: mtd-utils

[Riku Voipio]

On Sun, 20 Sep 2020 at 20:00, Bastian Germann
 wrote:
> I would like to salvage the mtd-utils package. The current maintainer is
> unresponsive on the open issues (2014 was the last answer). His last
> main package action was in August 2019, packging the version 2.1.1-1.
> This year, he sponsored a NMU that I prepared.

> #965155 asks for updating the package to the new version 2.1.2 and I
> handed in the patches to do that two months ago. I once again filed an
> NMU to get this in at #969918 and was encouraged to salvage the package.

I can sponsor the upload again, but feel free to take over the package as well.

Riku

Bug#964188: crashes in latest chromium

[Riku Voipio]

This should fix it:

https://salsa.debian.org/chromium-team/chromium/-/commit/b904fa41d40b967dcc8f6984db52f7a2f6a2c83d

We are not building with GCC but this seems to be exactly the place where the 
crash happens.
chromium built with this patch has not crashed for the last few hours for me, 
while before it would
crash in a few minutes.

Riku

Bug#964145: Chromium slow after security update

[Riku Voipio]

forcemerge 964161 964167 964145
thanks

Bug#931707: linux: HW_RANDOM_OMAP disabled for arm64 --> please enable

[Riku Voipio]

On Mon, 5 Aug 2019 at 03:21, Ben Hutchings  wrote:
>
> On Tue, 2019-07-09 at 12:43 +, Josua Mayer wrote:
> > Source: linux
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > While testing Debian 10 on a Marvell 8040 SoC I found that the rng and SSH 
> > were
> > coming up extremely slow, taking over a minute to start.
> >
> > This is caused by somebody disabling the rng driver for arm64 kernels a 
> > long time ago:
> > linux (4.14.13-1) unstable; urgency=medium
> > ...
> >   [ Riku Voipio ]
> >   * [arm64] disable CONFIG_HW_RANDOM_OMAP until the IRQ storm bug is fixed
> >
> > What is this IRQ storm bug? Has it been fixed? Can we re-enable this driver?
>
> Riku, what do you think?  I see that the MacchiatoBin has an Armada 8K
> SoC, and there was an upstream commit in February 2018 that could be a
> relevant fix:
>
> commit b166be0044913a4ce03564e7c81f172025d78867
> Author: Gregory CLEMENT 
> Date:   Wed Feb 28 15:27:23 2018 +0100
>
> hwrng: omap - Fix clock resource by adding a register clock
>
> Ben.

I think the problem was rather in the tianocore firmware than device
tree - but it might be the more accurate device tree fixes it. We can
enable it again, and then re-open the bug dialog with upstream if the
bug is still there.

Riku

> --
> Ben Hutchings
> Beware of programmers who carry screwdrivers. - Leonard Brandwein
>
>

Bug#930348: chromium: missing intrinsics on armhf

[Riku Voipio]

The build is fixed in:

https://salsa.debian.org/chromium-team/chromium/commits/arm-fixes/debian

I can make an upload if you prefer, or I can wait for you.

Cheers,
Riku

Bug#928097: chromium: crc32 build errors on arm64

[Riku Voipio]

On Thu, Jun 06, 2019 at 11:07:31AM +, Riku Voipio wrote:
> Sorry for missign this bug completly. I'll get into fixing at.

I pushed a fix to the arm64 branch:

https://salsa.debian.org/chromium-team/chromium/commit/945283642d205c7b5a5129030f525109ee7b22c1

Riku

Bug#928097: chromium: crc32 build errors on arm64

[Riku Voipio]

Hi,

Sorry for missign this bug completly. I'll get into fixing at.

Riku

Bug#868454: Bug#908593: u-boot-menu: U_BOOT_PARAMETERS should be "ro quiet" (not empty) by default

[Riku Voipio]

Hi Jonas,

Please go for it! I'm never offended if people fix bugs in my packages :)

Riku

On Sun, 31 Mar 2019 at 13:51, Jonas Smedegaard  wrote:

> Dear Riku,
>
> Are you still interested in maintaining the package u-boot-menu?
>
> I notice that your last upload was 1.5 years ago, and you have not
> addressed nor commented on any of the 3 bugs filed since then (where one
> of them - 908593 - arguably addresses also the last bug - 868454 - which
> you did comment on).
>
> If interested but need a little help, then you might find useful my
> slight fork of the package, addressing those 3 (or 4) bugs, at
> https://salsa.debian.org/js/u-boot-menu
>
> I can offer to co-maintain or take over maintenance, if you like.
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Riku Voipio]

On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote:
> were in the week-end). I was aware of the discussion but did not
> had the time to chime in, yet I was the person who re-opened the bug
> #881333 in the first place.
 
> I also invited someone else who is working on a concrete project involving
> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
> now but he also did not have the time to contribute to the discussion.

> Software can be fixed/improved to also work with OpenGL ES. However
> hardware, once bought, cannot be fixed to support Desktop OpenGL
> when it has been designed for OpenGL ES only.

Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27,
featuring Mali-T880. The hardware is not OpenGL ES only .. the
propiertary driver is. Mesa-based panfrost driver should support both
OpenGL and OpenGL ES:

https://gitlab.freedesktop.org/panfrost

The open source driver is of course not ready... ...but neither is
Debian ES 2.0. In the long run, making the driver ready is time better
spent than time spent trying to make Debian more friendly to a class
of propiertary drivers.

Riku

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Riku Voipio]

On Tue, Sep 04, 2018 at 11:43:07AM -0700, Geoff Levand wrote:
> > Is it resolved? Graeme Gregory claimed
> > (https://www.spinics.net/lists/arm-kernel/msg669946.html) that "most
> > people are running the firmware provided from HPe support but was never
> > put on release site".
> 
> I took that as just a comment on the discussion which it follows, which
> seemed to end with 'distro maintainers deciding how to handle the problem'
> and then Riku recommending to document the need in Debian for a m400
> specific command line option.

Generally I'm just dissapointed the way upstream discussion turned out,
and willing to throw hands in the air.

Given it seems ACPI only really worked on moonshot with an unofficial
firmware, out-of-box working isn't that meaningful anyways.

> At this point I feel our choices are:
> 
> 1) Merge the kernel config patch I proposed and add a comment to
> the arm64 Installation Guide about the need to add 'hest_disable=1'
> to the kernel command line for the m400.

I think that people capable of running an unnofficial firmware are also
capable of setting and kernel command line option.

> 2) Merge the kernel config patch and the
> 'Add fix for broken HPE moonshot ACPI-APEI support' patch I proposed.

Personally I'd prefer to avoid accumating delta against upstream, but
Geoff's patch is quite low-impact.

> 3) Remove the CONFIG_ACPI_APEI options from the the kernel config patch
> I proposed and merge that.

We should really enable APEI support for the benefit of platforms that
do support it.

Riku

Bug#904796: chromium for arm64 lacks security updates

[Riku Voipio]

On Thu, Aug 02, 2018 at 11:53:04PM +, Riku Voipio wrote:
> The issue seems to be binutils in stable not supporting LR = x30 alias. I've
> built a fixed version. I'm travelling now, but once I get back, I'll test the
> fix and submit patch upstream. Similar issue for armhf, but we don't have
> chromium/armhf on stable, so it's not as important.

Fixed branch at:

https://salsa.debian.org/chromium-team/chromium/tree/stretch-arm64

I didn't push this to main stretch branch, as the security upload commit
is reconstructed rather the original from Michael. Changelog hasn't been
updated either.

Test binaries at

https://people.debian.org/~riku/chromium/

Riku

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Riku Voipio]

On Thu, Jun 14, 2018 at 09:58:56AM +0100, Ian Campbell wrote:
> On Wed, 2018-06-13 at 12:25 -0700, Geoff Levand wrote:
> > On 06/09/2018 05:15 AM, Ian Campbell wrote:
> > 
> > > I think this is probably something for the arch (or perhaps
> > > platform)
> > > code to deal with. See for example all the various platform quirks
> > > in
> > > arch/x86/kernel/acpi/boot.c, which fixup various wrongness and/or
> > > disable features.
> > 
> > I followed your advice and created a fix in the arm64 acpi init
> > code of arch/arm64/kernel/acpi.c.  Here's the submission:
> > 
> >   https://marc.info/?l=linux-acpi=152891415600796=2
> >   https://www.spinics.net/lists/linux-acpi/msg82887.html
> 
> Thanks!

Thanks indeed - unfortunately we seem to be endind up in 
a dead end with the upstream developers:

https://www.spinics.net/lists/arm-kernel/msg669674.html

Considering HPE didn't actually release the firmware, I think we
can go with just enabling the options and documenting the command line
option.

Riku

Bug#904796: chromium for arm64 lacks security updates

[Riku Voipio]

tags 904796 + patch upstream
thanks

On Mon, Jul 30, 2018 at 01:37:57AM +, Riku Voipio wrote:
> On Sat, Jul 28, 2018 at 05:23:14PM -0400, Michael Gilbert wrote:
> > > Chromium on arm64 in Debian Stretch stopped receiving security updates.
> > > Chromium for i386, amd64 and armhf received updates for versions 67 and
> > > 68, however chromium for arm64 is stuck on version 66.
>  
> > There was a build error in crashpad on arm64 introduced by upstream
> > chromium 67.  A patch fixing that has been included with the last two
> > security uploads, so I'm not sure why those builds would have failed.
> 
> Security build logs are not available, so I missed that. I'll try to 
> reproduce.

The issue seems to be binutils in stable not supporting LR = x30 alias. I've
built a fixed version. I'm travelling now, but once I get back, I'll test the
fix and submit patch upstream. Similar issue for armhf, but we don't have
chromium/armhf on stable, so it's not as important.

Riku
description: Stretch binutils doesn't recognize LR on arm64
author: Riku Voipio

Index: chromium-browser-68.0.3440.75/third_party/crashpad/crashpad/util/misc/capture_context_linux.S
===
--- chromium-browser-68.0.3440.75.orig/third_party/crashpad/crashpad/util/misc/capture_context_linux.S
+++ chromium-browser-68.0.3440.75/third_party/crashpad/crashpad/util/misc/capture_context_linux.S
@@ -312,14 +312,14 @@ CAPTURECONTEXT_SYMBOL2:
   stp x28, x29, [x0, #0x198]
 
   // The original LR can't be recovered.
-  str LR, [x0, #0x1a8]
+  str x30, [x0, #0x1a8]
 
   // Use x1 as a scratch register.
   mov x1, SP
   str x1, [x0, #0x1b0] // context->uc_mcontext.sp
 
   // The link register holds the return address for this function.
-  str LR, [x0, #0x1b8]  // context->uc_mcontext.pc
+  str x30, [x0, #0x1b8]  // context->uc_mcontext.pc
 
   // NZCV, pstate, and CPSR are synonyms.
   mrs x1, NZCV

Bug#904796: chromium for arm64 lacks security updates

[Riku Voipio]

On Sat, Jul 28, 2018 at 05:23:14PM -0400, Michael Gilbert wrote:
> > Chromium on arm64 in Debian Stretch stopped receiving security updates.
> > Chromium for i386, amd64 and armhf received updates for versions 67 and
> > 68, however chromium for arm64 is stuck on version 66.
 
> There was a build error in crashpad on arm64 introduced by upstream
> chromium 67.  A patch fixing that has been included with the last two
> security uploads, so I'm not sure why those builds would have failed.

Security build logs are not available, so I missed that. I'll try to reproduce.

Riku

Bug#901290: Gcc ICE on compiling chromium 68 [arm64 armhf]

[Riku Voipio]

reassign 901290 gcc-6
notfound 901290 68.0.3440.7-1
found 6.4.0-17
thanks

Compiling chrome 68 with results an gcc ICE. This affects both arm64[1] and
armhf[2]. Filing against gcc-6 as this what buildd used, but this affects 
other versions too:

+---+---+---+---+
|   | gcc-6 | gcc-7 | gcc-8 |
+---+---+---+---+
| armhf | ICE   | ICE   | ICE   |
| arm64 | ICE   | works | works |
+---+---+---+---+

gcc-6 -MMD -MF obj/skia/skcms/Transform.o.d -DV8_DEPRECATION_WARNINGS 
-DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 
-DNO_TCMALLOC -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL 
-DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 
-I../.. -Igen -I../../third_party/skia/third_party/skcms -w -std=c11 
-fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector 
-Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= 
-funwind-tables -fPIC -pipe -pthread -march=armv7-a -mfloat-abi=hard 
-mtune=generic-armv7-a -mfpu=vfpv3-d16 -mthumb -Wall -Wno-psabi 
-Wno-unused-local-typedefs -Wno-maybe-uninitialized 
-Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments 
-Wno-missing-field-initializers -Wno-unused-parameter -Os -fno-ident 
-fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 
-fvisibility=hidden -std=gnu11 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c 
../../third_party/skia/third_party/skcms/src/Transform.c -o 
obj/skia/skcms/Transform.o
In file included from 
../../third_party/skia/third_party/skcms/src/Transform.c:176:0:
../../third_party/skia/third_party/skcms/src/Transform_inl.h: In function 
'exec_ops':
../../third_party/skia/third_party/skcms/src/Transform_inl.h:159:20: internal 
compiler error: in store_constructor, at expr.c:6565
 *rgba = (*rgba & 0x00ff00ff00ff00ff) << 8
 ~~~^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccLLjPon.out file, please attach this to 
your bugreport.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=chromium-browser=arm64=68.0.3440.7-1=1528688783=1
[2] 
https://buildd.debian.org/status/fetch.php?pkg=chromium-browser=armhf=68.0.3440.7-1=1528694705=1
// === BEGIN GCC DUMP ===
// Target: arm-linux-gnueabihf
// Configured with: ../src/configure -v --with-pkgversion='Debian 6.4.0-17' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr 
--with-as=/usr/bin/arm-linux-gnueabihf-as 
--with-ld=/usr/bin/arm-linux-gnueabihf-ld --program-suffix=-6 
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm 
--disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch 
--disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 
--with-float=hard --with-mode=thumb --enable-checking=release 
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf 
--target=arm-linux-gnueabihf
// Thread model: posix
// gcc version 6.4.0 20180424 (Debian 6.4.0-17) 
// 
// In file included from 
../../third_party/skia/third_party/skcms/src/Transform.c:176:0:
// ../../third_party/skia/third_party/skcms/src/Transform_inl.h: In function 
'exec_ops':
// ../../third_party/skia/third_party/skcms/src/Transform_inl.h:159:20: 
internal compiler error: in store_constructor, at expr.c:6565
//  *rgba = (*rgba & 0x00ff00ff00ff00ff) << 8
//  ~~~^
// Please submit a full bug report,
// with preprocessed source if appropriate.
// See  for instructions.

// /usr/lib/gcc/arm-linux-gnueabihf/6/cc1 -quiet -I ../.. -I gen -I 
../../third_party/skia/third_party/skcms -imultilib . -imultiarch 
arm-linux-gnueabihf -MMD obj/skia/skcms/Transform.d -MF 
obj/skia/skcms/Transform.o.d -MQ obj/skia/skcms/Transform.o -D_REENTRANT -D 
V8_DEPRECATION_WARNINGS -D USE_UDEV -D USE_AURA=1 -D USE_GLIB=1 -D 
USE_NSS_CERTS=1 -D USE_X11=1 -D NO_TCMALLOC -D FULL_SAFE_BROWSING -D 
SAFE_BROWSING_CSD -D SAFE_BROWSING_DB_LOCAL -D CHROMIUM_BUILD -D 
_FILE_OFFSET_BITS=64 -D _LARGEFILE_SOURCE -D _LARGEFILE64_SOURCE -D 
__STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D _FORTIFY_SOURCE=2 -D NDEBUG 
-D NVALGRIND -D DYNAMIC_ANNOTATIONS_ENABLED=0 -D __DATE__= -D __TIME__= -D 
__TIMESTAMP__= -D _FORTIFY_SOURCE=2 
../../third_party/skia/third_party/skcms/src/Transform.c -quiet 

Bug#901290: version 68 arm build causes internal compiler error

[Riku Voipio]

Verified this affects gcc6, gcc7 and gcc8. I'll file a bug against GCC once I 
get a reduced testcase.

Compile with clang6 works.

Riku

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Riku Voipio]

On Fri, Jun 01, 2018 at 10:07:57AM -0700, Geoff Levand wrote:
> Source: linux
> Severity: normal
> Tags: patch buster
> 
> Attached patches enable kernel features for newer ARM64 servers.

Thanks, I've been looking into updating these.
 
> o Change CONFIG_ACPI_NFIT=y to CONFIG_ACPI_NFIT=m.
> o Enable CONFIG_SCHED_SMT for hyperthreading processors.
> o Enable CONFIG_ARM64_LSE_ATOMICS for v8.1 processors.
> o Enable a number of ACPI options likely to be available on servers.
> o CONFIG_ACPI_APEI selects PSTORE, so remove the arm64 specific setting.

ACPI_APEI breaks HP m400, the xgene moonshot:

https://bugzilla.redhat.com/show_bug.cgi?id=1574718
 
The rest of options are generally fine. Wish more of these were modules tho.
If we ok with telling M400 users to setting kernel command line of 
ghes.disable=1,
we can enable APEI as well.

>   0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
>   0002-arm64-Updates-for-ACPI-servers.patch
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 4.16.12 (SMP w/224 CPU cores)

Cheeky. I take that means Debian kernel works well on you plaform.

> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

> >From 45de8904c961d98f48f61a87198579a90daa61f9 Mon Sep 17 00:00:00 2001
> From: Geoff Levand 
> Date: Thu, 31 May 2018 17:38:38 -0700
> Subject: [PATCH 1/4] [arm64] Use default of CONFIG_ACPI_NFIT=m
> 
> Commit ed497f3cb706d0e0f63844b064d9ebbf6f33b052 (Add server and 96boards 
> options)
> added an arm64 specific CONFIG_ACPI_NFIT=y, overriding the default of =m, but 
> the
> commit message mentions nothing about why this was done.
> 
> Remove the arm64 specific setting and use the default of module build.
> 
> Cc: Riku Voipio 
> Signed-off-by: Geoff Levand 
> ---
>  debian/config/arm64/config | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/debian/config/arm64/config b/debian/config/arm64/config
> index 4d862989014c..2cbdc9092de1 100644
> --- a/debian/config/arm64/config
> +++ b/debian/config/arm64/config
> @@ -68,11 +68,6 @@ CONFIG_ARCH_XGENE=y
>  CONFIG_ACPI=y
>  CONFIG_ACPI_NUMA=y
>  
> -##
> -## file: drivers/acpi/nfit/Kconfig
> -##
> -CONFIG_ACPI_NFIT=y
> -
>  ##
>  ## file: drivers/ata/Kconfig
>  ##
> -- 
> 2.14.1
> 

> >From 60439ed76d7c9660285d8805d40d35a84de218d3 Mon Sep 17 00:00:00 2001
> From: Geoff Levand 
> Date: Thu, 31 May 2018 17:38:38 -0700
> Subject: [PATCH 2/4] [arm64] Updates for ACPI servers
> 
> o Enable CONFIG_SCHED_SMT for hyperthreading processors.
> o Enable CONFIG_ARM64_LSE_ATOMICS for v8.1 processors.
> o Enable a number of ACPI options likely to be available on servers.
> o CONFIG_ACPI_APEI selects PSTORE, so remove the arm64 specific setting.
> 
> Signed-off-by: Geoff Levand 
> ---
>  debian/config/arm64/config | 29 -
>  1 file changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/debian/config/arm64/config b/debian/config/arm64/config
> index 2cbdc9092de1..ed40c33ce47d 100644
> --- a/debian/config/arm64/config
> +++ b/debian/config/arm64/config
> @@ -9,6 +9,7 @@ CONFIG_ARM64_ERRATUM_834220=y
>  CONFIG_ARM64_VA_BITS_48=y
>  ## end choice
>  CONFIG_SCHED_MC=y
> +CONFIG_SCHED_SMT=y
>  CONFIG_NR_CPUS=256
>  CONFIG_NUMA=y
>  CONFIG_SECCOMP=y
> @@ -24,6 +25,7 @@ CONFIG_RANDOMIZE_BASE=y
>  CONFIG_RANDOMIZE_MODULE_REGION_FULL=y
>  CONFIG_ARM64_ACPI_PARKING_PROTOCOL=y
>  CONFIG_COMPAT=y
> +CONFIG_ARM64_LSE_ATOMICS=y
>  
>  ##
>  ## file: arch/arm64/crypto/Kconfig
> @@ -67,6 +69,21 @@ CONFIG_ARCH_XGENE=y
>  ##
>  CONFIG_ACPI=y
>  CONFIG_ACPI_NUMA=y
> +CONFIG_ACPI_PCI_SLOT=y
> +CONFIG_ACPI_HED=y
> +CONFIG_ACPI_BGRT=y
> +CONFIG_ACPI_WATCHDOG=y
> +CONFIG_ACPI_CONFIGFS=m
> +
> +##
> +## file: drivers/acpi/apei/Kconfig
> +##
> +CONFIG_ACPI_APEI=y
> +CONFIG_ACPI_APEI_GHES=y
> +CONFIG_ACPI_APEI_PCIEAER=y
> +CONFIG_ACPI_APEI_SEA=y
> +CONFIG_ACPI_APEI_MEMORY_FAILURE=y
> +CONFIG_ACPI_APEI_EINJ=m
>  
>  ##
>  ## file: drivers/ata/Kconfig
> @@ -212,6 +229,12 @@ CONFIG_EXTCON_USB_GPIO=m
>  ##
>  CONFIG_RASPBERRYPI_FIRMWARE=y
>  
> +##
> +## file: drivers/firmware/efi/Kconfig
> +##
> +CONFIG_UEFI_CPER=y
> +CONFIG_UEFI_CPER_ARM=y
> +
>  ##
>  ## file: drivers/gpio/Kconfig
>  ##
> @@ -1074,6 +1097,7 @@ CONFIG_VIRTIO_MMIO=m
>  ## file: drivers/watchdog/Kconfig
>  ##
>  CONFIG_GPIO_WATCHDOG=m
> +CONFIG_WDAT_WDT=m
>  CONFIG_ARM_SP805_WATCHDOG=m
>  CONFIG_ARM_SBSA_WATCHDOG=m
>  CONFIG_DW_WATCHDOG=m
> @@ -1084,11 +1108,6 @@ CONFIG_MESON_GXBB_WATCHDOG=m
>  CONFIG_MESON_WATCHDOG=m
>  CONFIG_BCM2835_WDT=m
>  
> -##
> -## file: fs/pstore/Kconfig
> -##
> -CONFIG_PSTORE=y
> -
>  ##
>  ## file: mm/Kconfig
>  ##
> -- 
> 2.14.1
> 

Bug#564935: gmod: should this package be removed?

[Riku Voipio]

reassign 564935 ftp.debian.org
retitle 564935 gmod -- RoM; ancient; abandoned upstream;
thanks

On Mon, Apr 16, 2018 at 07:19:36PM +0200, Moritz Muehlenhoff wrote:
> On Tue, Jan 12, 2010 at 09:08:39PM +, Simon McVittie wrote:
> > Source: gmod
> > Severity: wishlist
> > User: debian...@lists.debian.org
> > Usertags: proposed-removal
> > 
> > gmod seems like a candidate for removal from Debian:
> > 
> > * RFA for a long time
> > * very low popcon (2 votes)
> > * alternatives that don't require specialized hardware exist (mikmod)
> > * nothing in Debian depends on it
> > 
> > If you want to keep this package around in Debian, please just close this 
> > bug.
> 
> Eight years without anyone voicing a concern seems like an acceptable grace 
> period
> to finally remove this? :-)

At this point the package is just dead weight. Please remove from Debian!

Riku

Bug#876774: tested with 4.16-rc6, patch

[Riku Voipio]

tags +876774 pending
thanks

On Wed, Apr 04, 2018 at 07:08:01PM +0200, Josua Mayer wrote:
> Greetings once again,
> 
> I have now rebuilt the current kernel package from sid, with the
> necessary config changes.
> So far it boots, and network works. I haven't tested anything else yet.
> 
> Please find attached the patch for enabling the missing options.

Applied as:

https://salsa.debian.org/kernel-team/linux/commit/652951710c6cd09423496dfa5175219eed45323b

Thanks,
Riku

Bug#894212: please add dragonboard 820c support

[Riku Voipio]

On Tue, Mar 27, 2018 at 01:52:46PM -0700, Vagrant Cascadian wrote:
> On 2018-03-27, Riku Voipio wrote:
> > I've created a merge request to add Dragonboard 820c support
> > in debian u-boot build:
> >
> > https://salsa.debian.org/debian/u-boot/merge_requests/1
> 
> Thanks!
> 
> Have you read up on the rests for testers:
> 
>   https://wiki.debian.org/U-boot
  
> The only thing I'm unsure of about the pull request is why you removed
> Ricardo Salveti as a tester for dragonboard410c?

Ricardo, do you want to keep testing DB410c? I notice from IRC you are testing
u-boot on DB820c as well ;)
 
> Not that I've received a lot of feedback about tested versions from many
> people:
> 
>   https://wiki.debian.org/U-boot/Status

Cool, I'll update it with DB410c at least

Riku

Bug#894212: please add dragonboard 820c support

[Riku Voipio]

Package: u-boot-qcom
Version: 2018.03+dfsg1-1
Severity: wishlist
Tags: patch

Hi,

I've created a merge request to add Dragonboard 820c support
in debian u-boot build:

https://salsa.debian.org/debian/u-boot/merge_requests/1

Riku

Bug#891062: [Pkg-chromium-maint] Bug#891062: Bug#891062: chromium: skia fails to build on arm64

[Riku Voipio]

tags 891062 +pending
thanks

On Thu, Feb 22, 2018 at 11:48:10AM +, Riku Voipio wrote:
> +// On ARM we expect that you're using Clang if you want SkJumper to be fast.
> +// If you are, the baseline float stages will use NEON, and lowp stages will
> +// also be available. (If somehow you're building for ARM not using Clang,
> +// you'll get scalar baseline stages and no lowp support.)
> 
> Well clearly the fallback was not tested.

I've pushed a workaround to the experimental branch. 

Bug#891062: [Pkg-chromium-maint] Bug#891062: chromium: skia fails to build on arm64

[Riku Voipio]

On Wed, Feb 21, 2018 at 09:59:18PM -0500, Michael Gilbert wrote:
> Starting with chromium 65, arm64 fails while building skia.
> 
> ../../third_party/skia/src/jumper/SkJumper_stages.cpp: In function 'F
> from_half(U16)':
> ../../third_party/skia/src/jumper/SkJumper_stages.cpp:670:12: error:
> 'vcvt_f32_f16' was not declared in this scope
>  return vcvt_f32_f16(h);

Looking at the breaking change:

+// On ARM we expect that you're using Clang if you want SkJumper to be fast.
+// If you are, the baseline float stages will use NEON, and lowp stages will
+// also be available. (If somehow you're building for ARM not using Clang,
+// you'll get scalar baseline stages and no lowp support.)

Well clearly the fallback was not tested.

Bug#887110: #887110: Debian Testing Cannot be installed on Macchiatobin

[Riku Voipio]

Hi,

The first hang is because your firmware doesn't provide everything in DTB:

https://patchwork.kernel.org/patch/10146687/

You need to updateyour EFI.

The later hang is caused by omap_rng driver - so I've disabled in the Debian
kernel as of 4.14.13-1

Riku

Bug#886122: android-platform-system-core: ftbfs with GCC-7

[Riku Voipio]

The attached paches fixes the build by 

- use system definition for ucontext_t
- compile the affected file with clang++

The latter is not the correct fix, but an upstream commit[1]
suggests these types are deprecated. The correct fix is then
to replace the usage with std::vector etc.

https://android.googlesource.com/platform/system/core/+/b8f152d3e2b9368717743ebcb1277239a6c00659%5E%21/
diff -Nru android-platform-system-core-7.0.0+r33/debian/changelog android-platform-system-core-7.0.0+r33/debian/changelog
--- android-platform-system-core-7.0.0+r33/debian/changelog	2017-07-05 16:55:06.0 +0300
+++ android-platform-system-core-7.0.0+r33/debian/changelog	2018-01-12 10:41:37.0 +0200
@@ -1,3 +1,10 @@
+android-platform-system-core (1:7.0.0+r33-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build
+
+ -- Riku Voipio <riku.voi...@linaro.org>  Fri, 12 Jan 2018 10:41:37 +0200
+
 android-platform-system-core (1:7.0.0+r33-2) unstable; urgency=medium
 
   * fix CVE-2017-0647 (Closes: #867229)
diff -Nru android-platform-system-core-7.0.0+r33/debian/control android-platform-system-core-7.0.0+r33/debian/control
--- android-platform-system-core-7.0.0+r33/debian/control	2017-04-25 22:46:58.0 +0300
+++ android-platform-system-core-7.0.0+r33/debian/control	2018-01-12 10:33:04.0 +0200
@@ -7,6 +7,7 @@
Chirayu Desai <chirayudes...@gmail.com>
 Build-Depends: android-libunwind-dev (>= 7.0.0+r1~) [amd64 i386 armel armhf arm64 mips mipsel mips64el],
bash-completion,
+   clang,
debhelper (>= 10),
dh-exec,
dpkg-dev (>= 1.17.14),
@@ -251,7 +252,7 @@
  fastboot mode, etc..
 
 Package: simg2img
-Architecture: amd64 i386
+Architecture: amd64 i386 armel armhf arm64 mips mipsel mips64el
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Breaks: android-tools-fsutils (<< 6.0~)
 Replaces: android-tools-fsutils (<< 6.0~)
@@ -260,7 +261,7 @@
  be manipulated with the standard tools.
 
 Package: img2simg
-Architecture: amd64 i386
+Architecture: amd64 i386 armel armhf arm64 mips mipsel mips64el
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Breaks: android-tools-fsutils (<< 6.0~)
 Replaces: android-tools-fsutils (<< 6.0~)
@@ -268,7 +269,7 @@
  A command line tool to create sparse images for usage with Android devices.
 
 Package: append2simg
-Architecture: amd64 i386
+Architecture: amd64 i386 armel armhf arm64 mips mipsel mips64el
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Android sparse image tool
  A command line tool to append data to the end of a sparse image.
diff -Nru android-platform-system-core-7.0.0+r33/debian/libutils.mk android-platform-system-core-7.0.0+r33/debian/libutils.mk
--- android-platform-system-core-7.0.0+r33/debian/libutils.mk	2016-12-06 15:08:28.0 +0200
+++ android-platform-system-core-7.0.0+r33/debian/libutils.mk	2018-01-12 10:33:45.0 +0200
@@ -31,8 +31,8 @@
-lpthread -L. -llog -lcutils -lbacktrace
 
 build: $(SOURCES)
-	$(CXX) $^ -o $(NAME).so.0 $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS)
+	clang++ $^ -o $(NAME).so.0 $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS)
 	ln -s $(NAME).so.0 $(NAME).so
 
 clean:
-	$(RM) $(NAME).so*
\ No newline at end of file
+	$(RM) $(NAME).so*
diff -Nru android-platform-system-core-7.0.0+r33/debian/patches/fix-backtrace.patch android-platform-system-core-7.0.0+r33/debian/patches/fix-backtrace.patch
--- android-platform-system-core-7.0.0+r33/debian/patches/fix-backtrace.patch	1970-01-01 02:00:00.0 +0200
+++ android-platform-system-core-7.0.0+r33/debian/patches/fix-backtrace.patch	2018-01-12 10:41:37.0 +0200
@@ -0,0 +1,22 @@
+Index: android-platform-system-core-7.0.0+r33/include/backtrace/Backtrace.h
+===
+--- android-platform-system-core-7.0.0+r33.orig/include/backtrace/Backtrace.h
 android-platform-system-core-7.0.0+r33/include/backtrace/Backtrace.h
+@@ -23,6 +23,7 @@
+ #include 
+ #include 
+ 
++#include 
+ #include 
+ #include 
+ 
+@@ -65,9 +66,6 @@ struct backtrace_frame_data_t {
+ #if defined(__APPLE__)
+ struct __darwin_ucontext;
+ typedef __darwin_ucontext ucontext_t;
+-#else
+-struct ucontext;
+-typedef ucontext ucontext_t;
+ #endif
+ 
+ struct backtrace_stackinfo_t {
diff -Nru android-platform-system-core-7.0.0+r33/debian/patches/series android-platform-system-core-7.0.0+r33/debian/patches/series
--- android-platform-system-core-7.0.0+r33/debian/patches/series	2017-07-05 16:53:22.0 +0300
+++ android-platform-system-core-7.0.0+r33/debian/patches/series	2018-01-12 10:36:45.0 +0200
@@ -7,3 +7,4 @@
 adb_libssl_bc.diff
 move-log-file-to-proper-dir.patch
 fix-CVE-2017-0647.patch
+fix-backtrace.patch

Bug#880584: [PATCH] auto_add_modules: add mfd in MODULES==most

[Riku Voipio]

Hi Ben,

On Thu, Nov 02, 2017 at 02:46:47PM +, Riku Voipio wrote:
> Package: initramfs-tools
> Version: 0.130
> Severity: normal
> Tags: patch
> 
> Multi Function Devices may carry essential functions on arm/arm64
> platforms. For example in 96boards HiKey mfd/hi655x-pmic has regulators,
> causing MMC driver init fail.  when generating generic initrd on offline
> with MODULES=most, update-initramfs doesn't pick mfd modules.
> 
> Since mfd is quite small (284K on arm64), just add them all to most. This
> may also open the road to make some currently built-in CONFIG_MFD
> drivers modules.


Is this patch ok to commit?
 
> Signed-off-by: Riku Voipio <riku.voi...@linaro.org>
> ---
>  hook-functions | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hook-functions b/hook-functions
> index 679e11d..4b49391 100644
> --- a/hook-functions
> +++ b/hook-functions
> @@ -537,6 +537,7 @@ auto_add_modules()
>   copy_modules_dir kernel/drivers/gpio
>   copy_modules_dir kernel/drivers/i2c/busses
>   copy_modules_dir kernel/drivers/i2c/muxes
> + copy_modules_dir kernel/drivers/mfd
>   copy_modules_dir kernel/drivers/phy
>   copy_modules_dir kernel/drivers/pinctrl
>   copy_modules_dir kernel/drivers/regulator
> -- 
> 2.14.2
> 

Bug#880584: [PATCH] auto_add_modules: add mfd in MODULES==most

[Riku Voipio]

Package: initramfs-tools
Version: 0.130
Severity: normal
Tags: patch

Multi Function Devices may carry essential functions on arm/arm64
platforms. For example in 96boards HiKey mfd/hi655x-pmic has regulators,
causing MMC driver init fail.  when generating generic initrd on offline
with MODULES=most, update-initramfs doesn't pick mfd modules.

Since mfd is quite small (284K on arm64), just add them all to most. This
may also open the road to make some currently built-in CONFIG_MFD
drivers modules.

Signed-off-by: Riku Voipio <riku.voi...@linaro.org>
---
 hook-functions | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hook-functions b/hook-functions
index 679e11d..4b49391 100644
--- a/hook-functions
+++ b/hook-functions
@@ -537,6 +537,7 @@ auto_add_modules()
copy_modules_dir kernel/drivers/gpio
copy_modules_dir kernel/drivers/i2c/busses
copy_modules_dir kernel/drivers/i2c/muxes
+   copy_modules_dir kernel/drivers/mfd
copy_modules_dir kernel/drivers/phy
copy_modules_dir kernel/drivers/pinctrl
copy_modules_dir kernel/drivers/regulator
-- 
2.14.2

Bug#874188: fai-client: Integrate some form of file templating system

[Riku Voipio]

Hi,

I've used envsubst[1] in my fai setup. envsubst comes from gettext-base
so most people have installed and it's very easy to use. jinja2 is more 
powerful (can do loops etc), so there are some cases where it is more
useful. 

Riku

[1] http://manpages.debian.net/envsubst

Bug#872782: lava-tool: missing debpendency: python-simplejson

[Riku Voipio]

Package: lava-tool
Version: 0.21-1
Severity: important

Dear Maintainer,

Looks like a dependency on python-simplejson is needed:

$ sudo apt install lava-tool
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  python-gpg
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  python-jinja2 python-markupsafe python-xdg python-zmq
Suggested packages:
  python-jinja2-doc
The following NEW packages will be installed:
  lava-tool python-jinja2 python-markupsafe python-xdg python-zmq
...
lava-tool auth-add https://m...@youknowwhere.org/RPC2/
ERROR:root:Unable to load command: job-output
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 74, in 
import_commands
command_cls = entrypoint.load()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2291, 
in load
return self.resolve()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2297, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python2.7/dist-packages/lava_scheduler_tool/commands.py", line 
42, in 
from lava_dashboard_tool.commands import DataSetRenderer, 
_get_pretty_renderer
  File "/usr/lib/python2.7/dist-packages/lava_dashboard_tool/commands.py", line 
36, in 
import simplejson
ImportError: No module named simplejson

After installing python-simplejson no errors are thrown.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 4.12.0-trunk-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lava-tool depends on:
ii  python 2.7.13-2
ii  python-jinja2  2.8-1
ii  python-requests2.12.4-1
ii  python-setuptools  33.1.1-1
ii  python-xdg 0.25-4
ii  python-yaml3.12-1
ii  python-zmq 16.0.2-2
ii  python2.7  2.7.13-2

Versions of packages lava-tool recommends:
ii  ca-certificates  20161130+nmu1

lava-tool suggests no packages.

-- no debconf information

Bug#864847: CP15 Barrier emulation performance?

[Riku Voipio]

On Tue, Jul 11, 2017 at 09:45:49AM +0100, Ian Campbell wrote:
> On Tue, 2017-07-11 at 08:56 +0100, Edmund Grimley Evans wrote:
> > > Does this emulation take a considerable performance hit, as opposed
> > > to
> > > running on armhf hardware/kernel, where the instruction doesn't
> > > appear
> > > to be listed as deprecated?
> > 
> > I'd expect the kernel-emulated instruction to be much slower than any
> > non-emulated instruction, but the overall effect on performance will,
> > of course, depend on how often the instruction is used.
> > 
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847 (where I
> > think I claimed that the instruction is deprecated on armhf hardware
> > but I could easily be wrong)

> Deprecated for both ARMv7 and ARMv8 according to the Kconfig help:
> config CP15_BARRIER_EMULATION
> bool "Emulate CP15 Barrier instructions"
> help
>   The CP15 barrier instructions - CP15ISB, CP15DSB, and
>   CP15DMB - are deprecated in ARMv8 (and ARMv7). It is
>   strongly recommended to use the ISB, DSB, and DMB
>   instructions instead.
> 
>   Say Y here to enable software emulation of these
>   instructions for AArch32 userspace code. When this option is
>   enabled, CP15 barrier usage is traced which can help
>   identify software that needs updating.
> 
>   If unsure, say Y
> 
> However I there is a sysctl which allows selecting between "undef",
> "emulated" and "hw" (where the latter is dependent on the hw actually
> supporting the instructions in question). See:
> http://elixir.free-electrons.com/linux/latest/source/Documentation/arm64/legacy_instructions.txt

The ghc sources don't appeart to have direct CP15 instructions, so I suspect
ghc might be calling llvm with options that make it emit CP15 barriers instead
of DMB. Anyways look like a configuration error rather than a coding error.

Riku

Bug#869808: kdump-tools builds incorrectly on some archs

[Riku Voipio]

Package: kdump-tools
Version: 1:1.6.1-1
Severity: important
Tags: patch

Dear Maintainer,

When building makedumpfile on arm64 host, kdump-tools becomes
uninstallable (etc/default/grub.d/ becomes missing). I recommend
dropping the arch-specific logic from debian/rules, since the
generated package is arch independent. The files are too small
to worry about anyways.

Riku

diff --git a/debian/rules b/debian/rules
index 903f416..c4acae5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,7 +20,5 @@ override_dh_install:
dh_install
install -D -m 755 debian/kernel-postinst-generate-initrd 
debian/kdump-tools/etc/kernel/postinst.d/kdump-tools
install -D -m 755 debian/kernel-postrm-delete-initrd 
debian/kdump-tools/etc/kernel/postrm.d/kdump-tools
-ifneq (,$(filter $(DEB_HOST_ARCH),i386 amd64 powerpc ppc64 ppc64el ia64))
install -D -m 644 debian/kdump-tools.grub.default 
debian/kdump-tools/etc/default/grub.d/kdump-tools.default
install -D -m 644 debian/kdump-tools.grub.ppc64el 
debian/kdump-tools/etc/default/grub.d/kdump-tools..ppc64el
-endif



-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kdump-tools depends on:
ii  bsdmainutils   9.0.12+nmu1
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  kexec-tools1:2.0.14-1
ii  lsb-base   9.20161125
ii  makedumpfile   1:1.6.1-1

kdump-tools recommends no packages.

kdump-tools suggests no packages.

-- debconf information excluded

Bug#868802: installation-reports: Successful install on X370-PRO on NVME storage

[Riku Voipio]

Package: installation-reports
Severity: wishlist

Dear Maintainer,


-- Package-specific info:

Boot method: usb
Image version: netinst
Date: July 5th 2017

Machine: X370-PRO
Partitions: 
Filesystem Type  1K-blocks   Used Available Use% Mounted on
udev   devtmpfs8171700  0   8171700   0% /dev
tmpfs  tmpfs   1643200   1572   1641628   1% /run
/dev/nvme0n1p2 ext4  4627075446525600 432607980   2% /
tmpfs  tmpfs   8215988  0   8215988   0% /dev/shm
tmpfs  tmpfs  5120  4  5116   1% /run/lock
tmpfs  tmpfs   8215988  0   8215988   0% /sys/fs/cgroup
/dev/nvme0n1p1 vfat 523248132523116   1% /boot/efi


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Happy to report that installation on new ryzen machine with nvme storage
went through without issues. Thanks for all your work :)

For post-stretch, a non-interrupted install would be great - answer all
debconf questions first, and then execute install in one go. Now it
takes a little bit too much attention having stay at machine in the 
answer questions - wait few minutes - answer some more questions - wait again
loop.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170615"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux berserk 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2 (2017-06-12) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1450]
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8747]
lspci -knn: 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Device 
[1022:1451]
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8747]
lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1453]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1453]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1453]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:07.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1454]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1454]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus 
Controller [1022:790b] (rev 59)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8747]
lspci -knn: 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH 
LPC Bridge [1022:790e] (rev 51)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8747]
lspci -knn: 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1460]
lspci -knn: 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1461]
lspci -knn: 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1462]
lspci -knn: 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1463]
lspci -knn: 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1464]
lspci -knn: 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1465]
lspci -knn: 00:18.6 Host bridge [0600]: Advanced Micro Devices, 

Bug#868454: u-boot-menu: wrong path for fdtdir in extlinux.conf

[Riku Voipio]

severity 868454 minor
thanks

Thanks for trying out u/boot menu.

On 15 July 2017 at 17:38, Diego Roversi  wrote:
> Package: u-boot-menu
> Version: 2
> Severity: important
>
> Entries in extlinux.conf contain this line:
>
> fdtdir /usr/lib/linux-image-4.9.0-3-armmp-lpae

This is correct path. That is where the kernel package installs dtbs to.

> But it should be /dtb-4.9.0-3-armmp-lpae

> This error make the menu unusable. No matter what entry you choose, file to 
> load
> dtb file and u-boot fallback to boot.scr for loading the images.

I think you have a partition setup where /boot is a separate
partition. This is unfortunately
not supported at the moment. You need to set up fdtdir setting in
/etc/default/u-boot file to fit
your setup.

Riku

> Thanks,
>   Diego Roversi
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable')
> Architecture: armhf (armv7l)
>
> Kernel: Linux 4.12.0-12921-g235b84fc86 (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
> (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages u-boot-menu depends on:
> ii  linux-base  4.5
>
> u-boot-menu recommends no packages.
>
> u-boot-menu suggests no packages.
>
> -- no debconf information

Bug#866580: obs-build: Please add depends to sudo, libarchive-tools

[Riku Voipio]

Package: obs-build
Version: 20170201-2
Severity: normal
Tags: patch

Dear Maintainer,

If sudo is not installed, osc build will fail with:

Running build
sudo: No such file or directory

If bsdtar is not installed, rpm based distro installs will fail:

[4s] [38/49] preinstalling sed...
[4s] cpio: Can't write over symlinks: ./bin/sed

see: https://github.com/openSUSE/open-build-service/issues/2195

bsddtar is in package libarchive-tools.

diff -Nru obs-build-20170201/debian/control obs-build-20170201/debian/control
--- obs-build-20170201/debian/control   2017-02-21 15:51:02.0 +0200
+++ obs-build-20170201/debian/control   2017-06-30 11:10:23.0 +0300
@@ -10,7 +10,7 @@
 
 Package: obs-build
 Architecture: all
-Depends: ${misc:Depends}, ${perl:Depends}, rpm, debootstrap
+Depends: ${misc:Depends}, ${perl:Depends}, rpm, debootstrap, sudo, 
libarchive-tools
 Recommends: rpm2cpio, osc, libcrypt-ssleay-perl
 Description: scripts for building RPM/debian packages for multiple 
distributions
  This package provides scripts for building RPM and debian packages in



-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armhf

Kernel: Linux 4.12.0-rc6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages obs-build depends on:
ii  debootstrap  1.0.89
ii  perl 5.24.1-3
ii  rpm  4.12.0.2+dfsg1-2

Versions of packages obs-build recommends:
pn  libcrypt-ssleay-perl  
ii  osc   0.156.0-1
ii  rpm2cpio  4.12.0.2+dfsg1-2

obs-build suggests no packages.

-- no debconf information

Bug#857986: npm: This pakcage is 3 years old? (consider removal)

[Riku Voipio]

On Fri, May 19, 2017 at 12:15:32PM +0200, Jérémy Lal wrote:
> 2017-05-19 12:07 GMT+02:00 Riku Voipio <riku.voi...@iki.fi>:
> 
> > Jérémy Lal:
> > > To others, preoccupied that npm won't be available in debian:
> > > - please help with npm maintenance
> > > - hopefully we'll make an updated version installable through debian
> > backports
> >
> > Are there any complications to building npm as part of nodejs package?
> >

> There are complications to distributing npm: it depends on a LOT of
> modules, which
> means it requires a lot of debian-maintainer time to package, and update.
> Using the upstream nodejs tarball as source for npm or the upstream npm
> tarball
> does not change anything about that.

Ok, thanks for clarifying.

Riku

Bug#857986: npm: This pakcage is 3 years old? (consider removal)

[Riku Voipio]

Jérémy Lal:
> To others, preoccupied that npm won't be available in debian:
> - please help with npm maintenance
> - hopefully we'll make an updated version installable through debian backports

Are there any complications to building npm as part of nodejs package?

Riku

Bug#861384: arm64: emulate deprecated instructions

[Riku Voipio]

Package: linux
Version: 4.10.7-1~exp1
Severity: wishlist
Tags: patch
User: debian-...@lists.debian.org
Usertag: arm64

After some consideration, I think indeed this kernel option needs to be
enabled.

 1) Rasperry pi binaries

While using rasperry-pi targetted Docker images is terrible for
performance, rebuilding the images for ARMv8 is often a messy process.
And then there is the valid usecase of developing images and apps for
rasperry pi users. Finally, there are some binary-only rasperry pi apps.

 2) Support for android apps

While anbox isn't around for armv8, it's probably just a matter of time.
Android ecosystem is binary-only and a non-trivial amount of binaries
have been built for pre-ARMv7 times.

 3) armel development

Most obsolete of all the options, but some people might want to use arm64
machines to build and test apps to be deployed on existing armel HW.
---
 debian/config/arm64/config | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/config/arm64/config b/debian/config/arm64/config
index 2be794a6c..a0432894d 100644
--- a/debian/config/arm64/config
+++ b/debian/config/arm64/config
@@ -12,6 +12,10 @@ CONFIG_SCHED_MC=y
 CONFIG_SECCOMP=y
 CONFIG_KEXEC=y
 CONFIG_XEN=y
+CONFIG_ARMV8_DEPRECATED=y
+CONFIG_SWP_EMULATION=y
+CONFIG_CP15_BARRIER_EMULATION=y
+CONFIG_SETEND_EMULATION=y
 CONFIG_RANDOMIZE_BASE=y
 CONFIG_RANDOMIZE_MODULE_REGION_FULL=y
 CONFIG_ARM64_ACPI_PARKING_PROTOCOL=y
-- 
2.11.0

Bug#853161: #853161: All workers run as one systemd unit

[Riku Voipio]

Hi,

> obs-worker is a, well, not very nice init script which runs all the
> worker instances (under screen of all things).

Digging under the hood, adapting this initscript to the brave new world
doesn't perhaps make much sense. The initscript downloads bs_worker from
obs server and starts it with a handful of parameters:

https://github.com/suihkulokki/obsworker/blob/master/start-obsworker

Similar approach would probably work on systemd service, although one
might need to provide upstream with a "quiet" mode so that bs_worker
doesn's spam the logs full of build lines...

The real complexities in the initscript come from the various VM support
options. Which is probably something that shouldnt really be done from
initscripts.

Riku

Bug#859711: bs_dodop needs gpg2

[Riku Voipio]

Package: obs-server
Version: 2.7.1-10
Severity: normal

bs_dodop calls gpg2, so a recommends: on gnupg2 would good.

Apr 06 09:12:13 obs bs_dodup[97]: 2017-04-06 09:12:13: checking 
CentOS:CentOS-7/standard/x86_64...
Apr 06 09:12:13 obs bs_dodup[97]: updating metadata for rpmmd repo at 
http://ftp.halifax.rwth-aachen.de/centos/7/os/x86_64/
Apr 06 09:12:14 obs bs_dodup[97]: Can't exec "gpg2": No such file or directory 
at /usr/lib/obs/server/bs_dodup line 88.

In longer term the upstream should change the exec call, but for now
most distros still have gpg to point to gnupg1.

Riku

Bug#856183: [Pkg-chromium-maint] Bug#856183: Acknowledgement (chromium: safe or unsafe defaults)

[Riku Voipio]

On Sun, Feb 26, 2017 at 02:49:25AM -0500, Michael Gilbert wrote:
> Let me clarify.  I am not going to make a decision about this, you are.
 
> Form a consensus (all involved must agree), and I will accept an
> implementation of what ever that turns out to be, but I reserve the
> right to exclude any negative participants.

This is a case where there will be unhappy users either way -

automated updates enabled by default:

- Users will complain when extensions lose features on updates or
  add privacy invading features. I remember this happening to me when
  "page monitor" updated silently to require using a 3rd party web service.

automated updates disabled

- As we have seen here in bug#, mailing list and planet debian.

I think that as packagers in Debian, we should try to ship software as
upstream provides. There are changes we need to do follow the Debian Policy,
but no other obligation to follow demands from users to diverge from what
the upstream is doing.

Every change we make is burden to maintain. Especially in the case of
chromium where stable security updates mean rebasing changes to new
upstream code. So I would vote for keeping automated updates enabled.

Users who want to disable extension autoupdates from chromium webstore
are free to persuade upstream to include a checkbox for that in
chrome://preferences

Riku

Bug#842140: ITP: obs-signd -- open build service signer client and daemon

[Riku Voipio]

Hi,

What's the status with this? Is there some preliminary packaging already?

Riku

Bug#855372: vagrant: please add recommends on vagrant-libvirt

[Riku Voipio]

Package: vagrant
Version: 1.9.1+dfsg-1
Severity: wishlist

Dear Maintainer,

Considering that virtualbox wont be part of stretch (#794466),
please add recommends for vagrant-libvirt - which appears to 
be the only vagrant provider available easily.

Riku

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armhf

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vagrant depends on:
ii  bsdtar 3.2.1-6
ii  curl   7.52.1-2
ii  openssh-client 1:7.4p1-6
ii  ruby   1:2.3.3
ii  ruby-bundler   1.13.6-2
ii  ruby-childprocess  0.5.9-1
ii  ruby-erubis2.7.0-3
ii  ruby-i18n  0.7.0-2
ii  ruby-listen3.0.3-3
ii  ruby-log4r 1.1.10-4
ii  ruby-net-scp   1.2.1-4
ii  ruby-net-sftp  1:2.1.2-3
ii  ruby-net-ssh   1:3.2.0-1
ii  ruby-nokogiri  1.6.8.1-1
ii  ruby-rb-inotify0.9.7-1
ii  ruby-rest-client   1.8.0-3

vagrant recommends no packages.

Versions of packages vagrant suggests:
pn  virtualbox  

-- no debconf information

Bug#854582: chromium extensions no longer enabled bu default

[Riku Voipio]

package: chromium
forcemerge 852398 854582
thanks

See the original issue at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909
https://news.ycombinator.com/item?id=9724409

to re-enable the setting use:

export CHROMIUM_FLAGS='--enable-remote-extensions'

See also /usr/share/doc/chromium/NEWS.Debian.gz

Riku

Bug#854079: firefox-esr: firefox dies immediately on arm64

[Riku Voipio]

On Tue, Feb 07, 2017 at 02:12:00PM +0900, Mike Hommey wrote:
> Okay, that one was fixed upstream in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1257055

> Can you try applying the patch there and see how things go from there?
> (I'd rather avoid doing multiple uploads if it turns out not to be
> sufficient, which I suspect might be the case).

The patch needed a bit of changing but after applying and compiling,
firefox now indeed works on arm64. Thanks.

Build package at: https://people.debian.org/~riku/firefox/ 

and debdiff attached.

diff -Nru firefox-esr-45.7.0esr/debian/patches/porting/Bug-1257055-use-aarch64-atomics.patch firefox-esr-45.7.0esr/debian/patches/porting/Bug-1257055-use-aarch64-atomics.patch
--- firefox-esr-45.7.0esr/debian/patches/porting/Bug-1257055-use-aarch64-atomics.patch	1970-01-01 00:00:00.0 +
+++ firefox-esr-45.7.0esr/debian/patches/porting/Bug-1257055-use-aarch64-atomics.patch	2017-02-07 07:52:38.0 +
@@ -0,0 +1,26 @@
+From: Makoto Kato 
+Subject: Bug 1257055 - Use jit/arm64/Architecture-arm64.h on non-JIT aarch64. r=lth
+
+MozReview-Commit-ID: EmzEDleNc7E
+--- a/js/src/jit/AtomicOperations.h
 b/js/src/jit/AtomicOperations.h
+@@ -304,6 +304,8 @@
+ || defined(__ppc64le__) || defined(__PPC64LE__) \
+ || defined(__ppc__) || defined(__PPC__)
+ # include "jit/none/AtomicOperations-ppc.h"
++#elif defined(__aarch64__)
++#  include "jit/arm64/AtomicOperations-arm64.h"
+ #elif defined(JS_CODEGEN_NONE)
+ # include "jit/none/AtomicOperations-none.h"
+ #elif defined(JS_CODEGEN_X86) || defined(JS_CODEGEN_X64)
+--- a/js/src/jit/arm64/AtomicOperations-arm64.h
 b/js/src/jit/arm64/AtomicOperations-arm64.h
+@@ -12,8 +12,6 @@
+ #include "mozilla/Assertions.h"
+ #include "mozilla/Types.h"
+ 
+-#include "jit/arm64/Architecture-arm64.h"
+-
+ inline bool
+ js::jit::AtomicOperations::isLockfree8()
+ {
diff -Nru firefox-esr-45.7.0esr/debian/patches/series firefox-esr-45.7.0esr/debian/patches/series
--- firefox-esr-45.7.0esr/debian/patches/series	2017-02-05 22:20:31.0 +
+++ firefox-esr-45.7.0esr/debian/patches/series	2017-02-07 07:43:52.0 +
@@ -26,3 +26,4 @@
 debian-hacks/Work-around-binutils-assertion-on-mips.patch
 debian-hacks/Allow-unsigned-addons-in-usr-lib-share-mozilla-exten.patch
 debian-hacks/Set-program-name-from-the-remoting-name.patch
+porting/Bug-1257055-use-aarch64-atomics.patch

Bug#854079: firefox-esr: firefox dies immediately on arm64

[Riku Voipio]

Mike Hommey wrote:
> That's fixed in 47.5.0esr-3. Can you check if you still get crashes with
> that version?

Thanks Mike for looking into this.

Indeed firefox-esr doesn't segfault in jemalloc anymore. However, I get a new
crash - I assume Aaro will get the same.

Looking at 
http://sources.debian.net/src/firefox-esr/45.7.0esr-1/js/src/jit/none/AtomicOperations-none.h/
AtomicOperations-ppc.h appears to include correct and portable implementation
(assuming gcc 4.6+). It's not clear to me what is the value of the *-none.h
file that only crashes. Using the -ppc.h instead can't make things worse.

New backtrace:

Thread 35 "DOM Worker" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f9edff1e0 (LWP 4093)]
0x007fb6341d14 in js::jit::AtomicOperations::loadSafeWhenRacy (addr=)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/jit/none/AtomicOperations-none.h:97
97  
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/jit/none/AtomicOperations-none.h:
 No such file or directory.
(gdb) bt
#0  0x007fb6341d14 in js::jit::AtomicOperations::loadSafeWhenRacy (addr=)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/jit/none/AtomicOperations-none.h:97
#1  0x007fb6348e14 in js::jit::AtomicOperations::loadSafeWhenRacy (addr=...)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/jit/AtomicOperations.h:219
#2  (anonymous namespace)::TypedArrayObjectTemplate::getIndex (
obj=0x7f9eb07680, index=0)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/TypedArrayObject.cpp:684
#3  (anonymous namespace)::TypedArrayObjectTemplate::getIndexValue (tarray=0x7f9eb07680, index=0)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/TypedArrayObject.cpp:960
#4  js::TypedArrayObject::getElement (this=this@entry=0x7f9eb07680, 
index=index@entry=0)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/TypedArrayObject.cpp:1783
#5  0x007fb62b3c18 in js::NativeObject::getDenseOrTypedArrayElement (
idx=0, this=0x7f9eb07680)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/NativeObject-inl.h:240
#6  NativeGetPropertyInline<(js::AllowGC)0> (vp=..., nameLookup=NotNameLookup, 
id=..., receiver=..., obj=0x7f9eb07680, cx=0x7f9efc)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/NativeObject.cpp:1931
#7  js::NativeGetPropertyNoGC (cx=0x7f9efc, obj=, 
receiver=..., id=..., vp=0x7f9ef7d468)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/NativeObject.cpp:1975
#8  0x007fb451fa50 in js::GetPropertyNoGC (vp=, id=..., 
receiver=..., obj=, cx=)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/NativeObject.h:1479
#9  js::GetElementNoGC (cx=, obj=, receiver=..., 
index=, vp=)
at /build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/jsobjinlines.h:210
#10 0x007fb62c8a4c in js::GetElementNoGC (vp=, 
index=, receiver=..., obj=, 
cx=)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter.cpp:2295
#11 js::GetElementNoGC (vp=, index=, 
receiver=, obj=, cx=)
at /build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/jsobjinlines.h:216
#12 js::GetObjectElementOperation (res=..., key=..., receiver=..., obj=..., 
op=, cx=)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter-inl.h:424
#13 js::GetElementOperation (res=..., rref=..., lref=..., op=, 
cx=)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter-inl.h:556
#14 Interpret (cx=0x7f9efc, state=...)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter.cpp:2608
#15 0x007fb62cd094 in js::RunScript (cx=cx@entry=0x7f9efc, state=...)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter.cpp:391
#16 0x007fb62cd3e8 in js::Invoke (cx=cx@entry=0x7f9efc, args=..., 
construct=construct@entry=js::NO_CONSTRUCT)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter.cpp:462
#17 0x007fb62d3210 in js::SpreadCallOperation (cx=0x7f9efc, 
script=..., 
pc=0x7f9eea7271 ")\005\231\rΐ\210\004\326\210\025\317\070\"\357\210\t", 
thisv=..., callee=..., arr=..., newTarget=..., res=...)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter.cpp:4549
#18 0x007fb62c2a94 in Interpret (cx=0x7f9efc, state=...)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter.cpp:2720
#19 0x007fb62cd094 in js::RunScript (cx=cx@entry=0x7f9efc, state=...)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter.cpp:391
#20 0x007fb62cd3e8 in js::Invoke (cx=cx@entry=0x7f9efc, args=..., 
construct=construct@entry=js::NO_CONSTRUCT)
at 
/build/firefox-esr-CmvRIX/firefox-esr-45.7.0esr/js/src/vm/Interpreter.cpp:462
#21 0x007fb62cdd00 in js::Invoke (cx=0x7f9efc, thisv=..., fval=..., 
argc=, argv=, rval=...)
at 

Bug#853888: bpfcc not building on ppc64el and aarch64

[Riku Voipio]

Hi,

If you submit a build to experimental, I'd be happy to
test it on aarch64 and armhf.

Riku

Bug#853108: [Pkg-chromium-maint] Bug#853108: chromium: fails to build on armhf

[Riku Voipio]

On Sun, Jan 29, 2017 at 02:59:40PM -0500, Michael Gilbert wrote:
> package: src:chromium-browser
> severity: grave
> version: 56.0.2924.76-1
 
> The upload to experimental fails to build on armhf due to new NEON code.

I have a fix for this (backport patch from upstream - NEON buildd is still
pending). Can you push the current experimental to git so I can merge the
fix on top of it, or should I just do it myself?

Riku

Bug#853170: fails to boot on debian's MP30-AR1 systems [regression]

[Riku Voipio]

On Tue, Jan 31, 2017 at 02:30:10PM +, Riku Voipio wrote:
> This hints that numerous kernel config changes we did are probably
> not the reason, but some of the kernel changes between 4.9.2 and 4.9.6.

The offending commit is:

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.9.y=74ce3fd64bc44f89856ff57bf684882dc098f93b

Upstream fix proposal:

http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/484924.html

Attached is patch verified fixing booting by simply reverting the change.

Riku
>From 23d82932b1b129b30ea2322c7ed3bffa5cb1a9ba Mon Sep 17 00:00:00 2001
From: Riku Voipio <riku.voi...@linaro.org>
Date: Wed, 1 Feb 2017 14:39:59 +0200
Subject: [PATCH] [arm64] Revert efistub changes, Closes: #853170

---
 ...libstub-arm-pass-latest-memory-map-to-the.patch | 200 +
 debian/patches/series  |   1 +
 3 files changed, 206 insertions(+), 2 deletions(-)
 create mode 100644 debian/patches/bugfix/arm64/efi-libstub-arm-pass-latest-memory-map-to-the.patch

diff --git a/debian/patches/bugfix/arm64/efi-libstub-arm-pass-latest-memory-map-to-the.patch b/debian/patches/bugfix/arm64/efi-libstub-arm-pass-latest-memory-map-to-the.patch
new file mode 100644
index 0..07f161d9e
--- /dev/null
+++ b/debian/patches/bugfix/arm64/efi-libstub-arm-pass-latest-memory-map-to-the.patch
@@ -0,0 +1,200 @@
+From 1816e2e5003836a142056957f7a813d846eba992 Mon Sep 17 00:00:00 2001
+From: Riku Voipio <riku.voi...@linaro.org>
+Date: Wed, 1 Feb 2017 13:37:49 +0200
+Subject: [PATCH] Revert "efi/libstub/arm*: Pass latest memory map to the
+ kernel"
+
+This reverts commit 74ce3fd64bc44f89856ff57bf684882dc098f93b.
+---
+ drivers/firmware/efi/libstub/efistub.h |  8 
+ drivers/firmware/efi/libstub/fdt.c | 87 --
+ 2 files changed, 39 insertions(+), 56 deletions(-)
+
+diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
+index fac67992bede..ee49cd23ee63 100644
+--- a/drivers/firmware/efi/libstub/efistub.h
 b/drivers/firmware/efi/libstub/efistub.h
+@@ -30,6 +30,14 @@ efi_status_t efi_file_close(void *handle);
+ 
+ unsigned long get_dram_base(efi_system_table_t *sys_table_arg);
+ 
++efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
++			unsigned long orig_fdt_size,
++			void *fdt, int new_fdt_size, char *cmdline_ptr,
++			u64 initrd_addr, u64 initrd_size,
++			efi_memory_desc_t *memory_map,
++			unsigned long map_size, unsigned long desc_size,
++			u32 desc_ver);
++
+ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
+ 	void *handle,
+ 	unsigned long *new_fdt_addr,
+diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
+index 921dfa047202..a6a93116a8f0 100644
+--- a/drivers/firmware/efi/libstub/fdt.c
 b/drivers/firmware/efi/libstub/fdt.c
+@@ -16,10 +16,13 @@
+ 
+ #include "efistub.h"
+ 
+-static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
+-			   unsigned long orig_fdt_size,
+-			   void *fdt, int new_fdt_size, char *cmdline_ptr,
+-			   u64 initrd_addr, u64 initrd_size)
++efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
++			unsigned long orig_fdt_size,
++			void *fdt, int new_fdt_size, char *cmdline_ptr,
++			u64 initrd_addr, u64 initrd_size,
++			efi_memory_desc_t *memory_map,
++			unsigned long map_size, unsigned long desc_size,
++			u32 desc_ver)
+ {
+ 	int node, num_rsv;
+ 	int status;
+@@ -98,23 +101,25 @@ static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
+ 	if (status)
+ 		goto fdt_set_fail;
+ 
+-	fdt_val64 = U64_MAX; /* placeholder */
++	fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map);
+ 	status = fdt_setprop(fdt, node, "linux,uefi-mmap-start",
+ 			 _val64,  sizeof(fdt_val64));
+ 	if (status)
+ 		goto fdt_set_fail;
+ 
+-	fdt_val32 = U32_MAX; /* placeholder */
++	fdt_val32 = cpu_to_fdt32(map_size);
+ 	status = fdt_setprop(fdt, node, "linux,uefi-mmap-size",
+ 			 _val32,  sizeof(fdt_val32));
+ 	if (status)
+ 		goto fdt_set_fail;
+ 
++	fdt_val32 = cpu_to_fdt32(desc_size);
+ 	status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-size",
+ 			 _val32, sizeof(fdt_val32));
+ 	if (status)
+ 		goto fdt_set_fail;
+ 
++	fdt_val32 = cpu_to_fdt32(desc_ver);
+ 	status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-ver",
+ 			 _val32, sizeof(fdt_val32));
+ 	if (status)
+@@ -143,43 +148,6 @@ static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
+ 	return EFI_LOAD_ERROR;
+ }
+ 
+-static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map)
+-{
+-	int node = fdt_path_offset(fdt, "/chosen");
+-	u64 fdt_val64;
+-	u32 fdt_val32;
+-	int err;
+-
+-	if (node < 0)
+-		return EFI_LOAD_ERROR;
+-
+-	fdt_val64 = cpu_to_fdt64((unsigned long)*map-

Bug#853170: fails to boot on debian's MP30-AR1 systems [regression]

[Riku Voipio]

Quick test with 
4.9.2-2 with new arm64 kernel config: boots
4.9.6-3 work old arm64 kernel config: booms

This hints that numerous kernel config changes we did are probably
not the reason, but some of the kernel changes between 4.9.2 and 4.9.6.

Especially between 4.9.5 and 4.9.6 a bulk of arm64 changes went in. So
next logical step is try with 4.9.5 - if that fails, there is only a 
few potential commits for breakage between 4.9.2 - 4.9.5 - and if succeeds
we have a more tedious way to go.

Riku

Bug#852493: Please enable Thunder NIC virtual function driver

[Riku Voipio]

On Wed, Jan 25, 2017 at 02:05:06AM +, Ben Hutchings wrote:
> Control: tag -1 moreinfo
> 
> On Tue, 2017-01-24 at 22:13 +, Punit Agrawal wrote:
> > Source: linux
> > Severity: wishlist
> > Tags: patch
> > 
> > While testing device passthrough with a debian guest on a Cavium
> > Thunder, I found that the virtual function(VF) driver for the built in
> > nic is not available.
> > 
> > Please enable CONFIG_THUNDER_NIC_VF in the debian kernel config.

> So long as this hardware is part of specific SoCs, we should only
> enable it for the CPU architectures used in those SoCs.  That's arm64,
> right?  (Possibly also mips64, but we don't support Cavium MIPS SoCs at
> all yet.)
 
> Shouldn't we also enable CONFIG_THUNDER_NIC_{PF,BGX,RGX} along with
> this?

I've added these and other drivers used by cavium SoC in arm64 config change
I posted[1]. I'm still in in process of refining the patch to make not change
ABI, but seems almost any config option fails the configcheck for me :/

[1] https://lists.debian.org/debian-kernel/2017/01/msg00178.html

Bug#851832: qtermwidget: missing qtf8proc support

[Riku Voipio]

Source: qtermwidget
Version: 0.7.1-1
Severity: normal
Tags: patch

The build log states:

-- Could NOT find UTF8PROC (missing:  UTF8PROC_LIBRARY
UTF8PROC_INCLUDE_DIR) 

https://buildd.debian.org/status/fetch.php?pkg=qtermwidget=amd64=0.7.1-1=1482363037=0

adding Build-dep helps:

--- qtermwidget-0.7.1/debian/control2016-12-22 00:36:22.0 +0200
+++ qtermwidget-0.7.1/debian/control2017-01-19 10:17:07.0 +0200
@@ -7,7 +7,8 @@
 Priority: optional
 Build-Depends: debhelper (>= 10),
cmake (>= 3.0.2),
-   qtbase5-dev
+   qtbase5-dev,
+   libutf8proc-dev
 Standards-Version: 3.9.8
 Vcs-Browser: 
https://anonscm.debian.org/git/pkg-lxqt/qtermwidget.git/?h=debian/sid
 Vcs-Git: https://anonscm.debian.org/git/pkg-lxqt/qtermwidget.git -b debian/sid



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#851761: obs-worker: fails to start, missing user: obsrun

[Riku Voipio]

Package: obs-worker
Version: 2.7.1-9
Severity: normal

Dear Maintainer,

After enabling in defaults, Starting obswork fails:

root@obs-worker:~# systemctl start obsworker
Job for obsworker.service failed because the control process exited with error 
code.
See "systemctl status obsworker.service" and "journalctl -xe" for details.
root@obs-worker:~# systemctl status obsworker
● obsworker.service - LSB: Open Build Service worker
   Loaded: loaded (/etc/init.d/obsworker; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-01-18 14:12:42 UTC; 3s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 7339 ExecStart=/etc/init.d/obsworker start (code=exited, 
status=1/FAILURE)

Jan 18 14:12:42 obs-worker systemd[1]: Starting LSB: Open Build Service 
worker...
Jan 18 14:12:42 obs-worker obsworker[7339]: chown: invalid user: 'obsrun:obsrun'
Jan 18 14:12:42 obs-worker systemd[1]: obsworker.service: Control process 
exited, code=exited status=1
Jan 18 14:12:42 obs-worker systemd[1]: Failed to start LSB: Open Build Service 
worker.
Jan 18 14:12:42 obs-worker systemd[1]: obsworker.service: Unit entered failed 
state.
Jan 18 14:12:42 obs-worker systemd[1]: obsworker.service: Failed with result 
'exit-code'.

The user setup should probably be moved or copied from obs-server postinst to 
obs-worker. 

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#851494: please upload new upstream version: 0.7.3

[Riku Voipio]

Package: dstat
Severity: wishlist

The homepage of dstat links to 
https://github.com/dagwieers/dstat/archive/0.7.3.tar.gz 
While the watch file errors out, so I guess that needs updating too.

Bug#827525: kvmtool: FTBFS on mips64el: guest/guest_init.o: linking 32-bit code with 64-bit code

[Riku Voipio]

Hi Andre and Dejan,

Debian stretch freeze is closing in, what's the state with the patch
for fixing mips64el build?

Riku

On 28 November 2016 at 12:40, Dejan Latinovic
<dejan.latino...@imgtec.com> wrote:
> Hi Andre,
>
> Did you have a chance to look at the patch?
>
> I did not do any additional testing. If you specify what particular tests you 
> mean I am willing to run it.
> Are you planing to forward this patch upstream or you want me to do that?
>
> Regards,
> Dejan
>
> 
> From: Andre Przywara [andre.przyw...@arm.com]
> Sent: Monday, June 20, 2016 11:13 AM
> To: Riku Voipio; Dejan Latinovic; 827...@bugs.debian.org; k...@vger.kernel.org
> Subject: Re: Bug#827525: kvmtool: FTBFS on mips64el: guest/guest_init.o: 
> linking 32-bit code with 64-bit code
>
> Hi,
>
> (thanks Riku for forwarding this!)
>
> On 17/06/16 19:31, Riku Voipio wrote:
>> On 17 June 2016 at 15:04, Dejan Latinovic <dejan.latino...@imgtec.com> wrote:
>>> Package kvmtool FTBFS for mips64el with the following error:
>>>
>>>> LINK lkvm
>>>> /usr/bin/ld: guest/guest_init.o: warning: linking abicalls files with 
>>>> non-abicalls files
>>>> /usr/bin/ld: guest/guest_init.o: linking 32-bit code with 64-bit code
>>>> /usr/bin/ld: failed to merge target specific data of file 
>>>> guest/guest_init.o
>>>> collect2: error: ld returned 1 exit status
>>>> Makefile:381: recipe for target 'lkvm' failed
>>>> make[1]: *** [lkvm] Error 1
>>>
>>> Full build log:
>>> https://buildd.debian.org/status/fetch.php?pkg=kvmtool=mips64el=0.20160419-1=1463209003
>>>
>>> The reason for that is behaviour is the way of creation guest_init.o.
>>>> ld -r -b binary -o guest/guest_init.o guest/init
>>>
>>> Resulting file is "MIPS-I" instead of expected "MIPS64 rel2".
>>>> file guest/guest_init.o.cp
>>>> guest/guest_init.o.cp: ELF 64-bit LSB relocatable, MIPS, MIPS-I version 1 
>>>> (SYSV), not stripped
>>>
>>> If options "-r -b binary" are used, linker will ignore flags of input file 
>>> "Flags: 0x8006, pic, cpic, mips64r2",
>>> and flags of resulting guest_init.o file will be  "Flags: 0x0".
>>>
>>> Solution for this issue could be using different method for creation 
>>> guest_init.o.
>>> If xxd and gcc are used instead of ld, resulting file will have regular 
>>> flags.
>>>> xxd -i guest/init | $(CC) -c -x c - -o guest/guest_init.o
>>> Here are proposed changes for this issue.
>>> http://www.spinics.net/lists/kvm/msg118016.html
>>>
>>> I have created a patch that fixes this issue modeled on mentioned solution.
>>> Using this patch I was able to build kvmtool for mips64el, mipsel, i386, 
>>> amd64.
>>> The patch is attached.
>>> Could you please consider including this patch.
>>
>> I think the patch is better applied directly upstream, I'm sure there
>> are non-Debian users who would like to use kvmtool on mips64el.
>
> Dejan, do you have a mean of actually _testing_ this?
> I haven't seen a kvmtool/MIPS user for a while (also the build is broken
> for ages), so I am curious ...
>
> Let me take a look and revive this old patch, which needs some
> adjustments due to the new (pre-)init code.
>
> Cheers,
> Andre.

Bug#849569: spice: Please package 0.13 branch to experimental

[Riku Voipio]

Hi Marc-André,

Do you think virgl code in spice-server 0.13 is solid enough to be included
in Debian stretch release? 

Michael wrote:
> So, maybe we really should let 0.13 to stretch, together with gl?

Full background at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849569

Riku

Bug#846648: [Pkg-chromium-maint] Bug#846648: another data point

[Riku Voipio]

On Tue, Dec 06, 2016 at 04:02:00PM -0500, Robert Lange wrote:
> Debian stretch with chromium 55.0.2883.75-1 (and only chromium) pulled
> in from unstable. With a brand new profile (i.e., by deleting
> .cache/chromium and .config/chromium and starting Chromium) Chromium
> aw-snaps on gfycat.com with very high probability. I occasionally also
> see gmail aw-snap, but it's not consistent. When an aw-snap occurs, it
> does not seem to affect other tabs.

I managed to reproduce this. I tested a build with using embedded 
libraries of chromium, and the aw snap problem is gone. unbundling
libraries found the library that made the difference is ffmpeg.
Dropping the FF_API_CONVERGENCE_DURATION definition makes chromium
work fine with system ffmpeg again, gfycat.com, gmail and www.maap.it
no longer "aw, snap".

The gpu stacktraces people have passed in the bug might be another bug. 

--- a/media/ffmpeg/ffmpeg_common.h
+++ b/media/ffmpeg/ffmpeg_common.h
@@ -25,14 +25,14 @@
 // Disable deprecated features which result in spammy compile warnings.  This
 // list of defines must mirror those in the 'defines' section of FFmpeg's
 // BUILD.gn file or the headers below will generate different structures!
-#define FF_API_CONVERGENCE_DURATION 0
+// #define FF_API_CONVERGENCE_DURATION 0


 
> 
> Stack trace:
> 
> libpng warning: iCCP: known incorrect sRGB profile
> Received signal 11 SEGV_MAPERR fffd503afed7
> #0 0x55f8a1a8d77e 
> #1 0x55f8a1a8db39 
> #2 0x7fca07207100 
> #3 0x55f8a025af21 
> #4 0x55f8a0260ffa 
> #5 0x55f8a02610bb 
> #6 0x55f8a5c0f612 
> #7 0x55f8a12cf952 
> #8 0x55f8a1ae7495 
> #9 0x55f8a1b13c21 
> #10 0x55f8a1aae629 
> #11 0x55f8a1aafd9d 
> #12 0x55f8a1ab0240 
> #13 0x55f8a1ab0e99 
> #14 0x55f8a1ace66a 
> #15 0x55f8a1aeb296 
> #16 0x55f8a1ae7322 
> #17 0x7fca071fd464 start_thread
> #18 0x7fc9fc6229df clone
>   r8:   r9: fffd503afecf r10: e9c46ecdadef r11:
> 0011bb10e749bd95
>  r12:  r13: 7fc9e5cb9548 r14: 7fc9e5cb9540 r15:
> e9c46ecdadef
>   di: 16393e5b0f70  si: 0013  bp: 0006  bx:
> fffd503afecf
>   dx: fffd503afecf  ax: fffd503afecf  cx: 16393ef75fa0  sp:
> 7fc9e5cb94a0
>   ip: 55f8a025af21 efl: 00010286 cgf: 002b0033 erf:
> 0005
>  trp: 000e msk:  cr2: fffd503afed7
> [end of stack trace]
> 
> ___
> Pkg-chromium-maint mailing list
> pkg-chromium-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-chromium-maint

Bug#734218: spice: Please support powerpcspe (and maybe other architectures)

[Riku Voipio]

severity 734218 important
user debian-...@lists.debian.org
usertags 734218 arm64
thanks

Wookeys patch looks good to me. Liang,  Michael, can you upload or are you ok
with an NMU?

Riku

Bug#845621: guestfs: please change build-deps for backport/arm64

[Riku Voipio]

Package: libguestfs
Version: 1:1.32.7-1~bpo8+1
Severity: wishlist
Tags: patch

libguestfs backport isn't building for arm64, because lzop is missing in 
jessie/arm64:

https://buildd.debian.org/status/package.php?p=libguestfs=jessie-backports

The attached patch appears to work, with I guess slightly degraded functionality
of the appliance. Still better than no guestfs at all.

Riku

diff -Nru libguestfs-1.32.7/debian/control libguestfs-1.32.7/debian/control
--- libguestfs-1.32.7/debian/control	2016-10-03 22:07:26.0 +0300
+++ libguestfs-1.32.7/debian/control	2016-11-25 11:18:47.0 +0200
@@ -82,7 +82,7 @@
   lsof,
   lsscsi,
   lvm2,
-  lzop,
+  lzop [!arm64],
   mdadm,
   mtools,
   nilfs-tools,

Bug#843868: ocamlbuild: invalid build-dependency: ocaml-best-compilers

[Riku Voipio]

Package: ocamlbuild
Version: 0.9.3-3
Severity: grave
Tags: experimental

ocamlbuild is failing to build since ocaml-best-compilers is a virtual package:

https://buildd.debian.org/status/package.php?p=ocamlbuild=experimental

Bug#843624: [Pkg-chromium-maint] Bug#843624: chromium: since upgrade to latest libnss3-1d chromium shows only "Aw, Snap!"

[Riku Voipio]

severity 843624 normal
tags 843624 +wheezy
thanks

On Tue, Nov 08, 2016 at 01:32:25PM +0100, J.Coltrane wrote:
> I'm running some full up to date installations of Wheezy, x86 and amd64. Since
> an update of some nameservice switch related libraries (libnspr4-0d, 
> libnss3-1d
> and libnss3) Chromium is useless. It only shows "Aw, Snap!" even on it's own
> config page. Starting Chromium with "--enable-logging --v=1" I see the
> following errors:

Hi John,

The discussion in debian-lts list (which should join) appears to show this issue
is known and a workaround/fix is happening. 

Riku

Bug#799939: chromium not available for armhf/arm64

[Riku Voipio]

On Sun, Nov 06, 2016 at 08:51:45PM -0500, Michael Gilbert wrote:
> On Thu, Oct 6, 2016 at 1:43 AM, Riku Voipio wrote:
> > Just requested on the alioth project and subscribed to the list.

> It took some time to get a response from alioth admins.  I've accepted
> your request now.  Welcome to pkg-chromium!

Thanks!

I'll start pushing an armhf/arm64 build to experimental then. Before I commit
anything to the repo, do you have any preferred git practices? 

Riku

Bug#839549: aisleriot: Takes an eternity to build, possibly related to network access

[Riku Voipio]

severity 839549 important
thanks

I can confirm this, the latest build took 4h on armhf buildd, yet the
buildd's cpu usage was 0% during this time. 

https://buildd.debian.org/status/fetch.php?pkg=aisleriot=armhf=1%3A3.22.1-1=1478592921

On amd64 build clearly see network access:

/usr/bin/xmllint --noout --noent --path sv --xinclude sv/index.docbook
http://www.oasis-open.org/docbook/xml/4.3/ent/iso-dia.ent:1: parser error : 
Content error in the external subset
HTTP/1.1 200 OK
sv/index.docbook:204: element include: XInclude error : could not load 
sv/king_albert.xml, and no fallback was found

https://buildd.debian.org/status/fetch.php?pkg=aisleriot=amd64=1%3A3.22.1-1=1478572195

you need to pass --nonet to xmllint.

Riku

Bug#843032: qemu-user-static: Upgrade fails: unable to close /proc/sys/fs/binfmt_misc/register

[Riku Voipio]

On Sun, Nov 06, 2016 at 03:59:12PM +, James Cowgill wrote:
> On Thu, 3 Nov 2016 13:15:47 +0300 Michael Tokarev <m...@tls.msk.ru> wrote:
> > 03.11.2016 12:46, Toby Speight wrote:
> > > I was able to work around this issue by hand-editing the postinst it to 
> > > add
> > > '|mips*' to the end of $omit (luckily, I don't need MIPS emulation on my
> > > systems).
> > > 
> > > The one thing that stands out about the MIPS registration is that the 
> > > magic
> > > and mask are much longer than for other systems - is it possible that the
> > > kernel can't handle such long patterns?  If so, can this be detected and
> > > avoided?
> > 
> > This change was introduced very recently, see #829243.  But it works fine
> > on my system.  I wonder if 3.16 kernel is unable to process that binfmt
> > while 4.1+ can handle it...  Oh well.
> 
> Looks like this kernel commit added support for longer formats:
> bbaecc088245e840e59a5abe23d69cf7748b3c88
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/binfmt_misc.c?id=bbaecc088245e840e59a5abe23d69cf7748b3c88
> 
> This is probably what causes this. The above commit exists only in 3.18+

The attached patch only registers the new longer patterns on 3.18+. I still
need another round for the patch. The kernel version check requires bash, and
the naive >> to > change doesn't actually make the script a bash script. But
before I invest more time into this I'd like to know if others agree this change
is the right way.

The other option is to revert the change from #829243 until a better way to
handle the change is done.

Riku

>From 919a7df74f4191092b95b5975e4687b4be0c3bdc Mon Sep 17 00:00:00 2001
From: Riku Voipio <riku.voi...@linaro.org>
Date: Mon, 7 Nov 2016 14:11:23 +0200
Subject: [PATCH] binfmt registering: work around mips registering on kernels

One needs kernel newer than 3.18 to register long form magic with
binfmt_misc. Detect the kernel version, and only register new
mips subarchitectures if kernel is 3.18 or newer. For older
kernel register the shorter version for mips/mipsel.

This solution is sub-optimal:
- if one upgrades kernel, one needs to run dpkg-reconfigure to
  gain the mips architectures
- if one *downgrades* kernel, binfmt registering will fail on boot.

Long term binfmt-support should handle this runtime. 

Closes: 843032
---
 debian/binfmt-update-in | 21 +
 debian/rules|  4 ++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/debian/binfmt-update-in b/debian/binfmt-update-in
index c0d45a2..9109ac0 100644
--- a/debian/binfmt-update-in
+++ b/debian/binfmt-update-in
@@ -1,3 +1,5 @@
+#!/bin/bash
+set -e
 # check if we're running inside an (lxc) container
 # (we may copy or move this to the postinst script too, to skip installing it)
 grep -zqs ^container= /proc/1/environ && exit 0
@@ -76,6 +78,25 @@ case "$DPKG_MAINTSCRIPT_ARCH" in
   *) omit="$DPKG_MAINTSCRIPT_ARCH" ;;
 esac
 
+# from libc preinst
+linux_compare_versions () {
+verA=$(($(echo "$1" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 1 + \2 \* 100 + \3/')))
+verB=$(($(echo "$3" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 1 + \2 \* 100 + \3/')))
+
+test $verA -$2 $verB
+}
+
+kernel_ver=`uname -r`
+if linux_compare_versions "$kernel_ver" lt 3.18
+then
+mips_magic='\x7f\x45\x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08'
+mips_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
+mipsel_magic='\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00'
+mipsel_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xfe\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
+omit="$omit|mipsn32|mipsn32el"
+echo "Skipping mipsn32 binfmt registering due to too old kernel"
+fi
+
 remove_binfmt() {
 if [ -f /var/lib/binfmts/qemu-$1 ]; then
 	update-binfmts --package @PACKAGE@ --remove qemu-$1 /usr/bin/qemu-$1@SUFFIX@
diff --git a/debian/rules b/debian/rules
index 27df782..8608d52 100755
--- a/debian/rules
+++ b/debian/rules
@@ -254,9 +254,9 @@ ifeq ($(enable_linux_user),enable)
 	# binfmt support
 	for x in postinst prerm; do \
 	sed -e s/@SUFFIX@/-static/ -e s/@PACKAGE@/qemu-user-static/ \
-		debian/binfmt-update-in >> debian/qemu-user-static.$$x.debhelper ; \
+		debian/binfmt-update-in > debian/qemu-user-static.$$x.debhelper ; \
 	sed -e s/@SUFFIX@// -e s/@PACKAGE@/qemu-user-binfmt/ \
-		debian/binfmt-update-in >> debian/qemu-user-binfmt.$$x.debhelper ; \
+		debian/binfmt-update-in > debian/qemu-user-binfmt.$$x.debhelper ; \
 	done
 
 endif	# enable_linux_user
-- 
2.1.4

Bug#837574: Patch for the qemu PIE FTBFS

[Riku Voipio]

On Wed, Oct 26, 2016 at 06:29:49PM +0300, Michael Tokarev wrote:
> 25.10.2016 11:31, Adrian Bunk wrote:
> > -LD_REL := $(CC) -nostdlib -Wl,-r $(LD_REL_FLAGS)
> > +LD_REL := $(CC) -nostdlib -r $(LD_REL_FLAGS)
 
> Adrian, can you elaborate on this a bit please?

I really wish gcc manpage explained the difference :-/ 

> I'm not sure of the possible consequences of this.
> Is this change good to be used upstream?
> Does it work the same with older compilers?

I've tested this with gcc 4.5 from the oldest
supported distro for compiling qemu (suse11),
and it works. 

Adrian, can you submit this to qemu-devel mailing list
for upstream with your Signed-off-by?  Or give us
permission to submit the patch in your behalf?

Riku

Bug#842911: [Pkg-libvirt-maintainers] Bug#842911: please reconsider dropping libvirt-bin

[Riku Voipio]

On Wed, Nov 02, 2016 at 09:23:53PM +0100, Guido Günther wrote:
> On Wed, Nov 02, 2016 at 09:36:21AM +0000, Riku Voipio wrote:
> > libvirt-bin is still referred to in many places, for example in openstack
> > devstack. The replacement -clients and -daemon-system packages are not yet
> > available in the latest ubuntu LTS. This leads to some inconvinient
> > "if ubuntu then else if debian newer than then" checks if we want to 
> > support both.
 
> It's simple as:
> 
> Depends: libvirt-daemon-system | libvirt-bin, libvirt-clients | 
> libvirt-bin

> so I'd rather not readd the transitional package. I don't want to make
> people's lifes harder than necessary though so if you think it's more
> complex please explain.

That is indeed simple for packages, but devstack case we install packages
from shellscript:

https://github.com/openstack-dev/devstack/blob/1c13be860ba3662bf6c633fc37668f7feacdd3e5/lib/nova_plugins/functions-libvirt#L27

The workaround is probably to add an "if debian && newer than jessie, install
these instead" but it's not exactly pretty. Then again installer scripts often
aren't.

Riku

Bug#842911: please reconsider dropping libvirt-bin

[Riku Voipio]

Package: libvirt
Version: 2.3.0-3
Severity: wishlist

Hi,

libvirt-bin is still referred to in many places, for example in openstack
devstack. The replacement -clients and -daemon-system packages are not yet
available in the latest ubuntu LTS. This leads to some inconvinient
"if ubuntu then else if debian newer than then" checks if we want to support 
both.

An extra dummy package doesn't really add much overhead to our archive.

Bug#791963: Please support ARM64

[Riku Voipio]

retitle 791963 Please support ARM64
tags 791963 + patch
thanks

Upstream support exists in kernel and compiling makedumpfile is just oneline 
change
in debian/control now.

Riku

diff --git a/debian/control b/debian/control
index e4174f2..c0396eb 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Vcs-Git: git://git.debian.org/collab-maint/makedumpfile.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/makedumpfile.git;a=summary
 
 Package: makedumpfile
-Architecture: i386 amd64 powerpc ia64 x32 armel armhf ppc64el s390x
+Architecture: i386 amd64 powerpc ia64 x32 armel armhf ppc64el s390x arm64
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}
 Recommends: crash, kexec-tools
 Replaces: kdump-tools (<< 1.3.4-1~)

Bug#799939: chromium not available for armhf/arm64

[Riku Voipio]

On Wed, Oct 05, 2016 at 09:59:00PM -0400, Michael Gilbert wrote:
> On Wed, Oct 5, 2016 at 2:56 PM, Riku Voipio wrote:
> > I understand if you feel the arm builds are a burden of extra work for
> > you. The churn of code in chromium and the rapidly rolling security
> > updates certainly made it challenge for me to keep building up-to-date
> > arm packages manually. So I'm certainly ready to stay around to watch
> > and fix any arm-related issues the chromium debian packages might
> > encounter.
 
> Are you willing to become comaintainer?

Just requested on the alioth project and subscribed to the list.

Riku

Bug#799939: chromium not available for armhf/arm64

[Riku Voipio]

Hi Michael,

All patches to support Chrome on arm64 and armhf have been upstreamed.
The attached patch against debian packages build and runs chromium on
my test machines (samsung chromebook for armhf and Dragonboard 410c).

I understand if you feel the arm builds are a burden of extra work for
you. The churn of code in chromium and the rapidly rolling security
updates certainly made it challenge for me to keep building up-to-date
arm packages manually. So I'm certainly ready to stay around to watch
and fix any arm-related issues the chromium debian packages might
encounter.

Riku
diff -Nru chromium-browser-53.0.2785.143/debian/control chromium-browser-53.0.2785.143/debian/control
--- chromium-browser-53.0.2785.143/debian/control	2016-09-06 02:31:04.0 +
+++ chromium-browser-53.0.2785.143/debian/control	2016-10-04 08:50:15.0 +
@@ -86,7 +86,7 @@
 Standards-Version: 3.9.8
 
 Package: chromium
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Built-Using: ${Built-Using}
 Depends:
  ${misc:Depends},
@@ -125,7 +125,7 @@
  ro, ru, sk, sl, sr, sv, sw, ta, te, th, tr, uk, vi, zh-CN, zh-TW
 
 Package: chromedriver
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
diff -Nru chromium-browser-53.0.2785.143/debian/rules chromium-browser-53.0.2785.143/debian/rules
--- chromium-browser-53.0.2785.143/debian/rules	2016-09-11 15:11:19.0 +
+++ chromium-browser-53.0.2785.143/debian/rules	2016-10-04 08:50:15.0 +
@@ -5,6 +5,7 @@
 
 # enable all build hardening flags
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
 # linker flags to avoid memory allocation issues on i386
 export LDFLAGS+=-Wl,--no-keep-memory -Wl,--reduce-memory-overheads -Wl,--hash-size=7919
@@ -23,6 +24,22 @@
 # treat all warnings as errors
 defines=werror=
 
+ifeq (arm64,$(DEB_HOST_ARCH))
+defines += \
+target_arch=arm64
+endif
+
+ifeq (armhf,$(DEB_HOST_ARCH))
+defines += \
+arm_neon=0 \
+arm_use_neon=0 \
+v8_use_arm_eabi_hardfloat=true \
+arm_float_abi=hard \
+arm_thumb=1 \
+armv7=1 \
+arm_version=7
+endif
+
 # build with gcc instead of clang
 defines+=clang=0
 defines+=clang_use_chrome_plugins=
diff -Nru chromium-browser-53.0.2785.143/debian/scripts/chromium chromium-browser-53.0.2785.143/debian/scripts/chromium
--- chromium-browser-53.0.2785.143/debian/scripts/chromium	2016-09-06 05:01:31.0 +
+++ chromium-browser-53.0.2785.143/debian/scripts/chromium	2016-10-04 08:50:15.0 +
@@ -30,11 +30,15 @@
 For more information, please read and possibly provide input to their
 bug tracking system at http://crbug.com/348761.;
 
-# Check whether this system supports sse2
-if test -z "$(grep sse2 /proc/cpuinfo)"; then
-  xmessage "$nosse2"
-  exit 1
-fi
+case `uname -m` in
+i386|i586|i686|x86_64)
+# Check whether this system supports sse2
+if ! grep -q sse2 /proc/cpuinfo; then
+xmessage "$nosse2"
+exit 1
+fi
+;;
+esac
 
 # Source additional settings
 for file in /etc/chromium.d/*; do


signature.asc
Description: Digital signature

Bug#837995: libvirt: please run tests on arm architectures

[Riku Voipio]

Source: libvirt
Version: 2.2.0-1
Severity: wishlist
Tags: patch

In my tests, libvirt tests pass fine on armhf/arm64. I take we
have newer kernel than debian builders, so it could fail in Debian.
To play safe, I suggest running tests but not failing them on arm/arm64.
This what the patch below does, being minimum impact.

The more ambitious way would be to enable tests on all platforms,
upload to experimental, and then set FAIL_CHECK for all architectures
that pass.

diff --git a/debian/rules b/debian/rules
index cf50336..0885cd6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,11 +7,12 @@ DEB_BUILDUSER=$(shell dpkg-parsechangelog -SMaintainer)
 ifneq (,$(findstring $(DEB_HOST_ARCH_OS), linux))
   ifneq (,$(findstring $(DEB_HOST_ARCH), i386 amd64))
 WITH_VBOX = --with-vbox
-MAKE_CHECK= 1
+FAIL_CHECK= 1
   else
 WITH_VBOX = --without-vbox
   endif
   ifneq (,$(findstring $(DEB_HOST_ARCH), i386 amd64 armhf arm64))
+MAKE_CHECK= 1
 WITH_XEN  = --with-xen
 WITH_LIBXL= --with-libxl
 XEN_ENABLED   = 1
@@ -154,7 +155,7 @@ override_dh_auto_test:
if ! dh_auto_test -O--builddirectory=$(DEB_BUILDDIR); then \
cat ./debian/build/gnulib/tests/test-suite.log \
./debian/build/tests/test-suite.log; \
-   exit 1; \
+   [ -n "$(FAIL_CHECK)" ] || exit 1; \
fi
 
 override_dh_install-arch:

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#837068: ITP: glshim -- Shim that translates OpenGL 1.x into OpenGL ES.

[Riku Voipio]

Package: wnpp
Severity: wishlist
Owner: Riku Voipio <riku.voi...@linaro.org>

* Package name: glshim
  Version : 0.0.20160225
  Upstream Author : Ryan Hileman <lunixbo...@gmail.com>
* URL : https://github.com/lunixbochs/glshim
* License : Expat
  Programming Lang: C
  Description : Shim that translates OpenGL 1.x into OpenGL ES.

This is a wrapper library providing OpenGL 1.x functionality using
OpenGL ES libraries as backend. The binary package will be called
libgl1-glshim-glx

Bug#835099: ITP: skales -- Boot image creation tools for qualcomm boards

[Riku Voipio]

Package: wnpp
Severity: wishlist
Owner: Riku Voipio <riku.voi...@linaro.org>

* Package name: skales
  Version : 0.20160202
  Upstream Author : Stephen Boyd
* URL : git://codeaurora.org/quic/kernel/skales
* License : BSD (3 clause)
  Programming Lang: Python and POSIX shel
  Description : Boot image creation tools for qualcomm boards

Scripts and tools used to build kernel images for some Qualcomm SoC
based boards, such as DB410c. Tools included in the package
 - dtbTool for building a QCDT table
 - mkbootimg, replacement for android's mkbootimg

Bug#737030: libgcrypt uses processor features not allowed for armhf (and i386?)

[Riku Voipio]

> hmm, looking further into the code, it looks like libgcrypt implements
> it's own way to detect hw features. But maybe somebody could confirm this

Correct. Debian armhf/armel buildd's don't have NEON unit yet testsuite
passes fine, so we even know the hw feature detection works fine. This
bug can be closed.

Riku

Bug#803031: patch: support serial serial dev/serial/by-path names

[Riku Voipio]

On 27 June 2016 at 21:56, Marc Haber <mh+debian-packa...@zugschlus.de> wrote:
> On Sun, Jun 26, 2016 at 10:39:04PM +0200, Marc Haber wrote:
>> On Mon, Oct 26, 2015 at 10:10:35AM +0200, Riku Voipio wrote:
>> > ser2net uses : as field separator in ser2net.conf. Udev creates by-path and
>> > by-id paths to identify unique serial ports. These paths are highly
>> > useful as ttyUSB* might end up shuffling around.

>> I have forwarded this upstream.

> Here is upstream's answer:
> |Unfortunately, the patch provided is not really a very good idea. If there
> |is a quote later in the data (after the separating :), it would break things
> |up wrong.

Fair enough, it's a quick hack.

> |
> |To do this right would require more complicated parsing or some creative
> |handling.  I've come up with the following options:
> |
> |* Do complicated parsing
> |* Do backslash handling and use \x3a for the colon.
> |* Allow a name (like BANNER) to be created for a device.

option 4) use a standard format like yaml and get quoting/escaping
automatically. hand-crafted parsers are a bit risky anyways.

> |
> |Of the three, I prefer the last.  These device paths are long and fairly
> |meaningless, this would allow a meaningful name to be created for these
> |devices.  And it would probably be the simplest.
> |
> |-corey
>
> He is also now subscribed here. Welcome, corey.

Thanks for working on ser2net!

Riku

Bug#827525: kvmtool: FTBFS on mips64el: guest/guest_init.o: linking 32-bit code with 64-bit code

[Riku Voipio]

On 17 June 2016 at 15:04, Dejan Latinovic  wrote:
> Package kvmtool FTBFS for mips64el with the following error:
>
>> LINK lkvm
>> /usr/bin/ld: guest/guest_init.o: warning: linking abicalls files with 
>> non-abicalls files
>> /usr/bin/ld: guest/guest_init.o: linking 32-bit code with 64-bit code
>> /usr/bin/ld: failed to merge target specific data of file guest/guest_init.o
>> collect2: error: ld returned 1 exit status
>> Makefile:381: recipe for target 'lkvm' failed
>> make[1]: *** [lkvm] Error 1
>
> Full build log:
> https://buildd.debian.org/status/fetch.php?pkg=kvmtool=mips64el=0.20160419-1=1463209003
>
> The reason for that is behaviour is the way of creation guest_init.o.
>> ld -r -b binary -o guest/guest_init.o guest/init
>
> Resulting file is "MIPS-I" instead of expected "MIPS64 rel2".
>> file guest/guest_init.o.cp
>> guest/guest_init.o.cp: ELF 64-bit LSB relocatable, MIPS, MIPS-I version 1 
>> (SYSV), not stripped
>
> If options "-r -b binary" are used, linker will ignore flags of input file 
> "Flags: 0x8006, pic, cpic, mips64r2",
> and flags of resulting guest_init.o file will be  "Flags: 0x0".
>
> Solution for this issue could be using different method for creation 
> guest_init.o.
> If xxd and gcc are used instead of ld, resulting file will have regular flags.
>> xxd -i guest/init | $(CC) -c -x c - -o guest/guest_init.o
> Here are proposed changes for this issue.
> http://www.spinics.net/lists/kvm/msg118016.html
>
> I have created a patch that fixes this issue modeled on mentioned solution.
> Using this patch I was able to build kvmtool for mips64el, mipsel, i386, 
> amd64.
> The patch is attached.
>
> Could you please consider including this patch.

I think the patch is better applied directly upstream, I'm sure there
are non-Debian users who would like to use kvmtool on mips64el.

Riku
--- kvmtool-0.20160419.orig/Makefile
+++ kvmtool-0.20160419/Makefile
@@ -395,8 +395,7 @@ endif
 $(GUEST_INIT): guest/init.c
 	$(E) "  LINK" $@
 	$(Q) $(CC) $(GUEST_INIT_FLAGS) guest/init.c -o $@
-	$(Q) $(LD) -r -b binary -o guest/guest_init.o $(GUEST_INIT)
-
+	$(Q) xxd -i $@ | $(CC) -c -x c - -o guest/guest_init.o
 %.s: %.c
 	$(Q) $(CC) -o $@ -S $(CFLAGS) -fverbose-asm $<
 
--- kvmtool-0.20160419.orig/builtin-setup.c
+++ kvmtool-0.20160419/builtin-setup.c
@@ -146,8 +146,8 @@ static int extract_file(const char *gues
 	return 0;
 }
 
-extern char _binary_guest_init_start;
-extern char _binary_guest_init_size;
+extern char guest_init;
+extern char guest_init_len;
 extern char _binary_guest_pre_init_start;
 extern char _binary_guest_pre_init_size;
 
@@ -163,8 +163,8 @@ int kvm_setup_guest_init(const char *gue
 		return err;
 #endif
 	err = extract_file(guestfs_name, "virt/init",
-&_binary_guest_init_start,
-&_binary_guest_init_size);
+_init,
+_init_len);
 	return err;
 }
 #else

Bug#799939: chromium not available for armhf/arm64

[Riku Voipio]

The latest spin of arm64/armhf support for chromium. My arm64 patches
are now upstream, but a new patch is needed for chrome 51 (included
and also submitted upstream). 

Riku

diff -Nru chromium-browser-51.0.2704.63/debian/changelog chromium-browser-51.0.2704.63/debian/changelog
--- chromium-browser-51.0.2704.63/debian/changelog	2016-05-29 01:43:34.0 +
+++ chromium-browser-51.0.2704.63/debian/changelog	2016-06-02 18:21:00.0 +
@@ -1,3 +1,10 @@
+chromium-browser (51.0.2704.63-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add arm64/armhf builds
+
+ -- Riku Voipio <riku.voi...@linaro.org>  Thu, 02 Jun 2016 21:20:42 +0300
+
 chromium-browser (51.0.2704.63-2) unstable; urgency=medium
 
   * Fix libspeechd build error.
diff -Nru chromium-browser-51.0.2704.63/debian/control chromium-browser-51.0.2704.63/debian/control
--- chromium-browser-51.0.2704.63/debian/control	2016-05-29 03:56:21.0 +
+++ chromium-browser-51.0.2704.63/debian/control	2016-06-02 18:14:14.0 +
@@ -84,7 +84,7 @@
 Standards-Version: 3.9.7
 
 Package: chromium
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Built-Using: ${Built-Using}
 Depends:
  ${misc:Depends},
@@ -122,7 +122,7 @@
  ro, ru, sk, sl, sr, sv, sw, ta, te, th, tr, uk, vi, zh-CN, zh-TW
 
 Package: chromedriver
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
diff -Nru chromium-browser-51.0.2704.63/debian/patches/aarch64-fix-sigsys.patch chromium-browser-51.0.2704.63/debian/patches/aarch64-fix-sigsys.patch
--- chromium-browser-51.0.2704.63/debian/patches/aarch64-fix-sigsys.patch	1970-01-01 00:00:00.0 +
+++ chromium-browser-51.0.2704.63/debian/patches/aarch64-fix-sigsys.patch	2016-06-02 18:24:16.0 +
@@ -0,0 +1,25 @@
+Ddescription: Fix build on arm64
+Author: Riku Voipio <riku.voi...@linaro.org>
+Forwarded: https://codereview.chromium.org/2033733002/
+
+Index: chromium-browser-50.0.2661.94/mojo/shell/runner/host/linux_sandbox.cc
+===
+--- chromium-browser-50.0.2661.94.orig/mojo/shell/runner/host/linux_sandbox.cc
 chromium-browser-50.0.2661.94/mojo/shell/runner/host/linux_sandbox.cc
+@@ -39,12 +39,16 @@ intptr_t SandboxSIGSYSHandler(const stru
+   const sandbox::syscall_broker::BrokerProcess* broker_process =
+   static_cast(aux);
+   switch (args.nr) {
++#if defined(__NR_access)
+ case __NR_access:
+   return broker_process->Access(reinterpret_cast(args.args[0]),
+ static_cast(args.args[1]));
++#endif
++#if defined(__NR_open)
+ case __NR_open:
+   return broker_process->Open(reinterpret_cast(args.args[0]),
+   static_cast(args.args[1]));
++#endif
+ case __NR_faccessat:
+   if (static_cast(args.args[0]) == AT_FDCWD) {
+ return broker_process->Access(
diff -Nru chromium-browser-51.0.2704.63/debian/patches/series chromium-browser-51.0.2704.63/debian/patches/series
--- chromium-browser-51.0.2704.63/debian/patches/series	2016-05-29 01:27:17.0 +
+++ chromium-browser-51.0.2704.63/debian/patches/series	2016-06-02 18:21:25.0 +
@@ -19,3 +19,4 @@
 
 webui.patch
 system/speechd.patch
+aarch64-fix-sigsys.patch
diff -Nru chromium-browser-51.0.2704.63/debian/rules chromium-browser-51.0.2704.63/debian/rules
--- chromium-browser-51.0.2704.63/debian/rules	2016-05-29 05:43:33.0 +
+++ chromium-browser-51.0.2704.63/debian/rules	2016-06-02 18:25:23.0 +
@@ -5,6 +5,7 @@
 
 # enable all build hardening flags
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
 # linker flags to avoid memory allocation issues on i386
 export LDFLAGS+=-Wl,--no-keep-memory -Wl,--reduce-memory-overheads -Wl,--hash-size=7919
@@ -19,6 +20,22 @@
 # treat all warnings as errors
 defines=werror=
 
+ifeq (arm64,$(DEB_HOST_ARCH))
+defines += \
+target_arch=arm64
+endif
+
+ifeq (armhf,$(DEB_HOST_ARCH))
+defines += \
+arm_neon=0 \
+arm_use_neon=0 \
+v8_use_arm_eabi_hardfloat=true \
+arm_float_abi=hard \
+arm_thumb=1 \
+armv7=1 \
+arm_version=7
+endif
+
 # build with gcc instead of clang
 defines+=clang=0
 defines+=clang_use_chrome_plugins=
diff -Nru chromium-browser-51.0.2704.63/debian/scripts/chromium chromium-browser-51.0.2704.63/debian/scripts/chromium
--- chromium-browser-51.0.2704.63/debian/scripts/chromium	2016-02-12 02:52:44.0 +
+++ chromium-browser-51.0.2704.63/debian/scripts/chromium	2016-06-02 18:20:36.0 +
@@ -30,11 +30,15 @@
 For more information, please read and possibly provide input to their
 bug tracking system at http://crbug.com/348761.;
 
-# Check whether this system supports sse2
-if test -z "$(grep sse2 /proc/cpuinfo)"; then
-  xmessage "$nosse2"
-  exit

Bug#730903: mutrace: FTBFS: b-d on libiberty-dev instead of binutils-dev No such file or directory

[Riku Voipio]

On 12 May 2016 at 19:47, Fernando Seiti Furusato  wrote:
> Actually, this works, not replacing build-deps, but adding
> libiberty-dev in addition to binutils-dev.

Thanks, uploading fixed version.

> With that and adding -I/usr/include/libiberty as suggested by
> YunQiang Su, the package built in a clean chroot (using sbuild).
>
> I produced a debdiff which does the aforementioned, attached here.
>
> Thanks and regards.
>
> Fernando

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[Riku Voipio]

On Sat, Apr 09, 2016 at 12:02:44PM +0200, Graham Inggs wrote:
> On 9 April 2016 at 00:53, peter green  wrote:
> > It would be useful if someone can reproduce the issue and get a dissasembly
> > of the failure location.
> 
> I hope this is useful.  I'll leave my screen session on abel.d.o. open
> in case I need to fetch more information.
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> WARNING: unable to determine host cpu name.
> exports.jl
> essentials.jl
> docs/bootstrap.jl
> base.jl
> reflection.jl
> build_h.jl
> version_git.jl
 
> Program received signal SIGILL, Illegal instruction.
> 0x940c5060 in julia_call_891 ()
> (gdb) disassemble $pc
> Dump of assembler code for function julia_call_891:
>0x940c5054 <+0>: push{r4, r5, r6, lr}
>0x940c5058 <+4>: vpush   {d8}
>0x940c505c <+8>: mov r0, #40 ; 0x28
> => 0x940c5060 <+12>:vorrd8, d0, d0

And yes, vorr is an NEON instruction.

>0x940c5064 <+16>:mov r4, r3
>0x940c5068 <+20>:mov r5, r2
>0x940c506c <+24>:mov r6, r1
>0x940c5070 <+28>:bl  0x940c50c4
>0x940c5074 <+32>:movwr1, #16432  ; 0x4030
>0x940c5078 <+36>:movtr1, #37900  ; 0x940c
>0x940c507c <+40>:ldr r1, [r1]
>0x940c5080 <+44>:stmda   r0, {r1, r6}
>0x940c5084 <+48>:ldr r1, [sp, #24]
>0x940c5088 <+52>:str r5, [r0, #4]
>0x940c508c <+56>:str r4, [r0, #8]
>0x940c5090 <+60>:str r1, [r0, #12]
>0x940c5094 <+64>:ldr r1, [sp, #28]
>0x940c5098 <+68>:str r1, [r0, #16]
>0x940c509c <+72>:ldrbr1, [sp, #32]
>0x940c50a0 <+76>:and r1, r1, #1
>0x940c50a4 <+80>:strbr1, [r0, #20]
>0x940c50a8 <+84>:ldr r1, [sp, #36]   ; 0x24
>0x940c50ac <+88>:str r1, [r0, #24]
>0x940c50b0 <+92>:vstrd8, [r0, #32]
>0x940c50b4 <+96>:vpop{d8}
>0x940c50b8 <+100>:   pop {r4, r5, r6, pc}
> End of assembler dump.

 

Bug#819890: haskell-http2: FTBFS on armel buildds (was: Re: Please give back haskell-http2 on armel)

[Riku Voipio]

On Sun, Apr 03, 2016 at 03:11:39PM +0100, Steven Chamberlain wrote:
> Wookey wrote:
> > +++ Steven Chamberlain [2016-04-01 10:31 +0100]:
> > > Currently haskell-http2 FTBFS on only armel:
> > > https://buildd.debian.org/status/package.php?p=haskell-http2=unstable
> > > delaying the package's testing migration and keeping many reverse-deps
> > > BD-Uninstallable on armel.
> > > 
> > > More recently than that it has successfully built:
> > > https://tests.reproducible-builds.org/rbuild/unstable/armhf/haskell-http2_1.5.3-2.rbuild.log
> > > 
> > > Therefore, please could it be given back for another build attempt?
> > > 
> > >   gb haskell-http2_1.5.3-2 . armel
> > 
> > Seems a reasonable request.
> > done
 
> Thanks;  it didn't work though.  Please could arm porters take a look?
 
> The reproducible-builds log shows the test suite passing, whereas on the
> buildds one test failed, on both build attempts.

The reproducible-builds is armhf while the failing ones are armel. The 
regression
appears to be a code change in haskell-http2 between 1.0.4 and 1.3.1:

https://buildd.debian.org/status/logs.php?pkg=haskell-http2=armel

Riku

Bug#769364: arm64: Error in `Xtightvnc': free(): invalid next size (fast)

[Riku Voipio]

Hi,

Sorry, wrong patch in previous mail. This one is correct.

Riku
diff -Nru tightvnc-1.3.9/debian/changelog tightvnc-1.3.9/debian/changelog
--- tightvnc-1.3.9/debian/changelog	2016-01-24 21:23:35.0 +0200
+++ tightvnc-1.3.9/debian/changelog	2016-03-23 15:24:23.0 +0200
@@ -1,3 +1,10 @@
+tightvnc (1.3.9-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to complete arm64 port, Closes: #769364
+
+ -- Riku Voipio <riku.voi...@linaro.org>  Wed, 23 Mar 2016 15:23:49 +0200
+
 tightvnc (1.3.9-7) unstable; urgency=medium
 
   * Applied a patch from upstream to fix a crash. Closes: #782620.
diff -Nru tightvnc-1.3.9/debian/patches/more-arm64-fixes.patch tightvnc-1.3.9/debian/patches/more-arm64-fixes.patch
--- tightvnc-1.3.9/debian/patches/more-arm64-fixes.patch	1970-01-01 02:00:00.0 +0200
+++ tightvnc-1.3.9/debian/patches/more-arm64-fixes.patch	2016-03-23 16:03:46.0 +0200
@@ -0,0 +1,44 @@
+Index: tightvnc-1.3.9/Xvnc/include/Xmd.h
+===
+--- tightvnc-1.3.9.orig/Xvnc/include/Xmd.h
 tightvnc-1.3.9/Xvnc/include/Xmd.h
+@@ -59,7 +59,7 @@ SOFTWARE.
+ #ifdef CRAY
+ #define WORD64/* 64-bit architecture */
+ #endif
+-#if defined(__alpha) || defined(__alpha__) || defined(__x86_64__) || defined(__powerpc64__)
++#if defined(__alpha) || defined(__alpha__) || defined(__x86_64__) || defined(__powerpc64__) || defined(__aarch64__)
+ #define LONG64/* 32/64-bit architecture */
+ #endif
+ #ifdef __sgi
+Index: tightvnc-1.3.9/Xvnc/programs/Xserver/include/servermd.h
+===
+--- tightvnc-1.3.9.orig/Xvnc/programs/Xserver/include/servermd.h
 tightvnc-1.3.9/Xvnc/programs/Xserver/include/servermd.h
+@@ -405,6 +405,26 @@ SOFTWARE.
+ 
+ #endif /* linux/m68k */
+ 
++#if defined (linux) && defined(__aarch64__)
++#  define BITMAP_SCANLINE_UNIT			64
++# define BITMAP_SCANLINE_PAD 			64
++# define LOG2_BITMAP_PAD			6
++# define LOG2_BYTES_PER_SCANLINE_PAD		3
++
++/* Add for handling protocol XPutImage and XGetImage; see comment in
++ * Alpha section.
++ */
++#define INTERNAL_VS_EXTERNAL_PADDING
++#define BITMAP_SCANLINE_UNIT_PROTO		32
++
++#define BITMAP_SCANLINE_PAD_PROTO 	 	32
++#define LOG2_BITMAP_PAD_PROTO			5
++#define LOG2_BYTES_PER_SCANLINE_PAD_PROTO	2
++#define GLYPHPADBYTES  4
++#define GETLEFTBITS_ALIGNMENT  1
++
++#endif /* linux/aarch64 */
++
+ #if defined (linux) && defined(__powerpc__)
+ 
+ #ifdef __powerpc64__
diff -Nru tightvnc-1.3.9/debian/patches/series tightvnc-1.3.9/debian/patches/series
--- tightvnc-1.3.9/debian/patches/series	2016-01-24 21:20:13.0 +0200
+++ tightvnc-1.3.9/debian/patches/series	2016-03-23 13:50:46.0 +0200
@@ -5,3 +5,4 @@
 aarch64.patch
 ppc64el.patch
 782620-crashfix.patch
+more-arm64-fixes.patch

Bug#769364: arm64: Error in `Xtightvnc': free(): invalid next size (fast)

[Riku Voipio]

tags 769364 + patch
user debian-...@lists.debian.org
usertags 769364 arm64
usertags 794326 arm64
thanks

Hi,

With the attached patch, tightvnc server works for me with bpp 24 on an
arm64 host.

Riku
diff -Nru tightvnc-1.3.9/debian/changelog tightvnc-1.3.9/debian/changelog
--- tightvnc-1.3.9/debian/changelog	2016-01-24 21:23:35.0 +0200
+++ tightvnc-1.3.9/debian/changelog	2016-03-23 15:24:23.0 +0200
@@ -1,3 +1,10 @@
+tightvnc (1.3.9-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to complete arm64 port, Closes: #769364
+
+ -- Riku Voipio <riku.voi...@linaro.org>  Wed, 23 Mar 2016 15:23:49 +0200
+
 tightvnc (1.3.9-7) unstable; urgency=medium
 
   * Applied a patch from upstream to fix a crash. Closes: #782620.
diff -Nru tightvnc-1.3.9/debian/patches/more-arm64-fixes.patch tightvnc-1.3.9/debian/patches/more-arm64-fixes.patch
--- tightvnc-1.3.9/debian/patches/more-arm64-fixes.patch	1970-01-01 02:00:00.0 +0200
+++ tightvnc-1.3.9/debian/patches/more-arm64-fixes.patch	2016-03-23 15:16:24.0 +0200
@@ -0,0 +1,33 @@
+--- a/Xvnc/include/Xmd.h
 b/Xvnc/include/Xmd.h
+@@ -59,7 +59,7 @@
+ #ifdef CRAY
+ #define WORD64/* 64-bit architecture */
+ #endif
+-#if defined(__alpha) || defined(__alpha__) || defined(__x86_64__) || defined(__powerpc64__)
++#if defined(__alpha) || defined(__alpha__) || defined(__x86_64__) || defined(__powerpc64__) || defined(__aarch64__)
+ #define LONG64/* 32/64-bit architecture */
+ #endif
+ #ifdef __sgi
+--- a/Xvnc/programs/Xserver/include/servermd.h
 b/Xvnc/programs/Xserver/include/servermd.h
+@@ -405,6 +405,19 @@
+ 
+ #endif /* linux/m68k */
+ 
++#if defined (linux) && defined(__aarch64__)
++#if defined(__LITTLE_ENDIAN__)
++#define IMAGE_BYTE_ORDER   LSBFirst
++#define BITMAP_BIT_ORDER   LSBFirst
++#else
++#define IMAGE_BYTE_ORDER   MSBFirst
++#define BITMAP_BIT_ORDER   MSBFirst
++#endif
++#define GLYPHPADBYTES  4
++#define GETLEFTBITS_ALIGNMENT  1
++
++#endif /* linux/aarch64 */
++
+ #if defined (linux) && defined(__powerpc__)
+ 
+ #ifdef __powerpc64__
diff -Nru tightvnc-1.3.9/debian/patches/series tightvnc-1.3.9/debian/patches/series
--- tightvnc-1.3.9/debian/patches/series	2016-01-24 21:20:13.0 +0200
+++ tightvnc-1.3.9/debian/patches/series	2016-03-23 13:50:46.0 +0200
@@ -5,3 +5,4 @@
 aarch64.patch
 ppc64el.patch
 782620-crashfix.patch
+more-arm64-fixes.patch

Bug#794326: enable arm64 assember routines

[Riku Voipio]

tags 794326 +patch
thanks

The attached patch gives 2x-10x improvements on aes-128-ctr and sha256
tests with openssl speed (tested on cortex-a53 and cortex-57)


diff -Nru openssl-1.0.2g/debian/patches/debian-targets.patch openssl-1.0.2g/debian/patches/debian-targets.patch
--- openssl-1.0.2g/debian/patches/debian-targets.patch  2016-01-28 18:36:07.0 +
+++ openssl-1.0.2g/debian/patches/debian-targets.patch  2016-03-17 10:45:16.0 +
@@ -1,8 +1,8 @@
-Index: openssl-1.0.2f/Configure
+Index: openssl-1.0.2g/Configure
 ===
 openssl-1.0.2f.orig/Configure
-+++ openssl-1.0.2f/Configure
-@@ -127,6 +127,10 @@ my $clang_devteam_warn = "-Wno-unused-pa
+--- openssl-1.0.2g.orig/Configure
 openssl-1.0.2g/Configure
+@@ -131,6 +131,10 @@ my $clang_devteam_warn = "-Wno-unused-pa
  # Warn that "make depend" should be run?
  my $warn_make_depend = 0;

@@ -13,7 +13,7 @@
  my $strict_warnings = 0;

  my $x86_gcc_des="DES_PTR DES_RISC1 DES_UNROLL";
-@@ -363,6 +367,55 @@ my %table=(
+@@ -367,6 +371,55 @@ my %table=(
  "osf1-alpha-cc",  "cc:-std1 -tune host -O4 -readonly_strings::(unknown):::SIXTY_FOUR_BIT_LONG RC4_CHUNK:${alpha_asm}:dlfcn:alpha-osf1-shared:::.so",
  "tru64-alpha-cc", "cc:-std1 -tune host -fast -readonly_strings::-pthread:::SIXTY_FOUR_BIT_LONG RC4_CHUNK:${alpha_asm}:dlfcn:alpha-osf1-shared::-msym:.so",

@@ -21,7 +21,7 @@
 +"debian-alpha","gcc:${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +"debian-alpha-ev4","gcc:${debian_cflags} -mcpu=ev4::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +"debian-alpha-ev5","gcc:${debian_cflags} -mcpu=ev5::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"debian-arm64","gcc:-DL_ENDIAN ${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"debian-arm64","gcc:-DL_ENDIAN ${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${aarch64_asm}:linux64:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +"debian-armel","gcc:-DL_ENDIAN ${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${armv4_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +"debian-armhf","gcc:-DL_ENDIAN ${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${armv4_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 +"debian-amd64", "gcc:-m64 -DL_ENDIAN ${debian_cflags} -DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::",

Bug#817965: kvmtool: dumps core when Linux reboots: in gdb: Program received signal SIG34, Real-time event 34.

[Riku Voipio]

Hi,

On 12 March 2016 at 07:27, Paul Wise  wrote:
> Due to #817962, Linux reboots after not finding the filesystem and then
> lkvm crashes due to not handling the reboot properly. gdb gives this:

> Program received signal SIG34, Real-time event 34.

I couldn't reproduce with. lkm run will end up with a reboot yes, but
there is no segfault or SIG34 recieved.

> Full log and backtrace:
>
> pabs@chianamo ~ $ lkvm run
> ...
> [0.348574] VFS: Cannot open root device "(null)" or unknown-block(0,0): 
> error -19
> [0.349459] Please append a correct "root=" boot option; here are the 
> available partitions:
> [0.350443] Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(0,0)
> [0.351421] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-1-amd64 #1 
> Debian 4.4.4-2
> [0.352476]  0086 cc1a1833 812ea6b5 
> 817eea98
> [0.352563]  88001a083ea0 8116619a 8810 
> 88001a083eb0
> [0.352563]  88001a083e48 cc1a1833 8808 
> 88001a083eb8
> [0.352563] Call Trace:
> [0.352563]  [] ? dump_stack+0x5c/0x77
> [0.352563]  [] ? panic+0xd3/0x215
> [0.352563]  [] ? mount_block_root+0x202/0x296
> [0.352563]  [] ? prepare_namespace+0x131/0x167
> [0.352563]  [] ? kernel_init_freeable+0x1e2/0x205
> [0.352563]  [] ? rest_init+0x80/0x80
> [0.352563]  [] ? kernel_init+0xa/0xe0
> [0.352563]  [] ? ret_from_fork+0x3f/0x70
> [0.352563]  [] ? rest_init+0x80/0x80
> [0.352563] Kernel Offset: disabled
> [0.352563] Rebooting in 1 seconds..
>   # KVM compatibility warning.
> virtio-9p device was not detected.
> While you have requested a virtio-9p device, the guest kernel did not 
> initialize it.
> Please make sure that the guest kernel was compiled with 
> CONFIG_NET_9P_VIRTIO=y enabled in .config.
>
>   # KVM compatibility warning.
> virtio-net device was not detected.
> While you have requested a virtio-net device, the guest kernel did 
> not initialize it.
> Please make sure that the guest kernel was compiled with 
> CONFIG_VIRTIO_NET=y enabled in .config.
> Segmentation fault (core dumped)
> pabs@chianamo ~ $ gdb -batch -n -ex 'set height 0' -ex run -ex bt -ex 'thread 
> apply all bt full' --args lkvm run
> ...
> [0.334751] VFS: Cannot open root device "(null)" or unknown-block(0,0): 
> error -19
> [0.335359] Please append a correct "root=" boot option; here are the 
> available partitions:
> [0.336047] Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(0,0)
> [0.336733] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.4.0-1-amd64 #1 
> Debian 4.4.4-2
> [0.337344]  0086 cde01d0b 812ea6b5 
> 817eea98
> [0.337969]  88001a083ea0 8116619a 8810 
> 88001a083eb0
> [0.338592]  88001a083e48 cde01d0b 8808 
> 88001a083eb8
> [0.339214] Call Trace:
> [0.339422]  [] ? dump_stack+0x5c/0x77
> [0.339842]  [] ? panic+0xd3/0x215
> [0.340030]  [] ? mount_block_root+0x202/0x296
> [0.340030]  [] ? prepare_namespace+0x131/0x167
> [0.340030]  [] ? kernel_init_freeable+0x1e2/0x205
> [0.340030]  [] ? rest_init+0x80/0x80
> [0.340030]  [] ? kernel_init+0xa/0xe0
> [0.340030]  [] ? ret_from_fork+0x3f/0x70
> [0.340030]  [] ? rest_init+0x80/0x80
> [0.340030] Kernel Offset: disabled
> [0.340030] Rebooting in 1 seconds..
> Program received signal SIG34, Real-time event 34.
> [Switching to Thread 0x7fffcfda9700 (LWP 13949)]
> 0x76bd32d7 in ioctl () at ../sysdeps/unix/syscall-template.S:81
> 81  ../sysdeps/unix/syscall-template.S: No such file or directory.
> #0  0x76bd32d7 in ioctl () at ../sysdeps/unix/syscall-template.S:81
> #1  0x00409455 in kvm_cpu__run (vcpu=) at kvm-cpu.c:40
> #2  0x0040950f in kvm_cpu__start (cpu=0x6555c0) at kvm-cpu.c:99
> #3  0x004051a7 in kvm_cpu_thread (arg=) at 
> builtin-run.c:174
> #4  0x779bd284 in start_thread (arg=0x7fffcfda9700) at 
> pthread_create.c:333
> #5  0x76bdaa4d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>
> Thread 12 (Thread 0x7fffce5a6700 (LWP 13952)):
> #0  __pthread_kill (threadid=, signo=34) at 
> ../sysdeps/unix/sysv/linux/pthread_kill.c:62
> pd = 
> tid = 13952
> val = 0
> #1  0x0040a04e in kvm__reboot (kvm=0x653b80) at kvm.c:410
> i = 
> #2  0x0041bd26 in kbd_write_command (val=, 
> kvm=) at hw/i8042.c:166
> No locals.
> #3  kbd_out (ioport=, vcpu=, port= out>, data=, size=) at hw/i8042.c:327
> data = 
> vcpu = 
> ioport = 
> port = 100
> size = 
> #4  0x00408f87 in kvm__emulate_io (vcpu=vcpu@entry=0x657410, 
> port=, data=, direction=1, size=1, 
> count=) at ioport.c:196
> ops = 0x62e630 
> ret = 
>  

Bug#817962: kvmtool: does not work with Debian kernels

[Riku Voipio]

severity 817962 normal
thanks

> I don't think we should ship kvmtool in stretch without a Linux kernel
> flavour for it. If you agree, please upgrade this bug to serious. Right
> now the Debian Linux kernel packages don't have CONFIG_NET_9P_VIRTIO
> and CONFIG_VIRTIO_NET enabled. For kvmtool we probably want a trimmed
> down Linux flavour for both speed and attack surface reduction.

kvmtool will work with debian kernel, you just need to pass -i initrd
parameter, since virtio is built as modules in the debian kernel. In
case the initrd in /boot has been tailored for your host, you may have
construct a different initrd for lkvm.

> pabs@chianamo ~ $ lkvm run
>   # lkvm run -k /boot/vmlinuz-4.4.0-1-amd64 -m 448 -c 4 --name guest-15121
> PPrroobbiinngg  EE  ((ee==oo  ttoo  ddiissaabbllee))..  ookk
>
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) 
> (gcc version 5.3.1 20160224 (Debian 5.3.1-10) ) #1 SMP Debian 4.4.4-2 
> (2016-03-09)
> [0.00] Command line: noapic noacpi pci=conf1 reboot=k panic=1 
> i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 console=ttyS0 earlyprintk=serial 
> i8042.noaux=1 rw rootflags=trans=virtio,version=9p2000.L,cache=loose 
> rootfstype=9p init=/virt/pre_init  ip=dhcp
> [0.00] CPU: vendor_id 'LKVMLKVMLKVM' unknown, using generic init.
> [0.00] CPU: Your system may be unstable.
> [0.00] x86/fpu: Legacy x87 FPU detected.
> [0.00] x86/fpu: Using 'lazy' FPU context switches.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000f-0x000e] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x1bff] usable
> [0.00] bootconsole [earlyser0] enabled
> [0.00] NX (Execute Disable) protection: active
> [0.00] DMI not present or invalid.
> [0.00] Hypervisor detected: KVM
> [0.00] e820: last_pfn = 0x1c000 max_arch_pfn = 0x4
> [0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
> [0.00] MTRR: Disabled
> [0.00] CPU MTRRs all blank - virtualized system.
> [0.00] found SMP MP-table at [mem 0x000f0370-0x000f037f] mapped at 
> [880f0370]
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI BIOS Error (bug): A valid RSDP was not found 
> (20150930/tbxfroot-243)
> [0.00] No NUMA configuration found
> [0.00] Faking a node at [mem 0x-0x1bff]
> [0.00] NODE_DATA(0) allocated [mem 0x1bffc000-0x1bff]
> [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
> [0.00] kvm-clock: cpu 0, msr 0:1bff4001, primary cpu clock
> [0.00] kvm-clock: using sched offset of 189012120618513 cycles
> [0.00] clocksource: kvm-clock: mask: 0x max_cycles: 
> 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
> [0.00] Zone ranges:
> [0.00]   DMA32[mem 0x1000-0x1bff]
> [0.00]   Normal   empty
> [0.00]   Device   empty
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x1000-0x0009efff]
> [0.00]   node   0: [mem 0x0010-0x1bff]
> [0.00] Initmem setup node 0 [mem 
> 0x1000-0x1bff]
> [0.00] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org
> [0.00] Intel MultiProcessor Specification v1.4
> [0.00] MPTABLE: OEM ID: KVMCPU00
> [0.00] MPTABLE: Product ID: 0.1
> [0.00] MPTABLE: APIC at: 0xFEE0
> [0.00] Processor #0 (Bootup-CPU)
> [0.00] Processor #1
> [0.00] Processor #2
> [0.00] Processor #3
> [0.00] IOAPIC[0]: apic_id 5, version 17, address 0xfec0, GSI 0-23
> [0.00] Unknown bustype  - ignoring
> [0.00] Processors: 4
> [0.00] smpboot: Allowing 5 CPUs, 1 hotplug CPUs
> [0.00] PM: Registered nosave memory: [mem 0x-0x0fff]
> [0.00] PM: Registered nosave memory: [mem 0x0009f000-0x0009]
> [0.00] PM: Registered nosave memory: [mem 0x000a-0x000e]
> [0.00] PM: Registered nosave memory: [mem 0x000f-0x000fefff]
> [0.00] PM: Registered nosave memory: [mem 0x000ff000-0x000f]
> [0.00] e820: [mem 0x1c00-0x] available for PCI devices
> [0.00] Booting paravirtualized kernel on KVM
> [0.00] clocksource: refined-jiffies: mask: 0x max_cycles: 
> 0x, max_idle_ns: 7645519600211568 ns
> [0.00] 

Bug#799939:

[Riku Voipio]

On 9 March 2016 at 11:00, Raphael Hertzog  wrote:
> what's the status of this bug? I would love to see chromium on armhf and
> arm64.

I've have armhf/arm64 builds of chromium for jessie at:

http://repo.linaro.org/ubuntu/linaro-overlay/pool/main/c/chromium-browser/

> Michael, it looks like Riku upstreamed most of the important changes and
> what's left is reasonable to include in the Debian package.

The patches upstream are a bit different. This week I'm at a
conferences, but for next week I can backport the patches against 49.

Riku

Bug#813141: chroot upgrade from jessie to stretch disables predictable network interface names

[Riku Voipio]

reassign 813141 udev
thanks

# we enabled net.ifnames in 220-7 by default; don't change iface names in
# virtualized envs (where 75-persistent-net-generator.rules didn't work)

I think we need a more precise check for affected systems rather than the
lack of existance of /etc/udev/rules.d/70-persistent-net.rules. For example
machines without network adapters would get disabled ifnames. once a 
network

adapter is attached, they would get a legacy ifnames.

Like the virtio-net check below, it should probably be restricted to 
affected

network drivers.

Bug#801588: libirman: Multiple issues, some of which blocks updating LIRC

[Riku Voipio]

Hi,

On torstaina 17. joulukuuta 2015 18.42.40 EET, Gianfranco Costamagna wrote:

control: severity -1 important

Hi dear maintainer, I write here to make you aware of my intent 
to NMU this package and lirc.


Let me know if you need a sponsor or you want to review 
changes, otherwise I'll follow NMU rules because the team seems 
dead and nobody seems interested in lirc anymore


As a former maintainer, please go ahead. If you need help, feel free to 
ask.


Riku

Bug#795841: protobuf: Please package version 3.0.0a3 of protobuf

[Riku Voipio]

On perjantaina 4. joulukuuta 2015 17.55.15 EET, Robert Edmonds wrote:

Riku Voipio wrote:
protobuf3 is now in beta. Since this package is in 
collab-maint, do you mind

if update the package in archive?


Hi, Riku:

The protobuf packaging repository is moving to a dedicated packaging
group on Alioth, which is working on the protobuf 3 release:

https://alioth.debian.org/projects/pkg-protobuf/

The repository in collab-maint will probably be retired after protobuf 3
is uploaded to the archive.


Thanks for updating the state. The bugreport was silent so I was left
wondering.


If you're interested in helping with the protobuf package please join
the pkg-protobuf-devel mailing list and coordinate there with the other
folks working on protobuf 3.  IIRC, there are a lot of disruptive
upstream changes that make the update from protobuf 2.x to protobuf 3
not so simple.


I did a quick packaging at:

https://people.debian.org/~riku/protobuf/

I think best way to weed out disruptive upstream changes would be upload to 
experimental. 

Bug#795841: protobuf: Please package version 3.0.0a3 of protobuf

[Riku Voipio]

Hi,

protobuf3 is now in beta. Since this package is in collab-maint, do you 
mind if update the package in archive?


Riku

Bug#799939:

[Riku Voipio]

Hi,

Michael wrote:

> These  changes are larger than I would like.  Please upstream them
> first, especially the assembly changes to openmax.

Submitted and applied upstream: https://codereview.chromium.org/1420973006/
Sandbox patch is also applied, and boringssl compiler flag changes has just been
submitted.

On 18 November 2015 at 23:26, Joost van Zwieten
<joostvanzwie...@gmail.com> wrote:
> On 3 November 2015 at 20:37, Joost van Zwieten
> <joostvanzwie...@gmail.com> wrote:
> That took a bit longer than expected. With the latest binutils from
> experimental I was still unable to link chromium: ld failed with the
> message 'Memory exhausted'. I came up the following solution: reduce
> the amount of debug information to line numbers only. Passing
> '-gline-tables-only' to clang does the job, see fourth attached patch.
> With all patches applied I can successfully build chromium.

I've verified that linking succeeds with these change on abel.debian.org,
which is identical to the Debian armhf builders.

Attached is the combined patch of my arm64 changes and Joost's armhf changes
against the experimental version of chromium:

ps. notice the vaapi.patch is broken. It assumes the tests "arch!=arm" and
"arch = x86" are identical.
diff -Nru chromium-browser-47.0.2526.16/debian/control chromium-browser-47.0.2526.16/debian/control
--- chromium-browser-47.0.2526.16/debian/control	2015-10-25 04:00:14.0 +0200
+++ chromium-browser-47.0.2526.16/debian/control	2015-10-28 21:53:26.0 +0200
@@ -82,10 +82,11 @@
  libgcrypt20-dev,
  fonts-ipafont-gothic,
  fonts-ipafont-mincho,
+ binutils (>= 2.25.1-7.1) [armhf],
 Standards-Version: 3.9.6
 
 Package: chromium
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Built-Using: ${Built-Using}
 Depends:
  ${misc:Depends},
@@ -106,7 +107,7 @@
  This package contains the web browser component.
 
 Package: chromium-dbg
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Section: debug
 Priority: extra
 Built-Using: ${Built-Using}
@@ -135,7 +136,7 @@
  ro, ru, sk, sl, sr, sv, sw, ta, te, th, tr, uk, vi, zh-CN, zh-TW
 
 Package: chromedriver
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
diff -Nru chromium-browser-47.0.2526.16/debian/patches/aarch64-fixes.patch chromium-browser-47.0.2526.16/debian/patches/aarch64-fixes.patch
--- chromium-browser-47.0.2526.16/debian/patches/aarch64-fixes.patch	1970-01-01 02:00:00.0 +0200
+++ chromium-browser-47.0.2526.16/debian/patches/aarch64-fixes.patch	2015-11-16 17:50:26.0 +0200
@@ -0,0 +1,29 @@
+Index: chromium-browser-47.0.2526.16/content/common/sandbox_linux/bpf_gpu_policy_linux.cc
+===
+--- chromium-browser-47.0.2526.16.orig/content/common/sandbox_linux/bpf_gpu_policy_linux.cc
 chromium-browser-47.0.2526.16/content/common/sandbox_linux/bpf_gpu_policy_linux.cc
+@@ -194,8 +194,11 @@ ResultExpr GpuBrokerProcessPolicy::Evalu
+ #if !defined(OS_CHROMEOS)
+ // The broker process needs to able to unlink the temporary
+ // files that it may create. This is used by DRI3.
++#if !defined(__aarch64__)
+ case __NR_unlink:
+-#endif
++#endif // !defined(__aarch64__)
++case __NR_unlinkat:
++#endif // !defined(OS_CHROMEOS)
+   return Allow();
+ default:
+   return GpuProcessPolicy::EvaluateSyscall(sysno);
+Index: chromium-browser-47.0.2526.16/third_party/boringssl/boringssl.gyp
+===
+--- chromium-browser-47.0.2526.16.orig/third_party/boringssl/boringssl.gyp
 chromium-browser-47.0.2526.16/third_party/boringssl/boringssl.gyp
+@@ -40,6 +40,7 @@
+   'conditions': [
+ ['OS == "linux" or OS == "android"', {
+   'sources': [ '<@(boringssl_linux_aarch64_sources)' ],
++  'cflags': [ '-march=armv8-a+crypto', ],
+ }, {
+   'defines': [ 'OPENSSL_NO_ASM' ],
+ }],
diff -Nru chromium-browser-47.0.2526.16/debian/patches/aarch64_openmax_clang.patch chromium-browser-47.0.2526.16/debian/patches/aarch64_openmax_clang.patch
--- chromium-browser-47.0.2526.16/debian/patches/aarch64_openmax_clang.patch	1970-01-01 02:00:00.0 +0200
+++ chromium-browser-47.0.2526.16/debian/patches/aarch64_openmax_clang.patch	2015-11-06 16:00:35.0 +0200
@@ -0,0 +1,308 @@
+From 4636f5bb744c0828ac853e1a513e375886fcd424 Mon Sep 17 00:00:00 2001
+From: Riku Voipio <riku.voi...@linaro.org>
+Date: Thu, 5 Nov 2015 15:34:36 -0800
+Subject: [PATCH] arm64: clang assembler compatability
+
+Fixes to compile with clang (3.7)
+
+- Fix fmul syntax:
+ fmul  v0.2s,v1.2s,v2.2s[0] ->  v0.2s,v1.2s,v2.s[0]
+- lowercase RSB macro call to -> rsb
+- add w modifier and use U32 in and out for fastlog2()
+
+With these changes openmax_dl compiles as part 

Bug#805796: www.debian.org: please mention httpredir.d.o on mirror page(s)

[Riku Voipio]

Hi,

While at it:

https://packages.debian.org/sid/arm64/bash/download

Doesn't mention httpredir either. 

Riku

Bug#804250: san...@debian.org, l...@alaxarxa.net

[Riku Voipio]

found 804250 3.0~dfsg-3
thanks

> Linker script needs adjustment to include typeinfo as need?

I've confirmed that rebuilding assimp with removing the following bit:

   
-DCMAKE_SHARED_LINKER_FLAGS="-Wl,--version-script=$(CURDIR)/debian/libassimp3.ver
 $(LDFLAGS)" \

Makes armhf linking against assimp3 work. I don't know anything about 
linker scripts, and much less about c++ symbols, so I can't propose a change
against libassimp3.ver that would export only the neccesary symbols.

As a quick fix one could disable linker script on armhf and armel archs?

Riku

Bug#804250: libassimp3v5: undefined reference to 'typeinfo for Assimp::IOSystem'

[Riku Voipio]

This breaks also building rviz and ros-robot-model.

../devel/lib/libcollada_urdf.so.1.11.8: undefined reference to `typeinfo for 
Assimp::IOSystem'

Linker script needs adjustment to include typeinfo as need?

Riku

Bug#803031: patch: support serial serial dev/serial/by-path names

[Riku Voipio]

Package: ser2net
Version: 2.9.1-1
Severity: wishlist
Tags: patch

Hi,

ser2net uses : as field separator in ser2net.conf. Udev creates by-path and
by-id paths to identify unique serial ports. These paths are highly
useful as ttyUSB* might end up shuffling around.

But the by-path symlink has always a : in the filename, and by-id might:

# arndale
7001:telnet:0:'/dev/serial/by-path/pci-:00:1d.0-usb-0:1.8.4.2:1.0-port0':115200
8DATABITS NONE 1STOPBIT

In this case the by-id doesn't, but it illustrates that the name comes
from the device and can have anything in the name. 

The attached patch adds quoting to ser2net device name:

--- x/ser2net-2.9.1/readconfig.c2013-07-24 19:04:39.0 +0300
+++ ser2net-2.9.1/readconfig.c  2015-10-26 09:55:53.973462321 +0200
@@ -379,7 +379,14 @@
return;
 }
 
-devname = strtok_r(NULL, ":", _data);
+if (strtok_data[0] == '\'') {
+/* device name may contains character ':'
+ eg. 
2003:raw:5:'/dev/serial/by-path/pci-:00:1d.1-usb-0:2.1:1.0-port0':9600 */
+devname = strtok_r(NULL, "'", _data);
+}
+else {
+devname = strtok_r(NULL, ":", _data);
+}
 if (devname == NULL) {
syslog(LOG_ERR, "No device name given on line %d", lineno);
return;


origin of patch:

https://github.com/Lingku/mser2net/commit/e36aa4b12d896e056c13759105ee9380c1f20fbe

Github seems to carry severaly useful forks of ser2net, all in having
useful features yet not beeing very actively maintained :(

https://github.com/longshine/ser2nets
https://github.com/Lingku/mser2net

Riku

Bug#799939: chromium: does not build / is not available for armhf

[Riku Voipio]

Hi,

Here's cleaned up patch against pkg-chromium git. I've now briefly tested the
built chromium runs on armhf hw and a bit more extensively on arm64 hw.

Michael, how would you feel about sending at test build at experimental? 

Riku

>From 10a49f52d08b576e82613a90de4a7ec1e036f387 Mon Sep 17 00:00:00 2001
From: Riku Voipio <riku.voi...@linaro.org>
Date: Wed, 21 Oct 2015 15:50:07 +0300
Subject: [PATCH] armhf and arm64 support

Add support for building chromium on armhf and arm64
---
 debian/control  |   7 +-
 debian/patches/aarch64-fixes.patch  |  42 +
 debian/patches/aarch64_openmax_clang.patch  | 273 
 debian/patches/series   |   3 +
 debian/patches/silence-clang-warnings.patch |  15 ++
 debian/rules|  22 +++
 debian/scripts/chromium |  26 ++-
 7 files changed, 380 insertions(+), 8 deletions(-)
 create mode 100644 debian/patches/aarch64-fixes.patch
 create mode 100644 debian/patches/aarch64_openmax_clang.patch
 create mode 100644 debian/patches/silence-clang-warnings.patch

diff --git a/debian/control b/debian/control
index 5172532..b21442e 100644
--- a/debian/control
+++ b/debian/control
@@ -81,10 +81,11 @@ Build-Depends:
  libgcrypt20-dev,
  fonts-ipafont-gothic,
  fonts-ipafont-mincho,
+ binutils (>= 2.25.1-7.1) [armhf],
 Standards-Version: 3.9.6
 
 Package: chromium
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Built-Using: ${Built-Using}
 Depends:
  ${misc:Depends},
@@ -105,7 +106,7 @@ Description: web browser
  This package contains the web browser component.
 
 Package: chromium-dbg
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Section: debug
 Priority: extra
 Built-Using: ${Built-Using}
@@ -134,7 +135,7 @@ Description: web browser - language packs
  ro, ru, sk, sl, sr, sv, sw, ta, te, th, tr, uk, vi, zh-CN, zh-TW
 
 Package: chromedriver
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
diff --git a/debian/patches/aarch64-fixes.patch b/debian/patches/aarch64-fixes.patch
new file mode 100644
index 000..cac330a
--- /dev/null
+++ b/debian/patches/aarch64-fixes.patch
@@ -0,0 +1,42 @@
+Index: chromium-browser-46.0.2490.13/content/common/sandbox_linux/bpf_gpu_policy_linux.cc
+===
+--- chromium-browser-46.0.2490.13.orig/content/common/sandbox_linux/bpf_gpu_policy_linux.cc
 chromium-browser-46.0.2490.13/content/common/sandbox_linux/bpf_gpu_policy_linux.cc
+@@ -194,8 +194,11 @@ ResultExpr GpuBrokerProcessPolicy::Evalu
+ #if !defined(OS_CHROMEOS)
+ // The broker process needs to able to unlink the temporary
+ // files that it may create. This is used by DRI3.
++#if !defined(__aarch64__)
+ case __NR_unlink:
+-#endif
++#endif // !defined(__aarch64__)
++case __NR_unlinkat:
++#endif // !defined(OS_CHROMEOS)
+   return Allow();
+ default:
+   return GpuProcessPolicy::EvaluateSyscall(sysno);
+Index: chromium-browser-46.0.2490.13/third_party/ffmpeg/ffmpeg.gyp
+===
+--- chromium-browser-46.0.2490.13.orig/third_party/ffmpeg/ffmpeg.gyp
 chromium-browser-46.0.2490.13/third_party/ffmpeg/ffmpeg.gyp
+@@ -267,7 +267,7 @@
+ '-fno-omit-frame-pointer',
+   ],
+ }],  # target_arch == "ia32"
+-['target_arch == "arm"', {
++['target_arch == "arm" or target_arch =="arm64" ', {
+   # On arm we use gcc to compile the assembly.
+   'sources': [
+ '<@(asm_sources)',
+Index: chromium-browser-46.0.2490.13/third_party/boringssl/boringssl.gyp
+===
+--- chromium-browser-46.0.2490.13.orig/third_party/boringssl/boringssl.gyp
 chromium-browser-46.0.2490.13/third_party/boringssl/boringssl.gyp
+@@ -40,6 +40,7 @@
+   'conditions': [
+ ['OS == "linux" or OS == "android"', {
+   'sources': [ '<@(boringssl_linux_aarch64_sources)' ],
++  'cflags': [ '-march=armv8-a+crypto', ],
+ }, {
+   'defines': [ 'OPENSSL_NO_ASM' ],
+ }],
diff --git a/debian/patches/aarch64_openmax_clang.patch b/debian/patches/aarch64_openmax_clang.patch
new file mode 100644
index 000..82ac45d
--- /dev/null
+++ b/debian/patches/aarch64_openmax_clang.patch
@@ -0,0 +1,273 @@
+From 7f322e1714aca3d77f826a313bbbe106950ad67e Mon Sep 17 00:00:00 2001
+From: Riku Voipio <riku.voi...@linaro.org>
+Date: Fri, 16 Oct 2015 16:29:58 +0300
+Subject: [PATCH] arm64: use correct syntax for FMUL
+
+While the current syntax is accepted by gcc, clang refuses it. According
+to ARM ARM, it seems gcc is a bit too flexible, and clang is correct to
+refuse it.
+

Bug#799939: chromium: does not build / is not available for armhf

[Riku Voipio]

Hi,

I didn't notice these messages since I was on the CC list.

> ../../media/base/audio_video_metadata_extractor.cc:116:17: error: use
> of undeclared identifier 'avcodec_get_name'; did you mean
> 'avcodec_get_type'

You need ffmpeg packages backports. The libav in jessie is too old.

I have now package down at:

http://repo.linaro.org/ubuntu/linaro-staging/pool/main/c/chromium-browser/

Apart from the debian/chromium wrapper script, the arm64 build works
great. Didn't test armhf build yet.

debdiff attached.

Commentary:

- the clang -> clang-3.7 diff is probably unneeded now that clang-3.6 was
fixed.
- binutils is needed for: #801879
- openmax changes submitted to 
https://code.google.com/p/webrtc/issues/detail?id=5090
- gpu, ffmpeg, boringssl fixes not sent upstream yet



diff -Nru chromium-browser-46.0.2490.13/debian/changelog chromium-browser-46.0.2490.13/debian/changelog
--- chromium-browser-46.0.2490.13/debian/changelog	2015-09-05 20:45:44.0 +0300
+++ chromium-browser-46.0.2490.13/debian/changelog	2015-10-16 13:58:31.0 +0300
@@ -1,3 +1,11 @@
+chromium-browser (46.0.2490.13-1.1) UNRELEASED; urgency=medium
+
+  * armhf and arm64 buildd
+  * build with clang-3.7 since older clangs are broken on armhf
+  * use gcc for build on arm64 since asm file fail to compile
+
+ -- Riku Voipio <r...@asachi.debian.org>  Fri, 25 Sep 2015 18:07:49 +
+
 chromium-browser (46.0.2490.13-1) experimental; urgency=medium
 
   * New upstream beta release.
diff -Nru chromium-browser-46.0.2490.13/debian/control chromium-browser-46.0.2490.13/debian/control
--- chromium-browser-46.0.2490.13/debian/control	2015-09-05 20:44:49.0 +0300
+++ chromium-browser-46.0.2490.13/debian/control	2015-10-20 16:25:31.0 +0300
@@ -8,7 +8,8 @@
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-chromium/pkg-chromium.git
 Homepage: http://www.chromium.org/Home
 Build-Depends:
- clang (>= 3.5),
+ binutils (>= 2.25.1-7.1) [armhf],
+ clang-3.7,
  debhelper (>= 9),
  gyp,
  python3,
@@ -85,7 +86,7 @@
 Standards-Version: 3.9.6
 
 Package: chromium
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Built-Using: ${Built-Using}
 Depends:
  ${misc:Depends},
@@ -106,7 +107,7 @@
  This package contains the web browser component.
 
 Package: chromium-dbg
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Section: debug
 Priority: extra
 Built-Using: ${Built-Using}
@@ -135,7 +136,7 @@
  ro, ru, sk, sl, sr, sv, sw, ta, te, th, tr, uk, vi, zh-CN, zh-TW
 
 Package: chromedriver
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
diff -Nru chromium-browser-46.0.2490.13/debian/patches/0001-arm64-use-correct-syntax-for-FMUL.patch chromium-browser-46.0.2490.13/debian/patches/0001-arm64-use-correct-syntax-for-FMUL.patch
--- chromium-browser-46.0.2490.13/debian/patches/0001-arm64-use-correct-syntax-for-FMUL.patch	1970-01-01 02:00:00.0 +0200
+++ chromium-browser-46.0.2490.13/debian/patches/0001-arm64-use-correct-syntax-for-FMUL.patch	2015-10-19 12:52:32.0 +0300
@@ -0,0 +1,273 @@
+From 7f322e1714aca3d77f826a313bbbe106950ad67e Mon Sep 17 00:00:00 2001
+From: Riku Voipio <riku.voi...@linaro.org>
+Date: Fri, 16 Oct 2015 16:29:58 +0300
+Subject: [PATCH] arm64: use correct syntax for FMUL
+
+While the current syntax is accepted by gcc, clang refuses it. According
+to ARM ARM, it seems gcc is a bit too flexible, and clang is correct to
+refuse it.
+---
+ third_party/openmax_dl/dl/sp/src/arm/arm64/ComplexToRealFixup.S   |  2 +-
+ .../armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_s.S   |  2 +-
+ third_party/openmax_dl/dl/sp/src/arm/arm64/armSP_FFT_CToC_FC32_Radix2_s.S | 17 
+ third_party/openmax_dl/dl/sp/src/arm/arm64/armSP_FFT_CToC_FC32_Radix4_s.S | 51 --
+ .../arm/arm64/armSP_FFT_CToC_FC32_Radix8_fs_s.S| 16 +++
+ 5 files changed, 46 insertions(+), 42 deletions(-)
+
+Index: chromium-browser-46.0.2490.13/third_party/openmax_dl/dl/sp/src/arm/arm64/ComplexToRealFixup.S
+===
+--- chromium-browser-46.0.2490.13.orig/third_party/openmax_dl/dl/sp/src/arm/arm64/ComplexToRealFixup.S
 chromium-browser-46.0.2490.13/third_party/openmax_dl/dl/sp/src/arm/arm64/ComplexToRealFixup.S
+@@ -93,7 +93,7 @@
+ #define qT2   v18.2s
+ #define qT3   v20.2s
+ 
+-#define half  v0.2s
++#define half  v0.s
+ #define dZip  v21.2s
+ #define dZip8bv21.8b
+ 
+@@ -106,7 +106,7 @@
+ 
+ clz order, subFFTNum// N = 2^order
+ 
+-RSB order,order,#63
++rsb order,order,#63
+ MOV subFFTSize,subFFTNum// subFFTSize = N/2
+ //MOV subFFTNum,N
+ mov argDst, pDst
+@@ -127,7 +127,7 @@
+ MOV zero,#0
+ movdX0rs[1],zero
+ lsl step,subFFTSize, #3   // step = N/2 * 8 by

Bug#801695: clang segfaults on hello world on arm64

[Riku Voipio]

Hi,

Seems this has been fixed with the latest 3.6.2-2 upload.

 clang -v
 Debian clang version 3.6.2-2 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
 clang hello.c -o hello
 ./hello
 Hello World

Riku